- Arch-general - lists.archlinux.org

[arch-general] Huge log file for SLiM
by Sébastien Leblanc 04 Jul '12

04 Jul '12

Dearest Arch Linux Mailing List, So I was installing a few packages on a fairly recent Arch install, when I got an error message from pacman: --------8<--------8<--------8<--------8<-------- : Retrieving packages from community... error: failed retrieving file '<package>' from <mirror1> : Failed writing body (1435 != 1448) error: failed retrieving file '<package>' from <mirror2> : Failed writing body (104 != 4344) error: failed retrieving file '<package>' from <mirror3> : Failed writing body (6 != 2896) warning: failed to retrieve some files from community error: failed to commit transaction (download library error) Errors occurred, no packages were upgraded. --------8<--------8<--------8<--------8<-------- I immediately thought of a full hard drive. `df` reported that my / partition was full. My root FS partition is around 33G in size: that's not huge, but since it is a fairly recent install, I thought there was no way it could be normally that full. I ran `du -sh` on things in my / drive, and it reported that /var/log was using up 27G of space. The culprit was SLiM's log: it was making up 99.99394 of all the space occupied by logs on my system. For some reason, log rotation does not occur with SLiM on my system. All other applications with logs work fine. Is anyone having this issue? I could not test it on other systems as it is the only one I have running SLiM. -- Sébastien Leblanc

7 8

[arch-general] Can't suspend or hibernate
by Brock York 04 Jul '12

04 Jul '12

Hey I haven't been able to suspend my desktop for about 6 months now. I'm not sure what has caused it. I haven't had any hardware changes and even a reload hasn't fixed the problem. I've tried reading the wiki on suspending and run some tests using pm-suspend. It suspends processes fine according to the guide I was following, but it seems to get stuck at suspending hardware. I tried disabling as many modules as possible to then get it to suspend but still no luck. Is anyone else having this problem or has anyone fixed this problem? Regards Brock

3 4

[arch-general] Installing to RAID .. cannot reboot
by D. R. Evans 04 Jul '12

04 Jul '12

I have carefully followed the RAID instructions at: https://wiki.archlinux.org/index.php/Software_RAID_and_LVM#RAID_installation I have not used LVM, just RAID. I have double-checked what I actually did, and believe that I did exactly what the page tells me to do. I have two identical drives, which I configured as RAID1. At the conclusion of the installation, the instructions say: ---- Once it is complete you can safely reboot your machine: # reboot ---- When I try to reboot, I receive the error message: ERROR: device /dev/md0 not found ERROR: unable to find root device /dev/md0 What do I have to do to get past this error? Doc PS I tried to go back to the very beginning and walk through the instructions again, but when I do that, when I reach this step: mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sd[cd]3 I am now informed that /dev/sdc3 is busy or unavailable. -- Web: http://www.sff.net/people/N7DR

8 25

[arch-general] Country Name (ISO-3116) Issues
by Zero, Chien-An Cho 04 Jul '12

04 Jul '12

Hello, First of all, I am sorry to bring political issues to here. I have been using ArchLinux for years, deployed on many servers, though I'm not joining the community until now. The recent changes to the ArchLinux webpages (ex. Downloads, Mirror Status) is really offending Taiwanese people. I would like to bring up this issue, and preferably to resolve this issue. I have posted this message on the forum: https://bbs.archlinux.org/viewtopic.php?id=144315 . The moderator suggested me to post on arch-general, so here it is. :) There is also a bug tracking issue submitted by other Taiwanese user that I'm requesting for reopen here: https://bugs.archlinux.org/task/30444 The following text is the same as the post on forum, except a few modification to make text smoother. The recent changes on the download page named Taiwan as Taiwan, Province of China, which is not reflecting the truth that Taiwan is a independent country which having its own government. I think this might be caused by following the ISO-3166 country name list standard. However, I don't think ISO-3166 is a good list when it comes to the country name. Many open source communities have encountered this problem before. Most of them understand that ISO-3166 is not really a neutral list that we all hope for, and thus made switch to a separate maintained country list. For example, FreeBSD[1], Rails[2], Debian[3]. Many big commercial entities also opt not to use "Taiwan, PRC" in their country list, like: Apple[4], IBM[5], also try Google, Facebook, Twitter, et cetra. A possible solution might be using the country name list from ICU[6]. I believed the ArchLinux is trying to expand its user-base around the world, so a neutral country name list would be the best for the benefit of all of us, ArchLinux developers and users. As a Taiwanese ArchLinux user, I'm really happy to see that user base of ArchLinux is growing in Taiwan. Some educational institutions provide mirrors site in Taiwan, Wiki localized in Traditional Chinese in the recent years. I sincerely hope this issue can be resolved as soon as possible. Let's keep the issue simple and not flaming it, thanks. References: [1] FreeBSD: http://www.freebsd.org/cgi/query-pr.cgi?pr=138672 [2] Rails: http://www.koziarski.net/archives/2008/9/24/countries-and-controversies/ [3] Debian: http://lists.debian.org/debian-devel/2004/04/msg00798.html [4] Apple: http://www.apple.com/choose-your-country/ [5] IBM: http://www.ibm.com/planetwide/select/selector.html [6] ICU: http://source.icu-project.org/repos/icu/icu/trunk/source/data/region/en.txt Best Regards, Chien-An "Zero" Cho

