April 2007 - Arch-ports - lists.archlinux.org

[arch-ports] [PPC] Possibilities to help
by Harley Laue 29 Apr '07

29 Apr '07

This summer I might invest in a piece of PowerPC hardware. After running Arch Linux on my Gamecube, I now want to perhaps take the next step and buy a more practical PowerPC computer (perhaps a used Mac Mini G4) with the sole purpose to try and help out with this port. Which brings me to my question, I'd like to have a bit of an idea of what still needs to be done/maintained with Arch Linux PPC. I'd like to have at least an idea of what might be needed before I invest my time and money into a piece of hardware. If all that's needed is bug fixing, I'll be much less likely to consider buying the hardware if that's the case.

4 6

[arch-ports] [PPC] OpenSSH Package Needs A Rebuild
by Matthew William Cox 27 Apr '07

27 Apr '07

The ssh client and sshd server have incorrect paths to xauth hardcoded into tme. This breaks X11 forwarding on PPC clients and servers. This package needs to be rebuilt with the correct paths (probably just matter of running ./configure.) Until then, a work around is to set, in your system-wide /etc/ssh/ssh_config: > XAuthLocation /usr/bin/xauth and the same in /etc/ssh/sshd_config Here's the results of dumping the strings from ssh looking for xauth. > $ strings /usr/bin/ssh | grep xauth > /usr/X11R6/bin/xauth > xauthlocation > No xauth program. > %s/xauthfile > Warning: No xauth data; using fake authentication data for X11 forwarding. and here's the same process on the sshd binary: > $ strings /usr/sbin/sshd | grep xauth > /usr/X11R6/bin/xauth > xauthlocation > maxauthtries > No xauth program; cannot forward with spoofing. The correct path for the xauth binary is /usr/bin/xauth. The package version effected is 4.6p1-3, which at the time of this writing is the version in the package db. Matthew Cox

2 1

[arch-ports] [PPC] Proposal to put ADBSYN patch in Kernel26-pmac
by Matthew William Cox 26 Apr '07

26 Apr '07

I propose to include this patch in the stock archppc kernel. http://adbsyn.crisidev.org/ It allows users of powerbooks who have a synaptics trackpad (all of them) that's connected through ADB (all those prior to the two-finger-scoll variety) to use the full features of the trackpad. Specifically it allows the use of the synaptics xorg input driver. I've been using this patch on top of the arch pmac kernel for about a week now. The synaptics driver works perfectly with it. http://lkml.org/lkml/2006/1/6/453 This discusses why the patch hasn't gone into the mainline kernel. Once the trackpad is in absolute mode, the kernel continues to provide ps2 mouse emulation through /dev/input/mice. I've confirmed that this works, although obviously it's much less capable than when using the synaptics driver. Some features available only through the synaptics features are corner-tapping for clicking mouse buttons 1-N and edge scrolling, and tap-and-drag. These would benefit anybody with an ADB trackpad. Matthew Cox

1 0

[arch-ports] [PPC] New Packages: Lablgtk, Lablgtk2, Lablgl, Darcs, Ghc
by Matthew William Cox 25 Apr '07

25 Apr '07

Apologies for the repost, sent this from a non-registered address. No idea if it got through. I use a few packages that aren't yet available on arch-ppc. For the most part they're simple rebuilds of the i686 pkgbuilds. These are: lablgtk,labgtk2, lablgl -- Objective Caml bindings to GTK, GTK2, OpenGl darcs -- a distributed version control system, written in Haskell, which brings me to: ghc -- a haskell compiler. Building this on linux/ppc was a little fun since the devs don't seem to have a binary available to bootstrap with. I ended up making a temporary port of bootstrap compiler provided by the Gentoo Haskell team. Then I built the package and removed the bootstrap compiler. I can send folks the binary package if there's any interest, and once you have that, you can rebuild the package easily (5 hours or so on my PB G4.) I've attached the pkgbuilds. The GHC one will require you to have my binary already installed to build. If there's any interest I can upload it to some place. I'm working on getting some hosting in the next few days so I'll be able to post it there as well. Matthew Cox

1 0

Re: [arch-ports] [arch-dev-public] x86_64: improving default CFLAGS
by Andreas Radke 03 Apr '07

03 Apr '07

Am Tue, 3 Apr 2007 16:40:20 -0500 schrieb "Aaron Griffin" <aaronmgriffin(a)gmail.com>: > > > to not break backward compatibility for those few early cpus that > > > lack SSE3 extensions we want to do it with -mtune. this is how we > > > want to set it for the future: > > > > > > CFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe" > > > CXXFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe" > > I don't know the details, so I assumed you looked into it all. Just > in case: what 64bit processors does this "leave in the dust". > > Dropping support for some processors is not a huge problem (the age > old Via C3 + Arch problem), but i think it might be important to put a > blurb somewhere saying "If you have an XYZ processor, you need to use > the arch i686". > i don't want to drop support for any early x86_64 cpu. that's why i want to use "mtune". code will be optimized for SSE3 capable cpus but will still run on non SSE3 capable processors. that's the difference mtune to march. i686 had something similar prepared in the old makepkg.conf i don't expect a big gain at all but in certain multimedia apps it can speedup things a lot. so why not make use of the additional registers? apps *might* run a little bit slower if they cannot make use of the additional flags and will it probably raise the pkg size a bit. but it should be still worth it. Andy

1 0

Re: [arch-ports] [arch-dev-public] x86_64: improving default CFLAGS
by Andreas Radke 03 Apr '07

03 Apr '07

Am Sat, 31 Mar 2007 12:31:20 +0200 schrieb Andreas Radke <a.radke(a)arcor.de>: > http://bbs.archlinux.org/viewtopic.php?id=27139 > > after some discussions in this thread we want to change our default > compiler flags. we want to make use of the SSE3 extensions most x86_64 > cpus have. > > to not break backward compatibility for those few early cpus that lack > SSE3 extensions we want to do it with -mtune. this is how we want to > set it for the future: > > CFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe" > CXXFLAGS="-march=x86-64 -mtune=nocona -O2 -pipe" > > some testing is still required. i would like to put a modified version > of pacman to testing right after it has moved to current. when > everything is ok we would ask the pacman devs to change it to the > default makepkg.conf. > > please discuss. > > Andy > > (for i686 are also some speedups possible but that's not my task) > > _______________________________________________ > arch-dev-public mailing list > arch-dev-public(a)archlinux.org > http://archlinux.org/mailman/listinfo/arch-dev-public no opinions? fine to everybody? Andy

1 0