- Arch-ports - lists.archlinux.org

Problem with libxml2 depending on icu
by Friedrich Romstedt 13 Jul '24

13 Jul '24

Hi, Today I upgraded my archlinux32 box (`# pacman -Syu`) and ran into a few problems: 1. Compiling `netatalk-3.2.0-5` fails with a linkage error: `libxml2.so.2` requires `libicuuc.so.74`, which is not found, so there are undefined references; 2. The `afpd` service of `netatalk-3.2.0-4` stopped working. For both issues, I am attaching explanatory logs. Downgrading `icu` from `75.1-1.0` back to `74.2-2.0` resolves both errors: `netatalk-3.2.0-5` now compiles, and both `netatalk-3.2.0-4` as well as `netatalk-3.2.0-5` are working fine. The upgrade of `icu` from `74.2-2.0` to `75.1-1.0` was part of today's maintenance upgrade. I speculate that `libxml2` needs an update to reflect the upgrade of `icu`? Friedrich

2 1

dhcpcd: Buffer overflow after update from 9.4.1-1.0 to 10.0.2-1.0
by Friedrich Romstedt 29 Sep '23

29 Sep '23

Hi, `dhcpcd-9.4.1-1.0` is running fine on my Arch Linux 32 box. However, when updating to `dhcpcd-10.0.2-1.0`, I am encountering errors captured by `systemd`. `dhcpcd` exits with the error message `*** buffer overflow detected ***: terminated`. I am attaching the output of `systemctl status --state failed`. I did some googling but couldn't find a way to remedy this problem. Any ideas? Seems to me to be possibly system specific; please let me know what details to provide would be helpful. Best, Friedrich

2 1

Re: dhcpcd: Buffer overflow after update from 9.4.1-1.0 to 10.0.2-1.0
by Friedrich Romstedt 29 Sep '23

29 Sep '23

Hi Andreas, Am Do., 28. Sept. 2023 um 20:16 Uhr schrieb Andreas Baumann <mail(a)andreasbaumann.cc>: > > Yes, this is a known problem with some versions of dhcp. Easiest > is to simply use dhclient instead of dhcpd. Ok, thanks for the info. To avoid risking to lose access to the machine when trying possible future versions of dhcpcd, I am using a systemd-networkd approach now, which is working fine. I have a fully static use-case here. Have a nice day, Friedrich

1 0

Archlinux32: python & lots of dependent packages out of sync
by Markus Schaaf 07 Sep '23

07 Sep '23

Hi, in the Archlinux32 repos, a lot of packages that install Python modules need rebuilding. It would be nice, if upgrading Python and such packages could somehow be coordinated, such that a new release of the Python interpreter and these packages are only pushed after all of them have been rebuilt. I don't know how Archlinux handles this, but I never noticed such problem there. A cursory look through the logs seems to show that many of the packages I'm complaining about failed building, because a dependency wasn't built/updated first. For instance Borg failed because of python-jaraco.functools, which failed because the dependency python-setuptools is missing, which should have been pulled in by python-setuptools-scm. Here is part of the build log for python-jaraco.functools: > (2/3) installing python [######################] 100% > > > Optional dependencies for python > python-setuptools > python-pip > sqlite [installed] > mpdecimal: for decimal > xz: for lzma [installed] > tk: for tkinter > (3/3) installing python-more-itertools [----------------------] 0% > (3/3) installing python-more-itertools [######################] 100% > > > [?25h==> Checking buildtime dependencies... > ==> Installing missing dependencies... > [?25lresolving dependencies... > looking for conflicting packages... > > Packages (15) perl-error-0.17029-5.0 perl-mailtools-2.21-7.0 > perl-timedate-2.33-5.0 python-iniconfig-2.0.0-2.1 > python-packaging-23.1-1.1 python-pep517-0.1-1.3 > python-pluggy-1.0.0-2.1 python-typing_extensions-4.7.1-1.0 > git-2.40.1-1.0 python-build-0.1-1.3 python-installer-0.1-1.3 > python-jaraco.classes-3.2.3-1.1 python-pytest-7.4.0-1.0 > python-setuptools-scm-7.1.0-4.1 python-wheel-0.1-1.3 > > Total Installed Size: 49.66 M As you can see, python-setuptools-scm gets installed without its dependency python-setuptools. Could someone please have a look at this? BR

