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

Back
[01:05:50] <fermino> Whose key is 0CF25682E6BA0751?
[01:07:18] <fermino> Nvm, found it
[01:41:16] <Charon77> fermino: thanks! I might use it for this chromebook, since I often need to connect to a serial port embedded in the same machine
[01:41:30] <fermino> <3
[01:42:11] <fermino> <rant> Someone thought it was a good idea to chainload uboot(oem, 2017) -> uboot(2024) -> kernel, I was way too excited when I first saw the 2024 build</rant>
[01:44:21] <Charon77> solskogen|M: wtf is sbsa-linux or even sbsa... some kind of compatibility contract across arm products or something?
[01:57:03] <Charon77> bschnei: morning
[01:57:21] <Charon77> bschnei: I use niri. it's a scrolling tiling compositor. https://github.com it's on wayland
[01:57:22] <phrik> Title: GitHub - niri-wm/niri: A scrollable-tiling Wayland compositor. · GitHub (at github.com)
[01:57:57] <bschnei> very nice. ok that makes more sense. i'd be surprised if a heavyweight DE actually works
[02:00:08] <bschnei> i'm actually going to sleep here. i'm normally on US pacific time, but am Eastern at the moment
[02:01:06] <Charon77> bschnei: let me dump some messages before you leave
[02:01:25] <Charon77> firefox fails because it's missing onnxruntime, it's a mess: https://imgur.com
[02:01:57] <Charon77> it's only used for "Smart tabs" feature, not so important, will consider creating pkgbuild of firefox without onnxruntime
[02:02:51] <bschnei> fermino: I encourage everyone as much as practical to flash a modern u-boot build where the devicetree is baked in, use it to chainload systemd-boot/grub via UEFI, and then forget u-boot even exists. my ARM experience has been quite pleasant the moment I didn't have to interact with u-boot to boot different kernels
[02:03:50] <Charon77> I tried asking pacman to install kde, it doesn't work because it's missing dolphin, kio-extras, libvlc stuffs, clang21
[02:05:21] <bschnei> Charon77: sure. I don't know why onnxruntime didn't build but can look into it in a couple days. Bear in mind, such a change would not currently be something you could submit upstream because it removes x64 functionality and that is explicitly out of scope at the moment. Re: KDE that sounds right...
[02:05:41] <fermino> I will give it a try, worse comes to worst I have an SPI reader to restore a backup. There seems to be an android build in the MMC that handles charging when "powered off" so I guess that's why they kept the old version
[02:06:24] <Charon77> Isn't it possible to have different makedepends for aarch64 and x86_64?
[02:06:25] <bschnei> ah interesting. you may have to check if it ever got upstreamed....
[02:06:33] <fermino> I'm starting off jelos/rocknix as a known working system; I still haven't figured out how they bundle uboot but I'm thinking about just trying to build it and give it a shot
[02:07:59] <bschnei> Charon77: yes, but there should be a compelling reason. For all I know onnxruntime simply needs more resources than my host has to build. I haven't looked into it...
[02:08:05] <fermino> I think it might have... There was a lot of movement around the rk3566 around two years ago when things started getting mainlined in the kernel, so I'm crossing my fingers
[02:08:24] <Charon77> btw about your out of memory issue on compiling firefox, it's because of profiler guided optimization
[02:08:37] <Charon77> someone on the channel says you need 50GB if you turn it on
[02:08:44] <Charon77> 50GB of RAM that is
[02:08:47] <fermino> ._.
[02:09:04] <Charon77> but you can turn PGO off and it will compile like really fast
[02:10:10] <Charon77> PGO = compile browser with tracing, run with xvfb and actually have it render stuffs, recompile browser with the result
[02:10:18] <Charon77> your firefox build log fails during profiling
[02:11:06] <bschnei> drzee would know better but the cloud ARM resources availale now and in the near future should render any current resource constraints irrelevant
[02:12:04] <Charon77> I see. PGO is even more important for arm devices
[02:14:01] <Charon77> onnxruntime not building: I attached an image. that should be all of the missing dependencies (mostly rocm stuffs)
[02:14:33] <Charon77> solskogen built onnxruntime with cpu only
[02:14:51] <bschnei> rocm stuff is notoriously heavy
[02:16:11] <bschnei> https://en.wikipedia.org 192 cores on the horizon from what I understand...
[02:16:12] <phrik> Title: AWS Graviton - Wikipedia (at en.wikipedia.org)
[02:16:22] <bschnei> (not in the region we use currently)
[02:17:39] <Charon77> even my day job is switching to graviton, I heard it's cheaper
[02:28:32] <bschnei> We don't have docs for it at the moment, but anyone serious about chipping away at packages they care about (whether for v8/8.2 or whatever march flavor you love) really should consider a cloud VM. Hetzner has small, cheap VMs that are v8.2. It is a bit of a slog to bootstrap from their recovery system but it is entirely possible to do. The reason I keep mentioning this is because no matter how good your physical ARM de
[02:28:33] <bschnei> vice is and how small the package you care about is, you will wind up resource constrained if you don't want to be forever maintaining what effectively is a fork of Arch (or some subset of its packages). That situation is a lot easier to remediate when your resources are virtual instead of physical.
[02:31:20] <Charon77> bschnei: can you outline what to do? I know you've mentioned it several times, but it's unclear. Do we build packages and upload to bens.haus for example?
[02:32:02] <Charon77> the goal here is to have people helping, but not doing duplicate work
[02:40:05] <bschnei> 0) identify a missing or outdated package, 1) try to build it (where you need a build environment), 2) if it builds, let us know!, if it doesn't, figure out why. Is it an unmantained upstream project that hasn't kept up with gcc15 standards and needs minor patches to work again? A bad checksum (extremely common)? A check that fails? etc. 3) determine if the issue is aarch64 specific or general. if general, you can at le
[02:40:05] <bschnei> ast raise a Work Item (fka Issue) on gitlab for the package to make the maintainer aware that the package doesn't even build for x64. Even better is if it is an issue you are capable of resolving yourself and you can send a MR (please see the Arch wiki for guidelines on MRs). If aarch64 specific you'll have to dig a lot further: does upstream even claim they support aarch64? Has an issue already been raised but hasn't b
[02:40:06] <bschnei> een released yet? (common). It is exactly what it sounds like: package maintenance :)
[02:43:07] <bschnei> The other area we can use contributions is device support. Even your confirmation that you can boot a chromebook is very helpful. If you are capable of going beyond and seeing if the linux kernel we package works on different devices and submitting MRs for our kernel config to fix devices that don't boot (or have missing drivers) then that's even better
[02:44:48] <bschnei> on 0) above...if packages on my personal site are outdated...don't let me know...i know they are :) I only use a small subset of the ones that are there. I get around to building the ones I don't use...whenever I get around to it :)
[02:49:05] <fermino> So if I understood it correctly, is everyone sort-of maintaining its own repo rn?
[03:03:33] <bschnei> drzee.net repos are the only documented and well maintained repos that exist thanks to drzee and solskogen
[03:05:33] <Charon77> bschnei: for bens.haus, is there a repo where we could create work items?
[03:06:19] <Charon77> for example I could create: firefox needs onnxruntime transplant from drzee, needs more memory because PGO
[03:06:41] <Charon77> because these are definitely our build specific
[03:06:47] <bschnei> the ports.archlinux.page really does do a pretty good job of describing the current state. it needs a bit of work but it's worth reading carefully to understand where we are at
[03:07:39] <Charon77> fermino: regarding ports archlinux: btw here's my MR for more details on our current state https://gitlab.archlinux.org
[03:07:40] <phrik> Title: AArch64 docs rewrite (!10) · Merge requests · Arch Linux / Ports / docs · GitLab (at gitlab.archlinux.org)
[03:08:36] <bschnei> hmm that just strikes me as Firefox is missing for v8 being the issue. but as I've said...v8 is my own personal experiment. it is not documented. it is not supported. it is just there. if it helps you... awesome...but don't expect anything from it so to speak
[03:09:07] <bschnei> tomorrow I could decide to take it all down
[03:09:57] <bschnei> the surprise is that it actually works for you :)
[03:10:48] <Charon77> I'm equally surprised :D
[03:13:11] <Charon77> fermino: I guess the point is not to trust these builds too much, because the source of truth is archlinux's pkgbuild.
[03:15:08] <bschnei> ...well arguably you should trust them more then :) but you probably mean in terms of stability etc in which case ....yes... absolutely. unofficial means... unofficial. expect nothing to go right and you won't be disappointed! :)
[03:17:30] <bschnei> it is a lot of fun though. you just missed us breaking the kernel for all of our users!
[03:22:47] -!- Daanct12 has joined #archlinux-ports
[03:25:31] -!- Daanct12 has quit [Client Quit]
[03:28:13] -!- hcmb_ has joined #archlinux-ports
[03:28:13] hcmb is now known as Guest1086
[03:28:13] -!- Guest1086 has quit [Killed (iridium.libera.chat (Nickname regained by services))]
[03:28:13] hcmb_ is now known as hcmb
[03:33:31] -!- Daanct12 has joined #archlinux-ports
[03:36:34] <fermino> I'm just trying to get a feel for how helpful would be trying to automate stuff without spending a ton of time doing what folks are already doing in buildbtw
[03:36:43] <fermino> @Charon77, thx for the link, i'll take a look
[03:43:01] -!- Charon77 has quit [Remote host closed the connection]
[05:14:28] <fermino> There we go :) >> U-Boot 2026.04 (Apr 17 2026 - 23:51:44 -0300)
[05:15:48] <fermino> Rockchip's boot process is surprisingly decent; it tries to boot from _everything_, at an offset
[05:16:05] <fermino> So as long as you have access to a removable media there's really no way to brick it
[05:21:34] <phantomas> fermino: it really depends on your SoC, and the nature of your bug
[05:24:37] <phantomas> On a few SBCs if you install the bootloader on SPI-flash and something has an issue after the initial check, the device is bricked until you re-flash via maskrom
[05:31:15] <fermino> Ohh, right, because the bootloader is actually being executed, that makes sense
[06:01:03] <phantomas> yep. Whenever possible, keeping the bootloaders on a removable media effectively avoid that risk to
[06:30:29] -!- marmis has quit [Quit: Bye!]
[06:57:48] -!- Charon77 has joined #archlinux-ports
[08:11:03] -!- drathir_tor has quit [Ping timeout: 265 seconds]
[08:12:58] -!- drathir_tor has joined #archlinux-ports
[09:19:34] <linkmauve> bschnei, what did you find unpleasant in using u-boot, compared to systemd-boot and grub? The first two even use the same configuration file.
[09:20:48] <linkmauve> Charon77, re onnxruntime, have you tried disabling its rocm dependency?
[09:22:02] <Charon77> onnxruntime - I haven't, I'm trying to get a cloud vm on oracle. seems like everyone's fighting for the resources (wish me luck)
[09:22:15] <Charon77> but solskogen built cpu-only onnxruntime so I know that'd work
[09:22:26] <linkmauve> bschnei, whether your build machine is in a VM on someone else’s computer, or on your desk, the resources are finite anyway.
[09:23:03] <linkmauve> And my Oracle Clown VM isn’t much faster than my Rock 5B, and I expect them to become equivalent once I get a heatsink for it.
[09:24:13] <Charon77> how much RAM on your rock5b?
[09:24:18] <linkmauve> 8 GiB.
[09:24:40] <linkmauve> Vs. 24 at Oracle, but I’ve never used that much, even 8 is a lot for just 4 useful cores.
[09:25:44] <linkmauve> I tend to avoid the Cortex-A55 for compilation, because they produce more heat than they contribute towards the build, in my very unscientific benchmarks of building some packages I care about.
[09:26:02] <linkmauve> So -j4 instead of -j$(nproc).
[09:26:29] <Charon77> oh that's because arm uses what's it called.. small big?
[09:26:47] <Charon77> sorry. `big.LITTLE`
[09:27:26] <linkmauve> big.LITTLE yeah, the small cores are power efficient at not doing much, but worse at churning through a lot of code.
[09:27:56] <Charon77> I put this on my udev rule:
[09:27:56] <Charon77>
[09:27:56] <Charon77> KERNEL=="cpu"
[09:27:56] <Charon77> ATTR{cpufreq/scaling_governor} = "schedutil"
[09:28:24] <linkmauve> I don’t know much about schedulers, I have no idea what to do with those, I generally use the default one.
[09:28:48] <Charon77> That's the only scheduler that makes sense for big.LITTLE. Let me see if I can find the original post
[09:31:01] <Charon77> https://docs.kernel.org
[09:31:02] <phrik> Title: Schedutil — The Linux Kernel documentation (at docs.kernel.org)
[09:36:16] <Charon77> (in any case you're right, just set -j4)
[09:37:34] <phantomas> linkmauve: [8 is a lot for just 4 useful core] that depends a lot on the task. For building I'd argue this is just false.
[09:38:40] <phantomas> I had ld oom-killed while building some rust-based compositor with 4GB of ram
[09:39:15] <Charon77> niri?
[09:39:34] <phantomas> amongst other :)
[09:40:09] <phantomas> rust "we'll elide everything during lto" means intermediates blobs are huge
[09:40:22] <linkmauve> Interesting, I have yet to experience that!
[09:40:47] <linkmauve> Although, I’ve had to drop to -j3 for sunshine, a C++ monster eating all of my memory otherwise.
[09:41:12] <linkmauve> phantomas, that’s only if you (the project) pass lto = true, otherwise it doesn’t use LTO by default.
[09:42:03] <phantomas> linkmauve: not quite. Disabling LTO doesn't remove symbol ellision
[09:42:13] <phantomas> it helps tho
[09:43:17] <linkmauve> What is symbol elision? Removal of some symbol if it isn’t called by main() or any of its descendents?
[09:43:32] <Charon77> had to disable lto to avoid oom as well.
[09:43:32] <linkmauve> I haven’t heard of Rust doing that!
[09:43:58] <Charon77> iirc rust remove unused symbols that are not main and not public
[09:44:01] <phantomas> in my case it wasn't enough, but zram came to the rescue :D
[09:44:33] <Charon77> zram definitely helps!
[09:44:43] <linkmauve> Charon77, it doesn’t even build them AFAIK.
[09:45:02] <linkmauve> That’s why you get a warning if a crate doesn’t use one of its non-pub symbols.
[09:45:12] <linkmauve> zram is amazing!
[09:45:41] <phantomas> Charon77: linkmauve: a bit of both. Deadcode is removed when building intermediate blobs, then at link-time unused symbols are removed.
[09:46:02] <phantomas> which is good because the standard is to build everything statically
[09:46:07] <Charon77> oh right. dead code on the codegen unit can be eliminated
[09:48:00] <linkmauve> phantomas, those unused symbols are pub ones which didn’t get any reference from the tree spanning from main()?
[09:48:03] <linkmauve> Makes sense!
[09:48:19] <linkmauve> I doubt that pass is taking any serious amount of memory though.
[09:48:45] <phantomas> OTOH intermediate blobs are bigger than C++ ones, which makes me wonder if rustc emit all symbols for generics. Another possibility is that it always emit a shit-ton of symbols for the linker
[09:50:30] <phantomas> linkmauve: [this pass is taking any serious amount of memory] enough to fill up 4GBs :D
[09:50:36] <linkmauve> phantomas, generics work the same way in C++ and Rust: the generic LLVM-IR is kept in the translation unit, and the code gets generated in the one using it.
[09:50:49] <Charon77> +1
[09:51:30] <linkmauve> phantomas, that’s probably some other pass, just looking at unused symbols is a colouring tree task which uses one bit per symbol. ^^'
[09:51:53] <phantomas> yeah, but the symbols need to be loaded
[09:52:39] <phantomas> linkmauve: iirc c++ templates aren't even emitted as IR if they are unused
[09:53:00] <phantomas> but don't quote me on that
[09:54:44] <phantomas> SFINAE requires that potentially invalid code must be ignored. They have to be syntactically valid, but I'm not sure if actual IR can be emitted
[09:57:23] <phantomas> [probably some other pass] maybe :) I haven't looked deep into the issue. I did try disabling lto but that didn't help
[10:01:56] <phantomas> but anyway, the point remains that "1GB per core" is a decent rule of thumb for a generic user, but for anything more specialized (e.g. compilation of big projects, scientific stuff, 3D rendering), it doesn't always holds true
[10:26:43] -!- filmroellchen has joined #archlinux-ports
[11:17:54] <bschnei> linkmauve: on my device, I could only interact with u-boot over serial. mfg shipped with broken UEFI support so trying to get different kernels to boot meant serial console to u-boot to muck around with config. re: VM resources, yes, of course, but vertical scaling is usually a lot easier when it's virtual :)
[11:26:02] -!- Daanct12 has quit [Ping timeout: 248 seconds]
[13:40:39] -!- filmroellchen has quit [Read error: Connection reset by peer]
[14:24:59] <solskogen|M> Charon77: Ask nvidia :-)
[15:06:44] <Charon77> yo
[15:06:49] <Charon77> I finally have cloud vm set up
[15:07:13] <solskogen|M> which one? :)
[15:07:22] <Charon77> I use oracle
[15:08:14] <solskogen|M> cool! How does it perform?
[15:08:41] <Charon77> uhh took me a WHILE just to get to arch because I have to start from ubuntu
[15:08:58] <solskogen|M> What would make it easier?
[15:09:02] <Charon77> their UI is slow as hell, even though the region is geographically close
[15:09:46] <Charon77> but I've managed to bootstrap pacman and networking and ssh using drzee
[15:10:30] <solskogen|M> Is there anything we could've provided that would make the process easier?
[15:10:56] <Charon77> used some vibecoded modification on vps2arch cause I don't want to bother creating multiple boot image :(
[15:11:00] <Charon77> oh right
[15:11:24] <Charon77> they accept booting from some image type, let me get the list..
[15:12:42] <Charon77> if there were a bootable .qcow2 or .vmdk that would've been sweet
[15:13:04] <Charon77> their machine boot using UEFI.
[15:13:51] <solskogen|M> I have a script ready which can make bootable images. The idea was that it could be used as a bootstrap image, but there nothing special about it, so you could ofc use it as is (you'd probably want to expand it)
[15:14:05] <solskogen|M> converting it to qcow2 should be fairly easy
[15:22:01] <Charon77> ya that'd be nice, maybe if it could be hosted somewhere
[15:22:58] <solskogen|M> hosting isn't a problem. Trying to convince @drzee to run the script every 14 days is :-) (he want to use the archiso instead)
[15:23:19] <solskogen|M> Which I totally agree on, but I haven't had the time to look at it.
[15:23:52] <solskogen|M> but this script is already in my home folder and works (it creates bootable images for both mainline, and pi5)
[15:24:45] <solskogen|M> I can ofc host it somewhere else
[15:25:39] <Charon77> outdated bootstrap is probably fine
[15:25:54] <solskogen|M> what do you mean?
[15:26:45] <Charon77> I mean, there's no rush to make a bootable image every 14 days or so, it could be outdated for few months and I think it should be okay?
[15:27:16] <solskogen|M> It takes about 30 seconds to make it
[15:27:20] <solskogen|M> maybe 45
[15:28:12] <Charon77> nice :D
[15:29:12] <Charon77> anyway, I'm kind of new to these cloud instance. any cool tooling you'd use to build packages? do you just do pkgctl and makepkg? how do I target v8? I assume it's a CFLAGS or something in makepkg.conf
[15:29:57] <solskogen|M> No, I use this: https://github.com - but it's quite tied up to our AWS instance.
[15:30:00] <phrik> Title: GitHub - solskogen/archlinux-aarch64-builder · GitHub (at github.com)
[15:35:15] <Charon77> btw, I still think we should have an issue tracker for talking about broken packages that are ports specific
[15:35:36] <Charon77> like talking about firefox for example
[15:41:03] <solskogen|M> what do you mean broken? It's not.
[15:41:21] <solskogen|M> It builds without modification on 8.2a
[15:42:25] <Charon77> sorry I forgot. on bens.haus it's not there because onnxruntime is not there, and even that I don't know if bschnei forgot to build it or have other issues
[15:42:37] <Charon77> I remember you mention that you modify onnxruntime to be cpu only
[15:43:11] <Charon77> my point is, this kind of discussion happened over irc, thought it'd be nice to document somewhere
[15:44:17] <solskogen|M> I did earlier, yes. When I didn't have all the dependencies. but now I do.
[15:45:48] <solskogen|M> But now you have access to all of the dependencies, and it should be a lot easier to get it to compile for armv8-a.
[15:45:59] <Charon77> so now onnxruntime builds without any modification?
[15:46:04] <solskogen|M> when we started we didn't have that. We did all that heavy lifting.
[15:46:06] <solskogen|M> Correct
[15:46:14] <solskogen|M> At least for 8.2-a :-)
[15:48:01] <solskogen|M> If you want to start making armv8-a packages, the easiest you can do is to use the 8.2-a as a starting point. Recompile everything with armv8-a, and recompile everything again against the packages you did build in stage1.
[15:48:34] <solskogen|M> I don't know how many cores you have, but if you have 4 I'd guess that would probably take around 6 months
[15:48:52] <Charon77> 4 cores, 24GB ram
[15:49:04] <solskogen|M> and during that time, the packages have been updated, so after those 6 months, it's another 3 to get up to date.
[15:50:15] <Charon77> how does arch linux proper does thing? do they have a buildfarm?
[15:50:15] <solskogen|M> (the package composable-kernel uses all 32 cores and it took our beefy build system 12h to build)
[15:50:39] <Charon77> or I guess that's the whole point of buildbtw?
[15:51:09] <tpkessler|M> Charon77: Mix of local machines of the packagers and a central build server to offload bigger builds
[15:51:19] <BrainDamage> arch is mostly individual devs buiding on their personal machine, there's an optional build server they can dispatch jobs to
[15:51:45] <BrainDamage> the problem is that you're racing as one vs many
[15:52:04] <BrainDamage> I can probably donate a bit of computing power since armv8a interests me too
[15:52:25] <solskogen|M> Heh, I remember the first build service for Arch.
[15:52:49] <solskogen|M> I installed some kind of a daemon on my machine, and something dispatched it to build something.
[15:53:04] <solskogen|M> what would be back in... 2004? 2005?
[15:53:50] <solskogen|M> Oh, I registered on the arch forum 21 years ago.
[15:53:59] <solskogen|M> "Registered: 06-03-2005"
[15:54:14] <BrainDamage> an issue with a shared pool of built packages would be trust, anyone with write access can inject malware, so pooling efforts even just to test things to work is tricky
[15:54:39] <solskogen|M> Which probably one of the reasons why that project was scrapped :-)
[15:54:41] <BrainDamage> and ofc, not all packages are reproducible ... yet, so even duplicating efforts isn't a sufficient guarantee
[15:58:18] <Charon77> but arch build uses shared pool, built by different maintainers?
[16:02:15] <BrainDamage> correct, and all the maintainers are assumed as trusted
[16:02:56] <BrainDamage> but one thing is a pool of people whom you gradually interacted with, gave escalating tasks, etc, it's harder for people to pull a jia tang
[16:03:11] <BrainDamage> another is random on a irc channel never met before
[16:30:33] -!- TheDcoder has quit [Read error: Connection reset by peer]
[16:30:54] -!- TheDcoder has joined #archlinux-ports
[16:34:21] <Charon77> building armv8 firefox now. hopefully it doesn't crash
[16:37:45] -!- cjc7373 has quit [Remote host closed the connection]
[16:39:46] -!- cjc7373 has joined #archlinux-ports
[16:41:12] <bschnei> Charon77: I think you might be operating under the assumption that my personal builds (targeting v8) are missing packages because of some technical problem. That could be true. But it also could simply be I haven't tried to build it. Or lacked sufficient memory. Or any one of many possible transient/trivial reasons that have absolutely nothing at all to do with v8 being the target. The
[16:41:12] <bschnei> current state of things is that nobody here (to my knowledge) knows the extent of work/workarounds needed to support v8. I know it's a bit stale but I tried to make that clear in https://gitlab.archlinux.org LSE, for example, was an issue and now it's not. But with 1000 missing packages it still could be. I just learned about
[16:41:12] <bschnei> CRC the other day. Perhaps there are others here who know the answers to the scope of the problem but until we hear from them, the issue linked above is the best place to collaborate on v8 specific issues. I think a lot more work needs to be done around Firefox/onnx before it is clear enough what the actual issue is
[16:41:14] <phrik> Title: Sign in · GitLab (at gitlab.archlinux.org)
[17:04:47] -!- Charon77 has quit [Remote host closed the connection]
[19:04:27] <fermino> I'm starting to think about how to package uboot for a specific board; has anyone seen any specific approach? I'm leaning towards an approach similar to grub-install: building uboot in the PKGBUILD and then providing instructions for the user to properly install it. I guess this would be reasonable for my board as the boot process conceptually is similar to booting from MBR; but I'd like to hear opinions :)
[20:42:40] -!- greyltc has quit [Ping timeout: 245 seconds]
[20:44:49] -!- greyltc has joined #archlinux-ports
[21:10:48] <bschnei> fermino: I'm sure the average user would appreciate any utility that allows them to manage/update their firmware from userspace a la https://github.com But I would expect a lot of inconsistency across devices. On mine, for example, there are no userspace utilities available. The firmware can only be updated via a u-boot executable. As a result, I made instructions for users (https://github.com/bs
[21:10:48] <bschnei> chnei/ebu-bootloader) but there's clearly no benefit in that scenario to packaging that.
[21:10:49] <phrik> Title: bs (Britt Selvitelle) · GitHub (at github.com)
[21:35:07] -!- greyltc has quit [Remote host closed the connection]
[22:27:10] -!- titus_livius has joined #archlinux-ports
[22:40:33] <fermino> Any thoughts? https://aur.archlinux.org
[22:40:34] <phrik> Title: PKGBUILD - aur.git - AUR Package Repositories (at aur.archlinux.org)
[22:40:37] <fermino> I'll take any roasting xD
[22:41:37] <solskogen|M> is it possible to build a "universial" u-boot instead of having 100x different ones?
[22:41:39] <fermino> IDK if that's the proper way to handle cross-compilation but it's the best one I could think of
[22:42:04] <fermino> I was thinking about a split-pkg but I didn't want to take too big of a bite atm
[22:42:09] <solskogen|M> the arch is wrong for aarch64 (the PKGBUILD says aarch)
[22:43:02] <fermino> Uh, thx. Fixed.
[22:44:16] <fermino> I'm thinking it _might_ be possible to unify stuff within the same chip line/boot processes; I'll see if I can find anything
[22:44:19] <solskogen|M> It's also missing a description on how to use / install it
[22:45:53] <fermino> I'll write something up :)
[22:46:03] <fermino> That should go in the .install, right?
[22:47:23] <solskogen|M> I'm quite a fan of putting such stuff in /usr/share, and a some message in post_install()
[22:47:34] <fermino> Instead of /usr/lib?
[22:47:43] <solskogen|M> yeah, but that's /me/
[22:47:53] <solskogen|M> Not a hill I'm willing to die on :-)
[22:48:27] <fermino> hahahha I'm still thinking about the definition of "architecture independent"
[22:48:41] <solskogen|M> good luck.
[22:48:47] <fermino> Because it _technically_ is not, but for all effects and purposes there makes zero sense to build uboot with this config for anything else
[22:49:02] <fermino> As a side note, I started working on something akin to arch-boxes but for SBCs (thus why I had to package uboot). Nothing is set in stone but I'll gladly take any ideas
[22:49:08] <solskogen|M> yeah, you have the same thing with mingw-w64-crt
[22:51:19] <solskogen|M> That said, u-boot is not a library. That's why I think it should go into /usr/share.
[22:51:58] <fermino> Tru
[23:19:14] -!- linkmauve has quit [Remote host closed the connection]
[23:22:23] -!- linkmauve has joined #archlinux-ports
[23:43:13] -!- linkmauve has quit [Read error: Connection reset by peer]