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
2025-01-15 14:37:18 <fabricionaweb> I believe I will run tests on x86_64 only
2025-01-15 16:09:14 <sam_> ncopa: thanks for the rsync fixes
2025-01-15 16:22:28 <ncopa> i wonder if I should have done the debian thing, and backport the 6 patches (+ regression fix)
2025-01-15 16:22:54 <ncopa> who knows what else broke in this release
2025-01-15 16:24:51 <sam_> i've done that fwiw
2025-01-15 16:24:57 <sam_> 6 patches + your fixes on top
2025-01-15 16:25:02 <sam_> just because i feel like there's bound to be more
2025-01-15 16:25:38 <Metroid> it's a shame because rsync was always a 'just works' tool
2025-01-15 16:29:47 <sam_> ncopa: my thinking being "man, all that stuff got found *very quickly*, it wouldn't surprise me if there were more subtle regressions"
2025-01-15 16:29:57 <sam_> of course, the problem is, I think all the regressions so far were in the CVE fixes
2025-01-15 16:32:00 <dne> it was under embargo for months though?
2025-01-15 17:03:07 <craftyguy[m]> seems like it was poorly handled :/
2025-01-15 20:22:16 <dne> lol https://github.com/RsyncProject/rsync/pull/705#pullrequestreview-2553701442
2025-01-15 20:24:07 <pj> comment in issue is much better
2025-01-15 20:26:52 <ikke> lol
2025-01-15 20:49:36 <iggy> matches with what I was thinking earlier... cg: "seems like it was poorly handled" me: "or more likely not handled at all because rsync is basically abandonware at this point"
2025-01-15 21:27:41 <fossdd[m]> haha thats funny
2025-01-15 21:29:39 <fossdd[m]> but iirc also new maintainers picked up rsync a few months ago since rsync was basically in maintainance mode
2025-01-15 21:29:54 <fossdd[m]> or am i mixing something
2025-01-15 21:30:05 <dne> 3.4.1 released ~25 min ago
2025-01-15 21:43:25 <vkrishn> managed to split firmware from modloop into separate modloop.firmware, rebooted, went well
2025-01-15 21:43:42 <vkrishn> creating next issue :)
2025-01-15 21:45:08 <vkrishn> hopefully wait period for users asking for their favorite firmwares, should be over
2025-01-16 09:56:13 <fabricionaweb> when a python app doesnt have build system (and they doesnt want to have it, I asked) what would be a proper way to have an aport? patch a build system? add the code to /usr/share/webapps or /usr/lib? or just dont make the aport?
2025-01-16 10:16:02 <chereskata> When trying to run the pipelines for !77226 i get the following error: `ERROR: qemu-pr-helper-9.2.0-r1: BAD signature`
2025-01-16 10:16:12 <chereskata> Is this to be expected atm?
2025-01-16 10:19:36 <ncopa> fabricionaweb: how does upstream envision how users install it? with cp -r?
2025-01-16 10:25:23 <ncopa> happens due to ce158e4e661b22159a88c1fc34182ed52f1a7e31 is missing pkgrel bump
2025-01-16 10:27:03 <ncopa> chereskata: I'm on it
2025-01-16 10:29:12 <chereskata> thank you 🤝
2025-01-16 10:39:22 <fabricionaweb> ncopa, yes, aur does the cp -r, and for the rest they think apt/deb is everything 🙈
2025-01-16 10:40:25 <fabricionaweb> seems bsd also does cp or something, I dont understand bsd
2025-01-16 10:42:32 <lotheac> ncopa: doh... sorry, my bad
2025-01-16 10:44:01 <ncopa> fabricionaweb: there you go
2025-01-16 10:46:06 <fabricionaweb> ok may I try make the aport again, thanks
2025-01-16 10:46:34 <fabricionaweb> do we have wiki or something about when to use the /usr/share/webapps instead of /usr/lib?
2025-01-16 10:52:51 <wyk72> Hello 
2025-01-16 10:54:11 <wyk72> I have to report that the latest tunctl/busybox shipped with 3.21.2 crashes with segfault often
2025-01-16 10:54:21 <wyk72> [ 3883.371732] tunctl[6079]: segfault at 0 ip 00007f84459d8178 sp 00007ffc38086970 error 4 in ld-musl-x86_64.so.1[21178,7f84459cb000+57000] likely on CPU 7 (core 10, socket 0) [ 3883.371749] Code: 4d 85 db 74 06 41 f6 03 20 74 36 45 85 ed 74 56 49 89 de b8 ff ff ff 7f 44 29 e0 44 39 f8 0f 8c 19 02 00 00 41 b8 ff ff ff 7f <41> 0f b6 06 45 01 fc 84 c0 0f 84 35 0d 00 00 4d 89 f5 e9 7a ff ff
2025-01-16 10:54:51 <wyk72> happens on all production machines (4) I updated yesterday
2025-01-16 10:55:38 <wyk72> functionality seems OK, but I have those crashes in dmesg
2025-01-16 11:15:03 <chereskata> does traceroute work for you?
2025-01-16 11:21:58 <wyk72> traceroute works ok
2025-01-16 11:22:25 <chereskata> thanks :)
2025-01-16 11:27:36 <ikke> wyk72: is it reproducable?
2025-01-16 11:29:42 <wyk72> absolutely
2025-01-16 11:30:46 <ikke> Could you open an issue with the details?
2025-01-16 11:30:53 <wyk72> it kicks in on a script I use for launching QEMU
2025-01-16 11:30:55 <wyk72> yep
2025-01-16 11:30:57 <ikke> Perhaps even try to get a backtrace
2025-01-16 11:30:58 <wyk72> where ? gitlab?
2025-01-16 11:31:00 <ikke> yes
2025-01-16 11:31:18 <wyk72> ok in busybox aport?
2025-01-16 11:31:30 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues
2025-01-16 11:38:19 <wyk72> ok done
2025-01-16 11:38:38 <ikke> I see it
2025-01-16 11:38:57 <ikke> Do you think it would be possible to run the tunctl command you are executing with gdb?
2025-01-16 11:41:42 <wyk72> yep
2025-01-16 11:43:20 <ikke> see if you can get a usable backtrace
2025-01-16 11:48:45 <wyk72> oops
2025-01-16 11:48:48 <wyk72> I found the culprit
2025-01-16 11:49:57 <wyk72> it happens when I accidentally delete the tap interface while still open i.e. issuing a  tunctl -d <ifname> while interface is still used by qemu
2025-01-16 11:50:10 <ikke> aha
2025-01-16 11:50:54 <ikke> I suppose it should not segfault in any case
2025-01-16 11:52:49 <wyk72> If I close qemu, the interface gets deleted normally
2025-01-16 12:25:14 <Asmadeus> `#define IOCTL(a, b, c) ioctl_or_perror_and_die(a, b, c, NULL)` but that NULL is a non-optional format arg, so if the ioctl fails then busybox tries to printf(NULL) which segfault...
2025-01-16 12:27:53 <Asmadeus> (Doesn't look like a new bug either, but I guess it's still something that should be fixed)
2025-01-16 12:29:08 <ikke> Asmadeus: could you add that to #16846 ?
2025-01-16 12:30:31 <Asmadeus> I'll do that after I've sent the patch upstream, can always hope Denys picks it up at some point (just checking mailing list etc first)
2025-01-16 12:31:27 <Asmadeus> Trading you that work for an idea on how to move !77498 forward -- Luca (maintainer) looks ok on principle, so I should look for a review from someone who can merge?
2025-01-16 12:56:33 <Asmadeus> (patch sent, and commented)
2025-01-16 14:16:51 <fabricionaweb> hi, could someone take a look to this !77555 
2025-01-16 15:06:21 <jahway603[m]> Can I please get !78549 and !78550 merged in? Thanks.
2025-01-16 19:36:00 <famfo> Ohai, does someone have an idea of how to proceed with the timing out pipeline in !72313? One idea I have is to disable the checks for RiscV builds. Context: the RiscV builder seems to have too little single core performance to do LTO + linking for 3 binaries and a bunch of tests within the one hour time timeout.
2025-01-16 19:37:19 <ikke> Yeah, single core performance of the current boards we have is not that good
2025-01-16 19:49:40 <ncopa> maybe increase the timeout?
2025-01-16 19:51:12 <ikke> Yeah, you can increase it in your fork
2025-01-16 19:57:45 <famfo> huh, can I? Only see the runners but can't edit anything
2025-01-16 19:59:56 <famfo> The docs also say "Prerequisites: You must be an administrator.", I guess I am of my own fork but not for the runners
2025-01-16 20:04:38 <ikke> General pipelines settings 
2025-01-16 20:04:45 <ikke> The timeout is global, not per runner
2025-01-16 20:06:57 <famfo> Ah okay, thanks
2025-01-16 20:37:49 <pj> famfo: it's weird and very unintuitive but CI runs are spawned in your own fork, so CI settings from your own project apply (even for global/parent project/group runners)
2025-01-16 21:50:07 <fossdd[m]> can i get some attention at !78627? :3
2025-01-16 21:57:03 <fossdd[m]> ikke: thanks!
2025-01-17 07:34:11 <caleb_m> sertonix: btw thx for landing those fixes to abuild-meson, I reworked my pmbootstrap patches and things seem to be working nicely :D https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/merge_requests/2474 
2025-01-17 07:35:08 <caleb_m> being able to run abuild natively rather than through QEMU is honestly such a huge difference
2025-01-17 12:38:17 <fossdd[m]> can someone merge !78648?
2025-01-17 12:39:42 <invoked> sorry, i keep forgetting to check mrs
2025-01-17 12:39:53 <invoked> my bad
2025-01-17 12:41:04 <fossdd[m]> no problem
2025-01-17 12:41:13 <fossdd[m]> actually i thought it was already merged
2025-01-17 16:05:37 <fabricionaweb> my first electro aport for the happiness of no one !78515 
2025-01-17 16:07:20 <fabricionaweb> I wasnt sure about the license, I havent found OSL license in other aport
2025-01-17 16:22:05 <fossdd[m]> seems to be valid: https://spdx.org/licenses/preview/OSL-3.0.html
2025-01-17 19:25:49 <vkrishn> wasn't there some thoughts/discussion before on having separate noarch folder in downloads?
2025-01-17 19:26:31 <vkrishn> build difficulty?
2025-01-17 19:26:52 <fossdd[m]> not sure if there was a discussion but that would be the point of noarch
2025-01-17 21:20:17 <ikke> vkrishn: it's a challenge to do in a way that is really beneficial 
2025-01-17 21:24:58 <vkrishn> could start with firmwares(signed and split squashfs)
2025-01-17 21:25:43 <vkrishn> will put that in gitlab.a.o issue
2025-01-17 21:27:09 <vkrishn> can also be done upstream, or on single place for firmwares(squashfs format)
2025-01-18 09:18:23 <alex2023[m]> hi , i found a possible bug when using the kernel option apkovl,   so i came here for discussing this
2025-01-18 09:19:04 <alex2023[m]> when i use apkovl=xxx.apkovl.tar.gz  , its clearly that xxx is not my hostname
2025-01-18 09:20:28 <alex2023[m]> but when i enter the system, and want to use lbu tool, it will located hostname.apkovl.tar.gz as the destine files, which would made my next boot no effect since i already set the boot using xxx.apkovl.tar.gz
2025-01-18 09:20:55 <alex2023[m]> i dont know if its really a bug or just my missing some underground setting?
2025-01-18 12:34:26 <fossdd[m]> can someone press the big button on !78715? 😅
2025-01-18 12:37:45 <pj> and !78693
2025-01-18 12:40:27 <vkrishn> alex2023[m]: cat /etc/hostname, probably that affects it
2025-01-18 12:51:07 <alex2023[m]> vkrishn: nope, that not works
2025-01-18 12:51:54 <alex2023[m]> i think its better to change lbu's code to detect from $KOPT_apkovl first 
2025-01-18 19:43:52 <famfo> wrt to !72313, is jirutka stil unreachable over IRC/Matrix?
2025-01-19 01:03:08 <pj> famfo: unless he joins
2025-01-19 01:03:28 <pj> your best option is to ping via gitlab or fedi
2025-01-19 01:26:25 <famfo> hm, okay
2025-01-19 07:18:32 <fraolt> Can somebody please take a look at !78150 and merge. 🙇
2025-01-19 09:30:21 <fabricionaweb> Why the  --modules-folders, I didn't know was a thing hehe
2025-01-19 12:13:19 <omni> 
ACTION still not loving "usr-merge"

