From jeff at ocjtech.us Sun Jul 1 02:33:30 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Sat, 30 Jun 2007 21:33:30 -0500 Subject: Koji and SVN In-Reply-To: <200706301448.24864.jkeating@redhat.com> References: <6a28481b0706281533p76a8bbfbmafebede5b9140057@mail.gmail.com> <200706301448.24864.jkeating@redhat.com> Message-ID: <1183257210.3564.5.camel@lt21223.campus.dmacc.edu> On Sat, 2007-06-30 at 14:48 -0400, Jesse Keating wrote: > On Thursday 28 June 2007 18:33:59 Oscar Victorio Calixto Bacho wrote: > > Hi List > > > > I have two questions > > > > Koji can support SVN at the moment? > > Not currently. > > > why not? > > The source control mechanism used by the Fedora project for it's packages is > currently CVS. It also looks like that any move away from CVS would be > toward a distributed SCM such as git or hg due to the things a distributed > SCM offers over CVS/SVN. > > However patches to Koji that enable svn support won't be turned away, provided > they're good (: There are patches for Koji attached to this ticket: https://hosted.fedoraproject.org/projects/koji/ticket/15 I can't comment as to the quality, as I haven't tested them... Jeff -------------- 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 prarit at redhat.com Sun Jul 1 12:16:02 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Sun, 01 Jul 2007 08:16:02 -0400 Subject: [ANNOUNCE]: thetango SRPM dependency system Message-ID: <46879B02.3050105@redhat.com> The problems associated with bootstrapping an OS on a new architecture have been around for a long time. The issues with doing so are numerous -- how to build, what order should the packages in the OS be built in, how to identify build dependencies, etc. Determining a build map, or build tree, would go a long way in decreasing the time to entirely rebuild or bootstrap an architecture. As a starting point, a brute force build method of repeatedly traversing the F7 SRPM list alphabetically was done. This resulted in approximately 2500 packages built over a week -- far short of the complete list of SRPMS. The frequency of successful builds slowed down dramatically after this number of SRPMS were built. The perl-* SRPMS are particularily nasty ... thetango attempts to resolve the build problem by taking a set of SRPMS and building build trees by evaluating the dependencies between the potential resulting binary RPMs, and determining the build tree for individual SRPMS. * I have not put this in source control yet. The TODO section has an entry about this and that is something I hope to complete in the next week. http://home.comcast.net/~prarit/thetango/ Prarit Bhargava prarit at redhat.com oftc.net: #ia64 From Axel.Thimm at ATrpms.net Sun Jul 1 22:36:56 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 2 Jul 2007 00:36:56 +0200 Subject: : thetango SRPM dependency system In-Reply-To: <46879B02.3050105@redhat.com> References: <46879B02.3050105@redhat.com> Message-ID: <20070701223656.GB30962@puariko.nirvana> On Sun, Jul 01, 2007 at 08:16:02AM -0400, Prarit Bhargava wrote: > The problems associated with bootstrapping an OS on a new architecture have > been around for a long time. The issues with doing so are numerous -- how > to build, what order should the packages in the OS be built in, how to > identify build dependencies, etc. Determining a build map, or build tree, > would go a long way in decreasing the time to entirely rebuild or bootstrap > an architecture. > > As a starting point, a brute force build method of repeatedly traversing > the F7 SRPM list alphabetically was done. This resulted in > approximately 2500 > packages built over a week -- far short of the complete list of SRPMS. > The frequency of successful builds slowed down dramatically after this > number > of SRPMS were built. The perl-* SRPMS are particularily nasty ... How can thetango know that perl-Foo will be providing perl(Bar) which perl-Baz BuildRequires? E.g. how can any automatic provides be guessed by thetango? A not-too-far away goal is to have a perl()-like system for python and other languages, which means more and more BRs depending on virtual automatic provides that you can only detect after a build, not before. I guess that if thetango cannot compute the depdency then it probably gets discarded to at least get some better ordering, but the final build will still need a brute force iterative approach. > thetango attempts to resolve the build problem by taking a set of SRPMS and > building build trees by evaluating the dependencies between the potential > resulting binary RPMs, and determining the build tree for individual SRPMS. > > * I have not put this in source control yet. The TODO section has an > entry about this and that is something I hope to complete in the next week. > > http://home.comcast.net/~prarit/thetango/ > > Prarit Bhargava > prarit at redhat.com > oftc.net: #ia64 > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From prarit at redhat.com Sun Jul 1 23:47:20 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Sun, 01 Jul 2007 19:47:20 -0400 Subject: : thetango SRPM dependency system In-Reply-To: <20070701223656.GB30962@puariko.nirvana> References: <46879B02.3050105@redhat.com> <20070701223656.GB30962@puariko.nirvana> Message-ID: <46883D08.6080400@redhat.com> Hi Axel, > > How can thetango know that perl-Foo will be providing perl(Bar) which > perl-Baz BuildRequires? > Good question, and I knew someone was going to ask how I got around that particular issue. perl-* was a real pain to deal with. /usr/lib/rpm/perl.prov is run on every source package to generate a close-to-complete list of perl(Bar::Foo) includes. I explode the source, but do not compile, and run perl.prov on it. This generates the perl(Bar::Foo) package entries. For example perl-AppConfig-1.64-1.fc7.src.rpm provides: perl-AppConfig perl(AppConfig) perl(AppConfig::Args) perl(AppConfig::CGI) perl(AppConfig::File) perl(AppConfig::Getopt) perl(AppConfig::State) perl(AppConfig::Sys) > E.g. how can any automatic provides be guessed by thetango? A > not-too-far away goal is to have a perl()-like system for python and > other languages, which means more and more BRs depending on virtual > automatic provides that you can only detect after a build, not before. > > IIRC, there were only a handful of these. I haven't decided what to do with these packages. It maybe useful to have an additional list (perl-prov?) that is queried and perl.prov is run on them if they are in the list. perl(mod_perl2) mod_perl-2.0.3-7.src.rpm perl(Apache2::Cookie) libapreq2-2.09-0.rc2.4.fc7.src.rpm perl(Apache2::Request) libapreq2-2.09-0.rc2.4.fc7.src.rpm perl(Apache::Test) mod_perl-2.0.3-7.src.rpm perl(Config) perl-5.8.8-18.fc7.src.rpm perl(Data::UUID) uuid-1.5.1-3.fc7.src.rpm perl(Errno) perl-5.8.8-18.fc7.src.rpm perl(Image::Magick) ImageMagick-6.3.2.9-3.fc7.src.rpm perl(Mail::SpamAssassin) spamassassin-3.2.0-1.fc7.src.rpm perl(Newt) newt-0.52.6-3.fc7.src.rpm perl(RRDs) rrdtool-1.2.23-3.fc7.src.rpm perl(SVN::Core) subversion-1.4.3-4.src.rpm perl(XML::SAX::Base) perl-XML-SAX-0.15-1.noarch.rpm perl(XML::SAX::Exception) perl-XML-SAX-0.15-1.noarch.rpm php-pear(PEAR) php-pear-PEAR-Command-Packaging-0.1.2-5.fc6.src.rpm As I point out in the code, this same process needs to be done for python. P. > I guess that if thetango cannot compute the depdency then it probably > gets discarded to at least get some better ordering, but the final > build will still need a brute force iterative approach. > > Nope. This absolutely is 100 times better than a brute force iterative approach. IMO of course :) P. From wacker at octothorp.org Mon Jul 2 04:20:31 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Sun, 1 Jul 2007 22:20:31 -0600 (MDT) Subject: Pungi can't gather SRPMS after installation of yum-3.2.1-1. Message-ID: After installing the above mentioned version of Yum, pungi prints the following error to the screen. Error: Cannot find a source rpm for yp-tools-2.9-0.1 The last few lines of the log contain nothing useful, or so it seems. INFO:yum.verbose.pungi:/home/wacker/moonshine/cache/hsqldb-1.8.0.7-2jpp.2.i386.rpm already exists and appears to be complete INFO:yum.verbose.pungi:/home/wacker/moonshine/cache/kipi-plugins-0.1.3-5.fc7.i386.rpm already exists and appears to be complete INFO:yum.verbose.pungi:/home/wacker/moonshine/cache/slang-devel-2.0.7-2.fc7.i386.rpm already exists and appears to be complete INFO:yum.verbose.pungi:/home/wacker/moonshine/cache/mediawiki-1.9.2-33.fc7.i386.rpm already exists and appears to be complete INFO:yum.verbose.pungi:/home/wacker/moonshine/cache/xdg-user-dirs-gtk-0.5-1.fc7.i386.rpm already exists and appears to be complete DEBUG:yum.verbose.YumBase:Setting up Package Sacks DEBUG:yum.verbose.YumBase:Setting up Package Sacks Reverting to the previous version of Yum fixes the problem. -- Bill in Denver From wacker at octothorp.org Mon Jul 2 04:31:15 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Sun, 1 Jul 2007 22:31:15 -0600 (MDT) Subject: Making sure all dependencies are met when using Pungi Message-ID: As packages are updated, they can grow dependencies. An example is that libpurple now requires libhowl.so.o, found in avahi-compat-howl. Yet, Pungi doesn't complain about the missing package. In the logs, I find that when libpurple is examined, there's a list of dependencies, but libhowl.so.0 is nowhere to be found. Where does Pungi get its dependency info? One would think that it comes from the metadata in the repo, which is local, in my case. -- Bill in Denver From jgranado at redhat.com Mon Jul 2 09:01:10 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Mon, 02 Jul 2007 11:01:10 +0200 Subject: [Patch][Pungi] To add a generic way of adding files and directories to the tree. Message-ID: <4688BED6.7060007@redhat.com> Hi list: Been working on a general way to add directories and files to the pungi tree. This patch allows what I think is the best way to do it. It allows the user to add whatever directory or file to the tree by means of an additional configuration file :( something I did not want to do, but saw no other choice) and packages (the packages are the ones that contain the data). I tested the code for the inclusion of files and directories into the tree. All my tests were successful (the script added the files and directories that I specified). I also tried changing the location of the Release notes to a docs directory. The pungi modifications performed as expected but I had to change anaconda so it could read from the new tree. The patches are attached (pungi's and anaconda's) Comments greatly appreciated. Regards -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffPungi URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffRelNot URL: From Axel.Thimm at ATrpms.net Mon Jul 2 10:19:02 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 2 Jul 2007 12:19:02 +0200 Subject: : thetango SRPM dependency system In-Reply-To: <46883D08.6080400@redhat.com> References: <46879B02.3050105@redhat.com> <20070701223656.GB30962@puariko.nirvana> <46883D08.6080400@redhat.com> Message-ID: <20070702101902.GC21731@puariko.nirvana> Hi, On Sun, Jul 01, 2007 at 07:47:20PM -0400, Prarit Bhargava wrote: > >How can thetango know that perl-Foo will be providing perl(Bar) which > >perl-Baz BuildRequires? > > Good question, and I knew someone was going to ask how I got around that > particular issue. perl-* was a real pain to deal with. > > /usr/lib/rpm/perl.prov is run on every source package to generate a > close-to-complete list of perl(Bar::Foo) includes. I see, good cheating ;) You will probably have a couple of false positives from code that is not being installed. > > I guess that if thetango cannot compute the depdency then it probably > > gets discarded to at least get some better ordering, but the final > > build will still need a brute force iterative approach. > > Nope. This absolutely is 100 times better than a brute force iterative > approach. IMO of course :) It's surely better, what I mean is you cannot avoid the final iterative approach, you can only provide a better ordered package list to start with. For example even when you can cheat a simulated build to find perl dependecnies, as well as many other script language depedencies, you will not be able to detect stuff needed for BuildRequires: %{_libdir}/libfoo.so, which as brain-daed as it looks it is sometimes needed when packages transition for not having *-devel to having one. I even have submitted such a package. But I agree, having an almost fully sorted filelist is 100x better than a random one. How about the following addition idea: Does restating thetango on cached results with a couple different provides take up too much time? Probably not. In that case you could append such an incremental thetango call after each package is built and dynamically adjust the ordering while building getting an almost 100% correct ordering. But maybe it is already 95% good and the final 5% will be using brute force, so it would be not worth while to do dynamical adjustments. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From prarit at redhat.com Mon Jul 2 10:33:38 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Mon, 02 Jul 2007 06:33:38 -0400 Subject: : thetango SRPM dependency system In-Reply-To: <20070702101902.GC21731@puariko.nirvana> References: <46879B02.3050105@redhat.com> <20070701223656.GB30962@puariko.nirvana> <46883D08.6080400@redhat.com> <20070702101902.GC21731@puariko.nirvana> Message-ID: <4688D482.7090106@redhat.com> Axel Thimm wrote: > I see, good cheating ;) > > :o) > You will probably have a couple of false positives from code that is > not being installed. > > Interesting. I'll keep that in mind. >>> I guess that if thetango cannot compute the depdency then it probably >>> gets discarded to at least get some better ordering, but the final >>> build will still need a brute force iterative approach. >>> >> Nope. This absolutely is 100 times better than a brute force iterative >> approach. IMO of course :) >> > > It's surely better, what I mean is you cannot avoid the final > iterative approach, you can only provide a better ordered package list > to start with. > > For example even when you can cheat a simulated build to find perl > dependecnies, as well as many other script language depedencies, you > will not be able to detect stuff needed for BuildRequires: > %{_libdir}/libfoo.so, which as brain-daed as it looks it is sometimes > needed when packages transition for not having *-devel to having > one. I even have submitted such a package. > > Isn't there also a libtool that would figure that out as well? As the code mentions I have not implemented it yet, but I intend to do so. > But I agree, having an almost fully sorted filelist is 100x better than a > random one. > I'm going to return to the system that I did the brute force build on this week. It is only a 64p/128G box, and I'm going to write code that uses a bottom-up tree algorithm to build the RPMS. I'd like to see how much faster having the sorted list is. > How about the following addition idea: Does restating thetango on > cached results with a couple different provides take up too much time? > Probably not. In that case you could append such an incremental > thetango call after each package is built and dynamically adjust the > ordering while building getting an almost 100% correct ordering. But > maybe it is already 95% good and the final 5% will be using brute > force, so it would be not worth while to do dynamical adjustments. > > Hmmm ... I haven't even considered that. I'll add that to the TODO list. :) P. From jkeating at redhat.com Mon Jul 2 13:12:42 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 09:12:42 -0400 Subject: Making sure all dependencies are met when using Pungi In-Reply-To: References: Message-ID: <200707020912.42473.jkeating@redhat.com> On Monday 02 July 2007 00:31:15 William F. Acker WB2FLW +1-303-722-7209 wrote: > As packages are updated, they can grow dependencies. ?An example is that > libpurple now requires libhowl.so.o, found in avahi-compat-howl. ?Yet, > Pungi doesn't complain about the missing package. ?In the logs, I find > that when libpurple is examined, there's a ?list of dependencies, but > libhowl.so.0 is nowhere to be found. ?Where does Pungi get its dependency > info? ?One would think that it comes from the metadata in the repo, which > is local, in my case. Gets it from the repo yes. There is a yum bug, fixed by 3.2.1 I do believe, that would make yum sometimes not complain about missing deps. Also look in your logs for WARNINGS regarding missing deps. I fixed pungi's reporting of missing deps recently. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rob.myers at gtri.gatech.edu Mon Jul 2 14:23:44 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 02 Jul 2007 10:23:44 -0400 Subject: Koji and SVN In-Reply-To: <1183257210.3564.5.camel@lt21223.campus.dmacc.edu> References: <6a28481b0706281533p76a8bbfbmafebede5b9140057@mail.gmail.com> <200706301448.24864.jkeating@redhat.com> <1183257210.3564.5.camel@lt21223.campus.dmacc.edu> Message-ID: <1183386224.3413.14.camel@rxm-581b.stl.gtri.gatech.edu> On Sat, 2007-06-30 at 21:33 -0500, Jeffrey C. Ollie wrote: > On Sat, 2007-06-30 at 14:48 -0400, Jesse Keating wrote: > > On Thursday 28 June 2007 18:33:59 Oscar Victorio Calixto Bacho wrote: > > > Hi List > > > > > > I have two questions > > > > > > Koji can support SVN at the moment? > > > > Not currently. > > > > > why not? > > > > The source control mechanism used by the Fedora project for it's packages is > > currently CVS. It also looks like that any move away from CVS would be > > toward a distributed SCM such as git or hg due to the things a distributed > > SCM offers over CVS/SVN. modifications are required to your Makefile.common to support svn. as you may know, switching to svn eliminates the make tag step in the build process. i can email you the Makefile.common i'm using if you need it. > > However patches to Koji that enable svn support won't be turned away, provided > > they're good (: > > There are patches for Koji attached to this ticket: > > https://hosted.fedoraproject.org/projects/koji/ticket/15 > > I can't comment as to the quality, as I haven't tested them... i posted an updated patch against koji 1.2.2 here: https://hosted.fedoraproject.org/projects/koji/attachment/ticket/15/koji-1.2.2-svn+ssh.patch they work for me; i'll let others judge their "quality". rob. From jkeating at redhat.com Mon Jul 2 14:26:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 10:26:07 -0400 Subject: Koji and SVN In-Reply-To: <1183386224.3413.14.camel@rxm-581b.stl.gtri.gatech.edu> References: <6a28481b0706281533p76a8bbfbmafebede5b9140057@mail.gmail.com> <1183257210.3564.5.camel@lt21223.campus.dmacc.edu> <1183386224.3413.14.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <200707021026.11092.jkeating@redhat.com> On Monday 02 July 2007 10:23:44 rob myers wrote: > modifications are required to your Makefile.common to support svn. ?as > you may know, switching to svn eliminates the make tag step in the build > process. ?i can email you the Makefile.common i'm using if you need it. Curious, do you no longer have a reference to the module at the time the build was done? While a cvs tag is convenient to tell the buildsystem what bits to pull, a named tag in general is convenient for humans to easily get the content at that point in time too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jgranado at redhat.com Mon Jul 2 14:48:58 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Mon, 02 Jul 2007 16:48:58 +0200 Subject: [Patch][Pungi] To add a generic way of adding files and directories to the tree. In-Reply-To: <4688BED6.7060007@redhat.com> References: <4688BED6.7060007@redhat.com> Message-ID: <4689105A.40303@redhat.com> Joel Andres Granados wrote: > Hi list: > > Been working on a general way to add directories and files to the > pungi tree. This patch allows what I think is the best way to do it. > It allows the user to add whatever directory or file to the tree by > means of an additional configuration file :( something I did not want > to do, but saw no other choice) and packages (the packages are the > ones that contain the data). > I tested the code for the inclusion of files and directories into the > tree. All my tests were successful (the script added the files and > directories that I specified). I also tried changing the location of > the Release notes to a docs directory. The pungi modifications > performed as expected but I had to change anaconda so it could read > from the new tree. > The patches are attached (pungi's and anaconda's) > > Comments greatly appreciated. > Regards > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Just realized that the diffRelNot was backwards, This will correct the mistake. Regards. -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffRelNot URL: From jeff at ocjtech.us Mon Jul 2 14:49:54 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Mon, 02 Jul 2007 09:49:54 -0500 Subject: Koji and SVN In-Reply-To: <200707021026.11092.jkeating@redhat.com> References: <6a28481b0706281533p76a8bbfbmafebede5b9140057@mail.gmail.com> <1183257210.3564.5.camel@lt21223.campus.dmacc.edu> <1183386224.3413.14.camel@rxm-581b.stl.gtri.gatech.edu> <200707021026.11092.jkeating@redhat.com> Message-ID: <1183387794.4039.19.camel@lt21223.campus.dmacc.edu> On Mon, 2007-07-02 at 10:26 -0400, Jesse Keating wrote: > On Monday 02 July 2007 10:23:44 rob myers wrote: > > modifications are required to your Makefile.common to support svn. as > > you may know, switching to svn eliminates the make tag step in the build > > process. i can email you the Makefile.common i'm using if you need it. > > Curious, do you no longer have a reference to the module at the time the build > was done? While a cvs tag is convenient to tell the buildsystem what bits to > pull, a named tag in general is convenient for humans to easily get the > content at that point in time too. For subversion, a path plus a revision number would be sufficient. Tags in subversion are really just a convention. Unless you put some code into a pre-commit hook to prohibit it, tags can be modified just like any other directory in subversion. Unfortunately the same can be said of CVS tags. Jeff -------------- 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 jkeating at redhat.com Mon Jul 2 14:51:38 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 2 Jul 2007 10:51:38 -0400 Subject: Koji and SVN In-Reply-To: <1183387794.4039.19.camel@lt21223.campus.dmacc.edu> References: <6a28481b0706281533p76a8bbfbmafebede5b9140057@mail.gmail.com> <200707021026.11092.jkeating@redhat.com> <1183387794.4039.19.camel@lt21223.campus.dmacc.edu> Message-ID: <200707021051.38505.jkeating@redhat.com> On Monday 02 July 2007 10:49:54 Jeffrey C. Ollie wrote: > For subversion, a path plus a revision number would be sufficient. ?Tags > in subversion are really just a convention. ?Unless you put some code > into a pre-commit hook to prohibit it, tags can be modified just like > any other directory in subversion. ?Unfortunately the same can be said > of CVS tags. Yes, I'm wondering why suddenly it would be not necessary to provide this convenience to developers, so that they'd have to guess at which path/rev# was used to build a particular nvr. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rob.myers at gtri.gatech.edu Mon Jul 2 15:16:20 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Mon, 02 Jul 2007 11:16:20 -0400 Subject: Koji and SVN In-Reply-To: <200707021051.38505.jkeating@redhat.com> References: <6a28481b0706281533p76a8bbfbmafebede5b9140057@mail.gmail.com> <200707021026.11092.jkeating@redhat.com> <1183387794.4039.19.camel@lt21223.campus.dmacc.edu> <200707021051.38505.jkeating@redhat.com> Message-ID: <1183389380.3413.35.camel@rxm-581b.stl.gtri.gatech.edu> On Mon, 2007-07-02 at 10:51 -0400, Jesse Keating wrote: > On Monday 02 July 2007 10:49:54 Jeffrey C. Ollie wrote: > > For subversion, a path plus a revision number would be sufficient. Tags > > in subversion are really just a convention. Unless you put some code > > into a pre-commit hook to prohibit it, tags can be modified just like > > any other directory in subversion. Unfortunately the same can be said > > of CVS tags. > > Yes, I'm wondering why suddenly it would be not necessary to provide this > convenience to developers, so that they'd have to guess at which path/rev# > was used to build a particular nvr. we have only svn revision numbers. noone here seems to miss the nvr tag. in other words, it is a convenience we haven't really needed or used, and of course YMMV. rob. From paul at city-fan.org Fri Jul 6 14:03:07 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 06 Jul 2007 15:03:07 +0100 Subject: Known mock/yum problem? In-Reply-To: <467FE7F3.7070807@city-fan.org> References: <467FDCC3.9050201@city-fan.org> <1182784936.13477.20.camel@hodge> <467FE7F3.7070807@city-fan.org> Message-ID: <468E4B9B.9010505@city-fan.org> Paul Howarth wrote: > seth vidal wrote: >> On Mon, 2007-06-25 at 16:18 +0100, Paul Howarth wrote: >>> Came across an oddity today and I'm not sure if it's mock or yum >>> that's the problem. >>> >>> I'm running with these updates from updates-testing (on an FC7 host): >>> mock-0.7.2-1.fc7 >>> yum-3.2.1-1.fc7 >>> >>> My rawhide mock config points to a single baseurl for the fedora >>> repo, and goes through a local squid proxy. I'm also using autocache. >>> >>> From time to time packages cannot be retrieved over the network, >>> perhaps due to the mirror being in mid-sync, or maybe transient >>> network issues. >>> >> >> Try this as a good test: Make a package with a BuildRequires: >> something-that-doesn't-exist >> >> If the build doesn't bail, then we have a problem, if it does bail, then >> we're fine. >> >> >> Can you test that and let me know? > > OK, tried this: > > * Got a simple perl module package and added a buildreq of > perl(No::Such::Module) to it. > * Tried building it: mock failed as I'd have expected ("No Package Found > for perl(No::Such::Module)") > > To more accurately mimic the issue I was seeing, I then: > > * Created a dummy perl-No-Such-Module package that provided > perl(No::Such::Module) > * Added that package to a local repo that's in my mock config > * After running createrepo to update the metadata, I then deleted the > actual RPM from the repo > * Tried building the original perl module package > > This reproduced what I was seeing; the dependency seemingly being > available from the metadata was sufficient for mock to proceed to the > build phase. > > The consequences aren't as bad as I'd thought though, as yum doesn't > seem to have installed *any* of the buildreqs in the setup phase, which > would cause most package builds to fail. Has anyone reproduced this? Paul. From Michael_E_Brown at dell.com Fri Jul 6 19:26:42 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 6 Jul 2007 14:26:42 -0500 Subject: mock rfe - buildgroup In-Reply-To: <200707052013.22137.jkeating@redhat.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> Message-ID: <20070706192641.GB6236@humbolt.us.dell.com> On Thu, Jul 05, 2007 at 08:13:17PM -0400, Jesse Keating wrote: > On Thursday 05 July 2007 18:21:38 Michael E Brown wrote: > > ? ? http://people.redhat.com/jkeating/git/mock-nogrouprepo.git > > ? ? I can probably review/push these, but it wont be until probably > > tomorrow. > > ? ? Thoughts? Jesse, Looking through your patch: +++ b/etc/defaults.cfg +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' This could be problematic for F7, F6, EPEL4/5 and others. I see two (three?) ways to handle this: 1) only add this line to -devel. 2) change the default in mock.py, and override F7/F6/EPEL4/EPEL5 configs. 3) add this line to -devel, and then migrate it to (2) above after a period of time (perhaps when we drop F6?) -- Michael From jkeating at redhat.com Fri Jul 6 19:32:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Jul 2007 15:32:17 -0400 Subject: mock rfe - buildgroup In-Reply-To: <20070706192641.GB6236@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> Message-ID: <200707061532.21175.jkeating@redhat.com> On Friday 06 July 2007 15:26:42 Michael E Brown wrote: > Looking through your patch: > > +++ b/etc/defaults.cfg > +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' > > This could be problematic for F7, F6, EPEL4/5 and others. > > I see two (three?) ways to handle this: > > 1) only add this line to -devel. > > 2) change the default in mock.py, and override F7/F6/EPEL4/EPEL5 > configs. > > 3) add this line to -devel, and then migrate it to (2) above after a > period of time (perhaps when we drop F6?) Yeah, I had this fleeting thought when I was doing it, then promptly forgot about it. One of those days... I think 2 is probably safest, if people have locally modified their configs, but I was also thinking we'd only make this change in rawhide, so it would only be rawhide people who get it, not pushing it out to existing Fedora/RHEL setups, so 3 is probably fine too. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Fri Jul 6 19:47:48 2007 From: opensource at till.name (Till Maas) Date: Fri, 06 Jul 2007 21:47:48 +0200 Subject: mock rfe - buildgroup In-Reply-To: <20070706192641.GB6236@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> Message-ID: <200707062147.50387.opensource@till.name> On Fr Juli 6 2007, Michael E Brown wrote: > +++ b/etc/defaults.cfg > +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' > > This could be problematic for F7, F6, EPEL4/5 and others. When you call the group "build" instead of "buildsys-build" , F7 may use the group definition that is in here: http://buildsys.fedoraproject.org/buildgroups/7/i386/repodata/buildroots.xml Or is this something different? Regards, Till From sheltren at cs.ucsb.edu Fri Jul 6 19:53:08 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 6 Jul 2007 15:53:08 -0400 Subject: mock rfe - buildgroup In-Reply-To: <200707061532.21175.jkeating@redhat.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> <200707061532.21175.jkeating@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 6, 2007, at 3:32 PM, Jesse Keating wrote: > On Friday 06 July 2007 15:26:42 Michael E Brown wrote: >> Looking through your patch: >> >> +++ b/etc/defaults.cfg >> +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' >> >> This could be problematic for F7, F6, EPEL4/5 and others. >> >> I see two (three?) ways to handle this: >> >> 1) only add this line to -devel. >> >> 2) change the default in mock.py, and override F7/F6/EPEL4/EPEL5 >> configs. >> >> 3) add this line to -devel, and then migrate it to (2) above after a >> period of time (perhaps when we drop F6?) > > Yeah, I had this fleeting thought when I was doing it, then > promptly forgot > about it. One of those days... > > I think 2 is probably safest, if people have locally modified their > configs, > but I was also thinking we'd only make this change in rawhide, so > it would > only be rawhide people who get it, not pushing it out to existing > Fedora/RHEL > setups, so 3 is probably fine too. > I'm confused why you would say (2) is the safest. Overriding the default would cause all those who use modified config files to fix them when mock gets updated. My order of preference for the above options would be (1), (3), (2). In fact, if you go with (3), it makes sense to me to change the default after F7 is dropped rather than FC6. F7 continues to use a buildgroups repo/RPM, correct? - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGjp2kKe7MLJjUbNMRAkoyAJ9aBkgqnPX9zD8/bc2T1bcyioRvsQCgld3q /Wf8M5r4txxBbc4IrVsYL5Q= =EwT8 -----END PGP SIGNATURE----- From Michael_E_Brown at dell.com Fri Jul 6 20:05:29 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 6 Jul 2007 15:05:29 -0500 Subject: mock rfe - buildgroup In-Reply-To: <20070706192641.GB6236@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> Message-ID: <20070706200529.GA7256@humbolt.us.dell.com> On Fri, Jul 06, 2007 at 02:26:42PM -0500, Michael E Brown wrote: > On Thu, Jul 05, 2007 at 08:13:17PM -0400, Jesse Keating wrote: > > On Thursday 05 July 2007 18:21:38 Michael E Brown wrote: > > > ? ? http://people.redhat.com/jkeating/git/mock-nogrouprepo.git > > > ? ? I can probably review/push these, but it wont be until probably > > > tomorrow. > > > ? ? Thoughts? > > Jesse, > > Looking through your patch: > > +++ b/etc/defaults.cfg > +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' > > This could be problematic for F7, F6, EPEL4/5 and others. > > I see two (three?) ways to handle this: > > 1) only add this line to -devel. > > 2) change the default in mock.py, and override F7/F6/EPEL4/EPEL5 > configs. > > 3) add this line to -devel, and then migrate it to (2) above after a > period of time (perhaps when we drop F6?) Expanding on this to explain my reasoning: my view is that defaults.cfg should be empty for default mock install. All of the default settings should be in mock.py, and defaults.py should be for sitewide customizations by the admin. Looking at the current defaults.cfg, we can remove all of the entries as they are redudnant (use_host_resolv, use_cache, chrootuid, and chrootgid all need to be migrated). I've pushed my proposed changes for defaults.cfg (not including this patch) to http://linux.dell.com/git/mock.git -- Michael From Michael_E_Brown at dell.com Fri Jul 6 20:08:28 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 6 Jul 2007 15:08:28 -0500 Subject: mock rfe - buildgroup In-Reply-To: References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> <200707061532.21175.jkeating@redhat.com> Message-ID: <20070706200827.GB7256@humbolt.us.dell.com> On Fri, Jul 06, 2007 at 03:53:08PM -0400, Jeff Sheltren wrote: > >>I see two (three?) ways to handle this: > >> > >>1) only add this line to -devel. > >> > >>2) change the default in mock.py, and override F7/F6/EPEL4/EPEL5 > >>configs. > >> > >>3) add this line to -devel, and then migrate it to (2) above after a > >>period of time (perhaps when we drop F6?) > > > >Yeah, I had this fleeting thought when I was doing it, then > >promptly forgot > >about it. One of those days... > > > >I think 2 is probably safest, if people have locally modified their > >configs, > >but I was also thinking we'd only make this change in rawhide, so > >it would > >only be rawhide people who get it, not pushing it out to existing > >Fedora/RHEL > >setups, so 3 is probably fine too. > > > > I'm confused why you would say (2) is the safest. Overriding the > default would cause all those who use modified config files to fix > them when mock gets updated. When we update defaults.cfg, everybody with local modifications is broken until they manually make the change. I dont like breaking people's configs. > My order of preference for the above options would be (1), (3), (2). > In fact, if you go with (3), it makes sense to me to change the > default after F7 is dropped rather than FC6. F7 continues to use a > buildgroups repo/RPM, correct? Yes, but at that point, F7 becomes one single config override, and is easier to manage than everything being an override. My preference is still 2. From Michael_E_Brown at dell.com Fri Jul 6 20:11:52 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 6 Jul 2007 15:11:52 -0500 Subject: mock rfe - buildgroup In-Reply-To: <200707061532.21175.jkeating@redhat.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> <200707061532.21175.jkeating@redhat.com> Message-ID: <20070706201151.GC6236@humbolt.us.dell.com> On Fri, Jul 06, 2007 at 03:32:17PM -0400, Jesse Keating wrote: > On Friday 06 July 2007 15:26:42 Michael E Brown wrote: > > Looking through your patch: > > > > +++ b/etc/defaults.cfg > > +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' > > > > This could be problematic for F7, F6, EPEL4/5 and others. > > > > I see two (three?) ways to handle this: > > > > 1) only add this line to -devel. > > > > 2) change the default in mock.py, and override F7/F6/EPEL4/EPEL5 > > configs. > > > > 3) add this line to -devel, and then migrate it to (2) above after a > > period of time (perhaps when we drop F6?) > > Yeah, I had this fleeting thought when I was doing it, then promptly forgot > about it. One of those days... > > I think 2 is probably safest, if people have locally modified their configs, > but I was also thinking we'd only make this change in rawhide, so it would > only be rawhide people who get it, not pushing it out to existing Fedora/RHEL > setups, so 3 is probably fine too. I dont like to make changes specific to one distribution as that requires thought on my part and I am likely to mess it up, or forget about the distro specifics next update. The only solution in that case is to branch, which brings its own overhead. -- Michael From Michael_E_Brown at dell.com Fri Jul 6 20:35:47 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 6 Jul 2007 15:35:47 -0500 Subject: mock rfe - buildgroup In-Reply-To: <20070706201151.GC6236@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> <200707061532.21175.jkeating@redhat.com> <20070706201151.GC6236@humbolt.us.dell.com> Message-ID: <20070706203547.GC7256@humbolt.us.dell.com> On Fri, Jul 06, 2007 at 03:11:52PM -0500, Michael E Brown wrote: > On Fri, Jul 06, 2007 at 03:32:17PM -0400, Jesse Keating wrote: > > On Friday 06 July 2007 15:26:42 Michael E Brown wrote: > > > Looking through your patch: > > > > > > +++ b/etc/defaults.cfg > > > +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' > > > > > > This could be problematic for F7, F6, EPEL4/5 and others. > > > > > > I see two (three?) ways to handle this: > > > > > > 1) only add this line to -devel. > > > > > > 2) change the default in mock.py, and override F7/F6/EPEL4/EPEL5 > > > configs. > > > > > > 3) add this line to -devel, and then migrate it to (2) above after a > > > period of time (perhaps when we drop F6?) > > > > Yeah, I had this fleeting thought when I was doing it, then promptly forgot > > about it. One of those days... > > > > I think 2 is probably safest, if people have locally modified their configs, > > but I was also thinking we'd only make this change in rawhide, so it would > > only be rawhide people who get it, not pushing it out to existing Fedora/RHEL > > setups, so 3 is probably fine too. > > I dont like to make changes specific to one distribution as that > requires thought on my part and I am likely to mess it up, or forget > about the distro specifics next update. The only solution in that case > is to branch, which brings its own overhead. Jesse, Clark, I've pushed to my git repo a patch representing option (2). Please review. I've updated defaults.cfg to contain nothing. I've imported the non-defaults.cfg part of Jesse's patch, updated mock.py and the legacy configs for F6/7 and EPEL4/5 to use the old buildsys-build rpm method. -- Michael PS: wait about 15 minutes for my mirror script to run to update the public repo... From sheltren at cs.ucsb.edu Fri Jul 6 21:32:49 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 6 Jul 2007 17:32:49 -0400 Subject: mock rfe - buildgroup In-Reply-To: <20070706203547.GC7256@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> <200707061532.21175.jkeating@redhat.com> <20070706201151.GC6236@humbolt.us.dell.com> <20070706203547.GC7256@humbolt.us.dell.com> Message-ID: <991B96B1-44BB-4E35-A8E5-6FB0E4E00E3A@cs.ucsb.edu> On Jul 6, 2007, at 4:35 PM, Michael E Brown wrote: > > Jesse, Clark, > > I've pushed to my git repo a patch representing option (2). Please > review. I've updated defaults.cfg to contain nothing. I've imported > the > non-defaults.cfg part of Jesse's patch, updated mock.py and the legacy > configs for F6/7 and EPEL4/5 to use the old buildsys-build rpm method. > > I don't like that this will break configs for my mock setup. For example, I have not changed defaults.cfg at all, but all of the fedora-*, redhat-*, epel* configs do have local modifications. Now, if you push a defaults.cfg file which is blank, that will cause my unedited defaults.cfg to be overwritten. Once that happens, all of the other mock configs will be trying to do 'groupinstall buildsys- build' which is a non-existent group (except apparently in rawhide). I would much prefer if the default install command remained the same for the time being and the change would only be made in the development config. Thanks, Jeff From jkeating at redhat.com Fri Jul 6 21:49:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Jul 2007 17:49:19 -0400 Subject: mock rfe - buildgroup In-Reply-To: References: <20070705222137.GD3109@humbolt.us.dell.com> <200707061532.21175.jkeating@redhat.com> Message-ID: <200707061749.19785.jkeating@redhat.com> On Friday 06 July 2007 15:53:08 Jeff Sheltren wrote: > I'm confused why you would say (2) is the safest. ?Overriding the > default would cause all those who use modified config files to fix > them when mock gets updated. Oops, I meant 1. Clearly not typing correctly > My order of preference for the above options would be (1), (3), (2). > In fact, if you go with (3), it makes sense to me to change the > default after F7 is dropped rather than FC6. ?F7 continues to use a > buildgroups repo/RPM, correct? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jul 6 21:50:31 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Jul 2007 17:50:31 -0400 Subject: mock rfe - buildgroup In-Reply-To: <991B96B1-44BB-4E35-A8E5-6FB0E4E00E3A@cs.ucsb.edu> References: <20070705222137.GD3109@humbolt.us.dell.com> <20070706203547.GC7256@humbolt.us.dell.com> <991B96B1-44BB-4E35-A8E5-6FB0E4E00E3A@cs.ucsb.edu> Message-ID: <200707061750.31258.jkeating@redhat.com> On Friday 06 July 2007 17:32:49 Jeff Sheltren wrote: > For example, I have not changed defaults.cfg at all, but all of the ? > fedora-*, redhat-*, epel* configs do have local modifications. ?Now, ? > if you push a defaults.cfg file which is blank, that will cause my ? > unedited defaults.cfg to be overwritten. ?Once that happens, all of ? > the other mock configs will be trying to do 'groupinstall buildsys- > build' which is a non-existent group (except apparently in rawhide). > > I would much prefer if the default install command remained the same ? > for the time being and the change would only be made in the ? > development config. Jeff, this is on a rawhide box you're talking about? I think we're only going to make the change in rawhide and not further down the stack. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Jul 6 21:52:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Jul 2007 17:52:19 -0400 Subject: mock rfe - buildgroup In-Reply-To: <20070706200529.GA7256@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <20070706192641.GB6236@humbolt.us.dell.com> <20070706200529.GA7256@humbolt.us.dell.com> Message-ID: <200707061752.19672.jkeating@redhat.com> On Friday 06 July 2007 16:05:29 Michael E Brown wrote: > my view is that defaults.cfg should be empty for default mock install. > All of the default settings should be in mock.py, and defaults.py should > be for sitewide customizations by the admin. > > Looking at the current defaults.cfg, we can remove all of the entries as > they are redudnant (use_host_resolv, use_cache, chrootuid, and chrootgid > all need to be migrated). > > I've pushed my proposed changes for defaults.cfg (not including this > patch) to http://linux.dell.com/git/mock.git I understand your view point. I think I'd rather leave some breadcumbs in the defaults.cfg file, though commented out. Show them with what is coded into mock.py but given them an easy way to just uncomment and alter. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Michael_E_Brown at dell.com Fri Jul 6 22:02:30 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 6 Jul 2007 17:02:30 -0500 Subject: mock rfe - buildgroup In-Reply-To: <991B96B1-44BB-4E35-A8E5-6FB0E4E00E3A@cs.ucsb.edu> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> <200707061532.21175.jkeating@redhat.com> <20070706201151.GC6236@humbolt.us.dell.com> <20070706203547.GC7256@humbolt.us.dell.com> <991B96B1-44BB-4E35-A8E5-6FB0E4E00E3A@cs.ucsb.edu> Message-ID: <20070706220230.GF7256@humbolt.us.dell.com> On Fri, Jul 06, 2007 at 05:32:49PM -0400, Jeff Sheltren wrote: > On Jul 6, 2007, at 4:35 PM, Michael E Brown wrote: > > > >Jesse, Clark, > > > > I've pushed to my git repo a patch representing option (2). Please > >review. I've updated defaults.cfg to contain nothing. I've imported > >the > >non-defaults.cfg part of Jesse's patch, updated mock.py and the legacy > >configs for F6/7 and EPEL4/5 to use the old buildsys-build rpm method. > > > > > > I don't like that this will break configs for my mock setup. > > For example, I have not changed defaults.cfg at all, but all of the > fedora-*, redhat-*, epel* configs do have local modifications. Now, > if you push a defaults.cfg file which is blank, that will cause my > unedited defaults.cfg to be overwritten. Once that happens, all of > the other mock configs will be trying to do 'groupinstall buildsys- > build' which is a non-existent group (except apparently in rawhide). Actually, I am pretty sure that it saves all the new files as ".rpmnew" files. All the config files are %config(noreplace) in the spec file. So your existing defaults.cfg and individual chroot configs would remain as they are. The only thing you would need to do to continue running would be to add the new config option to your FC<=7 to use the old buildsys-build rpm. > I would much prefer if the default install command remained the same > for the time being and the change would only be made in the > development config. I would probably push this to -devel at first and wait a little while before pushing to FC6/7, but at this point in time, I dont have any intention of branching for something this trivial. Jesse, Clark, How about I just change the -devel .cfg files to use the groupinstall commands and back out the mock.py default change? This would leave all of the config files with the exact install command they need. Leave this for one release, and then add the mock.py default change in the next release. This would give everybody time enough to get their configs updated so they dont break. -- Michael From Michael_E_Brown at dell.com Fri Jul 6 22:12:58 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 6 Jul 2007 17:12:58 -0500 Subject: mock rfe - buildgroup In-Reply-To: <200707061750.31258.jkeating@redhat.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <20070706203547.GC7256@humbolt.us.dell.com> <991B96B1-44BB-4E35-A8E5-6FB0E4E00E3A@cs.ucsb.edu> <200707061750.31258.jkeating@redhat.com> Message-ID: <20070706221258.GG7256@humbolt.us.dell.com> On Fri, Jul 06, 2007 at 05:50:31PM -0400, Jesse Keating wrote: > On Friday 06 July 2007 17:32:49 Jeff Sheltren wrote: > > For example, I have not changed defaults.cfg at all, but all of the ? > > fedora-*, redhat-*, epel* configs do have local modifications. ?Now, ? > > if you push a defaults.cfg file which is blank, that will cause my ? > > unedited defaults.cfg to be overwritten. ?Once that happens, all of ? > > the other mock configs will be trying to do 'groupinstall buildsys- > > build' which is a non-existent group (except apparently in rawhide). > > > > I would much prefer if the default install command remained the same ? > > for the time being and the change would only be made in the ? > > development config. > > Jeff, this is on a rawhide box you're talking about? I think we're only going > to make the change in rawhide and not further down the stack. Jesse, I've been updating FC6/7 and EPEL4/5 with every release. If we do this change and dont want to push it to the older releases, then we would need to branch mock, and this seems like too trivial a change to do all that work for. I think that my current repo at http://linux.dell.com/git/mock.git has everything we need to make everything nicely forward and backward compatible: Here is what I have done: 1) update all individual config files with the chroot_setup_cmd 2) mock.py still defaults to 'install buildsys-build' 3) defaults.cfg is now empty and reserved for site-local changes This means that anybody who has any site-local changes to any of their config files with get the updated configs as .rpmnew files. Their existing configs will continue to work, as we have not changed the defaults. They can then update the config files to include the chroot_setup_cmd at their leisure. Todo for $nextrelease: 1) update mock.py so that 'groupinstall buildsys-build' is the new default. -- Michael From Michael_E_Brown at dell.com Fri Jul 6 22:14:22 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 6 Jul 2007 17:14:22 -0500 Subject: mock rfe - buildgroup In-Reply-To: <200707061752.19672.jkeating@redhat.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <20070706192641.GB6236@humbolt.us.dell.com> <20070706200529.GA7256@humbolt.us.dell.com> <200707061752.19672.jkeating@redhat.com> Message-ID: <20070706221422.GH7256@humbolt.us.dell.com> On Fri, Jul 06, 2007 at 05:52:19PM -0400, Jesse Keating wrote: > On Friday 06 July 2007 16:05:29 Michael E Brown wrote: > > my view is that defaults.cfg should be empty for default mock install. > > All of the default settings should be in mock.py, and defaults.py should > > be for sitewide customizations by the admin. > > > > Looking at the current defaults.cfg, we can remove all of the entries as > > they are redudnant (use_host_resolv, use_cache, chrootuid, and chrootgid > > all need to be migrated). > > > > I've pushed my proposed changes for defaults.cfg (not including this > > patch) to http://linux.dell.com/git/mock.git > > I understand your view point. I think I'd rather leave some breadcumbs in the > defaults.cfg file, though commented out. Show them with what is coded into > mock.py but given them an easy way to just uncomment and alter. That is a very valid point. I can easily do that. Any suggestions on which config items are candidates for such treatment? -- Michael From sheltren at cs.ucsb.edu Fri Jul 6 22:53:23 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 6 Jul 2007 18:53:23 -0400 Subject: mock rfe - buildgroup In-Reply-To: <20070706220230.GF7256@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> <200707061532.21175.jkeating@redhat.com> <20070706201151.GC6236@humbolt.us.dell.com> <20070706203547.GC7256@humbolt.us.dell.com> <991B96B1-44BB-4E35-A8E5-6FB0E4E00E3A@cs.ucsb.edu> <20070706220230.GF7256@humbolt.us.dell.com> Message-ID: <72364BB0-5883-4B4E-A03D-45925A966CCE@cs.ucsb.edu> On Jul 6, 2007, at 6:02 PM, Michael E Brown wrote: > On Fri, Jul 06, 2007 at 05:32:49PM -0400, Jeff Sheltren wrote: >> >> I don't like that this will break configs for my mock setup. >> >> For example, I have not changed defaults.cfg at all, but all of the >> fedora-*, redhat-*, epel* configs do have local modifications. Now, >> if you push a defaults.cfg file which is blank, that will cause my >> unedited defaults.cfg to be overwritten. Once that happens, all of >> the other mock configs will be trying to do 'groupinstall buildsys- >> build' which is a non-existent group (except apparently in rawhide). > > Actually, I am pretty sure that it saves all the new files as > ".rpmnew" > files. All the config files are %config(noreplace) in the spec file. Unfortunately rpm has a different idea of what "noreplace" means than what most people would think. :) Even with %config(noreplace) it will replace non-modified files. I just verified this on FC6. In most cases this wouldn't be a big deal, but when you combine this with the change to mock.py modifying the default behavior, this leaves people (or at least me) in a bad situation. >> I would much prefer if the default install command remained the same >> for the time being and the change would only be made in the >> development config. > > I would probably push this to -devel at first and wait a little while > before pushing to FC6/7, but at this point in time, I dont have any > intention of branching for something this trivial. I understand that you don't want to maintain multiple branches - no argument here! > > Jesse, Clark, > How about I just change the -devel .cfg files to use the > groupinstall commands and back out the mock.py default change? This > would leave all of the config files with the exact install command > they > need. Leave this for one release, and then add the mock.py default > change in the next release. This would give everybody time enough > to get > their configs updated so they dont break. If you're convinced that the default mock behavior needs to change, then I would much prefer this -- wait a release (or two) before making the change. It may also be helpful to people if you do add something like the following in defaults.cfg: ---------- config_opts['chroot_setup_cmd'] = 'install buildsys-build' # The following is used in F8 (devel) and will soon become the default #config_opts['chroot_setup_cmd'] = 'groupinstall build' ---------- Thanks, Jeff From sheltren at cs.ucsb.edu Fri Jul 6 23:03:39 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 6 Jul 2007 19:03:39 -0400 Subject: mock rfe - buildgroup In-Reply-To: <20070706221422.GH7256@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <20070706192641.GB6236@humbolt.us.dell.com> <20070706200529.GA7256@humbolt.us.dell.com> <200707061752.19672.jkeating@redhat.com> <20070706221422.GH7256@humbolt.us.dell.com> Message-ID: <16927A33-2692-4D8F-86B6-497988C0A842@cs.ucsb.edu> On Jul 6, 2007, at 6:14 PM, Michael E Brown wrote: > On Fri, Jul 06, 2007 at 05:52:19PM -0400, Jesse Keating wrote: >> >> I understand your view point. I think I'd rather leave some >> breadcumbs in the >> defaults.cfg file, though commented out. Show them with what is >> coded into >> mock.py but given them an easy way to just uncomment and alter. > > That is a very valid point. I can easily do that. > > Any suggestions on which config items are candidates for such > treatment? > Hi Michael, I think what is currently included in defaults.cfg (looking at 7.2-1.fc6.1) is good. Also I'd add config_opts['chroot_setup_cmd'] = 'install buildsys-build' as I mentioned previously. If you want to have everything commented out (since it's defined in mock.py), that seems good to me, but at least this would give people an easy way to figure out what options they can change. Thanks, Jeff From sheltren at cs.ucsb.edu Fri Jul 6 23:06:07 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Fri, 6 Jul 2007 19:06:07 -0400 Subject: mock rfe - buildgroup In-Reply-To: <16927A33-2692-4D8F-86B6-497988C0A842@cs.ucsb.edu> References: <20070705222137.GD3109@humbolt.us.dell.com> <20070706192641.GB6236@humbolt.us.dell.com> <20070706200529.GA7256@humbolt.us.dell.com> <200707061752.19672.jkeating@redhat.com> <20070706221422.GH7256@humbolt.us.dell.com> <16927A33-2692-4D8F-86B6-497988C0A842@cs.ucsb.edu> Message-ID: <61CB5EF3-300E-43B4-AE4D-B98F5DE4602F@cs.ucsb.edu> On Jul 6, 2007, at 7:03 PM, Jeff Sheltren wrote: > > Hi Michael, I think what is currently included in defaults.cfg > (looking at 7.2-1.fc6.1) is good. As you may have guessed, I really meant: 0.7.2-1.fc6.1 -Jeff From sheltren at cs.ucsb.edu Sat Jul 7 13:54:19 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Sat, 7 Jul 2007 09:54:19 -0400 Subject: [mock] yum >= 3.0? Message-ID: I noticed when doing some EPEL dependency checking that the newer versions of mock (I'm looking at the spec for 0.7.1-1) have a requires on yum >= 3.0 in the spec file. Is there code in newer versions of mock which actually requires yum >= 3.0, or should any (~2.2+) version of yum work? Thanks, Jeff From rdieter at math.unl.edu Sat Jul 7 18:17:13 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 07 Jul 2007 13:17:13 -0500 Subject: [mock] yum >= 3.0? References: Message-ID: Jeff Sheltren wrote: > I noticed when doing some EPEL dependency checking that the newer > versions of mock (I'm looking at the spec for 0.7.1-1) have a > requires on yum >= 3.0 in the spec file. Is there code in newer > versions of mock which actually requires yum >= 3.0, or should any > (~2.2+) version of yum work? See also related EL-4 bug on this: http://bugzilla.redhat.com/244847 Almost 3 weeks old now. :( -- Rex From williams at redhat.com Mon Jul 9 14:07:52 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 09 Jul 2007 09:07:52 -0500 Subject: mock rfe - buildgroup In-Reply-To: <20070706201151.GC6236@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <200707052013.22137.jkeating@redhat.com> <20070706192641.GB6236@humbolt.us.dell.com> <200707061532.21175.jkeating@redhat.com> <20070706201151.GC6236@humbolt.us.dell.com> Message-ID: <46924138.40205@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael E Brown wrote: > On Fri, Jul 06, 2007 at 03:32:17PM -0400, Jesse Keating wrote: >> On Friday 06 July 2007 15:26:42 Michael E Brown wrote: >>> Looking through your patch: >>> >>> +++ b/etc/defaults.cfg >>> +config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' >>> >>> This could be problematic for F7, F6, EPEL4/5 and others. >>> >>> I see two (three?) ways to handle this: >>> >>> 1) only add this line to -devel. >>> >>> 2) change the default in mock.py, and override F7/F6/EPEL4/EPEL5 >>> configs. >>> >>> 3) add this line to -devel, and then migrate it to (2) above after a >>> period of time (perhaps when we drop F6?) >> Yeah, I had this fleeting thought when I was doing it, then promptly forgot >> about it. One of those days... >> >> I think 2 is probably safest, if people have locally modified their configs, >> but I was also thinking we'd only make this change in rawhide, so it would >> only be rawhide people who get it, not pushing it out to existing Fedora/RHEL >> setups, so 3 is probably fine too. > > I dont like to make changes specific to one distribution as that > requires thought on my part and I am likely to mess it up, or forget > about the distro specifics next update. The only solution in that case > is to branch, which brings its own overhead. > -- > Michael Man, take a few days off and your co-maintainers run amock! :) I'll get caught up this morning and try to look at what you and Jesse have done. I don't really have a strong opinion on how we construct a chroot (buildsys-build rpm or group). So, whatever you and Jesse work out will be ok with me. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGkkE4Hyuj/+TTEp0RAtBgAKDhTLogaDTS+mgk0G0ysca6PQ8d/gCgunT4 1T31h2KPWW/OLFDGge8LhMg= =B1Er -----END PGP SIGNATURE----- From Michael_E_Brown at dell.com Mon Jul 9 16:53:57 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 9 Jul 2007 11:53:57 -0500 Subject: [mock] yum >= 3.0? In-Reply-To: References: Message-ID: <20070709165356.GA20736@humbolt.us.dell.com> On Sat, Jul 07, 2007 at 01:17:13PM -0500, Rex Dieter wrote: > Jeff Sheltren wrote: > > > I noticed when doing some EPEL dependency checking that the newer > > versions of mock (I'm looking at the spec for 0.7.1-1) have a > > requires on yum >= 3.0 in the spec file. Is there code in newer > > versions of mock which actually requires yum >= 3.0, or should any > > (~2.2+) version of yum work? > > See also related EL-4 bug on this: > http://bugzilla.redhat.com/244847 > Almost 3 weeks old now. :( I've just submitted a new build to back out this dependency. -- Michael From Michael_E_Brown at dell.com Mon Jul 9 17:02:11 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 9 Jul 2007 12:02:11 -0500 Subject: mock rfe - buildgroup In-Reply-To: <16927A33-2692-4D8F-86B6-497988C0A842@cs.ucsb.edu> References: <20070705222137.GD3109@humbolt.us.dell.com> <20070706192641.GB6236@humbolt.us.dell.com> <20070706200529.GA7256@humbolt.us.dell.com> <200707061752.19672.jkeating@redhat.com> <20070706221422.GH7256@humbolt.us.dell.com> <16927A33-2692-4D8F-86B6-497988C0A842@cs.ucsb.edu> Message-ID: <20070709170210.GB20736@humbolt.us.dell.com> On Fri, Jul 06, 2007 at 07:03:39PM -0400, Jeff Sheltren wrote: > On Jul 6, 2007, at 6:14 PM, Michael E Brown wrote: > >On Fri, Jul 06, 2007 at 05:52:19PM -0400, Jesse Keating wrote: > >> > >>I understand your view point. I think I'd rather leave some > >>breadcumbs in the > >>defaults.cfg file, though commented out. Show them with what is > >>coded into > >>mock.py but given them an easy way to just uncomment and alter. > > > >That is a very valid point. I can easily do that. > > > >Any suggestions on which config items are candidates for such > >treatment? > > > > Hi Michael, I think what is currently included in defaults.cfg > (looking at 7.2-1.fc6.1) is good. Also I'd add > config_opts['chroot_setup_cmd'] = 'install buildsys-build' > as I mentioned previously. If you want to have everything commented > out (since it's defined in mock.py), that seems good to me, but at > least this would give people an easy way to figure out what options > they can change. My currently posted git repo does exactly this: -- adds 'chroot_setup_cmd' to every individual chroot config file -> install buildsys-build for legacy configs -> groupinstall buildsys-build for -devel -- mock.py remains with default of "install buildsys-build" to give everybody one release to update their config files. -- next release will change mock.py config default. This should be forward/backward compatible with everybody's config files for this release. Everybody is encouraged to update any site-local config files before the next release. I'm just waiting on feedback from Clark. Thanks, Michael From sheltren at cs.ucsb.edu Mon Jul 9 17:11:55 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Mon, 9 Jul 2007 13:11:55 -0400 Subject: [mock] yum >= 3.0? In-Reply-To: <20070709165356.GA20736@humbolt.us.dell.com> References: <20070709165356.GA20736@humbolt.us.dell.com> Message-ID: On Jul 9, 2007, at 12:53 PM, Michael E Brown wrote: > > I've just submitted a new build to back out this dependency. > -- > Michael > Great, thanks! -Jeff From williams at redhat.com Mon Jul 9 19:29:53 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 09 Jul 2007 14:29:53 -0500 Subject: mock rfe - buildgroup In-Reply-To: <20070709170210.GB20736@humbolt.us.dell.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <20070706192641.GB6236@humbolt.us.dell.com> <20070706200529.GA7256@humbolt.us.dell.com> <200707061752.19672.jkeating@redhat.com> <20070706221422.GH7256@humbolt.us.dell.com> <16927A33-2692-4D8F-86B6-497988C0A842@cs.ucsb.edu> <20070709170210.GB20736@humbolt.us.dell.com> Message-ID: <46928CB1.3070601@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael E Brown wrote: > > My currently posted git repo does exactly this: > > -- adds 'chroot_setup_cmd' to every individual chroot config file > -> install buildsys-build for legacy configs > -> groupinstall buildsys-build for -devel > > -- mock.py remains with default of "install buildsys-build" to give > everybody one release to update their config files. > > -- next release will change mock.py config default. > > This should be forward/backward compatible with everybody's config files > for this release. Everybody is encouraged to update any site-local > config files before the next release. > > I'm just waiting on feedback from Clark. I think this is a good solution. It certainly prevents the weird hiccups when you can't get to the buildsys-build rpm repo... I'm not sure why anyone would experience problems with changing over, but if they do and the outcry is loud enough, we can always delay the default change. +1. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGkoywHyuj/+TTEp0RAkZUAKCHMQoil/2sBu7SSn2amC2wt5Bt3ACfbVx5 NV45CTSYuYtf/3IiGp8dQOw= =69WM -----END PGP SIGNATURE----- From Michael_E_Brown at dell.com Mon Jul 9 19:36:27 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 9 Jul 2007 14:36:27 -0500 Subject: mock rfe - buildgroup In-Reply-To: <46928CB1.3070601@redhat.com> References: <20070705222137.GD3109@humbolt.us.dell.com> <20070706192641.GB6236@humbolt.us.dell.com> <20070706200529.GA7256@humbolt.us.dell.com> <200707061752.19672.jkeating@redhat.com> <20070706221422.GH7256@humbolt.us.dell.com> <16927A33-2692-4D8F-86B6-497988C0A842@cs.ucsb.edu> <20070709170210.GB20736@humbolt.us.dell.com> <46928CB1.3070601@redhat.com> Message-ID: <20070709193626.GE20736@humbolt.us.dell.com> On Mon, Jul 09, 2007 at 02:29:53PM -0500, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael E Brown wrote: > > > > My currently posted git repo does exactly this: > > > > -- adds 'chroot_setup_cmd' to every individual chroot config file > > -> install buildsys-build for legacy configs > > -> groupinstall buildsys-build for -devel > > > > -- mock.py remains with default of "install buildsys-build" to give > > everybody one release to update their config files. > > > > -- next release will change mock.py config default. > > > > This should be forward/backward compatible with everybody's config files > > for this release. Everybody is encouraged to update any site-local > > config files before the next release. > > > > I'm just waiting on feedback from Clark. > > I think this is a good solution. It certainly prevents the weird hiccups when you > can't get to the buildsys-build rpm repo... > > I'm not sure why anyone would experience problems with changing over, but if they do > and the outcry is loud enough, we can always delay the default change. > > +1. Ok. I'll commit my current repo upstream and push out new mock rpms. -- Michael From williams at redhat.com Tue Jul 10 16:53:55 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 10 Jul 2007 11:53:55 -0500 Subject: RFC: utility of 'orphansbuild' patch to mock-helper (BZ#221351)? Message-ID: <4693B9A3.1050604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael/Jesse (and the buildsys list), Jan Kratochvil has submitted a patch to mock that adds the 'orphanskill' command to mock-helper (a setuid root program used by mock). The patch traverses the /proc directory, looking for tasks with a "root" link that matches the chroot currently in use, and sends a SIGKILL to each matching task. As far as I can tell this is only useful to the GDB build. The testsuite for GDB seems to have some either abnormal terminations or so other oddity that leaves jobs hanging. I've looked at the C code and it looks well written, without obvious security holes. I've mixed feelings regarding adding the command. Michael and I have been fairly resistant to adding things to mock-helper, on the general principle that adding features to a setuid root program is fraught with peril. I see the utility of the code, but I'm torn as to whether the 'orphanskill' command is sufficiently useful to the general community. So, that's the question. Is 'orphanskill' worth adding to mock? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGk7miHyuj/+TTEp0RAlkFAKDgVLDuNdcGpVU3rtnv0gFTDMYPtwCePiKX IbGKSbEeD62CyrwZlZwTqo0= =bkbg -----END PGP SIGNATURE----- From mikeb at redhat.com Tue Jul 10 17:13:33 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 10 Jul 2007 13:13:33 -0400 Subject: RFC: utility of 'orphansbuild' patch to mock-helper (BZ#221351)? In-Reply-To: <4693B9A3.1050604@redhat.com> References: <4693B9A3.1050604@redhat.com> Message-ID: <1184087613.7724.26.camel@liffey.home> On Tue, 2007-07-10 at 11:53 -0500, Clark Williams wrote: > Jan Kratochvil has submitted a patch to mock that adds the 'orphanskill' command to > mock-helper (a setuid root program used by mock). The patch traverses the /proc > directory, looking for tasks with a "root" link that matches the chroot currently in > use, and sends a SIGKILL to each matching task. > > As far as I can tell this is only useful to the GDB build. The testsuite for GDB > seems to have some either abnormal terminations or so other oddity that leaves jobs > hanging. I've looked at the C code and it looks well written, without obvious > security holes. > > I've mixed feelings regarding adding the command. Michael and I have been fairly > resistant to adding things to mock-helper, on the general principle that adding > features to a setuid root program is fraught with peril. I see the utility of the > code, but I'm torn as to whether the 'orphanskill' command is sufficiently useful to > the general community. > > So, that's the question. Is 'orphanskill' worth adding to mock? GDB is not the only build that leaves orphaned processes lying around. I've seen similar behavior when building gcc, glibc, and mysql, to name a few. The problems are usually caused by test suites called during the build process, and leaving them around after a build has completed (or failed) can tie up system resources or in some cases cause subsequent builds to fail. Just as mock cleans up the filesystem after a build, it should probably be cleaning up the process list as well. I'd be in favor of adding this patch. Koji could certainly make use of it. From jkeating at redhat.com Tue Jul 10 17:30:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Jul 2007 13:30:15 -0400 Subject: RFC: utility of 'orphansbuild' patch to mock-helper (BZ#221351)? In-Reply-To: <1184087613.7724.26.camel@liffey.home> References: <4693B9A3.1050604@redhat.com> <1184087613.7724.26.camel@liffey.home> Message-ID: <200707101330.21553.jkeating@redhat.com> On Tuesday 10 July 2007 13:13:33 Mike Bonnet wrote: > GDB is not the only build that leaves orphaned processes lying around. > I've seen similar behavior when building gcc, glibc, and mysql, to name > a few. ?The problems are usually caused by test suites called during the > build process, and leaving them around after a build has completed (or > failed) can tie up system resources or in some cases cause subsequent > builds to fail. > > Just as mock cleans up the filesystem after a build, it should probably > be cleaning up the process list as well. ?I'd be in favor of adding this > patch. ?Koji could certainly make use of it. I see it with java builds too, so I'd +1 this as an easy tool to use to clean up stalled builds. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Michael_E_Brown at dell.com Tue Jul 10 19:01:49 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 10 Jul 2007 14:01:49 -0500 Subject: RFC: utility of 'orphansbuild' patch to mock-helper (BZ#221351)? In-Reply-To: <1184087613.7724.26.camel@liffey.home> References: <4693B9A3.1050604@redhat.com> <1184087613.7724.26.camel@liffey.home> Message-ID: <20070710190149.GB19578@humbolt.us.dell.com> On Tue, Jul 10, 2007 at 01:13:33PM -0400, Mike Bonnet wrote: > On Tue, 2007-07-10 at 11:53 -0500, Clark Williams wrote: > > Jan Kratochvil has submitted a patch to mock that adds the 'orphanskill' command to > > mock-helper (a setuid root program used by mock). The patch traverses the /proc > > directory, looking for tasks with a "root" link that matches the chroot currently in > > use, and sends a SIGKILL to each matching task. > > > > As far as I can tell this is only useful to the GDB build. The testsuite for GDB > > seems to have some either abnormal terminations or so other oddity that leaves jobs > > hanging. I've looked at the C code and it looks well written, without obvious > > security holes. > > > > I've mixed feelings regarding adding the command. Michael and I have been fairly > > resistant to adding things to mock-helper, on the general principle that adding > > features to a setuid root program is fraught with peril. I see the utility of the > > code, but I'm torn as to whether the 'orphanskill' command is sufficiently useful to > > the general community. > > > > So, that's the question. Is 'orphanskill' worth adding to mock? > > GDB is not the only build that leaves orphaned processes lying around. > I've seen similar behavior when building gcc, glibc, and mysql, to name > a few. The problems are usually caused by test suites called during the > build process, and leaving them around after a build has completed (or > failed) can tie up system resources or in some cases cause subsequent > builds to fail. > > Just as mock cleans up the filesystem after a build, it should probably > be cleaning up the process list as well. I'd be in favor of adding this > patch. Koji could certainly make use of it. It looks to me that, no matter the design of mock, we need to have this functionality. As long as the patch looks reasonable, we probably need to include it for now, until we get to the point where we drop the suid binary. -- Michael From sheltren at cs.ucsb.edu Tue Jul 10 19:31:21 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Tue, 10 Jul 2007 15:31:21 -0400 Subject: RFC: utility of 'orphansbuild' patch to mock-helper (BZ#221351)? In-Reply-To: <4693B9A3.1050604@redhat.com> References: <4693B9A3.1050604@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 10, 2007, at 12:53 PM, Clark Williams wrote: > So, that's the question. Is 'orphanskill' worth adding to mock? > Without looking at the patch in question, I am +1 for including the functionality which you've described. If you're interested, I'll try to review the patch which is linked from BZ #221351 - -Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iD8DBQFGk96JKe7MLJjUbNMRAlKQAKCErrBB1EcpJXh6ngHXpidtx93GvQCeLmZC AqKSGBSiVeNGAe5eGGClDfg= =MEU8 -----END PGP SIGNATURE----- From williams at redhat.com Tue Jul 10 22:09:56 2007 From: williams at redhat.com (Clark Williams) Date: Tue, 10 Jul 2007 17:09:56 -0500 Subject: RFC: utility of 'orphansbuild' patch to mock-helper (BZ#221351)? In-Reply-To: <20070710190149.GB19578@humbolt.us.dell.com> References: <4693B9A3.1050604@redhat.com> <1184087613.7724.26.camel@liffey.home> <20070710190149.GB19578@humbolt.us.dell.com> Message-ID: <469403B4.7040003@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael E Brown wrote: > On Tue, Jul 10, 2007 at 01:13:33PM -0400, Mike Bonnet wrote: >> On Tue, 2007-07-10 at 11:53 -0500, Clark Williams wrote: >>> Jan Kratochvil has submitted a patch to mock that adds the 'orphanskill' command to >>> mock-helper (a setuid root program used by mock). The patch traverses the /proc >>> directory, looking for tasks with a "root" link that matches the chroot currently in >>> use, and sends a SIGKILL to each matching task. >>> >>> As far as I can tell this is only useful to the GDB build. The testsuite for GDB >>> seems to have some either abnormal terminations or so other oddity that leaves jobs >>> hanging. I've looked at the C code and it looks well written, without obvious >>> security holes. >>> >>> I've mixed feelings regarding adding the command. Michael and I have been fairly >>> resistant to adding things to mock-helper, on the general principle that adding >>> features to a setuid root program is fraught with peril. I see the utility of the >>> code, but I'm torn as to whether the 'orphanskill' command is sufficiently useful to >>> the general community. >>> >>> So, that's the question. Is 'orphanskill' worth adding to mock? >> GDB is not the only build that leaves orphaned processes lying around. >> I've seen similar behavior when building gcc, glibc, and mysql, to name >> a few. The problems are usually caused by test suites called during the >> build process, and leaving them around after a build has completed (or >> failed) can tie up system resources or in some cases cause subsequent >> builds to fail. >> >> Just as mock cleans up the filesystem after a build, it should probably >> be cleaning up the process list as well. I'd be in favor of adding this >> patch. Koji could certainly make use of it. > > It looks to me that, no matter the design of mock, we need to have this > functionality. > > As long as the patch looks reasonable, we probably need to include it > for now, until we get to the point where we drop the suid binary. > That makes sense. I've got Jan's patch and I'll apply it to the current head (locally) and make sure it still works, then I'll push it to my public tree for you guys to review. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGlAO0Hyuj/+TTEp0RAtpNAKC5K52QYeCDq/2kVFWixd5NPy5McACgvK3h wVcqiMvrKdMjer3yL5RuPmM= =pVg6 -----END PGP SIGNATURE----- From sergio at sergiomb.no-ip.org Wed Jul 11 00:35:06 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Wed, 11 Jul 2007 01:35:06 +0100 Subject: missed pungi-fc6. Message-ID: <1184114106.7440.3.camel@monteirov> on https://hosted.fedoraproject.org/projects/pungi/wiki/PungiDocs/ConfigDocs is write: pungi-fc6. A set of config files supplied to spin FC6+Updates releases. I don't find any pungi-fc6 I'd like try make F7+ updates has any one tried ? how looks like pungi confs ? Thanks in advance ! -- S?rgio M.B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From jkeating at redhat.com Wed Jul 11 01:39:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 10 Jul 2007 21:39:37 -0400 Subject: missed pungi-fc6. In-Reply-To: <1184114106.7440.3.camel@monteirov> References: <1184114106.7440.3.camel@monteirov> Message-ID: <200707102139.41112.jkeating@redhat.com> On Tuesday 10 July 2007 20:35:06 Sergio Monteiro Basto wrote: > pungi-fc6. > ? ? ? ? A set of config files supplied to spin FC6+Updates releases. > > I don't find any pungi-fc6 > I'd like try make F7+ updates This was removed and replaced with f7-fedora. files that service as the configs used to produce Fedora 7. Composing Fedora 6 with the pungi from Fedora 7 will not work. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Wed Jul 11 13:41:50 2007 From: opensource at till.name (Till Maas) Date: Wed, 11 Jul 2007 15:41:50 +0200 Subject: [PATCH] Makefile.common: correct URL to Koji setup page in the wiki Message-ID: <200707111541.51834.opensource@till.name> Aloas, the attached patch changes the URL in Makefile.common for Koji client setup from http://fedoraproject.org/wiki/BuildSystemClientSetup to http://fedoraproject.org/wiki/PackageMaintainers/BuildSystemClientSetup The first URL is a redirection to the second one. If this is not the correct place to post a patch, please give me a pointer. I will write then a patch to Makefile.common to include a comment with the correct place/URL/procedure to submit patches. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common.BuildSystemClientSetup-url.patch Type: text/x-makefile Size: 821 bytes Desc: not available URL: From sergio at sergiomb.no-ip.org Wed Jul 11 14:04:13 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Wed, 11 Jul 2007 15:04:13 +0100 Subject: missed pungi-fc6. In-Reply-To: <200707102139.41112.jkeating@redhat.com> References: <1184114106.7440.3.camel@monteirov> <200707102139.41112.jkeating@redhat.com> Message-ID: <1184162653.23704.2.camel@localhost.localdomain> On Tue, 2007-07-10 at 21:39 -0400, Jesse Keating wrote: > > I'd like try make F7+ updates > > This was removed and replaced with f7-fedora. files that service > as the > configs used to produce Fedora 7. Composing Fedora 6 with the pungi > from > Fedora 7 will not work. Well I still don't see any f7-fedora. that produce Fedora 7 + updates , can you explain me or point to somewhere, how I produce a Fedora 7 _with_ all updates. Thanks in advance, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From jkeating at redhat.com Wed Jul 11 15:06:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 11 Jul 2007 11:06:12 -0400 Subject: missed pungi-fc6. In-Reply-To: <1184162653.23704.2.camel@localhost.localdomain> References: <1184114106.7440.3.camel@monteirov> <200707102139.41112.jkeating@redhat.com> <1184162653.23704.2.camel@localhost.localdomain> Message-ID: <200707111106.12988.jkeating@redhat.com> On Wednesday 11 July 2007 10:04:13 Sergio Monteiro Basto wrote: > Well I still don't see any f7-fedora. that produce Fedora 7 + > updates , can you explain me or point to somewhere, how I produce a > Fedora 7 _with_ all updates. The 'f7-fedora.i386' is the starting point, then alter the yum config file it points to by adding the updates repo (which wasn't available when I created these config files...), and you'll automatically get updated versions of the packages if they are available. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From opensource at till.name Wed Jul 11 15:22:15 2007 From: opensource at till.name (Till Maas) Date: Wed, 11 Jul 2007 17:22:15 +0200 Subject: [PATCH] Makefile.common: add scratch build targets Message-ID: <200707111722.17348.opensource@till.name> Aloas, the attached patch adds support for scratch builds to Makefile.common: scratch-build Request scratch build of "fcgi-2_4_0-2_fc8" for dist-f8 scratch-build- Request scratch build of "fcgi-2_4_0-2_fc8" for dist-f8 and archs examples: make scratch-build-i386,ppc64 make scratch-build-x86_64 Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefil.common-scratch-build.patch Type: text/x-diff Size: 2272 bytes Desc: not available URL: From dennis at ausil.us Wed Jul 11 15:39:59 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 11 Jul 2007 10:39:59 -0500 Subject: [PATCH] Makefile.common: add scratch build targets In-Reply-To: <200707111722.17348.opensource@till.name> References: <200707111722.17348.opensource@till.name> Message-ID: <200707111040.00066.dennis@ausil.us> On Wednesday 11 July 2007 10:22:15 am Till Maas wrote: > Aloas, > > the attached patch adds support for scratch builds to Makefile.common: > > scratch-build Request scratch build of "fcgi-2_4_0-2_fc8" for dist-f8 > scratch-build- Request scratch build of "fcgi-2_4_0-2_fc8" for > dist-f8 and archs > examples: make scratch-build-i386,ppc64 > make scratch-build-x86_64 > > Regards, > Till Rather than have a check for koji's existence in each target, i would perfer a target to check for koji and have the makefile call that. Then if the location to get information changes or we switch out koji and go to something else we only need to update information in one place. Dennis From opensource at till.name Wed Jul 11 16:02:50 2007 From: opensource at till.name (Till Maas) Date: Wed, 11 Jul 2007 18:02:50 +0200 Subject: [PATCH] Makefile.common: add scratch build targets In-Reply-To: <200707111040.00066.dennis@ausil.us> References: <200707111722.17348.opensource@till.name> <200707111040.00066.dennis@ausil.us> Message-ID: <200707111802.51882.opensource@till.name> On Mi Juli 11 2007, Dennis Gilmore wrote: > Rather than have a check for koji's existence in each target, i would > perfer a target to check for koji and have the makefile call that. Then if > the location to get information changes or we switch out koji and go to > something else we only need to update information in one place. Yes, I thought of this, too. Here is a patch that adds also a target koji-check, that checks for koji and also depends on build-check and $(COMMON_DIR)/branches, which all other koji build targets have in common. Also I added it to the chain-build target because afaik only koji supports chain-building. Do you maybe know a way to unify the redundant koji commandlines? This is something that may be improved, imho, but I do not know, whether or not there is an elegant way to do this with make. @$(BUILD_CLIENT) build $(BUILD_FLAGS) $(TARGET) '$(CVS_URL)' @$(BUILD_CLIENT) build --scratch $(BUILD_FLAGS) $(TARGET) '$(CVS_URL)' @$(BUILD_CLIENT) build --scratch --arch-override=$* $(BUILD_FLAGS) $(TARGET) '$(CVS_URL)' Is there are reason why all the targets should depend on "$(COMMON_DIR)/branches"? Maybe this can be dropped completely. Also imho the variable BUILD_CLIENT should be renamed to KOJI_CLIENT, I can provide a patch for this, too. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common-scratch-build-koji-check.patch Type: text/x-makefile Size: 2814 bytes Desc: not available URL: From opensource at till.name Wed Jul 11 16:29:11 2007 From: opensource at till.name (Till Maas) Date: Wed, 11 Jul 2007 18:29:11 +0200 Subject: [PATCH] Makefile.common: add scratch build targets In-Reply-To: <200707111802.51882.opensource@till.name> References: <200707111722.17348.opensource@till.name> <200707111040.00066.dennis@ausil.us> <200707111802.51882.opensource@till.name> Message-ID: <200707111829.13531.opensource@till.name> On Mi Juli 11 2007, Till Maas wrote: > @$(BUILD_CLIENT) build $(BUILD_FLAGS) $(TARGET) '$(CVS_URL)' > @$(BUILD_CLIENT) build --scratch $(BUILD_FLAGS) $(TARGET) '$(CVS_URL)' > @$(BUILD_CLIENT) build --scratch --arch-override=$* $(BUILD_FLAGS) > $(TARGET) '$(CVS_URL)' This new patch uses a variable and the $(call ...) to reduce the redundant code this way: koji-build = $(BUILD_CLIENT) build $(1) $(BUILD_FLAGS) $(TARGET) '$(CVS_URL)' koji: koji-check $(call koji-build) scratch-build: koji-check $(call koji-build, --scratch) scratch-build-%: koji-check $(call koji-build, --scratch --arch-overwrite=$*) Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common-scratch-build_koji-check_koji-build.patch Type: text/x-makefile Size: 2850 bytes Desc: not available URL: From opensource at till.name Wed Jul 11 16:40:50 2007 From: opensource at till.name (Till Maas) Date: Wed, 11 Jul 2007 18:40:50 +0200 Subject: [PATCH] Makefile.common: remove CVS_EXTRAS_RC Message-ID: <200707111840.51424.opensource@till.name> Hiyas, Makefile.common uses CVS_EXTRAS_RC to define the variable of the user config file and uses a complex structure to only include it, when it is a file. According to "info make", there is a much easier way: | If you want `make' to simply ignore a makefile which does not exist | and cannot be remade, with no error message, use the `-include' | directive instead of `include', like this: -include $(HOME)/.cvspkgsrc Imho, this makes the Makefile much more easier to read and also removes a reference to Extras with the variable CVS_EXTRAS_RC. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common-remove-CVS_EXTRAS_RC.patch Type: text/x-makefile Size: 643 bytes Desc: not available URL: From Michael_E_Brown at dell.com Wed Jul 11 18:13:16 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 11 Jul 2007 13:13:16 -0500 Subject: RFC: utility of 'orphansbuild' patch to mock-helper (BZ#221351)? In-Reply-To: <469403B4.7040003@redhat.com> References: <4693B9A3.1050604@redhat.com> <1184087613.7724.26.camel@liffey.home> <20070710190149.GB19578@humbolt.us.dell.com> <469403B4.7040003@redhat.com> Message-ID: <20070711181315.GA9945@humbolt.us.dell.com> On Tue, Jul 10, 2007 at 05:09:56PM -0500, Clark Williams wrote: > > It looks to me that, no matter the design of mock, we need to have this > > functionality. > > > > As long as the patch looks reasonable, we probably need to include it > > for now, until we get to the point where we drop the suid binary. > > > > That makes sense. I've got Jan's patch and I'll apply it to the current head > (locally) and make sure it still works, then I'll push it to my public tree for you > guys to review. Clark, I went ahead and tagged git for 0.7.3 with the groupinstall changes and pushed upstream yesterday. I just submitted a build for -devel. This should make Jesse happy since he has been waiting on this. I will hold off on submitting 0.7.3 for F-6/7 and EPEL4/5 until we get the current changes done to cut down churn. We can do an 0.7.4 release with these changes. -- Michael From sergio at sergiomb.no-ip.org Wed Jul 11 20:16:16 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Wed, 11 Jul 2007 21:16:16 +0100 Subject: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' Message-ID: <1184184976.23775.5.camel@localhost.localdomain> Hi, I use updated fedora 7 what I could do ? pungi -c /etc/pungi/f7-everything.i386 stops width : INFO:pypungi.pungi:Running /usr/lib/anaconda-runtime/pkgorder /srv/pungi/f7/7/Everything/i386/os i386 Fedora ERROR:pypungi.pungi:Got an error from /usr/lib/anaconda-runtime/pkgorder ERROR:pypungi.pungi:Traceback (most recent call last): File "/usr/lib/anaconda-runtime/pkgorder", line 169, in addGroups(ds, ["core", "base", "text-internet"]) File "/usr/lib/anaconda-runtime/pkgorder", line 105, in addGroups processTransaction(ds) File "/usr/lib/anaconda-runtime/pkgorder", line 77, in processTransaction ds.populateTs(keepold=0) File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 201, in populateTs self.downloadHeader(txmbr.po) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 863, in downloadHeader cache=repo.http_caching != 'none', File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 599, in getHeader cache=cache, File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 567, in _getFile http_headers=headers, File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 411, in urlgrab return self._mirror_try(func, url, kw) File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 397, in _mirror_try return func_ref( *(fullurl,), **kwargs ) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 927, in urlgrab return self._retry(opts, retryfunc, url, filename) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 845, in _retry r = apply(func, (opts,) + args, {}) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 915, in retryfunc fo._do_grab() File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 1196, in _do_grab else: new_fo = open(self.filename, 'wb') IOError: [Errno 2] No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' Thanks, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From opensource at till.name Thu Jul 12 12:40:46 2007 From: opensource at till.name (Till Maas) Date: Thu, 12 Jul 2007 14:40:46 +0200 Subject: [PATCH] Makefile.common: properly define the default goal Message-ID: <200707121440.47210.opensource@till.name> Aloa, the attached patch makes sure, that "all" ist the default goal, even when there are other targets in .cvspkgsrc. This allows to define other targets in this configuration file without changing the default goal. When one wants to change the default goal, this is still possible with setting .DEFAULT_GOAL to this goal. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common-default-goal.patch Type: text/x-makefile Size: 483 bytes Desc: not available URL: From cpg at users.sourceforge.net Thu Jul 12 15:24:00 2007 From: cpg at users.sourceforge.net (Carlos Puchol) Date: Thu, 12 Jul 2007 08:24:00 -0700 Subject: yum/rpm libraries in ruby? Message-ID: <20070712152400.GA28365@arctic.org> hi, is anyone aware of any yum and/or rpm libraries in ruby? i cannot seem to find any. thanks, -c From skvidal at linux.duke.edu Thu Jul 12 15:26:43 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 12 Jul 2007 11:26:43 -0400 Subject: yum/rpm libraries in ruby? In-Reply-To: <20070712152400.GA28365@arctic.org> References: <20070712152400.GA28365@arctic.org> Message-ID: <1184254003.8342.0.camel@cutter> On Thu, 2007-07-12 at 08:24 -0700, Carlos Puchol wrote: > hi, > > is anyone aware of any yum and/or rpm libraries in ruby? > i cannot seem to find any. > > thanks, There aren't any that I know of. -sv From mail-lists at karan.org Thu Jul 12 21:31:52 2007 From: mail-lists at karan.org (Karanbir Singh) Date: Thu, 12 Jul 2007 22:31:52 +0100 Subject: yum/rpm libraries in ruby? In-Reply-To: <20070712152400.GA28365@arctic.org> References: <20070712152400.GA28365@arctic.org> Message-ID: <46969DC8.8010409@karan.org> Carlos Puchol wrote: > hi, > > is anyone aware of any yum and/or rpm libraries in ruby? > i cannot seem to find any. > loook here : http://raa.ruby-lang.org/project/ruby-rpm/ and http://people.redhat.com/~dlutter/yum/SRPMS/ruby-rpm-1.2.3-1.src.rpm - KB -- Karanbir Singh : http://www.karan.org/ : 2522219 at icq From dlutter at redhat.com Thu Jul 12 22:04:38 2007 From: dlutter at redhat.com (David Lutterkort) Date: Thu, 12 Jul 2007 15:04:38 -0700 Subject: yum/rpm libraries in ruby? In-Reply-To: <46969DC8.8010409@karan.org> References: <20070712152400.GA28365@arctic.org> <46969DC8.8010409@karan.org> Message-ID: <1184277878.9501.1.camel@galia.watzmann.net> On Thu, 2007-07-12 at 22:31 +0100, Karanbir Singh wrote: > Carlos Puchol wrote: > > hi, > > > > is anyone aware of any yum and/or rpm libraries in ruby? > > i cannot seem to find any. > > > > loook here : http://raa.ruby-lang.org/project/ruby-rpm/ That one seems to be dead - at least, I (and others) could not get in touch with Kenta. > and http://people.redhat.com/~dlutter/yum/SRPMS/ruby-rpm-1.2.3-1.src.rpm The upstream for this is http://rubyforge.org/projects/ruby-rpm/ - patches welcome :) David From sergio at sergiomb.no-ip.org Fri Jul 13 13:05:25 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Fri, 13 Jul 2007 14:05:25 +0100 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <1184184976.23775.5.camel@localhost.localdomain> References: <1184184976.23775.5.camel@localhost.localdomain> Message-ID: <1184331925.3309.3.camel@localhost.localdomain> yap , pungi -P stops with message above others stages works including SplitTree stage and CreateISO. Anything that I can test ? thanks, On Wed, 2007-07-11 at 21:16 +0100, Sergio Monteiro Basto wrote: > Hi, > I use updated fedora 7 > what I could do ? > > pungi -c /etc/pungi/f7-everything.i386 stops width : > > INFO:pypungi.pungi:Running /usr/lib/anaconda-runtime/pkgorder /srv/pungi/f7/7/Everything/i386/os i386 Fedora > ERROR:pypungi.pungi:Got an error from /usr/lib/anaconda-runtime/pkgorder > ERROR:pypungi.pungi:Traceback (most recent call last): > File "/usr/lib/anaconda-runtime/pkgorder", line 169, in > addGroups(ds, ["core", "base", "text-internet"]) > File "/usr/lib/anaconda-runtime/pkgorder", line 105, in addGroups > processTransaction(ds) > File "/usr/lib/anaconda-runtime/pkgorder", line 77, in processTransaction > ds.populateTs(keepold=0) > File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 201, in populateTs > self.downloadHeader(txmbr.po) > File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 863, in downloadHeader > cache=repo.http_caching != 'none', > File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 599, in getHeader > cache=cache, > File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 567, in _getFile > http_headers=headers, > File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 411, in urlgrab > return self._mirror_try(func, url, kw) > File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 397, in _mirror_try > return func_ref( *(fullurl,), **kwargs ) > File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 927, in urlgrab > return self._retry(opts, retryfunc, url, filename) > File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 845, in _retry > r = apply(func, (opts,) + args, {}) > File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 915, in retryfunc > fo._do_grab() > File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 1196, in _do_grab > else: new_fo = open(self.filename, 'wb') > IOError: [Errno 2] No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' > > Thanks, > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From jkeating at redhat.com Fri Jul 13 14:05:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Jul 2007 10:05:45 -0400 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <1184331925.3309.3.camel@localhost.localdomain> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> Message-ID: <20070713100545.231dbe88@ender> On Fri, 13 Jul 2007 14:05:25 +0100 Sergio Monteiro Basto wrote: > yap , pungi -P stops with message above > others stages works including SplitTree stage and CreateISO. Sounds like pkgorder is busted in some way. > Anything that I can test ? Well, we'll probably have to find out why pkgorder is busted and either work around it or fix it. Most likely we'll have to work around it since pkgorder is in anaconda and that doesn't really get updates. -- Jesse Keating Release Engineer: Fedora From wacker at octothorp.org Fri Jul 13 22:25:06 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Fri, 13 Jul 2007 16:25:06 -0600 (MDT) Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <20070713100545.231dbe88@ender> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> Message-ID: On Fri, 13 Jul 2007, Jesse Keating wrote: > On Fri, 13 Jul 2007 14:05:25 +0100 > Sergio Monteiro Basto wrote: > >> yap , pungi -P stops with message above >> others stages works including SplitTree stage and CreateISO. > > Sounds like pkgorder is busted in some way. > >> Anything that I can test ? > > Well, we'll probably have to find out why pkgorder is busted and either > work around it or fix it. Most likely we'll have to work around it > since pkgorder is in anaconda and that doesn't really get updates. Could it be the latest yum? I got a report of a similar error when trying to install. I reverted yum, and am waiting for a report. HTH. -- Bill in Denver From jkeating at redhat.com Sat Jul 14 01:01:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 13 Jul 2007 21:01:51 -0400 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> Message-ID: <20070713210151.28d55e51@ender> On Fri, 13 Jul 2007 16:25:06 -0600 (MDT) "William F. Acker WB2FLW +1-303-722-7209" wrote: > Could it be the latest yum? I got a report of a similar error > when trying to install. I reverted yum, and am waiting for a report. It very well could be yum. Please let me know if things work better with the older yum. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wacker at octothorp.org Sat Jul 14 23:55:29 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Sat, 14 Jul 2007 17:55:29 -0600 (MDT) Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <20070713210151.28d55e51@ender> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> Message-ID: On Fri, 13 Jul 2007, Jesse Keating wrote: > On Fri, 13 Jul 2007 16:25:06 -0600 (MDT) > "William F. Acker WB2FLW +1-303-722-7209" wrote: > >> Could it be the latest yum? I got a report of a similar error >> when trying to install. I reverted yum, and am waiting for a report. > > It very well could be yum. Please let me know if things work better > with the older yum. > > They seem to. I've now had two separate reports of success. HTH. -- Bill in Denver From jkeating at redhat.com Sun Jul 15 02:13:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 14 Jul 2007 22:13:20 -0400 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> Message-ID: <20070714221320.20dd85dc@ender> On Sat, 14 Jul 2007 17:55:29 -0600 (MDT) "William F. Acker WB2FLW +1-303-722-7209" wrote: > They seem to. I've now had two separate reports of success. Interesting. Ok, now I'll have to see what changed in yum api to leave pkgorder behind. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Sun Jul 15 13:17:17 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 15 Jul 2007 15:17:17 +0200 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <20070714221320.20dd85dc@ender> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> Message-ID: <469A1E5D.3050202@kanarip.com> Jesse Keating wrote: > On Sat, 14 Jul 2007 17:55:29 -0600 (MDT) > "William F. Acker WB2FLW +1-303-722-7209" wrote: > >> They seem to. I've now had two separate reports of success. > > Interesting. Ok, now I'll have to see what changed in yum api to leave > pkgorder behind. > I've heard yum does not create the header(s) directory / files anymore. Kind regards, Jeroen van Meeuwen -kanarip From sergio at sergiomb.no-ip.org Mon Jul 16 15:34:58 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Mon, 16 Jul 2007 16:34:58 +0100 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <20070714221320.20dd85dc@ender> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> Message-ID: <1184600098.9130.4.camel@localhost.localdomain> On Sat, 2007-07-14 at 22:13 -0400, Jesse Keating wrote: > On Sat, 14 Jul 2007 17:55:29 -0600 (MDT) > "William F. Acker WB2FLW +1-303-722-7209" wrote: > > > They seem to. I've now had two separate reports of success. > > Interesting. Ok, now I'll have to see what changed in yum api to leave > pkgorder behind. > yep I confirm too rpm -Uvh yum-3.2.0-1.fc7.noarch.rpm --oldpackage have solved the problem ! and yes yum-3.2.1 don't generate any headers files but yum-3.2.0 does . thanks, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From jkeating at redhat.com Mon Jul 16 15:43:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Jul 2007 11:43:15 -0400 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <1184600098.9130.4.camel@localhost.localdomain> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> Message-ID: <20070716114315.38444de5@localhost.localdomain> On Mon, 16 Jul 2007 16:34:58 +0100 Sergio Monteiro Basto wrote: > yep I confirm too > > rpm -Uvh yum-3.2.0-1.fc7.noarch.rpm --oldpackage > have solved the problem ! > > and yes yum-3.2.1 don't generate any headers files but yum-3.2.0 > does . Seth has helped us track this down to a change in the yum api. We're testing a fix now that will create the headers directory if headers are asked for, which is a work around until such time as nothing requests the headers (if possible). An updated yum will fix this issue. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Jul 16 15:48:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Jul 2007 11:48:47 -0400 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <20070716114315.38444de5@localhost.localdomain> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> Message-ID: <20070716114847.1b67cddf@localhost.localdomain> On Mon, 16 Jul 2007 11:43:15 -0400 Jesse Keating wrote: > Seth has helped us track this down to a change in the yum api. We're > testing a fix now that will create the headers directory if headers > are asked for, which is a work around until such time as nothing > requests the headers (if possible). An updated yum will fix this > issue. It has been clarified to me that this wasn't an API change, instead a function change. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wacker at octothorp.org Mon Jul 16 16:05:11 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Mon, 16 Jul 2007 10:05:11 -0600 (MDT) Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <20070716114847.1b67cddf@localhost.localdomain> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> <20070716114847.1b67cddf@localhost.localdomain> Message-ID: On Mon, 16 Jul 2007, Jesse Keating wrote: > > It has been clarified to me that this wasn't an API change, instead a > function change. I wonder if this is better fixed in Anaconda. I'm aware of the policy against updating Anaconda once a general release happens, although an updated Anaconda did appear in FC6 testing, but was never pushed to updates. Now that we're being encouraged to spin our own releases, it seems to me that the policy should be revisited. -- Bill in Denver From jkeating at redhat.com Mon Jul 16 16:40:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 16 Jul 2007 12:40:50 -0400 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> <20070716114847.1b67cddf@localhost.localdomain> Message-ID: <20070716124050.2c066878@localhost.localdomain> On Mon, 16 Jul 2007 10:05:11 -0600 (MDT) "William F. Acker WB2FLW +1-303-722-7209" wrote: > I wonder if this is better fixed in Anaconda. I'm aware of the > policy against updating Anaconda once a general release happens, > although an updated Anaconda did appear in FC6 testing, but was never > pushed to updates. Now that we're being encouraged to spin our own > releases, it seems to me that the policy should be revisited. In reality, this is something that should have been in yum anyway, basically ensure that the headers directory exists if yum is being asked for headers. As for updating anaconda, well, there are only so many work hours in the day, and so much that we want to accomplish for the next release. Spending time on re-releasing stuff for the current release just takes time away from the next release. Most anaconda issues can be worked around in various ways so that an update won't be necessary. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Mon Jul 16 20:42:49 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 16 Jul 2007 22:42:49 +0200 Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> <20070716114847.1b67cddf@localhost.localdomain> Message-ID: <469BD849.3030309@kanarip.com> William F. Acker WB2FLW +1-303-722-7209 wrote: > On Mon, 16 Jul 2007, Jesse Keating wrote: > >> >> It has been clarified to me that this wasn't an API change, instead a >> function change. > > I wonder if this is better fixed in Anaconda. I'm aware of the > policy against updating Anaconda once a general release happens, > although an updated Anaconda did appear in FC6 testing, but was never > pushed to updates. Now that we're being encouraged to spin our own > releases, it seems to me that the policy should be revisited. > If I understand correctly the fix is in anaconda's development release. Kind regards, Jeroen van Meeuwen -kanarip From wacker at octothorp.org Mon Jul 16 23:41:22 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Mon, 16 Jul 2007 17:41:22 -0600 (MDT) Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <20070716124050.2c066878@localhost.localdomain> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> <20070716114847.1b67cddf@localhost.localdomain> <20070716124050.2c066878@localhost.localdomain> Message-ID: On Mon, 16 Jul 2007, Jesse Keating wrote: > In reality, this is something that should have been in yum anyway, > basically ensure that the headers directory exists if yum is being > asked for headers. > > As for updating anaconda, well, there are only so many work hours in the > day, and so much that we want to accomplish for the next release. > Spending time on re-releasing stuff for the current release just takes > time away from the next release. Most anaconda issues can be worked > around in various ways so that an update won't be necessary. I can dig it. I've done a few work-arounds for Anaconda locally in my time. Thanks for all the hard work. I love Pungi!! -- Bill in Denver From wacker at octothorp.org Mon Jul 16 23:44:43 2007 From: wacker at octothorp.org (William F. Acker WB2FLW +1-303-722-7209) Date: Mon, 16 Jul 2007 17:44:43 -0600 (MDT) Subject: pungi -P doesn't work Re: No such file or directory: u'/var/tmp/yum-root-O3By9L/anaconda/headers/ifd-egate-0.05-17.i386.hdr' In-Reply-To: <469BD849.3030309@kanarip.com> References: <1184184976.23775.5.camel@localhost.localdomain> <1184331925.3309.3.camel@localhost.localdomain> <20070713100545.231dbe88@ender> <20070713210151.28d55e51@ender> <20070714221320.20dd85dc@ender> <1184600098.9130.4.camel@localhost.localdomain> <20070716114315.38444de5@localhost.localdomain> <20070716114847.1b67cddf@localhost.localdomain> <469BD849.3030309@kanarip.com> Message-ID: On Mon, 16 Jul 2007, Jeroen van Meeuwen wrote: > > If I understand correctly the fix is in anaconda's development release. > > Kind regards, Does anyone know if the version now in development will still install Moonshine? -- Bill in Denver From sheltren at cs.ucsb.edu Wed Jul 18 12:26:25 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 18 Jul 2007 08:26:25 -0400 Subject: mock not reporting rpmbuild errors Message-ID: <9764DBE2-829E-41E8-A9E2-6B2018D87366@cs.ucsb.edu> Hi, is anyone else seeing this issue with current versions of mock? If rpmbuild exits with an error, mock proceeds happily as if the build succeeded. This is really annoying when building with plague, for example, since even if the build fails, the job gets added to the 'Successful Builds' list, and I won't get an email with the build error sent to me. I opened a BZ for this a couple of weeks ago, but it hasn't been responded to: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246614 Thanks, Jeff From fabrice at bellet.info Wed Jul 18 12:38:32 2007 From: fabrice at bellet.info (Fabrice Bellet) Date: Wed, 18 Jul 2007 14:38:32 +0200 Subject: mock not reporting rpmbuild errors In-Reply-To: <9764DBE2-829E-41E8-A9E2-6B2018D87366@cs.ucsb.edu> References: <9764DBE2-829E-41E8-A9E2-6B2018D87366@cs.ucsb.edu> Message-ID: <20070718123832.GA365@bellet.info> Hi, On Wed, Jul 18, 2007 at 08:26:25AM -0400, Jeff Sheltren wrote: > Hi, is anyone else seeing this issue with current versions of mock? If > rpmbuild exits with an error, mock proceeds happily as if the build > succeeded. This is really annoying when building with plague, for example, > since even if the build fails, the job gets added to the 'Successful > Builds' list, and I won't get an email with the build error sent to me. > > I opened a BZ for this a couple of weeks ago, but it hasn't been responded > to: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246614 I suggested a fix for this bug same bug in : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244596 -- fabrice From sheltren at cs.ucsb.edu Wed Jul 18 12:45:41 2007 From: sheltren at cs.ucsb.edu (Jeff Sheltren) Date: Wed, 18 Jul 2007 08:45:41 -0400 Subject: mock not reporting rpmbuild errors In-Reply-To: <20070718123832.GA365@bellet.info> References: <9764DBE2-829E-41E8-A9E2-6B2018D87366@cs.ucsb.edu> <20070718123832.GA365@bellet.info> Message-ID: On Jul 18, 2007, at 8:38 AM, Fabrice Bellet wrote: > > I suggested a fix for this bug same bug in : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244596 > Thanks, I missed that when searching through mock bugs. I'll try your patch. -Jeff From Michael_E_Brown at dell.com Wed Jul 18 18:14:18 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 18 Jul 2007 13:14:18 -0500 Subject: mock not reporting rpmbuild errors In-Reply-To: <20070718123832.GA365@bellet.info> References: <9764DBE2-829E-41E8-A9E2-6B2018D87366@cs.ucsb.edu> <20070718123832.GA365@bellet.info> Message-ID: <20070718181418.GB31281@humbolt.us.dell.com> On Wed, Jul 18, 2007 at 02:38:32PM +0200, Fabrice Bellet wrote: > Hi, > > On Wed, Jul 18, 2007 at 08:26:25AM -0400, Jeff Sheltren wrote: > > Hi, is anyone else seeing this issue with current versions of mock? If > > rpmbuild exits with an error, mock proceeds happily as if the build > > succeeded. This is really annoying when building with plague, for example, > > since even if the build fails, the job gets added to the 'Successful > > Builds' list, and I won't get an email with the build error sent to me. > > > > I opened a BZ for this a couple of weeks ago, but it hasn't been responded > > to: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246614 > > I suggested a fix for this bug same bug in : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=244596 Thanks for the spot. Patch accepted and pushed for 0.7.4. I'm building 0.7.4 for rawhide now. Will push to older releases shortly. -- Michael From asdas at redhat.com Thu Jul 19 05:00:12 2007 From: asdas at redhat.com (ashok shankar das) Date: Thu, 19 Jul 2007 10:30:12 +0530 Subject: Persistent LiveCD In-Reply-To: <20070718181418.GB31281@humbolt.us.dell.com> References: <9764DBE2-829E-41E8-A9E2-6B2018D87366@cs.ucsb.edu> <20070718123832.GA365@bellet.info> <20070718181418.GB31281@humbolt.us.dell.com> Message-ID: <469EEFDC.9020502@redhat.com> Hi, We have achived making a persistent LiveCD. The media which is to be used for storing data, should be specified in the kernel command line at the time of booting. In the current setup we have tested this with a Live CD created using pilgrim and a USB stick. -- Thanks Ashok Shankar Das RedHat, Pune +91-9373695832 From katzj at redhat.com Thu Jul 19 14:28:43 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 19 Jul 2007 10:28:43 -0400 Subject: Persistent LiveCD In-Reply-To: <469EEFDC.9020502@redhat.com> References: <9764DBE2-829E-41E8-A9E2-6B2018D87366@cs.ucsb.edu> <20070718123832.GA365@bellet.info> <20070718181418.GB31281@humbolt.us.dell.com> <469EEFDC.9020502@redhat.com> Message-ID: <1184855323.22262.13.camel@localhost.localdomain> On Thu, 2007-07-19 at 10:30 +0530, ashok shankar das wrote: > We have achived making a persistent LiveCD. > The media which is to be used for storing data, should be specified in > the kernel command line > at the time of booting. > > In the current setup we have tested this with a Live CD created using > pilgrim and a USB stick. Two things: 1) fedora-livecd-list is a much better place to send this 2) Rather than just saying "we have achieved", why not actually send the patch you're using? Jeremy From Matt.Patterson at bbc.co.uk Fri Jul 20 11:52:26 2007 From: Matt.Patterson at bbc.co.uk (Matt Patterson) Date: Fri, 20 Jul 2007 12:52:26 +0100 Subject: Problems specifying when config_opts['macros'] in a mock configuration file Message-ID: Hello, I'm trying to define some RPM macros using the config_opts['macros'] option in a mock.cfg as follows: config_opts['macros'] = """ %_dist bbc_gems """ When this section is present, mock fails with: No Spec file found in srpm: rubygem-bbc_extractor-0.0.1-1.src.rpm When I comment out the three lines above, it all works perfectly... Am I doing something silly? Is there a better way to set up mock with per-configuration RPM macros? Thanks, Matt -- Matt Patterson Senior Software Engineer, BBC Audio & Music Interactive http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From paul at city-fan.org Fri Jul 20 12:08:16 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 20 Jul 2007 13:08:16 +0100 Subject: Problems specifying when config_opts['macros'] in a mock configuration file In-Reply-To: References: Message-ID: <46A0A5B0.1080300@city-fan.org> Matt Patterson wrote: > Hello, > > I'm trying to define some RPM macros using the config_opts['macros'] option > in a mock.cfg as follows: > > config_opts['macros'] = """ > %_dist bbc_gems > """ > > When this section is present, mock fails with: > > No Spec file found in srpm: rubygem-bbc_extractor-0.0.1-1.src.rpm > > When I comment out the three lines above, it all works perfectly... > > Am I doing something silly? Is there a better way to set up mock with > per-configuration RPM macros? Try this: config_opts['macros'] = """ %%_topdir %s/build %%_rpmfilename %%%%{NAME}-%%%%{VERSION}-%%%%{RELEASE}.%%%%{ARCH}.rpm %%_dist bbc_gems """ % config_opts['chroothome'] Paul. From Matt.Patterson at bbc.co.uk Fri Jul 20 12:58:32 2007 From: Matt.Patterson at bbc.co.uk (Matt Patterson) Date: Fri, 20 Jul 2007 13:58:32 +0100 Subject: Problems specifying when config_opts['macros'] in a mock configuration file In-Reply-To: <46A0A5B0.1080300@city-fan.org> Message-ID: On 20/7/07 13:08, "Paul Howarth" wrote: > Try this: > > config_opts['macros'] = """ > %%_topdir %s/build > %%_rpmfilename %%%%{NAME}-%%%%{VERSION}-%%%%{RELEASE}.%%%%{ARCH}.rpm > %%_dist bbc_gems > """ % config_opts['chroothome'] Interesting, thanks, it worked a treat. But, why do I have to set so many values: aren't _topdir and _rpmfilename set elsewhere? The mock source makes it look like setting config_opts['macros'] simply prepends the string to a ~/.rpmmacros file, which I would've thought wouldn't cause other things to be, what, undefined or redefined... Thanks, Matt -- Matt Patterson Senior Software Engineer, BBC Audio & Music Interactive http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From paul at city-fan.org Fri Jul 20 13:09:23 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 20 Jul 2007 14:09:23 +0100 Subject: Problems specifying when config_opts['macros'] in a mock configuration file In-Reply-To: References: Message-ID: <46A0B403.507@city-fan.org> Matt Patterson wrote: > On 20/7/07 13:08, "Paul Howarth" wrote: > >> Try this: >> >> config_opts['macros'] = """ >> %%_topdir %s/build >> %%_rpmfilename %%%%{NAME}-%%%%{VERSION}-%%%%{RELEASE}.%%%%{ARCH}.rpm >> %%_dist bbc_gems >> """ % config_opts['chroothome'] > > Interesting, thanks, it worked a treat. > > But, why do I have to set so many values: aren't _topdir and _rpmfilename > set elsewhere? > > The mock source makes it look like setting config_opts['macros'] simply > prepends the string to a ~/.rpmmacros file, which I would've thought > wouldn't cause other things to be, what, undefined or redefined... That's right, but config_opts['macros'] has a default value that's built into mock, and that default value includes the definitions of those two macros, so if you override the default then you need to define those values or they won't be set anywhere. Maybe something like this would be better: config_opts['macros'] = config_opts['macros'] + """ %%_dist bc_gems """ Paul. From Matt.Patterson at bbc.co.uk Fri Jul 20 13:47:23 2007 From: Matt.Patterson at bbc.co.uk (Matt Patterson) Date: Fri, 20 Jul 2007 14:47:23 +0100 Subject: Problems specifying when config_opts['macros'] in a mock configuration file In-Reply-To: <46A0B403.507@city-fan.org> Message-ID: On 20/7/07 14:09, "Paul Howarth" wrote: > Matt Patterson wrote: >> The mock source makes it look like setting config_opts['macros'] simply >> prepends the string to a ~/.rpmmacros file, which I would've thought >> wouldn't cause other things to be, what, undefined or redefined... > > That's right, but config_opts['macros'] has a default value that's built > into mock, and that default value includes the definitions of those two > macros, so if you override the default then you need to define those > values or they won't be set anywhere. That'll teach me to actually read the source properly... > Maybe something like this would be better: > > config_opts['macros'] = config_opts['macros'] + """ > %%_dist bc_gems > """ Yes indeed, that makes good sense. Thanks, Matt -- Matt Patterson Senior Software Engineer, BBC Audio & Music Interactive http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From Michael_E_Brown at dell.com Mon Jul 23 16:00:01 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 23 Jul 2007 11:00:01 -0500 Subject: Problems specifying when config_opts['macros'] in a mock configuration file In-Reply-To: <46A0B403.507@city-fan.org> References: <46A0B403.507@city-fan.org> Message-ID: <20070723160000.GF31281@humbolt.us.dell.com> On Fri, Jul 20, 2007 at 02:09:23PM +0100, Paul Howarth wrote: > Matt Patterson wrote: > >On 20/7/07 13:08, "Paul Howarth" wrote: > That's right, but config_opts['macros'] has a default value that's built > into mock, and that default value includes the definitions of those two > macros, so if you override the default then you need to define those > values or they won't be set anywhere. > > Maybe something like this would be better: > > config_opts['macros'] = config_opts['macros'] + """ > %%_dist bc_gems > """ An excellent suggestion. I'll update the defaults config file to indicate that this is the preferred way to set this option. this will be in the next release. -- Michael From pmeyer at themeyerfarm.com Mon Jul 23 17:04:27 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Mon, 23 Jul 2007 11:04:27 -0600 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <46A107C1.8020801@cohtech.com> References: <46A107C1.8020801@cohtech.com> Message-ID: <46A4DF9B.8080202@themeyerfarm.com> Howard Wilkinson wrote: > We routinely rebuild systems from a kickstart driven facility we have > built. This uses a Fedora image - in this case fedora 7 Everything > with the updates merged in. We have run into 2 problems with this as > opposed to the original release image. > > First the version of yum available in updates currently is > incompatible with the version of anaconda. The problem is that this > version of yum does not create the headers directory and anaconda > assumes it will exist. > > anaconda-11.2.0.66-1.i386.rpm > yum-3.2.1-1.fc7 > > To get round this we have reverted to yum-3.2.0-1.fc7.noarch.rpm for > now but will probably try out the development releases of anaconda and > yum next week. Confirmed. A little more detail: The directory /tmp/cache/headers is created, but empty. The directory /tmp/cache/anaconda-base-200707231006/headers was not created, and it is here that anaconda is looking for the headers. The first package that it tries to install will throw the error. Built using pungi-0.3.7-2 with a build system that worked great until the yum update to 3.2.1-1. Cross posting to fedora-buildsys-list. From pmeyer at themeyerfarm.com Mon Jul 23 17:05:50 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Mon, 23 Jul 2007 11:05:50 -0600 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <46A107C1.8020801@cohtech.com> References: <46A107C1.8020801@cohtech.com> Message-ID: <46A4DFEE.1080102@themeyerfarm.com> Howard Wilkinson wrote: > We routinely rebuild systems from a kickstart driven facility we have > built. This uses a Fedora image - in this case fedora 7 Everything > with the updates merged in. We have run into 2 problems with this as > opposed to the original release image. > > First the version of yum available in updates currently is > incompatible with the version of anaconda. The problem is that this > version of yum does not create the headers directory and anaconda > assumes it will exist. > > anaconda-11.2.0.66-1.i386.rpm > yum-3.2.1-1.fc7 > > To get round this we have reverted to yum-3.2.0-1.fc7.noarch.rpm for > now but will probably try out the development releases of anaconda and > yum next week. Confirmed. A little more detail: The directory /tmp/cache/headers is created, but empty. The directory /tmp/cache/anaconda-base-200707231006/headers was not created, and it is here that anaconda is looking for the headers. The first package that it tries to install will throw the error. Built using pungi-0.3.7-2 with a build system that worked great until the yum update to 3.2.1-1. Cross posting to fedora-buildsys-list. From jkeating at redhat.com Mon Jul 23 17:18:00 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 13:18:00 -0400 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <46A4DFEE.1080102@themeyerfarm.com> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> Message-ID: <20070723131800.5040e8e8@localhost.localdomain> On Mon, 23 Jul 2007 11:05:50 -0600 Phil Meyer wrote: > Built using pungi-0.3.7-2 with a build system that worked great until > the yum update to 3.2.1-1. > > Cross posting to fedora-buildsys-list. A new yum is in updates-testing, please try with it. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Mon Jul 23 17:14:37 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 23 Jul 2007 13:14:37 -0400 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <46A4DFEE.1080102@themeyerfarm.com> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> Message-ID: <1185210877.2408.22.camel@cutter> On Mon, 2007-07-23 at 11:05 -0600, Phil Meyer wrote: > Howard Wilkinson wrote: > > We routinely rebuild systems from a kickstart driven facility we have > > built. This uses a Fedora image - in this case fedora 7 Everything > > with the updates merged in. We have run into 2 problems with this as > > opposed to the original release image. > > > > First the version of yum available in updates currently is > > incompatible with the version of anaconda. The problem is that this > > version of yum does not create the headers directory and anaconda > > assumes it will exist. > > > > anaconda-11.2.0.66-1.i386.rpm > > yum-3.2.1-1.fc7 > > > > To get round this we have reverted to yum-3.2.0-1.fc7.noarch.rpm for > > now but will probably try out the development releases of anaconda and > > yum next week. > > Confirmed. > > A little more detail: > > The directory /tmp/cache/headers is created, but empty. > The directory /tmp/cache/anaconda-base-200707231006/headers was not > created, and it is here that anaconda is looking for the headers. The > first package that it tries to install will throw the error. > > Built using pungi-0.3.7-2 with a build system that worked great until > the yum update to 3.2.1-1. > > Cross posting to fedora-buildsys-list. > 3.2.2 has been released - 3.2.2-1.fc7 is in updates-testing. Please test it. -sv From pmeyer at themeyerfarm.com Mon Jul 23 21:01:51 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Mon, 23 Jul 2007 15:01:51 -0600 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <1185210877.2408.22.camel@cutter> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> <1185210877.2408.22.camel@cutter> Message-ID: <46A5173F.5060904@themeyerfarm.com> seth vidal wrote: > On Mon, 2007-07-23 at 11:05 -0600, Phil Meyer wrote: > >> Howard Wilkinson wrote: >> >>> We routinely rebuild systems from a kickstart driven facility we have >>> built. This uses a Fedora image - in this case fedora 7 Everything >>> with the updates merged in. We have run into 2 problems with this as >>> opposed to the original release image. >>> >>> First the version of yum available in updates currently is >>> incompatible with the version of anaconda. The problem is that this >>> version of yum does not create the headers directory and anaconda >>> assumes it will exist. >>> >>> anaconda-11.2.0.66-1.i386.rpm >>> yum-3.2.1-1.fc7 >>> >>> To get round this we have reverted to yum-3.2.0-1.fc7.noarch.rpm for >>> now but will probably try out the development releases of anaconda and >>> yum next week. >>> >> Confirmed. >> >> A little more detail: >> >> The directory /tmp/cache/headers is created, but empty. >> The directory /tmp/cache/anaconda-base-200707231006/headers was not >> created, and it is here that anaconda is looking for the headers. The >> first package that it tries to install will throw the error. >> >> Built using pungi-0.3.7-2 with a build system that worked great until >> the yum update to 3.2.1-1. >> >> Cross posting to fedora-buildsys-list. >> >> > > 3.2.2 has been released - 3.2.2-1.fc7 is in updates-testing. Please test > it. > > -sv > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > Installed yum 3.2.2 from updates-testing. Verified that pungi was using and installing the new version. No difference. Is there a newer anaconda coming soon? There seems to be a disconnect here. First, yum is creating /tmp/cache/headers Second, anaconda is expecting: /tmp/cache/anaconda-base-200707231006/headers (where 200707231006 is a date/time stamp) In either case, the headers directory is empty, and anaconda throws an error if the package header is not found. Is it yum, or is it anaconda that is asking yum for the wrong thing? Also, it is not just a kickstart thing. Any pungi derived distro using this stuff cannot be installed manually. A manual install generates the exact same error. From jkeating at redhat.com Mon Jul 23 21:10:14 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Jul 2007 17:10:14 -0400 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <46A5173F.5060904@themeyerfarm.com> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> <1185210877.2408.22.camel@cutter> <46A5173F.5060904@themeyerfarm.com> Message-ID: <20070723171014.78573548@localhost.localdomain> On Mon, 23 Jul 2007 15:01:51 -0600 Phil Meyer wrote: > Installed yum 3.2.2 from updates-testing. > Verified that pungi was using and installing the new version. Did you ensure that pungi repo configs point to a repo that has that yum available? It not only has to be installed on the host doing the compose, but in a repo that pungi is configured to use. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmeyer at themeyerfarm.com Mon Jul 23 21:35:19 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Mon, 23 Jul 2007 15:35:19 -0600 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <20070723171014.78573548@localhost.localdomain> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> <1185210877.2408.22.camel@cutter> <46A5173F.5060904@themeyerfarm.com> <20070723171014.78573548@localhost.localdomain> Message-ID: <46A51F17.6040907@themeyerfarm.com> Jesse Keating wrote: > On Mon, 23 Jul 2007 15:01:51 -0600 > Phil Meyer wrote: > > >> Installed yum 3.2.2 from updates-testing. >> Verified that pungi was using and installing the new version. >> > > Did you ensure that pungi repo configs point to a repo that has that > yum available? It not only has to be installed on the host doing the > compose, but in a repo that pungi is configured to use. > yup. This is from the log. INFO:yum.verbose.pungi:Downloading yum-3.2.2-1.fc7.noarch.rpm INFO:yum.verbose.pungi:Downloading yum-updatesd-3.2.2-1.fc7.noarch.rpm I will torch the pungi cache to make absolutely sure and report back. From pmeyer at themeyerfarm.com Tue Jul 24 16:16:40 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Tue, 24 Jul 2007 10:16:40 -0600 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <46A51F17.6040907@themeyerfarm.com> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> <1185210877.2408.22.camel@cutter> <46A5173F.5060904@themeyerfarm.com> <20070723171014.78573548@localhost.localdomain> <46A51F17.6040907@themeyerfarm.com> Message-ID: <46A625E8.8090007@themeyerfarm.com> Phil Meyer wrote: > Jesse Keating wrote: >> On Mon, 23 Jul 2007 15:01:51 -0600 >> Phil Meyer wrote: >> >> >>> Installed yum 3.2.2 from updates-testing. >>> Verified that pungi was using and installing the new version. >>> >> >> Did you ensure that pungi repo configs point to a repo that has that >> yum available? It not only has to be installed on the host doing the >> compose, but in a repo that pungi is configured to use. >> > > yup. > > This is from the log. > INFO:yum.verbose.pungi:Downloading yum-3.2.2-1.fc7.noarch.rpm > INFO:yum.verbose.pungi:Downloading yum-updatesd-3.2.2-1.fc7.noarch.rpm > > I will torch the pungi cache to make absolutely sure and report back. > Sorry for the slow response. Had to finish Harry Potter. :) After verifying the yum is 3.2.2 all the way through, still no change. From jkeating at redhat.com Tue Jul 24 16:41:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Jul 2007 12:41:15 -0400 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <46A625E8.8090007@themeyerfarm.com> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> <1185210877.2408.22.camel@cutter> <46A5173F.5060904@themeyerfarm.com> <20070723171014.78573548@localhost.localdomain> <46A51F17.6040907@themeyerfarm.com> <46A625E8.8090007@themeyerfarm.com> Message-ID: <20070724124115.083413b8@localhost.localdomain> On Tue, 24 Jul 2007 10:16:40 -0600 Phil Meyer wrote: > Sorry for the slow response. Had to finish Harry Potter. :) > > After verifying the yum is 3.2.2 all the way through, still no change. Can I hazard a guess that you're doing a media installation? (burned iso, or qemu booting from the iso, or NFS iso dir)? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pmeyer at themeyerfarm.com Tue Jul 24 21:29:18 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Tue, 24 Jul 2007 15:29:18 -0600 Subject: Fedora 7 kickstart problem with rebuilt Everything image In-Reply-To: <20070724124115.083413b8@localhost.localdomain> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> <1185210877.2408.22.camel@cutter> <46A5173F.5060904@themeyerfarm.com> <20070723171014.78573548@localhost.localdomain> <46A51F17.6040907@themeyerfarm.com> <46A625E8.8090007@themeyerfarm.com> <20070724124115.083413b8@localhost.localdomain> Message-ID: <46A66F2E.4050609@themeyerfarm.com> Jesse Keating wrote: > On Tue, 24 Jul 2007 10:16:40 -0600 > Phil Meyer wrote: > > >> Sorry for the slow response. Had to finish Harry Potter. :) >> >> After verifying the yum is 3.2.2 all the way through, still no change. >> > > Can I hazard a guess that you're doing a media installation? (burned > iso, or qemu booting from the iso, or NFS iso dir)? > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Yes. I found this work around: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246357#c26 Am testing that right now. From prarit at redhat.com Wed Jul 25 01:04:44 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Tue, 24 Jul 2007 21:04:44 -0400 Subject: [ANNOUNCE]: thetango SRPM dependency system v 2.0.0-0 Message-ID: <46A6A1AC.3030406@redhat.com> The problems associated with bootstrapping an OS on a new architecture have been around for a long time. The issues with doing so are numerous -- how to build, what order should the packages in the OS be built in, how to identify build dependencies, etc. Determining a build map, or build tree, would go a long way in decreasing the time to entirely rebuild or bootstrap an architecture. As a starting point, a brute force build method of repeatedly traversing the F7 SRPM list alphabetically was done. This resulted in approximately 2500 packages built over a week -- far short of the complete list of SRPMS. The frequency of successful builds slowed down dramatically after this number of SRPMS were built. The perl-* SRPMS are particularily nasty ... thetango attempts to resolve the build problem by taking a set of SRPMS and building build trees by evaluating the dependencies between the potential resulting binary RPMs, and determining the build tree for individual SRPMS. Version 2.0.0-0 is similar to version 1.0.0-0 except the code is now in python. Anon git repo: ssh://git.fedoraproject.org/git/hosted/thetango Prarit Bhargava prarit at redhat.com oftc.net: #ia64 From jgranado at redhat.com Wed Jul 25 16:28:35 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Wed, 25 Jul 2007 18:28:35 +0200 Subject: [patch][pungi] logging module Message-ID: <46A77A33.1030808@redhat.com> Hi all: Added some new elements to my previous patch (https://www.redhat.com/archives/fedora-buildsys-list/2007-June/msg00028.html) hope this is what pungi is looking for. Any comments greatly appreciated. Regards. PS: Just wanted to repost the patch so it isn't forgotten :) -- Joel Andres Granados -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From pmeyer at themeyerfarm.com Wed Jul 25 17:07:48 2007 From: pmeyer at themeyerfarm.com (Phil Meyer) Date: Wed, 25 Jul 2007 11:07:48 -0600 Subject: Fedora 7 kickstart problem: WORKAROUND In-Reply-To: <46A66F2E.4050609@themeyerfarm.com> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> <1185210877.2408.22.camel@cutter> <46A5173F.5060904@themeyerfarm.com> <20070723171014.78573548@localhost.localdomain> <46A51F17.6040907@themeyerfarm.com> <46A625E8.8090007@themeyerfarm.com> <20070724124115.083413b8@localhost.localdomain> <46A66F2E.4050609@themeyerfarm.com> Message-ID: <46A78364.3010003@themeyerfarm.com> Phil Meyer wrote: > Jesse Keating wrote: >> On Tue, 24 Jul 2007 10:16:40 -0600 >> Phil Meyer wrote: >> >> >>> Sorry for the slow response. Had to finish Harry Potter. :) >>> >>> After verifying the yum is 3.2.2 all the way through, still no change. >>> >> >> Can I hazard a guess that you're doing a media installation? (burned >> iso, or qemu booting from the iso, or NFS iso dir)? >> >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-buildsys-list mailing list >> Fedora-buildsys-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > Yes. I found this work around: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246357#c26 > > Am testing that right now. The workaround suggested in comment 26 works. Basically, in the yum configuration file you are using to build, tell it to ignore updates for yum and yum-updatesd. Like this: [updates] name=Fedora $releasever - $basearch - Released Updates ... exclude=yum yum-updatesd enabled=1 gpgcheck=1 It does not matter what version of yum is on the build server, just what version is built into the CD/DVD image. The new version of yum in updates-testing is 3.2.2 and does not resolve the issue. Further Observations: In yum-3.2.0 on the CD/DVD image, both headers directories are created. /tmp/cache/headers /tmp/cahe/anaconda.../headers The second of those is populated. Good Luck! From sergio at sergiomb.no-ip.org Thu Jul 26 23:48:40 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Fri, 27 Jul 2007 00:48:40 +0100 Subject: Fedora 7 kickstart problem: WORKAROUND In-Reply-To: <46A78364.3010003@themeyerfarm.com> References: <46A107C1.8020801@cohtech.com> <46A4DFEE.1080102@themeyerfarm.com> <1185210877.2408.22.camel@cutter> <46A5173F.5060904@themeyerfarm.com> <20070723171014.78573548@localhost.localdomain> <46A51F17.6040907@themeyerfarm.com> <46A625E8.8090007@themeyerfarm.com> <20070724124115.083413b8@localhost.localdomain> <46A66F2E.4050609@themeyerfarm.com> <46A78364.3010003@themeyerfarm.com> Message-ID: <1185493720.3418.6.camel@monteirov> On Wed, 2007-07-25 at 11:07 -0600, Phil Meyer wrote: > Phil Meyer wrote: > > Jesse Keating wrote: > >> On Tue, 24 Jul 2007 10:16:40 -0600 > >> Phil Meyer wrote: > >> > >> > >>> Sorry for the slow response. Had to finish Harry Potter. :) > >>> > >>> After verifying the yum is 3.2.2 all the way through, still no change. > >>> > >> > >> Can I hazard a guess that you're doing a media installation? (burned > >> iso, or qemu booting from the iso, or NFS iso dir)? > >> > >> > >> ------------------------------------------------------------------------ > >> > >> -- > >> Fedora-buildsys-list mailing list > >> Fedora-buildsys-list at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > > > Yes. I found this work around: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246357#c26 > > > > Am testing that right now. > The workaround suggested in comment 26 works. > > Basically, in the yum configuration file you are using to build, tell it > to ignore updates for yum and yum-updatesd. Like this: > > [updates] > name=Fedora $releasever - $basearch - Released Updates > ... > exclude=yum yum-updatesd > enabled=1 > gpgcheck=1 > > > It does not matter what version of yum is on the build server, just what > version is built into the CD/DVD image. > > The new version of yum in updates-testing is 3.2.2 and does not resolve > the issue. > > Further Observations: > > In yum-3.2.0 on the CD/DVD image, both headers directories are created. > /tmp/cache/headers > /tmp/cahe/anaconda.../headers > > The second of those is populated. > > Good Luck! Hi , we know the regression is between yum-3.2.0 and yum-3.2.1 , so shouldn't be difficult , find and revert what make stop population of headers . I simply don't had time to further investigation. Someone write in this malling list that could be fix (the missing headers) on anaconda what is the status of anaconda ? thanks, -- S?rgio M.B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From prarit at redhat.com Mon Jul 30 13:05:10 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Mon, 30 Jul 2007 09:05:10 -0400 Subject: IA64 mock build issues .... Message-ID: <46ADE206.9070301@redhat.com> I'm using mock to build F8T1. mock --debug -r fedora-devel-ia64-core-0.cfg /home/F8T1/mock-0.7.4-1.fc8.src.rpm DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/state init clean DEBUG: Executing timeout(0): /usr/sbin/mock-helper rm -rf /var/lib/mock/fedora-devel-ia64-core-0 DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0 DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/state DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/result prep This may take a while DEBUG: uid:500, gid:500 DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0 DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/state DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/result DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/var/lib/rpm DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/var/log DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/var/lock/rpm DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/dev DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/etc/rpm DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/tmp DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/var/tmp DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/etc/yum.repos.d DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/proc DEBUG: mounting proc in /var/lib/mock/fedora-devel-ia64-core-0/root/proc DEBUG: Executing timeout(0): /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-devel-ia64-core-0/root/proc DEBUG: mounted proc on /var/lib/mock/fedora-devel-ia64-core-0/root/proc DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/dev DEBUG: bind mounting /dev in /var/lib/mock/fedora-devel-ia64-core-0/root/dev DEBUG: Executing timeout(0): /usr/sbin/mock-helper mount --bind /dev /var/lib/mock/fedora-devel-ia64-core-0/root/dev DEBUG: bind mounted dev on /var/lib/mock/fedora-devel-ia64-core-0/root/dev DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts DEBUG: mounting devpts in /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts DEBUG: Executing timeout(0): /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts DEBUG: mounted pts on /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts DEBUG: Executing timeout(0): /usr/sbin/mock-helper chmod 2775 /var/lib/mock/fedora-devel-ia64-core-0/root/etc DEBUG: Executing timeout(0): /usr/sbin/mock-helper chown 500.101 /var/lib/mock/fedora-devel-ia64-core-0/root/etc DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/etc/yum DEBUG: yum: command /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-devel-ia64-core-0/root groupinstall buildsys-build DEBUG: Executing timeout(0): /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-devel-ia64-core-0/root groupinstall buildsys-build file:///prarit/isos/F7-test4/test4/ia64/os/repodata/repomd.xml: [Errno 5] OSError: [Errno 13] Permission denied: '/prarit/isos/F7-test4/test4/ia64/os/repodata/repomd.xml' Trying other mirror. Error: Cannot open/read repomd.xml file for repository: core file:///prarit/isos/F7-test4/test4/ia64/os/repodata/repomd.xml: [Errno 5] OSError: [Errno 13] Permission denied: '/prarit/isos/F7-test4/test4/ia64/os/repodata/repomd.xml' Trying other mirror. Error: Cannot open/read repomd.xml file for repository: core DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/dev DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-devel-ia64-core-0/root/dev DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/proc DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-devel-ia64-core-0/root/proc Error performing yum command: /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-devel-ia64-core-0/root groupinstall buildsys-build ending DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/proc DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-devel-ia64-core-0/root/proc umount: /var/lib/mock/fedora-devel-ia64-core-0/root/proc: not mounted DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/dev DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-devel-ia64-core-0/root/dev umount: /var/lib/mock/fedora-devel-ia64-core-0/root/dev: not mounted DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts mock-helper: error: /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts: No such file or directory mock-helper: error: /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts: No such file or directory Traceback (most recent call last): File "/usr/bin/mock", line 1145, in ? main() File "/usr/bin/mock", line 1142, in main do_rebuild(config_opts, srpms) File "/usr/bin/mock", line 1007, in do_rebuild my.close() File "/usr/bin/mock", line 415, in close self._umountall() File "/usr/bin/mock", line 513, in _umountall self._umount(self.mounts[key]) File "/usr/bin/mock", line 506, in _umount raise RootError, "could not umount %s error was: %s" % (path, output) __main__.RootError: could not umount /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts error was: mock-helper: error: /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts: No such file or directory The key error appears to be that I cannot access the repo I've specified: [core] name=bigpapi Fedora 8 Test1 baseurl=file:///prarit/isos/F7-test4/test4/ia64/os But, [build at altix3 mock]$ cd /prarit/isos/F7-test4/test4/ia64/os [build at altix3 os]$ cd repodata/ [build at altix3 repodata]$ ls comps-fc7.xml filelists.xml.gz other.xml.gz primary.xml.gz filelists.sqlite.bz2 other.sqlite.bz2 primary.sqlite.bz2 repomd.xml [build at altix3 repodata]$ cat repomd.xml 79e98769280cb1fe29ce89d049e908fa214f0b46 1185799588 2f47e52389f5cffc32aa65ceccc6cfa33994c184 d30710a1d8e687d13979af5ecb7bc1fa5a687658 1185799588 ef754d4f3c3d44a4d2bbbb8b9b6c5a51ee48cab4 28ebe101655b09817fab865c8b6d0baba3444130 1185799588 a010e1d33d20b8c8d41e24f9b5f07f72026ceb90 [build at altix3 repodata]$ ls -l repomd.xml -rwxrwxrwx 1 build build 951 Jul 30 08:46 repomd.xml Running the mock-helper command by hand yields: yum --installroot /var/lib/mock/fedora-devel-ia64-core-0/root groupinstall buildsys-build error: db4 error(13) from dbenv->open: Permission denied error: cannot open Packages index using db3 - Permission denied (13) error: cannot open Packages database in /var/lib/mock/fedora-devel-ia64-core-0/root/var/lib/rpm Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 85, in main base.getOptionsConfig(args) File "/usr/share/yum-cli/cli.py", line 199, in getOptionsConfig errorlevel=opts.errorlevel) File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 125, in doConfigSetup self.conf = config.readMainConfig(startupconf) File "/usr/lib/python2.4/site-packages/yum/config.py", line 597, in readMainConfig vars['releasever'] = _getsysver(startupconf.installroot, startupconf.distroverpkg) File "/usr/lib/python2.4/site-packages/yum/config.py", line 656, in _getsysver idx = ts.dbMatch('provides', distroverpkg) TypeError: rpmdb open failed .... I've never seen this error before, and previous instances of Fedora have "just worked" ... anyone have ideas on what I might have screwed up? P. From prarit at redhat.com Mon Jul 30 13:06:36 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Mon, 30 Jul 2007 09:06:36 -0400 Subject: IA64 mock build issues .... In-Reply-To: <46ADE206.9070301@redhat.com> References: <46ADE206.9070301@redhat.com> Message-ID: <46ADE25C.9000908@redhat.com> Prarit Bhargava wrote: > I'm using mock to build F8T1. Just for clarification, my mock config is: #!/usr/bin/python -tt import os config_opts['root'] = 'fedora-devel-ia64-core-0' config_opts['target_arch'] = 'ia64' config_opts['chroot_setup_cmd'] = 'groupinstall buildsys-build' config_opts['yum.conf'] = """ [main] cachedir=/var/cache/yum debuglevel=1 reposdir=/dev/null logfile=/var/log/yum.log retries=20 obsoletes=1 gpgcheck=0 assumeyes=1 # repos [core] name=Fedora 7 baseurl=file:///prarit/isos/F7-test4/test4/ia64/os [groups] name=local copy of buildgroups baseurl=file:///home/buildgroups [extras] name=Built F8T1 Binaries baseurl=file:///home/extras """ > > mock --debug -r fedora-devel-ia64-core-0.cfg > /home/F8T1/mock-0.7.4-1.fc8.src.rpm > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/state > init > clean > DEBUG: Executing timeout(0): /usr/sbin/mock-helper rm -rf > /var/lib/mock/fedora-devel-ia64-core-0 > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0 > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/state > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/result > prep > This may take a while > DEBUG: uid:500, gid:500 > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0 > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/state > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/result > DEBUG: ensuring dir > /var/lib/mock/fedora-devel-ia64-core-0/root/var/lib/rpm > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/var/log > DEBUG: ensuring dir > /var/lib/mock/fedora-devel-ia64-core-0/root/var/lock/rpm > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/dev > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/etc/rpm > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/tmp > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/var/tmp > DEBUG: ensuring dir > /var/lib/mock/fedora-devel-ia64-core-0/root/etc/yum.repos.d > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/proc > DEBUG: mounting proc in /var/lib/mock/fedora-devel-ia64-core-0/root/proc > DEBUG: Executing timeout(0): /usr/sbin/mock-helper mount -t proc proc > /var/lib/mock/fedora-devel-ia64-core-0/root/proc > DEBUG: mounted proc on /var/lib/mock/fedora-devel-ia64-core-0/root/proc > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/dev > DEBUG: bind mounting /dev in > /var/lib/mock/fedora-devel-ia64-core-0/root/dev > DEBUG: Executing timeout(0): /usr/sbin/mock-helper mount --bind /dev > /var/lib/mock/fedora-devel-ia64-core-0/root/dev > DEBUG: bind mounted dev on > /var/lib/mock/fedora-devel-ia64-core-0/root/dev > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts > DEBUG: mounting devpts in > /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts > DEBUG: Executing timeout(0): /usr/sbin/mock-helper mount -t devpts > devpts /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts > DEBUG: mounted pts on /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts > DEBUG: Executing timeout(0): /usr/sbin/mock-helper chmod 2775 > /var/lib/mock/fedora-devel-ia64-core-0/root/etc > DEBUG: Executing timeout(0): /usr/sbin/mock-helper chown 500.101 > /var/lib/mock/fedora-devel-ia64-core-0/root/etc > DEBUG: ensuring dir /var/lib/mock/fedora-devel-ia64-core-0/root/etc/yum > DEBUG: yum: command /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-devel-ia64-core-0/root groupinstall buildsys-build > DEBUG: Executing timeout(0): /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-devel-ia64-core-0/root groupinstall buildsys-build > file:///prarit/isos/F7-test4/test4/ia64/os/repodata/repomd.xml: [Errno > 5] OSError: [Errno 13] Permission denied: > '/prarit/isos/F7-test4/test4/ia64/os/repodata/repomd.xml' > Trying other mirror. > Error: Cannot open/read repomd.xml file for repository: core > file:///prarit/isos/F7-test4/test4/ia64/os/repodata/repomd.xml: [Errno > 5] OSError: [Errno 13] Permission denied: > '/prarit/isos/F7-test4/test4/ia64/os/repodata/repomd.xml' > Trying other mirror. > Error: Cannot open/read repomd.xml file for repository: core > > DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts > DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount > /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts > DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/dev > DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount > /var/lib/mock/fedora-devel-ia64-core-0/root/dev > DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/proc > DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount > /var/lib/mock/fedora-devel-ia64-core-0/root/proc > Error performing yum command: /usr/sbin/mock-helper yum --installroot > /var/lib/mock/fedora-devel-ia64-core-0/root groupinstall buildsys-build > ending > DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/proc > DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount > /var/lib/mock/fedora-devel-ia64-core-0/root/proc > umount: /var/lib/mock/fedora-devel-ia64-core-0/root/proc: not mounted > DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/dev > DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount > /var/lib/mock/fedora-devel-ia64-core-0/root/dev > umount: /var/lib/mock/fedora-devel-ia64-core-0/root/dev: not mounted > DEBUG: umounting /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts > DEBUG: Executing timeout(0): /usr/sbin/mock-helper umount > /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts > mock-helper: error: > /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts: No such file or > directory > mock-helper: error: > /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts: No such file or > directory > > Traceback (most recent call last): > File "/usr/bin/mock", line 1145, in ? > main() > File "/usr/bin/mock", line 1142, in main > do_rebuild(config_opts, srpms) > File "/usr/bin/mock", line 1007, in do_rebuild > my.close() > File "/usr/bin/mock", line 415, in close > self._umountall() > File "/usr/bin/mock", line 513, in _umountall > self._umount(self.mounts[key]) > File "/usr/bin/mock", line 506, in _umount > raise RootError, "could not umount %s error was: %s" % (path, output) > __main__.RootError: could not umount > /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts error was: > mock-helper: error: > /var/lib/mock/fedora-devel-ia64-core-0/root/dev/pts: No such file or > directory > > > The key error appears to be that I cannot access the repo I've specified: > > [core] > name=bigpapi Fedora 8 Test1 > baseurl=file:///prarit/isos/F7-test4/test4/ia64/os > > But, > > [build at altix3 mock]$ cd /prarit/isos/F7-test4/test4/ia64/os > [build at altix3 os]$ cd repodata/ > [build at altix3 repodata]$ ls > comps-fc7.xml filelists.xml.gz other.xml.gz > primary.xml.gz > filelists.sqlite.bz2 other.sqlite.bz2 primary.sqlite.bz2 repomd.xml > [build at altix3 repodata]$ cat repomd.xml > > > > > type="sha">79e98769280cb1fe29ce89d049e908fa214f0b46 > 1185799588 > type="sha">2f47e52389f5cffc32aa65ceccc6cfa33994c184 > > > > type="sha">d30710a1d8e687d13979af5ecb7bc1fa5a687658 > 1185799588 > type="sha">ef754d4f3c3d44a4d2bbbb8b9b6c5a51ee48cab4 > > > > type="sha">28ebe101655b09817fab865c8b6d0baba3444130 > 1185799588 > type="sha">a010e1d33d20b8c8d41e24f9b5f07f72026ceb90 > > > [build at altix3 repodata]$ ls -l repomd.xml > -rwxrwxrwx 1 build build 951 Jul 30 08:46 repomd.xml > > > > Running the mock-helper command by hand yields: > > yum --installroot /var/lib/mock/fedora-devel-ia64-core-0/root > groupinstall buildsys-build > error: db4 error(13) from dbenv->open: Permission denied > error: cannot open Packages index using db3 - Permission denied (13) > error: cannot open Packages database in > /var/lib/mock/fedora-devel-ia64-core-0/root/var/lib/rpm > Traceback (most recent call last): > File "/usr/bin/yum", line 29, in ? > yummain.main(sys.argv[1:]) > File "/usr/share/yum-cli/yummain.py", line 85, in main > base.getOptionsConfig(args) > File "/usr/share/yum-cli/cli.py", line 199, in getOptionsConfig > errorlevel=opts.errorlevel) > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 125, in > doConfigSetup > self.conf = config.readMainConfig(startupconf) > File "/usr/lib/python2.4/site-packages/yum/config.py", line 597, in > readMainConfig > vars['releasever'] = _getsysver(startupconf.installroot, > startupconf.distroverpkg) > File "/usr/lib/python2.4/site-packages/yum/config.py", line 656, in > _getsysver > idx = ts.dbMatch('provides', distroverpkg) > TypeError: rpmdb open failed > > > .... I've never seen this error before, and previous instances of > Fedora have "just worked" ... anyone have ideas on what I might have > screwed up? > > P. > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > From jkeating at redhat.com Mon Jul 30 13:27:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 30 Jul 2007 09:27:46 -0400 Subject: IA64 mock build issues .... In-Reply-To: <46ADE206.9070301@redhat.com> References: <46ADE206.9070301@redhat.com> Message-ID: <20070730092746.57b6a91e@localhost.localdomain> On Mon, 30 Jul 2007 09:05:10 -0400 Prarit Bhargava wrote: > .... I've never seen this error before, and previous instances of > Fedora have "just worked" ... anyone have ideas on what I might have > screwed up? Is selinux tripping you up? Is the mock user (or root) allowed to read the repodata files? Try completely cleaning out that buildroot (rm -rf after making sure that nothing is mounted there, verify with /proc/mounts). -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From prarit at redhat.com Mon Jul 30 13:52:27 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Mon, 30 Jul 2007 09:52:27 -0400 Subject: IA64 mock build issues .... In-Reply-To: <20070730092746.57b6a91e@localhost.localdomain> References: <46ADE206.9070301@redhat.com> <20070730092746.57b6a91e@localhost.localdomain> Message-ID: <46ADED1B.3080109@redhat.com> Jesse Keating wrote: > On Mon, 30 Jul 2007 09:05:10 -0400 > Prarit Bhargava wrote: > > >> .... I've never seen this error before, and previous instances of >> Fedora have "just worked" ... anyone have ideas on what I might have >> screwed up? >> > > > Is selinux tripping you up? Is the mock user (or root) allowed to read > the repodata files? > I feel an selinux rant coming on.... Thanks Jesse -- that was it. :) P. > Try completely cleaning out that buildroot (rm -rf after making sure > that nothing is mounted there, verify with /proc/mounts). > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From williams at redhat.com Mon Jul 30 14:31:47 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 30 Jul 2007 09:31:47 -0500 Subject: IA64 mock build issues .... In-Reply-To: <46ADED1B.3080109@redhat.com> References: <46ADE206.9070301@redhat.com> <20070730092746.57b6a91e@localhost.localdomain> <46ADED1B.3080109@redhat.com> Message-ID: <46ADF653.5050008@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Prarit Bhargava wrote: > > > Jesse Keating wrote: >> On Mon, 30 Jul 2007 09:05:10 -0400 >> Prarit Bhargava wrote: >> >> >>> .... I've never seen this error before, and previous instances of >>> Fedora have "just worked" ... anyone have ideas on what I might have >>> screwed up? >>> >> >> >> Is selinux tripping you up? Is the mock user (or root) allowed to read >> the repodata files? >> > > I feel an selinux rant coming on.... > > Thanks Jesse -- that was it. > > :) > If you are running with SELinux in enforcing mode, you can try: $ sudo /usr/sbin/setenforce 0 to turn it off, run your mock instance and then setenforce 1 to turn it back on. If it works, blame SELinux :). If it's not SELinux, I'm not sure what it could be. Are the permissions correct on the repo? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGrfZTHyuj/+TTEp0RAq1YAKCaF15GN//6kbGMFzzrQZLJHy/ewQCg2n/G 4LWvRWoi9yDqaP/cOvqNm2s= =Avbx -----END PGP SIGNATURE----- From prarit at redhat.com Mon Jul 30 14:40:58 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Mon, 30 Jul 2007 10:40:58 -0400 Subject: IA64 mock build issues .... In-Reply-To: <46ADF653.5050008@redhat.com> References: <46ADE206.9070301@redhat.com> <20070730092746.57b6a91e@localhost.localdomain> <46ADED1B.3080109@redhat.com> <46ADF653.5050008@redhat.com> Message-ID: <46ADF87A.3090102@redhat.com> Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Prarit Bhargava wrote: > >> Jesse Keating wrote: >> >>> On Mon, 30 Jul 2007 09:05:10 -0400 >>> Prarit Bhargava wrote: >>> >>> >>> >>>> .... I've never seen this error before, and previous instances of >>>> Fedora have "just worked" ... anyone have ideas on what I might have >>>> screwed up? >>>> >>>> >>> Is selinux tripping you up? Is the mock user (or root) allowed to read >>> the repodata files? >>> >>> >> I feel an selinux rant coming on.... >> >> Thanks Jesse -- that was it. >> >> :) >> >> > > If you are running with SELinux in enforcing mode, you can try: > > $ sudo /usr/sbin/setenforce 0 > > to turn it off, run your mock instance and then setenforce 1 to turn it back on. If > it works, blame SELinux :). > > Yeah -- that was what I did when Jesse pointed me at selinux. P. > From williams at redhat.com Mon Jul 30 14:47:55 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 30 Jul 2007 09:47:55 -0500 Subject: IA64 mock build issues .... In-Reply-To: <46ADF87A.3090102@redhat.com> References: <46ADE206.9070301@redhat.com> <20070730092746.57b6a91e@localhost.localdomain> <46ADED1B.3080109@redhat.com> <46ADF653.5050008@redhat.com> <46ADF87A.3090102@redhat.com> Message-ID: <46ADFA1B.6070803@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Prarit Bhargava wrote: > > > Clark Williams wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Prarit Bhargava wrote: >> >>> Jesse Keating wrote: >>> >>>> On Mon, 30 Jul 2007 09:05:10 -0400 >>>> Prarit Bhargava wrote: >>>> >>>> >>>> >>>>> .... I've never seen this error before, and previous instances of >>>>> Fedora have "just worked" ... anyone have ideas on what I might have >>>>> screwed up? >>>>> >>>> Is selinux tripping you up? Is the mock user (or root) allowed to read >>>> the repodata files? >>>> >>> I feel an selinux rant coming on.... >>> >>> Thanks Jesse -- that was it. >>> >>> :) >>> >>> >> >> If you are running with SELinux in enforcing mode, you can try: >> >> $ sudo /usr/sbin/setenforce 0 >> >> to turn it off, run your mock instance and then setenforce 1 to turn >> it back on. If >> it works, blame SELinux :). >> >> > > Yeah -- that was what I did when Jesse pointed me at selinux. > > P. I depend on Jesse for all my SELinux rant-needs. Did that fix it? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGrfobHyuj/+TTEp0RAoZPAKDc0TC6X6S6psWe3pAeUDapoPHH0wCfW0qr PmqVkHiMPdahM2M754dlahI= =SThg -----END PGP SIGNATURE-----