From wdierkes at 5dollarwhitebox.org Thu Oct 4 00:34:32 2007 From: wdierkes at 5dollarwhitebox.org (BJ Dierkes) Date: Wed, 3 Oct 2007 19:34:32 -0500 Subject: mock improvements In-Reply-To: <20070926101906.GA6835@jasmine.xos.nl> References: <20070925191111.GB2414@humbolt.us.dell.com> <20070926101906.GA6835@jasmine.xos.nl> Message-ID: <0D9D8376-79C2-47F3-B986-1704DEE0F556@5dollarwhitebox.org> > >> 1) more reliable mount/umount >> several people have pointed out instances where mock exits leaving >> mounts behind (specifically /dev), and the next invokation of mock >> ends up 'rm -rf' the host machine's /dev. Bad.... > > And /dev/pts and /proc. > Yes... this is one should be pushed way up in priority if possible... building any apps around mock will lead to many a developer wondering what just happened to their '/dev'... as is the case right now for me.... atleast 10 times in the last few hours. Thanks. From williams at redhat.com Thu Oct 4 16:09:13 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 04 Oct 2007 11:09:13 -0500 Subject: mock improvements In-Reply-To: <0D9D8376-79C2-47F3-B986-1704DEE0F556@5dollarwhitebox.org> References: <20070925191111.GB2414@humbolt.us.dell.com> <20070926101906.GA6835@jasmine.xos.nl> <0D9D8376-79C2-47F3-B986-1704DEE0F556@5dollarwhitebox.org> Message-ID: <47051029.1080801@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 BJ Dierkes wrote: >> >>> 1) more reliable mount/umount >>> several people have pointed out instances where mock exits leaving >>> mounts behind (specifically /dev), and the next invokation of mock >>> ends up 'rm -rf' the host machine's /dev. Bad.... >> >> And /dev/pts and /proc. >> > > Yes... this is one should be pushed way up in priority if possible... > building any apps around mock will lead to many a developer wondering > what just happened to their '/dev'... as is the case right now for > me.... atleast 10 times in the last few hours. > > Thanks. I'm looking at BZ 250985 now. I'd like to add code to do two things: 1. Find where we're exiting without umounting 2. Add some paranoia code in the startup logic to not screw up if #1 fails (like is happening now). To that end, would you run one of your failure cases with mock --debug and send me the output? Thanks, Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHBRApHyuj/+TTEp0RAqW5AJ9M0tEIi7wMRSxMPTOvGvLr4nwr0ACbB3Qm bdfOov8fGh0optB3JdQ3hwA= =FiXR -----END PGP SIGNATURE----- From williams at redhat.com Thu Oct 4 17:40:39 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 04 Oct 2007 12:40:39 -0500 Subject: Patch for BZ 303791? Message-ID: <47052597.9000000@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Below is a patch for the $SUBJECT bz. I originally just changed the case of the search string to match what 'yum resolvedep' was printing, but then I thought about whether folks might not have the changed version of yum... After I took an aspirin to deal with the dependency combinatorial explosion headache, I looked at the code again. I didn't really want to pull in the re package just for this one case, so I resorted to doing a case-insensitive match, which I *hope* will deal with most cases. What do you guys think? Clark diff --git a/mock.py b/mock.py index 54b8f8c..35c3592 100644 - --- a/mock.py +++ b/mock.py @@ -355,9 +355,11 @@ class Root: # pass build reqs (as strings) to installer if arg_string != "": (retval, output) = self.yum('resolvedep %s' % arg_string) + searchstr = 'no package found for' for line in output.split('\n'): - - if line.find('No Package found for') != -1: - - errorpkg = line.replace('No Package found for', '') + idx = line.lower().find(searchstr) + if idx != -1: + errorpkg = line[idx+len(searchstr):] error(output) raise BuildError, "Cannot find build req %s. Exiting." % errorpkg # nothing made us exit, so we continue -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD4DBQFHBSWXHyuj/+TTEp0RAtzCAJYy31hDn5zsGedHFM/LcWnrBbR5AKDnO10u ou94vu8Kf369iaF/VKiE7w== =iG5Y -----END PGP SIGNATURE----- From skvidal at fedoraproject.org Thu Oct 4 17:42:09 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 04 Oct 2007 13:42:09 -0400 Subject: Patch for BZ 303791? In-Reply-To: <47052597.9000000@redhat.com> References: <47052597.9000000@redhat.com> Message-ID: <1191519729.6741.103.camel@cutter> On Thu, 2007-10-04 at 12:40 -0500, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Below is a patch for the $SUBJECT bz. I originally just changed the case of the > search string to match what 'yum resolvedep' was printing, but then I thought about > whether folks might not have the changed version of yum... > > After I took an aspirin to deal with the dependency combinatorial explosion headache, > I looked at the code again. I didn't really want to pull in the re package just for > this one case, so I resorted to doing a case-insensitive match, which I *hope* will > deal with most cases. > > What do you guys think? > > Clark > > diff --git a/mock.py b/mock.py > index 54b8f8c..35c3592 100644 > - --- a/mock.py > +++ b/mock.py > @@ -355,9 +355,11 @@ class Root: > # pass build reqs (as strings) to installer > if arg_string != "": > (retval, output) = self.yum('resolvedep %s' % arg_string) > + searchstr = 'no package found for' > for line in output.split('\n'): > - - if line.find('No Package found for') != -1: > - - errorpkg = line.replace('No Package found for', '') > + idx = line.lower().find(searchstr) > + if idx != -1: > + errorpkg = line[idx+len(searchstr):] > error(output) > raise BuildError, "Cannot find build req %s. Exiting." % errorpkg > # nothing made us exit, so we continue Is it time to start writing simple, custom yum-utils just for mock? So it can call them as a program but also so mock can more rigidly control its output? -sv From williams at redhat.com Thu Oct 4 18:00:41 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 04 Oct 2007 13:00:41 -0500 Subject: Patch for BZ 303791? In-Reply-To: <1191519729.6741.103.camel@cutter> References: <47052597.9000000@redhat.com> <1191519729.6741.103.camel@cutter> Message-ID: <47052A49.3050101@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: > On Thu, 2007-10-04 at 12:40 -0500, Clark Williams wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Below is a patch for the $SUBJECT bz. I originally just changed the case of the >> search string to match what 'yum resolvedep' was printing, but then I thought about >> whether folks might not have the changed version of yum... >> >> After I took an aspirin to deal with the dependency combinatorial explosion headache, >> I looked at the code again. I didn't really want to pull in the re package just for >> this one case, so I resorted to doing a case-insensitive match, which I *hope* will >> deal with most cases. >> >> What do you guys think? >> >> Clark >> >> diff --git a/mock.py b/mock.py >> index 54b8f8c..35c3592 100644 >> - --- a/mock.py >> +++ b/mock.py >> @@ -355,9 +355,11 @@ class Root: >> # pass build reqs (as strings) to installer >> if arg_string != "": >> (retval, output) = self.yum('resolvedep %s' % arg_string) >> + searchstr = 'no package found for' >> for line in output.split('\n'): >> - - if line.find('No Package found for') != -1: >> - - errorpkg = line.replace('No Package found for', '') >> + idx = line.lower().find(searchstr) >> + if idx != -1: >> + errorpkg = line[idx+len(searchstr):] >> error(output) >> raise BuildError, "Cannot find build req %s. Exiting." % errorpkg >> # nothing made us exit, so we continue > > Is it time to start writing simple, custom yum-utils just for mock? So > it can call them as a program but also so mock can more rigidly control > its output? > Maybe.... Are you talking about stuff that is a part of mock, a part of yum, or a separate package altogether? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHBSpJHyuj/+TTEp0RAmAJAKCTOzowhq8DMT71CrfRLON79c35HQCfYD1k S2qn/04z/xhtqRSgggvMd0o= =za13 -----END PGP SIGNATURE----- From skvidal at fedoraproject.org Thu Oct 4 18:06:12 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 04 Oct 2007 14:06:12 -0400 Subject: Patch for BZ 303791? In-Reply-To: <47052A49.3050101@redhat.com> References: <47052597.9000000@redhat.com> <1191519729.6741.103.camel@cutter> <47052A49.3050101@redhat.com> Message-ID: <1191521172.6741.105.camel@cutter> On Thu, 2007-10-04 at 13:00 -0500, Clark Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > seth vidal wrote: > > On Thu, 2007-10-04 at 12:40 -0500, Clark Williams wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Below is a patch for the $SUBJECT bz. I originally just changed the case of the > >> search string to match what 'yum resolvedep' was printing, but then I thought about > >> whether folks might not have the changed version of yum... > >> > >> After I took an aspirin to deal with the dependency combinatorial explosion headache, > >> I looked at the code again. I didn't really want to pull in the re package just for > >> this one case, so I resorted to doing a case-insensitive match, which I *hope* will > >> deal with most cases. > >> > >> What do you guys think? > >> > >> Clark > >> > >> diff --git a/mock.py b/mock.py > >> index 54b8f8c..35c3592 100644 > >> - --- a/mock.py > >> +++ b/mock.py > >> @@ -355,9 +355,11 @@ class Root: > >> # pass build reqs (as strings) to installer > >> if arg_string != "": > >> (retval, output) = self.yum('resolvedep %s' % arg_string) > >> + searchstr = 'no package found for' > >> for line in output.split('\n'): > >> - - if line.find('No Package found for') != -1: > >> - - errorpkg = line.replace('No Package found for', '') > >> + idx = line.lower().find(searchstr) > >> + if idx != -1: > >> + errorpkg = line[idx+len(searchstr):] > >> error(output) > >> raise BuildError, "Cannot find build req %s. Exiting." % errorpkg > >> # nothing made us exit, so we continue > > > > Is it time to start writing simple, custom yum-utils just for mock? So > > it can call them as a program but also so mock can more rigidly control > > its output? > > > > Maybe.... > > Are you talking about stuff that is a part of mock, a part of yum, or a separate > package altogether? part of mock. -sv From Michael_E_Brown at dell.com Thu Oct 4 18:20:14 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Thu, 4 Oct 2007 13:20:14 -0500 Subject: Patch for BZ 303791? In-Reply-To: <1191521172.6741.105.camel@cutter> References: <47052597.9000000@redhat.com> <1191519729.6741.103.camel@cutter> <47052A49.3050101@redhat.com> <1191521172.6741.105.camel@cutter> Message-ID: <20071004182014.GA23448@humbolt.us.dell.com> On Thu, Oct 04, 2007 at 02:06:12PM -0400, seth vidal wrote: > > On Thu, 2007-10-04 at 13:00 -0500, Clark Williams wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > seth vidal wrote: > > > On Thu, 2007-10-04 at 12:40 -0500, Clark Williams wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA1 > > >> > > > Is it time to start writing simple, custom yum-utils just for mock? So > > > it can call them as a program but also so mock can more rigidly control > > > its output? > > > > > > > Maybe.... > > > > Are you talking about stuff that is a part of mock, a part of yum, or a separate > > package altogether? > > part of mock. I agree. More of a long-term thing, though. Here is my list of stuff we need to work on: 1) "inside-out" setuid scheme (part of an overall revamp on how we see security for mock running. We currently dont have a coherent strategy or vision). 2) use yum-utils rather than calling cmdline 3) better caching (downloaded yum stuff, chroot cache) 4) more reliable mount/umount 5) Speedup options: ccache/distcc -- Michael From williams at redhat.com Thu Oct 4 18:24:47 2007 From: williams at redhat.com (Clark Williams) Date: Thu, 04 Oct 2007 13:24:47 -0500 Subject: Patch for BZ 303791? In-Reply-To: <20071004182014.GA23448@humbolt.us.dell.com> References: <47052597.9000000@redhat.com> <1191519729.6741.103.camel@cutter> <47052A49.3050101@redhat.com> <1191521172.6741.105.camel@cutter> <20071004182014.GA23448@humbolt.us.dell.com> Message-ID: <47052FEF.5050607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael E Brown wrote: > On Thu, Oct 04, 2007 at 02:06:12PM -0400, seth vidal wrote: >> On Thu, 2007-10-04 at 13:00 -0500, Clark Williams wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> seth vidal wrote: >>>> On Thu, 2007-10-04 at 12:40 -0500, Clark Williams wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>> Is it time to start writing simple, custom yum-utils just for mock? So >>>> it can call them as a program but also so mock can more rigidly control >>>> its output? >>>> >>> Maybe.... >>> >>> Are you talking about stuff that is a part of mock, a part of yum, or a separate >>> package altogether? >> part of mock. > > I agree. More of a long-term thing, though. Here is my list of stuff we > need to work on: > > 1) "inside-out" setuid scheme (part of an overall revamp on how we see > security for mock running. We currently dont have a coherent strategy or > vision). > 2) use yum-utils rather than calling cmdline > 3) better caching (downloaded yum stuff, chroot cache) > 4) more reliable mount/umount > 5) Speedup options: ccache/distcc All good. I agree completely. Now tell me if my short-term fix for $SUBJECT is acceptable :) Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHBS/vHyuj/+TTEp0RAqVWAJ4lK0QwHJ6Dda8VXQJD+q9ITga5hQCgkWP2 OXs1pxSeTnM6lmoEiv3S2Ho= =l1bJ -----END PGP SIGNATURE----- From wdierkes at 5dollarwhitebox.org Thu Oct 4 20:20:54 2007 From: wdierkes at 5dollarwhitebox.org (BJ Dierkes) Date: Thu, 4 Oct 2007 15:20:54 -0500 Subject: mock improvements In-Reply-To: <47051029.1080801@redhat.com> References: <20070925191111.GB2414@humbolt.us.dell.com> <20070926101906.GA6835@jasmine.xos.nl> <0D9D8376-79C2-47F3-B986-1704DEE0F556@5dollarwhitebox.org> <47051029.1080801@redhat.com> Message-ID: <635A202F-95B7-4D16-B220-8B2CA1FACFF4@5dollarwhitebox.org> On Oct 4, 2007, at 11:09 AM, Clark Williams wrote: > > > I'd like to add code to do two things: > > 1. Find where we're exiting without umounting > 2. Add some paranoia code in the startup logic to not screw up if > #1 fails (like is > happening now). > > To that end, would you run one of your failure cases with mock -- > debug and send me > the output? Looking at this a bit further... I can't recreate the issue using mock alone. One of the issues I fixed in my app yesterday (after commenting on this thread) was that I wasn't properly terminating spawned child processes (i.e. mock). Therefore, mock was still running a job at the time that I attempted to re-run it from my app. That said, I think the main focus here is #2... ensuring that if the bind mounts from the host are indeed still mounted, divert from cleaning the chroot (or add logic to clean everything except those points that are mounted). On top of this however, there does not appear to be anything in place to protect against two users (or the same user) using the same mock config file, and therefore the same /var/lib/mock/. If everyone knows how mock works they would use a --uniqueext for each build to protect from cleaning a chroot that is currently in use (and has host bind mounts). But that isn't likely, and isn't safe. If you look at the 'def clean()' method, mock isn't even _umounting '/ dev' at all before it cleans the chroot: === def clean(self): """clean out chroot with extreme prejudice :)""" self.state("clean") self.root_log('Cleaning Root') if os.path.exists('%s/%s' % (self.rootdir, 'proc')): self._umount('proc') if os.path.exists('%s/%s' % (self.rootdir, 'dev/pts')): self._umount('dev/pts') if os.path.exists(self.basedir): cmd = '%s -rf %s' % (self.config['rm'], self.basedir) (retval, output) = self.do(cmd) if retval != 0: error(output) if os.path.exists(self.rootdir): raise RootError, "Failed to clean basedir, exiting" === Should be: === --- /home/wdierkes/mock 2007-10-03 20:01:03.000000000 -0500 +++ /usr/bin/mock 2007-10-04 15:05:14.000000000 -0500 @@ -193,6 +193,8 @@ self._umount('proc') if os.path.exists('%s/%s' % (self.rootdir, 'dev/pts')): self._umount('dev/pts') + if os.path.exists('%s/%s' % (self.rootdir, 'dev')): + self._umount('dev') if os.path.exists(self.basedir): cmd = '%s -rf %s' % (self.config['rm'], self.basedir) === After adding this change, /dev no longer gets borked. I've added this patch/comment to BZ 250985. I would suggest adding some logic to say, determine if a build is currently in progress (using a specific config/chroot) and if so die out, but suggest the user add a --uniqueext.... or something to that effect. Thanks. From orion at cora.nwra.com Thu Oct 4 21:11:11 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 04 Oct 2007 15:11:11 -0600 Subject: mock improvements In-Reply-To: <20070925191111.GB2414@humbolt.us.dell.com> References: <20070925191111.GB2414@humbolt.us.dell.com> Message-ID: <470556EF.7040800@cora.nwra.com> Michael E Brown wrote: > So here is the list of things that have been requested lately and I'll > be working on a few of these over the next few weeks. If anybody has any > input, I'd take it. As I start on each, I'll most likely email the > mailing list with the outline of what I'm doing. Some kind of locking maybe so that when someone is running "mock -r shell" and "mock -r " is run that the latter doesn't run? -- 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 tdiehl at rogueind.com Sun Oct 7 03:52:40 2007 From: tdiehl at rogueind.com (Tom Diehl) Date: Sat, 6 Oct 2007 23:52:40 -0400 (EDT) Subject: Documentation for setting up koji? Message-ID: Hi, I am trying to setup koji and friends but documentation for the packages seems sparse at best. The only document I can find is at http://fedoraproject.org/wiki/Koji/ServerHowTo and it has several holes in it not to mention the note at the top that says "DRAFT/BETA/OH YEAH... DON'T USE" So far the biggest issue I am having is how do I disable kerberos support? I am sure there are others but that is what is stopping me presently. I commented out the kerberos stuff in /etc/kojira/kojira.conf and that seems to turn it off for kojira but I cannot find a corresponding config file for kojid. Suggestions?? Regards, -- Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From oliver at linux-kernel.at Mon Oct 8 07:14:30 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 08 Oct 2007 09:14:30 +0200 Subject: Documentation for setting up koji? In-Reply-To: References: Message-ID: <4709D8D6.9020808@linux-kernel.at> On 10/07/2007 05:52 AM, Tom Diehl wrote: > Hi, > > I am trying to setup koji and friends but documentation for the packages > seems > sparse at best. The only document I can find is at > http://fedoraproject.org/wiki/Koji/ServerHowTo and it has several holes > in it > not to mention the note at the top that says "DRAFT/BETA/OH YEAH... > DON'T USE" > > So far the biggest issue I am having is how do I disable kerberos support? > I am sure there are others but that is what is stopping me presently. > > I commented out the kerberos stuff in /etc/kojira/kojira.conf and that > seems > to turn it off for kojira but I cannot find a corresponding config file for > kojid. > > Suggestions?? http://wiki.linux-kernel.at/index.php/Koji Get back to me in case you need more information/help. Here's mine: http://buildsys.zero42.at/koji/ :-) -of From me at seanlangford.com Fri Oct 12 19:44:30 2007 From: me at seanlangford.com (Sean Langford) Date: Fri, 12 Oct 2007 15:44:30 -0400 Subject: no initrd generated with custom kernel Message-ID: <470FCE9E.4010507@seanlangford.com> Hello, I'm using pungi to spin a custom distribution with some installation automations using the anaconda kickstart mechanism. This mailing list has been invaluable to accomplish what I have thusfar. However, I have a need to include a patched fedora kernel. I've followed the guide here: http://fedoraproject.org/wiki/Docs/CustomKernel and included the resulting kernel rpm in the build manifest and in my local repo, tagged with my own invented distro tag;. Pungi correctly packages and then anaconda installs and boots this kernel but pungi does not seem to include an initrd. The logs seem to indicate that it created one: >From pungi log: > Found keymap override, using it > No i586 kernel, trying i686... > unpacking > /opt/build/work/analyzer-os/src/uos/output/7/Everything/i386/os/g4k/kernel-2.6.22.9-3268.il8.i686.rpm.i686 > Building initrd.img > Wrote /tmp/makebootdisk.initrdimage.19125 (3528k compressed) > Building isolinux directory however anaconda does not seem to be installing it. Its not clear to me how the pungi-anaconda-kernel-initrd relationship is all mapped out. Can anyone point me in the right direction? Thanks Sean -------------- next part -------------- A non-text attachment was scrubbed... Name: me.vcf Type: text/x-vcard Size: 232 bytes Desc: not available URL: From sergio at sergiomb.no-ip.org Sat Oct 13 22:06:56 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sat, 13 Oct 2007 23:06:56 +0100 Subject: pungi problem Message-ID: <1192313216.4297.13.camel@localhost.localdomain> Hi, pungi is chipping 2 kdepim without any apparent reason can someone explain why ? thanks INFO:yum.verbose.pungi:Checking deps of kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkcal_groupwise.so.1 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkcal_groupwise.so.1 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkpilot.so.0 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkpilot.so.0 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkcal_resourceremote.so.1 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkcal_resourceremote.so.1 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkabc_slox.so.0 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkabc_slox.so.0 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkgantt.so.0 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkgantt.so.0 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkode.so.1 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkode.so.1 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libknotes_xmlrpc.so.1 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libknotes_xmlrpc.so.1 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkitchensync.so.0 -------------- 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 Sat Oct 13 22:37:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 13 Oct 2007 18:37:51 -0400 Subject: pungi problem In-Reply-To: <1192313216.4297.13.camel@localhost.localdomain> References: <1192313216.4297.13.camel@localhost.localdomain> Message-ID: <20071013183751.2eaa84f1@redhat.com> On Sat, 13 Oct 2007 23:06:56 +0100 Sergio Monteiro Basto wrote: > Hi, > pungi is chipping 2 kdepim without any apparent reason > can someone explain why ? > thanks It found it as a potential match, but later we select the newest of the results. Is the second kdepim actually getting downloaded and put into the tree? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sergio at sergiomb.no-ip.org Sun Oct 14 00:58:48 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sun, 14 Oct 2007 01:58:48 +0100 Subject: pungi problem In-Reply-To: <20071013183751.2eaa84f1@redhat.com> References: <1192313216.4297.13.camel@localhost.localdomain> <20071013183751.2eaa84f1@redhat.com> Message-ID: <1192323528.4297.31.camel@localhost.localdomain> On Sat, 2007-10-13 at 18:37 -0400, Jesse Keating wrote: > On Sat, 13 Oct 2007 23:06:56 +0100 > Sergio Monteiro Basto wrote: > > > Hi, > > pungi is chipping 2 kdepim without any apparent reason > > can someone explain why ? > > thanks > > It found it as a potential match, but later we select the newest of the > results. Is the second kdepim actually getting downloaded and put into > the tree? yes , I have 2 kdepim in my iso I have about 31 duplicated packages in my iso to be more precisely to know that I done: #mount -o loop /home/F-7-i386-DVD.iso /mnt/disk #cd /mnt/disk/Fedora/ #ls -1 > ~/txt #cd ~ #cat txt | perl -pe 's/(.*)-[\w\.]+?-[\w\.]+(\.\w+)\.rpm/\1\2/' | sort > txt3 #cat txt | perl -pe 's/(.*)-[\w\.]+?-[\w\.]+(\.\w+)\.rpm/\1\2/' | sort -u > txt4 #diff txt3 txt4 | grep "^<" | perl -pe 's/< // ;s/\.\w+//' #diff txt3 txt4 | grep "^<" | perl -pe 's/< // ;s/\.\w+//' | wc -l I am testing with obsolete=0 on yum.conf.i386.f7 , to see what happens Regards, -- 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 Sun Oct 14 02:00:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 13 Oct 2007 22:00:44 -0400 Subject: pungi problem In-Reply-To: <1192323528.4297.31.camel@localhost.localdomain> References: <1192313216.4297.13.camel@localhost.localdomain> <20071013183751.2eaa84f1@redhat.com> <1192323528.4297.31.camel@localhost.localdomain> Message-ID: <20071013220044.3e64f92a@redhat.com> On Sun, 14 Oct 2007 01:58:48 +0100 Sergio Monteiro Basto wrote: > yes , I have 2 kdepim in my iso > I have about 31 duplicated packages in my iso to be more precisely > to know that I done: > #mount -o loop /home/F-7-i386-DVD.iso /mnt/disk > #cd /mnt/disk/Fedora/ > #ls -1 > ~/txt > #cd ~ > #cat txt | perl -pe 's/(.*)-[\w\.]+?-[\w\.]+(\.\w+)\.rpm/\1\2/' | > sort > txt3 #cat txt | perl -pe > 's/(.*)-[\w\.]+?-[\w\.]+(\.\w+)\.rpm/\1\2/' | sort -u > txt4 #diff > txt3 txt4 | grep "^<" | perl -pe 's/< // ;s/\.\w+//' #diff txt3 txt4 > | grep "^<" | perl -pe 's/< // ;s/\.\w+//' | wc -l > > I am testing with obsolete=0 on yum.conf.i386.f7 , to see what > happens What version of pungi are you using? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sergio at sergiomb.no-ip.org Sun Oct 14 15:00:04 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sun, 14 Oct 2007 16:00:04 +0100 Subject: pungi problem In-Reply-To: <20071013220044.3e64f92a@redhat.com> References: <1192313216.4297.13.camel@localhost.localdomain> <20071013183751.2eaa84f1@redhat.com> <1192323528.4297.31.camel@localhost.localdomain> <20071013220044.3e64f92a@redhat.com> Message-ID: <1192374004.26210.3.camel@localhost.localdomain> On Sat, 2007-10-13 at 22:00 -0400, Jesse Keating wrote: > What version of pungi are you using? pungi-0.3.7-2.fc7 -- 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 sergio at sergiomb.no-ip.org Sat Oct 13 03:15:16 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sat, 13 Oct 2007 04:15:16 +0100 Subject: pungi problem Message-ID: <1192245316.14148.1.camel@localhost.localdomain> pungi are chipping 2 kdepim without any apparent reason can someone explain why ? thanks INFO:yum.verbose.pungi:Checking deps of kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkcal_groupwise.so.1 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkcal_groupwise.so.1 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkpilot.so.0 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkpilot.so.0 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkcal_resourceremote.so.1 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkcal_resourceremote.so.1 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkabc_slox.so.0 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkabc_slox.so.0 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkgantt.so.0 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkgantt.so.0 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libkode.so.1 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkode.so.1 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.6-4.fc7.i386 to require for libknotes_xmlrpc.so.1 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libknotes_xmlrpc.so.1 INFO:yum.verbose.pungi:Added kdepim.i386 for kdepim-devel.i386 DEBUG:yum.verbose.YumBase:Matched kdepim - 6:3.5.7-3.fc7.i386 to require for libkitchensync.so.0 From msteinmann at bluesocket.com Mon Oct 15 21:56:56 2007 From: msteinmann at bluesocket.com (Martin Steinmann) Date: Mon, 15 Oct 2007 17:56:56 -0400 Subject: pungi used to create CD that includes a kickstart file Message-ID: <0240FDD68D6C1F4289F73D134A2536A1019C17C4@mail1.bluesocket.com> This was discussed on this list before back in June and in relation to pungi 0.3.7 by Joel Andres Granados and others. Using pungi I would like to create a CD that includes a kickstart file (ks.cfg) to be used during installation of a system using this CD. Is there a way to tell pungi to put a ks.cfg file into the root of the CD? I am using pungi-1.1.5-1.fc8 on F8-test3. What is the best way to modify the files in the isolinux directory? I.e. the file isolinux.cfg needs to be modified to use the ks.cfg file during boot. Should I create an RPM that overwrites these files already installed by the anaconda-runtime package or is there a more elegant way? Without such a capability to add / modify key files pungi can only really be used to respin distributions, but not create installation CDs used for automated install or appliances. Is this maybe not the intention with this tool? --martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgranado at redhat.com Tue Oct 16 12:51:10 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 16 Oct 2007 14:51:10 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <0240FDD68D6C1F4289F73D134A2536A1019C17C4@mail1.bluesocket.com> References: <0240FDD68D6C1F4289F73D134A2536A1019C17C4@mail1.bluesocket.com> Message-ID: <4714B3BE.1010408@redhat.com> Martin Steinmann wrote: > This was discussed on this list before back in June and in relation to > pungi 0.3.7 by Joel Andres Granados and others. > > > > Using pungi I would like to create a CD that includes a kickstart file > (ks.cfg) to be used during installation of a system using this CD. > > > > Is there a way to tell pungi to put a ks.cfg file into the root of the > CD? I am using pungi-1.1.5-1.fc8 on F8-test3. > > > > What is the best way to modify the files in the isolinux directory? > I.e. the file isolinux.cfg needs to be modified to use the ks.cfg file > during boot. Should I create an RPM that overwrites these files already > installed by the anaconda-runtime package or is there a more elegant > way? > > > > Without such a capability to add / modify key files pungi can only > really be used to respin distributions, but not create installation CDs > used for automated install or appliances. Is this maybe not the > intention with this tool? > > > > --martin > > > > > > > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list It been a long time since I had a hard look at pungi. I do know that it went from config files to using kickstart. Maybe you can use the %post functionality of kickstart, not sure :(. what version are you using? try using the latest version. http://hosted.fedoraproject.org/projects/pungi Regards -- Joel Andres Granados Red Hat / Brno, Czech Republic From jkeating at redhat.com Tue Oct 16 13:29:49 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 16 Oct 2007 09:29:49 -0400 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <4714B3BE.1010408@redhat.com> References: <0240FDD68D6C1F4289F73D134A2536A1019C17C4@mail1.bluesocket.com> <4714B3BE.1010408@redhat.com> Message-ID: <20071016092949.0828e304@redhat.com> On Tue, 16 Oct 2007 14:51:10 +0200 Joel Andres Granados wrote: > It been a long time since I had a hard look at pungi. I do > know that it went from config files to using kickstart. > Maybe you can use the %post functionality of kickstart, not > sure :(. > > what version are you using? try using the latest version. > http://hosted.fedoraproject.org/projects/pungi The %post part of a kickstart file is not yet processed by pungi. I haven't decided if or how it would be used. Also there has been a slight regression in configurability in pungi with the move to using kickstart files. You can no longer override what "release note" files to lay onto the install tree. This was the method before to use to get files out of packages and place them on the tree/media. A file such as a kickstart file. Right now unfortunately you have to edit the source code itself, in pypungi/config.py. You can add another file regular expression to match your kickstart file, and list another package to the packages to look in for those files that has your kickstart file in it. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jgranado at redhat.com Tue Oct 16 14:32:17 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 16 Oct 2007 16:32:17 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <20071016092949.0828e304@redhat.com> References: <0240FDD68D6C1F4289F73D134A2536A1019C17C4@mail1.bluesocket.com> <4714B3BE.1010408@redhat.com> <20071016092949.0828e304@redhat.com> Message-ID: <4714CB71.6020401@redhat.com> Jesse Keating wrote: > On Tue, 16 Oct 2007 14:51:10 +0200 > Joel Andres Granados wrote: > >> It been a long time since I had a hard look at pungi. I do >> know that it went from config files to using kickstart. >> Maybe you can use the %post functionality of kickstart, not >> sure :(. >> >> what version are you using? try using the latest version. >> http://hosted.fedoraproject.org/projects/pungi > > The %post part of a kickstart file is not yet processed by pungi. I > haven't decided if or how it would be used. > > Also there has been a slight regression in configurability in pungi > with the move to using kickstart files. You can no longer override > what "release note" files to lay onto the install tree. This was the > method before to use to get files out of packages and place them on the > tree/media. A file such as a kickstart file. Right now unfortunately > you have to edit the source code itself, in pypungi/config.py. You can > add another file regular expression to match your kickstart file, and > list another package to the packages to look in for those files that > has your kickstart file in it. > > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list I think you can also add the file to the resulting iso image. it should be easier than changing the code (IMO) 1. you have to mount the iso image somewhere `mount -o loop /path/to/isoimage /mount/dir` 2. cp -rf /mount/dir /other/temp/dir 3. cp kickstart.cfg /other/temp/dir 4. umount /mount/dir 5. mkisofs ... 6. put iso on cd I'm not really sure how the mkisofs command goes. but you can always look at the pungi code and see what is done there :) Be sure that the copy takes two hidden files that are at the root. -- Joel Andres Granados Red Hat / Brno, Czech Republic From msteinmann at bluesocket.com Tue Oct 16 15:00:51 2007 From: msteinmann at bluesocket.com (Martin Steinmann) Date: Tue, 16 Oct 2007 11:00:51 -0400 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <4714CB71.6020401@redhat.com> Message-ID: <0240FDD68D6C1F4289F73D134A2536A1019C1872@mail1.bluesocket.com> > >I think you can also add the file to the resulting iso image. >it should be easier than changing the code (IMO) >1. you have to mount the iso image somewhere `mount -o loop >/path/to/isoimage /mount/dir` >2. cp -rf /mount/dir /other/temp/dir >3. cp kickstart.cfg /other/temp/dir >4. umount /mount/dir >5. mkisofs ... >6. put iso on cd > >I'm not really sure how the mkisofs command goes. but you can always look >at the pungi >code and see what is done there :) > >Be sure that the copy takes two hidden files that are at the root. > Joel Many thanks for all the great suggestions - very helpful. We actually have a fully automated build system that creates CDs currently for RHEL4, RHEL5 and FC6. This is done by reverse engineering starting with disk 1 of the official distribution. We then create a new custom CD with a new repository, new metadata and we have to open and change the stage2 image as well to change the look & feel during installation. This is messy as you can imagine, but it works. For F7 we were hoping we could use pungi, but the pungi development now moved on to F8. Therefore, I don't think we will do an F7 based appliance. On F8 we were hoping pungi could do what we needed - pretty basic stuff after all as most of it can be added as RPMs (except kickstart files and modifications to files in the isolinux directory). I am not so keen changing the pungi code as pungi is still under heavy development and will therefore likely change. Therefore, we might choose your proposed approach of modifying the CD that was created with pungi in the first place. Still messy but slightly better than before. Eventually we hope that there will be a tool to create appliances. After all, just re-spinning Fedora or RHEL distributions is only fun the first time, but provides little value unless it can be turned either into an automated install or an appliance with custom look & feel, or both. BTW: The project I am working on is at http://www.sipfoundry.org --martin From jgranado at redhat.com Tue Oct 16 15:21:21 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Tue, 16 Oct 2007 17:21:21 +0200 Subject: pungi used to create CD that includes a kickstart file In-Reply-To: <0240FDD68D6C1F4289F73D134A2536A1019C1872@mail1.bluesocket.com> References: <0240FDD68D6C1F4289F73D134A2536A1019C1872@mail1.bluesocket.com> Message-ID: <4714D6F1.8030300@redhat.com> Martin Steinmann wrote: >> I think you can also add the file to the resulting iso image. >> it should be easier than changing the code (IMO) >> 1. you have to mount the iso image somewhere `mount -o loop >> /path/to/isoimage /mount/dir` >> 2. cp -rf /mount/dir /other/temp/dir >> 3. cp kickstart.cfg /other/temp/dir >> 4. umount /mount/dir >> 5. mkisofs ... >> 6. put iso on cd >> >> I'm not really sure how the mkisofs command goes. but you can always > look >at the pungi >> code and see what is done there :) >> >> Be sure that the copy takes two hidden files that are at the root. >> > > Joel > > Many thanks for all the great suggestions - very helpful. > > We actually have a fully automated build system that creates CDs > currently for RHEL4, RHEL5 and FC6. This is done by reverse engineering > starting with disk 1 of the official distribution. We then create a new > custom CD with a new repository, new metadata and we have to open and > change the stage2 image as well to change the look & feel during > installation. This is messy as you can imagine, but it works. > > For F7 we were hoping we could use pungi, but the pungi development now > moved on to F8. Therefore, I don't think we will do an F7 based > appliance. > > On F8 we were hoping pungi could do what we needed - pretty basic stuff > after all as most of it can be added as RPMs (except kickstart files and > modifications to files in the isolinux directory). I am not so keen > changing the pungi code as pungi is still under heavy development and > will therefore likely change. Therefore, we might choose your proposed > approach of modifying the CD that was created with pungi in the first > place. Still messy but slightly better than before. > > Eventually we hope that there will be a tool to create appliances. After > all, just re-spinning Fedora or RHEL distributions is only fun the first > time, but provides little value unless it can be turned either into an > automated install or an appliance with custom look & feel, or both. > > BTW: The project I am working on is at http://www.sipfoundry.org > > --martin > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list There is also the fedora livecd to play with. You can basically put together a bunch of apps and configure them in a certain way. When the livecd is created, you can boot it in pretty much any computer to show off your stuff. There is also revisor that tries to put pungi and livecd together into a very user friendly interface. It also has more funtionalities that I don't know about :( hope it helps. -- Joel Andres Granados Red Hat / Brno, Czech Republic From me at seanlangford.com Fri Oct 19 13:47:12 2007 From: me at seanlangford.com (Sean Langford) Date: Fri, 19 Oct 2007 09:47:12 -0400 Subject: no initrd generated with custom kernel [solved] In-Reply-To: <470FCE9E.4010507@seanlangford.com> References: <470FCE9E.4010507@seanlangford.com> Message-ID: <4718B560.4090902@seanlangford.com> Hello, I figured out the problem here, so thought I'd share it for the record. The problem was that the mkinitrd package was not getting included by pungi. The log I quoted below which shows an initrd being created is actually pungi creating the initrd for the anaconda installer itself, not the installed system. I added mkinitrd to the manifest and voila it worked. Cheers Sean Sean Langford wrote: > Hello, > > I'm using pungi to spin a custom distribution with some installation > automations using the anaconda kickstart mechanism. This mailing list > has been invaluable to accomplish what I have thusfar. > > However, I have a need to include a patched fedora kernel. I've > followed the guide here: > > http://fedoraproject.org/wiki/Docs/CustomKernel > > and included the resulting kernel rpm in the build manifest and in my > local repo, tagged with my own invented distro tag;. Pungi correctly > packages and then anaconda installs and boots this kernel but pungi does > not seem to include an initrd. The logs seem to indicate that it > created one: > > >From pungi log: > >> Found keymap override, using it >> No i586 kernel, trying i686... >> unpacking >> /opt/build/work/analyzer-os/src/uos/output/7/Everything/i386/os/g4k/kernel-2.6.22.9-3268.il8.i686.rpm.i686 >> Building initrd.img >> Wrote /tmp/makebootdisk.initrdimage.19125 (3528k compressed) >> Building isolinux directory >> > however anaconda does not seem to be installing it. Its not clear to me > how the pungi-anaconda-kernel-initrd relationship is all mapped out. > Can anyone point me in the right direction? > > Thanks > > Sean > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/anaconda-devel-list From msteinmann at bluesocket.com Sat Oct 20 03:40:03 2007 From: msteinmann at bluesocket.com (Martin Steinmann) Date: Fri, 19 Oct 2007 23:40:03 -0400 Subject: F8 rawhide, error from method.py during kickstart install from cdrom Message-ID: <0240FDD68D6C1F4289F73D134A2536A1017AB96A@mail1.bluesocket.com> F8 RAWHIDE updated. I get the following error from anaconda doing a kickstart install from cdrom: File "/usr/lib/python2.5/site-packages/pykickstart/commands/method.py", line 81, in parse (opts, extra) = op.parse_args(args=args) AttributeError: 'NoneType' object has no attribute 'parse_args' install exited abnormally [1/1] This happens right after anaconda started the X server. The kickstart file used looks fairly straight forward. Could this be a known error? thanks --martin ks.cfg: #--- Installation method (install, no upgrade) and source (CD-ROM) install cdrom #--- Debugging (uncomment next line to debug in the interactive mode) #interactive #--- Language and input support lang en_US.UTF-8 ##langsupport --default=en_US.UTF-8 en_US.UTF-8 keyboard us ##mouse generic3ps/2 #--- X-Windows (use "skipx" directive to skip X-Windows configuration) skipx #--- Network configuration # Add some default or else Anaconda will pop a window and ask network --device eth0 --bootproto static --ip 192.168.1.176 --netmask 255.255.255.0 --gateway 192.168.1.1 --nameserver 192.168.1.145 --hostname sipx.example.com #--- Authentication and security rootpw setup firewall --disabled selinux --disabled authconfig --enableshadow --enablemd5 #--- Time zone timezone America/New_York #--- Boot loader bootloader --location=mbr #--- Partitioning #--- NON_RAID Disk partitioning (LVM) zerombr yes clearpart --all --initlabel part /boot --fstype ext3 --size=128 part swap --size=1024 part /recovery --fstype ext3 --size=1024 part / --fstype ext3 --size=4096 part /var --fstype ext3 --size 1 --grow #--- Reboot the host after installation is done reboot #--- Package selection %packages --resolvedeps e2fsprogs -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio at sergiomb.no-ip.org Sat Oct 20 16:16:57 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Sat, 20 Oct 2007 17:16:57 +0100 Subject: pungi problem In-Reply-To: <20071013220044.3e64f92a@redhat.com> References: <1192313216.4297.13.camel@localhost.localdomain> <20071013183751.2eaa84f1@redhat.com> <1192323528.4297.31.camel@localhost.localdomain> <20071013220044.3e64f92a@redhat.com> Message-ID: <1192897017.30843.3.camel@localhost.localdomain> On Sat, 2007-10-13 at 22:00 -0400, Jesse Keating wrote: > On Sun, 14 Oct 2007 01:58:48 +0100 > Sergio Monteiro Basto wrote: > > > yes , I have 2 kdepim in my iso > > I have about 31 duplicated packages in my iso to be more precisely > > to know that I done: > > #mount -o loop /home/F-7-i386-DVD.iso /mnt/disk > > #cd /mnt/disk/Fedora/ > > #ls -1 > ~/txt > > #cd ~ > > #cat txt | perl -pe 's/(.*)-[\w\.]+?-[\w\.]+(\.\w+)\.rpm/\1\2/' | > > sort > txt3 #cat txt | perl -pe > > 's/(.*)-[\w\.]+?-[\w\.]+(\.\w+)\.rpm/\1\2/' | sort -u > txt4 #diff > > txt3 txt4 | grep "^<" | perl -pe 's/< // ;s/\.\w+//' #diff txt3 txt4 > > | grep "^<" | perl -pe 's/< // ;s/\.\w+//' | wc -l > > > > I am testing with obsolete=0 on yum.conf.i386.f7 , to see what > > happens > > What version of pungi are you using? I had update to pungi-1.1.5-1.fc8 and yum to yum-3.2.7-1.fc8 and I have exactely the same problem ! using only base and updates here is my confs: pungi -c /usr/share/pungi/f7-fedora.ks --destdir=/srv/pungi/f7/ --name Fedora --ver 7 --cachedir=/srv/pungi/cache --nosource cat /usr/share/pungi/f7-fedora.ks # Kickstart file for composing the "Fedora" spin of Fedora 8 # Use a part of 'iso' to define how large you want your isos. # Only used when composing to more than one iso. #part iso --size=4998 repo --name=Fedora7 --baseurl=ftp://ftp.di.uminho.pt/pub/fedora/core/7/Everything/i386/os/ # http://ftp.fc.up.pt/Mirrors/fedora/linux/releases/7/Everything/i386/os/ repo --name=Fedora7Updates --baseurl=ftp://ftp.di.uminho.pt/pub/fedora/core/updates/7/i386 # http://ftp.di.uminho.pt/pub/fedora/core/updates/7/i386 # http://ftp.fc.up.pt/Mirrors/fedora/linux/updates/7/i386 #repo --name=LivnaFedoraBase --baseurl=ftp://ftp.di.uminho.pt/pub/fedora/livna/fedora/7/i386/ # http://rpm.livna.org/fedora/7/i386/ # http://livna-dl.reloumirrors.net/fedora/7/i386/ # Add the repos you wish to use to compose here. At least one of them needs group data. #repo --name=rawhide --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch #repo --name=rawhide-source --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide-source&arch=$basearch # Package manifest for the compose. Uses repo group metadata to translate groups. # (@base is added by default unless you add --nobase to %packages) %packages * #%end From jgranado at redhat.com Sat Oct 20 21:52:45 2007 From: jgranado at redhat.com (Joel Andres Granados) Date: Sat, 20 Oct 2007 23:52:45 +0200 Subject: F8 rawhide, error from method.py during kickstart install from cdrom In-Reply-To: <0240FDD68D6C1F4289F73D134A2536A1017AB96A@mail1.bluesocket.com> References: <0240FDD68D6C1F4289F73D134A2536A1017AB96A@mail1.bluesocket.com> Message-ID: <471A78AD.7080603@redhat.com> Martin Steinmann wrote: > F8 RAWHIDE updated. I get the following error from anaconda doing a kickstart install from cdrom: > > File "/usr/lib/python2.5/site-packages/pykickstart/commands/method.py", line 81, in parse > (opts, extra) = op.parse_args(args=args) > AttributeError: 'NoneType' object has no attribute 'parse_args' > install exited abnormally [1/1] > > This happens right after anaconda started the X server. > > The kickstart file used looks fairly straight forward. Could this be a known error? > thanks > --martin > > ks.cfg: > #--- Installation method (install, no upgrade) and source (CD-ROM) > install > cdrom > > #--- Debugging (uncomment next line to debug in the interactive mode) > #interactive > > #--- Language and input support > lang en_US.UTF-8 > ##langsupport --default=en_US.UTF-8 en_US.UTF-8 > keyboard us > ##mouse generic3ps/2 > > #--- X-Windows (use "skipx" directive to skip X-Windows configuration) > skipx > > #--- Network configuration > # Add some default or else Anaconda will pop a window and ask > network --device eth0 --bootproto static --ip 192.168.1.176 --netmask 255.255.255.0 --gateway 192.168.1.1 --nameserver 192.168.1.145 --hostname sipx.example.com > > #--- Authentication and security > rootpw setup > firewall --disabled > selinux --disabled > authconfig --enableshadow --enablemd5 > > #--- Time zone > timezone America/New_York > > #--- Boot loader > bootloader --location=mbr > > #--- Partitioning > #--- NON_RAID Disk partitioning (LVM) > zerombr yes > clearpart --all --initlabel > part /boot --fstype ext3 --size=128 > part swap --size=1024 > part /recovery --fstype ext3 --size=1024 > part / --fstype ext3 --size=4096 > part /var --fstype ext3 --size 1 --grow > > #--- Reboot the host after installation is done > reboot > > #--- Package selection > %packages --resolvedeps > e2fsprogs > > > > ------------------------------------------------------------------------ > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list might want to discuss this on the anaconda-devel list. anaconda-devel-list at redhat.com. -- Joel Andres Granados Red Hat / Brno, Czech Republic From Michael_E_Brown at dell.com Sun Oct 21 22:22:58 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Sun, 21 Oct 2007 17:22:58 -0500 Subject: Mock 0.8.x available Message-ID: <20071021222258.GA26458@humbolt.us.dell.com> Mock users, I have posted a new version of mock for review and comments. RPM download: http://linux.dell.com/libsmbios/download/mock/mock-0.8.1/ Git repository: http://linux.dell.com/git/mock-v2.git Compatibility: -- Mock 0.8.x+ has been written on Fedora 7 and is intended for use on Fedora 7 and higher. A limited amount of testing has been done on FC6, so please report any FC6-specific bugs and we will make best-effort attempts to fix them. -- I have tried to maintain a high degree of compatibility with mock 0.7 in cmdline args and New stuff: -- plugin system to better modularize things -- new plugins: -- Yum cache -- root cache -- ccache -- bind mount -- root cache (formerly called autocache) is now significantly smaller in size -- speed increases: mock 0.8 is now in almost every case minutes faster than 0.7, especially for multiple builds. -- uses python logging.py module for increased logging flexibility -- new command: 'mock install PACKAGE' to run a 'yum install PACKAGE' inside the buildroot -- expanded command: 'mock installdeps RPM_FILE' can now install deps for a local binary RPM. Formerlly, only SRPMS were supported. -- new option: "--cleanup-after" that can be used with "--resultdir". This will do a cleanup of the buildroot after the build. This is enabled by default such that any '--resultdir' builds will be automatically cleaned up -- All of the config files delivered with mock have been tested and should work. (The test case compiles mock using each of the config files delivered with mock.) Changed: -- cmdline requires "rebuild" argument when rebuilding srpms. Previously you could just pass srpm name. -- output has slightly changed. Mock is now slightly more verbose. -- formerly /dev from the host was bind-mounted into the chroot. This is now not enabled by default, but can be configured easily per-chroot using the bind plugin. See the 'defaults.cfg' files for config details. -- '-r CONFIG' option can no longer accept full config filenames ("config.cfg"). Leave off the '.cfg' for mock 0.8+. Formerly, config ('-r' option) could be specified using either "config.cfg" or "config" and mock would look for /etc/mock/config.cfg, automatically adding the '.cfg', if necessary. -- logs are not overwritten or truncated for --no-clean or --resultdir builds. -- cmdline options removed: --autocache, --rebuild-cache: use "--enable-plugin" or "--disable-plugin" instead --verbose, --debug, --quiet: the log files contain all the information. --verbose could possibly return. --statedir: statedir didnt have much point in life and has gone away Config files: -- Old config files will, by and large, still work. There are several options in the old config files that are no longer applicable now that 'mock-helper' has went away. The next release of mock should have warnings enabled if it sees that your config file has obsolete options. Internal Changes: -- now modularized -- mock-helper is gone. Instead there is a setuid-wrapper that calls mock.py. This vastly simplifies development. Plugin Notes: -- the plugin system is somewhat rudimentary at this time. If this becomes something that is truly useful for out-of-tree plugins or third-parties, we can formalize the interface some more. As of now, the plugin interface should have most of the hooks to do useful stuff, but some other things like the 'conduit' interface that yum uses for plugins is not present. This would formalize the interface a bit more and make sure the plugins dont grope too badly into internals they shouldnt. Future plans: -- Upstream mock git will be updated to this version next week after we sort out branching for the 0.7 release. -- This version of mock will be checked into Fedora 9 next week. -- yum integration: plan to try to use the yum API rather than the cmdline. this will enable several optimizations and speed ups due to not redownloading the yum metadata multiple times. -- config file format change: at some future point, we probably will switch to an .ini format config file. SPECIAL SECURITY WARNING: 1) default /usr/bin/mock owner is root:mock with permissions 4550 (-rwsrwx---). Thus, it may only be run by the 'root' user or members of the 'mock' group. DO NOT PUT UNTRUSTED USERS IN THE 'MOCK' GROUP! The current code (as well as all previous versions) has many easily-used mechanisms that an untrusted user could use to elevate their local privileges. IT IS NOT THE GOAL OF THE MOCK DEVELOPERS TO MAKE MOCK A TOOL THAT CAN BE USED BY UNTRUSTED LOCAL USERS. 2) All 'rpmbuild' commands, as well as the 'rpm' command to install and unpack the to-be-built SRPM are run as the user running 'mock' with no elevated privileges. These 'rpm' and 'rpmbuild' commands are run in the chroot environment with these lower privileges. Thus, it should be relatively safe to use mock to compile code from untrusted sources. That being said, MOCK HAS NOT BEEN THOROUGHLY AUDITED TO GUARANTEE THE SAFETY OF THIS. -- Michael From jkeating at redhat.com Mon Oct 22 02:05:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 21 Oct 2007 22:05:30 -0400 Subject: Mock 0.8.x available In-Reply-To: <20071021222258.GA26458@humbolt.us.dell.com> References: <20071021222258.GA26458@humbolt.us.dell.com> Message-ID: <20071021220530.60ea6bfb@redhat.com> On Sun, 21 Oct 2007 17:22:58 -0500 Michael E Brown wrote: > I have posted a new version of mock for review and comments. I'm going to wait until we get Fedora 8 out the door before I start looking at this. I'd like to put it through my own paces, which involve doing pungi spins and such inside mock. Getting some time tests with that would be interesting. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- 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 fedoraproject.org Mon Oct 22 02:15:36 2007 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 22 Oct 2007 02:15:36 +0000 Subject: Mock 0.8.x available In-Reply-To: <20071021222258.GA26458@humbolt.us.dell.com> References: <20071021222258.GA26458@humbolt.us.dell.com> Message-ID: <1193019336.8542.263.camel@cutter> On Sun, 2007-10-21 at 17:22 -0500, Michael E Brown wrote: > Mock users, > > I have posted a new version of mock for review and comments. > > RPM download: http://linux.dell.com/libsmbios/download/mock/mock-0.8.1/ > Git repository: http://linux.dell.com/git/mock-v2.git These changes look like a great start. You should look at integrating the 'cost' feature from yum 3.2.6 and above a bit more, I think. It'll let you prefer a specific repo over another one for the same pkg nevra. Handy for having your just-built-but-same-version repo be pulled from instead of an older, remote repo. Also handy for a local-cache to drag from. -sv From jkeating at redhat.com Mon Oct 22 02:21:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 21 Oct 2007 22:21:51 -0400 Subject: Mock 0.8.x available In-Reply-To: <1193019336.8542.263.camel@cutter> References: <20071021222258.GA26458@humbolt.us.dell.com> <1193019336.8542.263.camel@cutter> Message-ID: <20071021222151.6c599dad@redhat.com> On Mon, 22 Oct 2007 02:15:36 +0000 seth vidal wrote: > These changes look like a great start. You should look at integrating > the 'cost' feature from yum 3.2.6 and above a bit more, I think. It'll > let you prefer a specific repo over another one for the same pkg > nevra. Handy for having your just-built-but-same-version repo be > pulled from instead of an older, remote repo. > > Also handy for a local-cache to drag from. THis is a big must. We absolutely need this before we enable the koji static-repos by default. Otherwise quite frequently all packages will be pulled from the static-repos over a costly data line instead of from a local mirror or on disk cache. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From msteinmann at bluesocket.com Mon Oct 22 19:41:43 2007 From: msteinmann at bluesocket.com (Martin Steinmann) Date: Mon, 22 Oct 2007 15:41:43 -0400 Subject: Minimal system created with Pungi Message-ID: <0240FDD68D6C1F4289F73D134A2536A1019C2059@mail1.bluesocket.com> I am trying to create a minimal system of F8 rawhide with pungi, where anaconda runs in graphics mode (with the X server) during installation, but the installed system does not have an X server. I am using a pungi config file like the one below. It turns out that the packages for the X server have to be included so that they can be used during stage2 of the install. However, they also end up in the RPM repository on the CD. Is there a way to avoid this? --martin %packages --nobase kernel xorg-x11-fonts-ISO8859-1-75dpi busybox-anaconda dejavu-lgc-fonts memtest86+ xorg-x11-drivers selinux-policy-targeted selinux-policy-mls anaconda-runtime man nano grub openssh-server dhclient rpcbind sendmail vixie-cron sudo rootfiles -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Mon Oct 22 19:55:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Oct 2007 15:55:37 -0400 Subject: Minimal system created with Pungi In-Reply-To: <0240FDD68D6C1F4289F73D134A2536A1019C2059@mail1.bluesocket.com> References: <0240FDD68D6C1F4289F73D134A2536A1019C2059@mail1.bluesocket.com> Message-ID: <20071022155537.2cbfe1b0@redhat.com> On Mon, 22 Oct 2007 15:41:43 -0400 "Martin Steinmann" wrote: > I am trying to create a minimal system of F8 rawhide with pungi, where > anaconda runs in graphics mode (with the X server) during > installation, but the installed system does not have an X server. > > > > I am using a pungi config file like the one below. It turns out that > the packages for the X server have to be included so that they can be > used during stage2 of the install. However, they also end up in the > RPM repository on the CD. Is there a way to avoid this? There isn't a good way of avoiding this with the current pungi codebase. What would be needed is separation of the packages used to compose vs the packages /in/ the compose. A work around would be to do one compose with the graphical packages, a second compose without the graphical packages and just swap the repodata and Packages/ directories. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rob.myers at gtri.gatech.edu Tue Oct 23 18:13:07 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Tue, 23 Oct 2007 14:13:07 -0400 Subject: RFC - Patch - koji SCM generalization Message-ID: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> attached is a patch that attempts to generalize checking out the components used to build an SRPM. this patch supports CVS, GIT, and SVN, but only CVS and SVN have been tested. the idea is to provide the infrastructure for different SCM systems to be configured at run-time so that users can choose their favorite system. is there a better approach? did i miss something obvious? general comments? thanks. rob. -------------- next part -------------- A non-text attachment was scrubbed... Name: koji-1.2.2-add-scm.patch Type: text/x-patch Size: 23865 bytes Desc: not available URL: From mikeb at redhat.com Tue Oct 23 18:25:03 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 23 Oct 2007 14:25:03 -0400 Subject: RFC - Patch - koji SCM generalization In-Reply-To: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> References: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <1193163903.4427.4.camel@burren.boston.redhat.com> On Tue, 2007-10-23 at 14:13 -0400, rob myers wrote: > attached is a patch that attempts to generalize checking out the > components used to build an SRPM. this patch supports CVS, GIT, and > SVN, but only CVS and SVN have been tested. the idea is to provide the > infrastructure for different SCM systems to be configured at run-time so > that users can choose their favorite system. > > is there a better approach? did i miss something obvious? general > comments? It looks pretty good, but I wonder if you need to make scmtype a config option? I'd rather have Koji support all scmtypes all the time and have some other method for restricting what URLs are valid locations to download the source from. Maybe a list of valid hostnames or hostname/path pairs? From mikeb at redhat.com Tue Oct 23 18:30:56 2007 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 23 Oct 2007 14:30:56 -0400 Subject: RFC - Patch - koji SCM generalization In-Reply-To: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> References: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> Message-ID: <1193164256.4427.11.camel@burren.boston.redhat.com> On Tue, 2007-10-23 at 14:13 -0400, rob myers wrote: > attached is a patch that attempts to generalize checking out the > components used to build an SRPM. this patch supports CVS, GIT, and > SVN, but only CVS and SVN have been tested. the idea is to provide the > infrastructure for different SCM systems to be configured at run-time so > that users can choose their favorite system. It would also be nice if rather than assuming the existence of the "common/" module and hard-coding the "make srpm" command, there was some way to specify what modules were necessary to checkout, and what command to run to create a srpm. This should probably be configurable per-repository. It might make sense to add a new database table to store this information in a more flexible way than possible with the config files. However, this is a great start. I'm going to review the patch more carefully, and I'll see about merging it soon (after possibly removing the scmtype config option I mentioned earlier). Thanks a lot! From rob.myers at gtri.gatech.edu Tue Oct 23 19:02:02 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Tue, 23 Oct 2007 15:02:02 -0400 Subject: RFC - Patch - koji SCM generalization In-Reply-To: <1193163903.4427.4.camel@burren.boston.redhat.com> References: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> <1193163903.4427.4.camel@burren.boston.redhat.com> Message-ID: <1193166122.18349.110.camel@rxm-581b.stl.gtri.gatech.edu> On Tue, 2007-10-23 at 14:25 -0400, Mike Bonnet wrote: > On Tue, 2007-10-23 at 14:13 -0400, rob myers wrote: > > attached is a patch that attempts to generalize checking out the > > components used to build an SRPM. this patch supports CVS, GIT, and > > SVN, but only CVS and SVN have been tested. the idea is to provide the > > infrastructure for different SCM systems to be configured at run-time so > > that users can choose their favorite system. > > > > is there a better approach? did i miss something obvious? general > > comments? > > It looks pretty good, but I wonder if you need to make scmtype a config > option? I'd rather have Koji support all scmtypes all the time and have > some other method for restricting what URLs are valid locations to > download the source from. Maybe a list of valid hostnames or > hostname/path pairs? what do you mean by "path"? /cvsroot or /usr/bin/cvs? i added the scmtype to function as a mechanism to determine which binary to call for a given url. for example, both git and svn can have http:// urls, so the url itself does not currently contain enough information to indicate which binary should be called. at the same time, there is no reason koji could not support all types of scm at once- if there is a mechanism to determine what binary or checkout command to call for a given url. an acl of approved SCM backends seems like it would be a nice feature. rob. From rob.myers at gtri.gatech.edu Tue Oct 23 19:14:38 2007 From: rob.myers at gtri.gatech.edu (rob myers) Date: Tue, 23 Oct 2007 15:14:38 -0400 Subject: RFC - Patch - koji SCM generalization In-Reply-To: <1193164256.4427.11.camel@burren.boston.redhat.com> References: <1193163187.18349.96.camel@rxm-581b.stl.gtri.gatech.edu> <1193164256.4427.11.camel@burren.boston.redhat.com> Message-ID: <1193166878.18349.121.camel@rxm-581b.stl.gtri.gatech.edu> On Tue, 2007-10-23 at 14:30 -0400, Mike Bonnet wrote: > On Tue, 2007-10-23 at 14:13 -0400, rob myers wrote: > > attached is a patch that attempts to generalize checking out the > > components used to build an SRPM. this patch supports CVS, GIT, and > > SVN, but only CVS and SVN have been tested. the idea is to provide the > > infrastructure for different SCM systems to be configured at run-time so > > that users can choose their favorite system. > > It would also be nice if rather than assuming the existence of the > "common/" module and hard-coding the "make srpm" command, there was some > way to specify what modules were necessary to checkout, and what command > to run to create a srpm. This should probably be configurable > per-repository. It might make sense to add a new database table to > store this information in a more flexible way than possible with the > config files. the existing design is (currently) sufficient for my needs. what you describe is more flexible and is probably a better design, but is it needed? > However, this is a great start. I'm going to review the patch more > carefully, and I'll see about merging it soon (after possibly removing > the scmtype config option I mentioned earlier). thanks for your feedback, and remove cruft as necessary. :) rob. From jmoskovc at redhat.com Thu Oct 25 12:56:07 2007 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Thu, 25 Oct 2007 14:56:07 +0200 Subject: cvs-1.11.22-12.fc8 rebuild in mock Message-ID: <47209267.9010809@redhat.com> I tried to rebuild this package in mock without any problems. According to log it seems that it failed because of missing "krb5-devel" package, but this is in BuildRequires, so I don't think it's the fault of wrong spec file. jirka From jkeating at redhat.com Thu Oct 25 13:01:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 25 Oct 2007 09:01:48 -0400 Subject: cvs-1.11.22-12.fc8 rebuild in mock In-Reply-To: <47209267.9010809@redhat.com> References: <47209267.9010809@redhat.com> Message-ID: <20071025090148.22da80dd@redhat.com> On Thu, 25 Oct 2007 14:56:07 +0200 Jiri Moskovcak wrote: > I tried to rebuild this package in mock without any problems. > According to log it seems that it failed because of missing > "krb5-devel" package, but this is in BuildRequires, so I don't think > it's the fault of wrong spec file. What repos were you configured to use in your mock config? What happens if you do a 'yum resolvedep krb5-devel' pointing to the repos that are configured? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jmoskovc at redhat.com Fri Oct 26 12:03:46 2007 From: jmoskovc at redhat.com (Jiri Moskovcak) Date: Fri, 26 Oct 2007 14:03:46 +0200 Subject: cvs-1.11.22-12.fc8 rebuild in mock In-Reply-To: <20071025090148.22da80dd@redhat.com> References: <47209267.9010809@redhat.com> <20071025090148.22da80dd@redhat.com> Message-ID: <4721D7A2.5040506@redhat.com> Jesse Keating wrote: > On Thu, 25 Oct 2007 14:56:07 +0200 > Jiri Moskovcak wrote: > >> I tried to rebuild this package in mock without any problems. >> According to log it seems that it failed because of missing >> "krb5-devel" package, but this is in BuildRequires, so I don't think >> it's the fault of wrong spec file. > > What repos were you configured to use in your mock config? What > happens if you do a 'yum resolvedep krb5-devel' pointing to the repos > that are configured? I tried to make scratch build via koji and everything was ok. According to the log from 2007-10-19 it fails only for ARCH=x86_64, isn't this package missing? From jkeating at redhat.com Fri Oct 26 13:35:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Oct 2007 09:35:16 -0400 Subject: cvs-1.11.22-12.fc8 rebuild in mock In-Reply-To: <4721D7A2.5040506@redhat.com> References: <47209267.9010809@redhat.com> <20071025090148.22da80dd@redhat.com> <4721D7A2.5040506@redhat.com> Message-ID: <20071026093516.6e5f461c@redhat.com> On Fri, 26 Oct 2007 14:03:46 +0200 Jiri Moskovcak wrote: > I tried to make scratch build via koji and everything was ok. > According to the log from 2007-10-19 it fails only for ARCH=x86_64, > isn't this package missing? I think the build on 2007-10-19 had repo issues. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ob.system at gmail.com Fri Oct 26 21:50:19 2007 From: ob.system at gmail.com (Oscar Victorio Calixto Bacho) Date: Fri, 26 Oct 2007 16:50:19 -0500 Subject: Koji SPEC Message-ID: <6a28481b0710261450ob430507n46acb92c0b607493@mail.gmail.com> Hi List I have one question. where define $PYDIR of file koji-1.2/hunb/Makefile? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio at sergiomb.no-ip.org Tue Oct 30 14:54:19 2007 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Tue, 30 Oct 2007 14:54:19 +0000 Subject: pungi problem In-Reply-To: <1192897017.30843.3.camel@localhost.localdomain> References: <1192313216.4297.13.camel@localhost.localdomain> <20071013183751.2eaa84f1@redhat.com> <1192323528.4297.31.camel@localhost.localdomain> <20071013220044.3e64f92a@redhat.com> <1192897017.30843.3.camel@localhost.localdomain> Message-ID: <1193756059.6459.14.camel@localhost.localdomain> On Sat, 2007-10-20 at 17:16 +0100, Sergio Monteiro Basto wrote: > On Sat, 2007-10-13 at 22:00 -0400, Jesse Keating wrote: > > On Sun, 14 Oct 2007 01:58:48 +0100 > > Sergio Monteiro Basto wrote: > > > > > yes , I have 2 kdepim in my iso > > > I have about 31 duplicated packages in my iso to be more precisely > > > to know that I done: > > > > What version of pungi are you using? > > I had update to pungi-1.1.5-1.fc8 and yum to yum-3.2.7-1.fc8 > > and I have exactely the same problem ! > using only base and updates > Hi , I build one iso with livna , for F7 , with this conf: my workaround was add with minus all dup packages. and made a little script to check duplicated packages ah I had test it with last rpm-4.4.2.2-2.fc7 and yum-3.2.7-1.fc7 from F7 , and pungi pungi-1.1.5-1.fc8 Thanks, -------------- next part -------------- # Kickstart file for composing the "Fedora" spin of Fedora 8 # Use a part of 'iso' to define how large you want your isos. # Only used when composing to more than one iso. #part iso --size=4998 repo --name=Fedora7 --baseurl=ftp://ftp.di.uminho.pt/pub/fedora/core/7/Everything/i386/os/ # http://ftp.fc.up.pt/Mirrors/fedora/linux/releases/7/Everything/i386/os/ repo --name=Fedora7Updates --baseurl=ftp://ftp.di.uminho.pt/pub/fedora/core/updates/7/i386 # http://ftp.di.uminho.pt/pub/fedora/core/updates/7/i386 # http://ftp.fc.up.pt/Mirrors/fedora/linux/updates/7/i386 repo --name=LivnaFedoraBase --baseurl=ftp://ftp.di.uminho.pt/pub/fedora/livna/fedora/7/i386/ # http://rpm.livna.org/fedora/7/i386/ # http://livna-dl.reloumirrors.net/fedora/7/i386/ # Add the repos you wish to use to compose here. At least one of them needs group data. #repo --name=rawhide --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch #repo --name=rawhide-source --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide-source&arch=$basearch # Package manifest for the compose. Uses repo group metadata to translate groups. # (@base is added by default unless you add --nobase to %packages) %packages * -pm-utils-0.99.3 -firefox-2.0.0.3 -kdepim-3.5.6 -compat-libosip2-devel-2.2.2-12.fc7 -compat-libosip2-2.2.2-12 -dbmail-2.2.4 -dbmail-mysql-2.2.4 -dbmail-pgsql-2.2.4 #-dbmail-sqlite-2.2.4 -koffice-1.6.2 -koffice-karbon-1.6.2 -koffice-kivio-1.6.2 -koffice-kspread-1.6.2 -koffice-libs-1.6.2 -DevIL-1.6.8-0.11.rc2.fc7 -kdebindings-3.5.6 -kdemultimedia-extras-3.5.6 -libgeda-20070216 -libgeda-doc-20070216 -metacity-2.18.0 -metacity-devel-2.18.0 -mod_perl-2.0.3-7 -mod_perl-devel-2.0.3-7 -mrtg-2.15.1-1 -ntfsprogs-1.13.1-3.fc6 -ntfsprogs-devel-1.13.1-3.fc6 -OpenSceneGraph-1.2-2.fc7 -pcb-0.20060822-9.fc7 #-pcb-doc-0.20060822-9.fc7 -perl-Class-DBI-Loader-Relationship-1.3-3.fc6 -perl-Email-MIME-Creator-1.453-1.fc7 -perl-Email-Simple-Creator-1.420-2.fc7 -system-switch-java-1.0.0 -pdflib-lite-7.0.1 #%end -------------- next part -------------- A non-text attachment was scrubbed... Name: checkpackages.sh Type: application/x-shellscript Size: 294 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From Michael_E_Brown at dell.com Tue Oct 30 18:19:01 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Tue, 30 Oct 2007 13:19:01 -0500 Subject: Makefile.common patch to remove deprecated mock syntax Message-ID: <20071030181900.GA21890@humbolt.us.dell.com> Attached is a small patch against makefile.common to remove use of deprecated mock syntax. This will work with both old mock (0.7.x) and new mock (0.8.x). -- dont specify '.cfg' in mock config -- specify 'rebuild' cmdline arg Tested by doing a 'make mockbuild' of mock. -- Michael -------------- next part -------------- ? makefile-common.patch ? mock-0.8.2.tar.gz ? mock-0.8.3.tar.gz ? mock-0.8.4.tar.gz ? mock.spec ? F-7/clog ? F-8/clog ? devel/clog Index: common/Makefile.common =================================================================== RCS file: /cvs/extras/common/Makefile.common,v retrieving revision 1.79 diff -u -r1.79 Makefile.common --- common/Makefile.common 23 Oct 2007 13:37:10 -0000 1.79 +++ common/Makefile.common 30 Oct 2007 18:15:03 -0000 @@ -49,22 +49,22 @@ MOCKDIR ?= $(WORKDIR) ifeq ($(DISTVAR),epel) DISTVAR := rhel -MOCKCFG ?= fedora-$(DISTVAL)-$(BUILDARCH)-epel.cfg +MOCKCFG ?= fedora-$(DISTVAL)-$(BUILDARCH)-epel else -MOCKCFG ?= fedora-$(DISTVAL)-$(BUILDARCH).cfg +MOCKCFG ?= fedora-$(DISTVAL)-$(BUILDARCH) ## 4, 5, 6 need -core ifeq ($(DISTVAL),4) -MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core.cfg +MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core endif ifeq ($(DISTVAL),5) -MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core.cfg +MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core endif ifeq ($(DISTVAL),6) -MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core.cfg +MOCKCFG = fedora-$(DISTVAL)-$(BUILDARCH)-core endif ## Devel builds use -devel mock config ifeq ($(BRANCH),devel) -MOCKCFG = fedora-devel-$(BUILDARCH).cfg +MOCKCFG = fedora-devel-$(BUILDARCH) endif endif @@ -301,7 +301,7 @@ # test build in mock mockbuild : srpm - mock $(MOCKARGS) -r $(MOCKCFG) --resultdir=$(MOCKDIR)/$(TAG) $(SRCRPMDIR)/$(NAME)-$(VERSION)-$(RELEASE).src.rpm + mock $(MOCKARGS) -r $(MOCKCFG) --resultdir=$(MOCKDIR)/$(TAG) rebuild $(SRCRPMDIR)/$(NAME)-$(VERSION)-$(RELEASE).src.rpm # build for a particular arch $(ARCHES) : sources $(TARGETS) From Michael_E_Brown at dell.com Wed Oct 31 06:25:13 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 31 Oct 2007 01:25:13 -0500 Subject: query: mock + libselinux-mock.so LD_PRELOAD... why? Message-ID: <20071031062512.GB2487@humbolt.us.dell.com> I need a little bit of help understanding what the 'libselinux-mock.so' LD_PRELOAD was supposed to be doing. I released and pushed out mock-0.8 without this. I have rebuilt most of rawhide with this new mock version and have not seen anything that I directly can say was a failure due to this being missing, so I am sort of not seeing the point. I have searched around as much as I can to try to understand why this was put into place. From what I can understand, it was only put in in the FC2 timeframe to fix some problems with the selinux policy on the host machine. These *appear* to have been fixed in the host selinux policy, so again, i dont see a reason to keep this around. Jesse mentioned on IRC, though, that this might be needed, so I pose this question. I've a local branch set up with the 0.8.x code and the LD_PRELOAD put back in. So, I can quickly spin a new release with this back in if it is actually needed. So far, I havent convinced myself it is needed, though... Could somebody please enlighten me? -- Michael