- Arch-general - lists.archlinux.org

[arch-general] pavucontrol doesn't find pulseaudio
by Peter Nabbefeld 20 Feb '17

20 Feb '17

Hello, I've tried to use Cadence to set up Pulseaudio with Jack, but it left my sound configuration even more corrupted. Now, after starting pulseaudio, even pavucontrol cannot find it. This is how I've started pulseaudio: $ pulseaudio --start -vv D: [pulseaudio] conf-parser.c: Parsing configuration file '/etc/pulse/client.conf' D: [pulseaudio] conf-parser.c: /etc/pulse/client.conf.d does not exist, ignoring. I: [pulseaudio] main.c: Daemon startup successful. So I'd expect everything should be okay - can someone tell me what to check? Kind regards Peter

1 2

[arch-general] Leftover kde4 stuff
by Oon-Ee Ng 18 Feb '17

18 Feb '17

I just hit a bug with okular (rarely used it and just got surprised by this) https://bugs.archlinux.org/task/53003 After more investigation I realized the kactivites was being provided by kactivities4 (which no longer exists). Further investigation showed that I had a bunch of old kde4 packages (some still in repos, some not) installed. I think this is the list:- kdebase-runtime (16.12.2-1) libkscreen4 (1.0.5-2) qjson (0.9.0-1) libkexiv2_4 (15.08.3-2) kdelibs (4.14.29-1) qca-qt4 (2.1.3-1) polkit-qt4 (0.112.0+git20160226-1) phonon-qt4 (4.9.1-1) phonon-qt4-vlc (0.9.0-1) libqzeitgeist (0.8.0-6) libdbusmenu-qt4 (0.9.3+16.04.20160218-1) attica-qt4 (0.4.2-3) Only libkscreen4 and libkexiv2_4 were no longer in repos, and uninstalling both removed the rest. Did I miss an announcement or anything where I'd have noted these packages disappearance and uninstalled them? Or should I be keeping an eye on pacman -Qm (I have 137 packages there at this point)?

3 2

[arch-general] What's with Ray Rashif?
by sekret＠posteo.se 17 Feb '17

17 Feb '17

Hey guys! I'm not writing this mail to complain, I'm just wondering! I use ardour quite a lot and of course I wanted the update to version 5 as soon as possible. The first release 5.0 didn't build here, so I thought ok, maybe the maintainer of this package is struggling with it too. The current version is 5.3 which compiles and runs just fine. So now I wonder why we don't get an update. So I looked at the other packages of the maintainer, see this link https://www.archlinux.org/packages/?packager=schiv and well, I see a lot of red there! So I must wonder: Is Ray still active? Best sekret

11 26

[arch-general] syslinux.cfg
by Ralf Mardorf 17 Feb '17

17 Feb '17

Hi, is the no way to get a menu Arch kernel 1 Arch Kernel 2 Foo Kernel 1 Foo Kernel 2 when using syslinux? Or even while booting another Linux requires chainloading, there's a feature to chose between all available kernels of another Linux by the "main" menu? IIUC chainloading only could provide Arch kernel 1 Arch Kernel 2 Foo and just when selecting Foo I can chose between Foo Kernel 1 Foo Kernel 2 and perhaps Arch so assuming I then decide to go back to the Arch menu, I need to chainload Arch from the chainloaded other Foo Linux? Regards, Ralf

3 5

[arch-general] Hibernation not working
by Peter Nabbefeld 14 Feb '17

14 Feb '17

Hello, since some time, hibernation does not work, dmesg contains following messages: [ 738.404244] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160422/nsarguments-95) [ 738.404353] ACPI: \_SB_.PCI0.PEG0.PEGP: failed to evaluate _DSM [ 738.404356] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20160422/nsarguments-95) Some time ago, when I closed my laptop, Linux automatically hibernated, now it does not. As my laptop becomes really warm and I don't want to stress my display, I'm using this rarely, so I cannot tell, since when hibernation doesn't work :-/ Kind regartds Peter

