some of you may have read some wiki pages about the plans for the new init system . As a first step in
this direction , I packaged prcsys from Mandriva, patched initscripts with a very small patch, and uploaded
the src.rpm to . To enable parallel booting just build and install both packages and edit
/etc/sysconfig/init. Set PARALLEL_STARTUP=yes and there we go.
The next step would be to modify all initscripts in /etc/init.d to be LSB compliant . This will speed up
booting, because they can and will be started in parallel. You should file bugzillas against the component, to
which this initscript belongs, with a patch (this has to be done anyway to be LSB compliant in regards to
initscripts over time). Especially the exit codes need to be fixed (which will make status queries a lot
easier and more robust).
Early login  is also a next step towards a "fast boot" user experience.
Alternatives to SysVInit (like upstart/initng) can live in Fedora as well, but we are very conservative in
changing the startup mechanism that proved to function for a long time now. Unless the "real" killer feature
is absolutly needed, we would like to keep backwards compatibility as long as possible.
I hope many of you try and test  and write patches to improve our service initscripts to be LSB compliant
:-) Parallel booting is the reward.
Currently mock configs make use of a 'groups' repo to provide
a 'buildsys-build' meta-package. This meta-package has a set of Requires:
that are used to create the 'minimal buildroot' mock uses to start builds.
This repo also provides a 'buildsys-macros' package. Historically this
package would define things like the %dist tag and post-build actions.
Today, in rawhide, fedora-release provides the %dist like macro definitions.
The post-build definition can be moved to redhat-rpm-config as well. This
would obviate the need for buildsys-macros. That would just leave the
meta-package to populate the buildroot.
Since mock supports installing a group rather than a (meta)package, I propose
we define the buildsys-build group in the comps group directly. This would
obviate the need for a single point of failure within mock building,
the 'groups' repo.
Here is the change I would make to comps:
diff -u -r1.28 comps-f8.xml.in
--- comps-f8.xml.in 27 Jun 2007 20:47:51 -0000 1.28
+++ comps-f8.xml.in 28 Jun 2007 17:27:19 -0000
@@ -486,6 +486,33 @@
+ <_name>Buildsystem building group</_name>
+ <packagereq type="mandatory">bash</packagereq>
+ <packagereq type="mandatory">bzip2</packagereq>
+ <packagereq type="mandatory">coreutils</packagereq>
+ <packagereq type="mandatory">cpio</packagereq>
+ <packagereq type="mandatory">diffutils</packagereq>
+ <packagereq type="mandatory">fedora-release</packagereq>
+ <packagereq type="mandatory">gcc</packagereq>
+ <packagereq type="mandatory">gcc-c++</packagereq>
+ <packagereq type="mandatory">gzip</packagereq>
+ <packagereq type="mandatory">make</packagereq>
+ <packagereq type="mandatory">patch</packagereq>
+ <packagereq type="mandatory">perl</packagereq>
+ <packagereq type="mandatory">redhat-rpm-config</packagereq>
+ <packagereq type="mandatory">rpm-build</packagereq>
+ <packagereq type="mandatory">sed</packagereq>
+ <packagereq type="mandatory">tar</packagereq>
+ <packagereq type="mandatory">unzip</packagereq>
+ <packagereq type="mandatory">which</packagereq>
The comps change can be made at any time, however changes to mock need to be
coordinated with the maintainer for redhat-rpm-config. I'd also like to
move /usr/lib/rpm/check-buildroot out of rpmdevtools and into one of the
packages already being pulled into the buildroot (redhat-rpm-config perhaps,
since it will be referencing it?), and thus we'll need to coordinate with the
We wouldn't be doing away with mock's ability to just use a meta-package to
populate the root, so those that want to alter what goes into the buildroot
can (just like before) build your own buildsys-build package and host it for
your mock, or define your own comps grouping, etc...
Release Engineer: Fedora
I'm trying to rpmbuild "ivi". However, the "ant" fails with
/ivi-1.0.2_1-src/configure.xml:40: plugin version 320v20060603 is
badly formatted: java.lang.NumberFormatException: invalid character at
position 4 in 320v20060603
Is that ok with the "v" in the version of
Any plans to incorporate into rawhide?
On Tap: HopZilla and a Belgian Tripel
Fermentating: Imperial English Pale Ale
Fermentating: Guinness Extra Extra Imperial Stout
Fermentating: Belgian Tripel Dry
Next: Brutal Blackend Bitter
I'm working on updating libgda + libgnomedb to 3.0.x for F-8 / future rawhide
(more on that later) and yesterday evening before going to bed I queued a build
of libgda-3.0.1, which completed successfully. This morning I build
libgnomedb-3.0.0, which correctly got its buildroot populated with the fresh
libgda-3.0.0 . So next I tried to build gnumeric against the new libgda +
libgnomedb, but populating the root failed with:
Executing /usr/sbin/mock-helper yum --installroot
/var/lib/mock/dist-f8-build-5517-1020/root resolvedep 'intltool' 'pygtk2-devel
>= 2.6.0' 'libgnomeprintui22-devel >= 2.8.2' 'libgnomedb-devel >= 3.0.0'
'python-devel' 'scrollkeeper' 'gettext' 'automake' 'desktop-file-utils >= 0.9'
'libgnomeui-devel >= 2.4.0' 'libgsf-gnome-devel >= 1.13.2' 'goffice-devel >=
0.2.0' 'libtool' 'autoconf' 'guile-devel'
Notice how it says its going to include libgnomedb-devel-1.9.100, not 3.0.0
Error: Missing Dependency: libgda-3.so.3()(64bit) is needed by package libgnomedb
Which figures, as that is the old 1.9.100 libgda .so
For the full log see:
So why is koji finding the new libgda, but not the new libgnomedb, is some
kinda sync script running for this at regular intervals, or ... ?
On Monday, perl-devel will be removed from the f8 buildroots. This
means that if you try to build a perl-* package that uses the perl build
tools, you will need to add those tools to the BuildRequires for the
package. The most common will be:
But you should also watch the build output to make sure tests aren't
being skipped due to other missing modules.
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching
A day or so ago, I flipped the switch and killed off the 586 specific
kernel, by making the 686 kernel bootable on older machines.
Turns out it isn't that easy however.
Rpm will refuse to install the 686 kernel a 586, because it checks
sudo rpm -ivh kernel-2.6.21-1.3228.fc8.i686.rpm
Preparing... ########################################### [100%]
package kernel-2.6.21-1.3228.fc8 is intended for a i686 architecture
(Oddly, the 586 kernel uname is reporting itself as 686 already,
which I don't quite understand..
Linux equinox 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:11:19 EDT 2007 i686 i686 i386 GNU/Linux)
Anyway.. To 'solve' this, I think I'm going to have to make the 686
kernel package an 'i386' package.
Does anyone see anything flawed with this approach?
(Modulo problems with yum doing exactarch matches and upgrades being
more of a nightmare than usual).