#archlinux-ports | Logs for 2026-04-19

Back
[00:03:47] -!- greyltc has joined #archlinux-ports
[00:45:25] -!- greyltc has quit [Remote host closed the connection]
[02:17:00] -!- Charon77 has joined #archlinux-ports
[02:55:14] <Charon77> bschnei: I hit the same firefox issue as you
[02:55:26] <Charon77> it's definitely not memory issue
[02:57:10] -!- greyltc has joined #archlinux-ports
[03:27:11] -!- hcmb_ has joined #archlinux-ports
[03:27:11] hcmb is now known as Guest3366
[03:27:11] -!- Guest3366 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
[03:27:11] hcmb_ is now known as hcmb
[05:35:22] <Charon77> bschnei: let's track firefox issues on v8 here https://gitlab.archlinux.org
[05:35:23] <phrik> Title: (armv8) firefox not building (#9) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[05:36:41] <Charon77> I'm trying to rebuild llvm-libs with debugging symbols
[07:22:45] <solskogen|M> oh, hang on. I try setting this: export MOZ_HEADLESS=1, after export MOZ_NOSPAM=1
[07:28:15] <Charon77> solskogen|M: Sure let me try that. I don't think it's documented anywhere, maybe you could put it on the work items? I'm not sure how many PKGBUILDs you needed to modify
[08:07:16] <Charon77> Bringing fermino 's discussion here:
[08:07:17] <Charon77> Given that aarch64 is ambiguous here, would it make sense to try to standardize towards a different naming scheme right from the start? I guess there is the same issue for x86_64 arch levels (and it certainly would require tooling changes as this field is currently taken from uname -m).
[08:13:38] <Charon77> I'm trying to wrap my heads around the glossary, maybe someone could help out.
[08:13:38] <Charon77> So ARMv8 is the architecture
[08:13:38] <Charon77> it has 32-bit instruction STATE AArch32 and 64-bit instruction STATE AArch64.
[08:13:38] <Charon77> AArch32 instruction state contains A32 an T32 instruction SET
[08:13:38] <Charon77> while AArch64 instruction state contains A64 instruction set.
[08:14:08] <Charon77> So armv8 would be an architecture.
[08:15:32] <Charon77> `uname -m` is ancient and probably shouldn't be treated as containing correct definition, especially with arm odditites. From the manual:
[08:15:32] <Charon77> "-m --machine print the machine hardware name"
[08:18:19] <Charon77> armv8.2 is an architecture extension, "It adds mandatory and optional architectural features."
[08:18:19] <Charon77> so because these are mandatory, I think it makes sense to distinguish armv8/, armv8.2/
[08:26:10] <Charon77> If we want to use 'aarc64' in the name, we can follow:
[08:26:10] <Charon77> "An Armv8-A implementation can be called an AArchv8-A implementation and an Armv9-A implementation can be called an AArchv9-A implementation."
[08:26:10] <Charon77> https://developer.arm.com
[08:26:12] <phrik> Title: Documentation – Arm Developer (at developer.arm.com)
[09:45:41] <solskogen|M> what do you mean "If we want to use 'aarc64' in the name" ? what name?
[10:07:07] <Charon77> sorry disregard that
[10:31:06] <solskogen|M> are there cases where a package doesn't go into -testing before moved to the stable repos?
[10:35:34] <bertptrs> in core, no, in extra, all the time
[12:35:43] -!- TheDcoder has quit [Read error: Connection reset by peer]
[12:36:04] -!- TheDcoder has joined #archlinux-ports
[13:01:24] <Charon77> Anyone with armv8, could you tell me what cpu flags you have?
[13:01:32] <Charon77> mine "fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid"
[13:03:25] <BrainDamage> fp asimd evtstrm crc32 cpuid, I am using a vanilla kernel tho
[13:03:34] <BrainDamage> which only supports a subset
[13:48:45] -!- greyltc has quit [Remote host closed the connection]
[13:56:31] -!- greyltc has joined #archlinux-ports
[14:11:18] <solskogen|M> <foxboron|M> "Ref all the patches adding a..." <- Why do you add append_once GOARCH "arm64" when $CARCH is x86_64? :)
[14:21:50] <solskogen|M> Foxboron: I just want you be aware that your messages does not appear in IRC.
[14:29:10] -!- foxboron|M has joined #archlinux-ports
[14:29:11] <foxboron|M> Should probably work now?
[14:30:36] <solskogen|M> It does!
[15:34:03] <Charon77> solskogen|M: okay, firefox with PGO builds on v8-a, just with the MOZ_HEADLESS=1 addition that you mention. I'm still curious why it crashed previously, probably want to dig deeper. I saw other distro use tinywl (xvfb but wayland) for profiling, wonder if it's going to fit people's usecase more
[15:34:10] <Charon77> https://imgur.com evidence :)
[16:14:42] -!- greyltc has quit [Ping timeout: 248 seconds]
[16:16:58] -!- greyltc has joined #archlinux-ports
[16:24:04] <bschnei> hey Charon77, let's keep the https://gitlab.archlinux.org space for non-package specific (i.e. general arm porting) issues. I know there isn't really a dedicated place currently for keeping track of package specific issues, but there are so few of us working at the moment that it hasn't really been a priority to figure that out :)
[16:24:05] <phrik> Title: Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[16:24:48] <bschnei> more to come on this. I'm working on doc updates. for now if you have package issues, i think it's fine to just raise them here
[16:26:18] <bschnei> alternatively, if you know it is due to missing features/flags (i.e. crc, lse, v8 vs v8.2 etc.) you can add to the discussion at the existing issue (which I also sorely need to update): https://gitlab.archlinux.org
[16:26:19] <phrik> Title: Determine which instruction set to support (#6) · Issues · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[16:26:36] <bschnei> crc needs to get added....
[16:33:11] <bschnei> re: naming I think makepkg/PKGBUILDs simply use what gcc uses. So it is signficantly broader-in-scope discussion to consider changing that somehow. What ultimately matters most of the time is what march is set to by makepkg.conf. Possible values and their meanings are documented here: https://gcc.gnu.org
[16:33:13] <phrik> Title: ARM Options (Using the GNU Compiler Collection (GCC)) (at gcc.gnu.org)
[16:35:19] <bschnei> ^ this is where armv8-a, armv8.2-a, etc. are "coming from". you'll note its also possible in may cases to add very specific feature (like CRC!) to ARMv8. The double-edged sword of letting manufacturers pick and choose which features to implement...
[16:37:54] <bschnei> It's worth noting too that the absence of some of these features comes with a performance penalty. dpdk won't build without CRC, but that doesn't mean it can't be worked around...it just means cycles are spent performing the needed operations in software instead