buildsys August 2011

buildsys@lists.fedoraproject.org

13 participants
12 discussions

[BUG] Koji and Lustre
by Thomas Guthmann 09 Sep '11

09 Sep '11

Hey guys, We found a bug(?) in listTaskOutput (/usr/share/koji-hub/kojihub.py) when used with a Lustre filesystem. This function parses all attributes of every file of a build and is used when you want to display build.log/root.log through the web interface. Everything returned by listTaskOutput is returned through XML-RPC and as a result we had this : An error has occurred while processing your request. Fault: <Fault 1: 'exceptions.OverflowError: long int exceeds XML-RPC limits'> Traceback (most recent call last): File "/usr/share/koji-web/lib/kojiweb/publisher.py", line 16, in publish_object return old_publish_object(req, object) File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py", line 412, in publish_object return publish_object(req,util.apply_fs_data(object, req.form, req=req)) File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line 439, in apply_fs_data return object(**args) File "/usr/share/koji-web/scripts/index.py", line 649, in getfile output = server.listTaskOutput(taskID, stat=True) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1468, in __call__ return self.__func(self.__name,args,opts) File "/usr/lib/python2.4/site-packages/koji/__init__.py", line 1718, in _callMethod raise err Fault: <Fault 1: 'exceptions.OverflowError: long int exceeds XML-RPC limits'> The issue comes from the st_dev value gathered by getStat (stat). In Lustre this value can be very high and that's why it complains. To fix that, we used the same condition than st_size, we cast the value as a string. See attached patch. Example (see 'Device:' the value after the '/'): # stat build.log File: `build.log' Size: 106021 Blocks: 208 IO Block: 2097152 regular file Device: e04ae70eh/3763005198d Inode: 721664 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 48/ apache) Gid: ( 48/ apache) Access: 2010-07-13 10:44:40.000000000 +1000 Modify: 2010-07-12 12:54:15.000000000 +1000 Change: 2010-07-12 12:54:52.000000000 +1000 # That's what is read by listTaskOutput relfilename=build.log ATTR=st_atime GETATTR=1278981616 relfilename=build.log ATTR=st_blksize GETATTR=2097152 relfilename=build.log ATTR=st_blocks GETATTR=208 relfilename=build.log ATTR=st_ctime GETATTR=1278903292 relfilename=build.log ATTR=st_dev GETATTR=3763005198 <----- /!\ relfilename=build.log ATTR=st_gid GETATTR=48 relfilename=build.log ATTR=st_ino GETATTR=721664 relfilename=build.log ATTR=st_mode GETATTR=33188 relfilename=build.log ATTR=st_mtime GETATTR=1278903255 relfilename=build.log ATTR=st_nlink GETATTR=1 relfilename=build.log ATTR=st_rdev GETATTR=0 relfilename=build.log ATTR=st_size GETATTR=106021 relfilename=build.log ATTR=st_uid GETATTR=48 Hope it helps, lost a good amount of time on that one :) Cheers, Thomas

2 3

How can I add another arch when project is going
by Yanchuan Nian 09 Sep '11

09 Sep '11

