- Arch-general - lists.archlinux.org

Suggestion: use static linking instead of dynamic linking just as how rust and golang do.
by Evan Greenup 13 Feb '24

13 Feb '24

Suggestion Build executable program written in Haskell statically. (For the convenient of package maintainer, remove Haskell library packages). Reason The advantage of dynamic linking is letting multiple executable sharing same part of code. The only benefit is to reduce storage consumption. But in nowadays, storage is getting cheaper and cheaper. It is no longer be a issue now. And Haskell packages are all relatively small. However, here are a lot of drawbacks for dynamic linking of Haskell ecosystem. - Firstly is dependency version conflict. If two package depend on a same package with exclusive permitted version range, it will be a big trouble. - One dependency version update requires Arch Linux package maintainer update a series of packages which depend on this package. (Unlike Python, Haskell is compiled language with low ABI compatibility across different version). - lack of link time optimization. - Long time of upgrading via pacman. Updating many small package is really much slower than updating one big package. And registering Haskell module take a long time. Why program written in C/C++ can be distributed in dynamical linking form? C/C++ has very poor dependency resolver and package manager. C/C++ project need developer take care of dependency manually. And C/C++ compiler provide relatively stable ABI. None of those condition applies to Haskell. Details of Action Only providing: - ghc exclusive to ghcup - ghcup provide ghc, stack, cabal-install. This is similar to rustup package. - haskell-language-server like other Haskell executables, statically linked. When user install ghcup via pacman , the need to manually set default toolchain to install ghc and other tools. All non-executable Haskell library become unnecessary. Since no Haskell developer will use haskell package provided by the Linux distro. Expected Benefit - package maintainer will save a lot of time on maintaining Haskell software. - update will be much quicker. - All Haskell program packages can easily up-to-date. I believe the gain of this suggestion is significantly greater than the loss. Evan

4 3

Re: Migration from LXD to Incus
by Bernd Rinn 13 Feb '24

13 Feb '24

Hello, The issue with using the lxd-to-incus migration program is that it requires the lxd server to run in order to work. If I install incus via pacman and then try to migrate, I get: # lxd-to-incus => Looking for source server ==> Detected: manual installation => Looking for target server Error: No target server could be found This message is expected, because the target server (lxd) was uninstalled by pacman during the installation of incus. In comparison, on a Debian box, 'apt-get install incus' installs Incus in parallel to lxd and the subsequent migration program works fine. Best, > Hello, > > I am yet to migrate to incus, however the lxd-to-incus tool is provided > by the incus package [1], and thus should still work as it seems to > migrate itself (lxd is just a frontend after all). > > Let incus replace lxd, run the tool, and it should work just fine. If > not, post the error and the log here so that you can be helped further. > > > What the proper way of migrating from LXD to Incus under Archlinux? > > Seen as incus is relatively new, there is no wiki article on it, and > thus, there is no "proper" way currently, but in general if the > solution provided by upstream works, why change it? > > It goes without saying but you might want to backup before you attempt > this. > > Take care,

4 6

Odd login issue
by pete 12 Feb '24

12 Feb '24

Hi all I strange one here i boot to a text prompt then login but When i enter my username hit enter it sites there not asking for password then the login prompt will return this time enter my username hit enter it then goes correctly to password and logs in perfectly Now i do not think this is related but one of the cats knocked a cup of tea into a keyboard scrapped it totally alarmingly fast a Logitec K270 wireless thing so went and purchased a replacement exactly the same make and model changed it over new usb receiver mouse keyboard . It is strange that i only nmoticed it after that Cheers Pete

1 0

warning: directory permissions differ on /usr/lib/mysql/plugin/auth_pam_tool_dir/
by David C. Rankin 11 Feb '24

11 Feb '24

All, When these crop up from time to time on update, do we just fix them and move on, or it is worth digging into further to find out when and why the permissions changed? E.g. warning: directory permissions differ on /usr/lib/mysql/plugin/auth_pam_tool_dir/ filesystem: 700 package: 755 God knows I haven't touched that package directory permissions, so something changed over the years. In the past, I have simply changed the permissions to match the package (as long as it meets a commons sense test) and been done with it. When these appear, does anybody want further info, or just fix and forget? -- David C. Rankin, J.D.,P.E.

