From martin.langhoff at gmail.com Wed Sep 3 01:21:28 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 3 Sep 2008 13:21:28 +1200 Subject: Pungi kickstart packages - stage2 deps vs instaled pkgs Message-ID: <46a038f90809021821s356cd7e8y93fbd9ef9a80b6bb@mail.gmail.com> Perhaps this is by design: the "build tools" dependencies (anaconda-runtime an friends) which end up in stage2 AFAICS need to be listed (and their dependencies met) in the main packages listing in the kickstart file. Is there a way to control those package listings separately? As a (trivial) example, we end up with an anaconda-runtime rpm in the iso, which we are not interested in... cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From jkeating at redhat.com Wed Sep 3 06:38:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Sep 2008 23:38:59 -0700 Subject: Pungi kickstart packages - stage2 deps vs instaled pkgs In-Reply-To: <46a038f90809021821s356cd7e8y93fbd9ef9a80b6bb@mail.gmail.com> References: <46a038f90809021821s356cd7e8y93fbd9ef9a80b6bb@mail.gmail.com> Message-ID: <1220423939.2795.0.camel@luminos.localdomain> On Wed, 2008-09-03 at 13:21 +1200, Martin Langhoff wrote: > Perhaps this is by design: the "build tools" dependencies > (anaconda-runtime an friends) which end up in stage2 AFAICS need to be > listed (and their dependencies met) in the main packages listing in > the kickstart file. > > Is there a way to control those package listings separately? As a > (trivial) example, we end up with an anaconda-runtime rpm in the iso, > which we are not interested in... This isn't the case with rawhide pungi. The need to have anaconda in the manifest has been removed. It just has to be available in the repos you are composing against. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 martin.langhoff at gmail.com Wed Sep 3 06:46:09 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 3 Sep 2008 18:46:09 +1200 Subject: Pungi / anaconda: seeding the pkg selection Message-ID: <46a038f90809022346q6c15b450pb4aa6689a7a0a479@mail.gmail.com> The installer cd I'm trying to build (for the School Server) is driven by 2 custom packages - a metapackage that pulls in all the dependenciess, and a configuration package that whacks /etc . Feeding those to Pungi via a kickstart file gets them on the installer CD, but does not get them installed by default. My overall goals (and stumbling blocks) are: 1 - Support interactive installs (that defaults to installing the XS packages!) for developers & pilot sites. This should be the default on the grub menu... - How do get anaconda to pick those 2 custom packages by default? Using a kickstart file is not an option - it switches off the interactive install mode. Is anaconda auto-installing the 'base' group and should I add them there? Should I create a new group in comps.xml and get anaconda to have it selected by default? - How can I feed Pungi a custom comps.xml? 1.1 - The interactive install should have a custom 'default' layout for the autopartitioning. Can I seed that somehow? 2 - Support a fully automated kickstart install (non-default option in grub menu). This is also an example for local teams to edit to their needs... - Does Pungi support a %post that can "copy in" a new grub menu to the isolinux/syslinux directory? - ... and add a ks.cfg file to the initrd? - Will anaconda probe for ks.cfg in any directories that are easier to edit than the initrd? lots of questions :-/ cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Wed Sep 3 06:47:57 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 3 Sep 2008 18:47:57 +1200 Subject: Pungi kickstart packages - stage2 deps vs instaled pkgs In-Reply-To: <1220423939.2795.0.camel@luminos.localdomain> References: <46a038f90809021821s356cd7e8y93fbd9ef9a80b6bb@mail.gmail.com> <1220423939.2795.0.camel@luminos.localdomain> Message-ID: <46a038f90809022347x2407f8b0n92626d4b06dd2b1c@mail.gmail.com> On Wed, Sep 3, 2008 at 6:38 PM, Jesse Keating wrote: > This isn't the case with rawhide pungi. Great to hear that - sounds like it'll be nice to build small ISOs. Is the rawhide Pungi reasonably usable on F9? cheers. m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From skvidal at fedoraproject.org Wed Sep 3 07:03:22 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 03 Sep 2008 07:03:22 +0000 Subject: Pungi / anaconda: seeding the pkg selection In-Reply-To: <46a038f90809022346q6c15b450pb4aa6689a7a0a479@mail.gmail.com> References: <46a038f90809022346q6c15b450pb4aa6689a7a0a479@mail.gmail.com> Message-ID: <1220425402.8829.34.camel@rosebud> On Wed, 2008-09-03 at 18:46 +1200, Martin Langhoff wrote: > The installer cd I'm trying to build (for the School Server) is driven > by 2 custom packages - a metapackage that pulls in all the > dependenciess, and a configuration package that whacks /etc . > > Feeding those to Pungi via a kickstart file gets them on the installer > CD, but does not get them installed by default. My overall goals (and > stumbling blocks) are: > > 1 - Support interactive installs (that defaults to installing the XS > packages!) for developers & pilot sites. This should be the default on > the grub menu... > > - How do get anaconda to pick those 2 custom packages by default? > Using a kickstart file is not an option - it switches off the > interactive install mode. why not a kickstart with 'interactive' in the file: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s1-kickstart2-options.html Pretty sure it's in F9, too - I just found the rhel5 ks manual faster. -sv From martin.langhoff at gmail.com Wed Sep 3 07:12:48 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 3 Sep 2008 19:12:48 +1200 Subject: Pungi / anaconda: seeding the pkg selection In-Reply-To: <1220425402.8829.34.camel@rosebud> References: <46a038f90809022346q6c15b450pb4aa6689a7a0a479@mail.gmail.com> <1220425402.8829.34.camel@rosebud> Message-ID: <46a038f90809030012g70bbc561g279bbf12c649a340@mail.gmail.com> On Wed, Sep 3, 2008 at 7:03 PM, Seth Vidal wrote: > why not a kickstart with 'interactive' in the file: > http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s1-kickstart2-options.html Bah, too easy to be true -- ;-) Thanks a lot for the hint - I'll try it. Wonder whether it also does the "load defaults but work interactively" trick with the disk partitioner. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Wed Sep 3 09:42:04 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 03 Sep 2008 11:42:04 +0200 Subject: Pungi kickstart packages - stage2 deps vs instaled pkgs In-Reply-To: <46a038f90809022347x2407f8b0n92626d4b06dd2b1c@mail.gmail.com> References: <46a038f90809021821s356cd7e8y93fbd9ef9a80b6bb@mail.gmail.com> <1220423939.2795.0.camel@luminos.localdomain> <46a038f90809022347x2407f8b0n92626d4b06dd2b1c@mail.gmail.com> Message-ID: <48BE5BEC.3060703@kanarip.com> Martin Langhoff wrote: > On Wed, Sep 3, 2008 at 6:38 PM, Jesse Keating wrote: >> This isn't the case with rawhide pungi. > > Great to hear that - sounds like it'll be nice to build small ISOs. Is > the rawhide Pungi reasonably usable on F9? > I think not, because pungi uses the anaconda-runtime buildinstall script in /usr/lib/anaconda-runtime/buildinstall. However, if you install anaconda-runtime from rawhide on your Fedora 9 station (which should just work), then pungi from rawhide should be able to run on the Fedora 9 station. I don't think however it's supported in any way. In any case, Revisor can already do what you're looking for on Fedora 9 genuine. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Wed Sep 3 10:55:46 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 03 Sep 2008 12:55:46 +0200 Subject: Pungi / anaconda: seeding the pkg selection In-Reply-To: <46a038f90809030012g70bbc561g279bbf12c649a340@mail.gmail.com> References: <46a038f90809022346q6c15b450pb4aa6689a7a0a479@mail.gmail.com> <1220425402.8829.34.camel@rosebud> <46a038f90809030012g70bbc561g279bbf12c649a340@mail.gmail.com> Message-ID: <48BE6D32.7000108@kanarip.com> Martin Langhoff wrote: > On Wed, Sep 3, 2008 at 7:03 PM, Seth Vidal wrote: >> why not a kickstart with 'interactive' in the file: >> http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en-US/s1-kickstart2-options.html > > Bah, too easy to be true -- ;-) Thanks a lot for the hint - I'll try > it. Wonder whether it also does the "load defaults but work > interactively" trick with the disk partitioner. > IIRC, yes it does. Kind regards, Jeroen van Meeuwen -kanarip From dledford at redhat.com Wed Sep 3 14:48:28 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 03 Sep 2008 10:48:28 -0400 Subject: koji-1.2.6 In-Reply-To: <48B34015.7010407@redhat.com> References: <48B34015.7010407@redhat.com> Message-ID: <1220453309.32151.27.camel@firewall.xsintricity.com> On Mon, 2008-08-25 at 19:28 -0400, Mike McLean wrote: > It's been a long time since we posted a fresh tarball, so I just tagged > and posted 1.2.6. Following is a summary of changes since 1.2.5. A > couple of them /may/ cause some slight upgrade issues. Any idea when updated packages for koji will hit the shelves? -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- 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 Wed Sep 3 21:22:00 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 3 Sep 2008 16:22:00 -0500 Subject: koji-1.2.6 In-Reply-To: <1220453309.32151.27.camel@firewall.xsintricity.com> References: <48B34015.7010407@redhat.com> <1220453309.32151.27.camel@firewall.xsintricity.com> Message-ID: <200809031622.12608.dennis@ausil.us> On Wednesday 03 September 2008 09:48:28 am Doug Ledford wrote: > On Mon, 2008-08-25 at 19:28 -0400, Mike McLean wrote: > > It's been a long time since we posted a fresh tarball, so I just tagged > > and posted 1.2.6. Following is a summary of changes since 1.2.5. A > > couple of them /may/ cause some slight upgrade issues. > > Any idea when updated packages for koji will hit the shelves? as soon as updates go out. its in EPEL-testing and rawhide now. updates are queued for Fedora-8 and Fedora-9 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 martin.langhoff at gmail.com Wed Sep 3 22:25:32 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 4 Sep 2008 10:25:32 +1200 Subject: Pungi / anaconda: seeding the pkg selection In-Reply-To: <46a038f90809022346q6c15b450pb4aa6689a7a0a479@mail.gmail.com> References: <46a038f90809022346q6c15b450pb4aa6689a7a0a479@mail.gmail.com> Message-ID: <46a038f90809031525h67b92213l2eebe4820ac403ca@mail.gmail.com> On Wed, Sep 3, 2008 at 6:46 PM, Martin Langhoff > 1.1 - The interactive install should have a custom 'default' layout > for the autopartitioning. Can I seed that somehow? > > 2 - Support a fully automated kickstart install (non-default option > in grub menu). This is also an example for local teams to edit to > their needs... > > - Does Pungi support a %post that can "copy in" a new grub menu to > the isolinux/syslinux directory? > - ... and add a ks.cfg file to the initrd? So I guess this is the question that remains - how to feed a ks file to Pungi. Google only finds discussions about the F7 Pungi (which could not do it), and in looking at the src I can't see any references to %post. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Thu Sep 4 05:01:09 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 4 Sep 2008 17:01:09 +1200 Subject: Pungi kickstart packages - stage2 deps vs instaled pkgs In-Reply-To: <48BE5BEC.3060703@kanarip.com> References: <46a038f90809021821s356cd7e8y93fbd9ef9a80b6bb@mail.gmail.com> <1220423939.2795.0.camel@luminos.localdomain> <46a038f90809022347x2407f8b0n92626d4b06dd2b1c@mail.gmail.com> <48BE5BEC.3060703@kanarip.com> Message-ID: <46a038f90809032201o448a975cqa3842537d8d16bea@mail.gmail.com> On Wed, Sep 3, 2008 at 9:42 PM, Jeroen van Meeuwen wrote: > In any case, Revisor can already do what you're looking for on Fedora 9 > genuine. Cool. I've spent a good part of today playing with your good Revisor. I have a few questions, hopefully not too OT for fedora-buildsys (the links to the revisor lists on https://fedorahosted.org/revisor/wiki/Troubleshooting#Troubleshooting seem to be dead, or the server down). - Trying to build f9-i386 leads to dep errors -- only if I leave fedora-updates enabled. The error is: Missing Dependency: glibc-common = 2.8-3 is needed by package glibc-2.8-3.i386 (fedora) - I am adding a metapackage that pulls in beecrypt. But I get depresolv errors about beecrypt -- even with debug=9 I can't see why beecrypt would not be found. It's right there in the main F9 repo, from which the depsolv process has already grabbed a all the other packages. How I'm running it: $ sudo revisor --debug=9 --yes --cli --conf revisor/revisor.conf --model f9-i386 --install-unified --kickstart-include --kickstart-default --kickstart revisor/anaconda-f9.ks The revisor-f9-i386.conf file has these additional repos: [xs7] name=XS 0.4 - i386 baseurl=http://fedora.laptop.org/xs/testing/olpc/7/i386 enabled=1 gpgcheck=0 [xs9] name=XS 0.5 - i386 baseurl=http://fedora.laptop.org/xs/testing/olpc/9/i386 enabled=1 gpgcheck=0 and the kickstart file is as follows: ### ### Kickstart file for OLPC XS School Server software ### ### Make it interactive - so these are 'seed' values interactive # Provide some defaults lang en_US.UTF-8 keyboard us timezone --utc America/New_York auth --useshadow --enablemd5 selinux --disabled network --device eth0 --bootproto dhcp --hostname schoolserver # We enable the firewall, even though we are going to overwrite # what anaconda leaves behind firewall --enabled ### X? #skipx ## Enable/Disable some services up front services --enabled=dhcdbd,network,sshd --disabled=netfs,nfs,nfslock,rpcbind,rpcgssd,rpcidmapd,rpcsvcgssd ### ### disk partitioning... ### # clear out sda without qualms... clearpart --drives=sda # Small Disk Support: (xs #7241) # If space >~10GiB then the sizes are # /boot 100 MiB # / 8 GiB # swap 2 GiB # /library fills all remaining capicity # If space is limited, partition sizes are reduced. # Smallest supported capacity is ~5GiB when no livecd-creator --uncompressed-size argument is # specified (defaults to 4096). # Using livecd-creator --uncompressed-size=2048 allows installation on ~3GiB disks (not tested yet). bootloader --location=mbr --driveorder=sda --append="rhgb quiet" clearpart --linux --drives=sda part /boot --fstype ext3 --size=100 --ondisk=sda part / --fstype ext3 --size=2048 --maxsize=8192 --grow --ondisk=sda # size of pv.6 must be at least enough to fit /library size and swap size part pv.6 --size=1025 --grow --ondisk=sda volgroup VolGroup00 --pesize=32768 pv.6 # Kickstart raises an error if logvol --size=0 logvol /library --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1 --grow logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=1024 --maxsize=2048 --grow %packages --nobase # School server core services metapackage xs-pkgs xs-config bash kernel passwd policycoreutils chkconfig authconfig rootfiles @admin-tools -gnome-packagekit %end %post # turn off firstboot for XS builds echo "RUN_FIRSTBOOT=NO" > /etc/sysconfig/firstboot %end cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Fri Sep 5 00:01:47 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 5 Sep 2008 12:01:47 +1200 Subject: Revisor - package not found and kickstart options change dep error tolerance? Message-ID: <46a038f90809041701g29bd40c0y9069790a1ed29c3d@mail.gmail.com> Hi Jeroen, I am trying to build a revisor-based School Server installer, and I am finding some oddities - As I mentioned before, it complains about a missing dependency for a package that is right there, in the same repo as other packages it is picking up. - If I pass --kickstart-include --kickstart-default the missing dependency is fatal. If I don't, it shows the warning and builds the image... both quite strange problems... I'm jumping into the src right now to see if I can find out more, thought I'd mention it... btw, http://lists.fedoraunity.org/mailman/listinfo/revisor-devel is still unreachable... cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Fri Sep 5 00:28:02 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 5 Sep 2008 12:28:02 +1200 Subject: Revisor - package not found and kickstart options change dep error tolerance? In-Reply-To: <46a038f90809041701g29bd40c0y9069790a1ed29c3d@mail.gmail.com> References: <46a038f90809041701g29bd40c0y9069790a1ed29c3d@mail.gmail.com> Message-ID: <46a038f90809041728y4db76087uba1d650c0bcfcc05@mail.gmail.com> On Fri, Sep 5, 2008 at 12:01 PM, Martin Langhoff wrote: > - As I mentioned before, it complains about a missing dependency for > a package that is right there, in the same repo as other packages it > is picking up. This is still misterious... > - If I pass --kickstart-include --kickstart-default the missing > dependency is fatal. If I don't, it shows the warning and builds the > image... But I found the explanation of this. It will tolerate missing deps unless it thinks that a subsequent step will fail, and a kickstart-driven install will conceivably fail if there's a missing dep - as per the comment: # FIXME: # - Dependency resolving may fail yet continue in case of composing installation media # - which is not supposed to go to cobbler # - which does not include the kickstart cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Fri Sep 5 00:49:07 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 5 Sep 2008 12:49:07 +1200 Subject: Revisor - package not found and kickstart options change dep error tolerance? In-Reply-To: <46a038f90809041728y4db76087uba1d650c0bcfcc05@mail.gmail.com> References: <46a038f90809041701g29bd40c0y9069790a1ed29c3d@mail.gmail.com> <46a038f90809041728y4db76087uba1d650c0bcfcc05@mail.gmail.com> Message-ID: <46a038f90809041749x4055b39cq3012f538d6033bb6@mail.gmail.com> On Fri, Sep 5, 2008 at 12:28 PM, Martin Langhoff wrote: > On Fri, Sep 5, 2008 at 12:01 PM, Martin Langhoff > wrote: >> - As I mentioned before, it complains about a missing dependency for >> a package that is right there, in the same repo as other packages it >> is picking up. > > This is still misterious... And is looking like a yum issue. Building a similar CD with Pungi leads to a CD that has no beecrypt, and errors about it in the logs. Why would yum not find beecrypt during the 'gather packages' phase? A F9 install looking at the same repos is able to find it? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From skvidal at fedoraproject.org Fri Sep 5 01:03:54 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 04 Sep 2008 21:03:54 -0400 Subject: Revisor - package not found and kickstart options change dep error tolerance? In-Reply-To: <46a038f90809041749x4055b39cq3012f538d6033bb6@mail.gmail.com> References: <46a038f90809041701g29bd40c0y9069790a1ed29c3d@mail.gmail.com> <46a038f90809041728y4db76087uba1d650c0bcfcc05@mail.gmail.com> <46a038f90809041749x4055b39cq3012f538d6033bb6@mail.gmail.com> Message-ID: <1220576634.17785.47.camel@rosebud> On Fri, 2008-09-05 at 12:49 +1200, Martin Langhoff wrote: > On Fri, Sep 5, 2008 at 12:28 PM, Martin Langhoff > wrote: > > On Fri, Sep 5, 2008 at 12:01 PM, Martin Langhoff > > wrote: > >> - As I mentioned before, it complains about a missing dependency for > >> a package that is right there, in the same repo as other packages it > >> is picking up. > > > > This is still misterious... > > And is looking like a yum issue. Building a similar CD with Pungi > leads to a CD that has no beecrypt, and errors about it in the logs. > > Why would yum not find beecrypt during the 'gather packages' phase? A > F9 install looking at the same repos is able to find it? > Can you get a log for me to look through? -sv From kanarip at kanarip.com Fri Sep 5 12:05:43 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 05 Sep 2008 14:05:43 +0200 Subject: Revisor - package not found and kickstart options change dep error tolerance? In-Reply-To: <46a038f90809041701g29bd40c0y9069790a1ed29c3d@mail.gmail.com> References: <46a038f90809041701g29bd40c0y9069790a1ed29c3d@mail.gmail.com> Message-ID: <48C12097.2040007@kanarip.com> Martin Langhoff wrote: > Hi Jeroen, > > I am trying to build a revisor-based School Server installer, and I am > finding some oddities > > - As I mentioned before, it complains about a missing dependency for > a package that is right there, in the same repo as other packages it > is picking up. > What exactly is the missing dependency error? > - If I pass --kickstart-include --kickstart-default the missing > dependency is fatal. If I don't, it shows the warning and builds the > image... > This is expected behaviour; If a compose that is going to get installed unattended (--kickstart-default is the key here) has dependency resolving problems, it will not get installed unattended (but fail miserably in attempting an unattended install). > both quite strange problems... I'm jumping into the src right now to > see if I can find out more, thought I'd mention it... btw, > http://lists.fedoraunity.org/mailman/listinfo/revisor-devel is still > unreachable... > Again? :/ Note to self: Still gotta move off Zimbra. Kind regards, Jeroen van Meeuwen -kanarip From paul.schroeder at bluecoat.com Mon Sep 8 21:27:01 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Mon, 08 Sep 2008 16:27:01 -0500 Subject: [PATCH] Perforce support for koji Message-ID: <1220909221.26292.25.camel@haywire.bluecoat.com> The powers that be require us to use Perforce. Thus, the patch. A few things to note about it: * Our P4 server is running on a non-standard port and thus needs to be specified. scm_tuple is now created via rsplit instead. Allows SCM port to be specified. i.e. This now works: allowed_scms=perforcetx.bluecoat.com:1999:/koji/sandbox/paul.schroeder/skeletor * P4 *requires* a stinkin' password. So I added password support to _parse_url. The "user" part of the SCM url can now be "user:password". Still works minus the ":password" too. Let me know if there's a better/preferred way to support passwords. * P4 can only checkout into the static client root specified in the P4 client spec (PITA). Sooo.. After the module_checkout_cmd is executed, if sourcedir does not exist, we do a 'os.rename' of the checked out code into the proper task sourcedir. * A P4 SCM URL looks like: p4://user:pass at p4port/p4client/p4depot?path/to/module#changelist i.e. p4port==host And p4client is your P4 client spec that you've created. Let me know if there are any Qs, comments, or any changes I should make.. Cheers...Paul... diff --git a/builder/kojid b/builder/kojid index 1a7afbf..92f8143 100755 --- a/builder/kojid +++ b/builder/kojid @@ -1830,7 +1830,8 @@ class BuildSRPMFromSCMTask(BaseTaskHandler): use_common = True for allowed_scm in options.allowed_scms.split(): - scm_tuple = allowed_scm.split(':') + # Use rsplit with 1 max split to allow for port numbers w/ scm host + scm_tuple = allowed_scm.rsplit(':', 1) if len(scm_tuple) in (2, 3): if fnmatch(scm.host, scm_tuple[0]) and fnmatch(scm.repository, scm_tuple[1]): # SCM host:repository is in the allowed list @@ -2325,7 +2326,8 @@ class SCM(object): 'GIT': ('git://', 'git+http://', 'git+https://', 'git +rsync://'), 'GIT+SSH': ('git+ssh://',), 'SVN': ('svn://', 'svn+http://', 'svn+https://'), - 'SVN+SSH': ('svn+ssh://',) } + 'SVN+SSH': ('svn+ssh://',), + 'P4': ('p4://',) } def is_scm_url(url): """ @@ -2362,10 +2364,11 @@ class SCM(object): raise koji.GenericError, 'Invalid SCM URL: %s' % url self.url = url - scheme, user, host, path, query, fragment = self._parse_url() + scheme, user, password, host, path, query, fragment = self._parse_url() self.scheme = scheme self.user = user + self.password = password self.host = host self.repository = path self.module = query @@ -2384,9 +2387,9 @@ class SCM(object): Parse the SCM url into usable components. Return the following tuple: - (scheme, user, host, path, query, fragment) + (scheme, user, password, host, path, query, fragment) - user may be None, everything else will have a value + user and password may be None, everything else will have a value """ # get the url's scheme scheme = self.url.split('://')[0] + '://' @@ -2396,14 +2399,21 @@ class SCM(object): dummyscheme, netloc, path, params, query, fragment = urlparse.urlparse(dummyurl) user = None + password = None userhost = netloc.split('@') if len(userhost) == 2: - user = userhost[0] + userpass = userhost[0].split(':') + user = userpass[0] + if len(userpass) == 2: + password = userpass[1] + elif len(userpass) > 2: + raise koji.GenericError, 'Invalid username:password specified: %s' % netloc if not user: # Don't return an empty string user = None - elif ':' in user: - raise koji.GenericError, 'username:password format not supported: %s' % user + if not password: + # Don't return an empty string + password = None netloc = userhost[1] elif len(userhost) > 2: raise koji.GenericError, 'Invalid username at hostname specified: %s' % netloc @@ -2419,7 +2429,7 @@ class SCM(object): raise koji.GenericError, 'Unable to parse SCM URL: %s' % self.url # return parsed values - return (scheme, user, netloc, path, query, fragment) + return (scheme, user, password, netloc, path, query, fragment) def checkout(self, scmdir, uploadpath, logfile, use_common=False): """ @@ -2514,6 +2524,39 @@ class SCM(object): module_checkout_cmd = ['svn', 'checkout', '-r', self.revision, '%s/%s' % (svnserver, self.module), self.module] common_checkout_cmd = ['svn', 'checkout', '%s/common' % svnserver] + elif self.scmtype == 'P4': + if not self.user: + raise koji.BuildError, 'No user specified for repository access scheme: %s' % self.scheme + # P4 URL: + # p4://user:pass at p4port/p4client/p4depot?path/to/module#changelist + + # Perforce uses a "client workspace" + # Before first slash is the p4 client, after is the p4 depot + (p4client, p4depot) = self.repository[1:].split('/', 1) + + p4client_root = None + p4info = os.popen('p4 -p ' + self.host + ' -c ' + p4client + ' info') + for line in p4info: + if line.startswith('Client root:'): + p4client_root = line.split()[-1] + break + p4info.close() + if not p4client_root: + raise koji.BuildError, 'Could not find perforce client root' + + # Perforce cannot checkout to a random dir (in this case scmdir). + # It will only checkout to the p4client_root, so we override scmdir + # with the p4client_root + scmdir = '%s/%s' % (p4client_root, p4depot) + + # When HEAD is given as the revision, we assume we want the latest + p4revision = '' + if self.revision.upper() != 'HEAD': + p4revision = '@%s' % self.revision + + module_checkout_cmd = ['p4', '-p', self.host, '-u', self.user, '-P', self.password, '-c', p4client, 'sync', '-f', '//%s/% s/...%s' % (p4depot, self.module, p4revision)] + common_checkout_cmd = ['p4', '-p', self.host, '-u', self.user, '-P', self.password, '-c', p4client, 'sync', '-f', '//% s/common/...' % p4depot] + else: raise koji.BuildError, 'Unknown SCM type: %s' % self.scmtype @@ -2521,6 +2564,10 @@ class SCM(object): if log_output(module_checkout_cmd[0], module_checkout_cmd, logfile, uploadpath, cwd=scmdir, logerror=1, env=env): raise koji.BuildError, 'Error running %s checkout command "%s", see %s for details' % \ (self.scmtype, ' '.join(module_checkout_cmd), os.path.basename(logfile)) + # Perforce checks out to the client root listed for the perforce client. + # Need to move checked out source into sourcedir. + if not os.path.exists(sourcedir): + os.rename('%s/%s' % (scmdir, self.module), sourcedir) if update_checkout_cmd: # Currently only required for GIT checkouts From dcbw at redhat.com Mon Sep 8 21:33:10 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 08 Sep 2008 17:33:10 -0400 Subject: [PATCH] Perforce support for koji In-Reply-To: <1220909221.26292.25.camel@haywire.bluecoat.com> References: <1220909221.26292.25.camel@haywire.bluecoat.com> Message-ID: <1220909590.9427.0.camel@localhost.localdomain> On Mon, 2008-09-08 at 16:27 -0500, Paul B Schroeder wrote: > The powers that be require us to use Perforce. Thus, the patch. A few > things to note about it: > > * Our P4 server is running on a non-standard port and thus needs to be > specified. scm_tuple is now created via rsplit instead. Allows SCM > port to be specified. i.e. This now works: > allowed_scms=perforcetx.bluecoat.com:1999:/koji/sandbox/paul.schroeder/skeletor > * P4 *requires* a stinkin' password. So I added password support to > _parse_url. The "user" part of the SCM url can now be "user:password". > Still works minus the ":password" too. Let me know if there's a > better/preferred way to support passwords. > * P4 can only checkout into the static client root specified in the P4 > client spec (PITA). Sooo.. After the module_checkout_cmd is executed, > if sourcedir does not exist, we do a 'os.rename' of the checked out code > into the proper task sourcedir. > * A P4 SCM URL looks like: > p4://user:pass at p4port/p4client/p4depot?path/to/module#changelist > i.e. p4port==host And p4client is your P4 client spec that you've > created. > > Let me know if there are any Qs, comments, or any changes I should > make.. The patch is linewrapped; any chance you could repost and make sure to use the "preformat" setting or something in your mail client? Dan > Cheers...Paul... > > > diff --git a/builder/kojid b/builder/kojid > index 1a7afbf..92f8143 100755 > --- a/builder/kojid > +++ b/builder/kojid > @@ -1830,7 +1830,8 @@ class BuildSRPMFromSCMTask(BaseTaskHandler): > use_common = True > > for allowed_scm in options.allowed_scms.split(): > - scm_tuple = allowed_scm.split(':') > + # Use rsplit with 1 max split to allow for port numbers w/ > scm host > + scm_tuple = allowed_scm.rsplit(':', 1) > if len(scm_tuple) in (2, 3): > if fnmatch(scm.host, scm_tuple[0]) and > fnmatch(scm.repository, scm_tuple[1]): > # SCM host:repository is in the allowed list > @@ -2325,7 +2326,8 @@ class SCM(object): > 'GIT': ('git://', 'git+http://', 'git+https://', 'git > +rsync://'), > 'GIT+SSH': ('git+ssh://',), > 'SVN': ('svn://', 'svn+http://', 'svn+https://'), > - 'SVN+SSH': ('svn+ssh://',) } > + 'SVN+SSH': ('svn+ssh://',), > + 'P4': ('p4://',) } > > def is_scm_url(url): > """ > @@ -2362,10 +2364,11 @@ class SCM(object): > raise koji.GenericError, 'Invalid SCM URL: %s' % url > > self.url = url > - scheme, user, host, path, query, fragment = self._parse_url() > + scheme, user, password, host, path, query, fragment = > self._parse_url() > > self.scheme = scheme > self.user = user > + self.password = password > self.host = host > self.repository = path > self.module = query > @@ -2384,9 +2387,9 @@ class SCM(object): > Parse the SCM url into usable components. > Return the following tuple: > > - (scheme, user, host, path, query, fragment) > + (scheme, user, password, host, path, query, fragment) > > - user may be None, everything else will have a value > + user and password may be None, everything else will have a > value > """ > # get the url's scheme > scheme = self.url.split('://')[0] + '://' > @@ -2396,14 +2399,21 @@ class SCM(object): > dummyscheme, netloc, path, params, query, fragment = > urlparse.urlparse(dummyurl) > > user = None > + password = None > userhost = netloc.split('@') > if len(userhost) == 2: > - user = userhost[0] > + userpass = userhost[0].split(':') > + user = userpass[0] > + if len(userpass) == 2: > + password = userpass[1] > + elif len(userpass) > 2: > + raise koji.GenericError, 'Invalid username:password > specified: %s' % netloc > if not user: > # Don't return an empty string > user = None > - elif ':' in user: > - raise koji.GenericError, 'username:password format not > supported: %s' % user > + if not password: > + # Don't return an empty string > + password = None > netloc = userhost[1] > elif len(userhost) > 2: > raise koji.GenericError, 'Invalid username at hostname > specified: %s' % netloc > @@ -2419,7 +2429,7 @@ class SCM(object): > raise koji.GenericError, 'Unable to parse SCM URL: %s' % > self.url > > # return parsed values > - return (scheme, user, netloc, path, query, fragment) > + return (scheme, user, password, netloc, path, query, fragment) > > def checkout(self, scmdir, uploadpath, logfile, use_common=False): > """ > @@ -2514,6 +2524,39 @@ class SCM(object): > module_checkout_cmd = ['svn', 'checkout', '-r', > self.revision, '%s/%s' % (svnserver, self.module), self.module] > common_checkout_cmd = ['svn', 'checkout', '%s/common' % > svnserver] > > + elif self.scmtype == 'P4': > + if not self.user: > + raise koji.BuildError, 'No user specified for > repository access scheme: %s' % self.scheme > + # P4 URL: > + # > p4://user:pass at p4port/p4client/p4depot?path/to/module#changelist > + > + # Perforce uses a "client workspace" > + # Before first slash is the p4 client, after is the p4 > depot > + (p4client, p4depot) = self.repository[1:].split('/', 1) > + > + p4client_root = None > + p4info = os.popen('p4 -p ' + self.host + ' -c ' + p4client > + ' info') > + for line in p4info: > + if line.startswith('Client root:'): > + p4client_root = line.split()[-1] > + break > + p4info.close() > + if not p4client_root: > + raise koji.BuildError, 'Could not find perforce client > root' > + > + # Perforce cannot checkout to a random dir (in this case > scmdir). > + # It will only checkout to the p4client_root, so we > override scmdir > + # with the p4client_root > + scmdir = '%s/%s' % (p4client_root, p4depot) > + > + # When HEAD is given as the revision, we assume we want the > latest > + p4revision = '' > + if self.revision.upper() != 'HEAD': > + p4revision = '@%s' % self.revision > + > + module_checkout_cmd = ['p4', '-p', self.host, '-u', > self.user, '-P', self.password, '-c', p4client, 'sync', '-f', '//%s/% > s/...%s' % (p4depot, self.module, p4revision)] > + common_checkout_cmd = ['p4', '-p', self.host, '-u', > self.user, '-P', self.password, '-c', p4client, 'sync', '-f', '//% > s/common/...' % p4depot] > + > else: > raise koji.BuildError, 'Unknown SCM type: %s' % > self.scmtype > > @@ -2521,6 +2564,10 @@ class SCM(object): > if log_output(module_checkout_cmd[0], module_checkout_cmd, > logfile, uploadpath, cwd=scmdir, logerror=1, env=env): > raise koji.BuildError, 'Error running %s checkout command > "%s", see %s for details' % \ > (self.scmtype, ' '.join(module_checkout_cmd), > os.path.basename(logfile)) > + # Perforce checks out to the client root listed for the > perforce client. > + # Need to move checked out source into sourcedir. > + if not os.path.exists(sourcedir): > + os.rename('%s/%s' % (scmdir, self.module), sourcedir) > > if update_checkout_cmd: > # Currently only required for GIT checkouts > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From paul.schroeder at bluecoat.com Mon Sep 8 21:32:34 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Mon, 08 Sep 2008 16:32:34 -0500 Subject: [PATCH] Perforce support for koji In-Reply-To: <1220909221.26292.25.camel@haywire.bluecoat.com> References: <1220909221.26292.25.camel@haywire.bluecoat.com> Message-ID: <48C599F2.60903@bluecoat.com> Hmm.. I'm looking a bit closer and it looks like I need to fix the scm_tuple part.. Paul B Schroeder wrote: > The powers that be require us to use Perforce. Thus, the patch. A few > things to note about it: > > * Our P4 server is running on a non-standard port and thus needs to be > specified. scm_tuple is now created via rsplit instead. Allows SCM > port to be specified. i.e. This now works: > allowed_scms=perforcetx.bluecoat.com:1999:/koji/sandbox/paul.schroeder/skeletor > * P4 *requires* a stinkin' password. So I added password support to > _parse_url. The "user" part of the SCM url can now be "user:password". > Still works minus the ":password" too. Let me know if there's a > better/preferred way to support passwords. > * P4 can only checkout into the static client root specified in the P4 > client spec (PITA). Sooo.. After the module_checkout_cmd is executed, > if sourcedir does not exist, we do a 'os.rename' of the checked out code > into the proper task sourcedir. > * A P4 SCM URL looks like: > p4://user:pass at p4port/p4client/p4depot?path/to/module#changelist > i.e. p4port==host And p4client is your P4 client spec that you've > created. > > Let me know if there are any Qs, comments, or any changes I should > make.. > > Cheers...Paul... > > > diff --git a/builder/kojid b/builder/kojid > index 1a7afbf..92f8143 100755 > --- a/builder/kojid > +++ b/builder/kojid > @@ -1830,7 +1830,8 @@ class BuildSRPMFromSCMTask(BaseTaskHandler): > use_common = True > > for allowed_scm in options.allowed_scms.split(): > - scm_tuple = allowed_scm.split(':') > + # Use rsplit with 1 max split to allow for port numbers w/ > scm host > + scm_tuple = allowed_scm.rsplit(':', 1) > if len(scm_tuple) in (2, 3): > if fnmatch(scm.host, scm_tuple[0]) and > fnmatch(scm.repository, scm_tuple[1]): > # SCM host:repository is in the allowed list > @@ -2325,7 +2326,8 @@ class SCM(object): > 'GIT': ('git://', 'git+http://', 'git+https://', 'git > +rsync://'), > 'GIT+SSH': ('git+ssh://',), > 'SVN': ('svn://', 'svn+http://', 'svn+https://'), > - 'SVN+SSH': ('svn+ssh://',) } > + 'SVN+SSH': ('svn+ssh://',), > + 'P4': ('p4://',) } > > def is_scm_url(url): > """ > @@ -2362,10 +2364,11 @@ class SCM(object): > raise koji.GenericError, 'Invalid SCM URL: %s' % url > > self.url = url > - scheme, user, host, path, query, fragment = self._parse_url() > + scheme, user, password, host, path, query, fragment = > self._parse_url() > > self.scheme = scheme > self.user = user > + self.password = password > self.host = host > self.repository = path > self.module = query > @@ -2384,9 +2387,9 @@ class SCM(object): > Parse the SCM url into usable components. > Return the following tuple: > > - (scheme, user, host, path, query, fragment) > + (scheme, user, password, host, path, query, fragment) > > - user may be None, everything else will have a value > + user and password may be None, everything else will have a > value > """ > # get the url's scheme > scheme = self.url.split('://')[0] + '://' > @@ -2396,14 +2399,21 @@ class SCM(object): > dummyscheme, netloc, path, params, query, fragment = > urlparse.urlparse(dummyurl) > > user = None > + password = None > userhost = netloc.split('@') > if len(userhost) == 2: > - user = userhost[0] > + userpass = userhost[0].split(':') > + user = userpass[0] > + if len(userpass) == 2: > + password = userpass[1] > + elif len(userpass) > 2: > + raise koji.GenericError, 'Invalid username:password > specified: %s' % netloc > if not user: > # Don't return an empty string > user = None > - elif ':' in user: > - raise koji.GenericError, 'username:password format not > supported: %s' % user > + if not password: > + # Don't return an empty string > + password = None > netloc = userhost[1] > elif len(userhost) > 2: > raise koji.GenericError, 'Invalid username at hostname > specified: %s' % netloc > @@ -2419,7 +2429,7 @@ class SCM(object): > raise koji.GenericError, 'Unable to parse SCM URL: %s' % > self.url > > # return parsed values > - return (scheme, user, netloc, path, query, fragment) > + return (scheme, user, password, netloc, path, query, fragment) > > def checkout(self, scmdir, uploadpath, logfile, use_common=False): > """ > @@ -2514,6 +2524,39 @@ class SCM(object): > module_checkout_cmd = ['svn', 'checkout', '-r', > self.revision, '%s/%s' % (svnserver, self.module), self.module] > common_checkout_cmd = ['svn', 'checkout', '%s/common' % > svnserver] > > + elif self.scmtype == 'P4': > + if not self.user: > + raise koji.BuildError, 'No user specified for > repository access scheme: %s' % self.scheme > + # P4 URL: > + # > p4://user:pass at p4port/p4client/p4depot?path/to/module#changelist > + > + # Perforce uses a "client workspace" > + # Before first slash is the p4 client, after is the p4 > depot > + (p4client, p4depot) = self.repository[1:].split('/', 1) > + > + p4client_root = None > + p4info = os.popen('p4 -p ' + self.host + ' -c ' + p4client > + ' info') > + for line in p4info: > + if line.startswith('Client root:'): > + p4client_root = line.split()[-1] > + break > + p4info.close() > + if not p4client_root: > + raise koji.BuildError, 'Could not find perforce client > root' > + > + # Perforce cannot checkout to a random dir (in this case > scmdir). > + # It will only checkout to the p4client_root, so we > override scmdir > + # with the p4client_root > + scmdir = '%s/%s' % (p4client_root, p4depot) > + > + # When HEAD is given as the revision, we assume we want the > latest > + p4revision = '' > + if self.revision.upper() != 'HEAD': > + p4revision = '@%s' % self.revision > + > + module_checkout_cmd = ['p4', '-p', self.host, '-u', > self.user, '-P', self.password, '-c', p4client, 'sync', '-f', '//%s/% > s/...%s' % (p4depot, self.module, p4revision)] > + common_checkout_cmd = ['p4', '-p', self.host, '-u', > self.user, '-P', self.password, '-c', p4client, 'sync', '-f', '//% > s/common/...' % p4depot] > + > else: > raise koji.BuildError, 'Unknown SCM type: %s' % > self.scmtype > > @@ -2521,6 +2564,10 @@ class SCM(object): > if log_output(module_checkout_cmd[0], module_checkout_cmd, > logfile, uploadpath, cwd=scmdir, logerror=1, env=env): > raise koji.BuildError, 'Error running %s checkout command > "%s", see %s for details' % \ > (self.scmtype, ' '.join(module_checkout_cmd), > os.path.basename(logfile)) > + # Perforce checks out to the client root listed for the > perforce client. > + # Need to move checked out source into sourcedir. > + if not os.path.exists(sourcedir): > + os.rename('%s/%s' % (scmdir, self.module), sourcedir) > > if update_checkout_cmd: > # Currently only required for GIT checkouts > > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -- --- Paul B Schroeder Blue Coat Systems, Inc. From paul.schroeder at bluecoat.com Mon Sep 8 22:32:28 2008 From: paul.schroeder at bluecoat.com (Paul B Schroeder) Date: Mon, 08 Sep 2008 17:32:28 -0500 Subject: [PATCH] Perforce support for koji In-Reply-To: <1220909590.9427.0.camel@localhost.localdomain> References: <1220909221.26292.25.camel@haywire.bluecoat.com> <1220909590.9427.0.camel@localhost.localdomain> Message-ID: <1220913148.26974.8.camel@haywire.bluecoat.com> On Mon, 2008-09-08 at 17:33 -0400, Dan Williams wrote: > The patch is linewrapped; any chance you could repost and make sure to > use the "preformat" setting or something in your mail client? Sure can.. Sorry about that. Also, quickly, this version fixes the previous patch in that the scm_tuple can handle when you specify use_common with an allowed_csm: allowed_scms=perforcetx.bluecoat.com:1999:/koji/sandbox/paul.schroeder/skeletor allowed_scms=perforcetx.bluecoat.com:1999:/koji/sandbox/paul.schroeder/skeletor:false allowed_scms=perforcetx.bluecoat.com:1999:/koji/sandbox/paul.schroeder/skeletor:true Cheers...Paul... diff --git a/builder/kojid b/builder/kojid index 1a7afbf..8f510f6 100755 --- a/builder/kojid +++ b/builder/kojid @@ -1830,14 +1830,19 @@ class BuildSRPMFromSCMTask(BaseTaskHandler): use_common = True for allowed_scm in options.allowed_scms.split(): - scm_tuple = allowed_scm.split(':') - if len(scm_tuple) in (2, 3): + scm_tuple = allowed_scm.rsplit(':', 1) + # check if we specify a value for use_common + if scm_tuple[1].lower() in ('false', 'no', '0'): + use_common = False + scm_tuple = scm_tuple[0].rsplit(':', 1) + elif scm_tuple[1].lower() in ('true', 'yes', '1'): + use_common = True + scm_tuple = scm_tuple[0].rsplit(':', 1) + else: + use_common = True + if len(scm_tuple) == 2: if fnmatch(scm.host, scm_tuple[0]) and fnmatch(scm.repository, scm_tuple[1]): # SCM host:repository is in the allowed list - # check if we specify a value for use_common - if len(scm_tuple) == 3: - if scm_tuple[2].lower() in ('false', 'no', '0'): - use_common = False break else: self.logger.warn('Ignoring incorrectly formatted SCM host:repository: %s' % allowed_scm) @@ -2325,7 +2330,8 @@ class SCM(object): 'GIT': ('git://', 'git+http://', 'git+https://', 'git+rsync://'), 'GIT+SSH': ('git+ssh://',), 'SVN': ('svn://', 'svn+http://', 'svn+https://'), - 'SVN+SSH': ('svn+ssh://',) } + 'SVN+SSH': ('svn+ssh://',), + 'P4': ('p4://',) } def is_scm_url(url): """ @@ -2362,10 +2368,11 @@ class SCM(object): raise koji.GenericError, 'Invalid SCM URL: %s' % url self.url = url - scheme, user, host, path, query, fragment = self._parse_url() + scheme, user, password, host, path, query, fragment = self._parse_url() self.scheme = scheme self.user = user + self.password = password self.host = host self.repository = path self.module = query @@ -2384,9 +2391,9 @@ class SCM(object): Parse the SCM url into usable components. Return the following tuple: - (scheme, user, host, path, query, fragment) + (scheme, user, password, host, path, query, fragment) - user may be None, everything else will have a value + user and password may be None, everything else will have a value """ # get the url's scheme scheme = self.url.split('://')[0] + '://' @@ -2396,14 +2403,21 @@ class SCM(object): dummyscheme, netloc, path, params, query, fragment = urlparse.urlparse(dummyurl) user = None + password = None userhost = netloc.split('@') if len(userhost) == 2: - user = userhost[0] + userpass = userhost[0].split(':') + user = userpass[0] + if len(userpass) == 2: + password = userpass[1] + elif len(userpass) > 2: + raise koji.GenericError, 'Invalid username:password specified: %s' % netloc if not user: # Don't return an empty string user = None - elif ':' in user: - raise koji.GenericError, 'username:password format not supported: %s' % user + if not password: + # Don't return an empty string + password = None netloc = userhost[1] elif len(userhost) > 2: raise koji.GenericError, 'Invalid username at hostname specified: %s' % netloc @@ -2419,7 +2433,7 @@ class SCM(object): raise koji.GenericError, 'Unable to parse SCM URL: %s' % self.url # return parsed values - return (scheme, user, netloc, path, query, fragment) + return (scheme, user, password, netloc, path, query, fragment) def checkout(self, scmdir, uploadpath, logfile, use_common=False): """ @@ -2514,6 +2528,39 @@ class SCM(object): module_checkout_cmd = ['svn', 'checkout', '-r', self.revision, '%s/%s' % (svnserver, self.module), self.module] common_checkout_cmd = ['svn', 'checkout', '%s/common' % svnserver] + elif self.scmtype == 'P4': + if not self.user: + raise koji.BuildError, 'No user specified for repository access scheme: %s' % self.scheme + # P4 URL: + # p4://user:pass at p4port/p4client/p4depot?path/to/module#changelist + + # Perforce uses a "client workspace" + # Before first slash is the p4 client, after is the p4 depot + (p4client, p4depot) = self.repository[1:].split('/', 1) + + p4client_root = None + p4info = os.popen('p4 -p ' + self.host + ' -c ' + p4client + ' info') + for line in p4info: + if line.startswith('Client root:'): + p4client_root = line.split()[-1] + break + p4info.close() + if not p4client_root: + raise koji.BuildError, 'Could not find perforce client root' + + # Perforce cannot checkout to a random dir (in this case scmdir). + # It will only checkout to the p4client_root, so we override scmdir + # with the p4client_root + scmdir = '%s/%s' % (p4client_root, p4depot) + + # When HEAD is given as the revision, we assume we want the latest + p4revision = '' + if self.revision.upper() != 'HEAD': + p4revision = '@%s' % self.revision + + module_checkout_cmd = ['p4', '-p', self.host, '-u', self.user, '-P', self.password, '-c', p4client, 'sync', '-f', '//%s/%s/...%s' % (p4depot, self.module, p4revision)] + common_checkout_cmd = ['p4', '-p', self.host, '-u', self.user, '-P', self.password, '-c', p4client, 'sync', '-f', '//%s/common/...' % p4depot] + else: raise koji.BuildError, 'Unknown SCM type: %s' % self.scmtype @@ -2521,6 +2568,10 @@ class SCM(object): if log_output(module_checkout_cmd[0], module_checkout_cmd, logfile, uploadpath, cwd=scmdir, logerror=1, env=env): raise koji.BuildError, 'Error running %s checkout command "%s", see %s for details' % \ (self.scmtype, ' '.join(module_checkout_cmd), os.path.basename(logfile)) + # Perforce checks out to the client root listed for the perforce client. + # Need to move checked out source into sourcedir. + if not os.path.exists(sourcedir): + os.rename('%s/%s' % (scmdir, self.module), sourcedir) if update_checkout_cmd: # Currently only required for GIT checkouts From martin.langhoff at gmail.com Tue Sep 9 05:12:38 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 9 Sep 2008 17:12:38 +1200 Subject: Patch fixing a problem with --kickstart-include Message-ID: <46a038f90809082212j45ec465avb427d476002655b9@mail.gmail.com> By naming the kickstart file as ks.cfg, anaconda would _always_ take it, regardless of kernel boot options. This is not what was expected - it is safer to give it a different name, and then use the boot menu item to select it. The patch is on top if F-9 . cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-base.py-The-kickstart-file-is-now-named-revisorks.c.patch Type: application/octet-stream Size: 1847 bytes Desc: not available URL: From kanarip at kanarip.com Tue Sep 9 08:48:41 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 09 Sep 2008 10:48:41 +0200 Subject: Patch fixing a problem with --kickstart-include In-Reply-To: <46a038f90809082212j45ec465avb427d476002655b9@mail.gmail.com> References: <46a038f90809082212j45ec465avb427d476002655b9@mail.gmail.com> Message-ID: <48C63869.9010705@kanarip.com> Martin Langhoff wrote: > By naming the kickstart file as ks.cfg, anaconda would _always_ take > it, regardless of kernel boot options. This is not what was expected - > it is safer to give it a different name, and then use the boot menu > item to select it. > So what you're saying is that anaconda picks up the kickstart file and runs away with it, even when it has not been told it should do so? It probably shouldn't do that... but I'll have to check with the anaconda guys to see if it's maybe an intended change. Kind regards, Jeroen van Meeuwen -kanarip From martin.langhoff at gmail.com Tue Sep 9 09:34:16 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 9 Sep 2008 21:34:16 +1200 Subject: Patch fixing a problem with --kickstart-include In-Reply-To: <48C63869.9010705@kanarip.com> References: <46a038f90809082212j45ec465avb427d476002655b9@mail.gmail.com> <48C63869.9010705@kanarip.com> Message-ID: <46a038f90809090234i646328b1yc37335f308baa4d8@mail.gmail.com> On Tue, Sep 9, 2008 at 8:48 PM, Jeroen van Meeuwen wrote: > So what you're saying is that anaconda picks up the kickstart file and runs > away with it, even when it has not been told it should do so? I am fairly sure that it does, though today I've tested ~20 different combination of builds and things, so there's a small chance I got it wrong. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Tue Sep 9 10:55:28 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 09 Sep 2008 12:55:28 +0200 Subject: Patch fixing a problem with --kickstart-include In-Reply-To: <46a038f90809090234i646328b1yc37335f308baa4d8@mail.gmail.com> References: <46a038f90809082212j45ec465avb427d476002655b9@mail.gmail.com> <48C63869.9010705@kanarip.com> <46a038f90809090234i646328b1yc37335f308baa4d8@mail.gmail.com> Message-ID: <48C65620.2090302@kanarip.com> Martin Langhoff wrote: > On Tue, Sep 9, 2008 at 8:48 PM, Jeroen van Meeuwen wrote: >> So what you're saying is that anaconda picks up the kickstart file and runs >> away with it, even when it has not been told it should do so? > > I am fairly sure that it does, though today I've tested ~20 different > combination of builds and things, so there's a small chance I got it > wrong. > I know it wasn't doing this before, and I'm not sure it's supposed to now. I've not seen any changes related to kickstart loading other then for the kickstart located on an NFS share... but then again I may have subconsciously ignored the commit. I'll try and figure out how it's supposed to work and how it actually works. -Jeroen From martin.langhoff at gmail.com Tue Sep 9 11:26:59 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 9 Sep 2008 23:26:59 +1200 Subject: Patch fixing a problem with --kickstart-include In-Reply-To: <48C65620.2090302@kanarip.com> References: <46a038f90809082212j45ec465avb427d476002655b9@mail.gmail.com> <48C63869.9010705@kanarip.com> <46a038f90809090234i646328b1yc37335f308baa4d8@mail.gmail.com> <48C65620.2090302@kanarip.com> Message-ID: <46a038f90809090426t103f98c9s14d63a93b78841cf@mail.gmail.com> On Tue, Sep 9, 2008 at 10:55 PM, Jeroen van Meeuwen wrote: > I know it wasn't doing this before, and I'm not sure it's supposed to now. > I've not seen any changes related to kickstart loading other then for the > kickstart located on an NFS share... but then again I may have > subconsciously ignored the commit. > > I'll try and figure out how it's supposed to work and how it actually works. When I crafted the patch I was reading the Anaconda/Kickstart wikipage, specifically the http://fedoraproject.org/wiki/Anaconda/Kickstart#Creating_a_Kickstart_Boot_CD-ROM section. Re-reading it now, I notice that you have to complement that with http://fedoraproject.org/wiki/Anaconda/Kickstart#Boot_CD-ROM - Hmmm. Unless a `git grep ks.cfg` of anaconda turns up a smoking gun, the patch I posted may be a misfire :-/ cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Wed Sep 10 09:23:34 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 10 Sep 2008 21:23:34 +1200 Subject: How stable is revisor 'master' as of now? I am keen on using --isolinux-cfg on F9 Message-ID: <46a038f90809100223s63674aaeiffacda561a3d2e47@mail.gmail.com> Hoping to provide a custom isolinux menu for the XS spin - and looking at the src in git, I see the --isolinux-cfg option. If it works, it'll be just the ticket. Is it reasonable to expect it to run with F-9 and with F-9 anaconda? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From bryce at zeniv.linux.org.uk Wed Sep 10 11:33:03 2008 From: bryce at zeniv.linux.org.uk (Bryce) Date: Wed, 10 Sep 2008 12:33:03 +0100 Subject: Assembling packages for ISO's Message-ID: <48C7B06F.2080101@zeniv.linux.org.uk> Can anyone think of a more succinct means to drag out all the latest rpms based on a tag? I could only came up with this horror. mkdir pool; cd pool TAG=f9-bryced koji list-pkgs --tag=${TAG} --quiet | cut -f 1 -d " " | xargs koji latest-pkg ${TAG} --quiet | cut -f1 -d " " | xargs -n1 koji download-build --arch=i386 --arch=i686 --arch=noarch Phil =--= From jonstanley at gmail.com Wed Sep 10 12:46:21 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 10 Sep 2008 08:46:21 -0400 Subject: Assembling packages for ISO's In-Reply-To: <48C7B06F.2080101@zeniv.linux.org.uk> References: <48C7B06F.2080101@zeniv.linux.org.uk> Message-ID: On Wed, Sep 10, 2008 at 7:33 AM, Bryce wrote: > mkdir pool; cd pool > TAG=f9-bryced > koji list-pkgs --tag=${TAG} --quiet | cut -f 1 -d " " | xargs koji latest-pkg ${TAG} --quiet | cut -f1 -d " " | xargs -n1 koji download-build --arch=i386 --arch=i686 --arch=noarch Maybe not succinct, but have you looked into mash (what Fedora uses to pull packages and make repos)? git clone git://git.fedorahosted.org/mash From bryce at zeniv.linux.org.uk Wed Sep 10 15:33:16 2008 From: bryce at zeniv.linux.org.uk (Bryce) Date: Wed, 10 Sep 2008 16:33:16 +0100 Subject: Assembling packages for ISO's In-Reply-To: References: <48C7B06F.2080101@zeniv.linux.org.uk> Message-ID: <48C7E8BC.3000600@zeniv.linux.org.uk> Jon Stanley wrote: > On Wed, Sep 10, 2008 at 7:33 AM, Bryce wrote: > > >> mkdir pool; cd pool >> TAG=f9-bryced >> koji list-pkgs --tag=${TAG} --quiet | cut -f 1 -d " " | xargs koji latest-pkg ${TAG} --quiet | cut -f1 -d " " | xargs -n1 koji download-build --arch=i386 --arch=i686 --arch=noarch >> > > Maybe not succinct, but have you looked into mash (what Fedora uses to > pull packages and make repos)? > > git clone git://git.fedorahosted.org/mash > > *tinkering* ok lets fire that up and see if it does what I expect. Yeah ok. thats tidier than my fiddling with koji cli scripting Thank you Phil =--= From sergio at sergiomb.no-ip.org Wed Sep 10 15:40:41 2008 From: sergio at sergiomb.no-ip.org (Sergio Monteiro Basto) Date: Wed, 10 Sep 2008 16:40:41 +0100 Subject: pungi my humble configurations Message-ID: <1221061241.7999.4.camel@segulix.localdomain> Hi , I put my humble configurations to build f8 and f9 updated repos with livna repos, on my homepage http://sergiomb.no-ip.org/pungi/confs/ feed back is welcome, hope that can help someone 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 martin.langhoff at gmail.com Thu Sep 11 02:50:10 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 11 Sep 2008 14:50:10 +1200 Subject: Revisor / yum oddity with package conflicts... Message-ID: <46a038f90809101950p1ef60539pc009807c38b46d1f@mail.gmail.com> With the exact same commandline, roughly 50% of the time I get a conflict betweem generic-logos and fedora-logos. This happens with stock F9 revisor from rpm and the tip of the F-9 branch in git. Nothing whatsoever requires fedora-logos. Sometimes it works, sometimes it doesn't. !? $ sudo revisor --cli --config revisor/revisor.conf \ --kickstart=revisor/anaconda-f9.ks \ --kickstart-include --kickstart-default \ --install-unified --model 'xs-f9-i386' --yes \ --rebrand-name=xs SELinux on this host is disabled. Composed media will not have SELinux, and as a result the system you install from the composed media will not have SELinux either. Loading Repositories: ######################################## 100.0% Select kickstart packages: ######################################## 100.0% Resolving Dependencies: ######################################## 100.0% generic-logos-9.0.0-1.fc9.noarch from fedora has depsolving problems --> generic-logos conflicts with fedora-logos Resolving Dependencies: ######################################## 100.0% Unable to resolve dependencies for some packages selected: generic-logos conflicts with fedora-logos *nothing* requires fedora-logos. Calling revisor with debug=5 shows... Adding required package kernel-0:2.6.25-14.fc9.i686 Adding required package kernel-xen-0:2.6.25-2.fc9.i686 Checking dependencies - not allowing any conflicts within the package set Resolving Dependencies: 0.0% Removing package fedora-release-0:9-2.noarch for rebranding Removing package fedora-release-notes-0:9.0.0-1.noarch for rebranding Removing package fedora-logos-0:9.0.0-2.fc9.noarch for rebranding Resolving Dependencies: ######################################## 100.0% generic-logos-9.0.0-1.fc9.noarch from fedora has depsolving problems --> generic-logos conflicts with fedora-logos Resolving Dependencies: ######################################## 100.0% Unable to resolve dependencies for some packages selected: cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Thu Sep 11 10:18:34 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 11 Sep 2008 12:18:34 +0200 Subject: How stable is revisor 'master' as of now? I am keen on using --isolinux-cfg on F9 In-Reply-To: <46a038f90809100223s63674aaeiffacda561a3d2e47@mail.gmail.com> References: <46a038f90809100223s63674aaeiffacda561a3d2e47@mail.gmail.com> Message-ID: <48C8F07A.7000509@kanarip.com> Martin Langhoff wrote: > Hoping to provide a custom isolinux menu for the XS spin - and looking > at the src in git, I see the --isolinux-cfg option. If it works, it'll > be just the ticket. > > Is it reasonable to expect it to run with F-9 and with F-9 anaconda? > Yes, it'll run. It is in there and it has been tested, it just didn't make it into a "stable" release pushed out to the updates/ repository (yet). Kind regards, Jeroen van Meeuwen -kanarip From skvidal at fedoraproject.org Thu Sep 11 14:58:48 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 11 Sep 2008 10:58:48 -0400 Subject: Revisor / yum oddity with package conflicts... In-Reply-To: <46a038f90809101950p1ef60539pc009807c38b46d1f@mail.gmail.com> References: <46a038f90809101950p1ef60539pc009807c38b46d1f@mail.gmail.com> Message-ID: <1221145128.987.180.camel@rosebud> On Thu, 2008-09-11 at 14:50 +1200, Martin Langhoff wrote: > With the exact same commandline, roughly 50% of the time I get a > conflict betweem generic-logos and fedora-logos. This happens with > stock F9 revisor from rpm and the tip of the F-9 branch in git. > Nothing whatsoever requires fedora-logos. > isn't fedora-logos being pulled in in @core in comps? that's why kickstart is pulling it in, I think. -sv From kanarip at kanarip.com Thu Sep 11 15:11:40 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 11 Sep 2008 17:11:40 +0200 Subject: Revisor / yum oddity with package conflicts... In-Reply-To: <1221145128.987.180.camel@rosebud> References: <46a038f90809101950p1ef60539pc009807c38b46d1f@mail.gmail.com> <1221145128.987.180.camel@rosebud> Message-ID: <48C9352C.1030307@kanarip.com> Seth Vidal wrote: > On Thu, 2008-09-11 at 14:50 +1200, Martin Langhoff wrote: >> With the exact same commandline, roughly 50% of the time I get a >> conflict betweem generic-logos and fedora-logos. This happens with >> stock F9 revisor from rpm and the tip of the F-9 branch in git. >> Nothing whatsoever requires fedora-logos. >> > > isn't fedora-logos being pulled in in @core in comps? > > that's why kickstart is pulling it in, I think. > Very true, notting has just closed #456882, having removed fedora-logos from @core, but that is rawhide only. In help of Martin, add exclude=fedora-logos to the YUM configuration file for the model you are using (probably located in /etc/revisor/conf.d/). Kind regards, Jeroen van Meeuwen -kanarip From martin.langhoff at gmail.com Thu Sep 11 22:38:14 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 12 Sep 2008 10:38:14 +1200 Subject: Revisor / yum oddity with package conflicts... In-Reply-To: <48C9352C.1030307@kanarip.com> References: <46a038f90809101950p1ef60539pc009807c38b46d1f@mail.gmail.com> <1221145128.987.180.camel@rosebud> <48C9352C.1030307@kanarip.com> Message-ID: <46a038f90809111538m40e1053ejde2a88fa8b6d60e4@mail.gmail.com> On Fri, Sep 12, 2008 at 3:11 AM, Jeroen van Meeuwen wrote: > Seth Vidal wrote: >> isn't fedora-logos being pulled in in @core in comps? >> that's why kickstart is pulling it in, I think. > Very true, notting has just closed #456882, having removed fedora-logos from > @core, but that is rawhide only. > > In help of Martin, add exclude=fedora-logos to the YUM configuration file > for the model you are using (probably located in /etc/revisor/conf.d/). Jeroen, Seth, thanks a ton for the hints. Happy to see that it's getting smoother for F10, and extra happy that I have a workaround. Now, on to the 200 more things I got to do to get the school server out... m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From paul at city-fan.org Fri Sep 12 15:05:02 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 12 Sep 2008 16:05:02 +0100 Subject: yum exitcode changes in 3.2.19-3.fc9 break some mock builds Message-ID: <48CA851E.4040103@city-fan.org> Today I tried building (in mock on a Fedora 9 host) some nmap packages for CentOS3 as version 4.76 came out. The mock build crashed out at the setup stage, due to the %pre script for the "dev" package failing (it thinks devfs is mounted). As I had built packages for version 4.75 only a couple of days ago, I tried rebuilding that and it now failed in the same way. I'd installed a bunch of updates in the last couple of days but the only one I could think of that might have caused that was the yum upgrade. So I downgraded yum from 3.2.19-3.fc9 to 3.2.17-2.fc9 and tried the build again, and this time it worked. The salient difference in the root.log was this: DEBUG util.py:250: Cannot install the dev package: mounted devfs detected. +DEBUG util.py:250: -------------------------------------------------------------------------------- +DEBUG util.py:250: Total 1.5 GB/s | 14 MB 00:00 DEBUG util.py:250: error: %pre(dev-3.3.12.3-1.centos.0.x86_64) scriptlet failed, exit status 1 DEBUG util.py:250: error: install: %pre scriptlet failed (2), skipping dev-3.3.12.3-1.centos.0 DEBUG util.py:250: ls: @@ -233,8 +236,7 @@ DEBUG util.py:250: mkinitrd failed DEBUG util.py:250: Installed: libpcap.x86_64 14:0.7.2-7.E3.5 openssl-devel.x86_64 0:0.9.7a-33.24 pcre-devel.x86_64 0:3.9-10.4 pkgconfig.x86_64 1:0.14.0-5 zlib-devel.x86_64 0:1.1.4-10.EL3 DEBUG util.py:250: Dependency Installed: dev.x86_64 0:3.3.12.3-1.centos.0 kernel.x86_64 0:2.4.21-57.EL krb5-devel.x86_64 0:1.2.7-68 losetup.x86_64 0:2.11y-31.24 lvm.x86_64 0:1.0.8-14 mkinitrd.x86_64 0:3.5.13.6-1 -DEBUG util.py:311: Child returncode was: 0 -DEBUG backend.py:436: Copying packages to result dir +DEBUG util.py:311: Child returncode was: 1 DEBUG backend.py:484: umount -n /var/lib/mock/centos-3-x86_64/root/proc DEBUG util.py:272: Executing command: umount -n /var/lib/mock/centos-3-x86_64/root/proc DEBUG util.py:311: Child returncode was: 0 So the scriptlet failures that didn't formerly affect affect mock builds due to the zero exit code of yum are now causing build failures due to a "1" exit code. I'm not sure what the best approach to fixing this should be. It makes perfect sense to me for yum to return a non-zero exit code when there's a scriptlet failure yet in some cases this is a problem that doesn't affect the subsequent build. As I suspect that this is a problem that mainly affects legacy distribution versions, perhaps there could be a mock option that could be set in the config file to ignore the yum exit code? Paul. From bryce at zeniv.linux.org.uk Fri Sep 12 16:45:33 2008 From: bryce at zeniv.linux.org.uk (Bryce) Date: Fri, 12 Sep 2008 17:45:33 +0100 Subject: What exactly is 'latest' Message-ID: <48CA9CAD.5000909@zeniv.linux.org.uk> I've created a tag I've imported various packages including several kernels ovs-2.1/kernel-2.4.21-52.0.0.0.2.EL.src.rpm ovs-2.1/kernel-2.6.18-8.1.6.0.18.el5.src.rpm ovs-2.1/kernel-2.6.9-42.0.10.2.3.EL.src.rpm ovs-2.1/kernel-2.6.9-42.32.0.0.4.EL.src.rpm when I look at latest-by-tag I get kernel-2.6.9-42.32.0.0.4.EL instead of kernel-2.6.18-8.1.6.0.18.el5 So I'm wondering if the koji code is simply making a character by character comparison ie it's seeing 2.6.1 vs 2.6.9 (this is using koji-1.2.6) Whats my option here? block-pkg? Phil =--= From jkeating at redhat.com Fri Sep 12 17:54:38 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 Sep 2008 10:54:38 -0700 Subject: What exactly is 'latest' In-Reply-To: <48CA9CAD.5000909@zeniv.linux.org.uk> References: <48CA9CAD.5000909@zeniv.linux.org.uk> Message-ID: <1221242078.24191.0.camel@luminos.localdomain> On Fri, 2008-09-12 at 17:45 +0100, Bryce wrote: > when I look at latest-by-tag I get kernel-2.6.9-42.32.0.0.4.EL instead > of kernel-2.6.18-8.1.6.0.18.el5 > So I'm wondering if the koji code is simply making a character by > character comparison > > ie it's seeing > 2.6.1 vs > 2.6.9 The last tagged == latest. Koji does not go by n-v-r, precisely so that you could use tagging to back down a version or roll back a version. The last tagged build always wins. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 Fri Sep 12 18:42:14 2008 From: mikem at redhat.com (Mike McLean) Date: Fri, 12 Sep 2008 14:42:14 -0400 Subject: What exactly is 'latest' In-Reply-To: <48CA9CAD.5000909@zeniv.linux.org.uk> References: <48CA9CAD.5000909@zeniv.linux.org.uk> Message-ID: <48CAB806.3040407@redhat.com> Bryce wrote: > when I look at latest-by-tag I get kernel-2.6.9-42.32.0.0.4.EL instead of kernel-2.6.18-8.1.6.0.18.el5 > So I'm wondering if the koji code is simply making a character by character comparison Note that latest-by-tag is an odd and misleading report that was submitted by a developer. I would not it. Use latest-pkg or list-tagged --latest instead. From bryce at zeniv.linux.org.uk Fri Sep 12 18:20:43 2008 From: bryce at zeniv.linux.org.uk (Bryce) Date: Fri, 12 Sep 2008 19:20:43 +0100 Subject: What exactly is 'latest' In-Reply-To: <1221242078.24191.0.camel@luminos.localdomain> References: <48CA9CAD.5000909@zeniv.linux.org.uk> <1221242078.24191.0.camel@luminos.localdomain> Message-ID: <48CAB2FB.8020002@zeniv.linux.org.uk> Jesse Keating wrote: > On Fri, 2008-09-12 at 17:45 +0100, Bryce wrote: > >> when I look at latest-by-tag I get kernel-2.6.9-42.32.0.0.4.EL instead >> of kernel-2.6.18-8.1.6.0.18.el5 >> So I'm wondering if the koji code is simply making a character by >> character comparison >> >> ie it's seeing >> 2.6.1 vs >> 2.6.9 >> > > The last tagged == latest. Koji does not go by n-v-r, precisely so that > you could use tagging to back down a version or roll back a version. > The last tagged build always wins > So whats happened is that when I was bootstrapping the tag, it tagged them in the order that 'ls' came across them? Ok, that seems fair. [root at emerald export]# ls ovs-2.1/kern*src.rpm ovs-2.1/kernel-2.4.21-52.0.0.0.2.EL.src.rpm ovs-2.1/kernel-2.6.18-8.1.6.0.18.el5.src.rpm ovs-2.1/kernel-2.6.9-42.0.10.2.3.EL.src.rpm ovs-2.1/kernel-2.6.9-42.32.0.0.4.EL.src.rpm <-- last in list, ergo last to be tagged, and thus the winner. Phil (victim of another gotcha) =--= From skvidal at fedoraproject.org Mon Sep 15 18:28:18 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 15 Sep 2008 14:28:18 -0400 Subject: yum exitcode changes in 3.2.19-3.fc9 break some mock builds In-Reply-To: <48CA851E.4040103@city-fan.org> References: <48CA851E.4040103@city-fan.org> Message-ID: <1221503298.25056.50.camel@rosebud> On Fri, 2008-09-12 at 16:05 +0100, Paul Howarth wrote: > Today I tried building (in mock on a Fedora 9 host) some nmap packages > for CentOS3 as version 4.76 came out. The mock build crashed out at the > setup stage, due to the %pre script for the "dev" package failing (it > thinks devfs is mounted). As I had built packages for version 4.75 only > a couple of days ago, I tried rebuilding that and it now failed in the > same way. I'd installed a bunch of updates in the last couple of days > but the only one I could think of that might have caused that was the > yum upgrade. So I downgraded yum from 3.2.19-3.fc9 to 3.2.17-2.fc9 and > tried the build again, and this time it worked. > > The salient difference in the root.log was this: > > DEBUG util.py:250: Cannot install the dev package: mounted devfs > detected. > +DEBUG util.py:250: > -------------------------------------------------------------------------------- > +DEBUG util.py:250: Total 1.5 > GB/s | 14 MB 00:00 > DEBUG util.py:250: error: %pre(dev-3.3.12.3-1.centos.0.x86_64) > scriptlet failed, exit status 1 > DEBUG util.py:250: error: install: %pre scriptlet failed (2), > skipping dev-3.3.12.3-1.centos.0 > DEBUG util.py:250: ls: > @@ -233,8 +236,7 @@ > DEBUG util.py:250: mkinitrd failed > DEBUG util.py:250: Installed: libpcap.x86_64 14:0.7.2-7.E3.5 > openssl-devel.x86_64 0:0.9.7a-33.24 pcre-devel.x86_64 0:3.9-10.4 > pkgconfig.x86_64 1:0.14.0-5 zlib-devel.x86_64 0:1.1.4-10.EL3 > DEBUG util.py:250: Dependency Installed: dev.x86_64 > 0:3.3.12.3-1.centos.0 kernel.x86_64 0:2.4.21-57.EL krb5-devel.x86_64 > 0:1.2.7-68 losetup.x86_64 0:2.11y-31.24 lvm.x86_64 0:1.0.8-14 > mkinitrd.x86_64 0:3.5.13.6-1 > -DEBUG util.py:311: Child returncode was: 0 > -DEBUG backend.py:436: Copying packages to result dir > +DEBUG util.py:311: Child returncode was: 1 > DEBUG backend.py:484: umount -n /var/lib/mock/centos-3-x86_64/root/proc > DEBUG util.py:272: Executing command: umount -n > /var/lib/mock/centos-3-x86_64/root/proc > DEBUG util.py:311: Child returncode was: 0 > > > So the scriptlet failures that didn't formerly affect affect mock builds > due to the zero exit code of yum are now causing build failures due to a > "1" exit code. > > I'm not sure what the best approach to fixing this should be. It makes > perfect sense to me for yum to return a non-zero exit code when there's > a scriptlet failure yet in some cases this is a problem that doesn't > affect the subsequent build. > > As I suspect that this is a problem that mainly affects legacy > distribution versions, perhaps there could be a mock option that could > be set in the config file to ignore the yum exit code? > Yah - the exit code was changed with a scriptlet failure. I think the correct thing to do here is to fix the pkg causing the scriptlet failure. Is there a reason why we can't do that? -sv From rdieter at math.unl.edu Tue Sep 16 14:32:08 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 16 Sep 2008 09:32:08 -0500 Subject: yum exitcode changes in 3.2.19-3.fc9 break some mock builds References: <48CA851E.4040103@city-fan.org> <1221503298.25056.50.camel@rosebud> Message-ID: Seth Vidal wrote: > On Fri, 2008-09-12 at 16:05 +0100, Paul Howarth wrote: ... >> The salient difference in the root.log was this: >> >> DEBUG util.py:250: Cannot install the dev package: mounted devfs >> detected. >> +DEBUG util.py:250: >> -------------------------------------------------------------------------------- >> +DEBUG util.py:250: Total 1.5 >> GB/s | 14 MB 00:00 >> DEBUG util.py:250: error: %pre(dev-3.3.12.3-1.centos.0.x86_64) >> scriptlet failed, exit status 1 ... > Yah - the exit code was changed with a scriptlet failure. I think the > correct thing to do here is to fix the pkg causing the scriptlet > failure. > > Is there a reason why we can't do that? This is a rhel (ok centos) pkg mind you... wanna take bets how long it'll take to get that fixed (if at all)? -- Rex From paul at city-fan.org Tue Sep 16 14:43:51 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 Sep 2008 15:43:51 +0100 Subject: yum exitcode changes in 3.2.19-3.fc9 break some mock builds In-Reply-To: <1221503298.25056.50.camel@rosebud> References: <48CA851E.4040103@city-fan.org> <1221503298.25056.50.camel@rosebud> Message-ID: <48CFC627.8000900@city-fan.org> Seth Vidal wrote: > On Fri, 2008-09-12 at 16:05 +0100, Paul Howarth wrote: >> Today I tried building (in mock on a Fedora 9 host) some nmap packages >> for CentOS3 as version 4.76 came out. The mock build crashed out at the >> setup stage, due to the %pre script for the "dev" package failing (it >> thinks devfs is mounted). As I had built packages for version 4.75 only >> a couple of days ago, I tried rebuilding that and it now failed in the >> same way. I'd installed a bunch of updates in the last couple of days >> but the only one I could think of that might have caused that was the >> yum upgrade. So I downgraded yum from 3.2.19-3.fc9 to 3.2.17-2.fc9 and >> tried the build again, and this time it worked. >> >> The salient difference in the root.log was this: >> >> DEBUG util.py:250: Cannot install the dev package: mounted devfs >> detected. >> +DEBUG util.py:250: >> -------------------------------------------------------------------------------- >> +DEBUG util.py:250: Total 1.5 >> GB/s | 14 MB 00:00 >> DEBUG util.py:250: error: %pre(dev-3.3.12.3-1.centos.0.x86_64) >> scriptlet failed, exit status 1 >> DEBUG util.py:250: error: install: %pre scriptlet failed (2), >> skipping dev-3.3.12.3-1.centos.0 >> DEBUG util.py:250: ls: >> @@ -233,8 +236,7 @@ >> DEBUG util.py:250: mkinitrd failed >> DEBUG util.py:250: Installed: libpcap.x86_64 14:0.7.2-7.E3.5 >> openssl-devel.x86_64 0:0.9.7a-33.24 pcre-devel.x86_64 0:3.9-10.4 >> pkgconfig.x86_64 1:0.14.0-5 zlib-devel.x86_64 0:1.1.4-10.EL3 >> DEBUG util.py:250: Dependency Installed: dev.x86_64 >> 0:3.3.12.3-1.centos.0 kernel.x86_64 0:2.4.21-57.EL krb5-devel.x86_64 >> 0:1.2.7-68 losetup.x86_64 0:2.11y-31.24 lvm.x86_64 0:1.0.8-14 >> mkinitrd.x86_64 0:3.5.13.6-1 >> -DEBUG util.py:311: Child returncode was: 0 >> -DEBUG backend.py:436: Copying packages to result dir >> +DEBUG util.py:311: Child returncode was: 1 >> DEBUG backend.py:484: umount -n /var/lib/mock/centos-3-x86_64/root/proc >> DEBUG util.py:272: Executing command: umount -n >> /var/lib/mock/centos-3-x86_64/root/proc >> DEBUG util.py:311: Child returncode was: 0 >> >> >> So the scriptlet failures that didn't formerly affect affect mock builds >> due to the zero exit code of yum are now causing build failures due to a >> "1" exit code. >> >> I'm not sure what the best approach to fixing this should be. It makes >> perfect sense to me for yum to return a non-zero exit code when there's >> a scriptlet failure yet in some cases this is a problem that doesn't >> affect the subsequent build. >> >> As I suspect that this is a problem that mainly affects legacy >> distribution versions, perhaps there could be a mock option that could >> be set in the config file to ignore the yum exit code? >> > > Yah - the exit code was changed with a scriptlet failure. I think the > correct thing to do here is to fix the pkg causing the scriptlet > failure. > > Is there a reason why we can't do that? This is without doubt the technically correct thing to do, though "official" updates for legacy distros and even RHEL 3 may be hard to get. I've taken the approach of building workaround packages and adding them to a local repo in my buildsystem. For CentOS 3, I needed a patched MAKEDEV package that didn't bail out of %pre (at least for the "dev" subpackage) if there was something mounted on /dev (which it assumed would be devfs). For other distributions of similar vintage, I needed a hacked mkinitrd package with a patched new-kernel-pkg script that didn't return a "1" exit status if mkinitrd failed (which typically happened in the kernel package's %post when mkinitrd found it didn't have any available loop devices to use). For Fedora 4 and 5 (some people just won't move on...) I also needed a tweaked util-linux package with %post tweaked to return a zero exit status. I think this may have been a package ordering issue as the %post script was getting "command not found" errors for things in /bin like touch, chown, and chmod. One other curiosity I noticed whilst looking at these issues was that mock silently refuses to overwrite an existing file if you try to do it using config_opts['files'], even if that file is empty. So it's not possible for instance to set up a custom /etc/fstab in the chroot this way, since mock has already created an empty one by this time. What's the reasoning behind this? Paul. From skvidal at fedoraproject.org Tue Sep 16 16:30:54 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 16 Sep 2008 12:30:54 -0400 Subject: yum exitcode changes in 3.2.19-3.fc9 break some mock builds In-Reply-To: References: <48CA851E.4040103@city-fan.org> <1221503298.25056.50.camel@rosebud> Message-ID: <1221582654.5296.2.camel@rosebud> On Tue, 2008-09-16 at 09:32 -0500, Rex Dieter wrote: > Seth Vidal wrote: > > > On Fri, 2008-09-12 at 16:05 +0100, Paul Howarth wrote: > ... > >> The salient difference in the root.log was this: > >> > >> DEBUG util.py:250: Cannot install the dev package: mounted devfs > >> detected. > >> +DEBUG util.py:250: > >> -------------------------------------------------------------------------------- > >> +DEBUG util.py:250: Total 1.5 > >> GB/s | 14 MB 00:00 > >> DEBUG util.py:250: error: %pre(dev-3.3.12.3-1.centos.0.x86_64) > >> scriptlet failed, exit status 1 > > ... > > Yah - the exit code was changed with a scriptlet failure. I think the > > correct thing to do here is to fix the pkg causing the scriptlet > > failure. > > > > Is there a reason why we can't do that? > > This is a rhel (ok centos) pkg mind you... wanna take bets how long it'll > take to get that fixed (if at all)? > So we add a config option into yum to optionally return valid returncodes to compensate? I don't think so. -sv From edge at edginton.net Tue Sep 16 17:22:18 2008 From: edge at edginton.net (Brian Edginton) Date: Tue, 16 Sep 2008 11:22:18 -0600 Subject: A couple of questions about pungi Message-ID: <7f3604b80809161022l93ee3e5jfbcf9185880dc941@mail.gmail.com> I hope this is the correct list, please correct me if there is a better one. I have two issues with pungi on F9 (x86_64) that I haven't been able to find the answer for. 1) With the advent of using a kickstart and/or command lines I cannot find a way to set iso_basename which defaults to "Fedora" 2) I cannot see a way of building an iso with only x86_64 and noarch rpms, I always seem to get the i386 rpms included. Can I do this with pungi alone and not have to massage the build before I make the iso? Thanks in advance, -edge From jkeating at j2solutions.net Tue Sep 16 17:28:25 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 16 Sep 2008 10:28:25 -0700 Subject: A couple of questions about pungi In-Reply-To: <7f3604b80809161022l93ee3e5jfbcf9185880dc941@mail.gmail.com> References: <7f3604b80809161022l93ee3e5jfbcf9185880dc941@mail.gmail.com> Message-ID: <1221586105.4736.11.camel@luminos.localdomain> On Tue, 2008-09-16 at 11:22 -0600, Brian Edginton wrote: > > 1) With the advent of using a kickstart and/or command lines I cannot > find a way to set iso_basename which defaults to "Fedora" Have you used the --name option? That's what defaults to Fedora. > > 2) I cannot see a way of building an iso with only x86_64 and noarch > rpms, I always seem to get the i386 rpms included. Can I do this with > pungi alone and not have to massage the build before I make the iso? Add an --exclude *.i?86 in the repo lines in the kickstart file. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) -------------- 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 edge at edginton.net Tue Sep 16 17:48:04 2008 From: edge at edginton.net (Brian Edginton) Date: Tue, 16 Sep 2008 11:48:04 -0600 Subject: A couple of questions about pungi In-Reply-To: <1221586105.4736.11.camel@luminos.localdomain> References: <7f3604b80809161022l93ee3e5jfbcf9185880dc941@mail.gmail.com> <1221586105.4736.11.camel@luminos.localdomain> Message-ID: <7f3604b80809161048s26c0ff2ax913fffc90d99b75@mail.gmail.com> On Tue, Sep 16, 2008 at 11:28 AM, Jesse Keating wrote: > On Tue, 2008-09-16 at 11:22 -0600, Brian Edginton wrote: >> >> 1) With the advent of using a kickstart and/or command lines I cannot >> find a way to set iso_basename which defaults to "Fedora" > > Have you used the --name option? That's what defaults to Fedora. Yes, I have. That set's the product and release information as it traverses through correctly but doesn't effect the name of the iso, which is built from a concatenation of iso_basename, version and arch (pungi.py). In config.py iso_basename is defaulted to 'Fedora' but it seems there is no practical way to set it from a config or cli. It looks like some older turn of pungi set iso_basename to name if it was empty but that has gone away now. -edge From jkeating at redhat.com Tue Sep 16 17:56:43 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 16 Sep 2008 10:56:43 -0700 Subject: A couple of questions about pungi In-Reply-To: <7f3604b80809161048s26c0ff2ax913fffc90d99b75@mail.gmail.com> References: <7f3604b80809161022l93ee3e5jfbcf9185880dc941@mail.gmail.com> <1221586105.4736.11.camel@luminos.localdomain> <7f3604b80809161048s26c0ff2ax913fffc90d99b75@mail.gmail.com> Message-ID: <1221587803.4736.16.camel@luminos.localdomain> On Tue, 2008-09-16 at 11:48 -0600, Brian Edginton wrote: > Yes, I have. That set's the product and release information as it > traverses through correctly but doesn't effect the name of the iso, > which is built from a concatenation of iso_basename, version and arch > (pungi.py). In config.py iso_basename is defaulted to 'Fedora' but it > seems there is no practical way to set it from a config or cli. It > looks like some older turn of pungi set iso_basename to name if it was > empty but that has gone away now. Hrm, ok. I know I lost some things when we moved away from a config file. I don't think it's all that unreasonable to set an iso basename to that of name, I'll take a look (or review a patch... :) -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 edge at edginton.net Tue Sep 16 18:01:07 2008 From: edge at edginton.net (Brian Edginton) Date: Tue, 16 Sep 2008 12:01:07 -0600 Subject: A couple of questions about pungi In-Reply-To: <1221587803.4736.16.camel@luminos.localdomain> References: <7f3604b80809161022l93ee3e5jfbcf9185880dc941@mail.gmail.com> <1221586105.4736.11.camel@luminos.localdomain> <7f3604b80809161048s26c0ff2ax913fffc90d99b75@mail.gmail.com> <1221587803.4736.16.camel@luminos.localdomain> Message-ID: <7f3604b80809161101r4a7b4390r5bd29abaf36d5c21@mail.gmail.com> On Tue, Sep 16, 2008 at 11:56 AM, Jesse Keating wrote: > On Tue, 2008-09-16 at 11:48 -0600, Brian Edginton wrote: >> Yes, I have. That set's the product and release information as it >> traverses through correctly but doesn't effect the name of the iso, >> which is built from a concatenation of iso_basename, version and arch >> (pungi.py). In config.py iso_basename is defaulted to 'Fedora' but it >> seems there is no practical way to set it from a config or cli. It >> looks like some older turn of pungi set iso_basename to name if it was >> empty but that has gone away now. > > Hrm, ok. I know I lost some things when we moved away from a config > file. I don't think it's all that unreasonable to set an iso basename > to that of name, I'll take a look (or review a patch... :) Hint taken. Let me review it a bit more and I'll get something to you. -edge From petersen at redhat.com Thu Sep 18 00:25:38 2008 From: petersen at redhat.com (Jens Petersen) Date: Wed, 17 Sep 2008 20:25:38 -0400 (EDT) Subject: Fwd: Broken dependencies: perl-Test-AutoBuild In-Reply-To: <20080917090505.GA10471@redhat.com> Message-ID: <50864570.1350981221697538565.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Hi, Any ideas or thoughts on how to get rid of these new daily warning mails? (Unfortunately porting ghc to ppc64 is a non-trivial amount of work and not going to happen any time soon unless someone kindly volunteers to work on it.) Is there a white list or something this can be added to? Thanks, Jens -------------- next part -------------- An embedded message was scrubbed... From: "Daniel P. Berrange" Subject: Re: Broken dependencies: perl-Test-AutoBuild Date: Wed, 17 Sep 2008 10:05:05 +0100 Size: 4607 URL: From jkeating at redhat.com Thu Sep 18 02:06:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 Sep 2008 19:06:22 -0700 Subject: Fwd: Broken dependencies: perl-Test-AutoBuild In-Reply-To: <50864570.1350981221697538565.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <50864570.1350981221697538565.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1221703582.14439.20.camel@luminos.localdomain> On Wed, 2008-09-17 at 20:25 -0400, Jens Petersen wrote: > > > Any ideas or thoughts on how to get rid of these new daily warning > mails? (Unfortunately porting ghc to ppc64 is a non-trivial amount of > work and not going to happen any time soon unless someone kindly > volunteers to work on it.) > > Is there a white list or something this can be added to? ifarch the things that depend on it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 petersen at redhat.com Thu Sep 18 04:49:20 2008 From: petersen at redhat.com (Jens Petersen) Date: Thu, 18 Sep 2008 00:49:20 -0400 (EDT) Subject: Broken dependencies: perl-Test-AutoBuild In-Reply-To: <1221703582.14439.20.camel@luminos.localdomain> Message-ID: <141358781.1369471221713360764.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> > > Any ideas or thoughts on how to get rid of these new daily warning > > mails? (Unfortunately porting ghc to ppc64 is a non-trivial amount > of > > work and not going to happen any time soon unless someone kindly > > volunteers to work on it.) > > > > Is there a white list or something this can be added to? > > ifarch the things that depend on it. How does that stop perl-Test-AutoBuild-darcs.noarch getting into ppc64 trees? Jens From jkeating at redhat.com Thu Sep 18 06:38:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 Sep 2008 23:38:21 -0700 Subject: Broken dependencies: perl-Test-AutoBuild In-Reply-To: <141358781.1369471221713360764.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <141358781.1369471221713360764.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1221719901.14439.23.camel@luminos.localdomain> On Thu, 2008-09-18 at 00:49 -0400, Jens Petersen wrote: > How does that stop perl-Test-AutoBuild-darcs.noarch getting into ppc64 > trees? ExcludeArch -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 martin.langhoff at gmail.com Thu Sep 18 07:44:33 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 18 Sep 2008 19:44:33 +1200 Subject: Revisor / yum oddity: anaconda-runtime Message-ID: <46a038f90809180044l2d64e7c1kf9ce851399b7db04@mail.gmail.com> On Fedora 9, using F9's revisor which has not changed in a while... - last week, I was able to invoke revisor and create a new installer CD without any problem... - this week, buildinstall dies, and if I enable logging it complains missing anaconda-runtime - this is looking at a local copy of the 'release' repo - I rsync'd it earlier today, but IIRC it had not changed... - my custom packages have changed a little bit, but none of them required anaconda-runtime - I have been experimenting with a different version of revisor - I've nuked /var/tmp/revisor* - perhaps state got saved anywhere else? Adding anaconda-runtime to the kickstart file that drives the process fixes the problem. It's not a problem I was expecting to have though :-/ In any case, am I missing any factor that could be messing up the process? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Thu Sep 18 08:50:23 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 18 Sep 2008 10:50:23 +0200 Subject: Revisor / yum oddity: anaconda-runtime In-Reply-To: <46a038f90809180044l2d64e7c1kf9ce851399b7db04@mail.gmail.com> References: <46a038f90809180044l2d64e7c1kf9ce851399b7db04@mail.gmail.com> Message-ID: <48D2164F.90905@kanarip.com> Martin Langhoff wrote: > On Fedora 9, using F9's revisor which has not changed in a while... > > - last week, I was able to invoke revisor and create a new installer > CD without any problem... > - this week, buildinstall dies, and if I enable logging it complains > missing anaconda-runtime > - this is looking at a local copy of the 'release' repo - I rsync'd > it earlier today, but IIRC it had not changed... > - my custom packages have changed a little bit, but none of them > required anaconda-runtime > - I have been experimenting with a different version of revisor - > I've nuked /var/tmp/revisor* - perhaps state got saved anywhere else? > > Adding anaconda-runtime to the kickstart file that drives the process > fixes the problem. It's not a problem I was expecting to have though > :-/ > > In any case, am I missing any factor that could be messing up the process? > I'd like to know what version of Fedora you're attempting to compose... Also Fedora 9? I'd love some debug output, since it's going to tell me what happened exactly. --debug 9 should do the trick and you can send it to me in private (since it's going to end up being a large log file). Kind regards, Jeroen van Meeuwen -kanarip From edge at edginton.net Thu Sep 18 15:49:56 2008 From: edge at edginton.net (Brian Edginton) Date: Thu, 18 Sep 2008 09:49:56 -0600 Subject: A couple of questions about pungi In-Reply-To: <7f3604b80809161101r4a7b4390r5bd29abaf36d5c21@mail.gmail.com> References: <7f3604b80809161022l93ee3e5jfbcf9185880dc941@mail.gmail.com> <1221586105.4736.11.camel@luminos.localdomain> <7f3604b80809161048s26c0ff2ax913fffc90d99b75@mail.gmail.com> <1221587803.4736.16.camel@luminos.localdomain> <7f3604b80809161101r4a7b4390r5bd29abaf36d5c21@mail.gmail.com> Message-ID: <7f3604b80809180849s1a5e825co77d3f44242030a4b@mail.gmail.com> On Tue, Sep 16, 2008 at 12:01 PM, Brian Edginton wrote: > On Tue, Sep 16, 2008 at 11:56 AM, Jesse Keating wrote: >> On Tue, 2008-09-16 at 11:48 -0600, Brian Edginton wrote: >>> Yes, I have. That set's the product and release information as it >>> traverses through correctly but doesn't effect the name of the iso, >>> which is built from a concatenation of iso_basename, version and arch >>> (pungi.py). In config.py iso_basename is defaulted to 'Fedora' but it >>> seems there is no practical way to set it from a config or cli. It >>> looks like some older turn of pungi set iso_basename to name if it was >>> empty but that has gone away now. >> >> Hrm, ok. I know I lost some things when we moved away from a config >> file. I don't think it's all that unreasonable to set an iso basename >> to that of name, I'll take a look (or review a patch... :) > > Hint taken. Let me review it a bit more and I'll get something to you. > > -edge > So, I would have expected the following change to have the effect of setting iso_basename to 'name'. config.py -self.set('default', 'iso_basename', 'Fedora') +self.set('default', 'iso_basename', self.get('default', 'name')) but what I find is that it sets iso_basename to the default value of 'name' even when 'name' has been set to another string. I can see this because the value I set it to is actually reflected in the options passed to the various utils that pungi calls. It is almost like iso_basename is being evaluated before name. Is there an inherent order that the members are instantiated in python? What am I missing here? -edge From martin.langhoff at gmail.com Fri Sep 19 04:33:04 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 19 Sep 2008 16:33:04 +1200 Subject: [Server-devel] Revisor / yum oddity: anaconda-runtime In-Reply-To: <48D270D2.6080307@shaw.ca> References: <46a038f90809180044l2d64e7c1kf9ce851399b7db04@mail.gmail.com> <48D270D2.6080307@shaw.ca> Message-ID: <46a038f90809182133n381944efo67051d37b99d4f5f@mail.gmail.com> On Fri, Sep 19, 2008 at 3:16 AM, Jerry Vonau wrote: > Yea, revisor needs anaconda-runtime, > cat /usr/lib/revisor/scripts/F9-buildinstall | grep anaconda Yes, but from what Jeroen has said, revisor will pull it in to satisfy the need at CD build time, without it being listed in the ks file (and therefore getting installed on the target system too...) > Anaconda-runtime needs to exist in the repo that you use for the compose, > but doesn't need to be in the kickstart file. Too bad, you have to add > anaconda-runtime to the kickstart file, to get the package into the compose > repo, in order to use it later in buildinstall. Well, that's supposed to be true for pungi, not true for revisor. As far as I understand anyway :-) Jeroen has asked for logs and I'm collecting some right now... cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Fri Sep 19 10:23:25 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 19 Sep 2008 12:23:25 +0200 Subject: [Server-devel] Revisor / yum oddity: anaconda-runtime In-Reply-To: <46a038f90809182133n381944efo67051d37b99d4f5f@mail.gmail.com> References: <46a038f90809180044l2d64e7c1kf9ce851399b7db04@mail.gmail.com> <48D270D2.6080307@shaw.ca> <46a038f90809182133n381944efo67051d37b99d4f5f@mail.gmail.com> Message-ID: <48D37D9D.8070908@kanarip.com> Martin Langhoff wrote: > On Fri, Sep 19, 2008 at 3:16 AM, Jerry Vonau wrote: >> Yea, revisor needs anaconda-runtime, >> cat /usr/lib/revisor/scripts/F9-buildinstall | grep anaconda > > Yes, but from what Jeroen has said, revisor will pull it in to satisfy > the need at CD build time, without it being listed in the ks file (and > therefore getting installed on the target system too...) > Revisor for Fedora 9 will not pull any required packages into the composed tree anymore, and here's why; F9-buildinstall shipped with Revisor in Fedora 9 takes additional parameters, which are supposed to represent the repositories used during the compose of the tree (e.g. Packages/ and repodata/). See the YUM config file you used for the model in /etc/revisor/conf.d/. The required packages for buildinstall to run completely have to exist in these repositories but they would have to exist no matter if Revisor wanted to pull them in the composed tree or whether buildinstall can pull them from the repositories directly. Hence the log-file is of interest to me ;-) >> Anaconda-runtime needs to exist in the repo that you use for the compose, >> but doesn't need to be in the kickstart file. Too bad, you have to add >> anaconda-runtime to the kickstart file, to get the package into the compose >> repo, in order to use it later in buildinstall. > > Well, that's supposed to be true for pungi, not true for revisor. > > As far as I understand anyway :-) Jeroen has asked for logs and I'm > collecting some right now... > Yes, anaconda-runtime needs to exist in the repositories you use. Again whether Revisor looks to these repositories for required packages, or whether buildinstall does doesn't matter in this aspect. However, you should not be required you to add it to the kickstart's package manifest. Apparently though, since it does work with anaconda-runtime listed in the package manifest I'm confused because the package seems to be available from the repositories but buildinstall can't seem to find it, judging from Martin's earlier message. Kind regards, Jeroen van Meeuwen -kanarip From martin.langhoff at gmail.com Fri Sep 19 10:37:17 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 19 Sep 2008 22:37:17 +1200 Subject: [Server-devel] Revisor / yum oddity: anaconda-runtime In-Reply-To: <48D37D9D.8070908@kanarip.com> References: <46a038f90809180044l2d64e7c1kf9ce851399b7db04@mail.gmail.com> <48D270D2.6080307@shaw.ca> <46a038f90809182133n381944efo67051d37b99d4f5f@mail.gmail.com> <48D37D9D.8070908@kanarip.com> Message-ID: <46a038f90809190337w4924a9dcs35bae331a18413f9@mail.gmail.com> On Fri, Sep 19, 2008 at 10:23 PM, Jeroen van Meeuwen wrote: > Hence the log-file is of interest to me ;-) Sent it in a private email :-) > Yes, anaconda-runtime needs to exist in the repositories you use. Sorry - I should have clarified - anaconda-runtime *is* in the repos configured. (otherwise, adding it to the ks wouldn't help anyway!) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kanarip at kanarip.com Sat Sep 20 11:20:23 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 20 Sep 2008 13:20:23 +0200 Subject: [Server-devel] Revisor / yum oddity: anaconda-runtime In-Reply-To: <48D3CFA3.9060701@shaw.ca> References: <46a038f90809180044l2d64e7c1kf9ce851399b7db04@mail.gmail.com> <48D270D2.6080307@shaw.ca> <46a038f90809182133n381944efo67051d37b99d4f5f@mail.gmail.com> <48D37D9D.8070908@kanarip.com> <46a038f90809190337w4924a9dcs35bae331a18413f9@mail.gmail.com> <48D3CFA3.9060701@shaw.ca> Message-ID: <48D4DC77.7030104@kanarip.com> Jerry Vonau wrote: > Martin Langhoff wrote: >> On Fri, Sep 19, 2008 at 10:23 PM, Jeroen van Meeuwen >> wrote: >>> Hence the log-file is of interest to me ;-) >> >> Sent it in a private email :-) >> >>> Yes, anaconda-runtime needs to exist in the repositories you use. >> >> Sorry - I should have clarified - anaconda-runtime *is* in the repos >> configured. (otherwise, adding it to the ks wouldn't help anyway!) >> > > "runtime" won't be in the repo that you're "spinning", and that is the > one that buildinstall is going to use: > > if [[ "$REPO" =~ ^/ ]]; then > [ -n "$OUTPUT" ] || OUTPUT=$REPO > REPO="file://$REPO" > > and from the log OUTPUT is set to: > /var/tmp/revisor-pungi/0.5/xs-f9-i386/i386/os > > That is the repo that getting spun right? > That is the composed tree, yes. From the log files though, you can see that more then one repository is used during buildinstall: Running Command: /usr/lib/revisor/scripts/F9-buildinstall --debug \ --product OLPC School Server --variant xs-f9-i386 --version 0.5 \ --release OLPC School Server 0.5 \ /var/tmp/revisor-pungi/0.5/xs-f9-i386/i386/os \ file:///xsrepos/testing/olpc/7/i386/ \ file:///media/disk/xs/releases/9/Everything/i386/os/ \ http://fedora.laptop.org/xs/testing/olpc/9/i386/ All of these should be searched for the anaconda-runtime package... I'm trying to figure out why it isn't so. Kind regards, Jeroen van Meeuwen -kanarip From mikem at redhat.com Mon Sep 22 21:06:37 2008 From: mikem at redhat.com (Mike McLean) Date: Mon, 22 Sep 2008 17:06:37 -0400 Subject: Broken dependencies: perl-Test-AutoBuild In-Reply-To: <1221719901.14439.23.camel@luminos.localdomain> References: <141358781.1369471221713360764.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1221719901.14439.23.camel@luminos.localdomain> Message-ID: <48D808DD.1050703@redhat.com> Jesse Keating wrote: > On Thu, 2008-09-18 at 00:49 -0400, Jens Petersen wrote: >> How does that stop perl-Test-AutoBuild-darcs.noarch getting into ppc64 >> trees? > > ExcludeArch ExcludeArch is odd, and is distinctly tied to the build. Note that only srpms get the ExcludeArch/BuildArchs/ExclusiveArch data in their headers; the built rpms do not have this data. While certain tools might theoretically be able to look up the matching srpm, check this data, and enforce it in some way for the built rpms, I don't believe there is any way to signal such restrictions only for a sub-package. In any case, such use seems a little fragile and sketchy to me. I'm not that familiar with Pungi's capabilities. Can it be told to special-case situations like this with a config? If Pungi is performing the roundabout ExcludeArch lookup I described above, then you might need to split the arch-limited subpackage into its own srpm in order to take advantage of that. I'm not sure if that is any better for you than moving the package away from noarch. From jkeating at redhat.com Mon Sep 22 22:06:48 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 15:06:48 -0700 Subject: Broken dependencies: perl-Test-AutoBuild In-Reply-To: <48D808DD.1050703@redhat.com> References: <141358781.1369471221713360764.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> <1221719901.14439.23.camel@luminos.localdomain> <48D808DD.1050703@redhat.com> Message-ID: <1222121208.4108.38.camel@luminos.localdomain> On Mon, 2008-09-22 at 17:06 -0400, Mike McLean wrote: > While certain tools might theoretically be able to look up the matching > srpm, check this data, and enforce it in some way for the built rpms, I > don't believe there is any way to signal such restrictions only for a > sub-package. In any case, such use seems a little fragile and sketchy to me. > > I'm not that familiar with Pungi's capabilities. Can it be told to > special-case situations like this with a config? Hrm, I need to look up what mash does again, as mash does notice and not put ExcludeArch packages (even noarch ones) where they don't belong. But you're right, it may be on an srpm level not a subpackage level. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- 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 plautrba at redhat.com Tue Sep 30 15:08:43 2008 From: plautrba at redhat.com (Petr Lautrbach) Date: Tue, 30 Sep 2008 17:08:43 +0200 Subject: [PATCH] Makefile.common autodetermine RPM_BUILD_DIR from spec file Message-ID: <48E240FB.6090604@redhat.com> Hello. make patch and make rediff don't work if %setup macro defines with -n other directory than $(NAME)-$(VERSION). Petr From plautrba at redhat.com Tue Sep 30 15:10:15 2008 From: plautrba at redhat.com (Petr Lautrbach) Date: Tue, 30 Sep 2008 17:10:15 +0200 Subject: [PATCH] Makefile.common autodetermine RPM_BUILD_DIR from spec file In-Reply-To: <48E240FB.6090604@redhat.com> References: <48E240FB.6090604@redhat.com> Message-ID: <48E24157.3020505@redhat.com> Petr Lautrbach wrote: > Hello. > > make patch and make rediff don't work if %setup macro defines with -n > other > directory than $(NAME)-$(VERSION). > > patch in attachment Petr -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile.common-patch-rediff.patch URL: