buildsys May 2008

buildsys@lists.fedoraproject.org

11 participants
9 discussions

corrupt rpmdb in mock-chroot
by Paul B Schroeder 02 Jun '08

02 Jun '08

Hello all... On my x86_64 (CentOS 5.1) system I use mock to init an i386 chroot for both Fedora 8 and CentOS 5.1. The init appears to work fine, but when I drop into a mock-shell for either F8 or CentOS my rpm database is corrupt on both accounts: mock-chroot> rpm -qa rpmdb: Program version 4.3 doesn't match environment version error: db4 error(-30974) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db3 - (-30974) error: cannot open Packages database in /var/lib/rpm Rebuilding the rpm database seems to fix this, but it's a pain to be sure. Any ideas as to why I'm seeing this corruption when creating an i386 mock chroot from a x86_64 system? Also, FYI, when I do this for x86_64 chroots or if I do this from my i386 CentOS system, the rpm database does not get corrupt. Thanks...Paul...

3 6

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

Patch adding rpmbuild -bi to makefile.common
by Julian Sikorski 28 May '08

28 May '08

Hello, this patch the install target to makefile common, completing the set of possible options. Julian P.S. Please CC me, I'm not subscribed. ? Makefile.common-install.patch Index: Makefile.common =================================================================== RCS file: /cvs/extras/common/Makefile.common,v retrieving revision 1.102 diff -u -r1.102 Makefile.common --- Makefile.common 23 May 2008 17:47:47 -0000 1.102 +++ Makefile.common 28 May 2008 06:59:35 -0000 @@ -177,7 +177,7 @@ PREP_ARCHES = $(addprefix prep-,$(ARCHES)) ## list all our bogus targets -.PHONY :: $(ARCHES) sources uploadsource upload export check build-check plague koji build cvsurl chain-build test-srpm srpm tag force-tag verrel new clean patch prep compile install-short compile-short FORCE local scratch-build scratch-build-% +.PHONY :: $(ARCHES) sources uploadsource upload export check build-check plague koji build cvsurl chain-build test-srpm srpm tag force-tag verrel new clean patch prep compile install install-short compile-short FORCE local scratch-build scratch-build-% # The TARGETS define is meant for local module targets that should be # made in addition to the SOURCEFILES whenever needed @@ -338,6 +338,9 @@ compile: sources $(TARGETS) $(RPM_WITH_DIRS) -bc $(SPECFILE) +install: sources $(TARGETS) + $(RPM_WITH_DIRS) -bi $(SPECFILE) + compile-short: sources $(TARGETS) $(RPM_WITH_DIRS) --nodeps --short-circuit -bc $(SPECFILE) @@ -577,6 +580,7 @@ @echo " local Local test rpmbuild binary" @echo " prep Local test rpmbuild prep" @echo " compile Local test rpmbuild compile" + @echo " install Local test rpmbuild install" @echo " compile-short Local test rpmbuild short-circuit compile" @echo " install-short Local test rpmbuild short-circuit install" @echo " export Create clean export in \"cvs-$(TAG)\""

1 0

Koji 1.3 release
by Jesse Keating 16 May '08

16 May '08

I've revived the 1.3 milestone in the Koji Trac space ( https://fedorahosted.org/koji/milestone/1.3 ) and triaged all the existing Trac tickets and bugzillas against koji. I've added what I thought was appropriate to target for a 1.3 release in the near future (next 3~ weeks?). Please review and make sure what I've put on there is sane and add anything else reasonable to target for the next couple releases. I hope to get all the code committed in the next couple weeks, freeze/branch the source control and do some release testing and finally make a release for rawhide, F8/F9 updates, and perhaps even EPEL5. -- Jesse Keating Fedora -- Freedom² is a feature!

1 0

[PATCH] Add anaconda-runtime to the package list for buildinstall
by Mark McLoughlin 12 May '08

12 May '08

