October 2011 - Arch-general - lists.archlinux.org

[arch-general] pacman transition - follow up
by fredbezies 13 Oct '11

13 Oct '11

I upgraded pacman flawlessly. Just had to run one pacman-key, and waiting for yaourt to be updated I installed packer. I will need to go back to simple mail for arch-general :[ -- Frederic Bezies fredbezies(a)gmail.com

1 0

[arch-general] How-to for pacman 4.0 transition ?
by fredbezies 13 Oct '11

13 Oct '11

Hello. I saw on arch-commits list that pacman 4.0 is in testing. So, is there somewhere a how-to to follow to ease the transition ? Thanks a lot ! -- Frederic Bezies fredbezies(a)gmail.com

3 2

[arch-general] Howto find alternate ABS source download mirror?
by David C. Rankin 12 Oct '11

12 Oct '11

Guys, Where do I find a list of ABS download mirrors? I was working with ffmpeg and the download from ftp.archlinux.org was painfully slow due to the throttled connection. Is there somewhere mirrors for ABS sources are listed? Usually it doesn't matter because most sources are relatively small, but with packages like ffmpeg (50 meg), the throttling difference can be extreme. Thanks. -- David C. Rankin, J.D.,P.E.

5 5

[arch-general] [signoff] linux-3.0.6-2
by Tobias Powalowski 11 Oct '11

11 Oct '11

Latest kernel is in testing, - fixed archiso support - revert to performance governor please signoff both arches, greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

8 10

Re: [arch-general] [arch-dev-public] [arch-projects] [HEADSUP] udevd moved out of PATH
by Myra Nelson 11 Oct '11

11 Oct '11

On Tue, Oct 11, 2011 at 08:32, Dan McGee <dpmcgee(a)gmail.com> wrote: > On Tue, Oct 11, 2011 at 8:14 AM, Tom Gundersen <teg(a)jklm.no> wrote: > > On Tue, Oct 11, 2011 at 11:44 PM, Dan McGee <dpmcgee(a)gmail.com> wrote: > >> This is really f***ing stupid of upstream. > > > > Unlikely. > > > >> Why are they doing this > >> outside of simply wanting to break everything? > > > > What is breaking? > Everything I outlined below? Restarting a daemon, which shouldn't > involve having to restart my computer to do so? > > >> I'm not a fan of this > >> as we are making upgrades way too fragile, > > > > How? We always require udev, initscripts and mkinitcpio to be in sync, > > running udev should not be affected. > Throw the filesystem package into that bucket too. What I meant to say > is we have at times had this dependency happen, but it seems like > every single upgrade as of late as absolutely required it. This was > never the case a year ago. I realize I'm coming across as a old, > resistant to change, pesky thorn in the side here, but we're doing > things that are beginning to clash mightily with the Arch way here. > > >> not to mention moving what > >> is very clearly a *binary* into a non-binary path, which is totally > >> bogus. > > > > There are plenty of binaries in libexec (and there are plenty of > > non-binaries in bin), I don't see the problem. > So let me make sure I understand here since the upstream commit wasn't > linked- upstream moved it to libexec, which we normally move into to > /usr/lib, but this particular binary is moving to /lib? > > >> I know I've done `killall udevd && udevd --daemon` before to > >> get the new version running; sounds like this is not going to work at > >> all anymore. > > > > That does not sound like a good idea, you'll at least lose events. > Am I the only one that does this? Because the handy-dandy, still on my > path `udevadm` command definitely doesn't have any sort of documented > 'restart' function for those of us that don't like to reboot our > installs once a week. > > Are you sure about losing events? I thought the kernel cues them up if > udevd isn't running. Maybe I need to add a `udevadm --exit` or > something else to my incantation, I don't know. > > >> I would honestly pester upstream and have them justify the color of > >> their hat this week; > > > > Unless you can come up with some real problems caused by this, I think > > that would be a waste of time. Even if they did not explain their > > reasoning very well this time, I'm pretty sure they have some, and > > won't revert just because some random people say "I don't like it". > > > >> -1 from me on this whole change, upstream decision > >> or not. > > > > -1 on what? What exactly are you proposing? > At the very least we should symlink this to the former location until > there is a udevadm that actually covers all of the use cases. Real > problem #1- how do I restart this? #2 without having the path > memorized? > > Re: upower, udisks, and polkit running out of libexec: I don't think > this is seen as an advantage by many around here. At least I see it as > a negative; why are we making things harder on the user to have > control of their system? > > I also think having to hardcode *any* path to a binary (user-usable or > not, WE still have to use it) like this is a real issue; what happens > when the Kool-Aid color of the week moves it again? We continue to > play along? > > -Dan > I'm not a dev but would like to stick my two cents in here anyway. The following statement by Dan McGee highlights some of my concerns with a lot of distros and why I chose Arch to begin with. "At least I see it as a negative; why are we making things harder on the user to have control of their system?" With Arch I still have control of my machine. I do not care for what, IMHO, is the drive to appease the corporate user types who insist everyones' machine look the same and force everyone into a common way of doing things. It may be great for the office, but not for other users. Like Dan I'm coming accross as old and resistant to change. Change is good and necessary unless it's change for changes' sake. I realize the Arch way dictates minimal patching and staying current with upstream, but what happens if upstream goes the wrong direction? I had a steep learning curve because I wanted to use Arch and I still have a long way to go, but at least I remember how to set up, maintain and use a computer again. I still have to look/ask for help ocassionally, but I'm getting there. Please keep Arch simple and useable. Myra -- Life's fun when your sick and psychotic!

1 0

[arch-general] [translation] pacman 4.0.0 string freeze
by Dan McGee 11 Oct '11

11 Oct '11

If you've helped us out before, or are looking to get involved, the string freeze for the magic 4.0 release is now in effect. Translators: http://www.archlinux.org/pacman/translation-help.html Transifex release page: https://www.transifex.net/projects/p/archlinux-pacman/r/4-0-0/ I've set the deadline 7 days from today. -Dan

5 7

[arch-general] xdm, who and X sessions
by Norbert Zeh 11 Oct '11

11 Oct '11

Hi folks, wanting to go lightweight, I just switched back from kdm to xdm, but I ran into a little snag, which I reported as bug FS#26395 on the bug tracker. I'm no longer sure this is actually a bug, at least not of "who". The problem: After loggin in via xdm, "who" does not show any logged in users. "who /var/run/utmp" on the other hand does show the logged in user. Using kdm, "who" and "who /var/run/utmp" both reported the same result. The reason: There's a small difference between running "who" with or without argument. When run without argument, "who" checks whether the process associated with a session in /var/run/utmp is dead or alive. If it is dead, the entry is not listed in the output. Now, when using xdm, sessreg is run from Xstartup and registers the shell running Xstartup as the PID associated with the session. The shell running Xstartup exits and then xdm fires up Xsetup to start the user's session. Since the shell running Xstartup has exited, there is no longer any process with the PID associated with the session in /var/run/utmp. Hence, who does not report this session. While this explains the source of the problem, I have no idea how to fix it. It seems that what would be needed is to run sessreg as root from a process that stays alive while the user is actually logged into the X session. kdm, for example, does in fact stay alive while the user is logged in. So does xdm, but the PID recorded in /var/run/utmp is not the one of xdm but of the shell it spawns to run Xsetup. Any suggestions would be greatly appreciated. Cheers, Norbert

2 2

Re: [arch-general] FW: no sound coming from speakers after update
by Roman V.Leon. 11 Oct '11

11 Oct '11

> On Monday, October 10, 2011, Martti Kühne wrote: > >> On Mon, Oct 10, 2011 at 3:25 AM, Madhurya Kakati >> >> wrote: >> > On Sunday, October 9, 2011, Martti Kühne wrote: >> > >> >> On Sun, Oct 9, 2011 at 7:09 PM, Madhurya Kakati >> >> > >> >> wrote: >> >> > >> >> > The last entry in mpd.log is from 02 oct. I doubt that will help. >> >> However >> >> > when I try to start mpd I get this error, [papul@archlinux ~]$ >> >> > sudo rc.d start mpd >> >> > :: Starting Music Player Daemon >> >> > [BUSY] /etc/rc.d/mpd: line 6: 9910 Aborted >> /usr/bin/mpd >> >> > /etc/mpd.conf &>/dev/null >> >> > >> >> >> >> Usually I put in hashes ('#') into the /etc/rc.d/mpd script to >> >> check what output there is destroyed. Could be useful. >> >> >> >> cheers! >> >> mar77i >> >> >> > >> > After adding '#' in /etc/rc.d/mpd here's what I get when I try to >> > start >> it, >> > [papul@archlinux ~]$ sudo rc.d start mpd >> > :: Starting Music Player Daemon >> > [BUSY] listen: bind to '0.0.0.0:6600' failed: Address already in >> > use (continuing anyway, because binding to '[::]:6600' succeeded) >> > output: No "audio_output" defined in config file >> > output: Attempt to detect audio output device >> > output: Attempting to detect a alsa audio device ALSA lib >> > pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: >> > Connection refused >> > >> > alsa: Error opening default ALSA device: Connection refused >> > output: Attempting to detect a oss audio device >> > oss: Error opening OSS device "/dev/dsp": No such file or directory >> > oss: Error opening OSS device "/dev/sound/dsp": No such file or >> > directory >> > output: Attempting to detect a pulse audio device >> > mpd: src/output/pulse_output_plugin.c:400: pulse_output_wait_connection: >> > Assertion `po->mainloop != ((void *)0)' failed. >> > /etc/rc.d/mpd: line 6: 27833 Aborted /usr/bin/mpd >> > /etc/mpd.conf >> > >> > [FAIL] >> > >> >> >> wow that fails for several reasons. you should: >> 1. configure alsa in mpd.conf, then mpd will be mixed over dmix (which >> won't fix the actual problem) 2. make sure the user which runs mpd to >> the audio group and figure out why both alsa and pulse would refuse >> the connection. >> who (uid/gid) runs those, what other security mechanisms could stick >> in between, like a too restrictively configured firewall etc. >> >> oh and you should figure out if mpd is already running, or if this >> config option is plain wrong that makes mpd try to "bind to >> '0.0.0.0:6600' failed: Address already in use" ... sometimes mpd hangs >> up and you have to kill it with SIGABRT / 6. >> >> I'm just at a very similar issue a friend of mine is having with mpd >> and jack. you should get those permissions right in the first place... >> :) I'll go there and adjust /etc/group until it works, I guess. >> >> cheers! >> mar77i >> > > > Forget about mpd. Why doesn't audio play on vlc and in browsers? I regularly visit sites like grooveshark,com. Also I do have my username in audio group. > Everything was fine until I ran pacman -Syu. :( Hello Martti. Please show 'ls -l /dev/snd/' output and try to launch alsamixer(under root and unprivileged user) copy all error messages. Be sure that you have alsa-utils installed and alsa daemon is running. Cheers, Roman. ______________________________ Распродажи купальников on-line. Сравнение цен. Описания, отзывы http://metamarket.ua/ru/odezhda-obuv-i-aksessuary/zhenskaya-odezhda/kupalni…

3 4

Re: [arch-general] [arch-dev-public] nvidai 285.05.09 and xorg-server 1.11.1
by Matthew Gyurgyik 10 Oct '11

10 Oct '11

On 10/10/2011 04:56 AM, Jan de Groot wrote: > I have decided to revert this commit in our packages. There's a 1.11-2 > package with some additional upstream patches and this reverted commit > on its way to testing. > If nobody has any objections, I'd like to move this to extra tomorrow. I had issues with 1.11-1 (nvidia 9400 GT). No problems with -2. For what it's worth, I have no objections. ~pyther

1 0

[arch-general] GLiv freezes when quitting with nVidia GPU
by Ricardo Catalinas Jiménez 10 Oct '11

10 Oct '11

Hi everyone, It seems that with the latest version of GLiv using a nVidia GPU when trying to quit the program with File->Quit or just hitting `q' it freezes and then starts eating all the CPU. Anybody have experienced the same issue? As far as I can tell, this problem was not present with previous versions of GLiv and/or nVidia driver. My GPU is: nVidia Corporation G73GL, Quadro FX 560 I'm on an updated Arch, so my package versions are: nvidia 280.13-1 gliv 1.9.7-1 I sent an email to the author of GLiv, but as it could be nVidia's fault (see backtrace below), it is possible that he can't help. Here it is the gdb backtrace when trying to quit GLiv: #0 0x00007f73935b1ba4 in _nv012tls () from /usr/lib/libnvidia-tls.so.280.13 #1 0x00007f73978f6dfd in ?? () from /usr/lib/libGL.so.1 #2 0x00007f73978d64b9 in ?? () from /usr/lib/libGL.so.1 #3 0x00007f739ac061e5 in _dl_fini () from /lib/ld-linux-x86-64.so.2 #4 0x00007f73962a5281 in ?? () from /lib/libc.so.6 #5 0x00007f73962a5305 in exit () from /lib/libc.so.6 #6 0x000000000041bfad in quit (code=0) at main.c:247 #7 0x000000000041c870 in gui_quit () at main.c:305 #8 0x00007f7398b500e4 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #9 0x00007f7398b6206a in ?? () from /usr/lib/libgobject-2.0.so.0 #10 0x00007f7398b6b6f1 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #11 0x00007f7398b6b892 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #12 0x00007f739a81827e in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0 #13 0x00007f739a71353d in gtk_menu_shell_activate_item () from /usr/lib/libgtk-x11-2.0.so.0 #14 0x00007f739a7138d7 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #15 0x00007f739a7000d8 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #16 0x00007f7398b500e4 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #17 0x00007f7398b61e9f in ?? () from /usr/lib/libgobject-2.0.so.0 #18 0x00007f7398b6b4c3 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #19 0x00007f7398b6b892 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #20 0x00007f739a819081 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #21 0x00007f739a6fe2d3 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #22 0x00007f739a6fe633 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #23 0x00007f739a37384c in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #24 0x00007f739827f85d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #25 0x00007f7398280058 in ?? () from /usr/lib/libglib-2.0.so.0 #26 0x00007f7398280592 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #27 0x00007f739a6fd687 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #28 0x0000000000410cff in main (argc=2, argv=0x7fffc3875478) at main.c:355 Regards -- Ricardo (http://r.untroubled.be/)

2 3