From phrkonaleash at gmail.com Tue Sep 1 03:52:31 2009 From: phrkonaleash at gmail.com (Ryan Rix) Date: Mon, 31 Aug 2009 20:52:31 -0700 Subject: [Fedora-packaging] Re: Packaging a game, need help with setgid security References: <29fee02b0908310141k43d80fa4n269158b7cfcadc5c@mail.gmail.com> Message-ID: Andrea Musuruane wrote: > On Mon, Aug 31, 2009 at 7:55 AM, Ryan Rix wrote: >> Like many roguelikes, it has a shared high score file and Bones files >> that all users are meant to have their scores and final data written to. >> As a result, the game is forced to run setgid games so that it has the >> rights to write to /var/games/ivan/. While packaging this application, I >> got a lot of help from some of the Fedora-KDE guys (hi Kevin, Ben) and >> they both suggested I run this through Fedora Security SIG so that the >> game would properly demote itself to non-setgid when it doesn't need to. >> >> What is the proper channel to go about this? Should I just mail to the >> security list? Should I put this package up for review beforehand/in the >> meantime? > > The game must drop setuid as early as possible: > http://fedoraproject.org/wiki/SIGs/Games/Packaging > > If you need help, consider writing to the fedora-games-list: > http://www.redhat.com/mailman/listinfo/fedora-games-list I didn't think of this when I first wrote my post but now am realizing that the application creates Bones files when a player dies in /var/games/ivan... :( How would I apply setgid rules to this scenario? I cannot accurately predict the name of the bones file in the main() and cannot create a new file every single time the application starts up, so I am unsure of how to handle that. Suggestions? -- Ryan Rix (623)-826-0051 Fortune: Truth can wait; he's used to it. http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels. From frankel at circlesfx.com Tue Sep 1 06:07:13 2009 From: frankel at circlesfx.com (Scott Frankel) Date: Mon, 31 Aug 2009 23:07:13 -0700 Subject: [Fedora-packaging] unwanted directory removal during rpm build Message-ID: Hello, I'm new to rpm package development and just joined this list. I'm trying to create an rpm, but working subdirs of BUILDROOT are getting deleted between %build and %install. This causes subsequent copy operations to fail and rpmbuild to error out with a bad exit status. The `rm -rf` that removes the working dir is not coming from any explicit statement in my spec file. I'm copying pertinent lines from shell output, the spec file, and system configuration below. I'm hopeful someone can suggest a work- around. Thanks in advance! Scott From shell output. Note the `rm -rf` line (line 18) before the `cp - r` that expects to access the subdirs, /opt/foo. [ ... ] Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.j5y3vI + umask 022 + cd /home/frankel/foo/versions/0.9.6/fedora/BUILD + cd foo-0.9.6 + LANG=C + export LANG + unset DISPLAY + rm -rf /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64 + mkdir /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64 + mkdir /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64/foo + mkdir /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64/opt + mkdir /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64/opt/foo + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.rQlamD + umask 022 + cd /home/frankel/foo/versions/0.9.6/fedora/BUILD + '[' /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64 '!=' / ']' + rm -rf /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64 ++ dirname /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64 + mkdir -p /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT + mkdir /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64 + cd foo-0.9.6 + LANG=C + export LANG + unset DISPLAY + cp -r schema /home/frankel/foo/versions/0.9.6/fedora/BUILDROOT/ foo-0.9-6.x86_64/opt/foo cp: cannot create directory `/home/frankel/foo/versions/0.9.6/fedora/ BUILDROOT/foo-0.9-6.x86_64/opt/foo': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.rQlamD (%install) [ ... ] I'm using the following one-liner in a bash script to execute the build: setarch x86_64 rpmbuild -ba --define "_topdir `pwd`" --define "_arch x86_64" $1 The spec file has this %build section (in its entirety), followed by the first of the failed copies. Note that these are contiguous lines of specfile code between %build and %install. [ ... ] %build rm -rf $RPM_BUILD_ROOT mkdir $RPM_BUILD_ROOT mkdir $RPM_BUILD_ROOT/opt mkdir $RPM_BUILD_ROOT/opt/foo %install cp -r schema $RPM_BUILD_ROOT/opt/foo [ ... ] Here's a yum list rpm* from my system: Installed Packages rpm.x86_64 4.7.1-1.fc11 installed rpm-apidocs.noarch 4.7.1-1.fc11 installed rpm-build.x86_64 4.7.1-1.fc11 installed rpm-devel.x86_64 4.7.1-1.fc11 installed rpm-libs.x86_64 4.7.1-1.fc11 installed rpm-python.x86_64 4.7.1-1.fc11 installed rpmconf.noarch 0.1.6-1.fc11 installed rpmdepsize.x86_64 1.0-3.fc11 installed rpmdevtools.noarch 7.3-1.fc11 installed rpmlint.noarch 0.90-1.fc11 installed rpmorphan.noarch 1.4-5.fc11 installed rpmreaper.x86_64 0.1.6-1.fc11 installed rpmrebuild.noarch 2.3-3.fc11 installed Available Packages rpm-devel.i586 4.7.1-1.fc11 updates rpm-libs.i586 4.7.1-1.fc11 updates From mattias.ellert at fysast.uu.se Tue Sep 1 07:20:42 2009 From: mattias.ellert at fysast.uu.se (Mattias Ellert) Date: Tue, 01 Sep 2009 09:20:42 +0200 Subject: [Fedora-packaging] unwanted directory removal during rpm build In-Reply-To: References: Message-ID: <1251789642.31404.12.camel@ellert.tsl.uu.se> m?n 2009-08-31 klockan 23:07 -0700 skrev Scott Frankel: > Hello, > > I'm new to rpm package development and just joined this list. I'm > trying to create an rpm, but working subdirs of BUILDROOT are getting > deleted between %build and %install. This causes subsequent copy > operations to fail and rpmbuild to error out with a bad exit status. > The `rm -rf` that removes the working dir is not coming from any > explicit statement in my spec file. > > I'm copying pertinent lines from shell output, the spec file, and > system configuration below. I'm hopeful someone can suggest a work- > around. > > Thanks in advance! > Scott > The spec file has this %build section (in its entirety), followed by > the first of the failed copies. Note that these are contiguous lines > of specfile code between %build and %install. > > [ ... ] > %build > rm -rf $RPM_BUILD_ROOT > mkdir $RPM_BUILD_ROOT > mkdir $RPM_BUILD_ROOT/opt > mkdir $RPM_BUILD_ROOT/opt/foo > > > %install > cp -r schema $RPM_BUILD_ROOT/opt/foo > [ ... ] The %build section must not create files or directories in the $RPM_BUILD_ROOT. That must only be done in the %install section. The Fedora packaging guidelines says that the first command in the %install section must be "rm -rf $RPM_BUILD_ROOT". If you are using a recent RPM version this will be enforced automatically, which is what happens in this case. %build %install rm -rf $RPM_BUILD_ROOT mkdir $RPM_BUILD_ROOT mkdir $RPM_BUILD_ROOT/opt mkdir $RPM_BUILD_ROOT/opt/foo cp -r schema $RPM_BUILD_ROOT/opt/foo 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 ultrafredde at gmail.com Tue Sep 1 13:50:04 2009 From: ultrafredde at gmail.com (Federico Hernandez) Date: Tue, 1 Sep 2009 15:50:04 +0200 Subject: [Fedora-packaging] Re: F-11 to F-12 transition In-Reply-To: References: <690f5ac90906091002n727a92d8x67ff0e87cdd3a84b@mail.gmail.com> <690f5ac90908241235j13a91c32o65e23ee3d400be2d@mail.gmail.com> Message-ID: <690f5ac90909010650pdf99432kef4b5185c9b7d911@mail.gmail.com> > > For posterity: > https://www.redhat.com/archives/fedora-devel-announce/2009- > August/msg00010.html > Thank you Rex. /Fredde -------------- next part -------------- An HTML attachment was scrubbed... URL: From frankel at circlesfx.com Tue Sep 1 16:09:35 2009 From: frankel at circlesfx.com (Scott Frankel) Date: Tue, 1 Sep 2009 09:09:35 -0700 Subject: [Fedora-packaging] unwanted directory removal during rpm build In-Reply-To: <1251789642.31404.12.camel@ellert.tsl.uu.se> References: <1251789642.31404.12.camel@ellert.tsl.uu.se> Message-ID: <2D2D22DF-3757-4047-8339-2D39428B5003@circlesfx.com> On Sep 1, 2009, at 12:20 AM, Mattias Ellert wrote: > m?n 2009-08-31 klockan 23:07 -0700 skrev Scott Frankel: > The %build section must not create files or directories in the > $RPM_BUILD_ROOT. That must only be done in the %install section. > > The Fedora packaging guidelines says that the first command in the > %install section must be "rm -rf $RPM_BUILD_ROOT". If you are using a > recent RPM version this will be enforced automatically, which is what > happens in this case. > > %build > > %install > rm -rf $RPM_BUILD_ROOT > mkdir $RPM_BUILD_ROOT > mkdir $RPM_BUILD_ROOT/opt > mkdir $RPM_BUILD_ROOT/opt/foo > cp -r schema $RPM_BUILD_ROOT/opt/foo Thanks for the information! Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Wed Sep 2 08:32:56 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 02 Sep 2009 10:32:56 +0200 Subject: [Fedora-packaging] Re: Packaging a game, need help with setgid security In-Reply-To: References: <29fee02b0908310141k43d80fa4n269158b7cfcadc5c@mail.gmail.com> Message-ID: <4A9E2DB8.2070305@hhs.nl> Hi, On 09/01/2009 05:52 AM, Ryan Rix wrote: > Andrea Musuruane wrote: > >> On Mon, Aug 31, 2009 at 7:55 AM, Ryan Rix wrote: >>> Like many roguelikes, it has a shared high score file and Bones files >>> that all users are meant to have their scores and final data written to. >>> As a result, the game is forced to run setgid games so that it has the >>> rights to write to /var/games/ivan/. While packaging this application, I >>> got a lot of help from some of the Fedora-KDE guys (hi Kevin, Ben) and >>> they both suggested I run this through Fedora Security SIG so that the >>> game would properly demote itself to non-setgid when it doesn't need to. >>> >>> What is the proper channel to go about this? Should I just mail to the >>> security list? Should I put this package up for review beforehand/in the >>> meantime? >> >> The game must drop setuid as early as possible: >> http://fedoraproject.org/wiki/SIGs/Games/Packaging >> >> If you need help, consider writing to the fedora-games-list: >> http://www.redhat.com/mailman/listinfo/fedora-games-list > > I didn't think of this when I first wrote my post but now am realizing that > the application creates Bones files when a player dies in /var/games/ivan... > :( How would I apply setgid rules to this scenario? I cannot accurately > predict the name of the bones file in the main() and cannot create a new > file every single time the application starts up, so I am unsure of how to > handle that. > > Suggestions? > This is a known issue with roguelikes, we've solved this for the other roguelikes (see there spec files) by creating a group esp. for the game and making it sgid itsowngroup and never dropping the sgid rights. This way we strongly limit the amount of damage / attacks which can be done by not dropping sgid, this is the best security versus usability trade off we could come up with for rogue likes. Regards, Hans From notting at redhat.com Wed Sep 2 15:47:04 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 Sep 2009 11:47:04 -0400 Subject: [Fedora-packaging] Directory draft (was Re: Triggers just to avoid unowned directories?) In-Reply-To: <615c05430909020057j17a5adb2h660ebee6346941ee@mail.gmail.com> References: <20090901073501.028929e4@faldor.intranet> <1251812042.2027.1610.camel@atropine.boston.devel.redhat.com> <4A9D7130.3030704@REDHAT.COM> <20090901214404.GQ28495@nostromo.devel.redhat.com> <1251843205.10114.6.camel@localhost.localdomain> <615c05430909020057j17a5adb2h660ebee6346941ee@mail.gmail.com> Message-ID: <20090902154704.GB8929@nostromo.devel.redhat.com> Michel Alexandre Salim (michael.silvanus at gmail.com) said: > >> Multi-ownership seems *far* preferable to me than using triggers to > >> move files around, or moving a prelink-specific directory to the base > >> filesystem package. > > > > Then the guidelines should be fixed to create less confusion over the > > matter. > > > Another precedence is with bash-completion -- the consensus is for > packages that provide completion scripts to own /etc/bash_completion.d OK, I've written up the following, which should be more clear: https://fedoraproject.org/wiki/BillNottingham/DirectoryDraft Comments? Bill From tcallawa at redhat.com Wed Sep 2 15:53:21 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 02 Sep 2009 11:53:21 -0400 Subject: [Fedora-packaging] Directory draft (was Re: Triggers just to avoid unowned directories?) In-Reply-To: <20090902154704.GB8929@nostromo.devel.redhat.com> References: <20090901073501.028929e4@faldor.intranet> <1251812042.2027.1610.camel@atropine.boston.devel.redhat.com> <4A9D7130.3030704@REDHAT.COM> <20090901214404.GQ28495@nostromo.devel.redhat.com> <1251843205.10114.6.camel@localhost.localdomain> <615c05430909020057j17a5adb2h660ebee6346941ee@mail.gmail.com> <20090902154704.GB8929@nostromo.devel.redhat.com> Message-ID: <4A9E94F1.2040807@redhat.com> On 09/02/2009 11:47 AM, Bill Nottingham wrote: > Michel Alexandre Salim (michael.silvanus at gmail.com) said: >>>> Multi-ownership seems *far* preferable to me than using triggers to >>>> move files around, or moving a prelink-specific directory to the base >>>> filesystem package. >>> >>> Then the guidelines should be fixed to create less confusion over the >>> matter. >>> >> Another precedence is with bash-completion -- the consensus is for >> packages that provide completion scripts to own /etc/bash_completion.d > > OK, I've written up the following, which should be more clear: > > https://fedoraproject.org/wiki/BillNottingham/DirectoryDraft > > Comments? Seems sane to me. ~spot From mclasen at redhat.com Wed Sep 2 16:03:49 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 02 Sep 2009 12:03:49 -0400 Subject: [Fedora-packaging] Re: Directory draft (was Re: Triggers just to avoid unowned directories?) In-Reply-To: <20090902154704.GB8929@nostromo.devel.redhat.com> References: <20090901073501.028929e4@faldor.intranet> <1251812042.2027.1610.camel@atropine.boston.devel.redhat.com> <4A9D7130.3030704@REDHAT.COM> <20090901214404.GQ28495@nostromo.devel.redhat.com> <1251843205.10114.6.camel@localhost.localdomain> <615c05430909020057j17a5adb2h660ebee6346941ee@mail.gmail.com> <20090902154704.GB8929@nostromo.devel.redhat.com> Message-ID: <1251907429.2881.32.camel@planemask> On Wed, 2009-09-02 at 11:47 -0400, Bill Nottingham wrote: > Michel Alexandre Salim (michael.silvanus at gmail.com) said: > > >> Multi-ownership seems *far* preferable to me than using triggers to > > >> move files around, or moving a prelink-specific directory to the base > > >> filesystem package. > > > > > > Then the guidelines should be fixed to create less confusion over the > > > matter. > > > > > Another precedence is with bash-completion -- the consensus is for > > packages that provide completion scripts to own /etc/bash_completion.d > > OK, I've written up the following, which should be more clear: > > https://fedoraproject.org/wiki/BillNottingham/DirectoryDraft > > Comments? I think it would be good to expand this to include some guidance on -filesystem packages and when they are an appropriate solution. From rc040203 at freenet.de Wed Sep 2 16:11:08 2009 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 Sep 2009 18:11:08 +0200 Subject: [Fedora-packaging] Directory draft (was Re: Triggers just to avoid unowned directories?) In-Reply-To: <20090902154704.GB8929@nostromo.devel.redhat.com> References: <20090901073501.028929e4@faldor.intranet> <1251812042.2027.1610.camel@atropine.boston.devel.redhat.com> <4A9D7130.3030704@REDHAT.COM> <20090901214404.GQ28495@nostromo.devel.redhat.com> <1251843205.10114.6.camel@localhost.localdomain> <615c05430909020057j17a5adb2h660ebee6346941ee@mail.gmail.com> <20090902154704.GB8929@nostromo.devel.redhat.com> Message-ID: <4A9E991C.10002@freenet.de> On 09/02/2009 05:47 PM, Bill Nottingham wrote: > Michel Alexandre Salim (michael.silvanus at gmail.com) said: >>>> Multi-ownership seems *far* preferable to me than using triggers to >>>> move files around, or moving a prelink-specific directory to the base >>>> filesystem package. >>> >>> Then the guidelines should be fixed to create less confusion over the >>> matter. >>> >> Another precedence is with bash-completion -- the consensus is for >> packages that provide completion scripts to own /etc/bash_completion.d > > OK, I've written up the following, which should be more clear: > > https://fedoraproject.org/wiki/BillNottingham/DirectoryDraft > > Comments? This proposal goes into the right direction. However I find it somewhat confusing, because it doesn't mention the actual rationales/motivations for when to apply "multiple owners" or "package deps" (The rationale is strict and permanent package hierarchies vs. "no or varying hierarchies") Ralf From a.badger at gmail.com Wed Sep 2 16:12:20 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 02 Sep 2009 09:12:20 -0700 Subject: [Fedora-packaging] Re: Directory draft (was Re: Triggers just to avoid unowned directories?) In-Reply-To: <20090902154704.GB8929@nostromo.devel.redhat.com> References: <20090901073501.028929e4@faldor.intranet> <1251812042.2027.1610.camel@atropine.boston.devel.redhat.com> <4A9D7130.3030704@REDHAT.COM> <20090901214404.GQ28495@nostromo.devel.redhat.com> <1251843205.10114.6.camel@localhost.localdomain> <615c05430909020057j17a5adb2h660ebee6346941ee@mail.gmail.com> <20090902154704.GB8929@nostromo.devel.redhat.com> Message-ID: <4A9E9964.6000307@gmail.com> On 09/02/2009 08:47 AM, Bill Nottingham wrote: > Michel Alexandre Salim (michael.silvanus at gmail.com) said: >>>> Multi-ownership seems *far* preferable to me than using triggers to >>>> move files around, or moving a prelink-specific directory to the base >>>> filesystem package. >>> >>> Then the guidelines should be fixed to create less confusion over the >>> matter. >>> >> Another precedence is with bash-completion -- the consensus is for >> packages that provide completion scripts to own /etc/bash_completion.d > > OK, I've written up the following, which should be more clear: > > https://fedoraproject.org/wiki/BillNottingham/DirectoryDraft > Section 1.3 Optional functoinality is a special case of Section 1.5 Common directory without one requiring the other. I'd combine them like this: """ Multiple packages have files in a common directory but none of them needs to require the others. An example: bash-completion owns the /etc/bash_completion.d directory and uses the files placed in there to configure itself git places files into /etc/bash_completion.d bzr places files into /etc/bash_completion.d Solution: Both the git and bzr packages should own the /etc/bash_completion.d directory as bash-completion is optional functionality and the installation of git or bzr should not force the installation of bash-completion. """ And one more idea to throw out there: How sacred is filesystem? How costly are adding new directories to it? For something like /etc/prelink.conf.d, adding to filesystem seems like the preferred option. If there's little cost involved, adding to filesystem for things like /etc/bash_completion.d also seems like the preferred solution. If there's no reason we shouldn't be expanding filesystem, I'd list that as an option in the directory draft as well. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From notting at redhat.com Wed Sep 2 16:59:36 2009 From: notting at redhat.com (Bill Nottingham) Date: Wed, 2 Sep 2009 12:59:36 -0400 Subject: [Fedora-packaging] Re: Directory draft (was Re: Triggers just to avoid unowned directories?) In-Reply-To: <4A9E9964.6000307@gmail.com> References: <20090901073501.028929e4@faldor.intranet> <1251812042.2027.1610.camel@atropine.boston.devel.redhat.com> <4A9D7130.3030704@REDHAT.COM> <20090901214404.GQ28495@nostromo.devel.redhat.com> <1251843205.10114.6.camel@localhost.localdomain> <615c05430909020057j17a5adb2h660ebee6346941ee@mail.gmail.com> <20090902154704.GB8929@nostromo.devel.redhat.com> <4A9E9964.6000307@gmail.com> Message-ID: <20090902165935.GC13267@nostromo.devel.redhat.com> Toshio Kuratomi (a.badger at gmail.com) said: > Section 1.3 Optional functoinality is a special case of Section 1.5 > Common directory without one requiring the other. I'd combine them like > this: I've updated the proposal based on this and other feedback. > And one more idea to throw out there: How sacred is filesystem? How > costly are adding new directories to it? For something like > /etc/prelink.conf.d, adding to filesystem seems like the preferred > option. If there's little cost involved, adding to filesystem for > things like /etc/bash_completion.d also seems like the preferred > solution. If there's no reason we shouldn't be expanding filesystem, > I'd list that as an option in the directory draft as well. My main objections would be: 1) filesystem started out as just the FHS dirs 2) We don't want a bunch of orphan directories if things like prelink change 3) We don't want to tie package submission on changes that would require updates on unrelated packages in older distributions. It's a combination of philosophical (#1) and practical (#2 and #3) concerns. We could expclitly state this in the draft if you want. Bill From michael.silvanus at gmail.com Wed Sep 2 18:06:41 2009 From: michael.silvanus at gmail.com (Michel Alexandre Salim) Date: Wed, 2 Sep 2009 14:06:41 -0400 Subject: [Fedora-packaging] Need access to a PPC machine to debug LLVM/pure self-test issues Message-ID: <615c05430909021106m246446e8p6080efe451ea732f@mail.gmail.com> Hi, I'm currently packaging pure, and there are some issues on several architectures (Rawhide/x86_64 and ppc on any Fedora release). The upstream developer is interested in getting the issues fixed, and while I can help debug the x86_64 issues, PPC would really require access to a PPC machine. Does anyone have access to such a machine that they can provide an SSH login for? There might be some rather heavy-duty compilation involved at the beginning (experimenting with LLVM build options) but after that it's a matter of building a small-ish package, pure, against it. Kevin Fenzi gave me access several months ago, IIRC, but it has expired by now (and anyway, it was for my public key, not the developer's). Upstream issue being tracked here; http://code.google.com/p/pure-lang/issues/detail?id=13 Thanks, -- Michel Alexandre Salim From kevin at tummy.com Wed Sep 2 18:13:24 2009 From: kevin at tummy.com (Kevin Fenzi) Date: Wed, 2 Sep 2009 12:13:24 -0600 Subject: [Fedora-packaging] Need access to a PPC machine to debug LLVM/pure self-test issues In-Reply-To: <615c05430909021106m246446e8p6080efe451ea732f@mail.gmail.com> References: <615c05430909021106m246446e8p6080efe451ea732f@mail.gmail.com> Message-ID: <20090902121324.2bffda50@ohm.scrye.com> On Wed, 2 Sep 2009 14:06:41 -0400 Michel Alexandre Salim wrote: > Hi, > > I'm currently packaging pure, and there are some issues on several > architectures (Rawhide/x86_64 and ppc on any Fedora release). The > upstream developer is interested in getting the issues fixed, and > while I can help debug the x86_64 issues, PPC would really require > access to a PPC machine. > > Does anyone have access to such a machine that they can provide an SSH > login for? There might be some rather heavy-duty compilation involved > at the beginning (experimenting with LLVM build options) but after > that it's a matter of building a small-ish package, pure, against it. > > Kevin Fenzi gave me access several months ago, IIRC, but it has > expired by now (and anyway, it was for my public key, not the > developer's). If you are in the packager group you have access to all my test machines: https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers Please contact me off list about getting this developer access. I would need a ssh public key at least from them and a preffered account name. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From michael.silvanus at gmail.com Wed Sep 2 18:47:29 2009 From: michael.silvanus at gmail.com (Michel Alexandre Salim) Date: Wed, 2 Sep 2009 14:47:29 -0400 Subject: [Fedora-packaging] Need access to a PPC machine to debug LLVM/pure self-test issues In-Reply-To: <20090902121324.2bffda50@ohm.scrye.com> References: <615c05430909021106m246446e8p6080efe451ea732f@mail.gmail.com> <20090902121324.2bffda50@ohm.scrye.com> Message-ID: <615c05430909021147q1467b9d9sebb6c9a7fb31abb8@mail.gmail.com> On Wed, Sep 2, 2009 at 2:13 PM, Kevin Fenzi wrote: > If you are in the packager group you have access to all my test > machines: > > https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers > Aha, neat! > Please contact me off list about getting this developer access. > I would need a ssh public key at least from them and a preffered > account name. > Will do that as soon as I get the public key. Thanks, -- Michel From ville.skytta at iki.fi Wed Sep 2 19:05:00 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 2 Sep 2009 22:05:00 +0300 Subject: [Fedora-packaging] "Explicit requires" and "requiring base package" In-Reply-To: <200905021334.56366.ville.skytta@iki.fi> References: <200905021334.56366.ville.skytta@iki.fi> Message-ID: <200909022205.00396.ville.skytta@iki.fi> Ping, any comments on this? On Saturday 02 May 2009, Ville Skytt? wrote: > https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires > Packages must not contain explicit Requires on libraries except when > absolutely necessary. [...] > > https://fedoraproject.org/wiki/Packaging/Guidelines#Requiring_Base_Package > Devel packages must require the base package using a fully versioned > dependency: Requires: %{name} = %{version}-%{release}. Usually, > subpackages other than -devel should also require the base package using a > fully versioned dependency. > > I think these two guidelines or their wording are more or less in conflict > these days. Most -devel packages do not "absolutely necessarily" need an > explicit dependency on the base package because rpm automatically adds > soname dependencies from symlinks in -devel to the corresponding shared lib > in the main/lib package. Ditto, many cases of other non-devel subpackages > get automatic lib soname dependencies to the main/lib package. > > If the intent is to still require explicit deps like in "requiring base > package" even though there are automatic ones that would usually work, just > to be sure or for other reasons (possibility of compilation options, > patchwork that affects some internal subpackages but not other -devel/lib > package consumers), I think "requiring base packages" and "explicit > requires" should be cross referenced noting that this is an exception and > those explicit deps are indeed wanted. > > If not, IMO "requiring base package" should be softened so that it requires > adding those explicit deps if no automatic ones are present, or just > removed because that'd be redundant with "explicit requires" and the rest > of the general dependency guidelines. From rdieter at math.unl.edu Wed Sep 2 19:10:25 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 02 Sep 2009 14:10:25 -0500 Subject: [Fedora-packaging] "Explicit requires" and "requiring base package" In-Reply-To: <200909022205.00396.ville.skytta@iki.fi> References: <200905021334.56366.ville.skytta@iki.fi> <200909022205.00396.ville.skytta@iki.fi> Message-ID: <4A9EC321.5030102@math.unl.edu> Ville Skytt? wrote: > Ping, any comments on this? > > On Saturday 02 May 2009, Ville Skytt? wrote: >> https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires >> Packages must not contain explicit Requires on libraries except when >> absolutely necessary. [...] >> >> https://fedoraproject.org/wiki/Packaging/Guidelines#Requiring_Base_Package >> Devel packages must require the base package using a fully versioned >> dependency: Requires: %{name} = %{version}-%{release}. Usually, >> subpackages other than -devel should also require the base package using a >> fully versioned dependency. >> >> I think these two guidelines or their wording are more or less in conflict >> these days. Most -devel packages do not "absolutely necessarily" need an >> explicit dependency on the base package because rpm automatically adds >> soname dependencies from symlinks in -devel to the corresponding shared lib >> in the main/lib package. Ditto, many cases of other non-devel subpackages >> get automatic lib soname dependencies to the main/lib package. I dont agree with this assertion. rpm may have implicit dependencies on base pkgs (from -devel ones) but these often aren't enough to ensure things "just work". This falls under the "except when ... necessary" section of the Explict_Requires guideline, imo. -- Rex From ville.skytta at iki.fi Wed Sep 2 19:54:53 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 2 Sep 2009 22:54:53 +0300 Subject: [Fedora-packaging] "Explicit requires" and "requiring =?iso-8859-1?q?base=09package?=" In-Reply-To: <4A9EC321.5030102@math.unl.edu> References: <200905021334.56366.ville.skytta@iki.fi> <200909022205.00396.ville.skytta@iki.fi> <4A9EC321.5030102@math.unl.edu> Message-ID: <200909022254.54003.ville.skytta@iki.fi> On Wednesday 02 September 2009, Rex Dieter wrote: > rpm may have implicit dependencies on > base pkgs (from -devel ones) but these often aren't enough to ensure > things "just work". This falls under the "except when ... necessary" > section of the Explict_Requires guideline, imo. That's fine, I don't have that strong opinions on it. But Explicit Requires also says "When explicit library Requires are necessary, there should be a spec file comment justifying it." So in other words, libfoo-devel's explicit dependency on libfoo would need such a comment. I don't think that's the intent. This could be improved by saying "When explicit library Requires are necessary, there should be a spec file comment justifying it, except in cases that fall under the Requiring Base Package guideline." From ville.skytta at iki.fi Wed Sep 2 19:58:40 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 2 Sep 2009 22:58:40 +0300 Subject: [Fedora-packaging] AutoProvidesAndRequiresFiltering comments Message-ID: <200909022258.40772.ville.skytta@iki.fi> A couple of comments to http://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFiltering 1) Usage I suggest changing "MUST only be used with packages which meet the following criteria:" to "MUST only be used with packages which meet one of the following criteria:" as both can't be satisifed by any package. 2) Compatibility A note/tip about older/other distro (e.g. EPEL) compatibility would be nice so applying this stuff wouldn't require specfile forking or fragile distro/version checks. For example wrapping stuff in %{?filter_setup: ...} works (i.e. gets bypassed when not available), e.g. like: %{?filter_setup: %filter_provides_in /some/path %filter_setup} From caillon at redhat.com Wed Sep 2 19:59:31 2009 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 02 Sep 2009 12:59:31 -0700 Subject: [Fedora-packaging] Re: Directory draft (was Re: Triggers just to avoid unowned directories?) In-Reply-To: <1251907429.2881.32.camel@planemask> References: <20090901073501.028929e4@faldor.intranet> <1251812042.2027.1610.camel@atropine.boston.devel.redhat.com> <4A9D7130.3030704@REDHAT.COM> <20090901214404.GQ28495@nostromo.devel.redhat.com> <1251843205.10114.6.camel@localhost.localdomain> <615c05430909020057j17a5adb2h660ebee6346941ee@mail.gmail.com> <20090902154704.GB8929@nostromo.devel.redhat.com> <1251907429.2881.32.camel@planemask> Message-ID: <4A9ECEA3.5090203@redhat.com> On 09/02/2009 09:03 AM, Matthias Clasen wrote: > On Wed, 2009-09-02 at 11:47 -0400, Bill Nottingham wrote: >> Michel Alexandre Salim (michael.silvanus at gmail.com) said: >>>>> Multi-ownership seems *far* preferable to me than using triggers to >>>>> move files around, or moving a prelink-specific directory to the base >>>>> filesystem package. >>>> >>>> Then the guidelines should be fixed to create less confusion over the >>>> matter. >>>> >>> Another precedence is with bash-completion -- the consensus is for >>> packages that provide completion scripts to own /etc/bash_completion.d >> >> OK, I've written up the following, which should be more clear: >> >> https://fedoraproject.org/wiki/BillNottingham/DirectoryDraft >> >> Comments? > > I think it would be good to expand this to include some guidance on > -filesystem packages and when they are an appropriate solution. Especially since one of the examples cited solves this by way of a -filesystem package (mozilla-filesystem). From ville.skytta at iki.fi Wed Sep 2 20:07:54 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 2 Sep 2009 23:07:54 +0300 Subject: [Fedora-packaging] Re: AutoProvidesAndRequiresFiltering comments In-Reply-To: <200909022258.40772.ville.skytta@iki.fi> References: <200909022258.40772.ville.skytta@iki.fi> Message-ID: <200909022307.54082.ville.skytta@iki.fi> On Wednesday 02 September 2009, you wrote: > A couple of comments to > http://fedoraproject.org/wiki/PackagingDrafts/AutoProvidesAndRequiresFilter >ing One more: 3) "Post-scan provides filtering is invoked through the %filter_from_provides. This macro can be fed PCRE's to filter from the stream of auto-found provides." This description does not appear to match the example following it nor the current implementation in redhat-rpm-config. AFAICS %filter_from_* take plain sed expressions, not filtering PCRE's. From phrkonaleash at gmail.com Wed Sep 2 21:47:54 2009 From: phrkonaleash at gmail.com (Ryan Rix) Date: Wed, 02 Sep 2009 14:47:54 -0700 Subject: [Fedora-packaging] Re: Re: Packaging a game, need help with setgid security References: <29fee02b0908310141k43d80fa4n269158b7cfcadc5c@mail.gmail.com> <4A9E2DB8.2070305@hhs.nl> Message-ID: Hans de Goede wrote: > > This is a known issue with roguelikes, we've solved this for the other > roguelikes (see there spec files) by creating a group esp. for the game > and making it sgid itsowngroup and never dropping the sgid rights. This > way we strongly limit the amount of damage / attacks which can be done by > not dropping sgid, this is the best security versus usability trade off we > could come up with for rogue likes. > > Regards, > > Hans Looking at the specs for nethack, ularn and rogue (cvs.fedoraproject.org/viewvc) shows that these are simply setgid games. I did not look at the actual code to see how they handle setgid. Could you point me to something in particular? Thank you for your time, Ryan Rix -- Ryan Rix (623)-826-0051 Fortune: C++ is the best example of second-system effect since OS/360. http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels. From ramforummail at gmail.com Thu Sep 3 12:06:58 2009 From: ramforummail at gmail.com (ram s) Date: Thu, 3 Sep 2009 17:36:58 +0530 Subject: [Fedora-packaging] RPM packaging for fedora 10 problem Message-ID: Hello all, sorry to ask questions again and again. I am new to rpm packaging. I am trying to create one RPM package for my daemon application in Fedora 10. daemon application contains , 1. daemon.c 2. daemon.h 3. list.c 4.list.h 5.makefile. So , I am just tar the daemon application as "daemon.tar.gz". I put this daemon.tar.gz in /home/user/rpmbuild/SOURCES directory. I am creating spec filr and put it in /home/user/rpmbuild/SPECS directory. Now, I am trying to create binary RPM for my application. I am in x86_64 architecture. when I run *rpmbuild -bs daemon-1.spec* and then *rpmbuild -bb daemon-1.spec* only source rpm created. Binary RPM is not created. How to cretae binary RPM for my application. If my spec file is wrong, please correct me. I create .rpmmacros in my home director (/home/user/). MY spec file is, [SPEC] Summary: This Package install Daemon application Name: daemon Version:1 Release:1 License: GPL Group: Applications/System Source:daemon.tar.gz BuildRoot: /home/nco_user/rpmbuild/tmp BuildArch:noarch Packager:S.J.Ram %description This Package install Daemon application %prep %setup -q %build make %install rm -rf $RPM_BUILD_ROOT make install %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root,-) %{_tmppath}/daemon [/SPEC] please guide me to create binary rpm. Do I need to change SPEC file?. If any one already did RPM package for their C or java application, please give me the example (with one tar.gz file) thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at danny.cz Thu Sep 3 12:11:58 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 03 Sep 2009 14:11:58 +0200 Subject: [Fedora-packaging] RPM packaging for fedora 10 problem In-Reply-To: References: Message-ID: <1251979918.17881.3.camel@eagle.danny.cz> ram s p??e v ?t 03. 09. 2009 v 17:36 +0530: > Hello all, > > sorry to ask questions again and again. > I am new to rpm packaging. > > I am trying to create one RPM package for my daemon application in > Fedora 10. > > daemon application contains , > 1. daemon.c > 2. daemon.h > 3. list.c > 4.list.h > 5.makefile. > > So , I am just tar the daemon application as "daemon.tar.gz". > > I put this daemon.tar.gz in /home/user/rpmbuild/SOURCES directory. > > I am creating spec filr and put it in /home/user/rpmbuild/SPECS > directory. > > Now, I am trying to create binary RPM for my application. I am in > x86_64 architecture. > > when I run rpmbuild -bs daemon-1.spec and then rpmbuild -bb > daemon-1.spec > > only source rpm created. Binary RPM is not created. > > How to cretae binary RPM for my application. > If my spec file is wrong, please correct me. > I create .rpmmacros in my home director (/home/user/). > > > MY spec file is, > > [SPEC] > Summary: This Package install Daemon application > Name: daemon > Version:1 > Release:1 > License: GPL > Group: Applications/System > Source:daemon.tar.gz > BuildRoot: /home/nco_user/rpmbuild/tmp > > BuildArch:noarch ^^^^ drop this line, a package that is built from C sources can't be "noarch" > Packager:S.J.Ram > > %description > This Package install Daemon application > %prep > %setup -q > %build > make > > %install > rm -rf $RPM_BUILD_ROOT > make install > > %clean > rm -rf $RPM_BUILD_ROOT > > %files > %defattr(-,root,root,-) > %{_tmppath}/daemon > > [/SPEC] > > > please guide me to create binary rpm. > Do I need to change SPEC file?. > > If any one already did RPM package for their C or java application, > please give me the example (with one tar.gz file) > thank you. Dan From rdieter at math.unl.edu Thu Sep 3 14:59:04 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 03 Sep 2009 09:59:04 -0500 Subject: [Fedora-packaging] "Explicit requires" and "requiring base package" In-Reply-To: <200909022254.54003.ville.skytta@iki.fi> References: <200905021334.56366.ville.skytta@iki.fi> <200909022205.00396.ville.skytta@iki.fi> <4A9EC321.5030102@math.unl.edu> <200909022254.54003.ville.skytta@iki.fi> Message-ID: <4A9FD9B8.9000705@math.unl.edu> Ville Skytt? wrote: > On Wednesday 02 September 2009, Rex Dieter wrote: > >> rpm may have implicit dependencies on >> base pkgs (from -devel ones) but these often aren't enough to ensure >> things "just work". This falls under the "except when ... necessary" >> section of the Explict_Requires guideline, imo. > > That's fine, I don't have that strong opinions on it. > > But Explicit Requires also says "When explicit library Requires are necessary, > there should be a spec file comment justifying it." So in other words, > libfoo-devel's explicit dependency on libfoo would need such a comment. I > don't think that's the intent. This could be improved by saying > > "When explicit library Requires are necessary, there should be a spec file > comment justifying it, except in cases that fall under the Requiring Base > Package guideline." Shrug, that should go without saying, imo. Has there been confusion? -- Rex From j.w.r.degoede at hhs.nl Thu Sep 3 15:04:40 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 03 Sep 2009 17:04:40 +0200 Subject: [Fedora-packaging] Re: Re: Packaging a game, need help with setgid security In-Reply-To: References: <29fee02b0908310141k43d80fa4n269158b7cfcadc5c@mail.gmail.com> <4A9E2DB8.2070305@hhs.nl> Message-ID: <4A9FDB08.4010302@hhs.nl> Hi, On 09/02/2009 11:47 PM, Ryan Rix wrote: > Hans de Goede wrote: >> >> This is a known issue with roguelikes, we've solved this for the other >> roguelikes (see there spec files) by creating a group esp. for the game >> and making it sgid itsowngroup and never dropping the sgid rights. This >> way we strongly limit the amount of damage / attacks which can be done by >> not dropping sgid, this is the best security versus usability trade off we >> could come up with for rogue likes. >> >> Regards, >> >> Hans > > Looking at the specs for nethack, ularn and rogue > (cvs.fedoraproject.org/viewvc) shows that these are simply setgid games. I > did not look at the actual code to see how they handle setgid. > They don't handle being sgid in any special way, as said: "and never dropping the sgid rights", which is why they are given there own group to limit any potential fall out from privilege escalation bugs in their code. IOW no changes to their code were made to support the sgid running. Regards, Hans From giesen at snickers.org Thu Sep 3 15:39:28 2009 From: giesen at snickers.org (Gary T. Giesen) Date: Thu, 3 Sep 2009 11:39:28 -0400 Subject: [Fedora-packaging] RPM packaging for fedora 10 problem In-Reply-To: <1251979918.17881.3.camel@eagle.danny.cz> References: <1251979918.17881.3.camel@eagle.danny.cz> Message-ID: <9a9d0c6a0909030839n20b3603creb338b129ff678e5@mail.gmail.com> Also, if this is your own program, this should also include a LICENSE file with the text of the license for the program. GG On 9/3/09, Dan Hor?k wrote: > ram s p??e v ?t 03. 09. 2009 v 17:36 +0530: >> Hello all, >> >> sorry to ask questions again and again. >> I am new to rpm packaging. >> >> I am trying to create one RPM package for my daemon application in >> Fedora 10. >> >> daemon application contains , >> 1. daemon.c >> 2. daemon.h >> 3. list.c >> 4.list.h >> 5.makefile. >> >> So , I am just tar the daemon application as "daemon.tar.gz". >> >> I put this daemon.tar.gz in /home/user/rpmbuild/SOURCES directory. >> >> I am creating spec filr and put it in /home/user/rpmbuild/SPECS >> directory. >> >> Now, I am trying to create binary RPM for my application. I am in >> x86_64 architecture. >> >> when I run rpmbuild -bs daemon-1.spec and then rpmbuild -bb >> daemon-1.spec >> >> only source rpm created. Binary RPM is not created. >> >> How to cretae binary RPM for my application. >> If my spec file is wrong, please correct me. >> I create .rpmmacros in my home director (/home/user/). >> >> >> MY spec file is, >> >> [SPEC] >> Summary: This Package install Daemon application >> Name: daemon >> Version:1 >> Release:1 >> License: GPL >> Group: Applications/System >> Source:daemon.tar.gz >> BuildRoot: /home/nco_user/rpmbuild/tmp >> >> BuildArch:noarch > ^^^^ > drop this line, a package that is built from C sources can't be "noarch" > >> Packager:S.J.Ram >> >> %description >> This Package install Daemon application >> %prep >> %setup -q >> %build >> make >> >> %install >> rm -rf $RPM_BUILD_ROOT >> make install >> >> %clean >> rm -rf $RPM_BUILD_ROOT >> >> %files >> %defattr(-,root,root,-) >> %{_tmppath}/daemon >> >> [/SPEC] >> >> >> please guide me to create binary rpm. >> Do I need to change SPEC file?. >> >> If any one already did RPM package for their C or java application, >> please give me the example (with one tar.gz file) >> thank you. > > > Dan > > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > > From phrkonaleash at gmail.com Thu Sep 3 21:19:29 2009 From: phrkonaleash at gmail.com (Ryan Rix) Date: Thu, 03 Sep 2009 14:19:29 -0700 Subject: [Fedora-packaging] Re: Re: Re: Packaging a game, need help with setgid security References: <29fee02b0908310141k43d80fa4n269158b7cfcadc5c@mail.gmail.com> <4A9E2DB8.2070305@hhs.nl> <4A9FDB08.4010302@hhs.nl> Message-ID: Hans de Goede wrote: > which is why they are given there own group to limit any > potential fall out from privilege escalation bugs in their code. Im misinterpreted this statement then, sorry :) I understood it as each game ran in the context of group nethack, or group rogue, but not group games. I understand this now. This makes more sense and is currently how my spec is written, the game runs in the context of setgid games. Thanks -- Ryan Rix (623)-826-0051 Fortune: You can't have your cake and let your neighbor eat it too. -- Ayn Rand http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels. From j.w.r.degoede at hhs.nl Fri Sep 4 08:22:08 2009 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 04 Sep 2009 10:22:08 +0200 Subject: [Fedora-packaging] Re: Re: Re: Packaging a game, need help with setgid security In-Reply-To: References: <29fee02b0908310141k43d80fa4n269158b7cfcadc5c@mail.gmail.com> <4A9E2DB8.2070305@hhs.nl> <4A9FDB08.4010302@hhs.nl> Message-ID: <4AA0CE30.4030806@hhs.nl> On 09/03/2009 11:19 PM, Ryan Rix wrote: > Hans de Goede wrote: > >> which is why they are given there own group to limit any >> potential fall out from privilege escalation bugs in their code. > > Im misinterpreted this statement then, sorry :) I understood it as each game > ran in the context of group nethack, or group rogue, but not group games. I > understand this now. This makes more sense and is currently how my spec is > written, the game runs in the context of setgid games. > Ok, Once you submit the package for review, can you send me the url or bugnr of the review request, then I'll take a look to make sure the sgid handling is ok. Regards, Hans From phrkonaleash at gmail.com Fri Sep 4 08:50:10 2009 From: phrkonaleash at gmail.com (Ryan Rix) Date: Fri, 04 Sep 2009 01:50:10 -0700 Subject: [Fedora-packaging] Re: Re: Re: Re: Packaging a game, need help with setgid security References: <29fee02b0908310141k43d80fa4n269158b7cfcadc5c@mail.gmail.com> <4A9E2DB8.2070305@hhs.nl> <4A9FDB08.4010302@hhs.nl> <4AA0CE30.4030806@hhs.nl> Message-ID: Hans de Goede wrote: > Ok, > > Once you submit the package for review, can you send me the url or bugnr > of the review request, then I'll take a look to make sure the sgid > handling is ok. Hi Hans, Thanks for offering to take a look: https://bugzilla.redhat.com/show_bug.cgi?id=520550 -- Ryan Rix (623)-826-0051 Fortune: I feel like I'm in a Toilet Bowl with a thumbtack in my forehead!! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonaleash at gmail.com | MSN: phrkonaleash at yahoo.com AIM: phrkonaleash | Yahoo: phrkonaleash IRC: PhrkOnLsh at irc.freenode.net/#srcedit,#teensonlinux,#plugaz and countless other FOSS channels. From ramforummail at gmail.com Sun Sep 6 09:32:13 2009 From: ramforummail at gmail.com (ram s) Date: Sun, 6 Sep 2009 15:02:13 +0530 Subject: [Fedora-packaging] How to run own shell script from rpm spec Message-ID: Hi, I am creating on example.sh in my source folder and tar it and put it in /home/user/rpmbuild/SOURCES directory. In that example.sh, I am creating one directory in my tmp folder. But, when I run the spec file, it not execute the shell script and run the command. I am using %pre section to run that shell script. My spec file is, ****************************************************************** Summary: This Package install example daemon application Name: example Version:1 Release:5 License: CC-GNU GPL version 2.0 Group: Applications/System Source:example-1.tar.gz BuildRoot:%{_tmppath}/%{name}-root Requires: python = 2.2.3 Requires: gcc Requires(post): /bin/sh BuildRequires: libpcap BuildRequires: gawk BuildArch:x86_64 Packager:S.Jayaram %description This Package install CDaemon application %prep %setup -q %build %{__make} %pre sh example.sh sh javacheck.sh %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/%{_tmppath} install -m755 example $RPM_BUILD_ROOT%{_tmppath}/example %makeinstall %files %defattr(-,root,root,-) #%dir /home/nco_user/rpmbuild/SOURCES/example-1 %{_bindir}/* %clean %{__rm} -rf %{buildroot} *************************************************************** My script is, #!/bin/sh mkdir /home/nco_user/rpmbuild/tmp/CDaemon I am not able to run the script and create the folder. When I run rpmbuild , it run properly and create the binary. But when I installed it shows following error, [error] Preparing... ########################################### [100%] sh: example.sh: No such file or directory sh: javacheck.sh: No such file or directory error: %pre(example-1-5.x86_64) scriptlet failed, exit status 127 error: install: %pre scriptlet failed (2), skipping example-1-5 //////////////////////////////////////////////////// what is my problem. I put my shell scripts in /home/user/rpmbuild/SOURCES/example-1/ directory and finally tar it. where can i call my own custom shell scripts. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jussilehtola at fedoraproject.org Sun Sep 6 10:01:05 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Sun, 06 Sep 2009 13:01:05 +0300 Subject: [Fedora-packaging] How to run own shell script from rpm spec In-Reply-To: References: Message-ID: <1252231265.2534.5.camel@localhost.localdomain> On Sun, 2009-09-06 at 15:02 +0530, ram s wrote: > Hi, > > I am creating on example.sh in my source folder and tar it and put it > in /home/user/rpmbuild/SOURCES directory. This is off-topic for this list. Ask at fedora-devel-list at redhat.com instead. (The reason why it fails is because example.sh and javacheck.sh are not included in the RPM. Install them somewhere and include them in %files, then you are able to run them in %post. They won't be available anyway in %pre for new installs.) -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From tcallawa at redhat.com Tue Sep 8 22:09:16 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 08 Sep 2009 18:09:16 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting on Wednesday, September 8, 2009 (1600 UTC) Message-ID: <4AA6D60C.8010104@redhat.com> Sorry for the late notice, but I'd like to have an FPC meeting tomorrow, usual time and place (#fedora-meeting). Here's a rough agenda for the next meeting: * Use the Better Source: https://fedoraproject.org/wiki/PackagingDrafts/Use_Better_Source * Move SIGs/Games/Packaging to Packaging/Games: https://fedoraproject.org/w/index.php?title=SIGs/Games/Packaging * Common Voice Data (update of SystemVoiceData): https://fedoraproject.org/wiki/PackagingDrafts/CommonVoiceData Thanks in advance, ~spot From tcallawa at redhat.com Tue Sep 8 22:15:05 2009 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 08 Sep 2009 18:15:05 -0400 Subject: [Fedora-packaging] Fedora Packaging Committee Meeting on Wednesday, September 9, 2009 (1600 UTC) In-Reply-To: <4AA6D60C.8010104@redhat.com> References: <4AA6D60C.8010104@redhat.com> Message-ID: <4AA6D769.6080505@redhat.com> On 09/08/2009 06:09 PM, Tom "spot" Callaway wrote: > Sorry for the late notice, but I'd like to have an FPC meeting tomorrow, > usual time and place (#fedora-meeting). Tomorrow is September 9th. Not the 8th. *sigh* It is time for me to go home now. :/ ~spot From ramforummail at gmail.com Wed Sep 9 10:32:18 2009 From: ramforummail at gmail.com (ram s) Date: Wed, 9 Sep 2009 16:02:18 +0530 Subject: [Fedora-packaging] rpm build problem Message-ID: hi, i am creating rpm packaging. i got the following problem Processing files:troapplication-1.0.0-1 Processing files: troapplication-debuginfo-1.0.0-1 error: Could not open %files file /home/user/rpmbuild/BUILD/troapplication-1.0.0/debugfiles.list: No such file or directory RPM build errors: Could not open %files file /home/nco_user/rpmbuild/BUILD/NCOVMSOFTS-1.0.0/debugfiles.list: No such file or directory I created same package before and built it properly and create rpm biunary and can able to install. Any idea. thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rakesh.pandit at gmail.com Wed Sep 9 10:45:35 2009 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Wed, 9 Sep 2009 16:15:35 +0530 Subject: [Fedora-packaging] rpm build problem In-Reply-To: References: Message-ID: 2009/9/9 ram s wrote: > hi, > > i am creating rpm packaging. > > > i got the following problem > > Processing files:troapplication-1.0.0-1 > Processing files: troapplication-debuginfo-1.0.0-1 > error: Could not open %files file > /home/user/rpmbuild/BUILD/troapplication-1.0.0/debugfiles.list: No such file > or directory > > > RPM build errors: > ??? Could not open %files file > /home/nco_user/rpmbuild/BUILD/NCOVMSOFTS-1.0.0/debugfiles.list: No such file > or directory > Uploading your source and spec (at least) some place and providing link to it would provide more insight. What system you are running ? Which rpm ? This is not suitable place to discuss it. fedora-devel would make more sense. -- Rakesh Pandit https://fedoraproject.org/ freedom, friends, features, first From shakthimaan at gmail.com Wed Sep 9 15:51:41 2009 From: shakthimaan at gmail.com (Shakthi Kannan) Date: Wed, 9 Sep 2009 21:21:41 +0530 Subject: [Fedora-packaging] Processing Review Requests Message-ID: Hi, I would like to know: 1. If there is a comprehensive contact list of Fedora Packagers who are allowed to sponsor packages? Is the list available somewhere that new joinees can use, and contact Fedora packagers? or is it always that whenever a Sponsor looks into FE-NEEDSPONSOR review requests in bugzilla, the package is reviewed? 2. Is there a queue of review requests that is maintained, say, for example a review-request that has not been reviewed for a month, should be given first priority or is there any criteria as such? or is it left to the Packagers? 3. If there is a SIG, and exists a group of Packagers who can sponsor a package within the SIG, how do they coordinate as to which packages need to be reviewed first, or in what order? Appreciate any inputs in this regard, Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com From tibbs at math.uh.edu Wed Sep 9 16:10:27 2009 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 09 Sep 2009 11:10:27 -0500 Subject: [Fedora-packaging] Processing Review Requests In-Reply-To: (Shakthi Kannan's message of "Wed, 9 Sep 2009 21:21:41 +0530") References: Message-ID: >>>>> "SK" == Shakthi Kannan writes: SK> 1. If there is a comprehensive contact list of Fedora Packagers who SK> are allowed to sponsor packages? The account system knows. Just look for the "packager" group, type "sponsor". SK> Is there a queue of review requests that is maintained, say, for SK> example a review-request that has not been reviewed for a month, SK> should be given first priority or is there any criteria as such? or SK> is it left to the Packagers? There's no policy for giving priority. The review queue is at http://fedoraproject.org/PackageReviewStatus/NEW.html SK> 3. If there is a SIG, and exists a group of Packagers who can SK> sponsor a package within the SIG, how do they coordinate as to which SK> packages need to be reviewed first, or in what order? I would suppose they would communicate with each other in some fashion. That kind of thing isn't going to be regulated by any policy. - J< From jussilehtola at fedoraproject.org Wed Sep 9 16:16:11 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 09 Sep 2009 19:16:11 +0300 Subject: [Fedora-packaging] Processing Review Requests In-Reply-To: References: Message-ID: <1252512971.22116.5.camel@politzer.theorphys.helsinki.fi> On Wed, 2009-09-09 at 21:21 +0530, Shakthi Kannan wrote: > Hi, > > I would like to know: This message is off-topic to this list. Redirecting discussion to fedora-devel-list at redhat.com. > 1. If there is a comprehensive contact list of Fedora Packagers who > are allowed to sponsor packages? Is the list available somewhere that > new joinees can use, and contact Fedora packagers? or is it always > that whenever a Sponsor looks into FE-NEEDSPONSOR review requests in > bugzilla, the package is reviewed? Yes, you can look in FAS who have sponsor status in the Packager group. Normally sponsors look for review requests needing sponsors, but if you've been waiting for very long you can mail fedora-devel-list and ask for someone to have a look at your package. > 2. Is there a queue of review requests that is maintained, say, for > example a review-request that has not been reviewed for a month, > should be given first priority or is there any criteria as such? or is > it left to the Packagers? Not especially, but the review bugs have bug numbers that are in increasing order in time, so older reviews have smaller numbers. Picking what to review is up to the packager. -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From jonstanley at gmail.com Wed Sep 9 16:19:30 2009 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 9 Sep 2009 12:19:30 -0400 Subject: [Fedora-packaging] Processing Review Requests In-Reply-To: References: Message-ID: On Wed, Sep 9, 2009 at 11:51 AM, Shakthi Kannan wrote: > 1. If there is a comprehensive contact list of Fedora Packagers who > are allowed to sponsor packages? Is the list available somewhere that > new joinees can use, and contact Fedora packagers? or is it always > that whenever a Sponsor looks into FE-NEEDSPONSOR review requests in > bugzilla, the package is reviewed? Any member of the packager group may review a package for an existing packager. They also may (and are encouraged to) do informal reviews of packages from non-sponsored packagers. The list of existing sponsors may be found at https://admin.fedoraproject.org/accounts/group/members/packager/*/sponsor > 2. Is there a queue of review requests that is maintained, say, for > example a review-request that has not been reviewed for a month, > should be given first priority or is there any criteria as such? or is > it left to the Packagers? Besides the normal bugzilla search? I don't think there's such a queue. There's a report that comes out every so often on package review stats, but no queue as such. > 3. If there is a SIG, and exists a group of Packagers who can sponsor > a package within the SIG, how do they coordinate as to which packages > need to be reviewed first, or in what order? They do this within their own control - maybe on their mailing list, maybe on a wiki page, etc. There is no "one way" that a SIG has to operate. From ville.skytta at iki.fi Wed Sep 9 18:35:37 2009 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 9 Sep 2009 21:35:37 +0300 Subject: [Fedora-packaging] "Explicit requires" and "requiring base package" In-Reply-To: <4A9FD9B8.9000705@math.unl.edu> References: <200905021334.56366.ville.skytta@iki.fi> <200909022254.54003.ville.skytta@iki.fi> <4A9FD9B8.9000705@math.unl.edu> Message-ID: <200909092135.37704.ville.skytta@iki.fi> On Thursday 03 September 2009, Rex Dieter wrote: > Ville Skytt? wrote: > > On Wednesday 02 September 2009, Rex Dieter wrote: > >> rpm may have implicit dependencies on > >> base pkgs (from -devel ones) but these often aren't enough to ensure > >> things "just work". This falls under the "except when ... necessary" > >> section of the Explict_Requires guideline, imo. > > > > That's fine, I don't have that strong opinions on it. > > > > But Explicit Requires also says "When explicit library Requires are > > necessary, there should be a spec file comment justifying it." So in > > other words, libfoo-devel's explicit dependency on libfoo would need such > > a comment. I don't think that's the intent. This could be improved by > > saying > > > > "When explicit library Requires are necessary, there should be a spec > > file comment justifying it, except in cases that fall under the Requiring > > Base Package guideline." > > Shrug, that should go without saying, imo. Has there been confusion? I find the two guidelines' wording to be at least partially in conflict, and cross referencing like in above would clarify things. I'm an old fart here so I know how to interpret them, but I'd be surprised if it didn't confuse newcomers. From a.badger at gmail.com Tue Sep 15 15:41:43 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 15 Sep 2009 08:41:43 -0700 Subject: [Fedora-packaging] Re: Common Voicedata Packaging Guidelines In-Reply-To: <1252568643.24243.25.camel@localhost.localdomain> References: <4AA7EFA6.2080809@gmail.com> <1252568643.24243.25.camel@localhost.localdomain> Message-ID: <4AAFB5B7.4020006@gmail.com> CC'ing fedora-packaging since there's no need for us to just talk about these things between ourselves. On 09/10/2009 12:44 AM, Ding-Yi Chen wrote: > ? ??2009-09-09 ? 11:10 -0700?Toshio Kuratomi ??? >> Greetings, >> >> I'm one of the other members of the Fedora Packaging Committee and we >> had some more questions about CommonVoiceData: >> >> https://fedoraproject.org/wiki/PackagingDrafts/CommonVoiceData >> >> 1) Who uses the data? (answered: just gcin) >> 2) Who uses the db? >> 3) Do we need a standard for this or is it just going to be used by > gcin? > > If that data is only for gcin, I would have just contacted gcin's > maintainer and include it as a sub-package of gcin. > > I do plan use the voice data with ibus and couple of others. > I also plan to pack other voice data, such as : > 1. Ekho http://e-guidedog.sourceforge.net/ekho.php > 2. http://espeak.sourceforge.net/ > > Hmm, do you mean that there must be sufficient amount of relative > packages to push this proposal? I can pack those voice-data, if that is > mandatory. > There does not need to be a large amount of voice data packages. I'm mainly wondering what is happening with the db. If there are several packages that use the db, then it seems like there needs to be some coordination among those projects to do so. >> 4) If a standard, who would be best to make a standard for this stuff? >> 4b) If no idea, do you think freedesktop would be a common meeting >> ground for the participants? > > I haven't though that way. I would gladly move the issue to freedeskop > if discussing there is more appreciate. > It may be. Usually the Fedora Guidelines are written to tell packagers how to deal with a standard that originated elsewhere (FHS, .desktop file handling, etc). If we're just talking about where on the filesystem the data files shold be placed and how the packages should be named, then Fedora Guidelines can cover it immediately (via the FHS and package naming being a distro-specific standard). It's the usage of the database that seems a bit odd to be originating in Fedora rather than some distro-agnostic, upstream location. >> 5) If not a standard, what does gcin do with this db? > It is merely an example usage for the voice data. > So -- what's the plan for using the db? >> Implementation >> 1) What package owns the db on the filesystem? > Actually the package: voicedata owns the db. > The packing voicedata is in on the way. > Okay. So the packages that contain voicedata need to Require(XXX): voicedata where XXX are the scriptlets that update the db. >> 2) Scriptlets need to account for upgrade/removal/install -- See >> https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Syntax >> >> https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Scriptlet_Ordering > > Thanks for pointing out the "upgrade" requirement. I think I covered > install/uninstall script in the sample spec file. > >> 3) What's this db created during the %build? We noticed that there's >> sqlite3 commands in %build but the db created there isn't installed. >> -Toshio >> > > Thanks for telling me this. > I will fix the proposal and spec if you think the common voicedata idea > still belong to fedora packaging guideline. No problem. We'll definitely want something written up in the Guidelines. I'm just not sure yet what the purpose of all the parts in the draft is and whether there needs to be cross-distro, cross-upstream-project consensus to make these effective. -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 braden at endoframe.com Tue Sep 15 22:11:40 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 15 Sep 2009 18:11:40 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific Message-ID: <1253052700.17997.4784.camel@localhost> Since apparently a requirement for "foo" can be satisfied by any available architecture for which a "foo" is available, "Requires" that do not specify the architecture are unsafe for multilib systems (unless the dependency really can be satisfied by any architecture--which does not strike me as the most common case). I think this bears mentioning in https://fedoraproject.org/wiki/Packaging/Guidelines#Explicit_Requires And I think the example there needs to add the architecture to be correct. -- Braden McDaniel From tgl at redhat.com Tue Sep 15 23:12:15 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 15 Sep 2009 19:12:15 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <1253052700.17997.4784.camel@localhost> References: <1253052700.17997.4784.camel@localhost> Message-ID: <25148.1253056335@sss.pgh.pa.us> Braden McDaniel writes: > Since apparently a requirement for "foo" can be satisfied by any > available architecture for which a "foo" is available, "Requires" that > do not specify the architecture are unsafe for multilib systems (unless > the dependency really can be satisfied by any architecture--which does > not strike me as the most common case). Surely this is a bug, not something that every single specfile must work around. regards, tom lane From braden at endoframe.com Tue Sep 15 23:38:56 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 15 Sep 2009 19:38:56 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <25148.1253056335@sss.pgh.pa.us> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> Message-ID: <1253057936.17997.4960.camel@localhost> On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: > Braden McDaniel writes: > > Since apparently a requirement for "foo" can be satisfied by any > > available architecture for which a "foo" is available, "Requires" that > > do not specify the architecture are unsafe for multilib systems (unless > > the dependency really can be satisfied by any architecture--which does > > not strike me as the most common case). > > Surely this is a bug, not something that every single specfile must > work around. If it's a bug, then how do you propose a specfile should articulate a "Requires" that *can* be satisfied by any architecture? Or maybe I'm misunderstanding what you think the bug is...? -- Braden McDaniel From tgl at redhat.com Wed Sep 16 01:39:23 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 15 Sep 2009 21:39:23 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <1253057936.17997.4960.camel@localhost> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253057936.17997.4960.camel@localhost> Message-ID: <26531.1253065163@sss.pgh.pa.us> Braden McDaniel writes: > On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: >> Surely this is a bug, not something that every single specfile must >> work around. > If it's a bug, then how do you propose a specfile should articulate a > "Requires" that *can* be satisfied by any architecture? Why would it need to? I should only have to require "foo", I should not have to know whether foo comes in arch-specific or arch-independent form. It should be up to the buildsystem to acquire the version that is most appropriate for the target arch being built. regards, tom lane From braden at endoframe.com Wed Sep 16 02:15:30 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 15 Sep 2009 22:15:30 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <26531.1253065163@sss.pgh.pa.us> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253057936.17997.4960.camel@localhost> <26531.1253065163@sss.pgh.pa.us> Message-ID: <1253067330.17997.5283.camel@localhost> On Tue, 2009-09-15 at 21:39 -0400, Tom Lane wrote: > Braden McDaniel writes: > > On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: > >> Surely this is a bug, not something that every single specfile must > >> work around. > > > If it's a bug, then how do you propose a specfile should articulate a > > "Requires" that *can* be satisfied by any architecture? > > Why would it need to? Because there's no reason to specify the architecture if it truly doesn't matter. For instance, if my package runs an executable, I probably don't care whether the executable was built for i686 or x86_64. On the other hand, if my package dlopen's a library, I probably do care. > I should only have to require "foo", I should > not have to know whether foo comes in arch-specific or arch-independent > form. It will always *come* in an arch-specific form--which is why it's important to specify the right one when it matters. > It should be up to the buildsystem to acquire the version that > is most appropriate for the target arch being built. If you're using "Requires", the build system is most likely irrelevant. "Requires" tends to be for things that are resolved at run time. -- Braden McDaniel From jcm at redhat.com Wed Sep 16 02:29:12 2009 From: jcm at redhat.com (Jon Masters) Date: Tue, 15 Sep 2009 22:29:12 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <25148.1253056335@sss.pgh.pa.us> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> Message-ID: <1253068152.6098.29.camel@localhost.localdomain> On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: > Braden McDaniel writes: > > Since apparently a requirement for "foo" can be satisfied by any > > available architecture for which a "foo" is available, "Requires" that > > do not specify the architecture are unsafe for multilib systems (unless > > the dependency really can be satisfied by any architecture--which does > > not strike me as the most common case). > > Surely this is a bug, not something that every single specfile must > work around. Well, if it's a bug then the entire multilib approach is a bug ;) Jon. From tgl at redhat.com Wed Sep 16 02:32:37 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 15 Sep 2009 22:32:37 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <1253067330.17997.5283.camel@localhost> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253057936.17997.4960.camel@localhost> <26531.1253065163@sss.pgh.pa.us> <1253067330.17997.5283.camel@localhost> Message-ID: <27248.1253068357@sss.pgh.pa.us> Braden McDaniel writes: > On Tue, 2009-09-15 at 21:39 -0400, Tom Lane wrote: >> Braden McDaniel writes: >>> If it's a bug, then how do you propose a specfile should articulate a >>> "Requires" that *can* be satisfied by any architecture? >> >> Why would it need to? > Because there's no reason to specify the architecture if it truly > doesn't matter. Indeed. > For instance, if my package runs an executable, I > probably don't care whether the executable was built for i686 or x86_64. > On the other hand, if my package dlopen's a library, I probably do care. Well, for separate executables you shouldn't have to care. For ordinary library bindings, the appropriate require is generated by RPM and the packager need not worry about it. I concede that dlopen'd libraries might need arch-specific Requires, but that's hardly such a common case as to motivate a recommendation that Requires should "usually" be arch-specific. regards, tom lane From tgl at redhat.com Wed Sep 16 02:39:14 2009 From: tgl at redhat.com (Tom Lane) Date: Tue, 15 Sep 2009 22:39:14 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <1253068152.6098.29.camel@localhost.localdomain> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253068152.6098.29.camel@localhost.localdomain> Message-ID: <27332.1253068754@sss.pgh.pa.us> Jon Masters writes: > On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: >> Surely this is a bug, not something that every single specfile must >> work around. > Well, if it's a bug then the entire multilib approach is a bug ;) I think that's widely agreed ;-). Multilib is a crock that is meant to sort of work for some common cases. The cases that Braden seems to be worried about, like version skew between different installed arches of the same package, are not something multilib was ever expected to be able to handle gracefully. regards, tom lane From skvidal at fedoraproject.org Wed Sep 16 02:42:45 2009 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 15 Sep 2009 22:42:45 -0400 (EDT) Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <27332.1253068754@sss.pgh.pa.us> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253068152.6098.29.camel@localhost.localdomain> <27332.1253068754@sss.pgh.pa.us> Message-ID: On Tue, 15 Sep 2009, Tom Lane wrote: > Jon Masters writes: >> On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: >>> Surely this is a bug, not something that every single specfile must >>> work around. > >> Well, if it's a bug then the entire multilib approach is a bug ;) > > I think that's widely agreed ;-). Multilib is a crock that is meant > to sort of work for some common cases. The cases that Braden seems > to be worried about, like version skew between different installed > arches of the same package, are not something multilib was ever > expected to be able to handle gracefully. > and yet just the other day I was hit up about making sure we install both versions (i386 and x86_64) of a set of libraries on any install for a customer using a fedora-derived distribution. -sv From braden at endoframe.com Wed Sep 16 03:36:16 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 15 Sep 2009 23:36:16 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <27248.1253068357@sss.pgh.pa.us> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253057936.17997.4960.camel@localhost> <26531.1253065163@sss.pgh.pa.us> <1253067330.17997.5283.camel@localhost> <27248.1253068357@sss.pgh.pa.us> Message-ID: <1253072176.17997.5470.camel@localhost> On Tue, 2009-09-15 at 22:32 -0400, Tom Lane wrote: > Braden McDaniel writes: > > On Tue, 2009-09-15 at 21:39 -0400, Tom Lane wrote: > >> Braden McDaniel writes: > >>> If it's a bug, then how do you propose a specfile should articulate a > >>> "Requires" that *can* be satisfied by any architecture? > >> > >> Why would it need to? > > > Because there's no reason to specify the architecture if it truly > > doesn't matter. > > Indeed. > > > For instance, if my package runs an executable, I > > probably don't care whether the executable was built for i686 or x86_64. > > On the other hand, if my package dlopen's a library, I probably do care. > > Well, for separate executables you shouldn't have to care. For ordinary > library bindings, the appropriate require is generated by RPM and the > packager need not worry about it. I concede that dlopen'd libraries > might need arch-specific Requires, but that's hardly such a common case > as to motivate a recommendation that Requires should "usually" be > arch-specific. It's a sufficiently common case that the packaging guidelines use it as an example for explicit Requires. Is there a more common case for explicit Requires (used by non-noarch packages) that I'm overlooking? -- Braden McDaniel From braden at endoframe.com Wed Sep 16 03:39:39 2009 From: braden at endoframe.com (Braden McDaniel) Date: Tue, 15 Sep 2009 23:39:39 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <27332.1253068754@sss.pgh.pa.us> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253068152.6098.29.camel@localhost.localdomain> <27332.1253068754@sss.pgh.pa.us> Message-ID: <1253072379.17997.5482.camel@localhost> On Tue, 2009-09-15 at 22:39 -0400, Tom Lane wrote: > Jon Masters writes: > > On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: > >> Surely this is a bug, not something that every single specfile must > >> work around. > > > Well, if it's a bug then the entire multilib approach is a bug ;) > > I think that's widely agreed ;-). Multilib is a crock that is meant > to sort of work for some common cases. The cases that Braden seems > to be worried about, like version skew between different installed > arches of the same package, are not something multilib was ever > expected to be able to handle gracefully. Actually, what I'm worried about is, "yum pulls in a bunch of i686 packages as dependencies that won't work when (for some reason) it can't find the x86_64 ones that it really needs". I don't think that's acceptable behavior. -- Braden McDaniel From braden at endoframe.com Wed Sep 16 07:07:48 2009 From: braden at endoframe.com (Braden McDaniel) Date: Wed, 16 Sep 2009 03:07:48 -0400 Subject: [Fedora-packaging] Explicit "Requires" should (usually) be arch-specific In-Reply-To: <1253072176.17997.5470.camel@localhost> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253057936.17997.4960.camel@localhost> <26531.1253065163@sss.pgh.pa.us> <1253067330.17997.5283.camel@localhost> <27248.1253068357@sss.pgh.pa.us> <1253072176.17997.5470.camel@localhost> Message-ID: <1253084868.32162.232.camel@localhost> On Tue, 2009-09-15 at 23:36 -0400, Braden McDaniel wrote: > On Tue, 2009-09-15 at 22:32 -0400, Tom Lane wrote: > > Braden McDaniel writes: > > > On Tue, 2009-09-15 at 21:39 -0400, Tom Lane wrote: > > >> Braden McDaniel writes: > > >>> If it's a bug, then how do you propose a specfile should articulate a > > >>> "Requires" that *can* be satisfied by any architecture? > > >> > > >> Why would it need to? > > > > > Because there's no reason to specify the architecture if it truly > > > doesn't matter. > > > > Indeed. > > > > > For instance, if my package runs an executable, I > > > probably don't care whether the executable was built for i686 or x86_64. > > > On the other hand, if my package dlopen's a library, I probably do care. > > > > Well, for separate executables you shouldn't have to care. For ordinary > > library bindings, the appropriate require is generated by RPM and the > > packager need not worry about it. I concede that dlopen'd libraries > > might need arch-specific Requires, but that's hardly such a common case > > as to motivate a recommendation that Requires should "usually" be > > arch-specific. > > It's a sufficiently common case that the packaging guidelines use it as > an example for explicit Requires. > > Is there a more common case for explicit Requires (used by non-noarch > packages) that I'm overlooking? ... And dlopen'd libraries aren't the only cases that merit an arch-specific Require. So do Requires for -devel packages. And a subpackage's Require for its main package should be arch-specific, too. -- Braden McDaniel From steve at lonetwin.net Wed Sep 16 07:33:22 2009 From: steve at lonetwin.net (steve) Date: Wed, 16 Sep 2009 13:03:22 +0530 Subject: [Fedora-packaging] What does one do when a package maintainer is unresponsive ? Message-ID: <4AB094C2.4030403@lonetwin.net> Hi, What is the course of action to be followed if a package maintainer appears to be unresponsive ? Specifically, I speak of the usb_modeswitch package, for which there has been an update-to-latest-upstream request pending for sometime now ... https://bugzilla.redhat.com/buglist.cgi?component=usb_modeswitch&product=Fedora In the BZ that I submitted[1], I even offered to co-maintain or take over ownership of this package in case the package maintainer is hard pressed for time, without receiving any response. I would like to see this bz fixed before I can start pester^Whelping out on BZ 515412 [2], which is causing me a lot of inconvenience. cheers, - steve [1] https://bugzilla.redhat.com/show_bug.cgi?id=519332 [2] https://bugzilla.redhat.com/show_bug.cgi?id=515412 -- random non tech spiel: http://lonetwin.blogspot.com/ tech randomness: http://lonehacks.blogspot.com/ what i'm stumbling into: http://lonetwin.stumbleupon.com/ From pingou at pingoured.fr Wed Sep 16 07:45:12 2009 From: pingou at pingoured.fr (Pierre-Yves) Date: Wed, 16 Sep 2009 09:45:12 +0200 Subject: [Fedora-packaging] What does one do when a package maintainer is unresponsive ? In-Reply-To: <4AB094C2.4030403@lonetwin.net> References: <4AB094C2.4030403@lonetwin.net> Message-ID: <1253087112.8884.0.camel@pingoured.dyndns.org> On Wed, 2009-09-16 at 13:03 +0530, steve wrote: > Hi, > > What is the course of action to be followed if a package maintainer appears to > be unresponsive ? The general guidelines are described there: http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers Best regards, Pierre From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 16 08:04:23 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 16 Sep 2009 10:04:23 +0200 Subject: [Fedora-packaging] Re: Explicit "Requires" should (usually) be arch-specific In-Reply-To: <26531.1253065163@sss.pgh.pa.us> (Tom Lane's message of "Tue, 15 Sep 2009 21:39:23 -0400") References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253057936.17997.4960.camel@localhost> <26531.1253065163@sss.pgh.pa.us> Message-ID: <871vm7l3i0.fsf@sheridan.bigo.ensc.de> Tom Lane writes: >> If it's a bug, then how do you propose a specfile should articulate a >> "Requires" that *can* be satisfied by any architecture? > > Why would it need to? dietlibc needs this. There are the arch specific libs in -devel and the common 'diet' program in 'dietlibc'. E.g. 'dietlibc-devel' for x86_64 and i386 can be used both with 'dietlibc' for x86_64 and for i386. Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Sep 16 08:06:42 2009 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 16 Sep 2009 10:06:42 +0200 Subject: [Fedora-packaging] Re: Explicit "Requires" should (usually) be arch-specific In-Reply-To: <1253057936.17997.4960.camel@localhost> (Braden McDaniel's message of "Tue, 15 Sep 2009 19:38:56 -0400") References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253057936.17997.4960.camel@localhost> Message-ID: <87ws3zjotp.fsf@sheridan.bigo.ensc.de> Braden McDaniel writes: > On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: >> Braden McDaniel writes: >> > Since apparently a requirement for "foo" can be satisfied by any >> > available architecture for which a "foo" is available, "Requires" that >> > do not specify the architecture are unsafe for multilib systems (unless >> > the dependency really can be satisfied by any architecture--which does >> > not strike me as the most common case). >> >> Surely this is a bug, not something that every single specfile must >> work around. > > If it's a bug, then how do you propose a specfile should articulate a > "Requires" that *can* be satisfied by any architecture? Can be solved with virtual provides (which should not be tied to an architecture): | Provides: program(%name) = %version-%release | | %package devel | Requires: program(%name) = %version-%release Enrico From steve at lonetwin.net Wed Sep 16 08:18:43 2009 From: steve at lonetwin.net (steve) Date: Wed, 16 Sep 2009 13:48:43 +0530 Subject: [Fedora-packaging] What does one do when a package maintainer is unresponsive ? In-Reply-To: <1253087112.8884.0.camel@pingoured.dyndns.org> References: <4AB094C2.4030403@lonetwin.net> <1253087112.8884.0.camel@pingoured.dyndns.org> Message-ID: <4AB09F63.9070305@lonetwin.net> On 09/16/2009 01:15 PM, Pierre-Yves wrote: > On Wed, 2009-09-16 at 13:03 +0530, steve wrote: >> Hi, >> >> What is the course of action to be followed if a package maintainer appears to >> be unresponsive ? > > The general guidelines are described there: > http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers Thanks Pierre ! cheers, - steve -- random non tech spiel: http://lonetwin.blogspot.com/ tech randomness: http://lonehacks.blogspot.com/ what i'm stumbling into: http://lonetwin.stumbleupon.com/ From jussilehtola at fedoraproject.org Wed Sep 16 18:52:04 2009 From: jussilehtola at fedoraproject.org (Jussi Lehtola) Date: Wed, 16 Sep 2009 21:52:04 +0300 Subject: [Fedora-packaging] EPEL + Fortran guideline Message-ID: <1253127124.2553.1.camel@localhost.localdomain> Hi, it just occurred to me that there is no %{_fmoddir} in EPEL. What should we do about that? Define the %{_fmoddir} macro in every package that needs it, make some wrapper package or what? -- Jussi Lehtola Fedora Project Contributor jussilehtola at fedoraproject.org From opensource at till.name Wed Sep 16 20:04:16 2009 From: opensource at till.name (Till Maas) Date: Wed, 16 Sep 2009 22:04:16 +0200 Subject: [Fedora-packaging] cleanup RPM Tags in Packaging Guidelines Message-ID: <20090916200416.GA23876@genius.kawo2.rwth-aachen.de> Hiyas, currently the RPM Tags section in the Packaging Guidelines[0] contains a blacklist of some RPM Tags: * Packager * Vendor * Copyright * PreReq Except for the Copyright tag, they all should not be used. I want to propose to change this to to a whitelist of RPM Tags that are allowed to be used and mention only explanations about their substitutions or reasons why they must not be used in the Guidelines. As the previous sentence implicates, I also want to change it to forbid these tags completely (must not) or there should be some information added, when it is ok to use them in Fedora. E.g. when is it ok to use PreReq or Packager in the Spec? The guidelines do not answer this question, therefore it would be easier to just forbid these tags for easier understanding of the guidelines. If there is a reason to use these tags in the future, the guidelines can be adapted anyways. The reason why I spotted this, is because a spec posted for review does contain a tag called "Distribution" and the Guidelines do not provide any guidance about how to proceed. I assume that it must not be used either. Regards Till [0] https://fedoraproject.org/wiki/Packaging/Guidelines#Tags -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From limb at jcomserv.net Wed Sep 16 20:10:23 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 16 Sep 2009 15:10:23 -0500 Subject: [Fedora-packaging] cleanup RPM Tags in Packaging Guidelines In-Reply-To: <20090916200416.GA23876@genius.kawo2.rwth-aachen.de> References: <20090916200416.GA23876@genius.kawo2.rwth-aachen.de> Message-ID: <4AB1462F.6090800@jcomserv.net> Till Maas wrote: > Hiyas, > > currently the RPM Tags section in the Packaging Guidelines[0] contains a > blacklist of some RPM Tags: > > * Packager > * Vendor > * Copyright > * PreReq > > Except for the Copyright tag, they all should not be used. I want to > propose to change this to to a whitelist of RPM Tags that are allowed to > be used and mention only explanations about their substitutions or > reasons why they must not be used in the Guidelines. As the previous > sentence implicates, I also want to change it to forbid these tags > completely (must not) or there should be some information added, when it > is ok to use them in Fedora. E.g. when is it ok to use PreReq or > Packager in the Spec? The guidelines do not answer this question, > therefore it would be easier to just forbid these tags for easier > understanding of the guidelines. If there is a reason to use these tags > in the future, the guidelines can be adapted anyways. > > The reason why I spotted this, is because a spec posted for review does > contain a tag called "Distribution" and the Guidelines do not provide > any guidance about how to proceed. I assume that it must not be used > either. > > Regards > Till > > [0] https://fedoraproject.org/wiki/Packaging/Guidelines#Tags > > ------------------------------------------------------------------------ > > -- > Fedora-packaging mailing list > Fedora-packaging at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-packaging > Would you be willing to write up a draft for submission to the FPC? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From opensource at till.name Wed Sep 16 22:44:42 2009 From: opensource at till.name (Till Maas) Date: Thu, 17 Sep 2009 00:44:42 +0200 Subject: [Fedora-packaging] cleanup RPM Tags in Packaging Guidelines In-Reply-To: <4AB1462F.6090800@jcomserv.net> References: <20090916200416.GA23876@genius.kawo2.rwth-aachen.de> <4AB1462F.6090800@jcomserv.net> Message-ID: <20090916224442.GB23876@genius.kawo2.rwth-aachen.de> On Wed, Sep 16, 2009 at 03:10:23PM -0500, Jon Ciesla wrote: > Would you be willing to write up a draft for submission to the FPC? I started here: https://fedoraproject.org/wiki/PackagingDrafts/RPM_Tags_Whitelist I noticed during the editing, that the several guidelines regarding the RPM tags are spread through the whole Packagaging Guidelines, e.g. at the end of the Guidelines, there are additional Guidelines regarding Patches and Epoch and a Guideline regarding %clean is in between two other RPM tags. I will address this in the draft, too, before I consider it ready for review. Nevertheless, please already add RPM Tags to the Whitelist that you are missing. Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From opensource at till.name Wed Sep 16 23:16:52 2009 From: opensource at till.name (Till Maas) Date: Thu, 17 Sep 2009 01:16:52 +0200 Subject: [Fedora-packaging] Package Guildelines / Review Guidelines: .la archives must/should not contradiction Message-ID: <20090916231652.GC23876@genius.kawo2.rwth-aachen.de> Hiyas, I just noticed that the packaging guidelines say the .la archives should not be included but the review guidelienes say that they must not included: https://fedoraproject.org/wiki/Packaging:Guidelines#StaticLibraries https://fedoraproject.org/wiki/Packaging:ReviewGuidelines I stumbled up this because the Merge Review of apr cannot be finished with clarification of this: https://bugzilla.redhat.com/show_bug.cgi?id=225253 Regards Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From a.badger at gmail.com Thu Sep 17 02:20:50 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 16 Sep 2009 19:20:50 -0700 Subject: [Fedora-packaging] Package Guildelines / Review Guidelines: .la archives must/should not contradiction In-Reply-To: <20090916231652.GC23876@genius.kawo2.rwth-aachen.de> References: <20090916231652.GC23876@genius.kawo2.rwth-aachen.de> Message-ID: <4AB19D02.7030201@gmail.com> On 09/16/2009 04:16 PM, Till Maas wrote: > Hiyas, > > I just noticed that the packaging guidelines say the .la archives should > not be included but the review guidelienes say that they must not > included: > > https://fedoraproject.org/wiki/Packaging:Guidelines#StaticLibraries > https://fedoraproject.org/wiki/Packaging:ReviewGuidelines > > I stumbled up this because the Merge Review of apr cannot be finished > with clarification of this: > https://bugzilla.redhat.com/show_bug.cgi?id=225253 > I believe it should be a MUST with exceptions. Review Guidelines are more succinct and therefore less prone to a slip up when being written up. Even then, there have been times when a Review Guideline uses the uppercase, bold '''MUST''' to show that it's a MUST but then used should in the sentence describing what needs to be done. The only current exception is: """ Note that if you are updating a library in a stable release (not devel) and the package already contains *.la files, removing the *.la files should be treated as an API/ABI change """ That means that *.la should only be removed in devel or on new package review. The apr case could be a second exception (based on the idea that the apr-1-config --link-libtool should work on fedora). However, looking at the source code to /usr/bin/apr-1-config, I don't think that the removal of the *.la causes apr-1-config to fail:: --link-libtool) # If the LA_FILE exists where we think it should be, use it. If we're # installed and the LA_FILE does not exist, assume to use -L/-l # (the LA_FILE may not have been installed). If we're building ourselves, # we'll assume that at some point the .la file be created. if test -f "$LA_FILE"; then flags="$flags $LA_FILE" elif test "$location" = "installed"; then ### avoid using -L if libdir is a "standard" location like /usr/lib # Since the user is specifying they are linking with libtool, we # *know* that -R will be recognized by libtool. flags="$flags -L$libdir -R$libdir -l${APR_LIBNAME}" else flags="$flags $LA_FILE" fi ;; Is there a test case where removing the *.la causes a program to stop that uses apr-1-config --link-libtool to stop building? If not, then this is definitely not a valid basis for an exception. -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 braden at endoframe.com Thu Sep 17 04:16:54 2009 From: braden at endoframe.com (Braden McDaniel) Date: Thu, 17 Sep 2009 00:16:54 -0400 Subject: [Fedora-packaging] Re: Explicit "Requires" should (usually) be arch-specific In-Reply-To: <87ws3zjotp.fsf@sheridan.bigo.ensc.de> References: <1253052700.17997.4784.camel@localhost> <25148.1253056335@sss.pgh.pa.us> <1253057936.17997.4960.camel@localhost> <87ws3zjotp.fsf@sheridan.bigo.ensc.de> Message-ID: <1253161014.11306.1506.camel@localhost> On Wed, 2009-09-16 at 10:06 +0200, Enrico Scholz wrote: > Braden McDaniel writes: > > > On Tue, 2009-09-15 at 19:12 -0400, Tom Lane wrote: > >> Braden McDaniel writes: > >> > Since apparently a requirement for "foo" can be satisfied by any > >> > available architecture for which a "foo" is available, "Requires" that > >> > do not specify the architecture are unsafe for multilib systems (unless > >> > the dependency really can be satisfied by any architecture--which does > >> > not strike me as the most common case). > >> > >> Surely this is a bug, not something that every single specfile must > >> work around. > > > > If it's a bug, then how do you propose a specfile should articulate a > > "Requires" that *can* be satisfied by any architecture? > > Can be solved with virtual provides (which should not be tied to an > architecture): > > > | Provides: program(%name) = %version-%release > | > | %package devel > | Requires: program(%name) = %version-%release So you'd want to change the meaning of an unadorned package name in Requires to imply the same architecture as the same package build? I'm a little skeptical that will go over well. Also, the approach you suggest requires buy-in from the dependency (to provide the virtual package name) and the consequence is a substantial expansion of the set of virtual package names. -- Braden McDaniel From orion at cora.nwra.com Mon Sep 28 22:33:24 2009 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 28 Sep 2009 16:33:24 -0600 Subject: [Fedora-packaging] Ocaml sub-package issue Message-ID: <4AC139B4.9030508@cora.nwra.com> I package plplot which ships bindings for oodles of languages, among them perl and ocaml. The ocaml packaging guidelines suggest: %global _use_internal_dependency_generator 0 %global __find_requires /usr/lib/rpm/ocaml-find-requires.sh %global __find_provides /usr/lib/rpm/ocaml-find-provides.sh to add the required ocaml Requires/Provides. However, this breaks the automatic perl (and other?) generation for the perl sub-package. How should this be handled? Is there a way to add the ocaml-find-requires/provides to the normal list of providers? Shouldn't this be done automatically by the build system? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From taljurf at fedoraproject.org Mon Sep 28 23:53:32 2009 From: taljurf at fedoraproject.org (Tareq Al Jurf) Date: Tue, 29 Sep 2009 02:53:32 +0300 Subject: [Fedora-packaging] Problem with creating RPM for screenlets Message-ID: <12d8a2fa0909281653g1d18ef04pda563da7a73fdc59@mail.gmail.com> does this "python setup.py bdist_rpm"create packages correctly? i'm trying to create a package for screenlets from a tar.bz file and what version of python does fedora 12 have? -- Tareq Al Jurf Fedora Ambassador Riyadh, Saudi Arabia taljurf at fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Tue Sep 29 01:21:22 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 28 Sep 2009 18:21:22 -0700 Subject: [Fedora-packaging] Problem with creating RPM for screenlets In-Reply-To: <12d8a2fa0909281653g1d18ef04pda563da7a73fdc59@mail.gmail.com> References: <12d8a2fa0909281653g1d18ef04pda563da7a73fdc59@mail.gmail.com> Message-ID: <4AC16112.8040408@gmail.com> On 09/28/2009 04:53 PM, Tareq Al Jurf wrote: > does this "python setup.py bdist_rpm"create packages correctly? > > i'm trying to create a package for screenlets from a tar.bz file > python setup.py bdist_rpm usually manages to create an rpm. However, it is not an rpm that would pass the Fedora Packaging Guidelines and make it into the Fedora Repositories unchanged. > and what version of python does fedora 12 have? > Python-2.6.2 -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 michael.silvanus at gmail.com Tue Sep 29 18:37:02 2009 From: michael.silvanus at gmail.com (Michel Alexandre Salim) Date: Tue, 29 Sep 2009 14:37:02 -0400 Subject: [Fedora-packaging] Exemption for bundling local copy of system library? Message-ID: <615c05430909291137t633f4764jaa10737d27caeca4@mail.gmail.com> Hi, Oolite is currently undergoing review, and a stumbling block is in its use of its own copy of libjs. An upstream developer is participating in the review and has a clear explanation for the rationale: https://bugzilla.redhat.com/show_bug.cgi?id=459211 libjs is not exposed to any network interfaces, so the risk is probably quite low -- the alternative is to wait until xulrunner 2.0 is released (the previous stable version has problems in its scripting mechanism and most third-party add-ons for Oolite do not work on it anymore. Would it be alright in this case to bundle libjs? PS the "no bundled libraries" draft (http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does not clearly indicate which mailing list is to be used Thanks, -- Michel Alexandre Salim From limb at jcomserv.net Tue Sep 29 18:50:56 2009 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 29 Sep 2009 13:50:56 -0500 Subject: [Fedora-packaging] Exemption for bundling local copy of system library? In-Reply-To: <615c05430909291137t633f4764jaa10737d27caeca4@mail.gmail.com> References: <615c05430909291137t633f4764jaa10737d27caeca4@mail.gmail.com> Message-ID: <4AC25710.3050901@jcomserv.net> Michel Alexandre Salim wrote: > Hi, > > Oolite is currently undergoing review, and a > stumbling block is in its use of its own copy of libjs. An upstream > developer is participating in the review and has a clear explanation > for the rationale: > > https://bugzilla.redhat.com/show_bug.cgi?id=459211 > > libjs is not exposed to any network interfaces, so the risk is > probably quite low -- the alternative is to wait until xulrunner 2.0 > is released (the previous stable version has problems in its scripting > mechanism and most third-party add-ons for Oolite do not work on it > anymore. > > Would it be alright in this case to bundle libjs? > > PS the "no bundled libraries" draft > (http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does > not clearly indicate which mailing list is to be used > > Thanks, > > This list is fine. Based on what I see in the BZ, I'd much rather see you wait until they get on the current libjs, especially since it sounds fairly immanent. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie From a.badger at gmail.com Tue Sep 29 19:37:10 2009 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 29 Sep 2009 12:37:10 -0700 Subject: [Fedora-packaging] Exemption for bundling local copy of system library? In-Reply-To: <615c05430909291137t633f4764jaa10737d27caeca4@mail.gmail.com> References: <615c05430909291137t633f4764jaa10737d27caeca4@mail.gmail.com> Message-ID: <4AC261E6.8000704@gmail.com> On 09/29/2009 11:37 AM, Michel Alexandre Salim wrote: > Hi, > > Oolite is currently undergoing review, and a > stumbling block is in its use of its own copy of libjs. An upstream > developer is participating in the review and has a clear explanation > for the rationale: > > https://bugzilla.redhat.com/show_bug.cgi?id=459211 > > libjs is not exposed to any network interfaces, so the risk is > probably quite low -- the alternative is to wait until xulrunner 2.0 > is released (the previous stable version has problems in its scripting > mechanism and most third-party add-ons for Oolite do not work on it > anymore. > > Would it be alright in this case to bundle libjs? > I would argue no. The guidelines are written to apply to all libraries except with very limited exceptions to keep this from happening because security vulnerabilities are not limited to network facing code, suid code, or any other class that we've been able to identify. The libz vulnerability many years ago is the classic example of this. Many programs were embedding libz, many statically. When a security vulnerability in libz was discovered, we had to find all of those programs, remove the vulnerable library, patch any code that didn't work with the newer version, and rebuild all of those packages. This is not what you want to do when you are in the time-constrained situation of putting out a zero day update to the code. The statement that libjsis not exposed to the network is also not a guarantee that security problems will be low-impact on several counts: 1) Libraries in C can cause problems in unrelated sections of code because they can access memory directly. Sometimes this can lead to very bad exploits (especially in code with enhanced privileges), other times it is the first step for an attacker to look for other programs on your machine that are vulnerable to other sorts of attacks. 2) """Libjs is used to run local user-installed scripts (as parts of expansion packs) only""". Although libjs may not retrieve scripts directly from the network, it is definitely handling data of foreign origin. If I download an expansion pack because I saw a review that made it look really cool and then run it, I am exposing libjs to that code from a random source. If there were a buffer overflow in libjs and someone realized that OOList contains its own copy of libjs, they could try to craft an expansion pack that takes advantage of that fact. And it's probably premature to go to FESCo with this. Firefox does not use the system libjs.so. So you should find out if the spidermonkey maintainer is willing to compile with JS_C_STRINGS_ARE_UTF8. At present the only depending package I see is mediatomb so this might be the best option. Also note, it sounds like Oolite is updating to js-1.80 -- that's currently at rc1, not an actual release. You'll need to work with the js maintainer and make sure that that is okay as well. > PS the "no bundled libraries" draft > (http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does > not clearly indicate which mailing list is to be used > The actual decision is a FESCo decision. That would be tracked in their trac instance. But FPC people are going to have input on it which would be here. Everyone on fedora-devel-list has 2 cents to put in on these cases but very few of them seem to want to look at the problems that arise with bundling libraries and propose solutions so it's easy to be mislead into thinking that something's acceptable because it's easy rather than likely to be denied because there's no basis to grant an exception. -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 michael.silvanus at gmail.com Tue Sep 29 20:13:11 2009 From: michael.silvanus at gmail.com (Michel Alexandre Salim) Date: Tue, 29 Sep 2009 16:13:11 -0400 Subject: [Fedora-packaging] Exemption for bundling local copy of system library? In-Reply-To: <4AC261E6.8000704@gmail.com> References: <615c05430909291137t633f4764jaa10737d27caeca4@mail.gmail.com> <4AC261E6.8000704@gmail.com> Message-ID: <615c05430909291313s2cc5eb32x347487936ca61a3c@mail.gmail.com> On Tue, Sep 29, 2009 at 3:37 PM, Toshio Kuratomi wrote: > On 09/29/2009 11:37 AM, Michel Alexandre Salim wrote: >> Hi, >> >> Oolite is currently undergoing review, and a >> stumbling block is in its use of its own copy of libjs. An upstream >> developer is participating in the review and has a clear explanation >> for the rationale: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=459211 >> >> libjs is not exposed to any network interfaces, so the risk is >> probably quite low -- the alternative is to wait until xulrunner 2.0 >> is released (the previous stable version has problems in its scripting >> mechanism and most third-party add-ons for Oolite do not work on it >> anymore. >> >> Would it be alright in this case to bundle libjs? >> > > I would argue no. ?The guidelines are written to apply to all libraries > except with very limited exceptions to keep this from happening because > security vulnerabilities are not limited to network facing code, suid > code, or any other class that we've been able to identify. ?The libz > vulnerability many years ago is the classic example of this. ?Many > programs were embedding libz, many statically. ?When a security > vulnerability in libz was discovered, we had to find all of those > programs, remove the vulnerable library, patch any code that didn't work > with the newer version, and rebuild all of those packages. ?This is not > what you want to do when you are in the time-constrained situation of > putting out a zero day update to the code. > Understandable. I suppose the best way to proceed is to continue the review, but wait on the libjs removal for final approval. > And it's probably premature to go to FESCo with this. ?Firefox does not > use the system libjs.so. ?So you should find out if the spidermonkey > maintainer is willing to compile with JS_C_STRINGS_ARE_UTF8. ?At present > the only depending package I see is mediatomb so this might be the best > option. Good point; I'll contact both maintainers. > > Also note, it sounds like Oolite is updating to js-1.80 -- that's > currently at rc1, not an actual release. ?You'll need to work with the > js maintainer and make sure that that is okay as well. > Worse come to worse, we can stay at the last version that support js-1.70, and probably ask the js maintainer to update Rawhide to 1.80-pre, now that F-12 branching has occured? Thanks, Toshio and Jon, for the inputs. -- Michel Alexandre Salim From michael.silvanus at gmail.com Tue Sep 29 20:30:21 2009 From: michael.silvanus at gmail.com (Michel Alexandre Salim) Date: Tue, 29 Sep 2009 16:30:21 -0400 Subject: Fwd: [Fedora-packaging] Exemption for bundling local copy of system library? In-Reply-To: <4AC261E6.8000704@gmail.com> References: <615c05430909291137t633f4764jaa10737d27caeca4@mail.gmail.com> <4AC261E6.8000704@gmail.com> Message-ID: <615c05430909291330w2bbc6dc4j32bb530e61e3ab81@mail.gmail.com> Hi all, I'm writing this because I am currently packaging an application, Oolite, that would require libjs to be compiled with -DJS_C_STRINGS_ARE_UTF8, and your packages are directly involved (either js, or a dependent). Is there any detrimental effect if libjs is compiled with this setting? From the upstream bug report, it would seem that it only affects Mozilla products (which, in Fedora, use xulrunner's libjs). There is a discussion on a Mozilla mailing list in which CouchDB developers even request this switch, but I cannot seem to find it today. $ repoquery --whatrequires --alldeps js mediatomb-0:0.11.0-11.fc12.x86_64 gpac-libs-0:0.4.6-0.1.cvs20090919.fc12.i686 gpac-libs-0:0.4.6-0.1.cvs20090919.fc12.x86_64 js-devel-0:1.70-8.fc12.i686 callweaver-javascript-0:1.2.1-2.fc12.x86_64 js-devel-0:1.70-8.fc12.x86_64 couchdb-0:0.9.1-1.fc12.x86_64 js-0:1.70-8.fc12.i686 js-0:1.70-8.fc12.x86_64 If the js maintainers are willing to make the change, then what I propose is to put up a test build somewhere, and then all of us could test our packages against this new js, and we can commit it if there is no breakage. Thanks, -- Michel ---------- Forwarded message ---------- From: Toshio Kuratomi Date: Tue, Sep 29, 2009 at 3:37 PM Subject: Re: [Fedora-packaging] Exemption for bundling local copy of system library? To: Discussion of RPM packaging standards and practices for Fedora , Fedora Devel On 09/29/2009 11:37 AM, Michel Alexandre Salim wrote: > Hi, > > Oolite is currently undergoing review, and a > stumbling block is in its use of its own copy of libjs. An upstream > developer is participating in the review and has a clear explanation > for the rationale: > > https://bugzilla.redhat.com/show_bug.cgi?id=459211 > > libjs is not exposed to any network interfaces, so the risk is > probably quite low -- the alternative is to wait until xulrunner 2.0 > is released (the previous stable version has problems in its scripting > mechanism and most third-party add-ons for Oolite do not work on it > anymore. > > Would it be alright in this case to bundle libjs? > I would argue no. ?The guidelines are written to apply to all libraries except with very limited exceptions to keep this from happening because security vulnerabilities are not limited to network facing code, suid code, or any other class that we've been able to identify. ?The libz vulnerability many years ago is the classic example of this. ?Many programs were embedding libz, many statically. ?When a security vulnerability in libz was discovered, we had to find all of those programs, remove the vulnerable library, patch any code that didn't work with the newer version, and rebuild all of those packages. ?This is not what you want to do when you are in the time-constrained situation of putting out a zero day update to the code. The statement that libjsis not exposed to the network is also not a guarantee that security problems will be low-impact on several counts: 1) Libraries in C can cause problems in unrelated sections of code because they can access memory directly. ?Sometimes this can lead to very bad exploits (especially in code with enhanced privileges), other times it is the first step for an attacker to look for other programs on your machine that are vulnerable to other sorts of attacks. 2) """Libjs is used to run local user-installed scripts (as parts of expansion packs) only""". ?Although libjs may not retrieve scripts directly from the network, it is definitely handling data of foreign origin. ?If I download an expansion pack because I saw a review that made it look really cool and then run it, I am exposing libjs to that code from a random source. ?If there were a buffer overflow in libjs and someone realized that OOList contains its own copy of libjs, they could try to craft an expansion pack that takes advantage of that fact. And it's probably premature to go to FESCo with this. ?Firefox does not use the system libjs.so. ?So you should find out if the spidermonkey maintainer is willing to compile with JS_C_STRINGS_ARE_UTF8. ?At present the only depending package I see is mediatomb so this might be the best option. Also note, it sounds like Oolite is updating to js-1.80 -- that's currently at rc1, not an actual release. ?You'll need to work with the js maintainer and make sure that that is okay as well. > PS the "no bundled libraries" draft > (http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries) does > not clearly indicate which mailing list is to be used > The actual decision is a FESCo decision. ?That would be tracked in their trac instance. ?But FPC people are going to have input on it which would be here. ?Everyone on fedora-devel-list has 2 cents to put in on these cases but very few of them seem to want to look at the problems that arise with bundling libraries and propose solutions so it's easy to be mislead into thinking that something's acceptable because it's easy rather than likely to be denied because there's no basis to grant an exception. -Toshio -- Fedora-packaging mailing list Fedora-packaging at redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging -- Michel Alexandre Salim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dtimms at iinet.net.au Wed Sep 30 13:33:41 2009 From: dtimms at iinet.net.au (David Timms) Date: Wed, 30 Sep 2009 23:33:41 +1000 Subject: [Fedora-packaging] packaging a command line app to have action / servicemenu in filemanagers Message-ID: <4AC35E35.4040501@iinet.net.au> Hi, my pre-reviewer [1] noted that I didn't run desktop-file-install on a .desktop file I am installing. However, the app isn't actually a gui app, therefore the must rule doesn't apply. What the .desktop file does achieve is adding an "extract tnef archive" menu item to files where the mime-type matches tnef. The unwanted sideeffect of doing this is that gnome places an icon for the program into the Application menu. This icon is useless; it runs a script to run the app, without an input parameter, and hence does nothing (well, that 'nothing' might need to be double checked). Is it acceptable to add a desktop file to achieve this ? Is there someway to indicate to the desktop program that the menu entry shouldn't be shown ? Does using desktop-file-x any use on .desktop files that aren't intended to become part of the menus ? DaveT. [1] https://bugzilla.redhat.com/show_bug.cgi?id=522920 From rdieter at math.unl.edu Wed Sep 30 13:40:15 2009 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 30 Sep 2009 08:40:15 -0500 Subject: [Fedora-packaging] packaging a command line app to have action / servicemenu in filemanagers In-Reply-To: <4AC35E35.4040501@iinet.net.au> References: <4AC35E35.4040501@iinet.net.au> Message-ID: <4AC35FBF.10109@math.unl.edu> David Timms wrote: > Is there someway to indicate to the desktop program that the menu entry > shouldn't be shown ? add to the .desktop file, the key: NoDisplay=true -- Rex From dtimms at iinet.net.au Wed Sep 30 14:05:07 2009 From: dtimms at iinet.net.au (David Timms) Date: Thu, 01 Oct 2009 00:05:07 +1000 Subject: [Fedora-packaging] packaging a command line app to have action / servicemenu in filemanagers In-Reply-To: <4AC35FBF.10109@math.unl.edu> References: <4AC35E35.4040501@iinet.net.au> <4AC35FBF.10109@math.unl.edu> Message-ID: <4AC36593.1020704@iinet.net.au> On 09/30/2009 11:40 PM, Rex Dieter wrote: >> Is there someway to indicate to the desktop program that the menu >> entry shouldn't be shown ? > > add to the .desktop file, the key: > NoDisplay=true Thanks Rex, Any opinions on the other items - like running desktop file install (which fails): + mkdir -p /home/davidt/rpmbuild/BUILDROOT/tnef-1.4.6-3.fc11.i386//usr/share/mimelnk/application/ + desktop-file-install --dir=/home/davidt/rpmbuild/BUILDROOT/tnef-1.4.6-3.fc11.i386/usr/share/mimelnk/applications /home/davidt/rpmbuild/SOURCES/vnd.ms-tnef.desktop /home/davidt/rpmbuild/BUILDROOT/tnef-1.4.6-3.fc11.i386/usr/share/mimelnk/applications/vnd.ms-tnef.desktop: error: key "MimeType" is present in group "Desktop Entry", but the type is "MimeType" while this key is only valid for type "Application" /home/davidt/rpmbuild/BUILDROOT/tnef-1.4.6-3.fc11.i386/usr/share/mimelnk/applications/vnd.ms-tnef.desktop: error: key "Exec" is present in group "Desktop Entry", but the type is "MimeType" while this key is only valid for type "Application" Error on file "/home/davidt/rpmbuild/SOURCES/vnd.ms-tnef.desktop": Failed to validate the created desktop file error: Bad exit status from /var/tmp/rpm-tmp.s0UHb2 (%install) Am I doing it all wrong, or is the validator not versed in this type of .desktop file ? DaveT. From mclasen at redhat.com Wed Sep 30 16:33:52 2009 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 30 Sep 2009 12:33:52 -0400 Subject: [Fedora-packaging] packaging a command line app to have action / servicemenu in filemanagers In-Reply-To: <4AC36593.1020704@iinet.net.au> References: <4AC35E35.4040501@iinet.net.au> <4AC35FBF.10109@math.unl.edu> <4AC36593.1020704@iinet.net.au> Message-ID: <1254328432.1676.3.camel@planemask> On Thu, 2009-10-01 at 00:05 +1000, David Timms wrote: > On 09/30/2009 11:40 PM, Rex Dieter wrote: > >> Is there someway to indicate to the desktop program that the menu > >> entry shouldn't be shown ? > > > > add to the .desktop file, the key: > > NoDisplay=true > Thanks Rex, > > Any opinions on the other items - like running desktop file install > (which fails): > + mkdir -p > /home/davidt/rpmbuild/BUILDROOT/tnef-1.4.6-3.fc11.i386//usr/share/mimelnk/application/ > + desktop-file-install > --dir=/home/davidt/rpmbuild/BUILDROOT/tnef-1.4.6-3.fc11.i386/usr/share/mimelnk/applications > /home/davidt/rpmbuild/SOURCES/vnd.ms-tnef.desktop > /home/davidt/rpmbuild/BUILDROOT/tnef-1.4.6-3.fc11.i386/usr/share/mimelnk/applications/vnd.ms-tnef.desktop: > error: key "MimeType" is present in group "Desktop Entry", but the type > is "MimeType" while this key is only valid for type "Application" > /home/davidt/rpmbuild/BUILDROOT/tnef-1.4.6-3.fc11.i386/usr/share/mimelnk/applications/vnd.ms-tnef.desktop: > error: key "Exec" is present in group "Desktop Entry", but the type is > "MimeType" while this key is only valid for type "Application" > Error on file "/home/davidt/rpmbuild/SOURCES/vnd.ms-tnef.desktop": > Failed to validate the created desktop file > error: Bad exit status from /var/tmp/rpm-tmp.s0UHb2 (%install) > > Am I doing it all wrong, or is the validator not versed in this type of > .desktop file ? > Your desktop file is not valid. If it is for an application, it needs to have Type=Application