2 2

Arch for Arm64 for Tegra / jetson nano : how good is it ?
by Mario Marietto 09 May '23

09 May '23

Hello. I dont hide my interest in the installation of Arch arm64 on the Jetson nano. I would like to understand what works and what not. Can I have a more modern OS than Ubuntu 18.04 ? help me to understand. Very thanks. -- Mario.

1 0

Kernel panic with archlinux32 on Intel Core Solo
by Georg 09 Feb '23

09 Feb '23

Hi, attempting to convert an old Laptop* to a usable (aka Arch-based) device I run into a kernel panic when booting the latest AL32. The messages dumped on screen seem pretty unhelpful, and I wanted to make sure this is not due the dated hardware which is not supported anymore? If so, I'd appreciate a hint on where to find a (preferably arch-based) distro for that device. Thanks. Georg * Sony Vaio VGN G11XN with an Intel Core Solo U1500

2 2

repod: A new Arch Linux project for repo management
by Brett Cornwall 22 Jun '22

22 Jun '22

I'm pleased to announce a new Arch Linux project named “repod”. This project [1] contains tooling to maintain binary package repositories for Linux distributions using the Pacman package manager. Repod aims to reduce the current complexity/pain-points of Arch repository management while supporting robust/convenient management tooling. Repod is still in pre-release state and as such has not yet reached its minimum feature set. However, we'd love your involvement; We hope to benefit all distributions using Pacman, not only Arch Linux. Existing documentation and functionality may be viewed at readthedocs [2]. A number of tickets feature tags of "good first issue" [3] to ease the nascent contributor into the project. If you're interested, Join the arch-projects(a)lists.archlinux.org list [4] for announcements, meeting minutes, and development discussion. Or stop by #archlinux-projects on Libera IRC. We'd love to see you there! [1] https://gitlab.archlinux.org/archlinux/repod [2] https://repod.readthedocs.io/en/latest/ [3] https://gitlab.archlinux.org/archlinux/repod/-/issues/?label_name%5B%5D=goo… [4] https://lists.archlinux.org/mailman3/lists/arch-projects@lists.archlinux.or…

1 0

[arch-ports] An issue with qemu7 and dependencies.
by Matthew Dyer 20 May '22

20 May '22

Hi all, I am a new member to this list as I am using a pi400 using a distro designed for the blind called stormux which is based on arch arm platform. Earlyer this week qemu7 was released in the stable repo and when trying to upgrade I was told that the package qemu desktop could not be installed because of broken dependencies. I had to add both qemu-headless and qemu-img to my ingore list in pacman.conf to get the other packages to upgrade. I am wondering if there is a way to force or in this case get this package to upgrade? I know that qemu-headless was replaced with qemu-desktop, but when trying to install I can not because of this broken dependency issue. Anyone else had this problem? Thanks in advance. I am new to arm so if there is something different in this is handeled then I appolegize up frount. Thanks. Matthew

2 1

Re: [arch-ports] Easier to cross-bootstrap or bootstrap with another distro?
by Sijie Bu 01 May '21

01 May '21

