- Arch-general - lists.archlinux.org

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

[arch-general] gnome-shell-extension-dock broke with gnome 3.2.0-1 update
by Chad Kellerman 10 Oct '11

10 Oct '11

Anyone else's gnome-shell-extension-dock break after the update? I've done some searching and it doesn't look like anyone has run into this issue. Just wondering if anyone would know how to get it back? I've removed it, installed it, enabled it, it just doesn't show, and nothing shows in the .xsession-errors file. Thanks, Chad -- A grasshopper walks into a bar and the bartender says "Hey, we have a drink named after you." And the grasshopper says "Really, You have a drink named Murray?"

3 5

[arch-general] no sound coming from speakers after update
by Madhurya Kakati 10 Oct '11

10 Oct '11

Hi, I ran pacman -Syu just now after a gap of almost 3 weeks. After the update I restarted my system and now I can't play audio. Even mpd doesn't start up. alsamixer shows Card: PulseAudio and Chip:PulseAudio. Please help me as I can't do work on my computer with listening to music. :( I have pulseaudio installed just because gdm needs it. Other than that I use alsa.

2 9

[arch-general] Can't install e4rat from AUR: pacman fails to install missing dependencies
by Lorenzo Bandieri 09 Oct '11

09 Oct '11

Hello everyone! I'm having problems installing E4rat from the AUR ( https://aur.archlinux.org/packages.php?K=e4rat&SeB=x) Installation fails: $ makepkg -s ==> WARNING: Sudo can not be found. Will use su to acquire root privileges. ==> Making package: e4rat 0.2.1-2 (Sun Oct 9 17:34:22 CEST 2011) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Installing missing dependencies... Password: error: target not found: audit ==> ERROR: 'pacman' failed to install missing dependencies. I performed a search with pacman -Ss, and audit seems not to be in the repos. Has anyone encountered this problem yet? Thanks. Lorenzo

5 5

Re: [arch-general] [arch-dev-public] [signoff] linux-3.0.6-2
by Rogutės Sparnuotos 09 Oct '11

09 Oct '11

Thomas Bächler (2011-10-09 09:47): > Am 09.10.2011 06:22, schrieb Tom Gundersen: > > Could you point me to some more info about this (I couldn't find any > > bug reports)? > > If I remember right, if you load p4-clockmod and try to set ondemand as > governor, cpufreq will refuse the to change the governor. On i686, linux > even refuses to build the performance governor as a module, even if it > is not the default. Doesn't the kernel config discourage the use of p4-clockmod? " This driver should be only used in exceptional circumstances when very low power is needed because it causes severe slowdowns and noticeable latencies. Normally Speedstep should be used instead. " -- -- Rogutės Sparnuotos

1 0