From ville.skytta at iki.fi Thu Jan 1 19:09:21 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 1 Jan 2009 21:09:21 +0200 Subject: [Fedora-packaging] Re: fontpackages template warnings In-Reply-To: <937de2565ad43ad918ed7c6e1f296ee8.squirrel@arekh.dyndns.org> References: <20081230142910.GA29904@gallagher.di.uoa.gr> <9d8b98149e12fc36d76c5a2cc35b1d61.squirrel@arekh.dyndns.org> <937de2565ad43ad918ed7c6e1f296ee8.squirrel@arekh.dyndns.org> Message-ID: <200901012109.21924.ville.skytta@iki.fi> On Tuesday 30 December 2008, Nicolas Mailhot wrote: [...] Sorry for hijacking the thread for something quite unrelated, but for me the "fontpackages" package name sounds pretty weird. I think similar packages are usually called foo-common; was "fonts-common" ever considered? From nicolas.mailhot at laposte.net Fri Jan 2 11:18:40 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 02 Jan 2009 12:18:40 +0100 Subject: [Fedora-packaging] Re: fontpackages template warnings In-Reply-To: <200901012109.21924.ville.skytta@iki.fi> References: <20081230142910.GA29904@gallagher.di.uoa.gr> <9d8b98149e12fc36d76c5a2cc35b1d61.squirrel@arekh.dyndns.org> <937de2565ad43ad918ed7c6e1f296ee8.squirrel@arekh.dyndns.org> <200901012109.21924.ville.skytta@iki.fi> Message-ID: <1230895120.26738.14.camel@arekh.okg> Le jeudi 01 janvier 2009 ? 21:09 +0200, Ville Skytt? a ?crit : > On Tuesday 30 December 2008, Nicolas Mailhot wrote: > [...] Hi > Sorry for hijacking the thread for something quite unrelated, np > but for me > the "fontpackages" package name sounds pretty weird. I think similar > packages are usually called foo-common; was "fonts-common" ever considered? I rather like the way it expands in nice self-explanatory fontpackages-filesystem and fontpackages-devel binary packages. It has some consistency with fontconfig (which felt strange at first when it was introduced too). Also, I'd rather avoid any name with the fonts- or -fonts affix as those denote past and present font packages and this package has not fonts at all inside it. Anyway, the project was originally named rpmfonts, and then during review people asked for a name change (various abandonned proposals: fonts-rpm, fonts, etc). So it was already renamed once. Since the package name translates in a fedorahosted project name, a FAS group name, is used in the templates which have already been applied to more than 30 packages, is used in wiki documentation, I'm not thrilled at the idea of doing another renaming. But I will do it if people want to and someone finds an awesome new name. I'm not convinced fonts-common is such a name :p Happy new year, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Fri Jan 2 12:05:21 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 02 Jan 2009 13:05:21 +0100 Subject: [Fedora-packaging] Re: fontpackages template warnings In-Reply-To: <20081231100007.GA4926@gallagher.di.uoa.gr> References: <20081230142910.GA29904@gallagher.di.uoa.gr> <9d8b98149e12fc36d76c5a2cc35b1d61.squirrel@arekh.dyndns.org> <937de2565ad43ad918ed7c6e1f296ee8.squirrel@arekh.dyndns.org> <20081231100007.GA4926@gallagher.di.uoa.gr> Message-ID: <1230897921.26738.17.camel@arekh.okg> > > > Le Mar 30 d?cembre 2008 15:29, Sarantis Paskalis a ?crit : > > >> I am converting my font packages to the new guidelines and hit some > > >> rpmlint warnings that appear to be template related. Anyway I've queued the following FPC-side so they can rule one way or the other. I'll just apply whatever they decide. http://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_(2009-01-02) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Fri Jan 2 17:26:28 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Fri, 2 Jan 2009 19:26:28 +0200 Subject: [Fedora-packaging] Re: fontpackages template warnings In-Reply-To: <1230895120.26738.14.camel@arekh.okg> References: <20081230142910.GA29904@gallagher.di.uoa.gr> <200901012109.21924.ville.skytta@iki.fi> <1230895120.26738.14.camel@arekh.okg> Message-ID: <200901021926.29212.ville.skytta@iki.fi> On Friday 02 January 2009, you wrote: > Le jeudi 01 janvier 2009 ? 21:09 +0200, Ville Skytt? a ?crit : > > > but for me > > the "fontpackages" package name sounds pretty weird. I think similar > > packages are usually called foo-common; was "fonts-common" ever > > considered? > > I rather like the way it expands in nice self-explanatory > fontpackages-filesystem and fontpackages-devel binary packages. Oops, sorry, I hadn't noticed that there's no main package. -filesystem and -devel don't sound bad/odd at all - the scenario I would have found quite weird would have been if one would for some reason explicitly install a package called fontpackages and get no font packages installed. From henriquecsj at gmail.com Tue Jan 6 01:14:46 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Mon, 5 Jan 2009 23:14:46 -0200 Subject: [Fedora-packaging] How to create a .spec file for a software that user cmake? Message-ID: <4f629b520901051714v1b6e945eua00ba74fb7b251a7@mail.gmail.com> Hi folks, I'm trying to package a software that use cmake to be build. In the process the software (octaviz) asks me to do this: - run ccmake . in Octaviz root directory - press "c" to configure - press "g" to generate Makefiles - press "q" to quit ccmake - run make - make install Can someone give me a hint on the correct way that my %build section needs to be? Thanks -- Henrique "LonelySpooky" Junior http://www.lonelyspooky.com ------------------------------------------------------------- "In a world without walls and fences, who needs windows and gates?!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Tue Jan 6 01:19:37 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 05 Jan 2009 17:19:37 -0800 Subject: [Fedora-packaging] How to create a .spec file for a software that user cmake? In-Reply-To: <4f629b520901051714v1b6e945eua00ba74fb7b251a7@mail.gmail.com> References: <4f629b520901051714v1b6e945eua00ba74fb7b251a7@mail.gmail.com> Message-ID: <4962B1A9.9080803@gmail.com> Henrique Junior wrote: > Hi folks, > I'm trying to package a software that use cmake to be build. > In the process the software (octaviz) asks me to do this: > - run ccmake . in Octaviz root directory > - press "c" to configure > - press "g" to generate Makefiles > - press "q" to quit ccmake > - run make > - make install > Can someone give me a hint on the correct way that my %build section > needs to be? > Have you seen this page already? https://fedoraproject.org/wiki/Packaging/cmake -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 henriquecsj at gmail.com Tue Jan 6 02:12:52 2009 From: henriquecsj at gmail.com (Henrique Junior) Date: Mon, 5 Jan 2009 18:12:52 -0800 (PST) Subject: Res: [Fedora-packaging] How to create a .spec file for a software that user cmake? References: <4f629b520901051714v1b6e945eua00ba74fb7b251a7@mail.gmail.com> <4962B1A9.9080803@gmail.com> Message-ID: <365186.73134.qm@web45411.mail.sp1.yahoo.com> No, Toshio. I completely missed it. I'm on it right now. Thank you Henrique "LonelySpooky" Junior ------------------------------ "In a world without walls and fences, who needs windows and gates?!" ----- Mensagem original ---- > De: Toshio Kuratomi > Para: henrique_csj at yahoo.com.br; Discussion of RPM packaging standards and practices for Fedora > Enviadas: Segunda-feira, 5 de Janeiro de 2009 23:19:37 > Assunto: Re: [Fedora-packaging] How to create a .spec file for a software that user cmake? > > Henrique Junior wrote: > > Hi folks, > > I'm trying to package a software that use cmake to be build. > > In the process the software (octaviz) asks me to do this: > > - run ccmake . in Octaviz root directory > > - press "c" to configure > > - press "g" to generate Makefiles > > - press "q" to quit ccmake > > - run make > > - make install > > Can someone give me a hint on the correct way that my %build section > > needs to be? > > > Have you seen this page already? > > https://fedoraproject.org/wiki/Packaging/cmake > > -Toshio Veja quais s?o os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com From j.w.r.degoede at hhs.nl Tue Jan 6 15:01:13 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 06 Jan 2009 16:01:13 +0100 Subject: [Fedora-packaging] Won't be making the FPC meeting tonight Message-ID: <49637239.4020606@hhs.nl> Hi all, As discussed before 18:00 CET is a really bad time for me (kids need to get them from daycare, feed them etc, all around this time). So I won't be attending the meeting tonight. Regards, Hans From dominik at greysector.net Tue Jan 6 18:02:02 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 6 Jan 2009 19:02:02 +0100 Subject: [Fedora-packaging] Won't be making the FPC meeting tonight In-Reply-To: <49637239.4020606@hhs.nl> References: <49637239.4020606@hhs.nl> Message-ID: <20090106180202.GA5797@mokona.greysector.net> On Tuesday, 06 January 2009 at 16:01, Hans de Goede wrote: > Hi all, > > As discussed before 18:00 CET is a really bad time for me (kids need to get > them from daycare, feed them etc, all around this time). > > So I won't be attending the meeting tonight. And I was stuck in a traffic jam, sorry. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From katzj at redhat.com Tue Jan 6 20:03:17 2009 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jan 2009 15:03:17 -0500 Subject: [Fedora-packaging] Re: Summary of the 2009-01-06 Packaging Committee meeting In-Reply-To: References: Message-ID: <1231272197.24873.39.camel@erebor.bos.redhat.com> On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote: > * Use of absolute symlinks in packages - > http://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_%282009-01-02%29 > o Turns out that rpm can be made to convert all symlinks to relative > ones transparently, so that's being experimented with first. So, at least as it stands right now, this can't easily be done with symlinks(8) symlinks -c will convert an absolute into a relative link, but the problem is that the absolute link is something like /usr/bin/barz -> /usr/bin/foo Since /usr/bin/foo only exists under $RPM_BUILD_ROOT, $RPM_BUILD_ROOT/usr/bin/barz looks like a dangling symlink (there is no real /usr/bin/foo) and thus symlinks won't convert it to a relative symlink. The thing that obviously pops to mind then would be to do a chroot into $RPM_BUILD_ROOT, but that would a) require symlinks under $RPM_BUILD_ROOT and b) require root to do chroot(2). So to get this to work will at the very least require a fair bit more scripting "fun" :/ Jeremy From paul at city-fan.org Tue Jan 6 20:20:08 2009 From: paul at city-fan.org (Paul Howarth) Date: Tue, 6 Jan 2009 20:20:08 +0000 Subject: [Fedora-packaging] Re: Summary of the 2009-01-06 Packaging Committee meeting In-Reply-To: <1231272197.24873.39.camel@erebor.bos.redhat.com> References: <1231272197.24873.39.camel@erebor.bos.redhat.com> Message-ID: <20090106202008.40640ea4@city-fan.org> On Tue, 06 Jan 2009 15:03:17 -0500 Jeremy Katz wrote: > On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote: > > * Use of absolute symlinks in packages - > > http://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_%282009-01-02%29 > > o Turns out that rpm can be made to convert all symlinks to > > relative ones transparently, so that's being experimented with > > first. > > So, at least as it stands right now, this can't easily be done with > symlinks(8) > > symlinks -c will convert an absolute into a relative link, but the > problem is that the absolute link is something like > /usr/bin/barz -> /usr/bin/foo > > Since /usr/bin/foo only exists under $RPM_BUILD_ROOT, > $RPM_BUILD_ROOT/usr/bin/barz looks like a dangling symlink (there is > no real /usr/bin/foo) and thus symlinks won't convert it to a relative > symlink. > > The thing that obviously pops to mind then would be to do a chroot > into $RPM_BUILD_ROOT, but that would a) require symlinks under > $RPM_BUILD_ROOT and b) require root to do chroot(2). > > So to get this to work will at the very least require a fair bit more > scripting "fun" :/ For symlinks that are created using "ln -s" in the install phase of the rpm build, this is trivially fixed by making the absolute symlink point to inside the buildroot, e.g. by changing: ln -s /path/to/target %{buildroot}/path/to/source to: ln -s %{buildroot}/path/to/target %{buildroot}/path/to/source and then using "symlinks -c" to convert it to a relative link. Symlinks created using e.g. an upstream Makefile are of course somewhat harder to fix. Paul. From katzj at redhat.com Tue Jan 6 20:20:07 2009 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 06 Jan 2009 15:20:07 -0500 Subject: [Fedora-packaging] Re: Summary of the 2009-01-06 Packaging Committee meeting In-Reply-To: <20090106202008.40640ea4@city-fan.org> References: <1231272197.24873.39.camel@erebor.bos.redhat.com> <20090106202008.40640ea4@city-fan.org> Message-ID: <1231273207.24873.53.camel@erebor.bos.redhat.com> On Tue, 2009-01-06 at 20:20 +0000, Paul Howarth wrote: > On Tue, 06 Jan 2009 15:03:17 -0500 Jeremy Katz wrote: > > On Tue, 2009-01-06 at 13:16 -0600, Jason L Tibbitts III wrote: > > > * Use of absolute symlinks in packages - > > > http://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_%282009-01-02%29 > > > o Turns out that rpm can be made to convert all symlinks to > > > relative ones transparently, so that's being experimented with > > > first. > > > > So, at least as it stands right now, this can't easily be done with > > symlinks(8) [snip] > For symlinks that are created using "ln -s" in the install phase of the > rpm build, this is trivially fixed by making the absolute symlink point > to inside the buildroot, e.g. by changing: Sure, but if we're going to dictate changes, let's say they should be changed to what we want :-) Jeremy From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 7 08:49:46 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Jan 2009 09:49:46 +0100 Subject: [Fedora-packaging] Re: Summary of the 2009-01-06 Packaging Committee meeting In-Reply-To: (Jason L. Tibbitts, III's message of "06 Jan 2009 13:16:59 -0600") References: Message-ID: <87ocyj4i1h.fsf@sheridan.bigo.ensc.de> Jason L Tibbitts III writes: > * Use of absolute symlinks in packages - > http://fedoraproject.org/wiki/PackagingDrafts/Absolute_symlinks_in_fonts_templates_%282009-01-02%29 > o Turns out that rpm can be made to convert all symlinks to relative > ones transparently, so that's being experimented with first. Bad idea; relative symlinks pointing to '../' will break when you are in a symlinked directory. E.g. 'ln -s ../passwd /etc/init.d/foo' points to /etc/rc.d/passwd, not to /etc/passwd. It's an arbitrary example; a more realistic one might be a symlink to /usr/libexec/some-init-wrapper. Enrico From loupgaroublond at gmail.com Wed Jan 7 16:54:12 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 7 Jan 2009 11:54:12 -0500 Subject: [Fedora-packaging] Update guidelines for using darcs based sources in packages Message-ID: <7f692fec0901070854j5d9fd99ax97ff8bc8ab09d643@mail.gmail.com> Hi List, (Packaging list, i'm double posting because i want you guys to see this, but please put further comments on the haskell list :) ) Because the macros, last i checked were for ghc 6.10.1, some of the packages i'm still working on will only compile from darcs. I've put together a tool to help with development of packages from darcs, and i'm looking for a standardized way to note which revision from darcs is being used. Darcs has two relatively canonical ways to refer to a package, with a hash and a timestamp. Internally this tool uses both. Judging from the different ways people note svn/git/other usage in fedora packages, i've put together a few recommendations that we can use for a standard. Keep in mind, my goal is to support darcs, so please be nitpicky about these details. Just keep in mind, this is easily bikesheddable, and all i want to do is support darcs based packages systematically. Normal Haskell Tarball name: %{hackage_name}-%{version}.tar.gz Output from darcs: %{hackage_name}-%{version}.%{timestamp_from_darcs}darcs.tar.gz Accesible from: darcs dist -d %{hackage_name}-%{version}.%{timestamp_from_darcs}darcs Timestamp accessible from darcs changes --xml-output --last=1 To note this in the rpm Normal Dist: 1%{?dist} Darcs Dist 1.%{timestamp_from_darcs}darcs%{?dist} I've attached a patch to the templates that puts in a placeholder to make it clearer how to do things. Note that in the timestamp i've added . and darcs systematically. Since the macro %dist includes the . prefix, as a matter of precedent, i've noted that we should just use the prefix and suffix in the %darcs macro as well. Also, the names of everything here is not so important. What's important is that i want to take a spec file that's been generated by cabal2spec, run it through a quick sed-like script that will append the correct darcs timestamp. Darcs doesn't make the timestamps that easily available, and i'm trying to automate a few things here. Cheers, Yaakov -------------- next part -------------- A non-text attachment was scrubbed... Name: templates.patch Type: application/octet-stream Size: 3397 bytes Desc: not available URL: From a.badger at gmail.com Wed Jan 7 19:09:39 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 07 Jan 2009 11:09:39 -0800 Subject: [Fedora-packaging] Update guidelines for using darcs based sources in packages In-Reply-To: <7f692fec0901070854j5d9fd99ax97ff8bc8ab09d643@mail.gmail.com> References: <7f692fec0901070854j5d9fd99ax97ff8bc8ab09d643@mail.gmail.com> Message-ID: <4964FDF3.2070008@gmail.com> Yaakov Nemoy wrote: > Hi List, > > (Packaging list, i'm double posting because i want you guys to see > this, but please put further comments on the haskell list :) ) > Not subscribed to the haskell list and this isn't really a haskell specific question.... > Because the macros, last i checked were for ghc 6.10.1, some of the > packages i'm still working on will only compile from darcs. I've put > together a tool to help with development of packages from darcs, and > i'm looking for a standardized way to note which revision from darcs > is being used. Darcs has two relatively canonical ways to refer to a > package, with a hash and a timestamp. Internally this tool uses both. > Judging from the different ways people note svn/git/other usage in > fedora packages, i've put together a few recommendations that we can > use for a standard. > > Keep in mind, my goal is to support darcs, so please be nitpicky about > these details. Just keep in mind, this is easily bikesheddable, and > all i want to do is support darcs based packages systematically. > > Normal Haskell Tarball name: > %{hackage_name}-%{version}.tar.gz > Output from darcs: > %{hackage_name}-%{version}.%{timestamp_from_darcs}darcs.tar.gz > > Accesible from: > darcs dist -d %{hackage_name}-%{version}.%{timestamp_from_darcs}darcs > Timestamp accessible from > darcs changes --xml-output --last=1 > > To note this in the rpm > Normal Dist: > 1%{?dist} > Darcs Dist > 1.%{timestamp_from_darcs}darcs%{?dist} > > I've attached a patch to the templates that puts in a placeholder to > make it clearer how to do things. Note that in the timestamp i've > added . and darcs systematically. Since the macro %dist includes the . > prefix, as a matter of precedent, i've noted that we should just use > the prefix and suffix in the %darcs macro as well. > > Also, the names of everything here is not so important. What's > important is that i want to take a spec file that's been generated by > cabal2spec, run it through a quick sed-like script that will append > the correct darcs timestamp. Darcs doesn't make the timestamps that > easily available, and i'm trying to automate a few things here. > Four comments: 1) Why do we need to add this to the templates? All packages could potentially be built from snapshots or built from releases. So I don't see why the Haskell templates should be special. 2) %darcs doesn't seem to be a good choice for macro name if it's intended for use in the Haskell Guidelines. Perhaps this shouldn't be part of the the Haskell Guidelines? 3) The patch has two wrong Release lines, %{?darcs} should come before %{?dist} but two of the patch hunks place it after. 4) Why not use a datetime string like the guidelines currently have in place? You could use something like: DATESTAMP=date -u +'%Y%m%d' -d @`darcs-get-timestamp` sed "s/%define darcs \"\"/%define darcs \"$DATESTAMP\"/" -i foo.spec -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 loupgaroublond at gmail.com Wed Jan 7 19:53:15 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 7 Jan 2009 14:53:15 -0500 Subject: [Fedora-packaging] Update guidelines for using darcs based sources in packages In-Reply-To: <4964FDF3.2070008@gmail.com> References: <7f692fec0901070854j5d9fd99ax97ff8bc8ab09d643@mail.gmail.com> <4964FDF3.2070008@gmail.com> Message-ID: <7f692fec0901071153rac94084i816c52351e7c809b@mail.gmail.com> 2009/1/7 Toshio Kuratomi : > Yaakov Nemoy wrote: >> Hi List, >> >> (Packaging list, i'm double posting because i want you guys to see >> this, but please put further comments on the haskell list :) ) >> > Not subscribed to the haskell list and this isn't really a haskell > specific question.... Point taken, continuing discussion here. CC'ing haskell list though. > Four comments: > > 1) Why do we need to add this to the templates? All packages could > potentially be built from snapshots or built from releases. So I don't > see why the Haskell templates should be special. It's a special exception in this case. Many current releases of packages won't build under the ghc in rawhide. The tool i'm composing will make it very easy to track darcs and then switch to a final release once it's made. > 2) %darcs doesn't seem to be a good choice for macro name if it's > intended for use in the Haskell Guidelines. Perhaps this shouldn't be > part of the the Haskell Guidelines? Like i said before, please rename it. %darcs is a temporary name only, and i was looking for comments and suggestions. Would %darcs_timestamp be acceptable? > 3) The patch has two wrong Release lines, %{?darcs} should come before > %{?dist} but two of the patch hunks place it after. I'll send an updated patch, though you have made some good points to abandon this strategy. > 4) Why not use a datetime string like the guidelines currently have in > place? You could use something like: > DATESTAMP=date -u +'%Y%m%d' -d @`darcs-get-timestamp` > sed "s/%define darcs \"\"/%define darcs \"$DATESTAMP\"/" -i foo.spec This would be nice for inserting the proper defines. Actually, since this is python, i could probably script in a '-D' parameter to rpmbuild and mock as well. The tricky part is that there are three lines that also need to be edited, not just the %define line in the spec file. I have a couple of choices here: 1) Have fedora-devshell do something a bit weird and non-standard, that will leave a macro that may or may not make sense in the final submission to Fedora 2) Standardize a macro for those three lines, so that when i use #1, package reviewers and co-maintainers won't scratch their heads wondering what fedora-devshell is doing. Given #2, that's what i'm asking for. -------------- next part -------------- A non-text attachment was scrubbed... Name: templates.patch Type: application/octet-stream Size: 3517 bytes Desc: not available URL: From opensource at till.name Fri Jan 9 10:56:39 2009 From: opensource at till.name (Till Maas) Date: Fri, 09 Jan 2009 11:56:39 +0100 Subject: [Fedora-packaging] Update guidelines for using darcs based sources in packages In-Reply-To: <7f692fec0901071153rac94084i816c52351e7c809b@mail.gmail.com> References: <7f692fec0901070854j5d9fd99ax97ff8bc8ab09d643@mail.gmail.com> <4964FDF3.2070008@gmail.com> <7f692fec0901071153rac94084i816c52351e7c809b@mail.gmail.com> Message-ID: <200901091156.50028.opensource@till.name> On Wed January 7 2009, Yaakov Nemoy wrote: > 2009/1/7 Toshio Kuratomi : > > 2) %darcs doesn't seem to be a good choice for macro name if it's > > intended for use in the Haskell Guidelines. Perhaps this shouldn't be > > part of the the Haskell Guidelines? > > Like i said before, please rename it. %darcs is a temporary name > only, and i was looking for comments and suggestions. Would > %darcs_timestamp be acceptable? The current Naming Guidelines[0] use %{alphatag} for this value. Regards, Till [0] https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From loupgaroublond at gmail.com Fri Jan 9 13:28:39 2009 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Fri, 9 Jan 2009 08:28:39 -0500 Subject: [Fedora-packaging] Update guidelines for using darcs based sources in packages In-Reply-To: <200901091156.50028.opensource@till.name> References: <7f692fec0901070854j5d9fd99ax97ff8bc8ab09d643@mail.gmail.com> <4964FDF3.2070008@gmail.com> <7f692fec0901071153rac94084i816c52351e7c809b@mail.gmail.com> <200901091156.50028.opensource@till.name> Message-ID: <7f692fec0901090528x5243e5c5q596becb2bd9b824a@mail.gmail.com> 2009/1/9 Till Maas : > On Wed January 7 2009, Yaakov Nemoy wrote: >> 2009/1/7 Toshio Kuratomi : > >> > 2) %darcs doesn't seem to be a good choice for macro name if it's >> > intended for use in the Haskell Guidelines. Perhaps this shouldn't be >> > part of the the Haskell Guidelines? >> >> Like i said before, please rename it. %darcs is a temporary name >> only, and i was looking for comments and suggestions. Would >> %darcs_timestamp be acceptable? > > The current Naming Guidelines[0] use %{alphatag} for this value. > > Regards, > Till > > [0] > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages Works for me :), thanks. From nicolas.mailhot at laposte.net Sun Jan 11 15:12:42 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 11 Jan 2009 16:12:42 +0100 Subject: [Fedora-packaging] Re: New font packaging guidelines In-Reply-To: <1229789615.16655.28.camel@arekh.okg> References: <1229789615.16655.28.camel@arekh.okg> Message-ID: <1231686762.16307.2.camel@arekh.okg> Dear all, To help people deal with the new fonts guidelines, I've added the following FAQ to the wiki: http://fedoraproject.org/wiki/Shipping_fonts_in_other_packages_(FAQ) Feel free to complete it (or request additions) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jonathan.underwood at gmail.com Mon Jan 12 12:26:44 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 12 Jan 2009 12:26:44 +0000 Subject: [Fedora-packaging] Package ownership of local state files (/var/lib)? Message-ID: <645d17210901120426s27c7dc15qbe05f23d02a617a4@mail.gmail.com> Hi, Firstly, apologies if this should be obvious or is documented somewhere and I've missed it. While in the process of updating the shorewall packages I noticed that on package removal directories were being left behind in /var/lib/shorewall because the directory contained some files created at run time which were not owned by the package (even though the directory itself is). My first thought was the obvious fix of creating these files at package build time (with touch) and using %ghost to own them. But then I decided to see what other packages do, and chose samba at random, figuring it's quite a mature package. With samba I see the same thing - files in /var/lib/samba which are unowned and so wouldn't be removed when removing the samba packages. So, what is best practice? Should a package own all local state files it creates in /var ? Or should it explicitly not own them so they are left behind (a bit like log files in /var/log) ? Cheers, Jonathan. From rc040203 at freenet.de Mon Jan 12 13:01:23 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 12 Jan 2009 14:01:23 +0100 Subject: [Fedora-packaging] Package ownership of local state files (/var/lib)? In-Reply-To: <645d17210901120426s27c7dc15qbe05f23d02a617a4@mail.gmail.com> References: <645d17210901120426s27c7dc15qbe05f23d02a617a4@mail.gmail.com> Message-ID: <496B3F23.4090905@freenet.de> Jonathan Underwood schrieb: > Hi, > > Firstly, apologies if this should be obvious or is documented > somewhere and I've missed it. > > While in the process of updating the shorewall packages I noticed that > on package removal directories were being left behind in > /var/lib/shorewall because the directory contained some files created > at run time which were not owned by the package (even though the > directory itself is). > > My first thought was the obvious fix of creating these files at > package build time (with touch) and using %ghost to own them. But then > I decided to see what other packages do, and chose samba at random, > figuring it's quite a mature package. With samba I see the same thing > - files in /var/lib/samba which are unowned and so wouldn't be removed > when removing the samba packages. > > So, what is best practice? Well, a soap box answer would be: "Play it safe" ;) > Should a package own all local state files > it creates in /var ? Depends on the use-case. In general, having everything owned is the preferred approach. The %ghost'ing case you mention is a subcase of this kind of situation and may well be suitable in certain situations. However, due to the dynamics below /var, in some cases, other approaches may occasionally be more suitable there, e.g.: * cleaning up via %post scriptlets. E.g. suitable when wanting to remove whole directory hierarchies with dynamic contents. * Not performing any cleanup. In general, this should be avoided whenever possible, nevertheless, it may sometimes preferable, e.g. to allow users/admins some kind of "post-mortem/post-deinstallation" inspection - At least some of the /var/log/* cases are from this group, because these package's maintainers want to leave log files around, to allow admins to inspect them in cases something goes "utterly wrong". > Or should it explicitly not own them so they are > left behind (a bit like log files in /var/log) ? > Depends, again (c.f. above). Ralf From dtimms at iinet.net.au Mon Jan 12 13:29:32 2009 From: dtimms at iinet.net.au (David Timms) Date: Tue, 13 Jan 2009 00:29:32 +1100 Subject: [Fedora-packaging] meta-package guideline needed ? Message-ID: <496B45BC.6060406@iinet.net.au> Hi, I'd like to see some guideline on when meta-packages should / can / can't be created for Fedora. It is definite that examples do currently exist, eg: xorg-x11-drivers I did dig up some old info, but it seems nothing made it into the wiki as a guideline. Can this be discussed and a suitable doc make it into the Guidelines ? [1] http://thread.gmane.org/gmane.linux.rpm.general/12588/focus=12589 [2] http://thread.gmane.org/gmane.linux.redhat.fedora.extras.packaging/3735 [3] https://bugzilla.redhat.com/show_bug.cgi?id=351571 It seems, that for the most part the preference should be to create a comps group, and add all the packages that would be required if it was a meta-package as "required" within the comps group. The package management tools (yum and PackageKit) can then be used with group options to install or remove the group. It seems there is some limitations on using comps groups (please correct me if these are solvable another way): - such a group can not cause the requiring of for example an i386 package on an x86_64 machine. - to workaround (rpm 4.x limitations) above, such a group can not cause the requiring of an i386 package by requiring a file only available in the i386 package. Cheers, David Timms. From pertusus at free.fr Mon Jan 12 13:33:11 2009 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 12 Jan 2009 14:33:11 +0100 Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: <496B45BC.6060406@iinet.net.au> References: <496B45BC.6060406@iinet.net.au> Message-ID: <20090112133311.GB3441@free.fr> On Tue, Jan 13, 2009 at 12:29:32AM +1100, David Timms wrote: > Hi, > > It seems there is some limitations on using comps groups (please correct > me if these are solvable another way): > - such a group can not cause the requiring of for example an i386 > package on an x86_64 machine. > > - to workaround (rpm 4.x limitations) above, such a group can not cause > the requiring of an i386 package by requiring a file only available in > the i386 package. Also some packages of the group can be removed, while a meta-package prevents that, as long as the meta-package itself is present. This can also be seen as an advantage, depending on the situation, but it is definitely a difference. -- Pat From dtimms at iinet.net.au Mon Jan 12 13:43:23 2009 From: dtimms at iinet.net.au (David Timms) Date: Tue, 13 Jan 2009 00:43:23 +1100 Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: <20090112133311.GB3441@free.fr> References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> Message-ID: <496B48FB.2000905@iinet.net.au> Patrice Dumas wrote: > Also some packages of the group can be removed, while a meta-package > prevents that, as long as the meta-package itself is present. This > can also be seen as an advantage, depending on the situation, but it is > definitely a difference. And in my situation removing any package in the "group" would break the external software that the meta package has simplified the install of. DaveT. From jonathan.underwood at gmail.com Mon Jan 12 13:49:31 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 12 Jan 2009 13:49:31 +0000 Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: <20090112133311.GB3441@free.fr> References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> Message-ID: <645d17210901120549x342e1293m68d9a7400f9fff25@mail.gmail.com> 2009/1/12 Patrice Dumas : > On Tue, Jan 13, 2009 at 12:29:32AM +1100, David Timms wrote: >> Hi, >> >> It seems there is some limitations on using comps groups (please correct >> me if these are solvable another way): >> - such a group can not cause the requiring of for example an i386 >> package on an x86_64 machine. >> >> - to workaround (rpm 4.x limitations) above, such a group can not cause >> the requiring of an i386 package by requiring a file only available in >> the i386 package. > > Also some packages of the group can be removed, while a meta-package > prevents that, as long as the meta-package itself is present. This > can also be seen as an advantage, depending on the situation, but it is > definitely a difference. My perception (which may be incorrect) is that the general use case for meta packages is to simplify the installation of a group of subpackages of one package. Whereas the use case for comps groups seems presently more targeted towards installation of a larger set of packages which are often not subpackages. If that is a correct perception, it suggests that this isn't an either/or question, as comps groups and meta packages are solving different but related situations. J. From nicolas.mailhot at laposte.net Mon Jan 12 13:51:44 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Jan 2009 14:51:44 +0100 (CET) Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: <496B48FB.2000905@iinet.net.au> References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> <496B48FB.2000905@iinet.net.au> Message-ID: Le Lun 12 janvier 2009 14:43, David Timms a ?crit : > > Patrice Dumas wrote: >> Also some packages of the group can be removed, while a meta-package >> prevents that, as long as the meta-package itself is present. This >> can also be seen as an advantage, depending on the situation, but it >> is >> definitely a difference. > And in my situation removing any package in the "group" would break > the > external software that the meta package has simplified the install of. However we do not change out package layout to accommodate external software. Please keep your external software adaptation layers outside the Fedora repository. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Jan 12 13:53:13 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Jan 2009 14:53:13 +0100 (CET) Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: <645d17210901120549x342e1293m68d9a7400f9fff25@mail.gmail.com> References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> <645d17210901120549x342e1293m68d9a7400f9fff25@mail.gmail.com> Message-ID: <187271a924a61d0a35643ceec182f358.squirrel@arekh.dyndns.org> Le Lun 12 janvier 2009 14:49, Jonathan Underwood a ?crit : > My perception (which may be incorrect) is that the general use case > for meta packages is to simplify the installation of a group of > subpackages of one package. Whereas the use case for comps groups > seems presently more targeted towards installation of a larger set of > packages which are often not subpackages. Just because a comps group can easily handle packages from different origin does not mean you should not use it for subpackages generated from the same srpm. -- Nicolas Mailhot From jonathan.underwood at gmail.com Mon Jan 12 14:02:08 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 12 Jan 2009 14:02:08 +0000 Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: <187271a924a61d0a35643ceec182f358.squirrel@arekh.dyndns.org> References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> <645d17210901120549x342e1293m68d9a7400f9fff25@mail.gmail.com> <187271a924a61d0a35643ceec182f358.squirrel@arekh.dyndns.org> Message-ID: <645d17210901120602j2c71fba6sfc03a89f3d8a1eaa@mail.gmail.com> 2009/1/12 Nicolas Mailhot : > > > Le Lun 12 janvier 2009 14:49, Jonathan Underwood a ?crit : > >> My perception (which may be incorrect) is that the general use case >> for meta packages is to simplify the installation of a group of >> subpackages of one package. Whereas the use case for comps groups >> seems presently more targeted towards installation of a larger set of >> packages which are often not subpackages. > > Just because a comps group can easily handle packages from different > origin does not mean you should not use it for subpackages generated > from the same srpm. Sure, agreed. A key difference though is that other packages can't Require a comps group, but they can Require a metapackage. I can see why that could be considered bad practice. Also, using comps groups for the metapackage use case I outlined would lead to many more compsgroups, themselves much smaller than the presently existing comps groups. Perhaps we need another concept - collections and groups, where collections is roughly what we currently call comps groups (large package sets with a big overall functionality payload like a desktop environment etc) and comps groups which are primarily for pulling in a series of subpackages. This would lose the ability for a metapackge to be Required now. But perhaps requiring a metapackage is bad practice anyway. J. From nicolas.mailhot at laposte.net Mon Jan 12 14:20:19 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Jan 2009 15:20:19 +0100 (CET) Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: <645d17210901120602j2c71fba6sfc03a89f3d8a1eaa@mail.gmail.com> References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> <645d17210901120549x342e1293m68d9a7400f9fff25@mail.gmail.com> <187271a924a61d0a35643ceec182f358.squirrel@arekh.dyndns.org> <645d17210901120602j2c71fba6sfc03a89f3d8a1eaa@mail.gmail.com> Message-ID: Le Lun 12 janvier 2009 15:02, Jonathan Underwood a ?crit : > Also, using comps groups for the metapackage use case I outlined would > lead to many more compsgroups, themselves much smaller than the > presently existing comps groups. If you look at the comps groups of past releases, you'll see that creating groups with half a dozen packages inside has been done before, and was a common case when comps was introduced. The distribution has massively grown without our comps layout following, probably because no one was perceived to be in chargo of comps those past years. > Perhaps we need another concept - collections and groups, where > collections is roughly what we currently call comps groups (large > package sets with a big overall functionality payload like a desktop > environment etc) and comps groups which are primarily for pulling in a > series of subpackages. There was supposed to be a session on comps future at FUDCON, I hope its results will be posted on the list soon. Regards, -- Nicolas Mailhot From itamar at ispbrasil.com.br Mon Jan 12 14:24:54 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Mon, 12 Jan 2009 12:24:54 -0200 Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> <645d17210901120549x342e1293m68d9a7400f9fff25@mail.gmail.com> <187271a924a61d0a35643ceec182f358.squirrel@arekh.dyndns.org> <645d17210901120602j2c71fba6sfc03a89f3d8a1eaa@mail.gmail.com> Message-ID: meta packages will be good. task-c-devel task-c++-devel task-kde-minimal task-kde task-gnome task-gnome-minimal etc..... On Mon, Jan 12, 2009 at 12:20 PM, Nicolas Mailhot wrote: > > > Le Lun 12 janvier 2009 15:02, Jonathan Underwood a ?crit : > >> Also, using comps groups for the metapackage use case I outlined would >> lead to many more compsgroups, themselves much smaller than the >> presently existing comps groups. > > If you look at the comps groups of past releases, you'll see that > creating groups with half a dozen packages inside has been done > before, and was a common case when comps was introduced. The > distribution has massively grown without our comps layout following, > probably because no one was perceived to be in chargo of comps those > past years. > >> Perhaps we need another concept - collections and groups, where >> collections is roughly what we currently call comps groups (large >> package sets with a big overall functionality payload like a desktop >> environment etc) and comps groups which are primarily for pulling in a >> series of subpackages. > > There was supposed to be a session on comps future at FUDCON, I hope > its results will be posted on the list soon. > > Regards, > > -- > Nicolas Mailhot > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From dtimms at iinet.net.au Mon Jan 12 14:28:25 2009 From: dtimms at iinet.net.au (David Timms) Date: Tue, 13 Jan 2009 01:28:25 +1100 Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> <496B48FB.2000905@iinet.net.au> Message-ID: <496B5389.5050106@iinet.net.au> Nicolas Mailhot wrote: > Le Lun 12 janvier 2009 14:43, David Timms a ??crit : >> And in my situation removing any package in the "group" would break >> the >> external software that the meta package has simplified the install of. > > However we do not change out package layout I'm not sure where you think I asked to do such a thing ? > to accommodate external > software. > Please keep your external software adaptation layers outside > the Fedora repository. Since you read my mind on "external software", I'll mention that I considered this to be a separate issue, I have a separate query/discuss/request that I'll post soon. DaveT. From skvidal at fedoraproject.org Mon Jan 12 14:33:32 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 12 Jan 2009 09:33:32 -0500 Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> <645d17210901120549x342e1293m68d9a7400f9fff25@mail.gmail.com> <187271a924a61d0a35643ceec182f358.squirrel@arekh.dyndns.org> <645d17210901120602j2c71fba6sfc03a89f3d8a1eaa@mail.gmail.com> Message-ID: <1231770812.14403.10.camel@rosebud> On Mon, 2009-01-12 at 15:20 +0100, Nicolas Mailhot wrote: > > Le Lun 12 janvier 2009 15:02, Jonathan Underwood a ?crit : > > > Also, using comps groups for the metapackage use case I outlined would > > lead to many more compsgroups, themselves much smaller than the > > presently existing comps groups. > > If you look at the comps groups of past releases, you'll see that > creating groups with half a dozen packages inside has been done > before, and was a common case when comps was introduced. The > distribution has massively grown without our comps layout following, > probably because no one was perceived to be in chargo of comps those > past years. > > > Perhaps we need another concept - collections and groups, where > > collections is roughly what we currently call comps groups (large > > package sets with a big overall functionality payload like a desktop > > environment etc) and comps groups which are primarily for pulling in a > > series of subpackages. > > There was supposed to be a session on comps future at FUDCON, I hope > its results will be posted on the list soon. We did have a productive, though a little bizarre, meeting on saturday. I'll see what I can write up briefly and one of the others can add to it. Here's a version of it: 0. There's some code we need before we can do this. So don't go changing anything right away. 1. comps groups will get rid of the 'types' of pkgs - a group being in a package means it is in the group - so no more optional/mandatory/default pkgs. 2. conditionals are going away entirely. 3. we're going to do something fairly radical to make group persistence behave as more people expect it. We're going to build metapkgs on the fly at the yum layer and install them. There's a a lot more to how we're going to do it but this is what was discussed at the meeting. I'll post more once I get through the rest of my email. -sv From dtimms at iinet.net.au Mon Jan 12 14:35:59 2009 From: dtimms at iinet.net.au (David Timms) Date: Tue, 13 Jan 2009 01:35:59 +1100 Subject: [Fedora-packaging] easing external software installation - discussion Message-ID: <496B554F.9030500@iinet.net.au> Hi (again), I would like to make it easier to install external software on a fedora system. My specific example is vmware-server and vmware-server-console, but as was suggested by others, once a precedent is set, surely other (unknown) external software would be requested to get this assistance. The specific case I'm considering is the situation where a packager would like to ease the installation of software on Fedora that can't be in Fedora due to either upstream or fedora reasons. An example is: [4] http://thread.gmane.org/gmane.linux.redhat.fedora.devel/82395/focus=82468 [5] https://bugzilla.redhat.com/show_bug.cgi?id=478007 In this case, there is multiple issues: - the external package is not freely re-distributable. - the external rpm does not have a source package. - the external binary rpm package is a generic package for all distros archs, and releases, and doesn't know about fedora specific package naming / requires / file locations. - the rpm (or pre-built source) needs i386 libraries on an x86_64 system. - it is unlikely that the upstream package will create a fedora specific rpm set (ie arch and releases) - people do still want to use such external packages on fedora systems The immediate private solution is to create a meta-package - this needed also other non-preferred tricks (requires: filename) so that i386 libs would get installed on a x86_64 system. While the end result actually works, various people have trouble with: - use of metapackages (see earlier fedora-packaging list discussion starter on metapackages) - the fact that this is making it easier to use non-free software in fedora It seems the preferred solution is to use comps groups (yet I don't think that they can solve the needing i386 libs on x86_64 problem). - It has been suggested that if such a group was committed, "a line would form to revert the change". - It suggests that Fedora somehow supports the external software. This might allow fedora users to expect solutions to problems in the external software. I would like to know in what ways an acceptable solution to this issue could be found. For example, do we want fedora to specifically exclude users from running external (as in not packaged in Fedora) software. Or just make it hard for them ? Could those individuals that are rejecting such groups or metapackages just ignore the fact that such things exist in Fedora, and let those people that it will assist get on with using their Fedora system how they want to ? Could we have an "external software requirement" category or sub-category in comps that packagers could use to put together similar groups of packages needed by specific external software packages - like: |- Desktop |- Servers ... |- Languages |- External software installation requirements { eases the install of external software by installing Fedora packages that such software needs to be able to run on Fedora. The external software will still need to be obtained from it's distributor, will often need further manual configuration to be usable, and is not supported by the Fedora project } |-- ldap browser |-- vmware server |-- vmware server console Is the fact that the external software is mentioned by name a potential problem ? Would for example "pc virtualization server" resolve that ? Are there any real problems in any of the above ? Cheers, David Timms. From rdieter at math.unl.edu Mon Jan 12 14:43:54 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 12 Jan 2009 08:43:54 -0600 Subject: [Fedora-packaging] meta-package guideline needed ? In-Reply-To: <1231770812.14403.10.camel@rosebud> References: <496B45BC.6060406@iinet.net.au> <20090112133311.GB3441@free.fr> <645d17210901120549x342e1293m68d9a7400f9fff25@mail.gmail.com> <187271a924a61d0a35643ceec182f358.squirrel@arekh.dyndns.org> <645d17210901120602j2c71fba6sfc03a89f3d8a1eaa@mail.gmail.com> <1231770812.14403.10.camel@rosebud> Message-ID: <496B572A.7050104@math.unl.edu> seth vidal wrote: > 2. conditionals are going away entirely. boo, I was actually starting to understand and like it (though I can understand the pain involved). -- Rex From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 12 20:07:25 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 12 Jan 2009 21:07:25 +0100 Subject: [Fedora-packaging] Re: Package ownership of local state files (/var/lib)? In-Reply-To: <645d17210901120426s27c7dc15qbe05f23d02a617a4@mail.gmail.com> (Jonathan Underwood's message of "Mon, 12 Jan 2009 12:26:44 +0000") References: <645d17210901120426s27c7dc15qbe05f23d02a617a4@mail.gmail.com> Message-ID: <874p04xp8i.fsf@sheridan.bigo.ensc.de> "Jonathan Underwood" writes: > While in the process of updating the shorewall packages I noticed that on > package removal directories were being left behind in /var/lib/shorewall > because the directory contained some files created at run time which were > not owned by the package (even though the directory itself is). > ... > So, what is best practice? See http://fedoraproject.org/wikiold/PackagingDrafts/Logfiles for a discussion of possible options. Enrico From jonathan.underwood at gmail.com Mon Jan 12 23:30:08 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 12 Jan 2009 23:30:08 +0000 Subject: [Fedora-packaging] Re: Package ownership of local state files (/var/lib)? In-Reply-To: <874p04xp8i.fsf@sheridan.bigo.ensc.de> References: <645d17210901120426s27c7dc15qbe05f23d02a617a4@mail.gmail.com> <874p04xp8i.fsf@sheridan.bigo.ensc.de> Message-ID: <645d17210901121530s4e43e527v230f6a38a298f3a0@mail.gmail.com> 2009/1/12 Enrico Scholz : > "Jonathan Underwood" writes: > >> While in the process of updating the shorewall packages I noticed that on >> package removal directories were being left behind in /var/lib/shorewall >> because the directory contained some files created at run time which were >> not owned by the package (even though the directory itself is). >> ... >> So, what is best practice? > > See http://fedoraproject.org/wikiold/PackagingDrafts/Logfiles for a > discussion of possible options. > Thanks, that's interesting. It could probably be extended to include state files too. J. > > Enrico > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > From ghosler at redhat.com Tue Jan 13 01:49:12 2009 From: ghosler at redhat.com (Gregory Hosler) Date: Tue, 13 Jan 2009 09:49:12 +0800 Subject: [Fedora-packaging] how to make use of bug-buddy bugreport files ? Message-ID: <496BF318.5060201@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, How do I, as a package developer/maintainer, make use of a bug-buddy bugreport.txt file ? I'm old school, and can deal w/ core files just fine. I'm looking for some way to get symbolic stack trace backs from bugreport.txt files. Any documentation as to how the bugreport.txt file is intended to help developers? urls/pointer to info/etc welcome. All the best, - -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) iD8DBQFJa/MW404fl/0CV/QRAu0AAJ4+opgvSIn775tuc89xGMHVnOjU6wCfRHyq lb2X720ooZzbH2RjozCvWdc= =6SlO -----END PGP SIGNATURE----- From rc040203 at freenet.de Tue Jan 13 05:40:27 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jan 2009 06:40:27 +0100 Subject: [Fedora-packaging] max. rpm file name length Message-ID: <496C294B.2050503@freenet.de> Hi, Current rpmlint is warning about rpm-filenames with length > 64, issuing a warning "W: filename-too-long-for-joliet" Question: Do we care about this issue or not? Ralf From rjones at redhat.com Tue Jan 13 11:47:55 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 13 Jan 2009 11:47:55 +0000 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline Message-ID: <20090113114755.GA14660@amd.home.annexia.org> This package just numbers their tarballs using the subversion release number. For example, 'r8' and 'r11': http://code.google.com/p/dlfcn-win32/downloads/list As far as I'm aware they are not planning on using "real" version numbers at any time in the future, nor have they used real version numbers in the past. I don't understand which if any of these guidelines apply to this case: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease In particular, what should the Version be? (And while we're at it, what should the Release be?) 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 rc040203 at freenet.de Tue Jan 13 12:45:54 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jan 2009 13:45:54 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <20090113114755.GA14660@amd.home.annexia.org> References: <20090113114755.GA14660@amd.home.annexia.org> Message-ID: <496C8D02.4080307@freenet.de> Richard W.M. Jones schrieb: > This package just numbers their tarballs using the subversion release > number. For example, 'r8' and 'r11': > > http://code.google.com/p/dlfcn-win32/downloads/list > > As far as I'm aware they are not planning on using "real" version > numbers at any time in the future, nor have they used real version > numbers in the past. > I don't understand which if any of these guidelines apply to this > case: > > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease Not quite. These guidelines are referring to assuring consistency of common upstream pre-release/alpha-/beta- (eg. 1.2.3pre1), upstream post-release/bugfix (e.g. 1.2.3fix1), VCS/date-versioning (e.g. 1.2.3-20081230) schemes with "pure numerical" versioning schemes (e.g. 1.2.3). > In particular, what should the Version be? (And while we're at it, > what should the Release be?) rpm-wise, versions and releases are mere "strings", with complex comparision-operations attached to them. I.e. there is no requirement to have mere numerical %version-%releases, strings are allowed. The only restriction is each package's NEVR to be steadily increasing between different versions of a package, wrt. rpm's version comparision operations. I.e. if I understand your case correctly (upstream using r), you could directly use their version strings as %version and chose %release at your personal preference. Ralf From nicolas.mailhot at laposte.net Tue Jan 13 13:08:32 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 Jan 2009 14:08:32 +0100 (CET) Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496C8D02.4080307@freenet.de> References: <20090113114755.GA14660@amd.home.annexia.org> <496C8D02.4080307@freenet.de> Message-ID: Le Mar 13 janvier 2009 13:45, Ralf Corsepius a ?crit : > > I.e. if I understand your case correctly (upstream using r), you > could directly use their version strings as %version and chose It's probably better to use just in that case as alphanumeric versions tend to bite you sooner or later -- Nicolas Mailhot From rc040203 at freenet.de Tue Jan 13 13:21:01 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jan 2009 14:21:01 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: References: <20090113114755.GA14660@amd.home.annexia.org> <496C8D02.4080307@freenet.de> Message-ID: <496C953D.9070501@freenet.de> Nicolas Mailhot schrieb: > > Le Mar 13 janvier 2009 13:45, Ralf Corsepius a ?crit : > >> I.e. if I understand your case correctly (upstream using r), you >> could directly use their version strings as %version and chose > > It's probably better to use just in that case as alphanumeric > versions tend to bite you sooner or later They don't bite you much more than using numerical versions do or using proprietary handcrafted versions which are diverging from upstream. Ralf From tcallawa at redhat.com Tue Jan 13 16:47:12 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 13 Jan 2009 11:47:12 -0500 Subject: [Fedora-packaging] max. rpm file name length In-Reply-To: <496C294B.2050503@freenet.de> References: <496C294B.2050503@freenet.de> Message-ID: <1231865232.3635.22.camel@localhost.localdomain> On Tue, 2009-01-13 at 06:40 +0100, Ralf Corsepius wrote: > Hi, > > Current rpmlint is warning about rpm-filenames with length > 64, > issuing a warning "W: filename-too-long-for-joliet" > > Question: Do we care about this issue or not? Nah. Everything not horribly broken will intelligently truncate. ~spot From a.badger at gmail.com Tue Jan 13 16:53:58 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 Jan 2009 08:53:58 -0800 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <20090113114755.GA14660@amd.home.annexia.org> References: <20090113114755.GA14660@amd.home.annexia.org> Message-ID: <496CC726.4010306@gmail.com> Richard W.M. Jones wrote: > This package just numbers their tarballs using the subversion release > number. For example, 'r8' and 'r11': > > http://code.google.com/p/dlfcn-win32/downloads/list > > As far as I'm aware they are not planning on using "real" version > numbers at any time in the future, nor have they used real version > numbers in the past. > Note that the crux of this statement is "at any time in the future". If upstream dies and then is revitalized later and the new project lead starts releasing tarballs, you could need epoch to get out of the versioning scheme you choose. (However, epoch does exist, so it's not like you can't escape). > I don't understand which if any of these guidelines apply to this > case: > > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease > > In particular, what should the Version be? (And while we're at it, > what should the Release be?) > In my personal descending order of preference I would do one of these: Version: 0 Release: 1.rNNN Version: 0 Release: 1.DATEsvnNNN Version: NNNN Release: 1 Version: rNNNN Release: 1 The first, second, and fourth are reasonably safe in case a new upstream emerges at some point in the future and decides to make releases with version numbers. The third would need an epoch if that were to occur. The first and second will survive if upstream switches to a new version control system which doesn't have release numbers (for instance, git and starts using dates) or has different release numbers (ie, starting over from 1) while the other two could require changes. The first and second most closely follow the letter of our guidelines (non-numeric version and snapshot package respectively) so they will be least confusing if you get a reviewer who thinks that's important and also will help any packager who takes over from you not make silly mistakes if they don't understand the limitations of the other forms. The first doesn't make you figure out the date which is irrelevant since you're pulling from a released tarball. The fourth, while closest to what upstream has, includes an alpha character in the version which is something that is explicitly forbidden in the Packaging Guidelines. If you want to use that, we'll need to vote on an amendment to allow it. -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 tgl at redhat.com Tue Jan 13 17:23:57 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 13 Jan 2009 12:23:57 -0500 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496CC726.4010306@gmail.com> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> Message-ID: <28242.1231867437@sss.pgh.pa.us> Toshio Kuratomi writes: > The fourth, while closest to what upstream has, includes an alpha > character in the version which is something that is explicitly forbidden > in the Packaging Guidelines. If you want to use that, we'll need to > vote on an amendment to allow it. Really? Don't expect me to adhere to that guideline when packaging something whose upstream uses a letter in the version number. regards, tom lane From tibbs at math.uh.edu Tue Jan 13 17:33:10 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Jan 2009 11:33:10 -0600 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <28242.1231867437@sss.pgh.pa.us> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> Message-ID: >>>>> "TL" == Tom Lane writes: TL> Really? Don't expect me to adhere to that guideline when TL> packaging something whose upstream uses a letter in the version TL> number. Really? Don't expect me to adhere to any guideline that I ever happen to disagree with at any point in time, ever. Rules simply don't apply to me, regardless of how well-considered they are. There, fixed it for you. - J< From a.badger at gmail.com Tue Jan 13 17:34:17 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 Jan 2009 09:34:17 -0800 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <28242.1231867437@sss.pgh.pa.us> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> Message-ID: <496CD099.2060105@gmail.com> Tom Lane wrote: > Toshio Kuratomi writes: >> The fourth, while closest to what upstream has, includes an alpha >> character in the version which is something that is explicitly forbidden >> in the Packaging Guidelines. If you want to use that, we'll need to >> vote on an amendment to allow it. > > Really? Don't expect me to adhere to that guideline when packaging > something whose upstream uses a letter in the version number. > Instead of complaining, get it fixed. 1) Figure out what upstream version number has a problem. 2) Write a draft to change the guideline with the justification 3) Put it under PackagingDrafts and list it on the PackagingDrafts/ page. Alternatively to #2, use your justification to convince someone else to do steps 2+ for you. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Tue Jan 13 17:59:52 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jan 2009 18:59:52 +0100 Subject: [Fedora-packaging] max. rpm file name length In-Reply-To: <1231865232.3635.22.camel@localhost.localdomain> References: <496C294B.2050503@freenet.de> <1231865232.3635.22.camel@localhost.localdomain> Message-ID: <496CD698.4020005@freenet.de> Tom "spot" Callaway schrieb: > On Tue, 2009-01-13 at 06:40 +0100, Ralf Corsepius wrote: >> Hi, >> >> Current rpmlint is warning about rpm-filenames with length > 64, >> issuing a warning "W: filename-too-long-for-joliet" >> >> Question: Do we care about this issue or not? > > Nah. Everything not horribly broken will intelligently truncate. OK, I hoped so. I'll file a bug against rpmlint to stop this warning. [A package review request of mine already is "almost stuck" because of this.] Ralf From rc040203 at freenet.de Tue Jan 13 18:07:15 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jan 2009 19:07:15 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496CC726.4010306@gmail.com> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> Message-ID: <496CD853.2070300@freenet.de> Toshio Kuratomi schrieb: > Richard W.M. Jones wrote: >> This package just numbers their tarballs using the subversion release >> number. For example, 'r8' and 'r11': >> >> http://code.google.com/p/dlfcn-win32/downloads/list >> >> As far as I'm aware they are not planning on using "real" version >> numbers at any time in the future, nor have they used real version >> numbers in the past. >> > Note that the crux of this statement is "at any time in the future". If > upstream dies and then is revitalized later and the new project lead > starts releasing tarballs, you could need epoch to get out of the > versioning scheme you choose. (However, epoch does exist, so it's not > like you can't escape). > >> I don't understand which if any of these guidelines apply to this >> case: >> >> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease >> >> In particular, what should the Version be? (And while we're at it, >> what should the Release be?) >> > > In my personal descending order of preference I would do one of these: > Version: 0 > Release: 1.rNNN > > Version: 0 > Release: 1.DATEsvnNNN > > Version: NNNN > Release: 1 > > Version: rNNNN > Release: 1 Urgh, ... insane overengineering, IMNSHO. All you are doing is adding confusion on user-expections on versions strings and avoidable hassle to package maintainers. Ralf From pertusus at free.fr Tue Jan 13 18:24:58 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 13 Jan 2009 19:24:58 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496CD853.2070300@freenet.de> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <496CD853.2070300@freenet.de> Message-ID: <20090113182457.GB2496@free.fr> On Tue, Jan 13, 2009 at 07:07:15PM +0100, Ralf Corsepius wrote: > Urgh, ... insane overengineering, IMNSHO. > > All you are doing is adding confusion on user-expections on versions > strings and avoidable hassle to package maintainers. It really depends on the case at hand. All of those alternatives have issues (epoch versus not following upstream). Chosing the right one would mean knowing the future, since this is not really easy, letting the maintainer chose one of the possibilities, but in an informed way is, in my opinion, the best. -- Pat From tgl at redhat.com Tue Jan 13 18:52:21 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 13 Jan 2009 13:52:21 -0500 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496CD099.2060105@gmail.com> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> <496CD099.2060105@gmail.com> Message-ID: <29391.1231872741@sss.pgh.pa.us> Toshio Kuratomi writes: > Tom Lane wrote: >> Really? Don't expect me to adhere to that guideline when packaging >> something whose upstream uses a letter in the version number. >> > Instead of complaining, get it fixed. > 1) Figure out what upstream version number has a problem. Well, I don't have to look very far: among my own packages I find /home/tgl/f-pkg/libjpeg/devel/libjpeg.spec:Version: 6b It cannot possibly be a good idea to use something other than the upstream version number in Version --- the ensuing confusion would trump whatever rationale there might be for this guideline. While I hope that there will soon be a new libjpeg upstream release that uses a more typical m.n type of number, it's folly to imagine that Fedora can dictate upstream version numbering practices. regards, tom lane From skvidal at fedoraproject.org Tue Jan 13 18:57:18 2009 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 13 Jan 2009 13:57:18 -0500 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <29391.1231872741@sss.pgh.pa.us> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> <496CD099.2060105@gmail.com> <29391.1231872741@sss.pgh.pa.us> Message-ID: <1231873038.14403.1484.camel@rosebud> On Tue, 2009-01-13 at 13:52 -0500, Tom Lane wrote: > Toshio Kuratomi writes: > > Tom Lane wrote: > >> Really? Don't expect me to adhere to that guideline when packaging > >> something whose upstream uses a letter in the version number. > >> > > Instead of complaining, get it fixed. > > > 1) Figure out what upstream version number has a problem. > > Well, I don't have to look very far: among my own packages I find > /home/tgl/f-pkg/libjpeg/devel/libjpeg.spec:Version: 6b > > It cannot possibly be a good idea to use something other than the > upstream version number in Version --- the ensuing confusion would > trump whatever rationale there might be for this guideline. > > While I hope that there will soon be a new libjpeg upstream release > that uses a more typical m.n type of number, it's folly to imagine that > Fedora can dictate upstream version numbering practices. No one said dictate. You ask to get it fixed, if possible. You cajole, bribe, etc. It's not like fedora is the only distro impacted by this. -sv From tgl at redhat.com Tue Jan 13 19:16:16 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 13 Jan 2009 14:16:16 -0500 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <1231873038.14403.1484.camel@rosebud> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> <496CD099.2060105@gmail.com> <29391.1231872741@sss.pgh.pa.us> <1231873038.14403.1484.camel@rosebud> Message-ID: <29731.1231874176@sss.pgh.pa.us> seth vidal writes: > On Tue, 2009-01-13 at 13:52 -0500, Tom Lane wrote: >> It cannot possibly be a good idea to use something other than the >> upstream version number in Version --- the ensuing confusion would >> trump whatever rationale there might be for this guideline. >> >> While I hope that there will soon be a new libjpeg upstream release >> that uses a more typical m.n type of number, it's folly to imagine that >> Fedora can dictate upstream version numbering practices. > No one said dictate. You ask to get it fixed, if possible. You cajole, > bribe, etc. [ shrug... ] If the guideline said "non-numeric versions are bad; if you have such a package, try to persuade upstream to use a saner versioning scheme next time, and here are reasons x, y, and z to persuade them with", I'd be fine with that. As it is, all I see is an arbitrary exercise of power that will have the principal result of confusing users. The very fine fine print of https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease appears to allow "6b" as a version number under the guise of "post-release packages", so we don't need to have a war about libjpeg in particular. But the whole thing reads to me like an exercise in wishful thinking. It's describing somebody's idea of what version numbering ought to be like, not what upstreams actually use in practice. regards, tom lane From nicolas.mailhot at laposte.net Tue Jan 13 19:28:42 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 13 Jan 2009 20:28:42 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <29731.1231874176@sss.pgh.pa.us> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> <496CD099.2060105@gmail.com> <29391.1231872741@sss.pgh.pa.us> <1231873038.14403.1484.camel@rosebud> <29731.1231874176@sss.pgh.pa.us> Message-ID: <1231874922.1030.4.camel@arekh.okg> Le mardi 13 janvier 2009 ? 14:16 -0500, Tom Lane a ?crit : > The very fine fine print of > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#NonNumericRelease > appears to allow "6b" as a version number under the guise of > "post-release packages", so we don't need to have a war about libjpeg in > particular. But the whole thing reads to me like an exercise in wishful > thinking. It's describing somebody's idea of what version numbering > ought to be like, not what upstreams actually use in practice. It's describing version numbering that people undestand and that will work in rpm. What's wishful thinking is to think you can drop just any versionning convention in rpm and it will magically process it. Before this convention was written we had many cases of packagers with the same attitude as you that blindly dropped upstream versions in rpm and where surprised when they upgrade paths didn't work. You can see the traces to this day in packages with insane epoch numbers used to workaround broken versionning. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From a.badger at gmail.com Tue Jan 13 20:16:50 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 Jan 2009 12:16:50 -0800 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <29731.1231874176@sss.pgh.pa.us> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> <496CD099.2060105@gmail.com> <29391.1231872741@sss.pgh.pa.us> <1231873038.14403.1484.camel@rosebud> <29731.1231874176@sss.pgh.pa.us> Message-ID: <496CF6B2.7080605@gmail.com> Tom Lane wrote: > But the whole thing reads to me like an exercise in wishful > thinking. It's describing somebody's idea of what version numbering > ought to be like, not what upstreams actually use in practice. > Your other argument that there can be confusion when using something that is not upstream's version number has validity to it but this does not. There's no attempt by the Guidelines to change upstream's versioning practices, only how to accommodate their versioning practices within the realm of what rpm can handle. So if you still care, please draft a Guideline change. I'd probably use the user confusion argument as primary justification and propose that epoch be used when versioning problems crop up. Note that much of the information on the page would need to be rewritten to show when epoch should be used if this is the proposal. -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 tgl at redhat.com Tue Jan 13 20:33:03 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 13 Jan 2009 15:33:03 -0500 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <1231874922.1030.4.camel@arekh.okg> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> <496CD099.2060105@gmail.com> <29391.1231872741@sss.pgh.pa.us> <1231873038.14403.1484.camel@rosebud> <29731.1231874176@sss.pgh.pa.us> <1231874922.1030.4.camel@arekh.okg> Message-ID: <760.1231878783@sss.pgh.pa.us> Nicolas Mailhot writes: > Le mardi 13 janvier 2009 ?? 14:16 -0500, Tom Lane a ??crit : >> ... But the whole thing reads to me like an exercise in wishful >> thinking. It's describing somebody's idea of what version numbering >> ought to be like, not what upstreams actually use in practice. > It's describing version numbering that people undestand and that will > work in rpm. > What's wishful thinking is to think you can drop just any versionning > convention in rpm and it will magically process it. No, the wishful thinking is that the Fedora guidelines can issue an edict sans justification and expect that upstreams will start following it. The entire text of this guideline should be replaced by "Try to get your upstream to use a versioning convention that rpm understands", plus a link to some reliable documentation about what it understands. regards, tom lane From rdieter at math.unl.edu Tue Jan 13 20:48:16 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Jan 2009 14:48:16 -0600 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <760.1231878783@sss.pgh.pa.us> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> <496CD099.2060105@gmail.com> <29391.1231872741@sss.pgh.pa.us> <1231873038.14403.1484.camel@rosebud> <29731.1231874176@sss.pgh.pa.us> <1231874922.1030.4.camel@arekh.okg> <760.1231878783@sss.pgh.pa.us> Message-ID: <496CFE10.2060804@math.unl.edu> Tom Lane wrote: > No, the wishful thinking is that the Fedora guidelines can issue an > edict sans justification That's a general problem, where to draw the line in including explanations or justifications for said guidelines. -- Rex From tibbs at math.uh.edu Tue Jan 13 21:00:27 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 13 Jan 2009 15:00:27 -0600 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <760.1231878783@sss.pgh.pa.us> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> <496CD099.2060105@gmail.com> <29391.1231872741@sss.pgh.pa.us> <1231873038.14403.1484.camel@rosebud> <29731.1231874176@sss.pgh.pa.us> <1231874922.1030.4.camel@arekh.okg> <760.1231878783@sss.pgh.pa.us> Message-ID: >>>>> "TL" == Tom Lane writes: TL> No, the wishful thinking is that the Fedora guidelines can issue TL> an edict sans justification and expect that upstreams will start TL> following it. We don't expect upstreams to follow Fedora guidelines. We expect Fedora packagers to follow Fedora guidelines. If you can get upstreams to make things easier on you, so much the better. Otherwise, adapt. - J< From dtimms at iinet.net.au Tue Jan 13 21:12:08 2009 From: dtimms at iinet.net.au (David Timms) Date: Wed, 14 Jan 2009 08:12:08 +1100 Subject: [Fedora-packaging] easing external software installation - discussion In-Reply-To: <496B554F.9030500@iinet.net.au> References: <496B554F.9030500@iinet.net.au> Message-ID: <496D03A8.9020805@iinet.net.au> David Timms wrote: > Could we have an "external software requirement" category or > sub-category in comps that packagers could use to put together similar > groups of packages needed by specific external software packages - like: > |- Desktop > |- Servers > ... > |- Languages > |- External software installation requirements > { eases the install of external software by installing Fedora packages > that such software needs to be able to run on Fedora. The external > software will still need to be obtained from it's distributor, will > often need further manual configuration to be usable, and is not > supported by the Fedora project } > |-- ldap browser > |-- vmware server > |-- vmware server console > > Is the fact that the external software is mentioned by name a potential > problem ? Would for example "pc virtualization server" resolve that ? > > Are there any real problems in any of the above ? - we could require that only external software, that could never be properly packaged in Fedora due to either third-party or our constraints, would be allowed to have such a comps entry. - Some people seem to call external software "third party software". This is a bit deceptive as most of the software packaged in Fedora is written by third parties (and their communities). Yet it might be better terminology. So far it seems no one is objecting to this proposal (at least in fedora-packaging list). Since this isn't directly a packaging issue, is this the most appropriate forum for such a discussion ? Cheers, David Timms. From dtimms at iinet.net.au Tue Jan 13 21:24:27 2009 From: dtimms at iinet.net.au (David Timms) Date: Wed, 14 Jan 2009 08:24:27 +1100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496CFE10.2060804@math.unl.edu> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <28242.1231867437@sss.pgh.pa.us> <496CD099.2060105@gmail.com> <29391.1231872741@sss.pgh.pa.us> <1231873038.14403.1484.camel@rosebud> <29731.1231874176@sss.pgh.pa.us> <1231874922.1030.4.camel@arekh.okg> <760.1231878783@sss.pgh.pa.us> <496CFE10.2060804@math.unl.edu> Message-ID: <496D068B.1020701@iinet.net.au> Rex Dieter wrote: > That's a general problem, where to draw the line in including > explanations or justifications for said guidelines. As one who learns best when an issue is understood, rather than just rote learned, I would be all for allowing the guidelines to include discrete "more info" type of links into the wiki. The target page might directly describe the issue/thinking etc, or provide links to the discussion that lead to the guideline, or to other documentation eg rpm manual. DaveT. From itamar at ispbrasil.com.br Tue Jan 13 21:30:16 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Tue, 13 Jan 2009 19:30:16 -0200 Subject: [Fedora-packaging] easing external software installation - discussion In-Reply-To: <496D03A8.9020805@iinet.net.au> References: <496B554F.9030500@iinet.net.au> <496D03A8.9020805@iinet.net.au> Message-ID: why are you asking ? because this https://bugzilla.redhat.com/show_bug.cgi?id=478007 ? On Tue, Jan 13, 2009 at 7:12 PM, David Timms wrote: > David Timms wrote: >> >> Could we have an "external software requirement" category or sub-category >> in comps that packagers could use to put together similar groups of packages >> needed by specific external software packages - like: >> |- Desktop >> |- Servers >> ... >> |- Languages >> |- External software installation requirements >> { eases the install of external software by installing Fedora packages >> that such software needs to be able to run on Fedora. The external software >> will still need to be obtained from it's distributor, will often need >> further manual configuration to be usable, and is not supported by the >> Fedora project } >> |-- ldap browser >> |-- vmware server >> |-- vmware server console >> >> Is the fact that the external software is mentioned by name a potential >> problem ? Would for example "pc virtualization server" resolve that ? >> >> Are there any real problems in any of the above ? > > - we could require that only external software, that could never be properly > packaged in Fedora due to either third-party or our constraints, would be > allowed to have such a comps entry. > > - Some people seem to call external software "third party software". This is > a bit deceptive as most of the software packaged in Fedora is written by > third parties (and their communities). Yet it might be better terminology. > > So far it seems no one is objecting to this proposal (at least in > fedora-packaging list). Since this isn't directly a packaging issue, is this > the most appropriate forum for such a discussion ? > > Cheers, > > David Timms. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From pertusus at free.fr Tue Jan 13 21:49:27 2009 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 13 Jan 2009 22:49:27 +0100 Subject: [Fedora-packaging] easing external software installation - discussion In-Reply-To: <496B554F.9030500@iinet.net.au> References: <496B554F.9030500@iinet.net.au> Message-ID: <20090113214927.GD2496@free.fr> On Tue, Jan 13, 2009 at 01:35:59AM +1100, David Timms wrote: > Hi (again), > > It seems the preferred solution is to use comps groups (yet I don't > think that they can solve the needing i386 libs on x86_64 problem). I don't think so. A meta-package looks like a right technical solution to me for your issue. > - It has been suggested that if such a group was committed, "a line > would form to revert the change". Agreed. A comps group for the dependencies of a proprietary (or free) software is not right in my opinion. > - It suggests that Fedora somehow supports the external software. This > might allow fedora users to expect solutions to problems in the external > software. This is really a weak argument. Also there are packages in fedora, for example libflashsupport to support proprietary software. So the argument about not helping with proprietary software is moot. As long as it is free software it is right. However I think that meta-packages that are not associated with a given package should be discouraged in fedora. Some specific meta-package only can be accepted, for example 'basesystem' is somehow a meta package, also meta-packages for hardware support when one don't know which precise driver should be used seem right to me. But random meta-packages are not acceptable in my opinion. This opens the door for arbitrary convenience packages, I don't think this is something we want. After that I will want a meta-package to be able to get the dependencies of a numerical model, maybe? -- Pat From rc040203 at freenet.de Tue Jan 13 22:14:07 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 13 Jan 2009 23:14:07 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <20090113182457.GB2496@free.fr> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <496CD853.2070300@freenet.de> <20090113182457.GB2496@free.fr> Message-ID: <496D122F.8070905@freenet.de> Patrice Dumas schrieb: > On Tue, Jan 13, 2009 at 07:07:15PM +0100, Ralf Corsepius wrote: > >> Urgh, ... insane overengineering, IMNSHO. >> >> All you are doing is adding confusion on user-expections on versions >> strings and avoidable hassle to package maintainers. > > It really depends on the case at hand. All of those alternatives have > issues (epoch versus not following upstream). Not quite - All "upstream version" -> "rpm EVR" schemes have issues somewhere, no matter which scheme is favored. > Chosing the right one > would mean knowing the future, There is no "everlasting right one", there only are "temporary right ones" > since this is not really easy, letting > the maintainer chose one of the possibilities, but in an informed way > is, in my opinion, the best. My view is different: A package's maintainer has to find a reasonable compromise between upstream, user-expectation, ease of maintenance and technical possibilities - Choose bizarre version tags is not helpful to anybody. Or differently: If upstream chooses alpha-numeric versions, it would be silly to use "integer versions" in Fedora. Ralf From ville.skytta at iki.fi Tue Jan 13 23:25:57 2009 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 14 Jan 2009 01:25:57 +0200 Subject: [Fedora-packaging] max. rpm file name length In-Reply-To: <496CD698.4020005@freenet.de> References: <496C294B.2050503@freenet.de> <1231865232.3635.22.camel@localhost.localdomain> <496CD698.4020005@freenet.de> Message-ID: <200901140125.57781.ville.skytta@iki.fi> On Tuesday 13 January 2009, Ralf Corsepius wrote: > Tom "spot" Callaway schrieb: > > On Tue, 2009-01-13 at 06:40 +0100, Ralf Corsepius wrote: > >> Hi, > >> > >> Current rpmlint is warning about rpm-filenames with length > 64, > >> issuing a warning "W: filename-too-long-for-joliet" > >> > >> Question: Do we care about this issue or not? > > > > Nah. Everything not horribly broken will intelligently truncate. > > OK, I hoped so. > > I'll file a bug against rpmlint to stop this warning. Thanks, but no need, done a few seconds ago in CVS: http://cvs.fedoraproject.org/viewvc/devel/rpmlint/rpmlint.config?r1=1.27&r2=1.28 From rjones at redhat.com Wed Jan 14 00:00:47 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 14 Jan 2009 00:00:47 +0000 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496CC726.4010306@gmail.com> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> Message-ID: <20090114000047.GA4157@amd.home.annexia.org> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote: > In my personal descending order of preference I would do one of these: > Version: 0 > Release: 1.rNNN Thanks .. For the moment I've used: Version: 0.1 Release: 0.1.r11 Ignore the Version number for now - I can change that to just be '0' later if necessary. How about the Release number: Isn't it more correct to use 0..r instead of .r? (I mean, in case upstream decides to use 0 or 0.1 as a real version number later on?) This is the package: https://bugzilla.redhat.com/show_bug.cgi?id=478640 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rc040203 at freenet.de Wed Jan 14 08:59:52 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Jan 2009 09:59:52 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <20090114000047.GA4157@amd.home.annexia.org> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> Message-ID: <496DA988.7010305@freenet.de> Richard W.M. Jones wrote: > On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote: >> In my personal descending order of preference I would do one of these: >> Version: 0 >> Release: 1.rNNN > > Thanks .. > > For the moment I've used: > > Version: 0.1 > Release: 0.1.r11 What issue are you trying to solve by this choice? You are not solving anything. > How about the Release number: Isn't it more correct to use 0..r > instead of .r? (I mean, in case upstream decides to use 0 or > 0.1 as a real version number later on?) The release numbers don't really matter. Much about them is personal preference and personal use-case. > This is the package: > https://bugzilla.redhat.com/show_bug.cgi?id=478640 I would reject it due to your choice of version. Ralf From rjones at redhat.com Wed Jan 14 09:00:49 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 14 Jan 2009 09:00:49 +0000 Subject: [Fedora-packaging] Use of dos2unix in %prep Message-ID: <20090114090049.GA6751@amd.home.annexia.org> While a package was being reviewed, the reviewer picked up on a use of the 'dos2unix --keepdate' command: https://bugzilla.redhat.com/show_bug.cgi?id=478640 The guidelines do indeed say not to use dos2unix, because quote "that can cause build fail on FC3" (like I care). http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors But I've used dos2unix before, and it appears that using 'dos2unix --keepdate' is a superior solution because it keeps the original timestamp, and is generally simpler and more obvious to people reading the specfile. So is this guideline for real? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rjones at redhat.com Wed Jan 14 09:01:28 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 14 Jan 2009 09:01:28 +0000 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496DA988.7010305@freenet.de> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <496DA988.7010305@freenet.de> Message-ID: <20090114090128.GB6751@amd.home.annexia.org> On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote: > Richard W.M. Jones wrote: >> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote: >>> In my personal descending order of preference I would do one of these: >>> Version: 0 >>> Release: 1.rNNN >> >> Thanks .. >> >> For the moment I've used: >> >> Version: 0.1 >> Release: 0.1.r11 > > What issue are you trying to solve by this choice? > > You are not solving anything. I don't understand what you mean. 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 rc040203 at freenet.de Wed Jan 14 09:14:17 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Jan 2009 10:14:17 +0100 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <20090114090049.GA6751@amd.home.annexia.org> References: <20090114090049.GA6751@amd.home.annexia.org> Message-ID: <496DACE9.4070601@freenet.de> Richard W.M. Jones wrote: > While a package was being reviewed, the reviewer picked up on a use of > the 'dos2unix --keepdate' command: > > https://bugzilla.redhat.com/show_bug.cgi?id=478640 > > The guidelines do indeed say not to use dos2unix, because quote "that > can cause build fail on FC3" (like I care). > > http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors > > But I've used dos2unix before, I use /usr/bin/dos2unix to avoid build breakdowns should dos2unix be moved between packages. and it appears that using 'dos2unix > --keepdate' is a superior solution because it keeps the original > timestamp, and is generally simpler and more obvious to people reading > the specfile. sigh, some people will never understand that keeping timestamps is painting bikesheds :( > So is this guideline for real? I would label this a "historic wart" of FPG, the FPC should revisit. Ralf From rc040203 at freenet.de Wed Jan 14 09:15:12 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Jan 2009 10:15:12 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <20090114090128.GB6751@amd.home.annexia.org> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <496DA988.7010305@freenet.de> <20090114090128.GB6751@amd.home.annexia.org> Message-ID: <496DAD20.2060904@freenet.de> Richard W.M. Jones wrote: > On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote: >> Richard W.M. Jones wrote: >>> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote: >>>> In my personal descending order of preference I would do one of these: >>>> Version: 0 >>>> Release: 1.rNNN >>> Thanks .. >>> >>> For the moment I've used: >>> >>> Version: 0.1 >>> Release: 0.1.r11 >> What issue are you trying to solve by this choice? >> >> You are not solving anything. > > I don't understand what you mean. Let me turn my question around: Why can't you directly use the upstream version? Ralf From rjones at redhat.com Wed Jan 14 09:31:15 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 14 Jan 2009 09:31:15 +0000 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496DAD20.2060904@freenet.de> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <496DA988.7010305@freenet.de> <20090114090128.GB6751@amd.home.annexia.org> <496DAD20.2060904@freenet.de> Message-ID: <20090114093115.GC6751@amd.home.annexia.org> On Wed, Jan 14, 2009 at 10:15:12AM +0100, Ralf Corsepius wrote: > Richard W.M. Jones wrote: >> On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote: >>> Richard W.M. Jones wrote: >>>> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote: >>>>> In my personal descending order of preference I would do one of these: >>>>> Version: 0 >>>>> Release: 1.rNNN >>>> Thanks .. >>>> >>>> For the moment I've used: >>>> >>>> Version: 0.1 >>>> Release: 0.1.r11 >>> What issue are you trying to solve by this choice? >>> >>> You are not solving anything. >> >> I don't understand what you mean. > > Let me turn my question around: Why can't you directly use the upstream > version? I'm just trying to work out the best way to do this. Can you not ask cryptic rhetorical questions and just say why the version and release scheme above, derived from Toshio's one, isn't right. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From dtimms at iinet.net.au Wed Jan 14 09:55:33 2009 From: dtimms at iinet.net.au (David Timms) Date: Wed, 14 Jan 2009 20:55:33 +1100 Subject: [Fedora-packaging] easing external software installation - discussion In-Reply-To: References: <496B554F.9030500@iinet.net.au> <496D03A8.9020805@iinet.net.au> Message-ID: <496DB695.8000700@iinet.net.au> Itamar Reis Peixoto wrote: > why are you asking ? > > because this > > https://bugzilla.redhat.com/show_bug.cgi?id=478007 Yes. You might have missed the initial post ? http://thread.gmane.org/gmane.linux.redhat.fedora.extras.packaging/5266 and references: http://thread.gmane.org/gmane.linux.redhat.fedora.extras.packaging/5255 DaveT. From eduardo at kalinowski.com.br Wed Jan 14 10:40:33 2009 From: eduardo at kalinowski.com.br (Eduardo M KALINOWSKI) Date: Wed, 14 Jan 2009 08:40:33 -0200 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496DAD20.2060904@freenet.de> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <496DA988.7010305@freenet.de> <20090114090128.GB6751@amd.home.annexia.org> <496DAD20.2060904@freenet.de> Message-ID: <496DC121.7060808@kalinowski.com.br> Ralf Corsepius wrote: > Richard W.M. Jones wrote: > >> On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote: >> >>> Richard W.M. Jones wrote: >>> >>>> For the moment I've used: >>>> >>>> Version: 0.1 >>>> Release: 0.1.r11 >>>> >>> What issue are you trying to solve by this choice? >>> >>> You are not solving anything. >>> >> I don't understand what you mean. >> > > Let me turn my question around: Why can't you directly use the upstream > version? > Prepending 0.0 before the SVN version would avoid the need for an epoch should upstream decide later on to release numbered versions, even one as low as 0.1. (Though it cannot cover all possible ways upstream might use to number releases.) -- Don't get mad, get interest. Eduardo M KALINOWSKI eduardo at kalinowski.com.br http://move.to/hpkb From pertusus at free.fr Wed Jan 14 10:57:25 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 14 Jan 2009 11:57:25 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <20090114000047.GA4157@amd.home.annexia.org> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> Message-ID: <20090114105725.GB2860@free.fr> On Wed, Jan 14, 2009 at 12:00:47AM +0000, Richard W.M. Jones wrote: > On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote: > > In my personal descending order of preference I would do one of these: > > Version: 0 > > Release: 1.rNNN > > Thanks .. > > For the moment I've used: > > Version: 0.1 > Release: 0.1.r11 > > Ignore the Version number for now - I can change that to just be '0' > later if necessary. Looks good to me. If version is set to 0, this is the safest choice with regard to avoiding epochs in case upstream changes something afterwards. This is also the numbering that is the most different from upstream, but as long as you are aware of that... -- Pat From pertusus at free.fr Wed Jan 14 11:02:17 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 14 Jan 2009 12:02:17 +0100 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <20090114090049.GA6751@amd.home.annexia.org> References: <20090114090049.GA6751@amd.home.annexia.org> Message-ID: <20090114110217.GC2860@free.fr> On Wed, Jan 14, 2009 at 09:00:49AM +0000, Richard W.M. Jones wrote: > While a package was being reviewed, the reviewer picked up on a use of > the 'dos2unix --keepdate' command: > > https://bugzilla.redhat.com/show_bug.cgi?id=478640 > > The guidelines do indeed say not to use dos2unix, because quote "that > can cause build fail on FC3" (like I care). > > http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors > > But I've used dos2unix before, and it appears that using 'dos2unix > --keepdate' is a superior solution because it keeps the original > timestamp, and is generally simpler and more obvious to people reading > the specfile. To avoid the dos2unix dependency and still keep timestamp, I use: sed -e 's/\r//' $file > $file.tmp touch -c -r $file $file.tmp mv $file.tmp $file But using dos2unix --keepdate with the apropriate BuildRequires (I would use a file BuildRequires) is right too, in my opinion. By the way I prefer keeping timestamps, in case it wasn't clear. -- Pat From rc040203 at freenet.de Wed Jan 14 11:52:32 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Jan 2009 12:52:32 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <20090114093115.GC6751@amd.home.annexia.org> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <496DA988.7010305@freenet.de> <20090114090128.GB6751@amd.home.annexia.org> <496DAD20.2060904@freenet.de> <20090114093115.GC6751@amd.home.annexia.org> Message-ID: <496DD200.4020001@freenet.de> Richard W.M. Jones wrote: > On Wed, Jan 14, 2009 at 10:15:12AM +0100, Ralf Corsepius wrote: >> Richard W.M. Jones wrote: >>> On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote: >>>> Richard W.M. Jones wrote: >>>>> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote: >>>>>> In my personal descending order of preference I would do one of these: >>>>>> Version: 0 >>>>>> Release: 1.rNNN >>>>> Thanks .. >>>>> >>>>> For the moment I've used: >>>>> >>>>> Version: 0.1 >>>>> Release: 0.1.r11 >>>> What issue are you trying to solve by this choice? >>>> >>>> You are not solving anything. >>> I don't understand what you mean. >> Let me turn my question around: Why can't you directly use the upstream >> version? > > I'm just trying to work out the best way to do this. Can you not ask > cryptic rhetorical questions These aren't rhetorical question. My point are: * There is nothing technically wrong with using this upstream's versioning. * Their versioning fits well in to rpm's versioning. => There is no reason to introduce a diverge versioning for your packages. > and just say why the version and release > scheme above, derived from Toshio's one, isn't right. It isn't technically wrong, I simply consider his proposal to be foolish, silly and stupid. Ralf From rc040203 at freenet.de Wed Jan 14 11:54:20 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Jan 2009 12:54:20 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496DC121.7060808@kalinowski.com.br> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <496DA988.7010305@freenet.de> <20090114090128.GB6751@amd.home.annexia.org> <496DAD20.2060904@freenet.de> <496DC121.7060808@kalinowski.com.br> Message-ID: <496DD26C.1050708@freenet.de> Eduardo M KALINOWSKI wrote: > Ralf Corsepius wrote: >> Richard W.M. Jones wrote: >> >>> On Wed, Jan 14, 2009 at 09:59:52AM +0100, Ralf Corsepius wrote: >>> >>>> Richard W.M. Jones wrote: >>>> >>>>> For the moment I've used: >>>>> >>>>> Version: 0.1 >>>>> Release: 0.1.r11 >>>>> >>>> What issue are you trying to solve by this choice? >>>> >>>> You are not solving anything. >>>> >>> I don't understand what you mean. >>> >> Let me turn my question around: Why can't you directly use the upstream >> version? >> > > Prepending 0.0 before the SVN version would avoid the need for an epoch > should upstream decide later on to release numbered versions, even one > as low as 0.1. Correct in case of svn snapshot version. But this doesn't apply here. This upstream releases releases but call them "r". > (Though it cannot cover all possible ways upstream might > use to number releases.) Correct. Ralf From rc040203 at freenet.de Wed Jan 14 11:55:13 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Jan 2009 12:55:13 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <20090114105725.GB2860@free.fr> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <20090114105725.GB2860@free.fr> Message-ID: <496DD2A1.5030300@freenet.de> Patrice Dumas wrote: > On Wed, Jan 14, 2009 at 12:00:47AM +0000, Richard W.M. Jones wrote: >> On Tue, Jan 13, 2009 at 08:53:58AM -0800, Toshio Kuratomi wrote: >>> In my personal descending order of preference I would do one of these: >>> Version: 0 >>> Release: 1.rNNN >> Thanks .. >> >> For the moment I've used: >> >> Version: 0.1 >> Release: 0.1.r11 >> >> Ignore the Version number for now - I can change that to just be '0' >> later if necessary. > > Looks good to me. If version is set to 0, this is the safest choice > with regard to avoiding epochs in case upstream changes something > afterwards. This is also the numbering that is the most different from > upstream, but as long as you are aware of that... Rubbish. People will expect: Requires: xxxx > r11 not Requires: xxxx > 0.1.r11 Ralf From jkeating at redhat.com Wed Jan 14 14:34:16 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Jan 2009 06:34:16 -0800 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <496DACE9.4070601@freenet.de> References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> Message-ID: <1231943656.5086.50.camel@localhost.localdomain> On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote: > sigh, some people will never understand that keeping timestamps is > painting bikesheds :( Keeping timestamps avoids file conflicts on multilib packages. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tibbs at math.uh.edu Wed Jan 14 14:58:58 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Jan 2009 08:58:58 -0600 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <20090114110217.GC2860@free.fr> References: <20090114090049.GA6751@amd.home.annexia.org> <20090114110217.GC2860@free.fr> Message-ID: >>>>> "PD" == Patrice Dumas writes: PD> To avoid the dos2unix dependency and still keep timestamp, I use: [...] I use the same, but collapsed into a one-liner. Honestly I think this and iconv are so common that they should be simple macros. - J< From pertusus at free.fr Wed Jan 14 15:04:18 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 14 Jan 2009 16:04:18 +0100 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <1231943656.5086.50.camel@localhost.localdomain> References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> Message-ID: <20090114150418.GA2538@free.fr> On Wed, Jan 14, 2009 at 06:34:16AM -0800, Jesse Keating wrote: > On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote: > > sigh, some people will never understand that keeping timestamps is > > painting bikesheds :( > > Keeping timestamps avoids file conflicts on multilib packages. not really file conflicts, but rpm -V false alarms. -- Pat From rdieter at math.unl.edu Wed Jan 14 15:08:41 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 14 Jan 2009 09:08:41 -0600 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <20090114150418.GA2538@free.fr> References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> <20090114150418.GA2538@free.fr> Message-ID: <496DFFF9.1090509@math.unl.edu> Patrice Dumas wrote: > On Wed, Jan 14, 2009 at 06:34:16AM -0800, Jesse Keating wrote: >> On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote: >>> sigh, some people will never understand that keeping timestamps is >>> painting bikesheds :( >> Keeping timestamps avoids file conflicts on multilib packages. > > not really file conflicts, but rpm -V false alarms. in my experience, true conflicts, but only when the multilib'd packages are installed in separate transactions. -- Rex From tibbs at math.uh.edu Wed Jan 14 15:18:38 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 14 Jan 2009 09:18:38 -0600 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496DD200.4020001@freenet.de> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <496DA988.7010305@freenet.de> <20090114090128.GB6751@amd.home.annexia.org> <496DAD20.2060904@freenet.de> <20090114093115.GC6751@amd.home.annexia.org> <496DD200.4020001@freenet.de> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> It isn't technically wrong, I simply consider his proposal to be RC> foolish, silly and stupid. Because being insulting is obviously the best way to constructively criticize something. Look, Ralf, you occasionally have good things to say. But when you write things like the above, you're just not being useful, OK? It's just unwanted noise. - J< From rc040203 at freenet.de Wed Jan 14 15:29:06 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 14 Jan 2009 16:29:06 +0100 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <1231943656.5086.50.camel@localhost.localdomain> References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> Message-ID: <496E04C2.6070105@freenet.de> Jesse Keating wrote: > On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote: >> sigh, some people will never understand that keeping timestamps is >> painting bikesheds :( > > Keeping timestamps avoids file conflicts on multilib packages. Wrong, ... if they cause conflicts, something else is broken. It's the contents which matters, not the timestamp. Ralf From tcallawa at redhat.com Wed Jan 14 15:32:39 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 14 Jan 2009 10:32:39 -0500 Subject: [Fedora-packaging] Draft vote on Font Package Naming Message-ID: <1231947159.3518.33.camel@localhost.localdomain> The Fedora Packaging Committee voted to approve a revised version of the Font Naming draft that was originally proposed in our last meeting, then revised by Nicolas Mailhot based on suggestions from the FPC. The draft is available here: http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% 282009-01-13%29 It has been sent to FESCo for ratification: https://fedorahosted.org/fesco/ticket/18 Thanks, ~spot, Fedora Packaging Committee Chair From nicolas.mailhot at laposte.net Wed Jan 14 15:56:38 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 14 Jan 2009 16:56:38 +0100 (CET) Subject: [Fedora-packaging] Draft vote on Font Package Naming In-Reply-To: <1231947159.3518.33.camel@localhost.localdomain> References: <1231947159.3518.33.camel@localhost.localdomain> Message-ID: <067d22b695ae4e3ee1574a2b9dc6afd8.squirrel@arekh.dyndns.org> Le Mer 14 janvier 2009 16:32, Tom \"spot\" Callaway a ?crit : BTW for the already approved by FPC draft on splitting: http://fedoraproject.org/wiki/PackagingDrafts/Font_package_splitting_rules_(2008-12-21) The following exception can probably be removed, as the packagers of all the critical font packages that could exercise it (dejavu, dejavu lgc, vera, liberation) already decided independently to split like everyone else in rawhide (gnu free font could still use it, but do we want an exception for a single non-default package?) ??historic Latin fonts which share a common designer, and are intended to be used together, as evidenced by their name (for example Liberation Sans, Liberation Serif and Liberation Mono). In that case splitting them in different subpackages or not is left to the packager discretion. ? -- Nicolas Mailhot From jkeating at redhat.com Wed Jan 14 18:07:45 2009 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 14 Jan 2009 10:07:45 -0800 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <496DFFF9.1090509@math.unl.edu> References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> <20090114150418.GA2538@free.fr> <496DFFF9.1090509@math.unl.edu> Message-ID: <1231956465.5086.55.camel@localhost.localdomain> On Wed, 2009-01-14 at 09:08 -0600, Rex Dieter wrote: > in my experience, true conflicts, but only when the multilib'd packages > are installed in separate transactions. That got "fixed" a while ago to trigger the conflict no matter what the transaction state is. It was far too confusing to only have conflicts if installing at different times. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fkooman at tuxed.net Wed Jan 14 21:01:19 2009 From: fkooman at tuxed.net (=?ISO-8859-1?Q?Fran=E7ois_Kooman?=) Date: Wed, 14 Jan 2009 22:01:19 +0100 Subject: [Fedora-packaging] Java packaging of Bluecove Message-ID: <496E529F.3030605@tuxed.net> Hi, I'm trying to package Bluecove (a Java stack implementation of JSR-82) using BlueZ [1]. Upstream has two tars: (bluecove-2.1.0-source.tar.gz) which contains everything needed for platforms like Windows and OS X (Apache 2 license), and for Linux a separate tar (bluecove-gpl-2.1.0-sources.tar.gz) that contains some BlueZ JNI foo (and which is GPL licensed). Does it make sense to put this all in one spec file/package? Bluecove without the "gpl" part is useless on Linux. It would probably be cleanest to just have one spec file and one package that includes the jar file and the native library? But this would require fiddling with Source0 and Source1 and some setup macros. Are there any examples of this? Any advice? Thanks, Fran?ois [1] http://code.google.com/p/bluecove/ From overholt at redhat.com Wed Jan 14 21:12:51 2009 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 14 Jan 2009 16:12:51 -0500 Subject: [Fedora-packaging] Java packaging of Bluecove In-Reply-To: <496E529F.3030605@tuxed.net> References: <496E529F.3030605@tuxed.net> Message-ID: <496E5553.9090907@redhat.com> Hi, Fran?ois Kooman wrote: > I'm trying to package Bluecove (a Java stack implementation of JSR-82) > using BlueZ [1]. Cool. > Does it make sense to put this all in one spec file/package? Bluecove > without the "gpl" part is useless on Linux. Sure. > But this would > require fiddling with Source0 and Source1 and some setup macros. Are > there any examples of this? Any advice? The Eclipse SDK spec -- eclipse.spec -- is huge and overkill for what you're looking for but it has multiple sources. OTTOMH I can't think of other examples. Anyone else? Andrew From petersen at redhat.com Wed Jan 14 23:53:37 2009 From: petersen at redhat.com (Jens Petersen) Date: Wed, 14 Jan 2009 18:53:37 -0500 (EST) Subject: [Fedora-packaging] Draft vote on Font Package Naming In-Reply-To: <1494628995.1297571231977064529.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "Tom \"spot\" Callaway" wrote: > The draft is available here: > http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% > 282009-01-13%29 Sorry but this is not a good idea IMO. It requires 119 binary font packages in rawhide to be renamed, a number of which are referenced by a number of other packages in the distro. It also makes it hard for people to work out what the source package name is. What is so bad about the current fonts package naming convention "name-fonts-face"? Jens From nicolas.mailhot at laposte.net Thu Jan 15 00:51:24 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Jan 2009 01:51:24 +0100 Subject: [Fedora-packaging] Draft vote on Font Package Naming In-Reply-To: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1231980684.24058.19.camel@arekh.okg> Anyway, to get the ball rolling: 1. I've pushed an updated fontpackages release on rawhide that takes into account FPC naming preferences 2. Packages with only a single font family inside should be unaffected by this change (they still build the same) 3. Packages with multiple font families inside need to be changed slightly to the new spec template. Basicaly a subpackage for foo font family was declared before with %package foo ... %description foo And need to use now %package -n %{fontname}-foo-fonts ... Obsoletes: %{name}-foo < thisversion-thisrelease %description -n %{fontname}-foo-fonts The rest of the spec is completely unchanged, the macros behaviours where modified to take the new naming conventions into account (management of the transition for packages which have deps on needs to be worked out, but that should mainly concern dejavu only, and I've not touched it yet) 4. Non-font srpms with fonts subpackages that used %package fonts-foo ... %description fonts-foo ... %_font_pkg -n fonts-foo ... Need to be changed to %package foo-fonts ... %description foo-fonts ... %_font_pkg -n foo ... This stuff is only lightly tested in rawhide which is why I'm not going to push it to stable releases now ; if you want to play with it on non-rawhide systems install the rawhide fontpackages rpms on them. This is mainly to provide people a way to test by themselves what FPC requirements means instead of flooding the lists with mails. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From a.badger at gmail.com Thu Jan 15 01:33:23 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 14 Jan 2009 17:33:23 -0800 Subject: [Fedora-packaging] Draft vote on Font Package Naming In-Reply-To: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <496E9263.30204@gmail.com> Jens Petersen wrote: > ----- "Tom \"spot\" Callaway" wrote: >> The draft is available here: >> http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% >> 282009-01-13%29 > > Sorry but this is not a good idea IMO. It requires 119 binary font packages in rawhide to be renamed, a number of which are referenced by a number of other packages in the distro. > This could be taken care of by not renaming existing packages. What's your preference, to grandfather or not to grandfather? > It also makes it hard for people to work out what the source package name is. > Not unduly. Unlike our original feedback to Nicolas that a prefix of font- would be preferable, this groups the font binary subpackage close to the font package it comes from in any menu entries. That makes it relatively easy to find the source package. > What is so bad about the current fonts package naming convention "name-fonts-face"? > What is "name" in the above convention? In the original proposal handed to us, there was foundryname[-fontprojectname]-fonts[-fontfamilyname]. This seems like an odd format as there's two mandatory and two optional sections separated from each other. The sections also bounce back and forth between general and specific criteria. Pulling the font packages out of a list of rpms requires more coding and guesswork than when the -fonts is at one end or the other as well. -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 petersen at redhat.com Thu Jan 15 02:28:26 2009 From: petersen at redhat.com (Jens Petersen) Date: Wed, 14 Jan 2009 21:28:26 -0500 (EST) Subject: [Fedora-packaging] Draft vote on Font Package Naming In-Reply-To: <496E9263.30204@gmail.com> Message-ID: <1184562143.1311781231986506058.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "Toshio Kuratomi" wrote: > This could be taken care of by not renaming existing packages. > What's your preference, to grandfather or not to grandfather? I am not sure: opinions seem to differ - also I am not completely clear how many of the packages need to be renamed anyway for foundry, etc. For package names that are changing anyway then this is less of an issue though of course there is still impact on the distro. So it would be helpful to see a complete list of names for f10 vs proposed f11 names to get a clearer idea about the impact. Maybe even multiple columns comparing the proposals. > > It also makes it hard for people to work out what the source package name is. > > > Not unduly. Unlike our original feedback to Nicolas that a prefix of > font- would be preferable, this groups the font binary subpackage close > to the font package it comes from in any menu entries. That makes it > relatively easy to find the source package. That is already mostly true of the current (f10) naming scheme, isn't it? > > What is so bad about the current fonts package naming convention > "name-fonts-face"? > > > What is "name" in the above convention? In the original proposal > handed to us, there was > foundryname[-fontprojectname]-fonts[-fontfamilyname]. Yes, I guess I meant [foundryname-]fontprojectname-fonts[-fontfamilyname]. > This seems like an odd format as there's two mandatory and two optional > sections separated from each other. The sections also bounce back > and forth between general and specific criteria. "%Package family" is a lot simpler than "%Package -n foundry-font-family-fonts". > Pulling the font packages > out of a list of rpms requires more coding and guesswork than when > the -fonts is at one end or the other as well. Well it just requires "*fonts*" rather than "*fonts". IMHO that is a small win and we are already used to the former glob anyway. Jens From a.badger at gmail.com Thu Jan 15 04:03:21 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 14 Jan 2009 20:03:21 -0800 Subject: [Fedora-packaging] Draft vote on Font Package Naming In-Reply-To: <1184562143.1311781231986506058.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1184562143.1311781231986506058.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <496EB589.107@gmail.com> Jens Petersen wrote: > ----- "Toshio Kuratomi" wrote: >>> It also makes it hard for people to work out what the source package name is. >>> >> Not unduly. Unlike our original feedback to Nicolas that a prefix of >> font- would be preferable, this groups the font binary subpackage close >> to the font package it comes from in any menu entries. That makes it >> relatively easy to find the source package. > > That is already mostly true of the current (f10) naming scheme, isn't it? > AFAICS it's currently, maintainer's choice. Am I missing the current Guideline? >>> What is so bad about the current fonts package naming convention >> "name-fonts-face"? >> What is "name" in the above convention? In the original proposal >> handed to us, there was >> foundryname[-fontprojectname]-fonts[-fontfamilyname]. > > Yes, I guess I meant [foundryname-]fontprojectname-fonts[-fontfamilyname]. > >> This seems like an odd format as there's two mandatory and two optional >> sections separated from each other. The sections also bounce back >> and forth between general and specific criteria. > > "%Package family" is a lot simpler than "%Package -n foundry-font-family-fonts". > Simpler is good but this just moves the complexity from the packager to the user. Why do you have "fonts" in the name at all? I assume it's so a person can tell by glancing at the package name that the package contains fonts? So it should be placed somewhere that highlights this fact -- either the beginning or end. What's the difference between a fonts-common and fonts-sans? Do they both contain fonts? >> Pulling the font packages >> out of a list of rpms requires more coding and guesswork than when >> the -fonts is at one end or the other as well. > > Well it just requires "*fonts*" rather than "*fonts". IMHO that is a small win and we are already used to the former glob anyway. > It depends on what you are doing. In yum, '*fonts*' might yield a correct result because you're depsolving. But selecting only packages containing fonts in the shell because you want to find the total size/number of font packages in the repo or make sure they all contain fonts would not work (for instance, they drag in the fonts-common subpackages). -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 paul at city-fan.org Thu Jan 15 09:06:27 2009 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Jan 2009 09:06:27 +0000 Subject: [Fedora-packaging] Java packaging of Bluecove In-Reply-To: <496E5553.9090907@redhat.com> References: <496E529F.3030605@tuxed.net> <496E5553.9090907@redhat.com> Message-ID: <496EFC93.1040205@city-fan.org> Andrew Overholt wrote: > Hi, > > Fran?ois Kooman wrote: >> I'm trying to package Bluecove (a Java stack implementation of JSR-82) >> using BlueZ [1]. > > Cool. > >> Does it make sense to put this all in one spec file/package? Bluecove >> without the "gpl" part is useless on Linux. > > Sure. > >> But this would require fiddling with Source0 and Source1 and some >> setup macros. Are there any examples of this? Any advice? > > The Eclipse SDK spec -- eclipse.spec -- is huge and overkill for what > you're looking for but it has multiple sources. OTTOMH I can't think of > other examples. Anyone else? dovecot has multiple sources and the spec includes 3 invocations of %setup. Paul. From nicolas.mailhot at laposte.net Thu Jan 15 09:09:01 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Jan 2009 10:09:01 +0100 (CET) Subject: [Fedora-packaging] Draft vote on Font Package Naming In-Reply-To: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int. phx2.redhat.com> References: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: Le Jeu 15 janvier 2009 00:53, Jens Petersen a ?crit : > > ----- "Tom \"spot\" Callaway" wrote: >> The draft is available here: >> http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% >> 282009-01-13%29 > > Sorry but this is not a good idea IMO. BTW I think Jens objects strongly because he did not see some of the horrific naming changes FPC proposed first, which would have resulted in mass srpm renames and totally un-obvious srpm name -> rpm name mappings. (and we use srpm names to reference packages in all our infra tools) The current FPC-approved draft is a lot saner and does not require too much implementing work I think: 1. it does not change existing font srpm names at all, except for - the handful of packages that didn't respect strictly the previous semi-official naming guidelines (I write semi-official because even though no explicit font naming guideline was written down a naming style was suggested in official font spec templates) - the handfuls of packages which didn't use foundryname prefixes when they could (and we'd planned to make them change them anyway since having some packages with this prefix and others without was confusing to users and packagers) 2. does change font subpackage names slightly for font subpackages of font srpms. I've pushed a new fontpackages-* rpm set (templates and macros) to rawhide that minimizes the changes needed to existing font specs to adapt to FPC naming (only %package and %description lines) Of course packagers will still have to add Obsoletes manually, plus some sort of Provides transition for the few font packages that other packages depend on Actual subpackage content and internal file layout didn't change. 3. Clarifies the font subpackage naming for font subpackages of non-font srpms. Well since there was no clear convention before, and inconsistent naming practices, any clear naming guideline was going to require changes in most packages. I've adapted the macros to force the FPC naming rules in that case. WARNING 2. and 3. mean that trying to rebuild a srpm with font subpackages in rawhide without doing the small spec changes entailed by the new naming rules adopted by As a test I've rebuilt a few font packages on my system, and changed bitstream vera in rawhide, to verify it works in koji (it does), and to provide people an example of what the renaming entails in practice for a non-trivial font package. Sincerely, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Thu Jan 15 09:13:16 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Jan 2009 10:13:16 +0100 (CET) Subject: [Fedora-packaging] Draft vote on Font Package Naming In-Reply-To: <496E9263.30204@gmail.com> References: <2143555607.1297781231977217381.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <496E9263.30204@gmail.com> Message-ID: <6b5c03981b4b5a9b882df4dd54a4496e.squirrel@arekh.dyndns.org> Le Jeu 15 janvier 2009 02:33, Toshio Kuratomi a ?crit : > Jens Petersen wrote: >> ----- "Tom \"spot\" Callaway" wrote: >>> The draft is available here: >>> http://fedoraproject.org/wiki/PackagingDrafts/Font_package_naming_% >>> 282009-01-13%29 >> >> Sorry but this is not a good idea IMO. It requires 119 binary font >> packages in rawhide to be renamed, a number of which are referenced >> by a number of other packages in the distro. >> > This could be taken care of by not renaming existing packages. What's > your preference, to grandfather or not to grandfather? I can't write font-packaging-support rpm macros that handle every possible naming variants, sorry. All the font packages in a release need to follow the same rules if you want spec files kept simple and understandable. Regards, -- Nicolas Mailhot From fkooman at tuxed.net Thu Jan 15 10:14:08 2009 From: fkooman at tuxed.net (=?ISO-8859-1?Q?Fran=E7ois_Kooman?=) Date: Thu, 15 Jan 2009 11:14:08 +0100 Subject: [Fedora-packaging] Java packaging of Bluecove In-Reply-To: <496E5553.9090907@redhat.com> References: <496E529F.3030605@tuxed.net> <496E5553.9090907@redhat.com> Message-ID: <496F0C70.1030407@tuxed.net> Andrew Overholt wrote: > The Eclipse SDK spec -- eclipse.spec -- is huge and overkill for what > you're looking for but it has multiple sources. OTTOMH I can't > think of other examples. Anyone else? I looked at that and also some RPM resources online (and dovecot SPEC). In the end I came up with: %setup -q %setup -q -T -D -a 1 Which unpacks Source0 (quietly) and after that unpacks Source1 inside the extracted Source0, without deleting the parent (Source0) directory. This seems to work, I have a preliminary SPEC file at http://users.tuxed.net/fkooman/rpmbuild/SPECS/bluecove.spec in case anyone is interested, but it is not quite ready for review yet. Thanks, Fran?ois From pertusus at free.fr Thu Jan 15 11:57:25 2009 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 15 Jan 2009 12:57:25 +0100 Subject: [Fedora-packaging] Java packaging of Bluecove In-Reply-To: <496F0C70.1030407@tuxed.net> References: <496E529F.3030605@tuxed.net> <496E5553.9090907@redhat.com> <496F0C70.1030407@tuxed.net> Message-ID: <20090115115725.GB2841@free.fr> On Thu, Jan 15, 2009 at 11:14:08AM +0100, Fran?ois Kooman wrote: > > I looked at that and also some RPM resources online (and dovecot SPEC). > In the end I came up with: > > %setup -q > %setup -q -T -D -a 1 Looks good to me. That's what I do in cernlib, too (but you don't want to look a the spec file for an example...). -- Pat From ivazqueznet at gmail.com Thu Jan 15 16:36:03 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 15 Jan 2009 11:36:03 -0500 Subject: [Fedora-packaging] Java packaging of Bluecove In-Reply-To: <496F0C70.1030407@tuxed.net> References: <496E529F.3030605@tuxed.net> <496E5553.9090907@redhat.com> <496F0C70.1030407@tuxed.net> Message-ID: <1232037363.12251.205.camel@ignacio.lan> On Thu, 2009-01-15 at 11:14 +0100, Fran?ois Kooman wrote: > %setup -q > %setup -q -T -D -a 1 > > Which unpacks Source0 (quietly) and after that unpacks Source1 inside > the extracted Source0, without deleting the parent (Source0) directory. This should be equivalent to: %setup -q -a 1 -- 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: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Thu Jan 15 17:07:07 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Jan 2009 18:07:07 +0100 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <496DA988.7010305@freenet.de> <20090114090128.GB6751@amd.home.annexia.org> <496DAD20.2060904@freenet.de> <20090114093115.GC6751@amd.home.annexia.org> <496DD200.4020001@freenet.de> Message-ID: <496F6D3B.2020900@freenet.de> Jason L Tibbitts III wrote: >>>>>> "RC" == Ralf Corsepius writes: > > RC> It isn't technically wrong, I simply consider his proposal to be > RC> foolish, silly and stupid. > > Because being insulting is obviously the best way to constructively > criticize something. > > Look, Ralf, you occasionally have good things to say. But when you > write things like the above, you're just not being useful, OK? > > It's just unwanted noise. OK, I realize you don't want to be told what you don't want to hear, no matter how silly/stupid/dumb/simple-minded a proposal might be. Would you have preferred me naming Toshio's proposal as "non-discuss worthy attempt of over-engineering"? Ralf From tibbs at math.uh.edu Thu Jan 15 17:14:43 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 15 Jan 2009 11:14:43 -0600 Subject: [Fedora-packaging] Confused by non-numeric version in release guideline In-Reply-To: <496F6D3B.2020900@freenet.de> References: <20090113114755.GA14660@amd.home.annexia.org> <496CC726.4010306@gmail.com> <20090114000047.GA4157@amd.home.annexia.org> <496DA988.7010305@freenet.de> <20090114090128.GB6751@amd.home.annexia.org> <496DAD20.2060904@freenet.de> <20090114093115.GC6751@amd.home.annexia.org> <496DD200.4020001@freenet.de> <496F6D3B.2020900@freenet.de> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> OK, I realize you don't want to be told what you don't want to RC> hear, no matter how silly/stupid/dumb/simple-minded a proposal RC> might be. That's rather comical; you have no idea what my stance on this issue is, yet you choose to argue against me anyway. If you were able to articulate your thoughts in a manner which befits adult discussion, you might even find that I agree with you. Anything is possible, as long as you're willing to actually participate in a manner which reflects the dignity of the people you are debating with. - J< From mschwendt at gmail.com Fri Jan 16 10:41:23 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 16 Jan 2009 11:41:23 +0100 Subject: [Fedora-packaging] Reviewing explicit Requires Message-ID: <20090116114123.6931b802.mschwendt@gmail.com> Hi everyone! Because of broken dependencies in an update declared as stable, I've run into package "condor". It's a 20K spec file with a remarkably short review ticket, and I wondered why it contains the following explicit dependencies? Requires: pcre Requires: postgresql-libs Requires: openssl Requires: krb5-libs Requires: gsoap Requires: mailx Actually, all of them except for "mailx" are added automatically by rpmbuild already (as dependencies on SONAMEs): http://koji.fedoraproject.org/koji/rpminfo?rpmID=948426 I've double-checked with the current ReviewGuidelines, and I could not find a corresponding entry that would make reviewers block such explicit dependencies. If memory serves correctly, we've had a section somewhere in the Wiki. Searching further, I've found only https://fedoraproject.org/wiki/Packaging/Guidelines#Requires which only says RPM has very good capabilities of automatically finding dependencies for libraries and eg. Perl modules. In short, don't reinvent the wheel, but just let rpm do its job. There is usually no need to explicitly list eg. Requires: libX11 when the dependency has already been picked up by rpm in the form of depending on libraries in the libX11 package. and which is linked from the review item MUST: The package must meet the Packaging Guidelines . The phrase "there is usually no need to" is vague without any emphasis like SHOULD/MUST and no specific entry in the review guidelines. Does anyone remember where the paragraph has gone, which commented on the badness of explicit dependencies on package names? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tcallawa at redhat.com Fri Jan 16 14:52:29 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 16 Jan 2009 09:52:29 -0500 Subject: [Fedora-packaging] Reviewing explicit Requires In-Reply-To: <20090116114123.6931b802.mschwendt@gmail.com> References: <20090116114123.6931b802.mschwendt@gmail.com> Message-ID: <1232117549.4394.15.camel@localhost.localdomain> On Fri, 2009-01-16 at 11:41 +0100, Michael Schwendt wrote: > Does anyone remember where the paragraph has gone, which commented on > the badness of explicit dependencies on package names? I'm not sure there was ever such a paragraph. Would you like to propose one? ~spot From fabian.deutsch at gmx.de Fri Jan 16 20:07:50 2009 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Fri, 16 Jan 2009 21:07:50 +0100 Subject: [Fedora-packaging] Packing Hadoop Message-ID: <1232136470.4980.10.camel@decade.local> Hello, I'm quite new to packing up packages for Fedora. It might not be the simplest package to create, but I quite like hadoop and wanted to package it up, so it's easier to maintain on Fedora based boxes. There are a couple of issues I ran into: - Can I explicitly require a java package not just to be installed, but also to be the the selected alternative? (openjdk ist required at build- and runtime) - Where to put those jars? I'm suggesting /usr/share/java - What about missing dependencies? There are some jars required which are not packed up in Fedora yet. I'm not allowed to use the binary-jars distributed in the hadoop tarball? - Scripts There are scripts to run hadoop and dfs (bin/start-all, stop-all, ...) Where shall I put them? Create a custom user, as postgres does? Maybe someone can share experience to solve this issues .. - fabian From pertusus at free.fr Sat Jan 17 11:22:58 2009 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 17 Jan 2009 12:22:58 +0100 Subject: [Fedora-packaging] Packing Hadoop In-Reply-To: <1232136470.4980.10.camel@decade.local> References: <1232136470.4980.10.camel@decade.local> Message-ID: <20090117112258.GB2914@free.fr> On Fri, Jan 16, 2009 at 09:07:50PM +0100, Fabian Deutsch wrote: > Hello, > > There are a couple of issues I ran into: > - Can I explicitly require a java package not just to be installed, but > also to be the the selected alternative? > (openjdk ist required at build- and runtime) I did that for tetex-tex4ht, copying what was done in freecol. > - What about missing dependencies? > There are some jars required which are not packed up in Fedora yet. > I'm not allowed to use the binary-jars distributed in the hadoop > tarball? Indeed you are not. They should be packaged in fedora. > - Scripts > There are scripts to run hadoop and dfs (bin/start-all, stop-all, ...) > Where shall I put them? Create a custom user, as postgres does? If hadoop runs as a daemon, it should not run as root but as a special user. And you can do an initscript for fedora, to integrate well with init daemon management. But since I have no ieda what hadoop is, I may be telling nonsensical stuff. In any case, and especially for your first package and an hard package, you can submit a review request with a non-perfect package, as long as you tell it clearly in a comment. As a side note, in general this list should not be used for packaging questions, unless you have in mind a needed change in guidelines to accomodate your package. The development questions should better go to fedora-devel-list, since here it is more to discuss packaging guidelines than for help on existing guidelines. -- Pat From fabian.deutsch at gmx.de Sat Jan 17 17:19:44 2009 From: fabian.deutsch at gmx.de (Fabian Deutsch) Date: Sat, 17 Jan 2009 18:19:44 +0100 Subject: [Fedora-packaging] Packing Hadoop In-Reply-To: <20090117112258.GB2914@free.fr> References: <1232136470.4980.10.camel@decade.local> <20090117112258.GB2914@free.fr> Message-ID: <1232212784.5023.2.camel@decade.local> Hey Pat, Am Samstag, den 17.01.2009, 12:22 +0100 schrieb Patrice Dumas: > On Fri, Jan 16, 2009 at 09:07:50PM +0100, Fabian Deutsch wrote: > > Hello, > > > > There are a couple of issues I ran into: > > - Can I explicitly require a java package not just to be installed, but > > also to be the the selected alternative? > > (openjdk ist required at build- and runtime) > > I did that for tetex-tex4ht, copying what was done in freecol. > > > - What about missing dependencies? > > There are some jars required which are not packed up in Fedora yet. > > I'm not allowed to use the binary-jars distributed in the hadoop > > tarball? > > Indeed you are not. They should be packaged in fedora. > > > - Scripts > > There are scripts to run hadoop and dfs (bin/start-all, stop-all, ...) > > Where shall I put them? Create a custom user, as postgres does? > > If hadoop runs as a daemon, it should not run as root but as a > special user. And you can do an initscript for fedora, to integrate well > with init daemon management. But since I have no ieda what hadoop is, > I may be telling nonsensical stuff. > > In any case, and especially for your first package and an hard package, > you can submit a review request with a non-perfect package, as long as > you tell it clearly in a comment. > > As a side note, in general this list should not be used for > packaging questions, unless you have in mind a needed change in > guidelines to accomodate your package. The development questions should > better go to fedora-devel-list, since here it is more to discuss > packaging guidelines than for help on existing guidelines. Thanks for this hint. I'll use a different list teh next time, didn't realize that it was the wrong lsit. - fabian > -- > Pat > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging From mschwendt at gmail.com Sun Jan 18 12:42:25 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 18 Jan 2009 13:42:25 +0100 Subject: [Fedora-packaging] Reviewing explicit Requires In-Reply-To: <1232117549.4394.15.camel@localhost.localdomain> References: <20090116114123.6931b802.mschwendt@gmail.com> <1232117549.4394.15.camel@localhost.localdomain> Message-ID: <20090118134225.64fc8eeb.mschwendt@gmail.com> On Fri, 16 Jan 2009 09:52:29 -0500, Tom wrote: > On Fri, 2009-01-16 at 11:41 +0100, Michael Schwendt wrote: > > Does anyone remember where the paragraph has gone, which commented on > > the badness of explicit dependencies on package names? > > I'm not sure there was ever such a paragraph. Would you like to propose > one? SHOULD: Reviewer should examine an RPM package's list of dependencies and (1) eliminate superfluous explicit ''Requires'' within the spec file and (2) ensure that any non-superfluous or versioned explicit ''Requires'' are explained in comments in the spec file. In particular, we rely on rpmbuild's automatically added dependencies on library SONAMEs. Modern package management tools are capable of resolving such dependencies to determine the required packages. Explicit dependencies on specific package names may aid the inexperienced user, who attempts at installing RPM packages manually. However, history has shown that such dependencies add confusion when library/files are moved from one package to another, when packages get renamed, when one out of multiple alternative packages would suffice, and when versioned explicit dependencies become out-of-date and inaccurate. Additionally, in some cases, old explicit dependencies on package names require unnecessary updates/rebuilds (for example, after renaming a packge, virtual package names are not kept forever). Exemplary rationale for a versioned explicit dependency: # The automatic dependency on libfubar.so.1 is insufficient, # as we strictly need at least the release that fixes two segfaults. Requires: libfubar >= 0:1.2.3-7 Packager should revisit an explicit versioned dependency as appropriate to avoid that it becomes inaccurate and superfluous. From tmz at pobox.com Sun Jan 18 17:22:39 2009 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 18 Jan 2009 12:22:39 -0500 Subject: [Fedora-packaging] Missing example text on Packaging/LicensingGuidelines Message-ID: <20090118172239.GT18365@inocybe.teonanacatl.org> It seems that some text went missing from the example on multiple licensing scenarios during the wiki conversion. Compare: https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios https://fedoraproject.org/wikiold/Packaging/LicensingGuidelines#line-79 The text in the example should be more like this: # The entire source code is GPLv2+ except foolib/ which is BSD License: GPLv2+ and BSD -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It's not denial. I'm just very selective about what I accept as reality. -- Calvin ("Calvin and Hobbes") -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From a.badger at gmail.com Sun Jan 18 19:51:25 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 18 Jan 2009 11:51:25 -0800 Subject: [Fedora-packaging] Missing example text on Packaging/LicensingGuidelines In-Reply-To: <20090118172239.GT18365@inocybe.teonanacatl.org> References: <20090118172239.GT18365@inocybe.teonanacatl.org> Message-ID: <4973883D.9000907@gmail.com> Todd Zullinger wrote: > It seems that some text went missing from the example on multiple > licensing scenarios during the wiki conversion. Compare: > > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Multiple_Licensing_Scenarios > https://fedoraproject.org/wikiold/Packaging/LicensingGuidelines#line-79 > > The text in the example should be more like this: > > # The entire source code is GPLv2+ except foolib/ which is BSD > License: GPLv2+ and BSD > Fixed that and the last example. Thanks for reporting this! -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jonathan.underwood at gmail.com Mon Jan 19 00:31:42 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 19 Jan 2009 00:31:42 +0000 Subject: [Fedora-packaging] Emacs add-on packaging and triggers Message-ID: <645d17210901181631p9be1fbdwa2de90edab36a567@mail.gmail.com> Hi, The current (X)Emacs add-on packaging guidelines cover how to package add-on packages for (x)emacs, such as things like AuCTeX, Muse etc. These guidelines also cover the situation where a package Foo has a few Emacs helper files (eg. which add a mode to emacs to be used with the main package) - presently the guidelines stipulate that the emacs files are placed in a sub-package, emacs-foo. For example, the main gnuplot package creates a sub-package called emacs-gnuplot containing the files to enhance editing of gnuplot input in Emacs. Other examples include emacs-git, emacs-mercurial etc etc. It is this sort of situation that this present email is concerned with i.e. where a package is not principally an add-on for Emacs, but adds some elisp support files for the program. When I was drafting the guidelines there was a different practice that I wasn't aware of at the time whereby the elisp files are packaged with the *main* package (i.e. not an emacs-foo subpackage) and triggers are used to create symlinks to these files in the Emacs tree when/if Emacs is installed. Amongst other things, this negates the need for the package to have Emacs as a dependency. Examples include rpmdevtools, maxima and others. Briefly, this strategy is schematically below for a single file. I'm not using %_datadir etc macros for clarity: %install ... install foo-mode.el %{buildroot}/usr/share/foo/emacs/foo.el install %{buildroot}/usr/share/emacs/site-lisp{,/site-start.d} ln -s %{buildroot}/usr/share/foo/emacs/ %{buildroot}/usr/share/emacs/site-lisp/foo ... %triggerin -- emacs-common if [ -d /usr/share/emacs/site-lisp ]; then rm -rf /usr/share/emacs/site-lisp/foo ln -sf /usr/share/foo/emacs /usr/emacs/site-lisp/foo/ ||: fi %triggerun -- emacs-common if [ $2 -eq 0 ]; then rm -rf /usr/share/emacs/site-lisp/foo ||: fi %files ... %ghost /usr/share/emacs/site-lisp .... I've simplified the above for clarity just to convey the essence of it, and obviously the same strategy applies to xemacs. Also I've skipped any byte compilation details. One of the things that should jump out at you is that every package adopting this strategy will own /usr/share/emacs/site-lisp - a directory owned by the emacs-common package. The key question is: do we want to be allowing this strategy verses the alternative of having a separate emacs-foo subpackage? On the plus side it allows the user to not have to go hunting to install an emacs-foo add on package after she's installed foo in order to get emacs support working. And it manages to do this without the package foo pulling in Emacs. On the negative side it uses triggers, and is (in my opinion) more complex than a separate sub-package. Nicholas Mailhot in a discussion related to this issue voiced concerns that "triggers are very difficult to maintain and master long term since it's code from one package that fires when another package is installed with not warning, making install logs useless to understand problems."[1] I'd like to get opinions on this issue with a view to drafting a change to the emacs add-on packaging guidelines IF this strategy is considered acceptable. On the other hand, if this sort of thing isn't acceptable I'd like to help fixing the packages which do use this strategy presently. Right now, I personally have mixed feelings about it, and I would very much welcome other thoughts. Best wishes, Jonathan. [1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg00186.html (and other messages in the thread). From petersen at redhat.com Tue Jan 20 08:41:49 2009 From: petersen at redhat.com (Jens Petersen) Date: Tue, 20 Jan 2009 03:41:49 -0500 (EST) Subject: [Fedora-packaging] Emacs add-on packaging and triggers In-Reply-To: <645d17210901181631p9be1fbdwa2de90edab36a567@mail.gmail.com> Message-ID: <928943253.373371232440909394.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> > The key question is: do we want to be allowing this strategy verses > the alternative of having a separate emacs-foo subpackage? I think we should recommend separate packages in the guidelines going forward, and use improvements in conditional install package handling in yum to handle their installation. That would be good for all new packages though a bit of work to subpackage for old packages. Jens From petersen at redhat.com Tue Jan 20 09:28:51 2009 From: petersen at redhat.com (Jens Petersen) Date: Tue, 20 Jan 2009 04:28:51 -0500 (EST) Subject: [Fedora-packaging] RFC: revision of Haskell Packaging Guidelines In-Reply-To: <1122468587.378731232443079594.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1800541320.379841232443731650.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Hi, I would like to solicit comments on the revised Haskell Packaging Guidelines, which have been updated and fixed a fair bit since the initial draft was first approved. https://fedoraproject.org/wiki/PackagingDrafts/Haskell cabal2spec which packages the latest packaging templates and generates spec files from haskell packages is currently under review: https://bugzilla.redhat.com/show_bug.cgi?id=479803. The new draft has been used successfully to review several packages now recently and older packages are mostly up-to-date with them too. If there are no obvious serious flaws then I would like to submit the revision to Fedora Packaging Committee for review. Thank you, Jens Petersen From jonathan.underwood at gmail.com Tue Jan 20 14:21:56 2009 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 20 Jan 2009 14:21:56 +0000 Subject: [Fedora-packaging] Emacs add-on packaging and triggers In-Reply-To: <928943253.373371232440909394.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <645d17210901181631p9be1fbdwa2de90edab36a567@mail.gmail.com> <928943253.373371232440909394.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <645d17210901200621g62107089qedce95a93269327f@mail.gmail.com> 2009/1/20 Jens Petersen : >> The key question is: do we want to be allowing this strategy verses >> the alternative of having a separate emacs-foo subpackage? > > I think we should recommend separate packages in the guidelines going forward, and use improvements in conditional install package handling in yum to handle their installation. That would be good for all new packages though a bit of work to subpackage for old packages. > This seems like a good stance to me too. Will the new yum finctionality be able to handle the following ... 1) User installs package foo, but not package emacs-foo, as he doesn't have emacs installed. 2) User installs emacs ... where at step 2, it would be nice if yum would suggest but not mandate installing emacs-foo. From pmatilai at laiskiainen.org Wed Jan 21 14:02:17 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 21 Jan 2009 16:02:17 +0200 (EET) Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <1231943656.5086.50.camel@localhost.localdomain> References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> Message-ID: On Wed, 14 Jan 2009, Jesse Keating wrote: > On Wed, 2009-01-14 at 10:14 +0100, Ralf Corsepius wrote: >> sigh, some people will never understand that keeping timestamps is >> painting bikesheds :( > > Keeping timestamps avoids file conflicts on multilib packages. Nope, timestamps of files are not considered a conflict. Time stamps *in* generated files are what causes conflicts, as the content checksums wont match. Take for example man- or info-pages: they get compressed at build time so the time stamps will always be different between different builds, no matter what the timestamp of the original file was. If timestamps caused conflicts, no such file could ever be shared even though the content is identical. The only thing keeping timestamps will help somewhat is avoiding timestamp difference whining on verification with older rpm versions, 4.6.0 filters them out on shared files (as timestamps are not considered a conflict at install time, it's bogus to consider it a verification failure either). - Panu - From pertusus at free.fr Wed Jan 21 14:10:31 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 21 Jan 2009 15:10:31 +0100 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> Message-ID: <20090121141031.GA3284@free.fr> On Wed, Jan 21, 2009 at 04:02:17PM +0200, Panu Matilainen wrote: > > Take for example man- or info-pages: they get compressed at build time so > the time stamps will always be different between different builds, no > matter what the timestamp of the original file was. If timestamps caused > conflicts, no such file could ever be shared even though the content is > identical. If I remembmer well, in fedora, man pages timestamps are kept, even if gzipped. > The only thing keeping timestamps will help somewhat is avoiding > timestamp difference whining on verification with older rpm versions, > 4.6.0 filters them out on shared files (as timestamps are not considered > a conflict at install time, it's bogus to consider it a verification > failure either). Ok. then this is not an issue anymore. -- Pat From pmatilai at laiskiainen.org Wed Jan 21 14:22:41 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 21 Jan 2009 16:22:41 +0200 (EET) Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <20090121141031.GA3284@free.fr> References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> <20090121141031.GA3284@free.fr> Message-ID: On Wed, 21 Jan 2009, Patrice Dumas wrote: > On Wed, Jan 21, 2009 at 04:02:17PM +0200, Panu Matilainen wrote: >> >> Take for example man- or info-pages: they get compressed at build time so >> the time stamps will always be different between different builds, no >> matter what the timestamp of the original file was. If timestamps caused >> conflicts, no such file could ever be shared even though the content is >> identical. > > If I remembmer well, in fedora, man pages timestamps are kept, even if > gzipped. I don't see any attempt to do time stamp preservation in brp-compress (and evidence from packages says the same), would be possible of course if somebody cared enough :) Hmm, would be easy even, as "touch" appears to have the perfect option for it: -r, --reference=FILE use this file?s times instead of current time - Panu - From mtasaka at ioa.s.u-tokyo.ac.jp Wed Jan 21 14:42:18 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 21 Jan 2009 23:42:18 +0900 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> <20090121141031.GA3284@free.fr> Message-ID: <4977344A.6040401@ioa.s.u-tokyo.ac.jp> Panu Matilainen wrote, at 01/21/2009 11:22 PM +9:00: > On Wed, 21 Jan 2009, Patrice Dumas wrote: > >> On Wed, Jan 21, 2009 at 04:02:17PM +0200, Panu Matilainen wrote: >>> >>> Take for example man- or info-pages: they get compressed at build >>> time so >>> the time stamps will always be different between different builds, no >>> matter what the timestamp of the original file was. If timestamps caused >>> conflicts, no such file could ever be shared even though the content is >>> identical. >> >> If I remembmer well, in fedora, man pages timestamps are kept, even if >> gzipped. > > I don't see any attempt to do time stamp preservation in brp-compress > (and evidence from packages says the same), would be possible of course > if somebody cared enough :) Hmm, would be easy even, as "touch" appears > to have the perfect option for it: > > -r, --reference=FILE > use this file?s times instead of current time > > - Panu - gzip itself keeps timestamps by default (man page also says: By default, gzip keeps the original file name and timestamp in the compressed file) Mamoru From pmatilai at laiskiainen.org Wed Jan 21 15:28:02 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 21 Jan 2009 17:28:02 +0200 (EET) Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <4977344A.6040401@ioa.s.u-tokyo.ac.jp> References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> <20090121141031.GA3284@free.fr> <4977344A.6040401@ioa.s.u-tokyo.ac.jp> Message-ID: On Wed, 21 Jan 2009, Mamoru Tasaka wrote: > Panu Matilainen wrote, at 01/21/2009 11:22 PM +9:00: >> On Wed, 21 Jan 2009, Patrice Dumas wrote: >> >>> On Wed, Jan 21, 2009 at 04:02:17PM +0200, Panu Matilainen wrote: >>>> >>>> Take for example man- or info-pages: they get compressed at build time so >>>> the time stamps will always be different between different builds, no >>>> matter what the timestamp of the original file was. If timestamps caused >>>> conflicts, no such file could ever be shared even though the content is >>>> identical. >>> >>> If I remembmer well, in fedora, man pages timestamps are kept, even if >>> gzipped. >> >> I don't see any attempt to do time stamp preservation in brp-compress (and >> evidence from packages says the same), would be possible of course if >> somebody cared enough :) Hmm, would be easy even, as "touch" appears to >> have the perfect option for it: >> >> -r, --reference=FILE >> use this file?s times instead of current time >> >> - Panu - > > gzip itself keeps timestamps by default (man page also says: > By default, gzip keeps the original file name and timestamp in the compressed > file) Ah, so it seems, I had never noticed that. The differences simply then come from the fact that the files are build-time generated, one way or the other. Just as an example of it, glibc generates it's *.info documentation from *.texi sources, so the timestamps differ regardless of gzip preserving it: [pmatilai at localhost ~]$ rpm -q --qf "[%{filemtimes} %{filenames}\n]" glibc-devel.x86_64|grep info| head -2 1228741245 /usr/share/info/libc.info-1.gz 1228741245 /usr/share/info/libc.info-10.gz [pmatilai at localhost ~]$ rpm -q --qf "[%{filemtimes} %{filenames}\n]" glibc-devel.i386|grep info| head -2 1228741252 /usr/share/info/libc.info-1.gz 1228741252 /usr/share/info/libc.info-10.gz - Panu - From pertusus at free.fr Wed Jan 21 15:32:45 2009 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 21 Jan 2009 16:32:45 +0100 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> <20090121141031.GA3284@free.fr> <4977344A.6040401@ioa.s.u-tokyo.ac.jp> Message-ID: <20090121153245.GC2531@free.fr> On Wed, Jan 21, 2009 at 05:28:02PM +0200, Panu Matilainen wrote: > > The differences simply then come from the fact that the files are > build-time generated, one way or the other. Just as an example of it, > glibc generates it's *.info documentation from *.texi sources, so the > timestamps differ regardless of gzip preserving it: This is quite unusual, in general info pages are pregenerated, to avoid issues with makeinfo version mismatches. Also it is possible, in such cases to use another timestamp (here, for example, the VERSION.texi or similar timestamp) with touch -r to correct timestamps. Some people consider that it is over-engineering, other like to do it. -- Pat From rc040203 at freenet.de Wed Jan 21 15:45:31 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 Jan 2009 16:45:31 +0100 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <20090121153245.GC2531@free.fr> References: <20090114090049.GA6751@amd.home.annexia.org> <496DACE9.4070601@freenet.de> <1231943656.5086.50.camel@localhost.localdomain> <20090121141031.GA3284@free.fr> <4977344A.6040401@ioa.s.u-tokyo.ac.jp> <20090121153245.GC2531@free.fr> Message-ID: <4977431B.8050306@freenet.de> Patrice Dumas wrote: > On Wed, Jan 21, 2009 at 05:28:02PM +0200, Panu Matilainen wrote: >> The differences simply then come from the fact that the files are >> build-time generated, one way or the other. Just as an example of it, >> glibc generates it's *.info documentation from *.texi sources, so the >> timestamps differ regardless of gzip preserving it: > > This is quite unusual, in general info pages are pregenerated, to avoid > issues with makeinfo version mismatches. Also it is possible, in such > cases to use another timestamp (here, for example, the VERSION.texi or > similar timestamp) with touch -r to correct timestamps. Some people > consider that it is over-engineering, other like to do it. Please explain, which _bug_ in Fedora's glibc rpm this would fix. From a.badger at gmail.com Wed Jan 21 23:53:08 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 21 Jan 2009 15:53:08 -0800 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <20090114090049.GA6751@amd.home.annexia.org> References: <20090114090049.GA6751@amd.home.annexia.org> Message-ID: <4977B564.1020209@gmail.com> Richard W.M. Jones wrote: > While a package was being reviewed, the reviewer picked up on a use of > the 'dos2unix --keepdate' command: > > https://bugzilla.redhat.com/show_bug.cgi?id=478640 > > The guidelines do indeed say not to use dos2unix, because quote "that > can cause build fail on FC3" (like I care). > > http://fedoraproject.org/wiki/Packaging/Guidelines#Rpmlint_Errors > This discussion has ranged far afield of the original post. So, does anyone know of a reason to keep the dos2unix warning? Does it affect EPEL4? If that's the only place we need to worry about, we should mention it but see no reason to definitively say not to use it. -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 nicolas.mailhot at laposte.net Thu Jan 22 09:25:38 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 22 Jan 2009 10:25:38 +0100 (CET) Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <4977B564.1020209@gmail.com> References: <20090114090049.GA6751@amd.home.annexia.org> <4977B564.1020209@gmail.com> Message-ID: <424ca2d8359383baec99c1e195e14c97.squirrel@arekh.dyndns.org> Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a ?crit : > This discussion has ranged far afield of the original post. > > So, does anyone know of a reason to keep the dos2unix warning? Is there anything dos2unix does which can not be done by standard tools like sed? for txt in *.txt ; do iconv -f WINDOWS-1252 -t UTF-8 -o $txt.1 $txt fold -s $txt.1 > $txt.2 sed -i 's/\r//' $txt.2 touch -r $txt $txt.2 mv $txt.2 $txt rm $txt.1 done -- Nicolas Mailhot From a.badger at gmail.com Thu Jan 22 10:13:39 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 22 Jan 2009 02:13:39 -0800 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <424ca2d8359383baec99c1e195e14c97.squirrel@arekh.dyndns.org> References: <20090114090049.GA6751@amd.home.annexia.org> <4977B564.1020209@gmail.com> <424ca2d8359383baec99c1e195e14c97.squirrel@arekh.dyndns.org> Message-ID: <497846D3.1020501@gmail.com> Nicolas Mailhot wrote: > > Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a ?crit : > >> This discussion has ranged far afield of the original post. >> >> So, does anyone know of a reason to keep the dos2unix warning? > > Is there anything dos2unix does which can not be done by standard > tools like sed? > > for txt in *.txt ; do > iconv -f WINDOWS-1252 -t UTF-8 -o $txt.1 $txt > fold -s $txt.1 > $txt.2 > sed -i 's/\r//' $txt.2 > touch -r $txt $txt.2 > mv $txt.2 $txt > rm $txt.1 > done > I don't know of any. But we shouldn't be telling people they must not use dos2unix (with a proper BuildRequires) if there's no actual problem. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Thu Jan 22 11:02:31 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 22 Jan 2009 12:02:31 +0100 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <424ca2d8359383baec99c1e195e14c97.squirrel@arekh.dyndns.org> References: <20090114090049.GA6751@amd.home.annexia.org> <4977B564.1020209@gmail.com> <424ca2d8359383baec99c1e195e14c97.squirrel@arekh.dyndns.org> Message-ID: <49785247.5060706@freenet.de> Nicolas Mailhot wrote: > > Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a ?crit : > >> This discussion has ranged far afield of the original post. >> >> So, does anyone know of a reason to keep the dos2unix warning? > > Is there anything dos2unix does which can not be done by standard > tools like sed? Your consideration defeats the purpose of using tools. It's their purpose to avoid such scripts. Ralf From tcallawa at redhat.com Thu Jan 22 15:08:48 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 22 Jan 2009 10:08:48 -0500 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <497846D3.1020501@gmail.com> References: <20090114090049.GA6751@amd.home.annexia.org> <4977B564.1020209@gmail.com> <424ca2d8359383baec99c1e195e14c97.squirrel@arekh.dyndns.org> <497846D3.1020501@gmail.com> Message-ID: <1232636928.3807.13.camel@localhost.localdomain> On Thu, 2009-01-22 at 02:13 -0800, Toshio Kuratomi wrote: > I don't know of any. But we shouldn't be telling people they must not > use dos2unix (with a proper BuildRequires) if there's no actual problem. dos2unix has a history of not working properly on sparc, but I wouldn't consider that guideline-worthy. ~spot From gavin at redhat.com Wed Jan 21 23:09:44 2009 From: gavin at redhat.com (Gavin Romig-Koch) Date: Wed, 21 Jan 2009 18:09:44 -0500 Subject: [Fedora-packaging] Squeak and Etoys packages Message-ID: <4977AB38.4060000@redhat.com> This is some background information about the Squeak and Etoys packages. The Etoys package is an important part of the XO software that we are trying to move into Fedora, and Etoys depends on Squeak. I've just submitted for review (BZ481056) the first of three packages that make up the Squeak and Etoys packages that I've been working on. I'll submit the other two packages for review as soon as I finish this note. There has been some issues with these packages in the past, in part licensing issues, in part because Squeak and Etoys are somewhat different than anything else. The licensing issues have been resolved, these packages are now under Fedora acceptable licenses. This email is an attempt to address the other issues. This is very long, for which I apologize. I've tried to be through, perhaps too much so. If I can answer any questions, please ask. I think it is useful for anyone reviewing the Squeak and Etoys RPM packages to understand the high level organization of Squeak and Etoys. It is possible that these packages may require some exceptions to the Fedora Packaging Guidelines. Squeak is an implementation of the Smalltalk-80 programming environment. Like most Smalltalk implementations, Squeak is not just a programming language, but also contains a set of software development tools for editing, understanding, documenting, storing, and distributing Smalltalk source code. Squeak is implemented as a virtual machine/image pair. The Squeak virtual machine is analogous to the Java virtual machine in that in both cases they are native host programs which implement a virtual machine specific to the language in question. One major difference between the Squeak and Java virtual machines is that whereas the Java virtual machine loads a set of ".class" files which were compiled from Java source code stored separately in native 'text' files, the Squeak virtual machine loads a single Image (a squeak virtual machine image) which contains both the Squeak source code and the compiled (byte) code that runs on the Squeak virtual machine. Squeak source is stored in, edited in, distributed between, and compiled from and into an image file running in a Squeak virtual machine. While it is possible to write Squeak source code out to a native 'text' file, this is not commonly done, and not the way that Squeak source code is typically edited or distributed. The standard Squeak image contains all the source code for itself, as well as all the tools one typically uses to create and edit programs (editors, compilers, source code control, search and diff, change distribution, ...) built into itself. To get Squeak running, one needs both a Squeak Image (an image) and a Squeak Virtual Machine (a vm). There is a 'standard' Squeak image distributed by the Squeak project. It is the image that most people use when running Squeak. Like all Squeak images it contains both the source and compiled (bytecode) forms of the code in that image, and is the expected way that one views and edits Smalltalk source code. There are also a number of other Squeak images distributed for specialized purposes. Etoys, for example, is a specialized Squeak image, as well as some wrapper shell scripts to make starting it easy. The squeak-image SRPM and RPM contain the "standard" Squeak image distributed by the Squeak project. This image is installed under /usr/share/squeak, and copied into directories owned by users user when the user starts Squeak for the first time. As stated above, the Squeak Virtual Machine (vm) is a native host program which loads and interprets the bytecode within a Squeak Image. The source for the vm consists of two main parts: the core interpreter, and a large set of plugins which provide the core interpreter with access to OS and environment specific features (like X, GStreamer, and DBus on Linux). The core interpreter is written in a restricted form of Smalltalk and maintained and distributed using the standard Squeak software development tools. The plugins are written in C and maintained and distributed as C source files typically are. The core vm is compiled from the restricted Smalltalk into C, this compiled C code for the core interpreter is combined with the plugins, and this combination is what is distributed by the SqueakVM project, and is what most people use as the source for building the Squeak vm. While it is possible to create a Squeak VM from from the original restricted Smalltalk stored in the Squeak image, it requires a working Squeak VM to build a new Squeak VM from those original sources. The squeak-vm SRPM contains the source distributed by the SqueakVM project, and that is compiled into the squeak-vm RPM. In preparing these packages, I have come up with several ways in which these packages may fall outside the Fedora Packaging guidelines. The first is that its possible that the "No inclusion of pre-built binaries or libraries" rule applies to the Squeak images included in both the squeak-image SRPM and RPM. My understanding of this Guidelines is that it is meant to apply only to executable binaries which does not include the Squeak image. Even if my understanding is not correct, the Squeak image contains both to source and compiled forms of all of the code it contains, and is the natural form in which Squeak/Smalltalk programmers work with Squeak/Smalltalk code. A second way in which these packages may fall outside the Fedora Packaging guidelines is the fact that the source code for the core interpreter part of the Squeak VM included in the squeak-vm SRPM is not the original restricted Smalltalk source for this code, but is instead the C source code created by compiling this original restricted Smalltalk into C. While I could not find a guideline explicitly forbidding this, it is possible that this could be outside the spirit of the guidelines. To be clear the source included in the SRPM _is_ the source distributed by the upsteam project, it's just not the original restricted Smalltalk source for the core interpreter. I've packaged it this way for several reasons. First, compiling from the original restricted Smalltalk to C requires a working Squeak system - a chicken and egg problem. Second, all existing Squeak distributions compile the Squeak VM from the C source; if Fedora were to build it's Squeak VM from the original restricted Smalltalk there is a small chance that the built Squeak VM might be incompatible with other Squeak VMs. I felt that, particularly for our first official release, we should minimize this possibility. Finally, while the upstream SqueakVM project does distribute the original restricted Smalltalk code for the core interpreter (in a specialized Squeak image), and the needed tools and instructions for building the C source from this Smalltalk source, they are not yet rigorous enough in their release process to insure that the C source produced from these images is exactly the same as the C source they distribute. Because everyone uses the C source they distribute (unless the explicitly want to build a non-standard VM), the needed rigor has never been a priority. For these three reasons, I ask the Packaging Committee to either decided that that this is not a violation of the Guidelines, or grant an exception for this case. A third way these packages may fall outside the guidelines is that the Etoys package uses locales, but does not use find_lang. The Etoys package puts it's local files in .../share/etoys/locale/..., but the find_lang macro (as of F9) only looks in .../share/locale/.... I do not know if this a a find_lang bug (find_lang should be looking in more places) or a Etoys bug (etoys should not put it's locale files in it's own special special place), and I have not taken the time to figure out which. I'm sorry. If someone can tell me which is wrong, I'll see about getting it fixed. Of course these packages fall outside the guidelines in other ways through my failure to understand or implement them correctly, but these are the ways that I'm currently aware of. I've run rpmlint on the spec files, the srpms and rpms. There were three warnings I felt I could not or should not 'fix', they are documented in the BZ. -gavin... From nicolas.mailhot at laposte.net Thu Jan 22 21:10:04 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 22 Jan 2009 22:10:04 +0100 Subject: [Fedora-packaging] Check for fonts during package review Message-ID: <1232658604.27177.2.camel@arekh.okg> Hi, As discussed during last FPC meeting, I've queued this (one-line) addition for FPC review http://fedoraproject.org/wiki/PackagingDrafts/ReviewGuideline_for_fonts_(2009-01-22) -- 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 denis at poolshark.org Fri Jan 23 10:39:37 2009 From: denis at poolshark.org (Denis Leroy) Date: Fri, 23 Jan 2009 11:39:37 +0100 Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <497846D3.1020501@gmail.com> References: <20090114090049.GA6751@amd.home.annexia.org> <4977B564.1020209@gmail.com> <424ca2d8359383baec99c1e195e14c97.squirrel@arekh.dyndns.org> <497846D3.1020501@gmail.com> Message-ID: <49799E69.5060201@poolshark.org> Toshio Kuratomi wrote: > Nicolas Mailhot wrote: >> Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a ??crit : >> >>> This discussion has ranged far afield of the original post. >>> >>> So, does anyone know of a reason to keep the dos2unix warning? >> Is there anything dos2unix does which can not be done by standard >> tools like sed? >> >> for txt in *.txt ; do >> iconv -f WINDOWS-1252 -t UTF-8 -o $txt.1 $txt >> fold -s $txt.1 > $txt.2 >> sed -i 's/\r//' $txt.2 >> touch -r $txt $txt.2 >> mv $txt.2 $txt >> rm $txt.1 >> done >> > I don't know of any. The whole point is to replace those 8 confusing lines of scripting with a simple call. It makes the spec file easier to read. > But we shouldn't be telling people they must not > use dos2unix (with a proper BuildRequires) if there's no actual problem. +1 From nicolas.mailhot at laposte.net Fri Jan 23 11:04:05 2009 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 23 Jan 2009 12:04:05 +0100 (CET) Subject: [Fedora-packaging] Use of dos2unix in %prep In-Reply-To: <49799E69.5060201@poolshark.org> References: <20090114090049.GA6751@amd.home.annexia.org> <4977B564.1020209@gmail.com> <424ca2d8359383baec99c1e195e14c97.squirrel@arekh.dyndns.org> <497846D3.1020501@gmail.com> <49799E69.5060201@poolshark.org> Message-ID: <7d1fc5c39861faa9ac216391044d17f4.squirrel@arekh.dyndns.org> Le Ven 23 janvier 2009 11:39, Denis Leroy a ?crit : > > Toshio Kuratomi wrote: >> Nicolas Mailhot wrote: >>> Le Jeu 22 janvier 2009 00:53, Toshio Kuratomi a ??crit : >>> >>>> This discussion has ranged far afield of the original post. >>>> >>>> So, does anyone know of a reason to keep the dos2unix warning? >>> Is there anything dos2unix does which can not be done by standard >>> tools like sed? >>> >>> for txt in *.txt ; do >>> iconv -f WINDOWS-1252 -t UTF-8 -o $txt.1 $txt >>> fold -s $txt.1 > $txt.2 >>> sed -i 's/\r//' $txt.2 >>> touch -r $txt $txt.2 >>> mv $txt.2 $txt >>> rm $txt.1 >>> done >>> >> I don't know of any. > > The whole point is to replace those 8 confusing lines of scripting > with simple call. It makes the spec file easier to read. But this simple call does not do half of the stuff of those 8 lines. It only replaces the sed -i 's/\r//' $txt part -- Nicolas Mailhot From susan_lists at ties.org Sat Jan 24 01:18:18 2009 From: susan_lists at ties.org (susan_lists at ties.org) Date: Fri, 23 Jan 2009 20:18:18 -0500 Subject: [Fedora-packaging] Intro and wiki info Message-ID: Greetings, I thought I should introduce myself to the packaging list and devel list. I'm here to help with documentation in general and packaging related wiki pages specifically. This includes the Packaging:, PackageMaintainers/*, and PackagingDrafts/* pages of the wiki. My immediate tasks include helping with page naming and categories to aid with searches. I am also available to assist with any proofreading. My $dayjob is mostly teaching and mostly for Red Hat (RHCE and RHCA classes). I've been *nix user and admin and instructor for years but I am fairly new as contributer. I have started out helping with the Fedora Docs Project and after meeting several people at FUDConF11, accepted the lead on the docs team side for the packaging docs. It is really a liaison position between the docs team and the packaging team and other contributors to packaging documentation. In addition to the renaming, categorizing, and proofreading, I am sure I will be helping with moving the Packaging Guidelines to the CMS when we decide on a system and I have DocBook experience to assist if any of the pages move to XML for other publishing. >From a docs side, the first thing that needs to occur is some renaming and categorization. Since it is a wiki and it is easy to undo changes, I am going to dig in add some categories and then start some page renaming. I won't be offended if anything gets undone but I hope that those who have worked so hard to get the pages where they are will also jump in with some suggestions. Here are some links that will help explain what needs to occur: https://fedoraproject.org/wiki/Help:Wiki_structure - This page explains page naming, namespaces, and categories. https://fedoraproject.org/wiki/User:Ianweller/Wiki_tip_of_the_week - The first week is about moving pages (preview available now) For example the current page [[PackageMaintainers/MaintainerResponsibility]] would not currently be found in a search for either "package" or "maintainers" because the mediawiki search uses whole word searches only. We also want to eliminate the hierarchy. A better name would be [[Package maintainer responsibilities]]. I was looking at the page https://fedoraproject.org/wiki/PackageMaintainersand see a lot of good naming suggestions in the link names and descriptions. With renaming, categories, and subcategories we can even generate a similar page automatically. Check out the fonts pages for an example: https://fedoraproject.org/wiki/Category:Fonts Something similar can be done for https://fedoraproject.org/wiki/Category:Package_Maintainers I am still looking for suggestions for subcategories for the Package Maintainers pages. If there are pages that are old or no longer in use they can be moved to the Archive namespace. Simply click the move button at the top of the page and add Archive: at the beginning of the name. For instance PackageMaintainers/FC3Status has recently been moved to Archive:PackageMaintainers/FC3Status Anything pointing to the original name is automatically redirected to the new name. This way the page still exists and can be found with an advanced search but will not appear in default search that a visitor to the site may use. Can PackageMaintainers/PackageStatus/CompsF9Missing also be archived? Finally, there is a fedora-wiki mailing list that has announcements and tips, but is also a good place to ask questions and discuss names and categories. https://admin.fedoraproject.org/mailman/listinfo/fedora-wiki And I am often on #fedora-docs as laubersm (or some variation) but anyone there should also be able to help. I look forward to helping and I appreciate any suggestions. Thanks, Susan -- Susan Lauber, (RHCX, RHCA, RHCSS) Lauber System Solutions, Inc. http://www.laubersolutions.com gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Fedora at FamilleCollet.com Sun Jan 25 18:51:21 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sun, 25 Jan 2009 19:51:21 +0100 Subject: [Fedora-packaging] PHP Guidelines update proposal Message-ID: <497CB4A9.7010207@FamilleCollet.com> What I was thinking (in an quite old discussion, during initial PHP Guidelines writing) is now reality According to PHP Guidelines, pear extension must be named php-pear-. That's ok for standard pear.php.net channel. With non standard channel we can encounter conflicts. llaumgui is working on submitting ezComponents for review. http://ezcomponents.org/ For example, one of the extension is Mail and php-pear-Mail already exists. My proposal is : http://fedoraproject.org/wiki/PackagingDrafts/PHP With this proposal, ezComponents will be named php-ezc- Comments ? Remi. From itamar at ispbrasil.com.br Sun Jan 25 20:32:18 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Sun, 25 Jan 2009 18:32:18 -0200 Subject: [Fedora-packaging] PHP Guidelines update proposal In-Reply-To: <497CB4A9.7010207@FamilleCollet.com> References: <497CB4A9.7010207@FamilleCollet.com> Message-ID: for me is ok, go ahead On Sun, Jan 25, 2009 at 4:51 PM, Remi Collet wrote: > What I was thinking (in an quite old discussion, during initial PHP > Guidelines writing) is now reality > > According to PHP Guidelines, pear extension must be named > php-pear-. > > That's ok for standard pear.php.net channel. > > With non standard channel we can encounter conflicts. > > llaumgui is working on submitting ezComponents for review. > http://ezcomponents.org/ > > For example, one of the extension is Mail and php-pear-Mail already exists. > > My proposal is : > http://fedoraproject.org/wiki/PackagingDrafts/PHP > > With this proposal, ezComponents will be named > php-ezc- > > Comments ? > Remi. > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From Axel.Thimm at ATrpms.net Mon Jan 26 10:26:56 2009 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Jan 2009 12:26:56 +0200 Subject: [Fedora-packaging] Re: PHP Guidelines update proposal In-Reply-To: <497CB4A9.7010207@FamilleCollet.com> References: <497CB4A9.7010207@FamilleCollet.com> Message-ID: <20090126102656.GA10884@victor.nirvana> On Sun, Jan 25, 2009 at 07:51:21PM +0100, Remi Collet wrote: > What I was thinking (in an quite old discussion, during initial PHP > Guidelines writing) is now reality > > According to PHP Guidelines, pear extension must be named > php-pear-. > > That's ok for standard pear.php.net channel. > > With non standard channel we can encounter conflicts. > > llaumgui is working on submitting ezComponents for review. > http://ezcomponents.org/ > > For example, one of the extension is Mail and php-pear-Mail already exists. > > My proposal is : > http://fedoraproject.org/wiki/PackagingDrafts/PHP > > With this proposal, ezComponents will be named > php-ezc- > > Comments ? > Remi. Is it possible/does it make sense to coinstall php-pear-Foo and php-ezc-Foo or are they mutually exclusive? Or rephrased, if another package requires Foo, can both serve up? If this is the case then we probably need to think about solutions with virtual dependencies. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lists at timj.co.uk Mon Jan 26 13:53:48 2009 From: lists at timj.co.uk (Tim Jackson) Date: Mon, 26 Jan 2009 13:53:48 +0000 Subject: [Fedora-packaging] PHP Guidelines update proposal In-Reply-To: <497CB4A9.7010207@FamilleCollet.com> References: <497CB4A9.7010207@FamilleCollet.com> Message-ID: <497DC06C.5070603@timj.co.uk> Remi Collet wrote: > My proposal is : > http://fedoraproject.org/wiki/PackagingDrafts/PHP > > With this proposal, ezComponents will be named > php-ezc- Sounds fine to me, and is consistent with php-ZendFramework-*. Where will the files be installed in the filesystem and what will a "require" statement look like for code which needs ezC? Tim From Fedora at FamilleCollet.com Mon Jan 26 18:22:34 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 26 Jan 2009 19:22:34 +0100 Subject: [Fedora-packaging] Re: PHP Guidelines update proposal In-Reply-To: <20090126102656.GA10884@victor.nirvana> References: <497CB4A9.7010207@FamilleCollet.com> <20090126102656.GA10884@victor.nirvana> Message-ID: <497DFF6A.3040607@FamilleCollet.com> Axel Thimm a ?crit : > Is it possible/does it make sense to coinstall php-pear-Foo and > php-ezc-Foo or are they mutually exclusive? No. > > Or rephrased, if another package requires Foo, can both serve up? If > this is the case then we probably need to think about solutions with > virtual dependencies. Both provides same goals : a class to manage mail in PHP But both implementation are really different. - php-pear-Mail only provide simple "send" methods - php-ezc-Mail provide (complex) send and receive methods Of course a projet should use only one. Remi. From Fedora at FamilleCollet.com Mon Jan 26 18:35:37 2009 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 26 Jan 2009 19:35:37 +0100 Subject: [Fedora-packaging] PHP Guidelines update proposal In-Reply-To: <497DC06C.5070603@timj.co.uk> References: <497CB4A9.7010207@FamilleCollet.com> <497DC06C.5070603@timj.co.uk> Message-ID: <497E0279.4050407@FamilleCollet.com> Tim Jackson a ?crit : > Sounds fine to me, and is consistent with php-ZendFramework-*. :) (even is ZendFramework doesn't use pear mechanism, AFAIK) > Where will the files be installed in the filesystem /usr/share/pear (as for all pear extension) /usr/share/pear/ezc (as define in package.xml provided upstream) > and what will a "require" statement look like for code which needs ezC? Requires: php-pear(components.ez.no/Mail) or, of course (but probably a lesser solution) Requires: php-ezc-Mail Remi. From a.badger at gmail.com Tue Jan 27 22:00:01 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 27 Jan 2009 14:00:01 -0800 Subject: [Fedora-packaging] Intro and wiki info In-Reply-To: References: Message-ID: <497F83E1.8040208@gmail.com> susan_lists at ties.org wrote: > From a docs side, the first thing that needs to occur is some renaming > and categorization. Since it is a wiki and it is easy to undo changes, > I am going to dig in add some categories and then start some page > renaming. I won't be offended if anything gets undone but I hope that > those who have worked so hard to get the pages where they are will also > jump in with some suggestions. Following up on this for the Packaging Guidelines, Susan has been doing a great job with the renaming to be mediawiki friendly: http://git.fedorahosted.org/git/?p=wikirename.git;a=blob_plain;f=Packaging.psv;hb=HEAD The most frequent change is simply adding spaces into the names although a few things, like Meeting minutes are going into a different namespace or having a bit more explanation added to the title. -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 ville.skytta at iki.fi Tue Jan 27 23:36:36 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 28 Jan 2009 01:36:36 +0200 Subject: [Fedora-packaging] Suggested ScriptletSnippets (icon cache) changes Message-ID: <200901280136.37005.ville.skytta@iki.fi> Hello, I'd suggest the following changes to the "GTK+ icon cache" entry in Packaging:ScriptletSnippets: 1) Rename the entry to "Icon cache". It's not all about GTK+ but KDE as well. 2) Append " &>/dev/null" to the "touch" line in %postun. If "touch" is not available when the package is removed, I find it more than likely that GTK+ or KDE are not there to benefit from icon cache updates any longer either. /usr/share may also be mounted read only with %_netsharedpath. 3) Append " &>/dev/null" to the "touch" line in %post. If "touch" is not yet available, neither should be kdelibs, and thus there is no reason to touch the dir. kdelibs itself does a forced update in its %post. /usr/share may also be mounted read only with %_netsharedpath. (This avoids the need to add unnecessary "Requires(post): coreutils" to every package that installs icons just to quiet down a pretty rare and harmless warning.) 4) Remove the -x test and --quiet option to gtk-update-icon-cache, redirect all output (including stderr) to /dev/null. gtk-update-icon-cache may not be installed, /usr/share may be mounted read only with %_netsharedpath, etc... and the --quiet tells me that there was no interest in seeing g-u-i-c's stdout anyway. 5) Wrap %post in "if [ $1 -eq 1 ] ; then ..." to take care of the initial installation and let %postun handle package upgrade cases in order to eliminate one touch and one g-u-i-c invocation per package upgrade. I suppose this would be "safe enough" to do, it'd just result in possibly stale icon caches for the duration of the upgrade transaction. (Icons change relatively rarely, and even if they do, does this smallish stale cache window really matter at all?) So the scriptlets would become: %post if [ $1 -eq 1 ] ; then touch --no-create %{_datadir}/icons/hicolor &>/dev/null gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : fi %postun touch --no-create %{_datadir}/icons/hicolor &>/dev/null gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 28 08:09:25 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 28 Jan 2009 09:09:25 +0100 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <200901280136.37005.ville.skytta@iki.fi> (Ville Skytt's message of "Wed, 28 Jan 2009 01:36:36 +0200") References: <200901280136.37005.ville.skytta@iki.fi> Message-ID: <87r62n6edm.fsf@sheridan.bigo.ensc.de> Ville Skytt? writes: > So the scriptlets would become: > > %post > if [ $1 -eq 1 ] ; then > touch --no-create %{_datadir}/icons/hicolor &>/dev/null > gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : > fi > > %postun > touch --no-create %{_datadir}/icons/hicolor &>/dev/null > gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : Why not | %post | touch --no-create %{_datadir}/icons/hicolor &>/dev/null | | %postun | touch --no-create %{_datadir}/icons/hicolor &>/dev/null | | %posttrans | gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : ? All relevant Fedora releases should understand %posttrans and this speeds up things significantly. Enrico From bruno at wolff.to Wed Jan 28 14:03:41 2009 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 28 Jan 2009 08:03:41 -0600 Subject: [Fedora-packaging] Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <200901280136.37005.ville.skytta@iki.fi> References: <200901280136.37005.ville.skytta@iki.fi> Message-ID: <20090128140341.GA11051@wolff.to> On Wed, Jan 28, 2009 at 01:36:36 +0200, Ville Skytt? wrote: > > 2) Append " &>/dev/null" to the "touch" line in %postun. If "touch" is not > available when the package is removed, I find it more than likely that GTK+ > or KDE are not there to benefit from icon cache updates any longer > either. /usr/share may also be mounted read only with %_netsharedpath. The right way to do things is to make sure touch is available by having an approiate script dependency on the package that provides touch. Something like: Requires(pre): coreutils From rdieter at math.unl.edu Wed Jan 28 15:53:05 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Jan 2009 09:53:05 -0600 Subject: [Fedora-packaging] guideline for OnlyShowIn? Message-ID: Per: "Base KDE applications (e.g. ksysguard) should have OnlyShowIn=KDE" https://bugzilla.redhat.com/show_bug.cgi?id=481739 Prompted me to try to come up with a good/simple guideline when it is and is not appropriate to use OnlyShowIn. Problem is, I couldn't, not easily or quickly anyway. I thought I'd start on the packaging list first, any thoughts? -- Rex From notting at redhat.com Wed Jan 28 16:22:20 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Jan 2009 11:22:20 -0500 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <87r62n6edm.fsf@sheridan.bigo.ensc.de> References: <200901280136.37005.ville.skytta@iki.fi> <87r62n6edm.fsf@sheridan.bigo.ensc.de> Message-ID: <20090128162220.GA6735@nostromo.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > | %postun > | touch --no-create %{_datadir}/icons/hicolor &>/dev/null > | > | %posttrans > | gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : > > ? All relevant Fedora releases should understand %posttrans and this > speeds up things significantly. As posttrans isn't collated into a single run, it just moves the total of calls from point A to point B, and therefore would theoretically only speed things up via cache effects. Bill From rdieter at math.unl.edu Wed Jan 28 16:25:44 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Jan 2009 10:25:44 -0600 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <20090128162220.GA6735@nostromo.devel.redhat.com> References: <200901280136.37005.ville.skytta@iki.fi> <87r62n6edm.fsf@sheridan.bigo.ensc.de> <20090128162220.GA6735@nostromo.devel.redhat.com> Message-ID: <49808708.2000804@math.unl.edu> Bill Nottingham wrote: > Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: >> | %postun >> | touch --no-create %{_datadir}/icons/hicolor &>/dev/null >> | >> | %posttrans >> | gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : >> >> ? All relevant Fedora releases should understand %posttrans and this >> speeds up things significantly. > > As posttrans isn't collated into a single run, it just moves the total > of calls from point A to point B, and therefore would theoretically > only speed things up via cache effects. posttrans could be a win if the idea from https://bugzilla.redhat.com/show_bug.cgi?id=170335#c33 ever came to fruition. -- Rex From tcallawa at redhat.com Wed Jan 28 16:26:24 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Jan 2009 11:26:24 -0500 Subject: [Fedora-packaging] guideline for OnlyShowIn? In-Reply-To: References: Message-ID: <49808730.3010102@redhat.com> On 2009-01-28 at 10:53:05 -0500, Rex Dieter wrote: > Per: > "Base KDE applications (e.g. ksysguard) should have OnlyShowIn=KDE" > https://bugzilla.redhat.com/show_bug.cgi?id=481739 > > Prompted me to try to come up with a good/simple guideline when it is and is > not appropriate to use OnlyShowIn. Problem is, I couldn't, not easily or > quickly anyway. > > I thought I'd start on the packaging list first, any thoughts? Well, let me turn that around, when is it ever appropriate to use "OnlyShowIn="? I can't think of a case where it would be appropriate, aside from some sort of KDE or GNOME Configuration utility (and by that, I mean "a utility for configuring KDE/GNOME"). ~spot From rdieter at math.unl.edu Wed Jan 28 16:37:46 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Jan 2009 10:37:46 -0600 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <49808708.2000804@math.unl.edu> References: <200901280136.37005.ville.skytta@iki.fi> <87r62n6edm.fsf@sheridan.bigo.ensc.de> <20090128162220.GA6735@nostromo.devel.redhat.com> <49808708.2000804@math.unl.edu> Message-ID: <498089DA.5060504@math.unl.edu> Rex Dieter wrote: > Bill Nottingham wrote: >> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: >>> ? All relevant Fedora releases should understand %posttrans and this >>> speeds up things significantly. >> >> As posttrans isn't collated into a single run, it just moves the total >> of calls from point A to point B, and therefore would theoretically >> only speed things up via cache effects. > > posttrans could be a win if the idea from > https://bugzilla.redhat.com/show_bug.cgi?id=170335#c33 > ever came to fruition. nevermind, recalled that posttrans was previously considered and rejected, since posttrans isn't called on erasure (only install/upgrade). -- Rex From ville.skytta at iki.fi Wed Jan 28 16:46:40 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 28 Jan 2009 18:46:40 +0200 Subject: [Fedora-packaging] Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <20090128140341.GA11051@wolff.to> References: <200901280136.37005.ville.skytta@iki.fi> <20090128140341.GA11051@wolff.to> Message-ID: <200901281846.41234.ville.skytta@iki.fi> On Wednesday 28 January 2009, Bruno Wolff III wrote: > On Wed, Jan 28, 2009 at 01:36:36 +0200, > > Ville Skytt? wrote: > > 2) Append " &>/dev/null" to the "touch" line in %postun. If "touch" is > > not available when the package is removed, I find it more than likely > > that GTK+ or KDE are not there to benefit from icon cache updates any > > longer either. /usr/share may also be mounted read only with > > %_netsharedpath. > > The right way to do things is to make sure touch is available by > having an approiate script dependency on the package that provides touch. > Something like: > Requires(pre): coreutils The point of the suggestion I posted is to avoid *unnecessary* dependencies like this one as well as unnecessary calls to touch and gtk-update-icon-cache. The part of my original message you quoted above explains why I think it doesn't matter if touch is available at %postun time or not (my assumption is that coreutils can't be removed while gtk2 or kdelibs is installed). If I'm correct and it doesn't matter, "Requires(postun): coreutils" is just unnecessary bloat in repodata, rpmdb and spec files. From notting at redhat.com Wed Jan 28 17:52:45 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 Jan 2009 12:52:45 -0500 Subject: [Fedora-packaging] guideline for OnlyShowIn? In-Reply-To: <49808730.3010102@redhat.com> References: <49808730.3010102@redhat.com> Message-ID: <20090128175244.GC8239@nostromo.devel.redhat.com> Tom spot Callaway (tcallawa at redhat.com) said: > > I thought I'd start on the packaging list first, any thoughts? > > Well, let me turn that around, when is it ever appropriate to use > "OnlyShowIn="? I can't think of a case where it would be appropriate, > aside from some sort of KDE or GNOME Configuration utility (and by that, > I mean "a utility for configuring KDE/GNOME"). Part of the rationale is that someone on a system with both KDE and GNOME may not necessarily want to have two menu entries for an editor, two menu entries for a calculator, two menu entries for a terminal, etc. Bill From tcallawa at redhat.com Wed Jan 28 17:55:57 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Jan 2009 12:55:57 -0500 Subject: [Fedora-packaging] guideline for OnlyShowIn? In-Reply-To: <20090128175244.GC8239@nostromo.devel.redhat.com> References: <49808730.3010102@redhat.com> <20090128175244.GC8239@nostromo.devel.redhat.com> Message-ID: <49809C2D.3050102@redhat.com> On 2009-01-28 at 12:52:45 -0500, Bill Nottingham wrote: > Tom spot Callaway (tcallawa at redhat.com) said: >>> I thought I'd start on the packaging list first, any thoughts? >> Well, let me turn that around, when is it ever appropriate to use >> "OnlyShowIn="? I can't think of a case where it would be appropriate, >> aside from some sort of KDE or GNOME Configuration utility (and by that, >> I mean "a utility for configuring KDE/GNOME"). > > Part of the rationale is that someone on a system with both KDE and > GNOME may not necessarily want to have two menu entries for an editor, > two menu entries for a calculator, two menu entries for a terminal, etc. Would they really? They'd only have one .desktop file. ~spot From tibbs at math.uh.edu Wed Jan 28 18:09:06 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 28 Jan 2009 12:09:06 -0600 Subject: [Fedora-packaging] guideline for OnlyShowIn? In-Reply-To: <49809C2D.3050102@redhat.com> References: <49808730.3010102@redhat.com> <20090128175244.GC8239@nostromo.devel.redhat.com> <49809C2D.3050102@redhat.com> Message-ID: >>>>> "TC" == Tom \"spot\" Callaway writes: TC> Would they really? They'd only have one .desktop file. Well, one Gnome calculator and one KDE calculator. - J< From tcallawa at redhat.com Wed Jan 28 18:14:39 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Jan 2009 13:14:39 -0500 Subject: [Fedora-packaging] guideline for OnlyShowIn? In-Reply-To: References: <49808730.3010102@redhat.com> <20090128175244.GC8239@nostromo.devel.redhat.com> <49809C2D.3050102@redhat.com> Message-ID: <4980A08F.6030004@redhat.com> On 2009-01-28 at 13:09:06 -0500, Jason L Tibbitts III wrote: >>>>>> "TC" == Tom \"spot\" Callaway writes: > > TC> Would they really? They'd only have one .desktop file. > > Well, one Gnome calculator and one KDE calculator. Okay, I understand this, but if I run GNOME, but want to install the KDE Calculator, I want it to show up in the menu. I would much rather have some way of tagging a desktop file like this: DesignedFor=KDE Then, being able to set a custom configuration variable in the GNOME/KDE menu configuration tools that allows a blanket show/hide for things with that don't match my DesignedFor (along with allowing me to specifically check the box to let k3b override, because it is so much nicer than the GNOME burning program). ~spot From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 28 18:44:09 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 28 Jan 2009 19:44:09 +0100 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <20090128162220.GA6735@nostromo.devel.redhat.com> (Bill Nottingham's message of "Wed, 28 Jan 2009 11:22:20 -0500") References: <200901280136.37005.ville.skytta@iki.fi> <87r62n6edm.fsf@sheridan.bigo.ensc.de> <20090128162220.GA6735@nostromo.devel.redhat.com> Message-ID: <8763jzqnie.fsf@fc5.bigo.ensc.de> Bill Nottingham writes: >> | %postun >> | touch --no-create %{_datadir}/icons/hicolor &>/dev/null >> | >> | %posttrans >> | gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || : > > As posttrans isn't collated into a single run, it just moves the total > of calls from point A to point B, no; gtk-update-icon-cache is cheap when icons/hicolor is up-to-date. Hence, only the first %posttrans will update the icon cache. Subsequent ones will be noops effectively. With old method, there is a 'touch icons/hicolor' which invalidates cache and makes every operation expensive. Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 28 18:49:44 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 28 Jan 2009 19:49:44 +0100 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <498089DA.5060504@math.unl.edu> (Rex Dieter's message of "Wed, 28 Jan 2009 10:37:46 -0600") References: <200901280136.37005.ville.skytta@iki.fi> <87r62n6edm.fsf@sheridan.bigo.ensc.de> <20090128162220.GA6735@nostromo.devel.redhat.com> <49808708.2000804@math.unl.edu> <498089DA.5060504@math.unl.edu> Message-ID: <871vunqn93.fsf@fc5.bigo.ensc.de> Rex Dieter writes: > nevermind, recalled that posttrans was previously considered and rejected, > since posttrans isn't called on erasure (only install/upgrade). Then use a modified %postun scriptlet like %postun touch --no-create %{_datadir}/icons/hicolor &>/dev/null test $1 -ge 1 || gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null --> install and update are cheap, but erase is expensive (but correct). Enrico From rdieter at math.unl.edu Wed Jan 28 18:53:56 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Jan 2009 12:53:56 -0600 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <871vunqn93.fsf@fc5.bigo.ensc.de> References: <200901280136.37005.ville.skytta@iki.fi> <87r62n6edm.fsf@sheridan.bigo.ensc.de> <20090128162220.GA6735@nostromo.devel.redhat.com> <49808708.2000804@math.unl.edu> <498089DA.5060504@math.unl.edu> <871vunqn93.fsf@fc5.bigo.ensc.de> Message-ID: <4980A9C4.6000902@math.unl.edu> Enrico Scholz wrote: > Rex Dieter writes: >> nevermind, recalled that posttrans was previously considered and rejected, >> since posttrans isn't called on erasure (only install/upgrade). > Then use a modified %postun scriptlet like > %postun > touch --no-create %{_datadir}/icons/hicolor &>/dev/null > test $1 -ge 1 || gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null > --> install and update are cheap, but erase is expensive (but correct). me likie. -- Rex From ville.skytta at iki.fi Wed Jan 28 19:48:34 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 28 Jan 2009 21:48:34 +0200 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (=?iso-8859-1?q?icon=09cache?=) changes In-Reply-To: <4980A9C4.6000902@math.unl.edu> References: <200901280136.37005.ville.skytta@iki.fi> <871vunqn93.fsf@fc5.bigo.ensc.de> <4980A9C4.6000902@math.unl.edu> Message-ID: <200901282148.35660.ville.skytta@iki.fi> On Wednesday 28 January 2009, Rex Dieter wrote: > Enrico Scholz wrote: > > Rex Dieter writes: > >> nevermind, recalled that posttrans was previously considered and > >> rejected, since posttrans isn't called on erasure (only > >> install/upgrade). > > > > Then use a modified %postun scriptlet like > > %postun > > touch --no-create %{_datadir}/icons/hicolor &>/dev/null > > test $1 -ge 1 || gtk-update-icon-cache %{_datadir}/icons/hicolor > > &>/dev/null > > > > --> install and update are cheap, but erase is expensive (but correct). > > me likie. Just remember to add something to prevent a non-zero gtk-update-icon-cache exit status from causing trouble. From pmatilai at laiskiainen.org Wed Jan 28 22:59:44 2009 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 29 Jan 2009 00:59:44 +0200 (EET) Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: <498089DA.5060504@math.unl.edu> References: <200901280136.37005.ville.skytta@iki.fi> <87r62n6edm.fsf@sheridan.bigo.ensc.de> <20090128162220.GA6735@nostromo.devel.redhat.com> <49808708.2000804@math.unl.edu> <498089DA.5060504@math.unl.edu> Message-ID: On Wed, 28 Jan 2009, Rex Dieter wrote: > Rex Dieter wrote: >> Bill Nottingham wrote: >>> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > >>>> ? All relevant Fedora releases should understand %posttrans and this >>>> speeds up things significantly. >>> >>> As posttrans isn't collated into a single run, it just moves the total >>> of calls from point A to point B, and therefore would theoretically >>> only speed things up via cache effects. >> >> posttrans could be a win if the idea from >> https://bugzilla.redhat.com/show_bug.cgi?id=170335#c33 >> ever came to fruition. > > nevermind, recalled that posttrans was previously considered and rejected, > since posttrans isn't called on erasure (only install/upgrade). Yup, %posttrans for erase is kinda hard when the package header(s) that the regular rpm scriptlet machinery needs are long gone by the time %posttrans runs. I've been playing around a bit with the "file triggers" concept recently, a very crude but lightweight version is actually possible with a three-liner patch to rpm 4.6 (heck, even 4.4.2.x) + bit of lua scripting. This is nowhere near real-world usable (see below) but in case somebody wants to tinker and play around, a quick and dirty example is here: http://laiskiainen.org/tmp/rpmhook-example/ This tries to get by with just watching bunch of selected directories and launching associated hooks if the directory times change, which is fairly close to being enough, at least for many things: [root at turre rpm-4.6.x]# ./rpm -Uvh --noscripts /tmp/gthumb-2.10.10-3.fc10.x86_64.rpm /tmp/seahorse-2.24.1-1.fc10.x86_64.rpm Preparing... ########################################### [100%] 1:seahorse ########################################### [ 50%] 2:gthumb ########################################### [100%] ldconfig hook caught: -> /usr/lib64 desktop_db hook caught: -> /usr/share/applications scrollkeeper hook caught: -> /usr/share/omf Icon cache gets missed here as the files go into subdirectories of /usr/share/icons/hicolor/, it'd need watching on all the directories recursively. This approach will give some false positives too, like gthumb putting files into /usr/lib64/gthumb/ triggering ldconfig needlessly, otoh in many cases the false positives are harmless as it only runs once. The nice point about using directory timestamps would be that it avoids potentially *very* expensive filename/regex matching on the entire transaction set filelist + needing to store the matches somewhere, but whether that's sufficient for real-world use I dunno... Also this doesn't handle chroot at all, and the hooks should come from the relevant packages, not from some central rpm scripts which in turn means the hooks should be in headers etc. - Panu - From mclasen at redhat.com Wed Jan 28 23:20:16 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 28 Jan 2009 18:20:16 -0500 Subject: [Fedora-packaging] Re: Suggested ScriptletSnippets (icon cache) changes In-Reply-To: References: <200901280136.37005.ville.skytta@iki.fi> <87r62n6edm.fsf@sheridan.bigo.ensc.de> <20090128162220.GA6735@nostromo.devel.redhat.com> <49808708.2000804@math.unl.edu> <498089DA.5060504@math.unl.edu> Message-ID: <1233184816.3131.23.camel@matthiasc> On Thu, 2009-01-29 at 00:59 +0200, Panu Matilainen wrote: > > Icon cache gets missed here as the files go into subdirectories of > /usr/share/icons/hicolor/, it'd need watching on all the directories > recursively. As per the icon theme spec, anybody who installs an icon in a icon theme is required to touch the toplevel directory (for precisely this reason). From panemade at gmail.com Thu Jan 29 06:02:58 2009 From: panemade at gmail.com (=?UTF-8?B?UGFyYWcgTijgpKrgpLDgpL7gpZop?=) Date: Thu, 29 Jan 2009 11:32:58 +0530 Subject: [Fedora-packaging] update cpanspec section in perl packaging guidelines Message-ID: Hi, Can someone with ACL modify https://fedoraproject.org/wiki/Packaging:Perl#cpanspec and add link there to https://fedoraproject.org/wiki/Perl/cpanspec ? Regards, Parag. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschwendt at gmail.com Fri Jan 30 21:24:19 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 30 Jan 2009 22:24:19 +0100 Subject: [Fedora-packaging] Update request for /wiki/Packaging:UnownedDirectories Message-ID: <20090130222419.db22e515.mschwendt@gmail.com> https://fedoraproject.org/wiki/Packaging:UnownedDirectories needs an update (it's read-only). The section about "Inaccessible Directories" applies only to RPM < 4.4.2.3 according to information on fedora-devel-list, and that means Fedora < 9 if the information is correct. At least since Fedora 10, RPM sets a sane default umask, so unowned directories are created with mode 0755. From xjakub at fi.muni.cz Sat Jan 31 17:40:28 2009 From: xjakub at fi.muni.cz (Milos Jakubicek) Date: Sat, 31 Jan 2009 18:40:28 +0100 Subject: [Fedora-packaging] Remove "Encoding=UTF-8" from sample desktop file Message-ID: <49848D0C.5030306@fi.muni.cz> Hi, yesterday when reviewing a package I noticed that although we have a MUST: follow the desktop-entry-spec in the Guidelines, the example on that page includes a line with: Encoding=UTF-8 which is deprecated according to: http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#legacy-mixed We should get rid of that line, as some people (including me) are taking that sample as a basis when creating new desktop files, shouldn't we? Regards, Milos Jakubicek From tcallawa at redhat.com Sat Jan 31 19:24:14 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 31 Jan 2009 14:24:14 -0500 Subject: [Fedora-packaging] Remove "Encoding=UTF-8" from sample desktop file In-Reply-To: <49848D0C.5030306@fi.muni.cz> References: <49848D0C.5030306@fi.muni.cz> Message-ID: <4984A55E.1000602@redhat.com> On 2009-01-31 at 12:40:28 -0500, Milos Jakubicek wrote: > Hi, > > yesterday when reviewing a package I noticed that although we have a > MUST: follow the desktop-entry-spec in the Guidelines, the example on > that page includes a line with: > > Encoding=UTF-8 > > which is deprecated according to: > http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#legacy-mixed > > > We should get rid of that line, as some people (including me) are taking > that sample as a basis when creating new desktop files, shouldn't we? Yep. That line is gone now. Thanks, ~spot From laubersm at fedoraproject.org Sat Jan 31 22:01:54 2009 From: laubersm at fedoraproject.org (Susan Lauber) Date: Sat, 31 Jan 2009 17:01:54 -0500 Subject: [Fedora-packaging] PackageMaintainers wiki cleanup update Message-ID: Greetings to the authors/maintainers of Package Maintainer wiki pages, I introduced myself last week [1] and since then I have dug into the pages and set up a task table [2] I have already added a category to most pages so they can all be found together [3]. If there are others or if you create a new page just add the string [[Category:Package Maintainers]] to the bottom of the page. The next step is renaming so that pages are easier to find in a search. It will also make the category page easier to use. I have started making suggested in the packagemaintainers.psv [4] file in the wikirename.git repo and ***I encourage others to check the proposed names and offer additional suggestions.*** I would like to have this file ready for the wikibot by the end of the week (Feb 7). Lack of response will be seen as a vote of confidence :) Thanks, Susan [1] https://www.redhat.com/archives/fedora-devel-list/2009-January/msg01545.html [2] https://fedoraproject.org/wiki/Docs_tasks_for_Packaging_Guide_and_related_materials#Package_Maintainer_pages [3] https://fedoraproject.org/wiki/Category:Package_Maintainers [4] http://git.fedorahosted.org/git/?p=wikirename.git;a=blob_plain;f=packagemaintainers.psv;hb=HEAD with naming instructions at https://fedoraproject.org/wiki/Help:Wiki_structure -- Susan Lauber, (RHCX, RHCA, RHCSS) Lauber System Solutions, Inc. http://www.laubersolutions.com gpg: 15AC F794 A3D9 64D1 D9CE 4C26 EFC3 11C2 BFA1 0974 -------------- next part -------------- An HTML attachment was scrubbed... URL: