So, I drew the short straw and I get to help organize the hackfests. It
looks like we’ll have 5 rooms and probably lots of miscellaneous
We’ll call the rooms: ABCDE. If you have a hackfest you’d like to start
up, let me know, I’ll update the wiki and see about organizing the
What do folks think about 2 hackfest sessions per day one before lunch
(caffeinated) and one after lunch (fed and maybe more caffeinated).
So sessions in rooms can be:
1A, 1B, 1C, 1D, 1E
2A, 2B, 2C, 2D, 2E
on friday and sunday.
and then everything else that can’t get a room. I’m sure some hackfests
will take longer than one session and I’m sure sunday afternoon a lot of
people will be leaving to go home, but I’d like to fill things up as
much as possible. So email your ideas and plans.
Monodevelop 1.0 beta 3 is now out, however it relies on mono-addins.
I've built mono-addins locally and packaged it, however I am unable to
log into my ftp server at all-the-johnsons.co.uk for some reason.
Can anyone host it for a while so I can get it approved and entered into
rawhide? I just need ftp access.
Sie können mich aufreizen und wirklich heiß machen!
I have noticed that mock in Rawhide has been changed to drop the SUID helper,
instead consolehelper is used to run the entire mock as root. IMHO, this is a
* It now means you have to know the root password to run mock. Before, it was
possible to give out mock access and only that simply by making the user a
member of the mockbuild group. Now the only way to do that is to allow running
all of mock as root, which probably opens up several ways to get full root
access from there.
* It means mock has to be run interactively. What are the implications of this
on the builders? Will they have to install all of mock SUID root, or set up
consolehelper in a way which effectively does the same?
* It reduces security, as instead of a small helper doing only a few controlled
operations, you now run all of mock as root. Sure, it's Python, so buffer
overflows probably can't happen, but still, trigger any bug in mock with a
trojaned SRPM and you have root.
I need to rebuild sear with the latest eris package, but eris can't be
pushed to the updates repo yet because the current sear package depends
on the old package.
Can someone from releng put eris-1.3.13 temporarily in the build root so
that I can rebuild sear and push both the updated eris and sear at the
thanks for adding the nfs root-path by dhcp support to mkinitrd.
Unfortunately there are some limitations and problems which may occur. I'd like to discuss them with you and the devel list.
My original patch evaluated the kernel command line like the kernel does. (Documentation/nfsroot.txt)
Setting root=/dev/nfs caused the initrd to read the root-path option from the dhcp lease.
The way you did it was looking at the mount-options of the root-filesystem in /etc/fstab. If the "dhcp" mount option is there it will read the dhcp lease file in the initrd.
I like this way, but the problem we're having is the following.
Setting the mount option "dhcp" in /etc/fstab causes the network script to fail as "dhcp" isn't a supported mount option.
Remounting root filesystem in read-write mode: Unsupported nfs mount option: dhcp [FAILED]
And as a consequence /etc/mtab doesn't contain the mounted root filesystem. The reboot will then fail as it tries to shutdown the network interface on an NFS root filesystem!
One workaround is to create a separate fstab with "dhcp" mount option. Then we pass this fstab as an argument to mkinitrd like: mkinitrd --fstab=fstab ...
Another workaround would have been to pass the option by using --rootopts . This isn't possible because of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=356371
Does anyone on this list have a suggestion about how we can improve / solve this issue?
Luckily there is a workaround available.
Thanks for your comments.
Trying to add kernel-184.108.40.206-47.fc7 in bodhi, I get
"kernel-220.127.116.11-47.fc7 not tagged with dist-fc7-updates-candidate".
Sure enough, the history says:
Sun Dec 16 05:22:24 2007: Untagged kernel-18.104.22.168-47.fc7 from dist-fc7-updates-candidate
Yet I never made any kind of request. What would cause my package
to get untagged like that?
Over the next few hours we're going to have a rolling outage of the
Koji builders. This is necessary to install a new kernel on them to
resolve some build issues discovered after the refresh. First we will
disable the host to be rebooted and allow it to complete any active
jobs without taking on new ones. Then the host will be rebooted to the
new kernel and re-enabled for taking new jobs.
Users should expect some delay in build tasks, but no loss of jobs.
Fedora -- All my bits are free, are yours?
Fedora-devel-announce mailing list
I'm trying to build a new qgis package, but am having a wierd build error;
I'll include it below (the entire build log is not large)
== start build.log ==
ENTER doChroot(<mock.backend.Root object at
0x2aaab11fe590>, 'rpmbuild -bs --target
x86_64 --nodeps //builddir/build/SPECS/qgis.spec', '',
uidManager=<mock.uid.uidManager object at
0x2aaab11fe810>logger=<mock.trace_decorator.getLog object at
ENTER do('rpmbuild -bs --target
x86_64 --nodeps //builddir/build/SPECS/qgis.spec', '/var/lib/mock/dist-f9-build-95445-12142/root/',
0, True, 0, <mock.uid.uidManager object at 0x2aaab11fe810>, 421,
421, 'x86_64', logger=<mock.trace_decorator.getLog object at 0x2aaab11fe9d0>)
run cmd timeout(0): rpmbuild -bs --target
x86_64 --nodeps //builddir/build/SPECS/qgis.spec
warning: Could not canonicalize hostname: xenbuilder4.fedora.phx.redhat.com
Building target platforms: x86_64
Building for target x86_64
LEAVE do -->
LEAVE doChroot -->
== stop build.log ==