- Arch-general - lists.archlinux.org

Re: [arch-general] [arch-dev-public] nilfs-utils moving in core
by Heiko Baums 08 Dec '10

08 Dec '10

Am Tue, 07 Dec 2010 16:26:00 +0100 schrieb Pierre Schmitz <pierre(a)archlinux.de>: > I second this. If the reason for moving a package to core is that the > installer cannot handle it otherwise the installer needs to be fixed. The question is not that the installer can't handle it if it's not in [core]. The question is that if the installer creates a filesystem on the harddisk the appropriate tools need to be installed on the system, too. And this is only possible if those packages are in [core] because the core iso only contains the [core] repo and not [extra] and [community]. Also the netinstall iso can only install from [core] as far as I know. So if AIF supports nilfs or another filesystem, those tools have to be moved to [core]. > That's why I would vote against moving it to core. I'd even say we > should have a look at those packages in core with low usage and see if > we should move them to extra. There are already packages for which we > don't get any sign-offs which shows that those are no longer needed to > be in core. That's definitely not the definition of [core]. [core] is not for supporting the most used and most popular packages. [core] is for providing system relevant packages which are necessary to build a minimal system. And it's not the dev's task to decide how a user wants to partition and format his harddisk. If it's done like you're suggesting than you would force a user to only format his harddisk with e.g. ext4, because you think that ext4 is the one and only and most popular filesystem and every other filesystem has to be moved to [extra], because they are not necessary or not as popular as ext4. It's all about choice - the user's, not the dev's choice. Instead every filesystem - probably except for dosfsutils - has to be moved to [core] and be supported by AIF, because a filesystem is the most basic and necessary part of a system which has to be chosen, used and installed during installation. You simply can't reformat or repartition a harddisk after the installation. Well, it's possible but not without having a second harddisk onto which the installed system had first to be copied. But that's not the way a system should be installed. So every filesystem - regardless of how much it is used and how popular it is - has definitely to be moved to [core] and supported by AIF. And, no, ext2 is not the only filesystem which can be used for /boot and /. But on the other hand every filesystem related package has to be removed from (base), while AIF should then be able to recognize which filesystems are created on the harddisk and install the appropriate filesystem tools automagically. > The idea of core was to provide a minimal set of packages that are > needed by nearly all users to set up a base system. Our sign-off > procedure ensures that we don't put broken packages by accident there. But filesystems - all of them - belong to the very minimal set of packages that are needed to set up a base system. But every user needs a different filesystem for a reason, because every user has different requirements. experimental != broken Just because a filesystem is marked as experimental doesn't mean that it's broken. Btrfs e.g. is missing a fsck, yet, but it shall be pretty stable until the harddisk gets too cluttered. At least it's said by many people in the web. So there are several people who like to use and to test it. As soon as there's a first stable version of a package it should of course not be updated anymore to newer, unstable versions. Of course, those experimental packages should explicitly be marked as experimental in AIF. There have been, btw., several kernel modules in the vanilla kernel which have been marked as experimental for many years even if they haven been really stable in the meantime. So the word experimental is quite relative. > I don't think that nilfs matches the criteria needed for inclusion in > core. (side note: it has 1.38% usage according to pkgstats) Why does it only have 1.38% usage? Just because it's not in [core] and not supported by AIF, just because a filesystem is usually chose at install time. And nilfs won't get as a high usage as ext4, just because it's primarily meant for using on a SSD (SSD disks, USB sticks, etc.). But to be able to install Arch Linux on a USB stick with the official install CD and to format the USB stick with nilfs it needs to be supported by AIF and to be in [core]. Heiko

7 14

[arch-general] [RFC] patches to initscripts
by Tom Gundersen 07 Dec '10

07 Dec '10

On Fri, Nov 19, 2010 at 7:58 AM, Allan McRae <allan(a)archlinux.org> wrote: > While looking through bugs for [core] packages, I notice that there are a > large number of bug report for these three packages. In total they account > for ~13% of the bugs in the tracker! [...] > But given these are some of the uniqueness of Arch, I wonder what we _as a > group_ could to do to improve this situation? Perhaps organize a > hack-a-thon on IRC one day? Or we could advertise for help, with the > selection criterion being a git repo provided by the applicant showing they > can do stuff? As discussed with Allan, here are some patches to initscripts: <https://github.com/teg/initscripts-arch>. Comments very much welcome. I started off with what appeared to me as the low-hanging fruit. Once I have had feedback on this I'll have a look at more difficult (or invasive) problems. My long-term goal is to ease the maintenance burden of initscripts by simplifying them and harmonizing them with other distros/projects (without, of course, loosing any of their features). Cheers, Tom

4 10

[arch-general] Multi architecture binary pkgs
by jesse jaara 07 Dec '10

07 Dec '10

Currently, if one wants to make a pkg, lets say, for an app that only has binaries available and only for 32bit archs, then one usually makes a bin32-appname pkg for it. I don't like this and would like to have the bin32 and the non-bin32 pkgs to be just one pkg with the name of the app. But if one makes this kind of a pkg, one must use ugly if [[ "$CARCH" = .... statements are in the PKGBUILD, so I was thinking that could it be possible to implement some new variables in PKGBUILDS like depends32 and optdepends32 and then build32() {} and package32() {}? I dont know how makepkg is written, so I dont know how hard it is to implement these, but in the best case it shouldn't be more than just one or two if-statements in the code, so if arch is x86_64 use the 32 variables if they are present. -- (\_ /) copy the bunny to your profile (0.o ) to help him achieve world domination. (> <) come join the dark side. /_|_\ (we have cookies.)

4 4

[arch-general] alsa, hdmi, and the invisible magic output
by Samuel Martín Moro 03 Dec '10

03 Dec '10

