- Arch-general - lists.archlinux.org

[arch-general] can't import ctype in python2
by 李永 03 Dec '10

03 Dec '10

Hi, all I can't run ibus-setup and can't see the ibus imput method pannel, after I investgation, I find it is a python problem, when I run ibus-setup, I got the following error: $ ibus-setup Traceback (most recent call last): File "/usr/share/ibus/setup/main.py", line 31, in <module> import ibus File "/usr/lib/python2.7/site-packages/ibus/__init__.py", line 26, in <module> from common import * File "/usr/lib/python2.7/site-packages/ibus/common.py", line 55, in <module> import ctypes File "/usr/lib/python2.7/ctypes/__init__.py", line 10, in <module> from _ctypes import Union, Structure, Array ImportError: No module named _ctypes and I can't import ctype in python2 too, $ python2 Python 2.7.1 (r271:86832, Dec 1 2010, 13:45:43) [GCC 4.5.1 20101125 (prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/ctypes/__init__.py", line 10, in <module> from _ctypes import Union, Structure, Array ImportError: No module named _ctypes do you meet the same probem, do I miss some package to install? any hint? thanks . -- --------------------------------------------------------------- Regards! Li Yong Email: yorklee(a)gmail.com Cell Phone: 13064787950 MSN Messenger: sanyork(a)hotmail.com Skype: sanyork

4 5

[arch-general] script idea - update single arch box -> updates all on local net
by David C. Rankin 02 Dec '10

02 Dec '10

