buildsys March 2006

buildsys@lists.fedoraproject.org

15 participants
9 discussions

Start a nNew thread

Extras build system back up
by Dan Williams 26 Oct '06

26 Oct '06

Hi, We're back up and using the latest plague code. yum update your plague-client and you should be good to go. Dan

3 7

mock buildroot definitions
by seth vidal 04 Apr '06

04 Apr '06

Hey, So it was brought up a while ago that due to the changing nature of the comps.xml format that we should not rely on it for the buildroot installations in mock. The idea a while back was to just have a 'buildroot' rpm that required all the stuff that would normally be in the comps.xml group. Then we could just install that rpm and it pulls in the rest of the buildroot components. What do folks think? Worth going through the process to do it? -sv

11 18

rfe: simple framework for post-build checks
by Bill Nottingham 23 Mar '06

23 Mar '06

The build system should have a framework where simple post-build checks can run. Simple design would be: - tests are collected in a package of scripts (or in CVS) - packagers can add extra ones for their packages - tests have access to: - the build logs - the name of the user who submitted the build - the owner of the package (if not the same) - the previous version of the package - the repodata for the repo being built for - tests have a defined return status, such as 0 - everythings OK. Carry on, sir! 1 - some information here 7 - someone should review this and approve before pushing the package 11 - the package is bad, please throw away These tests could then be: - e-mailed to the builder - e-mailed to the owner - posted on the web Doing this allows for simple, automated, QA; it can check that things that are caught in the package review for initial import are then caught later if they regress, and it can catch other things. Examples of tests: - test for files owned by the compile user - test for files with executable stack - look for specific compiler warnings in the build output, such as: ... will always overflow destination buffer ... ... warning: format argument XX unused before used argument XX ... *** buffer overflow detected *** ... warning: ignoring return value of 'realloc' ... - check for introduced multilib conflicts - check the scriplets for: - correct use of chkconfig - correct use of useradd or equivalents - excess complication (warning: package %post is 150 lines) - using the repo data: - check the package for broken deps - check the repository for induced breakage - using previous version of the same package: - check for added/removed files - check for added/removed/changed dependencies - check for introduction of new setuid files - check that symbols changed in libraries without changing soname - heck, just run the package through rpmlint and mail it out (or check it against a known list of exceptions for the package) I'm sure people could come up with a lot more. By making it a simple framework, it allows for easier contribution. Bill

2 1

/dev/std* missing in mock
by Toshio Kuratomi 21 Mar '06

21 Mar '06

Hi all, Seth is a bit tapped for time right now, could someone with mock checkin rights take a look at this bug? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179852 The current understanding in the bug report is that the buildsystem should have /dev/std{in,out,err} added. -Toshio

3 2

Fw: [Bug 179852] /dev/std* missing in mock - FE buildsystem
by Michael Schwendt 21 Mar '06

21 Mar '06

Begin forwarded message: Date: Tue, 21 Mar 2006 13:04:20 -0500 From: bugzilla(a)redhat.com To: bugs.michael(a)gmx.net Subject: [Bug 179852] /dev/std* missing in mock - FE buildsystem Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: /dev/std* missing in mock - FE buildsystem https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179852 ------- Additional Comments From bugs.michael(a)gmx.net 2006-03-21 13:04 EST ------- I'm not subscribed to that list, and Cc from within bugzilla doesn't work, please don't create additional hurdles inside the Fedora Project. I call upon the FE buildsys maintainers to please process this bugzilla ticket. wine-docs package for FC-4 continues to fail in the FE buildsys with an strace pointing to missing /dev/std{in,out,err} device links in the mock chroot: [pid 27154] open("/dev/stdin", O_RDONLY|O_NOCTTY|O_LARGEFILE) = -1 ENOENT (No su ch file or directory) [pid 27154] write(2, "ELinks: ", 8ELinks: ) = 8 [pid 27154] write(2, "No such file or directory", 25No such file or directory) = 25 It has not been examined why elinks searches for these devices or why it doesn't appear to do the same for FC-3 and FC-5. Anyway, wine-docs for FC-4 can't be built due to this issue with the build system. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. You are on the CC list for the bug, or are watching someone who is.

1 0

OT: using mock to build for SLES
by Matt Domsch 14 Mar '06

14 Mar '06

