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

Back
[00:17:45] -!- Charon77 has joined #archlinux-ports
[01:19:36] -!- bs86_ has joined #archlinux-ports
[01:20:50] -!- bs86 has quit [Ping timeout: 248 seconds]
[01:20:50] bs86_ is now known as bs86
[01:47:11] <Charon77> bschnei: I noticed in bens.haus there's no firefox (nor its dependencies). It's present in drzee. Anyway I can help? You mentioned there's a VM available? A lot of the dependencies seem trivial (nasm, imake). wasi-* are missing. onnxruntime might be a problem, but it's present on drzee, so we know it builds on arm
[01:47:39] <Charon77> missing deps for firefox: cbindgen imake nasm onnxruntime wasi-compiler-rt wasi-libc wasi-libc++ wasi-libc++abi xorg-server-xvfb yasm
[01:53:36] <bschnei> ya about 1000 packages don't build. many are benign like the hash changed for the source when coming from github. i might have logs for firefox specifically...
[01:54:46] <Charon77> hmm, when I build firefox, it failed even when getting dependency
[01:59:16] <bschnei> https://paste.rs
[02:00:12] <bschnei> disregard. looks like it got cut off
[02:00:30] -!- hcmb_ has joined #archlinux-ports
[02:00:30] hcmb is now known as Guest3320
[02:00:30] -!- Guest3320 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
[02:00:30] hcmb_ is now known as hcmb
[02:01:10] <bschnei> I use drzee's repos to cover missing packages in my build chroots
[02:11:17] <bschnei> https://gist.github.com
[02:11:19] <phrik> Title: gist:72d5047e6fd0732a6a655d1dc9e1875d · GitHub (at gist.github.com)
[02:12:38] <Charon77> I tried building nasm (firefox dependecncy), it's one of the dependency that's not there. builds in like
[02:12:38] <Charon77>
[02:12:38] <Charon77> Do you want me to like push the build somewhere?
[02:13:56] -!- bs86 has quit [Ping timeout: 252 seconds]
[02:16:29] <bschnei> no if it builds I should also be able to build it. if not I have may have issues in my build environment I would need to resolve anyway
[02:17:15] <bschnei> note that firefox may have failed simply due to not having enough mem on my host. it's hard to tell from the logs
[02:19:09] <bschnei> out of curiousity, when you lscpu on your device, what flags do you see?
[02:19:22] -!- bs86 has joined #archlinux-ports
[02:21:25] <Charon77> fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
[02:23:38] <bschnei> crc32 is another one I just discovered is needed by some packages to build (e.g. dpdk)
[02:28:56] <bschnei> nasm added
[02:29:34] <bschnei> actually, it was already there. make sure you are looking at messages for missing deps in the order they appear and work from top down
[02:58:10] -!- greyltc has quit [Remote host closed the connection]
[03:29:06] -!- hcmb has quit [Ping timeout: 246 seconds]
[03:29:17] -!- hcmb has joined #archlinux-ports
[03:32:50] -!- greyltc has joined #archlinux-ports
[05:59:54] -!- Charon77 has quit [Ping timeout: 245 seconds]
[07:00:13] -!- bschnei has quit [Remote host closed the connection]
[07:00:26] -!- bschnei has joined #archlinux-ports
[07:48:36] <yuvadm> bschnei: any notes on bootstrapping your v8 packages from a v8.2 system? I'm gonna try setting up a system on an MNT Reform Pocket (i.MX8MP, cortex-a53)
[07:49:02] <yuvadm> probably requires a patched kernel but otherwise counting on your builds
[07:50:43] <solskogen|M> yuvadm: you need to change makepkg.conf to the "correct" CFLAGS and the pkgbuild for gcc.
[08:04:18] <linkmauve> Ugh, glsl-optimizer has been unmaintained for the past six years…
[08:04:26] <linkmauve> Too bad Firefox uses that…
[08:05:02] <linkmauve> It amounts for most of the warnings in your build log.
[08:05:27] <solskogen|M> but does it build?
[08:06:59] <linkmauve> Probably, otherwise Firefox wouldn’t build in general.
[08:50:24] -!- TheDcoder has quit [Read error: Connection reset by peer]
[08:50:54] -!- TheDcoder has joined #archlinux-ports
[08:59:51] <yuvadm> solskogen|M: thx!
[09:34:18] <linkmauve> BrainDamage, on a rk3566, the difference in performances of AES with and witout the crypto extension is huge: https://paste.sr.ht
[09:34:19] <phrik> Title: Result of ``openssl speed -elapsed -evp aes-256-cbc`` with u-boot+BL31 (TF-A + TF-RK) from 2024.10 vs u-boot 2026.04 + TF-A with and without ARM CE — paste.sr.ht (at paste.sr.ht)
[09:34:42] <linkmauve> It goes from 20~27 MiB/s to 142~896 MiB/s.
[09:34:56] <linkmauve> So I doubt you could saturate a gigabit link without it.
[09:35:25] <linkmauve> Plus those results are on a Cortex-A55, you were talking about a Cortex-A53.
[09:47:55] -!- hcmb has quit [Remote host closed the connection]
[09:48:50] -!- hcmb has joined #archlinux-ports
[10:02:47] -!- filmroellchen has joined #archlinux-ports
[11:08:25] -!- Charon77 has joined #archlinux-ports
[11:12:31] <Charon77> bschnei: sorry for the confusion, I figurred out the chain that fails firefox
[11:13:43] <Charon77> firefox > onnxruntime > nccl
[11:15:21] <Charon77> nccl requires cuda, which requires opencl-nvidia, both of which are available. I want to try building nccl, just to check
[11:15:23] <gromit> Charon77: how is nccl getting involved here?
[11:15:59] <solskogen|M> gromit: required by onnxruntime
[11:16:05] <gromit> Huh, onnxruntime-cpu also requires cuda? :o tpkessler|M ^ why is that?
[11:19:30] <tpkessler|M> gromit: packaging bug 😅
[11:19:45] -!- Charon77 has quit [Ping timeout: 245 seconds]
[11:20:00] <solskogen|M> Does it?
[11:20:18] -!- kitlith has quit [Ping timeout: 248 seconds]
[11:20:21] -!- kitlith_ has joined #archlinux-ports
[11:20:23] kitlith_ is now known as kitlith
[11:20:28] <solskogen|M> I don't see it
[11:20:40] -!- Charon77 has joined #archlinux-ports
[11:21:26] <tpkessler|M> gromit: only as makedepends. That's because it's a split package.
[11:22:05] <tpkessler|M> solskogen|M: Same. The CPU version only requires boost and abseil.
[11:23:06] <Charon77> yes only for makedepends. other fork drops onnxruntime from firefox completely, but drzee repo builds onnxruntime just fine I think
[11:24:56] <solskogen|M> Correct.
[13:18:27] <bschnei> Charon77: nccl added
[14:05:54] <Charon77> I'm trying to understand why onnxruntime can't be built on bens.haus. Turns out they're missing a lot of roc & hip stuffs
[14:06:19] <solskogen|M> which is.. not fun to build.
[14:06:21] <Charon77> Here's the dependency graph in case anyone's feeling like spaghetti https://imgur.com
[14:07:08] <Charon77> solskogen|M: do you know why firefox even use onnx? AI stuffs?
[14:07:42] <solskogen|M> I have no idea why
[14:07:53] <Charon77> alarm got away without onnxruntime
[14:08:34] <solskogen|M> You can just remove it from depends on firefox and see if firefox builds
[14:09:11] <Charon77> oh it says so
[14:09:13] <Charon77> "onnxruntime: Local machine learning features such as smart tab groups"
[14:09:45] <solskogen|M> or edit the pkgbuild for onnxruntime to only build the cpu-part
[14:10:00] <solskogen|M> that's what I did before, until I got cuda and rocm to build on aarch64.
[14:10:36] -!- TheDcoder has quit [Remote host closed the connection]
[14:11:15] -!- TheDcoder has joined #archlinux-ports
[14:11:47] <solskogen|M> now you might see why rebuilding everything isn't as easy as it looks? :-)
[14:13:10] <Charon77> thank you for all of your hard work :D
[14:13:39] <solskogen|M> It has taken a year of my free time
[14:25:22] -!- bill-auger_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
[14:25:40] -!- bill-auger has joined #archlinux-ports
[14:26:37] <Charon77> okay, I made it past configure, it checked for ONNX runtime and we don't have it and it carries on
[14:27:10] <Charon77> I'm not gonna actually build firefox. if bschnei can't do it, neither can I on this machine
[14:27:56] <Charon77> I think what's taking a lot of resource was the profiling guided optimization.... build, run, refine kind of thing
[14:56:14] <bill-auger> Charon77: just FYI the PGO stage needs >50GB RAM-or it will fail or be painfully slow otherwise - skipping the PGO stage reduces the demand significantly and builds in half the time
[15:04:19] <bill-auger> it seems that you are stumbling over issues that have been resolved - re-inventing the wheel so to speak - ppl have been compiling mozilla for ARM for many years - if you were building upon the work from archlinuxarm, you would not have been impeded by those missing dependencies or wondering if it will build without them
[15:06:33] <bill-auger> you may not get much help from that dev team, but you will get working PKGBUILDs, which is really all you need
[15:20:33] <bill-auger> FWIW, i would strongly consider lowering the requirements for arch's ARM port - by simply adopting the work that archarm already has done, arch would get that entire port basivcally for free , could be ready for use in a matter of days - then that could be a solid base to build a 8.2 port onto, if that is still a priority (IMHO it should not be)
[15:22:39] <Antiz> bill-auger: That's is not really feasible (nor desirable really)
[15:25:02] <Antiz> Assuming that "archarm" refers to "alarm", we know little about package builds and infra, expect for the fact that it uses a custom workflow / tooling.
[15:26:54] <solsTiCe> he/she was talking about adopting PKGBUILDs and you are talking aboutinfra
[15:27:10] <Antiz> So simply "merging" alarm upstream as-is is not feasible / out of question. We need a port that fits our workflow and tooling, so it can be integrated cleanly and avoid undesired duplicated work.
[15:27:17] <bill-auger> yes, infra is irrelevant
[15:27:24] <Antiz> Ah my bad
[15:28:05] <Antiz> I thought you meant just merging alarm as-is (as a project)
[15:29:01] <Antiz> Though, the same applies for PKGBUILDs tbh. The goal here is to merge arch specific patches into upstream PKGBUILDs.
[15:29:50] <Antiz> Blindly using alarm PKGBUILDs (or applying their downstream patches) is not really desirable either.
[15:30:13] <bill-auger> i cant imagine what you base that presumtion on
[15:31:30] <Antiz> Well, based on the expectation we (Arch) have established for ports?
[15:31:42] <bill-auger> its not like archarm PKGBUILDs are written from scratch - like most arch derivatives, they are routinely rebased against the analogous arch PKGBUILD, with deltas only which are "arch-specific"
[15:31:58] <Antiz> That is an assumption however
[15:32:54] <Antiz> The current state of alarm is not so clear, sometimes alarming (pun semi-intended). They also target 32bits arch (ARMv7) which we don't want.
[15:33:08] <bill-auger> i dont know what excpectations arch has - can you identify any specific excpectations which archarm PKGBUILDs do not meet ?
[15:33:41] <bill-auger> those point are non sequitors - the PKGBUILDs work - they are all you need - they will save you time period
[15:33:55] <Antiz> This is a different / foreign distro
[15:34:39] <Antiz> We simply don't want to *blindy* adopt work done by a foreign / different distro which may (or may not) be specific to their own workflow / expectations.
[15:34:46] <bill-auger> separate but not foreign - archarm is arch for compiled ARM, nothing more or less
[15:34:47] <Antiz> I don't think this is controversial, is it?
[15:35:17] <Antiz> It as a foreign as any other Arch based / derivatives distributions
[15:35:36] <solskogen|M> Copying them blindly would be a bad choice, since they've introduced some extra variables that upstream Arch doesn't use.
[15:35:51] <Antiz> 👆 Among other things
[15:35:53] <Charon77> I think that's pretty much what I did. I compile firefox, it broke, see how alarm does it, oh they removed onnxruntime. rinse and repeat for other packages
[15:36:06] <Charon77> (not that I'd actually build everything, just checking the common ones)
[15:36:26] <Antiz> bill-auger: Claiming what alarm here and isn't is an assumption (specifically given the very little we know about the project internals).
[15:36:55] <Antiz> That doesn't mean we can't check what they do and taking it as an inspiration (or even "steal" patches from there)
[15:37:14] <Antiz> But *blindly* taking their work is not feasible / desirable.
[15:37:20] <solskogen|M> But take into account that we'll loose 7% or more performance on ARMv8.2-a (and higher) devices by going for ARMv8-a - I'm quite hesitant. That, and building all packages will take a lot of time and effort. If anything, we should then have both ARMv8-a packages and ARMv8.2-A packages.
[15:38:07] <bill-auger> no one adopts code blindly - diff the PKGBUILDs against arch - i expect that you would find that theos diffs are exactly what you would end up with if you redo it from scratch
[15:38:10] <Charon77> I'm kind of out of the loop. what's -a in ARMv8 and how do I know if I'll be invited to the party with my device or not
[15:38:57] <Antiz> "by simply adopting the work that archarm already has done" <-- Sound like you meant just adopting their PKGBUILDs as-is, which is not desirable
[15:39:27] <Antiz> Though if you're willing to do the diff and find patches applied on the alarm that fixes the related issue for us too, than please do
[15:39:34] <bill-auger> solskogen|M: you would lose that performance only on the newer machines - but you would get full performance on many other machines which are now being excluded
[15:39:42] <Antiz> on the alarm side*
[15:39:50] <bill-auger> i do that daily
[15:40:03] <Antiz> Thanks a lot for that then! :)
[15:40:08] <solskogen|M> 7% pr core it quite a lot.
[15:40:37] <bill-auger> not supporting other machines is more
[15:40:46] <bill-auger> that is 0% performance
[15:41:48] <bill-auger> yes i meant only taking the PKGBUILDs -- there is nothing else relevant - they work becuase someone has already done the very same work you are repeating
[15:41:49] <solskogen|M> Sure, but I'm not gonna spend a lot of time getting that to work. If I have my way, we can have both ARMv8-A packages and ARMv8.2-A packages :-)
[15:42:08] <solskogen|M> the same way that (I guess?) there's an effort to provide x86_64-v3 packages.
[15:42:56] <bill-auger> my point is that the time needed to gert that up and running would be minimal, because all recipes are ready to use now
[15:43:01] <solskogen|M> MOST PKGBUILDs will probably work without modification, but there are at least a handfull of PKGBUILDs that work out of the box now (with armv8.2-a) that won't with armv8-a.
[15:44:42] <Charon77> bill-auger: I'm using bens.haus's build which is coming from upstream PKGBUILD. most of the programs I care about already works. chromium works! (it doesn't work in alarm, kind of the whole reason I'm joining this effort)
[15:44:43] <bill-auger> sure, that could be the new work to be done, but the initial v8 port could be done with minimal effort and minimal time - and then that would be the ideal base to start work on 8.2 tweaks
[15:45:38] <solskogen|M> minimal effort and time for you perhaps, but it will require a significant effort and time on my part.
[15:46:11] <Antiz> bill-auger: I get your point and I'm not gonna argue further. I'm just saying that *somewhat blindly* taking stuff from alarm (or any other derivative distro / project) is not the aim here. We wanna ensure that patches we applied are necessary and relevant to us. Stating that "it works on alarm so it has to work on upstream Arch" is an assumption.
[15:46:31] <solskogen|M> and a bad one.
[15:47:43] <bill-auger> ok then you are saddled with answering my question - can you identify any specific excpectations which archarm PKGBUILDs do not meet ?
[15:48:12] <Antiz> Of course not, this is a case by case bases
[15:48:20] <bill-auger> you seem to be aswsuming that something archarm does will not fit arch - i cant imagine what that could be
[15:48:28] <Charon77> not being merged to archlinux's gitlab, not being up to date, not building (chromium for example)
[15:48:29] <Antiz> A ton of stuff
[15:48:51] <Charon77> containing tons of patches because they have to support older instruction sets
[15:48:53] <bill-auger> not being merged? that is exactly what i am suggesting
[15:49:19] <Antiz> What about the rest though?
[15:49:38] <solskogen|M> Other than not working on ARMv8-A, what does ALARM have that we don't?
[15:50:05] <bill-auger> they all sould be merged manually by eye - i was not suggesting to have a machine auto-merge blindly
[15:50:25] <Antiz> This is just more work than working from Arch upstream's PKGBUILD then
[15:50:38] <bill-auger> im only suggesting that you do that before trying to build each package
[15:51:02] <solskogen|M> (and by "we" I mean the work me and my team has done on the aarch64 porting effort)
[15:51:22] <bill-auger> merging in those changes is not more work - the "work" is done - mergin is easy
[15:51:30] <solskogen|M> We've already got a ton more packages ready than ALARM.
[15:51:35] <Antiz> bill-auger: That's also wrong
[15:52:10] <bill-auger> whatever changes you would need to make by trial and error, are probably identical to what you couls simply mergemerge
[15:52:27] <Antiz> PKGBUILDs from alarm may be outdated, containing patches specific to their own workflow / supported instructions set / infra, they may not build at all (I have multiple examples of this), they may do stuff we (Arch) don't want to do.
[15:53:15] <bill-auger> are you sure about that?
[15:53:19] <Antiz> We don't want to base our work from a derivative project that may or may not follow our packaging guidelines, may or may not use are tooling / workflow, etc...
[15:53:24] <bill-auger> can you identify any such ?
[15:54:16] <Antiz> bill-auger: Yes, alarm doesn't use our official tooling, they support architecture we are not targetting, they have PKGBUILDS that do not build (chromium is one of them IIRC), they apply patches we'd like to avoid (or apply differently).
[15:54:46] <bill-auger> tooling and infra are irrelevant
[15:54:52] <Antiz> There python packages PKGBUILDs often lags behind too as they have trouble to catch up
[15:54:56] <solskogen|M> In cases where something doesn't work or build, I've looked at both ALARM and the PKGBUILDs that felixonmars has kindly taken his/her time on for the RISC-V port and used that.
[15:55:37] <Antiz> bill-auger: That's wrong, tooling defines a bunch of things that woudl influence a pkgbuild
[15:56:06] <solskogen|M> if you were to take the PKGBUILDs from ALARM as is, you also risk breaking the package on x86_64
[15:56:23] <Antiz> bill-auger: Stuff like default build flags, dependencies included included by default in the build env, etc...
[15:56:49] <bill-auger> in principle, the infra could affect the build but i would consider that a bug in the recipe - i dont belive you would find anything like that in archarm
[15:57:21] <Antiz> " i dont belive you would find anything like that in archarm" <- Given we know very little about how they do things, this is an assumption.
[15:57:32] <Antiz> Anyway, I'm out
[15:57:46] <phantomas> well alarm has additional variables on top of the standard PKGBUILD, so tooling very much changes things
[15:57:59] <Antiz> Of course it does
[15:58:07] <Antiz> But I'm not loosing my mental sanity over this
[15:58:13] <bill-auger> those default build flags are determined by the pacman recipe - so thats taken care of - default build deps, that is the base-devel recipe so also done for you
[15:58:26] <Antiz> bill-auger: Wrong
[15:58:46] <Antiz> bill-auger: Some sets of default build flags are applied are the tooling level
[15:58:52] <Antiz> Check makepkg.conf / makepkg.conf.d
[15:59:18] <Antiz> And we don't know for sure if alarm use default conf or not on that front for instance.
[15:59:18] <gromit> Antiz, bill-auger: Lets chill a bit, the goal here is cooperation on a shared goal, not being right
[15:59:40] <bill-auger> ok i will need to stay wrong than - didnt mean to linger on this
[15:59:44] <solskogen|M> gromit: have you forgot how internet works?! ;-)
[16:00:13] <Charon77> so uhh, anyone want to tell me if armv8-a is the same as armv8?
[16:00:22] <bill-auger> gromit: i care not about being "right" - only trying to save this project time
[16:00:44] <solskogen|M> Charon77: It's not.
[16:01:18] <bill-auger> if i could convince to lower the 8.2 requirement, i may actually be able to use this port
[16:01:24] <Antiz> gromit: Right, I'm just trying to make sure the goal is actually shared (as merging alarm PKGBUILD is not it 👼)
[16:02:18] <solskogen|M> there's something called ARMv8-A, ARMv8-R and ARMv8-M.
[16:02:46] <solskogen|M> The -M lacks MMU if I recall correctly.
[16:02:50] <Antiz> Anyway, didn't meant to sound abrasive (sorry if that was the case)
[16:04:06] <bill-auger> personally, i dont expect to have such a computer any time in the near future, so im not likely to waste much of your time, as i have no real stake in it
[16:04:12] <Charon77> solskogen|M: so I have A73 and A53, they're armv8-a right? (according to https://developer.arm.com)
[16:04:57] <solskogen|M> bill-auger: As I've said, it IS possible to have both 8 and 8.2 - side by side. But it requires someone to take the time and effort to build for it, and create MRs for things that break. It's not going to be me.
[16:05:20] <solskogen|M> and quite a beefy build machine.
[16:05:42] <Charon77> bill-auger: https://repo.bens.haus this is v8 (not v8.2) and I'm using it right now
[16:05:43] <phrik> Title: Index of /arch/extra/os/aarch64/ (at repo.bens.haus)
[16:06:35] <bill-auger> ok but IMHO 7% seems like a fair price to pay for both - IMHO i would drop the 8.2 goal entirely until the majority of ARM baords in use meet that spec
[16:06:37] <Charon77> I use every part of it (except for the kernel) and I'm really happy with the state, it's definitely usable for my daily activities
[16:06:47] <bill-auger> because that day may never actually arrive
[16:06:48] <solskogen|M> Charon77: yes. But not straight ARMv8-A ;-) They have some extensions that isn't required for ARMv8.
[16:07:02] <Antiz> solskogen|M: Just for my own curiosity, do you know what other distros does on that front?
[16:07:57] <Charon77> solskogen|M: (btw, bens.haus is v8, right? not v8-a)
[16:08:29] <Charon77> so many configurations
[16:08:40] <solskogen|M> Antiz: I /think/ most of them target ARMv8-A, but please don't quote me on that.
[16:09:15] <solskogen|M> Charon77: No, it's ARMv8-A. there isn't a device that is just ARMv8 IIRC.
[16:09:19] <Antiz> solskogen|M: Okay, that's just out of curiosity though. I'm not trying to imply that we should do X or Y
[16:09:32] <bill-auger> i suspect that they target the "lowest-common-denominator" and reject special optimizations, so that users are not excluded simply because they dont have the dough to buy a new machine
[16:10:42] <solskogen|M> Antiz: I understand that. We started out with plain ARMv8-A as well, until we met a closed door with chromium and qt6-webengines.
[16:10:54] <Antiz> solskogen|M: Yeah I remember that
[16:11:08] <bill-auger> same concern as those who want to raise the x86_64 requirement now - all that buys is some percent performance, but at the cost of excludin the majority or users in a fell swoop
[16:11:53] <solskogen|M> chromium takes forever to build, and it was extremely frustrating to only get the error at the very end each time I tried something new.
[16:12:21] <Antiz> bill-auger: As solskogen|M just said the switch to ARMv8.2 was initially made to workaround blockers with specific stuff.
[16:12:49] <Antiz> Is those issues are now resolved (are they?), I guess switching back to ARMv8-A could be discussed.
[16:12:59] <solskogen|M> bill-auger: But I were to create a new distro today, I would never build for x86_64 - I would've chosen x86_64-v3 (which is from 2013)
[16:13:18] <Antiz> Nothing is set in stone yet on that front as far as I know
[16:13:21] <bill-auger> ok then i and most of the ppl in the workd could not use your distro
[16:13:47] <bill-auger> your distro would be a niche distro fotr rich ppl
[16:13:50] <Antiz> (I'm talking about Arch adoption though, not about package builds handled by solskogen|M)
[16:14:22] <solskogen|M> Antiz: I think they are fixed now, yes. That said, there are packages that need modifications to build if we switched. packages that now work out of the box.
[16:14:49] <Charon77> here's the discussion btw: https://gitlab.archlinux.org
[16:14:50] <phrik> Title: Work items · Arch Linux / Ports / AArch64 / project-management · GitLab (at gitlab.archlinux.org)
[16:15:06] <Antiz> solskogen|M: I see
[16:15:18] <bill-auger> yea i still cant login to arch's gitlab - TOTP defeats me
[16:15:39] <solskogen|M> Even if we were to switch to ARMv8-A, that does not mean that everything will work on all ARMv8-A devices. Some packages (crypto) will require the +crc32 extension which not all ARMv8-A devices have.
[16:16:08] <Antiz> solskogen|M: I see, thanks for the details.
[16:16:11] <Charon77> bschnei: mentioned that some packages won't even build without crc32
[16:16:18] <bill-auger> that just the nature of this beast - i call it "the ARM zoo"
[16:16:50] <bill-auger> whatever your griping about now, you will feel htat pain more when it comes time for bootkoaers
[16:17:10] <solskogen|M> Charon77: Correct. And all of a sudden some packages wont work on your device, even if it boots.
[16:17:50] <solskogen|M> bill-auger: what do you mean? we already have grub and systemd-boot working.
[16:18:06] <bill-auger> with every conveivable ARM board?
[16:18:29] <Charon77> you guys have grub? I'm here stuck on depthcharge, dealing with device trees and kernels that have to be put in special region
[16:18:41] <bill-auger> i see now maybe that why the preference - so you can avoid the bootloader jungle
[16:19:03] <linkmauve> solskogen|M, I don’t quite believe there are crypto libraries which mandate the crypto extension.
[16:19:07] <Antiz> To be fair, I don't think it's feasible to consider supporting all boards anyway.
[16:19:09] <solskogen|M> bill-auger: Ofc not. But the devices that we know works, works.
[16:19:19] <phantomas> bill-auger that will likely have to be a package per soc/soc family, but afaik that's out of scope in the same way x86 motherboard/bios/uefi firmware are
[16:19:20] <linkmauve> That would mean they wouldn’t run on the Raspberry Pi until 5, which is quite unlikely.
[16:19:40] <bill-auger> booting is out of scope?
[16:19:46] <phantomas> no
[16:19:49] <linkmauve> You can influence which extensions you use with compiler flags.
[16:19:50] <Antiz> Most distros just have a generic ARM ports, sometimes with RPI specific packages (being the most popular board)
[16:20:08] <solskogen|M> Antiz: Not by a long shot. That's why we love UEFI bootloaders :-)
[16:20:25] <phantomas> bill-auger: primary bootloader are out-of-scope tho
[16:20:37] <linkmauve> Some libs will use runtime detection based on getauxval(), but that shouldn’t prevent them from running on cores which didn’t license the extension.
[16:20:53] <bill-auger> wishes this was audible conversation - i suspect that i would be enjoying it immensely
[16:21:03] <solskogen|M> linkmauve: To compile? yes. Not work :-) It doesn't help if I build a package with +crc when you try to run it on a device that doesn't have it.
[16:21:39] <Charon77> btw I actually switched my gcc-libs to v8.2 because I was dumb and couldn't tell the difference, broke a lot of stuffs including pacman
[16:21:55] <Charon77> but thankfully it runs okay, as long as you close your eyes and ignore the illegal opcodes
[16:22:02] <linkmauve> solskogen|M, that’s why I highly recommend you to not use that flag in your build flags.
[16:22:27] <linkmauve> Even if the vast majority of the cores will have licensed the extension.
[16:22:47] <solskogen|M> GCC is the only package where I have rewritten the PKGBUILD immensely. The current one for x86_64 is way to complicated (and I haven't taken my time to properly fix it)
[16:22:47] <Charon77> my flags (mt8183) fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
[16:23:13] <bill-auger> so literally arch will not provide users with everyting needed to actually boot any ARM board?
[16:23:16] <solskogen|M> linkmauve: Well, that means no openssl for you. Or at least I think it was openssl.
[16:23:44] <linkmauve> solskogen|M, err, openssl obviously works without the extension…
[16:23:46] <Antiz> bill-auger: Are there any distros that does that (serious question)?
[16:23:57] <bill-auger> archarm
[16:24:01] <phantomas> bill-auger: that's not possible
[16:24:06] <linkmauve> It will optionally use it if your CPU supports it.
[16:24:07] <phantomas> alarm doesn't either
[16:24:08] <solskogen|M> Eh.. no.
[16:24:32] <linkmauve> solskogen|M, are you saying that openssl can’t run on a Raspberry Pi 1..4?
[16:24:32] <solskogen|M> linkmauve: then it was some other crypto library. I just don't remember which. bschnei probably does.
[16:24:42] <Antiz> bill-auger: Nah, they don't?
[16:24:57] <bill-auger> archarm has ready-made installl images for many boards and bootloaders for many more
[16:25:12] <Charon77> http://os.archlinuxarm.org
[16:25:18] <linkmauve> All TLS libraries have a software implementation, in C or Rust or any other portable language, and will optionally use CPU or SoC features to go faster.
[16:25:32] <Charon77> uses uboot
[16:25:34] <phantomas> bill-auger: alarm might provides packages and pre-built images for some board, but the generic image doesn't have any primary bootloader
[16:25:51] <bill-auger> of course not - that why it is generic
[16:26:05] <solskogen|M> No. That's not what I'm saying. Not all ARMv8-A devices are missing the crc32 extension. A lot of them have it. But it's not a required extension in order to be called ARMv8-A. It was first a required extension on ARMv8.1-A.
[16:26:14] <bill-auger> but the popular boards are fully bootable OOTB
[16:26:23] <solskogen|M> bill-auger: many is not the same as all.
[16:26:33] <Antiz> Alarm has tarballs for *some* boards
[16:26:35] <bill-auger> i did not suggest "all"
[16:26:36] <linkmauve> solskogen|M, I actually concur with bill-auger, even if you won’t use any of their stuff, you could try ALARM or Debian or Fedora or any other distribution built for AArch64. If none of them ship a specific package it might be broken for that architecture, but it’s very unlikely.
[16:26:43] <Antiz> And I think this is an exception
[16:26:45] <linkmauve> And they all target the bare ARMv8-a ISA.
[16:26:54] <Antiz> Most distros only officially offers a generic ARM port
[16:26:54] <bill-auger> but if it is "none" then i would not expect many users of this port
[16:27:04] <Antiz> Sometimes RPI specific image
[16:27:46] <Charon77> "some" it is then
[16:27:47] <bill-auger> we shuold not care about most distros - this should b at least what archarm is now and could be more - it seems like the aim os for something much much less
[16:28:08] <solskogen|M> linkmauve: Maybe there are patches or some tricks you can use. I don't know.
[16:28:08] <Antiz> I'm not sure why you are defining alarm as a reference
[16:28:35] <Antiz> We never intended to take it as a reference, nor trying to match whatever they are doing.
[16:28:42] <bill-auger> because they have been doing this for a decade, exactly what you are trying to do,
[16:28:44] <phantomas> bill-auger: alarm requires the user to setup u-boot or some similar stuff for *most* board
[16:28:47] <linkmauve> solskogen|M, again very unlikely, but this is all free software so you can have a look at their build process for each package.
[16:28:59] <solskogen|M> bill-auger: Go ahead and get your hands on as many boards as you can, and get them to work. I'll wait.
[16:29:26] <bill-auger> phantomas: that is the usual for ARM, no distro could do any different
[16:29:32] <solskogen|M> I'm not gonna do that for you.
[16:29:40] <linkmauve> I’ve been running my whole infrastructure on ARM for the past twelve years, and besides proprietary software I haven’t had to patch pretty much anything to support this architecture.
[16:29:45] <bill-auger> i have a few and they work
[16:29:47] <Antiz> bill-auger: The point is to an officially supported generic port. This could serve has a base for board specifics ports.
[16:29:47] <linkmauve> Except of course for performances. :)
[16:29:51] <Antiz> to have*
[16:30:03] <phantomas> bill-auger: then it's not different from what this project aims to do on that front
[16:30:07] <Antiz> We never agreed on support specific boards as far as I know
[16:30:35] <Antiz> alarm could continue maintaining tarballs aimed at specific baords if they want to, using the official generic ARM port as a base if they want to.
[16:30:46] <solskogen|M> In other news... I've got 172 packages enqueued to build (and 5 building at the moment) - thanks to KDE and new ROCm.
[16:30:46] <bill-auger> well there are not generic boards im afraid - that statement seems that you are support no actual machines
[16:31:17] <Antiz> ARM is not just for SBC
[16:31:25] <solskogen|M> bill-auger: Our prototype works at least on Pi5, Odroid M2 and Radxa Orion O6.
[16:31:35] <Charon77> I'm using chromebook right now and it works fine
[16:31:39] <solskogen|M> And some Rock 5 and a snapdragon IIRC
[16:31:40] <phantomas> and rock5b/5b+
[16:31:44] <Antiz> We have an ARM server running this port too
[16:31:55] <solskogen|M> And AWS. Yes.
[16:31:58] <linkmauve> bill-auger, the idea is that the user provides u-boot or similar UEFI environment, and then this ports doesn’t have to do anything special to support it, besides compiling the kernel with the relevant drivers and the device-tree for the specific board.
[16:32:05] <Antiz> And Hetzner
[16:32:23] <linkmauve> solskogen|M, you can add ODROID-M1 and Radxa Rock 5B to your list. :)
[16:32:35] <bill-auger> its great that they work in principle, but if you will not provide a way to boot them, they in practice, none work
[16:32:49] <solskogen|M> Who says we don't?!
[16:32:51] <linkmauve> bill-auger, I just told you how it works.
[16:32:53] <Charon77> of course, anyone could borrow alarm's uboot https://github.com and others
[16:32:54] <Charon77> but it's not a priority
[16:32:55] <phrik> Title: PKGBUILDs/alarm/uboot-raspberrypi/PKGBUILD at master · archlinuxarm/PKGBUILDs · GitHub (at github.com)
[16:33:01] <solskogen|M> Wtf man
[16:33:34] <Charon77> ?
[16:33:46] <Antiz> Specific kernels / drivers could live in the AUR FWIW
[16:34:19] <solskogen|M> I very much agree. And as soon as mainline works properly on the Pi5, the Pi5 kernel will be thrown to the AUR as well.
[16:34:48] <bill-auger> > <phantomas> bill-auger: primary bootloader are out-of-scope tho
[16:34:59] <phantomas> As I understand it, the port RFC allows board-specific packages for bootloaders
[16:35:05] <bill-auger> so by "out-of-scope" i assume that means, "we aint gonna"
[16:35:44] <solskogen|M> Why would you assume that?
[16:35:58] <solskogen|M> What purpose does it give you to assume something so stupid?
[16:35:59] <bill-auger> because that what "out-of-scope" means
[16:36:30] <solskogen|M> No, it doesn't.
[16:37:03] <solskogen|M> But again, talk is cheap. If you want to help, help. You're not helping, bill-auger
[16:38:31] <phantomas> bill-auger: It may not have been worded properly on my end. As far as I understand it, the first goal is to have the OS as a whole aligned with x86-64. Then maintainer/user with the specific know-how and hardware can add their packages on aur, or directly on arch repo.
[16:38:36] <bill-auger> im help the most i can by offering insights - i am machine spec'ed out of the game remember
[16:38:38] <linkmauve> A good way to help, based on what you mentioned, would indeed be to look at the differences for each package which doesn’t build between ArchLinux upstream and ALARM’s PKGBUILDs.
[16:39:04] <linkmauve> bill-auger, no, as Charon77 mentioned, there is an ARMv8 port ongoing.
[16:39:24] <bill-auger> ok i understand tht now - bootloaders will be in the AUR
[16:39:32] <linkmauve> Just lacking some 1000 packages currently.
[16:39:47] <linkmauve> You might want to go through these and figure out why they don’t build.
[16:41:11] <Charon77> bill-auger: v8 here btw https://repo.bens.haus what's your machine?
[16:41:41] <bill-auger> ive a pinebookpro and a olimex teres
[16:43:13] <Charon77> if you have alarm already set up, you can just change [extra] repository for testing, no need to change everything until the boot loader
[16:44:04] <Charon77> I'm using [core] and [extra] from the project. I'm not changing the kernel because I have some weird quirks
[16:46:01] <Charon77> solskogen|M: > And some Rock 5 and a snapdragon IIRC
[16:46:01] <Charon77> you talking a snapdragon SBC, or a specific device? I'm gonna put it on the list
[16:47:30] <bill-auger> id need to start fresh - they both running armbian now - but i am enthused
[16:48:41] <Charon77> I assume that enthusiastic but exhausted ;)
[16:49:02] <bill-auger> oh yea all dat
[17:23:43] <Charon77> I have a docs MR on the project's overall status, feel free to take a look
[17:23:44] <Charon77> https://gitlab.archlinux.org
[17:23:45] <phrik> Title: AArch64 docs rewrite (!10) · Merge requests · Arch Linux / Ports / docs · GitLab (at gitlab.archlinux.org)
[17:31:10] <linkmauve> Charon77, someone said the other day to keep the trailing spaces at the end of lines which shouldn’t get a newline after them.
[17:33:51] <phantomas> I'm pretty sure it's the other way around. IIRC markdown ignores merges lines together before rendering, but you can add an explicit new-line by leaving two spaces at the end of the line
[17:34:03] <phantomas> s/ignores//
[17:35:23] <Charon77> sure thing
[17:36:37] <phantomas> Charon77: on the rendered version, you can see the effect it has on the "Status" and "RFC" lines: https://gitlab.archlinux.org
[17:36:38] <phrik> Title: content/aarch64.md · aarch64_docs_rewrite · Evans Jahja / docs · GitLab (at gitlab.archlinux.org)
[17:36:42] <linkmauve> Oh, I see.
[17:42:54] <Charon77> Thank you, so two space 'Unofficial '
[17:42:54] <Charon77> I didn't know about this.
[17:42:55] <Charon77>
[17:42:55] <Charon77> I think linter complained that's why it was removed but it's clearly important
[17:49:14] <solskogen|M> Charon77: It was a laptop, I just don't remember which.
[17:49:52] <fermino> Hey guys, idk if anyone sent it before but, is there a list of failing packages so I can grab some of them and give them a shot?
[17:50:37] <solskogen|M> fermino: Not really. Most just works. We're missing haskell.
[17:51:43] <solskogen|M> But! One thing someone should do (not me!) - is to port linux-lts, linux-hardened,linux-rt, linux-rt-lts and linux-zen.
[17:52:34] <solskogen|M> You will also find python-pytorch in packages, but the hack that I did is so ugly I don't want anyone to see.
[17:53:23] <solskogen|M> I do have a blacklist.txt used by my build system, but that is mostly packages that doesn't make sense on aarch64 in the first place.
[17:53:36] <fermino> There's nothing more permanent than a temporary fix xD
[17:54:24] <solskogen|M> Heh, well. The idea is that a fix should be able to be merged into upstream PKGBUILD. Which means that the package must build (and work) on both aarch64 and x86_64. Good luck!
[17:55:25] <solskogen|M> So, if anyone can fix this please: https://gitlab.archlinux.org
[17:55:26] <phrik> Title: release fails when subpackages are intentionally missing (#305) · Issues · Arch Linux / devtools · GitLab (at gitlab.archlinux.org)
[17:59:56] <Charon77> solskogen|M: have we consider... building $pkgbase-dtbs even under x86_64? could even be an empty folder
[18:01:02] <solskogen|M> Last time I tried something for the kernel I broke a lot. I'm giving my self a hiatus for that :-)
[18:01:46] <solskogen|M> In other words, please try!
[18:06:23] <solskogen|M> I mean, I want people to experiment as much as possible. Not much is set in stone on how to do things.
[18:13:25] <Charon77> yeah, I'm just thankful alpm is so flexible from the get go w.r.t multiple arch, I'll think about it
[18:14:03] <Charon77> I just packaged my first bin AUR package with x86_64 and aarch64
[18:14:39] <Charon77> so annoying how some people call it arm64 while others call it aarch64
[18:16:18] <Charon77> anw it's 3 in the morning here, gnite y'all
[18:39:05] <bschnei> While it's not documented anywhere, it's important to understand that one of the reasons solskogen, drzee, and I are here at all is because we were not happy with a variety of things at ALARM. As a result, from the very beginning, it was never our intention to build a substitute to ALARM. That includes what devices might be supported, what packages can get built, etc. etc. While we did use their work on packages as a re
[18:39:06] <bschnei> ference very early on when we were just naively trying to build a basic system, ALARM long ago became largely irrelevant for the purposes and goals we have here.
[18:41:26] <bschnei> Said another way: we've definitely been able to benefit massively from the work there already, but when packages aren't building for whatever reason, it rarely has the answers anymore.
[18:43:12] <fermino> Found a little gem for us messing with embedded: https://github.com
[18:43:13] <phrik> Title: GitHub - tio/tio: A serial device I/O tool · GitHub (at github.com)
[18:44:41] <bschnei> https://aur.archlinux.org
[18:44:42] <phrik> Title: AUR (en) - tio (at aur.archlinux.org)
[19:35:10] <bill-auger> bschnei: just IMHO, given that archarm is what it is, the significant benefit of arch supporting ARM, is that arch will readily accept contributions and bug reports from users
[19:38:30] <fermino> I really hope this takes off, the price point is really good having in mind the current RAM situation http://www.orangepi.org
[19:38:31] <phrik> Title: OrangePi Zero 3W-Orange Pi | OrangePi (at www.orangepi.org)
[19:39:14] <fermino> 12GB RAM at 105 bucks
[20:03:00] <solskogen|M> Charon77: welcome to the club. nvidia has another name: sbsa-linux
[20:45:44] -!- TheDcoder has quit [Read error: Connection reset by peer]
[20:46:05] -!- TheDcoder has joined #archlinux-ports
[21:26:53] <bschnei> bill-auger: Arch does accept non-x64 contributions as outlined here: https://ports.archlinux.page note that work items (issues/bugs) for non-x64 architectures is currently out of scope.
[21:29:59] <bschnei> Issues with aarch64 packages can be raised here or against the forks of the packages in solskogen or my personal gitlab namespaces. We will often have a fork with an "aarch64" branch. I'd actually prefer for issues to be raised there vs IRC
[22:10:16] -!- titus_livius has joined #archlinux-ports
[22:30:09] <bschnei> Charon77: you mentioned chromium works on v8. What desktop environment did you install? With ~1k packages missing I'm kinda surprised to hear you made it that far. I only daily drive a barebones headless system on the packages in my repo so most of them have never actually been run by anyone ever.
[22:45:39] -!- marmis has quit [Quit: Bye!]
[22:47:32] -!- marmis has joined #archlinux-ports
[22:49:13] -!- marmis has quit [Client Quit]
[22:51:04] -!- marmis has joined #archlinux-ports