Hi Michael,

Well, activity log disagrees: https://bugzilla.redhat.com/bugzilla/show_activity.cgi?id=101563

I noticed the adding of this bug to 100644, but it's just the actual maintainer hasn't reacted to it.

Concerning missing buildrequires, it would be nice if someone from Red Hat could post a short comment on how clean their build environment is and whether they are interested in learning about src.rpm build problems.

These kind of requirements get fixed and are considered bugs afaict. I got a little list concerning missing (build)requirements in 7.3 of which about 3/4 have been fixed.

Maybe flex is an essential component in Red Hat's build environment?

If that were so some package my current setup should require it. I've been rebuilding a significant part of 7.3 with a propoliced gcc-2.95-3 lately and usually packages Requires what they require.

There are other packages with incomplete build requirements which fail to build in a clean environment.

Can you name a few?

Bye, Leonard.

-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.

On Sun, 24 Aug 2003, Michael Schwendt wrote:

...

I noticed the adding of this bug to 100644, but it's just the actual maintainer hasn't reacted to it.

Would that change a thing? No. Just imagine the maintainer wastes a few seconds on a "will be fixed in next release" comment, but then forgets to fix it actually. ;) Missing buildreqs run at very low priority unless a src.rpm breaks in Red Hat's own build environment. The maintainer will [hopefully] add a comment or close the report when the bug is fixed in the spec file actually.

It's also possible that a given maintainer might be on vacation. Also, adding new dependancies often takes more time than just adding a line to a spec file. Personally, any time someone requests a new BuildRequires, Requires, or somesuch dependancy on one of my packages, unless the dependancy is extremely obvious that it is needed and is missing, I investigate what specifically in the package does really require that, as I hate to add unneeded dependancies to a package. Occasionally, the real dependancy isn't the one the package the bug is reported against, but rather the bug is a missing dependancy in one of the other packages which the package requires that the bug is reported against.

It might seem a bit tedious to investigate these things to that level, but unneeded dependancies only complicate packaging and make the minimal distro install size increase. Also, in the case of package1 requires package2 which is missing dependancy A, if you add the dependancy to package1 without investigation, any other package in the distribution that requires package2 will end up missing that dependancy as well. It's always best to search for the proper dependancy unless it is drop dead obvious. ;o)

...

...

Maybe flex is an essential component in Red Hat's build environment?

If that were so some package my current setup should require it.

Wrong assumption. gcc-c++/make/gettext, for instance, are no package build requirements either. So, basically every C++ application would not build with your setup. But of course, you have installed those packages deliberately. Or because they belong to the development group.

Yes, some packages like gcc, etc. are obvious to not require BuildRequires. There are others too, however it never hurts to report one of these in case it is considered a legitimate bug. Perhaps we should have a "development-base" package, that Requires all of these things, just to ensure all truly required packages are installed in development installs? That might be a good suggestion.

...

...

There are other packages with incomplete build requirements which fail to build in a clean environment.

Can you name a few?

Sorry, no space left in my brain for such a list. Occasionally you stumble upon such packages, provided that your build environment is really pretty close to "clean" (with regard to -devel packages and lots of tools). And Red Hat seem to have had no problems building those packages, because their build environment is different from "just rpm-build and dependencies".

Correct. If I understand correctly, our buildsystem installs a certain number of hard coded applications considered minimum requirements for doing development. The C compiler, C++ compiler, and whatnot are all included. A lot of -devel packages I believe are also included. The rest of the -devel packages get included by a particular src.rpm listing it as a BuildRequires.

So for example, if I try to compile XFree86, and Glide3-devel isn't installed on a buildmachine in a buildroot, the buildsystem parses that XFree86 needs Glide3 and Glide3-devel to compile automatically, and it installs those packages first, prior to initiating the build. If that package (Glide3, and Glide3-devel) have dependancies that are also not installed, the buildsystem will continue to install all of the required dependancies until the build can proceed.

So, generally our build systems always have all software installed to compile anything in the OS, and if not, they will automatically install a given component when it is needed by a given build (assuming the package exists). If a package doesn't exist and is a buildrequire, then the build will fail, and we go running to find the problem and fix it. ;o)

On Sun, 24 Aug 2003, Leonard den Ottolander wrote:

...

Also, adding new dependancies often takes more time than just adding a line to a spec file.

...

