- Arch-general - lists.archlinux.org

[arch-general] ARCH .y kernel releases do not match kernel.org's
by Emmanuel Benisty 24 Apr '11

24 Apr '11

Hi, I was having some sound issue with ARCH 2.6.38.3 stock kernel so I started to bisect it from Greg KH's 2.6.38.y stable tree. .38.2 was good and .38.3 was bad (so I thought) but I hadn't any single bad commit during bisecting. However, .38.4 /was/ bad. I could finally find the guilty commit (which is in .38.4) but couldn't understand why I was hit by this issue even with 2.6.38.3-ARCH. Then I diff'd both .38.3 patches and found out that Arch's one includes patches that are not in Greg's release. It seems we include patches that are still in -stable patch queue. Finally, I just have one question: is that normal? All I can say is that it made my bisecting session a real PITA. Please give me back my CPU cycles :P Cheers. -- Emmanuel

3 3

[arch-general] scipy package - is there anything important that stops the update to 0.9?
by Andrzej Giniewicz 24 Apr '11

24 Apr '11

Hi all, I'd like to ask if there are any important issues regarding update of python-scipy? It's been flagged out of date for nearly two months, that's quite long time for Arch standards! Is there any issue remaining to be solved, anything I can help with? I'd really like to see this updated to 0.9, as I have some aur packages waiting for this. Cheers, Andrzej.

3 5

[arch-general] Updated TeXLive packages
by Rémy Oudompheng 23 Apr '11

23 Apr '11

Hello, I have uploaded updated TeXLive packages in [testing]. Apart from regular package updates from TeXLive, symlinks now belong to their respective packages (FS #23174, FS#22736). Since the currently shipped LuaTeX version (0.62) was unstable, as well as 0.66, the luatex in texlive-bin is now a SVN snapshot. TeXLive 2011 should be officially out this summer, so the next package update will probably be numbered 2011.x -- Rémy.

1 0

[arch-general] building tp_smapi from AUR
by Fons Adriaensen 23 Apr '11

23 Apr '11

Don't know if this is the right place to ask... I'm trying to install tp_smapi from AUR. The maintainer is listed as 'xduugu' without mail address. Everything runs fine until: ==> Starting build()... patching file Makefile patching file thinkpad_ec.c patching file tp_smapi.c patching file hdaps.c make -C /lib/modules/2.6.37-ARCH/build M=/data/build/tp_smapi/src/tp_smapi-0.40 O=/lib/modules/2.6.37-ARCH/build modules make[1]: Entering directory `/usr/src/linux-2.6.37-ARCH' CC [M] /data/build/tp_smapi/src/tp_smapi-0.40/thinkpad_ec.o /data/build/tp_smapi/src/tp_smapi-0.40/thinkpad_ec.c: In function ‘check_dmi_for_ec’: /data/build/tp_smapi/src/tp_smapi-0.40/thinkpad_ec.c:468:1: warning: the frame size of 1328 bytes is larger than 1024 bytes CC [M] /data/build/tp_smapi/src/tp_smapi-0.40/tp_smapi.o CC [M] /data/build/tp_smapi/src/tp_smapi-0.40/hdaps.o Building modules, stage 2. MODPOST 3 modules CC /data/build/tp_smapi/src/tp_smapi-0.40/hdaps.mod.o LD [M] /data/build/tp_smapi/src/tp_smapi-0.40/hdaps.ko CC /data/build/tp_smapi/src/tp_smapi-0.40/thinkpad_ec.mod.o LD [M] /data/build/tp_smapi/src/tp_smapi-0.40/thinkpad_ec.ko CC /data/build/tp_smapi/src/tp_smapi-0.40/tp_smapi.mod.o LD [M] /data/build/tp_smapi/src/tp_smapi-0.40/tp_smapi.ko make[1]: Leaving directory `/usr/src/linux-2.6.37-ARCH' ==> Entering fakeroot environment... ==> Starting package()... make: Entering directory `/usr/src/linux-2.6.37-ARCH' INSTALL /data/build/tp_smapi/src/tp_smapi-0.40/hdaps.ko INSTALL /data/build/tp_smapi/src/tp_smapi-0.40/thinkpad_ec.ko INSTALL /data/build/tp_smapi/src/tp_smapi-0.40/tp_smapi.ko DEPMOD 2.6.37-ARCH make: Leaving directory `/usr/src/linux-2.6.37-ARCH' mv: cannot stat `extra/hdaps.ko': No such file or directory ==> ERROR: A failure occurred in package(). Aborting... And indeed there's no hdaps.ko in the 'extra' directory. Any ideas ? TIA, -- FA

1 0

[arch-general] pacman: -Ss search results weird
by Marek Otahal 22 Apr '11

22 Apr '11

Hi, regarding the recent 'default syslog' discussion I wanted to check what is Arch up to now...I came to interesting results concerning pacman's search behavior. [marek@beruska ~]$ pacman -Ss syslog core/perl 5.12.3-1 [12.06 MB] (base) [installed] A highly capable, feature-rich programming language core/syslog-ng 3.2.2-2 [0.21 MB] (base) Next-generation syslogd with advanced networking and filtering capabilities extra/metalog 1.0-1 [0.02 MB] Metalog is a modern replacement for syslogd and klogd community/perl-device-modem 1.53-1 [0.04 MB] Perl extension to talk to modem devices connected via serial port community/rsyslog 5.8.0-1 [0.25 MB] [installed] An enhanced multi-threaded syslogd with a focus on security and reliability [marek@beruska ~]$ I thought pacman -Ss "string" searches packages' name and desc for the string, I wonder why the perl things show up? Cheers & happy Eastern! :) -- Marek Otahal :o)

