- Arch-general - lists.archlinux.org

[arch-general] Iptables
by siefke_listen＠web.de 13 Feb '20

13 Feb '20

Hi, I am writing to a script to generate iptables rules. I did this with the documentation in the Arch Linux wiki and would be happy if a few professionals would take a look over the script. Suggestions for improvement, comments would be very helpful. https://github.com/sisihagen/iptables Thank you & Regards Silvio

5 5

[arch-general] "date" C++ library packaging
by Brett Cornwall 13 Feb '20

13 Feb '20

Waybar [1] just had an update where it pulled in a project called "date" [2]. I'm hesitant to package this under the name "date" since GNU coreutils shares a binary with that name. But this isn't a totally obscure library. Should I persuade upstream to change the name? Should I package it under another name? Or should I lay claim to the unused "date" package name and go on with my life? [1] https://www.archlinux.org/packages/community/x86_64/waybar/ [2] https://github.com/HowardHinnant/date

3 2

[arch-general] Status of WPA3
by Bjoern Franke 10 Feb '20

10 Feb '20

Hi, recently AVM provided a beta-Firmware for Fritzboxes which support WPA3. Unfortunately, our wpa_supplicant seems not be capable of WPA3: https://bugs.archlinux.org/task/57413 When setting explicitly WPA3 in NetworkManager, my laptop is unable to connect to my WPA2/WPA3-wifi. I assume it is caused by the missing SAE support, or do I miss something? The assumption is caused by https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/9 Best Regards Bjoern

3 8

[arch-general] Pacman update: new package breaks many dependencies, how to cope
by Jeanette C. 08 Feb '20

08 Feb '20

Hey hey, I just tried to update my system. Admittedly, I probably left it a little too long. Now xorgproto apparently breas a lot of dependencies. This includes dmxproto and xproto, which in turn are required by other packages like libgmx or libxfont. It there an "automated" method of dealing with this kind of dependency breakage? I dare not try this by hand. I don't know how many other packages would be affected by this. Best wishes and many thanks, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * SoundCloud: https://soundcloud.com/jeanette_c * Twitter: https://twitter.com/jeanette_c_s * Audiobombs: https://www.audiobombs.com/users/jeanette_c * GitHub: https://github.com/jeanette-c ... About some useless information, Supposed to fire my imagination <3 (Britney Spears)

2 2

Re: [arch-general] omega won't build
by Jude DaShiell 04 Feb '20

04 Feb '20

Correction, it was the ncurses-5-compat package with the missing gpg key not ncurses-6. I found that out by ignoring all gpg checks and the other thing with pikaur is it didn't keep the gpg key that was unknown on the screen long enough for me to check with gpg2 and possibly import it. --

1 0

[arch-general] omega won't build
by Jude DaShiell 04 Feb '20

04 Feb '20

the reason omega won't build will effect every package that has ncurses 6 as a dependency since the ncurses 6 public gpg key is unknown. I could ignore the key for now, but this isn't the best security practice on my part so I aborted the build for now. --

1 0

[arch-general] sway package systemd service
by Stefan Tatschner 31 Jan '20

31 Jan '20

Hey, the sway package repo includes a systemd service: https://git.archlinux.org/svntogit/community.git/tree/trunk/sway.service?h=… This file is not included in the package though. Is this systemd service ready to use or just an obsolete artifact? Thanks! Stefan

2 1

[arch-general] FS#65265 - community/dolphin-emu 1:5.0.r11530.ea9b96370d-1 conflicts with discord-rpc-api (I don't agree with Scimmia decision)
by Krzysztof Krakowiak 29 Jan '20

29 Jan '20

Hi, I'm Krzysztof Krakowiak (pix3l in archlinux) and I'm new there https://bugs.archlinux.org/task/65265 I'm very dissapointed by Doug Newgard (Scimmia) bug resolution, who simply closed my bug report with excuse "AUR packages are not supported", but the problem is not in the package from 'aur', but from 'community': I've made request to re-open the the bug-report, by he simply ignored that request The problem lies in fact that dolphin-emu package contains files: discord-rpc-api: /usr/include/discord_register.h exists in filesystem (owned by dolphin-emu) discord-rpc-api: /usr/include/discord_rpc.h exists in filesystem (owned by dolphin-emu) They should belong to 'discord-rpc-api' (currently in aur), and there are many packages dependant on it. Even if 'dolphin-emu' maintainer decides that dolphin-emu wil be built using internal copy of 'discord-rpc-api', there's no reason to export/package those header files, because it's for internal use only(compilation time). I don't get reasoning that if something is fucked up in upstream, then it should be fucked up in distro package (because of upstream...) I was active PLD distro developer (evil_core) and we always had high standards and main excuse for pour existence was to fix upstream brakage/incompetence. best regards, Krzysztof Krakowiak (pix3l)

3 3

[arch-general] ssh askpass problem after todays updates to qt 5.14.1
by Genes Lists 27 Jan '20

27 Jan '20

After the recent updates to qt 5.14.1, both ksshaskpass as well as qt4-ssh-askpass (provided by openssh-askpass) programs dump core. Perhaps these need to be recompiled against the newer qt libraries? Wonder if the latter really is qt4 or just needs to be renamed. thanks. gene

2 4

[arch-general] Why "systemd --user" process hanging around after logout?
by David Rosenstrauch 25 Jan '20

25 Jan '20

I've noticed recently that even after I log out of my desktop env (XFCE) there is a process tree left hanging around running "systemd --user" under my user ID (with a bunch of gvfs child processes running under it). I wouldn't normally care about this, but if I then try to power down the machine, that running process seems to block syslog from successfully shutting down, and so the shutdown process waits for an extra minute and a half until it finally kills the process and powers off. If I manually kill the "systemd --user" process tree, I have no such issues and the machine can power down instantly. Anyone have an idea why this is happening / how to fix? Either by forcing "systemd --user" to terminate on logout, or by forcing syslog and/or the shutdown process to not be blocked by systemd? I did some digging on this, and saw some indication that setting "KillUserProcesses=yes" in /etc/systemd/logind.conf would force the systemd process to get shut down. But I tried changing that setting and it didn't make a difference. I also tried setting a script to run at logout in lightdm, but that didn't seem to work either: it did kill the original systemd process tree running gvfs, but then it looks like another one gets spun up to replace it, and I wind up with the same issue. Anyone have any suggestions how to work around this? Thanks, DR

3 3