- Arch-general - lists.archlinux.org

[arch-general] Is there a clean solution to get completely rid of Pulseaudio?
by Ralf Madorf 29 Dec '11

29 Dec '11

Hi :) people told me that Arch Linux will not force me to install PA. Today I continued to set up my Arch Linux. A cold still hinder me to work very long on my computer, so until now Google didn't help me to find an easy solution to get rid of PA. Arch Linux on my machine does force me to install PA to keep the system consistent. I found this information: https://bbs.archlinux.org/viewtopic.php?pid=998489#p998489 I already read tons of irrelevant comments similar to https://bbs.archlinux.org/viewtopic.php?pid=998290#p998290 Even no information on https://wiki.archlinux.org/index.php/Pro_Audio I like using Google and reading Wikis, in spite of my dyslexia. I don't like to read tons of irrelevant stuff to find out, that in the end there's no clean solution. Is there a clean solution to get completely rid of PA? PA for my needs is absolutely obstructive. I try to set up a DAW using two Terratec EWX 24/96 for MIDI only (but both are audio devices too) and for audio a RME HDSPe. The only thing PA will do for me, is causing trouble. IIRC on Debian I got rid of PA by replacing 2 packages by empty dummy packages, then everything was ok. I figured this out my self. Btw. for Debian it was the same, people told me that Debian doesn't force to use PA, but it does. Since I'm new to Arch Linux I need some information. May I ask where I get the needed information to completely once and for all get rid of PA? TIA, Ralf PS: There are reasons to get rid of PA. The "installing PA isn't absolutely obstructive" crowd might use Google, IIRC there e.g. was the description of an issue in an Ubuntu Studio mailing list this month.

23 77

[arch-general] People that depend on Arch, etc deserve to die? - Allan McRae - Clarifications
by Jonathan Vasquez 27 Dec '11

27 Dec '11

Hello everyone, I was reading the package signing discussion that was going on over at the [pacman-dev] mailing list http://mailman.archlinux.org/pipermail/pacman-dev/2011-February/012483.html and Allan said the following: "I think I know every distribution using pacman as a package manager and (unless there is an enterprise level distro I am missing) if peoples lives depend on one of these distros, then I am sorry to say it but in my opinion they are stupid and deserve to die." I wanted to know what was he trying to say? Is he saying that Arch and other Arch-like distros aren't serious distros that aren't meant for production? I mean I understand that Arch is rolling release and all that, but it's packages are marked stable by their corresponding upstreams. What are your opinions about this? -- Jonathan Vasquez

9 14

[arch-general] ldconfig -> Aborted.
by C Anthony Risinger 27 Dec '11

27 Dec '11

