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

Re: [arch-general] bluez and udev
by Seblu 30 Apr '11

30 Apr '11

On Tue, Mar 22, 2011 at 12:13 PM, Tom Gundersen <teg(a)jklm.no> wrote: > On Tue, Mar 22, 2011 at 11:25 AM, Seblu <seblu(a)seblu.net> wrote: > Could you try replacing your bluetooth rules with: > > # Run helper every time a Bluetooth device appears > # On remove actions, bluetoothd should go away by itself > ACTION=="add|change", SUBSYSTEM=="bluetooth", > RUN{fail_event_on_error}+="/usr/sbin/bluetoothd --udev" > > And after booting (so after dbus is running), calling "/sbin/udevadm > trigger --action=add --type=failed" manually? That's works. But as you said, it is now removed from upstream. > >> But in any case, if we do not modify the initscripts, the call for >> errors is done too early. > > At the moment udevadm trigger --type=failed is called after the file > system is mounted, but before dbus is started, so this would not help > with the current problem (I guess that's what you meant?). exactly. > I think the correct place to do it is either at the end of rc.multi as > you say, or maybe just at the end of the dbus script, to not affect > people not running dbus, and to make it clear why this is done for the > future? Doing this at the end of dbus rc.d script will fix this issue but seems to be less generic than at the end of rc.multi. Because it will not allow other programs launched in udev rules to start if a daemon is required. > On a related note: I noticed that udev upstream recently removed the > call to udevadm trigger --type=failed from their systemd unit files, > which would imply that they think this should never be necessary. This > particular problem would not happen on a systemd machine, but if it > turns out that we need to call "--type=failed" in this case, then > maybe there are other cases as well. So maybe it is worth > investigating why upstream made the change. Last commit remove option from manpage and add a death condition in TODO to --type failed. Actually this is probably a bad idea to patch in this way. http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=864fde8a087c0edb… I see nothing about this in linux-hotplug mailing list. I will ask them. Thanks a lot for your help Tom! -- Sébastien Luttringer www.seblu.net

2 4

[arch-general] What happened to Powerpill?
by Marek Otahal 07 Apr '11

07 Apr '11

Hi, anyone knows what happened to Xyne's powerpill [1] pacman wrapper? I started using it recently for it's aria2c multithreaded downloads but a couple of days it disappeared from community/aur and there's no trace. Thanks, marek [1] https://wiki.archlinux.org/index.php/Powerpill -- Marek Otahal :o)

11 15

[arch-general] Default Bootloader for AIF
by Matthew Gyurgyik 05 Apr '11

05 Apr '11

Arch Devs, In November Pierre wrote a mail to arch-dev-public about bootloaders in core. http://mailman.archlinux.org/pipermail/arch-dev-public/2010-November/018445… Pierre wrote: > Summing up my suggestion for some time in the future would be: > * move extlinux/syslinux to core/base > * move grub1 to extra/multilib and remove it from base group > * keep grub2 in extra > * maybe also move lilo to extra > * of course keep all of them on the install cd Now that there is Syslinux support in AIF, should AIF select Syslinux as the "Default" bootloader? Users are asked to select which bootloader package they would like to install. They can either pick from Grub or Syslinux. Since Grub is listed first it is selected as the "Default". ~pyther

8 18

[arch-general] [signoff] kernel26-2.6.38.2-1
by Tobias Powalowski 05 Apr '11

05 Apr '11

Hi guys, please signoff 2.6.38 series for both arches. Upstream changes: http://kernelnewbies.org/LinuxChanges Features included: - latest stable patches - disabled /dev/kmem - added AMD_IOMMU support - kernel image is now xz compressed - NUMA is enabled on x86_64 - AUTOSCHED (aka the wonder patch) is enabled - aufs2.1 latest snapshot - added additional i915 patch - added radeaon kms fix greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

11 16

[arch-general] pacman: downloading without "looking for inter-conflicts"?
by Magnus Therning 03 Apr '11

03 Apr '11