I've been looking at using mock to build srpms for Novell/SuSE SLES product, rather than using their build.rpm script. With one little change to mock (below), seems to work pretty well. opensuse-10.x is still a little weird, but SLES9 x86 and x86_64 seem to be building fine. Here's the mock patch to pass -m to useradd, and I'll follow up with the buildroots.xml and mock cfg file example too. Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com --- mock.orig 2006-03-05 20:58:49.000000000 -0600 +++ mock 2006-03-06 08:30:51.000000000 -0600 @@ -556,8 +556,8 @@ if not os.path.exists(self.rootdir + self.homedir): if not os.path.exists(os.path.join(self.rootdir, 'usr/sbin/useradd')): raise RootError, "Could not find useradd in chroot, maybe the install failed?" - cmd = '/usr/sbin/useradd -u %s -d %s %s' % (self.config['chrootuid'], - self.homedir, self.config['chrootuser']) + cmd = '/usr/sbin/useradd -m -u %s -d %s %s' % (self.config['chrootuid'], + self.homedir, self.config['chrootuser']) self.do_chroot(cmd, fatal = True) def _build_dir_setup(self): @@ -571,9 +571,9 @@ for subdir in ('RPMS', 'SRPMS', 'SOURCES', 'SPECS', 'BUILD', 'originals'): cmd = "mkdir -p %s/%s" % (self.builddir, subdir) self.do_chroot(cmd, fatal = True) - cmd = "chown %s.%s %s/%s" % (self.config['chrootuser'], - self.config['chrootgroup'], self.builddir, subdir) - self.do_chroot(cmd, fatal = True) + cmd = "chown -R %s.%s %s" % (self.config['chrootuser'], + self.config['chrootgroup'], self.builddir) + self.do_chroot(cmd, fatal = True) # rpmmacros default macrofile_out = '%s%s/.rpmmacros' % (self.rootdir, self.homedir)

2 5

having a weird issue building emacs w/ plague
by Jesse Keating 12 Mar '06

12 Mar '06

So we've got a plague+mock setup for Legacy, and I"m trying to build a new FC1 emacs. Here is the fun thing, when using plague-client and passing it a srpm to build, I get this error: creating src/Makefile + setarch i386 make i386: Success error: Bad exit status from /var/tmp/rpm-tmp.65918 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.65918 (%build) Not very helpful. So I go to hand build it w/ mock so that I can see where it is actually failing and fix it, but mock itself builds just fine. mock -r fedora-1-i386-core emacs.src.rpm completes w/out blinking. We've been able to reproduce it many times on our build system, and even other plague+mock setups. I'm really at a loss as to how plague can get it wrong w/ mock gets it right. Help? When it finishes uploading, you can find the package in question at http://geek.j2solutions.net/emacs-21.3-9.legacy.src.rpm Note, all Legacy did beyond the stock FC package was add patch16, add autoconf213 as a BuildReq, and added the changelog. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)

1 2

[ANN] plague-client++ (with proxy support)
by Enrico Scholz 06 Mar '06

06 Mar '06

Hello, this program is lingering around on my harddisk for some while already and I found now time for some cleanups to announce it officially. 'plague-client++' is an alternative plague-client implementation which uses a professional HTTP transport library (curl) instead of botching around with python's urllib resp. with direct sockets. So, 'plague-client++' works behind HTTP proxies. Currently, it was written completely for my purposes so it has the following cons: * no configuration files; it uses the default paths and urls for the certificates; when you need to change them, you have to edit src/PlagueOptions.cc * no support for src.rpm or local plague operations A snapshot is available at http://ensc.de/fedora/ or you can checkout it from the GNU Arch/Bazaar repository: tla register-archive ensc(a)ensc.de--fedora http://ensc.de/tla/{archives}/fedora baz get ensc(a)ensc.de--fedora/plague-clientxx--mainline--0.1 Enrico

1 0

Add a chroot command to mock?
by Clark Williams 02 Mar '06

02 Mar '06

When cross-building a root filesystem, you need to bootstrap something we call a "sysroot", which is essentially a software development environment for the target system (headers and libraries mostly). The way we do that is we create an empty "root" and as we build RPMS (starting with GLIBC), we install the -devel packages into that target root (the sysroot). Our cross toolchains know how to access the sysroot, so when you compile hello.c, it gets the correct headers and libraries. To be able to install rpms into the sysroot (which lives in the mock chroot) I've added a chroot command to my local copy of mock (patch below). Anyone object to committing this? Clark Index: mock.py =================================================================== RCS file: /cvs/fedora/mock/mock.py,v retrieving revision 1.36 diff -u -r1.36 mock.py --- mock.py 24 Feb 2006 19:31:57 -0000 1.36 +++ mock.py 2 Mar 2006 15:48:01 -0000 @@ -781,6 +781,12 @@ my.close() print 'Finished initializing root' + elif args[0] == 'chroot': + config_opts['clean'] = False + my= Root(config_opts) + my.do_chroot(' '.join(args[1:]), True) + print 'Finished chroot command' + else: if args[0] == 'rebuild': if len(args) > 1: -- Clark Williams <williams(a)redhat.com>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys March 2006