6 9

[arch-general] Revisiting the SELinux/audit question: Disabling audit on the kernel command line
by Tobias Markus 13 Feb '17

13 Feb '17

Hi, As some of you might know, the question of enabling SELinux support in the official Arch Linux kernel package has been brought up a number of times. The main issue that has been pointed out the previous time was that enabling SELinux depends on CONFIG_AUDIT which is considered unnecessary or even harmful for most desktop users since it generates a flood of kernel log messages. Citing Thomas Bächler's previous post (in 2014) on the matter [1]: > And here is my problem: Audit is enabled by default and must be > explicitly disabled by the admin. This is a showstopper for me! There > is no kernel option to configure audit to be disabled by default (as > far as I am aware) so that it can be enabled with 'audit=1' on the > command line. Actually, I think there is a perfectly valid and simple way to disable audit by default: By using the built-in kernel command line. This makes it possible to specify a number of kernel parameters at build time that the kernel prepends to the usual command line it gets from the bootloader. By specifying CONFIG_CMDLINE_BOOL=y CONFIG_CMDLINE="audit=0" in the configuration [2], the audit subsystem is disabled by default, but users intending to use it can do so by manually setting audit=1 on the bootloader's command line. That in turn would override the audit=0 specified on the built-in command line. I would be glad if Arch Linux's official kernel could support SELinux again this way! Thanks for your comments, Tobias [1] https://lists.archlinux.org/pipermail/arch-general/2014-March/03567 9.html [2] For menuconfig, look at the very end under "Processor type and features"

7 9

[arch-general] Bash broken: no PATH and completion
by Giovanni Santini 10 Feb '17

10 Feb '17

Good morning, I want to share one of my recent issues with bash. Everything was working nicely up to some time ago, but recently I'm having some issues. The major two things I've noticed are the following: 1. bash doesn't load */etc/profile*, thus not loading all the scripts in */etc/profile.d/* 2. bash-completion does not load properly all completion; for example, the completion for *optirun* is present but it is not loaded. Does anybody else have issues with it lately? I didn't notice info about bash config changes. -- Giovanni Santini My blog: http://giovannisantini.tk My code: https://git{hub,lab}.com/ItachiSan My GPG: 2FADEBF5

2 1

[arch-general] user namespaces
by sivmu 06 Feb '17

06 Feb '17

Summary: Arch Linux is one of the few, if not the only distribution that still disables or restricts the use of unprivileged user namespaces, a feature that is used by many applications and containers to provide secure sandboxing. There have been request to turn this feature on since Linux 3.13 (in 2013) but they are still being denied. While there may have been some reason for doing so a few year ago, leading to many distributions like Debian and Red Hat to restrict its use to privileged users via a kernel patch (they never disabled it completely), today arch seems to be the only distribution to block this feature. Even conservative distros like Debian 8 and 9 have this feature fully enabled. I would like to suggest that arch stops to disable this feature in future kernel versions. Resoning: The original reason to block user namespaces were a number of security issues that allowed unprivileged users to access features they should not have access to. Due to the nature of user namespaces to provide isolated user environments with access to privileged features like other namespaces (inside that isolated namespace only), it should be obvious that this feature had to be designed carefully in order not to harm the security outside the namespace. Even though there have been issues, this feature is now considered stable enough for distros like debian and red hat to allow its use even for unprivileged users. Moreover there are many applications that use this feature to provide or enhance security Among them are: lxc, systemd-nspawn, docker, flatpak, bubblewrap, firejail, firefox, chromium After working with sandboxing applications for several month, it seems clear to me that disabling user namespaces decreases the security of the system significantly. Some of these applications can not provide core features due to user namespaces missing. Others have significant security features disabled for this reasons. But the worst part is how some of these projects dealt with the missing feature: Many are using suid bits to execute the application as root to get access to the features they would have inside a user namespace. And for those who have worked with suid applications and their security it will not be surprising that they have failed to do this securely, leading to not just a few local root exploits. Taking firejail just as an example: (CVE-2017-5207) (CVE-2017-5206) (CVE-2017-5180) (CVE-2016-10122) (CVE-2016-10118) (CVE-2016-9016) And that is just from the last release... non of these issues would have been possible if user namespaces could be used, which is btw. what bubblewrap does if the feature is available, but since it isn’t on arch they have to use suid too (but bubblewrap is designed with security in mind for a change, so no known issues so far) Chromium is another case that has to use suid to use its sandbox and while I consider the developers very skilled in regards to security (they build a very nice broker architecture sandbox on windows too) there have been local root exploits in the linux version of chromium because of this. Even while looking at the surface of this problem it becomes clear this causes way more problems then it solves. Considering arch will be or already is the only linux distribution to disable this feature, developers of future applications will have to chose between dropping support for arch or to keep using features like suid that pose a real security threat opposite to user namespaces. Therefore I urge the people responsible to reconsider their choice an enable user namespaces in future kernel versions of arch linux. Bug reports regarding user namespaces: https://bugs.archlinux.org/task/36969 https://bugs.archlinux.org/task/49337

