From rjones at redhat.com Fri Dec 5 23:12:25 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 5 Dec 2008 23:12:25 +0000 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages Message-ID: <20081205231225.GA28600@thinkpad> So as I mentioned before we have an OCaml Windows cross-compiler as part of the Fedora MinGW project: http://hg.et.redhat.com/misc/fedora-mingw--devel/ (click 'manifest' then 'ocaml' or the 'ocaml-*' subdirectories) mingw32-ocaml - the cross-compiler (native Fedora prog) mingw32-ocaml-calendar - cross-compiled OCaml Calendar library mingw32-ocaml-csv - cross-compiled OCaml CSV library mingw32-ocaml-curses - cross-compiled OCaml curses bindings mingw32-ocaml-extlib - cross-compiled OCaml extlib (library) mingw32-ocaml-findlib - (this just has a single config file) mingw32-ocaml-lablgl - cross-compiled OCaml OpenGL bindings mingw32-ocaml-lablgtk - cross-compiled OCaml Gtk bindings mingw32-ocaml-libvirt - cross-compiled OCaml libvirt bindings mingw32-ocaml-xml-light - cross-compiled OCaml XML library When we were doing the original packaging, we explored the option of building the MinGW packages as subpackages of the native Fedora packages, eg: the gnutls specfile would contain the '-n mingw32-gnutls' subpackage. This would have made it simpler to keep the packages in synch with native Fedora, but we felt that native packagers wouldn't be so happy about this. They wouldn't be expert in MinGW packaging, and would drop the MinGW subpackage at the first sign of trouble. However, since I'm in the unique position of maintaining most of the corresponding ocaml-* (native) and mingw32-ocaml-* (cross-compiled) packages, I would like to ask whether I can create the packages above and others in future as subpackages of the already approved ocaml-* native packages. I'm not looking for any exception to the relevant packaging guidelines, which I would try to follow (excepting any mistakes). If you want to see what some RPMs look like, see: http://www.annexia.org/tmp/mingw/fedora-10/x86_64/RPMS/ Thoughts? I set follow-ups to the fedora-packaging list. Rich. From fab at fedoraproject.org Sat Dec 6 19:06:58 2008 From: fab at fedoraproject.org (Fabian Affolter) Date: Sat, 06 Dec 2008 20:06:58 +0100 Subject: [Fedora-packaging] Problems with the .info file Message-ID: <493ACD52.4060309@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, As I mentioned in the subject of this message, I have a problem with the .info file in a package. I'm able to build the package locally but mock fails. I guess that I missed something... Spec file (only the relevant parts): ... Requires(post): /sbin/install-info Requires(preun): /sbin/install-info ... %post /sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || : ... %preun if [ "$1" = 0 ]; then /sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || : fi ... %files -f %{name}.lang %defattr(-,root,root,-) %doc AUTHORS ChangeLog COPYING NEWS README TODO %{_infodir}/%{name}.info.gz ... mock complains about installed but not packaged file '/usr/share/info/dir' . Did I miss a directory? Can please anybody give me a hint? Thanks in advance. Kind regards, Fabian SRPM: http://fab.fedorapeople.org/packages/SRPMS/wol-0.7.1-1.fc9.src.rpm SPEC: http://fab.fedorapeople.org/packages/SRPMS/wol.spec - -- Fingerprint: 2F6C 930F D3C4 7E38 6AFA 4EB4 E23C D2DD 36A4 397F Fedora always leads and never follows. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkk6yAMACgkQ4jzS3TakOX9pmQCfTOFxTL4XFBuGq4+par9+lJ41 NYQAn1/D9Ct29WNWLxFOz39hZhO19plX =J7BS -----END PGP SIGNATURE----- From tibbs at math.uh.edu Sat Dec 6 20:19:50 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Dec 2008 14:19:50 -0600 Subject: [Fedora-packaging] Problems with the .info file In-Reply-To: <493ACD52.4060309@fedoraproject.org> References: <493ACD52.4060309@fedoraproject.org> Message-ID: >>>>> "FA" == Fabian Affolter writes: FA> mock complains about installed but not packaged file FA> '/usr/share/info/dir' . Did I miss a directory? You need to remove that file manually in your spec. The tools may or may not create it depending on what it installed when you build. Look at pretty much any other package that includes info documentation. My grep happened to turn up flex first. - J< From fabian.deutsch at gmx.de Sun Dec 7 19:25:22 2008 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Sun, 07 Dec 2008 20:25:22 +0100 Subject: [Fedora-packaging] Error when building: gimptool-2.0: Permission denied Message-ID: <1228677922.4901.4.camel@decade.local> Hey, I'm new to packaging packages and tried to build a new package for some gimp plugin. I can build the package local, but building it via koji fails with the following error: https://koji.fedoraproject.org/koji/getfile?taskID=985724&name=build.log Can some give me a hint what it migth be? Greetings fabian From fabian.deutsch at gmx.de Sun Dec 7 19:33:28 2008 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Sun, 07 Dec 2008 20:33:28 +0100 Subject: [Fedora-packaging] Error when building: gimptool-2.0: Permission denied In-Reply-To: <1228677922.4901.4.camel@decade.local> References: <1228677922.4901.4.camel@decade.local> Message-ID: <1228678408.4901.7.camel@decade.local> Hey, > I'm new to packaging packages and tried to build a new package for some > gimp plugin. > I can build the package local, but building it via koji fails with the > following error: > https://koji.fedoraproject.org/koji/getfile?taskID=985724&name=build.log > > > Can some give me a hint what it migth be? Okay, my fault. I got the wrong dependecy, doesn't depend just on gimp-devel, but on gimp too. Cheers fabian > > Greetings > fabian > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From jkeating at redhat.com Sun Dec 7 21:18:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 07 Dec 2008 13:18:44 -0800 Subject: [Fedora-packaging] Task work needed Message-ID: <1228684724.3370.18.camel@localhost.localdomain> Some small busy work needed, somebody to ensure each Review Guideline item in http://fedoraproject.org/wiki/Packaging/ReviewGuidelines has a matching guideline entry in https://fedoraproject.org/wiki/Packaging/Guidelines (or subpages). Bonus points for creating links in the ReviewGuidelines to the matching rule in the Guidelines. Case in point; Can anybody tell me where the guideline exists for: - SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. ? (this is suddenly a lot more relevant as rpm picks up pkg-config deps automatically and is dragging in quite a lot of -devel packages on otherwise non-devel installs due to .pc file placement) -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mefoster at gmail.com Mon Dec 8 15:52:44 2008 From: mefoster at gmail.com (Mary Ellen Foster) Date: Mon, 8 Dec 2008 16:52:44 +0100 Subject: [Fedora-packaging] Updates to Eclipse Plugin packaging guidelines In-Reply-To: <20081017145355.GA17890@redhat.com> References: <20081017145355.GA17890@redhat.com> Message-ID: On Fri, Oct 17, 2008 at 3:53 PM, Andrew Overholt wrote: > I have a few updates to the Eclipse Plugin packaging guidelines. They > include some clarifications, typos, and updates for Eclipse 3.4.x. The > only bit of real substance is modifying the template to note how we're > using the dropins mechanism for plugin installation in 3.4.x and above. (Resurrecting this thread ...) So if I'm trying to package an Eclipse plugin now (http://vimplugin.org), I should follow this advice and put the jar file in the "dropins" directory, *regardless* of the version of Fedora? That is, is 3.4.x the "live" version on all versions? NB: These changes don't seem to have been applied yet -- I was looking at the Wiki page earlier today and it clearly still had the old version. MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From overholt at redhat.com Mon Dec 8 15:59:04 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 8 Dec 2008 10:59:04 -0500 Subject: [Fedora-packaging] Updates to Eclipse Plugin packaging guidelines In-Reply-To: References: <20081017145355.GA17890@redhat.com> Message-ID: <20081208155904.GA5139@redhat.com> * Mary Ellen Foster [2008-12-08 10:53]: > On Fri, Oct 17, 2008 at 3:53 PM, Andrew Overholt wrote: > > I have a few updates to the Eclipse Plugin packaging guidelines. They > > include some clarifications, typos, and updates for Eclipse 3.4.x. The > > only bit of real substance is modifying the template to note how we're > > using the dropins mechanism for plugin installation in 3.4.x and above. > > (Resurrecting this thread ...) So if I'm trying to package an Eclipse > plugin now (http://vimplugin.org), I should follow this advice and put > the jar file in the "dropins" directory, *regardless* of the version > of Fedora? That is, is 3.4.x the "live" version on all versions? No, just for Fedora 10. I guess you'll have to have %if sections for older releases if you want to release on them. > NB: These changes don't seem to have been applied yet -- I was looking > at the Wiki page earlier today and it clearly still had the old > version. Yeah, I don't know what the procedure is to get changes actually applied. Andrew From tibbs at math.uh.edu Mon Dec 8 16:35:36 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 08 Dec 2008 10:35:36 -0600 Subject: [Fedora-packaging] Updates to Eclipse Plugin packaging guidelines In-Reply-To: <20081208155904.GA5139@redhat.com> References: <20081017145355.GA17890@redhat.com> <20081208155904.GA5139@redhat.com> Message-ID: >>>>> "AO" == Andrew Overholt writes: AO> Yeah, I don't know what the procedure is to get changes actually AO> applied. Make sure your draft is on the schedule: http://fedoraproject.org/wiki/PackagingDrafts/DraftsTodo and the committee will discuss it at the next meeting (which happens to be tomorrow). If the changes are trivial or obviously necessary to keep up with changes in the underlying software, we'll just make the fixes; otherwise they'll take a round drip through FESCo for ratification. - J< From rjones at redhat.com Mon Dec 8 17:53:19 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 8 Dec 2008 17:53:19 +0000 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: <20081205231225.GA28600@thinkpad> References: <20081205231225.GA28600@thinkpad> Message-ID: <20081208175319.GA29471@thinkpad> On Fri, Dec 05, 2008 at 11:12:25PM +0000, Richard W.M. Jones wrote: > So as I mentioned before we have an OCaml Windows cross-compiler as > part of the Fedora MinGW project: Everyone's happy with me to go ahead with this? Rich. From a.badger at gmail.com Mon Dec 8 20:58:24 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 08 Dec 2008 12:58:24 -0800 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: <20081208175319.GA29471@thinkpad> References: <20081205231225.GA28600@thinkpad> <20081208175319.GA29471@thinkpad> Message-ID: <493D8A70.2050900@gmail.com> Richard W.M. Jones wrote: > On Fri, Dec 05, 2008 at 11:12:25PM +0000, Richard W.M. Jones wrote: >> So as I mentioned before we have an OCaml Windows cross-compiler as >> part of the Fedora MinGW project: > > Everyone's happy with me to go ahead with this? > I'm not but I've been involved with other arguments so I haven't been able to think about whether this is just an unjustifiable gut feeling or if there's an actual reason this should be avoided. -------------- 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 Tue Dec 9 06:45:45 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 09 Dec 2008 07:45:45 +0100 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: <20081208175319.GA29471@thinkpad> References: <20081205231225.GA28600@thinkpad> <20081208175319.GA29471@thinkpad> Message-ID: <1228805145.30957.10962.camel@beck.corsepiu.local> On Mon, 2008-12-08 at 17:53 +0000, Richard W.M. Jones wrote: > On Fri, Dec 05, 2008 at 11:12:25PM +0000, Richard W.M. Jones wrote: > > So as I mentioned before we have an OCaml Windows cross-compiler as > > part of the Fedora MinGW project: > > Everyone's happy with me to go ahead with this? I am not, but I am sure if I understand you correctly. Is your plan to build mingw packages as part of building Fedora packages within the Fedora build system? If yes, I am opposed to doing this. Is your plan to add support to your ocaml package to enable you to reuse your ocaml Fedora rpm.specs to build mingw package outside of Fedora? I'd consider this to be "your private pleasures" and to be "outside of Fedora's business". Ralf From rc040203 at freenet.de Tue Dec 9 07:24:21 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 09 Dec 2008 08:24:21 +0100 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: <1228805145.30957.10962.camel@beck.corsepiu.local> References: <20081205231225.GA28600@thinkpad> <20081208175319.GA29471@thinkpad> <1228805145.30957.10962.camel@beck.corsepiu.local> Message-ID: <1228807461.30957.11120.camel@beck.corsepiu.local> On Tue, 2008-12-09 at 07:45 +0100, Ralf Corsepius wrote: > On Mon, 2008-12-08 at 17:53 +0000, Richard W.M. Jones wrote: > > On Fri, Dec 05, 2008 at 11:12:25PM +0000, Richard W.M. Jones wrote: > > > So as I mentioned before we have an OCaml Windows cross-compiler as > > > part of the Fedora MinGW project: > > > > Everyone's happy with me to go ahead with this? > I am not, but I am sure if I understand you correctly. .... not sure ..., sorry > Is your plan to build mingw packages as part of building Fedora packages > within the Fedora build system? If yes, I am opposed to doing this. > > Is your plan to add support to your ocaml package to enable you to reuse > your ocaml Fedora rpm.specs to build mingw package outside of Fedora? > I'd consider this to be "your private pleasures" and to be "outside of > Fedora's business". From rjones at redhat.com Tue Dec 9 10:52:02 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 9 Dec 2008 10:52:02 +0000 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: <1228805145.30957.10962.camel@beck.corsepiu.local> References: <20081205231225.GA28600@thinkpad> <20081208175319.GA29471@thinkpad> <1228805145.30957.10962.camel@beck.corsepiu.local> Message-ID: <20081209105202.GA31157@thinkpad> On Tue, Dec 09, 2008 at 07:45:45AM +0100, Ralf Corsepius wrote: > On Mon, 2008-12-08 at 17:53 +0000, Richard W.M. Jones wrote: > > On Fri, Dec 05, 2008 at 11:12:25PM +0000, Richard W.M. Jones wrote: > > > So as I mentioned before we have an OCaml Windows cross-compiler as > > > part of the Fedora MinGW project: > > > > Everyone's happy with me to go ahead with this? > I am not, but I am sure if I understand you correctly. > > Is your plan to build mingw packages as part of building Fedora packages > within the Fedora build system? If yes, I am opposed to doing this. I'm a bit confused by this. You are aware that we are planning to build lots of mingw packages in Fedora (using the build system) to enable cross-compilation? This has been discussed to death already, and approved, so it shouldn't be news to anyone. http://fedoraproject.org/wiki/MinGW http://fedoraproject.org/wiki/Features/Windows_cross_compiler http://fedoraproject.org/wiki/Packaging/MinGW https://bugzilla.redhat.com/buglist.cgi?version=&component=&target_milestone=&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=MODIFIED&short_desc_type=allwordssubstr&short_desc=mingw&long_desc_type=allwordssubstr&long_desc= > Is your plan to add support to your ocaml package to enable you to reuse > your ocaml Fedora rpm.specs to build mingw package outside of Fedora? > I'd consider this to be "your private pleasures" and to be "outside of > Fedora's business". No, I would like to build the cross-compiler from the ocaml.spec, instead of doing a separate review request for a new mingw32-ocaml package. (Plus the libraries too as mentioned in the original email). Rich. From rc040203 at freenet.de Tue Dec 9 15:05:25 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 09 Dec 2008 16:05:25 +0100 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: <20081209105202.GA31157@thinkpad> References: <20081205231225.GA28600@thinkpad> <20081208175319.GA29471@thinkpad> <1228805145.30957.10962.camel@beck.corsepiu.local> <20081209105202.GA31157@thinkpad> Message-ID: <1228835125.30957.13340.camel@beck.corsepiu.local> On Tue, 2008-12-09 at 10:52 +0000, Richard W.M. Jones wrote: > On Tue, Dec 09, 2008 at 07:45:45AM +0100, Ralf Corsepius wrote: > > On Mon, 2008-12-08 at 17:53 +0000, Richard W.M. Jones wrote: > > > On Fri, Dec 05, 2008 at 11:12:25PM +0000, Richard W.M. Jones wrote: > > > > So as I mentioned before we have an OCaml Windows cross-compiler as > > > > part of the Fedora MinGW project: > > > > > > Everyone's happy with me to go ahead with this? > > I am not, but I am sure if I understand you correctly. > > > > Is your plan to build mingw packages as part of building Fedora packages > > within the Fedora build system? If yes, I am opposed to doing this. > > I'm a bit confused by this. You are aware that we are planning to > build lots of mingw packages in Fedora (using the build system) to > enable cross-compilation? No, but if so, I have to reiterate to be vehemently disagreeing with this and will never agree with it. Shipping cross-toolchains as part of Fedora to enable users to build MinGW binaries is OK with me, but abusing Fedora to support Windows is not OK with me. Ralf From tibbs at math.uh.edu Tue Dec 9 15:41:41 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Dec 2008 09:41:41 -0600 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: <20081208175319.GA29471@thinkpad> References: <20081205231225.GA28600@thinkpad> <20081208175319.GA29471@thinkpad> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> Everyone's happy with me to go ahead with this? You have to torture reality pretty badly to assume that silence somehow implies happiness. Maybe people are just annoyed to see this come up again. So here's one from someone who was never all that comfortable with all of this Windows support in the first place: During the discussions you were somewhat adamant about the limited number of Windows library packages that your proposal would entail. You quoted numbers and relatively small size requirements as evidence that this was no big deal. Now you're talking about taking what is something of a niche package category (ocaml packages) and adding a second level of niche-itude to them (windows cross-compilation environment for ocaml packages) and I'm wondering if the overhead of these packages was included in your initial figures and whether you actually think that anyone other than you will actually use them. I mean, sure, if you're a packager and you can get someone to review your packages, you can basically turn Fedora into your own personal distro, with the specialized packages that you want already in there. I don't think that's a bad thing. Even better if other people happen to benefit from those packages. At some point, however, someone needs to actually think about how the cost of this compares to the benefits. I do have a couple of other hands in the fray, though: As a package reviewer, I think you've already dropped a metric ass-ton of packages on the review queue and I shudder to think that you would consider actually adding more without spending at least a solid month helping us review packages. Avoiding having to review another pile of whatever-for-windows packages would be great. As a Packaging Committee member, I would want you to at least add sufficient comments to these specfiles to discourage anyone who might want to package an ocaml module from using them as examples unless they somehow want to maintain them for Windows as well. After taht long review process we have what I think are a good set of ocaml package guidelines with nice templates, and now you're proposing to take the bulk of those packages away from that. - J< From rjones at redhat.com Tue Dec 9 17:59:41 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 9 Dec 2008 17:59:41 +0000 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: References: <20081205231225.GA28600@thinkpad> <20081208175319.GA29471@thinkpad> Message-ID: <20081209175941.GA31890@thinkpad> On Tue, Dec 09, 2008 at 09:41:41AM -0600, Jason L Tibbitts III wrote: > >>>>> "RWMJ" == Richard W M Jones writes: > > RWMJ> Everyone's happy with me to go ahead with this? > > You have to torture reality pretty badly to assume that silence > somehow implies happiness. Maybe people are just annoyed to see this > come up again. I was a bit surprised there was no response from the first email, and the second email was an opportunity to bring this to peoples' attention again. I haven't made any changes yet to the packages, precisely because I wanted to hear what people had to say and ensure there was general agreement first. > So here's one from someone who was never all that comfortable with all > of this Windows support in the first place: > > During the discussions you were somewhat adamant about the limited number > of Windows library packages that your proposal would entail. You > quoted numbers and relatively small size requirements as evidence that > this was no big deal. This is still the case. Even with all the packages we've done, plus the OCaml subpackages, the whole of mingw is under a gigabyte (src + noarch RPMs). At the time we estimated 800 MB, so we have gone slightly over our estimate, but at the same time we've expanded the scope to include C++ libraries like gtkmm. Still, I wouldn't really say that 1 GB is excessive. We have found a non-virt co-maintainer (Levente Farkas) for all the base packages too. > Now you're talking about taking what is > something of a niche package category (ocaml packages) and adding a > second level of niche-itude to them (windows cross-compilation > environment for ocaml packages) and I'm wondering if the overhead of > these packages was included in your initial figures and whether you > actually think that anyone other than you will actually use them. Yes, people in the OCaml community are excited by this. That may not be a community that is very visible to Fedora packagers I admit. > I mean, sure, if you're a packager and you can get someone to review > your packages, you can basically turn Fedora into your own personal > distro, with the specialized packages that you want already in there. > I don't think that's a bad thing. Even better if other people happen > to benefit from those packages. At some point, however, someone needs > to actually think about how the cost of this compares to the benefits. > > I do have a couple of other hands in the fray, though: > > As a package reviewer, I think you've already dropped a metric ass-ton > of packages on the review queue and I shudder to think that you would > consider actually adding more without spending at least a solid month > helping us review packages. Avoiding having to review another pile of > whatever-for-windows packages would be great. It's true that I have been negligent in doing very little review work. So I will try to change that. > As a Packaging Committee member, I would want you to at least add > sufficient comments to these specfiles to discourage anyone who might > want to package an ocaml module from using them as examples unless > they somehow want to maintain them for Windows as well. After taht > long review process we have what I think are a good set of ocaml > package guidelines with nice templates, and now you're proposing to > take the bulk of those packages away from that. OK, this is fair too. I usually encourage OCaml packagers to start out with: http://fedoraproject.org/wiki/Image:Packaging_OCaml_ocaml-foolib.spec linked from: http://fedoraproject.org/wiki/Packaging/OCaml That doesn't currently include a mingw subpackage, and nor should it. Note that there are currently 70 OCaml packages in Fedora, and only a handful of those (10) were proposed to be cross-compiled, 2 of those being the cross-compiler itself. Rich. From a.badger at gmail.com Tue Dec 9 18:46:08 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 09 Dec 2008 10:46:08 -0800 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: <20081209175941.GA31890@thinkpad> References: <20081205231225.GA28600@thinkpad> <20081208175319.GA29471@thinkpad> <20081209175941.GA31890@thinkpad> Message-ID: <493EBCF0.4050605@gmail.com> Richard W.M. Jones wrote: > OK, this is fair too. I usually encourage OCaml packagers to start > out with: > > http://fedoraproject.org/wiki/Image:Packaging_OCaml_ocaml-foolib.spec > > linked from: > > http://fedoraproject.org/wiki/Packaging/OCaml > > That doesn't currently include a mingw subpackage, and nor should it. > > Note that there are currently 70 OCaml packages in Fedora, and only a > handful of those (10) were proposed to be cross-compiled, 2 of those > being the cross-compiler itself. > So.. I'd like to stick with the current Guidelines that require separate reviews and packages for cross-compiled packages. Here's some of the logic: 1) Just because you are the maintainer of the package now doesn't mean that you'll be the maintainer in Fedora 27. 2) Rather than special-case OCaml, (or really... the OCaml subset maintained by you) it would be better to write a general rule. However, that general rule leads to a bit of confusion -- subpackages may be used when the maintainer is amenable to it. Separate packages when the maintainer is not. And when maintainership switches, go with whatever was done before? Or merge and drop as the current maintainer wishes? This is all very ugly. 3) Since we currently review packages on import time (instead of having an ongoing re-review process) and cross-compilation is a very large spec to add to the build, it's better to make sure cross-compilation is reviewed via separate packages than to have it added on to random packages willy-nilly. 4) Having cross-compiled sub-packages prevents us from separating out the cross-compiled packages should that become desirable in the future (I sit on Infrastructure and FPC and watch FESCo so I know how difficult this is from the infrastructure side and yet how desired it was from the other.) Once again, this is keeping options open for Fedora 27. -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 rjones at redhat.com Tue Dec 9 21:00:20 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 9 Dec 2008 21:00:20 +0000 Subject: [Fedora-packaging] MinGW subpackages of OCaml packages In-Reply-To: <493EBCF0.4050605@gmail.com> References: <20081205231225.GA28600@thinkpad> <20081208175319.GA29471@thinkpad> <20081209175941.GA31890@thinkpad> <493EBCF0.4050605@gmail.com> Message-ID: <20081209210020.GA32436@thinkpad> On Tue, Dec 09, 2008 at 10:46:08AM -0800, Toshio Kuratomi wrote: > Richard W.M. Jones wrote: > > > OK, this is fair too. I usually encourage OCaml packagers to start > > out with: > > > > http://fedoraproject.org/wiki/Image:Packaging_OCaml_ocaml-foolib.spec > > > > linked from: > > > > http://fedoraproject.org/wiki/Packaging/OCaml > > > > That doesn't currently include a mingw subpackage, and nor should it. > > > > Note that there are currently 70 OCaml packages in Fedora, and only a > > handful of those (10) were proposed to be cross-compiled, 2 of those > > being the cross-compiler itself. > > > So.. I'd like to stick with the current Guidelines that require separate > reviews and packages for cross-compiled packages. Here's some of the logic: > > 1) Just because you are the maintainer of the package now doesn't mean > that you'll be the maintainer in Fedora 27. > > 2) Rather than special-case OCaml, (or really... the OCaml subset > maintained by you) it would be better to write a general rule. However, > that general rule leads to a bit of confusion -- subpackages may be used > when the maintainer is amenable to it. Separate packages when the > maintainer is not. And when maintainership switches, go with whatever > was done before? Or merge and drop as the current maintainer wishes? > This is all very ugly. > > 3) Since we currently review packages on import time (instead of having > an ongoing re-review process) and cross-compilation is a very large spec > to add to the build, it's better to make sure cross-compilation is > reviewed via separate packages than to have it added on to random > packages willy-nilly. > > 4) Having cross-compiled sub-packages prevents us from separating out > the cross-compiled packages should that become desirable in the future > (I sit on Infrastructure and FPC and watch FESCo so I know how difficult > this is from the infrastructure side and yet how desired it was from the > other.) Once again, this is keeping options open for Fedora 27. This seems very reasonable. So I'll introduce these as new packages instead of doing them as subpackages. (And try to do some more reviews ...) Rich. From opensource at till.name Tue Dec 9 23:58:06 2008 From: opensource at till.name (Till Maas) Date: Wed, 10 Dec 2008 00:58:06 +0100 Subject: [Fedora-packaging] adding INSTALL="install -p" to %configure Message-ID: <200812100058.18280.opensource@till.name> Hi, the current Guidelines recommend to preserve timestamps when adding commands that copy files to a spec file: https://fedoraproject.org/wiki/Packaging/Guidelines#Timestamps Currently this is often in reviews also checked for commands that are e.g. in upstreams Makefile. If you think that this should be done, can you please adjust the Guidelines to reflect this and add "INSTALL='install -p'" to %configure, to make this automatically happen for packages using autotools? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From mclasen at redhat.com Wed Dec 10 02:50:56 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 09 Dec 2008 21:50:56 -0500 Subject: [Fedora-packaging] guidelines for dbus services Message-ID: <1228877456.7475.11.camel@matthiasc> In the light of the recent dbus debacle, I think it would be very good to add a section about dbus services to the packaging guidelines. As we have painfully learned, an incorrect policy file for a third-party service can render the entire system bus unusable, or open it up to everybody, so it is important that packagers pay attention to the dbus policy files in their packages. I don't have a concrete proposal right now, but Colin made a good start at writing up some best practices here: http://lists.freedesktop.org/archives/dbus/2008-December/010717.html Matthias From mefoster at gmail.com Wed Dec 10 09:26:06 2008 From: mefoster at gmail.com (Mary Ellen Foster) Date: Wed, 10 Dec 2008 10:26:06 +0100 Subject: [Fedora-packaging] Group tag for Java libraries and their documentation Message-ID: Going by the options proposed by rpmlint, the only possible tag for any development library -- whatever language it's written in -- is "Development/Libraries". At the same time, there are lots of packages using "Development/Libraries/Java"; on my computer, rpm -q -g Development/Libraries/Java | wc -l yields 46 of them. I also have the same question about "Documentation" vs. "Development/Documentation" for javadoc packages -- rpmlint only accepts the former, but a nontrivial number of packages use the latter. So what's the official verdict on this? Thanks, MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From pertusus at free.fr Wed Dec 10 09:31:23 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 10 Dec 2008 10:31:23 +0100 Subject: [Fedora-packaging] Group tag for Java libraries and their documentation In-Reply-To: References: Message-ID: <20081210093123.GB2550@free.fr> On Wed, Dec 10, 2008 at 10:26:06AM +0100, Mary Ellen Foster wrote: > > So what's the official verdict on this? Not official, but the Groups are not used a lot currently, they are superseded by comps. The 'official' list of groups is in /usr/share/doc/rpm-4.6.0/GROUPS but indeed there aren't too many. rpmbiuld doesn't need a Group: anymore, so maybe in the future they could be completly omitted from spec files. -- Pat From foster at in.tum.de Wed Dec 10 09:35:22 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Wed, 10 Dec 2008 10:35:22 +0100 Subject: [Fedora-packaging] Group tag for Java libraries and their documentation In-Reply-To: <20081210093123.GB2550@free.fr> References: <20081210093123.GB2550@free.fr> Message-ID: On Wed, Dec 10, 2008 at 10:31 AM, Patrice Dumas wrote: > On Wed, Dec 10, 2008 at 10:26:06AM +0100, Mary Ellen Foster wrote: >> >> So what's the official verdict on this? > > Not official, but the Groups are not used a lot currently, they are > superseded by comps. The 'official' list of groups is in > /usr/share/doc/rpm-4.6.0/GROUPS > but indeed there aren't too many. > > rpmbiuld doesn't need a Group: anymore, so maybe in the future they > could be completly omitted from spec files. So any Group-related warnings from rpmlint can be safely ignored? MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From pertusus at free.fr Wed Dec 10 09:40:32 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 10 Dec 2008 10:40:32 +0100 Subject: [Fedora-packaging] Group tag for Java libraries and their documentation In-Reply-To: References: <20081210093123.GB2550@free.fr> Message-ID: <20081210094032.GC2550@free.fr> On Wed, Dec 10, 2008 at 10:35:22AM +0100, Mary Ellen Foster wrote: > > So any Group-related warnings from rpmlint can be safely ignored? This rpmlint warning is touched upon at: http://fedoraproject.org/wiki/PackageMaintainers/Common_Rpmlint_Issues#non-standard-group implying that it should be fixed, but this is also non-official. I'd say use your best judgement. -- Pat From tcallawa at redhat.com Wed Dec 10 15:04:13 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 10 Dec 2008 10:04:13 -0500 Subject: [Fedora-packaging] Group tag for Java libraries and their documentation In-Reply-To: References: <20081210093123.GB2550@free.fr> Message-ID: <1228921453.10108.11.camel@localhost.localdomain> On Wed, 2008-12-10 at 10:35 +0100, Mary Ellen Foster wrote: > On Wed, Dec 10, 2008 at 10:31 AM, Patrice Dumas wrote: > > On Wed, Dec 10, 2008 at 10:26:06AM +0100, Mary Ellen Foster wrote: > >> > >> So what's the official verdict on this? > > > > Not official, but the Groups are not used a lot currently, they are > > superseded by comps. The 'official' list of groups is in > > /usr/share/doc/rpm-4.6.0/GROUPS > > but indeed there aren't too many. > > > > rpmbiuld doesn't need a Group: anymore, so maybe in the future they > > could be completly omitted from spec files. > > So any Group-related warnings from rpmlint can be safely ignored? We decided a while back that as soon as rpm didn't require Group anymore, we would stop including it. In the interim, you can put whatever you want in that field. ~spot From mefoster at gmail.com Fri Dec 12 10:16:40 2008 From: mefoster at gmail.com (Mary Ellen Foster) Date: Fri, 12 Dec 2008 11:16:40 +0100 Subject: [Fedora-packaging] Including a patched version of an upstream library -- advice? Message-ID: So I decided to try upping my own review karma by trying to review some outstanding Java packages. Unfortunately, I seem to have chosen one with an "interesting" issue: https://bugzilla.redhat.com/show_bug.cgi?id=464013 The package in question is "findbugs-bcel": an alternative version of the bcel library (already in Fedora), including a fairly large patch from the developers of the "findbugs" package. There seems to be no hope of getting this patch into upstream bcel (e.g., https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2007-April/001880.html). There was a short discussion on this on fedora-devel-list last year: http://www.redhat.com/archives/rhl-devel-list/2007-September/msg00865.html What's the official policy here? I guess I should try to find a more straightforward package for my first review ... MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From tcallawa at redhat.com Fri Dec 12 14:10:35 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 12 Dec 2008 09:10:35 -0500 Subject: [Fedora-packaging] Including a patched version of an upstream library -- advice? In-Reply-To: References: Message-ID: <1229091035.3560.9.camel@localhost.localdomain> On Fri, 2008-12-12 at 11:16 +0100, Mary Ellen Foster wrote: > So I decided to try upping my own review karma by trying to review > some outstanding Java packages. Unfortunately, I seem to have chosen > one with an "interesting" issue: > https://bugzilla.redhat.com/show_bug.cgi?id=464013 > > The package in question is "findbugs-bcel": an alternative version of > the bcel library (already in Fedora), including a fairly large patch > from the developers of the "findbugs" package. There seems to be no > hope of getting this patch into upstream bcel (e.g., > https://mailman.cs.umd.edu/pipermail/findbugs-discuss/2007-April/001880.html). > There was a short discussion on this on fedora-devel-list last year: > http://www.redhat.com/archives/rhl-devel-list/2007-September/msg00865.html > > What's the official policy here? Hmmm. This is definitely open source fail. So, here is my opinion: If the bcel maintainer is okay with this, and the findbugs-bcel package does not conflict in any way whatsoever... alright. I'm not happy about it, but I don't want to be a pain in a situation that isn't going to be resolved properly anytime soon. ~spot From overholt at redhat.com Fri Dec 12 17:02:29 2008 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 12 Dec 2008 12:02:29 -0500 Subject: [Fedora-packaging] "ratify" Message-ID: <49429925.9080605@redhat.com> Hi, I couldn't find the meeting minutes for the most recent meeting but did find that my proposed changes to the Eclipse plugin packaging guidelines have the "ratify" status meaning they need to be run by FESCo. Does this mean I need to be present during a FESCo meeting? If they're passed by FESCo, will the changes be applied or do I need to do something? Thanks, Andrew From a.badger at gmail.com Fri Dec 12 17:22:52 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 12 Dec 2008 09:22:52 -0800 Subject: [Fedora-packaging] "ratify" In-Reply-To: <49429925.9080605@redhat.com> References: <49429925.9080605@redhat.com> Message-ID: <49429DEC.6040408@gmail.com> Andrew Overholt wrote: > Hi, > > I couldn't find the meeting minutes for the most recent meeting but did > find that my proposed changes to the Eclipse plugin packaging guidelines > have the "ratify" status meaning they need to be run by FESCo. Does > this mean I need to be present during a FESCo meeting? If they're > passed by FESCo, will the changes be applied or do I need to do something? > Most of the time FESCo simply approves what FPC has passed. I don't believe that the Eclipse updates have anything controversial that FESCo will choose to take issue with but I'm not on FESCo. -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 Dec 12 17:37:17 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 12 Dec 2008 09:37:17 -0800 Subject: [Fedora-packaging] guidelines for dbus services In-Reply-To: <1228877456.7475.11.camel@matthiasc> References: <1228877456.7475.11.camel@matthiasc> Message-ID: <4942A14D.10006@gmail.com> Matthias Clasen wrote: > In the light of the recent dbus debacle, I think it would be very good > to add a section about dbus services to the packaging guidelines. > > As we have painfully learned, an incorrect policy file for a third-party > service can render the entire system bus unusable, or open it up to > everybody, so it is important that packagers pay attention to the dbus > policy files in their packages. > > I don't have a concrete proposal right now, but Colin made a good start > at writing up some best practices here: > http://lists.freedesktop.org/archives/dbus/2008-December/010717.html > This would be very useful. The information isn't really a Guideline (with MUST items at the moment) and ideas for how packagers should deal with upstreams that don't follow the suggestions but it is a good start. Maybe the best idea would be to get this in the wiki and expand it under PackagingDrafts/DBus. Then migrate it into a document similar to what each programming language has. Having a list of reviewables will make it better fodder for the Packaging Guidelines themselves. -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 tibbs at math.uh.edu Fri Dec 12 17:47:51 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Dec 2008 11:47:51 -0600 Subject: [Fedora-packaging] "ratify" In-Reply-To: <49429925.9080605@redhat.com> References: <49429925.9080605@redhat.com> Message-ID: >>>>> "AO" == Andrew Overholt writes: AO> Hi, I couldn't find the meeting minutes for the most recent AO> meeting but did find that my proposed changes to the Eclipse AO> plugin packaging guidelines have the "ratify" status meaning they AO> need to be run by FESCo. Honestly, I think that we should just make the changes. FESCo has previously told us to make obvious fixes without waiting for their approval, and these are needed to keep up with changes in the underlying environment. - J< From a.badger at gmail.com Fri Dec 12 18:01:17 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 12 Dec 2008 10:01:17 -0800 Subject: [Fedora-packaging] "ratify" In-Reply-To: References: <49429925.9080605@redhat.com> Message-ID: <4942A6ED.9040105@gmail.com> Jason L Tibbitts III wrote: >>>>>> "AO" == Andrew Overholt writes: > > AO> Hi, I couldn't find the meeting minutes for the most recent > AO> meeting but did find that my proposed changes to the Eclipse > AO> plugin packaging guidelines have the "ratify" status meaning they > AO> need to be run by FESCo. > > Honestly, I think that we should just make the changes. FESCo has > previously told us to make obvious fixes without waiting for their > approval, and these are needed to keep up with changes in the > underlying environment. > +1 -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 tibbs at math.uh.edu Mon Dec 15 17:32:48 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Dec 2008 11:32:48 -0600 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help Message-ID: Can someone tell me what package should own /usr/share/gnome/help, or if individual packages placing files there should own it? The latter seems to be the case, but that doesn't make a whole lot of sense to me. Is there any reason why /usr/share/gnome/help shouldn't just be owned by filesystem? It already owns /usr/share/gnome. Actually, it seems that several other packages own /usr/share/gnome too, which probably begs for some bugs to be filed. - J< From a.badger at gmail.com Mon Dec 15 17:42:12 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 15 Dec 2008 09:42:12 -0800 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: References: Message-ID: <494696F4.2070104@gmail.com> Jason L Tibbitts III wrote: > Can someone tell me what package should own /usr/share/gnome/help, or > if individual packages placing files there should own it? The latter > seems to be the case, but that doesn't make a whole lot of sense to > me. Is there any reason why /usr/share/gnome/help shouldn't just be > owned by filesystem? It already owns /usr/share/gnome. > yelp owns it. There's a question of whether packages which have gnome help should Require yelp or not. I think it's a bug if a package has a help menu that doesn't work so I lean towards requiring it. Others think help should be optional (like man pages and other documentation). If yelp is not Required, then filesystem should own /usr/share/gnome/help. If yelp is required, the filesystem ownership will do no harm. > Actually, it seems that several other packages own /usr/share/gnome > too, which probably begs for some bugs to be filed. > +1 -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 tibbs at math.uh.edu Mon Dec 15 18:08:11 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Dec 2008 12:08:11 -0600 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: <494696F4.2070104@gmail.com> References: <494696F4.2070104@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> yelp owns it. There's a question of whether packages which have TK> gnome help should Require yelp or not. What about a package that _only_ provides gnome help? The system-config-* packages have split out their documentation and I'm reviewing the new packages, but am stuck on this issue. TK> If yelp is not Required, then filesystem should own TK> /usr/share/gnome/help. If yelp is required, the filesystem TK> ownership will do no harm. This would imply that any package other than yelp or filesystem which owns /usr/share/gnome/help has a bug, I guess. More to file. - J< From tibbs at math.uh.edu Mon Dec 15 18:18:39 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Dec 2008 12:18:39 -0600 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: <494696F4.2070104@gmail.com> References: <494696F4.2070104@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TTK> yelp owns it. There's a question of whether packages which have TK> gnome help should Require yelp or not. I think it's a bug if a TK> package has a help menu that doesn't work so I lean towards TK> requiring it. For one reference, see https://bugzilla.redhat.com/show_bug.cgi?id=243408 which would tend to indicate that yelp should not generally be a dependency of packages which have gnome help However, the situation here may be different, since the package contains nothing other than help files. Are these not generally viewable without using yelp? (I.e. is there no KDE-based browser or command line client?) If not, what would be the point of having a package containing documentation that doesn't ensure that the system has a way to view it? - J< From a.badger at gmail.com Mon Dec 15 18:21:52 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 15 Dec 2008 10:21:52 -0800 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: References: <494696F4.2070104@gmail.com> Message-ID: <4946A040.4090406@gmail.com> Jason L Tibbitts III wrote: >>>>>> "TK" == Toshio Kuratomi writes: > > TK> yelp owns it. There's a question of whether packages which have > TK> gnome help should Require yelp or not. > > What about a package that _only_ provides gnome help? The > system-config-* packages have split out their documentation and I'm > reviewing the new packages, but am stuck on this issue. > From my point of view that the help button in the app should work, the new package doesn't need to split out the gnome-help portion as the app would need to require it anyway. And if the app requires it, the app package can also require yelp. However, maybe we need to decide whether it's okay for the help menu item to "not work". (ATM I believe the app appears to not do anything if yelp is not installed. Not sure what happens if yelp is installed but the help pages are not available.) If others think it's okay for Help to not pop up a help window then the sane thing to me would to move ownership of the directory into filesystem. > TK> If yelp is not Required, then filesystem should own > TK> /usr/share/gnome/help. If yelp is required, the filesystem > TK> ownership will do no harm. > > This would imply that any package other than yelp or filesystem which > owns /usr/share/gnome/help has a bug, I guess. More to file. > Yeah, after we get /usr/share/gnome/help into filesystem. -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 Mon Dec 15 18:52:01 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 15 Dec 2008 13:52:01 -0500 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: References: <494696F4.2070104@gmail.com> Message-ID: <1229367121.3343.10.camel@matthiasc> On Mon, 2008-12-15 at 12:08 -0600, Jason L Tibbitts III wrote: > >>>>> "TK" == Toshio Kuratomi writes: > > TK> yelp owns it. There's a question of whether packages which have > TK> gnome help should Require yelp or not. > > What about a package that _only_ provides gnome help? The > system-config-* packages have split out their documentation and I'm > reviewing the new packages, but am stuck on this issue. > > TK> If yelp is not Required, then filesystem should own > TK> /usr/share/gnome/help. If yelp is required, the filesystem > TK> ownership will do no harm. > > This would imply that any package other than yelp or filesystem which > owns /usr/share/gnome/help has a bug, I guess. More to file. Filing more bugs does not really help improve this situation. Fixing rpm to handle directories sensibly would. From tibbs at math.uh.edu Mon Dec 15 19:01:30 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Dec 2008 13:01:30 -0600 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: <1229367121.3343.10.camel@matthiasc> References: <494696F4.2070104@gmail.com> <1229367121.3343.10.camel@matthiasc> Message-ID: >>>>> "MC" == Matthias Clasen writes: MC> Filing more bugs does not really help improve this situation. It's just a directory ownership change. I mean, I'd just fix them, but then I'd expect to get flames. I guess I should expect that regardless. MC> Fixing rpm to handle directories sensibly would. That is not within my power. We have guidelines written for the rpm which currently exists. - J< From a.badger at gmail.com Mon Dec 15 19:17:29 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 15 Dec 2008 11:17:29 -0800 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: <1229367121.3343.10.camel@matthiasc> References: <494696F4.2070104@gmail.com> <1229367121.3343.10.camel@matthiasc> Message-ID: <4946AD49.3000807@gmail.com> Matthias Clasen wrote: > On Mon, 2008-12-15 at 12:08 -0600, Jason L Tibbitts III wrote: >>>>>>> "TK" == Toshio Kuratomi writes: >> TK> yelp owns it. There's a question of whether packages which have >> TK> gnome help should Require yelp or not. >> >> What about a package that _only_ provides gnome help? The >> system-config-* packages have split out their documentation and I'm >> reviewing the new packages, but am stuck on this issue. >> >> TK> If yelp is not Required, then filesystem should own >> TK> /usr/share/gnome/help. If yelp is required, the filesystem >> TK> ownership will do no harm. >> >> This would imply that any package other than yelp or filesystem which >> owns /usr/share/gnome/help has a bug, I guess. More to file. > > Filing more bugs does not really help improve this situation. What situation precisely? The passage quoted implicates adding /usr/share/gnome/help to the filesystem package and then changing individual packages to not own /usr/share/gnome/help as filesystem would then own it. That does seem like an improvement over the current situation. I have a feeling you're thinking of something more meta, though. > Fixing rpm to handle directories sensibly would. > This is probably something you need to talk to the rpm maintainers about. They've been making lots of changes to rpm recently. If you have a proposal, they'll be able to tell us if it's something that's doable in the continued rpm cleanup or something that goes too deeply into what rpm is. -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 Mon Dec 15 20:01:09 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 15 Dec 2008 12:01:09 -0800 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: References: <494696F4.2070104@gmail.com> Message-ID: <4946B785.4010404@gmail.com> Jason L Tibbitts III wrote: >>>>>> "TK" == Toshio Kuratomi writes: > > TTK> yelp owns it. There's a question of whether packages which have > TK> gnome help should Require yelp or not. I think it's a bug if a > TK> package has a help menu that doesn't work so I lean towards > TK> requiring it. > > For one reference, see > https://bugzilla.redhat.com/show_bug.cgi?id=243408 which would tend to > indicate that yelp should not generally be a dependency of packages > which have gnome help > Oops... I found the mailing list thread and there was a conclusion. Packages should not require yelp. Instead, packages that fail silently when yelp is not installed need a bug to print the error dialog returned from the gnome API. So it seems like filesystem owning /usr/share/gnome/help would be the best so that we don't need to have every package own /usr/share/gnome/help. -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 pertusus at free.fr Mon Dec 15 20:13:25 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 15 Dec 2008 21:13:25 +0100 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: <4946B785.4010404@gmail.com> References: <494696F4.2070104@gmail.com> <4946B785.4010404@gmail.com> Message-ID: <20081215201325.GA2386@free.fr> On Mon, Dec 15, 2008 at 12:01:09PM -0800, Toshio Kuratomi wrote: > > Oops... I found the mailing list thread and there was a conclusion. > Packages should not require yelp. Instead, packages that fail silently That was not my conclusion. My conclusion was that it was up to the packager. This doesn't change that your conclusion holds: > So it seems like filesystem owning /usr/share/gnome/help would be the > best so that we don't need to have every package own /usr/share/gnome/help. -- Pat From a.badger at gmail.com Mon Dec 15 21:34:55 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 15 Dec 2008 13:34:55 -0800 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: <20081215201325.GA2386@free.fr> References: <494696F4.2070104@gmail.com> <4946B785.4010404@gmail.com> <20081215201325.GA2386@free.fr> Message-ID: <4946CD7F.4060603@gmail.com> Patrice Dumas wrote: > On Mon, Dec 15, 2008 at 12:01:09PM -0800, Toshio Kuratomi wrote: >> Oops... I found the mailing list thread and there was a conclusion. >> Packages should not require yelp. Instead, packages that fail silently > > That was not my conclusion. My conclusion was that it was up to the > packager. > Well... https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01522.html Maybe there isn't a general case conclusion to draw but it sounds like treating help as an optional feature is what was decided for at least the desktop-team's subset of packages. We didn't generate any Guidelines out of that discussion so the package probably isn't going to raise any flags at review time. > This doesn't change that your conclusion holds: > >> So it seems like filesystem owning /usr/share/gnome/help would be the >> best so that we don't need to have every package own /usr/share/gnome/help. > -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 pertusus at free.fr Mon Dec 15 22:09:24 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 15 Dec 2008 23:09:24 +0100 Subject: [Fedora-packaging] Ownership of /usr/share/gnome/help In-Reply-To: <4946CD7F.4060603@gmail.com> References: <494696F4.2070104@gmail.com> <4946B785.4010404@gmail.com> <20081215201325.GA2386@free.fr> <4946CD7F.4060603@gmail.com> Message-ID: <20081215220923.GC2386@free.fr> On Mon, Dec 15, 2008 at 01:34:55PM -0800, Toshio Kuratomi wrote: > > Maybe there isn't a general case conclusion to draw but it sounds like > treating help as an optional feature is what was decided for at least > the desktop-team's subset of packages. We didn't generate any Indeed, and I remember there were some bugs filled. But the thread shows that there was no consensus, and, for example, I kept yelp as a gnochm dependency, considering that having a help window that comes when clicking on help wasn't optional, and that the bloat wasn't too important given that it already was a gnome app. That being said, I orphaned gnochm, so everybody is free to remove yelp :) # repoquery --whatrequires yelp gtranslator-0:1.1.7-9.fc10.i386 gnomesword-0:2.4.1-1.fc10.i386 gnochm-0:0.9.11-2.fc9.noarch lat-0:1.2.3-4.fc10.i386 conglomerate-0:0.9.1-5.fc9.i386 gnucash-docs-0:2.2.0-2.fc8.noarch gnomesword-0:2.4.0-1.fc10.i386 -- Pat From karsten at redhat.com Thu Dec 18 16:30:10 2008 From: karsten at redhat.com (Karsten Hopp) Date: Thu, 18 Dec 2008 17:30:10 +0100 Subject: [Fedora-packaging] Usage of {_libdir} or {_lib} in noarch packages Message-ID: <494A7A92.9020404@redhat.com> I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages which erronously use {_libdir} or {_lib} in their spec files. rpmdiff shows this output: ./firstaidkit-0.2.2-5.fc11.noarch.rpm removed /usr/lib/firstaidkit removed /usr/lib/firstaidkit/plugins added /usr/lib64/firstaidkit added /usr/lib64/firstaidkit/plugins As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs Here is the list of offending packages I've found: Package Owner ------------------------ ntfs-config laxathom firstaidkit msivak terminus-font ndim gdeskcal pfj libopensync-plugin-synce awjb cohoba tjikkun gnome-schedule farnold common-lisp-controller green gcstar tian revisor-cli jsteffan jruby konradm Can we make it a policy to not use _libdir or _lib in noarch packages, please ? Karsten From rc040203 at freenet.de Thu Dec 18 16:36:57 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 18 Dec 2008 17:36:57 +0100 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <494A7A92.9020404@redhat.com> References: <494A7A92.9020404@redhat.com> Message-ID: <1229618217.14090.543.camel@beck.corsepiu.local> On Thu, 2008-12-18 at 17:30 +0100, Karsten Hopp wrote: > I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages > which erronously use {_libdir} or {_lib} in their spec files. rpmdiff shows this output: > > ./firstaidkit-0.2.2-5.fc11.noarch.rpm > removed /usr/lib/firstaidkit > removed /usr/lib/firstaidkit/plugins > added /usr/lib64/firstaidkit > added /usr/lib64/firstaidkit/plugins > > As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs > > Here is the list of offending packages I've found: > > > Package Owner > ------------------------ > ntfs-config laxathom > firstaidkit msivak > terminus-font ndim > gdeskcal pfj > libopensync-plugin-synce awjb > cohoba tjikkun > gnome-schedule farnold > common-lisp-controller green > gcstar tian > revisor-cli jsteffan > jruby konradm > > > > Can we make it a policy to not use _libdir or _lib in noarch packages, please ? Wouldn't it be better to let rpm set _libdir/_lib to match noarch package requirements? Ralf From tcallawa at redhat.com Thu Dec 18 16:50:37 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 18 Dec 2008 11:50:37 -0500 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <1229618217.14090.543.camel@beck.corsepiu.local> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> Message-ID: <1229619037.3472.26.camel@localhost.localdomain> On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote: > Wouldn't it be better to let rpm set _libdir/_lib to match noarch > package requirements? What should it set it to? It has no knowledge of where the noarch rpm package will eventually be installed. Should we assume that /usr/lib is always correct (how Debian of me to even suggest this)? ~spot From jkeating at redhat.com Thu Dec 18 16:53:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Dec 2008 08:53:18 -0800 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <1229619037.3472.26.camel@localhost.localdomain> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> <1229619037.3472.26.camel@localhost.localdomain> Message-ID: <1229619198.6191.106.camel@localhost.localdomain> On Thu, 2008-12-18 at 11:50 -0500, Tom "spot" Callaway wrote: > On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote: > > Wouldn't it be better to let rpm set _libdir/_lib to match noarch > > package requirements? > > What should it set it to? It has no knowledge of where the noarch rpm > package will eventually be installed. Should we assume that /usr/lib is > always correct (how Debian of me to even suggest this)? > > ~spot Also, how does one get this right in the age of noarch subpackages to arch specific packages? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu Dec 18 17:00:01 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 18 Dec 2008 18:00:01 +0100 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <1229619037.3472.26.camel@localhost.localdomain> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> <1229619037.3472.26.camel@localhost.localdomain> Message-ID: <1229619601.14090.592.camel@beck.corsepiu.local> On Thu, 2008-12-18 at 11:50 -0500, Tom "spot" Callaway wrote: > On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote: > > Wouldn't it be better to let rpm set _libdir/_lib to match noarch > > package requirements? > > What should it set it to? It has no knowledge of where the noarch rpm > package will eventually be installed. It has. In case of noarch _lib always is the "default", which normally is lib. > Should we assume that /usr/lib is > always correct (how Debian of me to even suggest this)? In case of noarch, yes. Because an arch'aware (e.g. lib vs. lib64) _lib/_libdir qualifies a package as "arch'ed" Ralf From rc040203 at freenet.de Thu Dec 18 17:03:21 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 18 Dec 2008 18:03:21 +0100 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <1229619198.6191.106.camel@localhost.localdomain> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> <1229619037.3472.26.camel@localhost.localdomain> <1229619198.6191.106.camel@localhost.localdomain> Message-ID: <1229619801.14090.601.camel@beck.corsepiu.local> On Thu, 2008-12-18 at 08:53 -0800, Jesse Keating wrote: > On Thu, 2008-12-18 at 11:50 -0500, Tom "spot" Callaway wrote: > > On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote: > > > Wouldn't it be better to let rpm set _libdir/_lib to match noarch > > > package requirements? > > > > What should it set it to? It has no knowledge of where the noarch rpm > > package will eventually be installed. Should we assume that /usr/lib is > > always correct (how Debian of me to even suggest this)? > > > > ~spot > > Also, how does one get this right in the age of noarch subpackages to > arch specific packages? By properly parsing and preserving contexts in rpmbuild? Admitted, "proper", "parsing" and "contexts" don't go well along with rpm. Ralf From karsten at redhat.com Fri Dec 19 13:41:20 2008 From: karsten at redhat.com (Karsten Hopp) Date: Fri, 19 Dec 2008 14:41:20 +0100 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <1229618217.14090.543.camel@beck.corsepiu.local> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> Message-ID: <494BA480.4020108@redhat.com> Ralf Corsepius schrieb: > On Thu, 2008-12-18 at 17:30 +0100, Karsten Hopp wrote: >> I've run a x86_64 mass rebuild of all our Fedora packages and found several noarch packages >> which erronously use {_libdir} or {_lib} in their spec files. rpmdiff shows this output: >> >> ./firstaidkit-0.2.2-5.fc11.noarch.rpm >> removed /usr/lib/firstaidkit >> removed /usr/lib/firstaidkit/plugins >> added /usr/lib64/firstaidkit >> added /usr/lib64/firstaidkit/plugins >> >> As noarch packages can be built on any machine/architecture in koji, we'd end up with lib64 directories on 32bit archs >> >> Here is the list of offending packages I've found: >> >> >> Package Owner >> ------------------------ >> ntfs-config laxathom >> firstaidkit msivak >> terminus-font ndim >> gdeskcal pfj >> libopensync-plugin-synce awjb >> cohoba tjikkun >> gnome-schedule farnold >> common-lisp-controller green >> gcstar tian >> revisor-cli jsteffan >> jruby konradm >> >> >> >> Can we make it a policy to not use _libdir or _lib in noarch packages, please ? > Wouldn't it be better to let rpm set _libdir/_lib to match noarch > package requirements? > > Ralf > > I don't have any preferences on how we solve it, I'll leave that for FPC to decide. But I think it needs to be solved or we'll run out of luck and build one of those packages on 64bit anytime soon. Karsten From Axel.Thimm at ATrpms.net Sat Dec 20 14:57:52 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 20 Dec 2008 16:57:52 +0200 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <1229619037.3472.26.camel@localhost.localdomain> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> <1229619037.3472.26.camel@localhost.localdomain> Message-ID: <20081220145752.GA12856@victor.nirvana> On Thu, Dec 18, 2008 at 11:50:37AM -0500, Tom spot Callaway wrote: > On Thu, 2008-12-18 at 17:36 +0100, Ralf Corsepius wrote: > > Wouldn't it be better to let rpm set _libdir/_lib to match noarch > > package requirements? > > What should it set it to? It has no knowledge of where the noarch rpm > package will eventually be installed. Should we assume that /usr/lib is > always correct (how Debian of me to even suggest this)? Isn't the norach equivalent of _libdir _datadir? Or phrased in another way: Shouldn't a noach package avoid both lib and lib64? I think we even have rules already set for this. I don't quite agree that rpm should start changing _libdir to point to _datadir, but the packagers should probably patch up the packages to use _datadir instead of _libdir if the package is indeed noarch. -- Axel.Thimm at ATrpms.net -------------- 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 Sat Dec 20 16:58:34 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 20 Dec 2008 10:58:34 -0600 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <20081220145752.GA12856@victor.nirvana> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> <1229619037.3472.26.camel@localhost.localdomain> <20081220145752.GA12856@victor.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> Isn't the norach equivalent of _libdir _datadir? Or phrased in AT> another way: Shouldn't a noach package avoid both lib and lib64? I AT> think we even have rules already set for this. Well, sort of, but it doesn't always work out that way in practise. Witness Perl and Python, for example, which should both put arch-independent modules in datadir but put them in /usr/lib instead. Which leads to the fun situation where you can get it wrong and have the package work on i386 but fail to build on x86_64. Still, those languages have their own macros which give you the right thing. We don't have anything in general, and I agree that we shouldn't really encourage it. When really necessary, I've always recommended just using %{_prefix}/lib to make it really obvious. - J< From jkeating at redhat.com Sat Dec 20 19:46:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 20 Dec 2008 11:46:44 -0800 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <20081220145752.GA12856@victor.nirvana> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> <1229619037.3472.26.camel@localhost.localdomain> <20081220145752.GA12856@victor.nirvana> Message-ID: <1229802404.3861.15.camel@localhost.localdomain> On Sat, 2008-12-20 at 16:57 +0200, Axel Thimm wrote: > Isn't the norach equivalent of _libdir _datadir? Or phrased in another > way: Shouldn't a noach package avoid both lib and lib64? I think we > even have rules already set for this. > > I don't quite agree that rpm should start changing _libdir to point > to _datadir, but the packagers should probably patch up the packages > to use _datadir instead of _libdir if the package is indeed noarch. What about noarch python modules which live in /usr/lib/python(ver)/site-packages/ ? Perl in /usr/lib/perl(ver)/ ? So on, and so forth. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Sat Dec 20 20:31:49 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 20 Dec 2008 21:31:49 +0100 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <1229802404.3861.15.camel@localhost.localdomain> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> <1229619037.3472.26.camel@localhost.localdomain> <20081220145752.GA12856@victor.nirvana> <1229802404.3861.15.camel@localhost.localdomain> Message-ID: <20081220203149.GC2790@free.fr> On Sat, Dec 20, 2008 at 11:46:44AM -0800, Jesse Keating wrote: > > What about noarch python modules which live > in /usr/lib/python(ver)/site-packages/ ? Perl in /usr/lib/perl(ver)/ ? > So on, and so forth. Should be the only 2 exceptions. In my opinion these are wrong but long established, and maybe not worth changing, or it is to be seen with their maintainers. There is a rpmlint warning when there is only noarch content in %_libdir, I think this is right. -- Pat From nicolas.mailhot at laposte.net Mon Dec 22 11:16:40 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 22 Dec 2008 12:16:40 +0100 Subject: [Fedora-packaging] Font package naming guidelines Message-ID: <1229944600.20011.10.camel@arekh.okg> Hi, Since there has been no more remarks on the clarified font package naming rules discussed as part of http://fedoraproject.org/wiki/Fonts_SIG_Fedora_11_packaging_changes_(2008-11-08) I've queued the following for approval FPC-side: http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_(2008-12-22) Except for the comps changes which seem not baked yet, that concludes the fonts-related guidelines changes and clarifications that were proposed for F11. Sincerely, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Mon Dec 22 11:17:58 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 22 Dec 2008 12:17:58 +0100 Subject: [Fedora-packaging] Font package splitting clarification Message-ID: <1229944678.20011.12.camel@arekh.okg> [Drat. I *knew* I had forgotten to spam one list] Hi all, Since the discussion on font package splitting rules seems to be exhausted, and since no one stepped up with an obviously better proposal than mine, I've queued the following FPC-side: http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21) I've tried to integrate all the exceptions that were brought up during the discussion and that were consensual, and to separate the rules from their rationale (so packagers in a hurry only need to read the first part). I've ended up with four simple master rules that should not be open to interpretation. Best regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From opensource at till.name Mon Dec 22 11:49:05 2008 From: opensource at till.name (Till Maas) Date: Mon, 22 Dec 2008 12:49:05 +0100 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <20081220203149.GC2790@free.fr> References: <494A7A92.9020404@redhat.com> <1229802404.3861.15.camel@localhost.localdomain> <20081220203149.GC2790@free.fr> Message-ID: <200812221249.17145.opensource@till.name> On Saturday 20 December 2008 21:31:49 Patrice Dumas wrote: > On Sat, Dec 20, 2008 at 11:46:44AM -0800, Jesse Keating wrote: > > What about noarch python modules which live > > in /usr/lib/python(ver)/site-packages/ ? Perl in /usr/lib/perl(ver)/ ? > > So on, and so forth. > > Should be the only 2 exceptions. In my opinion these are wrong but long > established, and maybe not worth changing, or it is to be seen with > their maintainers. > > There is a rpmlint warning when there is only noarch content in > %_libdir, I think this is right. Here is another exception you might consider: $ rpm -qf /usr/lib/rpm/redhat/find-requires redhat-rpm-config-9.0.3-3.fc10.noarch Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pertusus at free.fr Mon Dec 22 12:09:04 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 22 Dec 2008 13:09:04 +0100 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <200812221249.17145.opensource@till.name> References: <494A7A92.9020404@redhat.com> <1229802404.3861.15.camel@localhost.localdomain> <20081220203149.GC2790@free.fr> <200812221249.17145.opensource@till.name> Message-ID: <20081222120904.GA2410@free.fr> On Mon, Dec 22, 2008 at 12:49:05PM +0100, Till Maas wrote: > > Here is another exception you might consider: > > $ rpm -qf /usr/lib/rpm/redhat/find-requires > redhat-rpm-config-9.0.3-3.fc10.noarch This is not the same here. Here it is a mixed arch/noarch package. The redhat-rpm-config happens to be strictly noarch, but it isn't the case for rpm-build, for example rpmdeps is an ELF file. That being said, this is unclear to me whether using /usr/lib is right or wrong for rpm. Maybe the scripts should be in _libexec, and the macros in _datadir. -- Pat From mtasaka at ioa.s.u-tokyo.ac.jp Mon Dec 22 12:14:55 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 22 Dec 2008 21:14:55 +0900 Subject: [Fedora-packaging] Re: Usage of {_libdir} or {_lib} in noarch packages In-Reply-To: <20081220203149.GC2790@free.fr> References: <494A7A92.9020404@redhat.com> <1229618217.14090.543.camel@beck.corsepiu.local> <1229619037.3472.26.camel@localhost.localdomain> <20081220145752.GA12856@victor.nirvana> <1229802404.3861.15.camel@localhost.localdomain> <20081220203149.GC2790@free.fr> Message-ID: <494F84BF.2020905@ioa.s.u-tokyo.ac.jp> Patrice Dumas wrote, at 12/21/2008 05:31 AM +9:00: > On Sat, Dec 20, 2008 at 11:46:44AM -0800, Jesse Keating wrote: >> What about noarch python modules which live >> in /usr/lib/python(ver)/site-packages/ ? Perl in /usr/lib/perl(ver)/ ? >> So on, and so forth. > > Should be the only 2 exceptions. In my opinion these are wrong but long > established, and maybe not worth changing, or it is to be seen with > their maintainers. > > There is a rpmlint warning when there is only noarch content in > %_libdir, I think this is right. > > -- > Pat And Ruby always uses /usr/lib/ruby. Another example is /usr/lib/bonobo/servers (ref: bug 463054) Mamoru From ville.skytta at iki.fi Thu Dec 25 06:47:06 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 25 Dec 2008 08:47:06 +0200 Subject: [Fedora-packaging] Missing links in Packaging:Debuginfo Message-ID: <200812250847.07465.ville.skytta@iki.fi> The "StackTraces" words in https://fedoraproject.org/wiki/Packaging:Debuginfo are no longer linked to https://fedoraproject.org/wiki/StackTraces From tcallawa at redhat.com Thu Dec 25 13:58:57 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 25 Dec 2008 08:58:57 -0500 Subject: [Fedora-packaging] Missing links in Packaging:Debuginfo In-Reply-To: <200812250847.07465.ville.skytta@iki.fi> References: <200812250847.07465.ville.skytta@iki.fi> Message-ID: <1230213537.24440.3.camel@localhost.localdomain> On Thu, 2008-12-25 at 08:47 +0200, Ville Skytt? wrote: > The "StackTraces" words in https://fedoraproject.org/wiki/Packaging:Debuginfo > are no longer linked to https://fedoraproject.org/wiki/StackTraces Fixed, thanks. ~spot From henriquecsj at gmail.com Fri Dec 26 15:54:00 2008 From: henriquecsj at gmail.com (Henrique Junior) Date: Fri, 26 Dec 2008 13:54:00 -0200 Subject: [Fedora-packaging] Problems accessing Koji website. Message-ID: <4f629b520812260754k44b2cc21r41a320084b976383@mail.gmail.com> Hello, everyone. I am submitting my first package and found some difficulty accessing Koji's website[1]. As specified in the "PackageMaintainers /Join"[2], I've runned "fedora-setup package", creating the file ~/fedora-browser-cert.p12. Importing it to Firefox [3] I went to the Koji' page and get a first warning that said that Koji's page doesn't have a trusted certificate (Error code: sec_error_untrusted_issuer); continue adding an exception, the page to check my ssl certificate returned the following error: (Error code: ssl_error_revoked_cert_alert). Am I doing something wrong? Excuse me for the inconvenience. Happy new year to all. [1] - https://koji.fedoraproject.org/koji/login [2] - https://fedoraproject.org/wiki/PackageMaintainers/Join [3] - http://img267.imageshack.us/img267/3248/capturadetelakj3.png -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Tue Dec 30 15:44:26 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 30 Dec 2008 16:44:26 +0100 (CET) Subject: [Fedora-packaging] Re: fontpackages template warnings In-Reply-To: <9d8b98149e12fc36d76c5a2cc35b1d61.squirrel@arekh.dyndns.org> References: <20081230142910.GA29904@gallagher.di.uoa.gr> <9d8b98149e12fc36d76c5a2cc35b1d61.squirrel@arekh.dyndns.org> Message-ID: <937de2565ad43ad918ed7c6e1f296ee8.squirrel@arekh.dyndns.org> Le Mar 30 d?cembre 2008 16:37, Nicolas Mailhot a ?crit : > > Le Mar 30 d?cembre 2008 15:29, Sarantis Paskalis a ?crit : >> Hello, > > Hi, > > Thank you for adapting your packages and providing feedback! > >> I am converting my font packages to the new guidelines and hit some >> rpmlint warnings that appear to be template related. Specifically, >> I >> followed the /etc/rpmdevtools/spectemplate-fonts-multi.spec from >> fontpackages-devel that creates absolute symlinks between >> /etc/fonts/conf.d/$font.conf and >> /usr/share/fontconfig/conf.avail/$font.conf >> rpmlint moans about the absolute symlink and wants a relative one. >> I >> don't really have an opinion about that and could not find any >> fedora >> policy on this one [1]. > > I didn't find a simple (for me and packagers) way to create relative > symlinks here. Individual packages are not supposed to know the values > of the directory macros since FPC asked for them in part to hide > future value changes from individual packagers. drat, should have read your link before commenting. I'm not sure how ok it is to add a dep to symlinks for fontpackages-devel. It looks harmless enough, but is this package even in all our spins? I suppose if I change the templates to use the symlinks command to avoid the rpmlint warning, I need to notify FPC at least (even if it's a minor change, it's still a guidelines change) -- Nicolas Mailhot From paskalis at di.uoa.gr Wed Dec 31 10:00:08 2008 From: paskalis at di.uoa.gr (Sarantis Paskalis) Date: Wed, 31 Dec 2008 12:00:08 +0200 Subject: [Fedora-packaging] Re: fontpackages template warnings In-Reply-To: <937de2565ad43ad918ed7c6e1f296ee8.squirrel@arekh.dyndns.org> References: <20081230142910.GA29904@gallagher.di.uoa.gr> <9d8b98149e12fc36d76c5a2cc35b1d61.squirrel@arekh.dyndns.org> <937de2565ad43ad918ed7c6e1f296ee8.squirrel@arekh.dyndns.org> Message-ID: <20081231100007.GA4926@gallagher.di.uoa.gr> On Tue, Dec 30, 2008 at 04:44:26PM +0100, Nicolas Mailhot wrote: > > > Le Mar 30 d?cembre 2008 16:37, Nicolas Mailhot a ?crit : > > > > Le Mar 30 d?cembre 2008 15:29, Sarantis Paskalis a ?crit : > >> Hello, > > > > Hi, > > > > Thank you for adapting your packages and providing feedback! > > > >> I am converting my font packages to the new guidelines and hit some > >> rpmlint warnings that appear to be template related. Specifically, > >> I > >> followed the /etc/rpmdevtools/spectemplate-fonts-multi.spec from > >> fontpackages-devel that creates absolute symlinks between > >> /etc/fonts/conf.d/$font.conf and > >> /usr/share/fontconfig/conf.avail/$font.conf > >> rpmlint moans about the absolute symlink and wants a relative one. > >> I > >> don't really have an opinion about that and could not find any > >> fedora > >> policy on this one [1]. > > > > I didn't find a simple (for me and packagers) way to create relative > > symlinks here. Individual packages are not supposed to know the values > > of the directory macros since FPC asked for them in part to hide > > future value changes from individual packagers. > > drat, should have read your link before commenting. > I'm not sure how ok it is to add a dep to symlinks for > fontpackages-devel. It looks harmless enough, but is this package even > in all our spins? Just for completeness, the link in question is http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/25 > I suppose if I change the templates to use the symlinks command to > avoid the rpmlint warning, I need to notify FPC at least (even if it's > a minor change, it's still a guidelines change) -- Sarantis