#archlinux-ports | Logs for 2025-12-11

Back
[00:39:26] -!- linkmauve has parted #archlinux-ports
[00:54:11] -!- linkmauve has joined #archlinux-ports
[01:34:14] -!- Daanct12 has joined #archlinux-ports
[03:16:36] -!- clover[m] has joined #archlinux-ports
[03:17:39] <clover[m]> hey guys, how can i try the official aarch64 port of arch?
[03:21:43] <clover[m]> What mirrors / paths should I use in pacman
[03:26:18] -!- clover[m] has quit [Quit: Client closed]
[03:27:55] -!- clover[m] has joined #archlinux-ports
[03:48:00] <amstan> clover[m]: \o i remember you!
[03:48:21] <clover[m]> 0/
[03:49:09] <amstan> we should make a channel alliance between #aarch64-laptops and here
[03:49:27] <noahimesaka1873|> clover[m]: `Server = https://arch-linux-repo.drzee.net`
[03:49:27] <noahimesaka1873|> core and extra exist
[03:50:23] <clover[m]> amstan: it would be great if this channel was on matrix ^_^
[03:50:57] <amstan> clover[m]: it might be 😉 i got hooked up by gromit
[03:54:29] <clover[m]> noahimesaka: thanks i'll check it out. how close to X64 parity is it?
[03:55:02] <amstan> i haven't been here long, but I think it's pretty early, right?
[03:55:27] <amstan> Solskogen is probably the person that knows
[04:04:31] <Daanct12> noahimesaka1873|: you also need to add the key
[04:04:44] <noahimesaka1873|> almost forgot lol
[04:04:52] <Daanct12> from an existing arch linux arm install you will want to remove alarm and aur repo
[04:05:15] <Daanct12> assuming clover[m] is using danctnix, they can keep danctnix/danctnix-testing repo
[04:05:33] <Daanct12> then after that you need to do a complete reinstall using pacman
[04:06:16] <Daanct12> one important note: you MUST be using an ARMv8.2 device
[04:06:24] <Daanct12> anything below will not work
[04:06:31] <Daanct12> as in, will not boot
[04:06:36] <noahimesaka1873|> https://arch-linux-repo.drzee.net
[04:06:45] <noahimesaka1873|> the required key
[04:07:43] <Daanct12> and speaking of that i should get my orange pi 5 up and running again
[04:07:48] <Daanct12> grrr
[04:15:08] <clover[m]> noahimesaka: thanks!
[04:24:20] -!- hcmb_ has joined #archlinux-ports
[04:24:20] hcmb is now known as Guest560
[04:24:20] -!- Guest560 has quit [Killed (zinc.libera.chat (Nickname regained by services))]
[04:24:20] hcmb_ is now known as hcmb
[04:41:19] -!- clover[m] has quit [Quit: Client closed]
[04:53:33] -!- clover[m] has joined #archlinux-ports
[04:58:17] -!- clover[m] has quit [Client Quit]
[07:09:35] <solskogen|M> very early - and please don't call it "official aarch64 port of arch" - because it's extremly unofficial.
[07:12:27] -!- h|weechat has quit [Ping timeout: 244 seconds]
[07:13:34] -!- h|weechat has joined #archlinux-ports
[07:18:13] <Daanct12> solskogen|M: whoops
[07:19:02] <solskogen|M> I hope it will be, one day.
[07:21:50] <solskogen|M> Oh, it would be nice if someone could go on reddit and tell them about our little project. With links to the tarball and urls to the repos [core] [extra] and [forge]
[07:22:43] <solskogen|M> forge is for aarch64 specific packages (pi kernels and -bin packages)
[07:34:59] <yuvadm> solskogen|M: maybe we can set up a simple home page for the project? would be happy to help do that
[07:35:21] <solskogen|M> Go ahead!
[07:35:48] <solskogen|M> it could be a github gist :-)
[07:36:39] <yuvadm> sure we can statr from that, any existing documentation i can help clean up and expand?
[07:36:46] <yuvadm> other than Server = ... ?
[07:37:12] <yuvadm> what's your current bootstrap procedure?
[07:38:25] <solskogen|M> We have... almost none.
[07:38:58] <solskogen|M> Use the tarball is the correct procedure.
[07:39:33] <solskogen|M> Partition and format your drive, unpack the tarball, install linux kernel and bootloader.
[08:00:42] -!- solsTiCe3 has joined #archlinux-ports
[08:02:44] <yuvadm> solskogen|M: link to the tarball?
[08:04:15] -!- solsTiCe has quit [Ping timeout: 240 seconds]
[08:04:15] -!- solskogen|M has quit [Ping timeout: 240 seconds]
[08:04:15] -!- linkmauve has quit [Ping timeout: 240 seconds]
[08:04:16] solsTiCe3 is now known as solsTiCe
[08:04:23] -!- solskogen|M has joined #archlinux-ports
[08:13:49] -!- linkmauve has joined #archlinux-ports
[09:57:27] -!- lynxy has quit [Remote host closed the connection]
[10:12:06] -!- lynxy has joined #archlinux-ports
[10:21:31] <solskogen|M> https://arch-linux-repo.drzee.net
[10:21:32] <phrik> Title: Index of arch/tarballs/os/aarch64/ (at arch-linux-repo.drzee.net)
[10:41:20] -!- mh4ckt3mh4ckt1c4 has quit [Quit: Client limit exceeded: 90]
[11:44:49] -!- lynxy has quit [Remote host closed the connection]
[11:52:50] -!- lynxy has joined #archlinux-ports
[11:53:04] <noahimesaka1873|> <solskogen|M> "https://arch-linux-repo.drzee...." <- access denied, how fun
[11:53:16] <solskogen|M> what?
[11:53:21] <noahimesaka1873|> the whole site doesn't have any indexes just access denied
[11:53:36] * noahimesaka1873| uploaded an image: (249KiB) < https://matrix.archlinux.org >
[11:53:37] <solskogen|M> yeah, you must have the last slash
[11:54:01] <solskogen|M> https://arch-linux-repo.drzee.net works, while https://arch-linux-repo.drzee.net don't. DrZee something you can fix?
[11:54:02] <phrik> Title: Index of arch/tarballs/os/aarch64/ (at arch-linux-repo.drzee.net)
[12:52:44] -!- Daanct12 has quit [Quit: WeeChat 4.7.2]
[13:42:11] <yuvadm> from the error the repo is basically an S3 bucket
[13:42:30] <solskogen|M> because it is :-)
[13:42:46] <yuvadm> you can generate indexes manually but s3 wont do that for you :)
[13:50:51] -!- strit|M has joined #archlinux-ports
[13:50:52] <strit|M> How much space does the aarch64 repo take?
[13:58:19] <solskogen|M> Around 88G
[14:06:12] <Danct12> have we found any mirrors yet?
[14:06:51] <strit|M> I would be interested in hosting a mirror in my homelab, if we can rsync from it. 🙂
[14:07:54] <solskogen|M> Danct12: No, but that is not very important either. at least now yet. We can enable some aws cache that makes that a bit unneeded. But in the end, the aarch64 port will be where ever x86_64 is.
[14:10:08] <strit|M> So the regular mirrosr will grow with about 88G when the port becomes official.
[14:10:19] <solskogen|M> when/if, yes.
[14:10:58] <Antiz> solskogen|M: Are "any" packages also hosted on the repo?
[14:11:29] <solskogen|M> We miss almost all haskell-packages. if somebody can get that up and running (it's a horrible job to bootstrap haskell), the repo would be even bigger.
[14:11:37] <solskogen|M> Antiz: Yes.
[14:11:53] <Antiz> solskogen|M, strit|M: Okay then it's 88G - all the any packages right?
[14:12:03] <Antiz> when/if the port becomes official that is
[14:12:30] <strit|M> If the any packages gets linked into each..
[14:12:48] <solskogen|M> in the unforeseeable future it would make no sense to have two sets of -any packages.
[14:13:00] <Antiz> Yes, that's my point
[14:14:02] <Antiz> "So the regular mirrosr will grow with about 88G when the port becomes official." <-- So it's be a bit less than 88G then
[14:14:39] <Antiz> (If the 88G includes "any" packages, which we won't host multiple times for each ports I assume)
[14:15:16] <anthraxx|M> each port has technically speaking still its own -any packages they are building (and releasing) as they may move it different pace. however, in the background we have a pool directory where the files are physically stored, and the repo ftp dirs are just linking to them. so it would naturally de-duplicate -any pacages of a port of the same pkgver-pkgrel
[14:15:59] <solskogen|M> not us! We cheese our way with -any packages by copying them from x86_64.
[14:16:22] <anthraxx|M> im speaking of how it would look like if a port is official :)
[14:16:23] <Danct12> solskogen|M: i guess that worked around cyclic dependencies?
[14:16:43] <solskogen|M> Danct12: It made my job A LOT easier!
[14:17:26] <Antiz> anthraxx|M: "each port has technically speaking still its own -any packages they are building (and releasing) as they may move it different pace." <-- I'm not sure to understand. So a "any" packages could be x.y.z-1 in one architectures and x.y.z-2 in another one?
[14:17:40] <Danct12> solskogen|M: neat! thats what i did too back then
[14:18:39] <solskogen|M> Antiz: x86_64 will probably always be first, while the others will come after. so yes.
[14:19:36] <Danct12> after this.. can we have riscv64? i want to run arch on a breadboard
[14:19:41] <anthraxx|M> Antiz: you mean the latest version available in the repositories? theoretically yes. I mean we should surely try our best to move in parallel where possible, but you do not want to block x86 forever if like riscv has some fundamental issues. so you'd need to cope with releasing individually, which may result in two architectures having different versions yes.
[14:21:25] <solskogen|M> anthraxx|M: Agreed!
[14:23:35] <Antiz> anthraxx|M: Okay, I guess that makes sense. Just to make sure, this would be about theoretical edgy cases like :
[14:24:34] <Antiz> aarch64 is lagging behind regarding bash because something something. The "whatever-any" package require bash 5.4+ that aarch64 doesn't have yet.
[14:25:06] <Antiz> The "whatever-any" package new release* requires bash 5.4+ (to be more precise)
[14:26:08] <Antiz> In that case, despite being an "-any" package, "whatever-any" would be updated on every arch but aarch64 because it's blocked on Bash < 5.4
[14:26:12] <Antiz> anthraxx|M: Correct?
[14:26:55] <anthraxx|M> Antiz: yes, thats a good example for such a case.
[14:27:20] <Antiz> anthraxx|M: Okay, thanks!
[14:27:36] <Antiz> I wouldn't expect being hit by such edgy cases too often, but I guess it can happen yeah
[14:27:43] <Antiz> Fair enough
[14:28:09] <solskogen|M> while we're talking about edge cases... Can someone please explain to me why there's a ttf-gentium-7.000-1-any.pkg.tar.zst package, and ttf-gentium-plus-6.200-5-any.pkg.tar.zst package? unless I'm mistaken gentium-plus-font is pkgbase for both.
[14:29:45] <Antiz> solskogen|M: ttf-gentium-plus is its own package. Not part of the gentium-plus-font split pkg
[14:30:00] <anthraxx|M> Solskogen: rotten leftover from a past dinner: https://gitlab.archlinux.org
[14:30:01] <phrik> Title: upgpkg: 7.000-1 (75bc6e70) · Commits · Arch Linux / Packaging / Packages / gentium-plus-font · GitLab (at gitlab.archlinux.org)
[14:30:14] <Antiz> solskogen|M: Hum no nevermind, my eyes crossed
[14:30:20] <anthraxx|M> someone should db-remove it
[14:30:28] <anthraxx|M> * should db-remove --partial it
[14:30:31] <solskogen|M> yeah, so ttf-gentium-plus-6.200-5-any.pkg.tar.zst shouldn't be there, right?
[14:30:38] <anthraxx|M> correct
[14:30:40] <Antiz> solskogen|M: Yes indeed
[14:30:42] <Antiz> I can remove it
[14:30:48] <anthraxx|M> Antiz: dont fotget the --partial :D
[14:30:54] <Antiz> anthraxx|M: Yup ;)
[14:31:04] <anthraxx|M> Antiz: thanks ❤️
[14:31:48] <Antiz> solskogen|M: Ah, so my eyes did not crossed completely :P It indeed isn't part of the gentium-plus-font split pkg *anymore* :P
[14:31:56] <Antiz> That's the actual problem and what confused me :P
[14:33:09] <Antiz> solskogen|M: I removed it, it should be disappear in a few :)
[14:33:21] <solskogen|M> I have a script that tests for all kinds of stuff. Like outdated any packages (on aarch64 end), package mismatches (we don't have efl-docs, but x86_64 do (but it's a older version than efl!)) or the sub package liquid-dsp-sse4.1. it also prints out packages that only exists on aarch64 - and packages where aarch64 packages is newer than x86_64. That's where the gentium-plus-font issue showed up :-)
[14:33:40] <Antiz> Nice one :)
[14:34:22] <Antiz> solskogen|M: It's gone ;)
[14:34:35] <Antiz> Thanks for raising it BTW :)
[14:34:44] <solskogen|M> Perfect!
[14:35:13] <solskogen|M> I'm a bit afraid of raising those kinds of issues, because more often than not the problem has been on my side :-)
[14:35:33] <anthraxx|M> Solskogen: you can now restrict split packges to only be available on a limited set of architectures :)
[14:35:39] <anthraxx|M> pacman 7.1 that is
[14:35:45] <Antiz> Yay :D
[14:35:55] <solskogen|M> That is perfect!
[14:35:55] <anthraxx|M> https://gitlab.archlinux.org
[14:35:57] <phrik> Title: makepkg: allow architecture-restricted split package building (2b281d71) · Commits · Pacman / Pacman · GitLab (at gitlab.archlinux.org)
[14:36:09] <solskogen|M> same thing goes for options_$arch
[14:36:35] <jelle> anthraxx|M: hmm how does that work?
[14:36:38] <solskogen|M> We have a couple of packages that doesn't work with lto on aarch64
[14:36:55] <anthraxx|M> jelle: you can define a subset of arch=() inside the package() function
[14:37:11] <Antiz> solskogen|M: Don't be afraid to report those though. Worst case it's not actually an issue and we move on :D
[14:37:29] <jelle> anthraxx|M: so pkgbase=linux-tools pkgnames=(intel-foo) package_intel_foo() { arch=('x86_64') } ?
[14:37:43] <Antiz> solskogen|M: "same thing goes for options_$arch" <-- Ah yeah pretty cool too :D
[14:38:22] <anthraxx|M> jelle: yeah but pkgbase would also need to declare the superset, so you can just define a subset of the pkgbase superset
[14:38:45] <solskogen|M> getting pacman 7.1 for aarch64 should be my goal for the weekend.
[14:39:21] <Antiz> solskogen|M: AFAIK there's still a bit of patching to do here and there before it moves out of testing for x86_64
[14:39:22] <jelle> anthraxx|M: well example is https://gitlab.archlinux.org
[14:39:23] <phrik> Title: PKGBUILD · main · Arch Linux / Packaging / Packages / linux-tools · GitLab (at gitlab.archlinux.org)
[14:40:05] <Antiz> solskogen|M: A few stuff are still broken / not compatible with pacman 7.1 yet. But they *should* be fixed / patched shortly AFAIK
[14:40:15] <Antiz> Just so you know
[14:41:03] <solskogen|M> Okay, I'll have to take a look then. For us, the most important part is the CFLAGS and urls to the repos.
[14:41:34] <DrZee> Danct12: as someone pointed out is hosted on S3 which is blazing fast ... when pulling from the repo via Pacman (5 in parallel) I get >100Mbit (that is if the package is large enough on the small PKG it's over before it starts). S3 is fronted with a CDN (CloudFront) but caching is disabled as we in the early development pushed the same PKG (without changing version or release number)
[14:41:35] <DrZee> multiple times - this creates issues for the cache as it thinks the file has not changed. But if we enable the cache the PKG would be cached on all edges making it super fast to retrieve them anywhere... no need for mirrors. ALARM uses a similar approach
[14:41:38] <anthraxx|M> jelle: yes, pkgbase would have arch=(x86_64 aarch64) and then your example with the split package only setting x86 is precisely correct
[14:42:01] <jelle> anthraxx|M: interesting, would be nice to have a test in pacman itself as example
[16:32:02] -!- grazzolini|M has quit [Quit: Client limit exceeded: 90]