With e.g.: repo --name=rawhide --baseurl=http://foo %packages %end You get: OSError: Got an error from /usr/lib/anaconda-runtime/buildinstall: and trying out the buildinstall command directly, you see: Running buildinstall... No Match for argument anaconda-runtime Nothing to download The issue here is that one of the first things buildinstall tries to do is install anaconda-runtime from the supplied repository, so the user must add anaconda-runtime to the package list or pungi fails. Automatically add it to the package list rather than requiring the user to do it. Signed-off-by: Mark McLoughlin <markmc(a)redhat.com> --- src/bin/pungi.py | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/bin/pungi.py b/src/bin/pungi.py index 91ca403..bcbe6fd 100755 --- a/src/bin/pungi.py +++ b/src/bin/pungi.py @@ -77,6 +77,10 @@ def main(): # Actually do work. if not opts.sourceisos: + if opts.do_all or opts.do_buildinstall: + # buildinstall requires anaconda-runtime (rh #443371) + ksparser.handler.packages.add(["anaconda-runtime"]) + if opts.do_all or opts.do_gather: mygather = pypungi.gather.Gather(config, ksparser) mygather.getPackageObjects() -- 1.5.4.5

4 8

[MOCK/PATCH] Make logging line-buffered
by Enrico Scholz 11 May '08

11 May '08

Current output processing reads data and puts them to logging without taking care about eol. This produces ugly and unreadable output like | checking whether to enable maintainer-specific portions of Makefiles... | no | checking build system type... | i386-redhat-linux-gnu Patch reads output into a buffer which is given to logging after a newline. Signed-off-by: Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de> --- py/mock/util.py | 46 +++++++++++++++++++++++++++++++++++----------- 1 files changed, 35 insertions(+), 11 deletions(-) diff --git a/py/mock/util.py b/py/mock/util.py index 9f0eb3a..6e3d88e 100644 --- a/py/mock/util.py +++ b/py/mock/util.py @@ -225,33 +225,57 @@ def condPersonality(per=None): def logOutput(fds, logger, returnOutput=1, start=0, timeout=0): output="" done = 0 + input = {} # set all fds to nonblocking for fd in fds: + input[fd] = '' flags = fcntl.fcntl(fd, fcntl.F_GETFL) if not fd.closed: fcntl.fcntl(fd, fcntl.F_SETFL, flags| os.O_NONBLOCK) while not done: - if (time.time() - start)>timeout and timeout!=0: + if timeout!=0 and (time.time() - start)>timeout: done = 1 break - i_rdy,o_rdy,e_rdy = select.select(fds,[],[],1) + i_rdy,o_rdy,e_rdy = select.select(fds,[],[],1) for s in i_rdy: # slurp as much input as is ready - input = s.read() - if input == "": + inp = s.read() + if inp == "": done = 1 break - if logger is not None: - for line in input.split("\n"): - if line == '': continue - logger.debug(chomp(line)) - for h in logger.handlers: - h.flush() + if returnOutput: - output += input + output += inp + + if logger is None: + continue + + assert('\n' not in input[s]) + input[s] += inp + if '\n' not in inp: + continue + + lines = input[s].split("\n") + input[s] = lines[len(lines)-1] + del lines[len(lines)-1] + + for line in lines: + if line == '': continue + logger.debug(chomp(line)) + for h in logger.handlers: + h.flush() + + if logger is not None: + for fd in fds: + if input[s]=='': continue + logger.debug(chomp(input[s])) + + for h in logger.handlers: + h.flush() + return output # logger = -- 1.5.4.1

1 0

koji add-group?
by Paul B Schroeder 08 May '08

08 May '08

