- Arch-dev-public - lists.archlinux.org

[arch-dev-public] [signooff] xz-utils 4.999.9beta-1
by Pierre Schmitz 27 Aug '09

27 Aug '09

Please sign off for new upstream version. This fixes e.g. data corruption: > XZ Utils 4.999.9beta was released on 2009-08-27. Among many less important > changes, this release fixes a data corruption in the compression code. > Everyone using an older version of XZ Utils should upgrade. > > This is the last beta release before XZ Utils 5.0.0. No big changes are > planned before the first stable release. -- Pierre Schmitz, http://users.archlinux.de/~pierre

2 1

[arch-dev-public] [Fwd: Re: [PATCH] Implement a hook-system that allows to add custom code to the initscripts at certain places]
by Thomas Bächler 27 Aug '09

27 Aug '09

Forwarding to the dev list. -------- Original-Nachricht -------- Betreff: Re: [PATCH] Implement a hook-system that allows to add custom code to the initscripts at certain places Datum: Thu, 27 Aug 2009 16:56:32 +0200 Von: Kurt J. Bosch <kujub(a)quantentunnel.de> An: Thomas Bächler <thomas(a)archlinux.org> CC: Public mailing list for ArchLinux development <arch-dev-public(a)archlinux.org> Referenzen: <4A93C509.7060505(a)archlinux.org> <4A955EAE.3040904(a)quantentunnel.de> <4A9561E1.4050108(a)archlinux.org> I noticed one problem: Fbsplash is unable now to show the SIGTERM message since the daemon restarter is forked before the stat_busy. [code] run_hook shutdown_prekillall # Terminate all processes stat_busy "Sending SIGTERM To Processes" [/code] To fix this please move the run_hook *behind* the stat_busy in rc.shutdown and rc.single: [code] # Terminate all processes stat_busy "Sending SIGTERM To Processes" run_hook shutdown_prekillall [/code] This would also improve consistency since in rc.sysinit there is already: [code] stat_busy "Mounting Local Filesystems" ... run_hook sysinit_premount [/code]

1 0

[arch-dev-public] introducing kernel26-lts
by Andreas Radke 27 Aug '09

27 Aug '09

Today I've added a 2nd kernel to our svn called "kernel26-lts". It should help to make you less caring about kernel updates. The intention is to 1) have a 2nd choice for the kernel pkg that suits better in certain situations and 2) it can be a fallback when a reboot after updating the core "kernel26" fails more detailed: 1) pkgdesc="The Linux Kernel and modules - stable longtime supported kernel package suitable for servers" The current longtime supported kernel version is 2.6.27.xx, right now we are at 2.6.27.31. The pkgdesc should clearly say what it should become in the future. Server systems won't be forced to take the risk to fail on the next boot after each kernel update. Modifications will be very small in the future within its lifecycle. The kernel configuration is based on the last .27.x config form our core pkg with small changes it has become in later versions + optimizations for server usage taken from here: http://www.serverwatch.com/tutorials/article.php/3715071/Ubuntu-Server--Ker… main changes are: 100Hz, no preempt, deadline I/O schedular. There will be no 3rd party modules. And no further patching. 2) a fallback kernel für almost everybody: a long requested feature. Everybody can install it along the core "kernel26" pkg and add lilo/grub entries for the "lts" kernel. Whenever an update of a future kernel26 will fail you won't be forced to boot with a rescue stick or cd. This should help a lot. attention: 2.6.27 kernel haven't had full ext4 support. I myself run a desktop with an ext4 / partition created with a later kernel version. the "lts" kernel is not capable to boot into this filesystem! But on real servers I guess everybody will wait a bit longer to use ext4. For the future it is planned to probably add Xen support to this or an outsplitted pkg. I will upload packages for both architectures to testing over the next days. Please discuss when you want see changes to the config file (x86_64 is done, i686 is not ready so far). -Andy

7 13

[arch-dev-public] [signoff] fakeroot-1.13-1
by Allan McRae 27 Aug '09