It might seem a bit tedious to investigate these things to that level, but unneeded dependancies only complicate packaging and make the minimal distro install size increase.

I fully agree with this. I can see this might be the case with the flex requirement.

No need to make smart crack remarks. The point I'm trying to make, is that every time you add a dependancy to a package, you also add dependancies to all of that packages dependancies. As a simple example, make some package have even one small simple thing that requires the package XFree86 to be installed. Now, for correctness, you need to add a "Requires: XFree86" to that package. At this point, by installing the package, you now have dragged in XFree86, and all of it's dependancies, and every single one of every one of those packages dependancies on down the line.

One example of this is midnight commander as someone pointed out. mc requires XFree86-libs. Someone out there might want to have mc installed on a system completely devoid of X, and will never be using mc inside X on that system. They might not even have a mouse attached to the system. Nonetheless, they have no choice but to install XFree86-libs and all of it's dependancies if they want to install mc.

An even worse example is some small simple application you can use in text mode requiring something in gnome. That drags in GNOME, all of XFree86, and half the distribution.

The only way that these types of drag-in-the-whole-OS traps can be prevented, is by adding true dependancies to the PROPER packages after ensuring that they are true dependancies, and that the dependancy shouldn't go at a lower level (in an already dependant package). Another thing needed would be to have as many things that end up being dependancy targets split out of other packages if not doing so would cause a whackload of software to get dependancy-domino-effect installed to meet a dep (like the mc case above). The downside of increased package splitup however is increased package maintenance and complexity, and quite often end user confusion. The downside of over specified dependancies, or deps specified at too high a level when they should be at a lower level, or the dependancy domino effect, is that it is hard to make a minimal OS installation truely "small".

...

Perhaps we should have a "development-base" package, that Requires all of these things, just to ensure all truly required packages are installed in development installs? That might be a good suggestion.

Indeed probably a good idea. I usually start out with a rather minimal installation and add packages as needed. This is how I come across these missing requirements in the first place. Even after using Linux for many years some things that might be obvious to some/many aren't obvious to me. Probably because I haven't been doing a lot of c development until lately.

With something like up2date handling auto-installation of the dependancy chain for a given package, that works fairly well. One will occasionally find dependancy failures simply due to a combination of packages being installed in a random minimal install that have never been installed in that manner before, or the problem never reported. So by all means, when you spot dependancy errors, track them down and report them. As I say above though, if for example some package seemingly wont work without 'foo' installed, try to find out if the package itself really does use foo, or if instead some application that the package uses that is part of an existing dep is missing the dep on foo.

yes, it's a PITA, but it does do 2 good things:

1) It minimizes over specified dependancies, and thus helps lower installation sizes, while still solving the problem properly

2) It puts the dependancy exactly where it really should be instead of one notch above that. that ensures that any other higher level packages in the dependancy heirarchy, will also have their deps met automatically because you fixed the problem at the proper spot, thus fixing it for all packages at once that are dependant on something.

If this sounds confusing, I apologize as it is hard to word in a manner that doesn't sound like Abbott and Costello. ;o)

On Sun, 24 Aug 2003, Stephen Smoogen wrote:

...

One example of this is midnight commander as someone pointed out. mc requires XFree86-libs. Someone out there might want to have mc installed on a system completely devoid of X, and will never be using mc inside X on that system. They might not even have a mouse attached to the system. Nonetheless, they have no choice but to install XFree86-libs and all of it's dependancies if they want to install mc.

I think 2 really cool things that the REALLY open development model can do is help organize Bug Triage days and also help point out and fix all these silly dependency chains. Maybe help rewrite spec files that create truly minimal packages that do not pull in extra dependencies.

That would be great. There's a lot of things that lots of us would "like" to do, but never find time to prioritize ourselves because we're too busy with work that is much more mission critical or time related. Having people volunteer to do such things, would be a great thing.

I think 2 really cool things that the REALLY open development model can do is help organize Bug Triage days and also help point out and fix all these silly dependency chains. Maybe help rewrite spec files that create truly minimal packages that do not pull in extra dependencies.

I am just looking at some of the build dependencies. Things get easily out of band. Perl requires dos2unix, elfutils require sharutils etc.

A bit bigger problem is the growing dependencies of libs. pam, openssl, openldap, tcp_wrappers, some GUI libs, kerberous and a couple of addon libs get easily added and the mix seems to get even bigger all the time.

