- Arch-general - lists.archlinux.org

[arch-general] x terminals refresh issue with latest kernels
by Sergey Manucharian 06 Jun '11

06 Jun '11

I have already reported this problem in kernels' sign-off threads, but still have no solution... With kernels 2.6.38 or 2.6.39 xterm and rxvt do not update the content properly. E.g. I enter "ps -ef" command and see only the first 2 lines at the top and empty space below. In some cases the new command output does not appear at all, I see just the previous command result. The terminal blinks every 6-7 seconds, and for very short time I can see the proper content. As soon as the terminal loses the focus (mouse cursor moved, alt-tab, workspace change) it shows the proper content. However it never happens with roxterm, but it is a gtk-based program. I'm running x86_64 Archlinux on ThinkPad R61 with Intel GM965, xserver 1.10.2. I've tried the recent xf86-video-intel driver from git - no difference at all. Any ideas, please? Thanks, Sergey

2 1

[arch-general] Installation images in need of an update?
by JM 05 Jun '11

05 Jun '11

Hello, The current installer images are from 05.2010 which is over a year old. I was unable to install Arch on my new laptop using this installer due to insufficient hardware support in kernel 2.6.33. Are there any plans to update it? Regards, JM

2 2

[arch-general] pacman "Targets" sort order
by David C. Rankin 05 Jun '11

05 Jun '11

Guys, I don't know if I am remembering correctly, but I thought the upgrade "Targets" were sorted alphabetically by name prior to the pacman upgrade a month or two ago. Now, it looks like they are listed either by repository, then alphabetized or some other logic that ends up -- almost alphabetized. Specifically: Targets (35): bluez-4.93-1 run-parts-3.4.4-1 ca-certificates-20110421-3 dcron-4.5-2 libzip-0.10-1 ebook-tools-0.2.1-2 eina-svn- 58920-1 eet-svn-58955-1 evas-svn-58958-1 ecore-svn-58945-1 e_dbus-svn-58954-1 embryo-svn-58829-1 edje-svn-58887-1 pciutils-3.1.7-4 udev-167-2 eeze-svn-58668-1 efreet- svn-58672-1 e-svn-58940-1 gutenprint-5.2.7-1 hdf5-1.8.6-1 libidn-1.21-1 libxcb-1.7-2 networkmanager-0.8.999-1 openssh- 5.8p2-1 python2-cairo-1.10.0-1 python2-distribute-0.6.16-1 qt-4.7.3-1 rp-pppoe-3.10-6 sudo-1.8.1.p1-1 telepathy- qt4-0.5.16-1 zziplib-0.13.60-1 texlive-bin-2010.1-8 texlive- core-2010.22154-1 udev-compat-167-2 usbutils-002-2 bluez -> run-parts -> ca-certificates?? In the past, I would scan the list to make sure there were no updates that I didn't want or that I needed to put off due to bugs or what not. Now I've been bitten a time or two by searching through long Target lists and confirming there were no unwanted updates only to find out that an unwanted update was alphabetized higher-up or lower in the target list. Has the target list always sorted by repo, then by name --or-- was the list fully sorted by name earlier? If so, is it easy to change? In short lists, it's not really a big deal, but when you have over 100 targets, having them sorted by name really helps. What say the pacman gurus? -- David C. Rankin, J.D.,P.E.

4 3

[arch-general] How to cache pacman mirror for LAN
by Takayuki Muranushi 05 Jun '11

05 Jun '11

Hello, I'm building a computer cluster with about 20 nodes, all of them running ArchLinux. One of them is the 'login' node connected to the Internet, other nodes share Internet connection via the login node being a router. https://wiki.archlinux.org/index.php/Internet_Share Now, when I update the system (pacman -Syu) or install package on all node, I think it's a bad idea because it will consume the mirror bandwidth proportional to the number of the nodes. Maybe it's not a big issue for 20 nodes, but I'd like to learn nevertheless for future use, that: Is there a way to cache the pacman transaction at the login node, so that the communication between the login node and the mirror is constant, and the rest of communications only take place within the LAN? Is seting up a pacman mirror at the login node is the correct solution? Best, Takayuki Muranushi

5 5

[arch-general] Lyx 1.6 vs. 2.0
by Bernardo Barros 05 Jun '11

05 Jun '11

Hi, Is there a reason not to update Lyx 1.6 to 2.0? Or at least create two packages lyx1 and lyx? Is there known bugs there? Best! Bernardo

2 1