2 2

Join the Arch Testing Team - Call for participation
by Robin Candau 10 Feb '24

10 Feb '24

Hi, We hope y'all had a good start in the new year of 2024 --- With the new year usually come new resolutions. If you don't have any so far, we have one for you: What if you decided to give Arch a bit of help with testing package updates this year? 😃 Arch uses testing repositories [1] as a buffer for core/critical package updates (or any other package updates that would benefit from being tested first) before entering the stable repositories. Testing these package updates helps us to catch more bugs upfront and ensures flawless updates for the stable repos, and that is where you can help! By joining the official Arch Linux Testing Team [2], you'll get the ability to "sign off" packages in testing after vouching for their correctness (or reporting a bug [3] otherwise). This helps Arch Package Maintainers catching eventual bugs upfront and helps to move packages out of the testing repositories faster and more efficiently. We are not necessarily looking for in depth testing. Verifying that a program launches correctly and that you're able to perform your usual routine with it is already a good test on its own. You can also check the general testing guidelines [4]. This is a very effective and rather easy way to contribute to Arch Linux. The more testers we have, the more reliable packages updates will be. We hope to see some of you there! 😉 [1]: https://wiki.archlinux.org/title/Official_repositories#Testing_repositories [2]: https://wiki.archlinux.org/title/Arch_Testing_Team [3]: https://wiki.archlinux.org/title/Bug_reporting_guidelines [4]: https://wiki.archlinux.org/title/Arch_Testing_Team#Guidelines -- Regards, Robin Candau / Antiz

1 0

laptop microphone not working properly
by Frank 08 Feb '24

08 Feb '24

Good evening, my build in mic stopped working. It produces only random noise, while i was on a Zoom call. I checked with gnome-recorder and confirm it's not the Zoom app. My wife's bluetooth headset works fine. My setup: UXEDO Pulse 14 Gen1 AMD Ryzen™ 7 4800H Arch Linux (obvioulsy) with current kernel and packages pipewire Tested on Hyperland and Gnome (both wayland and X). I checked settings in pavucontrol but looks all fine. Is there something else for me to check if it's a config/driver error and rule out hardware issue. Thanks Frank

2 1

Radicale is unmaintained upstream, but no other good alternative in official repos
by D. Debnath 05 Feb '24

05 Feb '24

Last commit is on April 22, 2023: https://github.com/Kozea/Radicale/commits/master/ Last release on July 15, 2022: https://github.com/Kozea/Radicale/releases Among the list of CalDAV/CardDAV servers mentioned in the wiki <https://wiki.archlinux.org/title/List_of_applications/Other#CalDAV/CardDAV_…>, Baikal seems to be a good alternative that is also maintained. Last commit 10 hours ago: https://github.com/sabre-io/Baikal/commits/master/ Last release on November 16, 2023: https://github.com/sabre-io/Baikal/releases While there is an AUR package of Baikal <https://aur.archlinux.org/packages/baikal>, I try to avoid installing AUR packages as much as possible. How do I request arch packagers to package Baikal in the official repos?

4 3

kernel module sg gone
by Jude DaShiell 02 Feb '24

02 Feb '24

When I wanted to read iso files on dvd or cd I used to need to do modprobe sg first. That's gone with latest update of kernel and modules and I'd like to know what replaced it. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.

3 4

[arch-general][OT] vagrant + ubuntu 20.04 based docker image
by Javier 02 Feb '24

02 Feb '24

