- Arch-general - lists.archlinux.org

[arch-general] Compositing broken on laptop, Compton and xcompmgr
by Harley W 14 Mar '16

14 Mar '16

I've been using Compton on my laptop for about a year without any issues. Recently, I noticed that transparency stopped working, and even more recently, shadows stopped working. If I try calling Compton from the command line I get an error saying "Failed to make GLX context current". I tried to use xcompmgr, but shadows and transparency still don't work, though I don't get any error messages. My Compton command is compton -b -z -c -r 32 My xcompmgr command is xcompmgr -r 32 -o 0.75 -l -16 -t -16 -a -c On Compton, I tried multiple backends, none were successful. I am testing this within bspwm, and got the same error on xmonad as well. However, compiz seems to be working perfectly in my xfce sessions. Recently, WiFi broke on my laptop as well, and now I have to run rfkill unblock WiFi when I start my computer. I'm thinking due to the recent onslaught of issues that this may be a hardware problem, but the laptop is only 3 years old. Any idea what's wrong? Thanks, Harley Wiltzer

4 5

[arch-general] mount shows hardcoded stripe=4 mount option for ext* /boot fs
by Bastien Traverse 13 Mar '16

13 Mar '16

I first stumbled upon this two years ago and opened a thread in the forum to ask about it [1]. I never got an answer but lived happy and forgetful about it, until some days ago another user PMed me to know if I had ever found out why mount consistently showed `stripe=4` as a mount option for the `/boot` partition, whether or not we leave it in /etc/fstab of use `defaults`. This piqued my interest again, so I'm submitting it here in hope somebody can enlighten us. Please see the original post for all the details. I can confirm that to this day, `$ mount | grep stripe` still returns /dev/mapper/boot-arch on / type ext4 (rw,stripe=4,data=ordered) but `# journalctl -b | grep stripe` returns kernel: EXT4-fs (dm-$): mounted filesystem with ordered data mode. Opts: (null) Cheers [1] https://bbs.archlinux.org/viewtopic.php?id=176092

3 3

[arch-general] stunnel
by flow 12 Mar '16

12 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * stunnel.service - SSL tunnel for network daemons Loaded: loaded (/usr/lib/systemd/system/stunnel.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) Process: 583 ExecStart=/usr/bin/stunnel (code=exited, status=1/FAILURE) stunnel[583]: [!] /etc/stunnel/stunnel.conf:105: "[zxy]": Failed to initialize SSL systemd[1]: stunnel.service: Control process exited, code=exited status=1 systemd[1]: Failed to start SSL tunnel for network daemons. systemd[1]: stunnel.service: Unit entered failed state. systemd[1]: stunnel.service: Failed with result 'exit-code'. - -- Have a nice day! ~~~ This PGP signature only certifies the sender and date of the message. It implies no approval from the administrators of nym.mixmin.net. Date: Sat Mar 12 18:53:42 2016 GMT From: flow(a)nym.mixmin.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlbkZbYACgkQViYZwngkfDurMQCgjD/uIQx9IRsWB5h7Z5atvpVO amAAnRMwpPg6MEuYLYUBAlbjXqsL8BC7 =hCCW -----END PGP SIGNATURE-----

3 2

[arch-general] anything in release notes cover this?
by Jude DaShiell 11 Mar '16

11 Mar '16

DKMS make.log for rt5592sta_linux_patched-dkms-2.6.0.0 for kernel 4.4.5-1-ARCH (x86_64) Thu Mar 10 23:37:22 EST 2016 make -C tools make[1]: Entering directory '/var/lib/dkms/rt5592sta_linux_patched-dkms/2.6.0.0/build/tools' gcc -g bin2h.c -o bin2h make[1]: Leaving directory '/var/lib/dkms/rt5592sta_linux_patched-dkms/2.6.0.0/build/tools' /var/lib/dkms/rt5592sta_linux_patched-dkms/2.6.0.0/build/tools/bin2h cp -f os/linux/Makefile.6 /var/lib/dkms/rt5592sta_linux_patched-dkms/2.6.0.0/build/os/linux/Makefile make -C /lib/modules/4.4.3-1-ARCH/build SUBDIRS=/var/lib/dkms/rt5592sta_linux_patched-dkms/2.6.0.0/build/os/linux modules make[1]: *** /lib/modules/4.4.3-1-ARCH/build: No such file or directory. Stop. Makefile:357: recipe for target 'LINUX' failed make: *** [LINUX] Error 2 --

