buildsys February 2009

buildsys@lists.fedoraproject.org

24 participants
23 discussions

[PATCH] Add a "sources" target as an alias for "tarball".
by Jeffrey Ollie 17 Feb '09

17 Feb '09

This makes building Koji packages directly from a Koji git repository in Koji possible. Highly self-referential! Signed-off-by: Jeffrey C. Ollie <jeff(a)ocjtech.us> --- Makefile | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 7432f31..fcd4dca 100644 --- a/Makefile +++ b/Makefile @@ -78,6 +78,8 @@ test-tarball: tarball: clean @git archive --format=tar --prefix=$(NAME)-$(VERSION)/ HEAD |bzip2 > $(NAME)-$(VERSION).tar.bz2 +sources: tarball + srpm: tarball $(RPM_WITH_DIRS) $(DIST_DEFINES) -bs $(SPECFILE) -- 1.6.1.3

1 0

[PATCH] Add a test-srpm target to the Makefile.
by Jeffrey Ollie 17 Feb '09

17 Feb '09

--- Makefile | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 7432f31..51196ea 100644 --- a/Makefile +++ b/Makefile @@ -81,6 +81,9 @@ tarball: clean srpm: tarball $(RPM_WITH_DIRS) $(DIST_DEFINES) -bs $(SPECFILE) +test-srpm: tarball + $(RPM_WITH_DIRS) $(DIST_DEFINES) --define "testbuild 1" -bs $(SPECFILE) + rpm: tarball $(RPM_WITH_DIRS) $(DIST_DEFINES) -bb $(SPECFILE) -- 1.6.1.2

1 0

[PATCH] Add --chainbuild option.
by Gianluca Sforna 17 Feb '09

17 Feb '09

With this patch, mock grows a --chainbuild option (and a Require on createrepo). The --chainbuild option work by creating a local yum repository in the resultdir path which is used during the BuildRequires installation step. The net result is that, when building more than one srpm in the same run, later builds can find required packages built in previous steps. --- py/mock.py | 11 +++++++++++ py/mock/backend.py | 8 ++++++++ py/mock/util.py | 7 +++++++ 3 files changed, 26 insertions(+), 0 deletions(-) diff --git a/py/mock.py b/py/mock.py index 408b421..a801807 100755 --- a/py/mock.py +++ b/py/mock.py @@ -113,6 +113,11 @@ def command_parse(config_opts): help="chroot name/config file name default: %default", default='default') + parser.add_option("--chainbuild", action="store_true", dest="chainbuild", + help="install all built RPMs in the chroot before continuing" + " with the next one", + default=False) + parser.add_option("--offline", action="store_false", dest="online", default=True, help="activate 'offline' mode.") @@ -216,6 +221,7 @@ def setup_default_config_opts(config_opts, unprivUid): config_opts['build_log_fmt_name'] = "unadorned" config_opts['root_log_fmt_name'] = "detailed" config_opts['state_log_fmt_name'] = "state" + config_opts['chainbuild'] = False config_opts['online'] = True config_opts['internal_dev_setup'] = True @@ -347,6 +353,7 @@ def set_config_opts_per_cmdline(config_opts, options, args): config_opts['cleanup_on_failure'] = False config_opts['online'] = options.online + config_opts['chainbuild'] = options.chainbuild decorate(traceLog()) def do_rebuild(config_opts, chroot, srpms): @@ -366,6 +373,10 @@ def do_rebuild(config_opts, chroot, srpms): log.info("Start(%s) Config(%s)" % (srpm, chroot.sharedRootName)) if config_opts['clean'] and chroot.state() != "clean": chroot.clean() + # if chainbuilding, prepare the local repository + if config_opts['chainbuild']: + mock.util.createRepo( chroot.resultdir ) + chroot.init() chroot.build(srpm, timeout=config_opts['rpmbuild_timeout']) elapsed = time.time() - start diff --git a/py/mock/backend.py b/py/mock/backend.py index 2bc63df..560fb03 100644 --- a/py/mock/backend.py +++ b/py/mock/backend.py @@ -57,6 +57,14 @@ class Root(object): self.chrootgid = config['chrootgid'] self.chrootgroup = 'mockbuild' self.yum_conf_content = config['yum.conf'] + + if config['chainbuild']: + self.yum_conf_content = self.yum_conf_content + '\n'.join([ + '[chainbuild]', + 'name=chainbuild', + 'baseurl=file://%s' % os.path.abspath(self.resultdir) + ]) + self.use_host_resolv = config['use_host_resolv'] self.chroot_file_contents = config['files'] self.chroot_setup_cmd = config['chroot_setup_cmd'] diff --git a/py/mock/util.py b/py/mock/util.py index f52003e..943d4bb 100644 --- a/py/mock/util.py +++ b/py/mock/util.py @@ -262,6 +262,13 @@ def logOutput(fds, logger, returnOutput=1, start=0, timeout=0): logger.debug(tail) return output + +decorate(traceLog()) +def createRepo(path): + cmd = 'createrepo %s' % path + mock.util.do( cmd, shell=True ) + + # logger = # output = [1|0] # chrootPath -- 1.6.0.6

2 3

mock problems on f10
by Lucian Langa 16 Feb '09

16 Feb '09

