#archlinux-ports | Logs for 2025-09-09

Back
[02:49:01] <bschnei> gromit: I'm also watching this project: https://mono.si
[02:49:02] <phrik> Title: Gateway development kit preorders (at mono.si)
[02:52:12] <bschnei> if v8 proves too problematic to support I could use that instead. it's absurdly OP for my small home net though and $ to match. also I'll just leave this here: https://system76.com 👀
[02:52:13] <phrik> Title: Thelio Astra (at system76.com)
[04:53:43] <nl6720> gromit: thanks! everything looks as it should. I'm not sure what's wrong with xorriso, though, since the command works for me
[05:22:44] <Solskogen> nl6720: which packages do you use to bootstrap?
[05:23:27] <Solskogen> I'm all in for having [core] and [extra], plus -staging and -testing for both.
[05:23:41] <nl6720> Solskogen: you mean for the bootstrap tarball? https://gitlab.archlinux.org
[05:23:42] <phrik> Title: configs/releng/bootstrap_packages.x86_64 · master · Arch Linux / archiso · GitLab (at gitlab.archlinux.org)
[05:23:49] <Solskogen> I just need a way to figure out which package goes where
[05:24:37] <Solskogen> nl6720: ah, I was under the impression you created tarballs for aarch64 :-)
[05:25:53] <nl6720> you need a aarch64 system to create the aarch64 tarball (it should have the same two packages) because you can't pacstrap across arches
[05:27:49] <Solskogen> correct. we don't have a automatic way of creating tarballs yet, but I think DrZee was about to change that.
[05:30:13] <nl6720> mkarchiso will be able to create tarballs for other architectures soon-ish. the WIP branch in the snippet I linked yesterday works
[06:09:31] <DrZee> nl6720: so if I read that right only base and arch-install-scripts are in the tarballs ....
[06:09:45] <DrZee> that's easy ....
[06:09:46] <nl6720> yes
[06:10:01] <nl6720> I'm not even sure why arch-install-scripts is even there
[06:26:18] <Solskogen> because you need pacstrap to do the actuall install?
[06:27:58] <nl6720> you don't. once you have base, you have already installed the system. the rest of the packages can be installed with pacman
[06:30:51] <Solskogen> isn't the arch iso only for booting the installation?
[06:32:21] <nl6720> aren't we talking about the bootstrap tarball? its only use is to be extracted on to a prepared file system; then you chroot and add the finishing touches if needed
[06:33:04] <Solskogen> Ah! Now I'm with you.
[06:33:06] <Solskogen> sorry
[06:37:21] <Solskogen> shouldn't the tarball only contain what the package base gives?
[06:38:34] <nl6720> most likely yes. I think arch-install-scripts is there because of some non-optimal install method that used to be documented in the wiki
[07:21:23] <DrZee> nl6720: can you test/check the tarball at the below URL and tell me if it's correctly packaged or not? https://arch-linux-repo.drzee.net
[07:36:46] <nl6720> DrZee: sorry to say, but it's wrong. the whole directory tree should be inside a "root.aarch64" directory. and, I'm not sure how to best explain it, the contents to the tarball should be added differently, so that they don't start with "./". you can see this with: bsdtar -tf archlinux-bootstrap-*aarch64.tar*
[07:37:14] <nl6720> compare it with the x86_64 tarball that whose files are listed differently
[07:38:20] <nl6720> I don't know how you're crating it, but in bash it's like this: https://gitlab.archlinux.org you cd into the directory with the root.$arch and run bsdtar there referencing the files or dirs by their names
[07:38:21] <phrik> Title: archiso/mkarchiso · master · Arch Linux / archiso · GitLab (at gitlab.archlinux.org)
[07:44:02] <DrZee> nl6720: this was just a quick and dirty pactrap in a folder and then tar that folder ... ,😀 .... thanks for the link Ill check it
[07:48:15] <nl6720> sadly a quick and dirty pacstrap in not enough. you need to be careful not to pollute it with things from the host system; e.g. things like pacman.conf's HookDir need to be explicitly set, the /etc/machine-id file must be deleted, etc.
[08:02:41] <gromit> DrZee: could we please not spin our own stuff and use the proper tooling for everything? Re-creating what the archiso tooling does only hinders efforts to utilize it later on
[08:31:18] <DrZee> nl6720: yeah I see there are more steps there ...
[08:40:24] <DrZee> gromit: this could be a lengthy discussion 😀.... I totally get where you coming from thouh ... but I'm looking to understand what's going on and re-implementing it is my way to figure that out ... it may give me the opportunity on how to do it differently and how to use modern approaches to solve some of the challenges
[08:44:34] -!- h|weechat has quit [Ping timeout: 256 seconds]
[08:45:55] -!- h|weechat has joined #archlinux-ports
[08:53:13] -!- nl6720 has quit []
[08:54:10] -!- nl6720 has joined #archlinux-ports
[09:04:24] <DrZee> nl6720: new tarball ... this time built with mkarchiso ....https://arch-linux-repo.drzee.net/tarballs/archlinux-baseline-bootstrap-2025.09.09-aarch64.tar.zst
[09:05:20] <nl6720> this one looks good
[09:07:38] <DrZee> there is no PKG for archiso? so have to pull it from gitlab and run make install?
[09:08:47] <nl6720> DrZee: there is a package, but the non-x86_64 changes are not merged yet
[09:09:37] <nl6720> there's also archiso-git in the AUR, but that has the same issue
[09:11:36] <DrZee> which one? I used the gitlab version and only needed to change arch in profile.sh and create / rename (from x86_64) bootstrap_packages.aarch64
[09:12:44] <nl6720> you used https://gitlab.archlinux.org right? the official source is https://gitlab.archlinux.org
[09:12:45] <phrik> Title: Commits · bootmodes-no-arch · nl6720 / archiso · GitLab (at gitlab.archlinux.org)
[09:14:31] <nl6720> hmm, actually the tarball may not need any of those changes to work as is
[09:14:44] <DrZee> nope the one I used was directly from gitlab: https://gitlab.archlinux.org
[09:14:48] <phrik> Title: archiso/mkarchiso · master · Arch Linux / archiso · GitLab (at gitlab.archlinux.org)
[09:15:48] <nl6720> DrZee: yeah, I was mistaken. sorry! the ISO creating needs multiple changes, but the tarball creating should work
[09:16:51] <DrZee> yeah the tarball path only needs very minimal stuff .... arch needs to set correctly ... bootstrap_packaged with correct arch needs to exist and the "rest" is handled by pointing to a pacman.conf that uses the aarch64 repos ...
[09:17:54] <nl6720> you can actually just remove "arch" and it will default to $(uname -m)
[09:19:00] <DrZee> even better ... that should be the default ... can we also do something about making bootstrap_packages generic?
[09:20:30] <nl6720> I was thinking about renaming the file to bootstrap_packages.any and setting bootstrap_packages='bootstrap_packages.any', but I don't want to overburden the person reviewing my MRs even more :)
[09:28:34] <DrZee> I was looking at the code in line 1783 ... why are we looking for a bootstrap package with the specific arch? If we want same Arch Linux on any architecture it make no sense ... what arch this "becomes" depends on the repository sources in pacman.
[09:29:22] <Solskogen> gromit: can you tell me a bit on how the worker (-w / --worker SLOT in pkgctl-build) works?
[09:30:32] <nl6720> DrZee: that's most likely because it matches with packages.${arch} that's used for the ISO. there's no deeper meaning
[09:44:44] <DrZee> nl6720: same argument for iso though... assume all different Arch Linux CPU architectures have the same packages ... then it shouldn't be different.
[09:46:17] <nl6720> things like intel-ucode do not make sense on non-x86_64
[09:47:55] <DrZee> nl6720: maybe the right approach is to have a default that the code always expects ... and then an optional one that has the specific architecture... but the code doesn't error if that one does not exist?
[09:49:36] <DrZee> right now the code will error if boostrap for the architecture does not exists unless you explicitly set boostrap_packages ... but then you can not pull in additional files ...
[09:49:58] <nl6720> IIRC having a one common file + arch specific ones is how it used to be more than a decade ago before the dual (i686+x86_64) stuff was ripped out. I don't having separate files is that much of an issue
[09:50:12] <nl6720> s/don't/don't think/
[09:51:03] * nl6720 hopes no one actually wants multi architecture ISOs
[09:59:47] <nl6720> DrZee: one of the packages missing from your repo is refind. AFAIK it supports AA64 UEFI, so it should be possible to build it
[10:07:11] <DrZee> solskogen is the builder at the moment,😀 .... he should know if there is an issue with it.
[10:11:25] <Solskogen> refind doesn't build on aarch64
[10:13:07] <nl6720> :(
[10:13:22] <Solskogen> Let me try again and see. I don't remember what the problem was.
[10:15:26] <nl6720> the PKGBUILD hardcodes x64, but I assume you already fixed that before building
[10:18:53] <DrZee> what does refind do?
[10:24:31] <Solskogen> nl6720: yes. And the Makefile assumes you're cross compiling as well, when building on aarch64, which means that it uses the wrong compiler and linker.
[10:24:35] <Solskogen> objcopy: refind_aa64.efi: file format not recognized
[10:24:42] <Solskogen> so it requires some changes, it seems.
[10:24:47] <Solskogen> binutils as well, I guess
[12:27:50] <gromit> Solskogen: Why are you asking about -w/--worker? tbh, I never had to use it :D
[12:57:35] <Solskogen> Because I'm wondering how it works (if it works)
[13:01:13] <gromit> Solskogen: but what's the usecase?
[14:09:06] <Solskogen> I mean, could we just install a agent on one of our build machines and pkgctl do the rest?
[15:06:39] <DrZee> in other news .... I managed to get archlinux-docker to work ... some manual override of the pacman extra conf that come with devtools (to point to the right repos) and it worked .... seems to run fine with podman run -i
[15:07:04] <jelle> podman++
[15:17:50] <DrZee> cool managed to get the image to run on AWS build pipeline service using ARM hardware ... now I canbuse this to build all kinds of stuff ,😀
[15:50:10] -!- Atsutane has joined #archlinux-ports
[15:55:42] -!- marmis has quit [Quit: Bye!]
[16:00:31] -!- marmis has joined #archlinux-ports
[16:08:00] -!- marmis has quit [Quit: Bye!]
[16:12:30] -!- marmis has joined #archlinux-ports
[16:32:36] -!- marmis has quit [Quit: Bye!]
[16:35:13] -!- marmis has joined #archlinux-ports
[16:39:52] -!- marmis has quit [Client Quit]
[16:42:47] -!- marmis has joined #archlinux-ports
[16:44:05] -!- marmis has quit [Client Quit]
[16:45:02] -!- marmis has joined #archlinux-ports
[16:51:20] -!- marmis has quit [Quit: Bye!]
[16:52:19] -!- marmis has joined #archlinux-ports
[16:53:01] -!- marmis has quit [Client Quit]
[16:55:17] -!- marmis has joined #archlinux-ports
[16:56:10] -!- marmis has quit [Client Quit]
[16:57:24] -!- marmis has joined #archlinux-ports
[17:23:07] -!- Wkiktor has joined #archlinux-ports
[19:27:28] -!- drathir_tor has quit [Remote host closed the connection]
[19:30:33] -!- drathir_tor has joined #archlinux-ports
[19:39:41] <Solskogen> felixonmars|M: How do you know figure out that the risc-v packages are behind x86_64? My guess is that you have a better way of figuring out when the packages are behind and needs updating then we in aarch64 do.
[19:40:20] <Solskogen> I only have a script that compares the .db files - and spits out a sorted list of pkgbase names.
[19:40:35] -!- Wkiktor has quit [Quit: Leaving]
[19:41:51] <Solskogen> I have to figure out a way to also put the correct package in the correct repo. as of now, we put all our compiled packages into one.
[19:43:12] <Solskogen> if anyone have an idea, I'm eager to listen to it!
[22:10:19] -!- titus_livius has joined #archlinux-ports