Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/01/2019 05:06 PM, Eli Schwartz via arch-general wrote: > Our dracut packager tried to get in touch with the dracut developer, > after a lack of success for quite some time it seems that the individual > in question was on... parental leave, IIRC? I'm not sure what the > current status is. Now that does not bode well as something to build your setup around. I have dracut working fine on openSUSE, so I know it will work, but I sure haven't had any problems with the current way Arch does it. Unless there is a reliable (and responsive) upstream, I don't see the benefit (or wisdom) of patching a project that is somewhat "on-hold" just to say we have dracut and moving to it. SuSE has a lot of resources to direct toward the issue. Personally I've always found the Arch KISS philosophy the better approach. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 11:27 PM, Giancarlo Razzolini wrote: > > > xz is much slower than gzip, and the kernel does not support zstd. > Right - facebook brought it up again a few months ago, thread went quiet and I incorrectly assumed it was actually mainlined - but you're right it isn't. https://lkml.org/lkml/2019/6/10/725 Thanks!
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
Em novembro 4, 2019 0:59 Genes Lists via arch-general escreveu: Yeh, that makes sense - plus its very easy to add to dracut.conf Yes. dracut supports /etc/dracut.d, so there's where they recommend to put settings. Been thinking about that - I've switched to building without -H and not creating a fallback image - I've also switched to signing all modules (in and out of tree). Not sure what value a fallback image actualy provides at this point? It takes more space and I don't see it adding much value. While I agree that they might not be needed that much, it's a good thing to have, even if you don't use it. I can ship with it enabled and then users can remove it. I that that we would be better with compression being put in dracut.conf. Be more flexible that way than the command line which I assume overides dracut.conf - so a lot less flexible. Yes, that's the idea. Also, is it time to switch from gzip to xz or even to zstd yet? xz is much slower than gzip, and the kernel does not support zstd. Regards, Giancarlo Razzolini pgprFrL3Qs2Yd.pgp Description: PGP signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 11:16 PM, Genes Lists via arch-general wrote: > > gene > Clearly image size and compression both likely impact boot time. An interesting comparison might be running systemd-analyze blame after booting with and with hostonly and with and without compression. Anyone have a comparison handy?
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 10:59 PM, Genes Lists via arch-general wrote: > > Not sure what value a fallback image actualy provides at this point? > It takes more space and I don't see it adding much value. > Didn't think enough - the host only image might well be faster to boot (being smaller) - but I have not benchmarked the benefit. Be curious how much faster booting with the host-only image would be. Anything else I've missed for having this? gene
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 7:31 PM, Giancarlo Razzolini wrote: > That would require having dracut depend on mdadm. I think this is something > to be done by the user. I plan a simple config/preset per kernel that > will be Yeh, that makes sense - plus its very easy to add to dracut.conf > called twice, once with -H and once without, to create the > regular/fallback images. Been thinking about that - I've switched to building without -H and not creating a fallback image - I've also switched to signing all modules (in and out of tree). Not sure what value a fallback image actualy provides at this point? It takes more space and I don't see it adding much value. > > Also, I've found out that, for some reason, dracut defaults to creating > non-compressed > images when nothing is passed, so I'll probably add arguments to make > sure they are compressed. Good catch - i missed that. I that that we would be better with compression being put in dracut.conf. Be more flexible that way than the command line which I assume overides dracut.conf - so a lot less flexible. Also, is it time to switch from gzip to xz or even to zstd yet? gene > > Regards, > Giancarlo Razzolini
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
Em novembro 3, 2019 21:05 Genes Lists via arch-general escreveu: Thank you ... I really like dracut - it works well. Only suggestion I'd make is adding "--mdadmconf" perhaps by default - though I can see it both ways for those who don't use RAID - if its easy to add that would also be totally fine. That would require having dracut depend on mdadm. I think this is something to be done by the user. I plan a simple config/preset per kernel that will be called twice, once with -H and once without, to create the regular/fallback images. Also, I've found out that, for some reason, dracut defaults to creating non-compressed images when nothing is passed, so I'll probably add arguments to make sure they are compressed. Regards, Giancarlo Razzolini pgptC3g9x8lIo.pgp Description: PGP signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 7:05 PM, Genes Lists via arch-general wrote: > Only suggestion I'd make is adding "--mdadmconf" perhaps by default - To clarify, I mean in dracut.conf - so I should probably have said mdadmconf="yes" ... anyway, thanks again. gene
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 11/3/19 4:02 PM, Giancarlo Razzolini wrote: > > I'm as of now writing hooks for dracut to be able to install the kernel, as > mkinitcpio does, and I'm considering have a preset config, like mkinicpio, > so it gives the user the ability to decide how dracut is ran. > > Other than that, given that dracut is slightly different than mkinitcpio, I > don't think these hooks should be overworked. On the other hand, the kernel > installation will be somewhat inflexible if done only to /boot. > > I think initially it'll be like that, but then we can use dracut's > configuration > for this. > > Regards, > Giancarlo Razzolini Thank you ... I really like dracut - it works well. Only suggestion I'd make is adding "--mdadmconf" perhaps by default - though I can see it both ways for those who don't use RAID - if its easy to add that would also be totally fine. Thanks again. gene
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
Em novembro 3, 2019 12:45 Genes Lists via arch-general escreveu: On 10/31/19 2:30 PM, Giancarlo Razzolini via arch-general wrote: ... ... Also, as I've mentioned, dracut should receive soon, hooks similar to those mkinitcpio did, with a few differences of course. Since Giancarlo brought up dracut in May this year, I've been using this successfully to boot custom built upstream kernels on about 8 different systems, including servers running soft RAID. And it works very, very well - thank you for driving this forward. Giancarlo is there anything that may need changing to boot using dracut going forward? I'm as of now writing hooks for dracut to be able to install the kernel, as mkinitcpio does, and I'm considering have a preset config, like mkinicpio, so it gives the user the ability to decide how dracut is ran. Other than that, given that dracut is slightly different than mkinitcpio, I don't think these hooks should be overworked. On the other hand, the kernel installation will be somewhat inflexible if done only to /boot. I think initially it'll be like that, but then we can use dracut's configuration for this. Regards, Giancarlo Razzolini pgpBrFDffKObr.pgp Description: PGP signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/19 2:30 PM, Giancarlo Razzolini via arch-general wrote: ... > ... Also, as I've mentioned, dracut should receive > soon, hooks similar to those mkinitcpio did, with a few differences of > course. Since Giancarlo brought up dracut in May this year, I've been using this successfully to boot custom built upstream kernels on about 8 different systems, including servers running soft RAID. And it works very, very well - thank you for driving this forward. Giancarlo is there anything that may need changing to boot using dracut going forward?
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
> > From: Eli Schwartz via arch-general > Sent: Fri Nov 01 23:06:03 CET 2019 > To: > Cc: Eli Schwartz > Subject: Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod > > > Dracut does not work out of the box (we currently patch it to not use a > nonexistent tool, and the same patch is now in upstream master but with > no release in sight), and has issues like the tests failing on > non-Redhat systems. > > Our dracut packager tried to get in touch with the dracut developer, > after a lack of success for quite some time it seems that the individual > in question was on... parental leave, IIRC? I'm not sure what the > current status is. > In such cases using tip of git branch would help. > So the jury is still out on whether dracut or mkinitcpio is more work. ;) > Making dracut work initially may need some work but after that it will just work. There is also 3rd-party initramfs modules developer perspective where coding something once which then will work on all distros (as dracut is supported in fedora/rhel, ubuntu/debian, suse, etc.) makes life easier than having to support each distro separately. Fragmentation is big issue as always. Yours sincerely G. K.
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/19 3:46 PM, Giancarlo Razzolini wrote: > Hi Eli, > > This is totally uncalled for. Even though I agree that kernel-install is > *not* > that great, there's no need to be aggressive. > > The question, even if phrased not in the best way, is a legitimate one. Didn't seem like much of a question to me. As far as I'm aware, there is no actual blocker to it, we even package it as one of the collection of tools made available by systemd so you literally cannot avoid having it available as it's a mandatory part of base. (The kernel is not mandatory, and mkinitcpio is not mandatory, but kernel-install is mandatory.) To aid such people, both mkinitcpio and dracut install relevant files to /usr/lib/kernel/install.d/ ... If people think kernel-install is an interesting technology which they would like to try out, that is fine. If people think kernel-install is literally the best ever and they must use it, that's fine too. I personally don't feel that way, and would rather have the option to skip the use of kernel-install, and that is fine too. I'm a bit skeptical, though, of posts which feature, essentially, "I notice Arch Linux does not bless kernel-install as the official kernel method of Arch Linux and request that you justify your decision to not use documented standards[0] and instead use your exclusivist Arch Linux hooks which merit multiple exclamation marks worth of surprise, because gosh is this surprisingly surprising". So I *inverted the question*. (I acknowledge I may have gotten a bit exaggerated in the process... I apologize. OTOH, I didn't quite intend my statements about kernel-install 100% seriously.) -- Eli Schwartz Bug Wrangler and Trusted User [0] Putting something in a manpage doesn't necessarily make it a standard, even if you find it really useful and enjoyable to use. signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/19 6:19 PM, Geo Kozey via arch-general wrote: > Thx, my concern was more about maintenance burden for Arch devs vs relying on > dracut + kernel-install combo and call it a day. > If devs prefer to work on exclusive service for Arch users then let it be. Dracut does not work out of the box (we currently patch it to not use a nonexistent tool, and the same patch is now in upstream master but with no release in sight), and has issues like the tests failing on non-Redhat systems. Our dracut packager tried to get in touch with the dracut developer, after a lack of success for quite some time it seems that the individual in question was on... parental leave, IIRC? I'm not sure what the current status is. So the jury is still out on whether dracut or mkinitcpio is more work. ;) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
> > From: Giancarlo Razzolini > Sent: Thu Oct 31 19:30:42 CET 2019 > To: General Discussion about Arch Linux , Geo > Kozey > Subject: Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod > > There are several reasons for not using it. It's overly complex, it does a > lot of assumptions for you, among other > things. That doesn't mean it *can't* be used by the users. We are taking baby > steps on making the booting process > on Arch overall more flexible. > > You can *right now* completely override the mkinitcpio hooks and, install and > deal with the kernel *any* way you want. > Want to not use /boot? Can do. Want to stuff everything on /efi? Can do. Want > a hook that will build your efistub and > update entries? Can do. This update opens up lots of possibilities, while > also maintaining (some) backward compatibility. > > I'm planning a few changes [0] to mkinitcpio, to make this even more > flexible. Also, as I've mentioned, dracut should receive > soon, hooks similar to those mkinitcpio did, with a few differences of > course. But, since the most important part for keeping > most user's systems booting is the actual kernel installation, if you opt to > override either the mkinitcpio hooks or dracut's, > it will be your job to make sure you install the kernel to wherever you want > it. > > Regards, > Giancarlo Razzolini > > [0] https://github.com/archlinux/mkinitcpio/issues Thx, my concern was more about maintenance burden for Arch devs vs relying on dracut + kernel-install combo and call it a day. If devs prefer to work on exclusive service for Arch users then let it be. Yours sincerely G. K.
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
> > From: Eli Schwartz via arch-general > Sent: Thu Oct 31 20:16:18 CET 2019 > To: > Cc: Eli Schwartz > Subject: Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod > > > On 10/31/19 2:11 PM, Geo Kozey via arch-general wrote: > > What was the reason for not using kernel-install[1] standard instead of all > > of those Arch's exclusive hooks again?? > > > > https://www.freedesktop.org/software/systemd/man/kernel-install.html > > What was the reason for suggesting to use kernel-install non-standard > Fedora tool that does gross things in a gross way instead of "all those > tools" (all one of them) which do the exact same thing in a more KISS > manner that respects user choice, makes it clear what you're using and > when you're using it, and helps track files properly in pacman? > As the link suggests, it's systemd tool not Fedora one. I don't think Arch has anything against systemd. As I understand there will be two tools that deal with kernel install now: mkinitcpio hook and dracut hook. kernel-install could replace both. They can just call it. Moreover as I read the long term plan was to replace mkinitcpio with dracut and dracut is already integrated with kernel-install because Fedora (yay!) uses them both. That means it would be possible to outsource whole initramfs creation process upstream and free up downstream resources for something else. > I don't understand your loaded question, but this game of "let's assume > things and then yell at people for doing things the same way they worked > for many many years" sure is fun! There was neither yelling or assumptions, just a question. Also things that worked for many many years are changing which is what triggered whole discussion. > P.S. Put down your question mark key. There's no need to act quite > *that* shocked that no one drank the Fedora kool-aid. I didn't noticed double question mark until I read your reply. Sorry. Yours sincerely G. K.
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/2019 01:30 PM, Giancarlo Razzolini via arch-general wrote: > Em outubro 31, 2019 15:11 Geo Kozey escreveu: >> >> What was the reason for not using kernel-install[1] standard instead of >> all of those Arch's exclusive hooks again?? >> >> https://www.freedesktop.org/software/systemd/man/kernel-install.html >> >> Yours sincerely >> >> G. K. >> > > There are several reasons for not using it. It's overly complex, it does a > lot of assumptions for you, among other things. That doesn't mean it > *can't* be used by the users. We are taking baby steps on making the > booting process on Arch overall more flexible. > > You can *right now* completely override the mkinitcpio hooks and, install > and deal with the kernel *any* way you want. Want to not use /boot? Can do. > Want to stuff everything on /efi? Can do. Want a hook that will build your > efistub and update entries? Can do. This update opens up lots of > possibilities, while also maintaining (some) backward compatibility. > As long as my mdadm arrays continue to assemble and I don't end up with a dead remote-supported box on reboot -- I'm all for it. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
Em outubro 31, 2019 16:16 Eli Schwartz via arch-general escreveu: What was the reason for suggesting to use kernel-install non-standard Fedora tool that does gross things in a gross way instead of "all those tools" (all one of them) which do the exact same thing in a more KISS manner that respects user choice, makes it clear what you're using and when you're using it, and helps track files properly in pacman? I don't understand your loaded question, but this game of "let's assume things and then yell at people for doing things the same way they worked for many many years" sure is fun! P.S. Put down your question mark key. There's no need to act quite *that* shocked that no one drank the Fedora kool-aid. *steps off soapbox* Hi Eli, This is totally uncalled for. Even though I agree that kernel-install is *not* that great, there's no need to be aggressive. The question, even if phrased not in the best way, is a legitimate one. Regards, Giancarlo Razzolini pgp22vrbCxYaP.pgp Description: PGP signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/19 2:11 PM, Geo Kozey via arch-general wrote: > What was the reason for not using kernel-install[1] standard instead of all > of those Arch's exclusive hooks again?? > > https://www.freedesktop.org/software/systemd/man/kernel-install.html What was the reason for suggesting to use kernel-install non-standard Fedora tool that does gross things in a gross way instead of "all those tools" (all one of them) which do the exact same thing in a more KISS manner that respects user choice, makes it clear what you're using and when you're using it, and helps track files properly in pacman? I don't understand your loaded question, but this game of "let's assume things and then yell at people for doing things the same way they worked for many many years" sure is fun! P.S. Put down your question mark key. There's no need to act quite *that* shocked that no one drank the Fedora kool-aid. *steps off soapbox* -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
Em outubro 31, 2019 15:28 Damjan Georgievski via arch-general escreveu: I can make a more general hook, for example triggering on usr/lib/modules/*/pkgbase (or vmlinuz?) - is that the recommended way now? All the official kernels will have pkgbase on them. So, trigger on vmlinuz, which is the actual kernel, but use pkgbase to know which one you're dealing with. The mkinitcpio hook, as it is now, won't touch a kernel that has no pkgbase, but in some circumstances, if the kernel is a non official one, that has no pkgbase yet, the hook might end up causing the initramfs to be built twice. Other than that, there shouldn't be any issues. Regards, Giancarlo Razzolini pgpTROo4MGg2c.pgp Description: PGP signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
Em outubro 31, 2019 15:11 Geo Kozey escreveu: What was the reason for not using kernel-install[1] standard instead of all of those Arch's exclusive hooks again?? https://www.freedesktop.org/software/systemd/man/kernel-install.html Yours sincerely G. K. There are several reasons for not using it. It's overly complex, it does a lot of assumptions for you, among other things. That doesn't mean it *can't* be used by the users. We are taking baby steps on making the booting process on Arch overall more flexible. You can *right now* completely override the mkinitcpio hooks and, install and deal with the kernel *any* way you want. Want to not use /boot? Can do. Want to stuff everything on /efi? Can do. Want a hook that will build your efistub and update entries? Can do. This update opens up lots of possibilities, while also maintaining (some) backward compatibility. I'm planning a few changes [0] to mkinitcpio, to make this even more flexible. Also, as I've mentioned, dracut should receive soon, hooks similar to those mkinitcpio did, with a few differences of course. But, since the most important part for keeping most user's systems booting is the actual kernel installation, if you opt to override either the mkinitcpio hooks or dracut's, it will be your job to make sure you install the kernel to wherever you want it. Regards, Giancarlo Razzolini [0] https://github.com/archlinux/mkinitcpio/issues pgp3LNR9eFr2a.pgp Description: PGP signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On Thu, 31 Oct 2019 at 14:55, Giancarlo Razzolini wrote: > > Em outubro 31, 2019 9:46 Damjan Georgievski via arch-general escreveu: > > Can someone explain in better detail the changes in > > * kmod 26-3 > > * mkinitcpio 27-1 > > * linux 5.3.8.1-1 > > around packaging and pacman hooks? > > > > I can see there's some reorganization of the hooks and scripts, and > > the kernel package no longer > > installing directly to /boot (which is a welcome change, the kernel is > > now only in /usr/lib/modules/5.3.8-arch1-1/vmlinuz) > > but it's not easy for me to reverse-understand what the bash scripts do > > exactly. > > > > I'm asking because I also use pacman hooks on the kernel and some > > other files in order to create my combined kernel+initramfs+cmdline > > UEFI executable signed for secure-boot, and it seems I'll have to > > adopt to a newer setup. > > > > > Hi Damjan, > > The kernel does not install itself anymore to /boot, as you've noticed. But, > the mkinitcpio > hook does that. For now, we are replicating the same behavior as before, but > with a little > more flexibility. > > > I'm working on dracut hooks for doing a similar job, but the idea is that we > eventually will > be more flexible with our booting, giving the user more options. Keep an eye > on the Arch announce > mailing list, as well as the news on the Arch site. > > As for your hooks, we made so that the mkinitcpio hook runs at the same step > the previous linux > hook would. So, there shouldn't be any incompatibilities. But, it depends on > what your hooks are. > Also, you can completely override the mkinitcpio hooks by linking their > filenames to /dev/null on > /etc/pacmand.d/hooks directory. But you'll be left doing the kernel > installation on your own. Thanks for the info Giancarlo, it's true that my hook works as before (I've tested that), but even my original hook was suboptimal anyway, since I needed to define one hook per kernel package. I'm wondering if I can make a more general hook, for example triggering on usr/lib/modules/*/pkgbase (or vmlinuz?) - is that the recommended way now? -- damjan
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
> > From: Giancarlo Razzolini via arch-general > Sent: Thu Oct 31 14:55:47 CET 2019 > To: General Discussion about Arch Linux > Cc: Giancarlo Razzolini > Subject: Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod > > Hi Damjan, > > The kernel does not install itself anymore to /boot, as you've noticed. But, > the mkinitcpio > hook does that. For now, we are replicating the same behavior as before, but > with a little > more flexibility. > > I'm working on dracut hooks for doing a similar job, but the idea is that we > eventually will > be more flexible with our booting, giving the user more options. Keep an eye > on the Arch announce > mailing list, as well as the news on the Arch site. > > As for your hooks, we made so that the mkinitcpio hook runs at the same step > the previous linux > hook would. So, there shouldn't be any incompatibilities. But, it depends on > what your hooks are. > Also, you can completely override the mkinitcpio hooks by linking their > filenames to /dev/null on > /etc/pacmand.d/hooks directory. But you'll be left doing the kernel > installation on your own. > > Regards, > Giancarlo Razzolini What was the reason for not using kernel-install[1] standard instead of all of those Arch's exclusive hooks again?? https://www.freedesktop.org/software/systemd/man/kernel-install.html Yours sincerely G. K.
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
Em outubro 31, 2019 9:46 Damjan Georgievski via arch-general escreveu: Can someone explain in better detail the changes in * kmod 26-3 * mkinitcpio 27-1 * linux 5.3.8.1-1 around packaging and pacman hooks? I can see there's some reorganization of the hooks and scripts, and the kernel package no longer installing directly to /boot (which is a welcome change, the kernel is now only in /usr/lib/modules/5.3.8-arch1-1/vmlinuz) but it's not easy for me to reverse-understand what the bash scripts do exactly. I'm asking because I also use pacman hooks on the kernel and some other files in order to create my combined kernel+initramfs+cmdline UEFI executable signed for secure-boot, and it seems I'll have to adopt to a newer setup. Hi Damjan, The kernel does not install itself anymore to /boot, as you've noticed. But, the mkinitcpio hook does that. For now, we are replicating the same behavior as before, but with a little more flexibility. I'm working on dracut hooks for doing a similar job, but the idea is that we eventually will be more flexible with our booting, giving the user more options. Keep an eye on the Arch announce mailing list, as well as the news on the Arch site. As for your hooks, we made so that the mkinitcpio hook runs at the same step the previous linux hook would. So, there shouldn't be any incompatibilities. But, it depends on what your hooks are. Also, you can completely override the mkinitcpio hooks by linking their filenames to /dev/null on /etc/pacmand.d/hooks directory. But you'll be left doing the kernel installation on your own. Regards, Giancarlo Razzolini pgpa0avOjF7IR.pgp Description: PGP signature
[arch-general] new packaging of the kernel/mkinitcpio/kmod
Can someone explain in better detail the changes in * kmod 26-3 * mkinitcpio 27-1 * linux 5.3.8.1-1 around packaging and pacman hooks? I can see there's some reorganization of the hooks and scripts, and the kernel package no longer installing directly to /boot (which is a welcome change, the kernel is now only in /usr/lib/modules/5.3.8-arch1-1/vmlinuz) but it's not easy for me to reverse-understand what the bash scripts do exactly. I'm asking because I also use pacman hooks on the kernel and some other files in order to create my combined kernel+initramfs+cmdline UEFI executable signed for secure-boot, and it seems I'll have to adopt to a newer setup. -- damjan