greetings,

Florian La Roche

On Sat, 23 Aug 2003, Michael Schwendt wrote:

...

While I am at it, I reported a simple missing BuildRequires for pam three weeks ago, but I haven't seen any reaction on bugzilla yet (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=101563).

Well, activity log disagrees: https://bugzilla.redhat.com/bugzilla/show_activity.cgi?id=101563

...

Why does it have to take so long just to fix such a simple bug for which a fix is provided? Not that I expect new pam rpms to be released for a single BuildRequires, but a simple "this will be fixed in the next release" would be nice.

Concerning missing buildrequires, it would be nice if someone from Red Hat could post a short comment on how clean their build environment is

It depends on what exactly you mean by "how clean is the build environment". That question could be interpreted in 10 different ways by 10 different people. Can you be more specific?

The Red Hat build machines contain an installation of some version of Red Hat Linux or Red Hat Enterprise Linux (depending on the particular machine and various other factors). That OS is what "hosts" the machine and the version doesn't matter very much. Every build machine has a number of "buildroots" installed on it, which are essentially a complete installation of a particular version of Red Hat Linux or Red Hat Enterprise Linux installed into a subdirectory which builds for that particular operating system version can be done, by chroot'ing into the particular buildroot directory and an rpm build being performed.

The creation of these clean buildroot "chroot jails" is automated by the buildsystem, and populated with a complete set of RPM packages that make up the given OS release the buildroot is for. Any erratum updates released by us are also applied to the buildroot so that all of our software builds are built with the latest updates to the OS.

When developing a new OS release, such as the currently codenamed "Cambridge", a buildroot is instantiated based on the last OS release (in this case Red Hat Linux 9), and all packages built for the developmental release get built in this new developmental buildroot. The buildsystem automatically installs BuildRequires dependancies named in the RPM specfile to ensure that all packages being built have their build time dependancies met.

Since the whole process of creating the buildroots, upgrading packages in the buildroots, and building RPM packages is completely automated, the buildroots and thus the buildsystem is fairly "clean" WRT what versions of what software are installed on a given buildsystem and buildroot at a particular time.

Does this answer your question about how clean our build environment is?

and whether they are interested in learning about src.rpm build problems.

Absolutely.

If there are build problems rebuilding a particular src.rpm, we definitely want to know about them. A lot of problems like this that get reported, get fixed rather quickly.

Some problems that get reported, such as build problems experienced when people use a proprietary C compiler or other tools not provided or supported by Red Hat, we will close as WONTFIX. There are other cases where a reported build time bug might be considered unsupported by us, but the majority of reported bugs of this nature are usually something that we want to know about. If in doubt, report it, and if we disagree, we'll let you know. ;o)

Maybe flex is an essential component in Red Hat's build environment? Similar to gcc/g++/make and a few other tools. There are other packages with incomplete build requirements which fail to build in a clean environment.

flex is definitely something required by the buildsystem at all times. If you discover any RPM packages missing BuildRequires, or missing Requires or other dependancies or conflicts, please report them.

Also note that some dependancies aren't always as they appear at all times. I recently had a bug report that XFree86-xfs required gzip in order to work properly, and that Requires: gzip was missing from the package. After close examination of the XFree86-xfs binaries, shell scripts, etc. I couldn't find anything that used gzip. I assumed that something else used by the XFree86-xfs package was missing a gzip dependancy. After a small amount of troubleshooting, I found the culprit to be ttmkfdir internally calling gzip. The proper dependancy in this case was ttmkfdir needing a "Requires: gzip" and not the XFree86-xfs package.

If possible, when you determine a missing dependancy on a package, be it a compile time, install time, or run time dependancy, please try to pinpoint the exact reason for the dependancy to ensure that the proper package gets fixed. This helps to lower the minimum install requirements, and makes things much more snazzalicious.

;o)

On Sun, 24 Aug 2003, Michael Schwendt wrote:

...

...

Concerning missing buildrequires, it would be nice if someone from Red Hat could post a short comment on how clean their build environment is

It depends on what exactly you mean by "how clean is the build environment". That question could be interpreted in 10 different ways by 10 different people. Can you be more specific?

With "clean build environment" I refer to the amount of what is installed without being a dependency. I mean that every -devel package, every tool which is needed to build a src.rpm would not be found unless it is a buildreq or a dependency of a package which is installed already. Sort of a minimal installation of Red Hat Linux with only rpm-build and its dependencies installed. Every additional package required to build a src.rpm would need to be an explicit BuildRequires in the src.rpm.

