From jgranado at redhat.com Fri Apr 6 11:30:59 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Fri, 06 Apr 2007 13:30:59 +0200 Subject: Pungi configuration file. Message-ID: <46162F73.1070101@redhat.com> Hi list: Been poking at pungi a bit and have found out some strange behavior when I used the 0.3.0 version. When I executed the `pungi -c /etc/pungi/pungi.conf` I ran across some python trace back that referred to looking for a file. On further inspection I realized that the comments where not being considered as such for the pung.conf file. At http://docs.python.org/dev/lib/module-ConfigParser.html it states that the "#" and ";" can be used for comments on the beginning of the line. strangely the ";" character can be used as an inline comment but "#" can't. In name = value ; comment "comment" is a comment. But in name = value # comment "comment" is not a comment and name receives a value of "value # comment". Below is the traceback and a patch that changes all the "#" characters of the config file to ";" characters. I've tested the resulting config file and the values for each variable seem to be what I expect. comments appreciated. regards. TRACEBACK: Traceback (most recent call last): File "/usr/bin/pungi", line 182, in main() File "/usr/bin/pungi", line 100, in main mygather = pypungi.gather.Gather(config, pkglist) File "/usr/lib/python2.5/site-packages/pypungi/gather.py", line 56, in __init__ self.compsobj.add(self.config.get('default', 'comps')) File "/usr/lib/python2.5/site-packages/yum/comps.py", line 339, in add infile = open(srcfile, 'rt') IOError: [Errno 2] No such file or directory: '/etc/pungi/comps-fc7.xml # Used to define package groupings and default installs' DIFF: diff -ubBr pungi-0.3.0/config/pungi.conf pungi-0.3.0-JG/config/pungi.conf --- pungi-0.3.0/config/pungi.conf 2007-04-02 23:10:30.000000000 +0200 +++ pungi-0.3.0-JG/config/pungi.conf 2007-04-06 11:24:13.000000000 +0200 @@ -1,20 +1,20 @@ -# Pungi config file -# +; Pungi config file +; [default] -product_name = Fedora # The name used during install -product_path = Fedora # The directory where RPMS go -iso_basename = F # The first part of the iso file name -bugurl = http://bugzilla.redhat.com # Used for betanag -comps = /etc/pungi/comps-fc7.xml # Used to define package groupings and default installs -manifest = /etc/pungi/minimal-manifest # Used to determine what to bring in. Supports Kickstart syntax -yumconf = /etc/pungi/yum.conf.x86_64 # Used to determine where to gather packages from -destdir = /srv/pungi/Fedora # Top level compose directory, must be clean -cachedir = /srv/pungi/cache # Cache used for repeat runs -arch = x86_64 # What arch to compose (must be same arch as system) -version = development # Used both in install and part of the dest tree -flavor = Custom # Further define a given cut of the package set -discs = 1 # Number of discs needed to fit data. -#cdsize = 4608.0 Not used if disc count is 1 -getsource = Yes # Used to determine if we want source packages or not +product_name = Fedora ; The name used during install +product_path = Fedora ; The directory where RPMS go +iso_basename = F ; The first part of the iso file name +bugurl = http://bugzilla.redhat.com ; Used for betanag +comps = /etc/pungi/comps-fc7.xml ; Used to define package groupings and default installs +manifest = /etc/pungi/minimal-manifest ; Used to determine what to bring in. Supports Kickstart syntax +yumconf = /etc/pungi/yum.conf.x86_64 ; Used to determine where to gather packages from +destdir = /srv/pungi/Fedora ; Top level compose directory, must be clean +cachedir = /srv/pungi/cache ; Cache used for repeat runs +arch = x86_64 ; What arch to compose (must be same arch as system) +version = development ; Used both in install and part of the dest tree +flavor = Custom ; Further define a given cut of the package set +discs = 1 ; Number of discs needed to fit data. +;cdsize = 4608.0 Not used if disc count is 1 +getsource = Yes ; Used to determine if we want source packages or not From jkeating at redhat.com Fri Apr 6 11:57:58 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 6 Apr 2007 07:57:58 -0400 Subject: Pungi configuration file. In-Reply-To: <46162F73.1070101@redhat.com> References: <46162F73.1070101@redhat.com> Message-ID: <200704060757.58493.jkeating@redhat.com> On Friday 06 April 2007 07:30:59 Joel Andres Granados wrote: > Been poking at pungi a bit and have found out some strange behavior when > I used the 0.3.0 version. ?When I executed the `pungi -c > /etc/pungi/pungi.conf` I ran across some python trace back that referred > to looking for a file. ?On further inspection I realized that the > comments where not being considered as such for the pung.conf file. ?At > http://docs.python.org/dev/lib/module-ConfigParser.html it states that > the "#" and ";" can be used for comments on the beginning of the line. ? > strangely the ";" character can be used as an inline comment but "#" can't. Ooops. This is totally my fault. I didn't actually test the config file after I put the comments in right before making the release. Sorry about that :/ -- 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 tom.stage at dvos.dk Fri Apr 6 13:44:27 2007 From: tom.stage at dvos.dk (dvos) Date: Fri, 6 Apr 2007 15:44:27 +0200 Subject: FC6 Respin Install Error Message-ID: <002101c77851$b1d6d8c0$0a0aa8c0@naga01> Hi All I keep getting the following error when i try to use the respin of FC6 i just created with the latest Pungi for FC6 : Running anaconda, the FC6 System installer - please wait... Traceback (most recent call last): File "/usr/bin/anaconda", line 588, in ? import signal, traceback, string, isys, iutil, time File "/usr/lib/anaconda/isys.py", line 32, in ? import block ImportError: No module named block install exited abnormally [1/1] >From i can see from the build process there was no errors, so my big question is why do i keep getting this, or rather what am i missing ?? Cheers Tom Stage -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Fri Apr 6 16:22:25 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 06 Apr 2007 10:22:25 -0600 Subject: FC6 Respin Install Error In-Reply-To: <002101c77851$b1d6d8c0$0a0aa8c0@naga01> References: <002101c77851$b1d6d8c0$0a0aa8c0@naga01> Message-ID: <461673C1.8000006@cora.nwra.com> dvos wrote: > Hi All > > I keep getting the following error when i try to use the respin of FC6 i just created with the latest Pungi for FC6 : > > Running anaconda, the FC6 System installer - please wait... > Traceback (most recent call last): > File "/usr/bin/anaconda", line 588, in ? > import signal, traceback, string, isys, iutil, time > File "/usr/lib/anaconda/isys.py", line 32, in ? > import block > ImportError: No module named block > install exited abnormally [1/1] > >>From i can see from the build process there was no errors, so my big question is why do i keep getting this, or rather what am i missing ?? Is your FC6 box completely up to date? I've seen similar with updates to parted but no corresponding mkinitrd update. I believe everything is in sync at the moment though with current updates. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jgranado at redhat.com Thu Apr 12 16:06:19 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 12 Apr 2007 18:06:19 +0200 Subject: mkisofs VolumeID 32 character limitation Message-ID: <461E58FB.70909@redhat.com> Hi list: still pocking at pungi... Bug(I think): Pungi fails sometimes with a message that the mkisofs command failed. On further investigation of the pungi log it seems that the label given to the iso is to long. Looked at the mkisofs man page and found out that it only supports 32 characters in the iso label. In my configuration it had a label of 33 "Fedora development x86_64 rescue" Reason: There is a possibility for the cds iso images label to be Too long. In the end the user defines the label because it is constructed from the pungi.conf variables:Prodcut_name, arch, version... Possible fix: make sure to snip off the label before creating the isoimage. With the patch I'm trying to cut the id to an allowable size. Although I *do* cut the original name and I don't know what the effects are in the installations. I did run pungi and it ended with no errors. Comments: when the was shortened from the config file pungi executed successfully. comments greatly appreciated. The diff: @@ -356,8 +359,8 @@ extraargs.append(os.path.join('%s-disc%s' % (self.topdir, disc), "ppc/mac")) extraargs.append('-V') - extraargs.append('"%s %s %s Disc %s"' % (self.config.get('default', 'product_name'), - self.config.get('default', 'version'), self.config.get('default', 'arch'), disc)) + extraargs.append(('"%s %s %s Disc %s"' % (self.config.get('default', 'product_name'), + self.config.get('default', 'version'), self.config.get('default', 'arch'), disc))[:32]) extraargs.append('-o') extraargs.append(isofile) @@ -417,8 +422,8 @@ extraargs.append(os.path.join('%s-disc%s' % (self.topdir, disc), "ppc/mac")) extraargs.append('-V') - extraargs.append('"%s %s %s DVD"' % (self.config.get('default', 'product_name'), - self.config.get('default', 'version'), self.config.get('default', 'arch'))) + extraargs.append(('"%s %s %s DVD"' % (self.config.get('default', 'product_name'), + self.config.get('default', 'version'), self.config.get('default', 'arch')))[:32]) extraargs.append('-o') extraargs.append(isofile) From jkeating at redhat.com Thu Apr 12 16:07:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 12 Apr 2007 12:07:57 -0400 Subject: mkisofs VolumeID 32 character limitation In-Reply-To: <461E58FB.70909@redhat.com> References: <461E58FB.70909@redhat.com> Message-ID: <200704121207.57245.jkeating@redhat.com> On Thursday 12 April 2007 12:06:19 Joel Andres Granados wrote: > Possible fix: make sure to snip off the label before creating the > isoimage. ?With the patch I'm trying to cut the id to an allowable > size. ?Although I *do* cut the original name and I don't know what the > effects are in the installations. ?I did run pungi and it ended with no > errors. > Comments: when the was shortened from the config file pungi executed > successfully. ?comments greatly appreciated. I've been reluctant to fix this part of the code for a while. I'm not really sure what a good thing to do here is, truncation can be kind of ugly, but it should have no effect upon the install, it'll just effect what the desktop shows as the volume should you mount the CD. Perhaps this is a good enough solution for now, to prevent strange failures. I'll apply it soon, thanks. -- 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 Thu Apr 12 16:16:21 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 12 Apr 2007 18:16:21 +0200 Subject: mkisofs VolumeID 32 character limitation In-Reply-To: <200704121207.57245.jkeating@redhat.com> References: <461E58FB.70909@redhat.com> <200704121207.57245.jkeating@redhat.com> Message-ID: <461E5B55.9020707@redhat.com> Jesse Keating wrote: > On Thursday 12 April 2007 12:06:19 Joel Andres Granados wrote: > >> Possible fix: make sure to snip off the label before creating the >> isoimage. With the patch I'm trying to cut the id to an allowable >> size. Although I *do* cut the original name and I don't know what the >> effects are in the installations. I did run pungi and it ended with no >> errors. >> Comments: when the was shortened from the config file pungi executed >> successfully. comments greatly appreciated. >> > > I've been reluctant to fix this part of the code for a while. I'm not really > sure what a good thing to do here is, truncation can be kind of ugly, but it > should have no effect upon the install, it'll just effect what the desktop > shows as the volume should you mount the CD. > Thats what I thought as well, I'll do an install test with one of the truncated IDs and see if it works > Perhaps this is a good enough solution for now, to prevent strange failures. > I'll apply it soon, thanks. > np > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From jgranado at redhat.com Thu Apr 12 16:33:51 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 12 Apr 2007 18:33:51 +0200 Subject: configuration file not found Message-ID: <461E5F6F.1040200@redhat.com> Hi list: Its me again. Bug (I think): Pungi fails with a traceback when the config file is not correctly specified. It says It does not find the default section. Reason: Its a config parser error. The ConfigParser reads the existing files and ingnores the not existing ones. In any case if the file does not exist or if it exists but there is no "default" section, pungi will fail with a traceback. IMO catching the mistake before the traceback and telling the user what is happening is the right thing to do. I don't know about the message though. Its the best thing that my little mind could come up with :) The diff: @@ -37,7 +37,10 @@ config = SafeConfigParser() config.read(opts.config) - + if "default" not in config.sections(): + print ("Check that the file %s exists and that " + "has a 'default' section" % opts.config) + exit(0) if not config.has_option('default', 'flavor'): config.set('default', 'flavor', flavor) From jgranado at redhat.com Fri Apr 13 11:42:11 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Fri, 13 Apr 2007 13:42:11 +0200 Subject: mkisofs VolumeID 32 character limitation In-Reply-To: <461E58FB.70909@redhat.com> References: <461E58FB.70909@redhat.com> Message-ID: <461F6C93.1040304@redhat.com> Joel Andres Granados wrote: > Hi list: > still pocking at pungi... > Bug(I think): Pungi fails sometimes with a message that the mkisofs > command failed. On further investigation > of the pungi log it seems that the label given to the iso is to > long. Looked at the mkisofs > man page and found out that it only supports 32 characters in the > iso label. In my configuration > it had a label of 33 "Fedora development x86_64 rescue" > Reason: There is a possibility for the cds iso images label to be Too > long. In the end the user > defines the label because it is constructed from the pungi.conf > variables:Prodcut_name, arch, > version... > Possible fix: make sure to snip off the label before creating the > isoimage. With the patch I'm trying to cut the id to an allowable > size. Although I *do* cut the original name and I don't know what the > effects are in the installations. I did run pungi and it ended with > no errors. > Comments: when the was shortened from the config file pungi executed > successfully. comments greatly appreciated. > > > The diff: > @@ -356,8 +359,8 @@ > extraargs.append(os.path.join('%s-disc%s' % > (self.topdir, disc), "ppc/mac")) > > extraargs.append('-V') > - extraargs.append('"%s %s %s Disc %s"' % > (self.config.get('default', 'product_name'), > - self.config.get('default', 'version'), > self.config.get('default', 'arch'), disc)) > + extraargs.append(('"%s %s %s Disc %s"' % > (self.config.get('default', 'product_name'), > + self.config.get('default', 'version'), > self.config.get('default', 'arch'), disc))[:32]) > > extraargs.append('-o') > extraargs.append(isofile) > @@ -417,8 +422,8 @@ > extraargs.append(os.path.join('%s-disc%s' % > (self.topdir, disc), "ppc/mac")) > > extraargs.append('-V') > - extraargs.append('"%s %s %s DVD"' % > (self.config.get('default', 'product_name'), > - self.config.get('default', 'version'), > self.config.get('default', 'arch'))) > + extraargs.append(('"%s %s %s DVD"' % > (self.config.get('default', 'product_name'), > + self.config.get('default', 'version'), > self.config.get('default', 'arch')))[:32]) > > extraargs.append('-o') > extraargs.append(isofile) > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list I missed a part of the code that also creates a volume ID. Here is the revised diff: --- pungi.py-0.3.0 2007-04-13 11:08:07.000000000 +0200 +++ pungi.py-0.3.1-JG 2007-04-13 13:37:47.000000000 +0200 @@ -356,8 +356,8 @@ extraargs.append(os.path.join('%s-disc%s' % (self.topdir, disc), "ppc/mac")) extraargs.append('-V') - extraargs.append('"%s %s %s Disc %s"' % (self.config.get('default', 'product_name'), - self.config.get('default', 'version'), self.config.get('default', 'arch'), disc)) + extraargs.append(('"%s %s %s Disc %s"' % (self.config.get('default', 'product_name'), + self.config.get('default', 'version'), self.config.get('default', 'arch'), disc))[:32]) extraargs.append('-o') extraargs.append(isofile) @@ -417,8 +417,8 @@ extraargs.append(os.path.join('%s-disc%s' % (self.topdir, disc), "ppc/mac")) extraargs.append('-V') - extraargs.append('"%s %s %s DVD"' % (self.config.get('default', 'product_name'), - self.config.get('default', 'version'), self.config.get('default', 'arch'))) + extraargs.append(('"%s %s %s DVD"' % (self.config.get('default', 'product_name'), + self.config.get('default', 'version'), self.config.get('default', 'arch')))[:32]) extraargs.append('-o') extraargs.append(isofile) @@ -483,8 +483,8 @@ extraargs.append(os.path.join(self.workdir, "%s-rescueimage" % self.config.get('default', 'arch'), "ppc/mac")) extraargs.append('-V') - extraargs.append('"%s %s %s Rescue"' % (self.config.get('default', 'product_name'), - self.config.get('default', 'version'), self.config.get('default', 'arch'))) + extraargs.append(('"%s %s %s Rescue"' % (self.config.get('default', 'product_name'), + self.config.get('default', 'version'), self.config.get('default', 'arch')))[:32]) extraargs.append('-o') extraargs.append(isofile) From jgranado at redhat.com Fri Apr 13 13:34:44 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Fri, 13 Apr 2007 15:34:44 +0200 Subject: Pungis work directory. Message-ID: <461F86F4.5000903@redhat.com> I ran pungi once and created a fedora iso. When I ran it again with the same config file, and forgot to erase the previous work directory files, pungi shows a traceback telling me that some file already exists. I have two proposals for this situation. 1. create a timestamp directory inside the working directory for each pungi run. The problem with this approach is that the use is left with a bunch of directories that are named after whatever time.time() spit out (not very pretty). But alas it does away with the ugly traceback message. The diff for the first solution: --- pungi-0.3.0 2007-04-02 23:17:25.000000000 +0200 +++ pungi-0.3.1-JG 2007-04-13 14:27:22.000000000 +0200 @@ -18,6 +18,7 @@ import yum from ConfigParser import SafeConfigParser +from time import time def main(): # Set some default variables, can be overrided in config file @@ -76,7 +77,8 @@ if not opts.destdir == "*CONFFILE*": config.set('default', 'destdir', opts.destdir) - + config.set('default', 'destdir', os.path.join(config.get('default','destdir'), + str(int(time())))) destdir = config.get('default', 'destdir') if not os.path.exists(destdir): 2. Just tell the user to erase the things he/she has in the directory. The diff for the second solution: --- pungi-0.3.0 2007-04-13 15:03:26.000000000 +0200 +++ pungi-0.3.1-JG 2007-04-13 15:02:22.000000000 +0200 @@ -18,6 +18,7 @@ import yum from ConfigParser import SafeConfigParser +from os.path import isdir def main(): # Set some default variables, can be overrided in config file @@ -77,7 +78,7 @@ if not opts.destdir == "*CONFFILE*": config.set('default', 'destdir', opts.destdir) - destdir = config.get('default', 'destdir') + destdir = check_destdir(config.get('default', 'destdir')) if not os.path.exists(destdir): try: @@ -180,4 +181,10 @@ manifestfile.close() return pkglist + def check_destdir(workpath): + if isdir(workpath) and len(os.listdir(workpath)) > 0: + print >> sys.stderr, "Please erase all items from the directory %s before continuing." % workpath + exit(1) + return workpath + main() From Matt_Domsch at dell.com Mon Apr 16 12:50:15 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 16 Apr 2007 07:50:15 -0500 Subject: feature request: mock --timeout Message-ID: <20070416125015.GA21078@lists.us.dell.com> I'd like to make a feature request for mock: the ability for it to determine a job has taken too long and kill it. mock --timeout N (with N in minutes) is the UI I'm picturing. I've been doing these mass rebuilds for a while. Every so often we'll wind up with a package with the halting problem - it continues to run, or not, but it doesn't ever finish building either. Ever. Several days later, it's still going, but not making progress. Sure, some jobs, like the kernel, openoffice, glibc, etc. can take a good number of hours. But even those don't run for days. The latest culprits was a few perl modules that ran for >2 days with no end in sight. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From Axel.Thimm at ATrpms.net Mon Apr 16 13:25:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 16 Apr 2007 15:25:21 +0200 Subject: feature request: mock --timeout In-Reply-To: <20070416125015.GA21078@lists.us.dell.com> References: <20070416125015.GA21078@lists.us.dell.com> Message-ID: <20070416132521.GG19042@neu.nirvana> On Mon, Apr 16, 2007 at 07:50:15AM -0500, Matt Domsch wrote: > I'd like to make a feature request for mock: the ability for it to > determine a job has taken too long and kill it. mock --timeout N (with N > in minutes) is the UI I'm picturing. > > > I've been doing these mass rebuilds for a while. Every so often we'll > wind up with a package with the halting problem - it continues to run, > or not, but it doesn't ever finish building either. Ever. Several > days later, it's still going, but not making progress. > > Sure, some jobs, like the kernel, openoffice, glibc, etc. can take a > good number of hours. But even those don't run for days. The latest > culprits was a few perl modules that ran for >2 days with no end in > sight. Did you find out why it was not ending? Was it a package bug? > Thanks, > Matt > > -- 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 Matt_Domsch at dell.com Mon Apr 16 13:50:26 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 16 Apr 2007 08:50:26 -0500 Subject: feature request: mock --timeout In-Reply-To: <20070416132521.GG19042@neu.nirvana> References: <20070416125015.GA21078@lists.us.dell.com> <20070416132521.GG19042@neu.nirvana> Message-ID: <20070416135026.GC21078@lists.us.dell.com> On Mon, Apr 16, 2007 at 03:25:21PM +0200, Axel Thimm wrote: > On Mon, Apr 16, 2007 at 07:50:15AM -0500, Matt Domsch wrote: > > I'd like to make a feature request for mock: the ability for it to > > determine a job has taken too long and kill it. mock --timeout N (with N > > in minutes) is the UI I'm picturing. > > > > > > I've been doing these mass rebuilds for a while. Every so often we'll > > wind up with a package with the halting problem - it continues to run, > > or not, but it doesn't ever finish building either. Ever. Several > > days later, it's still going, but not making progress. > > > > Sure, some jobs, like the kernel, openoffice, glibc, etc. can take a > > good number of hours. But even those don't run for days. The latest > > culprits was a few perl modules that ran for >2 days with no end in > > sight. > > Did you find out why it was not ending? Was it a package bug? It's usually not a packaging bug, but a package bug. :-) The perl 'make test' routines are the usual culprits. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From williams at redhat.com Mon Apr 16 17:50:11 2007 From: williams at redhat.com (Clark Williams) Date: Mon, 16 Apr 2007 12:50:11 -0500 Subject: feature request: mock --timeout In-Reply-To: <20070416125015.GA21078@lists.us.dell.com> References: <20070416125015.GA21078@lists.us.dell.com> Message-ID: <4623B753.8030306@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Domsch wrote: > I'd like to make a feature request for mock: the ability for it to > determine a job has taken too long and kill it. mock --timeout N (with N > in minutes) is the UI I'm picturing. > > > I've been doing these mass rebuilds for a while. Every so often we'll > wind up with a package with the halting problem - it continues to run, > or not, but it doesn't ever finish building either. Ever. Several > days later, it's still going, but not making progress. > > Sure, some jobs, like the kernel, openoffice, glibc, etc. can take a > good number of hours. But even those don't run for days. The latest > culprits was a few perl modules that ran for >2 days with no end in > sight. > File an RFE BZ on it and I'll look at it. Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGI7dTHyuj/+TTEp0RAmyTAKC4M3Pl/pFlUHkuCeS8X48Rspt7JACfR+rt fksWcDbzd8jiTfpRY8g3epY= =4xb7 -----END PGP SIGNATURE----- From Michael_E_Brown at dell.com Mon Apr 16 18:07:52 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 16 Apr 2007 13:07:52 -0500 Subject: feature request: mock --timeout In-Reply-To: <4623B753.8030306@redhat.com> References: <20070416125015.GA21078@lists.us.dell.com> <4623B753.8030306@redhat.com> Message-ID: <20070416180751.GC8494@humbolt.us.dell.com> On Mon, Apr 16, 2007 at 12:50:11PM -0500, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Matt Domsch wrote: > > I'd like to make a feature request for mock: the ability for it to > > determine a job has taken too long and kill it. mock --timeout N (with N > > in minutes) is the UI I'm picturing. > > > > > > I've been doing these mass rebuilds for a while. Every so often we'll > > wind up with a package with the halting problem - it continues to run, > > or not, but it doesn't ever finish building either. Ever. Several > > days later, it's still going, but not making progress. > > > > Sure, some jobs, like the kernel, openoffice, glibc, etc. can take a > > good number of hours. But even those don't run for days. The latest > > culprits was a few perl modules that ran for >2 days with no end in > > sight. > > > > File an RFE BZ on it and I'll look at it. I have some python code from another project that does exactly this. I can drop it in. I'll send a patch for review. -- Michael From tibbs at math.uh.edu Mon Apr 16 19:00:59 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 16 Apr 2007 14:00:59 -0500 Subject: feature request: mock --timeout In-Reply-To: <20070416125015.GA21078@lists.us.dell.com> References: <20070416125015.GA21078@lists.us.dell.com> Message-ID: >>>>> "MD" == Matt Domsch writes: MD> The latest culprits was a few perl modules that ran for >2 days MD> with no end in sight. BTW, those are usually Module::Build-using modules which are running with unsatisfied build dependencies. They will stop and prompt for input when that happens. - J< From jgranado at redhat.com Tue Apr 17 08:51:58 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Apr 2007 10:51:58 +0200 Subject: pungi window frontend Message-ID: <46248AAE.5070202@redhat.com> Hi list: How about having a py-gtk based front end for pungi. It would basically do two things : 1) manage the pungi config files (yum.conf.x86_64, manifest, pungi.conf...) and 2) call pungi with the selected data. This would be another package separate from pungi that depends on pungi and yum and other X stuff. I think this would be really cool at least to create the package list. The user would simply choose from a list of packages. More or less like anaconda does it when you are installing the system. The user can also specify other yum repositories and locate comp.xml files.... The Idea is to keep it simple but helpful so even more people can make there own spins. comments? PD: It would be called "snakecharmer" or something. From kanarip at kanarip.com Tue Apr 17 09:15:41 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 17 Apr 2007 11:15:41 +0200 Subject: pungi window frontend In-Reply-To: <46248AAE.5070202@redhat.com> References: <46248AAE.5070202@redhat.com> Message-ID: <4624903D.7030201@kanarip.com> Joel Andres Granados wrote: > Hi list: > > How about having a py-gtk based front end for pungi. It would basically > do two things : 1) manage the pungi config files (yum.conf.x86_64, > manifest, pungi.conf...) and 2) call pungi with the selected data. > This would be another package separate from pungi that depends on pungi > and yum and other X stuff. I think this would be really cool at least > to create the package list. The user would simply choose from a list of > packages. More or less like anaconda does it when you are installing > the system. The user can also specify other yum repositories and > locate comp.xml files.... > The Idea is to keep it simple but helpful so even more people can make > there own spins. > > comments? > > PD: It would be called "snakecharmer" or something. > Hi Joel, Fedora Unity has this kind of tool in the making [1], it's beta release being scheduled May 1st (this year). If you feel like you have ideas, please take a look at our feature list [2] and comment on our mailing list [3]. Kind regards, Jeroen van Meeuwen -kanarip [1] Revisor Source Repository http://hosted.fedoraproject.org/projects/revisor [2] Revisor Feature List http://revisor.fedoraunity.org/development/feature-list [3] Revisor Mailing List http://lists.fedoraunity.org/mailman/listinfo/revisor-users From jgranado at redhat.com Tue Apr 17 09:37:15 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 17 Apr 2007 11:37:15 +0200 Subject: pungi window frontend In-Reply-To: <4624903D.7030201@kanarip.com> References: <46248AAE.5070202@redhat.com> <4624903D.7030201@kanarip.com> Message-ID: <4624954B.70805@redhat.com> Jeroen van Meeuwen wrote: > Joel Andres Granados wrote: >> Hi list: >> >> How about having a py-gtk based front end for pungi. It would >> basically do two things : 1) manage the pungi config files >> (yum.conf.x86_64, manifest, pungi.conf...) and 2) call pungi with the >> selected data. >> This would be another package separate from pungi that depends on >> pungi and yum and other X stuff. I think this would be really cool >> at least to create the package list. The user would simply choose >> from a list of packages. More or less like anaconda does it when you >> are installing the system. The user can also specify other yum >> repositories and locate comp.xml files.... >> The Idea is to keep it simple but helpful so even more people can >> make there own spins. >> >> comments? >> >> PD: It would be called "snakecharmer" or something. >> > > Hi Joel, > > Fedora Unity has this kind of tool in the making [1], it's beta > release being scheduled May 1st (this year). > > If you feel like you have ideas, please take a look at our feature > list [2] and comment on our mailing list [3]. > > Kind regards, > > Jeroen van Meeuwen > -kanarip > > [1] Revisor Source Repository > http://hosted.fedoraproject.org/projects/revisor > > [2] Revisor Feature List > http://revisor.fedoraunity.org/development/feature-list > > [3] Revisor Mailing List > http://lists.fedoraunity.org/mailman/listinfo/revisor-users > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Yep, thats more or less what I was looking for. THX. :) From Michael_E_Brown at dell.com Thu Apr 19 06:14:32 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 19 Apr 2007 01:14:32 -0500 Subject: feature request: mock --timeout In-Reply-To: <20070416180751.GC8494@humbolt.us.dell.com> References: <20070416125015.GA21078@lists.us.dell.com> <4623B753.8030306@redhat.com> <20070416180751.GC8494@humbolt.us.dell.com> Message-ID: <20070419061432.GA4039@humbolt.us.dell.com> On Mon, Apr 16, 2007 at 01:07:52PM -0500, Michael E Brown wrote: > On Mon, Apr 16, 2007 at 12:50:11PM -0500, Clark Williams wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Matt Domsch wrote: > > > I'd like to make a feature request for mock: the ability for it to > > > determine a job has taken too long and kill it. mock --timeout N (with N > > > in minutes) is the UI I'm picturing. > > > > > > > > > I've been doing these mass rebuilds for a while. Every so often we'll > > > wind up with a package with the halting problem - it continues to run, > > > or not, but it doesn't ever finish building either. Ever. Several > > > days later, it's still going, but not making progress. > > > > > > Sure, some jobs, like the kernel, openoffice, glibc, etc. can take a > > > good number of hours. But even those don't run for days. The latest > > > culprits was a few perl modules that ran for >2 days with no end in > > > sight. > > > > > > > File an RFE BZ on it and I'll look at it. > > I have some python code from another project that does exactly this. I > can drop it in. I'll send a patch for review. here is my previous code to call an external command with a timeout. I'll do a patch when I get a minute, but this should give a good idea: # helper class & functions for executeCommand() # User should handle this if they specify a timeout class commandTimeoutExpired(Exception): pass # the problem with os.system() is that the command that is run gets any # keyboard input and/or signals. This means that -C interrupts the # sub-program instead of the python program. This helper function fixes # that. # It also allows us to set up a maximum timeout before all children are # killed def executeCommand(cmd, timeout=0): class alarmExc(Exception): pass def alarmhandler(signum,stackframe): raise alarmExc("timeout expired") pid = os.fork() if pid: #parent rpid = ret = 0 oldhandler=signal.signal(signal.SIGALRM,alarmhandler) starttime = time.time() prevTimeout = signal.alarm(timeout) try: (rpid, ret) = os.waitpid(pid, 0) signal.alarm(0) signal.signal(signal.SIGALRM,oldhandler) if prevTimeout: passed = time.time() - starttime signal.alarm(math.ceil(prevTimeout - passed)) except alarmExc: os.kill(-pid, signal.SIGTERM) time.sleep(1) os.kill(-pid, signal.SIGKILL) (rpid, ret) = os.waitpid(pid, 0) signal.signal(signal.SIGALRM,oldhandler) if prevTimeout: passed = time.time() - starttime signal.alarm(max(math.ceil(prevTimeout - passed), 1)) raise commandTimeoutExpired( "Specified timeout of %s seconds expired before command finished. Command was: %s" % (timeout, cmd) ) # mask and return just return value return (ret & 0xFF00) >> 8 else: #child os.setpgrp() # become process group leader so that we can kill all our children ret = os.system(cmd) os._exit( (ret & 0xFF00) >> 8 ) From olivier.eb at gmail.com Fri Apr 20 21:27:53 2007 From: olivier.eb at gmail.com (Olivier D) Date: Fri, 20 Apr 2007 23:27:53 +0200 Subject: Error when compiling anaconda 11.1.1.3 Message-ID: <2bbc7e300704201427q6e25793aq4b007f49e4789914@mail.gmail.com> Hello, I'm trying to compile anaconda 11.1.1.3 : rpmbuild -ba anaconda.spec I'm getting the following errors about wireless.h : cc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wall -Werror -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DUSESELINUX=1 -I/usr/include/python2.4 -I.. -DHAVE_NFS -I/usr/include/glib- 2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libdhcp -I/usr/include/dhcp4client -I/usr/include/dhcp6client -fPIC -o wireless.lo wireless.c In file included from wireless.c:29: /usr/include/linux/wireless.h:636: error: expected specifier-qualifier-list before '__s32' /usr/include/linux/wireless.h:648: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token /usr/include/linux/wireless.h:663: error: expected specifier-qualifier-list before '__s32' /usr/include/linux/wireless.h:674: error: expected specifier-qualifier-list before '__u8' /usr/include/linux/wireless.h:690: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:703: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:730: error: expected specifier-qualifier-list before '__u8' /usr/include/linux/wireless.h:792: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:806: error: expected specifier-qualifier-list before '__u16' /usr/include/linux/wireless.h:820: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:828: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:837: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:849: error: expected specifier-qualifier-list before '__u16' /usr/include/linux/wireless.h:872: error: 'IFNAMSIZ' undeclared here (not in a function) /usr/include/linux/wireless.h:887: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:931: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:1032: error: expected specifier-qualifier-list before '__u32' /usr/include/linux/wireless.h:1050: error: expected specifier-qualifier-list before '__u16' cc1: warnings being treated as errors wireless.c: In function 'get_wreq': wireless.c:34: warning: value computed is not used wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' wireless.c: In function 'set_essid': wireless.c:81: error: 'struct iw_point' has no member named 'flags' wireless.c:82: error: 'struct iw_point' has no member named 'pointer' wireless.c:83: error: 'struct iw_point' has no member named 'length' wireless.c:85: error: 'struct iw_point' has no member named 'flags' wireless.c:86: error: 'struct iw_point' has no member named 'pointer' wireless.c:87: error: 'struct iw_point' has no member named 'length' wireless.c: In function 'get_essid': wireless.c:108: error: 'struct iw_point' has no member named 'pointer' wireless.c:109: error: 'struct iw_point' has no member named 'length' wireless.c:110: error: 'struct iw_point' has no member named 'flags' wireless.c:120: error: 'struct iw_point' has no member named 'pointer' wireless.c: In function 'set_wep_key': wireless.c:193: error: 'union iwreq_data' has no member named 'data' wireless.c:194: error: 'union iwreq_data' has no member named 'data' wireless.c:195: error: 'union iwreq_data' has no member named 'data' wireless.c:198: error: 'union iwreq_data' has no member named 'data' wireless.c:199: error: 'union iwreq_data' has no member named 'data' wireless.c:200: error: 'union iwreq_data' has no member named 'data' wireless.c: In function 'set_managed': wireless.c:221: error: 'union iwreq_data' has no member named 'mode' make[1]: *** [wireless.lo] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/anaconda-11.1.1.3/isys' make: *** [subdirs] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.41753 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.41753 (%build) infos about /usr/include/linux/wireless.h : /* * This file define a set of standard wireless extensions * * Version : 20 17.2.06 * * Authors : Jean Tourrilhes - HPL - * Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved. */ Any idea ? Olivier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen.janssen at gmail.com Sat Apr 21 07:41:11 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Sat, 21 Apr 2007 09:41:11 +0200 Subject: Error when compiling anaconda 11.1.1.3 In-Reply-To: <2bbc7e300704201427q6e25793aq4b007f49e4789914@mail.gmail.com> References: <2bbc7e300704201427q6e25793aq4b007f49e4789914@mail.gmail.com> Message-ID: Hello Olivier, This question might be more appropriate in the anaconda development mailinglist at http://www.redhat.com/mailman/listinfo/anaconda-devel-list Best regards, Jeroen Janssen On 4/20/07, Olivier D wrote: > Hello, > > I'm trying to compile anaconda 11.1.1.3 : > > rpmbuild -ba anaconda.spec > > I'm getting the following errors about wireless.h : > cc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic > -fasynchronous-unwind-tables -Wall -Werror -D_GNU_SOURCE=1 > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 > -DUSESELINUX=1 -I/usr/include/python2.4 -I.. -DHAVE_NFS -I/usr/include/glib- > 2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libdhcp > -I/usr/include/dhcp4client -I/usr/include/dhcp6client -fPIC -o wireless.lo > wireless.c > In file included from wireless.c:29: > /usr/include/linux/wireless.h:636: error: expected > specifier-qualifier-list before '__s32' > /usr/include/linux/wireless.h:648: error: expected ':', > ',', ';', '}' or '__attribute__' before '*' token > /usr/include/linux/wireless.h:663: error: expected > specifier-qualifier-list before '__s32' > /usr/include/linux/wireless.h:674: error: expected > specifier-qualifier-list before '__u8' > /usr/include/linux/wireless.h:690: error: expected > specifier-qualifier-list before '__u32' > /usr/include/linux/wireless.h:703: error: expected > specifier-qualifier-list before '__u32' > /usr/include/linux/wireless.h:730: error: expected > specifier-qualifier-list before '__u8' > /usr/include/linux/wireless.h:792: error: expected > specifier-qualifier-list before '__u32' > /usr/include/linux/wireless.h:806: error: expected > specifier-qualifier-list before '__u16' > /usr/include/linux/wireless.h:820: error: expected > specifier-qualifier-list before '__u32' > /usr/include/linux/wireless.h:828: error: expected > specifier-qualifier-list before '__u32' > /usr/include/linux/wireless.h:837: error: expected > specifier-qualifier-list before '__u32' > /usr/include/linux/wireless.h:849: error: expected > specifier-qualifier-list before '__u16' > /usr/include/linux/wireless.h:872: error: 'IFNAMSIZ' > undeclared here (not in a function) > /usr/include/linux/wireless.h:887: error: expected > specifier-qualifier-list before '__u32' > /usr/include/linux/wireless.h:931: error: expected > specifier-qualifier-list before '__u32' > /usr/include/linux/wireless.h:1032: error: expected > specifier-qualifier-list before '__u32' > /usr/include/linux/wireless.h:1050: error: expected > specifier-qualifier-list before '__u16' > cc1: warnings being treated as errors > wireless.c: In function 'get_wreq': > wireless.c:34: warning: value computed is not used > wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' > wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' > wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' > wireless.c:35: error: 'struct iwreq' has no member named 'ifr_name' > wireless.c: In function 'set_essid': > wireless.c:81: error: 'struct iw_point' has no member named 'flags' > wireless.c:82: error: 'struct iw_point' has no member named 'pointer' > wireless.c:83: error: 'struct iw_point' has no member named 'length' > wireless.c:85: error: 'struct iw_point' has no member named 'flags' > wireless.c:86: error: 'struct iw_point' has no member named 'pointer' > wireless.c:87: error: 'struct iw_point' has no member named 'length' > wireless.c: In function 'get_essid': > wireless.c:108: error: 'struct iw_point' has no member named 'pointer' > wireless.c:109: error: 'struct iw_point' has no member named 'length' > wireless.c:110: error: 'struct iw_point' has no member named 'flags' > wireless.c:120: error: 'struct iw_point' has no member named 'pointer' > wireless.c: In function 'set_wep_key': > wireless.c:193: error: 'union iwreq_data' has no member named 'data' > wireless.c:194: error: 'union iwreq_data' has no member named 'data' > wireless.c:195: error: 'union iwreq_data' has no member named 'data' > wireless.c:198: error: 'union iwreq_data' has no member named 'data' > wireless.c:199: error: 'union iwreq_data' has no member named 'data' > wireless.c:200: error: 'union iwreq_data' has no member named 'data' > wireless.c: In function 'set_managed': > wireless.c:221: error: 'union iwreq_data' has no member named 'mode' > make[1]: *** [wireless.lo] Error 1 > make[1]: Leaving directory > `/usr/src/redhat/BUILD/anaconda-11.1.1.3/isys' > make: *** [subdirs] Error 1 > error: Bad exit status from /var/tmp/rpm- tmp.41753 (%build) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.41753 (%build) > > infos about /usr/include/linux/wireless.h : > /* > * This file define a set of standard wireless extensions > * > * Version : 20 17.2.06 > * > * Authors : Jean Tourrilhes - HPL - > * Copyright (c) 1997-2006 Jean Tourrilhes, All Rights Reserved. > */ > > Any idea ? > > Olivier > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > From bugs.michael at gmx.net Sun Apr 22 11:22:33 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Sun, 22 Apr 2007 13:22:33 +0200 Subject: [PATCH] kojid - BuildNotificationTask traceback Message-ID: <20070422132233.634a6e69.bugs.michael@gmx.net> --- kojid~ 2007-04-09 19:23:38.000000000 +0200 +++ kojid 2007-04-22 13:18:09.000000000 +0200 @@ -2118,7 +2118,7 @@ if changelog: changelog = "Changelog:\r\n%s" % changelog - from_addr = self.from_addr + from_addr = options.from_addr to_addrs = ', '.join(recipients) subject = self.subject_templ % locals() message = self.message_templ % locals() From mikeb at redhat.com Mon Apr 23 14:01:19 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 23 Apr 2007 10:01:19 -0400 Subject: [PATCH] kojid - BuildNotificationTask traceback In-Reply-To: <20070422132233.634a6e69.bugs.michael@gmx.net> References: <20070422132233.634a6e69.bugs.michael@gmx.net> Message-ID: <1177336879.27702.0.camel@liffey.home> On Sun, 2007-04-22 at 13:22 +0200, Michael Schwendt wrote: > --- kojid~ 2007-04-09 19:23:38.000000000 +0200 > +++ kojid 2007-04-22 13:18:09.000000000 +0200 > @@ -2118,7 +2118,7 @@ > if changelog: > changelog = "Changelog:\r\n%s" % changelog > > - from_addr = self.from_addr > + from_addr = options.from_addr > to_addrs = ', '.join(recipients) > subject = self.subject_templ % locals() > message = self.message_templ % locals() Thanks, patch applied. From Michael_E_Brown at dell.com Tue Apr 24 05:51:10 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 24 Apr 2007 00:51:10 -0500 Subject: feature request: mock --timeout In-Reply-To: <20070419061432.GA4039@humbolt.us.dell.com> References: <20070416125015.GA21078@lists.us.dell.com> <4623B753.8030306@redhat.com> <20070416180751.GC8494@humbolt.us.dell.com> <20070419061432.GA4039@humbolt.us.dell.com> Message-ID: <20070424055110.GF29738@humbolt.us.dell.com> On Thu, Apr 19, 2007 at 01:14:32AM -0500, Michael E Brown wrote: > On Mon, Apr 16, 2007 at 01:07:52PM -0500, Michael E Brown wrote: > > On Mon, Apr 16, 2007 at 12:50:11PM -0500, Clark Williams wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Matt Domsch wrote: > > > > I'd like to make a feature request for mock: the ability for it to > > > > determine a job has taken too long and kill it. mock --timeout N (with N > > > > in minutes) is the UI I'm picturing. Here is my patch. I've tested: -- builds without timeout -- builds with timeout, succesful build -- builds with timeout, takes too long I accidentally developed the patch against 0.6.11. I think it is a one line change to port to 0.6.12. Will do tomorrow if needed. I dont think this changes any behaviour, but could somebody please check the logging? -- Michael Patch for implementing a hard timeout for 'rpmbuild' command, to avoid builds that hang. To activate: commandline: --rpmbuild_timeout=N config file: config_opts["rpmbuild_timeout"]=N where N==seconds to wait before timing out signed-off-by: Michael E Brown --- mock.py-ORIGINAL 2007-04-23 23:28:30.000000000 -0500 +++ mock.py-PATCHED 2007-04-24 00:46:56.000000000 -0500 @@ -26,9 +26,11 @@ import rpmUtils.transaction import rpm import glob +import popen2 import shutil import types import grp +import signal import stat import time from exceptions import Exception @@ -58,6 +60,8 @@ def __str__(self): return self.msg +class commandTimeoutExpired(Error): pass + class YumError(Error): def __init__(self, msg): Error.__init__(self, msg) @@ -379,11 +383,14 @@ self.state("build") - (retval, output) = self.do_chroot(cmd) - - if retval != 0: - error(output) - raise BuildError, "Error building package from %s, See build log" % srpmfn + try: + (retval, output) = self.do_chroot(cmd, timeout=self.config['rpmbuild_timeout']) + + if retval != 0: + error(output) + raise BuildError, "Error building package from %s, See build log" % srpmfn + except commandTimeoutExpired: + raise BuildError, "Error building package from %s. Exceeded rpmbuild_timeout which was set to %s seconds." % (srpmfn, self.config['rpmbuild_timeout']) bd_out = self.rootdir + self.builddir rpms = glob.glob(bd_out + '/RPMS/*.rpm') @@ -490,13 +497,15 @@ # poof, no more file if os.path.exists(mf): os.unlink(mf) - - def do(self, command): + def do(self, command, timeout=0): """execute given command outside of chroot""" + class alarmExc(Exception): pass + def alarmhandler(signum,stackframe): + raise alarmExc("timeout expired") retval = 0 - msg = "Executing %s" % command + msg = "Executing timeout(%s): %s" % (timeout, command) self.debug(msg) self.root_log(msg) @@ -507,25 +516,62 @@ if self.state() == "build": logfile = self._build_log - pipe = os.popen('{ ' + command + '; } 2>&1', 'r') - output = "" - for line in pipe: - logfile.write(line) - if self.config['debug']: - print line[:-1] - sys.stdout.flush() - logfile.flush() - output += line - status = pipe.close() - if status is None: - status = 0 - - if os.WIFEXITED(status): - retval = os.WEXITSTATUS(status) + output="" + (r,w) = os.pipe() + pid = os.fork() + if pid: #parent + rpid = ret = 0 + os.close(w) + oldhandler=signal.signal(signal.SIGALRM,alarmhandler) + starttime = time.time() + # timeout=0 means disable alarm signal. no timeout + signal.alarm(timeout) - return (retval, output) + try: + # read output from child + r = os.fdopen(r, "r") + for line in r: + logfile.write(line) + if self.config['debug']: + print line[:-1] + sys.stdout.flush() + logfile.flush() + output += line + + # close read handle, get child return status, etc + r.close() + (rpid, ret) = os.waitpid(pid, 0) + signal.alarm(0) + signal.signal(signal.SIGALRM,oldhandler) + + except alarmExc: + os.kill(-pid, signal.SIGTERM) + time.sleep(1) + os.kill(-pid, signal.SIGKILL) + (rpid, ret) = os.waitpid(pid, 0) + signal.signal(signal.SIGALRM,oldhandler) + raise commandTimeoutExpired( "Timeout(%s) exceeded for command: %s" % (timeout, command)) + + # mask and return just return value, plus child output + return ((ret & 0xFF00) >> 8, output) + + else: #child + os.close(r) + # become process group leader so that our parent + # can kill our children + os.setpgrp() + + child = popen2.Popen4(command) + child.tochild.close() + + w = os.fdopen(w, "w") + for line in child.fromchild: + w.write(line) + w.close() + os._exit( (retval & 0xFF00) >> 8 ) + - def do_chroot(self, command, fatal = False, exitcode=None): + def do_chroot(self, command, fatal = False, exitcode=None, timeout=0): """execute given command in root""" cmd = "" @@ -539,7 +585,7 @@ self.rootdir, self.config['runuser'], command) - (ret, output) = self.do(cmd) + (ret, output) = self.do(cmd, timeout=timeout) if (ret != 0) and fatal: self.close() if exitcode: @@ -778,6 +824,8 @@ default=False, help="Turn on build-root caching") parser.add_option("--rebuildcache", action ="store_true", dest="rebuild_cache", default=False, help="Force rebuild of build-root cache") + parser.add_option("--rpmbuild_timeout", action="store", dest="rpmbuild_timeout", type="int", + default=None, help="Fail build if rpmbuild takes longer than 'timeout' seconds ") return parser.parse_args() @@ -789,6 +837,7 @@ config_opts['rm'] = '/usr/sbin/mock-helper rm' config_opts['mknod'] = '/usr/sbin/mock-helper mknod' config_opts['yum'] = '/usr/sbin/mock-helper yum' + config_opts['rpmbuild_timeout'] = 0 config_opts['runuser'] = '/sbin/runuser' config_opts['chroot_setup_cmd'] = 'install buildsys-build' config_opts['chrootuser'] = 'mockbuild' @@ -845,6 +894,8 @@ config_opts['statedir'] = options.statedir if options.uniqueext: config_opts['unique-ext'] = options.uniqueext + if options.rpmbuild_timeout is not None: + config_opts['rpmbuild_timeout'] = options.rpmbuild_timeout def do_clean(config_opts, init=0): my = None @@ -972,7 +1023,7 @@ # cmdline options override config options set_config_opts_per_cmdline(config_opts, options) - + # do whatever we're here to do if args[0] == 'clean': # unset a --no-clean From Michael_E_Brown at dell.com Tue Apr 24 06:28:03 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 24 Apr 2007 01:28:03 -0500 Subject: feature request: mock --timeout In-Reply-To: <20070424055110.GF29738@humbolt.us.dell.com> References: <20070416125015.GA21078@lists.us.dell.com> <4623B753.8030306@redhat.com> <20070416180751.GC8494@humbolt.us.dell.com> <20070419061432.GA4039@humbolt.us.dell.com> <20070424055110.GF29738@humbolt.us.dell.com> Message-ID: <20070424062802.GH29738@humbolt.us.dell.com> On Tue, Apr 24, 2007 at 12:51:10AM -0500, Michael E Brown wrote: > On Thu, Apr 19, 2007 at 01:14:32AM -0500, Michael E Brown wrote: > > On Mon, Apr 16, 2007 at 01:07:52PM -0500, Michael E Brown wrote: > > > On Mon, Apr 16, 2007 at 12:50:11PM -0500, Clark Williams wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > Matt Domsch wrote: > > > > > I'd like to make a feature request for mock: the ability for it to > > > > > determine a job has taken too long and kill it. mock --timeout N (with N > > > > > in minutes) is the UI I'm picturing. > And here is the same patch against (what I hope is) the mock-0-6-branch. I ran: $ git-format-patch origin/mock-0-6-branch 0001-Patch-for-implementing-a-hard-timeout-for-rpmbuild.patch I dont have a machine set up to test this patch. it was a one line fix from the previous submission. I'm not too handy with git yet, so I hope this is right... :) -- Michael From bugs.michael at gmx.net Tue Apr 24 10:24:22 2007 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 24 Apr 2007 12:24:22 +0200 Subject: [PATCH] koji import-comps Message-ID: <20070424122422.2d9a8d5d.bugs.michael@gmx.net> > #for import-comps handler (currently disabled) > #from rhpl.comps import Comps I've ported this to FC6 yum.comps to make it work for the buildroot list, but it's only rudimentary, because I didn't find anything about the "biarchonly" attribute. The "basearchonly" attribute, on the other hand, is not evaluated by yum.comps. Plus, I couldn't find any groupreq and metapkg support in yum.comps either. -------------- next part -------------- A non-text attachment was scrubbed... Name: koji-1.1.patch Type: application/octet-stream Size: 4699 bytes Desc: not available URL: From Michael_E_Brown at dell.com Tue Apr 24 13:41:36 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 24 Apr 2007 08:41:36 -0500 Subject: feature request: mock --timeout In-Reply-To: <20070424062802.GH29738@humbolt.us.dell.com> References: <20070416125015.GA21078@lists.us.dell.com> <4623B753.8030306@redhat.com> <20070416180751.GC8494@humbolt.us.dell.com> <20070419061432.GA4039@humbolt.us.dell.com> <20070424055110.GF29738@humbolt.us.dell.com> <20070424062802.GH29738@humbolt.us.dell.com> Message-ID: <20070424134136.GI29738@humbolt.us.dell.com> On Tue, Apr 24, 2007 at 01:28:03AM -0500, Michael E Brown wrote: > On Tue, Apr 24, 2007 at 12:51:10AM -0500, Michael E Brown wrote: > > On Thu, Apr 19, 2007 at 01:14:32AM -0500, Michael E Brown wrote: > > > On Mon, Apr 16, 2007 at 01:07:52PM -0500, Michael E Brown wrote: > > > > On Mon, Apr 16, 2007 at 12:50:11PM -0500, Clark Williams wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > Hash: SHA1 > > > > > > > > > > Matt Domsch wrote: > > > > > > I'd like to make a feature request for mock: the ability for it to > > > > > > determine a job has taken too long and kill it. mock --timeout N (with N > > > > > > in minutes) is the UI I'm picturing. > > > > And here is the same patch against (what I hope is) the mock-0-6-branch. > > I ran: > $ git-format-patch origin/mock-0-6-branch > 0001-Patch-for-implementing-a-hard-timeout-for-rpmbuild.patch > > I dont have a machine set up to test this patch. it was a one line fix > from the previous submission. > > I'm not too handy with git yet, so I hope this is right... :) Obviously not too handy with mutt, either, as I forgot to add the patch. -- Michael From Michael_E_Brown at dell.com Tue Apr 24 13:55:42 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 24 Apr 2007 08:55:42 -0500 Subject: feature request: mock --timeout In-Reply-To: <20070424134136.GI29738@humbolt.us.dell.com> References: <20070416125015.GA21078@lists.us.dell.com> <4623B753.8030306@redhat.com> <20070416180751.GC8494@humbolt.us.dell.com> <20070419061432.GA4039@humbolt.us.dell.com> <20070424055110.GF29738@humbolt.us.dell.com> <20070424062802.GH29738@humbolt.us.dell.com> <20070424134136.GI29738@humbolt.us.dell.com> Message-ID: <20070424135542.GL29738@humbolt.us.dell.com> On Tue, Apr 24, 2007 at 08:41:36AM -0500, Michael E Brown wrote: > On Tue, Apr 24, 2007 at 01:28:03AM -0500, Michael E Brown wrote: > > On Tue, Apr 24, 2007 at 12:51:10AM -0500, Michael E Brown wrote: > > > On Thu, Apr 19, 2007 at 01:14:32AM -0500, Michael E Brown wrote: > > > > On Mon, Apr 16, 2007 at 01:07:52PM -0500, Michael E Brown wrote: > > > > > On Mon, Apr 16, 2007 at 12:50:11PM -0500, Clark Williams wrote: > > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > Hash: SHA1 > > > > > > > > > > > > Matt Domsch wrote: > > > > > > > I'd like to make a feature request for mock: the ability for it to > > > > > > > determine a job has taken too long and kill it. mock --timeout N (with N > > > > > > > in minutes) is the UI I'm picturing. > > > > > > > And here is the same patch against (what I hope is) the mock-0-6-branch. > > > > I ran: > > $ git-format-patch origin/mock-0-6-branch > > 0001-Patch-for-implementing-a-hard-timeout-for-rpmbuild.patch > > > > I dont have a machine set up to test this patch. it was a one line fix > > from the previous submission. > > > > I'm not too handy with git yet, so I hope this is right... :) > > Obviously not too handy with mutt, either, as I forgot to add the patch. Ok, It wasnt me that time, as I had the patch there, honest! Looks like something stripped it off :( Lets try again a different way. (sorry for all the extra traffic.) -- Michael > From 40724405ee7c38ec5a4ba7ccecb7ae0bc7889d65 Mon Sep 17 00:00:00 2001 > From: Michael E Brown > Date: Tue, 24 Apr 2007 01:00:05 -0500 > Subject: [PATCH] implementing a hard timeout for 'rpmbuild' command To activate: commandline: --rpmbuild_timeout=N config file: config_opts["rpmbuild_timeout"]=N where N==seconds to wait before timing out --- mock.py | 105 ++++++++++++++++++++++++++++++++++++++++++++++---------------- 1 files changed, 78 insertions(+), 27 deletions(-) diff --git a/mock.py b/mock.py index 497a95f..370f48c 100644 --- a/mock.py +++ b/mock.py @@ -26,9 +26,11 @@ except: import rpmUtils.transaction import rpm import glob +import popen2 import shutil import types import grp +import signal import stat import time from exceptions import Exception @@ -58,6 +60,8 @@ class Error(Exception): def __str__(self): return self.msg +class commandTimeoutExpired(Error): pass + class YumError(Error): def __init__(self, msg): Error.__init__(self, msg) @@ -378,11 +382,14 @@ class Root: self.state("build") - (retval, output) = self.do_chroot(cmd) - - if retval != 0: - error(output) - raise BuildError, "Error building package from %s, See build log" % srpmfn + try: + (retval, output) = self.do_chroot(cmd, timeout=self.config['rpmbuild_timeout']) + + if retval != 0: + error(output) + raise BuildError, "Error building package from %s, See build log" % srpmfn + except commandTimeoutExpired: + raise BuildError, "Error building package from %s. Exceeded rpmbuild_timeout which was set to %s seconds." % (srpmfn, self.config['rpmbuild_timeout']) bd_out = self.rootdir + self.builddir rpms = glob.glob(bd_out + '/RPMS/*.rpm') @@ -489,13 +496,15 @@ class Root: # poof, no more file if os.path.exists(mf): os.unlink(mf) - - def do(self, command): + def do(self, command, timeout=0): """execute given command outside of chroot""" + class alarmExc(Exception): pass + def alarmhandler(signum,stackframe): + raise alarmExc("timeout expired") retval = 0 - msg = "Executing %s" % command + msg = "Executing timeout(%s): %s" % (timeout, command) self.debug(msg) self.root_log(msg) @@ -506,25 +515,62 @@ class Root: if self.state() == "build": logfile = self._build_log - pipe = os.popen('{ ' + command + '; } 2>&1', 'r') - output = "" - for line in pipe: - logfile.write(line) - if self.config['debug'] or self.config['verbose']: - print line[:-1] - sys.stdout.flush() - logfile.flush() - output += line - status = pipe.close() - if status is None: - status = 0 - - if os.WIFEXITED(status): - retval = os.WEXITSTATUS(status) + output="" + (r,w) = os.pipe() + pid = os.fork() + if pid: #parent + rpid = ret = 0 + os.close(w) + oldhandler=signal.signal(signal.SIGALRM,alarmhandler) + starttime = time.time() + # timeout=0 means disable alarm signal. no timeout + signal.alarm(timeout) - return (retval, output) + try: + # read output from child + r = os.fdopen(r, "r") + for line in r: + logfile.write(line) + if self.config['debug'] or self.config['verbose']: + print line[:-1] + sys.stdout.flush() + logfile.flush() + output += line + + # close read handle, get child return status, etc + r.close() + (rpid, ret) = os.waitpid(pid, 0) + signal.alarm(0) + signal.signal(signal.SIGALRM,oldhandler) + + except alarmExc: + os.kill(-pid, signal.SIGTERM) + time.sleep(1) + os.kill(-pid, signal.SIGKILL) + (rpid, ret) = os.waitpid(pid, 0) + signal.signal(signal.SIGALRM,oldhandler) + raise commandTimeoutExpired( "Timeout(%s) exceeded for command: %s" % (timeout, command)) + + # mask and return just return value, plus child output + return ((ret & 0xFF00) >> 8, output) + + else: #child + os.close(r) + # become process group leader so that our parent + # can kill our children + os.setpgrp() + + child = popen2.Popen4(command) + child.tochild.close() + + w = os.fdopen(w, "w") + for line in child.fromchild: + w.write(line) + w.close() + os._exit( (retval & 0xFF00) >> 8 ) + - def do_chroot(self, command, fatal = False, exitcode=None): + def do_chroot(self, command, fatal = False, exitcode=None, timeout=0): """execute given command in root""" cmd = "" @@ -538,7 +584,7 @@ class Root: self.rootdir, self.config['runuser'], command) - (ret, output) = self.do(cmd) + (ret, output) = self.do(cmd, timeout=timeout) if (ret != 0) and fatal: self.close() if exitcode: @@ -785,6 +831,8 @@ def command_parse(): default=False, help="Turn on build-root caching") parser.add_option("--rebuildcache", action ="store_true", dest="rebuild_cache", default=False, help="Force rebuild of build-root cache") + parser.add_option("--rpmbuild_timeout", action="store", dest="rpmbuild_timeout", type="int", + default=None, help="Fail build if rpmbuild takes longer than 'timeout' seconds ") return parser.parse_args() @@ -796,6 +844,7 @@ def setup_default_config_opts(config_opts): config_opts['rm'] = '/usr/sbin/mock-helper rm' config_opts['mknod'] = '/usr/sbin/mock-helper mknod' config_opts['yum'] = '/usr/sbin/mock-helper yum' + config_opts['rpmbuild_timeout'] = 0 config_opts['runuser'] = '/sbin/runuser' config_opts['chroot_setup_cmd'] = 'install buildsys-build' config_opts['chrootuser'] = 'mockbuild' @@ -852,6 +901,8 @@ def set_config_opts_per_cmdline(config_opts, options): config_opts['statedir'] = options.statedir if options.uniqueext: config_opts['unique-ext'] = options.uniqueext + if options.rpmbuild_timeout is not None: + config_opts['rpmbuild_timeout'] = options.rpmbuild_timeout def do_clean(config_opts, init=0): my = None @@ -979,7 +1030,7 @@ def main(): # cmdline options override config options set_config_opts_per_cmdline(config_opts, options) - + # do whatever we're here to do if args[0] == 'clean': # unset a --no-clean -- 1.5.0.6 From jgranado at redhat.com Tue Apr 24 15:17:48 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 24 Apr 2007 17:17:48 +0200 Subject: Creation of fedora CD install. Message-ID: <462E1F9C.5060408@redhat.com> Hi list: I wanted to use the configuration values that express the amount of cds that pungi should generate and their related size. When I executed pungi with "discs =2" and "cdsize=700", pungi threw a traceback that had something to do with not finding a directory. On further investigation I found out that it was anaconda-runtime's splittree.py script that was causing the traceback. It created the full directory structure for the first cd but did not do the same for the cds after that. I noticed that the addition of one line "fixed" it : --- /tmp/splittree.py 2007-04-23 12:50:23.000000000 -0400 +++ splittree.py 2007-04-23 12:51:35.000000000 -0400 @@ -228,6 +227,7 @@ pass else: + os.makedirs("%s-disc%d/%s" % (self.dist_dir, i, self.product_path)) self.linkFiles(self.dist_dir, "%s-disc%d" %(self.dist_dir, i), self.common_files) self.createDiscInfo(i) I also noticed that this line was recently removed from the splittree.py file and really don't understand why, since the idea is for pungi to create cd and dvd. Will the process to create CD isos change?? In any case, the addition of this line to splittree.py fixes the traceback I was getting. Regards. From jkeating at redhat.com Tue Apr 24 19:08:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Apr 2007 15:08:15 -0400 Subject: Creation of fedora CD install. In-Reply-To: <462E1F9C.5060408@redhat.com> References: <462E1F9C.5060408@redhat.com> Message-ID: <200704241508.15640.jkeating@redhat.com> On Tuesday 24 April 2007 11:17:48 Joel Andres Granados wrote: > --- /tmp/splittree.py ? 2007-04-23 12:50:23.000000000 -0400 > +++ splittree.py ? ? ? ?2007-04-23 12:51:35.000000000 -0400 > @@ -228,6 +227,7 @@ > ? ? ? ? ? ? ? ? ? ? ? ? pass > > ? ? ? ? ? ? else: > + ? ? ? ? ? ? ? ?os.makedirs("%s-disc%d/%s" % (self.dist_dir, i, > self.product_path)) > ? ? ? ? ? ? ? ? self.linkFiles(self.dist_dir, "%s-disc%d" > %(self.dist_dir, i), self.common_files) > ? ? ? ? ? ? self.createDiscInfo(i) > ? ? ? ? ? > I also noticed that this line was recently removed from the splittree.py > file and really don't understand why, since the idea is for pungi to > create cd and dvd. ?Will the process to create CD isos change?? ?In any > case, the addition of this line to splittree.py fixes the traceback I > was getting. Hrm, good to know, but that actually needs to be sent to anaconda-devel-list at redhat.com and fixed there. -- 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 Wed Apr 25 09:24:58 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Wed, 25 Apr 2007 11:24:58 +0200 Subject: Creation of fedora CD install. In-Reply-To: <200704241508.15640.jkeating@redhat.com> References: <462E1F9C.5060408@redhat.com> <200704241508.15640.jkeating@redhat.com> Message-ID: <462F1E6A.4060306@redhat.com> Jesse Keating wrote: > On Tuesday 24 April 2007 11:17:48 Joel Andres Granados wrote: > >> --- /tmp/splittree.py 2007-04-23 12:50:23.000000000 -0400 >> +++ splittree.py 2007-04-23 12:51:35.000000000 -0400 >> @@ -228,6 +227,7 @@ >> pass >> >> else: >> + os.makedirs("%s-disc%d/%s" % (self.dist_dir, i, >> self.product_path)) >> self.linkFiles(self.dist_dir, "%s-disc%d" >> %(self.dist_dir, i), self.common_files) >> self.createDiscInfo(i) >> >> I also noticed that this line was recently removed from the splittree.py >> file and really don't understand why, since the idea is for pungi to >> create cd and dvd. Will the process to create CD isos change?? In any >> case, the addition of this line to splittree.py fixes the traceback I >> was getting. >> > > Hrm, good to know, but that actually needs to be sent to > anaconda-devel-list at redhat.com and fixed there. > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list Sorry, I didn't make myself clear enough. I checked the anaconda changelog and saw the following lines: 830 * textw/upgrade_text.py (UpgradeSwapWindow.__call__): Likewise. 831 832 * scripts/splittree.py: Don't generate RPMS/ dir (Jesse Keating) 833 834 * iw/progress_gui.py (InstallProgressWindow.setShowPercentage): I thought that the missing line was part of some new feature that was not yet complete. This is the reason why I posted it here, but I guess anaconda guys took away the whole line when they should have just erased the RPMS part of the command. I'll post in on the anaconda list and see what they have to say. Regards. From jkeating at redhat.com Thu Apr 26 05:25:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Apr 2007 01:25:41 -0400 Subject: Creation of fedora CD install. In-Reply-To: <462F1E6A.4060306@redhat.com> References: <462E1F9C.5060408@redhat.com> <200704241508.15640.jkeating@redhat.com> <462F1E6A.4060306@redhat.com> Message-ID: <200704260125.46005.jkeating@redhat.com> On Wednesday 25 April 2007 05:24:58 Joel Andres Granados wrote: > I thought that the missing line was part of some new feature that was > not yet complete. ?This is the reason why I posted it here, but I guess > anaconda guys took away the whole line when they should have just erased > the RPMS part of the command. ?I'll post in on the anaconda list and see > what they have to say. > Regards. Oh dear, that may have been _me_ that broke it with an improper patch. Whoops. I'll follow up with anaconda folks and fix that up hopefully tomorrow. -- 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 Thu Apr 26 08:17:40 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 26 Apr 2007 10:17:40 +0200 Subject: Creation of fedora CD install. In-Reply-To: <200704260125.46005.jkeating@redhat.com> References: <462E1F9C.5060408@redhat.com> <200704241508.15640.jkeating@redhat.com> <462F1E6A.4060306@redhat.com> <200704260125.46005.jkeating@redhat.com> Message-ID: <46306024.70208@redhat.com> Jesse Keating wrote: > On Wednesday 25 April 2007 05:24:58 Joel Andres Granados wrote: > >> I thought that the missing line was part of some new feature that was >> not yet complete. This is the reason why I posted it here, but I guess >> anaconda guys took away the whole line when they should have just erased >> the RPMS part of the command. I'll post in on the anaconda list and see >> what they have to say. >> Regards. >> > > Oh dear, that may have been _me_ that broke it with an improper patch. > Whoops. I'll follow up with anaconda folks and fix that up hopefully > tomorrow. > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list For Reference: Bug #233384 From jgranado at redhat.com Thu Apr 26 15:05:12 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Thu, 26 Apr 2007 17:05:12 +0200 Subject: Creation of fedora CD install. In-Reply-To: <200704260125.46005.jkeating@redhat.com> References: <462E1F9C.5060408@redhat.com> <200704241508.15640.jkeating@redhat.com> <462F1E6A.4060306@redhat.com> <200704260125.46005.jkeating@redhat.com> Message-ID: <4630BFA8.2090503@redhat.com> Jesse Keating wrote: > On Wednesday 25 April 2007 05:24:58 Joel Andres Granados wrote: > >> I thought that the missing line was part of some new feature that was >> not yet complete. This is the reason why I posted it here, but I guess >> anaconda guys took away the whole line when they should have just erased >> the RPMS part of the command. I'll post in on the anaconda list and see >> what they have to say. >> Regards. >> > > Oh dear, that may have been _me_ that broke it with an improper patch. > Whoops. I'll follow up with anaconda folks and fix that up hopefully > tomorrow. > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list The bug has been patched by Jeremy. Regards