New Koji Setup - regen-repo task fails
by Kirk Harr
Hello,
When setting up a new Koji setup, I submit a regen-repo task which is picked up by the single builder host that I have setup, which fails with a message in the kojid.log file:
<snip>
2015-02-12 14:48:35,496 [WARNING] koji.TaskManager: TRACEBACK: Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 1161, in runTask
response = (handler.run(),)
File "/usr/lib/python2.7/site-packages/koji/tasks.py", line 157, in run
return koji.util.call_with_argcheck(self.handler, self.params, self.opts)
File "/usr/lib/python2.7/site-packages/koji/util.py", line 139, in call_with_argcheck
return func(*args, **kwargs)
File "/usr/sbin/kojid", line 3536, in handler
raise koji.GenericError, "Repo directory missing: %s" % path
GenericError: Repo directory missing: /mnt/koji/repos/dist-centos6-build/1085
</snip>
This directory /mnt/koji/repos/dist-centos6-build/1085 does exist on the host inside /mnt/koji which is a GlusterFS share which the Kojira/Koji-hub/Koji-web host and the builder host share with each other. Is there any cause for this error to occur when the directory referenced as missing does actually exist?
Thanks,
Kirk Harr
Systems and Network Engineer
End Point Corporation
8 years, 7 months
[PATCH] Read some defaults from an optional config file
by Pat Riehecky
From: Pat Riehecky <riehecky(a)fnal.gov>
Pungi's highly customizable behavior lends itself to some fairly long
execution lines. The attached patch will allow setting some defaults
in a ~/.pungirc while still allowing the end user to override them
on the command line.
I hope to eventually expand this to cover more of the pungi options.
But first things first, are there any objections to this patch?
Pat Riehecky (1):
Allow for setting some defaults via a .pungirc
src/pypungi/config.py | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
8 years, 7 months
[rpkg] A new format for 'sources' files
by Mathieu Bridon
As part of the move away from MD5 for the source files hashes in the lookaside
cache, we have decided to change the format of the 'sources' files, so it
includes the hash type, to make it easier to identify which hash was used.
We agreed on using the BSD-style format, as returned on Linux by passing the
extra --tag option to commands like md5sum, sha512sumn, etc.
In addition, we decided to forbid mixing hash types in a single sources file,
forcing maintainers to use `fedpkg new-sources` the first time they upload an
additional source file.
This 4 patches series implements all that, with loads of unit tests, and some
code cleanup.
src/pyrpkg/__init__.py | 60 ++++-----
src/pyrpkg/sources.py | 123 ++++++++++++------
test/test_sources.py | 334 ++++++++++++++++++++++++++++++++++--------------
3 files changed, 359 insertions(+), 158 deletions(-)
https://fedorahosted.org/rel-eng/ticket/5846
8 years, 8 months
[PATCH 0/3] pungi patches for lorax-dnf support
by Brian C. Lane
I took a look at pungi and decided that with the state it is in, and my lack of
deep understanding of it, I don't want to tackle converting it to DNF. So, in
order to support the ability to independently move lorax to DNF and Python3
I've converted the library call to run lorax as a process.
I'm still undecided about moving lorax to DNF for F22 or not. I'll probably
make a decision on that after tomorrow's Anaconda DNF test day.
I *am* going to make the switch for rawhide on Friday though, so these changes
will need to be in the rawhide version of pungi soon.
I've done multiple test runs and things look good, at least on x86_64. The only
issues I have right now are that the boot.iso is about 200M larger than the F21
one, and DNF doesn't log transaction decisions yet so it's hard to track down
what's getting pulled in by what.
Brian C. Lane (3):
Close child fds when using subprocess
Call lorax as a process not a library
Add the option to pass a custom path for the multilib config files
src/bin/pungi.py | 3 ++
src/pypungi/__init__.py | 83 +++++++++++++++++++++++++++----------------------
src/pypungi/config.py | 1 +
src/pypungi/multilib.py | 52 +++++++++++++++++++++----------
src/pypungi/util.py | 5 +--
5 files changed, 88 insertions(+), 56 deletions(-)
--
2.1.0
8 years, 8 months
Koji running on RHEL / CentOS 7
by Allen Hewes
Hi,
I am trying to move from Koji 1.9.0 on RHEL 5.11 to Koji 1.9.0 (gitcd45e886) on CentOS 7. But it didn't help my issue:
Testing out the new Koji instance with a task submission:
$ koji --debug regen-repo el5-decisiv
successfully connected to hub
Warning: el5-decisiv is not a build tag
Warning: tag el5-decisiv has an empty arch list Regenerating repo for tag el5-decisiv Watching tasks (this may be safely interrupted)...
30 newRepo (el5-decisiv): open (koji.decisiv.net) Traceback (most recent call last):
File "/usr/bin/koji", line 6566, in <module>
rv = locals()[command].__call__(options, session, args)
File "/usr/bin/koji", line 6410, in handle_regen_repo
return watch_tasks(session, [task_id], quiet=options.quiet)
File "/usr/bin/koji", line 472, in watch_tasks
changed = task.update()
File "/usr/bin/koji", line 377, in update
self.info = self.session.getTaskInfo(self.id, request=True)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1556, in __call__
return self.__func(self.__name,args,opts)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1899, in _callMethod
return self._sendCall(handler, headers, request)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1810, in _sendCall
return self._sendOneCall(handler, headers, request)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1830, in _sendOneCall
response = cnx.getresponse()
File "/usr/lib64/python2.7/httplib.py", line 1045, in getresponse
response.begin()
File "/usr/lib64/python2.7/httplib.py", line 409, in begin
version, status, reason = self._read_status()
File "/usr/lib64/python2.7/httplib.py", line 365, in _read_status
line = self.fp.readline(_MAXLINE + 1)
File "/usr/lib64/python2.7/socket.py", line 476, in readline
data = self._sock.recv(self._rbufsize)
File "/usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py", line 140, in recv
return con.recv(bufsize, flags)
OpenSSL.SSL.SysCallError: (-1, 'Unexpected EOF')
I added a rescue of SSL.SysCallError in the recv() function in /usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py:
diff -uab /usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py /usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py.b
--- /usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py 2015-01-29 04:00:08.000000000 +0000
+++ /usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py.b 2015-01-29 04:00:56.224059850 +0000
@@ -138,6 +138,11 @@
try:
return con.recv(bufsize, flags)
+ except SSL.SysCallError as e:
+ if e.args == (-1, 'Unexpected EOF'):
+ break
+ else:
+ raise
except SSL.ZeroReturnError:
return None
except SSL.WantReadError:
Which then the task submission succeeds:
$ koji --debug regen-repo el5-decisiv
successfully connected to hub
Warning: el5-decisiv is not a build tag
Warning: tag el5-decisiv has an empty arch list Regenerating repo for tag el5-decisiv Watching tasks (this may be safely interrupted)...
32 newRepo (el5-decisiv): free
32 newRepo (el5-decisiv): free -> closed
0 free 0 open 1 done 0 failed
32 newRepo (el5-decisiv) completed successfully
I couldn't find a Koji ticket for this error so I don't know if I am making it worse or what I added is Good Enough to use? Is this a known issue?
I also had to install a newer createrepo. I was getting the mergerepo error here:
https://bugzilla.redhat.com/show_bug.cgi?id=1058975
Maybe createrepo should be updated for EPEL 7?
/allen
________________________________
Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
8 years, 9 months
Exporting existing environment variables into mock
by Arun SAG
My build environment (jenkins) has an environment variable named
'BUILD_NUMBER', i want it to be available as a macro. To achieve this
i have added something like this to my mock configuration file
config_opts['macros']['%build_number'] = os.getenv('BUILD_NUMBER') if
os.getenv('BUILD_NUMBER') != None else time.strftime('%d%m%Y%I%M')
But, this os.getenv('BUILD_NUMBER') always returns 'None'. The
environment variable which is available outside mock never gets
exported to mock environment. My mock version is 1.2.7.
--
Arun S A G
http://zer0c00l.in/
8 years, 9 months
[PATCH] for prune-signed-copies, consider file timestamp
by Mike McLean
---
cli/koji | 3 +++
1 file changed, 3 insertions(+)
diff --git a/cli/koji b/cli/koji
index 9f5c5b1..bfb0955 100755
--- a/cli/koji
+++ b/cli/koji
@@ -2037,6 +2037,9 @@ def handle_prune_signed_copies(options, session, args):
#warn about this
print "Skipping %s. Not a regular file" % signedpath
continue
+ if st.st_mtime > cutoff_ts:
+ print "Skipping %s. File newer than cutoff" % signedpath
+ continue
if options.test:
print "Would have unlinked: %s" % signedpath
else:
--
1.9.3
8 years, 9 months
docker-rpm-builder: release 1.8
by Alan Franzoni
Hello,
I've just released version 1.8 of docker-rpm-builder.
https://github.com/alanfranz/docker-rpm-builder/
Changes:
Fix some small glitches with ownership inside the container
let the user choose the output ownership
Add test to verify our scripts are executable
Cleanup install instructions
Remove dependency on assumeyes for yum.conf
I'd like to thank everybody for the feedback I got, I'm working on
making the tool more usable and on removing some rough edges.
--
My development blog: ollivander.franzoni.eu . @franzeur on Twitter
contact me at public(a)[mysurname].eu
8 years, 9 months
a couple minor patches
by Mike McLean
0001 - Added a bunch of predefined archivetypes. Most of these were
added in our internal instance over time. Let me know if any of these
look wrong.
0002 - just a nicer error message if a host authenticates as a non-host user
8 years, 9 months
