We are currently shipping mock in CentOS-Extras that includes configs for
building against CentOS (without EPEL enabled). I think it makes sense for us to
cough up these configs for inclusion upstream. I'm happy to keep an eye on them
from our end if they need tweaking in the future.
Brian Stinson (5):
add CentOS base x86 configs
add CentOS base x86_64 configs
add CentOS base arm configs
add CentOS base ppc configs
install CentOS base configs
Makefile.am | 1 +
etc/mock/centos-5-i386.cfg | 61 +++++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-5-i686.cfg | 61 +++++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-5-x86_64.cfg | 61 +++++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-6-i386.cfg | 61 +++++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-6-x86_64.cfg | 61 +++++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-7-aarch64.cfg | 59 +++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-7-armhfp.cfg | 60 ++++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-7-i386.cfg | 61 +++++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-7-ppc64.cfg | 59 +++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-7-ppc64le.cfg | 59 +++++++++++++++++++++++++++++++++++++++++
etc/mock/centos-7-x86_64.cfg | 61 +++++++++++++++++++++++++++++++++++++++++++
12 files changed, 665 insertions(+)
create mode 100644 etc/mock/centos-5-i386.cfg
create mode 100644 etc/mock/centos-5-i686.cfg
create mode 100644 etc/mock/centos-5-x86_64.cfg
create mode 100644 etc/mock/centos-6-i386.cfg
create mode 100644 etc/mock/centos-6-x86_64.cfg
create mode 100644 etc/mock/centos-7-aarch64.cfg
create mode 100644 etc/mock/centos-7-armhfp.cfg
create mode 100644 etc/mock/centos-7-i386.cfg
create mode 100644 etc/mock/centos-7-ppc64.cfg
create mode 100644 etc/mock/centos-7-ppc64le.cfg
create mode 100644 etc/mock/centos-7-x86_64.cfg
I just released new version of Mock.
The release notes are here:
I will cc it here (sans links):
mock-1.2.18 has several bugfixes:
copy just content of SRPM not the attributes (RHBZ#1301985)
do not fail when we cannot link default.cfg (RHBZ#1305367)
Build always fails when using --nocheck (RHBZ#1327594)
keep machine-id in /etc/machine-id (RHBZ#1344305)
And several changes:
Unconditionally setup resolver config
use DNF for F24 chroot
Escape the escape sequences in PROMPT_COMMAND, improve prompt
Use root name instead config name for backups dir
Add MIPS personalities
scm plugin handle better submodules
And there are two new groups of configs. There are new Mageia configs:
And there are new custom configs:
Those configs does not have any repository configured and base is empty.
config_opts['chroot_setup_cmd'] = ''
This is useful if you want to prepare the chroot yourself. Or when you
use it with mockchain with `--addrepo=REPOS` option. This was added on
request of Koschei, which will use it.
Trying to get kojira to start up, with a new cert (using the instructions
for a self hosted CA on the koji server). Koji version 1.9.0-5 on a Centos
6.6 box. I get the following error:
Traceback (most recent call last):
File "/usr/sbin/kojira", line 743, in <module>
session.ssl_login(options.cert, options.ca, options.serverca)
File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1729, in
sinfo = self.callMethod('sslLogin', proxyuser)
File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1778, in
return self._callMethod(name, args, opts)
File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1898, in
return self._sendCall(handler, headers, request)
File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1809, in
return self._sendOneCall(handler, headers, request)
File "/usr/lib/python2.6/site-packages/koji/__init__.py", line 1827, in
File "/usr/lib64/python2.6/httplib.py", line 908, in endheaders
File "/usr/lib64/python2.6/httplib.py", line 780, in _send_output
File "/usr/lib64/python2.6/httplib.py", line 759, in send
File "/usr/lib/python2.6/site-packages/koji/ssl/SSLConnection.py", line
108, in sendall
sent = con.send(data, flags)
OpenSSL.SSL.Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE',
'certificate verify failed')]
If I run openssl from the command line, to verify the cert, it succeeds:
# openssl verify -CAfile /etc/pki/koji/koji_ca_cert.crt
The cert in question is SHA256/RSA4096 (matching the params of the certs
we've previously used).
Squirrels are the lunatic teenagers of the animal kingdom.
I didn't realize that I didn't have this before, so I've attached a
patch that applies onto devel that installs the Mageia configs.
Please apply at your earliest convenience.
Thanks in advance,
真実はいつも一つ！/ Always, there's only one truth!
Since my last email two months ago, I've been working steadily
towards the completion of our infrastructure bringup for supporting
COPR oriented workflows. I've added tito and copr CLI tools to the
distribution to enable CLI-centric workflows as well.
While we are still working on bringing up MirrorBrain for metalinks,
we have a rudimentary script that generates a yum-style mirrorlist
that DNF and mock can consume. This has allowed me to update and
expand the Mageia build target configuration for mock, which I have
added to our mock package.
The patches attached to this email update and expand the Mageia
configs, including adding Mageia 6. Note that the Mageia configuration
for armv7hl does not yet work because we are still in the process of
completing the build. We've estimated that it should be finished
within the next couple of days, and then the switch will be flipped to
make it public. This is why the Mageia armv7hl configuration files are
in a separate patch. While I have applied the entire patch series to
the Mageia mock package, it is up to you on whether you wish to
include the armv7hl configuration files or not right now.
These patches should apply cleanly on top of the devel branch for mock.
真実はいつも一つ！/ Always, there's only one truth!
I'd like to use koji as a layered build system. I'm not sure that this is the right place, or that koji is the right tool. If not, please let me know what is.
We are building rpms against Fedora and CentOS/RHEL 7. While all our dependencies are in Fedora, that's not the case for RHEL. We would like to store our dependencies (updated rarely) as well as our product packages (updated often) in our local koji, but we'd like the rest of the distribution to be picked up from upstream, rather than having to import (and keep updating) all of our upstream dependencies into our local koji instance.
To make the case concrete, our non-upstream dependencies include gcc 5.3 (included in Fedora 23, but not in RHEL), binutils and isl (dependencies of gcc), boost (we need a later version than is available), ninja-build, ragel, gdb, and pyparsing.
Currently, we just regenerate them each build. Ideally we pull them from our local koji instance.