Hmm.. Strange.. I don't seem to have the add-group command (see further below). I had to do this via psql to be able to "koji add-group-pkg": koji=> insert into groups (name) values('build'); INSERT 0 1 koji=> select * from groups; id | name ----+------- 1 | build (1 row) koji=> insert into group_config (group_id, tag_id, display_name) values(1, 2, 'build'); INSERT 0 1 koji=> select * from group_config; group_id | tag_id | blocked | exported | display_name | is_default | uservisible | description | langonly | biarchonly | create_event | revoke_event | active ----------+--------+---------+----------+--------------+------------+-------------+-------------+----------+------------+--------------+--------------+-------- 1 | 2 | f | t | build | | | | | | 3413 | | t (1 row) koji=> select * from group_package_listing; group_id | tag_id | package | blocked | type | basearchonly | requires | create_event | revoke_event | active ----------+--------+---------+---------+---------+--------------+----------+--------------+--------------+-------- 1 | 2 | bash | f | default | | | 3414 | | t (1 row) ---------------------------------------------- [root@koji koji]# rpm -q koji koji-1.2.2-2.fc8 [root@koji koji]# koji add-group --help Available commands: build Build a package from source buildinfo Print basic information about a build cancel Cancel tasks and/or builds chain-build Build one or more packages from source download-build Download a built package help List available commands latest-pkg Print the latest packages for a tag list-api Print the list of XML-RPC APIs list-buildroot List the rpms used in or built in a buildroot list-groups Print the group listings list-hosts Print the host listing list-pkgs Print the package listing for tag or for owner list-tag-history Print a history of tag operations list-tag-inheritance Print the inheritance information for a tag list-tagged List the builds or rpms in a tag list-tags Print the list of tags list-targets List the build targets list-tasks Print the list of tasks list-untagged List untagged builds mock-config Create a mock config move-pkg 'Move' one or more packages between tags resubmit Retry a canceled or failed task, using the same parameter as the original task. rpminfo Print basic information about an RPM show-groups Show groups data for a tag tag-pkg Apply a tag to one or more packages taginfo Print basic information about a tag taskinfo Show information about a task untag-pkg Remove a tag from one or more packages watch-logs Watch logs in realtime watch-task Track progress of particular tasks (Type "koji --help" for help about global options or "koji <command> --help" for help about a particular command's options.) Usage: koji [global-options] command [command-options-and-arguments] koji: error: Unknown command: add_group

3 2

koji.build: Session expired
by Paul B Schroeder 08 May '08

08 May '08

