buildsys September 2008

buildsys@lists.fedoraproject.org

18 participants
20 discussions

Supporting EPEL Builds in Koji
by Mike Bonnet 05 Jan '09

05 Jan '09

Hi. I've written up a proposal for a way to support EPEL builds in Koji. It's not the only way we could do this, but I think it's doable with a reasonable amount of effort, and has the side-effect of greatly simplifying the Koji setup process for a lot of people (by removing the need to bootstrap/import an entire distro of packages into your private Koji instance). You can view the proposal here: http://fedoraproject.org/wiki/Koji/EPELSupport It's fairly detailed regarding the data model changes necessary, so if you're not familiar with the Koji codebase you can skip those parts. Questions and comments welcome. Thanks, Mike

6 13

Yum Static Repos
by Brian Schubert 23 Oct '08

23 Oct '08

Hello, Is kojira capable of creating static repos such as those at http://koji.fedoraproject.org/static-repos/ or is this achieved through some other means? Either way, would anyone be able to instruct me as to how it's done? Thanks, Brian Schubert Open System Solutions Rutgers University

4 5

[PATCH] Makefile.common autodetermine RPM_BUILD_DIR from spec file
by Petr Lautrbach 30 Sep '08

30 Sep '08

Hello. make patch and make rediff don't work if %setup macro defines with -n other directory than $(NAME)-$(VERSION). Petr

1 1

Fwd: Broken dependencies: perl-Test-AutoBuild
by Jens-Ulrik Petersen 23 Sep '08

23 Sep '08

Hi, Any ideas or thoughts on how to get rid of these new daily warning mails? (Unfortunately porting ghc to ppc64 is a non-trivial amount of work and not going to happen any time soon unless someone kindly volunteers to work on it.) Is there a white list or something this can be added to? Thanks, Jens

3 5

Re: [Server-devel] Revisor / yum oddity: anaconda-runtime
by Jeroen van Meeuwen 20 Sep '08

20 Sep '08

Jerry Vonau wrote: > Martin Langhoff wrote: >> On Fri, Sep 19, 2008 at 10:23 PM, Jeroen van Meeuwen >> <kanarip(a)kanarip.com> wrote: >>> Hence the log-file is of interest to me ;-) >> >> Sent it in a private email :-) >> >>> Yes, anaconda-runtime needs to exist in the repositories you use. >> >> Sorry - I should have clarified - anaconda-runtime *is* in the repos >> configured. (otherwise, adding it to the ks wouldn't help anyway!) >> > > "runtime" won't be in the repo that you're "spinning", and that is the > one that buildinstall is going to use: > > if [[ "$REPO" =~ ^/ ]]; then > [ -n "$OUTPUT" ] || OUTPUT=$REPO > REPO="file://$REPO" > > and from the log OUTPUT is set to: > /var/tmp/revisor-pungi/0.5/xs-f9-i386/i386/os > > That is the repo that getting spun right? > That is the composed tree, yes. From the log files though, you can see that more then one repository is used during buildinstall: Running Command: /usr/lib/revisor/scripts/F9-buildinstall --debug \ --product OLPC School Server --variant xs-f9-i386 --version 0.5 \ --release OLPC School Server 0.5 \ /var/tmp/revisor-pungi/0.5/xs-f9-i386/i386/os \ file:///xsrepos/testing/olpc/7/i386/ \ file:///media/disk/xs/releases/9/Everything/i386/os/ \ http://fedora.laptop.org/xs/testing/olpc/9/i386/ All of these should be searched for the anaconda-runtime package... I'm trying to figure out why it isn't so. Kind regards, Jeroen van Meeuwen -kanarip

1 0

Re: [Server-devel] Revisor / yum oddity: anaconda-runtime
by Martin Langhoff 19 Sep '08

19 Sep '08

On Fri, Sep 19, 2008 at 3:16 AM, Jerry Vonau <jvonau(a)shaw.ca> wrote: > Yea, revisor needs anaconda-runtime, > cat /usr/lib/revisor/scripts/F9-buildinstall | grep anaconda Yes, but from what Jeroen has said, revisor will pull it in to satisfy the need at CD build time, without it being listed in the ks file (and therefore getting installed on the target system too...) > Anaconda-runtime needs to exist in the repo that you use for the compose, > but doesn't need to be in the kickstart file. Too bad, you have to add > anaconda-runtime to the kickstart file, to get the package into the compose > repo, in order to use it later in buildinstall. Well, that's supposed to be true for pungi, not true for revisor. As far as I understand anyway :-) Jeroen has asked for logs and I'm collecting some right now... cheers, m -- martin.langhoff(a)gmail.com martin(a)laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff

2 2

A couple of questions about pungi
by Brian Edginton 18 Sep '08

18 Sep '08

