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:
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
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?
Systems and Network Engineer
End Point Corporation
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(-)
i'm try to build a java package for epel-6 which use java-8.
unfortunately it seem it's not enough to simple add
since it's install it, but also still install during the mock setup
session old java packages ie:
java-1.5.0-gcj x86_64 126.96.36.199-29.1.el6 os
java-1.6.0-sun x86_64 1:188.8.131.52-1jpp.1.el6 os
java-1.7.0-ibm x86_64 1:184.108.40.206.0-1jpp.2.el6_4 os
java-1.7.0-ibm-devel x86_64 1:220.127.116.11.0-1jpp.2.el6_4 os
java-1.7.0-oracle x86_64 1:18.104.22.168-1jpp.2.el6_4 os
and i'm not bale to exclude them. in rpm the is a Obsoletes: but there
is no such thing as "BuildRequiresObsoletes":-(
what's more i can't run system-switch-java since it's required root
access and there is no command line option to switch to a given specific
so during build the system use the default javac which is not java8 but
ibm's java7 (IBM J9 VM (build 2.6, JRE 1.7.0).
is there any way to force java8? or is there any way to exclude other
java vm jre to install into mock during build?
thanks in advance.
Levente "Si vis pacem para bellum!"
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
src/pyrpkg/__init__.py | 60 ++++-----
src/pyrpkg/sources.py | 123 ++++++++++++------
test/test_sources.py | 334 ++++++++++++++++++++++++++++++++++--------------
3 files changed, 359 insertions(+), 158 deletions(-)
I wanted to share with the community a simple git-hook + listener I wrote
to automate koji builds from git. A post-receive hook analyzes commit
messages for any trigger flags, it then sends the necessary info over to a
listener on the koji-hub which in turn triggers a build via the Koji API.
It is something I wrote for my own use and in the spirit of opensource I
wanted to toss it out there so that others may make use of it as well. The
code currently lives on my public github repo @
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(-)
Thank you for reviewing the patch and sorry for the late reply.
Here’s a fixed version. Also I’ve a question :)
On 2/16/15, 2:16 PM, "Miroslav Suchy" <msuchy(a)redhat.com> wrote:
>>On 02/16/2015 09:11 PM, Clark Williams wrote:
[ I changed the api to passed to results of the current build to Œpost
build¹ hook ]
>>I do not understand the necessity of changing API. The result dir is
>>defined in buildroot.resultdir in __init__() of plugin and stored to
>>instance variable and then just walk() that directory.
The problem with that approach is that you will end up trying to sign
the srpm twice, and/or signing packages you have built in previous run
but you actually don¹t want to sign. For larger packages, that might be
an issue. What is your opinion on that ?