- Arch-ports - lists.archlinux.org

[arch-ports] [arch64] rm /usr/lib/libdbus-1.so.1
by Andreas Radke 28 Apr '06

28 Apr '06

if you have set that link from /usr/lib/libdbus-1.so -> libdbus-1.so.2.0.0 to get keep some apps running after dbus update plaese everybody remove it now. it will cause some trouble. rm /usr/lib/libdbus-1.so.1 please tell us broken packages so we can rebuild them. AndyRTR

2 4

[arch-ports] [arch64] udev broken
by Pierre Schmitz 27 Apr '06

27 Apr '06

Hello, the udev-package is incomplete. e.g. firmware_helper is missing. I grabbed current udev-PKGBUILD from arch32 und compiled it. Now udev loads firmware. Pierre

1 0

Re: [arch-ports] amarok svn in testing [Arch64]
by Varun Acharya 25 Apr '06

25 Apr '06

Strat wrote: > Hy ganja_guru > > Good work! I am using it right now. > Is there a reason for not having iriver support? > > -- > Strat > > > I want to keep things simple as of now cause we've had a lot of problems with amarok on Arch64. I just tried amarok-1.4beta3 and its not as stable as the svn build in testing, so I'm leaving the testing build as it is. I'll explicitly specify iRiver support in the next build. (iRiver support may be default, so try installing the package "ifp-line" and see if it works.) P.S- You need libgpod for iPod support. ganja_guru

1 0

[arch-ports] amarok svn in testing [Arch64]
by ganja.guru 24 Apr '06

24 Apr '06

Hi everyone, Up until now, we've had issues with older versions of amarok (even 1.3.9), but the new svn build I've uploaded to testing seems to work quite well. # pacman -S amarok-base-svn amarok-engine-xine-svn As of now, there is no arts/gst engine, and no ipod/iriver support. If people still have problems with this svn build I'll keep building new svn releases till basic issues are sorted out. Thanks, Varun "ganja_guru" Acharya

1 0

[arch-ports] [arch64] makeworld does a great job again - don't build updates!
by Andreas Radke 19 Apr '06

19 Apr '06

I've started again a makeworld run and it does the job very well. Tons of updates now I have to check. I'll have to update svn and look if each package is ok. Then I will upload all the stuff. So there's no need to build updates right now. In one or two days I think I can finish it. Then our ToDo list should be much shorter. AndyRTR

1 1

[arch-ports] [Arch64 - announce] final Arch64 "04.2006" ISOs available
by Andreas Radke 12 Apr '06

12 Apr '06

1 0

[arch-ports] Archlinux/PPC suffering
by Alexander Baldeck 08 Apr '06

08 Apr '06

Hey list, as you may have noticed, Archlinux/PPC does not get as much attention as Archlinux/64 gets. Now that Benoit quit for personal reasons, we are short on manpower to keep the work up. Nevertheless at least I will continue to work on the port but it will never be as usable as any other. This occasion brings me to the fact that I need to ask for help. We have several open positions I have in mind for give away. So the call goes out to anyone that uses Archlinux/PPC, I know at least 15 people update daily. ;) If you are interested, please go to http://archlinuxppc.org and read the topmost news. It explains two of the positions that are open at the moment. You would rather like to talk to someone? Don't hesitate and contact me via email. Best regards, Alex / kth5

3 4

[arch-ports] [Arch64] amd_agp driver and via_agp driver
by Strat 08 Apr '06

08 Apr '06

Hy all I am building the xf86-video-openchrome driver and I discovered that the ammd64_agp and the via_agp driver where not included in defaut kernel package (neither 2.6.16 or 2.6.15). As they are included in arch 32 I wonder if there is a reason for that. Also, if someone is intersted in the openchrome PKGBUILD, I can post it here. -- Strat

2 3

[arch-ports] [Arch64] Kernel26 package
by Strat 07 Apr '06

07 Apr '06

Hello again I am trying to build the kernel26 package from the svn repo but the mmconfig-2.6.16.patch file is missing. Am I using the right svn server (http://arch64.org/svn/trunk/current/) or is there another way to get the kernel26 PKGBUILD for arch 64 thanks -- Strat

3 4

[arch-ports] developing the (arch64) port
by Andreas Radke 05 Apr '06

05 Apr '06

On the port side: - All arch64 developers should read this: http://dev.gentoo.org/~plasmaroo/devmanual/archs/amd64/ "Applying |-fPIC| on all objects will slow down the binaries in a drastic way." So I will drop it again from the default CFLAGS. A new pacman package is needed. I'll do this later when we are sure how the future development will be. - So we need to review all packages for sorting out packages that will build *.so files. That's how I understand the Gentoo rule. Am I right? We can use a script crawling through /* for *.so | pacman -Qo to get the packages we need to patch with CFLAGS="$CFLAGS -fPIC" ??? Who can do this first? Then check the result against Gentoo and Fedora. - Then a recompile of the whole distro will be needed. makeworld will be my friend :) I hope this will solve our last problems with the iso(mkfs.ext3, lilo, grub) What I expect from the official archlinux developers side: - Jason, I've come to the conclusion that a common cvs and common pkgbuilds are not good for getting the ports accepted. It would take us a long time until i686 developers will accept bloated pkgbuilds and preparing the "arch" tag would take its time. I still don't know why we should need the "arch" tag. I think it would be only to declare if the pkgbuild builds on a certain architecture. But as long as the packages are build by a packager and not automatically we don't really need it. - I disagree to your opinion that i686 packagers will ever be able to build packages for the ports using pacbuild. Every package needs a check and real installation on the destination architecture before you can upload it to the repos. So you always will need to have a few packagers more for each port to check packages and play with bugfixes. - So I would prefer a separate svn/cvs for each port. Every port should be free to decide what packages to include into the port. This may not be as elegant as common cvs+pkgbuild but it's much easier to handle. - No changes would be need to pacman/makepkg. Less work and less learning for all - more KISS for everyone. And it will not take more space on the servers or something like that. So setup a separate svn for arch64 and create new subrepos for x86_64 and give a few of us access - we could start tomorrow! I know some arch64 devs dying to do real productiv stuff. Otherwise as I told you more packagers will leave the port. AndyRTR

4 7