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

English language differences
by Polarian 23 Jan '23

23 Jan '23

Hello, So today I have been working on a new ArchWiki page and I have realised that I have never considered the differences in English language when writing the pages. I assume I am meant to stick to US English, but being a Brit we spell things slightly differently, and as it is habit I am not sure what I am meant to do. What is the conventions when it comes to the spellings you use within the ArchWiki pages, and if I accidentally spelt something "non-US English", would it matter too much? Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

5 9

Linux kernel: delay before power-off
by Markus Schaaf 23 Jan '23

23 Jan '23

Hi all, for a long time now, I'm seeing unclean shutdowns of SATA drives on different machines running Arch. There is a nice write-up about the problem here: https://lore.kernel.org/lkml/20170410232118.GA4816@khazad-dum.debian.net/ If you are willing to google with the right keywords, you will find a lot of similar reports all over the interwebs. I can remember a configuration setting for the Linux kernel, which existed in ancient times, to delay the final step of powering off the machine for some time. Is there anything like that in the distributed kernels right now? Any knob I could turn? BR

9 23

new AUR tool - DNSSEC made easy!
by Genes Lists 22 Jan '23

22 Jan '23

I just uploaded my dns_tools to the AUR [1] and source to github [2]. DNSSEC can be a little tricky to manage but it adds a nice layer of protection for the dns zones for your domain(s). The tool creates and updates keys, signs zonefiles and makes key rolling as automated and simple as possible. There's a reasonably complete README file on github for those who may be interested. Thanks to all the folks contributing and keeping Arch rolling!! regards, gene [1] https://aur.archlinux.org/packages/dns_tools [2] https://github.com/gene-git/dns_tools

1 0

About the wiki's CAPTCHA system
by me＠foxt.dev 21 Jan '23

21 Jan '23

