buildsys July 2009

buildsys@lists.fedoraproject.org

11 participants
7 discussions

pungi recent bug
by Sergio Monteiro Basto 06 Aug '09

06 Aug '09

Hi, I am trying http://sergiomb.no-ip.org/pungi/confs/buildiso-f11.sh with pungi-2.0.16-1.fc11 don't obey to less like: -wormux-0.8.2-5.fc11.i586 I saw on changelog: 2.0.14-1 - Fix package excludes in kickstart files and try pungi-2.0.13 , and voilá it works again. I check duplicates with my script: http://sergiomb.no-ip.org/pungi/confs/checkduplicateds Thanks, -- Sérgio M. B.

4 14

Creating a custom distro with pungi
by Julian Aloofi 04 Aug '09

04 Aug '09

I'm currently trying to create a custom distro with pungi. More precisely, I've been using rpm -qa --qf="%{n}\n" to create a list of packages currently installed on my system, added the needed repos (rpmfusion-free, rpmfusion-free-updates and adobe-linux-i386) and built a kickstart file out of this. Now I have some questions, and it's pretty hard to find any documentation about that, so I thought I'd just ask on this list. 1.)How can I specify which packages should be installed by default? The packages in my kickstart file get added, but don't get installed by default. I figured out that it had something to do with some xml files, but what exactly do I have to do to, for example, install all packages from the kickstart file by default? I'm not so comfortable with anaconda and repo files, so please mention file locations if I have to edit some files. 2.)How can I replace fedora-logos, fedora-release and fedora-release-notes with generic-logos, generic-release and generic-release-notes? I tried to exclude them from repos in the kickstart file and excluding them from the package manifest, however it didn't work. Thanks in advance, Julian

2 1

Mock issue with ifarch BuildRequires
by Gianluca Sforna 23 Jul '09

23 Jul '09

I am trying to run the tests included in the BuildBot package during the RPM build, and one of the tests requires darcs, which is built in Fedora ExclusiveArch %{ix86} x86_64 ppc alpha. Now, I'm adding to buildbot's spec[1] file an ifarch like: %ifarch %{ix86} x86_64 ppc alpha # darcs ExclusiveArchs BuildRequires: darcs %endif but it seems darcs is never installed in the buildroot [2] am I just doing something stupid or there's a bug somewhere? [1] http://cvs.fedoraproject.org/viewvc/rpms/buildbot/devel/buildbot.spec?view=… [2] http://koji.fedoraproject.org/koji/getfile?taskID=1470380&name=root.log -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna

3 4

[patch] hardcode SPECFILE
by Jens-Ulrik Petersen 16 Jul '09

16 Jul '09

A few times I have run into SPECFILE=$(firstword $(wildcard *.spec)) grabbing a different spec file in a pkg cvs dir than intended when doing local testbuilds. While unlikely I think it would be embarrassing if one day such an alternate spec somehow ended up in koji (eg via cvs-import.sh), so I would like to propose that we hardcode SPECFILE based on package NAME for all new packages with the attached patch. Jens

1 0

mock gid
by Jitesh Shah 15 Jul '09

15 Jul '09