[arch-general] Was Fwd: [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.2-1, net-tools-1.60-15, udev-171-2, yp-tools-2.12-2
by Myra Nelson 04 Jun '11

04 Jun '11

---------- Forwarded message ---------- From: Myra Nelson <myra.nelson(a)hughes.net> Date: Sat, Jun 4, 2011 at 12:10 Subject: Re: [arch-dev-public] [signoff] coreutils-8.12-2, initscripts-2011.06.2-1, net-tools-1.60-15, udev-171-2, yp-tools-2.12-2 To: Public mailing list for Arch Linux development <arch-dev-public(a)archlinux.org> On Sat, Jun 4, 2011 at 11:30, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: > On Sat, Jun 4, 2011 at 4:58 AM, Tom Gundersen <teg(a)jklm.no> wrote: >> On Sat, Jun 4, 2011 at 5:41 AM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: >>> FWIW, the instructive comments in udev.conf doesn't mention "warning" >>> as a valid value. >> >> Oops, I meant to say "info". > > I also tried info when I tried with debug. I didn't noticed any > difference with debug as far as the excessive output go. I could try > it again and check dmesg more carefully. > > >> >>> I tried it and the error message doesn't get >>> printed. Dmesg doesn't have the error message and the logs are >>> useless since the error happens when the kernel is booting, i.e. >>> rc.sysinit isn't running yet. I suppose it's mkinitcpio/udev related. >> >> If rc.sysinit is not running, then this is an mkinitcpio problem. I >> guess the reason you are seeing it again might be a race? We have sped >> things up quite a bit with this release, so things might race >> differently than before. > > That's what I believe. I didn't mentionned it but dmesg contains > output saying that the raid was assemble and all mirrors are active. > So despite the error message from udevd, the kernel still manage to > assemble the raid array. Also, I can't find the hook or config file > that contains the mdadm command line displayed in the error message. > I looked in /etc and /lib/initcpio but it's not there. > >> >>> They work as expected. The error is not fatal. My raid array gets >>> assembled without user intervention. Either it is eventually done by >>> the initscripts (I can't find where, I think that code parthas been >>> removed) or by something else. >> >> My guess is that the error you are seeing is from udev in mkinitcpio, >> and the udev in rc.sysinit works correctly. To change the error >> reporting you would need to run mkinitcpio -p kernel26 after updating >> udev.conf. > > I was updating my initcpio file when changing the udev.conf. > >> >>>>> Also, my loopback interface didn't started. When I ran "/usr/sbin/ip >>>>> link set up dev lo" manually in a terminal, it started fine. I don't >>>>> know why it didn't work when booting up. >>>> >>>> Do you see anything in the above logs? >>> >>> I found the source of this error. My /usr is on it's own partition. So >>> when rc.sysinit attemps to setup the loopback interface with >>> /usr/sbin/ip, my /usr partition is not mounted yet. So it fails. I >>> don't know what would be the best way to fix. Maybe moving ip to /sbin >>> or to postpone the lo interface setup after the partitions are >>> mounted. >> >> Ahhhh. I think this might cause many more problems than just the >> loopback. In particular, anything called in udev rules may reside on >> /usr. This means the rule will fail and it will not be rerun. >> >> Have a look at "grep /usr /lib/udev/rules.d/*" to see examples of what >> might be broken. >> >> Most other distros, and upstream projects have given up on supporting >> a separate /usr, so it will be buggy. I suggest moving your /usr to >> your rootfs, regardless of this particular problem. >> > > I recall you mentionning that on another ML thread. I wanted to ask > you for details at the time but did get to. > I'll move my /usr to my rootfs. I use lvm2 so the > resizing/repartionning should be easy. > >> As to the loopback device. I don't think it is a good idea to delay >> this to after /usr is mounted. If anything we might want to move it >> earlier in boot. That leaves moving ip out of /usr. >> >> Does anyone know the consequences of this? Do we want to keep >> supporting a separate /usr? > > If I'm the only one with the problem, you can also keep things as they > are now, i.e. not support /usr on a separate partition. As I'll be > moving my /usr, that problem will become moot. > > Eric > >> >> Cheers, >> >> Tom >> > One quick question, why do I still have udev 169 and udev 171 starting. My /usr is on a separate partition and my loopback is not starting, but everything appears to work well. From the timing I would assume one is the mkinitcpio and one is rc.sysinit but thought I would check first. [myra@gandalf /var/log]:pacman -Qi udev Name : udev Version : 171-2 [myra@gandalf ~]:dmesg | grep udev [ 1.311992] udevd[86]: starting version 169 [ 5.723615] udevd[598]: starting version 171 [myra@gandalf ~]:sudo tail -n 2000 /var/log/everything.log | grep udev Jun 3 10:18:21 localhost [ 1.318643] udevd[86]: starting version 169 Jun 3 10:18:21 localhost [ 6.176941] udevd[609]: starting version 171 Jun 4 11:33:45 localhost [ 1.311992] udevd[86]: starting version 169 Jun 4 11:33:45 localhost [ 5.723615] udevd[598]: starting version 171 Myra -- Life's fun when your sick and psychotic! -- Life's fun when your sick and psychotic!

3 3

[arch-general] archlinux touchscreen problem on aigo p8880
by 吕宗庭 03 Jun '11

03 Jun '11

hello， I run archlinux on aigo p8880 with kernel 2.6.39 GMA500 with psb-gfx-bzr follow the link: wiki.archlinux.org/index.php/Poulsbo it works OK. But,the touchscreen doesn't works . someone can help me?

1 0

[arch-general] initscripts change
by Carl Mueller 03 Jun '11

03 Jun '11

Why change the modules array in initscripts? I always read that Arch was great because almost all configurations were done in one file, namely rc.conf.

2 1

[arch-general] [translation] Pacman 3.5.3 release soon
by Dan McGee 02 Jun '11

02 Jun '11

If you are interested in updating any translations before I release this maint version early next week, please do so: https://www.transifex.net/projects/p/archlinux-pacman/r/3-5-3/ Thanks! -Dan

1 0

[arch-general] /dev/snd/seq: Group permission lost
by XeCycle 02 Jun '11

02 Jun '11

Recently I need to chmod it manually after reboot. It's now 600, belong to root, group audio, I think 660 is better. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591 Facebook: Carl Lei Twitter: XeCycle Blog: http://xecycle.blogspot.com Thu, 02 Jun 2011 10:31:13 +0800

3 2