Extras build system back up
by Dan Williams
Hi,
We're back up and using the latest plague code. yum update your
plague-client and you should be good to go.
Dan
16 years, 7 months
mock buildroot definitions
by seth vidal
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
17 years, 2 months
rfe: simple framework for post-build checks
by Bill Nottingham
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
17 years, 2 months
Fw: [Bug 179852] /dev/std* missing in mock - FE buildsystem
by Michael Schwendt
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.
17 years, 2 months
OT: using mock to build for SLES
by Matt Domsch
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)
17 years, 3 months
having a weird issue building emacs w/ plague
by Jesse Keating
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)
17 years, 3 months
[ANN] plague-client++ (with proxy support)
by Enrico Scholz
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
17 years, 3 months
Add a chroot command to mock?
by Clark Williams
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>
17 years, 3 months