From a.badger at gmail.com Wed Apr 1 19:04:04 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 01 Apr 2009 12:04:04 -0700 Subject: [Fedora-packaging] How to package a patched older version of libvmime in Fedora best? In-Reply-To: <20090328204153.GA11515@hurricane.linuxnetz.de> References: <20090328204153.GA11515@hurricane.linuxnetz.de> Message-ID: <49D3BAA4.9070204@gmail.com> Robert Scheck wrote: > Good evening, > > I've the situation, that a package unluckily requires an older version of > libvmime and some specific/individual patches as well. The question is now, > how to package that best for Fedora and EPEL? > > What I'm requiring is libvmime 0.7.1 + patches, while upstream is at 0.9.1 > which is unluckily ABI and API incompatible. > > There are now multiple solutions how to deal with this as I can't use 0.9.1 > now and in foreseeable future: > > a) Build libvmime 0.7.1 + patches in before of the software requiring it > and link statically against it. This would make sense in this case, even > if static linking is discouraged in Fedora, but nothing except that > piece of software requires actually libvmime 0.7.1 + individual patches. > > b) Build libvmime 0.7.1 + patches as own package and call it e.g. something > like foobar-libvmime and rename libvmime.so.* to foobar-libvmime.so.* or > similar. That would bring me to -lfoobar-libvmime linking or something > similar, right? > > Just providing a compat-libvmime seems not suitable, as compat-* in Fedora > is only providing the library, not -devel stuff which is actually needed to > build the other software requiring the old libvmime 0.7.1 + patches. > > As of overlapping *.so filenames, it is not possible to avoid renaming the > patched version. Question is, which is better and which one will go through > the package review or are there better ideas how to solve this? > > Yes, some far day, upstream will accept all of the individual patches and > the other software will support latest libvmime version, but this won't be > in the next time as libvmime support is somehow seemingly less interested > in being backward compatible. > In general, my order of preference would be: 1) Port the application to the latest version of libvmime. If libvmime-0.9 has bugs, get those bugs fixed/patched against that version. This is part of Fedora's mission to push open source forward. 2) Use the -release flag to libtool in order to add 0.7 to the SONAME of the library [1]_ and ship that as libvmime0.7-0.7.1. 3) Change the name of the library to reflect that this isn't the same as the trunk vmime (like, libfoo-vmime) Note that I checked upstream for vmime: http://www.vmime.org/download/ and their sourceforge page as well. There's no links to 0.7.1 and 0.8.0 was released in 2005. This tells me that using vmime-0.7.1 is a very bad idea unless you explicitly fork. If you're willing to fork and become upstream for the new library, I'd recommend taking route #2 (if upstream will let you distribute your fixed copies from the vmime.org website/sourceforge pages) or #3 if you're going to start competing with vmime. .. _[1]: http://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html#Release-numbers -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From caillon at redhat.com Wed Apr 1 20:14:30 2009 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 01 Apr 2009 13:14:30 -0700 Subject: [Fedora-packaging] How to package a patched older version of libvmime in Fedora best? In-Reply-To: <20090328204153.GA11515@hurricane.linuxnetz.de> References: <20090328204153.GA11515@hurricane.linuxnetz.de> Message-ID: <49D3CB26.1020504@redhat.com> On 03/28/2009 01:41 PM, Robert Scheck wrote: > Yes, some far day, upstream will accept all of the individual patches If upstream is not accepting patches, that calls to question whether we want to include this software at all... May I ask what specific package you are trying to include that refuses to use a newer libvmime? From debayanin at gmail.com Wed Apr 1 21:38:00 2009 From: debayanin at gmail.com (Debayan Banerjee) Date: Thu, 2 Apr 2009 03:08:00 +0530 Subject: [Fedora-packaging] Need advice pertaining to GSoC proposal Message-ID: Dear List, I need some feedback on the feasibility of the proposal below from this list. ADDING ONE CLICK INSTALL SUPPORT TO FEDORA (Package-Kit in effect) To install a package x in Fedora one has to add the repository via the command line (or gui) and then type "yum install x" to get the package installed. In the one-click-install feature we have an xml file per-package which contains information in it such as package name,version,repository links (for installing further dependencies), GPG key etc. One may upload these xml files on the web and an user may click on these xml files in a browser. Once downloaded the a parser parses the contents of the file and automatically adds the requisite repositories and downloads requisite packages for dependency preservation. I have been discussing this topic simultaneously on 2 lists because of the nature of the problem. Here are the 2 threads: [1] http://lists.freedesktop.org/archives/packagekit/2009-March/004569.html [2] http://groups.google.com/group/redhat-summer/browse_thread/thread/50de9e16d5407b9c I think its time to summarise my proposal. The way I see it, there are 4 things to do: 1) Add .oci support to package-kit. 2) Add pluggable policies 3) Add voting system to package manager 4) A server that receives these votes and maintains a list of repos in sorted order. The distro maintains this. Leave it to the user which repo he wants to add now. Explanation: 1)Add .oci support to package-kit: This involves adding C code to Package-Kit. Much of the work has been done by Dorian Perkins and is available at http://www.cs.ucr.edu/~dperkins/projects/pk-oci/. 2)Pluggable Policies: The policy of what to allow to install will not be agreed across all distributions. So instead of discussing a policy that will never get unanimous approval the install policy pluggable, and allowing the distribution to choose the policy may be better. Some example policies would be * Only allow packages in the distribution itself * Only allow packages that are whitelisted or in whitelisted repository * Allow installation of anything that is not on a blacklist * Allow installation of anything" (In words of Benji Webber) 3) Add voting system to Package Manager: The word trust has to mean something that the end user understands, as opposed to GPG keys. One way of defining trust is by votes. It is my proposal that we enable a voting system at the package manager end so that every time a repository is added and a package installed for the first time users are asked for a "Recommend" vs "Do not recommend" vote. Conversely, every time a user disables/removes a repository he is asked whether he votes "Do not recommend". These votes go to a centrallised server I was advised on the Fedora list by Patrick Barnes to use the voting approach. I thought it made sense since it will keep evil people (repositories) away the same way wikipedia protects itself from evil people. Also there may be admins, like me, who shall ban a particular repository from the listings if it is found to be a malicious repository. If a repo is evil, there *will* be several "do not recommend" votes to it too which will attract attention. 4) A server that receives votes and maintains a listing of repositories in sorted order: We could make modifications to so that it provides one-click-install links to all packages thus. Similar efforts are at: [1] http://www.apturl.net/ [2] http://packages.opensuse-community.org/ [3] http://www.allmyapps.com/ I can set up a prototype server which accepts these votes and displays reposiories/packages accordingly. Once I have successfully built all the things I have mentioned, I dont mind buying hosting space to host it as a proof of concept. -- Be Intelligent, Use GNU/Linux http://debayanin.googlepages.com/ http://debayan.wordpress.com http://lug.nitdgp.ac.in From robert at fedoraproject.org Thu Apr 2 18:11:49 2009 From: robert at fedoraproject.org (Robert Scheck) Date: Thu, 2 Apr 2009 20:11:49 +0200 Subject: [Fedora-packaging] How to package a patched older version of libvmime in Fedora best? In-Reply-To: <49D3BAA4.9070204@gmail.com> References: <20090328204153.GA11515@hurricane.linuxnetz.de> <49D3BAA4.9070204@gmail.com> Message-ID: <20090402181149.GA30302@hurricane.linuxnetz.de> On Wed, 01 Apr 2009, Toshio Kuratomi wrote: > 1) Port the application to the latest version of libvmime. If > libvmime-0.9 has bugs, get those bugs fixed/patched against that > version. This is part of Fedora's mission to push open source forward. Well, porting isn't that easy, as libvmime seemingly got really massive and huge code changes including rewrites and the API (is according to the developers) completely incompatible between 0.7 <-> 0.8 <-> 0.9, thus it's not just some code moving or similar but also a heavy rewrite of the mail client using the libvmime. > 2) Use the -release flag to libtool in order to add 0.7 to the SONAME of > the library [1]_ and ship that as libvmime0.7-0.7.1. > 3) Change the name of the library to reflect that this isn't the same as > the trunk vmime (like, libfoo-vmime) Personally, I don't want to fork libvmime. More or less that already has been done by the patches. But the guys who've written the patches are not really interested in maintaining soname, API etc. as they just require the patched libvmime to get their mail client doing what they need to do. On the other hand, the original libvmime has a public API, soname and all that stuff. So why can't I just put the patched libvmime in the same mail client package, build it there static at the beginning and afterwards link the mail client against it? Again, as it's anyway a patched libvmime, it looks like nothing except the mail client seems to be able to use the library... > Note that I checked upstream for vmime: http://www.vmime.org/download/ > and their sourceforge page as well. There's no links to 0.7.1 and 0.8.0 > was released in 2005. This tells me that using vmime-0.7.1 is a very > bad idea unless you explicitly fork. As written above, it is already more or less a fork, but the guys don't see any real need to rename or much interest to maintain API, soname etc. For them it just works with their own more or less forking-patches currently. Greetings, Robert From tcallawa at redhat.com Thu Apr 2 18:13:57 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 02 Apr 2009 14:13:57 -0400 Subject: [Fedora-packaging] How to package a patched older version of libvmime in Fedora best? In-Reply-To: <20090402181149.GA30302@hurricane.linuxnetz.de> References: <20090328204153.GA11515@hurricane.linuxnetz.de> <49D3BAA4.9070204@gmail.com> <20090402181149.GA30302@hurricane.linuxnetz.de> Message-ID: <49D50065.6000800@redhat.com> On 04/02/2009 02:11 PM, Robert Scheck wrote: > As written above, it is already more or less a fork, but the guys don't see > any real need to rename or much interest to maintain API, soname etc. For > them it just works with their own more or less forking-patches currently. This is great until there is a security issue or a bug fix that doesn't make into this copy. The "toss random patches against old versions of libraries and carry them forever" is a plan for disaster. We shouldn't be encouraging it. ~spot From robert at fedoraproject.org Thu Apr 2 18:47:07 2009 From: robert at fedoraproject.org (Robert Scheck) Date: Thu, 2 Apr 2009 20:47:07 +0200 Subject: [Fedora-packaging] How to package a patched older version of libvmime in Fedora best? In-Reply-To: <49D50065.6000800@redhat.com> References: <20090328204153.GA11515@hurricane.linuxnetz.de> <49D3BAA4.9070204@gmail.com> <20090402181149.GA30302@hurricane.linuxnetz.de> <49D50065.6000800@redhat.com> Message-ID: <20090402184707.GA2153@hurricane.linuxnetz.de> On Thu, 02 Apr 2009, Tom spot Callaway wrote: > This is great until there is a security issue or a bug fix that doesn't > make into this copy. Okay, as per our talk in IRC, I will use app-libvmime or libvmime-app as package name and thus play with the -release possibility of libtool to get libvmime soname changed. [20:18:22] < rsc> spot: that's worse argumenting IMHO ;) [20:18:39] < rsc> spot: if it's "officially" forked, same can happen anyway. [20:19:14] < spot> rsc: yes, but in those cases, upstream is usually making other changes and there is less likelyhood of overlap in issues [20:19:29] < spot> (it's also less obvious to l33t hax0rs) [20:20:54] < rsc> spot: as upstream is focussed to rewriting code and API from 0.x to 0.x+1, I guess, upstream less cares about current 0.x-2 [20:21:34] < rsc> spot: means, I'm in doubt regarding whether security fixes (if there's one) really a) applies and b) is relevant at all. [20:22:39] < spot> rsc: again, since it would be buried in a dependent package, no one will know to look until it is too late. [20:22:58] < spot> the correct answer is "port it to the current library" [20:23:19] < spot> the slightly acceptable compromise answer is "rename the library, make it standalone" [20:23:46] < rsc> spot: and who will do that huge amount of work again and again for every 0.x+1 release of upstream? [20:24:21] < spot> coding is hard, lets go shopping. [20:24:40] < rsc> spot: second thing means forking in other words, right? [20:24:58] < spot> rsc: upstream forked the moment they decided to bundle a patched library. [20:25:12] < spot> you'd just be making a more managable, visible fork. [20:25:29] < rsc> spot: "just", exactly. [20:25:57] < rsc> spot: okay, that means, I better should simply go for libvmime0.7.so.0.7.1? [20:26:25] < spot> rsc: sure. [20:26:39] < spot> rsc: as a separate package, preferrably. [20:27:50] < rsc> spot: okay. Any suggestions how to %{name} the package? libvmime07? [20:28:22] < spot> well, given that it has specific patches for one app, i might incorporate the name of that app [20:28:34] < rsc> spot: okay, so app-libvmime? [20:30:54] < spot> rsc: or libvmime-app [20:32:03] < rsc> spot: any opinion which is better? AFAIK we not really have a guideline for that. Personally I would tend to app-libvmime to make visible where it belongs to. But I can life with both. [20:32:26] < spot> i wouldn't lose sleep over either honestly. [20:32:32] < spot> your call [20:33:05] < rsc> okay, then I'll throw a dice, once I come to that. Greetings, Robert From lkundrak at v3.sk Thu Apr 2 21:11:50 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Thu, 02 Apr 2009 23:11:50 +0200 Subject: [Fedora-packaging] How to package a patched older version of libvmime in Fedora best? In-Reply-To: <49D50065.6000800@redhat.com> References: <20090328204153.GA11515@hurricane.linuxnetz.de> <49D3BAA4.9070204@gmail.com> <20090402181149.GA30302@hurricane.linuxnetz.de> <49D50065.6000800@redhat.com> Message-ID: <1238706710.3036.14.camel@localhost.localdomain> On Thu, 2009-04-02 at 14:13 -0400, Tom "spot" Callaway wrote: > On 04/02/2009 02:11 PM, Robert Scheck wrote: > > As written above, it is already more or less a fork, but the guys don't see > > any real need to rename or much interest to maintain API, soname etc. For > > them it just works with their own more or less forking-patches currently. > > This is great until there is a security issue or a bug fix that doesn't > make into this copy. Well, not much of an issue if it has a caring and responsive maintainer. The Security Response team tracks also embedded and old copies and notifies their maintainers. There's no chance of fixing the security issue with "dumb luck" of bumping the package to newer release but I suspect that's nothing we want to rely on anyways. > The "toss random patches against old versions of libraries and carry > them forever" is a plan for disaster. We shouldn't be encouraging it. I can imagine that sticking to earlier release can be quite logical reaction when upstream keeps changing the API incompatibly. I don't know anything about this specific case though. (Oh,by the way, I remember porting balsa to newer version of some gnome mime library a couple of weeks ago. If this is the same library; they provide a shell script that tries to do most of the changes automatically. I discovered it when I was done with my patch... I could still verify. Anyways, if this is it, it might help you) -- "Excuse all the blood" -- Dead From ianweller at gmail.com Thu Apr 2 23:39:46 2009 From: ianweller at gmail.com (Ian Weller) Date: Thu, 2 Apr 2009 18:39:46 -0500 Subject: [Fedora-packaging] wordpress guidelines -- ping? Message-ID: <20090402233946.GA16227@gmail.com> During the most recent meeting it was decided that I would be contacted about a few issues with the WordPress plugin packaging guidelines; https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_guidelines_(draft) I wasn't contacted, but I did ask spot what the issue was, and he reported that we needed to know if there would be a case where the plugin may not function on either platform (mu or lack thereof). The answer is a strong "yes" from upstream. What are we waiting on? Is a list vote possible to get this moving along? -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From a.badger at gmail.com Fri Apr 3 00:17:59 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 02 Apr 2009 17:17:59 -0700 Subject: [Fedora-packaging] wordpress guidelines -- ping? In-Reply-To: <20090402233946.GA16227@gmail.com> References: <20090402233946.GA16227@gmail.com> Message-ID: <49D555B7.4030608@gmail.com> Ian Weller wrote: > During the most recent meeting it was decided that I would be contacted > about a few issues with the WordPress plugin packaging guidelines; > https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_guidelines_(draft) > > I wasn't contacted, but I did ask spot what the issue was, and he > reported that we needed to know if there would be a case where the > plugin may not function on either platform (mu or lack thereof). The > answer is a strong "yes" from upstream. > How do we tell when the plugin doesn't function? If we can write that down in the guidelines, it will help stop people from using the template to create wordpress and mu plugins when the plugin only works on one platform. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ianweller at gmail.com Fri Apr 3 01:39:18 2009 From: ianweller at gmail.com (Ian Weller) Date: Thu, 2 Apr 2009 20:39:18 -0500 Subject: [Fedora-packaging] wordpress guidelines -- ping? In-Reply-To: <49D555B7.4030608@gmail.com> References: <20090402233946.GA16227@gmail.com> <49D555B7.4030608@gmail.com> Message-ID: <20090403013918.GB19739@gmail.com> On Thu, Apr 02, 2009 at 05:17:59PM -0700, Toshio Kuratomi wrote: > Ian Weller wrote: > > During the most recent meeting it was decided that I would be contacted > > about a few issues with the WordPress plugin packaging guidelines; > > https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_guidelines_(draft) > > > > I wasn't contacted, but I did ask spot what the issue was, and he > > reported that we needed to know if there would be a case where the > > plugin may not function on either platform (mu or lack thereof). The > > answer is a strong "yes" from upstream. > > > How do we tell when the plugin doesn't function? If we can write that > down in the guidelines, it will help stop people from using the template > to create wordpress and mu plugins when the plugin only works on one > platform. > If it's not in the README for the plugin then it's not likely that you can find one small thing to be a whistleblower. The packager would have to test it. Understanding this, /most/ plugins will work on both platforms. This OK to make that clear? https://fedoraproject.org/w/index.php?title=User%3AIanweller%2FWordPress_plugin_packaging_guidelines_(draft)&diff=94870&oldid=91805 -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tibbs at math.uh.edu Fri Apr 3 03:24:11 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 02 Apr 2009 22:24:11 -0500 Subject: [Fedora-packaging] FPC meeting time proposal Message-ID: I wasn't sure if I should just directly mail this to the FPC members, but I figured this should work as well. At the last meeting those present discussed moving the meeting to better accommodate folks who have a tough time making it now. My understanding is that we can go at most two hours earlier because that puts the meeting at 8AM US Pacific time. We have to move at least one hour earlier to accommodate our friends in CET/CEST. The proposal discussed at the meeting is to move to Wednesdays at 15:00UTC. This would give us a two hour block and still give us (me) sufficient time before the FESCo meeting to get a report in. Unfortunately Toshio realized this morning that he would have to miss the first 30 minutes of that meeting due to another commitment. Thus I propose 15:30UTC on Wednesdays, which still gives us 90 minutes of channel time. I'd like to see a reply from each of the committee members indicating whether this works or not. Otherwise I'll mail you personally. - J< From a.badger at gmail.com Fri Apr 3 03:25:14 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 02 Apr 2009 20:25:14 -0700 Subject: [Fedora-packaging] wordpress guidelines -- ping? In-Reply-To: <20090403013918.GB19739@gmail.com> References: <20090402233946.GA16227@gmail.com> <49D555B7.4030608@gmail.com> <20090403013918.GB19739@gmail.com> Message-ID: <49D5819A.8050000@gmail.com> Ian Weller wrote: > On Thu, Apr 02, 2009 at 05:17:59PM -0700, Toshio Kuratomi wrote: >> Ian Weller wrote: >>> During the most recent meeting it was decided that I would be contacted >>> about a few issues with the WordPress plugin packaging guidelines; >>> https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_guidelines_(draft) >>> >>> I wasn't contacted, but I did ask spot what the issue was, and he >>> reported that we needed to know if there would be a case where the >>> plugin may not function on either platform (mu or lack thereof). The >>> answer is a strong "yes" from upstream. >>> >> How do we tell when the plugin doesn't function? If we can write that >> down in the guidelines, it will help stop people from using the template >> to create wordpress and mu plugins when the plugin only works on one >> platform. >> > If it's not in the README for the plugin then it's not likely that you > can find one small thing to be a whistleblower. The packager would have > to test it. > > Understanding this, /most/ plugins will work on both platforms. > > This OK to make that clear? > https://fedoraproject.org/w/index.php?title=User%3AIanweller%2FWordPress_plugin_packaging_guidelines_(draft)&diff=94870&oldid=91805 > If there's no one thing that makes it clear that something will work only on worpress or only on mu I guess that's the best we can do. I'm willing to +1 this. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Fri Apr 3 03:33:55 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 02 Apr 2009 20:33:55 -0700 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: References: Message-ID: <49D583A3.1000502@gmail.com> Jason L Tibbitts III wrote: > I wasn't sure if I should just directly mail this to the FPC members, > but I figured this should work as well. > > At the last meeting those present discussed moving the meeting to > better accommodate folks who have a tough time making it now. > > My understanding is that we can go at most two hours earlier because > that puts the meeting at 8AM US Pacific time. We have to move at > least one hour earlier to accommodate our friends in CET/CEST. > > The proposal discussed at the meeting is to move to Wednesdays at > 15:00UTC. This would give us a two hour block and still give us (me) > sufficient time before the FESCo meeting to get a report in. > Unfortunately Toshio realized this morning that he would have to miss > the first 30 minutes of that meeting due to another commitment. > > Thus I propose 15:30UTC on Wednesdays, which still gives us 90 minutes > of channel time. I'd like to see a reply from each of the committee > members indicating whether this works or not. Otherwise I'll mail you > personally. > That would work for me. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Fri Apr 3 04:13:19 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 03 Apr 2009 06:13:19 +0200 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: References: Message-ID: <49D58CDF.8070308@freenet.de> Jason L Tibbitts III wrote: > I wasn't sure if I should just directly mail this to the FPC members, > but I figured this should work as well. > > At the last meeting those present discussed moving the meeting to > better accommodate folks who have a tough time making it now. > > My understanding is that we can go at most two hours earlier because > that puts the meeting at 8AM US Pacific time. We have to move at > least one hour earlier to accommodate our friends in CET/CEST. > > The proposal discussed at the meeting is to move to Wednesdays at > 15:00UTC. This would give us a two hour block and still give us (me) > sufficient time before the FESCo meeting to get a report in. > Unfortunately Toshio realized this morning that he would have to miss > the first 30 minutes of that meeting due to another commitment. > > Thus I propose 15:30UTC on Wednesdays, which still gives us 90 minutes > of channel time. I'd like to see a reply from each of the committee > members indicating whether this works or not. Otherwise I'll mail you > personally. My personal restriction is "meeting must be finished before 19:00 local time", i.e. 17:00UTC during CEST and 18:00UTC during CET. => Both, 15:00UTC and 15:30 UTC, on Tuesdays and Wednesdays would work for me. Ralf From j.w.r.degoede at hhs.nl Fri Apr 3 06:29:04 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 03 Apr 2009 08:29:04 +0200 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: References: Message-ID: <49D5ACB0.5040300@hhs.nl> On 04/03/2009 05:24 AM, Jason L Tibbitts III wrote: > I wasn't sure if I should just directly mail this to the FPC members, > but I figured this should work as well. > > At the last meeting those present discussed moving the meeting to > better accommodate folks who have a tough time making it now. > > My understanding is that we can go at most two hours earlier because > that puts the meeting at 8AM US Pacific time. We have to move at > least one hour earlier to accommodate our friends in CET/CEST. > > The proposal discussed at the meeting is to move to Wednesdays at > 15:00UTC. This would give us a two hour block and still give us (me) > sufficient time before the FESCo meeting to get a report in. > Unfortunately Toshio realized this morning that he would have to miss > the first 30 minutes of that meeting due to another commitment. > > Thus I propose 15:30UTC on Wednesdays, which still gives us 90 minutes > of channel time. I'd like to see a reply from each of the committee > members indicating whether this works or not. Otherwise I'll mail you > personally. > > - J< > To (re)use Ralf's words: "My personal restriction is that": the meeting must not be between 17:30 and 19:00 localtime (dinner, but children in bed). So with summer time that is not between 15:30 and 17:00 UTC. iow, 15:30 UTC does work well at all for me. Regards, Hans From a.badger at gmail.com Fri Apr 3 10:50:06 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 03 Apr 2009 03:50:06 -0700 Subject: [Fedora-packaging] How to package a patched older version of libvmime in Fedora best? In-Reply-To: <1238706710.3036.14.camel@localhost.localdomain> References: <20090328204153.GA11515@hurricane.linuxnetz.de> <49D3BAA4.9070204@gmail.com> <20090402181149.GA30302@hurricane.linuxnetz.de> <49D50065.6000800@redhat.com> <1238706710.3036.14.camel@localhost.localdomain> Message-ID: <49D5E9DE.7090508@gmail.com> Lubomir Rintel wrote: > Well, not much of an issue if it has a caring and responsive maintainer. > The Security Response team tracks also embedded and old copies and > notifies their maintainers. Curious: How do you track embedded versions? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Fri Apr 3 14:55:36 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 03 Apr 2009 10:55:36 -0400 Subject: [Fedora-packaging] wordpress guidelines -- ping? In-Reply-To: <49D5819A.8050000@gmail.com> References: <20090402233946.GA16227@gmail.com> <49D555B7.4030608@gmail.com> <20090403013918.GB19739@gmail.com> <49D5819A.8050000@gmail.com> Message-ID: <49D62368.3070900@redhat.com> On 04/02/2009 11:25 PM, Toshio Kuratomi wrote: > Ian Weller wrote: >> This OK to make that clear? >> https://fedoraproject.org/w/index.php?title=User%3AIanweller%2FWordPress_plugin_packaging_guidelines_(draft)&diff=94870&oldid=91805 >> > If there's no one thing that makes it clear that something will work > only on worpress or only on mu I guess that's the best we can do. > > I'm willing to +1 this. +1 from me as well. ~spot From tcallawa at redhat.com Fri Apr 3 14:57:16 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 03 Apr 2009 10:57:16 -0400 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: <49D5ACB0.5040300@hhs.nl> References: <49D5ACB0.5040300@hhs.nl> Message-ID: <49D623CC.9020207@redhat.com> On 04/03/2009 02:29 AM, Hans de Goede wrote: > 15:30 UTC does work well at all for me. To clarify, it does or does not work well for you? ~spot From rdieter at math.unl.edu Fri Apr 3 15:01:39 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 03 Apr 2009 10:01:39 -0500 Subject: [Fedora-packaging] wordpress guidelines -- ping? In-Reply-To: <49D62368.3070900@redhat.com> References: <20090402233946.GA16227@gmail.com> <49D555B7.4030608@gmail.com> <20090403013918.GB19739@gmail.com> <49D5819A.8050000@gmail.com> <49D62368.3070900@redhat.com> Message-ID: <49D624D3.3080805@math.unl.edu> Tom "spot" Callaway wrote: > On 04/02/2009 11:25 PM, Toshio Kuratomi wrote: >> Ian Weller wrote: >>> This OK to make that clear? >>> https://fedoraproject.org/w/index.php?title=User%3AIanweller%2FWordPress_plugin_packaging_guidelines_(draft)&diff=94870&oldid=91805 >>> >> If there's no one thing that makes it clear that something will work >> only on worpress or only on mu I guess that's the best we can do. >> >> I'm willing to +1 this. > > +1 from me as well. +1 -- Rex From sindrepb at fedoraproject.org Fri Apr 3 18:46:34 2009 From: sindrepb at fedoraproject.org (=?UTF-8?Q?Sindre_Bj=C3=B8rdal?=) Date: Fri, 3 Apr 2009 20:46:34 +0200 Subject: [Fedora-packaging] gnome-do 0.8.0 In-Reply-To: <1236927080.875.57.camel@localhost.localdomain> References: <1236660589.1126.5.camel@localhost.localdomain> <1236927080.875.57.camel@localhost.localdomain> Message-ID: <8ddf2cad0904031146x137ed2b6h55d49b86e6e95a7d@mail.gmail.com> Luca: gnome-do 0.8 is in rawhide and is actively maintained. I haven't pushed the 0.8 update to F10 because gnome-do-plugins, which is now a separate package, is still stuck in review: https://bugzilla.redhat.com/show_bug.cgi?id=489014 and without the plugins 0.8 will be a regression for many gnome-do users. If you can, please help with the review of -plugins so we can bring gnome-do 0.8 goodness to F10 and future F11 users. -- Sindre Pedersen Bj?rdal From jspaleta at gmail.com Fri Apr 3 20:57:34 2009 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 3 Apr 2009 12:57:34 -0800 Subject: [Fedora-packaging] Need advice pertaining to GSoC proposal In-Reply-To: References: Message-ID: <604aa7910904031357se74fa7fy6d1620889edcfb8a@mail.gmail.com> On Wed, Apr 1, 2009 at 1:38 PM, Debayan Banerjee wrote: >2) Add pluggable policies Pluggable policies are a political landmine in terms of coordinating with 3rd party repos. Should the Fedora Project be setting policies with regard to how users use 3rd party repos? What happens when 3rd party repo maintainers don't like the default policies? Don't they just build repository release packages with scripts which override them setting them back to something they consider sane for their repo? We've been down this rabbit hole before. Fedora controls its repositories.. it does not control 3rd party repositories, we are not going to get into the business of whitelisting or blacklisting anything associated with 3rd party repos making any judgements whatsoever as to the packages in repositories we don't have control over. If this is implemented Fedora won't be doing anything with it at all. And isn't this duplicate functionality to yum-protectbase and yum-protect-packages that Fedora has...and is not enabled by default? 3)Add voting system to Package Manager: I have a very deep problem with equating votes with trust. I would be more inclined to integrate popcon like functionality or the application usage mechanism that mugshot used to get a crowdsource perspective on how "used" an application package is relative to another...without overloading the meaning of the word "trust." Re > 4) A server that receives these votes and maintains a list of repos in > sorted order. The distro maintains this. Leave it to the user which > repo he wants to add now. > 4) A server that receives votes and maintains a listing of > repositories in sorted order: > We could make modifications to > so that it provides one-click-install links to all packages thus. > Similar efforts are at: The external Fedora community actually had a site like this early on. package tracker or something. But let me be very very clear its going to be very difficult to get this sort of thing officially hosted as an official piece of Fedora infrastructure for the same technical reasons that we can't talk in detail about 3rd party repository packages in the wiki. The only conceivable way you could do this is if each repository hosted its own service instance and packagekit would query each repository's voting information after the repository was configured. Votes are just another form of metadata about packages. We don't host currently recognized 3rd party package metadata centrally, we shouldn't get into the business of hosting more exotic forms of metadata either. Regardless whether its dynamically served from a central service or from mirrored repomd metadata. And I think you have to make a stronger case for why this has to be a centralized service and not mirrorable repository metadata that fits within the repomd scheme so that it can be mirrored. And of course none of my comments speak to the value of this concept or the likelihood that Fedora would choose to enable this sort of metadata by default. If its valuable and if Fedora will turn it on, it won't happen unless you decentralize the information in such a way that Fedora does not become responsible for hosting or distributing any metadata about any packages from external repositories. > I can set up a prototype server which > accepts these votes and displays reposiories/packages accordingly. > Once I have successfully built all the things I have mentioned, I dont > mind buying hosting space to host it as a proof of concept. Please understand that an implementation that is designed as a single service which aggregates repositories from multiple vendors stands a vanishingly small chance of being enabled by default in Fedora for non-technical reasons. I would encourage you to implement your ideas such that each repository can take responsibility for providing its own tagging metadata (abstract enough to be used for other tagging models other than voting). -jef From lkundrak at v3.sk Sat Apr 4 07:37:03 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Sat, 04 Apr 2009 09:37:03 +0200 Subject: [Fedora-packaging] How to package a patched older version of libvmime in Fedora best? In-Reply-To: <49D5E9DE.7090508@gmail.com> References: <20090328204153.GA11515@hurricane.linuxnetz.de> <49D3BAA4.9070204@gmail.com> <20090402181149.GA30302@hurricane.linuxnetz.de> <49D50065.6000800@redhat.com> <1238706710.3036.14.camel@localhost.localdomain> <49D5E9DE.7090508@gmail.com> Message-ID: <1238830624.3036.22.camel@localhost.localdomain> On Fri, 2009-04-03 at 03:50 -0700, Toshio Kuratomi wrote: > Lubomir Rintel wrote: > > Well, not much of an issue if it has a caring and responsive maintainer. > > The Security Response team tracks also embedded and old copies and > > notifies their maintainers. > > Curious: How do you track embedded versions? Hm, looking at the fedora security CVS seems like my memories are fading since I left SRT. I was sure there was a file that lists known embedded versions of software packages within others, but I can't find it. Probably it was internal to Red Hat CVS. We've also been having an OpenGrok instance, which is no longer maintained at the time. That was pretty handy to find copied code anywhere. So... it might be that I was wrong -- I can't really say now SRT reliably tracks embedded copies of code. Current SRT members may know better. -- "Excuse all the blood" -- Dead From luca at foppiano.org Sat Apr 4 19:15:32 2009 From: luca at foppiano.org (Luca Foppiano) Date: Sat, 04 Apr 2009 21:15:32 +0200 Subject: [Fedora-packaging] gnome-do 0.8.0 In-Reply-To: <8ddf2cad0904031146x137ed2b6h55d49b86e6e95a7d@mail.gmail.com> References: <1236660589.1126.5.camel@localhost.localdomain> <1236927080.875.57.camel@localhost.localdomain> <8ddf2cad0904031146x137ed2b6h55d49b86e6e95a7d@mail.gmail.com> Message-ID: <1238872532.15975.13.camel@localhost.localdomain> On Fri, 2009-04-03 at 20:46 +0200, Sindre Bj?rdal wrote: > Luca: gnome-do 0.8 is in rawhide and is actively maintained. I haven't > pushed the 0.8 update to F10 because gnome-do-plugins, which is now a > separate package, is still stuck in review: > https://bugzilla.redhat.com/show_bug.cgi?id=489014 and without the > plugins 0.8 will be a regression for many gnome-do users. > > If you can, please help with the review of -plugins so we can bring > gnome-do 0.8 goodness to F10 and future F11 users. ok, I have not so much time but I can help for review (that may help me in long way to became a mantainer) I'll start a discussion in fedora-mono list. Cheers Luca -- Today is Prickle-Prickle, the 21st day of Discord in the YOLD 3175 Increased knowledge will help you now. Have mate's phone bugged. From j.w.r.degoede at hhs.nl Sun Apr 5 09:10:30 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 05 Apr 2009 11:10:30 +0200 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: <49D623CC.9020207@redhat.com> References: <49D5ACB0.5040300@hhs.nl> <49D623CC.9020207@redhat.com> Message-ID: <49D87586.9020203@hhs.nl> On 04/03/2009 04:57 PM, Tom "spot" Callaway wrote: > On 04/03/2009 02:29 AM, Hans de Goede wrote: >> 15:30 UTC does work well at all for me. > > To clarify, it does or does not work well for you? > Sorry does *not* work well for me, actually it does not work at all for me. Regards, Hans From dominik at greysector.net Sun Apr 5 14:21:22 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 5 Apr 2009 16:21:22 +0200 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: References: Message-ID: <20090405142122.GA7187@mokona.greysector.net> On Friday, 03 April 2009 at 05:24, Jason L Tibbitts III wrote: > I wasn't sure if I should just directly mail this to the FPC members, > but I figured this should work as well. > > At the last meeting those present discussed moving the meeting to > better accommodate folks who have a tough time making it now. > > My understanding is that we can go at most two hours earlier because > that puts the meeting at 8AM US Pacific time. We have to move at > least one hour earlier to accommodate our friends in CET/CEST. > > The proposal discussed at the meeting is to move to Wednesdays at > 15:00UTC. This would give us a two hour block and still give us (me) > sufficient time before the FESCo meeting to get a report in. > Unfortunately Toshio realized this morning that he would have to miss > the first 30 minutes of that meeting due to another commitment. > > Thus I propose 15:30UTC on Wednesdays, which still gives us 90 minutes > of channel time. I'd like to see a reply from each of the committee > members indicating whether this works or not. Otherwise I'll mail you > personally. 15:30UTC is bad for me currently. I'd be either always late or I'd have to stay at work after hours. 16:00UTC is the earliest I can make it without too much trouble. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From denis at poolshark.org Sun Apr 5 19:58:25 2009 From: denis at poolshark.org (Denis Leroy) Date: Sun, 05 Apr 2009 21:58:25 +0200 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: References: Message-ID: <49D90D61.4040008@poolshark.org> Jason L Tibbitts III wrote: > I wasn't sure if I should just directly mail this to the FPC members, > but I figured this should work as well. > > At the last meeting those present discussed moving the meeting to > better accommodate folks who have a tough time making it now. > > My understanding is that we can go at most two hours earlier because > that puts the meeting at 8AM US Pacific time. We have to move at > least one hour earlier to accommodate our friends in CET/CEST. > > The proposal discussed at the meeting is to move to Wednesdays at > 15:00UTC. This would give us a two hour block and still give us (me) > sufficient time before the FESCo meeting to get a report in. > Unfortunately Toshio realized this morning that he would have to miss > the first 30 minutes of that meeting due to another commitment. > > Thus I propose 15:30UTC on Wednesdays, which still gives us 90 minutes > of channel time. I'd like to see a reply from each of the committee > members indicating whether this works or not. Otherwise I'll mail you > personally. That works for me. I'm often on confcall with California during the current time. From dominik at greysector.net Tue Apr 7 20:51:33 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 7 Apr 2009 22:51:33 +0200 Subject: [Fedora-packaging] [Draft] The use of alternatives Message-ID: <20090407205132.GA31068@mokona.greysector.net> Hi. The UsingAlternatives draft[1] should now be ready for voting at the next meeting. I've just made some finishing touches. I'd like to include it in the agenda for the next FPC meeting. Regards, R. [1] https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jussi.lehtola at iki.fi Tue Apr 7 21:06:56 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Wed, 08 Apr 2009 00:06:56 +0300 Subject: [Fedora-packaging] [Draft] The use of alternatives In-Reply-To: <20090407205132.GA31068@mokona.greysector.net> References: <20090407205132.GA31068@mokona.greysector.net> Message-ID: <1239138416.3238.1.camel@localhost.localdomain> On Tue, 2009-04-07 at 22:51 +0200, Dominik 'Rathann' Mierzejewski wrote: > Hi. > > The UsingAlternatives draft[1] should now be ready for voting at the next > meeting. I've just made some finishing touches. I'd like to include > it in the agenda for the next FPC meeting. > > Regards, > R. > > [1] https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives Maybe add a note about cases where the use of alternatives is NOT recommended and environment-modules should be used instead, e.g. MPI environments and so on. [Generally cases where multiple versions and variants that offer different functionality need to be useable at the same time.] -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From jussi.lehtola at iki.fi Wed Apr 8 08:02:53 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Wed, 08 Apr 2009 11:02:53 +0300 Subject: [Fedora-packaging] Use of %{_libdir}/gfortran Message-ID: <1239177773.3257.29.camel@localhost.localdomain> Hi, the Fortran flags in Fedora 10 read FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -I/usr/lib64/gfortran/modules' However, # yum provides /usr/lib64/gfortran finds no match. What package is supposed to provide the aforementioned directory, and what is it supposed to be used for? Should all Fortran module files be installed in that directory? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From ianweller at gmail.com Wed Apr 8 21:19:17 2009 From: ianweller at gmail.com (Ian Weller) Date: Wed, 8 Apr 2009 16:19:17 -0500 Subject: [Fedora-packaging] wordpress guidelines -- ping? In-Reply-To: <49D624D3.3080805@math.unl.edu> References: <20090402233946.GA16227@gmail.com> <49D555B7.4030608@gmail.com> <20090403013918.GB19739@gmail.com> <49D5819A.8050000@gmail.com> <49D62368.3070900@redhat.com> <49D624D3.3080805@math.unl.edu> Message-ID: <20090408211917.GA3761@gmail.com> On Fri, Apr 03, 2009 at 10:01:39AM -0500, Rex Dieter wrote: > Tom "spot" Callaway wrote: >> On 04/02/2009 11:25 PM, Toshio Kuratomi wrote: >>> Ian Weller wrote: >>>> This OK to make that clear? >>>> https://fedoraproject.org/w/index.php?title=User%3AIanweller%2FWordPress_plugin_packaging_guidelines_(draft)&diff=94870&oldid=91805 >>>> >>> If there's no one thing that makes it clear that something will work >>> only on worpress or only on mu I guess that's the best we can do. >>> >>> I'm willing to +1 this. >> >> +1 from me as well. > > +1 > Can I get two more? -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jonstanley at gmail.com Wed Apr 8 21:35:32 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 8 Apr 2009 17:35:32 -0400 Subject: [Fedora-packaging] wordpress guidelines -- ping? In-Reply-To: <20090408211917.GA3761@gmail.com> References: <20090402233946.GA16227@gmail.com> <49D555B7.4030608@gmail.com> <20090403013918.GB19739@gmail.com> <49D5819A.8050000@gmail.com> <49D62368.3070900@redhat.com> <49D624D3.3080805@math.unl.edu> <20090408211917.GA3761@gmail.com> Message-ID: On Wed, Apr 8, 2009 at 5:19 PM, Ian Weller wrote: > Can I get two more? After being approved by FPC, it has to go to FESCo at our regular meeting - so I'm not sure what the rush here is. Obviously if FPC approves it we can add it to the agenda for Friday. From ianweller at gmail.com Wed Apr 8 23:08:26 2009 From: ianweller at gmail.com (Ian Weller) Date: Wed, 8 Apr 2009 18:08:26 -0500 Subject: [Fedora-packaging] wordpress guidelines -- ping? In-Reply-To: References: <20090402233946.GA16227@gmail.com> <49D555B7.4030608@gmail.com> <20090403013918.GB19739@gmail.com> <49D5819A.8050000@gmail.com> <49D62368.3070900@redhat.com> <49D624D3.3080805@math.unl.edu> <20090408211917.GA3761@gmail.com> Message-ID: <20090408230826.GB16455@gmail.com> On Wed, Apr 08, 2009 at 05:35:32PM -0400, Jon Stanley wrote: > On Wed, Apr 8, 2009 at 5:19 PM, Ian Weller wrote: > > > Can I get two more? > > After being approved by FPC, it has to go to FESCo at our regular > meeting - so I'm not sure what the rush here is. Obviously if FPC > approves it we can add it to the agenda for Friday. > I was just bringing the subject back up just in case somebody missed it. It would be wondrous if FESCo could vote on it ASAP as well :) -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sanjay.ankur at gmail.com Sun Apr 12 09:24:39 2009 From: sanjay.ankur at gmail.com (Ankur Sinha) Date: Sun, 12 Apr 2009 14:54:39 +0530 Subject: [Fedora-packaging] [Fedora-Packagers] SciLab Message-ID: <1239528279.3328.12.camel@localhost.localdomain> hi, Is scilab in the repos? I haven't been able to find the latest release.. It's an open source alternative to Matlab.. http://www.scilab.org/download/index_download.php?page=release#linux The license looks open source.. :) http://www.scilab.org/legal/ Can someone please package it ? The older version is present in the Dries repos though.. http://dries.ulyssis.org/rpm/packages/scilab/info.html regards, Ankur From jussi.lehtola at iki.fi Sun Apr 12 11:32:41 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Sun, 12 Apr 2009 14:32:41 +0300 Subject: [Fedora-packaging] [Fedora-Packagers] SciLab In-Reply-To: <1239528279.3328.12.camel@localhost.localdomain> References: <1239528279.3328.12.camel@localhost.localdomain> Message-ID: <1239535961.3209.3.camel@localhost.localdomain> On Sun, 2009-04-12 at 14:54 +0530, Ankur Sinha wrote: > hi, > > Is scilab in the repos? I haven't been able to find the latest release.. > It's an open source alternative to Matlab.. > > http://www.scilab.org/download/index_download.php?page=release#linux No, it's not in the repos yet. It's been under review for some time now: https://bugzilla.redhat.com/show_bug.cgi?id=472639 Scilab depends on matio, which hasn't had progress in a while: https://bugzilla.redhat.com/show_bug.cgi?id=466737 -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From Matt_Domsch at Dell.com Mon Apr 13 21:36:31 2009 From: Matt_Domsch at Dell.com (Matt_Domsch at Dell.com) Date: Mon, 13 Apr 2009 16:36:31 -0500 Subject: [Fedora-packaging] FW: [Bug 495529] rpmlint incorrect warning for missing-lsb-keyword Default-Stop References: <200904132042.n3DKglqD017458@bz-web2.app.phx.redhat.com> Message-ID: Packaging Committee: either rpmlint is correct, or the guidelines are correct; but at the moment they conflict. Please see this bugzilla and review. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux -----Original Message----- From: bugzilla at redhat.com [mailto:bugzilla at redhat.com] Sent: Mon 4/13/2009 3:42 PM To: Domsch, Matt Subject: [Bug 495529] rpmlint incorrect warning for missing-lsb-keyword Default-Stop Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=495529 Ville Skytt? changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NOTABUG --- Comment #1 from Ville Skytt? 2009-04-13 16:42:46 EDT --- I think the documentation cited draws wrong conclusions/interpretations from the LSB spec. One may very well want to have a service stopped by default in some runlevels even if it is not started in any by default. The LSB specs are quite vague too, which has resulted in rpmlint drawing its own conclusions, the one of which in effect here is that there should be no need not to have a Default-Stop in all init scripts, thus it always recommends adding one in all init scripts, even if empty. $ rpmlint -I missing-lsb-keyword missing-lsb-keyword: The package contains an init script that does not contain one of the LSB init script comment block convention keywords that are recommendable for all init scripts. If there is nothing to add to a keyword's value, include the keyword in the script with an empty value. Note that as of version 3.2, the LSB specification does not mandate presence of any keywords. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug. From dominik at greysector.net Tue Apr 14 17:09:37 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 14 Apr 2009 19:09:37 +0200 Subject: [Fedora-packaging] [Draft] The use of alternatives In-Reply-To: <1239138416.3238.1.camel@localhost.localdomain> References: <20090407205132.GA31068@mokona.greysector.net> <1239138416.3238.1.camel@localhost.localdomain> Message-ID: <20090414170937.GA1948@mokona.greysector.net> On Tuesday, 07 April 2009 at 23:06, Jussi Lehtola wrote: > On Tue, 2009-04-07 at 22:51 +0200, Dominik 'Rathann' Mierzejewski wrote: > > Hi. > > > > The UsingAlternatives draft[1] should now be ready for voting at the next > > meeting. I've just made some finishing touches. I'd like to include > > it in the agenda for the next FPC meeting. > > > > Regards, > > R. > > > > [1] https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives > > > Maybe add a note about cases where the use of alternatives is NOT > recommended and environment-modules should be used instead, e.g. MPI > environments and so on. [Generally cases where multiple versions and > variants that offer different functionality need to be useable at the > same time.] Done. Sorry it took so long. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Tue Apr 14 17:58:00 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 14 Apr 2009 19:58:00 +0200 Subject: [Fedora-packaging] [Draft] The use of alternatives In-Reply-To: <20090414170937.GA1948@mokona.greysector.net> References: <20090407205132.GA31068@mokona.greysector.net> <1239138416.3238.1.camel@localhost.localdomain> <20090414170937.GA1948@mokona.greysector.net> Message-ID: <20090414175759.GB1948@mokona.greysector.net> On Tuesday, 14 April 2009 at 19:09, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 07 April 2009 at 23:06, Jussi Lehtola wrote: > > On Tue, 2009-04-07 at 22:51 +0200, Dominik 'Rathann' Mierzejewski wrote: > > > Hi. > > > > > > The UsingAlternatives draft[1] should now be ready for voting at the next > > > meeting. I've just made some finishing touches. I'd like to include > > > it in the agenda for the next FPC meeting. > > > > > > Regards, > > > R. > > > > > > [1] https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives > > > > > > Maybe add a note about cases where the use of alternatives is NOT > > recommended and environment-modules should be used instead, e.g. MPI > > environments and so on. [Generally cases where multiple versions and > > variants that offer different functionality need to be useable at the > > same time.] > > Done. Sorry it took so long. ... although I couldn't actually mention environment-modules in the guideline because their use is not documented in the Packaging Guidelines. Would you be willing to write up a guideline with some examples, Jussi? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From cassmodiah at fedoraproject.org Tue Apr 14 19:14:41 2009 From: cassmodiah at fedoraproject.org (Simon Wesp) Date: Tue, 14 Apr 2009 21:14:41 +0200 Subject: [Fedora-packaging] Mono's dll/exe and debugpackage Message-ID: <20090414211441.75f3c2a3@fedoraproject.org> Hey all, I have a problem with a mono package. It creates only an *.exe file and some *.dll files in libdir. i can't create a debug package with this. Is there a trick for this? -- Mit freundlichen Gr??en aus dem sch?nen Hainzell Simon Wesp The G in GNU stands for GNU http://fedoraproject.org/wiki/SimonWesp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From tcallawa at redhat.com Tue Apr 14 19:40:37 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 14 Apr 2009 15:40:37 -0400 Subject: [Fedora-packaging] Mono's dll/exe and debugpackage In-Reply-To: <20090414211441.75f3c2a3@fedoraproject.org> References: <20090414211441.75f3c2a3@fedoraproject.org> Message-ID: <49E4E6B5.9060806@redhat.com> On 04/14/2009 03:14 PM, Simon Wesp wrote: > Hey all, > > I have a problem with a mono package. It creates only an *.exe file and > some *.dll files in libdir. i can't create a debug package with this. > Is there a trick for this? Nope. It is believed that Mono packages never create debuginfo. See: https://fedoraproject.org/wiki/Packaging/Debuginfo ~spot From tibbs at math.uh.edu Wed Apr 15 16:00:56 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 15 Apr 2009 11:00:56 -0500 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: (Jason L. Tibbitts, III's message of "Thu\, 02 Apr 2009 22\:24\:11 -0500") References: Message-ID: Well, obviously that didn't work. It looks to me as if the set of time requirements simply can't be satisfied, but to be sure we need to have everyone post the times they're available so that we can try to find an acceptable time without regard to what's going on in the meeting channel. Please keep all times in UTC and only list out times when you will be available both with and without DST/Summer time (so we don't lose people during the transition time). I am pretty flexible; I can conceivably meet at any time between 8AM and midnight local time, but I do have to get to and from work. Fortunately I can move that time around a bit, and on Wednesdays I generally work from home and have no time restrictions. So let's just say that I'm available any time between 14:00UTC (08:00CST) to 05:00UTC (00:00CDT), seven days a week. Assuming I've managed to wrap my head around summer time properly. - J< From sstarr at platform.com Wed Apr 15 16:50:33 2009 From: sstarr at platform.com (Shawn Starr) Date: Wed, 15 Apr 2009 12:50:33 -0400 Subject: [Fedora-packaging] New Draft Packaging Guideline - Fixing Gconf schema registration Message-ID: Hello everyone, I have created a draft guideline using OpenSuSE's existing macros.gconf2 script for Fedora. You can find this at: https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf I have done an initial test with the .spec file mentioned as an example in this draft. Seems to work fine. Since this the first iteration, I would like people to comment so we can get this finalized for Fedora 12 and rejoice in speedy installs and yum updates. Thanks! -- Shawn Starr Software Developer, Open Source Grid Development Center (OSGDC) Platform Computing 3760 14th Avenue Markham, ON L3R3T7 direct: 905.948.4229 http://www.platform.com From tcallawa at redhat.com Wed Apr 15 17:15:20 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 15 Apr 2009 13:15:20 -0400 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: References: Message-ID: <49E61628.7070104@redhat.com> On 04/15/2009 12:00 PM, Jason L Tibbitts III wrote: > Well, obviously that didn't work. It looks to me as if the set of > time requirements simply can't be satisfied, but to be sure we need to > have everyone post the times they're available so that we can try to > find an acceptable time without regard to what's going on in the > meeting channel. > > Please keep all times in UTC and only list out times when you will be > available both with and without DST/Summer time (so we don't lose > people during the transition time). Here is my availability: Mondays: Between 12:00 UTC (8:00 AM EDT) and 15:00 UTC (11:00 AM EDT) Between 16:00 UTC (12:00 PM EDT) and 18:00 UTC (2:00 PM EDT) Between 19:00 UTC (3:00 PM EDT) and 03:00 UTC (11:00 PM EDT) Tuesdays: Between 12:00 UTC (8:00 AM EDT) and 18:00 UTC (2:00 PM EDT) Between 19:00 UTC (3:00 PM EDT) and 03:00 UTC (11:00 PM EDT) Wednesdays: Between 12:00 UTC (8:00 AM EDT) and 03:00 UTC (11:00 PM EDT) Thursdays: Between 12:00 UTC (8:00 AM EDT) and 03:00 UTC (11:00 PM EDT) Fridays: Between 12:00 UTC (8:00 AM EDT) and 14:00 UTC (10:00 AM EDT) Between 15:30 UTC (11:30 AM EDT) and 18:00 UTC (2:00 PM EDT) Between 19:00 UTC (3:00 PM EDT) and 03:00 UTC (11:00 PM EDT) My weekends are far less predictable. I would greatly prefer that we held the meeting during the week. ~spot From mattias.ellert at fysast.uu.se Mon Apr 20 08:01:14 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Mon, 20 Apr 2009 10:01:14 +0200 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources Message-ID: <1240214474.24291.31.camel@ellert.tsl.uu.se> Hi! I have several very similar packages being reviewed and two different reviewers reviewing different packages have reach contradicting conclusions about how the packaging guidelines should be interpreted. Since it doesn't make sense that the same issue is resolved differently depending on who happens to be the reviewer, and the reviewers have failed to reach a common viewpoint I send this mail to this list in the hope that there will be a way to resolve the issue consistently for all packages. Here is a description of the problem at hand: When upstream distributes sources in a gigantic installer containing the sources for 300+ packages it doesn't make sense to include this full tarfile for each SRPM, since less than 1% of it is used to compile each package. Instead the relevant subdirectory is extracted from this beast (properly documented in the specfile in accordance to the packaging guidelines). Then the question is how should the following guideline be interpreted: "If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc." Does this text refer to the big gigantic installer or the extracted source tarfile in this case. One reviewer strongly argues the first point and will only approve packages where the license file is included, the other strongly argues the second point and will only approve packages where the license file is not included. Both quote the above rule as the foundation for there standpoint. Since it doesn't make sense to do things differently depending on who happens to be the reviewer, I would like to have an official view of the packaging experts on this issue. Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2272 bytes Desc: not available URL: From jussi.lehtola at iki.fi Mon Apr 20 08:15:04 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Mon, 20 Apr 2009 11:15:04 +0300 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <1240214474.24291.31.camel@ellert.tsl.uu.se> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> Message-ID: <1240215304.15626.6.camel@politzer.theorphys.helsinki.fi> On Mon, 2009-04-20 at 10:01 +0200, Mattias Ellert wrote: > Then the question is how should the following guideline be interpreted: > > "If (and only if) the source package includes the text of the license(s) > in its own file, then that file, containing the text of the license(s) > for the package must be included in %doc." > > Does this text refer to the big gigantic installer or the extracted > source tarfile in this case. My 0.02?: If everything in the gigantic tarball is under the same license, then it should be included. If the subpackages are from different upstreams and they are not under the same license, then if no license file is distributed with the subpackage it is not put into %doc. Of course, the situation is trickier if the upstream tarball contains many license files, e.g. COPYING.BSD, COPYING.MIT and COPYING.GPLv2; in that case the license file should be included in the (sub)package rpm even though the license file does not exist in the subpackage directory of the upstream tarball. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From mattias.ellert at fysast.uu.se Mon Apr 20 08:30:37 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Mon, 20 Apr 2009 10:30:37 +0200 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <1240215304.15626.6.camel@politzer.theorphys.helsinki.fi> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <1240215304.15626.6.camel@politzer.theorphys.helsinki.fi> Message-ID: <1240216237.24291.53.camel@ellert.tsl.uu.se> m?n 2009-04-20 klockan 11:15 +0300 skrev Jussi Lehtola: > On Mon, 2009-04-20 at 10:01 +0200, Mattias Ellert wrote: > > Then the question is how should the following guideline be interpreted: > > > > "If (and only if) the source package includes the text of the license(s) > > in its own file, then that file, containing the text of the license(s) > > for the package must be included in %doc." > > > > Does this text refer to the big gigantic installer or the extracted > > source tarfile in this case. > > My 0.02?: > > If everything in the gigantic tarball is under the same license, then it > should be included. > > If the subpackages are from different upstreams and they are not under > the same license, then if no license file is distributed with the > subpackage it is not put into %doc. > > Of course, the situation is trickier if the upstream tarball contains > many license files, e.g. COPYING.BSD, COPYING.MIT and COPYING.GPLv2; in > that case the license file should be included in the (sub)package rpm > even though the license file does not exist in the subpackage directory > of the upstream tarball. The upstream tarball contains one license file that applies to all code developed by upstream. The upstream tarball also contain copies of the source tree for some of its dependencies (openssl, libtool, libxml2, ...) which also have separate license files. The presence of these additional license files was given as an additional argument not to include the license in the packages by the reviewer exercising this position. These additional licences are rather irrelevant since those parts of the upstream tarball will never be packaged for Fedora, since the Fedora packages for these dependences are used. Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2272 bytes Desc: not available URL: From jussi.lehtola at iki.fi Mon Apr 20 08:53:14 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Mon, 20 Apr 2009 11:53:14 +0300 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <1240216237.24291.53.camel@ellert.tsl.uu.se> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <1240215304.15626.6.camel@politzer.theorphys.helsinki.fi> <1240216237.24291.53.camel@ellert.tsl.uu.se> Message-ID: <1240217594.15626.10.camel@politzer.theorphys.helsinki.fi> On Mon, 2009-04-20 at 10:30 +0200, Mattias Ellert wrote: > m?n 2009-04-20 klockan 11:15 +0300 skrev Jussi Lehtola: > > On Mon, 2009-04-20 at 10:01 +0200, Mattias Ellert wrote: > The upstream tarball contains one license file that applies to all code > developed by upstream. The upstream tarball also contain copies of the > source tree for some of its dependencies (openssl, libtool, > libxml2, ...) which also have separate license files. The presence of > these additional license files was given as an additional argument not > to include the license in the packages by the reviewer exercising this > position. These additional licences are rather irrelevant since those > parts of the upstream tarball will never be packaged for Fedora, since > the Fedora packages for these dependences are used. In that case I think the situation is clear: the license file must be present in %doc, since the subpackage rpms are all created from the same tarball. If everything is built in one big specfile, the license goes in the %doc of every subpackage that can be installed separately. (E.g. devel doesn't need to have the license, if devel requires the main package which already contains the license.) What do the others think? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From rc040203 at freenet.de Mon Apr 20 09:22:12 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Apr 2009 11:22:12 +0200 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <1240214474.24291.31.camel@ellert.tsl.uu.se> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> Message-ID: <49EC3EC4.6020300@freenet.de> Mattias Ellert wrote: > Hi! > Then the question is how should the following guideline be interpreted: > > "If (and only if) the source package includes the text of the license(s) > in its own file, then that file, containing the text of the license(s) > for the package must be included in %doc." > > Does this text refer to the big gigantic installer or the extracted > source tarfile in this case. Neither. This paragraph aims at the problem of tarballs containing "inlined licenses" vs. packages containing "detached licenses". With * "inlined licenses": source files contain a "license section" within their code. * "detached licenses": A tarball contains one or more files, describing the source's contents. Somewhat oversimplified, this guideline essentially means: "If the tarball has a license file, then you must include it - if it doesn't, you must not create one" Ralf From mattias.ellert at fysast.uu.se Mon Apr 20 10:28:40 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Mon, 20 Apr 2009 12:28:40 +0200 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <49EC3EC4.6020300@freenet.de> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC3EC4.6020300@freenet.de> Message-ID: <1240223320.24291.62.camel@ellert.tsl.uu.se> m?n 2009-04-20 klockan 11:22 +0200 skrev Ralf Corsepius: > This paragraph aims at the problem of tarballs containing > "inlined licenses" vs. packages containing "detached licenses". > > With > * "inlined licenses": source files contain a "license section" within > their code. > * "detached licenses": A tarball contains one or more files, describing > the source's contents. > > > Somewhat oversimplified, this guideline essentially means: "If the > tarball has a license file, then you must include it - if it doesn't, > you must not create one" > > > Ralf The question at hand is not whether the tarball contains inlined or detached licenses. The question is which tarball the guideline refers to. If it is the large upstream installer it does include a detached license file. If it is the extracted tarball it does not. Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2272 bytes Desc: not available URL: From paul at city-fan.org Mon Apr 20 10:40:00 2009 From: paul at city-fan.org (Paul Howarth) Date: Mon, 20 Apr 2009 11:40:00 +0100 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <1240223320.24291.62.camel@ellert.tsl.uu.se> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC3EC4.6020300@freenet.de> <1240223320.24291.62.camel@ellert.tsl.uu.se> Message-ID: <49EC5100.1050408@city-fan.org> Mattias Ellert wrote: > m?n 2009-04-20 klockan 11:22 +0200 skrev Ralf Corsepius: >> This paragraph aims at the problem of tarballs containing >> "inlined licenses" vs. packages containing "detached licenses". >> >> With >> * "inlined licenses": source files contain a "license section" within >> their code. >> * "detached licenses": A tarball contains one or more files, describing >> the source's contents. >> >> >> Somewhat oversimplified, this guideline essentially means: "If the >> tarball has a license file, then you must include it - if it doesn't, >> you must not create one" >> >> >> Ralf > > The question at hand is not whether the tarball contains inlined or > detached licenses. The question is which tarball the guideline refers > to. If it is the large upstream installer it does include a detached > license file. If it is the extracted tarball it does not. The upstream distribution is the big installer containing the license file. The creation of the extracted tarballs is part of the packaging process. Suppose the packager of a "standard" package with a detached license file in the upstream tarball made an extracted tarball containing everything but the upstream license file and then used that as the basis for a package. Would that make sense? No. Neither does the omission of the upstream license in the case of the humongous installer. The extracted tarball should include the upstream license and the subdirectory of interest from the installer, and then the resulting package should include the license file. Paul. From jussi.lehtola at iki.fi Mon Apr 20 10:55:47 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Mon, 20 Apr 2009 13:55:47 +0300 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <49EC3EC4.6020300@freenet.de> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC3EC4.6020300@freenet.de> Message-ID: <1240224947.15626.26.camel@politzer.theorphys.helsinki.fi> On Mon, 2009-04-20 at 11:22 +0200, Ralf Corsepius wrote: [clip] > Somewhat oversimplified, this guideline essentially means: "If the > tarball has a license file, then you must include it - if it doesn't, > you must not create one" I've never encountered hitherto an interpretation in which a license file has to be created if upstream hasn't supplied any. AFAIK that is the policy in Debian, not in Fedora. Maybe it should be made clearer in the guidelines what must be done also in this case. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From a.badger at gmail.com Mon Apr 20 12:58:44 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 20 Apr 2009 05:58:44 -0700 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <1240214474.24291.31.camel@ellert.tsl.uu.se> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> Message-ID: <49EC7184.2030505@gmail.com> Mattias Ellert wrote: > Here is a description of the problem at hand: > > When upstream distributes sources in a gigantic installer containing the > sources for 300+ packages it doesn't make sense to include this full > tarfile for each SRPM, since less than 1% of it is used to compile each > package. Instead the relevant subdirectory is extracted from this beast > (properly documented in the specfile in accordance to the packaging > guidelines). > What's the bugzilla URL? I think people have answered the licence question pretty well but I'm curious to see how the split up of the 300+ packages is being accomplished. That seems like it would be a more contentious area. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Mon Apr 20 13:31:36 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Apr 2009 15:31:36 +0200 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <1240224947.15626.26.camel@politzer.theorphys.helsinki.fi> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC3EC4.6020300@freenet.de> <1240224947.15626.26.camel@politzer.theorphys.helsinki.fi> Message-ID: <49EC7938.30606@freenet.de> Jussi Lehtola wrote: > On Mon, 2009-04-20 at 11:22 +0200, Ralf Corsepius wrote: > > [clip] > >> Somewhat oversimplified, this guideline essentially means: "If the >> tarball has a license file, then you must include it - if it doesn't, >> you must not create one" > > > I've never encountered hitherto an interpretation in which a license > file has to be created if upstream hasn't supplied any. Well, packagers wanting to add license files had been a common case in the early Fedora days. It had been (and still occasionally is) a typical packaging newcomer mistake, originating from people who interpret "include license files" as "must add one, if not present". You can still find packages which do so in Fedora. > AFAIK that is > the policy in Debian, not in Fedora. No idea what Debian does. > Maybe it should be made clearer in the guidelines what must be done also > in this case. This section is almost as old as Fedora. It has hardly been a problem before. Ralf From tcallawa at redhat.com Mon Apr 20 15:10:44 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 20 Apr 2009 11:10:44 -0400 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <1240223320.24291.62.camel@ellert.tsl.uu.se> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC3EC4.6020300@freenet.de> <1240223320.24291.62.camel@ellert.tsl.uu.se> Message-ID: <49EC9074.9050808@redhat.com> On 04/20/2009 06:28 AM, Mattias Ellert wrote: > The question at hand is not whether the tarball contains inlined or > detached licenses. The question is which tarball the guideline refers > to. If it is the large upstream installer it does include a detached > license file. If it is the extracted tarball it does not. *puts on his Fedora Legal hat* Does the tarball that you're using as Source0 (or whatever Source lines are in the spec) contain a separate (and relevant) license text file? If so, you MUST have it as %doc. If not, you (the packager) can choose to add it to the package as %doc if you want, but you are NOT required to do so. Hope that helps, ~spot From a.badger at gmail.com Mon Apr 20 15:50:30 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 20 Apr 2009 08:50:30 -0700 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <49EC9074.9050808@redhat.com> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC3EC4.6020300@freenet.de> <1240223320.24291.62.camel@ellert.tsl.uu.se> <49EC9074.9050808@redhat.com> Message-ID: <49EC99C6.10203@gmail.com> Tom "spot" Callaway wrote: > On 04/20/2009 06:28 AM, Mattias Ellert wrote: >> The question at hand is not whether the tarball contains inlined or >> detached licenses. The question is which tarball the guideline refers >> to. If it is the large upstream installer it does include a detached >> license file. If it is the extracted tarball it does not. > > *puts on his Fedora Legal hat* > > Does the tarball that you're using as Source0 (or whatever Source lines > are in the spec) contain a separate (and relevant) license text file? If > so, you MUST have it as %doc. If not, you (the packager) can choose to > add it to the package as %doc if you want, but you are NOT required to > do so. > But the packager is generating the tarball listed in Source0....so wouldn't this then be that the packager must include the license from the original upstream tarball used to generate the Source0 tarball. And preferably, they should include that license in the Source0 tarball? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Mon Apr 20 16:06:28 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 20 Apr 2009 18:06:28 +0200 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <49EC99C6.10203@gmail.com> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC3EC4.6020300@freenet.de> <1240223320.24291.62.camel@ellert.tsl.uu.se> <49EC9074.9050808@redhat.com> <49EC99C6.10203@gmail.com> Message-ID: <49EC9D84.5080703@freenet.de> Toshio Kuratomi wrote: > Tom "spot" Callaway wrote: >> On 04/20/2009 06:28 AM, Mattias Ellert wrote: >>> The question at hand is not whether the tarball contains inlined or >>> detached licenses. The question is which tarball the guideline refers >>> to. If it is the large upstream installer it does include a detached >>> license file. If it is the extracted tarball it does not. >> *puts on his Fedora Legal hat* >> >> Does the tarball that you're using as Source0 (or whatever Source lines >> are in the spec) contain a separate (and relevant) license text file? If >> so, you MUST have it as %doc. If not, you (the packager) can choose to >> add it to the package as %doc if you want, but you are NOT required to >> do so. >> > But the packager is generating the tarball listed in Source0....so > wouldn't this then be that the packager must include the license from > the original upstream tarball used to generate the Source0 tarball. If the original tarball contains one, yes. > And > preferably, they should include that license in the Source0 tarball? IMO, not only "preferable", but they likely must include it, because their works is a derivative work of other parties. From a.badger at gmail.com Mon Apr 20 15:56:51 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 20 Apr 2009 08:56:51 -0700 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: <49E61628.7070104@redhat.com> References: <49E61628.7070104@redhat.com> Message-ID: <49EC9B43.1050004@gmail.com> Tom "spot" Callaway wrote: > On 04/15/2009 12:00 PM, Jason L Tibbitts III wrote: >> Well, obviously that didn't work. It looks to me as if the set of >> time requirements simply can't be satisfied, but to be sure we need to >> have everyone post the times they're available so that we can try to >> find an acceptable time without regard to what's going on in the >> meeting channel. >> >> Please keep all times in UTC and only list out times when you will be >> available both with and without DST/Summer time (so we don't lose >> people during the transition time). > > Here is my availability: > > Mondays: Between 12:00 UTC (8:00 AM EDT) and 15:00 UTC (11:00 AM EDT) > Between 16:00 UTC (12:00 PM EDT) and 18:00 UTC (2:00 PM EDT) > Between 19:00 UTC (3:00 PM EDT) and 03:00 UTC (11:00 PM EDT) > Tuesdays: Between 12:00 UTC (8:00 AM EDT) and 18:00 UTC (2:00 PM EDT) > Between 19:00 UTC (3:00 PM EDT) and 03:00 UTC (11:00 PM EDT) > Wednesdays: Between 12:00 UTC (8:00 AM EDT) and 03:00 UTC (11:00 PM EDT) > Thursdays: Between 12:00 UTC (8:00 AM EDT) and 03:00 UTC (11:00 PM EDT) > Fridays: Between 12:00 UTC (8:00 AM EDT) and 14:00 UTC (10:00 AM EDT) > Between 15:30 UTC (11:30 AM EDT) and 18:00 UTC (2:00 PM EDT) > Between 19:00 UTC (3:00 PM EDT) and 03:00 UTC (11:00 PM EDT) > > My weekends are far less predictable. I would greatly prefer that we > held the meeting during the week. > Monday, Tuesday: Between 16:00UTC (8:00AM PST/9:00 PDT) and 7:00UTC (10:00PM PST/11:00PM PDT) Wednesday: Between 17:00UTC (9:00AM PST/10:00 PDT) and 7:00UTC (10:00PM PST/ 11:00PM PDT) Thursday: Between 16:00UTC (8:00AM PST/9:00 PDT) and 20:00UTC (11:00 AM PST/Noon PDT) Between 21:00UTC (Noon PST/1:00PM PDT) and 7:00UTC (10:00PM PST/11:00PM PDT) Friday: 16:00UTC (8:00AM PST/9:00 PDT) to 7:00UTC (10:00PM PST/ 11:00PM PDT) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From tcallawa at redhat.com Mon Apr 20 16:27:50 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 20 Apr 2009 12:27:50 -0400 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <49EC99C6.10203@gmail.com> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC3EC4.6020300@freenet.de> <1240223320.24291.62.camel@ellert.tsl.uu.se> <49EC9074.9050808@redhat.com> <49EC99C6.10203@gmail.com> Message-ID: <49ECA286.6070108@redhat.com> On 04/20/2009 11:50 AM, Toshio Kuratomi wrote: > But the packager is generating the tarball listed in Source0....so > wouldn't this then be that the packager must include the license from > the original upstream tarball used to generate the Source0 tarball. And > preferably, they should include that license in the Source0 tarball? Hmm. Okay, yeah, if the packager is making a custom tarball from the larger one, they should include the license text in the custom tarball. ~spot From oget.fedora at gmail.com Mon Apr 20 16:54:08 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Mon, 20 Apr 2009 12:54:08 -0400 Subject: [Fedora-packaging] Re: Packaging of license file in case of extracted sources Message-ID: On 04/20/2009 06:28 AM, Mattias Ellert wrote: > The question at hand is not whether the tarball contains inlined or > detached licenses. The question is which tarball the guideline refers > to. If it is the large upstream installer it does include a detached > license file. If it is the extracted tarball it does not. I want to make clear that the disagreement does not depend on whether we extract source tarballs from a larger tree or not. Let me talk over a toy example to demonstrate the situation: Suppose I am packaging MyApp. MyApp source tree has this layout: src/A/ src/B/ I am making MyApp-A and MyApp-B subpackages. Now there is a COPYING file under src/A/ Should I put that COPYING file into the %doc of the MyApp-B package, if - B requires A? - B doesn't require A? Let's make this clear, so that we can apply the general consensus on the new packages. Orcan From mattias.ellert at fysast.uu.se Mon Apr 20 17:03:45 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Mon, 20 Apr 2009 19:03:45 +0200 Subject: [Fedora-packaging] Re: Packaging of license file in case of extracted sources In-Reply-To: References: Message-ID: <65CFE42A-0AA3-4613-80C0-BB70A593CCE9@fysast.uu.se> 20 apr 2009 kl. 18.54 skrev Orcan Ogetbil: > On 04/20/2009 06:28 AM, Mattias Ellert wrote: >> The question at hand is not whether the tarball contains inlined or >> detached licenses. The question is which tarball the guideline refers >> to. If it is the large upstream installer it does include a detached >> license file. If it is the extracted tarball it does not. > > I want to make clear that the disagreement does not depend on whether > we extract source tarballs from a larger tree or not. > > Let me talk over a toy example to demonstrate the situation: > > Suppose I am packaging MyApp. MyApp source tree has this layout: > src/A/ > src/B/ > I am making MyApp-A and MyApp-B subpackages. Now there is a COPYING > file under src/A/ > > Should I put that COPYING file into the %doc of the MyApp-B package, > if > > - B requires A? > - B doesn't require A? > > Let's make this clear, so that we can apply the general consensus on > the new packages. > > Orcan I can add to this that when using the upstream install script (which is not used in the RPM packaging) the license file in src/A is not installed in a package specific directory like $prefix/share/doc/A, which is the case for all other documentation, but directly in $prefix, indicating that it is upstream's intention that this license file is intended to cover the code of the full installer, and not only the code in src/A. Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1444 bytes Desc: not available URL: From a.badger at gmail.com Mon Apr 20 17:19:08 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 20 Apr 2009 10:19:08 -0700 Subject: [Fedora-packaging] Re: Packaging of license file in case of extracted sources In-Reply-To: <65CFE42A-0AA3-4613-80C0-BB70A593CCE9@fysast.uu.se> References: <65CFE42A-0AA3-4613-80C0-BB70A593CCE9@fysast.uu.se> Message-ID: <49ECAE8C.7030309@gmail.com> Mattias Ellert wrote: > 20 apr 2009 kl. 18.54 skrev Orcan Ogetbil: > >> On 04/20/2009 06:28 AM, Mattias Ellert wrote: >>> The question at hand is not whether the tarball contains inlined or >>> detached licenses. The question is which tarball the guideline refers >>> to. If it is the large upstream installer it does include a detached >>> license file. If it is the extracted tarball it does not. >> >> I want to make clear that the disagreement does not depend on whether >> we extract source tarballs from a larger tree or not. >> >> Let me talk over a toy example to demonstrate the situation: >> >> Suppose I am packaging MyApp. MyApp source tree has this layout: >> src/A/ >> src/B/ >> I am making MyApp-A and MyApp-B subpackages. Now there is a COPYING >> file under src/A/ >> >> Should I put that COPYING file into the %doc of the MyApp-B package, if >> >> - B requires A? >> - B doesn't require A? >> >> Let's make this clear, so that we can apply the general consensus on >> the new packages. >> There's going to be differing thoughts on this depending on the circumstances. We need several specific examples to look at before we can come up with a general answer. > > I can add to this that when using the upstream install script (which is > not used in the RPM packaging) the license file in src/A is not > installed in a package specific directory like $prefix/share/doc/A, > which is the case for all other documentation, but directly in $prefix, > indicating that it is upstream's intention that this license file is > intended to cover the code of the full installer, and not only the code > in src/A. > Please send bugzilla ids. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From christoph.wickert at googlemail.com Mon Apr 20 17:26:30 2009 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 20 Apr 2009 19:26:30 +0200 Subject: [Fedora-packaging] How to create a subdir in %{_docdir}/%{name}-%{version} Message-ID: <1240248390.3337.43.camel@localhost.localdomain> Hi, I want to create an "examples" folder inside %{_docdir}/%{name}-%{version}. Here is my test case: > %install > mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/ > touch $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/test > > %files -f %{name}.lang > %defattr(-,root,root,-) > %doc AUTHORS COPYING ChangeLog README > %doc %{_docdir}/%{name}-%{version}/examples/ This wont work as the first %doc line deletes and re-creates %{_docdir}/%{name}-%{version}, so rpmbuild will fail with: "... /usr/share/doc/foo/examples/test: cpio: Bad magic" Any idea how I can have a subdir then? Christoph From tcallawa at redhat.com Mon Apr 20 17:26:30 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 20 Apr 2009 13:26:30 -0400 Subject: [Fedora-packaging] How to create a subdir in %{_docdir}/%{name}-%{version} In-Reply-To: <1240248390.3337.43.camel@localhost.localdomain> References: <1240248390.3337.43.camel@localhost.localdomain> Message-ID: <49ECB046.6020404@redhat.com> On 04/20/2009 01:26 PM, Christoph Wickert wrote: > Hi, > > I want to create an "examples" folder inside > %{_docdir}/%{name}-%{version}. Here is my test case: > >> %install >> mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/ >> touch $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/test >> >> %files -f %{name}.lang >> %defattr(-,root,root,-) >> %doc AUTHORS COPYING ChangeLog README >> %doc %{_docdir}/%{name}-%{version}/examples/ > > This wont work as the first %doc line deletes and re-creates > %{_docdir}/%{name}-%{version}, so rpmbuild will fail with: > "... /usr/share/doc/foo/examples/test: cpio: Bad magic" > > Any idea how I can have a subdir then? Off the top of my head: %install mkdir -p examples/ touch examples/test %files -f %{name}.lang %defattr(-,root,root,-) %doc AUTHORS COPYING ChangeLog README examples/ ~spot From mattias.ellert at fysast.uu.se Mon Apr 20 17:30:38 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Mon, 20 Apr 2009 19:30:38 +0200 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <49EC7184.2030505@gmail.com> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC7184.2030505@gmail.com> Message-ID: 20 apr 2009 kl. 14.58 skrev Toshio Kuratomi: > Mattias Ellert wrote: > >> Here is a description of the problem at hand: >> >> When upstream distributes sources in a gigantic installer >> containing the >> sources for 300+ packages it doesn't make sense to include this full >> tarfile for each SRPM, since less than 1% of it is used to compile >> each >> package. Instead the relevant subdirectory is extracted from this >> beast >> (properly documented in the specfile in accordance to the packaging >> guidelines). >> > > What's the bugzilla URL? I think people have answered the licence > question pretty well but I'm curious to see how the split up of the > 300+ > packages is being accomplished. That seems like it would be a more > contentious area. > > -Toshio Here is the reviewer saying "Will not approve package unless license file is removed": https://bugzilla.redhat.com/show_bug.cgi?id=467235 Here is the reviewer saying "Will not approve package unless license file is added": https://bugzilla.redhat.com/show_bug.cgi?id=478917 The specfiles for the two packages are almost identical. The split of the huge upstream installer was not an issue with either reviewer, except one of them requested it should be better documented - after implementing that he was happy. Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1444 bytes Desc: not available URL: From jussi.lehtola at iki.fi Mon Apr 20 19:26:05 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Mon, 20 Apr 2009 22:26:05 +0300 Subject: [Fedora-packaging] How to create a subdir in %{_docdir}/%{name}-%{version} In-Reply-To: <1240248390.3337.43.camel@localhost.localdomain> References: <1240248390.3337.43.camel@localhost.localdomain> Message-ID: <1240255565.3170.2.camel@localhost.localdomain> On Mon, 2009-04-20 at 19:26 +0200, Christoph Wickert wrote: > Hi, > > I want to create an "examples" folder inside > %{_docdir}/%{name}-%{version}. Here is my test case: > > > %install > > mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/ > > touch $RPM_BUILD_ROOT%{_docdir}/%{name}-%{version}/examples/test > > > > %files -f %{name}.lang > > %defattr(-,root,root,-) > > %doc AUTHORS COPYING ChangeLog README > > %doc %{_docdir}/%{name}-%{version}/examples/ > > This wont work as the first %doc line deletes and re-creates > %{_docdir}/%{name}-%{version}, so rpmbuild will fail with: > "... /usr/share/doc/foo/examples/test: cpio: Bad magic" > > Any idea how I can have a subdir then? > Christoph Simple: don't install examples/ in %docdir manually, instead include it in the %files section of %doc. Example: tarball contents is foo-0.1.0/ foo-0.1.0/foo.c foo-0.1.0/COPYING foo-0.1.0/examples/ foo-0.1.0/examples/run.me then your %doc section reads: %doc COPYING examples/ -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From a.badger at gmail.com Mon Apr 20 21:57:24 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 20 Apr 2009 14:57:24 -0700 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC7184.2030505@gmail.com> Message-ID: <49ECEFC4.7060509@gmail.com> Mattias Ellert wrote: > 20 apr 2009 kl. 14.58 skrev Toshio Kuratomi: > >> Mattias Ellert wrote: >> >>> Here is a description of the problem at hand: >>> >>> When upstream distributes sources in a gigantic installer containing the >>> sources for 300+ packages it doesn't make sense to include this full >>> tarfile for each SRPM, since less than 1% of it is used to compile each >>> package. Instead the relevant subdirectory is extracted from this beast >>> (properly documented in the specfile in accordance to the packaging >>> guidelines). >>> >> >> What's the bugzilla URL? I think people have answered the licence >> question pretty well but I'm curious to see how the split up of the 300+ >> packages is being accomplished. That seems like it would be a more >> contentious area. >> >> -Toshio > > > Here is the reviewer saying "Will not approve package unless license > file is removed": > https://bugzilla.redhat.com/show_bug.cgi?id=467235 > > Here is the reviewer saying "Will not approve package unless license > file is added": > https://bugzilla.redhat.com/show_bug.cgi?id=478917 > > The specfiles for the two packages are almost identical. > > The split of the huge upstream installer was not an issue with either > reviewer, except one of them requested it should be better documented - > after implementing that he was happy. > Ugh, upstream does put you in a bit of a bind, don't they? :-( I think that you're pretty clearly in violation of this guideline: https://fedoraproject.org/wiki/Packaging/SourceURL#Referencing_Source Have you asked upstream whether they'd consider releasing individual tarballs for all components? Since they release individual update tarballs, this might be an oversight rather than something that they don't want to do. This would be the ideal outcome for us. If they won't do this, there's a couple things you could do: 1) Package the monolithic tarball and remove the extraneous library sources at buildtime. You'd put each component into a subpackage of the main package (so far the same as any other package). When upstream releases one of their update tarballs with just an individual component, you'd include that as a separate Source. 2) Make separate packages each using the same tarball (unless an update tarball was released with just that component). This doesn't take up much more room on the server (since the huge tarball will have the same name and md5sum) but it does make building locally a bit more painful. 3) Ask the packaging Committee for an exception to the Source Rule so you can modify the source tarball as you're doing now. As for the specific licensing case. When the packager is doing the splitting of the tarball I think that Ralf's note that you may be legally obligated to copy the license file into the new tarball carries a lot of weight. If you have to keep splitting the tarball at the packager level I'd amend the instructions for generating the Source0 tarball to copy the license file from the upstream source in addition to the module directory. For the case of packages and subpackages that Orcan speaks of, when a Requires between a subpackage and another package built from the same RPM exists, we don't need to include the license file in both binary packages. When there is not a Requires, we still have a relationship among packages via the SRPM and we could use a -common subpackage or a main package (which is the most common usage) that has the licenses. The FPC touched briefly on this when discussing Duplicate Files:: https://fedoraproject.org/wiki/Packaging:Minutes/20090217#t12:18 As yet, no one has brought to our attention a specific, real life package to work on as a corner case yet. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mattias.ellert at fysast.uu.se Tue Apr 21 05:47:03 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Tue, 21 Apr 2009 07:47:03 +0200 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <49ECEFC4.7060509@gmail.com> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC7184.2030505@gmail.com> <49ECEFC4.7060509@gmail.com> Message-ID: <1240292823.2894.37.camel@ellert.tsl.uu.se> m?n 2009-04-20 klockan 14:57 -0700 skrev Toshio Kuratomi: > Mattias Ellert wrote: > > 20 apr 2009 kl. 14.58 skrev Toshio Kuratomi: > >> > >> What's the bugzilla URL? I think people have answered the licence > >> question pretty well but I'm curious to see how the split up of the 300+ > >> packages is being accomplished. That seems like it would be a more > >> contentious area. > >> > >> -Toshio > > > > > > Here is the reviewer saying "Will not approve package unless license > > file is removed": > > https://bugzilla.redhat.com/show_bug.cgi?id=467235 > > > > Here is the reviewer saying "Will not approve package unless license > > file is added": > > https://bugzilla.redhat.com/show_bug.cgi?id=478917 > > > > The specfiles for the two packages are almost identical. > > > > The split of the huge upstream installer was not an issue with either > > reviewer, except one of them requested it should be better documented - > > after implementing that he was happy. > > > Ugh, upstream does put you in a bit of a bind, don't they? :-( Thank you for pointing out the obvious. > I think that you're pretty clearly in violation of this guideline: > https://fedoraproject.org/wiki/Packaging/SourceURL#Referencing_Source I don't see the violation here. The page clearly states what you have to do if upstream does not provide the source tarball for your package. The recipe is to state the commands needed to reproduce the tarball from what is provided by upstream, which is exactly what is done in this case. Quoting the guideline verbatim: "There are several cases where upstream is not providing the source to you in an upstream tarball. In these cases you must document how to generate the tarball used in the rpm either through a spec file comment or a script included as a separate SourceX." After which follows a few examples. There is no substantial difference between the example stated on the page: # The source for this package was pulled from upstream's vcs. Use the # following commands to generate the tarball: # svn export -r 250 http://www.example.com/svn/foo/trunk foo-20070221 # tar -czvf foo-20070221.tar.gz foo-20070221 Source0: foo-20070221.tar.gz and the description in for extracting the source in this case: # Source is extracted from the globus toolkit installer: # wget -N http://www-unix.globus.org/ftppub/gt4/4.2.1/installers/src/gt4.2.1-all-source-installer.tar.bz2 # tar -jxf gt4.2.1-all-source-installer.tar.bz2 # mv gt4.2.1-all-source-installer/source-trees/core/source globus_core-5.15 # tar -zcf globus_core-5.15.tar.gz globus_core-5.15 Source: %{_name}-%{version}.tar.gz So the way the source is extracted and how it is documented is within the existing guidelines. Three different reviewers have already approved packages where the source has been created and documented in this way. > Have you asked upstream whether they'd consider releasing individual > tarballs for all components? Since they release individual update > tarballs, this might be an oversight rather than something that they > don't want to do. This would be the ideal outcome for us. > > If they won't do this, there's a couple things you could do: > > 1) Package the monolithic tarball and remove the extraneous library > sources at buildtime. You'd put each component into a subpackage of the > main package (so far the same as any other package). When upstream > releases one of their update tarballs with just an individual component, > you'd include that as a separate Source. This won't work. Each package expects that the previous packages it depends on are already installed in the final location when it is built. The upstream installer script does: configure A, make A, make install A, configure B, make B, make install B, and so on. Besides, each package has a separate version number, and I haven't seen an SRPM building packages with different version numbers yet. And do you really want an SRPM building something like 600-800 binary packages? Apart from these technical objections, such a package would be almost unmaintainable. You are not the first one to suggest this, but it is really the wrong thing to do. > 2) Make separate packages each using the same tarball (unless an update > tarball was released with just that component). This doesn't take up > much more room on the server (since the huge tarball will have the same > name and md5sum) but it does make building locally a bit more painful. The lookaside cache http://cvs.fedoraproject.org/repo/pkgs/ is unfortunately split per package, so this will not save any space on the Fedora server. The really huge waste would of course be that this huge unused piece of code would be inside each SRPM and replicated to all Fedora mirrors wasting both bandwidth and disk space. So this is also not the right thing to do. > 3) Ask the packaging Committee for an exception to the Source Rule so > you can modify the source tarball as you're doing now. I fail to see where the exception is (see above). > As for the specific licensing case. When the packager is doing the > splitting of the tarball I think that Ralf's note that you may be > legally obligated to copy the license file into the new tarball carries > a lot of weight. If you have to keep splitting the tarball at the > packager level I'd amend the instructions for generating the Source0 > tarball to copy the license file from the upstream source in addition to > the module directory. To summarize this thread, I conclude that the majority thinks that the license file must be part of the package. I also conclude that rather than being made a separate source file (which is how it was originally implemented) the license file should be copied into and made part of the extracted source tarball. Is this a correct assessment of the view of the members of this list? > -Toshio Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2272 bytes Desc: not available URL: From a.badger at gmail.com Tue Apr 21 06:13:55 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 20 Apr 2009 23:13:55 -0700 Subject: [Fedora-packaging] Packaging of license file in case of extracted sources In-Reply-To: <1240292823.2894.37.camel@ellert.tsl.uu.se> References: <1240214474.24291.31.camel@ellert.tsl.uu.se> <49EC7184.2030505@gmail.com> <49ECEFC4.7060509@gmail.com> <1240292823.2894.37.camel@ellert.tsl.uu.se> Message-ID: <49ED6423.9030008@gmail.com> Mattias Ellert wrote: > m?n 2009-04-20 klockan 14:57 -0700 skrev Toshio Kuratomi: >> Mattias Ellert wrote: >>> 20 apr 2009 kl. 14.58 skrev Toshio Kuratomi: >>>> What's the bugzilla URL? I think people have answered the licence >>>> question pretty well but I'm curious to see how the split up of the 300+ >>>> packages is being accomplished. That seems like it would be a more >>>> contentious area. >>>> >>>> -Toshio >>> >>> Here is the reviewer saying "Will not approve package unless license >>> file is removed": >>> https://bugzilla.redhat.com/show_bug.cgi?id=467235 >>> >>> Here is the reviewer saying "Will not approve package unless license >>> file is added": >>> https://bugzilla.redhat.com/show_bug.cgi?id=478917 >>> >>> The specfiles for the two packages are almost identical. >>> >>> The split of the huge upstream installer was not an issue with either >>> reviewer, except one of them requested it should be better documented - >>> after implementing that he was happy. >>> >> Ugh, upstream does put you in a bit of a bind, don't they? :-( > > Thank you for pointing out the obvious. > >> I think that you're pretty clearly in violation of this guideline: >> https://fedoraproject.org/wiki/Packaging/SourceURL#Referencing_Source > > I don't see the violation here. The page clearly states what you have to > do if upstream does not provide the source tarball for your package. The > recipe is to state the commands needed to reproduce the tarball from > what is provided by upstream, which is exactly what is done in this > case. Quoting the guideline verbatim: > > "There are several cases where upstream is not providing the source to > you in an upstream tarball. In these cases you must document how to > generate the tarball used in the rpm either through a spec file comment > or a script included as a separate SourceX." > The difference is that in this case, upstream is providing you with a tarball. [...] >> Have you asked upstream whether they'd consider releasing individual >> tarballs for all components? Since they release individual update >> tarballs, this might be an oversight rather than something that they >> don't want to do. This would be the ideal outcome for us. >> I love how everyone I talk to about guidelines violations ignores my upstream comment :-/ Upstream is the first thing to try in any situation. Has this been tried here? [...] >> 3) Ask the packaging Committee for an exception to the Source Rule so >> you can modify the source tarball as you're doing now. > > I fail to see where the exception is (see above). > Failing upstream cooperation, this seems like the best option. > > To summarize this thread, I conclude that the majority thinks that the > license file must be part of the package. I also conclude that rather > than being made a separate source file (which is how it was originally > implemented) the license file should be copied into and made part of the > extracted source tarball. > > Is this a correct assessment of the view of the members of this list? > Yes. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jussi.lehtola at iki.fi Tue Apr 21 19:42:22 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Tue, 21 Apr 2009 22:42:22 +0300 Subject: [Fedora-packaging] Sysreport is still in rawhide - why? Message-ID: <1240342942.3177.1.camel@localhost.localdomain> Hi, why is sysreport still available in rawhide? # yum --enablerepo=rawhide list sysreport Loaded plugins: downloadonly, refresh-packagekit Available Packages sysreport.noarch 1.4.4-3 rawhide # yum install sysreport Loaded plugins: downloadonly, refresh-packagekit Setting up Install Process Parsing package install arguments Package sysreport is obsoleted by sos, trying to install sos-1.8-9.fc10.noarch instead Package sos-1.8-9.fc10.noarch already installed and latest version Nothing to do -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From rdieter at math.unl.edu Tue Apr 21 19:47:48 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 21 Apr 2009 14:47:48 -0500 Subject: [Fedora-packaging] Sysreport is still in rawhide - why? In-Reply-To: <1240342942.3177.1.camel@localhost.localdomain> References: <1240342942.3177.1.camel@localhost.localdomain> Message-ID: <49EE22E4.9050905@math.unl.edu> Jussi Lehtola wrote: > why is sysreport still available in rawhide? Obsolete'ing a package is only part of the EOL process: http://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife -- Rex From a.badger at gmail.com Wed Apr 22 00:35:49 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 21 Apr 2009 17:35:49 -0700 Subject: [Fedora-packaging] Packaging guideline draft for globus toolkit Message-ID: <49EE6665.8070208@gmail.com> Mattias Ellert has proposed guidelines for packaging things from the Globus toolkit. It's a long document so I figured I'd give people a heads up so you don't come to the Meeting expecting to read it all there ;-) I've added a few small comments to the talk page: https://fedoraproject.org/wiki/Talk:PackagingDrafts/Globus Since I'm writing this, I'll add them here as well: * Could ./globus-spec.pl be put into a package? * Obtaining sources should also include copying over the the license file Mattias, let me know if it's better for you to have discussion on fedora-packaging list or on the talk page. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Wed Apr 22 06:50:40 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 21 Apr 2009 23:50:40 -0700 Subject: [Fedora-packaging] New Draft Packaging Guideline - Fixing Gconf schema registration In-Reply-To: References: Message-ID: <49EEBE40.4030604@gmail.com> Shawn Starr wrote: > Hello everyone, > > I have created a draft guideline using OpenSuSE's existing macros.gconf2 script for Fedora. > > You can find this at: https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf > > I have done an initial test with the .spec file mentioned as an example in this draft. Seems to work fine. Since this the first iteration, I would like people to comment so we can get this finalized for Fedora 12 and rejoice in speedy installs and yum updates. > I've added some more comments to the page along with a possibility for simpler rpm macros that don't use %posttrans since that doesn't seem to have any speed gains. Note that I've never coded rpm macros before and I haven't tested them (gotta sleep sometime): https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf#Compare_gconf_schemas mclasen, would the new macros or something like them be acceptable to you? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mclasen at redhat.com Wed Apr 22 14:02:23 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 22 Apr 2009 10:02:23 -0400 Subject: [Fedora-packaging] New Draft Packaging Guideline - Fixing Gconf schema registration In-Reply-To: <49EEBE40.4030604@gmail.com> References: <49EEBE40.4030604@gmail.com> Message-ID: <1240408943.4334.3.camel@localhost.localdomain> On Tue, 2009-04-21 at 23:50 -0700, Toshio Kuratomi wrote: > > https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf#Compare_gconf_schemas > > mclasen, would the new macros or something like them be acceptable to you? > Sure, looks fine to me in general. Small nit: I think for the 'obsoleting schema1' case, you need to have some "if [ -f "$schema" ]; " in there somewhere, since you don't know which version was previously installed. That also brings up the point that it is hard to know when to drop this obsoleting call, but that is nothing new and not that important, it happens relatively rarely that schemas get dropped. In %gconf_schema_upgrade, I think you want to remove to copy in /var/lib/rpm-state/gconf regardless of the outcome of the comparison. As far as owning the directory, I think it should be owned by whichever package ends up installing the macros. From a.badger at gmail.com Wed Apr 22 16:34:34 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 22 Apr 2009 09:34:34 -0700 Subject: [Fedora-packaging] New Draft Packaging Guideline - Fixing Gconf schema registration In-Reply-To: <1240408943.4334.3.camel@localhost.localdomain> References: <49EEBE40.4030604@gmail.com> <1240408943.4334.3.camel@localhost.localdomain> Message-ID: <49EF471A.7060006@gmail.com> Matthias Clasen wrote: > On Tue, 2009-04-21 at 23:50 -0700, Toshio Kuratomi wrote: > >> https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf#Compare_gconf_schemas >> >> mclasen, would the new macros or something like them be acceptable to you? >> > > Sure, looks fine to me in general. > > Small nit: I think for the 'obsoleting schema1' case, you need to have > some "if [ -f "$schema" ]; " in there somewhere, since you don't know > which version was previously installed. > Thanks, I was relying too much on >/dev/null || : to protect us. Fixed now. > That also brings up the point that it is hard to know when to drop this > obsoleting call, but that is nothing new and not that important, it > happens relatively rarely that schemas get dropped. > Yeah, we currently leave that up to the maintainer (by not mentioning it at all). If you have thoughts on how long is good enough, I'll be happy to add a note about it. > In %gconf_schema_upgrade, I think you want to remove to copy > in /var/lib/rpm-state/gconf regardless of the outcome of the comparison. > Good catch. Fixed. > As far as owning the directory, I think it should be owned by whichever > package ends up installing the macros. > Sounds right. The only constraint is that the macros are needed at build time and the directory is needed at install time. So if we put it in the GConf2 package, we'd want to add it to the BuildRequires. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From oget.fedora at gmail.com Wed Apr 22 16:56:31 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Wed, 22 Apr 2009 12:56:31 -0400 Subject: [Fedora-packaging] about compiler flags Message-ID: I have 2 questions. The first one is brought to my attention by a first time reviewer and he has got an interesting point. The guidelines at https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags say: "Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases." As you probably know that some packages add their own compiler flags on top of what we specified as %optflags. Until now, I did not do anything about these flags unless they override our %optflags. Now, having a second thought, I realized that the above statement can be interpreted in two ways: 1- The extra flags are added by the packager: This is the way I used to interpret the guideline, and I always document if I add additional flags on top of %{optflags} 2- The extra flags are added by the build script of upstream: Here is the question: Do we need to document such cases in the specfile? I know that we have hundreds (maybe thousands) of packages which don't document this case in the specfile. Are such packages violating the above guideline? Second question: From the same link above: "Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration." Does this apply to the stage where the compiler is doing the linking, i.e: "gcc -shared -lthis -lthat..."? Do we need to honor %optflags in this stage too? Again, I know many packages that don't pass %optflags to the compiler during the linking. Do these pakcages violate the guideline? Orcan From oget.fedora at gmail.com Fri Apr 24 19:22:04 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Fri, 24 Apr 2009 15:22:04 -0400 Subject: [Fedora-packaging] Re: about compiler flags In-Reply-To: References: Message-ID: I sent this email to fedora-packaging a couple days ago. I thought I CC'd the devel list but apparently I didn't. It consists of two issues, related to possible different interpretations of the guideline about compiler flags. I would like to have these clarified. On Wed, Apr 22, 2009 at 12:56 PM, Orcan Ogetbil wrote: > I have 2 questions. The first one is brought to my attention by a > first time reviewer and he has got an interesting point. > > The guidelines at > https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags > say: > "Adding to and overriding or filtering parts of these flags is > permitted if there's a good reason to do so; the rationale for doing > so should be reviewed and documented in the specfile especially in the > override and filter cases." > > As you probably know that some packages add their own compiler flags > on top of what we specified as %optflags. Until now, I did not do > anything about these flags unless they override our %optflags. Now, > having a second thought, I realized that the above statement can be > interpreted in two ways: > > 1- The extra flags are added by the packager: This is the way I used > to interpret the guideline, and I always document if I add additional > flags on top of %{optflags} > 2- The extra flags are added by the build script of upstream: Here is > the question: Do we need to document such cases in the specfile? I > know that we have hundreds (maybe thousands) of packages which don't > document this case in the specfile. Are such packages violating the > above guideline? > > > Second question: From the same link above: > "Compilers used to build packages should honor the applicable compiler > flags set in the system rpm configuration." > > Does this apply to the stage where the compiler is doing the linking, > i.e: "gcc -shared -lthis -lthat..."? Do we need to honor %optflags in > this stage too? Again, I know many packages that don't pass %optflags > to the compiler during the linking. Do these pakcages violate the > guideline? > > Orcan > From forum at ru.bir.ru Fri Apr 24 20:31:14 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Sat, 25 Apr 2009 00:31:14 +0400 Subject: [Fedora-packaging] Re: about compiler flags In-Reply-To: References: Message-ID: Orcan Ogetbil ?????: > I have 2 questions. The first one is brought to my attention by a > first time reviewer and he has got an interesting point. > > The guidelines at > https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags > say: > "Adding to and overriding or filtering parts of these flags is > permitted if there's a good reason to do so; the rationale for doing > so should be reviewed and documented in the specfile especially in the > override and filter cases." > > As you probably know that some packages add their own compiler flags > on top of what we specified as %optflags. Until now, I did not do > anything about these flags unless they override our %optflags. Now, > having a second thought, I realized that the above statement can be > interpreted in two ways: As I can understand primarily this required for the allowing Fedora set of optimisation for current platform, for which package build. So, in case when maintainer add flags which is important fo building, performance, or changed as some workaround to bug - it is acceptable, but need comment. Otherwise, we MUST rewrite developer flags to fedora default %optflags. Michael Schwendt point me in one of my own review request to this guidelines: https://bugzilla.redhat.com/show_bug.cgi?id=454980#c37 From oget.fedora at gmail.com Fri Apr 24 20:52:50 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Fri, 24 Apr 2009 16:52:50 -0400 Subject: [Fedora-packaging] Re: about compiler flags In-Reply-To: References: Message-ID: On Fri, Apr 24, 2009 at 4:31 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > > As I can understand primarily this required for the allowing Fedora set of > optimisation for current platform, for which package build. So, in case when > maintainer add flags which is important fo building, performance, or changed > as some workaround to bug - it is acceptable, but need comment. Otherwise, > we MUST rewrite developer flags to fedora default %optflags. > > Michael Schwendt point me in one of my own review request to this > guidelines: https://bugzilla.redhat.com/show_bug.cgi?id=454980#c37 > I just took two random examples from the first page of koji (no offence to anyone): 1- From the qt-4.5.1-3 build on x86_64: http://koji.fedoraproject.org/koji/taskinfo?taskID=1319567 g++ -c -m64 -pipe -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall -W -I../../../mkspecs/linux-g++-64 -I. -I/usr/X11R6/include -I. -o xrandr.o xrandr.cpp Here -W needs to be removed? 2- From the lxpanel-0.4.0-1 build on i586: http://koji.fedoraproject.org/koji/buildinfo?buildID=99531 /bin/sh ../../../libtool --tag=CC --mode=link gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables -module -avoid-version -rpath /usr/lib/lxpanel/plugins -no-undefined -export-symbols-regex "^[^_].*" -Wl,--as-needed -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,--sort-common -o netstatus.la -rpath /usr/lib/lxpanel/plugins netstatus-sysdeps.lo glade-support.lo netstatus-dialog-ui.lo netstatus-icon.lo netstatus-util.lo netstatus.lo netstatus-enums.lo netstatus-iface.lo netstatus-dialog.lo -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lmenu-cache -lglib-2.0 Here, "-fasynchronous-unwind-tables -module -avoid-version -rpath /usr/lib/lxpanel/plugins -no-undefined -export-symbols-regex "^[^_].*" -Wl,--as-needed -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,--sort-common -rpath /usr/lib/lxpanel/plugins" need to be removed? If what you are saying is correct, we need to "fix" hundreds of packages. Are you sure that's the right way? Orcan From pertusus at free.fr Fri Apr 24 20:58:11 2009 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 24 Apr 2009 22:58:11 +0200 Subject: [Fedora-packaging] Re: about compiler flags In-Reply-To: References: Message-ID: <20090424205811.GE4978@free.fr> On Fri, Apr 24, 2009 at 04:52:50PM -0400, Orcan Ogetbil wrote: > Here, "-fasynchronous-unwind-tables -module -avoid-version -rpath > /usr/lib/lxpanel/plugins -no-undefined -export-symbols-regex "^[^_].*" > -Wl,--as-needed -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,--sort-common > -rpath /usr/lib/lxpanel/plugins" need to be removed? > > If what you are saying is correct, we need to "fix" hundreds of > packages. Are you sure that's the right way? Everything but -fasynchronous-unwind-tables are linker flags that are not at stake. -- Pat From forum at ru.bir.ru Sat Apr 25 05:44:52 2009 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Sat, 25 Apr 2009 09:44:52 +0400 Subject: [Fedora-packaging] Re: about compiler flags In-Reply-To: References: Message-ID: Orcan Ogetbil wrote: > If what you are saying is correct, we need to "fix" hundreds of > packages. Are you sure that's the right way? In Our packages VERY much errors and guidelines violations most of comes from long history (f.e. lots of packages has not any comments of its patches, even have many of them). I think we shouldn't expire witch-hunt now, but new packages must follow guidelines as much as possible. So, if you are not agree with that in particularly you may inspire guidelines change proposals for Fedora Package Committee. From rc040203 at freenet.de Sat Apr 25 06:48:03 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 25 Apr 2009 08:48:03 +0200 Subject: [Fedora-packaging] Re: about compiler flags In-Reply-To: References: Message-ID: <49F2B223.7000606@freenet.de> Orcan Ogetbil wrote: > On Fri, Apr 24, 2009 at 4:31 PM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: >> As I can understand primarily this required for the allowing Fedora set of >> optimisation for current platform, for which package build. So, in case when >> maintainer add flags which is important fo building, performance, or changed >> as some workaround to bug - it is acceptable, but need comment. Otherwise, >> we MUST rewrite developer flags to fedora default %optflags. >> >> Michael Schwendt point me in one of my own review request to this >> guidelines: https://bugzilla.redhat.com/show_bug.cgi?id=454980#c37 >> > > I just took two random examples from the first page of koji (no > offence to anyone): > > 1- From the qt-4.5.1-3 build on x86_64: > http://koji.fedoraproject.org/koji/taskinfo?taskID=1319567 > g++ -c -m64 -pipe -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall > -W -I../../../mkspecs/linux-g++-64 -I. -I/usr/X11R6/include -I. -o > xrandr.o xrandr.cpp > > Here -W needs to be removed? man gcc -W are harmless > 2- From the lxpanel-0.4.0-1 build on i586: > http://koji.fedoraproject.org/koji/buildinfo?buildID=99531 > /bin/sh ../../../libtool --tag=CC --mode=link gcc -O2 -g -pipe > -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic > -fasynchronous-unwind-tables -module -avoid-version -rpath > /usr/lib/lxpanel/plugins -no-undefined -export-symbols-regex "^[^_].*" > -Wl,--as-needed -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,--sort-common -o > netstatus.la -rpath /usr/lib/lxpanel/plugins netstatus-sysdeps.lo > glade-support.lo netstatus-dialog-ui.lo netstatus-icon.lo > netstatus-util.lo netstatus.lo netstatus-enums.lo netstatus-iface.lo > netstatus-dialog.lo -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 > -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo > -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 > -lgthread-2.0 -lrt -lglib-2.0 -lmenu-cache -lglib-2.0 > > Here, "-fasynchronous-unwind-tables -module -avoid-version -rpath > /usr/lib/lxpanel/plugins -no-undefined -export-symbols-regex "^[^_].*" > -Wl,--as-needed -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,--sort-common > -rpath /usr/lib/lxpanel/plugins" need to be removed? -f* flags are not harmless. -Wl,-O1 is harmless, but likely is an ugly hack around to something deeply broken inside of the code. > If what you are saying is correct, we need to "fix" hundreds of > packages. Are you sure that's the right way? Yes. Ralf From rc040203 at freenet.de Tue Apr 28 14:31:28 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 28 Apr 2009 16:31:28 +0200 Subject: [Fedora-packaging] Re: Agenda for the 2009-04-28 Packaging Committee meeting In-Reply-To: References: Message-ID: <49F71340.7010605@freenet.de> Jason L Tibbitts III wrote: > The Packaging Committee will meet Tuesday, 2009-04-14 at 17:00UTC in > the #fedora-meeting channel on chat.freenode.net. 17:00 UTC will likely not work for me. Therefore, votes and comments interspersed below > FPC works from the agenda at > https://fedoraproject.org/wiki/Packaging/GuidelinesTodo; here are some > things which should be brought up for discussion at the next meeting: > > GConf scriptlets - > https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/GConf 0 ... this proposal needs further discussion. It's way too complex and way too intrusive to be able to comment on in a short emails. > Globus - > https://fedoraproject.org/wiki/PackagingDrafts/Globus In my understanding, the globus package set is an arbitrary set of packages like many 1000 others in Fedora and therefore doesn't need specialized rules in the FPG. => My vote: -1 > Compiler Flags - > https://fedoraproject.org/wiki/Compiler_Flags_(draft) I would presume this kind of "wisdom" to be "elementary and basic knowledge", people without should not package packages for Fedora. Apart of this, this proposal is misleading ("should honor", IMO "must honor"), partially wrong (make CFLAGS=... is wrong for modern autotools based packages), ... I don't find this proposal helpful. => My vote: -1 Ralf From j.w.r.degoede at hhs.nl Tue Apr 28 18:05:43 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 28 Apr 2009 20:05:43 +0200 Subject: [Fedora-packaging] Re: Agenda for the 2009-04-28 Packaging Committee meeting In-Reply-To: <49F71340.7010605@freenet.de> References: <49F71340.7010605@freenet.de> Message-ID: <49F74577.4020303@hhs.nl> On 04/28/2009 04:31 PM, Ralf Corsepius wrote: > Jason L Tibbitts III wrote: >> The Packaging Committee will meet Tuesday, 2009-04-14 at 17:00UTC in >> the #fedora-meeting channel on chat.freenode.net. > > 17:00 UTC will likely not work for me. > I'm afraid I missed it too, sorry (note as far as I'm concerned we really need a new meeting time) Regards, Hans From tibbs at math.uh.edu Tue Apr 28 18:10:25 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 28 Apr 2009 13:10:25 -0500 Subject: [Fedora-packaging] Re: Agenda for the 2009-04-28 Packaging Committee meeting In-Reply-To: <49F74577.4020303@hhs.nl> (Hans de Goede's message of "Tue\, 28 Apr 2009 20\:05\:43 +0200") References: <49F71340.7010605@freenet.de> <49F74577.4020303@hhs.nl> Message-ID: >>>>> "HdG" == Hans de Goede writes: HdG> On 04/28/2009 04:31 PM, Ralf Corsepius wrote: HdG> I'm afraid I missed it too, sorry (note as far as I'm concerned HdG> we really need a new meeting time) But yet I don't see from you a response to the request to list out your available times. We can't choose a time unless you tell us all of the times that you are available. - J< From oget.fedora at gmail.com Tue Apr 28 19:43:29 2009 From: oget.fedora at gmail.com (Orcan Ogetbil) Date: Tue, 28 Apr 2009 15:43:29 -0400 Subject: [Fedora-packaging] Re: about compiler flags In-Reply-To: References: Message-ID: On Wed, Apr 22, 2009 at 12:56 PM, Orcan Ogetbil wrote: > I have 2 questions. The first one is brought to my attention by a > first time reviewer and he has got an interesting point. > > The guidelines at > https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags > say: > "Adding to and overriding or filtering parts of these flags is > permitted if there's a good reason to do so; the rationale for doing > so should be reviewed and documented in the specfile especially in the > override and filter cases." > > As you probably know that some packages add their own compiler flags > on top of what we specified as %optflags. Until now, I did not do > anything about these flags unless they override our %optflags. Now, > having a second thought, I realized that the above statement can be > interpreted in two ways: > > 1- The extra flags are added by the packager: This is the way I used > to interpret the guideline, and I always document if I add additional > flags on top of %{optflags} > 2- The extra flags are added by the build script of upstream: Here is > the question: Do we need to document such cases in the specfile? I > know that we have hundreds (maybe thousands) of packages which don't > document this case in the specfile. Are such packages violating the > above guideline? > > > Second question: From the same link above: > "Compilers used to build packages should honor the applicable compiler > flags set in the system rpm configuration." > > Does this apply to the stage where the compiler is doing the linking, > i.e: "gcc -shared -lthis -lthat..."? Do we need to honor %optflags in > this stage too? Again, I know many packages that don't pass %optflags > to the compiler during the linking. Do these pakcages violate the > guideline? > > Orcan > I didn't get satisfactory responses to my questions, neither here nor in fedora-devel list. All the response we got in this thread was about specific examples concerning the first question, and there was no explanation in full generality. There was no attempt to answer the second question at all. There could be two reasons for this: Either everybody thinks that the answers are ridiculously trivial and they don't bother to answer them, or most people don't have a clue. I hope it is the former one. So please, if you have answers to any of these questions that are not case-specific, would you please share it with me? Thanks, Orcan From tcallawa at redhat.com Tue Apr 28 20:03:27 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 28 Apr 2009 16:03:27 -0400 Subject: [Fedora-packaging] about compiler flags In-Reply-To: References: Message-ID: <49F7610F.1090504@redhat.com> On 04/22/2009 12:56 PM, Orcan Ogetbil wrote: > As you probably know that some packages add their own compiler flags > on top of what we specified as %optflags. Until now, I did not do > anything about these flags unless they override our %optflags. Now, > having a second thought, I realized that the above statement can be > interpreted in two ways: > > 1- The extra flags are added by the packager: This is the way I used > to interpret the guideline, and I always document if I add additional > flags on top of %{optflags} If the packager is adding optflags above and beyond what is in %{optflags} as a manual action (not something inherited by upstream), they need to have a darned good reason to do so, and that reason should be documented in a comment next to this action in the spec file. > 2- The extra flags are added by the build script of upstream: Here is > the question: Do we need to document such cases in the specfile? I > know that we have hundreds (maybe thousands) of packages which don't > document this case in the specfile. Are such packages violating the > above guideline? In a perfect world, yes, this should be documented in the spec file, but practically, you're right, the upstreams often set specific compiler flags for valid reasons, but don't bother explaining them at all. In general, when the upstream compiler flags do not conflict with our %{optflags} and do generally sane things, I think it is okay to permit them. I know that is vague, but its the best answer I can give. In general, I trust that upstreams are not being idiots. If it is obvious that this is not true, the packager may want to reconsider their choice of additional compiler flags. > Second question: From the same link above: > "Compilers used to build packages should honor the applicable compiler > flags set in the system rpm configuration." > > Does this apply to the stage where the compiler is doing the linking, > i.e: "gcc -shared -lthis -lthat..."? Do we need to honor %optflags in > this stage too? Again, I know many packages that don't pass %optflags > to the compiler during the linking. Do these pakcages violate the > guideline? Generally, the answer here is no, as most of the time, these flags are just converted to ld flags, and the only one that really ever matters seems to be the -m32/-m64 split to ensure that resultant binary is linked at the proper bitsize. I've only ever seen this break on sparc64, and it is no longer an issue, since the ld defaults are now sane on that arch. ~spot From alan.evans at secure-24.com Tue Apr 28 21:27:25 2009 From: alan.evans at secure-24.com (Alan Evans) Date: Tue, 28 Apr 2009 17:27:25 -0400 Subject: [Fedora-packaging] Allowing only one package to provide a virtual capability Message-ID: <3A08B75200A4DF44B83752A09A93AFFB020E0CFB@ex1s24dca.S24.local> I am sorry if this is the wrong place but it seems that the rpm-list does not exist any more and this list looks to be the best fit otherwise. I am trying to create a few packages that all provide a virtual capability but would like to allow only one of these packages to be installed at a time. Has to be compatible with RPM 4.2 and greater. (RHEL4 and RHEL5) Name: package-a Provides: package-a config(package) Name: package-b Provides: package-b config(package) Name: package-c Provides: package-c config(package) I could obviously add Conflicts: package-b package-c to package package-a and so on, but every time I add a new package-X I have to manually go through my spec files and update the Conflicts tags. Again I suppose I could script the update but it seems less elegant. I tried: Name: package-a Provides: package-a config(package) Conflicts: config(package) But the result is: config(package) conflicts with package-a-1.1-1.svn20090428.noarch I thought I saw something like this in another list, will post link if I can find it. Where the goal was to only allow one package that provides a particular virtual capability. Anyone know how to accomplish this or if this is the wrong list can you direct me to a better resource? Regards, -Alan From j.w.r.degoede at hhs.nl Tue Apr 28 21:38:15 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 28 Apr 2009 23:38:15 +0200 Subject: [Fedora-packaging] Re: Agenda for the 2009-04-28 Packaging Committee meeting In-Reply-To: References: <49F71340.7010605@freenet.de> <49F74577.4020303@hhs.nl> Message-ID: <49F77747.9040202@hhs.nl> On 04/28/2009 08:10 PM, Jason L Tibbitts III wrote: >>>>>> "HdG" == Hans de Goede writes: > > HdG> On 04/28/2009 04:31 PM, Ralf Corsepius wrote: > HdG> I'm afraid I missed it too, sorry (note as far as I'm concerned > HdG> we really need a new meeting time) > > But yet I don't see from you a response to the request to list out > your available times. We can't choose a time unless you tell us all > of the times that you are available. > ?? Hmm, you're right, I can see the mail right there in my send folder, but not in the mailinglist archives. Let me resend it. Regards, Hans From j.w.r.degoede at hhs.nl Tue Apr 28 21:38:25 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 28 Apr 2009 23:38:25 +0200 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: <49EC9B43.1050004@gmail.com> References: <49E61628.7070104@redhat.com> <49EC9B43.1050004@gmail.com> Message-ID: <49F77751.2090106@hhs.nl> On 04/20/2009 05:56 PM, Toshio Kuratomi wrote: > Tom "spot" Callaway wrote: >> On 04/15/2009 12:00 PM, Jason L Tibbitts III wrote: >>> Well, obviously that didn't work. It looks to me as if the set of >>> time requirements simply can't be satisfied, but to be sure we need to >>> have everyone post the times they're available so that we can try to >>> find an acceptable time without regard to what's going on in the >>> meeting channel. >>> >>> Please keep all times in UTC and only list out times when you will be >>> available both with and without DST/Summer time (so we don't lose >>> people during the transition time). >> Here is my availability: >> >> Mondays: Between 12:00 UTC (8:00 AM EDT) and 15:00 UTC (11:00 AM EDT) >> Between 16:00 UTC (12:00 PM EDT) and 18:00 UTC (2:00 PM EDT) >> Between 19:00 UTC (3:00 PM EDT) and 03:00 UTC (11:00 PM EDT) >> Tuesdays: Between 12:00 UTC (8:00 AM EDT) and 18:00 UTC (2:00 PM EDT) >> Between 19:00 UTC (3:00 PM EDT) and 03:00 UTC (11:00 PM EDT) >> Wednesdays: Between 12:00 UTC (8:00 AM EDT) and 03:00 UTC (11:00 PM EDT) >> Thursdays: Between 12:00 UTC (8:00 AM EDT) and 03:00 UTC (11:00 PM EDT) >> Fridays: Between 12:00 UTC (8:00 AM EDT) and 14:00 UTC (10:00 AM EDT) >> Between 15:30 UTC (11:30 AM EDT) and 18:00 UTC (2:00 PM EDT) >> Between 19:00 UTC (3:00 PM EDT) and 03:00 UTC (11:00 PM EDT) >> >> My weekends are far less predictable. I would greatly prefer that we >> held the meeting during the week. >> > Monday, Tuesday: Between 16:00UTC (8:00AM PST/9:00 PDT) and 7:00UTC > (10:00PM PST/11:00PM PDT) > Wednesday: Between 17:00UTC (9:00AM PST/10:00 PDT) and 7:00UTC (10:00PM > PST/ 11:00PM PDT) > Thursday: Between 16:00UTC (8:00AM PST/9:00 PDT) and 20:00UTC (11:00 AM > PST/Noon PDT) > Between 21:00UTC (Noon PST/1:00PM PDT) and 7:00UTC (10:00PM > PST/11:00PM PDT) > Friday: 16:00UTC (8:00AM PST/9:00 PDT) to 7:00UTC (10:00PM PST/ 11:00PM PDT) > > -Toshio > I'm available during the following hours (all times UTC): Monday 8:00 - 15:30 Tuesday 8:00 - 15:30 Wednesday 8:00 - 15:30 Thursday 7:00 - 11:30 Friday 7:00 - 16:00 Regards, Hans From alan.evans at secure-24.com Wed Apr 29 04:03:38 2009 From: alan.evans at secure-24.com (Alan Evans) Date: Wed, 29 Apr 2009 00:03:38 -0400 Subject: [Fedora-packaging] Question about triggers Message-ID: <3A08B75200A4DF44B83752A09A93AFFB01C35177@ex1s24dca.S24.local> Can triggers be assigned to arbitrary capabilities or only by actual packages? All the docs I have read give me the impression that triggers are only triggered by packages and not arbitrary capabilities. Regards, -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Wed Apr 29 08:48:58 2009 From: paul at city-fan.org (Paul Howarth) Date: Wed, 29 Apr 2009 09:48:58 +0100 Subject: [Fedora-packaging] Allowing only one package to provide a virtual capability In-Reply-To: <3A08B75200A4DF44B83752A09A93AFFB020E0CFB@ex1s24dca.S24.local> References: <3A08B75200A4DF44B83752A09A93AFFB020E0CFB@ex1s24dca.S24.local> Message-ID: <20090429094858.7a260ebf@metropolis.intra.city-fan.org> On Tue, 28 Apr 2009 17:27:25 -0400 "Alan Evans" wrote: > I am sorry if this is the wrong place but it seems that the rpm-list > does not exist any more and this list looks to be the best fit > otherwise. > > I am trying to create a few packages that all provide a virtual > capability but would like to allow only one of these packages to be > installed at a time. Has to be compatible with RPM 4.2 and greater. > (RHEL4 and RHEL5) > > > Name: package-a > Provides: package-a config(package) > > > > Name: package-b > Provides: package-b config(package) > > > > Name: package-c > Provides: package-c config(package) > > > I could obviously add Conflicts: package-b package-c to package > package-a and so on, but every time I add a new package-X I have to > manually go through my spec files and update the Conflicts tags. > Again I suppose I could script the update but it seems less elegant. > > I tried: > > Name: package-a > Provides: package-a config(package) > Conflicts: config(package) > > > But the result is: > config(package) conflicts with package-a-1.1-1.svn20090428.noarch > > I thought I saw something like this in another list, will post link > if I can find it. Where the goal was to only allow one package that > provides a particular virtual capability. > > Anyone know how to accomplish this or if this is the wrong list can > you direct me to a better resource? Not the answer you're looking for but perhaps you could use "alternatives" to support parallel installation of all of your packages but only enabling one to be "active" at any one time? This is for instance how the various MTAs (sendmail, postfix, exim etc.) work. Paul. From enrico.scholz at informatik.tu-chemnitz.de Wed Apr 29 09:37:29 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 29 Apr 2009 11:37:29 +0200 Subject: [Fedora-packaging] Re: Allowing only one package to provide a virtual capability In-Reply-To: <3A08B75200A4DF44B83752A09A93AFFB020E0CFB@ex1s24dca.S24.local> (Alan Evans's message of "Tue\, 28 Apr 2009 17\:27\:25 -0400") References: <3A08B75200A4DF44B83752A09A93AFFB020E0CFB@ex1s24dca.S24.local> Message-ID: <8763gnls12.fsf@sheridan.bigo.ensc.de> "Alan Evans" writes: > I am trying to create a few packages that all provide a virtual > capability but would like to allow only one of these packages to be > installed at a time. > ... > Anyone know how to accomplish this or if this is the wrong list can you > direct me to a better resource? %package a Provides: foo(%name) = a Conflicts: foo(%name) < a Conflicts: foo(%name) > a Enrico From denis at poolshark.org Wed Apr 29 11:09:36 2009 From: denis at poolshark.org (Denis Leroy) Date: Wed, 29 Apr 2009 13:09:36 +0200 Subject: [Fedora-packaging] FPC meeting time proposal In-Reply-To: <49F77751.2090106@hhs.nl> References: <49E61628.7070104@redhat.com> <49EC9B43.1050004@gmail.com> <49F77751.2090106@hhs.nl> Message-ID: <49F83570.8040402@poolshark.org> My availability (time in UTC) every week day: early -> 15:00 and 16:00->18:00 From rdieter at math.unl.edu Wed Apr 29 11:43:30 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 29 Apr 2009 06:43:30 -0500 Subject: [Fedora-packaging] Question about triggers In-Reply-To: <3A08B75200A4DF44B83752A09A93AFFB01C35177@ex1s24dca.S24.local> References: <3A08B75200A4DF44B83752A09A93AFFB01C35177@ex1s24dca.S24.local> Message-ID: <49F83D62.1000705@math.unl.edu> On 04/28/2009 11:03 PM, Alan Evans wrote: > Can triggers be assigned to arbitrary capabilities or only by actual > packages? > > All the docs I have read give me the impression that triggers are only > triggered by packages and not arbitrary capabilities. As I understand it, only package names. -- Rex From dan at danny.cz Thu Apr 30 19:34:37 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 30 Apr 2009 21:34:37 +0200 Subject: [Fedora-packaging] ruby gem and library in C and debuginfo Message-ID: <1241120077.21702.66.camel@eagle.danny.cz> Hi, I am doing a review for a ruby gem package that includes a library written in C (https://bugzilla.redhat.com/show_bug.cgi?id=497640) and there are problems with proper generation of the debuginfo package. It cannot find the source files, because the paths in the debugsources.list contains the "ext/" part twice and that's wrong. + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /home/dan/rpmbuild/BUILD/rubygem-RedCloth-4.1.9 extracting debug info from /home/dan/rpmbuild/BUILDROOT/rubygem-RedCloth-4.1.9-3.fc10.x86_64/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/redcloth_scan.so cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_attributes.c: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_attributes.c.rl: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_inline.c: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_inline.c.rl: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_scan.c: Cannot stat: No such file or directory cpio: rubygem-RedCloth-4.1.9/usr/lib/ruby/gems/1.8/gems/RedCloth-4.1.9/ext/redcloth_scan/ext/redcloth_scan/redcloth_scan.c.rl: Cannot stat: No such file or directory Dan