From paragn at fedoraproject.org Mon Jun 1 07:42:25 2009 From: paragn at fedoraproject.org (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=) Date: Mon, 1 Jun 2009 13:12:25 +0530 Subject: [Fedora-packaging] ISC license link need to be updated. Message-ID: Hi, I see that ISC license is not exist at link https://www.isc.org/index.pl?/sw/dhcp/dhcp-copyright.php but its now available at https://www.isc.org/software/license. Can someone update new link to https://fedoraproject.org/wiki/Licensing? Regards, Parag. From tcallawa at redhat.com Mon Jun 1 12:36:08 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 01 Jun 2009 08:36:08 -0400 Subject: [Fedora-packaging] ISC license link need to be updated. In-Reply-To: References: Message-ID: <4A23CB38.70400@redhat.com> On 06/01/2009 03:42 AM, Parag N(????) wrote: > Hi, > I see that ISC license is not exist at link > https://www.isc.org/index.pl?/sw/dhcp/dhcp-copyright.php but its now > available at https://www.isc.org/software/license. Can someone update > new link to https://fedoraproject.org/wiki/Licensing? Updated, thanks. ~spot From tmz at pobox.com Mon Jun 1 15:35:01 2009 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 1 Jun 2009 11:35:01 -0400 Subject: [Fedora-packaging] Packaging:SysVInitScript questions Message-ID: <20090601153501.GT28808@inocybe.localdomain> I was reading over Packaging:SysVInitScript to bring some packages into line with the current guidelines. The template and the text differ a bit on the reload function, or at least aren't very clear. The template includes: reload() { restart } [...] case "$1" in [...] reload) rh_status_q || exit 7 $1 ;; Later, in the 'Required Actions' section, reload is described: reload: reload the configuration of the service without actually stopping and restarting the service (if the service does not support this, do nothing) So, which is preferred? If I have a daemon that doesn't have any way to reload its configuration short of restarting, should we do as the template shows and call restart or should reload() be a no-op? In many current packages, reload() does a restart if there's no other way to reload the config. For the puppet init scripts I was looking at updating, I think keeping reload() as restart would cause the least amount of surprise, as that's what it does currently. But I'm curious what the prevailing wisdom is. On another subject, the 'Initialization of Environment Variables' section mentions that init scripts may be run by admins with non-standard environment variables, like PATH, and that the init script should set these to known/default values if needed. Would it be worth noting that PATH is explicitly set and exported in /etc/init.d/functions, so init scripts which source that don't need to worry about PATH, unless they need to extend the default PATH set in the function library (which is "/sbin:/usr/sbin:/bin:/usr/bin")? Lastly, does anyone know what tools use (or used) the processname: and config: tags? The current puppet init script contains these, just under description: and I'm wondering whether they are so old that we don't have to bother keeping them any longer. They've been listed as optional tags in /usr/share/doc/initscripts-*/sysvinitfiles for ages. I just don't know of anything that uses them. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There is no sweeter sound than the crumbling of your fellow man. -- Groucho Marx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Jun 1 17:56:03 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-15?q?Skytt=E4?=) Date: Mon, 1 Jun 2009 20:56:03 +0300 Subject: [Fedora-packaging] Packaging:SysVInitScript questions In-Reply-To: <20090601153501.GT28808@inocybe.localdomain> References: <20090601153501.GT28808@inocybe.localdomain> Message-ID: <200906012056.03817.ville.skytta@iki.fi> On Monday 01 June 2009, Todd Zullinger wrote: > Later, in the 'Required Actions' section, reload is described: > > reload: reload the configuration of the service without actually > stopping and restarting the service (if the service does not > support this, do nothing) > > So, which is preferred? If I have a daemon that doesn't have any way > to reload its configuration short of restarting, should we do as the > template shows and call restart or should reload() be a no-op? Neither, IMO. Instead, print an error message that "reload" is not supported and exit with status 3. See the template init script in rpmdevtools (invoke rpmdev-newinit if you have >= 7.2), and http://refspecs.linux- foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html In case of an error while processing any init-script action except for status, the init script shall print an error message and exit with a non- zero status code: [...] 3 unimplemented feature (for example, "reload") From tibbs at math.uh.edu Mon Jun 1 19:59:28 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 01 Jun 2009 14:59:28 -0500 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> (Chris Weyl's message of "Sun\, 31 May 2009 13\:06\:32 -0700") References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> Message-ID: >>>>> "CW" == Chris Weyl writes: CW> Following up to myself here, I've created a feature page that I CW> intend to submit to FESCo: Well, honestly I think that FESCo would just kick it back to the FPC, but if you prefer to submit it that way then I guess I'll keep it off of the FPC agenda. - J< From cweyl at alumni.drew.edu Mon Jun 1 20:27:52 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 1 Jun 2009 13:27:52 -0700 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> Message-ID: <7dd7ab490906011327n3acc01dfpf9e5271927a058be@mail.gmail.com> On Mon, Jun 1, 2009 at 12:59 PM, Jason L Tibbitts III wrote: > >>>>> "CW" == Chris Weyl writes: > > CW> Following up to myself here, I've created a feature page that I > CW> intend to submit to FESCo: > > Well, honestly I think that FESCo would just kick it back to the FPC, > but if you prefer to submit it that way then I guess I'll keep it off > of the FPC agenda. > If taking it through the FPC is the right way to do it, then let's do it that way. I only created the feature page as I wasn't seeing any feedback as to how it should be done. How do I get it on the FPC agenda? Simply by asking here? :) -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.skytta at iki.fi Thu Jun 4 15:58:38 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-15?q?Skytt=E4?=) Date: Thu, 4 Jun 2009 18:58:38 +0300 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> Message-ID: <200906041858.40970.ville.skytta@iki.fi> On Sunday 31 May 2009, Chris Weyl wrote: > https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering > > Any feedback, good or bad, would be appreciated. Jeff Johnson notes in https://bugzilla.redhat.com/show_bug.cgi?id=502403#c1 that PLD has a general mechanism for that as well already deployed. The feature page does not mention whether existing solutions have been examined, and if they have, why one of them has not been adopted but instead a new one has been implemented. I suggest adding such a section and examining at least PLD, SUSE and Mandriva. From atorkhov at gmail.com Thu Jun 4 21:44:12 2009 From: atorkhov at gmail.com (Alexey Torkhov) Date: Fri, 05 Jun 2009 01:44:12 +0400 Subject: [Fedora-packaging] Proposal to explicitly allow dos2unix Message-ID: <1244151852.27465.26.camel@localhost.localdomain> Hi. In guidelines in common errors section https://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors there is the following phrase: --- This error occurs because of DOS line breaks in a file. Fix it with sed in the %prep section: %{__sed} -i 's/\r//' src/somefile -- DONT use dos2unix, that can cause build fail on FC3. --- Because FC3 is not supported for long time, I'm proposing to change it to: --- This error occurs because of DOS line breaks in a file. Fix it with in the %prep section with sed: %{__sed} -i 's/\r//' src/somefile or dos2unix. --- Packaging draft is created at https://fedoraproject.org/wiki/PackagingDrafts/Dos2unix and added to DraftsTodo page. Waiting for comments. Alexey From rayvd at bludgeon.org Thu Jun 4 21:49:15 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Thu, 4 Jun 2009 14:49:15 -0700 Subject: [Fedora-packaging] Proposal to explicitly allow dos2unix In-Reply-To: <1244151852.27465.26.camel@localhost.localdomain> References: <1244151852.27465.26.camel@localhost.localdomain> Message-ID: <20090604214915.GA14607@bludgeon.org> On Fri, Jun 05, 2009 at 01:44:12AM +0400, Alexey Torkhov wrote: > Hi. > > In guidelines in common errors section > https://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors > there is the following phrase: > --- > This error occurs because of DOS line breaks in a file. Fix it with sed > in the %prep section: %{__sed} -i 's/\r//' src/somefile -- DONT use > dos2unix, that can cause build fail on FC3. > --- > > Because FC3 is not supported for long time, I'm proposing to change it > to: > --- > This error occurs because of DOS line breaks in a file. Fix it with in > the %prep section with sed: %{__sed} -i 's/\r//' > src/somefile or dos2unix. > --- > > Packaging draft is created at > https://fedoraproject.org/wiki/PackagingDrafts/Dos2unix > and added to DraftsTodo page. > > Waiting for comments. Since RHEL4 is based on FC3, would the dos2unix concerns be valid there was well? Presumably EPEL packages are covered by the packaging guidelines above... Ray From cweyl at alumni.drew.edu Fri Jun 5 01:47:50 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 4 Jun 2009 18:47:50 -0700 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: <200906041858.40970.ville.skytta@iki.fi> References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> <200906041858.40970.ville.skytta@iki.fi> Message-ID: <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> On Thu, Jun 4, 2009 at 8:58 AM, Ville Skytt? wrote: > On Sunday 31 May 2009, Chris Weyl wrote: > > > https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering > > > > Any feedback, good or bad, would be appreciated. > > Jeff Johnson notes in > https://bugzilla.redhat.com/show_bug.cgi?id=502403#c1 > that PLD has a general mechanism for that as well already deployed. The > feature page does not mention whether existing solutions have been > examined, > and if they have, why one of them has not been adopted but instead a new > one > has been implemented. I suggest adding such a section and examining at > least > PLD, SUSE and Mandriva. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > I've added this, though it's brief and based on a 30-minute examination of the two: https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering/OtherFilteringSystems The "PLD" one, as near as I can figure, is a direct implementation in the rpm5.org codebase. (Corrections welcome.) Tibbs suggested bringing this before the FPC... It sounds like it makes sense to do it this way, though I'm still unclear as to how to get it on the agenda. -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From cweyl at alumni.drew.edu Fri Jun 5 01:57:23 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 4 Jun 2009 18:57:23 -0700 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> <200906041858.40970.ville.skytta@iki.fi> <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> Message-ID: <7dd7ab490906041857h61dfc18bq84cc7d7e0b1fa26b@mail.gmail.com> On Thu, Jun 4, 2009 at 6:47 PM, Chris Weyl wrote: > I've added this, though it's brief and based on a 30-minute examination of > the two: > > > https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering/OtherFilteringSystems > And might be reasonably be termed "biased". :) Edits welcome. -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Fri Jun 5 04:42:38 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 04 Jun 2009 23:42:38 -0500 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> (Chris Weyl's message of "Thu\, 4 Jun 2009 18\:47\:50 -0700") References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> <200906041858.40970.ville.skytta@iki.fi> <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> Message-ID: >>>>> "CW" == Chris Weyl writes: CW> Tibbs suggested bringing this before the FPC... It sounds like it CW> makes sense to do it this way, though I'm still unclear as to how CW> to get it on the agenda. Well, I do post the instructions with the FPC agenda that I post to fedora-devel-list before every meeting: Read https://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure, Make a draft Add it to https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo But fear not, because I made sure it came up at our meeting on Tuesday. Basically, the concept is sound but we'd like to see it in the form of a set of packaging guidelines, and we'd like the changes to the perl provides behavior that are hidden down in the macro file to be split out and discussed separately. The discussion starts at https://fedoraproject.org/wiki/Packaging:Minutes/20090602#t12:39 - J< From atorkhov at gmail.com Fri Jun 5 07:11:31 2009 From: atorkhov at gmail.com (Alexey Torkhov) Date: Fri, 05 Jun 2009 11:11:31 +0400 Subject: [Fedora-packaging] Proposal to explicitly allow dos2unix In-Reply-To: <20090604214915.GA14607@bludgeon.org> References: <1244151852.27465.26.camel@localhost.localdomain> <20090604214915.GA14607@bludgeon.org> Message-ID: <1244185891.27465.69.camel@localhost.localdomain> On Thu, 2009-06-04 at 14:49 -0700, Ray Van Dolson wrote: > On Fri, Jun 05, 2009 at 01:44:12AM +0400, Alexey Torkhov wrote: > > Hi. > > > > In guidelines in common errors section > > https://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors > > there is the following phrase: > > --- > > This error occurs because of DOS line breaks in a file. Fix it with sed > > in the %prep section: %{__sed} -i 's/\r//' src/somefile -- DONT use > > dos2unix, that can cause build fail on FC3. > > --- > > > > Because FC3 is not supported for long time, I'm proposing to change it > > to: > > --- > > This error occurs because of DOS line breaks in a file. Fix it with in > > the %prep section with sed: %{__sed} -i 's/\r//' > > src/somefile or dos2unix. > > --- > > > > Packaging draft is created at > > https://fedoraproject.org/wiki/PackagingDrafts/Dos2unix > > and added to DraftsTodo page. > > > > Waiting for comments. > > Since RHEL4 is based on FC3, would the dos2unix concerns be valid there > was well? Presumably EPEL packages are covered by the packaging > guidelines above... Supposedly, the bug that results in fail is https://bugzilla.redhat.com/show_bug.cgi?id=150277 Updated the draft with the note that should be added to EPEL-specific guidelines. Alexey From pmatilai at laiskiainen.org Fri Jun 5 07:30:01 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 5 Jun 2009 10:30:01 +0300 (EEST) Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: <7dd7ab490906041857h61dfc18bq84cc7d7e0b1fa26b@mail.gmail.com> References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> <200906041858.40970.ville.skytta@iki.fi> <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> <7dd7ab490906041857h61dfc18bq84cc7d7e0b1fa26b@mail.gmail.com> Message-ID: On Thu, 4 Jun 2009, Chris Weyl wrote: > On Thu, Jun 4, 2009 at 6:47 PM, Chris Weyl wrote: > I've added this, though it's brief and based on a 30-minute > examination of the two: > > ?https://fedoraproject.org/wiki/Features/BetterRpmAutoReqProvFiltering/OtherFilte > ringSystems > > > > And might be reasonably be termed "biased". :)? Edits welcome. As a generic filtering mechanism this is a no-go, doing this breaks multilib as Fedora uses it: %global _use_internal_dependency_generator 0 \ Multilib-safe filtering mechanism needs to be bolted to the internal dependency generator, patches welcome... The other alternative would be killing the multilib coloring which would "only" require splitting all relevant packages to separate -libs etc to avoid elf32/elf64 binary collisions (which the multilib coloring currently hides) - Panu - From paul at city-fan.org Fri Jun 5 08:16:56 2009 From: paul at city-fan.org (Paul Howarth) Date: Fri, 05 Jun 2009 09:16:56 +0100 Subject: [Fedora-packaging] Proposal to explicitly allow dos2unix In-Reply-To: <1244185891.27465.69.camel@localhost.localdomain> References: <1244151852.27465.26.camel@localhost.localdomain> <20090604214915.GA14607@bludgeon.org> <1244185891.27465.69.camel@localhost.localdomain> Message-ID: <4A28D478.70302@city-fan.org> Alexey Torkhov wrote: > On Thu, 2009-06-04 at 14:49 -0700, Ray Van Dolson wrote: >> On Fri, Jun 05, 2009 at 01:44:12AM +0400, Alexey Torkhov wrote: >>> Hi. >>> >>> In guidelines in common errors section >>> https://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors >>> there is the following phrase: >>> --- >>> This error occurs because of DOS line breaks in a file. Fix it with sed >>> in the %prep section: %{__sed} -i 's/\r//' src/somefile -- DONT use >>> dos2unix, that can cause build fail on FC3. >>> --- >>> >>> Because FC3 is not supported for long time, I'm proposing to change it >>> to: >>> --- >>> This error occurs because of DOS line breaks in a file. Fix it with in >>> the %prep section with sed: %{__sed} -i 's/\r//' >>> src/somefile or dos2unix. >>> --- >>> >>> Packaging draft is created at >>> https://fedoraproject.org/wiki/PackagingDrafts/Dos2unix >>> and added to DraftsTodo page. >>> >>> Waiting for comments. >> Since RHEL4 is based on FC3, would the dos2unix concerns be valid there >> was well? Presumably EPEL packages are covered by the packaging >> guidelines above... > > Supposedly, the bug that results in fail is > https://bugzilla.redhat.com/show_bug.cgi?id=150277 > > Updated the draft with the note that should be added to EPEL-specific > guidelines. This issue is fixed in EL-4 too: https://bugzilla.redhat.com/show_bug.cgi?id=174016 Paul. From atorkhov at gmail.com Fri Jun 5 08:36:04 2009 From: atorkhov at gmail.com (Alexey Torkhov) Date: Fri, 05 Jun 2009 12:36:04 +0400 Subject: [Fedora-packaging] Proposal to explicitly allow dos2unix In-Reply-To: <4A28D478.70302@city-fan.org> References: <1244151852.27465.26.camel@localhost.localdomain> <20090604214915.GA14607@bludgeon.org> <1244185891.27465.69.camel@localhost.localdomain> <4A28D478.70302@city-fan.org> Message-ID: <1244190964.5688.8.camel@localhost.localdomain> On Fri, 2009-06-05 at 09:16 +0100, Paul Howarth wrote: > Alexey Torkhov wrote: > >>> Waiting for comments. > >> Since RHEL4 is based on FC3, would the dos2unix concerns be valid there > >> was well? Presumably EPEL packages are covered by the packaging > >> guidelines above... > > > > Supposedly, the bug that results in fail is > > https://bugzilla.redhat.com/show_bug.cgi?id=150277 > > > > Updated the draft with the note that should be added to EPEL-specific > > guidelines. > > This issue is fixed in EL-4 too: > > https://bugzilla.redhat.com/show_bug.cgi?id=174016 Ah, good, so dropping EPEL4-specific note. Alexey From cweyl at alumni.drew.edu Fri Jun 5 17:47:54 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 5 Jun 2009 10:47:54 -0700 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> <200906041858.40970.ville.skytta@iki.fi> <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> <7dd7ab490906041857h61dfc18bq84cc7d7e0b1fa26b@mail.gmail.com> Message-ID: <7dd7ab490906051047p27d3280dv16b6fce5b02d81be@mail.gmail.com> On Fri, Jun 5, 2009 at 12:30 AM, Panu Matilainen wrote: > > As a generic filtering mechanism this is a no-go, doing this breaks > multilib as Fedora uses it: > > %global _use_internal_dependency_generator 0 \ > > Multilib-safe filtering mechanism needs to be bolted to the internal > dependency generator, patches welcome... The other alternative would be > killing the multilib coloring which would "only" require splitting all > relevant packages to separate -libs etc to avoid elf32/elf64 binary > collisions (which the multilib coloring currently hides) > AFAIK disabling the internal dependency generator is the only way to filter dependencies of this nature (namely, solib provides). Is there some way we could either do the necessary file coloring external to rpm, segregate the dependency and coloring functionality, or gain access to modify the auto-prov/dep results (if not functionality) using the embedded lua interperter? Also, if I read this correctly, the only impact disabling the internal dependency generator has on multilib is when elf32/64 binaries are actually present in the package, right? -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jussilehtola at fedoraproject.org Sat Jun 6 11:17:04 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sat, 06 Jun 2009 14:17:04 +0300 Subject: [Fedora-packaging] java-devel pulls in gcj, not openjdk-devel Message-ID: <1244287024.6210.3.camel@localhost.localdomain> Hi, isn't nowadays openjdk-1.6.0-java-devel supposed to be the Java compiler we use always? I just noticed that the java-devel that is supposed to be used in spec files pulls in java-1.5.0-gcj-devel-1.5.0.0-28.fc11.x86_64 which made my jaxodraw compilation fail (gcj isn't supported). Shouldn't the provides: java-devel be removed from java-1.5.0-gcj-devel since this causes problems? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From rdieter at math.unl.edu Sat Jun 6 15:52:57 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 06 Jun 2009 10:52:57 -0500 Subject: [Fedora-packaging] java-devel pulls in gcj, not openjdk-devel In-Reply-To: <1244287024.6210.3.camel@localhost.localdomain> References: <1244287024.6210.3.camel@localhost.localdomain> Message-ID: <4A2A90D9.1080906@math.unl.edu> On 06/06/2009 06:17 AM, Jussi Lehtola wrote: > Hi, > > > isn't nowadays openjdk-1.6.0-java-devel supposed to be the Java compiler > we use always? > > I just noticed that the java-devel that is supposed to be used in spec > files pulls in > > java-1.5.0-gcj-devel-1.5.0.0-28.fc11.x86_64 > > which made my jaxodraw compilation fail (gcj isn't supported). Shouldn't > the provides: java-devel be removed from java-1.5.0-gcj-devel since this > causes problems? IMO, if your app can only use openjdk, then explictly BuildRequires: java-devel-openjdk -- Rex From jussilehtola at fedoraproject.org Sat Jun 6 16:33:03 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sat, 06 Jun 2009 19:33:03 +0300 Subject: [Fedora-packaging] java-devel pulls in gcj, not openjdk-devel In-Reply-To: <4A2A90D9.1080906@math.unl.edu> References: <1244287024.6210.3.camel@localhost.localdomain> <4A2A90D9.1080906@math.unl.edu> Message-ID: <1244305983.11446.4.camel@localhost.localdomain> On Sat, 2009-06-06 at 10:52 -0500, Rex Dieter wrote: > On 06/06/2009 06:17 AM, Jussi Lehtola wrote: > > Hi, > > > > > > isn't nowadays openjdk-1.6.0-java-devel supposed to be the Java compiler > > we use always? > > > > I just noticed that the java-devel that is supposed to be used in spec > > files pulls in > > > > java-1.5.0-gcj-devel-1.5.0.0-28.fc11.x86_64 > > > > which made my jaxodraw compilation fail (gcj isn't supported). Shouldn't > > the provides: java-devel be removed from java-1.5.0-gcj-devel since this > > causes problems? > > IMO, if your app can only use openjdk, then explictly > BuildRequires: java-devel-openjdk Yes, that's what I am using now (BR: java-1.6.0-openjdk-devel, R: java-1.6.0-openjdk), I was just wondering if the provides in gcj is a packaging bug.. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From overholt at redhat.com Sat Jun 6 19:00:53 2009 From: overholt at redhat.com (Andrew Overholt) Date: Sat, 6 Jun 2009 15:00:53 -0400 Subject: [Fedora-packaging] java-devel pulls in gcj, not openjdk-devel In-Reply-To: <1244305983.11446.4.camel@localhost.localdomain> References: <1244287024.6210.3.camel@localhost.localdomain> <4A2A90D9.1080906@math.unl.edu> <1244305983.11446.4.camel@localhost.localdomain> Message-ID: <20090606190053.GB649@redhat.com> * Jussi Lehtola [2009-06-06 12:34]: > Yes, that's what I am using now (BR: java-1.6.0-openjdk-devel, R: > java-1.6.0-openjdk), I was just wondering if the provides in gcj is a > packaging bug.. It's not really a bug. If you want to be JVM-agnostic, use: java-devel >= 1:1.6.0 Andrew From cweyl at alumni.drew.edu Sun Jun 7 20:09:41 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sun, 7 Jun 2009 13:09:41 -0700 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> <200906041858.40970.ville.skytta@iki.fi> <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> Message-ID: <7dd7ab490906071309u4911a8f6m3281ff0fde56eac6@mail.gmail.com> On Thu, Jun 4, 2009 at 9:42 PM, Jason L Tibbitts III wrote: > >>>>> "CW" == Chris Weyl writes: > > CW> Tibbs suggested bringing this before the FPC... It sounds like it > CW> makes sense to do it this way, though I'm still unclear as to how > CW> to get it on the agenda. > > Well, I do post the instructions with the FPC agenda that I post to > fedora-devel-list before every meeting: > Read > https://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure > , > Make a draft > Add it to https://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo > > But fear not, because I made sure it came up at our meeting on > Tuesday. Basically, the concept is sound but we'd like to see it in > the form of a set of packaging guidelines, and we'd like the changes > to the perl provides behavior that are hidden down in the macro file > to be split out and discussed separately. > > The discussion starts at > https://fedoraproject.org/wiki/Packaging:Minutes/20090602#t12:39 Excellent, thank you :) I read through the minutes, and rewrote it as a guidelines draft and added it to DraftsTodo; I took out the %perl_default_filtering bits and can either propose those separately or can just take them up as potentially being included as an /etc/rpm/macros.perl in the main perl package. I also included an admonition to be careful of using this sort of filtering in a multilib situation, due to Panu's comments. https://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFiltering The revised macros (no changes, really, just split out the %perl_... bit) are out at: http://fedorapeople.org/~cweyl/macros.filtering http://fedorapeople.org/~cweyl/macros.perl -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sun Jun 7 20:25:13 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 07 Jun 2009 13:25:13 -0700 Subject: [Fedora-packaging] No Bundled Libraries Explanation Message-ID: <4A2C2229.9010602@gmail.com> There's been quite a few requests to bundle libraries recently. Some of these from web applications, one from C applications, one in the kernel itself. Cassmodiah has been good enough to create a tracker bug for these here:: https://bugzilla.redhat.com/show_bug.cgi?id=504493 We probably should add applications that bundle JavaScript components here as well, although we're are letting those continue to bundle until we have JavaScript Guidelines finalized. With several of these problems, I've been asked to explain/argue/discuss why we have a No bundle rule and have also argued against the exception that was requested for one of them. Because I don't want to keep repeating myself, I've started a page with the reasons that bundling is a bad idea here:: https://fedoraproject.org/wiki/No_Bundled_Libraries I've put this on the agenda for the Packaging Committee but would like some discussion with additions, clarifications, etc. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jussilehtola at fedoraproject.org Sun Jun 7 22:44:46 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Mon, 08 Jun 2009 01:44:46 +0300 Subject: [Fedora-packaging] Python packaging guideline has incorrect BR Message-ID: <1244414686.2742.3.camel@hawking.theorphys.helsinki.fi> Hi, https://fedoraproject.org/wiki/Packaging:Python still has BuildRequires: python while it should read BuildRequires: python-devel could somebody fix this? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From a.badger at gmail.com Mon Jun 8 14:56:59 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 08 Jun 2009 07:56:59 -0700 Subject: [Fedora-packaging] Python packaging guideline has incorrect BR In-Reply-To: <1244414686.2742.3.camel@hawking.theorphys.helsinki.fi> References: <1244414686.2742.3.camel@hawking.theorphys.helsinki.fi> Message-ID: <4A2D26BB.5060001@gmail.com> On 06/07/2009 03:44 PM, Jussi Lehtola wrote: > Hi, > > https://fedoraproject.org/wiki/Packaging:Python > > still has > BuildRequires: python > while it should read > BuildRequires: python-devel > > could somebody fix this? Sounds good to me. Change made. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mopsfelder at gmail.com Mon Jun 8 23:33:23 2009 From: mopsfelder at gmail.com (=?ISO-8859-1?Q?Murilo_Opsfelder_Ara=FAjo?=) Date: Mon, 8 Jun 2009 20:33:23 -0300 Subject: [Fedora-packaging] The better way to use %install section Message-ID: Hi guys, I'm packing a third party software and this third party software is a tarball with a install.sh and other binaries. For example: $ tar xvzf myprogram.tar.gz $ cd myprogram $ ls bin1 bin2 install.sh To install this software I just need to run (as root) install.sh and myprogram runs fine. After finishing installation I have all the files installed as the following example: /usr/bin/bin1 /usr/bin/bin2 What's the better way to install these files? Do I need to run install.sh on the %install section inside myprogram.spec? Something like this: %install sh install.sh Or do I need to copy all install.sh commands inside %install section? Something like this: %install install -o root -w root -m 0755 bin1 %{_installdir}/bin1 install -o root -w root -m 0755 bin2 %{_installdir}/bin2 And one question just to confirm: do I need to list all bin* files inside %files in both case, right? Thanks in advance. -- Murilo Opsfelder Ara?jo mopsfelder at gmail.com {murilo,panda}@bsd.com.br From tcallawa at redhat.com Tue Jun 9 01:20:23 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 08 Jun 2009 21:20:23 -0400 Subject: [Fedora-packaging] The better way to use %install section In-Reply-To: References: Message-ID: <4A2DB8D7.3020706@redhat.com> On 06/08/2009 07:33 PM, Murilo Opsfelder Ara?jo wrote: > Hi guys, > > I'm packing a third party software and this third party software is a > tarball with a install.sh and other binaries. Well, this is a bit off topic for this list, but I'm in a good mood, so I'll try to answer your questions. > What's the better way to install these files? The problem with the install.sh is that it almost certainly has the install directories for those binaries hardcoded to /usr/bin. When you're installing files during %install in an rpm, you want to install those files into %{buildroot}%{_bindir}. > Or do I need to copy all install.sh commands inside %install section? > Something like this: > > %install > install -o root -w root -m 0755 bin1 %{_installdir}/bin1 > install -o root -w root -m 0755 bin2 %{_installdir}/bin2 So, yes, you need to do something like this: install -m 0755 bin1 %{buildroot}/%{_bindir} install -m 0755 bin2 %{buildroot}/%{_bindir} Make sure you have "BuildRoot:" defined in the top section of the spec file, see: https://fedoraproject.org/wiki/Packaging/Guidelines#BuildRoot_tag for some recommended values. Also, %{_bindir} evaluates to /usr/bin, so it's the ideal macro to use here with the %{buildroot} prefix. > And one question just to confirm: do I need to list all bin* files > inside %files in both case, right? Yes, you can do it like this: %files %defattr(-,root,root,-) %{_bindir}/bin* Hope that helps, ~spot From ultrafredde at gmail.com Tue Jun 9 17:02:02 2009 From: ultrafredde at gmail.com (Federico Hernandez) Date: Tue, 9 Jun 2009 19:02:02 +0200 Subject: [Fedora-packaging] F-11 to F-12 transition Message-ID: <690f5ac90906091002n727a92d8x67ff0e87cdd3a84b@mail.gmail.com> Now this might really be a newbie question but since I haven't maintained a package that long yet I wonder how the transition now from F-11 to the future F-12 works. At what point can/must I check out a new CVS branch for F-12 of my package? Will it be created automatically and all the packages in rawhide will move by magic into F-12? Or do I need to request one via bugzilla? Just wondering as I have never been around for this transition. Greetings, /Federico -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Tue Jun 9 17:15:37 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 09 Jun 2009 12:15:37 -0500 Subject: [Fedora-packaging] F-11 to F-12 transition In-Reply-To: <690f5ac90906091002n727a92d8x67ff0e87cdd3a84b@mail.gmail.com> (Federico Hernandez's message of "Tue\, 9 Jun 2009 19\:02\:02 +0200") References: <690f5ac90906091002n727a92d8x67ff0e87cdd3a84b@mail.gmail.com> Message-ID: >>>>> "FH" == Federico Hernandez writes: FH> Now this might really be a newbie question but since I haven't FH> maintained a package that long yet I wonder how the transition now FH> from F-11 to the future F-12 works. F-11 branched some time ago, and the current "devel" branch goes to rawhide. As the F-12 release date gets closer, you will first have the option to request an F-12 branch (an announcement will be sent when this happens) and then, a bit later, all packages will acquire an F-12 branch (which will be accompanied by an announcement and some downtime). This happens much later in the release cycle, though; nothing will happen for a few months. - J< From ultrafredde at gmail.com Tue Jun 9 17:38:24 2009 From: ultrafredde at gmail.com (Federico Hernandez) Date: Tue, 9 Jun 2009 19:38:24 +0200 Subject: [Fedora-packaging] F-11 to F-12 transition In-Reply-To: References: <690f5ac90906091002n727a92d8x67ff0e87cdd3a84b@mail.gmail.com> Message-ID: <690f5ac90906091038x682b32b3j45c82b209f26b805@mail.gmail.com> > > downtime). This happens much later in the release cycle, though; > nothing will happen for a few months. > THX for answering. Now I know. /Federico -------------- next part -------------- An HTML attachment was scrubbed... URL: From g3orgexsh at gmail.com Wed Jun 10 08:37:41 2009 From: g3orgexsh at gmail.com (georgexsh) Date: Wed, 10 Jun 2009 16:37:41 +0800 Subject: [Fedora-packaging] Install apache moudle will restart apache automatical? Message-ID: Hi guys: I'm building a apache module that write by myself. Something I don't understand is, httpd will be restarted after I install the mould package, even while I didn't put anything in the %post and %postun/%preun section, I simply add a require directive: Requires: httpd. I wander is rpm that smart to know my module need restart httpd to be activated. httpd on my box is a customed version of apache 2.0.63, and configured to be able to be managed by /sbin/service. Thanks in advance. -- georgexsh From pmatilai at laiskiainen.org Wed Jun 10 11:57:40 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 10 Jun 2009 14:57:40 +0300 (EEST) Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: <7dd7ab490906051047p27d3280dv16b6fce5b02d81be@mail.gmail.com> References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> <200906041858.40970.ville.skytta@iki.fi> <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> <7dd7ab490906041857h61dfc18bq84cc7d7e0b1fa26b@mail.gmail.com> <7dd7ab490906051047p27d3280dv16b6fce5b02d81be@mail.gmail.com> Message-ID: On Fri, 5 Jun 2009, Chris Weyl wrote: > On Fri, Jun 5, 2009 at 12:30 AM, Panu Matilainen > wrote: > > As a generic filtering mechanism this is a no-go, doing this breaks > multilib as Fedora uses it: > > %global _use_internal_dependency_generator 0 \ > > Multilib-safe filtering mechanism needs to be bolted to the > internal dependency generator, patches welcome... The other > alternative would be killing the multilib coloring which would > "only" require splitting all relevant packages to separate -libs > etc to avoid elf32/elf64 binary collisions (which the multilib > coloring currently hides) > > > AFAIK disabling the internal dependency generator is the only way to > filter dependencies of this nature (namely, solib provides).? Currently yes, hence the "patches welcome" :) > Is there some way we could either do the necessary file coloring > external to rpm, segregate the dependency and coloring functionality, or > gain access to modify the auto-prov/dep results (if not functionality) > using the embedded lua interperter? Doing the coloring externally would require changing the external dependency generating quite dramatically as the internal coloring and dep generation is per-file, whereas external dependencies are per package. Separating the coloring from dependency generation should be quite possible but results in yet-another package style variant. Whether it matters ... dunno. But that'd be still be working around the fact that what is really needed is a proper dependency filtering/customization mechanism that doesn't require jumping through 15 hoops. > > Also, if I read this correctly, the only impact disabling the internal > dependency generator has on multilib is when elf32/64 binaries are > actually present in the package, right? Yup, packages with elf32/64 binaries are the only cases where it really matters. The internal dep generator adds some other things besides the coloring: file classes and per-file dependency information that the external one cannot do, but that extra info is not really used by anything (at least in part because its not available everywhere). - Panu - From cweyl at alumni.drew.edu Wed Jun 10 23:02:42 2009 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 10 Jun 2009 16:02:42 -0700 Subject: [Fedora-packaging] Re: Generic filtering macros... In-Reply-To: References: <7dd7ab490905290018n6c0e9f65l2aeede83c0cbbb84@mail.gmail.com> <7dd7ab490905311306k307dec89raab86d20d566db9@mail.gmail.com> <200906041858.40970.ville.skytta@iki.fi> <7dd7ab490906041847m23f88e7dk832ef1fae0d1f63e@mail.gmail.com> <7dd7ab490906041857h61dfc18bq84cc7d7e0b1fa26b@mail.gmail.com> <7dd7ab490906051047p27d3280dv16b6fce5b02d81be@mail.gmail.com> Message-ID: <7dd7ab490906101602k27fd2344u8f9a2a8e4b5f5525@mail.gmail.com> On Wed, Jun 10, 2009 at 4:57 AM, Panu Matilainen wrote: > On Fri, 5 Jun 2009, Chris Weyl wrote: > > AFAIK disabling the internal dependency generator is the only way to >> filter dependencies of this nature (namely, solib provides). >> > > Currently yes, hence the "patches welcome" :) Just making sure I was understanding that correctly :) Is there some way we could either do the necessary file coloring external >> to rpm, segregate the dependency and coloring functionality, or gain access >> to modify the auto-prov/dep results (if not functionality) using the >> embedded lua interperter? >> > > Doing the coloring externally would require changing the external > dependency generating quite dramatically as the internal coloring and dep > generation is per-file, whereas external dependencies are per package. > Separating the coloring from dependency generation should be quite possible > but results in yet-another package style variant. Whether it matters ... > dunno. But that'd be still be working around the fact that what is really > needed is a proper dependency filtering/customization mechanism that doesn't > require jumping through 15 hoops. > So, can we expose the generated dep info to the embedded lua interperter, the way sources/patches are, and make it possible to selectively add/remove deps from LUA as well? The few bits of documentation I've been able to find w.r.t. LUA in RPM refers tantalizingly to "hooks", yet doesn't actually describe how to use them... So I'm unsure if this can be leveraged here. From looking at the RPM source, it also doesn't look as if the same table structures built up for sources & patches are done for deps as well. (I'm focusing on LUA here as this seems to potentially be the sanest / easiest / most flexible way to get at this info w/o disabling the internal dep generator.) Also, if I read this correctly, the only impact disabling the internal >> dependency generator has on multilib is when elf32/64 binaries are >> actually present in the package, right? >> > > Yup, packages with elf32/64 binaries are the only cases where it really > matters. The internal dep generator adds some other things besides the > coloring: file classes and per-file dependency information that the external > one cannot do, but that extra info is not really used by anything (at least > in part because its not available everywhere). > Ok, cool. :) So what I'm taking away from the above is that we can implement this system as-is without yum/rpm breakage in the vast majority of situations this is called for (that is, plugin-style packages without elf32/64 binaries not having -libs subpackages). I know it's not perfect, but it's better than the several mystical filtering incantations we have right now. -Chris -- Chris Weyl Ex astris, scientia -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwheeler at dwheeler.com Thu Jun 11 00:08:28 2009 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Wed, 10 Jun 2009 20:08:28 -0400 Subject: [Fedora-packaging] Re: The better way to use %install section In-Reply-To: <20090609160048.BB51A619136@hormel.redhat.com> References: <20090609160048.BB51A619136@hormel.redhat.com> Message-ID: <4A304AFC.7040605@dwheeler.com> Murilo Opsfelder Ara?jo mopsfelder at gmail dot com asked: > I'm packing a third party software and this third party software is a > tarball with a install.sh and other binaries. ... > $ ls ... > install.sh > > To install this software I just need to run (as root) install.sh and > myprogram runs fine. > > After finishing installation I have all the files installed as the > following example: > /usr/bin/bin1 > /usr/bin/bin2 > Or do I need to copy all install.sh commands inside %install section? Tom Callaway graciously replied: > Well, this is a bit off topic for this list, but I'm in a > good mood, so I'll try to answer your questions. ... > The problem with the install.sh is that it almost certainly has the > install directories for those binaries hardcoded to /usr/bin. When > you're installing files during %install in an rpm, you want to install > those files into %{buildroot}%{_bindir}. I agree. Ideally, program authors would support the "DESTDIR" environment variable, so that you could easily install programs to an intermediate (DESTDIR) directory for later execution in the "real" directory (e.g., /usr/bin/). In my experience, almost nobody supports DESTDIR :-(. This lack of DESTDIR support causes trouble for rpm-based packagers (Fedora, RHEL, etc.) _and_ deb-based packagers (Debian, Ubuntu, etc.). For now, you have to re-implement the installation by hand. Ideally, DESTDIR support would be automated instead of requiring the modification of every makefile in the universe. That's not as easy as it seems; I've documented some options for doing that: http://www.dwheeler.com/essays/automating-destdir.html I intend to release some code relatively soon that should automate DESTDIR for most installations, as noted there. But for now, you'll need to do what Tom Callaway explained above. --- David A. Wheeler From cra at WPI.EDU Thu Jun 11 22:14:43 2009 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 11 Jun 2009 18:14:43 -0400 Subject: [Fedora-packaging] initscripts in spec file scriptlets Message-ID: <20090611221443.GK21110@angus.ind.WPI.EDU> http://fedoraproject.org/wiki/Packaging/SysVInitScript has an example of how to write %post/%preun scriptlets that install init scripts. The problem is, the %post one will overwrite the /etc/rc?.d/[KS] symlinks upon every package upgrade: %post # This adds the proper /etc/rc*.d links for the script /sbin/chkconfig --add