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

[arch-dev-public] anybody uses amule?
by Damir Perisa 02 Sep '07

02 Sep '07

i happen to be amule pkg maintainer... however, i never used it (too slow connection) so i just keep on updating it, but this is bad for good maintaining... anybody uses it and wants to take this pkg from me? to be done: http://bugs.archlinux.org/task/7908 if not, i would suggest moving it to AUR. as i'm now running my pkgs for 2 ARCHs, i want to optimise my resources by dumping such pkgs (i myself do not use) one after the other. thanx + greetings, damir

1 0

[arch-dev-public] Absence until 9.9.
by Thomas Bächler 31 Aug '07

31 Aug '07

I will be on a conference in Austria from Sunday on for one week. I will have internet there, but I won't have much time to work on arch. There won't be much time today and tomorrow either, so I wish you a pleasant week.

1 0

[arch-dev-public] forcedeth
by Paul Mattal 30 Aug '07

30 Aug '07

[If you don't use the forcedeth driver, you can stop reading; this is just for people who might benefit from the research we did on this.] For all of you with NVIDIA integrated ethernet adapters which use the forcedeth driver, I thought I'd share the results of some troubleshooting and benchmarking we did this week. As you may know, the forcedeth driver has a provision to limit the amount of work done by the driver per invocation of the irq handler. As far as I can tell, this was implemented specifically because there is some broken hardware out there which can get a stuck irq and so the handler will then never exit and hang your machine. In any case, in doing some nfs benchmarks (using bonnie++), I was able to reliably crash my forcedeth-equipped nfs client machine VERY HARD, even using 2.6.22.5 which includes a forcedeth-related patch to partially address this behavior. To make a long story short, we discovered that this problem goes away if you increase the limit by doing the following in /etc/modprobe.conf: options forcedeth max_interrupt_work=20 My theory is that this still is in the spirit of the initial implementation.. if you have broken hardware with a stuck irq, one imagines it's likely to go through the loop FAR more than 20 times and the mechanism will still prevent your whole system from hanging. But under heavy load, it will still perform fine. You could probably even go higher than 20 with no ill effects, but I've never hit the 20 limit even under heavy load, so it seemed like a good place to stop. *Maybe even more interestingly: Increasing max_interrupt_work seemed to boost performance significantly on the adapter; where before it was pushing about 30-40Mbit out the adapter, it is now 50-60Mbit.* So if you've got one of these motherboards with forcedeth ether, especially in a server, try increasing your max_interrupt_work parameter for MUCH better performance and stability. - P

1 0

[arch-dev-public] AUFS
by Paul Mattal 30 Aug '07

30 Aug '07

Every so often I try again to figure out how to make AUFS coexist happily with Arch, and I usually end up failing. So I'm asking for some help puzzling this one out. AUFS requires a 3-line kernel patch, which appears to expose one function which is needed by AUFS to enable proper interaction with NFS: http://aufs.cvs.sourceforge.net/*checkout*/aufs/aufs/lhash.patch When the unionfs patches are applied, this patch cannot be cleanly applied! Though they don't directly conflict, they modify adjacent lines so patch can't find the right place to patch. What I'm trying to figure out is some way we can have both unionfs and aufs as options against kernel26 without having to recompile the kernel, in some way that will be feasible to maintain long-term. Any ideas? Anyone else interested in using AUFS know anything about this? We use to do root-on-nfs diskless workstations against a common base root filesystem, allowing individual workstations to modify their own root filesystem using a writeable aufs layer. Unionfs is specifically deficient when used in combination with nfs, and aufs is proving quite superior. Even if you haven't any ideas, thanks for listening! - P

2 1

[arch-dev-public] switch to more up-to-date util-linux and kbd?
by Roman Kyrylych 28 Aug '07

28 Aug '07

Hi! Today I've noticed a message in lkml about util-linux-ng. A quote: "The util-linux-ng is a fork of the original util-linux project. The goal of the util-linux-ng is a transparent and reliable development that follows the Linux kernel and Linux distributions". Home page: http://userweb.kernel.org/~kzak/util-linux-ng/ Highlights of the first release: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/347 Changes look interesting IMO. On util-linux-ng news archive I've also found a thread about updated kbd: http://thread.gmane.org/gmane.linux.utilities.util-linux-ng/326 which can be obtained from there: ftp://ftp.altlinux.org/pub/people/legion/kbd/ (note that kbd.git is outdated compared to tarballs) What do you think about this? -- Roman Kyrylych (Роман Кирилич)

2 3

[arch-dev-public] Call for help.
by Travis Willard 27 Aug '07

27 Aug '07

Hey guys, Can anyone out there take a look at http://bugs.archlinux.org/task/7886 and try to help this guy out. His system isn't booting properly anymore and it seems that, in trying to help, I only made it worse. If anyone can offer assistance, I'd be pretty grateful. -- Travis

1 0

[arch-dev-public] netcfg2 beta - Revamped network profiles
by James Rayner 26 Aug '07

26 Aug '07

Looking for testers for netcfg2, which will replace the current netcfg/profile system. This is pretty much a rewrite of the current scripts, making them more intelligent, easier to use, maintain, and closes up many bugs that have been lingering for far too long. In addition, many feature requests have been implemented too[1]. There' still some left, they'll come after this is stabilised and implemented. Packages and source are available here: http://src.iphitus.org/netcfg-release/ Please make sure you get the latest release. Documentation is still short. The example configs in /etc/network.d/ should be sufficient to get most people started. Daemon is now a seperate rc.d/net-profiles, and the rc.conf array has been renamed to NETWORKS=(). James [1] http://wiki.archlinux.org/index.php/Network_Scripts#New_Features [2] http://bbs.archlinux.org/viewtopic.php?id=36384

1 0

[arch-dev-public] Gimp-2.4 beta to current?
by Tobias Kieslich 24 Aug '07

24 Aug '07

Hi, I like to bring gimp-2.4 (rc1) to current. the 2.3.x is fairly stable for a while and I actually use it exclusively. Any objections? -T

4 5

[arch-dev-public] absence from 23.8 - 15.9
by Tobias Powalowski 23 Aug '07

23 Aug '07

Hi guys, im on vacation the next days, don't know if i have an inet connection on those days. have fun and keep arch rockin. I orphaned quite some packages last weekend so feel free to adopt them, the workload is too high for me and it's better to have experts on the packages then just bumping the releases. thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 1

[arch-dev-public] Major error with kernel26ck
by Tom K 22 Aug '07

22 Aug '07

Hi all. I would like to apologise for a fairly spectacular mess I have made with kernel26ck. The gory details are as follows. During the 2.6.22 test period, I built a kernel26ck package with the SLUB memory allocator enabled, for my own use. I submitted this package to extra in error, and compiled all external module packages against it. When I was building the current version, 2.6.22.3.ck1-1, I noticed my mistake, and changed back to the SLAB allocator, as used in the stock kernel. However, I did not appreciate the significance of this change at the time. Shortly after the SLAB-enabled package was released, I received reports that some of the existing module packages did not work with it. To solve this, I rebuilt all the *-ck modules against the new kernel version. I incorrectly assumed that the problem had been caused by incompatibility between the final -ck patchset release, 2.6.22-ck1, and the 2.6.22.3 update from kernel.org. To avoid further problems, I decided to announce the retirement of kernel26ck. I would like to thank Andy for identifying the correct cause of the problem i.e. the change from SLUB to SLAB. Andy is also of the opinion that we should either continue to update the package as long as it is in our repos, or else remove it now, and he cites today's 2.6.22.4 update, which provides a security update, as a good example of this. Taking all of the above into consideration, I now intend to continue maintaining kernel26ck until we move to the 2.6.23 kernel, at which time I will remove it from extra. I will amend Arch News accordingly. Once again, my apologies to all for this screw-up, and my thanks to Andy for letting me know. Regards Tom.

3 3