corrupt rpmdb in mock-chroot
by Paul B Schroeder
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...
15 years, 6 months
Koji server installation
by Degremont, Guillaume
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 ^^
15 years, 6 months
Patch adding rpmbuild -bi to makefile.common
by Julian Sikorski
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)\""
15 years, 6 months
Koji 1.3 release
by Jesse Keating
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!
15 years, 6 months
[PATCH] Add anaconda-runtime to the package list for buildinstall
by Mark McLoughlin
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
15 years, 6 months
[MOCK/PATCH] Make logging line-buffered
by Enrico Scholz
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
15 years, 7 months
koji add-group?
by Paul B Schroeder
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
15 years, 7 months
koji.build: Session expired
by Paul B Schroeder
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
15 years, 7 months
Unresolvable deps when building Rawhide.
by William F. Acker WB2FLW +1 303 722 7209
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
15 years, 7 months
