buildsys February 2008

buildsys@lists.fedoraproject.org

18 participants
12 discussions

Koji server installation
by Degremont, Guillaume 28 May '08

28 May '08

Hello, I am currently working on deploying a small build system based on mock/koji The system is very simple, just one server hosting the builds and koji (another buidl system may be added later, but that is not the issue at thje present time). I am having some troubles deploying koji. The only document I have found is the ServerHowTo (http://fedoraproject.org/wiki/Koji/ServerHowTo) I retrieved the koji, koji-hub, koji-web and koji-utils packages and installd them successfully on my server. I configured koji to use SSL following the guidelines. Not being a SSL expert, I think I did not do any error, but it was tricky since filenames change between the certificate creation section and the kojihub/kojweb/kojid configuration sections. and I configured all 4 servers (kojihub, kojiweb, kojira, kojid) to be hosted on the same server, named murray. However, when I try to use koji, I get the following error: [koji@murray ~]$ koji add-user userTest Kerberos authentication failed: 'No credentials cache found' (-1765328189) [koji@murray ~]$ I have modified the /etc/koji.conf (though it is not mentioned in the How To) as follows, to ensure it will use SSL: [root@murray ~]# more /etc/koji.conf [koji] ;configuration for koji cli tool ;url of XMLRPC server server = http://murray.mysite.hp.com/kojihub ;url of web interface weburl = http://murray.mysite.hp.com/koji ;url of package download site pkgurl = http://murray.mysite.hp.com/packages ;path to the koji top directory topdir = /mnt/koji ;configuration for SSL athentication ;client certificate cert = /etc/kojiweb/clients/certs/koji.cert ;certificate of the CA that issued the client certificate ca = /etc/kojiweb/clients/koji_ca_cert.crt ;certificate of the CA that issued the HTTP server certificate serverca = /etc/kojiweb/clients/koji_ca_cert.crt koji_ca_cert.crt being the ca certificate I generated and koji.cert a certificate I generated for the koji user. This is my first problem. Can anyone help me on this ? My other problem is with the servers. I configured my apache and started it to have the kojihub and kojiweb started. I then want to perform some add--user, add-host commands. But I get the message "unable to connect to server". [root@murray ~]# koji --noauth add-host murray.mysite.hp.com i386 x86_64 Error: Unable to connect to server With the following logs from httpd: [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: Traceback (most recent call last): [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in HandlerDispatch\n result = object(req) [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/share/koji-hub/kojixmlrpc.py", line 278, in handler\n context.cnx = koji.db.connect(opts.get("KojiDebug",False)) [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/lib/python2.4/site-packages/koji/db.py", line 128, in connect\n conn = pgdb.connect(**opts) [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: File "/usr/lib/python2.4/site-packages/pgdb.py", line 383, in connect\n dbtty, dbuser, dbpasswd) [Thu Nov 15 10:28:51 2007] [error] [client X.X.X.X] PythonHandler kojixmlrpc: InternalError: could not connect to server: Connection refused\n\tIs the server running on host "murray.mysite.hp.com" and accepting\n\tTCP/IP connections on port 5432?\n Do you know what it comes from ? I can supply my other conf files, if needed. But I strictly followed the Howto nstructions for the configuration files. Reagrds, Guillaume Degremont PS: for security related reasons, I replaced the ipaddress with X.X.X.X and changed the hostname and fully qualified domain name with dummy ones ^^

2 1

mock 0.9 backport to F7/F8 -- Feb 1
by Michael E Brown 13 Mar '08

13 Mar '08

All mock users, The mock maintainers (Clark, Jesse, me) will upgrade mock in F7/F8 to current 0.9 on/around Feb 1. The mock 0.9 branch has brewed in rawhide since early Dec, and so far it looks good. The 0.9 branch is now being used on the official build systems, so if there were any major problems, we would expect to have hit them by now. The *only* difference between 0.8.<latest> and 0.9.<latest> at this point is that we have dropped the old mock setuid wrapper and now use the consolehelper subsystem. For this, you will notice new /etc/pam.d/mock, /etc/consolehelper/mock files which configure mock. The default config is set up to operate exactly the same as the old 0.8 branch: ie. you must be a member of the 'mock' group to run mock. Additionally, with consolehelper comes one new feature: if you are not in the 'mock' group, you will be prompted to enter the root password and it will run. This means you can run mock without worrying about any pre-setup. -- Michael

5 6

cache plugin behavior?
by Clark Williams 29 Feb '08

29 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael, I was looking at BZ 233529 on mock and was wondering if the requested behavior seems valid (it does to me, just wanted a sanity check). As far as I can tell, the only time the root cache is invalidated is when it ages out (was looking at the plugin). Does it make sense to also invalidate the cache when the .cfg that defines it has a newer modification time? Clark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkfIK6sACgkQHyuj/+TTEp1sxACg4cOB0uX5lsBSwprCenpVIVCS FnMAniBN93OFe9gf6znQreK26yzcB0b9 =Peks -----END PGP SIGNATURE-----

2 4

rebuilding from old cvs tags
by Mike McLean 29 Feb '08

29 Feb '08

I ran into an interesting problem while replicating some older Fedora builds in a test environment. Consider this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=6144 It was built by task 1648 using this cvs url: cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/sparse/devel#sparse-0_3-1_fc7 The problem is that if you rebuild this now, you get DIST=fc9, because devel has moved on. In my case, I am replicating the buildroot, which includes the package that provides the original DIST=fc7. This leads to a mismatch. Koji thinks it is building sparse-0.3-1.fc9, but the actual result is sparse-0.3-1.fc7. The build completes but import fails. I'm trying to reproduce the build as closely as possible, so I want .fc7, not .fc9. It occurred to me that Makefile.common could be smarter about this. When you checkout a specific revision with cvs, that revision is noted in CVS/Tag. It would be possible (though perhaps messy) for Makefile.common to note this and behave a little differently. Why? Better repeatability. If you checkout a specific revision from a time when dist has a different value, you probably ought to be using that dist and not the current one. I suppose the real problem is that although we're building from a specific revision of the main checkout, we're always using the HEAD of common. Solving that even more of a mess though (and even if we do, we still have a whole bunch of builds from unrecorded revisions of common in the system). So what do folks think? Am I crazy? Would a Makefile.common patch for this be welcome?

9 16

odd build failures under koji/mock
by Doug Chapman 23 Feb '08

23 Feb '08

We have a koji server set up for ia64 where I have been running rawhide builds through. I am seeing something that I imagine is a regression in rpmbuild???? that is likely to be seen on the main koji server as well. Take for example this failed build of openser-1.3.0-8.fc9.src.rpm: On our ia64 koji server it failed with: + mv '/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*' /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ mv: cannot stat `/var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/openser/perl/*': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.7626 (%install) The line in the specfile that triggered this is: mv $RPM_BUILD_ROOT/%{_libdir}/openser/perl/* somehow it appears it took the * path as literal. Looking at the main koji server at a build of the same package it expanded the * properly: + mv /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib64/openser/perl/OpenSER.pm /var/tmp/openser-1.3.0-8.fc9-root-mockbuild//usr/lib/perl5/vendor_perl/5.8.8/ My only guess is this is a bug in rpmbuild which was introduced after openser was built on the main koji server (Feb 9th). I have several other packages failing in a similar manner, all fail to expand * properly. any ideas? The full build log of the failure can be seen at: http://ia64.koji.fedoraproject.org/koji/getfile?taskID=14457&name=build.log - Doug

4 13

no kernel in pungi image
by Gary Thomas 20 Feb '08

20 Feb '08

Note: I'm not sure which list this belongs on - maybe anaconda-devel? I'm using pungi to build a distribution. If I build using anaconda-11.4.0.28, I get a good working build. If I use anaconda-11.4.0.36+ (from git 2008-02-19, just after 11.4.0.36), the result has no kernel package :-( I can see that it got scanned, but for some reason wasn't in the list of packages that yum installed. Can anyone give me a clue as to why? The logs from these builds, as well as the kickstart file, are at available from my website (too big for this list) http://www.mlbassoc.com/pungi-failures/AM_Fedora-min.ks http://www.mlbassoc.com/pungi-failures/ppc-anaconda-11.4.0.28.log http://www.mlbassoc.com/pungi-failures/ppc-anaconda-11.4.0.36.log Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------

1 0

[OT?] removing plague jobs...
by Fernando Lopez-Lezcano 11 Feb '08

11 Feb '08

Would this be the right list for this question? I have a mock/plague build system I'm just configuring and I wonder how can I get rid of old builds? (ie: erase all related files and clean up the database). Should be simple[*], I must be missing something obvious... Thanks for any help... -- Fernando [*] something like "plague-remove <jobid>"

2 2

scanning logical volumes from initrd nash script
by Fabio 08 Feb '08

08 Feb '08

Hi... The initrd nash script 'init' actually scans for logical volumes as follows: ..... code snippet from 'init' script ............ echo Scanning logical volumes lvm vgscan --ignorelockingfailure echo Activating logical volumes lvm vgchange -ay --ignorelockingfailure *<fixed volgroup name>* ....... end of code snippet ..... The volgroup name is fixed, it is written in the script itself. How to change this script in order to activate the logical volume name output of the 'vgscan' command? Nash is not the same as bash and I don't know how to do something like this: ------------------------------------------------------------------------ volgroup_name=`lvm vgscan --ignorelockingfailure` lvm vgchange -ay --ignorelockingfailure $volgroup_name ------------------------------------------------------------------------ Have you some suggestion ? .... Thank you

1 0

Local packages
by Gary Thomas 07 Feb '08

07 Feb '08

I'm trying to build a localized repository: Fedora + Updates + Local Packages Some of the local packages are derived from the mainline. I make some [minor] changes to match my hardware (sadly, my mods aren't suitable for pushing upstream). I want to keep the version+revision pretty much intact so I know where the package came from, etc. For example, I need to have a slightly modified X server (uncommon hardware, yeah!). So, I started with the package: xorg-x11-server-1.3.0.0-40.fc8.src.rpm I make my little change and rebuild, creating: xorg-x11-server-1.3.0.0-40_AM.fc8.src.rpm along with the desired binary packages. I'm trying to run pungi to create a munged/tailored repository, using the official versions of Fedora & Updates. Sadly, it seems that the original package always seems to override the one with my modifications, e.g. xorg-x11-server-1.3.0.0-40.fc8.src.rpm is chosen, even when both it and xorg-x11-server-1.3.0.0-40_AM.fc8.src.rpm are present. Is there a way to set the version so that my package always wins? That way, I can use the 100% official repositories as the starting point and only have my little mods. Thanks for any pointers n.b. at the moment, I'm just pruning the packages I need to change out of the official versions (local copies of course), but this is tedious and fraught with error. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------

2 2

Dazed and confused....
by Bryce 06 Feb '08

06 Feb '08

Just playing around with a miniature version of koji at home, building off my own box (i386/x86_64) using koji-1.2.5 Issue 1. The kernel, because my build host is defined as arch i386, x86_64 when I pass a kernel build in, it passes "--target i386" which leads to the usual train wreck of no i386 config how do I pass in i686 specifically for the kernel? Issue 2. One of the fun items in xen is that when you're building the 64bit version there is an odd dependency on pulling in a 32bit glibc-devel by adding /usr/include/gnu/stubs-32.h to the dependency list, when building in x86_64 that dependancy cannot get satisfied. How can I beat the tag into realizing it can pull from the i386 repo to fulfill that requirement? Phil =--=

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys February 2008