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

[arch-dev-public] Multilib on Archlinux x86_64
by Thomas Bächler 09 Jul '08

09 Jul '08

For a while now, there have been lib32-* packages in community. They sort of work for many applications, but have certain problems. This is what I don't like about them: - The naming convention (lib32-*) - The separate prefix (/opt/lib32) - The fact that the binaries are only copied from the 32 bit packages One can argue about the first two, but the third poses a real problem: Many libraries have hardcoded paths to plugin directories, like /usr/lib/gconv in glibc. If you run the glibc binary from arch32 in a 64 bit environment, glibc looks in /usr/lib/gconv for plugins, but only finds 64 bit binaries, which it can't load. Similar problems exist for many other libraries. Some can be worked around with environment variables, which is annoying, some can't. Thus, a clean solution is to rebuild all required binaries with the right paths included. I am proposing to build a new repository, let's call it [multilib] for now, which only exists on x86_64. I strictly want this to be separate from [extra], to keep our main repositories clean (however, extensions to [multilib] can still be placed in [community] IMO). GOALS: Fill in the missing pieces on x86_64: - flash - wine - possibility to install skype, teamspeak and google-earth from AUR Build all necessary libraries to install all of the above, but not more than that. APPROACH: The idea is to only install a 32 bit runtime, no complete toolchain. Packages are being built on a full 32 bit Archlinux system in the following way: The package is renamed from foo to foo-32bit (that's the naming convention I like most). All libraries are installed in /usr/lib32, only libraries are installed. It may be necessary to install exectuables, those should be put into /usr/bin in a way that they don't conflict with the normal 64 bit packages. If a library needs data files (for example in /usr/share), the package depends on the corresponding 64 bit package. makepkg must be fooled into marking the package as x86_64. This can be done by putting 'export CARCH="x86_64"' to the end of the build() function, but this is unclean (breaks with -L, possibly more). I am using a patched makepkg (not upstream yet) to introduce a 'destarch' keyword for the PKGBUILD (destarch='x86_64'). A package that can only exist in a 32 bit environment may put files into /usr/{bin,share,man,...} (but not include/), as there will never be conflicts with 64 bit packages (for example, wine will create /usr/{bin,share}/wine). Libraries must still be installed in /usr/lib32. To make all those packages work, glibc-32bit installs a symlink /lib/ld-linux.so.2 -> /usr/lib32/ld-linux.so.2. This is no problem because the 64 bit linker is called /lib/ld-linux-x86-64.so.2 (or /lib64/ld-linux-x86-64.so.2 in non-archlinux binaries). It also adds /usr/lib32 to /etc/ld.so.conf. To make ldd work, a separate ldd32 script can be installed. It would be even nicer if we could apply the following change to the ldd script in our core glibc package: < RTLDLIST="/lib/ld-linux-x86-64.so.2" > RTLDLIST="/lib/ld-linux-x86-64.so.2 /lib/ld-linux.so.2" That will make ldd work for both 32 and 64 bit binaries. PROGRESS I have built enough packages to install flash by just running 'pacman -Sy flashplugin' (some are already out of date though). I also built libgl and intel-dri to make OpenGL work on my Intel chip, other dri modules as well as the Nvidia/Ati versions of libGL.so are on my imaginary TODO list. I didn't build enough to try wine yet, and I was going to wait with this posting until then, but I am not sure when I will get to it. So this is it, the repository (in my public_html for now): [multilib] Server = http://dev.archlinux.org/~thomas/multilib I want to hear opinions about the idea and packages. Just try it by running pacman -Sy flashplugin. I didn't upload any PKGBUILDs yet, I want to clean them up first and see if and in what way the makepkg patches are accepted upstream. I can upload some examples though. SOME RANDOM DETAILS / TWEAKS: - pango and gtk2: Both pango and gtk2 install configuration files in /etc/ that contain paths to plugins. For the 32 bit packages, I had to change the hardcoded paths in the libraries and create separate configuration files for the 32 bit plugins. I also had to install 32 bit versions of the tools that generate these configuration files. - nspluginwrapper: nspluginwrapper is split into two packages: The nspluginviewer package contains only the 32 bit binaries and is built on a 32 bit system. The nspluginwrapper package contains the 64 bit binaries and is built on a 64 bit system. In order to properly install flash, nspluginwrapper has to create a separate file that contains the location of the real plugin. I had to patch nspluginwrapper so it is possible to manually specify the directory it puts the file in (/usr/lib/mozilla/plugins by default, but I needed ${startdir}/pkg/usr/lib/mozilla/plugins). The flash package is built on 64 bit, due to the lack of the npconfig program on the 32 bit system.

9 16

[arch-dev-public] Repository Maintenance 09-07-2008 06:00
by repomaint＠archlinux.org 09 Jul '08

09 Jul '08

Scan complete for extra (i686) at /home/ftp/extra/os/i686/ The following files are out of date They will be moved to /home/package-cleanup jdk-6u6-1-i686.pkg.tar.gz jre-6u6-1-i686.pkg.tar.gz

1 0

[arch-dev-public] Repository Maintenance 09-07-2008 03:00
by repomaint＠archlinux.org 09 Jul '08

09 Jul '08

Scan complete for extra (i686) at /home/ftp/extra/os/i686/ The following files are out of date They will be moved to /home/package-cleanup nmap-4.65-2-i686.pkg.tar.gz Scan complete for unstable (i686) at /home/ftp/unstable/os/i686/ The following files are in the repo but not the db They will be moved to /home/package-cleanup fvwm-crystal-3.0.4-1.pkg.tar.gz fvwm-crystal-3.0.6-1-i686.pkg.tar.gz Scan complete for unstable (x86_64) at /home/ftp/unstable/os/x86_64/ The following files are in the repo but not the db They will be moved to /home/package-cleanup fvwm-crystal-3.0.4-1.pkg.tar.gz fvwm-crystal-3.0.6-1-x86_64.pkg.tar.gz

1 0

[arch-dev-public] Repository Maintenance 09-07-2008 00:00
by repomaint＠archlinux.org 09 Jul '08

09 Jul '08

Scan complete for extra (x86_64) at /home/ftp/extra/os/x86_64/ The following files are out of date They will be moved to /home/package-cleanup jhead-2.4-1.pkg.tar.gz kino-1.2.0-1-x86_64.pkg.tar.gz latex2rtf-1.9.16-1.pkg.tar.gz Scan complete for testing (i686) at /home/ftp/testing/os/i686/ The following files are out of date They will be moved to /home/package-cleanup python24-2.4.5-2-i686.pkg.tar.gz

1 0

[arch-dev-public] Repository Maintenance 08-07-2008 21:00
by repomaint＠archlinux.org 09 Jul '08

09 Jul '08

Scan complete for extra (i686) at /home/ftp/extra/os/i686/ The following files are out of date They will be moved to /home/package-cleanup kino-1.2.0-1-i686.pkg.tar.gz latex2rtf-1.9.16-1.pkg.tar.gz Scan complete for unstable (i686) at /home/ftp/unstable/os/i686/ The following files are in the repo but not the db They will be moved to /home/package-cleanup fvwm-devel-2.5.26-1-i686.pkg.tar.gz Scan complete for unstable (x86_64) at /home/ftp/unstable/os/x86_64/ The following files are in the repo but not the db They will be moved to /home/package-cleanup fvwm-devel-2.5.26-1-x86_64.pkg.tar.gz Scan complete for testing (i686) at /home/ftp/testing/os/i686/ The following files are out of date They will be moved to /home/package-cleanup python-2.5.2-4-i686.pkg.tar.gz Scan complete for testing (x86_64) at /home/ftp/testing/os/x86_64/ The following files are out of date They will be moved to /home/package-cleanup kdebase-3.5.9-3-x86_64.pkg.tar.gz python-2.5.2-4-x86_64.pkg.tar.gz python24-2.4.5-2-x86_64.pkg.tar.gz

1 0

[arch-dev-public] Installer and i18n
by Hugo Doria 09 Jul '08

09 Jul '08

Hi everyone, I do not know what your guys think about i18n, but i'm trying to make the installer translatable and i am almost done. Although it seens to be working quite well, the installer still needs more tests. It is the first time that i put my hands in gettext and something can be wrong. A patch, the pot file and the setup can be found here: http://hdoria.archlinux-br.org/uploads/ As i said, i never used gettext before and i'm having some problems. I could not apply the gettext on messages that used dialog and variable (as in function _mkfs). For more I try, the pot file or the dialog were never correct. Can someone test the installer and give some tips of how fix these problems? Thanks. -- Hugo Doria

3 6

[arch-dev-public] Repository Maintenance 08-07-2008 18:00
by repomaint＠archlinux.org 09 Jul '08

09 Jul '08

Scan complete for extra (i686) at /home/ftp/extra/os/i686/ The following files are out of date They will be moved to /home/package-cleanup epiphany-2.22.2-2-i686.pkg.tar.gz jhead-2.4-1.pkg.tar.gz libxprintapputil-1.0.1-1.pkg.tar.gz libxprintutil-1.0.1-1.pkg.tar.gz

1 0

[arch-dev-public] Repository Maintenance 08-07-2008 15:00
by repomaint＠archlinux.org 09 Jul '08

09 Jul '08

Scan complete for extra (x86_64) at /home/ftp/extra/os/x86_64/ The following files are out of date They will be moved to /home/package-cleanup epiphany-2.22.2-2-x86_64.pkg.tar.gz libxprintapputil-1.0.1-1.pkg.tar.gz libxprintutil-1.0.1-1.pkg.tar.gz

1 0

[arch-dev-public] disowned pkgs
by K. Piche 09 Jul '08

09 Jul '08

All, I've dropped some pkgs for functional languages I know nothing about. Hopefully some of the new devs will pick 'em up. haskell: hugs98, nhc98 lisp: sbcl scheme: bigloo, drscheme Just a warning that the haskell stuff and sbcl don't build. k -- K. Piche <kpiche(a)rogers.com>

3 2

[arch-dev-public] Compiler issue with kernel and ext3
by Dan McGee 09 Jul '08

09 Jul '08

This is going to get us when we rebuild a kernel with gcc 4.3.1, so we should probably be aware: http://kerneltrap.org/Linux/Compiler_Oops https://bugzilla.redhat.com/show_bug.cgi?id=451068 Looks like 2.6.25.6 is built with gcc 4.3.0 so we are safe now. Should we patch gcc with the upstream fix? -Dan

3 5