Guys, I've played with an idea to save time with updates and duplicate (old version) removal from /var/cache/pacman/pkg for all arch boxes on a local network. I thought I would pass along the idea and the scripts as they exist now. Requirements: - public key/private key ssh access for user between boxes on the lan (id_dsa) - sudo rights for user on each box Config: - all script calls to additional scripts are to symlinks in /usr/local/bin Operation: pmduprsync.sh - is the outside script that runs pacman -Syu --noconfirm on a box on the lan (you can nix the --noconfirm if you want to review). -- it then calls fduparch.sh (which just sets the directories to remove old version of the packages from/to (I've posted a full description before). Which then calls: -- fduppkg (the actual script that scans /var/cache/pacman/pkg and moves old versions of packages to another directory of your chosing. (currently /home/backup/pkg-old for me) -- fduparch.sh runs a second time for me to remove old versions from /home/backup/pkg-old to /home/backup/pkg-older (original I know) pmduprsync.sh grabs a md5sum of the /var/cache/pacman/pkg dir on the remote hosts of the same arch and then rsyncs /var/cache/pacman/pkg dir to remote host and grabs another md5sum. If the sums differ, then pacman -Syu --noconfirm is called on the remote host following by fduparch.sh to tidy up the /var/cache/pacman/pkg dir there. For me the benefit is I keep a current package set for all boxes in the package dir of each host (not an issue in the days of 1T drives). Further, bandwidth reduction. Packages are only downloaded once and rsynced between boxes. Now granted the --noconfirm isn't optimal, and I always check first before pulling the trigger, but the automation of checking what an update will include on one host (generally the host with the widest package selection) and then having the updates daisy-chain to all other arch boxes on the lan while tidying up /var/cache/pacman/pkg on each box is a big plus. Currently you will see that I've just hard coded which hosts are i686 and x86_64 in pmduprsync.sh (easy at home - only 4 boxes 2 of each arch), but there is no reason why either an i686/x86_64 host list file couldn't be automagically built with some type of subnet host query followed up with ssh 'uname -r' calls. Anyway here are the scripts in case it sparks an idea with someone else. Regardless of whether you want the auto update part, the scripts that move old versions of packages from /var/cache/pacman/pkg have served me well. http://www.3111skyline.com/dl/Archlinux/scripts/pmduprsync.sh http://www.3111skyline.com/dl/Archlinux/scripts/fduparch.sh http://www.3111skyline.com/dl/Archlinux/scripts/fduppkg Once I refine the logic in the update script a bit more and the collection of hosts with the same arch on the lan, I'll follow up. All the scripts are my original work and are gpl, so use, reuse, tear apart at will. -- 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 2

Re: [arch-general] [arch-dev-public] [signoff] xinetd-2.3.14-6
by Allan McRae 01 Dec '10

01 Dec '10

On 21/11/10 18:28, Eric Bélanger wrote: > On Fri, Nov 19, 2010 at 8:32 AM, Allan McRae<allan(a)archlinux.org> wrote: >> Rebuild of old package, tidy up PKGBUILD. >> >> Signoff both, >> Allan >> > > signoff x86_64 > Anyone for i686?

2 1

Re: [arch-general] PulseAudio in [testing]
by Χρήστος Κώτσαρης 30 Nov '10

30 Nov '10

I believe this was the right choice. Pulseaudio should be in extra and all applications build with pulse support. Regarding phonon, i believe KDE intends to drop it at some point, not sure were i read that. I remember reading something about KDE 5 not including phonon, but it may be FUD. Anyone more informed on the issue? In any case, Linux/GNU needs pulseaudio. Pulseaudio should be the api to target for all apps. The kind of functionality it provides it is needed if modern distros are to compete with Windows 7. Windows 7 now provide the functionality to switch sound cards on the fly without restaring the app playing sound. This is possible only with Pulseaudio as far as i can tell in the Linux world. And this is just one example. Imagine if you have a headset with included sound card, for example a 5.1 headset. Without Pulseaudio, it is a chore to switch sound to it, with Pulseaudio it is easy and userfriendly. Windows 7 now can do it too. Imagine if a user tries to do it in Linux without pulse, he will be frustrated. Of course, Arch users should be knowledgable enough to switch sound cards in ALSA, but it still is a chore. And it is not the point. The point is, Linux needs a sound daemon to provide modern user friendliness. So it is a matter of time for GNOME and KDE to support it natively. KDE tried it with phonon, but it seems phonon is more problematic than pulseaudio, with less features. At least for me, when phonon sits on top of ALSA, i get all sorts of messages informing me that some interface should be disabled, it is annoying. Plus when i change a sound card, the app needs restarting. So yes, in time pulseaudio should become the default linux api for Linux/GNU, if not already. If there are bugs, they could be solved if all those geniuses bitching about it and use ALSA could be bothered to help a little.

13 24

[arch-general] what happened to nut (network-ups-tools)?
by David C. Rankin 30 Nov '10

30 Nov '10

Guys, Where did nut go? I just checked and network-ups-tools is no longer available. Did it change names? I must have missed it. 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

6 9

[arch-general] networkmanager crash
by Martín Cigorraga 29 Nov '10

29 Nov '10

Latest networkmanager update (0.8.2-3 ) makes my KDE SC 4.5.3 crash on shutdown, anyone else?

3 4

[arch-general] associations for chromium
by Sergey Manucharian 29 Nov '10

29 Nov '10

Hi folks, I wonder if somebody could already figure out how to handle file and protocol associations for Chromium. For those who use a DE like KDE/Gnome most probably everything works out of box. There is an article in wiki how to use chromium with no DE [1]. It suggest to use mimeo and xdg-utils-mimeo, but it simply does not work (at least in my case). For those who are interested to read further the details are below. When I click a link pointing to mms:// stream chromium pops up a message that it's going to use xdg-open to handle it. The xdg-utils-mimeo allows to associate a protocol with an application, which I already has done - set to mplayer. Instead it tries to open smplayer with no (or bad) link passed. I've uninstalled smplayer and it tried to use realplayer, I've uninstalled realplayer and now it uses vlc. I couldn't find where that sequence is hardcoded. But now I see that the link itself is getting transformed in something weird: ----------------------------8<---------------------------- File reading failed: VLC could not open the file "/etc/X11/mms:/76.191.112.53/streams_e/stb1_s_8b700762e4ba88f62c33ce2291e1baaa.wmv". Your input can't be opened: VLC is unable to open the MRL 'file:///etc/X11/mms%3A/76.191.112.53/streams_e/stb1_s_8b700762e4ba88f62c33ce2291e1baaa.wmv'. ----------------------------8<---------------------------- The strange path "/etc/X11" comes is the directory I've accidentally started X from... Any ideas? TIA Sergey [1] https://wiki.archlinux.org/index.php/Chromium

4 5

[arch-general] Pulseaudio
by Χρήστος Κώτσαρης 29 Nov '10

29 Nov '10

On a more serious mode now: As the devs themselves said, pulseaudio is optional, unless you are using GNOME, which requires Pulseaudio upstream. There is nothing clearer than that. Go blame GNOME developers. There is something i noticed. Morgan Gandwere is a Debian convert... That explains a lot of things actually. Debian is known to modify every possible package, since Debian maintainers are more wise and of course they know better than upstream developers about upstream software. Debian is known to fork a package when some upstream developer does not accept a debian maintainer's POS patch. Then the package is left to rott and die, since the debian maintainer is not able to develop it. Debian users are used to this mentality. That explains why someone with this background believes that a distribution should modify upstream to fit its maintainers whims. Sometimes there have been packages i wanted that didn't make part of Arch, even though in my opinion they should. For example, libxft-lcd was in community, while lib32-libxft-lcd was not. I asked in the forum to include that too, but instead, libxft-lcd went to AUR also. I didn't bitch about it, i just use AUR and that's it. One can't expect a whole distribution to accomondate his personal needs. So pulseaudio haters, since pulseaudio is optional, the only reason you complain is that you don't want it in extra, you don't want to install libpulse since you cant afford 1MB disk space, and you also don't want media packages compiled with pulse support because of a purely theoritical bloat. Well, you can't expect the distro to remain behind the times and not include proper (optional) pulse support for these reasons. If 1 mb of disk space and tiny bits of memory bloat in executables is such a waste for you, you could recompile those packages, or even better, try Gentoo. I hear Gentoo is really fast and without bloat. After 60 hours of compiling your apps start 5ns faster. Great!

6 7

Re: [arch-general] PulseAudio in [testing]
by Χρήστος Κώτσαρης 29 Nov '10

29 Nov '10

Regarding phonon being dropped, after some googling it seems i was mistaken, what i had read was that Qt framework is dropping phonon, not KDE. But still, i believe it would be sane to drop phonon in KDE too and replace it with Pulseaudio, it is the best choice. No need for 2 sound servers when one could do the trick. Plus, in case someone says Phonon can switch sound cards without the app restarting, everytime i try it Amarok and others crash, so yes, it needs restarting...

4 3

[arch-general] archlinux hardware question
by Jude DaShiell 29 Nov '10

29 Nov '10

Has anyone managed to get archlinux up and running on either a sled drive or a full-sized usb drive yet. Another Linux system I have couldn't even detect the disk drive was in the machine and I gave it my best hard drive too. Slackware has no problem with the drive, but Debian squeeze or an earlier edition of lenny squeeze had problems too.

4 4