I see some code in mock that picks up the mockuser uid/gid from the host machine. why is it so? I ask because recently, we came across some issues while building in koji where the builds failed with this : DEBUG util.py:280: Executing command: ['/usr/sbin/groupadd', '-g', '499', 'mockbuild'] DEBUG util.py:256: groupadd: GID 499 is not unique DEBUG util.py:319: Child returncode was: 4 (http://arm.koji.fedoraproject.org/koji/getfile?taskID=45343&name=root.log) GID 499 is already taken (in this case, by avahi). What is a good way to workaround this problem? Regards, Jitesh (PS: I am not sure whether this is the right place to ask mock-related questions. Let me know if I need to redirect it to the mock community)

2 1

Re: crossbuilding rpms with koji
by Kedar Sovani 09 Jul '09

09 Jul '09

> -----Original Message----- > Date: Tue, 07 Jul 2009 18:03:10 -0400 > From: Mark Salter <msalter(a)redhat.com> > Subject: crossbuilding rpms with koji > To: fedora-buildsys-list(a)redhat.com > Message-ID: <1247004190.2512.14.camel(a)deneb.localdomain> > Content-Type: text/plain > > I have been doing some experimenting with crossbuilds of rpms > using > koji. I realize that fedora policy requires supported arches to > be > native built, but my focus is towards infrastructure to > crossbuild > rpms for embedded systems where the fedora distribution is not > well > suited. So as a first stab at this, I started working with the > F-10 > release packages with an armv5tel target. The reason for this > was > that the ongoing work with fedora arm secondary arch allowed me > to > focus on the crossbuild infrastructure without having to spend > a lot > of time working on arch-specific patches in the packages > themselves. > > Anyway, I ended up crossbuilding around 400 F-10 packages. > Enough to > build up a rootfs which boots to a familiar looking gnome > desktop on > an omap-based beagleboard. Of those 400 packages, about 20% > needed > some amount of patching to support crossbuilding. Most were > simple > things like specfile tweaks (i.e. "s/gcc/%{__cc}/") or simple > makefile > patches to get around hard-coded tool names. And a handful > needed more > complicated patches (almost entirely autoconf/automake > related). Great! I had a similar attempt to build cross rpms for ARM. And since I was cross-building I could built those against glibc as well as uClibc. Although my package set is much smaller (~50). I'll try to place the cross patches that I have somewhere, probably most of them are already in your setup. I didn't build these in koji though, but it would be cool to have them in there. > > Now that I've gotten to this point, I'd like to solicit some > comments > on the approach taken and get some guidance on how to beat the > kludgey > first cut into shape so that it can be acceptable upstream. The > infrastructure side consists of: > > * A yum plugin which allows yum to install non-native rpms > into the build roots. > > * A mock plugin to handle the crossbuilding details. > > * A koji patch to support the crossbuild extensions to mock > > * A cross-toolchain package > > * A cross-rpm-config package which provides configuration > for rpm in the mock chroot and configuration details for > the mock plugin. > IIUC you have pkgname.armv5tel.rpm? If so, how did you make rpm to build those? I had to modify /etc/rpm/platform to fool rpm in thinking it is building for armv5tel. Is there a cleaner way for doing this? ...snip... > > If anyone is interested and would like to take a look at the > code and > comment, I placed source rpms at: > > http://people.redhat.com/msalter/crossbuild/source/ > > For convenience, here is the koji patch: > > http://people.redhat.com/msalter/crossbuild/koji/koji.patch > > And the yum plugin: > > http://people.redhat.com/msalter/crossbuild/yum/cross.py > > And the mock plugin: > > http://people.redhat.com/msalter/crossbuild/mock/cross.py > > and just for fun, a pic of F-10 running on a beagleboard: > > http://people.redhat.com/msalter/beagle-gnome.jpg > > --Mark Kedar.

2 1

crossbuilding rpms with koji
by Mark Salter 07 Jul '09

07 Jul '09

I have been doing some experimenting with crossbuilds of rpms using koji. I realize that fedora policy requires supported arches to be native built, but my focus is towards infrastructure to crossbuild rpms for embedded systems where the fedora distribution is not well suited. So as a first stab at this, I started working with the F-10 release packages with an armv5tel target. The reason for this was that the ongoing work with fedora arm secondary arch allowed me to focus on the crossbuild infrastructure without having to spend a lot of time working on arch-specific patches in the packages themselves. Anyway, I ended up crossbuilding around 400 F-10 packages. Enough to build up a rootfs which boots to a familiar looking gnome desktop on an omap-based beagleboard. Of those 400 packages, about 20% needed some amount of patching to support crossbuilding. Most were simple things like specfile tweaks (i.e. "s/gcc/%{__cc}/") or simple makefile patches to get around hard-coded tool names. And a handful needed more complicated patches (almost entirely autoconf/automake related). Now that I've gotten to this point, I'd like to solicit some comments on the approach taken and get some guidance on how to beat the kludgey first cut into shape so that it can be acceptable upstream. The infrastructure side consists of: * A yum plugin which allows yum to install non-native rpms into the build roots. * A mock plugin to handle the crossbuilding details. * A koji patch to support the crossbuild extensions to mock * A cross-toolchain package * A cross-rpm-config package which provides configuration for rpm in the mock chroot and configuration details for the mock plugin. The koji build machines need the first three things. The kojihub only needs the patched koji. Native builds are not affected by any of the above. There are no changes to the koji db schema. Tweaking the schema may make some things cleaner, but I don't have a lot of db experience and I left it alone for the first cut at this. There is nothing special in the koji server/builder setup except that the patch adds an option to the kojid.conf which is used to indicate that a host can crossbuild for some target(s). This is something that should probably be done in the database. The mock config file is used to distinguish native build from cross builds. Mock commands work the same for crossbuilding as for native. For crossbuilding, the "chroot_setup_cmd" needs to install the cross toolchain and cross-rpm-config packages in addition to the usual 'build' group. The koji patch adds a 'build-cross-<arch>' group to the mock config to accomplish this. The cross toolchain uses a sysroot to provide standard headers and libraries for the crossbuild. Basically, there is the normal mock chroot populated just as it would be for native builds. The mock cross plugin supports a second 'root' which serves as the toolchain sysroot. That is, if we crossbuild package 'foo' which 'BuildRequires: a b c', the normal mock code depsolves for 'a', 'b', and 'c' using a native-arch repo and installs those in the mock chroot. The mock cross plugin will also depsolve for 'a', 'b', and 'c', except using a target-arch repo and install them into the toolchain sysroot. The cross plugin also sets up a .rpmmacros and .rpmrc file in the mock build homedir which overrides rpmbuild macros such as "%{__cc}" to reference the cross-toolchain. That's the overview, but its really more complicated than that. For instance, if a package buildrequires texinfo to make docs, we really don't want to waste time/space putting texinfo into the toolchain sysroot because the native one is the one we want. The cross-rpm-config package has configuration that tells mock not to bother with that package for the target sysroot. These are the sorts of devils in the details of crossbuilding rpms. If anyone is interested and would like to take a look at the code and comment, I placed source rpms at: http://people.redhat.com/msalter/crossbuild/source/ For convenience, here is the koji patch: http://people.redhat.com/msalter/crossbuild/koji/koji.patch And the yum plugin: http://people.redhat.com/msalter/crossbuild/yum/cross.py And the mock plugin: http://people.redhat.com/msalter/crossbuild/mock/cross.py and just for fun, a pic of F-10 running on a beagleboard: http://people.redhat.com/msalter/beagle-gnome.jpg --Mark

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

buildsys July 2009