Creating a custom distro with pungi
by Julian Aloofi
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
14 years, 7 months
[patch] hardcode SPECFILE
by Jens-Ulrik Petersen
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
14 years, 8 months
mock gid
by Jitesh Shah
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)
14 years, 8 months
Re: crossbuilding rpms with koji
by Kedar Sovani
> -----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.
14 years, 8 months
crossbuilding rpms with koji
by Mark Salter
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
14 years, 8 months