From opensource at till.name Mon Sep 3 19:16:25 2007 From: opensource at till.name (Till Maas) Date: Mon, 03 Sep 2007 21:16:25 +0200 Subject: [Fedora-packaging] sponsorship needed for reviewes / fedorabugs membership Message-ID: <200709032116.37403.opensource@till.name> Hiyas, does one who wants to review other packages need to be sponsored or should fedorabugs membership be given to anyone who wants to have it? Afaik, the FAS says that a sponsor is not needed for fedorabugs. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From a.badger at gmail.com Mon Sep 3 20:19:37 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 03 Sep 2007 13:19:37 -0700 Subject: [Fedora-packaging] sponsorship needed for reviewes / fedorabugs membership In-Reply-To: <200709032116.37403.opensource@till.name> References: <200709032116.37403.opensource@till.name> Message-ID: <46DC6C59.6030902@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Till Maas wrote: > Hiyas, > > does one who wants to review other packages need to be sponsored or should > fedorabugs membership be given to anyone who wants to have it? Afaik, the FAS > says that a sponsor is not needed for fedorabugs. > There's really two questions here with two different answers: 1) Do I need to be sponsored to review packages? You need to be sponsored into cvsextras to complete a review and change the flags on a package from needs review to accepted. Enforcement of this policy is done through membership in fedorabugs. You do not need to be sponsored to give a preliminary review as part of showing that you have learned the packaging guidelines. 2) Do I need to be sponsored to have fedorabugs? You do not need to be a sponsored member of cvsextras in order to be sponsored into fedorabugs. There are multiple projects that need to have access to make changes to Fedora Bugzilla entries (Packaging for package reviews and Triage for closing bugs as dupes, for instance). Each project that makes use of fedorabugs probably has a different criterion. I don't know if there's any project currently which just says, "Ask us and we'll put you in Fedora Bugs". - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG3GxZX6yAic2E7kgRAuA+AJ9qhaEDRang9Xjw6N8dHc8LOe/q3gCghdjV DS5CQbbyXn0dNcE3rUW92i0= =KG3Z -----END PGP SIGNATURE----- From opensource at till.name Wed Sep 5 10:09:52 2007 From: opensource at till.name (Till Maas) Date: Wed, 05 Sep 2007 12:09:52 +0200 Subject: [Fedora-packaging] sponsorship needed for reviewes / fedorabugs membership In-Reply-To: <46DC6C59.6030902@gmail.com> References: <200709032116.37403.opensource@till.name> <46DC6C59.6030902@gmail.com> Message-ID: <200709051210.02211.opensource@till.name> On Mo September 3 2007, Toshio Kuratomi wrote: > 1) Do I need to be sponsored to review packages? > You need to be sponsored into cvsextras to complete a review and > change the flags on a package from needs review to accepted. > Enforcement of this policy is done through membership in fedorabugs. > You do not need to be sponsored to give a preliminary review as part of > showing that you have learned the packaging guidelines. So one needs to maintain at least one package to approve a package in a review, because one only gets cvsextras membership after submitting a package that was approved by a sponsor? Btw. I am asking these question because there is one volunteer who wants to help with reviewing packages but not maintaining one and the wiki does not really answer the question, whether this is possible and how he gets the permission to do this. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Wed Sep 5 14:15:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 5 Sep 2007 10:15:28 -0400 Subject: [Fedora-packaging] sponsorship needed for reviewes / fedorabugs membership In-Reply-To: <200709051210.02211.opensource@till.name> References: <200709032116.37403.opensource@till.name> <46DC6C59.6030902@gmail.com> <200709051210.02211.opensource@till.name> Message-ID: <20070905101528.3f74d27a@mentok.boston.redhat.com> On Wed, 05 Sep 2007 12:09:52 +0200 Till Maas wrote: > So one needs to maintain at least one package to approve a package in > a review, because one only gets cvsextras membership after submitting > a package that was approved by a sponsor? Btw. I am asking these > question because there is one volunteer who wants to help with > reviewing packages but not maintaining one and the wiki does not > really answer the question, whether this is possible and how he gets > the permission to do this. Technically the person would have to be sponsored. Right now the only documented way to get sponsored is to bring a new package to the party. However the tool will allow somebody to apply for cvsextras and somebody else to approve them, without a new package being involved. We just don't have any written guidelines on allowing this to happen. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Wed Sep 5 16:48:40 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 05 Sep 2007 09:48:40 -0700 Subject: [Fedora-packaging] sponsorship needed for reviewes / fedorabugs membership In-Reply-To: <20070905101528.3f74d27a@mentok.boston.redhat.com> References: <200709032116.37403.opensource@till.name> <46DC6C59.6030902@gmail.com> <200709051210.02211.opensource@till.name> <20070905101528.3f74d27a@mentok.boston.redhat.com> Message-ID: <46DEDDE8.9050306@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Wed, 05 Sep 2007 12:09:52 +0200 > Till Maas wrote: > >> So one needs to maintain at least one package to approve a package in >> a review, because one only gets cvsextras membership after submitting >> a package that was approved by a sponsor? Btw. I am asking these >> question because there is one volunteer who wants to help with >> reviewing packages but not maintaining one and the wiki does not >> really answer the question, whether this is possible and how he gets >> the permission to do this. > > Technically the person would have to be sponsored. Right now the only > documented way to get sponsored is to bring a new package to the > party. However the tool will allow somebody to apply for cvsextras and > somebody else to approve them, without a new package being involved. > We just don't have any written guidelines on allowing this to happen. > If this person is willing to put up with a certain amount of hassle because they'd be the guinea pig case, we do have to get to the point where we have other routes to sponsorship besides maintaining packages. Reviewing packages is a relatively easy test of this, since current maintainers are expected to show they understand the guidelines through review. There have been the beginnings of proposals for this kind of thing before but they've all tended to stall. I think they attempt to be too general and too big. We need to start small by extending the current policy on sponsorship to a few other groups (in this case, review-only) and see what we learn from doing that. This is a topic for fesco and fedora-devel rather than the packaging committee, though. I'd say start a discussion and proposal on fedora-devel and then get it added to the fesco meeting agenda. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG3t3oX6yAic2E7kgRApxUAKCrUiaCXxk23k2XKyS5qdNdQsDg6wCcDgxK 8/eAfm1FMSniZSemOIxzxvI= =gr7R -----END PGP SIGNATURE----- From opensource at till.name Wed Sep 5 21:09:06 2007 From: opensource at till.name (Till Maas) Date: Wed, 05 Sep 2007 23:09:06 +0200 Subject: [Fedora-packaging] broken wiki syntax on Packaging/ReviewGuidelines, Message-ID: <200709052309.11990.opensource@till.name> Hiyas, on http://fedoraproject.org/wiki/Packaging/ReviewGuidelines there is some broken wiki syntax: ["Packaging/LicensingGuidelines" Licensing Guidelines] should be (afaik) [:Packaging/LicensingGuidelines: Licensing Guidelines] [Packaging/Guidelines#FileAndDirectoryOwnership Guidelines] should be (afaik) [:Packaging/Guidelines#FileAndDirectoryOwnership: Guidelines] Also on http://fedoraproject.org/wiki/Packaging/Guidelines in Please remember that any package that you submit must also conform to the PackageReviewGuidelines there is reference to PackageReviewGuidelines instead of [:Packaging/ReviewGuidelines: Review Guidelines] which adds an annoying warning to the Review Guidelines (and "garbage" to the URL) when one follows the link. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From ville.skytta at iki.fi Wed Sep 5 21:28:02 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 6 Sep 2007 00:28:02 +0300 Subject: [Fedora-packaging] broken wiki syntax on Packaging/ReviewGuidelines, In-Reply-To: <200709052309.11990.opensource@till.name> References: <200709052309.11990.opensource@till.name> Message-ID: <200709060028.03078.ville.skytta@iki.fi> On Thursday 06 September 2007, Till Maas wrote: > Hiyas, > > on http://fedoraproject.org/wiki/Packaging/ReviewGuidelines there is some > broken wiki syntax: [...] > Also on > http://fedoraproject.org/wiki/Packaging/Guidelines [...] Fixed, thanks. From opensource at till.name Wed Sep 5 21:31:14 2007 From: opensource at till.name (Till Maas) Date: Wed, 05 Sep 2007 23:31:14 +0200 Subject: [Fedora-packaging] Firmware licensing Message-ID: <200709052331.19968.opensource@till.name> Hiyas, imho there is a section about firmware licenses missing on: http://fedoraproject.org/wiki/Licensing E.g. here is a license text: https://bugzilla.redhat.com/attachment.cgi?id=161738 How should I know, whether or not this license is ok? Or will someone with authority remove the FE-Legal block from https://bugzilla.redhat.com/show_bug.cgi?id=230161, once the license is approved? Also, is there a template to send to the vendors of firmware to use it as their license, e.g. here is a license text missing? https://bugzilla.redhat.com/show_bug.cgi?id=258681 I guess it should block FE-Legal, too? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From tcallawa at redhat.com Wed Sep 5 21:39:40 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 05 Sep 2007 17:39:40 -0400 Subject: [Fedora-packaging] Firmware licensing In-Reply-To: <200709052331.19968.opensource@till.name> References: <200709052331.19968.opensource@till.name> Message-ID: <1189028380.3941.31.camel@dhcp83-165.boston.redhat.com> On Wed, 2007-09-05 at 23:31 +0200, Till Maas wrote: > Hiyas, > > imho there is a section about firmware licenses missing on: > http://fedoraproject.org/wiki/Licensing > > E.g. here is a license text: > https://bugzilla.redhat.com/attachment.cgi?id=161738 > How should I know, whether or not this license is ok? Or will someone with > authority remove the FE-Legal block from > https://bugzilla.redhat.com/show_bug.cgi?id=230161, once the license is > approved? I will, if you keep reminding me. :) I've updated the bz ticket with the information holding it up. > Also, is there a template to send to the vendors of firmware to use it as > their license, e.g. here is a license text missing? > https://bugzilla.redhat.com/show_bug.cgi?id=258681 > I guess it should block FE-Legal, too? Sure looks that way. Blocked. ~spot From harald at redhat.com Thu Sep 6 07:24:52 2007 From: harald at redhat.com (Harald Hoyer) Date: Thu, 06 Sep 2007 09:24:52 +0200 Subject: [Fedora-packaging] Packaging Draft LSB Initscripts In-Reply-To: <20070831191059.GB31970@nostromo.devel.redhat.com> References: <46D6D031.7020504@redhat.com> <20070831191059.GB31970@nostromo.devel.redhat.com> Message-ID: <46DFAB44.8080001@redhat.com> Bill Nottingham schrieb: > Harald Hoyer (harald at redhat.com) said: >> Open for comments/corrections/modifications... >> >> http://fedoraproject.org/wiki/PackagingDrafts/SysVInitScript > > # config: > # pidfile: > # processname: > # probe: > > are all not used by anything; not sure we want to specify them. In fact, > 'probe' dates back to *linuxconf*. Ick. > > Probably should explain that starting by default with 'Default-Start' is > generally discouraged. > > [ "$NETWORKING" ] tests are crack and should be removed. > > /var/lock/subsys/$foo needs to match the init script name, not the daemon > name. > > Bill Removed, revised.. please review. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3623 bytes Desc: S/MIME Cryptographic Signature URL: From opensource at till.name Thu Sep 6 13:05:00 2007 From: opensource at till.name (Till Maas) Date: Thu, 06 Sep 2007 15:05:00 +0200 Subject: [Fedora-packaging] Use of conflicts in package splitups Message-ID: <200709061505.05908.opensource@till.name> Hiyas, http://fedoraproject.org/wiki/Packaging/Conflicts says: | If you find yourself in a situation where you feel that your package has to | conflict with another package (either explicitly or implicitly), but does | not fit the documented accepted cases above, then you need to make your case | to the Fedora Packaging Committee. I guess here is such a case: https://bugzilla.redhat.com/show_bug.cgi?id=266261 knm_new-fonts was split up from fonts-japanese, therefore it conflicts with an older version for fonts-japanese. I have also two review requests (vbetool and radeontool), that are splitups from pm-utils, do they need to conflict with the old version of pm-utils, too? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From fedora at leemhuis.info Thu Sep 6 13:42:03 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 06 Sep 2007 15:42:03 +0200 Subject: [Fedora-packaging] Use of conflicts in package splitups In-Reply-To: <200709061505.05908.opensource@till.name> References: <200709061505.05908.opensource@till.name> Message-ID: <46E003AB.10806@leemhuis.info> On 06.09.2007 15:05, Till Maas wrote: > Hiyas, > > http://fedoraproject.org/wiki/Packaging/Conflicts says: > > | If you find yourself in a situation where you feel that your package has to > | conflict with another package (either explicitly or implicitly), but does > | not fit the documented accepted cases above, then you need to make your case > | to the Fedora Packaging Committee. > > I guess here is such a case: > https://bugzilla.redhat.com/show_bug.cgi?id=266261 > > knm_new-fonts was split up from fonts-japanese, therefore it conflicts with an > older version for fonts-japanese. I have also two review requests (vbetool > and radeontool), that are splitups from pm-utils, do they need to conflict > with the old version of pm-utils, too? When I split the mail-notification plugin into a main package and a subpackage I used something else which maybe could help here as well: in the new mail-notification-evo-plugin I obsoleted the older mail-notification package (e.g. the one with the EVR before the split) and required the new main mail-notification package to be higher then that EVR (rough explanation, but I suppose you'll get the idea). That way I didn't need any Conflicts and users that had the not-yet-split package installed always got the both packages (including the one that was split off) during a yum upgrade. CU knurd From opensource at till.name Thu Sep 6 13:53:28 2007 From: opensource at till.name (Till Maas) Date: Thu, 06 Sep 2007 15:53:28 +0200 Subject: [Fedora-packaging] Use of conflicts in package splitups In-Reply-To: <46E003AB.10806@leemhuis.info> References: <200709061505.05908.opensource@till.name> <46E003AB.10806@leemhuis.info> Message-ID: <200709061553.34071.opensource@till.name> On Do September 6 2007, Thorsten Leemhuis wrote: > When I split the mail-notification plugin into a main package and a > subpackage I used something else which maybe could help here as well: in > the new mail-notification-evo-plugin I obsoleted the older > mail-notification package (e.g. the one with the EVR before the split) > and required the new main mail-notification package to be higher then > that EVR (rough explanation, but I suppose you'll get the idea). > > That way I didn't need any Conflicts and users that had the > not-yet-split package installed always got the both packages (including > the one that was split off) during a yum upgrade. When I understand you correctly, this will not work here, because knm_new-fonts does not require fonts-japanese afaics. And vbetool and radeontool do not require pm-utils. For pm-utils, it will be the other way round. The pm-utils evr after the splitup will require vbetool and radeontool. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From katzj at redhat.com Thu Sep 6 14:04:15 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 06 Sep 2007 10:04:15 -0400 Subject: [Fedora-packaging] Use of conflicts in package splitups In-Reply-To: <200709061505.05908.opensource@till.name> References: <200709061505.05908.opensource@till.name> Message-ID: <1189087455.4437.0.camel@localhost.localdomain> On Thu, 2007-09-06 at 15:05 +0200, Till Maas wrote: > http://fedoraproject.org/wiki/Packaging/Conflicts says: > > | If you find yourself in a situation where you feel that your package has to > | conflict with another package (either explicitly or implicitly), but does > | not fit the documented accepted cases above, then you need to make your case > | to the Fedora Packaging Committee. > > I guess here is such a case: > https://bugzilla.redhat.com/show_bug.cgi?id=266261 > > knm_new-fonts was split up from fonts-japanese, therefore it conflicts with an > older version for fonts-japanese. I have also two review requests (vbetool > and radeontool), that are splitups from pm-utils, do they need to conflict > with the old version of pm-utils, too? These sound like reasonable uses of conflicts to me Jeremy From opensource at till.name Thu Sep 6 14:32:50 2007 From: opensource at till.name (Till Maas) Date: Thu, 06 Sep 2007 16:32:50 +0200 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming Message-ID: <200709061633.01095.opensource@till.name> Aloas, http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce652c376d7ba3908461b638784b6952d states: | There is an exception to this rule. If the upstream source has "py" | (or "Py") in its name, you can use that name for the package. Maybe there should be another exception when upstream includes python it its name, e.g. fuse-python[1]. Should this be packaged as python-fuse or can it stay with upstream's name fuse-python? Should it provide python-fuse in case it stays with its upstream name? Regards, Till [1] Review Request: https://bugzilla.redhat.com/show_bug.cgi?id=250904 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From tcallawa at redhat.com Thu Sep 6 14:32:11 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 06 Sep 2007 10:32:11 -0400 Subject: [Fedora-packaging] Use of conflicts in package splitups In-Reply-To: <1189087455.4437.0.camel@localhost.localdomain> References: <200709061505.05908.opensource@till.name> <1189087455.4437.0.camel@localhost.localdomain> Message-ID: <1189089131.4022.1.camel@new-host-3> On Thu, 2007-09-06 at 10:04 -0400, Jeremy Katz wrote: > On Thu, 2007-09-06 at 15:05 +0200, Till Maas wrote: > > http://fedoraproject.org/wiki/Packaging/Conflicts says: > > > > | If you find yourself in a situation where you feel that your package has to > > | conflict with another package (either explicitly or implicitly), but does > > | not fit the documented accepted cases above, then you need to make your case > > | to the Fedora Packaging Committee. > > > > I guess here is such a case: > > https://bugzilla.redhat.com/show_bug.cgi?id=266261 > > > > knm_new-fonts was split up from fonts-japanese, therefore it conflicts with an > > older version for fonts-japanese. I have also two review requests (vbetool > > and radeontool), that are splitups from pm-utils, do they need to conflict > > with the old version of pm-utils, too? > > These sound like reasonable uses of conflicts to me Agreed, this is fine because you're explicitly conflicting with an older version of the package from whence these bits originally lived. ~spot From tcallawa at redhat.com Thu Sep 6 14:33:10 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 06 Sep 2007 10:33:10 -0400 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <200709061633.01095.opensource@till.name> References: <200709061633.01095.opensource@till.name> Message-ID: <1189089191.4022.3.camel@new-host-3> On Thu, 2007-09-06 at 16:32 +0200, Till Maas wrote: > Aloas, > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce652c376d7ba3908461b638784b6952d > states: > > | There is an exception to this rule. If the upstream source has "py" > | (or "Py") in its name, you can use that name for the package. > > Maybe there should be another exception when upstream includes python it its > name, e.g. fuse-python[1]. Should this be packaged as python-fuse or can it > stay with upstream's name fuse-python? Should it provide python-fuse in case > it stays with its upstream name? Does fuse-python have "py" in its name? If so, you can use that name for the package. ;) ~spot From ville.skytta at iki.fi Thu Sep 6 16:43:57 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 6 Sep 2007 19:43:57 +0300 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <1189089191.4022.3.camel@new-host-3> References: <200709061633.01095.opensource@till.name> <1189089191.4022.3.camel@new-host-3> Message-ID: <200709061943.57729.ville.skytta@iki.fi> On Thursday 06 September 2007, Tom "spot" Callaway wrote: > On Thu, 2007-09-06 at 16:32 +0200, Till Maas wrote: > > Aloas, > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce65 > >2c376d7ba3908461b638784b6952d > > > > states: > > | There is an exception to this rule. If the upstream source has "py" > > | (or "Py") in its name, you can use that name for the package. > > > > Maybe there should be another exception when upstream includes python it > > its name, e.g. fuse-python[1]. Should this be packaged as python-fuse or > > can it stay with upstream's name fuse-python? Should it provide > > python-fuse in case it stays with its upstream name? > > Does fuse-python have "py" in its name? If so, you can use that name for > the package. ;) I would personally call it python-fuse anyway for consistency, and perhaps add "Provides: fuse-python = VR", but maybe that's just me. From a.badger at gmail.com Thu Sep 6 17:33:16 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 06 Sep 2007 10:33:16 -0700 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <200709061943.57729.ville.skytta@iki.fi> References: <200709061633.01095.opensource@till.name> <1189089191.4022.3.camel@new-host-3> <200709061943.57729.ville.skytta@iki.fi> Message-ID: <46E039DC.2040508@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ville Skytt? wrote: > On Thursday 06 September 2007, Tom "spot" Callaway wrote: >> On Thu, 2007-09-06 at 16:32 +0200, Till Maas wrote: >>> Aloas, >>> >>> http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-8756a3bce65 >>> 2c376d7ba3908461b638784b6952d >>> >>> states: >>> | There is an exception to this rule. If the upstream source has "py" >>> | (or "Py") in its name, you can use that name for the package. >>> >>> Maybe there should be another exception when upstream includes python it >>> its name, e.g. fuse-python[1]. Should this be packaged as python-fuse or >>> can it stay with upstream's name fuse-python? Should it provide >>> python-fuse in case it stays with its upstream name? >> Does fuse-python have "py" in its name? If so, you can use that name for >> the package. ;) > > I would personally call it python-fuse anyway for consistency, and perhaps > add "Provides: fuse-python = VR", but maybe that's just me. > +1 In fact, I remember discussing removing the "py in the name" exception at one of the meetings. Might not have come to a vote, though. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG4DncX6yAic2E7kgRAkX7AKCZ3kLAQY8BjeW4mezi50vKRgE5dQCcCPed tQQRIEWdnye2WfJtVLju2uE= =zw9B -----END PGP SIGNATURE----- From opensource at till.name Fri Sep 7 16:31:38 2007 From: opensource at till.name (Till Maas) Date: Fri, 07 Sep 2007 18:31:38 +0200 Subject: [Fedora-packaging] Review Guidelines simplifications Message-ID: <200709071831.44080.opensource@till.name> Aloas, I noticed that it is possible to build local srpm with the koji client on the Fedora buildsystem. Therefore I propose to change and simplify the following items from the Review Guidelines | - MUST: The package must successfully compile and build into binary rpms on | at least one supported architecture. | - SHOULD: The reviewer should test that the package builds in mock. | - SHOULD: The package should compile and build into binary rpms on all | supported architectures. | - MUST: All build dependencies must be listed in BuildRequires, except for | any that are listed in the exceptions section of Packaging Guidelines; | inclusion of those as BuildRequires is optional. Apply common sense. into: - MUST: The package must be build on the Fedora Buildsystem for rawhide with {{{koji build --scratch dist-f8 package-*.src.rpm}}} and the build must succeed for at least one supported architecture. The "dist-f8" parameter has to be changed in the Guidelines each time a newer is created or someone needs to create a rawhide alias tag, if this is possible. The advantages of this approach is that the SHOULD items will be tested without extra work for the reviewer. Also there is no way acceptable way to verify that all needed BuildRequires are listed in the spec. Therefore a successfull build on the Fedora Buildsystem should be enough. I have another change to propose: Change | - SHOULD: Usually, subpackages other than devel should require the base | package using a fully versioned dependency. into: - SHOULD: Usually, subpackages other than devel should require the base package with {{{Requires: %{name} = %{version}-%{release}}}} This makes it easier to copy and paste the required code and is easier to understand. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Fri Sep 7 16:48:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Sep 2007 12:48:40 -0400 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <200709071831.44080.opensource@till.name> References: <200709071831.44080.opensource@till.name> Message-ID: <20070907124840.388c28ae@mentok.boston.redhat.com> On Fri, 07 Sep 2007 18:31:38 +0200 Till Maas wrote: > into: > > - MUST: The package must be build on the Fedora Buildsystem for > rawhide with {{{koji build --scratch dist-f8 package-*.src.rpm}}} and > the build must succeed for at least one supported architecture. > > The "dist-f8" parameter has to be changed in the Guidelines each time > a newer is created or someone needs to create a rawhide alias tag, if > this is possible. > > The advantages of this approach is that the SHOULD items will be > tested without extra work for the reviewer. Also there is no way > acceptable way to verify that all needed BuildRequires are listed in > the spec. Therefore a successfull build on the Fedora Buildsystem > should be enough. How should this be handled when one new package depends on another new package, both going through review at the same time? Do you effectively block the second review until the first is completely done and built into rawhide so that koji can make use of it in a buildroot? Would that introduce unreasonable delays in getting package sets in? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Fri Sep 7 16:59:48 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 07 Sep 2007 12:59:48 -0400 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <200709071831.44080.opensource@till.name> References: <200709071831.44080.opensource@till.name> Message-ID: <1189184388.4300.19.camel@localhost.localdomain> On Fri, 2007-09-07 at 18:31 +0200, Till Maas wrote: > - MUST: The package must be build on the Fedora Buildsystem for > rawhide with > {{{koji build --scratch dist-f8 package-*.src.rpm}}} and the build > must > succeed for at least one supported architecture. I'm not sure I see the point of this. The package must be buildable on the Fedora Buildsystem anyway, to enter the package collection. Pointing out that koji can do scratch builds as an alternative to mock for testing buildability might be useful, tough. From opensource at till.name Fri Sep 7 17:06:26 2007 From: opensource at till.name (Till Maas) Date: Fri, 07 Sep 2007 19:06:26 +0200 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <20070907124840.388c28ae@mentok.boston.redhat.com> References: <200709071831.44080.opensource@till.name> <20070907124840.388c28ae@mentok.boston.redhat.com> Message-ID: <200709071906.32206.opensource@till.name> On Fr September 7 2007, Jesse Keating wrote: > How should this be handled when one new package depends on another new > package, both going through review at the same time? Do you > effectively block the second review until the first is completely done > and built into rawhide so that koji can make use of it in a buildroot? > Would that introduce unreasonable delays in getting package sets in? Even with the current procedure the second package has to wait until the first is completely done in koji before it can be build for rawhide. The only difference is, that this delay will happen before the second package has been approved and not after it has been approved. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Fri Sep 7 17:10:05 2007 From: opensource at till.name (Till Maas) Date: Fri, 07 Sep 2007 19:10:05 +0200 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <1189184388.4300.19.camel@localhost.localdomain> References: <200709071831.44080.opensource@till.name> <1189184388.4300.19.camel@localhost.localdomain> Message-ID: <200709071910.05889.opensource@till.name> On Fr September 7 2007, Matthias Clasen wrote: > I'm not sure I see the point of this. The package must be buildable on > the Fedora Buildsystem anyway, to enter the package collection. Pointing > out that koji can do scratch builds as an alternative to mock for > testing buildability might be useful, tough. It simplifies the review guidelines. Instead of at least a demanded local rpmbuild and optional builds for every architecture and in mock and verifying the BuildRequires (either with rpmdev-rmdevelrpms or mock) only one step is needed. The advantage is also that always building for every architecture ist tested. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From tibbs at math.uh.edu Fri Sep 7 17:11:25 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Sep 2007 12:11:25 -0500 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <20070907124840.388c28ae@mentok.boston.redhat.com> References: <200709071831.44080.opensource@till.name> <20070907124840.388c28ae@mentok.boston.redhat.com> Message-ID: >>>>> "JK" == Jesse Keating writes: JK> How should this be handled when one new package depends on another JK> new package, both going through review at the same time? Indeed, this would needlessly complicate reviews which depend on one another. It's bad enough as it is because it takes ages for the packages to actually get through the system, but at least without a "builds in koji" requirement the reviewer can put things in a local repo and get their end of the process done. Now, sure, it would be nice if everyone tested in koji or local mock whenever possible, so it's certainly worth talking about getting some recommendations into the guidelines. It would also be nice if they posted rpmlint output from the resulting packages and explained all of the issues present. I fear that something like this is going to be required if the review process is ever going to actually work properly and we're not going to suddenly see ten times as many people reviewing packages. - J< From jkeating at redhat.com Fri Sep 7 17:15:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Sep 2007 13:15:53 -0400 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <200709071906.32206.opensource@till.name> References: <200709071831.44080.opensource@till.name> <20070907124840.388c28ae@mentok.boston.redhat.com> <200709071906.32206.opensource@till.name> Message-ID: <20070907131553.1027e240@mentok.boston.redhat.com> On Fri, 07 Sep 2007 19:06:26 +0200 Till Maas wrote: > Even with the current procedure the second package has to wait until > the first is completely done in koji before it can be build for > rawhide. The only difference is, that this delay will happen before > the second package has been approved and not after it has been > approved. Except that if all are approved prior to, one can use chain-build to build the entire stack in one execution instead of dragging it on and on and on. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Fri Sep 7 19:37:44 2007 From: opensource at till.name (Till Maas) Date: Fri, 07 Sep 2007 21:37:44 +0200 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <20070907131553.1027e240@mentok.boston.redhat.com> References: <200709071831.44080.opensource@till.name> <200709071906.32206.opensource@till.name> <20070907131553.1027e240@mentok.boston.redhat.com> Message-ID: <200709072137.44961.opensource@till.name> On Fr September 7 2007, Jesse Keating wrote: > Except that if all are approved prior to, one can use chain-build to > build the entire stack in one execution instead of dragging it on and > on and on. How often does one really need to do this? When I look trough the open review requests the majority does not depend on another review request. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Fri Sep 7 19:39:26 2007 From: opensource at till.name (Till Maas) Date: Fri, 07 Sep 2007 21:39:26 +0200 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <200709061943.57729.ville.skytta@iki.fi> References: <200709061633.01095.opensource@till.name> <1189089191.4022.3.camel@new-host-3> <200709061943.57729.ville.skytta@iki.fi> Message-ID: <200709072139.27451.opensource@till.name> On Do September 6 2007, Ville Skytt? wrote: > I would personally call it python-fuse anyway for consistency, and perhaps > add "Provides: fuse-python = VR", but maybe that's just me. Is doing it the other way round not good enough? Name: fuse-python Provides: python-fuse = VR Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Fri Sep 7 19:46:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 7 Sep 2007 15:46:58 -0400 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <200709072137.44961.opensource@till.name> References: <200709071831.44080.opensource@till.name> <200709071906.32206.opensource@till.name> <20070907131553.1027e240@mentok.boston.redhat.com> <200709072137.44961.opensource@till.name> Message-ID: <20070907154658.565df63c@mentok.boston.redhat.com> On Fri, 07 Sep 2007 21:37:44 +0200 Till Maas wrote: > How often does one really need to do this? When I look trough the > open review requests the majority does not depend on another review > request. I don't know how often. It does happen. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Fri Sep 7 20:00:40 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 7 Sep 2007 23:00:40 +0300 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <200709072139.27451.opensource@till.name> References: <200709061633.01095.opensource@till.name> <200709061943.57729.ville.skytta@iki.fi> <200709072139.27451.opensource@till.name> Message-ID: <200709072300.40644.ville.skytta@iki.fi> On Friday 07 September 2007, Till Maas wrote: > On Do September 6 2007, Ville Skytt? wrote: > > I would personally call it python-fuse anyway for consistency, and > > perhaps add "Provides: fuse-python = VR", but maybe that's just me. > > Is doing it the other way round not good enough? > > Name: fuse-python > Provides: python-fuse = VR Good enough for whom? Both of those definitely satisfy the current naming guidelines, but personally in cases like this I always go for "if it's bar for foo, or bar used from foo or the like, its Name: is foo-bar", ie this one would become python-fuse (assuming I guess correctly what the package contains). From opensource at till.name Fri Sep 7 20:03:33 2007 From: opensource at till.name (Till Maas) Date: Fri, 07 Sep 2007 22:03:33 +0200 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <200709072300.40644.ville.skytta@iki.fi> References: <200709061633.01095.opensource@till.name> <200709072139.27451.opensource@till.name> <200709072300.40644.ville.skytta@iki.fi> Message-ID: <200709072203.46137.opensource@till.name> On Fr September 7 2007, Ville Skytt? wrote: > On Friday 07 September 2007, Till Maas wrote: > > On Do September 6 2007, Ville Skytt? wrote: > > > I would personally call it python-fuse anyway for consistency, and > > > perhaps add "Provides: fuse-python = VR", but maybe that's just me. > > > > Is doing it the other way round not good enough? > > > > Name: fuse-python > > Provides: python-fuse = VR > > Good enough for whom? Both of those definitely satisfy the current naming Good enough for a user, will there be any differences if one uses yum to search for "fuse-python" or "python-fuse" or will both produce the same result? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From Fedora at FamilleCollet.com Sat Sep 8 12:38:39 2007 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 08 Sep 2007 14:38:39 +0200 Subject: [Fedora-packaging] Guidelines for packaging PHP addon modules (draft => official) Message-ID: <46E297CF.1030101@FamilleCollet.com> Since http://fedoraproject.org/wiki/PackagingDrafts/PHP is approved, can someone push section 3&4 to the official page (or give me the right to do the job). Regards, Remi From tibbs at math.uh.edu Sat Sep 8 16:02:41 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Sep 2007 11:02:41 -0500 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <200709072137.44961.opensource@till.name> References: <200709071831.44080.opensource@till.name> <200709071906.32206.opensource@till.name> <20070907131553.1027e240@mentok.boston.redhat.com> <200709072137.44961.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> How often does one really need to do this? Rather often, at least for the reviews I do. - J< From tcallawa at redhat.com Sat Sep 8 17:04:26 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 08 Sep 2007 13:04:26 -0400 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <200709072203.46137.opensource@till.name> References: <200709061633.01095.opensource@till.name> <200709072139.27451.opensource@till.name> <200709072300.40644.ville.skytta@iki.fi> <200709072203.46137.opensource@till.name> Message-ID: <1189271066.4831.32.camel@localhost.localdomain> On Fri, 2007-09-07 at 22:03 +0200, Till Maas wrote: > On Fr September 7 2007, Ville Skytt? wrote: > > On Friday 07 September 2007, Till Maas wrote: > > > On Do September 6 2007, Ville Skytt? wrote: > > > > I would personally call it python-fuse anyway for consistency, and > > > > perhaps add "Provides: fuse-python = VR", but maybe that's just me. > > > > > > Is doing it the other way round not good enough? > > > > > > Name: fuse-python > > > Provides: python-fuse = VR > > > > Good enough for whom? Both of those definitely satisfy the current naming > > Good enough for a user, will there be any differences if one uses yum to > search for "fuse-python" or "python-fuse" or will both produce the same > result? I don't think that yum search looks through provides, but I could be wrong on that. Should be easy enough to test (run repoquery on the one package, point yum at the new "repo" and run a search). ~spot From tcallawa at redhat.com Sat Sep 8 17:07:11 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 08 Sep 2007 13:07:11 -0400 Subject: [Fedora-packaging] Review Guidelines simplifications In-Reply-To: <200709071910.05889.opensource@till.name> References: <200709071831.44080.opensource@till.name> <1189184388.4300.19.camel@localhost.localdomain> <200709071910.05889.opensource@till.name> Message-ID: <1189271231.4831.35.camel@localhost.localdomain> On Fri, 2007-09-07 at 19:10 +0200, Till Maas wrote: > On Fr September 7 2007, Matthias Clasen wrote: > > > I'm not sure I see the point of this. The package must be buildable on > > the Fedora Buildsystem anyway, to enter the package collection. Pointing > > out that koji can do scratch builds as an alternative to mock for > > testing buildability might be useful, tough. > > It simplifies the review guidelines. Instead of at least a demanded local > rpmbuild and optional builds for every architecture and in mock and verifying > the BuildRequires (either with rpmdev-rmdevelrpms or mock) only one step is > needed. The advantage is also that always building for every architecture ist > tested. I think that I would rather amend the Review Guidelines to state that a successful scratch build in koji is an acceptable alternative to a successful local build. Either is permissable to meet this criteria. ~spot From tcallawa at redhat.com Sat Sep 8 17:08:21 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 08 Sep 2007 13:08:21 -0400 Subject: [Fedora-packaging] Guidelines for packaging PHP addon modules (draft => official) In-Reply-To: <46E297CF.1030101@FamilleCollet.com> References: <46E297CF.1030101@FamilleCollet.com> Message-ID: <1189271301.4831.37.camel@localhost.localdomain> On Sat, 2007-09-08 at 14:38 +0200, Remi Collet wrote: > Since http://fedoraproject.org/wiki/PackagingDrafts/PHP is approved, can > someone push section 3&4 to the official page (or give me the right to > do the job). I will do this as soon as I have time (I would do it right now, but I'm being dragged out the door). Alternately, if anyone else on the FPC wants to commit these changes for me, they're welcome to do so. (Just let me know that you did it, please) ~spot From nicolas.mailhot at laposte.net Sat Sep 8 17:22:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 08 Sep 2007 19:22:47 +0200 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <1189271066.4831.32.camel@localhost.localdomain> References: <200709061633.01095.opensource@till.name> <200709072139.27451.opensource@till.name> <200709072300.40644.ville.skytta@iki.fi> <200709072203.46137.opensource@till.name> <1189271066.4831.32.camel@localhost.localdomain> Message-ID: <1189272167.3276.0.camel@rousalka.dyndns.org> Le samedi 08 septembre 2007 ? 13:04 -0400, Tom "spot" Callaway a ?crit : > I don't think that yum search looks through provides, 1. It doesn't (yum-3.2.4-4.fc8.noarch) 2. It probably should -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tcallawa at redhat.com Sat Sep 8 17:30:09 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 08 Sep 2007 13:30:09 -0400 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <1189272167.3276.0.camel@rousalka.dyndns.org> References: <200709061633.01095.opensource@till.name> <200709072139.27451.opensource@till.name> <200709072300.40644.ville.skytta@iki.fi> <200709072203.46137.opensource@till.name> <1189271066.4831.32.camel@localhost.localdomain> <1189272167.3276.0.camel@rousalka.dyndns.org> Message-ID: <1189272609.4831.57.camel@localhost.localdomain> On Sat, 2007-09-08 at 19:22 +0200, Nicolas Mailhot wrote: > Le samedi 08 septembre 2007 ? 13:04 -0400, Tom "spot" Callaway a ?crit : > > > I don't think that yum search looks through provides, > > 1. It doesn't (yum-3.2.4-4.fc8.noarch) > 2. It probably should Someone more motivated (e.g not me!) should either try to patch this into yum, or should at least open a bug against yum for this item. :) ~spot From nicolas.mailhot at laposte.net Sat Sep 8 17:58:18 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 08 Sep 2007 19:58:18 +0200 Subject: [Fedora-packaging] Packaging/NamingGuidelines python modules naming In-Reply-To: <1189272609.4831.57.camel@localhost.localdomain> References: <200709061633.01095.opensource@till.name> <200709072139.27451.opensource@till.name> <200709072300.40644.ville.skytta@iki.fi> <200709072203.46137.opensource@till.name> <1189271066.4831.32.camel@localhost.localdomain> <1189272167.3276.0.camel@rousalka.dyndns.org> <1189272609.4831.57.camel@localhost.localdomain> Message-ID: <1189274298.5728.1.camel@rousalka.dyndns.org> Le samedi 08 septembre 2007 ? 13:30 -0400, Tom "spot" Callaway a ?crit : > On Sat, 2007-09-08 at 19:22 +0200, Nicolas Mailhot wrote: > > Le samedi 08 septembre 2007 ? 13:04 -0400, Tom "spot" Callaway a ?crit : > > > > > I don't think that yum search looks through provides, > > > > 1. It doesn't (yum-3.2.4-4.fc8.noarch) > > 2. It probably should > > Someone more motivated (e.g not me!) should either try to patch this > into yum, or should at least open a bug against yum for this item. :) ? https://bugzilla.redhat.com/show_bug.cgi?id=283611 Gwawawaaa -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From a.badger at gmail.com Tue Sep 11 00:17:41 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 10 Sep 2007 17:17:41 -0700 Subject: [Fedora-packaging] Python Eggs Draft 2 Message-ID: <46E5DEA5.5030005@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Draft 2 of the new Egg guidelines. I'm continuing to test things out so things might change a little. However, these are my current thoughts on how we can best use eggs in the distro and even if they change in specifics of spec file scripts, the general thrust is going to remain the same. http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs The basics are: Support eggs for all distutils and setuptools packages from f8 on. This depends on us reverting to upstream python WRT distutils in python-2.5. Jeremy, I've started testing what this changes but I need your input on whether we can make this change or not. Support for eggs for setuptools and distutils-only-when-required to make other packages work on f7 and below. Support for multi versions through eggs knowing that there's no API within setuptools that is "reliable" for making switching of versions work. A quick and dirty method that hacks the PYTHONPATH and involved method that makes using setuptools mandatory are documented as well as the problems that could occur with pkg_resources.require() and __require__. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG5d6lX6yAic2E7kgRArK5AJkBoBY2CD7m8sBCcS5JhVLyNappSQCfaAob vs5J5Z1+ORHjChflnyIbhkg= =le7v -----END PGP SIGNATURE----- From rdieter at math.unl.edu Tue Sep 11 13:31:14 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 11 Sep 2007 08:31:14 -0500 Subject: [Fedora-packaging] missing FPC meeting today Message-ID: <46E698A2.4060109@math.unl.edu> I'll likely not be able to attend today, gotta baby-sit the car in the shop. -- Rex From a.badger at gmail.com Tue Sep 11 22:32:55 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 11 Sep 2007 15:32:55 -0700 Subject: [Fedora-packaging] Python Egg Draft 3 Message-ID: <46E71797.5050608@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs This is the third round of the Python Egg Draft. It contains changes proposed at today's packaging meeting. # Sep 11, 2007 -- Add note that all eggs must be rebuilt from source. * Add summary of egg on-disk formats. * Revise where this information will be placed in the Guidelines. o Make most of it its own page o Add a short checklist of Must/Shoulds to go on Packaging/Python. And from slightly before the meeting: * Make the switch for eggs within distutils be F9 instead of F8 after talking with Jeremy. o Add some mailing list discussions to the links section. o Add a sample README.fedora file. I think I got everything except virtual Provides and virtual Requires. I'd like to make that a separate change to be discussed after we make sure we'll switch distutils egg generation on for F9. My reasoning is this: * Currently python doesn't have virtual provide symbols like perl or php do. * If we turn on egg generation in distutils, practically every python module is going to have egg-info. So if we start now with two separate namespaces python-egg(MODULE) and python(MODULE), by F-9 we could have everything using python-egg(MODULE) and next to nothing using python(). There are some little wrinkles in this and it may also be affected by Panu's work on a python-dependency-extractor for rpm. I'll send out a message on this shortly. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG5xeXX6yAic2E7kgRAmEgAJ0R8LghRVkxT7vW0GZEtqsxU68uCwCeJaTD Mpvw4V80emv4avD2+qbwnyM= =Tg9k -----END PGP SIGNATURE----- From pmatilai at a1.balanced.postal.mail.dreamhost.com Wed Sep 12 19:40:46 2007 From: pmatilai at a1.balanced.postal.mail.dreamhost.com (Panu Matilainen) Date: Wed, 12 Sep 2007 22:40:46 +0300 (EEST) Subject: [Fedora-packaging] Python Egg Draft 3 In-Reply-To: <46E71797.5050608@gmail.com> References: <46E71797.5050608@gmail.com> Message-ID: On Tue, 11 Sep 2007, Toshio Kuratomi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs > > This is the third round of the Python Egg Draft. It contains changes > proposed at today's packaging meeting. > > # Sep 11, 2007 -- Add note that all eggs must be rebuilt from source. > * Add summary of egg on-disk formats. > * Revise where this information will be placed in the Guidelines. > o Make most of it its own page > o Add a short checklist of Must/Shoulds to go on Packaging/Python. > > And from slightly before the meeting: > > * Make the switch for eggs within distutils be F9 instead of F8 after > talking with Jeremy. > o Add some mailing list discussions to the links section. > o Add a sample README.fedora file. > > I think I got everything except virtual Provides and virtual Requires. > I'd like to make that a separate change to be discussed after we make > sure we'll switch distutils egg generation on for F9. My reasoning is this: > > * Currently python doesn't have virtual provide symbols like perl or php do. > * If we turn on egg generation in distutils, practically every python > module is going to have egg-info. > > So if we start now with two separate namespaces python-egg(MODULE) and > python(MODULE), by F-9 we could have everything using python-egg(MODULE) > and next to nothing using python(). > > There are some little wrinkles in this and it may also be affected by > Panu's work on a python-dependency-extractor for rpm. I'll send out a > message on this shortly. Separating the namespaces is a fundamental problem for the dependency extractor. For provides this is obviously not an issue, but requires need to be generated without being able to actually locate (and possibly import) the actual module. Python syntax for importing egg- and regular modules is the same, so they need to live in the same namespace, otherwise the manual Requires just turn into manual BuildRequires and the depency extractor will be just adding syntactic sugar for nothing :) - Panu - From a.badger at gmail.com Thu Sep 13 00:28:36 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 12 Sep 2007 17:28:36 -0700 Subject: [Fedora-packaging] Python Egg Draft 3 In-Reply-To: References: <46E71797.5050608@gmail.com> Message-ID: <46E88434.6090700@gmail.com> Panu Matilainen wrote: > > Separating the namespaces is a fundamental problem for the dependency > extractor. For provides this is obviously not an issue, but requires > need to be generated without being able to actually locate (and possibly > import) the actual module. Python syntax for importing egg- and regular > modules is the same, so they need to live in the same namespace, > otherwise the manual Requires just turn into manual BuildRequires and > the depency extractor will be just adding syntactic sugar for nothing :) > I think I've figured out a way to make this almost work:: import sqlalchemy is equal to Requires python(sqlalchemy) Any of these:: __requires__='SQLAlchemy' pkg_resources.require('SQLAlchemy') requires.txt: install_requires = [ 'SQLAlchemy' ] are equal to python-egg(sqlalchemy) This breaks down when thinking about what happens in this case:: __requires__='TurboGears' import pkg_requires import sqlachemy At this point you have to know whether TurboGears or anything that it requires has a requires.txt which includes ['SQLAlchemy']. If it does we are using the egg interface to sqlalchemy. If it doesn't we are using the normal interface. So, assuming we remove our patch that stops generation of egg-info files for distutils generated modules for F9, I agree that there isn't very much value for quite a bit of work. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From pmatilai at a1.balanced.postal.mail.dreamhost.com Thu Sep 13 07:51:08 2007 From: pmatilai at a1.balanced.postal.mail.dreamhost.com (Panu Matilainen) Date: Thu, 13 Sep 2007 10:51:08 +0300 (EEST) Subject: [Fedora-packaging] Python Egg Draft 3 In-Reply-To: <46E88434.6090700@gmail.com> References: <46E71797.5050608@gmail.com> <46E88434.6090700@gmail.com> Message-ID: On Wed, 12 Sep 2007, Toshio Kuratomi wrote: > Panu Matilainen wrote: >> >> Separating the namespaces is a fundamental problem for the dependency >> extractor. For provides this is obviously not an issue, but requires >> need to be generated without being able to actually locate (and possibly >> import) the actual module. Python syntax for importing egg- and regular >> modules is the same, so they need to live in the same namespace, >> otherwise the manual Requires just turn into manual BuildRequires and >> the depency extractor will be just adding syntactic sugar for nothing :) >> > I think I've figured out a way to make this almost work:: > import sqlalchemy > > is equal to Requires python(sqlalchemy) > > Any of these:: > __requires__='SQLAlchemy' > pkg_resources.require('SQLAlchemy') > requires.txt: > install_requires = [ 'SQLAlchemy' ] > > are equal to python-egg(sqlalchemy) > > This breaks down when thinking about what happens in this case:: > __requires__='TurboGears' > import pkg_requires > import sqlachemy > > At this point you have to know whether TurboGears or anything that it > requires has a requires.txt which includes ['SQLAlchemy']. If it does > we are using the egg interface to sqlalchemy. If it doesn't we are > using the normal interface. > > So, assuming we remove our patch that stops generation of egg-info files > for distutils generated modules for F9, I agree that there isn't very > much value for quite a bit of work. Let me put it this way: why exactly do you want the eggs in a separate namespace? If using modules from them *required* using new interfaces it'd be a different story, but since they can be imported just like any regular module they should be in the same namespace. (or am I missing something here - I'm certainly not very familiar with the egg stuff?) One possibility would be to *only* extract python module dependencies from egg modules and software using the new requires interfaces and simply forget about the old-style modules. - Panu - From philipp_subx at redfish-solutions.com Fri Sep 14 02:12:25 2007 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 13 Sep 2007 19:12:25 -0700 Subject: [Fedora-packaging] Need help packaging proftpd Message-ID: <46E9EE09.8040106@redfish-solutions.com> I'm trying to get a .spec polished and checked in for the release of proftpd-1.3.1, but I'm having a few issues with it. If anyone has the time to offer some assistance, I'd appreciate it. I'm not an RPM guru... I've skimmed Maximum RPM a couple of times a year or two ago. I just want to get a more recent build of proftpd into the Fedora distro space, and the way to do that is with a proper .spec file in the source tree. Contact me offline if you can provide some comments/guidance. Thanks, -Philip From a.badger at gmail.com Fri Sep 14 02:29:49 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 13 Sep 2007 19:29:49 -0700 Subject: [Fedora-packaging] Python Egg Draft 3 In-Reply-To: References: <46E71797.5050608@gmail.com> <46E88434.6090700@gmail.com> Message-ID: <46E9F21D.1000801@gmail.com> Panu Matilainen wrote: > On Wed, 12 Sep 2007, Toshio Kuratomi wrote: > >> Panu Matilainen wrote: >>> >>> Separating the namespaces is a fundamental problem for the dependency >>> extractor. For provides this is obviously not an issue, but requires >>> need to be generated without being able to actually locate (and possibly >>> import) the actual module. Python syntax for importing egg- and regular >>> modules is the same, so they need to live in the same namespace, >>> otherwise the manual Requires just turn into manual BuildRequires and >>> the depency extractor will be just adding syntactic sugar for nothing :) >>> >> I think I've figured out a way to make this almost work:: >> import sqlalchemy >> >> is equal to Requires python(sqlalchemy) >> >> Any of these:: >> __requires__='SQLAlchemy' >> pkg_resources.require('SQLAlchemy') >> requires.txt: >> install_requires = [ 'SQLAlchemy' ] >> >> are equal to python-egg(sqlalchemy) >> >> This breaks down when thinking about what happens in this case:: >> __requires__='TurboGears' >> import pkg_requires >> import sqlachemy >> >> At this point you have to know whether TurboGears or anything that it >> requires has a requires.txt which includes ['SQLAlchemy']. If it does >> we are using the egg interface to sqlalchemy. If it doesn't we are >> using the normal interface. >> >> So, assuming we remove our patch that stops generation of egg-info files >> for distutils generated modules for F9, I agree that there isn't very >> much value for quite a bit of work. > > Let me put it this way: why exactly do you want the eggs in a separate > namespace? If using modules from them *required* using new interfaces > it'd be a different story, but since they can be imported just like any > regular module they should be in the same namespace. (or am I missing > something here - I'm certainly not very familiar with the egg stuff?) > Well, the way I'm proposing in the egg draft we will have compat-packages that are only importable via an egg interface. For instance python-sqlalchemy0.3 has these directories:: %{python_sitelib}/SQLAlchemy-0.3.10-py2.5.egg/ %{python_sitelib}/SQLAlchemy-0.3.10-py2.5.egg/sqlalchemy To be able to import it you need to do something like this: __requires__='SQLAlchemy >= 0.3, < 0.4alpha' import pkg_resources import sqlalchemy Or manually add %{python_sitelib}/SQLAlchemy-0.3.10-py2.5.egg/sqlalchemy to sys.path. The main python-sqlalchemy module would be directly importable or you could select it specifically using something like __requires__='SQLAlchemy >= 0.4, < 0.5'. > One possibility would be to *only* extract python module dependencies > from egg modules and software using the new requires interfaces and > simply forget about the old-style modules. > I'd rather we extract old-style modules and forget about eggs as the eggs don't come into play as often for us. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From petersen at redhat.com Fri Sep 14 02:58:23 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 14 Sep 2007 12:58:23 +1000 Subject: [Fedora-packaging] small typo on Packaging/SourceURL Message-ID: <46E9F8CF.3030506@redhat.com> There is a small typo at the bottom of http://fedoraproject.org/wiki/Packaging/SourceURL in the section "Using %{version}". I guess it should read "..., because most of the time you do not _need_ to edit ...". Thanks, Jens From panemade at gmail.com Fri Sep 14 09:08:53 2007 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 14 Sep 2007 14:38:53 +0530 Subject: [Fedora-packaging] Packaging/ScriptletSnippets Fonts section needs to mention Buildrequires In-Reply-To: <7390.192.54.193.51.1176278275.squirrel@rousalka.dyndns.org> References: <46130BD7.3070708@redhat.com> <461AF55D.7090704@redhat.com> <1176184707.25025.0.camel@rousalka.dyndns.org> <461C3FC0.3060005@redhat.com> <7390.192.54.193.51.1176278275.squirrel@rousalka.dyndns.org> Message-ID: Hi Nicolas, On 4/11/07, Nicolas Mailhot wrote: > Le Mer 11 avril 2007 03:54, Jens Petersen a ?crit : > > Nicolas Mailhot wrote: > >> Nope. Their whole point is not to add a fontconfig dep to font packages > > > > Should bugs be filed against all fonts packages that currently require > > fontconfig? > > IMHO yes. When this was formalized (around Bitstream Vera inclusion in > fedora.us then FC) non adherence of font packages to any specific renderer > was an explicit objective. (I'm speaking of truetype/opentype packages > there, core fonts are a lost cause). > > The most one can do is conflict with old fontconfig packages if the rpm > dumps a conf file in /etc/fonts, since fontconfig syntax has evolved over > time. Can you please provide more information on this issue of not having "Requires: fontconfig" in fonts packages? Currently I am in confusion on whether to drop fontconfig as Requires or not and still packaging guidelines is missing this issue to address it. I am sure many new packages got added to Fedora recently and many will be coming in future. But still we are missing proper fonts guidelines page. I think its good if we have wiki page that will describe and give sample SPEC for fonts packages including how to handle license and its naming issues for new coming fonts package reviews. Regards, Parag. From limb at jcomserv.net Fri Sep 14 10:56:21 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 14 Sep 2007 05:56:21 -0500 (CDT) Subject: [Fedora-packaging] Need help packaging proftpd In-Reply-To: <46E9EE09.8040106@redfish-solutions.com> References: <46E9EE09.8040106@redfish-solutions.com> Message-ID: <12383.63.85.68.164.1189767381.squirrel@mail.jcomserv.net> > I'm trying to get a .spec polished and checked in for the release of > proftpd-1.3.1, but I'm having a few issues with it. > > If anyone has the time to offer some assistance, I'd appreciate it. > > I'm not an RPM guru... I've skimmed Maximum RPM a couple of times a > year or two ago. > > I just want to get a more recent build of proftpd into the Fedora distro > space, and the way to do that is with a proper .spec file in the source > tree. > > Contact me offline if you can provide some comments/guidance. Phillip, I tried, but I got. . . ----- The following addresses had permanent fatal errors ----- (reason: 554 mail.redfish-solutions.com ESMTP not accepting messages) ----- Transcript of session follows ----- ... while talking to mail.redfish-solutions.com.: <<< 554 mail.redfish-solutions.com ESMTP not accepting messages 554 5.0.0 Service unavailable > Thanks, > > -Philip > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- novus ordo absurdum From philipp_subx at redfish-solutions.com Sat Sep 15 18:07:23 2007 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Sat, 15 Sep 2007 11:07:23 -0700 Subject: [Fedora-packaging] Need help packaging proftpd In-Reply-To: <12383.63.85.68.164.1189767381.squirrel@mail.jcomserv.net> References: <46E9EE09.8040106@redfish-solutions.com> <12383.63.85.68.164.1189767381.squirrel@mail.jcomserv.net> Message-ID: <46EC1F5B.8080208@redfish-solutions.com> Jon Ciesla wrote: >> I'm trying to get a .spec polished and checked in for the release of >> proftpd-1.3.1, but I'm having a few issues with it. >> >> If anyone has the time to offer some assistance, I'd appreciate it. >> >> I'm not an RPM guru... I've skimmed Maximum RPM a couple of times a >> year or two ago. >> >> I just want to get a more recent build of proftpd into the Fedora distro >> space, and the way to do that is with a proper .spec file in the source >> tree. >> >> Contact me offline if you can provide some comments/guidance. >> > > Phillip, I tried, but I got. . . > > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 mail.redfish-solutions.com ESMTP not accepting messages) > > ----- Transcript of session follows ----- > ... while talking to mail.redfish-solutions.com.: > <<< 554 mail.redfish-solutions.com ESMTP not accepting messages > 554 5.0.0 Service unavailable > Odd. Not sure why. If it were my spam filters (they are rather aggressive), you would have gotten a different message. I'll look into it. I'll post the .x86_64.rpm and the .src.rpm files onto ftp://ftp.redfish-solutions.com/ ... they should be there shortly (within 15 minutes). Wasn't sure if I should make "run from inetd (xinetd)" be the default or not. Anyone have any strong preferences? Using xinetd doesn't add a lot of overhead, except maybe on a very high volume site... and it does allow the use of tcp-wrappers with no additional configuration (whereas using mod_wrap.so in standalone mode requires a little more work). -Philip >> Thanks, >> >> -Philip >> >> From jeremy at jeremysanders.net Mon Sep 17 11:16:22 2007 From: jeremy at jeremysanders.net (Jeremy Sanders) Date: Mon, 17 Sep 2007 12:16:22 +0100 Subject: [Fedora-packaging] Alpine Message-ID: I see there is source for Alpine 0.9999 available. This is an "alpha" release of a replacement for the text user interface Pine mail client. See http://www.washington.edu/alpine/ and ftp://ftp.cac.washington.edu/alpine/ The advantages of this over the old Pine is that the source code has been reorganised and it now uses the free Apache License (version 2). This could added to Fedora now (unlike the original Pine). I'm not sure how many Fedora users are still addicted to Pine (like me). I wonder whether it would be a good idea to package up soon before it is finally released (they have a source rpm available, but I haven't looked at it yet). I believe it also has a web interface version, which could be interesting. I've been running the text mode client for a bit now and the quality already looks good - it seems at least as good as Pine at the moment. Jeremy -- http://jeremysanders.net/ From tibbs at math.uh.edu Mon Sep 17 11:28:22 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 17 Sep 2007 06:28:22 -0500 Subject: [Fedora-packaging] Alpine In-Reply-To: References: Message-ID: >>>>> "JS" == Jeremy Sanders writes: JS> I see there is source for Alpine 0.9999 available. I'm not sure why you're sending this to fedora-packaging, but in any case Alpine is already in the distro: http://koji.fedoraproject.org/koji/packageinfo?packageID=4982 http://koji.fedoraproject.org/koji/buildinfo?buildID=18087 - J< From dlutter at redhat.com Mon Sep 17 17:56:41 2007 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 17 Sep 2007 17:56:41 +0000 Subject: [Fedora-packaging] Unable to attend meeting on 9/18 Message-ID: <1190051801.20285.4.camel@localhost.localdomain> I won't be able to attend, sorry. David From petersen at redhat.com Wed Sep 19 05:30:26 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 19 Sep 2007 15:30:26 +1000 Subject: [Fedora-packaging] Packaging/ScriptletSnippets, fonts section: no "|| :" at the end of the fc-cache call? In-Reply-To: <46D79CE8.2040005@leemhuis.info> References: <46D5172F.7010604@leemhuis.info> <46D79CE8.2040005@leemhuis.info> Message-ID: <46F0B3F2.6060704@redhat.com> Thorsten Leemhuis ????????: > I noticed in between that is was something stupid on my side, but that > doesn't matter much IMHO. The ScriptletSnippets IMHO and AFAIK should be > adjusted to make sure the script for this or similar errors don't end > with a errorlevel != 0 I agree. From petersen at redhat.com Wed Sep 19 05:37:04 2007 From: petersen at redhat.com (Jens Petersen) Date: Wed, 19 Sep 2007 15:37:04 +1000 Subject: [Fedora-packaging] Packaging/ScriptletSnippets Fonts section needs to mention Buildrequires In-Reply-To: References: <46130BD7.3070708@redhat.com> <461AF55D.7090704@redhat.com> <1176184707.25025.0.camel@rousalka.dyndns.org> <461C3FC0.3060005@redhat.com> <7390.192.54.193.51.1176278275.squirrel@rousalka.dyndns.org> Message-ID: <46F0B580.60104@redhat.com> Parag N(????) ????????: > Can you please provide more information on this issue of not having > "Requires: fontconfig" in fonts packages? The argument I can see for having "Requires(post): fontconfig", etc is that potentially some fonts packages could get installed before fontconfig does and so not get included in the cache? Jens -- Jens Petersen I18n Engineering Red Hat From mclasen at redhat.com Wed Sep 19 05:43:05 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 19 Sep 2007 01:43:05 -0400 Subject: [Fedora-packaging] Packaging/ScriptletSnippets Fonts section needs to mention Buildrequires In-Reply-To: <46F0B580.60104@redhat.com> References: <46130BD7.3070708@redhat.com> <461AF55D.7090704@redhat.com> <1176184707.25025.0.camel@rousalka.dyndns.org> <461C3FC0.3060005@redhat.com> <7390.192.54.193.51.1176278275.squirrel@rousalka.dyndns.org> <46F0B580.60104@redhat.com> Message-ID: <1190180585.21756.3.camel@localhost.localdomain> On Wed, 2007-09-19 at 15:37 +1000, Jens Petersen wrote: > Parag N(????) ????????: > > Can you please provide more information on this issue of not having > > "Requires: fontconfig" in fonts packages? > > The argument I can see for having "Requires(post): fontconfig", etc is > that potentially some fonts packages could get installed before > fontconfig does and so not get included in the cache? > > Jens If fontconfig gets installed later, it should create all the required caches in %post: # Force regeneration of all fontconfig cache files From nicolas.mailhot at laposte.net Wed Sep 19 07:53:08 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 19 Sep 2007 09:53:08 +0200 (CEST) Subject: [Fedora-packaging] Packaging/ScriptletSnippets Fonts section needs to mention Buildrequires In-Reply-To: <46F0B580.60104@redhat.com> References: <46130BD7.3070708@redhat.com> <461AF55D.7090704@redhat.com> <1176184707.25025.0.camel@rousalka.dyndns.org> <461C3FC0.3060005@redhat.com> <7390.192.54.193.51.1176278275.squirrel@rousalka.dyndns.org> <46F0B580.60104@redhat.com> Message-ID: <39266.192.54.193.51.1190188388.squirrel@rousalka.dyndns.org> Le Mer 19 septembre 2007 07:37, Jens Petersen a ?crit : > Parag N(????) ????????: >> Can you please provide more information on this issue of not having >> "Requires: fontconfig" in fonts packages? > > The argument I can see for having "Requires(post): fontconfig", etc is > that potentially some fonts packages could get installed before > fontconfig does and so not get included in the cache? Fontconfig creates its cache on install. There is no need for Requires(post): fontconfig Since there were some interested replies to my font SIG proposal but no deluge of would-be SIG contributors I'll probably document in my wiki space with no particular urgency -- Nicolas Mailhot From ville.skytta at iki.fi Wed Sep 19 19:36:18 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 19 Sep 2007 22:36:18 +0300 Subject: [Fedora-packaging] small typo on Packaging/SourceURL In-Reply-To: <46E9F8CF.3030506@redhat.com> References: <46E9F8CF.3030506@redhat.com> Message-ID: <200709192236.18718.ville.skytta@iki.fi> On Friday 14 September 2007, Jens Petersen wrote: > There is a small typo at the bottom of > http://fedoraproject.org/wiki/Packaging/SourceURL > in the section "Using %{version}". > > I guess it should read "..., because most of the time you do not _need_ > to edit ...". Fixed, thanks. From tibbs at math.uh.edu Wed Sep 19 21:37:30 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Sep 2007 16:37:30 -0500 Subject: [Fedora-packaging] Apologize for missing the meeting Message-ID: My apologies for missing Tuesday's meeting; I have been in hospital with a nasty case of some food-borne illness and am only now strong enough to sit up at a computer. I don't think I have a proper log of the meeting, and I still have a tonne of mail to go through. If the meeting hasn't been summarized yet, could someone take care of that for me? - J< From fedora at leemhuis.info Thu Sep 20 05:36:16 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 20 Sep 2007 07:36:16 +0200 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages Message-ID: <46F206D0.9060109@leemhuis.info> Hi, I'm running rawhide these days again and during yum update I quite often see messages like > Updating : gedit ##################### [173/382] > gconfd-2: no process killed > Updating : deskbar-applet ##################### [174/382] > gconfd-2: Kein Prozess abgebrochen > Updating : gnome-terminal ##################### [175/382] Looking closer at the spec and at the Gconf session on http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets it seems they run killall -HUP gconfd-2 || : to make sure any running gconfd-2 pick up newly installed schemes. But well, as you can see from above output there might be cases when no gconfd-2 is running, thus killall will print a warning. I think we should avoid such useless warnings -- thus it would seem better to me to use killall with "--quiet" or use killall -HUP gconfd-2 2> /dev/null || : instead. What do you guys think? Cu knurd From pertusus at free.fr Thu Sep 20 22:10:15 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 21 Sep 2007 00:10:15 +0200 Subject: [Fedora-packaging] tex related packages naming Message-ID: <20070920221015.GC1456@free.fr> Hello, Could it be possible for the packaging commitee to decide on that issue, please? The proposals are: * prefix with tex- * no specific naming. Prefix with tex- when another package has the same name Could it be possible to have a vote/decision on that issue? In any case I think that a (long) period should be left for packagers to change their package names. -- Pat From tcallawa at redhat.com Thu Sep 20 23:53:32 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 20 Sep 2007 19:53:32 -0400 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: <20070920221015.GC1456@free.fr> References: <20070920221015.GC1456@free.fr> Message-ID: <1190332412.3418.40.camel@localhost.localdomain> On Fri, 2007-09-21 at 00:10 +0200, Patrice Dumas wrote: > Hello, > > Could it be possible for the packaging commitee to decide on that issue, > please? The proposals are: > > * prefix with tex- > * no specific naming. Prefix with tex- when another package has the same > name > > Could it be possible to have a vote/decision on that issue? Please pick one and propose it to us. (Or both, as they seem to work well together). Ideally, also follow our well-documented (although, not always well known) procedure: http://fedoraproject.org/wiki/Packaging/Committee#head-bc786fd8400956418c30ac87c30733f0c008b146 Thanks, ~spot From pertusus at free.fr Fri Sep 21 05:45:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 21 Sep 2007 07:45:51 +0200 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: <1190332412.3418.40.camel@localhost.localdomain> References: <20070920221015.GC1456@free.fr> <1190332412.3418.40.camel@localhost.localdomain> Message-ID: <20070921054550.GB16823@free.fr> On Thu, Sep 20, 2007 at 07:53:32PM -0400, Tom spot Callaway wrote: > > On Fri, 2007-09-21 at 00:10 +0200, Patrice Dumas wrote: > > Hello, > > > > Could it be possible for the packaging commitee to decide on that issue, > > please? The proposals are: > > > > * prefix with tex- > > * no specific naming. Prefix with tex- when another package has the same > > name > > > > Could it be possible to have a vote/decision on that issue? > > Please pick one and propose it to us. (Or both, as they seem to work > well together). I can't propose one, since there are people that want one and other that want the other. I am asking for a ruling by the packaging commitee. As for the Guideline change procedure, maybe this is useful in some cases, but what I ask for is a precise question for an existing point in guideline which is now wrong (use of the tetex- prefix), I don't think that bureaucracy is neeed (in that case, it is different for more complex guidelines). -- Pat From petersen at redhat.com Fri Sep 21 09:54:00 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 21 Sep 2007 19:54:00 +1000 Subject: [Fedora-packaging] Re: fonts packages requiring fontconfig In-Reply-To: <39266.192.54.193.51.1190188388.squirrel@rousalka.dyndns.org> References: <46130BD7.3070708@redhat.com> <461AF55D.7090704@redhat.com> <1176184707.25025.0.camel@rousalka.dyndns.org> <461C3FC0.3060005@redhat.com> <7390.192.54.193.51.1176278275.squirrel@rousalka.dyndns.org> <46F0B580.60104@redhat.com> <39266.192.54.193.51.1190188388.squirrel@rousalka.dyndns.org> Message-ID: <46F394B8.3030805@redhat.com> Nicolas Mailhot ????????: > Fontconfig creates its cache on install. There is no need for > Requires(post): fontconfig Ok, that is good then. One other small thing: except a few fonts, it seems only fontconfig currently owns /usr/share/fonts. Should it be owned by filesystem instead? > Since there were some interested replies to my font SIG proposal but > no deluge of would-be SIG contributors I'll probably document in my > wiki space with no particular urgency Ok, I see. If you like I would be happy to put the documentation of fonts for different languages, etc under I18N/Fonts in the wiki. :) Jens From nicolas.mailhot at laposte.net Fri Sep 21 11:52:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 21 Sep 2007 13:52:24 +0200 (CEST) Subject: [Fedora-packaging] Re: fonts packages requiring fontconfig In-Reply-To: <46F394B8.3030805@redhat.com> References: <46130BD7.3070708@redhat.com> <461AF55D.7090704@redhat.com> <1176184707.25025.0.camel@rousalka.dyndns.org> <461C3FC0.3060005@redhat.com> <7390.192.54.193.51.1176278275.squirrel@rousalka.dyndns.org> <46F0B580.60104@redhat.com> <39266.192.54.193.51.1190188388.squirrel@rousalka.dyndns.org> <46F394B8.3030805@redhat.com> Message-ID: <23392.192.54.193.51.1190375544.squirrel@rousalka.dyndns.org> Le Ven 21 septembre 2007 11:54, Jens Petersen a ?crit : > Nicolas Mailhot ????????: >> Fontconfig creates its cache on install. There is no need for >> Requires(post): fontconfig > > Ok, that is good then. > > One other small thing: except a few fonts, it seems only fontconfig > currently owns /usr/share/fonts. Should it be owned by filesystem > instead? I didn't check but if its not owned by filesystem it should be >> Since there were some interested replies to my font SIG proposal but >> no deluge of would-be SIG contributors I'll probably document in my >> wiki space with no particular urgency > > Ok, I see. If you like I would be happy to put the documentation of > fonts for different languages, etc under I18N/Fonts in the wiki. :) Well it seems this message has the intended effect of getting a few more people react, to I guess we may still get a font SIG :) At least I'll look this week-end what is required to formally create one, and start working on the wiki pages Regards, -- Nicolas Mailhot From tcallawa at redhat.com Fri Sep 21 12:59:21 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 21 Sep 2007 08:59:21 -0400 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: <20070921054550.GB16823@free.fr> References: <20070920221015.GC1456@free.fr> <1190332412.3418.40.camel@localhost.localdomain> <20070921054550.GB16823@free.fr> Message-ID: <1190379561.3418.45.camel@localhost.localdomain> On Fri, 2007-09-21 at 07:45 +0200, Patrice Dumas wrote: > On Thu, Sep 20, 2007 at 07:53:32PM -0400, Tom spot Callaway wrote: > > > > On Fri, 2007-09-21 at 00:10 +0200, Patrice Dumas wrote: > > > Hello, > > > > > > Could it be possible for the packaging commitee to decide on that issue, > > > please? The proposals are: > > > > > > * prefix with tex- > > > * no specific naming. Prefix with tex- when another package has the same > > > name > > > > > > Could it be possible to have a vote/decision on that issue? > > > > Please pick one and propose it to us. (Or both, as they seem to work > > well together). > > I can't propose one, since there are people that want one and other > that want the other. I am asking for a ruling by the packaging > commitee. Fair enough. I propose that we change the prefix from tetex- to tex-, since these packages were prefixed before. ~spot From a.badger at gmail.com Wed Sep 19 21:55:28 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 19 Sep 2007 14:55:28 -0700 Subject: [Fedora-packaging] Apologize for missing the meeting In-Reply-To: References: Message-ID: <46F19AD0.4000902@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason L Tibbitts III wrote: > My apologies for missing Tuesday's meeting; I have been in hospital with a > nasty case of some food-borne illness and am only now strong enough to > sit up at a computer. > > I don't think I have a proper log of the meeting, and I still have a > tonne of mail to go through. If the meeting hasn't been summarized > yet, could someone take care of that for me? > No worries, I took care of it today. (Sent it to fedora-devel as I'm not sure where we're sending it now that -maintainers is gone.) Hope you have a quick recovery, - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG8ZrQX6yAic2E7kgRAsUvAKCcyXHF37pBvFq8Mi7wdgmUSC79LwCZAaON spU4Q8kF8Mh8q/QdszLHZkc= =MXo2 -----END PGP SIGNATURE----- From a.badger at gmail.com Fri Sep 21 23:36:01 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 21 Sep 2007 16:36:01 -0700 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: <1190379561.3418.45.camel@localhost.localdomain> References: <20070920221015.GC1456@free.fr> <1190332412.3418.40.camel@localhost.localdomain> <20070921054550.GB16823@free.fr> <1190379561.3418.45.camel@localhost.localdomain> Message-ID: <46F45561.7070309@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom "spot" Callaway wrote: > On Fri, 2007-09-21 at 07:45 +0200, Patrice Dumas wrote: >> On Thu, Sep 20, 2007 at 07:53:32PM -0400, Tom spot Callaway wrote: >>> On Fri, 2007-09-21 at 00:10 +0200, Patrice Dumas wrote: >>>> Hello, >>>> >>>> Could it be possible for the packaging commitee to decide on that issue, >>>> please? The proposals are: >>>> >>>> * prefix with tex- >>>> * no specific naming. Prefix with tex- when another package has the same >>>> name >>>> >>>> Could it be possible to have a vote/decision on that issue? >>> Please pick one and propose it to us. (Or both, as they seem to work >>> well together). >> I can't propose one, since there are people that want one and other >> that want the other. I am asking for a ruling by the packaging >> commitee. > > Fair enough. I propose that we change the prefix from tetex- to tex-, > since these packages were prefixed before. > If email voting is sufficient for this, +1 to making the prefix tex- - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG9FVhX6yAic2E7kgRApByAKCf3aAqqqEk1aMqmuXlRFe1xLCplgCfa1MP YHzK0+IvO6coB8JpJRTde9Y= =c13X -----END PGP SIGNATURE----- From jkeating at redhat.com Fri Sep 21 23:55:18 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 21 Sep 2007 19:55:18 -0400 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: <46F45561.7070309@gmail.com> References: <20070920221015.GC1456@free.fr> <1190332412.3418.40.camel@localhost.localdomain> <20070921054550.GB16823@free.fr> <1190379561.3418.45.camel@localhost.localdomain> <46F45561.7070309@gmail.com> Message-ID: <20070921195518.57a2f78f@redhat.com> On Fri, 21 Sep 2007 16:36:01 -0700 Toshio Kuratomi wrote: > If email voting is sufficient for this, > > +1 to making the prefix tex- +1 from the "just pick one and be consistent" crowd. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From a.badger at gmail.com Sat Sep 22 04:03:05 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 21 Sep 2007 21:03:05 -0700 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: <46F206D0.9060109@leemhuis.info> References: <46F206D0.9060109@leemhuis.info> Message-ID: <46F493F9.7030104@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thorsten Leemhuis wrote: > Hi, > > I'm running rawhide these days again and during yum update I quite often > see messages like > >> Updating : gedit ##################### [173/382] >> gconfd-2: no process killed >> Updating : deskbar-applet ##################### [174/382] >> gconfd-2: Kein Prozess abgebrochen >> Updating : gnome-terminal ##################### [175/382] > > Looking closer at the spec and at the Gconf session on > http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets > it seems they run > > killall -HUP gconfd-2 || : > > to make sure any running gconfd-2 pick up newly installed schemes. But > well, as you can see from above output there might be cases when no > gconfd-2 is running, thus killall will print a warning. > > I think we should avoid such useless warnings -- thus it would seem > better to me to use killall with "--quiet" or use > > killall -HUP gconfd-2 2> /dev/null || : > > instead. What do you guys think? > This looks like a good change. Anyone object to me going ahead and changing it? - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG9JP5X6yAic2E7kgRAoCJAJ0d4x/I48DT4X/S01mT1u61gDKm3wCfQ6qO FB3LTGHUeUbop4nXIOVpRAQ= =33Sy -----END PGP SIGNATURE----- From tibbs at math.uh.edu Sat Sep 22 04:08:13 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Sep 2007 23:08:13 -0500 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: <46F493F9.7030104@gmail.com> References: <46F206D0.9060109@leemhuis.info> <46F493F9.7030104@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> This looks like a good change. Anyone object to me going ahead TK> and changing it? No objection here; removing inconsistencies from ScriptletSnippets is always a good thing. Using --quiet is probably the best choice if it's supported as far back as we need it to be. - J< From mclasen at redhat.com Sat Sep 22 04:23:47 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 22 Sep 2007 00:23:47 -0400 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: References: <46F206D0.9060109@leemhuis.info> <46F493F9.7030104@gmail.com> Message-ID: <1190435027.5089.5.camel@localhost.localdomain> On Fri, 2007-09-21 at 23:08 -0500, Jason L Tibbitts III wrote: > >>>>> "TK" == Toshio Kuratomi writes: > > TK> This looks like a good change. Anyone object to me going ahead > TK> and changing it? > > No objection here; removing inconsistencies from ScriptletSnippets is > always a good thing. Using --quiet is probably the best choice if > it's supported as far back as we need it to be. > The kill is completely redundant nowadays, since we have: --- GConf-2.18.0.1/gconf/gconftool.c.reload 2007-03-02 17:10:13.000000000 -0500 +++ GConf-2.18.0.1/gconf/gconftool.c 2007-03-13 02:21:29.000000000 -0400 @@ -3780,6 +3780,8 @@ ++args; } + g_spawn_command_line_sync ("/usr/bin/killall -q -TERM " GCONF_SERVERDIR "/" GCONFD, NULL, NULL, NULL, NULL); + retval |= do_sync (conf); return retval; } From rc040203 at freenet.de Sat Sep 22 04:38:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 22 Sep 2007 06:38:14 +0200 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: <1190435027.5089.5.camel@localhost.localdomain> References: <46F206D0.9060109@leemhuis.info> <46F493F9.7030104@gmail.com> <1190435027.5089.5.camel@localhost.localdomain> Message-ID: <1190435894.4733.82.camel@mccallum.corsepiu.local> On Sat, 2007-09-22 at 00:23 -0400, Matthias Clasen wrote: > On Fri, 2007-09-21 at 23:08 -0500, Jason L Tibbitts III wrote: > > >>>>> "TK" == Toshio Kuratomi writes: > > > > TK> This looks like a good change. Anyone object to me going ahead > > TK> and changing it? > > > > No objection here; removing inconsistencies from ScriptletSnippets is > > always a good thing. Using --quiet is probably the best choice if > > it's supported as far back as we need it to be. > > > > The kill is completely redundant nowadays, since we have: > > > --- GConf-2.18.0.1/gconf/gconftool.c.reload 2007-03-02 > 17:10:13.000000000 -0500 > +++ GConf-2.18.0.1/gconf/gconftool.c 2007-03-13 02:21:29.000000000 > -0400 > @@ -3780,6 +3780,8 @@ > ++args; > } > > + g_spawn_command_line_sync ("/usr/bin/killall -q -TERM " > GCONF_SERVERDIR "/" GCONFD, NULL, NULL, NULL, NULL); > + > retval |= do_sync (conf); > return retval; > } Then gconftool should probably better Requires: /usr/bin/killall Ralf From tibbs at math.uh.edu Sat Sep 22 04:49:57 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Sep 2007 23:49:57 -0500 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: <1190435027.5089.5.camel@localhost.localdomain> References: <46F206D0.9060109@leemhuis.info> <46F493F9.7030104@gmail.com> <1190435027.5089.5.camel@localhost.localdomain> Message-ID: >>>>> "MC" == Matthias Clasen writes: MC> The kill is completely redundant nowadays, since we have: Does nowadays extend back to RHEL4? If not, we need to document the point at which it becomes unnecessary. - J< From mclasen at redhat.com Sat Sep 22 04:58:36 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 22 Sep 2007 00:58:36 -0400 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: References: <46F206D0.9060109@leemhuis.info> <46F493F9.7030104@gmail.com> <1190435027.5089.5.camel@localhost.localdomain> Message-ID: <1190437116.5089.6.camel@localhost.localdomain> On Fri, 2007-09-21 at 23:49 -0500, Jason L Tibbitts III wrote: > >>>>> "MC" == Matthias Clasen writes: > > MC> The kill is completely redundant nowadays, since we have: > > Does nowadays extend back to RHEL4? If not, we need to document the > point at which it becomes unnecessary. * Wed Feb 1 2006 Christopher Aillon 2.13.5-2 - Add patch from Mandriva to reload GConf2 every time a schema is added or removed (solves bug 173869) From mclasen at redhat.com Sat Sep 22 04:59:53 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 22 Sep 2007 00:59:53 -0400 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: <1190435894.4733.82.camel@mccallum.corsepiu.local> References: <46F206D0.9060109@leemhuis.info> <46F493F9.7030104@gmail.com> <1190435027.5089.5.camel@localhost.localdomain> <1190435894.4733.82.camel@mccallum.corsepiu.local> Message-ID: <1190437193.5089.8.camel@localhost.localdomain> On Sat, 2007-09-22 at 06:38 +0200, Ralf Corsepius wrote: > Then gconftool should probably better > Requires: /usr/bin/killall That is true. From tibbs at math.uh.edu Sat Sep 22 05:15:54 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Sep 2007 00:15:54 -0500 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: <1190437116.5089.6.camel@localhost.localdomain> References: <46F206D0.9060109@leemhuis.info> <46F493F9.7030104@gmail.com> <1190435027.5089.5.camel@localhost.localdomain> <1190437116.5089.6.camel@localhost.localdomain> Message-ID: >>>>> "MC" == Matthias Clasen writes: MC> * Wed Feb 1 2006 Christopher Aillon 2.13.5-2 So that's a definite no for RHEL4 (looks like 2.8.1), but yes for FC5 and later. Which means Fedora doesn't care but EPEL does, and I think we still try to keep our documents valid for EPEL. - J< From a.badger at gmail.com Sat Sep 22 06:38:59 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 21 Sep 2007 23:38:59 -0700 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: <1190437116.5089.6.camel@localhost.localdomain> References: <46F206D0.9060109@leemhuis.info> <46F493F9.7030104@gmail.com> <1190435027.5089.5.camel@localhost.localdomain> <1190437116.5089.6.camel@localhost.localdomain> Message-ID: <46F4B883.9000105@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthias Clasen wrote: > On Fri, 2007-09-21 at 23:49 -0500, Jason L Tibbitts III wrote: >>>>>>> "MC" == Matthias Clasen writes: >> MC> The kill is completely redundant nowadays, since we have: >> >> Does nowadays extend back to RHEL4? If not, we need to document the >> point at which it becomes unnecessary. > > * Wed Feb 1 2006 Christopher Aillon 2.13.5-2 > - Add patch from Mandriva to reload GConf2 every time a schema is > added or removed (solves bug 173869) > Actually, it wasn't fixed until this release:: * Mon Nov 6 2006 Ray Strode - 2.14.0-2.fc5 - - remove path name from hacky killall workaround, so that the work around works more reliably (bug 173869, comment 14) Still fixed in FC5 and RHEL5, though, so I'll update the documentation to reflect the fact that EPEL4 is the only thing we're building for that's still affected. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG9LiDX6yAic2E7kgRAujHAJ4sgCUFohKaughwcNDYfOUchHAE4gCeMxjN byHwnTziPcqRcWgr21bodHw= =R1rW -----END PGP SIGNATURE----- From ville.skytta at iki.fi Sat Sep 22 07:19:19 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 22 Sep 2007 10:19:19 +0300 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: <1190435027.5089.5.camel@localhost.localdomain> References: <46F206D0.9060109@leemhuis.info> <1190435027.5089.5.camel@localhost.localdomain> Message-ID: <200709221019.19808.ville.skytta@iki.fi> On Saturday 22 September 2007, Matthias Clasen wrote: > + g_spawn_command_line_sync ("/usr/bin/killall -q -TERM " > GCONF_SERVERDIR "/" GCONFD, NULL, NULL, NULL, NULL); Hm, ScriptletSnippets advices to use -HUP; is -TERM instead of it intentional? From mszpak at wp.pl Sat Sep 22 18:01:58 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Sat, 22 Sep 2007 20:01:58 +0200 Subject: [Fedora-packaging] rpmdevtools required for rebuilding packages on F7 Message-ID: Hi, Recently my friend (which isn't a Fedora packager) was rebuilding my package on F7 and he got an error. It seems that there is check-rpaths used: + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot /var/tmp/rpm-tmp.39128: line 43: /usr/lib/rpm/check-rpaths: No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.39128 (%install) There is no that call in FC5 and it was probably introduced in F7. check-rpaths is provided by rpmdevtools which isn't on "the minimum build environment" list: http://fedoraproject.org/wiki/Packaging/Guidelines#head-4cadce5e79d38a63cad3941de1dadc9d25d67d30-2 (maybe because it was in Extras prior to F7) So the question, shouldn't it be added to mentioned list? Regards Marcin From ville.skytta at iki.fi Sat Sep 22 20:42:13 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-2?q?Skytt=E4?=) Date: Sat, 22 Sep 2007 23:42:13 +0300 Subject: [Fedora-packaging] rpmdevtools required for rebuilding packages on F7 In-Reply-To: References: Message-ID: <200709222342.13422.ville.skytta@iki.fi> On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: > > + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot > /var/tmp/rpm-tmp.39128: line 43: /usr/lib/rpm/check-rpaths: No such file > or directory > error: Bad exit status from /var/tmp/rpm-tmp.39128 (%install) > > There is no that call in FC5 and it was probably introduced in F7. > check-rpaths is provided by rpmdevtools which isn't on "the minimum > build environment" list: check-rpaths is not invoked by anything without explicitly being told. Check your ~/.rpmmacros . Additionally, update your rpm-build package, these scripts have moved to it from rpmdevtools in recent distro versions/updates: $ rpm -qf /usr/lib/rpm/check-rpaths rpm-build-4.4.2.1-1.fc7.x86_64 From mszpak at wp.pl Sat Sep 22 21:37:29 2007 From: mszpak at wp.pl (=?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?=) Date: Sat, 22 Sep 2007 23:37:29 +0200 Subject: [Fedora-packaging] Re: rpmdevtools required for rebuilding packages on F7 In-Reply-To: <200709222342.13422.ville.skytta@iki.fi> References: <200709222342.13422.ville.skytta@iki.fi> Message-ID: Ville Skytt? wrote: > On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: >> + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot >> /var/tmp/rpm-tmp.39128: line 43: /usr/lib/rpm/check-rpaths: No such file >> or directory >> error: Bad exit status from /var/tmp/rpm-tmp.39128 (%install) >> >> There is no that call in FC5 and it was probably introduced in F7. >> check-rpaths is provided by rpmdevtools which isn't on "the minimum >> build environment" list: > > check-rpaths is not invoked by anything without explicitly being told. Check > your ~/.rpmmacros . Additionally, update your rpm-build package, these It was called on vanilla F7 with rpmdevtools installed (under vmware). So probably is (was) called there by default. > scripts have moved to it from rpmdevtools in recent distro versions/updates: > > $ rpm -qf /usr/lib/rpm/check-rpaths > rpm-build-4.4.2.1-1.fc7.x86_64 That system was without updates, so it's possible. Movement it to rpm-build should help. Marcin From pmatilai at laiskiainen.org Sun Sep 23 08:16:57 2007 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sun, 23 Sep 2007 11:16:57 +0300 (EEST) Subject: [Fedora-packaging] Re: rpmdevtools required for rebuilding packages on F7 In-Reply-To: References: <200709222342.13422.ville.skytta@iki.fi> Message-ID: On Sat, 22 Sep 2007, [ISO-8859-2] Marcin Zaj?czkowski wrote: > Ville Skytt? wrote: >> On Saturday 22 September 2007, Marcin Zaj?czkowski wrote: >>> + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot >>> /var/tmp/rpm-tmp.39128: line 43: /usr/lib/rpm/check-rpaths: No such file >>> or directory >>> error: Bad exit status from /var/tmp/rpm-tmp.39128 (%install) >>> >>> There is no that call in FC5 and it was probably introduced in F7. >>> check-rpaths is provided by rpmdevtools which isn't on "the minimum >>> build environment" list: >> >> check-rpaths is not invoked by anything without explicitly being told. Check >> your ~/.rpmmacros . Additionally, update your rpm-build package, these > > It was called on vanilla F7 with rpmdevtools installed (under vmware). > So probably is (was) called there by default. rpmdev-setuptree plants check-rpath into ~/.rpmmacros, rpm does not use it by default. - Panu - From ville.skytta at iki.fi Sun Sep 23 19:06:44 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 23 Sep 2007 22:06:44 +0300 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: <46F45561.7070309@gmail.com> References: <20070920221015.GC1456@free.fr> <1190379561.3418.45.camel@localhost.localdomain> <46F45561.7070309@gmail.com> Message-ID: <200709232206.45081.ville.skytta@iki.fi> On Saturday 22 September 2007, Toshio Kuratomi wrote: > +1 to making the prefix tex- +1 From michel.sylvan at gmail.com Mon Sep 24 04:19:43 2007 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 24 Sep 2007 00:19:43 -0400 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: <200709221019.19808.ville.skytta@iki.fi> References: <46F206D0.9060109@leemhuis.info> <1190435027.5089.5.camel@localhost.localdomain> <200709221019.19808.ville.skytta@iki.fi> Message-ID: On 22/09/2007, Ville Skytt? wrote: > On Saturday 22 September 2007, Matthias Clasen wrote: > > > + g_spawn_command_line_sync ("/usr/bin/killall -q -TERM " > > GCONF_SERVERDIR "/" GCONFD, NULL, NULL, NULL, NULL); > > Hm, ScriptletSnippets advices to use -HUP; is -TERM instead of it intentional? > The next time an application uses GConf, the daemon is automatically respawned anyway, right? So there should be no difference between -HUP and -TERM. -- Michel From ville.skytta at iki.fi Mon Sep 24 14:49:15 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 24 Sep 2007 17:49:15 +0300 Subject: [Fedora-packaging] "gconfd-2: no process killed" messages In-Reply-To: References: <46F206D0.9060109@leemhuis.info> <200709221019.19808.ville.skytta@iki.fi> Message-ID: <200709241749.15729.ville.skytta@iki.fi> On Monday 24 September 2007, Michel Salim wrote: > On 22/09/2007, Ville Skytt? wrote: > > On Saturday 22 September 2007, Matthias Clasen wrote: > > > + g_spawn_command_line_sync ("/usr/bin/killall -q -TERM " > > > GCONF_SERVERDIR "/" GCONFD, NULL, NULL, NULL, NULL); > > > > Hm, ScriptletSnippets advices to use -HUP; is -TERM instead of it > > intentional? > > The next time an application uses GConf, the daemon is automatically > respawned anyway, right? I don't know, that's why I asked ;) > So there should be no difference between -HUP and -TERM. Actually, if the behaviour you described is how it works, -TERM may be a better idea than -HUP performance-wise - no need to repeatedly re-read things eg. during a rpm transaction which installs many packages that have something to do with GConf. From tibbs at math.uh.edu Mon Sep 24 15:24:29 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 24 Sep 2007 10:24:29 -0500 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: <46F45561.7070309@gmail.com> References: <20070920221015.GC1456@free.fr> <1190332412.3418.40.camel@localhost.localdomain> <20070921054550.GB16823@free.fr> <1190379561.3418.45.camel@localhost.localdomain> <46F45561.7070309@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> +1 to making the prefix tex- +1 here as well. - J< From jonathan.underwood at gmail.com Mon Sep 24 16:49:28 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 24 Sep 2007 17:49:28 +0100 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: References: <20070920221015.GC1456@free.fr> <1190332412.3418.40.camel@localhost.localdomain> <20070921054550.GB16823@free.fr> <1190379561.3418.45.camel@localhost.localdomain> <46F45561.7070309@gmail.com> Message-ID: <645d17210709240949tf788d7fsb4442f4ff13dba14@mail.gmail.com> On 24 Sep 2007 10:24:29 -0500, Jason L Tibbitts III wrote: > >>>>> "TK" == Toshio Kuratomi writes: > > TK> +1 to making the prefix tex- > > +1 here as well. And me. Can we also consider adding some virtual provides for making add-on packages TeX distribution agnostic. From tcallawa at redhat.com Tue Sep 25 04:13:24 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 25 Sep 2007 00:13:24 -0400 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: <645d17210709240949tf788d7fsb4442f4ff13dba14@mail.gmail.com> References: <20070920221015.GC1456@free.fr> <1190332412.3418.40.camel@localhost.localdomain> <20070921054550.GB16823@free.fr> <1190379561.3418.45.camel@localhost.localdomain> <46F45561.7070309@gmail.com> <645d17210709240949tf788d7fsb4442f4ff13dba14@mail.gmail.com> Message-ID: <1190693604.9424.12.camel@localhost.localdomain> On Mon, 2007-09-24 at 17:49 +0100, Jonathan Underwood wrote: > On 24 Sep 2007 10:24:29 -0500, Jason L Tibbitts III wrote: > > >>>>> "TK" == Toshio Kuratomi writes: > > > > TK> +1 to making the prefix tex- > > > > +1 here as well. > > And me. > > Can we also consider adding some virtual provides for making add-on > packages TeX distribution agnostic. Such as? I don't know TeX from a hole in the ground. If you know better, please draft guidelines for it. As long as they don't seem to have come from a haze of bong smoke, we'll probably sign off on them. Deferring to those who know what they're talking about is our secret to success. :) ~spot From jonathan.underwood at gmail.com Tue Sep 25 15:46:45 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 25 Sep 2007 16:46:45 +0100 Subject: [Fedora-packaging] tex related packages naming In-Reply-To: <1190693604.9424.12.camel@localhost.localdomain> References: <20070920221015.GC1456@free.fr> <1190332412.3418.40.camel@localhost.localdomain> <20070921054550.GB16823@free.fr> <1190379561.3418.45.camel@localhost.localdomain> <46F45561.7070309@gmail.com> <645d17210709240949tf788d7fsb4442f4ff13dba14@mail.gmail.com> <1190693604.9424.12.camel@localhost.localdomain> Message-ID: <645d17210709250846g56e3f4beqa78d52f4a0de2171@mail.gmail.com> On 25/09/2007, Tom spot Callaway wrote: > > On Mon, 2007-09-24 at 17:49 +0100, Jonathan Underwood wrote: > > On 24 Sep 2007 10:24:29 -0500, Jason L Tibbitts III wrote: > > > >>>>> "TK" == Toshio Kuratomi writes: > > > > > > TK> +1 to making the prefix tex- > > > > > > +1 here as well. > > > > And me. > > > > Can we also consider adding some virtual provides for making add-on > > packages TeX distribution agnostic. > > Such as? > > I don't know TeX from a hole in the ground. If you know better, please > draft guidelines for it. As long as they don't seem to have come from a > haze of bong smoke, we'll probably sign off on them. Deferring to those > who know what they're talking about is our secret to success. :) Well, some early proposals are here: http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming Basically, have texlive-bin Provides: TeX such that add-ons can Require: TeX. That way, if someone needs to install a different (La)TeX distribution than TeXLive (others do exist), she can still use the add-on packages (where it makes sense to do so. Depending on how texlive eventualy ends up being packaged, it may be that we want to add more fine grained virtual provides, eg tex, latex, tex-dvips, tex-pdflatex etc etc. This really needs to be done in consideration of the packaging strategy of texlive though. Input from Jindrich would be useful. > > ~spot > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From orion at cora.nwra.com Tue Sep 25 20:11:37 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 25 Sep 2007 14:11:37 -0600 Subject: [Fedora-packaging] Octave package standard Message-ID: <46F96B79.1010902@cora.nwra.com> I'm currently working with octave upstream to get their new package management system in line with Fedora so that we can easily build RPMs with it. I'd like to get a Fedora package standard configured and approved at the same time. I've put a draft on the wiki at: http://fedoraproject.org/wiki/PackagingDrafts/Octave Some further information: - Currently octave uses the /usr/libexec tree to install the .oct files. These are really shared libraries. It does use an arch/api versioned directory, e.g.: /usr/libexec/octave/packages/java-1.2.1/i386-redhat-linux-gnu-api-v26/ Some other package files (PKG_ADD/PKG_DEL) get added there too. - Currently the entire octave forge collection is part of the octave-forge package. I will releasing this for F8, with the understanding that this will be replaced by individual packages later. The octave forge package will have provides like: Provides: octave-gsl = 1.0.1 to try to provide a better upgrade path. We may want to keep the octave-forge as a meta package that pulls in the others. Let me know if this doesn't seem correct. - DISTPKG (%{octave_distpkg}) is a flag that this is being built by a package manager. The contents get inserted into an informational message, but otherwise does not mean much. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From rdieter at math.unl.edu Tue Sep 25 20:19:13 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Sep 2007 15:19:13 -0500 Subject: [Fedora-packaging] Octave package standard In-Reply-To: <46F96B79.1010902@cora.nwra.com> References: <46F96B79.1010902@cora.nwra.com> Message-ID: <46F96D41.8040408@math.unl.edu> Orion Poplawski wrote: > I'm currently working with octave upstream to get their new package > management system in line with Fedora so that we can easily build RPMs > with it. I'd like to get a Fedora package standard configured and > approved at the same time. I've put a draft on the wiki at: > > http://fedoraproject.org/wiki/PackagingDrafts/Octave Looks like a winner to me, bonus points for engaging upstream. -- Rex From jdennis at redhat.com Thu Sep 27 00:29:43 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 26 Sep 2007 20:29:43 -0400 Subject: [Fedora-packaging] error on DistTag wiki page? Message-ID: <46FAF977.30507@redhat.com> I think there might be an error on the following wiki page http://fedoraproject.org/wiki/Packaging/DistTag There are examples there like this: # If on Fedora 8, Requires: foo %{?fc8: Requires: foo} But if fc8 is defined you get an rpm error stating Unknown tag: Requires: foo After much fooling around I think I tracked the problem down to the fact RPM won't tolerate any white space in front of the "Requires:", I finally recalled that RPM will choke if it sees indentation in certain places in the spec file. The net effect of the macro on the wiki was that "Requires:" was indented by 1 space. It seems like it has to be: %{?fc8:Requires: foo} I will update the wiki but I thought I would sanity check my conclusion first. IMHO RPM's parsing is way too fragile, it took me a while before it occurred to me it was the space character causing the error. The error message wasn't very helpful either, did anybody else notice there were two spaces between the "Unknown tag:" and the "Requires" in the error message implying the tag was " Requires" and not "Requires"? John From ivazqueznet at gmail.com Thu Sep 27 04:07:23 2007 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 27 Sep 2007 00:07:23 -0400 Subject: [Fedora-packaging] error on DistTag wiki page? In-Reply-To: <46FAF977.30507@redhat.com> References: <46FAF977.30507@redhat.com> Message-ID: <1190866044.3259.52.camel@ignacio.lan> On Wed, 2007-09-26 at 20:29 -0400, John Dennis wrote: > IMHO RPM's parsing is way too fragile... Old news. > The error message wasn't very helpful either... Also old news. Patches welcome. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- 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 tcallawa at redhat.com Thu Sep 27 15:13:56 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 27 Sep 2007 11:13:56 -0400 Subject: [Fedora-packaging] error on DistTag wiki page? In-Reply-To: <46FAF977.30507@redhat.com> References: <46FAF977.30507@redhat.com> Message-ID: <1190906036.3457.72.camel@localhost.localdomain> On Wed, 2007-09-26 at 20:29 -0400, John Dennis wrote: > It seems like it has to be: > > %{?fc8:Requires: foo} Yep. Fixed in the wiki, thanks. ~spot From a.badger at gmail.com Fri Sep 28 18:13:42 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 28 Sep 2007 11:13:42 -0700 Subject: [Fedora-packaging] Octave package standard In-Reply-To: <46F96B79.1010902@cora.nwra.com> References: <46F96B79.1010902@cora.nwra.com> Message-ID: <46FD4456.1060704@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Orion Poplawski wrote: > I'm currently working with octave upstream to get their new package > management system in line with Fedora so that we can easily build RPMs > with it. I'd like to get a Fedora package standard configured and > approved at the same time. I've put a draft on the wiki at: > > http://fedoraproject.org/wiki/PackagingDrafts/Octave > > Some further information: > > - Currently octave uses the /usr/libexec tree to install the .oct files. > These are really shared libraries. It does use an arch/api versioned > directory, e.g.: > > /usr/libexec/octave/packages/java-1.2.1/i386-redhat-linux-gnu-api-v26/ > > Some other package files (PKG_ADD/PKG_DEL) get added there too. > This is the only part that needs more clarification to me. If the .oct files are really shared libraries it seems that they belong in %{_libdir}. libexec is more useful for binaries that shouldn't be multilib like helper programs that are invoked by other programs on the system and need to match arch with the invoking program for them to work correctly. - -Toshio -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFG/URWX6yAic2E7kgRAgSbAJ9ruRihsv5LqatTncAALwzDPNIoIwCfdgRC EEDwYzDRgWDR4/XRba8QlJc= =luEz -----END PGP SIGNATURE----- From orion at cora.nwra.com Fri Sep 28 18:25:01 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 28 Sep 2007 12:25:01 -0600 Subject: [Fedora-packaging] Octave package standard In-Reply-To: <46FD4456.1060704@gmail.com> References: <46F96B79.1010902@cora.nwra.com> <46FD4456.1060704@gmail.com> Message-ID: <46FD46FD.70201@cora.nwra.com> Toshio Kuratomi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Orion Poplawski wrote: >> >> - Currently octave uses the /usr/libexec tree to install the .oct files. >> These are really shared libraries. It does use an arch/api versioned >> directory, e.g.: >> >> /usr/libexec/octave/packages/java-1.2.1/i386-redhat-linux-gnu-api-v26/ >> >> Some other package files (PKG_ADD/PKG_DEL) get added there too. >> > This is the only part that needs more clarification to me. If the .oct > files are really shared libraries it seems that they belong in > %{_libdir}. libexec is more useful for binaries that shouldn't be > multilib like helper programs that are invoked by other programs on the > system and need to match arch with the invoking program for them to work > correctly. Well, it would be trivial to change /usr/libexec to /usr/lib. Multi-lib is then handled by the arch string farther down. Similar to java in /usr/lib/jvm/java/jre/lib/amd64/. Using %{_libdir} would be harder and I'm not sure for what gain. These are all dlopen libraries only for octave so as long as it knows where to go, that's okay. I also just updated the noarch spec to install from the source tarball directly. The package install script simply unpacks that tarball into the temp directory then. This assumes that nothing in the source needs patching. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com