[05.05.2012 21:57:36] <Philantrop> !pl

[05.05.2012 21:57:37] [Notice] -zebrapig to #exherbo- 0 patches in queue:

Here’s the list of affected patches:

[28.04.2012 17:24:28] [Notice] -zebrapig- 13 matching patches in queue:
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/510003/ ::sydbox (submitted by worr 161 days and 17 hours ago): [PATCH] Fixed race condition in sydbox
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/579419/ ::kde (submitted by heirecka_ 17 days and 5 hours ago): [PATCH 1/2] Move stuff from qt-creator-scm to its exlib
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/582592/ ::arbor (submitted by SuperHeron 11 days and 20 hours ago): [PATCH] app-shells/bash-completion[=scm]: /etc/bash_completion.d is
[28.04.2012 17:24:28] [Notice] -zebrapig- http://paste.pocoo.org/raw/582875/ ::x11 (submitted by moben 11 days and 8 hours ago): [PATCH 1/2] mesa multilib: Use multiunpack exparam
[28.04.2012 17:24:30] [Notice] -zebrapig- http://paste.pocoo.org/raw/583000/ ::arbor (submitted by keruspe 11 days and 1 hour ago): [PATCH] llvm: allow gcc 4.7.0
[28.04.2012 17:24:32] [Notice] -zebrapig- http://paste.pocoo.org/raw/584582/ ::mawww (submitted by heirecka 8 days and 3 hours ago): [PATCH] Fix building of espeak
[28.04.2012 17:24:34] [Notice] -zebrapig- http://paste.pocoo.org/raw/585239/ ::arbor (submitted by SuperHeron 7 days and 4 minutes ago): [PATCH] dev-lang/python: Add .pc file into alternatives
[28.04.2012 17:24:36] [Notice] -zebrapig- http://paste.pocoo.org/raw/585373/ ::anderslm (submitted by Philantrop 6 days and 18 hours ago): [PATCH] dev-libs/dotconf: ::anderslm -> ::media
[28.04.2012 17:24:38] [Notice] -zebrapig- http://paste.pocoo.org/raw/586847/ ::kde (submitted by Apetrini 3 days and 13 hours ago): [PATCH] networkmanagement: bump to 0.9.0.1-r1, fix dep
[28.04.2012 17:24:40] [Notice] -zebrapig- http://paste.pocoo.org/raw/588002/ ::ingmar (submitted by nakamuray 1 day and 3 minutes ago): [PATCH 1/3] notmuch: version bump to 0.12
[28.04.2012 17:24:42] [Notice] -zebrapig- http://paste.pocoo.org/raw/588028/ ::arbor (submitted by keruspe 23 hours and 6 minutes ago): [PATCH 1/3] autoconf: bump to 2.69
[28.04.2012 17:24:44] [Notice] -zebrapig- http://paste.pocoo.org/raw/588037/ ::x11 (submitted by keruspe 22 hours and 47 minutes ago): [PATCH] xkeyboard-config-scm: fix build
[28.04.2012 17:24:46] [Notice] -zebrapig- http://paste.pocoo.org/raw/588130/ ::kde (submitted by heirecka_ 19 hours and 56 minutes ago): [PATCH] Version bump to akonadi-1.7.2

Read ALL of this, it’s important to everyone using systemd.

Up to systemd[=42] we installed boot-critical components to / and others to /usr. This split was causing issues with respect to tmpfiles, intrinsic dependencies and dependencies on stuff on /usr.

systemd[=43] finally removes this split and installs everything but udev and pam stuff to /usr.

This won’t matter much to you if you don’t have /usr split from / (it should not be split; cf. http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken).

Even if you don’t have /usr != /, you need to update all packages that install to /${LIBDIR}/systemd/system because that got moved, too, of course. I’ve rev-bumped all packages, that install their own custom systemd units but even after you’ve updated those, you’ll still have some in /${LIBDIR}/systemd/system. Find out which package they belong to (use cave owner) and re-install them.

Should you forget to do so, you might end up in systemd’s emergency mode. If that happens, don’t panic. Get your network connection up and continue updating/re-installing. You’ll live, I promise.

There might be orphaned systemd units left behind. Check those on your own and decide if you need to move them to /etc/systemd/system. If you do, don’t forget to systemctl disable and then enable them.

You’ll also have some broken symlinks in /etc/systemd/system pointing to /${LIBDIR}/systemd/system. To fix those, all you have to do is disable and re-enable the respective unit. Here’s how to do it quickly and easily:

