1. Michael Damian Tiemann 2. USA, Chapel Hill, North Carolina 3. VP, Open Source Affairs (and former hacker) 4. Red Hat, Inc. (in Raleigh) 5. My goals are to push some extra useful packages that are built for other or ancient distros into Fedora Extras. These packages are ones that I believe will greatly expand the relevance of Fedora as a development platform because of the additional communities they bring with them. In particular:
* revive blender3d for FC2/Extras (was in FC1/Extras) * add support for the R language (see http://www.r-project.org/) * bring GRASS to Fedora (FreeGIS has been funded to do this) * bring in the latest and greatest free bioinformatics sw * see if the new eGroupware stuff is ready for FC2/Extras
As for doing QA, I can certainly do sanity checking of packages that I've built or that others have built but not published to Fedora.
6. Historical qualifications * A long time ago in a galaxy far away, I was a GCC hacker * I know C, C++, and can parse bash, perl, and many other languages * You should trust me because (1) Christian Gafton knows how to find me (I work in the same building) and (2) Warren Togami brought me macademia nuts from Hawaii
7. GPG KEYID and fingerprint:
[tiemann@localhost tiemann]$ gpg --keyserver pgp.mit.edu --fingerprint ea0ac0e4 pub 1024D/EA0AC0E4 2003-08-14 Michael Tiemann (CTO, Red Hat) tiemann@redhat.com Key fingerprint = F0AD 3368 D24A 56CD A2AD 6A12 CAB3 2E89 EA0A C0E4 sub 1024g/BB6171EB 2003-08-14 [expires: 2008-08-12]
M
On Wed, 2004-06-30 at 11:03, Michael Tiemann wrote:
- add support for the R language (see http://www.r-project.org/)
Is already in bugzilla.fedora.us.
Hmmm...I see Fedora BZ #826 for R-1.8.1 and FC1. I've just sent an email to Martyn Plummer, who's email is on the R-1.9.1 Fedora packages asking what needs to be done for R-1.9.1 re: FC2. If there's a BZ for R-1.9.1 on FC2, I didn't see it (couldn't find it).
M
On Wed, 2004-06-30 at 05:20, Gérard Milmeister wrote:
On Wed, 2004-06-30 at 11:03, Michael Tiemann wrote:
- add support for the R language (see http://www.r-project.org/)
Is already in bugzilla.fedora.us.
Gérard Milmeister Tannenrauchstrasse 35 8038 Zürich gemi@bluewin.ch
On Wed, Jun 30, 2004 at 05:31:29AM -0400, Michael Tiemann wrote:
Hmmm...I see Fedora BZ #826 for R-1.8.1 and FC1. I've just sent an email to Martyn Plummer, who's email is on the R-1.9.1 Fedora packages asking what needs to be done for R-1.9.1 re: FC2. If there's a BZ for R-1.9.1 on FC2, I didn't see it (couldn't find it).
It's best to keep all questions and QA in bugzilla.
It's probably just missing the FC2 keyword, QA'ing on FC2 is fine.o
Paul
On Wed, 2004-06-30 at 11:31, Michael Tiemann wrote:
Hmmm...I see Fedora BZ #826 for R-1.8.1 and FC1. I've just sent an email to Martyn Plummer, who's email is on the R-1.9.1 Fedora packages asking what needs to be done for R-1.9.1 re: FC2. If there's a BZ for R-1.9.1 on FC2, I didn't see it (couldn't find it).
I have the R-1.9.1 src ready, I will upload it as soon as possible, and change the BZ entry accordingly.
On Wed, Jun 30, 2004 at 05:03:51AM -0400, Michael Tiemann wrote:
- bring in the latest and greatest free bioinformatics sw
I packaged or ported a number of tools already: EMBOSS, Bioperl, Biojava, Pfaat, Artemis, Jalview, ClustalW, sim4, GBrowse, plus a lot of support Perl modules. I also have a package for T_coffee, but never heard back from the authors about redistribution, as the documentation says you need their permission first - maybe you could help there.
What has held me back so far has been the lack of spare time in recent months and, to a greater extent, the absence of a more automated procedure for package submission. There was a discussion about that several months ago on this list, with Eric Raymond and others. Some seem to have started working with the "old" fedora.us process, while others like me are probably waiting for the final infrastructure to be in place.
On Wed, 2004-06-30 at 11:31, Rudi Chiarito wrote:
On Wed, Jun 30, 2004 at 05:03:51AM -0400, Michael Tiemann wrote:
- bring in the latest and greatest free bioinformatics sw
I packaged or ported a number of tools already: EMBOSS, Bioperl, Biojava, Pfaat, Artemis, Jalview, ClustalW, sim4, GBrowse, plus a lot of support Perl modules. I also have a package for T_coffee, but never heard back from the authors about redistribution, as the documentation says you need their permission first - maybe you could help there.
Wouldn't it be easier to have a Yum repository for the bioinformatics stuff? Along the lines of Planet CCRMA for audio and softsynths.
On Wed, Jun 30, 2004 at 11:55:24AM +0100, John Hearns wrote:
Wouldn't it be easier to have a Yum repository for the bioinformatics stuff?
That's what I did at work - yum for FC2 and good old autoupdate for FC1/RH. That's not visible from outside, though, and I fear the legal/bureaucratic process to host the repository for external access would be long and complex (there's no lack of hardware or networking connectivity).
The repository actually started on my pages at the local LUG, which is, from time to time, what I point struggling biologists to. Unfortunately, the box is a bit underpowered to handle load spikes, so I never made any public announcements. I was just hoping to simply kill the repository once Fedora had a streamlined submission process, but that's apparently still in progress.
On Wed, Jun 30, 2004 at 12:31:32PM +0200, Rudi Chiarito wrote:
On Wed, Jun 30, 2004 at 05:03:51AM -0400, Michael Tiemann wrote:
- bring in the latest and greatest free bioinformatics sw
I packaged or ported a number of tools already: EMBOSS, Bioperl, Biojava, Pfaat, Artemis, Jalview, ClustalW, sim4, GBrowse, plus a lot of support Perl modules. I also have a package for T_coffee, but never heard back from the authors about redistribution, as the documentation says you need their permission first - maybe you could help there.
On Wed, Jun 30, 2004 at 02:58:56PM +0200, Rudi Chiarito wrote:
On Wed, Jun 30, 2004 at 11:55:24AM +0100, John Hearns wrote:
Wouldn't it be easier to have a Yum repository for the bioinformatics stuff?
That's what I did at work - yum for FC2 and good old autoupdate for FC1/RH. That's not visible from outside, though, and I fear the legal/bureaucratic process to host the repository for external access would be long and complex (there's no lack of hardware or networking connectivity).
As another post suggested there is a very nice repo for bioinformatics and expression analysis called BIOrpms (http://apt.bea.ki.se/). Its maintainer is Bent Terp (cced).
Perhaps you want to join forces and have your packages submitted with his site? The DNA (dis?)assembling tux logo is also very cool :)
The repository actually started on my pages at the local LUG, which is, from time to time, what I point struggling biologists to. Unfortunately, the box is a bit underpowered to handle load spikes, so I never made any public announcements. I was just hoping to simply kill the repository once Fedora had a streamlined submission process, but that's apparently still in progress.
On Wed, Jun 30, 2004 at 05:37:53PM +0200, Axel Thimm wrote:
As another post suggested there is a very nice repo for bioinformatics and expression analysis called BIOrpms (http://apt.bea.ki.se/). Its maintainer is Bent Terp (cced).
I wish I had heard about it when I started packaging things last year!
I notice, though, that it has T-Coffee, while the documentation page at
http://igs-server.cnrs-mrs.fr/~cnotred/Documentation/t_coffee/t_coffee_doc.h...
states that it can't be redistributed without permission and it also includes code by others.
I'll be glad to work with Bent Terp to include stuff that is not already in his tree (the EMBOSS web frontend, jalview, artemis, etc.) or to merge what is in common.
On Wed, 30 Jun 2004 14:58:56 +0200, Rudi Chiarito wrote:
I was just hoping to simply kill the repository once Fedora had a streamlined submission process, but that's apparently still in progress.
And no one discusses any details, so it is not known what you would like the "streamlined submission process" to look like.
The current package submission procedure is focused on testing packages prior to release and prior to submitting them to the non-automated build system. Packagers might find that filling in bugzilla forms is an extra burden. Some might want to upload their packages into an /incoming FTP directory and be done. But actually, too many submitted packages either fail to build or contain bugs which ought to be corrected prior to first release. Effectively, new packages need to be reviewed or else the build team would be overloaded with failed build attempts (there is no automated build system yet) or many package bugs would enter the repository.
At fedora.us, further QA policy changes are in the queue. One which allows for new packages to enter the "unstable" repository after a very basic review (in particular the security relevant checks) and then hope that the community reports any missing flaws. But even then, the packagers ought to make sure their packages build at least on all the target platforms and adhere to the packaging guidelines, too. The packagers themselves should do a good portion of the QA for their packages. For instance, there is documentation on how to use 'fedora-rmdevelrpms' or 'mach' to find missing build dependencies. And there are several other packaging topics covered in the Wiki, too.
The most time consuming parts of the current submission process are when
* a package doesn't build (a review stops here unless the reviewers does the packager's work and completes build requirements or develops fixes)
* a packager doesn't reply to bugzilla comments for a long time (either because he's entirely occupied with other stuff or has lost interest or has a different point of view than the reviewer / even a status update would be nice)
* basic functionality testing and reviewing of package contents raises a few questions (e.g. disabled features, files in questionable locations), but the answers take a long time / the reviewers move on, look into other packages, and see how unfinished packages in their queue piles up
* packagers don't improve the submitted and reviewed package, but return with a major version upgrade and completely rewritten and reformatted spec files (a diff is useless!)
* the packager doesn't seem to do the final step of the submission process--the verification of the binary packages--and probably expects QA people to do that, too, without saying a word
On Wed, Jun 30, 2004 at 05:53:32PM +0200, Michael Schwendt wrote:
And no one discusses any details, so it is not known what you would like the "streamlined submission process" to look like.
Eric Raymond discussed it eloquently a few months ago and I also stated it in my first email today: the absence of a more automated process. At least that's _my_ own take on it.
system. Packagers might find that filling in bugzilla forms is an extra burden. Some might want to upload their packages into an /incoming FTP directory and be done. But actually, too many submitted packages either
Again, Eric already explained that Bugzilla forces packagers/developers to enter data that is already available to a simple shell script. Plus, it can get awkward if you need to submit one of those programs that rely on a bunch of Perl modules (and, in turn, the latter's dependencies).
I'll admit that some of the trouble is more imaginary than real: five minutes spent copying, pasting and double-checking can easily seem like an eternity, when it's actually a mere five minutes... but why waste them, if it can be avoided?
Here's Eric's page on his proposed solution: http://www.catb.org/~esr/fedora-submit/
team would be overloaded with failed build attempts (there is no automated build system yet) or many package bugs would enter the repository.
This brings back the need for, I think, tools like mach. Should mach be part of FC? Should it be sanctioned as a required tool for packagers? On the other hand, should the inclusion and endorsement, perhaps, be postponed until mach can be made to use yum rather than apt-rpm? Documentation is good, but having the tools available out of the box further reduces any inertia (mine included).
On Wed, 30 Jun 2004 18:53:39 +0200, Rudi Chiarito wrote:
On Wed, Jun 30, 2004 at 05:53:32PM +0200, Michael Schwendt wrote:
And no one discusses any details, so it is not known what you would like the "streamlined submission process" to look like.
Eric Raymond discussed it eloquently a few months ago and I also stated it in my first email today: the absence of a more automated process. At least that's _my_ own take on it.
Known thing, and what you can do with rpm --querytags and friends was no news. But what has happened to the xmlrpc based bugzilla access?
I'll admit that some of the trouble is more imaginary than real: five minutes spent copying, pasting and double-checking can easily seem like an eternity, when it's actually a mere five minutes... but why waste them, if it can be avoided?
You cannot avoid human interaction as in setting bugzilla keywords and replying to comments. You could only avoid that with ultimately trusted package maintainers who get direct access to a build/publish system.
team would be overloaded with failed build attempts (there is no automated build system yet) or many package bugs would enter the repository.
This brings back the need for, I think, tools like mach. Should mach be part of FC?
No. It's in fedora.us already in the "stable" repository (much to the disliking of some people) and the fedora.us build system uses a modified version, http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/ but that is not an automated build system.
Should it be sanctioned as a required tool for packagers?
No, because it behaves differently than plain rpmbuild.
On Wed, Jun 30, 2004 at 07:07:59PM +0200, Michael Schwendt wrote:
You cannot avoid human interaction as in setting bugzilla keywords and
Of course you can't avoid human interaction, but at the very least you can reduce it (reducing the associated errors as well). That's the reason why e.g. you get notifications of changes to a Bugzilla report and why you click on the URL in the mail from Bugzilla, rather than copying it in manually in your browser.
No. It's in fedora.us already in the "stable" repository (much to the disliking of some people) and the fedora.us build system uses a modified
What are these people's objections? Instability? The use of apt-rpm? Security? Anything else?
I agree it's not a perfect tool, but IMHO it still beats the alternative of using nothing at all.
Should it be sanctioned as a required tool for packagers?
No, because it behaves differently than plain rpmbuild.
I did not mean that as in "a requirement for RPMs" (all of them); I rather meant it as in "a requirement for RPMs to be included in FC/FE".
My point is: get mach, rpmlint and equivalents into FC (not FE). The ultimate test would be: given a fresh Fedora install, how much work does it take to build an arbitrary package from a SRPM or SPEC+archive? how much effort does it take to verify that it builds on the current distribution as well as on at least another version? Make those two tasks reasonably simple and quick; at that point people like me will have no excuses - except for "the dog ate my SRPM".
On Wed, 30 Jun 2004 23:18:40 +0200, Rudi Chiarito wrote:
[mach]
No. It's in fedora.us already in the "stable" repository (much to the disliking of some people) and the fedora.us build system uses a modified
What are these people's objections? Instability? The use of apt-rpm? Security? Anything else?
Some issues collected here: http://tinyurl.com/2hbgy
My point is: get mach, rpmlint and equivalents into FC (not FE).
rpmlint is not bullet-proof and reports several false positives and misses many packaging mistakes. If it isn't customized--as the fedora.us rpmlint is a bit (or also take a look at http://bugzilla.fedora.us/show_bug.cgi?id=1788 )--it is less helpful.
On Thu, Jul 01, 2004 at 12:06:19AM +0200, Michael Schwendt wrote:
On Wed, 30 Jun 2004 23:18:40 +0200, Rudi Chiarito wrote:
[mach]
No. It's in fedora.us already in the "stable" repository (much to the disliking of some people) and the fedora.us build system uses a modified
What are these people's objections? Instability? The use of apt-rpm? Security? Anything else?
Some issues collected here: http://tinyurl.com/2hbgy
My point is: get mach, rpmlint and equivalents into FC (not FE).
rpmlint is not bullet-proof and reports several false positives and misses many packaging mistakes. If it isn't customized--as the fedora.us rpmlint is a bit (or also take a look at http://bugzilla.fedora.us/show_bug.cgi?id=1788 )--it is less helpful.
http://people.redhat.com/laroche/ also contains an rpmlint with some changes for Fedora Core. rpmlint looks at many items that get less interesting to verify like the Group: given in a spec-file, but I welcome anyone cleaning this up and starting to improve the current version. I also heard the upstream maintainer would be very co-operative to add patches/changes.
greetings,
Florian La Roche
On Wednesday 30 June 2004 05:03, Michael Tiemann wrote:
- bring GRASS to Fedora (FreeGIS has been funded to do this)
Excellent. GRASS plus some good GUI tools and the ability to tie in GPS would fulfil the need for a good mapping/tracking suite, even though GRASS is a little over powered for that job, it has all the tools.
- bring in the latest and greatest free bioinformatics sw
There is a bioinformatics repository out there that is pulled in with the ATrpms configuration; http://apt.bea.ki.se/biorpms/ is the location. R is one of the packages there. As I don't have that repository enabled in my apt config (I really like using synaptic to manage things, primarily because I can refresh, filter new packages, and see what is the latest and greatest out there easily; then simply selecting the package, hitting install, and 'vroom' there it is.) While you can do that with 'yum install' you have to first list the packages, filter on new, then remember the names. It is more convenient when busy to see a package and select it for installation.
Thanks!
/me visits http://apt.bea.ki.se/biorpms/
/me notices that the names of all these packages do not follow the fedora naming guidelines. Humpf. Moreover, there's also a comment about a stuck dependency
I focus on building for Fedora Core 1. Some packages are available for RH8.0 and RH9 as well. Requires freshrpms.net, ATrpms, and Dag repositories. As I depend heavily on these repositories, I will not build for Fedora Core 2 until they do.
This is /precisely/ the kind of blockage I want to help resolve!
Since you just saw my self-intro, you know that I am new to the inside of the sausage factory that is Fedora, though I am not new to Open Source (I started writing the GNU C++ compiler in 1987). If you have any advice on where I should start my campaign--either with Dag Wieers and other foundational sites, the biorpm folks, the mailing list, or whatever--I'd appreciate it. I'd certainly prefer to make my initial application of energy a positive, rather than a negative, experience for all.
Thanks!
M
On Wed, 2004-06-30 at 10:10, Lamar Owen wrote:
On Wednesday 30 June 2004 05:03, Michael Tiemann wrote:
- bring GRASS to Fedora (FreeGIS has been funded to do this)
Excellent. GRASS plus some good GUI tools and the ability to tie in GPS would fulfil the need for a good mapping/tracking suite, even though GRASS is a little over powered for that job, it has all the tools.
- bring in the latest and greatest free bioinformatics sw
There is a bioinformatics repository out there that is pulled in with the ATrpms configuration; http://apt.bea.ki.se/biorpms/ is the location. R is one of the packages there. As I don't have that repository enabled in my apt config (I really like using synaptic to manage things, primarily because I can refresh, filter new packages, and see what is the latest and greatest out there easily; then simply selecting the package, hitting install, and 'vroom' there it is.) While you can do that with 'yum install' you have to first list the packages, filter on new, then remember the names. It is more convenient when busy to see a package and select it for installation. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
On Wed, Jun 30, 2004 at 10:26:25AM -0400, Michael Tiemann wrote:
/me visits http://apt.bea.ki.se/biorpms/
I have Cced the maintainer, Bent Terp (I think he is not a list member, so please keep him in the Cc for related posts).
Moreover, there's also a comment about a stuck dependency
I focus on building for Fedora Core 1. Some packages are available for RH8.0 and RH9 as well. Requires freshrpms.net, ATrpms, and Dag repositories. As I depend heavily on these repositories, I will not build for Fedora Core 2 until they do.This is /precisely/ the kind of blockage I want to help resolve!
That's outdated, biorpms has an FC2 component since some time now!
We have also contemplated consolidating natural science releated rpms in an "scirpm" repo or the like, but that idea did not fruit, unfortunately.
On Wed, Jun 30, 2004 at 09:58:16PM +0200, Giandomenico De Tullio wrote:
On 30/06/2004 17:25:40, Axel Thimm wrote: Deo gratia Axel ... you have updated your pgpkey validity ^.^
Yes, more than half a year ago, a couple of weeks before the validity expired, like I do each year :)
;)
i had lost the hope ;)
I think you probably just had your first key refresh since 7 months at least ;)
See man gpg option --refresh-keys :)
On Wednesday 30 June 2004 10:26, Michael Tiemann wrote:
/me notices that the names of all these packages do not follow the fedora naming guidelines. Humpf. Moreover, there's also a comment about a stuck dependency ATrpms, and Dag repositories. As I depend heavily on these repositories, I will not build for Fedora Core 2 until they do.
This is /precisely/ the kind of blockage I want to help resolve!
Good luck. :-)
I just noticed the listing in my repository config; just passing along information. I personally would love a 'scirpms' repository, and would love to see IRAF and AIPS++ in the stack... :-)
Since you just saw my self-intro, you know that I am new to the inside of the sausage factory that is Fedora, though I am not new to Open Source (I started writing the GNU C++ compiler in 1987). If you have any advice on where I should start my campaign--either with Dag Wieers and other foundational sites, the biorpm folks, the mailing list, or whatever--I'd appreciate it. I'd certainly prefer to make my initial application of energy a positive, rather than a negative, experience for all.
Your name is familiar to me, from a while back. Axel Thimm is on list here, and he has cc:ed the appropriate person. I'll just step back out of the way, and let the dialog continue.... - Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
On Wed, 2004-06-30 at 12:03, Michael Tiemann wrote:
- revive blender3d for FC2/Extras (was in FC1/Extras)
Some work in progress here, but quiet for over a month: https://bugzilla.fedora.us/show_bug.cgi?id=1260
On Wed, 2004-06-30 at 05:03, Michael Tiemann wrote:
- see if the new eGroupware stuff is ready for FC2/Extras
I'm not trying to advocate one over another, but I'm more familiar with openGroupware.org which seems to me to be relatively mature, although new development seems limited. Is anyone familiar enough with both to compare and contrast them, or are they aimed at completely different audiences? (Looking at the websites, it seems like they do a lot of the same things.)
Howard Holm wrote:
On Wed, 2004-06-30 at 05:03, Michael Tiemann wrote:
- see if the new eGroupware stuff is ready for FC2/Extras
I'm not trying to advocate one over another, but I'm more familiar with openGroupware.org which seems to me to be relatively mature, although new development seems limited. Is anyone familiar enough with both to compare and contrast them, or are they aimed at completely different audiences? (Looking at the websites, it seems like they do a lot of the same things.)
See this thread on fedora-desktop-list:
http://www.redhat.com/archives/fedora-desktop-list/2004-May/msg00060.html
Richard
devel@lists.stg.fedoraproject.org
-
Axel Thimm -
Florian La Roche -
Giandomenico De Tullio -
Gérard Milmeister -
Howard Holm -
John Hearns -
Lamar Owen -
Michael Schwendt -
Michael Tiemann -
Paul Nasrat -
Richard Li -
Rudi Chiarito -
Ville Skyttä