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-----