2025-01-19 14:39:02 <vkrishn> nice ! 400+ pkgs got build yesterday, must be a "saturday night fever"
2025-01-19 14:58:24 <WhyNotHugo> I think this can be merged? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77155 
2025-01-19 14:59:10 <WhyNotHugo> omni: i had some interesting ideas keeping /bin and /lib from the initrd while bind-mounting /usr/bin and /usr/lib from sysroot, but usr-merge killed that :(
2025-01-19 15:07:53 <orbea> yea, usr-merge is a stupid idea
2025-01-19 15:08:50 <orbea> breaks several niche use cases and gains what?
2025-01-19 15:10:03 <quinq> Some ideology
2025-01-19 15:10:41 <quinq> “I don't need it so nobody else would, or they're wrong anyway because it comes from before”
2025-01-19 15:36:47 <invoked> atomic upgrades/fallback i can sort of understand, but it's a mess
2025-01-19 15:37:03 <invoked> or if it's not, it'll do until the mess gets here
2025-01-19 15:53:18 <WhyNotHugo> why would you need usr-merge for atomic upgrades?
2025-01-19 15:56:44 <invoked> "need" is a strong word
2025-01-19 16:34:28 <zcrayfish> !78128 is ready too
2025-01-19 21:30:54 <maribu> :q
2025-01-19 21:31:17 <maribu> oops, wrong terminal, sorry for the noise :/
2025-01-19 21:36:58 <quinq> maribu, that's unacceptabel condition
2025-01-19 21:44:53 <ikke> /kick maribu :p
2025-01-19 23:55:27 <Elon_Musk> Starlink today & the 1st Month is on me ! Limited Time Offer/ PROMO CODE YOLO !  http://star.linkrelay.com/
2025-01-20 08:24:21 <fabricionaweb> "Elon_Musk" hahahahha 
2025-01-20 08:38:06 <socksinspace> somehow more of a clown than the real thing already is :P
2025-01-20 08:57:23 <fabricionaweb> hi, I have this on queue !77555
2025-01-20 16:37:29 <donoban> any idea why www.X.org seems down? https://gitlab.alpinelinux.org/donoban/aports/-/jobs/1698626#L144  with my local connection also fails but worked from a vpn
2025-01-20 16:49:24 <j_v> "The requested URL was not found on this server."
2025-01-20 16:49:53 <ikke> curl -I https://www.x.org/archive/individual/driver/xf86-video-nouveau-1.0.18.tar.bz2 -> 404
2025-01-20 16:50:36 <ikke> .tar.gz exists
2025-01-20 16:50:38 <ikke> not .tar.bz
2025-01-20 16:51:06 <donoban> lol
2025-01-20 16:51:26 <donoban> better xz?
2025-01-20 17:14:43 <Ermine> They add bz2 when upgrading stuff. And nouveau is basically unmaintained
2025-01-20 17:16:19 <sam_> no, they switch to xz on new releases
2025-01-20 17:20:04 <Ermine> idr them doing that
2025-01-20 17:21:03 <donoban> well, last version builds except for loongarch64 removing last fix and very old patch
2025-01-20 17:21:12 <donoban> builds and runs :D
2025-01-20 17:22:06 <donoban> lol loongarch failed due connection error
2025-01-20 17:23:01 <donoban> https://gitlab.alpinelinux.org/donoban/aports/-/jobs/1698696#L139
2025-01-20 17:24:04 <Ermine> happens sometimes
2025-01-20 17:31:21 <rdBF5seCfwg> maybe do a /mode +s to avoid this spam?
2025-01-20 17:36:51 <sam_> they've been doing it for like at least half a decade
2025-01-20 17:36:53 <sam_> possibly longer
2025-01-20 17:39:38 <f_> >nouveau is basically unmaintained
2025-01-20 17:39:45 <f_> #nouveau probably begs to differ
2025-01-20 17:40:14 <f_> rdBF5seCfwg: What spam?
2025-01-20 17:40:33 <f_> Ah the Elon spam... it hit libera as well, should stop now
2025-01-20 17:40:46 <f_> no the libera one was different
2025-01-20 17:40:47 <f_> anyway.
2025-01-20 17:42:06 <orbea> f_: yea, xf86-video-nouveau is mostly unmaintained, last i saw they were recommending to use modesetting
2025-01-20 17:42:10 <f_> is anyone available for !76721 ? No pressure, just wondering.
2025-01-20 17:42:18 <f_> orbea: Oh, I misunderstood then.
2025-01-20 17:42:28 <f_> I thought Ermine meant nouveau as a whole.
2025-01-20 17:42:40 <orbea> yea, i almost thought that too until i reread :P
2025-01-20 17:46:25 <donoban> wow yeah, it builds fine on all archs, I should backport to v3.21
2025-01-20 18:07:58 <tomalok> any weird kernel issues with 6.12.8?  trying to launch an instance and its startup was getting consistently stuck on a "rm" to clean up some stuff on a NFS.  try new instance, stuck same place.  commented out the "rm" and now it's getting stuck doing other things further down the line, not associated with NFS.
2025-01-20 18:12:37 <tomalok> ironically it's stuck trying to apk install linux-virt-6.12.9
2025-01-20 18:52:24 <tomalok> also kcompactd0 apparently gets stuck
2025-01-20 19:24:36 <tomalok> does not seem to affect aarch64 🤞
2025-01-20 21:05:57 <tomalok> edge (6.12.9) + aarch64 = still problems with stuck process.  different aarch64 instance type, same story.  back to x86_64, i think
2025-01-20 21:06:25 <ikke> Is this a specific cloud provider?
2025-01-20 21:06:33 <tomalok> EC2
2025-01-20 21:07:41 <tomalok> i have a nice script that runs with tiny cloud that auto joins new instances to an existing docker swarm, does some other setup/cleanup.  well, it's nice when it doesn't mysteriously not work
2025-01-20 21:09:27 <tomalok> haven't heard any similar reports of issues with aarch64? maybe i try 3.20 / 3.19 (can't remember the last time i refreshed my nodes)
2025-01-20 21:42:06 <tomalok> aarch64 / alpine 3.20.5 / kernel 6.6.69 seems to work so far
2025-01-20 21:49:04 <ikke> haven't heard something like this
2025-01-20 21:49:38 <ikke> something kernel related?
2025-01-20 22:13:40 <tomalok> not sure...  just rebuilt the whole swarm without a problem...  maybe going to do a diff betwen the 3.20.5 and 3.21.2 linux-virt configs
2025-01-20 22:13:47 <tomalok> for aarch64
2025-01-21 09:27:46 <lanodan> Seems like gitlab.alpinelinux.org is down, can send requests so I guess reverse-proxy is up but no actual answer back.
2025-01-21 09:48:21 <zacksiri> gitlab.alpinelinux.org seems to be down.
2025-01-21 10:09:34 <fabricionaweb> I was about to ask it but I got too late
2025-01-21 10:09:58 <zacksiri> it's still down.
2025-01-21 10:41:25 <zacksiri> seems to be returning 404 now
2025-01-21 10:41:30 <zacksiri> at least it's something :)
2025-01-21 10:41:39 <zacksiri> sign of life
2025-01-21 10:42:24 <ikke> clandmeter is restarting gitlab 
2025-01-21 10:42:32 <zacksiri> Thank you!
2025-01-21 10:42:44 <ikke> See #alpine-infra
2025-01-21 10:44:46 <fabricionaweb> btw this infra isnt listed in docs
2025-01-21 10:45:18 <fabricionaweb> any reason or just no one have added?
2025-01-21 10:48:10 <clandmeter> which docs?
2025-01-21 10:48:28 <zacksiri> yeah the official website doens't mention the infra channel
2025-01-21 10:49:21 <fabricionaweb> sorry I meant wiki
2025-01-21 10:49:23 <fabricionaweb> https://wiki.alpinelinux.org/wiki/Alpine_Linux:IRC
2025-01-21 10:50:17 <clandmeter> be free to add it
2025-01-21 10:50:23 <clandmeter> i guess we could also add it to our www
2025-01-21 12:10:40 <raspbeguy> Hello, I'm trying to compile a rust package and I have those errors https://termbin.com/tfu0
2025-01-21 12:11:15 <raspbeguy> do you think this is because of libc not being gnu ?
2025-01-21 12:11:52 <ikke> raspbeguy: what version of the libc create is being used?
2025-01-21 12:12:00 <ikke> raspbeguy: might be a matter of making sure it's updated
2025-01-21 12:13:11 <raspbeguy> ikke, you mean what version of the libc rust crate ?
2025-01-21 12:13:22 <ikke> yes
2025-01-21 12:13:48 <raspbeguy> seems libc-0.2.167 from the pastebin content
2025-01-21 12:51:50 <ikke> Ok, I suppose that's new enough, not sure then
2025-01-21 12:51:58 <ikke> perhaps ask also in #alpine-rust
2025-01-21 14:07:56 <raspbeguy> ok then
2025-01-21 14:45:32 <fossdd[m]> someone wanna have a look at !77457?
2025-01-21 16:04:45 <fabricionaweb> this remembers me, I make an aport that is desktop but I havent called -desktop, should I?
2025-01-21 16:04:55 <fabricionaweb> reminds me
2025-01-21 17:10:04 <f_> hmm, is the gitlab undergoing some maintenance?
2025-01-21 17:10:10 <ikke> no
2025-01-21 17:10:11 <f_> > HTTP 502: Waiting for GitLab to boot
2025-01-21 17:10:35 <f_> let me refresh again then
2025-01-21 17:11:04 <f_> Okay, works again
2025-01-21 17:11:12 <f_> I suppose maybe a programmed reboot or something
2025-01-21 17:11:51 <f_> hm, happened again
2025-01-21 17:11:57 <ikke> Unresponsive due to load I guess
2025-01-21 17:12:09 <ikke> 'Up 6 hours'
2025-01-21 17:13:09 <f_> Ah I see it was under maintenance a few hours ago
2025-01-21 17:13:20 <ikke> No, all load induced
2025-01-21 17:13:42 <f_> alright
2025-01-21 17:14:38 <f_> anyways. Anyone wanna take a quick look at !76721 if they have time?
2025-01-21 17:34:17 <fraolt> Can somebody please rebuild (or even merge) !75466? I'd like to test it.
2025-01-21 17:38:30 <donoban> !78816 finally passed
2025-01-21 19:49:27 <f_> ptrc: ooh, ty!
2025-01-22 00:29:26 <vkrishn> not important, opennhrp 0.14.1 has release src pkg but git src was not tagged
2025-01-22 01:42:44 <vkrishn> and i did, apk upgrade --available, on a running ram based install with xfce
2025-01-22 01:42:56 <vkrishn> 1. closed firefox
2025-01-22 01:43:04 <vkrishn> 2. apk fix
2025-01-22 01:43:22 <vkrishn> 3. stopped lightdm
2025-01-22 01:43:41 <vkrishn> 4. restarted udev
2025-01-22 01:43:47 <vkrishn> 5. restarted lightdm
2025-01-22 01:43:55 <vkrishn> bingo ...
2025-01-22 01:44:23 <vkrishn> that that too on edge .... 
2025-01-22 01:45:07 <vkrishn> did not even restart laptop
2025-01-22 01:47:44 <vkrishn> note: do not forget to restart other services like ssh, syslogd, acpid, crond , if running
2025-01-22 01:50:18 <vkrishn> 1b. session save xfce + log out
2025-01-22 01:50:38 <vkrishn> 1c. lbu ci
2025-01-22 01:53:06 <vkrishn> du -sh /usr -> 1.4G /usr
2025-01-22 01:58:10 <vkrishn> updated code to handle upgrade, https://git.insteps.net/mess/apklist/
2025-01-22 02:03:18 <vkrishn> did i hear someone say awesome ...
2025-01-22 02:03:32 <vkrishn> nope ... not yet
2025-01-22 03:56:42 <qaqland> last month libgit2 released v1.9.0
2025-01-22 04:00:02 <qaqland> How can I know which packages need to be rebuilt because of this upgrade?
2025-01-22 05:40:52 <j_v> qaqland: i think this is what you are looking for? apk search -r libgit2
2025-01-22 05:44:03 <j_v> qaqland: oh, actually, you'll probably want: apk search --exact --rdepends libgit2
2025-01-22 05:44:54 <j_v> otherwise it will also match on things like libgit2-glib
2025-01-22 05:49:53 <j_v> or apk search -r so:libgit.so
2025-01-22 05:50:23 <j_v> s/libgit/libgit2/
2025-01-22 06:05:07 <qaqland> apk search -r so:libgit2.so, it works! thx
2025-01-22 06:07:03 <j_v> np
2025-01-22 13:03:46 <mzh> This is a MR that makes atool-linter parse/eval license field and check whether missing $pkgname-doc package, PLAT. https://gitlab.alpinelinux.org/alpine/infra/atools-go/-/merge_requests/55 
2025-01-22 14:18:05 <ikke> mzh: I've seen it, meant to reply
2025-01-22 14:19:08 <ikke> I don't think just requiring a -doc subpkg is a good way to ensure the license file is packaged 
2025-01-22 14:19:41 <ikke> And there also a lot of py3 packages that ship the license file in the wheel metadata dir
2025-01-22 14:20:57 <mzh> ikke should I check that LICENSE file been copied?
2025-01-22 14:22:26 <ikke> At that point it's no longer a good fit for a static linter
2025-01-22 14:23:37 <mzh> maybe a hint instead of error
2025-01-22 14:23:46 <ikke> How do you deal with license files being installed by build systems?
2025-01-22 14:24:50 <ikke> The signal-to-noise ratio would be too low in my opinion 
2025-01-22 14:24:59 <mzh> U are right
2025-01-22 14:25:30 <mzh> I think i just close this MR now
2025-01-22 18:45:21 <vkrishn> not important(another), openvpn-ad-check has release src pkg but git src was not tagged
2025-01-22 18:45:40 <vkrishn> and its also on sourceforge
2025-01-22 19:25:54 <raspbeguy> Hello, could someone review !78807 and !78885 please?
2025-01-22 20:03:03 <vkrishn> anyone why running glab --help , wants to connect to this ip, 172.65.251.78 ?
2025-01-22 20:05:09 <vkrishn> this is, glab-1.52.0-r0
2025-01-22 20:30:27 <j_v> vkrishn: since that is the ipv addr of gitlab.com, i check the source so see what it might be up to. first thing i just found is it does 'check_update' if some setting is set (or not set, still looking at it)
2025-01-22 20:33:16 <j_v> looks like the config knob is just that, 'check_update'. but that is just based on looking at the code.
2025-01-22 20:34:38 <vkrishn> cannot be disabled and build without it ?
2025-01-22 20:36:17 <j_v> idk, still looking at it. (i'll be afk for a little bit, but going to keep looking when i get back)
2025-01-22 20:43:21 <vkrishn> hmmm .. method to build pkgs(glab) now whats to download temporary files
2025-01-22 20:43:34 <vkrishn> abuild is getting funnier
2025-01-22 20:46:08 <vkrishn> apk del glab, for now
2025-01-22 20:47:15 <j_v> glab config set check_update false
2025-01-22 20:47:21 <j_v> easy as that
2025-01-22 20:48:52 <j_v> that doesn't mean it doesn't do other connect attempts, but that is the first one i found
2025-01-22 20:49:21 <vkrishn> if all this gets food to table, no issue, else rething to build alpine-go, with inter-distro-usable apk pkgs
2025-01-22 20:52:22 <j_v> rething?
2025-01-22 20:52:44 <j_v> rethink?
2025-01-22 20:53:47 <vkrishn> yes, rethink :)
2025-01-22 20:54:23 <vkrishn> j_v: doesn't look like ai bot, sure 51%
2025-01-22 20:54:32 <quinq> pastis
2025-01-22 20:56:05 <vkrishn> now building glab, wanna download tons of zip file, which is not prior checksumed in ABUILD
2025-01-22 20:56:31 <vkrishn> sounds super secure to me, or not
2025-01-22 20:57:10 <j_v> that is life with programming languages like go and rust, others as well
2025-01-22 20:57:41 <vkrishn> need to be clear about the structure of APKBUILD file
2025-01-22 20:58:18 <abby> go packages are checksummed in go.sum, which is part of the release archive
2025-01-22 20:58:20 <vkrishn> then start removing all checksum in it, why all this ambiguity
2025-01-22 20:58:46 <vkrishn> where is that go.sum?
2025-01-22 20:59:13 <Habbie> in the release archive
2025-01-22 20:59:24 <Habbie> the downloaded tar or zip
2025-01-22 21:00:46 <vkrishn> so now whenever i build a go pkg i need to tell this folks, hey, i am build again
2025-01-22 21:01:01 <vkrishn> cannot just add to distfiles, can i?
2025-01-22 21:01:31 <vkrishn> so the concept of distfiles is now distorted
2025-01-22 21:02:03 <vkrishn> hey man, we will distfile your distfile too
2025-01-22 21:07:57 <vkrishn> so that, if you don't have internet you cannot build
2025-01-22 21:09:24 <vkrishn> how much money does it take to design all is f'ups, give that 10% to needy ones and see how world improves
2025-01-22 21:10:28 <vkrishn> i have nothing against any of these languages or life around it
2025-01-22 21:10:43 <psykose> nothing against them except posting essays about how much you hate them on irc, of course
2025-01-22 21:11:29 <vkrishn> how i hate them, if i am saying i would want alpine-go
2025-01-22 21:11:47 <vkrishn> so how do i build "glab"
2025-01-22 21:12:09 <vkrishn> without internet, after populating my distfiles
2025-01-22 21:12:18 <psykose> you don't
2025-01-22 21:12:41 <vkrishn> so now you are against it ;)
2025-01-22 21:13:14 <psykose> no, i am the happy owner of an internet connection that is capable of making http requests
2025-01-22 21:13:43 <quinq> When you're happy, why caring about the distress of others
2025-01-22 21:14:08 <vkrishn> no idea what that means, i would like my good old alpine methods of ABUILDs back
2025-01-22 21:15:15 <vkrishn> again if all this gets food to your table, do it over and over again, no problem
2025-01-22 21:18:13 <vkrishn> in fact i also want alpine-rust and rust(pure) kernel too
2025-01-22 21:18:34 <vkrishn> i am sure that's where now all money is flowing
2025-01-22 21:24:12 <vkrishn> one thing is quite clear, moment a project become famous,stable, not only i want all fruits from it, 
2025-01-22 21:24:27 <vkrishn> i want to cut the tree too
2025-01-22 21:24:51 <vkrishn> and replant in my corp office
2025-01-22 21:27:16 <vkrishn> seems so now i cannot build glab with some new features, i am not allowed :)
2025-01-22 21:31:43 <vkrishn> ok, figured it out, will upload aports there, then say 'abuild -r community/glab', the even run it there , thanks
2025-01-22 21:33:49 <quinq> good luck!
2025-01-22 21:34:31 <vkrishn> :)
2025-01-22 21:38:13 <vkrishn> nothing to do for now, i want to pluck apple from orange tree
2025-01-22 23:22:46 <vkrishn> fine added :), #16863
2025-01-23 02:14:22 <pj> what is even that issue
2025-01-23 02:21:11 <vkrishn> mine one ?
2025-01-23 02:28:26 <pj> ikke: how should abuild behave in terms of net+rootbld combo? I would like to see the situation fixed for rootbld (even if just for my own usecase) so I was thinking to make "net" option a default or prepare phase gets net access always (and then remove it for later stages)
2025-01-23 04:30:48 <qaqland> pj: but net option can only be enabled for the entrie build or disabled
2025-01-23 05:15:56 <ikke> Making 'net' default kind of defeats the purpose of removing network access during build
2025-01-23 05:16:48 <ikke> Right now, with rootbuild, network access is kept until after the fetch stage
2025-01-23 05:31:23 <pj> since when?
2025-01-23 05:32:54 <pj> wait, "until after fetch", so just till fetch and no further?
2025-01-23 05:35:28 <ikke> yes
2025-01-23 05:35:43 <ikke> (unless you provide the 'net' option
2025-01-23 05:35:45 <ikke> )
2025-01-23 05:36:27 <ikke> The idea is (with traditional builds) is that after fetching sources, no network access should be needed anymore
2025-01-23 05:36:36 <pj> I'm aware
2025-01-23 05:37:30 <ikke> Oh, verify is also being done outside of the rootbld chroot
2025-01-23 05:37:45 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2540-2544
2025-01-23 05:38:15 <pj> the problem is when trying to fetch after unpack
2025-01-23 05:38:21 <ikke> yup
2025-01-23 05:38:28 <ikke> for things like rust and go
2025-01-23 05:38:31 <pj> yes
2025-01-23 05:38:49 <pj> which I would like to solve without mass sed'ing aports to enable 'net'
2025-01-23 05:39:44 <pj> could unpack be just a sub of fetch?
2025-01-23 05:40:02 <ikke> unpack can be overriden
2025-01-23 05:40:17 <ikke> The problem is that prepare should be done in the chroot
2025-01-23 05:40:35 <ikke> And either the entire chroot has net access or it hasn't
2025-01-23 05:40:38 <pj> I know all can be overriden
2025-01-23 05:40:45 <pj> I'm suggesting that unpack runs in fetch
2025-01-23 05:41:15 <pj> although I guess running go/rust package managers without chroot is not acceptable?
2025-01-23 05:41:50 <ikke> There is a desire to completely switch to rootbld for everything
2025-01-23 05:42:17 <pj> ikke: for that my idea was to bwrap with net until prepare and then exit, then spawn next bwrap with build
2025-01-23 05:42:28 <pj> ikke: yes, https://gitlab.alpinelinux.org/alpine/tsc/-/issues/33
2025-01-23 05:42:46 <ikke> pj: fyi, it's unpack that indirectly calls fetch
2025-01-23 05:42:58 <ikke> unpack -> verify -> sumcheck -> fetch
2025-01-23 05:45:06 <ikke> I guess that could make sense to do it in 2 phases
2025-01-23 05:45:26 <pj> the cog is spinning but can't think of a clean way to do it
2025-01-23 05:46:16 <ikke> I also need to think of how to do it in CI. Using rootbld (bwrap) does not make a lot of sense there and requires disabling some safeties in docker
2025-01-23 05:46:27 <pj> the other other option would be to stuff all deps into APKBUILD which kinda sucks
2025-01-23 05:46:56 <ikke> I don't think we have the capability to manage that
2025-01-23 05:47:16 <pj> we don't, that would have to be added to abuild
2025-01-23 05:47:42 <ikke> I mean the amount of work involved
2025-01-23 05:48:00 <ikke> To manage all deps 
2025-01-23 05:48:41 <pj> how so? would just need a helper script like rust2apk
2025-01-23 05:49:23 <pj> surely it looks ugly and verbose but I don't think it's much work apart from making abuild understand that
2025-01-23 05:49:24 <ikke> and keeping them up-to-date, and dealing with different versions of deps required
2025-01-23 05:49:54 <ikke> Never heard of rust2apk, cannot find a reference
2025-01-23 05:49:56 <pj> no, not keeping them up to date
2025-01-23 05:50:32 <pj> I'm not suggesting to start handling all dependencies as packages, just to put them in fetch/checksum
2025-01-23 05:51:05 <pj> rust2apk is just an example, based on stuff like rust2rpm
2025-01-23 05:51:19 <pj> https://pagure.io/fedora-rust/rust2rpm
2025-01-23 05:51:29 <ikke> ah ok
2025-01-23 05:51:57 <pj> macports also had some helper script for making rust ports and hashlocking deps
2025-01-23 05:52:03 <pj> don't remember the name currently
2025-01-23 05:52:56 <pj> but generally the idea would be that you point it at lockfile (or maybe even just tell the crate name/git repo) and it looks at that and makes APKBUILD for you
2025-01-23 05:53:40 <pj> would need a little bit of magic written in the script to update such ports but doable? me thinks
2025-01-23 05:54:00 <pj> gotta go buy breakfast, be back in ~20 minutes
2025-01-23 05:54:05 <ikke> Where would it put those deps? after fetching?
2025-01-23 05:54:41 <pj> srcdir? builddir?
2025-01-23 05:54:55 <pj> maybe could figure out caching
2025-01-23 05:55:06 <ikke> does cargo find them there?
2025-01-23 05:55:49 <pj> prepare or unpack/fetch could just put it in a place where cargo will find it
2025-01-23 05:56:17 <pj> although, for cargo specifically we would need to generate cargo.toml that replaces crates with local copies
2025-01-23 05:56:22 <pj> just like cargo vendor does
2025-01-23 05:56:25 <Arnavion> If you use the builtin `cargo vendor` functionality it's the first-party way of putting all deps under a path of your choice
2025-01-23 05:57:10 <ikke> Yes, but we would have to replicate that if we would fetch the crates and put them somewhere
2025-01-23 05:57:13 <pj> I know, but that would require cargo and would make no sense putting deps into fetch/checksums
2025-01-23 05:57:55 <pj> ikke: correct
2025-01-23 05:58:41 <ikke> similar with go
2025-01-23 06:03:13 <pj-> i believe go will just look for vendor dir and deal with it
2025-01-23 06:42:37 <Asmadeus> Would someone have time to look at !77498 ? It's a really niche problem so I can understand nobody wants to spend time on it, but it's be great to close this topic so I can communicate on an upgrade path one way or another.
2025-01-23 08:57:18 <chereskata> Hi there, been working again on !71840, hope the pipeline passes this time ... 
2025-01-23 08:57:29 <chereskata> could someone remove the status:mr-stale please :)
2025-01-23 08:59:40 <chereskata> thanks!
2025-01-23 09:48:18 <vkrishn> just separate the go aports, and let it get shaped from there, if buying alpine-go domain is expensive, then use go.a.o
2025-01-23 09:51:36 <vkrishn> it will bloat aports if try to solve in it
2025-01-23 09:54:38 <vkrishn> one solution is add go.sum to aports, then prefetch it, and apply patch, but then will 'go' be able to use the downloads
2025-01-23 09:55:47 <pj> what are you on about
2025-01-23 09:56:38 <pj> can you like stop with weird dumb "ideas" and complaining on irc
2025-01-23 10:02:22 <fabricionaweb> https://i.imgur.com/c7819Np.jpeg
2025-01-23 10:02:23 <fabricionaweb> !77555
2025-01-23 10:02:26 <vkrishn> its an idea, but how a complain? #16863
2025-01-23 10:03:07 <pj-> you keep bringing up buying a domain and having separate aports
2025-01-23 10:03:09 <pj-> what for
2025-01-23 10:03:53 <vkrishn> #16863 mentioned that too
2025-01-23 10:04:31 <pj-> that's your issue
2025-01-23 10:04:31 <vkrishn> awake whole night?
2025-01-23 10:05:05 <pj-> ?
2025-01-23 10:06:09 <vkrishn> yes, didn't you just discussed it with ikke
2025-01-23 10:06:58 <pj-> I've been discussing using rootbld to build go/cargo packages which require net option
2025-01-23 10:07:22 <vkrishn> yes, its related
2025-01-23 10:07:24 <pj-> Which slightly related to maybe trying fetch go/rust deps within APKBUILD
2025-01-23 10:07:51 <fabricionaweb> there is timezone so maybe your night is not pj' night
2025-01-23 10:08:37 <vkrishn> ^"The idea is (with traditional builds) is that after fetching sources, no network access should be needed anymore"
2025-01-23 10:08:54 <vkrishn> quite related
2025-01-23 10:09:42 <pj-> I only care about rootbld being able to build go/rust
2025-01-23 10:10:37 <vkrishn> and i want to build glab with some patches to one of inner mentioned downloads in go.sum
2025-01-23 10:10:39 <vkrishn> help pls
2025-01-23 10:11:13 <pj-> what patches
2025-01-23 10:11:47 <pj-> like what exactly are you trying to patch and why
2025-01-23 10:12:16 <pj-> for go.{sum,mod} it can be easily done in prepare or even sed'ed in APKBUILD
2025-01-23 10:12:44 <fabricionaweb> Im looking to your issue (and some others as well) I think the way you speak is confusing vkrishn, sorry but I didnt get what is the problem you are trying to solve
2025-01-23 10:12:46 <pj-> one might also just echo >> into go.mod + go mod tidy
2025-01-23 10:13:49 <pj-> I kind of understand certain points but going with "yeah just remove all the go stuff, go buy domain and do additional work because I want to" is not the argument you should ever try
2025-01-23 10:14:24 <vkrishn> ok, help here, so what is go.sum, dependency source code or blobs ?
2025-01-23 10:14:52 <pj-> it's a plaintext file that contains list of hashes of dependencies
2025-01-23 10:15:03 <pj-> commonly known as "lockfile"
2025-01-23 10:15:43 <pj-> akin to Cargo.lock or package-lock.json from npm
2025-01-23 10:16:21 <vkrishn> can i patch any of the codes in that dependencies in APKBUILD?
2025-01-23 10:17:00 <pj-> yes, if there is a need to fix something in package
2025-01-23 10:17:39 <vkrishn> how, is there an existing APKBUILD doing this, i can learn from it
2025-01-23 10:18:34 <pj-> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/apptainer/update-container-storage.patch
2025-01-23 10:18:55 <fabricionaweb> you can patch a program release, if is correct reproducible it should always work until next release that you may need to update the patches (mod and sum for example), it can be annoying but you shouldnt need a patch either, so one work to be done between releases is reasonable to me
2025-01-23 10:20:18 <vkrishn> yes, that is ok, all new release of any pkg needs to rechecked for its build in APKBUILD
2025-01-23 10:21:58 <vkrishn> can i download all the deps(anywhere) and rebuild with patch changes (if something went wrong)
2025-01-23 10:22:09 <vkrishn> or now need to re-download it?
2025-01-23 10:24:18 <pj-> abuild fetch when have internet
2025-01-23 10:24:24 <pj-> abuild prepare when no have internet
2025-01-23 10:26:24 <vkrishn> where do i store all the pkgs mentioned in go.sum for future re-builds?
2025-01-23 10:26:44 <pj-> they are stored in srcdir by default
2025-01-23 10:27:37 <pj-> you can set GO{CACHE,MODCACHE,TMPDIR} to change that
2025-01-23 10:27:38 <vkrishn> $srcdir=/var/cache/distfiles/
2025-01-23 10:27:48 <vkrishn> ?
2025-01-23 10:27:56 <pj-> that will break everything
2025-01-23 10:28:21 <pj-> maybe not, but I wouldn't do that
2025-01-23 10:28:28 <vkrishn> so how to permanentaly store pkgs mentioned in go.sum?
2025-01-23 10:28:41 <pj-> I justaid, GOCACHE, GOMODCACHE
2025-01-23 10:29:02 <vkrishn> ok, will try now, thanks
2025-01-23 10:29:43 <pj-> oh actually it's $tmpdir, not $srcdir but still, the envs change it
2025-01-23 10:29:57 <pj-> default is GOCACHE=$tmpdir/go and GOMODCACHE=$tmpdir/gomod
2025-01-23 10:30:10 <pj-> and GOTMPDIR=$tmpdir
2025-01-23 10:30:21 <vkrishn> can there be an example in aports, its best way to learn
2025-01-23 10:32:19 <pj-> set it in abuild.conf
2025-01-23 10:33:10 <vkrishn> meaning, custom settings?
2025-01-23 10:33:30 <pj-> yes?
2025-01-23 10:33:50 <pj-> etc/abuild.conf or ~/.abuild/abuild.conf
2025-01-23 10:34:28 <vkrishn> ok, will try
2025-01-23 10:35:33 <vkrishn> thanks
2025-01-23 10:39:09 <vkrishn> can there be commented lines in default /etc/abuild.conf for help on GO related variables pls?
2025-01-23 10:41:39 <vkrishn> fabricionaweb: making sense now :)
2025-01-23 10:43:14 <vkrishn> unless you have never build go pkgs, like me
2025-01-23 10:46:00 <vkrishn> now searching for GOCACHE, GOMODCACHE variables in wiki.a.o
2025-01-23 10:46:06 <vkrishn> nothing
2025-01-23 10:46:55 <pj-> generally you would search for that in go documentation
2025-01-23 10:47:57 <vkrishn> yes, didn't i say how to do in alpinelinux(APKBUILD, abuild.conf)
2025-01-23 10:48:28 <pj-> it's still go compiler though
2025-01-23 10:48:47 <vkrishn> have no idea , where this is going ;)
2025-01-23 10:59:53 <vkrishn> found some more, https://alogs.koi.moe/search?key=GOCACHE&channel=&after=&before= , i think it should solve
2025-01-23 11:09:52 <vkrishn> and here, https://lists.alpinelinux.org/~alpine/devel/%3CCAD+eXGQmWT+2ASHj+423TyosrHFRF974ogY+SqSCxYP99JQrdA%40mail.gmail.com%3E
2025-01-23 11:11:16 <fabricionaweb> I believe those env variables is more useful for the pipeline builders, but doesnt feel that important, I mean the names are very meaningful, I'd not be stuck on that
2025-01-23 11:11:17 <fabricionaweb> https://pkg.go.dev/cmd/go#hdr-Build_and_test_caching
2025-01-23 11:24:00 <vkrishn> now, lets see if i can patch one of the deps, and rebuild 2nd time, without internet
2025-01-23 11:25:13 <pj-> btw. if you replace the dependency in go.{mod,sum} then no
2025-01-23 11:25:24 <pj-> unless you have it locally
2025-01-23 11:27:07 <vkrishn> now you are just confusing me, why would i change go.{mod,sum}
2025-01-23 11:27:57 <fabricionaweb> lol ahhahah was not your objetive since the beginning to patch it
2025-01-23 11:28:12 <vkrishn> just patch one of the dep file mentioned in go.mod
2025-01-23 11:28:36 <vkrishn> after download
2025-01-23 11:28:39 <vkrishn> lol
2025-01-23 11:56:22 <chereskata> after some poking i got all poppler dependencies to compile
2025-01-23 11:56:33 <chereskata> last pipelines are running (i think they should succeed)
2025-01-23 11:56:46 <chereskata> could someone set this to automerge, please? !71840
2025-01-23 11:56:59 <chereskata> because it is a pita to rebase
2025-01-23 11:57:12 <chereskata> and the pipeline takes forever
2025-01-23 12:03:18 <vkrishn> some solutions, https://alogs.koi.moe/search?key=GOMODCACHE&channel=&after=&before= 
2025-01-23 12:14:57 <chereskata> IDENTIFY [sv7&6WGznV`Xmts|XghcBRa.'BT~;!kvdc3!UcW
2025-01-23 12:15:23 <q66> you should change your password now :P
2025-01-23 12:19:20 <z5rRZdiu1UE> at least it is not the famous eicar string ;)
2025-01-23 12:19:55 <chereskata> yes
2025-01-23 12:19:58 <chereskata> already done
2025-01-23 12:20:28 <chereskata> 😑🔫
2025-01-23 12:21:15 <chereskata> I think Polari should introduce some kind of warning if the User / Group is not NickServ
2025-01-23 12:21:54 <chereskata> Opsec = 0 😇
2025-01-23 12:52:42 <fabricionaweb> IDENTIFY z5rRZdiu1UE
2025-01-23 12:52:53 <fabricionaweb> that user looks like a password
2025-01-23 12:53:02 <Ermine> oof
2025-01-23 12:53:44 <ikke> Some people generate random usernames
2025-01-23 13:42:03 <chereskata> actually this increases entropy somewhat
2025-01-23 13:42:17 <chereskata> or at least keeps logs cleaner
2025-01-23 13:49:20 <chereskata> I think this is ready to merge !71840
2025-01-23 15:27:25 <ikke> chereskata: I'm checking it in the background
2025-01-23 15:35:08 <WhyNotHugo> Can we merge this one please? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77155
2025-01-23 15:36:28 <ikke> !77155
2025-01-23 21:19:12 <pj> ikke clandmeter: could someone step in #alpine-linux 
2025-01-23 21:20:49 <pj> with a little bit of moderation
2025-01-23 21:23:09 <fabricionaweb> Thanks pj
2025-01-23 21:26:19 <pj-> was debating internally if I should do something about it but I'd rather not be the judge and also sleep is looking really comfy right now :]
2025-01-23 21:36:48 <invoked> a mild warning followed by an immediate quiet if they don't abide, is what i'd do
2025-01-23 21:37:51 <invoked> but they left on their own accord, for now
2025-01-23 22:01:23 <socksinspace> god, that person again
2025-01-24 05:46:18 <Saijin_Naib[m]> fossddHere I am making an iotas aport to find you already have it in testing
2025-01-24 05:46:19 <Saijin_Naib[m]> Thanks!
2025-01-24 05:48:38 <Saijin_Naib[m]> I will say my aport is a bit different, with different depends/makedepends which I found I needed for file export and markdown view
2025-01-24 05:50:10 <Saijin_Naib[m]> That is to say, on a semi-minimal XFCE install, your aport crashes a lot
2025-01-24 05:54:23 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/issues/16865
2025-01-24 10:01:42 <fabricionaweb> Hi, could someone check my MR !77555
2025-01-24 10:12:52 <vkrishn> fabricionaweb: i am also new to go pkgs, but was pointed to https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L706
2025-01-24 10:16:11 <ikke> vkrishn: you could comment that on the MR itself 🙂
2025-01-24 10:18:57 <vkrishn> ok :)
2025-01-24 10:29:11 <fabricionaweb> thanks vkrishn, does it mean I can safe remove the variables as it gets in by default? I havent noted other aports removing it yet
2025-01-24 10:31:35 <vkrishn> don't know, wait for some experienced go dev to answer that, would rather look into other APKBUILDs examples
2025-01-24 10:32:12 <pj> i thought the go stuff has been resolved long time ago but I guess no one cleaned up aports
2025-01-24 10:32:20 <ikke> fabricionaweb: yes, but there has not been an effort to mass remove it
2025-01-24 10:34:58 <fabricionaweb> ptrc was involved (I think) !d27b635768c93704087ca7cbb9074d6619eaf848 
2025-01-24 10:35:10 <fabricionaweb> oops https://gitlab.alpinelinux.org/alpine/abuild/-/commit/d27b635768c93704087ca7cbb9074d6619eaf848
2025-01-24 10:35:35 <pj> correct
2025-01-24 10:36:28 <pj> IMO, aports should've been mass cleaned in a single commit without relbump and just deal with eventual failures if something happens
2025-01-24 10:36:37 <pj> I mean this not just for the go stuff
2025-01-24 10:37:11 <pj> stuff like CFLAGS, Rust envs, Go envs, etc.
2025-01-24 10:38:35 <pj> current situation makes it so that people copy whatever APKBUILD and are unaware of why and it's on the reviewer to remember that detail
2025-01-24 10:47:01 <fabricionaweb> thanks pj, we could do that if is consensual
2025-01-24 10:47:13 <fabricionaweb> and thank you again vkrishn, I wasnt aware of those coming from abuild and I kept copy/pasta it :P I will keep that in mind
2025-01-24 10:47:58 <pj> the decision is up to alpine devs
2025-01-24 10:49:09 <pj> I'm still waiting for a response regarding CFLAGS (unfortunately ncopa seems to be quite busy recently)
2025-01-24 15:24:58 <ncopa> hi
2025-01-24 15:25:14 <ncopa> i have been busy with fever sorry
2025-01-24 15:25:32 <ncopa> but im better now
2025-01-24 15:28:34 <ncopa> pj: can you give me the URL and I'll have a look
2025-01-24 15:30:06 <pj> !78137
2025-01-24 15:31:23 <pj> question is if it would be accepted, and eventual details like ${var/sub/str} vs ${var//sub/str}
2025-01-24 15:33:14 <pj> (also you shouldn't apologise, nothing was your fault [and I was patiently waiting])
2025-01-24 15:35:49 <pj> also if I can just remove CPPFLAGS completely (with exception of ports that actually define those, e.g. chromium), mainly because it's useless envvar that gets thrown into cc anyway
2025-01-24 15:36:45 <pj> often it repeats CFLAGS/CXXFLAGS and while duplicate flags are not an issue to cc it makes output more unreadable with flag spam
2025-01-24 15:38:53 <pj> also don't review whole MR, it's not complete and it's the same thing done for each aport that reexports C*FLAGS
2025-01-24 15:39:59 <ncopa> ok. I usually dont look at draft MRs unless asked to, as they are usually work in progress
2025-01-24 15:41:08 <ncopa> it would be accepted if it brings more value than it costs
2025-01-24 15:41:40 <pj> how would value be defined
2025-01-24 15:41:58 <ncopa> but right now I don't really see the value, and its not explained in commit message
2025-01-24 15:42:52 <ncopa> value could be better flexibility (do we need it?), less noisy logs etc
2025-01-24 15:43:32 <ncopa> the cost is the risk for breakages or unexpected consequences
2025-01-24 15:43:37 <pj> value for me is that I can change the default C*FLAGS optimisations and I don't end up with hardcoded values from certain ports
2025-01-24 15:44:27 <ncopa> that is a good reason imho, please write that in commit message
2025-01-24 15:45:01 <pj> there is no risk, abuild already defines -Os by default, changing -O2 into ${CFLAGS/-Os/-O2} should result in same thing just without -Os
2025-01-24 15:45:26 <pj> sorry for not writing it down already, I was msotly tinkering and talking about it on IRC
2025-01-24 15:46:36 <ncopa> what about if you dont specify -Os in your global CFLAGS? then you won't get them replaced
2025-01-24 15:46:53 <pj> that's true
2025-01-24 15:47:00 <ncopa> there were also some -O3 that got replaced to -O2? I dont know how much difference it makes
2025-01-24 15:47:13 <pj> that was just my mistake
2025-01-24 15:47:44 <pj> as mentioned earlier, don't review whole MR, just trying to get opinion on whole idea
2025-01-24 15:47:48 <pj> before I fully commit
2025-01-24 15:47:52 <ncopa> another thing that I don't like is that the ${var/search/replace} is non posix
2025-01-24 15:48:11 <pj> we use /bin/ash in abuild, I don't see any issue with that
2025-01-24 15:49:01 <ncopa> i suppose we won't change to posix shell either anytime soon
2025-01-24 15:49:17 <pj> also, I'm not introducing anything new
2025-01-24 15:49:26 <pj> (with exception for removing CPPFLAGS that I'm suggesting)
2025-01-24 15:49:30 <pj> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/R/APKBUILD#L51
2025-01-24 15:49:42 <pj> there's ton of ${var/search/replace} in aports already
2025-01-24 15:49:47 <ncopa> yeah
2025-01-24 15:50:00 <pj> https://gitlab.alpinelinux.org/search?group_id=2&project_id=1&scope=blobs&search=%24%7BCFLAGS%2F-Os%2F-O2%7D
2025-01-24 15:50:16 <ncopa> i was just thinking that might be good to not add even more, but I suppose that does not matter
2025-01-24 15:50:50 <pj> well, if you think it's better to not then I won't push for that
2025-01-24 15:51:06 <pj> and could just cleanup other ports to be more-posix
2025-01-24 15:51:17 <ncopa> nah
2025-01-24 15:51:24 <ncopa> I think it is generally good thing
2025-01-24 15:51:49 <ncopa> i dont "like" we are move away from posix, but nothing we can do I suppose
2025-01-24 15:52:18 <pj> I'm unsure if even abuild can run in posix shell
2025-01-24 15:52:20 <ncopa> other option would be to introduce some helper functions
2025-01-24 15:52:25 <pj> like the functions and core
2025-01-24 15:52:37 <ncopa> yeah, forget the posix thing, was just a brain fart from my side
2025-01-24 15:53:09 <ncopa> removing the CPPFLAGS is probably also a good idea
2025-01-24 15:53:49 <ncopa> I think I added the CPPFLAGS in the beginning due to gentoo did it
2025-01-24 15:54:11 <ncopa> probably due to some misbehaving software that didn't respect CFLAGS
2025-01-24 15:54:34 <ncopa> another option would be to add helper functions
2025-01-24 15:54:39 <pj> well, CPPFLAGS were not supposed to be CFLAGS and are not CXXFLAGS
2025-01-24 15:54:54 <ncopa> to add/remove/replace flags
2025-01-24 15:55:35 <ncopa> but I prefer keep it obvious what goes on, so I prefer the ${var/search/replace}
2025-01-24 15:55:39 <pj> what would that look like for example?
2025-01-24 15:55:45 <ncopa> need to have lunch now. bbl
2025-01-24 15:55:50 <pj> oki
2025-01-24 16:07:25 <ikke> ncopa: nice you're better again
2025-01-24 16:23:45 <ncopa> pj: I think your approach is better
2025-01-24 16:24:07 <ncopa> other question is why are there so many of the hardcoded -O2
2025-01-24 16:24:19 <ikke> moar performance!
2025-01-24 16:24:34 <pj> quite often it's used encryption or compression software
2025-01-24 16:24:40 <pj> or compilers/JITs
2025-01-24 16:25:06 <ncopa> like py3 fonttools
2025-01-24 16:25:31 <pj> that's to say, it did spread into other aports that certainly dont need it
2025-01-24 16:25:44 <pj> :]
2025-01-24 16:26:14 <ncopa> I mean, for zlib and xz, and musl it makes sense
2025-01-24 16:26:58 <pj> I would be for removing flags from them and if needed they should have a comment on top why it uses those flags
2025-01-24 16:29:55 <ncopa> yeah
2025-01-24 16:30:37 <ncopa> maybe even with numbers showing how much difference it makes
2025-01-24 16:31:34 <ncopa> pj: im ok with the general approach of https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78137
2025-01-24 16:31:56 <ncopa> write a good commie message why this change is needed
2025-01-24 16:32:34 <pj> btw. there was an issue related to opt flags
2025-01-24 16:32:35 <pj> https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10057
2025-01-24 16:32:36 <ncopa> and verify that there are no more -O3 to -O2 and similar
2025-01-24 16:33:00 <pj> the idea was to introduce performance profiles in ports
2025-01-24 16:35:10 <Habbie> ncopa, so not "dead to the proletariat", which would be a bad commie message
2025-01-24 16:36:44 <ncopa> heh
2025-01-24 16:37:24 <ncopa> that #10057 has a comment with good points
2025-01-24 16:37:46 <ncopa> abuild#10057
2025-01-24 16:38:07 <ncopa> I mean https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10057
2025-01-24 16:38:35 <ncopa> the point that cpu caches are bigger now than they were 20 years ago. would be nice with some numbers
2025-01-24 16:38:50 <ncopa> and maybe we should switch to -O2
2025-01-24 16:39:13 <orbea> ncopa: even slackware defaults to -O2
2025-01-24 16:39:54 <pj> I wonder if keeping -Os for x86 / armv6/7 would still make sense
2025-01-24 16:40:13 <pj> those tend to be not so powerful but also low storage devices
2025-01-24 16:40:44 <ncopa> orbea: I am perfectly aware that most distros prioritise performance over size
2025-01-24 16:41:13 <orbea> i dont think that is the reasoning in slackware, its that -O2 is a very well tested default that works almost everywhere
2025-01-24 16:41:24 <ncopa> in any case, nothing will happen without some real numbers
2025-01-24 16:41:37 <pj> -Os is -O2 without opts that increase bin size
2025-01-24 16:42:03 <pj> but yes, numbers would be nice
2025-01-24 16:42:45 <ncopa> and right now -0s works good enough for alpine
2025-01-24 16:43:02 <orbea> "if it works don't fix it"
2025-01-24 16:43:03 <ncopa> we have always been willing to trade some performance for size
2025-01-24 16:43:18 <ncopa> i dont mind improving things
2025-01-24 16:43:39 <ncopa> but I dont want "fix it" if the fix does not really fix anything
2025-01-24 16:44:15 <pj> with my MR, I might be able to provide stats diff between -Os/-O2 of aports for x86_64
2025-01-24 16:44:35 <pj> but I can't do that for any other arch and profiling runtime performance is also just impossible at this scale
2025-01-24 16:45:07 <ncopa> pj clean it it up and I'll merge it for you
2025-01-24 16:45:23 <pj> it will take me a bit of time, no rush
2025-01-24 16:45:39 <pj> I have to personally triple check each port after fixing
2025-01-24 16:46:27 <ncopa> check or double check would be good enough for me
2025-01-24 16:46:36 <ncopa> and thanks!
2025-01-24 16:47:40 <pj> I usually let my MRs/PRs in projects marinate for weeks as drafts and review them every few days, I've always been able to catch more things to fix when doing that :P
2025-01-24 19:04:16 <Saijin_Naib[m]> @fossdd thanks for the fixup on iotas! I will have errands done today, if you also use it with NC and want to test
2025-01-24 21:17:44 <ikke> For some reason, che-bld-1 cannot connect to guce.yahoo.com via ssl
2025-01-24 21:17:59 <ikke> or perhaps, at all
2025-01-24 21:18:16 <ikke> ticker has a test that tries to connect to it
2025-01-24 21:43:26 <vkrishn> cannot find any new info about current pcre2 main developer(nickolas) (his web-pages are like from 2011), seems microsoft was funding it, now cannot figure out
2025-01-24 21:44:19 <vkrishn> suggestions is to see if the test it has and runs during build is sane
2025-01-24 21:54:21 <vkrishn> last month main dev add "github's dependabot" to it
2025-01-24 21:54:27 <vkrishn> added^
2025-01-25 11:01:01 <lucbijl> Greetings, what is the typical respone time on a merge-request in aports? I am waiting for quite some weeks now, it would be very appreciated if someone of the aports team has a look at it (!77478). 
2025-01-25 11:10:07 <quinq> lucbijl, I guess that's kind of a per-maintainer average
2025-01-25 11:10:15 <quinq> And per “popularity” port
2025-01-25 11:10:49 <quinq> It also depends on the time of the year
2025-01-25 11:16:17 <quinq> lucbijl, found an intruder in your POSIX though ;)
2025-01-25 11:19:52 <lucbijl> o, that is not optimal.
2025-01-25 11:32:51 <quinq> Nice idea though
2025-01-25 11:38:43 <lucbijl> Thanks, what particular intruders did you notice? 
2025-01-25 11:45:52 <quinq> mktemp ;)
2025-01-25 11:57:10 <lucbijl> a, yes, I was already (partially) aware of the implications of that construct, but thanks for emphasizing it again. Though, reading tmpdir in initramfs is not particularly viable, right? (when proper kernel settings are set). 
2025-01-25 12:03:28 <quinq> I haven't analyzed the script itself, though the idiomatic way is making use of $$
2025-01-25 12:19:38 <lucbijl> I think I will keep the merge-request open, as the construct will not directly impose security risks though I will certainly start rewriting the scripts (in the idiomatic way) for the next release. Thanks for the advice!
2025-01-25 12:35:46 <quinq> lucbijl, note that this has nothing to do with getting your port merged though :)
2025-01-25 20:40:56 <ptrc> hm, we don't have any policy on contributors just adding their own personal projects to testing/, do we?
2025-01-25 20:41:32 <ikke> like zlevis?
2025-01-25 20:43:11 <ptrc> that was the package which made me wonder, yes
2025-01-25 20:43:46 <ikke> There's no policy as far as I know
2025-01-25 23:47:21 <z3ntu> ping on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78847 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78848 (and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78938 but that's a bit newer)
2025-01-26 00:08:30 <ptrc> pong :3
2025-01-26 00:52:19 <DavidHeidelberg> Can I join the party w/ Luanti / Minetest bump?
2025-01-26 01:55:44 <ptrc> oh, right! i was gonna get around to reviewing it.. at some point ;;
2025-01-26 02:38:39 <Thomas[m]1> From Trusted and Vouched Dealers... (full message at <https://matrix.org/oftc/media/v1/media/download/ATI-N7poeMjygr9imvbzaxoAUTGmRWmjVDefFVR3qq-W4UyOXnTs1o5CvoUvAkyZZXRD6m7zOPH6QM3UDayA5I5CeU6JK_WAAG1hdHJpeC5vcmcvTHV3Y3NyVXROaXF4eWNpbUNjWGFXeVpI>)
2025-01-26 05:13:39 <Saijin_Naib[m]> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79020
2025-01-26 05:13:50 <Saijin_Naib[m]> fossdd, if you wish to try out packaged Errands/Tasks for NC
2025-01-26 05:14:30 <Saijin_Naib[m]> If I am having trouble with the build of thunar-shares-plugin, best to ask here first, or XFCE-DEV? Specifically, the build process can't find thunarx, which I packaged earlier for another aport I added
2025-01-26 05:44:57 <pj> (banned Thomas[m]1 because scam links, ping me if they join other channels)
2025-01-26 05:50:34 <Saijin_Naib[m]> Anyone able to help me fixup my aport of xsnow?
2025-01-26 05:51:07 <Saijin_Naib[m]> The application binary goes to /usr/games so it isn't on path. NFI how to redirect it, and my email to the author goes unanswered
2025-01-26 06:11:58 <vkrishn> maybe create symlink in /usr/bin for it
2025-01-26 06:12:27 <Saijin_Naib[m]> is that good practice?
2025-01-26 06:13:27 <vkrishn> creating symlink in allowed path, i guess
2025-01-26 06:14:02 <vkrishn> there is no harm to MR it and see response on it
2025-01-26 06:16:50 <pj> you could just move it to /usr/bin
2025-01-26 06:21:55 <Saijin_Naib[m]> Hmm, okay. I'll need to find other examples and see
2025-01-26 06:22:14 <Saijin_Naib[m]> Also, anyone know how to enable abuild to use ccache/sccache? I can not remember how I did it last time I set this computer up
2025-01-26 06:22:20 <Saijin_Naib[m]> Search is failing me
2025-01-26 06:26:17 <vkrishn> grep ccache main/*/APKBUILD
2025-01-26 06:27:17 <vkrishn> oh, abuild.conf, nope
2025-01-26 06:30:01 <ikke> USE_CCACHE=1
2025-01-26 06:31:00 <Saijin_Naib[m]> haha, thank you
2025-01-26 06:36:30 <Saijin_Naib[m]> Is there a way to like... audit what arches the packages we specify in depends/makedepends/checkdepends are, so we can more easily/accurately set the arch field?
2025-01-26 06:36:42 <Saijin_Naib[m]> Right now I kinda throw it at the CI and see what sticks, which is not ideal
2025-01-26 06:37:05 <Saijin_Naib[m]> Or go item by item using pkgs.alpinelinux.org, which gets lengthy
2025-01-26 06:51:34 <vkrishn> you mean, what to goes in arch="" field?
2025-01-26 06:53:02 <vkrishn> i would see orig source sites, their home page generally say it build in....
2025-01-26 06:53:27 <vkrishn> or look into debian/ubuntu if it builds
2025-01-26 06:54:14 <vkrishn> then only thing left would be, does it build with musl
2025-01-26 06:57:30 <Saijin_Naib[m]> Yeah, I was hoping for something less laborious and error-prone, sort of like how we can run apkbuild-lint and have it linted for issues
2025-01-26 06:57:32 <Saijin_Naib[m]> Something like that
2025-01-26 06:57:45 <Saijin_Naib[m]> apkbuild-checkarch haha
2025-01-26 06:58:00 <vkrishn> if its small a pkg or you have a beefy system, would spin a vm and see
2025-01-26 06:58:20 <vkrishn> oh, you found it
2025-01-26 07:19:59 <vkrishn> didn't know there was a magic wand
2025-01-26 07:28:52 <Saijin_Naib[m]> There isn't, that is just what I think a reasonable name for such would be
2025-01-26 08:13:28 <quinq> The arch field is a bit weird, it should rather be a list of arch where the package is broken
2025-01-26 08:17:51 <ikke> arch="all !broken1 !broken2"
2025-01-26 08:18:04 <ikke> There are packages that only support specific arches
2025-01-26 08:18:12 <ikke> then it's arch="specific1 specific2"
2025-01-26 08:18:18 <quinq> Ah, that's nice then indeed
2025-01-26 08:18:21 <quinq> It's undocumented though :/
2025-01-26 08:20:14 <Asmadeus> https://wiki.alpinelinux.org/wiki/APKBUILD_Reference ?
2025-01-26 08:21:52 <quinq> Talking about the man-page
2025-01-26 08:32:26 <quinq> ikke, https://clbin.com/pPZlP
2025-01-26 08:35:09 <Asmadeus> quinq: here you go, https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/358
2025-01-26 08:37:00 <vkrishn> ok, i think Saijin_Naib[m] meant if its possible to detect the arch=<string> based on depends/makedepends/checkdepends, right?
2025-01-26 08:37:26 <vkrishn> before building anything
2025-01-26 08:38:22 <vkrishn> or lint its build feasiblity
2025-01-26 08:39:29 <quinq> Asmadeus, thanks :)
2025-01-26 08:40:03 <Asmadeus> (sorry, hadn't clicked your link until after I sent that -- I updated the reported-by with your mail in the commit)
2025-01-26 08:41:10 <quinq> No sweat!
2025-01-26 08:41:26 <quinq> Should have communicated, but that's not a lot wasted :)
2025-01-26 08:45:13 <vkrishn> i think i got what you meant, but does current linter does not do it, maybe its doing
2025-01-26 08:45:21 <vkrishn> its not that difficult to
2025-01-26 08:45:44 <vkrishn> query a db 
2025-01-26 08:54:32 <vkrishn> now looking at, https://gitlab.alpinelinux.org/alpine/infra/atools-go
2025-01-26 09:11:53 <vkrishn> nope, did not locate it
2025-01-26 09:14:16 <pj> doesn't make much sense to look for that or make such thing
2025-01-26 09:14:39 <pj> if someone is packaging something, they need to look into upstream documentation to see what dependencies it has
2025-01-26 09:15:32 <pj> build it locally, push, check CI, done
2025-01-26 09:17:41 <pj> there's also not many times that something is used by other port build and has restricted arch
2025-01-26 09:17:54 <pj> most of the time it would be limited by the language (e.g. rust)
2025-01-26 09:28:49 <vkrishn> ikke: how big is the pkgs.a.o db now, is it split in any way, like version branch/version?
2025-01-26 09:38:23 <vkrishn_> nm, it can be an overdo
2025-01-26 10:00:44 <fabricionaweb> did something change in options=net for cargo aports? 
2025-01-26 10:01:11 <fabricionaweb> vaultwarden wasnt using it and it worked but now I need to add it
2025-01-26 10:01:55 <pj-> are you building with rootbld
2025-01-26 10:03:25 <fabricionaweb> yes
2025-01-26 10:03:58 <fabricionaweb> but first time actually, before the other builds wasnt using rootbld
2025-01-26 10:05:35 <pj-> then yes, you need options=net for it to fetch crates
2025-01-26 10:06:19 <pj-> this is longstanding issue of abuild, rootbld doesn't get network in sandbox when building because all dependencies are fetched before it
2025-01-26 10:06:33 <fabricionaweb> but for the ci/piplines it worked without it
2025-01-26 10:06:45 <pj-> CI doesn't use rootbld
2025-01-26 10:07:15 <fabricionaweb> I see, I thought the options=net were useful for the ci as well
2025-01-26 10:07:30 <pj-> GitLab CI is abuild in docker, Alpine build hosts are building with no sandboxing
2025-01-26 10:07:31 <fabricionaweb> thanks! gonna add it to the aport now
2025-01-26 10:08:31 <pj-> I've recently talked about it here, I'm still trying to find a clean and nice solution to this
2025-01-26 10:22:36 <fabricionaweb> I think the latest vaulwarden have forget to update lock files :P it breaks if use --frozen
2025-01-26 10:53:20 <Asmadeus> pj-: fwiw fedora packages all the source crates (and kludge each applications lock file to all work with a single version), and it's a lot of work, so if you can run cargo in prep then `cargo vendor --locked` early on with net and build without net is probably easier, but as you said the other day that means adding some sort of deps mechanism to fetch (or making cargo/go/whatever else come up 
2025-01-26 10:53:26 <Asmadeus> available by default which isn't great either)... tricky...
2025-01-26 10:53:37 <Asmadeus> alternatively nix processes the cargo.lock to download stuff iirc
2025-01-26 10:55:00 <pj> I'm aware, not interested in Debian/Fedora approach of breaking applicatiosn though
2025-01-26 10:55:28 <Asmadeus> yeah, I said that to advice against it :)
2025-01-26 10:56:26 <pj> will tinker with it and how it feels
2025-01-26 11:39:12 <Asmadeus> hm... (checking https://github.com/NixOS/nixpkgs/tree/master/pkgs/build-support/rust later) yeah, if there is a lock file, and all dependencies are crates from crates.io (from the source attribute), then it's as simple as iterating over them and downloading https://crates.io/api/v1/crates/${crateName}/${version}/download as ${crateName}-${version}.tar.gz so it's actually not that hard to emulate 
2025-01-26 11:39:19 <Asmadeus> without cargo and that'll probably cover 90% of the apps
2025-01-26 11:39:38 <Asmadeus> Still going to need some way out for the rest though
2025-01-26 14:03:08 <Saijin_Naib[m]> I few of my aport MRs failed in CI with update-desktop-database being missing. Is that something I should normally declare for builddeps, or is that just a bit of oddness since the CI doesn't have much of anything in it?
2025-01-26 14:10:45 <ikke> If it's not available in CI, it's certainly not available on the builders
2025-01-26 14:11:16 <fossdd[m]> <Saijin_Naib[m]> "I few of my aport MRs failed..." <- yeah you should add `desktop-file-utils` to `makedepends`
2025-01-26 14:14:37 <Saijin_Naib[m]> Ah okay, thanks
2025-01-26 14:51:58 <fossdd[m]> can someone merge !78715?
2025-01-26 16:52:24 <ikke> gitlab will be updated in ~8 minutes and will be briefly unavailable
2025-01-26 19:46:51 <Saijin_Naib[m]> fossddI've resolved the issues with my three recent MRs, pending your review/approval. I think they are good to rock
2025-01-26 20:13:43 <quinq> Installing Alpine, “Enter ssh key or URL for $newuser”
2025-01-26 20:13:55 <quinq> Are we really expecting users to enter ssh public keys manually? xD
2025-01-26 20:16:01 <ikke> or URL
2025-01-26 20:16:33 <quinq> Is that a yes?
2025-01-26 20:16:48 <ikke> You don't _have_ to 
2025-01-26 20:17:42 <quinq> ok, let-me reformulate
2025-01-26 20:17:56 <quinq> Are we really expecting users to have the tenacity to ever enter an ssh public key manually?
2025-01-26 20:18:50 <quinq> I get that it's optional, it just feel weird
2025-01-26 20:21:11 <ikke> Not really, but in some cases, you can paste it in
2025-01-26 20:24:02 <ptrc> i've typed in an ed25519 public key by hand multiple time, so in a really bad situation i'd be glad to have that option :p
2025-01-26 20:24:38 <ikke> :)
2025-01-26 20:24:45 <ikke> ed25519 is certainly doable
2025-01-26 20:24:46 <ptrc> rsa4096 is a different matter though
2025-01-26 20:25:04 <Ermine> how do i type rsa8192
2025-01-26 20:26:25 <quinq> wuut
2025-01-26 20:26:38 <quinq> Why is my alpine setup sending traffic to clownfare
2025-01-26 20:27:08 <quinq> During install, at this point in the setup
2025-01-26 20:27:39 <quinq> NTP :(
2025-01-26 20:30:02 <quinq> Sooo
2025-01-26 20:30:10 <quinq> It's doing ns resolution correctly
2025-01-26 20:30:26 <quinq> But then doesn't even initiate an http request for getting the key
2025-01-26 20:30:44 <quinq> and wget timesout
2025-01-26 20:36:10 <quinq> fixed
2025-01-27 08:54:34 <mzh> Can some merge this? Thanks https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77905
2025-01-27 09:13:00 <Asmadeus> It needs a pkgrel bump as someone commented
2025-01-27 10:03:36 <mzh> Asmadeus done pkgrel bump
2025-01-27 10:18:13 <qaqland> .rootbld-repositories has $version, but abuild doesn't read it
2025-01-27 10:19:13 <qaqland> abuild just set it as "edge" or git HEAD branch
2025-01-27 10:21:30 <pj> seems correct
2025-01-27 10:22:51 <qaqland> but how can I run abuild rootbld with $version="v3.21"
2025-01-27 10:23:39 <sertonix[m]> Easiest way is to just edit .rootbld-repositories
2025-01-27 10:25:09 <pj> qaqland: you checkout 3.21-stable branch
2025-01-27 10:28:17 <qaqland> sertonix[m]: thx, it works
2025-01-27 10:29:25 <qaqland> hope it would be changed easily with env:version
2025-01-27 11:42:43 <fabricionaweb> damn I tried to bump nodejs, got so close
2025-01-27 11:43:07 <fabricionaweb> [1912/1919] and it failed
2025-01-27 13:13:55 <qaqland> riscv get this: ERROR: Job failed: execution took longer than 1h0m0s seconds
2025-01-27 13:15:42 <qaqland> !77397 waht shoud I do, disable check for this architecture?
2025-01-27 13:18:15 <pj> qaqland: go to your aports fork, into settings and change CI timeout
2025-01-27 13:18:48 <pj> https://gitlab.alpinelinux.org/alpine/aports/-/settings/ci_cd#js-general-pipeline-settings
2025-01-27 13:41:14 <elagost> would someone be willing to look at this merge request? very small change. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78867
2025-01-27 13:48:48 <qaqland> pj: thx
2025-01-27 14:31:41 <caskd> is it intentional that the bot pinging maintainers about outdated packages doesn't add the email date to the email?
2025-01-27 14:32:05 <caskd> my mail client sorts by date and doesnt add its own date so these mails often get pushed out of the view at the bottom
2025-01-27 16:03:48 <ikke> caskd: Never noticed anything about that
2025-01-27 16:03:57 <ikke> these are just gitlab notifications, so nothing special about that
2025-01-27 16:09:22 <caskd> not those
2025-01-27 16:09:40 <caskd> i mean the ones from the fedora stream
2025-01-27 16:09:45 <caskd> can't recall how it's named
2025-01-27 16:09:53 <caskd> i can look for a example in my email
2025-01-27 16:11:38 <ikke> ah those
2025-01-27 16:11:40 <ikke> anitya
2025-01-27 16:12:02 <ikke> By bot I assume you mean aports-qa-bot, which is gitlab ;-)
2025-01-27 16:12:38 <caskd> nah, those are fine
2025-01-27 16:13:11 <ikke> From one of the mails: Date: Sun, 26 Jan 2025 18:01:57 -0800 (PST)
2025-01-27 16:13:18 <ikke> I do get a Date header
2025-01-27 16:14:39 <caskd> lemme look for my example
2025-01-27 16:25:19 <caskd> oh, i got a few examples but they're not many
2025-01-27 16:25:27 <caskd> maybe they are old and i never archived them
2025-01-27 16:25:29 <caskd> ¯\_(ツ)_/¯
2025-01-27 16:25:46 <caskd> but if any further ones pop in my inbox i'll let you know
2025-01-27 17:52:21 <Asmadeus> Could someone have a look at !77498 ? Last time I'll ask here, 3.21 has been out for long enough that this is starting to matter less as people who'd upgrade probably have by now..
2025-01-27 20:00:01 <Asmadeus> ncopa: Thank you!
2025-01-27 23:27:58 <quinq> There seems to be an oversight (maybe) with the acpid package
2025-01-27 23:28:31 <quinq> It's installed in /usr/sbin, while the busybox is in /sbin
2025-01-27 23:29:00 <quinq> So even when installing acpid instead of the busybox stub, the latter stays there
2025-01-27 23:29:30 <quinq> In turn, the acpid-openrc package exclusively runs the busybox one, with "/sbin/acpid"
2025-01-27 23:30:31 <quinq> Maybe that's a conscious decision, but it rather looks like an actual issue
2025-01-27 23:34:44 <Ariadne> well, the /usr part is on purpose.  it allows for more cleanly overriding the busybox default.  but yes, probably a bug with the openrc script
2025-01-27 23:35:29 <Asmadeus> Is there anywhere one can check something akin to builders status? Looking at https://dl-cdn.alpinelinux.org/alpine/v3.21/community/aarch64/ I see a couple of days lag (1cd61a8a1daf ("community/dotnet9-runtime: security upgrade to 9.0.1") merged ~45h ago doesn't seem in while x86_64 is a bit further at go rebuilds (~33h ago), and edge is on top of recent merges); I wouldn't have expected such 
2025-01-27 23:35:35 <Asmadeus> differences. (Not complaining, just wondering if something got stuck)
2025-01-27 23:36:16 <Ariadne> https://build.alpinelinux.org/ shows the botnet status
2025-01-27 23:36:21 <Ariadne> and yes, i mean botnet literally
2025-01-27 23:36:54 <Ariadne> you can also get this information in real-time on #alpine-commits
2025-01-27 23:37:19 <Asmadeus> Thanks! So looking at that it looks like it's waiting for someone to look at the build fail for 3.21-aarch64 ?
2025-01-27 23:38:12 <Ariadne> i looked at it already, it appears to be a networking fault
2025-01-27 23:38:17 <Ariadne> i sent a retry
2025-01-27 23:38:35 <quinq> Ariadne, sounds about right :)
2025-01-27 23:38:54 <Asmadeus> Ariadne: thank you
2025-01-27 23:40:24 <quinq> Although afaiu, the busybox override system isn't done by making advantage of /(s)bin /usr/(s)bin separation, but by just overwriting symlinks to it
2025-01-27 23:51:02 <Ariadne> right
2025-01-27 23:51:15 <Ariadne> well, we do it both ways, it depends on the package
2025-01-28 02:13:32 <Abdulaziz> https://www.donte.net/
2025-01-28 14:20:44 <skarnet> donte click on dis
2025-01-28 14:21:01 <pj> too late
2025-01-28 14:47:38 <fabricionaweb> micronsoft donte net
2025-01-28 14:51:56 <qaqland> i think we can post a TSC document link here at the end of every meeting
2025-01-28 21:23:00 <ayakael> Hello all. Could someone review this MR for me? Thanks :) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/78661
2025-01-28 21:24:41 <ikke> ayakael: btw, I'm trying to figure out why dotnet9-runtime is failing on aarch64
2025-01-28 21:24:52 <ikke> I know there is some network issue to reach nuget
2025-01-28 21:24:59 <ikke> I've worked around it, but still getting a timeout
2025-01-28 21:25:42 <ayakael> Indeed! I'm also working on a workaround by having the test suite be buildable offline.
2025-01-28 21:26:37 <ikke> I can manually curl https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json both ipv4 and ipv6 in the build container now
2025-01-28 21:28:20 <ayakael> That's terrific, thanks! Hopefully this'll fix the issue on stage0 as well once I update that.
2025-01-28 21:28:58 <ikke> For some reason it still hangs though
2025-01-28 21:29:13 <ikke> Restore (nn.ns)
2025-01-28 21:31:10 <ikke> checking traffic with tcpdump / wireshark to see if that reveals something
2025-01-28 21:31:48 <ayakael> Gotcha, thanks.  I'll have the offline build finished up in a couple of hours.
2025-01-28 21:33:14 <ikke> ok
2025-01-28 21:41:49 <ikke> ayakael: In wireshark, I do see a TLS session being setup and traffic being sent 
2025-01-28 21:42:07 <ikke> So kinda puzzled
2025-01-28 21:42:12 <Asmadeus> ikke: MTU issue ?
2025-01-28 21:42:29 <Asmadeus> that kind of stuff connects and hangs in the middle of tls handshakes..
2025-01-28 21:43:47 <Asmadeus> Could try forcing ipv4 if ipv6 is on (routers in the middle don't fragment for you and if icmpv6 is blocked the client won't know it needs to reduce), or temporarily lower MTU on interface
2025-01-28 21:43:56 <ikke> it's ipv4
2025-01-28 21:44:51 <ikke> I don't see signs of MTU issue
2025-01-28 21:45:54 <ikke> ayakael: how long is the restore part expected to take?
2025-01-28 21:46:09 <ayakael> It should take less than 30 seconds.
2025-01-28 21:46:41 <ikke> hmm
2025-01-28 21:46:54 <ikke> taking almost 5 minutes now
2025-01-28 21:53:34 <ikke> ayakael: btw, -p:VersionSuffix="$(git rev-parse --short HEAD)" does not work, abuild sets GIT_CEILING_DIRS to prevent packages from accidentally  including information from aports
2025-01-28 21:56:16 <ayakael> Noted. Are you able to wget this file from container? https://www.nuget.org/api/v2/package/Microsoft.NetCore.Analyzers/3.3.2
2025-01-28 21:58:54 <ikke> yes
2025-01-28 22:03:44 <ikke> Bedtime now for me
2025-01-28 22:04:13 <ayakael> Thanks for taking a stab at the problem. I'm equally puzzled, can't make heads or tails of the issue.
2025-01-28 22:05:41 <ikke> There was a routing issue for sure. I've setup a temporary wg tunnel to route traffic over
2025-01-28 22:06:52 <ikke> After that was setup, I'm able to request the urls that were timing out, but the turkey test still times out
2025-01-28 22:32:59 <Ariadne> ayakael: thanks for working on this
2025-01-28 22:35:04 <ayakael> No worries. Unfortunately I've run out of time for tonight. I would merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/79098 to unblock builders and I'll take another stab at this in the coming days.
2025-01-29 02:47:14 <tomleb> hey folks, what could prevent a package to end up in the apk cache? I'm having trouble with udev-init-scripts. Somehow, my apk cache contains udev-init-scripts-openrc, but not udev-init-scripts.
2025-01-29 02:48:42 <tomleb> Even when I run `apk cache sync`
2025-01-29 02:58:08 <Asmadeus> Anything wrong if you run with `apk cache -v sync` ? (Curious if I can reproduce, what version/arch ?)
2025-01-29 03:14:58 <tomleb> Asmadeus: I get no output with -v. raspberry pi, aarch64
2025-01-29 03:15:26 <j_v> vile just released version 9.8za which lint pukes on... any ideas?
2025-01-29 03:17:50 <tomleb> Asmadeus: Here's some more output: https://paste.sr.ht/~tomleb/64e7e6b4e5b22756c80aa7d18e7e87f11c7e983c
2025-01-29 03:18:29 <Asmadeus> I've reproduced it on 3.21 (still had 3.20 locally and couldn't reproduce there)
2025-01-29 03:20:26 <Asmadeus> ok, so I think it's as simple as "because the package is empty"
2025-01-29 03:21:15 <Asmadeus> trying to check if I can find another empty package to confirm..
2025-01-29 03:25:51 <Asmadeus> yeah, does the same with another empty package
2025-01-29 03:27:06 <tomleb> Thanks for reproducing. This prevents installing other packages that depend on this one with `--no-network` (eg: when using diskless)
2025-01-29 03:27:52 <Asmadeus> Older versions of empty packages had a .dummy file inside, so this is probably an unintended change of https://gitlab.alpinelinux.org/alpine/abuild/-/commit/5a5df023cb05732ba293b81fdb729db4f2301ef0
2025-01-29 03:28:44 <Asmadeus> I agree it's a problem, not sure how to workaround quickly but the fix itself probably isn't too hard if you don't need something right now
2025-01-29 03:35:15 <tomleb> nice find. I would like to be able to run this thing diskless though. I suppose I could build the package locally with a dummy file added. 
2025-01-29 03:46:33 <Asmadeus> yes or pre-install it as a virtual package `apk add -t udev-init-scripts` might also work
2025-01-29 03:54:06 <tomleb> `apk add -t udev-init-scripts` still won't get it in the cache, so it won't be able to install on reboot. Unless I misunderstood your suggetsion
2025-01-29 03:55:09 <Asmadeus> I meant hardcoding its install in a script before reinstalling from cache, but yes it's kludgy :)
2025-01-29 03:55:47 <Asmadeus> Anyway, I couldn't find the problem in apk -- perhaps something that because there's no file the checksum isn't valid or something? (apk manifest output is empty..); it'd be great if you could open an issue in https://gitlab.alpinelinux.org/alpine/apk-tools
2025-01-29 03:56:01 <Asmadeus> 
ACTION 's lunch break is over

2025-01-29 04:01:52 <quinq> That's a very sloppy commit
2025-01-29 04:02:04 <quinq> Weird that it was validated by anybody
2025-01-29 04:02:24 <quinq> There's 0 explanation about how that was done, while it's also on a core part of Alpine
2025-01-29 04:02:30 <quinq> s/how/why/
2025-01-29 04:10:09 <tomleb> Will do, thanks for the help!
2025-01-29 04:43:03 <Saijin_Naib[m]> If !79020, !79021, and !79023 look good, can I get a final review and merge when someone has a moment?
2025-01-29 04:55:43 <tomleb> Here's the workaround I went with (in case that's useful): Built the package locally, added `touch "$pkgdir"/.dummy` to the install step, so the package isn't empty anymore. Copied the built packages dir and added the repo in /media/mmcblk0p1/apks2. That's it.I could probably get rid of the `touch` since the files don't end up in the cache because it's a local repo. 
2025-01-29 04:55:53 <tomleb> Will open an issue tomorrow, time to sleep now.
2025-01-29 05:26:32 <Asmadeus> tomleb: (I've opened https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11079 since it's fresh in memory)
2025-01-29 06:26:40 <j_v> i've read the pkgver description in APKBUILD(5) plenty of times, but i am mystified as to why it would disallow a version string such this: 9.8za.
2025-01-29 06:28:45 <j_v> this is the new release for the vile editor. i will admit, it is not a 'standard' by any definition i've read about. but i don't see why is should be wrong.
2025-01-29 06:30:55 <ikke> "After the final number (and optional single letter),"
2025-01-29 06:31:07 <j_v> yeah, i read it
2025-01-29 06:31:13 <j_v> but why
2025-01-29 06:32:00 <j_v> is there some higher official convention or rules in play with this
2025-01-29 06:32:02 <j_v> ?
2025-01-29 06:33:30 <ikke> j_v: The higher-level constraint is having a reliable way to compare versions
2025-01-29 06:33:58 <sertonix[m]> apk needs to understand the versions used without falling back to the faulty string comparison
2025-01-29 06:34:41 <j_v> ok, so i have to CHANGE upstreams' version string to suit our 'rules'? the words for this rigidity are not nice
2025-01-29 06:35:21 <ikke> j_v: not sure if it helps, but here is a (reverse engineered) EBNF specification: https://pkg.go.dev/gitlab.alpinelinux.org/alpine/go@v0.10.1/version
2025-01-29 06:37:01 <j_v> no, no... it's not whether i understand the text of the constraint, but the banality of it
2025-01-29 06:37:42 <ikke> You don't have to change the upstream version scheme, but it does mean you have to do some conversion if you want to make an APKBUILD
2025-01-29 06:38:36 <j_v> how do i convert '9.8za' to some thing that makes sense?
2025-01-29 06:39:27 <j_v> sorry this the kind of thing that really frustrates me
2025-01-29 06:39:42 <j_v> i mean, it just feels silly
2025-01-29 06:40:00 <j_v> sorry i leave, come back when i am not so irratated
2025-01-29 06:44:14 <ikke> j_v: It helps to realize these rules are not made arbitrarily
2025-01-29 07:48:04 <indy> fabled, ping hi, any plan for rc4 (apk-tools v3)?
2025-01-29 08:29:36 <fabled> indy: hi, yes, will tag this week. you may want to join #apk-tools channel for the v3 discussion
2025-01-29 08:36:46 <indy> fabled, thanks for channel sharing, joined
2025-01-29 09:59:51 <donoban> how package something that uses date as version? ttps://github.com/artempyanykh/marksman/releases
2025-01-29 10:40:07 <fossdd[m]> you can use a format like YYYY.MM.DD
2025-01-29 11:35:51 <donoban> and something like $_pkgver for sources?
2025-01-29 11:37:11 <ikke> ${pkgver//./-}
2025-01-29 11:43:40 <donoban> ok ty :)
2025-01-29 13:24:54 <tomleb> Asmadeus: Thanks for creating that issue. Looks like there were a few issues already opened about this. IIRC, it should be fixed in edge but not yet in v3.21. I'm trying to get a rasp pi image with edge, but can't find a download for that. I wonder if I can simply change the /etc/apk/respositories and `apk fix` for diskless images.
2025-01-29 13:25:16 <Saijin_Naib[m]> <j_v> "how do i convert '9.8za' to some..." <- Alphabet cypher? 9.8.26.1
2025-01-29 16:32:31 <donoban> beh I think that this is better than marksman ttps://github.com/Feel-ix-343/markdown-oxide
2025-01-29 16:46:56 <donoban> >>> markdown-oxide*: Create checksum...
2025-01-29 16:46:58 <donoban> >>> markdown-oxide*: Create markdown-oxide-0.25.0-r0.apk
2025-01-29 16:47:00 <donoban> awesome on first attempt
2025-01-29 16:48:34 <fabricionaweb> nice, love when it happens
2025-01-29 16:48:59 <fabricionaweb> remember me that I have one waiting to be merge
2025-01-29 16:49:11 <donoban> I was fighting with dotnet8 with marksman, opening a shell for patching on each try :D
2025-01-29 16:58:36 <donoban> 2025-01-29T17:57:43.785 helix_lsp::client [WARN] language server failed to terminate gracefully - server closed the stream
2025-01-29 16:58:38 <donoban> 2025-01-29T17:57:43.785 helix_lsp::transport [INFO] markdown-oxide -> {"jsonrpc":"2.0","method":"exit"}
2025-01-29 16:58:40 <donoban> 2025-01-29T17:57:43.785 helix_lsp::transport [ERROR] markdown-oxide err: <- IO(Os { code: 32, kind: BrokenPipe, message: "Broken pipe" })
2025-01-29 16:58:42 <donoban> something fails
2025-01-29 17:08:00 <yyp> markdown-oxide seems to incorrectly implement the language server protocol
2025-01-29 17:10:26 <donoban> yyp: wops, second time I typed /exit instead /close
2025-01-29 17:10:58 <donoban> I think that I will use other editor for md files
2025-01-29 17:11:34 <yyp> I can try to fix this upstream. Quite a few language servers incorrectly implement the shutdown sequence and thus cause issues helix 
2025-01-29 17:12:30 <donoban> hmm.. so it closes on startup?
2025-01-29 17:17:35 <donoban> https://github.com/Feel-ix-343/markdown-oxide/issues/210 uhmm...