Thank you for your input. The Debian port in question seems to have been bootstrapped by cross compiling, but the later stages are mostly done with qemu-user chroots. So there's still hope that I can qemu-user all the way if my host is fast enough... Have a nice day. Sincerely ________________________________________ From: Andreas Baumann Sent: Wednesday, April 28, 2021 21:57 To: Sijie Bu Cc: Discussion regarding the porting of Arch Linux to non-x86_64 architectures Subject: Re: Easier to cross-bootstrap or bootstrap with another distro? > Reply-To: Andreas Baumann <mail(a)andreasbaumann.cc> > In-Reply-To: <BY5PR14MB3669ACC64AF81801392F1F64DA429(a)BY5PR14MB3669.namprd14.prod.outlook.com> > > On Mon, Apr 26, 2021 at 09:00:04AM +0000, Sijie Bu via arch-ports wrote: > > (This message was originally posted on arch-general and I was redirected by a member to this list.) > > > > Hello, > > Hi, > > > > I am about to start working as an intern at CIP United, a company focusing on MIPS chips, and I will be bootstrapping Arch Linux onto the MIPS64r6 architecture, in a fashion similar to Arch Linux ARM. > > > > I have checked the Arch Linux MIPS project, but it seems to be inactive for years now. I have checked ArchWiki's DeveloperWiki section, but it seems to lack guidelines or suggestions on bootstrapping Arch onto a new architecture. Therefore I have a few questions: > > - Intuitively, I think I should cross-compile the packages of the "core" section (sans a few x64-specific packages) and build a bootable rootfs, but I was having some trouble finding how should I set makepkg to cross-compile. Do I just set up an Arch developer environment as usual, but substitute the toolchain with the cross ones? > > I did a "cross-compile" from x86_64 to i486 some time ago, you can maybe > find some useful information in https://git.archlinux32.org/bootstrap32/. > > I can also recommend the oakensource's RISC-V port at > https://github.com/oaken-source/parabola-cross-bootstrap > > Basically yes, you'll need a cross toolchain for MIPS, either from the AUR > or use a cross-platorm distro like http://t2sde.org/ to bootstrap directly > from MIPS (in qemu or so). > > > - Does adding a new architecture require modifications to the pacman source code? Or pacman itself should support new architectures? I have also tried looking at pacman source code, and it seems to not have hard-coded list of architectures, but I am not 100% sure about this (if I'll have to modify the source code of pacman, I will be emailing the pacman-dev mailing list regarding their policies on patches etc.). > > In theory pacman should be quite portable (it runs at least on x86_64, IA32, > ARM 32-bit, AARCH64). So the typical 32-/64-bit issues should have been > fixed. > > You will have to make pacman know about your new architecture (and > eventually subarchitectures). See our fork of pacman on > https://git.archlinux32.org/pacman/ > (basically auto-detection for SSE2, support for sub-architectures > 'i486', 'i686', 'pentium4'). > > Most work I expect in breaking cycles and dependencies in PKGBUILDs. > > > > > Thank you for your time and have a nice day. > > Sincerely > > _______________________________________________ > > arch-ports mailing list > > arch-ports(a)lists.archlinux.org > > https://lists.archlinux.org/listinfo/arch-ports > > Happy porting, feel free to ask questions on IRC at #archinux-ports or #archlinux32. :-) > > Cheers > > Andreas > > -- > Andreas Baumann > Trottenstrasse 20 > CH-8037 Zuerich > Telefon: +41(0)76/373 01 29 > E-mail: mail(a)andreasbaumann.cc > Homepage: www.andreasbaumann.cc > > On Thu, Apr 29, 2021 at 12:52:06AM +0000, Sijie Bu wrote: > Hello, > > I do have a quick follow-up question. My friends who works for CIP United told me that > they've already got a full Debian port, and it can be run with either qemu-system or > qemu-user (unfortunately it seems actual hardware for MIPS64 R6 aren't available yet, > probably due to the global silicon shortage). So I'm wondering will it be easier if > I first compile pacman against Debian libraries, and use that to natively bootstrap > a stage1 image than using cross compiler for bootstrapping? Hi, You can in this case start right away to build a minimal Archlinux chroot on Debian containing all essential packages (at least the C/C++ toolchain, base packages and pacman and its dependencies). It's definitely easier to do so, as you don't have to deal with cross-compilation issues in packages. On the other hand running this in qemu might me unthinkable slow, without ccache/distcc-ing the load to the native CPU, this will take forever. > Thank you for your time and have a nice day. > > Sincerely Cheers Andreas -- Andreas Baumann Trottenstrasse 20 CH-8037 Zuerich Telefon: +41(0)76/373 01 29 E-mail: mail(a)andreasbaumann.cc Homepage: www.andreasbaumann.cc

