- Arch-ports - lists.archlinux.org

[arch-ports] ArchPPC mirrors need some work?
by Matthew William Cox 23 Jun '07

23 Jun '07

Hello, There seems to a problem on the archppc mirrors. pacman -Syu has been trying to pull two nonexistent packages, and this of course causes pacman to abort. The problem packages are: transset-20050711-3 xpdf-3.01_pl2-8 Both of which do not exist on the mirrors (www.archlinuxppc.org). Think that we need to run gensync. Matthew Cox

2 2

Re: [arch-ports] archlinux-ppc on my mini-ppc
by sacarde 21 May '07

21 May '07

Alle lunedì 21 maggio 2007, hai scritto: > I guess you aren't yet chrooted and pacman tries to install the kernel > into the ramdisk. no no I am sure in chroot I have run: ln -s /proc/mounts /etc/mtab and now pacman work OK thankyou

1 0

[arch-ports] archlinux-ppc on my mini-ppc
by sacarde 21 May '07

21 May '07

hi, I try to install archlinux-ppc on my mini-ppc /dev/hda4 (with iso 28/8/2006) I have kubuntu already running on /dev/hda3 OK I have this yaboot.conf: boot=/dev/hda2 device=/pci@f4000000/ata-6@d/disk@0: partition=3 root=/dev/hda3 timeout=50 install=/usr/lib/yaboot/yaboot magicboot=/usr/lib/yaboot/ofboot enablecdboot enableofboot image=/boot/vmlinux label=Linux read-only initrd=/boot/initrd.img image=hd:4,/boot/vmlinux26 label=arch root=/dev/hda4 partition=4 initrd=/boot/kernel26.img read-only but arch load kernel and then have kernel-panic...... fstab seems OK can you help me ? thankyou

2 3

[arch-ports] going to start a new ArchLinux?
by Andreas Radke 10 May '07

10 May '07

congratulation. we have won! our gcc-gcj is broken due to a major feature addon the developer made right before he orphaned it. we (Hussam who does i686 rc packages and me) are no more able to build OpenOffice.org standing a few days before the 2.2.1 release candidate. this is not to blaim that developer but for any other developer and all users not using the testing repo. but this is only the peak of all the chaotic "development" as we call it. untill now we used have one ArchLinux tree now having two architectures officially supported (i686+x86_64) based on simplicity and pacman repo manager as its basic parts. Having the latest stable package version was the goal. we have put more and more packages into the current+extra repos. important packages we want to test for a while in our "testing" repos. sadly it's not worth the name. almost nobody uses it. even not all developers as highly recommended. continously we put packages with major issues into the stable repos. we from the x86_64 port are only 2 guys rebuilding and maintaining ~2500 packages. we have not the power and possebility to change anything important. from my point of view we have passed a point where this concept won't work anymore. we have a poor developement infrastructure compared to other distributions. we slow down our package release process due to many developers beeing busy with other things (real life and more). but then we force us to push things very quickly into the repos to satisfy our own old goals. well. not more with me beeing responsible for the Arch x86_64 port. some ways are possible: 1) improve the infrastructure and increase the manpower of developers and packagers for all supported dramatically. we are trying that for over a year now without any noticable real success. 2) dramatically lower the work(=less binary packages) for the devs to give them time for making packages of a better quality. doubt came up as Arch should remain a supported binary distribution in most parts. 3) new goals for ArchLinux: accept to have not well tested packages when we want to keep the update speed or accept a lower speed on update to get new packages better tested. 4) split the goals we have! let's have one more conservative stable rolling rellease tree for higher quality and one on the bleading edge front accepting it might break sometime. I've brought it up several times: i'm no more willing to be the dump rebuild monkey. wha i suggest is a mix of 3) and 4). there is only one working other distribution based on pacman out claiming having a stable tree. I've talked to several devs and users and they can imagine that a stable distribution by ArchLinux can become a successor. I'm going to start a new project based on what we now call ArchLinux for a new more stable but easy to maintain distribution. I would like to do this for ArchLinux. But I have also no problem if you totally dislike that and say it's a NoGo under the name of ArchLinux. Everybody who wants to help out or has something to say may post here or contact me on one of my instant messenger accounts you find in the forum. AndyRTR

5 9

[arch-ports] New entry
by Alessandro Calorì 06 May '07

06 May '07

Hi folks, my name is Alessandro, I'm an Italian student of computer sience and part-time employee of a company which designs and builds control panels for industry plants and develops the relative software. I'm a linux enthusiast. I would like to help the Arch64 project in porting packages from i686 to x86-64 platforms. How can I do that? Do I need to be a TU? Now I'm just translating some wiki docs to italian but I would like to be more involved in this project. Bye and thank you all, Alessandro.

2 2

[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 26 Apr '07

26 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 04 Apr '07

04 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