4 4

[arch-general] How to install a group when a package with same name exists?
by Cédric Girard 22 Apr '11

22 Apr '11

Hi, Today I wanted to install the group (xorg-apps). But there is a package with the same name. I did not find a way to tell pacman I wanted the group and not the package. I ended doing this: sudo pacman -S `pacman -Sg xorg-apps | sed 's!xorg-apps $.*$!\1!'` But there must be an easier way. Any thought about this? Regards, -- Cédric Girard

4 4

[arch-general] [arch-dev-public] [signoff] mkinitcpio 0.6.11
by Thomas Bächler 22 Apr '11

22 Apr '11

Version 0.6.10 was busted, this time everything should be fine (finally). Thomas Bächler (2): Rewrite parse_cmdline (again) Release version 0.6.11 There is a problem: The new filesystem package was moved to core and creates /run, but /run is not usable as it is not a world-writable tmpfs. We need this and the new initscripts (which should be released soon) in core quickly. Moving mkinitcpio only should suffice for now. Please sign off quickly. This is a copy of the last announcement: Fixes: - FS#23467 - FS#22080 - FS#13900 - FS#23622 It also introduces /run. Please sign off. Shortlog: Thomas Bächler (6): Fix broken command line parsing due to insufficient quoting introduced in 42e8dba5dce4879e4a372c5c2fb5446b4e8bb16c. init: Unify/improve mount --move handling Introduce /run Allow initramfs to be completely silent: Fix problems in parsing the kernel command line Release mkinitcpio 0.6.10

3 2

[arch-general] Myths and reality about cronie
by Kaiting Chen 22 Apr '11

22 Apr '11

I've compiled a short document describing exactly what cronie is and is not; and if it were to be the default what would and would not happen to base, [core], and the rest of Arch. It is my hope that this will clear up some of the misunderstanding surrounding the current discussion on arch-general. First of all the cronie in [community-testing] is compiled with --enable-anacron. It installs not only an /etc/crontab but also an /etc/anacrontab. Scripts in '/etc/cron.hourly' are run directly by `/usr/sbin/crond` while scripts in '/etc/cron.daily', '/etc/cron.weekly', and '/etc/cron.monthly' are run by indirectly by `/usr/sbin/crond` through `/usr/sbin/anacron`. Therefore it will accommodate both machines that are run continuously and machines that are not. Second cronie will in no way `replaces=('dcron')` but will most likely `conflicts=('dcron')`. Therefore while it will be impossible to install both on the same system having cronie in [core] will in no way force existing users to switch. Third if cronie is picked up as the default it will enter the 'base' group while 'dcron' will leave the 'base' group. In the foreseeable future there will never be a situation in which a package that is not in [core] is in 'base'. Next it is absolutely not the case that every package in 'base' is critical to the operation of a machine. For example 'reiserfsprogs' is in 'base' but unless you have a ReiserFS filesystem then you don't need it. Every package in 'base' is however installed by default. Please note that the following point is my opinion and does not in any way necessarily represent anyone else's point of view: At no point in time in the near future will 'systemd' become the default on Arch. It may certainly enter [extra] or [core], but sorry Thomas and falconindy, I just don't see it becoming the default for a while. Therefore waiting for 'systemd' to become the new default to replace 'dcron' is a serious mistake as we would be waiting a very very long time. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

5 5

[arch-general] [signoff] kernel26-2.6.38.3-1
by Tobias Powalowski 22 Apr '11

22 Apr '11

Hi guys, please signoff 2.6.38.3 series for both arches. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

2 2

[arch-general] Change Arch's default crond
by Sven-Hendrik Haase 22 Apr '11

22 Apr '11

We all know the situation with dcron (it can't keep time properly) and it still is broken. No fix (or any changes for that matter) have gone into its upstream git for over a year now. There have been multiple yeah-I'll-take-a-looks from various people as well as its upstream maintainer and no work was done. I certainly don't want to offend anybody but I think it is time another crond was made quasi default by swapping it for dcron in base group. I know that users can do that themselves but the we shouldn't suggest packages we know are broken by putting them into the base group. Perhaps fcron is a fine choice. Bug report for reference: https://bugs.archlinux.org/task/18681 -- Sven-Hendrik

37 121