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

[arch-dev-public] X.Org 7.3 pre-release testing repo
by Alexander Baldeck 06 Sep '07

06 Sep '07

Hey all, X.Org 7.3's release is about to happen in the next few days/weeks. For that reason I've built the latest xorg-server snapshot which is at version 1.3.99.2 and most of the drivers and newly introduced packages. A lot has changed, primarily in the area of driver ABI. For example nvidia is broken, it does build but xorg-server rejects it when starting up with an API mismatch error. Forcing it leads to hardlocks. I am using xf86-video-nv for now but this issue needs to be addressed. I have no idea how well fglrx & unichrome-dri plays with the new server. So I'd like to hear about it. Anyone wanting to take part in testing, should add this repo: http://kth5.telekommunisten.net/xorg/ The PKGBUILs will soon be available with the same URL, just need to clean them up a bit. Cheers, -F

8 20

[arch-dev-public] Fwd: [arch] WWW Root dir
by Aaron Griffin 04 Sep '07

04 Sep '07

Can we revisit this please? http://www.archlinux.org/mailman/private/arch-dev/2007-March/004700.html for reference ---------- Forwarded message ---------- From: Sergej Pupykin <ps(a)lx-ltd.ru> Date: Sep 4, 2007 8:29 AM Subject: [arch] WWW Root dir To: arch(a)archlinux.org Hi, I see /srv in filesystem package. What about www root? What decision was reached? _______________________________________________ arch mailing list arch(a)archlinux.org http://archlinux.org/mailman/listinfo/arch

1 0

Re: [arch-dev-public] Stellarium 0.9.0 and repo considerations
by Damir Perisa 04 Sep '07

04 Sep '07

Hi Corrado, Tuesday 04 September 2007, you wrote: | I wrote a PKGBUILD for the new stellarium, and added my .desktop | file to it (there even was a bug report about that, nobody added | it in the new version but I'm going to send it to the stellarium | team, too). I also noticed that the new version depends on qt4, | which is in community, while stellarium is in extra, so either we | move qt4 to extra (I don't think many people would like it) or we | move stellarium to community. If you think the latter is a good | idea I can take care of it and maintain the package there, just | let me know what you think about it. qt4 is going to [extra] "soon". kde4 will need it and also other pkgs are waiting for update for it (qtiplot, qsynth, speedcrunch... just to mention a few). also the scim/skim qt-immodules are qt4 and not available in qt3. so once qt4 is in [extra] the input system SCIM will finally work in kde :) the problem with qt4 not yet being official is that for making it clean we need to make 3 pkgs: * the core libs (without any dependency on xorg) - for qt4 server apps * the qt4 everything else except the core and qt3 compatibility (legacy) libs * the qt3compatibility libs other distros are separating it exactly the same way. the splitting of the thing in 3 pkgs is a little bit tricky if we want to make it nice (not e.g. by building it and then just removing the files from the target pkg that do not belong to this pkg)... this is still work in progress and actually the only thing holding us back. no dev has yet time to digg in qt4 build system to make the 3 pkgs yet. qt4 will be placed in /usr and not in /opt as qt3 and qt4 can coexist, no big migration is needed, once qt4 is in [extra] => i do not want to update stellarium in [extra] yet. the qt4 waiting is exactly the reason. i also do not want to move it to community just to move it back in a few months. | Attached to this message you'll find the new build with the | .desktop file. if you want, i can backport it. however it would mean triggering a update and stellarium is a big pkg for up/download :) | The only thing I didn't take care of is the | license, which at a first glance seems a bit complex (I think it's | two or three licenses). You can find a summary of the various | licensed materials in $startdir/src/stellarium-0.9.0/README. pacman can handle multiple licenses. the license=() is an array. stellarium is at least GPL for sure, IIRC. :) if you want to take over and maintain it in community, feel free. but consider that it will soon have to be rebuilt against a qt4 in /usr anyway. thanx + greetings, Damir

1 0

[arch-dev-public] fixed checkpkg
by Paul Mattal 03 Sep '07

03 Sep '07

I fixed checkpkg to also look for new makepkg3-style package names, and rolled that into the makepkg3 patch in the devtools package. - P

1 0

[arch-dev-public] perl modules in archlinux
by Jan de Groot 03 Sep '07

03 Sep '07

Hi all, I've been busy modifying all perl packages today to follow the same installation method. I think I'm past halfway now, only 20-25 packages to go. I added some dependencies for modules which I retrieved from the META.yml and/or Makefile.PL files. Things I did: - make all build() functions the same - add !emptydirs to options to get rid of empty perl directories - add md5sums - update to newest versions - add licenses (used PerlArtistic for anything that doesn't have an official license) Please watch out carefully when adding new perl packages to the repository, we don't want these things to become bad again.

5 6

[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