- Arch-general - lists.archlinux.org

[arch-general] VirtualBox_bin 3.12 - slow system freeze on i686, OK on x86_64
by David C. Rankin 12 Dec '10

12 Dec '10

Guys, just a heads up for those that use virtualbox_bin from AUR: I experienced a system freeze problem on a dell P4 box with VirtualBox-3.2.12 causing the machine to slowly freeze, become unresponsive, then hardlock. WinXP (guest) starts fine, but then it will freeze, followed by the kde taskbar, and then a minute or two later, the mouse and keyboard freeze and the box is locked. (hard reset required) I went through this lockup process twice to make sure. Downgrading to VirtualBox-3.2.10 solved the problem for me. Prior to updating the i686 box, I did another VirtualBox-3.2.12 upgrade on a x86_64 box (XP guest as well), and all is working well. So it looks like it may be some issue or memory leak that is killing the i686 package. I (and others) have dropped notes with the AUR package. -- 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 2

Re: [arch-general] [arch-dev-public] glibc and minimum kernel version
by Matthew Monaco 11 Dec '10

11 Dec '10

On 12/11/2010 10:49 AM, Allan McRae wrote: > Hi, > > I am in the progress of updating the toolchain and thought it time to review > what our minimum required kernel version is for glibc. > > For those that do not know, assuming a newer kernel allows glibc to have less > workarounds compiled in. So it may be advantagous to have a more recent version > as the minimum required. This comes at the obvious cost of not having support > for older kernels so a tradeoff is needed... When we discussed this 18 months > ago, it was decided 2.6.18 was appropraite then, but much has changed since. > > I am going to suggest that we follow the oldest longterm support kernel. That > would now be the 2.6.27.x series, which has been around for over two years. > > That might be being overly bold, so feel free to point out how much such an > update would break... and suggest an alternative minimum. > > Allan > The workarounds obviously make maintainence a little more difficult, but is there a performance hit too? Could a glibc and glibc-legacy/glibc-compat type of thing be a viable solution? Then the question would be what kernel defines the line between the two glibc packages (probably -lts would be good).

1 0

[arch-general] perl 5.12.2 anytime soon? or just going to wait for 5.12.3 or 5.14.1
by Caleb Cushing 11 Dec '10

11 Dec '10

perl 5.12.2 came out at the end of august... I'm just wondering if we'll be getting it... 5.12.3 should come out... I'd rather never see a stable 5.14.0 because 5.14.1 should follow a month later... and given the current speed of updated perls in arch... -- Caleb Cushing http://xenoterracide.com

1 1

[arch-general] [signoff] udev-164-3
by Tobias Powalowski 11 Dec '10

11 Dec '10

Hi guys, - fixed libusb-compat depend Seems I forgot to add it to the depend line. Please signoff both arches to fix this missing depend. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

3 2

[arch-general] Setuptools broken?
by Norbert Zeh 10 Dec '10

10 Dec '10