this might be a bit brief as it's really late and i'm already in trouble :-/ ... will expand as needed. i upgrade my machines and VMs very regularly, at least once a week, this last batch of updates broke all of my VMs in particular ... hardware devices still seem to function correctly. they are not really broken, but i am unable to regenerate `/etc/ld.so.cache` on any of them (3 ATM). upgraded packages (in order, from pacman.log): augeas linux-api-headers glibc <---------------------- prime suspect!!!! binutils fakeroot gcc-libs gcc pcre git keyutils krb5 libmysqlclient polkit yajl libvirt module-init-tools mkinitcpio linux pm-quirks postgresql-libs shadow systemd-arch-units texinfo ... during the upgrade i saw: upgraded linux-api-headers (3.0.1-1 -> 3.1.4-1) /tmp/alpm_gfNxsS/.INSTALL: line 4: 575 Aborted sbin/ldconfig -r . Generating locales... en_US.UTF-8...cannot map archive header: Invalid argument upgraded glibc (2.14.1-1 -> 2.14.1-2) upgraded binutils (2.21.1-2 -> 2.22-2) /tmp/alpm_dwiY8r/.INSTALL: line 5: 654 Aborted sbin/ldconfig -r . upgraded fakeroot (1.18.1-1 -> 1.18.2-1) ... the locale stuff is just a side effect of the ldconfig failure IIRC -- locales are a little borked because the archive file was blown away, not a problem tho. for some reason ldconfig refuses to update on all the VMs (each has worked without issue until today, for several months): # ldconfig Aborted ... i tried blacklisting some virtio modules (balloon in particular) and tripling memory, no change, and not convinced its 100% related to virtio yet. i tried removing `/var/cache/ldconfig/aux-cache` to force ldconfig to rescan everything (vs. stat checks) -- again, works on hardware but not VM. i tried removing the last library it processes before failing (per strace), no change, it just fails on another (libgcrypt -> libsysfs). i tried reinstalling glibc and whatnot ... these VMs are all pure 64bit, no multilib, and pure systemd, original initscript stuff purged. the only thing i didnt try was downgrading, because i would have to use the ARM ... i use 9p2000.L passthru for the rootfs of each VM, bindmount a local mirror into each VM's VFS, then configure pacman to use the `pool` directory of the bound mirror as a cachedir -- the net effect is pacman never downloads anything, ever, because it believes it already has :-) slightly odd perhaps, but working well for quite some time. any ideas? i can't find anything out of place, or any significant differences, and i'm not sure what to try next -- nothing unusual in dmesg or logs, on the VMs or the host. host is completely current as of Dec 14 00:00 CST. reduce strace follows, limited to files and signals. thanks for your time so far, if you made it to this point legitimately :-) C Anthony # LANG=C strace -ff -s256 -etrace=file,signal ldconfig execve("/sbin/ldconfig", ["ldconfig"], [/* 29 vars */]) = 0 open("/etc/ld.so.conf", O_RDONLY) = 3 open("/etc/ld.so.conf.d", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 open("/etc/ld.so.conf.d/fakeroot.conf", O_RDONLY) = 4 stat("/usr/lib/libfakeroot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 open("/etc/ld.so.conf.d/perl.conf", O_RDONLY) = 4 stat("/usr/lib/perl5/core_perl/CORE", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/lib64", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat("/usr/lib", {st_mode=S_IFDIR|0755, st_size=36864, ...}) = 0 stat("/usr/lib64", 0x7fff85a41d90) = -1 ENOENT (No such file or directory) open("/var/cache/ldconfig/aux-cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/libfakeroot", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 lstat("/usr/lib/libfakeroot/libfakeroot.so", {st_mode=S_IFLNK|0777, st_size=16, ...}) = 0 open("/usr/lib/libfakeroot/libfakeroot.so", O_RDONLY) = 4 lstat("/usr/lib/libfakeroot/libfakeroot-0.so", {st_mode=S_IFREG|0755, st_size=40400, ...}) = 0 stat("/usr/lib/libfakeroot/libfakeroot-0.so", {st_mode=S_IFREG|0755, st_size=40400, ...}) = 0 stat("/usr/lib/libfakeroot/libfakeroot.so", {st_mode=S_IFREG|0755, st_size=40400, ...}) = 0 open("/usr/lib/perl5/core_perl/CORE", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 lstat("/usr/lib/perl5/core_perl/CORE/libperl.so", {st_mode=S_IFREG|0555, st_size=1642088, ...}) = 0 open("/usr/lib/perl5/core_perl/CORE/libperl.so", O_RDONLY) = 4 stat("/usr/lib/perl5/core_perl/CORE/libperl.so", {st_mode=S_IFREG|0555, st_size=1642088, ...}) = 0 stat("/usr/lib/perl5/core_perl/CORE/libperl.so", {st_mode=S_IFREG|0555, st_size=1642088, ...}) = 0 open("/lib", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 lstat("/lib/libpopt.so", {st_mode=S_IFLNK|0777, st_size=12, ...}) = 0 open("/lib/libpopt.so", O_RDONLY) = 4 lstat("/lib/libudev.so.0.13.0", {st_mode=S_IFREG|0755, st_size=55952, ...}) = 0 open("/lib/libudev.so.0.13.0", O_RDONLY) = 4 lstat("/lib/libutil.so.1", {st_mode=S_IFLNK|0777, st_size=17, ...}) = 0 open("/lib/libutil.so.1", O_RDONLY) = 4 lstat("/lib/libgcrypt.so", {st_mode=S_IFLNK|0777, st_size=19, ...}) = 0 open("/lib/libgcrypt.so", O_RDONLY) = 4 lstat("/lib/libpamc.so.0", {st_mode=S_IFLNK|0777, st_size=17, ...}) = 0 open("/lib/libpamc.so.0", O_RDONLY) = 4 lstat("/lib/libsysfs.so.2.0.1", {st_mode=S_IFREG|0755, st_size=47640, ...}) = 0 open("/lib/libsysfs.so.2.0.1", O_RDONLY) = 4 lstat("/lib/libhandle.so.1.0.3", {st_mode=S_IFREG|0644, st_size=14400, ...}) = 0 open("/lib/libhandle.so.1.0.3", O_RDONLY) = 4 lstat("/lib/libBrokenLocale.so.1", {st_mode=S_IFLNK|0777, st_size=25, ...}) = 0 open("/lib/libBrokenLocale.so.1", O_RDONLY) = 4 lstat("/lib/libBrokenLocale-2.14.1.so", {st_mode=S_IFREG|0755, st_size=6264, ...}) = 0 lstat("/lib/libnss_mdns_minimal.so.2", {st_mode=S_IFREG|0755, st_size=9904, ...}) = 0 open("/lib/libnss_mdns_minimal.so.2", O_RDONLY) = 4 lstat("/lib/libpam.so.0", {st_mode=S_IFLNK|0777, st_size=16, ...}) = 0 open("/lib/libpam.so.0", O_RDONLY) = 4 lstat("/lib/liblvm2app.so.2.2", {st_mode=S_IFREG|0555, st_size=667916, ...}) = 0 open("/lib/liblvm2app.so.2.2", O_RDONLY) = 4 lstat("/lib/libutil-2.14.1.so", {st_mode=S_IFREG|0755, st_size=10656, ...}) = 0 lstat("/lib/libbz2.so.1.0", {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0 open("/lib/libbz2.so.1.0", O_RDONLY) = 4 lstat("/lib/libsystemd-login.so.0", {st_mode=S_IFLNK|0777, st_size=25, ...}) = 0 open("/lib/libsystemd-login.so.0", O_RDONLY) = 4 lstat("/lib/libanl-2.14.1.so", {st_mode=S_IFREG|0755, st_size=14928, ...}) = 0 open("/lib/libanl-2.14.1.so", O_RDONLY) = 4 lstat("/lib/libgpg-error.so", {st_mode=S_IFLNK|0777, st_size=21, ...}) = 0 open("/lib/libgpg-error.so", O_RDONLY) = 4 lstat("/lib/libacl.so", {st_mode=S_IFLNK|0777, st_size=11, ...}) = 0 open("/lib/libacl.so", O_RDONLY) = 4 lstat("/lib/libpam.so.0.83.1", {st_mode=S_IFREG|0755, st_size=55856, ...}) = 0 lstat("/lib/libgcrypt.so.11", {st_mode=S_IFLNK|0777, st_size=19, ...}) = 0 open("/lib/libgcrypt.so.11", O_RDONLY) = 4 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(2559, 2559, SIGABRT) = 0 --- {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2559, si_uid=0, si_value={int=2164749013, ptr=0xffffffff810772d5}} (Aborted) --- +++ killed by SIGABRT +++ Aborted

