January 2021 - Arch-general - lists.archlinux.org

[arch-general] drill -S . : is core dumping arch specific?
by u34＠net9.ga 18 Apr '21

18 Apr '21

$ drill -S . ;; Number of trusted keys: 2 ;; Chasing: . A drill: ./rdata.c:33: ldns_rdf_get_type: Assertion `rd != NULL' failed. zsh: abort (core dumped) drill -S . Is core dumping arch specific? The above is with ldns 1.7.1-2. To the best of my knowledge, the same command just aborts, without a core dump, with the old Debian ldnsutils 1.7.0-4. -- u34

6 8

[arch-general] [RFC] Potentially deprecating primus, bumblebee, virtualGL and primus_vk
by Emil Velikov 16 Feb '21

16 Feb '21

Hello all, As some of you may know, I have been an Arch user for over 5 years and a Linux graphics developer working on the whole stack from the kernel DRM all the way up-to Mesa and X. I would like to propose, partially deprecating and potentially removing some of the said packages in light of the development that has been happening over the last few years. tl;dr: these solutions have been partially or completely obsolete, for a while now ## OpenGL/GLX/etc # Background As you know, in the early days we would have both Mesa and vendors provide their own libGL.so.1 and in some cases libglx.so (xorg module). Alongside that drivers lacked dynPM, allowing you to powering off the GPU, when it's not used. To address those primus and bumblebee came about. Note: dynPM is mentioned for completeness, it won't be covered any more. # Since then Nvidia and open source drivers support client - Mesa drivers - since v17.2.0 (at least), packaged 7 Sep 2017 - Nvidia drivers - since v390.25 (at least), packaged 29 Jan 2018 ... and server-side glvnd: - xorg-xserver - since v1.20.6, packaged 23 Nov 2019 - Nvidia drivers - since v435.21, packaged 30 Aug 2019 ## Vulkan # Background On the Vulkan side the drivers are clearly separated from the start - libvulkan_$vendor.so. Yet very few applications would bother selecting the GPU, plus server-side (when using WSI_X11) wasn't complete. GL Vulkan interop was also tricky, with libGL.so.1 being provided by vendors. This resulted in primus_vk. # Since then - Mesa drivers - since 20.1.0, packaged 28 May 2020 Driver selection layer was added, falling back to DRI_PRIME [1] - Nvidia drivers - since v390.25 (at least), packaged 29 Jan 2018 Vulkan implicit layer was added - see [2] ## My proposal: Cleanup the packages, as outlined below and update the wiki. Please check out the Extra notes below. I will be more than happy to tackle this although maintainers will have to push/rebuild the packages for obvious reasons. - primus: replace with a simple compat script primusrun, which a) finds the ID_PATH_TAG for the Nvidia GPU and sets DRI_PRIME=$tag $@ - bumblebee: optirun - replace with script calling primusrun xorg config - should not be needed, double-check and drop bumblebeed - (optionally) remove no longer applicable code, config etc bumblebee - remove no longer applicable group - virtual GL: move to AUR, since it has no more users - primus_vk: replace with a simple compat script pvkrun akin to primusrun, making use of [1] and [2] ## Extra notes: - primus/bumblebee - seemingly been abandoned upstream for 4+ years. Arch maintainers having to carry fixes locally. - primus/virtualgl/primus_vk performance is worse than natively - compat primusrun/optirun/pvkrun are to minimise breakage - some legacy Nvidia drivers may lack support - those drivers live in the AUR, thus a solution for them should also be packaged there. ## Feedback I would love to hear the input from the respective maintainers and the overall Arch developer base as a whole. Is there a particular use-case that I've missed? How would you like this handled - as mentioned above, I'm happy to submit patches be that via Flyspray, email, MR or otherwise. Looking forward to your input -Emil [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1766 [2] http://download.nvidia.com/XFree86/Linux-x86_64/435.17/README/primerenderof…

4 28

[arch-general] https://git.archlinux.org/svntogit obsolete?
by Erich Eckner 13 Feb '21

13 Feb '21

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I was surprised to find git.archlinux.org/svntogit/packages.git/ and git.archlinux.org/svntogit/community.git/ being no longer updated since a few days. I know, there was a github mirror of the repositories set up some time ago - did I miss some deprecation notice for the old locations or is this some oversight on the arch end? regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl/ffMIACgkQCu7JB1Xa e1qskg//T0HkTdj33ygNCpDNwvDf2H6V1zOBkjadlHrXph4/WkQIyYa7QJxmWXfV d0CWioelIJM4qkBpXrwTa4xMvowW7HLgvpUnCfnXSSaiCODEbJDXC/b0OokHSS9c K+9rGdMgVwfmsMevc/k919ifzmNIUkmX3tOd4lRc1CO6A2EHxFELndY3MbBhpz12 gP599BPvopC+AlYg0MEu1l0/1wAq5p0zSJvneyh2R8LIo8RW/8N7JWnmt0CJf8sM iNiBHvj7byk1Y8uXghibaN9LqLAtRTodhb++Fm5NKdHmlVAnGxrdA3aKlYJYYXsL Q/OYBSTwuhNvxXJnewLtErWjcVu7IL29gPX2Hh7Yhyf+XHScond/Z6WWza3dBYMx rEC9sknS9aSQeuvJqAyfq0mCDQJxbDFAs2p2zh0LG65pbY04yZstmDo/Al+xZV5D wwqedpiTAUVI23m9IePMfxEUnWuRaF5GYeJIa/EFmYn5OXPWMuUO/Y5p2G54QLvX Zwbxu08NDzf+jznhVw2CiP/V7SDMtdLa0hMblvD63z+ywZql0KGIjhiyA9EtXMZm NGQexY5yHyb2R5gKx8e4a7o8ZRJP/n/85laRj3dBYA1ulr5Sp7FCNdYFOLs9xz64 IygVzAJG6Og4kDD7trPl++OwLzaKZ//Qodm3w/+egG3HY75/KvM= =vYL+ -----END PGP SIGNATURE-----

3 3

[arch-general] CVE-2021-3156 (Heap-Based Buffer Overflow in Sudo)
by Łukasz Michalski 29 Jan '21

29 Jan '21

Hi, Just checked my servers and all were vulnerable: [zork@archdevel ~]$ sudoedit -s '\' `perl -e 'print "A" x 65536'` malloc(): corrupted top size Aborted (core dumped) Updating to the latest version (sudo-1.9.5.p2-1) closed this vulnerability. Maybe this should be posted as arch news message? Regards, Łukasz

5 4

[arch-general] dracut roll-out plan?
by David C. Rankin 28 Jan '21

28 Jan '21

Archdevs, I see dracut is creeping into the system. Which I see as fine, SuSE has used dracut for a couple of years and it has proven to be quite robust. But I do have a question on roll-out and what will be required on the user's part. I have begun seeing, e.g.: New optional dependencies for brltty dracut: for dracut based initramfs support I currently have 3 Arch servers, with one remote administered, so if this will require some type of manual on-site intervention, it would be good to know before hand. -- David C. Rankin, J.D.,P.E.

11 17

Re: [arch-general] [arch-dev-public] Chromium losing Sync support on March 15
by Geo Kozey 27 Jan '21

27 Jan '21

> ---------------------------------------- > From: Levente Polyak via arch-dev-public <arch-dev-public(a)lists.archlinux.org> > Sent: Tue Jan 26 22:18:21 CET 2021 > To: <arch-dev-public(a)lists.archlinux.org> > Cc: Levente Polyak <anthraxx(a)archlinux.org> > Subject: Re: [arch-dev-public] Chromium losing Sync support on March 15 > > > On 1/26/21 9:53 PM, Morten Linderud via arch-dev-public wrote: > > > > It's dissapointing frankly. > > > > Disappointing doesn't really catch it tho. If it would be just about the > sync functionality: so be it. But crippling the API usage on a level > that rips out especially things like the safe browsing functionality as > well places chromium knowingly and forcefully into a position that > doesn't make it viable to be distributed to users. Didn't google already make it clear it's only about sync api and the rest including safe browsing is perfectly fine to use with current keys if you don't remove them[1]? I think some people here overdramatize this situation. Users who depend on sync would have to switch to chrome but for majority nothing will change unless you indeed drop the package which hardly helps to limit damage. [1] https://groups.google.com/a/chromium.org/g/chromium-packagers/c/SG6jnsP4pWM… Yours sincerely G. K.

3 6

Re: [arch-general] [arch-dev-public] Chromium losing Sync support on March 15
by Ondřej Kučera 27 Jan '21

27 Jan '21

Hi, On 26. 01. 21 20:20, Evangelos Foutras via arch-dev-public wrote: > On Fri, 22 Jan 2021 at 10:05, Evangelos Foutras <evangelos(a)foutrelis.com> wrote: >> > Building Chromium without API keys results in a browser that is > unsuitable for production use. Removing the OAuth 2.0 credentials (or > when the Chrome team limits them) mainly breaks Chrome data sync > (e.g.: passwords, bookmarks, open tabs). Additionally removing the > main API key disables functionality like Safe Browsing and > Geolocation. I don't consider a browser with downgraded functionality > and security suitable for end users. [2] I'd like to ask the devs, if they read this, to reconsider. I myself am a Firefox user. However, there are sites/web applications that just don't work in Firefox and probably never will. Some of them I have to use on a daily basis. For example, Microsoft Teams works perfectly fine in Chromium (audio, video, desktop sharing); it doesn't, to my knowledge, in Firefox. Skype works for chatting (unfortunatelly not for audio/video) in Chromium; while this is not perfect, chatting is in 95 % of times what I need. I remember even not being able to finish an order in an e-shop in Firefox once (I can't remember which shop it was) and I suspect this will happen more and more often. Frankly, since Chromium is only my browser for when stuff doesn't work in Firefox, I've never used Sync or geolocation or safe browsing. But it's still very useful to me having Chromium available as a second-choice browser in the repositories. -- Regards, Ondřej Kučera

1 0

[arch-general] pacman's NoUpgrade option does not ignore read-only files
by Marcel Menzel 26 Jan '21

26 Jan '21

Hello list, I can't get pacman to ignore read-only files via the the NoUpgrade and/or the NoExtract config options. I have several Arch Linux LXC (managed via LXD) containers, with several read-only files mapped into those containers for convenience. For example, to have a single resolv.conf for all containers, I configured the following in LXD: devices: resolv_conf: path: /etc/resolv.conf readonly: "true" source: /root/containerfiles/resolv.conf type: disk Now the problem is, when I want to run upgrades in containers, the pacman check for disk space fails with: error: Partition /etc/resolv.conf is mounted read only According to man pacman.conf, setting "etc/resolv.conf" in NoUpgrade should *in theory* get around this problem for my understandings, but it somehow doesn't. Also setting both does not work: NoUpgrade = etc/resolv.conf NoExtract = etc/resolv.conf Am I missing something out here? Is there any way to accomplish what I want or do I really have to work with a pacman hook here which copies the read only mounted file to the original place after a package upgrade? Thanks & kind regards, Marcel Menzel

2 2

[arch-general] Can pam_systemd_home.so functionality be split into a separate package to prevent cluttering the logs?
by David C. Rankin 26 Jan '21

26 Jan '21

Archdevs, Just as postfix is being split to separate non-default backends into separate packages, can pam_systemd_home.so functionality be split out into a separate package. The problems caused by this disabled part of pambase is discussed here: https://bbs.archlinux.org/viewtopic.php?pid=1952091 Even though the service is disabled, it fill the journal with entries every time sudo is invoked. For example, every time sudo is used with journalctl, you get 5-long lines of nonsense: Jan 26 03:17:42 phoinix dbus-daemon[363]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by ':1.19' (uid=0 pid=5293 comm="sudo journalctl --no-pager --full -f ") Jan 26 03:17:42 phoinix dbus-daemon[363]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service not found. Jan 26 03:17:42 phoinix sudo[5293]: pam_systemd_home(sudo:account): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found. Jan 26 03:17:42 phoinix sudo[5293]: david : TTY=pts/0 ; PWD=/home/david ; USER=root ; COMMAND=/usr/bin/journalctl --no-pager --full -f Jan 26 03:17:42 phoinix sudo[5293]: pam_unix(sudo:session): session opened for user root(uid=0) by david(uid=1000) Why not let the very few that will ever want pam_systemd_home install that package and enable the service rather than allowing a disabled server to clutter the logs every time sudo is used and forcing folks that don't want the noise from a disable package to set: NoExtract=usr/lib/security/pam_systemd_home.so just to get rid of the unnecessary messages. https://bugs.archlinux.org/task/65819 is referenced in the discussion. If nothing else, have NoExtract set by default and add a wiki entry about removing NoExtract and reinstalling systemd for the few that want it? -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] On arch-dev-public: Chromium losing Sync support on March 15
by u34＠net9.ga 26 Jan '21

26 Jan '21

There is a heads-up discussion at https://lists.archlinux.org/pipermail/arch-dev-public/2021-January/030260.h… . 1. Is it worth asking help from some free software org, since the problem is shared by other distributions? Perhaps google will agree to work with that org, as a representative of the distributions. Or,that a single distribtion will represent the other? 2. I hardly use chromium. Yet, few gov sites here mandate using it. At rare circumstancess, I have to deal with these gov sites. In short, I hardly knows, and don't care, about its Sync feature. 2.1 Can the package built, and run, without whatever is required for the Sync feature? 2.2 In case you will stop maintaining it and no one adopts it, can you upload it to the AUR, and disown it? -- u34

14 17