Hello, I'm having trouble building anything with mock (mock-0.9.13-1.fc10.noarch) for fedora-rawhide-x86_64. The error I'm getting is: rpmdb: Program version 4.5 doesn't match environment version 4.7 This happens even if I do a complete cleanup and reinit. wiping __db* from chroot, rebuilddb locally: rpmdb --dbpath /var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm/ --rebuilddb seems to work but as soon as trying to rebuild any package won't work: mock -r fedora-devel-x86_64 rebuild /root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm --no-clean INFO: mock.py version 0.9.13 starting... State Changed: init plugins State Changed: start INFO: Start(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) Config(fedora-rawhide-x86_64) State Changed: init State Changed: lock buildroot INFO: enabled root cache INFO: enabled yum cache State Changed: cleaning yum metadata INFO: enabled ccache State Changed: running yum State Changed: setup ERROR: Exception(/root/rpmbuild/SRPMS/soundmodem-0.10-6.fc10.src.rpm) Config(fedora-rawhide-x86_64) 0 minutes 8 seconds INFO: Results and/or logs in: /var/lib/mock//fedora-rawhide-x86_64/result ERROR: Command failed: # /usr/bin/yum --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ resolvedep ccache 'gtk+-devel' 'automake' 'libxml-devel' 'audiofile-devel' 'autoconf' 'alsa-lib-devel' 'gettext-devel' rpmdb: Program version 4.5 doesn't match environment version 4.7 error: db4 error(-30972) from dbenv->open: DB_VERSION_MISMATCH: Database environment version mismatch error: cannot open Packages index using db3 - (-30972) error: cannot open Packages database in /var/lib/mock/fedora-rawhide-x86_64/root/var/lib/rpm Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 229, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 84, in main base.getOptionsConfig(args) File "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig enabled_plugins=self.optparser._splitArg(opts.enableplugins)) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 192, in _getConfig self._conf = config.readMainConfig(startupconf) File "/usr/lib/python2.5/site-packages/yum/config.py", line 774, in readMainConfig yumvars['releasever'] = _getsysver(startupconf.installroot, startupconf.distroverpkg) File "/usr/lib/python2.5/site-packages/yum/config.py", line 844, in _getsysver idx = ts.dbMatch('provides', distroverpkg) TypeError: rpmdb open failed Thanks, --lucian

3 6

Re: problems of running koji on CentOS with EPEL packages
by Chen Baozi 11 Feb '09

11 Feb '09

> > This is happening because kojid is authenticating as a user that is not > associated with a build host (or perhaps not authenticating at all). You > can't run kojid as a regular user (or anonymously). The hub is trying to > determine which host is calling the function and is not finding one. Certain > calls can only be executed by build hosts. > > When you created the host entry (koji add-host ...), an associated user was > created with the same name. This is the user that kojid should authenticate > as. > > And just to clarify, the users I'm talking about are the ones internal to > koji, not the system users. Thanks. However, how can I associate the kojid user with a build host? Does it mean that I have to configure a DNS to make all this names associate together? Or is there something that I need to configure which I may not have done? At the beginning of wiki " https://fedoraproject.org/wiki/Koji/ServerHowToProposed", it is mentioned that - " > Builders > By default these will be referred to as *kojibuilderX*, but can also > be the hostname(s) of the boxes that will be setup as builders. TODO: can > also or should ? > " I think this may be why I can't make it correctly. What I'm confused now is what the mentioned "hostname(s)".

3 4

Re: problems of running koji on CentOS with EPEL packages
by Chen Baozi 10 Feb '09

10 Feb '09

Thanks, I think there may be something wrong configuring the "host", because when I tried the command "/usr/sbin/kojid -f" to see what happened, it showed information such as below: Traceback (most recent call last): File "/usr/sbin/kojid", line 2732, in ? main() File "/usr/sbin/kojid", line 68, in main tm = TaskManager() File "/usr/sbin/kojid", line 532, in __init__ self.host_id = session.host.getID() File "/usr/lib/python2.4/site-packages/koji/__init__.py" line 1133, in __call__ return self.__func(self.__name, args, opts) File "/usr/lib/python2.4/site-packages/koji/__init__.py" line 1380, in _callMethod raise err koji.AuthError: No host specified So I'm wondering whether I've made mistakes during configuring "some host". However, I'm really confused about which host it referred. Does it mean the kojihub server? If so, what should I do? I'm now playiing with the whole koji environment at one machine just to see how it works, and plan to run it on several machines to do the real jobs. I guess there must be something wrong with the URL configuration of mine. But I don't know where.

2 1

Mock patch to use hosts timezone info in the chroot (try 3)
by Jesse Keating 05 Feb '09

05 Feb '09

GRRR. git format-patch and /then/ git send-email. *sigh* Here is a third attempt at sending the patch. -- Jes

1 1

Mock patch to use hosts timezone info in the chroot (try 2)
by Jesse Keating 05 Feb '09

05 Feb '09

Another try at this. I noticed I used the wrong variable and could have wound up removing /etc/resolv.conf by accident. -- Jes

1 1

Mock patch to use hosts timezone info in the chroot
by Jesse Keating 05 Feb '09

05 Feb '09

This patch copies the host /etc/localtime into the chroot. This allows the chroot to have the same timezone info as the host, which plays into timestamps and such. -- Jes

1 1

problems of running koji on CentOS with EPEL packages
by Chen Baozi 05 Feb '09

05 Feb '09

Hello, I was trying to distribute koji with the rpms from EPEL on CentOS following the instructions of "ServerHowTo". It seems I've made some mistakes that it's said "kojid dead but subsys locked" while I was checking kojid status after having it started successfully. BTW, I was a little confused about how to run a koji environment with the "ServerHowTo" wiki, due to the relationship of those configurations. Chen Baozi

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys February 2009