Arch-general June 2023

arch-general@lists.archlinux.org

23 participants
13 discussions

nginx http3/quic support
by Genes Lists 29 Jun '23

29 Jun '23

Nginx mainline added (experimental) http3/quic support with version 1.25 in late May. Is there any interest in adding support to our nginx-mainline package? It can be optionally turned on in server config, so having it compiled in and available shouldn't have any impact until it's activated by changing the web server configs. I confirmed this with my web servers. I've been running this for a while now (even before the quic branch was merged into mainline) and it has been working well both with and without http3. Since quic uses udp, I did need to change the firewall to allow udp in addition to tcp for the web servers on port 443. In case of interest, here's what I did to build and get it running. Since openssl doesn't support quic, nginx provides for some alternatives; quictls, boringssl or libressl. I chose to use quictls. Since quictls is openssl plus quic support, I want to be sure it did not interfere in any way with the default Arch openssl libraries or binaries. So, I made a quictls package which installed into it's own tree not in /usr or /usr/local. I chose to use /usr/local/quictls/. This keeps the binaries in and libraries away from all normal paths while making the libraries readily available for nginx. I imagine there are other approaches to dealing with this. Once quictls was built and installed it is quite simple to use it to add quic support to the nginx-mainline package. As always, thanks to those keeping Arch vibrant and at the leading edge. gene

2 4

Monitor control issues after update
by Vasile Vilvoiu 27 Jun '23

27 Jun '23

Hello, So far I've relied on ddcutil to switch between two sources connected to my monitor (desktop PC over HDMI and laptop over USB-C). Unfortunately after today's update of the HDMI connected PC I can no longer do so on it as it returns the following error: $ sudo ddcutil setvcp 60 0x1b Display not found I tired building various versions of ddcutil, going back to 1.3.0, and each of them yields the same error, which makes me believe something changed in the way i2c communication is handled. Unfortunately I know nothing about i2c in Linux. These are the currently detected i2c devices: i2c-0 i2c NVIDIA GPU I2C adapter I2C adapter i2c-1 smbus SMBus I801 adapter at efa0 SMBus adapter i2c-2 i2c NVIDIA i2c adapter 1 at 1:00.0 I2C adapter i2c-3 i2c NVIDIA i2c adapter 2 at 1:00.0 I2C adapter i2c-4 i2c NVIDIA i2c adapter 3 at 1:00.0 I2C adapter i2c-5 i2c NVIDIA i2c adapter 5 at 1:00.0 I2C adapter i2c-6 i2c NVIDIA i2c adapter 6 at 1:00.0 I2C adapter I'd appreciate any help or hints that would point me in the right direction. Where should I be looking? What should I be looking for? -- Best regards, Vasile Vilvoiu

2 1

Scanner does not work in Arch Linux but works in Ubuntu VM
by Björn Försterling 18 Jun '23

18 Jun '23

Hello, I have a question about my "HP Deskjet F2280" printer/scanner. I could not get it working in Arch Linux with "sane" or "simple-scan". It is visible in a "lsusb" command and found by a "sudo sane-find-scanner" as a possible usb scanner. But it is not found in a "sudo scanimage -L" command. And "simple-scanner" or "xsane" cant find the sanner either. But when I fire up my Ubuntu 22.04 qemu VM and use the sanner through "usb-host-device" the sanner works out of the box just by installing "simple-scan". What is the key difference here? The checkbox "proprietary drivers for devices" is enabled in Ubuntu. Is the reason the custom kernel, that Ubuntu uses or kernel modules that could be also added to Arch Linux? Regards Björn

4 4

blas update
by Fons Adriaensen 15 Jun '23

15 Jun '23

On Wed, Jun 14, 2023 at 08:27:28PM -0000, Arch Linux: Recent news updates: Felix Yan wrote: > The openblas package prior to version 0.3.23-2 doesn't ship optimized > LAPACK routine and CBLAS/LAPACKE interfaces for compatibility. This > decision has been reverted now, and the ability to choose a different > default system BLAS/LAPACK implementation while keeping openblas > installed is now provided to allow future co-installation of BLIS, > ATLAS, etc. This must be the most confusing advice I ever got :-) As suggested, I tried: pacman -Syu blas-openblas which resulted in: :: Starting full system upgrade... resolving dependencies... looking for conflicting packages... :: blas-openblas and cblas are in conflict. Remove cblas? [y/N] n error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: blas-openblas and cblas are in conflict So what should I do if I want to keep cblas, lapack, numpy, scipy etc.. working ? Which blas is now 'the default one' ? TNX -- FA

2 2

