From fedora at leemhuis.info Sun Oct 22 14:40:01 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 22 Oct 2006 16:40:01 +0200 Subject: build kmods for ppc64 (was: Re: exclude arch for PPC64) In-Reply-To: <1161526587.3139.8.camel@vader.jdub.homelinux.org> References: <1161429764.3709.50.camel@T7.Linux> <1161470321.2909.186.camel@localhost.localdomain> <1161476537.3139.1.camel@vader.jdub.homelinux.org> <1161509443.3709.79.camel@T7.Linux> <1161526587.3139.8.camel@vader.jdub.homelinux.org> Message-ID: <453B82C1.6080602@leemhuis.info> Josh Boyer schrieb: > [...] > So, I'd need to see logs of it failing on ppc64 because as far as I > know, Extras doesn't even build ppc64 packages so you shouldn't even be > having a problem... Side note: We should at least build the kmods for PPC64. That's possible in mock, but we don't support that on our builders ATM. I don't even know if it's possible at all in current plague without building all the other stuff for ppc64, too. CU thl From jkeating at redhat.com Tue Oct 24 03:01:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 23 Oct 2006 23:01:45 -0400 Subject: New project, possibly share email list? Message-ID: <200610232301.45797.jkeating@redhat.com> I've started a new project, a tool to compose fedora releases, this time open source (: Its a candidate for the official tool to allow Fedora users to make their own spins of Fedora with whatever packages they want. Instead of creating Yet Another Mailing list, it was suggested that I make use of this one, given plague/mock use it, and this could potentially fit into the same space. I'm finally ready to announce the project and start getting folks talking about it and maybe contributing, so I'd like to ask your thoughts on using this list. So, thoughts? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Matt_Domsch at dell.com Tue Oct 24 03:36:25 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 23 Oct 2006 22:36:25 -0500 Subject: New project, possibly share email list? In-Reply-To: <200610232301.45797.jkeating@redhat.com> References: <200610232301.45797.jkeating@redhat.com> Message-ID: <20061024033625.GA3752@lists.us.dell.com> On Mon, Oct 23, 2006 at 11:01:45PM -0400, Jesse Keating wrote: > Instead of creating Yet Another Mailing list, it was suggested that I make use > of this one, given plague/mock use it, and this could potentially fit into > the same space. I'm finally ready to announce the project and start getting > folks talking about it and maybe contributing, so I'd like to ask your > thoughts on using this list. > > So, thoughts? Seems sane to me. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From giallu at gmail.com Tue Oct 24 06:36:50 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 24 Oct 2006 08:36:50 +0200 Subject: New project, possibly share email list? In-Reply-To: <200610232301.45797.jkeating@redhat.com> References: <200610232301.45797.jkeating@redhat.com> Message-ID: On 10/24/06, Jesse Keating wrote: > I've started a new project, a tool to compose fedora releases, this time open > source (: Its a candidate for the official tool to allow Fedora users to > make their own spins of Fedora with whatever packages they want. Is there any planned integration with kadischi, so one will get a live-spin? > > Instead of creating Yet Another Mailing list, it was suggested that I make use > of this one, given plague/mock use it, and this could potentially fit into > the same space. I'm finally ready to announce the project and start getting > folks talking about it and maybe contributing, so I'd like to ask your > thoughts on using this list. +1 From jkeating at redhat.com Tue Oct 24 12:17:04 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Oct 2006 08:17:04 -0400 Subject: New project, possibly share email list? In-Reply-To: References: <200610232301.45797.jkeating@redhat.com> Message-ID: <200610240817.07761.jkeating@redhat.com> On Tuesday 24 October 2006 02:36, Gianluca Sforna wrote: > Is there any planned integration with kadischi, so one will get a > live-spin? It could/should integrate with whatever the 'official' live CD becomes. There are serious doubts about kadischi becoming that. For right now I'm trying to keep it simple and handle the traditional install tree and isos, since that framework already exists. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Tue Oct 24 21:53:04 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 24 Oct 2006 17:53:04 -0400 Subject: New Project: pungi - A Fedora release composing tool Message-ID: <200610241753.07447.jkeating@redhat.com> I have started a new project, by the name of Pungi. This project aims to be a tool to compose Fedora releases. The goals include simplicity of both code and interface. I hope it will be a candidate for the Fedora Project's official tool to create user specific composes of Fedora comprising of both Core and Extras packages (or just Fedora packages once things merge) as well as the tool to compose the official Fedora Project spin of Fedora. It should prove useful to anybody creating a Fedora based distribution as well. The project is GPLv2 licensed. How it (I hope) works: A package list is fed into Pungi, either by comps or some other means. A set of yum repos to find packages in are also fed in. Pungi will search for matching packages in the set of repos and add the package to the download list. The download lost is depclosed (somewhat different than depsolved, no local rpmdb involved), all the deps that are pulled in are depclosed, etc... The list of packages is then downloaded into a configured cache dir and hardlinked into an arch specific dir within a configured destination dir. Then anaconda provided tools such as buildinstall, pkgorder, and splittree are ran on the directory of packages turning it into an installable tree and splitting packages into CD iso sized sets. Mkisofs would be used to create teh CD isos and DVD iso. These are the basic steps. The tool could further be extended to run some simple tree sanity to ensure the compose completed correctly, or other post processing type things. How to help: The code for this project lives in a public mercurial repository: hg clone http://linux.duke.edu/projects/pungi pungi Write access is via ssh and can be given upon (validated) request. Discussion of the project will make use of the fedora-buildsys-list at redhat.com mailing list. There are no web pages (other than the hg-web interface at the above URL) currently. The source includes information about design and some files for testing functionality. Since this is my first 'from scratch' python project, I welcome input not only on code content but code design, project layout, etc.. Also, even though I work for Red Hat, this is not so much a Red Hat software project. I'm developing this in the community space, a lot on my own time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jstodaro at us.ibm.com Wed Oct 25 15:08:33 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Wed, 25 Oct 2006 11:08:33 -0400 Subject: New Project: pungi - A Fedora release composing tool In-Reply-To: <200610241753.07447.jkeating@redhat.com> Message-ID: Hmm... so, how will it be different from Yam? http://dag.wieers.com/home-made/yam/ -Joe Jesse Keating Sent by: fedora-buildsys-list-bounces at redhat.com 10/24/2006 05:53 PM Please respond to Discussion of Fedora build system To fedora-buildsys-list at redhat.com, fedora-devel-list at redhat.com, kickstart-list at redhat.com cc Subject New Project: pungi - A Fedora release composing tool I have started a new project, by the name of Pungi. This project aims to be a tool to compose Fedora releases. The goals include simplicity of both code and interface. I hope it will be a candidate for the Fedora Project's official tool to create user specific composes of Fedora comprising of both Core and Extras packages (or just Fedora packages once things merge) as well as the tool to compose the official Fedora Project spin of Fedora. It should prove useful to anybody creating a Fedora based distribution as well. The project is GPLv2 licensed. How it (I hope) works: A package list is fed into Pungi, either by comps or some other means. A set of yum repos to find packages in are also fed in. Pungi will search for matching packages in the set of repos and add the package to the download list. The download lost is depclosed (somewhat different than depsolved, no local rpmdb involved), all the deps that are pulled in are depclosed, etc... The list of packages is then downloaded into a configured cache dir and hardlinked into an arch specific dir within a configured destination dir. Then anaconda provided tools such as buildinstall, pkgorder, and splittree are ran on the directory of packages turning it into an installable tree and splitting packages into CD iso sized sets. Mkisofs would be used to create teh CD isos and DVD iso. These are the basic steps. The tool could further be extended to run some simple tree sanity to ensure the compose completed correctly, or other post processing type things. How to help: The code for this project lives in a public mercurial repository: hg clone http://linux.duke.edu/projects/pungi pungi Write access is via ssh and can be given upon (validated) request. Discussion of the project will make use of the fedora-buildsys-list at redhat.com mailing list. There are no web pages (other than the hg-web interface at the above URL) currently. The source includes information about design and some files for testing functionality. Since this is my first 'from scratch' python project, I welcome input not only on code content but code design, project layout, etc.. Also, even though I work for Red Hat, this is not so much a Red Hat software project. I'm developing this in the community space, a lot on my own time. -- Jesse Keating Release Engineer: Fedora [attachment "attnbvg5.dat" deleted by Joe Todaro/Poughkeepsie/IBM] -- Fedora-buildsys-list mailing list Fedora-buildsys-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Wed Oct 25 15:56:21 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Oct 2006 11:56:21 -0400 Subject: New Project: pungi - A Fedora release composing tool In-Reply-To: References: Message-ID: <200610251156.21385.jkeating@redhat.com> On Wednesday 25 October 2006 11:08, Joe Todaro wrote: > Hmm... so, how will it be different from Yam? > ? > http://dag.wieers.com/home-made/yam/ Yam builds a local APT/Yum RPM repository from local ISO files, downloaded updates, and extra packages from 3rd party repositories. It takes care of setting up the ISO files, downloading the RPMs, configuring HTTP access and providing PXE/TFTP resources for remote network installations. There is some similar functionality in that it gathers packages and creates a repo. As far as I can tell, yam doesn't use any anaconda tools to create any installable tree. Rather it duplicates what already exists on isos, and adds other packages as other repos in a directory. Also there is nothing to create isos that can be distributed. Pungi would be used to produce a set of isos and an installable repository that yam would work FROM. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jaroslav at aster.pl Wed Oct 25 17:46:15 2006 From: jaroslav at aster.pl (Jaroslaw Gorny) Date: Wed, 25 Oct 2006 19:46:15 +0200 Subject: pungi (options error messages fix) Message-ID: <200610251946.15285.jaroslav@aster.pl> Hi, pungi sounds like a good idea for me ;) I'm in need for such a tool from time to time. I'll try to look deeper in the code and make some constructive questions about it, as for now, this is the trivial patch that fixes some error messages. regards, -- Jaroslaw Gorny -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-opts-error-messages.diff Type: text/x-diff Size: 1720 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Oct 25 18:01:12 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Oct 2006 14:01:12 -0400 Subject: pungi (options error messages fix) In-Reply-To: <200610251946.15285.jaroslav@aster.pl> References: <200610251946.15285.jaroslav@aster.pl> Message-ID: <200610251401.12737.jkeating@redhat.com> On Wednesday 25 October 2006 13:46, Jaroslaw Gorny wrote: > Hi, > pungi sounds like a good idea for me ;) I'm in need for such a tool from > time to time. > > I'll try to look deeper in the code and make some constructive questions > about it, as for now, this is the trivial patch that fixes some error > messages. Thanks for the patch! The error stuff was *cough* borrowed *cough* from other project, so I'm not surprised I've introduced some typos there. I never make mistakes so I've never seen the errors come up... (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Wed Oct 25 18:11:42 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Oct 2006 14:11:42 -0400 Subject: pungi (options error messages fix) In-Reply-To: <200610251401.12737.jkeating@redhat.com> References: <200610251946.15285.jaroslav@aster.pl> <200610251401.12737.jkeating@redhat.com> Message-ID: <200610251411.42844.jkeating@redhat.com> On Wednesday 25 October 2006 14:01, Jesse Keating wrote: > > I'll try to look deeper in the code and make some constructive questions > > about it, as for now, this is the trivial patch that fixes some error > > messages. > > Thanks for the patch! ?The error stuff was *cough* borrowed *cough* from > other project, so I'm not surprised I've introduced some typos there. ?I > never make mistakes so I've never seen the errors come up... (: And committed. Thanks again! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From brkamikaze at gmail.com Wed Oct 25 19:42:09 2006 From: brkamikaze at gmail.com (Nikolai) Date: Wed, 25 Oct 2006 16:42:09 -0300 Subject: New Project: pungi - A Fedora release composing tool In-Reply-To: <200610241753.07447.jkeating@redhat.com> References: <200610241753.07447.jkeating@redhat.com> Message-ID: That's a great tool, I was even wondering how to customize a installation CD or how to create another CD to install my favorite extras/livna packages without the need for networking on the new PC :) I'm just learning python, and I think that following a new project will be great for studies. I'll help when I can. From williams at redhat.com Wed Oct 25 20:06:21 2006 From: williams at redhat.com (Clark Williams) Date: Wed, 25 Oct 2006 15:06:21 -0500 Subject: Mock hangs - why? In-Reply-To: <20060814145837.15510.qmail@web35908.mail.mud.yahoo.com> References: <20060814145837.15510.qmail@web35908.mail.mud.yahoo.com> Message-ID: <453FC3BD.4050704@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Al Pacifico wrote: > I have fifteen CPAN packages that I'm packaging as > RPMs for FC5, and one (and only one) of them seems to > hang mock. Is this an appropriate place to ask for > advice? > Thanks. > -al Sure, although you could file a bugzilla on mock as well. Won't hurt my feelings. Which package hangs? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFP8O9Hyuj/+TTEp0RArjgAKCfx9tSuU/1JDvTEsYEqOpkMwEbXQCgyDlS Q5EUyR2iqlvlgKJcOhqWKe8= =hn/Z -----END PGP SIGNATURE----- From jkeating at redhat.com Wed Oct 25 20:08:37 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 25 Oct 2006 16:08:37 -0400 Subject: New Project: pungi - A Fedora release composing tool In-Reply-To: References: <200610241753.07447.jkeating@redhat.com> Message-ID: <200610251608.38101.jkeating@redhat.com> On Wednesday 25 October 2006 15:42, Nikolai wrote: > I'm just learning python, and I think that following a new project > will be great for studies. I'll help when I can. Great! I'd recommend subscribing to the fedora-buildsys-list mailing list. https://www.redhat.com/mailman/listinfo/fedora-buildsys-list That's where continued discussion of the project will happen. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sodarock at gmail.com Wed Oct 25 23:50:36 2006 From: sodarock at gmail.com (John Villalovos) Date: Wed, 25 Oct 2006 16:50:36 -0700 Subject: Using mock with SuSE Linux Enterprise Desktop? Message-ID: <5e61b72f0610251650s1f69548bs234e622eac8ab533@mail.gmail.com> Has anyone done any work using Mock with SuSE Linux Enterprise Desktop? We are working on a project where we need to build RPMS for Fedora, RHEL, SLED, and maybe OpenSuSE. So Mock looked like a cool tool to use. I've got it working with Fedora and have found info for RHEL/CentOS stuff. I've found a little bit of info for SuSE but it looks like it was done before Mock 0.5 came out. Thanks for any info! John From tibbs at math.uh.edu Thu Oct 26 00:24:12 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 25 Oct 2006 19:24:12 -0500 Subject: Mock hangs - why? In-Reply-To: <20060814145837.15510.qmail@web35908.mail.mud.yahoo.com> (Al Pacifico's message of "Mon, 14 Aug 2006 07:58:37 -0700 (PDT)") References: <20060814145837.15510.qmail@web35908.mail.mud.yahoo.com> Message-ID: >>>>> "AP" == Al Pacifico writes: AP> I have fifteen CPAN packages that I'm packaging as RPMs for FC5, AP> and one (and only one) of them seems to hang mock. Is this an AP> appropriate place to ask for advice? I have seen this happen when packages using Module::Build are missing a BuildRequires:; the package stops and asks for input, which looks like a hang. Try prepending "echo |" to the command where it hangs and see if you get any further. - J< From dcbw at redhat.com Thu Oct 26 02:06:08 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 25 Oct 2006 22:06:08 -0400 Subject: Using mock with SuSE Linux Enterprise Desktop? In-Reply-To: <5e61b72f0610251650s1f69548bs234e622eac8ab533@mail.gmail.com> References: <5e61b72f0610251650s1f69548bs234e622eac8ab533@mail.gmail.com> Message-ID: <1161828368.3102.0.camel@localhost.localdomain> On Wed, 2006-10-25 at 16:50 -0700, John Villalovos wrote: > Has anyone done any work using Mock with SuSE Linux Enterprise > Desktop? We are working on a project where we need to build RPMS for > Fedora, RHEL, SLED, and maybe OpenSuSE. People have done this, yes. I believe only a few modifications were needed for some differences in how users are added on SUSE, just modifications to the 'useradd' command. You then need repositories of SUSE RPMs that have been generated with createrepo. Dan > So Mock looked like a cool tool to use. I've got it working with > Fedora and have found info for RHEL/CentOS stuff. > > I've found a little bit of info for SuSE but it looks like it was done > before Mock 0.5 came out. > > Thanks for any info! > John > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From Matt_Domsch at dell.com Thu Oct 26 02:14:24 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 25 Oct 2006 21:14:24 -0500 Subject: Using mock with SuSE Linux Enterprise Desktop? In-Reply-To: <5e61b72f0610251650s1f69548bs234e622eac8ab533@mail.gmail.com> References: <5e61b72f0610251650s1f69548bs234e622eac8ab533@mail.gmail.com> Message-ID: <20061026021424.GA4028@lists.us.dell.com> On Wed, Oct 25, 2006 at 04:50:36PM -0700, John Villalovos wrote: > Has anyone done any work using Mock with SuSE Linux Enterprise > Desktop? We are working on a project where we need to build RPMS for > Fedora, RHEL, SLED, and maybe OpenSuSE. > > So Mock looked like a cool tool to use. I've got it working with > Fedora and have found info for RHEL/CentOS stuff. > > I've found a little bit of info for SuSE but it looks like it was done > before Mock 0.5 came out. We do for firmware-tools and libsmbios. http://linux.dell.com/files/mock/ has our configs etc. SLES 9 and 10 work. I don't know that opensuse-10.* work. -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From dcbw at redhat.com Thu Oct 26 15:35:48 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 26 Oct 2006 11:35:48 -0400 Subject: Extras build system back up In-Reply-To: <20051017212801.GJ5856@shell0.pdx.osdl.net> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> Message-ID: <1161876948.2927.40.camel@localhost.localdomain> On Mon, 2005-10-17 at 14:28 -0700, Chris Wright wrote: > * Dan Williams (dcbw at redhat.com) wrote: > > As I see you've figured out, it should be fixed now. Server-side issue > > with some database fields being way too small. They are larger now :) > > Yes, thanks. Is > > [Server] > ... > allow_uploads = True > > the recommended change to config? Sorry for the lag... allow_uploads should only be configured if you're using SRPM-only building and you want to allow people to upload random SRPMs to the build server. It's useless for CVS builds. Dan > I notice plague list once creates config with > > allow_uploads = no > > thanks, > -chris > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From dcbw at redhat.com Thu Oct 26 15:36:58 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 26 Oct 2006 11:36:58 -0400 Subject: Extras build system back up In-Reply-To: <20051017212801.GJ5856@shell0.pdx.osdl.net> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017201619.GB30904@shell0.pdx.osdl.net> <1129583751.1418.3.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> Message-ID: <1161877018.2927.41.camel@localhost.localdomain> On Mon, 2005-10-17 at 14:28 -0700, Chris Wright wrote: > * Dan Williams (dcbw at redhat.com) wrote: > > As I see you've figured out, it should be fixed now. Server-side issue > > with some database fields being way too small. They are larger now :) > > Yes, thanks. Is > > [Server] > ... > allow_uploads = True Haha, I just saw this was sent over a year ago. Yay for evolution and threaded message lists. > the recommended change to config? > > I notice plague list once creates config with > > allow_uploads = no > > thanks, > -chris > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From jkeating at redhat.com Thu Oct 26 15:40:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 26 Oct 2006 11:40:45 -0400 Subject: Extras build system back up In-Reply-To: <1161877018.2927.41.camel@localhost.localdomain> References: <1129572538.28887.1.camel@dhcp83-40.boston.redhat.com> <20051017212801.GJ5856@shell0.pdx.osdl.net> <1161877018.2927.41.camel@localhost.localdomain> Message-ID: <200610261140.45710.jkeating@redhat.com> On Thursday 26 October 2006 11:36, Dan Williams wrote: > Haha, I just saw this was sent over a year ago. ?Yay for evolution and > threaded message lists. That was me, I cleared out the moderator backlog. (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sodarock at gmail.com Thu Oct 26 20:30:17 2006 From: sodarock at gmail.com (John Villalovos) Date: Thu, 26 Oct 2006 13:30:17 -0700 Subject: Using mock with SuSE Linux Enterprise Desktop? In-Reply-To: <20061026021424.GA4028@lists.us.dell.com> References: <5e61b72f0610251650s1f69548bs234e622eac8ab533@mail.gmail.com> <20061026021424.GA4028@lists.us.dell.com> Message-ID: <5e61b72f0610261330u14bd68f8kaa64ae4c02c9e531@mail.gmail.com> On 10/25/06, Matt Domsch wrote: > On Wed, Oct 25, 2006 at 04:50:36PM -0700, John Villalovos wrote: > > Has anyone done any work using Mock with SuSE Linux Enterprise > > Desktop? We are working on a project where we need to build RPMS for > > Fedora, RHEL, SLED, and maybe OpenSuSE. > > > > So Mock looked like a cool tool to use. I've got it working with > > Fedora and have found info for RHEL/CentOS stuff. > > > > I've found a little bit of info for SuSE but it looks like it was done > > before Mock 0.5 came out. > > We do for firmware-tools and libsmbios. > http://linux.dell.com/files/mock/ > has our configs etc. SLES 9 and 10 work. I don't know that > opensuse-10.* work. Thanks I will look into it and also take a look at the stuff that Dan mentioned. John From jstodaro at us.ibm.com Fri Oct 27 04:32:45 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Fri, 27 Oct 2006 00:32:45 -0400 Subject: PATCH: SSL.SysCallError fix for plague-0.5.0 Message-ID: Hi, Has anyone ever seen this error before in their *plague-0.5.0* build environment? It surfaced last week shortly after we started stress-testing our buildsystem. In fact, there were three such errors in all, which I will post separately to avoid any confusion. This is one of three. It was triggered when we requested status about a job we killed before it actually got handed-off to archjobs. ====== THE ERROR ======- Request to enqueue 'stacker' tag 'stacker-1_3-5' for target 'oc-rhel4-dev' (user 'jtodaro at pok.ibm.com') 66 (stacker): Starting tag 'stacker-1_3-5' on target 'oc-rhel4-dev' 66 (stacker): Requesting depsolve... 66 (stacker): Starting depsolve for arches: ['i686']. 66 (stacker): Finished depsolve (successful), requesting archjobs. 66 (stacker/i686): https://lnxbuild1.pok.ibm.com.:8888 - UID is 9adf56cdd15bfae2388966b08837250d3bf6772c ---------------------------------------- Exception happened during processing of request from ('10.63.82.73', 49136) Traceback (most recent call last): File "/usr/lib64/python2.3/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address) File "/usr/lib64/python2.3/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/lib64/python2.3/SocketServer.py", line 521, in __init__ self.handle() File "/usr/lib64/python2.3/BaseHTTPServer.py", line 324, in handle self.handle_one_request() File "/usr/lib64/python2.3/BaseHTTPServer.py", line 307, in handle_one_request self.raw_requestline = self.rfile.readline() File "/usr/lib64/python2.3/socket.py", line 338, in readline data = self._sock.recv(self._rbufsize) File "/usr/lib/python2.3/site-packages/plague/SSLConnection.py", line 142, in recv return con.recv(bufsize, flags) SysCallError: (-1, 'Unexpected EOF') ---------------------------------------- ====== OUR FIX ====== We added lines 147-148 to the *recv* method of the */usr/lib/python2.3/site-packages/plague/SSLConnection.py* module. Here's the patch: So, can someone please review the above fix.. We want to make sure it won't come back to *bite* us later on / or possibly evn be *masking* a larger problem. Thank you. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SSLConnection.py-SysCallError-fix.patch Type: application/octet-stream Size: 384 bytes Desc: not available URL: From jstodaro at us.ibm.com Fri Oct 27 05:11:15 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Fri, 27 Oct 2006 01:11:15 -0400 Subject: PATCH: job.die fix for plague-0.5.0 Message-ID: Hi, Has anyone ever seen this error before in their *plague-0.5.0* build environment? This is error two of three, which I mentioned in my previous post. It too surfaced last week shortly after we started stress-testing our buildsystem. There were three such errors in all, which I've posted separately to avoid any confusion. This particular error seemed to trigger when we attempted to kill a job we didn't know had already failed the depsolve stage. ====== THE ERROR ====== 146 (cfengine): Requesting depsolve... 146 (cfengine): Starting depsolve for arches: ['x86_64', 'i386', 'i686']. Cannot open/read repomd.xml file for repository: plague failure: repodata/repomd.xml from plague: [Errno 256] No more mirrors to try. 146 (cfengine/x86_64): Depsolve Error: failure: repodata/repomd.xml from plague: [Errno 256] No more mirrors to try. 146 (cfengine): Finished depsolve (unsuccessful), trying again later. 145 (cfengine): Job kill request from jtodaro at pok.ibm.com 145 (cfengine): Build on target oc-rhel4-rel was killed by jtodaro at pok.ibm.com. Exception in thread PackageJob: 145/cfengine: Traceback (most recent call last): File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap self.run() File "/usr/share/plague/server/PackageJob.py", line 86, in run self._pkg_job.process() File "/usr/share/plague/server/PackageJob.py", line 745, in process self._handle_death() File "/usr/share/plague/server/PackageJob.py", line 725, in _handle_death self._kill_all_archjobs(True) File "/usr/share/plague/server/PackageJob.py", line 737, in _kill_all_archjobs job.die(user_requested) AttributeError: 'NoneType' object has no attribute 'die' ====== OUR FIX ====== We added lines 710-711 to the *_kill_all_archjobs* method of the * /usr/share/plague/server/PackageJob.py * module. Here's the patch: So, can someone please review the above fix.. Again, we just want to make sure that it won't come back to *bite* us later on / or possibly even be *masking* a larger problem. Thank you. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PackageJob.py-die-fix.patch Type: application/octet-stream Size: 446 bytes Desc: not available URL: From jstodaro at us.ibm.com Fri Oct 27 06:01:43 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Fri, 27 Oct 2006 02:01:43 -0400 Subject: PATCH: depsolve-kill fix for plague-0.5.0 Message-ID: Hi, Has anyone ever seen a yum/depsolve-related error like this before in their *plague-0.5.0* build environment, and then tried *killing* the job that had caused it? This was problem three of three which I had mentioned in my previous posts. And it too had surfaced last week while we started stress-testing our buildsystem. Actually, the error you see below in itself was *not* the problem (we knew how to fix that) -- rather, it was the fact that we were *unable* to kill the job (plague-client kill 204) that was responsible for causing the error. ====== THE ERROR ====== 204 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on target 'oc-rhel4-pre' 204 (fuse-sshfs): Requesting depsolve... 204 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386', 'i686']. Exception in thread PackageJob: 204/fuse-sshfs: Traceback (most recent call last): File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap self.run() File "/usr/share/plague/server/PackageJob.py", line 86, in run self._pkg_job.process() File "/usr/share/plague/server/PackageJob.py", line 753, in process if func(): File "/usr/share/plague/server/PackageJob.py", line 618, in _stage_depsolve if self._arch_deps_solved(arch) == False: File "/usr/share/plague/server/PackageJob.py", line 562, in _arch_deps_solved except yum.Errors.PackageSackError, exc: AttributeError: 'module' object has no attribute 'PackageSackError' ====== OUR FIX ====== We updated line 680 in the *die* method of the */usr/share/plague/server/PackageJob.py * module. Here's the patch: Again, can someone please review the fix.. We just want to make sure that it won't come back to *haunt* us later on / or possibly even be *masking* another problem. Thank you. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PackageJob.py-depsolvekill-fix.patch Type: application/octet-stream Size: 530 bytes Desc: not available URL: From dcbw at redhat.com Mon Oct 30 20:53:13 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 30 Oct 2006 15:53:13 -0500 Subject: PATCH: depsolve-kill fix for plague-0.5.0 In-Reply-To: References: Message-ID: <1162241593.11682.7.camel@localhost.localdomain> On Fri, 2006-10-27 at 02:01 -0400, Joe Todaro wrote: > > Hi, > > Has anyone ever seen a yum/depsolve-related error like this before in > their *plague-0.5.0* build environment, and then tried *killing* the > job that had caused it? This was problem three of three which I had > mentioned in my previous posts. And it too had surfaced last week > while we started stress-testing our buildsystem. Actually, the error > you see below in itself was *not* the problem (we knew how to fix > that) -- rather, it was the fact that we were *unable* to kill the job > (plague-client kill 204) that was responsible for causing the error. Can you tell me a few things about your plague server? 1) What version of yum is it running? 2) What version of yum-utils if any? 3) the output of: rpm -qf /usr/lib/python2.3/site-packages/repomd/mdErrors.py rpm -qf /usr/lib/python2.4/site-packages/repomd/mdErrors.py 4) Next, can you try: python >>> import repomd.mdErrors >>> repomd.mdErrors.PackageSackError 5) Then try: python >>> import yum >>> yum.Errors.PackageSackError I think this is an issue of the yum depsolve stuff moving from yum-utils to yum itself, we just need to figure out what the permutations are and then work around them in the source. Thanks, Dan > ====== THE ERROR ====== > 204 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on target > 'oc-rhel4-pre' > 204 (fuse-sshfs): Requesting depsolve... > 204 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386', > 'i686']. > Exception in thread PackageJob: 204/fuse-sshfs: > Traceback (most recent call last): > File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap > self.run() > File "/usr/share/plague/server/PackageJob.py", line 86, in run > self._pkg_job.process() > File "/usr/share/plague/server/PackageJob.py", line 753, in process > if func(): > File "/usr/share/plague/server/PackageJob.py", line 618, in > _stage_depsolve > if self._arch_deps_solved(arch) == False: > File "/usr/share/plague/server/PackageJob.py", line 562, in > _arch_deps_solved > except yum.Errors.PackageSackError, exc: > AttributeError: 'module' object has no attribute 'PackageSackError' > > ====== OUR FIX ====== > We updated line 680 in the *die* method of the > */usr/share/plague/server/PackageJob.py * module. Here's the patch: > > > Again, can someone please review the fix.. We just want to make sure > that it won't come back to *haunt* us later on / or possibly even be > *masking* another problem. Thank you. > > -Joe > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From eklitzke at gmail.com Tue Oct 31 06:36:56 2006 From: eklitzke at gmail.com (Evan Klitzke) Date: Mon, 30 Oct 2006 22:36:56 -0800 Subject: plague-server issues (4.4.1) Message-ID: Hello everyone, I have been trying to get plague working. I have installed the plague programs that come with Fedora Core 6 (4.4.1). When running plague-server, I get the following error: [evan at thinkpad ~]$ plague-server Using database engine sqlite. Builders: ------------------------------------------------------------------------------------------ http://127.0.0.1:8888 i386 i486 i586 i686 athlon noarch alive Traceback (most recent call last): File "/usr/bin/plague-server", line 198, in ? main() File "/usr/bin/plague-server", line 152, in main bm_server.register_instance(ui) AttributeError: 'NoneType' object has no attribute 'register_instance' As a consequence, plague-client cannot connect to the server -- connection attempts always return '(111, 'Connection refused')'. Does anyone know if this is a known issue that has been fixed in a newer release? Alternatively, is there a way to get lots of debugging/logging output? I poked around the code a bit, but I'm not really sure how I would go about debugging it. I have also tried the CVS snapshot, but I had problems importing the yum logger module, presumably because this is a yum feature that isn't in FC6. I wouldn't mind using the CVS checkout if it fixes the aforementioned problem, but I'd rather not have to upgrade a bunch of other programs to bleeding edge versions to get plague working. -- Evan Klitzke From jstodaro at us.ibm.com Tue Oct 31 12:39:37 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Tue, 31 Oct 2006 07:39:37 -0500 Subject: PATCH: depsolve-kill fix for plague-0.5.0 In-Reply-To: <1162241593.11682.7.camel@localhost.localdomain> Message-ID: Dan Williams wrote on 10/30/2006 03:53:13 PM: > On Fri, 2006-10-27 at 02:01 -0400, Joe Todaro wrote: > > > > Hi, > > > > Has anyone ever seen a yum/depsolve-related error like this before in > > their *plague-0.5.0* build environment, and then tried *killing* the > > job that had caused it? This was problem three of three which I had > > mentioned in my previous posts. And it too had surfaced last week > > while we started stress-testing our buildsystem. Actually, the error > > you see below in itself was *not* the problem (we knew how to fix > > that) -- rather, it was the fact that we were *unable* to kill the job > > (plague-client kill 204) that was responsible for causing the error. > > Can you tell me a few things about your plague server? > > 1) What version of yum is it running? yum-2.4.2-2 > 2) What version of yum-utils if any? yum-utils-0.5-1.c4 > 3) the output of: > > rpm -qf /usr/lib/python2.3/site-packages/repomd/mdErrors.py yum-2.4.2-2 > rpm -qf /usr/lib/python2.4/site-packages/repomd/mdErrors.py error: file /usr/lib/python2.4/site-packages/repomd/mdErrors.py: No such file or directory > > 4) Next, can you try: > > python > >>> import repomd.mdErrors > >>> repomd.mdErrors.PackageSackError Python 2.3.4 (#1, Feb 6 2006, 10:38:45) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import repomd.mdErrors >>> repomd.mdErrors.PackageSackError >>> > > 5) Then try: > > python > >>> import yum > >>> yum.Errors.PackageSackError Python 2.3.4 (#1, Feb 6 2006, 10:38:45) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import yum >>> yum.Errors.PackageSackError Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'PackageSackError' >>> > > > I think this is an issue of the yum depsolve stuff moving from yum-utils > to yum itself, we just need to figure out what the permutations are and > then work around them in the source. > > > Thanks, > Dan Thank You, Joe > > > ====== THE ERROR ====== > > 204 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on target > > 'oc-rhel4-pre' > > 204 (fuse-sshfs): Requesting depsolve... > > 204 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386', > > 'i686']. > > Exception in thread PackageJob: 204/fuse-sshfs: > > Traceback (most recent call last): > > File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap > > self.run() > > File "/usr/share/plague/server/PackageJob.py", line 86, in run > > self._pkg_job.process() > > File "/usr/share/plague/server/PackageJob.py", line 753, in process > > if func(): > > File "/usr/share/plague/server/PackageJob.py", line 618, in > > _stage_depsolve > > if self._arch_deps_solved(arch) == False: > > File "/usr/share/plague/server/PackageJob.py", line 562, in > > _arch_deps_solved > > except yum.Errors.PackageSackError, exc: > > AttributeError: 'module' object has no attribute 'PackageSackError' > > > > ====== OUR FIX ====== > > We updated line 680 in the *die* method of the > > */usr/share/plague/server/PackageJob.py * module. Here's the patch: > > > > > > Again, can someone please review the fix.. We just want to make sure > > that it won't come back to *haunt* us later on / or possibly even be > > *masking* another problem. Thank you. > > > > -Joe > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstodaro at us.ibm.com Tue Oct 31 15:19:37 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Tue, 31 Oct 2006 10:19:37 -0500 Subject: What happened to the plague-0.5.0 push scripts -- like extras-push-new, ExtrasPushUtils.py, etc -- they're gone!!! Message-ID: Does anyone know what happened to the following *plague-0.5.0* programs? File: ExtrasMultiLib.py Status: Entry Invalid File: ExtrasPushUtils.py Status: Entry Invalid File: extras-push-new Status: Entry Invalid File: extras-repobuild.py Status: Entry Invalid File: extras-repoview.py Status: Entry Invalid File: extras-sync Status: Entry Invalid ... they seem to have _disappeared_ from the extras-buildsys/utils module in the CVS tree.. Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Tue Oct 31 15:32:26 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 31 Oct 2006 10:32:26 -0500 Subject: PATCH: depsolve-kill fix for plague-0.5.0 In-Reply-To: References: Message-ID: <1162308746.3155.7.camel@localhost.localdomain> On Tue, 2006-10-31 at 07:39 -0500, Joe Todaro wrote: > > Dan Williams wrote on 10/30/2006 03:53:13 PM: > > > On Fri, 2006-10-27 at 02:01 -0400, Joe Todaro wrote: > > > > > > Hi, > > > > > > Has anyone ever seen a yum/depsolve-related error like this before > in > > > their *plague-0.5.0* build environment, and then tried *killing* > the > > > job that had caused it? This was problem three of three which I > had > > > mentioned in my previous posts. And it too had surfaced last > week > > > while we started stress-testing our buildsystem. Actually, the > error > > > you see below in itself was *not* the problem (we knew how to fix > > > that) -- rather, it was the fact that we were *unable* to kill the > job > > > (plague-client kill 204) that was responsible for causing the > error. > > > > Can you tell me a few things about your plague server? > > > > 1) What version of yum is it running? > > yum-2.4.2-2 > > > 2) What version of yum-utils if any? > > yum-utils-0.5-1.c4 > > > 3) the output of: > > > > rpm -qf /usr/lib/python2.3/site-packages/repomd/mdErrors.py > > yum-2.4.2-2 > > > rpm -qf /usr/lib/python2.4/site-packages/repomd/mdErrors.py > > error: file /usr/lib/python2.4/site-packages/repomd/mdErrors.py: No > such file or directory > > > > > 4) Next, can you try: > > > > python > > >>> import repomd.mdErrors > > >>> repomd.mdErrors.PackageSackError > > Python 2.3.4 (#1, Feb 6 2006, 10:38:45) > [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 > Type "help", "copyright", "credits" or "license" for more > information. > >>> import repomd.mdErrors > >>> repomd.mdErrors.PackageSackError > > >>> > > > > > 5) Then try: > > > > python > > >>> import yum > > >>> yum.Errors.PackageSackError > > Python 2.3.4 (#1, Feb 6 2006, 10:38:45) > [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 > Type "help", "copyright", "credits" or "license" for more > information. > >>> import yum > >>> yum.Errors.PackageSackError > Traceback (most recent call last): > File "", line 1, in ? > AttributeError: 'module' object has no attribute 'PackageSackError' > >>> Ok, that tells me what I need to know. I think we need to conditionalize the except statements from around the line in which you were having the error. I'll see what I can do. Dan > > > > > > I think this is an issue of the yum depsolve stuff moving from > yum-utils > > to yum itself, we just need to figure out what the permutations are > and > > then work around them in the source. > > > > > > Thanks, > > Dan > > Thank You, > Joe > > > > > > ====== THE ERROR ====== > > > 204 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on > target > > > 'oc-rhel4-pre' > > > 204 (fuse-sshfs): Requesting depsolve... > > > 204 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386', > > > 'i686']. > > > Exception in thread PackageJob: 204/fuse-sshfs: > > > Traceback (most recent call last): > > > File "/usr/lib64/python2.3/threading.py", line 436, in > __bootstrap > > > self.run() > > > File "/usr/share/plague/server/PackageJob.py", line 86, in run > > > self._pkg_job.process() > > > File "/usr/share/plague/server/PackageJob.py", line 753, in > process > > > if func(): > > > File "/usr/share/plague/server/PackageJob.py", line 618, in > > > _stage_depsolve > > > if self._arch_deps_solved(arch) == False: > > > File "/usr/share/plague/server/PackageJob.py", line 562, in > > > _arch_deps_solved > > > except yum.Errors.PackageSackError, exc: > > > AttributeError: 'module' object has no attribute > 'PackageSackError' > > > > > > ====== OUR FIX ====== > > > We updated line 680 in the *die* method of the > > > */usr/share/plague/server/PackageJob.py * module. Here's the > patch: > > > > > > > > > Again, can someone please review the fix.. We just want to make > sure > > > that it won't come back to *haunt* us later on / or possibly even > be > > > *masking* another problem. Thank you. > > > > > > -Joe > > > -- > > > Fedora-buildsys-list mailing list > > > Fedora-buildsys-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > From dcbw at redhat.com Tue Oct 31 15:36:41 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 31 Oct 2006 10:36:41 -0500 Subject: plague-server issues (4.4.1) In-Reply-To: References: Message-ID: <1162309001.3155.9.camel@localhost.localdomain> On Mon, 2006-10-30 at 22:36 -0800, Evan Klitzke wrote: > Hello everyone, > > I have been trying to get plague working. I have installed the plague > programs that come with Fedora Core 6 (4.4.1). When running > plague-server, I get the following error: > > [evan at thinkpad ~]$ plague-server > Using database engine sqlite. > > Builders: > ------------------------------------------------------------------------------------------ > http://127.0.0.1:8888 i386 i486 i586 i686 athlon > noarch alive > > Traceback (most recent call last): > File "/usr/bin/plague-server", line 198, in ? > main() > File "/usr/bin/plague-server", line 152, in main > bm_server.register_instance(ui) > AttributeError: 'NoneType' object has no attribute 'register_instance' Right above that line, where you see: except socket.error, e: if e[0] == 98: # Address already in use print "Error: couldn't bind to address '%s:%s'. Is the server already running?" % (hostname, port) os._exit(1) can you insert the extra print to find out what the error is? except socket.error, e: if e[0] == 98: # Address already in use print "Error: couldn't bind to address '%s:%s'. Is the server already running?" % (hostname, port) os._exit(1) print "Other error: %s" % e Obviously there should be a catch-all there so this wouldn't happen, but I'm curious what the error is. Thanks! Dan > As a consequence, plague-client cannot connect to the server -- > connection attempts always return '(111, 'Connection refused')'. Does > anyone know if this is a known issue that has been fixed in a newer > release? Alternatively, is there a way to get lots of > debugging/logging output? I poked around the code a bit, but I'm not > really sure how I would go about debugging it. > > I have also tried the CVS snapshot, but I had problems importing the > yum logger module, presumably because this is a yum feature that isn't > in FC6. I wouldn't mind using the CVS checkout if it fixes the > aforementioned problem, but I'd rather not have to upgrade a bunch of > other programs to bleeding edge versions to get plague working. > > -- Evan Klitzke > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From dcbw at redhat.com Tue Oct 31 15:38:59 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 31 Oct 2006 10:38:59 -0500 Subject: What happened to the plague-0.5.0 push scripts -- like extras-push-new, ExtrasPushUtils.py, etc -- they're gone!!! In-Reply-To: References: Message-ID: <1162309139.3155.11.camel@localhost.localdomain> On Tue, 2006-10-31 at 10:19 -0500, Joe Todaro wrote: > > Does anyone know what happened to the following *plague-0.5.0* > programs? > > File: ExtrasMultiLib.py Status: Entry Invalid > File: ExtrasPushUtils.py Status: Entry Invalid > File: extras-push-new Status: Entry Invalid > File: extras-repobuild.py Status: Entry Invalid > File: extras-repoview.py Status: Entry Invalid > File: extras-sync Status: Entry Invalid > > ... they seem to have _disappeared_ from the extras-buildsys/utils > module in the CVS tree.. It looks like they changed somewhat, and migrated to extras-buildsys/utils/pushscript/ Dan > Joe > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From jstodaro at us.ibm.com Tue Oct 31 16:05:06 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Tue, 31 Oct 2006 11:05:06 -0500 Subject: What happened to the plague-0.5.0 push scripts -- like extras-push-new, ExtrasPushUtils.py, etc -- they're gone!!! In-Reply-To: <1162309139.3155.11.camel@localhost.localdomain> Message-ID: fedora-buildsys-list-bounces at redhat.com wrote on 10/31/2006 10:38:59 AM: > On Tue, 2006-10-31 at 10:19 -0500, Joe Todaro wrote: > > > > Does anyone know what happened to the following *plague-0.5.0* > > programs? > > > > File: ExtrasMultiLib.py Status: Entry Invalid > > File: ExtrasPushUtils.py Status: Entry Invalid > > File: extras-push-new Status: Entry Invalid > > File: extras-repobuild.py Status: Entry Invalid > > File: extras-repoview.py Status: Entry Invalid > > File: extras-sync Status: Entry Invalid > > > > ... they seem to have _disappeared_ from the extras-buildsys/utils > > module in the CVS tree.. > > It looks like they changed somewhat, and migrated to > extras-buildsys/utils/pushscript/ Thanks. Now I see it. Had to do a fresh checkout of the extras-buildsys tree to get it download. Joe > > Dan > > > Joe > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From bugs.michael at gmx.net Tue Oct 31 16:20:25 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Tue, 31 Oct 2006 17:20:25 +0100 Subject: What happened to the plague-0.5.0 push scripts -- like extras-push-new, ExtrasPushUtils.py, etc -- they're gone!!! In-Reply-To: References: Message-ID: <20061031172025.d563779c.bugs.michael@gmx.net> On Tue, 31 Oct 2006 10:19:37 -0500, Joe Todaro wrote: > Does anyone know what happened to the following *plague-0.5.0* programs? > > File: ExtrasMultiLib.py Status: Entry Invalid > File: ExtrasPushUtils.py Status: Entry Invalid > File: extras-push-new Status: Entry Invalid > File: extras-repobuild.py Status: Entry Invalid > File: extras-repoview.py Status: Entry Invalid > File: extras-sync Status: Entry Invalid > > ... they seem to have _disappeared_ from the extras-buildsys/utils module > in the CVS tree.. They are not part of plague, they are not needed by plague, but they can still be found in CVS in the "pushscript" sub-directory. [One of the primary reasons they have been moved there is the included copy of yum and the added configuration support. That makes it much easier to re-use the script for repositories other than Fedora Extras. The Config_Extras.py file becomes Config_PROJECTNAME.py (for customisation) and then either the scripts are run like "./Push.py PROJECTNAME options-here" or you create wrapper-scripts like the examples extras-push, extras-repobuild and so on, where the projectname can be filled in and activates the right Config file.] From dcbw at redhat.com Tue Oct 31 16:45:56 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 31 Oct 2006 11:45:56 -0500 Subject: PATCH: SSL.SysCallError fix for plague-0.5.0 In-Reply-To: References: Message-ID: <1162313157.3155.35.camel@localhost.localdomain> On Fri, 2006-10-27 at 00:32 -0400, Joe Todaro wrote: > > Hi, > > Has anyone ever seen this error before in their *plague-0.5.0* build > environment? It surfaced last week shortly after we started > stress-testing our buildsystem. In fact, there were three such > errors in all, which I will post separately to avoid any confusion. > This is one of three. It was triggered when we requested status > about a job we killed before it actually got handed-off to archjobs. > > ====== THE ERROR ======- > Request to enqueue 'stacker' tag 'stacker-1_3-5' for target > 'oc-rhel4-dev' (user 'jtodaro at pok.ibm.com') > 66 (stacker): Starting tag 'stacker-1_3-5' on target 'oc-rhel4-dev' > 66 (stacker): Requesting depsolve... > 66 (stacker): Starting depsolve for arches: ['i686']. > 66 (stacker): Finished depsolve (successful), requesting archjobs. > 66 (stacker/i686): https://lnxbuild1.pok.ibm.com.:8888 - UID is > 9adf56cdd15bfae2388966b08837250d3bf6772c > ---------------------------------------- > Exception happened during processing of request from ('10.63.82.73', > 49136) > Traceback (most recent call last): > File "/usr/lib64/python2.3/SocketServer.py", line 463, in > process_request_thread > self.finish_request(request, client_address) > File "/usr/lib64/python2.3/SocketServer.py", line 254, in > finish_request > self.RequestHandlerClass(request, client_address, self) > File "/usr/lib64/python2.3/SocketServer.py", line 521, in __init__ > self.handle() > File "/usr/lib64/python2.3/BaseHTTPServer.py", line 324, in handle > self.handle_one_request() > File "/usr/lib64/python2.3/BaseHTTPServer.py", line 307, in > handle_one_request > self.raw_requestline = self.rfile.readline() > File "/usr/lib64/python2.3/socket.py", line 338, in readline > data = self._sock.recv(self._rbufsize) > File "/usr/lib/python2.3/site-packages/plague/SSLConnection.py", > line 142, in recv > return con.recv(bufsize, flags) > SysCallError: (-1, 'Unexpected EOF') > ---------------------------------------- > > ====== OUR FIX ====== > We added lines 147-148 to the *recv* method of the > */usr/lib/python2.3/site-packages/plague/SSLConnection.py* module. > Here's the patch: > > > So, can someone please review the above fix.. We want to make sure it > won't come back to *bite* us later on / or possibly evn be *masking* a > larger problem. Thank you. This one makes me a bit nervous. The SSL stuff is pretty fragile, since SSL in general adds yet another protocol layer on top of everything that's subject to more handshakes and state over just TCP/IP. The traceback here shouldn't really have an effect, since it just terminates the current thread, and plague's state machine is built to be resilient to dropped and dead connection threads. I'd like to hide the traceback (or at least just print a one-line message) but that's not possible since plague code isn't anywhere in the traceback and therefore would require more subclassing. Furthermore, it technically is an error (that the other side closed the socket prematurely or something broke the connection) but one that we should ignore and retry, which plague will do. However, if this fix seems to work OK for you for a while, I'd be interested in revisiting the issue. Dan > -Joe > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From dcbw at redhat.com Tue Oct 31 16:48:26 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 31 Oct 2006 11:48:26 -0500 Subject: PATCH: job.die fix for plague-0.5.0 In-Reply-To: References: Message-ID: <1162313306.3155.37.camel@localhost.localdomain> On Fri, 2006-10-27 at 01:11 -0400, Joe Todaro wrote: > > Hi, > > Has anyone ever seen this error before in their *plague-0.5.0* build > environment? This is error two of three, which I mentioned in my > previous post. It too surfaced last week shortly after we started > stress-testing our buildsystem. There were three such errors in all, > which I've posted separately to avoid any confusion. This particular > error seemed to trigger when we attempted to kill a job we didn't know > had already failed the depsolve stage. Committed to HEAD, thanks! Dan > ====== THE ERROR ====== > 146 (cfengine): Requesting depsolve... > 146 (cfengine): Starting depsolve for arches: ['x86_64', 'i386', > 'i686']. > Cannot open/read repomd.xml file for repository: plague > failure: repodata/repomd.xml from plague: [Errno 256] No more mirrors > to try. > 146 (cfengine/x86_64): Depsolve Error: failure: repodata/repomd.xml > from plague: [Errno 256] No more mirrors to try. > 146 (cfengine): Finished depsolve (unsuccessful), trying again later. > 145 (cfengine): Job kill request from jtodaro at pok.ibm.com > 145 (cfengine): Build on target oc-rhel4-rel was killed by > jtodaro at pok.ibm.com. > Exception in thread PackageJob: 145/cfengine: > Traceback (most recent call last): > File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap > self.run() > File "/usr/share/plague/server/PackageJob.py", line 86, in run > self._pkg_job.process() > File "/usr/share/plague/server/PackageJob.py", line 745, in process > self._handle_death() > File "/usr/share/plague/server/PackageJob.py", line 725, in > _handle_death > self._kill_all_archjobs(True) > File "/usr/share/plague/server/PackageJob.py", line 737, in > _kill_all_archjobs > job.die(user_requested) > AttributeError: 'NoneType' object has no attribute 'die' > > ====== OUR FIX ====== > We added lines 710-711 to the *_kill_all_archjobs* method of the > */usr/share/plague/server/PackageJob.py * module. Here's the patch: > > > So, can someone please review the above fix.. Again, we just want to > make sure that it won't come back to *bite* us later on / or possibly > even be *masking* a larger problem. Thank you. > > -Joe > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list From jstodaro at us.ibm.com Tue Oct 31 17:21:46 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Tue, 31 Oct 2006 12:21:46 -0500 Subject: What happened to the plague-0.5.0 push scripts -- like extras-push-new, ExtrasPushUtils.py, etc -- they're gone!!! In-Reply-To: <20061031172025.d563779c.bugs.michael@gmx.net> Message-ID: fedora-buildsys-list-bounces at redhat.com wrote on 10/31/2006 11:20:25 AM: > On Tue, 31 Oct 2006 10:19:37 -0500, Joe Todaro wrote: > > > Does anyone know what happened to the following *plague-0.5.0* programs? > > > > File: ExtrasMultiLib.py Status: Entry Invalid > > File: ExtrasPushUtils.py Status: Entry Invalid > > File: extras-push-new Status: Entry Invalid > > File: extras-repobuild.py Status: Entry Invalid > > File: extras-repoview.py Status: Entry Invalid > > File: extras-sync Status: Entry Invalid > > > > ... they seem to have _disappeared_ from the extras-buildsys/utils module > > in the CVS tree.. > > They are not part of plague, they are not needed by plague, but theycan still > be found in CVS in the "pushscript" sub-directory. > > [One of the primary reasons they have been moved there is the included > copy of yum and the added configuration support. That makes it much easier > to re-use the script for repositories other than Fedora Extras. The > Config_Extras.py file becomes Config_PROJECTNAME.py (for customisation) > and then either the scripts are run like "./Push.py PROJECTNAME options-here" > or you create wrapper-scripts like the examples extras-push, > extras-repobuild and so on, where the projectname can be filled in and > activates the right Config file.] I very much appreciate the explanation. Thank You, Joe > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstodaro at us.ibm.com Tue Oct 31 17:56:07 2006 From: jstodaro at us.ibm.com (Joe Todaro) Date: Tue, 31 Oct 2006 12:56:07 -0500 Subject: PATCH: SSL.SysCallError fix for plague-0.5.0 In-Reply-To: <1162313157.3155.35.camel@localhost.localdomain> Message-ID: fedora-buildsys-list-bounces at redhat.com wrote on 10/31/2006 11:45:56 AM: > On Fri, 2006-10-27 at 00:32 -0400, Joe Todaro wrote: > > > > Hi, > > > > Has anyone ever seen this error before in their *plague-0.5.0* build > > environment? It surfaced last week shortly after we started > > stress-testing our buildsystem. In fact, there were three such > > errors in all, which I will post separately to avoid any confusion. > > This is one of three. It was triggered when we requested status > > about a job we killed before it actually got handed-off to archjobs. > > > > ====== THE ERROR ======- > > Request to enqueue 'stacker' tag 'stacker-1_3-5' for target > > 'oc-rhel4-dev' (user 'jtodaro at pok.ibm.com') > > 66 (stacker): Starting tag 'stacker-1_3-5' on target 'oc-rhel4-dev' > > 66 (stacker): Requesting depsolve... > > 66 (stacker): Starting depsolve for arches: ['i686']. > > 66 (stacker): Finished depsolve (successful), requesting archjobs. > > 66 (stacker/i686): https://lnxbuild1.pok.ibm.com.:8888 - UID is > > 9adf56cdd15bfae2388966b08837250d3bf6772c > > ---------------------------------------- > > Exception happened during processing of request from ('10.63.82.73', > > 49136) > > Traceback (most recent call last): > > File "/usr/lib64/python2.3/SocketServer.py", line 463, in > > process_request_thread > > self.finish_request(request, client_address) > > File "/usr/lib64/python2.3/SocketServer.py", line 254, in > > finish_request > > self.RequestHandlerClass(request, client_address, self) > > File "/usr/lib64/python2.3/SocketServer.py", line 521, in __init__ > > self.handle() > > File "/usr/lib64/python2.3/BaseHTTPServer.py", line 324, in handle > > self.handle_one_request() > > File "/usr/lib64/python2.3/BaseHTTPServer.py", line 307, in > > handle_one_request > > self.raw_requestline = self.rfile.readline() > > File "/usr/lib64/python2.3/socket.py", line 338, in readline > > data = self._sock.recv(self._rbufsize) > > File "/usr/lib/python2.3/site-packages/plague/SSLConnection.py", > > line 142, in recv > > return con.recv(bufsize, flags) > > SysCallError: (-1, 'Unexpected EOF') > > ---------------------------------------- > > > > ====== OUR FIX ====== > > We added lines 147-148 to the *recv* method of the > > */usr/lib/python2.3/site-packages/plague/SSLConnection.py* module. > > Here's the patch: > > > > > > So, can someone please review the above fix.. We want to make sure it > > won't come back to *bite* us later on / or possibly evn be *masking* a > > larger problem. Thank you. > > This one makes me a bit nervous. The SSL stuff is pretty fragile, since > SSL in general adds yet another protocol layer on top of everything > that's subject to more handshakes and state over just TCP/IP. > > The traceback here shouldn't really have an effect, since it just > terminates the current thread, and plague's state machine is built to be > resilient to dropped and dead connection threads. Aha - I didn't realize that. So, I will backout our patch. Thank You so much for the excellent clarification. Joe > I'd like to hide the > traceback (or at least just print a one-line message) but that's not > possible since plague code isn't anywhere in the traceback and therefore > would require more subclassing. > > Furthermore, it technically is an error (that the other side closed the > socket prematurely or something broke the connection) but one that we > should ignore and retry, which plague will do. > > However, if this fix seems to work OK for you for a while, I'd be > interested in revisiting the issue. > > Dan > > > -Joe > > -- > > Fedora-buildsys-list mailing list > > Fedora-buildsys-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list > > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcbw at redhat.com Tue Oct 31 18:00:45 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 31 Oct 2006 13:00:45 -0500 Subject: PATCH: depsolve-kill fix for plague-0.5.0 In-Reply-To: References: Message-ID: <1162317645.3155.40.camel@localhost.localdomain> On Fri, 2006-10-27 at 02:01 -0400, Joe Todaro wrote: > > Hi, > > Has anyone ever seen a yum/depsolve-related error like this before in > their *plague-0.5.0* build environment, and then tried *killing* the > job that had caused it? This was problem three of three which I had > mentioned in my previous posts. And it too had surfaced last week > while we started stress-testing our buildsystem. Actually, the error > you see below in itself was *not* the problem (we knew how to fix > that) -- rather, it was the fact that we were *unable* to kill the job > (plague-client kill 204) that was responsible for causing the error. Fix has been committed to HEAD, attaching the patch for your convenience. Thanks! Dan > ====== THE ERROR ====== > 204 (fuse-sshfs): Starting tag 'fuse-sshfs-1_6-4_ocrhel4' on target > 'oc-rhel4-pre' > 204 (fuse-sshfs): Requesting depsolve... > 204 (fuse-sshfs): Starting depsolve for arches: ['x86_64', 'i386', > 'i686']. > Exception in thread PackageJob: 204/fuse-sshfs: > Traceback (most recent call last): > File "/usr/lib64/python2.3/threading.py", line 436, in __bootstrap > self.run() > File "/usr/share/plague/server/PackageJob.py", line 86, in run > self._pkg_job.process() > File "/usr/share/plague/server/PackageJob.py", line 753, in process > if func(): > File "/usr/share/plague/server/PackageJob.py", line 618, in > _stage_depsolve > if self._arch_deps_solved(arch) == False: > File "/usr/share/plague/server/PackageJob.py", line 562, in > _arch_deps_solved > except yum.Errors.PackageSackError, exc: > AttributeError: 'module' object has no attribute 'PackageSackError' > > ====== OUR FIX ====== > We updated line 680 in the *die* method of the > */usr/share/plague/server/PackageJob.py * module. Here's the patch: > > > Again, can someone please review the fix.. We just want to make sure > that it won't come back to *haunt* us later on / or possibly even be > *masking* another problem. Thank you. > > -Joe > -- > Fedora-buildsys-list mailing list > Fedora-buildsys-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-buildsys-list -------------- next part -------------- A non-text attachment was scrubbed... Name: old-yum-fixes.patch Type: text/x-patch Size: 3410 bytes Desc: not available URL: