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

Back
[03:48:48] * felixonmars|M wonders if he should invite riscv64 and loong64 team here too
[04:03:21] -!- qixiqaq|M has joined #archlinux-ports
[05:34:06] <Solskogen> felixonmars|M: go ahead!
[05:35:56] <Solskogen> I'm quite sure we face a lot of the same issues.
[07:22:41] -!- marmis1 has joined #archlinux-ports
[07:24:46] -!- marmis has quit [Ping timeout: 256 seconds]
[07:24:46] marmis1 is now known as marmis
[11:19:35] -!- tpkessler|M has joined #archlinux-ports
[11:20:15] <tpkessler|M> @liberachat_gromit:archlinux.org Here to help with the rocm stuff!
[11:21:58] <gromit> tpkessler|M: \o/ noice, so I already found that we need to change one compiler flag to adjust for the different architecture target, but even when setting this the build fails with a hard error; I can send a link to the log later
[11:23:29] <gromit> tpkessler|M: https://gist.github.com
[11:23:30] <phrik> Title: rocm-llvm-6.4.3-2-aarch64-build.log · GitHub (at gist.github.com)
[11:23:58] <gromit> This is with already adjusted "-D LLVM_TARGETS_TO_BUILD='AMDGPU;NVPTX;AArch64'"
[12:53:30] <tpkessler|M> @liberachat_gromit:archlinux.org That's a weird error. It could be that AMD breaks ARM64 without realizing it as they officially support x86_64 only.
[13:17:09] <Solskogen> why is NVPTX there?
[13:17:21] <Solskogen> and why not Native instead of AArch64?
[13:40:15] <gromit> Solskogen: because we also carry it in the PKGBUILD on x86_64, maybe tpkessler|M knows more about it
[13:40:27] <gromit> Solskogen: I can try "Native"
[13:44:25] <tpkessler|M> <Solskogen> "why is NVPTX there?..." <- That's because of hipify, a tool to translate cuda into rocm code. Clang needs to know cuda to generate and modify the AST of the source code.
[13:46:34] <tpkessler|M> @liberachat_Solskogen:archlinux.org
[13:47:52] <gromit> tpkessler|M: I could also imagine that the error is already fixed in main llvm but just one of these lacking backports
[13:49:03] -!- solsTiCe8 has joined #archlinux-ports
[13:51:55] -!- solsTiCe has quit [Ping timeout: 250 seconds]
[13:51:55] solsTiCe8 is now known as solsTiCe
[14:01:59] <nl6720> are the current porting efforts listed/documented somewhere?
[14:42:35] <bschnei> nl6720: we are kicking ideas around: https://gitlab.archlinux.org
[14:42:37] <phrik> Title: Project space for the Aarch64 Linux project (#699) · Issues · Arch Linux / infrastructure · GitLab (at gitlab.archlinux.org)
[14:44:05] <bschnei> as it stands there is plenty of work to be done just getting packages to build that we just look to see if one of us has already opened an MR for something, and if not, we try to tackle it
[14:51:44] <nl6720> I'm trying to get archiso to work on non-x86_64 (to build ISOs and bootstrap tarballs), so I was wondering who would be interested to test it (when things are at a point where they can be tested)
[15:00:20] <Solskogen> tpkessler|M: Ah, I see.
[15:01:05] <Solskogen> nl6720: I can! I've a got UEFI capable ARM board
[15:01:09] <gromit> nl6720: I guess we can find someone in here to test
[15:01:15] <gromit> Thanks for your efforts
[15:01:31] <nl6720> for reference: https://gitlab.archlinux.org
[15:01:32] <phrik> Title: Support other architectures (#193) · Issues · Arch Linux / archiso · GitLab (at gitlab.archlinux.org)
[15:02:11] <nl6720> things are still WIP, but the branch mentioned in https://gitlab.archlinux.org could work
[15:02:12] <phrik> Title: Support other architectures (#193) · Issues · Arch Linux / archiso · GitLab (at gitlab.archlinux.org)
[15:02:30] <nl6720> at least the bootstrap tarball builds
[15:02:57] <nl6720> (and I uncovered an issue with the tarball creation in the process)
[15:04:17] <gromit> nl6720: \o/
[15:04:35] <gromit> nl6720: I'll try to create a bootstrap tarball from it later and report back
[15:13:29] <bschnei> also happy to test. thanks for tackling!
[15:14:18] <nl6720> you can try it with https://gitlab.archlinux.org
[15:14:19] <phrik> Title: archiso bootstrap tarball AArch64 test ($3782) · Snippets · GitLab (at gitlab.archlinux.org)
[15:14:42] <nl6720> that's on top of the bootmodes-no-arch branch
[15:26:30] * nl6720 added instructions on applying the patch to the snippet
[16:32:13] <gromit> tpkessler|M, Solskogen: I think I now know what the issue is with rocm-llvm, but I don't know how we can manage the insanity of backports needed to fix it x)
[16:37:17] <gromit> Maybe a manual patch will cut it :p
[18:01:31] <gromit> tpkessler|M, Solskogen: After patching my way around the previous compiler error it's still very much unhappy: https://gist.github.com
[18:01:32] <phrik> Title: rocm-llvm-6.4.3-2-aarch64-build.log · GitHub (at gist.github.com)
[18:01:48] <gromit> I'm actually curious how tom handles all of this for fedora 🤔
[18:02:50] <tpkessler|M> gromit: fedora uses upstream LLVM and maintains their own forks of compiler support (comgr).
[18:03:21] <gromit> right 🥹
[18:03:52] <gromit> nl6720: Image built successfully, now I just need to test it ^_^
[18:15:40] <gromit> DrZee: did you already have a chance to test the MR by nl6720? If you want I can make you the output images available
[18:28:43] <DrZee> gromit: you mean testing the arch iso for arm? i never used that as a foundation to build the machine images not even on x86 .... would have to change the build process and figure out how to convert them. I just use pactrap directly.... most of it is outlined here: http://arch-ami-list.drzee.net Its almost the same for arm except that i use uefi boot which requires
[18:28:43] <DrZee> some changes in setting up the partitions and grub
[18:28:43] <phrik> Title: How to build an Arch Linux AMI (at arch-ami-list.drzee.net)
[18:29:37] <gromit> DrZee: but then you'd still need the bootstrap tarball for that right?
[18:29:58] * jelle ponders about mkosi ami
[18:30:56] <DrZee> nope I never create a tarbal as such (even though what I do is almost the same steps needed to create a tarbal)
[18:32:26] <DrZee> it would be easier to explain in a show and tell (then typing on my phone on IRC) ,😀 .... always happy to find a VC timeslot ....
[18:40:31] <jelle> DrZee: hmm is this up to date?
[18:42:15] <jelle> oh good mkinitcpio supports dropin files now
[18:44:14] <jelle> seems this could be supported by http://arch-ami-list.drzee.net but I don't feel like sending AWS money :p
[18:44:15] <phrik> Title: How to build an Arch Linux AMI (at arch-ami-list.drzee.net)
[18:44:43] <jelle> the audit stuff seems custom, but I'm mostly curious about the cloud init things
[18:44:59] <jelle> we don't modify cloud-init at all for our cloud images https://gitlab.archlinux.org
[18:45:00] <phrik> Title: images/cloud-image.sh · master · Arch Linux / arch-boxes · GitLab (at gitlab.archlinux.org)
[18:46:01] <jelle> aws tooling == aws-cli?
[18:49:01] <DrZee> jelle: a few things are a bit outdated and I have updated it ... but mostly yes it's close
[18:49:29] <jelle> seems like only mkinitcpio changes are needed
[18:50:04] <DrZee> jelle: AWS is not as bad as everyone thinks (after all I work there for 12y now) .
[18:50:04] <DrZee> .
[18:50:36] <jelle> sure, work uses AWS for all the things
[18:50:51] <jelle> but I don't have to deal with it :)
[18:52:10] <DrZee> yes Aws tooling mostly refers to the aws-cli wich is a must (not technically a must but its easier if it's already in the image) to run on AWS ....
[18:55:44] <DrZee> I'm not sure if the cloud-init changes are still needed they once where or I would get some errors and cloud-init failed. But since then cloud-init is more robust and has improved.... I just have more important things to do then go back and retool ... the AMI building process is 100% automized and i at most spend 1h/month maintaining it ... it runs on AWS ....
[19:03:21] <nl6720> DrZee: ISOs are not the same as deployable machine images so the considerations are a little different. we're not using grub for the ISO ever again
[19:04:32] <nl6720> archiso does support using grub, but it just brings too many issues
[19:05:45] <nl6720> IMO the biggest issue is: how do you pacstrap across arches?
[19:06:50] <nl6720> well, maybe it's not actually an "issue", since you can just not do that
[19:07:28] <jelle> tbh ISO for arm is gonna work on a few machines
[19:09:32] <nl6720> the ISO format (also for x86_64) is only kept for compatibility with VM software
[19:09:46] <jelle> wut?
[19:10:08] <nl6720> things like VirtualBox want ISOs
[19:10:55] <jelle> you mean not for laptops? or burning? :p
[19:11:47] <nl6720> sure, you can burn it, but rarely anyone does
[19:12:02] <nl6720> most people write it to a USB flash drive
[19:14:03] <DrZee> jelle: if your employer use AWS ... Check if you have access to skillsbuilder.aws ... I see daily the way the industry is going and most larger companies are moving to one of the large hyper scalers like AWS .... what Hetzner or OCS offer are ok if you only want a basic virtual server and some storage .... but the eco system AWS provides (or Azure) is unmatched and allows developers to
[19:14:03] <DrZee> integrate close to the business needs. So if you have the chance to learn about one of the hyper scalers do it ... just my 2 cents with 30y in the it industry.
[19:15:20] <DrZee> nl6720: That's fine just wanted to throw that in there .... IMHO better share what you know/do then holding back and a "nugget" may get lost
[19:16:11] <jelle> DrZee: ami thing looks fine, maybe wCPO can be convinced to support it in arch-boxes :p
[19:16:26] <nl6720> DrZee: I don't mind :)
[19:16:54] <DrZee> wCPO??
[19:17:36] <jelle> DrZee: he maintains arch-boxes, which I linked above, it builds our cloud/basic vm images
[19:18:12] <nl6720> those ^ do use grub, unlike the iso
[19:19:03] <jelle> they use the best bootloader
[19:19:31] * nl6720 is at loss of words
[19:22:05] <jelle> nl6720: dont you like updating your bootloader all the time for security issues
[19:22:17] <DrZee> jelle: For AMIs in Aws they have to be hosted in AWS .... so i just build them there .... you could build 98% of it on any Arch Linux machine but the last step of turning them into an AWS AMI has to be done on/with AWS and access to an AWS Account. And if you want to offer then in all AWS Regions you have to copy them into each region. I do all that fully automated... cost is 6-7usd/month
[19:22:18] <DrZee> and most is the storage cost to have a copy in all the regions
[19:23:19] <jelle> DrZee: aha, you can't just offer it for download to import?
[19:23:27] <DrZee> nope
[19:26:42] <DrZee> check https://docs.aws.amazon.com for the process of launching an virtual machine on AWS it kinda gives an explanation/insight ...
[19:26:44] <phrik> Title: Tutorial 1: Launch my very first Amazon EC2 instance - Amazon Elastic Compute CloudTutorial 1: Launch my very first Amazon EC2 instance - Amazon Elastic Compute Cloud (at docs.aws.amazon.com)
[19:28:35] <DrZee> that was a shit link this is better https://docs.aws.amazon.com
[19:28:36] <phrik> Title: Get started with Amazon EC2 - Amazon Elastic Compute CloudGet started with Amazon EC2 - Amazon Elastic Compute Cloud (at docs.aws.amazon.com)
[19:39:52] <nl6720> gromit: could you please share the output of: xorriso -indev archlinux-*.iso -report_el_torito plain -report_system_area plain -report_el_torito as_mkisofs; fdisk -t mbr -l archlinux-*.iso; fdisk -t gpt -l archlinux-*.iso; gdisk -l archlinux-*.iso
[19:40:17] <nl6720> if the last one asks a question (it shouldn't, IIRC), then choose "2"
[20:09:03] <wCPO> jelle: I’m not sure providing AWS AMIs is worth the “bureaucracy” without anything running at AWS
[20:09:22] <jelle> wCPO: blegh, I thought we could just dump an image which users could import
[20:10:06] <anthraxx|M> DrZee: its a bit of a headache you do not have 'core' or 'extra' repos, can we try to keep the repo layout the same, minus multilib?
[20:10:13] <wCPO> jelle: how do we test it then? We could need a AWS acc I reckon :)
[20:14:52] <DrZee> anthraxx|M: we will most like restructure to that ... but right now it was not a priority. For me maintaining the repos it's not a Biggie to change it and then copy the files into the right "place" .... however I do like the idea of an "any" repo where packages that can run on any arch live so they are not lost in the "extra" jungle .... maybe it could be an idea for the official repos to
[20:14:52] <DrZee> have "any" ... I'll let solskogen make the call though as he does most the building
[20:15:44] <jelle> DrZee: any in extra is not a problem, we hardlinked them in the past
[20:15:59] <jelle> back in the i686/x86_64 days
[20:16:05] <anthraxx|M> DrZee: not really possible, as the repos cant have same package of multiple versions. but ports may be forced to move slower and sometimes tech stacks require specific versions even for any packages. so you need to move a port coherently, and you can't do that with a single generic any repo shared across architectures. its merely there for mirror deduplication.
[20:17:18] <anthraxx|M> DrZee: i don't have an arm environment to actually test all code paths i need to touch for devtools, so the sooner you guys get the structure matching the sooner we can get in devtools support :)
[20:20:13] <gromit> nl6720: "xorriso : FAILURE : Not a known command: 'plain'"
[20:20:14] <DrZee> wCPO: I already have the infrastructure on AWS to build and test the AMIs .... so for now I'm happy to just do that. I'm happy for someone to review the build process and adjust the PKGs I pull in to make them uniform to other images that are provided elsewhere ....
[20:22:52] <DrZee> anthraxx|M: The "any" repo we host is just a copy of the any PKGs from x86 extra we sync it daily at the moment. We have found no issues and they all work on ARM. They are always the same version as x86
[20:25:17] <anthraxx|M> DrZee: not my point though, i was just explaining why sharing an any repository across multiple architectures is deemed futile and wrong. you cannot assume all architectures always move in the same pace, subsequently its just a matter of time until a stack is incompatible. you need to maintain specific versions of any packages for a parcitular architecture, hence there is no real gain in having an any repo but instead you can glue
[20:25:17] <anthraxx|M> them into the native purpose repos core and extra.
[20:25:22] <DrZee> anthraxx|M: can I find your public PGP some where? then I can send you the private key to ash into one of our host on ARM in AWS we use for building. Also need an email to send it to and some basic instructions on how to login....
[20:25:36] <nl6720> gromit: hmm, that shouldn't have happened
[20:25:41] <anthraxx|M> DrZee: probably in the archlinux keyring :)
[20:27:25] <gromit> DrZee: pgp key of anthraxx|M is in archlinux-keyring, but you can also find our staff ssh keys here: https://gitlab.archlinux.org
[20:27:27] <phrik> Title: pubkeys · master · Arch Linux / infrastructure · GitLab (at gitlab.archlinux.org)
[20:27:40] <gromit> anthraxx|M: but you also have access to my hetzner box
[20:28:48] <anthraxx|M> gromit: and how does that solve the mismatching repo names that there is no core and no extra? or am i missing something 😅
[20:29:17] <gromit> anthraxx|M: Nothing, separate point
[20:30:20] <gromit> anthraxx|M: I was answering to "anthraxx|M | DrZee: i don't have an arm environment to actually test all code paths"
[20:33:55] <anthraxx|M> gromit: ok let me rephrase: I dont have an arm environment with the expected alpm repository layout to test all code paths :P
[20:35:20] <DrZee> anthraxx|M: ahh ... well have to coordinate that with solskogen and he seems not to be online right now or he would have chipped in ....
[20:35:59] <DrZee> the offer remains we can give you access no problem.... you can even get you own machine if you want
[20:39:58] <anthraxx|M> DrZee: thanks, i may come back to it. right now gromits boxy is good enough. but i need someone to solve the repo names :P
[20:41:32] <DrZee> anthraxx|M: lets see what the rest of the team says .....
[20:43:56] <DrZee> anthraxx|M: and buy the way ... Day of the Tentacle was one of the last good point and click adventures ever made .... together with Monkey Island ....
[20:44:27] <anthraxx|M> yeah, still all time favorite
[20:53:29] <DrZee> anthraxx|M: just see on you home page where you born .... we made a road trip there (from northern Germany) in 1984 when I was 10 ... coming in from Austria. Driving to Budapest, Puszta, Balaton ... 10 days or so ...
[21:06:52] <gromit> So supposing I'd like to get some arm hardware? Right now I'm looking at an RPI5, any alternatives? I think I heard an Orion board being mentioned a few times now
[21:08:00] <gromit> nl6720: these are the other outputs: https://gist.github.com
[21:08:01] <phrik> Title: gist:42dd503bf11750d37b0db00ff7b244ea · GitHub (at gist.github.com)
[21:10:57] <DrZee> gromit: yeah Pi5 is one option solskogen uses and Orion O6 .... but that one is pricey .... I just use virtual machines