From twaugh at redhat.com Tue Mar 1 09:35:58 2005
From: twaugh at redhat.com (Tim Waugh)
Date: Tue, 1 Mar 2005 09:35:58 +0000
Subject: Saving space: drop Omni?
In-Reply-To: <20050228210155.GE10778@nostromo.devel.redhat.com>
References: <20050228093444.GL3626@redhat.com>
<20050228210155.GE10778@nostromo.devel.redhat.com>
Message-ID: <20050301093558.GN3626@redhat.com>
On Mon, Feb 28, 2005 at 04:01:55PM -0500, Bill Nottingham wrote:
> Tim Waugh (twaugh at redhat.com) said:
> > All the recent talk of saving space on CDs reminded me of a suggestion
> > from a while back.
> >
> > Should we drop Omni? Does anyone actually use it successfully with
> > their printer?
>
> I have a sample of one printer that doesn't use Omni. :)
>
> Is there some way to drill out a list of what printers default to Omni?
grep -l 'omni.*' /usr/share/foomatic/db/source/printer/*
But the trouble with that is that you'll get the list of printers that
Omni can drive, more or less. There is duplication.
For instance, HP-LaserJet_4P_4MP will be in the list, but
HP-LaserJet_4P defaults to hpijs.
Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From alan at redhat.com Tue Mar 1 13:49:05 2005
From: alan at redhat.com (Alan Cox)
Date: Tue, 1 Mar 2005 08:49:05 -0500
Subject: Summary of Dropped Packages
In-Reply-To: <20050224185516.GA2983@devserv.devel.redhat.com>
References: <80d7e409050223154464743b99@mail.gmail.com>
<20050224041924.GA5236@nostromo.devel.redhat.com>
<20050224043750.GB5490@nostromo.devel.redhat.com>
<1109231991.4631.7.camel@localhost.localdomain>
<20050224081436.GA6566@dudweiler.stuttgart.redhat.com>
<1109233259.10915.70.camel@cutter>
<1109233269.4631.12.camel@localhost.localdomain>
<20050224101133.4341fbd6@python2>
<1109251244.8440.26.camel@localhost.localdomain>
<20050224185516.GA2983@devserv.devel.redhat.com>
Message-ID: <20050301134905.GC7968@devserv.devel.redhat.com>
On Thu, Feb 24, 2005 at 01:55:16PM -0500, Jeff Garzik wrote:
> Let me propose a wild suggestion:
>
> Increase to 5 CDs rather than dropping packages others have expressed
> should stay (xfce, exim).
>
> Revisist in FC5, when we can do multiple repositories.
I believe this to be the right choice also, both as a mirror site operator
and as a developer.
From laroche at redhat.com Tue Mar 1 14:04:17 2005
From: laroche at redhat.com (Florian La Roche)
Date: Tue, 1 Mar 2005 15:04:17 +0100
Subject: Summary of Dropped Packages
In-Reply-To: <20050301134905.GC7968@devserv.devel.redhat.com>
References: <20050224041924.GA5236@nostromo.devel.redhat.com>
<20050224043750.GB5490@nostromo.devel.redhat.com>
<1109231991.4631.7.camel@localhost.localdomain>
<20050224081436.GA6566@dudweiler.stuttgart.redhat.com>
<1109233259.10915.70.camel@cutter>
<1109233269.4631.12.camel@localhost.localdomain>
<20050224101133.4341fbd6@python2>
<1109251244.8440.26.camel@localhost.localdomain>
<20050224185516.GA2983@devserv.devel.redhat.com>
<20050301134905.GC7968@devserv.devel.redhat.com>
Message-ID: <20050301140417.GB5541@dudweiler.stuttgart.redhat.com>
On Tue, Mar 01, 2005 at 08:49:05AM -0500, Alan Cox wrote:
> On Thu, Feb 24, 2005 at 01:55:16PM -0500, Jeff Garzik wrote:
> > Let me propose a wild suggestion:
> >
> > Increase to 5 CDs rather than dropping packages others have expressed
> > should stay (xfce, exim).
> >
> > Revisist in FC5, when we can do multiple repositories.
>
> I believe this to be the right choice also, both as a mirror site operator
> and as a developer.
ACK, too. Both seem to be important enough.
greetings,
Florian La Roche
From dmalcolm at redhat.com Tue Mar 1 19:42:44 2005
From: dmalcolm at redhat.com (David Malcolm)
Date: Tue, 01 Mar 2005 14:42:44 -0500
Subject: GConf schema packaging guidelines
Message-ID: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
How should we be dealing with GConf schema in spec files?
Looking over some existing spec files, I see things like this:
SCHEMAS="clock.schemas fish.schemas pager.schemas panel-compatibility.schemas panel-general.schemas panel-global.schemas panel-object.schemas panel-toplevel.schemas tasklist.schemas window-list.schemas workspace-switcher.schemas"
for S in $SCHEMAS; do
gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/$S > /dev/null
done
(from the gnome-panel spec file's "inst" section)
Why is this done here?
Can we have an RPM macro instead?
Some spec files try to uninstall the schema e.g. from
evolution-connector:
%preun
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-uninstall-rule \
%{_sysconfdir}/gconf/schemas/apps_evolution_exchange.schemas >/dev/null || :
Is this recommended best-practise?
I'll update http://fedoraproject.org/wiki/PackagingGuidelines once I get
a good answer to this.
Dave
From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 1 19:48:33 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Tue, 1 Mar 2005 20:48:33 +0100
Subject: GConf schema packaging guidelines
In-Reply-To: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
References: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
Message-ID: <20050301204833.41a56ac6@python2>
David Malcolm wrote :
> How should we be dealing with GConf schema in spec files?
In addition to the scriplets you mention, there is also the disabling of
the schema installation during the build, which can be done either by a
configure option, or by an env var export before the make install stage.
Dunno which one should be common practise as I often see both been
redundantly being included. I personally prefer the configure option.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3.radeon
Load : 0.79 0.83 0.46
From markmc at redhat.com Wed Mar 2 08:59:48 2005
From: markmc at redhat.com (Mark McLoughlin)
Date: Wed, 02 Mar 2005 08:59:48 +0000
Subject: GConf schema packaging guidelines
In-Reply-To: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
References: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
Message-ID: <1109753988.4120.9.camel@blaa>
Hi Dave,
On Tue, 2005-03-01 at 14:42 -0500, David Malcolm wrote:
> How should we be dealing with GConf schema in spec files?
>
> Looking over some existing spec files, I see things like this:
> SCHEMAS="clock.schemas fish.schemas pager.schemas panel-compatibility.schemas panel-general.schemas panel-global.schemas panel-object.schemas panel-toplevel.schemas tasklist.schemas window-list.schemas workspace-switcher.schemas"
> for S in $SCHEMAS; do
> gconftool-2 --makefile-install-rule %{_sysconfdir}/gconf/schemas/$S > /dev/null
> done
>
> (from the gnome-panel spec file's "inst" section)
>
> Why is this done here?
This is in %post and needs to be there since you don't want to package
the %gconf.xml files that --makefile-install creates
in /etc/gconf/gconf.xml.defaults - those files are the aggregate of what
(possibly multiple) packages install.
So, in %post, you've no way (that I know of) to know which .schemas
installed belong to this package - hence the hardcoded list of .schemas
files.
> Can we have an RPM macro instead?
Dunno, the only thing that doesn't look like its generic is the list
of .schemas files.
> Some spec files try to uninstall the schema e.g. from
> evolution-connector:
> %preun
> export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
> gconftool-2 --makefile-uninstall-rule \
> %{_sysconfdir}/gconf/schemas/apps_evolution_exchange.schemas >/dev/null || :
>
> Is this recommended best-practise?
Yeah, all packages should do this and we should probably also be doing
killall -HUP gconfd-2 or something so the daemons see the new schemas.
Cheers,
Mark.
From markmc at redhat.com Wed Mar 2 09:02:59 2005
From: markmc at redhat.com (Mark McLoughlin)
Date: Wed, 02 Mar 2005 09:02:59 +0000
Subject: GConf schema packaging guidelines
In-Reply-To: <20050301204833.41a56ac6@python2>
References: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
<20050301204833.41a56ac6@python2>
Message-ID: <1109754179.4120.11.camel@blaa>
On Tue, 2005-03-01 at 20:48 +0100, Matthias Saou wrote:
> David Malcolm wrote :
>
> > How should we be dealing with GConf schema in spec files?
>
> In addition to the scriplets you mention, there is also the disabling of
> the schema installation during the build, which can be done either by a
> configure option, or by an env var export before the make install stage.
> Dunno which one should be common practise as I often see both been
> redundantly being included. I personally prefer the configure option.
The configure option is slightly less likely to work because it
requires packages to add AM_GCONF_SOURCE_2 to configure whereas the
GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL env var is handled by gconftool
itself.
Cheers,
Mark.
From skvidal at phy.duke.edu Thu Mar 3 17:10:13 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 03 Mar 2005 12:10:13 -0500
Subject: People needing sponsors
Message-ID: <1109869813.13736.6.camel@opus.phy.duke.edu>
Hey Folks,
Here is the list of people needing sponsors for cvs access to extras.
If anyone wants to pick one of them up - then email them and remove them
from the wiki page. Thanks.
http://fedoraproject.org/wiki/Extras/SponsorsNeeded
-sv
From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 3 18:39:12 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Thu, 3 Mar 2005 19:39:12 +0100
Subject: rawhide/fc4 extras builds
In-Reply-To: <1109473002.27384.129.camel@cutter>
References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com>
<20050226154652.21d09ff4.bugs.michael@gmx.net>
<1109434328.27384.68.camel@cutter>
<20050226172028.03b28d62.bugs.michael@gmx.net>
<1109435966.27384.78.camel@cutter>
<20050226174400.30d1e828.bugs.michael@gmx.net>
<1109437075.27384.83.camel@cutter>
<20050226181950.683f7de3.bugs.michael@gmx.net>
<1109439489.27384.97.camel@cutter>
<20050226192830.36b8f59e.bugs.michael@gmx.net>
<1109467015.27384.123.camel@cutter>
<20050227025859.407b1405.bugs.michael@gmx.net>
<1109473002.27384.129.camel@cutter>
Message-ID: <20050303193912.5d5b0c6a@python2>
seth vidal wrote :
> > My plan would have been this:
> >
> > 1. bump release of every package in "devel"
> > 2. make sure that every update of FC-3 and older either loses
> > RPM version comparison compared with "devel" or is also imported
> > into "devel" tree with a higher release number
> >
> > Then we would be ready for a mass-rebuild any time.
>
> Let's ask if anyone is bothered by you doing #1 with your script.
> Anyone got a problem with that?
>
> We can do #2 iteratively post-mass-rebuild. I bet it will only be a
> handful of items anyway.
>
> then on with the rebuild-foo.
But what if we start using the ".fc4" release tag? Then no more mass
release incrementing is required.
> the only item we might want to delay a tiny bit on is gcc->gcc4.
This has now happened, yeah! :-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.770_FC3
Load : 1.72 1.10 0.68
From skvidal at phy.duke.edu Thu Mar 3 18:48:45 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 03 Mar 2005 13:48:45 -0500
Subject: rawhide/fc4 extras builds
In-Reply-To: <20050303193912.5d5b0c6a@python2>
References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com>
<20050226154652.21d09ff4.bugs.michael@gmx.net>
<1109434328.27384.68.camel@cutter>
<20050226172028.03b28d62.bugs.michael@gmx.net>
<1109435966.27384.78.camel@cutter>
<20050226174400.30d1e828.bugs.michael@gmx.net>
<1109437075.27384.83.camel@cutter>
<20050226181950.683f7de3.bugs.michael@gmx.net>
<1109439489.27384.97.camel@cutter>
<20050226192830.36b8f59e.bugs.michael@gmx.net>
<1109467015.27384.123.camel@cutter>
<20050227025859.407b1405.bugs.michael@gmx.net>
<1109473002.27384.129.camel@cutter> <20050303193912.5d5b0c6a@python2>
Message-ID: <1109875725.13736.13.camel@opus.phy.duke.edu>
> But what if we start using the ".fc4" release tag? Then no more mass
> release incrementing is required.
let's not do that if we can avoid it.
>
> > the only item we might want to delay a tiny bit on is gcc->gcc4.
>
> This has now happened, yeah! :-)
>
I can't install rawhide right now :)
-sv
From dwmw2 at infradead.org Thu Mar 3 21:29:06 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 03 Mar 2005 21:29:06 +0000
Subject: rawhide/fc4 extras builds
In-Reply-To: <20050303193912.5d5b0c6a@python2>
References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com>
<20050226154652.21d09ff4.bugs.michael@gmx.net>
<1109434328.27384.68.camel@cutter>
<20050226172028.03b28d62.bugs.michael@gmx.net>
<1109435966.27384.78.camel@cutter>
<20050226174400.30d1e828.bugs.michael@gmx.net>
<1109437075.27384.83.camel@cutter>
<20050226181950.683f7de3.bugs.michael@gmx.net>
<1109439489.27384.97.camel@cutter>
<20050226192830.36b8f59e.bugs.michael@gmx.net>
<1109467015.27384.123.camel@cutter>
<20050227025859.407b1405.bugs.michael@gmx.net>
<1109473002.27384.129.camel@cutter> <20050303193912.5d5b0c6a@python2>
Message-ID: <1109885346.29792.95.camel@baythorne.infradead.org>
On Thu, 2005-03-03 at 19:39 +0100, Matthias Saou wrote:
> > the only item we might want to delay a tiny bit on is gcc->gcc4.
>
> This has now happened, yeah! :-)
Let's give it a little time to settle -- let Fedora Core be the canary
for gcc4 issues and build Extras once, when the compiler is done.
--
dwmw2
From mharris at redhat.com Fri Mar 4 00:11:29 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 3 Mar 2005 19:11:29 -0500 (EST)
Subject: rawhide/fc4 extras builds
In-Reply-To: <1109885346.29792.95.camel@baythorne.infradead.org>
References: <1109390126.27384.3.camel@cutter> <42204EAC.9010800@redhat.com>
<20050226154652.21d09ff4.bugs.michael@gmx.net>
<1109434328.27384.68.camel@cutter>
<20050226172028.03b28d62.bugs.michael@gmx.net>
<1109435966.27384.78.camel@cutter>
<20050226174400.30d1e828.bugs.michael@gmx.net>
<1109437075.27384.83.camel@cutter>
<20050226181950.683f7de3.bugs.michael@gmx.net>
<1109439489.27384.97.camel@cutter>
<20050226192830.36b8f59e.bugs.michael@gmx.net>
<1109467015.27384.123.camel@cutter>
<20050227025859.407b1405.bugs.michael@gmx.net>
<1109473002.27384.129.camel@cutter>
<20050303193912.5d5b0c6a@python2>
<1109885346.29792.95.camel@baythorne.infradead.org>
Message-ID:
On Thu, 3 Mar 2005, David Woodhouse wrote:
>On Thu, 2005-03-03 at 19:39 +0100, Matthias Saou wrote:
>> > the only item we might want to delay a tiny bit on is gcc->gcc4.
>>
>> This has now happened, yeah! :-)
>
>Let's give it a little time to settle -- let Fedora Core be the canary
>for gcc4 issues and build Extras once, when the compiler is done.
I read that as "conary" for a minute, and thought you were
suggesting we use conary for FC4. ;)
Might not be a bad idea even. ;o)
--
Mike A. Harris, Systems Engineer - X11 Development team, Red Hat Canada, Ltd.
IT executives rate Red Hat #1 for value: http://www.redhat.com/promo/vendor
From notting at redhat.com Fri Mar 4 06:42:35 2005
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 4 Mar 2005 01:42:35 -0500
Subject: picking the best option from similar packages
Message-ID: <20050304064235.GB5707@nostromo.devel.redhat.com>
Looking at the distro, there are some cases where we have duplicate
functionality where it's not immediately obvious (at least, to
me) which is the right thing to be Core and which might be better
as an Extra.
The ones right now are:
a2ps -vs- enscript
These obviously have a large overlap.
netpbm -vs- ImageMagick
Right now, both of these are in the dependency chain, so it may
be a moot point for now. But picking one seems to be the way to go.
Bill
From skvidal at phy.duke.edu Fri Mar 4 06:54:36 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 04 Mar 2005 01:54:36 -0500
Subject: picking the best option from similar packages
In-Reply-To: <20050304064235.GB5707@nostromo.devel.redhat.com>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
Message-ID: <1109919276.23585.48.camel@cutter>
> The ones right now are:
>
> a2ps -vs- enscript
well from the standpoint of code actually being more actively
maintained.
a2ps was last updated 2 yrs ago, according to the website.
enscript was last updated 5 yrs ago.
It might make sense to keep the one in core with the more active
maintenance upstream.
I like enscript better but .
-sv
From skvidal at phy.duke.edu Fri Mar 4 06:55:49 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 04 Mar 2005 01:55:49 -0500
Subject: picking the best option from similar packages
In-Reply-To: <1109919276.23585.48.camel@cutter>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<1109919276.23585.48.camel@cutter>
Message-ID: <1109919349.23585.50.camel@cutter>
On Fri, 2005-03-04 at 01:54 -0500, seth vidal wrote:
> > The ones right now are:
> >
> > a2ps -vs- enscript
>
> well from the standpoint of code actually being more actively
> maintained.
>
> a2ps was last updated 2 yrs ago, according to the website.
> enscript was last updated 5 yrs ago.
okay I typed that backward.
enscript - updated 2 yrs ago
a2ps - updated 5yrs ago.
sorry
so maybe it's best to move a2ps to extras.
-sv
From notting at redhat.com Fri Mar 4 06:54:39 2005
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 4 Mar 2005 01:54:39 -0500
Subject: package functionality - is it a core feature?
Message-ID: <20050304065439.GD5707@nostromo.devel.redhat.com>
Some of the discussion on fedora-devel was about certain Core
packages and whether or not they seemed appropriate for Core as
opposed to Extras. So, collecting more opinions at this point on:
- iptstate
- cscope
- tora
- Emacs addons - mew/ddskk/flim/wl
Do people think that these are core functionality?
Bill
From ville.skytta at iki.fi Fri Mar 4 07:36:06 2005
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Fri, 04 Mar 2005 09:36:06 +0200
Subject: picking the best option from similar packages
In-Reply-To: <1109919349.23585.50.camel@cutter>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<1109919276.23585.48.camel@cutter> <1109919349.23585.50.camel@cutter>
Message-ID: <1109921766.15077.344.camel@bobcat.mine.nu>
On Fri, 2005-03-04 at 01:55 -0500, seth vidal wrote:
> so maybe it's best to move a2ps to extras.
...and update enscript to 1.6.4, that version has some nifty features
that are used eg. by ViewCVS/CVSweb for HTML colorization of various
file formats.
From notting at redhat.com Fri Mar 4 07:42:17 2005
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 4 Mar 2005 02:42:17 -0500
Subject: picking the best option from similar packages
In-Reply-To: <20050304064235.GB5707@nostromo.devel.redhat.com>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
Message-ID: <20050304074217.GA6671@nostromo.devel.redhat.com>
Bill Nottingham (notting at redhat.com) said:
> The ones right now are:
>
> a2ps -vs- enscript
So, attempting to distinguish based on features/support, I decided
to see if they support UTF-8. Ow.
It's sort of sad that to get a reasonable printout of a text file
in UTF-8 I had to open it in gedit first. Or is there some magic
I'm missing out on?
Bill
From pnasrat at redhat.com Fri Mar 4 09:15:16 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Fri, 04 Mar 2005 09:15:16 +0000
Subject: package functionality - is it a core feature?
In-Reply-To: <20050304065439.GD5707@nostromo.devel.redhat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
Message-ID: <1109927716.4072.4.camel@anu.eridu>
On Fri, 2005-03-04 at 01:54 -0500, Bill Nottingham wrote:
>Some of the discussion on fedora-devel was about certain Core
>packages and whether or not they seemed appropriate for Core as
>opposed to Extras. So, collecting more opinions at this point on:
>- tora
>Do people think that these are core functionality?
The only time I've used tora is for linux users who wanted something
like toad, I had to build with oracle support - which the spec allows
for. I imagine most people will be rebuilding with oracle support
anyway, as opposed to using our binary package.
Paul
From mharris at redhat.com Fri Mar 4 10:08:17 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Fri, 4 Mar 2005 05:08:17 -0500 (EST)
Subject: package functionality - is it a core feature?
In-Reply-To: <20050304065439.GD5707@nostromo.devel.redhat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
Message-ID:
On Fri, 4 Mar 2005, Bill Nottingham wrote:
>Some of the discussion on fedora-devel was about certain Core
>packages and whether or not they seemed appropriate for Core as
>opposed to Extras. So, collecting more opinions at this point on:
>
>- iptstate
I think this would be nice in Extras, but I don't see any major
reason to include it in Core.
>- cscope
>- tora
No opinions either way.
>- Emacs addons - mew/ddskk/flim/wl
Unless there are tight integration problems that require them to
be in Core, I'd think they'd be best in Extras no?
--
Mike A. Harris, Systems Engineer - X11 Development team, Red Hat Canada, Ltd.
IT executives rate Red Hat #1 for value: http://www.redhat.com/promo/vendor
From wtogami at redhat.com Fri Mar 4 10:36:20 2005
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 04 Mar 2005 00:36:20 -1000
Subject: package functionality - is it a core feature?
In-Reply-To: <20050304065439.GD5707@nostromo.devel.redhat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
Message-ID: <42283A24.6020301@redhat.com>
Bill Nottingham wrote:
> Some of the discussion on fedora-devel was about certain Core
> packages and whether or not they seemed appropriate for Core as
> opposed to Extras. So, collecting more opinions at this point on:
>
> - iptstate
iptstate is tiny but useful, IMHO.
> - cscope
No opinion.
> - tora
Every time I've tried to figure out tora in the past 3 years, it seemed
to be totally inoperative or horribly bad at doing anything useful with
our open source database. Not to mention it is extremely prone to
crashing. IMHO it isn't too useful for us to ship in either Core or
Extras, especially because we can't build it to interface with Oracle.
> - Emacs addons - mew/ddskk/flim/wl
I am in the complete removal of *emacs* camp.
Warren Togami
wtogami at redhat.com
From fche at redhat.com Fri Mar 4 10:21:04 2005
From: fche at redhat.com (Frank Ch. Eigler)
Date: Fri, 4 Mar 2005 05:21:04 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <20050304065439.GD5707@nostromo.devel.redhat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
Message-ID: <20050304102104.GA16849@redhat.com>
Hi -
On Fri, Mar 04, 2005 at 01:54:39AM -0500, Bill Nottingham wrote:
> [...]
> - cscope
> [...]
> Do people think that these are core functionality?
There being no formal definition of "core", it's hard to know by what
criteria this small (350K), useful (customers requested it, developers
who try it tend to like it), unique (no other tool like it in fedora),
newish (added in FC3) tool might fail to qualify.
- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From twaugh at redhat.com Fri Mar 4 10:29:22 2005
From: twaugh at redhat.com (Tim Waugh)
Date: Fri, 4 Mar 2005 10:29:22 +0000
Subject: picking the best option from similar packages
In-Reply-To: <20050304074217.GA6671@nostromo.devel.redhat.com>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<20050304074217.GA6671@nostromo.devel.redhat.com>
Message-ID: <20050304102922.GF3626@redhat.com>
On Fri, Mar 04, 2005 at 02:42:17AM -0500, Bill Nottingham wrote:
> It's sort of sad that to get a reasonable printout of a text file
> in UTF-8 I had to open it in gedit first. Or is there some magic
> I'm missing out on?
Did you try just printing the text file with lpr? It gets converted
to PostScript (and thence to raster) using CUPS' *own* texttops
program. :-)
Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Mar 4 10:35:33 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Fri, 4 Mar 2005 11:35:33 +0100
Subject: package functionality - is it a core feature?
In-Reply-To: <20050304102104.GA16849@redhat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
<20050304102104.GA16849@redhat.com>
Message-ID: <20050304113533.6da55326@python2>
Frank Ch. Eigler wrote :
> On Fri, Mar 04, 2005 at 01:54:39AM -0500, Bill Nottingham wrote:
> > [...]
> > - cscope
> > [...]
> > Do people think that these are core functionality?
>
> There being no formal definition of "core", it's hard to know by what
> criteria this small (350K), useful (customers requested it, developers
> who try it tend to like it), unique (no other tool like it in fedora),
> newish (added in FC3) tool might fail to qualify.
I tend to agree. I'm also wondering on what set of packages the next RHEL
will based too. Can packages move to Extras when they should be included in
the next RHEL? Meaning... will RHEL also include part of Extras packages?
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.770_FC3
Load : 0.05 0.33 0.35
From otaylor at redhat.com Fri Mar 4 13:20:03 2005
From: otaylor at redhat.com (Owen Taylor)
Date: Fri, 04 Mar 2005 08:20:03 -0500
Subject: picking the best option from similar packages
In-Reply-To: <20050304102922.GF3626@redhat.com>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<20050304074217.GA6671@nostromo.devel.redhat.com>
<20050304102922.GF3626@redhat.com>
Message-ID: <1109942403.8906.2.camel@localhost.localdomain>
On Fri, 2005-03-04 at 10:29 +0000, Tim Waugh wrote:
> On Fri, Mar 04, 2005 at 02:42:17AM -0500, Bill Nottingham wrote:
>
> > It's sort of sad that to get a reasonable printout of a text file
> > in UTF-8 I had to open it in gedit first. Or is there some magic
> > I'm missing out on?
>
> Did you try just printing the text file with lpr? It gets converted
> to PostScript (and thence to raster) using CUPS' *own* texttops
> program. :-)
Which still almost certainly won't handle all our supported languages...
Regards,
Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From sgrubb at redhat.com Fri Mar 4 14:11:48 2005
From: sgrubb at redhat.com (Steve Grubb)
Date: Fri, 4 Mar 2005 09:11:48 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <20050304065439.GD5707@nostromo.devel.redhat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
Message-ID: <200503040911.48259.sgrubb@redhat.com>
On Friday 04 March 2005 01:54, Bill Nottingham wrote:
> - iptstate
I've found this package to be of great use demonstrating that a Linux based
corporate firewall is doing its job. You can watch both interfaces and see
the packet port stats. To those in the trenches doing battle, this is useful.
-Steve Grubb
From notting at redhat.com Fri Mar 4 17:32:26 2005
From: notting at redhat.com (Bill Nottingham)
Date: Fri, 4 Mar 2005 12:32:26 -0500
Subject: picking the best option from similar packages
In-Reply-To: <20050304102922.GF3626@redhat.com>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<20050304074217.GA6671@nostromo.devel.redhat.com>
<20050304102922.GF3626@redhat.com>
Message-ID: <20050304173226.GC8420@nostromo.devel.redhat.com>
Tim Waugh (twaugh at redhat.com) said:
> > It's sort of sad that to get a reasonable printout of a text file
> > in UTF-8 I had to open it in gedit first. Or is there some magic
> > I'm missing out on?
>
> Did you try just printing the text file with lpr? It gets converted
> to PostScript (and thence to raster) using CUPS' *own* texttops
> program. :-)
Yeah. That handled the classic latin glyphs, but not CJK, Indic,
etc.
Bill
From hp at redhat.com Fri Mar 4 19:44:56 2005
From: hp at redhat.com (Havoc Pennington)
Date: Fri, 04 Mar 2005 14:44:56 -0500
Subject: picking the best option from similar packages
In-Reply-To: <1109919349.23585.50.camel@cutter>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<1109919276.23585.48.camel@cutter> <1109919349.23585.50.camel@cutter>
Message-ID: <1109965496.31782.8.camel@localhost.localdomain>
On Fri, 2005-03-04 at 01:55 -0500, seth vidal wrote:
> On Fri, 2005-03-04 at 01:54 -0500, seth vidal wrote:
> > > The ones right now are:
> > >
> > > a2ps -vs- enscript
> >
> > well from the standpoint of code actually being more actively
> > maintained.
> >
> > a2ps was last updated 2 yrs ago, according to the website.
> > enscript was last updated 5 yrs ago.
>
> okay I typed that backward.
>
> enscript - updated 2 yrs ago
> a2ps - updated 5yrs ago.
>
> sorry
>
> so maybe it's best to move a2ps to extras.
>
Doesn't 2 vs. 5 years seem sort of academic? Degrees of deadness. ;-)
Havoc
From fche at redhat.com Fri Mar 4 19:47:52 2005
From: fche at redhat.com (Frank Ch. Eigler)
Date: Fri, 4 Mar 2005 14:47:52 -0500
Subject: picking the best option from similar packages
In-Reply-To: <1109965496.31782.8.camel@localhost.localdomain>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<1109919276.23585.48.camel@cutter>
<1109919349.23585.50.camel@cutter>
<1109965496.31782.8.camel@localhost.localdomain>
Message-ID: <20050304194752.GA22133@redhat.com>
Hi -
hp wrote:
> [...]
> > enscript - updated 2 yrs ago
> > a2ps - updated 5yrs ago.
> > [...]
> Doesn't 2 vs. 5 years seem sort of academic? Degrees of deadness. ;-)
Indeed. But really, we should not assume that a long-unmodified piece
of software is abandoned in a pejorative sense. It may simply be
complete, mature, and of that rare variant of software that has few
bugs. I think they call it "finished". :-)
- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From hp at redhat.com Fri Mar 4 19:51:51 2005
From: hp at redhat.com (Havoc Pennington)
Date: Fri, 04 Mar 2005 14:51:51 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <20050304065439.GD5707@nostromo.devel.redhat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
Message-ID: <1109965911.31782.14.camel@localhost.localdomain>
On Fri, 2005-03-04 at 01:54 -0500, Bill Nottingham wrote:
> Some of the discussion on fedora-devel was about certain Core
> packages and whether or not they seemed appropriate for Core as
> opposed to Extras. So, collecting more opinions at this point on:
>
> - iptstate
> - cscope
> - tora
> - Emacs addons - mew/ddskk/flim/wl
>
> Do people think that these are core functionality?
>
Can I suggest stepping back and asking "in our star trek future (FC5 or
6), what is the right line between Core and Extras" then try to apply
that line to specific packages.
"Reasonably objective to apply" would be a desirable property of the
line, if we can manage it.
My suggestion is that we have default package sets for the common use
cases (mail server, desktop, java dev workstation, etc.) and their union
is Core. Is that broken?
Havoc
From skvidal at phy.duke.edu Fri Mar 4 20:01:19 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 04 Mar 2005 15:01:19 -0500
Subject: picking the best option from similar packages
In-Reply-To: <1109965496.31782.8.camel@localhost.localdomain>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<1109919276.23585.48.camel@cutter> <1109919349.23585.50.camel@cutter>
<1109965496.31782.8.camel@localhost.localdomain>
Message-ID: <1109966479.23585.137.camel@cutter>
> Doesn't 2 vs. 5 years seem sort of academic? Degrees of deadness. ;-)
>
5 > 2
:)
-sv
From skvidal at phy.duke.edu Fri Mar 4 20:02:04 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 04 Mar 2005 15:02:04 -0500
Subject: picking the best option from similar packages
In-Reply-To: <20050304194752.GA22133@redhat.com>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<1109919276.23585.48.camel@cutter> <1109919349.23585.50.camel@cutter>
<1109965496.31782.8.camel@localhost.localdomain>
<20050304194752.GA22133@redhat.com>
Message-ID: <1109966524.23585.139.camel@cutter>
On Fri, 2005-03-04 at 14:47 -0500, Frank Ch. Eigler wrote:
> Hi -
>
> hp wrote:
>
> > [...]
> > > enscript - updated 2 yrs ago
> > > a2ps - updated 5yrs ago.
> > > [...]
> > Doesn't 2 vs. 5 years seem sort of academic? Degrees of deadness. ;-)
>
> Indeed. But really, we should not assume that a long-unmodified piece
> of software is abandoned in a pejorative sense. It may simply be
> complete, mature, and of that rare variant of software that has few
> bugs. I think they call it "finished". :-)
>
except without utf8 support I'd argue that it's not finished.
-sv
From mharris at redhat.com Fri Mar 4 23:05:46 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Fri, 4 Mar 2005 18:05:46 -0500 (EST)
Subject: picking the best option from similar packages
In-Reply-To: <1109966479.23585.137.camel@cutter>
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<1109919276.23585.48.camel@cutter> <1109919349.23585.50.camel@cutter>
<1109965496.31782.8.camel@localhost.localdomain>
<1109966479.23585.137.camel@cutter>
Message-ID:
On Fri, 4 Mar 2005, seth vidal wrote:
>Date: Fri, 04 Mar 2005 15:01:19 -0500
>From: seth vidal
>To: List for Fedora Package Maintainers
>Content-Type: text/plain
>Reply-To: List for Fedora Package Maintainers
>
>X-BeenThere: fedora-maintainers at redhat.com
>Subject: Re: picking the best option from similar packages
>
>
>> Doesn't 2 vs. 5 years seem sort of academic? Degrees of deadness. ;-)
>>
>
>5 > 2
I think what he is suggesting, is that projects that have had no
new releases in "n" days/weeks/months/years, have become
"unmaintained" and "dead". As "n" increases beyond that value,
it just underlines the fact, but doesn't change it in any
noticeable way.
While it can be argued that some projects have theoretically
reached a point of being "finished", where they have a complete
feature set, and no known bugs, with no reason to further extend
the software with additional features, I strongly question wether
this is the case for these specific software packages?
Do either of them have bug reports open in our bugzilla? In
their upstream bugzillas or other trackers? What is their
security history? What if new bugs are found and reported?
Security flaws? Is there an upstream maintainer still, who just
hasn't had anything to actually do for 2-5 years, or have the
maintainers abandoned the project(s)?
I think that's more what was intended. ;o)
--
Mike A. Harris, Systems Engineer - X11 Development team, Red Hat Canada, Ltd.
IT executives rate Red Hat #1 for value: http://www.redhat.com/promo/vendor
From skvidal at phy.duke.edu Sat Mar 5 01:22:53 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 04 Mar 2005 20:22:53 -0500
Subject: picking the best option from similar packages
In-Reply-To:
References: <20050304064235.GB5707@nostromo.devel.redhat.com>
<1109919276.23585.48.camel@cutter> <1109919349.23585.50.camel@cutter>
<1109965496.31782.8.camel@localhost.localdomain>
<1109966479.23585.137.camel@cutter>
Message-ID: <1109985774.23585.173.camel@cutter>
> I think that's more what was intended. ;o)
yah, I know, I was just being a smart-ass. :)
-sv
From sopwith at redhat.com Mon Mar 7 04:45:54 2005
From: sopwith at redhat.com (Elliot Lee)
Date: Sun, 6 Mar 2005 23:45:54 -0500 (EST)
Subject: FC-3 branch for vnstat
In-Reply-To: <20050305111349.GA29757@lisas.de>
References: <20050305111349.GA29757@lisas.de>
Message-ID:
On Sat, 5 Mar 2005, Adrian Reber wrote:
> Please create the FC-3 branch of vnstat.
Hi,
This is done.
I think we need to set up a cvsmaster at fedora.redhat.com request queue at
some point. I'll try to remember to get it on the TODO list.
-- Elliot
From nphilipp at redhat.com Mon Mar 7 08:03:39 2005
From: nphilipp at redhat.com (Nils Philippsen)
Date: Mon, 07 Mar 2005 09:03:39 +0100
Subject: [Fwd: "make tag"?]
Message-ID: <1110182619.2817.8.camel@gibraltar.stuttgart.redhat.com>
Hi there,
I sent this to fedora-extras-list at redhat.com, but to no avail. What's
the rationale behind Extras' CVS not having "make tag" (and along that
line "make force-tag")?
-------- Forwarded Message --------
From: Nils Philippsen
Reply-To: Discussion related to Fedora Extras
To: fedora-extras-list at redhat.com
Subject: "make tag"?
Date: Fri, 04 Mar 2005 16:59:15 +0100
Hi everybody,
I'm just getting the feel for Extras' CVS (now that my CVS account was
fixed -- thanks guys) and I'm wondering about why we don't have "make
tag" in Makefile.common. Granted, I may be assuming wrong things coming
from Red Hat's internal build system but as I couldn't find any docs on
that I'm asking here:
- Are we packagers supposed to tag the files in CVS for a specific
version-release? If yes, could we please have "make tag" which pulls
that info from the spec file?
- Or is this supposed to be done by whoever builds the package when it
is being built?
I'd say the latter is undesirable because this would mean that 1)
packaging "development" is stalled until the package is built and 2)
inadvertent commits by the packager or anybody else in the meantime will
get the wrong thing built.
Comments?
Nils
--
Nils Philippsen / Red Hat / nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
From SteveD at redhat.com Mon Mar 7 13:22:00 2005
From: SteveD at redhat.com (Steve Dickson)
Date: Mon, 07 Mar 2005 08:22:00 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <20050304065439.GD5707@nostromo.devel.redhat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
Message-ID: <422C5578.1050102@RedHat.com>
Bill Nottingham wrote:
> Some of the discussion on fedora-devel was about certain Core
> packages and whether or not they seemed appropriate for Core as
> opposed to Extras. So, collecting more opinions at this point on:
>
> - cscope
I use (and a lot of people in the westford office) use this everyday.
It ties in very nicely with vim tagging which makes it
incredibly easy to "fly" around in the kernel code....
I vote to keep this part of the core...
steved.
> - tora
> - Emacs addons - mew/ddskk/flim/wl
>
> Do people think that these are core functionality?
>
> Bill
>
> --
> Fedora-maintainers mailing list
> Fedora-maintainers at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-maintainers
From shahms at shahms.com Mon Mar 7 17:38:05 2005
From: shahms at shahms.com (Shahms King)
Date: Mon, 07 Mar 2005 09:38:05 -0800
Subject: cvs-import.sh and transparent proxies
Message-ID: <1110217085.11074.85.camel@shahms.mesd.k12.or.us>
I'm guessing this is more appropriate than extras-list for this, but
we'll see.
I recently tried to import ipython-0.6.11-2.src.rpm into Extras CVS and
got about 50% done when the cvs-import.sh script failed due to a 403
error on the upload.cgi script. I'm guessing that this is due to the
transparent proxy setup here at work. Clearly, removing source-ip
checking from the upload script is not an option. I asked the proxy
administrator to not re-route the http requests to
cvs.fedora.redhat.com, but not everyone in this situation might be able
to do that.
Would it be possible for cvs.fedora.redhat.com to listen on https or
8080 or something which is less frequently proxied (and have
Makefile.common default to that port)?
It seems like transparent proxying, while not common, is probably common
enough that more people than me will run into this problem sooner or
later...
--
Shahms E. King
Multnomah ESD
Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From enrico.scholz at informatik.tu-chemnitz.de Mon Mar 7 18:25:44 2005
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Mon, 07 Mar 2005 19:25:44 +0100
Subject: cvs-import.sh and transparent proxies
In-Reply-To: <1110217085.11074.85.camel@shahms.mesd.k12.or.us> (Shahms
King's message of "Mon, 07 Mar 2005 09:38:05 -0800")
References: <1110217085.11074.85.camel@shahms.mesd.k12.or.us>
Message-ID: <87vf83gvo7.fsf@kosh.ultra.csn.tu-chemnitz.de>
shahms at shahms.com (Shahms King) writes:
> I recently tried to import ipython-0.6.11-2.src.rpm into Extras CVS and
> got about 50% done when the cvs-import.sh script failed due to a 403
> error on the upload.cgi script. I'm guessing that this is due to the
> transparent proxy setup here at work. Clearly, removing source-ip
> checking from the upload script is not an option.
It is the only option... IP based authentication for public HTTP servers
is not a very clever solution (to say it politely). It does not gain any
security but destroys functionality.
A better option would be HTTP(S) auth for the upload script or auth by
SSL/TLS client certificates. Login data for the former method could be
reused from Bugzilla; the latter option requires some CA infrastructure
at RH.
Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL:
From mjohnson at redhat.com Mon Mar 7 22:51:19 2005
From: mjohnson at redhat.com (Mark Johnson)
Date: Mon, 07 Mar 2005 17:51:19 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <1109965911.31782.14.camel@localhost.localdomain>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
<1109965911.31782.14.camel@localhost.localdomain>
Message-ID: <422CDAE7.2070900@redhat.com>
Havoc Pennington wrote:
> My suggestion is that we have default package sets for the common use
> cases (mail server, desktop, java dev workstation, etc.) and their union
> is Core. Is that broken?
i don't think it's broken at all. debian does something similar in that it
groups packages into 'tasks', and you can decide at install time which tasks you
want to install (database server, python development, documentation tools, X,
workstation, etc.)
something similar might work for fc5, but imo fc5 need not comprise the entire
union of all the tasks. just thinking out loud here...
Mark
>
> Havoc
>
>
> --
> Fedora-maintainers mailing list
> Fedora-maintainers at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
----------------------------------------------------------
Mark Johnson
OS Product Documentation
Engineering, Red Hat, Inc.
Tel: 919.754.4151 Fax: 919.754.3708
GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
From skvidal at phy.duke.edu Mon Mar 7 23:02:38 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 07 Mar 2005 18:02:38 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <422CDAE7.2070900@redhat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
<1109965911.31782.14.camel@localhost.localdomain>
<422CDAE7.2070900@redhat.com>
Message-ID: <1110236558.12658.43.camel@cutter>
On Mon, 2005-03-07 at 17:51 -0500, Mark Johnson wrote:
> Havoc Pennington wrote:
> > My suggestion is that we have default package sets for the common use
> > cases (mail server, desktop, java dev workstation, etc.) and their union
> > is Core. Is that broken?
>
> i don't think it's broken at all. debian does something similar in that it
> groups packages into 'tasks', and you can decide at install time which tasks you
> want to install (database server, python development, documentation tools, X,
> workstation, etc.)
>
> something similar might work for fc5, but imo fc5 need not comprise the entire
> union of all the tasks. just thinking out loud here...
How is this any different than the way comps handles arbitrary grouping
right now?
-sv
From notting at redhat.com Tue Mar 8 19:07:29 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 8 Mar 2005 14:07:29 -0500
Subject: Saving space: drop Omni?
In-Reply-To: <20050228093444.GL3626@redhat.com>
References: <20050228093444.GL3626@redhat.com>
Message-ID: <20050308190729.GA12022@nostromo.devel.redhat.com>
Tim Waugh (twaugh at redhat.com) said:
> All the recent talk of saving space on CDs reminded me of a suggestion
> from a while back.
>
> Should we drop Omni? Does anyone actually use it successfully with
> their printer?
>
> (How to tell: go to System Settings->Printing, double-click on each
> queue name, go to the Printer driver tab and see if omni-compiled is
> selected.)
You know, there's been a distinct lack of response to this. As it stands
now, due to increases in size in OpenOffice (with version 2.0), x86
is back onto a fifth CD. Omni seems like it may be the quickest and easiest
solution to this problem.
Bill
From wcohen at redhat.com Tue Mar 8 19:26:16 2005
From: wcohen at redhat.com (William Cohen)
Date: Tue, 08 Mar 2005 14:26:16 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <422C5578.1050102@RedHat.com>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
<422C5578.1050102@RedHat.com>
Message-ID: <422DFC58.2090405@redhat.com>
Steve Dickson wrote:
> Bill Nottingham wrote:
>
>> Some of the discussion on fedora-devel was about certain Core
>> packages and whether or not they seemed appropriate for Core as
>> opposed to Extras. So, collecting more opinions at this point on:
>>
>> - cscope
>
> I use (and a lot of people in the westford office) use this everyday.
> It ties in very nicely with vim tagging which makes it
> incredibly easy to "fly" around in the kernel code....
>
> I vote to keep this part of the core...
>
> steved.
I second that. cscope is very useful to find out where things are in
source code.
-Will
From fche at redhat.com Tue Mar 8 20:04:47 2005
From: fche at redhat.com (Frank Ch. Eigler)
Date: Tue, 8 Mar 2005 15:04:47 -0500
Subject: Saving space: drop Omni?
In-Reply-To: <20050308190729.GA12022@nostromo.devel.redhat.com>
References: <20050228093444.GL3626@redhat.com>
<20050308190729.GA12022@nostromo.devel.redhat.com>
Message-ID: <20050308200446.GA13076@redhat.com>
Hi -
On Tue, Mar 08, 2005 at 02:07:29PM -0500, Bill Nottingham wrote:
> [...] As it stands now, due to increases in size in OpenOffice
> (with version 2.0), x86 is back onto a fifth CD. Omni seems like it
> may be the quickest and easiest solution to this problem.
The quickest and easiest solution may in fact be to dump the 4-cd limit.
- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From hp at redhat.com Wed Mar 9 02:41:54 2005
From: hp at redhat.com (Havoc Pennington)
Date: Tue, 08 Mar 2005 21:41:54 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <1110236558.12658.43.camel@cutter>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
<1109965911.31782.14.camel@localhost.localdomain>
<422CDAE7.2070900@redhat.com> <1110236558.12658.43.camel@cutter>
Message-ID: <1110336114.7568.21.camel@localhost.localdomain>
On Mon, 2005-03-07 at 18:02 -0500, seth vidal wrote:
> On Mon, 2005-03-07 at 17:51 -0500, Mark Johnson wrote:
> > Havoc Pennington wrote:
> > > My suggestion is that we have default package sets for the common use
> > > cases (mail server, desktop, java dev workstation, etc.) and their union
> > > is Core. Is that broken?
> >
> > i don't think it's broken at all. debian does something similar in that it
> > groups packages into 'tasks', and you can decide at install time which tasks you
> > want to install (database server, python development, documentation tools, X,
> > workstation, etc.)
> >
> > something similar might work for fc5, but imo fc5 need not comprise the entire
> > union of all the tasks. just thinking out loud here...
>
> How is this any different than the way comps handles arbitrary grouping
> right now?
>
My point was to only have the stuff that's in a comps group in Core at
all (and then the debate about what's in Core can be more about which
comps group, e.g. "does Java Development go in Core" rather than "does
package XYZ go in Core")
Of course there can be flames about which packages are in the comps
groups... but that seems somewhat more manageable than an undefined
Core/Extras line.
Havoc
From jspaleta at gmail.com Wed Mar 9 02:54:04 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Tue, 8 Mar 2005 21:54:04 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <1110336114.7568.21.camel@localhost.localdomain>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
<1109965911.31782.14.camel@localhost.localdomain>
<422CDAE7.2070900@redhat.com> <1110236558.12658.43.camel@cutter>
<1110336114.7568.21.camel@localhost.localdomain>
Message-ID: <604aa79105030818547c6d5ec0@mail.gmail.com>
On Tue, 08 Mar 2005 21:41:54 -0500, Havoc Pennington wrote:
> My point was to only have the stuff that's in a comps group in Core at
> all (and then the debate about what's in Core can be more about which
> comps group, e.g. "does Java Development go in Core" rather than "does
> package XYZ go in Core")
>
> Of course there can be flames about which packages are in the comps
> groups... but that seems somewhat more manageable than an undefined
> Core/Extras line.
+1
But I warn you the discussion about how to define comps groupings is
going to get messy. Comps has to be extended into extras...
organizing extras into groupings is going to be a dentist visit sort
of fun. You might be able to pigeon hole Core into sane, intutive
functionality groups that ui experts will love to expose to Core
users, but what ever group naming scheme works for Core is going to
break down a bit in the larger Extras space.
Do you really want to expose seperate groupings like
gnome games, java games, kde games
as comps groupings in whatever ui a user sees?
-jef
From notting at redhat.com Wed Mar 9 02:55:51 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 8 Mar 2005 21:55:51 -0500
Subject: package functionality - is it a core feature?
In-Reply-To: <1110336114.7568.21.camel@localhost.localdomain>
References: <20050304065439.GD5707@nostromo.devel.redhat.com>
<1109965911.31782.14.camel@localhost.localdomain>
<422CDAE7.2070900@redhat.com> <1110236558.12658.43.camel@cutter>
<1110336114.7568.21.camel@localhost.localdomain>
Message-ID: <20050309025551.GD19219@nostromo.devel.redhat.com>
Havoc Pennington (hp at redhat.com) said:
> My point was to only have the stuff that's in a comps group in Core at
> all (and then the debate about what's in Core can be more about which
> comps group, e.g. "does Java Development go in Core" rather than "does
> package XYZ go in Core")
>
> Of course there can be flames about which packages are in the comps
> groups... but that seems somewhat more manageable than an undefined
> Core/Extras line.
Realistically, that's where we're headed. Of course, there
will be 'additions' to the base comps groups in Extras as well
(in areas such as office apps, development, etc.)
For example, as brought up in this discussion:
- mew/wl/flim/etc aren't in comps
- tora is, but there's significant question as to whether it works, so
it's a prime candidate for moving
We could do a more rigourous dependency ananlysis and list
all the leaf nodes to spark discussion. :)
Bill
From aoliva at redhat.com Wed Mar 9 05:23:46 2005
From: aoliva at redhat.com (Alexandre Oliva)
Date: 09 Mar 2005 02:23:46 -0300
Subject: Saving space: drop Omni?
In-Reply-To: <20050308190729.GA12022@nostromo.devel.redhat.com>
References: <20050228093444.GL3626@redhat.com>
<20050308190729.GA12022@nostromo.devel.redhat.com>
Message-ID:
On Mar 8, 2005, Bill Nottingham wrote:
> You know, there's been a distinct lack of response to this. As it stands
> now, due to increases in size in OpenOffice (with version 2.0), x86
> is back onto a fifth CD. Omni seems like it may be the quickest and easiest
> solution to this problem.
So we dump Omni now, then at the time of FC4 test2 or test3, after a
few additional package upgrades, we're back to 4 CDs + change again,
and dump more useful packages, and so on until FC4 ships. Sounds like
a great approach to me, for someone who has nothing better to do than
counting CDs and selecting packages to remove. Erhm, to push to
extras, if someone chooses to pick them up, that is.
Meanwhile, we could be spending this time on actually making Fedora a
better distro :-/
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
From notting at redhat.com Wed Mar 9 06:42:06 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 9 Mar 2005 01:42:06 -0500
Subject: Saving space: drop Omni?
In-Reply-To:
References: <20050228093444.GL3626@redhat.com>
<20050308190729.GA12022@nostromo.devel.redhat.com>
Message-ID: <20050309064206.GA31160@nostromo.devel.redhat.com>
Alexandre Oliva (aoliva at redhat.com) said:
> Meanwhile, we could be spending this time on actually making Fedora a
> better distro :-/
Who's to say that by not focusing resources on Omni that are better used
elsewhere we aren't?
Bill
From twaugh at redhat.com Wed Mar 9 12:40:57 2005
From: twaugh at redhat.com (Tim Waugh)
Date: Wed, 9 Mar 2005 12:40:57 +0000
Subject: Saving space: drop Omni?
In-Reply-To: <20050309064206.GA31160@nostromo.devel.redhat.com>
References: <20050228093444.GL3626@redhat.com>
<20050308190729.GA12022@nostromo.devel.redhat.com>
<20050309064206.GA31160@nostromo.devel.redhat.com>
Message-ID: <20050309124056.GB6739@redhat.com>
On Wed, Mar 09, 2005 at 01:42:06AM -0500, Bill Nottingham wrote:
> Who's to say that by not focusing resources on Omni that are better used
> elsewhere we aren't?
Good point -- for example, take a look at the size of the patch I had
to make to get Omni to compile with GCC 4.
Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From notting at redhat.com Thu Mar 10 19:42:58 2005
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 10 Mar 2005 14:42:58 -0500
Subject: note about packaging init scripts
Message-ID: <20050310194258.GA5034@nostromo.devel.redhat.com>
If you are packaging init scripts with a file path of
/etc/init.d/your_script
you *need* to either:
a) prereq chkconfig (even if you don't call it)
b) package it in /etc/rc.d/init.d/your_script
As /etc/init.d is a symlink, if you don't do one of
these, your package may be installed first, and this
will cause chkconfig to fail to install later.
Bill
From skvidal at phy.duke.edu Thu Mar 10 19:45:08 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 10 Mar 2005 14:45:08 -0500
Subject: note about packaging init scripts
In-Reply-To: <20050310194258.GA5034@nostromo.devel.redhat.com>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
Message-ID: <1110483908.19164.23.camel@opus.phy.duke.edu>
On Thu, 2005-03-10 at 14:42 -0500, Bill Nottingham wrote:
> If you are packaging init scripts with a file path of
> /etc/init.d/your_script
> you *need* to either:
>
> a) prereq chkconfig (even if you don't call it)
> b) package it in /etc/rc.d/init.d/your_script
>
> As /etc/init.d is a symlink, if you don't do one of
> these, your package may be installed first, and this
> will cause chkconfig to fail to install later.
Thanks Bill, CCing this over to fedora-packaging to let Tom roll it into
his docs.
-sv
From mharris at redhat.com Thu Mar 10 19:50:25 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Thu, 10 Mar 2005 14:50:25 -0500 (EST)
Subject: note about packaging init scripts
In-Reply-To: <20050310194258.GA5034@nostromo.devel.redhat.com>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
Message-ID:
On Thu, 10 Mar 2005, Bill Nottingham wrote:
>Date: Thu, 10 Mar 2005 14:42:58 -0500
>From: Bill Nottingham
>To: fedora-maintainers at redhat.com
>Content-Type: text/plain; charset=us-ascii
>Reply-To: List for Fedora Package Maintainers
>
>X-BeenThere: fedora-maintainers at redhat.com
>Subject: note about packaging init scripts
>
>If you are packaging init scripts with a file path of
> /etc/init.d/your_script
>you *need* to either:
>
>a) prereq chkconfig (even if you don't call it)
>b) package it in /etc/rc.d/init.d/your_script
>
>As /etc/init.d is a symlink, if you don't do one of
>these, your package may be installed first, and this
>will cause chkconfig to fail to install later.
Wouldn't it be better to do:
PreReq: /etc/init.d
--
Mike A. Harris, Systems Engineer - X11 Development team, Red Hat Canada, Ltd.
IT executives rate Red Hat #1 for value: http://www.redhat.com/promo/vendor
From notting at redhat.com Thu Mar 10 19:52:58 2005
From: notting at redhat.com (Bill Nottingham)
Date: Thu, 10 Mar 2005 14:52:58 -0500
Subject: note about packaging init scripts
In-Reply-To:
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
Message-ID: <20050310195258.GC5034@nostromo.devel.redhat.com>
Mike A. Harris (mharris at redhat.com) said:
> >If you are packaging init scripts with a file path of
> > /etc/init.d/your_script
> >you *need* to either:
> >
> >a) prereq chkconfig (even if you don't call it)
> >b) package it in /etc/rc.d/init.d/your_script
> >
> >As /etc/init.d is a symlink, if you don't do one of
> >these, your package may be installed first, and this
> >will cause chkconfig to fail to install later.
>
> Wouldn't it be better to do:
>
> PreReq: /etc/init.d
Either chkconfig, or /etc/init.d will work.
Bill
From nphilipp at redhat.com Thu Mar 10 20:56:51 2005
From: nphilipp at redhat.com (Nils Philippsen)
Date: Thu, 10 Mar 2005 21:56:51 +0100
Subject: note about packaging init scripts
In-Reply-To:
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
Message-ID: <1110488211.7950.4.camel@wombat.tiptoe.de>
On Thu, 2005-03-10 at 14:50 -0500, Mike A. Harris wrote:
> On Thu, 10 Mar 2005, Bill Nottingham wrote:
>
> >Date: Thu, 10 Mar 2005 14:42:58 -0500
> >From: Bill Nottingham
> >To: fedora-maintainers at redhat.com
> >Content-Type: text/plain; charset=us-ascii
> >Reply-To: List for Fedora Package Maintainers
> >
> >X-BeenThere: fedora-maintainers at redhat.com
> >Subject: note about packaging init scripts
> >
> >If you are packaging init scripts with a file path of
> > /etc/init.d/your_script
> >you *need* to either:
> >
> >a) prereq chkconfig (even if you don't call it)
> >b) package it in /etc/rc.d/init.d/your_script
> >
> >As /etc/init.d is a symlink, if you don't do one of
> >these, your package may be installed first, and this
> >will cause chkconfig to fail to install later.
>
> Wouldn't it be better to do:
>
> PreReq: /etc/init.d
Don't "PreReq:" (which gets treated like a simple "Requires:" IIRC), use
"Requires(pre):" and for that matter "Requires(post):" as well. Don't do
this:
Requires(pre,post): /sbin/chkconfig
but do that instead:
Requires(pre): /sbin/chkconfig
Requires(post): /sbin/chkconfig
Nils
--
Nils Philippsen / Red Hat / nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From timp at redhat.com Thu Mar 10 21:06:47 2005
From: timp at redhat.com (Tim Powers)
Date: Thu, 10 Mar 2005 16:06:47 -0500
Subject: note about packaging init scripts
In-Reply-To: <1110488211.7950.4.camel@wombat.tiptoe.de>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
Message-ID: <9dd35777c324cdcfc58600c3d0649078@redhat.com>
On Mar 10, 2005, at 3:56 PM, Nils Philippsen wrote:
>
> Don't "PreReq:" (which gets treated like a simple "Requires:" IIRC),
> use
> "Requires(pre):" and for that matter "Requires(post):" as well. Don't
> do
> this:
>
> Requires(pre,post): /sbin/chkconfig
>
> but do that instead:
>
> Requires(pre): /sbin/chkconfig
> Requires(post): /sbin/chkconfig
Every time I see this I get confused. jbj: please tell us whether or
not we should be doing this. I remember the stone-age when it was
introduced, abused, and we were told not to do this anymore. What's the
current recommendation?
--
Tim Powers
Technical Lead, Release Engineering
Red Hat, Inc.
From ville.skytta at iki.fi Fri Mar 11 12:15:18 2005
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Fri, 11 Mar 2005 14:15:18 +0200
Subject: note about packaging init scripts
In-Reply-To: <9dd35777c324cdcfc58600c3d0649078@redhat.com>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
<9dd35777c324cdcfc58600c3d0649078@redhat.com>
Message-ID: <1110543318.2786.34.camel@bobcat.mine.nu>
On Thu, 2005-03-10 at 16:06 -0500, Tim Powers wrote:
> On Mar 10, 2005, at 3:56 PM, Nils Philippsen wrote:
>
> >
> > Don't "PreReq:" (which gets treated like a simple "Requires:" IIRC),
Almost. In case of circular dependencies, PreReq "wins" over Requires.
In the vast majority of cases (ie. when there are no circular
dependencies), they're equivalent, and rpm will do the right thing at
install time.
AFAIK, erasure ordering is still unimplemented though, and the only
thing a packager can do is to "manually" take that into account in
specfiles where necessary.
> > use
> > "Requires(pre):" and for that matter "Requires(post):" as well. Don't
> > do
> > this:
> >
> > Requires(pre,post): /sbin/chkconfig
> >
> > but do that instead:
> >
> > Requires(pre): /sbin/chkconfig
> > Requires(post): /sbin/chkconfig
>
> Every time I see this I get confused. jbj: please tell us whether or
> not we should be doing this. I remember the stone-age when it was
> introduced, abused, and we were told not to do this anymore. What's the
> current recommendation?
I'm not jbj, but here's something related:
https://bugzilla.redhat.com/118780
https://bugzilla.redhat.com/118773
From jbj at redhat.com Fri Mar 11 18:24:12 2005
From: jbj at redhat.com (Jeff Johnson)
Date: Fri, 11 Mar 2005 13:24:12 -0500
Subject: note about packaging init scripts
In-Reply-To: <1110543318.2786.34.camel@bobcat.mine.nu>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
<9dd35777c324cdcfc58600c3d0649078@redhat.com>
<1110543318.2786.34.camel@bobcat.mine.nu>
Message-ID: <20050311182412.GV9722@devserv.devel.redhat.com>
On Fri, Mar 11, 2005 at 02:15:18PM +0200, Ville Skytt? wrote:
> On Thu, 2005-03-10 at 16:06 -0500, Tim Powers wrote:
> > On Mar 10, 2005, at 3:56 PM, Nils Philippsen wrote:
> >
> > >
> > > Don't "PreReq:" (which gets treated like a simple "Requires:" IIRC),
>
> Almost. In case of circular dependencies, PreReq "wins" over Requires.
> In the vast majority of cases (ie. when there are no circular
> dependencies), they're equivalent, and rpm will do the right thing at
> install time.
No no no no no no no no!
There is literally no difference between PreReq: and Requires:, rpm-4.4
and beyond is incapable of either setting or testing RPMSENSE_PREREQ.
>From /usr/include/rpm/rpmlib.h:
RPMSENSE_ANY = 0,
...
/* bit 6 used to be RPMSENSE_PREREQ */
#define RPMSENSE_PREREQ RPMSENSE_ANY
Now please explain how rpmlib distingushes between PreReq: and Requires:
when the bit cannot be either tested or set because the mask is 0?
>
> AFAIK, erasure ordering is still unimplemented though, and the only
> thing a packager can do is to "manually" take that into account in
> specfiles where necessary.
>
Erasure ordering has always been implemented as the reverse of
install ordering., so "unimplemented" is more FUD.
> > > use
> > > "Requires(pre):" and for that matter "Requires(post):" as well. Don't
> > > do
> > > this:
> > >
> > > Requires(pre,post): /sbin/chkconfig
> > >
> > > but do that instead:
> > >
> > > Requires(pre): /sbin/chkconfig
> > > Requires(post): /sbin/chkconfig
> >
> > Every time I see this I get confused. jbj: please tell us whether or
> > not we should be doing this. I remember the stone-age when it was
> > introduced, abused, and we were told not to do this anymore. What's the
> > current recommendation?
>
I couldn't care less what you do as packagers, the syntax is there, and
you can use as you see fit. It Simply Does Not Matter in the majority of
cases.
Meanwhile, what needs to be done is automate the identification of
scriptlet dependencies by resurrecting the patch to bash from RHL 6.2.
That's my opinion anyways.
> I'm not jbj, but here's something related:
> https://bugzilla.redhat.com/118780
> https://bugzilla.redhat.com/118773
>
I am jbj ;-) Not that it matters, sigh.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC
From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 11 18:40:15 2005
From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz)
Date: Fri, 11 Mar 2005 19:40:15 +0100
Subject: note about packaging init scripts
In-Reply-To: <20050311182412.GV9722@devserv.devel.redhat.com> (Jeff
Johnson's message of "Fri, 11 Mar 2005 13:24:12 -0500")
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
<9dd35777c324cdcfc58600c3d0649078@redhat.com>
<1110543318.2786.34.camel@bobcat.mine.nu>
<20050311182412.GV9722@devserv.devel.redhat.com>
Message-ID: <87psy681rk.fsf@kosh.ultra.csn.tu-chemnitz.de>
jbj at redhat.com (Jeff Johnson) writes:
>> > > Don't do this:
>> > >
>> > > Requires(pre,post): /sbin/chkconfig
>> > >
>> > > but do that instead:
>> > >
>> > > Requires(pre): /sbin/chkconfig
>> > > Requires(post): /sbin/chkconfig
> ...
> I couldn't care less what you do as packagers, the syntax is there, and
> you can use as you see fit. It Simply Does Not Matter in the majority of
> cases.
Sorry, when I disagree, but when with:
| Requires(pre,postun): test-A
'test-A' will be installed *after* %pre, then it matters. Or do you know a
way to determine if a package belongs to the "majority of cases", or if it
belongs to the "minority" where 'Requires(pre,postun)' fails miserably?
> https://bugzilla.redhat.com/118773
Enrico
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 480 bytes
Desc: not available
URL:
From jbj at redhat.com Fri Mar 11 18:50:35 2005
From: jbj at redhat.com (Jeff Johnson)
Date: Fri, 11 Mar 2005 13:50:35 -0500
Subject: note about packaging init scripts
In-Reply-To: <87psy681rk.fsf@kosh.ultra.csn.tu-chemnitz.de>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
<9dd35777c324cdcfc58600c3d0649078@redhat.com>
<1110543318.2786.34.camel@bobcat.mine.nu>
<20050311182412.GV9722@devserv.devel.redhat.com>
<87psy681rk.fsf@kosh.ultra.csn.tu-chemnitz.de>
Message-ID: <20050311185035.GW9722@devserv.devel.redhat.com>
On Fri, Mar 11, 2005 at 07:40:15PM +0100, Enrico Scholz wrote:
> jbj at redhat.com (Jeff Johnson) writes:
>
> >> > > Don't do this:
> >> > >
> >> > > Requires(pre,post): /sbin/chkconfig
> >> > >
> >> > > but do that instead:
> >> > >
> >> > > Requires(pre): /sbin/chkconfig
> >> > > Requires(post): /sbin/chkconfig
> > ...
> > I couldn't care less what you do as packagers, the syntax is there, and
> > you can use as you see fit. It Simply Does Not Matter in the majority of
> > cases.
>
> Sorry, when I disagree, but when with:
>
> | Requires(pre,postun): test-A
>
> 'test-A' will be installed *after* %pre, then it matters. Or do you know a
> way to determine if a package belongs to the "majority of cases", or if it
> belongs to the "minority" where 'Requires(pre,postun)' fails miserably?
>
Nope, %pre does not matter, because both %pre/%post are marked as "install"
context independent of their "pre" or "post" qualities.
The only known useful case for the markings is the libtermcap <-> bash loop,
where "install" versus "erase" context is used to snip a loop.
In practice, there are increasingly ever more dependency loops in the distro,
and rpmlib happily ignores all relations in the loop equally. That leads
to a degree of indeterminancy in installing, and ignoring all relations
rather than a single relation is perhaps to blame, but the problem is loops,
not otherwise, and needs to be handled by identifying loops and carefully
examining where the loop needs to be snipped, not through *.spec usage.
>
> > https://bugzilla.redhat.com/118773
>
Which has nothing important to do with any problem, as
Requires(pre):
Requires(post):
works just fine.
I will prevent the syntax
Requires(pre,post):
if you do not have the discipline to not use known broken syntax.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC
From jbj at redhat.com Fri Mar 11 19:31:19 2005
From: jbj at redhat.com (Jeff Johnson)
Date: Fri, 11 Mar 2005 14:31:19 -0500
Subject: note about packaging init scripts
In-Reply-To: <20050311185035.GW9722@devserv.devel.redhat.com>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
<9dd35777c324cdcfc58600c3d0649078@redhat.com>
<1110543318.2786.34.camel@bobcat.mine.nu>
<20050311182412.GV9722@devserv.devel.redhat.com>
<87psy681rk.fsf@kosh.ultra.csn.tu-chemnitz.de>
<20050311185035.GW9722@devserv.devel.redhat.com>
Message-ID: <20050311193119.GX9722@devserv.devel.redhat.com>
On Fri, Mar 11, 2005 at 01:50:35PM -0500, Jeff Johnson wrote:
> On Fri, Mar 11, 2005 at 07:40:15PM +0100, Enrico Scholz wrote:
> > jbj at redhat.com (Jeff Johnson) writes:
> >
> > >> > > Don't do this:
> > >> > >
> > >> > > Requires(pre,post): /sbin/chkconfig
> > >> > >
> > >> > > but do that instead:
> > >> > >
> > >> > > Requires(pre): /sbin/chkconfig
> > >> > > Requires(post): /sbin/chkconfig
> > > ...
> > > I couldn't care less what you do as packagers, the syntax is there, and
> > > you can use as you see fit. It Simply Does Not Matter in the majority of
> > > cases.
> >
> > Sorry, when I disagree, but when with:
> >
> > | Requires(pre,postun): test-A
> >
> > 'test-A' will be installed *after* %pre, then it matters. Or do you know a
> > way to determine if a package belongs to the "majority of cases", or if it
> > belongs to the "minority" where 'Requires(pre,postun)' fails miserably?
> >
>
> Nope, %pre does not matter, because both %pre/%post are marked as "install"
> context independent of their "pre" or "post" qualities.
>
> The only known useful case for the markings is the libtermcap <-> bash loop,
> where "install" versus "erase" context is used to snip a loop.
>
> In practice, there are increasingly ever more dependency loops in the distro,
> and rpmlib happily ignores all relations in the loop equally. That leads
> to a degree of indeterminancy in installing, and ignoring all relations
> rather than a single relation is perhaps to blame, but the problem is loops,
> not otherwise, and needs to be handled by identifying loops and carefully
> examining where the loop needs to be snipped, not through *.spec usage.
>
> >
> > > https://bugzilla.redhat.com/118773
> >
>
> Which has nothing important to do with any problem, as
> Requires(pre):
> Requires(post):
> works just fine.
>
> I will prevent the syntax
> Requires(pre,post):
> if you do not have the discipline to not use known broken syntax.
>
Apologies if I sound perhaps more vehement and angry.
The combining of PreReq: and Requires: occurred in RHL 7.0.
The busted syntax has been known for at least a year.
To see these issues *still* being discussed without any ability
whatsoever to change already deployed rpm, or to be able to change
rpm in any RHEL product, is quite distressing to me.
I'd much rather spend my time "fixing" rpm problems than discussing
very ancient history. Alas, that is not possible.
So my apologies to both Ville and Enrico, there is certainly no bad
will from me towards either of you.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC
From twaugh at redhat.com Sat Mar 12 13:36:15 2005
From: twaugh at redhat.com (Tim Waugh)
Date: Sat, 12 Mar 2005 13:36:15 +0000
Subject: note about packaging init scripts
In-Reply-To: <20050311182412.GV9722@devserv.devel.redhat.com>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
<9dd35777c324cdcfc58600c3d0649078@redhat.com>
<1110543318.2786.34.camel@bobcat.mine.nu>
<20050311182412.GV9722@devserv.devel.redhat.com>
Message-ID: <20050312133615.GL15511@redhat.com>
On Fri, Mar 11, 2005 at 01:24:12PM -0500, Jeff Johnson wrote:
> Meanwhile, what needs to be done is automate the identification of
> scriptlet dependencies by resurrecting the patch to bash from RHL 6.2.
> That's my opinion anyways.
The patch never went away. bash --rpm-requires is still
there. (Whether it still works, of course, is another question..)
Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
From anvil at livna.org Sat Mar 12 14:11:29 2005
From: anvil at livna.org (Dams)
Date: Sat, 12 Mar 2005 15:11:29 +0100
Subject: GConf schema packaging guidelines
In-Reply-To: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
References: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
Message-ID: <1110636689.31593.19.camel@gruyere>
Hi.
This is a packaging bug if you dont test the upgrade case.
If you uninstall schemas you just *must* have an `if' statement
surrounding the gconf schema un-installation in %preun, to test if we're
being upgraded or un-installed.
Remember that, when upgrading, %preun of the old package is ran after
the new package %post.
And anyway, we have a problem in cases like:
* foo-1 which has foo.schema is installed
* you upgrade to foo-2 which has foo2.schema, but has no
foo.schema.
foo.schema will never be uninstalled, as foo-2 knows nothing about it.
(Yes, that sort of things has already happened).
So, do we bother about un-installing or.. ?
D
Le mardi 01 mars 2005 ? 14:42 -0500, David Malcolm a ?crit :
> Some spec files try to uninstall the schema e.g. from
> evolution-connector:
> %preun
> export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
> gconftool-2 --makefile-uninstall-rule \
> %{_sysconfdir}/gconf/schemas/apps_evolution_exchange.schemas
> >/dev/null || :
>
--
Dams Nad?
Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora
"Dona Nobis Pacem E Dona Eis Requiem". Noir.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL:
From sgrubb at redhat.com Sat Mar 12 15:40:15 2005
From: sgrubb at redhat.com (Steve Grubb)
Date: Sat, 12 Mar 2005 10:40:15 -0500
Subject: note about packaging init scripts
In-Reply-To: <20050312133615.GL15511@redhat.com>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<20050311182412.GV9722@devserv.devel.redhat.com>
<20050312133615.GL15511@redhat.com>
Message-ID: <200503121040.15458.sgrubb@redhat.com>
On Saturday 12 March 2005 08:36, Tim Waugh wrote:
> The patch never went away. ?bash --rpm-requires is still
> there. (Whether it still works, of course, is another question..)
It works. I have a %__find_requires macro that runs a test of all shell
scripts and compares that to what the rpm dependency checker comes up with
and adds the difference. Its configurable to either output the dependency as
files or packages. I have one more tweek to it before adding it to the
Rookery build system. Shell script dependency info is the weak link. Let me
know if you want a copy of the script to experiment with.
-Steve Grubb
From wtogami at redhat.com Sat Mar 12 22:37:07 2005
From: wtogami at redhat.com (Warren Togami)
Date: Sat, 12 Mar 2005 12:37:07 -1000
Subject: Purge Fedora updates
Message-ID: <42336F13.3000706@redhat.com>
Can we purge the Fedora updates again? Should we auto-purge updates
that were obosleted and older than 2 months?
Warren Togami
wtogami at redhat.com
From dcbw at redhat.com Sat Mar 12 22:49:54 2005
From: dcbw at redhat.com (Dan Williams)
Date: Sat, 12 Mar 2005 17:49:54 -0500 (EST)
Subject: Purge Fedora updates
In-Reply-To: <42336F13.3000706@redhat.com>
References: <42336F13.3000706@redhat.com>
Message-ID:
On Sat, 12 Mar 2005, Warren Togami wrote:
> Can we purge the Fedora updates again? Should we auto-purge updates
> that were obosleted and older than 2 months?
FC3 updates has something like 3 or 4 versions of OOo currently mirrored,
including the most recent release. That's a lot of space (~200MB each).
Dan
From riel at redhat.com Sun Mar 13 02:02:56 2005
From: riel at redhat.com (Rik van Riel)
Date: Sat, 12 Mar 2005 21:02:56 -0500 (EST)
Subject: Saving space: drop Omni?
In-Reply-To: <20050308190729.GA12022@nostromo.devel.redhat.com>
References: <20050228093444.GL3626@redhat.com>
<20050308190729.GA12022@nostromo.devel.redhat.com>
Message-ID:
On Tue, 8 Mar 2005, Bill Nottingham wrote:
> You know, there's been a distinct lack of response to this. As it stands
> now, due to increases in size in OpenOffice (with version 2.0),
Is it including a second libc now ? ;)
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
From davidz at redhat.com Sun Mar 13 07:16:22 2005
From: davidz at redhat.com (David Zeuthen)
Date: Sun, 13 Mar 2005 02:16:22 -0500
Subject: STR working out of the box
Message-ID: <1110698182.8327.69.camel@daxter.boston.redhat.com>
Hey,
As ACPI suspend-to-ram (S3) seems to work for more and more people as
the kernel improves, I've written some code/scripts to make it work
better out of the box as, ideally, this should be zero configuration,
e.g., if it's supported, it should "Just Work".
We're pretty far from that goal right now, we don't have an easy-to-edit
configuration file (and we certainly shouldn't be relying users on being
able to edit configuration files either), and suspend-to-ram just
doesn't work on enough boxes to enable it per default.
On http://people.redhat.com/davidz/suspend/ you should find SRPMs and
i386 RPMS for
vbetool-0.2 - Tool for run real-mode video BIOS code to alter
hardware state
powermgmt-001 - ACPI S3 suspend script, configuration file and
lid event script for acpid
hal-0.5.0.cvs20050312 - new version of hal to cope with whitelist data
(see below)
Out of the box, this does nothing, if you run /usr/sbin/suspend.sh
(which is also invoked by acpid when the lid is closed) the following is
printed:
[root at daxter ~]# /usr/sbin/suspend.sh
Checking whether system is whitelisted
error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.can_suspend on device with id /org/freedesktop/Hal/devices/computer
error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.suspend.method on device with id /org/freedesktop/Hal/devices/computer
error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.suspend.vbetool_post on device with id /org/freedesktop/Hal/devices/computer
error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.suspend.vbetool_dpms on device with id /org/freedesktop/Hal/devices/computer
error: libhal_device_get_property_type: org.freedesktop.Hal.NoSuchProperty: No property policy.acpi.linux.suspend.modules on device with id /org/freedesktop/Hal/devices/computer
Suspend enabled: No
Using vbetool to POST on resume: No
Using vbetool to turn off backlight: No
Kernel modules to unload: (none)
Suspend method: mem
Suspend not enabled; Follow instructions in /etc/suspend.conf
So, we need to configure this stuff in /etc/suspend.conf (Q: wait,
didn't he just tell me users shouldn't edit config files? A: keep
reading!). Open this file and change SUSPEND_ENABLED to "true" and also
SUSPEND_GENERATE_HAL_FDI to "true".
Now, save all your work (since your box may not come up!), cross your
fingers and run /usr/sbin/suspend.sh again.
Depending on your video card, you may need to set SUSPEND_VBETOOL_POST
and/or SUSPEND_VBETOOL_DPMS to "true". You may also need to add kernel
modules (lsmod is useful here) to SUSPEND_MODULES, e.g. SUSPEND_MODULES=
"ehci_hcd uhci_hcd" depending on your box.
When and if your system finally resumes you should see a blurb similar
to this:
Generating HAL device information file..
Generated HAL device information file for whitelist
==== BEGIN CUT ====
true
mem
==== END CUT ====
TODO: Prompt user to interactively submit this file to RH Bugzilla
This is a hal device information file that should be submitted upstream
so other users, that use the same hardware, can suspend out of the box
too (<-- that's the answer to the Q above :->). As it should be evident
from the XML, we match on
- ACPI version must be as new as on the test box
- kernel must be as new as on the test box
- The manufacturer name (from dmidecode)
- The product name (from dmidecode)
and if this matches, we put the same values in the hal device
information as the ones that worked in the /etc/suspend.conf file
(If you study /usr/sbin/suspend.sh, you will see that this script
queries HAL for these properties and replaces them if appropriate.
(Ideally, we should have a mechanism for automatically allowing users to
post this to our Bugzilla)
So, for me, if I put the device information file that was given to me
above (see attached for the file) in /etc/hal/fdi/information, reboot
the box (I could restart services, sure, but it's easier to write
"reboot the box"), then I've got suspend-on-lid working. No
configuration, no command line, no config files. Out of the box.
Similarly, if we ship these RPM's and this very device information file
other users of instances of this particular version of IBM Thinkpad T41
would be easily well of.
Or would they?
Here are fairly difficult questions/issues:
1. I've assumed that "ACPI S3 sleep works" is tied to what kind of
system it is; I use SMBIOS values (and the SMBIOS may lie!) as
keys; are there better keys (such as `md5sum /proc/acpi/dsdt`)
or is the assumption totally wrong?
2. I've assumed that there are no regressions in the kernel; e.g.
if ACPI S3 sleep works in kernel X for a system Y then it also
works in kernel Z for system Y given that Z >= X. I don't
really know enough linux-acpi history if this is a good assumption?
3. vbetool is kind of evil; it's a workaround for broken video
drivers and the mess that is X.org / kernel interaction wrt.
to video hardware (so, vbetool becomes the 3th or 4th player
directly touching hardware. Yay!). I expect we need to add
radeontool at some point too.
Also, for fun, go look at the /usr/sbin/suspend.sh script to
see the wonderful hacks switching virtual terminals (most of
these tricks are taken from looking at what other distros/
upstream scripts does)
4. ditto for rmmod; modules should never never be unloaded or
so the core kernel guys says.
5. I've assumed that the list of modules to unload is also tied
to the system, but isn't it more tied to the current kernel
version?
6. Sometimes suspend fails for me because the mDNSResponder
service wasn't stopped:
Mar 13 01:33:32 daxter kernel: stopping tasks failed (1 tasks remaining)
Mar 13 01:33:32 daxter kernel: Restarting tasks...<6> Strange, mDNSResponder not stopped
Some of the other distro/upstream scripts have a list of
services to stop. I've seen mysql there too. Euhw.
7. There is a TODO to shutdown networking completely as some
network drivers refuse to be unloaded otherwise - even if
the drivers were to be fixed we'd probably want this anyway
in a NetworkManager world
8. This is a very first cut; in time all policy will be controlled
from the desktop (thus respecting per-user policy / lock down
etc.) - see http://live.gnome.org/ProjectUtopia_2fPowerManagement
for details
9. Support for non-ACPI power-manegement, e.g. PMU for Apple hardware,
should be easy to add along the way.
In light of this: is it too dangerous, at this point, to enable this per
default given we use the white lists as discussed above? Should we
rather wait for the kernel/X.org to get fixed? (no, I'm not trolling
here, I'm being serious actually)
(and no, I'm not asking for hal device information files either just
yet, so please don't send / bugzilla them)
Cheers,
David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20-acpi-s3-IBM-2373HU6.fdi
Type: application/x-extension-fdi
Size: 680 bytes
Desc: not available
URL:
From davej at redhat.com Sun Mar 13 08:12:22 2005
From: davej at redhat.com (Dave Jones)
Date: Sun, 13 Mar 2005 03:12:22 -0500
Subject: STR working out of the box
In-Reply-To: <1110698182.8327.69.camel@daxter.boston.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
Message-ID: <20050313081221.GC25814@redhat.com>
On Sun, Mar 13, 2005 at 02:16:22AM -0500, David Zeuthen wrote:
> 2. I've assumed that there are no regressions in the kernel; e.g.
> if ACPI S3 sleep works in kernel X for a system Y then it also
> works in kernel Z for system Y given that Z >= X. I don't
> really know enough linux-acpi history if this is a good assumption?
Bwahahahaha! ACPI is sadly probably one of the worst areas of the
kernel wrt regressions. Every time a new point release comes out
it's a case of 'some bugs got fixed, a bunch of new ones appeared'.
Unfortunatly, I don't see any way forward without making the same
assumption.
> 3. vbetool is kind of evil; it's a workaround for broken video
> drivers and the mess that is X.org / kernel interaction wrt.
> to video hardware (so, vbetool becomes the 3th or 4th player
> directly touching hardware. Yay!). I expect we need to add
> radeontool at some point too.
One day when the kernel does proper arbitration for the video
resources hopefully we won't need this, but that's way way off
in the future.
> 4. ditto for rmmod; modules should never never be unloaded or
> so the core kernel guys says.
Well.. that depends. There's no excuse for buggy modules, and
where bugs are found, we should fix them.
A lot of the issues like "I need to rmmod foo before I suspend"
are possibly just drivers lacking suspend/resume methods to
save/restore state.
> 5. I've assumed that the list of modules to unload is also tied
> to the system, but isn't it more tied to the current kernel
> version?
Very likely. Annoyingly, upstream have this habit of renaming modules
gratuitously every so often.
> 7. There is a TODO to shutdown networking completely as some
> network drivers refuse to be unloaded otherwise - even if
> the drivers were to be fixed we'd probably want this anyway
> in a NetworkManager world
All network drivers should be rmmod'able, even if the interface
is up. (It sometimes does crazy things though, like immediately
reloading the module and firing up dhclient)
> In light of this: is it too dangerous, at this point, to enable this per
> default given we use the white lists as discussed above? Should we
> rather wait for the kernel/X.org to get fixed? (no, I'm not trolling
> here, I'm being serious actually)
There are *lots* of 'suspend broke' bugs in bugzilla against the kernel.
As no-one has been doing any work on this aside from upstream (and even there
it's not really a priority, as the ACPI folks are buried alive in fixing
ACPI bugs related to configuration issues, and everyone else seems to
think swsusp is the best thing since sliced bread).
I'll warn you now, that there will be kernel bugs. Whether anyone
gets to fixing them in any short amount of time is something that
I wouldn't like to place odds on. I'd love it if suspend/resume
worked on more systems, however it's something of a black art
chasing down problems related to this issue. My laptop for instance
suspends just fine. Resume however looks just like I powered it on
for the first time. I've written this off as 'BIOS bug', and don't
ever expect it to work. Some of our users however won't see things
the same way because "Windows works fine".
Dave
From wtogami at redhat.com Sun Mar 13 11:19:58 2005
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 13 Mar 2005 01:19:58 -1000
Subject: STR working out of the box
In-Reply-To: <1110698182.8327.69.camel@daxter.boston.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
Message-ID: <423421DE.2050403@redhat.com>
David Zeuthen wrote:
>
> 2. I've assumed that there are no regressions in the kernel; e.g.
> if ACPI S3 sleep works in kernel X for a system Y then it also
> works in kernel Z for system Y given that Z >= X. I don't
> really know enough linux-acpi history if this is a good assumption?
After the whitelist format stabilizes, upstream needs a database driven
testing matrix of kernels versions, hardware, and tested drivers, and
userspace stuff that interferes. This kind of thing is the only way to
spot trends to identify when regressions began (for LART targeting),
which drivers seem to work, which hardware seems to work, which drivers
need fixing, which userspace stuff needs fixing/workarounds.
A relatively simple XML-RPC-like reporting tool would make it possible
to submit uniform and accurate data to such a database.
But I don't volunteer to organize this. =)
>
> 3. vbetool is kind of evil; it's a workaround for broken video
> drivers and the mess that is X.org / kernel interaction wrt.
> to video hardware (so, vbetool becomes the 3th or 4th player
> directly touching hardware. Yay!). I expect we need to add
> radeontool at some point too.
> Also, for fun, go look at the /usr/sbin/suspend.sh script to
> see the wonderful hacks switching virtual terminals (most of
> these tricks are taken from looking at what other distros/
> upstream scripts does)
More ugly hacks...
/sbin/hwclock --systohc /sbin/hwclock --hctosys
Would it be appropriate to include these pair of commands in the
suspend.sh in order to avoid time clock screwage?
At least on my Thinkpad T41 it seems that the time clock goes twice as
fast while suspended. Don't know how many other machines are affected
in this way.
>
> 6. Sometimes suspend fails for me because the mDNSResponder
> service wasn't stopped:
>
> Mar 13 01:33:32 daxter kernel: stopping tasks failed (1 tasks remaining)
> Mar 13 01:33:32 daxter kernel: Restarting tasks...<6> Strange, mDNSResponder not stopped
>
> Some of the other distro/upstream scripts have a list of
> services to stop. I've seen mysql there too. Euhw.
>
>
Is it possible to stop mDNSResponder manually without uninstalling it?
It seems that service mDNSResponder stop always fails, as does kill -9.
One more question...
suspend-checklid.sh assumes that all users *always* wants suspend if the
LID is closed. I am assuming this will eventually be configurable
easily from the desktop, but will it default this way?
Warren Togami
wtogami at redhat.com
From ville.skytta at iki.fi Sun Mar 13 17:12:12 2005
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Sun, 13 Mar 2005 19:12:12 +0200
Subject: note about packaging init scripts
In-Reply-To: <20050311182412.GV9722@devserv.devel.redhat.com>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
<9dd35777c324cdcfc58600c3d0649078@redhat.com>
<1110543318.2786.34.camel@bobcat.mine.nu>
<20050311182412.GV9722@devserv.devel.redhat.com>
Message-ID: <1110733932.2786.132.camel@bobcat.mine.nu>
On Fri, 2005-03-11 at 13:24 -0500, Jeff Johnson wrote:
> On Fri, Mar 11, 2005 at 02:15:18PM +0200, Ville Skytt? wrote:
> > On Thu, 2005-03-10 at 16:06 -0500, Tim Powers wrote:
> > > On Mar 10, 2005, at 3:56 PM, Nils Philippsen wrote:
> > >
> > > >
> > > > Don't "PreReq:" (which gets treated like a simple "Requires:" IIRC),
> >
> > Almost. In case of circular dependencies, PreReq "wins" over Requires.
> > In the vast majority of cases (ie. when there are no circular
> > dependencies), they're equivalent, and rpm will do the right thing at
> > install time.
>
> No no no no no no no no!
>
> There is literally no difference between PreReq: and Requires:, rpm-4.4
> and beyond is incapable of either setting or testing RPMSENSE_PREREQ.
Good to hear this has happened in rpm >= 4.4, thanks. However, all
versions of rpm in _shipped, non-test_ FC versions as of now
(IOW rpm <= 4.3.2) do make the distinction I described above, right?
> > AFAIK, erasure ordering is still unimplemented though, and the only
> > thing a packager can do is to "manually" take that into account in
> > specfiles where necessary.
>
> Erasure ordering has always been implemented as the reverse of
> install ordering., so "unimplemented" is more FUD.
FUD or not, I did not invent that. Quoting you from some 2 years ago,
rpm-4.[12] days (which is less than "always", I presume), both reports
CLOSED DEFERRED:
https://bugzilla.redhat.com/89740
- "Yup, rpm does not do erasure ordering."
- "Not implemented means exactly that."
https://bugzilla.redhat.com/89500
- "Ah yes, erase ordering has never been implemented in rpm."
From skvidal at phy.duke.edu Sun Mar 13 18:19:25 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Sun, 13 Mar 2005 13:19:25 -0500
Subject: mach questions
Message-ID: <1110737965.30233.28.camel@cutter>
I'm rebuilding some items for fc4t1 and I'm running into:
checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
error: Bad exit status from /var/tmp/rpm-tmp.96910 (%build)
Is this a gcc4ism? Does the package need to be fixed for this?
-sv
From dwmw2 at infradead.org Mon Mar 14 01:40:27 2005
From: dwmw2 at infradead.org (David Woodhouse)
Date: Sun, 13 Mar 2005 18:40:27 -0700
Subject: STR working out of the box
In-Reply-To: <1110698182.8327.69.camel@daxter.boston.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
Message-ID: <1110764428.9249.63.camel@localhost.localdomain>
On Sun, 2005-03-13 at 02:16 -0500, David Zeuthen wrote:
> As ACPI suspend-to-ram (S3) seems to work for more and more people as
> the kernel improves, I've written some code/scripts to make it work
> better out of the box as, ideally, this should be zero configuration,
> e.g., if it's supported, it should "Just Work".
STR works very nicely on my PowerBook. I currently use apmud to trigger
a suspend on lid event, etc. That should die and be replaced with a
machine-agnostic mechanism and event/response configuration. Please make
sure whatever you develop _is_ machine-agnostic.
--
dwmw2
From bnocera at redhat.com Mon Mar 14 10:29:12 2005
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 14 Mar 2005 10:29:12 +0000
Subject: mach questions
In-Reply-To: <1110737965.30233.28.camel@cutter>
References: <1110737965.30233.28.camel@cutter>
Message-ID: <1110796153.6823.21.camel@bnocera.surrey.redhat.com>
On Sun, 2005-03-13 at 13:19 -0500, seth vidal wrote:
> I'm rebuilding some items for fc4t1 and I'm running into:
>
> checking how to run the C++ preprocessor... /lib/cpp
> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> error: Bad exit status from /var/tmp/rpm-tmp.96910 (%build)
>
>
> Is this a gcc4ism? Does the package need to be fixed for this?
Have you actually checked that cpp is installed and working? Last this
sort of thing happened to me, it wasn't actually properly installed (ie.
not at all), only the link was there.
--
Bastien Nocera
From bnocera at redhat.com Mon Mar 14 10:50:13 2005
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 14 Mar 2005 10:50:13 +0000
Subject: STR working out of the box
In-Reply-To: <1110698182.8327.69.camel@daxter.boston.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
Message-ID: <1110797413.6823.32.camel@bnocera.surrey.redhat.com>
Hey David,
On Sun, 2005-03-13 at 02:16 -0500, David Zeuthen wrote:
> Hey,
> On http://people.redhat.com/davidz/suspend/ you should find SRPMs and
> i386 RPMS for
>
> vbetool-0.2 - Tool for run real-mode video BIOS code to alter
> hardware state
> powermgmt-001 - ACPI S3 suspend script, configuration file and
> lid event script for acpid
> hal-0.5.0.cvs20050312 - new version of hal to cope with whitelist data
> (see below)
Cool stuff. I'll need to try and see if vbetool works as well as the
hacky, very specific "video_post" tool I currently use.
> Here are fairly difficult questions/issues:
>
> 2. I've assumed that there are no regressions in the kernel; e.g.
> if ACPI S3 sleep works in kernel X for a system Y then it also
> works in kernel Z for system Y given that Z >= X. I don't
> really know enough linux-acpi history if this is a good assumption?
DaveJ already replied on that one. I'm lucky enough that regression
didn't last for more than one release for me.
> 4. ditto for rmmod; modules should never never be unloaded or
> so the core kernel guys says.
What's the current policy on this? On my laptop (again), none of the
modules need to be unloaded. I wouldn't want the network, the sound, or
something else being unloaded if it didn't have to. And I really think
that those scripts should never do that unless the user added the
modules as to be removed. Those drivers are broken and should be fixed.
> 6. Sometimes suspend fails for me because the mDNSResponder
> service wasn't stopped:
>
> Mar 13 01:33:32 daxter kernel: stopping tasks failed (1 tasks remaining)
> Mar 13 01:33:32 daxter kernel: Restarting tasks...<6> Strange, mDNSResponder not stopped
>
> Some of the other distro/upstream scripts have a list of
> services to stop. I've seen mysql there too. Euhw.
Wouldn't it be a better idea to check why on earth it stays running?
I've seen that one as well...
> 7. There is a TODO to shutdown networking completely as some
> network drivers refuse to be unloaded otherwise - even if
> the drivers were to be fixed we'd probably want this anyway
> in a NetworkManager world
Crappy drivers, should be fixed.
I don't think that unloading drivers should be the default, ever,
otherwise bugs don't get filed, bugs don't get fixed, problems still
occur, and applications break ("Oooh, let's kill all the apps using the
sound device because the sound driver's crap").
Keep on the good work.
--
Bastien Nocera
From bnocera at redhat.com Mon Mar 14 10:54:35 2005
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 14 Mar 2005 10:54:35 +0000
Subject: STR working out of the box
In-Reply-To: <1110797413.6823.32.camel@bnocera.surrey.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<1110797413.6823.32.camel@bnocera.surrey.redhat.com>
Message-ID: <1110797675.6823.36.camel@bnocera.surrey.redhat.com>
On Mon, 2005-03-14 at 10:50 +0000, Bastien Nocera wrote:
> Hey David,
>
> On Sun, 2005-03-13 at 02:16 -0500, David Zeuthen wrote:
> > Hey,
>
> > On http://people.redhat.com/davidz/suspend/ you should find SRPMs and
> > i386 RPMS for
> >
> > vbetool-0.2 - Tool for run real-mode video BIOS code to alter
> > hardware state
> > powermgmt-001 - ACPI S3 suspend script, configuration file and
> > lid event script for acpid
> > hal-0.5.0.cvs20050312 - new version of hal to cope with whitelist data
> > (see below)
>
> Cool stuff. I'll need to try and see if vbetool works as well as the
> hacky, very specific "video_post" tool I currently use.
I forgot to add that I hope your script takes into account for weird
hardware (yay! my laptop again). Even under Windows it behaves very
bizarrely because it generates a close lid event, but will only wake up
with a key press, not generating any lid open event, as the machine was
sleeping when the lid was opened again.
(Under Windows, the machine will go to sleep after closing the lid, and
re-opening it, very useful to get a depleted battery).
--
Bastien Nocera
From bnocera at redhat.com Mon Mar 14 16:50:18 2005
From: bnocera at redhat.com (Bastien Nocera)
Date: Mon, 14 Mar 2005 16:50:18 +0000
Subject: GConf schema packaging guidelines
In-Reply-To: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
References: <1109706164.23341.7.camel@cassandra.boston.redhat.com>
Message-ID: <1110819018.6823.53.camel@bnocera.surrey.redhat.com>
On Tue, 2005-03-01 at 14:42 -0500, David Malcolm wrote:
> How should we be dealing with GConf schema in spec files?
> Can we have an RPM macro instead?
This is one of the pains of writing .spec files for RPM packages. That's
one of the good things in debian packages (the "dh_*" deb-helpers).
Can't rpm read macros that some packages could add in a directory? The
GConf2-devel could add some macros to handle schemas...
--
Bastien Nocera
From notting at redhat.com Mon Mar 14 16:52:23 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 14 Mar 2005 11:52:23 -0500
Subject: Purge Fedora updates
In-Reply-To: <42336F13.3000706@redhat.com>
References: <42336F13.3000706@redhat.com>
Message-ID: <20050314165223.GC10338@nostromo.devel.redhat.com>
Warren Togami (wtogami at redhat.com) said:
> Can we purge the Fedora updates again?
Again? It's done automatically.
Bill
From adrian at lisas.de Mon Mar 14 17:05:25 2005
From: adrian at lisas.de (Adrian Reber)
Date: Mon, 14 Mar 2005 18:05:25 +0100
Subject: mach questions
In-Reply-To: <1110737965.30233.28.camel@cutter>
References: <1110737965.30233.28.camel@cutter>
Message-ID: <20050314170525.GA21457@lisas.de>
On Sun, Mar 13, 2005 at 01:19:25PM -0500, seth vidal wrote:
> I'm rebuilding some items for fc4t1 and I'm running into:
>
> checking how to run the C++ preprocessor... /lib/cpp
> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> error: Bad exit status from /var/tmp/rpm-tmp.96910 (%build)
>
> Is this a gcc4ism? Does the package need to be fixed for this?
I get the same error but in a completely different situation. I have a
FC-3 chroot on a rawhide system. I have to install gcc-c++ to fix it.
Maybe this helps you.
Adrian
From notting at redhat.com Mon Mar 14 17:04:48 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 14 Mar 2005 12:04:48 -0500
Subject: STR working out of the box
In-Reply-To: <1110698182.8327.69.camel@daxter.boston.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
Message-ID: <20050314170448.GE10338@nostromo.devel.redhat.com>
David Zeuthen (davidz at redhat.com) said:
> When and if your system finally resumes you should see a blurb similar
> to this:
>
> Generating HAL device information file..
>
> Generated HAL device information file for whitelist
>
> ==== BEGIN CUT ====
>
>
>
>
>
>
>
>
>
>
>
> true
> mem
>
>
>
>
>
>
>
> ==== END CUT ====
>
> TODO: Prompt user to interactively submit this file to RH Bugzilla
>
> This is a hal device information file that should be submitted upstream
> so other users, that use the same hardware, can suspend out of the box
> too (<-- that's the answer to the Q above :->). As it should be evident
> from the XML, we match on
>
> - ACPI version must be as new as on the test box
> - kernel must be as new as on the test box
> - The manufacturer name (from dmidecode)
> - The product name (from dmidecode)
>
> and if this matches, we put the same values in the hal device
> information as the ones that worked in the /etc/suspend.conf file
>
> (If you study /usr/sbin/suspend.sh, you will see that this script
> queries HAL for these properties and replaces them if appropriate.
These files will become rapidly obsolete as the kernel fixes bugs,
drivers change names, etc. How do you handle updates and verifications?
Do we push a new RPM every week?
(As I've stated before, I think a whitelist is crack. :) )
> 1. I've assumed that "ACPI S3 sleep works" is tied to what kind of
> system it is; I use SMBIOS values (and the SMBIOS may lie!) as
> keys; are there better keys (such as `md5sum /proc/acpi/dsdt`)
> or is the assumption totally wrong?
It's tied to the system, kernel version, hardware type, and BIOS
version.
> 2. I've assumed that there are no regressions in the kernel; e.g.
> if ACPI S3 sleep works in kernel X for a system Y then it also
> works in kernel Z for system Y given that Z >= X. I don't
> really know enough linux-acpi history if this is a good assumption?
No. But it keeps the kernel people on their toes.
> 3. vbetool is kind of evil; it's a workaround for broken video
> drivers and the mess that is X.org / kernel interaction wrt.
> to video hardware (so, vbetool becomes the 3th or 4th player
> directly touching hardware. Yay!). I expect we need to add
> radeontool at some point too.
Note that vbetool is only for certain cards. There are other tools
for other cards.
> 5. I've assumed that the list of modules to unload is also tied
> to the system, but isn't it more tied to the current kernel
> version?
'Version of the code in the modules, along with the PM layer.'
> 6. Sometimes suspend fails for me because the mDNSResponder
> service wasn't stopped:
>
> Mar 13 01:33:32 daxter kernel: stopping tasks failed (1 tasks remaining)
> Mar 13 01:33:32 daxter kernel: Restarting tasks...<6> Strange, mDNSResponder not stopped
>
> Some of the other distro/upstream scripts have a list of
> services to stop. I've seen mysql there too. Euhw.
Read apmscript. Cry at the horror.
> In light of this: is it too dangerous, at this point, to enable this per
> default given we use the white lists as discussed above? Should we
> rather wait for the kernel/X.org to get fixed? (no, I'm not trolling
> here, I'm being serious actually)
I'd just enable it without the whitelist, personally.
Bill
From notting at redhat.com Mon Mar 14 17:07:47 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 14 Mar 2005 12:07:47 -0500
Subject: STR working out of the box
In-Reply-To: <1110797413.6823.32.camel@bnocera.surrey.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<1110797413.6823.32.camel@bnocera.surrey.redhat.com>
Message-ID: <20050314170747.GF10338@nostromo.devel.redhat.com>
Bastien Nocera (bnocera at redhat.com) said:
> > 7. There is a TODO to shutdown networking completely as some
> > network drivers refuse to be unloaded otherwise - even if
> > the drivers were to be fixed we'd probably want this anyway
> > in a NetworkManager world
>
> Crappy drivers, should be fixed.
>
> I don't think that unloading drivers should be the default, ever,
> otherwise bugs don't get filed, bugs don't get fixed, problems still
> occur, and applications break ("Oooh, let's kill all the apps using the
> sound device because the sound driver's crap").
Agree 1000%.
Bill
From bugs.michael at gmx.net Mon Mar 14 17:11:36 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Mon, 14 Mar 2005 18:11:36 +0100
Subject: mach questions
In-Reply-To: <1110737965.30233.28.camel@cutter>
References: <1110737965.30233.28.camel@cutter>
Message-ID: <20050314181136.1db7df80.bugs.michael@gmx.net>
On Sun, 13 Mar 2005 13:19:25 -0500, seth vidal wrote:
> I'm rebuilding some items for fc4t1 and I'm running into:
>
> checking how to run the C++ preprocessor... /lib/cpp
> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> error: Bad exit status from /var/tmp/rpm-tmp.96910 (%build)
>
>
> Is this a gcc4ism? Does the package need to be fixed for this?
Unless something has changed, it's a machism, as mach doesn't
install gcc-c++ in its default build environment.
From dcbw at redhat.com Mon Mar 14 17:44:36 2005
From: dcbw at redhat.com (Dan Williams)
Date: Mon, 14 Mar 2005 12:44:36 -0500
Subject: Purge Fedora updates
In-Reply-To: <20050314165223.GC10338@nostromo.devel.redhat.com>
References: <42336F13.3000706@redhat.com>
<20050314165223.GC10338@nostromo.devel.redhat.com>
Message-ID: <1110822276.29531.17.camel@dcbw.boston.redhat.com>
On Mon, 2005-03-14 at 11:52 -0500, Bill Nottingham wrote:
> Warren Togami (wtogami at redhat.com) said:
> > Can we purge the Fedora updates again?
>
> Again? It's done automatically.
Then it seems not to be working. From download.fedora.devel.redhat.com
in fc3-updates:
[ ] openoffice.org-1.1.2-11.5.fc3.i386.rpm 10-Nov-2004 12:49 43M
[ ] openoffice.org-1.1.3-2.5.fc3.i386.rpm 26-Jan-2005 16:57 34M
[ ] openoffice.org-1.1.3-5.5.0.fc3.i386.rpm 11-Feb-2005 15:14 34M
[ ] openoffice.org-1.1.3-6.5.0.fc3.i386.rpm 14-Feb-2005 13:01 34M
[ ] openoffice.org-1.1.3-9.5.0.fc3.i386.rpm 11-Mar-2005 13:19 34M
That's a pretty old version of OOo :)
Dan
From skvidal at phy.duke.edu Mon Mar 14 17:48:54 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 14 Mar 2005 12:48:54 -0500
Subject: mach questions
In-Reply-To: <20050314170525.GA21457@lisas.de>
References: <1110737965.30233.28.camel@cutter>
<20050314170525.GA21457@lisas.de>
Message-ID: <1110822534.23972.9.camel@opus.phy.duke.edu>
On Mon, 2005-03-14 at 18:05 +0100, Adrian Reber wrote:
> On Sun, Mar 13, 2005 at 01:19:25PM -0500, seth vidal wrote:
> > I'm rebuilding some items for fc4t1 and I'm running into:
> >
> > checking how to run the C++ preprocessor... /lib/cpp
> > configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> > error: Bad exit status from /var/tmp/rpm-tmp.96910 (%build)
> >
> > Is this a gcc4ism? Does the package need to be fixed for this?
>
> I get the same error but in a completely different situation. I have a
> FC-3 chroot on a rawhide system. I have to install gcc-c++ to fix it.
> Maybe this helps you.
yah - I got it fixed up - it was just a screw up.
thanks
-sv
From skvidal at phy.duke.edu Mon Mar 14 17:49:36 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 14 Mar 2005 12:49:36 -0500
Subject: mach questions
In-Reply-To: <20050314181136.1db7df80.bugs.michael@gmx.net>
References: <1110737965.30233.28.camel@cutter>
<20050314181136.1db7df80.bugs.michael@gmx.net>
Message-ID: <1110822576.23972.11.camel@opus.phy.duke.edu>
> Unless something has changed, it's a machism, as mach doesn't
> install gcc-c++ in its default build environment.
>
yah. But the mach packages I released yesterday do install a larger
build environment now. :)
-sv
From notting at redhat.com Mon Mar 14 20:46:17 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 14 Mar 2005 15:46:17 -0500
Subject: Purge Fedora updates
In-Reply-To: <1110822276.29531.17.camel@dcbw.boston.redhat.com>
References: <42336F13.3000706@redhat.com>
<20050314165223.GC10338@nostromo.devel.redhat.com>
<1110822276.29531.17.camel@dcbw.boston.redhat.com>
Message-ID: <20050314204617.GB20780@nostromo.devel.redhat.com>
Dan Williams (dcbw at redhat.com) said:
> > Again? It's done automatically.
>
> Then it seems not to be working. From download.fedora.devel.redhat.com
> in fc3-updates:
>
> [ ] openoffice.org-1.1.2-11.5.fc3.i386.rpm 10-Nov-2004 12:49 43M
> [ ] openoffice.org-1.1.3-2.5.fc3.i386.rpm 26-Jan-2005 16:57 34M
> [ ] openoffice.org-1.1.3-5.5.0.fc3.i386.rpm 11-Feb-2005 15:14 34M
> [ ] openoffice.org-1.1.3-6.5.0.fc3.i386.rpm 14-Feb-2005 13:01 34M
> [ ] openoffice.org-1.1.3-9.5.0.fc3.i386.rpm 11-Mar-2005 13:19 34M
OK, so the algorithm is pretty simple.
Once a new update goes out, after 28 days older updates are removed.
The problem is each new OOo update is resetting the clock....
Bill
From skvidal at phy.duke.edu Mon Mar 14 20:48:31 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Mon, 14 Mar 2005 15:48:31 -0500
Subject: Purge Fedora updates
In-Reply-To: <20050314204617.GB20780@nostromo.devel.redhat.com>
References: <42336F13.3000706@redhat.com>
<20050314165223.GC10338@nostromo.devel.redhat.com>
<1110822276.29531.17.camel@dcbw.boston.redhat.com>
<20050314204617.GB20780@nostromo.devel.redhat.com>
Message-ID: <1110833311.23972.56.camel@opus.phy.duke.edu>
On Mon, 2005-03-14 at 15:46 -0500, Bill Nottingham wrote:
> Dan Williams (dcbw at redhat.com) said:
> > > Again? It's done automatically.
> >
> > Then it seems not to be working. From download.fedora.devel.redhat.com
> > in fc3-updates:
> >
> > [ ] openoffice.org-1.1.2-11.5.fc3.i386.rpm 10-Nov-2004 12:49 43M
> > [ ] openoffice.org-1.1.3-2.5.fc3.i386.rpm 26-Jan-2005 16:57 34M
> > [ ] openoffice.org-1.1.3-5.5.0.fc3.i386.rpm 11-Feb-2005 15:14 34M
> > [ ] openoffice.org-1.1.3-6.5.0.fc3.i386.rpm 14-Feb-2005 13:01 34M
> > [ ] openoffice.org-1.1.3-9.5.0.fc3.i386.rpm 11-Mar-2005 13:19 34M
>
> OK, so the algorithm is pretty simple.
>
> Once a new update goes out, after 28 days older updates are removed.
> The problem is each new OOo update is resetting the clock....
>
How about we change the algorithm a bit:
latest 2 versions or less than 28days old.
-sv
From notting at redhat.com Mon Mar 14 21:49:58 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 14 Mar 2005 16:49:58 -0500
Subject: Purge Fedora updates
In-Reply-To: <1110833311.23972.56.camel@opus.phy.duke.edu>
References: <42336F13.3000706@redhat.com>
<20050314165223.GC10338@nostromo.devel.redhat.com>
<1110822276.29531.17.camel@dcbw.boston.redhat.com>
<20050314204617.GB20780@nostromo.devel.redhat.com>
<1110833311.23972.56.camel@opus.phy.duke.edu>
Message-ID: <20050314214958.GA12276@nostromo.devel.redhat.com>
seth vidal (skvidal at phy.duke.edu) said:
> > > [ ] openoffice.org-1.1.2-11.5.fc3.i386.rpm 10-Nov-2004 12:49 43M
> > > [ ] openoffice.org-1.1.3-2.5.fc3.i386.rpm 26-Jan-2005 16:57 34M
> > > [ ] openoffice.org-1.1.3-5.5.0.fc3.i386.rpm 11-Feb-2005 15:14 34M
> > > [ ] openoffice.org-1.1.3-6.5.0.fc3.i386.rpm 14-Feb-2005 13:01 34M
> > > [ ] openoffice.org-1.1.3-9.5.0.fc3.i386.rpm 11-Mar-2005 13:19 34M
> >
> > OK, so the algorithm is pretty simple.
> >
> > Once a new update goes out, after 28 days older updates are removed.
> > The problem is each new OOo update is resetting the clock....
> >
>
> How about we change the algorithm a bit:
>
> latest 2 versions or less than 28days old.
Changed to compare the 28 day clock against all released updates,
not just the newest one. This should clean things up significantly.
Bill
From sgrubb at redhat.com Mon Mar 14 21:56:03 2005
From: sgrubb at redhat.com (Steve Grubb)
Date: Mon, 14 Mar 2005 16:56:03 -0500
Subject: Purge Fedora updates
In-Reply-To: <20050314214958.GA12276@nostromo.devel.redhat.com>
References: <42336F13.3000706@redhat.com>
<1110833311.23972.56.camel@opus.phy.duke.edu>
<20050314214958.GA12276@nostromo.devel.redhat.com>
Message-ID: <200503141656.03981.sgrubb@redhat.com>
On Monday 14 March 2005 16:49, Bill Nottingham wrote:
> Changed to compare the 28 day clock against all released updates,
> not just the newest one.
Of the same package?
-Steve Grubb
From notting at redhat.com Mon Mar 14 21:56:43 2005
From: notting at redhat.com (Bill Nottingham)
Date: Mon, 14 Mar 2005 16:56:43 -0500
Subject: Purge Fedora updates
In-Reply-To: <200503141656.03981.sgrubb@redhat.com>
References: <42336F13.3000706@redhat.com>
<1110833311.23972.56.camel@opus.phy.duke.edu>
<20050314214958.GA12276@nostromo.devel.redhat.com>
<200503141656.03981.sgrubb@redhat.com>
Message-ID: <20050314215643.GA12407@nostromo.devel.redhat.com>
Steve Grubb (sgrubb at redhat.com) said:
> On Monday 14 March 2005 16:49, Bill Nottingham wrote:
> > Changed to compare the 28 day clock against all released updates,
> > not just the newest one.
>
> Of the same package?
(package, arch), actually.
Bill
From jbj at redhat.com Mon Mar 14 22:23:04 2005
From: jbj at redhat.com (Jeff Johnson)
Date: Mon, 14 Mar 2005 17:23:04 -0500
Subject: note about packaging init scripts
In-Reply-To: <20050312133615.GL15511@redhat.com>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
<9dd35777c324cdcfc58600c3d0649078@redhat.com>
<1110543318.2786.34.camel@bobcat.mine.nu>
<20050311182412.GV9722@devserv.devel.redhat.com>
<20050312133615.GL15511@redhat.com>
Message-ID: <20050314222304.GY9722@devserv.devel.redhat.com>
On Sat, Mar 12, 2005 at 01:36:15PM +0000, Tim Waugh wrote:
> On Fri, Mar 11, 2005 at 01:24:12PM -0500, Jeff Johnson wrote:
>
> > Meanwhile, what needs to be done is automate the identification of
> > scriptlet dependencies by resurrecting the patch to bash from RHL 6.2.
> > That's my opinion anyways.
>
> The patch never went away. bash --rpm-requires is still
> there. (Whether it still works, of course, is another question..)
>
Ooooh, you just made my day! I thought the patch long since dropped, was
not looking forward to trying to resurrect.
Thank you! Even more than cleaning up the automake spewage! ;-)
todo++, automating scriptlet dependencies is as simple as running
the scriptlet through bash with some filtering on output, rpm
automagic dependency extraction will take care of the rest.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC
From davidz at redhat.com Tue Mar 15 06:21:35 2005
From: davidz at redhat.com (David Zeuthen)
Date: Tue, 15 Mar 2005 01:21:35 -0500
Subject: STR working out of the box
In-Reply-To: <20050313081221.GC25814@redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<20050313081221.GC25814@redhat.com>
Message-ID: <1110867695.14869.177.camel@daxter.boston.redhat.com>
Hi,
sorry for the slowness,
On Sun, 2005-03-13 at 03:12 -0500, Dave Jones wrote:
> I'll warn you now, that there will be kernel bugs. Whether anyone
> gets to fixing them in any short amount of time is something that
> I wouldn't like to place odds on. I'd love it if suspend/resume
> worked on more systems, however it's something of a black art
> chasing down problems related to this issue.
Yah, I guess we shouldn't bother with white lists then, it was only a
few hours of hacking anyway :-).
I'd love, though, to have some easy-to-configure scripts (like the
suspend.sh script I've sent) shipped in the distro (even with
questionable tools such as vbetool).
> My laptop for instance
> suspends just fine. Resume however looks just like I powered it on
> for the first time. I've written this off as 'BIOS bug', and don't
> ever expect it to work. Some of our users however won't see things
> the same way because "Windows works fine".
It all comes down to managing users expectations, really. I suppose to
achieve as good coverage as Windows we'd need to be bug-by-bug
compatible as I understand that the Windows driver, acpi.sys or
something, is a generic one...
David
From davidz at redhat.com Tue Mar 15 06:25:34 2005
From: davidz at redhat.com (David Zeuthen)
Date: Tue, 15 Mar 2005 01:25:34 -0500
Subject: STR working out of the box
In-Reply-To: <423421DE.2050403@redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<423421DE.2050403@redhat.com>
Message-ID: <1110867934.14869.182.camel@daxter.boston.redhat.com>
On Sun, 2005-03-13 at 01:19 -1000, Warren Togami wrote:
> More ugly hacks...
>
> /sbin/hwclock --systohc /sbin/hwclock --hctosys
>
> Would it be appropriate to include these pair of commands in the
> suspend.sh in order to avoid time clock screwage?
Yeah, I guess.
> One more question...
> suspend-checklid.sh assumes that all users *always* wants suspend if the
> LID is closed. I am assuming this will eventually be configurable
> easily from the desktop, but will it default this way?
Well, for the FC5 time frame I hope we can ship something like described
here
http://live.gnome.org/ProjectUtopia_2fPowerManagement
http://live.gnome.org/ProjectUtopia_2fPowerManagement_2fPreferences
http://live.gnome.org/ProjectUtopia_2fPowerManagement_2fgnome_2dpower_2dmanager
(though clarkbw seems to hate the dialog :-)
and the good thing is that someone is already working it :-)
For FC4 I suppose we can patch battstat-applet to do something sane per
default.
Cheers,
David
From davidz at redhat.com Tue Mar 15 06:34:19 2005
From: davidz at redhat.com (David Zeuthen)
Date: Tue, 15 Mar 2005 01:34:19 -0500
Subject: STR working out of the box
In-Reply-To: <1110797413.6823.32.camel@bnocera.surrey.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<1110797413.6823.32.camel@bnocera.surrey.redhat.com>
Message-ID: <1110868460.14869.192.camel@daxter.boston.redhat.com>
On Mon, 2005-03-14 at 10:50 +0000, Bastien Nocera wrote:
>
> > 6. Sometimes suspend fails for me because the mDNSResponder
> > service wasn't stopped:
> >
> > Mar 13 01:33:32 daxter kernel: stopping tasks failed (1 tasks remaining)
> > Mar 13 01:33:32 daxter kernel: Restarting tasks...<6> Strange, mDNSResponder not stopped
> >
> > Some of the other distro/upstream scripts have a list of
> > services to stop. I've seen mysql there too. Euhw.
>
> Wouldn't it be a better idea to check why on earth it stays running?
> I've seen that one as well...
I certainly don't disagree here! FWIW, I saw a patch on acpi-devel for
that the other day re: mysql. My hacking with hal tells me also that if
you have processes in state D the suspend will always fail (usb-storage
likes to hang processes especially for, uhm, crappy USB2 card readers).
So it looks to me like there's some architectural problems in the kernel
also, though I could be wrong.
> > 7. There is a TODO to shutdown networking completely as some
> > network drivers refuse to be unloaded otherwise - even if
> > the drivers were to be fixed we'd probably want this anyway
> > in a NetworkManager world
>
> Crappy drivers, should be fixed.
>
> I don't think that unloading drivers should be the default, ever,
> otherwise bugs don't get filed, bugs don't get fixed, problems still
> occur, and applications break ("Oooh, let's kill all the apps using the
> sound device because the sound driver's crap").
Right.
In another mail you wrote:
> I forgot to add that I hope your script takes into account for weird
> hardware (yay! my laptop again). Even under Windows it behaves very
> bizarrely because it generates a close lid event, but will only wake
> up
> with a key press, not generating any lid open event, as the machine
> was
> sleeping when the lid was opened again.
It's probably difficult to fine tune with things like acpid but in the
star trek future where all policy is enforced from e.g. gnome-power-
manager we should be able to do the right thing.
Cheers,
David
From davidz at redhat.com Tue Mar 15 06:34:19 2005
From: davidz at redhat.com (David Zeuthen)
Date: Tue, 15 Mar 2005 01:34:19 -0500
Subject: STR working out of the box
In-Reply-To: <1110797413.6823.32.camel@bnocera.surrey.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<1110797413.6823.32.camel@bnocera.surrey.redhat.com>
Message-ID: <1110868460.14869.192.camel@daxter.boston.redhat.com>
On Mon, 2005-03-14 at 10:50 +0000, Bastien Nocera wrote:
>
> > 6. Sometimes suspend fails for me because the mDNSResponder
> > service wasn't stopped:
> >
> > Mar 13 01:33:32 daxter kernel: stopping tasks failed (1 tasks remaining)
> > Mar 13 01:33:32 daxter kernel: Restarting tasks...<6> Strange, mDNSResponder not stopped
> >
> > Some of the other distro/upstream scripts have a list of
> > services to stop. I've seen mysql there too. Euhw.
>
> Wouldn't it be a better idea to check why on earth it stays running?
> I've seen that one as well...
I certainly don't disagree here! FWIW, I saw a patch on acpi-devel for
that the other day re: mysql. My hacking with hal tells me also that if
you have processes in state D the suspend will always fail (usb-storage
likes to hang processes especially for, uhm, crappy USB2 card readers).
So it looks to me like there's some architectural problems in the kernel
also, though I could be wrong.
> > 7. There is a TODO to shutdown networking completely as some
> > network drivers refuse to be unloaded otherwise - even if
> > the drivers were to be fixed we'd probably want this anyway
> > in a NetworkManager world
>
> Crappy drivers, should be fixed.
>
> I don't think that unloading drivers should be the default, ever,
> otherwise bugs don't get filed, bugs don't get fixed, problems still
> occur, and applications break ("Oooh, let's kill all the apps using the
> sound device because the sound driver's crap").
Right.
In another mail you wrote:
> I forgot to add that I hope your script takes into account for weird
> hardware (yay! my laptop again). Even under Windows it behaves very
> bizarrely because it generates a close lid event, but will only wake
> up
> with a key press, not generating any lid open event, as the machine
> was
> sleeping when the lid was opened again.
It's probably difficult to fine tune with things like acpid but in the
star trek future where all policy is enforced from e.g. gnome-power-
manager we should be able to do the right thing.
Cheers,
David
From davidz at redhat.com Tue Mar 15 06:44:04 2005
From: davidz at redhat.com (David Zeuthen)
Date: Tue, 15 Mar 2005 01:44:04 -0500
Subject: STR working out of the box
In-Reply-To: <20050314170448.GE10338@nostromo.devel.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<20050314170448.GE10338@nostromo.devel.redhat.com>
Message-ID: <1110869044.14869.201.camel@daxter.boston.redhat.com>
On Mon, 2005-03-14 at 12:04 -0500, Bill Nottingham wrote:
> (As I've stated before, I think a whitelist is crack. :) )
Yah.
> > 3. vbetool is kind of evil; it's a workaround for broken video
> > drivers and the mess that is X.org / kernel interaction wrt.
> > to video hardware (so, vbetool becomes the 3th or 4th player
> > directly touching hardware. Yay!). I expect we need to add
> > radeontool at some point too.
>
> Note that vbetool is only for certain cards. There are other tools
> for other cards.
Apart from radeontool?
> Read apmscript. Cry at the horror.
I had to wear sunglasses.
>
> > In light of this: is it too dangerous, at this point, to enable this per
> > default given we use the white lists as discussed above? Should we
> > rather wait for the kernel/X.org to get fixed? (no, I'm not trolling
> > here, I'm being serious actually)
>
> I'd just enable it without the whitelist, personally.
Care to maintain the package and handle all the bug reports and angry
users then? :-)
Personally I think that the only sensible thing is to disable it per
default and require users to open a terminal (whoops, we just 50% of the
users), find the /etc/suspend.conf file (/me wonders how many we lost
there), have them figure out the options for suspend (there goes another
~50%), pray that it works (maybe it works for 65%) and make them really
hope the next kernel doesn't break. Lather, Rinse, Repeat. [1]
Cheers,
David
[1] : the percentages above are ca. 95% wrong
From jbj at redhat.com Tue Mar 15 15:16:40 2005
From: jbj at redhat.com (Jeff Johnson)
Date: Tue, 15 Mar 2005 10:16:40 -0500
Subject: note about packaging init scripts
In-Reply-To: <1110733932.2786.132.camel@bobcat.mine.nu>
References: <20050310194258.GA5034@nostromo.devel.redhat.com>
<1110488211.7950.4.camel@wombat.tiptoe.de>
<9dd35777c324cdcfc58600c3d0649078@redhat.com>
<1110543318.2786.34.camel@bobcat.mine.nu>
<20050311182412.GV9722@devserv.devel.redhat.com>
<1110733932.2786.132.camel@bobcat.mine.nu>
Message-ID: <20050315151640.GZ9722@devserv.devel.redhat.com>
On Sun, Mar 13, 2005 at 07:12:12PM +0200, Ville Skytt? wrote:
>
> FUD or not, I did not invent that. Quoting you from some 2 years ago,
> rpm-4.[12] days (which is less than "always", I presume), both reports
> CLOSED DEFERRED:
>
> https://bugzilla.redhat.com/89740
> - "Yup, rpm does not do erasure ordering."
> - "Not implemented means exactly that."
>
> https://bugzilla.redhat.com/89500
> - "Ah yes, erase ordering has never been implemented in rpm."
>
>From context, one is supposed to infer "correctly.", as in
rpm does not do erasure order sufficiently correctly.
No matter what, there is an implementation, erasure ordering is
the reverse of install ordering. That turns out not to be sufficiently
correct.
The final answer will be to incorporate the ordering from the
smart package manager into rpm. Gustavo was wise enough to
realize that a dependency graph should label nodes as "package-operation"
rather than "package", thereby permitting explicit tsort relations like
Order "package-install" before "package-erase".
There are other ramifications too.
Meanwhile, as we all know, no one has ever bothered to set up the
necessary QA to insure that erasures, indeed, are well tracked by
dependencies, mainly because install/upgrade, not erasure, is
what is mainly of interest.
Meanwhile, now thanks to Tim Waugh's careful maintenance of bash
over the years, the syntactical sugar of Requires(post): et al can
be automated, removing Yet Another error prone process adding
dependencies to *.spec files.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC
From ville.skytta at iki.fi Tue Mar 15 18:03:45 2005
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Tue, 15 Mar 2005 20:03:45 +0200
Subject: RFD: kernel-devel package improvements
Message-ID: <1110909825.26174.173.camel@bobcat.mine.nu>
Warning: lengthy mail.
Once again, here's a request for discussion about the current kernel-
devel packages, and improving them to better meet the requirements of
module packagers. As suggested by wtogami in private mail (and agreed
by riel, if I understand correctly), let's try on this list in order to
avoid too much noise which has been the problem with earlier kernel-
source/devel discussions on fedora-devel.
The kernel-devel packages currently in Rawhide are a good step towards
general usefulness, but they partially fail to implement what they've
been designed for, and there is room for improvements. Rik has agreed
to follow this discussion and assist in evaluating and getting the
improvements applied if we can come up with something sane here. Based
on Bugzilla traffic, I see he's already working on some of the issues
below.
Because I'm starting this discussion, I'll present my own biased,
lengthy POV first. Be encouraged to comment, disagree and fill in the
blanks. I'm focusing on the kernel-devel packages, not things like
module package naming; let's get the framework ready first. I'm more
describing what I would consider "ideal", with less focus on backwards
compatibility issues or build system constraints.
Short version: I would like to more use of "uname -r" output in the
provisions and naming in general, and a single big kernel-devel package
for each archtecture "group", using (sym|hard) links in order to save
space for common files. One example of one (fictious) arch group would
be eg. {i586,i686}{,smp,xen0,xenU}, all of the above in a single
kernel-devel rpm, possibly noarch or i386 (although that might be tricky
to implement). One example of the space-saving linking is in the
fedora.us/livna.org kernel-module-devel packages (<= FC3 only), see
http://cvs.fedora.us/cgi-bin/cvsweb.cgi/pkg/kernel-module-devel/
The end of this message contains a pseudo-module-specfile snippet
describing one approach how a module specfile could depend on stuff and
locate dirs, as well as a kernel specfile patch for
documentation/clarification purposes. For the long version, read on.
Requirement categories: in order to be really useful for module
packagers and module package users, kernel-devel (and kernel) packages
should 1) provide means for robust build and install time dependencies,
and 2) be easy enough to use, and 3) not require module packagers too
much knowledge/hardcoding of the set of variants (think custom kernels),
and 4) honor the documented upstream way of building modules for the
currently running kernel while keeping it possible to build for a given
arbitrary kernel.
Definitions: for the purpose of this discussion, $version is the "base
version" of the kernel (without the possible "smp" etc variants; usually
equivalent to %{version}-%{release} in rpm terms), $variant is the
"smp", "xen0", "custom" etc part, $uname is the output of "uname -r" for
that kernel (ie. $version and $variant concatenated), and $arch is the
architecture. For example, in the current Rawhide kernel-
smp-2.6.11-1.1177_FC4.i686 package: $variant=smp,
$version=2.6.11-1.1177_FC4, $arch=i686, $uname=2.6.11-1.1177_FC4smp.
Item 1: naming in general (categories 1, 2, and 3 above).
Module packages need to be able to robustly identify their build and
install time dependencies. The components required for this AFAICS are
$version, $variant, and $arch. I and several others have used $uname in
the past with pretty good results, and the kernel packages themselves
already use $uname in various places. Here's a summary of how the above
"components" are currently being used in Rawhide kernel(-devel)
packages:
a) rpm package names:
kernel(-$variant)(-devel) = $version(.$arch)
b) kernel*-devel provision:
kernel(-$variant)-devel-$arch = $version
c) Provision in all kernel packages:
kernel = $version
d) /usr/src/kernels dir names:
$version-$variant-$arch
e) Additional provision rumoured to be in the kernel packages or
coming soon, not in Rawhide yet though:
kernel(-$variant)-$arch = $version
f) Module dirs:
/lib/modules/$uname
g) Kernel binaries (note: not always in /boot):
vmlinuz-$uname
rpm does not currently allow architecture qualified dependencies, so
such provisions are being and have been added to the kernel and -devel
packages in various forms, which is ok.
Of the above, b) and d) are the only suitable ones to be used as module
package build dependencies, and e) is the only one suitable for an
install time dependency. However, IMO inventing another naming scheme
is not (or would not have been) necessary: $uname could have been used
in b), d) and e):
b) kernel-devel-$arch = $uname
d) $uname-$arch
e) kernel-$arch = $uname
The good things about $uname over various other %{name}, $variant and
$version combinations are for example: it has always been there in the
kernel packages in various places, there's a lot of documentation out
there referring to it, people are familiar with it, using it avoids
having to know the global set of $variants. Related Bugzilla entries:
https://bugzilla.redhat.com/145914
https://bugzilla.redhat.com/149249
Short version: IMO $uname should be used more, instead of inventing new
name-version-variant combinations.
Item 2: kernel header tree location (categories 1, 2, 3, and 4).
/lib/modules/$uname/build is AFAIK the documented, official upstream way
to point to the headers tree for a particular kernel. This is mostly
relevant for people building modules (not necessarily packages)
theirselves, and probably eg. DKMS. The current Rawhide packages sort
of break this "contract": https://bugzilla.redhat.com/149210
Keeping the "build" symlink in the devel packages as it is now results
in the possibility of $arch mismatch with the installed kernel package.
Moving the symlink away from the -devel packages to the kernel packages
would look like an obvious solution.
The header tree location is of course also relevant for buildsystem
produced module packages, or IOW ones to be built for a given kernel
version. Item 1 and its Bugzilla entries above already discussed this
to some extent; in this case it's necessary to be able to find the
headers tree without having the target kernel installed, and to depend
on the package providing it. I think /usr/src/kernels/$uname-$arch
would work for both. /usr/src/kernels/$version-$variant-$arch works
too, but does not have the good properties of using $uname.
Note: using /lib/modules/$uname/build as the header tree location in
module packages does not look like a good idea. If the build symlink
stays as is, there's possibility of arch mismatch as discussed above.
If it is moved to the kernel packages, the module package builds would
require the target kernel package being installed during the build,
which is bad. Better to stick with the /usr/src/kernels/$whatever dir
when packaging modules and leave use of the build symlink to non-
packaged module builders.
Item 3: installing -devel packages for multiple archs (categories 2, 4).
For mass production of kernel modules in automated build environments,
it'd be good to be able to install the headers for all supported (and
buildable in the target system) archs in parallel. The file/dir naming
part (to avoid conflicts) of this is AFAICS ok in Rawhide, but the
requirement is not met due to other implementation issues:
https://bugzilla.redhat.com/147553 I don't have good ideas how to fix
this apart from the vague suggestion of combining more archs and
variants in "bigger" and fewer kernel-devel packages (possibly noarch
ones).
Item 4: install time dependencies (category 1).
Currently there's no sane way to place arch-qualified install time
dependencies in module packages. https://bugzilla.redhat.com/149249
There have been reports of "kernel(-$variant)-$arch = $version" being
The Way, but no FC kernel yet provides that. Since it's not there yet,
I'd suggest considering using $uname instead (see end of Item 1 above,
as well as below).
Summary:
Yes, I am a $uname fan. Anyway, to summarize, here's how a module
package could depend on the necessary packages and locate the necessary
dirs in its specfile, assuming the target $uname would be available at
build time as %{uname} (eg. by passing something like "--define 'uname
2.6.10-1.770_FC3smp'" to rpmbuild). %{_target_cpu} is already
available, its value is determined by --target to rpmbuild. People
building this example package for their running kernel would need to
specify the correct --target manually, but %{uname} could be "auto-
detected".
%{!?uname: %define uname %(uname -r)}
...
BuildRequires: kernel-devel-%{_target_cpu} = %{uname}
Requires: kernel-%{_target_cpu} = %{uname}
...
%build
KSRCDIR=/usr/src/kernels/%{uname}-%{_target_cpu}
...
%install
DESTDIR=$RPM_BUILD_ROOT/lib/modules/%{uname}/...
Attached is also a patch against the current Rawhide kernel specfile
that would implement the stuff required for the above specfile snippet.
For brevity (in a mail like this, ha!) it doesn't take backwards
compatibility into account, but that'd be trivial to provide if
necessary. It's untested, and included here for documentation purposes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-2.6.spec.patch
Type: text/x-patch
Size: 3984 bytes
Desc: not available
URL:
From notting at redhat.com Tue Mar 15 18:49:35 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 15 Mar 2005 13:49:35 -0500
Subject: STR working out of the box
In-Reply-To: <1110869044.14869.201.camel@daxter.boston.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<20050314170448.GE10338@nostromo.devel.redhat.com>
<1110869044.14869.201.camel@daxter.boston.redhat.com>
Message-ID: <20050315184935.GF12363@nostromo.devel.redhat.com>
David Zeuthen (davidz at redhat.com) said:
> > > 3. vbetool is kind of evil; it's a workaround for broken video
> > > drivers and the mess that is X.org / kernel interaction wrt.
> > > to video hardware (so, vbetool becomes the 3th or 4th player
> > > directly touching hardware. Yay!). I expect we need to add
> > > radeontool at some point too.
> >
> > Note that vbetool is only for certain cards. There are other tools
> > for other cards.
>
> Apart from radeontool?
radeontool/vbetool should cover ATI & nVidia. Hopefully everyone
else doesn't need them. :)
Bill
From skvidal at phy.duke.edu Tue Mar 15 21:24:49 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 15 Mar 2005 16:24:49 -0500
Subject: extras merging
Message-ID: <1110921889.617.86.camel@cutter>
Hi folks,
Bill suggested I merge over all the packages from fedora extras 3 into
fedora development (fc4). What do you think?
merge them over and then fix the ones that break or rebuild and fix the
ones that break?
-sv
From roland at redhat.com Tue Mar 15 21:25:48 2005
From: roland at redhat.com (Roland McGrath)
Date: Tue, 15 Mar 2005 13:25:48 -0800
Subject: extras merging
In-Reply-To: seth vidal's message of Tuesday,
15 March 2005 16:24:49 -0500 <1110921889.617.86.camel@cutter>
Message-ID: <200503152125.j2FLPmGB012708@magilla.sf.frob.com>
> Hi folks,
> Bill suggested I merge over all the packages from fedora extras 3 into
> fedora development (fc4). What do you think?
>
> merge them over and then fix the ones that break or rebuild and fix the
> ones that break?
fc4 has gcc4, so I think you want to rebuild everything (and probably more
will break than would have otherwise).
From notting at redhat.com Tue Mar 15 22:00:14 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 15 Mar 2005 17:00:14 -0500
Subject: extras merging
In-Reply-To: <200503152125.j2FLPmGB012708@magilla.sf.frob.com>
References: <1110921889.617.86.camel@cutter>
<200503152125.j2FLPmGB012708@magilla.sf.frob.com>
Message-ID: <20050315220014.GC28555@nostromo.devel.redhat.com>
Roland McGrath (roland at redhat.com) said:
> > Bill suggested I merge over all the packages from fedora extras 3 into
> > fedora development (fc4). What do you think?
> >
> > merge them over and then fix the ones that break or rebuild and fix the
> > ones that break?
>
> fc4 has gcc4, so I think you want to rebuild everything (and probably more
> will break than would have otherwise).
The idea would be that, until everyting *is* rebuilt, the old versions
would still be available for use. Much like Core packages in rawhide
that aren't rebuilt yet.
Bill
From bugs.michael at gmx.net Wed Mar 16 03:48:06 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Wed, 16 Mar 2005 04:48:06 +0100
Subject: extras merging
In-Reply-To: <20050315220014.GC28555@nostromo.devel.redhat.com>
References: <1110921889.617.86.camel@cutter>
<200503152125.j2FLPmGB012708@magilla.sf.frob.com>
<20050315220014.GC28555@nostromo.devel.redhat.com>
Message-ID: <20050316044806.359a1594.bugs.michael@gmx.net>
On Tue, 15 Mar 2005 17:00:14 -0500, Bill Nottingham wrote:
> > > Bill suggested I merge over all the packages from fedora extras 3 into
> > > fedora development (fc4). What do you think?
> > >
> > > merge them over and then fix the ones that break or rebuild and fix the
> > > ones that break?
> >
> > fc4 has gcc4, so I think you want to rebuild everything (and probably more
> > will break than would have otherwise).
>
> The idea would be that, until everyting *is* rebuilt, the old versions
> would still be available for use. Much like Core packages in rawhide
> that aren't rebuilt yet.
When is everything rebuilt? How do we keep track whether everything is
rebuilt? Do we have scripts which compare EVR of binary package trees?
Do we have the developer resources to make sure that packages which need
a rebuild are noticed as needing a rebuild?
From laroche at redhat.com Wed Mar 16 09:42:16 2005
From: laroche at redhat.com (Florian La Roche)
Date: Wed, 16 Mar 2005 10:42:16 +0100
Subject: extras merging
In-Reply-To: <1110921889.617.86.camel@cutter>
References: <1110921889.617.86.camel@cutter>
Message-ID: <20050316094216.GA6925@dudweiler.stuttgart.redhat.com>
On Tue, Mar 15, 2005 at 04:24:49PM -0500, seth vidal wrote:
> Hi folks,
> Bill suggested I merge over all the packages from fedora extras 3 into
> fedora development (fc4). What do you think?
>
> merge them over and then fix the ones that break or rebuild and fix the
> ones that break?
Automatic rebuilds in fc4 and making sure bug-fixes e.g. for gcc4 are added
would be great. Not sure we want to push all these packages as part of the
FC development tree or not.
I'd also really like to see us building packages for several
releases and trying to automate that. This makes even more sense for
FC-extras and longterm also FC-updates would benefit from this.
greetings,
Florian La Roche
From notting at redhat.com Wed Mar 16 16:55:55 2005
From: notting at redhat.com (Bill Nottingham)
Date: Wed, 16 Mar 2005 11:55:55 -0500
Subject: extras merging
In-Reply-To: <20050316044806.359a1594.bugs.michael@gmx.net>
References: <1110921889.617.86.camel@cutter>
<200503152125.j2FLPmGB012708@magilla.sf.frob.com>
<20050315220014.GC28555@nostromo.devel.redhat.com>
<20050316044806.359a1594.bugs.michael@gmx.net>
Message-ID: <20050316165555.GA14017@nostromo.devel.redhat.com>
Michael Schwendt (bugs.michael at gmx.net) said:
> > The idea would be that, until everyting *is* rebuilt, the old versions
> > would still be available for use. Much like Core packages in rawhide
> > that aren't rebuilt yet.
>
> When is everything rebuilt?
When it's rebuilt. It's easy enough to kick off a mass rebuild,
and clean up the stragglers later.
> How do we keep track whether everything is rebuilt?
If you keep the trees of built packages separate until they're combined
for the download site, it's easy.
Bill
From nphilipp at redhat.com Wed Mar 16 18:18:25 2005
From: nphilipp at redhat.com (Nils Philippsen)
Date: Wed, 16 Mar 2005 19:18:25 +0100
Subject: STR working out of the box
In-Reply-To: <1110867934.14869.182.camel@daxter.boston.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<423421DE.2050403@redhat.com>
<1110867934.14869.182.camel@daxter.boston.redhat.com>
Message-ID: <1110997105.12106.5.camel@wombat.tiptoe.de>
On Tue, 2005-03-15 at 01:25 -0500, David Zeuthen wrote:
> On Sun, 2005-03-13 at 01:19 -1000, Warren Togami wrote:
> > More ugly hacks...
> >
> > /sbin/hwclock --systohc /sbin/hwclock --hctosys
You'd have to take into account whether the hardware clock runs on UTC
or not -- we don't want to suspend, then crash and come up with a
totally skewed system time on top of that.
my 2p,
Nils
--
Nils Philippsen / Red Hat / nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
From fedora at leemhuis.info Wed Mar 16 19:00:19 2005
From: fedora at leemhuis.info (Thorsten Leemhuis)
Date: Wed, 16 Mar 2005 20:00:19 +0100
Subject: RFD: kernel-devel package improvements
In-Reply-To: <1110909825.26174.173.camel@bobcat.mine.nu>
References: <1110909825.26174.173.camel@bobcat.mine.nu>
Message-ID: <1110999620.5479.41.camel@notebook.thl.home>
Am Dienstag, den 15.03.2005, 20:03 +0200 schrieb Ville Skytt?:
> Warning: lengthy mail.
Warning: short mail ;-)
I'm also involved with packaging kernel-modules and from my point of
view everything Ville described/criticized in his mail is reasonable.
And the solution(s) sounds good afaics. It would make things a lot
easier if we used the "uname -r" approach Ville suggests.
Therefor I really would appreciate it if we could apply a
tested/modified version of the patch Ville posted before FC4 is shipped
to solve the biggest pitfalls from his list of problems. I'm willing to
help with this where I can if that is needed.
Yes, maybe we are a bit incompatible to RHEL4 then -- i think this is a
problem, but I think that is no good reason to stay with the current
situation.
--
Thorsten Leemhuis
From skvidal at phy.duke.edu Wed Mar 16 19:18:31 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 16 Mar 2005 14:18:31 -0500
Subject: fedora extras development package population
Message-ID: <1111000711.30523.27.camel@opus.phy.duke.edu>
Hi folks,
I'm going to merge packages from extras 3 into extras development then
run repomanage over them and prune all the older packages.
Once that's done - people need to submit changes to their packages in
cvs and then ask for rebuilds of those packages via the wiki:
http://fedoraproject.org/wiki/Extras/FC4Status
When I'm done merging the packages over from the 3 repo I'll post to
extras-list that things were merged over.
Thanks,
-sv
From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 17 09:35:27 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Thu, 17 Mar 2005 10:35:27 +0100
Subject: fedora extras development package population
In-Reply-To: <1111000711.30523.27.camel@opus.phy.duke.edu>
References: <1111000711.30523.27.camel@opus.phy.duke.edu>
Message-ID: <20050317103527.4e85e4a8@python2>
seth vidal wrote :
> I'm going to merge packages from extras 3 into extras development then
> run repomanage over them and prune all the older packages.
>
> Once that's done - people need to submit changes to their packages in
> cvs and then ask for rebuilds of those packages via the wiki:
So this means that all packagers should go through their package files in
CVS, bump the release, add a %changelog entry with at least "Rebuild
against FC4" or something like that, and ideally do a first test build
against FC4t1/Rawhide, fixing eventual gcc4/library problems? If so,
that's fine by me, it never hurts to need to go through all spec files
once in a while.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.770_FC3
Load : 0.69 0.69 0.75
From skvidal at phy.duke.edu Thu Mar 17 14:40:39 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Thu, 17 Mar 2005 09:40:39 -0500
Subject: fedora extras development package population
In-Reply-To: <20050317103527.4e85e4a8@python2>
References: <1111000711.30523.27.camel@opus.phy.duke.edu>
<20050317103527.4e85e4a8@python2>
Message-ID: <1111070439.5267.63.camel@cutter>
> So this means that all packagers should go through their package files in
> CVS, bump the release, add a %changelog entry with at least "Rebuild
> against FC4" or something like that, and ideally do a first test build
> against FC4t1/Rawhide, fixing eventual gcc4/library problems? If so,
> that's fine by me, it never hurts to need to go through all spec files
> once in a while.
yep. that's what this means.
-sv
From skvidal at phy.duke.edu Fri Mar 18 06:28:26 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Fri, 18 Mar 2005 01:28:26 -0500
Subject: Question about an orphaned package
Message-ID: <1111127306.30200.29.camel@cutter>
Hey,
I was looking at the orphaned list seeing if there was anything I
wanted to pickup. I noticed gpa there and was thinking about owning it,
but I've got a kinda dumb question:
gpa devel appears to be sluggish atm and 0.7.0 is still the latest
release. I looked at the package and spec file, it all looks spiffy. So,
my question is - if it's not moving and not changing, what exactly is it
I would do to maintain it? :)
-sv
From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Mar 18 10:01:19 2005
From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou)
Date: Fri, 18 Mar 2005 11:01:19 +0100
Subject: Question about an orphaned package
In-Reply-To: <1111127306.30200.29.camel@cutter>
References: <1111127306.30200.29.camel@cutter>
Message-ID: <20050318110119.33e273aa@python2>
seth vidal wrote :
> I was looking at the orphaned list seeing if there was anything I
> wanted to pickup. I noticed gpa there and was thinking about owning it,
> but I've got a kinda dumb question:
> gpa devel appears to be sluggish atm and 0.7.0 is still the latest
> release. I looked at the package and spec file, it all looks spiffy. So,
> my question is - if it's not moving and not changing, what exactly is it
> I would do to maintain it? :)
Answer bug reports with "development is slow, wait for the next version,
sorry", bump release and ask for a rebuild for every new FC release... an
that's basically it, right? :-D
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3.radeon
Load : 0.16 0.21 0.28
From ville.skytta at iki.fi Fri Mar 18 13:11:33 2005
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Fri, 18 Mar 2005 15:11:33 +0200
Subject: Question about an orphaned package
In-Reply-To: <20050318110119.33e273aa@python2>
References: <1111127306.30200.29.camel@cutter>
<20050318110119.33e273aa@python2>
Message-ID: <1111151493.4784.209.camel@bobcat.mine.nu>
On Fri, 2005-03-18 at 11:01 +0100, Matthias Saou wrote:
> seth vidal wrote :
>
> > I was looking at the orphaned list seeing if there was anything I
> > wanted to pickup. I noticed gpa there and was thinking about owning it,
> > but I've got a kinda dumb question:
> > gpa devel appears to be sluggish atm and 0.7.0 is still the latest
> > release. I looked at the package and spec file, it all looks spiffy. So,
> > my question is - if it's not moving and not changing, what exactly is it
> > I would do to maintain it? :)
>
> Answer bug reports with "development is slow, wait for the next version,
> sorry", bump release and ask for a rebuild for every new FC release... an
> that's basically it, right? :-D
Right! And besides, if it works and does what it's designed for, why
blame anyone for sluggish development...? :)
Seth, it'd be cool if you'd (or someone else) pick it up; ever since
kgpg started working sanely somewhere at FC2ish time or so, I haven't
really used or even launched gpa. FWIW, I've successfully test-built it
on FC4test1.
From kevin at tummy.com Sat Mar 19 06:55:50 2005
From: kevin at tummy.com (Kevin Fenzi)
Date: Fri, 18 Mar 2005 23:55:50 -0700
Subject: cvs-import.sh help
Message-ID: <20050319065553.EE30812FBE@voldemort.scrye.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings.
I am trying to import into CVS the xfce4 packages. The first of these
is the dbh library package.
First issue was that I tried to run it in a cvs tree where I had
checked everything out with anonymous back before I had a CVS
account. Would there be a way we could modify the cvs-import.sh to
detect this and spit out an error?
After checking out a new common directory with my cvs account, I tried
running cvs-import.sh:
cvs-import.sh ../../SRPMS/dbh-1.0.22-1.src.rpm
Checking out the modules file...
Creating new module: dbh
Running syncmail...
Mailing cvsextras...
...syncmail done.
Running syncmail...
Mailing cvsextras...
...syncmail done.
Entry for module 'dbh' created.
Checking out module: 'dbh'
Unpacking source package: dbh-1.0.22-1.src.rpm...
A dbh-1.0.22-rpath.patch
L dbh-1.0.22.tar.gz
A dbh.spec
Checking : dbh-1.0.22.tar.gz on http://cvs.fedora.redhat.com/repo/extras/upload.cgi...
ERROR: could not check remote file status
make: *** [upload] Error 255
ERROR: Uploading the source tarballs failed!
zsh: 7140 exit 9 cvs-import.sh ../../SRPMS/dbh-1.0.22-1.src.rpm
Any ideas what I am doing wrong?
thanks for any assisstance.
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8
iD8DBQFCO8z53imCezTjY0ERArvrAJ9YQsIpVfbJzKxMYptintg5DhZd4gCfZTJ4
qHlQMxhXTYp6BGKSjapF8m8=
=qchG
-----END PGP SIGNATURE-----
From wtogami at redhat.com Sat Mar 19 07:08:31 2005
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 18 Mar 2005 21:08:31 -1000
Subject: cvs-import.sh help
In-Reply-To: <20050319065553.EE30812FBE@voldemort.scrye.com>
References: <20050319065553.EE30812FBE@voldemort.scrye.com>
Message-ID: <423BCFEF.6070700@redhat.com>
Kevin Fenzi wrote:
>
> Checking : dbh-1.0.22.tar.gz on http://cvs.fedora.redhat.com/repo/extras/upload.cgi...
> ERROR: could not check remote file status
> make: *** [upload] Error 255
> ERROR: Uploading the source tarballs failed!
> zsh: 7140 exit 9 cvs-import.sh ../../SRPMS/dbh-1.0.22-1.src.rpm
>
Are you behind some kind of HTTP proxy where your incoming IP address
would appear to be different than your incoming SSH address? If so this
is the problem, because we currently rely on a problematic IP-based ACL
to allow both ssh and HTTP upload access. Is this the case for you?
Warren Togami
wtogami at redhat.com
From kevin at tummy.com Sat Mar 19 07:25:56 2005
From: kevin at tummy.com (Kevin Fenzi)
Date: Sat, 19 Mar 2005 00:25:56 -0700
Subject: cvs-import.sh help
References: <20050319065553.EE30812FBE@voldemort.scrye.com>
<423BCFEF.6070700@redhat.com>
Message-ID: <20050319072600.CF8E1B9D3C@voldemort.scrye.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Warren" == Warren Togami writes:
Warren> Kevin Fenzi wrote:
>> Checking : dbh-1.0.22.tar.gz on
>> http://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR:
>> could not check remote file status make: *** [upload] Error 255
>> ERROR: Uploading the source tarballs failed! zsh: 7140 exit 9
>> cvs-import.sh ../../SRPMS/dbh-1.0.22-1.src.rpm
>>
Warren> Are you behind some kind of HTTP proxy where your incoming IP
Warren> address would appear to be different than your incoming SSH
Warren> address? If so this is the problem, because we currently rely
Warren> on a problematic IP-based ACL to allow both ssh and HTTP
Warren> upload access. Is this the case for you?
Ah ha. Yes.
I have both a dsl line (which I use for ssh, etc) and a cable modem
(which I use for http, as it has a nice fast download).
If I change that, can I just re-run the cvs-import?
Or does something need to get fixed with the failed attempt before?
Warren> Warren Togami wtogami at redhat.com
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8
iD8DBQFCO9QI3imCezTjY0ERApMJAKCXBPdjpD/9He93u5Hm5kqie0vJqgCdFVCK
HZCuTUqI5DiOkZt0Nj/Jgig=
=BXeH
-----END PGP SIGNATURE-----
From wtogami at redhat.com Sat Mar 19 07:50:18 2005
From: wtogami at redhat.com (Warren Togami)
Date: Fri, 18 Mar 2005 21:50:18 -1000
Subject: cvs-import.sh help
In-Reply-To: <20050319072600.CF8E1B9D3C@voldemort.scrye.com>
References: <20050319065553.EE30812FBE@voldemort.scrye.com> <423BCFEF.6070700@redhat.com>
<20050319072600.CF8E1B9D3C@voldemort.scrye.com>
Message-ID: <423BD9BA.2090205@redhat.com>
Kevin Fenzi wrote:
>
> Ah ha. Yes.
>
> I have both a dsl line (which I use for ssh, etc) and a cable modem
> (which I use for http, as it has a nice fast download).
>
> If I change that, can I just re-run the cvs-import?
> Or does something need to get fixed with the failed attempt before?
>
Do a checkout of that module, and use "make upload
FILES=filename.tar.bz2". It should work out OK I think. If not try
cvs-import.sh again.
Warren Togami
wtogami at redhat.com
From markmc at redhat.com Sat Mar 19 09:40:13 2005
From: markmc at redhat.com (Mark McLoughlin)
Date: Sat, 19 Mar 2005 09:40:13 +0000
Subject: cvs-import.sh help
In-Reply-To: <20050319072600.CF8E1B9D3C@voldemort.scrye.com>
References: <20050319065553.EE30812FBE@voldemort.scrye.com>
<423BCFEF.6070700@redhat.com>
<20050319072600.CF8E1B9D3C@voldemort.scrye.com>
Message-ID: <1111225213.3858.24.camel@blaa>
On Sat, 2005-03-19 at 00:25 -0700, Kevin Fenzi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >>>>> "Warren" == Warren Togami writes:
>
> Warren> Kevin Fenzi wrote:
> >> Checking : dbh-1.0.22.tar.gz on
> >> http://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR:
> >> could not check remote file status make: *** [upload] Error 255
> >> ERROR: Uploading the source tarballs failed! zsh: 7140 exit 9
> >> cvs-import.sh ../../SRPMS/dbh-1.0.22-1.src.rpm
> >>
>
> Warren> Are you behind some kind of HTTP proxy where your incoming IP
> Warren> address would appear to be different than your incoming SSH
> Warren> address? If so this is the problem, because we currently rely
> Warren> on a problematic IP-based ACL to allow both ssh and HTTP
> Warren> upload access. Is this the case for you?
>
> Ah ha. Yes.
>
> I have both a dsl line (which I use for ssh, etc) and a cable modem
> (which I use for http, as it has a nice fast download).
>
> If I change that, can I just re-run the cvs-import?
> Or does something need to get fixed with the failed attempt before?
My tarball upload failed during cvs-import too, I fixed the problem and
re-ran cvs-import and there didn't seem to be any problems with that.
Cheers,
Mark.
From shahms at shahms.com Sat Mar 19 19:30:55 2005
From: shahms at shahms.com (Shahms E. King)
Date: Sat, 19 Mar 2005 11:30:55 -0800
Subject: cvs-import.sh help
In-Reply-To: <1111225213.3858.24.camel@blaa>
References: <20050319065553.EE30812FBE@voldemort.scrye.com>
<423BCFEF.6070700@redhat.com>
<20050319072600.CF8E1B9D3C@voldemort.scrye.com>
<1111225213.3858.24.camel@blaa>
Message-ID: <1111260655.5670.30.camel@home.shahms.com>
On Sat, 2005-03-19 at 09:40 +0000, Mark McLoughlin wrote:
> On Sat, 2005-03-19 at 00:25 -0700, Kevin Fenzi wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > >>>>> "Warren" == Warren Togami writes:
> >
> > Warren> Kevin Fenzi wrote:
> > >> Checking : dbh-1.0.22.tar.gz on
> > >> http://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR:
> > >> could not check remote file status make: *** [upload] Error 255
> > >> ERROR: Uploading the source tarballs failed! zsh: 7140 exit 9
> > >> cvs-import.sh ../../SRPMS/dbh-1.0.22-1.src.rpm
> > >>
> >
> > Warren> Are you behind some kind of HTTP proxy where your incoming IP
> > Warren> address would appear to be different than your incoming SSH
> > Warren> address? If so this is the problem, because we currently rely
> > Warren> on a problematic IP-based ACL to allow both ssh and HTTP
> > Warren> upload access. Is this the case for you?
> >
> > Ah ha. Yes.
> >
> > I have both a dsl line (which I use for ssh, etc) and a cable modem
> > (which I use for http, as it has a nice fast download).
> >
> > If I change that, can I just re-run the cvs-import?
> > Or does something need to get fixed with the failed attempt before?
>
> My tarball upload failed during cvs-import too, I fixed the problem and
> re-ran cvs-import and there didn't seem to be any problems with that.
>
> Cheers,
> Mark.
I'm in a similar situation at work. My "solution" is an ugly one, but
works. Attached is the script I use to accomplish it.
It installs an iptables rule to redirect outgoing port 80 to
cvs.fedora.redhat.com to localhost 8081, sets up an ssh tunnel, executes
the command, kills the tunnel and removes the rule. I said it was ugly,
but it gets the job done.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fedora-run
Type: application/x-shellscript
Size: 653 bytes
Desc: not available
URL:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
From kevin at tummy.com Sat Mar 19 21:55:29 2005
From: kevin at tummy.com (Kevin Fenzi)
Date: Sat, 19 Mar 2005 14:55:29 -0700
Subject: cvs-import.sh help
References: <20050319065553.EE30812FBE@voldemort.scrye.com>
<423BCFEF.6070700@redhat.com>
<20050319072600.CF8E1B9D3C@voldemort.scrye.com>
<1111225213.3858.24.camel@blaa>
<1111260655.5670.30.camel@home.shahms.com>
Message-ID: <20050319215533.099ED8F432@voldemort.scrye.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Shahms" == Shahms E King writes:
Shahms> I'm in a similar situation at work. My "solution" is an ugly
Shahms> one, but works. Attached is the script I use to accomplish it.
Shahms> It installs an iptables rule to redirect outgoing port 80 to
Shahms> cvs.fedora.redhat.com to localhost 8081, sets up an ssh
Shahms> tunnel, executes the command, kills the tunnel and removes the
Shahms> rule. I said it was ugly, but it gets the job done.
I just had to add one rule in my firewall:
- -A OUTPUT -p tcp -m tcp --dport 80 -d 209.132.176.51 -j ACCEPT
Which hit before my rule that marks packets for port 80 to go out the
cable connection. :)
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8
iD8DBQFCPJ/U3imCezTjY0ERAmKoAJ9mVWJ15lMEUZcuIWUmnBVQ5Vvj7wCcC66Q
xdkTzsLnT3gHJIoZKY205RU=
=RN6x
-----END PGP SIGNATURE-----
From wtogami at redhat.com Tue Mar 22 09:03:08 2005
From: wtogami at redhat.com (Warren Togami)
Date: Mon, 21 Mar 2005 23:03:08 -1000
Subject: STR working out of the box
In-Reply-To: <1110997105.12106.5.camel@wombat.tiptoe.de>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com> <423421DE.2050403@redhat.com> <1110867934.14869.182.camel@daxter.boston.redhat.com>
<1110997105.12106.5.camel@wombat.tiptoe.de>
Message-ID: <423FDF4C.4000008@redhat.com>
Nils Philippsen wrote:
> On Tue, 2005-03-15 at 01:25 -0500, David Zeuthen wrote:
>
>>On Sun, 2005-03-13 at 01:19 -1000, Warren Togami wrote:
>>
>>>More ugly hacks...
>>>
>>>/sbin/hwclock --systohc /sbin/hwclock --hctosys
>
>
> You'd have to take into account whether the hardware clock runs on UTC
> or not -- we don't want to suspend, then crash and come up with a
> totally skewed system time on top of that.
>
Good point... and it seems that the clock screwage during suspend went
away when I upgraded from 2.6.10 to 2.6.11 kernel. So this hwclock
thing is indeed a bad idea to add to the scripts by default.
Warren Togami
wtogami at redhat.com
From skvidal at phy.duke.edu Tue Mar 22 20:59:11 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 22 Mar 2005 15:59:11 -0500
Subject: minor spec file updates
Message-ID: <1111525151.19235.56.camel@cutter>
Hey folks,
As I've been coming across trivial and minor specfile adjustments to
things being built in extras I've been making them and checking them in
If anyone is uncomfortable with this and would rather I not touch the
specfiles that they maintain, yell at me and let me know.
-sv
From skvidal at phy.duke.edu Wed Mar 23 04:31:27 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Tue, 22 Mar 2005 23:31:27 -0500
Subject: FC3 and extras build requests
Message-ID: <1111552287.28357.6.camel@cutter>
Hey folks,
until you have code checked in for the right branches do not request
builds.
ie: if I can't cd into that directory in a full check out of that
branch, then don't put the build request in the wiki page. please.
thanks,
-sv
From wtogami at redhat.com Fri Mar 25 04:57:39 2005
From: wtogami at redhat.com (Warren Togami)
Date: Thu, 24 Mar 2005 18:57:39 -1000
Subject: RFD: kernel-devel package improvements
In-Reply-To: <1110909825.26174.173.camel@bobcat.mine.nu>
References: <1110909825.26174.173.camel@bobcat.mine.nu>
Message-ID: <42439A43.5090001@redhat.com>
Hi Ville,
Are you satisfied with the changes made to FC4 kernel-devel? Are there
any remaining pending Bugzilla reports that need discussion or action?
Warren Togami
wtogami at redhat.com
From ville.skytta at iki.fi Sun Mar 27 09:27:47 2005
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Sun, 27 Mar 2005 12:27:47 +0300
Subject: RFD: kernel-devel package improvements
In-Reply-To: <42439A43.5090001@redhat.com>
References: <1110909825.26174.173.camel@bobcat.mine.nu>
<42439A43.5090001@redhat.com>
Message-ID: <1111915667.12235.77.camel@bobcat.mine.nu>
On Thu, 2005-03-24 at 18:57 -1000, Warren Togami wrote:
> Are you satisfied with the changes made to FC4 kernel-devel? Are there
> any remaining pending Bugzilla reports that need discussion or action?
The changes made thus far are very welcome, but I think there is still
room for improvement. More details later today.
From ville.skytta at iki.fi Sun Mar 27 09:34:28 2005
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Sun, 27 Mar 2005 12:34:28 +0300
Subject: RFD: kernel-devel package improvements
In-Reply-To: <1110909825.26174.173.camel@bobcat.mine.nu>
References: <1110909825.26174.173.camel@bobcat.mine.nu>
Message-ID: <1111916068.12235.85.camel@bobcat.mine.nu>
Fernando Lopez-Lezcano of PlanetCCRMA replied to me in private, here's
the part of his mail (forwarded with permission) which is related to the
"infrastructure" stuff:
-----
From: Fernando Lopez-Lezcano
Subject: Re: on kernel module packaging (from thread on fedora-devel)
Background: I don't package (at Planet CCRMA) as many kernel modules as
Dag or Axel, but I do package ALSA (and midishare) and have been doing
that since 2001 (with matching custom kernels with good low latency
behavior). I have found through experience (and after making many
mistakes) most of the solutions that are being proposed in this email
(of course not using exactly the same names and all that):
https://www.redhat.com/archives/fedora-maintainers/2005-
March/msg00096.html
I agree with the approach to dependency resolving explained there (ie:
tying the kernel module with the proper kernel through kernel version,
variant and architecture as explicit requires). I think I also like the
"let's use uname" approach. I'm using something similar in my kernels,
including special provides that are "required" in the kernel modules.
Obviously I'll have to change again things at my end once all the big
names agree on something, sigh [*].
From wtogami at redhat.com Sun Mar 27 21:53:24 2005
From: wtogami at redhat.com (Warren Togami)
Date: Sun, 27 Mar 2005 11:53:24 -1000
Subject: libexif upgrade in FC4
Message-ID: <42472B54.7030005@redhat.com>
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146027
Do we want to upgrade libexif in FC4 from libexif-0.5.12-7 to 0.6.12?
It would require rebuilding packages that depend on it.
Warren Togami
wtogami at redhat.com
From ville.skytta at iki.fi Mon Mar 28 20:32:38 2005
From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=)
Date: Mon, 28 Mar 2005 23:32:38 +0300
Subject: RFD: kernel-devel package improvements
In-Reply-To: <1110909825.26174.173.camel@bobcat.mine.nu>
References: <1110909825.26174.173.camel@bobcat.mine.nu>
Message-ID: <1112041958.19155.11.camel@bobcat.mine.nu>
A quick status update:
some of the points from my initial mail in this thread have been
applied/implemented in the current Rawhide kernels; here are the missing
ones I think would be nice to get "in" too:
uname in kernel-devel directories:
https://bugzilla.redhat.com/145914
uname-based -devel provisions:
https://bugzilla.redhat.com/152357
If the two RFEs/patches above would be accepted, I think we'd have a
complete, easy-to-use, and consistent "interface" in place for kernel
module packagers.
Then, in a different category: not interface, but implementation issue,
there's still https://bugzilla.redhat.com/147553 , but I tend to think
this is secondary priority.
From notting at redhat.com Tue Mar 29 17:01:01 2005
From: notting at redhat.com (Bill Nottingham)
Date: Tue, 29 Mar 2005 12:01:01 -0500
Subject: note to packagers: notification of library version upgrades
Message-ID: <20050329170101.GA27496@nostromo.devel.redhat.com>
If you're upgrading a library to a new version that may cause rebuilds
to be needed, either in Core or Extras, *please* notify fedora-maintainers
so that other packagers can be aware of it.
These include things such as the recent flac or musicbrainz changes,
the upgrade from python-2.3 to python-2.4, or the openssl changes.
Bill
From mharris at www.linux.org.uk Tue Mar 29 17:07:04 2005
From: mharris at www.linux.org.uk (Mike A. Harris)
Date: Tue, 29 Mar 2005 12:07:04 -0500
Subject: Heads up for 3rd party libGL/libGLU rpm packagers (ie: nvidia, ati)
Message-ID: <42498B38.3010500@www.linux.org.uk>
xorg-x11-Mesa-libGL now has a virtual provide of:
Provides: libGL = 1
Likewise, xorg-x11-Mesa-libGLU has a virtual provide of:
Provides: libGLU = 1
The reason for these additions should be obvious, but in
case it isn't, these have been added, so that packages
providing the development environments for these libs,
can "Requires: libGL >= 1" and be confident that the
build time dependancies are all properly met. The reason
for a virtual provide/require instead of an explicit
package requirement, is to allow any 3rd party
implementation's runtime libs to be able to be used,
instead of hard coding deps on Mesa supplied libs.
In order to avoid rpm warning about missing libGL and/or
libGLU dependancies, all
Once these new changes are built into rawhide, 3rd party
libGL implementations might choose to add virtual provides
to their subpackages that provide the libGL and/or libGLU
runtimes. Doing this may reduce the likelyhood of users
experiencing new rpm warnings about missing libGL and/or
libGLU dependancies if they do not already see similar
warnings.
With these new provides/requires in place, any software
which links to libGL or libGLU, can simply do:
BuildRequires: libGL >= 1
and/or
BuildRequires: libGLU >= 1
... and their dependancies will be met correctly, as long
as they have libGL{,U} implementations installed via rpm
packaging which provide the correct virtual provides as
outlined above. This also should help minimal buildroot
setups to ensure all dependancies get installed.
Future heads up for planning:
This is phase one of several longer term phases we will
be making to X and libGL/libGLU packaging to make life
easier on developers and package maintainers.
The next major change wont occur until the modularized
X11R7 is released. Once that occurs, we will be shifting
to much more modularized X11 packaging, and will likely
be shipping Mesa and libGLU from their own separate
src.rpm packages. When that occurs, each library will
have it's own separate -devel subpackage, which will
likely be an even more optimal solution.
As always, during each phase of change, every effort
will be made to try to preserve as much backward
compatibility with existing packaging as possible. If
we need to make changes that may require 3rd party
packaging changes, we try to minimize the impact of the
changes within reasonable limits, and provide details
far enough in advance for packagers to plan and roll
out updated packages.
If you are a packager of 3rd party libGL/libGLU
implementations, please consider adding the changes
I've recommended above at your earliest convenience.
Thanks in advance.
From mharris at redhat.com Tue Mar 29 18:04:41 2005
From: mharris at redhat.com (Mike A. Harris)
Date: Tue, 29 Mar 2005 13:04:41 -0500 (EST)
Subject: xsri package available to any interested parties to maintain
Message-ID:
xsri is currently in need of an upstream maintainer who might be
interested in improving the program, and adding features and
other enhancements to it.
xsri is not used in the default Red Hat desktops anymore, and
anything in the OS that can use it, does so conditionally by
checking to see if it is installed first. Due to it not being
used by default anywhere, adding new features to it is very low
on the Red Hat priority list.
As such, I think xsri is a good candidate for Fedora Extras if
there's a volunteer out there who is partial to it, and willing
to take ownership of it, and/or assume the role of upstream
maintainer.
We should consider deprecating it from Fedora Core IMHO.
Feedback and/or volunteers appreciated.
--
Mike A. Harris, Systems Engineer - X11 Development team, Red Hat Canada, Ltd.
IT executives rate Red Hat #1 for value: http://www.redhat.com/promo/vendor
From riel at redhat.com Tue Mar 29 19:57:24 2005
From: riel at redhat.com (Rik van Riel)
Date: Tue, 29 Mar 2005 14:57:24 -0500 (EST)
Subject: RFD: kernel-devel package improvements
In-Reply-To: <1112041958.19155.11.camel@bobcat.mine.nu>
References: <1110909825.26174.173.camel@bobcat.mine.nu>
<1112041958.19155.11.camel@bobcat.mine.nu>
Message-ID:
On Mon, 28 Mar 2005, Ville Skytt? wrote:
> If the two RFEs/patches above would be accepted, I think we'd have a
> complete, easy-to-use, and consistent "interface" in place for kernel
> module packagers.
I just committed these, so they should be in the next
Rawhide kernel.
> Then, in a different category: not interface, but implementation issue,
> there's still https://bugzilla.redhat.com/147553 , but I tend to think
> this is secondary priority.
And indeed, RPM isn't able to install both the i586 and
i686 version of the kernel-devel package, even though
there are no file conflicts.
# rpm -ivh i686/kernel-devel-2.6.11-1.1208_FC4.i686.rpm i586/kernel-devel-2.6.11-1.1208_FC4.i586.rpm
warning: package kernel-devel = 2.6.11-1.1208_FC4 was already added, skipping kernel-devel < 2.6.11-1.1208_FC4
error: error reading from file i586/kernel-devel-2.6.11-1.1208_FC4.i586.rpm
Note that the "error reading file" seems to be caused
by something inside RPM, since I can cat the file just
fine.
I really don't know what the nicest way to fix this bug
would be, so I guess I'd throw it out for discussion. The
naive way would be to add the architecture to the name of
the package - but that's butt ugly and sure to break things
left and right.
Any other ideas ?
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
From bnocera at redhat.com Wed Mar 30 09:06:33 2005
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 30 Mar 2005 10:06:33 +0100
Subject: xsri package available to any interested parties to maintain
In-Reply-To:
References:
Message-ID: <1112173593.1531.35.camel@bnocera.surrey.redhat.com>
On Tue, 2005-03-29 at 13:04 -0500, Mike A. Harris wrote:
> xsri is currently in need of an upstream maintainer who might be
> interested in improving the program, and adding features and
> other enhancements to it.
>
> xsri is not used in the default Red Hat desktops anymore, and
> anything in the OS that can use it, does so conditionally by
> checking to see if it is installed first. Due to it not being
> used by default anywhere, adding new features to it is very low
> on the Red Hat priority list.
Are the dependencies on it in gdm, firstboot and system-config-display
gone in rawhide?
--
Bastien Nocera
From bugs.michael at gmx.net Wed Mar 30 09:54:50 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Wed, 30 Mar 2005 11:54:50 +0200
Subject: Broken pkgconfig dependency chains in packages
Message-ID: <20050330115450.5e111668.bugs.michael@gmx.net>
Yesterday I filed the remaining 23 bug reports about broken pkgconfig
dependency chains in Fedora Core packages:
Package 'foo' contains a pkgconfig template file, which lists other
pkgconfig files as requirements. When these files are included in other
RPM packages, the RPM package "Requires" must be complete. Else
pkgconfig fails, prints an error message and returns an error code for
standard queries like "pkg-config --exists foo-1.0", "pkg-config
--cflags foo-1.0" or "pkg-config --list-all".
A detailed list of what RPM "Requires" lines are missing is attached to
each bug report.
A total of 24 packages in Fedora Core 4 Test 1 are affected this time.
Nine out of 24 packages are non -devel packages, which seem to include
development related files, such as a pkgconfig .pc file. Most likely they
cannot be fixed until a -devel package is split off. Additionally, often
such non -devel packages do not "Provides: %name-devel = %version-%release"
although they contain devel files.
The effect of broken pkgconfig dependencies are really ugly. Excerpt from
bug 152169, which is a non -devel package:
$ pkg-config --exists gnopernicus-1.0 || echo "no"
no
$ pkg-config --cflags gnopernicus-1.0
Package cspi-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `cspi-1.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'cspi-1.0', required by 'gnopernicus', not found
$ rpm --query gnopernicus
gnopernicus-0.10.3-1
I'd like to emphasise that a broken pkgconfig dependency chain not only
breaks specific queries, but also makes the global "pkg-config --list-all"
query, as parsed by some applications, print an error message and return
an error code (!), too. It remains broken until all pkgconfig files are
installed. So, preferably, RPM package dependencies ought to be complete.
From veillard at redhat.com Wed Mar 30 10:44:34 2005
From: veillard at redhat.com (Daniel Veillard)
Date: Wed, 30 Mar 2005 05:44:34 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <424A7E4D.4020702@redhat.com>
References: <424A769C.3040908@redhat.com> <20050330101154.GA19176@redhat.com>
<424A7E4D.4020702@redhat.com>
Message-ID: <20050330104434.GC19176@redhat.com>
On Wed, Mar 30, 2005 at 12:24:13AM -1000, Warren Togami wrote:
> Daniel Veillard wrote:
> >On Tue, Mar 29, 2005 at 11:51:24PM -1000, Warren Togami wrote:
> >
> >>http://tinyurl.com/493x7
> >>(Bugzilla query)
> >>
> >>Hi, if you are receiving this, then one or more of your packages are
> >>missing dependencies according to their provided pkgconfig files. While
> >>this is seemingly inconsequential, it is important to fix these because
> >>otherwise it prevents many missing and wrongly duplicated BuildRequires
> >>in other packages. Waste of time with bad reports and bad changes in
> >>other packages.
> >
> >
> > I don't understand what is the consequence of adding a library to
> > pkgconfig.
> >Suppose package A requires gamin to work. It will link with gamin or fam.
> >It does not need to link with glib. But glib is needed for gamin server
> >and the server only not the library used by the client application. The
> >package of the application depending on gamin should *not* get a glib
> >dependancy, only gamin need to. It seems the bug raised break that test
> >case, but I don't understand how pkgconfig works.
> > Do you have a clear normative description of pkgconfig which could
> >explain how that case need to be handled ? If by requiring gamin/fam
> >all KDE suddenly get a glib dependancy people will complain publicly
> >that's 100 sure. So I'm very reluctant following the advice in
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152486
> >or in your mail.
> >
> >Daniel
> >
>
> My response is only "builds fail without it", political reasons should
> not override reality. However...
>
> https://www.redhat.com/archives/fedora-maintainers/2005-March/msg00132.html
> Michael explains here with more detail. If you have a response, then
> please respond on that list.
Okay I have only one normative text for what pkgconfig is all about:
man pkg-config
-------------------------
The pkg-config program is used to retrieve information about installed
libraries in the system. It is typically used to compile and link
against one or more libraries. Here is a typical usage scenario in a
Makefile:
-------------------------
pkg-config is there to get library dependancies. Program needing fam or
gamin support need it to get the libraries to link to. The output of
pkgconfig cflags or link must *NOT* show glib output, even if from a
packaging level, gamin requires glib for the server side. The fact that
KDE requires fam or gamin, does not mean it should link against glib.
So without further detailed information allowing to disambiguate using
pkgconfig for it's original goal of simplifying compiling and linking from
the added use as a packaging dependancy, bug #152486 is a WONTFIX for me.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
From bugs.michael at gmx.net Wed Mar 30 11:01:36 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Wed, 30 Mar 2005 13:01:36 +0200
Subject: Missing pkgconfig dependencies
In-Reply-To: <20050330104434.GC19176@redhat.com>
References: <424A769C.3040908@redhat.com> <20050330101154.GA19176@redhat.com>
<424A7E4D.4020702@redhat.com> <20050330104434.GC19176@redhat.com>
Message-ID: <20050330130136.19ec17e9.bugs.michael@gmx.net>
On Wed, 30 Mar 2005 05:44:34 -0500, Daniel Veillard wrote:
> Okay I have only one normative text for what pkgconfig is all about:
>
> man pkg-config
> -------------------------
> The pkg-config program is used to retrieve information about installed
> libraries in the system. It is typically used to compile and link
> against one or more libraries. Here is a typical usage scenario in a
> Makefile:
> -------------------------
>
> pkg-config is there to get library dependancies. Program needing fam or
> gamin support need it to get the libraries to link to. The output of
> pkgconfig cflags or link must *NOT* show glib output, even if from a
> packaging level, gamin requires glib for the server side. The fact that
> KDE requires fam or gamin, does not mean it should link against glib.
> So without further detailed information allowing to disambiguate using
> pkgconfig for it's original goal of simplifying compiling and linking from
> the added use as a packaging dependancy, bug #152486 is a WONTFIX for me.
Bug-specific replies are better added in bugzilla. I replied to #152486
already. gamin-devel's gamin.pc file creates a dependency on glib2-devel
for glib-2.0 and gthread-2.0 CFLAGS and LDFLAGS, see:
pkg-config --cflags --ldflags gamin
That is a bug, if these are wrong and not needed. The fix for gamin-devel
then would be to drop these dependencies from the gamin.pc file instead
of adding "Requires: glib2-devel" to the rpm.
From bugs.michael at gmx.net Wed Mar 30 11:03:51 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Wed, 30 Mar 2005 13:03:51 +0200
Subject: Missing pkgconfig dependencies
In-Reply-To: <20050330130136.19ec17e9.bugs.michael@gmx.net>
References: <424A769C.3040908@redhat.com> <20050330101154.GA19176@redhat.com>
<424A7E4D.4020702@redhat.com> <20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
Message-ID: <20050330130351.435c8cde.bugs.michael@gmx.net>
On Wed, 30 Mar 2005 13:01:36 +0200, Michael Schwendt wrote:
> pkg-config --cflags --ldflags gamin
should read: pkg-config --cflags --libs gamin
$ pkg-config --cflags --libs gamin
-pthread -I/usr/include/fam -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -lgamin-1 -lgthread-2.0 -lglib-2.0
From veillard at redhat.com Wed Mar 30 12:45:59 2005
From: veillard at redhat.com (Daniel Veillard)
Date: Wed, 30 Mar 2005 07:45:59 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <20050330130136.19ec17e9.bugs.michael@gmx.net>
References: <424A769C.3040908@redhat.com> <20050330101154.GA19176@redhat.com>
<424A7E4D.4020702@redhat.com> <20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
Message-ID: <20050330124559.GE19176@redhat.com>
On Wed, Mar 30, 2005 at 01:01:36PM +0200, Michael Schwendt wrote:
> On Wed, 30 Mar 2005 05:44:34 -0500, Daniel Veillard wrote:
>
> > Okay I have only one normative text for what pkgconfig is all about:
> >
> > man pkg-config
> > -------------------------
> > The pkg-config program is used to retrieve information about installed
> > libraries in the system. It is typically used to compile and link
> > against one or more libraries. Here is a typical usage scenario in a
> > Makefile:
> > -------------------------
> >
> > pkg-config is there to get library dependancies. Program needing fam or
> > gamin support need it to get the libraries to link to. The output of
> > pkgconfig cflags or link must *NOT* show glib output, even if from a
> > packaging level, gamin requires glib for the server side. The fact that
> > KDE requires fam or gamin, does not mean it should link against glib.
> > So without further detailed information allowing to disambiguate using
> > pkgconfig for it's original goal of simplifying compiling and linking from
> > the added use as a packaging dependancy, bug #152486 is a WONTFIX for me.
>
> Bug-specific replies are better added in bugzilla. I replied to #152486
The underlying concern I have is that pkg-config is self described as
a tool for libraries dependancies, and the reports I get here are about
packages dependancies. There can be good reasons why both are not the same.
I still don't have an explanation why both semantic are pushed as a
being the same distro wide, nor what I misssed assuming I got something
wrong.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
From pnasrat at redhat.com Wed Mar 30 13:10:28 2005
From: pnasrat at redhat.com (Paul Nasrat)
Date: Wed, 30 Mar 2005 14:10:28 +0100
Subject: RFD: kernel-devel package improvements
In-Reply-To:
References: <1110909825.26174.173.camel@bobcat.mine.nu>
<1112041958.19155.11.camel@bobcat.mine.nu>
Message-ID: <1112188228.27816.62.camel@anu.eridu>
On Tue, 2005-03-29 at 14:57 -0500, Rik van Riel wrote:
> On Mon, 28 Mar 2005, Ville Skytt? wrote:
> And indeed, RPM isn't able to install both the i586 and
> i686 version of the kernel-devel package, even though
> there are no file conflicts.
>
> # rpm -ivh i686/kernel-devel-2.6.11-1.1208_FC4.i686.rpm i586/kernel-devel-2.6.11-1.1208_FC4.i586.rpm
> warning: package kernel-devel = 2.6.11-1.1208_FC4 was already added, skipping kernel-devel < 2.6.11-1.1208_FC4
Try in two seperate runs rather than the same transaction.
> error: error reading from file i586/kernel-devel-2.6.11-1.1208_FC4.i586.rpm
>
> Note that the "error reading file" seems to be caused
> by something inside RPM, since I can cat the file just
> fine.
Hmm, bugzilla against RPM please.
Paul
From mclasen at redhat.com Wed Mar 30 13:43:38 2005
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 30 Mar 2005 08:43:38 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <20050330124559.GE19176@redhat.com>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
Message-ID: <1112190219.28956.57.camel@golem.boston.redhat.com>
On Wed, 2005-03-30 at 07:45 -0500, Daniel Veillard wrote:
> On Wed, Mar 30, 2005 at 01:01:36PM +0200, Michael Schwendt wrote:
> > On Wed, 30 Mar 2005 05:44:34 -0500, Daniel Veillard wrote:
> >
> > > Okay I have only one normative text for what pkgconfig is all about:
> > >
> > > man pkg-config
> > > -------------------------
> > > The pkg-config program is used to retrieve information about installed
> > > libraries in the system. It is typically used to compile and link
> > > against one or more libraries. Here is a typical usage scenario in a
> > > Makefile:
> > > -------------------------
> > >
> > > pkg-config is there to get library dependancies. Program needing fam or
> > > gamin support need it to get the libraries to link to. The output of
> > > pkgconfig cflags or link must *NOT* show glib output, even if from a
> > > packaging level, gamin requires glib for the server side. The fact that
> > > KDE requires fam or gamin, does not mean it should link against glib.
> > > So without further detailed information allowing to disambiguate using
> > > pkgconfig for it's original goal of simplifying compiling and linking from
> > > the added use as a packaging dependancy, bug #152486 is a WONTFIX for me.
> >
> > Bug-specific replies are better added in bugzilla. I replied to #152486
>
> The underlying concern I have is that pkg-config is self described as
> a tool for libraries dependancies, and the reports I get here are about
> packages dependancies. There can be good reasons why both are not the same.
> I still don't have an explanation why both semantic are pushed as a
> being the same distro wide, nor what I misssed assuming I got something
> wrong.
Daniel,
.pc files contain dependencies, e.g. the gdk-pixbuf-2.0.pc file has the
line
Requires: gobject-2.0,gmodule-no-export-2.0
which means you'll get errors from pgk-config if you try to use the gdk-
pixbuf-2.0.pc file without having glib-devel installed (which contains
the gobject-2.0.pc and gmodule-no-export-2.0.pc files). Since rpm does
not pick up these dependencies on its own, you need to add an explict
Requires: glib-devel
line to the gdk-pixbuf-devel spec portion.
As you can see, library dependencies are not the same as package
dependencies, but pkg-config does a good job of translating the former
into the latter :-(
Matthias
From mitr at redhat.com Wed Mar 30 14:01:48 2005
From: mitr at redhat.com (Miloslav Trmac)
Date: Wed, 30 Mar 2005 16:01:48 +0200
Subject: Missing pkgconfig dependencies
In-Reply-To: <1112190219.28956.57.camel@golem.boston.redhat.com>
References: <424A769C.3040908@redhat.com> <20050330101154.GA19176@redhat.com>
<424A7E4D.4020702@redhat.com> <20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
Message-ID: <20050330140148.GA5240@amilo>
On Wed, Mar 30, 2005 at 08:43:38AM -0500, Matthias Clasen wrote:
> .pc files contain dependencies, e.g. the gdk-pixbuf-2.0.pc file has the
> line
>
> Requires: gobject-2.0,gmodule-no-export-2.0
>
> which means you'll get errors from pgk-config if you try to use the gdk-
> pixbuf-2.0.pc file without having glib-devel installed (which contains
> the gobject-2.0.pc and gmodule-no-export-2.0.pc files). Since rpm does
> not pick up these dependencies on its own,
Wouldn't It Be Cool(tm) if rpm did pick these dependencies automatically?
for i in $RPM_BUILD_DIR{%{_libdir},%{_datadir}}/pkgconfig/*.pc; do
set -- $(sed -n 's/^Requires: //p' < "$i")
for dep; do
f=%{_libdir}/pkgconfig/$dep.pc
[ -f "$f" ] && { rpm -qf "$f"; continue; }
f=%{_datadir}/pkgconfig/$dep.pc
[ -f "$f" ] && { rpm -qf "$f"; continue; }
echo "pkg-config file $dep.pc not found" >&2
done
done
Anyone care to integrate the above into the RPM scripts?
Mirek
From jspaleta at gmail.com Wed Mar 30 14:12:51 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Wed, 30 Mar 2005 09:12:51 -0500
Subject: xsri package available to any interested parties to maintain
In-Reply-To: <1112173593.1531.35.camel@bnocera.surrey.redhat.com>
References:
<1112173593.1531.35.camel@bnocera.surrey.redhat.com>
Message-ID: <604aa79105033006122b4a8f80@mail.gmail.com>
On Wed, 30 Mar 2005 10:06:33 +0100, Bastien Nocera
> Are the dependencies on it in gdm, firstboot and system-config-display
> gone in rawhide?
>
not yet
rpm -e --test xsri
error: Failed dependencies:
xsri is needed by (installed) firstboot-1.3.39-3.noarch
xsri is needed by (installed) system-config-display-1.0.25-3.noarch
xsri >= 1:2.0.2 is needed by (installed) gdm-2.6.0.7-8.i386
I'm pretty sure the requires in firstboot is no longer valid.
grep xsri `rpm -ql firstboot` returns clean
grep xsri `rpm -ql gdm` returns a hit on /etc/X11/gdm/Init/:0
but the section referencing xsri is commented out.
grep xsri `rpm -ql system-config-display` returns a hit on
/usr/share/system-config-display/xconf.py
the call is not commented out at line 374
os.system("xsri --scale-width=100 --scale-height=100
/usr/share/system-config-display/pixmaps/lightrays.png")
Naively, right now s-c-display is the only package of the 3 that
still attempts to use xrsi, so the firstboot and gdm package requires
can probably be dropped.
-jef
From mclasen at redhat.com Wed Mar 30 14:23:54 2005
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 30 Mar 2005 09:23:54 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <20050330140148.GA5240@amilo>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo>
Message-ID: <1112192634.28956.59.camel@golem.boston.redhat.com>
On Wed, 2005-03-30 at 16:01 +0200, Miloslav Trmac wrote:
> On Wed, Mar 30, 2005 at 08:43:38AM -0500, Matthias Clasen wrote:
> > .pc files contain dependencies, e.g. the gdk-pixbuf-2.0.pc file has the
> > line
> >
> > Requires: gobject-2.0,gmodule-no-export-2.0
> >
> > which means you'll get errors from pgk-config if you try to use the gdk-
> > pixbuf-2.0.pc file without having glib-devel installed (which contains
> > the gobject-2.0.pc and gmodule-no-export-2.0.pc files). Since rpm does
> > not pick up these dependencies on its own,
> Wouldn't It Be Cool(tm) if rpm did pick these dependencies automatically?
>
> for i in $RPM_BUILD_DIR{%{_libdir},%{_datadir}}/pkgconfig/*.pc; do
> set -- $(sed -n 's/^Requires: //p' < "$i")
> for dep; do
> f=%{_libdir}/pkgconfig/$dep.pc
> [ -f "$f" ] && { rpm -qf "$f"; continue; }
> f=%{_datadir}/pkgconfig/$dep.pc
> [ -f "$f" ] && { rpm -qf "$f"; continue; }
> echo "pkg-config file $dep.pc not found" >&2
> done
> done
>
Nice idea, but you'll run into difficulties with things like:
Requires: gdk-${target}-2.0 atk
From bnocera at redhat.com Wed Mar 30 14:28:01 2005
From: bnocera at redhat.com (Bastien Nocera)
Date: Wed, 30 Mar 2005 15:28:01 +0100
Subject: STR working out of the box
In-Reply-To: <20050315184935.GF12363@nostromo.devel.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<20050314170448.GE10338@nostromo.devel.redhat.com>
<1110869044.14869.201.camel@daxter.boston.redhat.com>
<20050315184935.GF12363@nostromo.devel.redhat.com>
Message-ID: <1112192881.1531.87.camel@bnocera.surrey.redhat.com>
On Tue, 2005-03-15 at 13:49 -0500, Bill Nottingham wrote:
> David Zeuthen (davidz at redhat.com) said:
> > > > 3. vbetool is kind of evil; it's a workaround for broken video
> > > > drivers and the mess that is X.org / kernel interaction wrt.
> > > > to video hardware (so, vbetool becomes the 3th or 4th player
> > > > directly touching hardware. Yay!). I expect we need to add
> > > > radeontool at some point too.
> > >
> > > Note that vbetool is only for certain cards. There are other tools
> > > for other cards.
> >
> > Apart from radeontool?
>
> radeontool/vbetool should cover ATI & nVidia. Hopefully everyone
> else doesn't need them. :)
vbetool seems to work fine on my laptop, with a Radeon 9700 Mobility. I
had to switch to a VT and back to get X displaying properly, but I had
the same issue with the "video_post" tool some Intel guys gave me.
--
Bastien Nocera
From bugs.michael at gmx.net Wed Mar 30 15:00:13 2005
From: bugs.michael at gmx.net (Michael Schwendt)
Date: Wed, 30 Mar 2005 17:00:13 +0200
Subject: Missing pkgconfig dependencies
In-Reply-To: <1112192634.28956.59.camel@golem.boston.redhat.com>
References: <424A769C.3040908@redhat.com> <20050330101154.GA19176@redhat.com>
<424A7E4D.4020702@redhat.com> <20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo>
<1112192634.28956.59.camel@golem.boston.redhat.com>
Message-ID: <20050330170013.45b5ced3.bugs.michael@gmx.net>
On Wed, 30 Mar 2005 09:23:54 -0500, Matthias Clasen wrote:
> On Wed, 2005-03-30 at 16:01 +0200, Miloslav Trmac wrote:
> > On Wed, Mar 30, 2005 at 08:43:38AM -0500, Matthias Clasen wrote:
> > > .pc files contain dependencies, e.g. the gdk-pixbuf-2.0.pc file has the
> > > line
> > >
> > > Requires: gobject-2.0,gmodule-no-export-2.0
> > >
> > > which means you'll get errors from pgk-config if you try to use the gdk-
> > > pixbuf-2.0.pc file without having glib-devel installed (which contains
> > > the gobject-2.0.pc and gmodule-no-export-2.0.pc files). Since rpm does
> > > not pick up these dependencies on its own,
> > Wouldn't It Be Cool(tm) if rpm did pick these dependencies automatically?
> >
> > for i in $RPM_BUILD_DIR{%{_libdir},%{_datadir}}/pkgconfig/*.pc; do
> > set -- $(sed -n 's/^Requires: //p' < "$i")
> > for dep; do
> > f=%{_libdir}/pkgconfig/$dep.pc
> > [ -f "$f" ] && { rpm -qf "$f"; continue; }
> > f=%{_datadir}/pkgconfig/$dep.pc
> > [ -f "$f" ] && { rpm -qf "$f"; continue; }
> > echo "pkg-config file $dep.pc not found" >&2
> > done
> > done
> >
>
> Nice idea, but you'll run into difficulties with things like:
>
> Requires: gdk-${target}-2.0 atk
Also with comma-separated lists and versioned ones like:
Requires: atk >= 2.0, glib-2.0
The Perl fragment I use to parse pkgconfig files has not been changed
for a long time:
open (PCFILE, "< $pc") or die "Unable to open: $pc\n";
while ( ) {
chomp;
# Crude hack to collect and substitute macros.
if ( /([a-z_]+)=(.*)/ ) {
$macros{$1} = $2;
}
while ( /(\${([a-z_]+)})/ ) {
$a = $1;
$b = $2;
$a =~ s/\$/\\\$/g;
s/$a/$macros{$b}/g;
}
/^Requires/ or next;
s/^Requires:\s*//;
s/,/ /g; # pkgconfig permits space/comma separate lists
s/>*=\s+\d+(\.\d+)*//g; # get rid of versions like "foo >= 1.0"
(my @req) = split;
push @requires, @req;
}
From katzj at redhat.com Wed Mar 30 15:32:50 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 30 Mar 2005 10:32:50 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <20050330140148.GA5240@amilo>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo>
Message-ID: <1112196771.4513.1.camel@bree.local.net>
On Wed, 2005-03-30 at 16:01 +0200, Miloslav Trmac wrote:
> Wouldn't It Be Cool(tm) if rpm did pick these dependencies automatically?
[snip]
> Anyone care to integrate the above into the RPM scripts?
Nalin has a patch for pkg-config[1] to make it so that it could print
out the bits you need to integrate nicely with a find-requires. I think
he also had the redhat-rpm-config bits as well.
Jeremy
[1] https://bugs.freedesktop.org/show_bug.cgi?id=2458
From mclasen at redhat.com Wed Mar 30 15:40:57 2005
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 30 Mar 2005 10:40:57 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <1112196771.4513.1.camel@bree.local.net>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo> <1112196771.4513.1.camel@bree.local.net>
Message-ID: <1112197257.28956.61.camel@golem.boston.redhat.com>
On Wed, 2005-03-30 at 10:32 -0500, Jeremy Katz wrote:
> On Wed, 2005-03-30 at 16:01 +0200, Miloslav Trmac wrote:
> > Wouldn't It Be Cool(tm) if rpm did pick these dependencies automatically?
> [snip]
> > Anyone care to integrate the above into the RPM scripts?
>
> Nalin has a patch for pkg-config[1] to make it so that it could print
> out the bits you need to integrate nicely with a find-requires. I think
> he also had the redhat-rpm-config bits as well.
>
> Jeremy
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=2458
>
Should we put that patch in our pkgconfig package ? Upstream development
of pkgconfig seems dead...
Matthias
From davidz at redhat.com Wed Mar 30 15:46:30 2005
From: davidz at redhat.com (David Zeuthen)
Date: Wed, 30 Mar 2005 10:46:30 -0500
Subject: STR working out of the box
In-Reply-To: <1112192881.1531.87.camel@bnocera.surrey.redhat.com>
References: <1110698182.8327.69.camel@daxter.boston.redhat.com>
<20050314170448.GE10338@nostromo.devel.redhat.com>
<1110869044.14869.201.camel@daxter.boston.redhat.com>
<20050315184935.GF12363@nostromo.devel.redhat.com>
<1112192881.1531.87.camel@bnocera.surrey.redhat.com>
Message-ID: <1112197590.3952.2.camel@daxter.boston.redhat.com>
On Wed, 2005-03-30 at 15:28 +0100, Bastien Nocera wrote:
> On Tue, 2005-03-15 at 13:49 -0500, Bill Nottingham wrote:
> > David Zeuthen (davidz at redhat.com) said:
> > > > > 3. vbetool is kind of evil; it's a workaround for broken video
> > > > > drivers and the mess that is X.org / kernel interaction wrt.
> > > > > to video hardware (so, vbetool becomes the 3th or 4th player
> > > > > directly touching hardware. Yay!). I expect we need to add
> > > > > radeontool at some point too.
> > > >
> > > > Note that vbetool is only for certain cards. There are other tools
> > > > for other cards.
> > >
> > > Apart from radeontool?
> >
> > radeontool/vbetool should cover ATI & nVidia. Hopefully everyone
> > else doesn't need them. :)
>
> vbetool seems to work fine on my laptop, with a Radeon 9700 Mobility. I
> had to switch to a VT and back to get X displaying properly, but I had
> the same issue with the "video_post" tool some Intel guys gave me.
>
I thought the suspend script that I posted took care of this?
Btw, I've got an update of all this (removing the white lists, moving
what action to do into battstat applet) that I will post in a few days
so stay tuned.
Cheers,
David
From katzj at redhat.com Wed Mar 30 15:59:28 2005
From: katzj at redhat.com (Jeremy Katz)
Date: Wed, 30 Mar 2005 10:59:28 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <1112197257.28956.61.camel@golem.boston.redhat.com>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo> <1112196771.4513.1.camel@bree.local.net>
<1112197257.28956.61.camel@golem.boston.redhat.com>
Message-ID: <1112198369.4513.15.camel@bree.local.net>
On Wed, 2005-03-30 at 10:40 -0500, Matthias Clasen wrote:
> On Wed, 2005-03-30 at 10:32 -0500, Jeremy Katz wrote:
> > [1] https://bugs.freedesktop.org/show_bug.cgi?id=2458
>
> Should we put that patch in our pkgconfig package ? Upstream development
> of pkgconfig seems dead...
Sounds like a plan to me.
Jeremy
From dcbw at redhat.com Wed Mar 30 20:06:56 2005
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 30 Mar 2005 15:06:56 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <1112197257.28956.61.camel@golem.boston.redhat.com>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo> <1112196771.4513.1.camel@bree.local.net>
<1112197257.28956.61.camel@golem.boston.redhat.com>
Message-ID: <1112213216.1347.0.camel@dcbw.boston.redhat.com>
On Wed, 2005-03-30 at 10:40 -0500, Matthias Clasen wrote:
> On Wed, 2005-03-30 at 10:32 -0500, Jeremy Katz wrote:
> > On Wed, 2005-03-30 at 16:01 +0200, Miloslav Trmac wrote:
> > > Wouldn't It Be Cool(tm) if rpm did pick these dependencies automatically?
> > [snip]
> > > Anyone care to integrate the above into the RPM scripts?
> >
> > Nalin has a patch for pkg-config[1] to make it so that it could print
> > out the bits you need to integrate nicely with a find-requires. I think
> > he also had the redhat-rpm-config bits as well.
> >
> > Jeremy
> >
> > [1] https://bugs.freedesktop.org/show_bug.cgi?id=2458
> >
>
> Should we put that patch in our pkgconfig package ? Upstream development
> of pkgconfig seems dead...
hp has commented many times that pkgconfig is the world's easiest
package to maintain because it does exactly what people want, and has
done so for years without the need for change... so its not that
development is dead, its that for once on Linux, the software "Just
Works" :)
Dan
From mclasen at redhat.com Wed Mar 30 20:11:51 2005
From: mclasen at redhat.com (Matthias Clasen)
Date: Wed, 30 Mar 2005 15:11:51 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <1112213216.1347.0.camel@dcbw.boston.redhat.com>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo> <1112196771.4513.1.camel@bree.local.net>
<1112197257.28956.61.camel@golem.boston.redhat.com>
<1112213216.1347.0.camel@dcbw.boston.redhat.com>
Message-ID: <1112213511.10574.14.camel@golem.boston.redhat.com>
On Wed, 2005-03-30 at 15:06 -0500, Dan Williams wrote:
> On Wed, 2005-03-30 at 10:40 -0500, Matthias Clasen wrote:
> > On Wed, 2005-03-30 at 10:32 -0500, Jeremy Katz wrote:
> > > On Wed, 2005-03-30 at 16:01 +0200, Miloslav Trmac wrote:
> > > > Wouldn't It Be Cool(tm) if rpm did pick these dependencies automatically?
> > > [snip]
> > > > Anyone care to integrate the above into the RPM scripts?
> > >
> > > Nalin has a patch for pkg-config[1] to make it so that it could print
> > > out the bits you need to integrate nicely with a find-requires. I think
> > > he also had the redhat-rpm-config bits as well.
> > >
> > > Jeremy
> > >
> > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=2458
> > >
> >
> > Should we put that patch in our pkgconfig package ? Upstream development
> > of pkgconfig seems dead...
>
> hp has commented many times that pkgconfig is the world's easiest
> package to maintain because it does exactly what people want, and has
> done so for years without the need for change... so its not that
> development is dead, its that for once on Linux, the software "Just
> Works" :)
>
Too late, I already included that patch...
From wtogami at redhat.com Thu Mar 31 02:34:32 2005
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 30 Mar 2005 16:34:32 -1000
Subject: RFD: kernel-devel package improvements
In-Reply-To:
References: <1110909825.26174.173.camel@bobcat.mine.nu> <1112041958.19155.11.camel@bobcat.mine.nu>
Message-ID: <424B61B8.4020008@redhat.com>
Rik van Riel wrote:
>
>
> And indeed, RPM isn't able to install both the i586 and
> i686 version of the kernel-devel package, even though
> there are no file conflicts.
>
> # rpm -ivh i686/kernel-devel-2.6.11-1.1208_FC4.i686.rpm i586/kernel-devel-2.6.11-1.1208_FC4.i586.rpm
> warning: package kernel-devel = 2.6.11-1.1208_FC4 was already added, skipping kernel-devel < 2.6.11-1.1208_FC4
> error: error reading from file i586/kernel-devel-2.6.11-1.1208_FC4.i586.rpm
>
> Note that the "error reading file" seems to be caused
> by something inside RPM, since I can cat the file just
> fine.
>
> I really don't know what the nicest way to fix this bug
> would be, so I guess I'd throw it out for discussion. The
> naive way would be to add the architecture to the name of
> the package - but that's butt ugly and sure to break things
> left and right.
>
> Any other ideas ?
My thought is that "multiple" isn't as important as "any". We need the
ability to install any kernel-devel of a specific target architecture,
version and release.
apt is able to install any specific version of a package with "apt-get
install kernel-VERSION-RELEASE" even if the one you are specifying is
not the newest. Is yum able to do this too?
Warren Togami
wtogami at redhat.com
From wtogami at redhat.com Thu Mar 31 02:40:20 2005
From: wtogami at redhat.com (Warren Togami)
Date: Wed, 30 Mar 2005 16:40:20 -1000
Subject: Missing pkgconfig dependencies
In-Reply-To: <20050330140148.GA5240@amilo>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com> <20050330130136.19ec17e9.bugs.michael@gmx.net> <20050330124559.GE19176@redhat.com> <1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo>
Message-ID: <424B6314.7070604@redhat.com>
Miloslav Trmac wrote:
>
> Wouldn't It Be Cool(tm) if rpm did pick these dependencies automatically?
>
> for i in $RPM_BUILD_DIR{%{_libdir},%{_datadir}}/pkgconfig/*.pc; do
> set -- $(sed -n 's/^Requires: //p' < "$i")
> for dep; do
> f=%{_libdir}/pkgconfig/$dep.pc
> [ -f "$f" ] && { rpm -qf "$f"; continue; }
> f=%{_datadir}/pkgconfig/$dep.pc
> [ -f "$f" ] && { rpm -qf "$f"; continue; }
> echo "pkg-config file $dep.pc not found" >&2
> done
> done
>
> Anyone care to integrate the above into the RPM scripts?
> Mirek
May I warn that whatever implementation is chosen, this is not an easy
problem to fully automate. Regular software packages (not development)
must NOT have deps on -devel packages. Automated script in rpmbuild
would need to only add deps to -devel packages, and only if -devel
packages are split. But then there are a whole bunch of exceptions to
this. It is simply not this easy to automate this and do the right thing.
Warren Togami
wtogami at redhat.com
From sopwith at redhat.com Thu Mar 31 03:19:06 2005
From: sopwith at redhat.com (Elliot Lee)
Date: Wed, 30 Mar 2005 22:19:06 -0500 (EST)
Subject: Call for FC4t2 release notes!
Message-ID:
Hey all,
Just a reminder that there's just under a week left to complete release
notes for Fedora Core 4 test2.
The best way to help with the release notes is to join the Fedora Docs
Project. You can find more info at
http://fedoraproject.org/wiki/FedoraDocsProject - your help is definitely
wanted!
Actually submitting a release notes change means going to
http://fedoraproject.org/wiki/FedoraDocs_2fRelNotes_2fCore4Test1RelNotes
and clicking on the 'pre-filled bugzilla request' link. Or you can e-mail
relnotes at fedoraproject.org, and Karsten Wade (the courageous new FDP
leader) will handle your e-mail. Please use bugzilla if at all possible.
What information needs submitting for release notes?
. Current information on hardware requirements
. Information on changes that have occurred since Fedora Core 3
. Explanations of the package additions and removals
. Removals of information that is no longer necessary for FC4
. General "I think users need to know this information about this
release" submissions.
Thanks in advance,
-- Elliot
From skvidal at phy.duke.edu Thu Mar 31 04:49:05 2005
From: skvidal at phy.duke.edu (seth vidal)
Date: Wed, 30 Mar 2005 23:49:05 -0500
Subject: RFD: kernel-devel package improvements
In-Reply-To: <424B61B8.4020008@redhat.com>
References: <1110909825.26174.173.camel@bobcat.mine.nu>
<1112041958.19155.11.camel@bobcat.mine.nu>
<424B61B8.4020008@redhat.com>
Message-ID: <1112244545.30867.60.camel@cutter>
> My thought is that "multiple" isn't as important as "any". We need the
> ability to install any kernel-devel of a specific target architecture,
> version and release.
>
> apt is able to install any specific version of a package with "apt-get
> install kernel-VERSION-RELEASE" even if the one you are specifying is
> not the newest. Is yum able to do this too?
should work just fine. all the ver-rel.arch options are able to be
specified on the cli.
If you started using yum instead of apt you might learn that faster.
-sv
From oliver at linux-kernel.at Thu Mar 31 05:33:20 2005
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 31 Mar 2005 07:33:20 +0200
Subject: apg
In-Reply-To:
Message-ID: <200503310532.j2V5WjMj007691@pils.linux-kernel.at>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi fc-maintainers!
I wonder if there is a real maintainer for apg? Matthias, you where the last
who updated apg...
I'd like to update it to v 2.3.0 - it's out since 01/09/2003 (see
http://www.adel.nursat.kz/apg/ for yourself).
I allready have a rpm available at my site, which does also include
'support'
for xinetd.
See the SRPM:
http://rpms.linux-kernel.at/RPMS/lkernAT/SRPMS/apg-2.3.0b-2.src.rpm
The RPM for fcdev:
http://rpms.linux-kernel.at/RPMS/lkernAT/fedora/core/development/i386/apg-2.
3.0b
- -2.i386.rpm
The RPM for fc3:
http://rpms.linux-kernel.at/RPMS/lkernAT/fedora/core/development/i386/apg-2.
3.0b
- -2.i386.rpm
Or for RH8:
http://rpms.linux-kernel.at/RPMS/lkernAT/redhat/extras/8.0/i386/apg-2.3.0b-2
.i38
6.rpm
:-)
I'm also thinking of splitting apg into apg and apg-server - RFC regarding
this.
Let me know.
Best,
Oliver
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQkuLoMVjeRnvJSlDEQK7FgCfXKh46jb9UBtXayeIyCFSuxzbeDQAnRVw
UsPcfTGpjL9iTfpPj/GkptLp
=xu1D
-----END PGP SIGNATURE-----
From mitr at redhat.com Thu Mar 31 06:59:59 2005
From: mitr at redhat.com (Miloslav Trmac)
Date: Thu, 31 Mar 2005 08:59:59 +0200
Subject: Missing pkgconfig dependencies
In-Reply-To: <424B6314.7070604@redhat.com>
References: <424A769C.3040908@redhat.com> <20050330101154.GA19176@redhat.com>
<424A7E4D.4020702@redhat.com> <20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo> <424B6314.7070604@redhat.com>
Message-ID: <20050331065959.GA5292@amilo>
On Wed, Mar 30, 2005 at 04:40:20PM -1000, Warren Togami wrote:
> May I warn that whatever implementation is chosen, this is not an easy
> problem to fully automate. Regular software packages (not development)
> must NOT have deps on -devel packages.
Why? I don't think it is more important to keep the dependency tree "clean"
than to keep pkg-config working. If it bothers someone, the package will
eventually get split.
Mirek
From jspaleta at gmail.com Thu Mar 31 14:22:58 2005
From: jspaleta at gmail.com (Jeff Spaleta)
Date: Thu, 31 Mar 2005 09:22:58 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <20050331065959.GA5292@amilo>
References: <424A769C.3040908@redhat.com> <20050330101154.GA19176@redhat.com>
<424A7E4D.4020702@redhat.com> <20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo> <424B6314.7070604@redhat.com>
<20050331065959.GA5292@amilo>
Message-ID: <604aa791050331062216c4d0fb@mail.gmail.com>
On Thu, 31 Mar 2005 08:59:59 +0200, Miloslav Trmac wrote:
> Why? I don't think it is more important to keep the dependency tree "clean"
> than to keep pkg-config working. If it bothers someone, the package will
> eventually get split.
If anything... this will help identify which packages should be split
and give user a little leverage to harsh maintainers in public forums
about splitting off a -devel subpackage. If i runtime package foo
ends up pulling in bar-devel package using this automated tagging of
requirements.. clearly foo is including crap that should be in
foo-devel. If the the long term ideal goal is both clean dep trees as
well as complete seperation of runtime and devel components, i think
this extra requirements check helps identify both types of packaging
problems.
Rawhide would be a very good place to test this sort of automation out
to identify a list of problem packages that are pulling in -devel
requirements so those packages can get fixed. If the new check is
incredibly problematic (more than say 10% of the runtime packages),
disable this automated requires check before a final release and
rebuild the package set. At the very least you end up knowing which
packages are screwed up and need to be split so you can work on that
in rawhide.
-jef"and knowing is half the battle.. Yo Joe!"
From pjones at redhat.com Thu Mar 31 15:13:00 2005
From: pjones at redhat.com (Peter Jones)
Date: Thu, 31 Mar 2005 10:13:00 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <424B6314.7070604@redhat.com>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo> <424B6314.7070604@redhat.com>
Message-ID: <1112281980.16858.22.camel@localhost.localdomain>
(Ccing spot, since he's packaging-standards czar)
On Wed, 2005-03-30 at 16:40 -1000, Warren Togami wrote:
> May I warn that whatever implementation is chosen, this is not an easy
> problem to fully automate. Regular software packages (not development)
> must NOT have deps on -devel packages. Automated script in rpmbuild
> would need to only add deps to -devel packages, and only if -devel
> packages are split. But then there are a whole bunch of exceptions to
> this. It is simply not this easy to automate this and do the right thing.
I don't think it's as hard as you think, but we do have to have some
(common sense) rules about packages containing pkgconfig files. That
being said, I'm not sure mitr's current implementation is quite the
right thing, either.
Here's a shot at the packaging rules for this:
1) "Provides" and "Requires" generated from pkg-config should be in a
pkgconfig namespace. That is, this:
vroomfondel:~$ pkg-config --print-provides glib-2.0
glib-2.0 = 2.6.3
Should translate into glib2-devel having:
Provides: pkgconfig(glib-2.0) = 2.6.3
In the spec file.
2) Spec files may not manually have Provides or Requires for anything in
the pkgconfig namespace.
3) Only development packages should add pkgconfig files which include
Provides or Requires. "Development packages" basically means
"$FOO-devel", but if a package *isn't* split, the main package can serve
this purpose. Rules for splitting or not are a separate discussion.
Are there any concerns you have that _aren't_ addressed by these rules?
In particular, I want to stress that this isn't right:
> Automated script in rpmbuild would need to only add deps to -devel
> packages, and only if -devel packages are split.
The problems with this are two fold: firstly, it doesn't matter if
they're split or not; pkg-config directly represents functionality, so
it's a very straightforward question: "does the package provide or
require $FOO?"
Which brings us to the second problem with your statement. If the
automated script adds something to a non-development package, the
package is providing a pkg-config script which supplies incorrect data.
--
Peter
From pjones at redhat.com Thu Mar 31 15:17:40 2005
From: pjones at redhat.com (Peter Jones)
Date: Thu, 31 Mar 2005 10:17:40 -0500
Subject: Missing pkgconfig dependencies
In-Reply-To: <1112281980.16858.22.camel@localhost.localdomain>
References: <424A769C.3040908@redhat.com>
<20050330101154.GA19176@redhat.com> <424A7E4D.4020702@redhat.com>
<20050330104434.GC19176@redhat.com>
<20050330130136.19ec17e9.bugs.michael@gmx.net>
<20050330124559.GE19176@redhat.com>
<1112190219.28956.57.camel@golem.boston.redhat.com>
<20050330140148.GA5240@amilo> <424B6314.7070604@redhat.com>
<1112281980.16858.22.camel@localhost.localdomain>
Message-ID: <1112282260.16858.24.camel@localhost.localdomain>
On Thu, 2005-03-31 at 10:13 -0500, Peter Jones wrote:
> (Ccing spot, since he's packaging-standards czar)
Hrm. Or not, apparently. I'll poke him and make sure he sees the
discussion.
--
Peter
From johnp at redhat.com Thu Mar 31 17:07:34 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Thu, 31 Mar 2005 12:07:34 -0500
Subject: Packages that require DBus
Message-ID: <1112288854.8735.4.camel@remedyz.boston.redhat.com>
I am building 0.32 in beehive right now. Packages that require dbus do
not have to recompile as there is no API or ABI changes. However, any
packages that specifically require a particular version of dbus (i.e.
dbus = 0.31) should change to using dbus >= 0.31. If the API changes
we now bump the so names so adding the >= will allow me to update dbus
without having to bother other package maintainers unless the so names
are bumped.
--
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com
From dcbw at redhat.com Thu Mar 31 17:47:10 2005
From: dcbw at redhat.com (Dan Williams)
Date: Thu, 31 Mar 2005 12:47:10 -0500
Subject: Packages that require DBus
In-Reply-To: <1112288854.8735.4.camel@remedyz.boston.redhat.com>
References: <1112288854.8735.4.camel@remedyz.boston.redhat.com>
Message-ID: <1112291230.18405.45.camel@dcbw.boston.redhat.com>
On Thu, 2005-03-31 at 12:07 -0500, John (J5) Palmieri wrote:
> I am building 0.32 in beehive right now. Packages that require dbus do
> not have to recompile as there is no API or ABI changes. However, any
> packages that specifically require a particular version of dbus (i.e.
> dbus = 0.31) should change to using dbus >= 0.31. If the API changes
> we now bump the so names so adding the >= will allow me to update dbus
> without having to bother other package maintainers unless the so names
> are bumped.
I assume this is for an FC3 update?
Dan
From johnp at redhat.com Thu Mar 31 18:13:45 2005
From: johnp at redhat.com (John (J5) Palmieri)
Date: Thu, 31 Mar 2005 13:13:45 -0500
Subject: Packages that require DBus
In-Reply-To: <1112291230.18405.45.camel@dcbw.boston.redhat.com>
References: <1112288854.8735.4.camel@remedyz.boston.redhat.com>
<1112291230.18405.45.camel@dcbw.boston.redhat.com>
Message-ID: <1112292825.8735.5.camel@remedyz.boston.redhat.com>
On Thu, 2005-03-31 at 12:47 -0500, Dan Williams wrote:
> On Thu, 2005-03-31 at 12:07 -0500, John (J5) Palmieri wrote:
> > I am building 0.32 in beehive right now. Packages that require dbus do
> > not have to recompile as there is no API or ABI changes. However, any
> > packages that specifically require a particular version of dbus (i.e.
> > dbus = 0.31) should change to using dbus >= 0.31. If the API changes
> > we now bump the so names so adding the >= will allow me to update dbus
> > without having to bother other package maintainers unless the so names
> > are bumped.
>
> I assume this is for an FC3 update?
No, just rawhide.
> Dan
>
> --
> Fedora-maintainers mailing list
> Fedora-maintainers at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-maintainers
--
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com
From oliver at linux-kernel.at Thu Mar 31 20:45:40 2005
From: oliver at linux-kernel.at (Oliver Falk)
Date: Thu, 31 Mar 2005 22:45:40 +0200
Subject: Libmcrypt not available on extras
Message-ID: <200503312045.j2VKjeVA020525@pils.linux-kernel.at>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
I wonder there is no libmcrypt package available at extras... Is anyone
interessted in managing?
There is a package from Dag Wieers available AFAIK, from wich we could
start...
- -
Oliver Falk
UNIX/Linux Systems Administrator
Autonomy Information Engineer
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQkxhTMVjeRnvJSlDEQJzBQCggJ7aS4LK8bERL1bYKMHSAHmKYYYAoIqi
1RxGl5m80XirITnNvYLdMv3I
=C52K
-----END PGP SIGNATURE-----