Supporting EPEL Builds in Koji
by Mike Bonnet
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
14 years, 11 months
Yum Static Repos
by Brian Schubert
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
15 years, 1 month
Fwd: Broken dependencies: perl-Test-AutoBuild
by Jens-Ulrik Petersen
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
15 years, 2 months
Re: [Server-devel] Revisor / yum oddity: anaconda-runtime
by Jeroen van Meeuwen
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
15 years, 2 months
Re: [Server-devel] Revisor / yum oddity: anaconda-runtime
by Martin Langhoff
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
15 years, 2 months
A couple of questions about pungi
by Brian Edginton
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
15 years, 2 months
Revisor / yum oddity: anaconda-runtime
by Martin Langhoff
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
15 years, 2 months
yum exitcode changes in 3.2.19-3.fc9 break some mock builds
by Paul Howarth
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.
15 years, 2 months
What exactly is 'latest'
by Bryce
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
=--=
15 years, 2 months
