- Arch-general - lists.archlinux.org

[arch-general] How can packages be "Newer than testing"??
by David C. Rankin 16 Jul '09

16 Jul '09

Listmates, On an i586 box with kde4 from testing, I am now unable to login. kdm starts to login, crashes and restarts. (detailed in a separate post) I was hoping that this would be fixed by an update or two, but upon checking this evening, I received the following: 19:27 supersff:~> pms -u :: Synchronizing package databases... kdemod-legacy is up to date testing is up to date kde-unstable is up to date core is up to date extra is up to date community is up to date archlinuxfr 25.2K 47.3K/s 00:00:01 [##################################################] 100% :: Starting full system upgrade... warning: akonadi: local (1.1.95-1) is newer than testing (1.1.2-2) warning: kdebase-runtime: local (4.2.95-1) is newer than testing (4.2.4-2) warning: kdelibs: local (4.2.95-1) is newer than testing (4.2.4-3) local database is up to date Huh??? I guess what it is saying is that akonadi, etc. are newer than the versions in "testing", but why would that message ever be generated with "kde-unstable" available? Also, could this also be a cause of the crashed kdm login on the i586 box? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

2 1

[arch-general] Perplexing libjpeg-related packaging issue
by bardo 15 Jul '09

15 Jul '09

Hi guys. Yesterday I rebuild mldonkey since it depended on libjpeg. On x86_64 there are no problems, and everything works as expected; this is not the case for i686, where there's a strange problem: [root@plafone ~]# ldd /usr/bin/mldonkey | grep libjpeg libjpeg.so.7 => /usr/lib/libjpeg.so.7 (0xb7f1c000) libjpeg.so.62 => not found The package was created with makechrootpkg in a clean chroot. How is it even possible to link with two different versions of the same library? And where did it get the old version, since it didn't exist in the chroot? I'm trying to rebuild a sane version now, but if anybody has a clue I'd be happy to hear it :P Corrado

3 10

[arch-general] 32bit chroot in 64bit guest
by bardo 15 Jul '09

15 Jul '09

I've got some packages to upgrade for both arches and I was wondering if it's possible to run a non-native chroot and stop resorting to virtual machines. Given that i686 binaries should be runnable on an x86_64 guest, i just used mkarchroot with an i686-configured pacman.conf, but I get a sudo error when it tries to run makepkg from makechrootpkg. makechrootpkg launches sudo only once, at line 202, and this is the full command: sudo -u nobody makepkg $MAKEPKG_ARGS || touch BUILD_FAILED Now, why require installing sudo in the chroot (standard procedure) if the 'sudo' and 'makepkg' commangs used are *outside* the chroot? Shouldn't they be run through 'mkarchroot -r' to allow cross compilation? Or am I missing something (as usual)? bardo

8 8

[arch-general] Mirror not updating
by David Rosenstrauch 14 Jul '09

14 Jul '09

Anyone have contact info for the rit.edu mirror? It doesn't appear to have been updated since June 30. Thanks, DR

13 25

[arch-general] [AUR-Server] lastsync file on aur.archlinux.org
by Gerhard Brauer 14 Jul '09

14 Jul '09

Hi, since 3-4 days i notice on mirrorchecking that for community repos the status file for indicate the last sync of the mirror switch temporary on some mirrors between actual(synced) and a out-of-sync period from ~16 days. It seems that only mirrors are affected which snyc more than once a day and when theys sync from rsync.archlinux.org. So somewhat "switches" the lastsync file (which is automatically generated by cron each hour on gerolde for all repos). I don't know how or if aur.archlinux.org and gerolde get synced, but please: could one admin look if on aur.al.org is in the community repos a file named lastsync? If you, please remove this so it don't overwrite the generated one on gerolde. If you look currently on: http://users.archlinux.de/~gerbra/mirrorcheck.html you could see several mirror with comminity outdated. And maybe on the next check they are all synced again and overnext check they are bad once more. Short (Sorry for my bad english <g>): If you found a lastsync file on aur.al.org in the repos - please remove it... Gerhard "gerbra"

2 1

[arch-general] About user signoffs
by Denis A. Altoé Falqueto 14 Jul '09

14 Jul '09

Hi all. I would like to know how can we, common and lay users, give signoffs on the packages that we use in testing. I know that arch-public-dev is read only for non developpers and I would like to help too. Can we send the signoffs in this list? Thanks in advance. -- ------------------------------------------- Denis A. Altoe Falqueto ------------------------------------------- Milton Berle - "If opportunity doesn't knock, build a door." - http://www.brainyquote.com/quotes/authors/m/milton_berle.html

3 6

[arch-general] libreadline.so issues
by Samuel Baldwin 14 Jul '09

14 Jul '09

The other day I tried to install K3B on my x86_64 laptop, and midway through it I got some errors, so I ran pacman -Sy k3b and it got about midway through before I started getting error messages about the computer not being able to find libreadline.so. I use zsh as my shell for my normal user, but bash for root, and I couldn't login as root anymore. I shutdown the machine (sudo worked, thankfully, but not sudo -s), but now when I boot I get errors when it tries to enter runlevel 3 (I haven't played with any runlevel stuff): /bin/bash: error while loading shared libraries: libreadline.so.5: cannot open shared object file: No such file or directory INIT: Entering runlvel: 3 /bin/bash: error while loading shared libraries: libreadline.so.5: cannot open shared object file: No such file or directory I could just wipe / and start over, but I'd prefer to find a better way to deal with this. I haven't installed anything on my desktop (x86_64 as well) for fear this is will trash that machine as well. Any suggestions? -- Samuel 'Shardz' Baldwin - staticfree.info/~samuel

