From pertusus at free.fr Sun Jun 1 08:00:29 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 1 Jun 2008 10:00:29 +0200 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <4841DAA5.7090807@gmail.com> References: <4840B051.9040804@gmail.com> <20080531093725.GB2608@free.fr> <4841DAA5.7090807@gmail.com> Message-ID: <20080601080029.GA2600@free.fr> On Sat, May 31, 2008 at 04:09:25PM -0700, Toshio Kuratomi wrote: > > However, the flipside of this is if a program has an xml config file > that the user is expected to edit manually in a text editor and the > program will adapt to multiple encodings (for instance, by using libxml2 > to parse the file[1]_) having it exist in utf-8 is much better than > having it exist in SOME_EXOTIC_ENCODING. In this case it's the program I disagree. It is not an obvious choice and should be left to the maintainer. It depends on the user target of the software, for instance. > not upstream agrees. In the case of documentation that does specify the > encoding I lean towards converting [2]_. In the case of a file that is > used by a program we should definitely have a conversation with upstream > about it, although we could convert locally with upstream's blessing > (ie: Upstream says: "I'm going to continue writing my xml config file in > latin-1. If you want to convert them to utf-8 for your users that's > fine -- I'm going to continue to use a library for xml parsing that > understands encodings.") Once again, better leave it to the maintainer. This doesn't prevent from issuing recommendations, though. -- Pat From a.badger at gmail.com Sun Jun 1 17:17:32 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 01 Jun 2008 10:17:32 -0700 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <20080601080029.GA2600@free.fr> References: <4840B051.9040804@gmail.com> <20080531093725.GB2608@free.fr> <4841DAA5.7090807@gmail.com> <20080601080029.GA2600@free.fr> Message-ID: <4842D9AC.9060106@gmail.com> Patrice Dumas wrote: > On Sat, May 31, 2008 at 04:09:25PM -0700, Toshio Kuratomi wrote: >> However, the flipside of this is if a program has an xml config file >> that the user is expected to edit manually in a text editor and the >> program will adapt to multiple encodings (for instance, by using libxml2 >> to parse the file[1]_) having it exist in utf-8 is much better than >> having it exist in SOME_EXOTIC_ENCODING. In this case it's the program > > I disagree. It is not an obvious choice and should be left to the > maintainer. It depends on the user target of the software, for instance. > Please state your counter example. I'm laying out the parameters by which we could relax the current rule. If we don't lay out the boundaries correctly the replacement rule will end up still being too restrictive. -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 Sun Jun 1 19:24:55 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 1 Jun 2008 21:24:55 +0200 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <4842D9AC.9060106@gmail.com> References: <4840B051.9040804@gmail.com> <20080531093725.GB2608@free.fr> <4841DAA5.7090807@gmail.com> <20080601080029.GA2600@free.fr> <4842D9AC.9060106@gmail.com> Message-ID: <20080601192455.GD2597@free.fr> On Sun, Jun 01, 2008 at 10:17:32AM -0700, Toshio Kuratomi wrote: > Patrice Dumas wrote: >> On Sat, May 31, 2008 at 04:09:25PM -0700, Toshio Kuratomi wrote: >>> However, the flipside of this is if a program has an xml config file >>> that the user is expected to edit manually in a text editor and the >>> program will adapt to multiple encodings (for instance, by using >>> libxml2 to parse the file[1]_) having it exist in utf-8 is much >>> better than having it exist in SOME_EXOTIC_ENCODING. In this case >>> it's the program >> >> I disagree. It is not an obvious choice and should be left to the >> maintainer. It depends on the user target of the software, for instance. >> > Please state your counter example. I'm laying out the parameters by > which we could relax the current rule. If we don't lay out the > boundaries correctly the replacement rule will end up still being too > restrictive. I may be wrong, but it seems to me that there is no current rule? Except that rpmlint warning/errors should be handled if possible, but there is nothing about that in the guidelines (spec file and filename should be utf8, though). Here is a wording that would seem right to me: Files that don't carry information about their encoding should be converted to UTF-8. It is typically useful for NEWS files with author names with acceented characters. There may be exceptions, for example a README.cn file written in chinese may be encoded in a popular chinese encoding like Big5. Files that carry over their encoding (xml, tex, info...) may also be converted to UTF-8, but the decision is left to the package maintainer. It may be especially relevant for files that are to be edited by the user, since it may be difficult to edit a file not in UTF-8, while UTF-8 should be handled by most editors automatically, as the default for fedora is an UTF-8 locale. -- Pat From a.badger at gmail.com Sun Jun 1 19:53:06 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 01 Jun 2008 12:53:06 -0700 Subject: [Fedora-packaging] CMake link to upstream documentation added Message-ID: <4842FE22.9020007@gmail.com> I at the request of liquidat and cmake upstream I added some links to upstream's documentation to our cmake page: https://fedoraproject.org/wiki/Packaging/cmake This seemed straightforward. If anyone has issues with it, holler and we can discuss it at the Packaging Meeting. -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 Sun Jun 1 20:18:02 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 01 Jun 2008 13:18:02 -0700 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <20080601192455.GD2597@free.fr> References: <4840B051.9040804@gmail.com> <20080531093725.GB2608@free.fr> <4841DAA5.7090807@gmail.com> <20080601080029.GA2600@free.fr> <4842D9AC.9060106@gmail.com> <20080601192455.GD2597@free.fr> Message-ID: <484303FA.9020800@gmail.com> Patrice Dumas wrote: > On Sun, Jun 01, 2008 at 10:17:32AM -0700, Toshio Kuratomi wrote: >> Patrice Dumas wrote: >>> On Sat, May 31, 2008 at 04:09:25PM -0700, Toshio Kuratomi wrote: >>>> However, the flipside of this is if a program has an xml config file >>>> that the user is expected to edit manually in a text editor and the >>>> program will adapt to multiple encodings (for instance, by using >>>> libxml2 to parse the file[1]_) having it exist in utf-8 is much >>>> better than having it exist in SOME_EXOTIC_ENCODING. In this case >>>> it's the program >>> I disagree. It is not an obvious choice and should be left to the >>> maintainer. It depends on the user target of the software, for instance. >>> >> Please state your counter example. I'm laying out the parameters by >> which we could relax the current rule. If we don't lay out the >> boundaries correctly the replacement rule will end up still being too >> restrictive. > > I may be wrong, but it seems to me that there is no current rule? Except > that rpmlint warning/errors should be handled if possible, but there is > nothing about that in the guidelines (spec file and filename should be > utf8, though). > My bad, I must have been recalling the debates over the filename's must be utf-8 guideline. If there's no current guideline then I'm not sure we need a new one. > Here is a wording that would seem right to me: > > Files that don't carry information about their encoding should be > converted to UTF-8. It is typically useful for NEWS files with author > names with acceented characters. There may be exceptions, for example a > README.cn file written in chinese may be encoded in a popular chinese > encoding like Big5. > I could go either way on this but lean towards this should be utf-8. ShiftJS, Big5, etc have benefits over UTF-8 and the people who use those are the consumers of this file. OTOH, for Fedora to truly support the UTF-8 locale out of the box, these kinds of files (which don't specify an encoding and aren't used by the program) have to be UTF-8. How can we ship with a UTF-8 locale by default knowing that the README.cn isn't readable by people who stick with our default? > Files that carry over their encoding (xml, tex, info...) may also be > converted to UTF-8, but the decision is left to the package maintainer. > It may be especially relevant for files that are to be edited by the > user, since it may be difficult to edit a file not in UTF-8, while UTF-8 > should be handled by most editors automatically, as the default for > fedora is an UTF-8 locale. This part seems quite reasonable as a recommendation. -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 Sun Jun 1 21:42:32 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 1 Jun 2008 23:42:32 +0200 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <484303FA.9020800@gmail.com> References: <4840B051.9040804@gmail.com> <20080531093725.GB2608@free.fr> <4841DAA5.7090807@gmail.com> <20080601080029.GA2600@free.fr> <4842D9AC.9060106@gmail.com> <20080601192455.GD2597@free.fr> <484303FA.9020800@gmail.com> Message-ID: <20080601214232.GF2597@free.fr> On Sun, Jun 01, 2008 at 01:18:02PM -0700, Toshio Kuratomi wrote: >> > My bad, I must have been recalling the debates over the filename's must > be utf-8 guideline. If there's no current guideline then I'm not sure > we need a new one. Agreed. > I could go either way on this but lean towards this should be utf-8. > ShiftJS, Big5, etc have benefits over UTF-8 and the people who use those > are the consumers of this file. OTOH, for Fedora to truly support the > UTF-8 locale out of the box, these kinds of files (which don't specify > an encoding and aren't used by the program) have to be UTF-8. How can > we ship with a UTF-8 locale by default knowing that the README.cn isn't > readable by people who stick with our default? Once again I think that it really depends on the package user community. I don't know anything about asian encodings, but if the packager thinks that users anticipate a file encoded in Big5 he could leave it in the original encoding. -- Pat From overholt at redhat.com Mon Jun 2 14:36:33 2008 From: overholt at redhat.com (Andrew Overholt) Date: Mon, 02 Jun 2008 10:36:33 -0400 Subject: [Fedora-packaging] eclipse plugin without feature.xml In-Reply-To: <89b36810805301507g506404a5pdfd3a79a89e300c1@mail.gmail.com> References: <89b36810805301507g506404a5pdfd3a79a89e300c1@mail.gmail.com> Message-ID: <1212417393.24760.6.camel@blingbling> Hi On Sat, 2008-05-31 at 00:07 +0200, Sergio Pascual wrote: > Hello, I'm trying to package a eclipse plugin called veditor. I have > followed the guidelines in wiki/Packaging/EclipsePlugins > The zip with the source code contains a file plugin.xmll but doesn't > contain feature.xml. When building, > > %{eclipse_base}/buildscripts/pdebuild -f net.sourceforge.veditor > > fails, because feature.xml doesn't exist. How do I build with > plugin.xml but without feature.xml? Until package-build (a wrapper around PDE Build) supports building plugins which have no containing feature, you'll either need to spoof up a feature.xml like eclipse-quickrex -- and offer it to upstream, please :) -- or build like the following but with a spoofed build/assemble.net.sourceforge.veditor.all.xml (look for another simple package's generated one for inspiration): # See attached patch patch < veditorbuild.patch ant -f buildjavacc.xml # This next bit is essentially what pde-build wraps eclipse -nosplash -Duser.home=`pwd`/home \ -application org.eclipse.ant.core.antRunner \ -Dtype=plugin -Did=net.sourceforge.veditor \ -DsourceDirectory=$(pwd) \ -DbaseLocation=$SDK \ -Dbuilder=/usr/share/eclipse/plugins/org.eclipse.pde.build/templates/package-build \ -DjavacSource=1.5 -DjavacTarget=1.5 \ -f /usr/share/eclipse/plugins/org.eclipse.pde.build/scripts/build.xml HTH, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: veditorbuild.patch Type: text/x-patch Size: 947 bytes Desc: not available URL: From ville.skytta at iki.fi Mon Jun 2 15:26:03 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 2 Jun 2008 18:26:03 +0300 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <20080531093725.GB2608@free.fr> References: <4840B051.9040804@gmail.com> <20080531093725.GB2608@free.fr> Message-ID: <200806021826.04236.ville.skytta@iki.fi> On Saturday 31 May 2008, Patrice Dumas wrote: > On Fri, May 30, 2008 at 06:56:33PM -0700, Toshio Kuratomi wrote: > > Reencoding the xml files that specify an encoding isn't strictly > > necessary. We should probably ask upstream whether they are amenable to > > I think that reencoding files that carry over the encoding information > (info, texinfo, tex and xml for example) is wrong. It is better to let > upstream do whatever they want. I agree with Toshio on this one, IMO it's not necessarily wrong. Anyway wrt. XML files, upstreams probably wouldn't mind a friendly reminder that the only encodings conformant XML processors are required to support are UTF-8 and UTF-16. From pertusus at free.fr Mon Jun 2 20:35:24 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 2 Jun 2008 22:35:24 +0200 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <200806021826.04236.ville.skytta@iki.fi> References: <4840B051.9040804@gmail.com> <20080531093725.GB2608@free.fr> <200806021826.04236.ville.skytta@iki.fi> Message-ID: <20080602203524.GA2594@free.fr> On Mon, Jun 02, 2008 at 06:26:03PM +0300, Ville Skytt? wrote: > On Saturday 31 May 2008, Patrice Dumas wrote: > > On Fri, May 30, 2008 at 06:56:33PM -0700, Toshio Kuratomi wrote: > > > Reencoding the xml files that specify an encoding isn't strictly > > > necessary. We should probably ask upstream whether they are amenable to > > > > I think that reencoding files that carry over the encoding information > > (info, texinfo, tex and xml for example) is wrong. It is better to let > > upstream do whatever they want. > > I agree with Toshio on this one, IMO it's not necessarily wrong. Anyway wrt. I don't disagree. I think it should be left to the maintainer. -- Pat From a.badger at gmail.com Mon Jun 2 22:52:05 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 02 Jun 2008 15:52:05 -0700 Subject: [Fedora-packaging] file-not-utf8 complaints In-Reply-To: <20080601214232.GF2597@free.fr> References: <4840B051.9040804@gmail.com> <20080531093725.GB2608@free.fr> <4841DAA5.7090807@gmail.com> <20080601080029.GA2600@free.fr> <4842D9AC.9060106@gmail.com> <20080601192455.GD2597@free.fr> <484303FA.9020800@gmail.com> <20080601214232.GF2597@free.fr> Message-ID: <48447995.7080409@gmail.com> Patrice Dumas wrote: > On Sun, Jun 01, 2008 at 01:18:02PM -0700, Toshio Kuratomi wrote: >> I could go either way on this but lean towards this should be utf-8. >> ShiftJS, Big5, etc have benefits over UTF-8 and the people who use those >> are the consumers of this file. OTOH, for Fedora to truly support the >> UTF-8 locale out of the box, these kinds of files (which don't specify >> an encoding and aren't used by the program) have to be UTF-8. How can >> we ship with a UTF-8 locale by default knowing that the README.cn isn't >> readable by people who stick with our default? > > Once again I think that it really depends on the package user community. > I don't know anything about asian encodings, but if the packager thinks > that users anticipate a file encoded in Big5 he could leave it in the > original encoding. > I think you're wrong on this. We ship with a default locale choice that has utf-8 as the encoding. If the user is changing the default, they can't expect things to work. More importantly, if the user is leaving the defaults alone, they should be able to expect things to work. The choice of UTF-8 encoding for a locale is something we do at the distribution level. Everything we ship in the distribution should work with that choice. For files that do not specify this encoding, there's no way to satisfy that requirement except to ship them as UTF-8. -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 kagesenshi.87 at gmail.com Mon Jun 9 03:07:42 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Mon, 9 Jun 2008 11:07:42 +0800 Subject: [Fedora-packaging] No build ID note found - how to resolve this? Message-ID: + /usr/lib/rpm/find-debuginfo.sh --strict-build-id /builddir/build/BUILD/libitl-0.6.4 extracting debug info from /var/tmp/libitl-0.6.4-4.fc10-root-mockbuild/usr/lib/libitl.so.0.0.6 *** ERROR: No build ID note found in /var/tmp/libitl-0.6.4-4.fc10-root-mockbuild/usr/lib/libitl.so.0.0.6 What should I do to resolve that?. FTBFS bug 449622 . This package previously builds fine on F9. -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From paul at city-fan.org Mon Jun 9 07:00:39 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 9 Jun 2008 08:00:39 +0100 Subject: [Fedora-packaging] No build ID note found - how to resolve this? In-Reply-To: References: Message-ID: <20080609080039.4a67f171@metropolis.intra.city-fan.org> On Mon, 9 Jun 2008 11:07:42 +0800 "Izhar Firdaus" wrote: > + /usr/lib/rpm/find-debuginfo.sh --strict-build-id > /builddir/build/BUILD/libitl-0.6.4 > extracting debug info from > /var/tmp/libitl-0.6.4-4.fc10-root-mockbuild/usr/lib/libitl.so.0.0.6 > *** ERROR: No build ID note found in > /var/tmp/libitl-0.6.4-4.fc10-root-mockbuild/usr/lib/libitl.so.0.0.6 > > What should I do to resolve that?. FTBFS bug 449622 . This package > previously builds fine on F9. Adding "LDFLAGS+=--build-id" to the "make" invocations in both %build and %install seems to fix it. Paul. From mtasaka at ioa.s.u-tokyo.ac.jp Mon Jun 9 07:15:24 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 09 Jun 2008 16:15:24 +0900 Subject: [Fedora-packaging] No build ID note found - how to resolve this? In-Reply-To: References: Message-ID: <484CD88C.4040806@ioa.s.u-tokyo.ac.jp> Izhar Firdaus wrote, at 06/09/2008 12:07 PM +9:00: > + /usr/lib/rpm/find-debuginfo.sh --strict-build-id > /builddir/build/BUILD/libitl-0.6.4 > extracting debug info from > /var/tmp/libitl-0.6.4-4.fc10-root-mockbuild/usr/lib/libitl.so.0.0.6 > *** ERROR: No build ID note found in > /var/tmp/libitl-0.6.4-4.fc10-root-mockbuild/usr/lib/libitl.so.0.0.6 > > What should I do to resolve that?. FTBFS bug 449622 . This package > previously builds fine on F9. Your package are calling ld directly. http://www.redhat.com/archives/fedora-maintainers/2007-August/msg00135.html This patch seems to work. ---------------------------------------------------------------------------- --- libitl-0.6.4/Makefile.ld 2008-06-09 16:05:30.000000000 +0900 +++ libitl-0.6.4/Makefile 2008-06-09 16:06:23.000000000 +0900 @@ -23,7 +23,7 @@ @false build/libitl.so: components - $(LD) build/*.o $(LDFLAGS) -shared -lm -lc -soname=$(SONAME) -o build/$(FULLNAME) + $(CC) build/*.o $(LDFLAGS) -shared -lm -lc -Wl,-soname,$(SONAME) -o build/$(FULLNAME) (cd build/ && ln -sf $(FULLNAME) $(SONAME)) (cd build/ && ln -sf $(FULLNAME) libitl.so) ---------------------------------------------------------------------------- Regards, Mamoru From pertusus at free.fr Mon Jun 9 08:01:04 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 9 Jun 2008 10:01:04 +0200 Subject: [Fedora-packaging] clarification about the DraftsTodo table to edit Message-ID: <20080609080104.GD2566@free.fr> Hello, I try to follow the http://fedoraproject.org/wiki/Packaging/Committee#Guideline_Change_Procedure to resubmit a guideline that didn't pass the vote the first time. But in the Step One, there is: Once you're happy with the Draft, add it to the DraftsTodo table. However there are 3 tables in DraftsTodo table, one with 'Has a Driver', one with 'Queued but Unowned', and one 'Tabled (On indefinite hold)'. The most logical seems to be 'Has a Driver', but it is not very clear. In fact it looks less like a page where new guidelines are proposed than like a page holding the status of current guidelines under review. Maybe there could be a new table with the packaging drafts proposed? -- Pat From kagesenshi.87 at gmail.com Mon Jun 9 08:08:32 2008 From: kagesenshi.87 at gmail.com (Izhar Firdaus) Date: Mon, 9 Jun 2008 16:08:32 +0800 Subject: [Fedora-packaging] No build ID note found - how to resolve this? In-Reply-To: <484CD88C.4040806@ioa.s.u-tokyo.ac.jp> References: <484CD88C.4040806@ioa.s.u-tokyo.ac.jp> Message-ID: thanks , compiles ok now (^_^) On Mon, Jun 9, 2008 at 3:15 PM, Mamoru Tasaka wrote: > Izhar Firdaus wrote, at 06/09/2008 12:07 PM +9:00: >> >> + /usr/lib/rpm/find-debuginfo.sh --strict-build-id >> /builddir/build/BUILD/libitl-0.6.4 >> extracting debug info from >> /var/tmp/libitl-0.6.4-4.fc10-root-mockbuild/usr/lib/libitl.so.0.0.6 >> *** ERROR: No build ID note found in >> /var/tmp/libitl-0.6.4-4.fc10-root-mockbuild/usr/lib/libitl.so.0.0.6 >> >> What should I do to resolve that?. FTBFS bug 449622 . This package >> previously builds fine on F9. > > Your package are calling ld directly. > http://www.redhat.com/archives/fedora-maintainers/2007-August/msg00135.html > > This patch seems to work. > ---------------------------------------------------------------------------- > --- libitl-0.6.4/Makefile.ld 2008-06-09 16:05:30.000000000 +0900 > +++ libitl-0.6.4/Makefile 2008-06-09 16:06:23.000000000 +0900 > @@ -23,7 +23,7 @@ > @false > > build/libitl.so: components > - $(LD) build/*.o $(LDFLAGS) -shared -lm -lc -soname=$(SONAME) -o > build/$(FULLNAME) > + $(CC) build/*.o $(LDFLAGS) -shared -lm -lc -Wl,-soname,$(SONAME) -o > build/$(FULLNAME) > (cd build/ && ln -sf $(FULLNAME) $(SONAME)) > (cd build/ && ln -sf $(FULLNAME) libitl.so) > > ---------------------------------------------------------------------------- > > Regards, > Mamoru > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? http://fedoraproject.org/wiki/MohdIzharFirdaus http://blog.kagesenshi.org 92C2 B295 B40B B3DC 6866 5011 5BD2 584A 8A5D 7331 From j.w.r.degoede at hhs.nl Thu Jun 12 19:54:37 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 12 Jun 2008 21:54:37 +0200 Subject: [Fedora-packaging] Unifying Fedora and openSuse packaging guidelines, rpmmacros and scriplets Message-ID: <48517EFD.5080902@hhs.nl> Hi, As a result fo some discussion on the fdo distributions list, I've been having some very interesting discussions with people from Suse, currently one of them (Stanislav Brabec) is preparing a wiki document describing the differences, and shared problems we have like gtk-update-icon-cache, etc. We would really like to continue our discussions in the open and Stanislav had discussed this with the rpm.org people, and as they are interested in large parts of this discussion they have suggesting to join rpm-maint at lists.rpm.org. This is not a high traffic list (about 50 mails/month), and most people there would be interested in the discussion anyway. So I would like to invite anyone interested to subscribe to rpm-maint at lists.rpm.org Stanislav will send a mail there to start the discussion when he has some wiki pages which describe the current differences and shared problems. Thanks & Regards, Hans From jnovy at redhat.com Thu Jun 12 20:04:46 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 12 Jun 2008 22:04:46 +0200 Subject: [Fedora-packaging] Unifying Fedora and openSuse packaging guidelines, rpmmacros and scriplets In-Reply-To: <48517EFD.5080902@hhs.nl> References: <48517EFD.5080902@hhs.nl> Message-ID: <20080612200446.GA11774@dhcp-lab-186.brq.redhat.com> On Thu, Jun 12, 2008 at 09:54:37PM +0200, Hans de Goede wrote: > Hi, > > As a result fo some discussion on the fdo distributions list, I've been > having some very interesting discussions with people from Suse, currently > one of them (Stanislav Brabec) is preparing a wiki document describing > the differences, and shared problems we have like gtk-update-icon-cache, > etc. The problems page is located at: http://wiki.rpm.org/Problems Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From j.w.r.degoede at hhs.nl Thu Jun 12 20:22:30 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 12 Jun 2008 22:22:30 +0200 Subject: [Fedora-packaging] Unifying Fedora and openSuse packaging guidelines, rpmmacros and scriplets In-Reply-To: <20080612200446.GA11774@dhcp-lab-186.brq.redhat.com> References: <48517EFD.5080902@hhs.nl> <20080612200446.GA11774@dhcp-lab-186.brq.redhat.com> Message-ID: <48518586.4070704@hhs.nl> Jindrich Novy wrote: > On Thu, Jun 12, 2008 at 09:54:37PM +0200, Hans de Goede wrote: >> Hi, >> >> As a result fo some discussion on the fdo distributions list, I've been >> having some very interesting discussions with people from Suse, currently >> one of them (Stanislav Brabec) is preparing a wiki document describing >> the differences, and shared problems we have like gtk-update-icon-cache, >> etc. > > The problems page is located at: > > http://wiki.rpm.org/Problems > Woa, Stanislav has been making nice progress on this already! And people, please send any comments on this to rpm-maint at rpm.org Regards, Hans From artem.rusanov at gmail.com Fri Jun 13 00:08:51 2008 From: artem.rusanov at gmail.com (artem rus) Date: Fri, 13 Jun 2008 04:08:51 +0400 Subject: [Fedora-packaging] New name for dhcp-3.0.5-42.fc7.src.rpm Message-ID: <232135720806121708j3b574b0dtf675341b2106c980@mail.gmail.com> Hi ! I slightly change dhcp-3.0.5-42.fc7.src.rpm and generate from it dhcp and related binary packages. I want what my packages was installed in system insted of original, but I don't know what names give to my new packages. Now i just change subversion from 42 to 99, but i am afraid, what my packages will be overwriten in future updates. I can change name to dhcp-custom... for example, but this can broke dependency. So, I have question. How I can safely install my own package what overrides system package ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Fri Jun 13 00:38:09 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 12 Jun 2008 19:38:09 -0500 Subject: [Fedora-packaging] New name for dhcp-3.0.5-42.fc7.src.rpm In-Reply-To: <232135720806121708j3b574b0dtf675341b2106c980@mail.gmail.com> References: <232135720806121708j3b574b0dtf675341b2106c980@mail.gmail.com> Message-ID: When I need to do this I either configure yum to not update the package, or build my custom package with an epoch. Of course, you should also arrange to watch the commits made to the package so that you know when you need to update your custom package to match. And of course if you use epoch you will break things like upgrades to new Fedora releases, but you have to be prepared to handle that kind of thing anyway. If you want to actually rename the package yet still have the dependencies work, just have your package Provides: the old package name. - J< From tibbs at math.uh.edu Sat Jun 14 15:54:55 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Jun 2008 10:54:55 -0500 Subject: [Fedora-packaging] Haskell packages Message-ID: Someone has bombed the package review queue with a bunch of GHC (Haskell) packages. Actually, they're not really actual packages, just spec files and patches that he wants us to assemble. Hopefully we can get that worked out, but the larger issue of Haskell packaging remains. I recalled that we briefly considered Haskell packaging after the last fudcon, but nothing came of it. Should we block Haskell packages like we blocked Java (and various language packages before it)? Do we have anyone that's still interested in developing Haskell guidelines? I have essentially no knowledge of Haskell, so it should be obvious that I'm not the best person to do this. However, all of the submissions were generated mechanically so I suspect that at least a portion of them could just be reviewed mechanically. I made a few comments to one of the tickets, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=451413, and hopefully the submissions will get cleaned up into a reviewable state. But we still need to cecide whether or not we want to block them until guidelines are ready. - J< From tibbs at math.uh.edu Sat Jun 14 22:42:35 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Jun 2008 17:42:35 -0500 Subject: [Fedora-packaging] TeX package naming Message-ID: Way back in October FPC voted on naming TeX-related packages "tex-foo" as opposed to the old "tetex-foo" or, in recent distros, "texlive-foo". http://fedoraproject.org/wiki/Packaging/Minutes20071002 It doesn't seem that this was ever implemented; there's no specific "TeX" section http://fedoraproject.org/wiki/Packaging/NamingGuidelines and indeed "tetex-" is specifically mentioned in the "Addon Packages (General)" section. I'd just edit this in but that document has a block at the top with a version string and I've never quite understood the protocol for updating it. - J< From rjones at redhat.com Sat Jun 14 22:49:47 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 14 Jun 2008 23:49:47 +0100 Subject: [Fedora-packaging] Haskell packages In-Reply-To: References: Message-ID: <20080614224926.GA21426@amd.home.annexia.org> I would certainly be willing to review Haskell packages, but I don't know enough to write guidelines (the last time I used GHC was so long ago, you had to download the C intermediate files for the compiler and go through an elaborate bootstrapping procedure). I had a look at the bug you pointed to and as you say the packages aren't in a reviewable state at the moment. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From tcallawa at redhat.com Sun Jun 15 01:18:26 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 14 Jun 2008 21:18:26 -0400 Subject: [Fedora-packaging] TeX package naming In-Reply-To: References: Message-ID: <1213492706.3302.45.camel@localhost.localdomain> On Sat, 2008-06-14 at 17:42 -0500, Jason L Tibbitts III wrote: > I'd just edit this in but that document has a block at the top with a > version string and I've never quite understood the protocol for > updating it. Increment version when you make a change. Or not. It doesn't really matter, honestly. At one point in the long-long-ago, I thought perhaps the guidelines might make their way into printed books, so I wanted to have a revision on them. ~spot From rc040203 at freenet.de Sun Jun 15 16:16:20 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 15 Jun 2008 18:16:20 +0200 Subject: [Fedora-packaging] Missing FPC meeting Message-ID: <1213546580.4413.110.camel@beck.corsepiu.local> Hi, I am on vacation next week and will likely not have access to "the net" at all. Thus, I will also likely not be able to attend next week's FPC meeting. Ralf From tcallawa at redhat.com Sun Jun 15 18:12:48 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 15 Jun 2008 14:12:48 -0400 Subject: [Fedora-packaging] Missing FPC meeting In-Reply-To: <1213546580.4413.110.camel@beck.corsepiu.local> References: <1213546580.4413.110.camel@beck.corsepiu.local> Message-ID: <1213553568.3302.60.camel@localhost.localdomain> On Sun, 2008-06-15 at 18:16 +0200, Ralf Corsepius wrote: > Hi, > > I am on vacation next week and will likely not have access to "the net" > at all. Thus, I will also likely not be able to attend next week's FPC > meeting. I will also not be in attendance for the regular Tuesday meeting, but I will be at FUDCon on Thursday and Friday. ~spot From tibbs at math.uh.edu Sun Jun 15 19:22:58 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Jun 2008 14:22:58 -0500 Subject: [Fedora-packaging] Missing FPC meeting In-Reply-To: <1213553568.3302.60.camel@localhost.localdomain> References: <1213546580.4413.110.camel@beck.corsepiu.local> <1213553568.3302.60.camel@localhost.localdomain> Message-ID: Perhaps we should consider postponing the meeting a week, or simply skipping it to pick things up two weeks hence. I'm not sure we have anything on the schedule for this week anyway. - J< From petersen at redhat.com Mon Jun 16 00:15:17 2008 From: petersen at redhat.com (Jens Petersen) Date: Mon, 16 Jun 2008 10:15:17 +1000 Subject: [Fedora-packaging] Haskell packages In-Reply-To: <20080614224926.GA21426@amd.home.annexia.org> References: <20080614224926.GA21426@amd.home.annexia.org> Message-ID: <4855B095.6010306@redhat.com> Richard W.M. Jones ????????: > I would certainly be willing to review Haskell packages, but I don't > know enough to write guidelines (the last time I used GHC was so long > ago, you had to download the C intermediate files for the compiler and > go through an elaborate bootstrapping procedure). I had a look at the > bug you pointed to and as you say the packages aren't in a reviewable > state at the moment. Thanks for the follow up. I think this can be discussed on the Fedora Haskell SIG. Yes we still haven't gotten to cleaning up the draft packaging guidelines, but this could help to prod that process along... :) Jens From juanucleus at gmail.com Mon Jun 16 01:27:20 2008 From: juanucleus at gmail.com (Juan Carlos Cornejo) Date: Sun, 15 Jun 2008 21:27:20 -0400 Subject: [Fedora-packaging] New package help Message-ID: <67102fce0806151827k5710c9efkcd4b40de75a33ce3@mail.gmail.com> Hello all, I am preparing a package that I will submit for review, and hopefully later, for inclusion in Fedora. However, I have run into some issues which I cannot seem to resolve myself. I write to the list, hoping that some of you may be able to help me resolve the issues. First, let me tell you a little bit about the program, as its important to the issues on hand. The program is called ROOT, it is a whole analysis framework developed by CERN that is currently in use in most high energy to medium energy physics laboratories, and released under the LGPv2+. However, it is written general enough that it can be applied to other fields that require a complex analysis framework. Additionally, ROOT makes use of an internal C/C++ Interpreter, which allows for on the fly scripting of C/C++ code. So essentially, ROOT is both an analysis package, and a development package, which really leads into the next problems. 1) the C/C++ interpreter called CINT, produces, as output, DLL files. I don't know why, but this is their solution to dynamic libraries that will be shared across all supported OS's. They support Linux and many Unices, as well as Mac OS X and Windows. These DLL files are compiled by the code, so we have the source code available, though rpmlint seems to give a warning about them. And essentially, I don't know what to make of it. Here is a sample error: root-devel.x86_64: W: unstripped-binary-or-object /usr/lib64/root/cint/include/stdcxxfunc.dll 2) Because rpmlint used to complain about header files being in a non devel package, I moved all header files to the devel package. But the devel _MUST_ be installed along with the main package, CINT requires them to be there. So if I don't create a devel package, I get hundreds of warnings for the header files. If I do create a devel package, and require this devel package from the core files, I get an error out of rpmlint. 3) This one is not really an I issue I guess, but I figured I might as well mention it now. ROOT ships with MS TrueType fonts, for some reason. So I just removed them from the package, as I have not had any problems without them on Fedora. And I use root extensively. Also, I've removed some windows DLL's that were included in the package. Also not needed for a Fedora release. I am hoping that this will not be a problem, having a tar archive that is slightly different than the upstream one. Thank you all for your advanced help. I really hope this program can be made fit to include in the distribution. --Juan Carlos Cornejo -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Mon Jun 16 09:21:38 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 16 Jun 2008 11:21:38 +0200 Subject: [Fedora-packaging] New package help In-Reply-To: <67102fce0806151827k5710c9efkcd4b40de75a33ce3@mail.gmail.com> References: <67102fce0806151827k5710c9efkcd4b40de75a33ce3@mail.gmail.com> Message-ID: <20080616092138.GA3646@free.fr> On Sun, Jun 15, 2008 at 09:27:20PM -0400, Juan Carlos Cornejo wrote: > Hello all, > > The program is called ROOT, it is a whole analysis framework developed by > CERN that is currently in use in most high energy to medium energy physics > laboratories, and released under the LGPv2+. However, it is written general It would indeed be very nice to have ROOT in fedora. I'd be happy to review it. > enough that it can be applied to other fields that require a complex > analysis framework. Additionally, ROOT makes use of an internal C/C++ > Interpreter, which allows for on the fly scripting of C/C++ code. I guess it is similar with comis from the cernlib? Though there doesn't seems to be a corresponding interpreter in the cernlib it seems to do the same. > 1) the C/C++ interpreter called CINT, produces, as output, DLL files. I > don't know why, but this is their solution to dynamic libraries that will be > shared across all supported OS's. The dynamic libraries cannot be shared accross different OS? They have to be recompiled? In any case it is a bit strange for an interpreter to produce long lived output. Is a cmopiler used while interpreting, that would defeat the interpretation? > They support Linux and many Unices, as > well as Mac OS X and Windows. These DLL files are compiled by the code, so > we have the source code available, though rpmlint seems to give a warning > about them. And essentially, I don't know what to make of it. > > Here is a sample error: root-devel.x86_64: W: unstripped-binary-or-object > /usr/lib64/root/cint/include/stdcxxfunc.dll dll on linux are in general called along stdcxxfunc.so. I guess that the script that does the stripping and collect the debugging informations don't know about objects ending in .dll. Also the objects should be executables. In that case, you'll have to either have cint do .so files or tweak the debuginfo generating script such that it also find files ending in .dll. > 2) Because rpmlint used to complain about header files being in a non devel > package, I moved all header files to the devel package. But the devel > _MUST_ be installed along with the main package, CINT requires them to be > there. So if I don't create a devel package, I get hundreds of warnings for > the header files. If I do create a devel package, and require this devel > package from the core files, I get an error out of rpmlint. Is cint really needed for root to work? This seems wrong to me. Anyway, there are some exceptions for cases like this one. In that case you have to end up ignoring some rpmlint errors. I don't think it is possible to have guidelines about these cases since they are all different. Sometime it is better to have the headers in a non-devel package, sometime it is better to have a non devel package depend on a devel package and there are certainly onter cases. There were some discussions about thosdee issues in the past, but there seems to be nothing in the guidelines reflecting it. In the http://fedoraproject.org/wiki/Packaging/ReviewGuidelines it is a MUST to have header files in devel packages, for example. > 3) This one is not really an I issue I guess, but I figured I might as well > mention it now. ROOT ships with MS TrueType fonts, for some reason. So I > just removed them from the package, as I have not had any problems without > them on Fedora. And I use root extensively. Also, I've removed some > windows DLL's that were included in the package. Also not needed for a > Fedora release. I am hoping that this will not be a problem, having a tar > archive that is slightly different than the upstream one. It is covered in https://fedoraproject.org/wiki/Packaging/SourceURL#When_Upstream_uses_Prohibited_Code > Thank you all for your advanced help. I really hope this program can be > made fit to include in the distribution. I hope too. I think that the best would be that you begin a submission, even with somthing you know isn't ready for acceptation, such that the issues can be tracked in bugzilla, and that we can see the actual code. -- Pat From tibbs at math.uh.edu Mon Jun 16 14:18:55 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jun 2008 09:18:55 -0500 Subject: [Fedora-packaging] New package help In-Reply-To: <20080616092138.GA3646@free.fr> References: <67102fce0806151827k5710c9efkcd4b40de75a33ce3@mail.gmail.com> <20080616092138.GA3646@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> It would indeed be very nice to have ROOT in fedora. I'd be happy PD> to review it. It should be noted that "root" is a rather ambiguous package name; I hope that there's some reasonable name that can be used. - J< From skvidal at fedoraproject.org Mon Jun 16 15:41:45 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 16 Jun 2008 11:41:45 -0400 (EDT) Subject: [Fedora-packaging] New package help Message-ID: On Mon, 16 Jun 2008, Jason L Tibbitts III wrote: >>>>>> "PD" == Patrice Dumas writes: > > PD> It would indeed be very nice to have ROOT in fedora. I'd be happy > PD> to review it. > > It should be noted that "root" is a rather ambiguous package name; I > hope that there's some reasonable name that can be used. You'd think that, alas, this is not to be so. :( I had to deal with root for years. It likes to run a daemon named 'rootd'. There's nothing that makes a sysadmin cringe up like a process named 'rootd' -sv From tibbs at math.uh.edu Mon Jun 16 16:19:20 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jun 2008 11:19:20 -0500 Subject: [Fedora-packaging] New package help In-Reply-To: References: Message-ID: >>>>> "SV" == Seth Vidal writes: SV> You'd think that, alas, this is not to be so. :( Well, we can at least choose a reasonable name for the Fedora package; renaming the daemons and executables is probably a bit much to ask, unless they conflict with those from other packages. SV> I had to deal with root for years. It likes to run a daemon named SV> 'rootd'. There's nothing that makes a sysadmin cringe up like a SV> process named 'rootd' I can only imagine what happens when a user says "I need root on my machine". - J< From a.badger at gmail.com Mon Jun 16 18:30:45 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 16 Jun 2008 14:30:45 -0400 Subject: [Fedora-packaging] Python Virtual Provides Message-ID: <4856B155.7030608@gmail.com> I've added Python Virtual Provides to the list of draft guidelines. https://fedoraproject.org/wiki/PackagingDrafts/Python There are two parts: 1) introduce virtual provides for python eggs. Copying from the way we do rubygems, this would be: Provides: pythonegg(SQLAlchemy) = %{version} Requires: pythonegg(SQLAlchemy) >= 0.3.11 2) introduce virtualprovides for normal python modules: Provides: python(sqlalchemy) = %{version} Requires: python(sqlalchemy) The motivation for this is that David Malcolm (dmalcolm) wrote a proof of concept script to show how easy it would be to extract egg dependency information as part of the rpm build process. Since this will be a far reaching change, should it be discussed on fedora-devel-list first or whether we want to do both parts? -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 katzj at redhat.com Mon Jun 16 18:38:28 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 16 Jun 2008 14:38:28 -0400 Subject: [Fedora-packaging] Python Virtual Provides In-Reply-To: <4856B155.7030608@gmail.com> References: <4856B155.7030608@gmail.com> Message-ID: <1213641508.12817.24.camel@aglarond.local> On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote: > I've added Python Virtual Provides to the list of draft guidelines. > https://fedoraproject.org/wiki/PackagingDrafts/Python [snip] > The motivation for this is that David Malcolm (dmalcolm) wrote a proof > of concept script to show how easy it would be to extract egg dependency > information as part of the rpm build process. To help maintain the sanity of everyone building packages, can't we just auto-generate these? I know there's the old patch floating around somewhere for python deps that we should be using but haven't yet instituted. And extending that to work with eggs also seems to make sense. And then we avoid everyone having to add stuff to their spec files Jeremy From dmalcolm at redhat.com Mon Jun 16 19:56:33 2008 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 16 Jun 2008 15:56:33 -0400 Subject: [Fedora-packaging] Re: Python Virtual Provides In-Reply-To: <4856B155.7030608@gmail.com> References: <4856B155.7030608@gmail.com> Message-ID: <1213646193.13902.13.camel@radiator.bos.redhat.com> On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote: > I've added Python Virtual Provides to the list of draft guidelines. > > https://fedoraproject.org/wiki/PackagingDrafts/Python > > There are two parts: > 1) introduce virtual provides for python eggs. Copying from the way we > do rubygems, this would be: > > Provides: pythonegg(SQLAlchemy) = %{version} > Requires: pythonegg(SQLAlchemy) >= 0.3.11 > > 2) introduce virtualprovides for normal python modules: > > Provides: python(sqlalchemy) = %{version} > Requires: python(sqlalchemy) > > The motivation for this is that David Malcolm (dmalcolm) wrote a proof > of concept script to show how easy it would be to extract egg dependency > information as part of the rpm build process. I ran into various inconsistencies between the versions listed in the egg requires.txt file and the rpm specfile, and thought that the latter ought to be autogenerated from the former. First pass at a script attached to bug 451228, and I posted this to fedora-python-devel-list: https://www.redhat.com/archives/fedora-python-devel-list/2008-June/msg00002.html Obvious mistake I made was to try to store the mapping from python modules to package names, instead, the script ought to generate some kind of virtual provides as in Toshio's suggestion above. Should be simple to update the script > > Since this will be a far reaching change, should it be discussed on > fedora-devel-list first or whether we want to do both parts? > Could we simply put the script in a place where it's available to the maintainer, so they can opt-in and have it generate the deps? Hope this helps Dave From dmalcolm at redhat.com Mon Jun 16 20:31:49 2008 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 16 Jun 2008 16:31:49 -0400 Subject: [Fedora-packaging] Re: Python Virtual Provides In-Reply-To: <1213646193.13902.13.camel@radiator.bos.redhat.com> References: <4856B155.7030608@gmail.com> <1213646193.13902.13.camel@radiator.bos.redhat.com> Message-ID: <1213648309.13902.16.camel@radiator.bos.redhat.com> On Mon, 2008-06-16 at 15:56 -0400, David Malcolm wrote: > On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote: > > I've added Python Virtual Provides to the list of draft guidelines. > > > > https://fedoraproject.org/wiki/PackagingDrafts/Python > > > > There are two parts: > > 1) introduce virtual provides for python eggs. Copying from the way we > > do rubygems, this would be: > > > > Provides: pythonegg(SQLAlchemy) = %{version} > > Requires: pythonegg(SQLAlchemy) >= 0.3.11 > > > > 2) introduce virtualprovides for normal python modules: > > > > Provides: python(sqlalchemy) = %{version} > > Requires: python(sqlalchemy) > > > > The motivation for this is that David Malcolm (dmalcolm) wrote a proof > > of concept script to show how easy it would be to extract egg dependency > > information as part of the rpm build process. > > I ran into various inconsistencies between the versions listed in the > egg requires.txt file and the rpm specfile, and thought that the latter > ought to be autogenerated from the former. > > First pass at a script attached to bug 451228, and I posted this to > fedora-python-devel-list: > https://www.redhat.com/archives/fedora-python-devel-list/2008-June/msg00002.html > > Obvious mistake I made was to try to store the mapping from python > modules to package names, instead, the script ought to generate some > kind of virtual provides as in Toshio's suggestion above. Should be > simple to update the script Implemented, attached to bug 451228. This generates the following for the TurboGears egg (telling it to use the optional SQLAlchemy stuff): # Autogenerated metadata from "requires.py /usr/lib/python2.4/site-packages/TurboGears-1.0.4.4-py2.4.egg-info SQLAlchemy" Provides: pythonegg(TurboGears) = 1.0.4.4 Requires: pythonegg(CherryPy) >= 2.3.0 Requires: pythonegg(CherryPy) < 3.0.0alpha Requires: pythonegg(DecoratorTools) >= 1.4 Requires: pythonegg(FormEncode) >= 0.7.1 Requires: pythonegg(PasteScript) >= 1.6.2 Requires: pythonegg(RuleDispatch) >= 0.5a0.dev-r2303 Requires: pythonegg(setuptools) >= 0.6c2 Requires: pythonegg(simplejson) >= 1.3 Requires: pythonegg(TurboCheetah) >= 1.0 Requires: pythonegg(TurboJson) >= 1.1.2 Requires: pythonegg(TurboKid) >= 1.0.4 Requires: pythonegg(SQLAlchemy) >= 0.3.10 Is the dash in the RuleDispatch version likely to cause problems? > > > > > Since this will be a far reaching change, should it be discussed on > > fedora-devel-list first or whether we want to do both parts? > > > > Could we simply put the script in a place where it's available to the > maintainer, so they can opt-in and have it generate the deps? > > > Hope this helps > Dave > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From tibbs at math.uh.edu Mon Jun 16 20:41:41 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jun 2008 15:41:41 -0500 Subject: [Fedora-packaging] Re: Python Virtual Provides In-Reply-To: <1213648309.13902.16.camel@radiator.bos.redhat.com> References: <4856B155.7030608@gmail.com> <1213646193.13902.13.camel@radiator.bos.redhat.com> <1213648309.13902.16.camel@radiator.bos.redhat.com> Message-ID: >>>>> "DM" == David Malcolm writes: DM> Requires: pythonegg(RuleDispatch) >= 0.5a0.dev-r2303 DM> Is the dash in the RuleDispatch version likely to cause problems? Not so much the dash as the fact that there is a huge chance that with such incredibly poor versioning practices we're likely to see things fail to sort properly in the future, leading to versions which go backwards rpm-wise. - J< From a.badger at gmail.com Mon Jun 16 20:39:47 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 16 Jun 2008 16:39:47 -0400 Subject: [Fedora-packaging] Python Virtual Provides In-Reply-To: <1213641508.12817.24.camel@aglarond.local> References: <4856B155.7030608@gmail.com> <1213641508.12817.24.camel@aglarond.local> Message-ID: <4856CF93.2020200@gmail.com> Jeremy Katz wrote: > On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote: >> I've added Python Virtual Provides to the list of draft guidelines. >> https://fedoraproject.org/wiki/PackagingDrafts/Python > [snip] >> The motivation for this is that David Malcolm (dmalcolm) wrote a proof >> of concept script to show how easy it would be to extract egg dependency >> information as part of the rpm build process. > > To help maintain the sanity of everyone building packages, can't we just > auto-generate these? I know there's the old patch floating around > somewhere for python deps that we should be using but haven't yet > instituted. And extending that to work with eggs also seems to make > sense. And then we avoid everyone having to add stuff to their spec > files > Err, that's why I said the motivation for this was that Dave Malcolm wrote a script to do that for eggs :-) -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 Jun 16 21:11:21 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 16 Jun 2008 17:11:21 -0400 Subject: [Fedora-packaging] Re: Python Virtual Provides In-Reply-To: References: <4856B155.7030608@gmail.com> <1213646193.13902.13.camel@radiator.bos.redhat.com> <1213648309.13902.16.camel@radiator.bos.redhat.com> Message-ID: <4856D6F9.6030001@gmail.com> Jason L Tibbitts III wrote: >>>>>> "DM" == David Malcolm writes: > > DM> Requires: pythonegg(RuleDispatch) >= 0.5a0.dev-r2303 > > DM> Is the dash in the RuleDispatch version likely to cause problems? > > Not so much the dash as the fact that there is a huge chance that with > such incredibly poor versioning practices we're likely to see things > fail to sort properly in the future, leading to versions which go > backwards rpm-wise. > Well, the package will already have that problem. This is the prettiest I could make cleaning up the version:: %define nonnumeric_relstring a0.dev-r2303 Name: python-ruledispatch Version: 0.5 Release: 0.1.%{nonnumeric_relstring} Provides: pythonegg(RuleDispatch) = %{version}%{nonnumeric_relstring} Since the script Dave provided makes constructs the Provides line for us, using the script with these kinds of versions doesn't really make our lives harder. -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 jkeating at j2solutions.net Mon Jun 16 20:39:21 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 16 Jun 2008 16:39:21 -0400 Subject: [Fedora-packaging] Re: Python Virtual Provides In-Reply-To: <1213648309.13902.16.camel@radiator.bos.redhat.com> References: <4856B155.7030608@gmail.com> <1213646193.13902.13.camel@radiator.bos.redhat.com> <1213648309.13902.16.camel@radiator.bos.redhat.com> Message-ID: <9339c38c0806161339j153dea6evb89d05d146d29f0e@mail.gmail.com> On Mon, Jun 16, 2008 at 4:31 PM, David Malcolm wrote: > On Mon, 2008-06-16 at 15:56 -0400, David Malcolm wrote: > > On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote: > > > I've added Python Virtual Provides to the list of draft guidelines. > > > > > > https://fedoraproject.org/wiki/PackagingDrafts/Python > > > > > > There are two parts: > > > 1) introduce virtual provides for python eggs. Copying from the way we > > > do rubygems, this would be: > > > > > > Provides: pythonegg(SQLAlchemy) = %{version} > > > Requires: pythonegg(SQLAlchemy) >= 0.3.11 > > > > > > 2) introduce virtualprovides for normal python modules: > > > > > > Provides: python(sqlalchemy) = %{version} > > > Requires: python(sqlalchemy) > > > > > > The motivation for this is that David Malcolm (dmalcolm) wrote a proof > > > of concept script to show how easy it would be to extract egg > dependency > > > information as part of the rpm build process. > > > > I ran into various inconsistencies between the versions listed in the > > egg requires.txt file and the rpm specfile, and thought that the latter > > ought to be autogenerated from the former. > > > > First pass at a script attached to bug 451228, and I posted this to > > fedora-python-devel-list: > > > https://www.redhat.com/archives/fedora-python-devel-list/2008-June/msg00002.html > > > > Obvious mistake I made was to try to store the mapping from python > > modules to package names, instead, the script ought to generate some > > kind of virtual provides as in Toshio's suggestion above. Should be > > simple to update the script > > Implemented, attached to bug 451228. This generates the following for > the TurboGears egg (telling it to use the optional SQLAlchemy stuff): > > # Autogenerated metadata from "requires.py > /usr/lib/python2.4/site-packages/TurboGears-1.0.4.4-py2.4.egg-info > SQLAlchemy" > Provides: pythonegg(TurboGears) = 1.0.4.4 > Requires: pythonegg(CherryPy) >= 2.3.0 > Requires: pythonegg(CherryPy) < 3.0.0alpha > Requires: pythonegg(DecoratorTools) >= 1.4 > Requires: pythonegg(FormEncode) >= 0.7.1 > Requires: pythonegg(PasteScript) >= 1.6.2 > Requires: pythonegg(RuleDispatch) >= 0.5a0.dev-r2303 > Requires: pythonegg(setuptools) >= 0.6c2 > Requires: pythonegg(simplejson) >= 1.3 > Requires: pythonegg(TurboCheetah) >= 1.0 > Requires: pythonegg(TurboJson) >= 1.1.2 > Requires: pythonegg(TurboKid) >= 1.0.4 > Requires: pythonegg(SQLAlchemy) >= 0.3.10 > > Is the dash in the RuleDispatch version likely to cause problems? > It shouldn't, provided the package which this lives in has a matching provides. -- Jes -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Mon Jun 16 22:27:47 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Jun 2008 17:27:47 -0500 Subject: [Fedora-packaging] Re: Python Virtual Provides In-Reply-To: <4856D6F9.6030001@gmail.com> References: <4856B155.7030608@gmail.com> <1213646193.13902.13.camel@radiator.bos.redhat.com> <1213648309.13902.16.camel@radiator.bos.redhat.com> <4856D6F9.6030001@gmail.com> Message-ID: >>>>> "TK" == Toshio Kuratomi writes: TK> Well, the package will already have that problem. Perhaps, but then a human is involved to do things like rationalize the version or bump epoch when required. If a script is pulling this info out of the egg file then it won't have the benefit of such oversight. I guess I'm assuming that this works like it does for Perl, where the packager needs to specify build dependencies but essentially doesn't have to specify any kind of runtime dependency. - J< From katzj at redhat.com Mon Jun 16 22:37:12 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 16 Jun 2008 18:37:12 -0400 Subject: [Fedora-packaging] Python Virtual Provides In-Reply-To: <4856CF93.2020200@gmail.com> References: <4856B155.7030608@gmail.com> <1213641508.12817.24.camel@aglarond.local> <4856CF93.2020200@gmail.com> Message-ID: <1213655832.12817.30.camel@aglarond.local> On Mon, 2008-06-16 at 16:39 -0400, Toshio Kuratomi wrote: > Jeremy Katz wrote: > > On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote: > >> I've added Python Virtual Provides to the list of draft guidelines. > >> https://fedoraproject.org/wiki/PackagingDrafts/Python > > [snip] > >> The motivation for this is that David Malcolm (dmalcolm) wrote a proof > >> of concept script to show how easy it would be to extract egg dependency > >> information as part of the rpm build process. > > > > To help maintain the sanity of everyone building packages, can't we just > > auto-generate these? I know there's the old patch floating around > > somewhere for python deps that we should be using but haven't yet > > instituted. And extending that to work with eggs also seems to make > > sense. And then we avoid everyone having to add stuff to their spec > > files > > > Err, that's why I said the motivation for this was that Dave Malcolm > wrote a script to do that for eggs :-) If it's being done automatically, it's not really packaging policy -- it's just part of things working :) Jeremy From opensource at till.name Mon Jun 16 22:47:03 2008 From: opensource at till.name (Till Maas) Date: Tue, 17 Jun 2008 00:47:03 +0200 Subject: [Fedora-packaging] running testsuites of packages Message-ID: <200806170047.04251.opensource@till.name> Hiyas, I noticed that there are sometines indications that reviewers expect to run testsuites of packages (maybe in %check?) and not running them may be a review blocker, for example: https://bugzilla.redhat.com/show_bug.cgi?id=435835#c6 Can you maybe add this to the Guidelines queue? https://fedoraproject.org/wiki/Packaging/GuidelinesTodo I will probably write something once I find the time and know what to write. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From a.badger at gmail.com Mon Jun 16 23:20:22 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 16 Jun 2008 19:20:22 -0400 Subject: [Fedora-packaging] Python Virtual Provides In-Reply-To: <1213655832.12817.30.camel@aglarond.local> References: <4856B155.7030608@gmail.com> <1213641508.12817.24.camel@aglarond.local> <4856CF93.2020200@gmail.com> <1213655832.12817.30.camel@aglarond.local> Message-ID: <4856F536.8010508@gmail.com> Jeremy Katz wrote: > On Mon, 2008-06-16 at 16:39 -0400, Toshio Kuratomi wrote: >> Jeremy Katz wrote: >>> On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote: >>>> I've added Python Virtual Provides to the list of draft guidelines. >>>> https://fedoraproject.org/wiki/PackagingDrafts/Python >>> [snip] >>>> The motivation for this is that David Malcolm (dmalcolm) wrote a proof >>>> of concept script to show how easy it would be to extract egg dependency >>>> information as part of the rpm build process. >>> To help maintain the sanity of everyone building packages, can't we just >>> auto-generate these? I know there's the old patch floating around >>> somewhere for python deps that we should be using but haven't yet >>> instituted. And extending that to work with eggs also seems to make >>> sense. And then we avoid everyone having to add stuff to their spec >>> files >>> >> Err, that's why I said the motivation for this was that Dave Malcolm >> wrote a script to do that for eggs :-) > > If it's being done automatically, it's not really packaging policy -- > it's just part of things working :) > The packaging policy portion is: * Are Virtual Provides the way to go (I say yes and so far no one's shot me down :-) * What should the virtual provides be named? * Should we do the part where we can only manage to pull Provides out automatically but not Requires? * Should we try harder to make subpackages listed? -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 katzj at redhat.com Tue Jun 17 00:50:53 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 16 Jun 2008 20:50:53 -0400 Subject: [Fedora-packaging] Python Virtual Provides In-Reply-To: <4856F536.8010508@gmail.com> References: <4856B155.7030608@gmail.com> <1213641508.12817.24.camel@aglarond.local> <4856CF93.2020200@gmail.com> <1213655832.12817.30.camel@aglarond.local> <4856F536.8010508@gmail.com> Message-ID: <1213663853.12817.34.camel@aglarond.local> On Mon, 2008-06-16 at 19:20 -0400, Toshio Kuratomi wrote: > Jeremy Katz wrote: > > On Mon, 2008-06-16 at 16:39 -0400, Toshio Kuratomi wrote: > >> Jeremy Katz wrote: > >>> On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote: > >>>> I've added Python Virtual Provides to the list of draft guidelines. > >>>> https://fedoraproject.org/wiki/PackagingDrafts/Python > >>> [snip] > >>>> The motivation for this is that David Malcolm (dmalcolm) wrote a proof > >>>> of concept script to show how easy it would be to extract egg dependency > >>>> information as part of the rpm build process. > >>> To help maintain the sanity of everyone building packages, can't we just > >>> auto-generate these? I know there's the old patch floating around > >>> somewhere for python deps that we should be using but haven't yet > >>> instituted. And extending that to work with eggs also seems to make > >>> sense. And then we avoid everyone having to add stuff to their spec > >>> files > >>> > >> Err, that's why I said the motivation for this was that Dave Malcolm > >> wrote a script to do that for eggs :-) > > > > If it's being done automatically, it's not really packaging policy -- > > it's just part of things working :) > > > The packaging policy portion is: > > * Are Virtual Provides the way to go (I say yes and so far no one's shot > me down :-) I don't really know how else you'd do it... > * What should the virtual provides be named? Bikeshed :-) But the proposal matches what we do for everything else > * Should we do the part where we can only manage to pull Provides out > automatically but not Requires? Obviously it'd be nice if we could get Requires done automatically too, but it doesn't hurt to give the provides until then. > * Should we try harder to make subpackages listed? How so? I might be missing something here but I don't see anything that subpackages are especially relevant for? You mean like if a module is split across subpackages? Jeremy From juanucleus at gmail.com Tue Jun 17 02:05:13 2008 From: juanucleus at gmail.com (Juan Carlos Cornejo) Date: Mon, 16 Jun 2008 22:05:13 -0400 Subject: [Fedora-packaging] New package help In-Reply-To: References: Message-ID: <67102fce0806161905w5662e4e6jb9b7912c1d05aa25@mail.gmail.com> Hi all, Sorry for such late response, my laptop just died :'(( and since I'm in a conference, I have limited computer access. As for the name, yes, it was one of my primary concerns. I figured that would have been resolved at the end. I thought about perhaps naming it root-analyzer. At Jefferson Lab, where I'm at, we have our own version just called Analyzer. And it's very common to just think of it as root-analyzer. So that might work as a name. If need be, I guess I'll have to dwell into the code and change the names of the binaries and various daemons. I submitted the spec and source file in for review. Thank you all for your early pre-reviews. --Juan Carlos On Mon, Jun 16, 2008 at 12:19 PM, Jason L Tibbitts III wrote: > >>>>> "SV" == Seth Vidal writes: > > SV> You'd think that, alas, this is not to be so. :( > > Well, we can at least choose a reasonable name for the Fedora package; > renaming the daemons and executables is probably a bit much to ask, > unless they conflict with those from other packages. > > SV> I had to deal with root for years. It likes to run a daemon named > SV> 'rootd'. There's nothing that makes a sysadmin cringe up like a > SV> process named 'rootd' > > I can only imagine what happens when a user says "I need root on my > machine". > > - J< > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Tue Jun 17 10:37:33 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 17 Jun 2008 06:37:33 -0400 Subject: [Fedora-packaging] Python Virtual Provides In-Reply-To: <1213663853.12817.34.camel@aglarond.local> References: <4856B155.7030608@gmail.com> <1213641508.12817.24.camel@aglarond.local> <4856CF93.2020200@gmail.com> <1213655832.12817.30.camel@aglarond.local> <4856F536.8010508@gmail.com> <1213663853.12817.34.camel@aglarond.local> Message-ID: <485793ED.7060003@gmail.com> Jeremy Katz wrote: > On Mon, 2008-06-16 at 19:20 -0400, Toshio Kuratomi wrote: >> Jeremy Katz wrote: >>> On Mon, 2008-06-16 at 16:39 -0400, Toshio Kuratomi wrote: >>>> Jeremy Katz wrote: >>>>> On Mon, 2008-06-16 at 14:30 -0400, Toshio Kuratomi wrote: >>>>>> I've added Python Virtual Provides to the list of draft guidelines. >>>>>> https://fedoraproject.org/wiki/PackagingDrafts/Python >>>>> [snip] >>>>>> The motivation for this is that David Malcolm (dmalcolm) wrote a proof >>>>>> of concept script to show how easy it would be to extract egg dependency >>>>>> information as part of the rpm build process. >>>>> To help maintain the sanity of everyone building packages, can't we just >>>>> auto-generate these? I know there's the old patch floating around >>>>> somewhere for python deps that we should be using but haven't yet >>>>> instituted. And extending that to work with eggs also seems to make >>>>> sense. And then we avoid everyone having to add stuff to their spec >>>>> files >>>>> >>>> Err, that's why I said the motivation for this was that Dave Malcolm >>>> wrote a script to do that for eggs :-) >>> If it's being done automatically, it's not really packaging policy -- >>> it's just part of things working :) >>> >> The packaging policy portion is: >> >> * Are Virtual Provides the way to go (I say yes and so far no one's shot >> me down :-) > > I don't really know how else you'd do it... > >> * What should the virtual provides be named? > > Bikeshed :-) But the proposal matches what we do for everything else > >> * Should we do the part where we can only manage to pull Provides out >> automatically but not Requires? > > Obviously it'd be nice if we could get Requires done automatically too, > but it doesn't hurt to give the provides until then. > >> * Should we try harder to make subpackages listed? > > How so? I might be missing something here but I don't see anything that > subpackages are especially relevant for? You mean like if a module is > split across subpackages? > So, eggs seem pretty straightforward to me. They establish what they provide and what they depend on in their metadata. But the python() namespace is not so easy. On the PackagingDraft/Python page I mention that one thing we could try is to make a Provides: python(foo) for every module in the site-packages directories. This is relatively straightforward to automate but misses subpackages. The example I brought up is bzr-gtk:: bzr has:: %{python_sitearch}/bzrlib And so it Provides: python(bzrlib) bzr-gtk has:: %{python_sitearch}/bzrlib/plugins/gtk And in this scheme it wouldn't have any automated Provides. Other bzr plugins can require that bzr-gtk is installed, though, so they'll have to write their requirements on the package name instead of a virtual provide. Another example that's not so plugin/program based is toscawidgets. It creates the directory: %{python_sitearch}/tw Packages which create widgets that work within tosca can install into subdirectories of that so this heuristic won't find them. -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 j.w.r.degoede at hhs.nl Tue Jun 17 13:20:34 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 17 Jun 2008 15:20:34 +0200 Subject: [Fedora-packaging] Creating a mailinglist for discussions about Fedora and openSUSE package guidelines merging Message-ID: <4857BA22.9030003@hhs.nl> Hi, As you know I've been in contact with some people from openSUSE, talking about merging our package guidelines. This has lead to some discussion about rpm shortcomings which is now being discussed at rpm-maint at rpm.org. But another part of this discussion is merging our guidelines in general, esp. those which are not workaround for the rpm shortcomings. The openSUSE people would like to create a foo at opensuse.org mailinglist hosting this discussion. Are there any objections to such a list being hosted @opensuse.org? Regards, Hans From katzj at redhat.com Tue Jun 17 15:10:35 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 17 Jun 2008 11:10:35 -0400 Subject: [Fedora-packaging] Python Virtual Provides In-Reply-To: <485793ED.7060003@gmail.com> References: <4856B155.7030608@gmail.com> <1213641508.12817.24.camel@aglarond.local> <4856CF93.2020200@gmail.com> <1213655832.12817.30.camel@aglarond.local> <4856F536.8010508@gmail.com> <1213663853.12817.34.camel@aglarond.local> <485793ED.7060003@gmail.com> Message-ID: <1213715435.12817.41.camel@aglarond.local> On Tue, 2008-06-17 at 06:37 -0400, Toshio Kuratomi wrote: > So, eggs seem pretty straightforward to me. They establish what they > provide and what they depend on in their metadata. But the python() > namespace is not so easy. On the PackagingDraft/Python page I mention > that one thing we could try is to make a Provides: python(foo) for every > module in the site-packages directories. This is relatively > straightforward to automate but misses subpackages. The example I > brought up is bzr-gtk:: Aha, okay. I think that the right thing here is to get the first level and then we can later worry about the secondary case of subpackages. I mean, you could do Provides: python(bzrlib.plugins.gtk) or some-such, but I suspect that might get a bit out of hand. And I'm also not sure how common of a case it is to need to care about Jeremy From nicolas.mailhot at laposte.net Tue Jun 17 16:50:42 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 17 Jun 2008 18:50:42 +0200 Subject: [Fedora-packaging] Creating a mailinglist for discussions about Fedora and openSUSE package guidelines merging In-Reply-To: <4857BA22.9030003@hhs.nl> References: <4857BA22.9030003@hhs.nl> Message-ID: <1213721442.3368.1.camel@rousalka.okg> Le mardi 17 juin 2008 ? 15:20 +0200, Hans de Goede a ?crit : > Hi, > > As you know I've been in contact with some people from openSUSE, talking about > merging our package guidelines. > > This has lead to some discussion about rpm shortcomings which is now being > discussed at rpm-maint at rpm.org. But another part of this discussion is merging > our guidelines in general, esp. those which are not workaround for the rpm > shortcomings. > > The openSUSE people would like to create a foo at opensuse.org mailinglist hosting > this discussion. Are there any objections to such a list being hosted > @opensuse.org? Since you're already discussing rpm-related stuff on a rpm.org list, why not create a rpm.org list dedicated to packaging guidelines instead ? -- 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 rdieter at math.unl.edu Tue Jun 17 16:56:27 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 17 Jun 2008 11:56:27 -0500 Subject: [Fedora-packaging] Creating a mailinglist for discussions about Fedora and openSUSE package guidelines merging In-Reply-To: <4857BA22.9030003@hhs.nl> References: <4857BA22.9030003@hhs.nl> Message-ID: <4857ECBB.6040806@math.unl.edu> Hans de Goede wrote: > Hi, > > As you know I've been in contact with some people from openSUSE, talking > about merging our package guidelines. > > This has lead to some discussion about rpm shortcomings which is now > being discussed at rpm-maint at rpm.org. But another part of this > discussion is merging our guidelines in general, esp. those which are > not workaround for the rpm shortcomings. > > The openSUSE people would like to create a foo at opensuse.org mailinglist > hosting this discussion. Are there any objections to such a list being > hosted @opensuse.org? no objection here, doesn't matter where the discussion happens (bikeshed) as long as it does happen. -- Rex From j.w.r.degoede at hhs.nl Tue Jun 17 18:03:27 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 17 Jun 2008 20:03:27 +0200 Subject: [Fedora-packaging] Creating a mailinglist for discussions about Fedora and openSUSE package guidelines merging In-Reply-To: <1213721442.3368.1.camel@rousalka.okg> References: <4857BA22.9030003@hhs.nl> <1213721442.3368.1.camel@rousalka.okg> Message-ID: <4857FC6F.7090100@hhs.nl> Nicolas Mailhot wrote: > Le mardi 17 juin 2008 ? 15:20 +0200, Hans de Goede a ?crit : >> Hi, >> >> As you know I've been in contact with some people from openSUSE, talking about >> merging our package guidelines. >> >> This has lead to some discussion about rpm shortcomings which is now being >> discussed at rpm-maint at rpm.org. But another part of this discussion is merging >> our guidelines in general, esp. those which are not workaround for the rpm >> shortcomings. >> >> The openSUSE people would like to create a foo at opensuse.org mailinglist hosting >> this discussion. Are there any objections to such a list being hosted >> @opensuse.org? > > Since you're already discussing rpm-related stuff on a rpm.org list, why > not create a rpm.org list dedicated to packaging guidelines instead ? > Good point, I got the same response from Stanislav from Suse. Regards, Hans From ghosler at redhat.com Wed Jun 18 05:59:56 2008 From: ghosler at redhat.com (Gregory Hosler) Date: Wed, 18 Jun 2008 13:59:56 +0800 Subject: [Fedora-packaging] How to package EPEL packages Message-ID: <4858A45C.8090008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a Fedora package, and i need to know the guidelines for creating a EPEL package. Any url's or wiki on this ? Thanks, and best rgds, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. ~ (from /var/log/Xorg.setup.log) | Greg Hosler ghosler at redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIWKRZ404fl/0CV/QRAinaAJ0c8Zix97i6mEt/LUot6b5vsW2wfgCfWKsw q+21MkZOJymqGqvnTJl2md8= =9bqC -----END PGP SIGNATURE----- From dan at danny.cz Wed Jun 18 06:18:53 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 18 Jun 2008 08:18:53 +0200 Subject: [Fedora-packaging] How to package EPEL packages In-Reply-To: <4858A45C.8090008@redhat.com> References: <4858A45C.8090008@redhat.com> Message-ID: <1213769933.3487.2.camel@eagle.danny.cz> Gregory Hosler p??e v St 18. 06. 2008 v 13:59 +0800: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I have a Fedora package, and i need to know the guidelines for creating a EPEL > package. > > Any url's or wiki on this ? create EPEL branches http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure main EPEL page http://fedoraproject.org/wiki/EPEL EPEL specific guidelines http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies Dan From orion at cora.nwra.com Wed Jun 18 18:05:39 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 18 Jun 2008 12:05:39 -0600 Subject: [Fedora-packaging] More alternatives fun and games Message-ID: <48594E73.7050408@cora.nwra.com> I just removed the 32-bit emacs package from a 64-bit machine and /usr/bin/emacs went away, presumably because of: preuninstall scriptlet (using /bin/sh): alternatives --remove emacs /usr/bin/emacs-22.1 Is there any standard way we can avoid this? Count the number of emacs packages there will be after removal? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From dominik at greysector.net Wed Jun 18 20:33:28 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 18 Jun 2008 22:33:28 +0200 Subject: [Fedora-packaging] More alternatives fun and games In-Reply-To: <48594E73.7050408@cora.nwra.com> References: <48594E73.7050408@cora.nwra.com> Message-ID: <20080618203327.GA10326@mokona.greysector.net> On Wednesday, 18 June 2008 at 20:05, Orion Poplawski wrote: > I just removed the 32-bit emacs package from a 64-bit machine and > /usr/bin/emacs went away, presumably because of: > > preuninstall scriptlet (using /bin/sh): > alternatives --remove emacs /usr/bin/emacs-22.1 > > Is there any standard way we can avoid this? Count the number of emacs > packages there will be after removal? Hm. Must be a packaging bug, because I have reviewed a (livna) package that uses alternatives and uninstalling the 32bit version didn't make the alternativized link go away. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From philipp_subx at redfish-solutions.com Thu Jun 19 00:00:24 2008 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 18 Jun 2008 17:00:24 -0700 Subject: [Fedora-packaging] Adding mod_proxy_html to httpd package? Message-ID: <4859A198.3000008@redfish-solutions.com> I recently found out that I needed but couldn't find mod_proxy_html.so for my FC7 system running httpd-2.2.8. Mod_proxy_html is GPL'd, so that's not an issue. It looks like it just drops right down into the modules/proxy/ directory and builds (with minor patching of the config.m4 file). I was thinking of tweaking the existing package to build mod_proxy_html as well, but put it into a separate %package. If I do this for fc7, is someone else willing to code review it and hopefully port the changes up to fc10 or rawhide? Thanks, -Philip From shobhit_gupta_it at yahoo.co.in Thu Jun 19 17:52:50 2008 From: shobhit_gupta_it at yahoo.co.in (Shobhit Gupta) Date: Thu, 19 Jun 2008 23:22:50 +0530 (IST) Subject: [Fedora-packaging] Mounting Problem... Message-ID: <671692.43511.qm@web7814.mail.in.yahoo.com> hi all... ?i m new user of LINUX. i m using Fedora9 i dont hve much knowledge abt it but, i wanna learn it mn wrk on it... i gotta a prob after installation i m using LINUX along wid Windows XP & Vista i hve 6 partitions in total c is for win XP 32 bit d is for WIN Vista 32 bit e is for Fedora9 - 64 bit whn i open My Computer in LINUX, i am able to c all the partitions but not able to open any one of? them except the one tht i use for Linux i searched for the solution on net i tried follow commands in the terminal:- ? su - yum install ntfs-3g ? it got installed successfull and i came 2 know abt it whn i retried this command 2-3 times. it showed tht i have already installed this component but still i m not able to use the partitions i really want to ba regular user of fedora as i like it... kindly help me out ... my e-mail address is shobhit_gupta_it at yahoo.co.in please reply me soon and help me out...plz... Bollywood, fun, friendship, sports and more. You name it, we have it on http://in.promos.yahoo.com/groups/bestofyahoo/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From henriquecsj at gmail.com Thu Jun 19 21:23:23 2008 From: henriquecsj at gmail.com (Henrique Junior) Date: Thu, 19 Jun 2008 14:23:23 -0700 (PDT) Subject: [Fedora-packaging] Menu entries Message-ID: <695936.11294.qm@web45504.mail.sp1.yahoo.com> Hi, folks, I'm Henrique from Brazil and I'm trying to be a maintainer of a chemical drawing tool called bkchem. After some reseach and with Terje's help the job is almost done, but I'm not able to make the RPM create a menu entrie for the software. Can anyone helpe with this? In the source folder we see bkchem-0.12.2/images that contains icons with many resolutions and a splash screen. Thank you all Henrique "LonelySpooky" Junior ________________________________ "In a world without walls and fences, who needs windows and gates?!" Abra sua conta no Yahoo! Mail, o ?nico sem limite de espa?o para armazenamento! http://br.mail.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eduardo at kalinowski.com.br Thu Jun 19 21:33:00 2008 From: eduardo at kalinowski.com.br (Eduardo M KALINOWSKI) Date: Thu, 19 Jun 2008 18:33:00 -0300 Subject: [Fedora-packaging] Menu entries In-Reply-To: <695936.11294.qm@web45504.mail.sp1.yahoo.com> References: <695936.11294.qm@web45504.mail.sp1.yahoo.com> Message-ID: <485AD08C.5030900@kalinowski.com.br> Henrique Junior wrote: > Hi, folks, > I'm Henrique from Brazil and I'm trying to be a maintainer of a > chemical drawing tool called bkchem. > After some reseach and with Terje's help the job is almost done, but > I'm not able to make the RPM create a menu entrie for the software. > Can anyone helpe with this? > In the source folder we see bkchem-0.12.2/images that contains icons > with many resolutions and a splash screen. You need a .desktop file for that. The description of the file's format can be found here: http://standards.freedesktop.org/desktop-entry-spec/latest/ You can also look at other package's files to see how to create one such file. Having the .desktop file, you just need to make some small changes to the spec file to register the file. They are described in the packaging guidelines: https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files -- The brotherhood of man is not a mere poet's dream; it is a most depressing and humiliating reality. -- Oscar Wilde Eduardo M KALINOWSKI eduardo at kalinowski.com.br http://move.to/hpkb From abartlet at samba.org Thu Jun 19 23:51:49 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 20 Jun 2008 09:51:49 +1000 Subject: [Fedora-packaging] Unclear in the use of %doc Message-ID: <1213919509.3603.8.camel@naomi> I'm a bit lost on the use of %doc for manpages. I'm building a package of Heimdal Kerberos, so I'm following a lot of the MIT krb5 package as a pattern. Should manpages be marked as %doc, or just other documentation? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Fri Jun 20 01:35:55 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 19 Jun 2008 21:35:55 -0400 Subject: [Fedora-packaging] Unclear in the use of %doc In-Reply-To: <1213919509.3603.8.camel@naomi> References: <1213919509.3603.8.camel@naomi> Message-ID: <1213925755.10118.207.camel@ignacio.lan> On Fri, 2008-06-20 at 09:51 +1000, Andrew Bartlett wrote: > I'm a bit lost on the use of %doc for manpages. > > I'm building a package of Heimdal Kerberos, so I'm following a lot of > the MIT krb5 package as a pattern. > > Should manpages be marked as %doc, or just other documentation? Files under /usr/share/{man,info} are automagically marked %doc by rpmbuild. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Fri Jun 20 02:28:05 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 20 Jun 2008 12:28:05 +1000 Subject: [Fedora-packaging] Unclear in the use of %doc In-Reply-To: <1213925755.10118.207.camel@ignacio.lan> References: <1213919509.3603.8.camel@naomi> <1213925755.10118.207.camel@ignacio.lan> Message-ID: <1213928885.3603.26.camel@naomi> On Thu, 2008-06-19 at 21:35 -0400, Ignacio Vazquez-Abrams wrote: > On Fri, 2008-06-20 at 09:51 +1000, Andrew Bartlett wrote: > > I'm a bit lost on the use of %doc for manpages. > > > > I'm building a package of Heimdal Kerberos, so I'm following a lot of > > the MIT krb5 package as a pattern. > > > > Should manpages be marked as %doc, or just other documentation? > > Files under /usr/share/{man,info} are automagically marked %doc by > rpmbuild. Following the pattern long-established history and from the MIT krb5 pacakge, I'm using a new directory (yes, I know I need to ask approval) of /usr/heimdal, so I think that means I need to manually mark them as % doc. Thanks for the info, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Fri Jun 20 02:33:00 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 20 Jun 2008 12:33:00 +1000 Subject: [Fedora-packaging] Non-UTF8 gzipped manpages Message-ID: <1213929180.3603.34.camel@naomi> I'm getting warnings on all the gzipped manpages (I'm instructed by rpmlint to gzip them) being not UTF8. heimdal-devel.x86_64: W: file-not-utf8 /usr/heimdal/man/man3/gss_krb5_ccache_name.3.gz The character encoding of this file is not UTF-8. Consider converting it in the specfile for example using iconv(1). Running: man /usr/heimdal/man/man3/gss_krb5_ccache_name.3.gz> /tmp/heimdal.txt [abartlet at naomi heimdal-mandriva-rpm]$ file /tmp/heimdal.txt /tmp/heimdal.txt: UTF-8 Unicode English text, with overstriking Indicates they are UTF-8, so what's going on here? I've attached this example to this mail. Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: gss_krb5_ccache_name.3.gz Type: application/x-gzip Size: 4847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Fri Jun 20 02:35:36 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Jun 2008 21:35:36 -0500 Subject: [Fedora-packaging] Non-UTF8 gzipped manpages In-Reply-To: <1213929180.3603.34.camel@naomi> References: <1213929180.3603.34.camel@naomi> Message-ID: >>>>> "AB" == Andrew Bartlett writes: AB> Indicates they are UTF-8, so what's going on here? Line 1: .\" Copyright (c) 2003 - 2007 Kungliga Tekniska Hgskolan Looks non-utf8 to me. - J< From abartlet at samba.org Fri Jun 20 03:55:34 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 20 Jun 2008 13:55:34 +1000 Subject: [Fedora-packaging] Non-UTF8 gzipped manpages In-Reply-To: References: <1213929180.3603.34.camel@naomi> Message-ID: <1213934134.3603.39.camel@naomi> On Thu, 2008-06-19 at 21:35 -0500, Jason L Tibbitts III wrote: > >>>>> "AB" == Andrew Bartlett writes: > > AB> Indicates they are UTF-8, so what's going on here? > > Line 1: > .\" Copyright (c) 2003 - 2007 Kungliga Tekniska Hgskolan > > Looks non-utf8 to me. Thanks. I presumed it would be that (I've regularly mangled names when working on heimdal over the years :-), but as it was a comment it never makes it to the formatted manpage :-) Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Fri Jun 20 06:18:20 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 20 Jun 2008 08:18:20 +0200 Subject: [Fedora-packaging] Unclear in the use of %doc In-Reply-To: <1213928885.3603.26.camel@naomi> References: <1213919509.3603.8.camel@naomi> <1213925755.10118.207.camel@ignacio.lan> <1213928885.3603.26.camel@naomi> Message-ID: <1213942700.23243.2.camel@rousalka.okg> Le vendredi 20 juin 2008 ? 12:28 +1000, Andrew Bartlett a ?crit : > On Thu, 2008-06-19 at 21:35 -0400, Ignacio Vazquez-Abrams wrote: > > On Fri, 2008-06-20 at 09:51 +1000, Andrew Bartlett wrote: > > > I'm a bit lost on the use of %doc for manpages. > > > > > > I'm building a package of Heimdal Kerberos, so I'm following a lot of > > > the MIT krb5 package as a pattern. > > > > > > Should manpages be marked as %doc, or just other documentation? > > > > Files under /usr/share/{man,info} are automagically marked %doc by > > rpmbuild. > > Following the pattern long-established history and from the MIT krb5 > pacakge, I'm using a new directory (yes, I know I need to ask approval) > of /usr/heimdal, so I think that means I need to manually mark them as % > doc. Please follow the FHS rules and do not create new roots where the FHS says you should not. I certainly hope the krb packages get fixed someday but in the meanwhile that's no reason to repeat their mistakes -- 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 abartlet at samba.org Fri Jun 20 07:04:57 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 20 Jun 2008 17:04:57 +1000 Subject: [Fedora-packaging] Unclear in the use of %doc In-Reply-To: <1213942700.23243.2.camel@rousalka.okg> References: <1213919509.3603.8.camel@naomi> <1213925755.10118.207.camel@ignacio.lan> <1213928885.3603.26.camel@naomi> <1213942700.23243.2.camel@rousalka.okg> Message-ID: <1213945497.3603.46.camel@naomi> On Fri, 2008-06-20 at 08:18 +0200, Nicolas Mailhot wrote: > Le vendredi 20 juin 2008 ? 12:28 +1000, Andrew Bartlett a ?crit : > > On Thu, 2008-06-19 at 21:35 -0400, Ignacio Vazquez-Abrams wrote: > > > On Fri, 2008-06-20 at 09:51 +1000, Andrew Bartlett wrote: > > > > I'm a bit lost on the use of %doc for manpages. > > > > > > > > I'm building a package of Heimdal Kerberos, so I'm following a lot of > > > > the MIT krb5 package as a pattern. > > > > > > > > Should manpages be marked as %doc, or just other documentation? > > > > > > Files under /usr/share/{man,info} are automagically marked %doc by > > > rpmbuild. > > > > Following the pattern long-established history and from the MIT krb5 > > pacakge, I'm using a new directory (yes, I know I need to ask approval) > > of /usr/heimdal, so I think that means I need to manually mark them as % > > doc. > > Please follow the FHS rules and do not create new roots where the FHS > says you should not. I certainly hope the krb packages get fixed someday > but in the meanwhile that's no reason to repeat their mistakes No worries, I'll move them. (The MIT krb5 package's use of a non-FHS prefix allows me to avoid conflicts ;-) Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From philipp_subx at redfish-solutions.com Fri Jun 20 17:07:28 2008 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 20 Jun 2008 10:07:28 -0700 Subject: [Fedora-packaging] Adding mod_proxy_html to httpd package? In-Reply-To: <4859A198.3000008@redfish-solutions.com> References: <4859A198.3000008@redfish-solutions.com> Message-ID: <485BE3D0.7040703@redfish-solutions.com> Philip Prindeville wrote: > I recently found out that I needed but couldn't find mod_proxy_html.so > for my FC7 system running httpd-2.2.8. > > Mod_proxy_html is GPL'd, so that's not an issue. > > It looks like it just drops right down into the modules/proxy/ > directory and builds (with minor patching of the config.m4 file). > > I was thinking of tweaking the existing package to build > mod_proxy_html as well, but put it into a separate %package. > > If I do this for fc7, is someone else willing to code review it and > hopefully port the changes up to fc10 or rawhide? > > Thanks, > > -Philip As threatened... Turns out it builds via apxs with no issues. The same RPM should build with no issues against FC9 or FC10... -Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: httpd-mod_proxy_html-3.0.0-1.fc7.src.rpm Type: application/octet-stream Size: 23684 bytes Desc: not available URL: From tgl at redhat.com Sat Jun 21 19:29:39 2008 From: tgl at redhat.com (Tom Lane) Date: Sat, 21 Jun 2008 15:29:39 -0400 Subject: [Fedora-packaging] Why is hard-wired version dependency required by Packaging/Tcl? Message-ID: <23128.1214076579@sss.pgh.pa.us> At https://fedoraproject.org/wiki/Packaging/Tcl I read Both arch-specific and noarch Tcl extensions MUST use Requires: tcl(abi) = 8.5 which seems more than a little bizarre when every other part of the page tells you that you MUST avoid putting hard-wired Tcl version number dependencies into your specfile. And it also tells you exactly how to extract the Tcl version dynamically. So why isn't this a better solution? Requires: tcl(abi) = %{tcl_version} regards, tom lane From tibbs at math.uh.edu Sat Jun 21 23:05:34 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Jun 2008 18:05:34 -0500 Subject: [Fedora-packaging] Requires(hint): Message-ID: I've seen packages using Requires(hint): and testing shows that currently this is handled no differently from a regular Requires:. I happen to think Requires(hint): is a horrible syntax, because cognation with Requires(pre, post, preun, etc.): implies that some %hint scriptlet will be run at some point, but that's neither here nor there and I suspect that any upstream brain-damage is already a fait accompli. However, there's still the question of what to do with Requires(hint): in Fedora packages. Either we get rid of it or we need to document what it does and what it might do in the future. Strawman proposal: ban use of Requires(hint) in Fedora packages. Comments? Votes from FPC folks? - J< From pertusus at free.fr Sun Jun 22 00:20:42 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 22 Jun 2008 02:20:42 +0200 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: Message-ID: <20080622002042.GA3243@free.fr> On Sat, Jun 21, 2008 at 06:05:34PM -0500, Jason L Tibbitts III wrote: > I've seen packages using Requires(hint): and testing shows that > currently this is handled no differently from a regular Requires:. This looks like a bug. Shouldn't a 'hint' not be installed in the defaut case? -- Pat From tibbs at math.uh.edu Sun Jun 22 00:59:20 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Jun 2008 19:59:20 -0500 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <20080622002042.GA3243@free.fr> References: <20080622002042.GA3243@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> This looks like a bug. Shouldn't a 'hint' not be installed in the PD> defaut case? I think the bug is that the build proceeds at all with Requires(hint) present. I'm not sure it's handled any differently than Requires(randomcrap):. In fact, testing shows that it isn't. The point is that our rpm doesn't seem to recognize Requires(hint) specifically. It might start doing so in the future; I don't know. If it does, I expect that the behavior will change because the current behavior isn't what you would expect if rpm actually recognized the string in parentheses. Thus I think it's a bad idea for us to have it anywhere in the distro currently. - J< From henriquecsj at gmail.com Sun Jun 22 01:25:13 2008 From: henriquecsj at gmail.com (Henrique Junior) Date: Sat, 21 Jun 2008 18:25:13 -0700 (PDT) Subject: [Fedora-packaging] Troubles with the .desktop file Message-ID: <327097.21526.qm@web45513.mail.sp1.yahoo.com> Hi folks, I'm trying to create an RPM from the chemical drawing tool BkChem but: 1 - The software doesn't have an .desktop file So I created it myself and it looks right [1] 2 - But when creating an RPM I receive a message that some files are not packaged. Can someone, please, give some help? Here is the .spec [2] and the src.rpm that I made without creating an .desktop entry. [1] - http://lspooky.fedorapeople.org/bkchem.desktop [2] - http://lspooky.fedorapeople.org/bkchem.spec [3] - http://lspooky.fedorapeople.org/bkchem-0.12.2-1.fc9.src.rpm Thanks Henrique "LonelySpooky" Junior ________________________________ "In a world without walls and fences, who needs windows and gates?!" Novos endere?os, o Yahoo! que voc? conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com. http://br.new.mail.yahoo.com/addresses -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.stone at gmail.com Sun Jun 22 01:30:56 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Sat, 21 Jun 2008 18:30:56 -0700 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: Message-ID: On Sat, Jun 21, 2008 at 4:05 PM, Jason L Tibbitts III wrote: > Strawman proposal: ban use of Requires(hint) in Fedora packages. Shouldn't this be: ban use of Requires(RandomCrapWhichIsntSupportedYet) Otherwise, I can just change my Requires(hint) to Requires(opt) or some other random crap. From tibbs at math.uh.edu Sun Jun 22 01:59:16 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Jun 2008 20:59:16 -0500 Subject: [Fedora-packaging] Troubles with the .desktop file In-Reply-To: <327097.21526.qm@web45513.mail.sp1.yahoo.com> References: <327097.21526.qm@web45513.mail.sp1.yahoo.com> Message-ID: >>>>> "HJ" == Henrique Junior writes: HJ> But when creating an RPM I receive a message that some files are HJ> not packaged. Yes, you need to include the installed .desktop file in your %files list with a line like %{_datadir}/applications/* or %{_datadir}/applications/%{name}.desktop Every file that the %install section of your spec installs into the buildroot must be included in the %files list somehow. If not, you get the error you're seeing. - J< From tibbs at math.uh.edu Sun Jun 22 02:04:03 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Jun 2008 21:04:03 -0500 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: Message-ID: >>>>> "CS" == Christopher Stone writes: CS> Shouldn't this be: ban use of CS> Requires(RandomCrapWhichIsntSupportedYet) Otherwise, I can just CS> change my Requires(hint) to Requires(opt) or some other random CS> crap. It would be disappointing to have to go to this level of lawyering. I mean, who would actually do that? Of course, I'd hoped that people wouldn't want to use things like Requires(hint): until they're actually defined and supported, but that seems to have been a lost cause. - J< From tgl at redhat.com Sun Jun 22 02:37:46 2008 From: tgl at redhat.com (Tom Lane) Date: Sat, 21 Jun 2008 22:37:46 -0400 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: Message-ID: <29692.1214102266@sss.pgh.pa.us> Jason L Tibbitts III writes: > "CS" == Christopher Stone writes: > CS> Shouldn't this be: ban use of > CS> Requires(RandomCrapWhichIsntSupportedYet) Otherwise, I can just > CS> change my Requires(hint) to Requires(opt) or some other random > CS> crap. > It would be disappointing to have to go to this level of lawyering. I > mean, who would actually do that? *Everyone* is only one typo away from invoking Requires(randomcrap). ISTM this is not a policy problem. The correct response to this is to fix our tools so that you get an error if the parenthesized string isn't one of the accepted values. If the tools enforce a list-of-accepted-values that's a bit stricter than upstream's, that's fine too; but what the heck are we doing allowing obvious mistakes in specfiles to pass? regards, tom lane From tibbs at math.uh.edu Sun Jun 22 02:40:40 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Jun 2008 21:40:40 -0500 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <29692.1214102266@sss.pgh.pa.us> References: <29692.1214102266@sss.pgh.pa.us> Message-ID: >>>>> "TL" == Tom Lane writes: TL> The correct response to this is to fix our tools so that you get TL> an error if the parenthesized string isn't one of the accepted TL> values. I don't disagree, but "correct" and "workable" are different things; as much as we wish it were so, we have to work with the rpm we have, not the one we wish we had. It's certainly worth trying to get rpm changed, but this committee has in the past not had a whole lot of luck with that, and so we write guidelines which take into account rpm's issues. - J, From tgl at redhat.com Sun Jun 22 03:00:14 2008 From: tgl at redhat.com (Tom Lane) Date: Sat, 21 Jun 2008 23:00:14 -0400 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: <29692.1214102266@sss.pgh.pa.us> Message-ID: <161.1214103614@sss.pgh.pa.us> Jason L Tibbitts III writes: > I don't disagree, but "correct" and "workable" are different things; > as much as we wish it were so, we have to work with the rpm we have, > not the one we wish we had. Hmm, I understand that upstream might be less than tractable, but surely that doesn't prevent us from carrying our own patches that enforce restrictions that Fedora deems desirable. I don't like carrying distro-private patches more than anyone else; but when you're talking about fundamental bits of distro infrastructure, allowing someone else to dictate our project policy doesn't seem right. regards, tom lane From henriquecsj at gmail.com Sun Jun 22 03:23:42 2008 From: henriquecsj at gmail.com (Henrique "LonelySpooky" Junior) Date: Sun, 22 Jun 2008 00:23:42 -0300 Subject: [Fedora-packaging] Package Revision Needed Message-ID: <1214105022.3070.6.camel@localhost.localdomain> Hello, all I just finished the RPM for BkChem. The next step is to ask someone to check it? Any volunteer? Here they are: http://lspooky.fedorapeople.org/ Regards -- Henrique "LonelySpooky" Junior Projeto Fedora Brasil From tibbs at math.uh.edu Sun Jun 22 05:02:32 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Jun 2008 00:02:32 -0500 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <161.1214103614@sss.pgh.pa.us> References: <29692.1214102266@sss.pgh.pa.us> <161.1214103614@sss.pgh.pa.us> Message-ID: >>>>> "TL" == Tom Lane writes: TL> Hmm, I understand that upstream might be less than tractable, but TL> surely that doesn't prevent us from carrying our own patches that TL> enforce restrictions that Fedora deems desirable. Well, personally I don't invest a lot of time in the idea that rpm will suddenly grow sanity; I concentrate on packaging issues and how they relate to the rpm we actually have. Besides, the packaging guidelines currently cover releases that will almost certainly not receive any version of rpm that is updated to fix this issue, so its still a reasonable thing for the packaging committee to discuss. TL> I don't like carrying distro-private patches more than anyone TL> else; but when you're talking about fundamental bits of distro TL> infrastructure, allowing someone else to dictate our project TL> policy doesn't seem right. You seem to assume that the Fedora rpm developers will agree with you and decide to change rpm; that is certainly not a given. I would, however, encourage you to pursue that line of inquiry. Getting a check for this kind of thing into rpmlint would be an expedient stopgap measure, but without the packaging committee actually writing a guideline, rpmlint complaints don't carry all that much weight. - J< From tgl at redhat.com Sun Jun 22 06:10:33 2008 From: tgl at redhat.com (Tom Lane) Date: Sun, 22 Jun 2008 02:10:33 -0400 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: <29692.1214102266@sss.pgh.pa.us> <161.1214103614@sss.pgh.pa.us> Message-ID: <2982.1214115033@sss.pgh.pa.us> Jason L Tibbitts III writes: >> [ some other discussion ] > You seem to assume that the Fedora rpm developers will agree with you > and decide to change rpm; that is certainly not a given. Hm ... so this committee takes it as a given that the maintainer of RPM can arbitrarily reject any committee decision. That's completely fine with me, because transitive closure implies that I can ignore the committee's decisions for my own packages. I think I will unsubscribe now. Call me when you've grown some backbone. regards, tom lane From debarshi.ray at gmail.com Sun Jun 22 09:45:32 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sun, 22 Jun 2008 15:15:32 +0530 Subject: [Fedora-packaging] Package Revision Needed In-Reply-To: <1214105022.3070.6.camel@localhost.localdomain> References: <1214105022.3070.6.camel@localhost.localdomain> Message-ID: <3170f42f0806220245l7dc87008xaa6388e0b63a039f@mail.gmail.com> > I just finished the RPM for BkChem. The next step is to ask someone to > check it? You need to submit a review request. If this is your first package follow https://fedoraproject.org/wiki/PackageMaintainers/Join Cheers, Debarshi From tcallawa at redhat.com Sun Jun 22 11:41:51 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 22 Jun 2008 07:41:51 -0400 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <2982.1214115033@sss.pgh.pa.us> References: <29692.1214102266@sss.pgh.pa.us> <161.1214103614@sss.pgh.pa.us> <2982.1214115033@sss.pgh.pa.us> Message-ID: <1214134911.3172.13.camel@localhost.localdomain> On Sun, 2008-06-22 at 02:10 -0400, Tom Lane wrote: > Hm ... so this committee takes it as a given that the maintainer of > RPM can arbitrarily reject any committee decision. Tom, I think you're misunderstanding our "lack of backbone" here. In the recent past, we've generated patches for RPM to fix "obvious bugs", submitted them upstream, and had them rejected without alternative suggestions (aside from flame wars). In many cases, our "obvious bugs" are described by upstream as features. The Fedora RPM maintainers (who are actually RPM's upstream as well) don't want to carry these patches either, taking an "upstream or nothing" approach to this. In addition, when we've suggested fixes to RPM, we've gotten the feedback of "is it in the Packaging Guidelines"? Accordingly, we've adopted the strategy that: 1. It is not in the Packaging Committee's mandate (or ability) to be able to force patches into RPM. 2. The next best thing is to make guidelines which describe how RPM should/must be used in Fedora. 3. When applicable, the Packaging Committee will make suggestions based around our guidelines to RPM upstream in the hopes that our guidelines will be made obsolete. For example, it is only now that RPM is working on setting a default BuildRoot, something we set guidelines for over a year ago. ~spot From ville.skytta at iki.fi Sun Jun 22 11:46:15 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 22 Jun 2008 14:46:15 +0300 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: Message-ID: <200806221446.15616.ville.skytta@iki.fi> On Sunday 22 June 2008, Jason L Tibbitts III wrote: > Strawman proposal: ban use of Requires(hint) in Fedora packages. -1 From jkeating at redhat.com Sun Jun 22 12:03:44 2008 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 22 Jun 2008 08:03:44 -0400 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <200806221446.15616.ville.skytta@iki.fi> References: <200806221446.15616.ville.skytta@iki.fi> Message-ID: <1214136224.4405.3.camel@localhost.localdomain> On Sun, 2008-06-22 at 14:46 +0300, Ville Skytt? wrote: > On Sunday 22 June 2008, Jason L Tibbitts III wrote: > > > Strawman proposal: ban use of Requires(hint) in Fedora packages. > > -1 > How about a little meat to that "-1", like what you don't agree to in the proposal, alternative proposals to resolve the problem, etc... -- Jesse Keating Fedora -- Freedom? is a feature! -------------- 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 ville.skytta at iki.fi Sun Jun 22 16:56:01 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sun, 22 Jun 2008 19:56:01 +0300 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <1214136224.4405.3.camel@localhost.localdomain> References: <200806221446.15616.ville.skytta@iki.fi> <1214136224.4405.3.camel@localhost.localdomain> Message-ID: <200806221956.01586.ville.skytta@iki.fi> On Sunday 22 June 2008, Jesse Keating wrote: > On Sun, 2008-06-22 at 14:46 +0300, Ville Skytt? wrote: > > On Sunday 22 June 2008, Jason L Tibbitts III wrote: > > > Strawman proposal: ban use of Requires(hint) in Fedora packages. > > > > -1 > > How about a little meat to that "-1", like what you don't agree to in > the proposal, alternative proposals to resolve the problem, etc... There's not much to say except the obvious: I just fail to see the problem you're referring to and thus see no reason why it should be banned. The semantics (both current and future) should be pretty clear and I'd be surprised if we wouldn't eventually see tools that support it better than just treating it as equivalent to plain Requires. I do think that Enhances:/Recommends:/Suggests: are better syntaxes than Requires(hint): though, but unlike (hint) they're not backwards compatible. From tibbs at math.uh.edu Sun Jun 22 16:59:57 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Jun 2008 11:59:57 -0500 Subject: [Fedora-packaging] Best practices for packaging logfiles Message-ID: I noticed a package in the review queue doing this to manage its logfile: %post /sbin/chkconfig --add %{name} touch %{_localstatedir}/log/%{name} chown sip:sip %{_localstatedir}/log/%{name} %files [...] %ghost %attr(0644,sip,sip) %{_localstatedir}/log/%{name} (the sip user/group are created in %pre). I was unsure of the difference between this and simply owning the file in %files; the ownership comes out right, but behavior might differ on upgrades and there's the issue of rpm -V. Does %ghost imply something like %verify(not md5 size mtime)? That's the best current practice for doing this? - J< From tibbs at math.uh.edu Sun Jun 22 17:11:30 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Jun 2008 12:11:30 -0500 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <200806221956.01586.ville.skytta@iki.fi> References: <200806221446.15616.ville.skytta@iki.fi> <1214136224.4405.3.camel@localhost.localdomain> <200806221956.01586.ville.skytta@iki.fi> Message-ID: >>>>> "VS" == Ville Skytt? writes: VS> The semantics (both current and future) should be pretty clear and VS> I'd be surprised if we wouldn't eventually see tools that support VS> it better than just treating it as equivalent to plain Requires. That's precisely my point, though. It has no use in current packages, and may change behavior according to the whims of rpm's maintainers. Not a terribly good thing to allow. Besides, ignoring rpm's behavior for a bit, it's still a valid question as to whether this is desired in Fedora. That question touches on things like how yum and kickstart should handle such dependencies. I don't think it should be allowed until the larger questions are answered. - J< From enrico.scholz at informatik.tu-chemnitz.de Sun Jun 22 17:51:32 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 22 Jun 2008 19:51:32 +0200 Subject: [Fedora-packaging] Re: Best practices for packaging logfiles In-Reply-To: (Jason L. Tibbitts, III's message of "22 Jun 2008 11:59:57 -0500") References: Message-ID: <87r6ap5pej.fsf@sheridan.bigo.ensc.de> Jason L Tibbitts III writes: > I noticed a package in the review queue doing this to manage its > logfile: > ... > That's the best current practice for doing this? https://fedoraproject.org/wiki/PackagingDrafts/Logfiles Enrico From enrico.scholz at informatik.tu-chemnitz.de Sun Jun 22 18:11:06 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 22 Jun 2008 20:11:06 +0200 Subject: [Fedora-packaging] Re: Best practices for packaging logfiles In-Reply-To: <87r6ap5pej.fsf@sheridan.bigo.ensc.de> (Enrico Scholz's message of "Sun, 22 Jun 2008 19:51:32 +0200") References: <87r6ap5pej.fsf@sheridan.bigo.ensc.de> Message-ID: <87myld5ohx.fsf@sheridan.bigo.ensc.de> Enrico Scholz writes: >> I noticed a package in the review queue doing this to manage its >> logfile: > ... > https://fedoraproject.org/wiki/PackagingDrafts/Logfiles Wiki conversion removed some important information; original page should be more readable http://fedoraproject.org/wikiold/PackagingDrafts/Logfiles Enrico From tibbs at math.uh.edu Sun Jun 22 18:14:16 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 22 Jun 2008 13:14:16 -0500 Subject: [Fedora-packaging] Re: Best practices for packaging logfiles In-Reply-To: <87r6ap5pej.fsf@sheridan.bigo.ensc.de> References: <87r6ap5pej.fsf@sheridan.bigo.ensc.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> https://fedoraproject.org/wiki/PackagingDrafts/Logfiles Well, no offense, but your tendencies towards needless obfuscation require me ask if these are anyone else's best practices. At the very least, it's reasonable to ask why these were never submitted to the packaging committee. At least, I don't recall ever seeing them. - J< From rdieter at math.unl.edu Sun Jun 22 19:44:19 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 22 Jun 2008 14:44:19 -0500 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: Message-ID: <485EAB93.7010609@math.unl.edu> Jason L Tibbitts III wrote: > I've seen packages using Requires(hint): and testing shows that > currently this is handled no differently from a regular Requires:. > > I happen to think Requires(hint): is a horrible syntax, because > cognation with Requires(pre, post, preun, etc.): implies that some > %hint scriptlet will be run at some point, but that's neither here nor > there and I suspect that any upstream brain-damage is already a fait > accompli. > > However, there's still the question of what to do with Requires(hint): > in Fedora packages. Either we get rid of it or we need to document > what it does and what it might do in the future. > > Strawman proposal: ban use of Requires(hint) in Fedora packages. -1 to ban, this is (potential) rpm functionality at issue here, which should *first* be discussed with rpm maintainers before any action or policy be considered. -- Rex From pmatilai at laiskiainen.org Mon Jun 23 08:36:12 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 23 Jun 2008 11:36:12 +0300 (EEST) Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <1214134911.3172.13.camel@localhost.localdomain> References: <29692.1214102266@sss.pgh.pa.us> <161.1214103614@sss.pgh.pa.us> <2982.1214115033@sss.pgh.pa.us> <1214134911.3172.13.camel@localhost.localdomain> Message-ID: On Sun, 22 Jun 2008, Tom \spot\ Callaway wrote: > On Sun, 2008-06-22 at 02:10 -0400, Tom Lane wrote: >> Hm ... so this committee takes it as a given that the maintainer of >> RPM can arbitrarily reject any committee decision. > > Tom, > > I think you're misunderstanding our "lack of backbone" here. In the > recent past, we've generated patches for RPM to fix "obvious bugs", > submitted them upstream, and had them rejected without alternative > suggestions (aside from flame wars). In many cases, our "obvious bugs" > are described by upstream as features. In the recent past, hmm? Care to refresh my memory, I don't remember rejecting patches for "obvious bugs"? > The Fedora RPM maintainers (who are actually RPM's upstream as well) > don't want to carry these patches either, taking an "upstream or > nothing" approach to this. Well, that's one of the big principles in Fedora, isn't it? :) > In addition, when we've suggested fixes to RPM, we've gotten the > feedback of "is it in the Packaging Guidelines"? There seems to be a serious disconnect here, something being in Fedora packaging guidelines sure as hell isn't a prerequisite for getting patches accepted to rpm.org upstream. And I certainly don't recall asking for such a thing, if some response I've given has given you that impression then please point it out and lets straighten up the apparent miscommunication. > Accordingly, we've adopted the strategy that: > > 1. It is not in the Packaging Committee's mandate (or ability) to be > able to force patches into RPM. > 2. The next best thing is to make guidelines which describe how RPM > should/must be used in Fedora. > 3. When applicable, the Packaging Committee will make suggestions based > around our guidelines to RPM upstream in the hopes that our guidelines > will be made obsolete. > > For example, it is only now that RPM is working on setting a default > BuildRoot, something we set guidelines for over a year ago. Yes, catching up years of abandon doesn't happen overnight... As for Requires(randomcrap), sure it's a bug that RPM doesn't catch the error and bail out, and "hint" is just random crap as far as RPM is concerned. Now, of course the same could be said about putting versions into changelog "author field" - it's just an ancient bug in RPM it doesn't catch "trailing garbage after email address", it just happens to be so widely abused (and even encouraged in various packaging standards) that just making the spec parser treat it as an error is not really an option. ...if you catch my drift... I'm all for making the spec syntax stricter and saner, but things are not always so black and white. Knowingly putting invalid things into specs just because rpm doesn't currently happen to trip on them certainly does not help the cause, see above wrt the version-in-changelog thing. - Panu - From Fedora at FamilleCollet.com Mon Jun 23 16:29:41 2008 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 23 Jun 2008 18:29:41 +0200 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: Message-ID: <485FCF75.1090207@FamilleCollet.com> Jason L Tibbitts III a ?crit : > I've seen packages using Requires(hint): and testing shows that > currently this is handled no differently from a regular Requires:. Using this have one usefull purpose : documentation. Ok, we can also use # Optional dependency Requires: foo My 0.02 ? Regards From amir.pluglist at gmail.com Tue Jun 24 04:30:53 2008 From: amir.pluglist at gmail.com (Amir Franco Joven) Date: Tue, 24 Jun 2008 12:30:53 +0800 Subject: [Fedora-packaging] Customizing Fedora Installer Message-ID: Hi, I'm trying to customize the Fedora installer for my orgs use. The idea is we have apps that we want to include in the fedora cd/dvd installer, we only need it for our own, not for the whole fedora distribution. What I've tried so far is pungi, and yes, I was able to produce an updated installer. the only problem that i have now is i dont know which files to modify to add our app in the package selection can someone point me to a document that i should read to carry out our plan? or is this really possible? Thank you very much in advance. Best regards, Amir -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwilson at redhat.com Tue Jun 24 18:41:52 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 24 Jun 2008 14:41:52 -0400 Subject: [Fedora-packaging] Customizing Fedora Installer In-Reply-To: References: Message-ID: <200806241441.52284.jwilson@redhat.com> On Tuesday 24 June 2008 12:30:53 am Amir Franco Joven wrote: > Hi, > > I'm trying to customize the Fedora installer for my orgs use. > The idea is we have apps that we want to include in the fedora cd/dvd > installer, > we only need it for our own, not for the whole fedora distribution. > > What I've tried so far is pungi, and yes, I was able to produce an updated > installer. > the only problem that i have now is i dont know which files to modify to > add our app in the package selection > > can someone point me to a document that i should read to carry out our > plan? or is this really possible? Packages show up in the package selection area based on entries in the comps file. The comps file for the installer is created on the fly by pungi, but merging together the comps metadata out of all the yum repos used to create the spin. I've done some fairly extensive package selection changes myself by simply putting the comps file I wanted into a private yum repo w/my custom packages. Not sure if its particularly well documented anywhere, but its definitely doable. Google around for MythDora (version 5) to see an example of a modified F8 installer. -- Jarod Wilson jwilson at redhat.com From amir.pluglist at gmail.com Wed Jun 25 06:43:17 2008 From: amir.pluglist at gmail.com (Amir Franco Joven) Date: Wed, 25 Jun 2008 14:43:17 +0800 Subject: [Fedora-packaging] Customizing Fedora Installer In-Reply-To: <200806241441.52284.jwilson@redhat.com> References: <200806241441.52284.jwilson@redhat.com> Message-ID: Hi Jarod, Thanks very much for the hints. Will explore further. Best regards, Amir On Wed, Jun 25, 2008 at 2:41 AM, Jarod Wilson wrote: > On Tuesday 24 June 2008 12:30:53 am Amir Franco Joven wrote: > > Hi, > > > > I'm trying to customize the Fedora installer for my orgs use. > > The idea is we have apps that we want to include in the fedora cd/dvd > > installer, > > we only need it for our own, not for the whole fedora distribution. > > > > What I've tried so far is pungi, and yes, I was able to produce an > updated > > installer. > > the only problem that i have now is i dont know which files to modify to > > add our app in the package selection > > > > can someone point me to a document that i should read to carry out our > > plan? or is this really possible? > > Packages show up in the package selection area based on entries in the > comps > file. The comps file for the installer is created on the fly by pungi, but > merging together the comps metadata out of all the yum repos used to create > the spin. I've done some fairly extensive package selection changes myself > by > simply putting the comps file I wanted into a private yum repo w/my custom > packages. Not sure if its particularly well documented anywhere, but its > definitely doable. Google around for MythDora (version 5) to see an example > of a modified F8 installer. > > > > -- > Jarod Wilson > jwilson at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmatilai at laiskiainen.org Wed Jun 25 08:02:18 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 25 Jun 2008 11:02:18 +0300 (EEST) Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <485FCF75.1090207@FamilleCollet.com> References: <485FCF75.1090207@FamilleCollet.com> Message-ID: On Mon, 23 Jun 2008, Remi Collet wrote: > Jason L Tibbitts III a ?crit : >> I've seen packages using Requires(hint): and testing shows that >> currently this is handled no differently from a regular Requires:. > > Using this have one usefull purpose : documentation. Abusing bugs in software for documentation purposes? Lets not... > Ok, we can also use > > # Optional dependency > Requires: foo Yes, that's what comments are for. - Panu - From chris.stone at gmail.com Wed Jun 25 11:50:44 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 25 Jun 2008 04:50:44 -0700 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: <485FCF75.1090207@FamilleCollet.com> Message-ID: On Wed, Jun 25, 2008 at 1:02 AM, Panu Matilainen wrote: > On Mon, 23 Jun 2008, Remi Collet wrote: > >> Jason L Tibbitts III a ?crit : >>> >>> I've seen packages using Requires(hint): and testing shows that >>> currently this is handled no differently from a regular Requires:. >> >> Using this have one usefull purpose : documentation. > > Abusing bugs in software for documentation purposes? Lets not... It works well for me, so I will continue to "abuse" the "bug" for documentation purposes. My personal opinion is that this thread is making a big deal out of nothing. From rc040203 at freenet.de Wed Jun 25 12:02:01 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 25 Jun 2008 14:02:01 +0200 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: <485FCF75.1090207@FamilleCollet.com> Message-ID: <1214395321.3656.244.camel@beck.corsepiu.local> On Wed, 2008-06-25 at 04:50 -0700, Christopher Stone wrote: > On Wed, Jun 25, 2008 at 1:02 AM, Panu Matilainen > wrote: > > On Mon, 23 Jun 2008, Remi Collet wrote: > > > >> Jason L Tibbitts III a ?crit : > >>> > >>> I've seen packages using Requires(hint): and testing shows that > >>> currently this is handled no differently from a regular Requires:. > >> > >> Using this have one usefull purpose : documentation. > > > > Abusing bugs in software for documentation purposes? Lets not... > > It works well for me, so I will continue to "abuse" the "bug" for > documentation purposes. > > My personal opinion is that this thread is making a big deal out of nothing. Provided what you say: +1 to Tibbs' initial proposal on banning Requires(hint) Rationale: It's undocumented, error-prone pollution to spec files, which is likely to show harmful effects once rpm/yum/apt etc. should start support it. Ralf From chris.stone at gmail.com Wed Jun 25 14:13:59 2008 From: chris.stone at gmail.com (Christopher Stone) Date: Wed, 25 Jun 2008 07:13:59 -0700 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: <1214395321.3656.244.camel@beck.corsepiu.local> References: <485FCF75.1090207@FamilleCollet.com> <1214395321.3656.244.camel@beck.corsepiu.local> Message-ID: On Wed, Jun 25, 2008 at 5:02 AM, Ralf Corsepius wrote: > On Wed, 2008-06-25 at 04:50 -0700, Christopher Stone wrote: >> On Wed, Jun 25, 2008 at 1:02 AM, Panu Matilainen >> wrote: >> > On Mon, 23 Jun 2008, Remi Collet wrote: >> > >> >> Jason L Tibbitts III a ?crit : >> >>> >> >>> I've seen packages using Requires(hint): and testing shows that >> >>> currently this is handled no differently from a regular Requires:. >> >> >> >> Using this have one usefull purpose : documentation. >> > >> > Abusing bugs in software for documentation purposes? Lets not... >> >> It works well for me, so I will continue to "abuse" the "bug" for >> documentation purposes. >> >> My personal opinion is that this thread is making a big deal out of nothing. > > Provided what you say: > +1 to Tibbs' initial proposal on banning Requires(hint) > > Rationale: It's undocumented, error-prone pollution to spec files, which > is likely to show harmful effects once rpm/yum/apt etc. should start > support it. If rpm/yum/apt ever started to support it, then that would be the greatest thing ever. Too bad that wont ever happen. From rc040203 at freenet.de Wed Jun 25 14:56:37 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 25 Jun 2008 16:56:37 +0200 Subject: [Fedora-packaging] Requires(hint): In-Reply-To: References: <485FCF75.1090207@FamilleCollet.com> <1214395321.3656.244.camel@beck.corsepiu.local> Message-ID: <1214405798.3656.332.camel@beck.corsepiu.local> On Wed, 2008-06-25 at 07:13 -0700, Christopher Stone wrote: > On Wed, Jun 25, 2008 at 5:02 AM, Ralf Corsepius wrote: > > Rationale: It's undocumented, error-prone pollution to spec files, which > > is likely to show harmful effects once rpm/yum/apt etc. should start > > support it. > > If rpm/yum/apt ever started to support it, then that would be the > greatest thing ever. Well, it would be a random accident if your constructs would match with rpm's "then syntax". E.g. openSUSE's rpm has such constructs, but they are using a different *spec-syntax. They have "Recommends:, Supplements:, Enhances:, Suggests:", not Requires(hint). > Too bad that wont ever happen. You can never be sure. openSUSE claims to be supporting them. Whether these are useful is a different matter. Ralf From enrico.scholz at informatik.tu-chemnitz.de Wed Jun 25 17:13:31 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 25 Jun 2008 19:13:31 +0200 Subject: [Fedora-packaging] Re: Requires(hint): In-Reply-To: <1214405798.3656.332.camel@beck.corsepiu.local> (Ralf Corsepius's message of "Wed, 25 Jun 2008 16:56:37 +0200") References: <485FCF75.1090207@FamilleCollet.com> <1214395321.3656.244.camel@beck.corsepiu.local> <1214405798.3656.332.camel@beck.corsepiu.local> Message-ID: <87ej6lbfpg.fsf@sheridan.bigo.ensc.de> Ralf Corsepius writes: > E.g. openSUSE's rpm has such constructs, but they are using a > different *spec-syntax. They have "Recommends:, Supplements:, > Enhances:, Suggests:", not Requires(hint). 'Suggests:' + 'Recommends:' are synonyms for 'Requires(hint)' in upstream rpm (which creates corresponding RPMTAG_SUGGESTS* tags for them). Enrico From pmatilai at laiskiainen.org Thu Jun 26 06:41:36 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 26 Jun 2008 09:41:36 +0300 (EEST) Subject: [Fedora-packaging] Re: Requires(hint): In-Reply-To: <87ej6lbfpg.fsf@sheridan.bigo.ensc.de> References: <485FCF75.1090207@FamilleCollet.com> <1214395321.3656.244.camel@beck.corsepiu.local> <1214405798.3656.332.camel@beck.corsepiu.local> <87ej6lbfpg.fsf@sheridan.bigo.ensc.de> Message-ID: On Wed, 25 Jun 2008, Enrico Scholz wrote: > Ralf Corsepius writes: > >> E.g. openSUSE's rpm has such constructs, but they are using a >> different *spec-syntax. They have "Recommends:, Supplements:, >> Enhances:, Suggests:", not Requires(hint). > > 'Suggests:' + 'Recommends:' are synonyms for 'Requires(hint)' in upstream > rpm (which creates corresponding RPMTAG_SUGGESTS* tags for them). Requires(hint) is only synonym for Requires(randomjunk) for rpm.org which is the upstream rpm for Fedora. - Panu - From spencercw at googlemail.com Thu Jun 26 12:29:34 2008 From: spencercw at googlemail.com (Chris Spencer) Date: Thu, 26 Jun 2008 13:29:34 +0100 Subject: [Fedora-packaging] moc, moc-qt4? Message-ID: <48638BAE.9050209@googlemail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, I am developing a program and have begun testing it on other distributions, however I am having some trouble getting it to compile on Fedora. The configure script checks for the program 'moc' and fails if it doesn't find it. I have installed the qt-devel package, but for some reason it installs moc as moc-qt4, no symlink or anything. Can anyone explain to me why this is, and possibly suggest a suitable workaround? Cheers. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhji64ACgkQ6iqRtkAADZjcJwCdE9SX7+rtJ6yBDYyMZddZ3pra KVMAoPatrn0RO+ohfDAFBgMBMDLR1zYA =ZF06 -----END PGP SIGNATURE----- From rdieter at math.unl.edu Thu Jun 26 13:42:23 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Jun 2008 08:42:23 -0500 Subject: [Fedora-packaging] moc, moc-qt4? In-Reply-To: <48638BAE.9050209@googlemail.com> References: <48638BAE.9050209@googlemail.com> Message-ID: <48639CBF.3070801@math.unl.edu> Chris Spencer wrote: > I am developing a program and have begun testing it on other > distributions, however I am having some trouble getting it to compile on > Fedora. > > The configure script checks for the program 'moc' and fails if it > doesn't find it. I have installed the qt-devel package, but for some > reason it installs moc as moc-qt4, no symlink or anything. Can anyone > explain to me why this is, and possibly suggest a suitable workaround? qt3 moc or qt4 moc? (I'll assume the latter). If building rpms: Put in specfile: export PATH=%{_qt4_bindir}:$PATH and/or (this sometimes helps): export MOC=%{_qt4_bindir}/moc See /etc/rpm/macros.qt4 for other useful goodies. -- Rex From spencercw at googlemail.com Thu Jun 26 13:54:04 2008 From: spencercw at googlemail.com (Chris Spencer) Date: Thu, 26 Jun 2008 14:54:04 +0100 Subject: [Fedora-packaging] moc, moc-qt4? In-Reply-To: <48639CBF.3070801@math.unl.edu> References: <48638BAE.9050209@googlemail.com> <48639CBF.3070801@math.unl.edu> Message-ID: <48639F7C.5040902@googlemail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rex, Yes, I am building for Qt4. Currently I am not in the packaging stage, I am simply installing various distributions on VMware and running the standard ./configure; make; make install to make sure everything works. Inevitably there will be slight differences between distros that will cause problems. Once I have got these issues ironed out I will start packaging it up in rpms, debs, whatever. I think the easiest thing to do would probably be to just add another check for 'moc-qt4' and fail if it doesn't find either. I guess what I'm really asking is why it was done like this? Developers expect it to be under the name 'moc', renaming it without even a symlink is just going to create problems. Rex Dieter wrote: | Chris Spencer wrote: | |> I am developing a program and have begun testing it on other |> distributions, however I am having some trouble getting it to compile on |> Fedora. |> |> The configure script checks for the program 'moc' and fails if it |> doesn't find it. I have installed the qt-devel package, but for some |> reason it installs moc as moc-qt4, no symlink or anything. Can anyone |> explain to me why this is, and possibly suggest a suitable workaround? | | qt3 moc or qt4 moc? (I'll assume the latter). | | If building rpms: | Put in specfile: | export PATH=%{_qt4_bindir}:$PATH | | and/or (this sometimes helps): | export MOC=%{_qt4_bindir}/moc | | See /etc/rpm/macros.qt4 for other useful goodies. | | -- Rex | | -- | Fedora-packaging mailing list | Fedora-packaging at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-packaging -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhjn3wACgkQ6iqRtkAADZjkiACeOiKm0agijmb0B54oCPZtKYpL SpkAoMypC68GROH9Fuqcon2r6MkIW6Bk =nBaL -----END PGP SIGNATURE----- From rdieter at math.unl.edu Thu Jun 26 13:59:46 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Jun 2008 08:59:46 -0500 Subject: [Fedora-packaging] Re: moc, moc-qt4? References: <48638BAE.9050209@googlemail.com> <48639CBF.3070801@math.unl.edu> <48639F7C.5040902@googlemail.com> Message-ID: Chris Spencer wrote: > I think the easiest thing to do would probably be to just add another > check for 'moc-qt4' and fail if it doesn't find either. I guess what I'm > really asking is why it was done like this? Developers expect it to be > under the name 'moc', renaming it without even a symlink is just going > to create problems. Both qt3 and qt4 provide "moc" (there are other dups, but let's still with this example). So, a convention that most distros use is to ship moc-qt3 and moc-qt4 (and possibly a 'moc' pointing to one of those). -- Rex From spencercw at googlemail.com Thu Jun 26 14:12:35 2008 From: spencercw at googlemail.com (Chris Spencer) Date: Thu, 26 Jun 2008 15:12:35 +0100 Subject: [Fedora-packaging] Re: moc, moc-qt4? In-Reply-To: References: <48638BAE.9050209@googlemail.com> <48639CBF.3070801@math.unl.edu> <48639F7C.5040902@googlemail.com> Message-ID: <4863A3D3.5020805@googlemail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes that makes sense, I suppose what I will do then is look for 'moc-qt4' first, then just 'moc'. However, it would probably be advantageous for Fedora to include a symlink between moc and moc-qt4, perhaps with some mechanism to switch between that and moc-qt3. Anyway, thanks for your help. Chris. Rex Dieter wrote: | Chris Spencer wrote: | | |> I think the easiest thing to do would probably be to just add another |> check for 'moc-qt4' and fail if it doesn't find either. I guess what I'm |> really asking is why it was done like this? Developers expect it to be |> under the name 'moc', renaming it without even a symlink is just going |> to create problems. | | Both qt3 and qt4 provide "moc" (there are other dups, but let's still with | this example). So, a convention that most distros use is to ship moc-qt3 | and moc-qt4 (and possibly a 'moc' pointing to one of those). | | -- Rex | | -- | Fedora-packaging mailing list | Fedora-packaging at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-packaging -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhjo9IACgkQ6iqRtkAADZjFKgCgiw2mX+gGojlO9K2uvvI2S9dR cDsAn17XlpIKfYl6jzdNMIEL4iZcITIV =Oh1M -----END PGP SIGNATURE----- From rdieter at math.unl.edu Thu Jun 26 14:20:37 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Jun 2008 09:20:37 -0500 Subject: [Fedora-packaging] Re: moc, moc-qt4? In-Reply-To: <4863A3D3.5020805@googlemail.com> References: <48638BAE.9050209@googlemail.com> <48639CBF.3070801@math.unl.edu> <48639F7C.5040902@googlemail.com> <4863A3D3.5020805@googlemail.com> Message-ID: <4863A5B5.50408@math.unl.edu> Chris Spencer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Yes that makes sense, I suppose what I will do then is look for > 'moc-qt4' first, then just 'moc'. However, it would probably be > advantageous for Fedora to include a symlink between moc and moc-qt4, > perhaps with some mechanism to switch between that and moc-qt3. For F-10 (and previous fedora's when qt-4.4/kde-4.1 is released), the default moc will be qt4's instead of qt(3)'s. -- Rex From enrico.scholz at informatik.tu-chemnitz.de Thu Jun 26 14:36:39 2008 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 26 Jun 2008 16:36:39 +0200 Subject: [Fedora-packaging] Re: moc, moc-qt4? In-Reply-To: <48638BAE.9050209@googlemail.com> (Chris Spencer's message of "Thu, 26 Jun 2008 13:29:34 +0100") References: <48638BAE.9050209@googlemail.com> Message-ID: <87ej6ke008.fsf@fc5.bigo.ensc.de> Chris Spencer writes: > The configure script checks for the program 'moc' and fails if it > doesn't find it. I have installed the qt-devel package, but for some > reason it installs moc as moc-qt4, no symlink or anything. Can anyone > explain to me why this is, and possibly suggest a suitable workaround? Use | PKG_CHECK_MODULES(QT, Qt) | QT4_BINDIR=`$PKG_CONFIG Qt --variable bindir` | AC_CHECK_TOOLS(MOC, [moc],, [$QT4_BINDIR:$PATH]) This gives most flexibility by using proper defaults while allowing users to override detected tool by setting $MOC environment/autoconf variable. Enrico From rdieter at math.unl.edu Thu Jun 26 15:50:14 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Jun 2008 10:50:14 -0500 Subject: [Fedora-packaging] Re: moc, moc-qt4? References: <48638BAE.9050209@googlemail.com> <87ej6ke008.fsf@fc5.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > Chris Spencer writes: > >> The configure script checks for the program 'moc' and fails if it >> doesn't find it. I have installed the qt-devel package, but for some >> reason it installs moc as moc-qt4, no symlink or anything. Can anyone >> explain to me why this is, and possibly suggest a suitable workaround? > > Use > > | PKG_CHECK_MODULES(QT, Qt) > | QT4_BINDIR=`$PKG_CONFIG Qt --variable bindir` > | AC_CHECK_TOOLS(MOC, [moc],, [$QT4_BINDIR:$PATH]) > > This gives most flexibility by using proper defaults while allowing > users to override detected tool by setting $MOC environment/autoconf > variable. Be warned, however, that the Qt.pc file as distributed in fedora, is not yet upstreamed and is fedora-specific. Hope to rectify that soonish. -- Rex From spencercw at googlemail.com Thu Jun 26 16:14:47 2008 From: spencercw at googlemail.com (Chris Spencer) Date: Thu, 26 Jun 2008 17:14:47 +0100 Subject: [Fedora-packaging] Re: moc, moc-qt4? In-Reply-To: References: <48638BAE.9050209@googlemail.com> <87ej6ke008.fsf@fc5.bigo.ensc.de> Message-ID: <4863C077.4070504@googlemail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Right, in that case I'll stick to my current method. I have set it to look for moc-qt4 first, and then moc if it can't find it, and this works fine. Thanks for the suggestion though Enrico. Chris. Rex Dieter wrote: | Enrico Scholz wrote: | |> Use |> |> | PKG_CHECK_MODULES(QT, Qt) |> | QT4_BINDIR=`$PKG_CONFIG Qt --variable bindir` |> | AC_CHECK_TOOLS(MOC, [moc],, [$QT4_BINDIR:$PATH]) |> |> This gives most flexibility by using proper defaults while allowing |> users to override detected tool by setting $MOC environment/autoconf |> variable. | | Be warned, however, that the Qt.pc file as distributed in fedora, is not yet | upstreamed and is fedora-specific. Hope to rectify that soonish. | | -- Rex | | -- | Fedora-packaging mailing list | Fedora-packaging at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-packaging -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhjwHcACgkQ6iqRtkAADZi+gACg+jZ1ZqlFhWSx+f4V9K9XE1WO Y1MAnjMDeTbTQ9kOutJ6KeIjHRUIB0Bh =XNux -----END PGP SIGNATURE----- From linuxkernel at edcint.co.nz Thu Jun 26 23:40:29 2008 From: linuxkernel at edcint.co.nz (Matthew Jurgens) Date: Fri, 27 Jun 2008 09:40:29 +1000 Subject: [Fedora-packaging] Packaging of Nagios Message-ID: <486428ED.6080607@edcint.co.nz> I am waiting for the release of the fedora Nagios package and was wondering if I could get involved to help speed up the process? From linuxkernel at edcint.co.nz Thu Jun 26 23:44:14 2008 From: linuxkernel at edcint.co.nz (Matthew Jurgens) Date: Fri, 27 Jun 2008 09:44:14 +1000 Subject: [Fedora-packaging] [Fwd: Packaging of Nagios] Message-ID: <486429CE.4070008@edcint.co.nz> I am referring to Nagios v3 From linuxkernel at edcint.co.nz Thu Jun 26 23:46:10 2008 From: linuxkernel at edcint.co.nz (Matthew Jurgens) Date: Fri, 27 Jun 2008 09:46:10 +1000 Subject: [Fedora-packaging] Packaging of Nagios In-Reply-To: <486428ED.6080607@edcint.co.nz> References: <486428ED.6080607@edcint.co.nz> Message-ID: <48642A42.1090801@edcint.co.nz> I am referring to Nagios v3 From rdieter at math.unl.edu Thu Jun 26 23:51:51 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 26 Jun 2008 18:51:51 -0500 Subject: [Fedora-packaging] Packaging of Nagios In-Reply-To: <486428ED.6080607@edcint.co.nz> References: <486428ED.6080607@edcint.co.nz> Message-ID: <48642B97.9020004@math.unl.edu> Matthew Jurgens wrote: > I am waiting for the release of the fedora Nagios package and was > wondering if I could get involved to help speed up the process? This list is for discussing fedora packaging policy and guidelines. Contacting the maintainer, filing a bug, or asking on fedora-devel list would get you closer to what you're after. :) -- Rex From tibbs at math.uh.edu Sat Jun 28 22:15:48 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jun 2008 17:15:48 -0500 Subject: [Fedora-packaging] Ownership of /etc/maven/fragments and /usr/share/maven2/poms Message-ID: I hope I'm CC'ing this sufficiently; I do not know if any representatives form the Java group are members of fedora-packaging. I was reviewing my first maven-using package and ran into an issue with the Java packaging guidelines. Namely that they specify that every maven-using package should own /etc/maven/fragments and /usr/share/maven2/poms, which contradicts our usual policy on directory ownership by multiple packages. I don't really understand why the packages would need to own those directories; jpackage-utils already serves as a kind of filesystem package for java, it already owns /etc/maven and several java-related directories in /usr/share, and all of the packages which would own files in the two directories at issue already depend on it. So I think jpackage-utils should just own /etc/maven/fragments and /usr/share/maven2/poms and we can tweak the guidelines to not specify that the individual packages own these directory. Another possibility would be to shift this off to a java-filesystem package analogous to our other *-filesystem packages which could own these and various other java directories. This would fix ownership issues for 22 packages currently. Another separate bug related issue is the fact that the contents of /etc/maven/fragments do not seem to be configuration files, and so probably should not live under /etc. I do not have sufficient Java knowledge to propose a solution, however. - J< From tibbs at math.uh.edu Sat Jun 28 22:22:51 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jun 2008 17:22:51 -0500 Subject: [Fedora-packaging] Ownership of /etc/maven/fragments and /usr/share/maven2/poms Message-ID: Sorry for the resend; this should have the correct address for the java list. I hope I'm CC'ing this sufficiently; I do not know if any representatives form the Java group are members of fedora-packaging. I was reviewing my first maven-using package and ran into an issue with the Java packaging guidelines. Namely that they specify that every maven-using package should own /etc/maven/fragments and /usr/share/maven2/poms, which contradicts our usual policy on directory ownership by multiple packages. I don't really understand why the packages would need to own those directories; jpackage-utils already serves as a kind of filesystem package for java, it already owns /etc/maven and several java-related directories in /usr/share, and all of the packages which would own files in the two directories at issue already depend on it. So I think jpackage-utils should just own /etc/maven/fragments and /usr/share/maven2/poms and we can tweak the guidelines to not specify that the individual packages own these directory. Another possibility would be to shift this off to a java-filesystem package analogous to our other *-filesystem packages which could own these and various other java directories. This would fix ownership issues for 22 packages currently. Another separate bug related issue is the fact that the contents of /etc/maven/fragments do not seem to be configuration files, and so probably should not live under /etc. I do not have sufficient Java knowledge to propose a solution, however. - J< From nicolas.mailhot at laposte.net Sat Jun 28 22:40:06 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 29 Jun 2008 00:40:06 +0200 Subject: [Fwd: [Fedora-packaging] Ownership of /etc/maven/fragments and /usr/share/maven2/poms] Message-ID: <1214692806.3166.1.camel@rousalka.okg> [adding jpp-discuss to the list] -------- Message transf?r? -------- De: Jason L Tibbitts III Sujet: [Fedora-packaging] Ownership of /etc/maven/fragments and /usr/share/maven2/poms Date: 28 Jun 2008 17:22:51 -0500 Sorry for the resend; this should have the correct address for the java list. I hope I'm CC'ing this sufficiently; I do not know if any representatives form the Java group are members of fedora-packaging. I was reviewing my first maven-using package and ran into an issue with the Java packaging guidelines. Namely that they specify that every maven-using package should own /etc/maven/fragments and /usr/share/maven2/poms, which contradicts our usual policy on directory ownership by multiple packages. I don't really understand why the packages would need to own those directories; jpackage-utils already serves as a kind of filesystem package for java, it already owns /etc/maven and several java-related directories in /usr/share, and all of the packages which would own files in the two directories at issue already depend on it. So I think jpackage-utils should just own /etc/maven/fragments and /usr/share/maven2/poms and we can tweak the guidelines to not specify that the individual packages own these directory. Another possibility would be to shift this off to a java-filesystem package analogous to our other *-filesystem packages which could own these and various other java directories. This would fix ownership issues for 22 packages currently. Another separate bug related issue is the fact that the contents of /etc/maven/fragments do not seem to be configuration files, and so probably should not live under /etc. I do not have sufficient Java knowledge to propose a solution, however. - J< -- Fedora-packaging mailing list Fedora-packaging at redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging -- 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 dbhole at redhat.com Mon Jun 30 16:53:43 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 30 Jun 2008 12:53:43 -0400 Subject: [Fedora-packaging] Re: Ownership of /etc/maven/fragments and /usr/share/maven2/poms In-Reply-To: References: Message-ID: <20080630165342.GC3851@redhat.com> * Jason L Tibbitts III [2008-06-28 18:23]: > Sorry for the resend; this should have the correct address for the > java list. > > I hope I'm CC'ing this sufficiently; I do not know if any > representatives form the Java group are members of fedora-packaging. > > I was reviewing my first maven-using package and ran into an issue > with the Java packaging guidelines. Namely that they specify that > every maven-using package should own /etc/maven/fragments and > /usr/share/maven2/poms, which contradicts our usual policy on > directory ownership by multiple packages. > > I don't really understand why the packages would need to own those > directories; jpackage-utils already serves as a kind of filesystem > package for java, it already owns /etc/maven and several > java-related directories in /usr/share, and all of the packages which > would own files in the two directories at issue already depend on it. > So I think jpackage-utils should just own /etc/maven/fragments and > /usr/share/maven2/poms and we can tweak the guidelines to not specify > that the individual packages own these directory. > > Another possibility would be to shift this off to a java-filesystem > package analogous to our other *-filesystem packages which could own > these and various other java directories. > I think moving them to jpackage-utils would be sufficient, as it owns a multitude of other java related directories right now. I have put this down on my TODO list and will get to it on Monday (off today and tomorrow). > This would fix ownership issues for 22 packages currently. > > Another separate bug related issue is the fact that the contents of > /etc/maven/fragments do not seem to be configuration files, and so > probably should not live under /etc. I do not have sufficient Java > knowledge to propose a solution, however. > Correct, technically they are not configuration related files. I'd be happy to move them, but I am not sure what the best place for them is either :/ .. suggestions are welcome. The files serve as configuration in the sense that they provide maven with a "mapping" between where maven expects jars to be, and where they actually are on the system. Cheers, Deepak From dbhole at redhat.com Mon Jun 30 17:09:03 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 30 Jun 2008 13:09:03 -0400 Subject: [Fedora-packaging] Re: [fedora-java] Re: Ownership of /etc/maven/fragments and /usr/share/maven2/poms In-Reply-To: <48691217.8080606@zarb.org> References: <20080630165342.GC3851@redhat.com> <48691217.8080606@zarb.org> Message-ID: <20080630170903.GH3851@redhat.com> * David Walluck [2008-06-30 13:04]: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Deepak Bhole wrote: > | I think moving them to jpackage-utils would be sufficient, as it owns a > | multitude of other java related directories right now. I have put this > > I agree. This is consistent since %{_sysconfdir}/maven is already owned > by jpackage-utils. > > | Correct, technically they are not configuration related files. I'd be > happy to > > Config files are specified to always have %config(noreplace) (in my > rpmlint anyway). So, unless they are user-editable files that can be > kept between upgrades, then they should be moved. I think that since > these files aren't meant to be editable and in fact must be kept in sync > with package upgrades they are not proper config files and should be moved. > > | move them, but I am not sure what the best place for them is either :/ .. > | suggestions are welcome. The files serve as configuration in the sense > | that they provide maven with a "mapping" between where maven expects > | jars to be, and where they actually are on the system. > > The obvious choice seems to be %{_datadir}/maven2/fragments and most > other files appear to be in %{_datadir}/maven2. > Yep I am fine with this. I will make the change for the next version. A change of this sort will require rebuild of all maven2 dependent packages. > The important thing besides single ownership by jpackage-utils is to > move the maven macros into jpackage.macros so that you don't have to > change every spec just to change the location of the files. > The fragment dir location is already a macros, and all maven related macros are in jpackage-utils already. Cheers, Deepak > - -- > Sincerely, > > David Walluck > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iEYEARECAAYFAkhpEhYACgkQItObMyg2XCVcZwCgsmj7Go0jDO5YjRb2s/5iKsxp > HYUAn21+dloZoJ3A0boYwr3nqfaGuWy1 > =M/Pp > -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Mon Jun 30 17:10:19 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 30 Jun 2008 19:10:19 +0200 Subject: [Fedora-packaging] Re: Ownership of /etc/maven/fragments and /usr/share/maven2/poms In-Reply-To: <20080630165342.GC3851@redhat.com> References: <20080630165342.GC3851@redhat.com> Message-ID: <1214845819.24148.3.camel@rousalka.okg> Le lundi 30 juin 2008 ? 12:53 -0400, Deepak Bhole a ?crit : > I think moving them to jpackage-utils would be sufficient, as it owns a > multitude of other java related directories right now. If it's ok for files to exist in those directories without maven being present on-system, they belong in jpp-utils. If you require maven presence before allowing a package to drop content there, they belong in the maven package > I have put this > down on my TODO list and will get to it on Monday (off today and > tomorrow). > > > This would fix ownership issues for 22 packages currently. > > > > Another separate bug related issue is the fact that the contents of > > /etc/maven/fragments do not seem to be configuration files, and so > > probably should not live under /etc. I do not have sufficient Java > > knowledge to propose a solution, however. > > > > Correct, technically they are not configuration related files. I'd be happy to > move them, but I am not sure what the best place for them is either :/ .. > suggestions are welcome. /var/lib/maven should be ok. Owned by the maven package -- 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: