July 2012 - Arch-general - lists.archlinux.org

[arch-general] In the systemd scheme, where should startup/stop scripts for things systemd can't handle go?
by David Benfell 28 Jul '12

28 Jul '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, So now that I've got a network through systemd, I ran into trouble with some daemon service files that I crafted by hand. None of the following directives will work (culled from different files): ExecStartPre=cd /etc/solr ExecStart=$JAVA_HOME/bin/java -jar $JAVA_OPTS start.jar $JETTY_OPTS >> /var/log/jetty.log 2>&1 ExecStop=kill `pidof -o %PPID /usr/sbin/dictd` 2>/dev/null 1>/dev/null Basically lots of things that would be normal in a shell are problematic. So I need to create separate scripts to start and stop some daemons. I'm thinking I definitely do not want to use /etc/rc.d for this (I had to back out and go back to init and /etc/rc.d is still in use for that). Is there some consensus on where such scripts should go? - -- David Benfell benfell(a)parts-unknown.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQEv+RAAoJELT202JKF+xp9rAP/1+hg9rapqIp8xI01vJ6Uvyd twIXA5bD3LvGS36FkCTmapdpcNKxGzCgxIoXcST0Qe1uJsrFboTl7LGJ14dmBBqg 05tqpvg6Vv4/tv+ac4S6dIO9uY0SmyzZoQMue5B0cvGvEAb7vcdh+dCjru0/YGis 8Nzsyyv3c/hJE43GIL4buz46cqKhcJqQyJAs8xXBbM50uchr2vpOQ6F2COMs196C 4NeLnPut4Gc5xZJd0cJmS/cqAYd7CYH0UX6gGYfxo9GT+CVoLJmnSeooNiRZZBAN uO/Fq7azsN8jRBWynmS0Ckqt5Dx1ErPyW/J2uj3UinMbg2XeOK2cLbmYAsmWyLIu 9fnWfsllHXEs+phbk4qUerojHDH4p/IQAyNV2FsiLVQmAV0FXKZB39NaM+7ws7z4 X9xbRcWKM8kTAflmPdiaGGmDJ7v8E0yhaB/0IbTbAhM2HDQxUVvgpHZFSyiQbR8T pED90wLp2iv10Jl16K/GRdn6GjMLS4QVftAWdPUyfR9NlLV/wPGVsB4jVmTmLzM5 jw0JJvKyrybZvJP0l/G/mUX+0KxHHcSQaldhTL2q5jlD+ZbHOda1inwgH5Dq+eJ2 ruJDNXYIy0Jy7fa1J3Wh+9FRk9LEo9VEdoQhPzjjhYXZ4qnkwRd5etmUun99v6/2 FX8jWC4EAX6Gb0gq9Fxh =zGji -----END PGP SIGNATURE-----

5 12

[arch-general] talking arch disk and instructions were both outdated here
by Jude DaShiell 28 Jul '12

28 Jul '12

I'll have to download a newer copy of the talking arch disk among other things that takes account of pacstrap and uses the arch scripts rather than the framework to install archlinux. The braille instructions I made are also outdated so I'll fix that after some reading. Earlier this morning I got through the partitioning and formatting of a hard drive and since the material I have on archlinux on this end is that outdated, I decided to install debian on the large hard drive only archlinux could install on earlier. Debian would always thrash the disk before. This time no disk thrashing. Apparently use of archlinux to give debian some clues worked. I'll put archlinux on some of my smaller drives in the future when I figure out how to do that now that the talking archlinux I have no longer finds grub to install it. ---------------------------------------------------------------- Hardware eventually fails; software eventually works, no amount of band width can fix poor design Jude <jdashiel-at-shellworld-dot-net> <http://www.shellworld.net/~jdashiel/nj.html>

4 3

[arch-general] Uninstallable Packages
by Jeremiah Dodds 28 Jul '12

28 Jul '12

Sorry if this is dragging up an old topic, but I've been poking around AIF as I'm interested in possibly (hopefully) bringing it up to speed and/or improving it, and I noticed that it's still in the repos, but isn't installable by anyone who doesn't happen to have grub legacy still installed on their system, unless I'm missing something. It seems like we'd want to avoid having to manually remove packages every time it becomes impossible to install a set of them. This might be my unfamiliarity with libalpm or pacman or any other myriad part of the stack, but it seems like the type of thing that could be handled by a utlity and a cron job fairly easily. It also seems like the type of thing that wouldn't be too annoying to deal with manually at the moment, but that could get frustrating for both users and devs down the line. Menial maintanence tasks like that[1] tend to end up sucking down a lot of people's time and energy in the long run, in my experience. If the lack of an automated "dead package remover" is just a "lack of time / patches welcome" type of thing, I'd volunteer to take a crack at writing the thing. If it isn't, I'd really like to know why. Footnotes: [1] unless, of course, it's not actually a menial task, in which case please enlighten me -- Jeremiah Dodds github: https://github.com/jdodds irc : exhortatory

3 3

[arch-general] arduino mega2560 and gcc-avr
by andrea crotti 28 Jul '12

28 Jul '12

I'm trying to use my arduino mega2560 with arch but there's no way to get it working yet.. I installed the arduino 1.0.1-1, and everything seems to work, until I try to use the Serial, when I get (compiling from gnoduino): avr:5 architecture of input file `/tmp/build1342512569.47XizyI/core.a(HardwareSerial.cpp.o)' is incompatible with avr:6 output collect2: error: ld returned 1 exit status I saw about a bug in avr-gcc but it should have been fixed long time ago, and it's probably not the same thing... Anyone got it working?

3 4

[arch-general] rc.conf changes, virtual consoles and initramfs
by Mauro Santos 28 Jul '12

28 Jul '12

So now that rc.conf was split and the change pushed to the stable repos I have been doing the necessary changes in my system. One problem I have found is that it is not clear how I can configure the system to load (in my case) pt-latin9 and compose.latin1 automatically. This is needed to be able to type things like â and ã. Having KEYMAP="pt-latin9 compose.latin1" in /etc/vconsole.conf will result in an error during boot. Another thing I have noticed is that this change may affect the keymap hook for people that need a fully working mapping, such as people with encrypted root. >From what I understand /etc/vconsole.conf will be sourced by /usr/lib/initcpio/install/keymap, listing both keymaps will probably result in an error that will not be reported since -q is used. Listing both keymaps separately will also not work since only the last attribution will take affect. Am I missing something here, or have I stumbled upon a problem? -- Mauro Santos

1 0

[arch-general] tmp cleanup problems
by Lukas Jirkovsky 28 Jul '12

28 Jul '12

Hi guys, Today I noticed a bunch of the following (kinda scary) errors on boot: Attempted to remove disk file system, and we can't allow that. rm_rf(/tmp): Operation not permitted And my /tmp is not cleaned up. I guess this is caused by the systemd-tmpfiles. I'm using initscripts. I use separate partition for my /tmp. I have following in the /etc/tmpfiles.d/tmp.conf: D /tmp 1777 root root 0d D /var/tmp 1777 root root 10d Is anyone seeing similar errors? Is there a problem with my config, or is a bug? Thanks, Lukas

2 2

[arch-general] systemd and pm-utils
by jsteel 28 Jul '12

28 Jul '12

Hi, When using systemd to handle suspend, it doesn't run hooks in /etc/pm/sleep.d/ which work when running "pm-suspend". My hook is called 01custom and is executable. Is it incapable of handing these suspend/resume scripts or does it have its own method? Thanks, jsteel

2 1

[arch-general] [arch-dev-public] [RFC, after the fact] initscripts config
by Yclept Nemo 28 Jul '12

28 Jul '12

3) Personally this depends on the final rc.conf, is [1] or [2] going to be it? I don't enjoy visually collating options across rc.conf (terminal #1,vim) and rc.conf(5) (terminal #2,man). So if after actions (2), and (4), nothing remains but "esoteric" options, then sure, go ahead and do whatever you wish: remove them all or include everything. [1] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=ae28554e56151… [2] http://projects.archlinux.org/initscripts.git/tree/rc.conf?id=5b062674869c9… 4.1) Are we going to ship default (possibly empty) replacement configuration files, which currently may not exist on many systems, and add these to the backup array? This includes (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname). 4.2) To be clear, is there going to be a separate configuration for the HARDWARECLOCK and TIMEZONE variables? >>>d) The new format does not require a bash interpreter to be read 4.d) I think this is a terrible justification. A programming language embedded in a configuration system grants a lot of possibilities. That in and of itself can generate much controversy. On one hand, it might be better to enforce a strict separation between configuration and code, thus requiring the removal of code into wrapper scripts. On the other hand, blurring such a line could while providing extensibility, in certain situations encourage faux-pas configurations better suited to wrapper scripts. Then is the faux-pas inherent to the programming language or the context of the configuration file? In my defense, I refer to [3] which lists many incorrect idioms. Also there is a sound way to read configuration files written in a programming language - simply evaluate the code. In any case, to preserve compatibility with systemd, the new files (/etc/vconsole.conf, /etc/locale.conf, /etc/hostname) should not contain bash. [3] mywiki.wooledge.org/BashFAQ/ 5) With the plethora of changes, each for different reasons, I think there is justifcation for a comprehensive news item summarizing changes to each variable: LOCALE -> /etc/locale.conf HARDWARECLOCK -> deprecated USE_BTRFS -> esoteric, removed for cosmetic reasons etc...

5 4

[arch-general] System hangs at "Booting the kernel" upon drive addition
by pants 28 Jul '12

28 Jul '12

Hello, I have a system which is hanging during boot at the line "Booting the kernel" when I have a drive connected to either port of the PCI-Express SATA card I recently installed (chipset ASM1061). When a drive is not connected to the card, the system boots normally, and connecting the drive to the card after booting leads to no errors or other problems. I am running the latest version of linux and linux-headers in the core repository. It is worth noting that I also have an identical SATA card in the same system with two drives identical to the one in question connected to it. This setup has operated smoothly for about six months. Cheers, pants.

1 0

[arch-general] Joining mp3's --> Floating point exceptionffmpeg
by Nelson Marambio 27 Jul '12

27 Jul '12

Hi, folks, for joining audio dramas (d/l from Amazon) which come along in MP3-Format I use a short script #!/bin/bash mp3wrap tmp.mp3 *.mp3 ffmpeg -i tmp_MP3WRAP.mp3 -acodec copy all.mp3 && rm tmp_MP3WRAP.mp3 It works for half of my books, processing the other half produces this error message: /home/nelson/scripts/mp3_join.sh: line 3: 15295 Floating point exceptionffmpeg -i tmp_MP3WRAP.mp3 -acodec copy all.mp3 As to my knowledge the script worked fine for a few months then, I think after an update of ffmpeg, the trouble shown above began. Are the MP3 files corrupt or is this a bug in ffmpeg. I'd say it is a bug, because running Windows and MP3 Album Maker it still works fine. OK, I could keep Windows for this scenario but I try to get away from this. Does anyone have an advice for me ? Have the suitable parameters for ffmpeg changed ? Or is the ffmpeg-call obsolete meanwhile (it seemed to be necessary for fixing the audio-header concering track length) ? Thanks in advance, Nelson.

4 5