- Arch-general - lists.archlinux.org

Re: [arch-general] [arch-dev-public] dbscripts fails to move split packages
by Evangelos Foutras 05 Sep '10

05 Sep '10

On Sun, Sep 5, 2010 at 5:23 PM, Ionuț Bîru <ibiru(a)archlinux.org> wrote: > On 09/05/2010 05:18 PM, Ionuț Bîru wrote: >> >> Hi, >> i tried to move vim from testing into extra and it failed. >> >> $ arch/db-move >> ==> usage: db-move <repo-from> <repo-to> <pkgname|pkgbase> ... >> $ /arch/db-move testing extra vim >> ==> Moving packages from [testing] to [extra]... >> -> vim (i686) >> -> vim (x86_64) >> $ /arch/db-move testing extra vim-runtime >> ==> ERROR vim-runtime not found in testing >> ==> Removing left over lock from [extra] (i686) >> ==> Removing left over lock from [testing] (i686) >> ==> Removing left over lock from [extra] (x86_64) >> ==> Removing left over lock from [testing] (x86_64) >> >> >> is it safe to do it manually ? >> >> > > false alarm. it looks like only the output is kinda wrong :) > > -- > Ionuț It looks like the first command took care of all the split packages. The usage message also mentions pkgbase, so this would be expected behavior.

1 0

Re: [arch-general] [arch-dev-public] [signoff] sudo-1.7.4.p3-1
by Florian Pritz 05 Sep '10

05 Sep '10

On 05.09.2010 15:30, Allan McRae wrote: > On 22/08/10 17:46, Ionuț Bîru wrote: >> On 08/22/2010 07:39 AM, Allan McRae wrote: >>> Upstream bug fix release. >>> >>> Signoff both, >>> Allan >>> >> >> signoff x86_64 >> > > Any chance of an i686? i686 signoff -- Florian Pritz -- {flo,bluewind}@server-speed.net

3 2

[arch-general] How to convert a 32-bit system to 64-bit?
by Lauri Niskanen 05 Sep '10

05 Sep '10

I have a working 32-bit Arch Linux server. It's more like a testing playground than a production server. I decided to convert it to a 64-bit system. I could reinstall Arch, but is there any easier way to do the "upgrade"? I'd like to retain my list of applications, configuration and user files. -- Ape <Lauri Niskanen>

3 2

[arch-general] X11 crashes after pacman -Syu
by Samuel Baldwin 04 Sep '10

04 Sep '10

I recently updated my system with pacman -Syu; everything worked fine, but since I've rebooted the machine, running 'startx' causes X to start, I see the 'nvidia' logo flash, and then crash. I updated 'nvidia', but now when it starts it complains of being unable to allocate DMA memory and aborts. My Xorg.0.log is here: http://sprunge.us/GOLS -- Samuel Baldwin - logik.li

4 9

Re: [arch-general] [arch-dev-public] The "Great Python Rebuild of 2010" begins
by Christopher Brannon 03 Sep '10

03 Sep '10

Rémy Oudompheng <remyoudompheng(a)gmail.com> writes: > I have generated the attached quick-and-dirty list of safe packages > from the wiki. There could be false positives, of course. ===begin list=== *SNIP* > jython Actually, this doesn't need a rebuild at all. jython doesn't rely on the C implementation of Python for anything. It made the rebuild list, because some of the files in its standard library start with #!/usr/bin/python lines. Should I just flag it as done? *SNIP* > python-foolscap This one installs things under /usr/lib/python2.6, so it doesn't belong in this list. *SNIP REST* ===end list=== -- Chris

1 0

[arch-general] kde 4.5.1-1 looks much better.
by David C. Rankin 03 Sep '10

03 Sep '10

Guys, Even from a kde4 hater, kde 4.5.1-1 is looking much better than prior releases. Way to go Arch on the packaging. It is starting to add some of the efficiencies k3 had that k4 has lacked. Simple case-in-point, just rt-click to change the desktop wp and you now have a clean 3 column thumbnail setup that provides 300% more info than the old slow single column thumbnail list. Not earth-shattering, but it is good to see some of the really awkward dialogs getting reworked. Don't get me wrong, k4 still needs work, but I'm more than willing to tip my hat and recognize good progress when it has been made despite the 2.5 years of hell I've been though with that desktop. (as an aside - the 3D chessboard wallpaper is just killer) We shall see where it goes... -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

6 8

