From rdieter at math.unl.edu Fri Sep 1 14:11:37 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 01 Sep 2006 09:11:37 -0500 Subject: [Fedora-packaging] cmake best practices In-Reply-To: <44F60AA0.3090508@cora.nwra.com> References: <44F60AA0.3090508@cora.nwra.com> Message-ID: <44F83F99.8040308@math.unl.edu> Orion Poplawski wrote: > It appears that more and more projects are moving to cmake, especially > with KDE4 making the jump. Two packages of mine (plplot and kdesvn) are > also making the switch. I also happen to be the current packager for > cmake itself (because I package paraview which uses it), though I expect > it will have to get moved to core relatively soon. > > It seems like it is time to start collecting cmake best practices for > generating Fedora RPMS using cmake, and perhaps even creating a %cmake > rpm macro that is analagous to the %configure macro. Excellent! ... > Now, where to put this in the wiki? I'd suggest http://fedoraproject.org/wiki/PackagingDrafts/cmake for starters. -- Rex From Axel.Thimm at ATrpms.net Sat Sep 2 15:23:11 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Sep 2006 17:23:11 +0200 Subject: [Fedora-packaging] python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <1157209762.6577.65.camel@ender> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902150824.GB28210@neu.nirvana> <1157209762.6577.65.camel@ender> Message-ID: <20060902152311.GC28210@neu.nirvana> Moving the discussion to fedora-packaging as if even memebers of the packaging committee are confused and gove wrong advice, then this is something that should be discussed and placed into the packaging guidelines. On Sat, Sep 02, 2006 at 11:09:22AM -0400, Jesse Keating wrote: > On Sat, 2006-09-02 at 17:08 +0200, Axel Thimm wrote: > > On Sat, Sep 02, 2006 at 10:48:11AM -0400, Jesse Keating wrote: > > > Due to the way that python works, if any part of a python's > > > module is arch specific (sitearch), the entire thing has to go > > > into sitearch. Python will not import part from sitearch and > > > part from sitelib. So it'd all have to go in sitearch. > > > > That's wrong. > > Oh? Care to expand upon this? > > If you have a module, importable module that is, has an __init.py__ and > all that, if you shove part of it in sitearch and part of it in sitelib, > it won't work. Is this statement wrong? If so, please do explain. You mean just the way python-elementtree (and thus yum) works exactly that way since FC3? Yes, that statement is wrong, just log onto a multilib system and check ownership of parts of sitelib. For example on FC5/x86_64: # rpm -qf --qf '%{n}-%{v}-%{r}.%{arch}.rpm\n' /usr/lib/python2.4/site-packages/* | uniq | grep x86_64 aqbanking-1.8.1beta-3.1.x86_64.rpm audit-libs-python-1.1.5-1.x86_64.rpm avahi-tools-0.6.10-1.FC5.x86_64.rpm python-elementtree-1.2.6-4.2.1.x86_64.rpm wireshark-0.99.2-fc5.2.x86_64.rpm -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Sep 2 15:37:54 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 02 Sep 2006 11:37:54 -0400 Subject: [Fedora-packaging] python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <20060902152311.GC28210@neu.nirvana> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902150824.GB28210@neu.nirvana> <1157209762.6577.65.camel@ender> <20060902152311.GC28210@neu.nirvana> Message-ID: <1157211474.6577.74.camel@ender> On Sat, 2006-09-02 at 17:23 +0200, Axel Thimm wrote: > You mean just the way python-elementtree (and thus yum) works exactly > that way since FC3? > > Yes, that statement is wrong, just log onto a multilib system and > check ownership of parts of sitelib. For example on FC5/x86_64: I think we're confusing the point. If the binary blob is part of the python module that won't work. Lets look at your examples: > # rpm -qf --qf '%{n}-%{v}-%{r}.%{arch}.rpm > \n' /usr/lib/python2.4/site-packages/* | uniq | grep x86_64 > aqbanking-1.8.1beta-3.1.x86_64.rpm Only arch specific stuff is in %{_libdir}/aqbanking/ %{_libdir}/gwenhywfar/ and %{_libdir} itself. There are no python modules that span both python sitearch and sitelib. > audit-libs-python-1.1.5-1.x86_64.rpm This one is strange, has /usr/lib/python2.4/site-packages/audit.py AND /usr/lib64/python2.4/site-packages/_audit.so, not exactly sure whats going on there... > avahi-tools-0.6.10-1.FC5.x86_64.rpm Only has python content in /usr/lib/python2.4/site-packages/avahi, no /usr/lib64 python content. > python-elementtree-1.2.6-4.2.1.x86_64.rpm Has two different modules. /usr/lib/python2.4/site-packages/elementtree/ being the 'elementtree' module and /usr/lib64/python2.4/site-packages/cElementTree.so being the 'cElementTree' module. Again no mixed locations for the same module. > wireshark-0.99.2-fc5.2.x86_64.rpm Once again, the only python content is in /usr/lib/python2.4/site-packages/, no python content in /usr/lib64. So I fail to see how these serve as any kind of example. -- Jesse Keating Release Engineer: Fedora -------------- 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 Axel.Thimm at ATrpms.net Sat Sep 2 15:47:30 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Sep 2006 17:47:30 +0200 Subject: [Fedora-packaging] Re: python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <1157211474.6577.74.camel@ender> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902150824.GB28210@neu.nirvana> <1157209762.6577.65.camel@ender> <20060902152311.GC28210@neu.nirvana> <1157211474.6577.74.camel@ender> Message-ID: <20060902154730.GE28210@neu.nirvana> Stripped off quote from Jesse Keating: > Due to the way that python works, if any part of a python's module is > arch specific (sitearch), the entire thing has to go into sitearch. On Sat, Sep 02, 2006 at 11:37:54AM -0400, Jesse Keating wrote: > On Sat, 2006-09-02 at 17:23 +0200, Axel Thimm wrote: > > You mean just the way python-elementtree (and thus yum) works exactly > > that way since FC3? > > > > Yes, that statement is wrong, just log onto a multilib system and > > check ownership of parts of sitelib. For example on FC5/x86_64: > > [ examples of packages having parts in both siteliba and sitearch ] > [ Jesse trying to justify why these packages do so ] > So I fail to see how these serve as any kind of example. Just check your statement again. You outruled coexistence of python modules in both lib and lib64 and there are real-life counterexamples to that. What's more to not see??? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Sep 2 15:52:27 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 02 Sep 2006 11:52:27 -0400 Subject: [Fedora-packaging] Re: python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <20060902154730.GE28210@neu.nirvana> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902150824.GB28210@neu.nirvana> <1157209762.6577.65.camel@ender> <20060902152311.GC28210@neu.nirvana> <1157211474.6577.74.camel@ender> <20060902154730.GE28210@neu.nirvana> Message-ID: <1157212347.6577.79.camel@ender> On Sat, 2006-09-02 at 17:47 +0200, Axel Thimm wrote: > > Just check your statement again. You outruled coexistence of python > modules in both lib and lib64 and there are real-life counterexamples > to that. What's more to not see??? Again I think we're talking past each other. I'm saying that a single python's module can't _both_ be in /usr/lib and /usr/lib64 at the SAME TIME. You can't have /usr/lib/python2.4/site-packages/yum and /usr/lib64/python2.4/site-packages/yum especially with different contents in each. Is what I'm saying clear now? -- Jesse Keating Release Engineer: Fedora -------------- 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 toshio at tiki-lounge.com Sat Sep 2 15:56:40 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 02 Sep 2006 08:56:40 -0700 Subject: [Fedora-packaging] Re: python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <20060902152311.GC28210@neu.nirvana> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902150824.GB28210@neu.nirvana> <1157209762.6577.65.camel@ender> <20060902152311.GC28210@neu.nirvana> Message-ID: <1157212600.3000.16.camel@localhost> On Sat, 2006-09-02 at 17:23 +0200, Axel Thimm wrote: > On Sat, Sep 02, 2006 at 11:09:22AM -0400, Jesse Keating wrote: > > > On Sat, Sep 02, 2006 at 10:48:11AM -0400, Jesse Keating wrote: > > > > Due to the way that python works, if any part of a python's > > > > module is arch specific (sitearch), the entire thing has to go > > > > into sitearch. Python will not import part from sitearch and > > > > part from sitelib. So it'd all have to go in sitearch. > > [snip] > > > If you have a module, importable module that is, has an __init.py__ and > > all that, if you shove part of it in sitearch and part of it in sitelib, > > it won't work. Is this statement wrong? If so, please do explain. > > You mean just the way python-elementtree (and thus yum) works exactly > that way since FC3? > > Yes, that statement is wrong, just log onto a multilib system and > check ownership of parts of sitelib. For example on FC5/x86_64: > > # rpm -qf --qf '%{n}-%{v}-%{r}.%{arch}.rpm\n' /usr/lib/python2.4/site-packages/* | uniq | grep x86_64 None of your examples violate what Jesse is saying, although they may need some explanation: > aqbanking-1.8.1beta-3.1.x86_64.rpm - The python portion of this exists entirely in sitelib. There's no mixing of sitelib and sitearch. > audit-libs-python-1.1.5-1.x86_64.rpm - There are two separate modules in this one. audit and _audit. They exist at the toplevel: %{sitelib}/audit.py and %{sitearch}/_audit.so. The _audit.so portion is referenced by the audit.py portion but it is not the same. If the modules were structured like this: %{sitelib}/audit/{__init__.py,audit.py} %{sitearch}/audit/{__init.py,_audit.so} then the modules would conflict and current python will find only one of them. [1]_ > avahi-tools-0.6.10-1.FC5.x86_64.rpm - Exists entirely in sitelib. > python-elementtree-1.2.6-4.2.1.x86_64.rpm - Two separate modules: elementree in sitelib and cElementTree in sitearch. Same as audit-libs-python. > wireshark-0.99.2-fc5.2.x86_64.rpm - Exists entirely in sitelib. [1]_: Python-dev thread explaining this: http://mail.python.org/pipermail/python-dev/2006-March/062462.html -Toshio -------------- 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 Axel.Thimm at ATrpms.net Sat Sep 2 16:03:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Sep 2006 18:03:05 +0200 Subject: [Fedora-packaging] Should packages really own their config files??? Message-ID: <20060902160305.GF28210@neu.nirvana> Of course they should (IMO), the subject is just for catching your attention. But prominent rpm persona think otherwise - Jeff Johnson considers rpm owning its own /etc/rpm/config file wrong and even questions that there exists a convention of packages owning their config files. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204606 Isn't this handled in some guidelines? If not shouldn't it? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Sep 2 16:04:53 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Sep 2006 18:04:53 +0200 Subject: [Fedora-packaging] Re: python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <1157212347.6577.79.camel@ender> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902150824.GB28210@neu.nirvana> <1157209762.6577.65.camel@ender> <20060902152311.GC28210@neu.nirvana> <1157211474.6577.74.camel@ender> <20060902154730.GE28210@neu.nirvana> <1157212347.6577.79.camel@ender> Message-ID: <20060902160453.GG28210@neu.nirvana> On Sat, Sep 02, 2006 at 11:52:27AM -0400, Jesse Keating wrote: > On Sat, 2006-09-02 at 17:47 +0200, Axel Thimm wrote: > > > > Just check your statement again. You outruled coexistence of python > > modules in both lib and lib64 and there are real-life counterexamples > > to that. What's more to not see??? > > Again I think we're talking past each other. I'm saying that a single > python's module can't _both_ be in /usr/lib and /usr/lib64 at the SAME > TIME. You can't have > > /usr/lib/python2.4/site-packages/yum and > /usr/lib64/python2.4/site-packages/yum > > especially with different contents in each. Is what I'm saying clear > now? I agree with the above, but that was not what you were saying. I won't bother copying your quote back again, you seem to have a reason why you're trimming it ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Sep 2 16:05:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 02 Sep 2006 12:05:51 -0400 Subject: [Fedora-packaging] Should packages really own their config files??? In-Reply-To: <20060902160305.GF28210@neu.nirvana> References: <20060902160305.GF28210@neu.nirvana> Message-ID: <1157213151.6577.81.camel@ender> On Sat, 2006-09-02 at 18:03 +0200, Axel Thimm wrote: > Isn't this handled in some guidelines? If not shouldn't it? I thought we had a rule about creating files in %post or whatnot and not owning them. I could be wrong, but I check for that when I review packages. IMHO any file a package creates on the file system at install time should be owned or ghosted by that package. -- Jesse Keating Release Engineer: Fedora -------------- 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 Axel.Thimm at ATrpms.net Sat Sep 2 16:11:56 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Sep 2006 18:11:56 +0200 Subject: [Fedora-packaging] python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <1157208491.6577.63.camel@ender> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> Message-ID: <20060902161156.GH28210@neu.nirvana> OK, here is the original quoting. A user has both arch specific and non-arch specific parts of a package and needs to decide which parts to place under sitelib and which under sitearch. Jesse's (wrong) answer is that if one needs to get into sitearch it pulls the rest into there, too. It's not about files with the same name under sitearch and sitelib as Jesse later explained, it's about a package like python-elementtree and friends that has some parts that are arch specific and some parts that are not. And there is no need to move everything to sitearch contrary to Jesse's statement. Everything clear as mud? Removing too much in quoting generates this kind of confusion. On Sat, Sep 02, 2006 at 10:48:11AM -0400, Jesse Keating wrote: > On Sat, 2006-09-02 at 16:40 +0200, Sander Hoentjen wrote: > > On Sat, 2006-09-02 at 16:34 +0200, Sander Hoentjen wrote: > > > I am working on packaging cohoba, this is a python gui client/mission > > > control for telepathy. It has one small .c file, so I have a few > > > questions: > > > - because of the .c file the package has to by arch-specific i guess. Is > > > there a strong preference to package as noarch? (the c part is used for > > > changing the name for killall, so to put it as noarch i can just leave > > > that part out (not being able to killall cohoba), or add a dependency on > > > python-ctypes and add a small patch to cohoba to use ctypes to do it > > > instead) > > If it can use all pure python, that would be best for the upstream > project. Why reinvent the wheel? > > > i didn't want to send yet, so i'll continue: > > - should i just not care about arch vs noarch and package as arch > > specific, then where must i place the modules, all in python_sitelib and > > only osutils (the c one) in python_sitearch? > > > > thanks for any pointers > > > > Due to the way that python works, if any part of a python's module is > arch specific (sitearch), the entire thing has to go into sitearch. > Python will not import part from sitearch and part from sitelib. So > it'd all have to go in sitearch. > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Sep 2 16:13:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 02 Sep 2006 12:13:41 -0400 Subject: [Fedora-packaging] Re: python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <20060902160453.GG28210@neu.nirvana> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902150824.GB28210@neu.nirvana> <1157209762.6577.65.camel@ender> <20060902152311.GC28210@neu.nirvana> <1157211474.6577.74.camel@ender> <20060902154730.GE28210@neu.nirvana> <1157212347.6577.79.camel@ender> <20060902160453.GG28210@neu.nirvana> Message-ID: <1157213621.6577.87.camel@ender> On Sat, 2006-09-02 at 18:04 +0200, Axel Thimm wrote: > > I agree with the above, but that was not what you were saying. I won't > bother copying your quote back again, you seem to have a reason why > you're trimming it ;) Please. Tell me what is wrong with: > Due to the way that python works, if any part of a python's module is > arch specific (sitearch), the entire thing has to go into sitearch. > Python will not import part from sitearch and part from sitelib. So > it'd all have to go in sitearch. Maybe my English isn't clear enough to you? "any part of a python's module", so we're talking about a single module here right? "is arch specific", pretty clear. "the entire thing", thing being the module. "has to go into sitearch", correct, has to go into the arch specific dir. Be that /usr/lib in i386 or /usr/lib64 on x86_64. Please, tell me where I'm failing English here, as it is my native language and I'd really like to know. -- Jesse Keating Release Engineer: Fedora -------------- 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 Axel.Thimm at ATrpms.net Sat Sep 2 16:14:57 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Sep 2006 18:14:57 +0200 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <1157213151.6577.81.camel@ender> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> Message-ID: <20060902161457.GI28210@neu.nirvana> On Sat, Sep 02, 2006 at 12:05:51PM -0400, Jesse Keating wrote: > On Sat, 2006-09-02 at 18:03 +0200, Axel Thimm wrote: > > Isn't this handled in some guidelines? If not shouldn't it? > > I thought we had a rule about creating files in %post or whatnot and not > owning them. I could be wrong, but I check for that when I review > packages. IMHO any file a package creates on the file system at install > time should be owned or ghosted by that package. The file is not created by %post. Currently it is created by anaconda, which is a remnant of old times (a safety measure of making sure rpm behaves multilib). The target would be for anaconda to not have to touch /etc/rpm/config at all leaving it completely to the user's discretion. But still that file is unowned. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Sep 2 16:16:08 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 02 Sep 2006 12:16:08 -0400 Subject: [Fedora-packaging] Re: python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <20060902161156.GH28210@neu.nirvana> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902161156.GH28210@neu.nirvana> Message-ID: <1157213768.6577.90.camel@ender> On Sat, 2006-09-02 at 18:11 +0200, Axel Thimm wrote: > OK, here is the original quoting. A user has both arch specific and > non-arch specific parts of a package and needs to decide which parts > to place under sitelib and which under sitearch. > > Jesse's (wrong) answer is that if one needs to get into sitearch it > pulls the rest into there, too. It's not about files with the same > name under sitearch and sitelib as Jesse later explained, it's about a > package like python-elementtree and friends that has some parts that > are arch specific and some parts that are not. And there is no need to > move everything to sitearch contrary to Jesse's statement. > > Everything clear as mud? Removing too much in quoting generates this > kind of confusion. No, too much assuming causes these problems. I said "Due to the way that python works, if any part of a python's module". However you assumed I was speaking about a python module PACKAGE. Now, did I say Package? No, I said module. Pretty hard to remove a quote that didn't exist. Please don't put words in my mouth. -- Jesse Keating Release Engineer: Fedora -------------- 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 Axel.Thimm at ATrpms.net Sat Sep 2 16:18:44 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Sep 2006 18:18:44 +0200 Subject: [Fedora-packaging] Re: python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <1157213621.6577.87.camel@ender> References: <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902150824.GB28210@neu.nirvana> <1157209762.6577.65.camel@ender> <20060902152311.GC28210@neu.nirvana> <1157211474.6577.74.camel@ender> <20060902154730.GE28210@neu.nirvana> <1157212347.6577.79.camel@ender> <20060902160453.GG28210@neu.nirvana> <1157213621.6577.87.camel@ender> Message-ID: <20060902161844.GJ28210@neu.nirvana> On Sat, Sep 02, 2006 at 12:13:41PM -0400, Jesse Keating wrote: > On Sat, 2006-09-02 at 18:04 +0200, Axel Thimm wrote: > > > > I agree with the above, but that was not what you were saying. I won't > > bother copying your quote back again, you seem to have a reason why > > you're trimming it ;) > > Please. Tell me what is wrong with: > > > Due to the way that python works, if any part of a python's module is > > arch specific (sitearch), the entire thing has to go into sitearch. > > Python will not import part from sitearch and part from sitelib. So > > it'd all have to go in sitearch. > > Maybe my English isn't clear enough to you? "any part of a python's > module", so we're talking about a single module here right? "is arch > specific", pretty clear. "the entire thing", thing being the module. > "has to go into sitearch", correct, has to go into the arch specific > dir. Be that /usr/lib in i386 or /usr/lib64 on x86_64. Please, tell me > where I'm failing English here, as it is my native language and I'd > really like to know. Add the OP's quote that is missing above and you'll see what you were meaning with "part of a python's module". I replied to the original post of yours, where all the context is present and I think it's quite clear. E.g. your answer only makes sense if the packager was implying to tear foo.py apart into an arch-dependent and arch-independent part, which is certainly not what he wanted to do. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at j2solutions.net Sat Sep 2 16:20:44 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 02 Sep 2006 12:20:44 -0400 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <20060902161457.GI28210@neu.nirvana> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <20060902161457.GI28210@neu.nirvana> Message-ID: <1157214044.6577.94.camel@ender> On Sat, 2006-09-02 at 18:14 +0200, Axel Thimm wrote: > > The file is not created by %post. Currently it is created by anaconda, > which is a remnant of old times (a safety measure of making sure rpm > behaves multilib). > The target would be for anaconda to not have to touch /etc/rpm/config > at all leaving it completely to the user's discretion. But still that > file is unowned. If anaconda creates it, and nothing else owns it, anaconda should become the owner, or it should be packaged up by rpm. If anaconda doesn't touch it, then it shouldn't be packaged at all. It would be like the user created files in /etc/httpd/conf.d/ or any other such thing. /etc isn't rpm's playground alone, there could be many files in there not owned by a package once the system is used for a while. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 Axel.Thimm at ATrpms.net Sat Sep 2 16:23:26 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 2 Sep 2006 18:23:26 +0200 Subject: [Fedora-packaging] Re: python: mixing sitearch and sitelib (was: python noarch vs arch) In-Reply-To: <1157213768.6577.90.camel@ender> References: <1157207689.3150.9.camel@peecee.hoentjen.eu> <1157208047.3150.14.camel@peecee.hoentjen.eu> <1157208491.6577.63.camel@ender> <20060902161156.GH28210@neu.nirvana> <1157213768.6577.90.camel@ender> Message-ID: <20060902162326.GK28210@neu.nirvana> On Sat, Sep 02, 2006 at 12:16:08PM -0400, Jesse Keating wrote: > On Sat, 2006-09-02 at 18:11 +0200, Axel Thimm wrote: > > OK, here is the original quoting. A user has both arch specific and > > non-arch specific parts of a package and needs to decide which parts > > to place under sitelib and which under sitearch. > > > > Jesse's (wrong) answer is that if one needs to get into sitearch it > > pulls the rest into there, too. It's not about files with the same > > name under sitearch and sitelib as Jesse later explained, it's about a > > package like python-elementtree and friends that has some parts that > > are arch specific and some parts that are not. And there is no need to > > move everything to sitearch contrary to Jesse's statement. > > > > Everything clear as mud? Removing too much in quoting generates this > > kind of confusion. > > No, too much assuming causes these problems. I said "Due to the way > that python works, if any part of a python's module". However you > assumed I was speaking about a python module PACKAGE. Now, did I say > Package? No, I said module. Pretty hard to remove a quote that didn't > exist. Please don't put words in my mouth. OK, so in your POV a user asked whether it is OK to place foo.py and bar.so in sitelib and sitearch respectively and you answer that baz.py can't be installed under both sitearch and sitelib. I think it's better to admit the original error instead. :) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Sat Sep 2 17:14:49 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 02 Sep 2006 12:14:49 -0500 Subject: [Fedora-packaging] Should packages really own their config files??? In-Reply-To: <1157213151.6577.81.camel@ender> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> Message-ID: <44F9BC09.6060503@math.unl.edu> On Sat, 2 Sep 2006, Jesse Keating wrote: > On Sat, 2006-09-02 at 18:03 +0200, Axel Thimm wrote: >> Isn't this handled in some guidelines? If not shouldn't it? > > I thought we had a rule about creating files in %post or whatnot and not > owning them. I could be wrong, but I check for that when I review > packages. IMHO any file a package creates on the file system at install > time should be owned or ghosted by that package. I argued for such a rule, but others pointed out examples where this is not always/generally a good idea, so the proposal did not have the support to pass. -- Rex From tcallawa at redhat.com Mon Sep 4 01:45:06 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 03 Sep 2006 20:45:06 -0500 Subject: [Fedora-packaging] Should packages really own their config files??? In-Reply-To: <44F9BC09.6060503@math.unl.edu> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> Message-ID: <1157334306.29259.22.camel@dhcp-32-122.ord.redhat.com> On Sat, 2006-09-02 at 12:14 -0500, Rex Dieter wrote: > On Sat, 2 Sep 2006, Jesse Keating wrote: > > > On Sat, 2006-09-02 at 18:03 +0200, Axel Thimm wrote: > >> Isn't this handled in some guidelines? If not shouldn't it? > > > > I thought we had a rule about creating files in %post or whatnot and not > > owning them. I could be wrong, but I check for that when I review > > packages. IMHO any file a package creates on the file system at install > > time should be owned or ghosted by that package. > > I argued for such a rule, but others pointed out examples where this is > not always/generally a good idea, so the proposal did not have the > support to pass. I'd be interested in seeing examples of cases where creating files in %post that are not owned by %files would be wanted. I can't think of any. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From rc040203 at freenet.de Mon Sep 4 09:28:40 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 04 Sep 2006 11:28:40 +0200 Subject: [Fedora-packaging] New meeting time In-Reply-To: <20060831170107.GH28961@neu.nirvana> References: <20060831170107.GH28961@neu.nirvana> Message-ID: <1157362121.4488.7.camel@mccallum.corsepiu.local> On Thu, 2006-08-31 at 19:01 +0200, Axel Thimm wrote: > Hi, > > all 7 participants of today's IRC session would agree to Tue, 17:00 > UTC + DST fixes. > > http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime > > It's two days before fesco which will make some easier information > passing and evaluation. > > The remaining three are Ralf, Jose and David. Is it OK with you? Well, sorry, unfortunately, to me, this is a regression. As I wrote before, this time slot is 19:00-20:00 local time (CEST) and overlaps with dinner-time. I.e. for it is very likely for me not being able to attend/having to quit early/being late on meetings. Ralf From jkeating at redhat.com Mon Sep 4 12:42:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 Sep 2006 08:42:56 -0400 Subject: [Fedora-packaging] New meeting time In-Reply-To: <1157362121.4488.7.camel@mccallum.corsepiu.local> References: <20060831170107.GH28961@neu.nirvana> <1157362121.4488.7.camel@mccallum.corsepiu.local> Message-ID: <1157373776.2047.0.camel@ender> On Mon, 2006-09-04 at 11:28 +0200, Ralf Corsepius wrote: > > As I wrote before, this time slot is 19:00-20:00 local time (CEST) and > overlaps with dinner-time. I.e. for it is very likely for me not being > able to attend/having to quit early/being late on meetings. Whereas the current meeting time is lunch time for the East coast of the United States and has been the cause of me not making some meetings or leaving early. -- Jesse Keating Release Engineer: Fedora -------------- 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 jkeating at redhat.com Mon Sep 4 13:28:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 Sep 2006 09:28:51 -0400 Subject: [Fedora-packaging] [Fwd: devel packages with only one .pc file] Message-ID: <1157376531.2047.5.camel@ender> Forwarding this here too. -------- Forwarded Message -------- From: Alexander Larsson Reply-To: List for Fedora Package Maintainers To: List for Fedora Package Maintainers Subject: devel packages with only one .pc file Date: Mon, 04 Sep 2006 15:11:26 +0200 I've recently got several bugs against package involving basically splitting out only one pkg-config file into a -devel package, because the packaging guidelines says so. I've done this for a couple of packages, but its starting to get very ridicolous. The one-file -devel package is totally useless, all it leads to is: * Existance of -devel package means we bloat the 64bit distro with the 32bit version of the main package too. * Developers, script or packages fail because they want to use the .pc file but the -devel package is not installed. * The package metadata (like changelog) stored twice in the rpm database. I can't really think of any advantages. What exactly is the reasoning behind this rule? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an ungodly neurotic stage actor on a search for his missing sister. She's a time-travelling foul-mouthed femme fatale trying to make a difference in a man's world. They fight crime! -- Fedora-maintainers mailing list Fedora-maintainers at redhat.com https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Jesse Keating Release Engineer: Fedora -------------- 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 rdieter at math.unl.edu Mon Sep 4 13:53:46 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 04 Sep 2006 08:53:46 -0500 Subject: [Fedora-packaging] [Fwd: devel packages with only one .pc file] In-Reply-To: <1157376531.2047.5.camel@ender> References: <1157376531.2047.5.camel@ender> Message-ID: <44FC2FEA.3060602@math.unl.edu> Jesse Keating wrote: > Forwarding this here too. > > -------- Forwarded Message -------- > From: Alexander Larsson > Reply-To: List for Fedora Package Maintainers > > To: List for Fedora Package Maintainers > Subject: devel packages with only one .pc file > Date: Mon, 04 Sep 2006 15:11:26 +0200 > > I've recently got several bugs against package involving basically > splitting out only one pkg-config file into a -devel package, because > the packaging guidelines says so. I've done this for a couple of > packages, but its starting to get very ridicolous. > > The one-file -devel package is totally useless I would tend to agree, a single .pc file -devel pkg is a bit silly. Perhaps the existing rule: - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. probably ought to be amended. -- Rex From jorton at redhat.com Mon Sep 4 13:40:16 2006 From: jorton at redhat.com (Joe Orton) Date: Mon, 4 Sep 2006 14:40:16 +0100 Subject: [Fedora-packaging] Should packages really own their config files??? In-Reply-To: <1157334306.29259.22.camel@dhcp-32-122.ord.redhat.com> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> <1157334306.29259.22.camel@dhcp-32-122.ord.redhat.com> Message-ID: <20060904134016.GA2774@redhat.com> On Sun, Sep 03, 2006 at 08:45:06PM -0500, Tom 'spot' Callaway wrote: > I'd be interested in seeing examples of cases where creating files in > %post that are not owned by %files would be wanted. I can't think of > any. With httpd we auto-generate a unique SSL certificate in %post (/etc/pki/tls/localhost.crt et al; some other packages are similar IIRC). I don't think it would be correct to have those generated files %files-owned by the package in any way. joe From jkeating at redhat.com Mon Sep 4 13:44:56 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 Sep 2006 09:44:56 -0400 Subject: [Fedora-packaging] Should packages really own their config files??? In-Reply-To: <20060904134016.GA2774@redhat.com> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> <1157334306.29259.22.camel@dhcp-32-122.ord.redhat.com> <20060904134016.GA2774@redhat.com> Message-ID: <1157377496.2047.7.camel@ender> On Mon, 2006-09-04 at 14:40 +0100, Joe Orton wrote: > With httpd we auto-generate a unique SSL certificate in %post > (/etc/pki/tls/localhost.crt et al; some other packages are similar > IIRC). I don't think it would be correct to have those generated > files > %files-owned by the package in any way. Shouldn't this be done the first time the service is started? The same install could be cloned many times over (xen) and your unique identifier will be invalid. This is why ssh generates its keys the first time the service is started. -- Jesse Keating Release Engineer: Fedora -------------- 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 Axel.Thimm at ATrpms.net Mon Sep 4 13:47:43 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Sep 2006 15:47:43 +0200 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <20060904134016.GA2774@redhat.com> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> <1157334306.29259.22.camel@dhcp-32-122.ord.redhat.com> <20060904134016.GA2774@redhat.com> Message-ID: <20060904134743.GC12388@neu.nirvana> On Mon, Sep 04, 2006 at 02:40:16PM +0100, Joe Orton wrote: > On Sun, Sep 03, 2006 at 08:45:06PM -0500, Tom 'spot' Callaway wrote: > > I'd be interested in seeing examples of cases where creating files in > > %post that are not owned by %files would be wanted. I can't think of > > any. > > With httpd we auto-generate a unique SSL certificate in %post > (/etc/pki/tls/localhost.crt et al; some other packages are similar > IIRC). I don't think it would be correct to have those generated files > %files-owned by the package in any way. I wouldn't consider certificates config files anyway. although one should think about ownership over them, too. What's wrong with %ghost %config(noreplace) them? Upgrades won't touch them. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jorton at redhat.com Mon Sep 4 13:55:25 2006 From: jorton at redhat.com (Joe Orton) Date: Mon, 4 Sep 2006 14:55:25 +0100 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <20060904134743.GC12388@neu.nirvana> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> <1157334306.29259.22.camel@dhcp-32-122.ord.redhat.com> <20060904134016.GA2774@redhat.com> <20060904134743.GC12388@neu.nirvana> Message-ID: <20060904135525.GB2774@redhat.com> On Mon, Sep 04, 2006 at 03:47:43PM +0200, Axel Thimm wrote: > On Mon, Sep 04, 2006 at 02:40:16PM +0100, Joe Orton wrote: > > On Sun, Sep 03, 2006 at 08:45:06PM -0500, Tom 'spot' Callaway wrote: > > > I'd be interested in seeing examples of cases where creating files in > > > %post that are not owned by %files would be wanted. I can't think of > > > any. > > > > With httpd we auto-generate a unique SSL certificate in %post > > (/etc/pki/tls/localhost.crt et al; some other packages are similar > > IIRC). I don't think it would be correct to have those generated files > > %files-owned by the package in any way. > > I wouldn't consider certificates config files anyway. although one > should think about ownership over them, too. What's wrong with > %ghost %config(noreplace) them? Upgrades won't touch them. I don't know how a ghosted noreplace file would be handled actually. Would an --erase always remove such a file? That is not really desirable. Jesse: yes, generating the files at first invocation would be a good idea. But I don't think it makes a difference *when* the file is generated w.r.t. the question of whether the package should own it though. joe From Axel.Thimm at ATrpms.net Mon Sep 4 14:00:35 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Sep 2006 16:00:35 +0200 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <44F9BC09.6060503@math.unl.edu> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> Message-ID: <20060904140035.GD12388@neu.nirvana> On Sat, Sep 02, 2006 at 12:14:49PM -0500, Rex Dieter wrote: > On Sat, 2 Sep 2006, Jesse Keating wrote: > > > On Sat, 2006-09-02 at 18:03 +0200, Axel Thimm wrote: > >> Isn't this handled in some guidelines? If not shouldn't it? > > > > I thought we had a rule about creating files in %post or whatnot and not > > owning them. I could be wrong, but I check for that when I review > > packages. IMHO any file a package creates on the file system at install > > time should be owned or ghosted by that package. > > I argued for such a rule, but others pointed out examples where this is > not always/generally a good idea, so the proposal did not have the > support to pass. Were the examples for certificate/ssh keys only? I don't really meant these with "config files". Are there any arguments against owning config files but certifcates/ssh keys? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Sep 4 14:06:05 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Sep 2006 16:06:05 +0200 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <20060904135525.GB2774@redhat.com> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> <1157334306.29259.22.camel@dhcp-32-122.ord.redhat.com> <20060904134016.GA2774@redhat.com> <20060904134743.GC12388@neu.nirvana> <20060904135525.GB2774@redhat.com> Message-ID: <20060904140605.GE12388@neu.nirvana> On Mon, Sep 04, 2006 at 02:55:25PM +0100, Joe Orton wrote: > On Mon, Sep 04, 2006 at 03:47:43PM +0200, Axel Thimm wrote: > > On Mon, Sep 04, 2006 at 02:40:16PM +0100, Joe Orton wrote: > > > On Sun, Sep 03, 2006 at 08:45:06PM -0500, Tom 'spot' Callaway wrote: > > > > I'd be interested in seeing examples of cases where creating files in > > > > %post that are not owned by %files would be wanted. I can't think of > > > > any. > > > > > > With httpd we auto-generate a unique SSL certificate in %post > > > (/etc/pki/tls/localhost.crt et al; some other packages are similar > > > IIRC). I don't think it would be correct to have those generated files > > > %files-owned by the package in any way. > > > > I wouldn't consider certificates config files anyway. although one > > should think about ownership over them, too. What's wrong with > > %ghost %config(noreplace) them? Upgrades won't touch them. > > I don't know how a ghosted noreplace file would be handled actually. > Would an --erase always remove such a file? That is not really > desirable. I'm not sure, if it does, then don't %ghost it. The drawback of not ghosting would be a phony empty /etc/pki/tls/localhost.crt.rpmnew. But this could be removed in the same %post operation that generates the contents for /etc/pki/tls/localhost.crt. E.g. %install ... touch %{buildroot}%{mycert} ... %post rm -f %{mycert}.rpmnew if ... ... > %{mycert} fi %files ... %config(noreplace) %{mycert} -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Sep 4 14:09:03 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 4 Sep 2006 16:09:03 +0200 Subject: [Fedora-packaging] Re: [Fwd: devel packages with only one .pc file] In-Reply-To: <44FC2FEA.3060602@math.unl.edu> References: <1157376531.2047.5.camel@ender> <44FC2FEA.3060602@math.unl.edu> Message-ID: <20060904140903.GF12388@neu.nirvana> On Mon, Sep 04, 2006 at 08:53:46AM -0500, Rex Dieter wrote: > Jesse Keating wrote: > > Forwarding this here too. > > > > -------- Forwarded Message -------- > > From: Alexander Larsson > > Reply-To: List for Fedora Package Maintainers > > > > To: List for Fedora Package Maintainers > > Subject: devel packages with only one .pc file > > Date: Mon, 04 Sep 2006 15:11:26 +0200 > > > > I've recently got several bugs against package involving basically > > splitting out only one pkg-config file into a -devel package, because > > the packaging guidelines says so. I've done this for a couple of > > packages, but its starting to get very ridicolous. > > > > The one-file -devel package is totally useless > > I would tend to agree, a single .pc file -devel pkg is a bit silly. > Perhaps the existing rule: > > - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. > > probably ought to be amended. What good is a pc file w/o any other development bits? Maybe the package is question has a bogus pc file that ought to be rm'd instead of split off into a subpackage? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Sep 4 14:21:08 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 4 Sep 2006 16:21:08 +0200 Subject: [Fedora-packaging] [Fwd: devel packages with only one .pc file] In-Reply-To: <44FC2FEA.3060602@math.unl.edu> References: <1157376531.2047.5.camel@ender> <44FC2FEA.3060602@math.unl.edu> Message-ID: <20060904162108.3421d207@python2> Rex Dieter wrote : > Jesse Keating wrote: > > Forwarding this here too. > > > > -------- Forwarded Message -------- > > From: Alexander Larsson > > Reply-To: List for Fedora Package Maintainers > > > > To: List for Fedora Package Maintainers > > Subject: devel packages with only one .pc file > > Date: Mon, 04 Sep 2006 15:11:26 +0200 > > > > I've recently got several bugs against package involving basically > > splitting out only one pkg-config file into a -devel package, because > > the packaging guidelines says so. I've done this for a couple of > > packages, but its starting to get very ridicolous. > > > > The one-file -devel package is totally useless > > I would tend to agree, a single .pc file -devel pkg is a bit silly. > Perhaps the existing rule: > > - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. > > probably ought to be amended. Well, if the .pc file has its cflags or libs show that the package requires other libraries (some X libs, or gtk stuff, or...), then it does make sense to split the -devel package out, since it will not just contain one file, but also other -devel package requirements that we definitely don't want to be forcing on all simple users of the runtime bits. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.91 (FC6 Test2) - Linux kernel 2.6.17-1.2611.fc6 Load : 0.49 0.40 0.43 From chris.stone at gmail.com Mon Sep 4 17:59:53 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Mon, 4 Sep 2006 10:59:53 -0700 Subject: [Fedora-packaging] [Fwd: devel packages with only one .pc file] In-Reply-To: <20060904162108.3421d207@python2> References: <1157376531.2047.5.camel@ender> <44FC2FEA.3060602@math.unl.edu> <20060904162108.3421d207@python2> Message-ID: On 9/4/06, Matthias Saou wrote: > Rex Dieter wrote : > > > Jesse Keating wrote: > > > Forwarding this here too. > > > > > > -------- Forwarded Message -------- > > > From: Alexander Larsson > > > Reply-To: List for Fedora Package Maintainers > > > > > > To: List for Fedora Package Maintainers > > > Subject: devel packages with only one .pc file > > > Date: Mon, 04 Sep 2006 15:11:26 +0200 > > > > > > I've recently got several bugs against package involving basically > > > splitting out only one pkg-config file into a -devel package, because > > > the packaging guidelines says so. I've done this for a couple of > > > packages, but its starting to get very ridicolous. > > > > > > The one-file -devel package is totally useless > > > > I would tend to agree, a single .pc file -devel pkg is a bit silly. > > Perhaps the existing rule: > > > > - MUST: Files used by pkgconfig (.pc files) must be in a -devel package. > > > > probably ought to be amended. > > Well, if the .pc file has its cflags or libs show that the package > requires other libraries (some X libs, or gtk stuff, or...), then it > does make sense to split the -devel package out, since it will not just > contain one file, but also other -devel package requirements that we > definitely don't want to be forcing on all simple users of the runtime > bits. > +1 This has been discussed before and it was decided that a .pc file should be in a devel package even if it is the only file in the package for the reason given by Matthias. And I don't see it being worth the effort to try and come up with exceptions to the rule. There is barely any overhead involved in creating a single file devel package (AFAIK). From katzj at redhat.com Mon Sep 4 18:22:49 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Sep 2006 14:22:49 -0400 Subject: [Fedora-packaging] Should packages really own their config files??? In-Reply-To: <1157377496.2047.7.camel@ender> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> <1157334306.29259.22.camel@dhcp-32-122.ord.redhat.com> <20060904134016.GA2774@redhat.com> <1157377496.2047.7.camel@ender> Message-ID: <1157394169.13910.18.camel@aglarond.local> On Mon, 2006-09-04 at 09:44 -0400, Jesse Keating wrote: > On Mon, 2006-09-04 at 14:40 +0100, Joe Orton wrote: > > With httpd we auto-generate a unique SSL certificate in %post > > (/etc/pki/tls/localhost.crt et al; some other packages are similar > > IIRC). I don't think it would be correct to have those generated > > files > > %files-owned by the package in any way. > > Shouldn't this be done the first time the service is started? The same > install could be cloned many times over (xen) and your unique identifier > will be invalid. This is why ssh generates its keys the first time the > service is started. Actually, the reason sshd generates its keys the first time is because it made a significant difference on 31-bit s390 install time with Red Hat Linux 7.1 on zSeries. Jeremy From katzj at redhat.com Mon Sep 4 18:25:21 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 04 Sep 2006 14:25:21 -0400 Subject: [Fedora-packaging] [Fwd: devel packages with only one .pc file] In-Reply-To: References: <1157376531.2047.5.camel@ender> <44FC2FEA.3060602@math.unl.edu> <20060904162108.3421d207@python2> Message-ID: <1157394321.13910.21.camel@aglarond.local> On Mon, 2006-09-04 at 10:59 -0700, Christopher Stone wrote: > And I don't see it being worth the effort to try and come up with > exceptions to the rule. There is barely any overhead involved in > creating a single file devel package (AFAIK). There *are* some overheads, though -- you duplicate the vast majority of the package information in the rpmdb and in metadata (thus, more bits to download for updates, etc). It also means that the package becomes multilib[1] Also, I've now seen pkgconfig files used for things other than development tasks, although I think that might be kind of crack ;-) Jeremy [1] The current mechanism is that we want all devel packages to be available as multilib as that makes it something a computer can do rather than something a human maintains[2]. Which is pretty sensible on the whole. But it starts to show some fuzziness at the edges when we talk about only vaguely arch-specific stuff (mono and java are what come to mind here) [2] A few years of a human maintaining has shown that it doesn't work :-) From jkeating at redhat.com Mon Sep 4 18:44:53 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 Sep 2006 14:44:53 -0400 Subject: [Fedora-packaging] Should packages really own their config files??? In-Reply-To: <1157394169.13910.18.camel@aglarond.local> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> <1157334306.29259.22.camel@dhcp-32-122.ord.redhat.com> <20060904134016.GA2774@redhat.com> <1157377496.2047.7.camel@ender> <1157394169.13910.18.camel@aglarond.local> Message-ID: <1157395493.2047.14.camel@ender> On Mon, 2006-09-04 at 14:22 -0400, Jeremy Katz wrote: > Actually, the reason sshd generates its keys the first time is because > it made a significant difference on 31-bit s390 install time with Red > Hat Linux 7.1 on zSeries. Ah. But a neat side effect is that cloned systems don't get the same ssh keys (: -- Jesse Keating Release Engineer: Fedora -------------- 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 paul at all-the-johnsons.co.uk Mon Sep 4 20:09:36 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 04 Sep 2006 21:09:36 +0100 Subject: [Fedora-packaging] [Fwd: devel packages with only one .pc file] In-Reply-To: <1157376531.2047.5.camel@ender> References: <1157376531.2047.5.camel@ender> Message-ID: <1157400577.6923.11.camel@T7.Linux> Hi, As the person who actually filed the bugs... > The one-file -devel package is totally useless, all it leads to is: > * Existance of -devel package means we bloat the 64bit distro with the > 32bit version of the main package too. Is there actually a reason for doing this? I could never understand it. > * Developers, script or packages fail because they want to use the .pc > file but the -devel package is not installed. And? Just requires adding the devel package - hardly an amazingly difficult act! > I can't really think of any advantages. What exactly is the reasoning > behind this rule? This point was discussed at length when the mono packaging rules were being done. Most (if not all) mono packages ONLY have the .pc file in the devel package - mono-debugger is the exception to that but that is a special case. My personal feeling was (at the time) - bloody stupid idea, but now I can see the point. TTFN Paul -- "Bist Du meine Mutter?" - das leere kind -------------- 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 dlutter at redhat.com Sat Sep 2 07:36:43 2006 From: dlutter at redhat.com (David Lutterkort) Date: Sat, 02 Sep 2006 00:36:43 -0700 Subject: [Fedora-packaging] New meeting time In-Reply-To: <20060831170107.GH28961@neu.nirvana> References: <20060831170107.GH28961@neu.nirvana> Message-ID: <1157182603.30117.23.camel@localhost.localdomain> On Thu, 2006-08-31 at 19:01 +0200, Axel Thimm wrote: > Hi, > > all 7 participants of today's IRC session would agree to Tue, 17:00 > UTC + DST fixes. > > http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime > > It's two days before fesco which will make some easier information > passing and evaluation. > > The remaining three are Ralf, Jose and David. Is it OK with you? Yes, that works for me. David From dlutter at redhat.com Sat Sep 2 07:36:43 2006 From: dlutter at redhat.com (David Lutterkort) Date: Sat, 02 Sep 2006 00:36:43 -0700 Subject: [Fedora-packaging] New meeting time In-Reply-To: <20060831170107.GH28961@neu.nirvana> References: <20060831170107.GH28961@neu.nirvana> Message-ID: <1157182603.30117.23.camel@localhost.localdomain> On Thu, 2006-08-31 at 19:01 +0200, Axel Thimm wrote: > Hi, > > all 7 participants of today's IRC session would agree to Tue, 17:00 > UTC + DST fixes. > > http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime > > It's two days before fesco which will make some easier information > passing and evaluation. > > The remaining three are Ralf, Jose and David. Is it OK with you? Yes, that works for me. David From notting at redhat.com Tue Sep 5 02:41:09 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 4 Sep 2006 22:41:09 -0400 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <1157214044.6577.94.camel@ender> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <20060902161457.GI28210@neu.nirvana> <1157214044.6577.94.camel@ender> Message-ID: <20060905024109.GF20387@nostromo.devel.redhat.com> Jesse Keating (jkeating at j2solutions.net) said: > If anaconda creates it, and nothing else owns it, anaconda should become > the owner, or it should be packaged up by rpm. anaconda is very unlikely to be on the system. Bill From jkeating at redhat.com Tue Sep 5 02:48:15 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 04 Sep 2006 22:48:15 -0400 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <20060905024109.GF20387@nostromo.devel.redhat.com> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <20060902161457.GI28210@neu.nirvana> <1157214044.6577.94.camel@ender> <20060905024109.GF20387@nostromo.devel.redhat.com> Message-ID: <1157424495.2047.21.camel@ender> On Mon, 2006-09-04 at 22:41 -0400, Bill Nottingham wrote: > anaconda is very unlikely to be on the system. Good point. Lets focus on whether or not this file is really needed... -- Jesse Keating Release Engineer: Fedora -------------- 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 toshio at tiki-lounge.com Tue Sep 5 03:13:26 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 04 Sep 2006 20:13:26 -0700 Subject: [Fedora-packaging] New meeting time In-Reply-To: <1157362121.4488.7.camel@mccallum.corsepiu.local> References: <20060831170107.GH28961@neu.nirvana> <1157362121.4488.7.camel@mccallum.corsepiu.local> Message-ID: <1157426007.21368.55.camel@localhost> On Mon, 2006-09-04 at 11:28 +0200, Ralf Corsepius wrote: > On Thu, 2006-08-31 at 19:01 +0200, Axel Thimm wrote: > > Hi, > > > > all 7 participants of today's IRC session would agree to Tue, 17:00 > > UTC + DST fixes. > > > > http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime > > > > It's two days before fesco which will make some easier information > > passing and evaluation. > > > > The remaining three are Ralf, Jose and David. Is it OK with you? > Well, sorry, unfortunately, to me, this is a regression. > > As I wrote before, this time slot is 19:00-20:00 local time (CEST) and > overlaps with dinner-time. I.e. for it is very likely for me not being > able to attend/having to quit early/being late on meetings. Ralf, could you put your name to some times that are good for you? There are several other times that could work for me and I'm sure everyone else could find a few other times as well. But without having a list of some possible times, we won't know if there's any one time that'll work for everyone or not. Thanks, Toshio -------------- 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 toshio at tiki-lounge.com Tue Sep 5 05:59:55 2006 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 04 Sep 2006 22:59:55 -0700 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <20060904140035.GD12388@neu.nirvana> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> <20060904140035.GD12388@neu.nirvana> Message-ID: <1157435995.21368.88.camel@localhost> On Mon, 2006-09-04 at 16:00 +0200, Axel Thimm wrote: > On Sat, Sep 02, 2006 at 12:14:49PM -0500, Rex Dieter wrote: > > I argued for such a rule, but others pointed out examples where this is > > not always/generally a good idea, so the proposal did not have the > > support to pass. > > Were the examples for certificate/ssh keys only? I don't really meant > these with "config files". Are there any arguments against owning > config files but certifcates/ssh keys? I don't recall anything except certificates. The log of that meeting is here: http://www.fedoraproject.org/wiki/Packaging/IRCLog20060727 Relevant timeframe: (09:33:08) - (09:59:24) -Toshio -------------- 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 Axel.Thimm at ATrpms.net Tue Sep 5 07:57:18 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 5 Sep 2006 09:57:18 +0200 Subject: [Fedora-packaging] Re: Should packages really own their config files??? In-Reply-To: <1157435995.21368.88.camel@localhost> References: <20060902160305.GF28210@neu.nirvana> <1157213151.6577.81.camel@ender> <44F9BC09.6060503@math.unl.edu> <20060904140035.GD12388@neu.nirvana> <1157435995.21368.88.camel@localhost> Message-ID: <20060905075718.GA32098@neu.nirvana> On Mon, Sep 04, 2006 at 10:59:55PM -0700, Toshio Kuratomi wrote: > On Mon, 2006-09-04 at 16:00 +0200, Axel Thimm wrote: > > On Sat, Sep 02, 2006 at 12:14:49PM -0500, Rex Dieter wrote: > > > I argued for such a rule, but others pointed out examples where this is > > > not always/generally a good idea, so the proposal did not have the > > > support to pass. > > > > Were the examples for certificate/ssh keys only? I don't really meant > > these with "config files". Are there any arguments against owning > > config files but certifcates/ssh keys? > > I don't recall anything except certificates. The log of that meeting is > here: > http://www.fedoraproject.org/wiki/Packaging/IRCLog20060727 > > Relevant timeframe: (09:33:08) - (09:59:24) Thanks! There isn't much in there which hasn't been said in this thread, I think. It's mostly about not wanting to accidentially remove certificates or other sensitive auto-generated key material and that can be handled fine (see my reply to Joe). And it also didn't fail on passing, it failed on available time in the session - looks like most people were not rejecting the idea of having config files (or other generated files) owned by the package, if it doesn't do harm. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Tue Sep 5 08:18:45 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 05 Sep 2006 10:18:45 +0200 Subject: [Fedora-packaging] New meeting time In-Reply-To: <1157426007.21368.55.camel@localhost> References: <20060831170107.GH28961@neu.nirvana> <1157362121.4488.7.camel@mccallum.corsepiu.local> <1157426007.21368.55.camel@localhost> Message-ID: <1157444326.4654.82.camel@mccallum.corsepiu.local> On Mon, 2006-09-04 at 20:13 -0700, Toshio Kuratomi wrote: > On Mon, 2006-09-04 at 11:28 +0200, Ralf Corsepius wrote: > > On Thu, 2006-08-31 at 19:01 +0200, Axel Thimm wrote: > > > Hi, > > > > > > all 7 participants of today's IRC session would agree to Tue, 17:00 > > > UTC + DST fixes. > > > > > > http://www.fedoraproject.org/wiki/Packaging/NewMeetingTime > > > > > > It's two days before fesco which will make some easier information > > > passing and evaluation. > > > > > > The remaining three are Ralf, Jose and David. Is it OK with you? > > Well, sorry, unfortunately, to me, this is a regression. > > > > As I wrote before, this time slot is 19:00-20:00 local time (CEST) and > > overlaps with dinner-time. I.e. for it is very likely for me not being > > able to attend/having to quit early/being late on meetings. > > Ralf, could you put your name to some times that are good for you? The day doesn't matter much to me, but almost any time-slot out of the 22:00-04:00 UTC (night-time, but I am used to getting up early :)) and the 17:00-19:00 UTC (dinner-time [1]) time slots would be equally fine with me. The old time-slot had not been optimal (European office hours preferred), but it had been an acceptable and reasonable compromise to me which would have worked almost always for me. The new is worse, but not "totally undoable". I am willing to swallow it, but ... I am sure, it won't work for me in many cases. > There are several other times that could work for me and I'm sure > everyone else could find a few other times as well. But without having > a list of some possible times, we won't know if there's any one time > that'll work for everyone or not. Let's hope for that. Ralf [1] Most other Europeans around here don't have a family, I presume? ;) From orion at cora.nwra.com Tue Sep 5 19:54:32 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 05 Sep 2006 13:54:32 -0600 Subject: [Fedora-packaging] cmake best practices In-Reply-To: <44F83F99.8040308@math.unl.edu> References: <44F60AA0.3090508@cora.nwra.com> <44F83F99.8040308@math.unl.edu> Message-ID: <44FDD5F8.6040100@cora.nwra.com> Rex Dieter wrote: > Orion Poplawski wrote: >> Now, where to put this in the wiki? > > I'd suggest > http://fedoraproject.org/wiki/PackagingDrafts/cmake > for starters. Created. -- Orion Poplawski System Administrator 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 Axel.Thimm at ATrpms.net Wed Sep 6 21:42:02 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 6 Sep 2006 23:42:02 +0200 Subject: [Fedora-packaging] IRC session Sep 7th + 14th Message-ID: <20060906214202.GG27467@neu.nirvana> Hi, I have a very tight schedule on these two dates, so I may not be able to attend. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Fri Sep 8 14:07:09 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 08 Sep 2006 09:07:09 -0500 Subject: [Fedora-packaging] pkgconfig(.pc) guildeline update proposal Message-ID: <4501790D.1070309@math.unl.edu> Ville asked for a clarification... here's what I propose: # () explanations may be omitted in final draft. opinions? MUST: Packages containing pkgconfig(.pc) files MUST Requires: pkgconfig (for directory ownership and usability). SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so SHOULD be placed in a -devel pkg. (A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb.) -- Rex From fedora at leemhuis.info Fri Sep 8 15:41:58 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 08 Sep 2006 17:41:58 +0200 Subject: [Fedora-packaging] Rewording of Review Guidelines Message-ID: <45018F46.5070605@leemhuis.info> Hi All! can someone from the PC please reword http://fedoraproject.org/wiki/Packaging/ReviewGuidelines slightly? We had this earlier today here in #fedora-extras: ndim> '"The primary Reviewer can be any current package owner, unless the Contributor is a first timer."; What does that mean? I can only make official reviews after I maintain two packages?' Maybe something like "The primary Reviewer can be any current package owner. Only packages that are from first time contributors need to be reviewed from sponsors." would be better. Cu thl From opensource at till.name Fri Sep 8 15:49:51 2006 From: opensource at till.name (Till Maas) Date: Fri, 08 Sep 2006 17:49:51 +0200 Subject: [Fedora-packaging] Rewording of Review Guidelines In-Reply-To: <45018F46.5070605@leemhuis.info> References: <45018F46.5070605@leemhuis.info> Message-ID: <200609081750.13822.opensource@till.name> On Friday 08 September 2006 17:41, Thorsten Leemhuis wrote: > "The primary Reviewer can be any current package owner. Only packages > that are from first time contributors need to be reviewed from sponsors." I would change the second sentence to (something like): "Only the first package from a new contributor needs to be reviewed from an sponsor" This makes it more clear that it is only about the first package that someone wants to maintain in Extras. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at leemhuis.info Fri Sep 8 16:02:00 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 08 Sep 2006 18:02:00 +0200 Subject: [Fedora-packaging] Rewording of Review Guidelines In-Reply-To: <200609081750.13822.opensource@till.name> References: <45018F46.5070605@leemhuis.info> <200609081750.13822.opensource@till.name> Message-ID: <450193F8.3@leemhuis.info> Till Maas schrieb: > On Friday 08 September 2006 17:41, Thorsten Leemhuis wrote: > >> "The primary Reviewer can be any current package owner. Only packages >> that are from first time contributors need to be reviewed from sponsors." > > I would change the second sentence to (something like): > > "Only the first package from a new contributor needs to be reviewed from an > sponsor" > > This makes it more clear that it is only about the first package that someone > wants to maintain in Extras. That's okay for me. Can somebody simply change that in the wiki? tia! CU thl From jkeating at redhat.com Fri Sep 8 15:59:32 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 8 Sep 2006 11:59:32 -0400 Subject: [Fedora-packaging] Rewording of Review Guidelines In-Reply-To: <200609081750.13822.opensource@till.name> References: <45018F46.5070605@leemhuis.info> <200609081750.13822.opensource@till.name> Message-ID: <200609081159.35811.jkeating@redhat.com> On Friday 08 September 2006 11:49, Till Maas wrote: > "Only the first package from a new contributor needs to be reviewed from an > sponsor" > > This makes it more clear that it is only about the first package that > someone wants to maintain in Extras. Except where a new packager submits 3 packages for review their first time up. I'd go more for: "Only packages from unsponsored contributors need be reviewed by a sponsor." -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Fri Sep 8 16:01:21 2006 From: paul at city-fan.org (Paul Howarth) Date: Fri, 08 Sep 2006 17:01:21 +0100 Subject: [Fedora-packaging] Rewording of Review Guidelines In-Reply-To: <200609081750.13822.opensource@till.name> References: <45018F46.5070605@leemhuis.info> <200609081750.13822.opensource@till.name> Message-ID: <450193D1.8070401@city-fan.org> Till Maas wrote: > On Friday 08 September 2006 17:41, Thorsten Leemhuis wrote: > >> "The primary Reviewer can be any current package owner. Only packages >> that are from first time contributors need to be reviewed from sponsors." > > I would change the second sentence to (something like): > > "Only the first package from a new contributor needs to be reviewed from an > sponsor" > > This makes it more clear that it is only about the first package that someone > wants to maintain in Extras. I think thl's wording is better; first time contributors often have multiple packages up for review, and none of them can be officially reviewed by anyone other than a sponsor until such time as the contributor is sponsored. Perhaps this for the second sentence: "Only packages from contributors that are not yet sponsored need to be reviewed by a sponsor." Paul. From rhbugs at n-dimensional.de Fri Sep 8 16:28:40 2006 From: rhbugs at n-dimensional.de (Hans Ulrich Niedermann) Date: Fri, 08 Sep 2006 18:28:40 +0200 Subject: [Fedora-packaging] Rewording of Review Guidelines In-Reply-To: <45018F46.5070605@leemhuis.info> (Thorsten Leemhuis's message of "Fri, 08 Sep 2006 17:41:58 +0200") References: <45018F46.5070605@leemhuis.info> Message-ID: <86pse61fwn.fsf@n-dimensional.de> Thorsten Leemhuis writes: > can someone from the PC please reword > http://fedoraproject.org/wiki/Packaging/ReviewGuidelines > slightly? We had this earlier today here in #fedora-extras: > > ndim> '"The primary Reviewer can be any current package owner, unless > the Contributor is a first timer."; What does that mean? I can only make > official reviews after I maintain two packages?' That was me, and I now know why I didn't understand it. The ReviewGuidelines page deals with two persons: The "Contributor" and the "Reviewer". The section on the "Reviewer" contains the phrase cited above, referring to the "Contributor" section immediately above it, but I did not make the connection that the "Contributor" mentioned in the "Reviewer" section was the same one explained in the section above. Unfortunately, there is a humongously large screenshot image (1600x1150) between those two sections disrupting the text and layout so much that one cannot see anything of the previous section. Already having been sponsored, I was looking for information how I could do reviews myself, so I quickly skipped the "Contributor" section, got my mind erased by the image, and then stumbled on the "Reviewer" section, having forgotten that the person who has submitted his package for review is called "Contributor" here. As the "Reviewer" also is a contributor to Fedora... I became a little confused. So there are two problems here: 1. "Contributor" is not self explanatory: Both the person who submitted his package for review and the "Reviewer" are contributors to the Fedora Project. 2. The screenshot is too large (much too wide). Fixing 1. may be difficult, because the wording may be referenced from elsewhere. However, then we should at least make the difference between "Contributor" and "contributor" clear, and make the screenshot small enought that it doesn't completely disrupt the text flow. I have created a gimped version of the screenshot which has been reduced to 872x987 from the original 1600x1150: http://es.lauft.net/fedora/sample-review-ndim.png That may still not be enought, but IMHO it is a lot better. > Maybe something like > > "The primary Reviewer can be any current package owner. Only packages > that are from first time contributors need to be reviewed from sponsors." > > would be better. This should be "Contributors" with capital "C". The whole paragraph reads: | A Reviewer is defined as the person who chooses to review a | package. For the sake of clarity, one person takes ownership of the | review. Other people are encouraged to comment on the review as | well, either in the bug or on the mailing list. The primary | Reviewer can be any current package owner, unless the Contributor | is a first timer. I'd suggest something like | A Reviewer is defined as the person who chooses to review a | package. For the sake of clarity, one person takes ownership of the | review. Other people are encouraged to comment on the review as | well, either in the bug or on the mailing list. The primary | Reviewer for the Contributor's first package must be a sponsor; for | the Contributor's further packages any current package owner can be | the primary Reviewer. or something which repeats the structure of the sentence: | A Reviewer is defined as the person who chooses to review a | package. For the sake of clarity, one person takes ownership of the | review. Other people are encouraged to comment on the review as | well, either in the bug or on the mailing list. For the | Contributor's first package, the primary Reviewer must be a | sponsor. For the Contributur's further[1] packages, the primary | Reviewer can be any current package owner. [1] A native speaker of English should choose a better word here. Together with a smaller screenshot, this should create a readable document. :-) I hope this doesn't make things more complicated than they deserve to be. Gru?, Uli -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From orion at cora.nwra.com Fri Sep 8 16:44:36 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 08 Sep 2006 10:44:36 -0600 Subject: [Fedora-packaging] pkgconfig dependency question Message-ID: <45019DF4.1030509@cora.nwra.com> After skimming some of the thread about .pc files in -devel or not, it seems like .pc files should be generating automatic dependencies. Is that not correct? I package plplot, and plplot-devel contains: # cat /usr/lib/pkgconfig/plplotd.pc prefix=/usr exec_prefix=/usr libdir=/usr/lib includedir=/usr/include/plplot drvdir=${libdir}/plplot5.6.1/driversd Name: PLplot Description: Scientific plotting library (double precision) Requires: Version: 5.6.1 Libs: -L${libdir} -lplplotd -L/usr/lib -lqhull -L/usr/lib -lcsironn -ldl -lm -L/usr/lib -lcsirocsa -lz -L/usr/lib -lfreetype Cflags: -I${includedir} But there are no dependencies on qhull-devel (via libqhull.so) and so forth. Should there be? -- Orion Poplawski System Administrator 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 Fri Sep 8 16:51:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 08 Sep 2006 11:51:52 -0500 Subject: [Fedora-packaging] pkgconfig dependency question In-Reply-To: <45019DF4.1030509@cora.nwra.com> References: <45019DF4.1030509@cora.nwra.com> Message-ID: <45019FA8.1090707@math.unl.edu> Orion Poplawski wrote: > After skimming some of the thread about .pc files in -devel or not, it > seems like .pc files should be generating automatic dependencies. Is > that not correct? Nope, only newer versions (than what Fedora currently has) of rpm includes the feature to automatically add Requires: dependencies extracted from .pc files (see Requires: line below, which happens to be empty). > I package plplot, and plplot-devel contains: > > # cat /usr/lib/pkgconfig/plplotd.pc > prefix=/usr > exec_prefix=/usr > libdir=/usr/lib > includedir=/usr/include/plplot > drvdir=${libdir}/plplot5.6.1/driversd > > Name: PLplot > Description: Scientific plotting library (double precision) > Requires: > Version: 5.6.1 > Libs: -L${libdir} -lplplotd -L/usr/lib -lqhull -L/usr/lib -lcsironn > -ldl -lm -L/usr/lib -lcsirocsa -lz -L/usr/lib -lfreetype > Cflags: -I${includedir} > > > But there are no dependencies on qhull-devel (via libqhull.so) and so > forth. Should there be? Kinda sorta. 2 solutions: 1. (imo, preferred), strip all/most non-plplot libs from the Libs: line. Those are only ever really needed for static linking (and Fedora doesn't include those, by default) 2. Add to plplot-devel Requires for the pkgs that include the libs referenced in Libs: -- rex From jmorris at redhat.com Fri Sep 8 20:50:44 2006 From: jmorris at redhat.com (James Morris) Date: Fri, 8 Sep 2006 16:50:44 -0400 (EDT) Subject: [Fedora-packaging] SELinux testing Message-ID: Many packages are not being tested with SELinux enabled before release, which is increasing the number of software defects being shipped, and causing users to disable SELinux. It is well documented that the cost of fixing software defects rises dramatically the further from the source they are experienced, and the worst possible case is after the software is shipped and deployed. For Fedora, these costs can be thought of in terms of cost to the project's goodwill and cost of everyone's time dealing with usually trivially addressable SELinux policy issues. Given that SELinux is a core security feature of the OS, enabled by default, I'd like to propose that the Fedora project establishes a simple guideline for package maintainers in relation to SELinux testing. This guideline would request that developers test their package with SELinux enabled (and by this I mean in enforcing mode) and follow a simple procedure: 1. Ensure they have the latest SELiunx policy installed. 2. Boot with selinux=1 and in enforcing mode. 3. Perform the normal testing of their application. 4. Check syslog (or /var/log/audit/audit.log if audit is enabled) for AVC messages related to their package. If there are any bugs or AVC messages: 5. Obtain support from the SELinux team. The best way to do this I believe is to file a bugzilla against the selinux-policy package. They should note that they are a Fedora packager (and expect a high priority response). If SELinux is running all or most of the time, issues will be caught and fixed eariler in their dev cycle. 6. Don't release the package until the SELinux issue is resolved. 7. If for some reason, #2 is not possible, and the release of the package is important enough to warrant disabling a core security feature of the OS: 7a. Make a note of the bugzilla # from (1) in the rpm info, cvs commit and release notes, with an explanation. Also include a standardized disclaimer in the rpm info which advises the user of the security risks arising from disabling SELinux. This should only happen in truly exceptional cases. I'm not sure how we can reliably notify users that SELinux can be re-enabled again, and whether they'll tolerate the entire fs being relabeled on reboot. Really, this just should not happen. Perhaps we can establish some kind of approval scheme for releasing a package which requires SELinux to be disabled (or for that matter, any security feature). Thoughts? -- James Morris From jmorris at redhat.com Fri Sep 8 20:52:52 2006 From: jmorris at redhat.com (James Morris) Date: Fri, 8 Sep 2006 16:52:52 -0400 (EDT) Subject: [Fedora-packaging] Re: SELinux testing In-Reply-To: Message-ID: On Fri, 8 Sep 2006, James Morris wrote: > 6. Don't release the package until the SELinux issue is resolved. > > 7. If for some reason, #2 is not possible, and the release of the package ^^^ that should be #6 -- James Morris From tibbs at math.uh.edu Fri Sep 8 21:09:41 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 08 Sep 2006 16:09:41 -0500 Subject: [Fedora-packaging] SELinux testing In-Reply-To: (James Morris's message of "Fri, 8 Sep 2006 16:50:44 -0400 (EDT)") References: Message-ID: >>>>> "JM" == James Morris writes: JM> This guideline would request that developers test their package JM> with SELinux enabled (and by this I mean in enforcing mode) and JM> follow a simple procedure: Just like the IPv6 thing, I don't think this is an appropriate topic for the packaging committee to consider. If it were in our purview, we could require that packages operate with SELinux targeted enforcing, but forcing reviewers and package maintainers to do this is a good way to make sure we have no package maintainers or reviewers (except for the ones who are paid by Red Hat, of course). I mean, FC5 as shipped won't even boot in my environment with SELinux turned on. (Yes, I reported the problems and they were quickly fixed, but that still doesn't get me a system I can boot to the point of getting updates.) So I think it's way too early to be forcing people to test with SELinux on. For Extras, an SELinux SIG would be great; they could go through and test applications, probably the server ones first. Core could of course make their own policy. It's not for the packaging committee to dictate either of those policies. Now, the packaging committee could publish guidelines for how to include SELinux rules in a package; that would be great. - J< From gdk at redhat.com Fri Sep 8 21:14:53 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Fri, 8 Sep 2006 17:14:53 -0400 (EDT) Subject: [Fedora-packaging] SELinux testing In-Reply-To: References: Message-ID: On Fri, 8 Sep 2006, Jason L Tibbitts III wrote: > >>>>> "JM" == James Morris writes: > > JM> This guideline would request that developers test their package > JM> with SELinux enabled (and by this I mean in enforcing mode) and > JM> follow a simple procedure: > > Just like the IPv6 thing, I don't think this is an appropriate topic > for the packaging committee to consider. > > If it were in our purview, we could require that packages operate with > SELinux targeted enforcing, but forcing reviewers and package > maintainers to do this is a good way to make sure we have no package > maintainers or reviewers (except for the ones who are paid by Red Hat, > of course). A big +1 here. We must *always* remember when working with community packagers: they do this work to accomplish *their* needs. The fact that they accomplish *our* needs as well is almost always a fortunate side effect. > I mean, FC5 as shipped won't even boot in my environment with SELinux > turned on. (Yes, I reported the problems and they were quickly fixed, > but that still doesn't get me a system I can boot to the point of > getting updates.) So I think it's way too early to be forcing people to > test with SELinux on. > > For Extras, an SELinux SIG would be great; they could go through and > test applications, probably the server ones first. Core could of > course make their own policy. It's not for the packaging committee to > dictate either of those policies. Another big +1. The unfortunate side effect here is that it's possible -- even likely -- that most community packagers won't give two craps about the SELinux SIG. > Now, the packaging committee could publish guidelines for how to > include SELinux rules in a package; that would be great. +1 again. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From tibbs at math.uh.edu Fri Sep 8 21:27:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 08 Sep 2006 16:27:47 -0500 Subject: [Fedora-packaging] SELinux testing In-Reply-To: (Greg DeKoenigsberg's message of "Fri, 8 Sep 2006 17:14:53 -0400 (EDT)") References: Message-ID: >>>>> "GD" == Greg DeKoenigsberg writes: GD> Another big +1. The unfortunate side effect here is that it's GD> possible -- even likely -- that most community packagers won't GD> give two craps about the SELinux SIG. Well, don't underestimate your reviewers. I know enough to point out some packages which will likely have selinux issues even though I am not generally able to test them under selinux. What has been a problem (for instance, in the Bugzilla review) is that even given an SELinux policy to test, nobody involved could do the testing. I tried but I just ended up wasting a couple of hours on relabels and ending up with a machine that needed to be reinstalled. Fortunately I have plenty of machines around that I can hack on; many reviewers and packagers aren't so blessed. I note that the submitter/maintainer of the Extras Bugzilla package is @redhat.com. The review ticket is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=188359 - J< From nicolas.mailhot at laposte.net Fri Sep 8 21:30:28 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 08 Sep 2006 23:30:28 +0200 Subject: [Fedora-packaging] SELinux testing In-Reply-To: References: Message-ID: <1157751028.4678.54.camel@rousalka.dyndns.org> Le vendredi 08 septembre 2006 ? 16:09 -0500, Jason L Tibbitts III a ?crit : > So I think it's way too early to be > forcing people to test with SELinux on. It's a vicious circle - if you don't test next release won't work with selinux, which mean you won't test, and so on. I'd probably relax the rules as "all packages must be tested with SeLinux by FC7T1", with the selinux team making sure selinux does not change too much afterwards so : 1. tested packages keep working at least till FC9T1 2. FC7 is solid selinux-wise and from FC7 on we *can* require new packages to be selinux-proof Note that FC7T1 is an *optimistic* deadline, it requires the selinux team to stabilise code tools and documentation well before, *and* block the human resources that will be necessary to help other packagers at the test date, and fix packages before FC7 proper. If FC7 is half-fixed like the previous ones, it *will* quickly degenerate. (network effects) -- 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 notting at redhat.com Fri Sep 8 22:09:31 2006 From: notting at redhat.com (Bill Nottingham) Date: Fri, 8 Sep 2006 18:09:31 -0400 Subject: [Fedora-packaging] SELinux testing In-Reply-To: References: Message-ID: <20060908220931.GA31219@nostromo.devel.redhat.com> Jason L Tibbitts III (tibbs at math.uh.edu) said: > Now, the packaging committee could publish guidelines for how to > include SELinux rules in a package; that would be great. Well, there's a draft standard, but you know that. :) http://fedoraproject.org/wiki/PackagingDrafts/SELinux Bill From rhbugs at n-dimensional.de Fri Sep 8 22:49:38 2006 From: rhbugs at n-dimensional.de (Hans Ulrich Niedermann) Date: Sat, 09 Sep 2006 00:49:38 +0200 Subject: [Fedora-packaging] SELinux testing In-Reply-To: (James Morris's message of "Fri, 8 Sep 2006 16:50:44 -0400 (EDT)") References: Message-ID: <86lkou0y9p.fsf@n-dimensional.de> James Morris writes: > This guideline would request that developers test their package with > SELinux enabled (and by this I mean in enforcing mode) and follow a simple > procedure: > > 1. Ensure they have the latest SELiunx policy installed. > 2. Boot with selinux=1 and in enforcing mode. > 3. Perform the normal testing of their application. Using which policy? targeted? strict? mls? Testing with "targeted" should be a "MUST" requirement IMHO, but requiring "strict" or "mls" will cause problems. > 4. Check syslog (or /var/log/audit/audit.log if audit is enabled) for AVC > messages related to their package. Gru?, Uli -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: From jmorris at redhat.com Fri Sep 8 22:56:30 2006 From: jmorris at redhat.com (James Morris) Date: Fri, 8 Sep 2006 18:56:30 -0400 (EDT) Subject: [Fedora-packaging] SELinux testing In-Reply-To: <86lkou0y9p.fsf@n-dimensional.de> Message-ID: On Sat, 9 Sep 2006, Hans Ulrich Niedermann wrote: > James Morris writes: > > > This guideline would request that developers test their package with > > SELinux enabled (and by this I mean in enforcing mode) and follow a simple > > procedure: > > > > 1. Ensure they have the latest SELiunx policy installed. > > 2. Boot with selinux=1 and in enforcing mode. > > 3. Perform the normal testing of their application. > > Using which policy? targeted? strict? mls? > > Testing with "targeted" should be a "MUST" requirement IMHO, but > requiring "strict" or "mls" will cause problems. Yes, we only worry about targeted for general users. -- James Morris From paul at city-fan.org Sat Sep 9 07:56:40 2006 From: paul at city-fan.org (Paul Howarth) Date: Sat, 09 Sep 2006 08:56:40 +0100 Subject: [Fedora-packaging] SELinux testing In-Reply-To: <20060908220931.GA31219@nostromo.devel.redhat.com> References: <20060908220931.GA31219@nostromo.devel.redhat.com> Message-ID: <1157788600.31547.6.camel@metropolis.intra.city-fan.org> On Fri, 2006-09-08 at 18:09 -0400, Bill Nottingham wrote: > Jason L Tibbitts III (tibbs at math.uh.edu) said: > > Now, the packaging committee could publish guidelines for how to > > include SELinux rules in a package; that would be great. > > Well, there's a draft standard, but you know that. :) > > http://fedoraproject.org/wiki/PackagingDrafts/SELinux That particular page needs a bit of work now, as some of the content has moved here: http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules Paul. From steve at silug.org Sat Sep 9 16:15:06 2006 From: steve at silug.org (Steven Pritchard) Date: Sat, 9 Sep 2006 11:15:06 -0500 Subject: [Fedora-packaging] SELinux testing In-Reply-To: References: Message-ID: <20060909161506.GA25452@osiris.silug.org> On Fri, Sep 08, 2006 at 04:50:44PM -0400, James Morris wrote: > 7. If for some reason, #2 is not possible, and the release of the package > is important enough to warrant disabling a core security feature of the > OS: > > 7a. Make a note of the bugzilla # from (1) in the rpm info, cvs commit and > release notes, with an explanation. Also include a standardized > disclaimer in the rpm info which advises the user of the security risks > arising from disabling SELinux. This should only happen in truly > exceptional cases. I'm not sure how we can reliably notify users that > SELinux can be re-enabled again, and whether they'll tolerate the entire > fs being relabeled on reboot. Really, this just should not happen. Can the policy for one application be turned off? (I honestly don't know... I haven't been able to justify spending the time to really wrap my brain around SELinux yet.) If not, that seems like a major flaw. It seems to me that if a user could just toggle off checks for a particular application (and reboot, I would assume) and have everything work well enough, there would be an incentive to fix the one application to work with SELinux instead of just turning off SELinux entirely. BTW, my limited experience with SELinux issues with one of my packages is here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187305 The time it took to resolve that bug really should be a hint that we're not ready to require SELinux compatibility in Extras yet. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From paul at city-fan.org Sun Sep 10 08:36:53 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 10 Sep 2006 09:36:53 +0100 Subject: [Fedora-packaging] SELinux testing In-Reply-To: <20060909161506.GA25452@osiris.silug.org> References: <20060909161506.GA25452@osiris.silug.org> Message-ID: <1157877413.12559.2.camel@metropolis.intra.city-fan.org> On Sat, 2006-09-09 at 11:15 -0500, Steven Pritchard wrote: > On Fri, Sep 08, 2006 at 04:50:44PM -0400, James Morris wrote: > > 7. If for some reason, #2 is not possible, and the release of the package > > is important enough to warrant disabling a core security feature of the > > OS: > > > > 7a. Make a note of the bugzilla # from (1) in the rpm info, cvs commit and > > release notes, with an explanation. Also include a standardized > > disclaimer in the rpm info which advises the user of the security risks > > arising from disabling SELinux. This should only happen in truly > > exceptional cases. I'm not sure how we can reliably notify users that > > SELinux can be re-enabled again, and whether they'll tolerate the entire > > fs being relabeled on reboot. Really, this just should not happen. > > Can the policy for one application be turned off? (I honestly don't > know... I haven't been able to justify spending the time to really > wrap my brain around SELinux yet.) This is usually possible, by setting the xxx_disable_trans SELinux boolean, service xxx doesn't transition from the unconfined domain and effectively runs with SELinux protection turned off. > If not, that seems like a major flaw. It seems to me that if a user > could just toggle off checks for a particular application (and reboot, > I would assume) and have everything work well enough, there would be > an incentive to fix the one application to work with SELinux instead > of just turning off SELinux entirely. Reboot isn't necessary; restarting the service should suffice. Paul. From panemade at gmail.com Sun Sep 10 08:51:53 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Sun, 10 Sep 2006 14:21:53 +0530 Subject: [Fedora-packaging] Re: Importance of debuginfo packages In-Reply-To: <1156180806.26974.18.camel@localhost.localdomain> References: <44E9C8E1.1070501@math.unl.edu> <200608211248.08625.jkeating@redhat.com> <20060821171655.GD25253@neu.nirvana> <1156180806.26974.18.camel@localhost.localdomain> Message-ID: Hi, On 8/21/06, Tom 'spot' Callaway wrote: > On Mon, 2006-08-21 at 19:16 +0200, Axel Thimm wrote: > > On Mon, Aug 21, 2006 at 11:54:22AM -0500, Jason L Tibbitts III wrote: > > > >>>>> "JK" == Jesse Keating writes: > > > > > > JK> Enough so that running gdb (gnu debugger) on the application will > > > JK> produce a meaningful traceback. > > > > > > So what needs to be there in order for that to work? > > > > > > I need to be able to superficially inspect a debuginfo package and > > > know whether it has enough stuff in it or not. > > > > That's very difficult, especially in projects with subdirectories that > > may redefine CFLAGS/CXXFLAGS w/o the builder noticing. sope/ogo is one > > nasty candidate for example. > > > > There are some safety pins in debuginfo, IIRC if it's turned on, but > > the debuginfo turns out empty the build will fail. That's how it gets > > my attention to fix debugging symbols at least :) > > Indeed, debuginfo being empty is about the only giant red warning flag > that I'm aware of. :) > May i know if debuginfo packages are really good in terms of let the end user debug applications to check if he is facing any crashes then why not we have separate debuginfo directory also present publicly for download? Regards, Parag. From ville.skytta at iki.fi Sun Sep 10 08:53:24 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 10 Sep 2006 11:53:24 +0300 Subject: [Fedora-packaging] pkgconfig dependency question In-Reply-To: <45019DF4.1030509@cora.nwra.com> References: <45019DF4.1030509@cora.nwra.com> Message-ID: <1157878404.16129.336.camel@viper.local> On Fri, 2006-09-08 at 10:44 -0600, Orion Poplawski wrote: > After skimming some of the thread about .pc files in -devel or not, it > seems like .pc files should be generating automatic dependencies. Is > that not correct? As far as I know, that's implemented only in newer versions of rpm than what's shipped in FC. Ditto *.la, FWIW. From panemade at gmail.com Sun Sep 10 09:09:55 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Sun, 10 Sep 2006 14:39:55 +0530 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <1156180726.3129.1.camel@localhost> References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <1155927752.2982.5.camel@localhost> <1156061937.2508.0.camel@localhost.localdomain> <1156180726.3129.1.camel@localhost> Message-ID: hi, On 8/21/06, Toshio Kuratomi wrote: > On Sun, 2006-08-20 at 11:18 +0300, Ville Skytt? wrote: > > On Fri, 2006-08-18 at 12:02 -0700, Toshio Kuratomi wrote: > > > > > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > > > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > > > that can work with Makefiles that don't make use of the DESTDIR variable > > > but it has the following potential issues:" > > > > +1 > > With my +1, that's six. > So can i say in other words that if applications built using say GTK application built using glade which automatically creates Makefiles must use always make install DESTDIR=%{buildroot} and not %makeinstall AND if upstream package developer himself written a Makefile then he must use %makeinstall ?? I need explanation on my understanding. Regards, Parag. From chris.stone at gmail.com Sun Sep 10 09:43:08 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 10 Sep 2006 02:43:08 -0700 Subject: [Fedora-packaging] .so files in main package for python packages In-Reply-To: References: Message-ID: Upstream says there is a packaging error in one of my packages, pypoker-eval-devel. Upstream claims that the .so file should not be in the devel package but should be in the main package. I told upstream about our .so rule saying .so files should be in -devel, but he said this is not the case for python packages, and promptly demonstrated that the libxml2-python package is similar and that this package puts the .so files in the main pacakge on Fedora as well. So is libxml2-python package in error, or is upstream correct and there are exceptions to the .so rule for python packages? Upstream informs me that my package will break unless I put the .so file in the main package. From jkeating at redhat.com Sun Sep 10 13:11:16 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Sep 2006 09:11:16 -0400 Subject: [Fedora-packaging] .so files in main package for python packages In-Reply-To: References: Message-ID: <200609100911.16656.jkeating@redhat.com> On Sunday 10 September 2006 05:43, Christopher Stone wrote: > Upstream claims that the .so file should not be in the devel package > but should be in the main package. > > I told upstream about our .so rule saying .so files should be in > -devel, but he said this is not the case for python packages, and > promptly demonstrated that the libxml2-python package is similar and > that this package puts the .so files in the main pacakge on Fedora as > well. Only .so SYMLINKS should be in the -devel package, the symlinks that are made to the actual libraries that would be in the main package. Python modules often have unversioned shared object files (.so) that are part of the module. They are not development symlinks and they SHOULD be packaged in the main package. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Sep 10 13:13:29 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 10 Sep 2006 09:13:29 -0400 Subject: [Fedora-packaging] .so files in main package for python packages In-Reply-To: <200609100911.16656.jkeating@redhat.com> References: <200609100911.16656.jkeating@redhat.com> Message-ID: <200609100913.29721.jkeating@redhat.com> On Sunday 10 September 2006 09:11, Jesse Keating wrote: > Only .so SYMLINKS should be in the -devel package, the symlinks that are > made to the actual libraries that would be in the main package. Whoops, that's not quite right I think... That's the general idea but I'm sure there are exceptions. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Sun Sep 10 14:26:04 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sun, 10 Sep 2006 09:26:04 -0500 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <1155927752.2982.5.camel@localhost> <1156061937.2508.0.camel@localhost.localdomain> <1156180726.3129.1.camel@localhost> Message-ID: <1157898364.31496.3.camel@dhcp-32-122.ord.redhat.com> On Sun, 2006-09-10 at 14:39 +0530, Parag N(????) wrote: > hi, > On 8/21/06, Toshio Kuratomi wrote: > > On Sun, 2006-08-20 at 11:18 +0300, Ville Skytt? wrote: > > > On Fri, 2006-08-18 at 12:02 -0700, Toshio Kuratomi wrote: > > > > > > > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > > > > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > > > > that can work with Makefiles that don't make use of the DESTDIR variable > > > > but it has the following potential issues:" > > > > > > +1 > > > > With my +1, that's six. > > > > So can i say in other words that if applications built using say GTK > application built using glade which automatically creates Makefiles > must use always > make install DESTDIR=%{buildroot} > and not %makeinstall If "make install DESTDIR=%{buildroot}" or "make install DESTDIR= $RPM_BUILD_ROOT" (depending on your preference) works, then you MUST use it. Only in those cases where it does not work can you then try % makeinstall. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From jamatos at fc.up.pt Sun Sep 10 15:37:43 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Sun, 10 Sep 2006 16:37:43 +0100 Subject: [Fedora-packaging] Re: Importance of debuginfo packages In-Reply-To: References: <1156180806.26974.18.camel@localhost.localdomain> Message-ID: <200609101637.43746.jamatos@fc.up.pt> On Sunday 10 September 2006 09:51, Parag N(????) wrote: > May i know if debuginfo packages are really good in terms of let the > end user debug applications to check if he is facing any crashes then > why not we have separate debuginfo directory also present publicly for > download? But they are. :-) Look into /etc/yum.repos.d/fedora-extras.repo the repository is there although disabled by default. > Regards, > Parag. -- Jos? Ab?lio From a.badger at gmail.com Sun Sep 10 15:12:02 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 Sep 2006 08:12:02 -0700 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <1155927752.2982.5.camel@localhost> <1156061937.2508.0.camel@localhost.localdomain> <1156180726.3129.1.camel@localhost> Message-ID: <1157901122.9161.69.camel@localhost> On Sun, 2006-09-10 at 14:39 +0530, Parag N(????) wrote: > hi, > On 8/21/06, Toshio Kuratomi wrote: > > > > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > > > > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > > > > that can work with Makefiles that don't make use of the DESTDIR variable > > > > but it has the following potential issues:" > So can i say in other words that if applications built using say GTK > application built using glade which automatically creates Makefiles > must use always > make install DESTDIR=%{buildroot} > and not %makeinstall > > AND if upstream package developer himself written a Makefile then he must use > %makeinstall ?? %makeinstall is an RPM spec file macro. It doesn't involve upstream because it is not part of the Makefile. It is only part of the spec file that you, as a Fedora packager, write. When upstream projects create Makefiles, they usually include a variable called DESTDIR which allows downstream packagers to install into a temporary directory. This works by prepending DESTDIR to the directories that the program installs into *during make install* (LIBDIR, DATADIR, etc). During build (regular "make" or "make all") the program uses only the directories the program will end up in (LIBDIR, DATADIR, etc) and does not use DESTDIR at all. Older Makefiles did not use DESTDIR. So with these the packager has to modify the values of the actual destination directories in order to install into the temporary root during packaging. This is what % makeinstall does. Since packagers still run across these Makefiles once in a while so %makeinstall still has value. But using it requires extra vigilance on the part of the packager and reviewer. You should look in the build.log to be sure that the package is not rebuilding any part of itself during "make install" and grep through the installed files to make sure the temporary root isn't included in any of the installed files. -Toshio -------------- 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 panemade at gmail.com Mon Sep 11 04:07:08 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Mon, 11 Sep 2006 09:37:08 +0530 Subject: [Fedora-packaging] Re: Importance of debuginfo packages In-Reply-To: <200609101637.43746.jamatos@fc.up.pt> References: <1156180806.26974.18.camel@localhost.localdomain> <200609101637.43746.jamatos@fc.up.pt> Message-ID: Hi, On 9/10/06, Jos? Matos wrote: > On Sunday 10 September 2006 09:51, Parag N(????) wrote: > > May i know if debuginfo packages are really good in terms of let the > > end user debug applications to check if he is facing any crashes then > > why not we have separate debuginfo directory also present publicly for > > download? > > But they are. :-) > Look into /etc/yum.repos.d/fedora-extras.repo the repository is there > although disabled by default. Oops i did not look into that. I should have checked it before. One more thing there is no separate iso or directory present in install media why so? Does that mean whoever want to use debuginfo packages he must download it from fedora website? > > > Regards, > > Parag. From panemade at gmail.com Mon Sep 11 04:10:16 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Mon, 11 Sep 2006 09:40:16 +0530 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: <1157901122.9161.69.camel@localhost> References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <1155927752.2982.5.camel@localhost> <1156061937.2508.0.camel@localhost.localdomain> <1156180726.3129.1.camel@localhost> <1157901122.9161.69.camel@localhost> Message-ID: Hi, On 9/10/06, Toshio Kuratomi wrote: > On Sun, 2006-09-10 at 14:39 +0530, Parag N(????) wrote: > > hi, > > On 8/21/06, Toshio Kuratomi wrote: > > > > > "Fedora's RPM includes a %makeinstall macro but it must NOT be used when > > > > > make install DESTDIR=%{buildroot} will work. %makeinstall is a kludge > > > > > that can work with Makefiles that don't make use of the DESTDIR variable > > > > > but it has the following potential issues:" > > > So can i say in other words that if applications built using say GTK > > application built using glade which automatically creates Makefiles > > must use always > > make install DESTDIR=%{buildroot} > > and not %makeinstall > > > > AND if upstream package developer himself written a Makefile then he must use > > %makeinstall ?? > > %makeinstall is an RPM spec file macro. It doesn't involve upstream > because it is not part of the Makefile. It is only part of the spec > file that you, as a Fedora packager, write. > > > When upstream projects create Makefiles, they usually include a variable > called DESTDIR which allows downstream packagers to install into a > temporary directory. This works by prepending DESTDIR to the > directories that the program installs into *during make install* > (LIBDIR, DATADIR, etc). During build (regular "make" or "make all") the > program uses only the directories the program will end up in (LIBDIR, > DATADIR, etc) and does not use DESTDIR at all. > > Older Makefiles did not use DESTDIR. So with these the packager has to > modify the values of the actual destination directories in order to > install into the temporary root during packaging. This is what % > makeinstall does. Since packagers still run across these Makefiles > once in a while so %makeinstall still has value. But using it requires > extra vigilance on the part of the packager and reviewer. You should > look in the build.log to be sure that the package is not rebuilding any > part of itself during "make install" and grep through the installed > files to make sure the temporary root isn't included in any of the > installed files. > So in other words i can say if i am going to package any tarball i should first check main Makefile for DESTDIR variable. If its present use make install DESTDIR=%{buildroot} if DESTDIR is not in Makefile use %makeinstall right? Regards, Parag. From a.badger at gmail.com Mon Sep 11 04:36:15 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 10 Sep 2006 21:36:15 -0700 Subject: [Fedora-packaging] %makeinstall - must not or should not use it? In-Reply-To: References: <200608181548.47138.opensource@till.name> <44E5C8C0.1010907@city-fan.org> <1155912220.4800.8.camel@localhost> <1155927752.2982.5.camel@localhost> <1156061937.2508.0.camel@localhost.localdomain> <1156180726.3129.1.camel@localhost> <1157901122.9161.69.camel@localhost> Message-ID: <1157949375.9161.127.camel@localhost> On Mon, 2006-09-11 at 09:40 +0530, Parag N(????) wrote: > So in other words i can say if i am going to package any tarball i > should first check main Makefile for DESTDIR variable. If its present > use > make install DESTDIR=%{buildroot} This part is correct barring brokecn Makefiles :-). I think all packages which use automake have DESTDIR (although this might not be the case in the distant past). > if DESTDIR is not in Makefile use > %makeinstall > right? ... and be sure to check that it doesn't compile the buildroot's path into the resulting programs. -Toshio -------------- 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 jamatos at fc.up.pt Mon Sep 11 07:42:56 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Mon, 11 Sep 2006 08:42:56 +0100 Subject: [Fedora-packaging] Re: Importance of debuginfo packages In-Reply-To: References: <200609101637.43746.jamatos@fc.up.pt> Message-ID: <200609110842.56960.jamatos@fc.up.pt> On Monday 11 September 2006 05:07, Parag N(????) wrote: > ? Oops i did not look into that. I should have checked it before. One > more thing there is no separate iso or directory present in install > media why so? Due to disk space constraints and since those packages are seldom needed the compromise was to leave them only on the on-line repository. > Does that mean whoever want to use debuginfo packages he > must download it from fedora website? Yep. -- Jos? Ab?lio From notting at redhat.com Mon Sep 11 14:02:34 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 11 Sep 2006 10:02:34 -0400 Subject: [Fedora-packaging] SELinux testing In-Reply-To: References: Message-ID: <20060911140234.GA9038@nostromo.devel.redhat.com> James Morris (jmorris at redhat.com) said: > This guideline would request that developers test their package with > SELinux enabled (and by this I mean in enforcing mode) and follow a simple > procedure: > > 1. Ensure they have the latest SELiunx policy installed. > 2. Boot with selinux=1 and in enforcing mode. > 3. Perform the normal testing of their application. > 4. Check syslog (or /var/log/audit/audit.log if audit is enabled) for AVC > messages related to their package. > > If there are any bugs or AVC messages: > > 5. Obtain support from the SELinux team. The best way to do this I > believe is to file a bugzilla against the selinux-policy package. They > should note that they are a Fedora packager (and expect a high priority > response). If SELinux is running all or most of the time, issues will be > caught and fixed eariler in their dev cycle. > > 6. Don't release the package until the SELinux issue is resolved. I'd suggest all of the following except #6 - make sure the issues are known, give a reasonable amount of time for fixes, but not necessarily hold until release. For example, fixes may not be backported to earlier releases, or the SELinux changes might require kernel fixes that are non-trivial to implement. Bill From Jochen at herr-schmitt.de Mon Sep 11 17:40:50 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 11 Sep 2006 19:40:50 +0200 Subject: [Fedora-packaging] Removing of unwanted compiler flags from $RPM_OPT_FLAGS Message-ID: <0MKwtQ-1GMpmH02Sk-0003Mq@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, becouse I have to find out, that some packages like blender have trouble if you are specify $RPM_OPT_FLAGS I have tried to search a method to remove selected compiler options from $RPM_OPT_FLAGS. My suggestion to solve this problem you may find at http://www.fedoraproject.org/wiki/JochenSchmitt/RemoveCFlagsFromRpmOptFlags#preview I will be happy for any comment and improvements. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBRQWfq09gByurcX4MEQJ6sgCg2XjHBWBAJww22r44/5RhqiP6JIAAoI+K PRZSyaFRredlXj4YLKXW2XwC =jsLk -----END PGP SIGNATURE----- From tcallawa at redhat.com Mon Sep 11 18:12:35 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 11 Sep 2006 13:12:35 -0500 Subject: [Fedora-packaging] Removing of unwanted compiler flags from $RPM_OPT_FLAGS In-Reply-To: <0MKwtQ-1GMpmH02Sk-0003Mq@mrelayeu.kundenserver.de> References: <0MKwtQ-1GMpmH02Sk-0003Mq@mrelayeu.kundenserver.de> Message-ID: <1157998355.13234.106.camel@localhost.localdomain> On Mon, 2006-09-11 at 19:40 +0200, Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > becouse I have to find out, that some packages like blender have > trouble if you are specify $RPM_OPT_FLAGS I have tried to search > a method to remove selected compiler options from $RPM_OPT_FLAGS. > > My suggestion to solve this problem you may find at > > http://www.fedoraproject.org/wiki/JochenSchmitt/RemoveCFlagsFromRpmOptFlags#preview > > I will be happy for any comment and improvements. That seems like serious overkill. Gambas can't build with the FORTIFY_SOURCE flag, so I remove it like this: # Gambas can't deal with -Wp,-D_FORTIFY_SOURCE=2 CFLAGS=`echo $RPM_OPT_FLAGS | sed -e 's/-Wp,-D_FORTIFY_SOURCE=2//g' Thats it. No extra shell scripts necessary. :) ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From rc040203 at freenet.de Tue Sep 12 04:59:01 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 12 Sep 2006 06:59:01 +0200 Subject: [Fedora-packaging] Removing of unwanted compiler flags from $RPM_OPT_FLAGS In-Reply-To: <1157998355.13234.106.camel@localhost.localdomain> References: <0MKwtQ-1GMpmH02Sk-0003Mq@mrelayeu.kundenserver.de> <1157998355.13234.106.camel@localhost.localdomain> Message-ID: <1158037141.4654.415.camel@mccallum.corsepiu.local> On Mon, 2006-09-11 at 13:12 -0500, Tom 'spot' Callaway wrote: > On Mon, 2006-09-11 at 19:40 +0200, Jochen Schmitt wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hello, > > > > becouse I have to find out, that some packages like blender have > > trouble if you are specify $RPM_OPT_FLAGS I have tried to search > > a method to remove selected compiler options from $RPM_OPT_FLAGS. > > > > My suggestion to solve this problem you may find at > > > > http://www.fedoraproject.org/wiki/JochenSchmitt/RemoveCFlagsFromRpmOptFlags#preview > > > > I will be happy for any comment and improvements. IMO, a package that can't build with fortify enabled is broken and ought to be fixed. > That seems like serious overkill. Gambas can't build with the > FORTIFY_SOURCE flag, so I remove it like this: > > # Gambas can't deal with -Wp,-D_FORTIFY_SOURCE=2 > CFLAGS=`echo $RPM_OPT_FLAGS | sed -e 's/-Wp,-D_FORTIFY_SOURCE=2//g' > > Thats it. No extra shell scripts necessary. :) That's acceptable as a temporary work-around, but ... a package not being able to deal with fortify is very likely to be plain broken (and harmful, likely to be suffering from memory leaks), which means you are playing with symptoms and not providing a cure. Ralf From panemade at gmail.com Tue Sep 12 05:15:59 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 12 Sep 2006 10:45:59 +0530 Subject: [Fedora-packaging] pkgconfig dependency question In-Reply-To: <1157878404.16129.336.camel@viper.local> References: <45019DF4.1030509@cora.nwra.com> <1157878404.16129.336.camel@viper.local> Message-ID: Hi, On 9/10/06, Ville Skytt? wrote: > On Fri, 2006-09-08 at 10:44 -0600, Orion Poplawski wrote: > > After skimming some of the thread about .pc files in -devel or not, it > > seems like .pc files should be generating automatic dependencies. Is > > that not correct? > > As far as I know, that's implemented only in newer versions of rpm than > what's shipped in FC. Ditto *.la, FWIW. Could you elaborate more on this? I mean you said newer rpm versions but what is that version name? and which FC(FC5?) ? Regards, Parag. From jkeating at redhat.com Tue Sep 12 05:25:15 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Sep 2006 01:25:15 -0400 Subject: [Fedora-packaging] pkgconfig dependency question In-Reply-To: References: <45019DF4.1030509@cora.nwra.com> <1157878404.16129.336.camel@viper.local> Message-ID: <200609120125.16105.jkeating@redhat.com> On Tuesday 12 September 2006 01:15, Parag N(????) wrote: > ?Could you elaborate more on this? I mean you said newer rpm versions > but what is that version name? and which FC(FC5?) ? He's referencing the rpm work done by Jeff Johnson that is not included in any Fedora Core release or development tree. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From panemade at gmail.com Tue Sep 12 05:49:42 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Tue, 12 Sep 2006 11:19:42 +0530 Subject: [Fedora-packaging] pkgconfig dependency question In-Reply-To: <200609120125.16105.jkeating@redhat.com> References: <45019DF4.1030509@cora.nwra.com> <1157878404.16129.336.camel@viper.local> <200609120125.16105.jkeating@redhat.com> Message-ID: Hi, On 9/12/06, Jesse Keating wrote: > On Tuesday 12 September 2006 01:15, Parag N(????) wrote: > > Could you elaborate more on this? I mean you said newer rpm versions > > but what is that version name? and which FC(FC5?) ? > > He's referencing the rpm work done by Jeff Johnson that is not included in any > Fedora Core release or development tree. But when i saw .pc files on FC6T2, i found that Requires tag there. So that mean that rpm workdone is included in FC6T2 right? Regards, Parag. From enrico.scholz at informatik.tu-chemnitz.de Tue Sep 12 06:15:12 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 12 Sep 2006 08:15:12 +0200 Subject: [Fedora-packaging] Removing of unwanted compiler flags from $RPM_OPT_FLAGS In-Reply-To: <0MKwtQ-1GMpmH02Sk-0003Mq@mrelayeu.kundenserver.de> (Jochen Schmitt's message of "Mon, 11 Sep 2006 19:40:50 +0200") References: <0MKwtQ-1GMpmH02Sk-0003Mq@mrelayeu.kundenserver.de> Message-ID: <878xkphaq7.fsf@kosh.bigo.ensc.de> Jochen at herr-schmitt.de (Jochen Schmitt) writes: > becouse I have to find out, that some packages like blender have > trouble if you are specify $RPM_OPT_FLAGS I have tried to search > a method to remove selected compiler options from $RPM_OPT_FLAGS. > > My suggestion to solve this problem you may find at > > http://www.fedoraproject.org/wiki/JochenSchmitt/RemoveCFlagsFromRpmOptFlags#preview The | RPM_OPT_FLAGS=$(echo $RPM_OPT_FLAGS | sed -e "s/\S*$i\S*//") stuff can be written shorter as | RPM_OPT_FLAGS=${RPM_OPT_FLAGS/-D.../} or perhaps | RPM_OPT_FLAGS="$RPM_OPT_FLAGS -fno-protector" I do not think that it is worth to create extra scriptlets for this case; packages which do not build with $RPM_OPT_FLAGS are usually broken. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Sep 12 11:38:53 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 12 Sep 2006 06:38:53 -0500 Subject: [Fedora-packaging] pkgconfig dependency question In-Reply-To: References: <45019DF4.1030509@cora.nwra.com> <1157878404.16129.336.camel@viper.local> <200609120125.16105.jkeating@redhat.com> Message-ID: <45069C4D.1060706@math.unl.edu> Parag N(????) wrote: > Hi, > On 9/12/06, Jesse Keating wrote: >> On Tuesday 12 September 2006 01:15, Parag N(????) wrote: >> > Could you elaborate more on this? I mean you said newer rpm versions >> > but what is that version name? and which FC(FC5?) ? >> >> He's referencing the rpm work done by Jeff Johnson that is not >> included in any >> Fedora Core release or development tree. > > But when i saw .pc files on FC6T2, i found that Requires tag there. So > that mean that rpm workdone is included in FC6T2 right? That Requires was added *by hand*, not automatically by rpm. -- Rex From jkeating at redhat.com Tue Sep 12 12:34:46 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 12 Sep 2006 08:34:46 -0400 Subject: [Fedora-packaging] pkgconfig dependency question In-Reply-To: References: <45019DF4.1030509@cora.nwra.com> <200609120125.16105.jkeating@redhat.com> Message-ID: <200609120834.50029.jkeating@redhat.com> On Tuesday 12 September 2006 01:49, Parag N(????) wrote: > But when i saw .pc files on FC6T2, i found that Requires tag there. So > that mean that rpm workdone is included in FC6T2 right? Within a .pc file, there are some Requires listed at times. This is generated during the build or upstream at the project site. The rpm work will find the Requires listed there and implant that into the rpm itself. Currently the Fedora (and RHEL) rpms will not do this automatic implant and the maintainer manually has to read the .pc file and add the Requires: line to the package which contains the .pc file (should be the -devel package). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Fedora at FamilleCollet.com Wed Sep 13 16:59:52 2006 From: Fedora at FamilleCollet.com (Remi Collet) Date: Wed, 13 Sep 2006 18:59:52 +0200 Subject: [Fedora-packaging] Including a CHANGELOG in php-pear extension package. Message-ID: <45083908.9000508@FamilleCollet.com> Do you thinks it's a good idea ? I wrote a little script to extract the CHANGELOG from the package.xml provided by the upstream package. Only have to add to the spec : Source2: xml2changelog In %prep : %setup -q -c [ -f package2.xml ] || mv package.xml package2.xml + %{_bindir}/php -n %{SOURCE2} package2.xml >CHANGELOG mv package2.xml %{pear_name}-%{version}/%{pear_name}.xml and, of course %doc CHANGELOG Here is my script : release->version, $xml->release->state, $xml->release->date, $xml->release->notes); foreach($xml->changelog->release as $rel) printf("* Version %s (%s) - %s\n\n%s\n\n", $rel->version, $rel->state, $rel->date, $rel->notes); ?> From panemade at gmail.com Thu Sep 14 12:44:51 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Thu, 14 Sep 2006 18:14:51 +0530 Subject: [Fedora-packaging] Kernel Module Packaging Message-ID: Hi, I am planning to submit kernel module packages which are not in mainstream kernel yet. May i know what guidelines should i follow? Do Fedora Packaging people confirmed on any kernel module packaging guidelines? I saw already many packages waiting for review in FE and yet no progress for them. why so? I don't understand why Fedora people don't want kernel module package that do not satisfy "A publishable explanation from the author(s) why the module is not merged with the mainline kernel yet and when it's planed to get merged. You of course can ask the author to explain it directly in the bug report. " How then ubuntu/debian distribution got them included in their OS? I saw many peoples claiming on IRC channels that they got many kernel module packages from their distro only and enjoying their usage then why Fedora is having objection on those waiting FE review packages? BTW is kmdl approach accepted or not? If not then should we let new kernel modules submissions according to kmod approach? Regards, Parag. From Jochen at herr-schmitt.de Thu Sep 14 19:51:09 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 14 Sep 2006 21:51:09 +0200 Subject: [Fedora-packaging] Kernel Module Packaging In-Reply-To: References: Message-ID: <0ML21M-1GNxEy2lgJ-0002k7@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 14 Sep 2006 18:14:51 +0530, you wrote: > I don't understand why Fedora people don't want kernel module >package that do not satisfy >"A publishable explanation from the author(s) why the module is not >merged with the mainline kernel yet and when it's planed to get >merged. You of course can ask the author to explain it directly in the >bug report. " I'm not a specialist about kernel modules. But one problem of there are the potential necessary to rebuild such packages for each new kernel release. Such rebuild may work well, but you have the potential danger, that the API of the kernel may be changed in a way, that the module will not work with the new kernel release. That is the result of the 'We need no stable kernel API'-philosophy of the kernel hackers There are approaches to developement tools to determinate such changes to minimize the need of rebuilds, but I think the is not the best solution. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.2 (Build 2424) iQA/AwUBRQmyrk9gByurcX4MEQIWOACfby5ecqMu2hirSn6SlHQGGE5FulIAn1/B WDYOhBnnfLkxIdPetBU0CDsO =lPBo -----END PGP SIGNATURE----- From rdieter at math.unl.edu Thu Sep 14 20:02:07 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 14 Sep 2006 15:02:07 -0500 Subject: [Fedora-packaging] Kernel Module Packaging In-Reply-To: References: Message-ID: <4509B53F.1060006@math.unl.edu> Parag N(????) wrote: > I don't understand why Fedora people don't want kernel module > package that do not satisfy > "A publishable explanation from the author(s) why the module is not > merged with the mainline kernel yet and when it's planed to get > merged. You of course can ask the author to explain it directly in the > bug report. " Because one of Fedora's Objectives(1) is: * To do as much of the development work as possible directly in the upstream packages. In short, if the kernel module isn't good enough for the upstream kernel, it's not good enough for Fedora either. -- Rex (1) http://fedoraproject.org/wiki/Objectives From michael at knox.net.nz Thu Sep 14 20:08:36 2006 From: michael at knox.net.nz (Michael J. Knox) Date: Fri, 15 Sep 2006 08:08:36 +1200 (NZST) Subject: [Fedora-packaging] Kernel Module Packaging In-Reply-To: <4509B53F.1060006@math.unl.edu> References: <4509B53F.1060006@math.unl.edu> Message-ID: <23061.203.118.135.21.1158264516.squirrel@www.knox.net.nz> Rex Dieter wrote: > Parag N(????????????) wrote: > >> I don't understand why Fedora people don't want kernel module >> package that do not satisfy >> "A publishable explanation from the author(s) why the module is not >> merged with the mainline kernel yet and when it's planed to get >> merged. You of course can ask the author to explain it directly in the >> bug report. " > > Because one of Fedora's Objectives(1) is: > * To do as much of the development work as possible directly in the > upstream packages. > > In short, if the kernel module isn't good enough for the upstream > kernel, it's not good enough for Fedora either. I don't mean to sound like I am baiting, but I do find that an interesting "objective" in light of recent xorg 7.1 "dramas".... Maybe I have missed a large portion of the discussions... Michael From panemade at gmail.com Fri Sep 15 03:59:23 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 15 Sep 2006 09:29:23 +0530 Subject: [Fedora-packaging] Kernel Module Packaging In-Reply-To: <4509B53F.1060006@math.unl.edu> References: <4509B53F.1060006@math.unl.edu> Message-ID: Hi Rex, On 9/15/06, Rex Dieter wrote: > Parag N(????) wrote: > > > I don't understand why Fedora people don't want kernel module > > package that do not satisfy > > "A publishable explanation from the author(s) why the module is not > > merged with the mainline kernel yet and when it's planed to get > > merged. You of course can ask the author to explain it directly in the > > bug report. " > > Because one of Fedora's Objectives(1) is: > * To do as much of the development work as possible directly in the > upstream packages. > > In short, if the kernel module isn't good enough for the upstream > kernel, it's not good enough for Fedora either. It looks to me that everybody want to stick with the Fedora Objectives whatever it has been decided but don't want to comment at all regarding kernel module packaging guidelines. So i assume that we will no longer be in decision to build any kernel modules packages for Fedora OS right? Because for same reason no progress i can find for kernel module packages with their status as FE-NEW. Regards, Parag. From panemade at gmail.com Fri Sep 15 04:08:00 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 15 Sep 2006 09:38:00 +0530 Subject: [Fedora-packaging] Kernel Module Packaging In-Reply-To: <0ML21M-1GNxEy2lgJ-0002k7@mrelayeu.kundenserver.de> References: <0ML21M-1GNxEy2lgJ-0002k7@mrelayeu.kundenserver.de> Message-ID: Hi, On 9/15/06, Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 14 Sep 2006 18:14:51 +0530, you wrote: > > > I don't understand why Fedora people don't want kernel module > >package that do not satisfy > >"A publishable explanation from the author(s) why the module is not > >merged with the mainline kernel yet and when it's planed to get > >merged. You of course can ask the author to explain it directly in the > >bug report. " > > I'm not a specialist about kernel modules. But one problem of > there are the potential necessary to rebuild such packages for > each new kernel release. And how it will be different than if same kernel module is inbuilt in upstream kernel releases? Its the Author who will be always releasing newer versions for his kernel modules whenever there are kernel API changes. So may i know what is the difference between a kernel module in upstream kernel which will be released with kernel along with its source code changes when some API changes in that release and external module that will be also updated for each new release? May be i am missing something to have complete idea about why should we don't have kernel module packages. can you tell me? May be i think this is the problem with Fedora kernels as we have always having a lot of patches along with any new Fedora kernel release and it may be difficult to maintain in that condition to make compatible any external module. > > Such rebuild may work well, but you have the potential danger, > that the API of the kernel may be changed in a way, that the > module will not work with the new kernel release. That is the > result of the 'We need no stable kernel API'-philosophy of the > kernel hackers > > There are approaches to developement tools to determinate such > changes to minimize the need of rebuilds, but I think the is not > the best solution. > Regards, Parag. From rdieter at math.unl.edu Fri Sep 15 11:26:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 15 Sep 2006 06:26:50 -0500 Subject: [Fedora-packaging] Re: Kernel Module Packaging In-Reply-To: References: <4509B53F.1060006@math.unl.edu> Message-ID: <450A8DFA.70402@math.unl.edu> Parag N(????) wrote: > ... i assume that we will no longer be in decision to build any > kernel modules packages for Fedora OS right? This is an incorrect assumption. -- Rex From panemade at gmail.com Fri Sep 15 12:41:50 2006 From: panemade at gmail.com (=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)?=) Date: Fri, 15 Sep 2006 18:11:50 +0530 Subject: [Fedora-packaging] Re: Kernel Module Packaging In-Reply-To: <450A8DFA.70402@math.unl.edu> References: <4509B53F.1060006@math.unl.edu> <450A8DFA.70402@math.unl.edu> Message-ID: Hi, On 9/15/06, Rex Dieter wrote: > Parag N(????) wrote: > > > ... i assume that we will no longer be in decision to build any > > kernel modules packages for Fedora OS right? > > This is an incorrect assumption. OK. Then how long i need to wait to get the kernel module guidelines to create kernel module packages? Regards, Parag. From rdieter at math.unl.edu Fri Sep 15 13:21:00 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 15 Sep 2006 08:21:00 -0500 Subject: [Fedora-packaging] Re: Kernel Module Packaging In-Reply-To: References: <4509B53F.1060006@math.unl.edu> <450A8DFA.70402@math.unl.edu> Message-ID: <450AA8BC.1060903@math.unl.edu> Parag N(????) wrote: > Hi, > On 9/15/06, Rex Dieter wrote: >> Parag N(????) wrote: >> >> > ... i assume that we will no longer be in decision to build any >> > kernel modules packages for Fedora OS right? >> >> This is an incorrect assumption. > > OK. Then how long i need to wait to get the kernel module guidelines > to create kernel module packages? A quick text search for 'kmod' turned up: http://fedoraproject.org/wiki/Packaging/KernelModules This is probably what you're looking for. -- Rex From fedora at leemhuis.info Fri Sep 15 14:51:09 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 15 Sep 2006 16:51:09 +0200 Subject: [Fedora-packaging] Re: Kernel Module Packaging In-Reply-To: References: Message-ID: <450ABDDD.7040705@leemhuis.info> Hi! Parag N(????) schrieb: > I am planning to submit kernel module packages which are not in > mainstream kernel yet. May i know what guidelines should i follow? As some poeple pointed out already: Use http://fedoraproject.org/wiki/Packaging/KernelModules > I saw already many packages waiting for review in FE and > yet no progress for them. why so? Seems no reviewer really wants to touch them :-/ And there was a discussion on FAB if we should generally (dis)allow kernel module packages in Extras. There was no real decision on this yet afaik -- the next meeting where this probably finally will be discussed is next Tuesday afaik. That's probably one of the reasons why kmod-packages are on hold slightly. > I don't understand why Fedora people don't want kernel module > package that do not satisfy > "A publishable explanation from the author(s) why the module is not > merged with the mainline kernel yet and when it's planed to get > merged. You of course can ask the author to explain it directly in the > bug report. " That's more a political hurdle we installed on purpose. The reasons behind this are not quickly answered. In short: Kernel modules belong into the kernel, that easier for users, developers and packagers. And we want to make sure they get there. [...] CU thl From a.badger at gmail.com Sun Sep 17 05:08:28 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 16 Sep 2006 22:08:28 -0700 Subject: [Fedora-packaging] No pre-built applications rule Message-ID: <1158469708.5063.32.camel@localhost> Hey guys, It's come to my attention that we don't have a "Packages must be built from source, no precompiled binaries" rule in the current guidelines. I think this is an oversight as the Binary Firmware section: http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware implies this for the specific case of firmware. How about something like: "Packages must be built from source code. Including pre-built programs or libraries is strictly forbidden. A select few exceptions are made for binary firmware. Please see http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware for details." And on ReviewGuidelines: "Must: The package must be built from source. No pre-built programs or libraries are acceptable." Thoughts, opinions welcome. -Toshio -------------- 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 rc040203 at freenet.de Sun Sep 17 05:53:10 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 17 Sep 2006 07:53:10 +0200 Subject: [Fedora-packaging] No pre-built applications rule In-Reply-To: <1158469708.5063.32.camel@localhost> References: <1158469708.5063.32.camel@localhost> Message-ID: <1158472390.5558.35.camel@mccallum.corsepiu.local> On Sat, 2006-09-16 at 22:08 -0700, Toshio Kuratomi wrote: > Hey guys, > It's come to my attention that we don't have a "Packages must be built > from source, no precompiled binaries" rule in the current guidelines. I > think this is an oversight as the Binary Firmware section: > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > implies this for the specific case of firmware. > > How about something like: > > "Packages must be built from source code. Including pre-built programs > or libraries is strictly forbidden. A select few exceptions are made > for binary firmware. Please see > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > for details." > > And on ReviewGuidelines: > "Must: The package must be built from source. No pre-built programs or > libraries are acceptable." -1 > Thoughts, opinions welcome. IMO, both rules above are a mistake. In my understanding the original intend was to force "rebuildability" on LINUX code, i.e. all Linux code to be open-sourced. I.e. you'd first have to define what you understand as "Linux code". A native firmware to be applied by a running Linux kernel would definitely qualify as such. But a firmware (as being applied by emulators) or foreign libraries (as being required by cross compilers) are cornercases. I find forcing to build them from source to be non-helpful, because 1. Technically, - Rebuilding such binaries can require very large toolchains underneath. - The toolchains required to rebuild such binaries, often have a circular dependency on such binaries. E.g. bootstrapping (cross-)compilers from scratch often is not possible or at least very hard to achieve (Applies to Linux itself, too) - Forcing to rebuild a binary introduces a very large risk of producing a non-usable binary from it, due to bugs in the toolchain required to rebuild it. Fixing such bugs is far from being trivial. 2. Where to draw the line between "such binaries" and "ordinary data"? >From a running OS's perspective, running a "non-native firmware" on in am emulator is not any different from processing "data", e.g. displaying a postscript document in ghostscript is essentially the same as running a foreign firmware in an emulator. Ralf From Axel.Thimm at ATrpms.net Sun Sep 17 07:19:28 2006 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 17 Sep 2006 09:19:28 +0200 Subject: [Fedora-packaging] Re: No pre-built applications rule In-Reply-To: <1158472390.5558.35.camel@mccallum.corsepiu.local> References: <1158469708.5063.32.camel@localhost> <1158472390.5558.35.camel@mccallum.corsepiu.local> Message-ID: <20060917071928.GA11176@neu.nirvana> On Sun, Sep 17, 2006 at 07:53:10AM +0200, Ralf Corsepius wrote: > On Sat, 2006-09-16 at 22:08 -0700, Toshio Kuratomi wrote: > > Hey guys, > > It's come to my attention that we don't have a "Packages must be built > > from source, no precompiled binaries" rule in the current guidelines. I > > think this is an oversight as the Binary Firmware section: > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > > > implies this for the specific case of firmware. > > > > How about something like: > > > > "Packages must be built from source code. Including pre-built programs > > or libraries is strictly forbidden. A select few exceptions are made > > for binary firmware. Please see > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > for details." > > > > And on ReviewGuidelines: > > "Must: The package must be built from source. No pre-built programs or > > libraries are acceptable." > -1 > > > Thoughts, opinions welcome. > > IMO, both rules above are a mistake. > > In my understanding the original intend was to force "rebuildability" on > LINUX code, i.e. all Linux code to be open-sourced. > > I.e. you'd first have to define what you understand as "Linux code". > > A native firmware to be applied by a running Linux kernel would > definitely qualify as such. But a firmware (as being applied by > emulators) or foreign libraries (as being required by cross compilers) > are cornercases. > > I find forcing to build them from source to be non-helpful, because > > 1. Technically, > - Rebuilding such binaries can require very large toolchains underneath. > > - The toolchains required to rebuild such binaries, often have a > circular dependency on such binaries. E.g. bootstrapping > (cross-)compilers from scratch often is not possible or at least very > hard to achieve (Applies to Linux itself, too) > > - Forcing to rebuild a binary introduces a very large risk of producing > a non-usable binary from it, due to bugs in the toolchain required to > rebuild it. Fixing such bugs is far from being trivial. Doesn't all this apply to several other software projects like gcc and openoffice, too? Why, then, do we ship source for these, too? > 2. Where to draw the line between "such binaries" and "ordinary data"? > > >From a running OS's perspective, running a "non-native firmware" on in > am emulator is not any different from processing "data", e.g. displaying > a postscript document in ghostscript is essentially the same as running > a foreign firmware in an emulator. So uploading closed source binaries to arm/scalepath/ppc hardware from i386 should be allowed? IMHO I think our mission as the packaging group is that need to define *how* to package something. *Whether* something is allowed to be packaged or not is not our decision. See also the kernel module discussion. This is because if we were to do so we would be touching Fedora's goals in one or another way, possibly with a different intention than what the original goals were. I read them as everything-open-source which would even include firmwares. I don't neccessarily personally agree with these goals, but that's not for me to decide, and neither for the packaging committee, e.g. how-vs-whether. So better bring this up with fesco or fab. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at city-fan.org Sun Sep 17 08:38:16 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 17 Sep 2006 09:38:16 +0100 Subject: [Fedora-packaging] No pre-built applications rule In-Reply-To: <1158469708.5063.32.camel@localhost> References: <1158469708.5063.32.camel@localhost> Message-ID: <1158482297.12938.3.camel@metropolis.intra.city-fan.org> On Sat, 2006-09-16 at 22:08 -0700, Toshio Kuratomi wrote: > Hey guys, > It's come to my attention that we don't have a "Packages must be built > from source, no precompiled binaries" rule in the current guidelines. I > think this is an oversight as the Binary Firmware section: > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > implies this for the specific case of firmware. > > How about something like: > > "Packages must be built from source code. Including pre-built programs > or libraries is strictly forbidden. A select few exceptions are made > for binary firmware. Please see > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > for details." > > And on ReviewGuidelines: > "Must: The package must be built from source. No pre-built programs or > libraries are acceptable." > > Thoughts, opinions welcome. Might another exception be needed for the bootstrapping procedures for new compilers, e.g. some of the lisp/haskell compilers in Extras? Paul. From nicolas.mailhot at laposte.net Sun Sep 17 08:58:34 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 17 Sep 2006 10:58:34 +0200 Subject: [Fedora-packaging] No pre-built applications rule In-Reply-To: <1158469708.5063.32.camel@localhost> References: <1158469708.5063.32.camel@localhost> Message-ID: <450D0E3A.5070902@laposte.net> Toshio Kuratomi a ?crit : > How about something like: > > "Packages must be built from source code. Including pre-built programs > or libraries is strictly forbidden. A select few exceptions are made > for binary firmware. If you want to tackle this particular problem, you also need an official bootstraping policy Regards, -- Nicolas Mailhot From paul at all-the-johnsons.co.uk Sun Sep 17 10:16:24 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 17 Sep 2006 11:16:24 +0100 Subject: [Fedora-packaging] No pre-built applications rule In-Reply-To: <1158469708.5063.32.camel@localhost> References: <1158469708.5063.32.camel@localhost> Message-ID: <1158488184.3845.49.camel@T7.Linux> Hi, > It's come to my attention that we don't have a "Packages must be built > from source, no precompiled binaries" rule in the current guidelines. I > think this is an oversight as the Binary Firmware section: > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware I have a problem with that and it's called ikvm (one of the mono packages). It cannot be built from source as FE or FC doesn't have the bits in yet (I looked into it a while back, but it's beyond my knowledge to do things with java stuff that needs bringing in). The package that was accepted is prebuilt. If ikvm comes out, then quite a number of the other mono packages in FE will be broken. However, I do agree that *new* packages should be covered by the "from source" only with a caveat that as soon as practicable, those already in are moved to source compiles. TTFN Paul -- "Bist Du meine Mutter?" - das leere kind -------------- 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 rdieter at math.unl.edu Sun Sep 17 16:58:59 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 17 Sep 2006 11:58:59 -0500 Subject: [Fedora-packaging] Re: No pre-built applications rule In-Reply-To: <1158482297.12938.3.camel@metropolis.intra.city-fan.org> References: <1158469708.5063.32.camel@localhost> <1158482297.12938.3.camel@metropolis.intra.city-fan.org> Message-ID: <450D7ED3.9070907@math.unl.edu> Paul Howarth wrote: > On Sat, 2006-09-16 at 22:08 -0700, Toshio Kuratomi wrote: >> Hey guys, >> It's come to my attention that we don't have a "Packages must be built >> from source, no precompiled binaries" rule in the current guidelines. I >> think this is an oversight as the Binary Firmware section: >> http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware >> >> implies this for the specific case of firmware. >> >> How about something like: >> >> "Packages must be built from source code. Including pre-built programs >> or libraries is strictly forbidden. A select few exceptions are made >> for binary firmware. Please see >> http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware >> for details." >> >> And on ReviewGuidelines: >> "Must: The package must be built from source. No pre-built programs or >> libraries are acceptable." >> >> Thoughts, opinions welcome. > > Might another exception be needed for the bootstrapping procedures for > new compilers, e.g. some of the lisp/haskell compilers in Extras? bootstrapping is kinda a separate problem. The proposal here is that *Packages* must be built from source, which I tend to I agree with, in principle. The "source" in question, can potentially include binary bits (for bootstrapping, whatever). -- Rex From rdieter at math.unl.edu Sun Sep 17 17:01:46 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 17 Sep 2006 12:01:46 -0500 Subject: [Fedora-packaging] Re: No pre-built applications rule In-Reply-To: <1158488184.3845.49.camel@T7.Linux> References: <1158469708.5063.32.camel@localhost> <1158488184.3845.49.camel@T7.Linux> Message-ID: <450D7F7A.7030706@math.unl.edu> Paul wrote: > Hi, > >> It's come to my attention that we don't have a "Packages must be built >> from source, no precompiled binaries" rule in the current guidelines. I >> think this is an oversight as the Binary Firmware section: >> http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > I have a problem with that and it's called ikvm (one of the mono > packages). It cannot be built from source as FE or FC doesn't have the > bits in yet (I looked into it a while back, but it's beyond my knowledge > to do things with java stuff that needs bringing in). The package that > was accepted is prebuilt. Building from source (also) brings a certain level of trust to the built-binary, which you don't necessarily have when using prebuilt binaries (from potentially untrusted sources). In general, for this reason alone, I think it's not a good idea to accept prebuilt binaries. -- Rex From a.badger at gmail.com Sun Sep 17 18:43:36 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 17 Sep 2006 11:43:36 -0700 Subject: [Fedora-packaging] No pre-built applications rule In-Reply-To: <1158472390.5558.35.camel@mccallum.corsepiu.local> References: <1158469708.5063.32.camel@localhost> <1158472390.5558.35.camel@mccallum.corsepiu.local> Message-ID: <1158518617.5063.105.camel@localhost> On Sun, 2006-09-17 at 07:53 +0200, Ralf Corsepius wrote: > On Sat, 2006-09-16 at 22:08 -0700, Toshio Kuratomi wrote: > > Hey guys, > > It's come to my attention that we don't have a "Packages must be built > > from source, no precompiled binaries" rule in the current guidelines. I > > think this is an oversight as the Binary Firmware section: > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > > > implies this for the specific case of firmware. > > > > How about something like: > > > > "Packages must be built from source code. Including pre-built programs > > or libraries is strictly forbidden. A select few exceptions are made > > for binary firmware. Please see > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > for details." > > > > And on ReviewGuidelines: > > "Must: The package must be built from source. No pre-built programs or > > libraries are acceptable." > -1 > > > Thoughts, opinions welcome. > > IMO, both rules above are a mistake. > By both, do you mean the sections for Packaging/Guidelines and for Packaging/ReviewGuidelines or the new proposal and the pre-existing BinaryFirmware Guidelines? > In my understanding the original intend was to force "rebuildability" on > LINUX code, i.e. all Linux code to be open-sourced. > > I.e. you'd first have to define what you understand as "Linux code". > > A native firmware to be applied by a running Linux kernel would > definitely qualify as such. But a firmware (as being applied by > emulators) I'd place this under the BinaryFirmware Guidelines so it's not covered in this new guideline. > or foreign libraries (as being required by cross compilers) > are cornercases. > Meaning the libraries built for the foreign architecture? So these do not execute on the host OS? If that's the case, then it could be considered data for the cross-toolchain rather than a library or program. I haven't thought about that case enough to know if that's a good idea or not, though. If it's a special build of a library that the cross toolchain uses to run on the host OS, then I think it does need to be rebuilt from source. -Toshio -------------- 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 a.badger at gmail.com Sun Sep 17 18:43:46 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 17 Sep 2006 11:43:46 -0700 Subject: [Fedora-packaging] No pre-built applications rule In-Reply-To: <1158488184.3845.49.camel@T7.Linux> References: <1158469708.5063.32.camel@localhost> <1158488184.3845.49.camel@T7.Linux> Message-ID: <1158518626.5063.108.camel@localhost> On Sun, 2006-09-17 at 11:16 +0100, Paul wrote: > Hi, > > > It's come to my attention that we don't have a "Packages must be built > > from source, no precompiled binaries" rule in the current guidelines. I > > think this is an oversight as the Binary Firmware section: > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > I have a problem with that and it's called ikvm (one of the mono > packages). It cannot be built from source as FE or FC doesn't have the > bits in yet (I looked into it a while back, but it's beyond my knowledge > to do things with java stuff that needs bringing in). The package that > was accepted is prebuilt. > I think this package shouldn't have made it through review. Packaging/Mono clearly prohibits this already. (It appears to have been reviewed before the Guidelines were updated, though.) The ikvm that's in cvs right now doesn't even include java or C# source. Since it's licensed under the GPL, that's a sticky legal consideration on top of the technical considerations. > If ikvm comes out, then quite a number of the other mono packages in FE > will be broken. > Not sure what to do with packages that are already in (whether they should be grandfathered or given a time limit to be fixed.) I lean towards a time limit to be fixed. > However, I do agree that *new* packages should be covered by the "from > source" only with a caveat that as soon as practicable, those already in > are moved to source compiles. > Packaging situations like ikvm are exactly what the Guidelines should be preventing. For python, mono, and other things that are compiled to a more machine efficient form, this makes sure the byte code on the machine comes from the auditable source. (python can be fooled by changing timestamps. mono is just like any other compiled language) Additionally, for C, C++, and native java this makes sure we compile with FORTIFY_SOURCE for enhanced security. -Toshio -------------- 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 a.badger at gmail.com Sun Sep 17 18:43:41 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 17 Sep 2006 11:43:41 -0700 Subject: [Fedora-packaging] No pre-built applications rule In-Reply-To: <450D0E3A.5070902@laposte.net> References: <1158469708.5063.32.camel@localhost> <450D0E3A.5070902@laposte.net> Message-ID: <1158518621.5063.107.camel@localhost> On Sun, 2006-09-17 at 10:58 +0200, Nicolas Mailhot wrote: > Toshio Kuratomi a ?crit : > > > How about something like: > > > > "Packages must be built from source code. Including pre-built programs > > or libraries is strictly forbidden. A select few exceptions are made > > for binary firmware. > > If you want to tackle this particular problem, you also need an official > bootstraping policy True. In the past it seemed like bootstrapping cases asked for permission on fedora-extras and permission was granted to do the one time import of a binary followed by compiling from the previous Fedora package. For now, I'd amend the draft policy to read: "Packages must be built from source code. Including pre-built programs or libraries is forbidden. There are exception for certain classes of binaries. See BinaryFirmware for exceptions that involve firmware. Send an email to fedora-extras-list(fesco?fedora-maintainers?) for discussion in the case of bootstrapping." For a real bootstrapping policy the main thing will be figuring out what criteria is needed for determining if we trust the binary compiler. Is it acceptable if it comes from upstream? If it comes from upstream with gpg signatures? If it comes from a Debian Package? Etc. The Ken Thompson article [1]_ is good reading for anyone that doesn't know why bootstrapping compilers needs an extra level of paranoia. [1]_ http://www.acm.org/classics/sep95/ -Toshio -------------- 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 bpepple at fedoraproject.org Sun Sep 17 18:57:06 2006 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 17 Sep 2006 14:57:06 -0400 Subject: [Fedora-packaging] No pre-built applications rule In-Reply-To: <1158518626.5063.108.camel@localhost> References: <1158469708.5063.32.camel@localhost> <1158488184.3845.49.camel@T7.Linux> <1158518626.5063.108.camel@localhost> Message-ID: <1158519426.10742.2.camel@shuttle.piedmont.com> On Sun, 2006-09-17 at 11:43 -0700, Toshio Kuratomi wrote: > > If ikvm comes out, then quite a number of the other mono packages in FE > > will be broken. > > > Not sure what to do with packages that are already in (whether they > should be grandfathered or given a time limit to be fixed.) I lean > towards a time limit to be fixed. I agree, this should be given a time limit to comply. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 rc040203 at freenet.de Mon Sep 18 01:44:36 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 18 Sep 2006 03:44:36 +0200 Subject: [Fedora-packaging] Re: No pre-built applications rule In-Reply-To: <20060917071928.GA11176@neu.nirvana> References: <1158469708.5063.32.camel@localhost> <1158472390.5558.35.camel@mccallum.corsepiu.local> <20060917071928.GA11176@neu.nirvana> Message-ID: <1158543876.5558.43.camel@mccallum.corsepiu.local> On Sun, 2006-09-17 at 09:19 +0200, Axel Thimm wrote: > On Sun, Sep 17, 2006 at 07:53:10AM +0200, Ralf Corsepius wrote: > > On Sat, 2006-09-16 at 22:08 -0700, Toshio Kuratomi wrote: > > > Hey guys, > > > It's come to my attention that we don't have a "Packages must be built > > > from source, no precompiled binaries" rule in the current guidelines. I > > > think this is an oversight as the Binary Firmware section: > > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > > > > > implies this for the specific case of firmware. > > > > > > How about something like: > > > > > > "Packages must be built from source code. Including pre-built programs > > > or libraries is strictly forbidden. A select few exceptions are made > > > for binary firmware. Please see > > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > > for details." > > > > > > And on ReviewGuidelines: > > > "Must: The package must be built from source. No pre-built programs or > > > libraries are acceptable." > > -1 > > > > > Thoughts, opinions welcome. > > > > IMO, both rules above are a mistake. > > > > In my understanding the original intend was to force "rebuildability" on > > LINUX code, i.e. all Linux code to be open-sourced. > > > > I.e. you'd first have to define what you understand as "Linux code". > > > > A native firmware to be applied by a running Linux kernel would > > definitely qualify as such. But a firmware (as being applied by > > emulators) or foreign libraries (as being required by cross compilers) > > are cornercases. > > > > I find forcing to build them from source to be non-helpful, because > > > > 1. Technically, > > - Rebuilding such binaries can require very large toolchains underneath. > > > > - The toolchains required to rebuild such binaries, often have a > > circular dependency on such binaries. E.g. bootstrapping > > (cross-)compilers from scratch often is not possible or at least very > > hard to achieve (Applies to Linux itself, too) > > > > - Forcing to rebuild a binary introduces a very large risk of producing > > a non-usable binary from it, due to bugs in the toolchain required to > > rebuild it. Fixing such bugs is far from being trivial. > > Doesn't all this apply to several other software projects like gcc and > openoffice, too? Dunno about openoffice, but this applies a GCC/kernel/glibc triple. To build them from scratch, you at one point need a foreign OS and a foreign c-compiler. > Why, then, do we ship source for these, too? Strictly speaking, we don't: GCC/kernel/glibc being built incrementally. We don't ship the foreign OS and the foreign c-compiler, you'd need to build them from scratch. > > 2. Where to draw the line between "such binaries" and "ordinary data"? > > > > >From a running OS's perspective, running a "non-native firmware" on in > > am emulator is not any different from processing "data", e.g. displaying > > a postscript document in ghostscript is essentially the same as running > > a foreign firmware in an emulator. > > So uploading closed source binaries to arm/scalepath/ppc hardware from > i386 should be allowed? No, closed-source != binary. The question is whether we enforce "must rebuild everything from scratch". > IMHO I think our mission as the packaging group is that need to define > *how* to package something. *Whether* something is allowed to be > packaged or not is not our decision. See also the kernel module > discussion. Agreed. Ralf From rc040203 at freenet.de Mon Sep 18 01:57:32 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 18 Sep 2006 03:57:32 +0200 Subject: [Fedora-packaging] Re: No pre-built applications rule In-Reply-To: <450D7ED3.9070907@math.unl.edu> References: <1158469708.5063.32.camel@localhost> <1158482297.12938.3.camel@metropolis.intra.city-fan.org> <450D7ED3.9070907@math.unl.edu> Message-ID: <1158544653.5558.56.camel@mccallum.corsepiu.local> On Sun, 2006-09-17 at 11:58 -0500, Rex Dieter wrote: > Paul Howarth wrote: > > On Sat, 2006-09-16 at 22:08 -0700, Toshio Kuratomi wrote: > >> Hey guys, > >> It's come to my attention that we don't have a "Packages must be built > >> from source, no precompiled binaries" rule in the current guidelines. I > >> think this is an oversight as the Binary Firmware section: > >> http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > >> > >> implies this for the specific case of firmware. > >> > >> How about something like: > >> > >> "Packages must be built from source code. Including pre-built programs > >> or libraries is strictly forbidden. A select few exceptions are made > >> for binary firmware. Please see > >> http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > >> for details." > >> > >> And on ReviewGuidelines: > >> "Must: The package must be built from source. No pre-built programs or > >> libraries are acceptable." > >> > >> Thoughts, opinions welcome. > > > > Might another exception be needed for the bootstrapping procedures for > > new compilers, e.g. some of the lisp/haskell compilers in Extras? > > bootstrapping is kinda a separate problem. The proposal here is that > *Packages* must be built from source, which I tend to I agree with, in > principle. The "source" in question, can potentially include binary > bits (for bootstrapping, whatever). You can't separate these problems, because problems in bootstrapping are primary the reason (Typically either circular deps large dependency chains) or for open-source packages to contain binaries (of open-sourced sources). A classical example for such cases are emulators: They typically need a some "k-byte piece of Firmware", having to be compiled by a cross-toolchain. I.e. to rebuild them from scratch, you'd first have to have this cross-toolchain. If your're lucky such a cross-toolchain is buildable, but several 100MB in size. If you're out of luck, such a toolchain doesn't exist for linux, but only for some other OS (Open source != Linux; Open-source != buildable by open source). Packagers often circumvent this "ugly dependency chain", by shipping binaries. Now consider pdf or ps documents - People often use foreign tools to write them - They are binaries having been built from closed source, aren't they? Ralf From rc040203 at freenet.de Mon Sep 18 02:32:34 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 18 Sep 2006 04:32:34 +0200 Subject: [Fedora-packaging] No pre-built applications rule In-Reply-To: <1158518617.5063.105.camel@localhost> References: <1158469708.5063.32.camel@localhost> <1158472390.5558.35.camel@mccallum.corsepiu.local> <1158518617.5063.105.camel@localhost> Message-ID: <1158546755.5558.78.camel@mccallum.corsepiu.local> On Sun, 2006-09-17 at 11:43 -0700, Toshio Kuratomi wrote: > On Sun, 2006-09-17 at 07:53 +0200, Ralf Corsepius wrote: > > On Sat, 2006-09-16 at 22:08 -0700, Toshio Kuratomi wrote: > > > Hey guys, > > > It's come to my attention that we don't have a "Packages must be built > > > from source, no precompiled binaries" rule in the current guidelines. I > > > think this is an oversight as the Binary Firmware section: > > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > > > > > implies this for the specific case of firmware. > > > > > > How about something like: > > > > > > "Packages must be built from source code. Including pre-built programs > > > or libraries is strictly forbidden. A select few exceptions are made > > > for binary firmware. Please see > > > http://www.fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware > > > for details." > > > > > > And on ReviewGuidelines: > > > "Must: The package must be built from source. No pre-built programs or > > > libraries are acceptable." > > -1 > > > > > Thoughts, opinions welcome. > > > > IMO, both rules above are a mistake. > > > By both, do you mean the sections for Packaging/Guidelines and for > Packaging/ReviewGuidelines or the new proposal and the pre-existing > BinaryFirmware Guidelines? I meant the old and the new version to be a mistake. > > In my understanding the original intend was to force "rebuildability" on > > LINUX code, i.e. all Linux code to be open-sourced. > > > > I.e. you'd first have to define what you understand as "Linux code". > > > > A native firmware to be applied by a running Linux kernel would > > definitely qualify as such. But a firmware (as being applied by > > emulators) > > I'd place this under the BinaryFirmware Guidelines so it's not covered > in this new guideline. IMO, the BinaryFirmware Guideline is a special case from the more general case. I don't see any sense in the BinaryFirmware Guideline to exist. > > or foreign libraries (as being required by cross compilers) > > are cornercases. > > > Meaning the libraries built for the foreign architecture? So these do > not execute on the host OS? Yes, except when using emulators/simulators, they typically they are not executed on the host. An example for such a case is a (cross-) target's libc. In general, you need it to be able to build a (cross-) GCC and to use this (cross-) GCC. In some cases you can address this by bootstrapping the target OS/kernel, libc and GCC at once, but this is magnitudes more difficult than using (repackaging a target's binary files) a target's libc binaries directly. Consider building a i386-redhat-gcc -> ppc-redhat-GCC. Everything is free, but building a ppc-glibc/GCC from scratch is magnitudes more difficult and error-prone than repackaging Fedora's ppc-rpms for such purposes. The same applies to other opensource cross-GCC targets, such as FreeBSDs, MinGW, Cygwin or other Linuxes. > If that's the case, then it could be > considered data for the cross-toolchain rather than a library or > program. I haven't thought about that case enough to know if that's a > good idea or not, though. > > If it's a special build of a library that the cross toolchain uses to > run on the host OS, then I think it does need to be rebuilt from source. ACK, but ... when to stop "requiring to build from source"? I don't have an answer to this question. If I think your proposal's and the current guidelines to an end, * it is required each and every binary to be rebuild and NOT to use ANY pre-built binary. * you don't define what a binary is. Ralf From dlutter at redhat.com Mon Sep 18 11:55:05 2006 From: dlutter at redhat.com (David Lutterkort) Date: Mon, 18 Sep 2006 13:55:05 +0200 Subject: [Fedora-packaging] Re: No pre-built applications rule In-Reply-To: <1158544653.5558.56.camel@mccallum.corsepiu.local> References: <1158469708.5063.32.camel@localhost> <1158482297.12938.3.camel@metropolis.intra.city-fan.org> <450D7ED3.9070907@math.unl.edu> <1158544653.5558.56.camel@mccallum.corsepiu.local> Message-ID: <1158580506.15572.3.camel@localhost.localdomain> On Mon, 2006-09-18 at 03:57 +0200, Ralf Corsepius wrote: > Now consider pdf or ps documents - People often use foreign tools to > write them - They are binaries having been built from closed source, > aren't they? They are (compressed, in the case of pdf) text files. The 'from source' guideline should be restricted to executable code; strictly speaking, that would include ps, since it's run through a complete, fairly unrestricted Forth interpreter. PDF should be unproblematic. David From rdieter at math.unl.edu Mon Sep 18 13:35:17 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 18 Sep 2006 08:35:17 -0500 Subject: [Fedora-packaging] Re: No pre-built applications rule References: <1158469708.5063.32.camel@localhost> <1158488184.3845.49.camel@T7.Linux> <1158518626.5063.108.camel@localhost> <1158519426.10742.2.camel@shuttle.piedmont.com> Message-ID: Brian Pepple wrote: > On Sun, 2006-09-17 at 11:43 -0700, Toshio Kuratomi wrote: >> > If ikvm comes out, then quite a number of the other mono packages in FE >> > will be broken. >> > >> Not sure what to do with packages that are already in (whether they >> should be grandfathered or given a time limit to be fixed.) I lean >> towards a time limit to be fixed. > > I agree, this should be given a time limit to comply. +1. Hopefully we won't have to deploy the Packaging thugs, err, bandits, err, police to enforce compliance. (: -- Rex From opensource at till.name Tue Sep 19 15:36:39 2006 From: opensource at till.name (Till Maas) Date: Tue, 19 Sep 2006 17:36:39 +0200 Subject: [Fedora-packaging] changelog entries: release with disttag? Message-ID: <200609191736.46035.opensource@till.name> Hiyas, what information about E-V-R should be in changelog entries? In http://fedoraproject.org/wiki/Packaging/Guidelines#head-b7d622f4bb245300199c6a33128acce5fb453213 the first example is: * Wed Jun 14 2003 Joe Packager - 0:1.0-0.fdr.2 This seems to contain %{?dist} (fdr) but the other examples do not. This is irritating. And as far as I understand the NamingGuidelines 0.fdr.2 is not a valid release tag nowadays. In http://lemenkov.newmail.ru/SPECS/sipsak.spec (sipsak has been submitted as a review request (206872)) %{?dist} is used in a changelog entry, is this allowed? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Sep 19 15:45:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Sep 2006 10:45:13 -0500 Subject: [Fedora-packaging] changelog entries: release with disttag? In-Reply-To: <200609191736.46035.opensource@till.name> References: <200609191736.46035.opensource@till.name> Message-ID: <45101089.5080704@math.unl.edu> Till Maas wrote: > what information about E-V-R should be in changelog entries? > In > http://fedoraproject.org/wiki/Packaging/Guidelines#head-b7d622f4bb245300199c6a33128acce5fb453213 > the first example is: > > * Wed Jun 14 2003 Joe Packager - 0:1.0-0.fdr.2 > > This seems to contain %{?dist} (fdr) but the other examples do not. This is > irritating. And as far as I understand the NamingGuidelines 0.fdr.2 is not a > valid release tag nowadays. NamingGuidelines (mostly) only pertain to *new* changelog entries. Maintaining old ones as-is is important to see the history of the package. 0.fdr.2 dates back to the fedora.us days. -- Rex From opensource at till.name Tue Sep 19 15:58:29 2006 From: opensource at till.name (Till Maas) Date: Tue, 19 Sep 2006 17:58:29 +0200 Subject: [Fedora-packaging] changelog entries: release with disttag? In-Reply-To: <45101089.5080704@math.unl.edu> References: <200609191736.46035.opensource@till.name> <45101089.5080704@math.unl.edu> Message-ID: <200609191758.46516.opensource@till.name> On Tuesday 19 September 2006 17:45, Rex Dieter wrote: > NamingGuidelines (mostly) only pertain to *new* changelog entries. > Maintaining old ones as-is is important to see the history of the > package. 0.fdr.2 dates back to the fedora.us days. The Packaging Guidelines describe how new changelog entries should the added and this example is used to show how new changelog entries should be added. Since it is not correct anymore it should be changed to a current, valid one. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Sep 19 16:03:58 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Sep 2006 11:03:58 -0500 Subject: [Fedora-packaging] changelog entries: release with disttag? In-Reply-To: <200609191758.46516.opensource@till.name> References: <200609191736.46035.opensource@till.name> <45101089.5080704@math.unl.edu> <200609191758.46516.opensource@till.name> Message-ID: <451014EE.2020307@math.unl.edu> Till Maas wrote: > On Tuesday 19 September 2006 17:45, Rex Dieter wrote: > >> NamingGuidelines (mostly) only pertain to *new* changelog entries. >> Maintaining old ones as-is is important to see the history of the >> package. 0.fdr.2 dates back to the fedora.us days. > > The Packaging Guidelines describe how new changelog entries should the added > and this example is used to show how new changelog entries should be added. > Since it is not correct anymore it should be changed to a current, valid one. No biggie, though that's not one including in the section labeled "You must use one of the following (changelog) formats"... (: -- Rex From rdieter at math.unl.edu Tue Sep 19 16:09:52 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Sep 2006 11:09:52 -0500 Subject: [Fedora-packaging] changelog entries: release with disttag? In-Reply-To: <451014EE.2020307@math.unl.edu> References: <200609191736.46035.opensource@till.name> <45101089.5080704@math.unl.edu> <200609191758.46516.opensource@till.name> <451014EE.2020307@math.unl.edu> Message-ID: <45101650.2040706@math.unl.edu> Rex Dieter wrote: > Till Maas wrote: >> On Tuesday 19 September 2006 17:45, Rex Dieter wrote: >> >>> NamingGuidelines (mostly) only pertain to *new* changelog entries. >>> Maintaining old ones as-is is important to see the history of the >>> package. 0.fdr.2 dates back to the fedora.us days. >> >> The Packaging Guidelines describe how new changelog entries should the >> added and this example is used to show how new changelog entries >> should be added. Since it is not correct anymore it should be changed >> to a current, valid one. > > No biggie, though that's not one including in the section labeled "You > must use one of the following (changelog) formats"... (: OK, Guideline updated to remove reference to 0.fdr in changelog example. -- Rex From opensource at till.name Tue Sep 19 22:37:05 2006 From: opensource at till.name (Till Maas) Date: Wed, 20 Sep 2006 00:37:05 +0200 Subject: [Fedora-packaging] ReviewGuidelines: What are proper permissions? Message-ID: <200609200037.31253.opensource@till.name> Hiyas, ReviewGuidelines say: MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. I just noticed that there are some files with permissions 0444 on my fc5 system installed, for example manpages: -r--r--r-- 1 root root 24410 15. Feb 2006 cdrecord.1.gz -r--r--r-- 1 root root 1229 11. Feb 2006 dos2unix.1.gz -r--r--r-- 1 root root 1790 11. Feb 2006 hesinfo.1.gz Are 0444 proper permission bits for manpages / non-executable files? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Tue Sep 19 23:29:57 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 19 Sep 2006 18:29:57 -0500 Subject: [Fedora-packaging] ReviewGuidelines: What are proper permissions? In-Reply-To: <200609200037.31253.opensource@till.name> References: <200609200037.31253.opensource@till.name> Message-ID: <1158708597.6156.46.camel@localhost.localdomain> On Wed, 2006-09-20 at 00:37 +0200, Till Maas wrote: > Hiyas, > > ReviewGuidelines say: > MUST: Permissions on files must be set properly. Executables should be set > with executable permissions, for example. > > I just noticed that there are some files with permissions 0444 on my fc5 > system installed, for example manpages: > > -r--r--r-- 1 root root 24410 15. Feb 2006 cdrecord.1.gz > -r--r--r-- 1 root root 1229 11. Feb 2006 dos2unix.1.gz > -r--r--r-- 1 root root 1790 11. Feb 2006 hesinfo.1.gz > > Are 0444 proper permission bits for manpages / non-executable files? Well, I'd think anyone should be able to read them, no one should really ever need to write to them, and they darned well better not be executable. Seems sane to me. ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From a.badger at gmail.com Wed Sep 20 00:24:43 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 19 Sep 2006 17:24:43 -0700 Subject: [Fedora-packaging] ReviewGuidelines: What are proper permissions? In-Reply-To: <200609200037.31253.opensource@till.name> References: <200609200037.31253.opensource@till.name> Message-ID: <1158711884.2838.40.camel@localhost> On Wed, 2006-09-20 at 00:37 +0200, Till Maas wrote: > Hiyas, > > ReviewGuidelines say: > MUST: Permissions on files must be set properly. Executables should be set > with executable permissions, for example. > > I just noticed that there are some files with permissions 0444 on my fc5 > system installed, for example manpages: > > -r--r--r-- 1 root root 24410 15. Feb 2006 cdrecord.1.gz > -r--r--r-- 1 root root 1229 11. Feb 2006 dos2unix.1.gz > -r--r--r-- 1 root root 1790 11. Feb 2006 hesinfo.1.gz > > Are 0444 proper permission bits for manpages / non-executable files? 0644 is traditional but I don't see anything wrong with 0444. -Toshio -------------- 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 opensource at till.name Wed Sep 20 22:11:32 2006 From: opensource at till.name (Till Maas) Date: Thu, 21 Sep 2006 00:11:32 +0200 Subject: [Fedora-packaging] Taking care of renamed config file Message-ID: <200609210011.40981.opensource@till.name> Hiyas, I am updating the spec of john to the newest version. John now uses john.conf as config file but used john.ini before. Should I now rename existing john.ini to john.conf within a post or pre scriptlet or only add the new config file? I would prefer to rename it in a pre scriptlet if it is an upgrade so that the new shipped config file would be created as john.conf.rpmnew. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mgarski at post.pl Fri Sep 22 10:53:31 2006 From: mgarski at post.pl (Marcin Garski) Date: Fri, 22 Sep 2006 12:53:31 +0200 Subject: [Fedora-packaging] GTK+ icon cache "bugs" on ScriptletSnippets Message-ID: <4513C0AB.50301@post.pl> Hello, I'm a maintainer of Krusader package in Fedora Extras. Recently I've recived bug report http://bugzilla.redhat.com/206650 yum install krusader Installing: krusader ######################### [1/1] No theme index file in '/usr/share/icons/locolor'. If you really want to create an icon cache here, use --ignore-theme-index. I've started to investigate it. The problem is GTK+ icon cache. I've used in my spec file scripts from: http://fedoraproject.org/wiki/Packaging/ScriptletSnippets (GTK+ icon cache section). This scripts doesn't check if %{_datadir}/icons/hicolor/index.theme exist, so in this case gtk-update-icon-cache generate such error. My proposed resolution for this bug can be found in http://bugzilla.redhat.com/206860 but I will also paste it here: if [ -x %{_bindir}/gtk-update-icon-cache ]; then if [ -f %{_datadir}/icons/hicolor/index.theme ]; then touch --no-create %{_datadir}/icons/hicolor || : %{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : fi fi -- Best Regards Marcin Garski From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Sep 22 14:36:46 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 22 Sep 2006 16:36:46 +0200 Subject: [Fedora-packaging] Including a static library Message-ID: <20060922163646.56974fad@python3.es.egwn.lan> Hi, Regarding this bug : https://bugzilla.redhat.com/204568 It does makes sense to ship the DirectFB static libraries for some users. So here are my questions : - Should they be put into the existing -devel sub-package? - Should they be put into a new separate sub-package? (-static) I'm asking because since it's not really for "development", it would make sense to split it out in a new sub-package. Also, that way it would avoid any possible scenario where something rebuilding against DirectFB would "accidentally" link statically instead of dynamically. Thoughts? Some existing guideline I might have missed? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5.92 (FC6 Test3) - Linux kernel 2.6.17-1.2647.fc6 Load : 0.08 0.12 0.12 From rdieter at math.unl.edu Sun Sep 24 03:21:57 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 23 Sep 2006 22:21:57 -0500 Subject: [Fedora-packaging] Re: GTK+ icon cache "bugs" on ScriptletSnippets In-Reply-To: <4513C0AB.50301@post.pl> References: <4513C0AB.50301@post.pl> Message-ID: Marcin Garski wrote: > My proposed resolution for this bug can be found in > http://bugzilla.redhat.com/206860 but I will also paste it here: > > if [ -x %{_bindir}/gtk-update-icon-cache ]; then > if [ -f %{_datadir}/icons/hicolor/index.theme ]; then > touch --no-create %{_datadir}/icons/hicolor || : > %{_bindir}/gtk-update-icon-cache --quiet > %{_datadir}/icons/hicolor || : > fi > fi I'd argue to greatly simplify the above to just: gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2>/dev/null ||: but that's just me. Actually, I'd argue this, imo, *stooopid* gtk-update-* crud doesn't belong in packages at all, but again, that's just me, or wait, me and *lots* of others too: http://bugzilla.redhat.com//170335 -- Rex From chris.stone at gmail.com Sun Sep 24 16:37:52 2006 From: chris.stone at gmail.com (Christopher Stone) Date: Sun, 24 Sep 2006 09:37:52 -0700 Subject: [Fedora-packaging] Re: GTK+ icon cache "bugs" on ScriptletSnippets In-Reply-To: References: <4513C0AB.50301@post.pl> Message-ID: On 9/23/06, Rex Dieter wrote: > Marcin Garski wrote: > > > My proposed resolution for this bug can be found in > > http://bugzilla.redhat.com/206860 but I will also paste it here: > > > > if [ -x %{_bindir}/gtk-update-icon-cache ]; then > > if [ -f %{_datadir}/icons/hicolor/index.theme ]; then > > touch --no-create %{_datadir}/icons/hicolor || : > > %{_bindir}/gtk-update-icon-cache --quiet > > %{_datadir}/icons/hicolor || : > > fi > > fi > > I'd argue to greatly simplify the above to just: > gtk-update-icon-cache -q %{_datadir}/icons/hicolor 2>/dev/null ||: > but that's just me. > > Actually, I'd argue this, imo, *stooopid* gtk-update-* crud doesn't > belong in packages at all, but again, that's just me, or wait, me and > *lots* of others too: > http://bugzilla.redhat.com//170335 +1 on stupidity comment. Just curious, how come KDE doesn't have to do such stupid things? Let's please remove gtk+ stupidity from spec files. Thanks. From rdieter at math.unl.edu Sun Sep 24 21:51:08 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 24 Sep 2006 16:51:08 -0500 Subject: [Fedora-packaging] Re: GTK+ icon cache "bugs" on ScriptletSnippets In-Reply-To: References: <4513C0AB.50301@post.pl> Message-ID: <4516FDCC.9060309@math.unl.edu> Christopher Stone wrote: > Just curious, how come KDE doesn't have to > do such stupid things? kde doesn't cache icon themes. To be fair, gtk doesn't *have* to redo/use gtk-update-icon-cache either, as it will (properly) fall-back to not using the cache if it is stale (and it'll just be slower, of course). -- rex From rdieter at math.unl.edu Mon Sep 25 11:56:42 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 25 Sep 2006 06:56:42 -0500 Subject: [Fedora-packaging] Re: Re: GTK+ icon cache "bugs" on ScriptletSnippets References: <4513C0AB.50301@post.pl> <4516FDCC.9060309@math.unl.edu> Message-ID: Rex Dieter wrote: > Christopher Stone wrote: >> Just curious, how come KDE doesn't have to >> do such stupid things? > > kde doesn't cache icon themes. To be fair, gtk doesn't *have* to > redo/use gtk-update-icon-cache either, as it will (properly) fall-back > to not using the cache if it is stale (and it'll just be slower, of > course). OK, one more cause to take up with the packaging committee. We should just get the guideline fixed properly once and for all, and leave the gtk2 maintainer to the job of fixing the bug (that's really what we have here, a workaround for a hack/bug). -- Rex From rdieter at math.unl.edu Mon Sep 25 11:59:26 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 25 Sep 2006 06:59:26 -0500 Subject: [Fedora-packaging] Re: Including a static library References: <20060922163646.56974fad@python3.es.egwn.lan> Message-ID: Matthias Saou wrote: > Regarding this bug : https://bugzilla.redhat.com/204568 > > It does makes sense to ship the DirectFB static libraries for some > users. So here are my questions : > - Should they be put into the existing -devel sub-package? > - Should they be put into a new separate sub-package? (-static) As long as the static lib doesn't change the behavior of (most) typical builds using BuildRequires: DirectFB-devel I'd say a separate package is overkill. -- Rex From rc040203 at freenet.de Mon Sep 25 13:38:05 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 25 Sep 2006 15:38:05 +0200 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: References: <20060922163646.56974fad@python3.es.egwn.lan> Message-ID: <1159191485.19391.38.camel@mccallum.corsepiu.local> On Mon, 2006-09-25 at 06:59 -0500, Rex Dieter wrote: > Matthias Saou wrote: > > > Regarding this bug : https://bugzilla.redhat.com/204568 > > > > It does makes sense to ship the DirectFB static libraries for some > > users. So here are my questions : > > - Should they be put into the existing -devel sub-package? > > - Should they be put into a new separate sub-package? (-static) > > As long as the static lib doesn't change the behavior of (most) typical > builds using > BuildRequires: DirectFB-devel > I'd say a separate package is overkill. I'd say packaging static libs into separate *-static packages should be made mandatory to * make such dependencies apparent (otherwise the next maintainer will want to drop them from *-devel and nobody will notice until somebody who can't resist linking against them will yell). * avoid bloating the distro with unnecessary libs (Almost nobody will use them). * make packages providing static libs obvious. Besides this: Is using a userspace library such as DirectFB inside of initrd useful? I hardly can't imagine why. Ralf From rdieter at math.unl.edu Mon Sep 25 13:42:10 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 25 Sep 2006 08:42:10 -0500 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <1159191485.19391.38.camel@mccallum.corsepiu.local> References: <20060922163646.56974fad@python3.es.egwn.lan> <1159191485.19391.38.camel@mccallum.corsepiu.local> Message-ID: <4517DCB2.1050606@math.unl.edu> Ralf Corsepius wrote: > I'd say packaging static libs into separate *-static packages should be > made mandatory to > * make such dependencies apparent (otherwise the next maintainer will > want to drop them from *-devel and nobody will notice until somebody who > can't resist linking against them will yell). > * avoid bloating the distro with unnecessary libs (Almost nobody will > use them). > * make packages providing static libs obvious. Excellent logic (that I previously totally missed, which I will blame on insufficient morning coffee). +1 to Ralf's suggestion for -static pkg. -- Rex From rdieter at math.unl.edu Mon Sep 25 13:36:18 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 25 Sep 2006 08:36:18 -0500 Subject: [Fedora-packaging] Re: Re: GTK+ icon cache "bugs" on ScriptletSnippets References: <4513C0AB.50301@post.pl> <4516FDCC.9060309@math.unl.edu> Message-ID: OK, comments? http://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/iconcache -- Rex From a.badger at gmail.com Mon Sep 25 18:24:21 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 25 Sep 2006 11:24:21 -0700 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <4517DCB2.1050606@math.unl.edu> References: <20060922163646.56974fad@python3.es.egwn.lan> <1159191485.19391.38.camel@mccallum.corsepiu.local> <4517DCB2.1050606@math.unl.edu> Message-ID: <1159208661.3842.0.camel@localhost> On Mon, 2006-09-25 at 08:42 -0500, Rex Dieter wrote: > Ralf Corsepius wrote: > > > I'd say packaging static libs into separate *-static packages should be > > made mandatory to > > * make such dependencies apparent (otherwise the next maintainer will > > want to drop them from *-devel and nobody will notice until somebody who > > can't resist linking against them will yell). > > * avoid bloating the distro with unnecessary libs (Almost nobody will > > use them). > > * make packages providing static libs obvious. > > Excellent logic (that I previously totally missed, which I will blame on > insufficient morning coffee). +1 to Ralf's suggestion for -static pkg. +1 from me as well. -Toshio -------------- 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 dominik at greysector.net Mon Sep 25 20:16:41 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 25 Sep 2006 22:16:41 +0200 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <1159208661.3842.0.camel@localhost> References: <20060922163646.56974fad@python3.es.egwn.lan> <1159191485.19391.38.camel@mccallum.corsepiu.local> <4517DCB2.1050606@math.unl.edu> <1159208661.3842.0.camel@localhost> Message-ID: <20060925201641.GB32723@rathann.pekin.waw.pl> On Monday, 25 September 2006 at 20:24, Toshio Kuratomi wrote: > On Mon, 2006-09-25 at 08:42 -0500, Rex Dieter wrote: > > Ralf Corsepius wrote: > > > > > I'd say packaging static libs into separate *-static packages should be > > > made mandatory to > > > * make such dependencies apparent (otherwise the next maintainer will > > > want to drop them from *-devel and nobody will notice until somebody who > > > can't resist linking against them will yell). > > > * avoid bloating the distro with unnecessary libs (Almost nobody will > > > use them). > > > * make packages providing static libs obvious. > > > > Excellent logic (that I previously totally missed, which I will blame on > > insufficient morning coffee). +1 to Ralf's suggestion for -static pkg. > > +1 from me as well. Finally! Let me point out that PLD has been doing that for YEARS. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From tcallawa at redhat.com Mon Sep 25 20:40:50 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 25 Sep 2006 15:40:50 -0500 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <20060925201641.GB32723@rathann.pekin.waw.pl> References: <20060922163646.56974fad@python3.es.egwn.lan> <1159191485.19391.38.camel@mccallum.corsepiu.local> <4517DCB2.1050606@math.unl.edu> <1159208661.3842.0.camel@localhost> <20060925201641.GB32723@rathann.pekin.waw.pl> Message-ID: <1159216850.8583.213.camel@localhost.localdomain> On Mon, 2006-09-25 at 22:16 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 25 September 2006 at 20:24, Toshio Kuratomi wrote: > > On Mon, 2006-09-25 at 08:42 -0500, Rex Dieter wrote: > > > Ralf Corsepius wrote: > > > > > > > I'd say packaging static libs into separate *-static packages should be > > > > made mandatory to > > > > * make such dependencies apparent (otherwise the next maintainer will > > > > want to drop them from *-devel and nobody will notice until somebody who > > > > can't resist linking against them will yell). > > > > * avoid bloating the distro with unnecessary libs (Almost nobody will > > > > use them). > > > > * make packages providing static libs obvious. > > > > > > Excellent logic (that I previously totally missed, which I will blame on > > > insufficient morning coffee). +1 to Ralf's suggestion for -static pkg. > > > > +1 from me as well. > > Finally! Let me point out that PLD has been doing that for YEARS. -static subpackages have always seemed to make sense to me, but it was pointed out to me originally that increasing the number of subpackages increases the size of the metadata and makes all yum operations slower. Thoughts? Perhaps a separate -static repo? ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From notting at redhat.com Mon Sep 25 20:53:46 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 25 Sep 2006 16:53:46 -0400 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <1159216850.8583.213.camel@localhost.localdomain> References: <20060922163646.56974fad@python3.es.egwn.lan> <1159191485.19391.38.camel@mccallum.corsepiu.local> <4517DCB2.1050606@math.unl.edu> <1159208661.3842.0.camel@localhost> <20060925201641.GB32723@rathann.pekin.waw.pl> <1159216850.8583.213.camel@localhost.localdomain> Message-ID: <20060925205345.GA17994@nostromo.devel.redhat.com> Tom 'spot' Callaway (tcallawa at redhat.com) said: > -static subpackages have always seemed to make sense to me, but it was > pointed out to me originally that increasing the number of subpackages > increases the size of the metadata and makes all yum operations slower. > > Thoughts? Perhaps a separate -static repo? Depends on how many. I believe the idea is not to package *all* static libs.... Bill From skvidal at linux.duke.edu Mon Sep 25 21:00:24 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 25 Sep 2006 17:00:24 -0400 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <1159216850.8583.213.camel@localhost.localdomain> References: <20060922163646.56974fad@python3.es.egwn.lan> <1159191485.19391.38.camel@mccallum.corsepiu.local> <4517DCB2.1050606@math.unl.edu> <1159208661.3842.0.camel@localhost> <20060925201641.GB32723@rathann.pekin.waw.pl> <1159216850.8583.213.camel@localhost.localdomain> Message-ID: <1159218024.31916.35.camel@cutter> On Mon, 2006-09-25 at 15:40 -0500, Tom 'spot' Callaway wrote: > On Mon, 2006-09-25 at 22:16 +0200, Dominik 'Rathann' Mierzejewski wrote: > > On Monday, 25 September 2006 at 20:24, Toshio Kuratomi wrote: > > > On Mon, 2006-09-25 at 08:42 -0500, Rex Dieter wrote: > > > > Ralf Corsepius wrote: > > > > > > > > > I'd say packaging static libs into separate *-static packages should be > > > > > made mandatory to > > > > > * make such dependencies apparent (otherwise the next maintainer will > > > > > want to drop them from *-devel and nobody will notice until somebody who > > > > > can't resist linking against them will yell). > > > > > * avoid bloating the distro with unnecessary libs (Almost nobody will > > > > > use them). > > > > > * make packages providing static libs obvious. > > > > > > > > Excellent logic (that I previously totally missed, which I will blame on > > > > insufficient morning coffee). +1 to Ralf's suggestion for -static pkg. > > > > > > +1 from me as well. > > > > Finally! Let me point out that PLD has been doing that for YEARS. > > -static subpackages have always seemed to make sense to me, but it was > pointed out to me originally that increasing the number of subpackages > increases the size of the metadata and makes all yum operations slower. > > Thoughts? Perhaps a separate -static repo? To be fair - the yum operations for fc6 should be fairly dramatically sped up. Menno, Tambet and others have done some really good work to get rid of slow sections of code or repetitive pieces. -sv From katzj at redhat.com Mon Sep 25 21:23:18 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 25 Sep 2006 17:23:18 -0400 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <1159218024.31916.35.camel@cutter> References: <20060922163646.56974fad@python3.es.egwn.lan> <1159191485.19391.38.camel@mccallum.corsepiu.local> <4517DCB2.1050606@math.unl.edu> <1159208661.3842.0.camel@localhost> <20060925201641.GB32723@rathann.pekin.waw.pl> <1159216850.8583.213.camel@localhost.localdomain> <1159218024.31916.35.camel@cutter> Message-ID: <1159219398.7697.10.camel@orodruin.boston.redhat.com> On Mon, 2006-09-25 at 17:00 -0400, seth vidal wrote: > On Mon, 2006-09-25 at 15:40 -0500, Tom 'spot' Callaway wrote: > > -static subpackages have always seemed to make sense to me, but it was > > pointed out to me originally that increasing the number of subpackages > > increases the size of the metadata and makes all yum operations slower. > > > > Thoughts? Perhaps a separate -static repo? Ugh, separate repo is a nitemare from the point of view of installation and the build system[1] > To be fair - the yum operations for fc6 should be fairly dramatically > sped up. Menno, Tambet and others have done some really good work to get > rid of slow sections of code or repetitive pieces. Sadly, we can't really speed up the download of bits. And _that_ is where this hurts us. There have been a lot of good speedups in yum; let's not go and ruin that by making people have to download and process more data Jeremy [1] And if it doesn't matter for these cases, then I argue they shouldn't be packaged _at all_. Because there isn't any way people are going to get to them From skvidal at linux.duke.edu Mon Sep 25 23:09:06 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 25 Sep 2006 19:09:06 -0400 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <1159219398.7697.10.camel@orodruin.boston.redhat.com> References: <20060922163646.56974fad@python3.es.egwn.lan> <1159191485.19391.38.camel@mccallum.corsepiu.local> <4517DCB2.1050606@math.unl.edu> <1159208661.3842.0.camel@localhost> <20060925201641.GB32723@rathann.pekin.waw.pl> <1159216850.8583.213.camel@localhost.localdomain> <1159218024.31916.35.camel@cutter> <1159219398.7697.10.camel@orodruin.boston.redhat.com> Message-ID: <1159225746.1544.3.camel@cutter> On Mon, 2006-09-25 at 17:23 -0400, Jeremy Katz wrote: > On Mon, 2006-09-25 at 17:00 -0400, seth vidal wrote: > > On Mon, 2006-09-25 at 15:40 -0500, Tom 'spot' Callaway wrote: > > > -static subpackages have always seemed to make sense to me, but it was > > > pointed out to me originally that increasing the number of subpackages > > > increases the size of the metadata and makes all yum operations slower. > > > > > > Thoughts? Perhaps a separate -static repo? > > Ugh, separate repo is a nitemare from the point of view of installation > and the build system[1] > > > To be fair - the yum operations for fc6 should be fairly dramatically > > sped up. Menno, Tambet and others have done some really good work to get > > rid of slow sections of code or repetitive pieces. > > Sadly, we can't really speed up the download of bits. And _that_ is > where this hurts us. There have been a lot of good speedups in yum; > let's not go and ruin that by making people have to download and process > more data okay - I didn't understand where we were thinking about slowness. thanks. -sv From rc040203 at freenet.de Tue Sep 26 04:54:16 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 26 Sep 2006 06:54:16 +0200 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <20060925205345.GA17994@nostromo.devel.redhat.com> References: <20060922163646.56974fad@python3.es.egwn.lan> <1159191485.19391.38.camel@mccallum.corsepiu.local> <4517DCB2.1050606@math.unl.edu> <1159208661.3842.0.camel@localhost> <20060925201641.GB32723@rathann.pekin.waw.pl> <1159216850.8583.213.camel@localhost.localdomain> <20060925205345.GA17994@nostromo.devel.redhat.com> Message-ID: <1159246456.19391.67.camel@mccallum.corsepiu.local> On Mon, 2006-09-25 at 16:53 -0400, Bill Nottingham wrote: > Tom 'spot' Callaway (tcallawa at redhat.com) said: > > -static subpackages have always seemed to make sense to me, but it was > > pointed out to me originally that increasing the number of subpackages > > increases the size of the metadata and makes all yum operations slower. > > > > Thoughts? Perhaps a separate -static repo? > > Depends on how many. I believe the idea is not to package *all* > static libs.... Exactly, but isn't it apparent that we need measures to enforce this rule to shift the threshold to maintainers to be wanting to ship static libs? So far, FE package maintainers are ignoring this rule, some are hostile against this, rpmlint doesn't warn about them, but ... RH/FC doesn't actually do better. At least on my installations the major of static libs originate from FC. How about RH behaving as a positive example and to start abandoning static libs in FC? Ralf From jkeating at redhat.com Tue Sep 26 14:35:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 26 Sep 2006 10:35:58 -0400 Subject: [Fedora-packaging] Re: Including a static library In-Reply-To: <1159246456.19391.67.camel@mccallum.corsepiu.local> References: <20060922163646.56974fad@python3.es.egwn.lan> <20060925205345.GA17994@nostromo.devel.redhat.com> <1159246456.19391.67.camel@mccallum.corsepiu.local> Message-ID: <200609261035.58270.jkeating@redhat.com> On Tuesday 26 September 2006 00:54, Ralf Corsepius wrote: > ... RH/FC doesn't actually do better. At least on my installations the > major of static libs originate from FC. How about RH behaving as a > positive example and to start abandoning static libs in FC? Keep filing bugs. The majority of RH packages came before the guidelines, please try to continue to remember this. There is a lot of crud in the RH packages, but unless bugs are filed or effort is put into clean it up, it won't get cleaned up. Unfortunately a lot of RH packagers don't pay attention to whats going on, especially if they're mostly doing RHEL updates and just using Fedora as a inroad to RHEL. So file bugs, point out the guidelines and get the packagers attention. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Sep 26 15:51:13 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Sep 2006 10:51:13 -0500 Subject: [Fedora-packaging] desktop-file-install --vendor=... proposal, comments? Message-ID: <45194C71.2080400@math.unl.edu> See http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles Comments? -- Rex From rdieter at math.unl.edu Tue Sep 26 15:53:25 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Sep 2006 10:53:25 -0500 Subject: [Fedora-packaging] libtool(.la) archive policy proposal Message-ID: <45194CF5.3090509@math.unl.edu> See http://fedoraproject.org/wiki/PackagingDrafts/LibtoolArchives Comments? -- Rex From tibbs at math.uh.edu Tue Sep 26 16:49:24 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 26 Sep 2006 11:49:24 -0500 Subject: [Fedora-packaging] desktop-file-install --vendor=... proposal, comments? In-Reply-To: <45194C71.2080400@math.unl.edu> (Rex Dieter's message of "Tue, 26 Sep 2006 10:51:13 -0500") References: <45194C71.2080400@math.unl.edu> Message-ID: For some reason that confuses me a bit. The first line after the example says "we're going to talk about --vendor in the context of the menu spec", then the first item says not to use --vendor at all and the second item talks about KDE and --dir. Plus, I'm not sure how I'm supposed to know if the upstream provides vendor_id. How about three examples: Proposed desktop-file-install examples: If upstream provides a desktop file, does it include "Vendor:" (or however I'm supposed to know that it specifies vendor_id:)? If so, use this: [[ blah ]] KDE applications not falling into the above category should use the following: (or put this first if KDE-ness overrides the other options) [[ blah ]] Otherwise, use the following: [[ blah ]] From rdieter at math.unl.edu Tue Sep 26 16:52:40 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Sep 2006 11:52:40 -0500 Subject: [Fedora-packaging] desktop-file-install --vendor=... proposal, comments? In-Reply-To: References: <45194C71.2080400@math.unl.edu> Message-ID: <45195AD8.3020204@math.unl.edu> Jason L Tibbitts III wrote: > For some reason that confuses me a bit. The first line after the > example says "we're going to talk about --vendor in the context of the > menu spec", then the first item says not to use --vendor at all and > the second item talks about KDE and --dir. In the context of --vendor, using a subdir is (relatively) equivalent. > Plus, I'm not sure how I'm supposed to know if the upstream provides > vendor_id. If the .desktop filenames are either of the form: vendor/foo.desktop or vendor-foo.desktop then upstream is providing them. Does that help? -- Rex From tibbs at math.uh.edu Tue Sep 26 16:58:24 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 26 Sep 2006 11:58:24 -0500 Subject: [Fedora-packaging] libtool(.la) archive policy proposal In-Reply-To: <45194CF5.3090509@math.unl.edu> (Rex Dieter's message of "Tue, 26 Sep 2006 10:53:25 -0500") References: <45194CF5.3090509@math.unl.edu> Message-ID: You should probably also mention /etc/ld.so.conf.d. I hope it's not necessary to note specifically that a package can't have .la files in directories that it adds to the ld search path. - J< From tibbs at math.uh.edu Tue Sep 26 17:15:05 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 26 Sep 2006 12:15:05 -0500 Subject: [Fedora-packaging] desktop-file-install --vendor=... proposal, comments? In-Reply-To: <45195AD8.3020204@math.unl.edu> (Rex Dieter's message of "Tue, 26 Sep 2006 11:52:40 -0500") References: <45194C71.2080400@math.unl.edu> <45195AD8.3020204@math.unl.edu> Message-ID: >>>>> "RD" == Rex Dieter writes: RD> Does that help? Well, perhaps, but any such explanation needs to be part of or referred to by the guideline. - J< From rdieter at math.unl.edu Tue Sep 26 17:15:40 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Sep 2006 12:15:40 -0500 Subject: [Fedora-packaging] Re: desktop-file-install --vendor=... proposal, comments? References: <45194C71.2080400@math.unl.edu> Message-ID: Jason L Tibbitts III wrote: > For some reason that confuses me a bit. The first line after the > example says "we're going to talk about --vendor in the context of the > menu spec", then the first item says not to use --vendor at all and > the second item talks about KDE and --dir. > > Plus, I'm not sure how I'm supposed to know if the upstream provides > vendor_id. OK, I updated the draft to include 2 examples, one using --vendor= the other using --dir=%buildroot%_datadir/applications/ --vendor="" and included language from the spec describing the difference (hopefully): ------------------- To prevent that a desktop entry from one party inadvertently cancels out the desktop entry from another party because both happen to get the same desktop-file id it is recommended that providers of desktop-files ensure that all desktop-file ids start with a vendor prefix... Please namespace the filename, as in "vendor-foo.desktop", or use a subdirectory of datadir/applications/ so you have "vendor/foo.desktop"... ----------------- -- Rex From rdieter at math.unl.edu Tue Sep 26 17:17:54 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Sep 2006 12:17:54 -0500 Subject: [Fedora-packaging] Re: libtool(.la) archive policy proposal References: <45194CF5.3090509@math.unl.edu> Message-ID: Jason L Tibbitts III wrote: > You should probably also mention /etc/ld.so.conf.d. Since that's (should be!) already referenced in /etc/ld.so.conf, I figured it didn't need to be explictly mentioned. Maybe I was being too optimistic. > I hope it's not > necessary to note specifically that a package can't have .la files in > directories that it adds to the ld search path. I hope that too. (: -- Rex From opensource at till.name Tue Sep 26 17:34:58 2006 From: opensource at till.name (Till Maas) Date: Tue, 26 Sep 2006 19:34:58 +0200 Subject: [Fedora-packaging] desktop-file-install --vendor=... proposal, comments? In-Reply-To: <45194C71.2080400@math.unl.edu> References: <45194C71.2080400@math.unl.edu> Message-ID: <200609261935.05860.opensource@till.name> On Tuesday 26 September 2006 17:51, Rex Dieter wrote: > See > http://fedoraproject.org/wiki/PackagingDrafts/DesktopFiles > > Comments? It's not about desktop-file-install but about the desktop-file itself: I propose to provide some guidelines about the contents of a desktop-file, e.g. that they should not contain paths in the Exec entry and should provide a StartupWMClass entry. Another issue is, which / how many Categories should be added, every categores that fits like for example "Application;AudioVideo;Audio;Midi;Music;" for an midi application that generates midis or only some of them? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Tue Sep 26 17:43:27 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 26 Sep 2006 12:43:27 -0500 Subject: [Fedora-packaging] Re: desktop-file-install --vendor=... proposal, comments? References: <45194C71.2080400@math.unl.edu> <200609261935.05860.opensource@till.name> Message-ID: Till Maas wrote: > It's not about desktop-file-install Well, *this* proposal is limited in scope only to the use of desktop-file-install. > >but about the desktop-file itself: > I propose to provide some guidelines about the contents of a desktop-file, > e.g. that they should not contain paths in the Exec entry and should > provide a StartupWMClass entry. Another issue is, which / how many > Categories should be added, every categores that fits like for > example "Application;AudioVideo;Audio;Midi;Music;" for an midi application > that generates midis or only some of them? Agreed, some extra guidelines should be written to cover these topics as well. Are you volunteering? (: -- Rex From tcallawa at redhat.com Wed Sep 27 20:38:26 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Sep 2006 15:38:26 -0500 Subject: [Fedora-packaging] Absent (Sep 28, 2006) Message-ID: <1159389506.3227.66.camel@dhcp-32-122.ord.redhat.com> Dear Teacher, Spot will not be able to attend tomorrows FESCO and Fedora Packaging Committee meetings because he has to go sell Linux to unsuspecting companies in Indianapolis. Please excuse him from his duties for the day. Thanks, ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From paul at all-the-johnsons.co.uk Wed Sep 27 21:07:06 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 27 Sep 2006 22:07:06 +0100 Subject: [Fedora-packaging] MS shared source license Message-ID: <1159391227.3901.31.camel@T7.Linux> Hi, I've packaged IronPython and it's quite happy here. However, it looks like the license is the MS shared source one. Is it worth even submitting it for FE review? TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- 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 Wed Sep 27 21:33:53 2006 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Sep 2006 16:33:53 -0500 Subject: [Fedora-packaging] MS shared source license In-Reply-To: <1159391227.3901.31.camel@T7.Linux> References: <1159391227.3901.31.camel@T7.Linux> Message-ID: <1159392833.3227.77.camel@dhcp-32-122.ord.redhat.com> On Wed, 2006-09-27 at 22:07 +0100, Paul wrote: > Hi, > > I've packaged IronPython and it's quite happy here. However, it looks > like the license is the MS shared source one. Is it worth even > submitting it for FE review? Nope. FSF calls it out as Non-Free, and its not on the OSI list. Sorry. :/ ~spot -- Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260 "We must not confuse dissent with disloyalty. We must remember always that accusation is not proof and that conviction depends upon evidence and due process of law. We will not walk in fear, one of another. We will not be driven by fear into an age of unreason, if we dig deep in our history and our doctrine, and remember that we are not descended from fearful men -- not from men who feared to write, to speak, to associate and to defend causes that were, for the moment, unpopular." -- Edward R. Murrow, March 9, 1954 From paul at all-the-johnsons.co.uk Wed Sep 27 21:35:01 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 27 Sep 2006 22:35:01 +0100 Subject: [Fedora-packaging] MS shared source license In-Reply-To: <1159392833.3227.77.camel@dhcp-32-122.ord.redhat.com> References: <1159391227.3901.31.camel@T7.Linux> <1159392833.3227.77.camel@dhcp-32-122.ord.redhat.com> Message-ID: <1159392901.3901.32.camel@T7.Linux> Hi, > > I've packaged IronPython and it's quite happy here. However, it looks > > like the license is the MS shared source one. Is it worth even > > submitting it for FE review? > > Nope. FSF calls it out as Non-Free, and its not on the OSI list. Thought that would be the case. I think I'll package it and put it on my home website for folks to use. Seems a pity, but that's the way it smells! TTFN Paul -- "Der einzige Weg, Leute zu kontrollieren ist sie anzul?gen" - L. Ron "Ich kann kein Science-Fiction schreiben" Hubbard; L?gner, Betr?ger, Fixer und Wohlt?ter zu niemandem -------------- 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 Jochen at herr-schmitt.de Thu Sep 28 14:19:00 2006 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 28 Sep 2006 16:19:00 +0200 Subject: [Fedora-packaging] MS shared source license In-Reply-To: <1159392901.3901.32.camel@T7.Linux> References: <1159391227.3901.31.camel@T7.Linux> <1159392833.3227.77.camel@dhcp-32-122.ord.redhat.com> <1159392901.3901.32.camel@T7.Linux> Message-ID: <0ML29c-1GSwjT0NPj-00004x@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 27 Sep 2006 22:35:01 +0100, you wrote: >Thought that would be the case. I think I'll package it and put it on my >home website for folks to use. Seems a pity, but that's the way it >smells! Perhaps you should talk with the folks of rpm.livna.org. They host packaging which are not arcodrding the requirements of Fedora Extras like the nvidia closed source driver or packages with mp3 support. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.6 (Build 6060) iQA/AwUBRRvZ5k9gByurcX4MEQKj+ACgu89EKTPFzcYv56CpEAQQqyPaXBkAn05F d0xipzGPWZPgoPunHo7Zn1VK =RvLp -----END PGP SIGNATURE----- From rdieter at math.unl.edu Thu Sep 28 14:45:05 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 28 Sep 2006 09:45:05 -0500 Subject: [Fedora-packaging] Re: MS shared source license References: <1159391227.3901.31.camel@T7.Linux> <1159392833.3227.77.camel@dhcp-32-122.ord.redhat.com> <1159392901.3901.32.camel@T7.Linux> <0ML29c-1GSwjT0NPj-00004x@mrelayeu.kundenserver.de> Message-ID: Jochen Schmitt wrote: > On Wed, 27 Sep 2006 22:35:01 +0100, you wrote: > >>Thought that would be the case. I think I'll package it and put it on my >>home website for folks to use. Seems a pity, but that's the way it >>smells! > > Perhaps you should talk with the folks of rpm.livna.org. They > host packaging which are not arcodrding the requirements of > Fedora Extras like the nvidia closed source driver or packages > with mp3 support. Uh, exactly. livna.org != fedoraproject.org They have no affiliation with Fedora, so they (can and do) play by their own rules. -- Rex