for link in $(find -L /etc/systemd/system -type l); do
systemctl disable $(basename ${link});
systemctl enable $(basename ${link});
done

Final sanity checks:

1. Is /${LIBDIR/systemd gone? If so, carry on; if not, you missed a step. Go back and find out which one.

2. No broken symlinks in /etc/systemd/system anymore? (“find -L /etc/systemd/system -type l” doesn’t output anything) If so, carry on. Otherwise, you missed a step. Go back and find out which one.

If you do NOT have /usr separated from /, you’re done now and it should be safe to reboot if you so desire.

If you do have /usr separated from /, you’ll have to use an initramfs (preferrably created by dracut) for booting from systemd[=43] onwards.

The first step to using an initramfs is enabling CONFIG_BLK_DEV_INITRD in your kernel, recompiling and installing it. If you want to switch from a custom initramfs to dracut, don’t forget to empty CONFIG_INITRAMFS_SOURCE in your kernel configuration either if you have been using it before.

If you want to use dracut (sys-boot/dracut[>=14]), install it and add

add_dracutmodules+=”98usrmount”

to /etc/dracut.conf. If you have some weird configuration, you might need to add further dracut or kernel modules. In general, though, dracut is going to pick up everything you’ll need to boot.

Now run dracut to create your shiny new initramfs:

dracut -H <initramfs filename incl. path> <kernel version>

e. g.

dracut -H /boot/init-3.2.5.gz 3.2.5-00001-gf74dd96

-H (or –hostonly) tells dracut to build an initramfs for the machine it’s running on. Leaving it out should create a HUGE generic initramfs that should bascially be able to boot everything. In reality, leaving -H out usually builds something that doesn’t boot anything.

Next, update grub’s config so that it includes a root= parameter for the kernel command line and your new initramfs, e. g.:

(for grub-0.9x’s menu.lst)
title Exherbo Linux
root (hd0,1)
kernel /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv
initrd /init-3.2.5.gz

or

(for grub-1.9x’s grub.cfg)
menuentry “Exherbo Linux” {
set root=(hd0,1)
linux /kernel-3.2.5-00001-gf74dd96 root=/dev/primary/uselv
initrd /init-3.2.5.gz
}

Do NOT forget the root= parameter. It’s essential.

(Of course, you need to adjust paths and filenames to your setup but if I need to tell you that, you shouldn’t be using Exherbo in the first place.)

If you’re using a custom initramfs, you must make sure that you mount /usr as early as possible but definitely before systemd (/sbin/init) starts. If you’re rolling your own initramfs, you should know how to accomplish that.

After you’ve updated your grub configuration, systemd is updated and your kernel is ready, too, say a little prayer ;-) and reboot.

Best regards, Wulf

We’ve now merged all multilib branches into master (this will go down into history books as “The Great Merge”!).

Thus, we don’t have any separate branches in our official and dev repositories anymore and if you still have a multilib branch  in your repository, please merge it, too.

Now is a good time to write an updated multilib migration guide so, without further ado, here we go:

• Switch to the multibuild profile in arbor.conf (${location}/profiles/amd64/multilib)
• Ensure that CHOST is not set in bashrc, and note that CFLAGS will apply to all C targets. You can use MULTIBUILD_C_{32,64}_USER_C{,XX}FLAGS for individual C targets.
• Re-install/update sys-apps/skeleton-filesystem-layout
• Install sys-libs/glibc[bootstrap], note that this should pull in sys-devel/bootstrap-gcc, too. (This is going to take a long time.)
• Install sys-devel/gcc[-openmp] (This is potentially going to take a long time, especially if you have the java option set.)
• Install sys-libs/glibc[-bootstrap], you can let Paludis purge sys-devel/bootstrap-gcc while doing so.
• Adjust your options to include the C targets you want and re-install any packages accordingly. You might have to re-install lots of package dependencies to fulfill a newly selected target’s requirements. (I simply did a cave resolve -e world)

Best regards, Wulf

We’ve come a long way with Exherbo since we started:

Let’s look at an example:

From 2a11f609e8be4f61a545112f1fceda6f8c40bfeb Mon Sep 17 00:00:00 2001

From: Johannes Nixdorf <mixi@user-helfen-usern.de>

Date: Thu, 24 Mar 2011 16:26:59 +0100

Subject: [PATCH] revive agg in ::mixi

—

drizzt.graveyard | 7 ——-