4 7

[arch-general] iPod Touch not detected with GtkPod
by Jordan Windsor 25 Dec '11

25 Dec '11

Hello, I've read the wiki page at https://wiki.archlinux.org/index.php/IPod , I'm following the part titled "The iFuse Way - iPhone OS 3.x and 4.x", I've mounted the iPod at /mnt/ipod then I run GtkPod, I then click "Load all or Selected iPods" and nothing happens at all, no windows or menus popup. Where should I go from here? (I can also read & write to the iPod directory as a user) Thanks.

1 0

Re: [arch-general] a plea for python 2
by Alex Bolgarov 24 Dec '11

24 Dec '11

> you all think the proper fix is for > me to put in the docs something like "on Arch systems you need to do > [x] before building", whether [x] is "get the PKGBUILD with the patch > from AUR" or even "run the sed-python-with-python2.sh included in the > distribution". I personally don't think it is a proper fix - I think it is not a fix at all. My opinion is that Python3 is sufficiently different from Python2 to be considered a new language, not just a new version of old (thus it would be appropriate to use new name, 'python3', for it, leaving 'python' forever referring to python2). (That is, desire to be on the bleeding edge does not warrant breaking existing software) If I were you, I would probably stop putting shebangs into my Python scripts (so that they would be not executables), and write a shell wrapper script for every python script that figures out during runtime how python2 executable is called, and call python2 script using this python executables (or write single script with symbolic links to it with different names and use $0 shell variable to find which python script to call).

