2025-01-01 02:03:13 <fossdd[m]> i think the message is kinda lost due to the matrix spam, so yeah i'd be happy if someone can hit the big button for !77734
2025-01-01 02:04:33 <Ariadne> it seems with the new kde packages in edge, there is now a dependency on org.freedesktop.locale1 service.  i guess we need to update elogind?
2025-01-01 02:06:45 <fossdd[m]> oh interesting
2025-01-01 02:06:56 <fossdd[m]> i had a look at the elogind upgrade the other day
2025-01-01 02:07:21 <Arnavion> elogind doesn't have a localed implementation, does it?
2025-01-01 02:07:54 <Arnavion> https://github.com/elogind/elogind/blob/main/man/org.freedesktop.login1.xml#L1643-L1645
2025-01-01 02:30:07 <fossdd[m]> <Ariadne> "it seems with the new kde..." <- fwiw pushed a wip elogind upgrade to !77841
2025-01-01 13:14:26 <j_v> is there a reason why main/byacc has to install the yacc symlink... seems weird to have to uninstall bison to use byacc for some things... ususally it is easy  enough to supply something like YACC=byacc to make commandline
2025-01-01 13:16:01 <j_v> i realize this is no problem when it is in makedepends, but for generally use, i see no reason both can't be installed
2025-01-01 13:16:19 <j_v> other than that symlink
2025-01-01 13:18:13 <j_v> s/\(general\)ly/\1/
2025-01-02 00:04:35 <tomalok> it's not often that I find myself trying to compile random C things these days, but I'm currently up against a wall trying to figure out error: invalid application of 'sizeof' to incomplete type 'FILE' that's tripping me up on a doc->len = sizeof(FILE); -- any hints?  I tried adding CFLAGS='-std=c11' to no avail
2025-01-02 00:10:13 <humm> tomalok: not much to say other than the code is non-conforming
2025-01-02 00:13:08 <tomalok> back 10 years ago it compiled just fine ;)
2025-01-02 00:28:07 <humm> with musl it may compile with -std=c99, but it’s still wrong and may not work
2025-01-02 00:44:12 <tomalok> there was no difference with/without -std=c11
2025-01-02 00:52:53 <tomalok> i think i figured it out -- added #define for __NEED_struct__IO_FILE and __NEED_FILE before #include <stdio.h>
2025-01-02 00:53:21 <j_v> tomalok: best guess is that the actual definition for the FILE type is not in the headers. the definition in usr/include/bits/alltypes.h is just a stub
2025-01-02 00:53:43 <tomalok> though the stub is enough, as long as I add those defines
2025-01-02 00:55:54 <tomalok> actually __NEED_FILE is already defined in stdio.h, but __NEED_struct__IO_FILE is only set if __STDC_VERSION__ is < 201112L
2025-01-02 01:03:32 <j_v> i sense a segfault looming
2025-01-02 01:19:11 <tomalok> well no segfault so far
2025-01-02 01:23:07 <j_v> i guess it depends on what doc->len is being used for
2025-01-02 01:59:27 <vkrishn_> have not traced it , but some app postinstall creates ~/.local/share/flatpack/db
2025-01-02 10:28:12 <aparcar[m]> who controls the github.com/alpinelinux stuff? Would it be possible to enable macos CI jobs there for the APK package manager?
2025-01-02 10:29:14 <pj> it's a mirror from gitlab
2025-01-02 10:29:34 <ncopa> its the infra team that manages I think
2025-01-02 10:30:04 <pj> still, you need a CI template in source which would have to be added in apk-tools on gitlab.a.o
2025-01-02 10:31:18 <ncopa> would be better to have a macos runner for https://gitlab.alpinelinux.org/alpine/apk-tools
2025-01-02 10:31:30 <ncopa> because that is where the development happens
2025-01-02 10:31:33 <aparcar[m]> pj: sure I think i could make that happen, however someone needs to allow CI over on github
2025-01-02 10:32:01 <pj> ncopa: i think the problem would be to obtain a mac runner? maybe Ariadne has/could have some spare machine?
2025-01-02 10:32:21 <aparcar[m]> ncopa: agree, I could ask for some sponsoring but then again I'm not really part of the alpine project
2025-01-02 10:32:52 <aparcar[m]> I talked to https://www.scaleway.com/en/ in the past and they offerend some free macos runners, i guess you could talk to them
2025-01-02 10:33:07 <pj> enabling GitHub CI would solve that for free (TM) but you miss out on any information unles you watch that specific github repo
2025-01-02 10:33:29 <clandmeter> my experience with scaleway is not that great
2025-01-02 10:33:30 <ncopa> the last part is what I worry for
2025-01-02 10:33:37 <aparcar[m]> technically i could open issues at gitlab via a webhook
2025-01-02 10:33:52 <aparcar[m]> ncopa: why part worries you?
2025-01-02 10:34:03 <ncopa> "but you miss out on any information unles you watch that specific github repo"
2025-01-02 10:34:03 <aparcar[m]> clandmeter: can't say, no experience 
2025-01-02 10:34:04 <pj> why issues?
2025-01-02 10:34:15 <pj> This was supposed to be only CI, not also issues?
2025-01-02 10:34:18 <aparcar[m]> ncopa: for that, issue API
2025-01-02 10:34:35 <aparcar[m]> the github CI can automatically create gitlab issues
2025-01-02 10:34:40 <clandmeter> we had scaleway as sponsors before
2025-01-02 10:34:47 <ncopa> the workflow becomes cumbersome
2025-01-02 10:34:56 <clandmeter> and gave me a lot of headaches 
2025-01-02 10:35:42 <aparcar[m]> maintaining a CI runner is also somewhat cumbersome, based on clandmeter the communication with people maintaining it for you, too
2025-01-02 10:35:43 <ncopa> you want a change in apk-tools, you create a merge request, it passes the gitlab CI, it gets merged, and mirrored to github, macos CI run and fail. you get a ticket that the merge you just did breaks mac os
2025-01-02 10:35:46 <ncopa> now what
2025-01-02 10:36:19 <ncopa> so you create a fix for macos, but dont know if it works until you have merged the fix
2025-01-02 10:36:38 <pj> I'm not deciding voice in this but gitlab vcs > github ci > gitlab issue sounds extremely painful
2025-01-02 10:36:54 <ncopa> exactly
2025-01-02 10:36:59 <aparcar[m]> ncopa: agree, well right now openwrt sees those errors via downstream CI. I'm thinking of a simple way to move it up the chain
2025-01-02 10:37:20 <ncopa> so yeah, it is a "cheap" way to get macos CI, but not optimal
2025-01-02 10:37:30 <aparcar[m]> so the solution would be something "other" than scaleway?
2025-01-02 10:38:41 <pj> I would recommend using external status checks if you want to use external CI
2025-01-02 10:39:02 <pj> but still would need to figure out a proper flow for PRs/MRs
2025-01-02 10:39:44 <pj> https://docs.gitlab.com/ee/api/status_checks.html
2025-01-02 10:39:54 <ncopa> https://www.scaleway.com/en/hello-m1/ the cost is 0.11 EUR/hour. ~80 EUR/month
2025-01-02 10:40:32 <ncopa> openwrt uses github CI?
2025-01-02 10:40:41 <pj> yes
2025-01-02 10:41:03 <pj> (sidenote: why openwrt needs macos?)
2025-01-02 10:41:18 <clandmeter> my question as well 
2025-01-02 10:43:36 <pj> btw. https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10832
2025-01-02 10:44:20 <pj> according to gitlab backlog, significant portion of openwrt devs are using macOS
2025-01-02 10:46:12 <pj> alternative to scaleway: you could ask macstadium
2025-01-02 10:47:23 <ncopa> https://www.macstadium.com/pricing $89 / month
2025-01-02 10:47:37 <aparcar[m]> yea, some (core) developers use macos
2025-01-02 10:47:42 <pj> I meant the "we are Open Source, gib us free CI pls"
2025-01-02 10:47:52 <pj> https://www.macstadium.com/company/opensource
2025-01-02 10:48:03 <aparcar[m]> and yea we use the free macos m1 github stuff
2025-01-02 10:50:28 <pj> do you need dev apk version or just whatever apk
2025-01-02 10:50:59 <pj> is this just about "macos build broken" or is there kind of expectation for macos artefacts?
2025-01-02 10:52:09 <pj> could also include apk-tools in macports/homebrew
2025-01-02 10:52:18 <aparcar[m]> pj: we want to fully build openwrt on macos, we use apk for packaging openwrt packages, ergo we need a macos working apk
2025-01-02 10:52:30 <aparcar[m]> we use v3 only
2025-01-02 10:56:04 <liske> linux-lts: is it intentional that CONFIG_IPV6_OPTIMISTIC_DAD is not enabled? (no 3.21 regression, 3.18 looks like the same)
2025-01-02 10:57:32 <ncopa> probably not
2025-01-02 10:58:09 <ncopa> liske: can you please open an issue why we want this enabled? and I'll fix it now
2025-01-02 10:58:18 <ncopa> looks like there are new kernels out today
2025-01-02 10:58:30 <liske> sure, thanks!
2025-01-02 10:58:59 <pj> aparcar: I get that but it's like, do you need always the latest apk-tools because you are testing with it as well or you just need "apk-tools v3". If it's just the apk you are after, then maybe contributing portfile to like macports or homebrew recipe would solve it for everyone no? (when I was using apk on macos, I made myself a macports port to build apk)
2025-01-02 11:00:49 <aparcar[m]> pj: we also include some downstream patches and use somewhat "latest" features of APK, so I'd prefer being in sync with what we got in openwrt instead relying on homebrew etc
2025-01-02 11:00:56 <aparcar[m]> would this macstatium be an option?
2025-01-02 11:01:13 <aparcar[m]> I can setup build testing in gitlab ci for apk-tools, I just don't want to be the contact person for the CI runners
2025-01-02 11:01:44 <ncopa> it would be ikke or clandmeter
2025-01-02 11:02:20 <ncopa> i think ikke may be off this week
2025-01-02 11:02:33 <pj> could wait for Ariadne, maybe she will be able to still provide a macOS runner as noted in the issue and maybe ikke/clandmeter could help with setting up the gitlab-runner?
2025-01-02 11:02:46 <pj> I can also guide with that
2025-01-02 11:02:52 <ncopa> i can also help enabling the runner
2025-01-02 11:02:55 <pj> though only verbally
2025-01-02 11:04:27 <liske> ncopa: #16799 - I can create the MRs for the issue if that helps
2025-01-02 11:04:59 <ncopa> liske: nah, dont bother with MR, i'm on it already
2025-01-02 11:05:24 <liske> thanks!
2025-01-02 11:06:14 <ncopa> liske: https://cateee.net/lkddb/web-lkddb/IPV6_OPTIMISTIC_DAD.html says "experimental" and "say N if unsure"
2025-01-02 11:06:32 <ncopa> i suppose it is for getting the ipv6 faster?
2025-01-02 11:07:35 <vkrishn> don't know what created this, /var/cache/swcatalog/cache/C-local-metainfo.xb
2025-01-02 11:07:57 <ncopa> i have no idea either
2025-01-02 11:08:03 <vkrishn> and found this in it, https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/docker/firefox-flatpak/runme.sh
2025-01-02 11:08:26 <vkrishn> uninstalling sway for now
2025-01-02 11:10:07 <liske> ncopa: when assigning a IPv6 address to an interface the kernel *must* do DAD - in this time the addresses are not usable (from the network nor from the userspace); you could set accept_dad=0 which violates some IPv6 RFC and is hard to configure if you have many interfaces; optimistic_dad instead follows a RFC and allows to use the addresses *before* DAD has been completed… if DAD failes the address will be removed
2025-01-02 11:10:07 <liske> later on
2025-01-02 11:11:18 <liske> (it is not activated by default; Debian and others have the kernel option enabled, too)
2025-01-02 11:12:39 <ncopa> ok. thanks for explaining
2025-01-02 11:12:44 <ncopa> makes sense to enable it
2025-01-02 11:12:53 <ncopa> also fedora has it enabled
2025-01-02 11:29:44 <aparcar[m]> pj ncopa should I come back in a week and ask again? 
2025-01-02 11:36:24 <ncopa> aparcar[m]: do you have a machine to connect to CI?
2025-01-02 11:37:02 <ncopa> let me put it this way, once you have a machine to connect to CI, let us know
2025-01-02 11:38:21 <pj> i commented on the issue in apk-tools
2025-01-02 11:38:45 <pj> preferably we could continue that topic there, once something develops (as ncopa said: once you have machine for CI)
2025-01-02 11:39:22 <ncopa> yeah
2025-01-02 11:50:04 <aparcar[m]> just for clarification, I should get a machine from $provider and let you know?
2025-01-02 11:50:11 <aparcar[m]> I'll continue in the thread after that
2025-01-02 11:59:27 <fossdd[m]> ncopa: btw i think i will open a MR with a linux-stable aport based on linux-lts's config once 6.13.1 is released
2025-01-02 11:59:48 <fabricionaweb> happy new year, who wants check my last year's mr !77555
2025-01-02 12:14:06 <fossdd[m]> not again...
2025-01-02 12:14:40 <fossdd[m]> oh and friendly reminder about merging !77734 😅
2025-01-02 13:59:12 <vkrishn> xfce4 is super nice now, some minor issues probably, https://tpaste.us/4vvj from ~/.xsession-errors file
2025-01-02 14:01:06 <vkrishn> it even session saves "number of pager" count and opened apps in it
2025-01-02 15:07:14 <ncopa> those messages are harmless
2025-01-02 15:10:48 <fabled> The accessibility bug is annoying. It's a lightdm issue with patch available. Not sure why it's not applied upstream 
2025-01-02 15:12:42 <fabled> Need to find the patch again 
2025-01-02 15:16:55 <ncopa> fabled: do you have an URL to upstream issue?
2025-01-02 15:22:56 <fabled> ncopa: I think this is what I saw earlier and is the same issue https://bugs.launchpad.net/lightdm-gtk-greeter/+bug/1670933
2025-01-02 15:24:50 <fabled> Seems its merged 
2025-01-02 15:25:30 <fabled> I wonder if it's not yet in release or this is something else
2025-01-02 15:26:15 <ncopa> not unlikely
2025-01-02 15:27:29 <ncopa> oh, there is a new version
2025-01-02 15:27:37 <ncopa> let me bump it
2025-01-02 15:30:39 <ncopa> i tried get a nice lightweight greeter for wayland a couple of weeks ago. got greetd + cage + gtkgreet working, but I cannot say that gtkgreet is very nice
2025-01-02 15:31:00 <ncopa> i am tempted to build one myself, for xfce only
2025-01-02 15:31:01 <fabled> Seems the GitHub and launchpad versions seem to differ.
2025-01-02 15:31:18 <fabled> And the accessibility fix seems to not be in github
2025-01-02 15:31:25 <ncopa> ok
2025-01-02 15:31:39 <ncopa> where do i find the patch from launchpad?
2025-01-02 15:32:03 <ncopa> I find it difficult to find the sources in launchpad
2025-01-02 15:32:35 <fabled> The diff link is in the issue main page. Look for the related branches
2025-01-02 15:33:53 <ncopa> found it, thanks
2025-01-02 15:34:45 <fabled> But agree. Launchpad manages to hide those pretty well
2025-01-02 15:36:49 <ncopa> github has this though: https://github.com/Xubuntu/lightdm-gtk-greeter/commit/7975139dcd92de35ef9c39e0f187803e63654f2f
2025-01-02 15:36:55 <ncopa> which seems to fix same issue?
2025-01-02 15:37:38 <ncopa> it was included since version 2.0.4
2025-01-02 15:38:55 <fabled> Weird
2025-01-02 15:39:04 <fabled> I wonder if the greeter gets killed
2025-01-02 15:41:58 <fabled> Sounds like related issue. Perhaps the exact root cause is slightly different with same symptoms. Or the fix not working in some specific circumstances. But I do get the same warning log a lot also
2025-01-02 15:46:31 <ncopa> https://bugs.launchpad.net/lightdm-gtk-greeter/+bug/1670933/comments/6 mentions systemd?
2025-01-02 17:07:34 <elagost> would someone mind looking at this mr: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77921 waybar on edge segfaults with fmt 11.1.0, this is a minor compatibliity fix
2025-01-02 19:44:07 <Ariadne> yes, i can set up a mac mini or something for CI
2025-01-02 20:32:04 <Ariadne> i have an m2 pro 16gb ram sitting in my closet i could set up as a CI agent tonight
2025-01-02 21:03:28 <ncopa> awesome! https://docs.gitlab.com/runner/install/osx.html
2025-01-02 21:04:04 <ncopa> I can set up the gitlab runner if you add my ssh key
2025-01-02 21:04:54 <ncopa> alternatively we can set it up together, and I'll pass you the token somehow
2025-01-03 06:38:43 <mzh> Hi, I've put a linter for license file subpackage https://gitlab.alpinelinux.org/alpine/infra/atools-go/-/merge_requests/55. Request for some comment
2025-01-03 09:19:52 <frojnd> Happy new year to everyone!
2025-01-03 09:21:06 <frojnd> Who do I buy a beer to merge these two: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76856 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76880
2025-01-03 10:09:22 <ncopa> frojnd: you should buy ptrc a beer for reviewing it.
2025-01-03 10:12:23 <ncopa> and ikke
2025-01-03 10:27:51 <frojnd> Thank you ncopa :) And ikke and ptrc
2025-01-03 10:41:49 <frojnd> ptrc: please pvt me back, when you are online :)
2025-01-03 14:33:05 <fabricionaweb> mzh: Hi, I've put a linter for license file subpackage> that is super nice, I loved it
2025-01-03 16:37:41 <pj> ncurses 6.5_p20241006 is gone
2025-01-03 16:39:16 <pj> 3.21-stable and edge are on 6.5_p20241006
2025-01-03 16:43:38 <quinq> There's still https://invisible-mirror.net/archives/ncurses/6.5/ncurses-6.5-20241006.patch.gz, but yeah that sounds a bit weird to build from /current/ that changes around
2025-01-03 16:49:18 <pj> I think it would be possible to switch to github source
2025-01-03 16:49:38 <pj> https://github.com/ThomasDickey/ncurses-snapshots/releases/tag/v6_5_20241006
2025-01-03 16:59:27 <ncopa> we also keep a copy here: https://distfiles.alpinelinux.org/distfiles/v3.21/ncurses-6.5-20241006.tgz
2025-01-03 17:00:33 <pj> ncopa: that's great but seems really tiresome to switch between sources every update
2025-01-03 17:02:46 <pj> unless someone will keep mirroring ncurses to distfiles.a.o
2025-01-03 17:04:00 <quinq> Well, the safest way seems to be the intended upstream usage, base+patch.tgz
2025-01-03 17:04:05 <quinq> This looks stable
2025-01-03 17:14:02 <pj> safest way would be to purge ncurses from existence
2025-01-03 17:32:18 <quinq> pj, I second :D
2025-01-03 17:48:35 <ncopa> pj: the stable builders has DISTFILES_MIRROR set, so it will first try the distfiles and then fall back to upstream source
2025-01-03 17:49:35 <ncopa> see for example https://build.alpinelinux.org/buildlogs/build-3-21-aarch64/community/autobrr/autobrr-1.56.1-r0.log
2025-01-03 17:49:41 <pj> but that's builders only
2025-01-03 17:49:47 <ncopa> but yeah
2025-01-03 17:50:01 <ncopa> i woudlnt mind nuking ncurses
2025-01-03 17:50:21 <pj> is this abuild or buildrepo config
2025-01-03 18:28:30 <Ariadne> with `dbus-launch startplasma-wayland` i am able to get back into kde after installing `openrc-settingsd`, but sddm keeps crashing :(
2025-01-03 18:53:25 <ncopa> im still on xfce4 with x11
2025-01-03 18:54:54 <Ariadne> i have a controversial take incidentally: i think we should stop using elogind, etc and just pull these things directly from systemd (which can be done without using systemd as init).
2025-01-03 18:57:17 <pj> I believe that was proposed (by you) 2 years ago in the wonderful systemd merge request
2025-01-03 18:57:30 <Ariadne> yes, i still hold this position :P
2025-01-03 18:58:04 <Ariadne> since then: openrc-settingsd is no longer maintained, elogind is barely maintained, etc :p
2025-01-03 18:58:04 <pj> to which I agree, it's just better to use particular components straight from upstream
2025-01-03 18:58:26 <ncopa> we probably dont have much of a choice
2025-01-03 18:58:59 <quinq> Why not maintaining elogind instead, which sounds like… What you want to do?
2025-01-03 18:59:32 <Ariadne> i have nothing to do with maintaining elogind, so... not really?
2025-01-03 18:59:34 <pj> who wants to maintain elogind?
2025-01-03 18:59:44 <pj> first time I hear such thing
2025-01-03 19:00:08 <quinq> Isn't elogind systemd's login thing?
2025-01-03 19:00:15 <Ariadne> it is a fork
2025-01-03 19:00:32 <ncopa> not well maintained
2025-01-03 19:00:34 <quinq> Ah, it has diverged
2025-01-03 19:00:37 <Ariadne> it is also not supporting some current d-bus message types, but it hasn't so far been a serious issue
2025-01-03 19:00:52 <quinq> I thought it was just systemd login extracted from systemd
2025-01-03 19:00:58 <ncopa> we are in the same situation with eudev
2025-01-03 19:01:11 <pj> quinq: it is
2025-01-03 19:01:13 <Ariadne> eudev is dead, i haven't seen a single PR there in years
2025-01-03 19:01:25 <quinq> So…
2025-01-03 19:01:34 <pj> but if you fork off and try to pull in changes occassionally it will lag behind
2025-01-03 19:01:35 <quinq> “pull these things directly from systemd”
2025-01-03 19:01:41 <quinq> Which is what this elogind does
2025-01-03 19:01:48 <Ariadne> no, that is not what elogind does
2025-01-03 19:01:57 <Ariadne> they pull very select commits from systemd, sometimes
2025-01-03 19:02:03 <Ariadne> based on vibes
2025-01-03 19:02:14 <quinq> ok
2025-01-03 19:02:32 <pj> IMO, replace elogind with sd-logind, replace gummitboot with sd-boot, replace eudev with sd-udev
2025-01-03 19:02:38 <quinq> Just sounds like a bit of a waste to duplicate effort
2025-01-03 19:02:53 <Ariadne> yes, it is.  that is why i propose just using systemd directly for those components
2025-01-03 19:03:13 <ncopa> problem is that systemd is not designed to be used in parts only
2025-01-03 19:03:18 <ncopa> its all or nothing
2025-01-03 19:03:22 <pj> no
2025-01-03 19:03:27 <Ariadne> not true anymore
2025-01-03 19:03:28 <pj> please stop with that lie
2025-01-03 19:03:35 <Ariadne> for a long time, it isn't true
2025-01-03 19:03:48 <Ariadne> i could switch these packages this afternoon and we would still have openrc as init :P
2025-01-03 19:04:07 <Ariadne> (i will acknowledge doing this technically creates the scenario for "systemd as gateway drug", but systemd's approach to init is so not-alpine that i am not worried about it)
2025-01-03 19:04:20 <ncopa> can you build the sd-logind alone?
2025-01-03 19:04:22 <Ariadne> yes
2025-01-03 19:04:23 <quinq> A lie is intentional, let's not call names
2025-01-03 19:04:48 <pj> it has been intentionally spread by people who don't like systemd
2025-01-03 19:04:54 <ncopa> i mean, it used to be "possible" but the configure script would fail if deps for the other parts were missing
2025-01-03 19:04:57 <quinq> As you said, it was true at some point
2025-01-03 19:05:04 <quinq> Let's not put affect into it
2025-01-03 19:05:15 <ncopa> it was not designed to be split originally
2025-01-03 19:05:38 <ncopa> but its classic microsoft. you only need one component
2025-01-03 19:05:47 <ncopa> but you get 5 other for free
2025-01-03 19:05:57 <pj> why is microsoft brought up in this
2025-01-03 19:06:01 <quinq> EEE
2025-01-03 19:06:15 <ncopa> so there is no point use other products for the other 4 things, since you already paid for it
2025-01-03 19:06:49 <Ariadne> that is an argument, but i don't think it holds, as the init system and other microservices can be isolated into subpackages
2025-01-03 19:06:51 <pj> this conversation is as dumb as previous usr-merge conversations
2025-01-03 19:06:54 <ncopa> like when you got 5 windows licenses with hyper-v. why would you use qemu/vmware if you had to buy the windows licenses anyway
2025-01-03 19:07:09 <quinq> pj, don't take things personally
2025-01-03 19:07:30 <pj> why should I not?
2025-01-03 19:07:37 <Ariadne> well the coc says not to for one
2025-01-03 19:07:48 <quinq> Because it's not about you
2025-01-03 19:08:11 <quinq> Anyway, if systemd components can now be built independently, indeed there's no need for elogind anymore I suppose
2025-01-03 19:08:12 <ncopa> i would love to make my own init system, but it is me against microsoft
2025-01-03 19:08:20 <pj> systemd mr was also apparently not about me
2025-01-03 19:08:24 <pj> and yet
2025-01-03 19:08:26 <quinq> Does systemd try to be a bit more portable too, or do they still rely on glibc?
2025-01-03 19:08:44 <ncopa> they explicitly don't support musl
2025-01-03 19:08:45 <Ariadne> yes, portability situation is improving
2025-01-03 19:08:48 <ncopa> only glibc
2025-01-03 19:08:49 <Ariadne> not true anymore
2025-01-03 19:09:04 <Ariadne> adelie devs have managed to get musl fixes into systemd
2025-01-03 19:09:04 <ncopa> they officially support musl?
2025-01-03 19:09:10 <pj> adelie linux is working with L.P on fixing musl compat
2025-01-03 19:09:15 <quinq> Maybe not officially :/
2025-01-03 19:09:23 <quinq> But it's at least something if they accepted patches!
2025-01-03 19:09:39 <ncopa> yeah, you get fixes in there, but you cannot really say "this is to fix musl" as argument
2025-01-03 19:10:08 <Ariadne> well, that view is aligned with musl's view
2025-01-03 19:10:08 <quinq> No, it's to fix systemd! :)
2025-01-03 19:10:25 <Ariadne> remember, musl does not provide `#define MUSL` for a reason
2025-01-03 19:10:45 <ncopa> and systemd does not care about POSIX
2025-01-03 19:10:59 <pj> weird, because last PR in systemd I saw was "this is to fix musl"
2025-01-03 19:11:00 <ncopa> so you cannot say "this is compat with posix"
2025-01-03 19:11:04 <ncopa> or you could not, at least
2025-01-03 19:11:05 <pj> and it's merged
2025-01-03 19:11:10 <Ariadne> ncopa: that is also allowed now
2025-01-03 19:11:29 <pj> obviously systemd is not going to turn world upside down for musl
2025-01-03 19:11:38 <ncopa> so things are changed
2025-01-03 19:11:50 <quinq> fixing software = turning world upside down?
2025-01-03 19:12:04 <Ariadne> with that said, i think right now from alpine's perspective, we are on the worse side of the various anti-systemd forks for these microservices
2025-01-03 19:12:17 <Ariadne> and i think that is what actually matters
2025-01-03 19:12:38 <ncopa> yeah, as I said, I dont think we have much of a choice
2025-01-03 19:12:58 <ncopa> sd-logind, sd-udev and what more?
2025-01-03 19:13:10 <Ariadne> yeah those
2025-01-03 19:13:18 <pj> sd-boot
2025-01-03 19:13:21 <ncopa> yeah
2025-01-03 19:13:23 <ncopa> sd-boot
2025-01-03 19:13:25 <ncopa> makes sense
2025-01-03 19:13:43 <pj> (I wouldn't mind if I could actually use full systemd on alpine anyway)
2025-01-03 19:13:49 <pj> :_
2025-01-03 19:13:51 <pj> :)
2025-01-03 19:13:57 <ncopa> i think you can with postmarkedOS
2025-01-03 19:14:21 <ncopa> the issues with systemd has mostly been soft issues
2025-01-03 19:14:23 <Ariadne> i have no objection to packaging the init, with the usual caveat of switching alpine's init from openrc applying (you keep the pieces when it breaks)
2025-01-03 19:15:10 <Ariadne> i am just tired of the "upstream depends on a new systemd-provided microservice, find the right alternative provider for it, debug said alternative" loop
2025-01-03 19:15:56 <ncopa> and it is difficult to justify writing alternatives
2025-01-03 19:16:05 <ncopa> when you have the reference implementation
2025-01-03 19:18:53 <pj> Ariadne: btw. are you volunteering to maintain sd-* package(s)?
2025-01-03 19:19:37 <Ariadne> yes, i am willing to help maintain systemd in alpine (though i would prefer to stay with openrc for now for init)
2025-01-03 19:20:08 <pj> I thought that init remains unchanged
2025-01-03 19:20:24 <Ariadne> yes, i am just being extremely clear in my intentions here
2025-01-03 19:20:30 <ncopa> those links to elogind-dev: https://tpaste.us/j11V
2025-01-03 19:21:14 <Ariadne> yep, which probably means my sddm is broken because elogind doesn't actually implement something it needs to
2025-01-03 19:21:25 <ncopa> elogind* - and with proper sort -u: https://tpaste.us/Drrl
2025-01-03 19:21:52 <pj> I would would certainly be happy with the same plan as was discussed in systemd MR, where systemd is packaged completely but no work is going to be done to make it be an init/rc and no subpackages will be done for service unit and no package will be modified to link to systemd
2025-01-03 19:22:15 <ncopa> packages need to link to systemd
2025-01-03 19:22:16 <pj> (exception logind)
2025-01-03 19:22:20 <Ariadne> i mean, i am not even against there being a "alpine, but with systemd as init" variant
2025-01-03 19:22:22 <quinq> What does elogind do though? Just make some directories in /run or something, no?
2025-01-03 19:22:43 <Ariadne> it does a number of things
2025-01-03 19:22:44 <ncopa> seat management as well
2025-01-03 19:23:00 <Ariadne> seat management, session management, authentication (though mostly as a bridge into PAM), ...
2025-01-03 19:23:24 <pj> ncopa: not everything, there's stuff like hostnamectl that is not a requirement and does not need to be linked to (I've heard recently that MATE desktop links to systemd for some hostname stuff)
2025-01-03 19:25:46 <ncopa> does sd-logind depend on journald for logging?
2025-01-03 19:26:02 <Ariadne> no
2025-01-03 19:26:25 <Ariadne> internally systemd components all just use syslog
2025-01-03 19:26:36 <Ariadne> and then depend on journald to be the syslog daemon
2025-01-03 19:30:26 <invoked> how would libsystemd be packaged?
2025-01-03 19:31:14 <invoked> in other words would the stuff that depends on elogind just switch to, i guess, 'libsystemd'?
2025-01-03 19:31:40 <Ariadne> probably
2025-01-03 19:31:58 <ncopa> polkit-elogind depends on so:libelogind.so.0
2025-01-03 19:32:04 <ncopa> will need to be rebuilt
2025-01-03 19:32:12 <ncopa> or have different packages
2025-01-03 19:32:31 <ncopa> sddm does not seem to link to libelogind
2025-01-03 19:32:51 <ncopa> so it probably only needs it via dbus
2025-01-03 19:33:04 <ncopa> so we can solve that with providers
2025-01-03 19:33:19 <ncopa> eg you can choose between elogind or sd-logind
2025-01-03 19:33:45 <Ariadne> yeah but there is no real point in keeping elogind
2025-01-03 19:34:20 <ncopa> will still need to have a migration plan
2025-01-03 19:34:30 <ncopa> $ apk list --depends so:libelogind.so.0 | tpaste
2025-01-03 19:34:30 <ncopa> https://tpaste.us/BMMR
2025-01-03 19:34:47 <ncopa> sigh. i get doubles
2025-01-03 19:34:58 <ncopa> $ apk list --depends so:libelogind.so.0 | sort -u | tpaste
2025-01-03 19:34:58 <ncopa> https://tpaste.us/bQQB
2025-01-03 19:38:07 <Ariadne> that's not too bad of an rdepends set
2025-01-03 19:38:28 <Ariadne> (though i have questions about some of those packages depending on elogind in the first place o.O)
2025-01-03 19:39:43 <ncopa> polkit has two variants, one for consolekit and one for elogind
2025-01-03 19:39:51 <ncopa> consolekit is now gone
2025-01-03 19:40:06 <ncopa> so it does not make sense with a separate polkit-elogind
2025-01-03 19:41:11 <ncopa> i'd suggest with focusing on elogind first, or eudev
2025-01-03 19:41:15 <ncopa> and not all at once
2025-01-03 19:41:32 <ncopa> and maybe call the subpackage logind instead of systemd-logind
2025-01-03 19:41:51 <Ariadne> i was going to start with eudev, since i can say with upstream authority that one is dead
2025-01-03 19:41:53 <ncopa> people will go bananas if they discover a systemd-* package on their system :)
2025-01-03 19:42:07 <ncopa> name it udev
2025-01-03 19:42:14 <ncopa> and not systemd-udev
2025-01-03 19:42:19 <pj> sd-udev?
2025-01-03 19:42:36 <ncopa> but thats just my humble opinion
2025-01-03 19:42:52 <ncopa> sd-udev may work as well, but not sure how much sense it makes
2025-01-03 19:43:30 <pj> there's only so much you can do to shield users from ignorance and discovering systemd.so
2025-01-03 19:43:55 <orbea> you will be getting rid of one of alpine's main selling points, RIP
2025-01-03 19:44:03 <pj> thank you matrix for formatting
2025-01-03 19:44:17 <pj> orbea: which one?
2025-01-03 19:44:24 <ncopa> distro without systemd
2025-01-03 19:44:28 <pj> eudev/elogind is still systemd code
2025-01-03 19:44:29 <ncopa> "i want that!"
2025-01-03 19:44:57 <invoked> to me, this is a discussion of which polyfill is worse. unmaintained shit is probably worse
2025-01-03 19:45:17 <orbea> so have something maintained by large corporate interests instead
2025-01-03 19:45:43 <quinq> ncopa, what about "alpined"? :>
2025-01-03 19:46:02 <pj> there's definite lack of "alpinectl" on my machine
2025-01-03 19:47:07 <quinq> For doing what?
2025-01-03 19:47:44 <ncopa> doesnt matter :)
2025-01-03 19:49:23 <pj> I just hope it allows backdoors via xz
2025-01-03 19:50:22 <pj> but back to being serious, I think that statement "alpine without systemd" has not been true ever since elogind/eudev have been part of it
2025-01-03 19:50:53 <ncopa> it is possible to run servers without those
2025-01-03 19:51:29 <Ermine> that meant 'alpine without systemd as pid 1' i guess
2025-01-03 19:51:45 <ncopa> and you can run alpine without udev too
2025-01-03 19:51:52 <pj> you can still run servers without sd-logind/sd-udev?
2025-01-03 19:51:59 <ncopa> yes
2025-01-03 19:52:06 <Ermine> servers yes
2025-01-03 19:52:15 <pj> so I don't understand the argument "distro without systemd" and "getting rid of one of alpine's main selling points"
2025-01-03 19:52:19 <Ermine> desktops basically need udev anyway
2025-01-03 19:52:23 <ncopa> yes
2025-01-03 19:53:17 <quinq> I don't have elogind here
2025-01-03 19:53:23 <quinq> On the laptop
2025-01-03 19:53:34 <pj> you can hack mdev and there are alternatives to (e)logind
2025-01-03 19:53:50 <ncopa> you dont find "distro without systemd" anywhere on the official website though
2025-01-03 19:54:44 <quinq> pj, the argument is that some people don't want systemd on their system, so Alpine offers something that tries to fulfil this
2025-01-03 19:55:08 <Ermine> mdev + libudev-zero is probably possible, but again, a whole bunch of stuff doesn't work with it without patching (and I'm not sure available patches are correct)
2025-01-03 19:55:11 <quinq> Now, we agreed there's already a couple of its parts here
2025-01-03 19:55:16 <pj> we're replacing systemd code with systemd code
2025-01-03 19:55:46 <quinq> It's not about its code I think
2025-01-03 19:56:09 <pj> "wait, it all systemd"
2025-01-03 19:56:09 <pj> "always has been"
2025-01-03 19:56:30 <quinq> Doesn't parse
2025-01-03 19:56:31 <ncopa> the problem with systemd is not the code. the problem is all the noise around it
2025-01-03 19:56:50 <pj> yeah, but you can't really avoid it
2025-01-03 19:56:53 <pj> it's just living in denial
2025-01-03 19:57:05 <quinq> Well
2025-01-03 19:57:15 <quinq> Look at Alpine for one counter example
2025-01-03 19:57:26 <pj> I'm looking
2025-01-03 19:57:34 <quinq> And it's not using systemd
2025-01-03 19:57:47 <pj> what is "not using systemd"
2025-01-03 19:57:56 <pj> what does that mean
2025-01-03 19:58:11 <pj> the whole I'm making is that alpine is using systemd via eudev/elogind
2025-01-03 19:58:16 <pj> whole point*
2025-01-03 19:58:19 <quinq> If you don't understand, it'll be a bit hard to try to explain
2025-01-03 19:58:33 <quinq> Yeah, I wouldn't say that's using systemd
2025-01-03 19:58:41 <pj> the only thing that changes is that one has label "not systemd" and other has label "systemd"
2025-01-03 19:58:55 <pj> if you mean using init, then that's not changing
2025-01-03 19:58:56 <Ariadne> cursed idea: change libsystemd soname to libelogind
2025-01-03 19:59:04 <pj> otherwise what's the difference?
2025-01-03 19:59:05 <ncopa> lol
2025-01-03 19:59:10 <quinq> Does it really matter, Ariadne? :)
2025-01-03 19:59:22 <quinq> pj, again if you can't just see the different, not sure how to explain it
2025-01-03 19:59:36 <quinq> Have you been using distros that effectively use systemd?
2025-01-03 19:59:43 <pj> Yes?
2025-01-03 19:59:53 <quinq> Have you been using Alpine?
2025-01-03 19:59:57 <pj> Yes?
2025-01-03 20:00:06 <quinq> Now, do you see any difference between both regarding systemd?
2025-01-03 20:00:12 <pj> No
2025-01-03 20:00:14 <ncopa> Ariadne: i think thats brilliant
2025-01-03 20:00:15 <Ermine> While at it, how does one actually build systemd for alpine?
2025-01-03 20:00:27 <quinq> Well, you won't be able to get it then I fear :/
2025-01-03 20:00:30 <pj> Look at postmarketOS systemd package
2025-01-03 20:00:40 <pj> quinq: I think the problem is on your side
2025-01-03 20:00:45 <quinq> Sure sure :)
2025-01-03 20:00:48 <ncopa> Ariadne: but I hate it
2025-01-03 20:00:51 <ncopa> :D
2025-01-03 20:01:17 <pj> I vote for "cant-believe-its-nay-systemd.so"
2025-01-03 20:01:46 <quinq> Honestly I don't think it makes sense to rename things
2025-01-03 20:01:52 <quinq> That would actually be a lie there
2025-01-03 20:02:21 <quinq> If the decision to use libsystemd is taken, let's be honest but clear about it
2025-01-03 20:02:27 <quinq> What it means and imply
2025-01-03 20:02:29 <pj> quinq: well, you can't explain the difference, so it sounds like there is none
2025-01-03 20:02:37 <quinq> Sure sure :)
2025-01-03 20:02:46 <Ariadne> i was mostly kidding
2025-01-03 20:02:51 <quinq> ok ^^
2025-01-03 20:03:01 <pltrz[m]> Ariadne: libsystemd to libelogind is hilarious
2025-01-03 20:03:03 <pltrz[m]> lol
2025-01-03 20:03:20 <ncopa> changing name to libelogind solves a technical problem though, you avoid rebuild all the packages currently linked to it
2025-01-03 20:03:28 <Ariadne> i think "you already had systemd components on your system, they just weren't properly maintained and probably have CVE-worthy vulnerabilities in them, we got rid of this situation for you" is a fully defensible situation :P
2025-01-03 20:03:41 <quinq> yeah
2025-01-03 20:04:07 <ncopa> and we can still ship the tiny default iso images without systemd
2025-01-03 20:04:34 <quinq> ncopa, good point, though only a short-term one
2025-01-03 20:04:41 <quinq> (rebuild part)
2025-01-03 20:05:05 <Ariadne> alpine with openrc is not going anywhere, probably won't ever go anywhere because there's too many unknowns in switching the init away (even if openrc maintenance situation is... wavering between a bus factor of 0 and 1 for years now)
2025-01-03 20:05:44 <quinq> :)
2025-01-03 20:05:51 <ncopa> i have been thinking of dinit or even write my own init
2025-01-03 20:06:03 <quinq> runit is nice too
2025-01-03 20:06:05 <pj> I don't think openrc being init also has been one of the largest issues there is in Alpine
2025-01-03 20:06:09 <pj> sure it has some, peculiarities, but it's fine
2025-01-03 20:06:15 <pj> uhm, busybox
2025-01-03 20:06:29 <pj> you keep talking about openrc init but we use bb
2025-01-03 20:06:36 <ncopa> also been thinking alot of making a new udev alternative
2025-01-03 20:06:41 <Ariadne> by init i mean "service manager"
2025-01-03 20:07:05 <Ariadne> anyway, the world i want for alpine is one where you use whatever service management you want
2025-01-03 20:07:15 <quinq> \o/
2025-01-03 20:07:15 <Ariadne> openrc, systemd, dinit, s6, whatever
2025-01-03 20:07:31 <pltrz[m]> I was curious - does the OpenRC choice in alpine, come from origins as a gentoo fork?
2025-01-03 20:07:32 <pj> ncopa: would it not be better to use something pre-existing and improve upon that? like mdev?
2025-01-03 20:07:36 <Ariadne> just without the bitrot of all of these "we forked some specific part of systemd 4 years ago" projects
2025-01-03 20:07:53 <ncopa> pj: like mdevd
2025-01-03 20:08:02 <Ariadne> $dayjob is rewriting kmod btw, with parallelized `depmod`
2025-01-03 20:08:43 <ncopa> pj: the idea is to mix in Lua
2025-01-03 20:09:01 <pj> ugh
2025-01-03 20:09:05 <ncopa> instead of forking external progs, use Lua plugins
2025-01-03 20:09:18 <pj> which lua version ? :>
2025-01-03 20:09:19 <quinq> What's $dayjob, Ariadne, if you don't mind of course?
2025-01-03 20:09:22 <ncopa> instead of shell scripts, use Lua
2025-01-03 20:09:44 <ncopa> latest
2025-01-03 20:09:50 <quinq> busybox-lua
2025-01-03 20:10:17 <ncopa> i even suggsted add lua as a busybox applet once :)
2025-01-03 20:11:05 <ncopa> problem with Lua is the multiple versions, and not being able to get rid of old versions
2025-01-03 20:11:14 <ncopa> its too fragmented
2025-01-03 20:11:31 <ncopa> but you get alot bang for the bucks with Lua
2025-01-03 20:11:35 <Ariadne> quinq: i don't really know how to describe it, we are basically a bespoke cloud-native security firm with a product that can turn any docker image into something vaguely shaped like a unikernel
2025-01-03 20:11:43 <quinq> Wasn't also something backwards with Lua regex?
2025-01-03 20:12:10 <quinq> That's good, thanks Ariadne :)
2025-01-03 20:12:43 <quinq> (just don't get what's “cloud-native”, but I can search)
2025-01-03 20:13:00 <Ariadne> oh that's just the trendier way of saying "kubernetes"
2025-01-03 20:13:05 <quinq> (as for me those two words are antinomic)
2025-01-03 20:16:02 <pj> can the hardcoded -O2 be removed from aports?
2025-01-03 20:16:15 <invoked> ncopa: i'd love to see what you'd come up with for init or udev. however, would you really want to maintain that stuff long term
2025-01-03 20:17:14 <pj> someone should make s6-udev
2025-01-03 20:17:40 <invoked> or maybe it's a question of could... i've had to reckon with my limitations these past 10 years
2025-01-03 20:17:43 <Ermine> that's mdevd
2025-01-03 20:20:08 <Ariadne> pj: skarnet already did, that's what mdevd is
2025-01-03 20:21:31 <Ariadne> anyway...
2025-01-03 20:21:53 <Ariadne> i need to find an ethernet cable, but i have a mac mini that can act as a gitlab runner.  i have no idea how to set it up though
2025-01-03 20:22:29 <pj> https://docs.gitlab.com/runner/install/osx.html
2025-01-03 20:23:28 <pj> when you run the install command it should ask you for token which you or someone else can get from gitlab
2025-01-03 20:23:44 <Ariadne> cool
2025-01-03 20:23:50 <pj> maybe ncopa is still near pc to help out
2025-01-03 20:24:34 <quinq> ../src/basic/stdio-util.h:4:10: fatal error: printf.h: No such file or directory
2025-01-03 20:24:39 <quinq> Not there yet xD
2025-01-03 20:25:22 <fossdd[m]> quinq: what are you trying to do?
2025-01-03 20:25:51 <quinq> Build systemd
2025-01-03 20:25:56 <Ariadne> fossdd[m]: compile systemd without the patchset
2025-01-03 20:26:03 <quinq> Not really trying though, just wanted to have a quick look at current state
2025-01-03 20:26:07 <Ariadne> though adelie has reduced that patchset to like 3 or 4 now
2025-01-03 20:26:15 <fossdd[m]> oh yeah
2025-01-03 20:26:38 <fossdd[m]> yeah but afaik adelie doesnt care about upstreaming stuff or working together
2025-01-03 20:26:39 <Ariadne> why would apple put a power button on the bottom of a computer
2025-01-03 20:26:46 <fossdd[m]> no idea
2025-01-03 20:26:51 <fossdd[m]> classic apple ig
2025-01-03 20:27:01 <ncopa> maybe the computer is upside down
2025-01-03 20:27:06 <invoked> it's not meant to be turned off
2025-01-03 20:27:11 <ncopa> its late here
2025-01-03 20:27:12 <Ariadne> no, it's definitely the bottom
2025-01-03 20:27:18 <quinq> It's a bit like “Why would Thinkpad put the battery indicator on the *back* of the laptop”
2025-01-03 20:27:30 <ncopa> have a nice evening everyone!
2025-01-03 20:27:35 <quinq> You too ncopa :)
2025-01-03 20:27:36 <fossdd[m]> the same reason why the power cable has to be inserted on the buttom of the mouse
2025-01-03 20:27:45 <Ariadne> they fixed that one finally
2025-01-03 20:27:48 <fossdd[m]> ncopa: you too!
2025-01-03 20:27:49 <Ariadne> with the usb-c version
2025-01-03 20:27:55 <fossdd[m]> oh really
2025-01-03 20:28:29 <nu[m]> whats the reason for more systemd code making it's way into alpine? are desktop projects depending on it too hard or is it that there arent just enough maintainers to keep some useful code in shape?
2025-01-03 20:28:50 <fossdd[m]> elogind is basically unmaintained and is lots of work for no real gain
2025-01-03 20:29:06 <Ariadne> elogind *is* systemd code, just with somebody scribbling "totally not systemd" on it
2025-01-03 20:29:26 <Ariadne> i would rather have the real systemd code with the real vulnerability fixes than some fork that is barely maintained
2025-01-03 20:29:30 <fossdd[m]> systemd is really not that bad, of course its a big mono repo but so is alpine or linux
2025-01-03 20:29:34 <nu[m]> then what's preventing the world to have a non systemd elogind?
2025-01-03 20:29:45 <quinq> nu[m], apparently the actual reason here is that some packages rely on some features not provided (yet?) by elogind
2025-01-03 20:29:45 <pj> nu: no one wants to maintain that
2025-01-03 20:30:02 <invoked> sddm is crashing, is what i recall this started with
2025-01-03 20:30:13 <Ermine> nobody has written 'non-systemd logind'
2025-01-03 20:30:15 <fossdd[m]> nu[m]: for what gain?
2025-01-03 20:30:22 <Ariadne> sddm is still crashing, incidentally
2025-01-03 20:30:32 <fossdd[m]> there already exists systemd and works awesome
2025-01-03 20:30:32 <pj> this is basically the same thing as "why is everyone pushing wayland and not fixing x11" with answer "no one wants to work on x11, duh"
2025-01-03 20:30:57 <quinq> Instead, make the same mistakes in wayland :D
2025-01-03 20:30:59 <fossdd[m]> yea and to fix x11 you basically have to rewrite x11 and that is wayland
2025-01-03 20:31:13 <Ariadne> anyway alpine is not nor has ever been "anti systemd", regardless of how much 4chan insists otherwise
2025-01-03 20:31:14 <quinq> Next graphical gen env will fix those issues, promise
2025-01-03 20:31:19 <Ariadne> i'm just being blunt
2025-01-03 20:31:20 <fossdd[m]> quinq: nah a lot of stuff was fixed with wayland
2025-01-03 20:31:29 <Ariadne> we use whatever we need to make alpine work
2025-01-03 20:31:31 <nu[m]> yeah, but for me its weird that there is the systemd way or no way
2025-01-03 20:31:44 <invoked> we're literally talking about a third way here
2025-01-03 20:31:56 <quinq> nu[m], that's because systemd is mostly (or at least “was”) that
2025-01-03 20:32:05 <pj> again, we're not making alpine using complete systemd suite
2025-01-03 20:32:07 <quinq> It's not the opposite
2025-01-03 20:32:14 <Ariadne> the third way was "use forks of systemd that bitrot" :p
2025-01-03 20:32:16 <fossdd[m]> nu[m]: yea feel free to write a own logind and compete with systemd
2025-01-03 20:32:19 <pj> we want to replace outdated systemd forks with updated systemd code
2025-01-03 20:32:28 <quinq> nu[m], sorry, misunderstood what you meant there :)
2025-01-03 20:32:30 <Ermine> on that
2025-01-03 20:33:00 <Ermine> if I build pmos's systemd package and install it and make a service for sd-logind for example, will it work?
2025-01-03 20:33:11 <Ariadne> yes
2025-01-03 20:33:13 <fossdd[m]> yes
2025-01-03 20:33:14 <invoked> pmos went full systemd w/init? i forget what happened there.
2025-01-03 20:33:28 <Ariadne> invoked: no, its optional.  you can still have pmos with openrc
2025-01-03 20:33:30 <fossdd[m]> invoked: pmos tries to offer systemd as a alternative top openrc
2025-01-03 20:33:38 <fossdd[m]> its still optional and is still in development
2025-01-03 20:33:54 <invoked> ah, thanks
2025-01-03 20:34:02 <Ariadne> my pmOS machines (which are mainly weird ones that would require ugly hacks to run mainline alpine on) are all running openrc
2025-01-03 20:34:10 <Ariadne> i don't foresee that changing anytime soon :p
2025-01-03 20:34:39 <fossdd[m]> i have a small (big) systemd addiction, so i have to use it :p
2025-01-03 20:34:41 <fossdd[m]> but i love it
2025-01-03 20:34:47 <Ermine> I'm just fact-checking "you can run systemd microservices without systemd-the-pid 1"
2025-01-03 20:35:05 <Ariadne> yep
2025-01-03 20:35:05 <pj> yes, you can
2025-01-03 20:35:58 <Ariadne> wtf this mac uses a non-grounded power cable
2025-01-03 20:35:59 <fossdd[m]> btw http://0pointer.de/blog/projects/the-biggest-myths.html and https://0pointer.net/blog/projects/why.html are good articles about myths about systemd
2025-01-03 20:36:09 <pj> chimera also is one of the distros that uses certain systemd components but not systemd init
2025-01-03 20:36:38 <Ariadne> gross gross gross
2025-01-03 20:36:43 <fossdd[m]> yeah they also maintain https://github.com/chimera-linux/sd-tools
2025-01-03 20:37:02 <fossdd[m]> i feel like they rebuild systemd without systemd
2025-01-03 20:37:42 <Ermine> I've read that myths article, and iirc there are both fair points and bullshit points
2025-01-03 20:37:57 <quinq> fossdd[m], that's more than 10 yo
2025-01-03 20:38:08 <fossdd[m]> quinq: and still valid
2025-01-03 20:38:29 <pj> always has been
2025-01-03 20:40:25 <pj> whyyyyyy is there so much -O2 hardcoded
2025-01-03 20:40:56 <invoked> in the absence of anybody who wants to do that work (systemd polyfills), and elogind bitrot, it doesn't really feel like it's even a discussion
2025-01-03 20:41:13 <invoked> either it gets removed or we pull systemd
2025-01-03 20:41:45 <Ariadne> not just elogind, openrc-settingsd was last maintained by pmOS before they switched to systemd :P
2025-01-03 20:41:48 <quinq> fossdd[m], I remember having read that at the time, still very oriented :)
2025-01-03 20:41:53 <invoked> or someone forks elogind which doesn't really make sense either
2025-01-03 20:42:24 <pj> openrc-settingsd is archived
2025-01-03 20:42:30 <pj> effectively unmaintained
2025-01-03 20:42:33 <quinq> invoked, or help is given to elogind
2025-01-03 20:42:55 <Ermine> and then someone forks elogind fork because it got unmaintained, and ad infinitum
2025-01-03 20:42:55 <fossdd[m]> and no one ever told me a good reason not to package systemd and use its logind
2025-01-03 20:43:03 <quinq> Just because there's no new code added doesn't mean that it's “bit-rotting”
2025-01-03 20:43:29 <pj> it certainly does
2025-01-03 20:43:30 <fossdd[m]> pj: no? https://gitlab.postmarketos.org/postmarketOS/openrc-settingsd/
2025-01-03 20:43:45 <fossdd[m]> they switched to a own gitlab instance, so gitlab.com's repo is archived
2025-01-03 20:43:56 <pj> I stand correcte
2025-01-03 20:43:57 <fossdd[m]> afaik its in maintainance mode but still
2025-01-03 20:43:59 <pj> * I stand corrected
2025-01-03 20:44:14 <invoked> the rate of change on systemd is fairly high, at least some of those are secfixes
2025-01-03 20:44:17 <pj> did open gitlab.com/*
2025-01-03 20:44:32 <quinq> invoked, that makes sense to pull of course
2025-01-03 20:44:58 <Ariadne> ah i see
2025-01-03 20:45:15 <Ariadne> well still it's just maintenance burden verses just use the real systemd code
2025-01-03 20:45:31 <pj> I believe that pmOS still has plans to make rc-settingd archived tho?
2025-01-03 20:45:48 <pj> (as per the blog post)
2025-01-03 20:46:13 <fossdd[m]> not sure where you red that
2025-01-03 20:46:25 <fossdd[m]> since openrc is still being supported on pmos it makes not much sense to archive it
2025-01-03 20:46:32 <fossdd[m]> but i might be wrong
2025-01-03 20:47:08 <pj> it could be gitlab issue, but I remember burden of maintaining polyfill mentioned
2025-01-03 20:47:48 <Ariadne> fossdd[m]: my goal is to arrive at a state where we have "just enough systemd" to avoid this polyfill mess, while retaining openrc (or s6, or dinit, or whatever) as service manager
2025-01-03 20:48:20 <fossdd[m]> yes this would be awesome
2025-01-03 20:48:22 <Ariadne> so, if we succeed, then openrc-settingsd is functionally obsolete
2025-01-03 20:48:39 <fossdd[m]> yes and so would be elogind, etc
2025-01-03 20:48:44 <fossdd[m]> sounds like a reasonable goal
2025-01-03 20:51:03 <quinq> Would be even more reasonable if upstream would be interested in making it more portable
2025-01-03 20:51:14 <fossdd[m]> they are
2025-01-03 20:51:35 <quinq> Nice
2025-01-03 20:51:56 <fossdd[m]> i think https://media.ccc.de/v/all-systems-go-2024-278-systemd-ifying-postmarketos-our-immutable-future-and-why-alpine-is-cooler-than-you-thought explains a lot quite nice
2025-01-03 20:52:17 <fossdd[m]> i think lennart even talks in the q&a
2025-01-03 20:52:29 <pj> we mentioned it at the beginning but, adelie linux devs are working on making systemd work with musl
2025-01-03 20:52:39 <Ariadne> as are pmOS
2025-01-03 20:52:41 <Ariadne> and others
2025-01-03 20:53:13 <pj> well, yocto has been making patches to at least make it compilable :P
2025-01-03 20:54:17 <invoked> systemd stuff changes a lot though, which beyond any philosophical reasons, is more work
2025-01-03 20:54:33 <fossdd[m]> wdym?
2025-01-03 20:55:01 <quinq> Maintenance burden
2025-01-03 20:55:05 <quinq> I suppose
2025-01-03 20:55:09 <pj> I'm going to say what I said before: patching systemd is not more work or worse than patching gcc or busybox
2025-01-03 20:55:30 <quinq> Well, it was at least
2025-01-03 20:55:32 <fossdd[m]> well its a active project with a lot of contributors
2025-01-03 20:56:07 <fossdd[m]> and there are obviously a lot of people who would take that maintainance burden
2025-01-03 20:56:34 <invoked> i haven't looked in a while but they bump every couple weeks, from what i remember
2025-01-03 20:56:36 <quinq> fossdd[m], it's not about systemd, it's about systems that have it as a dependecy
2025-01-03 20:56:39 <quinq> *dependency
2025-01-03 20:56:59 <pj> invoked: there is lts
2025-01-03 20:57:20 <Ariadne> well the "problem" really is that we have evolved our way of thinking from a security perspective
2025-01-03 20:57:31 <pj> https://github.com/systemd/systemd-stable
2025-01-03 20:57:40 <Ariadne> in the old days, we would use `gksudo`, and programs would just become root and do things as root
2025-01-03 20:57:42 <invoked> pj: roger that
2025-01-03 20:57:53 <Ariadne> then we slowly shifted to a more OCAP-based model with d-bus services
2025-01-03 20:58:11 <Ariadne> systemd just wound up becoming the catchall for the latest iterations of those d-bus services
2025-01-03 20:58:15 <fossdd[m]> quinq: i dont have more work with systemd systemds than with openrc ones? quite the opposite, but this isnt even about using systemd as a service manager
2025-01-03 20:58:49 <invoked> so systemd-stable looks like what, once a month?
2025-01-03 20:59:14 <fossdd[m]> systemd-stable is maintained by distros, so as long as distros use it a version is maintained
2025-01-03 20:59:15 <invoked> i paged back a few, the cadence looks like once a month.
2025-01-03 20:59:29 <fossdd[m]> so for alpine's lifespan of releases: basically forever
2025-01-03 20:59:39 <Ermine> the less works it requires the better
2025-01-03 20:59:39 <Ariadne> i don't think systemd changes APIs that often, the problem is when *new* APIs get added that the forked versions from 3 years ago don't have
2025-01-03 20:59:40 <pj> v252 has been released in 2022
2025-01-03 20:59:59 <quinq> Indeed not, fossdd[m], was more about API
2025-01-03 21:00:01 <pj> and they still maintain it
2025-01-03 21:00:16 <Ariadne> systemd tries to stay evergreen like alpine
2025-01-03 21:01:08 <pj> invoked: they backport each month but releases overall stay updated for very long time
2025-01-03 21:01:15 <pj> to the point where it can be in main
2025-01-03 21:01:45 <fossdd[m]> yes, since distros like rhel or debian support it for much longer than alpine needs it
2025-01-03 21:01:59 <fossdd[m]> our elogind version is also from 2022
2025-01-03 21:02:17 <pj> it definitely helps that one of systemd devs is debian maintainer
2025-01-03 21:02:51 <fossdd[m]> oh yeah systemd devs are very active in the community and pay a lot of attention to their downstream distros
2025-01-03 21:02:51 <Ariadne> anyway the main thing that has changed is systemd people have to care a little about musl because of musl's record on memory safety vs glibc
2025-01-03 21:03:05 <pj> although elogind is in community so we could not bother with stable
2025-01-03 21:03:27 <pj> eudev is main though
2025-01-03 21:03:48 <Ariadne> eudev is deader than dead
2025-01-03 21:04:08 <pj> yes, but I mean where replacement would need to fit
2025-01-03 21:04:19 <fossdd[m]> i think even chimera linux uses systemd udev
2025-01-03 21:04:21 <pj> if eudev is main then sd-udev needs to be main as well no?
2025-01-03 21:04:52 <quinq> afaik chimera is all for using all the new things, so no real surprise there
2025-01-03 21:04:56 <Ariadne> yes
2025-01-03 21:05:02 <Ariadne> my plan is to put it into main
2025-01-03 21:05:11 <pj> fossdd: correct
2025-01-03 21:05:15 <fossdd[m]> quinq: oh yeah but they still avoid systemd cause of their design decisions afaik
2025-01-03 21:05:27 <quinq> ah ok :)
2025-01-03 21:06:00 <pj> https://chimera-linux.org/docs/faq#what-is-the-projects-take-on-systemd
2025-01-03 21:07:42 <pj> they also use sd-boot, tmpfiles and sysusers
2025-01-03 21:08:08 <fossdd[m]> yep, all of which i'd love to have in alpine because it rocks
2025-01-03 21:08:51 <Ariadne> i'll get on it after getting this CI up
2025-01-03 21:11:09 <Ermine> i have some transient wifi connectivity issues, so apk managed to remove one version of libacl and failed to install another
2025-01-03 21:11:48 <Ariadne> ouch
2025-01-03 21:12:00 <Ariadne> use apk fix to recover?
2025-01-03 21:12:13 <Ermine> it somehow recovered itself
2025-01-03 21:14:32 <invoked> i'm trying to find something like a charter/mission/plan/set of principles documented for systemd-stable, not having success.
2025-01-03 21:14:52 <invoked> just this https://www.freedesktop.org/wiki/Software/systemd/Backports/
2025-01-03 21:14:57 <Ariadne> its just like the rest of FOSS, they are yoloing it
2025-01-03 21:15:04 <Ariadne> just accept it and move on ;)
2025-01-03 21:15:07 <fossdd[m]> i've no idea what you mean
2025-01-03 21:15:35 <fossdd[m]> its branches of stable systemd releases and distros can backport stuff they think is important
2025-01-03 21:15:41 <fossdd[m]> dont think there is more to explain
2025-01-03 21:16:12 <invoked> "small non-conflicting features deemed safe" (by who)
2025-01-03 21:16:12 <Ariadne> it does not matter because i intend to follow latest systemd
2025-01-03 21:16:28 <Ariadne> by whoever did the backport, obviously
2025-01-03 21:16:31 <Ariadne> just like it is in alpine
2025-01-03 21:16:47 <Ariadne> are you going to go ask the TSC for a flowchart on how things get backported to alpine releases too? :p
2025-01-03 21:16:55 <fossdd[m]> if you concern systemd's stable releases you should concern alpine too
2025-01-03 21:17:02 <invoked> no. just curious what the line is
2025-01-03 21:17:17 <Ariadne> i think i covered that a few messages ago
2025-01-03 21:17:22 <fossdd[m]> Ariadne: lol
2025-01-03 21:17:26 <Ariadne> 1:14 PM <Ariadne> its just like the rest of FOSS, they are yoloing it
2025-01-03 21:17:58 <Ariadne> it is just like "when does alpine releases happen", we release based on vibes man
2025-01-03 21:18:09 <quinq> Thought systemd isn't exactly like the rest of FOSS, some people are paid to work on it
2025-01-03 21:18:14 <Ariadne> we *target* may and november, but if the vibe isn't right, the release slips
2025-01-03 21:18:36 <invoked> last one slipped for reasons unrelated to vibe
2025-01-03 21:18:40 <fossdd[m]> quinq: and they are going to care about the stuff their employer cares about
2025-01-03 21:18:51 <quinq> Exactly
2025-01-03 21:18:57 <fossdd[m]> its not like youre the one paying them
2025-01-03 21:19:07 <quinq> Exactly
2025-01-03 21:19:16 <quinq> Not very FOSS
2025-01-03 21:19:47 <Ariadne> that's corporate FOSS, which is also more vibes than you might think actually
2025-01-03 21:20:03 <Ariadne> it's just vibes with scrum meetings and gantt charts
2025-01-03 21:20:07 <quinq> What's “vibes”?
2025-01-03 21:20:17 <fossdd[m]> and corborate FOSS is a whole new topic to talk about lol
2025-01-03 21:20:25 <Ariadne> "are we feeling like this is a good time for a release or not"
2025-01-03 21:20:54 <quinq> Ah, yeah, I totally agree that doesn't mean it's better quality managed
2025-01-03 21:20:59 <Ariadne> like i guess you have the side like eclipse foundation and apache and whatnot, but that's not the side of corporate FOSS systemd is in
2025-01-03 21:21:16 <quinq> Just that the orientation is, as fossdd[m] stated, towards the one who pays
2025-01-03 21:21:39 <Ariadne> well, people are paid to work on components of alpine
2025-01-03 21:21:50 <quinq> haha yeah, let's not bring eclipse in the conversation ^^
2025-01-03 21:22:34 <quinq> Ariadne, by whom?
2025-01-03 21:22:42 <quinq> (rhetorical question)
2025-01-03 21:23:02 <Ariadne> well, my employer pays me to work on alpine
2025-01-03 21:23:16 <Ariadne> ncopa is paid to work on alpine by mirantis
2025-01-03 21:23:24 <Ariadne> fabled is paid to work on apk-tools
2025-01-03 21:23:35 <Ariadne> some pmOS people are paid to work on pmOS by NLnet
2025-01-03 21:23:43 <fossdd[m]> and without them alpine wouldnt be here
2025-01-03 21:23:48 <invoked> i do have an issue with people backporting features, at least philosophically
2025-01-03 21:23:59 <invoked> but not enough to turn that into a whole drama here
2025-01-03 21:24:04 <quinq> fossdd[m], that's a supposition
2025-01-03 21:24:35 <fossdd[m]> invoked: we do that in alpine too, if it helps backporting other bugs
2025-01-03 21:24:40 <Ariadne> the loongson people are paid to work on alpine/loongarch, despite loongson corporation not possessing the signing keys (which could be a bummer for the CCP)
2025-01-03 21:26:04 <quinq> ^^
2025-01-03 21:26:24 <Ariadne> those are just examples i think of easily.  there are definitely others being paid to work on alpine that i am not aware of right off the top of my mind :p
2025-01-03 21:27:11 <Ariadne> harrumph, i don't have to grant this gitlab CI runner admin access to this machine do i
2025-01-03 21:27:53 <fossdd[m]> quinq: ok let me rephrase it like that: alpine would be the same as it is now
2025-01-03 21:27:59 <pj> Ariadne: "When you build iOS or macOS applications on macOS, jobs run directly on the host, and use the identity of the authenticated user."
2025-01-03 21:28:09 <Ariadne> gross, gross, gross
2025-01-03 21:28:26 <pj> if apple had containers
2025-01-03 21:28:28 <invoked> Ariadne: what's the reasoning for systemd-latest instead of systemd-stable, if you have it?
2025-01-03 21:28:47 <invoked> or some -lts, i guess, putting it another way
2025-01-03 21:28:53 <Ariadne> invoked: staying at latest is usually better for overall system health in my experience
2025-01-03 21:29:11 <pj> I agree that systemd not stable is better
2025-01-03 21:29:25 <Ariadne> especially in a world where programs may just start using d-bus interfaces without checking to see whether they actually are present first
2025-01-03 21:29:31 <Ariadne> (which is why sddm is crashing atm)
2025-01-03 21:29:40 <pj> Unless you want to have outage like Azure had because Ubuntu has ancient systemd version that is backported to hell
2025-01-03 21:30:02 <invoked> feels like we're blaming the wrong things tho :)
2025-01-03 21:30:27 <Ariadne> blaming no, i blame the programs that blindly use interfaces without probing for them.  but the thing is...
2025-01-03 21:30:33 <pj> the issue literally was an ancient systemd version with tons of backports
2025-01-03 21:30:49 <Ariadne> if i can just "fix" those programs by providing the latest version of those interfaces
2025-01-03 21:30:58 <Ariadne> then i can spend that time on things more useful to alpine
2025-01-03 21:31:15 <Ariadne> like reverse engineering all of these hardware raid controllers sitting on my workbench
2025-01-03 21:31:24 <Ariadne> or maybe another ifupdown-ng release finally :)
2025-01-03 21:31:26 <fossdd[m]> oh i love t hat
2025-01-03 21:31:30 <fossdd[m]> both
2025-01-03 21:31:45 <quinq> I love the hat too
2025-01-03 21:33:41 <invoked> yeah. i'm not a fan of heavy backporting which is precisely why i don't use debian. if running systemd-latest is a least-effort decision, then that's the answer and fair enough.
2025-01-03 21:43:13 <pj> Ariadne: i think if you install runner on non admin account it will work ok?
2025-01-03 22:08:11 <Ariadne> pj: yeah probably.  can't register a runner though, so will need to work with #alpine-infra on that
2025-01-03 22:36:53 <Ermine> loginctl doesn't work due to no systemd-as-pid-1
2025-01-03 22:39:12 <Ermine> and libseat's logind backend doesn't work either
2025-01-03 23:19:00 <Ermine> also logind tries to start systemd --user and a scope for user, and fails due to no systemd-as-pid-1
2025-01-03 23:19:55 <Ermine> Therefore statement "logind can work without systemd-as-pid-1" is proven to be false. Thank you for attention
2025-01-03 23:20:41 <fossdd[m]> uhhm. there is a lot of new stuff happening in systemd that allows systemd to be more portable and doesn't rely on being PID 1
2025-01-03 23:21:46 <fossdd[m]> and even if so elogind is also just a logind fork which runs without systemd as PID 1, so it would be (easily) patchable.
2025-01-03 23:24:58 <Ermine> the checked version is 255.whatever they have in pmos
2025-01-03 23:38:02 <invoked> but we've already established that we'd be using latest systemd, not 255
2025-01-03 23:40:37 <invoked> (and all that entails, i guess, including its release cadence)
2025-01-03 23:43:34 <Ermine> i've just pulled what pmOS has, and I don't want to upgrade it and I don't think logind have stopped depending on systemd being pid 1 in those 2 versions
2025-01-03 23:49:30 <invoked> 
ACTION has noticed that, as of 257, they have started listing 'libsystemd' separately on release now

2025-01-03 23:49:40 <NilsK[m]> <Ermine> "i've just pulled what pmOS has..." <- Yeah I think logind is one of the more tighlty coupled sd components
2025-01-04 00:09:49 <skarnet> invoked: did they really? did they make libsystemd available separately from systemd?
2025-01-04 00:10:33 <skarnet> if it is the case, I will take the credit for that :)
2025-01-04 00:11:19 <Ariadne> Ermine: i see no reason why logind would require systemd to be PID 1.  at the most it would require a similar cgroup setup, which is *already* required for elogind.
2025-01-04 00:12:25 <NilsK[m]> Ariadne: Doesn't it also set up scopes and such? Or is that the ?
2025-01-04 00:12:30 <NilsK[m]> * that the PAM module?
2025-01-04 00:12:46 <Ariadne> that is what the elogind/systemd pam module does yes
2025-01-04 00:12:52 <Ermine> scope is cgroup stuff
2025-01-04 00:13:14 <invoked> skarnet: no, just in the release notes kind of way, seems like
2025-01-04 00:13:19 <Ariadne> at any rate, depending on these downstream forks where all they do is take a systemd component, hard fork it and only selectively pull in changesets from upstream is just causing strange bugs to accumulate in alpine and does not really do anything material wrt systemd
2025-01-04 00:13:38 <Ariadne> what i want: bug and CVE fixes in these components
2025-01-04 00:14:12 <NilsK[m]> skarnet: I mean yes but not sure what you would want to use it for? I mean you can use their dbus/varlink/json/event-loop etc implementation but these are very specific to systemd's needs
2025-01-04 00:14:14 <quinq> Ohhh, you'll get the bugs allright ;)
2025-01-04 00:14:55 <Ariadne> quinq: yes, that is the problem.  we get the bugs, but not the fixes.  because maintaining software is *hard* and as soon as they got their jab in on lennart they get bored of maintaining it.
2025-01-04 00:15:21 <NilsK[m]> invoked: Probably because they added quite a bit of functionality to libsystemd this release (varlink, json, etc)
2025-01-04 00:16:56 <quinq> moar bugs
2025-01-04 00:17:08 <skarnet> NilsK[m]: I wouldn't, but one argument Lennart loves to use against critics is that "it's free software, we're not vendoring stuff, you're free to use libsystemd without systemd", to which I objected that libsystemd was not packaged separately, and he shut up
2025-01-04 00:17:32 <Ariadne> essentially: i would like our systemd components to have the same level of bugginess that real systemd has, not the level of bugginess systemd from N years ago had
2025-01-04 00:17:39 <skarnet> so I'm happy that someone finally listened to me, even for something that minor
2025-01-04 00:17:45 <invoked> it's all that constant change which (i hope i'm incorrect) sounds like more work for alpine
2025-01-04 00:18:17 <Ariadne> because no matter how many times we get renamed systemd components, they are still systemd components
2025-01-04 00:18:27 <Ariadne> and it's really not helping alpine to pretend otherwise
2025-01-04 00:19:15 <skarnet> what I'm hearing is "we don't have the manpower to maintain components so we better delegate the maintenance to the systemd team, who does", and it is both entirely reasonable and super sad
2025-01-04 00:19:23 <quinq> Not sure if naming is related to bug introduction and bug fixing
2025-01-04 00:19:43 <Ariadne> we have manpower to maintain components, but these are components that are otherwise imposed upon alpine to support non-alpine software
2025-01-04 00:19:47 <quinq> Also, do they
2025-01-04 00:20:00 <Ariadne> so why should we maintain reimplementations of these APIs, when we could put that manpower elsewhere?
2025-01-04 00:20:15 <Ermine> Ok, I'll check cgroup configuration on my machine
2025-01-04 00:21:30 <NilsK[m]> skarnet: On fedora it has been a separate package for quite some time (containing libnss_*, libsystemd, and libudev)
2025-01-04 00:21:38 <Ariadne> skarnet: but in reality, the situation is more sad.  it is more like "we don't have the manpower to fix someone else's messy systemd fork, so we should just work directly with the original project to support their APIs properly in alpine"
2025-01-04 00:22:06 <Ermine> anything else I need to configure for logind to to work?
2025-01-04 00:22:07 <quinq> Instead dealing directly with messy systemd
2025-01-04 00:22:08 <skarnet> NilsK[m]: yeah, but that's how Fedora packages it, and it's still not independent of systemd by any means
2025-01-04 00:22:30 <Ariadne> quinq: yes, you're still buying a used car, but at least you're not dealing with a slimy used car salesperson on top of it
2025-01-04 00:22:59 <skarnet> this bad boy can fit so many glibcisms in it
2025-01-04 00:23:38 <quinq> Ariadne, to be clear I'm not saying that I think it's a bad idea
2025-01-04 00:23:51 <quinq> I just think it'll solve some issues, but bring others
2025-01-04 00:23:59 <Ariadne> oh it definitely will
2025-01-04 00:24:11 <Ariadne> i can think of several issues, from social ones, to technical ones
2025-01-04 00:24:30 <quinq> And that in the balance it might just be “there's one less project outside of systemd”
2025-01-04 00:24:45 <Ariadne> but that's my point
2025-01-04 00:24:52 <Ariadne> alpine ships systemd components *today*
2025-01-04 00:25:00 <Ariadne> it has shipped systemd components for the past decade
2025-01-04 00:25:03 <NilsK[m]> skarnet: So you mean that you want to build it without building the rest?
2025-01-04 00:25:03 <NilsK[m]> That it is not independent is not surprising, its called libsystemd after all, not libjournal+libdevice+liblogin...
2025-01-04 00:25:11 <Ariadne> we are just pretending they are not systemd components ;)
2025-01-04 00:25:52 <invoked> it'd be nice if yamakuzure were here to explain elogind's pov
2025-01-04 00:26:15 <invoked> i browsed a bit on that repo and didn't see much to suggest that it's dead
2025-01-04 00:26:51 <invoked> no issue complaining that the lack of latest systemd apis was causing a problem
2025-01-04 00:26:58 <invoked> also wonder what gentoo's pov is also
2025-01-04 00:27:28 <fossdd[m]> Ariadne: btw i think packaging systemd is a very reasonable decision and am excited about it.
2025-01-04 00:27:48 <fossdd[m]> its just so bad that we even have to be in this mess and have to consider packaging systemd or not
2025-01-04 00:27:54 <j_v> i was just looking at elogind repo. while not heavily active, not dead, and seems responsive to issues
2025-01-04 00:28:11 <quinq> Ariadne, maybe, I have no experience dealing with those components, but elogind looked like the idea is to stabilizing it, backporting fixes
2025-01-04 00:28:23 <skarnet> NilsK[m]: again, I don't, but it being possible is a good thing
2025-01-04 00:28:37 <fossdd[m]> j_v: nah a MR that blocks a build on musl gets no response at all for months
2025-01-04 00:28:47 <fossdd[m]> thats just.. dead
2025-01-04 00:29:02 <quinq> months sound like a lot yeah
2025-01-04 00:29:06 <fossdd[m]> (a very trivial one)
2025-01-04 00:29:20 <fossdd[m]> https://github.com/elogind/elogind/pull/288
2025-01-04 00:30:00 <fossdd[m]> Oh and for newer elogind releases this one (https://github.com/elogind/elogind/pull/292) is required on musl aswell
2025-01-04 00:30:21 <fossdd[m]> And even then I didnt got it to build !77841
2025-01-04 00:30:37 <skarnet> NilsK[m]: https://social.treehouse.systems/@ska/112422065782975414  here is where I argued to Lennart that ssh-proxy.c was more of a way to lock users into systemd than a gift aimed at interoperability, as long as libsystemd was packaged with systemd itself
2025-01-04 00:31:16 <skarnet> if libsystemd is separate, then ssh-proxy.c becomes more usable by non-systemd users and that's good
2025-01-04 00:31:20 <invoked> i'm not sure the reflex should be to yeet the latest systemd release though, without understanding why there's a real and/or perceived bottleneck at elogind. i dunno.
2025-01-04 00:33:06 <fossdd[m]> skarnet: idk feels like you both have been misunderstanding each other
2025-01-04 00:33:38 <skarnet> lol, you're not bothsidesing this
2025-01-04 00:33:53 <skarnet> it's not our first spar
2025-01-04 00:34:31 <fossdd[m]> hmm okay then i said nothing, thats just how it looks to me
2025-01-04 00:37:27 <quinq> To me it looks like “this is free software, do whatever you want with our software. Use it or don't.”
2025-01-04 00:37:36 <quinq> Which is just denying all responsibility
2025-01-04 00:37:58 <quinq> Anyway, good night gentle folks :)
2025-01-04 00:38:06 <invoked> gn quinq 
2025-01-04 00:39:17 <skarnet> exactly. Lennart is a slippery weasel, who's both "I am a serious person and you are not, stop questioning me" and "lol we're just making free software we're responsible for nothing", whatever is most convenient at a given time. He's a difficult person to have straight technical discussions with.
2025-01-04 00:40:05 <skarnet> so if questioning him actually had the tiniest impact and helped move systemd in the right direction, I'm happy.
2025-01-04 00:40:28 <skarnet> and, sleepy time as well, gn everyone.
2025-01-04 00:40:40 <fossdd[m]> gn you two
2025-01-04 00:42:56 <Ariadne> look i just want sddm to work :)))
2025-01-04 00:43:22 <fossdd[m]> haha
2025-01-04 00:50:42 <quinq> “Distributions without pam and systemd will need to put the "sddm" user into the "video" group”
2025-01-04 00:50:53 <quinq> Sounds like an easier fix
2025-01-04 00:51:56 <fossdd[m]> that solves this particular problem
2025-01-04 00:52:24 <fossdd[m]> (probably, i dont this that this is the problem)
2025-01-04 00:52:32 <fossdd[m]> s/this/think/
2025-01-04 01:17:51 <vkrishn> as regarding issue #16682, code for CONFIG_USB_NET_RNDIS_HOST=m is still active in stable tree (drivers/net/usb/rndis_host.c), iirc CONFIG_USB_NET_RNDIS_WLAN=m is now replaced by cdc_ncm (don't know full)
2025-01-04 01:19:57 <fossdd[m]> vkrishn: can you still open a new issue
2025-01-04 01:20:02 <fossdd[m]> i think here it will be forgotten
2025-01-04 01:20:22 <vkrishn> pls, enable/undo RNDIS_HOST where disabled, this is what i need to connect to mobile device, https://tpaste.us/pyyk
2025-01-04 01:21:49 <vkrishn> issue is already there, with comment "a few things got lost in the linux upgrade from 6.6 to 6.12"
2025-01-04 01:22:08 <Ariadne> quinq: not the issue.  the issue is apparently not even related to elogind (though i still think elogind should be replaced with the real one), but instead https://github.com/sddm/sddm/issues/1844
2025-01-04 01:22:36 <Ariadne> i am not even sure why this is, but i am going to NMU a fix to sddm to make it ignore all VTs other than tty7 as starting point because this is ridiculous
2025-01-04 01:22:40 <fossdd[m]> vkrishn: yeah but its closed with a commit
2025-01-04 01:23:17 <vkrishn> but not correctly fixed, x86 is still not undone
2025-01-04 01:23:27 <NilsK[m]> vkrishn: IIRC the whole RNDIS stuff is planned to be removed soon(TM)
2025-01-04 01:23:27 <NilsK[m]> https://www.phoronix.com/news/Linux-RNDIS-Removal-EOY2024
2025-01-04 01:27:09 <vkrishn> article does not say about RNDIS_HOST and RNDIS_WLAN, just rndis
2025-01-04 01:29:19 <vkrishn> using it on guest side should not be an issue, i use it with firewalls and still works like a charm
2025-01-04 01:30:03 <vkrishn> new kernel/hosts probably need to implement newer NCM
2025-01-04 01:30:18 <Ariadne> hmm, building sddm with -DSDDM_INITIAL_VT=7 caused my machine to kpanic
2025-01-04 01:30:21 <Ariadne> amazing
2025-01-04 01:30:27 <vkrishn> and don't think android kernel move that fast up android tree
2025-01-04 01:32:54 <Ariadne> or not kpanic, but makes the display go dead
2025-01-04 01:33:08 <vkrishn> getting to0 much future-optimistic-implemenation is not too nice
2025-01-04 01:38:51 <vkrishn> hmmm... there is no plans to create a temporary net blackout, right :)
2025-01-04 01:39:02 <NilsK[m]> <skarnet> "if libsystemd is separate..." <- `ssh-proxy.c` does nothing special here. You could just as well use `ProxyCommand="socat - VSOCK-CONNECT:$PID:%p"` or `nc` - which is also what [mkosi currently does](https://github.com/systemd/mkosi/blob/425371ff4d60d87ae2920bfd833c6fd8731388fc/mkosi/qemu.py#L762). They pretty much just reimplemented a subset of a tool so that they could provide it to their users without adding a dependency
2025-01-04 01:39:03 <NilsK[m]> on `socat`/`nc`. Oh and they also added sd-machined integration but that is also not really of interrest for someone not using systemd.
2025-01-04 01:45:12 <Ariadne> so anyway this seems to be an sddm regression, but i still think using these forks of individual systemd components is not helpful
2025-01-04 05:37:29 <Daanct12> omni: greets, please take over the package. don't have time to maintain it and i hardly use alpine on the desktop anyway
2025-01-04 10:08:27 <skarnet> NilsK[m]: if you read the entire thread, you'll see that it's what I'm saying, yes (also, socat is not a good tool either, for different reasons), but in this particular post I wasn't talking about that
2025-01-04 12:23:25 <Dell> hi
2025-01-04 16:32:56 <sdomi> mesa-dri-gallium got broken with edc392649d7c586a6290c5f08f65f09d86e861ac due to the path change at APKBUILD line 77
2025-01-04 16:33:16 <sdomi> (i'm running X11 and that, of course, no longer knows how to load those modules)
2025-01-04 16:34:10 <sdomi> please deposit the "you're holding it wrong" into this box *points at self*
2025-01-04 16:36:59 <fossdd[m]> https://gitlab.alpinelinux.org/alpine/aports/-/issues/16369 lol
2025-01-04 16:38:01 <fossdd[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75827#note_462764 hmm
2025-01-04 16:52:59 <ncopa> vkrishn: create an issue and I’ll have a look when I get a chance. Otherwise I will forget 
2025-01-04 17:01:53 <ncopa> sdomi: please open an issue and ping the author. IIRC I asked if it would break X11
2025-01-04 17:04:40 <fossdd[m]> ncopa: yes see https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75827#note_462764
2025-01-04 17:04:44 <fossdd[m]> > Shouldn't for majority
2025-01-04 18:54:52 <pltrz[m]> I was curious to know the state of packages not monitored on anitya (release-monitoring.org); came up with the following pkgs not monitored (main: 440/1573; community: 3749/6933; testing: 2708/3310) - I thought I might try and go through `main` and link all the packages that are unmonitored. Would I be duplicating an already existing effort? Is it useful? unmonitored pkgs in main (https://tpaste.us/knna)
2025-01-04 18:55:04 <pltrz[m]> https://tpaste.us/knna
2025-01-04 19:11:12 <j_v> creating a symlink, 'ln -s /usr/lib/dri /usr/lib/xorg/modules/dri', resolves any loading i was having with new mesa on X11... had to drop out of X after creating the link then restarted X and loading dri drivers are now error free.
2025-01-04 19:22:20 <pj> pltrz: I don't think adding acf-* or other alpine specific packages is useful
2025-01-04 19:28:59 <vkrishn> ncopa: yes, will do, getting my all email applications together today
2025-01-04 20:31:36 <pltrz[m]> pj: good point - thx!
2025-01-04 20:32:03 <pj> other than that, adding packages to anitya definitely 
2025-01-04 20:47:54 <pj> ikke clandmeter ncopa can someone op me or join via matrix to ban the spam?
2025-01-04 20:48:28 <fossdd[m]> the spam really got crazy in the last days
2025-01-04 20:49:52 <pj> apparently IRC side doesn't see this :>
2025-01-04 20:50:04 <fossdd[m]> yeah oftc banned them long  time ago
2025-01-04 20:51:17 <pj> done
2025-01-04 20:51:31 <clandmeter> can you explain what you did?
2025-01-04 20:51:34 <clandmeter> just for our record
2025-01-04 20:51:55 <pj> I'm on element and banned the spammer
2025-01-04 20:51:59 <pj> "pj banned James idowu Toyin: begone spam"
2025-01-04 20:52:00 <fossdd[m]> pj banned @jay.hay:matrix.org Reason: begone spam
2025-01-04 20:52:06 <fossdd[m]> and the spam is deleted
2025-01-04 20:52:10 <fossdd[m]> pj: thanks
2025-01-04 20:52:20 <clandmeter> Ok lets keep you ops here for now
2025-01-04 20:52:31 <pj> can you op in #alpine-security too?
2025-01-04 20:52:38 <clandmeter> ikke: ^
2025-01-04 20:52:55 <fossdd[m]> and basically every other #alpine- channel which is bridged to matrix :p
2025-01-04 20:53:29 <pj> can ban the person but so far other channels are pretty clean for now
2025-01-04 20:53:38 <pj> -security is very bad tho
2025-01-04 20:54:17 <fossdd[m]> hmm -commits, -loongarch64 aswell
2025-01-04 20:54:32 <clandmeter> i dont see you on security
2025-01-04 20:55:23 <fossdd[m]> yeah matrix disconnects users from IRC when they dont write for a long time
2025-01-04 20:56:54 <pj> I thought it's per network, not per channel
2025-01-04 21:00:36 <pj> https://cdn.panekj.dev/images/matrix-spam.png
2025-01-04 21:02:14 <pj> seems that #alpine-commits also is affected
2025-01-04 21:02:27 <clandmeter> cant op without a user
2025-01-04 21:02:41 <fossdd[m]> yes, and #alpine-loongarch
2025-01-04 21:05:02 <pj> hold on, need to find that room since I didn't join
2025-01-04 21:52:58 <pj> I should be in most channels now, ping me when needed help with matrix stuff
2025-01-04 21:53:29 <fossdd[m]> yep thanks
2025-01-05 08:17:38 <fraolt> fossdd: Thank you for !77829
2025-01-05 08:19:31 <fraolt> I wanted to use the build artifact for todays anki flash card reviews. Unfortunately, the artifacts have already been removed: https://gitlab.alpinelinux.org/fossdd/aports/-/jobs/1671470
2025-01-05 08:20:44 <fraolt> According to https://gitlab.alpinelinux.org/help/user/gitlab_com/index.md#gitlab-cicd the artifacts should be stored for 30 days (and it has only been 4 day).
2025-01-05 08:20:45 <fossdd[m]> i restarted the CI, should be ready in a few mins
2025-01-05 08:20:57 <fraolt> Great, thanks!
2025-01-05 08:39:07 <aquaherd> Could someone be so nice and merge aports 75150? 
2025-01-05 10:36:23 <aquaherd> exit
2025-01-06 10:22:33 <fabricionaweb> good morning, I may need some eyes here !77555
2025-01-06 11:15:08 <matttbe> Hello! Sorry to bother you about that, but I'm coming here because the Aports Qa Bot suggested me to do so: my MR I opened in November to add a new package (mptcpd) didn't get any reviews so far.
2025-01-06 11:15:09 <matttbe> Do I need to find someone who can help me, or should I just wait? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75529
2025-01-06 11:33:41 <ncopa> matttbe: I can have a quick look. thanks
2025-01-06 11:35:23 <chereskata> hi, is there any possibility to chech SODIFF without using the builders?
2025-01-06 11:35:37 <matttbe> ncopa: great, thank you!
2025-01-06 11:35:55 <ncopa> chereskata: checkapk
2025-01-06 11:37:53 <chereskata> thank you!
2025-01-06 13:01:27 <chereskata> i am trying to upgrade linux-pam. Unfortunately it fails on some libintl error: https://paste.gnome.org/nuj0DAB7Z could someone give me a hint please :)?
2025-01-06 13:05:17 <invoked> might be missing a patch for musl
2025-01-06 14:05:12 <chereskata> this is probably the case, thanks
2025-01-06 17:24:54 <zcrayfish> Would like someone to take a look at LXQt 2.1 on edge related MRs; !78078, !78128, !77177. First one addresses #16790 on edge; I'll work on v3.21 later.
2025-01-06 18:43:46 <ncopa> im tagging stable releases now
2025-01-06 19:00:26 <ncopa> does this look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.21.1-released.html
2025-01-06 19:00:44 <ncopa> typo
2025-01-06 19:00:48 <ikke> 3.20 series -> 3.21 series
2025-01-06 19:01:37 <ikke> an u-boot -> a u-boot 
2025-01-06 19:01:50 <ncopa> and this https://wwwtest.alpinelinux.org/posts/Alpine-3.18.10-3.19.5-3.20.4-released.html
2025-01-06 19:02:28 <ncopa> I think an u-boot is correct, but it should probably be U-Boot
2025-01-06 19:03:48 <ikke> The pronounciation determines whether it's a vs an
2025-01-06 19:04:38 <ikke> the yu / ju pronounciation makes 'an' a bit awkward
2025-01-06 19:06:00 <ncopa> chatgpt also pointed that out when asked to review it
2025-01-06 19:07:30 <ncopa> ok lets push it
2025-01-06 19:07:55 <ncopa> thank you!
2025-01-06 19:15:16 <ikke> I've posted it on fosstodon
2025-01-06 19:26:33 <ncopa> thanks!
2025-01-06 20:13:32 <vkrishn> someone guide 'Marek Zori' of guidelines/norms of 'git titles' pls
2025-01-06 20:13:59 <ikke> vkrishn: You could do that yourself
2025-01-06 20:14:09 <ikke> There is the COMMITSTYLE.md document you could point them to
2025-01-06 20:14:48 <vkrishn> i don't know irc nick? email?
2025-01-06 20:15:52 <vkrishn> i mean know email, do i send email?
2025-01-06 20:16:48 <ikke> There was an MR, but apparently already merged without checking the commit style
2025-01-06 20:19:03 <vkrishn> committer would be fcolista ^
2025-01-06 20:19:57 <vkrishn> not 1, 2 .. 6 in a row, hatric
2025-01-06 20:20:21 <ikke> It's just one MR that the author kept adding fixup commits to
2025-01-06 20:20:50 <vkrishn> ok
2025-01-06 20:25:03 <vkrishn> iirc `git squash` does clubbing
2025-01-06 20:30:51 <ikke> There is no built-in squash command
2025-01-06 20:31:17 <ikke> You use git rebase -i <base> or git reset --soft <base> && git commit
2025-01-06 20:34:15 <ncopa> I added a omment https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77854#note_471590
2025-01-06 20:35:21 <ncopa> the gitlab UI does not really encourage reviewers to look at the commit messages.
2025-01-06 20:36:15 <ikke> nod
2025-01-06 21:10:22 <quinq> Add a checklist :>
2025-01-06 21:14:07 <vkrishn> i do that often, but on wiki, don't know how expensive op is that on gitlab
2025-01-06 21:14:17 <vkrishn> pmwiki
2025-01-06 21:15:54 <vkrishn> this is supper neat, https://www.pmwiki.org/wiki/Cookbook/Flipbox
2025-01-06 21:20:03 <pj> if someone merges such thing, they should have merge permissions revoked :>
2025-01-06 21:20:33 <pj> what would be the clean way to substitue strings twice out of variable?
2025-01-06 21:21:07 <quinq> Without context, sed
2025-01-06 21:21:08 <ikke> pj: can you elaborate?
2025-01-06 21:21:10 <pj> do I have to redeclare it twice
2025-01-06 21:21:18 <pj> I'm talking about APKBUILD
2025-01-06 21:21:33 <ikke> ${foo//bar/baz}?
2025-01-06 21:21:52 <pj> something like  ${${CFLAGS/-fstack-clash-protection}/-Os/-O2}
2025-01-06 21:23:18 <quinq> Not like that ;p
2025-01-06 21:23:25 <pj> well obviously
2025-01-06 21:23:27 <quinq> I suppose that assigning it twice wouldn't hurt
2025-01-06 21:23:40 <quinq> And would be clearer
2025-01-06 21:25:00 <quinq> (also // while you're at it)
2025-01-06 21:25:31 <quinq> (or /%)
2025-01-06 21:26:03 <quinq> Ah no, that's not how % werks
2025-01-06 21:26:22 <pj> will just //, I don't want to touch more than that
2025-01-06 21:26:40 <pj> it's already a massive change to whole ports repo and it's only a workaround
2025-01-06 21:27:50 <pj> I hope I don't have to pkgrel bump this or do I
2025-01-06 21:29:07 <quinq> As a nobody here, I'd say if you're making a new package binary, it should be bumped
2025-01-06 21:29:23 <pj> I'm doing !78137
2025-01-06 21:30:10 <pj> good algitbot
2025-01-06 21:30:58 <quinq> This doesn't look like it's needed
2025-01-06 21:31:18 <quinq> If you specify several optimization levels, only the last one will be used anyway
2025-01-06 21:31:37 <quinq> So CFLAGS="$CFLAGS -O2" will always trigger -O2
2025-01-06 21:31:51 <pj> you're getting closer
2025-01-06 21:31:58 <pj> now figure out which default -O is in abuild
2025-01-06 21:32:03 <pj> and where it ends up in chain
2025-01-06 21:33:00 <quinq> If abuild sets any CFLAGS after sourcing the APKBUILD, nothing you do in the APKBUILD will help
2025-01-06 21:33:45 <quinq> But most likely I'm just misunderstanding what you're doing here :)
2025-01-06 21:33:50 <pj> if -Os is replaced with -O2 then people who don't use -Os in abuild will not get forced -O2
2025-01-06 21:34:40 <pj> Setting -O2 as default will change nothing and setting -O3 as default, will not make specific packages build with hardcoded -O2
2025-01-06 21:34:47 <quinq> Ah ok :)
2025-01-06 21:35:01 <pj> and since -Os is very close to -O1 I don't really care about that opt level
2025-01-06 21:35:14 <quinq> So Alpine forbids building with -Os
2025-01-06 21:35:23 <quinq> And instead will substitute O2
2025-01-06 21:36:09 <pj> also rip -Oz but I hope no one is using that
2025-01-06 21:36:42 <pj> again, this is mostly workaround for the actual issue https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10057
2025-01-06 21:37:14 <pj> but also maybe an opportunity to clean-up CFLAGS, because holy, what am I looking at
2025-01-06 21:38:03 <pj> quinq: I'm unsure what you refer to with "Alpine forbids -Os"
2025-01-06 21:38:19 <pj> -Os is the default, -O2 is used for certain packages
2025-01-06 21:38:39 <pj> unless you mean those certain packages, then yes
2025-01-06 21:40:17 <quinq> Allright, got it, Alpine doesn't want to build those specific packages with anything <= O2
2025-01-06 21:40:28 <quinq> So anything => O2 is ok
2025-01-06 21:40:56 <pj> yes, this is usually stuff like musl/gcc/llvm stuff, compression tools/libs and other performance sensitive stuff
2025-01-06 21:41:10 <quinq> But then there's O0 and O1 (and Oz as you said) 
2025-01-06 21:42:41 <quinq> Is abuild using bash?
2025-01-06 21:42:53 <pj> no, /bin/ash
2025-01-06 21:44:01 <quinq> Great: ${CFLAGS/-O[01sz]/-O2}
2025-01-06 21:45:44 <pj> I will defer until ncopa or others will have an opinion on that :v
2025-01-06 21:45:49 <quinq> ^^
2025-01-06 21:46:52 <pj> are CPPFLAGS actually used anywhere?
2025-01-06 21:47:56 <pj> if (yes|no) I would remove them anyway and/or replace them with export CPPFLAGS="$CXXFLAGS"
2025-01-06 21:48:18 <pj> (not even defined in abuild)
2025-01-06 21:48:59 <pj> 202 files with CPPFLAGS
2025-01-06 21:49:02 <quinq> It's non standard, but:
2025-01-06 21:49:03 <quinq> $ grep -F CPPFLAGS */*/APKBUILD|wc -l
2025-01-06 21:49:04 <quinq> 138
2025-01-06 21:49:46 <quinq> ah, I must be missing some secret packages
2025-01-06 21:50:01 <pj> I included all files
2025-01-06 21:51:38 <pj> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/wine/APKBUILD#L83
2025-01-06 21:51:55 <pj> kind of pointless when CPPFLAGS is empty?
2025-01-06 21:54:30 <ikke> pj: it would allow us to define CPPFLAGS in the future
2025-01-06 21:54:30 <pj> "Extra flags to give to the C preprocessor and programs that use it (the C and Fortran compilers). "
2025-01-06 21:54:32 <pj> hm
2025-01-06 21:56:07 <pj> seems that at least chromium has difference in those
2025-01-06 21:57:25 <pj> ikke: shouldn't it be set anyway already to e.g "-Os"
2025-01-06 21:59:20 <quinq> haha
2025-01-06 21:59:29 <quinq> Also you don't get pre-processor optimizations
2025-01-06 22:00:11 <pj> seems like abuild had CPPFLAGS which were set to CFLAGS and now they are removed
2025-01-06 22:01:16 <pj> going through backlog, I'm guessing alice removed that since it was useless
2025-01-06 22:01:18 <pj> https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/180
2025-01-06 22:03:05 <pj> https://gitlab.alpinelinux.org/alpine/abuild/-/commit/861e21fab234e8bc8a472215382bf86d823859e4
2025-01-06 22:03:29 <pj> looking at most usage in APKBUILDs, it seems no one really knows what CPPFLAGS are for
2025-01-06 22:04:34 <pj> and everything is usually compiled with $(CC) $(CFLAGS) $(CPPFLAGS)
2025-01-06 22:19:02 <pj> I'm guessing nothing happen in area of removing dead packages (no maintainer, stuck in testing)?
2025-01-07 15:41:51 <orbea> pj: CPPFLAGS are for things like -DFOO
2025-01-07 15:42:27 <panekj> I've noticed
2025-01-07 16:17:08 <WhyNotHugo> Rust itself (the alpine package) is compiled using GCC, correct?
2025-01-07 16:19:01 <ikke> I thought it was llvm
2025-01-07 16:20:12 <j_v> looking at the APKBUILD for rust... looks like it uses llvm
2025-01-07 16:20:56 <WhyNotHugo> --set="target.$_target.cc=${CROSS_COMPILE}cc"
2025-01-07 16:21:22 <WhyNotHugo> This and subsequent lines confuse me, since this poitns to gcc.
2025-01-07 16:24:17 <pj> Rust is compiled with GCC
2025-01-07 16:25:38 <ikke> is llvm used to compile rust code?
2025-01-07 16:26:12 <WhyNotHugo> ikke: I believe so
2025-01-07 16:26:30 <WhyNotHugo> rust produces a few intermediate representations, which are finally handed for llvm for optimisation and compilation.
2025-01-07 16:27:05 <pj> Yes, LLVM is used as main codegen
2025-01-07 18:20:47 <lotheac> at risk of stating the obvious: CPP in CPPFLAGS refers to the C preprocessor, completely unrelated to c++
2025-01-07 18:21:32 <lotheac> so CPPFLAGS="$CXXFLAGS" is probably not a good idea
2025-01-07 18:22:53 <ptrc> any idea what to do when apk-tools just returns `No error information`?
2025-01-07 18:23:17 <ptrc> https://ptrc.gay/SiSZFEwK
2025-01-07 18:23:26 <pj> lotheac: yes, I already posted the part from GNU documentation which explains variable usage
2025-01-07 18:23:44 <lotheac> ok, fair enough, I missed that :) 
2025-01-07 18:25:31 <pj> ptrc: strace, gdb?
2025-01-07 18:26:01 <Arnavion> And disk/filesystem corruption on that particular path
2025-01-07 18:26:22 <ptrc> strace doesn't really show anything useful, but it might be because it tries to write to the hidden apk file first
2025-01-07 18:31:28 <ptrc> idunno it just reads a bunch of data from fd 7, and then prints the message
2025-01-07 18:32:36 <ptrc> https://ptrc.gay/NBHGnKQc
2025-01-07 18:32:54 <ptrc> relevant strace snippet with the read(7, ...) calls filtered out
2025-01-07 18:33:07 <ptrc> ( all those read calls are successful though )
2025-01-07 18:33:40 <Ermine> Looks like it checks for error in a wrong way somewhere
2025-01-07 18:44:48 <ptrc> ah, hm
2025-01-07 18:44:51 <ptrc> https://ptrc.gay/tYxjoDQC
2025-01-07 18:45:06 <ptrc> it's grown in size from 1.97 GiB to 2.01 GiB
2025-01-07 18:45:37 <ptrc> and i think going over the 2**31 bytes boundary might be related somehow
2025-01-07 21:35:24 <Ariadne> WhyNotHugo: C components are built with GCC, yes
2025-01-07 21:53:52 <Ariadne> incidentally, i have a systemd-udev package up and running on my desktop that replaces eudev, and it is working as expected
2025-01-07 21:56:37 <Ermine> i'd appreciate an apkbuild for this
2025-01-07 21:56:54 <Ariadne> soon(tm)
2025-01-07 21:57:36 <fossdd[m]> im excited
2025-01-07 21:57:43 <fossdd[m]> thanks for the work
2025-01-07 22:08:48 <quinq> Not excited here
2025-01-07 22:09:18 <ikke> quinq: we are already using eudev, which is a fork of systemd-udev
2025-01-07 22:09:41 <quinq> I know
2025-01-07 22:10:11 <quinq> That still doesn't feel exciting to me :)
2025-01-07 22:58:33 <Ariadne> ikke: well there is also libudev-zero which is a supported option
2025-01-07 23:45:14 <WhyNotHugo> Ariadne: you need to rebuild packages for libudev-zero, right?
2025-01-07 23:45:42 <Ariadne> no, it's ABI-compatible
2025-01-07 23:46:29 <Ariadne> mileage varies depending on devfs manager though
2025-01-08 00:02:04 <navi> a ping from openrc, user services got merged to master
2025-01-08 00:03:33 <invoked> nice
2025-01-08 00:08:51 <invoked> so https://github.com/OpenRC/openrc/commits/master/?author=navi-desu&since=2025-01-07&until=2025-01-07
2025-01-08 00:11:10 <fossdd[m]> navi: very nice, thanks!
2025-01-08 00:15:19 <q66> Ariadne: "mileage varies" is putting it lightly, for pretty much any client use and a lot of server use, any mdev or whatever is just too functionally deficient
2025-01-08 00:15:50 <Ariadne> q66: yeah basically
2025-01-08 00:16:39 <q66> even ignoring that udev comes with a lot of useful rulesets for all sorts of stuff, lack of hwdb and therefore stuff like hid quirks really hurts
2025-01-08 07:36:15 <fabricionaweb> Nice
2025-01-08 08:29:06 <ncopa> ikke: im sorry abou thte ca-certificate problem
2025-01-08 08:29:26 <ikke> No problem 
2025-01-08 08:30:00 <ncopa> i think it means we need tag new releases :-/
2025-01-08 08:30:24 <ikke> Yes
2025-01-08 09:02:20 <ncopa> ikke can I merge https://gitlab.alpinelinux.org/alpine/ca-certificates/-/merge_requests/16 ?
2025-01-08 09:32:46 <ikke> Feel free to undo the ci commit 
2025-01-08 09:32:55 <ikke> I'll include that later
2025-01-08 09:33:10 <ikke> Otherwise it should be fine
2025-01-08 09:34:50 <ikke> I see you have already merged it
2025-01-08 09:35:02 <ncopa> i fixed the ci
2025-01-08 09:44:11 <ikke> Yes, I saw, thanks 
2025-01-08 10:21:52 <vkrishn> ncopa: #16810 is also related to #16808 (if modloop get build with it)
2025-01-08 10:40:22 <ncopa> vkrishn: can you create a /firmware direcotry with all the needed firmware on your boot media?
2025-01-08 10:48:57 <ncopa> im tagging new stable releases now
2025-01-08 12:02:29 <ncopa> does this look ok? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/95
2025-01-08 12:04:26 <vkrishn> i was trying to avoid custom build of modloop
2025-01-08 12:35:14 <vkrishn_> ah ok, aside from current modloop, looking at the init code again, thanks
2025-01-08 13:09:33 <f_> \o/ !
2025-01-08 13:34:39 <fabled> Finally. https://gitlab.xfce.org/xfce/xfwm4/-/merge_requests/149 got merged
2025-01-08 13:35:26 <fabricionaweb> \o/
2025-01-08 13:40:49 <ncopa> i'll backport it to aports
2025-01-08 13:50:53 <fabled> Thanks
2025-01-08 13:51:59 <ncopa> and its merged now. thank you!
2025-01-08 14:19:51 <pj> something is broken with tailscale on 3.21
2025-01-08 14:20:18 <pj> not exactly sure what, "flag provided but not defined: -login-cmd"
2025-01-08 14:22:21 <invoked> ncopa: minor thing but #alpine-linux /topic is still 3.12.1
2025-01-08 14:23:51 <fabricionaweb> here I see 3.21.1
2025-01-08 14:27:56 <dne> pj: works fine for me
2025-01-08 14:28:20 <pj> are you using tailscale ssh?
2025-01-08 14:28:58 <dne> no
2025-01-08 14:35:10 <pj> looks like outdated bin
2025-01-08 14:38:39 <ncopa> invoked: thanks!
2025-01-08 16:58:01 <ovf> just tried running qtcreator and looks like the qt libs drifted or something? http://0x0.st/8-ia.txt
2025-01-08 16:58:45 <ovf> this looks to be private qtcore apis, so i guess qtcreator needs to be kept in sync with that
2025-01-08 17:09:04 <vkrishn> ovf did upgrade ? is lib libUtils.so.14 available? apk info -W /path/to/libUtils.so.14
2025-01-08 17:10:30 <ovf> vkrishn: libutils is part of qtcreator, and it's looking for qtcore-internal apis that are no longer there. so at the very least a rebuild is needed
2025-01-08 17:19:58 <vkrishn> thank, its in testing
2025-01-08 21:07:07 <ovf> ERROR: clang17-dev-17.0.6-r2: trying to overwrite usr/lib/libclang.so owned by clang19-dev-19.1.6-r0.
2025-01-08 21:11:16 <quinq> oops
2025-01-08 23:48:52 <caleb_m> [@_oftc_Ariadne:matrix.org](https://matrix.to/#/@_oftc_Ariadne:matrix.org) super excited to hear you're interested in getting actual upstream systemd components into Alpine. What Chimera is doing makes so much more sense than what Alpine does today.
2025-01-08 23:49:05 <caleb_m> I also asked Lennart about this before and he said he was open to build system changes to more easily allow for building systemd components standalone
2025-01-08 23:49:30 <caleb_m> so patches like what we have for systemd-boot in pmos and what Chimera are doing for sysusers/tmpfiles could hopefully go away
2025-01-09 00:32:09 <fossdd[m]> btw some MRs that are imo ready to merge: !78246 !78244 !78191 !78190 !78189 !77565 !77839 !78192 !78131 !76651 !77603 !78055 !77462 !78057 !77829 !77972 !76192 !77691
2025-01-09 00:32:21 <fossdd[m]> that are a lot more than i expected lol
2025-01-09 00:32:32 <fossdd[m]> but no need to rush ofc ^^
2025-01-09 00:35:59 <fossdd[m]> !77840
2025-01-09 01:10:43 <vkrishn> poor aligibot, did fossdd[m] panic you!!
2025-01-09 02:29:52 <fabricionaweb> Almost rate limit
2025-01-09 10:15:17 <krystianch> i noticed that on RPi1B+, on Alpine 3.21.2 and edge, loading the bcm2835_v4l2 module causes an exception https://paste.sr.ht/~krystianch/07d031b8a0c3ff3cac6b2dd81c4c13e7b233cab9 this happens only when you load start_x and fixup_x from the raspberrypi-bootloader-experimental package, are start_x and fixup_x supported in Alpine?
2025-01-09 14:08:32 <WhyNotHugo> CTARGET is the architecture for which I'm producing binaries. Is CBUILD the architecture on which I'm building?
2025-01-09 15:13:55 <invoked> WhyNotHugo: bingo
2025-01-09 15:18:39 <invoked> having said that, i should say i don't know how cross works here though, like i did when i was at gentoo. i haven't tried setting that up on alpine
2025-01-09 16:41:49 <calebccff> invoked: i taught pmbootstrap how to natively cross compile with abuild here, maybe a useful reference: https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/merge_requests/2474
2025-01-09 16:42:13 <calebccff> you can see the APKBUILD changes needed in the linked pmaports MR
2025-01-09 16:44:21 <invoked> nice
2025-01-09 16:44:38 <invoked> i've never been one to go full "releng", much of that is almost like voodoo to me
2025-01-09 16:44:45 <calebccff> releng?
2025-01-09 16:44:52 <invoked> release engineering
2025-01-09 16:45:03 <calebccff> like what pmbootstrap does?
2025-01-09 16:45:44 <invoked> nevermind it's just color commentary
2025-01-09 16:45:56 <calebccff> nono i like the term
2025-01-09 16:45:58 <invoked> but i like what you wrote in there. "when it works"
2025-01-09 16:46:08 <invoked> haha. that's what i mean. voodoo
2025-01-09 16:46:23 <calebccff> hehe yeah
2025-01-09 16:46:27 <calebccff> i've seen the power
2025-01-09 16:46:37 <calebccff> im increasingly determined to make this viable
2025-01-09 16:47:10 <calebccff> order of magnitude faster than our current "cross" compilation method of building in a qemu-user chroot with gcc symlinked to a cross-compiler
2025-01-09 16:47:16 <invoked> you might want to make salt circles and seek the protection of long-dead gods
2025-01-09 16:47:23 <calebccff> lol
2025-01-09 16:47:40 <calebccff> some day we will have the best of all worlds
2025-01-09 16:48:55 <calebccff> tbh i do think it would make sense to eventually normalise that APKBUILDs support cross compilation
2025-01-09 16:49:08 <calebccff> and require exceptions for packages that can't be cross compiled
2025-01-09 16:49:56 <invoked> it would be nice.  although when problems come up at runtime it can be tough to know if something went wrong in the toolchain
2025-01-09 16:51:17 <invoked> i don't really know how that gets sustained but, it's gotta be better now than it was in, whatever 2005.
2025-01-09 16:51:35 <calebccff> invoked: well projects like yocto cross compile the entire system
2025-01-09 16:52:02 <calebccff> invoked: but i don't think it makes sense necessarily to do that for the binary repo, i do think it makes sense for developers
2025-01-09 16:52:20 <invoked> for speed, definitely
2025-01-09 16:52:27 <calebccff> the pmOS arm64 repo is entirely "cross" compiled through our cursed qemu-user + cross-compiler setup
2025-01-09 16:52:39 <calebccff> and that's been fine
2025-01-09 16:54:15 <abby> void cross-compiles aarch64* and armv[67]l*
2025-01-09 16:54:47 <abby> maybe someone will get an ampere server at some point and aarch64 goes native
2025-01-09 16:57:24 <invoked> has it been reliable?
2025-01-09 17:02:21 <abby> there's a small amount of packages that can't be cross-compiled or need awful patches to cross-compile, but for the most part it works
2025-01-09 17:18:16 <invoked> cool
2025-01-09 20:00:15 <bl4ckb0ne> fossdd: if you want to dive into pango tests https://gitlab.gnome.org/GNOME/pango/-/blob/main/tests/testboundaries_ucd.c?ref_type=heads#L317 
2025-01-09 20:00:44 <bl4ckb0ne> there's g_test_verbose not set in our package that could be worth
2025-01-09 20:00:56 <bl4ckb0ne> ive also noticed that test-fonts is fixed with 1.56
2025-01-09 20:00:57 <fossdd[m]> oh yeah let me try that maybe
2025-01-09 20:14:26 <fossdd[m]> uhmm bisected it to this commit: https://gitlab.gnome.org/GNOME/pango/-/commit/fe6dd76eda6a906fe1e6b4f8d8d63863f89f2de1
2025-01-09 20:14:49 <fossdd[m]> but now i'll finally eat
2025-01-09 20:17:21 <bl4ckb0ne> > Note that the line break tests are currently broken.
2025-01-09 20:17:21 <bl4ckb0ne> nice
2025-01-09 20:30:18 <fossdd[m]> yeah and i suppose the didnt got to fix it, so i think ill just disable it
2025-01-09 20:31:15 <bl4ckb0ne> probably wise yeah
2025-01-09 20:58:30 <vkrishn> there has been some improvement, since amber discussions https://alogs.koi.moe/log?id=510969&start=-50&end=50#log-510969 , https://docs.mesa3d.org/amber.html#building
2025-01-09 20:58:46 <vkrishn> it can exist together
2025-01-10 07:17:16 <Asmadeus> Is @lucaweiss around here? I'd really like to have some feedback on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77498 (kludge to make libgpiod v2's gpioget/set temporarily compatible with v1 to allow an upgrade path), even if it's a hard no (too dangerous or just CBA); this has been impacting our users (and it's just bad manners to just break compat without any heads up) so I'd 
2025-01-10 07:17:22 <Asmadeus> like to smooth things a bit temporarily
2025-01-10 10:17:06 <PaoloBarbolini[m]> I see there are many more open MRs than I usually see on the aports repo. Is there any way we could help?
2025-01-10 10:41:42 <ncopa> PaoloBarbolini[m]: i think it would be good to help the Draft issues out of Draft state. or help the ones that fails in CI to make them pass
2025-01-10 10:45:26 <raspbeguy> Hello, could someone have a look at !72559 please? Also more recently !78117, !74517, !78116 and !78118
2025-01-10 11:19:06 <ikke> There are a lot of MRs waiting on maintainers
2025-01-10 11:19:25 <ikke> >200
2025-01-10 11:19:40 <ikke> (at least, assigned to a maintainer)
2025-01-10 11:53:07 <j_v> ikke: is it possible for maintainer without commit rights to Approve an mr? for !78200, i gave it a 'thumbs up' and commented 'LGTM', but did not find a method to mark the mr as approved.
2025-01-10 11:59:12 <fabricionaweb> I also have one new aport just sitting xD but I can wait
2025-01-10 11:59:38 <fabricionaweb> 
ACTION 🪑