27 Aug '09

Upstream update. Signoff both. Allan

3 2

[arch-dev-public] Mirrors supporting rsync
by Aaron Griffin 27 Aug '09

27 Aug '09

Below is a list of our current mirrors that support rsync. I would like to begin the process of setting up Tiered mirroring to give gerolde some breathing room. To do this, I would like to know the following things: * Which of these mirrors are unreliable? * How many mirrors do we want at the first tier? * What criteria should we use to decide which mirrors are capable of being a tier 1 mirror? * What is the rsync speed for these mirrors? (How much bandwidth do they have to offer?) If anyone has the time to research this, please do so and respond. Mirrors supporting rsync: 26 aarnet.edu.au archlinux.fi archlinux.nautile.nc archlinuxfr.org archlinuxfr.org c3sl.ufpr.br csclub.uwaterloo.ca ftp.df.lth.se gwdg.de hs-esslingen.de iinet.net.au internode.on.net las.ic.unicamp.br leaseweb.com mirror.svk.su mirrors.xmission.com pacific.net.au pwsz.elblag.pl rit.edu roedu.net spline.inf.fu-berlin.de twilightlair.net umoss.org unej.ac.id uni-bayreuth.de uni-kl.de

6 8

[arch-dev-public] [Fwd: Re: [PATCH] Implement a hook-system that allows to add custom code to the initscripts at certain places]
by Thomas Bächler 26 Aug '09

26 Aug '09

