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

[arch-general] Asking for swap device
by Andrea Crotti 18 Aug '10

18 Aug '10

I use ususpw and pm-suspend to suspend my dell mini 1010. Now the swap partition is on lvm, and every time I reboot it will ask for it, even if it knows perfectly where it is (it's printed 2 lines above). And also it works perfectly after, but I would like to get rid of this thing asking me every time... Anyone using a swap partition for the swap?

1 0

Re: [arch-general] [arch-dev-public] kde 4.5.0
by Martín Cigorraga 18 Aug '10

18 Aug '10

It's good to see finally 4.5 will hit extra :) >1) Sometimes, when I change settings in 'systemsettings' (forgot which >ones, have to investigate again), kwin and/or plasma-desktop freeze and >I cannot do anything but move the mouse or switch to VT. >2) dolphin segfaults. A lot. All the time. It's annoying. >3) I don't understand why, but starting xbindkeys with KDE's autostart >is broken: When I want to use qdbus or dolphin from xbindkeys, nothing >happens. When I kill and launch it again later, everything seems to work. However if the problems reported by Thomas persist I would wait to 4.5.1 before upgrading - looking for smooth transition. On the composite issue I have a workaround thats works pretty good. I'm one of those people experiencing artifacts problems with Catalyst 10.7-3 on an ATI Readeon 5750HD. For some time it was a habit to just push twice alt+shift+f12 after login but now that's gone. After searching for a fix to this issue I found a commandline hack to automatically disable and enable composite in the KDE forums: $ qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing & qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing So the trick was to put that in a script in ~/bin and tell KDE to run it on every start-up (a cleaner way to implement this will be welcomed). Another optimization I'm using since a week or so without *any* problems (with composite and KWin working at their best) is launching plasma-desktop with the --graphicssytem raster argument. This solved the exasperating low speed when performing ceratin tasks with plasmoids on the desktop (like rotating folder view plasmoids and so on). It works very nice with Yakuake too. /usr/share/autostart/plasma-desktop.desktop should look like this (only showing relevant part): [Desktop Entry] Exec=plasma-desktop --graphicssystem raster Credits goes to a video on YT and the folks at Chakra forum.

1 0

Re: [arch-general] [arch-dev-public] Large packages in repositories
by Sven-Hendrik Haase 18 Aug '10

18 Aug '10

