buildsys October 2006

buildsys@lists.fedoraproject.org

13 participants
12 discussions

Using mock with SuSE Linux Enterprise Desktop?
by John Villalovos 06 Dec '06

06 Dec '06

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

4 5

PATCH: depsolve-kill fix for plague-0.5.0
by Joe Todaro 01 Nov '06

01 Nov '06

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

2 6

plague-server issues (4.4.1)
by Evan Klitzke 01 Nov '06

01 Nov '06

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@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

2 2

PATCH: SSL.SysCallError fix for plague-0.5.0
by Joe Todaro 31 Oct '06

31 Oct '06

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(a)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

2 2

What happened to the plague-0.5.0 push scripts -- like extras-push-new, ExtrasPushUtils.py, etc -- they're gone!!!
by Joe Todaro 31 Oct '06

31 Oct '06

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

3 4

PATCH: job.die fix for plague-0.5.0
by Joe Todaro 31 Oct '06

31 Oct '06

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(a)pok.ibm.com 145 (cfengine): Build on target oc-rhel4-rel was killed by jtodaro(a)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

2 1

Extras build system back up
by Dan Williams 26 Oct '06

26 Oct '06

Hi, We're back up and using the latest plague code. yum update your plague-client and you should be good to go. Dan

3 7

Mock hangs - why?
by Al Pacifico 25 Oct '06

25 Oct '06

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 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

New Project: pungi - A Fedora release composing tool
by Jesse Keating 25 Oct '06

25 Oct '06

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(a)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

3 4

pungi (options error messages fix)
by Jarosław Górny 25 Oct '06

25 Oct '06

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

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys October 2006