About half of my builds fail with ...
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 158, 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 154, in call_with_argcheck
return func(*args, **kwargs)
File "/usr/sbin/kojid", line 3817, in handler
File "/usr/sbin/kojid", line 460, in init
rv = self.mock(['--init'])
File "/usr/sbin/kojid", line 408, in mock
incremental_upload(self.session, fname, fd, uploadpath, logger=self.logger)
File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 48, in incremental_upload
fast_incremental_upload(session, fname, fd, path, retries, logger)
File "/usr/lib/python2.7/site-packages/koji/daemon.py", line 87, in fast_incremental_upload
result = session.rawUpload(contents, offset, path, fname, overwrite=True)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1577, in __call__
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1920, in _callMethod
return self._sendCall(handler, headers, request)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1831, in _sendCall
return self._sendOneCall(handler, headers, request)
File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 1850, in _sendOneCall
File "/usr/lib64/python2.7/httplib.py", line 820, in send
File "/usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py", line 111, in sendall
File "/usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py", line 82, in close
File "/usr/lib/python2.7/site-packages/koji/ssl/SSLConnection.py", line 53, in shutdown
If I simply resubmit the same build request enough times the job will eventually succeed, but it's really annoying as is. This all started when I upgraded to koji-1.10. Is anyone else seeing this or did I perhaps screw something up with the upgrade? I filed a bug a few days ago but have heard nothing there.
This patch allows the usage of plugins on cli. Majority of the changes are just a re-ordering of existing code.
Christos Triantafyllidis (3):
Added support for plugins at client
Added plugin configuration in client conf file
Passing options variable to plugins
cli/koji | 91 +++++++++++++++++++++++++++++++++++++----------------------
cli/koji.conf | 8 ++++++
2 files changed, 65 insertions(+), 34 deletions(-)
I just released new mock release (mock-1.2.13). It is bugfix release,
but some bugfix may be interesting for you:
* Fedora 23 configs are reverted back to use yum again. To be on pair
* Lot of fixes for --new-chroot option
* Mockchain can download SRPM from Dropbox
* DNF does not install weak dependencies by default
* When cleaning up chroots, mock now exclude mountpoints
* When you build using DNF (rawhide) on systems, which does not have DNF
(EL6, 7), mock will print warning, wait for confirmation, tell you how
to suppress this warning next time. Nevertheless this warning is not
fatal and Mock can continue using YUM.
* Previously package_state plugin always used YUM, now it use DNF when
chroot is configured to use DNF.
* When file `/usr/bin/yum-deprecated` is present on your machine, then
variable `config_opts['yum_command']` is set to this v
alue by default.
* Several others bugfixes
The following patch is adding support for PAM authentication for the
koji-hub and BasicAuth for the koji-web.
This is useful for our internal use case as it allows us to login without
the overhead of setting up either a CA or a kerberos realm for our users.
The configuration is backwards compatible and hopefully similar to the
other authntication methods.
To active PAM support on hub you define the option:
PAMService = koji
in hub.conf. The value will be the name of the PAM service. Note the call
to the PAM module is done via unpriviledged call thus the use of pam_unix
won't be possible.
Note that activating this option will have as result that username/password
combinations from the DB will no longer be checked (similarly to when
activating kerberos or SSL client auth).
The BasicAuth for koji-web requires 2 changes:
a) To enable WSGIPassAuthorization for /koji/login in httpd configuration.
That passes the authorization variable from the apache to the application.
b) Set the "BasicAuthRealm" option to the Basic Authentication Realm that
will be presented to the user to login.
Finally python-pam package has been added to the hub's dependencies.
Christos Triantafyllidis (1):
- Added PAM support for hub - Added BasicAuth support for web
hub/hub.conf | 4 +++-
hub/kojixmlrpc.py | 2 ++
koji.spec | 1 +
koji/auth.py | 33 +++++++++++++++++++++++++--------
koji/server.py | 2 ++
www/conf/kojiweb.conf | 5 +++++
www/conf/web.conf | 3 +++
www/kojiweb/index.py | 18 +++++++++++++++++-
www/kojiweb/wsgi_publisher.py | 9 +++++++--
9 files changed, 65 insertions(+), 12 deletions(-)
Quick question, would you consider to use mergerepo_c with option
--all  in koji ?
I am happy to work on a patch if it would be accepted. Maybe, we can
keep default behavior and enable with an option on the tag.
My use case is to be able to ship different release built against fix
external repo package that may not be latest version
(Buildrequires:pkg = 1.0.0 while external repo has already 1.1.0)
Include all packages with the same name and arch if version or
release is different. If used --method argument is ignored!
I would like to ask what is current status of migrating Koji to use DNF for building?
I am mainly interested whether Koji will use DNF for building F23 packages, or you postpone it for F24?
Because in such case I would revert fedora-23-*.cfg default configs in Mock to use Yum so Mock is on pair with Koji.
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
Because Fedora is a self-hosted system, circular dependencies are a fact of life. Self-hosted compilers and the like will always exist.
But I think the circular BR nature of redhat-rpm-config and macro packages is unnecessary self-inflicted pain. Currently, I am trying to backport (into a downstream distribution) the introduction of go-srpm-macros into redhat-rpm-config:
Yet because redhat-rpm-config itself is pulled into the build root for go-srpm-macros, it introduces a circular build dependency.
I could imagine external ways out of this (try dropping the BR of rrc for go-srpm-macros externally), but it would seem to me to be a lot saner just to include the macros themselves in redhat-rpm-config.
Thoughts? (Is this the right list?)