That sounds sensible. If you find packages missing such dependancies, please file them in bugzilla.

A less clean environment would have a few core development tools installed always, e.g. compilers, interpreters (such a Perl) or related utilities (make, patch, parser generators), so that they don't need to be listed as buildreqs in a high number of src.rpms. Of course, this could also be done with a new development-core package, like fedora-rpmdevtools does it to pull in some dependencies which are considered essential for a build environment.

Sure. It's nice to fix things where possible, and when someone reports them. It's not something we're likely to modify our buildsystem to install the absolute minimum of software, to try and find every last single buildrequires ourselves anally for though IMHO.

These type of fixes are very trivial and are often things someone will never find in real world usage, generally only via specific testing to locate such minor bugs.

In other words, if someone makes them known, they're worth fixing, but IMHO they're not worth us spending a lot of our own time to track down as they don't really cause problems in general for the majority of users.

Who knows though, maybe someone will modify the beehive buildroot creation code to only install rpm-build and it's dependancies. ;o)

On Sun, 24 Aug 2003, Leonard den Ottolander wrote:

...

These type of fixes are very trivial and are often things someone will never find in real world usage, generally only via specific testing to locate such minor bugs.

Well, obviously they are real world usage examples, because they get found, reported and fixed.

Some are, yes. And some are found by trying installations designed specifically to try and find lurking trivial bugs. Both are fine as I said, feel free to report the bugs. But they're not all things that people will really hit in real world situations where they're not purposefully trying to find them. ;o)

...

In other words, if someone makes them known, they're worth fixing, but IMHO they're not worth us spending a lot of our own time to track down as they don't really cause problems in general for the majority of users.

That I can understand. Like most bugs they get exposed by using the system, not by actively looking for them.

Indeed. There are literally thousands of things we could actively try to search for and fix. It wouldn't be efficient to do so however, and it would use up valueable and limited engineering resources for little gain, when those resources could be allocated elsewhere for bigger-bang-for-the-buck stuff.

That said, we welcome those who want to track down nickel and dime bugs and report them too. Even better with fixes attached. ;o)

For the record, I leave trivial stuff build up for a while, and then go on a "trivial bug fix day" day every now and then when things are NOT very busy. That way I can fix 5, 10, 20, etc. trivial bugs all at once quickly and be done with them, and not be doing it when I have to rush to meet a deadline or cram important stuff into builds to meet a tree freeze or something.

I assume others do that too, which also helps explain why trivial things don't necessarily get fixed ASAP. It's more efficient to fix a whackload at once when it's convenenient and when pressing matters aren't on the table.

On Sun, 24 Aug 2003, Joel Young wrote:

...

That sounds sensible. If you find packages missing such dependancies, please file them in bugzilla.

As someone who maintained a 460 package rpm set up providing gnome and kde and a lot of other stuff install for Solaris using packages drawn from redhat, mandrake, pld, suse, ximian, I found the use of build tools in packages to be highly frustrating. Package builders routinely hard coded paths to external programs or just let them default to whatever one was first in path. This creates chaos on a solaris system if a non gnu version is found for some esoteric build requirement. I ended up creating/customizing a large set of macros allowing these to be specified explicitly. e.g.

%__patch /pro/gnome/bin/patch %__perl /pro/gnome/bin/perl %__pgp %{_pgpbin} %__rm /pro/gnome/bin/rm %__rsh /bin/rsh %__sed /pro/gnome/bin/sed %__ssh /usr/local/bin/ssh %__lex /pro/gnome/bin/flex

included from basedir/lib/rpm/macros

The frustrating thing was even for redhat packages, these macros provided in the redhat provided rpm package weren't used religiously in redhat spec files.

Because we're developing Red Hat Linux on Red Hat Linux FOR Red Hat Linux, and we're testing those packages on Red Hat Linux only. Such macros are almost never useful in Linux OS's themselves, and they add a large amount of complicated looking ugliness to spec files.

While this may inconvenience a solaris user trying to compile one of my src.rpms on solaris, um... sorry, but I'm not trying to make RPM packages that build on solaris. You'll be very hard pressed to find rpm packages in any distribution that compile without modification on non-Linux systems.

