- Arch-general - lists.archlinux.org

[arch-general] kernel: why is can bus support deactivated?
by Matthias Klein 23 Dec '14

23 Dec '14

Hello, what is the reason that can-bus support is disabled in the arch linux kernel? CONFIG_CAN CONFIG_CAN_PEAK_USB ... Best regards, Matthias

2 2

[arch-general] mutt and gnupg
by Magnus Therning 23 Dec '14

23 Dec '14

It seems a recent upgrade of gnupg (I'm at 2.1.0-6) has degraded my mutt config slightly. I've just compared my gpg-related config of mutt to /usr/share/doc/mutt/samples/gpg.rc and they match. Beyond what's found there I also have the following settings: set crypt_autoencrypt = no set crypt_autosign = yes set crypt_autosmime = no set crypt_replyencrypt = yes set crypt_replysign = yes set crypt_replysignencrypted = yes set crypt_use_gpgme = no set pgp_sign_as = 0xAB4DFBA4 set pgp_use_gpg_agent = yes set smime_is_default = no The behaviour that changed after the recent upgrade of gnupg was that mutt started asking me for a password. Before the upgrade it didn't, it handed over to the gpg-agent right away. My testing suggests that the value of `pgp_use_gpg_agent` has no influence on mutt's behaviour at all any more. However, if I do set `crypt_use_gpgme` mutt hands off to the gpg-agent right away. However, if I set that mutt reports the following when started: Using GPGME backend, although no gpg-agent is running So, is there some way to configure mutt to go straight to the gpg-agent, without any warning messages on startup? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Any fool can write code that a computer can understand. Good programmers write code that humans can understand. -- Martin Fowler

4 7

[arch-general] Multithreaded XZ
by Mark Lee 22 Dec '14

22 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 To All, Now that xz is multithreaded (not available in Arch Repos yet); I was wondering if package building and installing would, by default, utilize multiple threads. Regards, Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlSXgRsACgkQZ/Z80n6+J/Yc6AD+ORs6WkeCmLwlpPEGF/TWGqBX D1YBmbZRocJ8YqtovT8A+wc9spnkCF37mD3WrTRTBs6cCyRDurCpMQX1ZUg87FpQ =sMcR -----END PGP SIGNATURE-----

4 5

[arch-general] dhcpcd not working after install from custom iso
by Christian Demsar 22 Dec '14

22 Dec '14

I had internet connection when installing from an iso I built using the archiso tools, but dhcpcd isn't connecting any more (starting via sytemd). I've also had internet access in previous installs of archlinux and FreeBSD, so I don't think there's anything wrong with the hardware. [dmesg output] http://pastebin.com/vtVRid1Y [ip link output] http://pastebin.com/gaZxUCmf The device I'm using is listed as enp2s0. It hangs, even though it's set up (pastebin for proof). Waiting for carrier? I also noticed that at the bottom of my dmesg, it reports only IPv6, not IPv4. Is this normal behavior? I think my network only supports IPv4, for dhcp anyway. Since I have to register the addresses of the NICs with the ISP, only enp2s0 should hypothetically be able to connect, not enp1s0. This is also the first time I've had a problem with dhcpcd. If it makes a difference, I built a custom iso (base) and dropped the bcache-tools package in /etc so I could set that up. I made no other modifications to the bulid. dhcpcd is at version 6.6.4-1 and is fully up-to-date. == LOG SNIPPET == dhcpcd(a)enp2s0.service - dhcpcd on enp2s0 Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; disabled) Active: failed (Result: exit-code) since Wed 2014-12-17 09:15:46 EST; 51s ago Process: 542 ExecStart=/usr/bin/dhcpcd -q -w %I (code=exited, status=1/FAILURE) Dec 17 09:15:16 vss dhcpcd[542]: version 6.6.4 starting Dec 17 09:15:16 vss dhcpcd[542]: enp2s0: waiting for carrier Dec 17 09:15:46 vss systemd[1]: dhcpcd(a)enp2s0.service: control process exited, code=exited status=1 Dec 17 09:15:46 vss systemd[1]: Failed to start dhcpcd on enp2s0. Dec 17 09:15:46 vss systemd[1]: Unit dhcpcd(a)enp2s0.service entered failed state. Dec 17 09:15:46 vss systemd[1]: dhcpcd(a)enp2s0.service failed. -- vixsomnis

3 3

[arch-general] Booting ArchLinux with `initscripts` is now broken
by Ciprian Dorin Craciun 21 Dec '14

21 Dec '14

Hello all! I'm in a little bit of a pickle, and I would like to ask for some help with my particular setup. I haven't switched to `systemd` and I'm still booting my system with the old `initscripts` `/etc/rc.sysinit` and friends (except this all the packages are up-to-date). Before updating `systemd` from 216 to 217, it still worked. However after upgrading, two things happened: (A) the kernel modules firmware is not loaded any more; (I know that now the kernel automatically loads the firmware, but I'm still on Linux 3.6.11;) (B) `systemd-udevd` seems to get stuck while "doing it's magic" on something like `/sys/.../cpu0`; I've now downgraded to `systemd` 216, and marked it as ignored in `/etc/pacman.conf`, due to the firmware loading. (Issue (B) was solved by just replacing `udevadm settle` with a `sleep 6s`.) However I would be interested if someone has an idea on how to: * fix problem (A) regarding the firmware loading; (I'll have to dig the documentation, but perhaps there is a tool and some `/proc/sys/...` knob I can use...) * find a way in which I can still have my non-systemd setup; (I know about `mdev`, and other `udev` replacements, but I would prefer an `udev`-based solution just to be sure that X, or LVM, etc. don't break;) Thanks in advance, Ciprian. P.S.: Just to be clear, I don't want to start a systemd flame war. My reason for not using it is simple: I already use `runit` and custom scripts for all my services (except `udevd` and `agetty`), and my setup relies on somewhat modified `/etc/rc.d/functions` script for encrypted devices.

3 3

[arch-general] p11-kit
by Ralf Mardorf 20 Dec '14

20 Dec '14

Am I the only one who noticed something "unusal" when running $ grep p11-kit $HOME/.xsession-errors ? I cared about https://www.archlinux.org/news/ca-certificates-update/ .

2 3

[arch-general] systemd upgrade - run mkinitcpio automaitcally
by Troy Engel 19 Dec '14

19 Dec '14

Hiya all, Upgrading this evening we get systemd 218 - I rebooted and happened to notice that the initramfs said "loading systemd 217" and off it went... so I ran mkinitcpio -p linux to rebuild a new one and rebooted into it. I'm OCD like that. Should upgrades to systemd have some sort of post install hook to run mkinitcpio for the new version? Does it matter? Just curious, -te

2 1

[arch-general] Screen recording in gnome is not working
by Marcos Sánchez 19 Dec '14

19 Dec '14

Reposting here in case someone doesn't read the forums. From: https://bbs.archlinux.org/viewtopic.php?id=191231 I'm having trouble running the screen recording feature in gnome. When I press ctrl + alt + shift + r the desktop is not recorded and no file is created. I have installed the following gstreamer packages https://gist.github.com/anonymous/62aa75202f798821ab38. I'm running GNOME Shell 3.14.2 in a fully updated archlinux. Related topic (the solution didn't work for me): https://bbs.archlinux.org/viewtopic.php?id=120134 Any ideas on how to fix the issue? -- # Marcos

1 0

[arch-general] Missing module ag mkinitcpio
by Heiko Becker 19 Dec '14

19 Dec '14

Hey everyone, as pointed out somewhere else on the list, it is necessary to run mkinitcpio after updating to systemd 218. Doin so today gave me the following warning: WARNING: Possibly missing firmware for module: aic94xx Can someone give me a hint where I have to search to fix this? Best, Heiko

3 3

[arch-general] gnupg 2.1 not stable
by Ido Rosen 18 Dec '14

18 Dec '14

>From gnupg.org: "2.0.26 is the stable version suggested for most users, 2.1.1 is the brand-new modern version with support for ECC and many other new features, and 1.4.18 is the classic portable version." The 2.1 series of gnupg is not stable, it still has many major bugs, not the least of which is backwards compatibility with various key sizes previously supported (introduced by the new gpg to gpg-agent IPC layer restrictions). On the gnupg-devel mailing list I've seen a few potentially serious security issues with it. Given that it's not marked as stable upstream, and that it's such a critical core component of Arch's infrastructure, I find it questionable for Arch to have upgraded so soon. In the future, can we avoid upgrading gnupg proper to non-stable releases? Instead, how about creating a gpg21 or gpg-modern package would be appropriate for those wishing to try the unstable version and then updating the gnupg package once that branch gets marked stable?

10 23