2025-01-10 12:00:06 <ikke> j_v: you have to be added as guest to the project. Then you can approve it
2025-01-10 12:01:30 <j_v> ikke: ok, thanks for the explanation. just wanted to make sure i am doing my due diligence.
2025-01-10 13:00:36 <omni> j_v: and an "LGTM" comment from a maintainer is fine, if you lack the ability to mark it as Approved, it will bump the MR (but just clicking thumbs up will not and will thus take longer to notice)
2025-01-10 13:06:49 <j_v> omni: i appreciate your clarification. good to know. ty
2025-01-10 13:49:23 <ncopa> i woudl like to add maintainers as guests
2025-01-10 13:49:28 <ncopa> so they can approve
2025-01-10 13:49:39 <ncopa> i dont know how much work it means
2025-01-10 13:49:54 <ncopa> can guests also assign issues?
2025-01-10 13:50:42 <ncopa> maybe we could have the bot to auto rebase-and-merge MRs which are approved by the assignee
2025-01-10 13:51:13 <ncopa> ... and only if it passes CI
2025-01-10 13:56:40 <omni> in my experience, they too often need additional review to be made automatic
2025-01-10 13:57:34 <omni> if such a bot would only do it if there are minimal changes, like simple minor upgrades, and also do proper SODIFF checks, perhaps..
2025-01-10 13:57:53 <ncopa> yeah, coudl start with those
2025-01-10 13:58:26 <ncopa> it would be helpful even if they only offloaded half of the MRs
2025-01-10 14:02:56 <omni> most of the time such minor changes are things that could be automated but sometimes, and "too often", not
2025-01-10 14:03:48 <ncopa> I find the workflow time consuming, partly due to gitlab is slow. first click on merge requests. wait 1 sec. click on the MR, wait 2 sec.click at the changes. wait 1 sec. go back to overview. (1 sec). click rebase. wait 10-15 sec. you easily spend ~30 sec waiting on gitlab per MR. with 670 MRs it adds up. 
2025-01-10 14:03:58 <ncopa> would be nice if gitlab was snappier.
2025-01-10 14:03:58 <omni> but it would only offload the really low hanging fruit, that is not too much work anyway, but perhaps that's just me
2025-01-10 14:04:27 <omni> yeah, the gitlab UI sure is sluggish
2025-01-10 14:05:11 <omni> (and I really should update my workflow to use glab more often)
2025-01-10 14:06:13 <omni> I wouldn't stand for it if I didn't use qutebrowser, and it's still frustrating how the stupid web shit is jumping around when you try to do stuff
2025-01-10 14:06:26 <j_v> the point that omni makes about 'and "too often", no' is one that i think is very valid... an ounce of prevention is worth a pound of repair
2025-01-10 14:10:46 <ikke> To be honest, the trivial maintainer updates are the easiest to handle, and the lowest amount of MRs that remain open
2025-01-10 14:11:35 <ikke> The bulk is MRs waiting for maintainer feedback, new aports and broken MRs
2025-01-10 14:12:35 <ikke> ncopa: I use glab + nq to automate rebasing and merging MRs
2025-01-10 14:13:24 <fossdd[m]> i mean there is marge-bot, which rebases + merges if you assign the bot to the MR
2025-01-10 14:13:28 <fossdd[m]> https://gitlab.com/postmarketOS/marge-bot
2025-01-10 14:14:43 <dalias> is there a safe way to install edge packages on stable?
2025-01-10 14:14:51 <fossdd[m]> dalias: not really
2025-01-10 14:14:56 <fossdd[m]> unless you build them directly against stable
2025-01-10 14:15:21 <dalias> maybe a chroot
2025-01-10 14:15:32 <fossdd[m]> or like that, yeah
2025-01-10 14:16:38 <dalias> i might should setup a framework for that
2025-01-10 14:18:09 <dalias> where only system packages are on main root stable and i have a chroot apk environment for applications and overlay it onto main view
2025-01-10 14:18:34 <dalias> maybe even multiple ones so i can add/update some apps without breaking others
2025-01-10 14:18:45 <fossdd[m]> sounds interesting
2025-01-10 14:28:47 <ncopa> dalias: it often works, but there are no guarantees
2025-01-10 14:30:04 <vkrishn> some maybe already doing it, if not try passing your firefox through ssh socks (i notice some speed)
2025-01-10 14:30:19 <vkrishn> https://tpaste.us/yBgd
2025-01-10 14:30:42 <vkrishn> its good to use socks in winter
2025-01-10 17:03:59 <PaoloBarbolini[m]> !66288 and !66289 could probably be closed given that they target EOL Alpine versions and they fail to build anyways
2025-01-10 18:12:11 <ncopa> Thanks!
2025-01-10 18:34:01 <ikke> Anyone caring to take over maintenance for netdata?
2025-01-10 18:52:19 <vkrishn> ncopa: will it make sense to have booth bootx64.efi and bootia32.efi in x86_64 isos?
2025-01-10 18:53:06 <vkrishn> i noticed on some old bios bootia32.efi gets picked
2025-01-10 18:53:53 <vkrishn> or it will complicate things?
2025-01-10 19:25:29 <fabricionaweb> when a .patch have the .patch.noauto exntesion, what the .noauto means?
2025-01-10 19:26:00 <ikke> fabricionaweb: it means nothing, except that it bypasses abuilds automatic application of patches which looks for files with the *.patch extension
2025-01-10 19:26:39 <fabricionaweb> ahh cool, I see the patch is applied on APKBUILD manually ok
2025-01-10 19:26:40 <fabricionaweb> thanks
2025-01-10 19:36:37 <durrendal> ikke: how has the maintenance for it been in the past? has it been tough to keep up to date?
2025-01-10 19:38:53 <ikke> One issue is that they are migrating / switching over to some propriatary web interface
2025-01-10 19:39:17 <ikke> And I must say, I haven't been keeping it up-to-date lately
2025-01-10 19:57:14 <durrendal> I was just looking at that, the licensing terms don't look great. https://app.netdata.cloud/LICENSE.txt
2025-01-10 19:58:19 <durrendal> I guess the package would need to remove the UI components at some point, and then a user could pull them in if they wanted to.
2025-01-10 19:58:37 <ikke> In the current version, it's already patched to still use the old UI
2025-01-10 19:58:51 <durrendal> :) now that's a solution I like 
2025-01-10 19:59:08 <ikke> The question is whether that will still be possible in the future
2025-01-10 19:59:27 <ikke> https://github.com/netdata/netdata/pull/18437
2025-01-10 20:03:02 <durrendal> That's a significant amount of work to just replace the frontend
2025-01-10 20:03:18 <ikke> that's not the patch btw
2025-01-10 20:03:56 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/netdata/disable-non-free-dashboard-v2.patch
2025-01-10 20:03:56 <durrendal> yeah reading through it, I was thinking about it backwards, it what they changed to force you into the proprietary ui
2025-01-10 20:04:57 <durrendal> that's not that bad (your patch), but I see the concern, upstream could easily make this more difficult
2025-01-10 20:05:29 <ikke> more difficult as in, dropping the v1 dashboard code
2025-01-10 20:06:50 <ikke> The patch came from opensuse :)
2025-01-10 20:16:05 <durrendal> would alpine accept a script as part of the package to easy installation of the proprietary dashboard if the proprietary bits weren't included?
2025-01-10 20:16:41 <durrendal> seems like a bit of a grey area, but that would probably be the route I would go if it came to it, to make it easier on consumers of the package
2025-01-10 20:17:54 <ikke> Probably
2025-01-10 20:18:22 <ikke> similar how debian ships mib files. They have a package called snmp-mibs-downloader
2025-01-10 20:25:54 <ikke> But the question is if we want to ship a project that relies on a proprietary interface
2025-01-10 20:29:02 <fossdd[m]> yeah that sounds kinda fishy
2025-01-10 20:29:23 <fossdd[m]> imo that makes more sense in a private aports repo
2025-01-10 21:15:26 <vkrishn> yabadabadoo, i copied bootia32.efi to efi/ dir and booted my asus netbook and it booted successfully
2025-01-10 21:15:43 <vkrishn> its on v3.21.2_x86_64
2025-01-10 21:16:14 <vkrishn> will test a bit, then create an issue :)
2025-01-10 21:17:35 <vkrishn> to /efi/boot/ ^
2025-01-10 21:18:26 <ikke> nice
2025-01-10 21:22:15 <vkrishn> confirmed, removed and re-booted, fails to boot
2025-01-10 21:22:23 <vkrishn> readded, and it boots
2025-01-10 21:23:08 <vkrishn> both .efi needs to be there for backward-compat, unless bootia32.efi posses some security issue
2025-01-10 21:23:54 <vkrishn> x86 does not need 64.efi
2025-01-10 21:24:07 <vkrishn> x86.isos ^
2025-01-10 21:28:22 <vkrishn> noticed some sof- related merge, checking if related to this device
2025-01-10 21:33:34 <vkrishn> wow, some busybox related shell line-edits issues been fixed
2025-01-10 21:39:39 <vkrishn> funny rndis module recogonizes usb0 as eth0
2025-01-10 21:49:21 <vkrishn> hmm.. community/sof-firmware: upgrade to 2024.09.2 , 12hrs ago
2025-01-10 22:02:50 <vkrishn> with both .efi it boots in 2nd gen laptop
2025-01-10 22:14:52 <vkrishn> thanks fossdd[m] for sof- updates, hope that fixes some more issues
2025-01-10 23:02:03 <vkrishn> is this a bug or modloop is not build with symlinks for files in it ?
2025-01-10 23:03:10 <vkrishn> i have done the writeup for issue but someone confirm it pls
2025-01-10 23:04:06 <vkrishn> https://tpaste.us/5QPx 
2025-01-10 23:07:21 <vkrishn> a fattening issue (pun, as fat fs cannot have symlinks)
2025-01-10 23:09:20 <vkrishn> if i squashfs both brcm/ folders i still save 5mb on apk folder side
2025-01-10 23:20:47 <vkrishn> seems non-trivial to squash it, as it symlinks to file outside its folder
2025-01-10 23:24:21 <vkrishn> current full firmware is 600Mb+
2025-01-10 23:25:15 <vkrishn> i think next-generation kids would call their OS, firmwaresoft or firwareux
2025-01-11 10:56:58 <omni> any wayfire user that would like to maintain wayfire packages? !76171
2025-01-11 11:01:55 <omni> dalias: perhaps distrobox would be of interest?
2025-01-11 13:42:05 <qaqland> have a question, how can I keep abuild -K option in rootbld subcommand?
2025-01-11 13:43:57 <qaqland> want to inspect error in !78356
2025-01-11 13:55:31 <qaqland> 
ACTION AFK