12 36

[arch-general] OpenJFX package out-of-date
by Kyle Laker 06 Feb '17

06 Feb '17

Hello, The extra/java-openjfx package has been flagged out-of-date since 2016-09-13 and is stuck at verison 8u76-b03. This can result in runtime warnings for some JavaFX applications whose FXML was created specifying a newer API version, potentially causing confusion for users because `java -version` would return the newest version (1.8.0_121). The following patch (created using `svn diff`) of the PKGBUILD should bring it up to match the latest version of extra/jdk8-openjdk. No changes should be necessary for the gradle.properties file. Regards, Kyle Patch: Index: PKGBUILD =================================================================== --- PKGBUILD (revision 287772) +++ PKGBUILD (working copy) @@ -12,11 +12,11 @@ pkgbase=java-${_libname} pkgname=('java-openjfx' 'java-openjfx-doc' 'java-openjfx-src') _java_ver=8 -_jdk_update=76 -_jdk_build=03 +_jdk_update=121 +_jdk_build=13 _hgtag=${_java_ver}u${_jdk_update}-b${_jdk_build} pkgver=${_java_ver}.u${_jdk_update} -pkgrel=2 +pkgrel=1 pkgdesc='Java OpenJFX 8 client application platform (open-source implementation of JavaFX)' arch=('i686' 'x86_64') url='https://wiki.openjdk.java.net/display/OpenJFX/Main'

2 3

[arch-general] Generating gdb debug logs for devs
by Pekka Järvinen 03 Feb '17

03 Feb '17

Hi, I have segfaulting lxrandr and I was referred to https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces after filing bug report. I've installed ABS, modified PKGBUILD and made my own /etc/makepkg-dev.conf makepkg -sf --config /etc/makepkg-dev.conf generates the executable. Still gdb gives very little info after running cd lxrandr/pkg/lxrandr/usr/bin gdb -ex "set logging file debug.log" -ex "set logging overwrite on" -ex "thread apply all bt full" -ex "set logging on" -ex "run" -ex "backtrace" -ex "frame 0" -ex "kill" -ex "quit" ./lxrandr I'm guessing because I need to add debugging to libraries which lxrandr is using too. In the wiki there's --- snip --- Note: It is insufficient to simply install the newly compiled debug package, because the debugger will check that the file containing the debug symbols is from the same build as the associated library and executable. You must install both of the recompiled packages. In Arch, the debug symbols files are installed under /usr/lib/debug. See the GDB documentation for more information about debug packages. --- snip --- But as a non c/c++ dev this doesn't say anything. What do I need to install/run and where? So could the wiki page be enhanced by adding concrete example(s)? Original bug report: https://bugs.archlinux.org/task/51480 -- Pekka Järvinen

5 11