Is there some way of downloading upgradable packages without running the "looking for inter-conflicts" step? I have a locally modified broadcom-wl package[1], the modification is a dependency on the specific version of the kernel (in order to avoid the all too common situation where I updated the kernel and promptly lost connectivity). What I'd really like to do is download all upgradable packages, then remove connectivity in a controlled way, perform the upgrade from the local cache, re-boot, re-build the broadcom-wl package. I fail at this since 'pacman -Suw' won't download upgradable packages if there are "inter-conflicts" (in my case caused by my broadcom-wl package). Is there some way to get pacman to perform the download without "looking for inter-conflicts"? /M [1]: http://aur.archlinux.org/packages.php?ID=19514 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus

3 4

[arch-general] ArchLinux for mipsel (Loongson)
by Heiher 31 Mar '11

31 Mar '11

Hello, Main page : http://dev.lemote.com:2001/ Docs : http://dev.lemote.com:2001/archlinux/other/docs/ -- Best regards! Heiher

1 0

[arch-general] [signoff] kernel26 2.6.37.6-1
by Tobias Powalowski 31 Mar '11

31 Mar '11

Upstream update. This package is NOT in testing (2.6.38 currently resides there), but at: http://dev.archlinux.org/~tpowa/kernel26/ please signoff for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] cancel request to reopen a feature request
by Kyle 31 Mar '11

31 Mar '11

Is there a way to cancel a request to reopen a feature request? Seems I jumped the gun just a little when I requested to reopen it, as the package release that implements the feature took a little time to get to my mirror of choice, and I based my request on the prior release. The task in question is #23517, and it should indeedd remain closed, as the feature has been implemented and I have successfully tested it. The error message I pasted in the task is from the previous release, which was still the latest version on my chosen mirror at the time I encountered the error. BTW, I would like to thank the Arch developers for such a quick response to my rather minor feature request. It was fixed just over two hours after I submitted it. You guys rock! ~Kyle

2 1

[arch-general] Display "Flicker" with 2.6.37.5-1 & nvidia 270.30-3 (dual head)
by David C. Rankin 30 Mar '11

30 Mar '11

Guys, Can anyone else confirm seeing display "Flicker" on startup with the new kernel and nvidia driver? What I mean by "Flicker" is that dark bands 1/8-1/4 screen wide (vertically) will appear as horizontal bars for a fraction of a second for the first few minutes after boot. (It is not hardware warming up/etc.. -- it happens on reboot as well and this box runs 24/7) The bars appear causing what looks like an old vertical timing sync problem on a CRT monitor, even though this is LCD. I am running dual-head and have seen other posts suggesting the problem is primarily a dual-head problem. After install of the new kernel and nvidia driver (2.6.37.5-1 & nvidia 270.30-3) the flicker was really bad, to the point I didn't think it was ever going to quit. The display has settled down, but I still get the flicker every time I switch desktops. (switching from desktop 1 -> desktop 2, with kpager) I don't know what software package may be at the bottom of this? (Xorg? Nvidia?) I would like to know if anyone else has experienced this and if you have any thoughts on which package it may be. Thanks. -- David C. Rankin, J.D.,P.E.

5 6

[arch-general] OHCI: work around for nVidia shutdown problem
by Andre "Osku" Schmidt 30 Mar '11

30 Mar '11

Hello, do you have a nvidia usb controller? and had/have problems with usb devices staying powered on after shutdown? this patch added in 2.6.37 had the opposite effect on my system: https://patchwork.kernel.org/patch/341321/ but the helpful devs found a solution: http://marc.info/?l=linux-usb&m=130142049527638&w=2 so in my system all is fine again. but, as i didn't find anyone with this problem (the first patch having the opposite effect) anywhere, i wanted to ask you if you can test this patch and tell if your nvidia usb controller still (or now) works as supposed. if desired, i can also tell when (if) this patch gets included upstream. (so you don't need to hassle with this patch, but know when to check) cheers .andre

1 0