- Arch-general - lists.archlinux.org

[arch-general] The need for /lib64 - testing please
by Allan McRae 01 Jul '11

01 Jul '11

Hi all, I was looking at the /lib64 folder and wondering what it is really needed for... It just seems clutter to me on a pure x86_64 system (or even with a multilib in lib32 folders like we have). As far as I can tell, most things are perfectly fine without that folder and its two symlinks. I would like some help testing removing this so I can get an idea of what issues people run into. There is bound to be some software that makes assumptions about /lib64 in its installation and I would like to know (a) how widespread that issue is and (b) how hard it is to work around. If you want to try it out, just remove the /lib64 folder (after making sure it only has symlinks to ld-2.13.so and ld-linux-x86-64.so.2 in it. Run your system as usual for a while and report any issues you come across. Thanks, Allan

5 4

Re: [arch-general] [arch-dev-public] The need for /lib64 - testing please
by Emmanuel Benisty 01 Jul '11

01 Jul '11

On Fri, Jul 1, 2011 at 3:10 PM, Thomas Bächler <thomas(a)archlinux.org> wrote: > Am 01.07.2011 06:48, schrieb Allan McRae: >> Hi all, >> >> I was looking at the /lib64 folder and wondering what it is really >> needed for... It just seems clutter to me on a pure x86_64 system (or >> even with a multilib in lib32 folders like we have). As far as I can >> tell, most things are perfectly fine without that folder and its two >> symlinks. >> >> I would like some help testing removing this so I can get an idea of >> what issues people run into. There is bound to be some software that >> makes assumptions about /lib64 in its installation and I would like to >> know (a) how widespread that issue is and (b) how hard it is to work >> around. >> >> If you want to try it out, just remove the /lib64 folder (after making >> sure it only has symlinks to ld-2.13.so and ld-linux-x86-64.so.2 in it. >> Run your system as usual for a while and report any issues you come across. > > First of all, /lib64/ld-2.14.so is unnecessary, only > /lib/ld-linux-x86-64.so must exist. > > The problem is quite simple: The ELF binary hardcodes the path to the > interpreter (which is the linker). Binaries that were compiled for other > distributions or generic binaries distributed by third parties will have > the path "/lib64/ld-linux-x86-64.so.2" hardcoded as their interpreter - > I don't know where this convention comes from and why they didn't choose > /lib (choosing /lib would be no problem, as the file names for the 32 > and 64 bit linkers differ, the former is ld-linux.so.2). Just FTR, it most likely comes from http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64

2 1

[arch-general] [signoff] mkinitcpio 0.7-1, device-mapper/lvm2 2.02.85-3, dmraid 1.0.0.rc16.3-2, mdadm 3.2.2-2, v86d 0.1.10-2
by Thomas Bächler 01 Jul '11

01 Jul '11

This is a huge release and should stay in testing for a while. I want to point out two significant changes: 1) We now have a build() function instead of an install() function - the latter was an unfortunate conflict with the install utility. The hooks in the repository have been adjusted, but backward-compatibility code is in place (a deprecation warning will be printed). All these packages have conflicts=(mkinitcpio<0.7). 2) We now use bsdcpio instead of gen_init_cpio. This obsoletes the gen_init_cpio package and adds a dependency on libarchive. This also speeds up the image generation considerably. Other changes include massive cleanups and fixes, code refactoring, and changes that should finally make the -b (basedir) option useful. Please test and sign off. Here comes the full shortlog: Dave Reisner (52): init: don't attempt modprobe if $MODULES is empty mkinitcpio.conf: s/raid/mdadm/ mkinitcpio: deprecate install() in install hooks dmesg: remove install/hook functions: cleanup and refactor add_binary functions: refactor add_module functions: remove add_device functions: remove add_symlink2 use bsdcpio to create images functions: refactor add_file functions: document hook API mkinitcpio.conf: note implicit support for lzop mkinitcpio: use simple PEs instead of externals mkinitcpio: allow specifying kernel ver as path to image lsinitcpio: new utility to dump contents of images Makefile: refactor and simplify mkinitcpio: bashify preset build loop use consistent vim modelines declare all variables in mkinitcpio mkinitcpio: refactor and bashify early path calculations declare SAVELIST, QUIET, SHOW_AUTOMODS as faux booleans mkinitcpio: remove cruft in getopts loop overhaul output, introducing color functions: refactor add_symlink functions: simplify parse_hook mkinitcpio: bashification, part 1/2 mkinitcpio: bashification, part 2/2 add -t option to specify alternate build directory install/keymap: refactor and bashify mkinitcpio: declare usage as a heredoc remove support for -m to add a startup message install/base: cleanup and simplify functions: remove get_module_name init: declare PATH, remove absolute paths init: remove unnecessary variable declarations mkinitcpio: allow overriding the compression method mkinitcpio: only show usage on request mkinitcpio.5: alphabetize options for easier nav README: update copyright year, add self as author mkinitcpio: catch errors in parse_hook add a PKGBUILD for easier testing from the repo mkinitcpio: allow absolute paths to preset files install/{sata,pata,scsi}: cleanup and simplify properly support $BASEDIR install/autodetect: refactor and simplify hook functions: support $BASEDIR in modprobe Makefile: the Makefile itself is a dep for the manpage functions: add missing 'command' before install functions: s/basedir/BASEDIR/ functions: fix pathing issue with $BASEDIR install/base: use private API call to add config mkinitcpio: fix resolution issues with RTLD Eric Bélanger (1): Added usbinput to default hooks (implements FS#19328) Gerardo Exequiel Pozzi (3): Fix some install hooks due recent change in all_modules() Add missing /etc/bash_completion.d in Makefile Add asciidoc as makedepends in private PKGBUILD. Sebastien Luttringer (6): Add bash completion to mkinitcpio Fix printing of bash usage when asking for a bad hook Print pretty message if no help is defined in hook Use error function instead of echo Add lsinitcpio bash completion Use _get_comp_words_by_ref in bash completion Thomas Bächler (7): Merge branch 'master' of https://github.com/seblu/arch-mkinitcpio into working Remove old '-m' option from bash completion. emove old '-a' option from bash completion and fix '-s' option. Merge branch 'working' Add .gitignore file install/keymap: fix installation ($buildroot -> $BUILDROOT) Release version 0.7

