- Arch-general - lists.archlinux.org

[arch-general] [pacman] unknown-horizons / dependencies
by Peter Nabbefeld 03 Feb '16

03 Feb '16

Hi, as far as I understood, there's a conflict between "unknown-horizons" and current version of fife. However, the game refuses to start, so I want to re-install it, respectively replace it by the git version. Using "pacman -Rssd" (also using only one "s"), optional dependencies of other packages are removed, too (e.g. "boost" for "ogre"), but without any "s", no dependencies are removed. 1. As I don't remember, which package has installed "ogre" probably as a dependency, I'd like to know that. Using "-Qo" it seems only to be possible to get the owners of files - how can I view the "parent" or "owner package" of a package? 2. How can I exclude optional dependencies from removal? Kind regards Peter

2 1

[arch-general] pacman and hooks
by Magnus Therning 03 Feb '16

03 Feb '16

I just noticed an email in this list mentioning that with pacman 5.0 we know have support for hooks. I proceeded to look at the man pages for /pacman/, /makepkg/, and /PKGBUILD/ but only found one mention of a /hookdir/. Is there more information about this feature available somewhere? /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Do not meddle in the affairs of Wizards, for they are subtle and quick to anger. -- J.R.R Tolkien

6 12

[arch-general] systemd user accounts are created in a inconsistent way
by Daniel Milewski 02 Feb '16

02 Feb '16

Most systemd user accounts are present in the /etc/passwd file provided by the filesystem package. This is not the case for only two of them, namely systemd-journal-upload and systemd-journal-remote, which are set up by systemd-sysusers, executed when the systemd package is installed. Is there a reason for that? Wouldn't it be better to include all systemd users in /etc/passwd, or let systemd-sysusers handle account creation? -- Daniel Milewski GPG key ID: 8D43A4A1

3 2

[arch-general] Why does a regular user have access to /dev/uinput (and why only temporary)
by Manuel Reimer 02 Feb '16

02 Feb '16

Hello, I'm currently developing a usermode input driver using uinput. While doing this, I've found some "ugly" behaviour. If I do getfacl from my regular user, I get: $ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:manuel:rw- group::--- mask::rw- other::--- So for whatever reason my user is able to launch a usermode input driver. No root permission needed. But in fact the driver isn't even loaded (no uinput module). But it is loaded as soon as I try to access the device. After that, I have: $ getfacl /dev/uinput getfacl: Removing leading '/' from absolute path names # file: dev/uinput # owner: root # group: root user::rw- user:manuel:rw- #effective:--- group::--- mask::--- other::--- So somehow the permission is still there, but no longer effective??? If I switch VT once (and probably switching the active session this way) I have permission again and now my user keeps it. What is causing this ugly behaviour? Why does a user have to have uinput permissions at all? The (possible security) problem with this is, that the driver (may be a simulated keyboard driver) keeps active even if the session changes. So a software, launched in one session, affects another session. Thanks in advance Manuel

2 2

[arch-general] btrfs/snapper hook for pacman 5.0?
by Karol Babioch 02 Feb '16

02 Feb '16

Hi all, now with hooks newly introduced to pacman, are there already some useful btrfs and/or snapper hooks available? At least a quick look-around in the forums and with Google hasn't revealed anything yet. Maybe I'm getting something wrong here, but in my understanding it should be doable and probably is even a cool feature that other distros / package managers already provide. Basically all we have to do is to create a snapshot before and after each pacman invocation. However, after having a look at the alpm-hooks(5) man page I'm not too sure what kind of trigger would make the most sense here. With the "recommended" btrfs / snapper subvolume layout, one could add triggers for paths that should be backed up (e.g. /, /var/, etc.). On the other hand the man page tells us that using the root directory as trigger path is not recommended. So has anyone already looked into this and has some thoughts on this? Best regards, Karol Babioch

6 13

[arch-general] Instructions to mount efivars as readonly should be linked to in Beginner's Guide
by Jayesh Badwaik 02 Feb '16

02 Feb '16

Hi, I have read the dangers of mounting efivars as writable recently, and I think there should be an entry in the archlinux installation guide and beginner's guide which should say exactly what is said in the warning in [1], and then link to [1] for further instructions. -- Cheers Jayesh Badwaik [1] https://wiki.archlinux.org/index.php/ Unified_Extensible_Firmware_Interface#Mount_efivarfs

9 11

[arch-general] opinion request about Firefox add-ons
by Francis Gerund 01 Feb '16

01 Feb '16

Hi. Firefox 44.0 does not seem to allow installing the firefox-adblock-plus addon package from the Arch community repository. Instead, Firefox states that it only allows addons "signed" by Mozilla to be installed. That seems to exclude the package mentioned. I could install the adblock-plus addon version available from Mozilla, directly through Firefox. But is this okay, or a bad idea, or is there a better idea? Any opinions?

9 15

[arch-general] Chromium Favorites Bar Partially Inoperative
by Dutch Ingraham 01 Feb '16

01 Feb '16

Hello all: I just installed Chromium, v. 48.0.2564.97, two days ago. I imported my bookmarks from Firefox and enabled the bookmarks bar. I added a few new bookmarks to the bar, but not in my existing folders. Today, I tried to drag-and-drop the bookmarks into the folders on my bookmarks bar, but nothing happened - the bookmarks just remained on the bar. In addition, it seems impossible to move anything on the bar, i.e., adjusting the order of folders or bookmarks. Everything just stays where it was originally placed. For those who don't use Chromium, this is not normal behavior - one should be able to drag-and-drop into folders, subfolders, and slide things around at will. In fact, even in the bookmark manager it is not possible to drag-and-drop; the only way I've found to move a bookmark into a folder is to copy and paste it there, then delete the original. I've tried disabling my two extensions without luck, and I see no recent activity on the boards or on Chromium's bug tracker. Anyone else seeing this? Any suggestions?

3 4

[arch-general] FireFox 44 turning the bookmark toolbar+ extensions area + current tab into light gray (like selected) [gist image]
by Javier Vasquez 31 Jan '16

31 Jan '16

Hi, Just updated Arch, and got FF 44, but there's a new color behavior on the bookmark toolbar, the extensions area, and current tab. It looks like if everything was somehow selected, light grayed. This is new, but I don't know if it's the new 44+ expected behavior, or something that got broken, and perhaps there's a way to work it around. The gist linked image provides a snapshot of the new weird behavior: https://gist.github.com/je-vv/7a00601e9217cd9d3447 Thanks, -- Javier

3 4

Re: [arch-general] [arch-security] [Announcement] Discussion about restricting arch-security for public participation
by Elmar Stellnberger 30 Jan '16

30 Jan '16

Am 2016-01-30 um 20:37 schrieb Emil Lundberg: > > Getting posts about imminent and potential security risks from many > different sides is f.i. something I still estimate about the Debian > security list very much. > > > I think the word you're looking for instead of "estimate" is > "appreciate". I suspect these two words translate to the same word in > your native language (German?), as they do in mine (Swedish). :) > > /Emil Actually, yes; that is to say. Elmar

1 0