[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, 3 months
How do I remove a package from koji?
by steve.webb＠beatport.com
How do I remove or clean out a build repo/tag from koji to start over with
a new build tag?
- Steve
--
Steve Webb | System Administrator
Beatport | Play With Music
------------------------------------------
2399 Blake Street, Suite 170
Denver, Colorado USA 80205
tel: +1.720.932.9103
fax: +1.720.932.9104
noc: +1.303.565.2710
mobile: +1.303.564.4269
12 years, 10 months
I've got admin privs, but I can't remove packages through the web interface
by steve.webb＠beatport.com
I've got admin privs, but I don't seem to be able to remove packages or
builds through the web interface. Is the web interface missing something?
[swebb@bpbuild001 ~]$ koji grant-permission admin swebb
GenericError: user swebb already has permission: admin
- Steve
--
Steve Webb | System Administrator
Beatport | Play With Music
------------------------------------------
2399 Blake Street, Suite 170
Denver, Colorado USA 80205
tel: +1.720.932.9103
fax: +1.720.932.9104
noc: +1.303.565.2710
mobile: +1.303.564.4269
12 years, 10 months
pungi vs anaconda buildinstall: TMPDIR works, local cache ignored...
by Martin Langhoff
Working with Pungi 2.1.4 to build the School Server OLPC spin (which
fir test purposes is being done on F14, though that's not the final
target).
- Seems like Pungi has for a long time avoided setting a smart TMPDIR
when calling anaconda's buildinstall. This uses a sizable chunk of
/tmp . I've pached pypungi/__init__.py to set it, and it works fairly
well (for me at least). Was going to post a patch but v2.5.0 has been
completely reworked.
- The buildinstall process is dog slow for me -- because buildinstall
is ignoring the pungi cache and grabbing it all itself, again. Is this
expected? Should pungi add a "repo" of it's own local cache?
Looking at pungi's git repo, I ended up looking at Lorax code -- so I
gather patches to scratch my own itch won't be merged.
Keen on hearing when new pungi plus new lorax can build a F14 image.
cheers,
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
12 years, 10 months
GenericError: Unable to complete build: release mismatch (build: 4.P1.el5_4.2, rpm: 4.P1.el5.2)
by steve.webb＠beatport.com
What does koji mean when I get this error?
GenericError: Unable to complete build: release mismatch (build:
4.P1.el5_4.2, rpm: 4.P1.el5.2)
The individual builds completed successfully, but the "Result" of the
build ended up with that error.
- Steve
--
Steve Webb | System Administrator
Beatport | Play With Music
------------------------------------------
2399 Blake Street, Suite 170
Denver, Colorado USA 80205
tel: +1.720.932.9103
fax: +1.720.932.9104
noc: +1.303.565.2710
mobile: +1.303.564.4269
12 years, 10 months
[PATCH] fedpkg: call sources before running mockbuild
by Josh Boyer
Currently a 'fedpkg mockbuild' in a fresh clone of a package will
result in something like:
[jwboyer@r2d2 kernel]$ fedpkg mockbuild
error: File /home/jwboyer/src/fedora/kernel/linux-2.6.34.tar.bz2: No
such file or directory
Could not run mockbuild: Command 'rpmbuild --define '_sourcedir
/home/jwboyer/src/fedora/kernel' --define '_specdir
/home/jwboyer/src/fedora/kernel' --define '_builddir
/home/jwboyer/src/fedora/kernel' --define '_srcrpmdir
/home/jwboyer/src/fedora/kernel' --define '_rpmdir
/home/jwboyer/src/fedora/kernel' --define 'dist .fc13' --define
'fedora 13' --define 'fc13 1' --nodeps -bs
/home/jwboyer/src/fedora/kernel/kernel.spec' returned non-zero exit
status 1
[jwboyer@r2d2 kernel]$
because the sources have not been downloaded yet. Under the old
dist-cvs system, a mockbuild had a dependency on srpm, which had a
dependency on sources.
The following patch accomplishes the a similar dependency in fedpkg by
making it fetch the sources prior to doing the mock setup. Tested
locally on F14.
josh
---
diff --git a/src/fedpkg.py b/src/fedpkg.py
index dbae1a8..31c18dd 100755
--- a/src/fedpkg.py
+++ b/src/fedpkg.py
@@ -576,6 +576,12 @@ def local(args):
sys.exit(1)
def mockbuild(args):
+ try:
+ pyfedpkg.sources(args.path)
+ except pyfedpkg.FedpkgError, e:
+ log.error('Could not download sources: %s' % e)
+ sys.exit(1)
+
# Pick up any mockargs from the env
mockargs = []
try:
12 years, 10 months
Strange mock build failure due to typo
by Paul Howarth
Hi,
today I have been preparing an update to perl-Math-Pari and came across
a very strange build failure whilst doing a local mock build on a Fedora
13 x86_64 host. My package built successfully on x86_64 but when I tried
to build for i386, the build failed during %setup but without any
diagnostics. The SRPM was installed but no attempt to install its build
requirements was made. The root.log showed an exit status of 0 for all
commands that had been run.
After much experimentation bisecting the changes I had made, I
discovered that a typo in the changelog entry was the culprit: I had set
the year to 2100 instead of 2010. So it would appear that somewhere in
the mock/yum/rpm stack there may be a year 2038 problem waiting to bite
us (though I suspect there may not be too many 32-bit builds happening
by then).
Seriously though, it would be nice to have better diagnostics for this
and perhaps an rpmlint check for changelog entries in the future?
Paul.
12 years, 10 months
koji mock build trying to use package from another build
by steve.webb＠beatport.com
Hey there.
Another issue (I'm getting close to getting everything working, I swear!)
I've done several good builds of packages and I switched around some
external repos to use local repos instead. Not sure if that's related,
but I thought that I'd throw that in there in case it's a variable.
When doing the mock part of the buildroot, I'm getting:
[snip]
termcap noarch 1:5.5-1.20060701.1 build 265 k
tzdata x86_64 2010l-1.el5 build 796 k
udev x86_64 095-14.21.el5_5.1 build 2.4 M
util-linux x86_64 2.13-0.52.el5_4.1 build 1.8 M
zlib x86_64 1.2.3-3 build 51 k
Transaction Summary
================================================================================
Install 106 Package(s)
Total download size: 109 M
Installed size: 109 M
http://bpbuild001.co0.nar.beatportcorp.net/packages/less/436/2.el5/x86_64...: [Errno 14] HTTP Error 404 : http://bpbuild001.co0.nar.beatportcorp.net/packages/less/436/2.el5/x86_64...
Trying other mirror.
Error Downloading Packages:
less-436-2.el5.x86_64: failed to retrieve less-436-2.el5.x86_64.rpm from build
error was [Errno 14] HTTP Error 404 : http://bpbuild001.co0.nar.beatportcorp.net/packages/less/436/2.el5/x86_64...
[/snip]
The bpbuild001.co0.nar.beatportcorp.net machine is my build server, so I'm
guessing that the new package is expecting to find the rpm for 'less' on
my build server instead of on the repo, right? I'm expecting that I just
need to configure the .../packages/ URL to hit the right packages
directory on my server. I changed the kojidir from /mnt/koji to
/data/koji (a larger disk). Which config file do I need to change to get
.../packages/ to point to the /data/koji/... ?? I checked the dir, and
the files are in there, so I just need to change that config var
somewhere.
Thanks in advance.
- Steve
--
Steve Webb | System Administrator
Beatport | Play With Music
------------------------------------------
2399 Blake Street, Suite 170
Denver, Colorado USA 80205
tel: +1.720.932.9103
fax: +1.720.932.9104
noc: +1.303.565.2710
mobile: +1.303.564.4269
12 years, 10 months
