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

Bring ARM into the fold?
by Christer Solskogen 02 Mar '24

02 Mar '24

Is it time to bring Arch Linux ARM into the fold of Arch Linux? The GNU toolchain of ALARM is now very behind, and the developers are dead silent about why. There little to no response on pull requests on the github page, and while it seems like there is activity on their PKGBUILDs repo, it almost seems to me that it is some kind of automatic jobs being run. Their forum is broken and has been broken for quite some time as well. -- chs

3 2

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

[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

When I upgrade to dbus-broker should I expect anything to break?
by David C. Rankin 31 Jan '24

31 Jan '24

Archdevs, Just got the announcement about the replacement of dbus-daemon with dbus-broker. The RFC link is rather terse on any problems users may encounter when upgrading. Will all existing rules be accepted by dbus-broker or should we expect custom rules to break? (like custom access to embedded devices as character devices) What has been the experience of the devs in making the change? -- David C. Rankin, J.D.,P.E.

13 22

Postorius configuration help
by Georg 30 Jan '24

30 Jan '24

Hi list, I'm looking for a good description for postorius configuration. The Arch wiki is unclear to me, and the mailman documentation points to postorius.org configuration, who then points to another mailman doc providing little info on the actual configuration. Long story short, I'm failing to set up postorius so I can create users and let them log in. It would be highly appreciated if someone proficient in this topic is willing to walk me throuh. I'd then amend the wiki for more clarity. Thanks in advance Georg

2 1

libjxl upgrade issue
by Brian Allred 26 Jan '24

26 Jan '24

Hey all, After this morning's upgrade, libjxl was upgraded from 0.8.2-2 to 0.9.1-1. This upgrade broke several apps I use regularly, including Telegram and Discord. Downgrading back to 0.8.2-2 solved the problem, but I figured I'd send a heads-up to anyone else scratching their heads like I did for a bit. Brian

6 7

Postfix db, cdb, lmdb -- general question
by David C. Rankin 25 Jan '24

25 Jan '24

Devs, The "[Postfix] Warn that databases need regeneration" thread touched on a proposed change from BDB to another, either cdb or lmdb. This loosely mentions "licensing" issues. What licensing issue is the problem? The Oracle open-source license is OSI-certified and permits use of Berkeley DB in open source projects ... https://www.oracle.com/database/technologies/related/berkeleydb/berkeleydb-… Is there a question whether Arch or Postfix are open-source? Seems like they certainly qualify. The larger issue is what of other packages using a db backend, like Apache basic auth and the htdbm or dbmmanage tools? This begins to impact a number of server operations if db is dropped and other packages are impacted. This may be a non-issue, but not knowing what all db is integrated with, the prospect of db just going away is a bit concerning. So is this proposed change just for postfix, or could it impact other packages? -- David C. Rankin, J.D.,P.E.

2 1

[Postfix] Warn that databases need regeneration
by Polarian 24 Jan '24

24 Jan '24

Hello, I realised overnight I was not receiving emails after the latest version of postfix [1]. This is currently in testing, however I thought it would be best to discuss in the general mailing list instead of #archlinux-testing as it is a larger topic. I searched for a "updating" or "upgrading" documentation from postfix, and read their announcement and no mention was made of this. [2][3] Background behind this, I thought it was weird I didn't receive any emails for 24 hours (spam emails are pretty common, and mailing list emails so this is unheard of), so I checked the logs and found the following after updating: Jan 23 14:43:46 email postfix/trivial-rewrite[1043]: warning: virtual_alias_domains lookup failure Jan 23 14:43:46 email postfix/trivial-rewrite[1043]: warning: virtual_alias_domains: hash:/etc/postfix/virtual: table lookup problem Jan 23 14:43:46 email postfix/trivial-rewrite[1043]: warning: hash:/etc/postfix/virtual is unavailable. open database /etc/postfix/virtual.db: Invalid argument Jan 23 14:43:46 email postfix/trivial-rewrite[1043]: error: open database /etc/postfix/virtual.db: Invalid argument (Note these are in REVERSE order) So I found this pretty weird and checked my config, and checked to see virtual.db existed, which it did, so I decided to just regenerate it (postmap virtual). And it fixed the issue. I then restarted and found this: Jan 23 14:46:55 email postfix/local[1094]: warning: hash:/etc/postfix/aliases: lookup of 'polarian' failed Jan 23 14:46:55 email postfix/local[1094]: warning: hash:/etc/postfix/aliases is unavailable. open database /etc/postfix/aliases.db: Invalid argument And I did the same thing, regenerated aliases.db (postmap aliases). This fixed the issue and I am back to recieving emails, but there was NO warning of the requirement to regenerate the databases, unless it is deeply nested into the documentation somewhere? I have had my email server for years, and I have never had issues with updating, so I do find it a little strange that this update required regeneration of the databases, and there was no warning in the accouncement about it. So I have a few suggestions: - Adding a upgrading note to the ArchWiki article. [4] - Add a echo to warn the user to regenerate the virtual and aliases database in post_upgrade(). [5] And also a few questions: - Does anyone know if there is any source I am missing which warned about the requirement to regenerate the aliases and virtual databases on upgrade? - Did anyone else encounter this issue? (you would need to have testing repository enabled) Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)icebound.dev [1] https://gitlab.archlinux.org/archlinux/packaging/packages/postfix/-/commit/… [2] https://www.postfix.org/smtp-smuggling.html [3] https://www.postfix.org/announcements/postfix-3.8.5.html [4] https://wiki.archlinux.org/title/Postfix [5] https://gitlab.archlinux.org/archlinux/packaging/packages/postfix/-/blob/ma…

3 5

Mouse C & P
by pete 23 Jan '24

23 Jan '24

Hi all i can not get Cut & Paste to work with the mouse any longer it worked fine before the big opps but now humm I used to be able to C&P from xterm to gui term to term with the mouse now it does not work at all What am i mising Cheers Pete

2 7

Re: Stepping down as Python maintainer
by Genes Lists 23 Jan '24

23 Jan '24

On Wed, 2023-12-13 at 16:28 +0200, Felix Yan wrote: > Hello, > > ... > so I am > making room for others to try on the 3.11 and 3.12 rebuilds. As Jelle > has progressed a lot now, I feel it's approaching the right time for > me > to step down as the Python maintainer. > > .. Thank you Felix for all the work you've done over the years helping to make Arch into what it is today. I wonder if you could share any updates on the maintainer transition and any thoughts around the rather large 3.12 project? I also notice that while many python modules have continued to be updated some have not. Is the thinking perhaps to hold on some, especially perhaps the more complicated ones like pandas, until 3.12 is out? gene

1 0