Hello.. I'm running F8 with the latest koji-* packages: [root@koji koji]# rpm -qa 'koji*' koji-hub-1.2.2-2.fc8 koji-1.2.2-2.fc8 koji-utils-1.2.2-2.fc8 koji-web-1.2.2-2.fc8 koji-builder-1.2.2-2.fc8 I've been following the Koji Server HOWTO here: http://fedoraproject.org/wiki/Koji/ServerHowTo I've gotten all of the way through it, but I'm having issues when starting kojira. It doesn't stay running and it seems to somehow be causing kojid to shutdown as well. I've turned on debug for kojid and kojira. I see this in kojid.log: 2008-05-07 06:10:37,895 [ERROR] koji.build: Session expired 2008-05-07 06:10:37,896 [WARNING] koji.build: Shutting down, please wait... Below is a full output of what I see in those logs. Am I missing something simple? Anybody have any clue what's going wrong? Thanks in advance...Paul... /var/log/kojid.log (before I attempt to start kojira): 2008-05-07 06:10:04,662 [INFO] koji.build: Starting up 2008-05-07 06:10:05,125 [DEBUG] koji.build.TaskManager: Local buildroots: 0 2008-05-07 06:10:05,125 [DEBUG] koji.build.TaskManager: Active buildroots: 0 2008-05-07 06:10:05,126 [DEBUG] koji.build.TaskManager: Expired/stray buildroots: 0 2008-05-07 06:10:05,438 [DEBUG] koji.build.TaskManager: Task Load: 0.0 2008-05-07 06:10:05,438 [DEBUG] koji.build.TaskManager: Current tasks: {} 2008-05-07 06:10:05,743 [DEBUG] koji.build.TaskManager: hostdata: {'capacity': 2.0, 'name': 'koji.bcstx.cacheflow.com', 'enabled': True, 'arches': 'i386 x86_64', 'task_load': 0.0, 'ready': True, 'user_id': 3, 'id': 1} 2008-05-07 06:10:05,750 [DEBUG] koji.build.TaskManager: disk space available in '/var/lib/mock': 43829 MB 2008-05-07 06:10:06,186 [DEBUG] koji.build.TaskManager: Load Data: 2008-05-07 06:10:06,186 [DEBUG] koji.build.TaskManager: hosts: [{'capacity': 2.0, 'name': 'koji.bcstx.cacheflow.com', 'channels': [1, 2], 'arches': 'i386 x86_64', 'task_load': 0.0, 'id': 1}] 2008-05-07 06:10:06,187 [DEBUG] koji.build.TaskManager: tasks: [] 2008-05-07 06:10:06,187 [DEBUG] koji.build.TaskManager: bins: {'1:noarch': 1, '2:noarch': 1, '1:x86_64': 1, '1:i386': 1, '2:x86_64': 1, '2:i386': 1} /var/log/kojid.log (after I start kojira): 2008-05-07 06:10:21,504 [DEBUG] koji.build.TaskManager: Local buildroots: 0 2008-05-07 06:10:21,505 [DEBUG] koji.build.TaskManager: Active buildroots: 0 2008-05-07 06:10:21,505 [DEBUG] koji.build.TaskManager: Expired/stray buildroots: 0 2008-05-07 06:10:21,818 [DEBUG] koji.build.TaskManager: Task Load: 0.0 2008-05-07 06:10:21,818 [DEBUG] koji.build.TaskManager: Current tasks: {} 2008-05-07 06:10:22,138 [DEBUG] koji.build.TaskManager: hostdata: {'capacity': 2.0, 'name': 'koji.bcstx.cacheflow.com', 'enabled': True, 'arches': 'i386 x86_64', 'task_load': 0.0, 'ready': True, 'user_id': 3, 'id': 1} 2008-05-07 06:10:22,145 [DEBUG] koji.build.TaskManager: disk space available in '/var/lib/mock': 43829 MB 2008-05-07 06:10:22,586 [DEBUG] koji.build.TaskManager: Load Data: 2008-05-07 06:10:22,586 [DEBUG] koji.build.TaskManager: hosts: [{'capacity': 2.0, 'name': 'koji.bcstx.cacheflow.com', 'channels': [1, 2], 'arches': 'i386 x86_64', 'task_load': 0.0, 'id': 1}] 2008-05-07 06:10:22,587 [DEBUG] koji.build.TaskManager: tasks: [] 2008-05-07 06:10:22,587 [DEBUG] koji.build.TaskManager: bins: {'1:noarch': 1, '2:noarch': 1, '1:x86_64': 1, '1:i386': 1, '2:x86_64': 1, '2:i386': 1} 2008-05-07 06:10:37,895 [ERROR] koji.build: Session expired 2008-05-07 06:10:37,896 [WARNING] koji.build: Shutting down, please wait... /var/log/kojira.log: 2008-05-07 06:10:25,519 [DEBUG] koji.repo.manager: Reading current repo data 2008-05-07 06:10:25,654 [DEBUG] koji.repo.manager: Repo data: [] 2008-05-07 06:10:25,654 [DEBUG] koji.repo.manager: Scanning filesystem for repos

3 10

Unresolvable deps when building Rawhide.
by William F. Acker WB2FLW +1 303 722 7209 06 May '08

06 May '08

Hi all, When I do a Pungi run on an x86_64, I get the following. Pungi.Gather:WARNING: Unresolvable dependency jakarta-commons-beanutils-javadoc in checkstyle.noarch Pungi.Gather:INFO: Added jakarta-commons-beanutils.x86_64 for checkstyle.noarch Pungi.Gather:WARNING: Unresolvable dependency antlr-javadoc in checkstyle.noarch Pungi.Gather:INFO: Added jdom.x86_64 for checkstyle.noarch Pungi.Gather:WARNING: Unresolvable dependency xml-commons-apis-javadoc in checkstyle.noarch Pungi.Gather:WARNING: Unresolvable dependency ant-javadoc in checkstyle.noarch I believe this is related to the last batch of package exclusions to save space that appeared in the fedora-9 ks file with the latest version of Pungi. Is this condition OK? Might it be possible for someone to select the wrong package combination and have a failed installation, or would this be caught when dependencies are checked Thanks. -- Bill in Denver

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys May 2008