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

Back
[00:04:09] -!- titus_livius has joined #archlinux-ports
[00:54:02] <bschnei> gromit: I have us on for 0800 PDT tomorrow. if that still works let us know what meeting client you prefer to use. I had an issue getting browser-based Jitsi Meet to work on Brave before so I want to try to be prepared this time :)
[01:06:04] <gromit> Nice yes that is still planned
[01:06:57] <gromit> bschnei: DM'ed you an invite
[01:07:16] <gromit> I'll send the actual meeting invite later today
[01:48:00] -!- Solskogen has quit [Server closed connection]
[01:48:13] -!- Solskogen has joined #archlinux-ports
[01:51:06] -!- gromit has quit [Server closed connection]
[01:51:13] -!- gromit has joined #archlinux-ports
[02:16:10] -!- xce232 has joined #archlinux-ports
[02:22:50] -!- xce232 has quit []
[03:58:52] -!- h|weechat has quit [Ping timeout: 255 seconds]
[04:00:16] -!- p71 has quit [Server closed connection]
[04:00:26] -!- h|weechat has joined #archlinux-ports
[04:01:37] -!- p71 has joined #archlinux-ports
[04:22:43] -!- h|weechat has quit [Ping timeout: 255 seconds]
[04:39:48] -!- h|weechat has joined #archlinux-ports
[04:58:58] -!- oaken-source has quit [Ping timeout: 272 seconds]
[04:59:19] -!- oaken-source has joined #archlinux-ports
[05:37:20] -!- h|weechat has quit [Ping timeout: 256 seconds]
[05:53:10] -!- h|weechat has joined #archlinux-ports
[06:16:02] <jelle> so wait, when is this meeting and whats it about?
[06:20:01] <Antiz> jelle: https://gitlab.archlinux.org
[06:20:02] <phrik> Title: Project space for the Aarch64 Linux project (#699) · Issues · Arch Linux / infrastructure · GitLab (at gitlab.archlinux.org)
[06:26:01] -!- h|weechat has quit [Quit: WeeChat 4.6.3]
[06:28:26] -!- h|weechat has joined #archlinux-ports
[06:30:26] -!- h|weechat has quit [Read error: Connection reset by peer]
[06:33:44] -!- h|weechat has joined #archlinux-ports
[06:39:38] -!- drathir_tor has quit [Remote host closed the connection]
[06:40:00] -!- drathir_tor has joined #archlinux-ports
[06:48:07] -!- h|weechat has quit [Read error: Connection reset by peer]
[06:49:23] -!- h|weechat has joined #archlinux-ports
[06:56:30] -!- h|weechat has quit [Read error: Connection reset by peer]
[06:57:21] -!- h|weechat has joined #archlinux-ports
[07:02:05] -!- h|weechat has quit [Read error: Connection reset by peer]
[07:02:57] -!- h|weechat has joined #archlinux-ports
[07:06:28] -!- h|weechat has quit [Read error: Connection reset by peer]
[07:07:41] -!- h|weechat has joined #archlinux-ports
[07:09:14] -!- h|weechat has quit [Read error: Connection reset by peer]
[07:09:57] -!- h|weechat has joined #archlinux-ports
[07:11:53] -!- h|weechat has quit [Read error: Connection reset by peer]
[08:19:23] <gromit> jelle: I can forward you the invite aswell later on :)
[08:28:42] <jelle> gromit: sure, not sure if I can join, what time is it?
[08:29:00] <gromit> jelle: 17:00 CEST
[08:29:14] <jelle> oooo, can't join then
[08:41:01] <anthraxx|M> gromit: can you send me the invite as well plz
[08:41:22] <gromit> anthraxx|M: sure, just didn't get to it yet
[09:22:11] <Solskogen> gromit: why are you including protobuf into grpc?
[09:22:34] <gromit> Solskogen: what do you mean?
[09:23:02] <Solskogen> "https://github.com/protocolbuffers/protobuf/archive/v$_protover/protobuf-$_protover.tar.gz")
[09:24:15] <Solskogen> I'm not saying there isn't a (good) explaination - I'm just wondering why :-)
[09:25:01] <gromit> Solskogen: I'm struggling to understand the question, what do you mean with "including"?
[09:25:25] -!- archmatrix has quit [Quit: Bridge terminating on SIGTERM]
[09:25:26] -!- anthraxx|M has quit [Quit: Bridge terminating on SIGTERM]
[09:25:26] <Solskogen> Why is it there in the first place?
[09:25:26] -!- heftig has quit [Quit: Bridge terminating on SIGTERM]
[09:25:26] -!- bgyorgy|M has quit [Quit: Bridge terminating on SIGTERM]
[09:25:50] <gromit> Solskogen: ??? what are we talking about
[09:26:05] -!- phrik has quit [Remote host closed the connection]
[09:26:22] -!- archmatrix has joined #archlinux-ports
[09:26:28] -!- heftig has joined #archlinux-ports
[09:26:29] <Solskogen> https://gitlab.archlinux.org
[09:26:33] <gromit> Ah you mean https://gitlab.archlinux.org ?
[09:26:43] <Solskogen> yes :-)
[09:26:50] <jelle> gromit: I think the question is why does it include protobuf.tar.gz while it is also a dependency
[09:27:10] -!- phrik has joined #archlinux-ports
[09:28:38] <gromit> https://github.com and https://github.com
[09:29:24] <phrik> Title: Incompatible with protobuf 30.0 · Issue #52 · abique/hefur · GitHub (at github.com)
[09:30:14] <Solskogen> ah, so it used to be an issue.
[09:30:21] -!- anthraxx|M has joined #archlinux-ports
[09:30:22] -!- bgyorgy|M has joined #archlinux-ports
[09:31:15] <Solskogen> I think that has been fixed, because I tried packaging grpc without it and that worked fine.
[09:31:26] <gromit> Nice, wanna raise an mr?
[09:31:56] -!- h|weechat has joined #archlinux-ports
[09:32:35] <Solskogen> There's a bug in protobuf that broke compiling on aarch64, so I had to cherry-pick a commit for it to work. And it didn't make sense (to me) that grpc was broken :-)
[09:32:38] <Solskogen> will do
[10:28:21] -!- titus_livius has joined #archlinux-ports
[10:29:10] -!- h|weechat has joined #archlinux-ports
[15:00:09] <gromit> Brief reminder, meeting starts now DrZee, Solskogen, bschnei, anthraxx|M, Antiz
[15:00:19] <gromit> If anybody else wants to join let me know
[15:03:40] <bschnei> I believe I'm in a "waiting room" state
[15:57:49] -!- dvzrv has joined #archlinux-ports
[16:00:51] -!- dvzrv|M has joined #archlinux-ports
[16:20:20] <gromit> anthraxx|M: could you reduce the access level to the pad from freely to something else? Then we could archive it in the issue on gitlab :)
[16:20:40] <anthraxx|M> aye
[16:22:09] <gromit> https://gitlab.archlinux.org
[16:22:10] <phrik> Title: Project space for the Aarch64 Linux project (#699) · Issues · Arch Linux / infrastructure · GitLab (at gitlab.archlinux.org)
[16:26:39] -!- jelle|M has joined #archlinux-ports
[16:28:07] <gromit> DrZee: You mentioned setting up on AWS, but I guess hetzner would also be an option no?
[16:35:07] <gromit> bschnei: do you want to use matrix over irc? Then we could invite you in here I think
[16:35:21] <gromit> Solskogen: will look at your grpc mr later, thanks!
[16:35:45] <jelle> gromit: I found hetzner docs somewhere
[16:39:14] <jelle> https://blog.alexanderkoch.net
[16:39:15] <phrik> Title: Running Arch Linux ARM on Hetzner Cloud (at blog.alexanderkoch.net)
[16:39:17] <jelle> untested tho
[16:39:25] <jelle> but uefi \o/
[16:43:53] <Solskogen> just a small follow up on the bootstrapping. I've bootstrapped our packages three times already. I should've mentioned that.
[16:48:02] <Solskogen> And I've fixed the wording a bit on https://gitlab.archlinux.org
[16:48:04] <phrik> Title: aarch64 support (!3) · Merge requests · Arch Linux / Packaging / Packages / go · GitLab (at gitlab.archlinux.org)
[16:48:57] <bschnei> gromit: the host I use to build ARMv8 packages is a Heztner CAX31 in Falkenstein. My fork of the linux package (and the config therein) is what I use on this server and what Solskogen and DrZee run on their AWS hosts.
[16:49:25] <bschnei> It's been working very well for us for a couple months now :)
[16:51:14] <bschnei> I'm fine with IRC. I have an instance of soju (https://soju.im/) running on x64 Hetzner host much closer to home and then use Goguma on mobile and senpai on desktop. A few glitches here and there but overall pretty happy with that setup.
[16:52:35] <bschnei> jelle: that is indeed how I got started, but those directions won't just work perfectly out-of-the-box. You'll hit issues with the boot partition being too small to update and the ISO from ALARM is quite old so it's a big delta.
[16:53:04] <jelle> do you have more modern instructions? :)
[16:53:46] <bschnei> My/our(?) hope was to get our own ISOs that do work before we needed to write even longer directions to use an ALARM ISO :)
[16:54:21] <bschnei> In our call just now it sounded like Solskogen and DrZee are pretty close
[16:55:12] <Solskogen> Oh, I haven't started at that. But what I can do is to prepare a tarball.
[16:55:16] <jelle> I think a bootstrap tar.gz would also be interesting
[16:55:18] <bschnei> I'm not prioritizing making ISOs from the packages I build for now because they target ARMv8 and the cloud servers all support at least v8.2 or newer
[16:55:20] <jelle> ye tarball would be neat
[16:55:46] <Solskogen> There are a few caveats here, just so you know.
[16:55:54] <Solskogen> None of the packages as signed
[16:56:49] <Solskogen> until further notice you just have to trust us - and/or put it on a device that are not on the same network as your other stuff.
[16:57:31] <bschnei> jelle: if you are just wanting to start playing around, you could also try to get tpowa's archboot ISOs for aarch64 to work. They use the generic ALARM linux kernel which should work just fine on cloud hosts.
[16:59:24] <Solskogen> that's probably the easiest, and switch out the repos with our and reinstall every package.
[16:59:34] <jelle> hmm interesting
[17:02:49] <Solskogen> https://antarctica.no
[17:08:34] <Solskogen> What we SHOULD have said in the meeting was that our biggest hurdle as of now is to get haskell bootstrapped.
[17:10:58] <Antiz> Let's just rename "haskell" as "hurdle" actually
[17:11:17] <Antiz> That sums it up pretty accurately I guess :P
[17:12:24] <Antiz> On a side, I think haskell is (indirectly) needed to build our packaging tooling (devtools / pkgctl) by the way...
[17:12:44] <jelle> Antiz: really, in what way?
[17:12:53] <Antiz> jelle: It makedepends on shellcheck
[17:12:55] <jelle> oh shellcheck I guess
[17:12:57] <jelle> blegh
[17:12:58] <Antiz> Yup :/
[17:13:09] <jelle> honestly packaging bug :p
[17:13:14] <Antiz> Haha
[17:13:36] <jelle> we shouldn't be running linters which can break rebuilding packages
[17:14:03] <Antiz> So yeah, getting the packaging tooling to build in the first place requires going through the haskell hurdle first unfortunately (at least in the current state of things) :/
[17:16:15] <jelle> Antiz: this sounds fixable ;-)
[17:19:02] <Antiz> jelle: Yeah
[17:19:06] <Antiz> I mean
[17:19:46] <Antiz> gromit, anthraxx|M: What is the shellcheck makedepend used for in devtools? I only see it being used in `make check`?
[17:21:12] <Antiz> Is it actually used at build time by something? If we could demote it to a checkdepend that would allow to build devtools with `--nocheck`
[17:22:09] <Antiz> Which would probably be a great help for port efforts, so they don't have to go through the hurdle of packaging haskell to get the packaging tooling to build in the first place.
[17:27:40] <Antiz> Or alternatively drop it from the PKGBUILD altogether if possible (as doing code linting in PKGBUILDs doesn't make much sens anyway I guess).
[17:30:44] <bschnei> You guys have identified one of the first obstacles we ran into very early. My workaround has been to use -bin versions from the AUR because I did rely a lot on shellcheck anyway to help develop "good" bash habits.
[17:31:04] <Antiz> Actually, `check()` is running `make test` while shellcheck is only called in the "check" Make target.
[17:31:19] <Antiz> I'm actually wondering if shellcheck is even needed at all now 🤔
[17:31:21] <bschnei> But yes, dependencies on shellcheck or pandoc anywhere mean a dependency on haskell
[17:32:04] <Antiz> bschnei: Well, either I'm missing something, or the shellcheck dependency is actually not needed at all.
[17:32:20] <bschnei> that'd be nice :)
[17:32:36] <Antiz> The only place I see it being called in devtools' makefile is in the "check:" target: https://gitlab.archlinux.org
[17:32:38] <phrik> Title: Makefile · master · Arch Linux / devtools · GitLab (at gitlab.archlinux.org)
[17:33:22] <bschnei> https://gitlab.archlinux.org
[17:33:23] <phrik> Title: Makefile: Add a simple 'check' target that runs shellcheck (430e1265) · Commits · Arch Linux / devtools · GitLab (at gitlab.archlinux.org)
[17:33:27] <Antiz> And, as far as I can tell, this "check:" target is never called in the PKGBUILD (neither during build() nor check())
[17:34:12] <bschnei> I'm sure the intention was good, but if you have to manually call shellcheck anyway....
[17:34:54] <Antiz> In any case, code linting in PKGBUILD doesn't make much sense.
[17:35:38] <Antiz> bschnei: From what I can tell, this shellcheck dependency can just be dropped without consequence. Maybe I'm missing something, but it doesn't seem like it's being used at all
[17:36:32] <DrZee> gromit: the machine images I have only work on AWS and I do not have hetzner infrastructure. It's the easiest on AWS as we have everything in place if you have an account you will be up running in under 5 min. That being said in sure you can make a hetzner boot image using an arm linux they already have (Debian) and then use a Arch ARM tarball (if we had one) and chroot into that and
[17:36:32] <DrZee> complete the image generation process. Thats what i did to make the first Arch x86_64 machine image on AWS .... I dont have the time to make it though and learn hetzners process....
[17:36:45] <Antiz> bschnei: FWIW, I just rebuilt the package without it successfully
[17:36:56] <bschnei> While we're on the topic of Things That Make Bootstrapping Hard, you guys did touch on this in our call, but we didn't have time to really dig in. Split packages are a blessing and a curse. The amount of dependencies that get pulled in just to build documentation just causes things to explode exponentially.
[17:37:42] <bschnei> Antiz: cool!
[17:37:59] -!- antiz|M has joined #archlinux-ports
[17:40:17] <Antiz> anthraxx|M, gromit: So yeah, it seems like the shellcheck makedependency for devtools could just be dropped altogether, which would avoid the requirement to deal with haskell prior to be able to build devtools. That would be a great help for port efforts 🤗
[17:40:38] <Antiz> If you confirm this, I can push a rebuild without shellcheck to testing ;)
[17:42:06] <DrZee> Antiz: i have the Haskell process in place... on paper it should work .... i just didn't have time in the last 3 months to test it....
[17:42:30] <Solskogen> Antiz: shellcheck and pandoc.
[17:42:47] <Solskogen> our workaround has been to use the -bin packages (from aur)
[17:42:59] <Antiz> DrZee: Yeah... That's a monster. I mean... Haskell would still need to be done anyway, but if we can make our packaging tooling more accessible and straightforward to build that's still a win :D
[17:44:02] <Solskogen> I tried bootstrapping it, and ofc it has problems with gcc-15.
[17:44:16] <Antiz> Solskogen: Yeah, everything haskell really... But for new ports, we probably want our packaging tooling to be built and used fairly early in the process so if we can drop haskell dependencies from it, that'd be great:
[17:44:21] <Solskogen> the ghc version in arch is old as well (and not really supported)
[17:46:17] <Solskogen> --nocheck also has it problems, because there's a lot of packages that won't compile because in some cases configure won't even finished because of a missing dependency that is fulfilled in checkdepends.
[17:47:03] <Antiz> Sure
[17:47:24] <Antiz> But in that case, it seems shellcheck is not even required at check time. It could just be dropped altogether as far as I can tell.
[17:48:20] <DrZee> Solskogen: it's Felix who is the maintainer on Haskell and I'm pretty sure he has the same problem I have .... basically going to a new vesion Haskell requires you to bootstrap GHC and then rebuild all Haskell- packages against that ... there are avou 800 900 in the arch repo today ....
[17:48:37] <Solskogen> Probably.
[17:49:38] <Antiz> DrZee, Solskogen: I mean, $pkgrel on Haskell reverse dependencies speaks for itself
[17:49:44] <Antiz> https://archlinux.org
[17:49:46] <phrik> Title: Arch Linux - haskell-aeson-yaml 1.1.0.1-290 (x86_64) (at archlinux.org)
[17:49:50] <Antiz> haskell-aeson-yaml 1.1.0.1-290
[17:49:51] <Antiz> lol
[17:50:03] <Solskogen> haskell is a very strange beast. I tried bootstrapping ghc 9.4.8 with 9.4.8. Not able to. In order for stage1 to work, I had to start with 9.4.7.
[17:50:41] <Solskogen> lol
[17:54:08] <DrZee> Antiz: so o think I have a way around that with a different approach.... but that's one of the test I still need to do and I need a week quiet without kid wife and work ....
[17:57:09] <Antiz> DrZee: Haha alright, well good luck with that :P I hope it'll work the way you image it 🤞
[17:59:18] <Solskogen> Antiz or gromit: https://gitlab.archlinux.org
[17:59:20] <phrik> Title: Add missing dependency to fix FTBFS (!3) · Merge requests · Arch Linux / Packaging / Packages / gnome-mplayer · GitLab (at gitlab.archlinux.org)
[17:59:58] <Antiz> Solskogen: Ah yeah, the glib2-devel split is also something that may have worth a general ToDo rebuild x)
[18:00:21] <Antiz> Taking a look at it ;)
[18:00:50] <DrZee> I was lucky earlier in the summer may and June it was not so busy at work and I could use work time to make progress..... now ...... I have more things at work that it barely fits in a day (partial my own fault for wanting certain project) and I need to spend more time with the family.....
[18:02:03] <Antiz> DrZee: Totally fair, we are all volunteers here 🤗
[18:03:12] <Solskogen> Antiz: that rebuild will show a lot of broken packages
[18:03:47] <anthraxx|M> well ghc is kinda stuck because felix unfortunately prioritizes riscv over x86
[18:04:21] <Antiz> Solskogen: Merged, rebuilding the package right now ;)
[18:04:33] <anthraxx|M> <Solskogen> "--nocheck also has it problems..." <- ^ this is a bug, please submit MRs :)
[18:05:40] <Solskogen> anthraxx|M: Are you really sure about that? I've got some MR closed because some think that is not a bug.
[18:05:56] <Solskogen> jelle is one of them
[18:06:17] <Solskogen> https://gitlab.archlinux.org
[18:06:18] <phrik> Title: gtest belongs to makedepends (!3) · Merge requests · Arch Linux / Packaging / Packages / ninja · GitLab (at gitlab.archlinux.org)
[18:08:03] <anthraxx|M> Solskogen: if a package fails to build because of dependencies if you use --nocheck, yes thats a packaging bug.
[18:10:18] <anthraxx|M> Solskogen: ive added a comment to the MR, maybe you can provide an error log.
[18:11:11] <dvzrv|M> AFAIK, gtest always needs to be a build time dependency though (although tests based on the compilation are only run in check() of course)? 🤔
[18:11:54] <Solskogen> ninja is a special case, because what happens is that if it doesn't find gtest it will download a copy instead.
[18:12:04] <anthraxx|M> David Runge: technically not, but yes like most lazy ecosystem setups use it in cmake and fail if you dont have it. but ive seen multiple that do it "properly".
[18:13:13] <anthraxx|M> they need to compile the test binary, which is often not guarded :/
[18:13:18] <dvzrv|M> anthraxx|M: hm, interesting, but gtest is already required for detection and compilation during build(), right?
[18:14:09] <anthraxx|M> its required for compilation, yes. thats why it is makedepends in these cases. for checkdepends in needs auto-detection.
[18:14:30] <Solskogen> you have a log!
[18:15:57] <Solskogen> and this is what I'm talking about. synergy effects of having simple people like us trying to port arch linux over to a new platform.
[18:16:17] <Solskogen> the question is, how long until someone wants to make a s390x port!
[18:20:59] <Antiz> anthraxx|M, gromit: I opened https://gitlab.archlinux.org 🤗
[18:21:01] <phrik> Title: Remove `shellcheck` from the dependency tree (!5) · Merge requests · Arch Linux / Packaging / Packages / devtools · GitLab (at gitlab.archlinux.org)
[18:21:16] <Antiz> (cc bschnei 😉)
[18:26:59] <anthraxx|M> Antiz: seems like a leftover, i remember to have split tests and lints like a year or two ago so linting is only run in CI
[18:28:12] <Antiz> anthraxx|M: Alright, well if that confirms we can get rid of it that's great \o/
[18:55:16] <bschnei> Solkogen: who are you calling "simple"? ;)
[19:30:31] <bschnei> DrZee: I've updated/rebased cloud-init. Knowing what we know now, do you want to try to clean it up for a potential MR? https://gitlab.archlinux.org
[19:30:32] <phrik> Title: aarch64 changes (6d14137b) · Commits · Benjamin Schneider / cloud-init · GitLab (at gitlab.archlinux.org)
[19:34:13] <bschnei> With the workarounds we have in place now, it seems like we may not even need any of these changes anymore? I'm happy to keep updating/rebasing for you as long as it keeps rebasing cleanly.
[19:37:26] <dvzrv|M> bschnei: btw, this would be shorter:... (full message at <https://matrix.archlinux.org/ircmedia/v1/media/download/AW9zwfiCZRhhkA3UC104iyVG-9XFMl2uBEQeY6MsGW_UcZJO7vsbVMza4V4_AO2XN8MsJoceYpxDT9BF5Ugj4IxCeZOkhjZwAGFyY2hsaW51eC5vcmcvVmZsUUpGc1dEcUR1a3VwZXhZTkpVQlB1>)
[19:39:46] <jelle> we shouldn't be doing this
[19:42:36] <Antiz> jelle: WDYM?
[19:42:43] <Antiz> Conditions based on $CARCH?
[19:42:46] <jelle> yes
[19:42:54] <jelle> because pandoc isn't build yet
[19:54:30] <bschnei> The commit above is from four months ago when we had no idea what we were doing. Most likely we don't want any of it nor would it be a candidate for an MR. ...and we only know a tiny bit more than four months ago but a tiny bit divided by 0 is technically infinitely more. at least that's what I tell myself whenever I break everything 😅
[20:00:46] <bschnei> also during the call transparency into our automation was brought up. The scripts I use (which are only for a subset of packages built for ARMv8, not v8.2) can be found here: https://github.com
[20:00:48] <phrik> Title: GitHub - bschnei/arch_a64: Arch Linux packaging automation for aarch64 architecture (at github.com)
[20:00:53] <anthraxx|M> <dvzrv|M> "bschnei: btw, this would be..." <- i dont think this is a good idea in terms of srcinfo
[20:02:21] <bschnei> ^ great point. I'd think we'd want to use xdepends(), xdepends_x86_64(), construct when/if dependencies differ?
[20:02:35] <dvzrv|M> ah yes, true
[20:02:47] <Solskogen> bschnei: me! :-D
[20:02:55] <bschnei> :)
[20:03:10] <dvzrv|M> for local hack probably no problem, but not for the package sources in the repos :)
[20:10:00] <bschnei> my basic recipe for maintaining the small subset of ARMv8 packages is: 1) run status.sh to get state of x64 core and extra repos and check versions against the versions I have built for armv8. save that state to disk because it's possible i'll need to build many things before "releasing" them. 2) in naive alphabetical order, try to build things out of date, 3) check for what failed, if not something to hold up a release
[20:10:00] <bschnei> , release what did build. repeat. work on issues that come up. note that this "daily" process is only concerned with packages i already have built. unlike what Solkogen has, I'm not self-contained/indepdent yet because I've been focusing more on getting what I already do have to be relatively reliable/easy to maintain before I add more. I have no idea (yet), if I can cleanly carve out a subset of packages that avoids th
[20:10:00] <bschnei> e issue of ARMv8 not having LSE.
[20:17:16] <bschnei> I believe I have built every package I actually use/install on my devices/hosts. But I definitely do not have all of the packages needed to *build* those packages. On rare days when things are running smoothly, I chip away towards that.
[20:19:47] <bschnei> I host them here: https://repo.bens.haus I only have a single "testing" repo. When I say "release" it's from staging to testing.
[20:19:50] <phrik> Title: Index of /arch/testing/os/aarch64/ (at repo.bens.haus)
[20:22:08] <bschnei> Antiz: if you did want to play on the RPi4, you should be able to mkarchroot and/or pacstrap to a partition using this repo.
[20:23:17] <Antiz> bschnei: Alright cool, thanks for sharing!
[20:32:11] <Solskogen> I think makedepends_aarch64=() works
[20:35:22] -!- felixonmars|M has joined #archlinux-ports
[20:35:36] <Solskogen> oh, hi felixonmars|M
[20:36:36] <felixonmars|M> hello :)
[20:37:35] <Solskogen> if not the man of the hour, it's not very far. we talked briefly about bootstrapping haskell.
[20:40:59] <Solskogen> yeah, makedepends_aarch64=() works. but it will bork up .SRCINFO unless you have aarch64 in the arch= array.
[20:41:37] <anthraxx|M> Solskogen: thats okay for now :)
[20:42:33] <Solskogen> breaking .SRCINFO or having aarch64 in the arch array? :-)
[20:43:23] <Solskogen> That said, we have pandoc in our repos.
[20:43:44] <anthraxx|M> .SRCINFO wont really be broken, it just wont contain the aarch64 array. and thats okay for now :)
[20:44:13] <Solskogen> Okay, good!
[20:44:42] <Solskogen> https://aur.archlinux.org
[20:44:43] <phrik> Title: AUR (en) - pandoc-bin (at aur.archlinux.org)
[20:45:43] <Solskogen> anyways, point is that you don't need if [[ "$CARCH" != "aarch64" ]]; then
[20:46:18] <anthraxx|M> yeah good, as THAT one is really breaking things in srcinfo determinism 😅
[20:50:18] <Solskogen> so far there's one package that has an additional dependency when built for aarch64 and that is libcamera. it has a soft dependency (you can disable it) on libpisp.
[22:10:10] -!- titus_livius has joined #archlinux-ports
[22:56:03] <DrZee> bschnei: I have to look into cloud-init if we have pandoc (without Haskell dependency) then we can have netplan .... with netplan we don't need the changes in cloud-init it should build as-is for x86 ... in theoy since it's all python (at least if you build without netplan) it could be an ANY package .....
[23:03:27] <DrZee> anthraxx|M: could you take a peak then at the MR I have for grub? ..... even on x86 grub uses $CARCH for setting up certain things .... grub PKGBUILD may need a general overhaul as it (if I read it right) includes some i686 decision logic that may no longer be needed .... https://gitlab.archlinux.org
[23:03:28] <phrik> Title: Restructured PKGBUILD to make it work on both x86_64 and aarch64. (!2) · Merge requests · Arch Linux / Packaging / Packages / grub · GitLab (at gitlab.archlinux.org)
[23:05:56] <DrZee> when I made the changes to grub I only expanded/followed the logic already present in the PKGBUILD but if that is already not the desirable way to do we should maybe overhaul it more thoroughly
[23:27:10] <bschnei> DrZee: re: cloud-init. ok I'll take a look. thx