2025-01-11 14:39:37 <j_v> qaqland: the -K option should keep the rootbld container chroot dir in /var/tmp/abuild.$(some_tmpdir_suffix). if you have other of those directories in /var/tmp, the trick is figuring out which one to inspect.
2025-01-11 14:45:53 <ikke> or remove them before building again
2025-01-11 15:45:57 <j_v> ikke: yep, that is the way. i just remember the first time i figured out where to find those chroot dir's, i had a mess of them from prior -K runs when i thought -K wasn't saving anything. there could be documentation about it, but i haven't seen it yet. could be i haven't looked hard enough. but it is handy to see just what is in that chroot, not to mention the build artifacts,
2025-01-11 15:45:59 <j_v> also.
2025-01-12 13:05:53 <omni> is !77715 locked? I cannot rebase it
2025-01-12 13:07:21 <ikke> "Allow commits from members who can merge to the target branch" was not enabled
2025-01-12 13:16:54 <omni> is this something that users actively choose?
2025-01-12 13:17:47 <ikke> normally aports-qa-bot should automatically enable that
2025-01-12 13:19:08 <omni> ok
2025-01-12 14:00:47 <ikke> I don't see any details, but if I look at the qa-bot log, I see that the service ran
2025-01-12 14:00:53 <ikke> to change the settings
2025-01-12 14:02:19 <ikke> Thanks for taking care of the MR queue :)
2025-01-12 17:30:23 <fabricionaweb> when moving a package from testing to community, do I need to bump pkgrel?
2025-01-12 17:30:52 <ikke> no
2025-01-12 17:31:25 <ikke> unless you are also making other changes 
2025-01-12 18:29:57 <DylanVanAssche> My tests are failing in the CI because a kernel option is not enabled, would it be possible to enable it? If so, which kernel is used in CI?
2025-01-12 18:30:30 <ikke> DylanVanAssche: We use -lts kernels generally stable releases
2025-01-12 18:31:02 <DylanVanAssche> ikkeSo If I patch the config in aports and submit it as a MR, it would be fine?
2025-01-12 18:31:38 <ikke> It would need to be backported, and then we would need to update and reboot the releval CI host
2025-01-12 18:31:45 <ikke> relevant
2025-01-12 18:32:05 <ikke> If it's ppc64le and/or s390x, it's a bit more involved
2025-01-12 18:34:00 <DylanVanAssche> I mostly care about aarch64
2025-01-12 18:34:21 <DylanVanAssche> That's the main target of the library, x86 passed but ARM aarch64 not
2025-01-12 18:35:49 <DylanVanAssche> I disabled tests for now, will look into the config and try to patch it. Once everything lands, I can re-enable tests
2025-01-12 18:37:46 <ikke> Ok, please ping me when the kernels are available
2025-01-12 18:38:15 <ikke> oh, for aarch64, we use the -virt kernel (because it's in a VM)
2025-01-12 20:19:26 <vkrishn> how does https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/openrc/modloop.initd?ref_type=heads#L116 (modoverlayfs) work?
2025-01-12 20:20:08 <vkrishn> both in diskless and sys boot?
2025-01-12 20:37:51 <vkrishn> i think it works now in diskless, trying it with full setup
2025-01-12 20:38:14 <ikke> You don't need it for a sys install
2025-01-12 20:58:49 <vkrishn> thanks, was guessing as its already writable
2025-01-12 20:59:13 <vkrishn> may have found a bug
2025-01-12 20:59:28 <ikke> The goal of modloop is to save memory by not installing modules and firmware on tmpfs
2025-01-12 21:00:48 <vkrishn> but modloop currently has duplicate files, need some thinkings to be done on it
2025-01-12 21:02:02 <vkrishn> simply asking more firmwares to be included, will become inconvenient
2025-01-12 21:11:41 <vkrishn> and another one in modloop.initd
2025-01-12 21:12:07 <vkrishn> making a patch now
2025-01-12 21:25:12 <vkrishn> ikke: does it make sense https://tpaste.us/j1OV 
2025-01-12 21:26:36 <ikke> vkrishn: isn't the idea of the overlay that you _don't_ need to copy?
2025-01-12 21:27:55 <vkrishn> but overlay which folder ?
2025-01-12 21:30:27 <vkrishn> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/openrc/modloop.initd?ref_type=heads#L127
2025-01-12 21:31:26 <vkrishn> overlayfs makes it writable, maybe it need more documentation
2025-01-12 21:31:44 <ikke> yeah, normally if you mount the modloop directly, then nothign else can write to it
2025-01-12 21:31:47 <ikke> but with overlayfs, you can
2025-01-12 21:32:50 <vkrishn> yup :)
2025-01-12 21:34:50 <vkrishn> unionfs used be previous defacto
2025-01-12 21:37:14 <vkrishn> thinking of another enhacement, will generate another patch for it
2025-01-12 21:58:26 <vkrishn> with some more changes there is possibility for al to get free from firmware requests
2025-01-12 21:59:24 <vkrishn> ahh.. ikke which irc client u use ? wanna try others, something not ok in weechat
2025-01-12 21:59:51 <ikke> I use weechat ;-)
2025-01-12 22:04:32 <vkrishn> duh!
2025-01-13 07:40:13 <qaqland> ncopa: can we drop the testing/flamegraph port? it conflicts !77669
2025-01-13 08:09:05 <ncopa> qaqland. done. 240c4a95371e60aa564ee02d339f077460eebd8b
2025-01-13 09:12:32 <vkrishn> ncopa: have a look at, https://d.insteps.net/patches/openrc/
2025-01-13 09:12:51 <vkrishn> 1.txt - should be complete
2025-01-13 09:14:02 <vkrishn> 2.txt - requires somemore changes (in modloop building code)
2025-01-13 09:16:16 <vkrishn> if ok, i can create an issue (or try mr)
2025-01-13 09:19:48 <vkrishn> some more changes if these work, which should then make al free of request of adding new firmware
2025-01-13 09:38:16 <ncopa> please create an MR an write why this change is needed so I dont have to guess what the intention is
2025-01-13 09:39:55 <vkrishn> issue is ok? mr means it should be complete code
2025-01-13 09:49:26 <ncopa> ok
2025-01-13 09:51:20 <vkrishn> thanks, on it
2025-01-13 10:22:59 <DylanVanAssche> ikkeWill ping you when it is fixed in aports. Thanks!
2025-01-13 14:32:28 <dalias> is there a reason freecad is in testing not community yet?
2025-01-13 14:52:04 <ncopa> dalias: most likely due to noby has created merge request to move it 
2025-01-13 15:00:09 <dalias> :/
2025-01-13 15:00:26 <dalias> i'm on stable now without it and can't afford to break system with edge stuff atm
2025-01-13 15:00:35 <dalias> but i guess i can send one next month if needed
2025-01-13 15:01:17 <ncopa> I suppose I can do it for you
2025-01-13 15:01:28 <dalias> if you an confirm package works
2025-01-13 15:05:16 <ncopa> looks like it has some build issues
2025-01-13 15:06:15 <ncopa>  /home/ncopa/aports/testing/freecad/src/FreeCAD-1.0.0/src/App/PropertyExpressionEngine.h:31:10: fatal error: App/PropertyLinks.h: No such file or directory
2025-01-13 15:06:15 <ncopa> compilation terminated.
2025-01-13 15:57:01 <dalias> doh
2025-01-13 15:57:23 <dalias> theres a pkg in edge tho..?
2025-01-13 17:17:05 <fossdd[m]> someone feels like merging !78390 and !78391?
2025-01-13 20:30:54 <vkrishn> fixed some issues, tested 1st part or firmware overlay, reboot and it seems to work
2025-01-13 20:32:04 <vkrishn> will let ncopa nice it and fix ebegin...eend part 
2025-01-13 20:40:24 <vkrishn> and my sof-audio- firmware got picked up ... \o/
2025-01-14 07:55:33 <fossdd[m]> can someone also merge !78392?
2025-01-14 07:59:00 <PureTryOut> A very useful MR
2025-01-14 07:59:47 <fossdd[m]> well, it properly tests the packages against big endian which can be quite useful
2025-01-14 08:00:37 <fossdd[m]> thanks!
2025-01-14 12:08:28 <fabled> ncopa: tagged apk-tools 2.14.8 just now with a handful of bug fixes
2025-01-14 12:09:33 <ikke> https://gitlab.alpinelinux.org/alpine/apk-tools/-/compare/v2.14.7...v2.14.8
2025-01-14 13:02:09 <ncopa> nice!
2025-01-14 13:02:33 <ncopa> I'll bump it in edge
2025-01-14 13:02:52 <ncopa> we can run it in edge over the weekend and I bump it in stable branches next week
2025-01-14 14:16:27 <fabled> ncopa: thanks, soname change is also implied, so you probably need to pkgrel bump the dependees
2025-01-14 14:50:41 <ncopa> oh, right
2025-01-14 15:02:55 <ncopa> every single one of the fails to build for some reason
2025-01-14 15:35:55 <fabled> Huh
2025-01-14 15:54:19 <fabled> check fails
2025-01-14 15:58:51 <vkrishn> sounds like "manic tuesday"
2025-01-14 16:04:49 <fabled> oh, now i know
2025-01-14 16:05:12 <fabled> there's two separate issues, a new one triggering an older one
2025-01-14 16:08:12 <fabled> the autoupdate works now slightly differently, especially when using as library
2025-01-14 16:08:16 <fabled> and that triggers index update
2025-01-14 16:08:37 <fabled> and the libapk-qt will then do things which are not supported anymore
2025-01-14 16:08:43 <fabled> and intentionally assert()
2025-01-14 16:22:28 <fabled> ncopa: just pushed a commit that should fix the apk dependees.
2025-01-14 16:22:35 <fabled> if you can verify that, i'll make a dot release
2025-01-14 16:23:33 <fabled> actually, that fixes it
2025-01-14 16:23:47 <fabled> the bindings still self-define and misuse a #define that was removed
2025-01-14 16:23:54 <fabled> but at least it will not trigger anymore
2025-01-14 16:24:34 <fabled> made a new tag too now
2025-01-14 16:29:36 <fabled> ncopa: abumped apk-tools, hopefully things will now work out for the dependee packages
2025-01-14 16:30:22 <ncopa> thank! I'll add it to the MR
2025-01-14 16:30:50 <ncopa> >>> apk-tools: Installing for build: build-base musl>=1.2.3_git20230424 ca-certificates-bundle openssl>3 lua5.3 lua5.3-lzlib scdoc zlib-dev openssl-dev zlib-static openssl-libs-static linux-headers lua5.3-dev ccache
2025-01-14 16:30:50 <ncopa> cache_max_age=14400
2025-01-14 16:30:50 <ncopa> cache_max_age=14400
2025-01-14 16:30:50 <ncopa> cache_max_age=14400
2025-01-14 16:30:50 <ncopa> cache_max_age=14400
2025-01-14 16:30:52 <ncopa> cache_max_age=14400
2025-01-14 16:31:14 <ncopa> is that debug printf leftovers? (in 2.14.8)
2025-01-14 16:32:50 <ncopa> yeah :D
2025-01-14 16:33:08 <vkrishn> working code for firmware overlay seems working, https://git.insteps.net/mess/aportsbag/tree/openrc
2025-01-14 16:33:37 <vkrishn> ncopa:  modloop.initd,  modloop.initd.readme , add it to gitlab.a.o (issue) soonish
2025-01-14 16:33:50 <vkrishn> will add it to^
2025-01-14 16:34:17 <ikke> ncopa: there's a commit to remove it
2025-01-14 16:34:26 <ikke> ncopa: https://git.alpinelinux.org/apk-tools/commit/?id=bf50ae7d11e6
2025-01-14 16:34:40 <ncopa> i just saw :)
2025-01-14 16:35:36 <fabled> note to self: never backport anything non-trivial or release when not fully recovered.
2025-01-14 16:36:58 <ncopa> :)
2025-01-14 16:37:17 <ncopa> thank you for the quick follow up release
2025-01-14 17:07:45 <JohannesJacobs[m]12> ncopa sorry to bother you here, but did you see my reply to you on mastodon? :)
2025-01-14 17:10:57 <ikke> It's not for Bart
2025-01-14 17:11:20 <ikke> It's for our risv64 builders
2025-01-14 17:11:32 <JohannesJacobs[m]12> ok well, how can i help? :)
2025-01-14 17:11:44 <ikke> If you have something, please contact clandmeter 
2025-01-14 17:11:53 <JohannesJacobs[m]12> ok will do!
2025-01-14 18:06:26 <craftyguy[m]> how do I search apk for all packages that depend on some soname, for identifying which packages need to be rebuilt when a lib is upgraded?
2025-01-14 18:07:32 <PureTryOut> apk info -d so:whatever
2025-01-14 18:07:59 <craftyguy[m]> thank you :)
2025-01-14 18:09:54 <ikke> craftyguy[m]: I use this incantation :P
2025-01-14 18:09:56 <ikke> apk search -q --has-origin libkiwix | xargs apk info -Pq | awk -F'=' '/so:/ {print $1}' | xargs apk search -q -or  | sort -u | xargs printf '- %s\n'
2025-01-14 18:14:06 <craftyguy[m]> wowzers :P
2025-01-14 18:14:43 <fabled> i'm gonna do a new "apk query" thing that can give that on one go
2025-01-14 18:14:52 <ikke> fabled: cool
2025-01-14 18:15:48 <craftyguy[m]> nice!
2025-01-14 18:16:16 <craftyguy[m]> then maybe we can have CI do it, so we can figure out pre-merge which pkgs should be rebuilt when a library is upgraded heh
2025-01-14 19:33:15 <hjaekel> In !76326 bl4ckb0ne and I are trying to figure out how depends vs depends-dev should be used for header-only libraries. Can anyone help?
2025-01-14 19:34:39 <bl4ckb0ne> ah right ive been meaning to come back to this, thanks
2025-01-14 19:37:08 <hjaekel> Me too, but the bot reminded me.
2025-01-14 19:37:39 <ikke> I think depends_dev only makes sense if you have a -dev subpackage
2025-01-14 19:38:38 <ikke> check_depends_dev || warning "depends_dev found but no development subpackage found"
2025-01-14 19:38:42 <ikke> yup, that confirms it
2025-01-14 19:38:58 <hjaekel> In my case, the root package is serving as -dev package
2025-01-14 19:39:09 <ikke> yes
2025-01-14 19:39:53 <ikke> To me it would make sense that if someone manually installs the header-only package with apk to build something with it, the relevant dependencies to build with it should also come
2025-01-14 19:46:43 <hjaekel> OK, thank you ikke
2025-01-14 19:46:58 <bl4ckb0ne> thanks
2025-01-14 19:47:03 <bl4ckb0ne> so its all good to merge?
2025-01-14 19:47:05 <hjaekel> bl4ckb0ne let me rebase and upgrade to the latest version
2025-01-14 19:47:09 <bl4ckb0ne> sure
2025-01-14 19:50:03 <hjaekel> done. you can merge when you think its ready
2025-01-14 21:18:19 <craftyguy[m]> FYI folks who run mirrors over rsync... https://www.openwall.com/lists/oss-security/2025/01/14/3 (the 9.8's summary is terrifying)
2025-01-14 21:21:41 <ikke> yes, was mentioned in #alpine-security
2025-01-14 21:22:08 <ikke> Trying to build it, but for some reason it cannot build man pages and fails on that
2025-01-14 21:23:59 <craftyguy[m]> oh ok, figured y'all might have already known but just in case. thanks for working on the upgrade :)
2025-01-14 21:56:08 <Asmadeus> Does alpine have any policy on non-upstream patches? (Asking for !77498 -- that would be only for the rest of 3.21 community lifetime so it's nothing long-lived and we'd basically drop the patch in 4 months when 3.22 is out, but it's still a non-upstream kludge)
2025-01-15 08:31:42 <fabricionaweb> Traefik tests are always a pain
2025-01-15 08:55:16 <fabricionaweb> on my machine it passed but also failed once, kinda intermintent... no sure how to improve/fix that tho, I will investigate
2025-01-15 09:42:32 <ovf> i just realised that one needs something like -devdoc in addition to -dev and -doc. e.g. now if i have 'docs' installing libidn (even as a dependency) pulls in libidn-doc, which is (mostly) man pages, that are quite useless without libidn-dev
2025-01-15 10:16:23 <mzh> Hi, anyone knows how to keep intermediate files of `abuild -r` ? My doute is "opencv" config files been deleted when packaging.
2025-01-15 10:47:30 <ikke> -K
2025-01-15 11:03:21 <fabricionaweb> ok so tests pass on my machine but not on ci, any tip how to mitigate it
2025-01-15 11:03:41 <fabricionaweb> maybe I have deps that is missing for check
2025-01-15 11:25:29 <fabricionaweb> I think it is some kind of dns issue with the ci container, I had similar issue on another aport as well
2025-01-15 11:25:34 <fabricionaweb> but its fine just skip that test
2025-01-15 11:41:00 <fabricionaweb> still failing, I give up
2025-01-15 11:44:19 <ikke> what test?
2025-01-15 11:45:51 <fabricionaweb> for traefik
2025-01-15 11:45:59 <fabricionaweb> a retry seems to worked
2025-01-15 11:46:07 <fabricionaweb> but thats not a good sign
2025-01-15 11:46:53 <fabricionaweb> also it is too many stuff failing all over different places hahahah
2025-01-15 11:49:04 <j_v> fabricionaweb: abuild -r or abuild rootbld?;
2025-01-15 11:49:34 <fabricionaweb> local is passing on both
2025-01-15 11:50:36 <j_v> ah, sorry, i miss read, the issues are on ci. all arches, just certain one(s)?
2025-01-15 12:00:02 <j_v> i wonder if it's a 32bit thing, all the arches failing are that
2025-01-15 12:02:06 <fabricionaweb> there are one that seems to be related to 32bit, I will disable it
2025-01-15 12:02:10 <fabricionaweb> there is*
2025-01-15 12:04:35 <j_v> i haven't studied go, so i'm afraid i can't be much help. c/lua/shell is more my thing. sorry
2025-01-15 12:06:44 <j_v> i see some notes in the arch pkgbuild that might worth your time looking at
2025-01-15 12:09:12 <j_v> https://gitlab.archlinux.org/archlinux/packaging/packages/traefik/-/blob/main/PKGBUILD?ref_type=heads#L66
2025-01-15 12:13:01 <j_v> scoping round my usual targets, arch seems the most current. gentoo, void, chimera don't package it. could look at fedora, but i usually avoid that route as get annoyed reading rpm spec files
2025-01-15 12:33:10 <mzh> ikke thx
2025-01-15 12:34:36 <fabricionaweb> thank you j_v
2025-01-15 12:36:27 <mzh> fabricionaweb: I'm one of Go developer, can you paste url that CI runs?
2025-01-15 12:38:11 <j_v> fabricionaweb: yw, hope you find a solution