February 2010 - Arch-general - lists.archlinux.org

[arch-general] Was the kernel suspend to disk feature removed on 2.6.32.8-1
by Javier Vasquez 20 Feb '10

20 Feb '10

Hi all, Previously I was having the following settings: /etc/default/grub ---------------------- GRUB_CMDLINE_LINUX_DEFAULT='resume=/dev/sda5' grub.cfg ----------- linux /vmlinuz26 root=/dev/sda7 ro resume=/dev/sda5 I have installed: acpitool 0.5.1-1 kernel26 2.6.32.8-1 And fro quiet a long time I've been using the kernel suspend feature through acpitool, so in order to suspend I've always done: acpitool -S As of now, it seems storing the state into the swap area is working. Problem is that when booting, the kernel is not even trying to see if there's state stored in the swap, since I don't see any message about it, and all I'm getting is plain boot. So I suspect the kernel is not compiled with built in support for suspend to disk. Is this true? Thanks, -- Javier.

3 3

[arch-general] [signoff] pciutils-3.1.7-1
by Tobias Powalowski 20 Feb '10

20 Feb '10

Hi bump to latest version. Please signoff both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] Recent upgrade of vim&gvim generates assertion errors in console
by LI Ye 19 Feb '10

19 Feb '10

Hi guys, Just paste my post from forum. Have you guys encountered this issue after recent upgrades of vim & gvim: ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed ** (gvim:17054): CRITICAL **: gtk_form_set_static_gravity: assertion `static_gravity_supported' failed This happens when running gvim in the console. It works all fine except the warnings. Downgrading to version 7.2.266 can avoid this. Best Regards -- LI Ye

3 2

[arch-general] pacman.conf: can I use wildcards?
by clemens fischer 19 Feb '10

19 Feb '10

I could not find any decisive answer in either the man page or on the web. Here's my question: in etc/pacman.conf, can I use entries such as: NoExtract = usr/share/man/man1/mkisofs* NoExtract = etc/logrotate.d/* or: NoUpgrade = etc/cron.daily/logrotate etc/logrotate.* clemens

9 16

[arch-general] CDROM cannot mount
by Thanos Zygouris 19 Feb '10

19 Feb '10

Hi gyus, i got a problem...(do not know how/when did it started though). I cannot mount CD roms...(i do not speak about automounting) Here is what "dmesg" tells: sr 5:0:0:0: [sr0] Unhandled sense code sr 5:0:0:0: [sr0] Result: hostbyte=0x00 driverbyte=0x08 sr 5:0:0:0: [sr0] Sense Key : 0x4 [current] sr 5:0:0:0: [sr0] ASC=0x3e ASCQ=0x2 sr 5:0:0:0: [sr0] CDB: cdb[0]=0x28: 28 00 00 00 e6 2a 00 00 02 00 end_request: I/O error, dev sr0, sector 235688 Buffer I/O error on device sr0, logical block 29461 I got more or less the same problem with almost all my data cds (i do not use audio ones) Also, i cannot even mount them manually (via mount /dev/cdrom0 <dir> or /dev/sr0/ <dir>) But one or two, mounts normally. (I use pcmanfm as a file manager, and yes i have ck-launch-session in my .xinitrc) The strange thing is that all of them can be mounted under Windows XP SP3...so it's not a hardware problem. Looked through Archlinux forums, but found nothing that i could use... Any clues? P.S.1 : Most of the CDs are bootable ones, writen with "cdrecord -v speed=8 dev=/dev/scd0 -data -tao -multi". They boot normally though. -- Beware of he who would deny you access to information, for in his heart he dreams himself your master.

3 9

[arch-general] Kernel 2.6.30 on EEE and KMS
by fons＠kokkinizita.net 19 Feb '10

19 Feb '10

Hello all, I'm installing Arch on an EEE. Following the wiki, I installed from a core image which hase 2.6.30, blocked its update, and then updated all the rest. Starting X I get this: (EE) intel(0): No kernel modesetting driver detected. Does this mean I'll need 2.6.32 anyway (and hence no Wifi) or are there other solutions ? TIA, -- FA O tu, che porte, correndo si ? E guerra e morte !

4 8

[arch-general] EEE 1000H - control of Wifi device
by fons＠kokkinizita.net 19 Feb '10

19 Feb '10

Hello all, A few days ago I installed Arch on an EEE-1000H. Things work very well and I'm sort of impressed by how easy it worked out to be (there were a few hickups but nothing serious). Today I discovered one possible problem. The key combination 'Fn + F2' enables or disables the wireless network device. If you hit it accidentally there's no more wifi. Using netcfg (I'm using the version from testing) doesn't bring it back, as the wlan0 device doesn't exist. The solution is hitting again 'Fn + F2', then netcfg the wireless profile. No big deal for me, but the end users of this machine are less technically inclined. So I'm looking for either - a way to disable the action of this key combination (while leaving the other F-keys intact), or - a way to re-enable the wireless device from a script. The trick mentioned on the EEE-901 wiki echo 1 > /sys/......./wlan0 doesn't work - there's no such file on the 1000H Any hints will be appreciated ! Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte !

8 14

[arch-general] new libdrm breaks nouveau
by Ray Kohler 19 Feb '10

19 Feb '10

After upgrading to the just-released libdrm 2.4.18-1 (and the new xorg-server), I can no longer start X: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0 (EE) [drm] failed to open device (EE) No devices detected. Fatal server error: no screens found I tried rebuilding xf86-video-nouveau against this new libdrm, but it doesn't compile: nouveau_xv.c: In function ‘nouveau_xv_bo_realloc’: nouveau_xv.c:251: error: ‘NOUVEAU_BO_TILED’ undeclared (first use in this function) nouveau_xv.c:251: error: (Each undeclared identifier is reported only once nouveau_xv.c:251: error: for each function it appears in.) make: *** [nouveau_xv.lo] Error 1 make: *** Waiting for unfinished jobs.... nv_accel_common.c: In function ‘NVAccelInitImageBlit’: nv_accel_common.c:273: error: ‘NV04_IMAGE_BLIT_DMA_NOTIFY’ undeclared (first use in this function) nv_accel_common.c:273: error: (Each undeclared identifier is reported only once nv_accel_common.c:273: error: for each function it appears in.) nv_accel_common.c:275: error: ‘NV04_IMAGE_BLIT_COLOR_KEY’ undeclared (first use in this function) nv_accel_common.c:279: error: ‘NV04_IMAGE_BLIT_CLIP_RECTANGLE’ undeclared (first use in this function) nv_accel_common.c:283: error: ‘NV04_IMAGE_BLIT_OPERATION’ undeclared (first use in this function) nv_accel_common.c:284: error: ‘NV04_IMAGE_BLIT_OPERATION_ROP_AND’ undeclared (first use in this function) nv_accel_common.c: In function ‘NVAccelInitScaledImage’: nv_accel_common.c:327: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_DMA_NOTIFY’ undeclared (first use in this function) nv_accel_common.c:337: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_COLOR_CONVERSION’ undeclared (first use in this function) nv_accel_common.c:338: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_COLOR_CONVERSION_DITHER’ undeclared (first use in this function) nv_accel_common.c:340: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_OPERATION’ undeclared (first use in this function) nv_accel_common.c:341: error: ‘NV04_SCALED_IMAGE_FROM_MEMORY_OPERATION_SRCCOPY’ undeclared (first use in this function) nv_accel_common.c: In function ‘NVAccelInitImageFromCpu’: nv_accel_common.c:436: error: ‘NV05_IMAGE_FROM_CPU_BETA4’ undeclared (first use in this function) nv_accel_common.c:439: error: ‘NV05_IMAGE_FROM_CPU_SURFACE’ undeclared (first use in this function) make: *** [nv_accel_common.lo] Error 1 Downgrading libdrm makes X work again. Is this already being worked on, or should I open a bug? If so, against which package, libdrm or xf86-video-nouveau?

2 3

[arch-general] netcfg v2.5.2 in [core]
by James Rayner 18 Feb '10

18 Feb '10

netcfg v2.5.2 This release brings a completely new auto wireless/wired configuration. The old net-auto is deprecated and no longer included. There are also some very minor configuration changes that may affect a few people. Move to new auto-wireless/wired The new automatic connection has proper roaming support and will prove more reliable than the old setup - particularly with more complicated wireless configurations. To migrate to the new automatic wireless setup: 1. pacman -S testing/wpa_actiond 2. Set WIRELESS_INTERFACE="" to your wireless interface in /etc/rc.conf. For example WIRELESS_INTERFACE="wlan0" 3. Add net-auto-wireless to your DAEMONS=() array. Note: wpa-config profiles do not work with this, convert them to wpa-configsection profiles. An example is included in /etc/network.d/examples/ The new auto-wired uses similar configuration - follow the above instructions except use the net-auto-wired daemon, and WIRED_INTERFACE configuration option. New features: - net-auto-wireless/wpa_actiond - Real wireless roaming/auto connection. Based on same principle as autowifi. Requires optional dependency: wpa_actiond - net-auto-wired - automatic ethernet configuration. Requires optional dependency: ifplugd - Interface configurations - set options for all profiles using an interface - Output hooks - Internal cleanup & improvement Internal changes: - Uses wpa_supplicant for all wireless configuration by default, including wep/none security. This adds improves support for most and should improve reliability. - Uses iproute by default for all static configuration. net_tools which contains ifconfig is effectively obsolete and hasnt seen a release for over 8 years. The 'ethernet-iproute' and 'ethernet' connection types have been merged together to simply 'ethernet'. All options are still supported and existing configurations will continue to work for both types. A symlink has been made to ensure that profiles using 'ethernet-iproute' will continue to function. Changes in configuration syntax - net-auto and AUTO_NETWORKS is now deprecated in favour of net-auto-wireless/net-auto-wired. - wireless: If you were previously specifying the wpa_supplicant driver in WPA_OPTS, you now need to specify it in WPA_DRIVER. - wireless: iwconfig based configuration for wep/none can be used by changing to wep-old or none-old. This should not be necessary and is left in place only for the possibility of very old drivers that do not support wpa_supplicant. - ethernet-iproute: As 'ethernet' is now iproute based, those using 'ethernet-iproute' can revert the name. There is a symlink in place, so existing configurations of either name will continue to function regardless. - wireless-dbus: Unsupported. The wpa_supplicant dbus interface isn't particularly well documented and it doesn't fit well into the netcfg codebase. There is a symlink in place so that configurations using wireless-dbus will continue to function using the 'wireless' connection scripts. Download: netcfg 2.5.2 is in [core]. Source: ftp://ftp.archlinux.org/other/netcfg/netcfg-2.5.2.tar.gz PKGBUILD: In subversion Documentation: http://wiki.archlinux.org/index.php/Network_Profiles Contributors: I had a few big contributors to this release: Jim Pryor: Many internal changes and improvements Thomas Bächler: wpa_actiond based auto roaming/connection Thanks guys! Bugs: On the bug tracker as always.

2 1

[arch-general] Pacman Error: upgrading to same package version again & again
by Gaurish Sharma 17 Feb '10

17 Feb '10

Hi, Pacman is acting weird. Its asking me to upgrade same set of packages over & over. Even, I have just updated said packages.I posted my query on forums[1] but helpful reply. So posting it here: gaurish ~ > upgrade :: Synchronizing package databases... core 35.9K 21.8K/s 00:00:02 [#####################################################################] 100% extra 445.1K 31.6K/s 00:00:14 [#####################################################################] 100% community is up to date :: Starting full system upgrade... warning: go-openoffice: ignoring package upgrade (3.2.0.4-1 => 3.2.0.5-1) resolving dependencies... looking for inter-conflicts... Targets (8): flashplugin-10.0.45.2-1 fuse-2.8.3-1 gstreamer0.10-base- plugins-0.10.26-1 soprano-2.4.0.1-1 kdelibs-4.4.0-4 ppp-2.4.5-1 rp-pppoe-3.10-4 vi-050325-2 Total Download Size: 0.15 MB Total Installed Size: 97.46 MB Proceed with installation? [Y/n] y :: Retrieving packages from core... vi-050325-2-x86_64 158.3K 17.8K/s 00:00:09 [#####################################################################] 100% checking package integrity... (8/8) checking for file conflicts [#####################################################################] 100% (1/8) upgrading flashplugin [#####################################################################] 100% (2/8) upgrading fuse [#####################################################################] 100% (3/8) upgrading gstreamer0.10-base-plugins [#####################################################################] 100% (4/8) upgrading soprano [#####################################################################] 100% (5/8) upgrading kdelibs [#####################################################################] 100% (6/8) upgrading ppp [#####################################################################] 100% (7/8) upgrading rp-pppoe [#####################################################################] 100% >>> The kernel-mode plugin has a new place. >>> It's now located under /usr/lib/rp-pppoe/rp-pppoe.so >>> Change LINUX_PLUGIN to the new path in your /etc/ppp/pppoe.conf (8/8) upgrading vi [#####################################################################] 100% Now If I run the update again, it still asks to upgrade same set of packages again. gaurish ~ > upgrade :: Synchronizing package databases... core is up to date extra is up to date community is up to date :: Starting full system upgrade... warning: go-openoffice: ignoring package upgrade (3.2.0.4-1 => 3.2.0.5-1) resolving dependencies... looking for inter-conflicts... Targets (7): flashplugin-10.0.45.2-1 fuse-2.8.3-1 gstreamer0.10-base- plugins-0.10.26-1 soprano-2.4.0.1-1 kdelibs-4.4.0-4 ppp-2.4.5-1 rp-pppoe-3.10-4 Total Download Size: 0.00 MB Total Installed Size: 97.12 MB Proceed with installation? [Y/n] y checking package integrity... (7/7) checking for file conflicts [#####################################################################] 100% (1/7) upgrading flashplugin [#####################################################################] 100% (2/7) upgrading fuse [#####################################################################] 100% (3/7) upgrading gstreamer0.10-base-plugins [#####################################################################] 100% (4/7) upgrading soprano [#####################################################################] 100% (5/7) upgrading kdelibs [#####################################################################] 100% (6/7) upgrading ppp [#####################################################################] 100% (7/7) upgrading rp-pppoe [#####################################################################] 100% >>> The kernel-mode plugin has a new place. >>> It's now located under /usr/lib/rp-pppoe/rp-pppoe.so >>> Change LINUX_PLUGIN to the new path in your /etc/ppp/pppoe.conf This errors is weird and I also have fsck root, /home partition . I would apreciate your help in solving this [1] http://bbs.archlinux.org/viewtopic.php?id=91207

4 4