You'll also be unlikely to find Solaris packages that work without modification on Linux.

There's no incentive to do extra work like that when it slows down development, and gives you zero benefit and you have zero way of testing it, and end up with an ugly looking spec file that is mostly unreadable.

That is why.

Anytime a spec developer calls an external routine, they should consider creating a macro in lib/rpm/macros if it doesn't exist already. If he decides not to create one, he should consider defining a macro a the top of his package and also having a build dependency.

Sorry for soapbox. Just venting an old frustration. Since I no longer am no longer maintaining this mass of .spec files, it isn't so important to me any more :-)

No, by all means, feel free to vent your frustrations. Just realize that there isn't any incentive or real benefits to developers of any Linux distribution (or external packagers) in trying to make their packages build on 10000 operating systems they don't have access to.

Does XFree86.spec compile on Solaris/sparc? No idea. Don't care, and I'd reject/delete any patch sent to me that made it actually work as it would be non-useful to me as a developer, non useful to Red Hat, and non useful to our users.

I will however bet that it is easier for a Solaris RPM packager dude to take my src.rpm and free of cost to them, be able to modify it to build on solaris. I'll even bet that my work would have saved them countless hours of time, and that they'll be thankful they had something to start with instead of writing one from scratch. Ditto for other packages. ;o)

You'll be hard pressed to find many developers out there who favour making their packages unreadable for other OS's IMHO. It's often hard enough to just make a single src.rpm package build on more than one Linux distribution.

But I digress...

On Sun, 24 Aug 2003, Joel Young wrote:

...

Such macros are almost never useful in Linux OS's themselves, and they add a large amount of complicated looking ugliness to spec files.

%{__lex} is uglier than /usr/bin/flex ?

Yes, it is. But I wouldn't use either. I'd use "flex" as it is in the path.

Do you ever ever ever test rpms with alternate roots? Suppose the flex you wanted to use for the build wasn't in the default location, but instead in your alternate build root? Wouldn't it be nice to not have a custom spec?

Locally, my packages are built for testing purposes and development in a custom RPM configuration downloadable from my ftp "hacks" dir on people.redhat.com. It basically builds everything under ~/rpmbuild

In the Red Hat buildsystem, things are built in chrooted buildroots, also with customized rpm configuration, some of it via macro files and some via commandline options IIRC.

We test what we plan on shipping. We don't test if things compile on Solaris or any other OS, nor do we care, or have reason to care.

...

While this may inconvenience a solaris user trying to compile one of my src.rpms on solaris, um... sorry, but I'm not trying to make RPM packages that build on solaris.

Agreed 100% for redhat developers.

Then we agree.

...

You'll be very hard pressed to find rpm packages in any distribution that compile without modification on non-Linux systems.

You might be surprised. Perhaps 30 percent build with no modification, most with trivial modification.

Perhaps via luck at best. Hardly due to people going out of their way to make them build like that.

...

There's no incentive to do extra work like that when it slows down development, and gives you zero benefit and you have zero way of testing it, and end up with an ugly looking spec file that is mostly unreadable.

That is why.

Then why did redhat include all of the default %{__xxxx} macros in the first place?

To allow people who wanted those features the ability to use them, in their OWN rpm packages. ie: 3rd party software developers/packagers who wanted those features for their own software.

Why did they make relocatable packages?

Ditto. 3rd party software developers/packagers who wanted those features for their own software.

Why are the things like sysconfdir etc. configurable? Because it was and is useful to redhat I would suppose?

Exactly. Those are defined via macros so that when you're using a buildroot, your packages get installed into the fake buildroot (really misnamed "installroot") aka. RPM_BUILD_ROOT, instead of overwriting files on your actual running operating system during %install.

When you use %configure, it gets passed the values of all of those variables automatically, so that the autoconfized package installs to RPM_BUILD_ROOT not /

And I would also suppose that having the discipline of using them makes things easier internally to redhat in the long run? Just supposition on my part tho.

I don't see the point you're trying to make here. RPM has tonnes of features. Some were added by Red Hat because they enhanced rpm in ways that make creating and maintaining RPM packages easier, some enhancements were contributed by other Linux vendors, some enhancements were contributed by users of other operating systems. RPM, while used in Red Hat Linux, and initially created by Red Hat, is a tool which is portable to many operating systems, and used by developers of many operating systems to package software for those operating systems.