1 files changed, 0 insertions(+), 7 deletions(-)

diff –git a/drizzt.graveyard b/drizzt.graveyard

index 98979b9..92ed79a 100644

— a/drizzt.graveyard

+++ b/drizzt.graveyard

@@ -287,10 +287,3 @@ www-servers/

homepage = http://nginx.net

removed-by = Wulf C. Krueger <philantrop@exherbo.org>

removed-from = drizzt

-x11-libs/

- agg/

- :0 2.5

- description = A High Quality Rendering Engine for C++

- homepage = http://antigrain.com/

- removed-by = Wulf C. Krueger <philantrop@exherbo.org>

- removed-from = drizzt

–

1.7.4.1

This patch was for ::graveyard. It simply removes a single entry for a package that found a new home since I removed it. Great!

Anyone with push access could have verified and pushed it with minimal effort and, yet, nobody did for about two days and I’m pretty sure it would still be rotting on zebrapig if I hadn’t done so today.

Unfortunately, it’s by far not the only example. At the time of writing, zebrapig keeps 16 patches. A week ago, it were over 30. Nobody gave a shit.

There are patches that have been on zebrapig for months now (Ruby comes to mind!) and help with them is rejected because some people have worked on them and instead of submitting improved patches, they keep them to themselves, effectively stopping anyone from doing anything. And hardly anyone gives a shit.

Now, why is that situation so bad:

1. Patches are submitted to improve Exherbo. You’re impeding improvement by ignoring them.
2. Patches are submitted by our contributors/non-core developers. If you ignore their patches, they will become frustrated and stop submitting patches but create their own repositories, duplicating our work and making things harder for all of us. Or they will just go away. The latter is the worst possible outcome for Exherbo as a whole because with hardly more than a handful of active core developers, we will fail if we drive contributors away.
3. You’re putting more workload on the even fewer people with push access that actually work on patches. This takes away from our time working on more interesting stuff and, at least in my case, really alienates people from Exherbo.

Effectively, I’m handling most of the contributed patches myself. Either by reviewing, discussing and pushing them myself or by asking people to work on them (and usually getting stupid answers…).

Another thing that annoys me greatly are the answers I’m getting from people I’m asking to review patches; here are some examples (in no particular order) and what I think about them (which is usually not what I say):

• "I prefer playing SC2." / "I’m watching Star Trek!" – Well, yes, fine but I’m sure you could really dedicate at least one or two hours per week to work on patches.

• "Exherbo is just something nice to play with. I don’t really want to really work on it or be professional about it." – (I really hate that one.) If you take up responsibility for something, even as a hobby or so, then live up to it or leave it be. Get used to behaving professionally now while you can afford it not to be. Once you get a job, people won’t be so forgiving.
• "I don’t really care about that package anymore." – Well, I don’t either but there’s a patch so other people obviously do care. If you really want to get rid of a package, mail the exherbo-dev mailinglist and tell people. If there’s no taker, use Dexter to bury the package if need be.
• "I prefer vodka over patches." – …
• "I’m working! Not a student anymore." / "I’m so tired!" – So am I. And I’m married, have three kids and two rabbits. I’m working hard myself so you have my sympathy but, really, are one or two hours per week too much to ask? I usually invest much more time myself.
• "I’ve been busy slacking for a year!" (or longer) – Then please make it official and resign as a core developer. At least I’m going to know whom not to ask and it’ll become more obvious we’re under-staffed.
• "I said I’d do it but now I can’t be arsed." – Great, you could at least have told me right from the start you’re not going to do anything. I could have acted accordingly then.

And sometimes, the very same people who just refused to even look at a patch will ask me to review their patches seconds later…

All of this is really annoying and it’s the most likely reason for me to quit working on Exherbo and switching all my machines to another Linux distribution at some point if we don’t find a solution.

• You have to run Linux kernel >=2.6.36-rc1. The new kernel is only needed at runtime, not for building systemd.
• Kernel options for systemd: In your kernel config, enable autofs4, devtmpfs and cgroups. Do not enable autofs3. Here’s what I’m using (I enable more kernel options than strictly necessary, though.):

CONFIG_DEVTMPFS=y (Strictly required!)

CONFIG_DEVTMPFS_MOUNT=y (unless you're using an initramfs that's mounting it for you, e. g. one created by Dracut)

# CONFIG_AUTOFS_FS is not set (Strictly required!)

CONFIG_AUTOFS4_FS=y (Strictly required!)