-------- Original-Nachricht -------- Betreff: Re: [arch-dev-public] [PATCH] Implement a hook-system that allows to add custom code to the initscripts at certain places Datum: Wed, 26 Aug 2009 15:10:16 +0200 Von: Michael Towers <larch42(a)googlemail.com> An: Thomas Bächler <thomas(a)archlinux.org> Referenzen: <4A93C509.7060505(a)archlinux.org> <4A93C694.3030401(a)archlinux.org> <ed5b1830908260446o4cd75196s617baf1a3dd68db4(a)mail.gmail.com> <4A95255D.2080507(a)archlinux.org> 2009/8/26 Thomas Bächler <thomas(a)archlinux.org>: > Full-quoting, as your mail didn't go to the list. > > Michael Towers schrieb: >> >> 2009/8/25 Thomas Bächler <thomas(a)archlinux.org>: >>> >>> Thomas Bächler schrieb: >>>> >>>> A function add_hook can be called from functions.d to register a hook >>>> function. The existing hooks are based on suggestions from Michael >>>> Towers >>>> (larch) and on the implementation of initscripts-extras-fbsplash which >>>> currently uses the strings passed to stat_busy and stat_done for this. >>>> More >>>> hooks can be added if requested. >>> >>> Forgot to mention this in the commit and the first mail: the hook >>> function >>> names should be prefixed by something to make them unique, for example: >>> >>> add_hook premount larch_premount >>> >>> If larch would decide to add a "premount" hook. >>> >>> >> >> I've had a look at this now and find it basically a pretty good idea, >> though I think I slightly prefer my suggestion. > > Hmm, your suggestion required an extra file per hook and wouldn't allow > several parties to register code for the same hook. That's what I didn't > like. > >> This just seems a >> little too complicated, but I have a couple of ideas for simplifying >> it a bit. Mainly I'm not so sure about passing the script name as >> argument and having hooks with the same name (e.g. 'start') in several >> rc. files. That means that if I write a hook function for 'start' I >> must always test that the call came from the correct rc. file. > > Correct. The idea came up because if I have a "prekillall" hook, users like > fbsplash would want to hook up code regardless of whether it is caled from > rc.shutdown or rc.single, while other users would only want to use it from > rc.shutdown. This was part of my first approach. > > With the new approach, I could have a hook shutdown_prekillall and > single_prekillall and just register the same function for it: > > add_hook single_prekillall my_prekillall > add_hook shutdown_prekillall my_prekillall > > So this is obsolete now, and I agree that renaming the hooks to be unique is > a better idea. If I don't receive a patch for that until tonight, I will do > it then. > >> Wouldn't it be simpler to give each hook a unique name, even if it has >> to be something like 'start_shutdown'? > > I will use the convention $FILE_$HOOKTYPE if that is alright, like > "sysinit_start" or "shutdown_poweroff". > >> That would be nearly the same >> as what you are suggesting, but the hook functions would not have to >> test the argument. >> >> I also have a further suggestion for simplification - the >> predeclaration of the hook names in the 'functions' file: >> >> for hook in start end udevlaunched udevsettled premount prekillall >> postkillall poweroff; do >> hook_funcs["${hook}"]="" >> done >> >> is not necessary. Bash arrays return empty strings for undefined >> indexes too. This has the great advantage that when a new hook is >> added you wouldn't have to edit the 'functions' file. > > I still would have to add a comment in 'functions', but I agree. > >> Apart from that it seems quite attractive, if you are determined to >> keep it all as scripts in functions.d. > > Yes, I don't want to add extra directories, functions.d can serve several > purposes quite fine. And if you like, your hooks can just be wrappers that > will call scripts from other places. > > Anyway, I'm glad that this is an approach you are willing to work with, and > I hope fbsplash will also adopt this instead of parting $1 in stat_busy and > stat_done. > > Can you give suggestions regarding the hook names (I still find some of them > sound weird) and comment on whether more hooks are needed, or some of them > are badly placed? > >> Regards, >> mt >> > > > It sounds like my wishes will be well satisfied now! As to the names, it's not something that seems terribly important to me. I try to comment my code anyway and so it wouldn't even be a disaster if they had names like x23_ooo_aaah (ok, I'm exaggerating, they should probably make some sort of sense). I also can't say much about their placement in general or suggest further places as I have only really thought about the places the current larch design would use, and you already have those. I guess you got the others from fbsplash. Maybe at the beginning there shouldn't be too many - it would be easier to add a new one than to move an old one (which somebody might already be using). Maybe briefly the reasons I requested this for larch. In a live system it is helpful to have a bit of flexibility in the way the system is started, the root filesystem is mostly aufs (etc.) and what should appear in /etc/mtab is probably not the same as in a non-live system, also what should get mounted or entered in fstab might well change from boot to boot (from machine to machine). There are other points at which this can be done, but via a hook in rc.sysinit seems cleaner to me. As to rc.shutdown, the main need in larch is caused by session saving, which is probably cleanest/safest when carried out towards the end of the shutdown process. With CDs there is also the question of ejecting the device, which must also happen right at the end. Up to now I have used modified rc.sysinit and rc.shutdown scripts to achieve this, which means editing them every time initscripts is updated - rather annoying. Thanks for your interest and work, mt

1 1

[arch-dev-public] Away Thurs-Sun
by Daniel Isenmann 26 Aug '09

26 Aug '09

Time for a short vacation. I will be back on Sunday evening. I have no internet access during this time. A weekend full of camping and hiking :) Daniel

3 2

Re: [arch-dev-public] [PATCH] Implement a hook-system that allows to add custom code to the initscripts at certain places
by Thomas Bächler 26 Aug '09

26 Aug '09

Kurt J. Bosch schrieb: > Thank you for this one. I already tried this with > initscripts-extras-fbsplash without any problems. :) I Keep watching initscritps-git, it will change again slightly before I release it. I hope to keep the hooks API stable after the next initscripts release though. Were you able to remove all your hacks that needed to compare the arguments of stat_busy and stat_done calls to fixed strings? I particularly disliked those. > OT: Currently I have to duplicate the CONSOLEFONTS code from rc.sysinit > and run it after the splash daemon is stopped because setfont destroys > the splash screen. Could this be moved into a separate daemon scriptlet > ? ... or even simply dropped since the keymap initcpio hook provides > this functionality anyway ? We cannot depend on the initramfs in the real system - once the root is mounted and the system is started, it's a new game. I don't know how to solve this right away, can you open a bug report (haha ...) - seriously, we need a clean way to move this code, I'll think about it.