8 12

[arch-general] AUR Search
by Andrei Thorp 13 Jul '09

13 Jul '09

Hello there! Today, I'd like to be all complainy about the AUR search feature. I haven't really looked around, but are there plans to improve it? Or is the solution just "use google with site://"? It seems to be kind of bad at finding stuff. Some examples: - Can't search by description (well, it does search by description by default, but it's not in the advanced options anywhere) - Can't really do any decent multi-word searches afaik. To take an example from the other argument thread, try searching for "java gstreamer". It finds neither gstreamer-java nor java-gstreamer. It actually finds nothing at all. - Similarly, wildcards seem to not work. "java*gstreamer" has no results. - It seems to not even do exact matches first. For example, search for my package, "sup". There is a package in AUR that's exactly named "sup", but if you search for that, you get 658 results, sorted alphabetically! - Which reminds me, what about sorting by relevance somehow? Perhaps sort by a weighting of votes, age, downloads, etc. I'm sorry if I'm bringing this up as someone's already writing improvements for AUR and this is just a waste of time :) Anyway, thanks! -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) <miguel> any new sendmail hole I have to fix before going on vacations? -- Seen on #Linux

7 9

[arch-general] [signoff] iwlwifi-4965-ucode 228.61.2.24-1
by Thomas Bächler 13 Jul '09

13 Jul '09

New upstream release, please test and sign off. I also remove the ABI version 1 ucode, which should not be needed anymore with recent kernels. This is the original E-Mail from the Intel wifi mailing list: Version 228.61.2.24 of uCode for Intel Wireless WiFi Link 4965AGN is now available for download from http://intellinuxwireless.org/?n=Downloads Changes: -- More graceful handling of Rx hangs (NMI) -- More reliable scanning -- Wait 10 seconds after association before power down -- Reset receiver via retune after missing beacons -- Disable TGK measurement when receiving packet -- More reliable Tx of ACK/BA/CTS Reinette

3 2

[arch-general] SIGSEGV in getopt, libc-problem?
by clemens fischer 13 Jul '09

13 Jul '09

For a few days now I noticed some programs not working, like "lzma" or "xz" from the "xz-utils". They segfault and "xz --help" says: $ /usr/bin/xz --help /usr/bin/xz: unrecognized option '--' /usr/bin/xz: Try `/usr/bin/xz --help' for more information. So I went to compile the original source, and the gdb(1) backtrace shows them to die in "_getopt_internal()". I thought my system to be inconsistent somehow, because a friend reports these programs working. I already re-installed the package. It gets its libs from archlinux package locations: $ ldd /usr/bin/xz linux-gate.so.1 => (0xb80a4000) liblzma.so.0 => /usr/lib/liblzma.so.0 (0xb806e000) libpthread.so.0 => /lib/libpthread.so.0 (0xb8056000) libc.so.6 => /lib/libc.so.6 (0xb7f0e000) /lib/ld-linux.so.2 (0xb80a5000) It is possibly a problem with getopt_long(). Most programs work(!), ie. I only noticed this with "xz", "lzma" and friends, both the packages and hand-compiled versions. I use the bash commandline all the time with many programs calling getopt_long(), they all work. Backtrace: (gdb) run Starting program: /home/src/bulk/lzma/xz/src/xz/xz Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Reading symbols from system-supplied DSO at 0xb8069000...(no debugging symbols found)...done. Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Reading symbols from /lib/libc.so.6... (no debugging symbols found)...done. [New Thread 0xb7ef36c0 (LWP 32015)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7ef36c0 (LWP 32015)] 0xb7fa84dc in _getopt_internal_r () from /lib/libc.so.6 (gdb) bt incomplete CFI data; unspecified registers (e.g., eax) at 0xb7fa838a...#0 0xb7fa84dc in _getopt_internal_r () from /lib/libc.so.6 #1 0xb7fa946e in _getopt_internal () from /lib/libc.so.6 #2 0xb7fa96b9 in getopt_long () from /lib/libc.so.6 #3 0x0804980d in parse_real () #4 0x08049a07 in args_parse () #5 0x0804b18e in main () $ pac o /lib/libc.so.6 /lib/libc.so.6 is owned by glibc 2.10.1-2 $ ll /lib/libc[.-]* 393476 -rwxr-xr-x 1 root root ? 1.6M 2009-05-23 05:54 /lib/libc-2.10.1.so* 393470 lrwxrwxrwx 1 root root ? 14 2009-05-23 05:54 /lib/libc.so.6 -> libc-2.10.1.so* Did somebody else observe something like this? I already searched the web ("_getopt_internal_r SIGSEGV"), but there's nothing specific, although other programs had problems like this years ago. Any pointers appreciated. clemens

5 9