"Please append your preferred default BLAS implementation to the regular -Syu command line"
by Ralf Mardorf 15 Jun '23

15 Jun '23

Hi, I don't have a preferred default BLAS implementation. IIUC BLAS is the original implementation, the standard. OpenBLAS does more or less the same as BLAS, while on one hand it was or is missing some compatibility, on the other hand depending on the used CPU, it chose different routines optimized to the CPU's instruction sets, hence OpenBLAS is faster. IIUC the problem with competing implementations is fixing bugs. IIUC... IOW my understanding is, that I don't understand anything at all related to this topic. Out of feeling and because OpenBLAS was already installed in the old version, I decided to run $ sudo pacman -Syu blas-openblas [snip] :: blas-openblas and cblas are in conflict. Remove cblas? [y/N] y :: blas-openblas and lapack are in conflict. Remove lapack? [y/N] y Packages (6) cblas-3.11.0-2 [removal] duktape-2.7.0-6 glslang- 12.2.0-1 lapack-3.11.0-2 [removal] openblas-0.3.23-3 blas- openblas-0.3.23-3 [snip] I don't like having options as long as I have no idea if my choice will make a difference or not and how that decision might affect usage. Is it possible to explain the pros and cons of the two implementations in simple terms? Regards, Ralf

2 2

Prevent pip from breaking the system by adopting PEP 668
by Martin Rys 14 Jun '23

14 Jun '23

Some time ago, PEP 668[1] enabled distributions to mark the python installation as externally managed by a package manager, thus preventing pip from breaking the system by either installing packages to the system or locally in the home folder. Debian has already adopted this[2]. >From my understanding, setting the flag EXTERNALLY-MANAGED only allows using pip inside of a virtualenv and bans using it anywhere else, unless the user uses the very self-explanatory flag --break-system-packages. Currently on Arch, users can run either `sudo pip`, which will install packages as system and break pacman altogether, or `pip` which automatically uses the --user flag nowadays, which will still break things if done outside of virtual env. Quoting arojas[3], "There are hundreds of bug reports around caused by user installed pip packages overriding system ones" it seems like using the new EXTERNALLY-MANAGED mechanism would greatly reduce wasted time for both users and people managing the bug tracker. Is Arch going to be adopting this behavior too? I could not find a discussion anywhere else about this. Martin (C0rn3j) [1] https://peps.python.org/pep-0668/ [2] https://salsa.debian.org/python-team/packages/python-pip/-/blob/master/debi… [3] https://t.me/archlinuxgroup/662555

6 10

Help debugging random lockups
by Spencer Collyer 14 Jun '23

14 Jun '23

Hi, I have a reasonably new PC which ran with no problems for around six weeks after initial install of Arch, but then about two weeks ago it started locking up randomly. I can't see anything obvious that is causing it to lock up. Sometimes it does it while I am actively working, and other times it locks up overnight (I tend to leave it running continuously). The lockups don't all look the same. For instance, sometimes the mouse cursor is still active and can be moved around the screen, and at other times it disappears completely. I've got kernel.sysrq = 1 set in my sysctl config, but sometimes it doesn't respond to the Magic SysRq key despite that. Obviously I'd like to work out what is causing the crash, so I'm looking for some pointers as to where I should be looking and what tools I could use to investigate. Thanks in advance for any info. Regards, Spencer

11 17

Resource management questions
by Hauke Fath 13 Jun '23

13 Jun '23

Hi, I am currently exploring two options for resource managing, and wondering whether I am looking in the right spot... (1) User access We have a compute server that only some groups of users have access to, since the others' boss didn't chip in. I attempted to disable logins for users without a HOME on the machine by setting DEFAULT_HOME no in /etc/login.defs, but find that HOMEless people can still ssh in. What is the equivalent of the above option for sshd on Arch? (2) Resource control On said server, I would like students' jobs to run at a lower priority. In a /etc/security/limits.d/nt-limits.conf file, I set priority limits for the respective groups @students - priority 10 but they still login with default priority value. The system log has nothing relevant. Is this supposed to work, and what does it take to make it? Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344

2 1

dhcpcd going away quietly after half a day
by Hauke Fath 13 Jun '23

13 Jun '23

Hi, since a 2023-05-30 update to my coworkers' Arch desktop machines, machines have started to go off the network after 12 - 24 hrs. When I check such a machine, dhcpcd is gone without a trace, nothing in the logs. Manually restarting dhcpcd will bring the machine back online, but only for the above timespan. I downgraded dhcpcd from the current 10.0.1 package to 9.4.1, but that doesn't make a difference. Before rolling back two dozen machines to the previous 2023-04-26 installation: Does this ring a bell for anyone? Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344