6 6

[arch-general] Issue with monolithic gcc-libs package
by Paul Fox 23 Dec '11

23 Dec '11

Hello, I have been looking into GNUStep and Etoile development recently, and I ran into an Arch packaging issue that I'm not sure how to address. Essentially, Etoile requires the experimental GNUStep libobjc runtime (libobjc2 or GNUStep runtime) that has additional features from Objective 2.0. However, libobjc on Arch is part of the gcc-libs package making it hard to replace without removing libobjc.so manually and breaking the package. It puzzles me that gcc-libs includes runtimes for all the major languages supported by gcc. Might it not be better to have each library be its own package (so, for example, libstdc++, libgomp, libfortran, and so forth) and only have gcc-libs include libgcc_s? This would allow more flexibility to selectively install or replace runtime libs (for example, I might not need fortran, so why should I have it installed?)

1 0

[arch-general] python-urwid and python2-urwid contain .pyo files, didn't used to.
by Peter Lewis 23 Dec '11

23 Dec '11

Hi, python-urwid and python2-urwid now seem to contain .pyo files, but they didn't before. Just thought I'd check that this was intentional. Caveat: I know nothing about python packaging, but pacman just gave me a bunch of file conflicts for .pyo files not previously owned by anything. Pete.

3 3

[arch-general] pacman -Syu fails due to conflict with mtab?
by David C. Rankin 23 Dec '11

23 Dec '11

Guys, Just a quick question. Upgrade failed due to conflict with mtab: <snip> (67/67) checking for file conflicts [#######################################] 100% error: failed to commit transaction (conflicting files) filesystem: /etc/mtab exists in filesystem Errors occurred, no packages were upgraded. How should I handle this? I don't think it would be a good idea to replace an active mtab with --force. What say the experts? -- David C. Rankin, J.D.,P.E.

14 22

[arch-general] TeXLive update
by Rémy Oudompheng 23 Dec '11

23 Dec '11

Hello, I have done an update of TeXLive to catch up with the distribution updates. I think I had a free fix for FS#25250, the packages are in [testing] and will move to [extra] quite quickly unless new problmes are reported. Regards, Rémy.

1 1

[arch-general] Top Posting Revisited
by gt 22 Dec '11

22 Dec '11

Hello folks, i'll probably get flamed for reviving a very controversial, yet consistently brought up topic. I have seen a similar thread last year, and every other day, someone points out to someone that top posting is bad. I was off the list for a while, and now when i came back, the story is still the same. I know top posting is bad, and i too sometimes preach people to avoid it. But from what i've seen, most of the times, people don't bother, or simply don't know what's wrong. Instead of having top-posting related mails in every thread, there should be a better way out. I suggest all of the top-posting haters should including one of these links or similar in their signatures. http://idallen.com/topposting.html http://www.caliburn.nl/topposting.html Also, we can have a forum and mailing list etiquette drive for a few days, with mention in the arch linux news, the mailing list, and setting it as the topic in the irc channel also. I know this is probably overkill, but it'll probably inform a lot more people about these issues than some stray posts in every other thread. PS: Since arch is always ahead of the other distros in adopting new stuff and bringing about change, let's be the first ones to spread some netiquette. -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

34 59