Hi there, There are one or more arches in each build tag.These arches are decided before a project opening.I what to know how to add another arch when the project is going.for instance,tag1 contains two arches(i386 and x86_64) at the beginning, and dist-tag1 is a target using tag1 as its build tag.I can build zlib successfully with this command koji build dist-tag1 /path/to/zlib-1.2.3-4.src.rpm Then I add mips as the third arch of tag1, and rebuild zlib koji build dist-tag1 /path/to/zlib-1.2.3-4.src.rpm A error occurs "Build already exists". zlib-1.2.3-4.mips.rpm can not generate for the information of zlib-1.2.3-4 has been stored in the database.Is there a solution for this problem?If I have to modify the source code of koji, how? Thanks in advance. Yanchuan Nian -- buildsys mailing list buildsys(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys

2 1

about sparc koji
by Jinze Xue 30 Aug '11

30 Aug '11

hello, We find the sparc koji web can't open in these days, what's happened? the pages provide us many useful infomations about packages and build logs, when will it work normally? expecting thanks very much!! sparcers -_- 2011-08-30 xuejinze

2 1

[PATCH] pungi: Add support for generating EFI-bootable USB images
by Matthew Garrett 25 Aug '11

25 Aug '11

Right now our hybrid images aren't bootable via EFI when written directly to a USB stick. This patch adds the necessary argument to the isohybrid call, and in addition will perform appropriate setup to make the image bootable on older EFI Macs if the tree has a macboot image. This requires syslinux 4.02-5 or later. diff --git a/src/pypungi/__init__.py b/src/pypungi/__init__.py index e183b9c..ac2f7f0 100644 --- a/src/pypungi/__init__.py +++ b/src/pypungi/__init__.py @@ -1002,6 +1002,9 @@ class Pungi(pypungi.PungiBase): efibootargs = ['-eltorito-alt-boot', '-e', 'images/efiboot.img', '-no-emul-boot'] + macbootargs = ['-eltorito-alt-boot', '-e', 'images/macboot.img', + '-no-emul-boot'] + ia64bootargs = ['-b', 'images/boot.img', '-no-emul-boot'] ppcbootargs = ['-part', '-hfs', '-r', '-l', '-sysid', 'PPC', '-no-desktop', '-allow-multidot', '-chrp-boot'] @@ -1016,6 +1019,8 @@ class Pungi(pypungi.PungiBase): sparcbootargs = ['-G', '/boot/isofs.b', '-B', '...', '-s', '/boot/silo.conf', '-sparc-label', '"sparc"'] + isohybrid = ['/usr/bin/isohybrid'] + # Check the size of the tree # This size checking method may be bunk, accepting patches... if not self.config.get('pungi', 'arch') == 'source': @@ -1044,6 +1049,10 @@ class Pungi(pypungi.PungiBase): extraargs.extend(x86bootargs) if self.config.get('pungi', 'arch') == 'x86_64': extraargs.extend(efibootargs) + isohybrid.append('-u') + if os.path.exists(os.path.join(self.topdir, 'images', 'macboot.img')): + extraargs.extend(macbootargs) + isohybrid.append('-m') elif self.config.get('pungi', 'arch') == 'ia64': extraargs.extend(ia64bootargs) elif self.config.get('pungi', 'arch') == 'ppc': @@ -1061,7 +1070,9 @@ class Pungi(pypungi.PungiBase): self.config.get('pungi', 'version'), self.config.get('pungi', 'arch'))) extraargs.extend(['-o', isofile]) - + + isohybrid.append(isofile) + if not self.config.get('pungi', 'arch') == 'source': extraargs.append(self.topdir) else: @@ -1072,7 +1083,7 @@ class Pungi(pypungi.PungiBase): # Run isohybrid on the iso if os.path.exists("/usr/bin/isohybrid"): - subprocess.call(["/usr/bin/isohybrid", isofile]) + pypungi.util._doRunCommand(isohybrid, self.logger) # implant md5 for mediacheck on all but source arches if not self.config.get('pungi', 'arch') == 'source': -- Matthew Garrett | mjg59(a)srcf.ucam.org

2 1

Question about koji packages
by Kiu Leung 22 Aug '11

22 Aug '11

Hi all, My name is Ken Leung and I am a Red Hat's summer internship student working at Red Hat's Toronto office. I have a question about koji packages shown on the koji web interface: There is an instance of koji running at Red Hat's Toronto office for testing purposes. From the koji web interface of that instance, I noticed that there are a total of 2620 packages. However, when I look at it's list of user (10 users), there is only one user who owns packages and he has only 638 packages. So does it mean the the other packages are all imported from some other database or they just simply do no have an owner? I should be grateful for your kind advice and thank you very much in advance! Have a great weekend! Best wishes, Ken Leung

3 4

Question about scratch builds.
by Kiu Leung 22 Aug '11

22 Aug '11

Hi all, I have a question about koji scratch builds. I noticed that in the database, a scratch build is no associated with a task. So what is being returned when a scratch build is pushed to koji? Your kind advice is appreciated, thank you very much! Ken Leung

3 3

Question about listBuilds with multiple task IDs
by Kiu Leung 09 Aug '11

09 Aug '11

Hi all, I have a question about how to form the parameter list of a listBuilds web method call with multiple task ID. According to the definition of a hash table/dictionary, keys are unique, so I cannot put more than 1 entry in the table with the same key "taskID". I tried to set the value of the "taskID" entry as a list of integers (in Java, as shown below) but koji hub will not accept it, so I should be grateful for your advice about how should I form the parameter list, thank you very much in advance! Best regards, Ken Leung The code: HashMap<String, Object> params = new HashMap<String, Object>(); ArrayList<Integer> taskIDParamList = new ArrayList<Integer>(); params.put("__starstar", new Boolean(true)); taskIDParamList.add(new Integer(3)); taskIDParamList.add(new Integer(5343)); params.put("taskID", taskIDParamList); //web method call with params as the parameter.

1 0

Problem solved : Question about koji hub opts and Java
by Kiu Leung 08 Aug '11

08 Aug '11

Hi all, This is Ken Leung again. I just want to say that I finally got that problem solved, thank you very much! Ken Leung

1 0

Question about koji hub opts and Java
by Kiu Leung 08 Aug '11

08 Aug '11

Hi all, This is Ken Leung, the Red Hat intern student has been trying to create a java client for koji hub. I ran a few koji debugs with koji web and my java client and noticed that koji web has been generating web method calls with opts instead of parms for a listBuild by task ID, as shown below: 2011-08-08 14:41:48,533 [DEBUG] m=listBuilds u=None koji.xmlrpc: Handling method listBuilds for session None (#None) 2011-08-08 14:41:48,533 [DEBUG] m=listBuilds u=None koji.xmlrpc: Params: () 2011-08-08 14:41:48,533 [DEBUG] m=listBuilds u=None koji.xmlrpc: Opts: {'taskID': 4623} If I use the apache xmlrpc library, I can only generate a call with the following: 2011-08-08 14:55:01,171 [DEBUG] m=getBuild u=testuser koji.xmlrpc: Handling method getBuild for session 14571 (#None) 2011-08-08 14:55:01,172 [DEBUG] m=getBuild u=testuser koji.xmlrpc: Params: ({'taskID': 4623},) 2011-08-08 14:55:01,173 [DEBUG] m=getBuild u=testuser koji.xmlrpc: Opts: {} So I wonder if anybody knows how to generate the koji hub desired Opts with apache xmlrpc library? Or is Opts a python specific feature which is not reproducable with Java and apache xmlrpc? You kind advice is appreciated and thanks in advance! Best regards, Ken Leung

1 0

Kojid unable to regen-repo in Fedora 15
by Anthony Joseph Messina 05 Aug '11

05 Aug '11

I'm running a Kojid instance, freshly upgraded from Fedora 14 -> 15. My koji hub is still running Fedora 14. When running a regen-repo, I now get this error: 2011-05-25 20:20:41,405 [WARNING] koji.TaskManager: TRACEBACK: Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1114, in runTask response = (handler.run(),) File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 146, in run return self.handler(*self.params,**self.opts) File "/usr/sbin/kojid", line 2552, in handler self.create_local_repo(rinfo, arch, pkglist, groupdata, oldrepo) File "/usr/sbin/kojid", line 2606, in create_local_repo % parseStatus(status, ' '.join(cmd)) GenericError: failed to create repo: /usr/bin/createrepo -vd -o /tmp/koji/tasks/1796/1796/repo -u http://messinet.com/koji-mnt/packages -i /mnt/koji/repos/dist-f14-build/221/x86_64/pkglist -g /mnt/koji/repos/dist-f14-build/221/groups/comps.xml --update --skip-stat /mnt/koji/packages/ exited with status 1 Any ideas on where I should go? Thanks in advance. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

4 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys August 2011