From pnasrat at redhat.com Fri Jul 1 21:43:16 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 01 Jul 2005 17:43:16 -0400 Subject: incoming: dependency warnings In-Reply-To: <20050621170058.GA9231@nostromo.devel.redhat.com> References: <20050621170058.GA9231@nostromo.devel.redhat.com> Message-ID: <1120254196.5790.1.camel@enki.eridu> On Tue, 2005-06-21 at 13:00 -0400, Bill Nottingham wrote: > Starting later today or tomorrow, the build system will start > sending mail when there are broken dependencies in the development > tree. > > Mail will be sent to the package owner, and those who may be > responsible. Consider yourself warned. > > I suppose it will be about two days until all of these are procmailed > to /dev/null. Is there anyway to register exceptions, - eg for secondary archs such as ppc64 which is all I'm getting build dep failures on? Paul From notting at redhat.com Fri Jul 1 21:54:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 1 Jul 2005 17:54:00 -0400 Subject: incoming: dependency warnings In-Reply-To: <1120254196.5790.1.camel@enki.eridu> References: <20050621170058.GA9231@nostromo.devel.redhat.com> <1120254196.5790.1.camel@enki.eridu> Message-ID: <20050701215400.GC18766@nostromo.devel.redhat.com> Paul Nasrat (pnasrat at redhat.com) said: > On Tue, 2005-06-21 at 13:00 -0400, Bill Nottingham wrote: > > Starting later today or tomorrow, the build system will start > > sending mail when there are broken dependencies in the development > > tree. > > > > Mail will be sent to the package owner, and those who may be > > responsible. Consider yourself warned. > > > > I suppose it will be about two days until all of these are procmailed > > to /dev/null. > > Is there anyway to register exceptions, - eg for secondary archs such as > ppc64 which is all I'm getting build dep failures on? Not very easily, no. Bill From dwmw2 at infradead.org Fri Jul 1 22:52:36 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 01 Jul 2005 23:52:36 +0100 Subject: incoming: dependency warnings In-Reply-To: <1120254196.5790.1.camel@enki.eridu> References: <20050621170058.GA9231@nostromo.devel.redhat.com> <1120254196.5790.1.camel@enki.eridu> Message-ID: <1120258356.3142.7.camel@localhost.localdomain> On Fri, 2005-07-01 at 17:43 -0400, Paul Nasrat wrote: > Is there anyway to register exceptions, - eg for secondary archs such > as ppc64 which is all I'm getting build dep failures on? We do a ppc64 compose which is expected to work, don't we? We don't ever actually _ship_ it but it's still expected to be complete, surely? Why are dependency failures expected? -- dwmw2 From pnasrat at redhat.com Sat Jul 2 12:37:32 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Sat, 02 Jul 2005 08:37:32 -0400 Subject: incoming: dependency warnings In-Reply-To: <1120258356.3142.7.camel@localhost.localdomain> References: <20050621170058.GA9231@nostromo.devel.redhat.com> <1120254196.5790.1.camel@enki.eridu> <1120258356.3142.7.camel@localhost.localdomain> Message-ID: <1120307852.4888.1.camel@enki.eridu> On Fri, 2005-07-01 at 23:52 +0100, David Woodhouse wrote: > On Fri, 2005-07-01 at 17:43 -0400, Paul Nasrat wrote: > > Is there anyway to register exceptions, - eg for secondary archs such > > as ppc64 which is all I'm getting build dep failures on? > > We do a ppc64 compose which is expected to work, don't we? We don't ever > actually _ship_ it but it's still expected to be complete, surely? Why > are dependency failures expected? Eg - yaboot is ppc32 only - as OF only supports booting 32bit ELF IIRC. ppc64-utils requires yaboot ppc64-utils in the ppc64 tree has a broken dep Therefore in the ppc64 only tree which doesn't have any biarch magic ppc64-utils will always be seen as broken. Paul From dwmw2 at infradead.org Sat Jul 2 12:44:22 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 02 Jul 2005 13:44:22 +0100 Subject: incoming: dependency warnings In-Reply-To: <1120307852.4888.1.camel@enki.eridu> References: <20050621170058.GA9231@nostromo.devel.redhat.com> <1120254196.5790.1.camel@enki.eridu> <1120258356.3142.7.camel@localhost.localdomain> <1120307852.4888.1.camel@enki.eridu> Message-ID: <1120308262.3808.81.camel@localhost.localdomain> On Sat, 2005-07-02 at 08:37 -0400, Paul Nasrat wrote: > Eg - yaboot is ppc32 only - as OF only supports booting 32bit ELF > IIRC. > > ppc64-utils requires yaboot > ppc64-utils in the ppc64 tree has a broken dep > > Therefore in the ppc64 only tree which doesn't have any biarch magic > ppc64-utils will always be seen as broken. Ah, I understand. But doesn't that mean the ppc64 compose isn't bootable? I haven't tried it, but I thought it should give a fully 64-bit system. Should we do the same (evil) trick as we do with memtest86 on x86_64 -- build a 64-bit package which actually contains 32-bit binaries? -- dwmw2 From wtogami at redhat.com Wed Jul 6 06:24:27 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 05 Jul 2005 20:24:27 -1000 Subject: Package Process for Discussion In-Reply-To: <42C3CA1A.8010709@redhat.com> References: <42C3CA1A.8010709@redhat.com> Message-ID: <42CB791B.3090708@redhat.com> After talking with dkl, he pointed out significant technical problems with the proposed process. It needs to be reworked in order to be technically possible to implement within our existing Bugzilla infrastructure. Unfortunately I personally have urgent priorities to deal with until August. I am passing on my half-finished notes to dkl and hopefully he or someone else in the company can finish it sooner. I am disheartened by this entire situation, because the end process is looking more and more similar to the old fedora.us process. i.e. we could have done this (albeit without the convenience of flags) in February like I had originally proposed. Warren Togami wtogami at redhat.com From skvidal at phy.duke.edu Fri Jul 8 02:31:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 07 Jul 2005 22:31:32 -0400 Subject: extras buildsystem downtime Message-ID: <1120789892.9653.0.camel@cutter> Hi, This weekend starting on friday night (10pm GMT-5) the fedora extras buildsystems will go down so we can migrate over to the newer buildsystem code. We will be testing the code throughout the weekend and will not be accepting build submissions in this time. You can use cvs as normal to check in changes but you won't be able to submit your jobs to be built this weekend. Thanks, -sv From wtogami at redhat.com Fri Jul 8 22:33:17 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 08 Jul 2005 12:33:17 -1000 Subject: Package umask issues Message-ID: <42CEFF2D.2010101@redhat.com> Hi Spot, During FUDCON2 one of the TODO's I promised you was to send details about package umask issues. This is only an issue for sysadmins when they insist on using a system umask of 077 supposedly for some hardening reason. Two kinds of packages then have problems: 1) Packages with unowned files or directories. This of course has an obvious solution, simply own it. This is already covered in our packaging guidelines. MUST right? 2) Packages which create unpackaged files in scriptlets like %post https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136030 This is one example where this caused a problem. The quick and ugly workaround is to explicitly set umask at the beginning of the scriptlet. But the correct fix would be to make it so the software does not create files in %post. The latter solution is not always trivial. Should we make #2 a SHOULD or MUST in guidelines? Warren Togami wtogami at redhat.com From tcallawa at redhat.com Fri Jul 8 23:22:54 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 08 Jul 2005 18:22:54 -0500 Subject: Package umask issues In-Reply-To: <42CEFF2D.2010101@redhat.com> References: <42CEFF2D.2010101@redhat.com> Message-ID: <1120864974.22400.18.camel@localhost.localdomain> On Fri, 2005-07-08 at 12:33 -1000, Warren Togami wrote: > Hi Spot, > > During FUDCON2 one of the TODO's I promised you was to send details > about package umask issues. This is only an issue for sysadmins when > they insist on using a system umask of 077 supposedly for some hardening > reason. Two kinds of packages then have problems: > > 1) Packages with unowned files or directories. This of course has an > obvious solution, simply own it. This is already covered in our > packaging guidelines. MUST right? > > 2) Packages which create unpackaged files in scriptlets like %post > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136030 > This is one example where this caused a problem. The quick and ugly > workaround is to explicitly set umask at the beginning of the scriptlet. > But the correct fix would be to make it so the software does not > create files in %post. The latter solution is not always trivial. > > Should we make #2 a SHOULD or MUST in guidelines? I'm inclined to add: MUST: Packages should not create files in %post. All files should be accounted for in %files. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From wtogami at redhat.com Fri Jul 8 23:29:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 08 Jul 2005 13:29:53 -1000 Subject: Package umask issues In-Reply-To: <1120864974.22400.18.camel@localhost.localdomain> References: <42CEFF2D.2010101@redhat.com> <1120864974.22400.18.camel@localhost.localdomain> Message-ID: <42CF0C71.6060800@redhat.com> Tom 'spot' Callaway wrote: > On Fri, 2005-07-08 at 12:33 -1000, Warren Togami wrote: > >>Hi Spot, >> >>During FUDCON2 one of the TODO's I promised you was to send details >>about package umask issues. This is only an issue for sysadmins when >>they insist on using a system umask of 077 supposedly for some hardening >>reason. Two kinds of packages then have problems: >> >>1) Packages with unowned files or directories. This of course has an >>obvious solution, simply own it. This is already covered in our >>packaging guidelines. MUST right? >> >>2) Packages which create unpackaged files in scriptlets like %post >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136030 >>This is one example where this caused a problem. The quick and ugly >>workaround is to explicitly set umask at the beginning of the scriptlet. >> But the correct fix would be to make it so the software does not >>create files in %post. The latter solution is not always trivial. >> >>Should we make #2 a SHOULD or MUST in guidelines? > > > I'm inclined to add: > > MUST: Packages should not create files in %post. All files should be > accounted for in %files. > > ~spot That isn't going to be easy to fix for all software. It is desired though. Warren Togami wtogami at redhat.com From tgl at redhat.com Fri Jul 8 23:38:16 2005 From: tgl at redhat.com (Tom Lane) Date: Fri, 08 Jul 2005 19:38:16 -0400 Subject: Package umask issues In-Reply-To: <42CF0C71.6060800@redhat.com> References: <42CEFF2D.2010101@redhat.com> <1120864974.22400.18.camel@localhost.localdomain> <42CF0C71.6060800@redhat.com> Message-ID: <29192.1120865896@sss.pgh.pa.us> Warren Togami writes: > Tom 'spot' Callaway wrote: >> I'm inclined to add: >> >> MUST: Packages should not create files in %post. All files should be >> accounted for in %files. > That isn't going to be easy to fix for all software. It is desired though. Would it work in such cases for the %post routine to just fill in the contents of a file that was created (as empty, say) in the regular file list? regards, tom lane From tcallawa at redhat.com Fri Jul 8 23:45:25 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 08 Jul 2005 18:45:25 -0500 Subject: Package umask issues In-Reply-To: <29192.1120865896@sss.pgh.pa.us> References: <42CEFF2D.2010101@redhat.com> <1120864974.22400.18.camel@localhost.localdomain> <42CF0C71.6060800@redhat.com> <29192.1120865896@sss.pgh.pa.us> Message-ID: <1120866325.22400.20.camel@localhost.localdomain> On Fri, 2005-07-08 at 19:38 -0400, Tom Lane wrote: > Warren Togami writes: > > Tom 'spot' Callaway wrote: > >> I'm inclined to add: > >> > >> MUST: Packages should not create files in %post. All files should be > >> accounted for in %files. > > > That isn't going to be easy to fix for all software. It is desired though. > > Would it work in such cases for the %post routine to just fill in the > contents of a file that was created (as empty, say) in the regular file > list? Sounds like a valid methodology to me. We just need to make sure the file is taken out when the package is. ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From wtogami at redhat.com Fri Jul 8 23:45:47 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 08 Jul 2005 13:45:47 -1000 Subject: Package umask issues In-Reply-To: <29192.1120865896@sss.pgh.pa.us> References: <42CEFF2D.2010101@redhat.com> <1120864974.22400.18.camel@localhost.localdomain> <42CF0C71.6060800@redhat.com> <29192.1120865896@sss.pgh.pa.us> Message-ID: <42CF102B.90805@redhat.com> Tom Lane wrote: > Warren Togami writes: > >>Tom 'spot' Callaway wrote: >> >>>I'm inclined to add: >>> >>>MUST: Packages should not create files in %post. All files should be >>>accounted for in %files. > > >>That isn't going to be easy to fix for all software. It is desired though. > > > Would it work in such cases for the %post routine to just fill in the > contents of a file that was created (as empty, say) in the regular file > list? > > regards, tom lane > If it preserves the file permissions (by modifying?) then yes. If it deletes and recreates the file, it will still be affected by the umask problem. Warren Togami wtogami at redhat.com From mitr at redhat.com Fri Jul 8 23:47:21 2005 From: mitr at redhat.com (Miloslav Trmac) Date: Sat, 9 Jul 2005 01:47:21 +0200 Subject: Package umask issues In-Reply-To: <42CEFF2D.2010101@redhat.com> References: <42CEFF2D.2010101@redhat.com> Message-ID: <20050708234721.GC2900@amilo> On Fri, Jul 08, 2005 at 12:33:17PM -1000, Warren Togami wrote: > This is only an issue for sysadmins when > they insist on using a system umask of 077 supposedly for some hardening > reason. Would it be too daring to suggest that this would be easiest to fix in rpm by forcing umask to 022 before extracting files or running scripts? Mirek From skvidal at phy.duke.edu Sat Jul 9 05:01:02 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 09 Jul 2005 01:01:02 -0400 Subject: extras buildsystem Message-ID: <1120885262.22153.0.camel@cutter> Hi Folks, The buildsystem is down for the duration of the weekend except for testing of the new code. Running 'make build' will accomplish nothing and the jobs you try to queue that way will just get ignored. Thanks, -sv From enrico.scholz at informatik.tu-chemnitz.de Sat Jul 9 08:20:00 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 09 Jul 2005 10:20:00 +0200 Subject: Package umask issues In-Reply-To: <42CEFF2D.2010101@redhat.com> (Warren Togami's message of "Fri, 08 Jul 2005 12:33:17 -1000") References: <42CEFF2D.2010101@redhat.com> Message-ID: <87oe9cl7bj.fsf@kosh.bigo.ensc.de> wtogami at redhat.com (Warren Togami) writes: > 1) Packages with unowned files or directories. This of course has an > obvious solution, simply own it. This solution is not so obviously as it seems to be. Handling of locale directories is still unsolved. Plus, there are lot of Fedora Core packages violating this rule and are leaving unowned directories. Fedora Extras packages using these dirs and requiring a package which should own them but does not do it, are doing the right thing but violate the MUST-OWN rule. http://enrico-scholz.de/rpmDirectoryCheck/sample/fc4.html.gz Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From laroche at redhat.com Sat Jul 9 10:23:39 2005 From: laroche at redhat.com (Florian La Roche) Date: Sat, 9 Jul 2005 12:23:39 +0200 Subject: Package umask issues In-Reply-To: <20050708234721.GC2900@amilo> References: <42CEFF2D.2010101@redhat.com> <20050708234721.GC2900@amilo> Message-ID: <20050709102339.GA13808@dudweiler.stuttgart.redhat.com> On Sat, Jul 09, 2005 at 01:47:21AM +0200, Miloslav Trmac wrote: > On Fri, Jul 08, 2005 at 12:33:17PM -1000, Warren Togami wrote: > > This is only an issue for sysadmins when > > they insist on using a system umask of 077 supposedly for some hardening > > reason. > Would it be too daring to suggest that this would be easiest to fix > in rpm by forcing umask to 022 before extracting files or running scripts? Yes, this should be set in rpm. greetings, Florian La Roche From roland at redhat.com Sat Jul 9 20:28:40 2005 From: roland at redhat.com (Roland McGrath) Date: Sat, 9 Jul 2005 13:28:40 -0700 (PDT) Subject: sqlite Message-ID: <20050709202840.D24BB230048@magilla.sf.frob.com> AFAICT, the only reason sqlite is in Core rather than Extras is that rpm uses it. (rpm doesn't tell me about any other dependencies on an Everything install.) The package seems to be abandoned, as far as a maintainer. Is that accurate? Would rpm survive an upgrade of sqlite to the current version, 3.2.2? Thanks, Roland From jspaleta at gmail.com Sat Jul 9 20:32:23 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jul 2005 16:32:23 -0400 Subject: sqlite In-Reply-To: <20050709202840.D24BB230048@magilla.sf.frob.com> References: <20050709202840.D24BB230048@magilla.sf.frob.com> Message-ID: <604aa7910507091332175a9a72@mail.gmail.com> On 7/9/05, Roland McGrath wrote: > AFAICT, the only reason sqlite is in Core rather than Extras is that rpm > uses it. (rpm doesn't tell me about any other dependencies on an > Everything install.) The package seems to be abandoned, as far as a > maintainer. Is that accurate? Would rpm survive an upgrade of sqlite to > the current version, 3.2.2? pretty sure yum is using sqlite. Lets take my development box for example. rpm -q --provides sqlite libsqlite3.so.0 <------ lets look at that sqlite = 3.1.2-3 rpm -q --whatrequires libsqlite3.so.0 net-snmp-5.2.1-13 rpm-libs-4.4.1-21 rpm-4.4.1-21 apt-0.5.15cnc7-2 net-snmp-utils-5.2.1-13 python-sqlite-1.1.6-1 <--------- lets look at that sqlite-3.1.2-3 rpm-build-4.4.1-21 rpm -q --whatrequires python-sqlite yum-2.3.4-1 -jef From skvidal at phy.duke.edu Sat Jul 9 20:35:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 09 Jul 2005 16:35:36 -0400 Subject: sqlite In-Reply-To: <20050709202840.D24BB230048@magilla.sf.frob.com> References: <20050709202840.D24BB230048@magilla.sf.frob.com> Message-ID: <1120941336.22153.9.camel@cutter> On Sat, 2005-07-09 at 13:28 -0700, Roland McGrath wrote: > AFAICT, the only reason sqlite is in Core rather than Extras is that rpm > uses it. (rpm doesn't tell me about any other dependencies on an > Everything install.) The package seems to be abandoned, as far as a > maintainer. Is that accurate? Would rpm survive an upgrade of sqlite to > the current version, 3.2.2? > sqlite is in core b/c yum requires it, too. -sv From roland at redhat.com Sat Jul 9 20:34:52 2005 From: roland at redhat.com (Roland McGrath) Date: Sat, 9 Jul 2005 13:34:52 -0700 (PDT) Subject: sqlite In-Reply-To: Jeff Spaleta's message of Saturday, 9 July 2005 16:32:23 -0400 <604aa7910507091332175a9a72@mail.gmail.com> Message-ID: <20050709203452.A5D50230048@magilla.sf.frob.com> > rpm -q --provides sqlite > libsqlite3.so.0 <------ lets look at that That's what I didn't do. Thanks. > sqlite = 3.1.2-3 > > rpm -q --whatrequires libsqlite3.so.0 > net-snmp-5.2.1-13 > rpm-libs-4.4.1-21 > rpm-4.4.1-21 > apt-0.5.15cnc7-2 > net-snmp-utils-5.2.1-13 > python-sqlite-1.1.6-1 <--------- lets look at that > sqlite-3.1.2-3 > rpm-build-4.4.1-21 > > rpm -q --whatrequires python-sqlite > yum-2.3.4-1 It sure would be nice if rpm or yum or something had a --whatrequires that did what I was thinking. ;-) So, I amend my question. Would all those things (looks like all stuff using it for rpm purposes, plus net-snmp) survive the upgrade? Thanks, Roland From skvidal at phy.duke.edu Sat Jul 9 20:40:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 09 Jul 2005 16:40:26 -0400 Subject: sqlite In-Reply-To: <20050709203452.A5D50230048@magilla.sf.frob.com> References: <20050709203452.A5D50230048@magilla.sf.frob.com> Message-ID: <1120941626.22153.11.camel@cutter> On Sat, 2005-07-09 at 13:34 -0700, Roland McGrath wrote: > > rpm -q --provides sqlite > > libsqlite3.so.0 <------ lets look at that > > That's what I didn't do. Thanks. > > > sqlite = 3.1.2-3 > > > > rpm -q --whatrequires libsqlite3.so.0 > > net-snmp-5.2.1-13 > > rpm-libs-4.4.1-21 > > rpm-4.4.1-21 > > apt-0.5.15cnc7-2 > > net-snmp-utils-5.2.1-13 > > python-sqlite-1.1.6-1 <--------- lets look at that > > sqlite-3.1.2-3 > > rpm-build-4.4.1-21 > > > > rpm -q --whatrequires python-sqlite > > yum-2.3.4-1 > > It sure would be nice if rpm or yum or something had a --whatrequires that > did what I was thinking. ;-) > > So, I amend my question. Would all those things (looks like all stuff > using it for rpm purposes, plus net-snmp) survive the upgrade? > it depends - is there an api break from 3.1 to 3.2? -sv From roland at redhat.com Sat Jul 9 20:42:43 2005 From: roland at redhat.com (Roland McGrath) Date: Sat, 9 Jul 2005 13:42:43 -0700 (PDT) Subject: sqlite In-Reply-To: seth vidal's message of Saturday, 9 July 2005 16:40:26 -0400 <1120941626.22153.11.camel@cutter> Message-ID: <20050709204243.1FA60230048@magilla.sf.frob.com> > it depends - is there an api break from 3.1 to 3.2? I really don't know anything about it. I can look at the diffs. But I need knowledgeable users of sqlite to say what the effects might be. Thanks, Roland From skvidal at phy.duke.edu Sat Jul 9 20:46:32 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 09 Jul 2005 16:46:32 -0400 Subject: sqlite In-Reply-To: <20050709204243.1FA60230048@magilla.sf.frob.com> References: <20050709204243.1FA60230048@magilla.sf.frob.com> Message-ID: <1120941992.22153.13.camel@cutter> On Sat, 2005-07-09 at 13:42 -0700, Roland McGrath wrote: > > it depends - is there an api break from 3.1 to 3.2? > > I really don't know anything about it. I can look at the diffs. > But I need knowledgeable users of sqlite to say what the effects might be. > > i've not tried 3.2.2 but from the look of the changelog http://sqlite.org/changes.html no massive api-breaking changes have occurred. give it a try on a couple of systems and see what breaks. -sv From ivazquez at ivazquez.net Sat Jul 9 20:48:35 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 09 Jul 2005 16:48:35 -0400 Subject: sqlite In-Reply-To: <20050709203452.A5D50230048@magilla.sf.frob.com> References: <20050709203452.A5D50230048@magilla.sf.frob.com> Message-ID: <1120942115.9522.45.camel@ignacio.lan> On Sat, 2005-07-09 at 13:34 -0700, Roland McGrath wrote: > So, I amend my question. Would all those things (looks like all stuff > using it for rpm purposes, plus net-snmp) survive the upgrade? Does it have the same ABI and SONAME? -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Sat Jul 9 20:48:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jul 2005 16:48:31 -0400 Subject: sqlite In-Reply-To: <1120941992.22153.13.camel@cutter> References: <20050709204243.1FA60230048@magilla.sf.frob.com> <1120941992.22153.13.camel@cutter> Message-ID: <604aa791050709134857228514@mail.gmail.com> On 7/9/05, seth vidal wrote: > no massive api-breaking changes have occurred. > > give it a try on a couple of systems and see what breaks. And please god... if you are going to roll updates for fc3 and fc4... do a test update and let sit in testing for a week if you can. -jef From roland at redhat.com Sat Jul 9 20:51:01 2005 From: roland at redhat.com (Roland McGrath) Date: Sat, 9 Jul 2005 13:51:01 -0700 (PDT) Subject: sqlite In-Reply-To: Ignacio Vazquez-Abrams's message of Saturday, 9 July 2005 16:48:35 -0400 <1120942115.9522.45.camel@ignacio.lan> Message-ID: <20050709205101.DAA94230048@magilla.sf.frob.com> > Does it have the same ABI and SONAME? It looks like it does. It has some additional entry points, but didn't change the soname (and doesn't use symbol versioning). Nothing else in the exported header file changed. Thanks, Roland From roland at redhat.com Sat Jul 9 20:54:40 2005 From: roland at redhat.com (Roland McGrath) Date: Sat, 9 Jul 2005 13:54:40 -0700 (PDT) Subject: sqlite In-Reply-To: Jeff Spaleta's message of Saturday, 9 July 2005 16:48:31 -0400 <604aa791050709134857228514@mail.gmail.com> Message-ID: <20050709205440.AE45C230048@magilla.sf.frob.com> > And please god... if you are going to roll updates for fc3 and fc4... > do a test update and let sit in testing for a week if you can. I can't see any rationale for changing this in released versions. I was only proposing this for FC5. It's just an upstream version bump for its own sake. (Actually my motivation is to have the current version available for other packages in extras to be able to buildrequire. In particular the latest monotone uses sqlite 3.2.2 and can't use the system 3.1.2 one, so builds its own private copy of 3.2.2 on existing systems.) There are bug fixes mentioned in the sqlite change log, but I have no particular reason to suspect that any of our uses of sqlite have been bitten by any of the bugs that have been fixed. From jspaleta at gmail.com Sat Jul 9 21:07:24 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 9 Jul 2005 17:07:24 -0400 Subject: sqlite In-Reply-To: <20050709205440.AE45C230048@magilla.sf.frob.com> References: <604aa791050709134857228514@mail.gmail.com> <20050709205440.AE45C230048@magilla.sf.frob.com> Message-ID: <604aa791050709140771770ebf@mail.gmail.com> On 7/9/05, Roland McGrath wrote: > I can't see any rationale for changing this in released versions. I was > only proposing this for FC5. Oh well... if its just for fc5... i say batten down the hatches and lauch the torpedos. I'm sure if you sink someone's development box.. you'll hear about it. -jef From roland at redhat.com Sat Jul 9 21:25:21 2005 From: roland at redhat.com (Roland McGrath) Date: Sat, 9 Jul 2005 14:25:21 -0700 (PDT) Subject: sqlite In-Reply-To: Jeff Spaleta's message of Saturday, 9 July 2005 17:07:24 -0400 <604aa791050709140771770ebf@mail.gmail.com> Message-ID: <20050709212521.3E5AF230048@magilla.sf.frob.com> > Oh well... if its just for fc5... i say batten down the hatches and > lauch the torpedos. > I'm sure if you sink someone's development box.. you'll hear about it. Well, I'm not going to commit anything before waiting to hear about there being a maintainer, and from the rpm maintainers, who might answer on Monday. I tried it on my rawhide box, and yum still seems to work unchanged with it installed. I haven't done much more to test it. In particular, I haven't rebuilt anything that requires sqlite-devel. Does anyone know why the sqlite-tcl subpackage got dropped? I don't care about the package, but enabling the tcl stuff in the build make it possible to run the upstream test suite in %check (which I've done and it passed). You can tweak %define tcl 0 to 1 in my sqlite.spec file to try that. Those interested can try my new build from: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: roland.repo URL: From sopwith at redhat.com Mon Jul 11 19:53:29 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 11 Jul 2005 15:53:29 -0400 (EDT) Subject: Extras Bugzilla change Message-ID: Hi all, Just a note to let you know that the bugzilla-related items for Fedora Extras (components, component owners, etc.) should now be edited via checkins to the 'owners.list' file in the 'owners' module of /cvs/extras. The http://fedoraproject.org/wiki/Extras/BugzillaAdmin process is now obsolete. Please let me know if you have any questions. Best, -- Elliot From ivazquez at ivazquez.net Mon Jul 11 22:48:54 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 11 Jul 2005 18:48:54 -0400 Subject: Extras Bugzilla change In-Reply-To: References: Message-ID: <1121122134.4423.5.camel@ignacio.lan> On Mon, 2005-07-11 at 15:53 -0400, Elliot Lee wrote: > Please let me know if you have any questions. Just three. 1) How long until changes take effect? 2) What format should the initialcclist field be in? 3) Should all entries have "extras-qa at ..." in initialqalist? (Some are missing that) -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Tue Jul 12 05:51:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 12 Jul 2005 01:51:54 -0400 Subject: buildsys update information Message-ID: <1121147515.10435.35.camel@cutter> Hi Everyone, Wanted to give you a heads up on the build system status. Right now it is still down. We've run into a snag where it seems like python on x86_64 or ppc on FC4 is not playing nicely with the threading and pyOpenSSL use by the buildsys code. I'm going to testing this theory on a 'spare' machine tomorrow and if it works out punting the build system boxes back to FC3 or RHEL4 for our use. After that it should be all gravy and sunshine.(hah hah) Sorry for the delay in getting things back up and running and please bear with us. When the new system comes up you, as developers and submitters of jobs, will have to add a couple of new files to your homedirs so you can submit jobs. We'll be writing up where to get these files and what to do with them once we have everything online. Again, sorry for the hassle. It'll all be over soon and then you'll have a whole new set of things to complain about! :) -sv From wtogami at redhat.com Tue Jul 12 06:13:21 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 11 Jul 2005 20:13:21 -1000 Subject: Package umask issues In-Reply-To: <20050709102339.GA13808@dudweiler.stuttgart.redhat.com> References: <42CEFF2D.2010101@redhat.com> <20050708234721.GC2900@amilo> <20050709102339.GA13808@dudweiler.stuttgart.redhat.com> Message-ID: <42D35F81.4010407@redhat.com> Florian La Roche wrote: > On Sat, Jul 09, 2005 at 01:47:21AM +0200, Miloslav Trmac wrote: > >>On Fri, Jul 08, 2005 at 12:33:17PM -1000, Warren Togami wrote: >> >>>This is only an issue for sysadmins when >>>they insist on using a system umask of 077 supposedly for some hardening >>>reason. >> >>Would it be too daring to suggest that this would be easiest to fix >>in rpm by forcing umask to 022 before extracting files or running scripts? > > > Yes, this should be set in rpm. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163003 Filed for consideration in future FC rpm releases https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=163004 Cloned for RHEL update consideration Warren Togami wtogami at redhat.com From mharris at www.linux.org.uk Tue Jul 12 09:48:45 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Tue, 12 Jul 2005 05:48:45 -0400 Subject: Package umask issues In-Reply-To: <42CEFF2D.2010101@redhat.com> References: <42CEFF2D.2010101@redhat.com> Message-ID: <42D391FD.1040403@www.linux.org.uk> Warren Togami wrote: > Hi Spot, > > During FUDCON2 one of the TODO's I promised you was to send details > about package umask issues. This is only an issue for sysadmins when > they insist on using a system umask of 077 supposedly for some hardening > reason. Two kinds of packages then have problems: > > 1) Packages with unowned files or directories. This of course has an > obvious solution, simply own it. This is already covered in our > packaging guidelines. MUST right? > > 2) Packages which create unpackaged files in scriptlets like %post > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136030 > This is one example where this caused a problem. The quick and ugly > workaround is to explicitly set umask at the beginning of the scriptlet. > But the correct fix would be to make it so the software does not create > files in %post. The latter solution is not always trivial. > > Should we make #2 a SHOULD or MUST in guidelines? Fonts intended to be useable systemwide by all users, must get installed on the system with read mode set for user, group, and other, at a minimum. In order for these fonts to then be useable by the X11 core fonts subsystem (legacy font support, mostly used by Xt/Xaw apps and other old stuff), the font metadata files (fonts.dir, fonts.scale, fonts.alias) must also be world readable (generally mode 0644 is preferred). Any font package that installs fonts and prepares them for use by the core fonts system, by calling chkfontpath, ttmkfdir/mkfontscale, mkfontdir, must be invoked in an environment which has umask set to 0133 to ensure the metadata files are created with the proper permissions to be seen by all users. Of course this assumes that the intention of a given rpm is to make the fonts useable systemwide, and not limited to a specific user or group, etc. Previously we used to patch mkfontdir to force fonts.dir and encodings.dir metadata files to be mode 0644, however XFree86.org rejected the patch, so I dropped it in the next OS release and changed the initscript for xfs to force "umask 0133" instead, however that only works if all font packages correctly set the umask upon installation as well. It's been ages since I've seen any bug reports of the nature of fonts missing which could be traced to improper font installation permissions however, so this may not be a huge problem nowadays simply out of coincidence or luck. Nonetheless, I thought I'd mention it in the thread upon request of Warren. TTYL From pnasrat at redhat.com Wed Jul 13 19:46:43 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 13 Jul 2005 15:46:43 -0400 Subject: sqlite In-Reply-To: <20050709202840.D24BB230048@magilla.sf.frob.com> References: <20050709202840.D24BB230048@magilla.sf.frob.com> Message-ID: <1121284004.3121.14.camel@enki.eridu> On Sat, 2005-07-09 at 13:28 -0700, Roland McGrath wrote: > AFAICT, the only reason sqlite is in Core rather than Extras is that rpm > uses it. (rpm doesn't tell me about any other dependencies on an > Everything install.) The package seems to be abandoned, as far as a > maintainer. Is that accurate? Would rpm survive an upgrade of sqlite to > the current version, 3.2.2? I don't think it's going to be too much of an issue, the sqlite rpmdb is not in common use in Fedora - Montavista are using it quite extensively, I've spoken with Mark Hatle there and he hasn't tested yet, jbj seems to have with external so I don't think we should expect any huge suprises. Paul From roland at redhat.com Wed Jul 13 19:51:00 2005 From: roland at redhat.com (Roland McGrath) Date: Wed, 13 Jul 2005 12:51:00 -0700 (PDT) Subject: sqlite In-Reply-To: Paul Nasrat's message of Wednesday, 13 July 2005 15:46:43 -0400 <1121284004.3121.14.camel@enki.eridu> Message-ID: <20050713195100.434361809FC@magilla.sf.frob.com> > I don't think it's going to be too much of an issue, the sqlite rpmdb is > not in common use in Fedora - Montavista are using it quite extensively, > I've spoken with Mark Hatle there and he hasn't tested yet, jbj seems to > have with external so I don't think we should expect any huge suprises. So, is there anyone like a maintainer for the sqlite package? If I do this upgrade, will it be me? The new upstream version builds out of the box, so updating the rawhide rpm is easy. But I don't ever want to think about what sqlite does. From notting at redhat.com Thu Jul 14 04:12:13 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 14 Jul 2005 00:12:13 -0400 Subject: PCMCIA & udev changes Message-ID: <20050714041213.GA905@nostromo.devel.redhat.com> Beginning tomorrow, the following changes will be in rawhide: - pcmcia-cs will be replaced with the new pcmciautils - udev will be upgraded to 062 What does this mean for you, the user? - PCMCIA support should be better. Notably, 16-bit PCMCIA support will be going through the same hotplug, etc. mechanisms as Cardbus, PCI, and other devices. - Certain operations should be faster. The new udev internalizes some of the mechanisms that were farmed out to scripts before (such as loading of modules for PCI, PCMCIA/Cardbus, and USB), so things should be faster. What does this mean for you, the developer? - The use of /etc/hotplug.d and /etc/dev.d for the running of programs on hotplug and udev events is officially deprecated. All programs that have been run in this way need to be converted to RUN targets in udev rule files; these can be dropped in /etc/udev/rules.d. Old dev.d and hotplug.d events will still be run in a compatibility mode for now... I'm not yet sure how long we will continue to do so. What sort of problems could arise, and where should they be filed? - All matching of of PCMCIA devices to drivers is done via standard module aliases. /etc/pcmcia/config is no longer used. If your driver isn't loaded properly, bugs should be filed against 'kernel'; ids will need to be added to the drivers. - Not everything may be converted to new udev rules yet. For things that aren't, please file bugs against the relevant packages. And, of course, there could be something that's just plain broken. :) This isn't going to be the last device handling change; these changes allow further tweaks to udev, hotplug, and related packages. Hopefully nothing will break too badly along the way. Bill From petersen at redhat.com Thu Jul 14 04:31:43 2005 From: petersen at redhat.com (Jens Petersen) Date: Thu, 14 Jul 2005 13:31:43 +0900 Subject: incoming: dependency warnings In-Reply-To: <20050621173000.GA9969@nostromo.devel.redhat.com> References: <20050621170058.GA9231@nostromo.devel.redhat.com> <1119374751.24920.20.camel@opus.phy.duke.edu> <20050621173000.GA9969@nostromo.devel.redhat.com> Message-ID: <42D5EAAF.4010703@redhat.com> Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > >>And you'll be sending a general report to the -devel list for everyone >>to see, right? > > > With this change, general 'these deps are broken' notes should be in > the normal rawhide mail. Would it be better to send it out as a separate mail from the daily rawhide report? Either that or perhaps restrict the deps report in the daily rawhide mail to a single arch during the early part of the devel cycle? Currently it seems more to be bloating the daily rawhide mail IMHO and a lot of the broken deps are duplicated across archs anyway. Jens From skvidal at phy.duke.edu Thu Jul 14 06:59:15 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Jul 2005 02:59:15 -0400 Subject: buildsys status report Message-ID: <1121324355.13861.18.camel@cutter> Hi All, Dan is the man and he has made it possible for things to work - and on smp processors even! :) Long and short successful package builds have occurred. It's like heaven on a sunday. It's sugar and spice. It's all things nice. Heck, I'll even throw in snails and puppy dog tails if that's your kink. Anyway - to do some more testing I'm going to push all the stuff in tobuild through the system and see what comes out the other side. The next steps: 1. get a list of all the extras committers/maintainers from Elliot and push them into the plague authN db. 2. write up the brief 'how do I use this' docs - this includes some info about certs and other items you'll need. 3. see if Dan is game for putting a version of plague IN extras so you, the developer, can install plague-client. 4. modify make build so it ends up calling plague-client 5. work on getting a webpage status report dump from the buildsys. 6. add new doodads and fix broken doodads. Sound like a passel of fun? I certainly hope so. -sv From ivazquez at ivazquez.net Thu Jul 14 07:07:09 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 14 Jul 2005 03:07:09 -0400 Subject: buildsys status report In-Reply-To: <1121324355.13861.18.camel@cutter> References: <1121324355.13861.18.camel@cutter> Message-ID: <1121324829.6290.9.camel@ignacio.lan> On Thu, 2005-07-14 at 02:59 -0400, seth vidal wrote: > Hi All, > Dan is the man and he has made it possible for things to work - and on > smp processors even! :) Long and short successful package builds have > occurred. It's like heaven on a sunday. It's sugar and spice. It's all > things nice. Heck, I'll even throw in snails and puppy dog tails if > that's your kink. What, no snips? Ah well, a job well done by both of you regardless ;) -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Thu Jul 14 07:09:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 14 Jul 2005 03:09:06 -0400 Subject: buildsys status report In-Reply-To: <1121324829.6290.9.camel@ignacio.lan> References: <1121324355.13861.18.camel@cutter> <1121324829.6290.9.camel@ignacio.lan> Message-ID: <1121324946.13861.19.camel@cutter> On Thu, 2005-07-14 at 03:07 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2005-07-14 at 02:59 -0400, seth vidal wrote: > > Hi All, > > Dan is the man and he has made it possible for things to work - and on > > smp processors even! :) Long and short successful package builds have > > occurred. It's like heaven on a sunday. It's sugar and spice. It's all > > things nice. Heck, I'll even throw in snails and puppy dog tails if > > that's your kink. > > What, no snips? Ah well, a job well done by both of you regardless ;) Give Dan the credit. I just break stuff. -sv From jwboyer at jdub.homelinux.org Thu Jul 14 11:52:59 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 14 Jul 2005 06:52:59 -0500 Subject: buildsys status report In-Reply-To: <1121324355.13861.18.camel@cutter> References: <1121324355.13861.18.camel@cutter> Message-ID: <1121341980.2685.38.camel@yoda.jdub.homelinux.org> On Thu, 2005-07-14 at 02:59 -0400, seth vidal wrote: > Hi All, > Dan is the man and he has made it possible for things to work - and on > smp processors even! :) Long and short successful package builds have > occurred. It's like heaven on a sunday. It's sugar and spice. It's all > things nice. Heck, I'll even throw in snails and puppy dog tails if > that's your kink. > Awesome! > Anyway - to do some more testing I'm going to push all the stuff in > tobuild through the system and see what comes out the other side. > > The next steps: > 1. get a list of all the extras committers/maintainers from Elliot and > push them into the plague authN db. > 2. write up the brief 'how do I use this' docs - this includes some > info about certs and other items you'll need. > 3. see if Dan is game for putting a version of plague IN extras so you, > the developer, can install plague-client. > 4. modify make build so it ends up calling plague-client > 5. work on getting a webpage status report dump from the buildsys. > 6. add new doodads and fix broken doodads. Any chance we could have: 7. release an Extras RPM update for the latest and greatest mock stuff It's been a while since that was updated... josh From jspaleta at gmail.com Thu Jul 14 13:53:22 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 14 Jul 2005 09:53:22 -0400 Subject: incoming: dependency warnings In-Reply-To: <42D5EAAF.4010703@redhat.com> References: <20050621170058.GA9231@nostromo.devel.redhat.com> <1119374751.24920.20.camel@opus.phy.duke.edu> <20050621173000.GA9969@nostromo.devel.redhat.com> <42D5EAAF.4010703@redhat.com> Message-ID: <604aa791050714065347c23c40@mail.gmail.com> On 7/14/05, Jens Petersen wrote: > Would it be better to send it out as a separate mail from the daily > rawhide report? Either that or perhaps restrict the deps report in > the daily rawhide mail to a single arch during the early part of the devel > cycle? Currently it seems more to be bloating the daily rawhide mail > IMHO and a lot of the broken deps are duplicated across archs anyway. What about looking into re-organizing the output so that dep problems that exist across all arches show up in a common block, then after that dep specific variations show up? Would that solve most of the issues you have with the report bloat? It's to early to tell for sure, but having the information available in the report sure has seemed to cut down on the avalanche of mailinglist posts about the same broken tree deps from people eating rawhide. I'd hate to turn off ppc and x86-64 from the report and encourage people to start posting redundantly again asking for other to confirm arch specific dep problems. Is the script that generates that report open for review and patching? 'someone' might be able to patch the script to produce a common block of dep problems to bloat if this approach is worth attempting. -jef From dcbw at redhat.com Thu Jul 14 14:13:16 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 14 Jul 2005 10:13:16 -0400 Subject: buildsys status report In-Reply-To: <1121324946.13861.19.camel@cutter> References: <1121324355.13861.18.camel@cutter> <1121324829.6290.9.camel@ignacio.lan> <1121324946.13861.19.camel@cutter> Message-ID: <1121350396.14067.3.camel@dcbw.boston.redhat.com> On Thu, 2005-07-14 at 03:09 -0400, seth vidal wrote: > On Thu, 2005-07-14 at 03:07 -0400, Ignacio Vazquez-Abrams wrote: > > On Thu, 2005-07-14 at 02:59 -0400, seth vidal wrote: > > > Hi All, > > > Dan is the man and he has made it possible for things to work - and on > > > smp processors even! :) Long and short successful package builds have > > > occurred. It's like heaven on a sunday. It's sugar and spice. It's all > > > things nice. Heck, I'll even throw in snails and puppy dog tails if > > > that's your kink. > > > > What, no snips? Ah well, a job well done by both of you regardless ;) > > Give Dan the credit. I just break stuff. Would have been 1000 harder without mock and the other infrastructure Seth has done. Dan From fedora at camperquake.de Thu Jul 14 14:20:05 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 14 Jul 2005 16:20:05 +0200 Subject: buildsys status report In-Reply-To: <1121350396.14067.3.camel@dcbw.boston.redhat.com> References: <1121324355.13861.18.camel@cutter> <1121324829.6290.9.camel@ignacio.lan> <1121324946.13861.19.camel@cutter> <1121350396.14067.3.camel@dcbw.boston.redhat.com> Message-ID: <20050714162005.228a3ff5@nausicaa.camperquake.de> Hi. Dan Williams wrote: > > Give Dan the credit. I just break stuff. > > Would have been 1000 harder without mock and the other infrastructure > Seth has done. OK, let's face it. You two rock. -- You can always tell a good idea by the enemies it makes. -- programmer's axiom From oliver at linux-kernel.at Thu Jul 14 14:24:36 2005 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 14 Jul 2005 16:24:36 +0200 Subject: buildsys status report In-Reply-To: <20050714162005.228a3ff5@nausicaa.camperquake.de> References: <1121324355.13861.18.camel@cutter> <1121324829.6290.9.camel@ignacio.lan> <1121324946.13861.19.camel@cutter> <1121350396.14067.3.camel@dcbw.boston.redhat.com> <20050714162005.228a3ff5@nausicaa.camperquake.de> Message-ID: <42D675A4.2060607@linux-kernel.at> On 07/14/2005 04:20 PM, Ralf Ertzinger wrote: > Hi. > > Dan Williams wrote: > > >>>Give Dan the credit. I just break stuff. >> >>Would have been 1000 harder without mock and the other infrastructure >>Seth has done. > > OK, let's face it. You two rock. Or: Together you are unbeatable. :-) Best, Oliver From notting at redhat.com Thu Jul 14 16:28:22 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 14 Jul 2005 12:28:22 -0400 Subject: incoming: dependency warnings In-Reply-To: <604aa791050714065347c23c40@mail.gmail.com> References: <20050621170058.GA9231@nostromo.devel.redhat.com> <1119374751.24920.20.camel@opus.phy.duke.edu> <20050621173000.GA9969@nostromo.devel.redhat.com> <42D5EAAF.4010703@redhat.com> <604aa791050714065347c23c40@mail.gmail.com> Message-ID: <20050714162822.GF18422@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > Is the script that generates that report open for review and patching? > 'someone' might be able to patch the script to produce a common block > of dep problems to bloat if this approach is worth attempting. I'd suspect the initial problem with coalescing them is that the deps can be different per-arch (64bit or not). Bill -------------- next part -------------- #!/usr/bin/python import os from stat import * import sys import tempfile import pwd import re import string import glob import yum from yum.constants import * sys.path.append("/usr/bin/") import repoclosure arches = [] owners = {} deps = {} dbh = None cspec = None tmpdir = '/var/tmp' def generateConfig(theDir): for entry in os.listdir(theDir): try: if 'repodata' in os.listdir("%s/%s" % (theDir,entry)): arches.append(entry) except: pass try: (fd, conffile) = tempfile.mkstemp() except: conffile = tempfile.mktemp() fd = os.open(conffile,os.O_RDWR|os.O_CREAT) confheader = """ [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=fedora-release reposdir=/dev/null """ os.write(fd,confheader) for arch in arches: repo = """ [development-%s] name=Fedora Core Development Tree - %s baseurl=file://%s/%s enabled=1 """ % (arch, arch, theDir, arch) os.write(fd,repo) os.close(fd) return conffile def libmunge(match): if match.groups()[1].isdigit(): return "%s%d" % (match.groups()[0],int(match.groups()[1])+1) else: return "%s%s" % (match.groups()[0],match.groups()[1]) def getCacheDir(): uid = os.geteuid() try: usertup = pwd.getpwuid(uid) username = usertup[0] except KeyError: return None # if it returns None then, well, it's bollocksed prefix = 'yum-%s-' % username dirpath = '%s/%s*' % (tmpdir, prefix) cachedirs = glob.glob(dirpath) for thisdir in cachedirs: # if one exists take the first one # check if it is: # 0. is a dir if not os.path.isdir(thisdir): continue stats = os.stat(thisdir) # 1. owned by the user if stats[4] != uid: continue # 2. 0700 if S_IMODE(stats[0]) != 448: continue # it made it through the gauntlet! return thisdir if 'mkdtemp' in dir(tempfile): cachedir = tempfile.mkdtemp(prefix=prefix, dir=tmpdir) else: tempfile.tempdir = tmpdir tempfile.template = prefix cachedir = tempfile.mktemp() try: os.mkdir(cachedir,0700) except: cachedir = None return cachedir def addOwner(list, pkg): if list.has_key(pkg): return True f = getOwner(pkg) if f: list[pkg] = f return True return False def getSrcPkg(pkg): srpm = pkg.returnSimple('sourcerpm') if not srpm: return None srcpkg = string.join(srpm.split('-')[:-2],'-') return srcpkg def printableReq(pkg, dep): (n, f, v) = dep req = '%s' % n if f: flag = LETTERFLAGS[f] req = '%s %s' % (req, flag) if v: req = '%s %s' % (req, v) return "%s requires %s" % (pkg, req,) def assignBlame(resolver, dep, guilty): # Given a dep, find potential responsible parties list = [] # The dep itself if addOwner(guilty, dep): list.append(dep) # Something that provides the dep try: sack = resolver.whatProvides(dep, None, None) for package in sack.returnPackages(): p = getSrcPkg(package) if addOwner(guilty, p): list.append(p) except yum.Errors.RepoError, e: pass # Libraries: check for variant in soname if re.match("lib*\.so\.[0-9]+",dep): new = re.sub("(lib.*\.so\.)([0-9])+",libmunge,1) try: sack = resolver.whatProvides(new, None, None) for package in sack.returnPackages(): p = getSrcPkg(package) if addOwner(guilty, p): list.append(p) except yum.Errors.RepoError, e: pass return list def generateSpam(pkgname, sendmail = True): package = deps[pkgname] guilty = owners[pkgname] conspirators = [] for s in package.keys(): subpackage = package[s] for arch in subpackage.keys(): brokendeps = subpackage[arch] for dep in brokendeps: for blame in dep[2]: party = owners[blame] if party != guilty and party not in conspirators: conspirators.append(party) foo = """ %s has broken dependencies in the development tree: """ % (pkgname,) for s in package.keys(): subpackage = package[s] for arch in subpackage.keys(): foo = foo + "On %s:\n" % (arch) brokendeps = subpackage[arch] for dep in brokendeps: foo = foo + "\t%s\n" % printableReq(dep[0],dep[1]) foo = foo + "Please resolve this as soon as possible.\n\n" command = '/bin/mail -s "Broken dependencies: %s" %s' % (pkgname, guilty) if conspirators: command = command + " -c %s" % (string.join(conspirators,","),) if sendmail: mailer = os.popen(command, 'w') mailer.write(foo) mailer.close() else: print """ To: %s Cc: %s Subject: Broken dependencies: %s """ % (guilty, string.join(conspirators,','), pkgname) print foo def doit(args): conffile = generateConfig(args[0]) mail = True if len(args) > 1: mail = False cachedir = getCacheDir() for arch in arches: if arch == 'i386': carch = 'i686' else: carch = arch repoid = 'development-%s' % (arch,) my = repoclosure.RepoClosure(config = conffile, arch = carch) for repo in my.repos.repos.values(): repo.cachedir = '%s/%s' % (cachedir,repo.id) repo.hdrdir = '%s/%s/headers' % (cachedir, repo.id) repo.pkgdir = '%s/%s/packages' % (cachedir, repo.id) if repo.id != repoid: repo.disable() else: repo.enable() my.readMetadata() baddeps = my.getBrokenDeps() pkgs = baddeps.keys() pkgs.sort() if len(pkgs) > 0: print "Broken deps for %s" % (arch,) print "----------------------------------------------------------" for pkg in pkgs: srcpkg = getSrcPkg(pkg) addOwner(owners, srcpkg) if not deps.has_key(srcpkg): deps[srcpkg] = {} pkgid = pkg.returnNevraPrintable() if not deps[srcpkg].has_key(pkgid): deps[srcpkg][pkgid] = {} broken = [] for (n, f, v) in baddeps[pkg]: print "\t%s" % printableReq(pkg, (n, f, v)) blamelist = assignBlame(my, n, owners) broken.append( (pkg, (n, f, v), blamelist) ) deps[srcpkg][pkgid][arch] = broken print "\n\n" pkglist = deps.keys() for pkg in pkglist: generateSpam(pkg, mail) os.unlink(conffile) if __name__ == '__main__': if len(sys.argv) > 1: doit(sys.argv[1:]) else: print "usage: spam-o-matic " From wtogami at redhat.com Thu Jul 14 20:30:23 2005 From: wtogami at redhat.com (Warren Togami) Date: Thu, 14 Jul 2005 10:30:23 -1000 Subject: fedora-rpmdevtools imported into /cvs/fedora Message-ID: <42D6CB5F.5030400@redhat.com> http://cvs.fedora.redhat.com/viewcvs/fedora-rpmdevtools/?root=fedora Just FYI, please maintain this software here instead. Anything else important remaining at the old CVS at cvs.fedora.us? I want to shut it down at some point in the near future. Warren Togami wtogami at redhat.com From roland at redhat.com Fri Jul 15 00:00:26 2005 From: roland at redhat.com (Roland McGrath) Date: Thu, 14 Jul 2005 17:00:26 -0700 (PDT) Subject: sqlite Message-ID: <20050715000026.4F8AB1809FC@magilla.sf.frob.com> I've built the new sqlite (3.2.2) in dist-fc5. Maintainers of rpm, yum, et al, please watch for issues on your next rebuild. Thanks, Roland From skvidal at phy.duke.edu Fri Jul 15 12:48:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 15 Jul 2005 08:48:13 -0400 Subject: buildsystem test results Message-ID: <1121431694.22260.55.camel@cutter> Hi Folks, I pushed all the packages that were in tobuild back through the new buildsystem last night. Here are the packages that caused a problem: moodss: (all) Whoever checked in the last changes forgot to upload the tarball. scim-anthy: (ppc) http://buildsys.fedoraproject.org/logs//4/21-scim-anthy-0.5.1-1.fc4/ scim: (x86_64) http://buildsys.fedoraproject.org/logs//devel/23-scim-1.3.3-1.fc5/ barcode: (x86_64) http://buildsys.fedoraproject.org/logs//devel/25-barcode-0.98-6.fc5/ gkrellm-freq: (ppc) http://buildsys.fedoraproject.org/logs//devel/46-gkrellm-freq-0.1.1-1.fc5/ Take a look at the build.log and let me know if the failure reason seems more like the fault of the buildsys or more like just a packaging/code issue. Somethings to keep in mind: 1. we're drawing from a normal rawhide mirror so it should be newest or nearly newest rawhide. (within 1 day of current) 2. the x86_64 chroots has i386, i686, athlon, i586, and i486 excluded from its trees. So you should not see any of those conflicts anymore. 3. everything is being built in mock so it should operate for builds just like it would on your local system. 4. there are still some packages building and I'll report any other failures as I find them. thanks, -sv From dwmw2 at infradead.org Fri Jul 15 13:04:39 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 Jul 2005 14:04:39 +0100 Subject: buildsystem test results In-Reply-To: <1121431694.22260.55.camel@cutter> References: <1121431694.22260.55.camel@cutter> Message-ID: <1121432679.16070.104.camel@hades.cambridge.redhat.com> On Fri, 2005-07-15 at 08:48 -0400, seth vidal wrote: > scim-anthy: (ppc) > http://buildsys.fedoraproject.org/logs//4/21-scim-anthy-0.5.1-1.fc4/ Failed download? + /usr/bin/gzip -dc /builddir/build/SOURCES/scim-anthy-0.5.1.tar.gz + tar -xf - gzip: /builddir/build/SOURCES/scim-anthy-0.5.1.tar.gz: unexpected end of file tar: Read 4307 bytes from - tar: Unexpected EOF in archive tar: Unexpected EOF in archive > gkrellm-freq: (ppc) > http://buildsys.fedoraproject.org/logs//devel/46-gkrellm-freq-0.1.1-1.fc5/ Bogus use of asm in the rdtsc() function (which doesn't even seem to be used, afaict). -- dwmw2 From andreas at bawue.net Fri Jul 15 13:45:21 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Fri, 15 Jul 2005 15:45:21 +0200 (CEST) Subject: buildsystem test results In-Reply-To: <1121431694.22260.55.camel@cutter> References: <1121431694.22260.55.camel@cutter> Message-ID: On Fri, 15 Jul 2005, seth vidal wrote: > barcode: (x86_64) > http://buildsys.fedoraproject.org/logs//devel/25-barcode-0.98-6.fc5/ Even though Oliver thinks this might be a package problem, I am not so sure. I just rebuilt that package in mock-0.3.2 on a x86_64 successfully. The package, plus the logs are at http://home.bawue.net/~ixs/barcode/devel/ It looks to me as if the tex you're having is a bit different than the one I get: Excerpt from my log: tex barcode.texinfo This is TeX, Version 3.141592 (Web2C 7.5.4) (./barcode.texinfo (/usr/share/texmf/tex/texinfo/texinfo.tex Loading texinfo [version 2005-01-30.17]: Basics, pdf, fonts, page headings, tables, conditionals, indexing, sectioning, toc, environments, defuns, macros, cross references, insertions, (/usr/share/texmf/tex/generic/epsf/epsf.tex) localization, and turning on texinfo input format.) [1] (Barcode tools) Chapter 1 Chapter 2 [1] [2] Chapter 3 Cross reference values unknown; you must run TeX again. [3] Chapter 4 [4] Chapter 5 [5] [6] Chapter 6 [7] [8] Chapter 7 [9] Chapter 8 [10] (./barcode.toc ) [-1] ) Output written on barcode.dvi (12 pages, 44816 bytes). Your log: tex barcode.texinfo ar: creating libbarcode.a makeinfo barcode.texinfo -o barcode.info Any ideas? Judging by the root.log, the packages being installed are the same. bye, andreas From skvidal at phy.duke.edu Fri Jul 15 15:15:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 15 Jul 2005 11:15:41 -0400 Subject: More Build Errors Message-ID: <1121440541.26771.18.camel@cutter> gaim-meanwhile: (ppc) http://buildsys.fedoraproject.org/logs//4/63-gaim-meanwhile-1.2.4-1.fc4/ note the tar xvvf on a .tar.gz file. a number of build errors on rawhide are due to not-quite-synced repository. I'll resubmit those in a bit. -sv From jwboyer at jdub.homelinux.org Fri Jul 15 15:46:48 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 15 Jul 2005 10:46:48 -0500 (CDT) Subject: More Build Errors In-Reply-To: <1121440541.26771.18.camel@cutter> References: <1121440541.26771.18.camel@cutter> Message-ID: <38851.129.42.161.36.1121442408.squirrel@jdub.homelinux.org> > > gaim-meanwhile: (ppc) > http://buildsys.fedoraproject.org/logs//4/63-gaim-meanwhile-1.2.4-1.fc4/ > note the tar xvvf on a .tar.gz file. > Urm... that makes absolutely no sense. The spec file just uses the %setup and %configure macros, so I don't specify any tar options myself. Any ideas? josh From jwboyer at jdub.homelinux.org Fri Jul 15 18:25:33 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 15 Jul 2005 13:25:33 -0500 (CDT) Subject: More Build Errors In-Reply-To: <38851.129.42.161.36.1121442408.squirrel@jdub.homelinux.org> References: <1121440541.26771.18.camel@cutter> <38851.129.42.161.36.1121442408.squirrel@jdub.homelinux.org> Message-ID: <41139.129.42.161.36.1121451933.squirrel@jdub.homelinux.org> >> >> gaim-meanwhile: (ppc) >> http://buildsys.fedoraproject.org/logs//4/63-gaim-meanwhile-1.2.4-1.fc4/ >> note the tar xvvf on a .tar.gz file. >> > > Urm... that makes absolutely no sense. The spec file just uses the %setup > and %configure macros, so I don't specify any tar options myself. > > Any ideas? Ok, did some poking around and noticed that the sources file in CVS was wrong for the FC-3 and FC-4 branches. I've fixed that and I'll try a rebuild of all branches tonight. josh From pnasrat at redhat.com Fri Jul 15 19:18:55 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 15 Jul 2005 15:18:55 -0400 Subject: buildsystem test results In-Reply-To: <1121431694.22260.55.camel@cutter> References: <1121431694.22260.55.camel@cutter> Message-ID: <1121455135.6104.1.camel@enki.eridu> On Fri, 2005-07-15 at 08:48 -0400, seth vidal wrote: > Hi Folks, > I pushed all the packages that were in tobuild back through the new > buildsystem last night. Here are the packages that caused a problem: Hmm http://buildsys.fedoraproject.org/logs/devel/61-splint-3.1.1-9.fc5/ppc/root.log /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-ppc-core-f5a038c79be4e54f9990b33128bf26957e185fc3/root groupinstall build http://newmirror.linux.duke.edu/pub/fedora/linux/core/development/ppc/repodata/comps.xml: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/comps.xml from core: [Errno 256] No more mirrors to try. Cleaning up... Do I just need to make build again? Paul From petersen at redhat.com Sat Jul 16 03:18:30 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 16 Jul 2005 12:18:30 +0900 Subject: buildsystem test results In-Reply-To: <1121431694.22260.55.camel@cutter> References: <1121431694.22260.55.camel@cutter> Message-ID: <42D87C86.7080804@redhat.com> seth vidal wrote: > scim-anthy: (ppc) > http://buildsys.fedoraproject.org/logs//4/21-scim-anthy-0.5.1-1.fc4/ 22-scim-anthy-0.5.1-2.fc4 built fine. :) > scim: (x86_64) > http://buildsys.fedoraproject.org/logs//devel/23-scim-1.3.3-1.fc5/ Seems to be some problem related to cairo and C++. (Built fine the other day in the fc5 buildroot in the FC buildsystem though fwiw.) Thanks, Jens From petersen at redhat.com Sat Jul 16 03:43:46 2005 From: petersen at redhat.com (Jens Petersen) Date: Sat, 16 Jul 2005 12:43:46 +0900 Subject: buildsystem test results In-Reply-To: <42D87C86.7080804@redhat.com> References: <1121431694.22260.55.camel@cutter> <42D87C86.7080804@redhat.com> Message-ID: <42D88272.9090205@redhat.com> Jens Petersen wrote: >>scim: (x86_64) >>http://buildsys.fedoraproject.org/logs//devel/23-scim-1.3.3-1.fc5/ > > Seems to be some problem related to cairo and C++. > (Built fine the other day in the fc5 buildroot in the FC buildsystem though fwiw.) Erm, well not any more anyway... Jens From jaboutboul at fedoraproject.org Fri Jul 15 16:44:06 2005 From: jaboutboul at fedoraproject.org (Jack Aboutboul) Date: Fri, 15 Jul 2005 12:44:06 -0400 Subject: Join Fedora at LinuxWorld in San Francisco Message-ID: <1121445847.15274.47.camel@deepfort> The Fedora Project would like to invite you to join us at our booth at the LinuxWorld Conference and Expo taking place on August 8th through 11th, 2005 at the Moscone Convention Center in San Francisco, CA. All you need to do to get your free exhibit hall pass and join us is, either register online before August 8th with the priority code on the attached flyer, or download and print it out and bring it in on August 9th to 11th. At the show the Fedora Project will be hosting mini-sessions at our booth, located at section #2053 in the .org Pavilion, on a large variety of topics. Please check back at http://fedora.redhat.com for more information and a booth presentation schedule. In addition to that, all members of the Fedora community, users and developers alike are more than welcome to attend the Fedora Birds of a Feather session taking place on Tuesday August 9th, from 5:30-7:00PM local time, in the BoF session rooms. Hope to see you all at the show. -------------- next part -------------- A non-text attachment was scrubbed... Name: LWSF05ExpoPass2b.pdf Type: application/pdf Size: 264978 bytes Desc: not available URL: From ville.skytta at iki.fi Sun Jul 17 11:29:12 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 17 Jul 2005 14:29:12 +0300 Subject: fedora-rpmdevtools imported into /cvs/fedora In-Reply-To: <42D6CB5F.5030400@redhat.com> References: <42D6CB5F.5030400@redhat.com> Message-ID: <1121599752.2872.293.camel@localhost.localdomain> On Thu, 2005-07-14 at 10:30 -1000, Warren Togami wrote: > Just FYI, please maintain this software here instead. Anything else > important remaining at the old CVS at cvs.fedora.us? I want to shut it > down at some point in the near future. docs/packagers-handbook contains quite a bit of useful stuff, it'd be cool to have it hosted somewhere. I have a local backup of it. Other than that, I don't have anything that would need saving there. From petersen at redhat.com Fri Jul 22 14:28:28 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 22 Jul 2005 23:28:28 +0900 Subject: proposal to remove static libs from -devel packages for FC5 Message-ID: <42E1028C.20609@redhat.com> This has been in my mind for a while, but now I finally post it here: I believe we're still shipping many static libs in -devel not least in Core, which make our -devel packages rather heavy. I think the vast majority of them are not needed or used really at all. So they should just be removed. Some packages may have a --disable-static configure option for example to help with this, or they can just be deleted easily by hand in the %install section. For the cases where it is still desirable or necessary to ship static libs, I would suggest to move them from -devel into a separate -static subpackage so that people who don't need them don't have to suffer downloading and installing them. Does this sound reasonable? Make any sense? :) Comments and discussion welcome. What would be the best way to proceed? Filing bugs against every package that ships static libs? Jens From wtogami at redhat.com Sat Jul 23 06:08:17 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 22 Jul 2005 20:08:17 -1000 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E1028C.20609@redhat.com> References: <42E1028C.20609@redhat.com> Message-ID: <42E1DED1.9060803@redhat.com> Jens Petersen wrote: > This has been in my mind for a while, but now I finally post it here: > > I believe we're still shipping many static libs in -devel not least > in Core, which make our -devel packages rather heavy. I think the > vast majority of them are not needed or used really at all. > So they should just be removed. Some packages may have a --disable-static > configure option for example to help with this, or they can just be > deleted easily by hand in the %install section. > > For the cases where it is still desirable or necessary to ship static libs, > I would suggest to move them from -devel into a separate -static > subpackage so that people who don't need them don't have to suffer > downloading and installing them. > > Does this sound reasonable? Make any sense? :) > Comments and discussion welcome. What would be the best way to proceed? > Filing bugs against every package that ships static libs? > Furthermore would anyone be averse to the idea of making it policy to explicitly note in spec files when static libs are used in such a way that it is easy to do an automated search? Something simple like: # Static Lib: libfoo It is otherwise a huge PITA when a security hole is discovered and we need to sweep the entire distro for static copies, like the huge zlib mess we had a while back. The majority of cases though we want to try to eliminate use of static copies... Warren Togami wtogami at redhat.com From wtogami at redhat.com Sat Jul 23 11:20:24 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 23 Jul 2005 01:20:24 -1000 Subject: yum GPG verify and package sigs... Message-ID: <42E227F8.4060206@redhat.com> I just noticed that using yum's default FC4 configuration, it is seemingly impossible to install packages like docbook-utils which is signed by a different GPG key than the default specified to that repository in /etc/yum.repos.d/fedora.repo. I suppose this is partially my fault because I'm the last person to touch that repo file, but it is strange to me that I never noticed this problem until now. I *like* that yum enforces this strictly, but are there any good reasons why we should allow packages in a repo to be signed by two or more valid keys rather than a single key? Did we screw up by not resigning everything in base before pushing FC4, or is this really a yum config problem? Any ideas how we should fix this now? Should we resign the entire repo and push that to mirrors? Or maybe less radically update yum so the repo file allows both keys? (Use this as a one-time kludge for FC4, and in the future make sure each repo uses *one* key.) Warren Togami wtogami at redhat.com Demonstration of docbook-utils install failing: =============================================== Is this ok [y/N]: y Downloading Packages: warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID db42a60e public key not available for docbook-utils-0.6.14-4.noarch.rpm Retrieving GPG key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora The GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora (0x4F2A6FD2) is already installed but is not the correct key for this package. Check that this is the correct key for the "Fedora Core 4 - i386 - Base" repository. Some other examples in FC4 base signed by the older key, which seems to be packages built Sept 2004 and earlier. ======================================================== anaconda-help autoconf automake14 automake15 bitmap-fonts-cjk caching-nameserver crontabs docbook-simple docbook-slides docbook-utils-100dpi fonts-KOI8-R fonts-KOI8-R-75dpi ghostscript-fonts man-pages-cs Unscientific count of packages in FC4 base signed with this other key ===================================================================== rpm -qpi *.rpm |grep 219180cddb42a60e |wc -l 35 From mattdm at mattdm.org Sat Jul 23 13:49:29 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 23 Jul 2005 09:49:29 -0400 Subject: yum GPG verify and package sigs... In-Reply-To: <42E227F8.4060206@redhat.com> References: <42E227F8.4060206@redhat.com> Message-ID: <20050723134928.GA22421@jadzia.bu.edu> On Sat, Jul 23, 2005 at 01:20:24AM -1000, Warren Togami wrote: > I *like* that yum enforces this strictly, but are there any good reasons > why we should allow packages in a repo to be signed by two or more valid > keys rather than a single key? [...] > Did we screw up by not resigning everything in base before pushing FC4, > or is this really a yum config problem? > Any ideas how we should fix this now? Should we resign the entire repo > and push that to mirrors? [...] > Or maybe less radically update yum so the repo file allows both keys? > (Use this as a one-time kludge for FC4, and in the future make sure each > repo uses *one* key.) The very latest version of yum, 2.3.4, can handle multiple GPG keys. FC4 has 2.3.2; perhaps updating it is the easiest solution. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 78 degrees Fahrenheit. From skvidal at phy.duke.edu Sat Jul 23 15:25:15 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 23 Jul 2005 11:25:15 -0400 Subject: yum GPG verify and package sigs... In-Reply-To: <42E227F8.4060206@redhat.com> References: <42E227F8.4060206@redhat.com> Message-ID: <1122132315.12310.7.camel@cutter> On Sat, 2005-07-23 at 01:20 -1000, Warren Togami wrote: > I just noticed that using yum's default FC4 configuration, it is > seemingly impossible to install packages like docbook-utils which is > signed by a different GPG key than the default specified to that > repository in /etc/yum.repos.d/fedora.repo. I suppose this is partially > my fault because I'm the last person to touch that repo file, but it is > strange to me that I never noticed this problem until now. > > I *like* that yum enforces this strictly, but are there any good reasons > why we should allow packages in a repo to be signed by two or more valid > keys rather than a single key? > > Did we screw up by not resigning everything in base before pushing FC4, > or is this really a yum config problem? This is a screw up by not resigning everything. We've implemented support for multiple gpgkeys per-repo in yum 2.3.4 but fedora core should be signed with a single key. > Any ideas how we should fix this now? Should we resign the entire repo > and push that to mirrors? won't work - most mirrors don't re-sync core after the initial release. > Or maybe less radically update yum so the repo file allows both keys? > (Use this as a one-time kludge for FC4, and in the future make sure each > repo uses *one* key.) also won't work b/c a lot of people have modified their repo file. I'd recommend just not makin this mistake again. -sv From kaboom at oobleck.net Sat Jul 23 15:43:32 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sat, 23 Jul 2005 11:43:32 -0400 (EDT) Subject: yum GPG verify and package sigs... In-Reply-To: <42E227F8.4060206@redhat.com> References: <42E227F8.4060206@redhat.com> Message-ID: On Sat, 23 Jul 2005, Warren Togami wrote: > I just noticed that using yum's default FC4 configuration, it is seemingly > impossible to install packages like docbook-utils which is signed by a > different GPG key than the default specified to that repository in > /etc/yum.repos.d/fedora.repo. I suppose this is partially my fault because > I'm the last person to touch that repo file, but it is strange to me that I > never noticed this problem until now. > > I *like* that yum enforces this strictly, but are there any good reasons why > we should allow packages in a repo to be signed by two or more valid keys > rather than a single key? > > Did we screw up by not resigning everything in base before pushing FC4, or is > this really a yum config problem? > > Any ideas how we should fix this now? Should we resign the entire repo and > push that to mirrors? Either: * Don't do that again (not resign everything) next time * list multiple keys now that yum supports See also a whole slew of bugs in Bugzilla (160898, 161786, 162302, 162301, 160436, etc) caused by this later, chris From mattdm at mattdm.org Sat Jul 23 16:22:07 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 23 Jul 2005 12:22:07 -0400 Subject: yum GPG verify and package sigs... In-Reply-To: <1122132315.12310.7.camel@cutter> References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> Message-ID: <20050723162207.GA26475@jadzia.bu.edu> On Sat, Jul 23, 2005 at 11:25:15AM -0400, seth vidal wrote: > > Any ideas how we should fix this now? Should we resign the entire repo > > and push that to mirrors? > won't work - most mirrors don't re-sync core after the initial release. Yeah; it'd have to be done by releasing updates for each of the packges. (please don't do that). > > Or maybe less radically update yum so the repo file allows both keys? > > (Use this as a one-time kludge for FC4, and in the future make sure each > > repo uses *one* key.) > also won't work b/c a lot of people have modified their repo file. Yeah, but at least they'd get the .rpmnew file, and we'd have an easy suggestion for anyone who runs into the problem. > I'd recommend just not makin this mistake again. Always the best advice. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From jspaleta at gmail.com Sat Jul 23 16:27:30 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 23 Jul 2005 12:27:30 -0400 Subject: yum GPG verify and package sigs... In-Reply-To: <20050723162207.GA26475@jadzia.bu.edu> References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> <20050723162207.GA26475@jadzia.bu.edu> Message-ID: <604aa79105072309275f077296@mail.gmail.com> On 7/23/05, Matthew Miller wrote: > Yeah, but at least they'd get the .rpmnew file, and we'd have an easy > suggestion for anyone who runs into the problem. I have an easy suggestion right now. rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY* -jef From wtogami at redhat.com Sat Jul 23 21:38:36 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 23 Jul 2005 11:38:36 -1000 Subject: yum GPG verify and package sigs... In-Reply-To: <604aa79105072309275f077296@mail.gmail.com> References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> <20050723162207.GA26475@jadzia.bu.edu> <604aa79105072309275f077296@mail.gmail.com> Message-ID: <42E2B8DC.3090104@redhat.com> Jeff Spaleta wrote: > On 7/23/05, Matthew Miller wrote: > >>Yeah, but at least they'd get the .rpmnew file, and we'd have an easy >>suggestion for anyone who runs into the problem. > > > I have an easy suggestion right now. > > rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY* In case you missed the discussion, this does not solve the problem. Warren Togami wtogami at redhat.com From jspaleta at gmail.com Sat Jul 23 22:41:59 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 23 Jul 2005 18:41:59 -0400 Subject: yum GPG verify and package sigs... In-Reply-To: <42E2B8DC.3090104@redhat.com> References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> <20050723162207.GA26475@jadzia.bu.edu> <604aa79105072309275f077296@mail.gmail.com> <42E2B8DC.3090104@redhat.com> Message-ID: <604aa79105072315414a18e488@mail.gmail.com> On 7/23/05, Warren Togami wrote: > In case you missed the discussion, this does not solve the problem. Discussion where? I dont see anyone in the 5 posts before mine in this thread making a comment about importing all the provided keys.. fedora and redhat keys manully. I've run into this on #fedora and I have yet to see importing of all the provided keys fail to resolve the problem. But I'll run through this again from scratch on my fc4 desktop >rpm -e --allmatches gpg-pubkey >yum install docbook-utils ... Is this ok [y/N]: y Downloading Packages: warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID db42a60e public key not available for docbook-utils-0.6.14-4.noarch.rpm Retrieving GPG key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora Importing GPG key 0x4F2A6FD2 "Fedora Project " Is this ok [y/N]: y Key imported successfully Key import didn't help, wrong key? public key not available for docbook-utils-0.6.14-4.noarch.rpm >rpm -q gpg-pubkey gpg-pubkey-4f2a6fd2-3f9d9d3b > rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY* >rpm -q gpg-pubkey gpg-pubkey-4f2a6fd2-3f9d9d3b gpg-pubkey-db42a60e-37ea5438 gpg-pubkey-897da07a-3c979a7f gpg-pubkey-4f2a6fd2-3f9d9d3b gpg-pubkey-1ac70ce6-41bebeef gpg-pubkey-1cddbca9-3f9da14c gpg-pubkey-30c9ecf8-3f9da3f7 gpg-pubkey-a109b1ec-3f6e28d5 gpg-pubkey-e418e3aa-3f439953 >yum install docbook-utils ... Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: docbook-utils ######################### [1/1] Installed: docbook-utils.noarch 0:0.6.14-4 Complete! My workaround seems to workforme and for every user I've come across using the provided yum confs in fc4. The keys needed are provided by the fedora-release package.. you just need to manually import all of them. -jef From ivazquez at ivazquez.net Sun Jul 24 01:28:58 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 23 Jul 2005 21:28:58 -0400 Subject: yum GPG verify and package sigs... In-Reply-To: <604aa79105072315414a18e488@mail.gmail.com> References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> <20050723162207.GA26475@jadzia.bu.edu> <604aa79105072309275f077296@mail.gmail.com> <42E2B8DC.3090104@redhat.com> <604aa79105072315414a18e488@mail.gmail.com> Message-ID: <1122168538.6804.2.camel@ignacio.lan> On Sat, 2005-07-23 at 18:41 -0400, Jeff Spaleta wrote: > On 7/23/05, Warren Togami wrote: > > In case you missed the discussion, this does not solve the problem. > I've run into this on #fedora and I have yet to see importing of all > the provided keys fail to resolve the problem. No, it only applies a bandage over it. The actual problem is that the packages are signed by 2 different keys. The solution is to re-sign them. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Sun Jul 24 01:58:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 23 Jul 2005 21:58:03 -0400 Subject: yum GPG verify and package sigs... In-Reply-To: <1122168538.6804.2.camel@ignacio.lan> References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> <20050723162207.GA26475@jadzia.bu.edu> <604aa79105072309275f077296@mail.gmail.com> <42E2B8DC.3090104@redhat.com> <604aa79105072315414a18e488@mail.gmail.com> <1122168538.6804.2.camel@ignacio.lan> Message-ID: <604aa791050723185860960af1@mail.gmail.com> On 7/23/05, Ignacio Vazquez-Abrams wrote: > On Sat, 2005-07-23 at 18:41 -0400, Jeff Spaleta wrote: > > On 7/23/05, Warren Togami wrote: > > > In case you missed the discussion, this does not solve the problem. > > > I've run into this on #fedora and I have yet to see importing of all > > the provided keys fail to resolve the problem. > > No, it only applies a bandage over it. The actual problem is that the > packages are signed by 2 different keys. The solution is to re-sign > them. There are solutions.. and there are workarounds. I was originally commenting on Miller's comment about an 'easy suggestion' to tell users who encounter this problem. You are right the only real 'solution' is to rebuild the packages AND rebuild the isos. But I know thats realistically not going to happen. So we can either beat our heads against the brick wall and shake or fists every-so viciously in the air... or we can note in several places that the easiest way to 'workaround' the problem is to manually import all the keys installed on the system by the fedora-release package and just move on. I'd like to point out that while yum supporting multiple keys is probably a useful option for frankenstien local repos that people patch together(like on my home lan) it wouldn't have prevented this problem. The packages in the fc4 release were suppose to all be the same key.. the yum config in the shipped fedora-release would have just had one key defined... and I suspect that come fc5 fedora-release will continue to only have one key defined in the provided yum config because the expectation about how the packages are supposed to be signed hasn't changed. The only long-term solution is to build in some scripted checks to make sure that all the packages in the iso are signed with the same key at iso generation time. That way every iso as part of the fc5 testing and release process can be checked for signing consistency before the iso is public. -jef From wtogami at redhat.com Sun Jul 24 02:03:29 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 23 Jul 2005 16:03:29 -1000 Subject: yum GPG verify and package sigs... In-Reply-To: <1122168538.6804.2.camel@ignacio.lan> References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> <20050723162207.GA26475@jadzia.bu.edu> <604aa79105072309275f077296@mail.gmail.com> <42E2B8DC.3090104@redhat.com> <604aa79105072315414a18e488@mail.gmail.com> <1122168538.6804.2.camel@ignacio.lan> Message-ID: <42E2F6F1.10209@redhat.com> Ignacio Vazquez-Abrams wrote: > On Sat, 2005-07-23 at 18:41 -0400, Jeff Spaleta wrote: > >>On 7/23/05, Warren Togami wrote: >> >>>In case you missed the discussion, this does not solve the problem. > > >>I've run into this on #fedora and I have yet to see importing of all >>the provided keys fail to resolve the problem. > > > No, it only applies a bandage over it. The actual problem is that the > packages are signed by 2 different keys. The solution is to re-sign > them. Jef was correct, and I was misunderstanding yum's behavior. Perhaps the error message text is misleading. This however leads me to wonder, would it be good if yum could enforce that all packages in this defined repository must be this key? Would this gain us anything if yum had a "stricter" option to enforce this? Warren Togami wtogami at redhat.com From kaboom at oobleck.net Sun Jul 24 04:07:56 2005 From: kaboom at oobleck.net (Chris Ricker) Date: Sun, 24 Jul 2005 00:07:56 -0400 (EDT) Subject: yum GPG verify and package sigs... In-Reply-To: <604aa791050723185860960af1@mail.gmail.com> References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> <20050723162207.GA26475@jadzia.bu.edu> <604aa79105072309275f077296@mail.gmail.com> <42E2B8DC.3090104@redhat.com> <604aa79105072315414a18e488@mail.gmail.com> <1122168538.6804.2.camel@ignacio.lan> <604aa791050723185860960af1@mail.gmail.com> Message-ID: On Sat, 23 Jul 2005, Jeff Spaleta wrote: > problem. The packages in the fc4 release were suppose to all be the > same key.. the yum config in the shipped fedora-release would have > just had one key defined... and I suspect that come fc5 fedora-release > will continue to only have one key defined in the provided yum config > because the expectation about how the packages are supposed to be > signed hasn't changed. Now that yum supports it, I don't see any reason for fedora-release not to list multiple keys. That's the solution with the minimal amount of churn after all.... later, chris From skvidal at phy.duke.edu Sun Jul 24 07:36:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 24 Jul 2005 03:36:19 -0400 Subject: builds started Message-ID: <1122190579.12310.19.camel@cutter> Hi, all of you who have requested builds in the last couple of weeks you should start seeing all your builds from the tobuild file pushed through the system. You'll get an email for a success or failure and it should point you to build logs of the results. This should be mostly functional - let us know what breaks. -sv From ville.skytta at iki.fi Sun Jul 24 10:42:25 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 24 Jul 2005 13:42:25 +0300 Subject: builds started In-Reply-To: <1122190579.12310.19.camel@cutter> References: <1122190579.12310.19.camel@cutter> Message-ID: <1122201745.4030.70.camel@localhost.localdomain> On Sun, 2005-07-24 at 03:36 -0400, seth vidal wrote: > all of you who have requested builds in the last couple of weeks you > should start seeing all your builds from the tobuild file pushed through > the system. > > You'll get an email for a success or failure and it should point you to > build logs of the results. > > This should be mostly functional - let us know what breaks. I got 12 "prep error" failure mails for various packages, like: could not check out gdome2-0_8_1-1_fc5 from development - output was: cvs [checkout aborted]: reading from server: Connection timed out Should I do "make build" for these again? Do I need to bump release and tag before doing that? By the way, judging from the timestamps of the mails I received, the builds don't seem to be necessarily happening in the same order as in "tobuild". If so, that's a build dependency problem which needs to be addressed somehow in the system or by the build submitters. From andreas at bawue.net Sun Jul 24 12:33:18 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Sun, 24 Jul 2005 14:33:18 +0200 (CEST) Subject: builds started In-Reply-To: <1122190579.12310.19.camel@cutter> References: <1122190579.12310.19.camel@cutter> Message-ID: On Sun, 24 Jul 2005, seth vidal wrote: > This should be mostly functional - let us know what breaks. perl-Crypto-Blowfish just failed as it could not install perl-Crypto-CBC, a build dependency. This one was build sucessfully earlier today. Maybe it would make sense feeding the "just-built" repository to mock as well? bye, adnreas From mattdm at mattdm.org Sun Jul 24 13:50:44 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 24 Jul 2005 09:50:44 -0400 Subject: yum GPG verify and package sigs... In-Reply-To: References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> <20050723162207.GA26475@jadzia.bu.edu> <604aa79105072309275f077296@mail.gmail.com> <42E2B8DC.3090104@redhat.com> <604aa79105072315414a18e488@mail.gmail.com> <1122168538.6804.2.camel@ignacio.lan> <604aa791050723185860960af1@mail.gmail.com> Message-ID: <20050724135044.GA1967@jadzia.bu.edu> On Sun, Jul 24, 2005 at 12:07:56AM -0400, Chris Ricker wrote: > > problem. The packages in the fc4 release were suppose to all be the > > same key.. the yum config in the shipped fedora-release would have > > just had one key defined... and I suspect that come fc5 fedora-release > > will continue to only have one key defined in the provided yum config > > because the expectation about how the packages are supposed to be > > signed hasn't changed. > Now that yum supports it, I don't see any reason for fedora-release not to > list multiple keys. That's the solution with the minimal amount of churn > after all.... And for people who haven't edited their yum repos file, it'd be a transparent fix, yeah? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> Current office temperature: 77 degrees Fahrenheit. From skvidal at phy.duke.edu Sun Jul 24 13:53:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 24 Jul 2005 09:53:45 -0400 Subject: extras builds Message-ID: <1122213226.12310.21.camel@cutter> If you have a build that successfully completed please remove the entry for that build from the tobuild file. Thanks, -sv From jspaleta at gmail.com Sun Jul 24 15:12:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 24 Jul 2005 11:12:08 -0400 Subject: yum GPG verify and package sigs... In-Reply-To: <20050724135044.GA1967@jadzia.bu.edu> References: <42E227F8.4060206@redhat.com> <1122132315.12310.7.camel@cutter> <20050723162207.GA26475@jadzia.bu.edu> <604aa79105072309275f077296@mail.gmail.com> <42E2B8DC.3090104@redhat.com> <604aa79105072315414a18e488@mail.gmail.com> <1122168538.6804.2.camel@ignacio.lan> <604aa791050723185860960af1@mail.gmail.com> <20050724135044.GA1967@jadzia.bu.edu> Message-ID: <604aa79105072408125a7a1e20@mail.gmail.com> On 7/24/05, Matthew Miller wrote: > And for people who haven't edited their yum repos file, it'd be a > transparent fix, yeah? You want a transparent workaround with minimal package that works for all users... you release an update to fedora-release with a postinstall scriptlet to rpm --import all the keys provided as part of the fedora-release package. -jef From stickster at gmail.com Sun Jul 24 16:34:14 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 24 Jul 2005 12:34:14 -0400 Subject: web/html/docs/release-notes index.php,1.5,1.6 In-Reply-To: <200507241552.j6OFqweG020343@cvs-int.fedora.redhat.com> References: <200507241552.j6OFqweG020343@cvs-int.fedora.redhat.com> Message-ID: <1122222854.3447.10.camel@localhost.localdomain> On Sun, 2005-07-24 at 11:52 -0400, Karsten Wade wrote: > Author: kwade > > Update of /cvs/fedora/web/html/docs/release-notes > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv20326 > > Modified Files: > index.php > Log Message: > New date on updated notice. I wonder what the chances are of having the release-notes errata rolled into a fedora-release update? Note that the fedora-maintainers list is now tossing around the idea[1] of producing an update to allow for a script to do a "rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY*". I don't think we should lobby for doing this with every relnotes erratum, but certainly with the addition of the big section on legally encumbered material, it would be worth our while to piggyback there? = = = = = [1] https://www.redhat.com/archives/fedora-maintainers/2005-July/msg00080.html -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Christian.Iseli at licr.org Mon Jul 25 08:14:12 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 25 Jul 2005 10:14:12 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: Your message of "Fri, 22 Jul 2005 23:28:28 +0900." <42E1028C.20609@redhat.com> Message-ID: <200507250814.j6P8ECt9000985@ludwig-alpha.unil.ch> petersen at redhat.com said: > Does this sound reasonable? Yes. ? Make any sense? :) Yes. > What would be the best way to proceed? Filing bugs against every > package that ships static libs? Yes, and put a line in the packaging guidelines/review process. I also think having a -static package would be nice where possible. It would be great to have a kind of dependency noted in the packages that use the static libs as well. It could probably be somewhat automated, because said package should probably have a BuildRequire for the static lib anyway. Cheers, Christian From katzj at redhat.com Mon Jul 25 15:57:27 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 25 Jul 2005 11:57:27 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E1028C.20609@redhat.com> References: <42E1028C.20609@redhat.com> Message-ID: <1122307048.2608.3.camel@bree.local.net> On Fri, 2005-07-22 at 23:28 +0900, Jens Petersen wrote: > For the cases where it is still desirable or necessary to ship static libs, > I would suggest to move them from -devel into a separate -static > subpackage so that people who don't need them don't have to suffer > downloading and installing them. I'd rather not ship them in most cases and not add a package in the case where it might be needed. It ends up leading to a much worse comps nitemare otherwise. Jeremy From katzj at redhat.com Mon Jul 25 15:58:22 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 25 Jul 2005 11:58:22 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E1DED1.9060803@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> Message-ID: <1122307103.2608.5.camel@bree.local.net> On Fri, 2005-07-22 at 20:08 -1000, Warren Togami wrote: > Furthermore would anyone be averse to the idea of making it policy to > explicitly note in spec files when static libs are used in such a way > that it is easy to do an automated search? Something simple like: > > # Static Lib: libfoo This is then dependent on every packager knowing for certain every static lib that gets linked. I don't think that can be counted on... > It is otherwise a huge PITA when a security hole is discovered and we > need to sweep the entire distro for static copies, like the huge zlib > mess we had a while back. ... which means that we'd still have to do this and thus I'm not sure if it buys us much/anything. Jeremy From aoliva at redhat.com Mon Jul 25 17:50:07 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Jul 2005 14:50:07 -0300 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E1028C.20609@redhat.com> References: <42E1028C.20609@redhat.com> Message-ID: On Jul 22, 2005, Jens Petersen wrote: > Some packages may have a --disable-static configure option for > example to help with this, or they can just be deleted easily by > hand in the %install section. --disable-static is the way to go. Deleting the .a file will break the corresponding .la file, if it exists. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From Christian.Iseli at licr.org Mon Jul 25 21:39:23 2005 From: Christian.Iseli at licr.org (Christian.Iseli at licr.org) Date: Mon, 25 Jul 2005 23:39:23 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: Your message of "25 Jul 2005 14:50:07 -0300." Message-ID: <200507252216.j6PMGwhJ024241@mx2.redhat.com> aoliva at redhat.com said: > Deleting the .a file will break the corresponding .la file, if it exists. That shouldn't be a problem: we delete the .la files already anyway. Christian From petersen at redhat.com Tue Jul 26 03:52:13 2005 From: petersen at redhat.com (Jens Petersen) Date: Tue, 26 Jul 2005 12:52:13 +0900 Subject: builds started In-Reply-To: <1122190579.12310.19.camel@cutter> References: <1122190579.12310.19.camel@cutter> Message-ID: <42E5B36D.6060203@redhat.com> seth vidal wrote: > all of you who have requested builds in the last couple of weeks you > should start seeing all your builds from the tobuild file pushed through > the system. Just to clarify: are these builds being pushed to Extras for real or are they still test builds? I didn't seen any new packages appear yet. Jens From skvidal at phy.duke.edu Tue Jul 26 06:25:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 26 Jul 2005 02:25:50 -0400 Subject: builds started In-Reply-To: <42E5B36D.6060203@redhat.com> References: <1122190579.12310.19.camel@cutter> <42E5B36D.6060203@redhat.com> Message-ID: <1122359150.9641.6.camel@cutter> On Tue, 2005-07-26 at 12:52 +0900, Jens Petersen wrote: > seth vidal wrote: > > all of you who have requested builds in the last couple of weeks you > > should start seeing all your builds from the tobuild file pushed through > > the system. > > Just to clarify: are these builds being pushed to Extras for real > or are they still test builds? I didn't seen any new packages appear yet. > they are for real. They just hadn't been pushed yet. -sv From skvidal at phy.duke.edu Tue Jul 26 06:51:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 26 Jul 2005 02:51:43 -0400 Subject: builds started In-Reply-To: References: <1122190579.12310.19.camel@cutter> Message-ID: <1122360703.9641.17.camel@cutter> On Sun, 2005-07-24 at 14:33 +0200, Andreas Thienemann wrote: > On Sun, 24 Jul 2005, seth vidal wrote: > > > This should be mostly functional - let us know what breaks. > perl-Crypto-Blowfish just failed as it could not install perl-Crypto-CBC, > a build dependency. > > This one was build sucessfully earlier today. > Maybe it would make sense feeding the "just-built" repository to mock as > well? > we do. It was probably built out of order. The buildsys was not building in the order that things were put in. I think that will be corrected shortly. -sv From andreas at bawue.net Tue Jul 26 08:26:09 2005 From: andreas at bawue.net (Andreas Thienemann) Date: Tue, 26 Jul 2005 10:26:09 +0200 (CEST) Subject: builds started In-Reply-To: <1122360703.9641.17.camel@cutter> References: <1122190579.12310.19.camel@cutter> <1122360703.9641.17.camel@cutter> Message-ID: On Tue, 26 Jul 2005, seth vidal wrote: > > This one was build sucessfully earlier today. Maybe it would make > > sense feeding the "just-built" repository to mock as well? > we do. Ohh. > It was probably built out of order. The buildsys was not building in the > order that things were put in. I think that will be corrected shortly. In that case something must have broken. I got the mail about the successfull Crypto-CBC build a few hours before the failed Crypto-Blowfish package. But regardless of that, is the buildsystem still in testing stage or is back in automatic mode? bye, andreas From fedora at camperquake.de Tue Jul 26 13:07:13 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 26 Jul 2005 15:07:13 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122307048.2608.3.camel@bree.local.net> References: <42E1028C.20609@redhat.com> <1122307048.2608.3.camel@bree.local.net> Message-ID: <20050726130713.GA4754@ryoko.camperquake.de> On Mon, Jul 25, 2005 at 11:57:27AM -0400, Jeremy Katz wrote: > I'd rather not ship them in most cases and not add a package in the case > where it might be needed. It ends up leading to a much worse comps > nitemare otherwise. Well, I'd like to be able to link a library statically if I choose to. I do not care much if the .a file is in the -devel or a -static package, but I'd like to have it. From katzj at redhat.com Tue Jul 26 14:14:14 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 26 Jul 2005 10:14:14 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <20050726130713.GA4754@ryoko.camperquake.de> References: <42E1028C.20609@redhat.com> <1122307048.2608.3.camel@bree.local.net> <20050726130713.GA4754@ryoko.camperquake.de> Message-ID: <1122387254.3581.65.camel@bree.local.net> On Tue, 2005-07-26 at 15:07 +0200, Ralf Ertzinger wrote: > On Mon, Jul 25, 2005 at 11:57:27AM -0400, Jeremy Katz wrote: > > I'd rather not ship them in most cases and not add a package in the case > > where it might be needed. It ends up leading to a much worse comps > > nitemare otherwise. > > Well, I'd like to be able to link a library statically if I choose to. > I do not care much if the .a file is in the -devel or a -static package, > but I'd like to have it. I think there are plenty of cases at the lower levels of the stack where it makes sense and thus I think they should remain in -devel. But, for example, a lot of the GNOME stack actually doesn't make any sense at all to link statically as it depends on dlopen()'ing of various shared objects. So static libs along those lines seem like good candidates to remove and save some space Jeremy From rc040203 at freenet.de Tue Jul 26 14:38:01 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 26 Jul 2005 16:38:01 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122387254.3581.65.camel@bree.local.net> References: <42E1028C.20609@redhat.com> <1122307048.2608.3.camel@bree.local.net> <20050726130713.GA4754@ryoko.camperquake.de> <1122387254.3581.65.camel@bree.local.net> Message-ID: <1122388681.4264.259.camel@mccallum.corsepiu.local> On Tue, 2005-07-26 at 10:14 -0400, Jeremy Katz wrote: > On Tue, 2005-07-26 at 15:07 +0200, Ralf Ertzinger wrote: > > On Mon, Jul 25, 2005 at 11:57:27AM -0400, Jeremy Katz wrote: > > > I'd rather not ship them in most cases and not add a package in the case > > > where it might be needed. It ends up leading to a much worse comps > > > nitemare otherwise. > > > > Well, I'd like to be able to link a library statically if I choose to. > > I do not care much if the .a file is in the -devel or a -static package, > > but I'd like to have it. > I think there are plenty of cases at the lower levels of the stack where > it makes sense Well, though I have to agree, there are rare/exceptional cases where static linkage is useful, IMO, as part of a distribution, the downside of shipping (and using) static libs by far outweighs the rare occasions where static libs are useful. > and thus I think they should remain in -devel. I beg to differ, moving static libs to separate packages would make packages using static libs explicit, because their specs would have to have an explicit "BR: *-static" in their spec. As a side-effect, "*-static" rpms to a large extend would render Warren's considerations moot. All in all, I am favor to avoid shipping static libs whenever possible and am in favor of Jens' proposal. Ralf From jspaleta at gmail.com Tue Jul 26 14:51:48 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 26 Jul 2005 10:51:48 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122388681.4264.259.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <1122307048.2608.3.camel@bree.local.net> <20050726130713.GA4754@ryoko.camperquake.de> <1122387254.3581.65.camel@bree.local.net> <1122388681.4264.259.camel@mccallum.corsepiu.local> Message-ID: <604aa79105072607513e4ca3ef@mail.gmail.com> On 7/26/05, Ralf Corsepius wrote: > I beg to differ, moving static libs to separate packages would make > packages using static libs explicit, because their specs would have to > have an explicit "BR: *-static" in their spec. That's the big concern here right.. if statics are going to be used, then there needs to be a way to quickly identify packages that are using static libs so when there is a problem in the lib that demands an update people can have high confidence in systematicly finding packages that a rebuild against the updated static. Is a BuildRequires for a "-static" subpackage good enough to generate high confidence when doing this sort of audit? I'm not sure this goes far enough.. Don't some srpms contain the sources for a specific version of a library to build statically against at build time? So they wouldn't actually be using a BuildRequires at all. -jef From caillon at redhat.com Tue Jul 26 14:51:11 2005 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 26 Jul 2005 10:51:11 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E1028C.20609@redhat.com> References: <42E1028C.20609@redhat.com> Message-ID: <42E64DDF.3050309@redhat.com> On 07/22/2005 10:28 AM, Jens Petersen wrote: >This has been in my mind for a while, but now I finally post it here: > >I believe we're still shipping many static libs in -devel not least >in Core, which make our -devel packages rather heavy. I think the >vast majority of them are not needed or used really at all. >So they should just be removed. Some packages may have a --disable-static >configure option for example to help with this, or they can just be >deleted easily by hand in the %install section. > >For the cases where it is still desirable or necessary to ship static libs, >I would suggest to move them from -devel into a separate -static >subpackage so that people who don't need them don't have to suffer >downloading and installing them. > >Does this sound reasonable? Make any sense? :) >Comments and discussion welcome. What would be the best way to proceed? >Filing bugs against every package that ships static libs? > Let's get rid of static libs where we can. But there's no need to force people to move things around in packages. Firefox, Mozilla, Thunderbird, etc. ABSOLUTELY CANNOT BUILD without the static lib of nspr. Sure, that is a bug that is worth fixing, however, moving the static lib out of nspr-devel currently makes nspr-devel USELESS, so I see no point in doing this if people will need to install the -static package anyway to make use of the -devel package. Veto on the proposed package naming scheme, but +1 on cleaning up static libs. From shahms at shahms.com Tue Jul 26 15:17:43 2005 From: shahms at shahms.com (Shahms King) Date: Tue, 26 Jul 2005 08:17:43 -0700 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122388681.4264.259.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <1122307048.2608.3.camel@bree.local.net> <20050726130713.GA4754@ryoko.camperquake.de> <1122387254.3581.65.camel@bree.local.net> <1122388681.4264.259.camel@mccallum.corsepiu.local> Message-ID: <42E65417.20404@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the most part, the focus on packages using static libraries is misplaced as most packages should be dynamically linked. I would wager the most frequent use for static libraries is with unpackaged or internal applications. And even this use is likely to be limited. - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC5lQX/qs2NkWy11sRAnCUAJ0RDUBaYgwQHJI1L6bVa5qsSqqqSACgtVQn N9QB+DZ8x7LW339c1MxqtP4= =gBmc -----END PGP SIGNATURE----- From petersen at redhat.com Wed Jul 27 04:16:17 2005 From: petersen at redhat.com (Jens Petersen) Date: Wed, 27 Jul 2005 13:16:17 +0900 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E64DDF.3050309@redhat.com> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> Message-ID: <42E70A91.9010403@redhat.com> Christopher Aillon wrote: > Let's get rid of static libs where we can. But there's no need to force > people to move things around in packages. Firefox, Mozilla, > Thunderbird, etc. ABSOLUTELY CANNOT BUILD without the static lib of > nspr. Sure, that is a bug that is worth fixing, however, moving the > static lib out of nspr-devel currently makes nspr-devel USELESS, so I > see no point in doing this if people will need to install the -static > package anyway to make use of the -devel package. Ok, sure there will have to be exceptions and nspr will be one of them. :) > Veto on the proposed package naming scheme That does not mean that -static is necessarily a bad idea in general though. :) Jens From rc040203 at freenet.de Wed Jul 27 04:23:20 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jul 2005 06:23:20 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E70A91.9010403@redhat.com> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> Message-ID: <1122438200.4264.343.camel@mccallum.corsepiu.local> On Wed, 2005-07-27 at 13:16 +0900, Jens Petersen wrote: > Christopher Aillon wrote: > > Let's get rid of static libs where we can. But there's no need to force > > people to move things around in packages. Firefox, Mozilla, > > Thunderbird, etc. ABSOLUTELY CANNOT BUILD without the static lib of > > nspr. Sure, that is a bug that is worth fixing, however, moving the > > static lib out of nspr-devel currently makes nspr-devel USELESS, so I > > see no point in doing this if people will need to install the -static > > package anyway to make use of the -devel package. > > Ok, sure there will have to be exceptions and nspr will be one of them. :) Why? Ship a nspr-static instead of nspr-devel. > > Veto on the proposed package naming scheme > > That does not mean that -static is necessarily a bad idea in general though. :) It only makes sense if it is strictly obeyed. I.e. no exceptions should be allowed. Ralf From petersen at redhat.com Wed Jul 27 04:28:23 2005 From: petersen at redhat.com (Jens Petersen) Date: Wed, 27 Jul 2005 13:28:23 +0900 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <200507250814.j6P8ECt9000985@ludwig-alpha.unil.ch> References: <200507250814.j6P8ECt9000985@ludwig-alpha.unil.ch> Message-ID: <42E70D67.1000909@redhat.com> Christian.Iseli at licr.org wrote: > Yes, and put a line in the packaging guidelines/review process. Done yesterday. Jens From caillon at redhat.com Wed Jul 27 04:56:37 2005 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jul 2005 00:56:37 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122438200.4264.343.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> Message-ID: <42E71405.6010206@redhat.com> Ralf Corsepius wrote: > On Wed, 2005-07-27 at 13:16 +0900, Jens Petersen wrote: > >>Christopher Aillon wrote: >> >>>Let's get rid of static libs where we can. But there's no need to force >>>people to move things around in packages. Firefox, Mozilla, >>>Thunderbird, etc. ABSOLUTELY CANNOT BUILD without the static lib of >>>nspr. Sure, that is a bug that is worth fixing, however, moving the >>>static lib out of nspr-devel currently makes nspr-devel USELESS, so I >>>see no point in doing this if people will need to install the -static >>>package anyway to make use of the -devel package. >> >>Ok, sure there will have to be exceptions and nspr will be one of them. :) > > Why? Ship a nspr-static instead of nspr-devel. Act I, Scene I (Tim is sitting, drinking a latte at Starbucks. He using their access point with his laptop.) Tim: Hmm. I want to create an application using nspr. I think I'll go find nspr-devel. (Tim typing.) Tim: WTF? IT DOESNT EXIST?!?!?! (Tim sighs.) Tim: Wow, such defeat. Tom shall never let me hear the end of it. (Tim files a bug report.) Act I, Scene II Todd: Seriously. I saw the bugmail. Let me show you. (Tom looks over as Todd produces the aforementioned bugmail.) Tom: (laughing) Man, I knew he didn't have it in him. Tom: (aside) That silly Tim, creating his own applications. Everyone knows the real glory is hacking firefox. But first, I need the nspr devel env. Little does he know that to alleviate Tim's issues, the RPM maintainer just built a new nspr package without the evil static libs. nspr-devel now exists and has just the headers. I'll grab it quickly and be one step ahead of him! (Tom goes to his laptop and successfully wgets the RPM) Act I, Scene III WTF? FIREFOX DOESNT BUILD WITH IT? Same with mozilla, thunderbird, and subsequently evolution, etc. Noooooooooooooooooooooooo! Act II, Scene I Tim and Tom are discussing how well their progress is going. ... Act III, Scene IV ... Both frustrated, and not willing to admit defeat to the other, they end up tragically killing themselves. THE END. Obviously, in both cases we disservice the developer. The real solution is to fix things to not require the static libs, and just simply remove them, not to hack around it by adding -static packages. That just causes confusion. (Yes, it is late here. I'm bored waiting for laundry to finish.) From rc040203 at freenet.de Wed Jul 27 05:06:37 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jul 2005 07:06:37 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E71405.6010206@redhat.com> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> Message-ID: <1122440797.4264.348.camel@mccallum.corsepiu.local> On Wed, 2005-07-27 at 00:56 -0400, Christopher Aillon wrote: > Ralf Corsepius wrote: > > On Wed, 2005-07-27 at 13:16 +0900, Jens Petersen wrote: > > > >>Christopher Aillon wrote: > >> > >>>Let's get rid of static libs where we can. But there's no need to force > >>>people to move things around in packages. Firefox, Mozilla, > >>>Thunderbird, etc. ABSOLUTELY CANNOT BUILD without the static lib of > >>>nspr. Sure, that is a bug that is worth fixing, however, moving the > >>>static lib out of nspr-devel currently makes nspr-devel USELESS, so I > >>>see no point in doing this if people will need to install the -static > >>>package anyway to make use of the -devel package. > >> > >>Ok, sure there will have to be exceptions and nspr will be one of them. :) > > > > Why? Ship a nspr-static instead of nspr-devel. > Obviously, in both cases we disservice the developer. The real > solution is to fix things to not require the static libs, Right. > and just simply remove them, not to hack around it by adding -static > packages. That just causes confusion. No, it just makes package bugs/deficiencies obvious. If it affects mozilla, firefox and friends, so be it ... what shall I say ... design probs therein. Ralf From caillon at redhat.com Wed Jul 27 05:22:36 2005 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jul 2005 01:22:36 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122440797.4264.348.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> Message-ID: <42E71A1C.1060400@redhat.com> Ralf Corsepius wrote: > On Wed, 2005-07-27 at 00:56 -0400, Christopher Aillon wrote: > >>Obviously, in both cases we disservice the developer. The real >>solution is to fix things to not require the static libs, > > Right. Good, we agree on this. :) >> and just simply remove them, not to hack around it by adding -static >>packages. That just causes confusion. > > No, it just makes package bugs/deficiencies obvious. The bug in this case is already obvious. In fact, in case it wasn't, I've already pointed it out several times having announced it on this (public) list and elsewhere. So, it just annoys people if you break things without a proper fix. > If it affects mozilla, firefox and friends, so be it ... what shall I > say ... design probs therein. Design flaws and all, don't break my packages in your quest for package divinity. Patches will be accepted if you can grok your way through the NSS coreconf build system and its warts. From rc040203 at freenet.de Wed Jul 27 06:39:26 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jul 2005 08:39:26 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E71A1C.1060400@redhat.com> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> Message-ID: <1122446367.4264.378.camel@mccallum.corsepiu.local> On Wed, 2005-07-27 at 01:22 -0400, Christopher Aillon wrote: > Ralf Corsepius wrote: > > On Wed, 2005-07-27 at 00:56 -0400, Christopher Aillon wrote: > > If it affects mozilla, firefox and friends, so be it ... what shall I > > say ... design probs therein. > > > Design flaws and all, don't break my packages in your quest for > package divinity. Pardon? Are you seriously expecting "the world isn't a'changing"? We are talking about "changing packaging conventions" to reduce to possibilities of potential bugs. If you guys are unwilling to change anything on your packages, we can stop this discussion now. Ralf From wtogami at redhat.com Wed Jul 27 11:21:51 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 27 Jul 2005 01:21:51 -1000 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122446367.4264.378.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> Message-ID: <42E76E4F.5020004@redhat.com> Ralf Corsepius wrote: > > We are talking about "changing packaging conventions" to reduce to > possibilities of potential bugs. If you guys are unwilling to change > anything on your packages, we can stop this discussion now. > We cannot change *everything* that has existed for years to suddenly follow a new ideal perfect conventions. If we did so, then we would have enforced that all library packages begin with "lib", and many other package changes that don't really benefit us. There is a significant maintenance and engineering burden for not only us, but 3rd party software providers when anything is changed. Generally "old" stuff are grandfathered in for this reason. Any ideal perfect convention of today might easily become different in the future, meaning more changes that may needlessly upset people and complicate engineering. We cannot change *everything*, but it is OK to change some things. Where to draw the line is the key question with no simple answers. Another example: I warned on fedora-devel-list a while ago that the influx of java packages with arbitrary names are polluting the namespace with names that are not obvious that they have anything to do with java. It has been suggested that java packages providing libraries should be named java-* and only applications can avoid this rule, similar to perl-* modules and perl software like spamassassin. This however upset our java people because it would be significant maintenance burden to fork from upstream jpackage, who had used these names in some cases for *years* prior to our importing. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Wed Jul 27 11:47:40 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jul 2005 13:47:40 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E76E4F.5020004@redhat.com> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> <42E76E4F.5020004@redhat.com> Message-ID: <1122464860.4264.426.camel@mccallum.corsepiu.local> On Wed, 2005-07-27 at 01:21 -1000, Warren Togami wrote: > Ralf Corsepius wrote: > > > > We are talking about "changing packaging conventions" to reduce to > > possibilities of potential bugs. If you guys are unwilling to change > > anything on your packages, we can stop this discussion now. > > > > We cannot change *everything* that has existed for years to suddenly > follow a new ideal perfect conventions. Well, I had assumed we were talking about few broken packages, but checking core (rpm -qlp *.rpm | grep '/lib/lib.*\.a$' reveals that things much more packages are shipping static libs than I had expected. Anyhow, given the fact static libs normally are only used if no shared version of a library is available, or if they are forced, I would expect only very few of them being used. > If we did so, then we would > have enforced that all library packages begin with "lib", and many other > package changes that don't really benefit us. There is a significant > maintenance and engineering burden for not only us, but 3rd party > software providers when anything is changed. I.e. Debian conventions ;) I perceive them as overly stylish, nevertheless they make sense. However, I were lucky if at least *-devel was systematically applied. > Generally "old" stuff are grandfathered in for this reason. > > Any ideal perfect convention of today might easily become different in > the future, meaning more changes that may needlessly upset people and > complicate engineering. Wasn't Fedora meant to be progressive? Instead, I perceive unwillingness and ultra-conservativism :( > We cannot change *everything*, but it is OK to change some things. > Where to draw the line is the key question with no simple answers. > > Another example: I warned on fedora-devel-list a while ago that the > influx of java packages with arbitrary names are polluting the namespace > with names that are not obvious that they have anything to do with java. Similar considerations apply to selinux - No visible conventions on their tools' naming :( I think, we'll have to wait until a similar issue like the zlib disaster happens again (may be libnspr forcing are recompilation of half of FC) until people will be willing to change their attitude. Ralf PS.: Sorry for sounding bitter. From pmatilai at laiskiainen.org Wed Jul 27 11:58:55 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 27 Jul 2005 04:58:55 -0700 (PDT) Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122464860.4264.426.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> <42E76E4F.5020004@redhat.com> <1122464860.4264.426.camel@mccallum.corsepiu.local> Message-ID: On Wed, 27 Jul 2005, Ralf Corsepius wrote: > > Similar considerations apply to selinux - No visible conventions on > their tools' naming :( Yeah, my personal favorite being the "fixfiles" command. From caillon at redhat.com Wed Jul 27 14:53:30 2005 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jul 2005 10:53:30 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122446367.4264.378.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> Message-ID: <42E79FEA.50607@redhat.com> On 07/27/2005 02:39 AM, Ralf Corsepius wrote: >On Wed, 2005-07-27 at 01:22 -0400, Christopher Aillon wrote: > > >>Ralf Corsepius wrote: >> >> >>>On Wed, 2005-07-27 at 00:56 -0400, Christopher Aillon wrote: >>> >>> > > > >>>If it affects mozilla, firefox and friends, so be it ... what shall I >>>say ... design probs therein. >>> >>> >>Design flaws and all, don't break my packages in your quest for >>package divinity. >> >> >Pardon? Are you seriously expecting "the world isn't a'changing"? > >We are talking about "changing packaging conventions" to reduce to >possibilities of potential bugs. If you guys are unwilling to change >anything on your packages, we can stop this discussion now. > > So let me get this straight. The package maintainer has alerted everyone to the problem (which you agree with), has said what the ideal fix is (which you agree with), and has publicly announced that the ideal fix will be accepted if someone offers a patch. How is that unwilling to accept change? IMO, the only thing that we should be discussing now since you are so adamant about this whole affair is when you are going to stop ranting about naming schemes, and provide me with a patch to let Firefox build against the shared nspr libs instead of the static nspr libs, as that would obviate this entire discussion. From rc040203 at freenet.de Wed Jul 27 15:55:50 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 27 Jul 2005 17:55:50 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E79FEA.50607@redhat.com> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> <42E79FEA.50607@redhat.com> Message-ID: <1122479751.4264.526.camel@mccallum.corsepiu.local> On Wed, 2005-07-27 at 10:53 -0400, Christopher Aillon wrote: > IMO, the only thing that we should be discussing now since you are so > adamant about this whole affair is when you are going to stop ranting > about naming schemes, Seems as if you haven't understood what this is about :( > and provide me with a patch to let Firefox build > against the shared nspr libs instead of the static nspr libs, as that > would obviate this entire discussion. I am too long in this business to fall into this old rhetorical trick from the "1000 tricks to get rid of customers in 1st level support" grab bag - I am not going to solve your bugs. But let try to outline what I have in mind: The point I am talking about, is you to ship a package called nspr-static instead of nspr-devel (s/devel/static/g in your specfile), because you are shipping static libs only, and then use BR: nspr-static inside of packages linking against this static libnspr. E.g. %{_bindir}/* -static %{_includedir}/* %{_libdir}/lib*.a I.e. there would not be any *-devel package at this point in time, anymore for packages shipping static libs only. Packages wanting to link against them would be required to use -static. This is one point where the dependency on a static lib would become explicit. And yes, this would be incompatible to now. However, this incompatibility is intended - The purpose of this whole undertaking is to make the dependency on a static library explicit, by mapping it to build-time package dependencies. When you once should be shipping a shared libnspr, you could reorganize the packages this way: %{_bindir}/* %{_libdir}/*.so.* -devel %{_includedir}/* %{_libdir}/*.so -static Requires: -devel %{_libdir}/*.a If you want to drop the static lib, you would remove -static, which would cause the "BR: -static" inside of apps trying to statically link, to break. This is yet another point where the dependency on a static lib would become explicit and intentionally break if packaging changes. Anyway, as Warren correctly pointed out, applying this scheme to FC probably is an illusion :( Ralf From caillon at redhat.com Wed Jul 27 17:04:38 2005 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jul 2005 13:04:38 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122479751.4264.526.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> <42E79FEA.50607@redhat.com> <1122479751.4264.526.camel@mccallum.corsepiu.local> Message-ID: <42E7BEA6.8000503@redhat.com> On 07/27/2005 11:55 AM, Ralf Corsepius wrote: >On Wed, 2005-07-27 at 10:53 -0400, Christopher Aillon wrote: > > >>and provide me with a patch to let Firefox build >>against the shared nspr libs instead of the static nspr libs, as that >>would obviate this entire discussion. >> >> >I am too long in this business to fall into this old rhetorical trick >from the "1000 tricks to get rid of customers in 1st level support" grab >bag - I am not going to solve your bugs. > It's not a trick. You're the one that's unabashedly trying to force things down my throat. If you want it this badly, prove it and do the work. This is how open source has come to thrive. >When you once should be shipping a shared libnspr, you could reorganize >the packages this way: > > So, I think I see your confusion. You appear to think I only ship static libs, but that is not so. I currently ship a shared AND a static library. Right now, nobody links against the shared lib, only the static lib. You are proposing that because nothing does that right now, I should rename -devel to -static, but that would force people who want to write their own app against the shared nspr libs to use the -static package which is very badly broken. If I go ahead and add a -static package, that would force every CURRENT consumer that is forced to build against the static libary (firefox, et. al) to get both the -devel AND the -static package which (beating a dead horse) is also broken. You should need only the -devel package. Refer to the three-act play. There is nothing else I really can say here unless there is a patch available to make the current consumers use the shared lib. I will not be further replying to this discussion. From tcallawa at redhat.com Wed Jul 27 22:17:50 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 27 Jul 2005 17:17:50 -0500 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E7BEA6.8000503@redhat.com> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> <42E79FEA.50607@redhat.com> <1122479751.4264.526.camel@mccallum.corsepiu.local> <42E7BEA6.8000503@redhat.com> Message-ID: <1122502670.2645.7.camel@localhost.localdomain> On Wed, 2005-07-27 at 13:04 -0400, Christopher Aillon wrote: > It's not a trick. You're the one that's unabashedly trying to force > things down my throat. If you want it this badly, prove it and do the > work. This is how open source has come to thrive. Well, turns out its not that much work. I just removed the static libs, and noted the places where nss broke. Patch attached to fix Firefox Deer Park Alpha 2, should be applicable for anything else with nss bits. Now, can we get back on the original topic? :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox-1.1-nspr-shared.patch Type: text/x-patch Size: 1090 bytes Desc: not available URL: From mattdm at mattdm.org Thu Jul 28 00:26:14 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 27 Jul 2005 20:26:14 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122502670.2645.7.camel@localhost.localdomain> References: <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> <42E79FEA.50607@redhat.com> <1122479751.4264.526.camel@mccallum.corsepiu.local> <42E7BEA6.8000503@redhat.com> <1122502670.2645.7.camel@localhost.localdomain> Message-ID: <20050728002614.GA20533@jadzia.bu.edu> On Wed, Jul 27, 2005 at 05:17:50PM -0500, Tom 'spot' Callaway wrote: > Well, turns out its not that much work. I just removed the static libs, > and noted the places where nss broke. Heh. You rock. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From caillon at redhat.com Thu Jul 28 01:33:11 2005 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Jul 2005 21:33:11 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122502670.2645.7.camel@localhost.localdomain> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> <42E79FEA.50607@redhat.com> <1122479751.4264.526.camel@mccallum.corsepiu.local> <42E7BEA6.8000503@redhat.com> <1122502670.2645.7.camel@localhost.localdomain> Message-ID: <42E835D7.1070001@redhat.com> Tom 'spot' Callaway wrote: > On Wed, 2005-07-27 at 13:04 -0400, Christopher Aillon wrote: > > >>It's not a trick. You're the one that's unabashedly trying to force >>things down my throat. If you want it this badly, prove it and do the >>work. This is how open source has come to thrive. > > > Well, turns out its not that much work. I just removed the static libs, > and noted the places where nss broke. > > Patch attached to fix Firefox Deer Park Alpha 2, should be applicable > for anything else with nss bits. Thanks, I filed it as https://bugzilla.mozilla.org/show_bug.cgi?id=302416 From skvidal at phy.duke.edu Thu Jul 28 07:34:24 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 03:34:24 -0400 Subject: fun with the buildsystem status page Message-ID: <1122536064.13300.13.camel@cutter> Something that might help you all keep track of your own builds: http://buildsys.fedoraproject.org/build-status/indiv.psp?email=skvidal at phy.duke.edu if you replace my email address in that url with the address you have for your fedora cvs account you should get the status of the packages in the database that you've submitted. -sv From skvidal at phy.duke.edu Thu Jul 28 08:54:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 04:54:56 -0400 Subject: plague-client/buildsys client docs Message-ID: <1122540896.13300.29.camel@cutter> Hi folks, I've written up some docs for using the plague-client interface. They're available here: http://fedoraproject.org/wiki/Extras/BuildSystemClientSetup At some point 'soon' in the future you'll need to have the plague-client package installed in order to request builds. Right now, though, it will just let you see what is going on with the buildsystem w/o going to the web interface. It will also let you kill your own jobs or requeue your own job if it failed for some spurious reason. Once Dan wants to make a plague 0.3 release these packages will be in fedora extras, but for the moment they're not. -sv From veillard at redhat.com Thu Jul 28 11:05:39 2005 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 28 Jul 2005 07:05:39 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E1DED1.9060803@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> Message-ID: <20050728110539.GL10076@redhat.com> On Fri, Jul 22, 2005 at 08:08:17PM -1000, Warren Togami wrote: > >So they should just be removed. Some packages may have a --disable-static > >configure option for example to help with this, or they can just be > >deleted easily by hand in the %install section. > > > >For the cases where it is still desirable or necessary to ship static libs, > >I would suggest to move them from -devel into a separate -static > >subpackage so that people who don't need them don't have to suffer > >downloading and installing them. > > > >Does this sound reasonable? Make any sense? :) I dislike that. Any non-LSB lib should have static libs available one way or another from the distro otherwise we just make the distro unsuitable for ISV development (from an LSB POV). Now having a duplicate for -devel in -static 1/ breaks all the documentation and user expectations 2/ forces Fedora Core 5 spec to be different from other distro specs Just taking the example of libxml2 upstream maintainer viewpoint this means: 1/ that I need to change my FAQ and user documentation to say that if you use Fedora Core X X>5 and you need static link, then user should also install libxml2-static and it must also be in the same rpm transaction as the main, devel and python packages otherwise this may just fail. 2/ that I either have to change my upstream packaging model, as I ship RPM and maintain my upstream and Fedora/RedHat spec in sync, or I must have different spec for upstream and Fedora which IMHO is a bad regression (and yes at least one other distro at least test the same spec file: Mandriva) Now multiply by the number of library we ship, to me you annoy the user and the maintainers. I really disagree with this myself. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From jwboyer at jdub.homelinux.org Thu Jul 28 11:35:02 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 28 Jul 2005 06:35:02 -0500 Subject: plague-client/buildsys client docs In-Reply-To: <1122540896.13300.29.camel@cutter> References: <1122540896.13300.29.camel@cutter> Message-ID: <1122550502.29547.2.camel@yoda.jdub.homelinux.org> On Thu, 2005-07-28 at 04:54 -0400, seth vidal wrote: > Hi folks, > I've written up some docs for using the plague-client interface. > They're available here: > http://fedoraproject.org/wiki/Extras/BuildSystemClientSetup Looks good. I was able to follow these and get it working just fine. > > At some point 'soon' in the future you'll need to have the plague-client > package installed in order to request builds. Right now, though, it will > just let you see what is going on with the buildsystem w/o going to the > web interface. It will also let you kill your own jobs or requeue your > own job if it failed for some spurious reason. So if one has plague-client installed correctly, can we start using it to request builds now? > > Once Dan wants to make a plague 0.3 release these packages will be in > fedora extras, but for the moment they're not. I hope a mock update comes with the plague 0.3 packages ;) Great job to both you and Dan. And thanks! josh From rc040203 at freenet.de Thu Jul 28 12:29:07 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 28 Jul 2005 14:29:07 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <20050728110539.GL10076@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> Message-ID: <1122553747.19663.34.camel@mccallum.corsepiu.local> On Thu, 2005-07-28 at 07:05 -0400, Daniel Veillard wrote: > On Fri, Jul 22, 2005 at 08:08:17PM -1000, Warren Togami wrote: > > Now multiply by the number of library we ship, to me you annoy the user > and the maintainers. > > I really disagree with this myself. Then let me turn your remark around into a devel's advocate question: Which packages in all RH based distributions (FC, FE, etc.) are statically linked against libxml and therefore will be subject to the vulnerability that allows arbitrary users to become root by parsing xml-files, to be discovered, tomorrow? Ralf From veillard at redhat.com Thu Jul 28 13:20:36 2005 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 28 Jul 2005 09:20:36 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122553747.19663.34.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <1122553747.19663.34.camel@mccallum.corsepiu.local> Message-ID: <20050728132036.GO10076@redhat.com> On Thu, Jul 28, 2005 at 02:29:07PM +0200, Ralf Corsepius wrote: > On Thu, 2005-07-28 at 07:05 -0400, Daniel Veillard wrote: > > On Fri, Jul 22, 2005 at 08:08:17PM -1000, Warren Togami wrote: > > > > > Now multiply by the number of library we ship, to me you annoy the user > > and the maintainers. > > > > I really disagree with this myself. > Then let me turn your remark around into a devel's advocate question: > > Which packages in all RH based distributions (FC, FE, etc.) are > statically linked against libxml and therefore will be subject to the > vulnerability that allows arbitrary users to become root by parsing > xml-files, to be discovered, tomorrow? I don't think there is any in the distro (I think open-office specific version was removed). The problem of course is for ISV and independant developpers. Sorry you tried to attack the problem from the wrong angle. I could not conclude whether you suspected libxml2 had security problems when parsing files, I hope not. Now if you are really worried, I would suggest you start chasing the various expat libraries used right and left some of them using the system ones but not all ... Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From skvidal at phy.duke.edu Thu Jul 28 13:51:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 09:51:51 -0400 Subject: plague-client/buildsys client docs In-Reply-To: <1122550502.29547.2.camel@yoda.jdub.homelinux.org> References: <1122540896.13300.29.camel@cutter> <1122550502.29547.2.camel@yoda.jdub.homelinux.org> Message-ID: <1122558711.13300.71.camel@cutter> > So if one has plague-client installed correctly, can we start using it > to request builds now? you can, sure. Just becareful that you run make tag first, please. > I hope a mock update comes with the plague 0.3 packages ;) > yah yah. In our copious free time. -sv From rc040203 at freenet.de Thu Jul 28 13:53:40 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 28 Jul 2005 15:53:40 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <20050728132036.GO10076@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <1122553747.19663.34.camel@mccallum.corsepiu.local> <20050728132036.GO10076@redhat.com> Message-ID: <1122558820.19663.56.camel@mccallum.corsepiu.local> On Thu, 2005-07-28 at 09:20 -0400, Daniel Veillard wrote: > On Thu, Jul 28, 2005 at 02:29:07PM +0200, Ralf Corsepius wrote: > > On Thu, 2005-07-28 at 07:05 -0400, Daniel Veillard wrote: > > > On Fri, Jul 22, 2005 at 08:08:17PM -1000, Warren Togami wrote: > > > > > > > > Now multiply by the number of library we ship, to me you annoy the user > > > and the maintainers. > > > > > > I really disagree with this myself. > > Then let me turn your remark around into a devel's advocate question: > > > > Which packages in all RH based distributions (FC, FE, etc.) are > > statically linked against libxml and therefore will be subject to the > > vulnerability that allows arbitrary users to become root by parsing > > xml-files, to be discovered, tomorrow? > > I don't think there is any in the distro (I think open-office specific > version was removed). You think ... this isn't enough. You should be sure, otherwise in case of serious emergency with libxml, _you_ can't react. > The problem of course is for ISV and independant > developpers. Sorry you tried to attack the problem from the wrong angle. Why, what's technically wrong with my proposal? What would you propose instead? Shipping static libraries to me means handing people a loaded gun. It's only a matter of time until somebody stumbles and shoots himself. > I could not conclude whether you suspected libxml2 had security problems > when parsing files, I hope not. Any widely used major library is potentially subject to vulnerabilities, especially those being used in applications with network access like libxml - You simply can't be sure - never. > Now if you are really worried, I would suggest > you start chasing the various expat libraries used right and left some > of them using the system ones but not all ... I am worried about all statically applications nobody exactly knows what they actually are linked against, and therefore are hot candidates to be missed during security updates. Ralf From jspaleta at gmail.com Thu Jul 28 13:54:01 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jul 2005 09:54:01 -0400 Subject: plague-client/buildsys client docs In-Reply-To: <1122558711.13300.71.camel@cutter> References: <1122540896.13300.29.camel@cutter> <1122550502.29547.2.camel@yoda.jdub.homelinux.org> <1122558711.13300.71.camel@cutter> Message-ID: <604aa7910507280654590f372c@mail.gmail.com> On 7/28/05, seth vidal wrote: > > I hope a mock update comes with the plague 0.3 packages ;) > > > > yah yah. In our copious free time. question... in the new buildsystem configuration.. what has replaced the "local" repo definition as provided in the default mock configs? for example: [local] name=local baseurl=http://extras64.linux.duke.edu/needsign/development/ Is there a new substitute for http://extras64.linux.duke.edu/needsign/development/ ? -jef From skvidal at phy.duke.edu Thu Jul 28 14:00:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 10:00:45 -0400 Subject: plague-client/buildsys client docs In-Reply-To: <604aa7910507280654590f372c@mail.gmail.com> References: <1122540896.13300.29.camel@cutter> <1122550502.29547.2.camel@yoda.jdub.homelinux.org> <1122558711.13300.71.camel@cutter> <604aa7910507280654590f372c@mail.gmail.com> Message-ID: <1122559245.13300.73.camel@cutter> On Thu, 2005-07-28 at 09:54 -0400, Jeff Spaleta wrote: > On 7/28/05, seth vidal wrote: > > > I hope a mock update comes with the plague 0.3 packages ;) > > > > > > > yah yah. In our copious free time. > > question... in the new buildsystem configuration.. what has replaced > the "local" repo definition as provided in the default mock configs? > for example: > [local] > name=local > baseurl=http://extras64.linux.duke.edu/needsign/development/ > > Is there a new substitute for > http://extras64.linux.duke.edu/needsign/development/ ? > yes, I'll update the location in mock's config files today in cvs and work on the mock 0.4 release. Fair enough? -sv From skvidal at phy.duke.edu Thu Jul 28 14:07:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 10:07:45 -0400 Subject: plague-client/buildsys client docs In-Reply-To: <604aa791050728070335dde9ca@mail.gmail.com> References: <1122540896.13300.29.camel@cutter> <1122550502.29547.2.camel@yoda.jdub.homelinux.org> <1122558711.13300.71.camel@cutter> <604aa7910507280654590f372c@mail.gmail.com> <1122559245.13300.73.camel@cutter> <604aa791050728070335dde9ca@mail.gmail.com> Message-ID: <1122559665.13300.75.camel@cutter> On Thu, 2005-07-28 at 10:03 -0400, Jeff Spaleta wrote: > On 7/28/05, seth vidal wrote: > > yes, I'll update the location in mock's config files today in cvs and > > work on the mock 0.4 release. Fair enough? > > Do i need to wait for the new mock? Let me be clear.. i'm not asking > for a new mock I just want to know where needsign lives now. I'd want > this documented outside of mock somewhere for a number of reasons, > primarily because I would think 3rd parties who need to rebuild > against new updates in FE would like to be able to track the needsign > directory to get a heads up of impending dep breakage caused by FE > updates. I just fixed it so the needsign path works. presto -sv From jspaleta at gmail.com Thu Jul 28 14:03:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 28 Jul 2005 10:03:53 -0400 Subject: plague-client/buildsys client docs In-Reply-To: <1122559245.13300.73.camel@cutter> References: <1122540896.13300.29.camel@cutter> <1122550502.29547.2.camel@yoda.jdub.homelinux.org> <1122558711.13300.71.camel@cutter> <604aa7910507280654590f372c@mail.gmail.com> <1122559245.13300.73.camel@cutter> Message-ID: <604aa791050728070335dde9ca@mail.gmail.com> On 7/28/05, seth vidal wrote: > yes, I'll update the location in mock's config files today in cvs and > work on the mock 0.4 release. Fair enough? Do i need to wait for the new mock? Let me be clear.. i'm not asking for a new mock I just want to know where needsign lives now. I'd want this documented outside of mock somewhere for a number of reasons, primarily because I would think 3rd parties who need to rebuild against new updates in FE would like to be able to track the needsign directory to get a heads up of impending dep breakage caused by FE updates. -jef From veillard at redhat.com Thu Jul 28 14:14:54 2005 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 28 Jul 2005 10:14:54 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122558820.19663.56.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <1122553747.19663.34.camel@mccallum.corsepiu.local> <20050728132036.GO10076@redhat.com> <1122558820.19663.56.camel@mccallum.corsepiu.local> Message-ID: <20050728141453.GP10076@redhat.com> On Thu, Jul 28, 2005 at 03:53:40PM +0200, Ralf Corsepius wrote: > On Thu, 2005-07-28 at 09:20 -0400, Daniel Veillard wrote: > > I don't think there is any in the distro (I think open-office specific > > version was removed). > You think ... this isn't enough. You should be sure, otherwise in case > of serious emergency with libxml, _you_ can't react. Well if you think not shipping a static lib will help, you're on crack sorry. OpenOffice used to have its own code tree *inside*. The problem is more to know who use what, and not shipping -static makes it even harder ! > > The problem of course is for ISV and independant > > developpers. Sorry you tried to attack the problem from the wrong angle. > Why, what's technically wrong with my proposal? What would you propose > instead? > > Shipping static libraries to me means handing people a loaded gun. > It's only a matter of time until somebody stumbles and shoots himself. We can stop shipping any compiler too, sounds the way to go. > I am worried about all statically applications nobody exactly knows what > they actually are linked against, and therefore are hot candidates to be > missed during security updates. The point is to educate upstream, not make the life of users miserable. It's like playing "we have a firewall so we are safe" game, it's wrong, static libs may be required, linking statically to libxml2 *Right Now* is a requirement for an ISV wanting to ship an LSB compliant application using libxml2. The best way to avoid what you are afraid of are: - make sure our set of libraries is API and ABI stable, including for C++ user - make sure the libraries gets into LSB once reaching that state - make sure people developping apps know about it and stop copying code or compile statically Forcing developpers to go though hoops to get where they need, inventing new process and loosing trackability of those is the wrong way. At least if you have a static library shipped, you can guess what application linked to it based on code analysis, and detect in as much as possible automatic way how to get them fixed. If developpers start having their in-house static compilation environment: - we loose as a developper platform - guessing what uses what statically starts becoming impossible. I really think your point of view is detrimental to the platform acceptance and to the overall manageability, sorry I still disagree with your approach to the problem (not with the problem !) Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From skvidal at phy.duke.edu Thu Jul 28 17:49:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 13:49:38 -0400 Subject: buildsys notice Message-ID: <1122572978.19679.25.camel@cutter> The Mesa colo is not accessible right now due to a planned outage. so don't submit any jobs to the buildsys right now via plague-client b/c we can't get to the ppc build box until the colo is back up. thanks, -sv From rrelyea at redhat.com Thu Jul 28 18:04:00 2005 From: rrelyea at redhat.com (Bob Relyea) Date: Thu, 28 Jul 2005 11:04:00 -0700 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E835D7.1070001@redhat.com> References: <42E1028C.20609@redhat.com> <42E64DDF.3050309@redhat.com> <42E70A91.9010403@redhat.com> <1122438200.4264.343.camel@mccallum.corsepiu.local> <42E71405.6010206@redhat.com> <1122440797.4264.348.camel@mccallum.corsepiu.local> <42E71A1C.1060400@redhat.com> <1122446367.4264.378.camel@mccallum.corsepiu.local> <42E79FEA.50607@redhat.com> <1122479751.4264.526.camel@mccallum.corsepiu.local> <42E7BEA6.8000503@redhat.com> <1122502670.2645.7.camel@localhost.localdomain> <42E835D7.1070001@redhat.com> Message-ID: <42E91E10.7080103@redhat.com> Christopher Aillon wrote: > Tom 'spot' Callaway wrote: >> On Wed, 2005-07-27 at 13:04 -0400, Christopher Aillon wrote: >> >> >>> It's not a trick. You're the one that's unabashedly trying to force >>> things down my throat. If you want it this badly, prove it and do >>> the work. This is how open source has come to thrive. >> >> >> Well, turns out its not that much work. I just removed the static libs, >> and noted the places where nss broke. >> >> Patch attached to fix Firefox Deer Park Alpha 2, should be applicable >> for anything else with nss bits. Turns out the patch requires a little more work, but not *that* much more work. I'll have a new patch attached shortly, I'm pretty sure it will pass NSS reviews;). BTW Thanks for the initial patch Tom. bob > > Thanks, I filed it as https://bugzilla.mozilla.org/show_bug.cgi?id=302416 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3340 bytes Desc: S/MIME Cryptographic Signature URL: From skvidal at phy.duke.edu Thu Jul 28 18:20:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 14:20:35 -0400 Subject: buildsys notice In-Reply-To: <1122572978.19679.25.camel@cutter> References: <1122572978.19679.25.camel@cutter> Message-ID: <1122574835.19679.31.camel@cutter> On Thu, 2005-07-28 at 13:49 -0400, seth vidal wrote: > The Mesa colo is not accessible right now due to a planned outage. > > so don't submit any jobs to the buildsys right now via plague-client b/c > we can't get to the ppc build box until the colo is back up. > things appear to be back - feel free to submit jobs. -sv From orion at cora.nwra.com Thu Jul 28 20:05:02 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 Jul 2005 14:05:02 -0600 Subject: plague-client/buildsys client docs In-Reply-To: <1122540896.13300.29.camel@cutter> References: <1122540896.13300.29.camel@cutter> Message-ID: <42E93A6E.20302@cora.nwra.com> seth vidal wrote: > Hi folks, > I've written up some docs for using the plague-client interface. > They're available here: > http://fedoraproject.org/wiki/Extras/BuildSystemClientSetup > > At some point 'soon' in the future you'll need to have the plague-client > package installed in order to request builds. Right now, though, it will > just let you see what is going on with the buildsystem w/o going to the > web interface. It will also let you kill your own jobs or requeue your > own job if it failed for some spurious reason. > > Once Dan wants to make a plague 0.3 release these packages will be in > fedora extras, but for the moment they're not. > > -sv > For devel builds do we use: plague-client 5 or plague-client devel ? Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From skvidal at phy.duke.edu Thu Jul 28 20:43:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 28 Jul 2005 16:43:34 -0400 Subject: plague-client/buildsys client docs In-Reply-To: <42E93A6E.20302@cora.nwra.com> References: <1122540896.13300.29.camel@cutter> <42E93A6E.20302@cora.nwra.com> Message-ID: <1122583414.19679.46.camel@cutter> > For devel builds do we use: > > plague-client 5 > > or > > plague-client devel > > ? devel. -sv From orion at cora.nwra.com Thu Jul 28 20:47:58 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 28 Jul 2005 14:47:58 -0600 Subject: CVS tag help needed Message-ID: <42E9447E.5010901@cora.nwra.com> I accidentally did a "make tag" with some locally modified files: $ make tag cvs tag -c python-matplotlib-0_83_1-1_fc5 For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs ? build.log ? i386 ? matplotlib-0.82.tar.gz ? matplotlib-0.83.1 ? python-matplotlib-0.83.1-1.src.rpm cvs tag: .cvsignore is locally modified cvs tag: sources is locally modified cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 I've checked in .cvsignore and sources now, but they are not tagged with python-matplotlib-0_83_1-1_fc5, and make tag now fails: $ make tag cvs tag -c python-matplotlib-0_83_1-1_fc5 For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs ? build.log ERROR: Tag python-matplotlib-0_83_1-1_fc5 has been already created. The following tags have been created so far python-matplotlib-0_82-2:devel:orion:1120167615 python-matplotlib-0_82-3_fc5:devel:orion:1120235006 python-matplotlib-0_82-4_fc5:devel:orion:1122582000 python-matplotlib-0_83_1-1_fc5:devel:orion:1122583172 cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! make: *** [tag] Error 1 What's the best way out? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From roland at redhat.com Thu Jul 28 20:52:08 2005 From: roland at redhat.com (Roland McGrath) Date: Thu, 28 Jul 2005 13:52:08 -0700 (PDT) Subject: CVS tag help needed In-Reply-To: Orion Poplawski's message of Thursday, 28 July 2005 14:47:58 -0600 <42E9447E.5010901@cora.nwra.com> Message-ID: <20050728205208.43BA0180EB8@magilla.sf.frob.com> Certainly the simplest thing is to just give up and bump the release number, start over with a different tag and forget about the botched one. From jakub at redhat.com Thu Jul 28 20:54:51 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 28 Jul 2005 16:54:51 -0400 Subject: CVS tag help needed In-Reply-To: <42E9447E.5010901@cora.nwra.com> References: <42E9447E.5010901@cora.nwra.com> Message-ID: <20050728205451.GY30077@devserv.devel.redhat.com> On Thu, Jul 28, 2005 at 02:47:58PM -0600, Orion Poplawski wrote: > $ make tag > cvs tag -c python-matplotlib-0_83_1-1_fc5 > For more information on using the Fedora CVS repositories, please visit > http://fedoraproject.org/wiki/UsingCvs > ? build.log > ERROR: Tag python-matplotlib-0_83_1-1_fc5 has been already created. > The following tags have been created so far > python-matplotlib-0_82-2:devel:orion:1120167615 > python-matplotlib-0_82-3_fc5:devel:orion:1120235006 > python-matplotlib-0_82-4_fc5:devel:orion:1122582000 > python-matplotlib-0_83_1-1_fc5:devel:orion:1122583172 > cvs tag: Pre-tag check failed > cvs [tag aborted]: correct the above errors first! > make: *** [tag] Error 1 > > What's the best way out? Verify that tagging that way is what you really want and use make force-tag instead. Jakub From bugs.michael at gmx.net Thu Jul 28 22:49:55 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Jul 2005 00:49:55 +0200 Subject: CVS tag help needed In-Reply-To: <20050728205451.GY30077@devserv.devel.redhat.com> References: <42E9447E.5010901@cora.nwra.com> <20050728205451.GY30077@devserv.devel.redhat.com> Message-ID: <20050729004955.75f695cc.bugs.michael@gmx.net> On Thu, 28 Jul 2005 16:54:51 -0400, Jakub Jelinek wrote: > On Thu, Jul 28, 2005 at 02:47:58PM -0600, Orion Poplawski wrote: > > $ make tag > > cvs tag -c python-matplotlib-0_83_1-1_fc5 > > For more information on using the Fedora CVS repositories, please visit > > http://fedoraproject.org/wiki/UsingCvs > > ? build.log > > ERROR: Tag python-matplotlib-0_83_1-1_fc5 has been already created. > > The following tags have been created so far > > python-matplotlib-0_82-2:devel:orion:1120167615 > > python-matplotlib-0_82-3_fc5:devel:orion:1120235006 > > python-matplotlib-0_82-4_fc5:devel:orion:1122582000 > > python-matplotlib-0_83_1-1_fc5:devel:orion:1122583172 > > cvs tag: Pre-tag check failed > > cvs [tag aborted]: correct the above errors first! > > make: *** [tag] Error 1 > > > > What's the best way out? > > Verify that tagging that way is what you really want and use > make force-tag instead. That one is not available with Extras. Above situation can only be corrected with plain "cvs" and proper options. But be careful, please. From katzj at redhat.com Fri Jul 29 04:21:34 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 29 Jul 2005 00:21:34 -0400 Subject: More status on the Extras buildsystem Message-ID: <1122610894.8768.17.camel@bree.local.net> We should now be up and running with all of the build machines for the Extras build system. There are now 3 machines for doing x86_64 and i386 builds and one machine for ppc builds. I've successfully done a build for FE3, FE4 and the development tree and so think everything should be sanely set up. If not, DO NOT SEND MAIL TO SETH :-) You can send mail here, to fedora-extras-list or file a bug in bugzilla against the Fedora Infrastructure product, buildsys component. Also, I've added a 'make plague' target to the Extras Makefile.common. This is for testing prior to switching 'make build' over to using plague-client. If you install the packages Seth pointed to[1], then this should work. If not, let me know[2]. And thirdly, there is going to be some network work going on tomorrow (Friday) evening between 2100 and 0200[3]. So some hiccups might occur then. Builds will hopefully resume after the outage is over, but worst case scenario is that I might have to kick stuff when I wake up Saturday morning. Jeremy [1] http://fedoraproject.org/wiki/Extras/BuildSystemClientSetup [2] A patch would be even better... :) [3] Timezone is America/New_York which should currently be -0400. You can use 'TZ="America/New_York" date' to find out the time here and figure out your offset from it. From icon at linux.duke.edu Fri Jul 29 04:49:38 2005 From: icon at linux.duke.edu (Konstantin Ryabitsev) Date: Fri, 29 Jul 2005 00:49:38 -0400 Subject: More status on the Extras buildsystem In-Reply-To: <1122610894.8768.17.camel@bree.local.net> References: <1122610894.8768.17.camel@bree.local.net> Message-ID: <42E9B562.4030302@linux.duke.edu> Jeremy Katz wrote: > Also, I've added a 'make plague' target to the Extras Makefile.common. So, when can we expect "make locusts" and "make babies die"? :) Thanks all for your work on the FEBS! Hmm.. FEBuS? FedEx BS? Cheers, --icon From skvidal at phy.duke.edu Fri Jul 29 06:09:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Jul 2005 02:09:05 -0400 Subject: repomanage'ing extras development Message-ID: <1122617345.2521.8.camel@cutter> Anyone have any objections if I run repomanage -o over top of extras development to purge out old packages? it's getting sorta unnecessarily big. -sv From skvidal at phy.duke.edu Fri Jul 29 06:50:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Jul 2005 02:50:34 -0400 Subject: tobuild file Message-ID: <1122619834.2521.13.camel@cutter> Hey folks, At this point all the jobs left to be submitted to the buildsys from the tobuild file have been submitted. Unless you have a compelling reason please don't submit anything new to the tobuild file. Try out the 'make plague' option and report any problems you have. Thanks, -sv From rc040203 at freenet.de Fri Jul 29 08:06:48 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Jul 2005 10:06:48 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <20050728141453.GP10076@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <1122553747.19663.34.camel@mccallum.corsepiu.local> <20050728132036.GO10076@redhat.com> <1122558820.19663.56.camel@mccallum.corsepiu.local> <20050728141453.GP10076@redhat.com> Message-ID: <1122624408.4941.81.camel@mccallum.corsepiu.local> On Thu, 2005-07-28 at 10:14 -0400, Daniel Veillard wrote: > On Thu, Jul 28, 2005 at 03:53:40PM +0200, Ralf Corsepius wrote: > > On Thu, 2005-07-28 at 09:20 -0400, Daniel Veillard wrote: > > > I don't think there is any in the distro (I think open-office specific > > > version was removed). > > You think ... this isn't enough. You should be sure, otherwise in case > > of serious emergency with libxml, _you_ can't react. > > Well if you think not shipping a static lib will help, you're on crack sorry. Thanks for this "warm" welcome ;) > OpenOffice used to have its own code tree *inside*. That's a completely different problem. > and not shipping -static makes it even harder ! I am not talking about "banishing static libs", I am talking about moving static libs from "*-devel" packages into "*-static" packages to raise the threshold for users/applications wanting to link against them. > > > The problem of course is for ISV and independant > > > developpers. Sorry you tried to attack the problem from the wrong angle. > > Why, what's technically wrong with my proposal? What would you propose > > instead? > > > > Shipping static libraries to me means handing people a loaded gun. > > It's only a matter of time until somebody stumbles and shoots himself. > > We can stop shipping any compiler too, sounds the way to go. With all due respect, ... > > I am worried about all statically applications nobody exactly knows what > > they actually are linked against, and therefore are hot candidates to be > > missed during security updates. > > The point is to educate upstream, not make the life of users miserable. > It's like playing "we have a firewall so we are safe" game, it's wrong, > static libs may be required, linking statically to libxml2 *Right Now* is > a requirement for an ISV wanting to ship an LSB compliant application using > libxml2. Where from the LSB do you conclude the LSB is disallowing dependencies on shared libs? I don't see any such requirement. > The best way to avoid what you are afraid of are: > - make sure our set of libraries is API and ABI stable, including for > C++ user LSB-compliant, C++ and ABI ... see http://gcc.gnu.org/ml/gcc/2004-07/threads.html > I really think your point of view is detrimental to the platform acceptance > and to the overall manageability, I don't see this, conversely, such a change would be transparent to the majority of users/developers, because "BR: *-devel" would remain functional as before for those packages providing shared libs. Only those packages which explicitly try to link statically would be affected. Ralf From petersen at redhat.com Fri Jul 29 08:35:34 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Jul 2005 17:35:34 +0900 Subject: CVS tag help needed In-Reply-To: <20050729004955.75f695cc.bugs.michael@gmx.net> References: <42E9447E.5010901@cora.nwra.com> <20050728205451.GY30077@devserv.devel.redhat.com> <20050729004955.75f695cc.bugs.michael@gmx.net> Message-ID: <42E9EA56.6060505@redhat.com> Michael Schwendt wrote: > On Thu, 28 Jul 2005 16:54:51 -0400, Jakub Jelinek wrote: > > >>On Thu, Jul 28, 2005 at 02:47:58PM -0600, Orion Poplawski wrote: >> >>> $ make tag >>>cvs tag: Pre-tag check failed >>>cvs [tag aborted]: correct the above errors first! >>>make: *** [tag] Error 1 >>> >>>What's the best way out? >> >>Verify that tagging that way is what you really want and use >>make force-tag instead. > > That one is not available with Extras. Above situation can only > be corrected with plain "cvs" and proper options. But be careful, > please. I haven't tried it yet but AFAICT "make tag TAG_OPTS=-F" does the equivalent of "make force-tag" for core cvs. I still think force-tag would be useful for Extras too though... comments? Jens From veillard at redhat.com Fri Jul 29 08:56:54 2005 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 29 Jul 2005 04:56:54 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122624408.4941.81.camel@mccallum.corsepiu.local> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <1122553747.19663.34.camel@mccallum.corsepiu.local> <20050728132036.GO10076@redhat.com> <1122558820.19663.56.camel@mccallum.corsepiu.local> <20050728141453.GP10076@redhat.com> <1122624408.4941.81.camel@mccallum.corsepiu.local> Message-ID: <20050729085653.GZ10076@redhat.com> On Fri, Jul 29, 2005 at 10:06:48AM +0200, Ralf Corsepius wrote: > On Thu, 2005-07-28 at 10:14 -0400, Daniel Veillard wrote: > > On Thu, Jul 28, 2005 at 03:53:40PM +0200, Ralf Corsepius wrote: > > > On Thu, 2005-07-28 at 09:20 -0400, Daniel Veillard wrote: > > > > I don't think there is any in the distro (I think open-office specific > > > > version was removed). > > > You think ... this isn't enough. You should be sure, otherwise in case > > > of serious emergency with libxml, _you_ can't react. > > > > Well if you think not shipping a static lib will help, you're on crack sorry. > Thanks for this "warm" welcome ;) Maybe I'm the one offbase, but to me this is a significant breakage, I think this is one more thing which will just push ISV to only use RHEL and not Fedora Core for development, maybe this is a good thing from a different perspective, but from my viewpoint as an upstream maintainer of widely reused libraries I consider this a big regression. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From petersen at redhat.com Fri Jul 29 09:02:10 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Jul 2005 18:02:10 +0900 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <20050728110539.GL10076@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> Message-ID: <42E9F092.8030902@redhat.com> Daniel Veillard wrote: > I dislike that. Any non-LSB lib should have static libs available one way > or another from the distro otherwise we just make the distro unsuitable for > ISV development (from an LSB POV). Ok, fair point. Except for some of the gnome libs perhaps as was pointed out earlier. > 1/ breaks all the documentation and user expectations I don't see this, since most users don't need static libs at all anyway. > 2/ forces Fedora Core 5 spec to be different from other distro specs Perhaps we can encourage other distros to follow suite? > then user should also install libxml2-static and it must also be in the same rpm > transaction as the main, devel and python packages otherwise this > may just fail. Why would libxml2-static have to be installed in the same rpm transaction? > Now multiply by the number of library we ship, to me you annoy the user > and the maintainers. Maintainers perhaps, but it seems most users don't need static libs at all. > I really disagree with this myself. Ok, but what about all the wasted bandwidth of users who are forced to download static libs as part of -devel packages every time they update that they never ever use? Thanks for your comments, Jens From veillard at redhat.com Fri Jul 29 09:43:43 2005 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 29 Jul 2005 05:43:43 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E9F092.8030902@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> Message-ID: <20050729094343.GA10076@redhat.com> On Fri, Jul 29, 2005 at 06:02:10PM +0900, Jens Petersen wrote: > Daniel Veillard wrote: > > then user should also install libxml2-static and it must also be in the same rpm > > transaction as the main, devel and python packages otherwise this > > may just fail. > > Why would libxml2-static have to be installed in the same rpm transaction? because you really can't allow -static and -devel to mismatch > > Now multiply by the number of library we ship, to me you annoy the user > > and the maintainers. > > Maintainers perhaps, but it seems most users don't need static libs at all. for me an user, i.e. the person who need to be aware that the library exists is a developper, not an end-user. The end-user can't care less, or should not. > > I really disagree with this myself. > > Ok, but what about all the wasted bandwidth of users who are forced to download > static libs as part of -devel packages every time they update that they never > ever use? Tell me first why an end-user should need a -devel package ever ? Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From bugs.michael at gmx.net Fri Jul 29 10:04:34 2005 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 29 Jul 2005 12:04:34 +0200 Subject: CVS tag help needed In-Reply-To: <42E9EA56.6060505@redhat.com> References: <42E9447E.5010901@cora.nwra.com> <20050728205451.GY30077@devserv.devel.redhat.com> <20050729004955.75f695cc.bugs.michael@gmx.net> <42E9EA56.6060505@redhat.com> Message-ID: <20050729120434.68268cc4.bugs.michael@gmx.net> On Fri, 29 Jul 2005 17:35:34 +0900, Jens Petersen wrote: > > be corrected with plain "cvs" and proper options. But be careful, > > please. > > I haven't tried it yet but AFAICT "make tag TAG_OPTS=-F" does the equivalent > of "make force-tag" for core cvs. > > I still think force-tag would be useful for Extras too though... comments? Convenient access to dangerous options bears an unknown risk, IMO. From petersen at redhat.com Fri Jul 29 10:05:35 2005 From: petersen at redhat.com (Jens Petersen) Date: Fri, 29 Jul 2005 19:05:35 +0900 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <20050729094343.GA10076@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> Message-ID: <42E9FF6F.7070307@redhat.com> Daniel Veillard wrote: > On Fri, Jul 29, 2005 at 06:02:10PM +0900, Jens Petersen wrote: > >>Why would libxml2-static have to be installed in the same rpm transaction? > > because you really can't allow -static and -devel to mismatch Err, can't the -static package just requires the -devel package with the same EVR? >>Maintainers perhaps, but it seems most users don't need static libs at all. > > for me an user, i.e. the person who need to be aware that the library exists > is a developper, not an end-user. The end-user can't care less, or should not. Yep, by user here I meant developers of the distro, as in users of -devel packages. Sorry for the confusion. :) >>Ok, but what about all the wasted bandwidth of users who are forced to download >>static libs as part of -devel packages every time they update that they never >>ever use? > > Tell me first why an end-user should need a -devel package ever ? Indeed people who don't need -devel packages don't need -static either. My concern is developers having to download static libs that they never use. Jens From jakub at redhat.com Fri Jul 29 10:09:46 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 29 Jul 2005 06:09:46 -0400 Subject: CVS tag help needed In-Reply-To: <20050729120434.68268cc4.bugs.michael@gmx.net> References: <42E9447E.5010901@cora.nwra.com> <20050728205451.GY30077@devserv.devel.redhat.com> <20050729004955.75f695cc.bugs.michael@gmx.net> <42E9EA56.6060505@redhat.com> <20050729120434.68268cc4.bugs.michael@gmx.net> Message-ID: <20050729100945.GA30077@devserv.devel.redhat.com> On Fri, Jul 29, 2005 at 12:04:34PM +0200, Michael Schwendt wrote: > On Fri, 29 Jul 2005 17:35:34 +0900, Jens Petersen wrote: > > > > be corrected with plain "cvs" and proper options. But be careful, > > > please. > > > > I haven't tried it yet but AFAICT "make tag TAG_OPTS=-F" does the equivalent > > of "make force-tag" for core cvs. > > > > I still think force-tag would be useful for Extras too though... comments? > > Convenient access to dangerous options bears an unknown risk, IMO. make force-tag is really useful, e.g. when: 1) you forgot to say make FILES=new-tarball new-source and make build fails because it can't find the tarball. Then you just run make ... new-source; cvs ci; make force-tag and make build again 2) if make build fails for some other reason, e.g. some patch contains a fatal bug that causes compilation failure. There is no point to bump %{release} as rpm with that %{release} hasn't ever been built. Jakub From veillard at redhat.com Fri Jul 29 10:17:09 2005 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 29 Jul 2005 06:17:09 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E9FF6F.7070307@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> <42E9FF6F.7070307@redhat.com> Message-ID: <20050729101709.GB10076@redhat.com> On Fri, Jul 29, 2005 at 07:05:35PM +0900, Jens Petersen wrote: > Daniel Veillard wrote: > > On Fri, Jul 29, 2005 at 06:02:10PM +0900, Jens Petersen wrote: > > > >>Why would libxml2-static have to be installed in the same rpm transaction? > > > > because you really can't allow -static and -devel to mismatch > > Err, can't the -static package just requires the -devel package with the same EVR? yes so you need a single transaction for anything which may upgrade any of the packages. This is confusing a lot of people even developpers when they are new with the platform, yum helps a lot there. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From rc040203 at freenet.de Fri Jul 29 10:20:50 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Jul 2005 12:20:50 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <20050729094343.GA10076@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> Message-ID: <1122632450.4941.88.camel@mccallum.corsepiu.local> On Fri, 2005-07-29 at 05:43 -0400, Daniel Veillard wrote: > On Fri, Jul 29, 2005 at 06:02:10PM +0900, Jens Petersen wrote: > > Daniel Veillard wrote: > > > then user should also install libxml2-static and it must also be in the same rpm > > > transaction as the main, devel and python packages otherwise this > > > may just fail. > > > > Why would libxml2-static have to be installed in the same rpm transaction? Not true. > because you really can't allow -static and -devel to mismatch -static: Requires: -devel = %{name}-%{version} Ralf From jspaleta at gmail.com Fri Jul 29 12:08:49 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 29 Jul 2005 08:08:49 -0400 Subject: repomanage'ing extras development In-Reply-To: <1122617345.2521.8.camel@cutter> References: <1122617345.2521.8.camel@cutter> Message-ID: <604aa7910507290508706bc558@mail.gmail.com> On 7/29/05, seth vidal wrote: > Anyone have any objections if I run repomanage -o over top of extras > development to purge out old packages? > > it's getting sorta unnecessarily big. I have no problem with repomanage -o being scripted to run everyday for extras development.. considering its tracking the rolling rawhide tree. -jef From fedora at camperquake.de Fri Jul 29 13:33:25 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 29 Jul 2005 15:33:25 +0200 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E9FF6F.7070307@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> <42E9FF6F.7070307@redhat.com> Message-ID: <20050729153325.2e7738d5@nausicaa.camperquake.de> Hi. Jens Petersen wrote: > Indeed people who don't need -devel packages don't need -static either. > My concern is developers having to download static libs that they never > use. Given the fact that selecting "development" in the installation process will give you almost each and every -devel package the system has to offer anyway I thinks this is a kind of moot point. Disk space is cheap. And yes, I do use static libraries. Rarely, but I do. Building binaries for a different distribution that do specialized things very important at that time without having to worry about dynamic libraries has saved my ass more than once. -- Nothing is fool-proof to a sufficiently talented fool. From skvidal at phy.duke.edu Fri Jul 29 13:37:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Jul 2005 09:37:26 -0400 Subject: CVS tag help needed In-Reply-To: <20050729100945.GA30077@devserv.devel.redhat.com> References: <42E9447E.5010901@cora.nwra.com> <20050728205451.GY30077@devserv.devel.redhat.com> <20050729004955.75f695cc.bugs.michael@gmx.net> <42E9EA56.6060505@redhat.com> <20050729120434.68268cc4.bugs.michael@gmx.net> <20050729100945.GA30077@devserv.devel.redhat.com> Message-ID: <1122644246.2521.21.camel@cutter> On Fri, 2005-07-29 at 06:09 -0400, Jakub Jelinek wrote: > On Fri, Jul 29, 2005 at 12:04:34PM +0200, Michael Schwendt wrote: > > On Fri, 29 Jul 2005 17:35:34 +0900, Jens Petersen wrote: > > > > > > be corrected with plain "cvs" and proper options. But be careful, > > > > please. > > > > > > I haven't tried it yet but AFAICT "make tag TAG_OPTS=-F" does the equivalent > > > of "make force-tag" for core cvs. > > > > > > I still think force-tag would be useful for Extras too though... comments? > > > > Convenient access to dangerous options bears an unknown risk, IMO. > > make force-tag is really useful, e.g. when: > 1) you forgot to say make FILES=new-tarball new-source > and make build fails because it can't find the tarball. > Then you just run make ... new-source; cvs ci; make force-tag > and make build again > 2) if make build fails for some other reason, e.g. some patch > contains a fatal bug that causes compilation failure. > There is no point to bump %{release} as rpm with that %{release} > hasn't ever been built. you don't need to increment release and bump anymore. The new buildsys will rebuild things it already built. however, everyone should be doing 'make mock' before they submit their builds, right? :) -sv From jspaleta at gmail.com Fri Jul 29 14:10:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 29 Jul 2005 10:10:53 -0400 Subject: CVS tag help needed In-Reply-To: <1122644246.2521.21.camel@cutter> References: <42E9447E.5010901@cora.nwra.com> <20050728205451.GY30077@devserv.devel.redhat.com> <20050729004955.75f695cc.bugs.michael@gmx.net> <42E9EA56.6060505@redhat.com> <20050729120434.68268cc4.bugs.michael@gmx.net> <20050729100945.GA30077@devserv.devel.redhat.com> <1122644246.2521.21.camel@cutter> Message-ID: <604aa7910507290710fccfc47@mail.gmail.com> On 7/29/05, seth vidal wrote: > however, everyone should be doing 'make mock' before they submit their > builds, right? :) Perhaps its time to refresh the wiki's standard recipe of steps when prepping for a build request. make tag is mentioned.. make mock isn't. -jef From katzj at redhat.com Fri Jul 29 14:28:24 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 29 Jul 2005 10:28:24 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <20050729153325.2e7738d5@nausicaa.camperquake.de> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> <42E9FF6F.7070307@redhat.com> <20050729153325.2e7738d5@nausicaa.camperquake.de> Message-ID: <1122647305.8768.21.camel@bree.local.net> On Fri, 2005-07-29 at 15:33 +0200, Ralf Ertzinger wrote: > Jens Petersen wrote: > > Indeed people who don't need -devel packages don't need -static either. > > My concern is developers having to download static libs that they never > > use. > > Given the fact that selecting "development" in the installation process > will give you almost each and every -devel package the system has to > offer anyway I thinks this is a kind of moot point. Disk space is cheap. And if the static libs are split out, then it will give you the -static packages as well. But at a huge cost of maintenance for the comps file + overhead of more headers in the rpmdb (with duplicated changelogs, etc). The more I think about this, the more I think that it's a solution in search of a real problem. Jeremy From jspaleta at gmail.com Fri Jul 29 16:46:00 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 29 Jul 2005 12:46:00 -0400 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <1122647305.8768.21.camel@bree.local.net> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> <20050729094343.GA10076@redhat.com> <42E9FF6F.7070307@redhat.com> <20050729153325.2e7738d5@nausicaa.camperquake.de> <1122647305.8768.21.camel@bree.local.net> Message-ID: <604aa791050729094658c38860@mail.gmail.com> On 7/29/05, Jeremy Katz wrote: > And if the static libs are split out, then it will give you the -static > packages as well. But at a huge cost of maintenance for the comps file > + overhead of more headers in the rpmdb (with duplicated changelogs, > etc). > > The more I think about this, the more I think that it's a solution in > search of a real problem. What is the recommended process for people who desire building a static binary.. for say in-house usage? If Fedora as a general rule is removing static libs from binary packages... do people have to rebuild the packages with editted spec files to get the staic libs back? If so can there be a macro definition that can be used a switch to quickly rebuild these src.rpms locally to get the statics back.. avoiding the need to edit a spec file by hand? -jef From orion at cora.nwra.com Fri Jul 29 16:51:23 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 29 Jul 2005 10:51:23 -0600 Subject: changing mock directory Message-ID: <42EA5E8B.40205@cora.nwra.com> I'm trying to move the mock chroot base from /var/lib/mock to /export/mock, without much success: mock -r fedora-5-i386-core.cfg /export/home/orion/fedora/extras/pytz/devel/pytz-2005i-2.fc5.src.rpm Errors cleaning out chroot: mock-helper: error: /export/mock/fedora-5-i386-core: not under allowed directory (/var/lib/mock) Starting Prep Preparing Root could not mount proc error was: mock-helper: error: proc: mount not allowed on /export/mock/fedora-5-i386-core/root/proc could not mount /dev/pts error was: mock-helper: error: devpts: mount not allowed on /export/mock/fedora-5-i386-core/root/dev/pts Traceback (most recent call last): File "/usr/bin/mock", line 672, in ? main() File "/usr/bin/mock", line 664, in main my.close() File "/usr/bin/mock", line 297, in close self._umount_by_file() File "/usr/bin/mock", line 382, in _umount_by_file self._umount(item) File "/usr/bin/mock", line 364, in _umount raise Error, "could not umount %s error was: %s" % (path, output) __main__.Error: could not umount proc error was: mock-helper: error: /export/mock/fedora-5-i386-core/root/proc: not under allowed directory (/var/lib/mock) make: *** [mockbuild] Error 1 I just don't have room in /var. Is /var/lib/mock hardcoded somewhere? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From skvidal at phy.duke.edu Fri Jul 29 16:56:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Jul 2005 12:56:39 -0400 Subject: changing mock directory In-Reply-To: <42EA5E8B.40205@cora.nwra.com> References: <42EA5E8B.40205@cora.nwra.com> Message-ID: <1122656199.6197.33.camel@cutter> On Fri, 2005-07-29 at 10:51 -0600, Orion Poplawski wrote: > I'm trying to move the mock chroot base from /var/lib/mock to > /export/mock, without much success: > > mock -r fedora-5-i386-core.cfg > /export/home/orion/fedora/extras/pytz/devel/pytz-2005i-2.fc5.src.rpm > Errors cleaning out chroot: mock-helper: error: > /export/mock/fedora-5-i386-core: not under allowed directory (/var/lib/mock) > Starting Prep > Preparing Root > could not mount proc error was: mock-helper: error: proc: mount not > allowed on /export/mock/fedora-5-i386-core/root/proc > could not mount /dev/pts error was: mock-helper: error: devpts: mount > not allowed on /export/mock/fedora-5-i386-core/root/dev/pts > Traceback (most recent call last): > File "/usr/bin/mock", line 672, in ? > main() > File "/usr/bin/mock", line 664, in main > my.close() > File "/usr/bin/mock", line 297, in close > self._umount_by_file() > File "/usr/bin/mock", line 382, in _umount_by_file > self._umount(item) > File "/usr/bin/mock", line 364, in _umount > raise Error, "could not umount %s error was: %s" % (path, output) > __main__.Error: could not umount proc error was: mock-helper: error: > /export/mock/fedora-5-i386-core/root/proc: not under allowed directory > (/var/lib/mock) > make: *** [mockbuild] Error 1 > > I just don't have room in /var. Is /var/lib/mock hardcoded somewhere? yes. in the suid helper. It's a known 'bug' without a good resolution in code. We're probably going to remove the option from the config file and tell people it has to be in /var/lib/mock you can just bind-mount /export/mock to /var/lib/mock and it will work just fine. -sv From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 29 17:02:26 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 29 Jul 2005 19:02:26 +0200 Subject: tobuild file In-Reply-To: <1122619834.2521.13.camel@cutter> (seth vidal's message of "Fri, 29 Jul 2005 02:50:34 -0400") References: <1122619834.2521.13.camel@cutter> Message-ID: <87fytx4kbh.fsf@kosh.bigo.ensc.de> skvidal at phy.duke.edu (seth vidal) writes: > Unless you have a compelling reason please don't submit anything new to > the tobuild file. Try out the 'make plague' option and report any > problems you have. plague seems to try to connect directly with the buildserver. This will not work in most corporate or complex environments: | [ensc at kosh ~]$ plague-client list_builders | Error connecting to build server: '(110, 'Connection timed out')' From the packet-filter: | [drop] IN=eth0 OUT=eth2 SRC=192.168.46.2 DST=152.3.220.164 LEN=60 TOS=0x00 PREC=0x00 TTL=74 ID=15979 DF PROTO=TCP SPT=38501 DPT=8887 SEQ=3481872747 ACK=0 WINDOW=5840 RES=0x00 CWR ECE SYN URGP=0 OPT (020405B40402080A575FC6D00000000001030302) ($https_proxy is set to a correctly) You will have to add proxy support and let the buildserver listen on standard ports (443 would be appropriate as CONNECT is usually allowed for this ports). Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 29 17:21:13 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 29 Jul 2005 19:21:13 +0200 Subject: changing mock directory In-Reply-To: <42EA5E8B.40205@cora.nwra.com> (Orion Poplawski's message of "Fri, 29 Jul 2005 10:51:23 -0600") References: <42EA5E8B.40205@cora.nwra.com> Message-ID: <87br4l4jg6.fsf@kosh.bigo.ensc.de> orion at cora.nwra.com (Orion Poplawski) writes: > File "/usr/bin/mock", line 364, in _umount > raise Error, "could not umount %s error was: %s" % (path, output) > __main__.Error: could not umount proc error was: mock-helper: error: > /export/mock/fedora-5-i386-core/root/proc: not under allowed directory > (/var/lib/mock) Caused by too much security checks at the wrong place ('mock-helper chroot ...' gives full control over the system, so these path-checks (which can be workarounded with symlinks) are senseless). Best thing for functionality would be: * execute mock in an own namespace; so you do not have to care about unmounting * do the mounting nativly (call 'mount(2)' instead of exec(2) the 'mount' command) * for all other commands, do just an 'execv(argv[1], argv+1)' in mock-helpers main() routine Patches for the first two points are existing already. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From skvidal at phy.duke.edu Fri Jul 29 17:25:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Jul 2005 13:25:14 -0400 Subject: changing mock directory In-Reply-To: <87br4l4jg6.fsf@kosh.bigo.ensc.de> References: <42EA5E8B.40205@cora.nwra.com> <87br4l4jg6.fsf@kosh.bigo.ensc.de> Message-ID: <1122657915.6197.36.camel@cutter> On Fri, 2005-07-29 at 19:21 +0200, Enrico Scholz wrote: > orion at cora.nwra.com (Orion Poplawski) writes: > > > File "/usr/bin/mock", line 364, in _umount > > raise Error, "could not umount %s error was: %s" % (path, output) > > __main__.Error: could not umount proc error was: mock-helper: error: > > /export/mock/fedora-5-i386-core/root/proc: not under allowed directory > > (/var/lib/mock) > > Caused by too much security checks at the wrong place ('mock-helper > chroot ...' gives full control over the system, so these path-checks > (which can be workarounded with symlinks) are senseless). Best thing for > functionality would be: > > * execute mock in an own namespace; so you do not have to care about > unmounting > * do the mounting nativly (call 'mount(2)' instead of exec(2) the 'mount' > command) > * for all other commands, do just an 'execv(argv[1], argv+1)' in > mock-helpers main() routine > > Patches for the first two points are existing already. where? -sv From enrico.scholz at informatik.tu-chemnitz.de Fri Jul 29 17:47:58 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 29 Jul 2005 19:47:58 +0200 Subject: changing mock directory In-Reply-To: <1122657915.6197.36.camel@cutter> (seth vidal's message of "Fri, 29 Jul 2005 13:25:14 -0400") References: <42EA5E8B.40205@cora.nwra.com> <87br4l4jg6.fsf@kosh.bigo.ensc.de> <1122657915.6197.36.camel@cutter> Message-ID: <877jf94i7l.fsf@kosh.bigo.ensc.de> skvidal at phy.duke.edu (seth vidal) writes: >> * execute mock in an own namespace; so you do not have to care about >> unmounting >> * do the mounting nativly (call 'mount(2)' instead of exec(2) the 'mount' >> command) > > >> * for all other commands, do just an 'execv(argv[1], argv+1)' in >> mock-helpers main() routine >> >> Patches for the first two points are existing already. > > where? http://ensc.de/fedora/mock-namespace.diff (the native mounting was done for a new usecase for environments without CAP_MKNOD only; but proc-/devpts-mounting can be done similarly as it is not more than a | mount("none", destpath, "proc", 0, 0) ) Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rc040203 at freenet.de Fri Jul 29 19:36:46 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Jul 2005 21:36:46 +0200 Subject: tobuild file In-Reply-To: <1122619834.2521.13.camel@cutter> References: <1122619834.2521.13.camel@cutter> Message-ID: <1122665806.4941.154.camel@mccallum.corsepiu.local> On Fri, 2005-07-29 at 02:50 -0400, seth vidal wrote: > Hey folks, > At this point all the jobs left to be submitted to the buildsys from > the tobuild file have been submitted. > > Unless you have a compelling reason please don't submit anything new to > the tobuild file. Try out the 'make plague' option and report any > problems you have. I would highly recommend to extend mock's and the plague-* programs' CLI to comply better with the GNU Standards: http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces i.e. please implement --help and --version Ralf From skvidal at phy.duke.edu Fri Jul 29 19:42:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Jul 2005 15:42:09 -0400 Subject: tobuild file In-Reply-To: <1122665806.4941.154.camel@mccallum.corsepiu.local> References: <1122619834.2521.13.camel@cutter> <1122665806.4941.154.camel@mccallum.corsepiu.local> Message-ID: <1122666129.6197.54.camel@cutter> On Fri, 2005-07-29 at 21:36 +0200, Ralf Corsepius wrote: > On Fri, 2005-07-29 at 02:50 -0400, seth vidal wrote: > > Hey folks, > > At this point all the jobs left to be submitted to the buildsys from > > the tobuild file have been submitted. > > > > Unless you have a compelling reason please don't submit anything new to > > the tobuild file. Try out the 'make plague' option and report any > > problems you have. > > I would highly recommend to extend mock's and the plague-* programs' CLI > to comply better with the GNU Standards: > http://www.gnu.org/prep/standards/standards.html#Command_002dLine-Interfaces > > i.e. please implement --help and --version > mock supports --help and --version. I'll look at plague-client shortly for that. -sv From orion at cora.nwra.com Fri Jul 29 19:54:37 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 29 Jul 2005 13:54:37 -0600 Subject: Clearing out failed builds Message-ID: <42EA897D.1010808@cora.nwra.com> Do failed builds clear out eventually or do we have to remove them. If so, how? Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From skvidal at phy.duke.edu Fri Jul 29 20:03:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 29 Jul 2005 16:03:34 -0400 Subject: Clearing out failed builds In-Reply-To: <42EA897D.1010808@cora.nwra.com> References: <42EA897D.1010808@cora.nwra.com> Message-ID: <1122667414.6197.58.camel@cutter> On Fri, 2005-07-29 at 13:54 -0600, Orion Poplawski wrote: > Do failed builds clear out eventually or do we have to remove them. If > so, how? > It's something that is as-yet to be implemented. We need to do cleanup of a lot of places. I think a plague-client clean jobid might make sense to purge the jobid and only have it work on killed and failed jobs. What do you think? -sv From rc040203 at freenet.de Fri Jul 29 20:01:22 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 29 Jul 2005 22:01:22 +0200 Subject: tobuild file In-Reply-To: <1122666129.6197.54.camel@cutter> References: <1122619834.2521.13.camel@cutter> <1122665806.4941.154.camel@mccallum.corsepiu.local> <1122666129.6197.54.camel@cutter> Message-ID: <1122667282.4941.161.camel@mccallum.corsepiu.local> On Fri, 2005-07-29 at 15:42 -0400, seth vidal wrote: > On Fri, 2005-07-29 at 21:36 +0200, Ralf Corsepius wrote: > > On Fri, 2005-07-29 at 02:50 -0400, seth vidal wrote: > > i.e. please implement --help and --version > > > > mock supports --help and --version. Sorry, you are right - I just started playing with plague-client and didn't explicitly check mock. BTW: I would be nice to see this changed: [root at mccallum]# mock --help Don't try to run mock as root! IMO, mock should at least allow --help and --version for root. Ralf From orion at cora.nwra.com Fri Jul 29 20:03:13 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 29 Jul 2005 14:03:13 -0600 Subject: Clearing out failed builds In-Reply-To: <1122667414.6197.58.camel@cutter> References: <42EA897D.1010808@cora.nwra.com> <1122667414.6197.58.camel@cutter> Message-ID: <42EA8B81.1030602@cora.nwra.com> seth vidal wrote: > It's something that is as-yet to be implemented. We need to do cleanup > of a lot of places. I think a plague-client clean jobid might make sense > to purge the jobid and only have it work on killed and failed jobs. > > What do you think? plague-client clean works for me. Best for the developer to explicitly deal with it I think. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Fri Jul 29 21:05:01 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 29 Jul 2005 15:05:01 -0600 Subject: CVS tag help needed In-Reply-To: <1122644246.2521.21.camel@cutter> References: <42E9447E.5010901@cora.nwra.com> <20050728205451.GY30077@devserv.devel.redhat.com> <20050729004955.75f695cc.bugs.michael@gmx.net> <42E9EA56.6060505@redhat.com> <20050729120434.68268cc4.bugs.michael@gmx.net> <20050729100945.GA30077@devserv.devel.redhat.com> <1122644246.2521.21.camel@cutter> Message-ID: <42EA99FD.1050406@cora.nwra.com> seth vidal wrote: > > however, everyone should be doing 'make mock' before they submit their > builds, right? :) > > -sv > It appears to be "make mockbuild". I will now... -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From tcallawa at redhat.com Fri Jul 29 21:17:49 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Jul 2005 16:17:49 -0500 Subject: Help with blacs Message-ID: <1122671869.2775.100.camel@localhost.localdomain> In the attempt to improve blacs, I've patched it to build shared libraries in addition to the static ones it already generates. With the code checked into CVS, I was able to successfully build a blacs package with shared libraries on FC-3. It also uses those shared libraries to build its test executables. However, for FC-4 and devel, x86 and x86_64 cannot use the shared libraries it generates to build its test executables. For the life of me, I can't figure out why this is happening. The only difference between FC-3 and FC-4/devel is that FC-3 uses g77 for the fortran bits, and FC-4/devel uses gfortran. The working (plague built) FC-3 blacs packages and logs are here: http://buildsys.fedoraproject.org/logs//3/201-blacs-1.1-11.fc3/ The broken (plague failed) FC-4 blacs bits and logs are here: http://buildsys.fedoraproject.org/logs//4/202-blacs-1.1-11.fc4/ Of course, to add insult to injury, FC-4 ppc works perfectly. If anyone can help me figure out what is going on here (and fix it), I would be very grateful. Here is a diff between the FC-3 and FC-4 cvs branches: [spot at swoop blacs]$ diff -urp FC-3/ FC-4 --exclude=Entries --exclude=branch --exclude=Repository diff -urp --exclude=Entries --exclude=branch --exclude=Repository FC-3/blacs.spec FC-4/blacs.spec --- FC-3/blacs.spec 2005-07-29 14:41:40.000000000 -0500 +++ FC-4/blacs.spec 2005-07-29 14:42:08.000000000 -0500 @@ -15,7 +15,7 @@ Source6: http://www.netlib.org/blacs/f77 Source7: http://www.netlib.org/blacs/cblacsqref.ps Source8: http://www.netlib.org/blacs/lawn94.ps Source9: Bmake.inc.64bit -BuildRequires: gcc-g77 +BuildRequires: gcc-gfortran # Lam before 7.1.1-5 is missing: # -shared library support # -fPIC compilation flag diff -urp --exclude=Entries --exclude=branch --exclude=Repository FC-3/Bmake.inc FC-4/Bmake.inc --- FC-3/Bmake.inc 2005-07-12 14:46:23.000000000 -0500 +++ FC-4/Bmake.inc 2005-07-12 14:46:24.000000000 -0500 @@ -203,8 +203,8 @@ # optimization. This is the F77NO_OPTFLAG. The usage of the remaining # macros should be obvious from the names. #============================================================================= - F77 = g77 - F77NO_OPTFLAGS = $(RPM_OPT_FLAGS) -ff90 -Wno-globals -fno-globals -fPIC + F77 = gfortran + F77NO_OPTFLAGS = $(RPM_OPT_FLAGS) -fPIC F77FLAGS = $(F77NO_OPTFLAGS) -O F77LOADER = $(F77) F77LOADFLAGS = diff -urp --exclude=Entries --exclude=branch --exclude=Repository FC-3/Bmake.inc.64bit FC-4/Bmake.inc.64bit --- FC-3/Bmake.inc.64bit 2005-07-12 14:46:23.000000000 -0500 +++ FC-4/Bmake.inc.64bit 2005-07-12 14:46:24.000000000 -0500 @@ -203,8 +203,8 @@ # optimization. This is the F77NO_OPTFLAG. The usage of the remaining # macros should be obvious from the names. #============================================================================= - F77 = g77 - F77NO_OPTFLAGS = $(RPM_OPT_FLAGS) -ff90 -Wno-globals -fno-globals -fPIC + F77 = gfortran + F77NO_OPTFLAGS = $(RPM_OPT_FLAGS) -fPIC F77FLAGS = $(F77NO_OPTFLAGS) -O F77LOADER = $(F77) F77LOADFLAGS = Thanks in advance, ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From orion at cora.nwra.com Fri Jul 29 21:30:13 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 29 Jul 2005 15:30:13 -0600 Subject: Help with blacs In-Reply-To: <1122671869.2775.100.camel@localhost.localdomain> References: <1122671869.2775.100.camel@localhost.localdomain> Message-ID: <42EA9FE5.2090306@cora.nwra.com> Tom 'spot' Callaway wrote: > In the attempt to improve blacs, I've patched it to build shared > libraries in addition to the static ones it already generates. > > With the code checked into CVS, I was able to successfully build a blacs > package with shared libraries on FC-3. It also uses those shared > libraries to build its test executables. > > However, for FC-4 and devel, x86 and x86_64 cannot use the shared > libraries it generates to build its test executables. > > For the life of me, I can't figure out why this is happening. The only > difference between FC-3 and FC-4/devel is that FC-3 uses g77 for the > fortran bits, and FC-4/devel uses gfortran. That's the difference. g77 uses two underscores following the function name, gfortran now uses the more common convention of a single underscore. The makefile is defining -Df77IsF2C, which in Bconfig.h turns on ADD_ which adds an extra _. Looks like you need a new Bmake.inc that uses INTFACE=NoChange (I think). -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From orion at cora.nwra.com Fri Jul 29 21:54:59 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 29 Jul 2005 15:54:59 -0600 Subject: Cannot get mock to work Message-ID: <42EAA5B3.6040306@cora.nwra.com> I'm having trouble getting mock to setup the chroot environment. Specifically, the groupinstall build is failing with lots of rpm script errors: error: %post(libgcc-4.0.1-4.fc4.i386) scriptlet failed, exit status 255 error: %post(glibc-common-2.3.5-10.i386) scriptlet failed, exit status 255 error: %post(glibc-2.3.5-10.i686) scriptlet failed, exit status 255 error: %post(libselinux-1.23.10-2.i386) scriptlet failed, exit status 255 error: %post(zlib-1.2.2.2-5.fc4.i386) scriptlet failed, exit status 255 error: %post(e2fsprogs-1.37-4.i386) scriptlet failed, exit status 255 error: %post(bzip2-libs-1.0.2-16.i386) scriptlet failed, exit status 255 error: %post(elfutils-libelf-0.108-1.i386) scriptlet failed, exit status 255 error: %post(popt-1.10.1-22.i386) scriptlet failed, exit status 255 error: %post(libstdc++-4.0.1-4.fc4.i386) scriptlet failed, exit status 255 error: %post(beecrypt-4.1.2-8.i386) scriptlet failed, exit status 255 error: %post(expat-1.95.8-6.i386) scriptlet failed, exit status 255 error: %post(db4-4.3.27-3.i386) scriptlet failed, exit status 255 error: %post(libtermcap-2.0.8-41.i386) scriptlet failed, exit status 255 error: %post(bash-3.0-31.i386) scriptlet failed, exit status 255 error: %post(ncurses-5.4-17.i386) scriptlet failed, exit status 255 error: %post(info-4.8-4.i386) scriptlet failed, exit status 255 error: %post(readline-5.0-3.i386) scriptlet failed, exit status 255 error: %post(sqlite-3.1.2-3.i386) scriptlet failed, exit status 255 error: %post(gawk-3.1.4-5.2.i386) scriptlet failed, exit status 255 error: %post(findutils-4.2.20-1.i386) scriptlet failed, exit status 255 error: %post(sed-4.1.4-1.i386) scriptlet failed, exit status 255 error: %post(m4-1.4.3-1.i386) scriptlet failed, exit status 255 error: %post(gdbm-1.8.0-25.i386) scriptlet failed, exit status 255 error: %post(cpp-4.0.1-4.fc4.i386) scriptlet failed, exit status 255 error: %post(cpio-2.6-7.i386) scriptlet failed, exit status 255 error: %post(tar-1.15.1-7.FC4.i386) scriptlet failed, exit status 255 error: %post(binutils-2.15.94.0.2.2-2.1.i386) scriptlet failed, exit status 255 error: %post(gzip-1.3.5-6.i386) scriptlet failed, exit status 255 error: %post(net-tools-1.60-52.i386) scriptlet failed, exit status 255 error: %post(cracklib-2.8.2-1.i386) scriptlet failed, exit status 255 error: %post(libxml2-2.6.20-1.FC4.i386) scriptlet failed, exit status 255 error: %post(iputils-20020927-22.i386) scriptlet failed, exit status 255 error: %post(elfutils-0.108-1.i386) scriptlet failed, exit status 255 error: %post(file-4.13-4.i386) scriptlet failed, exit status 255 error: %post(audit-libs-0.9.19-2.FC4.i386) scriptlet failed, exit status 255 error: %post(tcp_wrappers-7.6-39.i386) scriptlet failed, exit status 255 error: %post(libsepol-1.5.10-1.1.i386) scriptlet failed, exit status 255 error: %post(glib2-2.6.4-1.i386) scriptlet failed, exit status 255 error: %post(pcre-5.0-4.i386) scriptlet failed, exit status 255 error: %post(grep-2.5.1-48.2.i386) scriptlet failed, exit status 255 error: %pre(MAKEDEV-3.19-1.i386) scriptlet failed, exit status 255 and so on.... Is there any way I can find out what is actually failing? -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From tcallawa at redhat.com Fri Jul 29 21:59:37 2005 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 29 Jul 2005 16:59:37 -0500 Subject: Help with blacs In-Reply-To: <42EA9FE5.2090306@cora.nwra.com> References: <1122671869.2775.100.camel@localhost.localdomain> <42EA9FE5.2090306@cora.nwra.com> Message-ID: <1122674377.2775.102.camel@localhost.localdomain> On Fri, 2005-07-29 at 15:30 -0600, Orion Poplawski wrote: > Tom 'spot' Callaway wrote: > > In the attempt to improve blacs, I've patched it to build shared > > libraries in addition to the static ones it already generates. > > > > With the code checked into CVS, I was able to successfully build a blacs > > package with shared libraries on FC-3. It also uses those shared > > libraries to build its test executables. > > > > However, for FC-4 and devel, x86 and x86_64 cannot use the shared > > libraries it generates to build its test executables. > > > > For the life of me, I can't figure out why this is happening. The only > > difference between FC-3 and FC-4/devel is that FC-3 uses g77 for the > > fortran bits, and FC-4/devel uses gfortran. > > That's the difference. g77 uses two underscores following the function > name, gfortran now uses the more common convention of a single > underscore. The makefile is defining -Df77IsF2C, which in Bconfig.h > turns on ADD_ which adds an extra _. Looks like you need a new > Bmake.inc that uses INTFACE=NoChange (I think). You're exactly right about the failure! When I set it to INTFACE=Add_, it works again. I owe you one. :) ~spot -- Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260 Fedora Extras Steering Committee Member (RPM Standards and Practices) Aurora Linux Project Leader: http://auroralinux.org Lemurs, llamas, and sparcs, oh my! From dcbw at redhat.com Fri Jul 29 23:31:49 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 29 Jul 2005 19:31:49 -0400 (EDT) Subject: Cannot get mock to work In-Reply-To: <42EAA5B3.6040306@cora.nwra.com> References: <42EAA5B3.6040306@cora.nwra.com> Message-ID: On Fri, 29 Jul 2005, Orion Poplawski wrote: > I'm having trouble getting mock to setup the chroot environment. > Specifically, the groupinstall build is failing with lots of rpm script > errors: > > error: %post(libgcc-4.0.1-4.fc4.i386) scriptlet failed, exit status 255 > error: %post(glibc-common-2.3.5-10.i386) scriptlet failed, exit status 255 Just for kicks, try turning SELinux off. 'setenforce 0' or modify /etc/sysconfig/selinux. While mock should work correctly with selinux on, this is a lot like what I was getting before Jeremy added selinux support to mock. Dan From dcbw at redhat.com Fri Jul 29 23:34:02 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 29 Jul 2005 19:34:02 -0400 (EDT) Subject: Clearing out failed builds In-Reply-To: <42EA897D.1010808@cora.nwra.com> References: <42EA897D.1010808@cora.nwra.com> Message-ID: On Fri, 29 Jul 2005, Orion Poplawski wrote: > Do failed builds clear out eventually or do we have to remove them. If > so, how? I guess I'd rather have the server do something, but having the developer do it would be fine too I guess. Note that I'm planning to revamp some of the state/stage stuff with PackageJob after I get back, and that may take care of this. In the mean time, I'm sure Seth can figure something out? But I'd caution against changing the job's state/stage to something else other than 'failed' at this point since a lot of code depends on that stage. Maybe we just need a "show me in the UI" bit for each job in the job database that devs can set on/off. Dan From jwboyer at jdub.homelinux.org Fri Jul 29 23:54:34 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 29 Jul 2005 18:54:34 -0500 Subject: Cannot get mock to work In-Reply-To: References: <42EAA5B3.6040306@cora.nwra.com> Message-ID: <1122681274.4755.1.camel@yoda.jdub.homelinux.org> On Fri, 2005-07-29 at 19:31 -0400, Dan Williams wrote: > On Fri, 29 Jul 2005, Orion Poplawski wrote: > > > I'm having trouble getting mock to setup the chroot environment. > > Specifically, the groupinstall build is failing with lots of rpm script > > errors: > > > > error: %post(libgcc-4.0.1-4.fc4.i386) scriptlet failed, exit status 255 > > error: %post(glibc-common-2.3.5-10.i386) scriptlet failed, exit status 255 > > Just for kicks, try turning SELinux off. 'setenforce 0' or modify > /etc/sysconfig/selinux. > > While mock should work correctly with selinux on, this is a lot like what I was > getting before Jeremy added selinux support to mock. Which has yet to actually be released as an update to the extras package. So unless Orion is running with the CVS version of mock, SELinux could very well be the problem. josh From paul at city-fan.org Fri Jul 29 16:56:30 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 29 Jul 2005 17:56:30 +0100 Subject: changing mock directory In-Reply-To: <42EA5E8B.40205@cora.nwra.com> References: <42EA5E8B.40205@cora.nwra.com> Message-ID: <42EA5FBE.5080109@city-fan.org> Orion Poplawski wrote: > I'm trying to move the mock chroot base from /var/lib/mock to > /export/mock, without much success: > > mock -r fedora-5-i386-core.cfg > /export/home/orion/fedora/extras/pytz/devel/pytz-2005i-2.fc5.src.rpm > Errors cleaning out chroot: mock-helper: error: > /export/mock/fedora-5-i386-core: not under allowed directory > (/var/lib/mock) > Starting Prep > Preparing Root > could not mount proc error was: mock-helper: error: proc: mount not > allowed on /export/mock/fedora-5-i386-core/root/proc > could not mount /dev/pts error was: mock-helper: error: devpts: mount > not allowed on /export/mock/fedora-5-i386-core/root/dev/pts > Traceback (most recent call last): > File "/usr/bin/mock", line 672, in ? > main() > File "/usr/bin/mock", line 664, in main > my.close() > File "/usr/bin/mock", line 297, in close > self._umount_by_file() > File "/usr/bin/mock", line 382, in _umount_by_file > self._umount(item) > File "/usr/bin/mock", line 364, in _umount > raise Error, "could not umount %s error was: %s" % (path, output) > __main__.Error: could not umount proc error was: mock-helper: error: > /export/mock/fedora-5-i386-core/root/proc: not under allowed directory > (/var/lib/mock) > make: *** [mockbuild] Error 1 > > I just don't have room in /var. Is /var/lib/mock hardcoded somewhere? Yes, it is. Use a bind mount instead. e.g. in /etc/fstab /export/mock /var/lib/mock auto bind 0 0 Paul. From skvidal at phy.duke.edu Sat Jul 30 14:17:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 30 Jul 2005 10:17:39 -0400 Subject: Cannot get mock to work In-Reply-To: <1122681274.4755.1.camel@yoda.jdub.homelinux.org> References: <42EAA5B3.6040306@cora.nwra.com> <1122681274.4755.1.camel@yoda.jdub.homelinux.org> Message-ID: <1122733060.7609.4.camel@cutter> On Fri, 2005-07-29 at 18:54 -0500, Josh Boyer wrote: > On Fri, 2005-07-29 at 19:31 -0400, Dan Williams wrote: > > On Fri, 29 Jul 2005, Orion Poplawski wrote: > > > > > I'm having trouble getting mock to setup the chroot environment. > > > Specifically, the groupinstall build is failing with lots of rpm script > > > errors: > > > > > > error: %post(libgcc-4.0.1-4.fc4.i386) scriptlet failed, exit status 255 > > > error: %post(glibc-common-2.3.5-10.i386) scriptlet failed, exit status 255 > > > > Just for kicks, try turning SELinux off. 'setenforce 0' or modify > > /etc/sysconfig/selinux. > > > > While mock should work correctly with selinux on, this is a lot like what I was > > getting before Jeremy added selinux support to mock. > > Which has yet to actually be released as an update to the extras > package. So unless Orion is running with the CVS version of mock, > SELinux could very well be the problem. > even with the latest selinux-handling code there still seems to be a few problems. Though it might only be with the rhel4 kernel. -sv From skvidal at phy.duke.edu Sat Jul 30 14:24:30 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 30 Jul 2005 10:24:30 -0400 Subject: Cannot get mock to work In-Reply-To: <1122733060.7609.4.camel@cutter> References: <42EAA5B3.6040306@cora.nwra.com> <1122681274.4755.1.camel@yoda.jdub.homelinux.org> <1122733060.7609.4.camel@cutter> Message-ID: <1122733470.7609.12.camel@cutter> > > Which has yet to actually be released as an update to the extras > > package. So unless Orion is running with the CVS version of mock, > > SELinux could very well be the problem. > > One more thing. Here is the stuff I want to do before releasing mock 0.4 1. make up mock and plague webpages and release places so I don't have to keep putting them in ~skvidal off of linux.duke.edu :) 2. work on the documentation of mock a bit. if anyone wants to help with either of those - let me know, please. thanks. -sv From byte at aeon.com.my Sun Jul 31 00:43:48 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 31 Jul 2005 08:43:48 +0800 Subject: [Fwd: Fedora Rewards] Message-ID: <1122770629.8973.719.camel@potter.soho.bytebot.net> Maintainers, If you feel someone is worthy of receiving some gifts/goodies (t-shirts, caps, bumper stickers), please don't hesitate to send fedorarewards at fedoraproject.org and e-mail message with your target recipient of a gift (just an e-mail address and reason as to why recipient deserves gift should be good enough - fedora rewards can take care of the rest) Any questions can be directed down my way (or matt's) Kind regards, Colin Your Fedora Marketing Man -- Colin Charles, http://www.bytebot.net/ -------------- next part -------------- An embedded message was scrubbed... From: Matt Frye Subject: Fedora Rewards Date: Thu, 28 Jul 2005 09:41:14 -0400 Size: 3835 URL: From ville.skytta at iki.fi Sun Jul 31 08:57:43 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 31 Jul 2005 11:57:43 +0300 Subject: CVS tag help needed In-Reply-To: <20050729100945.GA30077@devserv.devel.redhat.com> References: <42E9447E.5010901@cora.nwra.com> <20050728205451.GY30077@devserv.devel.redhat.com> <20050729004955.75f695cc.bugs.michael@gmx.net> <42E9EA56.6060505@redhat.com> <20050729120434.68268cc4.bugs.michael@gmx.net> <20050729100945.GA30077@devserv.devel.redhat.com> Message-ID: <1122800263.1285.5.camel@localhost.localdomain> On Fri, 2005-07-29 at 06:09 -0400, Jakub Jelinek wrote: > On Fri, Jul 29, 2005 at 12:04:34PM +0200, Michael Schwendt wrote: > > > > Convenient access to dangerous options bears an unknown risk, IMO. Seconded. > There is no point to bump %{release} as rpm with that %{release} > hasn't ever been built. Well, we're not running out of numbers to use in the release tag, so it doesn't hurt anything either, and works better than force-tagging in the "fundamentals of version control" sense. From ville.skytta at iki.fi Sun Jul 31 09:05:50 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 31 Jul 2005 12:05:50 +0300 Subject: Cannot get mock to work In-Reply-To: <1122733470.7609.12.camel@cutter> References: <42EAA5B3.6040306@cora.nwra.com> <1122681274.4755.1.camel@yoda.jdub.homelinux.org> <1122733060.7609.4.camel@cutter> <1122733470.7609.12.camel@cutter> Message-ID: <1122800750.1285.11.camel@localhost.localdomain> On Sat, 2005-07-30 at 10:24 -0400, seth vidal wrote: > 1. make up mock and plague webpages and release places so I don't have > to keep putting them in ~skvidal off of linux.duke.edu :) How about keeping the FE CVS populated with up to date versions of mock and plague (the latter apparently needs importing, dunno about the state of the former)? Even if the actual packages are not built and shipped yet, I think this would make things easier. From skvidal at phy.duke.edu Sun Jul 31 09:12:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 31 Jul 2005 05:12:17 -0400 Subject: Cannot get mock to work In-Reply-To: <1122800750.1285.11.camel@localhost.localdomain> References: <42EAA5B3.6040306@cora.nwra.com> <1122681274.4755.1.camel@yoda.jdub.homelinux.org> <1122733060.7609.4.camel@cutter> <1122733470.7609.12.camel@cutter> <1122800750.1285.11.camel@localhost.localdomain> Message-ID: <1122801137.7609.32.camel@cutter> On Sun, 2005-07-31 at 12:05 +0300, Ville Skytt? wrote: > On Sat, 2005-07-30 at 10:24 -0400, seth vidal wrote: > > > 1. make up mock and plague webpages and release places so I don't have > > to keep putting them in ~skvidal off of linux.duke.edu :) > > How about keeping the FE CVS populated with up to date versions of mock > and plague (the latter apparently needs importing, dunno about the state > of the former)? Even if the actual packages are not built and shipped > yet, I think this would make things easier. > but it already exists in fedora cvs. /cvs/fedora/mock -sv From ville.skytta at iki.fi Sun Jul 31 10:30:42 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 31 Jul 2005 13:30:42 +0300 Subject: Cannot get mock to work In-Reply-To: <1122801137.7609.32.camel@cutter> References: <42EAA5B3.6040306@cora.nwra.com> <1122681274.4755.1.camel@yoda.jdub.homelinux.org> <1122733060.7609.4.camel@cutter> <1122733470.7609.12.camel@cutter> <1122800750.1285.11.camel@localhost.localdomain> <1122801137.7609.32.camel@cutter> Message-ID: <1122805842.1285.23.camel@localhost.localdomain> On Sun, 2005-07-31 at 05:12 -0400, seth vidal wrote: > On Sun, 2005-07-31 at 12:05 +0300, Ville Skytt? wrote: > > On Sat, 2005-07-30 at 10:24 -0400, seth vidal wrote: > > > > > 1. make up mock and plague webpages and release places so I don't have > > > to keep putting them in ~skvidal off of linux.duke.edu :) > > > > How about keeping the FE CVS populated with up to date versions of mock > > and plague (the latter apparently needs importing, dunno about the state > > of the former)? Even if the actual packages are not built and shipped > > yet, I think this would make things easier. > > but it already exists in fedora cvs. > > /cvs/fedora/mock Sure, and I believe plague is also somewhere there. But I mentioned and asked about "FE CVS", in other words, the usual Extras packages CVS tree just like all other packages. So that people could just "make build" and nobody would have to use ~skvidal off of linux.duke.edu. From ville.skytta at iki.fi Sun Jul 31 10:35:47 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 31 Jul 2005 13:35:47 +0300 Subject: Cannot get mock to work In-Reply-To: <1122805842.1285.23.camel@localhost.localdomain> References: <42EAA5B3.6040306@cora.nwra.com> <1122681274.4755.1.camel@yoda.jdub.homelinux.org> <1122733060.7609.4.camel@cutter> <1122733470.7609.12.camel@cutter> <1122800750.1285.11.camel@localhost.localdomain> <1122801137.7609.32.camel@cutter> <1122805842.1285.23.camel@localhost.localdomain> Message-ID: <1122806147.1285.24.camel@localhost.localdomain> On Sun, 2005-07-31 at 13:30 +0300, Ville Skytt? wrote: > So that people could just "make build" Oops, s/build/i386/ From ville.skytta at iki.fi Sun Jul 31 11:56:19 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 31 Jul 2005 14:56:19 +0300 Subject: proposal to remove static libs from -devel packages for FC5 In-Reply-To: <42E9F092.8030902@redhat.com> References: <42E1028C.20609@redhat.com> <42E1DED1.9060803@redhat.com> <20050728110539.GL10076@redhat.com> <42E9F092.8030902@redhat.com> Message-ID: <1122810979.1285.34.camel@localhost.localdomain> On Fri, 2005-07-29 at 18:02 +0900, Jens Petersen wrote: > Daniel Veillard wrote: > > > 2/ forces Fedora Core 5 spec to be different from other distro specs > > Perhaps we can encourage other distros to follow suite? FWIW, PLD (www.pld.org.pl) has already done the -devel/-static separation for a long time AFAIK, and Mandriva seems to be heading that way too (using -devel/-static-devel). From ed at eh3.com Sun Jul 31 19:30:36 2005 From: ed at eh3.com (Ed Hill) Date: Sun, 31 Jul 2005 15:30:36 -0400 Subject: More status on the Extras buildsystem In-Reply-To: <1122610894.8768.17.camel@bree.local.net> References: <1122610894.8768.17.camel@bree.local.net> Message-ID: <1122838237.25925.139.camel@ernie> On Fri, 2005-07-29 at 00:21 -0400, Jeremy Katz wrote: > We should now be up and running with all of the build machines for the > Extras build system. There are now 3 machines for doing x86_64 and i386 > builds and one machine for ppc builds. I've successfully done a build > for FE3, FE4 and the development tree and so think everything should be > sanely set up. If not, DO NOT SEND MAIL TO SETH :-) You can send mail > here, to fedora-extras-list or file a bug in bugzilla against the Fedora > Infrastructure product, buildsys component. Thank you for the explanation! I have no idea whether the following is a bug or my incompetence so please point out either. ;-) cvs co rpms/opendap rpms/nco for i in opendap nco ; do for j in FC-3 FC-4 devel ; do ( cd rpms/${i}/${j} ; make tag ; make plague ) done done which seems to work just fine judging by the output generated. Unfortunately, the command plague-client list email ed at eh3.com lists only the three udunits builds that I submitted yesterday using, AFAICT, exactly the same procedure. And they seem to have built without any problems. So, what went wrong this time? Can anyone help me figure it out...? Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464