2 1

Re: [arch-general] [arch-dev-public] DKMS modules for virtualbox
by Joakim Hernberg 09 Mar '16

09 Mar '16

We could stop splitting kernel headers out of the kernel package? As a user I think it would be ace if we had binary modules for those that want them but I have recently started using dkms modules again, and find it clearly superior for out of tree modules. (I maintain a couple of kernels myself, and for instance creating/updating and building nvidia packages is really somewhat of a pain). Personally I'd like to see the extramodules patching in the kernel buildscripts go away too ;) -- Joakim

3 2

[arch-general] IP of my coworking space blocked in Arch Linux Archive
by Damian Nowak 09 Mar '16

09 Mar '16

Well, where should I report that to get it unblocked? Thanks -Damian Nowak www.virtkick.com

2 1

[arch-general] most efficient way to get linux kernel statistics
by Andre Schmidt 08 Mar '16

08 Mar '16

hello archers, thought i ask here first, before i try some kernel mailing list. i'm writing (for fun) a tiny daemon that sends linux usage (cpu, mem, net, etc.) statistics as efficiently as possible to another machine, repeatedly, to get "live" data. at the moment i'm simply sending /proc files, but they sometimes have too much data. so was wondering if there is a more efficient way to get (only parts of) the data thats available in /proc? for example, /proc/meminfo has all this info: MemTotal: 8051660 kB MemFree: 6046020 kB MemAvailable: 6843080 kB Buffers: 109116 kB Cached: 708336 kB SwapCached: 0 kB Active: 1332416 kB Inactive: 455428 kB Active(anon): 971040 kB Inactive(anon): 22340 kB Active(file): 361376 kB Inactive(file): 433088 kB Unevictable: 16 kB Mlocked: 16 kB SwapTotal: 1048572 kB SwapFree: 1048572 kB Dirty: 16 kB Writeback: 0 kB AnonPages: 970412 kB Mapped: 323384 kB Shmem: 23008 kB Slab: 71760 kB SReclaimable: 44860 kB SUnreclaim: 26900 kB KernelStack: 6544 kB PageTables: 22924 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 5074400 kB Committed_AS: 3487604 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB HardwareCorrupted: 0 kB AnonHugePages: 413696 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 168600 kB DirectMap2M: 8091648 kB but i only need: MemTotal: 8051660 kB MemAvailable: 6843080 kB Cached: 708336 kB event better would be if kernel would only tell me: 8051660 6843080 708336 if /proc is the only way to get this info, i wonder if creating a kernel module for this would be more efficient, or even possible? Cheers Andre Schmidt

4 8

Re: [arch-general] Missing Dependency virtualbox-host-dkms
by Jack O'Connor 07 Mar '16

07 Mar '16

> I didn't force the deps to linux-headers because you could use the kernel > (linux, linux-lts, linux-zen, linux-grsec, etc) you prefer (or all together). > I will add a message with the next release of virtualbox. Would it be possible to depend on a "Provides" that all the different kernel header packages share? Similar to how nvidia-libgl, catalyst-libgl, and mesa-libgl all provide the "libgl" dependency. That would solve the presumably-very-common case where users initially installed virtualbox without any host headers at all, and are now landing in a broken state by default. (Or would that mean that the different header packages conflict where they didn't before?) - Jack

2 2

[arch-general] dkms remove
by Ralf Mardorf 07 Mar '16

07 Mar '16

