- Arch-general - lists.archlinux.org

[arch-general] Change how cross compilers are packaged
by Christer Solskogen 08 Feb '21

08 Feb '21

I've been using the aarch64 cross compiler packages for some time, lately I've also taken a look at how that PKGBUILD looks and how it relates to Cross-compiling tools package guidelines. The situation now is that aarch64-linux-gnu-glibc installs into a sysroot in /usr/aarch64-linux-gnu. Where also aarch64-linux-gnu-binutils installs some files into. This is bad because the sysroot is a directory thats supposed to be reserved for the target system. This is fine on bare-metal systems, but not for linux/mingw targets. What do you think of having /usr/sysroot/$target as sysroots instead for targets that are supposed to be configured that way? Only a small hand full of packages needs to be rewritten (aarch64, mingw-w64 and riscv64) - and I can fix that I (the package maintainers still need to review my changes, as I don't have git access) One other option would be to follow gcc's defaults, which is $prefix/$target/sys-root But before I do that, I'd like some comments if you think this is needed. I don't want to waste time :-) At the same time, I would remove some of the old/deprecated options for binutils, glibc and gcc that are present in the current PKGBUILDs. -- chs

1 0

[arch-general] nsd 4.3.5 broken
by Genes Lists 06 Feb '21

06 Feb '21

Good morning nsd package (4.3.5-1) in testing doesn't start for me. 4.3.4 works but 4.3.5 fails - lacks permission in the working directory. This is what log says: service: Changing to the requested working directory failed: Not a directory service: Failed at step CHDIR spawning /bin/kill: Not a directory service: Control process exited, code=exited, status=200/CHDIR The new service start file has: WorkingDirectory=~ I tried: WorkingDirectory=/etc/nsd but this still fails Thanks.

3 8

[arch-general] DKMS problem with the latest linux-ck kernel
by Randy DuCharme 06 Feb '21

06 Feb '21

Greetings, Seems the latest linux-ck kernel and DKMS don't play well together. The post-install goes something like this: :: Running post-transaction hooks... (1/4) Arming ConditionNeedsUpdate... (2/4) Updating module dependencies... (3/4) Install DKMS modules ==> dkms install --no-depmod -m openrazer-driver -v 2.9.0 -k 5.10.13-3-ck Error! Bad return status for module build on kernel: 5.10.13-3-ck (x86_64) Consult /var/lib/dkms/openrazer-driver/2.9.0/build/make.log for more information. ==> Warning, `dkms install --no-depmod -m openrazer-driver -v 2.9.0 -k 5.10.13-3-ck' returned 10 ==> dkms install --no-depmod -m nvidia -v 390.138 -k 5.10.13-3-ck Error! Bad return status for module build on kernel: 5.10.13-3-ck (x86_64) Consult /var/lib/dkms/nvidia/390.138/build/make.log for more information. ==> Warning, `dkms install --no-depmod -m nvidia -v 390.138 -k 5.10.13-3-ck' returned 10 ==> depmod 5.10.13-3-ck (4/4) Updating linux initcpios... ==> Building image from preset: /etc/mkinitcpio.d/linux-ck.preset: 'default' -> -k /boot/vmlinuz-linux-ck -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-ck.img ==> Starting build: 5.10.13-3-ck -> Running build hook: [base] -> Running build hook: [udev] -> Running build hook: [autodetect] -> Running build hook: [modconf] -> Running build hook: [block] -> Running build hook: [filesystems] -> Running build hook: [keyboard] -> Running build hook: [fsck] ==> ERROR: module not found: `nvidia' ==> ERROR: module not found: `nvidia_modeset' ==> ERROR: module not found: `nvidia_uvm' ==> ERROR: module not found: `nvidia_drm' . . . The pertinent lines in the DKMS logs complain about my GLIBC - mine's at 2.35. CC [M] /var/lib/dkms/nvidia/390.138/build/nvidia/nv-cray.o CC [M] /var/lib/dkms/nvidia/390.138/build/nvidia/nv-dma.o scripts/basic/fixdep: /usr/lib/libc.so.6: version `GLIBC_2.33' not found (required by scripts/basic/fixdep) make[2]: *** [scripts/Makefile.build:279: /var/lib/dkms/nvidia/390.138/build/nvidia/nv-cray.o] Error 1 make[2]: *** Deleting file '/var/lib/dkms/nvidia/390.138/build/nvidia/nv-cray.o' make[2]: *** Waiting for unfinished jobs.... scripts/basic/fixdep: /usr/lib/libc.so.6: version `GLIBC_2.33' not found (required by scripts/basic/fixdep) make[2]: *** [scripts/Makefile.build:279: /var/lib/dkms/nvidia/390.138/build/nvidia/nv-instance.o] Error 1 make[2]: *** Deleting file '/var/lib/dkms/nvidia/390.138/build/nvidia/nv-instance.o' . . . I spent some time scratching around looking for where/how this is configured but so far I haven't figured it out. Can someone point the way? Where is this set? I looked into the kernel fixdep code a little and tried tweaking it some just to see if I could coax it into installing but haven't yet been able to spend a bunch of time on it. Thanks in advance! -- Randall DuCharme (Radio AD5GB) Powered entirely by Open Source software.

2 1

[arch-general] Gcc 10.2.0-5 cannot create executable error on Archlinux testing.
by fredbezies 04 Feb '21

04 Feb '21

Hello. I had a bad surprise this morning when I tried to build dosbox-x-sdl2-git on my freshly updated Archlinux; checking whether the C compiler works... no configure: error: in `/home/fred/dosbox-x-sdl2-git/src/dosbox-x': configure: error: C compiler cannot create executables I tried midnight commander, same error: ==> Starting build()... checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking whether make supports the include directive... yes (GNU style) checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/home/fred/mc/src/mc-4.8.25': configure: error: C compiler cannot create executables See `config.log' for more details I noticed binutils, gcc/gcc-libs and glibc were updated this morning. Downgrading these ones and rebooting gave me a working C compiler back. Bug opened: https://bugs.archlinux.org/task/69530 Thread opened on archlinux forum: https://bbs.archlinux.org/viewtopic.php?pid=1953864 -- Frederic Bezies fredbezies(a)gmail.com

1 0

[arch-general] makepkg default flags
by Christopher W. 02 Feb '21

02 Feb '21

A few months back there was a proposal to edit the default makepkg build flags for improved security: https://lists.archlinux.org/pipermail/arch-dev-public/2020-July/030031.html As far as I can tell, this was never committed. The show-stopper at the time was Clang 11 not being released yet. Now that it's been in the repos for a while, could we revisit this improvement and possibly get a mass rebuild with it applied?

1 0

[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