I hope this is the correct list, please correct me if there is a better one. I have two issues with pungi on F9 (x86_64) that I haven't been able to find the answer for. 1) With the advent of using a kickstart and/or command lines I cannot find a way to set iso_basename which defaults to "Fedora" 2) I cannot see a way of building an iso with only x86_64 and noarch rpms, I always seem to get the i386 rpms included. Can I do this with pungi alone and not have to massage the build before I make the iso? Thanks in advance, -edge

3 5

Revisor / yum oddity: anaconda-runtime
by Martin Langhoff 18 Sep '08

18 Sep '08

On Fedora 9, using F9's revisor which has not changed in a while... - last week, I was able to invoke revisor and create a new installer CD without any problem... - this week, buildinstall dies, and if I enable logging it complains missing anaconda-runtime - this is looking at a local copy of the 'release' repo - I rsync'd it earlier today, but IIRC it had not changed... - my custom packages have changed a little bit, but none of them required anaconda-runtime - I have been experimenting with a different version of revisor - I've nuked /var/tmp/revisor* - perhaps state got saved anywhere else? Adding anaconda-runtime to the kickstart file that drives the process fixes the problem. It's not a problem I was expecting to have though :-/ In any case, am I missing any factor that could be messing up the process? cheers, m -- martin.langhoff(a)gmail.com martin(a)laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff

2 1

yum exitcode changes in 3.2.19-3.fc9 break some mock builds
by Paul Howarth 16 Sep '08

16 Sep '08

Today I tried building (in mock on a Fedora 9 host) some nmap packages for CentOS3 as version 4.76 came out. The mock build crashed out at the setup stage, due to the %pre script for the "dev" package failing (it thinks devfs is mounted). As I had built packages for version 4.75 only a couple of days ago, I tried rebuilding that and it now failed in the same way. I'd installed a bunch of updates in the last couple of days but the only one I could think of that might have caused that was the yum upgrade. So I downgraded yum from 3.2.19-3.fc9 to 3.2.17-2.fc9 and tried the build again, and this time it worked. The salient difference in the root.log was this: DEBUG util.py:250: Cannot install the dev package: mounted devfs detected. +DEBUG util.py:250: -------------------------------------------------------------------------------- +DEBUG util.py:250: Total 1.5 GB/s | 14 MB 00:00 DEBUG util.py:250: error: %pre(dev-3.3.12.3-1.centos.0.x86_64) scriptlet failed, exit status 1 DEBUG util.py:250: error: install: %pre scriptlet failed (2), skipping dev-3.3.12.3-1.centos.0 DEBUG util.py:250: ls: @@ -233,8 +236,7 @@ DEBUG util.py:250: mkinitrd failed DEBUG util.py:250: Installed: libpcap.x86_64 14:0.7.2-7.E3.5 openssl-devel.x86_64 0:0.9.7a-33.24 pcre-devel.x86_64 0:3.9-10.4 pkgconfig.x86_64 1:0.14.0-5 zlib-devel.x86_64 0:1.1.4-10.EL3 DEBUG util.py:250: Dependency Installed: dev.x86_64 0:3.3.12.3-1.centos.0 kernel.x86_64 0:2.4.21-57.EL krb5-devel.x86_64 0:1.2.7-68 losetup.x86_64 0:2.11y-31.24 lvm.x86_64 0:1.0.8-14 mkinitrd.x86_64 0:3.5.13.6-1 -DEBUG util.py:311: Child returncode was: 0 -DEBUG backend.py:436: Copying packages to result dir +DEBUG util.py:311: Child returncode was: 1 DEBUG backend.py:484: umount -n /var/lib/mock/centos-3-x86_64/root/proc DEBUG util.py:272: Executing command: umount -n /var/lib/mock/centos-3-x86_64/root/proc DEBUG util.py:311: Child returncode was: 0 So the scriptlet failures that didn't formerly affect affect mock builds due to the zero exit code of yum are now causing build failures due to a "1" exit code. I'm not sure what the best approach to fixing this should be. It makes perfect sense to me for yum to return a non-zero exit code when there's a scriptlet failure yet in some cases this is a problem that doesn't affect the subsequent build. As I suspect that this is a problem that mainly affects legacy distribution versions, perhaps there could be a mock option that could be set in the config file to ignore the yum exit code? Paul.

3 4

What exactly is 'latest'
by Bryce 12 Sep '08

12 Sep '08

I've created a tag I've imported various packages including several kernels ovs-2.1/kernel-2.4.21-52.0.0.0.2.EL.src.rpm ovs-2.1/kernel-2.6.18-8.1.6.0.18.el5.src.rpm ovs-2.1/kernel-2.6.9-42.0.10.2.3.EL.src.rpm ovs-2.1/kernel-2.6.9-42.32.0.0.4.EL.src.rpm when I look at latest-by-tag I get kernel-2.6.9-42.32.0.0.4.EL instead of kernel-2.6.18-8.1.6.0.18.el5 So I'm wondering if the koji code is simply making a character by character comparison ie it's seeing 2.6.1 vs 2.6.9 (this is using koji-1.2.6) Whats my option here? block-pkg? Phil =--=

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys September 2008