1 0

[arch-ports] Easier to cross-bootstrap or bootstrap with another distro?
by Sijie Bu 29 Apr '21

29 Apr '21

Hello, I do have a quick follow-up question. My friends who works for CIP United told me that they've already got a full Debian port, and it can be run with either qemu-system or qemu-user (unfortunately it seems actual hardware for MIPS64 R6 aren't available yet, probably due to the global silicon shortage). So I'm wondering will it be easier if I first compile pacman against Debian libraries, and use that to natively bootstrap a stage1 image than using cross compiler for bootstrapping? Thank you for your time and have a nice day. Sincerely ________________________________________ From: Andreas Baumann Sent: Monday, April 26, 2021 02:27 To: Discussion regarding the porting of Arch Linux to non-x86_64 architectures Cc: Sijie Bu Subject: Re: [arch-ports] Advice on bootstrapping Arch onto a new architecture? Reply-To: Andreas Baumann <mail(a)andreasbaumann.cc> In-Reply-To: <BY5PR14MB3669ACC64AF81801392F1F64DA429(a)BY5PR14MB3669.namprd14.prod.outlook.com> On Mon, Apr 26, 2021 at 09:00:04AM +0000, Sijie Bu via arch-ports wrote: > (This message was originally posted on arch-general and I was redirected by a member to this list.) > > Hello, Hi, > I am about to start working as an intern at CIP United, a company focusing on MIPS chips, and I will be bootstrapping Arch Linux onto the MIPS64r6 architecture, in a fashion similar to Arch Linux ARM. > > I have checked the Arch Linux MIPS project, but it seems to be inactive for years now. I have checked ArchWiki's DeveloperWiki section, but it seems to lack guidelines or suggestions on bootstrapping Arch onto a new architecture. Therefore I have a few questions: > - Intuitively, I think I should cross-compile the packages of the "core" section (sans a few x64-specific packages) and build a bootable rootfs, but I was having some trouble finding how should I set makepkg to cross-compile. Do I just set up an Arch developer environment as usual, but substitute the toolchain with the cross ones? I did a "cross-compile" from x86_64 to i486 some time ago, you can maybe find some useful information in https://git.archlinux32.org/bootstrap32/. I can also recommend the oakensource's RISC-V port at https://github.com/oaken-source/parabola-cross-bootstrap Basically yes, you'll need a cross toolchain for MIPS, either from the AUR or use a cross-platorm distro like http://t2sde.org/ to bootstrap directly from MIPS (in qemu or so). > - Does adding a new architecture require modifications to the pacman source code? Or pacman itself should support new architectures? I have also tried looking at pacman source code, and it seems to not have hard-coded list of architectures, but I am not 100% sure about this (if I'll have to modify the source code of pacman, I will be emailing the pacman-dev mailing list regarding their policies on patches etc.). In theory pacman should be quite portable (it runs at least on x86_64, IA32, ARM 32-bit, AARCH64). So the typical 32-/64-bit issues should have been fixed. You will have to make pacman know about your new architecture (and eventually subarchitectures). See our fork of pacman on https://git.archlinux32.org/pacman/ (basically auto-detection for SSE2, support for sub-architectures 'i486', 'i686', 'pentium4'). Most work I expect in breaking cycles and dependencies in PKGBUILDs. > > Thank you for your time and have a nice day. > Sincerely > _______________________________________________ > arch-ports mailing list > arch-ports(a)lists.archlinux.org > https://lists.archlinux.org/listinfo/arch-ports Happy porting, feel free to ask questions on IRC at #archinux-ports or #archlinux32. :-) Cheers Andreas -- Andreas Baumann Trottenstrasse 20 CH-8037 Zuerich Telefon: +41(0)76/373 01 29 E-mail: mail(a)andreasbaumann.cc Homepage: www.andreasbaumann.cc

2 1