- Arch-general - lists.archlinux.org

[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

[arch-general] rlocate status
by SanskritFritz 10 Nov '11

10 Nov '11

I saw rlocate was moved into community in 2008 and again back to aur. I remember trying it once, but could not compile it. Now it complains "configure: error: *** rlocate needs kernel 2.6 to work". What is the status of this project now, is it usable in archlinux? I find the idea very attractive.

2 2

[arch-general] codecs/codecs64 - what's the scoop? Why the massive difference.
by David C. Rankin 10 Nov '11

10 Nov '11

Guys, I'm trying to figure out why the i686 codecs package (rm from extra now in aur) is so massively different from the x86_64 codecs64 package in aur. The i686 package seems fine, but the x86_64 package seems to be nothing but a shadow of a package: 183164 Nov 10 00:08 codecs64-20071007-1-x86_64.pkg.tar.xz 183k? The codecs i686 package is: 18465084 Nov 9 17:51 codecs-20110131-1-i686.pkg.tar.xz 18.4M ? I read the aur notes about the i686 and x86_64 bit versions use different upstream releases and contain completely different codecs, but I don't understand why or how this can possibly work. I have also read https://wiki.archlinux.org/index.php/Codecs which seems a bit 'tounge-in-cheek', but provides no additional information. Anybody know more? Does the x86_64 package even work? If you use these, please let me know. Thanks. -- David C. Rankin, J.D.,P.E.

2 2

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

09 Nov '11

Latest LTS kernel is in testing, 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] timezones
by Jorge Almeida 09 Nov '11

09 Nov '11

I have HARDWARECLOCK="UTC" TIMEZONE="right/Portugal" in /etc/rc.conf, but I'm not sure this is the right thing to do. I use clockspeed to keep the clock synchronized with a ntp server, and other sofware requires a "right/*" timezone. Anyone has any knowledge to share about this issue? For example, "date" gives output that ignores leap seconds. Is this a date issue, unrelated with rc.conf? Anyone else using a right/* timezone? TIA J.Almeida

3 5