From kanarip at kanarip.com Wed Apr 16 16:17:44 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 16 Apr 2008 18:17:44 +0200 Subject: Mock / Koji issues on EL5 Message-ID: <480626A8.9090301@kanarip.com> Hello there, I was about to send this mail about all kinds of errors I had not seen before, until I somehow ended up screwing around in the code and fixed like 6 things that I did wrong. Still one minor thing though: On a CentOS 5, up-to-date box, I am running mock-0.9.7-1.el5, and koji-1.1-2.el5. I could not update to koji-1.2.3-1.el5 because it has a missing dependency on createrepo >= 0.4.11. When using the following command (or submitting the build through koji): mock --configdir=/etc/mock/koji -v -r dist-el5-build-3-3 rebuild ~/rpmbuild/SRPMS/revisor-2.1.0-1rc5.src.rpm The macros koji writes out in it's mock configuration file is a string, while mock expects a dict. I think this change made it in koji-1.2.3-1.el5, but for now... I changed line 62 in mock/backend.py from: self.macros = config['macros'] into: self.macros = {} if isinstance(config['macros'], str): _macros = config['macros'].split('\n') while len(_macros) > 0: (key, value) = _macros.pop(0).split(' ') self.macros[key] = value else: self.macros = config['macros'] I hope this helps others on el5 running into this problem. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Apr 16 17:51:58 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Apr 2008 13:51:58 -0400 Subject: Mock / Koji issues on EL5 In-Reply-To: <480626A8.9090301@kanarip.com> References: <480626A8.9090301@kanarip.com> Message-ID: <1208368318.4291.18.camel@localhost.localdomain> On Wed, 2008-04-16 at 18:17 +0200, Jeroen van Meeuwen wrote: > On a CentOS 5, up-to-date box, I am running mock-0.9.7-1.el5, and > koji-1.1-2.el5. I could not update to koji-1.2.3-1.el5 because it has a > missing dependency on createrepo >= 0.4.11. The version of createrepo you need is available as a "fastrack" rhel 5 update. I'm not sure if CentOS does anything with those, but that version of createrepo will be in RHEL 5.2. You really really need to be running koji 1.2.3 on RHEL/CentOS5 -- 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: 197 bytes Desc: This is a digitally signed message part URL: From oliver at linux-kernel.at Wed Apr 16 18:24:33 2008 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 16 Apr 2008 20:24:33 +0200 Subject: Mock / Koji issues on EL5 In-Reply-To: <1208368318.4291.18.camel@localhost.localdomain> References: <480626A8.9090301@kanarip.com> <1208368318.4291.18.camel@localhost.localdomain> Message-ID: <48064461.5070303@linux-kernel.at> Jesse Keating schrieb: > On Wed, 2008-04-16 at 18:17 +0200, Jeroen van Meeuwen wrote: >> On a CentOS 5, up-to-date box, I am running mock-0.9.7-1.el5, and >> koji-1.1-2.el5. I could not update to koji-1.2.3-1.el5 because it has a >> missing dependency on createrepo >= 0.4.11. > > The version of createrepo you need is available as a "fastrack" rhel 5 > update. I'm not sure if CentOS does anything with those, but that > version of createrepo will be in RHEL 5.2. You really really need to be > running koji 1.2.3 on RHEL/CentOS5 Confirmed. Even if I do no longer run Koji on RHEL5, since I left the company, where I used to do so, I know this is true :-) -of From kanarip at kanarip.com Wed Apr 16 21:37:10 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 16 Apr 2008 23:37:10 +0200 Subject: Mock / Koji issues on EL5 In-Reply-To: <48064461.5070303@linux-kernel.at> References: <480626A8.9090301@kanarip.com> <1208368318.4291.18.camel@localhost.localdomain> <48064461.5070303@linux-kernel.at> Message-ID: <48067186.1010307@kanarip.com> Oliver Falk wrote: > Jesse Keating schrieb: >> On Wed, 2008-04-16 at 18:17 +0200, Jeroen van Meeuwen wrote: >>> On a CentOS 5, up-to-date box, I am running mock-0.9.7-1.el5, and >>> koji-1.1-2.el5. I could not update to koji-1.2.3-1.el5 because it has >>> a missing dependency on createrepo >= 0.4.11. >> >> The version of createrepo you need is available as a "fastrack" rhel 5 >> update. I'm not sure if CentOS does anything with those, but that >> version of createrepo will be in RHEL 5.2. You really really need to be >> running koji 1.2.3 on RHEL/CentOS5 > > Confirmed. Even if I do no longer run Koji on RHEL5, since I left the > company, where I used to do so, I know this is true :-) > That's cool, although I did get it to work finally, I'll probably be experiencing some other problems when I start using it seriously; I'll be pulling in createrepo from "fasttrack" RHEL 5 or wait for the package to land in 5.2. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Apr 16 21:50:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 16 Apr 2008 17:50:19 -0400 Subject: Mock / Koji issues on EL5 In-Reply-To: <48067186.1010307@kanarip.com> References: <480626A8.9090301@kanarip.com> <1208368318.4291.18.camel@localhost.localdomain> <48064461.5070303@linux-kernel.at> <48067186.1010307@kanarip.com> Message-ID: <1208382619.4291.44.camel@localhost.localdomain> On Wed, 2008-04-16 at 23:37 +0200, Jeroen van Meeuwen wrote: > "fasttrack" For more fun and confusion, it's actually 'FasTrack' http://www.redhat.com/rhn/rhndetails/fastrack/ -- 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: 197 bytes Desc: This is a digitally signed message part URL: From kanarip at kanarip.com Wed Apr 16 22:03:28 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 17 Apr 2008 00:03:28 +0200 Subject: Mock / Koji issues on EL5 In-Reply-To: <1208382619.4291.44.camel@localhost.localdomain> References: <480626A8.9090301@kanarip.com> <1208368318.4291.18.camel@localhost.localdomain> <48064461.5070303@linux-kernel.at> <48067186.1010307@kanarip.com> <1208382619.4291.44.camel@localhost.localdomain> Message-ID: <480677B0.9060508@kanarip.com> Jesse Keating wrote: > On Wed, 2008-04-16 at 23:37 +0200, Jeroen van Meeuwen wrote: >> "fasttrack" > > For more fun and confusion, it's actually 'FasTrack' > http://www.redhat.com/rhn/rhndetails/fastrack/ > Yeah, I got it ;-) Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Thu Apr 17 10:50:41 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 17 Apr 2008 12:50:41 +0200 Subject: [patch] Require createrepo >= 0.4.11 Message-ID: <48072B81.3050408@kanarip.com> I found pungi does not require createrepo >= 0.4.11, although it needs that; attached is one of the smallest patches, ever ;-) Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: require-createrepo.patch Type: text/x-patch Size: 593 bytes Desc: not available URL: From jkeating at redhat.com Thu Apr 17 11:26:51 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 17 Apr 2008 07:26:51 -0400 Subject: [patch] Require createrepo >= 0.4.11 In-Reply-To: <48072B81.3050408@kanarip.com> References: <48072B81.3050408@kanarip.com> Message-ID: <1208431611.3235.17.camel@localhost.localdomain> On Thu, 2008-04-17 at 12:50 +0200, Jeroen van Meeuwen wrote: > I found pungi does not require createrepo >= 0.4.11, although it needs > that; attached is one of the smallest patches, ever ;-) Thanks, I've applied upstream. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From sergio at sergiomb.no-ip.org Fri Apr 18 22:56:59 2008 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Fri, 18 Apr 2008 23:56:59 +0100 Subject: [patch] Require createrepo >= 0.4.11 In-Reply-To: <1208431611.3235.17.camel@localhost.localdomain> References: <48072B81.3050408@kanarip.com> <1208431611.3235.17.camel@localhost.localdomain> Message-ID: <1208559419.26976.4.camel@segulix.localdomain> On Thu, 2008-04-17 at 07:26 -0400, Jesse Keating wrote: > On Thu, 2008-04-17 at 12:50 +0200, Jeroen van Meeuwen wrote: > > I found pungi does not require createrepo >= 0.4.11, although it needs > > that; attached is one of the smallest patches, ever ;-) > > Thanks, I've applied upstream. and pypungi._doRunCommand(repoview, self.logger) shouldn't stop the building on error. on /usr/lib/python2.5/site-packages/pypungi/pungi.py # setup the repoview call I build isos with livna repo. And repoview give some errors but those errors shouln't stop the building . Thanks, -- S?rgio M. B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2192 bytes Desc: not available URL: From markmc at redhat.com Mon Apr 21 08:35:29 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 21 Apr 2008 09:35:29 +0100 Subject: [PATCH] Add anaconda-runtime to the package list for buildinstall Message-ID: <1208766929-19553-1-git-send-email-markmc@redhat.com> With e.g.: repo --name=rawhide --baseurl=http://foo %packages %end You get: OSError: Got an error from /usr/lib/anaconda-runtime/buildinstall: and trying out the buildinstall command directly, you see: Running buildinstall... No Match for argument anaconda-runtime Nothing to download The issue here is that one of the first things buildinstall tries to do is install anaconda-runtime from the supplied repository, so the user must add anaconda-runtime to the package list or pungi fails. Automatically add it to the package list rather than requiring the user to do it. Signed-off-by: Mark McLoughlin --- src/bin/pungi.py | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/bin/pungi.py b/src/bin/pungi.py index 91ca403..bcbe6fd 100755 --- a/src/bin/pungi.py +++ b/src/bin/pungi.py @@ -77,6 +77,10 @@ def main(): # Actually do work. if not opts.sourceisos: + if opts.do_all or opts.do_buildinstall: + # buildinstall requires anaconda-runtime (rh #443371) + ksparser.handler.packages.add(["anaconda-runtime"]) + if opts.do_all or opts.do_gather: mygather = pypungi.gather.Gather(config, ksparser) mygather.getPackageObjects() -- 1.5.4.5 From kanarip at kanarip.com Mon Apr 21 08:54:13 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 21 Apr 2008 10:54:13 +0200 Subject: [PATCH] Add anaconda-runtime to the package list for buildinstall In-Reply-To: <1208766929-19553-1-git-send-email-markmc@redhat.com> References: <1208766929-19553-1-git-send-email-markmc@redhat.com> Message-ID: <480C5635.5050605@kanarip.com> Mark McLoughlin wrote: > With e.g.: > > repo --name=rawhide --baseurl=http://foo > > %packages > %end > > You get: > > OSError: Got an error from /usr/lib/anaconda-runtime/buildinstall: > > and trying out the buildinstall command directly, you see: > > Running buildinstall... > No Match for argument anaconda-runtime > Nothing to download > > The issue here is that one of the first things buildinstall > tries to do is install anaconda-runtime from the supplied > repository, so the user must add anaconda-runtime to the > package list or pungi fails. > > Automatically add it to the package list rather than > requiring the user to do it. > Because pungi doesn't pull in *any* "required" packages, I was reluctant to submit this patch... It seems that once you go down this road you will want to catch *all* required packages, like we do in Revisor (and creates a very, very long list[1]). Kind regards, Jeroen van Meeuwen -kanarip [1] http://git.fedorahosted.org/git/?p=revisor;a=blob;f=revisor/cfg.py#l1165 -------------- next part -------------- A non-text attachment was scrubbed... Name: force-anaconda-runtime-into-package-set.patch Type: text/x-patch Size: 662 bytes Desc: not available URL: From jkeating at redhat.com Mon Apr 21 11:12:04 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Apr 2008 07:12:04 -0400 Subject: [PATCH] Add anaconda-runtime to the package list for buildinstall In-Reply-To: <480C5635.5050605@kanarip.com> References: <1208766929-19553-1-git-send-email-markmc@redhat.com> <480C5635.5050605@kanarip.com> Message-ID: <1208776324.3445.133.camel@localhost.localdomain> On Mon, 2008-04-21 at 10:54 +0200, Jeroen van Meeuwen wrote: > > Because pungi doesn't pull in *any* "required" packages, I was reluctant > to submit this patch... It seems that once you go down this road you > will want to catch *all* required packages, like we do in Revisor (and > creates a very, very long list[1]). Yep. I'll be fixing this proper after F9 goes out by removing the dependency of having these compose needs in the manifest. It'll allow fully graphical installers for tiny package sets too. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From kanarip at kanarip.com Mon Apr 21 11:44:26 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 21 Apr 2008 13:44:26 +0200 Subject: [PATCH] Add anaconda-runtime to the package list for buildinstall In-Reply-To: <1208776324.3445.133.camel@localhost.localdomain> References: <1208766929-19553-1-git-send-email-markmc@redhat.com> <480C5635.5050605@kanarip.com> <1208776324.3445.133.camel@localhost.localdomain> Message-ID: <480C7E1A.9060509@kanarip.com> Jesse Keating wrote: > On Mon, 2008-04-21 at 10:54 +0200, Jeroen van Meeuwen wrote: >> Because pungi doesn't pull in *any* "required" packages, I was reluctant >> to submit this patch... It seems that once you go down this road you >> will want to catch *all* required packages, like we do in Revisor (and >> creates a very, very long list[1]). > > Yep. I'll be fixing this proper after F9 goes out by removing the > dependency of having these compose needs in the manifest. It'll allow > fully graphical installers for tiny package sets too. > I might be looking at doing the same -given that I may misunderstand what you're going to do. Does look similar to: 1. Pull in the requested packages (depsolve, etc) to become the final payload, 2. Create another repo with the required packages and pull in the required packages as well as their dependencies, build the installer images with the joined repo configuration, 3. Delete all overhead Or were you thinking something else? Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Mon Apr 21 13:48:17 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 21 Apr 2008 09:48:17 -0400 Subject: [PATCH] Add anaconda-runtime to the package list for buildinstall In-Reply-To: <480C7E1A.9060509@kanarip.com> References: <1208766929-19553-1-git-send-email-markmc@redhat.com> <480C5635.5050605@kanarip.com> <1208776324.3445.133.camel@localhost.localdomain> <480C7E1A.9060509@kanarip.com> Message-ID: <1208785697.3258.5.camel@localhost.localdomain> On Mon, 2008-04-21 at 13:44 +0200, Jeroen van Meeuwen wrote: > Or were you thinking something else? I was. buildinstall recently changed how it works. You no longer point it at a directory of packages, you point it at a yum repo. You can also have it output to a different directory. So my plan, which will take some modification to createrepo (Seth is already aware of this and has it planned), is to use pungi to wire up all the repos configured in the kickstart file and generate a "reference" repo. This repo would be "local" to the file system, use a combined comps grouping (for all the repos that you wish to consider for groupdata (another change coming for pykickstart)), but the repodata itself would have hrefs to the packages locations in the other repos. You get local repodata without having to mirror all the packages. Buildinstall would be pointed at that repo, and it would download (insert caching dances here) the packages it needs in order to make install images. Then (well, still not sure of the step orders) pungi would use it's manifest to create the package trees and insert the produced images into the trees. That's the fairly rough overview. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From doug.chapman at hp.com Tue Apr 22 00:54:25 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Mon, 21 Apr 2008 20:54:25 -0400 Subject: koji clone-tag? Message-ID: <1208825665.15954.18.camel@athlon> We are working on building a beta release of our ia64 F9 bits. I have been digging through the wiki for general release engineering processes and found this: http://fedoraproject.org/wiki/ReleaseEngineering/SOP/FreezingRawhide?highlight=%28ReleaseEngineering/SOP/%29 which shows using the command: koji clone-tag dist-f8 f8-final however, I find that the clone-tag command does not actually exist. Was it replaced by something else? We are looking for a way to take the latest version of all packages and tag them with a tag which will be used to build the beta release. - Doug From mikeb at redhat.com Tue Apr 22 02:06:36 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 21 Apr 2008 22:06:36 -0400 Subject: koji clone-tag? In-Reply-To: <1208825665.15954.18.camel@athlon> References: <1208825665.15954.18.camel@athlon> Message-ID: <1208829996.29755.1.camel@localhost.localdomain> On Mon, 2008-04-21 at 20:54 -0400, Doug Chapman wrote: > We are working on building a beta release of our ia64 F9 bits. I have > been digging through the wiki for general release engineering processes > and found this: > > http://fedoraproject.org/wiki/ReleaseEngineering/SOP/FreezingRawhide?highlight=%28ReleaseEngineering/SOP/%29 > > > which shows using the command: > > koji clone-tag dist-f8 f8-final > > however, I find that the clone-tag command does not actually exist. Was > it replaced by something else? We are looking for a way to take the > latest version of all packages and tag them with a tag which will be > used to build the beta release. It does exist, what version of Koji are you using? It requires admin permissions, so it'll only show up in "koji help --admin". For usage, use "koji clone-tag --help". From doug.chapman at hp.com Tue Apr 22 02:18:23 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Mon, 21 Apr 2008 22:18:23 -0400 Subject: koji clone-tag? In-Reply-To: <1208829996.29755.1.camel@localhost.localdomain> References: <1208825665.15954.18.camel@athlon> <1208829996.29755.1.camel@localhost.localdomain> Message-ID: <1208830703.15954.22.camel@athlon> On Mon, 2008-04-21 at 22:06 -0400, Mike Bonnet wrote: > On Mon, 2008-04-21 at 20:54 -0400, Doug Chapman wrote: > > We are working on building a beta release of our ia64 F9 bits. I have > > been digging through the wiki for general release engineering processes > > and found this: > > > > http://fedoraproject.org/wiki/ReleaseEngineering/SOP/FreezingRawhide?highlight=%28ReleaseEngineering/SOP/%29 > > > > > > which shows using the command: > > > > koji clone-tag dist-f8 f8-final > > > > however, I find that the clone-tag command does not actually exist. Was > > it replaced by something else? We are looking for a way to take the > > latest version of all packages and tag them with a tag which will be > > used to build the beta release. > > It does exist, what version of Koji are you using? It requires admin > permissions, so it'll only show up in "koji help --admin". For usage, > use "koji clone-tag --help". > Ok, appears I have an old version of koji which is odd because I did do a "yum update koji" but evidently we don't have this version in the f8 repos right now. I will grab the latest rawhide koji and try that. thanks, - Doug From notting at redhat.com Tue Apr 22 02:19:40 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Apr 2008 22:19:40 -0400 Subject: fun with CVS branching Message-ID: <20080422021940.GA23425@nostromo.devel.redhat.com> Two things from this mass branching that showed up: 1) Something weird happened, and all the modules entries pw*-z got deleted from the modules file halfway through. We get to try and put them back. Um, yay? 2) The modules file, *as it stands now*, is nearly 3MB checked out, and nearly *1.2GB* under RCS. That can't be good. The reason for this is to allow for the creation of pseudo-modules for each 'branch', i.e., so 'cvs co FC-5' generates a: FC-5/bash FC-5/automake FC-5/autoconf ... tree, where the FC-5/ directory is the 'normal' /FC-5 dir. (Note that the 'devel' meta-branch is done in an Entirely Different manner.) So, the question would be... is this worth it? Do we want to keep supporting this? Bill From tibbs at math.uh.edu Tue Apr 22 02:35:01 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Apr 2008 21:35:01 -0500 Subject: fun with CVS branching In-Reply-To: <20080422021940.GA23425@nostromo.devel.redhat.com> References: <20080422021940.GA23425@nostromo.devel.redhat.com> Message-ID: >>>>> "BN" == Bill Nottingham writes: BN> So, the question would be... is this worth it? Do we want to keep BN> supporting this? I can't see how it's all that useful. And given that this is the kind of weirdness that's going to be difficult to emulate using some other version control system, getting rid of it now could make it easier to switch to something else in the future. - J< From a.badger at gmail.com Tue Apr 22 03:15:18 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 21 Apr 2008 20:15:18 -0700 Subject: fun with CVS branching In-Reply-To: <20080422021940.GA23425@nostromo.devel.redhat.com> References: <20080422021940.GA23425@nostromo.devel.redhat.com> Message-ID: <480D5846.70802@gmail.com> Bill Nottingham wrote: > Two things from this mass branching that showed up: > > 1) Something weird happened, and all the modules entries pw*-z > got deleted from the modules file halfway through. We get to try > and put them back. Um, yay? > > 2) The modules file, *as it stands now*, is nearly 3MB checked out, > and nearly *1.2GB* under RCS. That can't be good. > > The reason for this is to allow for the creation of pseudo-modules > for each 'branch', i.e., so 'cvs co FC-5' generates a: > > FC-5/bash > FC-5/automake > FC-5/autoconf > ... > > tree, where the FC-5/ directory is the 'normal' /FC-5 > dir. > > (Note that the 'devel' meta-branch is done in an Entirely Different > manner.) > > So, the question would be... is this worth it? Do we want to keep > supporting this? > I'd say no but I've never used this feature at all. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From ivazqueznet at gmail.com Tue Apr 22 05:48:48 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 22 Apr 2008 01:48:48 -0400 Subject: fun with CVS branching In-Reply-To: <20080422021940.GA23425@nostromo.devel.redhat.com> References: <20080422021940.GA23425@nostromo.devel.redhat.com> Message-ID: <1208843328.13044.4.camel@ignacio.lan> On Mon, 2008-04-21 at 22:19 -0400, Bill Nottingham wrote: > So, the question would be... is this worth it? Do we want to keep > supporting this? Is the fact that you can check out e.g. "FC-5" even *documented* anywhere? I don't recall having come across it, but then again I am a skimmer. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Christian.Iseli at unil.ch Tue Apr 22 06:42:10 2008 From: Christian.Iseli at unil.ch (Christian Iseli) Date: Tue, 22 Apr 2008 08:42:10 +0200 Subject: fun with CVS branching In-Reply-To: References: <20080422021940.GA23425@nostromo.devel.redhat.com> Message-ID: <20080422084210.56fd6224@ludwig-alpha.unil.ch> On 21 Apr 2008 21:35:01 -0500, Jason L Tibbitts III wrote: > >>>>> "BN" == Bill Nottingham writes: > > BN> So, the question would be... is this worth it? Do we want to keep > BN> supporting this? > > I can't see how it's all that useful. And given that this is the kind > of weirdness that's going to be difficult to emulate using some other > version control system, getting rid of it now could make it easier to > switch to something else in the future. Agreed. Take it out back and... Cheers, Christian From bugs.michael at gmx.net Tue Apr 22 09:59:29 2008 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 22 Apr 2008 11:59:29 +0200 Subject: fun with CVS branching In-Reply-To: <1208843328.13044.4.camel@ignacio.lan> References: <20080422021940.GA23425@nostromo.devel.redhat.com> <1208843328.13044.4.camel@ignacio.lan> Message-ID: <20080422115929.d10f831f.bugs.michael@gmx.net> On Tue, 22 Apr 2008 01:48:48 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2008-04-21 at 22:19 -0400, Bill Nottingham wrote: > > So, the question would be... is this worth it? Do we want to keep > > supporting this? > > Is the fact that you can check out e.g. "FC-5" even *documented* > anywhere? I don't recall having come across it, but then again I am a > skimmer. The generic "cvs co BRANCH" was documented and used during the FE era. It's a matter of convenience. It was quick access to a specific branch without the need to filter package branch dirs [with a little bit extra work in scripts]. But all I remember is that the modules file was broken often and needed fixes before a full branch could be checked out. Nowadays, cvs contents are so huge, one better avoids checking out complete branches. One is better of to download the seed file and up from there. From jkeating at redhat.com Tue Apr 22 14:02:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Apr 2008 10:02:21 -0400 Subject: fun with CVS branching In-Reply-To: <20080422021940.GA23425@nostromo.devel.redhat.com> References: <20080422021940.GA23425@nostromo.devel.redhat.com> Message-ID: <1208872941.3258.94.camel@localhost.localdomain> On Mon, 2008-04-21 at 22:19 -0400, Bill Nottingham wrote: > 1) Something weird happened, and all the modules entries pw*-z > got deleted from the modules file halfway through. We get to try > and put them back. Um, yay? The branching is done now, any smooth thoughts on how to recover this before I turn CVS commits back on? > > 2) The modules file, *as it stands now*, is nearly 3MB checked out, > and nearly *1.2GB* under RCS. That can't be good. > > The reason for this is to allow for the creation of pseudo-modules > for each 'branch', i.e., so 'cvs co FC-5' generates a: > > FC-5/bash > FC-5/automake > FC-5/autoconf > ... > > tree, where the FC-5/ directory is the 'normal' > /FC-5 > dir. > > (Note that the 'devel' meta-branch is done in an Entirely Different > manner.) > > So, the question would be... is this worth it? Do we want to keep > supporting this? No, get rid of 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: 197 bytes Desc: This is a digitally signed message part URL: From mikem at redhat.com Tue Apr 22 15:18:44 2008 From: mikem at redhat.com (Mike McLean) Date: Tue, 22 Apr 2008 11:18:44 -0400 Subject: koji clone-tag? In-Reply-To: <1208830703.15954.22.camel@athlon> References: <1208825665.15954.18.camel@athlon> <1208829996.29755.1.camel@localhost.localdomain> <1208830703.15954.22.camel@athlon> Message-ID: <480E01D4.8030005@redhat.com> Doug Chapman wrote: > Ok, appears I have an old version of koji which is odd because I did do > a "yum update koji" but evidently we don't have this version in the f8 > repos right now. I will grab the latest rawhide koji and try that. Odd. the clone-tag command was added on 2007-07-23. Git has several fc8 tags, but I don't see matching builds on koji.fp.o. From jkeating at redhat.com Tue Apr 22 15:21:02 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Apr 2008 11:21:02 -0400 Subject: koji clone-tag? In-Reply-To: <480E01D4.8030005@redhat.com> References: <1208825665.15954.18.camel@athlon> <1208829996.29755.1.camel@localhost.localdomain> <1208830703.15954.22.camel@athlon> <480E01D4.8030005@redhat.com> Message-ID: <1208877662.3258.101.camel@localhost.localdomain> On Tue, 2008-04-22 at 11:18 -0400, Mike McLean wrote: > Doug Chapman wrote: > > Ok, appears I have an old version of koji which is odd because I did do > > a "yum update koji" but evidently we don't have this version in the f8 > > repos right now. I will grab the latest rawhide koji and try that. > > Odd. the clone-tag command was added on 2007-07-23. Git has several fc8 > tags, but I don't see matching builds on koji.fp.o. I don't know if I've pushed any koji updates for F-8 since the server side of things changed a lot and may not work with current F-8 toolings. Given that the client is tied to the server it makes it rather hard to do client updates. -- 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: 197 bytes Desc: This is a digitally signed message part URL: From mikem at redhat.com Tue Apr 22 20:30:21 2008 From: mikem at redhat.com (Mike McLean) Date: Tue, 22 Apr 2008 16:30:21 -0400 Subject: koji clone-tag? In-Reply-To: <1208877662.3258.101.camel@localhost.localdomain> References: <1208825665.15954.18.camel@athlon> <1208829996.29755.1.camel@localhost.localdomain> <1208830703.15954.22.camel@athlon> <480E01D4.8030005@redhat.com> <1208877662.3258.101.camel@localhost.localdomain> Message-ID: <480E4ADD.70500@redhat.com> Jesse Keating wrote: > I don't know if I've pushed any koji updates for F-8 since the server > side of things changed a lot and may not work with current F-8 toolings. > Given that the client is tied to the server it makes it rather hard to > do client updates. I'm pretty sure the F8 updates are sufficient to run koji. I've had an F8 system running koji development code (hub, client, builder, and kojira) for a while now. $ koji latest-pkg --quiet dist-f8-updates mock yum createrepo python-krbV mock-0.9.7-2.fc8 dist-f8-updates jcwillia yum-3.2.8-2.fc8 dist-f8-updates skvidal createrepo-0.4.11-2.fc8 dist-f8-updates lmacken python-krbV-1.0.13-6.fc8 dist-f8 mikeb Well, ok, I'm cheating a little bit. I previously had to make skip-stat optional in kojid (change committed on the shadow branch), but that appears to no longer be necessary since createrepo-0.4.11-2.fc8 has the skip-stat patch. http://koji.fedoraproject.org/koji/buildinfo?buildID=32381 From jkeating at redhat.com Tue Apr 22 20:31:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 22 Apr 2008 16:31:00 -0400 Subject: koji clone-tag? In-Reply-To: <480E4ADD.70500@redhat.com> References: <1208825665.15954.18.camel@athlon> <1208829996.29755.1.camel@localhost.localdomain> <1208830703.15954.22.camel@athlon> <480E01D4.8030005@redhat.com> <1208877662.3258.101.camel@localhost.localdomain> <480E4ADD.70500@redhat.com> Message-ID: <1208896261.3258.134.camel@localhost.localdomain> On Tue, 2008-04-22 at 16:30 -0400, Mike McLean wrote: > I'm pretty sure the F8 updates are sufficient to run koji. I've had an > F8 system running koji development code (hub, client, builder, and > kojira) for a while now. > > $ koji latest-pkg --quiet dist-f8-updates mock yum createrepo python-krbV > mock-0.9.7-2.fc8 dist-f8-updates jcwillia > yum-3.2.8-2.fc8 dist-f8-updates skvidal > createrepo-0.4.11-2.fc8 dist-f8-updates lmacken > python-krbV-1.0.13-6.fc8 dist-f8 mikeb > > Well, ok, I'm cheating a little bit. I previously had to make skip-stat > optional in kojid (change committed on the shadow branch), but that > appears to no longer be necessary since createrepo-0.4.11-2.fc8 has the > skip-stat patch. > > http://koji.fedoraproject.org/koji/buildinfo?buildID=32381 Gotcha, now that everything is almost in sync, it would be a good time to do another upstream release and push it to F8 as well. -- Jesse Keating Fedora -- Freedom? is a feature! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dennis at ausil.us Thu Apr 24 02:44:38 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 23 Apr 2008 21:44:38 -0500 Subject: Makefile.common change Message-ID: <200804232145.01760.dennis@ausil.us> The way we currently check for branches is broken at release time. everything that was tagged in devel that was branched for F-9 when you try and build in koji gets a disttag of .fc10 and fails to build due to a mismatch. this has been a minor issue in the past. but it is a big issue for secondary arch rampup. Makefile.common checked for the existence of a branch file which devel does not have. it is added at branch time. long term we probably need to add some logic so that we always have a branch file and check it and fall back to this method if its not there. it will help with always being able to reproduce a srpm. Since this is somewhat invasive i wanted to run it by people first. it worked ok in my testing. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.common.branch Type: text/x-makefile Size: 651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From notting at redhat.com Thu Apr 24 03:06:49 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Apr 2008 23:06:49 -0400 Subject: Makefile.common change In-Reply-To: <200804232145.01760.dennis@ausil.us> References: <200804232145.01760.dennis@ausil.us> Message-ID: <20080424030649.GC26790@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > ? Makefile.common.branch > Index: Makefile.common > =================================================================== > RCS file: /cvs/pkgs/common/Makefile.common,v > retrieving revision 1.94 > diff -u -r1.94 Makefile.common > --- Makefile.common 22 Apr 2008 15:44:53 -0000 1.94 > +++ Makefile.common 24 Apr 2008 02:30:13 -0000 > @@ -19,7 +19,7 @@ > ifndef HEAD_BRANCH > HEAD_BRANCH := devel > endif > -BRANCH:=$(shell [ -f branch ] && cat branch || echo $(HEAD_BRANCH)) > +BRANCH:=$(lastword $(shell pwd| cut -d/ --output-delimiter=" " -f2-)) > # check to see if this is an early branched package; we should make this more > # generic in the future > ifeq ($(BRANCH),devel) Seems good. Of course, there's 5000 ways to do it, with cut, awk, ${foo##*/}, etc. Bill From dennis at ausil.us Thu Apr 24 04:02:26 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 23 Apr 2008 23:02:26 -0500 Subject: Makefile.common change In-Reply-To: <20080424030649.GC26790@nostromo.devel.redhat.com> References: <200804232145.01760.dennis@ausil.us> <20080424030649.GC26790@nostromo.devel.redhat.com> Message-ID: <200804232302.35171.dennis@ausil.us> On Wednesday 23 April 2008, Bill Nottingham wrote: > Dennis Gilmore (dennis at ausil.us) said: > > ? Makefile.common.branch > > Index: Makefile.common > > =================================================================== > > RCS file: /cvs/pkgs/common/Makefile.common,v > > retrieving revision 1.94 > > diff -u -r1.94 Makefile.common > > --- Makefile.common 22 Apr 2008 15:44:53 -0000 1.94 > > +++ Makefile.common 24 Apr 2008 02:30:13 -0000 > > @@ -19,7 +19,7 @@ > > ifndef HEAD_BRANCH > > HEAD_BRANCH := devel > > endif > > -BRANCH:=$(shell [ -f branch ] && cat branch || echo $(HEAD_BRANCH)) > > +BRANCH:=$(lastword $(shell pwd| cut -d/ --output-delimiter=" " -f2-)) > > # check to see if this is an early branched package; we should make this > > more # generic in the future > > ifeq ($(BRANCH),devel) > > Seems good. Of course, there's 5000 ways to do it, with cut, awk, > ${foo##*/}, etc. Thanks ive applied Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From davej at redhat.com Thu Apr 24 11:39:15 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 24 Apr 2008 07:39:15 -0400 Subject: fun with CVS branching In-Reply-To: <20080422021940.GA23425@nostromo.devel.redhat.com> References: <20080422021940.GA23425@nostromo.devel.redhat.com> Message-ID: <20080424113915.GA28297@redhat.com> On Mon, Apr 21, 2008 at 10:19:40PM -0400, Bill Nottingham wrote: > Two things from this mass branching that showed up: > > 1) Something weird happened, and all the modules entries pw*-z > got deleted from the modules file halfway through. We get to try > and put them back. Um, yay? > > 2) The modules file, *as it stands now*, is nearly 3MB checked out, > and nearly *1.2GB* under RCS. That can't be good. > > The reason for this is to allow for the creation of pseudo-modules > for each 'branch', i.e., so 'cvs co FC-5' generates a: > > FC-5/bash > FC-5/automake > FC-5/autoconf > ... > > tree, where the FC-5/ directory is the 'normal' /FC-5 > dir. > > (Note that the 'devel' meta-branch is done in an Entirely Different > manner.) > > So, the question would be... is this worth it? Do we want to keep > supporting this? I find it handy to check out the entirity of devel/, but the older releases I couldn't care less about. I can't imagine why someone would want the entire package CVS of an older release unless they were looking for something tree-wide, which few peope are loony enough to want to do. Dave -- http://www.codemonkey.org.uk From orion at cora.nwra.com Thu Apr 24 15:43:02 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 24 Apr 2008 09:43:02 -0600 Subject: fun with CVS branching In-Reply-To: <20080424113915.GA28297@redhat.com> References: <20080422021940.GA23425@nostromo.devel.redhat.com> <20080424113915.GA28297@redhat.com> Message-ID: <4810AA86.8020601@cora.nwra.com> Dave Jones wrote: > On Mon, Apr 21, 2008 at 10:19:40PM -0400, Bill Nottingham wrote: > > So, the question would be... is this worth it? Do we want to keep > > supporting this? > > I find it handy to check out the entirity of devel/, but the older > releases I couldn't care less about. I'm with Dave here. I keep devel/ checked out so I can grep for BuildRequires and the like. I would really like to just be able to checkout all the spec files - don't care about the patches, etc. -- 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 notting at redhat.com Thu Apr 24 16:42:37 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Apr 2008 12:42:37 -0400 Subject: fun with CVS branching In-Reply-To: <4810AA86.8020601@cora.nwra.com> References: <20080422021940.GA23425@nostromo.devel.redhat.com> <20080424113915.GA28297@redhat.com> <4810AA86.8020601@cora.nwra.com> Message-ID: <20080424164237.GA5522@nostromo.devel.redhat.com> Orion Poplawski (orion at cora.nwra.com) said: >> I find it handy to check out the entirity of devel/, but the older >> releases I couldn't care less about. > > I'm with Dave here. I keep devel/ checked out so I can grep for > BuildRequires and the like. I would really like to just be able to > checkout all the spec files - don't care about the patches, etc. As stated in the original mail, 'devel' still works, as it's done in a different manner. Bill From doug.chapman at hp.com Thu Apr 24 17:29:49 2008 From: doug.chapman at hp.com (Doug Chapman) Date: Thu, 24 Apr 2008 13:29:49 -0400 Subject: arch specific packages pulled in by pungi Message-ID: <1209058189.10543.11.camel@dchapman.boston.redhat.com> When building an install image using pungi and the example rawhide- fedora.ks that is provided we found that elilo does not get pulled in on our ia64 builds. For those not familiar with ia64 elilo is the bootloader used instead of grub. What is the best way to fix this? For now we just added it to the rawhide-fedora.ks we are using but I am wondering if there is a more appropriate fix for packages like this that are required for boot. Since I don't see grub as part of the example rawhide-fedora.ks supplied with pungi I am wondering if there is some other mechanism pungi uses to know to pull packages like this in. If so that seems like the right way to handle elilo. This will also be an issue for x86 systems that boot with elilo. thanks, - Doug From katzj at redhat.com Thu Apr 24 18:10:13 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 24 Apr 2008 14:10:13 -0400 Subject: arch specific packages pulled in by pungi In-Reply-To: <1209058189.10543.11.camel@dchapman.boston.redhat.com> References: <1209058189.10543.11.camel@dchapman.boston.redhat.com> Message-ID: <1209060613.8821.37.camel@aglarond.local> On Thu, 2008-04-24 at 13:29 -0400, Doug Chapman wrote: > What is the best way to fix this? For now we just added it to the > rawhide-fedora.ks we are using but I am wondering if there is a more > appropriate fix for packages like this that are required for boot. > Since I don't see grub as part of the example rawhide-fedora.ks supplied > with pungi I am wondering if there is some other mechanism pungi uses to > know to pull packages like this in. If so that seems like the right way > to handle elilo. Generally, the package should be marked as default in comps. > This will also be an issue for x86 systems that boot with elilo. Really, we shouldn't be booting x86 systems with elilo, even if they are EFI based now that Peter has grub working with efi systems. In fact, we could even stop building it on x86 Jeremy From notting at redhat.com Thu Apr 24 18:17:54 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Apr 2008 14:17:54 -0400 Subject: arch specific packages pulled in by pungi In-Reply-To: <1209060613.8821.37.camel@aglarond.local> References: <1209058189.10543.11.camel@dchapman.boston.redhat.com> <1209060613.8821.37.camel@aglarond.local> Message-ID: <20080424181754.GB10943@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > > This will also be an issue for x86 systems that boot with elilo. > > Really, we shouldn't be booting x86 systems with elilo, even if they are > EFI based now that Peter has grub working with efi systems. In fact, we > could even stop building it on x86 What about grub+efi working on ia64, so we could stop building elilo entirely? Bill From katzj at redhat.com Thu Apr 24 18:24:14 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 24 Apr 2008 14:24:14 -0400 Subject: arch specific packages pulled in by pungi In-Reply-To: <20080424181754.GB10943@nostromo.devel.redhat.com> References: <1209058189.10543.11.camel@dchapman.boston.redhat.com> <1209060613.8821.37.camel@aglarond.local> <20080424181754.GB10943@nostromo.devel.redhat.com> Message-ID: <1209061454.8821.39.camel@aglarond.local> On Thu, 2008-04-24 at 14:17 -0400, Bill Nottingham wrote: > Jeremy Katz (katzj at redhat.com) said: > > > This will also be an issue for x86 systems that boot with elilo. > > > > Really, we shouldn't be booting x86 systems with elilo, even if they are > > EFI based now that Peter has grub working with efi systems. In fact, we > > could even stop building it on x86 > > What about grub+efi working on ia64, so we could stop building elilo > entirely? I think that's the idea, but not there yet Jeremy