- Arch-general - lists.archlinux.org

[arch-general] [translation] pacman 4.0.1 release
by Dan McGee 14 Nov '11

14 Nov '11

I'd like to release 4.0.1 later this week. String changes are very minimal if you were up to date before; 3 new ones in pacman scripts and 2 capitalization changes in pacman. https://www.transifex.net/projects/p/archlinux-pacman/r/4-0-1/ Languages below could use some love if anyone is interested- please sign up as a team member through Transifex to get started: * Chinese (Taiwan) * Swedish * Danish * Russian * Kazakh * Slovak These are close but not quite up to date as of 4.0.0: * Polish * Turkish * Finnish * Portuguese Thanks! -Dan

1 0

[arch-general] Time delay problem with latest [core] kernel
by XeCycle 13 Nov '11

13 Nov '11

Hi, I'm using the latest kernel from [core] (linux 3.1-4), and experienced a terrible delay of software MIDI synthesizers. I'm using fluidsynth, using ALSA as the output driver (I simply can't get jack working), and VMPK as a keyboard MIDI event generator. The delay used to be fine, but with the latest kernel, it's longer than 0.5 secs --- that's unusable. I believe this should be kernel-related, could you please suggest some solutions or workarounds? -- 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

3 4

[arch-general] Display issues with Linux 3.1
by Taylor Hedberg 13 Nov '11

13 Nov '11

Since updating to Linux 3.1 yesterday, I've been having strange problems with the display on my laptop. The first reboot after updating the kernel went normally, but every subsequent boot since then has had problems. This is a Dell Latitude D620 laptop with the following graphics-related lines in the lspci output: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) During boot, at the stage where it says "Waiting for UDev uevents to be processed", the backlight normally blinks and the display mode changes, presumably due to udev detecting my graphics hardware. Since the kernel update, the backlight still blinks off momentarily, but when it comes back on, the screen remains blank. Rather than seeing the rest of the boot messages, the display is just black (but backlit). The system still seems to boot like normal; I boot to the virtual console rather than starting X automatically, and once the hard disk activity stops after booting, I can blindly type my login credentials and issue shell commands, though I still can't see any output. Additionally, after the first reboot following the update (which did not have the aforementioned display problems), I had issues with the display backlight after starting X. If I shut the laptop lid, the backlight usually shuts off, and comes back on when I reopen it. However, after the kernel update, around 80% of the time, the backlight seemed to come back on at about a third of its usual brightness. I had to close and reopen it several times, and eventually it would come on at full power like normal. I managed to boot the system in single-user mode using the fallback initcpio image (any other combination of boot options seemed to result in the blank screen), and then downgraded the kernel back to 3.0.7. After downgrading, all of these problems seem to have disappeared. I've scanned through dmesg output and I don't really see anything out of the ordinary. But I admit that I don't really know what I'm looking for. Any thoughts or suggestions?

11 25

[arch-general] Systemd Questions / Problem
by Eric Griffith 13 Nov '11

13 Nov '11

Hey everyone, I've been reading up on Systemd lately, trying it out in a VM just to see how the setup and everything and I've run into 1 problem, along with a few questions about it. The main question I have about it related to its "On Demand Loading" of daemons. What exactly does this mean in a desktop or server environment? Such as, if my desktop is just sitting there, no configuration done beyond just installing openssh, and I'm at my laptop and I tell it ssh root@desktop. Will systemd automatically spot the incoming ssh connection, since its watching the ssh socket, and start sshd, and then stop it again when I close the connection? Or would I still need to issue "systemctl enable sshd.service" so that sshd is permanently enabled after a reboot? Related to the above; whats the difference between 'enabled' and 'started' / 'active.' following a reboot? The reason I ask is because after I got systemd setup in the VM, and enabled network.service, i rebooted. When I got back into the VM, i tried to ping google, and it wouldn't go through. I checked the status of network.service, it said it was enabled, but "started (inactive)," So i'm confused. If its enabled, and started...why was it inactive? If we assume for a second that systemd temporarily killed the network because nothing was being done with it, then why didnt systemd restart it when it caught activity on the network from me issuing the ping command? The problem I'm having is after sym-linking /etc/systemd/system/default.target to /lib/systemd/system/graphical.target, when I reboot I get dropped into a rescue shell saying: "Failed to issue method call: Unit graphical.target is masked." Anyone able to translate that?

2 1

[arch-general] Gnome's notification
by Carlos Alberto Ospina 13 Nov '11

13 Nov '11

Hi everybody / hola tod@s [english] some time ago that gnome notifications doesn't work, rthymboxand the integration of empathy doesn't work. Anyone have the same problem? Any suggestion? [español] hace un tiempo que las notificaciones de gnome no funcionan, rthymbox y la integracion de empathy no trabajan. Alguien tiene el mismo problema? Alguna sugerencia? Greetings / un saludo Carlos Alberto Ospina E. Linux User #506652

1 0

[arch-general] Building coreutils
by Myra Nelson 12 Nov '11

12 Nov '11

I changed the cflags in makepkg.conf and have been rebuilding packages and have a problem building coreutils. The following is an excerpt from the check log with the appropriate line numbers. 1501 ================================ 1502 1503 Skipping test: no chinese GB18030 locale is installed 1504 1505 FAIL: test-parse-datetime (exit: 134) 1506 ================================= 1507 1508 test-parse-datetime.c:142: assertion failed 1509 1510 SKIP: test-setlocale1.sh (exit: 77) 1511 =================================== 1512 1513 Skipping test: no locale for testing is installed 1514 My current settings in makepkg.conf are: CFLAGS="-march=native -O2 -pipe -fstack-protector-all --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" CXXFLAGS="-march=native -O2 -pipe -fstack-protector-all --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu" MAKEFLAGS="-j3" I run with testing repos enabled so I don't cherrypick anything, I simply rebuild my packages with the above configuration, and in 90% of the cases I manage to figure out my problems and fix them. I always assume it's something I've done my self first, then look elsewhere later. The way I get my PKGBUILDS etc is [ svn checkout --depth-empty ] then [ svn update [ pkgname ] ] then build the trunk version. If that doesn't work I try the testing repos, which I assume is the same as trunk but try it anyway. After that I search for bugs relating to the package, this time coreutils and the only thing I could find was related to ISO-8601 [ http://lists.gnu.org/archive/html/bug-coreutils/2011-10/msg00096.html ] but wasn't sure it was directly related. This from the end of the check: 1 of 269 tests failed (25 tests were not run) See gnulib-tests/test-suite.log Please report to bug-coreutils(a)gnu.org ====================================== make[6]: *** [test-suite.log] Error 1 make[6]: Leaving directory `/mnt/myra/myra/build/arch_svn/packages/coreutils/trunk/src/coreutils-8.14/gnulib-tests' make[5]: *** [check-TESTS] Error 2 make[5]: Leaving directory `/mnt/myra/myra/build/arch_svn/packages/coreutils/trunk/src/coreutils-8.14/gnulib-tests' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/mnt/myra/myra/build/arch_svn/packages/coreutils/trunk/src/coreutils-8.14/gnulib-tests' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/mnt/myra/myra/build/arch_svn/packages/coreutils/trunk/src/coreutils-8.14/gnulib-tests' make[2]: *** [check] Error 2 make[2]: Leaving directory `/mnt/myra/myra/build/arch_svn/packages/coreutils/trunk/src/coreutils-8.14/gnulib-tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/mnt/myra/myra/build/arch_svn/packages/coreutils/trunk/src/coreutils-8.14' make: *** [check] Error 2 [1m38;5;1m==> ERROR:A failure occurred in check() [1m Aborting... This from test-parse-datetime.log FAIL: test-parse-datetime (exit: 134) ===================================== test-parse-datetime.c:142: assertion failed This from test-parse-datetime.c 136 /* ISO 8601 extended date and time of day representation, 137 'T' separator, local time zone */ 135 p = "2011-05-01T11:55:18"; 137 expected.tv_sec = 1304250918 - gmtoff; 138 expected.tv_nsec = 0; 139 ASSERT (parse_datetime (&result, p, 0)); 140 LOG (p, expected, result); 141 ASSERT (expected.tv_sec == result.tv_sec 142 && expected.tv_nsec == result.tv_nsec); After checking all these I cloned the git repo for coreutils, applied the patch files, bootstraped the build which clones the gnulib repo and builds it, then ran [ ./configure --prefix=/usr --libexecdir=/usr/lib/coreutils \ --enable-install-program=su \ --enable-no-install-program=groups,hostname,kill,uptime \ --enable-pam CFLAGS="-march=native -O2 -pipe -fstack-protector-all --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" \ LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu" ] which duplicates the PKGBUILD and my makepkg.conf, then make -j3, then [ make RUN_EXPENSIVE_TESTS=yes check ] and all the tests passed. I did this twice just to make sure I'd done it the same both times and achieved the same results I previously built this package as below with no problems with the following makepkg.conf [ CFLAGS="-march=amdfam10 -m64 -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu" ] [myra@gandalf ~]:pacq coreutils Name : coreutils Version : 8.14-1 URL : http://www.gnu.org/software/coreutils Licenses : GPL3 Groups : base Provides : None Depends On : glibc shadow pam acl gmp libcap Optional Deps : None Required By : ca-certificates dbus-core filesystem hwdetect initscripts linux linux-pf mkinitcpio mlocate netcfg perl pkgstats rpmextract sysvinit Conflicts With : None Replaces : mktemp Installed Size : 13860.00 KiB Packager : Myra Nelson <myra.nelson(a)hughes.net> Architecture : x86_64 Build Date : Sat 15 Oct 2011 02:07:03 AM CDT Install Date : Sat 15 Oct 2011 02:08:51 AM CDT Install Reason : Installed as a dependency for another package Install Script : Yes Description : The basic file, shell and text manipulation utilities of the GNU operating system Apparently something changed between know and then as my only changes were in my makepkg.conf file and I know use localepurge to remove locales that I don't use. My assumption in not having the extra locales on my machine casued the failure, but thought I would put this out there anyway to make sure. Thanks for your time and assistance. Myra -- Life's fun when your sick and psychotic!

1 0

[arch-general] Bad LUN and bad target number messages during boot
by Lorenzo Bandieri 12 Nov '11

12 Nov '11

Hello archers, I'm running Arch Linux on an Acer Aspire One D257 [1]. Since last month, I've notices these messages showing up during the boot process: (from dmesg | less) [ 6.714686] Bad LUN (0:1) [ 6.715042] Bad target number (1:0) [ 6.715437] sd 4:0:0:0: [sdb] Attached SCSI removable disk #I usally don't see this one [ 6.715733] Bad target number (2:0) [ 6.716020] Bad target number (3:0) [ 6.716308] Bad target number (4:0) [ 6.716594] Bad target number (5:0) [ 6.716937] Bad target number (6:0) [ 6.717225] Bad target number (7:0) Just before the aforementioned messages, I see also: (this time from less /var/log/everything.log ) [ 5.730996] acer_wmi: No or unsupported WMI interface, unable to load I don't know if these messages are connected (I don't think so) Apparently, this doesn't lead to further problems. My google searches did not return anything useful, except that others experienced similar messages; there is even one thread in the Arch Forum [2], but didn't get much attention. As far as I can see, there are no bug reports or documentation concerning messages like these. It seems something regarding SD card reader... Now, I'm wondering: - Is it a known problem? - What do these messages mean? - Can it cause problems or harm my hardware? Should I be worried? - Should I fill a bug report...? Now, some output: # ls /sys/block/ sda sdb # cat /proc/partitions major minor #blocks name 8 0 244198584 sda 8 1 104391 sda1 8 2 2048287 sda2 8 3 51207187 sda3 8 4 190836135 sda4 # fdisk -l Disk /dev/sda: 250.1 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00097750 Device Boot Start End Blocks Id System /dev/sda1 * 63 208844 104391 83 Linux /dev/sda2 208845 4305419 2048287+ 82 Linux swap / Solaris /dev/sda3 4305420 106719794 51207187+ 83 Linux /dev/sda4 106719795 488392064 190836135 83 Linux # cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: Hitachi HTS54322 Rev: ESBO Type: Direct-Access ANSI SCSI revision: 05 Host: scsi4 Channel: 00 Id: 00 Lun: 00 Vendor: Generic- Model: xD/SD/M.S. Rev: 1.00 Type: Direct-Access ANSI SCSI revision: 02 #cat /etc/fstab # # /etc/fstab: static file system information # # <file system> <dir> <type> <options> <dump> <pass> tmpfs /tmp tmpfs nodev,nosuid 0 0 UUID=0d3cf67e-565e-495c-bac8-66dfd290b882 /boot ext2 defaults 0 1 UUID=21b920dc-54a0-43a5-9e37-e7c7e85e4cba /home ext4 defaults,noatime,nodiratime 0 1 UUID=5d8f2ea7-de29-4972-a127-0ea2363d65fd swap swap defaults 0 0 UUID=784fbd71-712f-4b1f-9ea7-f2c681cdbbda / ext4 defaults,noatime,nodiratime 0 1 [1] http://us.acer.com/ac/en/US/content/model/LU.SFS0D.002 [2] https://bbs.archlinux.org/viewtopic.php?id=124139 Thanks to everyone. Best regards, Lorenzo

1 0

[arch-general] [OT, maybe] "Secure Key Generation"
by Gr., F. 12 Nov '11

12 Nov '11

Hi, I think the following is interesting: "However, this imply another problem: all the signatures made on other keys would be invalid too after the expiration of our key, unless we renew it periodically. Moreover, if we decided not to renew our old key after its expiration but to generate a new one, we would need to collect again on the new key all the signatures that other persons made on the old one." (source: <http://tjl73.altervista.org/secure_keygen/en/en.html>) In short (for who knows GPG): - create a public key -- RSA (sign only) - backup your '.gnupg' dir and keep it in a secure place - add a subkey for encryption - export your subkey - delete secret and public key - import your subkey - to modify our key we can type the command 'gpg2 --no-permission-warning --homedir <your path> --keyring ~/.gnupg/pubring.gpg --secret-keyring <your path> --trustdb-name ~/.gnupg/trustdb.gpg --edit-key <keyid>' - to sign other keys 'gpg2 --no-permission-warning --homedir <your path> --keyring ~/.gnupg/pubring.gpg --secret-keyring <your path> --trustdb-name ~/.gnupg/trustdb.gpg --edit-key <key imported>' That's all. :-) -- Law is mind without reason. --Aristotle

1 0

[arch-general] [signoff] kernel26-lts 2.6.32.48-1
by Tobias Powalowski 11 Nov '11

11 Nov '11

Latest LTS kernel is in testing, Attention: - This version uses the /lib/modules/extramodules-2.6.32-lts for self compiled modules - uname -r now reports the real kernel version, like the 3.x series does please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

1 0

[arch-general] linux 3.1-4 - two i686 lockups after ~ 5 hours of operations. two x86_64 seem OK
by David C. Rankin 10 Nov '11

10 Nov '11

tpowa, Upgraded 5 i686 boxes and 2 x86_64 boxes to linux 3.1-4 yesterday night. This morning, one i686 server is dead, other i686 box responded to xterm (return input) and then locked (ssh connection was left up after login to confirm reboot). Two other i686 boxes (under no load) still running. The boxes are remote. I'll pull the logs when I get to the site and send. Anybody else seeing this with linux 3.1-4? -- David C. Rankin, J.D.,P.E.

8 19