5 6

[arch-general] Warning - Thunderbird 5 Breaks Access to pop accounts
by David C. Rankin 30 Jun '11

30 Jun '11

Guys, This may just be on my box, but after update to thunderbird 5, all access to new messages on pop accounts broke. The error message said: Please send PASS command. It looks like the mailer wasn't responding properly to the server communications. I rebooted, I tried everything. Finally I had to downgrade to thunderbird-3.1.11-1 to restore access to my pop accounts. Anyone else see this? -- David C. Rankin, J.D.,P.E.

6 13

[arch-general] Synaptics Gesture Suite on Arch?
by Karol Babioch 30 Jun '11

30 Jun '11

Hi, I've got a Synaptics Touchpad capable of recognizing gestures. After using this quite heavily on Windows I got used to it and would like to have it available on Linux also ;). After some research I found that there is a Synaptics Gesture Suite for Linux ([1]), which looks quite useful. However there is no direct download available, and it seems that you have to be some sort of OEM in order to get it. I couldn't find any package in the repositories, so I'm wondering whether anyone knows more about it. Best regards, Karol Babioch [1] http://www.synaptics.com/solutions/technology/gestures/touchpad-linux

5 4

[arch-general] python2-zope-interface - failed to commit transaction (conflicting files)
by David C. Rankin 29 Jun '11

29 Jun '11

Just FYI, This may be my fault, but on each box I have updated, I get the following error: (13/13) checking for file conflicts [#######################################] 100% error: failed to commit transaction (conflicting files) python2-zope-interface: /usr/lib/python2.7/site-packages/zope.interface-3.6.3-py2.7.egg-info/ exists in filesystem Errors occurred, no packages were upgraded. I just -f'ed it... -- David C. Rankin, J.D.,P.E.

2 2

[arch-general] Java 7 is now in [community-testing] and needs testing.
by Thomas Dziedzic 29 Jun '11

29 Jun '11

Hi, Java 7 is getting released on July 28th so I thought it would be a good time to let users test it out. I have just pushed jre/jdk 7 build 147 into [community-testing] so that users can have a month in advance to report bugs, and notify upstream projects if they are incompatible with java 7. You should be able to install jre/jdk 7 without the need to enable any of the testing repos. I have tested it on my computer with a couple of browser games which seem to work fine. The only program that doesn't work with Java 7 afaik is minecraft, the specific problem can be tracked here: http://getsatisfaction.com/mojang/topics/minecraft_doesnt_work_with_java_7 Hopefully we can have enough users complaining that the devs will take notice. A summary of the changes that come with Java 7: http://openjdk.java.net/projects/jdk7/features/ Bugs that are not packaging bugs should be submitted to http://bugreport.sun.com/bugreport/ The Java 7 feedback forum is located at http://www.java.net/forums/jdk/java-se-snapshots-project-feedback?force=259 Cheers!

5 9

[arch-general] KDE 4.6.4 when?
by Lukáš Jirkovský 29 Jun '11

29 Jun '11

Hello, I'd like to ask what is keeping KDE 4.6.4 from moving to [extra]? I'm using it for some time without any problems, neither I can find any bug report specific for 4.6.4 Have a nice day, Lukas

4 5

Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.39.2-1
by David C. Rankin 28 Jun '11

28 Jun '11

On 06/27/2011 03:10 PM, Thomas Bächler wrote: > Upstream update, please sign off. > responding on the general list: Signoff - both (2-x86_64, 4-x86) -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] Post-processing of packages?
by Magnus Therning 28 Jun '11

28 Jun '11

I'm in the situation where some of the information that I really would like to have in the pkgver/pkgrel isn't available until after the build step. Also, some information about the dependencies is clearly much easier to extract during the build process (due to the tools I have available to me). So, in short I'd like to massage the typically static values usually found in the head of the PKGBUILD as the build progresses. So, is there some way of either modifying this information during the PKGBUILD, or doing some post-processing from the PKGBUILD on the built package (like processing of the .PKGINFO)? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

1 0