On 17.08.2010 16:28, Thomas Bächler wrote: > Am 17.08.2010 16:12, schrieb Dan McGee: >> tl;dr: I think we need some standards with these huge packages, and >> people need to be a lot more cognizant as to how big they are. We have >> lost more than one mirror due to complaints over needed space and >> stuff like this doesn't help. > If a mirror cannot cope with a few GB, then it should be dropped anyway. > Our repos will get bigger, one way or the other. I share this opinion. The Arch repos are hardly large and even if we added 50 GB to them they would still wouldn't be that large. I know comparisons with other distributions are probably not a good idea on this list but it does help to get a general understanding of where we stand and what "large" really means. Debian - 428GB (http://www.debian.org/mirror/size) Fedora - 653GB (http://download.fedora.redhat.com/pub/DIRECTORY_SIZES.txt) Ubuntu - 421GB (https://wiki.ubuntu.com/Mirrors) openSUSE - 500GB+ (http://en.opensuse.org/openSUSE:Mirror_infrastructure) Thankfully, we don't keep around old releases of packages or isos. Our mirrors will never have to cope with the amount of data that other distributions make them cope with. I think since they are already mirroring 2TB+ worth of data from other distros, they can easily squeeze in 50GB of Arch, or more. I'd really like to resolve this problem in the course of this discussion since it has been brought up every time big packages are pending (mostly games). Personally, I think we don't need a policy or anything on this. Something very odd would have to happen for our repos to grow too much for our mirrors to handle. This is Arch, let's keep it simple and unbureaucratic. I'm not saying "let's throw all that big shit into there" but if there are potential packages that would improve the user experience, their size should not be the determining factor to their inclusion. -- Sven-Hendrik

4 3

[arch-general] Update to 2.6.34.3-1 & LTS 2.6.32.18-1 killed dmraid box??
by David C. Rankin 18 Aug '10

18 Aug '10

Guys, This one caught me by surprise. I have my test server that I update before updating my regular server. It is based on a MSI K9N2 board (MS-7374) with a Phenom 9850 proc & 8G of ram. The box has 2 dmraid arrays: [22:00 ecstasy:/mnt/arch] # dmraid -r /dev/sdd: nvidia, "nvidia_baaccaja", mirror, ok, 1465149166 sectors, data@ 0 /dev/sdc: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 /dev/sdb: nvidia, "nvidia_baaccaja", mirror, ok, 1465149166 sectors, data@ 0 /dev/sda: nvidia, "nvidia_fdaacfde", mirror, ok, 976773166 sectors, data@ 0 [22:00 ecstasy:/mnt/arch] # dmraid -s *** Active Set name : nvidia_baaccaja size : 1465149056 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 *** Active Set name : nvidia_fdaacfde size : 976773120 stride : 128 type : mirror status : ok subsets: 0 devs : 2 spares : 0 The kernel updates applied tonight were: [2010-08-16 20:13] upgraded kernel26 (2.6.34.2-2 -> 2.6.34.3-1) [2010-08-16 20:13] upgraded kernel26-headers (2.6.34.2-2 -> 2.6.34.3-1) [2010-08-16 20:14] upgraded kernel26-lts (2.6.32.17-2 -> 2.6.32.18-1) Both completed successfully. The pacman.log info is here: http://www.3111skyline.com/dl/Archlinux/bugs/pm-updt-8-16.txt After boot to the normal 2.6.34 kernel, the box kept automatically rebooting itself - WTF? So I booted to the LTS kernel, which booted this time and rebuilt the initramfs file with: /sbin/mkinitcpio -k 2.6.34-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img It completed successfully. Rebooting resulted in an error that the the partitions were corrupt. So I attempted to boot back into the LTS kernel. It failed as well?? So I rebooted into suse 11.0 which is on the other array. The box booted into suse without any problems. I then mouted the Arch array and the partitions are fine. (that's where the raid info above came from). I don't know what is going on here. Kernel updates on this box have always been uneventful. Tonight all hell broke loose. What could have caused Arch to report the partitions were bad? More important, what do I do to get Arch back? I believe I have the correct modules in mkinitcpio.conf (they are the same ones I have had in the conf file since I first loaded Arch with the 200902 install media in March '09). Here is the lspci info (running suse): The raid controller is the standard nvraid soft raid controller: 00:09.0 RAID bus controller: nVidia Corporation Device 0ad8 (rev a2) Subsystem: Micro-Star International Co., Ltd. Device 7374 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 4347 I/O ports at b080 [size=8] I/O ports at b000 [size=4] I/O ports at ac00 [size=8] I/O ports at a880 [size=4] I/O ports at a800 [size=16] Memory at f9e76000 (32-bit, non-prefetchable) [size=8K] Capabilities: [44] Power Management version 2 Capabilities: [8c] SATA HBA <?> Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable+ Capabilities: [ec] HyperTransport: MSI Mapping Enable+ Fixed+ Kernel driver in use: ahci Kernel modules: ahci What say the gurus? (Tobias what could have changed here?) Any help would be greatly appreciated. I'll keep dorking with it, but I'm at a loss here... Additional Info: The partitions on the box are: [22:02 ecstasy:/mnt/arch] # cat /proc/partitions major minor #blocks name 8 0 488386584 sda 8 1 1 sda1 8 5 72229 sda5 8 6 2104483 sda6 8 7 20972826 sda7 8 8 465234336 sda8 8 16 732574584 sdb 8 17 1 sdb1 8 21 19534977 sdb5 8 22 120456 sdb6 8 23 39062016 sdb7 8 24 1951866 sdb8 8 25 15358108 sdb9 8 26 30716248 sdb10 8 27 7510356 sdb11 8 28 618317721 sdb12 8 32 488386584 sdc 8 33 1 sdc1 8 37 72229 sdc5 8 38 2104483 sdc6 8 39 20972826 sdc7 8 40 465234336 sdc8 8 48 732574584 sdd 8 49 1 sdd1 8 53 19534977 sdd5 8 54 120456 sdd6 8 55 39062016 sdd7 8 56 1951866 sdd8 8 57 15358108 sdd9 8 58 30716248 sdd10 8 59 7510356 sdd11 8 60 618317721 sdd12 253 0 732574583 dm-0 253 1 488386583 dm-1 253 2 732572001 dm-2 253 3 19534977 dm-3 253 4 120456 dm-4 253 5 39062016 dm-5 253 6 1951866 dm-6 253 7 15358108 dm-7 253 8 30716248 dm-8 253 9 7510356 dm-9 253 10 618317721 dm-10 253 11 488384001 dm-11 253 12 72229 dm-12 253 13 2104483 dm-13 253 14 20972826 dm-14 253 15 465234336 dm-15 -- 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

2 10

[arch-general] pacman seems to leak ftp connections
by Alexander Duscheleit 18 Aug '10

18 Aug '10

Hi, since I upgraded to pacman 3.4.0 I notice a strange behavior in the way pacman integrates with my local mirror server. First, pacman opens a new ftp connection for every download, which spams the logs a lot. Second, pacman doesn't seem to close those connections either at all, or at least not in a timely fashion. This results in pacman not being able to download more than a hand full of packages before my ftp won't let it connect anymore. The server-log says: Aug 18 00:42:38 titan proftpd[4666]: titan.huntemann.uni-oldenburg.de - MaxInstances (30) reached, new connection denied over and over while pacman switches to the next mirror for every download. The pacman frontend clyde exhibits the same behavior, so I suspect the culprit is somewhere in libalpm. Pacman prior to 3.4.0 did not show this behavior and all downloads worked fine. Greetings, Alex --

5 7

[arch-general] Dovecot 2.0.0 in testing
by Andreas Radke 18 Aug '10

18 Aug '10

Dovecot 2.0.0 has been released and it's in our testing repo (it has been build against core/extra only). The configuration files are completely split up now! Everybody please read the post.install msg carefully! Test the new pkg and give suggestions if anything needs to be improved. I should move soon to extra. I got it running locally here. PS: I had to disable IPv6 listen option to make it start properly. -Andy

3 4

[arch-general] Empathy on Arch?
by Magnus Therning 18 Aug '10

18 Aug '10

I've tried empathy a few times since my switch to Arch, but I never manage to get it even close to working. Latest was today. It even imported account info from my working pidgin, but still, no connection to any of the accounts. Is it me or is it the empathy packages in Arch that are the problem? :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

4 8

[arch-general] one suggestion for aur edbrowse package
by Jude DaShiell 18 Aug '10

18 Aug '10

In its present configuration it's a good package. However someone who unpacks the edbrowse package for the first time ought to be told while running as a user account to prepare to use edbrowse for the first time first run the setup.ebrc package. Once that's done, necessary set up edbrowse needs to have gets done.

2 1

[arch-general] suggestions for astrolog package on aur
by Jude DaShiell 18 Aug '10

18 Aug '10

For ecraven specifically, the astrolog package needs its astrolog.dat file packaged with it since the astrolog.dat file controls the operation of astrolog itself. I was able to fix that deficit after having downloaded and installed the aur package as a result of prior use of the software. That file belongs in /usr/share/astrolog and the DEFAULT path in astrolog.h needs to point to /usr/share/astrolog as well before compilation. The file ephemall.zip also ought to be extracted into /usr/share/astrolog because that file on the same site as the astrolog software is the ephemeris files for astrolog. The accuracy of calculations improve with use of ephemeris files and Lilith can then also be calculated. Other than that, this is a good package and builds well.

2 1

Re: [arch-general] [arch-dev-public] The "Great Python Rebuild of 2010" begins
by Rogutės Sparnuotos 18 Aug '10

18 Aug '10

Allan McRae (2010-08-18 01:46): > Hi, > > I have pushed the new python (3.1) and python2 (2.7) packages to the > new [staging] repo so rebuilds can start there. Remember the > staging repo should never be used outside a build chroot... If you > do, everything python related will break on your system. > > TUs will not be able to start uploading rebuilds yet as they do not > have a staging equivalent, but we will sort something out for them > once we get all the db-scripts/devtools changes tested for the main > one first. The package pool is going to save us a heap of issues > when this gets moved so it is worth the wait. > > > The key things to remember with the rebuild are: > > - build in clean chroots. Most packages will detect "python2" or > "python-2.7" once they see no "python" and use that. Some will need > simple patching. > > - change your dependencies to python2 > > - check files for #!'s with "/usr/bin/python" or "/usr/bin/env > python". If you have those you will need to do a sed to change them > to python2. Me wonders what is planned for e.g. pyqt, which is available for both, python2 and python3? Thanks, -- Rogutės Sparnuotos

2 1