Hi folks, With the python upgrade from 2.7 to 3.1, I ran into the following snag. gitosis from AUR depends on python and setuptools. Now, python = python3.1 now and setuptools installs in the python2.7 library tree. This was easy enough to fix, by simply replacing python with python2 in the gitosis PKGBUILD. However, I would expect that python2 will disappear completely somewhere down the road. What then? Moreover, being a purist, I would like to avoid having two python versions installed on my machine. So what's the deal with python3.1 and setuptools? Is the procedure for installing python packages different under 3.1 than under the old 2.x series, and there simply are no setuptools any more? If that's the case, I guess it's the responsibility of package maintainers to migrate to the setup used in python3.1. If setuptools is still what is needed in python3.1, shouldn't there now be two packages setuptools and setuptools2 that install in the library trees of python3.1 and python2.7, respectively? (I'm happy to file a bug report if this is indeed a bug.) Cheers, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

33 64

[arch-general] State of the Repositories
by keenerd 09 Dec '10

09 Dec '10

If you have not played with Expac yet, you should! It is a brilliant program. Here is a small example of it in action. Feel free to tease me for the overuse of pipes. > find /var/abs -name 'PKGBUILD' | wc -l 3976 > grep -rc '|| return 1$' /var/abs | cut -d ':' -f 2 | awk '{s+=$1} END {print s}' 5929 > find /var/abs -name 'PKGBUILD' | xargs -n 1 -I '{}' grep -l '|| return 1$' '{}' | cut -d '/' -f 5 | sort > return_one > wc -l return_one 1923 return_one Half of the repo is littered with '|| return 1'. We've been assured it will be phased out as packages are updated. Sometimes this happens, sometimes not. Makepkg was fixed in 0.3.4, released on 2010-06-16. What packages have been updated since then? > expac -S -t '%F' '%b %n' $(pacman -Ssq) | sort > releases > awk '/2010-06-16/,EOF' < releases | cut -d ' ' -f 2 > updated > wc -l updated 3276 updated This is really depressing. Out of 3973 packages, 3276 have been updated in the last six months. No matter how you draw the Venn diagram, there is a large set of packages in the middle that must both contain '|| return 1' and have been recently updated. So which packages are they? > comm -12 return_one updated > lazy_packages > wc -l lazy_packages 590 lazy_packages Let's make a graph to show how bad it continues to be. > expac -S -t '%Y-%m' '%b' $(cat return_one) | sort | uniq -c | sed 's/^ *//' > return_one_releases http://kmkeen.com/tmp/return-one-releases.png If packages were actually cleaned up when updated, the red line would be flat on zero. Instead, 50-100 packages with 'return 1' are released every month. (And yes, the oldest surviving package is almost three years old. Happy birthday perl-passwd-md5, if you make it another month.) And finally > expac -S "%p" $(cat lazy_packages) | sort | uniq -Kyle http://kmkeen.com

4 3

Re: [arch-general] [arch-dev-public] nilfs-utils moving in core
by Heiko Baums 08 Dec '10

08 Dec '10

Am Tue, 07 Dec 2010 16:26:00 +0100 schrieb Pierre Schmitz <pierre(a)archlinux.de>: > I second this. If the reason for moving a package to core is that the > installer cannot handle it otherwise the installer needs to be fixed. The question is not that the installer can't handle it if it's not in [core]. The question is that if the installer creates a filesystem on the harddisk the appropriate tools need to be installed on the system, too. And this is only possible if those packages are in [core] because the core iso only contains the [core] repo and not [extra] and [community]. Also the netinstall iso can only install from [core] as far as I know. So if AIF supports nilfs or another filesystem, those tools have to be moved to [core]. > That's why I would vote against moving it to core. I'd even say we > should have a look at those packages in core with low usage and see if > we should move them to extra. There are already packages for which we > don't get any sign-offs which shows that those are no longer needed to > be in core. That's definitely not the definition of [core]. [core] is not for supporting the most used and most popular packages. [core] is for providing system relevant packages which are necessary to build a minimal system. And it's not the dev's task to decide how a user wants to partition and format his harddisk. If it's done like you're suggesting than you would force a user to only format his harddisk with e.g. ext4, because you think that ext4 is the one and only and most popular filesystem and every other filesystem has to be moved to [extra], because they are not necessary or not as popular as ext4. It's all about choice - the user's, not the dev's choice. Instead every filesystem - probably except for dosfsutils - has to be moved to [core] and be supported by AIF, because a filesystem is the most basic and necessary part of a system which has to be chosen, used and installed during installation. You simply can't reformat or repartition a harddisk after the installation. Well, it's possible but not without having a second harddisk onto which the installed system had first to be copied. But that's not the way a system should be installed. So every filesystem - regardless of how much it is used and how popular it is - has definitely to be moved to [core] and supported by AIF. And, no, ext2 is not the only filesystem which can be used for /boot and /. But on the other hand every filesystem related package has to be removed from (base), while AIF should then be able to recognize which filesystems are created on the harddisk and install the appropriate filesystem tools automagically. > The idea of core was to provide a minimal set of packages that are > needed by nearly all users to set up a base system. Our sign-off > procedure ensures that we don't put broken packages by accident there. But filesystems - all of them - belong to the very minimal set of packages that are needed to set up a base system. But every user needs a different filesystem for a reason, because every user has different requirements. experimental != broken Just because a filesystem is marked as experimental doesn't mean that it's broken. Btrfs e.g. is missing a fsck, yet, but it shall be pretty stable until the harddisk gets too cluttered. At least it's said by many people in the web. So there are several people who like to use and to test it. As soon as there's a first stable version of a package it should of course not be updated anymore to newer, unstable versions. Of course, those experimental packages should explicitly be marked as experimental in AIF. There have been, btw., several kernel modules in the vanilla kernel which have been marked as experimental for many years even if they haven been really stable in the meantime. So the word experimental is quite relative. > I don't think that nilfs matches the criteria needed for inclusion in > core. (side note: it has 1.38% usage according to pkgstats) Why does it only have 1.38% usage? Just because it's not in [core] and not supported by AIF, just because a filesystem is usually chose at install time. And nilfs won't get as a high usage as ext4, just because it's primarily meant for using on a SSD (SSD disks, USB sticks, etc.). But to be able to install Arch Linux on a USB stick with the official install CD and to format the USB stick with nilfs it needs to be supported by AIF and to be in [core]. Heiko

7 14

[arch-general] [RFC] patches to initscripts
by Tom Gundersen 07 Dec '10

07 Dec '10

On Fri, Nov 19, 2010 at 7:58 AM, Allan McRae <allan(a)archlinux.org> wrote: > While looking through bugs for [core] packages, I notice that there are a > large number of bug report for these three packages. In total they account > for ~13% of the bugs in the tracker! [...] > But given these are some of the uniqueness of Arch, I wonder what we _as a > group_ could to do to improve this situation? Perhaps organize a > hack-a-thon on IRC one day? Or we could advertise for help, with the > selection criterion being a git repo provided by the applicant showing they > can do stuff? As discussed with Allan, here are some patches to initscripts: <https://github.com/teg/initscripts-arch>. Comments very much welcome. I started off with what appeared to me as the low-hanging fruit. Once I have had feedback on this I'll have a look at more difficult (or invasive) problems. My long-term goal is to ease the maintenance burden of initscripts by simplifying them and harmonizing them with other distros/projects (without, of course, loosing any of their features). Cheers, Tom

4 10

[arch-general] Multi architecture binary pkgs
by jesse jaara 07 Dec '10

07 Dec '10

Currently, if one wants to make a pkg, lets say, for an app that only has binaries available and only for 32bit archs, then one usually makes a bin32-appname pkg for it. I don't like this and would like to have the bin32 and the non-bin32 pkgs to be just one pkg with the name of the app. But if one makes this kind of a pkg, one must use ugly if [[ "$CARCH" = .... statements are in the PKGBUILD, so I was thinking that could it be possible to implement some new variables in PKGBUILDS like depends32 and optdepends32 and then build32() {} and package32() {}? I dont know how makepkg is written, so I dont know how hard it is to implement these, but in the best case it shouldn't be more than just one or two if-statements in the code, so if arch is x86_64 use the 32 variables if they are present. -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. (> <) come join the dark side. /_|_\ (we have cookies.)

4 4

[arch-general] alsa, hdmi, and the invisible magic output
by Samuel Martín Moro 03 Dec '10

03 Dec '10

Good evening everyone, I'm using arch since a while now. Everything was working just fine, until a few weeks (months?) ago. Since, I had a few problems I can't understand : The first symptom was the day I lost sound on my regular audio output (moterhboard intel HDA). I finally noticed sound was actually send to my TV through my G92 9800GT. I had a long period during while I was always switching my speakers wire from my tower to the screen, and back to the computer. The main problem beeing that, after putting the screen in sleep mode, I wasn't able to get the sound back without restarting X. Since, the problem changed, somewhat. Now, vlc sends its sound in both my motherboard and my graphic card outputs. While banshee's still only using the motherboard one. The most recent symptom is that, when I'm already playing some music with banshee, I can't have sound on any web browser (opera, firefox & chromium tested so far). I first though it was flash-related. But since I can't have sound while playing quakelive too (and AFAIK, QLive doesn't uses flash), I'm a bit confused... What could be happening? The only way I can get sound working back in the web browser is to shut down banshee and restart the browser. And I won't be able to make banshee work again before closing the browser, and then starting banshee. The following error is continuously reported when executing chrome from terminal, while using banshee: ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave I searched for some details on google. It seems the first thing I may do is to specify which audio device use by default. So, I tried to find where my HDMI output is... faust@alpha : aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 1: AD198x Digital [AD198x Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 faust@alpha : lspci | grep -i audio 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller faust@alpha /proc/asound : l -R /proc/asound/ /proc/asound/: total 0 dr-xr-xr-x 5 root root 0 Dec 2 23:45 card0 -r--r--r-- 1 root root 0 Dec 2 23:45 cards -r--r--r-- 1 root root 0 Dec 2 23:45 devices -r--r--r-- 1 root root 0 Dec 2 23:45 hwdep lrwxrwxrwx 1 root root 5 Dec 2 23:45 Intel -> card0 -r--r--r-- 1 root root 0 Dec 2 23:45 modules dr-xr-xr-x 2 root root 0 Dec 2 23:45 oss -r--r--r-- 1 root root 0 Dec 2 23:45 pcm dr-xr-xr-x 2 root root 0 Dec 2 23:45 seq -r--r--r-- 1 root root 0 Dec 2 23:45 timers -r--r--r-- 1 root root 0 Dec 2 23:45 version /proc/asound/card0: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 codec#0 -r--r--r-- 1 root root 0 Dec 2 23:45 id -rw-r--r-- 1 root root 0 Dec 2 23:45 oss_mixer dr-xr-xr-x 5 root root 0 Dec 2 23:45 pcm0c dr-xr-xr-x 3 root root 0 Dec 2 23:45 pcm0p dr-xr-xr-x 3 root root 0 Dec 2 23:45 pcm1p /proc/asound/card0/pcm0c: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 oss dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub0 dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub1 dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub2 /proc/asound/card0/pcm0c/sub0: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/card0/pcm0c/sub1: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/card0/pcm0c/sub2: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/card0/pcm0p: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 oss dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub0 /proc/asound/card0/pcm0p/sub0: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/card0/pcm1p: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 oss dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub0 /proc/asound/card0/pcm1p/sub0: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/oss: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 devices -r--r--r-- 1 root root 0 Dec 2 23:45 sndstat /proc/asound/seq: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 clients -r--r--r-- 1 root root 0 Dec 2 23:45 drivers -r--r--r-- 1 root root 0 Dec 2 23:45 oss -r--r--r-- 1 root root 0 Dec 2 23:45 queues -r--r--r-- 1 root root 0 Dec 2 23:45 timer faust@alpha : uname -a Linux alpha.example.com 2.6.36-ARCH #1 SMP PREEMPT Wed Nov 24 00:39:57 CET 2010 x86_64 Intel(R) Core(TM) i7 920 @ 2.67Ghzs GenuineIntel GNU/Linux I'm not sure to understand what represent pcm0c, pcm0p and pcm1p... Launching alsamixer, I only have one device (identified as default and hda intel) The last listed output is 'HDMI', and indeed, controls my screen speakers' sound level. So, I don't understand. How is it possible to have only one card recognized, and controlling both of them through the same alsamixer/gnome-volume-control panel? What can I do? Setting HDMI as default (only) output? How to do so? Wait for a patch? Is it a kernel-related bug? Or with nvidia driver? Would that even fix the banshee/browser troubles accessing device? This arch worked for more than a year. I guess that's the bad side of mainstream distros. Whatever. I'm still enjoying my stay. Also, I often get this warn: *** NSPlugin Viewer *** WARNING: unhandled variable 18 (<unknown variable>) in NPN_GetValue() I'm quite sure it's not related to my problem, but I'm still curious: wtf? I read on some ubuntu forum it's related to flash, kernel & x86_64. It's seems to be fixed on ubuntu. Did I misunderstood? (When) would it come to arch? Thanks for your help, and your time! -- Samuel Martín Moro {EPITECH.} tek5 CamTrace S.A.S (+033) 1 41 38 37 60 1 Allée de la Venelle 92150 Suresnes FRANCE "Nobody wants to say how this works. Maybe nobody knows ..." Xorg.conf(5)

5 10