While RPM "the tool" is portable, that doesn't mean that every developer out there in the wild, nor every developer of a given operating system should spend half their time trying to make sure their actual RPM packages compile and run on 10000 different OS's.

Many of the features added to RPM were for the benefit of others who wanted those features for other OS's, not for Red Hat to personally use in Red Hat Linux, or even care about. IMHO.

...

No, by all means, feel free to vent your frustrations. Just realize that there isn't any incentive or real benefits to developers of any Linux distribution (or external packagers) in trying to make their packages build on 10000 operating systems they don't have access to.

I see benefit at least to external packagers. External packagers presumably would like their packages to build easily on at least multiple rpm based linux distros. The more they use the spec file macro system, the easier that is.

By all means, feel free to create src.rpm packages that compile and install on every operating system to which RPM is available for. It's all open source. Feel free to spend as much time as you like doing this work, and feel free to distribute the results of your labours via ftp/http/apt/yum/etc. to as many people as you like, running as many operating systems as you like.

As far as I'm concerned personally for any RPM package I maintain inside or outside Red Hat Linux, my goal is to make a given package compile and install and work properly on Red Hat Linux. I don't care if the package compiles or installs on any other Linux distribution, or if it compiles or installs on any other operating system. Life is short, and my priorities are getting more work done that is personally useful to me, to Red Hat, and to Red Hat users. I really don't care if my packages ever work on Solaris to be honest, and I doubt you'll find any large percentage of RPM packagers out there who feel differently.

...

I will however bet that it is easier for a Solaris RPM packager dude to take my src.rpm and free of cost to them, be able to modify it to build on solaris. I'll even bet that my work would have saved them countless hours of time, and that they'll be thankful they had something to start with instead of writing one from scratch. Ditto for other packages. ;o)

Guaranteed :-) Maybe thousands of hours saved across 460 packages :-) And you know, redhat and polish linux packages were by far the easiest to port because their spec files had the most discipline.

There you go.

I tried to configure a modem using the Network Configuration window (neat) and it failed. I'm getting an error 38 when neat tries to activate the connection with ppp-watch.

It seems to not like the new feature of using the provider name as the network-script. For example, it called my ifcfg file /etc/sysconfig/network-scripts/ifcfg-CenturyTel. When I ran the Internet Connection Wizard again, but called my provider "ppp0" it created the file that I was used to seeing (ifcfg-ppp0) and worked fine. (I'm using redhat-config-network-tui-1.3.1-1.)

bugzilla?

-- Chris Negus

On Sat, Aug 30, 2003 at 09:25:20PM -0300, Thiago Vinhas de Moraes wrote:

Hi!

After yesterday's latest updates from rawhide, I don't know why the file /etc/X11/dm/Sessions/kde.desktop was removed, and there was no KDE option at gdm.

I've put the file in the right place, and it worked again.

What package owns that file on your system? I only have a script called "KDE"

(Not running rawhide on this machine, granted)

Havoc

On Sun, Aug 31, 2003 at 07:45:21AM -0300, Thiago Vinhas de Moraes wrote:

I guess it should be gdm. I'm running the latest rawhide updates from RHN, and the package is gdm-2.4.2.102-1.

Everything works fine now, but I had to manually duplicate the /etc/X11/dm/Sessions/gnome.desktop as /etc/X11/dm/Sessions/kde.desktop changing the GNOME references to KDE, and the Exec= from gnome-session to kde.

It looks like kde.desktop is now in kdebase-3.1.3-7

Havoc

Hi Mike,

If there are build problems rebuilding a particular src.rpm, we definitely want to know about them. A lot of problems like this that get reported, get fixed rather quickly.

By browsing bugzilla last night I noticed this indeed seems to be the case. I noticed various requirement bugs fixed within two weeks. This is also what I had expected, that's why I was surprised not to hear anything in 3 weeks time. Guess I forgot it is vacation time.

Bye, Leonard.

-- How clean is a war when you shoot around nukelar waste? Stop the use of depleted uranium ammo! End all weapons of mass destruction.

On Sun, 2003-08-24 at 17:54, Elliot Lee wrote:

All the packages in rawhide that weren't signed with the beta key should now be signed with a 'rawhide' key that just indicates that the package has been through the Red Hat buildsystem. Tomorrow, you'll find out why. :)

Is that a hint that beta 2 will be out tomorrow? ;-)

Regards, Jim H