15 21

Re: [arch-general] [arch-dev-public] final leg of /lib removal
by Oon-Ee Ng 04 Jul '12

04 Jul '12

On Tue, Jul 3, 2012 at 11:41 PM, Dave Reisner <d(a)falconindy.com> wrote: <snip> > - linux, linux-lts (diff for linux here: http://paste.xinu.at/LLd/) <snip> I'm basing my modifications to my PKGBUILDs on this, simple enough, but a simple observation - ${pkgdir} is used throughout the PKGBUILD except in the diff =) ditto for ${_kernver}

1 0

[arch-general] initscripts 20120631 and BTRFS
by Arno Gaboury 03 Jul '12

03 Jul '12

Dear list, I refer to this bug report: > https://bugs.archlinux.org/task/30517 I have exactly the same situation at boot, and this didn't happend before. Form my kernel.log: > Jul 3 16:27:01 localhost kernel: [ 240.373550] INFO: task > btrfs-transacti:353 blocked for more than 120 seconds. > Jul 3 16:27:01 localhost kernel: [ 240.373554] "echo 0 > > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Jul 3 16:27:01 localhost kernel: [ 240.373557] btrfs-transacti D > ffff880402ae3b58 0 353 2 0x00000000 > Jul 3 16:27:01 localhost kernel: [ 240.373562] ffff880402bc3c80 > 0000000000000046 ffff880402ae3790 ffff880402bc3fd8 > Jul 3 16:27:01 localhost kernel: [ 240.373568] ffff880402bc3fd8 > ffff880402bc3fd8 ffff880408daa7b0 ffff880402ae3790 > Jul 3 16:27:01 localhost kernel: [ 240.373580] ffff88041f493740 > 0000000000013740 ffff880400000000 ffff880402bc3bc8 > Jul 3 16:27:01 localhost kernel: [ 240.373583] Call Trace: > Jul 3 16:27:01 localhost kernel: [ 240.373590] [<ffffffff81013580>] > ? __switch_to+0x120/0x410 > Jul 3 16:27:01 localhost kernel: [ 240.373595] [<ffffffff81468b29>] > schedule+0x29/0x70 > Jul 3 16:27:01 localhost kernel: [ 240.373598] [<ffffffff81468df7>] > schedule_preempt_disabled+0x27/0x40 > Jul 3 16:27:01 localhost kernel: [ 240.373600] [<ffffffff814674a8>] > __mutex_lock_slowpath+0x148/0x340 > Jul 3 16:27:01 localhost kernel: [ 240.373603] [<ffffffff814676b6>] > mutex_lock+0x16/0x30 > Jul 3 16:27:01 localhost kernel: [ 240.373625] [<ffffffffa013d2bb>] > btrfs_run_ordered_operations+0x3b/0x210 [btrfs] > Jul 3 16:27:01 localhost kernel: [ 240.373636] [<ffffffffa011d3a4>] > btrfs_commit_transaction+0x74/0xaa0 [btrfs] > Jul 3 16:27:01 localhost kernel: [ 240.373646] [<ffffffffa011ca4c>] > ? join_transaction.isra.22+0x2dc/0x310 [btrfs] > Jul 3 16:27:01 localhost kernel: [ 240.373650] [<ffffffff81073b60>] > ? abort_exclusive_wait+0xb0/0xb0 > Jul 3 16:27:01 localhost kernel: [ 240.373660] [<ffffffffa0115e25>] > transaction_kthread+0x235/0x2b0 [btrfs] > Jul 3 16:27:01 localhost kernel: [ 240.373669] [<ffffffffa0115bf0>] > ? btrfs_alloc_root+0x50/0x50 [btrfs] > Jul 3 16:27:01 localhost kernel: [ 240.373671] [<ffffffff810731d3>] > kthread+0x93/0xa0 > Jul 3 16:27:01 localhost kernel: [ 240.373674] [<ffffffff8146bbe4>] > kernel_thread_helper+0x4/0x10 > Jul 3 16:27:01 localhost kernel: [ 240.373677] [<ffffffff81073140>] > ? kthread_freezable_should_stop+0x70/0x70 > Jul 3 16:27:01 localhost kernel: [ 240.373680] [<ffffffff8146bbe0>] > ? gs_change+0x13/0x13 Is it really a bug, or did I miss something or did something wrong? TY for any advise.

3 4

[arch-general] Error when upgrading "reflector"
by Benjamin Boudreau 03 Jul '12

03 Jul '12

Just got when doing a pacman -Syu: reflector-2012.7.1-1-any 10.8 KiB 672K/s 00:00 [#############################] 1 ... (14/14) checking for file conflicts [#############################] 100% error: failed to commit transaction (conflicting files) reflector: /usr/lib/python3.2/site-packages/__pycache__/Reflector.cpython-32.pyc exists in filesystem Should I force the update? --Benjamin Boudreau

5 4

Re: [arch-general] compact view removed from Nautilus
by Kevin Chadwick 03 Jul '12

03 Jul '12

On Tue, 3 Jul 2012 09:26:57 +0200 Olav Vitters wrote: > You have command line tools for gconf as well as dconf: > gconftool-2 > gsettings That's two interfaces that depend on installed binaries and you haven't listed them all yet, not only is the syntax rediculously long compared to for example a sed command but it certainly isn't a truly universal interface that would work from say even a minimal boot cd or even a hexeditor or by hand. Apparently they are meant to make it easier for administrators, yet they cost us time. I guess more user testing as well as dev testing is required.

1 0

[arch-general] Asked for PIN during pairing of Bluetooth mouse
by Karol Babioch 03 Jul '12

03 Jul '12

Hi, I'm pretty sure that this is an upstream issue, but to narrow things down and to verify and/or falsify my experience, I'm asking here first. Basically it is about my Bluetooth mouse (Speedlink Saphyr Bluetooth). I paired it some time ago (half a year or something like that) and it worked fine until now, even with the latest packages. However for some other reason I had to delete the pairing and repeat the process of pairing. Surprisingly I've realized that this isn't possible anymore using GNOME Bluetooth. During the process of pairing (after the mouse is discovered and I want to proceed), I'm asked whether the PIN displayed within GNOME Bluetooth matches the one on the device. Obviously the mouse itself by no means can actually display anything, so this seems odd and wasn't the case back when I paired it initially. Regardless of whether I decide to click on the button that says that they match or the one that says that they doesn't, the process of pairing fails. However I can connect the mouse to my computer by using hidd directly (hidd --connect xx:xx:xx:xx:xx:xx), although this is not a long term solution as it has to be repeated every single time it gets disconnected. I'm now wondering whether anyone of you has also experienced this? I haven't yet looked into it, so I'm not sure whether this is a problem of Gnome Bluetooth itself, or whether there gets something messed up further down in the Bluetooth stack. Maybe some of you could try to repair their Bluetooth mouse (and/or equipment). But be aware that I haven't found a way to pair it permanently once again, so probably you either want to do this in a test environment and/or save your Bluetooth settings beforehand somehow. Thanks in advance! Best regards, Karol Babioch

1 1

[arch-general] Custom libexecdir not recommended for gnome
by Clemens Buchacher 03 Jul '12

03 Jul '12

Hi, I'd like to bring to your attention the discussion surrounding gnome-shell/networkmanager bug #679212 (NetworkManager VPN secrets: NetworkAgent internal error): https://bugzilla.gnome.org/show_bug.cgi?id=679212 A fix for this particular bug is under way. The cause for the bug was Arch Linux's use of different libexecdirs for gnome-shell and networkmanager plugins (/usr/lib/gnome-shell and /usr/lib/networkmanager, respectively), instead of the default /usr/libexec. This is in accordance with Arch Packaging Standards: "Avoid using /usr/libexec/ for anything. Use /usr/lib/${pkgname}/ instead." [1] What is the motivation for this rule? In response to the above bug report, a gnome-shell dev says that he "could consider this weird libexecdir setting a distribution problem." Since this seems to be an unusual setting, I suspect that there might still be many more bugs lurking around for which Arch Linux plays beta tester. Indeed, this is not the first time that I am having trouble with Arch Linux packages using custom installation directories [2]. Maybe it's not such a big deal and it's just me having some tough luck (2 events do not make a good statistic). But expectations upstream seem to contradict the Arch Linux rule, so I wanted to bring it up for discussion. Clemens [1] https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Package_etiqu… [2] http://gnu-octave-repository.2306053.n4.nabble.com/geometry-1-4-0-cannot-ha…

6 8