CONFIG_CGROUPS=y (Strictly required!)

# CONFIG_CGROUP_DEBUG is not set

CONFIG_CGROUP_NS=y

CONFIG_CGROUP_FREEZER=y

CONFIG_CGROUP_DEVICE=y

CONFIG_CGROUP_CPUACCT=y

# CONFIG_CGROUP_MEM_RES_CTLR is not set

CONFIG_CGROUP_SCHED=y

CONFIG_BLK_CGROUP=y

# CONFIG_DEBUG_BLK_CGROUP is not set

CONFIG_FANOTIFY=y (only used for readahead stuff which is not enabled by default.)

CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y (only used for readahead stuff which is not enabled by default.)

• Set the “systemd” option globally in /etc/paludis/options.conf: */* systemd
• Install systemd: cave resolve -x sys-apps/systemd (Read what cave tells you. If in doubt, read Paludis’ documentation.)
• Reinstall every package with the new option set: cave resolve world -cx
• Switch to systemd as your init system: eclectic init set systemd
• Set the desired hostname in /etc/hostname.
• Optional: Edit /etc/vconsole.conf to your liking.
• Optional: Edit /etc/machine-info to your liking.
• Read Lennart’s blog post about the other configuration files.
• Install a Linux kernel >=2.6.36-rc1. (see above for kernel options, etc.)
• Temporary measure: Set the pass field in /etc/fstab to 0 for your partitions, e. g. /dev/sda2 / ext4 noatime 0 0
• Reboot.

After that reboot, you’ll be in a console with a minimal set of services started, hopefully ready to log in. Log in as root (the keyboard layout is set to US by default!). Then you can enable whatever services (found in /lib/systemd/system) you like, suggested ones are:

• dhcpcd.service or NetworkManager.service
• sshd.socket (it doesn’t start? Missing host keys? man sshd or http://tinyurl.com/24jwxjd)

As an extremely simple and limited alternative to NetworkManager.service, there’s network.service and network.conf which get installed if you set the “simple-net” option for systemd. network.service only allows for static network setups with IPv4.

Alternatively, you can use dhcpcd.service.

If I were you, I’d not enable your display manager’s service (either kdm.service, gdm.service, xdm.service or slim.service) until your basic system has at least booted properly once and you can reach your system using ssh because in case things go wrong, it’s easier not to have to wrestle with a GUI.

To actually enable a service, run “systemctl enable <foo.service>”. More details can be found in systemd’s man page.

If you need help, it’s available in #exherbo, as usual, but if you didn’t read this before asking, grumpy me will bite your head off unless you prove you read this by mentioning “Homunculus“. :-)

FAQ section:

• “How/where do you specify extra modules to be loaded?” – You put the module name into /etc/modules-load.d/foo.conf and it will get loaded. Unless udev has already loaded it for you. Check that first.
• “My hostname is set to something funny, e. g. ’08′!” – If you’re using NetworkManager, you need to set your hostname in /etc/NetworkManager/NetworkManager.conf, too.
• “I’m getting messages about failing services, e. g. dev-hugepages.mount or sys-kernel-debug.automount. What’s up with that?” – You can either enable the corresponding kernel options, delete the symlink (e. g. /lib/systemd/system/basic.target.wants/sys-kernel-debug.automount) or just ignore those messages. They’re harmless.
• “When sshd.socket is enabled, every closed ssh connection leaves a failed service around, e. g. sshd@192…:55140.service.” – Harmless as well. There are no ressources used by those so ignore them. (This should be fixed anyway.)
• “Where can I learn more about the usual administration tasks? – Read Lennart’s series of blog posts about systemd for administrators: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8
• “How do I debug problems with systemd?” – Read this page http://fedoraproject.org/wiki/How_to_debug_Systemd_problems
• “I’m completely lost. What do I do?” – Please remember there’s always a friend around. It’s called “man”. ;-)

• You have to run at least Linux kernel 2.6.36-rc1 (I’m using 2.6.36-rc3; latest NVidia-Drivers work fine and there are patches for the VMWare modules available.).
• In your kernel config, enable autofs4, devtmpfs and cgroups.
• Do not set autofs3.

My own kernel options (with respect to systemd):

# CONFIG_AUTOFS_FS is not set

CONFIG_AUTOFS4_FS=y

CONFIG_DEVTMPFS=y

CONFIG_DEVTMPFS_MOUNT=y

CONFIG_CGROUPS=y

# CONFIG_CGROUP_DEBUG is not set

CONFIG_CGROUP_NS=y

CONFIG_CGROUP_FREEZER=y

CONFIG_CGROUP_DEVICE=y

CONFIG_CGROUP_CPUACCT=y

# CONFIG_CGROUP_MEM_RES_CTLR is not set

CONFIG_CGROUP_SCHED=y

CONFIG_BLK_CGROUP=y

# CONFIG_DEBUG_BLK_CGROUP is not set

CONFIG_FANOTIFY=y

CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y

What has been accomplished so far:

• The Exherbo patches are done. Do NOT try to submit them upstream yet, though. I’ll take care of that when the time is ripe.
• Lots of services are done.
• You can boot and run most systems using systemd now.
• I’ve built new amd64 and x86 stages without any init system so you can start out without the baselayout-1/sysvinit cruft.
• The installation guide has been updated.

Every systemd service is implemented natively and we’re not using anything from baselayout-1 or sysvinit anymore. Instead, all the important stuff has been moved to skeleton-filesystem-layout. systemd’s dependencies have been updated accordingly.

Thus, for people using systemd, baselayout-1 and sysvinit are now obsolete. YAY!

What still needs to be done:

• Improve existing service definitions for systemd.
• Create socket definitions for several of the existing service definitions. (And new ones, of course.)
• Create systemd service files for missing services.

Rules for new service files:

• Please make sure they’re implemented natively. I won’t accept non-native service files unless you can convince me there’s definitely no other solution.
• If you convinced me, scripts go to /usr/${LIBDIR}/systemd.
• EnvironmentFiles (configuration) go to /etc/conf.d and end in .conf. We do NOT create a configuration file for every single service but create (grep-able) logical units, e. g. now-obsolete font@.service and keymap@.service used to use console.conf).
• You can reference environment variables from configuration files in service. If you have to quote the values in the configuration file, you need to use $FOO; if you don’t quote them (preferred), you use ${FOO}. This is probably a bug (and known to upstream) but for now that’s how it is.
• Services and their (potentially) accompanying files must not collide with baselayout-1.

Requirements:

• You have to run Linux kernel >=2.6.36-rc1 (I’m using 2.6.36-rc6; latest NVidia-Drivers work fine and there are patches for the VMWare modules available.).

How to get started with systemd:

Read this.

Conclusion:

Since both systemd and its exheres have now reached an acceptable degree of stability, I don’t intend on breaking things anymore as I’ve done over the last months from time to time.

In fact, systemd is so usable these days, I’m writing this on a systemd-initialised system! This means as well that I can live without baselayout-1 and sysvinit. YAY! :-)

• warn you that I will break systemd (and consequently your boot process) until further notice recklessly, repeatedly and without prior warning to anyone
• make clear what I intend to do with systemd in Exherbo
• make a plan for myself.

What I want to do first is get a feeling for systemd and see if it might have the potential to replace baselayout-1 (bl-1) and, at least for myself, be used instead of the init-system-that-is-not-to-be. ;)

As I really want to replace bl-1, I’m not going to go the Gentoo way of simply adding a handful of pseudo-units that essentially just call the openrc init scripts. If you want that, you’re on your own and I won’t accept patches that do that. Instead, I’m aiming for:

• a full native set of systemd units not tainted by anything else
• a minimal set of non-native configuration files (what we currently have in /etc/conf.d; I don’t think it will be possible to avoid them completely but I will if I can)
• staying as near to upstream as possible and I’ll try to submit my patches upstream even though the DISTRO_PORTING instructions don’t exactly make inclusion seem likely
• the units included in the systemd package will at most get you to some kind of login (either graphical or console)
• all additional units for services like sshd should eventually be added to their respective packages, possibly using a “systemd” option.

The process to make systemd really usable in Exherbo will be a slow one. One that I expect to take till autumn this year because:

• I’m really busy at work,
• this summer seems to become a damn hot one again and I spend quite some time after work in our pool,
• I’ll be on holidays in France for most of July.

The steps I intend to take:

• finalise the Exherbo patches for systemd (90% done, ETA: Mid June)
• create and enhance a basic set of units for booting (5% done)
• create units for other services

How you can help:

• Remind me of the stuff I’ve forgotten due to a power outage here. :-)
• Make yourself acquainted with systemd units.
• Once I’ve pushed the Exherbo patches, test systemd and
• submit patches for the missing units. :-)
• Leave comments here or on the dev mailinglist so that I can consider your input, comments and concerns.