When upgrading [root@archlinux rocketmouse]# grep 5.0.14-4 /var/log/pacman.log [2016-03-07 10:48] [ALPM] upgraded virtualbox-host-dkms (5.0.14-1 -> 5.0.14-4) [2016-03-07 10:49] [ALPM] upgraded virtualbox (5.0.14-1 -> 5.0.14-4) automatically the modules for all installed kernels were build. [root@archlinux rocketmouse]# pacman -Q linux linux-rt linux-rt-lts linux 4.4.3-1 linux-rt 4.0.4_rt1-1 linux-rt-lts 3.10.61_rt65-1 [root@archlinux rocketmouse]# ls -Ggh /var/lib/dkms/vboxhost/ total 8.0K drwxr-xr-x 5 4.0K Mar 7 10:47 5.0.14 drwxr-xr-x 5 4.0K Mar 7 10:53 5.0.14_OSE lrwxrwxrwx 1 35 Jan 27 12:22 kernel-3.10.61-rt65-1-rt-lts-x66_64 -> 5.0.14/3.10.61-rt65-1-rt-lts/x66_64 lrwxrwxrwx 1 39 Mar 7 10:50 kernel-3.10.61-rt65-1-rt-lts-x86_64 -> 5.0.14_OSE/3.10.61-rt65-1-rt-lts/x86_64 lrwxrwxrwx 1 32 Mar 7 10:52 kernel-4.0.4-rt1-1-rt-x86_64 -> 5.0.14_OSE/4.0.4-rt1-1-rt/x86_64 lrwxrwxrwx 1 26 Jan 27 12:19 kernel-4.3.3-3-ARCH-x86_64 -> 5.0.14/4.3.3-3-ARCH/x86_64 lrwxrwxrwx 1 26 Feb 3 08:08 kernel-4.4.1-1-ARCH-x86_64 -> 5.0.14/4.4.1-1-ARCH/x86_64 lrwxrwxrwx 1 30 Mar 7 10:53 kernel-4.4.3-1-ARCH-x86_64 -> 5.0.14_OSE/4.4.3-1-ARCH/x86_64 however, I want to get rid of the unneeded modules in /lib/modules and I want to get rid of the dkms directory and links that belong to 5.0.14. I expected that 'dkms remove -m vboxhost -v 5.0.14 --all' would remove all 5.0.14 modules. IIRC it worked _after_ an upgrade, when I removed modules in the past. I can't remember that I removed old modules _before_ I upgraded. [root@archlinux rocketmouse]# dkms remove -m vboxhost -v 5.0.14 --all Error! Could not locate dkms.conf file. File: does not exist. Sure, the new config is available, just the old isn't. [root@archlinux rocketmouse]# ls -Ggh /usr/src/vboxhost*/dkms.conf -rw-r--r-- 1 1.1K Mar 4 22:50 /usr/src/vboxhost-5.0.14_OSE/dkms.conf Am I mistaken, is there the need to remove old modules before upgrading when using 'dkms remove' or did something change and it was possible in the past? https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support#Remove_m… only mentions that after removing the package 'dkms' the required information to remove kernel modules gets lost. If I use the browser's find option to search "remove", I don't find information about removing old modules using 'dkms remove' here: https://wiki.archlinux.org/index.php/VirtualBox I'm aware the 'rm -r' and 'unlink' could be used either, it's just a surprise that 'dkms remove' doesn't work. Perhaps I'm mistaken and I used 'dkms remove' in the past before I upgraded. Regards, Ralf

1 0

[arch-general] JasPer vulnerabilities
by Harrison Wells 07 Mar '16

07 Mar '16

Is the package JasPer in extra repo vulnerable to CVE-2016-1577, CVE-2016-2089 and CVE-2016-2116? I noticed that the version number of JasPer is same in Debian, Ubuntu and Arch, i.e. 1.900.1. Debian and Ubuntu seem to have updated/patched it, is Arch not vulnerable to it? With regards, Harrison Wells

3 4