[arch-general] dovecot.conf kills update (conflicting file)
by David C. Rankin 03 Sep '10

03 Sep '10

Guys, The dovecot update needs to be fixed. Currently, on upgrade you get: checking package integrity... (288/288) checking for file conflicts [#####################################] 100% error: failed to commit transaction (conflicting files) dovecot: /etc/dovecot/dovecot.conf exists in filesystem Errors occurred, no packages were upgraded. which is a bit frustrating. I know we talked a little about fixing dovecot (and other packages that break if upgraded but not restarted) so I don't know if this is related (I thought the discussion/debate was whether to add a one-liner advising that a dovecot restart was required), but in any event, related or not, dovecot should update without failing due to the existing dovecot.conf Do I open a ticket or is this post enough? I have asked this question of whether to open a ticket on every bug or whether little items like this are preferred to be worked from the list w/o a ticket opened at least 3 times now and I have never received an answer (I apologize if I have missed it). I want to help Arch the best way I can. If you want bugs opened on everything, let me know -- I'm happy to open them. If you can work an issue from the list, then at least let me know "I'll take it from here" so I know things are not being missed. Thanks. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

4 12

[arch-general] Fwd: Re: [Nut-upsdev] usbhid-ups causing hang on boot with 2.6.35 - any ideas?
by David C. Rankin 03 Sep '10

03 Sep '10

Guys, Below are the thoughts from the NUT developer on what to check in the Arch NUT package to see if recent changes to udev bus designations, and permission are incorporated. My guess is that it is udev related since 50% of the time it boots and loads usbhid-ups just fine and everything works, other times, it hangs loading usbhid-ups and nothing works. Hope this helps. -------- Original Message -------- Subject: Re: [Nut-upsdev] usbhid-ups causing hang on boot with 2.6.35 - any ideas? Date: Fri, 03 Sep 2010 10:49:27 +0200 From: Arjen de Korte <nut%2Bdevel(a)de-korte.org> To: nut-upsdev(a)lists.alioth.debian.org Citeren "David C. Rankin" <drankinatty>: > (Arjen - I apologize if you get two copies, I sent the first one to > the old de-korte.org address) That address isn't old, but the mailserver is configured to only accept messages from the mailinglist server. > Aug 30 20:31:03 archangel upsd[2295]: listening on 192.168.6.14 port 3493 > Aug 30 20:31:03 archangel upsd[2295]: listening on 127.0.0.1 port 3493 > Aug 30 20:31:03 archangel upsd[2295]: Can't connect to UPS > [archangel_ups] (usbhid-ups-archangel_ups): No such file or directory This means the driver isn't running (but you probably already knew that). > Aug 30 20:31:03 archangel upsd[2296]: Startup successful > Aug 30 20:31:03 archangel upsmon[2298]: Startup successful > Aug 30 20:31:03 archangel upsmon[2300]: Login on UPS > [archangel_ups@localhost] failed - got [ERR ACCESS-DENIED] > Aug 30 20:31:03 archangel upsmon[2300]: Login on UPS > [nirvana_ups(a)nirvana.3111skyline.com] failed - got [ERR ACCESS-DENIED] The above two error messages indicate there is a problem with logging into the server. You could run the server in debug mode, but my guess is this has to do with either NUT being build with tcp-wrappers support and you failed setting this up properly (see 'man 8 upsd') or the credentials you're using are incorrect. [...] > Looks like some type of udev issue or kernel issue, but I > thought I would check here to see if you guys have any more info on > the problem. Anybody seen this behavior before? This looks like the udev rules are incorrect. If memory serves, there have been some changes in the syntax (BUS was changed to SUBSYSTEMS). Other than that, there are no known issues. Best regards, Arjen -- Please keep list traffic on the list (off-list replies will be rejected) _______________________________________________ Nut-upsdev mailing list Nut-upsdev(a)lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

1 0

[arch-general] 2.6.35.4-1 still hangs waiting on udev with usbhid errors
by David C. Rankin 03 Sep '10

03 Sep '10

Guys, There are still usbhid-ups problem on boot that hang the boot and don't configure the usbhid-ups driver. This is a flakey issue. I have booted twice, hung the first time (errors below), rebooted and got by the udev/usbhid load in boot and upsmonitoring worked fine. The problem is, there is no way I can remotely administer this box with a 50% chance of it hanging on boot. Any ideas? Here is the error log from everything.log Aug 30 20:30:28 archangel kernel: eth0: no IPv6 routers present Aug 30 20:30:30 archangel kdm_greet[2283]: Cannot load /usr/share/apps/kdm/faces/.default.face: No such file or directory Aug 30 20:31:03 archangel upsd[2295]: listening on 192.168.6.14 port 3493 Aug 30 20:31:03 archangel upsd[2295]: listening on 127.0.0.1 port 3493 Aug 30 20:31:03 archangel upsd[2295]: Can't connect to UPS [archangel_ups] (usbhid-ups-archangel_ups): No such f ile or directory Aug 30 20:31:03 archangel upsd[2296]: Startup successful Aug 30 20:31:03 archangel upsmon[2298]: Startup successful Aug 30 20:31:03 archangel upsmon[2300]: Login on UPS [archangel_ups@localhost] failed - got [ERR ACCESS-DENIED] Aug 30 20:31:03 archangel upsmon[2300]: Login on UPS [nirvana_ups(a)nirvana.3111skyline.com] failed - got [ERR ACC ESS-DENIED] Aug 30 20:31:06 archangel kernel: INFO: task modprobe:1579 blocked for more than 120 seconds. Aug 30 20:31:06 archangel kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Aug 30 20:31:06 archangel kernel: modprobe D 0000000000000000 0 1579 1576 0x00000000 Aug 30 20:31:06 archangel kernel: ffff88022616da28 0000000000000082 ffffffff8167eb00 ffff880200000000 Aug 30 20:31:06 archangel kernel: 0000000000014f40 0000000000014f40 ffff88022616dfd8 ffff88022616dfd8 Aug 30 20:31:06 archangel kernel: ffff88022616dfd8 ffff8802269c1bc0 ffff88022616dfd8 0000000000014f40 Aug 30 20:31:06 archangel kernel: Call Trace: Aug 30 20:31:06 archangel kernel: [<ffffffffa0202ba5>] usb_kill_urb+0x85/0xc0 [usbcore] Aug 30 20:31:06 archangel kernel: [<ffffffff810718d0>] ? autoremove_wake_function+0x0/0x40 Aug 30 20:31:06 archangel kernel: [<ffffffffa02e0831>] usbhid_init_reports+0xb1/0x120 [usbhid] Aug 30 20:31:06 archangel kernel: [<ffffffffa02e0d53>] usbhid_start+0x4b3/0x5a0 [usbhid] Aug 30 20:31:06 archangel kernel: [<ffffffffa02ca6d8>] hid_device_probe+0x98/0xe0 [hid] Aug 30 20:31:06 archangel kernel: [<ffffffff812877ea>] ? driver_sysfs_add+0x5a/0x90 Aug 30 20:31:06 archangel kernel: [<ffffffff81287ac6>] driver_probe_device+0x96/0x1c0 Aug 30 20:31:06 archangel kernel: [<ffffffff81287c90>] ? __device_attach+0x0/0x60 Aug 30 20:31:06 archangel kernel: [<ffffffff81287cdb>] __device_attach+0x4b/0x60 Aug 30 20:31:06 archangel kernel: [<ffffffff812866a4>] bus_for_each_drv+0x64/0x90 Aug 30 20:31:06 archangel kernel: [<ffffffff8128795f>] device_attach+0x8f/0xb0 Aug 30 20:31:06 archangel kernel: [<ffffffff81287115>] bus_probe_device+0x25/0x40 Aug 30 20:31:06 archangel kernel: [<ffffffff81284e5f>] device_add+0x4ff/0x5e0 Aug 30 20:31:06 archangel kernel: [<ffffffffa02ca0a7>] hid_add_device+0x87/0x1b0 [hid] Aug 30 20:31:06 archangel kernel: [<ffffffffa02de4b9>] usbhid_probe+0x329/0x500 [usbhid] Aug 30 20:31:06 archangel kernel: [<ffffffffa0207a2b>] usb_probe_interface+0xfb/0x1f0 [usbcore] Aug 30 20:31:06 archangel kernel: [<ffffffff81287ac6>] driver_probe_device+0x96/0x1c0 Aug 30 20:31:06 archangel kernel: [<ffffffff81287c8b>] __driver_attach+0x9b/0xa0 Aug 30 20:31:06 archangel kernel: [<ffffffff81287bf0>] ? __driver_attach+0x0/0xa0 Aug 30 20:31:06 archangel kernel: [<ffffffff812869fe>] bus_for_each_dev+0x5e/0x90 Aug 30 20:31:06 archangel kernel: [<ffffffff81287789>] driver_attach+0x19/0x20 Aug 30 20:31:06 archangel kernel: [<ffffffff81287297>] bus_add_driver+0xc7/0x2e0 Aug 30 20:31:06 archangel kernel: [<ffffffff81287f01>] driver_register+0x71/0x140 Aug 30 20:31:06 archangel kernel: [<ffffffffa02066f8>] usb_register_driver+0xb8/0x170 [usbcore] Aug 30 20:31:06 archangel kernel: [<ffffffffa0299000>] ? hid_init+0x0/0xd1 [usbhid] Aug 30 20:31:06 archangel kernel: [<ffffffffa0299093>] hid_init+0x93/0xd1 [usbhid] Aug 30 20:31:06 archangel kernel: [<ffffffff81002149>] do_one_initcall+0x39/0x1a0 Aug 30 20:31:06 archangel kernel: [<ffffffff8108cefb>] sys_init_module+0xbb/0x200 Aug 30 20:31:06 archangel kernel: [<ffffffff81009e82>] system_call_fastpath+0x16/0x1b Aug 30 20:31:08 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:08 archangel upsmon[2300]: Communications with UPS archangel_ups@localhost lost Aug 30 20:31:08 archangel wall[2302]: wall: user nut broadcasted 1 lines (54 chars) Aug 30 20:31:13 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:13 archangel upsmon[2300]: UPS archangel_ups@localhost is unavailable Aug 30 20:31:13 archangel wall[2305]: wall: user nut broadcasted 1 lines (44 chars) Aug 30 20:31:18 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:23 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:28 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:33 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:38 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:43 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:48 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:53 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:31:58 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:03 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:08 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:13 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:18 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:23 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:28 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:33 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:38 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:43 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:48 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:53 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:32:58 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:33:03 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:33:06 archangel kernel: INFO: task modprobe:1579 blocked for more than 120 seconds. Aug 30 20:33:06 archangel kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Aug 30 20:33:06 archangel kernel: modprobe D 0000000000000000 0 1579 1576 0x00000000 Aug 30 20:33:06 archangel kernel: ffff88022616da28 0000000000000082 ffffffff8167eb00 ffff880200000000 Aug 30 20:33:06 archangel kernel: 0000000000014f40 0000000000014f40 ffff88022616dfd8 ffff88022616dfd8 Aug 30 20:33:06 archangel kernel: ffff88022616dfd8 ffff8802269c1bc0 ffff88022616dfd8 0000000000014f40 Aug 30 20:33:06 archangel kernel: Call Trace: Aug 30 20:33:06 archangel kernel: [<ffffffffa0202ba5>] usb_kill_urb+0x85/0xc0 [usbcore] Aug 30 20:33:06 archangel kernel: [<ffffffff810718d0>] ? autoremove_wake_function+0x0/0x40 Aug 30 20:33:06 archangel kernel: [<ffffffffa02e0831>] usbhid_init_reports+0xb1/0x120 [usbhid] Aug 30 20:33:06 archangel kernel: [<ffffffffa02e0d53>] usbhid_start+0x4b3/0x5a0 [usbhid] Aug 30 20:33:06 archangel kernel: [<ffffffffa02ca6d8>] hid_device_probe+0x98/0xe0 [hid] Aug 30 20:33:06 archangel kernel: [<ffffffff812877ea>] ? driver_sysfs_add+0x5a/0x90 Aug 30 20:33:06 archangel kernel: [<ffffffff81287ac6>] driver_probe_device+0x96/0x1c0 Aug 30 20:33:06 archangel kernel: [<ffffffff81287c90>] ? __device_attach+0x0/0x60 Aug 30 20:33:06 archangel kernel: [<ffffffff81287cdb>] __device_attach+0x4b/0x60 Aug 30 20:33:06 archangel kernel: [<ffffffff812866a4>] bus_for_each_drv+0x64/0x90 Aug 30 20:33:06 archangel kernel: [<ffffffff8128795f>] device_attach+0x8f/0xb0 Aug 30 20:33:06 archangel kernel: [<ffffffff81287115>] bus_probe_device+0x25/0x40 Aug 30 20:33:06 archangel kernel: [<ffffffff81284e5f>] device_add+0x4ff/0x5e0 Aug 30 20:33:06 archangel kernel: [<ffffffffa02ca0a7>] hid_add_device+0x87/0x1b0 [hid] Aug 30 20:33:06 archangel kernel: [<ffffffffa02de4b9>] usbhid_probe+0x329/0x500 [usbhid] Aug 30 20:33:06 archangel kernel: [<ffffffffa0207a2b>] usb_probe_interface+0xfb/0x1f0 [usbcore] Aug 30 20:33:06 archangel kernel: [<ffffffff81287ac6>] driver_probe_device+0x96/0x1c0 Aug 30 20:33:06 archangel kernel: [<ffffffff81287c8b>] __driver_attach+0x9b/0xa0 Aug 30 20:33:06 archangel kernel: [<ffffffff81287bf0>] ? __driver_attach+0x0/0xa0 Aug 30 20:33:06 archangel kernel: [<ffffffff812869fe>] bus_for_each_dev+0x5e/0x90 Aug 30 20:33:06 archangel kernel: [<ffffffff81287789>] driver_attach+0x19/0x20 Aug 30 20:33:06 archangel kernel: [<ffffffff81287297>] bus_add_driver+0xc7/0x2e0 Aug 30 20:33:06 archangel kernel: [<ffffffff81287f01>] driver_register+0x71/0x140 Aug 30 20:33:06 archangel kernel: [<ffffffffa02066f8>] usb_register_driver+0xb8/0x170 [usbcore] Aug 30 20:33:06 archangel kernel: [<ffffffffa0299000>] ? hid_init+0x0/0xd1 [usbhid] Aug 30 20:33:06 archangel kernel: [<ffffffffa0299093>] hid_init+0x93/0xd1 [usbhid] Aug 30 20:33:06 archangel kernel: [<ffffffff81002149>] do_one_initcall+0x39/0x1a0 Aug 30 20:33:06 archangel kernel: [<ffffffff8108cefb>] sys_init_module+0xbb/0x200 Aug 30 20:33:06 archangel kernel: [<ffffffff81009e82>] system_call_fastpath+0x16/0x1b Aug 30 20:33:06 archangel kernel: INFO: task usbhid-ups:2006 blocked for more than 120 seconds. Aug 30 20:33:06 archangel kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Aug 30 20:33:06 archangel kernel: usbhid-ups D 0000000000000000 0 2006 1 0x00000000 Aug 30 20:33:06 archangel kernel: ffff880227789b98 0000000000000082 ffff880227789ae8 ffffffff00000000 Aug 30 20:33:06 archangel kernel: 0000000000014f40 0000000000014f40 ffff880227789fd8 ffff880227789fd8 Aug 30 20:33:06 archangel kernel: ffff880227789fd8 ffff880226c9b780 ffff880227789fd8 0000000000014f40 Aug 30 20:33:06 archangel kernel: Call Trace: Aug 30 20:33:06 archangel kernel: [<ffffffff81371879>] __mutex_lock_slowpath+0x139/0x310 Aug 30 20:33:06 archangel kernel: [<ffffffff81371a61>] mutex_lock+0x11/0x30 Aug 30 20:33:06 archangel kernel: [<ffffffffa020c195>] usbdev_open+0x145/0x330 [usbcore] Aug 30 20:33:06 archangel kernel: [<ffffffff81127807>] chrdev_open+0x127/0x270 Aug 30 20:33:06 archangel kernel: [<ffffffff811276e0>] ? chrdev_open+0x0/0x270 Aug 30 20:33:06 archangel kernel: [<ffffffff81121d2b>] __dentry_open+0x11b/0x3c0 Aug 30 20:33:06 archangel kernel: [<ffffffff811a263a>] ? security_inode_permission+0x1a/0x20 Aug 30 20:33:06 archangel kernel: [<ffffffff81122f64>] nameidata_to_filp+0x54/0x70 Aug 30 20:33:06 archangel kernel: [<ffffffff811311f0>] do_last+0x480/0x740 Aug 30 20:33:06 archangel kernel: [<ffffffff8113169d>] do_filp_open+0x1ed/0x680 Aug 30 20:33:06 archangel kernel: [<ffffffff8113cc74>] ? alloc_fd+0xf4/0x150 Aug 30 20:33:06 archangel kernel: [<ffffffff81122fe4>] do_sys_open+0x64/0x130 Aug 30 20:33:06 archangel kernel: [<ffffffff811230cb>] sys_open+0x1b/0x20 Aug 30 20:33:06 archangel kernel: [<ffffffff81009e82>] system_call_fastpath+0x16/0x1b Aug 30 20:33:08 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:33:13 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:33:18 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:33:23 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:33:28 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected Aug 30 20:33:33 archangel upsmon[2300]: Poll UPS [archangel_ups@localhost] failed - Driver not connected -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

3 6

[arch-general] Remove duplicate packages from /var/cache/pacman/pkg script updated
by David C. Rankin 03 Sep '10

03 Sep '10

In case anyone uses it, I updated my fduppkg script that scans /var/cache/pacman/pkg and moves duplicate packages to a separate directory so you can either keep the current + last package sets or just delete the dups. This update just cleans up the output and adds an -s | --silent option that suppresses all screen output and simply writes to the log file. Additionally the screen output has been cleaned up so it looks like this now: [14:18 alchemy:/home/david] # fduparch fduppkg /var/cache/pacman/pkg -d /home/backup/pkg-old -l /home/backup/pkgdups.log Total packages to screen: 2858 Removing duplicates from: /var/cache/pacman/pkg Duplicates directory: /home/backup/pkg-old Log file location: /home/backup/pkgdups.log Verbose mode set: [use -q to stop pkg output | -s to stop all output] pkg [ 434] feh dup => feh-1.8-1-x86_64.pkg.tar.xz pkg [ 727] gstreamer0 dup => gstreamer0.10-ugly-0.10.15-4-x86_64.pkg.tar.xz pkg [ 785] gtranslator dup => gtranslator-1.9.7-1-x86_64.pkg.tar.gz pkg [1446] kernel26-docs dup => kernel26-docs-2.6.35.3-1-x86_64.pkg.tar.xz pkg [1869] lpsolve dup => lpsolve-5.5.0.15-1-x86_64.pkg.tar.gz pkg [1895] madwifi dup => madwifi-0.9.4.4119-2-x86_64.pkg.tar.xz pkg [2043] obexd-client dup => obexd-client-0.29-3-x86_64.pkg.tar.xz pkg [2070] openssh dup => openssh-5.5p1-1-x86_64.pkg.tar.xz pkg [2263] pulseaudio dup => pulseaudio-0.9.21-8-x86_64.pkg.tar.xz pkg [2399] ruby dup => ruby-1.9.1_p429-1-x86_64.pkg.tar.xz pkg [2537] timidity++ dup => timidity++-2.13.2-9-x86_64.pkg.tar.xz 11 duplicates moved to /home/backup/pkg-old I've set the package name field width to 26 as a compromise to handle most package names. (You wouldn't have any screen left if it was wide enough for all the screwy kde4 50+ char package names). If the output above wraps -- you get the drift. In verbose mode (default) you get a summary showing the total number of packages to be screened, being moved from /var/cache/pacman/pkg to the dupdir you specify and the files moved are logged in the logfile you specify. The package listing just shows the array index for the current package and any dups found are shown on the right. I find it handy, YMMV. The way I use it is to set up a 'wrapper script' to call fduppkg twice. Once to move dups from /var/cache/pacman/pkg => /home/backup/pkg-old Then again to move dups from /home/backup/pkg-old => /home/backup/pkg-older That way I have the current set in /var/cache/pacman/pkg and a clean last installed set in /home/backup/pkg-old. Plus moving to /home/backup will offload the storage from / to /home partitions on most installs. The main fduppkg scrip is here: http://www.3111skyline.com/dl/Archlinux/scripts/fduppkg The wrapper script I use to call fduppkg is here: http://www.3111skyline.com/dl/Archlinux/scripts/fduparch.sh I just link the scripts to /usr/local/bin as follows and then make sure /usr/local/bin is in your path: lrwxrwxrwx 1 root root 32 Apr 18 19:17 fduparch -> /home/david/scr/arch/fduparch.sh lrwxrwxrwx 1 root root 28 Apr 18 19:18 fduppkg -> /home/david/scr/arch/fduppkg Then once you have edited fduparch.sh and set the directories and options the way you like it, just call fduparch as root or 'sudo fduparch' and all dups will be moved to the directory you specify. (NOTE: this script uses the package DATE to determine which is the newest package, so if you have somehow reset all the ctime or mtime info on your files by block copying them without preserving the file attributes, it won't work) (Yes I know I have left comments and commented out stuff in the scripts, they are still works in progress :-) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com

1 0