[BUG] Koji and Lustre
by Thomas Guthmann
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
12 years
Kojid unable to regen-repo in Fedora 15
by Anthony Joseph Messina
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
12 years, 1 month
rpm build error with 6.1
by Farkas Levente
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!"
12 years, 4 months
installing koji on F15.
by Bryce
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?
12 years, 4 months
initrd or initramfs ... etc.
by r_burton
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
12 years, 4 months
pungi - x86_64 wine issue
by Phillip T. George
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
12 years, 4 months
[PATCH] Configuration for source-fetching command needs documentation
by Garrett Holmstrom
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
12 years, 4 months