Good evening everyone, I'm using arch since a while now. Everything was working just fine, until a few weeks (months?) ago. Since, I had a few problems I can't understand : The first symptom was the day I lost sound on my regular audio output (moterhboard intel HDA). I finally noticed sound was actually send to my TV through my G92 9800GT. I had a long period during while I was always switching my speakers wire from my tower to the screen, and back to the computer. The main problem beeing that, after putting the screen in sleep mode, I wasn't able to get the sound back without restarting X. Since, the problem changed, somewhat. Now, vlc sends its sound in both my motherboard and my graphic card outputs. While banshee's still only using the motherboard one. The most recent symptom is that, when I'm already playing some music with banshee, I can't have sound on any web browser (opera, firefox & chromium tested so far). I first though it was flash-related. But since I can't have sound while playing quakelive too (and AFAIK, QLive doesn't uses flash), I'm a bit confused... What could be happening? The only way I can get sound working back in the web browser is to shut down banshee and restart the browser. And I won't be able to make banshee work again before closing the browser, and then starting banshee. The following error is continuously reported when executing chrome from terminal, while using banshee: ALSA lib pcm_dmix.c:1018:(snd_pcm_dmix_open) unable to open slave I searched for some details on google. It seems the first thing I may do is to specify which audio device use by default. So, I tried to find where my HDMI output is... faust@alpha : aplay -l **** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: Intel [HDA Intel], device 1: AD198x Digital [AD198x Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 faust@alpha : lspci | grep -i audio 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller faust@alpha /proc/asound : l -R /proc/asound/ /proc/asound/: total 0 dr-xr-xr-x 5 root root 0 Dec 2 23:45 card0 -r--r--r-- 1 root root 0 Dec 2 23:45 cards -r--r--r-- 1 root root 0 Dec 2 23:45 devices -r--r--r-- 1 root root 0 Dec 2 23:45 hwdep lrwxrwxrwx 1 root root 5 Dec 2 23:45 Intel -> card0 -r--r--r-- 1 root root 0 Dec 2 23:45 modules dr-xr-xr-x 2 root root 0 Dec 2 23:45 oss -r--r--r-- 1 root root 0 Dec 2 23:45 pcm dr-xr-xr-x 2 root root 0 Dec 2 23:45 seq -r--r--r-- 1 root root 0 Dec 2 23:45 timers -r--r--r-- 1 root root 0 Dec 2 23:45 version /proc/asound/card0: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 codec#0 -r--r--r-- 1 root root 0 Dec 2 23:45 id -rw-r--r-- 1 root root 0 Dec 2 23:45 oss_mixer dr-xr-xr-x 5 root root 0 Dec 2 23:45 pcm0c dr-xr-xr-x 3 root root 0 Dec 2 23:45 pcm0p dr-xr-xr-x 3 root root 0 Dec 2 23:45 pcm1p /proc/asound/card0/pcm0c: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 oss dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub0 dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub1 dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub2 /proc/asound/card0/pcm0c/sub0: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/card0/pcm0c/sub1: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/card0/pcm0c/sub2: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/card0/pcm0p: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 oss dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub0 /proc/asound/card0/pcm0p/sub0: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/card0/pcm1p: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 oss dr-xr-xr-x 2 root root 0 Dec 2 23:45 sub0 /proc/asound/card0/pcm1p/sub0: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 hw_params -r--r--r-- 1 root root 0 Dec 2 23:45 info -rw-r--r-- 1 root root 0 Dec 2 23:45 prealloc -r--r--r-- 1 root root 0 Dec 2 23:45 prealloc_max -r--r--r-- 1 root root 0 Dec 2 23:45 status -r--r--r-- 1 root root 0 Dec 2 23:45 sw_params /proc/asound/oss: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 devices -r--r--r-- 1 root root 0 Dec 2 23:45 sndstat /proc/asound/seq: total 0 -r--r--r-- 1 root root 0 Dec 2 23:45 clients -r--r--r-- 1 root root 0 Dec 2 23:45 drivers -r--r--r-- 1 root root 0 Dec 2 23:45 oss -r--r--r-- 1 root root 0 Dec 2 23:45 queues -r--r--r-- 1 root root 0 Dec 2 23:45 timer faust@alpha : uname -a Linux alpha.example.com 2.6.36-ARCH #1 SMP PREEMPT Wed Nov 24 00:39:57 CET 2010 x86_64 Intel(R) Core(TM) i7 920 @ 2.67Ghzs GenuineIntel GNU/Linux I'm not sure to understand what represent pcm0c, pcm0p and pcm1p... Launching alsamixer, I only have one device (identified as default and hda intel) The last listed output is 'HDMI', and indeed, controls my screen speakers' sound level. So, I don't understand. How is it possible to have only one card recognized, and controlling both of them through the same alsamixer/gnome-volume-control panel? What can I do? Setting HDMI as default (only) output? How to do so? Wait for a patch? Is it a kernel-related bug? Or with nvidia driver? Would that even fix the banshee/browser troubles accessing device? This arch worked for more than a year. I guess that's the bad side of mainstream distros. Whatever. I'm still enjoying my stay. Also, I often get this warn: *** NSPlugin Viewer *** WARNING: unhandled variable 18 (<unknown variable>) in NPN_GetValue() I'm quite sure it's not related to my problem, but I'm still curious: wtf? I read on some ubuntu forum it's related to flash, kernel & x86_64. It's seems to be fixed on ubuntu. Did I misunderstood? (When) would it come to arch? Thanks for your help, and your time! -- Samuel Martín Moro {EPITECH.} tek5 CamTrace S.A.S (+033) 1 41 38 37 60 1 Allée de la Venelle 92150 Suresnes FRANCE "Nobody wants to say how this works. Maybe nobody knows ..." Xorg.conf(5)

5 10

[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