3 3

Indexing of official and unofficial pages on ArchWiki
by Polarian 07 Jun '23

07 Jun '23

Hello, So I was editing the ArchWiki today and I found the following: https://wiki.archlinux.org/title/Unofficial_user_repositories#Packages_sear… It seems we are recommending the use of pkgs.org which has indexed a few of the unofficial repositories along with the official. It is however flagged for factual accuracy (although I have not validated the flag, therefore it might have been fixed by pkgs.org), and we are relying on a third party tool. I was not too sure where to send this email, because sending it to aur-general would imply it is aur exclusive which it is not, therefore I choose arch-general as a more well rounded generally discussion. I have a single question, and I am fully aware this will not be "officially supported", however due to the disorganisation of this page, and also the flag on the current package search, is a global package search for all official and unofficial repositories something desired by the arch community? Follow up question is has the former already been attempted but failed? I have a few reasons below on why I feel it would be useful: - Currently on ArchWiki pages we attempt to list unofficial repositories which include AUR package builds for easier installation, but now with the size of the unofficial repository list, and the chance that the packages may overlap one another (ie: two or more repositories could build the same package from the AUR) it would be useful to have a tool, or database which we can link to, or we just ignore unofficial repositories completely. Currently, and I am one of the people guilty of this, only ArchWiki editors document their repositories on pages, having a tool to do it for us would be useful I feel. - There is a lot of unofficial repositories, there is no way to go through each one manually and find the package you are looking for, so no offense to all those who have put their time into unofficial repositories, but... majority of the time its "AUR builds" or with chaotic AUR everything they want to build within the AUR, with their own personal biases. I have seen projects such as bioarchlinux use the source code of the arch package search to create their own repository index, I assume this is due to the shear size of the repository. The concept would be simple: - Mirror (of official) and unofficial (repository or mirror of said repository) opt-in to being indexed. - Each database is downloaded, and the packages within it indexed against the repository name, similar to how pkgs.org does it, we should flag it as official or unofficial. - API access should be free to the entire of the arch, and the wider arch community using arch-based distributions, without any cost, and also without profit. - All source code should be open source, but saying this is a little obvious within the arch community, seen as 9/10 people stand very strongly against proprietary software. Now the reasons against it: - Centralised and unofficial, trusting centralised authority is already difficult enough, the entire reason we (hopefully) trust the arch staff is due to the representation of different viewpoints, and the voting system. This idea being unofficial and ungoverned means its subject to abuse, which is a good reason why I think nobody has suggested this, and if they have I am sure the arch staff would be uneasy about it, however on the other hand, its just indexing of publicly available information, so its not really a sensitive project. - Could be subject to abuse, just like how arch staff do not validate that unofficial repositories are not distributing anything malicious (hence the "use at your own risk" and numerous other warnings throughout the wiki about it), indexing said databases makes the project potentially liable for said problems. - I am not even sure it will work well... concepts always seem amazing when you think about it, but in practise they tend to be a whole lot worse, but it would be massively helpful for fixing and maintaining the "Installation" sections of numerous software pages on the ArchWiki. The reason I am not just going off and doing it myself, and emailing here is I have the following questions: For everyone: - Is this a terrible idea? - Who would develop and maintain the source code? - Who would be responsible to hosting it, its unofficial thus someone has to? - Would you feel comfortable using a tool which is not officially supported? For arch staff (which I hope will critisise the idea massively): - Would this breach any rules? - Would you be happy with official packages being indexed alongside their unofficial counterparts? - Would this cause conflict within the community, or with staff members? I would like to highlight this was an idea to improve what pkgs.org has already done in the way of archlinux indexing, and secondly, draw it into the arch community to follow the ideals and rules, for example pkgs.org profits off their API use, while arch believes in non-profit etc etc. I am in two minds about whether I should suggest this or should forget about it, it could go really well where users would be interested in it, or it could go badly and I might start an argument, which would be a breach of CoC on my part. I ask that people be critical of the idea, but please bare in mind this was an idea, and I am not actively trying to cause problems, it seems stupid me highlighting this but due to previous posts over the past 1-2 months which have had heavy amounts of hate towards them, I must highlight this is meant as a harmless suggestion of an idea to help ArchWiki and the general community use the unofficial repositories. If there is already a project (or many projects) which are developing something like this, please let me know, as far as I am aware I can not see any wide effort, although i am aware one or two repositories have their own indexing efforts. Anyways please let me know your opinions on this, and I hope that this doesn't turn sour like the last mailing list thread I started. Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Arch-general June 2023