buildsys May 2011

buildsys@lists.fedoraproject.org

10 participants
7 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

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

rpm build error with 6.1
by Farkas Levente 26 May '11

26 May '11

hi, it seems most of the rpm in 6.1 have the same problems as described in: http://www.mail-archive.com/buildsys@lists.fedoraproject.org/msg00741.html many src.rpm (i mean many hundreds of packages) in rhel-6.1 when try to rebuild in mock gives such an error: ------------------------------------------------ Executing command: ['bash', '--login', '-c', 'rpmbuild -bs --target i686 --nodeps builddir/build/SPECS/OpenEXR.spec'] error: Macro % has illegal name (%define) error: Macro % has illegal name (%define) error: parse error in expression error: /builddir/build/SPECS/OpenEXR.spec:2: parseExpressionBoolean returns -1 error: Macro % has illegal name (%define) Building target platforms: i686 Building for target i686 Child returncode was: 1 ------------------------------------------------ where the spec contains this line: %if 0%{?fedora} > 7 || 0%{?rhel} >= 6 which seems to good to me. and such problems don't happened with 6.0. does anybody know the reason for this and even better the solution to build these packages? thanks in advance. regards. -- Levente "Si vis pacem para bellum!"

2 5

installing koji on F15.
by Bryce 25 May '11

25 May '11

I'd a quick go at installing koji on an F15 box this afternoon but hit the following. [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] mod_python (pid=18341, interpreter='build1', phase='PythonHandler', handler='kojixmlrpc'): Application error [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] ServerName: 'build1' [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] DocumentRoot: '/var/www/html' [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] URI: '/kojihub/ssllogin' [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] Location: None [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] Directory: '/usr/share/koji-hub/' [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] Filename: '/usr/share/koji-hub/XMLRPC' [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] PathInfo: '/ssllogin' [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] Traceback (most recent call last): [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] File "/usr/lib64/python2.7/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch\n default=default_handler, arg=req, silent=hlist.silent) [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] File "/usr/lib64/python2.7/site-packages/mod_python/importer.py", line 1202, in _process_target\n module = import_module(module_name, path=path) [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] File "/usr/lib64/python2.7/site-packages/mod_python/importer.py", line 296, in import_module\n log, import_path) [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] File "/usr/lib64/python2.7/site-packages/mod_python/importer.py", line 680, in import_module\n execfile(file, module.__dict__) [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] File "/usr/share/koji-hub/kojixmlrpc.py", line 35, in <module>\n import koji.db [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] File "/usr/lib/python2.7/site-packages/koji/db.py", line 29, in <module>\n from pgdb import _quoteparams [Wed May 25 16:53:00 2011] [error] [client 192.168.122.112] ImportError: cannot import name _quoteparams /usr/lib64/python2.7/site-packages/pgdb.py: def _quoteparams(self, string, params): """Quote parameters. This function works for both mappings and sequences. """ if isinstance(params, dict): params = _quotedict(params) params.quote = self._quote else: params = tuple(map(self._quote, params)) return string % params /usr/lib/python2.7/site-packages/koji/db.py: import pgdb ... from pgdb import _quoteparams ... if debug: self.logger.debug(_quoteparams(operation,parameters)) I got around this by removing the "from pgdb import _quoteparams" line since the whole module is already imported. Would that be a correct action or is there some nuance that I'm overlooking that will bite me later?

2 1

initrd or initramfs ... etc.
by r_burton 18 May '11

18 May '11

I am running Fedora-14-x86_64 I have imported, and built kernel source: linux-2.6.38.6 My problem: How do I build a new 'initrd'? I have examined the file /boot/initramfs-2.6.35.6-45.fc14.x86_64.img Which comes with the Fedora-14 distribution. How do I build a new one? On other distributions which I am familiar (e.g. Suse) there is a script, 'mkinitrd'. Is there such a script for Fedora? Is there a definitive "Guide to the Fedora Kernel Build Procedure"? Thanks Bob

2 1

pungi - x86_64 wine issue
by Phillip T. George 13 May '11

13 May '11

I seem to be having an issue with wine. Well, it likely is not only specific to wine, but has to do with the configuration I have set up, which includes wine. I am building on x86_64 ... and wine has dependencies that are x86-32. Those dependencies are not getting included, so whenever the install is being ran, it complains about those missing dependencies. FYI, I'm doing this on Fedora 14. The missing RPMs are: wine-capi-1.3.18-1.fc14.i686.rpm wine-cms-1.3.18-1.fc14.i686.rpm wine-core-1.3.18-1.fc14.i686.rpm wine-ldap-1.3.18-1.fc14.i686.rpm wine-openal-1.3.18-1.fc14.i686.rpm wine-pulseaudio-1.3.18-1.fc14.i686.rpm wine-twain-1.3.18-1.fc14.i686.rpm Understand part of the goal is to slipstream updates as well as other custom RPMs into the install process. It appears that pungi is purposely ignoring these packages due to them not being the main architecture. What would be the method in telling pungi that including i686 packages is ok, as long as its a requirement of another package? Or is this just a bug? Thanks, Phillip

2 4

[PATCH] Configuration for source-fetching command needs documentation
by Garrett Holmstrom 03 May '11

03 May '11

The fourth part of allowed_scm tuples in kojid.conf that specifies what command to run in lieu of ``make sources'' isn't documented. Attached is a patch that describes it in kojid.conf's commentary alongside the rest of allowed_scm's documentation. The patch is copypasted from bug 679897, which is a few months old now, so I apologize if it no longer applies perfectly cleanly. -- Garrett Holmstrom

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys May 2011