1 0

[arch-dev-public] [Fwd: Re: [PATCH] Implement a hook-system that allows to add custom code to the initscripts at certain places]
by Thomas Bächler 26 Aug '09

26 Aug '09

Full-quoting, as your mail didn't go to the list. Michael Towers schrieb: > 2009/8/25 Thomas Bächler <thomas(a)archlinux.org>: >> Thomas Bächler schrieb: >>> A function add_hook can be called from functions.d to register a hook >>> function. The existing hooks are based on suggestions from Michael Towers >>> (larch) and on the implementation of initscripts-extras-fbsplash which >>> currently uses the strings passed to stat_busy and stat_done for this. More >>> hooks can be added if requested. >> Forgot to mention this in the commit and the first mail: the hook function >> names should be prefixed by something to make them unique, for example: >> >> add_hook premount larch_premount >> >> If larch would decide to add a "premount" hook. >> >> > > I've had a look at this now and find it basically a pretty good idea, > though I think I slightly prefer my suggestion. Hmm, your suggestion required an extra file per hook and wouldn't allow several parties to register code for the same hook. That's what I didn't like. > This just seems a > little too complicated, but I have a couple of ideas for simplifying > it a bit. Mainly I'm not so sure about passing the script name as > argument and having hooks with the same name (e.g. 'start') in several > rc. files. That means that if I write a hook function for 'start' I > must always test that the call came from the correct rc. file. Correct. The idea came up because if I have a "prekillall" hook, users like fbsplash would want to hook up code regardless of whether it is caled from rc.shutdown or rc.single, while other users would only want to use it from rc.shutdown. This was part of my first approach. With the new approach, I could have a hook shutdown_prekillall and single_prekillall and just register the same function for it: add_hook single_prekillall my_prekillall add_hook shutdown_prekillall my_prekillall So this is obsolete now, and I agree that renaming the hooks to be unique is a better idea. If I don't receive a patch for that until tonight, I will do it then. > Wouldn't it be simpler to give each hook a unique name, even if it has > to be something like 'start_shutdown'? I will use the convention $FILE_$HOOKTYPE if that is alright, like "sysinit_start" or "shutdown_poweroff". > That would be nearly the same > as what you are suggesting, but the hook functions would not have to > test the argument. > > I also have a further suggestion for simplification - the > predeclaration of the hook names in the 'functions' file: > > for hook in start end udevlaunched udevsettled premount prekillall > postkillall poweroff; do > hook_funcs["${hook}"]="" > done > > is not necessary. Bash arrays return empty strings for undefined > indexes too. This has the great advantage that when a new hook is > added you wouldn't have to edit the 'functions' file. I still would have to add a comment in 'functions', but I agree. > Apart from that it seems quite attractive, if you are determined to > keep it all as scripts in functions.d. Yes, I don't want to add extra directories, functions.d can serve several purposes quite fine. And if you like, your hooks can just be wrappers that will call scripts from other places. Anyway, I'm glad that this is an approach you are willing to work with, and I hope fbsplash will also adopt this instead of parting $1 in stat_busy and stat_done. Can you give suggestions regarding the hook names (I still find some of them sound weird) and comment on whether more hooks are needed, or some of them are badly placed? > Regards, > mt >

2 1

[arch-dev-public] To the developers that went to froscon 09
by Eduardo Romero 26 Aug '09

26 Aug '09

Hi guys, I know some of you went to froscon, and did enjoyed the experience a lot. I am here asking, if any of you developers could write a text about froscon, the experience, who you met, and how it all went overall. Nothing too fancy, it will in fact feature as an article in the Arch Linux Magazine, it would be appreciated if you could have some photos as well. Contact me if you are able to take on it. Preferably a developer, but in the event that no developer can get to it, a trusted user could do. Thanks for your interest as always, Eduardo Romero "kensai"

10 14