Hello ! At work I need to use an ubuntu 20.04 based docker image built by our org, and we use vagrant to easy the way to load and start the image. I'm not able to do "vagrant up", since it seems the host can't connect to the container (guest): > INFO global: Vagrant version: 2.4.1 > INFO global: Ruby version: 3.0.6 > INFO global: RubyGems version: 3.3.25 > INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="/opt/vagrant/embedded" > INFO global: VAGRANT_EXECUTABLE="/opt/vagrant/embedded/gems/gems/vagrant-2.4.1/bin/vagrant" > INFO global: VAGRANT_INSTALLER_ENV="1" > INFO global: VAGRANT_INSTALLER_VERSION="2" > INFO global: VAGRANT_LOG="debug" > ... > DEBUG ssh: Checking key permissions: /home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.ed25519 > DEBUG ssh: Checking key permissions: /home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.rsa > INFO ssh: Attempting SSH connection... > INFO ssh: Attempting to connect to SSH... > INFO ssh: - Host: 127.0.0.1 > INFO ssh: - Port: 2222 > INFO ssh: - Username: a2sdk > INFO ssh: - Password? false > INFO ssh: - Key Path: ["/home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.ed25519", "/home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.rsa"] > DEBUG ssh: - connect_opts: {:auth_methods=>["none", "hostbased", "publickey"], :config=>false, :forward_agent=>true, :send_env=>false, :keys_only=>true, :verify_host_key=>:never, :password=>nil, :port=>"2222", :timeout=>15, :user_known_hosts_file=>[], :verbose=>:debug, :logger=>#<Logger:0x000070e2913f9dc0 @level=0, @progname=nil, @default_formatter=#<Logger::Formatter:0x000070e2913f9d20 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x000070e2913f9c80 @shift_period_suffix=nil, @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<StringIO:0x000070e2913f9e38>, @binmode=false, @mon_data=#<Monitor:0x000070e2913f9c30>, @mon_data_owner_object_id=14600>>, :keys=>["/home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.ed25519", "/home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.rsa"], :remote_user=>"a2sdk", :keepalive=>true, :keepalive_interval=>5} > DEBUG ssh: == Net-SSH connection debug-level log START == > DEBUG ssh: D, [2024-01-26T23:11:19.799621 #24466] DEBUG -- net.ssh.transport.session[391c]: establishing connection to 127.0.0.1:2222 > D, [2024-01-26T23:11:19.799907 #24466] DEBUG -- net.ssh.transport.session[391c]: connection established > I, [2024-01-26T23:11:19.799980 #24466] INFO -- net.ssh.transport.server_version[3930]: negotiating protocol version > D, [2024-01-26T23:11:19.800002 #24466] DEBUG -- net.ssh.transport.server_version[3930]: local is `SSH-2.0-Ruby/Net::SSH_7.2.1 x86_64-linux' > D, [2024-01-26T23:11:19.810429 #24466] DEBUG -- net.ssh.transport.server_version[3930]: remote is `SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.9' > I, [2024-01-26T23:11:19.810692 #24466] INFO -- net.ssh.transport.algorithms[3944]: sending KEXINIT > D, [2024-01-26T23:11:19.810886 #24466] DEBUG -- socket[3958]: queueing packet nr 0 type 20 len 852 > D, [2024-01-26T23:11:19.810953 #24466] DEBUG -- socket[3958]: sent 856 bytes > D, [2024-01-26T23:11:19.811421 #24466] DEBUG -- socket[3958]: read 1056 bytes > D, [2024-01-26T23:11:19.811496 #24466] DEBUG -- socket[3958]: received packet nr 0 type 20 len 1052 > I, [2024-01-26T23:11:19.811532 #24466] INFO -- net.ssh.transport.algorithms[3944]: got KEXINIT from server > I, [2024-01-26T23:11:19.811623 #24466] INFO -- net.ssh.transport.algorithms[3944]: negotiating algorithms > D, [2024-01-26T23:11:19.811712 #24466] DEBUG -- net.ssh.transport.algorithms[3944]: negotiated: >... > * kex: ecdh-sha2-nistp521 > * host_key: ssh-ed25519 > * encryption_server: aes256-ctr > * encryption_client: aes256-ctr > * hmac_client: hmac-sha2-512-etm(a)openssh.com > * hmac_server: hmac-sha2-512-etm(a)openssh.com > * compression_client: none > * compression_server: none > * language_client: > * language_server: > D, [2024-01-26T23:11:19.811733 #24466] DEBUG -- net.ssh.transport.algorithms[3944]: exchanging keys > D, [2024-01-26T23:11:19.812318 #24466] DEBUG -- socket[3958]: queueing packet nr 1 type 30 len 148 > D, [2024-01-26T23:11:19.812375 #24466] DEBUG -- socket[3958]: sent 152 bytes > D, [2024-01-26T23:11:19.816223 #24466] DEBUG -- socket[3958]: read 312 bytes > D, [2024-01-26T23:11:19.816293 #24466] DEBUG -- socket[3958]: received packet nr 1 type 31 len 292 > D, [2024-01-26T23:11:19.818291 #24466] DEBUG -- socket[3958]: queueing packet nr 2 type 21 len 20 > D, [2024-01-26T23:11:19.818346 #24466] DEBUG -- socket[3958]: sent 24 bytes > D, [2024-01-26T23:11:19.818401 #24466] DEBUG -- socket[3958]: received packet nr 2 type 21 len 12 > D, [2024-01-26T23:11:19.818751 #24466] DEBUG -- net.ssh.authentication.session[396c]: beginning authentication of `a2sdk' > D, [2024-01-26T23:11:19.818817 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.820166 #24466] DEBUG -- socket[3958]: queueing packet nr 3 type 5 len 32 > D, [2024-01-26T23:11:19.820205 #24466] DEBUG -- socket[3958]: sent 100 bytes > D, [2024-01-26T23:11:19.859904 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.860311 #24466] DEBUG -- socket[3958]: received packet nr 3 type 6 len 32 > D, [2024-01-26T23:11:19.860522 #24466] DEBUG -- net.ssh.authentication.session[396c]: trying none > D, [2024-01-26T23:11:19.860731 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.860969 #24466] DEBUG -- socket[3958]: queueing packet nr 4 type 50 len 48 > D, [2024-01-26T23:11:19.861076 #24466] DEBUG -- socket[3958]: sent 116 bytes > D, [2024-01-26T23:11:19.866706 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.867057 #24466] DEBUG -- socket[3958]: received packet nr 4 type 51 len 32 > D, [2024-01-26T23:11:19.867183 #24466] DEBUG -- net.ssh.authentication.session[396c]: allowed methods: publickey,password > D, [2024-01-26T23:11:19.867282 #24466] DEBUG -- net.ssh.authentication.methods.none[3980]: none failed > D, [2024-01-26T23:11:19.867369 #24466] DEBUG -- net.ssh.authentication.session[396c]: trying publickey > D, [2024-01-26T23:11:19.868848 #24466] DEBUG -- net.ssh.authentication.agent[3994]: connecting to ssh-agent > D, [2024-01-26T23:11:19.869065 #24466] DEBUG -- net.ssh.authentication.agent[3994]: sending agent request 1 len 44 > D, [2024-01-26T23:11:19.869366 #24466] DEBUG -- net.ssh.authentication.agent[3994]: received agent packet 5 len 1 > D, [2024-01-26T23:11:19.869434 #24466] DEBUG -- net.ssh.authentication.agent[3994]: sending agent request 11 len 0 > D, [2024-01-26T23:11:19.869678 #24466] DEBUG -- net.ssh.authentication.agent[3994]: received agent packet 12 len 498 > D, [2024-01-26T23:11:19.870704 #24466] DEBUG -- net.ssh.authentication.methods.publickey[39bc]: trying publickey (dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6) alg rsa-sha2-256 > D, [2024-01-26T23:11:19.870908 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.871129 #24466] DEBUG -- socket[3958]: queueing packet nr 5 type 50 len 352 > D, [2024-01-26T23:11:19.871241 #24466] DEBUG -- socket[3958]: sent 420 bytes > D, [2024-01-26T23:11:19.876890 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.877237 #24466] DEBUG -- socket[3958]: received packet nr 5 type 51 len 32 > D, [2024-01-26T23:11:19.877359 #24466] DEBUG -- net.ssh.authentication.session[396c]: allowed methods: publickey,password > D, [2024-01-26T23:11:19.877425 #24466] DEBUG -- net.ssh.authentication.methods.publickey[39bc]: trying publickey (dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6) alg ssh-rsa > D, [2024-01-26T23:11:19.877582 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.877778 #24466] DEBUG -- socket[3958]: queueing packet nr 6 type 50 len 352 > D, [2024-01-26T23:11:19.877885 #24466] DEBUG -- socket[3958]: sent 420 bytes > D, [2024-01-26T23:11:19.883542 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.883942 #24466] DEBUG -- socket[3958]: received packet nr 6 type 51 len 32 > D, [2024-01-26T23:11:19.884065 #24466] DEBUG -- net.ssh.authentication.session[396c]: allowed methods: publickey,password > D, [2024-01-26T23:11:19.884282 #24466] DEBUG -- net.ssh.authentication.methods.publickey[39bc]: trying publickey (c8:ac:1c:f8:c5:f9:7f:fc:86:97:a4:96:a3:a1:2e:d8) alg ssh-ed25519 > D, [2024-01-26T23:11:19.884463 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.884677 #24466] DEBUG -- socket[3958]: queueing packet nr 7 type 50 len 128 > D, [2024-01-26T23:11:19.884800 #24466] DEBUG -- socket[3958]: sent 196 bytes > D, [2024-01-26T23:11:19.890441 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.890795 #24466] DEBUG -- socket[3958]: received packet nr 7 type 51 len 32 > D, [2024-01-26T23:11:19.890918 #24466] DEBUG -- net.ssh.authentication.session[396c]: allowed methods: publickey,password > E, [2024-01-26T23:11:19.891081 #24466] ERROR -- net.ssh.authentication.session[396c]: all authorization methods failed (tried none, publickey) > > DEBUG ssh: == Net-SSH connection debug-level log END == > INFO ssh: SSH not up: #<Vagrant::Errors::SSHAuthenticationFailed: SSH authentication failed! This is typically caused by the public/private > keypair for the SSH user not being properly set on the guest VM. Please > verify that the guest VM is setup with the proper public key, and that > the private key path for Vagrant is setup properly as well.> > ERROR warden: Error occurred: Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > INFO warden: Beginning recovery process... > INFO warden: Recovery complete. > INFO warden: Beginning recovery process... > INFO warden: Recovery complete. > INFO warden: Beginning recovery process... > INFO warden: Recovery complete. > ERROR warden: Error occurred: Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > INFO warden: Beginning recovery process... > INFO warden: Recovery complete. > ERROR warden: Error occurred: Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > ... > INFO interface: error: Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > INFO interface: Machine: error-exit ["Vagrant::Errors::MachineGuestNotReady", "Guest-specific operations were attempted on a machine that is not\nready for guest communication. This should not happen and a bug\nshould be reported."] After the SSH authentication error, apparently because none of the attempted key authentication methods worked. Weird thing, on ubuntu 22.04 there's no problem. On arch is that I see the error. BTW, I tried "config.ssh.disable_deprecated_algorithms" [1] set to true on the Vagrantfile, and it doesn't help. I see nothing particularly curious on the Vagrantfile. For SSH: > # SSH options > sdk.ssh.username = "<container_username>" > sdk.ssh.forward_agent = true > sdk.ssh.pty = true > sdk.ssh.forward_x11 = true > sdk.ssh.insert_key = false Disabling deprecated algorithms since Arch has obviously a newer openssh, but again, that didn't help. It's weird that on arch the SSH authentication fails... I've created other docker containers based on ubuntu, pretty similar on this SSH Vagrantfile config, and no issues. On the other hand, I've also used other docker containers. Actually there are 2 from the org I work, that I would like to use on my arch box, but I just cant, currently relying on remote VMs... Thanks for any hints... -- Javier [1] https://developer.hashicorp.com/vagrant/docs/vagrantfile/ssh_settings

2 2

Nextcloud 28.0.2 removes Rescan option if integrity check disabled
by David C. Rankin 02 Feb '24

02 Feb '24

Arch devs, After the 'sodium' issue with the original 28 update, there was a request that we make known Nextcloud issues so if they are packaging related they can be fixed. In today's 28.0.2 update, the "Rescan" option is no longer presented in Admin Settings -> Overview if you have disabled integrity checks in config.php which is routinely needed on update so that the .htaccess file can be rescanned and hash updated if you have installed to a directory under your document root and needed to adjust the caldav/carddav paths in .htaccess. Without the "Rescan" option available, this way of updating the .htaccess hash to remove the warning no longer exists (it still works, you just have to save the Rescan URL before disabling integrity checks and then manually run it even though the Rescan option isn't provided) If this is a packaging issue, it needs to be fixed so the hash update can function without saving/manually running the rescan. It was there and worked fine in 28.0.1, but is gone in 28.0.2. I've also asked for help on the nextcloud forum in case this isn't a packaging issue. Further details in that post: https://help.nextcloud.com/t/nextclout-28-0-2-removes-rescan-option-when-in… -- David C. Rankin, J.D.,P.E.

1 0