Hi all, (apologies if this is not the correct place to post this -- i didn't see anywhere more appropriate) I recently tried to sign up to the Arch wiki, but I was met by the following CAPTCHA. What is the output of: pacman -V|base32|head -1 and I had some issues with this that I'd like to share, while I get the reasons this captcha system was put in place (to prevent spam & to ensure the user is currently using an Arch system), however I don't believe the current captcha is a good solution. First of all, my problem is with the requirement to verify the user is currently using Arch, as the Arch Wiki is a very popular resource in the greater Linux community as a lot of resources apply to software that is commonly seen on other distributions, for example, I wanted to make a change (which I encountered configuring an Arch system) that was useful to everyone who used systemd, anyone, be it an Ubuntu, Debian, Fedora, etc user may have found on the Arch wiki. While I think (I'm not sure, anyone is welcome to prove me wrong), the little number of users trying to post good faith, however, off topic, non-Arch related content, should be stopped by having their changes undone, and people who are Arch Linux users may still fail the challenge (i.e. using a non-arch system at the time, using an Arch system with an different version of Pacman.) However, my second larger problem is that it doesn't seem that it'd be a very good spam prevention mechanism. The CAPTCHA seems to be the same for all users, and changes very infrequently. (pacman version 6.0.1 (according to https://archlinux.org/pacman/#_releases, released in September 2021) and 6.0.2 (according to https://archlinux.org/packages/core/x86_64/pacman/, released in November 2022) were released over a year apart, so any spammer could define the captcha challenge for the Arch Wiki and post spam for many months. Determined spammers could even write a system to run the command inside a Arch Linux container and cache it until the challenge does not work. Ideally, CAPTCHA systems should be - hard for computers - easy for humans - accessible - unique for every request. The current CAPTCHA system fails every one of those requirements, I'd suggest either using a more common captcha type (such as Google reCAPTCHA, hCaptcha or a generic maths challenge), switching to more human friendly, easily Googleable, but still domain specific questions (i.e. "in which year was the Arch Linux project founded"), less ideal, but you could use commands that always produce the same output (i.e. "uname | base64" should always produce "TGludXgK" on Linux) Thank you.

4 4

Re: RFC: Increase _FORTIFY_SOURCE level to 3
by Genes Lists 19 Jan '23

19 Jan '23

Follow up to my previous note It looks fairly straightforward to identify which applications need to remain on level 2 by checking binaries for those using the malloc_usable_size() call. e.g. $ nm -uD /usr/lib/systemd/systemd-networkd |grep malloc_usable U malloc_usable_size(a)GLIBC_2.2.5 gene

1 0

Fwd: RFC: Increase _FORTIFY_SOURCE level to 3
by Genes Lists 19 Jan '23

19 Jan '23

On 1/18/23 19:31, Levente Polyak wrote: > A new RFC (request for comment) has been opened here: > > https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/17 > > Please visit the above link for discussion. > > Summary: > > Adjust packaging CFLAGS from -D_FORTIFY_SOURCE=2 to -D_FORTIFY_SOURCE=3 > for better fortification coverage Hi Levente - I'm not permissioned on arch-dev list or gitlab so replying direct + arch-general - hope that's okay. You are likely already aware, but sharing as saw no mention about this in the rfc discussion. There aare these comments from Fedora / Redhat regarding level 3 and systemd not working with it which looks relevant [1] [2] "There are packages (e.g. systemd) that do not interact well with _FORTIFY_SOURCE and will also need a workaround to downgrade fortification to level 2. " and in detail: "_FORTIFY_SOURCE=3 revealed another pattern. Applications such as systemd used malloc_usable_size to determine available space in objects and then used the residual space. The glibc manual discourages this type of usage, dictating that malloc_usable_size is for diagnostic purposes only. But applications use the function as a hack to avoid reallocating buffers when there is space in the underlying malloc chunk. The implementation of malloc_usable_size needs to be fixed to return the allocated object size instead of the chunk size in non-diagnostic use. Alternatively, another solution is to deprecate the function. But that is a topic for discussion by the glibc community." regards gene [1] https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distributi… [2] https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-le…

1 0

Weird Firefox & Thunderbird Context Menu/Right Click Bug
by NicoHood 17 Jan '23

17 Jan '23

Hey guys, I dont know where to report this, as it could be related to firefox, thunderbird or gnome (or any other desktop related software). In the last 1-2 Weeks (I dont update that often) I noticed that after some time (have not found a reproducible reason) right clicks, or context menus in genral in Firefox stop working at all. The menu pops up for a few milliseconds and then disappear. When you restart firefox everything works again. I noticed the same isse in thunderbird too, which is also by mozilla. I did not notice it in any other application. I am using gnome as Desktop environment. Do you have the same issue? Any hint if this is a gnome, firefox or other issue? Cheers Nico

10 12

Obfuscation of emails
by Polarian 15 Jan '23

15 Jan '23

Hello, This point is highly controversial within the Arch community, I have seen a lot of people argue either side, but I want to share my opinion on this. Personally I think obfuscation of emails is a complete waste of time, and I am going to explain why. So lets take my email as an example, polarian(a)polarian.dev, people often always obfuscate in the same way: <polarian at polarian dot dev> now what stops a bot from substituting "at" with "@" and "dot" with ".", it is not hard to do, and quite frankly it is a pain to deobfuscate peoples emails within PKGBUILD files when you need to email them to report issues, or get into contact. I have read a lot of pages on the ArchWiki and they all promote obfuscation of emails, have seen discussions on discussing the pros and cons, and not saying obfuscation has no downsides, but none of the discussions amounted to anything. Can we please stop advertising obfuscation of emails, it is counter-productive, we have anti-spam measures, and bots can easily bypass the obfuscation unless you make it more sophisticated, but at that point people won't be able to understand the email and you will be uncontactable. All obfuscation does in my experience, is make it 100x harder for people to report issues, its counter productive in a lot of cases but yet Arch community still advertises. It is up to you personally if you want to obfuscate your email address in PKGBUILDs and other files, but PLEASE can we stop advertising it as a perfect solution to spam, because in many cases, it doesn't even protect you from spam, just is a hindrance for people who genuinely want to contact you. Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

14 40

Re: ROCm in [community]
by Sefa Eyeoglu 11 Jan '23

11 Jan '23

Hi Torsten, thanks a lot for your work! I am here to ask if it's planned to create a group for these packages. That would make it a lot easier to install all of the (currently available) toolchain at once. Best, Sefa On Fri, 2022-12-23 at 16:20 +0100, Torsten Keßler wrote: > Hi all! > > I'm excited to announce that basic ROCm support was added to > [community-testing] yesterday! > > What is ROCm? > ROCm is AMD's open source framework for GPU programming. It comprises > an > OpenCL implementation, HIP (AMD's CUDA) and OpenMP offloading. > > Which GPUs are supported? > Official support is limited, see [1]. > > Which parts were added to [community-testing]? > The low level components (rocminfo, rocm-smi-lib), the OpenCL runtime > (rocm-opencl-runtime) and the HIP runtime / compiler (hip-runtime- > amd). > > How can I use it? > Install (hip-runtime-amd rocm-smi-lib rocm-opencl-runtime) to use all > currently available packages. First check if the amdgpu kernel module > is > loaded and add your login user to the video and render groups. Run > /opt/rocm/bin/rocminfo to validate that the HSA runtime correctly > detects your hardware. You can also check the output of clinfo for > OpenCL support. > > Use case: blender > First, install hip-runtime-amd and add /opt/rocm/bin to PATH. Open > blender, go to Edit -> Preferences and select "HIP" in "System / > Cycles > Render Devices". Open your favorite scene and select "GPU compute" in > "Render Properties". You can monitor the GPU load with > > watch -n.1 rocm-smi > > if you've installed rocm-smi-lib. > > What's next? > Add the ROCm math libraries (rocblas, rocsparse, rocfft, ..) that are > needed for Machine Learning and many other applications. > > Best! > Torsten > > [1] > https://docs.amd.com/bundle/Hardware_and_Software_Reference_Guide/page/Hard…

1 0

Mailing list to discuss ArchWiki?
by Polarian 08 Jan '23

08 Jan '23

Hello, I have realised a lot of the ArchWiki discussions are very empty, and have not been used for years for some of the pages. At first I thought this was because the pages were just not edited very often, but now I have realised that even the most popular pages do not have many discussions. Is there a mailing list for the ArchWiki, or do ArchWiki memebers use an alternative form of discussion to discuss wiki related subjects? Thank you, Polarian

9 12