From lutter at redhat.com Mon Mar 2 06:08:50 2009 From: lutter at redhat.com (David Lutterkort) Date: Sun, 01 Mar 2009 22:08:50 -0800 Subject: [Fedora-packaging] Packaging guidelines for rubygems In-Reply-To: <49A6C625.4030008@kanarip.com> References: <49A6C625.4030008@kanarip.com> Message-ID: <1235974130.4045.35.camel@localhost.localdomain> On Thu, 2009-02-26 at 17:41 +0100, Jeroen van Meeuwen wrote: > I find patching rubygems (for CVEs) a pain in the ass because of the > packaging guideline requirement to have the rubygem package's Source0 be > the actual gem. > > I'd much rather work from tarballs. I think the real culprit is that nothing is done until %install in basic rubygem packages. Maybe we should move to a scheme where we 'install' the rubygem into the source dir during %prep, and then copy files from there to %{buildroot}%{gemdir} during %install. David From mtasaka at ioa.s.u-tokyo.ac.jp Mon Mar 2 08:07:07 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 02 Mar 2009 17:07:07 +0900 Subject: [Fedora-packaging] Packaging guidelines for rubygems In-Reply-To: <1235974130.4045.35.camel@localhost.localdomain> References: <49A6C625.4030008@kanarip.com> <1235974130.4045.35.camel@localhost.localdomain> Message-ID: <49AB93AB.7080900@ioa.s.u-tokyo.ac.jp> David Lutterkort wrote, at 03/02/2009 03:08 PM +9:00: > On Thu, 2009-02-26 at 17:41 +0100, Jeroen van Meeuwen wrote: >> I find patching rubygems (for CVEs) a pain in the ass because of the >> packaging guideline requirement to have the rubygem package's Source0 be >> the actual gem. >> >> I'd much rather work from tarballs. > > I think the real culprit is that nothing is done until %install in basic > rubygem packages. > > Maybe we should move to a scheme where we 'install' the rubygem into the > source dir during %prep, and then copy files from there to > %{buildroot}%{gemdir} during %install. > > David I think you are saying "into the build dir" (i.e. %_builddir). Then: As you know for rubygems containing C codes I suggested to install them first under %_builddir, compile C codes there and copy all files into %buildroot and this was already accepted by FPC/FESCo. So I think suggesting to install _all_ rubygems under %_builddir first can also be accepted. What I am wondering currently is at what stage we should install rubygems into %_builddir, whether %prep or %build. Current "rubygem with C code" (proposed by me) is - to create "empty" directory first by "%setup -q -c -T" at %prep - then install rubygems under %_builddir at %build (then some compilation is done in %build) - then copy all needed files at %install However if we want to use "%patch0 -p1 -b .foo", for example, for files installed under %_builddir, rubygems must be installed under %_builddir at %prep, because rpm does not accept %patch? method at %build like: ----------------------------------------------------- + %patch0 -p0 -b .filechooser /home/tasaka1/rpmbuild/INSTROOT/rpm-tmp.n07iGu: line 29: fg: no job control ----------------------------------------------------- Regards, Mamoru From lutter at redhat.com Mon Mar 2 23:27:52 2009 From: lutter at redhat.com (David Lutterkort) Date: Mon, 02 Mar 2009 15:27:52 -0800 Subject: [Fedora-packaging] Packaging guidelines for rubygems In-Reply-To: <49AB93AB.7080900@ioa.s.u-tokyo.ac.jp> References: <49A6C625.4030008@kanarip.com> <1235974130.4045.35.camel@localhost.localdomain> <49AB93AB.7080900@ioa.s.u-tokyo.ac.jp> Message-ID: <1236036472.1270.12.camel@avon.watzmann.net> On Mon, 2009-03-02 at 17:07 +0900, Mamoru Tasaka wrote: > David Lutterkort wrote, at 03/02/2009 03:08 PM +9:00: > > On Thu, 2009-02-26 at 17:41 +0100, Jeroen van Meeuwen wrote: > >> I find patching rubygems (for CVEs) a pain in the ass because of the > >> packaging guideline requirement to have the rubygem package's Source0 be > >> the actual gem. > >> > >> I'd much rather work from tarballs. > > > > I think the real culprit is that nothing is done until %install in basic > > rubygem packages. > > > > Maybe we should move to a scheme where we 'install' the rubygem into the > > source dir during %prep, and then copy files from there to > > %{buildroot}%{gemdir} during %install. > > > > David > > I think you are saying "into the build dir" (i.e. %_builddir). Then: Yeah, that's what I meant. > As you know for rubygems containing C codes I suggested to install > them first under %_builddir, compile C codes there and copy all files > into %buildroot and this was already accepted by FPC/FESCo. > > So I think suggesting to install _all_ rubygems under %_builddir first > can also be accepted. I would hope so, too. > What I am wondering currently is at what stage we should install rubygems > into %_builddir, whether %prep or %build. > Current "rubygem with C code" (proposed by me) is > - to create "empty" directory first by "%setup -q -c -T" at %prep > - then install rubygems under %_builddir at %build (then some compilation > is done in %build) > - then copy all needed files at %install > However if we want to use "%patch0 -p1 -b .foo", for example, for files > installed under %_builddir, rubygems must be installed under %_builddir > at %prep, because rpm does not accept %patch? method at %build like: Since the main motiviation for a change is to enable the workflow that RPM maintainers are used to, we do want the various sections to have their 'usual' meanings, i.e. %prep - unpack sources, apply patches %build - compile/generate files from sources %install - put files into their 'right' place So the main deviation from what the guidelines for binary rubygems suggest right now is that we'd run 'gem install' in %prep - for Ruby-only gems not a big deal, but for binary gems, it's stupid, since we'd need to recompile the gem in %build after patches have been applied. Unfortunately, rubygems don't have a way to split building them into unpack/compile/install the same way as rpm's do. David From mtasaka at ioa.s.u-tokyo.ac.jp Wed Mar 4 16:07:44 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 05 Mar 2009 01:07:44 +0900 Subject: [Fedora-packaging] Call for the owner of %_datadir/gnome-background-properties Message-ID: <49AEA750.6040804@ioa.s.u-tokyo.ac.jp> Hello, all: I am now trying to review on bug 483498, then I got a question. Currently: ----------------------------------------------------------------- # repoquery --repoid=koji-11 --whatprovides '/usr/share/gnome-background-properties/*' | sort | uniq desktop-backgrounds-basic-0:9.0.0-7.noarch desktop-backgrounds-waves-0:9.0.0-7.noarch fedorainfinity-backgrounds-0:0.0.5-2.fc11.noarch gears-backgrounds-0:0.0.1-3.fc11.noarch gnome-backgrounds-0:2.24.0-4.fc11.noarch invinxble-backgrounds-0:0.0.1-3.fc11.noarch neon-backgrounds-0:0.0.1-3.fc11.noarch solar-backgrounds-0:0.92.0-2.fc11.noarch solar-backgrounds-extras-0:0.92.0-2.fc11.noarch themes-backgrounds-gnome-0:0.5.1-2.fc11.noarch # repoquery --repoid=koji-11 --whatprovides '/usr/share/gnome-background-properties' | sort | uniq desktop-backgrounds-basic-0:9.0.0-7.noarch fedorainfinity-backgrounds-0:0.0.5-2.fc11.noarch gears-backgrounds-0:0.0.1-3.fc11.noarch gnome-backgrounds-0:2.24.0-4.fc11.noarch invinxble-backgrounds-0:0.0.1-3.fc11.noarch neon-backgrounds-0:0.0.1-3.fc11.noarch solar-backgrounds-0:0.92.0-2.fc11.noarch ------------------------------------------------------------------- My question is: which package should own %_datadir/gnome-background-properties? - As the name of this directory shows something related to GNOME, maybe one component of GNOME should own this directory. However in that case forcing these packages to have "Requires" for the GNOME component due to this ownership issue seems redundant. - Or maybe filesystem (even if "gnome" appears on this directory name)? Any comments appreciated. Regards, Mamoru From rayvd at bludgeon.org Wed Mar 4 22:09:21 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Wed, 4 Mar 2009 14:09:21 -0800 Subject: [Fedora-packaging] Dual licensing question... Message-ID: <20090304220921.GA12446@bludgeon.org> This is kind of a two part question. I have a package up for review[1] that, per the author, is dual licensed GPL and Artistic. Only GPL is accepted in Fedora. Do I specify my License as just GPLv2+ or do I indicate it's dual licensed even though Artistic is not allowed in Fedora? Also, there was a bit of confusion on the licensing status of this particular package. The PKG-INFO file indicates "Artistic" as the license, but also lists GPL -- I think this is just a side effect of one of the two licenses needing to be listed as "primary" on the pypi page[2]. Note the License field there and then the Categories field. I was able to contact the author, and he has indicated to me via email that this package should indeed be dual licensed under GPL and Artistic. This leads me to wonder a couple of things: - Is the PKG-INFO as indicated above sufficient to demonstrate the dual licensed nature of this package? - If it's not, would including the email from the author as part of the documentation be adequate? - Failing that, is the only way to get the author to release a new version of the package including license information and/or updatin the pypi entry? Guidance appreciated! Ray [1]: https://bugzilla.redhat.com/show_bug.cgi?id=488407#c4 [2]: http://pypi.python.org/pypi/text_table/0.02 From tcallawa at redhat.com Wed Mar 4 22:21:34 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 04 Mar 2009 17:21:34 -0500 Subject: [Fedora-packaging] Dual licensing question... In-Reply-To: <20090304220921.GA12446@bludgeon.org> References: <20090304220921.GA12446@bludgeon.org> Message-ID: <49AEFEEE.3080706@redhat.com> On 03/04/2009 05:09 PM, Ray Van Dolson wrote: > This is kind of a two part question. I have a package up for review[1] > that, per the author, is dual licensed GPL and Artistic. Only GPL is > accepted in Fedora. > > Do I specify my License as just GPLv2+ or do I indicate it's dual > licensed even though Artistic is not allowed in Fedora? We permit you to list the Artistic license on dual licensed perl bits, like this: License: GPLv2+ or Artistic Make sure the source (or the reference email) actually says GPL version 2 or later. If it just says GPL, it should be "GPL+ or Artistic". > Also, there was a bit of confusion on the licensing status of this > particular package. The PKG-INFO file indicates "Artistic" as the > license, but also lists GPL -- I think this is just a side effect of > one of the two licenses needing to be listed as "primary" on the pypi > page[2]. Note the License field there and then the Categories field. > > I was able to contact the author, and he has indicated to me via email > that this package should indeed be dual licensed under GPL and > Artistic. This leads me to wonder a couple of things: > > - Is the PKG-INFO as indicated above sufficient to demonstrate the > dual licensed nature of this package? > - If it's not, would including the email from the author as part of > the documentation be adequate? Including the email as a %doc file is sufficient. Thanks, ~spot From laubersm at fedoraproject.org Thu Mar 5 18:00:24 2009 From: laubersm at fedoraproject.org (Susan Lauber) Date: Thu, 5 Mar 2009 13:00:24 -0500 Subject: [Fedora-packaging] Wiki cleanup TODO Message-ID: Greetings, Much progress has been made on packaging related pages with regards to the wiki cleanup. This involves better use of categories, archiving old pages, and renaming pages for better search results. The detailed task list is at https://fedoraproject.org/wiki/Docs_tasks_for_Packaging_Guide_and_related_materials I have three TODO items that I would appreciate some help with. 1. Spread the word to use the new naming and categories. 2. Let me know if there are any major changes that need to be done (so I don't repeat the mistakes with future page changes) 3. Look over the list of renaming changes for the protected Packaging pages. I finished up adding categories last night and am a bit cross eyed looking at it so general proofreading would also be helpful. This is in with wikirename.git repo and named Packaging.psv http://git.fedorahosted.org/git/wikirename.git?p=wikirename.git;a=blob_plain;f=Packaging.psv;hb=HEAD Here's the high level structure that Toshio and put together last night: *Category:Packaging (containing mostly subcategories and few if any pages) https://fedoraproject.org/wiki/Category:Packaging Inside Packaging you can find (among others): Category:Package Maintainers https://fedoraproject.org/wiki/Category:Package_Maintainers Category:Packages Category:Packaging SIGs Category:Packaging best practices (this one replaces an old guidelines and policy category) Category:Packaging committee https://fedoraproject.org/wiki/Category:Packaging_committee Inside Packaging committee you can find: Category:Packaging guidelines - holding the Packaging: namespace pages Category:Packaging guidelines drafts - holding the drafts (in the Main: namespace) in progress and a sub category of archived drafts Category:Packaging meeting logs - Meeting logs which will be in the Meeting: namespace Category:Packaging meeting minutes - Meeting minutes which will be in the Meeting: namespace I have already renamed the Package Maintainers pages. Any that I missed are probably recent additions but I will keep looking and assist anyone who has questions. I have renamed most of the Packaging guidelines drafts. The rest will be archived or renamed within the next week. Feel free to take care of your own pages. We are still hoping to get the scripts worked out so that the pages in Packaging: can be changed by wikibot. [Failing that, I am willing to do it manually if given access or someone already with access will need to manually make the changes.] 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 From mschwendt at gmail.com Sat Mar 7 10:11:16 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 7 Mar 2009 11:11:16 +0100 Subject: [Fedora-packaging] Re: Update request for /wiki/Packaging:UnownedDirectories In-Reply-To: <20090130222419.db22e515.mschwendt@gmail.com> References: <20090130222419.db22e515.mschwendt@gmail.com> Message-ID: <20090307111116.7ec8aa63.mschwendt@gmail.com> On Fri, 30 Jan 2009 22:24:19 +0100, Michael wrote: > 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. So, what is the proper procedure for getting somebody to update this protected page in the Wiki? :-/ Opensuse have picked it up, and I'm sure I could edit it there ( http://en.opensuse.org/Packaging/Unowned_Directories ) but I'd like to see the Fedora Wiki get updated. From a.badger at gmail.com Sat Mar 7 16:58:01 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 07 Mar 2009 08:58:01 -0800 Subject: [Fedora-packaging] Re: Update request for /wiki/Packaging:UnownedDirectories In-Reply-To: <20090307111116.7ec8aa63.mschwendt@gmail.com> References: <20090130222419.db22e515.mschwendt@gmail.com> <20090307111116.7ec8aa63.mschwendt@gmail.com> Message-ID: <49B2A799.7080407@gmail.com> Michael Schwendt wrote: > On Fri, 30 Jan 2009 22:24:19 +0100, Michael wrote: > >> 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. > > So, what is the proper procedure for getting somebody to update > this protected page in the Wiki? :-/ > Since this is a clarification because of technical changes, I can just change it. But I'm a bit short on time so I'm not able to do the research to make sure what I write is accurate. Could you send the text as you would want to see it updated and I'll apply it? These are the things I'd want: * We probably shouldn't take this out altogether for a long time because the Guidelines are used by EPEL as well. * Should mention the version fixed in so status can be updated as needed. * Should mention the version of Fedora where the recent enough rpm first appeared in the General Availability release so we can eventually say "Not a problem in Fedora" Thanks, -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 mschwendt at gmail.com Sat Mar 7 19:37:10 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 7 Mar 2009 20:37:10 +0100 Subject: [Fedora-packaging] Re: Update request for /wiki/Packaging:UnownedDirectories In-Reply-To: <49B2A799.7080407@gmail.com> References: <20090130222419.db22e515.mschwendt@gmail.com> <20090307111116.7ec8aa63.mschwendt@gmail.com> <49B2A799.7080407@gmail.com> Message-ID: <20090307203710.7790366c.mschwendt@gmail.com> On Sat, 07 Mar 2009 08:58:01 -0800, Toshio wrote: > >> 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. > > > > So, what is the proper procedure for getting somebody to update > > this protected page in the Wiki? :-/ > > > Since this is a clarification because of technical changes, I can just > change it. But I'm a bit short on time so I'm not able to do the > research to make sure what I write is accurate. > > Could you send the text as you would want to see it updated and I'll > apply it? These are the things I'd want: > > * We probably shouldn't take this out altogether for a long time because > the Guidelines are used by EPEL as well. > * Should mention the version fixed in so status can be updated as needed. > * Should mention the version of Fedora where the recent enough rpm first > appeared in the General Availability release so we can eventually say > "Not a problem in Fedora" Instead of | Inaccessible Directories | | A restrictive superuser umask during package installation can | create inaccessible directories. it should say: | Inaccessible Directories | | A restrictive superuser umask during package installation can | create inaccessible directories on target platforms using the | RPM Package Manager older than 4.4.2.3. Fedora 9 and RHEL 5.3 | are the first to use RPM 4.4.2.3, which sets umask 0022 always. From a.badger at gmail.com Sat Mar 7 20:23:06 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 07 Mar 2009 12:23:06 -0800 Subject: [Fedora-packaging] Re: Update request for /wiki/Packaging:UnownedDirectories In-Reply-To: <20090307203710.7790366c.mschwendt@gmail.com> References: <20090130222419.db22e515.mschwendt@gmail.com> <20090307111116.7ec8aa63.mschwendt@gmail.com> <49B2A799.7080407@gmail.com> <20090307203710.7790366c.mschwendt@gmail.com> Message-ID: <49B2D7AA.2090908@gmail.com> Michael Schwendt wrote: > >>>> https://fedoraproject.org/wiki/Packaging:UnownedDirectories > | Inaccessible Directories > | > | A restrictive superuser umask during package installation can > | create inaccessible directories on target platforms using the > | RPM Package Manager older than 4.4.2.3. Fedora 9 and RHEL 5.3 > | are the first to use RPM 4.4.2.3, which sets umask 0022 always. > Thank you! Updated. -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 luca at foppiano.org Sun Mar 8 18:05:33 2009 From: luca at foppiano.org (Luca Foppiano) Date: Sun, 08 Mar 2009 19:05:33 +0100 Subject: [Fedora-packaging] Inactive mantainers? Message-ID: <1236535533.27420.484.camel@localhost.localdomain> Hi guys, I want to know which is the status of this two tickets: * https://bugzilla.redhat.com/show_bug.cgi?id=477938 * https://bugzilla.redhat.com/show_bug.cgi?id=483380 I tried to comment those tickets, mail to maintainers but I got just a /dev/null...What I have to do? Luca -- Today is Boomtime, the 67th day of Chaos in the YOLD 3175 Good day for overcoming obstacles. Try a steeplechase. From lkundrak at v3.sk Sun Mar 8 23:01:26 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Sun, 08 Mar 2009 19:01:26 -0400 Subject: [Fedora-packaging] Inactive mantainers? In-Reply-To: <1236535533.27420.484.camel@localhost.localdomain> References: <1236535533.27420.484.camel@localhost.localdomain> Message-ID: <1236553286.5343.54.camel@localhost.localdomain> On Sun, 2009-03-08 at 19:05 +0100, Luca Foppiano wrote: > Hi guys, > I want to know which is the status of this two tickets: > * https://bugzilla.redhat.com/show_bug.cgi?id=477938 Lennart is usually pretty busy. Try to ping him in the bugzilla ticket once or twice more. (There's no known fix, only workaround if I understand correctly, right?) > * https://bugzilla.redhat.com/show_bug.cgi?id=483380 This seems to be trivial to address. In case you can do it yourself, it would help if you attached a patch. If you can't, ask someone (I think I could do that for you). > I tried to comment those tickets, mail to maintainers but I got just > a /dev/null...What I have to do? I think there used to be a procedure that would allow one to file a CVS admin request to change package's ACL in case maintainer doesn't respond to bugzilla and mail for some time, but I can't find it anymore. That would be interesting for you if you are a fedora packager (I am lazy to check). Regards, -- Lubomir Rintel From luca at foppiano.org Sun Mar 8 19:16:14 2009 From: luca at foppiano.org (Luca Foppiano) Date: Sun, 08 Mar 2009 20:16:14 +0100 Subject: [Fedora-packaging] Inactive mantainers? In-Reply-To: <1236553286.5343.54.camel@localhost.localdomain> References: <1236535533.27420.484.camel@localhost.localdomain> <1236553286.5343.54.camel@localhost.localdomain> Message-ID: <1236539774.27420.491.camel@localhost.localdomain> On Sun, 2009-03-08 at 19:01 -0400, Lubomir Rintel wrote: > > * https://bugzilla.redhat.com/show_bug.cgi?id=477938 > Lennart is usually pretty busy. Try to ping him in the bugzilla ticket > once or twice more. I'll try in this way. > (There's no known fix, only workaround if I > understand correctly, right?) To be sure I don't know if this is a bug or just need a workaround, I need mantainer because maybe he know better the situation... > > * https://bugzilla.redhat.com/show_bug.cgi?id=483380 > > This seems to be trivial to address. In case you can do it yourself, it > would help if you attached a patch. If you can't, ask someone (I think I > could do that for you). You mean, spec file patch? > I think there used to be a procedure that would allow one to file a CVS > admin request to change package's ACL in case maintainer doesn't respond > to bugzilla and mail for some time, but I can't find it anymore. That > would be interesting for you if you are a fedora packager (I am lazy to > check). I'm not a fedora packager, I don't know...I can try to package it by myself, ask for request...but after? Luca -- Today is Boomtime, the 67th day of Chaos in the YOLD 3175 Every man is as God made him, ay, and often worse. -- Miguel de Cervantes From lkundrak at v3.sk Sun Mar 8 23:22:10 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Sun, 08 Mar 2009 19:22:10 -0400 Subject: [Fedora-packaging] Inactive mantainers? In-Reply-To: <1236539774.27420.491.camel@localhost.localdomain> References: <1236535533.27420.484.camel@localhost.localdomain> <1236553286.5343.54.camel@localhost.localdomain> <1236539774.27420.491.camel@localhost.localdomain> Message-ID: <1236554530.5343.57.camel@localhost.localdomain> On Sun, 2009-03-08 at 20:16 +0100, Luca Foppiano wrote: > On Sun, 2009-03-08 at 19:01 -0400, Lubomir Rintel wrote: > > > > * https://bugzilla.redhat.com/show_bug.cgi?id=477938 > > > Lennart is usually pretty busy. Try to ping him in the bugzilla ticket > > once or twice more. > > I'll try in this way. > > > (There's no known fix, only workaround if I > > understand correctly, right?) > > To be sure I don't know if this is a bug or just need a workaround, I > need mantainer because maybe he know better the situation... If you're unsure about this, I'm quite sure someone at fedora-devel-list@ will be able to advise. > > > * https://bugzilla.redhat.com/show_bug.cgi?id=483380 > > > > This seems to be trivial to address. In case you can do it yourself, it > > would help if you attached a patch. If you can't, ask someone (I think I > > could do that for you). > > You mean, spec file patch? Exactly. > > I think there used to be a procedure that would allow one to file a CVS > > admin request to change package's ACL in case maintainer doesn't respond > > to bugzilla and mail for some time, but I can't find it anymore. That > > would be interesting for you if you are a fedora packager (I am lazy to > > check). > > I'm not a fedora packager, I don't know...I can try to package it by > myself, ask for request...but after? I, or someone else with commit rights, can commit it then. Feel free to ask for help if you have trouble making the new package and need help. -- Lubomir Rintel From luca at foppiano.org Sun Mar 8 21:00:54 2009 From: luca at foppiano.org (Luca Foppiano) Date: Sun, 08 Mar 2009 22:00:54 +0100 Subject: [Fedora-packaging] Inactive mantainers? In-Reply-To: <1236554530.5343.57.camel@localhost.localdomain> References: <1236535533.27420.484.camel@localhost.localdomain> <1236553286.5343.54.camel@localhost.localdomain> <1236539774.27420.491.camel@localhost.localdomain> <1236554530.5343.57.camel@localhost.localdomain> Message-ID: <1236546054.27420.492.camel@localhost.localdomain> On Sun, 2009-03-08 at 19:22 -0400, Lubomir Rintel wrote: > I, or someone else with commit rights, can commit it then. Feel free > to ask for help if you have trouble making the new package and need > help. ok, thank you so much Luca -- Today is Boomtime, the 67th day of Chaos in the YOLD 3175 Great American Axiom: Some is good, more is better, too much is just right. From mtasaka at ioa.s.u-tokyo.ac.jp Mon Mar 9 18:32:55 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 10 Mar 2009 03:32:55 +0900 Subject: [Fedora-packaging] Packaging guidelines for rubygems In-Reply-To: <1236036472.1270.12.camel@avon.watzmann.net> References: <49A6C625.4030008@kanarip.com> <1235974130.4045.35.camel@localhost.localdomain> <49AB93AB.7080900@ioa.s.u-tokyo.ac.jp> <1236036472.1270.12.camel@avon.watzmann.net> Message-ID: <49B560D7.3010904@ioa.s.u-tokyo.ac.jp> David Lutterkort wrote, at 03/03/2009 08:27 AM +9:00: > On Mon, 2009-03-02 at 17:07 +0900, Mamoru Tasaka wrote: >> What I am wondering currently is at what stage we should install rubygems >> into %_builddir, whether %prep or %build. >> Current "rubygem with C code" (proposed by me) is >> - to create "empty" directory first by "%setup -q -c -T" at %prep >> - then install rubygems under %_builddir at %build (then some compilation >> is done in %build) >> - then copy all needed files at %install >> However if we want to use "%patch0 -p1 -b .foo", for example, for files >> installed under %_builddir, rubygems must be installed under %_builddir >> at %prep, because rpm does not accept %patch? method at %build like: > > Since the main motiviation for a change is to enable the workflow that > RPM maintainers are used to, we do want the various sections to have > their 'usual' meanings, i.e. > %prep - unpack sources, apply patches > %build - compile/generate files from sources > %install - put files into their 'right' place > > So the main deviation from what the guidelines for binary rubygems > suggest right now is that we'd run 'gem install' in %prep - for > Ruby-only gems not a big deal, but for binary gems, it's stupid, since > we'd need to recompile the gem in %build after patches have been > applied. > > Unfortunately, rubygems don't have a way to split building them into > unpack/compile/install the same way as rpm's do. > > David Umm.. Currently I have no idea for this, however - Anyway it seems that installing rubygems first under %_builddir (after %setup -q -c -T) should be done at %prep, in case applying patches and some extra commands are needed. - For rubygems including C codes, for now recompiling all codes seems unavoidable if we use rubygems and when patches are needed, very unwilling, though. Perhaps there are some cases where installing rubygems (by $ gem install) itself fails without patches Usually recompiling such codes will be done through "rake build" or so. I think such commands (i.e. "rake build" or so) should be done at %build like non-gem rpms (even if first attempt of compiling C codes through $ gem install are already done _at %prep_) - Or we (explicitly) allow to expand gem archive by using "tar" twice like below? -------------------------------------------------------- %prep %setup -q -c -T tar xf mkdir data ; cd data tar xf ../data.tar.gz %patch0 -p0 -b .foo %build cd data/ rake build .... -------------------------------------------------------- Regards, Mamoru From luca at foppiano.org Tue Mar 10 04:49:49 2009 From: luca at foppiano.org (Luca Foppiano) Date: Tue, 10 Mar 2009 05:49:49 +0100 Subject: [Fedora-packaging] gnome-do 0.8.0 Message-ID: <1236660589.1126.5.camel@localhost.localdomain> Hi, here the updated gnome-do 0.8.0. SPEC: http://lfoppiano.fedorapeople.org/gnome-do.spec RPM (x86_64): http://lfoppiano.fedorapeople.org/gnome-do-0.8.0-1.fc10.x86_64.rpm http://lfoppiano.fedorapeople.org/gnome-do-devel-0.8.0-1.fc10.x86_64.rpm SRPM: http://lfoppiano.fedorapeople.org/gnome-do-0.8.0-1.fc10.src.rpm I just updated the package version and check it with mock and rpmlint (both finished without errors). Thanks in advance :) Luca -- Today is Prickle-Prickle, the 69th day of Chaos in the YOLD 3175 AIX - the Unix from the universe where Spock has a beard. From jdennis at redhat.com Wed Mar 11 17:36:33 2009 From: jdennis at redhat.com (John Dennis) Date: Wed, 11 Mar 2009 13:36:33 -0400 Subject: [Fedora-packaging] bad file in look-aside repository Message-ID: <49B7F6A1.6060207@redhat.com> I need to correct a problem and I'm not sure the best way to handle it. Unbeknownst to me upstream released a bad tar file. I uploaded it to the look-aside repository via "make new-sources FILES=XXX". Upstream has replaced the tar file with a new one and in the process removed a higher version tar file I also uploaded (Arghh...) I need to do the following two things, replace one file with another, remove one file (because this file will at some point, e.g. next version, will need to be in the repository, but just not now). FWIW no build has been performed yet, thus by replacing and/or removing these file it cannot lead to a non-repeatable build. It seems as though "make new-sources" allows one to replace a file. Is this true? If so I'm a bit surprised because it could permit malicious behaviour and lead to non-repeatable builds. Is there a mechanism to remove a file uploaded by mistake? How can I avoid this problem in the future? I normally do a "make local" when a new release comes from upstream and iterate locally until the spec file and patch set is correct before doing a cvs commit, make tag, make build. In the past this has always seemed safe and assured I didn't get anything into our master until it was ready. However, "make local" requires the tar file already be in the look-aside repository and you may not know the tar file is hosed. I believe the same problem applies to scratch builds. So, is there a way to test new builds locally without having to have uploaded the sources first? (I know I can manually craft an rpmbuild command line to emulate what "make local" would do, but it would be better if one could ask the tools to do the equivalent of "make local" without involving the look-aside. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rdieter at math.unl.edu Wed Mar 11 17:44:29 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 11 Mar 2009 12:44:29 -0500 Subject: [Fedora-packaging] bad file in look-aside repository In-Reply-To: <49B7F6A1.6060207@redhat.com> References: <49B7F6A1.6060207@redhat.com> Message-ID: <49B7F87D.8040204@math.unl.edu> John Dennis wrote: > I need to correct a problem and I'm not sure the best way to handle it. ... > It seems as though "make new-sources" allows one to replace a file. Is > this true? If so I'm a bit surprised because it could permit malicious > behaviour and lead to non-repeatable builds. My understanding is that sources are stored per cvs module (ie, a source uploaded in cvs module foo/ is not accessible from module bar/). > Is there a mechanism to remove a file uploaded by mistake? make new-sources ... again. the md5sum will (should!) be different, and life should be good again. -- Rex From tgl at redhat.com Wed Mar 11 17:51:59 2009 From: tgl at redhat.com (Tom Lane) Date: Wed, 11 Mar 2009 13:51:59 -0400 Subject: [Fedora-packaging] bad file in look-aside repository In-Reply-To: <49B7F6A1.6060207@redhat.com> References: <49B7F6A1.6060207@redhat.com> Message-ID: <886.1236793919@sss.pgh.pa.us> John Dennis writes: > I need to correct a problem and I'm not sure the best way to handle it. > Unbeknownst to me upstream released a bad tar file. I uploaded it to the > look-aside repository via "make new-sources FILES=XXX". Upstream has > replaced the tar file with a new one and in the process removed a higher > version tar file I also uploaded (Arghh...) I believe that the look-aside repository tracks stuff by md5sum not by file name. Unless you were so unlucky as to have an exact match on the md5sum, there are no worries. Just re-upload the corrected file. > Is there a mechanism to remove a file uploaded by mistake? Not that I've heard of, but unless it's a frickin' enormous file there is not really a reason to bother. regards, tom lane From ivazqueznet at gmail.com Thu Mar 12 03:28:09 2009 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Wed, 11 Mar 2009 23:28:09 -0400 Subject: [Fedora-packaging] Re: [Distutils] SOLVED: bdist_rpm and pre-release python packages / eggs (was: pre-release versioning problems with sdist, bdist_rpm, bdist_debian) In-Reply-To: <49B86AE2.4030608@verizon.net> References: <200903102234.50856.rudd-o@rudd-o.com> <49B853AD.5090807@verizon.net> <49B85D42.9020501@verizon.net> <200903112019.20391.rudd-o@rudd-o.com> <49B868DE.9010108@verizon.net> <49B86AE2.4030608@verizon.net> Message-ID: <1236828489.31110.108.camel@ignacio.lan> On Wed, 2009-03-11 at 21:52 -0400, Gerry Reno wrote: > Manuel, > Additionally, from a Python Distutils perspective, Distutils should > not be enforcing one distro's policy. There are RPM-based distro's that > DO NOT follow fedora's packaging policy. Actually, Fedora people have been approached by other distros because they want to adopt most or all of the policies due to its comprehensiveness. But you didn't hear this from me. -- Ignacio Vazquez-Abrams -------------- 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 luca at foppiano.org Fri Mar 13 06:51:20 2009 From: luca at foppiano.org (Luca Foppiano) Date: Fri, 13 Mar 2009 07:51:20 +0100 Subject: [Fedora-packaging] gnome-do 0.8.0 In-Reply-To: <1236660589.1126.5.camel@localhost.localdomain> References: <1236660589.1126.5.camel@localhost.localdomain> Message-ID: <1236927080.875.57.camel@localhost.localdomain> On Tue, 2009-03-10 at 05:49 +0100, Luca Foppiano wrote: > Hi, > here the updated gnome-do 0.8.0. > > SPEC: http://lfoppiano.fedorapeople.org/gnome-do.spec > > RPM (x86_64): > http://lfoppiano.fedorapeople.org/gnome-do-0.8.0-1.fc10.x86_64.rpm > http://lfoppiano.fedorapeople.org/gnome-do-devel-0.8.0-1.fc10.x86_64.rpm > > SRPM: http://lfoppiano.fedorapeople.org/gnome-do-0.8.0-1.fc10.src.rpm > > > I just updated the package version and check it with mock and rpmlint > (both finished without errors). Any suggestion? I have to ask on fedora-devel-list? Luca -- Today is Boomtime, the 72nd day of Chaos in the YOLD 3175 When the going gets weird, the weird turn pro. -- Hunter S. Thompson From debarshi.ray at gmail.com Fri Mar 13 06:54:14 2009 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 13 Mar 2009 12:24:14 +0530 Subject: [Fedora-packaging] gnome-do 0.8.0 In-Reply-To: <1236927080.875.57.camel@localhost.localdomain> References: <1236660589.1126.5.camel@localhost.localdomain> <1236927080.875.57.camel@localhost.localdomain> Message-ID: <3170f42f0903122354j629636bbn967d997bfc209926@mail.gmail.com> > Any suggestion? I have to ask on fedora-devel-list? Yes, because this list is mainly for Fedora packaging guidelines related discussions. Happy hacking, Debarshi From rjones at redhat.com Fri Mar 13 09:00:07 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 13 Mar 2009 09:00:07 +0000 Subject: [Fedora-packaging] Executable example scripts in docs Message-ID: <20090313090007.GA29832@amd.home.annexia.org> I raised this on fedora-devel-list here: https://www.redhat.com/archives/fedora-devel-list/2009-March/thread.html#00355 in relationship to this review request: https://bugzilla.redhat.com/show_bug.cgi?id=487527 My opinion is that executable example scripts are fine and that rpmlint is wrong to warn about them. Probably we should have some guidelines in this area because currently the situation is a bit confused. What do Fedora packager folk think? 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 mschwendt at gmail.com Fri Mar 13 11:40:37 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 13 Mar 2009 12:40:37 +0100 Subject: [Fedora-packaging] Executable example scripts in docs In-Reply-To: <20090313090007.GA29832@amd.home.annexia.org> References: <20090313090007.GA29832@amd.home.annexia.org> Message-ID: <20090313124037.300e0b65.mschwendt@gmail.com> On Fri, 13 Mar 2009 09:00:07 +0000, Richard wrote: > I raised this on fedora-devel-list here: > https://www.redhat.com/archives/fedora-devel-list/2009-March/thread.html#00355 > > in relationship to this review request: > https://bugzilla.redhat.com/show_bug.cgi?id=487527 > > My opinion is that executable example scripts are fine and that > rpmlint is wrong to warn about them. Probably we should have some > guidelines in this area because currently the situation is a bit > confused. > > What do Fedora packager folk think? > > Rich. > Warnings are no review blockers. Use option -i when running rpmlint. It just warns about these files. These executables are stored outside $PATH and in the documentation tree, so there is no reason they need to be +x. Such a warning is good, because it can happen that doc files are +x by mistake. Since executable scripts are easier to execute accidentally than non-executable scripts, making them -x is safer. From rc040203 at freenet.de Fri Mar 13 11:50:44 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Mar 2009 12:50:44 +0100 Subject: [Fedora-packaging] Executable example scripts in docs In-Reply-To: <20090313124037.300e0b65.mschwendt@gmail.com> References: <20090313090007.GA29832@amd.home.annexia.org> <20090313124037.300e0b65.mschwendt@gmail.com> Message-ID: <49BA4894.3030105@freenet.de> Michael Schwendt wrote: > On Fri, 13 Mar 2009 09:00:07 +0000, Richard wrote: > >> I raised this on fedora-devel-list here: >> https://www.redhat.com/archives/fedora-devel-list/2009-March/thread.html#00355 >> >> in relationship to this review request: >> https://bugzilla.redhat.com/show_bug.cgi?id=487527 >> >> My opinion is that executable example scripts are fine and that >> rpmlint is wrong to warn about them. Probably we should have some >> guidelines in this area because currently the situation is a bit >> confused. >> >> What do Fedora packager folk think? IMO, such files are useful, helpful and should be allowed. rpmlint is overzealous in warning about them. > Warnings are no review blockers. Unfortunately, these warnings are justified, because rpm mis-treats such files. > Such a warning is good, because it can happen that doc files are +x by > mistake. Since executable scripts are easier to execute accidentally > than non-executable scripts, making them -x is safer. Only if you have them in $PATH. Ralf From mschwendt at gmail.com Fri Mar 13 12:08:12 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 13 Mar 2009 13:08:12 +0100 Subject: [Fedora-packaging] Executable example scripts in docs In-Reply-To: <49BA4894.3030105@freenet.de> References: <20090313090007.GA29832@amd.home.annexia.org> <20090313124037.300e0b65.mschwendt@gmail.com> <49BA4894.3030105@freenet.de> Message-ID: <20090313130812.1410b2c9.mschwendt@gmail.com> On Fri, 13 Mar 2009 12:50:44 +0100, Ralf wrote: > > Such a warning is good, because it can happen that doc files are +x by > > mistake. Since executable scripts are easier to execute accidentally > > than non-executable scripts, making them -x is safer. > Only if you have them in $PATH. Also in current dir (not even ./foo.sh runs them then) and with visual shells and file browsers. From rc040203 at freenet.de Fri Mar 13 12:19:30 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Mar 2009 13:19:30 +0100 Subject: [Fedora-packaging] Executable example scripts in docs In-Reply-To: <20090313130812.1410b2c9.mschwendt@gmail.com> References: <20090313090007.GA29832@amd.home.annexia.org> <20090313124037.300e0b65.mschwendt@gmail.com> <49BA4894.3030105@freenet.de> <20090313130812.1410b2c9.mschwendt@gmail.com> Message-ID: <49BA4F52.8070907@freenet.de> Michael Schwendt wrote: > On Fri, 13 Mar 2009 12:50:44 +0100, Ralf wrote: > >> > Such a warning is good, because it can happen that doc files are +x by >> > mistake. Since executable scripts are easier to execute accidentally >> > than non-executable scripts, making them -x is safer. >> Only if you have them in $PATH. > > Also in current dir *nix newbie lesson #1: Do not have '.' in $PATH. Actually, I think, this rpmlint craze only exists to play low rpm's brokenness on handing /usr/share/doc/+. Ralf From mschwendt at gmail.com Fri Mar 13 12:32:16 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 13 Mar 2009 13:32:16 +0100 Subject: [Fedora-packaging] Executable example scripts in docs In-Reply-To: <49BA4F52.8070907@freenet.de> References: <20090313090007.GA29832@amd.home.annexia.org> <20090313124037.300e0b65.mschwendt@gmail.com> <49BA4894.3030105@freenet.de> <20090313130812.1410b2c9.mschwendt@gmail.com> <49BA4F52.8070907@freenet.de> Message-ID: <20090313133216.0f7d101b.mschwendt@gmail.com> On Fri, 13 Mar 2009 13:19:30 +0100, Ralf wrote: > Michael Schwendt wrote: > > On Fri, 13 Mar 2009 12:50:44 +0100, Ralf wrote: > > > >> > Such a warning is good, because it can happen that doc files are +x by > >> > mistake. Since executable scripts are easier to execute accidentally > >> > than non-executable scripts, making them -x is safer. > >> Only if you have them in $PATH. > > > > Also in current dir > > *nix newbie lesson #1: Do not have '.' in $PATH. Fix your attitude. Do you still meet people who add '.' to $PATH? $ touch example.sh $ ./example.sh bash: ./example.sh: Permission denied Also check it out in a graphical file browser compared to +x. From rc040203 at freenet.de Fri Mar 13 12:56:39 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 13 Mar 2009 13:56:39 +0100 Subject: [Fedora-packaging] Executable example scripts in docs In-Reply-To: <20090313133216.0f7d101b.mschwendt@gmail.com> References: <20090313090007.GA29832@amd.home.annexia.org> <20090313124037.300e0b65.mschwendt@gmail.com> <49BA4894.3030105@freenet.de> <20090313130812.1410b2c9.mschwendt@gmail.com> <49BA4F52.8070907@freenet.de> <20090313133216.0f7d101b.mschwendt@gmail.com> Message-ID: <49BA5807.4070608@freenet.de> Michael Schwendt wrote: > On Fri, 13 Mar 2009 13:19:30 +0100, Ralf wrote: > >> Michael Schwendt wrote: >>> On Fri, 13 Mar 2009 12:50:44 +0100, Ralf wrote: >>> >>>> > Such a warning is good, because it can happen that doc files are +x by >>>> > mistake. Since executable scripts are easier to execute accidentally >>>> > than non-executable scripts, making them -x is safer. >>>> Only if you have them in $PATH. >>> Also in current dir >> *nix newbie lesson #1: Do not have '.' in $PATH. > Do you still meet people who add '.' to $PATH? Seemingly you - It's the point behind your sentence above. > Also check it out in a graphical file browser compared to +x. And? Where is the problem? Ralf From wolfy at nobugconsulting.ro Sat Mar 14 16:21:23 2009 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 14 Mar 2009 18:21:23 +0200 Subject: [Fedora-packaging] Executable example scripts in docs In-Reply-To: <20090313133216.0f7d101b.mschwendt@gmail.com> References: <20090313090007.GA29832@amd.home.annexia.org> <20090313124037.300e0b65.mschwendt@gmail.com> <49BA4894.3030105@freenet.de> <20090313130812.1410b2c9.mschwendt@gmail.com> <49BA4F52.8070907@freenet.de> <20090313133216.0f7d101b.mschwendt@gmail.com> Message-ID: <49BBD983.2080104@nobugconsulting.ro> On 03/13/2009 02:32 PM, Michael Schwendt wrote: > [...] > Do you still meet people who add '.' to $PATH? > I do. I have lots of colleagues who add "." to their $PATH because their normal flow of work is $vcs $vsim <----- the result of the previous command and they are too lazy to type ./vsim ( or even to add a ln -s /path/to/workdir/vsim ~/bin ) From ffesti at redhat.com Sat Mar 14 18:05:19 2009 From: ffesti at redhat.com (Florian Festi) Date: Sat, 14 Mar 2009 19:05:19 +0100 Subject: [Fedora-packaging] Executable example scripts in docs In-Reply-To: <20090313133216.0f7d101b.mschwendt@gmail.com> References: <20090313090007.GA29832@amd.home.annexia.org> <20090313124037.300e0b65.mschwendt@gmail.com> <49BA4894.3030105@freenet.de> <20090313130812.1410b2c9.mschwendt@gmail.com> <49BA4F52.8070907@freenet.de> <20090313133216.0f7d101b.mschwendt@gmail.com> Message-ID: <49BBF1DF.8010606@redhat.com> Michael Schwendt wrote: > On Fri, 13 Mar 2009 13:19:30 +0100, Ralf wrote: > >> Michael Schwendt wrote: >>> On Fri, 13 Mar 2009 12:50:44 +0100, Ralf wrote: >>> >>>> > Such a warning is good, because it can happen that doc files are +x by >>>> > mistake. Since executable scripts are easier to execute accidentally >>>> > than non-executable scripts, making them -x is safer. >>>> Only if you have them in $PATH. >>> Also in current dir >> *nix newbie lesson #1: Do not have '.' in $PATH. > > Fix your attitude. Do you still meet people who add '.' to $PATH? echo 'rm -rf $HOME' > /tmp/ll; chmod 755 /tmp/ll Have fun Florian From mschwendt at gmail.com Fri Mar 13 15:28:44 2009 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 13 Mar 2009 16:28:44 +0100 Subject: [Fedora-packaging] Executable example scripts in docs In-Reply-To: <49BA5807.4070608@freenet.de> References: <20090313090007.GA29832@amd.home.annexia.org> <20090313124037.300e0b65.mschwendt@gmail.com> <49BA4894.3030105@freenet.de> <20090313130812.1410b2c9.mschwendt@gmail.com> <49BA4F52.8070907@freenet.de> <20090313133216.0f7d101b.mschwendt@gmail.com> <49BA5807.4070608@freenet.de> Message-ID: <20090313162844.88f4f9e3.mschwendt@gmail.com> On Fri, 13 Mar 2009 13:56:39 +0100, Ralf wrote: > >> *nix newbie lesson #1: Do not have '.' in $PATH. > > > Do you still meet people who add '.' to $PATH? > Seemingly you - It's the point behind your sentence above. Good bye, list members. From tibbs at math.uh.edu Mon Mar 16 16:53:33 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 16 Mar 2009 11:53:33 -0500 Subject: [Fedora-packaging] Meeting time Message-ID: So, what time is the next FPC meeting (tomorrow)? Are we moving for American DST (which moves the time in Europe by an hour for, I believe, this one meeting), moving for European summer time, or not moving at all? http://fedoraproject.org/wiki/Packaging/Committee just says that we use 17:00UTC and includes no rules about DST or summer time. Personally, I have no preference and no conflicts either way. - J< From a.badger at gmail.com Mon Mar 16 16:53:32 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 16 Mar 2009 09:53:32 -0700 Subject: [Fedora-packaging] Meeting time In-Reply-To: References: Message-ID: <49BE840C.6000706@gmail.com> Jason L Tibbitts III wrote: > So, what time is the next FPC meeting (tomorrow)? Are we moving for American > DST (which moves the time in Europe by an hour for, I believe, this one > meeting), moving for European summer time, or not moving at all? > > http://fedoraproject.org/wiki/Packaging/Committee just says that we > use 17:00UTC and includes no rules about DST or summer time. > > Personally, I have no preference and no conflicts either way. > No preferences or conflicts either. -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 rayvd at bludgeon.org Tue Mar 17 00:31:06 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 16 Mar 2009 17:31:06 -0700 Subject: [Fedora-packaging] Checking distro release from spec file Message-ID: <20090317003106.GA4251@bludgeon.org> I'm trying to write a "distro agnostic" spec file that will apply two patches: - Patch 1 if and only if we're building for EL5 or EL4 - Patch 2 if and only if we're building for EL4 I know I can check for EL with the presence of the %{fedora} macro, but is there a "right" way to check the EL version short of calling rpm -q redhat-release? I don't see a macro defined for this in /etc/rpm. I guess I could operate on the dist tag... Ray From rdieter at math.unl.edu Tue Mar 17 00:51:27 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 16 Mar 2009 19:51:27 -0500 Subject: [Fedora-packaging] Checking distro release from spec file In-Reply-To: <20090317003106.GA4251@bludgeon.org> References: <20090317003106.GA4251@bludgeon.org> Message-ID: <49BEF40F.4090502@math.unl.edu> Ray Van Dolson wrote: > I'm trying to write a "distro agnostic" spec file that will apply two > patches: > > - Patch 1 if and only if we're building for EL5 or EL4 > - Patch 2 if and only if we're building for EL4 > > I know I can check for EL with the presence of the %{fedora} macro, %{fedora} macro is the *fedora* release, for EL, the corresponding macro is %{rhel}. In your case. you could use something like: %if 0%{?rhel} >= 4 %patch1 ... %endif %if 0%{?rhel} >= 5 %patch2 ... %endif From rayvd at bludgeon.org Tue Mar 17 00:56:52 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 16 Mar 2009 17:56:52 -0700 Subject: [Fedora-packaging] Checking distro release from spec file In-Reply-To: <49BEF40F.4090502@math.unl.edu> References: <20090317003106.GA4251@bludgeon.org> <49BEF40F.4090502@math.unl.edu> Message-ID: <20090317005652.GA11248@bludgeon.org> On Mon, Mar 16, 2009 at 07:51:27PM -0500, Rex Dieter wrote: > Ray Van Dolson wrote: >> I'm trying to write a "distro agnostic" spec file that will apply two >> patches: >> >> - Patch 1 if and only if we're building for EL5 or EL4 >> - Patch 2 if and only if we're building for EL4 >> >> I know I can check for EL with the presence of the %{fedora} macro, > > %{fedora} macro is the *fedora* release, for EL, the corresponding macro > is %{rhel}. > > In your case. you could use something like: > > %if 0%{?rhel} >= 4 > %patch1 ... > %endif > > %if 0%{?rhel} >= 5 > %patch2 ... > %endif Slick. Thanks Rex. Ray From rdieter at math.unl.edu Tue Mar 17 01:04:52 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 16 Mar 2009 20:04:52 -0500 Subject: [Fedora-packaging] Checking distro release from spec file In-Reply-To: <20090317005652.GA11248@bludgeon.org> References: <20090317003106.GA4251@bludgeon.org> <49BEF40F.4090502@math.unl.edu> <20090317005652.GA11248@bludgeon.org> Message-ID: <49BEF734.8040707@math.unl.edu> Ray Van Dolson wrote: > On Mon, Mar 16, 2009 at 07:51:27PM -0500, Rex Dieter wrote: >> Ray Van Dolson wrote: >>> I'm trying to write a "distro agnostic" spec file that will apply two >>> patches: >>> >>> - Patch 1 if and only if we're building for EL5 or EL4 >>> - Patch 2 if and only if we're building for EL4 >>> >>> I know I can check for EL with the presence of the %{fedora} macro, >> %{fedora} macro is the *fedora* release, for EL, the corresponding macro >> is %{rhel}. >> >> In your case. you could use something like: >> >> %if 0%{?rhel} >= 4 >> %patch1 ... >> %endif >> >> %if 0%{?rhel} >= 5 >> %patch2 ... >> %endif > > Slick. Thanks Rex. Here's more gory details: https://fedoraproject.org/wiki/Packaging/DistTag (sorry, should've included the link last time). -- Rex From rayvd at bludgeon.org Tue Mar 17 04:29:59 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Mon, 16 Mar 2009 21:29:59 -0700 Subject: [Fedora-packaging] Checking distro release from spec file In-Reply-To: <49BEF734.8040707@math.unl.edu> References: <20090317003106.GA4251@bludgeon.org> <49BEF40F.4090502@math.unl.edu> <20090317005652.GA11248@bludgeon.org> <49BEF734.8040707@math.unl.edu> Message-ID: <20090317042959.GA19505@bludgeon.org> On Mon, Mar 16, 2009 at 08:04:52PM -0500, Rex Dieter wrote: > Ray Van Dolson wrote: >> On Mon, Mar 16, 2009 at 07:51:27PM -0500, Rex Dieter wrote: >>> Ray Van Dolson wrote: >>>> I'm trying to write a "distro agnostic" spec file that will apply two >>>> patches: >>>> >>>> - Patch 1 if and only if we're building for EL5 or EL4 >>>> - Patch 2 if and only if we're building for EL4 >>>> >>>> I know I can check for EL with the presence of the %{fedora} macro, >>> %{fedora} macro is the *fedora* release, for EL, the corresponding >>> macro is %{rhel}. >>> >>> In your case. you could use something like: >>> >>> %if 0%{?rhel} >= 4 >>> %patch1 ... >>> %endif >>> >>> %if 0%{?rhel} >= 5 >>> %patch2 ... >>> %endif >> >> Slick. Thanks Rex. > > Here's more gory details: > https://fedoraproject.org/wiki/Packaging/DistTag > (sorry, should've included the link last time). > Hmm, it doesn't seem like %{rhel}, %{rhl}, %{el#} are set on CentOS. I tried adding an echo to my .spec file for each and they all show up empty. Actually, just tried on a real RHEL5 box and echo %{?rhel} Is empty as well. And, when I set up an if block using this: %if 0%{?rhel} == 4 stuff %endif "stuff" never is executed. Guess I will rely on %{dist} for now. Ray From lkundrak at v3.sk Tue Mar 17 12:06:12 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Tue, 17 Mar 2009 13:06:12 +0100 Subject: [Fedora-packaging] Checking distro release from spec file In-Reply-To: <20090317042959.GA19505@bludgeon.org> References: <20090317003106.GA4251@bludgeon.org> <49BEF40F.4090502@math.unl.edu> <20090317005652.GA11248@bludgeon.org> <49BEF734.8040707@math.unl.edu> <20090317042959.GA19505@bludgeon.org> Message-ID: <1237291572.29600.1.camel@localhost.localdomain> On Mon, 2009-03-16 at 21:29 -0700, Ray Van Dolson wrote: > On Mon, Mar 16, 2009 at 08:04:52PM -0500, Rex Dieter wrote: > > Ray Van Dolson wrote: > >> On Mon, Mar 16, 2009 at 07:51:27PM -0500, Rex Dieter wrote: > >>> Ray Van Dolson wrote: > >>>> I'm trying to write a "distro agnostic" spec file that will apply two > >>>> patches: > >>>> > >>>> - Patch 1 if and only if we're building for EL5 or EL4 > >>>> - Patch 2 if and only if we're building for EL4 > >>>> > >>>> I know I can check for EL with the presence of the %{fedora} macro, > >>> %{fedora} macro is the *fedora* release, for EL, the corresponding > >>> macro is %{rhel}. > >>> > >>> In your case. you could use something like: > >>> > >>> %if 0%{?rhel} >= 4 > >>> %patch1 ... > >>> %endif > >>> > >>> %if 0%{?rhel} >= 5 > >>> %patch2 ... > >>> %endif > >> > >> Slick. Thanks Rex. > > > > Here's more gory details: > > https://fedoraproject.org/wiki/Packaging/DistTag > > (sorry, should've included the link last time). > > > > Hmm, it doesn't seem like %{rhel}, %{rhl}, %{el#} are set on CentOS. I > tried adding an echo to my .spec file for each and they all show > up empty. Well, in case you're making an EPEL package, %rhel macro will be defined in buildsystem, by buildsys-macros package. You can get it here: http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/ Regards, -- Lubomir Rintel From dominik at greysector.net Tue Mar 17 13:04:18 2009 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 17 Mar 2009 14:04:18 +0100 Subject: [Fedora-packaging] Meeting time In-Reply-To: <49BE840C.6000706@gmail.com> References: <49BE840C.6000706@gmail.com> Message-ID: <20090317130417.GB9271@mokona.greysector.net> On Monday, 16 March 2009 at 17:53, Toshio Kuratomi wrote: > Jason L Tibbitts III wrote: > > So, what time is the next FPC meeting (tomorrow)? Are we moving for American > > DST (which moves the time in Europe by an hour for, I believe, this one > > meeting), moving for European summer time, or not moving at all? > > > > http://fedoraproject.org/wiki/Packaging/Committee just says that we > > use 17:00UTC and includes no rules about DST or summer time. > > > > Personally, I have no preference and no conflicts either way. > > > No preferences or conflicts either. I'm fine with current time, too. However, I won't be coming to the meeting today, 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 rayvd at bludgeon.org Tue Mar 17 15:30:44 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Tue, 17 Mar 2009 08:30:44 -0700 Subject: [Fedora-packaging] Checking distro release from spec file In-Reply-To: <1237291572.29600.1.camel@localhost.localdomain> References: <20090317003106.GA4251@bludgeon.org> <49BEF40F.4090502@math.unl.edu> <20090317005652.GA11248@bludgeon.org> <49BEF734.8040707@math.unl.edu> <20090317042959.GA19505@bludgeon.org> <1237291572.29600.1.camel@localhost.localdomain> Message-ID: <20090317153044.GA5565@bludgeon.org> On Tue, Mar 17, 2009 at 01:06:12PM +0100, Lubomir Rintel wrote: > On Mon, 2009-03-16 at 21:29 -0700, Ray Van Dolson wrote: > > On Mon, Mar 16, 2009 at 08:04:52PM -0500, Rex Dieter wrote: > > > Ray Van Dolson wrote: > > >> On Mon, Mar 16, 2009 at 07:51:27PM -0500, Rex Dieter wrote: > > >>> Ray Van Dolson wrote: > > >>>> I'm trying to write a "distro agnostic" spec file that will apply two > > >>>> patches: > > >>>> > > >>>> - Patch 1 if and only if we're building for EL5 or EL4 > > >>>> - Patch 2 if and only if we're building for EL4 > > >>>> > > >>>> I know I can check for EL with the presence of the %{fedora} macro, > > >>> %{fedora} macro is the *fedora* release, for EL, the corresponding > > >>> macro is %{rhel}. > > >>> > > >>> In your case. you could use something like: > > >>> > > >>> %if 0%{?rhel} >= 4 > > >>> %patch1 ... > > >>> %endif > > >>> > > >>> %if 0%{?rhel} >= 5 > > >>> %patch2 ... > > >>> %endif > > >> > > >> Slick. Thanks Rex. > > > > > > Here's more gory details: > > > https://fedoraproject.org/wiki/Packaging/DistTag > > > (sorry, should've included the link last time). > > > > > > > Hmm, it doesn't seem like %{rhel}, %{rhl}, %{el#} are set on CentOS. I > > tried adding an echo to my .spec file for each and they all show > > up empty. > > Well, in case you're making an EPEL package, %rhel macro will be defined > in buildsystem, by buildsys-macros package. You can get it here: > > http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/ > > Regards, Ah, so when building by hand via rpmbuild, I should define "rhel 5" on the command line? Or would it be proper to BuildRequires on buildsys-macros? The package won't do the "right thing" unless I can apply a patch correctly based on the OS. Maybe I just assume anyone building by hand will read the .spec file and know what they're doing though. Thanks, Ray From jussi.lehtola at iki.fi Tue Mar 17 16:26:33 2009 From: jussi.lehtola at iki.fi (Jussi Lehtola) Date: Tue, 17 Mar 2009 18:26:33 +0200 Subject: [Fedora-packaging] Checking distro release from spec file In-Reply-To: <20090317153044.GA5565@bludgeon.org> References: <20090317003106.GA4251@bludgeon.org> <49BEF40F.4090502@math.unl.edu> <20090317005652.GA11248@bludgeon.org> <49BEF734.8040707@math.unl.edu> <20090317042959.GA19505@bludgeon.org> <1237291572.29600.1.camel@localhost.localdomain> <20090317153044.GA5565@bludgeon.org> Message-ID: <1237307193.23333.5.camel@localhost.localdomain> On Tue, 2009-03-17 at 08:30 -0700, Ray Van Dolson wrote: > On Tue, Mar 17, 2009 at 01:06:12PM +0100, Lubomir Rintel wrote: > > Well, in case you're making an EPEL package, %rhel macro will be defined > > in buildsystem, by buildsys-macros package. You can get it here: > > > > http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/ > > > > Regards, > > Ah, so when building by hand via rpmbuild, I should define "rhel 5" on > the command line? Or would it be proper to BuildRequires on > buildsys-macros? The package won't do the "right thing" unless I can > apply a patch correctly based on the OS. > > Maybe I just assume anyone building by hand will read the .spec file > and know what they're doing though. Hmm, to my knowledge the %{rhel} macro is provided by /usr/lib/rpm/redhat/dist.sh which is contained in the redhat-rpm-config package. Don't BR the package, since it's automatically provided by the build environment. If you want to compile packages on your own computers, just make sure redhat-rpm-config is installed. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From rayvd at bludgeon.org Tue Mar 17 16:39:58 2009 From: rayvd at bludgeon.org (Ray Van Dolson) Date: Tue, 17 Mar 2009 09:39:58 -0700 Subject: [Fedora-packaging] Checking distro release from spec file In-Reply-To: <1237307193.23333.5.camel@localhost.localdomain> References: <20090317003106.GA4251@bludgeon.org> <49BEF40F.4090502@math.unl.edu> <20090317005652.GA11248@bludgeon.org> <49BEF734.8040707@math.unl.edu> <20090317042959.GA19505@bludgeon.org> <1237291572.29600.1.camel@localhost.localdomain> <20090317153044.GA5565@bludgeon.org> <1237307193.23333.5.camel@localhost.localdomain> Message-ID: <20090317163958.GA9006@bludgeon.org> On Tue, Mar 17, 2009 at 06:26:33PM +0200, Jussi Lehtola wrote: > On Tue, 2009-03-17 at 08:30 -0700, Ray Van Dolson wrote: > > On Tue, Mar 17, 2009 at 01:06:12PM +0100, Lubomir Rintel wrote: > > > Well, in case you're making an EPEL package, %rhel macro will be defined > > > in buildsystem, by buildsys-macros package. You can get it here: > > > > > > http://buildsys.fedoraproject.org/buildgroups/rhel5/i386/ > > > > > > Regards, > > > > Ah, so when building by hand via rpmbuild, I should define "rhel 5" on > > the command line? Or would it be proper to BuildRequires on > > buildsys-macros? The package won't do the "right thing" unless I can > > apply a patch correctly based on the OS. > > > > Maybe I just assume anyone building by hand will read the .spec file > > and know what they're doing though. > > Hmm, to my knowledge the %{rhel} macro is provided > by /usr/lib/rpm/redhat/dist.sh which is contained in the > redhat-rpm-config package. Ah, sure enough. And this script doesn't appear to be modified to work with CentOS, although it does return distnum, all of the other ones come back blank. Perhaps I should file a bug with CentOS. > Don't BR the package, since it's automatically provided by the build > environment. If you want to compile packages on your own computers, just > make sure redhat-rpm-config is installed. Sounds good. Thanks, Ray From rjones at redhat.com Thu Mar 19 12:44:36 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 19 Mar 2009 12:44:36 +0000 Subject: [Fedora-packaging] Compat packages Message-ID: <20090319124436.GA21095@amd.home.annexia.org> Is there any policy at all on compat packages? I can't find anything except this oblique reference to "openssl" vs "openssl096b": https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_with_the_same_base_name There are a number of compat-* packages in Fedora. We would like to add one for celt (an audio codec), since the bitstream changes incompatibly in each release, and interoperability depends on an application always using the same specific version. (This is in relation to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=485245 and the celt package in both Rawhide and RHEL 5) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw From tcallawa at redhat.com Thu Mar 19 14:08:47 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 19 Mar 2009 10:08:47 -0400 Subject: [Fedora-packaging] Compat packages In-Reply-To: <20090319124436.GA21095@amd.home.annexia.org> References: <20090319124436.GA21095@amd.home.annexia.org> Message-ID: <49C251EF.8090106@redhat.com> On 03/19/2009 08:44 AM, Richard W.M. Jones wrote: > Is there any policy at all on compat packages? I can't find anything > except this oblique reference to "openssl" vs "openssl096b": > > https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_with_the_same_base_name > > There are a number of compat-* packages in Fedora. > > We would like to add one for celt (an audio codec), since the > bitstream changes incompatibly in each release, and interoperability > depends on an application always using the same specific version. > > (This is in relation to this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=485245 > and the celt package in both Rawhide and RHEL 5) There is no formalized policy at this time. The last attempt by FESCo was tabled, but is here: https://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages My opinion is that compat- packages are acceptable in cases where the primary (non-compat) maintainer agrees that there is value in the compat packages, and that it does not encourage upstreams to remain on old APIs unnecessarily. ~spot From tmz at pobox.com Thu Mar 19 17:11:11 2009 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 19 Mar 2009 13:11:11 -0400 Subject: [Fedora-packaging] Typo in GConf ScriptletSnippet Message-ID: <20090319171111.GB2030@inocybe.teonanacatl.org> I think there's a typo at: https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#GConf This chunk: %post export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source gconftool-2 --makefile-install-rule \ %{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null ||| : has an extra | at the end. It should end with '|| :' AFAIK. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce -------------- 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 Thu Mar 19 17:28:29 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 19 Mar 2009 10:28:29 -0700 Subject: [Fedora-packaging] Typo in GConf ScriptletSnippet In-Reply-To: <20090319171111.GB2030@inocybe.teonanacatl.org> References: <20090319171111.GB2030@inocybe.teonanacatl.org> Message-ID: <49C280BD.5000202@gmail.com> Todd Zullinger wrote: > I think there's a typo at: > > https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#GConf > > This chunk: > > %post > export GCONF_CONFIG_SOURCE=gconftool-2 --get-default-source > gconftool-2 --makefile-install-rule \ > %{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null ||| : > > has an extra | at the end. It should end with '|| :' AFAIK. > > Thank you! Fixed. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ianweller at gmail.com Sat Mar 21 03:41:46 2009 From: ianweller at gmail.com (Ian Weller) Date: Fri, 20 Mar 2009 22:41:46 -0500 Subject: [Fedora-packaging] WordPress plugins Message-ID: <20090321034146.GA6926@gmail.com> Hi, please read and discuss: https://fedoraproject.org/wiki/User:Ianweller/WordPress_plugin_packaging_guidelines_(draft) This packaging guideline draft is for packaging WordPress plugins in a way that will work with both wordpress and wordpress-mu without requiring both to be installed. -- Ian Weller GnuPG fingerprint: E51E 0517 7A92 70A2 4226 B050 87ED 7C97 EFA8 4A36 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From tmz at pobox.com Sun Mar 22 16:39:57 2009 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 22 Mar 2009 12:39:57 -0400 Subject: [Fedora-packaging] Output from %post scriptlets Message-ID: <20090322163957.GB32644@inocybe.teonanacatl.org> Are there guidelines on output from %post scriptlets? Specifically, if a scriptlet calls service whatever condrestart, is it required to send output to /dev/null? Most packages seem to do so, and the scriptlet snippets for init scripts suggest this. But some packages don't and the "stopping ... [OK]; starting ... [OK]' output is then displayed when updating. (I'm not suggesting that there should be a guideline on this, just checking if there is one that I've overlooked. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Liberty is always dangerous, but it is the safest thing we have. -- Harry Emerson Fosdick -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From rdieter at math.unl.edu Sun Mar 22 16:44:41 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 22 Mar 2009 11:44:41 -0500 Subject: [Fedora-packaging] Output from %post scriptlets In-Reply-To: <20090322163957.GB32644@inocybe.teonanacatl.org> References: <20090322163957.GB32644@inocybe.teonanacatl.org> Message-ID: <49C66AF9.9060604@math.unl.edu> Todd Zullinger wrote: > Are there guidelines on output from %post scriptlets? Specifically, > if a scriptlet calls service whatever condrestart, is it required to > send output to /dev/null? Most packages seem to do so, and the > scriptlet snippets for init scripts suggest this. Yes, suppressing scriptlet output is recommended. -- Rex From lkundrak at v3.sk Mon Mar 23 06:47:54 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Mon, 23 Mar 2009 07:47:54 +0100 Subject: [Fedora-packaging] Binary FreeDOS image Message-ID: <1237790874.3002.7.camel@localhost.localdomain> Hi, I'm just reviewing a DOSEmu package, where the package author includes a tarball of FreeDOS installation (binary images of a couple of basic DOS utilities, shell and the kernel). I believe that it's probably illegal (provided it's GPL code, I have not checked) to do this unless we distribute sources as well. Would anyone mind if I told the maintainer just to include the source tarball in SRPM for now? Building the whole thing from source, while cleanly being possible, would add a huge amount of work at this point. Thanks, -- Lubomir Rintel From j.w.r.degoede at hhs.nl Mon Mar 23 08:36:29 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 23 Mar 2009 09:36:29 +0100 Subject: [Fedora-packaging] Binary FreeDOS image In-Reply-To: <1237790874.3002.7.camel@localhost.localdomain> References: <1237790874.3002.7.camel@localhost.localdomain> Message-ID: <49C74A0D.5020302@hhs.nl> Lubomir Rintel wrote: > Hi, > > I'm just reviewing a DOSEmu package, where the package author includes a > tarball of FreeDOS installation (binary images of a couple of basic DOS > utilities, shell and the kernel). I believe that it's probably illegal > (provided it's GPL code, I have not checked) to do this unless we > distribute sources as well. > > Would anyone mind if I told the maintainer just to include the source > tarball in SRPM for now? Building the whole thing from source, while > cleanly being possible, would add a huge amount of work at this point. > Actually it is *not * possible to build freedos from source as this requires (or atleast used to) non free tools such as Borland C 3. Which means that we should seriously consider wether we want to ship it at all. And if start shipping it having diskimages for qemu would be a nice bonus to have :) Regards, Hans From lkundrak at v3.sk Mon Mar 23 09:24:45 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Mon, 23 Mar 2009 10:24:45 +0100 Subject: [Fedora-packaging] Binary FreeDOS image In-Reply-To: <49C74A0D.5020302@hhs.nl> References: <1237790874.3002.7.camel@localhost.localdomain> <49C74A0D.5020302@hhs.nl> Message-ID: <1237800285.3183.6.camel@localhost.localdomain> On Mon, 2009-03-23 at 09:36 +0100, Hans de Goede wrote: > Lubomir Rintel wrote: > > Hi, > > > > I'm just reviewing a DOSEmu package, where the package author includes a > > tarball of FreeDOS installation (binary images of a couple of basic DOS > > utilities, shell and the kernel). I believe that it's probably illegal > > (provided it's GPL code, I have not checked) to do this unless we > > distribute sources as well. > > > > Would anyone mind if I told the maintainer just to include the source > > tarball in SRPM for now? Building the whole thing from source, while > > cleanly being possible, would add a huge amount of work at this point. > > > > Actually it is *not * possible to build freedos from source as this > requires (or atleast used to) non free tools such as Borland C 3. A brief search through the wiki [1] reveals that it might be possible to build it with Open Watcom C and nasm, though Open Watcom's license is unfortunatelly not allowed in Fedora :( [1] http://apps.sourceforge.net/mediawiki/freedos/index.php?title=FreeDOS_Spec#Programming_tools -- Lubomir Rintel From berrange at redhat.com Mon Mar 23 09:43:43 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 23 Mar 2009 09:43:43 +0000 Subject: [Fedora-packaging] Binary FreeDOS image In-Reply-To: <1237790874.3002.7.camel@localhost.localdomain> References: <1237790874.3002.7.camel@localhost.localdomain> Message-ID: <20090323094343.GE10388@redhat.com> On Mon, Mar 23, 2009 at 07:47:54AM +0100, Lubomir Rintel wrote: > Hi, > > I'm just reviewing a DOSEmu package, where the package author includes a > tarball of FreeDOS installation (binary images of a couple of basic DOS > utilities, shell and the kernel). I believe that it's probably illegal > (provided it's GPL code, I have not checked) to do this unless we > distribute sources as well. > > Would anyone mind if I told the maintainer just to include the source > tarball in SRPM for now? Building the whole thing from source, while > cleanly being possible, would add a huge amount of work at this point. IMHO, it must be buildable from source in Fedora before it is approved. If you ship a pre-built binary + source, there is no guarentee that the source being shipped actually matches the binary. If the build from source isn't possible using Fedora toolchain, then users would be unable to exercise their freedoms to rebuild the RPM. There have been a few places in Fedora where we've had binary blobs in the past, but we've been striving to eliminate these and ensure everything is fully buildable from source with no blobs. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From denis at poolshark.org Mon Mar 23 12:32:38 2009 From: denis at poolshark.org (Denis Leroy) Date: Mon, 23 Mar 2009 13:32:38 +0100 Subject: [Fedora-packaging] Compat packages In-Reply-To: <49C251EF.8090106@redhat.com> References: <20090319124436.GA21095@amd.home.annexia.org> <49C251EF.8090106@redhat.com> Message-ID: <49C78166.5010009@poolshark.org> Tom "spot" Callaway wrote: > On 03/19/2009 08:44 AM, Richard W.M. Jones wrote: >> Is there any policy at all on compat packages? I can't find anything >> except this oblique reference to "openssl" vs "openssl096b": >> >> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_with_the_same_base_name >> >> There are a number of compat-* packages in Fedora. >> >> We would like to add one for celt (an audio codec), since the >> bitstream changes incompatibly in each release, and interoperability >> depends on an application always using the same specific version. >> >> (This is in relation to this bug: >> https://bugzilla.redhat.com/show_bug.cgi?id=485245 >> and the celt package in both Rawhide and RHEL 5) > > There is no formalized policy at this time. The last attempt by FESCo > was tabled, but is here: > > https://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages > > My opinion is that compat- packages are acceptable in cases where the > primary (non-compat) maintainer agrees that there is value in the compat > packages, and that it does not encourage upstreams to remain on old APIs > unnecessarily. My opinion also. On that topic, should we do something about compat packages not explicitly named as such. For example, we ship gtksourceview and gtksourceview2. Shouldn't they be called 'compat-gtksourceview' and 'gtksourceview' respectively ? Where do we draw the line ? From mattias.ellert at fysast.uu.se Mon Mar 23 14:31:02 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Mon, 23 Mar 2009 15:31:02 +0100 Subject: [Fedora-packaging] Directory ownership guidelines Message-ID: <1237818667.19224.31.camel@ellert.tsl.uu.se> Hi! It was suggested to me to bring this issue to this list. The packaging guidelines says that a package should not own a directory that is owned by a package on which it depends. The packaging guidelines also says that packages should own all directories needed in order not to leave orphaned directories after a package de-installation. The way rpm/yum currently works these guidelines are contradicting and you must choose which one to implement in your packaging. My question is - is this a bug in yum/rpm, or a flaw in the packaging guidelines? Here is an example that implements the first guideline - and violates the second - spec file attached. The spec builds a main package, 8 packages (A-H) that depend on the main package and 8 devel packages that each depends on one of the packages (A-H). If I install all 17 packages and then do "yum remove mytest", all packages should be removed cleanly if the Requires are influencing the order the packages are uninstalled, which it must do if both guidelines is supposed to be implementable simultaneously. This is not what happens: [root at localhost ~]# rpm -ivh /home/ellert/rpmbuild/RPMS/i386/mytest-* F?rbereder... ########################################### [100%] 1:mytest ########################################### [ 6%] 2:mytest-A ########################################### [ 12%] 3:mytest-B ########################################### [ 18%] 4:mytest-C ########################################### [ 24%] 5:mytest-D ########################################### [ 29%] 6:mytest-E ########################################### [ 35%] 7:mytest-F ########################################### [ 41%] 8:mytest-G ########################################### [ 47%] 9:mytest-H ########################################### [ 53%] 10:mytest-A-devel ########################################### [ 59%] 11:mytest-B-devel ########################################### [ 65%] 12:mytest-C-devel ########################################### [ 71%] 13:mytest-D-devel ########################################### [ 76%] 14:mytest-E-devel ########################################### [ 82%] 15:mytest-F-devel ########################################### [ 88%] 16:mytest-G-devel ########################################### [ 94%] 17:mytest-H-devel ########################################### [100%] [root at localhost ~]# yum remove mytest Loaded plugins: refresh-packagekit Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package mytest.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest for package: mytest-A --> Processing Dependency: mytest for package: mytest-E --> Processing Dependency: mytest for package: mytest-G --> Processing Dependency: mytest for package: mytest-B --> Processing Dependency: mytest for package: mytest-F --> Processing Dependency: mytest for package: mytest-C --> Processing Dependency: mytest for package: mytest-D --> Processing Dependency: mytest for package: mytest-H --> Running transaction check ---> Package mytest-A.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-A = 1.0-1.fc10 for package: mytest-A-devel ---> Package mytest-B.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-B = 1.0-1.fc10 for package: mytest-B-devel ---> Package mytest-C.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-C = 1.0-1.fc10 for package: mytest-C-devel ---> Package mytest-D.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-D = 1.0-1.fc10 for package: mytest-D-devel ---> Package mytest-E.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-E = 1.0-1.fc10 for package: mytest-E-devel ---> Package mytest-F.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-F = 1.0-1.fc10 for package: mytest-F-devel ---> Package mytest-G.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-G = 1.0-1.fc10 for package: mytest-G-devel ---> Package mytest-H.i386 0:1.0-1.fc10 set to be erased --> Processing Dependency: mytest-H = 1.0-1.fc10 for package: mytest-H-devel --> Running transaction check ---> Package mytest-A-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-B-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-C-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-D-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-E-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-F-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-G-devel.i386 0:1.0-1.fc10 set to be erased ---> Package mytest-H-devel.i386 0:1.0-1.fc10 set to be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: mytest i386 1.0-1.fc10 installed 0.0 Removing for dependencies: mytest-A i386 1.0-1.fc10 installed 6.0 mytest-A-devel i386 1.0-1.fc10 installed 7.0 mytest-B i386 1.0-1.fc10 installed 6.0 mytest-B-devel i386 1.0-1.fc10 installed 7.0 mytest-C i386 1.0-1.fc10 installed 6.0 mytest-C-devel i386 1.0-1.fc10 installed 7.0 mytest-D i386 1.0-1.fc10 installed 6.0 mytest-D-devel i386 1.0-1.fc10 installed 7.0 mytest-E i386 1.0-1.fc10 installed 6.0 mytest-E-devel i386 1.0-1.fc10 installed 7.0 mytest-F i386 1.0-1.fc10 installed 6.0 mytest-F-devel i386 1.0-1.fc10 installed 7.0 mytest-G i386 1.0-1.fc10 installed 6.0 mytest-G-devel i386 1.0-1.fc10 installed 7.0 mytest-H i386 1.0-1.fc10 installed 6.0 mytest-H-devel i386 1.0-1.fc10 installed 7.0 Transaction Summary ================================================================================ Install 0 Package(s) Update 0 Package(s) Remove 17 Package(s) Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Erasing : mytest-E-devel 1/17 Erasing : mytest-H-devel 2/17 Erasing : mytest-A 3/17 Erasing : mytest-C 4/17 Erasing : mytest-D 5/17 Erasing : mytest-E 6/17 Erasing : mytest-G 7/17 Erasing : mytest-H 8/17 Erasing : mytest-C-devel 9/17 Erasing : mytest-F-devel 10/17 Erasing : mytest-F 11/17 Erasing : mytest-A-devel 12/17 Erasing : mytest-D-devel 13/17 Erasing : mytest 14/17 Erasing : mytest-G-devel 15/17 Erasing : mytest-B 16/17 Erasing : mytest-B-devel 17/17 Removed: mytest.i386 0:1.0-1.fc10 Dependency Removed: mytest-A.i386 0:1.0-1.fc10 mytest-A-devel.i386 0:1.0-1.fc10 mytest-B.i386 0:1.0-1.fc10 mytest-B-devel.i386 0:1.0-1.fc10 mytest-C.i386 0:1.0-1.fc10 mytest-C-devel.i386 0:1.0-1.fc10 mytest-D.i386 0:1.0-1.fc10 mytest-D-devel.i386 0:1.0-1.fc10 mytest-E.i386 0:1.0-1.fc10 mytest-E-devel.i386 0:1.0-1.fc10 mytest-F.i386 0:1.0-1.fc10 mytest-F-devel.i386 0:1.0-1.fc10 mytest-G.i386 0:1.0-1.fc10 mytest-G-devel.i386 0:1.0-1.fc10 mytest-H.i386 0:1.0-1.fc10 mytest-H-devel.i386 0:1.0-1.fc10 Complete! After the removal there are orphaned directories: [root at localhost ~]# find /usr/share/mytest /usr/share/mytest /usr/share/mytest/C /usr/share/mytest/G /usr/share/mytest/B /usr/share/mytest/D /usr/share/mytest/A [root at localhost ~]# rpm -q --whatprovides `find /usr/share/mytest` filen /usr/share/mytest tillh?r inget paket filen /usr/share/mytest/C tillh?r inget paket filen /usr/share/mytest/G tillh?r inget paket filen /usr/share/mytest/B tillh?r inget paket filen /usr/share/mytest/D tillh?r inget paket filen /usr/share/mytest/A tillh?r inget paket -------------- next part -------------- A non-text attachment was scrubbed... Name: mytest.spec Type: text/x-rpm-spec Size: 5241 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2272 bytes Desc: not available URL: From rdieter at math.unl.edu Mon Mar 23 14:34:47 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 23 Mar 2009 09:34:47 -0500 Subject: [Fedora-packaging] Directory ownership guidelines In-Reply-To: <1237818667.19224.31.camel@ellert.tsl.uu.se> References: <1237818667.19224.31.camel@ellert.tsl.uu.se> Message-ID: <49C79E07.6000300@math.unl.edu> Mattias Ellert wrote: > It was suggested to me to bring this issue to this list. > > The packaging guidelines says that a package should not own a directory > that is owned by a package on which it depends. > > The packaging guidelines also says that packages should own all > directories needed in order not to leave orphaned directories after a > package de-installation. > > The way rpm/yum currently works these guidelines are contradicting and > you must choose which one to implement in your packaging. > > My question is - is this a bug in yum/rpm, or a flaw in the packaging > guidelines? bug. -- Rex From mtasaka at ioa.s.u-tokyo.ac.jp Mon Mar 23 14:38:46 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 23 Mar 2009 23:38:46 +0900 Subject: [Fedora-packaging] Directory ownership guidelines In-Reply-To: <1237818667.19224.31.camel@ellert.tsl.uu.se> References: <1237818667.19224.31.camel@ellert.tsl.uu.se> Message-ID: <49C79EF6.7080708@ioa.s.u-tokyo.ac.jp> Mattias Ellert wrote, at 03/23/2009 11:31 PM +9:00: > Hi! > > It was suggested to me to bring this issue to this list. > > The packaging guidelines says that a package should not own a directory > that is owned by a package on which it depends. > > The packaging guidelines also says that packages should own all > directories needed in order not to leave orphaned directories after a > package de-installation. > > The way rpm/yum currently works these guidelines are contradicting and > you must choose which one to implement in your packaging. > > My question is - is this a bug in yum/rpm, or a flaw in the packaging > guidelines? I guess this is a bug in rpm. As far as I am correct current Fedora packaging guidelines assume this is properly handled by rpm. Actually I filed bug 490975 and am waiting for comments from rpm maintainers. Regards, Mamoru From skvidal at fedoraproject.org Mon Mar 23 14:38:46 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 23 Mar 2009 10:38:46 -0400 (EDT) Subject: [Fedora-packaging] Directory ownership guidelines In-Reply-To: <49C79E07.6000300@math.unl.edu> References: <1237818667.19224.31.camel@ellert.tsl.uu.se> <49C79E07.6000300@math.unl.edu> Message-ID: On Mon, 23 Mar 2009, Rex Dieter wrote: > Mattias Ellert wrote: > >> It was suggested to me to bring this issue to this list. >> >> The packaging guidelines says that a package should not own a directory >> that is owned by a package on which it depends. >> >> The packaging guidelines also says that packages should own all >> directories needed in order not to leave orphaned directories after a >> package de-installation. >> >> The way rpm/yum currently works these guidelines are contradicting and >> you must choose which one to implement in your packaging. >> >> My question is - is this a bug in yum/rpm, or a flaw in the packaging >> guidelines? > > bug. What bug number is this? -sv From rc040203 at freenet.de Mon Mar 23 15:37:56 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 23 Mar 2009 16:37:56 +0100 Subject: [Fedora-packaging] Compat packages In-Reply-To: <49C78166.5010009@poolshark.org> References: <20090319124436.GA21095@amd.home.annexia.org> <49C251EF.8090106@redhat.com> <49C78166.5010009@poolshark.org> Message-ID: <49C7ACD4.7010705@freenet.de> Denis Leroy wrote: > Tom "spot" Callaway wrote: >> On 03/19/2009 08:44 AM, Richard W.M. Jones wrote: >>> Is there any policy at all on compat packages? I can't find anything >>> except this oblique reference to "openssl" vs "openssl096b": >>> >>> https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Multiple_packages_with_the_same_base_name >>> >>> >>> There are a number of compat-* packages in Fedora. >>> >>> We would like to add one for celt (an audio codec), since the >>> bitstream changes incompatibly in each release, and interoperability >>> depends on an application always using the same specific version. >>> >>> (This is in relation to this bug: >>> https://bugzilla.redhat.com/show_bug.cgi?id=485245 >>> and the celt package in both Rawhide and RHEL 5) >> >> There is no formalized policy at this time. The last attempt by FESCo >> was tabled, but is here: >> >> https://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages >> >> My opinion is that compat- packages are acceptable in cases where the >> primary (non-compat) maintainer agrees that there is value in the compat >> packages, and that it does not encourage upstreams to remain on old APIs >> unnecessarily. > > My opinion also. On that topic, should we do something about compat > packages not explicitly named as such. For example, we ship > gtksourceview and gtksourceview2. Shouldn't they be called > 'compat-gtksourceview' and 'gtksourceview' respectively ? No. These are 2 different historic ways to having been applied to introduce "compat packages". 1) Add "compat-*" packages 2) Use versioned package names "package" Both approaches have pros and cons each. E.g. * compat-* package typically supply "backward compatible run-times". They very often aim at "keeping users' applications" happy. * "package" package often aim at "parallel installation", often stemming from times when some underlying package has undergone major API/ABI changes, while it's clients/users have not been updated to the new version yet (classic example: gtk (gtk1) vs. gtk2). > Where do we draw the line ? Why do you want to draw a line? There are many aspects why one solution might be preferable/better suitable in one or the other situation. Ralf From denis at poolshark.org Tue Mar 24 13:35:26 2009 From: denis at poolshark.org (Denis) Date: Tue, 24 Mar 2009 14:35:26 +0100 Subject: [Fedora-packaging] Compat packages In-Reply-To: <49C7ACD4.7010705@freenet.de> References: <20090319124436.GA21095@amd.home.annexia.org> <49C251EF.8090106@redhat.com> <49C78166.5010009@poolshark.org> <49C7ACD4.7010705@freenet.de> Message-ID: <49C8E19E.1040102@poolshark.org> On 03/23/2009 04:37 PM, Ralf Corsepius wrote: >> My opinion also. On that topic, should we do something about compat >> packages not explicitly named as such. For example, we ship >> gtksourceview and gtksourceview2. Shouldn't they be called >> 'compat-gtksourceview' and 'gtksourceview' respectively ? > > > No. These are 2 different historic ways to having been applied to > introduce "compat packages". > > 1) Add "compat-*" packages > > 2) Use versioned package names "package" > > Both approaches have pros and cons each. > > E.g. > * compat-* package typically supply "backward compatible run-times". > They very often aim at "keeping users' applications" happy. > > * "package" package often aim at "parallel installation", often > stemming from times when some underlying package has undergone major > API/ABI changes, while it's clients/users have not been updated to the > new version yet (classic example: gtk (gtk1) vs. gtk2). To be honest, I fail to see the difference between both your cases above. Compat packages are also meant to be parallel installable (e.g. compat-gcc34), and "package" also supply backward compatible run-times (as gtksourceview, used for example by dead-upstream 'scratchpad') From chepkov at yahoo.com Tue Mar 24 14:17:10 2009 From: chepkov at yahoo.com (Vadym Chepkov) Date: Tue, 24 Mar 2009 07:17:10 -0700 (PDT) Subject: [Fedora-packaging] RPM variation Message-ID: <373185.92419.qm@web36804.mail.mud.yahoo.com> Hi, A typical rpm spec file has just one %build section and subpackages contain sub-set of the build tree. I want to create 3 different rpms with different names which follow "subpackage" schema, but, they will contain the full set of build files. I will explain why I need this. IBM MQ Series provides very strange API. The function MQCONN, for example, will behave differently if you link your application either with -lmqm or with -lmqic (you have to choose one). The fist one is so called "server" version, second is "client" version and it depends on what MQ Series you use (client or server edition). In order to accommodate to this requirement, make files for my application have this logic: ifndef WITHOUTMQ MQDEFS = -DMQSERIES ifdef WITHMQCLIENT MQLIBS = -lmqic else MQLIBS = -lmqm endif endif So I can create complete set of binaries for each case: no MQ at all, server or client installation. I want to pack results in 3 different rpms: app.rpm, app-MQServer.rpm and app-MQClient.rpm. rpm -ql for each package will list the same file names. How can I accomplish this in one spec file? Thank you. Sincerely yours, Vadym Chepkov From rjones at redhat.com Tue Mar 24 14:39:08 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 24 Mar 2009 14:39:08 +0000 Subject: [Fedora-packaging] Binary FreeDOS image In-Reply-To: <1237790874.3002.7.camel@localhost.localdomain> References: <1237790874.3002.7.camel@localhost.localdomain> Message-ID: <20090324143908.GA30414@amd.home.annexia.org> On Mon, Mar 23, 2009 at 07:47:54AM +0100, Lubomir Rintel wrote: > Hi, > > I'm just reviewing a DOSEmu package, where the package author includes a > tarball of FreeDOS installation (binary images of a couple of basic DOS > utilities, shell and the kernel). I believe that it's probably illegal > (provided it's GPL code, I have not checked) to do this unless we > distribute sources as well. > > Would anyone mind if I told the maintainer just to include the source > tarball in SRPM for now? Building the whole thing from source, while > cleanly being possible, would add a huge amount of work at this point. Just a note that I checked on Debian's package (dosemu[1] and dosemu-freedos) and they are also distributing the freedos binary. According to their README file: The files dosemu-freedos-*-bin.tgz and dosemu-freedos-*-sources.tgz, previously packaged in the separate Debian package dosemu-freedos, are also licensed under the GPL version 2, see above. However, they currently require non-free C compilers to build. This still doesn't make it OK to distribute the binary without building from source IMO. We should get together with Debian and fix whatever problems are stopping us from building FreeDOS using Free tools. Rich. [1] http://packages.debian.org/source/sid/dosemu -- 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 Tue Mar 24 14:40:47 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 24 Mar 2009 15:40:47 +0100 Subject: [Fedora-packaging] Compat packages In-Reply-To: <49C8E19E.1040102@poolshark.org> References: <20090319124436.GA21095@amd.home.annexia.org> <49C251EF.8090106@redhat.com> <49C78166.5010009@poolshark.org> <49C7ACD4.7010705@freenet.de> <49C8E19E.1040102@poolshark.org> Message-ID: <49C8F0EF.8080109@freenet.de> Denis wrote: > On 03/23/2009 04:37 PM, Ralf Corsepius wrote: >>> My opinion also. On that topic, should we do something about compat >>> packages not explicitly named as such. For example, we ship >>> gtksourceview and gtksourceview2. Shouldn't they be called >>> 'compat-gtksourceview' and 'gtksourceview' respectively ? >> >> >> No. These are 2 different historic ways to having been applied to >> introduce "compat packages". >> >> 1) Add "compat-*" packages >> >> 2) Use versioned package names "package" >> >> Both approaches have pros and cons each. >> >> E.g. >> * compat-* package typically supply "backward compatible run-times". >> They very often aim at "keeping users' applications" happy. >> >> * "package" package often aim at "parallel installation", often >> stemming from times when some underlying package has undergone major >> API/ABI changes, while it's clients/users have not been updated to the >> new version yet (classic example: gtk (gtk1) vs. gtk2). > > To be honest, I fail to see the difference between both your cases > above. The difference is substantial. The key points are * Choosing "unique package name" A compat prefix can only be applied once, it's insufficient to handle several versions. * Choosing the "nominal package" name. Using a "compat-* package-prefix" forces all packages's specs which can't be upgraded to the latest version of a package to be modified. Using a "versioned package name" ties a package's spec to a particular version. > Compat packages are also meant to be parallel installable (e.g. > compat-gcc34), Well, compat-gcc is a twit of both approaches :) > and "package" also supply backward compatible > run-times Correct. The "package" approach is more flexible than the "compat-" convention. Finally: compat-* is the tradtional approach RH has been using/RH seems to have favored, until ... packages were facing it's limitations ;) Ralf From lkundrak at v3.sk Tue Mar 24 15:14:09 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Tue, 24 Mar 2009 16:14:09 +0100 Subject: [Fedora-packaging] RPM variation In-Reply-To: <373185.92419.qm@web36804.mail.mud.yahoo.com> References: <373185.92419.qm@web36804.mail.mud.yahoo.com> Message-ID: <1237907649.7357.7.camel@localhost.localdomain> On Tue, 2009-03-24 at 07:17 -0700, Vadym Chepkov wrote: > IBM MQ Series provides very strange API. The function MQCONN, for > example, will behave differently if you link your application either > with -lmqm or with -lmqic (you have to choose one). [...] Strange translates to "utterly stupid" here. This should not have been a compile-time option, but a run-time option in the first place. This is the very same kind of decision the GRUB 2 people made about PC BIOS vs. EFI. > So I can create complete set of binaries for each case: no MQ at all, > server or client installation. I want to pack results in 3 different > rpms: app.rpm, app-MQServer.rpm and app-MQClient.rpm. rpm -ql for each > package will list the same file names. How can I accomplish this in > one spec file? We, unlike Debian, avoid file conflict as much as we can (it would make sense to have both packages installed, wouldn't it?). So your only option is to name the files differently, I'd say. For the executable, you can use alternatives system (see update-alternatives(8)). Regards, -- Lubomir Rintel From mattias.ellert at fysast.uu.se Wed Mar 25 05:24:41 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Wed, 25 Mar 2009 06:24:41 +0100 Subject: [Fedora-packaging] Directory ownership guidelines In-Reply-To: <49C79EF6.7080708@ioa.s.u-tokyo.ac.jp> References: <1237818667.19224.31.camel@ellert.tsl.uu.se> <49C79EF6.7080708@ioa.s.u-tokyo.ac.jp> Message-ID: <1237958681.3018.10.camel@localhost.localdomain> m?n 2009-03-23 klockan 23:38 +0900 skrev Mamoru Tasaka: > Mattias Ellert wrote, at 03/23/2009 11:31 PM +9:00: > > Hi! > > > > It was suggested to me to bring this issue to this list. > > > > The packaging guidelines says that a package should not own a directory > > that is owned by a package on which it depends. > > > > The packaging guidelines also says that packages should own all > > directories needed in order not to leave orphaned directories after a > > package de-installation. > > > > The way rpm/yum currently works these guidelines are contradicting and > > you must choose which one to implement in your packaging. > > > > My question is - is this a bug in yum/rpm, or a flaw in the packaging > > guidelines? > > I guess this is a bug in rpm. As far as I am correct current Fedora packaging > guidelines assume this is properly handled by rpm. > Actually I filed bug 490975 and am waiting for comments from rpm maintainers. > > Regards, > Mamoru I added my test case to your existing bug report. Considering that this bug is the cause for thousands of packages violating the packaging guidelines, should the severity/priority of the bug be raised? Should it be made a blocker? Mattias -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2272 bytes Desc: not available URL: From cfinlay at gmail.com Wed Mar 25 15:58:46 2009 From: cfinlay at gmail.com (Conner Finlay) Date: Wed, 25 Mar 2009 11:58:46 -0400 Subject: [Fedora-packaging] Perl Question Message-ID: <9d000acd0903250858r5cbffde9k28779ecf15c7d97c@mail.gmail.com> Hello list, I have searched Google high and low, but I have not found an answer. I have a spec file that requires some perl modules, ie Net::IP, XML::Simple, etc. For all but one there is an RPM available for it. In the SPEC file I have them as Requires: perl(Net::IP) and the spec file builds fine(rpmbuild -ba -v) but when I go to install the RPM it complains about the missing perl modules. If I do a `yum install perl-xyz` and rebuild the SPEC file, it will not complain about the missing perl modules. How can I have the SPEC file download/install the perl modules/packages? If it is easier, I can also post the SPEC file itself. Thanks, Conner -- Conner Finlay -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Wed Mar 25 16:06:28 2009 From: paul at city-fan.org (Paul Howarth) Date: Wed, 25 Mar 2009 16:06:28 +0000 Subject: [Fedora-packaging] Perl Question In-Reply-To: <9d000acd0903250858r5cbffde9k28779ecf15c7d97c@mail.gmail.com> References: <9d000acd0903250858r5cbffde9k28779ecf15c7d97c@mail.gmail.com> Message-ID: <49CA5684.1050802@city-fan.org> Conner Finlay wrote: > Hello list, > > I have searched Google high and low, but I have not found an answer. I > have a spec file that requires some perl modules, ie Net::IP, > XML::Simple, etc. For all but one there is an RPM available for it. In > the SPEC file I have them as Requires: perl(Net::IP) and the spec file > builds fine(rpmbuild -ba -v) but when I go to install the RPM it > complains about the missing perl modules. If I do a `yum install > perl-xyz` and rebuild the SPEC file, it will not complain about the > missing perl modules. How can I have the SPEC file download/install the > perl modules/packages? If it is easier, I can also post the SPEC file > itself. If you use yum to install the rpm you've built, it will resolve the dependencies and install them too. When you specify "Requires: foo", this means that your package needs "foo" on the system to run, but not necessarily to build, so rpm enforces this when you try to install the package. If you want "foo" available at build time (perhaps to run a test suite), you specify that as "BuildRequires: foo", and rpm-build will insist you have "foo" when you try to build the package. Paul. From tcallawa at redhat.com Wed Mar 25 16:13:10 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 25 Mar 2009 12:13:10 -0400 Subject: [Fedora-packaging] Perl Question In-Reply-To: <9d000acd0903250858r5cbffde9k28779ecf15c7d97c@mail.gmail.com> References: <9d000acd0903250858r5cbffde9k28779ecf15c7d97c@mail.gmail.com> Message-ID: <49CA5816.1020202@redhat.com> On 03/25/2009 11:58 AM, Conner Finlay wrote: > For all but one there is an RPM available for it. I know this is offtopic, but which perl module was not available in Fedora? ~spot From cfinlay at gmail.com Wed Mar 25 17:07:36 2009 From: cfinlay at gmail.com (Conner Finlay) Date: Wed, 25 Mar 2009 13:07:36 -0400 Subject: [Fedora-packaging] Perl Question In-Reply-To: <49CA5684.1050802@city-fan.org> References: <9d000acd0903250858r5cbffde9k28779ecf15c7d97c@mail.gmail.com> <49CA5684.1050802@city-fan.org> Message-ID: <9d000acd0903251007w420e4013t3d2f6208d6cd81ef@mail.gmail.com> Paul, Wouldn't BuildRequires: be pretty much the same thing as doing a manual yum install of the package, then building the spec file? Thanks, Conner On Wed, Mar 25, 2009 at 12:06 PM, Paul Howarth wrote: > Conner Finlay wrote: > >> Hello list, >> >> I have searched Google high and low, but I have not found an answer. I >> have a spec file that requires some perl modules, ie Net::IP, XML::Simple, >> etc. For all but one there is an RPM available for it. In the SPEC file I >> have them as Requires: perl(Net::IP) and the spec file builds fine(rpmbuild >> -ba -v) but when I go to install the RPM it complains about the missing perl >> modules. If I do a `yum install perl-xyz` and rebuild the SPEC file, it will >> not complain about the missing perl modules. How can I have the SPEC file >> download/install the perl modules/packages? If it is easier, I can also post >> the SPEC file itself. >> > > If you use yum to install the rpm you've built, it will resolve the > dependencies and install them too. > > When you specify "Requires: foo", this means that your package needs "foo" > on the system to run, but not necessarily to build, so rpm enforces this > when you try to install the package. If you want "foo" available at build > time (perhaps to run a test suite), you specify that as "BuildRequires: > foo", and rpm-build will insist you have "foo" when you try to build the > package. > > Paul. > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > -- Conner Finlay -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Wed Mar 25 17:14:50 2009 From: paul at city-fan.org (Paul Howarth) Date: Wed, 25 Mar 2009 17:14:50 +0000 Subject: [Fedora-packaging] Perl Question In-Reply-To: <9d000acd0903251007w420e4013t3d2f6208d6cd81ef@mail.gmail.com> References: <9d000acd0903250858r5cbffde9k28779ecf15c7d97c@mail.gmail.com> <49CA5684.1050802@city-fan.org> <9d000acd0903251007w420e4013t3d2f6208d6cd81ef@mail.gmail.com> Message-ID: <49CA668A.8000307@city-fan.org> Conner Finlay wrote: > Paul, > > Wouldn't BuildRequires: be pretty much the same thing as doing a manual > yum install of the package, then building the spec file? Yes; that's the way dependencies are done. The spec file contains the dependency information and it's up to the user how to satisfy that dependency. Given that packages should be built as non-root users for security reasons, nothing in the spec file that attempted to download and install dependencies on to the system (and in particular, into the rpm database) would work anyway due to permissions. Paul. From paul at all-the-johnsons.co.uk Wed Mar 25 19:19:16 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 25 Mar 2009 19:19:16 +0000 Subject: [Fedora-packaging] Binary FreeDOS image In-Reply-To: <1237790874.3002.7.camel@localhost.localdomain> References: <1237790874.3002.7.camel@localhost.localdomain> Message-ID: <1238008756.17087.179.camel@PB3.Linux> Hi, > I'm just reviewing a DOSEmu package, where the package author includes a > tarball of FreeDOS installation (binary images of a couple of basic DOS > utilities, shell and the kernel). I believe that it's probably illegal > (provided it's GPL code, I have not checked) to do this unless we > distribute sources as well. Following this, I decided to look at the source to see if it would be a trivial task to get the code running under gcc with nasm. It seems there are a couple of big problems. 1. The use of the FAR/far macros. These are a kickback to the old 16 bit days and as gcc doesn't have an 8086 backend, the closest I could find is Lambertsen's ia16 backend (from 2007). No idea if it'll do the job. 2. Next is the assembler bits. While nasm will compile 16 bit code, it's another pain in the backside to getting the source to build. It might be just as wise to drop FreeDOS completely... TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 mtasaka at ioa.s.u-tokyo.ac.jp Wed Mar 25 21:31:14 2009 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 26 Mar 2009 06:31:14 +0900 Subject: [Fedora-packaging] Directory ownership guidelines In-Reply-To: <1237958681.3018.10.camel@localhost.localdomain> References: <1237818667.19224.31.camel@ellert.tsl.uu.se> <49C79EF6.7080708@ioa.s.u-tokyo.ac.jp> <1237958681.3018.10.camel@localhost.localdomain> Message-ID: <49CAA2A2.602@ioa.s.u-tokyo.ac.jp> Hello: Mattias Ellert wrote, at 03/25/2009 02:24 PM +9:00: > m?n 2009-03-23 klockan 23:38 +0900 skrev Mamoru Tasaka: >> Mattias Ellert wrote, at 03/23/2009 11:31 PM +9:00: >>> Hi! >>> >>> It was suggested to me to bring this issue to this list. >>> >>> The packaging guidelines says that a package should not own a directory >>> that is owned by a package on which it depends. >>> >>> The packaging guidelines also says that packages should own all >>> directories needed in order not to leave orphaned directories after a >>> package de-installation. >>> >>> The way rpm/yum currently works these guidelines are contradicting and >>> you must choose which one to implement in your packaging. >>> >>> My question is - is this a bug in yum/rpm, or a flaw in the packaging >>> guidelines? >> I guess this is a bug in rpm. As far as I am correct current Fedora packaging >> guidelines assume this is properly handled by rpm. >> Actually I filed bug 490975 and am waiting for comments from rpm maintainers. >> >> Regards, >> Mamoru > > I added my test case to your existing bug report. > > Considering that this bug is the cause for thousands of packages > violating the packaging guidelines, should the severity/priority of the > bug be raised? Should it be made a blocker? > > Mattias For now I marked this as F11Target (I don't think that we should stop reviewing submitted review requests until this bug is fixed) Mamoru From lkundrak at v3.sk Wed Mar 25 22:01:13 2009 From: lkundrak at v3.sk (Lubomir Rintel) Date: Wed, 25 Mar 2009 23:01:13 +0100 Subject: [Fedora-packaging] Binary FreeDOS image In-Reply-To: <1238008756.17087.179.camel@PB3.Linux> References: <1237790874.3002.7.camel@localhost.localdomain> <1238008756.17087.179.camel@PB3.Linux> Message-ID: <1238018473.7357.32.camel@localhost.localdomain> On Wed, 2009-03-25 at 19:19 +0000, Paul wrote: > Hi, > > > I'm just reviewing a DOSEmu package, where the package author includes a > > tarball of FreeDOS installation (binary images of a couple of basic DOS > > utilities, shell and the kernel). I believe that it's probably illegal > > (provided it's GPL code, I have not checked) to do this unless we > > distribute sources as well. > > Following this, I decided to look at the source to see if it would be a > trivial task to get the code running under gcc with nasm. It seems there > are a couple of big problems. > > 1. The use of the FAR/far macros. These are a kickback to the old 16 bit > days and as gcc doesn't have an 8086 backend, the closest I could find > is Lambertsen's ia16 backend (from 2007). No idea if it'll do the job. What came to my mind here was dev86's bcc. I didn't even believe gcc compiles Intel 8086 code, though I've heard that it's used to compile Bochs BIOS, so... Anyways, I've not tried to get it to build with bcc, though I saw a mailing list post (I can't find it now) about it, that remained unanswered. > 2. Next is the assembler bits. While nasm will compile 16 bit code, it's > another pain in the backside to getting the source to build. I thought they already use nasm for their builds. At least their wiki says so [1]. [1] http://apps.sourceforge.net/mediawiki/freedos/index.php?title=FreeDOS_Spec#Programming_tools -- "Excuse all the blood" -- Dead From jwulf at redhat.com Thu Mar 26 07:19:33 2009 From: jwulf at redhat.com (Joshua Wulf) Date: Thu, 26 Mar 2009 17:19:33 +1000 Subject: [Fedora-packaging] Re: Publican Issues In-Reply-To: <49CB1E67.5060801@redhat.com> References: <1238016887.20751.64.camel@localhost.localdomain> <3A16D9F8583C409C824A6F6CE3E6E301@Aidan> <49CAE372.1070801@redhat.com> <49CB0163.3040809@fedoraproject.org> <49CB16EC.7060607@redhat.com> <49CB1BFF.80602@gmail.com> <49CB1E67.5060801@redhat.com> Message-ID: <49CB2C85.9040606@redhat.com> Joshua Wulf wrote: >> > I think that Jeff and Chris are referring to this: > https://bugzilla.redhat.com/show_bug.cgi?id=476471 Comment #58 by Jens Petersen: I am not veto'ing parallel install per se, but maybe it is worth considerng what is so special about docs packages that warrants/necessitates parallel install since we don't really do this for any other packages except libraries/tools needed occasionally for back-compatibility. The idea here is that people who are using Fedora in a production capacity, rather than just as a beta test of RHEL, are able to install multiple documentation sets. The use case would be like this: I'm a system administrator with a number of different servers on my network running different versions of Fedora. Some are internal servers and running the ancient Fedora 10. There is one running Fedora 15 that I'm intending to upgrade later. The ones on the firewall I run at latest-1, and are currently on Fedora 19. I'm running Fedora 20 on my personal workstation, and I have a virtual machine running Fedora Rawhide. On my Fedora 20 workstation I have the documentation for all of these different versions installed (F10, F15, F19, F20, Rawhide), so that I can refer to the relevant docs in my graphical user environment as I administer them remotely via ssh. That's the idea. It doesn't make much sense if you envision Fedora as a RHEL beta test that you scrap each time a new version comes out, but if it's a viable OS that can be deployed and used in a production capacity like that described above, parallel documentation installation will be useful. What are your thoughts on this? Josh -- Joshua J Wulf Engineering Content Services Red Hat Asia Pacific eml: jwulf at redhat.com tel: +61 (0)7 3514 8140 mob: +61 (0)431 929 675 tmz: GMT +10 (0) - omit when dialling internationally From jwulf at redhat.com Thu Mar 26 07:31:12 2009 From: jwulf at redhat.com (Joshua Wulf) Date: Thu, 26 Mar 2009 17:31:12 +1000 Subject: [Fedora-packaging] Re: Publican Issues In-Reply-To: <49CB2AC1.1070504@gmail.com> References: <1238016887.20751.64.camel@localhost.localdomain> <3A16D9F8583C409C824A6F6CE3E6E301@Aidan> <49CAE372.1070801@redhat.com> <49CB0163.3040809@fedoraproject.org> <49CB16EC.7060607@redhat.com> <49CB1BFF.80602@gmail.com> <49CB1E67.5060801@redhat.com> <49CB2AC1.1070504@gmail.com> Message-ID: <49CB2F40.3030301@redhat.com> Thanks for your response and suggestions Toshio. I think it's more venting frustration than actually blaming the FPC for being a roadblock. *Anything* that we can do to resolve these issues, keeping in mind the limited resources we are working with and the need to work together and forge stronger relationships going forward, will be great. Josh Toshio Kuratomi wrote: > Joshua Wulf wrote: > Thanks Joshua, > > >> I think that Jeff and Chris are referring to this: >> https://bugzilla.redhat.com/show_bug.cgi?id=476471 >> >> > IIUC, this boils down to: > 1) Publican creates a different documentation package for each Fedora > Release as it considers them to be separate documents. ie: > Fedora-10-Security-Guide, Fedora-11-Security-Guide. > > 2) This means a new package review for each documentation package each > release. > > If you're willing to go through a new review each release, there's no > problem. > > If you want a single review to cover you for all releases, we need a new > Guideline. I think if it's a potential goal to be able to install the > Fedora-10-Security-Guide on Fedora-11, then I'd be against such a > Guideline as separate packages really are what you want. If it's > specifically a non-goal to do that, then it's a possibility although > changing the name to not have the version in it strikes me as the better > option there. Following onto that, I'm not sure why you wouldn't want > to use publican to create an initial spec file and then modify it to > meet the specifics of the situation. This is the workflow for CPAN2RPM, > rpmdev-newspetemplate, and other tools. > > Another option is to look at a streamlined set of review items for > publican-created doc packages... We've never explicitly done this but in > practice, people know they don't have to check, for instance, shared > library guidelines when writing and reviewing a pure python module. > > >> and possibly this as well: >> https://bugzilla.redhat.com/show_bug.cgi?id=482972 >> >> > What's the problem here? That the .desktop is created inline in the > spec file instead of as a separate file? If that's all it is, I can > propose to the FPC to amend that. I can't recall a reason that it had > to be included in the SRPM as a file specifically. > > Note that neither of these issues had reached the FPC's radar (they > still haven't, really, as I'm only one member and this isn't the > packaging mailing list) so blaming the FPC as the roadblock is a bit > misplaced. > > -Toshio > > -- Joshua J Wulf Engineering Content Services Red Hat Asia Pacific eml: jwulf at redhat.com tel: +61 (0)7 3514 8140 mob: +61 (0)431 929 675 tmz: GMT +10 (0) - omit when dialling internationally From paul at all-the-johnsons.co.uk Thu Mar 26 23:07:03 2009 From: paul at all-the-johnsons.co.uk (Paul) Date: Thu, 26 Mar 2009 23:07:03 +0000 Subject: [Fedora-packaging] Advice over mono and rebuilding for silverlight Message-ID: <1238108823.17087.193.camel@PB3.Linux> Hi, I've had a request from rpmfusion to rebuild mono with the --with-moonlight flag set. This builds in the functionality required to build Silverlight on rpmfusion. I am aware that Fedora itself cannot have Silverlight in (the licence is the MS "shared source" (cough) licence) due to the potential for MS to do it's usual trick of going back on their word and applying patents to cause problems. While adding in the smcs and silverlight code possibly does not break any of the fedora rules, I am of the thinking that we don't add the flag for the same reason that we have disabled xmms for mp3; it has the potential to cause us problems. This is probably a question for the legal people, but I'm asking it here as I don't have the legal people's email address and it is also a packaging problem. If I get the okay to build mono with the flag, I will. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 caillon at redhat.com Thu Mar 26 23:43:27 2009 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 26 Mar 2009 16:43:27 -0700 Subject: [Fedora-packaging] Advice over mono and rebuilding for silverlight In-Reply-To: <1238108823.17087.193.camel@PB3.Linux> References: <1238108823.17087.193.camel@PB3.Linux> Message-ID: <49CC131F.9000403@redhat.com> On 03/26/2009 04:07 PM, Paul wrote: > This is probably a question for the legal people, but I'm asking it here > as I don't have the legal people's email addres http://www.redhat.com/mailman/listinfo/fedora-legal-list From makowski.fedora at gmail.com Fri Mar 27 16:28:57 2009 From: makowski.fedora at gmail.com (philippe makowski) Date: Fri, 27 Mar 2009 17:28:57 +0100 Subject: [Fedora-packaging] First post Message-ID: Hi, I'm new to the Fedora Project. I'm Philippe Makowski, member of the Firebird AdminTeam (www.firebirdsql.org) I jump here to help packaging Firebird and it's related tools inside Fedora. I hope that we will solve this request quick (https://bugzilla.redhat.com/show_bug.cgi?id=488100) so after, we can add at least Flamerobin and the Python driver for Firebird packages. If need, I think I can find time to be co maintainer of Firebird and related tools package. Wish you all sucess. From robert at fedoraproject.org Sat Mar 28 20:41:53 2009 From: robert at fedoraproject.org (Robert Scheck) Date: Sat, 28 Mar 2009 21:41:53 +0100 Subject: [Fedora-packaging] How to package a patched older version of libvmime in Fedora best? Message-ID: <20090328204153.GA11515@hurricane.linuxnetz.de> Good evening, I've the situation, that a package unluckily requires an older version of libvmime and some specific/individual patches as well. The question is now, how to package that best for Fedora and EPEL? What I'm requiring is libvmime 0.7.1 + patches, while upstream is at 0.9.1 which is unluckily ABI and API incompatible. There are now multiple solutions how to deal with this as I can't use 0.9.1 now and in foreseeable future: a) Build libvmime 0.7.1 + patches in before of the software requiring it and link statically against it. This would make sense in this case, even if static linking is discouraged in Fedora, but nothing except that piece of software requires actually libvmime 0.7.1 + individual patches. b) Build libvmime 0.7.1 + patches as own package and call it e.g. something like foobar-libvmime and rename libvmime.so.* to foobar-libvmime.so.* or similar. That would bring me to -lfoobar-libvmime linking or something similar, right? Just providing a compat-libvmime seems not suitable, as compat-* in Fedora is only providing the library, not -devel stuff which is actually needed to build the other software requiring the old libvmime 0.7.1 + patches. As of overlapping *.so filenames, it is not possible to avoid renaming the patched version. Question is, which is better and which one will go through the package review or are there better ideas how to solve this? Yes, some far day, upstream will accept all of the individual patches and the other software will support latest libvmime version, but this won't be in the next time as libvmime support is somehow seemingly less interested in being backward compatible. Greetings, Robert From rc040203 at freenet.de Tue Mar 31 14:16:38 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 31 Mar 2009 16:16:38 +0200 Subject: [Fedora-packaging] Re: Agenda for the 2009-03-31 Packaging Committee meeting In-Reply-To: References: Message-ID: <49D225C6.3010400@freenet.de> Jason L Tibbitts III wrote: > The Packaging Committee will meet Tuesday, 2009-03-31 at 17:00UTC in > the #fedora-meeting channel on chat.freenode.net. Due to Europe having shifted to DST, 17:00UTC is once again (as in previous years) hardly suitable for me. I'll very likely not be able to attend many upcoming FPC meetings, rsp. if I can attend, will have to leave early. Ralf