2022-03-01 02:12:55 <ktprograms> Hi, any ideas on how I can further debug the xorg segfault I'm getting when running "picom --backend glx" on my Thinkpad X1 Carbon Gen 1? (See my question from yesterday for more details). Should I open an issue?
2022-03-01 02:20:14 <psykose> an issue would be nice
2022-03-01 02:20:55 <ktprograms> gitlab theme has changed? The sidebar icons seem to have thinner lines.
2022-03-01 02:21:08 <psykose> 14.5.x->14.7.x
2022-03-01 02:21:20 <psykose> earlier today
2022-03-01 02:21:25 <psykose> upgraded
2022-03-01 02:21:42 <ktprograms> psykose: I see
2022-03-01 02:21:43 <psykose> lots of icons are different
2022-03-01 02:21:50 <psykose> that is just about the only change i noticed
2022-03-01 02:22:09 <psykose> i guess everything also loads like 2x faster than before somehow
2022-03-01 02:22:10 <psykose> :)
2022-03-01 02:22:21 <psykose> but that's probably just being restarted or whatever
2022-03-01 02:22:36 <ktprograms> hmm it does seem to be faster
2022-03-01 02:25:08 <ktprograms> #13556
2022-03-01 02:25:15 <ktprograms> #13566
2022-03-01 02:25:19 <ktprograms> I can't read apparently
2022-03-01 02:25:22 <ktprograms> :)
2022-03-01 02:25:45 <psykose> neither can i
2022-03-01 05:54:53 <ikke> glad to hear it's faster :)
2022-03-01 05:55:01 <ikke> (gitlab)
2022-03-01 06:12:17 <psykose> overwhelming speed
2022-03-01 06:15:15 <psykose> how would you feel if i threw ~515 rebuilds at the ci
2022-03-01 06:17:14 <boomanaiden154> LLVM13 stuff?
2022-03-01 06:17:21 <psykose> that's not merged yet
2022-03-01 06:17:27 <ikke> psykose: I'd say that would be quite much
2022-03-01 06:17:32 <psykose> gettext-dev -> gettext-tiny-dev
2022-03-01 06:17:40 <psykose> we were planning it eventually
2022-03-01 06:17:46 <psykose> i already have the 515 commits i just made
2022-03-01 06:17:57 <boomanaiden154> There's also a limit on the Gitlab CI for how deep it will go in the git history to find packages to rebuild.
2022-03-01 06:18:04 <psykose> ah, there sure is
2022-03-01 06:18:06 <ikke> 500 commits atm
2022-03-01 06:18:08 <psykose> heh
2022-03-01 06:18:10 <psykose> barely over
2022-03-01 06:18:12 <ikke> at least, that's the fetch depth
2022-03-01 06:18:15 <psykose> yeah
2022-03-01 06:18:16 <boomanaiden154> Yes. We ran into it with the python rebuild in December.
2022-03-01 06:18:30 <ikke> I can increase it if necessary
2022-03-01 06:18:39 <psykose> 550 would work, if i missed nothing
2022-03-01 06:18:50 <boomanaiden154> Not that the CI passed for that anyways with the CI not working on subpackage dependencies.
2022-03-01 06:18:51 <ikke> but maybe a good usecase of the multi-stage builds I'm working on
2022-03-01 06:18:57 <psykose> but i went by libintl dep, so it should be correct
2022-03-01 06:19:13 <psykose> idk what else would need a rebuild against -tiny that also doesn't explicitly already pull libintl
2022-03-01 06:20:19 <psykose> and with that we will fix the python mess too, of gettextdomain not existing
2022-03-01 06:20:27 <boomanaiden154> multi-stage builds would be great. I still think splitting each package build into an individual job would allow for better parallelism, but like Ikke has mentioned, there are some disadvantages to that approach.
2022-03-01 06:20:53 <psykose> it wouldn't work unless we had a) more than 2 runners and b) the base setup time wasn't like 45 seconds
2022-03-01 06:21:16 <boomanaiden154> Yeah. The setup time is the big killer. The two runners are on two different machines?
2022-03-01 06:21:18 <psykose> if the containers got to abuild() in 2 seconds it would be a little better
2022-03-01 06:21:21 <psykose> same machine
2022-03-01 06:21:30 <rabbitz> 
ACTION who the fuck need gui at server ... . just go from here ... . https://cryptobug.wordpress.com/2020/10/04/ssh-tunneling-xming-with-putty-opening-gui-application-with-command-line/ , is from client with ssh forwarder .... .

2022-03-01 06:21:33 <psykose> wow!
2022-03-01 06:22:36 <boomanaiden154> psykose: the docker containers run by the gitlab runner just have abuild.conf set to $(nproc / 2) or something like that?
2022-03-01 06:22:45 <psykose> i assume not
2022-03-01 06:22:54 <psykose> no idea
2022-03-01 06:23:02 <psykose> that also isn't generally good, as a lot of the time is downtime
2022-03-01 06:24:49 <boomanaiden154> True. Didn't even think of that.
2022-03-01 06:25:33 <boomanaiden154> I wonder how much faster the setup time would be if the docker executor was switched to a shell executor and abuild rootbld was used like the TSC has been discussing.
2022-03-01 06:25:44 <psykose> ikke: you should also let me have like ~99999 hours, but not sure if that will work anyway :)
2022-03-01 06:25:45 <psykose> mm
2022-03-01 06:26:04 <psykose> a lot? that would take 0s before the deps start
2022-03-01 06:26:35 <psykose> well, you add the git stuff
2022-03-01 06:26:41 <ktprograms> psykose: I thought abuild rootbld takes a while to download the source and create the chroot stuff?
2022-03-01 06:26:41 <ikke> We have a tradeoff. We don't want one MR to hold back other MRs for days
2022-03-01 06:27:00 <psykose> ktprograms: the containers already download the source- this is for ci
2022-03-01 06:27:46 <ktprograms> psykose: Ah I see
2022-03-01 06:28:05 <psykose> ikke: no conflict from me- but at some point this has to be tested/built or somesuch, not sure what the other approach aside from doing it like python and just merging it
2022-03-01 06:28:23 <psykose> if you want a formal writeup first i can make one, i think we had some discussions already
2022-03-01 06:28:28 <psykose> but i would wait for ariadne to wake up
2022-03-01 06:28:45 <psykose> she told me to do it in the first place :p
2022-03-01 07:12:08 <ikke> The multi-stage builds should help in theory 
2022-03-01 07:14:17 <psykose> if it cycles between all open builds that is nice
2022-03-01 07:14:31 <psykose> i.e. the runners pick something random each time
2022-03-01 07:22:35 <ikke> AFAIK, the jobs in a stage get scheduled once the pipeline reaches that stage 
2022-03-01 07:24:23 <psykose> yeah, it seems to work that way
2022-03-01 07:24:30 <psykose> just guessing off the timing off the lint stage
2022-03-01 07:24:39 <psykose> also the lint stage holds things for 30 seconds for no reason :p
2022-03-01 07:25:01 <ikke> So that should give other jobs a chance to go in between 
2022-03-01 07:25:21 <psykose> with multi stage, yeah
2022-03-01 07:25:24 <psykose> sounds good to me
2022-03-01 07:29:50 <boomanaiden154> https://gitlab.com/gitlab-org/gitlab/-/issues/323100 this would be interesting for deprioritizing really large builds to allow smaller MRs to get built in the meantime and run large MRs in what would otherwise be downtime, but doesn’t look like it’s coming out for a while.
2022-03-01 07:30:28 <psykose> can this yaml priority be added dynamically
2022-03-01 07:30:42 <psykose> if it's in the gitlab conf then it's pretty hard to actually configure per aport or something
2022-03-01 07:30:48 <boomanaiden154> Once the feature exists, yes.
2022-03-01 07:31:01 <psykose> then it's possible
2022-03-01 07:31:16 <boomanaiden154> At least if Ikke is planning on using dynamic child pipelines.
2022-03-01 07:31:18 <psykose> still takes some work, it's basically having some scripted heuristic for 'build time' and weighing priority by that
2022-03-01 07:31:22 <boomanaiden154> (Which I believe is the current plan)
2022-03-01 07:31:34 <psykose> we have no metrics for per-package build time, and that would take a lot of things to make
2022-03-01 07:31:55 <psykose> if we did, it's just scanning mr changes, adding up some numbers, etc etc
2022-03-01 07:32:33 <boomanaiden154> I think just setting a threshold for the number of rebuilt aports would be enough.
2022-03-01 07:32:34 <psykose> there is also the lazy version of 'changed more than 10 apkbuilds' or 'has a web browser in it' etc
2022-03-01 07:32:47 <psykose> which is good sure
2022-03-01 07:32:57 <ikke> Right now the plan is to just limit the amount of packages per job 
2022-03-01 07:41:17 <ikke> Later weer can look into more fancy things 
2022-03-01 07:41:53 <psykose> don't think we need anything that fancy tbh
2022-03-01 07:42:09 <psykose> 99.99% of our issues go away with just stages and fixing the eternal startup time
2022-03-01 10:21:34 <PureTryOut> psykose: just a tip, you didn't have to disable ace-of-penguins for riscv64
2022-03-01 10:21:53 <PureTryOut> I re-enabled it, you can just run `update_config_sub` and `update_config_guess` in the `prepare()` function and it'll work just fine
2022-03-01 10:25:18 <psykose> PureTryOut: i did try the latter but forgot the former
2022-03-01 10:25:19 <psykose> thanks
2022-03-01 10:25:36 <PureTryOut> np!
2022-03-01 14:12:09 <Ariadne> tempted to just push that gettext thing this weekend and see what blows up
2022-03-01 16:09:42 <psykose> ikke: could you kick/retry the aarch64 builder when you see this :)
2022-03-01 17:31:01 <Hello71> why all archs except ppc64le think no aports changed? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/31554
2022-03-01 17:56:41 <psykose> now that is broken
2022-03-01 19:50:34 <ikke> nmeum: nice 0a9f26836cae7242bf781a1629e54b4f97f3f120
2022-03-01 19:57:00 <nmeum> ikke: was also merged upstream, let's hope that this was actually the issue we were seeing on the builders 🤞
2022-03-01 19:57:38 <ikke> nmeum: ahuh
2022-03-01 19:58:01 <ikke> nmeum: at least seams plausible, given how we worked around it
2022-03-01 19:58:14 <ikke> ie, it matches the specific thing we changed
2022-03-01 20:34:09 <Hello71> ikke: ideas about !31554?
2022-03-01 20:38:23 <ikke> Hello71: Could you try to run it with CI_DEBUG_BUILD=1 set in the environment? (either in your project CI settings or .gitlab-ci.yml?
2022-03-01 20:57:48 <ikke> I wish we had something that would verify whether patches matched a commit from upstream
2022-03-01 20:58:54 <Hello71> something something blockchain something
2022-03-01 21:04:18 <Hello71> so the reason why it works on ppc64le is because ppc64le is using an old alpine-docker-ci
2022-03-01 21:07:02 <Hello71> the reason why it's broken everywhere else is because https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/commit/8e74233319028bd5ba75ac6b0eb18fe8c813b63f does not account for packages being removed from a repository
2022-03-01 21:08:08 <Hello71> so build_start becomes negative, and sed decides to print nothing
2022-03-01 21:08:29 <Hello71> possibly this is related to recent busybox patches
2022-03-01 21:14:46 <ptrc> could https://gitlab.alpinelinux.org/alpine/alpine-baselayout get marked as archived? from what i can see, files for baselayout are in aports anyway and people seem to open issues there for some reason
2022-03-01 21:24:21 <ptrc> hm, on !31562 it doesn't see changed aports either
2022-03-01 21:24:29 <ptrc> even though nothing is moved/removed
2022-03-01 21:31:38 <Hello71> you've not updated pkgrel
2022-03-01 21:32:14 <ptrc> ah, yeah
2022-03-01 21:32:16 <ptrc> i messed up
2022-03-01 21:32:17 <ptrc> nevermind
2022-03-01 21:32:44 <ptrc> i didn't commit APKBUILD at all
2022-03-01 21:33:27 <Hello71> er, or sha256sums, right
2022-03-02 04:53:20 <ikke> Hello71: thanks, I'll look into it 
2022-03-02 13:10:43 <psykose> ikke: seems you have to kick aarch64 again because yet another testsuite deadlocked in it
2022-03-02 13:10:45 <psykose> joy
2022-03-02 13:10:58 <ikke> F.U.N
2022-03-02 13:11:04 <psykose> i passed those testsuites maybe 30 times in ci
2022-03-02 13:12:07 <ikke> openvdb
2022-03-02 13:12:09 <psykose> yep
2022-03-02 13:12:35 <psykose> sigh
2022-03-02 13:12:38 <psykose> this has only one test too
2022-03-02 13:15:01 <psykose> ah, riscv caught up too
2022-03-02 13:15:03 <psykose> nice :)
2022-03-02 18:22:05 <ikke> Hello71: apparently it's not necessary about removing packages, but packages that have been moved
2022-03-02 18:24:44 <Hello71> yes, removed from an alpine repository, not necessarily the git repository
2022-03-02 18:24:51 <Hello71> s/git/aports &/
2022-03-02 18:24:51 <alpine-meetbot> Hello71 meant to say: yes, removed from an alpine repository, not necessarily the aports & repository
2022-03-02 18:28:34 <ikke> It doesn't support & sadly :)
2022-03-02 18:34:11 <ikke> Hello71: any case, the fix is simple. There is discrapency between changed_repos and changed_aports
2022-03-02 18:34:31 <ikke> changed_aports uses a diff-filter, while changed_repos does not
2022-03-02 18:40:42 <Hello71> mmhmm
2022-03-02 18:40:57 <Hello71> what about the outdated ppc64le image
2022-03-02 18:41:28 <ikke> just need to pull it on that ci host
2022-03-02 18:41:46 <ikke> to prevent rate-limiting, it only pull the image if it does not exist
2022-03-02 18:42:09 <ikke> and there is a cron job that once a week that removed everything that's not used, which then also causes new images to be pulled
2022-03-02 19:22:43 <ikke> Hello71: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/merge_requests/11
2022-03-02 21:46:08 <ikke> Hello71: now it's actually building the packages
2022-03-02 22:13:42 <Ariadne> by the way, if you like actually signed alpine docker base images, i am now building those with apko at https://ghcr.io/distroless/alpine-base
2022-03-02 22:17:29 <psykose> > is rebuilt nightly from Alpine edge.
2022-03-02 22:17:37 <psykose> that makes it much more up to date than the other edge image :)
2022-03-03 04:51:10 <Ariadne> psykose: going to expand it to v3.15 too
2022-03-03 04:51:18 <psykose> :)
2022-03-03 04:52:56 <boomanaiden154> Looks awesome. Going to begin switching over all my images soon.
2022-03-03 04:53:26 <boomanaiden154> Might also start playing with apko soon too.
2022-03-03 04:53:32 <Ariadne> i wouldn't quite yet
2022-03-03 04:53:56 <Ariadne> we want to add a few features that are likely to ruin your day
2022-03-03 04:54:04 <Ariadne> namely, root/non-root variants
2022-03-03 04:54:10 <Ariadne> with default being non-root
2022-03-03 04:55:26 <boomanaiden154> Breaking changes do definitely add a level of frustration. Non-root building would be cool. I’m assuming apko is by default unprivileged (like kaniko)?
2022-03-03 04:55:39 <psykose> it requires root or fakeroot+fakechroot to run
2022-03-03 04:55:46 <psykose> and fakechroot is not packaged in alpine
2022-03-03 04:55:47 <psykose> i tried
2022-03-03 04:55:53 <psykose> i gave up after an hour, maybe another day
2022-03-03 04:56:22 <Ariadne> boomanaiden154: unfortunately not, it needs chroot(2) access
2022-03-03 04:56:53 <Ariadne> boomanaiden154: can probably do something with `proot`
2022-03-03 04:59:16 <boomanaiden154> I might have to experiment with that at some point. Having fast unprivileged image building would be awesome.
2022-03-03 05:02:32 <psykose> somehow i can't run anything with proot
2022-03-03 06:01:20 <Ariadne> i think it is because linux-edge disallows ptrace
2022-03-03 06:04:53 <psykose> do you know what the kconfig option is? the existing configs have 0 matches in -lts and -edge
2022-03-03 06:05:01 <psykose> for "PTRACE"
2022-03-03 06:06:02 <psykose> config_ftrace is off while on in lts
2022-03-03 06:14:00 <ikke> Ariadne: am I understanding the point of apko correctly that you first create packages that contain everything you need, and then use apko to turn that into an image?
2022-03-03 06:14:47 <psykose> yes
2022-03-03 06:26:56 <ikke> The readme mentions crane, but cannot find anything about it. I guess they still have the release it
2022-03-03 12:51:13 <Hello71> i'm pretty sure turning off ptrace is not a standard kernel option
2022-03-03 14:11:04 <Ariadne> ikke: crane is part of go-containerregistry
2022-03-03 14:15:26 <Ariadne> Hello71: i don’t think it’s turned off entirely, but some major feature is disabled due to some setting by mps.  this came up for me last year but i’ve slept since then and just went back to using lts kernel
2022-03-03 14:47:23 <Ariadne> ikke: we have a nice replacement to abuild in the works that is designed to be cloudy :)
2022-03-03 14:47:48 <Ariadne> (not crane, crane is basically google's replacement for docker image management in k8s)
2022-03-03 14:53:36 <fcolista> is anyone here using strongswan site-to-site and awall?
2022-03-03 14:54:18 <fcolista> I'm struggling on understand how to setup the fw to allow the two lan subnets between the endpoint talk each other...
2022-03-03 14:54:34 <fcolista> i've enabled ipsec on external iface 
2022-03-03 14:54:53 <fcolista> ipsec tunnel is fine, if i disable the fw, the two subnets communicate each other
2022-03-03 17:08:08 <wyk72> hello
2022-03-03 17:08:31 <wyk72> I have an humble  request for the package qemu
2022-03-03 17:09:02 <wyk72> can you add the package "liburing-dev" to the list of dependencies ?
2022-03-03 17:09:32 <wyk72> with this added one can experiment with the option -aio=io_uring
2022-03-03 17:09:39 <wyk72> in qemu
2022-03-03 17:09:50 <ikke> wyk72: maybe open an issue or merge request
2022-03-03 17:09:53 <ikke> to request this
2022-03-03 17:09:53 <wyk72> without it the binary omits the option entirely
2022-03-03 17:40:09 <psykose> simply adding the option doesn't seem to work
2022-03-03 17:40:24 <psykose> the dep*
2022-03-03 17:40:39 <psykose> i would convert this to the new meson version first, then see
2022-03-03 17:47:47 <wyk72> I added it and I have a binary with aio=io_uring working (qemu 6.1.0)
2022-03-03 17:47:55 <wyk72> qemu-nbd too
2022-03-03 17:48:22 <wyk72> v3.15 aports tree
2022-03-03 17:51:32 <psykose> hm
2022-03-03 17:51:36 <psykose> oh right
2022-03-03 17:51:40 <psykose> i'm silly
2022-03-03 17:51:46 <psykose> it does static first
2022-03-03 17:51:48 <psykose> sure
2022-03-04 05:05:27 <smcavoy>  fcolista: you could check if the packets are being received on the other side of the tunnel.  That would at least help narrow things down to which awall config has an errant rule
2022-03-04 07:14:29 <fcolista> smcavoy, appars that the issue was/is masquerading. All packets exiting from external iface are masqueraded, so i had to exclude the destination network from masq.
2022-03-04 07:17:20 <fcolista> which I'm able to do with iptables, but not with awall :)
2022-03-04 07:18:29 <fcolista> https://git.alpinelinux.org/awall/about/ states about ipsec in zone, which i set to false on external iface. If i set this on one side of the tunnel, it works one way. When apply the same on the other side, it stops working. So, basically, I don't understand...
2022-03-04 07:56:08 <smcavoy> fcolista: not sure if strongswan ipsec creates a seperate interface for ipsec traffic.. I *think* not. *perhaps* with awall two zones would be created with the same interface but one with ipsec true and one false? This way you would have seperate rules for ipsec traffic / external traffic..?
2022-03-04 07:59:27 <fcolista> no, strongswan does not use a separate interface. I can see that if i set ipsec:false on both interface, traffic is correctly encapsulated. 
2022-03-04 07:59:47 <fcolista> but I does not return. Works one-way only
2022-03-04 08:13:23 <smcavoy> do you have zones created for oppposite ends of the ipsec tunnels? as in you apply rules to an ipsec specific zone instead of the external zone?
2022-03-04 08:14:17 <fcolista> yes
2022-03-04 08:14:35 <fcolista> i've inet zone, with eth0 having the public ip interface
2022-03-04 08:14:45 <fcolista> then i've inet_vpn zone
2022-03-04 08:15:01 <fcolista> inet_vpn zone has ipsec:true, inet_zone has ipsec:false
2022-03-04 08:15:49 <fcolista> (same settings on both endpoints)
2022-03-04 08:17:31 <fcolista> I mean, with iptables is quite easy: iptables -t nat -A POSTROUTING -o eth0 ! -d $DEST_NET -j MASQUERADE
2022-03-04 08:44:46 <smcavoy> so packets from siteA to siteB are SNAT'd to the address of the internal interface of siteA and are seen at siteB as that internal address and not that of the actual sending device? 
2022-03-04 08:49:58 <fcolista> Without that SNAT rule, the default is: MASQUERADE *everything* that exit from eth0
2022-03-04 08:50:28 <fcolista> so, the internal subnet of SiteA does *not* reach the other side of the tunnel
2022-03-04 08:50:45 <fcolista> actually, the traffic is not going to be encapsulated in ipsec at all
2022-03-04 08:57:48 <smcavoy> it *looks* like snat has to be explicitly set per zone. so only inet_zone would set. not sure how that translates to the actual iptable rules specifically, how awall handles applying snat to the external zone for all sources except those in a zone with the same interface as external but ipsec enabled
2022-03-04 08:58:34 <fcolista> but what happens if the inet_zone and inet_vpn are the same physical iface?
2022-03-04 09:02:14 <nico78> Hi all, I've recently started using Alpine (great stuff!) and I have a need to run pimd (https://github.com/troglobit/pimd) so I attempted to create a APK package for this. I'm looking for some 'guidance' to finish this so that it can be shared with others.
2022-03-04 09:02:25 <nico78> At this moment I effectively have: APKBUILD, pimd.confd and pimd.initrd. It's a bit rough but it builds (pimd, -openrc and -doc) packages, they install and work.
2022-03-04 09:04:51 <smcavoy> my thought was that the use of the ipsec attribute in the zone would allow for an interface to be used more than once..
2022-03-04 09:09:18 <fcolista> let me try
2022-03-04 09:10:59 <smcavoy> nico78: open a merge request at https://gitlab.alpinelinux.org/ (you will need an account, you can sign up there as well). A merge request will allow for builds across platforms to be run and others can comment on the specifics of the merge requests (changes to APKBUILD/initd files/etc)
2022-03-04 09:11:50 <smcavoy> you can see all the open MR (merge requests) here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests
2022-03-04 09:15:13 <ikke> nico78: maybe you can make a draft merge request for the package so that we can have a look? 
2022-03-04 09:15:36 <ikke> Oh, what smcavoy said
2022-03-04 09:18:55 <nico78> ok - I have created an account and I can see the merge requests.
2022-03-04 09:19:40 <nico78> My files are not yet in git - should I create new project and commit them there?
2022-03-04 09:20:16 <smcavoy> nico78: clone https://gitlab.alpinelinux.org/alpine/aports 
2022-03-04 09:20:19 <psykose> fork aports, push to a new branch in your fork
2022-03-04 09:20:30 <psykose> mr that branch into aports master
2022-03-04 09:20:31 <psykose> :)
2022-03-04 09:21:12 <smcavoy> err... right .. fork.. 
2022-03-04 09:33:57 <nico78> git clone is done - now I have a nice big aports dir
2022-03-04 09:35:04 <ikke> In the testing directory you can create a new directory with the name of the package 
2022-03-04 09:38:39 <nico78> ok. Copied the files to testing/pimd , ran git add -A, git commit -m "...."
2022-03-04 09:39:03 <ikke> See commitstyle.md
2022-03-04 09:40:54 <ikke> Did you also create a dedicated branch? 
2022-03-04 09:47:39 <nico78> I did not create a branch
2022-03-04 09:49:39 <psykose> you should
2022-03-04 09:49:46 <psykose> also make sure you forked it as internal and not private
2022-03-04 09:50:19 <ikke> psykose: each hour a job runs that should make it public 
2022-03-04 09:50:36 <psykose> not in my experience? idk
2022-03-04 09:50:44 <psykose> there's people i've seen around multiple times that did not have visible ci
2022-03-04 09:50:57 <psykose> until i told them to change it
2022-03-04 09:51:05 <psykose> definitely over an hour
2022-03-04 09:51:08 <psykose> weeks in some cases
2022-03-04 09:51:33 <ikke> Hmm, let me know if you see it again 
2022-03-04 09:51:40 <psykose> sure thing
2022-03-04 09:51:47 <psykose> it happens basically every single time for me lol
2022-03-04 09:52:00 <psykose> along with not being able to rebase the branch even when non-master
2022-03-04 09:52:07 <ikke> It only does it for direct forks of aports 
2022-03-04 09:52:16 <psykose> ah
2022-03-04 09:52:24 <ikke> Yes, that's a known bug 
2022-03-04 09:52:35 <ikke> Which is why we make it public 
2022-03-04 09:52:46 <psykose> are all those things caused by non-direct fork
2022-03-04 09:52:48 <psykose> i didn't even think of that
2022-03-04 10:03:48 <nico78> https://gitlab.alpinelinux.org/ndh/aports/-/commit/ca6a32343c8b039030372ab5fc2bd7c0067d3a6b
2022-03-04 10:04:18 <ikke> Now you can make a merge request from thy PIMD branch
2022-03-04 10:04:49 <ikke> https://gitlab.alpinelinux.org/ndh/aports/-/merge_requests/new?merge_request%5Bsource_project_id%5D=1769&merge_request%5Bsource_branch%5D=pimd&merge_request%5Btarget_project_id%5D=1&merge_request%5Btarget_branch%5D=master
2022-03-04 10:05:21 <psykose> thy :p
2022-03-04 10:05:34 <psykose> royal branch
2022-03-04 10:05:49 <nico78> It is not ready for merging just yet :) I'm looking for some guidance to get there - should I create the merge request at this stage?
2022-03-04 10:05:55 <psykose> yeah that's fine
2022-03-04 10:05:59 <nico78> ok
2022-03-04 10:06:06 <ikke> psykose: thy / thee was the not-formal form of you :)
2022-03-04 10:06:20 <psykose> :)
2022-03-04 10:06:28 <psykose> and now it's backwards
2022-03-04 10:07:43 <ikke> nico78: good: !31637
2022-03-04 10:09:47 <nico78> yay! it did something!
2022-03-04 10:46:03 <nico78> If I fix something locally and commit / push that back to my pimd branch, how do I reflect that in the merge request? (or shoud I do this in an other way?)
2022-03-04 10:49:48 <psykose> it updates itself
2022-03-04 10:49:54 <psykose> the mr tracks your branch
2022-03-04 10:50:09 <psykose> though you should amend your `new aport` commit
2022-03-04 10:50:21 <psykose> in the end there should only be one
2022-03-04 10:51:49 <ikke> (in the case that you add a new package)
2022-03-04 10:55:37 <psykose> yep
2022-03-04 10:58:40 <fcolista>    
2022-03-04 11:54:20 <nico78> @psykose - All items are resolved. I'd like to stick to the latest GIT version for now (older 2.3.2 'stable' does not build without some work and missing libs)
2022-03-04 11:55:02 <nico78> Thanks for the feedback - much appreciated
2022-03-04 15:28:26 <fcolista> mps, nftables has added examples dir that does create some issue with building atm
2022-03-04 15:53:48 <donoban> fcolista: he is not in the channel
2022-03-04 16:01:20 <fcolista> yeah, I talked with him in commits
2022-03-04 16:01:22 <fcolista> thanks donoban 
2022-03-04 16:02:22 <donoban> nice
2022-03-04 19:28:20 <bl4ckb0ne> psykose: upgraded vkd3d to 1.3 in !30599, if you could take a quick look pls
2022-03-04 19:28:46 <bl4ckb0ne> also if anybody could merge it please, that would be very appreciated 
2022-03-04 19:33:41 <bl4ckb0ne> welp, failed pipeline anyway
2022-03-04 19:44:19 <ikke> quite some tests failing
2022-03-04 19:45:00 <bl4ckb0ne> run fine on my end but not with rootbld, investigating it
2022-03-04 19:45:08 <bl4ckb0ne> probably something about connecting to a display
2022-03-04 19:46:49 <bl4ckb0ne> xvfb-run doesnt seems to do anything
2022-03-04 19:56:27 <bl4ckb0ne> apparently it needs vulkan to run tests
2022-03-04 19:57:54 <ikke> unfortunate
2022-03-04 19:58:13 <bl4ckb0ne> should I disable them?
2022-03-04 19:58:41 <ikke> I guess, don't think we will have vulkan support on the builders
2022-03-04 19:59:14 <bl4ckb0ne> might be worth checking lavapipe in the future
2022-03-04 20:06:55 <bl4ckb0ne> pipeline fixed
2022-03-05 01:07:32 <psykose> bl4ckb0ne: lgtm
2022-03-05 01:24:09 <bl4ckb0ne> ty
2022-03-05 01:24:22 <bl4ckb0ne> ill try to package the vulkan-swrast sometime soon to reactivate the tests
2022-03-05 03:59:27 <minimal> psykose: tried to build using that binutils patch - problem is rng-tools is not using the new binutils package, even after I added binutils to its makedepends
2022-03-05 03:59:55 <psykose> you didn't add a version constraint
2022-03-05 04:00:16 <minimal> didn't think that was needed, ok, will try that now
2022-03-05 04:00:21 <psykose> usually not
2022-03-05 04:00:31 <psykose> but for something that is part of build-base, i think you do
2022-03-05 04:00:54 <psykose> or downgrades (though that doesn't apply here of course)
2022-03-05 04:11:47 <psykose> minimal: well would you look at that
2022-03-05 04:11:52 <psykose> it works :p
2022-03-05 04:12:10 <minimal> yupe, I was expecting/hoping for that
2022-03-05 04:12:11 <psykose> you can convert the mr to just the patch backport
2022-03-05 04:12:47 <minimal> the binutils conversation also mentioned a gcc bug that the binutils patch is sort of working around
2022-03-05 04:12:54 <psykose> mm
2022-03-05 04:13:28 <minimal> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104090
2022-03-05 04:14:20 <psykose> this looks like it was in gcc-11 at.. february?
2022-03-05 04:14:33 <psykose> but ours is git20220219
2022-03-05 04:14:38 <psykose> hm
2022-03-05 04:14:50 <psykose> let me check
2022-03-05 04:15:42 <psykose> yeah, that diff is in our tree
2022-03-05 04:16:02 <psykose> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104090#c3 the thing from here
2022-03-05 04:16:13 <psykose> edge gcc has this already
2022-03-05 04:16:23 <psykose> and it's still broken
2022-03-05 04:17:40 <minimal> yeah from my limited understanding I wasn't convinced of a direct linkage between the binutils fix and the gcc one.
2022-03-05 04:18:03 <psykose> just backport the binutils fix i guess
2022-03-05 04:18:10 <psykose> i think i saw it break something else on ppc too
2022-03-05 04:18:17 <minimal> anyway progress - I'll sort out MR for just the binutils patch and let someone like Ariadne make a call on it
2022-03-05 04:18:21 <psykose> mhm
2022-03-05 04:18:38 <minimal> I guess it will break anything related to "optional" opcodes
2022-03-05 04:19:32 <psykose> i will let ariadne decide
2022-03-05 04:41:07 <Ariadne> seems fine to me
2022-03-05 04:43:00 <minimal> cool
2022-03-05 08:18:22 <smcavoy> fcolista: did you sort out the ipsec/awall issue?
2022-03-05 08:19:01 <fcolista> hi smcavoy ! 
2022-03-05 08:19:04 <fcolista> Thanks for asking
2022-03-05 08:19:08 <fcolista> yes, partially
2022-03-05 08:19:35 <fcolista> at the moment I've the two subnets being able to communicate each other withing the ipsec tunnel
2022-03-05 08:19:47 <fcolista> but they are unable to go to internet
2022-03-05 08:19:59 <fcolista> actually, only one of the two subnets have this issue
2022-03-05 08:20:45 <fcolista> I know why on one side works and why on another not
2022-03-05 08:20:46 <ikke> forwarding is enabled on the interface?
2022-03-05 08:20:50 <ikke> oh ok
2022-03-05 08:21:07 <fcolista> yes they are lxc containers used to work
2022-03-05 08:21:30 <fcolista> https://tpaste.us/
2022-03-05 08:21:36 <fcolista> this is the side that is working
2022-03-05 08:21:47 <fcolista> of course, this is due to the MASQUERADE rule
2022-03-05 08:21:48 <ikke> that's just the home page
2022-03-05 08:21:55 <fcolista> https://tpaste.us/d4ax 
2022-03-05 08:21:59 <fcolista> sorry wrong paste 
2022-03-05 08:22:46 <ikke> So the masquerade is too broad?
2022-03-05 08:22:49 <fcolista> and this is the one that is not working
2022-03-05 08:22:49 <fcolista> https://tpaste.us/4o5J 
2022-03-05 08:23:26 <fcolista> ikke, well, no. It's ok since it matches the policy that *is not* ipsec
2022-03-05 08:23:33 <fcolista> which is what I want actually
2022-03-05 08:24:09 <fcolista> Routers should not masq the traffic between the two lan segments 192.168.x.y/24
2022-03-05 08:24:28 <ikke> only to the WAN, right?
2022-03-05 08:24:28 <fcolista> but 19.168.x.y should be masq'ed when they have to reach internet
2022-03-05 08:24:34 <fcolista> correct
2022-03-05 08:24:42 <ikke> sounds a lot like our dmvpn setup
2022-03-05 08:24:58 <fcolista> but here you have gre iface
2022-03-05 08:25:03 <fcolista> here is not
2022-03-05 08:25:08 <fcolista> you have only one internet iface
2022-03-05 08:25:19 <ikke> ok
2022-03-05 08:25:20 <fcolista> *there
2022-03-05 08:25:40 <fcolista> "snat": [ { "out": "INET", "to-addr":"192.168.100.0/24", "action": "exclude" } ]
2022-03-05 08:26:01 <fcolista> this should do the trick
2022-03-05 08:26:32 <fcolista> and as smcavoy suggested, I've
2022-03-05 08:26:32 <fcolista>   "zone": {                                        
2022-03-05 08:26:32 <fcolista>   },
2022-03-05 08:26:32 <fcolista>     "VPN": { "iface": "eth0", "addr": "192.168.50.0/24", "ipsec": "true" } 
2022-03-05 08:26:58 <fcolista> the two subnets as you guessed are 192.168.50.0/24 (local) and 192.168.0.100/24 (remote)
2022-03-05 08:27:17 <fcolista> in the other endpoint, it's the other way round of course
2022-03-05 08:28:16 <fcolista> i've just defined INET interface to eth0 (iface having the public IP)
2022-03-05 08:28:32 <fcolista> and accept the ipsec traffic from INET interface.
2022-03-05 08:28:38 <fcolista> That's all. No other snat rules.
2022-03-05 08:29:16 <ikke> Yeah, you only want snat for the external interface
2022-03-05 08:29:21 <fcolista> only the one you see. Still, awall on one side MASQ the traffic correctly, on another side not. And this is where I'm banging my head.
2022-03-05 08:29:50 <ikke> Did you compare the nat table rules?
2022-03-05 08:30:03 <fcolista> I've not found as yet from where the MASQ https://tpaste.us/d4ax  comes from
2022-03-05 08:30:31 <fcolista> ikke, yes. I checked on /etc/iptables/rules-save each time i run awall translate
2022-03-05 08:30:40 <ikke> fcolista: that seems to be a static rule
2022-03-05 08:30:46 <ikke> I see you have enabled the isolated chains on awall
2022-03-05 08:30:59 <ikke> so awall does not touch the POSTROUTING chain itself
2022-03-05 08:31:19 <fcolista> I did it due to docker
2022-03-05 08:31:24 <ikke> yes, makes sense
2022-03-05 08:31:33 <fcolista> otherwise docker messup the iptables rules
2022-03-05 08:31:37 <fcolista> and i had to "awall_dedicated_chains": "true"
2022-03-05 08:31:44 <ikke> That's exactly the reason why kunkku added that
2022-03-05 08:31:45 <fcolista> but i did it on both endopoints
2022-03-05 08:31:52 <fcolista> exactly
2022-03-05 08:31:59 <ikke> But that rule is left behind it seems
2022-03-05 08:32:02 <ikke> awall does not clean it up
2022-03-05 08:32:16 <ikke> Did you try manually removing it?
2022-03-05 08:32:20 <fcolista> 1723  142K MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            policy match dir out pol none
2022-03-05 08:32:20 <fcolista>   994 71192 awall-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0   
2022-03-05 08:32:30 <fcolista> this one is actually the side the *is working*
2022-03-05 08:32:34 <ikke> hmm
2022-03-05 08:32:36 <ikke> ok
2022-03-05 08:32:53 <ikke> did you chgeck the awall-POSTROUTING chain on both?
2022-03-05 08:32:55 <fcolista> so the issue is that i *don't* ahve this rule on the other place
2022-03-05 08:32:58 <fcolista> yes
2022-03-05 08:33:00 <fcolista> is the same
2022-03-05 08:33:22 <fcolista> it's just one line
2022-03-05 08:33:22 <fcolista> Chain awall-POSTROUTING (1 references)
2022-03-05 08:33:22 <fcolista>  1054 72922 ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0   
2022-03-05 08:33:22 <fcolista>  pkts bytes target     prot opt in     out     source               destination         
2022-03-05 08:33:48 <fcolista> ^ this is the side the is *not working*
2022-03-05 08:33:49 <fcolista> Chain awall-POSTROUTING (1 references)
2022-03-05 08:33:49 <fcolista>  pkts bytes target     prot opt in     out     source               destination         
2022-03-05 08:33:49 <fcolista>     1    84 ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0 
2022-03-05 08:33:53 <ikke> Ok, so awall is not applying the masquerade rule
2022-03-05 08:33:56 <fcolista> This is the side the *is working*
2022-03-05 08:33:58 <fcolista> exaclty
2022-03-05 08:34:13 <fcolista> but I don't know why as first, and where i've set this masq rule
2022-03-05 08:34:14 <ikke> can you check `awall dump 5`
2022-03-05 08:34:16 <fcolista> from where it comes
2022-03-05 08:34:32 <fcolista> because the only snat rule i have is the one i pasted before
2022-03-05 08:34:37 <ikke> If there is an Snat rule?
2022-03-05 08:34:38 <fcolista> lemem check
2022-03-05 08:34:53 <ikke> https://tpaste.us/MkO7 
2022-03-05 08:35:17 <fcolista> same
2022-03-05 08:35:18 <fcolista> peach:/etc/iptables# awall dump 5 | grep -i snat
2022-03-05 08:35:18 <fcolista> Snat 1                        {"action":"exclude","out":"E","to-addr":"192.168.100.0\/24"}
2022-03-05 08:35:24 <fcolista> and:
2022-03-05 08:35:24 <fcolista> bowser:/etc/awall/optional# awall dump 5 | grep -i snat
2022-03-05 08:35:24 <fcolista> Snat 1                        {"action":"exclude","out":"E","to-addr":"192.168.50.0\/24"}
2022-03-05 08:35:36 <ikke> but isn't that just an exclude rule?
2022-03-05 08:36:08 <fcolista> yes. I don't know from where the MASQ rule comes.
2022-03-05 08:36:46 <fcolista> ...who makes the thing works, moreover.
2022-03-05 08:37:03 <ikke> Did you try just something like: "snat": [ {"out": "INET"} ]
2022-03-05 08:37:05 <ikke> ?
2022-03-05 08:37:17 <fcolista> I did it after the exclude rule
2022-03-05 08:37:26 <ikke> fcolista: it makes things work by disabling masquerading I guess
2022-03-05 08:37:27 <fcolista> but didn't worked
2022-03-05 08:37:45 <fcolista> ikke, i suppose that too.
2022-03-05 08:37:58 <fcolista> let me remove it manually
2022-03-05 08:38:17 <fcolista> ok, removed
2022-03-05 08:38:17 <ikke> fcolista: maybe you can add a source range as well to that snat rule
2022-03-05 08:38:30 <ikke> or source zone
2022-03-05 08:38:44 <ikke> not sure if that makes sense for snat
2022-03-05 08:39:12 <fcolista> ok, without that masq rule, containers are not able to reach internet
2022-03-05 08:39:19 <fcolista> now on both sides
2022-03-05 08:40:01 <ikke> And you say if you add just "snat": [ {"out": "INET"} ], it breaks ipsec?
2022-03-05 08:40:31 <ikke> are the containers setting up the ipsec tunnels?
2022-03-05 08:40:37 <ikke> or the host
2022-03-05 08:40:40 <fcolista> no. I'm saying that this snat rule allows the container to reach internet
2022-03-05 08:40:56 <fcolista> "are the containers setting up the ipsec tunnels?" what you mean?
2022-03-05 08:41:31 <ikke> You say that if you manually add that MASQUERADE rule, it works as expected
2022-03-05 08:41:43 <ikke> so I wonder why you cannot then just apply that rule, without anything else
2022-03-05 08:41:56 <fcolista> that one avoid ipsec to work
2022-03-05 08:42:13 <fcolista> containers on both sides are unable to reach each other
2022-03-05 08:44:06 <ikke> I wonder why. THat traffic should not go over the public interface, so I epect no masquerading needed
2022-03-05 08:44:28 <fcolista> the ipsec traffic goes actually toward the public interface
2022-03-05 08:44:49 <ikke> is the host setting up the ipsec traffic, or are individual containers doing that?
2022-03-05 08:45:00 <fcolista> if i ping the ip in the internal subnet, i see traffic on external interface on udp/500
2022-03-05 08:45:03 <ikke> the ipsec tunnel
2022-03-05 08:45:14 <fcolista> host 
2022-03-05 08:45:18 <ikke> Yes, it makes sense the ipsec traffic itself goes over the public interface
2022-03-05 08:45:20 <fcolista> not container rules
2022-03-05 08:45:29 <ikke> but the container traffic should first hit the ipsec interface
2022-03-05 08:45:37 <fcolista> there's no ipsec interface
2022-03-05 08:46:18 <fcolista> it's not like dmvpn where you can play with gre+ or the old-fashioned ipsec0 iface
2022-03-05 08:47:00 <ikke> How is it distinguished between traffic going to the public internet and the ipsec tunnel?
2022-03-05 08:47:09 <ikke> ie, private lan
2022-03-05 08:47:19 <ikke> or WAN I must say
2022-03-05 08:47:55 <fcolista> with awall, there's this ipsec zone that I'm struggling to understand
2022-03-05 08:47:58 <fcolista> "If used, the ipsec attribute is used to exclude from the zone any traffic that is or is not subject to IPsec processing. If set to true in the in zone, only the packets subject to IPsec decapsulation are considered originating from the zone. In the out zone, only the packets subject to IPsec encapsulation will be included if ipsec is set to true. The value of false would exclude any traffic requiring IPsec processing towards the respective 
2022-03-05 08:47:58 <fcolista> direction."
2022-03-05 08:48:04 <fcolista> From: https://github.com/alpinelinux/awall/blob/master/README.md
2022-03-05 08:48:19 <fcolista> I read it 20 times, and still i've not being able to understand it
2022-03-05 08:48:23 <ikke> fcolista: is it based on route level or something like that?
2022-03-05 08:48:51 <fcolista> no, it's based on ipsec stack within the kernel 
2022-03-05 08:49:09 <fcolista> you see that with ip xfrm or swanct tool
2022-03-05 08:49:16 <fcolista> there are no routing tables for ipsec
2022-03-05 08:49:25 <fcolista> i mean
2022-03-05 08:49:32 <fcolista> there are no routing table you can see with ip route
2022-03-05 08:49:51 <ikke> ok
2022-03-05 08:52:41 <ikke> fcolista: I think what it means is that attributes toggles whether ipsec traffic is or is not considered part of the zone
2022-03-05 08:53:54 <fcolista> I don't understand how to apply that :D
2022-03-05 08:55:38 <ikke> So there are 2 scenarios (depending on where the zone is used in a rule)
2022-03-05 08:56:54 <ikke> If the zone is used in the 'out' attribute, and ipsec is set to true, I understand it will only consider internal traffic (ie, needing ipsec encapsulation) part of that zone
2022-03-05 08:57:38 <ikke> if the zone is used in the 'in' attribute, and ipsec is set to true, it should only consider external traffic part of the zone (ie, it needs ipsec decapsulation)
2022-03-05 08:59:18 <ikke> I have no good understanding of how ipsec tunneling is working in this situation, though
2022-03-05 09:09:37 <ikke> I would expect ipsec traffic to have the source address of the external interface, and not use masquerading
2022-03-05 09:17:24 <smcavoy> and the containers are lxc containers with their own "network", an interface managed by lxd (lxdbr0), is that correct? 
2022-03-05 09:20:10 <fcolista> ikke, right
2022-03-05 09:20:33 <fcolista> masq must not be used for lan ip within tunnel
2022-03-05 09:22:01 <ikke> fcolista: just to be clear, with that manual MASQUERADE rule, does everything work as expected, or is the ipsec traffic then not working?
2022-03-05 09:22:32 <fcolista> with the MASQUERADE rule (that I've not inserted, but for some reasons appear), it works :-/
2022-03-05 09:23:17 <ikke> But you added a some policy to that rule?
2022-03-05 09:23:29 <fcolista> bah. That must be a refuse, ikke. 
2022-03-05 09:23:54 <ikke> refuse instead of exclude?
2022-03-05 09:24:27 <fcolista> correct. THat MASQ appeared and I don't know  why (Which allow the container to work). But now I've cleaned up awall and iptables, this rule does not appear.
2022-03-05 09:24:39 <fcolista> So, in this scenario, tunnel works, but containers cannot reach internet
2022-03-05 09:24:42 <fcolista> on both sides
2022-03-05 09:29:53 <ikke> fcolista: so if you do: iptables -t nat -I POSTROUTING 1 --out eth0 -m policy --pol none --dir out -j MASQUERADE 
2022-03-05 09:29:55 <ikke> then it works?
2022-03-05 09:30:00 <ikke> (or somehting like that)
2022-03-05 09:30:35 <fcolista> let me try
2022-03-05 09:31:12 <ikke> (that tries to recreate the rule that you showed earlier)
2022-03-05 09:31:28 <fcolista> it works
2022-03-05 09:31:39 <fcolista> that was the rule i had before
2022-03-05 09:31:41 <fcolista> exactly
2022-03-05 09:31:59 <fcolista> I need to find how to set it with awall :)
2022-03-05 09:32:09 <ikke> Not sure if it supports it, was looking in the source
2022-03-05 09:32:37 <ikke> oh, I see some test rules that show it
2022-03-05 09:32:46 <fcolista> <3
2022-03-05 09:33:40 <ikke> https://gitlab.alpinelinux.org/alpine/awall/-/blob/master/awall/model.lua#L146
2022-03-05 09:34:21 <fcolista> maybe I need to  set ipsec: false
2022-03-05 09:34:36 <ikke> yes
2022-03-05 09:34:40 <ikke> exactly
2022-03-05 09:34:44 <fcolista> (btw: i've found a bug in awall while i as playing with it)
2022-03-05 09:34:59 <ikke> if it's false, it would set --pol none
2022-03-05 09:35:23 <fcolista> "snat": [ { "out": "E", "ipsec": "false" } ]
2022-03-05 09:35:37 <fcolista> i suppose that this is the rule
2022-03-05 09:35:53 <ikke> fcolista: from what I understand, you set it on the zone
2022-03-05 09:36:21 <ikke> Yeah, it's the zone model that this is in
2022-03-05 09:36:46 <ikke> so you would add it to your INET zone
2022-03-05 09:36:59 <ikke> "ipsec": false
2022-03-05 09:37:01 <fcolista> I've found that if I set ipsec: false, tunnel is not going up
2022-03-05 09:37:12 <ikke> on INET?
2022-03-05 09:37:13 <fcolista> let me try agagin.
2022-03-05 09:37:14 <fcolista> Yes
2022-03-05 09:37:16 <ikke> hmm
2022-03-05 09:37:28 <ikke> Can you show the diff before you activate/
2022-03-05 09:37:30 <ikke> awall diff
2022-03-05 09:37:39 <fcolista> yeah absolutely
2022-03-05 09:38:32 <fcolista> https://tpaste.us/EB6W
2022-03-05 09:38:59 <ikke> ok, so it applies to more than you probably want
2022-03-05 09:39:09 <ikke> maybe create a dedicated zone for this?
2022-03-05 09:39:13 <fcolista> yes, it applies it on all the rules
2022-03-05 09:39:27 <fcolista> https://tpaste.us/0W9y
2022-03-05 09:39:31 <fcolista> I've this other rule
2022-03-05 09:41:21 <fcolista> I know that maybe I'm messing up the rules, basically I don't understand how the ipsec/zone interaction works, actually
2022-03-05 09:44:06 <ikke> What I understand is that --pol none basically means it only applies to traffic that is not considered part of the tunnel
2022-03-05 09:44:21 <ikke> so containers trying to reach the internet do not use the IPSEC tunnel
2022-03-05 09:44:21 <fcolista> right. And that's why the masq rule works
2022-03-05 09:44:27 <fcolista> exactly
2022-03-05 09:44:38 <fcolista> now, we need to figure how to translate this to awall :)
2022-03-05 09:44:48 <ikke> so, at least a simple fix / workaround is to have a dedicated zone
2022-03-05 09:44:53 <ikke> INET-EXT or whatever
2022-03-05 09:44:57 <ikke> and set ipsec to false there
2022-03-05 09:45:01 <fcolista> https://tpaste.us/0W9 
2022-03-05 09:45:06 <ikke> 404
2022-03-05 09:45:07 <fcolista> i've made this zone
2022-03-05 09:45:25 <fcolista> https://tpaste.us/0W9y
2022-03-05 09:45:30 <fcolista> missed one letter :)
2022-03-05 09:45:38 <ikke> :)
2022-03-05 09:46:12 <ikke> fcolista: you want to create a masquerade rule, which only applies to non-ipsec traffic
2022-03-05 09:46:25 <fcolista> yeah
2022-03-05 09:46:26 <ikke> So you need a dedicated zone where ipsec is explicitly set to false
2022-03-05 09:46:27 <fcolista> let me check
2022-03-05 09:46:46 <ikke> And because you use the INET zone for other traffic as well
2022-03-05 09:46:53 <ikke> creating a separate one would make sense to me
2022-03-05 09:46:58 <ikke> at least the easiest way
2022-03-05 09:47:08 <fcolista> umh.
2022-03-05 09:47:20 <ikke> and then: "snat": [{"out": "INET-EXT"}]
2022-03-05 09:47:20 <fcolista> so this is useless
2022-03-05 09:47:21 <fcolista> https://tpaste.us/0W9y
2022-03-05 09:47:30 <ikke> I think so
2022-03-05 09:47:42 <ikke> Because that zone does not apply to the masquerade rule
2022-03-05 09:48:07 <fcolista> ok so
2022-03-05 09:48:39 <fcolista> "snat": [ { "out": "INET", "to-addr":"192.168.100.0/24", "action": "exclude" } ] 
2022-03-05 09:48:43 <ikke> no
2022-03-05 09:49:02 <fcolista> "zone": {
2022-03-05 09:49:02 <fcolista>   },
2022-03-05 09:49:02 <fcolista>     "INET": { "iface": "eth0" }
2022-03-05 09:49:18 <fcolista> those are the rules i've now
2022-03-05 09:49:37 <ikke> step 1: Add INET-EXT
2022-03-05 09:49:37 <fcolista> i need to add:
2022-03-05 09:49:49 <fcolista> "snat": [ { "out": "INET-EXT" } ]
2022-03-05 09:49:53 <ikke> yes
2022-03-05 09:49:55 <fcolista> and:
2022-03-05 09:50:24 <fcolista> "zone": {
2022-03-05 09:50:24 <fcolista>     "INET-EXT": { "iface": "eth0", "ipsec": "false" }
2022-03-05 09:50:24 <fcolista>   },
2022-03-05 09:50:29 <ikke> indeed
2022-03-05 09:51:08 <fcolista> but for security, i need to add also: 
2022-03-05 09:51:13 <fcolista> "policy": [ { "in": "INET-EXT", "action": "drop" } ],
2022-03-05 09:51:29 <ikke> yes
2022-03-05 09:52:31 <fcolista> ok
2022-03-05 09:52:44 <fcolista> let me do it
2022-03-05 09:52:55 <ikke> fcolista: maybe that's redundant, not sure
2022-03-05 09:53:18 <fcolista> i don't know how this is translated into iptables rule, perhaps yes
2022-03-05 09:53:20 <fcolista> i'll check
2022-03-05 09:53:24 <ikke> awall diff
2022-03-05 09:53:27 <ikke> tells you
2022-03-05 09:53:44 <fcolista> at this point, rather than INET, I'll call it VPN
2022-03-05 09:53:49 <fcolista> and INET-EXT, INET
2022-03-05 09:53:53 <fcolista> which is more clear
2022-03-05 09:53:56 <ikke> Right
2022-03-05 09:54:14 <ikke> and then ipsec: true on vpn
2022-03-05 09:54:16 <ikke> VPN
2022-03-05 09:56:14 <fcolista> https://tpaste.us/a07b
2022-03-05 09:57:26 <ikke> You still have an incorrect masquerade rule
2022-03-05 09:57:28 <ikke> +  inet/nat/awall-POSTROUTING  -o eth0 -m policy --dir out --pol ipsec -j MASQUERADE
2022-03-05 09:57:36 <ikke> You have 2
2022-03-05 09:57:37 <fcolista> https://tpaste.us/qad4 
2022-03-05 09:58:23 <fcolista> indeed
2022-03-05 09:58:40 <ikke> +Snat 1                        {"out":"E"}
2022-03-05 09:59:26 <fcolista> that's wrong?
2022-03-05 09:59:27 <fcolista> "E": { "iface": "eth0", "ipsec": "false"  }
2022-03-05 09:59:32 <fcolista> i've this zone set
2022-03-05 10:00:15 <ikke> false
2022-03-05 10:00:19 <fcolista> https://tpaste.us/NOvq 
2022-03-05 10:00:23 <fcolista> this is the rule
2022-03-05 10:00:23 <ikke> note "false"
2022-03-05 10:00:25 <ikke> I think'
2022-03-05 10:00:33 <fcolista> that's the bug i've found
2022-03-05 10:00:39 <ikke> ah ok
2022-03-05 10:00:47 <fcolista> wihtout "", the rule is not applied
2022-03-05 10:00:50 <fcolista> let me check again
2022-03-05 10:03:26 <ikke> It seems to evaluate to true now
2022-03-05 10:04:33 <fcolista> umh..
2022-03-05 10:05:01 <fcolista> something is wrong. No tcp/udp traffic on internet iface
2022-03-05 10:10:06 <fcolista> "ipsec": false on inet interface mess-up the things
2022-03-05 10:10:53 <fcolista> https://tpaste.us/x5Zv 
2022-03-05 10:18:59 <ikke> can you check on what rules that policy is applied now?
2022-03-05 10:21:52 <fcolista> ok ,so
2022-03-05 10:22:57 <fcolista> this is the output of awall dump 5: https://tpaste.us/yvW0
2022-03-05 10:23:07 <fcolista> when I apply this rules: https://tpaste.us/YrJZ 
2022-03-05 10:23:39 <fcolista> with this configuration, containers reach internet, but not the lan subnet on the other side of the tunnel
2022-03-05 10:24:19 <fcolista> ipsec is blocked :-/
2022-03-05 10:24:39 <ikke> -A awall-POSTROUTING -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
2022-03-05 10:24:41 <ikke> -A awall-POSTROUTING -o eth0 -j MASQUERADE
2022-03-05 10:24:47 <ikke> So it's not applied
2022-03-05 10:24:50 <ikke> there
2022-03-05 10:26:04 <fcolista> indeed
2022-03-05 10:26:19 <ikke> -A awall-FORWARD -i eth0 -m policy --dir in --pol ipsec -j awall-logdrop-3 this rule is redundant
2022-03-05 10:26:40 <fcolista> this means that VPN policy DROP actually duplicates the rule
2022-03-05 10:26:52 <ikke> yes
2022-03-05 10:28:05 <ikke> But you need to somehow set ipsec to false
2022-03-05 10:28:17 <fcolista> yeah
2022-03-05 10:28:26 <ikke> any reason you still have this rule? "{"action":"exclude","out":"VPN","to-addr":"192.168.100.0\/24"}"
2022-03-05 10:28:46 <fcolista> not really
2022-03-05 10:30:43 <fcolista> https://tpaste.us/5kjB 
2022-03-05 10:31:06 <fcolista> output of awall dump 5
2022-03-05 10:31:07 <fcolista> https://tpaste.us/vyrB
2022-03-05 10:31:47 <ikke> ok, the masquerade rule now looks ok
2022-03-05 10:31:56 <ikke> -o eth0 -m policy --dir out --pol none -j MASQUERADE
2022-03-05 10:32:09 <fcolista> yes. But traffic for 192.168.x.x is masq'd
2022-03-05 10:33:18 <ikke> hmm, strange, it's the same rule now as you already had
2022-03-05 10:33:30 <fcolista> it works from the host
2022-03-05 10:33:34 <fcolista> but not from the container
2022-03-05 10:34:02 <fcolista> this thing is crazy though
2022-03-05 10:34:31 <fcolista> within the container:
2022-03-05 10:34:32 <fcolista> # traceroute -nI 192.168.100.10
2022-03-05 10:34:32 <fcolista>  1  192.168.50.1  0.008 ms  0.007 ms  0.005 ms
2022-03-05 10:34:32 <fcolista>  2  *
2022-03-05 10:34:32 <fcolista> traceroute to 192.168.100.10 (192.168.100.10), 30 hops max, 46 byte packets
2022-03-05 10:34:49 <ikke> You did add "ipsec": true to the VPN zone now, right?
2022-03-05 10:35:06 <fcolista> yes
2022-03-05 10:35:11 <ikke> what if you remove that
2022-03-05 10:35:16 <fcolista>  "VPN": { "iface": "eth0", "ipsec": true },
2022-03-05 10:36:08 <fcolista> same behavior
2022-03-05 10:36:56 <fcolista> https://tpaste.us/KeOw
2022-03-05 10:37:06 <fcolista> this is the output of awall dump without "ipsec": true
2022-03-05 11:12:40 <ikke> fcolista: can you start with the simple case where you only set ipsec to false for the masquerade rule?
2022-03-05 12:46:38 <Newbyte> Do you understand what's going wrong here: https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/651330#L782
2022-03-05 13:07:31 <ikke> There are no files theeset have been added to the -dev package 
2022-03-05 13:07:45 <ikke> that*
2022-03-05 13:07:48 <psykose> your new subpackage does not call your actual function
2022-03-05 13:07:56 <psykose> i left a comment :)
2022-03-05 13:53:42 <Newbyte> thanks! should be ready now I think 
2022-03-05 14:04:44 <Newbyte> actually, maybe not yet
2022-03-05 14:08:20 <Newbyte> okay, this should be it
2022-03-05 14:12:59 <Newbyte> Is this because I put gtk-vnc in the dependencies of libgvncpulse: https://gitlab.alpinelinux.org/Newbyte/aports/-/jobs/651422#L724
2022-03-05 14:13:34 <Newbyte> That is, does this make it build gtk-vnc first despite that it's after libgvncpulse in the subpackage list and thus it "steals" that file?
2022-03-05 14:15:20 <psykose> the thing you are amove'ing doesn't exist
2022-03-05 14:17:14 <psykose> also i don't understand the point of splitting this subpackage if it just depends on the parent package
2022-03-05 14:17:53 <psykose> when you install gnome-boxes with these changes it will pull in all of gtk-vnc anyway if that library depends on gtk-vnc
2022-03-05 14:18:27 <Newbyte> oh I see why now
2022-03-05 14:19:08 <Newbyte> psykose: e.g. virt-manager depends on gtk-vnc but not libgvncpulse
2022-03-05 14:19:32 <Newbyte> so I thought maybe this could be nice to do
2022-03-05 14:19:47 <Newbyte> but maybe this is more trouble than it's worth 
2022-03-05 14:20:11 <psykose> i would assume it still uses gvncpulse too to play audio, but i'm probably wrong
2022-03-05 14:20:16 <psykose> but yeah, the whole thing is ~450kb anyway
2022-03-05 14:20:44 <psykose> also generally when doing splits like this it's easier to not also split -dev
2022-03-05 14:21:15 <Newbyte> Maybe I should try this without splitting off -dev then?
2022-03-05 14:21:33 <psykose> you could, but overall i don't see much point in it
2022-03-05 14:22:33 <psykose> also the reason that amove failed is you removed pulseaudio-dev so it was never built, i would guess
2022-03-05 14:22:39 <Newbyte> yeah, I realised
2022-03-06 17:58:14 <bl4ckb0ne> psykose: im not done with !31115 
2022-03-06 17:58:26 <psykose> sure, just looked done to me :)
2022-03-06 17:58:31 <psykose> i fixed the rest of it
2022-03-06 17:58:55 <bl4ckb0ne> oh you took care of the hard link with the version number
2022-03-06 17:59:19 <psykose> and rebased it
2022-03-06 17:59:19 <bl4ckb0ne> i guess i cant take care of the spirv stuff and moving out of main in a following mr
2022-03-06 17:59:24 <bl4ckb0ne> o7 ship it 
2022-03-06 17:59:29 <psykose> well i can't :p but yeah
2022-03-06 17:59:48 <bl4ckb0ne> i missed the edits, just saw the "labeled as ready" in my mails
2022-03-06 17:59:53 <psykose> mhm
2022-03-06 18:01:08 <bl4ckb0ne> hm nope it's not ready, there's the crossopts missing
2022-03-06 18:01:26 <psykose> i don't think the crossopts really matter at all as we don't really do much cross compiling
2022-03-06 18:01:35 <bl4ckb0ne> alrighty
2022-03-06 18:01:46 <psykose> the only things that really need them are the things that use cmake in the initial bootstrap chain
2022-03-06 18:01:49 <psykose> which is like 3 things in main
2022-03-06 18:01:51 <bl4ckb0ne> i guess you could approve it so people will know its good
2022-03-06 18:02:00 <bl4ckb0ne> thanks for the edits
2022-03-06 18:02:09 <psykose> not that they harm anything, but i have yet to see someone do a full cross-built alpine
2022-03-06 18:04:00 <psykose> fine, fine, added anyway :)
2022-03-06 18:15:16 <psykose> ikke: you should merge it :p
2022-03-06 18:21:57 <psykose> and !30095
2022-03-06 18:22:00 <psykose> and the 5 expat mrs
2022-03-06 18:31:34 <ikke> bl4ckb0ne: so 31115 is ready?
2022-03-06 19:22:14 <psykose> it is, they said ship it :p
2022-03-06 19:24:56 <psykose> this also has mpv broken in the meantime
2022-03-06 19:26:22 <psykose> hm
2022-03-06 19:26:23 <psykose> actually
2022-03-06 19:37:26 <psykose> the spirv-tools upgrade was wrong i think
2022-03-06 19:37:32 <psykose> needs another one
2022-03-06 19:43:44 <psykose> no, even that doesn't fix it
2022-03-06 19:45:04 <psykose> bl4ckb0ne: both the current and rebuilt .so's can't find some symbols, demangled: https://img.ayaya.dev/SgOvmoopw4Gl
2022-03-06 19:45:54 <psykose> those look like they come from spirv-tools, and glslang/shaderc have not been touched yet, but that .so does not link to anything from spirvtools anyway.. neither does libSPIRV.so
2022-03-06 19:46:02 <psykose> not sure why they are suddenly missing with a spirv-tools upgrade
2022-03-06 19:46:31 <psykose> also spirv-tools should also be 1.3.204.1 with the new sdk versioning
2022-03-06 19:47:33 <psykose> the only thing spirv-tools has is libSPIRV-Tools-shared.so and nothing links to it, yet they are all missing those
2022-03-06 19:48:52 <psykose> those functions to also exist in spirv-tools, and force linking with patchelf doesn't resolve them either
2022-03-06 19:49:01 <psykose> to->do*
2022-03-06 19:54:54 <ikke> psykose: soo.. should I merge 31115 or not/
2022-03-06 19:54:56 <ikke> ?
2022-03-06 19:55:59 <psykose> i have no idea, even if i downgrade everything everything is still broken lol
2022-03-06 19:56:24 <ikke> F.U.N.
2022-03-06 19:58:12 <psykose> i have a few more things to try
2022-03-06 19:58:26 <psykose> i think just a single thing was overlooked
2022-03-06 20:02:26 <psykose> (and you know what caused it? i forgot to double check checkapk again) :)
2022-03-06 20:02:28 <psykose> i fixed it now
2022-03-06 20:02:40 <psykose> do you want to fast merge something first? then it will be the mr above
2022-03-06 20:02:56 <ikke> ok
2022-03-06 20:03:14 <ikke> varnish?
2022-03-06 20:03:34 <psykose> !31730
2022-03-06 20:03:37 <ikke> ok
2022-03-06 20:03:40 <psykose> the issue was the static arg was wrong
2022-03-06 20:03:46 <psykose> everything was built into static instead
2022-03-06 20:03:51 <psykose> but we may as well get the correct version too
2022-03-06 20:04:02 <psykose> after this passes on builders, then the shaderc one above should be merged too
2022-03-06 20:04:23 <psykose> and yeah, the varnish cve
2022-03-06 20:06:36 <psykose> yep, checkapk looks fixed now
2022-03-06 20:06:36 <psykose> hah
2022-03-06 20:07:08 <psykose> cmake is very fun, especially when projects like making their own names for these very standard flags
2022-03-06 20:07:33 <psykose> and with that and the other mr, mpv works again
2022-03-06 20:08:28 <ikke> The version scheme change might give issues though
2022-03-06 20:08:39 <psykose> it won't cause downgrade issues in the same repo
2022-03-06 20:08:44 <psykose> spirv-headers was also downgraded
2022-03-06 20:09:01 <psykose> the old version will be gone- so everything goes to this version
2022-03-06 20:09:04 <ikke> I mean if people have the 2022 version installed
2022-03-06 20:09:08 <psykose> yeah, that's fine
2022-03-06 20:09:17 <psykose> it only fails if they have a local repo 2022
2022-03-06 20:09:42 <psykose> if they only use dl-cdn mirrors and didn't build a local one, the downgrade goes in, because there is no other version anymore
2022-03-06 20:10:02 <ikke> apk does not automatically downgrade
2022-03-06 20:10:22 <psykose> how does every revert downgrade work then?
2022-03-06 20:10:28 <psykose> because all of those work fine all the time
2022-03-06 20:10:32 <psykose> e.g. 0.9.0->0.8.1
2022-03-06 20:10:34 <ikke> hope people use --available when running upgrade
2022-03-06 20:10:36 <psykose> ah
2022-03-06 20:10:49 <psykose> hm
2022-03-06 20:10:54 <psykose> i guess i /do/ always put that..
2022-03-06 20:10:58 <ikke> me too
2022-03-06 20:11:09 <psykose> it should really be the default then
2022-03-06 20:11:17 <psykose> or.. something that allows this form of downgrade
2022-03-06 20:11:18 <psykose> sigh
2022-03-06 20:14:39 <psykose> in any case this does fix it
2022-03-06 20:14:44 <psykose> soo
2022-03-06 20:15:10 <psykose> and hopefully they will not pull another version scheme change on us yet again
2022-03-06 20:15:18 <psykose> to `0.0.realsdk.999` or something
2022-03-06 20:17:42 <ikke> :D
2022-03-06 20:17:45 <psykose> :D
2022-03-06 20:17:49 <psykose> i will eat my words won't i
2022-03-06 21:09:01 <ikke> psykose: why do you use `glslang-static~1.3.204`? afaik, the ~ has no benefit in this case
2022-03-06 21:09:39 <psykose> you mean it's already pulling in 1.3.204 because of the other ~ above it?
2022-03-06 21:10:05 <ikke> no, more that it does the same as '=' when you specify the full version
2022-03-06 21:10:18 <ikke> it's not the ruby ~ oeprator
2022-03-06 21:10:22 <ikke> operator*
2022-03-06 21:10:22 <psykose> ah, sure, i suppose it does
2022-03-06 21:10:26 <psykose> but in that case they both pull that in
2022-03-06 21:10:26 <psykose> hah
2022-03-06 21:10:35 <psykose> i think with = you also need the -r0
2022-03-06 21:10:37 <psykose> unless i forgot
2022-03-06 21:11:09 <ikke> oh, you are right
2022-03-06 21:11:19 <psykose> yeah
2022-03-06 21:11:25 <ikke> ok, good to know
2022-03-06 21:16:47 <psykose> it's the last little mpv piece
2022-03-06 21:18:46 <ikke> should gtest and gmock be added to checkdepends, as you use want_check?
2022-03-06 21:19:58 <psykose> you are correct, let me change it
2022-03-06 21:20:34 <psykose> done
2022-03-06 21:26:27 <psykose> ever since my email showed up in aports i sure get a lot of people wanting to give me billions of dollars
2022-03-06 21:26:50 <psykose> those poor princes
2022-03-06 21:28:53 <ikke> lol
2022-03-06 21:37:14 <lucidiot> i didn't know maintaining alpine packages could get you rich so quick
2022-03-06 21:37:40 <c7s> shh, don't tell everyone
2022-03-06 21:37:47 <psykose> it's a secret
2022-03-06 21:38:10 <psykose> ikke: there is also still the 5 expat mrs :p
2022-03-06 21:39:11 <ikke> Why do you think so many people want to maintain packages?
2022-03-06 21:39:34 <lucidiot> rich people don't want you to share your email online because they want to keep the money to themselves
2022-03-06 22:24:45 <bl4ckb0ne> busy sunday I see psykose :p
2022-03-06 22:24:55 <bl4ckb0ne> spirv-tools switching to vulkan rev is a nightmare
2022-03-06 22:25:08 <psykose> and already done :)
2022-03-06 22:25:11 <psykose> i fixed everything
2022-03-06 22:25:16 <bl4ckb0ne> thanks!
2022-03-06 22:25:34 <bl4ckb0ne> so next moving spirv-* out of main
2022-03-06 22:25:42 <psykose> yep, should be simple enough
2022-03-06 22:25:48 <psykose> just triple-make-sure glslang doesn't need it
2022-03-06 22:25:52 <bl4ckb0ne> and the vulkan swrast for vkd4d
2022-03-06 22:25:54 <bl4ckb0ne> d3d*
2022-03-06 22:25:57 <psykose> mhm
2022-03-06 22:25:59 <bl4ckb0ne> yeah ill run it
2022-03-06 22:47:20 <boomanaiden154> Is anyone here on aarch64 that is willing to make sure that the chromium upgrade in !31659 works properly?
2022-03-06 23:45:06 <zv> on ppc64le, how long does the libtool test suite take on alpine's builders? absurdly long compared to other platforms or?
2022-03-06 23:46:06 <psykose> they are currently disabled
2022-03-06 23:46:31 <psykose> but i could give it a run on the ci which is almost the same, if you want to see the time
2022-03-06 23:49:01 <zv> psykose: that'd be great, thanks!
2022-03-06 23:49:39 <psykose> !31739
2022-03-06 23:50:40 <psykose> they were disabled a week after being enabled in 2018
2022-03-06 23:50:47 <psykose> also note the excluded tests in there
2022-03-06 23:50:56 <psykose> `make check TESTSUITEFLAGS="1-69 71-116 118-169"`
2022-03-06 23:51:56 <psykose> 170 appears to be a repeat of all of them given the comment: `# Test 170 repeats the entire test suite with shorter max_cmd_len`
2022-03-06 23:52:53 <psykose> the CI is apparently power9, while the builders are power8, but they have the same p8 march setting (or so i was told), and in my experience everything takes about the same time on either
2022-03-06 23:53:22 <psykose> (slower than all the other builders/ci, which is quite miserable, aside from the emulated riscv64)
2022-03-07 00:11:35 <psykose> 69 and 102 fail with our toolchain now, and it's about 11m for x86_64 and 22m for ppc64le
2022-03-07 00:45:15 <zv> thank you--mostly in line with what we're seeing. there was a suggestion that `environ` needs to be as small as possible due to poor `exec` performance on ppc64.
2022-03-07 00:46:28 <psykose> perhaps it's sound :) it should be fairly easy to test by just filling it with trash
2022-03-07 01:33:09 <Ariadne> nmeum: revised gcc-go patches queued for a new gcc 11 snapshot
2022-03-07 01:38:16 <psykose> you should also include !31725 and !31303
2022-03-07 01:38:36 <psykose> (just in case you missed them)
2022-03-07 01:42:22 <Ariadne> that's... what i'm talking about
2022-03-07 01:42:49 <psykose> one of them is ppc
2022-03-07 01:43:37 <psykose> oh right, my head completed go as an architecture
2022-03-07 01:43:38 <psykose> fantastic
2022-03-07 01:43:44 <psykose> i hope that does not become reality
2022-03-07 01:45:51 <psykose> my apologies
2022-03-07 02:12:26 <Ellenor> i ate cadmium
2022-03-07 02:12:40 <valerius> great job
2022-03-07 02:13:02 <boomanaiden154> How is this discussion relevant to Alpine package development?
2022-03-07 02:14:10 <psykose> i would recommend seeking medical attention
2022-03-07 02:14:19 <psykose> boomanaiden154: thanks for keeping up with the chromium updates :)
2022-03-07 02:15:25 <boomanaiden154> No problem. It’s been some interesting work to try and fix some of the problems. I might try and file an issue soon on the upstream’s side to look at seeing if it would be possible for me to upstream some of the patches.
2022-03-07 02:15:35 <psykose> yeah
2022-03-07 02:15:35 <boomanaiden154> Because that would make maintenance a whole lot easier.
2022-03-07 02:15:44 <psykose> i hope that works, usually i expect it's not that easy..
2022-03-07 02:15:48 <psykose> given who the upstream is
2022-03-07 02:15:52 <psykose> but i wish you luck :)
2022-03-07 02:16:20 <psykose> i also noticed you are interested in getting the tests to run, which sounds like it would be quite challenging
2022-03-07 02:16:53 <boomanaiden154> Thank you. I’ve seen one thread on switching ChromeOS to musl which understandably didn’t go anywhere, but they seem to be somewhat supportive of different things for Linux Distro packaging.
2022-03-07 02:17:04 <boomanaiden154> And the full patch set is only like 20 or 30 flags or something.
2022-03-07 02:17:13 <psykose> mm
2022-03-07 02:17:15 <psykose> sounds small
2022-03-07 02:17:18 <psykose> that is good :)
2022-03-07 02:17:41 <boomanaiden154> Getting the tests working would be challenging, but it would be great to have that feedback in the CI for future updates.
2022-03-07 02:17:44 <boomanaiden154> Yes.
2022-03-07 02:18:15 <boomanaiden154> Mostly just related to musl’s implantation of resolv being nonstandard and then some other stuff.
2022-03-07 02:18:21 <psykose> yep
2022-03-07 02:18:29 <boomanaiden154> Like I think there’s probably a few backtrace calls in there somewhere.
2022-03-07 02:18:51 <psykose> if only resolv was always an external part to the libc
2022-03-07 02:19:39 <boomanaiden154> Yeah. It would be pretty easy to separate out. (If everyone didn’t already depend on the libc implementations).
2022-03-07 02:19:42 <psykose> mhm
2022-03-07 02:20:16 <psykose> backtrace has the same issue now (i think it was dropped from posix, but is still in glibc, or whatever), and so we carry a ton of patches to -lbacktrace things
2022-03-07 02:20:32 <psykose> or just disable it in some places
2022-03-07 02:21:08 <psykose> but i guess api design is a lot easier when you can imagine changing the past 30 years ago
2022-03-07 02:21:12 <boomanaiden154> I usually just patch it out. Definitely lots of patches for that though.
2022-03-07 02:21:14 <boomanaiden154> Yep.
2022-03-07 02:21:20 <boomanaiden154> Hindsight is always 20/20.
2022-03-07 07:06:45 <nmeum> Ariadne: great, thanks
2022-03-07 08:14:17 <omni> !31735
2022-03-07 08:14:56 <PureTryOut> what about it?
2022-03-07 08:14:59 <psykose> :)
2022-03-07 08:15:01 <psykose> merged too fast
2022-03-07 08:15:34 <omni> haha
2022-03-07 08:17:40 <PureTryOut> I see them appearing in my mailbox, don't worry 😉
2022-03-07 08:18:42 <omni> psykose: thanks for hints and suggestions on !31530 just haven't had time and energy for it yet
2022-03-07 08:18:50 <psykose> take your time :)
2022-03-07 08:19:11 <psykose> i usually don't have energy for anything either
2022-03-07 08:24:17 <ncopa> good morning
2022-03-07 08:24:28 <Daanct12> good morning ncopa 
2022-03-07 08:25:26 <Daanct12> i'm currently out of here with a phone, keyboard and mouse
2022-03-07 08:25:30 <Daanct12> (and a esp8266)
2022-03-07 08:25:58 <psykose> smol
2022-03-07 08:26:28 <Daanct12> smol indeed, i have it plugged to the phone through my usb-c dock :)
2022-03-07 08:26:51 <Daanct12> so the phone is now running hexchat and all of my necessary linux apps
2022-03-07 08:27:20 <ktprograms> Daanct12: what are you using the esp8266 for?
2022-03-07 08:29:16 <Daanct12> as a fake hotspot device for fun, wanted to see unsuspecting people connect to it and see a set of linux memes as captive portal page 
2022-03-07 08:29:36 <ktprograms> lmao
2022-03-07 08:30:04 <psykose> lol
2022-03-07 08:30:10 <ktprograms> Can you program it from the phone or is it just for data/power?
2022-03-07 08:30:19 <psykose> that is the good kind of trolling :)
2022-03-07 08:31:18 <Daanct12> android should be able to handle usb serial, in fact i did interrupt u-boot on my pinenote using just my phone
2022-03-07 08:31:54 <Daanct12> but since this is a linux phone (pinephone pro), it's just.. a linux computer :)
2022-03-07 08:31:58 <psykose> i would imagine the mcu sdk runs fine off a phone too
2022-03-07 08:32:48 <boomanaiden154> Every android phone is sort of a Linux computer too.
2022-03-07 08:33:05 <boomanaiden154> Along with like fridges and espresso machines these days.
2022-03-07 08:33:06 <Daanct12> it should! as long as you got a linux shell, you should be able to do anything you want the linux way
2022-03-07 08:33:21 <ktprograms> Makes sense.
2022-03-07 08:33:35 <Daanct12> i recommend getting root access as it's very handy if you want raw device access
2022-03-07 08:34:53 <Daanct12> maybe i'll upgrade to an actual linux device with large storage if i want to push more memes to a captive portal :)
2022-03-07 08:57:49 <Daanct12> whoops, got disconnected because i accidentally hit the power button :)
2022-03-07 08:57:51 <Daanct12> just moved places
2022-03-07 08:58:10 <psykose> hehe
2022-03-07 08:58:17 <Daanct12> there was no power daemon overriding it, not even upowerd is installed
2022-03-07 08:58:47 <psykose> in my experience on alpine the power button does not work until i edit some files
2022-03-07 08:58:47 <Daanct12> just a basic sway setup :)
2022-03-07 08:58:48 <psykose> hah
2022-03-07 08:59:17 <psykose> namely the acpi handler.sh
2022-03-07 08:59:35 <Daanct12> heh, acpi :)
2022-03-07 08:59:39 <psykose> by default it's PWRN or something, but all of my devices seem to generate PBTN in the middle of the string
2022-03-07 09:00:00 <psykose> did not check the other working options much
2022-03-07 09:04:44 <boomanaiden154> The virtual box power button has always worked for me.
2022-03-07 09:04:58 <boomanaiden154> Never actually done a bare metal install of Alpine though.
2022-03-07 09:07:39 <Daanct12> https://imgur.com/a/FkUwvP4
2022-03-07 09:07:44 <Daanct12> here's my setup :)
2022-03-07 09:07:59 <psykose> mm
2022-03-07 09:08:04 <psykose> i saw the other picture on twitter too
2022-03-07 09:08:05 <psykose> very cute
2022-03-07 09:09:05 <Daanct12> yep, i also posted the other picture on twitter. but it's a prime example of dongle & usb life
2022-03-07 09:10:11 <Daanct12> this was all in the public too as you can tell, there are like at least 10+ people sitting right here
2022-03-07 09:10:19 <psykose> it's actually the least messy dongle setup i've ever seen
2022-03-07 09:10:28 <psykose> props to that :p
2022-03-07 09:11:46 <Daanct12> :)
2022-03-07 09:12:26 <Daanct12> maybe i'll go messier next time
2022-03-07 09:12:33 <psykose> lewd
2022-03-07 09:13:55 <Daanct12> i have yet seeing people looking at me though lol
2022-03-07 12:27:09 <minimal> can someone please merge !31508
2022-03-07 16:41:02 <bl4ckb0ne> anybody managed to use the clang sanitizers? there was a patch that go merged recently about it
2022-03-07 16:41:25 <bl4ckb0ne> also I have `/usr/lib/clang/13.0.1/lib/linux/libclang_rt.asan-x86_64.so` in my system, but never got it to link properly
2022-03-07 18:57:05 <maxice8> ikke: atools 20.1.0 is released
2022-03-07 18:57:25 <maxice8> found some weird bug while testing under NixOS
2022-03-07 19:00:40 <ikke> maxice8: ok
2022-03-08 00:47:24 <psykose> bl4ckb0ne: it always worked for me
2022-03-08 00:47:43 <psykose> afaik all you need is -fsanitize-address
2022-03-08 00:47:46 <psykose> with clang, nothing else
2022-03-08 01:03:27 <bl4ckb0ne> did you managed to run it with meson?
2022-03-08 01:03:43 <bl4ckb0ne> i tried -Db_sanitize=address but i think it omits the flags
2022-03-08 01:05:01 <psykose> i didn't try that, but it doesn't make much sense to omit the flags
2022-03-08 01:05:02 <psykose> hm
2022-03-08 01:05:35 <psykose> could you throw something to reproduce it with
2022-03-08 01:07:17 <psykose> the first thing i tried that with clearly has -fsanitize=address on the compiler invocation with meson
2022-03-08 01:21:51 <bl4ckb0ne> weird
2022-03-08 01:22:32 <psykose> it warns you about some other flag too, like wanting to set -Db_lundef=false
2022-03-08 01:22:35 <psykose> but idk
2022-03-08 01:22:46 <psykose> maybe the meson.build is doing something fancy
2022-03-08 01:55:41 <eletrotupi> Hello! I'm trying to upgrade sway to it's edge version, but (1) apparently apk upgrade sway always try to update every single package installed & (2) firefox and other aports are depending on a newer version of icu that is on edge/main   
2022-03-08 01:56:06 <psykose> you can't mix repos, so you have to upgrade either everything or stay on 3.15
2022-03-08 01:56:34 <eletrotupi> hm, this seems dangerous
2022-03-08 01:57:04 <psykose> less so than mixing repositories where half the things will just be broken :p
2022-03-08 01:57:18 <eletrotupi> hm, right
2022-03-08 01:58:06 <eletrotupi> also, does apk upgrade accepts a single package? the docs mention it, but I don't think I could ever make it work
2022-03-08 01:58:17 <eletrotupi> a single or a list of packages 
2022-03-08 01:58:27 <psykose> i think it does, if you have all the repositories specified
2022-03-08 01:58:34 <eletrotupi> hm
2022-03-08 01:59:17 <eletrotupi> well, I think I'll live on edge now 
2022-03-08 01:59:25 <eletrotupi> until 3.16 
2022-03-08 02:00:19 <psykose> upgrade with --available
2022-03-08 02:06:13 <ktprograms> eletrotupi: apk was probably upgrading all the sway dependencies to edge, that's why it seemed like it was upgrading everything.
2022-03-08 02:33:14 <skarnet> Late night push: !31777
2022-03-08 02:33:55 <psykose> go to sleep laurent
2022-03-08 02:34:00 <skarnet> yes mom
2022-03-08 02:34:09 <psykose> get to it dear
2022-03-08 05:47:45 <ikke> eletrotupi: apk add --upgrade <package> can be used to update a single package 
2022-03-08 06:54:26 <Ariadne> ikke: you can also do `apk upgrade <package>`
2022-03-08 07:52:46 <bratkartoffel> Any estimation if / when the stable (3.15 / 3.14 / 3.13) kernels are upgraded to address the dirtypipes (CVE-2022-0847) vulnerability?
2022-03-08 08:04:57 <psykose> whenever ncopa decides to go and do it
2022-03-08 08:55:25 <ncopa> good morning
2022-03-08 08:55:35 <ncopa> im working on 3.15 kernel update right now
2022-03-08 08:56:12 <psykose> :)
2022-03-08 08:57:50 <bratkartoffel> thanks for the update
2022-03-08 10:00:17 <ncopa> working on 3.14 now
2022-03-08 10:01:52 <Daanct12> good morning ncopa!
2022-03-08 10:02:53 <maxice8> ncopa: good luck
2022-03-08 10:21:23 <PureTryOut> Is it possible to skip a single test with `meson test`?
2022-03-08 10:21:27 <psykose> nope
2022-03-08 10:21:40 <psykose> generally i went for sed -i '/something/d'
2022-03-08 10:22:00 <psykose> in the test definition place
2022-03-08 10:22:14 <psykose> they usually put one per line, so, works out
2022-03-08 10:22:46 <PureTryOut> eew... Ok that'll have to do I suppose
2022-03-08 10:23:56 <psykose> wireplumber eh :p
2022-03-08 10:24:22 <PureTryOut> Yup
2022-03-08 10:24:36 <PureTryOut> Annoyingly they define each test to run over 6 lines, https://gitlab.freedesktop.org/pipewire/wireplumber/-/blob/master/tests/wp/meson.build#L65
2022-03-08 10:25:02 <PureTryOut> Also strange enough, the tests all succeed on Alpine on the upstream CI. https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/336
2022-03-08 10:25:54 <psykose> ah, not fun
2022-03-08 10:26:00 <PureTryOut> I suppose I'll patch it out for now instead
2022-03-08 10:26:05 <psykose> yep
2022-03-08 10:27:45 <psykose> their ci is only x86_64 from what i can see
2022-03-08 10:27:59 <psykose> or at least this job https://gitlab.freedesktop.org/PureTryOut/wireplumber/-/jobs/19515039 doesn't mention anything else
2022-03-08 10:28:06 <PureTryOut> True
2022-03-08 10:28:19 <PureTryOut> And x86_64 is succeeding for us as well. Fun, I'll report it upstream
2022-03-08 10:28:26 <psykose> yep
2022-03-08 10:28:34 <psykose> seems to be the same issue you already had, but they thought they fixed it
2022-03-08 10:28:36 <psykose> guess not
2022-03-08 10:28:57 <psykose> well, ppc also fails now
2022-03-08 10:29:05 <PureTryOut> Nah that was different (if you're referring to https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/81)
2022-03-08 10:29:08 <PureTryOut> as that one was 32-bit specific
2022-03-08 10:29:14 <psykose> ah, i was
2022-03-08 11:17:19 <PureTryOut> Well at least both PipeWire and WirePlumber upstream CI now cover Alpine Linux with Musl. That should help with future upgrades, at least for x86_64
2022-03-08 12:18:27 <PureTryOut> psykose: oh the test that was failing was already fixed in master lol. I backported the fix and it worked so I re-enabled the test
2022-03-08 12:18:37 <psykose> oh, nice :)
2022-03-08 12:18:45 <PureTryOut> So far I find the PipeWire project quite a nice upstream to have
2022-03-08 12:18:56 <psykose> and a nice piece of software
2022-03-08 12:21:35 <PureTryOut> yup!
2022-03-08 14:13:48 <bl4ckb0ne> psykose: was missing -Db_lundef=false indeed
2022-03-08 20:10:10 <nmeum> ikke: could you move/copy https://dev.alpinelinux.org/~nmeum/catapult-5eedfe23148a234211ba477f76fc2ea2e8529189.tar.gz to dev.alpinelinux.org/archive/qt5-qtwebengine for !31794?
2022-03-08 20:10:23 <ikke> Don't you have access to it?
2022-03-08 20:11:39 <ikke> hmm, you're not in the group
2022-03-08 20:11:54 <ikke> nmeum: you should have now
2022-03-08 20:12:26 <nmeum> yep, does work now indeed. thanks!
2022-03-08 21:19:57 <skarnet> So, finally, !30104 can be merged
2022-03-08 21:20:08 <skarnet> but gitlab says "rebase locally first"
2022-03-08 21:20:22 <skarnet> which makes sense, the thing is more than 1 month old and 2.6k commits behind
2022-03-08 21:20:39 <skarnet> but I can't see a way to do it via the web interface? and my local copy is rebased already
2022-03-08 21:20:43 <skarnet> so I'm not sure what to do
2022-03-08 21:21:30 <panekj> if you rebased onto master, then you should be able to just force push
2022-03-08 21:22:09 <panekj> skarnet: did you git pull --rebase ?
2022-03-08 21:22:18 <skarnet> no
2022-03-08 21:22:23 <skarnet> guess I should?
2022-03-08 21:22:31 <panekj> :) yes
2022-03-08 21:22:53 <panekj> well, pull whatever you named alpine/aports remote
2022-03-08 21:23:16 <panekj> so, git pull upstream master --rebase
2022-03-08 21:28:38 <skarnet> didn't work, I had to do ugly things (merge master into my branch >.>) but now at least it's up to date and mergeable
2022-03-08 21:31:16 <ikke> Yes, but now it includes merge commit, which it should not
2022-03-08 21:31:56 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30104/commits
2022-03-08 21:32:16 <skarnet> well yes but it's the only way I could make it work >.>
2022-03-08 21:32:38 <ikke> What issues did you have with rebasing?
2022-03-08 21:33:29 <skarnet> I don't know and I'd rather scrape my balls with a cheese grater than talk about details of why git is a pain in the ass
2022-03-08 21:34:02 <ikke> I can fix it for you if you want
2022-03-08 21:34:23 <skarnet> but if you have a recipe to take the thing that works as it is now and make it into a palatable form, I'm all ears
2022-03-08 21:34:49 <skarnet> and yes please, but also tell me what you're doing so I can maybe do it myself next time
2022-03-08 21:35:36 <ikke> I fetched your branch, fetched upstream
2022-03-08 21:35:52 <ikke> checked out the branch
2022-03-08 21:35:56 <ikke> then run git rebase upstream/master
2022-03-08 21:36:04 <ikke> Now fixing a conflict
2022-03-08 21:36:35 <skarnet> if the conflict is execline, I already fixed it *twice* so never tell me git is friendly
2022-03-08 21:36:45 <skarnet> and the correct version is the latest one, 2.8.3.0
2022-03-08 21:36:57 <ikke> That's the one I picked
2022-03-08 21:37:11 <ikke> so after fixing the conflict, git add APKBUILD, git rebase --continue
2022-03-08 21:37:13 <ikke> and done
2022-03-08 21:37:19 <ikke> now git push --force-with-lease
2022-03-08 21:37:26 <skarnet> I really have no idea why this one conflicts among the 10 changes in the branch
2022-03-08 21:37:44 <skarnet> --force-with-lease
2022-03-08 21:37:55 <skarnet> that's an intuitive one
2022-03-08 21:38:12 <skarnet> anyway, thanks :)
2022-03-08 21:38:27 <ikke> You can also do --force, but the former is just slightly less obtrusive
2022-03-08 21:39:01 <skarnet> anything involving --force sounds suspicious to me
2022-03-08 21:40:43 <ikke> it conflicts because of the pkgrel bump, while you previously ugpraded it
2022-03-08 21:41:09 <skarnet> ah yes, I bumped the pkgrel when adding the /usr/bin symlink
2022-03-08 21:41:18 <skarnet> that makes sense.
2022-03-08 21:42:18 <ikke> ok, pushed now
2022-03-08 21:42:32 <skarnet> awesome, thanks!
2022-03-08 21:44:40 <skarnet> (also since you're here can you please merge it? XD)
2022-03-08 23:47:23 <psykose> merged with a hack : )
2022-03-08 23:54:16 <skarnet> what kind of hack? 😱
2022-03-08 23:54:28 <panekj> mhmm
2022-03-08 23:55:30 <psykose> that's a secret :p
2022-03-08 23:55:44 <psykose> and if i told you.. i'd have to kill you..
2022-03-09 07:47:40 <ncopa> good morning
2022-03-09 07:47:50 <psykose> morning
2022-03-09 07:48:36 <Daanct12> good morning ncopa 
2022-03-09 07:48:40 <Daanct12> how are you?
2022-03-09 08:20:26 <ncopa> im pretty good thanks. how about you?
2022-03-09 08:36:22 <Daanct12> ncopa, i'm doing good, sitting here again just to play around with my linux phone
2022-03-09 08:36:36 <Daanct12> with a 104 keys kb attached and a mouse
2022-03-09 08:36:40 <Daanct12> blue switches btw
2022-03-09 09:21:13 <omni> moin
2022-03-09 09:49:56 <panekj> mornin
2022-03-09 09:50:41 <panekj> abuild just told me 'libc.so.6: path not found' when tracing dependencies after package build, how
2022-03-09 09:54:05 <psykose> that sounds like glibc
2022-03-09 09:54:22 <Daanct12> ah yes, the classic glibc
2022-03-09 09:54:38 <psykose> i would guess either packaging something prebuilt or it downloads random extra artifacts prelinked against glibc
2022-03-09 09:54:40 <psykose> or something
2022-03-09 09:55:54 <Daanct12> the latter would be a disgusting practice of complete disrespect
2022-03-09 09:56:06 <panekj> yeah, i love how anything related to dotnet can't be built from source
2022-03-09 09:56:45 <Daanct12> lol microsoft libc
2022-03-09 09:57:09 <Daanct12> maybe we'll have mlibc in the future
2022-03-09 09:57:29 <panekj> what do you mean by "microsoft libc"
2022-03-09 09:57:30 <psykose> almost everything i tried works
2022-03-09 09:57:35 <psykose> except osu!lazer
2022-03-09 09:57:49 <psykose> microsoft libc exists on windows
2022-03-09 09:57:51 <psykose> msvcrt
2022-03-09 09:58:06 <psykose> funnily, the whole libc is written in c++
2022-03-09 09:59:26 <Daanct12> at least there's one thing i love about windows, is that they tried to keep it binary compatible for the last 30 years
2022-03-09 09:59:35 <Daanct12> except for 16-bit applications because
2022-03-09 10:00:00 <Daanct12> linux world doesn't have that
2022-03-09 10:09:43 <markand> blue switches are not compatible with openspace work 
2022-03-09 10:09:44 <markand> :D
2022-03-09 10:10:32 <PureTryOut> what is the policy for removing packages from unmaintained/? Do they ever get removed?
2022-03-09 10:11:42 <Daanct12> markand, lol, this is in the public tho
2022-03-09 10:11:52 <Daanct12> an open space with a ton of people around
2022-03-09 10:12:16 <Daanct12> also using the esp8266 to spread linux memes
2022-03-09 10:15:12 <Daanct12> I'm thinking of switching this setup to the PinePhone, as the storage is more larger and allows more users on AP
2022-03-09 10:17:39 <PureTryOut> let's get back on-topic people 😉
2022-03-09 10:18:03 <Daanct12> sure, i'm going to continue with my linux joke hotspot :)
2022-03-09 10:18:47 <Daanct12> i'm thinking of logging user's mac address (to see which vendor is their device or wifi chip) and user agent (for OS identification)
2022-03-09 10:19:08 <Daanct12> maybe if their user agent is linux then they get different jokes
2022-03-09 10:19:24 <Daanct12> whoops, should be in #alpine-offtopic
2022-03-09 10:55:52 <panekj> Why remove them, PureTryOut?
2022-03-09 10:56:45 <PureTryOut> Because if we keep on adding unmaintained packages there forever without sometimes clearing them it just becomes a huge folder of junk
2022-03-09 11:00:16 <skarnet> you seem to be confused on what exactly a distribution package repository is. :)
2022-03-09 11:03:40 <PureTryOut> I'm not sure I understand what you're saying. There is a difference between packages actively built and shipped and the ones in a folder named "unmaintained" with no work being done to them and not even being built or shipped
2022-03-09 11:04:58 <psykose> rm -r unmaintained/; git add .; git commit; git push
2022-03-09 11:04:58 <psykose> :)
2022-03-09 11:12:01 <psykose> (i'm not really sure why we have the folder either)
2022-03-09 11:14:03 <skarnet> PureTryOut: it was a joke, implying that a package repository was a huge folder of junk anyway.
2022-03-09 11:14:50 <skarnet> also, the folder exists in case someone wants to take a look at what's in it and take up maintainership. Which happened, for instance, *yesterday*.
2022-03-09 11:17:24 <psykose> once i got denigrated over useless comments, and told the 'git history' was a place for things
2022-03-09 11:17:28 <psykose> so i will respond in kind :p
2022-03-09 11:18:58 <panekj> I think it's okay to remove software that is not maintained by upstream or which doesn't have source available
2022-03-09 11:21:21 <panekj> psykose, do you know the way to find out which files are linked to glibc?
2022-03-09 11:21:30 <panekj> something something 'find ... | xargs'
2022-03-09 11:21:37 <psykose> mm
2022-03-09 11:21:47 <psykose> ldd shows, but won't give you stuff per file
2022-03-09 11:21:52 <psykose> i never automated it
2022-03-09 11:22:07 <psykose> per file as in a nice output
2022-03-09 11:22:37 <psykose> usually you could just start the program and it will clearly fail to load the libc.so.6
2022-03-09 11:22:40 <psykose> and show you what failed it
2022-03-09 11:22:45 <psykose> from the build folder
2022-03-09 11:22:57 <psykose> depends
2022-03-09 11:23:16 <psykose> or well, probably not very clearly
2022-03-09 11:23:33 <panekj> pretty sure I won't find it that way because it's some tiny component
2022-03-09 11:23:41 <panekj> btw. software is powershell
2022-03-09 11:24:09 <panekj> well, I guess since I have it built and installed I can just write script in pwsh to get files
2022-03-09 11:25:04 <psykose> ah
2022-03-09 11:25:45 <PureTryOut> skarnet: I understand that there can be cases of packages being restored from there, so I'm not saying it should be wiped entirely. It's just that I noticed it had a lot of python2 packages in there for example, those will never be restored
2022-03-09 11:26:39 <donoban> they should be moved to 'deprecated' :D
2022-03-09 11:27:55 <panekj> aah, im dummy
2022-03-09 11:28:11 <psykose> 🥺
2022-03-09 11:28:29 <psykose> PureTryOut: you will see zero opposition to just delete them i think
2022-03-09 11:28:33 <psykose> feel free to do the spring cleaning :)
2022-03-09 11:28:59 <panekj> feel free to delete all other python-related things as well including python3 ;)
2022-03-09 11:29:39 <PureTryOut> ok will do that later then 😄
2022-03-09 12:00:15 <lmarz> packaging blender 3.1 speedrun any% WR
2022-03-09 12:00:26 <lmarz> weare faster than the official website
2022-03-09 12:00:41 <lmarz> thanks psykose :)
2022-03-09 12:00:58 <psykose> :)
2022-03-09 12:01:50 <psykose> heh, does it build with ffmpeg 5 do you think
2022-03-09 12:02:05 <psykose> i just bumped ffmpeg to 5 and added ffmpeg4 for backwards libraries, but ffmpeg-dev points to 5
2022-03-09 12:02:20 <psykose> so need to rebuild everything piece by piece and swap them over to 4-dev
2022-03-09 12:02:29 <lmarz> lets hope it works
2022-03-09 12:02:53 <psykose> sure, it will only clash on x86_64 since the builder was backed up and will then do it in order
2022-03-09 12:02:57 <psykose> i will test it locally real quick
2022-03-09 12:13:34 <lmarz> just found a commit message that says blender is compatible with ffmpeg 5
2022-03-09 12:13:55 <psykose> sweet
2022-03-09 12:27:55 <PureTryOut> oh cool ffmpeg 5 got released?
2022-03-09 12:28:07 <PureTryOut> any noteworthy changes?
2022-03-09 12:28:53 <psykose> 2 months ago, major .so bump
2022-03-09 12:28:57 <Daanct12> it has been released for at least two months lol
2022-03-09 12:29:03 <psykose> the news has the usual highlights https://ffmpeg.org/index.html#news
2022-03-09 12:29:10 <psykose> mostly just some new features
2022-03-09 12:29:15 <psykose> and removing some deprecated interface
2022-03-09 12:29:17 <panekj> that's a lot of text
2022-03-09 12:29:21 <panekj> tl;dr pls?
2022-03-09 12:29:32 <psykose> nothing should break in edge, i added ffmpeg4 :)
2022-03-09 12:29:43 <psykose> but rebuilds might fail for half the ffmpeg-dev packages, so slowly going through them
2022-03-09 12:30:20 <psykose> i already patched firefox to work correctly, don't think anything else wanted ffmpeg4-libs without linking them at runtime
2022-03-09 12:30:21 <PureTryOut> ok cool
2022-03-09 16:27:52 <PureTryOut> hey psykose we got a user report at pmOS: `ffmpeg4-libs-4.4.1-r0 trying to overwrite usr/lib/libavcodec.so.58 owned by ffmpeg-libs-4.4.1-r5`
2022-03-09 16:28:15 <psykose> that means `ffmpeg` didn't upgrade to 5 yet
2022-03-09 16:28:16 <PureTryOut> seems you missed a `replaces="ffmpeg-libs"`
2022-03-09 16:28:24 <psykose> hm
2022-03-09 16:28:25 <psykose> did i
2022-03-09 16:28:40 <PureTryOut> sure but since the builders and packages are still transitioning this is a bit of a problem atm
2022-03-09 16:28:41 <psykose> no, ffmpeg-5 is .59
2022-03-09 16:28:49 <psykose> it will clear when the ffmpeg package rebuilds
2022-03-09 16:28:52 <PureTryOut> but maybe we should just advise our users to wait upgrading for a bit 
2022-03-09 16:28:52 <psykose> it just did for arm
2022-03-09 16:28:54 <PureTryOut> yeah ok
2022-03-09 16:29:07 <psykose> i merged ffmpeg4 and then ffmpeg5 immediately after
2022-03-09 16:29:14 <psykose> so they got the unlucky in-between upgrade i guess
2022-03-09 16:29:27 <psykose> should've just pushed at the same time, haha
2022-03-09 16:29:42 <psykose> by pkgs.a.o only x86_64 is left
2022-03-09 16:29:54 <psykose> it will be clear in... maybe an hour
2022-03-09 16:30:07 <psykose> poor builder built firefox like 9 times today
2022-03-09 16:30:41 <PureTryOut> Np, you're doing good work 👍️
2022-03-09 16:30:52 <PureTryOut> I indeed asked the user to upgrade again in an hour or so
2022-03-09 16:31:03 <psykose> sure, should be fine
2022-03-09 16:31:04 <PureTryOut> Lol it also built Qt5WebEngine like 3 times
2022-03-09 16:31:53 <psykose> yep
2022-03-09 17:04:17 <skarnet> aight folks, time for some theoretical apk questions
2022-03-09 17:04:36 <ikke> So theoreticaly answers, right?
2022-03-09 17:05:00 <skarnet> let's say alpine-base depends on fat-package which contains a lot of stuff
2022-03-09 17:05:36 <skarnet> among that stuff, there's foo
2022-03-09 17:06:13 <skarnet> until now, foo has always been a part of fat-package and alpine-base and nobody had any existential anxiety
2022-03-09 17:06:45 <skarnet> now here I come with metal boots and say hey, I have betterfoo, an alternative for foo
2022-03-09 17:07:01 <skarnet> so I split fat-package into slim-package and foo
2022-03-09 17:07:28 <skarnet> (well fat-package is still named fat-package because it's still fat, but it's a bit less fat because foo isn't part of it anymore)
2022-03-09 17:07:47 <skarnet> I make foo provide virtualfoo, and betterfoo also provide virtualfoo
2022-03-09 17:08:02 <skarnet> I have foo packaging and betterfoo packaging and everything seems fine
2022-03-09 17:08:25 <skarnet> except now, when someone installs alpine-base, they will get fat-package, but neither foo nor betterfoo
2022-03-09 17:08:30 <skarnet> they need one of these
2022-03-09 17:08:42 <skarnet> so I thought of adding foo to alpine-base's depends
2022-03-09 17:08:43 <ikke> skarnet: You need to add a provider_priority
2022-03-09 17:08:50 <skarnet> no that's not a priority problem
2022-03-09 17:08:52 <ikke> ok
2022-03-09 17:09:03 <skarnet> it's a continuity problem
2022-03-09 17:09:23 <skarnet> in order for nothing to change when people install Alpine, alpine-base now needs to provide foo along with fat-package
2022-03-09 17:09:50 <skarnet> but then, if someone wants betterfoo instead of foo, they will remove foo
2022-03-09 17:09:56 <ikke> installing fat-package does not automatically install foo or betterfoo untill it's pulled in, correct
2022-03-09 17:10:26 <skarnet> and removing foo will make apk believe it must remove alpine-base, right?
2022-03-09 17:10:33 <skarnet> if foo is part of alpine-base's depends
2022-03-09 17:10:40 <ikke> No, it will keep foo installed
2022-03-09 17:10:43 <ikke> as a dependency
2022-03-09 17:10:50 <skarnet> ah
2022-03-09 17:10:51 <ikke> it would say: world updated, but not removing foo 
2022-03-09 17:11:01 <skarnet> but that's not what I want, because foo and betterfoo conflict
2022-03-09 17:11:15 <skarnet> one of those must be installed, and only one of those
2022-03-09 17:11:17 <ikke> Ok, so you start with that
2022-03-09 17:11:31 <ikke> add !foo to betterfoo, and !betterfoo to foo as dependency
2022-03-09 17:12:00 <ikke> And because you want people to be able to install either foo or betterfoo, you add virtualfoo as a dependency to fat-package
2022-03-09 17:12:25 <ikke> And then, to make apk be able to choose one by default, you need to add a provider_priority to both
2022-03-09 17:12:35 <skarnet> ah, so you can depend on a virtual name
2022-03-09 17:12:38 <skarnet> that's cool
2022-03-09 17:12:51 <ikke> Yes, for depends that's possible, not for makedepends
2022-03-09 17:13:26 <skarnet> isn't it better to add virtualfoo as a dep to alpine-base rather than fat-package? fat-package is a bunch of unrelated things that are only bundled together for convenience
2022-03-09 17:13:41 <ikke> if that makes more sense, then ofcourse
2022-03-09 17:13:56 <skarnet> okay then, I'll do that, thanks
2022-03-09 17:14:33 <ikke> But, it also depends if people expect foo to be installed when they install fat-package
2022-03-09 17:15:08 <ikke> and if betterfoo contains overlapping files with foo, then you need to add a replaces= as well
2022-03-09 17:15:08 <skarnet> nobody installs fat-package by choice, it just comes with alpine-base
2022-03-09 17:15:39 <skarnet> and yes I've done the replaces thing.
2022-03-09 17:15:48 <skarnet> You will see soon enough. <evil laugh>
2022-03-09 17:16:32 <ikke> I have no doubt
2022-03-09 17:16:43 <psykose> not the french express again
2022-03-09 17:16:51 <skarnet> choo choo bitch
2022-03-09 17:17:01 <psykose> :p
2022-03-09 17:20:20 <skarnet> now to break the abstraction a little...
2022-03-09 17:20:48 <skarnet> I need to add a provides= line to an -openrc package
2022-03-09 17:21:02 <skarnet> depends_openrc is a thing but not provides_openrc
2022-03-09 17:21:33 <skarnet> if I do openrc() { provides="virtualfoo" ; default_openrc ; }   will it work?
2022-03-09 17:22:14 <skarnet> (yes, the conflicting functionality is in the openrc scripts, not in the mechanism)
2022-03-09 17:23:19 <ikke> skarnet: I think it should work, yes
2022-03-09 17:23:22 <psykose> it would
2022-03-09 17:23:29 <skarnet> okay, thanks
2022-03-09 17:50:24 <psykose> PureTryOut: dl-cdn is now up to date for x86_64 ffmpeg
2022-03-09 18:36:51 <skarnet> sanity check: it's on purpose that apk add never removes packages, right? so it's normal that I need to "apk del foo ; apk add betterfoo" or vice-versa every time I want to switch ?
2022-03-09 18:44:56 <psykose> it can remove packages
2022-03-09 18:45:29 <psykose> but in that case, yes, unless one was a default and you explicitly added the other, in which case it would remove the other
2022-03-09 18:45:44 <psykose> i.e. you apk add the lower priority one
2022-03-09 19:10:43 <Hello71> e.g. apk add linux-firmware-none uninstalls stuff
2022-03-09 19:19:27 <skarnet> hm
2022-03-09 19:19:34 <skarnet> there is some stuff I'm still not figuring out then
2022-03-09 19:19:42 <skarnet> I need to keep experimenting before pushing
2022-03-09 19:29:54 <psykose> lewd
2022-03-09 20:17:23 <ikke> skarnet: add and remove basically manipulate world. apk then tries to find a solution that satisfies world
2022-03-09 20:17:46 <ikke> s/remove/del
2022-03-09 20:17:46 <alpine-meetbot> ikke meant to say: skarnet: add and del basically manipulate world. apk then tries to find a solution that satisfies world
2022-03-09 20:17:58 <ikke> skarnet: https://ariadne.space/2021/10/31/spelunking-through-the-apk-tools-dependency-solver/
2022-03-09 20:18:05 <ikke> Oh, that's more low-level
2022-03-09 20:18:13 <ikke> https://ariadne.space/2021/04/25/why-apk-tools-is-different-than-other-package-managers/
2022-03-09 20:18:43 <skarnet> yeah I know how it's supposed to work, but in practice I'm not obtaining that so I'm looking for what I'm doing wrong. I'll figure it out.
2022-03-09 20:21:54 <ikke> things like virtual packages / provides surely complicate these things
2022-03-09 20:23:36 <ikke> skarnet: there is also a difference between versioned and unversioned provides
2022-03-10 07:09:56 <PureTryOut> psykose: `ERROR: ffmpeg4-libs-4.4.1-r0: trying to overwrite usr/lib/libavcodec.so.58 owned by ffmpeg-libs-4.4.1-r5`
2022-03-10 07:10:22 <PureTryOut> so what is happening is that ffmpeg4-libs is being installed _before_ ffmpeg is being upgraded to 5. So it needs `replaces` after all
2022-03-10 07:27:33 <Ariadne> ikke: can you review https://gitlab.alpinelinux.org/alpine/go/-/merge_requests/4 when you have a moment
2022-03-10 07:27:41 <Ariadne> :)
2022-03-10 09:00:16 <HRio> is there a new v3.15.1 planned, due to the "dirty pipe" kernel update?
2022-03-10 09:45:33 <ncopa> morning
2022-03-10 09:46:10 <ncopa> i have been working on a more minimal kernel config, which only includes the differences from the default config, using make savedefconfig
2022-03-10 09:46:36 <ncopa> i have it more or less working, but it is somewhat more tricky to use
2022-03-10 09:47:05 <ncopa> i have tried to enable zswap after the refactor of the configs and it was kinda komplicated
2022-03-10 09:47:35 <ncopa> and its difficult to know if the change is actually enabled or not without generating the full .config
2022-03-10 10:52:14 <ncopa> (5/20) Installing ffmpeg4-libs (4.4.1-r0)
2022-03-10 10:52:14 <ncopa> ERROR: ffmpeg4-libs-4.4.1-r0: trying to overwrite usr/lib/libavcodec.so.58 owned by ffmpeg-libs-4.4.1-r5.
2022-03-10 10:52:30 <ncopa> looks like they cannot be installed in parallel
2022-03-10 10:55:25 <ncopa> oh they can, it was just during the upgrade
2022-03-10 11:01:30 <skarnet> Okay so I figured out what's going on with my dependencies. And unfortunately it's a side effect of how apk works - the difference between explicitly adding/deleting things from world and pulling dependencies. And the fact that mechanism packages (foobar) automatically pull policy packages (foobar-openrc).
2022-03-10 11:02:18 <skarnet> It makes it pretty hard to have several mechanism packages installed and only have the policy packages conflict.
2022-03-10 11:03:13 <skarnet> Ideally you should be able to have all the daemons in the world installed on your machine, even if they're not doing anything (could be used for testing or whatever), but only one of them is launched in the init scripts
2022-03-10 11:04:27 <skarnet> it *is* currently possible to do that, but the sequence of apk operations is pretty unintuitive: when you want to switch daemons, you must apk del the policy *and* the mechanism, then apk add the new policy, then apk add the old mechanism
2022-03-10 11:44:34 <ikke> Ariadne: merged + tagged
2022-03-10 12:03:37 <skarnet> Ahahahahah! This time I got you cornered, Mr. Bond!
2022-03-10 12:04:13 <skarnet> so, there are now 3 implementations of virtualfoo: foo, otherfoo, and my addition, betterfoo
2022-03-10 12:04:44 <skarnet> I split foo from fat-package and have all 3 implementations at the same level, everything is working, nice.
2022-03-10 12:05:10 <skarnet> But foo, or more precisely, foo-openrc, is an early service - it's started in sysinit, not in default
2022-03-10 12:05:32 <skarnet> and since foo previously came with the bundled fat-package, it *did not have a setup script*
2022-03-10 12:05:50 <skarnet> it was started in sysinit by default.
2022-03-10 12:06:26 <skarnet> When packaging betterfoo, I was told "you cannot automatically add services to openrc, you need a /sbin/setup-betterfoo script"
2022-03-10 12:06:58 <skarnet> which is what I did... except foo and otherfoo are in the exact same situation now and they *don't* have a setup script
2022-03-10 12:07:03 <skarnet> Checkmate, Mr. Bond!
2022-03-10 12:07:10 <skarnet> So, what should I do?
2022-03-10 12:07:21 <skarnet> - add setup scripts to foo and otherfoo?
2022-03-10 12:07:46 <skarnet> - (my preferred solution, obviously) give betterfoo the same diplomatic immunity as foo and otherfoo?
2022-03-10 12:09:22 <skarnet> my argument is that adding setup scripts to foo and otherfoo would modify user experience and likely break things.
2022-03-10 13:03:51 <Ariadne> skarnet: in some cases it is appropriate, so give your betterfoo the same treatment i guess
2022-03-10 13:04:01 <Ariadne> this is smelling a lot like cloud-init though
2022-03-10 13:07:05 <skarnet> it has nothing to do with cloud-init, no worries
2022-03-10 14:36:03 <Sheila> …oops. accidentally three commits to my main branch that should've been in their own branch. (nheko bump)
2022-03-10 14:39:50 <Sheila> ohshitgit.com to the rescue. :)
2022-03-10 18:00:55 <nmeum> I think I will now move python2 to testing
2022-03-10 18:03:15 <jvoisin> nmeum: isn't python2 dead and buried?
2022-03-10 18:03:27 <nmeum> yes, that's why I am moving it away from community/ to testing/
2022-03-10 18:03:40 <ikke> jvoisin: qt6-qtwebengine still depends on it for building
2022-03-10 18:04:03 <nmeum> python 2 is EOL since >2 years iirc
2022-03-10 18:04:11 <PureTryOut> is the plan to completely remove it in time? it can be useful for bootstrapping some stuff, e.g. older Dart's build system requires it for example
2022-03-10 18:04:23 <ikke> PureTryOut: that was the plan, yes
2022-03-10 18:04:37 <nmeum> we don't package dart though
2022-03-10 18:04:42 <PureTryOut> Hmm ok
2022-03-10 18:04:44 <nmeum> (or do we?)
2022-03-10 18:04:46 <PureTryOut> I know we don't, it's an example
2022-03-10 18:04:50 <PureTryOut> (I was looking into that recently)
2022-03-10 18:05:01 <nmeum> I will not remove python2 entirely for now
2022-03-10 18:05:03 <nmeum> just move it to testing
2022-03-10 18:05:12 <nmeum> but we won't ship 3.16 with python2 support
2022-03-10 18:05:20 <ikke> PureTryOut: wondering, would pypy work for that/
2022-03-10 18:05:22 <PureTryOut> yeah just wondering about long time plans
2022-03-10 18:05:24 <nmeum> and ideally I would also like to see it removed from testing soon
2022-03-10 18:09:11 <nmeum> dca765490b8d375b6ce7d58906a9998116c9b812
2022-03-10 18:09:20 <nmeum> so long and thanks for all the fish 👋
2022-03-10 20:55:40 <omni> \o/
2022-03-10 22:12:40 <psykose> PureTryOut: sorry i was asleep for like 16 hours, added a replaces for backwards compat
2022-03-10 22:44:42 <psykose> ikke: wonder why !31873 sees no changed aports
2022-03-10 22:44:47 <psykose> and this time it's not crlf
2022-03-11 00:26:22 <Hello71> i don't see anything obviously wrong
2022-03-11 05:58:09 <psykose> strangely there also seems to be like 1 runner per arch
2022-03-11 05:59:15 <ikke> There is one runner which should accept 2 jobs concurrently
2022-03-11 05:59:24 <psykose> that's what i mean
2022-03-11 05:59:30 <psykose> seems to be 1 job
2022-03-11 05:59:35 <psykose> on every arch
2022-03-11 05:59:54 <ikke> I'll have to look later
2022-03-11 06:00:06 <psykose> at least merge libxml first :p
2022-03-11 06:22:52 <PureTryOut> psykose: 👍️
2022-03-11 06:23:11 <psykose> :)
2022-03-11 06:23:13 <PureTryOut> ikke: maybe, I don't have any experience with alternative Python implementations
2022-03-11 07:02:53 <ikke> like here does 
2022-03-11 07:03:13 <ikke> liske 
2022-03-11 07:05:03 <psykose> afaik if it only needs py2 it should work
2022-03-11 07:05:14 <psykose> but you will still need to add the python->pypy alias
2022-03-11 07:06:03 <psykose> if it needs python deps, not sure :) but i think if it's like chromium it won't
2022-03-11 07:06:12 <psykose> could give it a try, pypy is packaged
2022-03-11 07:06:29 <psykose> can give it a try for qt6-qtwebengine too
2022-03-11 07:06:36 <psykose> then we can truly drop python2 :p
2022-03-11 07:06:46 <psykose> rdiff1 is fine to drop as hriomar said it was fine
2022-03-11 07:08:52 <liske> py deps needs to build against pypy (many are supported, but not all)
2022-03-11 07:09:54 <psykose> yeah
2022-03-11 08:50:21 <PureTryOut> so, say I want to add a new feature to the mkinitfs, where would I start? Adding the required files in `features.d/<feature>.files` and then what? `initramfs-init.in` seems to do the actual initramfs logic but I'm not sure where to insert the required logic and how the kernel parameters (`$KOPT_<something>`) are set
2022-03-11 10:54:36 <PureTryOut> also how can I check that all the required files are actually present in the initramfs? The image seems to be a complete disk image so I'm unsure how to mount it
2022-03-11 10:55:20 <ktprograms> PureTryOut: It's a gzipped cpio archive, so rename it to initramfs.gz and gunzip it, then do standard cpio commands (e.g. "cpio -it <initramfs" to list files)
2022-03-11 10:58:24 <PureTryOut> Thanks! Is that command (cpio) supposed to complete quickly? Either I'm not patient enough or it's just hanging
2022-03-11 11:01:47 <psykose> < 
2022-03-11 11:01:50 <psykose> it reads stdin
2022-03-11 11:01:55 <psykose> maybe you missed that, so it's waiting for input
2022-03-11 11:02:15 <psykose> fell for that before :)
2022-03-11 11:03:04 <PureTryOut> yeah I'm falling for that lol
2022-03-11 11:03:21 <PureTryOut> it doesn't seem to respond to input though 🤔
2022-03-11 11:03:40 <psykose> it's the usual stdin in terminal input, where you press ctrl-d at the end
2022-03-11 11:03:54 <PureTryOut> ah
2022-03-11 11:03:59 <psykose> i usually just do gunzip | cpio
2022-03-11 11:04:08 <PureTryOut> I see `cpio -it -F <initramfs>` also just works
2022-03-11 11:04:12 <psykose> yep
2022-03-11 11:07:59 <PureTryOut> well so far my initramfs init script changes seem to be ignored. The files are there but the required behaviour does not happen 🤔 Unsure how to debug it easily
2022-03-11 11:08:50 <ktprograms> You can extract the cpio and see if initramfs-init seems to have your changes
2022-03-11 11:11:34 <PureTryOut> Ah seems it doesn't. I've changed VERSION and the extracted init still has the old version
2022-03-11 11:12:05 <ktprograms> How are you generating the initramfs?
2022-03-11 11:13:24 <PureTryOut> just `/path/to/modified/mkinitfs -o /boot/initramfs-lts <kernel version>`
2022-03-11 11:15:01 <PureTryOut> seems `make VERSION=<modified version number>` just ignores my changes for some reason
2022-03-11 11:15:41 <PureTryOut> at least the version number
2022-03-11 11:16:10 <ktprograms> PureTryOut: In the Makefile it's a ":=" variable so I'm not sure if setting it from the commmand line works
2022-03-11 11:16:25 <PureTryOut> that's how the APKBUILD does it though 🤔
2022-03-11 11:16:29 <PureTryOut> how else would I set it?
2022-03-11 11:16:34 <ktprograms> I suggest just looking for the changes you made in the initramfs-init
2022-03-11 11:17:07 <PureTryOut> yeah I was but couldn't find it
2022-03-11 11:17:36 <ktprograms> PureTryOut: btw I use "-b /" instead of the -o option when using mkinitfs
2022-03-11 11:18:12 <ktprograms> Although I'm mostly doing it by editing the initramfs-init in /usr/share on an already installed system
2022-03-11 11:18:14 <PureTryOut> the changes are in the files installed by `make install`, just not in the actual created initramfs 🤔
2022-03-11 11:20:57 <ktprograms> PureTryOut: I think the problem is that the Makefile uses sed to make mkinitfs look for initramfs-init in /usr/share (so it's including the default one installed by Alpine)
2022-03-11 11:22:18 <PureTryOut> seems like it yes, if I just edit initramfs-init in `/usr/share/` directly my changes _are_ there after regenerating the initramfs
2022-03-11 11:22:46 <PureTryOut> Oh well, let's just edit it in `/usr/share` directly then 🤷
2022-03-11 11:23:04 <ktprograms> I think just doing the editing there will be best because otherwise you'll need to set datarootdir and stuff
2022-03-11 11:25:11 <PureTryOut> yeah annoying
2022-03-11 11:27:45 <PureTryOut> Ok my print is in the boot log now. Thanks! Now I can actually make my stuff happen 😄
2022-03-11 11:27:56 <ktprograms> 🎉
2022-03-11 11:44:18 <ikke> psykose: WARNING: py3-seaborn: not provided by any known APKBUILD
2022-03-11 11:45:23 <psykose> hah
2022-03-11 11:45:25 <psykose> that was it
2022-03-11 16:37:47 <skarnet> Soooo...
2022-03-11 16:38:09 <skarnet> Do we have any examples of Alpine installations using kernel bootparams to use udev?
2022-03-11 16:38:51 <skarnet> Apparently, in the current openrc scripts, mdev doesn't start if "udev" is given on the kernel command line
2022-03-11 16:39:04 <skarnet> Do people actually use this?
2022-03-13 05:35:50 <boomanaiden154> psykose: Did you check the build logs/CI on the Chromium revert commit?
2022-03-13 05:35:56 <psykose> yes
2022-03-13 05:36:30 <psykose> what i forgot to check is that you forgot to bump the pkgrel too :p but yeah
2022-03-13 05:36:33 <psykose> it was just ffmpeg4
2022-03-13 05:38:34 <boomanaiden154> I should’ve foreseen the ffmpeg upgrade breaking the build. Can’t believe I forgot the pkgrel bump. 🤦‍♂️
2022-03-13 05:38:41 <boomanaiden154> Thanks for merging and fixing my mistakes.
2022-03-13 05:38:44 <psykose> mhm
2022-03-13 05:38:46 <psykose> :)
2022-03-13 05:38:56 <psykose> there is a quite small ffmpeg5 patch
2022-03-13 05:39:10 <psykose> but it also needs a patch to ffmpeg itself, i have an mr open for the same change in qt5-qtwebengine
2022-03-13 05:39:20 <psykose> if that gets merged feel free to add it to chromium next run around
2022-03-13 05:40:23 <boomanaiden154> Thank you. I’ll have to take a look. Is there an effort to integrate the ffmpeg patch upstream?
2022-03-13 05:40:33 <psykose> nooot entirely sure
2022-03-13 05:42:46 <psykose> i don't see it on the ML by title
2022-03-13 05:42:51 <psykose> but it really is tiny
2022-03-13 05:42:54 <psykose> https://github.com/archlinux/svntogit-packages/blob/packages/ffmpeg/trunk/add-av_stream_get_first_dts-for-chromium.patch
2022-03-13 05:43:17 <psykose> then just replacing 4 calls with that in chromium base
2022-03-13 05:43:41 <psykose> and on chromium side i'm not sure what the story is
2022-03-13 05:44:05 <psykose> based on how it looks it almost looks like a backport of something chromium custom patched in a vendored ffmpeg
2022-03-13 05:45:14 <boomanaiden154> Probably. There’s an ffmpeg version vendored into the Chromium tree.
2022-03-13 05:45:21 <boomanaiden154> Not sure what version it’s on though.
2022-03-13 05:45:30 <psykose> me either :)
2022-03-13 05:53:43 <boomanaiden154> Looks like the vendored ffmpeg got upgraded two days after ffmpeg 5 got released. Too lazy right now to check if the commit that they reference actually hits version 5. I’ll have to do more investigation to see if they’re patching it/did something else to get the compile working.
2022-03-13 05:54:17 <psykose> have fun with it
2022-03-13 05:58:09 <boomanaiden154> Should be fun going down the rabbit hole once I have some time. :)
2022-03-13 05:58:34 <psykose> :3
2022-03-14 06:33:54 <rabbitz> 
ACTION https://docs.google.com/document/d/1T5rOhHGQvTlfj7zMHWImHALQ9hJPlyTS/edit?usp=sharing&ouid=100976977371543538488&rtpof=true&sd=true

2022-03-14 08:28:51 <wyk72> hello ppl
2022-03-14 08:29:40 <wyk72> I have what it seems an hardware issue/problem with a server I rented from an online provider
2022-03-14 08:30:14 <wyk72> I have installed Alpine 3.15 on it, it works but takes forever to boot
2022-03-14 08:30:59 <wyk72> I narrowd down the problem to the onboard ipmi :
2022-03-14 08:31:09 <wyk72> on dmesg I get : udevd[1835]: worker [1892] /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/IPI0001:00 is taking a long tim
2022-03-14 08:31:25 <wyk72> and  udevd[1835]: worker [1898] /devices/pci0000:00/0000:00:14.3/IPI0001:00 is taking a long time
2022-03-14 08:32:01 <wyk72> "long time" = about 120 seconds each
2022-03-14 08:32:36 <wyk72> there's a way to tell udevd to ignore this device ?
2022-03-14 08:33:17 <wyk72> I thought about blacklisting the ipmi modules on the kernel line, is it the right thing to do ?
2022-03-14 08:35:54 <wyk72> kernel version= 5.15.26-0-lts
2022-03-14 08:45:11 <clandmeter> wyk72: this is not our support channel, we have #alpine-linux that such cases.
2022-03-14 08:46:26 <clandmeter> s/that/for
2022-03-14 08:46:26 <alpine-meetbot> clandmeter meant to say: wyk72: this is not our support channel, we have #alpine-linux for such cases.
2022-03-14 09:22:42 <nico78> Hi, I have created a new aport and I get the message "Merge blocked: the source branch must be rebased onto the target branch." Is this something I should do or fix?
2022-03-14 09:23:16 <ikke> nico78: the one merging it will do it before its merged
2022-03-14 09:23:46 <ikke> When it's very far behind, you could do it 
2022-03-14 09:24:33 <nico78> Ok. I'll practice some patience. :)
2022-03-14 13:42:23 <skarnet> Follow-up to last week's questions. After some tries and some work, I'm less and less convinced that adding post-install scripts enabling virtualfoo services is the way to go, even if historically it's what was implicitly done for foo.
2022-03-14 13:43:39 <skarnet> (I mean, I think it's acceptable policy in a void, but since it goes against Alpine policy for most services, extending the exception to more implementations of virtualfoo services feels clunky and sticks out.)
2022-03-14 13:45:33 <skarnet> So, I think having a setup-virtualfoo is the best idea. At the moment there is no setup-foo (because historically foo is the default and always installed), but there is a setup-otherfoo and I would add a setup-betterfoo as well. That is not a good situation at all.
2022-03-14 13:45:55 <skarnet> However, virtualfoo is low-level enough that it should really be a part of setup-alpine.
2022-03-14 13:46:46 <skarnet> There could be a setup-virtualfoo in alpine-conf, called by setup-alpine, asking the user to choose between foo, otherfoo or betterfoo. That's what is done for other low-level stuff, and even some not so low-level stuff such as sshd.
2022-03-14 13:47:09 <skarnet> What is the Alpine policy on adding stuff to alpine-conf?
2022-03-14 13:48:20 <skarnet> I'm asking because alpine-conf is in another repository, and modifying it means changing the version number in the alpine-conf aport, etc. It's more convoluted than just modifying aports, and I wonder whether the feel that alpine-conf is less modifiable is on purpose.
2022-03-14 15:28:42 <ikke> You mean because it's in another repository?
2022-03-14 15:43:52 <nmeum> I think in general our external repository tools (alpine-conf, mkinitfs, abuild, …) could be a bit better maintained. many of them have quite a few open MRs and issues
2022-03-14 15:44:18 <nmeum> easier said then done ofc
2022-03-14 15:45:19 <ikke> The difficult part is determining whether somehting is a correct solution in the first place
2022-03-14 15:49:29 <nmeum> indeed
2022-03-14 15:55:16 <skarnet> tbh after studying this I'm more and more convinced having setup-virtualfoo in setup-alpine is the correct approach
2022-03-14 15:55:54 <skarnet> because the alternative approach of enabling services in post-install just feels too un-alpineish
2022-03-14 15:56:02 <ikke> superficially, that seems to me as well
2022-03-14 15:56:24 <ikke> skarnet: correct, in generall we do not expect installing packages to enable services
2022-03-14 15:56:45 <skarnet> I know it's not the general policy, but historically (and for good reason) foo is an exception
2022-03-14 15:57:06 <ikke> yes, understood
2022-03-14 15:57:14 <skarnet> I initially thought extending the exception to other implementations of virtualfoo could work, and in theory it can
2022-03-14 15:57:32 <skarnet> but in practice that really feels like going against the way Alpine works
2022-03-14 16:55:55 <minimal> skarnet: the advantage of having a separate setup script (rather than bundling it into setup-alpine) is that if another package relies on it then it can call setup-foo rather than having to find another way to enable that (as calling setup-alpine would be "excessive", or possible unfeasible, if all it needs is foo to be enabled)
2022-03-14 16:57:29 <skarnet> minimal: alpine-conf is a series of setup-foobar scripts with setup-alpine calling them in a sequence
2022-03-14 16:57:38 <skarnet> I intend to follow that pattern
2022-03-14 16:58:59 <minimal> skarnet: sorry, I thought you had said as the contents of setup-foo would be so simply that you'd include it directly into setup-alpine instead
2022-03-14 17:00:35 <skarnet> it would be the case if it were only foo, but it's actually a setup-virtualfoo command that needs to handle foo, otherfoo and betterfoo
2022-03-14 17:00:59 <skarnet> so no, it needs its own script
2022-03-14 17:01:24 <skarnet> (and there is already a setup-otherfoo script in the otherfoo package, that will be redirected to setup-virtualfoo)
2022-03-14 17:15:31 <minimal> can someone please merge !31834 and !31959
2022-03-14 17:58:57 <ikke> I'm working on getting all packages up to shape
2022-03-15 01:51:08 <tomalok> looking to do a new aports, but upstream does version tags instead of actual releases -- there another aport that does something similar?
2022-03-15 01:52:26 <boomanaiden154> Upstream in this case is Github?
2022-03-15 01:52:42 <boomanaiden154> /s/is/is on
2022-03-15 01:53:38 <tomalok> yep
2022-03-15 01:55:33 <boomanaiden154> There are plenty of aports that do this. You just download the source code archive from the tag instead of downloading from the release endpoint. Basically only changes a couple things in the URL.
2022-03-15 01:57:24 <tomalok> okay, cool.  thx for clarifying
2022-03-15 01:59:56 <Saijin_Naib> https://git.alpinelinux.org/aports/tree/testing/lsd/APKBUILD
2022-03-15 02:00:02 <Saijin_Naib> One of mine looks like this 
2022-03-15 15:50:15 <mercenary> where does the latest development on apk3 live?
2022-03-15 15:50:35 <ikke> master branch in apk-tools
2022-03-15 17:12:02 <ncopa> Ariadne: I'd like to test rebuild against openssl3, and I wonder what is the way to do it?
2022-03-15 17:12:29 <Ariadne> make openssl3 provide openssl-dev=3
2022-03-15 17:12:52 <ncopa> maybe I rename current openssl -> openssl1.1-compat, and openssl3 -> openssl?
2022-03-15 17:12:54 <ikke> ncopa: according to psykose there is no release of mariadb yet that properly works with openssl3?
2022-03-15 17:13:06 <ncopa> ikke: i saw that fedora has patches
2022-03-15 17:13:11 <ikke> ok
2022-03-15 17:13:13 <psykose> i do not think it is a good idea
2022-03-15 17:14:00 <ncopa> https://src.fedoraproject.org/rpms/mariadb/blob/rawhide/f/mariadb-openssl3.patch
2022-03-15 17:14:26 <panekj> go1.18 has been released, cc: ncopa
2022-03-15 17:14:28 <psykose> this is for 10.5, but sure, i guess it might apply
2022-03-15 17:15:17 <psykose> ncopa: regarding renaming, i would prefer to explicitly mark things with openssl3-dev
2022-03-15 17:15:45 <ncopa> i guess thats the least intrusive
2022-03-15 17:15:47 <psykose> and then move the packages last
2022-03-15 17:15:55 <psykose> it will need ssldir to be swapped again too
2022-03-15 17:17:01 <ncopa> so they cannot reuse same ssldir?
2022-03-15 17:17:13 <psykose> nope
2022-03-15 17:17:24 <psykose> that is already fixed, just openssl3 is /etc/ssl3 currently
2022-03-15 17:19:15 <ncopa> so, build all packages with openssl3-dev, then swap ssldir?
2022-03-15 17:19:45 <psykose> yeah, making 1.1 /etc/ssl1.1
2022-03-15 17:21:51 <psykose> i can take care of that when we get there, just not sure if it's even worth the attempt
2022-03-15 17:22:10 <psykose> even with mariadb patched, there was like another 15% of aports or something that failed last time
2022-03-15 17:27:21 <ncopa> https://discourse.ubuntu.com/t/openssl-3-0-transition-plans/24453
2022-03-15 17:28:48 <ncopa> since both fedora and ubuntu is aiming for openssl3, i would expect patches to be available for most packages at this point
2022-03-15 17:29:11 <ncopa> i also think that 15% with openssl1.1 might be okish
2022-03-15 17:29:25 <ncopa> last time we had it around 50%, mostly due to mariadb as I understand
2022-03-15 17:29:29 <psykose> ye
2022-03-15 17:29:51 <ncopa> those who does not build with openssl3 might build with libressl?
2022-03-15 17:30:02 <psykose> not sure how that's better
2022-03-15 17:30:23 <ncopa> in case we want get completely rid of openssl1.1
2022-03-15 17:35:02 <psykose> given how well that ubuntu transition has gone, i would expect just a clusterfuck in testing, like always
2022-03-15 17:35:51 <psykose> i guess it is somewhat doable
2022-03-15 17:36:45 <psykose> i can take care of all the bumps for things, but this is a little fat to run CI on, are we ok with just messing up the builders a little for a while and doing it live :)
2022-03-15 17:49:09 <ikke> psykose: I'll see if I can finish the multi-stage building for CI
2022-03-15 17:49:23 <psykose> sure thing
2022-03-16 09:15:42 <psykose> ikke: !32039 for instance, private with nothing visible, nothing automatically set
2022-03-16 09:20:51 <ikke> psykose: hmm, the script looks for projects with visibility internal
2022-03-16 09:20:58 <ikke> so wonder why this is set to rpivate
2022-03-16 09:21:17 <psykose> one can fork as private, it is an option
2022-03-16 09:21:50 <psykose> though i don't know if it's possible to override those too
2022-03-16 09:33:20 <ikke> psykose: ok, updated the script to also include private projects
2022-03-16 09:33:30 <psykose> sweet
2022-03-16 09:33:32 <psykose> hope it works
2022-03-16 09:33:38 <psykose> will the rescan hit this same one so we can see
2022-03-16 09:33:41 <ikke> I see it updated JostBrand/aports
2022-03-16 09:33:51 <psykose> oh hey
2022-03-16 09:33:52 <psykose> visible
2022-03-16 09:33:59 <psykose> and rebase is available
2022-03-16 09:34:01 <psykose> nice
2022-03-16 09:34:04 <psykose> thanks
2022-03-16 09:34:45 <ikke> I do wonder if we want to make all private aport forks public, though
2022-03-16 09:36:54 <psykose> does it hit every single one or just the ones that open mrs
2022-03-16 09:47:31 <ikke> right now every single project
2022-03-16 09:47:42 <psykose> hm
2022-03-16 09:47:44 <psykose> then maybe not
2022-03-16 09:48:19 <ikke> or rather, every single fork of aports
2022-03-16 09:51:17 <ikke> I reverted that part for now
2022-03-16 09:51:55 <psykose> is it possible to disable the private selection in the fork screen
2022-03-16 09:52:42 <ikke> globally
2022-03-16 09:52:50 <ikke> but not sure if we want to disable it globally
2022-03-16 10:06:27 <markand> sooo.... I've submitted an aport a long time ago and someone changed it entirely to another software 
2022-03-16 10:06:30 <markand> https://gitlab.alpinelinux.org/alpine/aports/-/commit/2cf432429d5245759d052ff3ff2be808135a6a37
2022-03-16 10:06:33 <markand> totally awesome
2022-03-16 10:09:39 <ikke> hmm
2022-03-16 10:10:05 <ikke> maxice8: ^
2022-03-16 10:14:33 <markand> I think I'll drop all my aports
2022-03-16 10:17:06 <PureTryOut> Is it possible for `abuild rootbld` to somehow not remove the build files? I need to verify some files it build but the full package isn't complete yet so no package to check
2022-03-16 10:17:23 <ikke> markand: that would be sad
2022-03-16 10:18:57 <ncopa> markand: I believe it was done in good faith
2022-03-16 10:19:18 <markand> I've been mentioning those kind of troubles several times on the mailing list and I start to be tired to see that people keep modifying their non's aports without any approval
2022-03-16 10:19:41 <ikke> markand: FYI, this is something we're bringing up to the TSC: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/36
2022-03-16 10:20:00 <ncopa> the commit message says "upgrade" so he probably thought it was a newer version of same software
2022-03-16 10:21:32 <ncopa> i think i will tag new edge release now. please dont push anything big til after the release is done
2022-03-16 10:24:49 <ikke> markand: What would you feel to be a good policy in this regard?
2022-03-16 10:25:49 <ktprograms> PureTryOut: You can remove "bldroot" from the *CLEANUP variables in /etc/abuild.conf
2022-03-16 10:30:25 <markand> ikke, I'm reading #22 
2022-03-16 10:30:51 <PureTryOut> ktprograms: thanks! In my case I need ERROR_CLEANUP but this helpes!
2022-03-16 10:31:40 <PureTryOut> Would be nice if rootbld had some `--unstrict` flag I could pass it to only sometimes not wipe everything (most of the time I _do_ want everything wiped)
2022-03-16 10:32:28 <ktprograms> PureTryOut: -K flag?
2022-03-16 10:32:39 <ktprograms> Found in the abuild source code, keep_build
2022-03-16 10:33:05 <PureTryOut> yes I know about that one but it doesn't apply to rootbld sadly
2022-03-16 10:35:14 <ktprograms> PureTryOut: Hmm, weird. At [0]line 140-142 it seems like it'll skip the cleanup if keep_build is set. [0]:https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L140-142
2022-03-16 10:35:28 <ktprograms> s/[0]:/[0]: /
2022-03-16 10:35:28 <alpine-meetbot> ktprograms meant to say: PureTryOut: Hmm, weird. At [0]line 140-142 it seems like it'll skip the cleanup if keep_build is set. [0]: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L140-142
2022-03-16 10:35:50 <PureTryOut> Hmm, I'll try again then
2022-03-16 10:45:09 <PureTryOut> ktprograms: nope, it's still wiping the build directory
2022-03-16 10:45:54 <PureTryOut> The only thing that remains is an empty pkg folder, and a src folder with only symlinks to the $source files in /var/cache/apk/distfiles
2022-03-16 10:47:19 <ktprograms> PureTryOut: The rootbld directory is in /var/tmp/abuild.XXXXXXXXXX
2022-03-16 10:48:54 <PureTryOut> oh, derp
2022-03-16 10:49:23 <PureTryOut> and where can I find the build directory in there
2022-03-16 10:49:25 <PureTryOut> ?
2022-03-16 10:50:14 <PureTryOut> There is my home directory in there but that only goes up to the root of the aports tree
2022-03-16 10:51:30 <ikke> That's the disadvantage of rootbld, it's a lot more difficult to inspect if things fial
2022-03-16 10:51:37 <ikke> fail
2022-03-16 10:52:13 <PureTryOut> 😢 But it's so much better in every other way lol
2022-03-16 10:52:44 <ktprograms> PureTryOut: The hack I normally do is put a call to sh in the failing step
2022-03-16 10:53:07 <ktprograms> From what I remember I also couldn't find the build dir when doing rootbld, not sure why
2022-03-16 10:53:21 <PureTryOut> A call to sh? What do you mean?
2022-03-16 10:53:40 <ktprograms> For example putting "ash" in the check() function of the APKBUILD
2022-03-16 10:53:42 <psykose> build() { make || ash }
2022-03-16 10:53:57 <ktprograms> Oh that's actually better, thanks!
2022-03-16 11:06:40 <PureTryOut> ah interesting, thanks
2022-03-16 11:25:33 <ikke> markand: thanks for your feedback!
2022-03-16 13:31:09 <PureTryOut> So uh, any linker that supports the `--as-needed` flag? `ld: unknown option: --as-needed`
2022-03-16 13:32:10 <ncopa> oh no. kernel 5.15.29 got released...
2022-03-16 13:34:20 <ncopa> well, not yet released... https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.15.y
2022-03-16 13:36:10 <PureTryOut> "oh no"? 😂
2022-03-16 13:44:50 <ncopa> i was just about to tag a 3.15.1 release
2022-03-16 13:44:59 <ncopa> i think we want the new kernel in there
2022-03-16 13:46:28 <psykose> all of them
2022-03-16 13:46:50 <psykose> you should link with the compiler and pass that in ldflags with -Wl instead
2022-03-16 13:46:55 <psykose> the default alpine ldflags have it
2022-03-16 13:47:57 <psykose> i'm also confused what ld that is, cause bfd (the default), gold, and lld, all accept that flag directly too
2022-03-16 14:28:38 <ktprograms> Oh darn it, I forgot to ask about getting some mkinitfs fixes merged[0],[1] earlier and now 3.15.1 is about to be released :(. [0]: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/99 [1]: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/100
2022-03-16 14:30:07 <omni> I haven't followed up on this, but think it would be good to have in order for 3.15.1 https://gitlab.alpinelinux.org/alpine/aports/-/issues/13512
2022-03-16 14:30:26 <omni> #13512
2022-03-16 14:32:43 <psykose> ncopa: could you merge !31643
2022-03-16 14:32:57 <psykose> or well, the commit message is wrong
2022-03-16 14:33:01 <psykose> but i can make one that is correct :)
2022-03-16 14:33:03 <psykose> i think it's fine
2022-03-16 14:34:53 <omni> there's also !29061 that I got stuck on and haven't followed up on yet
2022-03-16 14:36:50 <omni> I'll see if I can look at any of these a bit later today
2022-03-16 14:37:52 <sam_> 1.17.8 fixes security issues too i think
2022-03-16 14:42:08 <PureTryOut> psykose: not sure. I'm trying to get Darling working on Alpine so it might be some messy macOS stuff. I'll ask upstream
2022-03-16 14:42:18 <psykose> ahh
2022-03-16 14:42:27 <psykose> darling, what a cute name
2022-03-16 14:42:52 <psykose> i would sure, not sure what the mode of operation was, but every ld in alpine has that flag, so i assume they are doing something overriden
2022-03-16 14:42:56 <psykose> maybe it's the macos default ld
2022-03-16 14:42:57 <psykose> or something
2022-03-16 14:43:17 <PureTryOut> yeah not sure
2022-03-16 14:44:27 <psykose> yeah, seems macos ld just doesn't have that flag
2022-03-16 14:45:08 <psykose> -Wl,-dead_strip_dylibs is the equivalent i think
2022-03-16 14:45:47 <psykose> maybe you are leaking some ldflags from the host env, or something mixes up the cross environment, but yeah, good luck :)
2022-03-16 14:55:07 <sam_> psykose: yeah, that's the equiv
2022-03-16 14:55:16 <sam_> macos ld is lld but apple's fork fwiw
2022-03-16 14:55:24 <sam_> (apple clang is notoriously a bit weird)
2022-03-16 14:55:33 <sam_> "somewhere between the last 2 LLVM releases, maybe"
2022-03-16 14:55:33 <psykose> seems like quite a divergent fork given regular lld is just the normal options
2022-03-16 14:55:34 <psykose> :p
2022-03-16 14:55:49 <sam_> it's more to do with the platform b./c macho doesn't have NEEDED
2022-03-16 14:55:52 <psykose> right
2022-03-16 14:57:38 <sam_> what bothers me most is gcc -> clang
2022-03-16 14:57:47 <sam_> there's no need to be doing that!
2022-03-16 15:03:17 <Hello71> huh? standard macos ld is ld64. it long predates lld
2022-03-16 15:03:39 <Hello71> according to https://news.ycombinator.com/item?id=26753805, mach-o lld doesn't really work
2022-03-16 15:04:10 <sam_> oh right, thanks, i'd forgot about ld64; i got into the darwiny bits trying to do a prefix a while ago and apparently forgot stuff
2022-03-16 16:15:25 <omni> would most of the aports listed in #13512 be satisfied just by switching to util-linux-misc?
2022-03-16 16:17:02 <psykose> i dunno, would they? :)
2022-03-16 16:18:10 <omni> uhhh.. how to know...
2022-03-16 16:18:31 <psykose> you cast a magic spell of knowing.. or something
2022-03-16 16:19:13 <omni> 
ACTION reaches for their dice

2022-03-16 16:19:41 <psykose> :o
2022-03-16 16:19:43 <psykose> what did you roll
2022-03-16 16:23:24 <omni> i³
2022-03-16 17:39:09 <omni> psykose: so nothing need to be done in 3.15-stable wrt util-linux subpackage split you say?
2022-03-16 17:39:18 <psykose> probably not
2022-03-16 17:39:57 <omni> I've forgotten how I noticed about this in the first place
2022-03-16 17:40:31 <omni> ncopa: sorry if this added to stalling 3.15.1
2022-03-16 17:41:58 <ikke> not sure that even needs to necessarily be in 3.15.1
2022-03-16 17:42:08 <ikke> which mostly affects boot media / docker images
2022-03-16 17:45:21 <maxice8> Ikke: go 1.18 is out, I wrote a small binary that prints out all the deps recorded in a go binary, replacing my previous plan9rc thing
2022-03-16 17:45:43 <ikke> Yes, I noticed
2022-03-16 17:45:53 <ikke> nmeum already has an MR for go itself
2022-03-16 17:46:26 <nmeum> yep, though it fails to build on ppc64le with a segfault :(
2022-03-16 17:46:32 <maxice8> I guess we can put it in atools and just tell people to use it ?
2022-03-16 17:46:51 <maxice8> people == whoever needs to bump all packages that use module/foo due to a CVE
2022-03-16 17:46:59 <nmeum> that would be cool, I think we could also consider doing a rebuild before 1.18 is pushed
2022-03-16 17:47:06 <nmeum> in case you want to test your script ;)
2022-03-16 17:47:30 <psykose> oh, nice
2022-03-16 17:47:43 <nmeum> (because we haven't done a rebuild for go 1.17.8 and go 1.17.7 yet)
2022-03-16 17:47:44 <maxice8> I ran it through all the binaries in my $HOME/go/bin that vscode prompts me to install and it seems to work fine
2022-03-16 17:48:33 <maxice8> https://pastebin.com/raw/KneQTuz2
2022-03-16 17:48:37 <nmeum> does it also work on stripped go binaries?
2022-03-16 17:49:01 <ikke> I believe so
2022-03-16 17:49:34 <nmeum> great
2022-03-16 17:49:36 <maxice8> let me check
2022-03-16 17:49:51 <maxice8> doing quick stuff in terminal in NixOS can be unwieldy at times
2022-03-16 17:50:44 <maxice8> running strip -s should be enough or go has some strip equivalent command ?
2022-03-16 17:51:46 <ikke> -ldflags '-s -w'
2022-03-16 17:51:49 <ikke> but should be equivalent
2022-03-16 17:52:21 <psykose> they are the same, yes
2022-03-16 17:52:27 <maxice8> ok then it works
2022-03-16 17:52:42 <psykose> sweet
2022-03-16 17:53:37 <nmeum> \o/
2022-03-16 18:09:05 <maxice8> https://paste.debian.net/plain/1234630
2022-03-16 18:29:42 <nmeum> looks easy enough, maybe atools is indeed the right place for it?
2022-03-16 18:33:45 <maxice8> yeah, I'll put it there and figure out how redo works
2022-03-16 18:36:30 <ikke> should be easy enough :)
2022-03-16 18:36:46 <ikke> shell scripts, args 1-3, redo-ifchange to mark dependencies
2022-03-16 18:37:33 <maxice8> I didn't understand a single thing you just said
2022-03-16 18:38:05 <ikke> I bet you understood 'shell script'
2022-03-16 18:38:48 <psykose> what's that?
2022-03-16 18:41:04 <maxice8> is it a type of fruit ?
2022-03-16 18:42:17 <ikke> https://tpaste.us/1l0Q 
2022-03-16 18:42:34 <maxice8> ok got it work
2022-03-16 19:54:32 <ncopa> im gonna tag 3.15.1 now. please dont push anything to 3.15-stable til after the release is donw
2022-03-16 19:55:00 <ikke> 👍
2022-03-16 20:22:20 <ncopa> where is the test site for release notes?
2022-03-16 20:22:52 <ikke> wwwdev.a.o
2022-03-16 20:22:56 <ikke> but I need to point it to a branch
2022-03-16 20:23:07 <ikke> Do you have a branch?
2022-03-16 20:23:13 <ncopa> master?
2022-03-16 20:23:39 <ikke> https://wwwtest.alpinelinux.org/ should track master, right?
2022-03-16 20:23:55 <ncopa> i thought it did, but apparently its broken
2022-03-16 20:24:50 <ikke> let me check
2022-03-16 20:25:57 <ikke> mqtt-exec failed
2022-03-16 20:27:10 <ikke> it's up-to-date now
2022-03-16 20:35:43 <ncopa> thanks!
2022-03-16 20:35:49 <ncopa> does it look ok now? https://wwwtest.alpinelinux.org/posts/Alpine-3.15.1-released.html
2022-03-16 20:37:43 <ikke> Looks alright
2022-03-16 20:37:52 <ncopa> i think its good enough
2022-03-16 20:38:03 <ncopa> pushing. thank you for verifying!
2022-03-16 21:34:43 <syscomet> Heads-up: release 3.15.1 file alpine-standard-3.15.1-aarch64.iso.asc is empty (zero-length).
2022-03-16 21:38:31 <ikke> ugh
2022-03-16 21:40:00 <syscomet> I don't think I fetch _all_ the OS variants, just "several" of them, and check checksums and PGP signatures, so I can install locally from this copy.  I think this is the first time I've noticed this failure.
2022-03-16 21:41:48 <ikke> I've reported it here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13603#note_222783
2022-03-16 21:46:45 <syscomet> thank you; sorry, didn't know where better to report than here
2022-03-16 21:47:53 <ikke> no worry
2022-03-16 21:54:32 <ncopa> syscomet: thanks for the heads up
2022-03-16 21:58:27 <ncopa> should be fixed now
2022-03-16 22:03:07 <syscomet> Confirmed: 833 octets, much more recent embedded timestamp but I'll cross my fingers that the input file was from a trusted source ;)  Signature checks out. 
2022-03-17 00:05:15 <maxice8> Ikke: released atools 20.2.0 with print-go-deps, when go 1.18 is merged it can be upgraded
2022-03-17 08:05:29 <ncopa> good morning. seems like stunnel build hangs on some arches
2022-03-17 08:15:21 <ikke> Do I recall correctly that stunnel is hanging more frequently?
2022-03-17 09:13:35 <ncopa> i think i have seen stunnel hanging in the past yes
2022-03-17 09:19:22 <ncopa> im pushing 3.12.10, 3.13.8 and 3.14.4 releases now
2022-03-17 09:34:30 <ncopa> look ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.12.10-3.13.8-3.14.4-released.html
2022-03-17 09:36:32 <ikke> Looks good
2022-03-17 10:20:05 <omni> \o/
2022-03-17 16:02:13 <fcolista> psykose, meson 0.61.3 has been released
2022-03-17 16:02:20 <psykose> feel free to bump
2022-03-17 16:02:31 <psykose> i will then remove the upstream patches and patch out the cmake test
2022-03-17 16:02:35 <fcolista> ok
2022-03-17 16:02:35 <psykose> and i think you can merge the tests after
2022-03-17 16:02:40 <psykose> they are all fine, the cmake one flakes
2022-03-17 16:02:50 <psykose> (and it's reported upstream)
2022-03-17 16:02:58 <psykose> the rest of the disables are just samurai stuff
2022-03-17 16:03:28 <fcolista> ok good. Pushed
2022-03-17 16:17:21 <psykose> i think also the circular deps are not good to have for check are they
2022-03-17 16:17:37 <psykose> unless we set ABUILD_BOOTSTRAP on first build, but i don't think we do
2022-03-17 16:19:08 <ikke> psykose: I did use that to bootstrap 3.15
2022-03-17 16:19:11 <psykose> ah
2022-03-17 16:19:13 <psykose> then it is fine
2022-03-17 16:19:18 <psykose> it's only circular with checkdepends
2022-03-17 16:19:52 <psykose> (only asking because one of those circles are not tested for in the test and then i have to disable another one..)
2022-03-17 16:23:07 <psykose> i think 3.16 is going to be not fun
2022-03-17 16:23:40 <psykose> there are a ton of stray things that need patches for gcc11, a ton of things that need a patch for meson 0.60 (that positional arg thing), probably some ppc64le failures with binutils..
2022-03-17 16:24:00 <psykose> i try and fix everything i find but half of aports is not rebuilt since those
2022-03-17 16:25:08 <psykose> it might be a good idea to try and get a 3.16 builder soon and just make it track master and see how a full world goes, then we can iron out these things before trying to make the larger changes (i.e. openssl3)
2022-03-17 16:30:22 <psykose> fcolista: tests pass :) ready to merge if you want to
2022-03-17 16:31:21 <ncopa> the idea is to set up 3.16 builder early april
2022-03-17 16:32:54 <psykose> works for me
2022-03-17 23:53:27 <craftyguy> networkmanager 1.36 has a bad regression from 1.34 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006622)
2022-03-17 23:53:49 <craftyguy> reverting the upgrade patch isn't straight forward, since there were some follow up patches to make a new subpackage, etc
2022-03-17 23:54:09 <craftyguy> so I'm wondering if I should revert + bump pkgrel or how this should be handled
2022-03-17 23:54:13 <psykose> mm
2022-03-17 23:54:17 <psykose> that does not look very good
2022-03-17 23:54:23 <psykose> right when i was about to get into comfy bed for real
2022-03-17 23:54:50 <craftyguy> yeah it's not... breaks mobile data connections on postmarketOS, for carriers that are ipv6 only (like mine :( )
2022-03-17 23:55:08 <craftyguy> psykose: I'm willing to make a patch, I'm just not sure how exactly to handle a revert in that case
2022-03-17 23:55:17 <craftyguy> s/revert/downgrade/
2022-03-17 23:55:17 <alpine-meetbot> craftyguy meant to say: psykose: I'm willing to make a patch, I'm just not sure how exactly to handle a downgrade in that case
2022-03-17 23:55:21 <psykose> and the patch that did it is +-2k
2022-03-17 23:55:23 <psykose> uhh i'll do it
2022-03-17 23:55:25 <psykose> sec
2022-03-17 23:55:39 <craftyguy> ah thank you :) sorry to keep you up longer
2022-03-17 23:57:17 <psykose> pushed
2022-03-17 23:57:28 <psykose> oh oops
2022-03-17 23:57:28 <psykose> :)
2022-03-17 23:57:30 <psykose> i keep doing that
2022-03-17 23:59:50 <craftyguy> nice, thank you so much :)
2022-03-17 23:59:50 <psykose> built, should be fine now
2022-03-18 01:30:15 <panekj> psykose sleep >:(
2022-03-18 03:12:47 <basicer> Hello! Fairly new to contributing to alpine.  I was wondering if anyone had some advise on how I could push aports !30649 forward?
2022-03-18 03:15:20 <boomanaiden154> It looks like you’ve addressed all the concerns, so just rebasing it will bump it up the queue and someone will take note of it soon.
2022-03-18 03:16:36 <boomanaiden154> Leo has been the one reviewing and merging most of the changes in main, and he’s been dedicating less time to the project recently, so it might be a little bit of time before someone with merge access can do anything.
2022-03-18 03:17:16 <basicer> I've rebased it once so far, but it seems to have mostly gone unnoticed. 
2022-03-18 03:18:34 <boomanaiden154> If you rebase it a couple of times, it’s bound to be high up in the queue once someone goes to review stuff at some point.
2022-03-18 03:19:11 <boomanaiden154> Someone with merge access might also check IRC at some point and see your message.
2022-03-18 03:24:03 <basicer> =]
2022-03-18 05:51:59 <ikke> omni: hmm, now uutils-coreutils fails on all enabled arches :/
2022-03-18 06:00:58 <ptrc> doesn't musl have a lower default soft limit of file descriptors?
2022-03-18 06:02:08 <ptrc> i mean, hm, it's weird that cp opens more than 1024 files for a directory literally called "dir_with_10_files"
2022-03-18 06:02:43 <ptrc> nevermind then
2022-03-18 06:16:48 <ikke> it succeeds if I manually run abuild check
2022-03-18 06:36:06 <ikke> ptrc: apparently the test sets a limit
2022-03-18 06:36:24 <ikke> https://tpaste.us/x5p1 
2022-03-18 06:36:49 <ikke> so for some reason, the descriptors are not closed
2022-03-18 06:37:03 <ikke> or, it goves above a threshold where it would close it
2022-03-18 07:55:58 <ncopa> basicer: a friendly ping here on IRC usually helps. thanks!
2022-03-18 08:12:36 <basicer> \o/
2022-03-18 08:24:19 <panekj> ncopa: friendly ping about !31227 :)
2022-03-18 08:24:53 <panekj> as well, as good morning to everyone
2022-03-18 08:39:39 <ikke> ncopa: can it be mqtt-exec is leaking fds or something? uutils-coreutils sets ulimit nofiles to 9 and copies a directory with 10 entries, with the expectation that fds are closed again
2022-03-18 08:40:00 <ikke> The test fails when built via mqtt-exec
2022-03-18 08:40:12 <ikke> If I run abuild check, it passes
2022-03-18 08:46:16 <ddevault> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/32061
2022-03-18 08:46:22 <ddevault> was merged but does not look like the builders picked it up
2022-03-18 08:47:26 <ikke> ddevault: seems they did? https://pkgs.alpinelinux.org/packages?name=bupstash&branch=edge
2022-03-18 08:47:38 <ddevault> hm
2022-03-18 08:48:01 <ddevault> dl-cdn.a.o did not get the new package
2022-03-18 08:48:35 <ikke> http://dl-cdn.alpinelinux.org/alpine/edge/community/x86_64/bupstash-0.11.0-r0.apk
2022-03-18 08:48:42 <ddevault> o_O
2022-03-18 08:48:48 <ddevault> maybe it's not in the index?
2022-03-18 08:48:51 <ddevault> apk policy bupstash
2022-03-18 08:48:51 <ikke> perhaps
2022-03-18 08:48:53 <ddevault> what do you get
2022-03-18 08:49:37 <ikke> https://tpaste.us/YrMr 
2022-03-18 08:49:57 <ddevault> https://paste.sr.ht/~sircmpwn/5c7b07316cf76f8ba39097f40f469244edbc52ec
2022-03-18 08:50:17 <ddevault> oh duh
2022-03-18 08:50:18 <ddevault> 3.15
2022-03-18 08:50:20 <ddevault> disregard the idiot
2022-03-18 09:25:38 <ncopa> ikke: quite possible that mqtt-exec leaks fds
2022-03-18 11:04:56 <indy> skarnet, hi thanks for s6-overlay package
2022-03-18 11:05:13 <indy> skarnet, any plans for 'reviving' it also for 3.15?
2022-03-18 11:09:38 <indy> ikke, ncopa, hi, is acceptable to move package from unmaintained for released branches?
2022-03-18 11:10:25 <psykose> if skarnet really wants to put in the work to move s6-overlay to 3.15 then i guess it's not impossible
2022-03-18 11:16:09 <hcs> Do I have to notify the appropriate maintainer about merge requests on GitLab, or will they automatically get a notification? I see other MRs on alpine/mkinitfs that have not been addressed for several months. I'm not trying to rush anything, just asking.
2022-03-18 11:21:30 <indy> ddevault, hi no plans to package shit? :)
2022-03-18 11:22:19 <ddevault> no.
2022-03-18 11:35:43 <ncopa> indy: i guess it depends if it was moved in edge and if there is a maintainer. generally we dont introduce things that causes breakages in stable branches. "adding" new packages normally don't do that so it should not be any problem as long as there is a maintainer
2022-03-18 11:37:01 <ncopa> hcs: i normally have a look at those once in a while (monthly?). the current challenge with mkinitfs is the lack of test suite. people want add features/fixes that causes regressions
2022-03-18 11:37:18 <psykose> technically it's not a move from unmaintained, as it was a completely new rewrite :)
2022-03-18 11:37:52 <ncopa> hcs: do you have any specific MR in mind?
2022-03-18 11:39:29 <hcs> Yes, I've just created https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/101 which has been running in production on a fleet of embedded devices since 2019 at my workplace
2022-03-18 11:39:40 <ncopa> hcs: the problem is that I no longer trust that people test their own code changes, and I have not had the time (or interest) to test it for them
2022-03-18 11:39:46 <ncopa> ok. thats good info
2022-03-18 11:39:50 <psykose> that one looks fine to me
2022-03-18 11:40:00 <psykose> if it breaks something, shoot me :p
2022-03-18 11:40:20 <hcs> It's worrysome that there is no test suite for mkinitfs. You shouldn't take my word for it, but in my opinion that change is stable.
2022-03-18 11:40:58 <ktprograms> While we're talking about this, can someone please take a look at https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/99 and https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/100? Thanks!
2022-03-18 11:41:04 <hcs> What permissions does the test runner have? If I were to write automated testing for it, I would need to run qemu
2022-03-18 11:41:07 <ikke> hcs: we agree on that
2022-03-18 11:41:12 <ikke> (re test suite)
2022-03-18 11:41:44 <ikke> hcs: the runners run in docker
2022-03-18 11:43:14 <hcs> ikke: So it's just the regular gitlab-ci runner in docker? I'll have see if qemu likes to run in docker. It seems gross, but doable.
2022-03-18 11:43:31 <indy> ncopa, you mean maintainer of package itself or for branch?
2022-03-18 11:43:41 <ncopa> maintainer for the package
2022-03-18 11:48:27 <hcs> Ubuntu 21.10 uses zstd compression for initramfs by default. Is there a reason why Alpine still uses gzip?
2022-03-18 11:48:31 <nmeum> I wonder if it really makes sense for us to maintain our own initramfs generator in the long run, maybe we could consider using a pre-existing solution at some point? for example I recently packaged booster as alternative to mkinitfs and succesfully used on a few system, though not sure if it fits our needs a default
2022-03-18 11:48:44 <nmeum> *as a default
2022-03-18 11:50:33 <panekj> if I recall correctly, there was some issues with busybox zstd, hcs
2022-03-18 11:50:55 <ncopa> that should not matter for the initramfs
2022-03-18 11:51:19 <psykose> that was for modules specifically pretty sure
2022-03-18 11:51:23 <psykose> regarding kmod
2022-03-18 11:51:33 <panekj> ah
2022-03-18 11:51:34 <hcs> panekj: What kind of issues? Does busybox zstd garble the data, or is it just picky about pipes/options/files etc?
2022-03-18 11:51:37 <psykose> and needing a full kmod in the initrd to decompress
2022-03-18 11:51:49 <psykose> the issue is busybox kmod doesn't have zstd support at all
2022-03-18 11:51:51 <ncopa> gz has been a pretty good solution wrt tradoffs compression speed / compression ration / decompression speed/ memory usage
2022-03-18 11:51:53 <panekj> glad to be around smarter people than me :P
2022-03-18 11:52:06 <ncopa> gz is not best at anything, but its not bad on any of those either
2022-03-18 11:52:14 <psykose> there is some patch somewhere for bb kmod zstd, but it has not been merged upstream for a year now
2022-03-18 11:52:26 <ncopa> so gz has been pretty good tradeoff
2022-03-18 11:52:27 <psykose> but i think keeping modules at gz and using zst for the rest is ok
2022-03-18 11:52:32 <hcs> ncopa: I agree. Gzip is the epitome of "fine". I was just wondering.
2022-03-18 11:52:54 <ncopa> but the real answer is that nobody has asked for zstd initramfs until now
2022-03-18 11:52:58 <psykose> the kernel itself is fine as zstd, i think Hello71 had a draft mr for adding it and removing the debug syms
2022-03-18 11:53:00 <ncopa> and I think we should consider it
2022-03-18 11:53:18 <psykose> and yes, for mkinitfs it's just a toggle, the code is already there i think
2022-03-18 11:53:34 <psykose> yeah, it is
2022-03-18 11:53:41 <ncopa> just have had more urgen fires to deal with...
2022-03-18 11:54:40 <ncopa> hcs: we desperately need a testsuite from mkinitfs. unfortunately it is non-trivial. but there was someone who had a proposal using qemu expat that didnt look too bad
2022-03-18 11:55:02 <ncopa> part of the challenge is that i also want it multiarch....
2022-03-18 11:55:11 <ncopa> but i guess its better to start somewhere
2022-03-18 11:55:24 <ikke> hcs: no promises, but we could look into setting up a dedicated runner for it
2022-03-18 11:55:27 <indy> ncopa, psykose even it is rewrite of s6-overlay, 3.15 is the only release without working package so new one will not break anything
2022-03-18 11:55:41 <psykose> i'm aware, the only thing you need is for skarnet to go and do it
2022-03-18 11:57:12 <ncopa> hcs: thank you!
2022-03-18 12:01:29 <Ariadne> to be clear, the minio removal is not a value judgement on AGPL, but rather on MinIO's conduct regarding the relicensing
2022-03-18 12:04:53 <psykose> less code equals more better
2022-03-18 12:05:21 <panekj> ncopa: can !31689 be also merged, seems straightforward 
2022-03-18 12:20:02 <ncopa> re testsuite for mkinitfs: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/86#note_213176
2022-03-18 12:55:51 <nmeum> speaking of stale MRs in alpine repos: ncopa, do you mind if I move forward with https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/134 (that would allow us to no longer require the chmod-clean option for go aports, CC: ikke)
2022-03-18 12:57:14 <ikke> no objection from me
2022-03-18 13:02:29 <Hello71> i don't understand the problem with zstd modules and initramfs at all. there should be no problem, because initramfs modules should never be individually compressed in the first place. they should always be decompressed before adding to initramfs or modloop
2022-03-18 13:02:30 <skarnet> indy, psykose: huh? the new s6-overlay package is in edge now, in community/ unless I'm mistaken. Is there something more that needs to be done?
2022-03-18 13:02:40 <psykose> skarnet: they want it in 3.15 too
2022-03-18 13:02:42 <Hello71> this caused a big size increase in 3.15
2022-03-18 13:03:11 <psykose> nmeum: lgtm
2022-03-18 13:04:05 <hcs> ncopa, ikke: I'll investigate docker with qemu tied together with ash sometime in the following two fridays. I won't promise anything, but I'll at least have a look at it.
2022-03-18 13:04:20 <Hello71> does mkinitfs really need qemu-system to be tested? why can't we use chroot or namespaces? the only thing this wouldn't catch is if initramfs format is not suitable for kernel
2022-03-18 13:04:21 <ikke> thanks
2022-03-18 13:04:25 <indy> skarnet, yes :) alpine 3.15 has no s6-overlay, i just tried to compile with current skalibs and s6 and it worked
2022-03-18 13:04:27 <skarnet> psykose: can this be done? I have no idea how to. It just means backporting the package and its dependencies, I don't think it would impact much or be exceedingly hard, but so far I've only added stuff to edge.
2022-03-18 13:04:56 <skarnet> indy: no, it will compile for sure but it won't work unless you get the latest dependencies
2022-03-18 13:04:57 <psykose> you branch off 3.15-stable and then you target 3.15-stable in the mr
2022-03-18 13:05:25 <skarnet> psykose: okay I'll do that, prob not today though
2022-03-18 13:05:38 <psykose> up to you :) i'm not the one making the request
2022-03-18 13:05:45 <psykose> just saying it's possible if everyone feels like it
2022-03-18 13:05:57 <hcs> Hello71: It doesnt strictly speaking NEED qemu, but it's definately the easiest way to confirm that it can produce output that can be used by the kernel / can boot correctly
2022-03-18 13:07:26 <indy> skarnet, in both, edge and 3.15, are skalibs and s6 2.11.x and execline-2.8.x
2022-03-18 13:08:17 <skarnet> there are more dependencies than that :P
2022-03-18 13:08:40 <skarnet> I mean it *can* be done for sure, it's just not instant
2022-03-18 13:09:21 <omni> ikke: but they ran fine in gitlab ci...
2022-03-18 13:09:53 <ikke> omni: yes, I have a feeling it's something about leaked file descriptors
2022-03-18 13:10:08 <ikke> ie, subprocesses inherriting open fds from the parnet
2022-03-18 13:10:09 <indy> skarnet, which deps?
2022-03-18 13:10:14 <ikke> parent*
2022-03-18 13:10:31 <ikke> omni: the test artificially limits the amount of open fds to 9
2022-03-18 13:11:16 <skarnet> indy: they're listed in the APKBUILD. s6-rc, s6-linux-init, s6-portable-utils, s6-linux-utils, s6-dns, s6-networking, and s6-overlay-helpers, IIRC
2022-03-18 13:11:53 <skarnet> basically the whole skaware stack because John didn't bother with a scalpel and cut the thing with an axe instead
2022-03-18 13:13:03 <skarnet> (and I added s6-l-i and s6-rc for the rewrite because 80% of the needed work was already done therein)
2022-03-18 13:15:57 <omni> ikke: we'll see if I look at it before the next release, but I'll try to remember to look at your comments in the merged MR and perhaps also report something upstream
2022-03-18 13:16:18 <psykose> it does sound like an mqtt issue
2022-03-18 13:16:42 <omni> !31823 !29072
2022-03-18 13:18:45 <panekj> can we also get merged https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/135 since we already set these optimisations in APKBUILD? cc: nmeum psykose ariadne ncopa
2022-03-18 13:18:59 <psykose> +1 from me as well
2022-03-18 13:19:41 <psykose> also https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/60
2022-03-18 13:19:48 <psykose> and https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/128
2022-03-18 13:19:54 <psykose> so newapkbuild is a little more accurate
2022-03-18 13:20:01 <panekj> +1 to both
2022-03-18 13:20:30 <psykose> they shouldn't cause any issues on merge, unless abuild is modified on builders and it won't upgrade
2022-03-18 13:22:47 <panekj> re: 128 we could do same for packages built with Go via 'go get .' in prepare()
2022-03-18 13:23:59 <psykose> most likely, not sure if it always works
2022-03-18 13:24:44 <panekj> will check out later :) I also have to figure out how to deal with fish completions situation
2022-03-18 13:31:28 <Hello71> about https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/135, i am a little concerned about the potential increase in compile time
2022-03-18 13:32:11 <Hello71> 16 -> 1 codegen units is theoretically up to 16x slowdown, and fat lto is another ~2-10x slowdown
2022-03-18 13:32:23 <panekj> correct
2022-03-18 13:32:37 <panekj> but we already do that in aports for rust packages
2022-03-18 13:32:39 <Hello71> i think additive not multiplicative though
2022-03-18 13:33:28 <Hello71> oh, also i think this MR will break compiling rust itself
2022-03-18 13:33:47 <Hello71> dylibs cannot be compiled with lto
2022-03-18 13:33:49 <indy> skarnet, i see, on the other hand they are not explicitly requested except skalib-dev in s6-overlay-helpers
2022-03-18 13:34:21 <Hello71> also https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/122 would be very good to have before branching 3.16
2022-03-18 13:34:23 <skarnet> indy: don't mix build-time and run-time dependencies
2022-03-18 13:34:24 <panekj> Hello71, I was about to say that rust itself would need to have it unset
2022-03-18 13:34:34 <Hello71> we can counteract some of this rust bloat
2022-03-18 13:34:55 <panekj> lol
2022-03-18 13:35:44 <psykose> does rust itself run cargo --release
2022-03-18 13:36:16 <panekj> you were fixing rust once, you should know :P
2022-03-18 13:36:43 <psykose> i will assume 'yes'
2022-03-18 13:36:46 <psykose> it also does break firefox
2022-03-18 13:42:46 <Hello71> rust lto works with firefox for me
2022-03-18 13:43:09 <Hello71> i use linker-plugin-lto and thinlto but if anything that should cause more breakage, not less
2022-03-18 13:43:30 <indy> skarnet, i don't mix them. in that case 'depends' should contain minimal working versions of dependencies
2022-03-18 13:44:38 <psykose> those 4 variables in the environment don't specifically, there is some objdump that fails near the end
2022-03-18 13:44:51 <psykose> and firefox lto doesn't work on alpine either, since llvm ooms at 9G for some reason (out of 256G)
2022-03-18 13:44:58 <psykose> only on x86_64
2022-03-18 13:45:37 <psykose> reproduced on like 4 machines
2022-03-18 13:45:42 <psykose> meanwhile it works fine on glibc gentoo
2022-03-18 13:46:22 <psykose> if you want to have fun with it, just add --enable-lto=cross to the firefox apkbuild
2022-03-18 13:46:41 <psykose> or =full, same issue, and then it ooms on 32-bit arches too
2022-03-18 13:47:18 <skarnet> indy: ah, you mean the version numbers. Yeah, I usually don't mention them in edge (except for breaking changes, i.e. major versions) because I update everything in edge at once and when stuff gets built, everything is built at the same time with always the latest versions.
2022-03-18 13:47:49 <Hello71> i guess probably fat lto is not tested so much
2022-03-18 13:48:30 <psykose> cross is thin
2022-03-18 13:49:55 <psykose> (at least going off what it says everywhere and seeing a bunch of lld threads during the process..)
2022-03-18 13:50:15 <psykose> and i have no idea why it's only x86_64 that fails with it
2022-03-18 13:52:29 <Hello71> when you say oom do you mean killed or ENOMEM
2022-03-18 13:52:55 <psykose> 30:40.86 LLVM ERROR: out of memory
2022-03-18 13:53:00 <psykose> 30:40.86 Allocation failed
2022-03-18 13:53:29 <psykose> if i do it on the 256G container it never goes past like 9-11G in htop while printing that
2022-03-18 13:53:34 <psykose> so.. neither? no idea why it does
2022-03-18 13:53:52 <panekj> is there a way to look through makedepends in all packages?
2022-03-18 13:53:54 <psykose> this was an issue on 12.0.1 llvm as well as the current one
2022-03-18 13:54:42 <psykose> panekj: to print a list of packages that depend on something in makedeps?
2022-03-18 13:54:54 <panekj> yeah
2022-03-18 13:54:58 <Hello71> at a guess, it is too many threads
2022-03-18 13:55:06 <psykose> `ap revdep pkgname` probably, inside main/ or community/ or something
2022-03-18 13:55:14 <Hello71> interacting with overcommit heuristics
2022-03-18 13:55:20 <psykose> Hello71: sure, but i have like 12, and on my laptop i have 8
2022-03-18 13:55:26 <psykose> do they really expect like 2 threads or something
2022-03-18 13:55:36 <psykose> it builds fine on glibc gentoo with the same config or whatnot
2022-03-18 13:57:01 <Hello71> well it is a total mem divided by threads thing
2022-03-18 13:57:23 <psykose> it would be weird given the other arches pass fine, and aarch64 ci has the same ratio
2022-03-18 13:58:00 <psykose> well, slightly higher actually
2022-03-18 13:58:03 <psykose> 32 instead of 48
2022-03-18 13:59:09 <psykose> 32/64G so like 1:2G.. that would be like 8 threads for me, so let me cap it to 6 and see if it 'magically works' now locally
2022-03-18 13:59:54 <panekj> psykose: which package provides that
2022-03-18 14:00:02 <psykose> lua-aports
2022-03-18 14:01:23 <panekj> sh: cd: line 26: can't cd to /home/pj/.dev/gitlab.a.o/alpine/aports/*: No such file or directory
2022-03-18 14:01:43 <panekj> :>
2022-03-18 14:02:34 <psykose> you have to be in main/
2022-03-18 14:02:36 <psykose> etc
2022-03-18 14:02:56 <panekj> ahm
2022-03-18 14:02:59 <nmeum> regarding the "fetch dependencies in prepare()" thing it would be nice to have abuild rootbld run the prepare stage unconditionally without --unshare-net before we merge that
2022-03-18 14:03:29 <psykose> i don't think the order matters because everything already fails in rootbld
2022-03-18 14:03:59 <psykose> (we do need to not unshare net in prepare(), but that change doesn't break anything any more than it already is regarding it)
2022-03-18 14:04:42 <nmeum> the entire premise of the change is that we can make stuff like go and rust build in rootbld without options=net
2022-03-18 14:05:29 <nmeum> if that isn't feasible because running only prepare() without --unshare-net turns out to be difficul to implement then I don't see the benefit of that "fetch go/rust dependencies in prepare()" change
2022-03-18 14:05:58 <psykose> i suppose
2022-03-18 14:06:10 <psykose> but i think we will manage :p
2022-03-18 14:08:03 <nmeum> right but I don't see why the prepare() change is urgent if rootbld doesn't support prepare() without unshare net in the first place
2022-03-18 14:08:50 <nmeum> iirc Ariadne was looking into patching rootbld to run prepare() without --unshare-net?
2022-03-18 14:14:09 <nmeum> the rust and go changes to abuild.conf should probably be done before we setup the 3.16 builders
2022-03-18 15:08:58 <indy> skarnet, keep us informed about 3.15 merge request :)
2022-03-18 15:09:48 <skarnet> will do.
2022-03-18 16:45:22 <pabloyoyoista> Hi, I am trying to split some files from a package (gnome-shell) into a subpackage (gnome-shell-schemas) to limit the number of things pulled by packages that only depend on some files and not the package. One dev experimented some issues during testing upgrades and downgrades, where the files were removed by the original packaged, but not installed by the subpackage (even if the subpackage was reported installed)
2022-03-18 16:46:05 <pabloyoyoista> And "apk fix gnome-shell-schemas" fixed the problem, but I am unsure if there should be some "replaces" or something else that one would have to add in these cases
2022-03-18 16:46:25 <pabloyoyoista> (subpackage inheriting ownership over some files)
2022-03-18 16:46:59 <psykose> does apk error during the upgrade to the new subpackage versions
2022-03-18 16:47:34 <pabloyoyoista> Not on first upgrade
2022-03-18 16:48:04 <pabloyoyoista> Or at least neither of us experimented it first time we tested
2022-03-18 16:49:11 <pabloyoyoista> This is the discussion if it helps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/31086#note_222314
2022-03-18 16:49:45 <pabloyoyoista> If anybody has an informed opinion on whether we should let it be or add something else, it would be great :)
2022-03-18 20:18:47 <ikke> smcavoy: ansible-lint checksum failed
2022-03-18 20:19:49 <ikke> ah, psykose already fixed it
2022-03-18 20:20:33 <psykose> i broke it in the first place a month ago :p
2022-03-18 21:19:16 <smcavoy> ikke: where did the checksum fail? 
2022-03-18 21:19:53 <ikke> psykose: on the builders, but psykose already fixed it. The source archive name had a version hardcoded
2022-03-18 21:20:26 <ikke> http://dup.pw/alpine/aports/8988abf2ad7c
2022-03-18 21:20:40 <psykose> these links load so fast now
2022-03-18 21:21:00 <ikke> Loaded before I even open the window
2022-03-18 21:30:28 <smcavoy> ah.. weird/whoops :) 
2022-03-19 06:13:22 <boomanaiden154> Does anyone have any idea why apk would be saying "package format file error" in the middle of installing large (about 1.6GB) APKs generated by abuild?
2022-03-19 10:38:25 <ptrc> looks like something's broken with cgit
2022-03-19 10:38:31 <ptrc> downloading https://git.alpinelinux.org/abuild/snapshot/abuild-3.9.0.tar.xz returns a corrupted archive
2022-03-19 10:42:45 <ikke> psykose: ^
2022-03-19 11:15:09 <psykose> that's weird
2022-03-19 11:15:20 <psykose> it's corrupted and throws an error but still extracts and has the files
2022-03-19 11:17:27 <ptrc> has some files, but not all of them
2022-03-19 11:18:10 <psykose> the gzip is also similarly broken
2022-03-19 11:18:42 <ptrc> the file is almost exactly 64KB
2022-03-19 11:19:19 <ptrc> so maybe a wsgi/cgit update added some kind of size limit?
2022-03-19 11:20:31 <psykose> fixed i guess
2022-03-19 11:20:38 <psykose> try again
2022-03-19 11:21:21 <ptrc> seems to work, thanks
2022-03-19 11:21:34 <psykose> ...cgit is magical software
2022-03-19 11:22:47 <psykose> (the fix was disabling the cache that i enabled)
2022-03-19 11:22:53 <ikke> ha!
2022-03-19 11:22:57 <psykose> :)
2022-03-19 11:23:03 <psykose> i left a comment on the thing for future readers
2022-03-19 11:23:04 <ikke> We need to keep a counter
2022-03-19 11:23:13 <psykose> we do
2022-03-19 11:23:19 <ikke> I think the count is 3
2022-03-19 11:23:28 <psykose> let me guess
2022-03-19 11:23:31 <psykose> the three of us each
2022-03-19 11:23:32 <psykose> :p
2022-03-19 11:23:34 <ikke> :D
2022-03-19 11:23:36 <psykose> :D
2022-03-19 11:26:20 <psykose> algitbot: ping
2022-03-19 11:31:35 <psykose> algitbot: ping
2022-03-19 11:31:41 <psykose> strange
2022-03-19 11:36:17 <psykose> looking at these logs now, no wonder cgit gets so swamped randomly
2022-03-19 11:36:26 <psykose> 50% of the requests are 'repology linkchecked'
2022-03-19 11:37:20 <ikke> yeah, all kinds of scraping going on
2022-03-19 14:50:41 <nmeum> I pushed the Go 1.18 with a (hopefully) temporary workaround for an upstream issue on ppc64le. let me know if anyone encounters issues with building go aports on ppc64le
2022-03-19 14:52:38 <ikke> interesting
2022-03-19 14:52:49 <ikke> do we need to rebuild go related packages as well?
2022-03-19 14:54:16 <nmeum> ikke: afaik there have been no security fixes in 1.18 though we haven't rebuild for 1.17.8 and 1.17.7 (which did include security fixes)
2022-03-19 15:33:41 <ikke> I suppose we'll see any issue with the 3.16 rebuild anyway
2022-03-19 15:33:56 <ikke> (not that I expect many)
2022-03-19 15:34:39 <ikke> oh, apparently michal did want to do it
2022-03-19 15:40:37 <ikke> First casualty: Something in this program imports go4.org/unsafe/assume-no-moving-gc to declare that it assumes a non-moving garbage collector, but your version of go4.org/unsafe/assume-no-moving-gc hasn't been updated to assert that it's safe against the go1.18 runtime.
2022-03-19 15:43:06 <psykose> another explicitly can't build with 1.18 because of some dependency
2022-03-19 15:43:47 <ikke> dendrite
2022-03-19 15:43:50 <ikke> gomplate
2022-03-19 15:44:34 <ikke> quic-go 0.25.0 supports 1.18
2022-03-19 15:44:41 <ikke> https://github.com/lucas-clemente/quic-go/releases/tag/v0.25.0
2022-03-19 15:46:57 <ikke> psykose: are you working on something/
2022-03-19 15:47:11 <psykose> currently no
2022-03-19 15:47:14 <ikke> ok
2022-03-19 15:47:16 <psykose> do you want me to fix the mess
2022-03-19 15:47:36 <psykose> i would rather let polanski do it :)
2022-03-19 15:47:40 <ikke> heh
2022-03-19 15:48:01 <ikke> I can make a summary issue
2022-03-19 15:48:03 <psykose> sure
2022-03-19 15:50:57 <ikke> #13614
2022-03-19 16:19:12 <psykose> fwiw
2022-03-19 16:19:16 <psykose> this is a good rebuild to have
2022-03-19 16:19:23 <psykose> because a lot of these now shrink up to 15% in size
2022-03-19 16:19:30 <psykose> they optimised some linker stuff
2022-03-19 16:19:36 <ikke> cool
2022-03-19 16:21:02 <psykose> https://img.ayaya.dev/sEfMgJdLcdsX.png
2022-03-19 16:21:07 <psykose> :)
2022-03-19 16:21:33 <psykose> (0 apkbuild changes)
2022-03-19 16:24:48 <nmeum> sweet
2022-03-19 16:37:36 <ikke> I need to patch a dependency of shelfmt
2022-03-19 16:37:57 <ikke> shfmt*
2022-03-19 16:40:13 <psykose> i'm doing testing/ preliminarily
2022-03-19 16:40:26 <psykose> one by one locally
2022-03-19 16:40:27 <psykose> :)
2022-03-19 16:40:48 <ikke> I think you mean preemtively?
2022-03-19 16:40:51 <psykose> of course
2022-03-19 16:40:58 <psykose> but i prefer the imaginary words
2022-03-19 16:41:01 <ikke> heh :)
2022-03-19 16:41:04 <psykose> :3
2022-03-19 17:26:38 <Ermine> Were there any pango-related changes last two weeks?
2022-03-19 17:27:22 <ikke> Last commit to main/pango was in august
2022-03-19 17:27:26 <Ermine> I'm trying to test gajim but pango segfaults with messages pango_font_get_hb_font: assertion 'PANGO_IS_FONT (font)' failed
2022-03-19 17:32:34 <Ermine> I didn't change apkbuild
2022-03-19 17:43:01 <psykose> main/pango was recently updated
2022-03-19 17:43:19 <psykose> the commit says august
2022-03-19 17:43:21 <psykose> but it's wrong
2022-03-19 17:43:26 <psykose> it was like last week
2022-03-19 17:43:50 <psykose> that sounds like missing a font or something
2022-03-19 17:44:06 <psykose> those errors are usually printed in CI when there is no font installed, or a *specific* font is not installed
2022-03-19 17:44:18 <psykose> and not really related to pango
2022-03-19 17:44:23 <ikke> ooh, looked at author date, not commit date
2022-03-19 17:44:40 <psykose> it was me that updated it :) technically
2022-03-19 17:59:08 <Ermine> Ah, I installed ttf-dejavu and it worked, thanks! Will add to checkdepends
2022-03-19 18:06:01 <boomanaiden154> Does someone with an AMD/NVIDIA graphics mind testing Vulkan on !31994?
2022-03-19 18:06:27 <psykose> sure
2022-03-19 18:06:39 <psykose> is there something to test it with other than looking at chrome://gpu
2022-03-19 18:06:59 <psykose> (and are there any flags to pass)
2022-03-19 18:07:13 <boomanaiden154> You need to set it to enabled in chrome://flags
2022-03-19 18:07:18 <boomanaiden154> I’m unsure of the command line options.
2022-03-19 18:07:38 <boomanaiden154> https://webglsamples.org
2022-03-19 18:07:46 <boomanaiden154> I’m pretty sure these should render using Vulkan if you have it enabled.
2022-03-19 18:08:46 <boomanaiden154> It should also just be used for page rendering.
2022-03-19 18:08:48 <psykose> well they render
2022-03-19 18:08:50 <psykose> vulkan says enabled
2022-03-19 18:09:05 <psykose> works on wayland too
2022-03-19 18:09:09 <boomanaiden154> What does chrome://gpu say?
2022-03-19 18:09:21 <psykose> https://img.ayaya.dev/OW85YITl3SIX.png
2022-03-19 18:09:29 <psykose> https://img.ayaya.dev/Cw4YHUwaukbJ.png
2022-03-19 18:09:43 <psykose> rx460, mesa 22
2022-03-19 18:10:52 <psykose> i notice the disabled compositing
2022-03-19 18:11:21 <psykose> it works without vulkan
2022-03-19 18:12:17 <psykose> but uh it seems fine to me
2022-03-19 18:14:04 <boomanaiden154> Interesting. I’ll probably put the Vulkan SO into its own sub package since it’s disabled by default.
2022-03-19 18:14:33 <boomanaiden154> Once I get that done and upgrade chromium to *.74, the MR should be ready to push.
2022-03-19 18:14:40 <psykose> you sure there's a point
2022-03-19 18:14:42 <psykose> it's probably like 1mb
2022-03-19 18:15:04 <psykose> also to make me even happier, do you feel like fixing those 4 near-meaningless lint warnings
2022-03-19 18:15:04 <psykose> :3
2022-03-19 18:15:37 <psykose> i just like green checkmarks
2022-03-19 18:16:07 <boomanaiden154> I can fix the lint warnings. There’s not a ton of point, but it’s not a lot of work, and a bunch of other stuff is separated out in the APKBUILD.
2022-03-19 18:16:19 <boomanaiden154> I like the green checkmarks too.
2022-03-19 18:16:31 <psykose> :)
2022-03-19 18:17:20 <boomanaiden154> Still trying to figure out how to get a debug symbols package. The one that I generated locally for some reason won’t install.
2022-03-19 18:17:52 <boomanaiden154> And probably not something to put into the infrastructure due to the debug symbols being 1.6GB compressed.
2022-03-19 18:19:51 <psykose> mm
2022-03-19 18:19:56 <psykose> i don't know why it failed to install either
2022-03-19 18:20:06 <psykose> i remember some bug with huge packages in apk, but afaik it was patched
2022-03-19 19:01:18 <Ermine> I'm building another package. On install step, it outputs 'Using simplified encoding detection, you might want to install chardet.' These messages disappeared after I installed py3-chardet. Should I add it as a dependency? 
2022-03-19 19:01:28 <psykose> sure
2022-03-19 19:07:54 <minimal> psykose: I see on build.alpinelinux.org that Nomad is being rebuilt. This will fail as its a know issue with no current fix: !28610
2022-03-19 19:09:01 <minimal> I guess the only way forward is to either remove nomad or else find a way to build it without its UI
2022-03-19 19:09:02 <ikke> Can't we disable the interface, like we did for vault?
2022-03-19 19:09:15 <minimal> ikke: you read my mind lol
2022-03-19 19:14:52 <psykose> yes
2022-03-19 19:18:54 <psykose> i have disabled it for now
2022-03-19 19:19:06 <psykose> feel free to cycle builders
2022-03-19 19:20:05 <minimal> I'll have a go at a disable-ui patch locally
2022-03-19 19:20:16 <ikke> psykose just pushed it
2022-03-19 19:24:18 <minimal> ah, misread that. Anyway I'll have a go at packaging a more recently version (without ui) as we're lagging behind on secfixes due to the ui issue
2022-03-19 19:24:50 <psykose> good luck
2022-03-19 19:24:55 <psykose> ikke: you should cycle the builders
2022-03-19 19:25:03 <ikke> do I have to?
2022-03-19 19:25:11 <psykose> it's stuck on them
2022-03-19 19:25:13 <psykose> and will be forever
2022-03-19 19:25:23 <psykose> unless you already did
2022-03-19 19:25:58 <psykose> x86_64/s390x/arm*/aarch64
2022-03-19 19:28:38 <psykose> technically ppc too since eventually it will reach it
2022-03-19 19:29:02 <ikke> just did everything except ppc64le
2022-03-19 19:29:05 <psykose> mhm
2022-03-19 19:34:47 <Ermine> mhm... one test fails on s390x at !32271
2022-03-19 19:49:28 <psykose> i would tell you why but first you would have to buy me a mainframe
2022-03-19 19:49:30 <psykose> :^)
2022-03-19 19:56:54 <psykose> this go rebuild stuff sure is scuffed
2022-03-19 20:12:11 <Ermine> psykose: getting a mainframe was exactly what I thought about :D
2022-03-19 20:12:43 <Ermine> Should I disable tests at all or exclude s390x from target architectures
2022-03-19 20:13:20 <boomanaiden154> The best option is probably to just deselect that individual test.
2022-03-19 20:19:06 <nmeum> you could also try gathering some more information, e.g. in s390x abuild rootbld and report the failure upstream
2022-03-19 20:19:19 <nmeum> failures only on s390x are often a sign of an endiness problem upstream
2022-03-19 20:19:28 <nmeum> since s390x is our only big-endian architecture
2022-03-19 20:19:33 <psykose> so you _are_ buying me an entire mainframe :o
2022-03-19 20:19:38 <psykose> /s
2022-03-19 20:19:53 <psykose> did you see the couple ppc fails
2022-03-19 20:19:56 <nmeum> with qemu-binfmt `CBUILD=s390x abuild rootbld` should suffice to reproduce most s390x ci issues
2022-03-19 20:20:10 <psykose> true
2022-03-19 20:20:15 <nmeum> me? no, I haven't looked at the go build stuff yet
2022-03-19 20:20:26 <nmeum> but I would assume ppc go issues to fail during build, not during test
2022-03-19 20:20:36 <psykose> there's a few that segfault the final binary
2022-03-19 20:20:45 <psykose> after build, on running it
2022-03-19 20:21:06 <psykose> there's a few pings on gitlab if you want the specific packages
2022-03-19 20:21:44 <nmeum> *nod*
2022-03-19 20:21:50 <nmeum> can look into it later
2022-03-19 20:21:53 <psykose> no rush :)
2022-03-19 20:22:04 <psykose> there's like 10 broken packages on every arch to fix in the meantime anyway
2022-03-19 20:22:09 <psykose> we sure broke our builders real good
2022-03-19 20:22:09 <nmeum> hehe
2022-03-19 20:22:18 <nmeum> yeah, might have been a bit too early for a go rebuild
2022-03-19 20:22:25 <psykose> it's good
2022-03-19 20:22:30 <psykose> this version shrinks like every go bin
2022-03-19 20:22:32 <nmeum> given that 1.18 was just released a few days ago and most go upstreams haven't adjusted yet
2022-03-19 20:22:32 <psykose> by 10-15%
2022-03-19 20:22:36 <psykose> in size
2022-03-19 20:22:37 <psykose> truly magic
2022-03-19 20:22:46 <nmeum> right
2022-03-19 20:22:56 <psykose> but yeah, it was indeed early
2022-03-19 20:23:37 <Ermine> nmeum: thank you, will try
2022-03-19 20:23:40 <psykose> i saw the commit and felt like going to sleep for 2 days instead
2022-03-19 20:23:42 <psykose> but alas
2022-03-19 20:23:56 <Hello71> aren't old s390x machines pretty cheap
2022-03-19 20:24:04 <Hello71> if your electricity is ~free
2022-03-19 20:24:10 <psykose> never seen any
2022-03-19 20:24:31 <psykose> s390x is since.. 2015?
2022-03-19 20:24:44 <psykose> unless i have some dates mixed up
2022-03-19 20:27:51 <Ermine> nmeum: seems like qemu-binfmt binary does not exist: https://pkgs.alpinelinux.org/contents?file=qemu-binfmt&path=&name=&branch=edge
2022-03-19 20:28:22 <nmeum> Ermine: it's an openrc-service provided by the qemu-openrc service
2022-03-19 20:28:34 <Ermine> Ah
2022-03-19 20:28:35 <nmeum> the openrc service just does a bunch of binfmt registrations for qemu-user stuff
2022-03-19 20:28:36 <Hello71> afaik it's a huge mess of acronyms but s390x isn't a specific machine
2022-03-19 20:29:15 <nmeum> Ermine: so you need like qemu-openrc and qemu-s390x and then do rc-service qemu-binfmt start
2022-03-19 20:29:35 <nmeum> and afterwards the rootbld command I mentioned above
2022-03-19 20:29:44 <nmeum> psykose: the glad go failure is weird
2022-03-19 20:29:57 <nmeum> it doesn't segfault if I execute it directly
2022-03-19 20:29:59 <nmeum> only in fakeroot
2022-03-19 20:30:01 <psykose> hmm
2022-03-19 20:30:11 <psykose> but it works in fakeroot on x86_64..
2022-03-19 20:30:15 <nmeum> yes
2022-03-19 20:30:19 <psykose> that is very strange
2022-03-19 20:30:20 <Ermine> Seems like it will not work in lxc container: /proc/sys/fs/binfmt_misc/register: Permission denied
2022-03-19 20:30:21 <nmeum> I currently have an ongoing email thread
2022-03-19 20:30:26 <psykose> oh no
2022-03-19 20:30:28 <nmeum> with the fakeroot author about a bug in fakeroot
2022-03-19 20:30:59 <nmeum> but this should only effect fakeroot >=1.27 so not sure whats going on here
2022-03-19 20:31:17 <nmeum> but the specific glad failure I can't reproduce on ppc64le outside fakeroot
2022-03-19 20:33:02 <nmeum> Ermine: yes, in containers it will probably not work
2022-03-19 20:34:02 <Hello71> well it will work if you register it on host
2022-03-19 20:34:10 <Hello71> depends on what you mean by "it"
2022-03-19 20:34:36 <nmeum> right
2022-03-19 20:36:20 <nmeum> psykose: https://tpaste.us/Bkon <-- this fixes the glad build for example
2022-03-19 20:36:27 <nmeum> because now the glad binary is no longer run in fakeroot
2022-03-19 20:36:45 <nmeum> so, in this particular case it looks like a fakeroot, and not a go issue
2022-03-19 20:37:13 <psykose> alright, i guess i will throw that in then
2022-03-19 20:37:23 <nmeum> wait let me commit that with a comment :D
2022-03-19 20:37:32 <nmeum> so it doesn't get changed back
2022-03-19 20:38:35 <psykose> sure, feel free
2022-03-19 20:38:41 <psykose> i was about to push it with your name :)
2022-03-19 20:38:49 <psykose> you can do it
2022-03-19 20:39:53 <nmeum> pushed it with a quick comment, hopefully have the time to revisit this eventually  ':D
2022-03-19 20:39:57 <nmeum> let's hope it also works on the builders
2022-03-19 20:41:24 <ikke> to be honest, I don't even think it's that bad to build the completion in the build phase :)
2022-03-19 20:41:33 <psykose> it's not :)
2022-03-19 20:41:33 <nmeum> yeah, it's fine
2022-03-19 20:41:39 <psykose> but bugs want to be fixed
2022-03-19 20:41:42 <psykose> they yearn for it
2022-03-19 20:41:44 <nmeum> but still: running glab in fakeroot shouldn't cause a segfault
2022-03-19 20:41:49 <nmeum> and if it does, that's a sign of a bug somewhere
2022-03-19 20:41:50 <ikke> agreed
2022-03-19 20:51:25 <smcavoy> hello, MR !29675 has failing tests. I checked and it requires fuse / mount  and some other bits for the tests to pass. I do not think these are enabled/possible to enable on the builders, correct?
2022-03-19 20:51:50 <ikke> smcavoy: correct
2022-03-19 20:55:41 <smcavoy> has the idea of a option to run in a vm instead of a container been brought up before?
2022-03-19 20:57:06 <minimal> when writing secfixes part of a APKBUILD, do I list entries for the most recent of the releases which contain a CVE fix or all of the previous releases in different branches (such as 1.2.x, 1.1.1, etc) that contain the fix?
2022-03-19 21:00:34 <Ermine> in virtual machine, qemu-binfmt cannot find proc/sys/fs/binfmt_misc . Do I need to load any kernel module? Or is it impossible to do in vm?
2022-03-19 21:04:08 <psykose> minimal: it corresponds to our releases, so if 1.1.1,1.1.2,1.1.3 fixed cves, and you upgrade 1.1.0->1.1.3, you add all of them under 1.1.3
2022-03-19 21:04:23 <psykose> sorting them is also nice
2022-03-19 21:04:52 <ikke> smcavoy: containers are way more convenient for us
2022-03-19 21:05:13 <ikke> vms are 'expensive'
2022-03-19 21:06:41 <minimal> psykose: I'm doing the secfixes for Nomad 1.2.6 where its a jump from 1.1.1. Some secfixes apply to both 1.2.3 and 1.1.9 for example. So I just put them under 1.2.3, right?
2022-03-19 21:07:00 <ikke> minimal: you specify the version that we have published that fixes it
2022-03-19 21:07:06 <psykose> yeah, since they affected prior versions
2022-03-19 21:07:13 <psykose> well
2022-03-19 21:07:17 <psykose> you put it under 1.2.6
2022-03-19 21:07:22 <psykose> but you do include them, sure
2022-03-19 21:07:26 <minimal> ok
2022-03-19 21:27:57 <Ermine> nmeum: so, CBUILD=s390x abuild rootbld didn't reproduce that issue
2022-03-19 21:47:18 <smcavoy> Ermine: I think the package `qemu-openrc` will handle setting that up for you, it installs `/etc/init.d/qemu-binfmt` which can be run to enable all that
2022-03-19 21:52:07 <smcavoy> Ermine: "all that"  includes loading the module `binfmt_misc`
2022-03-19 21:53:38 <smcavoy> so the package `qemu-openrc` should be installed and the service `qemu-binfmt` started which loads the `binfmt_misc` module and registers the various binary formats and interpreters (qemu-system-*)
2022-03-19 21:58:08 <Ermine> smcavoy: thank you
2022-03-19 22:01:52 <smcavoy> ikke: indeed vms are more expensive there does seem to be a class of package that benefits from a vm over a container though I guess that is a ever shrinking amount
2022-03-19 22:04:57 <psykose> time to move our infra to microvms
2022-03-19 22:05:05 <psykose> just gotta find the $100,000,0000000000
2022-03-19 22:36:48 <smcavoy> micro vms might not cut it, to many limitation :)
2022-03-19 22:41:42 <panekj> firecracker goes brrrr
2022-03-19 23:59:06 <nmeum> Ermine: unfourtunate, probably hard to debug then
2022-03-20 08:28:50 <psykose> also a lot of the go rebuilds dont have tests so they probably segfault in the same way with the json mod at runtime but were undetected
2022-03-20 08:40:59 <ikke> good to know
2022-03-20 13:00:59 <ptrc> could someone take a look at !32211? i'm not quite sure how to get it to build packages in correct order
2022-03-20 13:02:12 <ktprograms> ptrc: There seems to be a circular dependency. (py3-pip depends on py3-nox, but py3-nox depends on py3-pip)
2022-03-20 13:15:12 <ptrc> ah, you're right... i'll tinker with unzip + compileall
2022-03-20 14:43:51 <eschwartz> why does pip depend on nox? Why does anything depend on pip?
2022-03-20 14:44:41 <ikke> For your last question, PEP517/518
2022-03-20 14:45:10 <eschwartz> no
2022-03-20 14:45:14 <eschwartz> absolutely not
2022-03-20 14:45:45 <eschwartz> that pep does NOT mean "everything depends on pip", and I'm super mad at PyPA for strongly implying it
2022-03-20 14:46:02 <ikke> eschwartz: note that it's a makedepend, not a run-time dependency
2022-03-20 14:46:13 <eschwartz> it should not be a makedepend either
2022-03-20 14:46:38 <ikke> Well, it's the case currently
2022-03-20 14:46:40 <ikke> for some packages
2022-03-20 14:48:47 <ikke> Is there another build front-end one should use?
2022-03-20 14:49:12 <eschwartz> first of all, nox uses setuptools (setup.cfg, no setup.py), so it is possible to use python -c 'from setuptools import setup; setup()' install --root=... or create a two-line setup.py with "echo ... > setup.py"
2022-03-20 14:50:00 <eschwartz> second of all, I'm surprised that pip requires nox at build? I would assume perhaps it requires it during check, maybe
2022-03-20 14:50:57 <ikke> eschwartz: that does not make a lot of difference. abuild installs depepends + makedepends + checkdepends (if checks are enabled) 
2022-03-20 14:52:18 <ikke> (before building anything)
2022-03-20 14:53:36 <eschwartz> well, the difference is pretty major, if it is only for check then you'd be able to disable the build cycle during bootstrap
2022-03-20 14:53:42 <eschwartz> ... oh, but you're using it during build() to install HTML documentation?
2022-03-20 14:53:55 <eschwartz> You don't need that, you can manually run sphinx-build
2022-03-20 14:54:12 <ikke> eschwartz: yes, for bootstrap we can disable running the checks (and thus installing checkdepends)
2022-03-20 14:54:36 <eschwartz> there's a comment about:
2022-03-20 14:54:38 <eschwartz> > Could not import extension myst_parser (exception: No module named 'myst_parser')
2022-03-20 14:54:55 <eschwartz> probably a missing makedep that nox installs over the internet using `pip install` :)
2022-03-20 14:56:31 <eschwartz> really. nox just creates a virtualenv, pip installs docs/requirements.txt, and runs sphinx-build
2022-03-20 15:19:17 <ptrc> eschwartz: yeah, i've thought about running sphinx-build directly, but on any future updates people would have to check the noxfile if the command hasn't changed in any way
2022-03-20 15:20:54 <ptrc> as for installing wheels, only pip/setuptools generates launcher scripts, i've been looking into this for a while now and haven't found a good solution
2022-03-20 15:21:30 <ptrc> unpacking wheels directly into sitedir and running `python3 -m compileall` works... fine otherwise
2022-03-20 15:21:48 <eschwartz> ptrc: why is this any different from any other package where people would have to check the readme or whatever to see if commands changed?
2022-03-20 15:24:25 <ptrc> in my experience usually when something changes in the build process, it's not building correctly anymore and it's easy to catch in tests
2022-03-20 15:24:59 <ptrc> but docs aren't really tested by anything, so if there wouldn't be any added/removed files, someone could miss that
2022-03-20 15:26:21 <eschwartz> but if sphinx-build is no longer the correct command to run, then it should error out and fail the build...
2022-03-20 15:27:23 <ptrc> not really, for example, they might add "-t something" to filter what's shown in the docs, "-A version=<something>", etc.
2022-03-20 15:31:00 <eschwartz> do you think that is actually likely in the first case. In the second case, they already get the version number from conf.py which reads pip's own __init__.py and extracts the version, why would they make noxfile.py read that version too and pass it as a command line argument to sphinx
2022-03-20 15:32:03 <ptrc> i don't think this is *very* likely, i'd be fine with leaving just raw sphinx-build command with maybe a comment to check noxfile just in case
2022-03-20 15:32:14 <eschwartz> that's what I'd do, yeah
2022-03-20 15:32:29 <ptrc> i just think that when it's possible, it would be cool to use what upstream actually does
2022-03-20 15:39:31 <ptrc> in case of the launcher scripts, imo it would be cool to have a small wrapper for aports that unzips wheels and adds simple launcher scripts as seen in https://github.com/ninjaaron/fast-entry_points
2022-03-20 15:40:01 <ptrc> ooor poetry could support installing to another directory
2022-03-20 15:41:05 <ptrc> but that still leaves stuff built with py3-build
2022-03-20 15:47:54 <eschwartz> ptrc: this was a huge topic of discussion in arch/gentoo etc. around when setuptools decided to deprecate 'setup.py install', as neither project wanted to use `pip install`
2022-03-20 15:48:10 <eschwartz> I see that alpine followed the fedora approach of just running lots of pip everywhere :(
2022-03-20 15:49:06 <eschwartz> anyway, the result of that discussion -- and the strongly held beliefs of arch/gentoo that failure to provide a non-pip installer meant that PEP 517/518 was hostile to distros -- there is now https://github.com/pypa/installer/issues/52
2022-03-20 15:49:42 <eschwartz> so, please package py3-installer and replace *all* `pip install` with `python -m installer --destdir=... *.whl`
2022-03-20 15:50:13 <ptrc> oh wow, that's nice
2022-03-20 15:50:19 <ptrc> thanks for the link
2022-03-20 15:50:51 <eschwartz> it compiles bytecode too
2022-03-20 15:50:55 <ptrc> exactly what i was looking for, back when i moved some projects away from the deprecated pyproject2setuppy
2022-03-20 15:51:40 <eschwartz> you will need to use py3-build to create wheels, probably, since python setup.py bdist_wheel is a dead end due to "we are removing the CLI"
2022-03-20 15:51:58 <eschwartz> however, for poetry and flit you can do `flit build --format wheel`
2022-03-20 15:52:16 <ptrc> yeah, that's how it's currently done
2022-03-20 15:52:21 <eschwartz> and poetry build -f wheel
2022-03-20 15:52:38 <ptrc> wheels built with either python3 -m build or ^, installed with pip install
2022-03-20 15:52:50 <eschwartz> because yeah, those may be easier makedeps than python3 -m build
2022-03-20 15:53:11 <ptrc> ah, apparently py3-installer is packaged already..
2022-03-20 15:53:23 <ptrc> wish i knew about it sooner
2022-03-20 15:54:13 <eschwartz> it's only in community? Should likely be moved to main if it is going to be the universal install tool
2022-03-20 15:54:44 <ikke> yes, eventually
2022-03-20 15:56:40 <Ariadne> eschwartz: can the python community pick a packaging tool already
2022-03-20 15:56:51 <Ariadne> every 18 or so months, they come up with a new one, and deprecate the old ones
2022-03-20 15:58:07 <eschwartz> Yes, that is indeed depressing, I know
2022-03-20 15:58:32 <Hello71> more pypa than "the python community" i think
2022-03-20 15:58:49 <Ariadne> the whatever
2022-03-20 15:59:02 <Hello71> pip whatever will fix it! [insert xkcd here]
2022-03-20 15:59:28 <eschwartz> I really want Meson to eventually support creating .dist-info metadata
2022-03-20 15:59:58 <eschwartz> and then meson can stop using setuptools, but instead install itself with ./meson.py setup builddir && ./meson.py install -C builddir
2022-03-20 16:00:35 <eschwartz> also, other projects wishing some sanity can use meson and still be pip-compatible and everything
2022-03-20 16:03:43 <eschwartz> sadly, PyPA *also* requires toml as a file format
2022-03-20 16:04:01 <eschwartz> which they standardized in 2016, but didn't add to the stdlib until 2022
2022-03-20 16:04:04 <ikke> And does not provide a base library for parsing toml
2022-03-20 16:04:07 <ikke> oh
2022-03-20 16:04:09 <ikke> they just did?
2022-03-20 16:04:10 <eschwartz> we'll finally have it in 3.11
2022-03-20 16:04:15 <ikke> heh
2022-03-20 16:04:18 <eschwartz> they merged it days ago
2022-03-20 16:04:38 <eschwartz> it only took them 6 years...
2022-03-20 16:05:52 <eschwartz> however, Meson has a stdlib-only policy, because you must be able to use Meson as a low-level bootstrap tool and that's hard enough when it is written in python, so we absolutely refuse to introduce the python packaging ecosystem *too*.
2022-03-20 16:06:32 <ikke> nod
2022-03-20 16:06:43 <ikke> But there is also muon
2022-03-20 16:06:57 <eschwartz> at least today you just need to build python, then package meson ./packaging/create_zipapp.py --outfile $DESTDIR/usr/bin/meson
2022-03-20 16:07:34 <eschwartz> and it works, a single-file executable that relies solely on the stdlib and doesn't even need setuptools to build
2022-03-20 16:08:53 <eschwartz> openwrt uses this, for example
2022-03-20 16:09:28 <eschwartz> if you do it, it *will* prevent other python packages from adding an `install_requires` on meson, but eh, who cares about that for a bootstrap package?
2022-03-20 16:09:42 <eschwartz> like, you would need that for building py3-scipy, sure
2022-03-20 16:10:07 <eschwartz> anyway
2022-03-20 16:11:09 <eschwartz> once 2026 swings around I'll definitely add toml imports to meson and use that to power a PEP 517/518 compatible workflow inside meson, so people can use a sane build system that just happens to also produce pip wheels as a side effect
2022-03-20 17:49:03 <ikke> Hmm, setuptools 60 seems to require jaraco.text, which needs setuptools to build..
2022-03-20 17:52:36 <boomanaiden154> The python circular dependencies are never ending, as always.
2022-03-20 18:00:13 <boomanaiden154> ikke: it looks jaraco is only used during check and maybe for the GitHub release?
2022-03-20 18:00:23 <boomanaiden154> It also looks like it’s vendored into the repository.
2022-03-20 18:13:51 <ikke> psykose: what was the issue with upgrading setuptools again? 
2022-03-20 18:16:33 <boomanaiden154> It had to get downgraded several times in the past because it broke some packages.
2022-03-20 18:17:14 <ikke> yes, that should have been solved now
2022-03-20 18:17:38 <ikke> issue was that it was missing the egg-info files
2022-03-20 18:18:12 <ikke> some bootstrap issue again
2022-03-20 18:18:18 <ikke> but that has been solved in newer versions
2022-03-20 18:20:38 <ikke> boomanaiden154: apparently the source archive from github does not have the _vendor dir
2022-03-20 18:21:13 <ikke> and it's pkg_resources that needs jaraco.text, not just during the test phase
2022-03-20 18:22:07 <ikke> https://tpaste.us/yvPn
2022-03-20 18:23:56 <ikke> Oh, n/m, I do  get the _vendor dir
2022-03-20 18:29:38 <ikke> ah, we explicitly remove the _vendor directories
2022-03-20 18:29:42 <ikke> in the APKBUILD
2022-03-20 18:29:47 <boomanaiden154> Yep.
2022-03-20 18:30:05 <boomanaiden154> It looks like if you removed the devendoring logic in prepare or added an exception for Jaraco, it should work.
2022-03-20 18:30:30 <boomanaiden154> Because the init.py file in pkg_resources by default uses the vendored version.
2022-03-20 18:32:21 <ikke> it means it will also ship these packages
2022-03-20 18:34:08 <boomanaiden154> As in it will also install to system all the vendored packages?
2022-03-20 18:34:46 <ikke> yes, but it remains in the _vendor dir
2022-03-20 18:35:03 <ikke> so would only be used by setuptools
2022-03-20 18:36:35 <boomanaiden154> That is what I would expect. It doesn't seem like there's any easy way around that. Other than something like a setuptools-bootstrap package that uses vendored dependencies to get jaraco packaged.
2022-03-20 18:37:05 <ikke> yea
2022-03-20 18:42:53 <elibrokeit> jaraco.* is such a garbage collection of garbage :(
2022-03-20 18:43:29 <elibrokeit> Also setuptools >=60 has big ramifications in the "tries to take over distutils" scene
2022-03-20 18:43:59 <elibrokeit> Which wreaks havoc on stuff like numpy.distutils and suchlike
2022-03-20 18:44:22 <elibrokeit> Setuptools is such a pile of hacks and monkey-patched hacks
2022-03-20 18:44:36 <elibrokeit> Not sure anyone knows how it works anymore...
2022-03-20 18:45:01 <elibrokeit> Sadly, and shamefully, *still* the best that pypa has to offer for packaging.
2022-03-20 18:46:33 <psykose> ikke: last i checked it was ok, just one removed module that like 3 things used
2022-03-20 18:46:52 <psykose> but i didnt build community with it
2022-03-20 18:48:54 <ikke> elibrokeit: I suppose for now we can remain on 59.3.0
2022-03-20 18:55:10 <elibrokeit> lol, jaraco.text provides a public API for `lorem_ipsum` as a string
2022-03-20 18:55:34 <elibrokeit> that is actually funny
2022-03-20 18:56:18 <ikke> heh
2022-03-20 19:04:23 <joneskoo> Is there anything I can do to make sure https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/31953 is merged for the next release?
2022-03-20 19:04:40 <joneskoo> (scripts/mkimg.arm.sh: add support for Raspberry Zero 2 W
2022-03-20 19:05:03 <panekj> gently ping ncopa about it
2022-03-20 21:58:45 <skarnet> minimal: I'm deep in the woods with my betterfoo work, so I did the utmps changes you wanted, can you take a look at !32304 and tell me if it addresses the issue?
2022-03-20 21:59:36 <skarnet> (0.1.2.0 adds configurability of the wtmp filename, the new package adds a btmpd service, and some unrelated refactoring)
2022-03-20 22:00:06 <minimal> skarnet: thanks, I'll have a look
2022-03-21 01:10:56 <skarnet> wow, I didn't think there were so many MRs for alpine-conf :D
2022-03-21 01:11:10 <skarnet> I got #1, woohoo!
2022-03-21 01:11:52 <skarnet> wait, no, I'm an idiot
2022-03-21 01:12:03 <skarnet> just a wrong maneuver. :P
2022-03-21 01:17:40 <skarnet> So I got #59, that's not #1, but that's still not a lot.
2022-03-21 01:17:50 <skarnet> no, algitbot...
2022-03-21 01:18:07 <skarnet> I mean https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/59
2022-03-21 01:19:14 <skarnet> ncopa is listed as the maintainer for alpine-conf, but I suppose any core dev can take a look. :)
2022-03-21 01:19:44 <skarnet> that said, time for sleep, have fun looking at that in the morning. :P
2022-03-21 12:46:41 <psykose> nice work!
2022-03-21 12:48:34 <skarnet> thanks. ncopa is already making me rewrite all of it :D
2022-03-21 12:55:47 <psykose> time to set tabwidth in your editor :)
2022-03-21 12:56:50 <panekj> just grab editorconfig plugin for whatever you use
2022-03-21 12:57:21 <Ermine> May I ask somebody to review !32271 ?
2022-03-21 12:57:48 <psykose> why the tests removed homie
2022-03-21 12:58:37 <Ermine> one test from that suite was failing on s390x
2022-03-21 12:58:57 <psykose> add a comment for it
2022-03-21 12:59:12 <panekj> or note it in patch file
2022-03-21 12:59:54 <psykose> indeed
2022-03-21 13:00:28 <panekj> I stole ptrcnull method of git {add,commit,show} :P
2022-03-21 13:00:43 <panekj> works really well
2022-03-21 13:00:54 <psykose> show > something.patch ?
2022-03-21 13:00:59 <panekj> yes
2022-03-21 13:01:03 <psykose> i do that for something that is not patching one file yeah
2022-03-21 13:01:07 <psykose> and format-patch instead
2022-03-21 13:17:13 <Ermine> I can try to figure out which test fails in this suite
2022-03-21 13:49:20 <Ermine> Where should I place a comment for patch? before source= or after?
2022-03-21 13:49:36 <psykose> in the patch
2022-03-21 13:56:52 <Ermine> Ok
2022-03-21 14:19:11 <Ermine> thank you psykose
2022-03-21 14:49:34 <psykose> :)
2022-03-21 15:14:23 <Androw> Can we easily restrict patching to one arch? Should we do this when the patch is needed for one arch atm but doesn't break building on other?
2022-03-21 15:15:06 <panekj> if [ "$CARCH" = "s390x" ]; then
2022-03-21 15:15:16 <panekj> if I remember the variable name correctly
2022-03-21 15:16:00 <ikke> That's correct, but you cannot use that for sources 
2022-03-21 15:16:38 <psykose> you can make a .patch.noauto and manually patch -p1 the file in prepare yourself with a conditional
2022-03-21 15:16:41 <psykose> if you really feel like it
2022-03-21 15:17:07 <ikke> Yes, that's the way I'd do it 
2022-03-21 15:17:40 <panekj> although it would be better if source was patched to work on all targeted arches
2022-03-21 15:17:46 <panekj> most languages allow to check for cpu arch
2022-03-21 15:23:51 <Androw> So either make the patch non automatic, or include the check in the source code, and so in the patch. Thanks!
2022-03-21 15:33:37 <Hello71> i call it .diff for maximum confusion
2022-03-22 14:47:16 <handlerug> should *-src packages that install kernel modules using AKMBUILD depend on akms? I see that some (testing/openrazer) do but others don't (testing/linux-apfs-rw-src)
2022-03-22 14:47:36 <handlerug> I do depend on it in my local package but I thought I'd ask about the general convention
2022-03-22 14:47:54 <psykose> they probably should
2022-03-22 19:58:30 <ikke> ncopa: apparently we need to do another 3.15 release
2022-03-22 19:58:35 <ikke> #13623
2022-03-22 21:37:53 <Hello71> this sounds bogus
2022-03-22 21:38:06 <ikke> why?
2022-03-22 21:38:08 <Ariadne> its not
2022-03-22 21:38:26 <ikke> it's fixed in -r3, which is not part of 3.15.1
2022-03-22 21:39:02 <Hello71> er, never mind
2022-03-22 21:41:02 <Ariadne> edge is missing secfixes data for it
2022-03-22 21:41:18 <ikke> yeah, noticed it
2022-03-22 21:41:24 <ikke> didn
2022-03-22 21:41:33 <ikke> didn't know if it was on purpose or not
2022-03-23 04:09:59 <Daanct12> good afternoon
2022-03-23 07:33:55 <ncopa> good morning
2022-03-23 07:34:12 <ncopa> ugh. so we need a 3.15.2 release
2022-03-23 07:34:21 <ncopa> im on it
2022-03-23 07:50:56 <ikke> thanks
2022-03-23 07:55:02 <ncopa> hum... seems like 3.15.1 aarch64 does not boot in vmware
2022-03-23 08:07:56 <Daanct12> good morning ncopa 
2022-03-23 09:11:58 <ncopa> so, alpine-virt 3.15.0 boots in aarch64 vmware. 3.15.1 does not
2022-03-23 09:15:37 <ncopa> also, upgrading the kernel from a 3.15.0 makes it not boot anymore. hum..
2022-03-23 09:57:23 <clandmeter> ncopa: boots as in iso or after installation?
2022-03-23 10:14:42 <clandmeter> ncopa: i also forgot, we need to update the console option for aarch64
2022-03-23 10:14:57 <clandmeter> aarch64 uses ttyAMA0
2022-03-23 10:23:15 <Ermine> clandmeter: does this option need to be updated for armv7 by the way?
2022-03-23 10:30:39 <clandmeter> Ermine: not sure about armv7
2022-03-23 10:34:11 <Ermine> Actually there are two console= options in armv7 iso (console=tty0 console=ttyS0,11520)
2022-03-23 10:38:23 <Ermine> It can be possibly related to #13576 , because I get to the same situation, but VM continues to work and eat my cpu
2022-03-23 10:41:58 <ikke> Ermine: the latter should probably ttyS0,115200
2022-03-23 10:42:02 <ikke> (missing a 0)
2022-03-23 10:42:35 <Ermine> Yeah
2022-03-23 10:53:00 <ncopa> seems to be an issue with apple's hypervisor framweork and kernels 5.15.28 and newer
2022-03-23 10:53:19 <ncopa> https://lore.kernel.org/stable/907327093697278cd816aafec9e20b3e@kernel.org/T/
2022-03-23 10:59:59 <clandmeter> Ermine: have you tried to use ttyAMA0?
2022-03-23 11:00:18 <clandmeter> i just tried to boot armv7 iso but the kernel panics
2022-03-23 11:00:28 <ncopa> i think armv7 may be a different problem
2022-03-23 11:01:22 <Ermine> clandmeter: same thing
2022-03-23 11:01:39 <clandmeter> looks like a problem with armv7 initramfs
2022-03-23 11:01:42 <Ermine> 'Attempted to kill init'
2022-03-23 11:01:59 <clandmeter> Ermine: yes, remove quiet 
2022-03-23 11:02:46 <clandmeter> could be related to initramfs compression
2022-03-23 11:06:51 <clandmeter> but it looks like armv7 also needs ttyAMA0
2022-03-23 11:07:34 <ncopa> Ermine: what host is qemu running on?
2022-03-23 11:07:59 <Ermine> x86_64
2022-03-23 11:13:02 <clandmeter> ncopa: armv7 is a different issue, i can reproduce it here. just fails to run init.
2022-03-23 11:13:32 <clandmeter> i would guess its something with initramfs
2022-03-23 11:13:45 <ncopa> ok
2022-03-23 11:13:49 <ncopa> or efi?
2022-03-23 11:13:58 <clandmeter> i remember for 32bit arm the initramfs cannot be compressed
2022-03-23 11:14:15 <clandmeter> efi loads fine
2022-03-23 11:14:23 <clandmeter> runs the kernel
2022-03-23 11:15:01 <clandmeter> and panics when trying /init
2022-03-23 11:16:05 <clandmeter> but i had to take ovmf from somewhere else as we dont ship it, iirc
2022-03-23 11:16:12 <ncopa> isnt it the efi firmware that loads the initramfs?
2022-03-23 11:16:30 <clandmeter> it does
2022-03-23 11:16:38 <ncopa> in any case, i guess its not a blocker for 3.15.2 which we need to release today
2022-03-23 11:16:57 <clandmeter> its broken, not sure thats concidered a blocker :)
2022-03-23 11:17:09 <clandmeter> would be nice it we can change the serial device for arm
2022-03-23 11:17:32 <Ermine> so it can print panic message at least
2022-03-23 11:25:50 <clandmeter> ncopa: i guess the virt kernel has problems for armv7
2022-03-23 11:29:28 <clandmeter> the armv7 and aarch64 virt configs are a lot different
2022-03-23 11:29:50 <Ermine> There's message "Freeing initrd memory: 6344K" before /init launches
2022-03-23 11:33:28 <ncopa> $  diff -u virt.aarch64.config virt.armv7.config | tpaste
2022-03-23 11:33:28 <ncopa> https://tpaste.us/Jr6v
2022-03-23 13:23:04 <omni> !29072 !31823
2022-03-23 13:54:41 <ncopa> can someone please help me review https://wwwtest.alpinelinux.org/posts/Alpine-3.15.2-released.html?
2022-03-23 13:54:58 <ncopa> omni: i may be able to review those after 3.15.2 is out or tomorrow
2022-03-23 14:01:07 <Hello71> #13576
2022-03-23 14:17:01 <handlerug> what's the best way to include binary firmware blobs and their licenses for ${pkgname}-src packages? I'm planning to upstream an xone package, a kernel module that implements support for xbox controllers, and it needs a firmware blob for wireless dongle support
2022-03-23 14:17:07 <handlerug> https://www.microsoft.com/en-us/legal/terms-of-use https://github.com/medusalix/xone/blob/master/install/firmware.sh
2022-03-23 14:18:56 <handlerug> I don't think prompting the user to press Enter is the best solution, if it'll ever work. or maybe the user doesn't want to install these blobs if they only need wired controller support
2022-03-23 14:19:17 <handlerug> then there's a possibility of installing that script into /usr/bin, but that's messy IMO
2022-03-23 14:19:46 <Ermine> You can make a subpackage containing firmware blobs
2022-03-23 14:21:52 <handlerug> I'll probably proceed this way, I also had some questions about the license but linux drivers ship a lot of blobs too
2022-03-23 14:23:49 <Hello71> linux kernel itself is not supposed to contain any blobs
2022-03-23 14:23:58 <Hello71> amdgpu driver is arguably an exception
2022-03-23 14:24:09 <Ermine> Afaik linux-firmware is an exception
2022-03-23 14:24:10 <Hello71> blobs are contained in linux-firmware repository
2022-03-23 14:24:27 <handlerug> yeah and they're installed more often than not
2022-03-23 14:24:33 <Hello71> and package
2022-03-23 14:24:33 <handlerug> that's what I meant, sorry
2022-03-23 14:25:20 <Ermine> https://gitlab.alpinelinux.org/alpine/tsc/-/issues/23
2022-03-23 14:25:29 <Hello71> linux-firmware is different, it is generally agreed that the firmware has unrestricted distribution
2022-03-23 14:26:00 <Hello71> whereas the linked microsoft terms of use (which it is not quite clear applies?) says "Unless otherwise specified, the Services are for your personal and non-commercial use. You may not modify, copy, distribute, transmit, display, perform, reproduce, publish, license, create derivative works from, transfer, or sell any information, software, products, or services obtained from
2022-03-23 14:26:02 <Hello71> the Services."
2022-03-23 14:26:25 <Hello71> read in the ordinary manner, this prohibits alpine from distributing the binaries in question
2022-03-23 14:26:58 <Hello71> the least worst solution is probably to install a "setup-xone" program which downloads the questionable firmware
2022-03-23 14:57:03 <daniel_tirzuman> hello
2022-03-23 14:57:46 <daniel_tirzuman> is #alpine-linux channel working?
2022-03-23 14:59:48 <Ermine> Yes
2022-03-23 15:02:25 <daniel_tirzuman> for me it appears as an empty channel
2022-03-23 15:02:41 <daniel_tirzuman> and when I try to send a message, I get: <irc.oftc.net> Error(404): #alpine-linux Cannot send to channel
2022-03-23 15:07:16 <psykose> are you sure you joined it
2022-03-23 15:07:49 <Ermine> And you need to register in oftc and then log in
2022-03-23 15:11:00 <daniel_tirzuman> well I registered with pwd and email, then I got a link and clicked the link to verify and here I am
2022-03-23 15:11:26 <psykose> you probably tried to join it before you were registered
2022-03-23 15:11:52 <daniel_tirzuman> hmm, seems like you are correct, I joined again and it works
2022-03-23 15:11:56 <daniel_tirzuman> thank you :-)
2022-03-23 17:10:06 <handlerug> is there a way to maintain package cache between `abuild rootbld` invocations? 561 MiB of packages is quite a lot
2022-03-23 17:11:22 <ikke> handlerug: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/133
2022-03-23 17:12:18 <psykose> you can manually hotpatch in that --cache-dir line for now
2022-03-23 17:12:18 <handlerug> ikke: tyvm!
2022-03-23 17:12:30 <handlerug> hm true
2022-03-23 18:39:20 <handlerug> should a theoretical zfs-src package contain `install_if="zfs linux-edge"` so that it gets installed automatically, or it's better to leave this decision to the user?
2022-03-23 18:40:07 <psykose> user
2022-03-23 18:40:14 <psykose> since it's for any kernel
2022-03-23 18:40:21 <handlerug> makes sense, thanks
2022-03-23 18:42:43 <handlerug> last question: should it be submitted testing or main?
2022-03-23 18:42:54 <handlerug> submitted to*
2022-03-23 18:43:59 <ikke> handlerug: first to testing
2022-03-23 18:44:12 <handlerug> mkay thanks
2022-03-23 20:05:49 <omni> ncopa: ok, just thought it'd be good to have in a bit ahead of 3.16 release =)
2022-03-23 20:06:54 <smcavoy> in a APKBUILD file can you describe a dependency as needing to be <=1.0,>=0.5 ? it seems to only support a single clause.. 
2022-03-23 20:07:51 <ikke> Don't think it's possible
2022-03-23 20:08:47 <Hello71> depends="foo<1 foo>0.5"?
2022-03-23 20:11:32 <Ariadne> what Hello71 said should work
2022-03-23 20:12:23 <smcavoy> I have specified the package with the two requirements and it builds the package but not sure if that will have the desired effect.. 
2022-03-23 20:12:52 <ikke> Easy enough to test. Specify something that cannot be satisfied
2022-03-23 20:16:37 <smcavoy> seems to.. 
2022-03-23 21:19:30 <boomanaiden154> Does someone on aarch64 mind testing !32356?
2022-03-24 17:42:37 <psykose> think busybox is stuck on its tests on builders again
2022-03-24 17:42:46 <ikke> :/
2022-03-24 17:43:25 <ikke> huh
2022-03-24 17:43:29 <ikke> that should have been resolved
2022-03-24 17:43:39 <ikke> "yes The quick brown fox jumps over the lazy dog"
2022-03-24 17:45:42 <ikke> cfef5066eb1429d5fcc0fca075b9c7490b62b0cd
2022-03-24 17:51:42 <ikke> what man page contains all the signals again?
2022-03-24 17:52:20 <psykose> man 7 signal i think
2022-03-24 17:52:35 <ikke> thank you, yes
2022-03-24 18:03:17 <Ariadne> did mqtt-exec get restarted ?
2022-03-24 18:03:52 <ikke> afaik, it has
2022-03-24 18:04:07 <psykose> don't think it would have passed before without a restart
2022-03-24 18:04:16 <psykose> could do it twice
2022-03-24 18:04:37 <ikke> If I look to the first subprocess of mqtt-exec, then I get SigIgn: 0000000000000004
2022-03-24 18:04:44 <ikke> which, afaik is exected
2022-03-24 18:04:51 <psykose> yeah, that looks fixed
2022-03-24 18:06:00 <ikke> But then buildrepo: SigIgn: 0000000000001006
2022-03-24 18:06:08 <psykose> huh
2022-03-24 18:06:18 <psykose> which part of the chain flips it
2022-03-24 18:06:45 <psykose> maybe we fixed it in two places and one was a hotpatch and forgot
2022-03-24 18:09:29 <ikke> https://tpaste.us/9bNK 
2022-03-24 18:10:10 <ikke> The SigIgn describes the process above
2022-03-24 18:12:57 <ikke> Not sure how buildrepo suddenly ignores sigpipe
2022-03-24 18:13:35 <psykose> maybe it's on strike
2022-03-24 18:13:44 <psykose> have you tried petting it gently
2022-03-24 18:21:17 <Hello71> kill -l also lists signals
2022-03-24 18:23:34 <ikke> psykose: is SIGHUP gentle? :P
2022-03-24 18:23:44 <psykose> very kind and caring
2022-03-24 18:24:59 <ikke> It does work :P
2022-03-24 18:25:06 <ikke> in the sense that the process continues
2022-03-24 18:25:17 <ikke> but the next one just hangs
2022-03-24 18:28:17 <ikke> restarted mqtt-exec, and now buildrepo has 0000000000000006
2022-03-24 18:28:20 <ikke> so that looks better
2022-03-24 18:34:56 <psykose> strange
2022-03-24 18:35:03 <psykose> afaik we restarted it before
2022-03-24 18:35:06 <psykose> you sure there was no other changes?
2022-03-24 18:35:37 <ikke> Not that I'm aware of
2022-03-24 19:48:12 <psykose> armhf/armv7 still seem stuck
2022-03-24 19:52:52 <ikke> hmm
2022-03-24 19:52:54 <ikke> strange
2022-03-24 19:53:24 <ikke> it's still set to 0000000000001006
2022-03-24 19:57:34 <ikke> I don't get it
2022-03-24 20:04:45 <ikke> still :/
2022-03-24 20:05:25 <psykose> armv7 cleared though
2022-03-24 20:05:29 <ikke> huh
2022-03-24 20:05:43 <ikke> I'm profoundly puzzled
2022-03-24 20:05:58 <psykose> me too
2022-03-24 20:12:44 <ikke> now armhf as well
2022-03-25 09:51:31 <ncopa> does anybody know who did the work behind the musl-tid-caching.patch for chromium in a8fa962568231152a151b966d0d3e10c6da9349c
2022-03-25 09:51:50 <ncopa> says Aiden Grossman
2022-03-25 09:52:36 <ikke> That's boomanaiden154 
2022-03-25 09:53:17 <ikke> https://gitlab.alpinelinux.org/boomanaiden154
2022-03-25 09:53:19 <ncopa> boomanaiden154: just want to say a big *thank you* for your work on it.
2022-03-25 09:57:52 <ncopa> ah the debugging of the issue was done by https://gitlab.alpinelinux.org/illiliti and https://gitlab.alpinelinux.org/git-bruh https://gitlab.alpinelinux.org/alpine/aports/-/issues/13579#note_224393
2022-03-25 11:27:27 <ikke> ncopa: for 3.15 we switched to 4096 bits keys, but for edge we have not done so yet. What do you think is a good moment to do so?
2022-03-25 11:29:38 <ikke> edge already has the new keys, so in most cases, everyone already does have the correct key
2022-03-25 12:30:14 <ncopa> when was those keys added?
2022-03-25 12:30:44 <Habbie> we just issued a security update for pdns and pdns-recursor; to which alpine releases do I MR that? 3.12 and up? (https://www.alpinelinux.org/releases/ suggests so)
2022-03-25 12:31:15 <ikke> ncopa: just before 3.15
2022-03-25 12:31:55 <ikke> Habbie: pdns is in community
2022-03-25 12:32:01 <ikke> so officially only 3.15 and edge
2022-03-25 12:32:14 <Habbie> oh yes, excellent
2022-03-25 12:32:16 <Habbie> thanks
2022-03-25 12:35:42 <Habbie> i see now the page also says that :D
2022-03-25 14:11:16 <ncopa> ikke: i think it should be ok to start use them now, but we could also way til after 3.16 is released
2022-03-25 14:11:19 <ncopa> im ok with both
2022-03-25 14:11:59 <ncopa> I guess the downside of doing it now is that you cannot upgrade to edge from 3.14
2022-03-25 14:13:01 <ikke> 3.14 has the new keys
2022-03-25 14:15:45 <ikke> the keys have been backported to 3.11
2022-03-25 14:19:51 <Ermine> Maybe one should post an announcement about it in the mailing list
2022-03-25 14:26:53 <ikke> Yes
2022-03-25 14:28:04 <ncopa> ah, then I see no reason to wait more
2022-03-25 14:28:56 <ikke> ncopa: there is no issue when mixed keys are used, right?
2022-03-25 14:29:11 <ikke> ie, the index and some package with key A, and some other packages with key B
2022-03-25 14:29:20 <ncopa> I dont think so
2022-03-25 14:29:43 <ncopa> but maybe wait til monday in case there are unexpected problems
2022-03-25 14:29:59 <ikke> Yes, was not planning to do it right away
2022-03-25 14:30:11 <ncopa> good. I was planning to take weekend :)
2022-03-25 14:30:20 <ikke> that's a very good plan :)
2022-03-25 15:19:57 <skarnet> ncopa: before leaving for the week-end please tell me if the current version of my alpine-conf modif is acceptable and maybe merge it if it is, that's a blocking point for me
2022-03-26 04:24:06 <boomanaiden154> Does anyone have any idea how chromium in ForkWithFlags(https://source.chromium.org/chromium/chromium/src/+/main:base/process/launch_posix.cc;l=721) is able to call clone() with the CLONE_NEWPID flag without seeming to have the necessary CAP_SYS_ADMIN permission? When I try to replace the call to clone with fork+unshare, I get EPERM due to not having CAP_SYS_ADMIN.
2022-03-26 04:29:39 <psykose> i don't see CLONE_NEWPID in either that or the function it calls, is it added somewhere else
2022-03-26 04:31:30 <psykose> ah, namespace_sandbox.cc:ForkInNewPidNamespace
2022-03-26 04:33:09 <psykose> maybe it's an 'unprivileged user namespace' thing? but i don't think we have that enabled
2022-03-26 04:39:51 <boomanaiden154> Could be. It looks like if you pass CLONE_NEWUSER and CLONE_NEWPID to clone you don't need escalated privileges.
2022-03-26 04:40:07 <boomanaiden154> Looks like I'll have to test if the same works with unshare().
2022-03-26 04:42:51 <boomanaiden154> Not totally sure how that will work out though because you have to unshare() the PID namespace in the parent process before calling fork (because unshare(CLONE_NEWPID) only moves childprocesses to a new namespace) and I'm not totally sure of the implications of moving that process to a new user namespace.
2022-03-26 04:43:43 <boomanaiden154> Looks like unshare(CLONE_NEWUSER | CLONE_NEWPID) works in an unprivileged environment.
2022-03-26 04:44:33 <boomanaiden154> Thanks for the hint psykose. I had been struggling with that issue all day.
2022-03-26 04:45:36 <psykose> just a shot in the dark :)
2022-03-26 10:15:40 <Sheila> psykose: if you would, please, I'd appreciate it (re !32498)
2022-03-26 10:21:55 <ikke> Sheila: I can help if you want
2022-03-26 10:30:16 <Sheila> that would also be fine, yes, please.
2022-03-26 10:31:17 <ikke> So what remotes do you have on your repository?
2022-03-26 10:33:00 <Sheila> my aports and alpine's, which I periodically pull in via `git pull git@gitlab.alpinelinux.org:alpine/aports.git`
2022-03-26 10:34:05 <ikke> Ok, I would suggest adding that as a proper remote
2022-03-26 10:34:27 <ikke> `git remote add upstream git@gitlab.alpinelinux.org:alpine/aports.git` for example
2022-03-26 10:35:40 <ikke> The advantage is that it will keep remote tracking branches for that remote
2022-03-26 10:35:40 <Sheila> okay.
2022-03-26 10:36:30 <ikke> After you added the remote, you can run: `git fetch upstream`
2022-03-26 10:38:34 <Sheila> okay. that's branch-independent, right?
2022-03-26 10:39:59 <ikke> yes
2022-03-26 10:40:35 <Sheila> all right. that's done, then.
2022-03-26 10:43:26 <ikke> ok
2022-03-26 10:43:34 <ikke> Now, you have that branch checked out?
2022-03-26 10:43:36 <ikke> nheko/0.9.3
2022-03-26 10:45:07 <ikke> git rebase --onto upstream/master HEAD~ nheko/0.9.3
2022-03-26 10:45:58 <Sheila> okay, done.
2022-03-26 10:46:23 <ikke> now git push -f origin nheko/0.9.3
2022-03-26 10:47:21 <Sheila> okay.
2022-03-26 10:47:35 <ikke> That looks better :)
2022-03-26 10:54:48 <Sheila> gitlab's still got all of those extra commits in my MR, but I'm assuming that's just it being itself and not an actual issue since the buildbot stuff is kosher now.
2022-03-26 10:55:21 <ikke> press F5
2022-03-26 10:56:18 <Sheila> aha. nevermind, then. :D thanks.
2022-03-26 10:57:46 <ikke> np
2022-03-26 10:58:08 <ikke> So you can use `git fetch upstream` to make sure upstream/master is up-to-date, and base your feature branches on upstream/master
2022-03-26 16:18:38 <handlerug> what's the timeline of a package getting moved from testing into the community repository? what are the requirements, basically?
2022-03-26 16:19:45 <ikke> handlerug: It can happen very quickly. Just needds to be tested to work it's working as expected, and the APKBUILD needs to be up to shape
2022-03-26 16:21:26 <handlerug> can I then vouch for mycorrhiza package to get accepted? :P I just submitted it some days ago, and I'm also one of the project maintainers so I can work on the upstream
2022-03-26 16:23:47 <handlerug> I haven't submitted a MR or anything like that moving it, btw, do I need to do that?
2022-03-26 16:23:59 <panekj> yes
2022-03-26 16:24:14 <ikke> Indeed
2022-03-26 16:24:36 <ikke> handlerug: 'pkgver=1.8.2_git20220324'
2022-03-26 16:24:49 <ikke> it would help if an actual release is used
2022-03-26 16:25:31 <handlerug> a proper Makefile was added just recently, and we did not make a release yet. I might arrange for a patch release actually
2022-03-26 16:26:03 <panekj> you don't need to use makefile
2022-03-26 16:26:21 <handlerug> but I still want to use it to make packaging easier
2022-03-26 16:26:22 <panekj> especially since it's just 2 lines
2022-03-26 17:36:54 <psykose> Sheila: i was asleep, but you did it :3 congrats
2022-03-26 17:38:18 <Sheila> figured, and yeah. just need to remember to either do the things *before* branching or do the other things before MR'ing.
2022-03-26 17:39:32 <Ermine> Do I need to prefix any ruby package with ruby-, even if it is end-user application?
2022-03-26 17:40:09 <Sheila> end-user applications generally don't.
2022-03-26 17:40:12 <ikke> no, just ruby libraries / gfems
2022-03-26 17:40:48 <Ermine> ok, thank you
2022-03-26 18:20:53 <Ermine> If ruby package has both .gemspec and Rakefile, should I use gem or rake for build?
2022-03-26 18:21:13 <ikke> A Rakefile is much like a Makefile
2022-03-26 18:28:03 <ikke> You can see what's in the Rakefile if there is anything special in it
2022-03-26 18:29:02 <ikke> Upgrading gitlab in a couple of minutes
2022-03-26 18:37:33 <ikke> Upgrading now
2022-03-26 18:41:35 <psykose> the interface is completely different
2022-03-26 18:41:42 <psykose> for pipelines
2022-03-26 18:41:42 <psykose> hah
2022-03-26 18:42:06 <ikke> ahuh
2022-03-26 18:42:20 <psykose> planning hierarchy..
2022-03-26 18:42:33 <panekj> oh wow
2022-03-26 19:02:50 <ikke> To be honest, I don't see a lot of difference myself..
2022-03-26 19:03:09 <psykose> that is the only place that had a difference so far
2022-03-26 19:03:16 <psykose> :p
2022-03-26 19:03:18 <psykose> the rest is the same
2022-03-26 19:03:21 <ikke> 0https://about.gitlab.com/releases/2022/02/22/gitlab-14-8-released/#improve-pipeline-index-page-layout
2022-03-26 21:48:26 <skarnet> Do we have a list of Alpine-packaged software that modifies /etc/resolv.conf? (dhcp clients, k8s/k0s misdesigns, other stuff that tries to be too smart)
2022-03-26 22:02:27 <ikke> reso;vconf
2022-03-26 22:03:18 <skarnet> breathe
2022-03-26 22:03:45 <ikke> Not sure if it counts, but afaik something like vim would also move in place
2022-03-26 22:04:23 <ikke> The package is opensresolv
2022-03-26 22:04:31 <skarnet> no, I'm thinking of automated stuff
2022-03-26 22:05:00 <skarnet> okay but does the resolvconf program centralize everything? I suppose other stuff misbehaves
2022-03-26 22:06:19 <ikke> It's meant to handle mutliple competing sources
2022-03-26 22:06:57 <skarnet> and is it official Alpine policy that everything that wants to modify /etc/resolv.conf has to go through it?
2022-03-26 22:07:22 <ikke> It's not shipped by default
2022-03-26 22:07:26 <ikke> so users have to install i
2022-03-26 22:07:28 <ikke> it
2022-03-26 22:08:01 <skarnet> does dhcpclient depend on it?
2022-03-26 22:08:26 <skarnet> because if the mechanism exists and nothing uses it, it's... useless
2022-03-26 22:10:37 <ikke> I'm not sure what's hooked into it
2022-03-26 22:11:41 <ikke> By default there is /usr/share/udhcpc/default.script
2022-03-26 22:11:59 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/busybox/default.script
2022-03-26 22:12:28 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/busybox/default.script#L123
2022-03-26 22:12:29 <ikke> does a mv
2022-03-26 22:16:18 <ikke> Are you trying to hardlink /etc/resolv.conf or something like that?
2022-03-26 22:16:42 <skarnet> no, I'm thinking of something much more radical and you don't want to know
2022-03-26 22:17:01 <Habbie> tell us anyway :)
2022-03-26 22:17:13 <ikke> I suppose that came out of that libc gethostbyname discussion?
2022-03-26 22:17:22 <skarnet> it's much older than that
2022-03-26 22:17:25 <ikke> ok
2022-03-26 22:18:06 <skarnet> the discussion just reminded me of it and I'm waiting for my mr to be reviewed anyway
2022-03-26 22:18:37 <skarnet> I'll tell more when I have a better idea of the doability of the thing
2022-03-26 22:29:45 <psykose> skarnet's illegal experiments ep. 3
2022-03-26 22:30:15 <skarnet> it's still at the ideation stage and even the idea is illegal
2022-03-26 22:32:10 <psykose> these thoughts must not be thought
2022-03-26 22:32:29 <ikke> goodthink
2022-03-26 22:52:48 <Hello71> how close is it to /run/systemd/resolve/resolv.conf
2022-03-26 22:55:16 <skarnet> very close, but without the bugs
2022-03-26 22:55:36 <begs> <skarnet> "no, I'm thinking of something..." <- chattr +i? :D
2022-03-26 22:56:05 <skarnet> that would be way too simple
2022-03-26 22:56:59 <skarnet> (no, I would love it if it could be that simple, but that would return errors, dhcp clients wouldn't like it, and it can still be defeated)
2022-03-26 23:36:47 <Habbie> chattr +i resolv.conf is a terrible hack that bites people every day
2022-03-27 11:14:17 <donoban> I got many errors like ERROR: font-liberation-2.1.5-r0: trying to overwrite etc/fonts/conf.avail/30-liberation-mono.conf owned by ttf-liberation-2.00.5-r0.
2022-03-27 11:15:13 <donoban> it seems that 'apk fix' solved them
2022-03-27 11:26:33 <psykose> yes, there is a missing replaces= to allow a clean upgrade, but it's fine otherwise
2022-03-27 11:26:39 <psykose> jirutka will fix it when he sees it
2022-03-27 11:26:51 <psykose> #13637
2022-03-27 11:31:53 <ncopa> skarnet: sorry. got busy with other stuff
2022-03-27 11:33:37 <donoban> psykose: ok, nice
2022-03-27 14:00:42 <Newbyte> Hi, could someone have a look at !29703? It's sort of far back in the MR list as I opened it a while ago and struggled with finding the root of an issue for about a month or two.
2022-03-27 14:12:30 <psykose> could you add a sonameprefix="wlrootsphosh:so:" or somesuch
2022-03-27 14:28:34 <ikke> psykose: what's the goal of that? Preventing something from pulling it in?
2022-03-27 14:28:57 <psykose> we had that issue before, where one of these extra wlroots got upgraded and provided the same .so.n
2022-03-27 14:29:04 <psykose> just safety i suppose
2022-03-27 14:29:07 <psykose> and no harm to the package
2022-03-27 17:07:40 <zx2c4> ncopa: wondering if you saw https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/32521 - seems like a trivial merge
2022-03-27 17:08:43 <ikke> I've merged it already
2022-03-27 17:09:01 <ikke> oh, sorry
2022-03-27 17:09:05 <ikke> ignorem e
2022-03-27 17:18:00 <zx2c4> ikke: well, you could press the green button instead i guess ;-)
2022-03-27 21:16:18 <ncopa> zx2c4: hi! will merge it. Thank you!
2022-03-27 21:26:12 <ncopa> zx2c4: I guess this should be backported to our stable branches as well?
2022-03-27 23:48:37 <bl4ckb0ne> has there been any progress regarding the dotnet aports? im dying to run jellyfin outside of podman
2022-03-27 23:49:39 <boomanaiden154> They've been merged and they're in testing, so you should be able to check them out if you add the testing repo.
2022-03-27 23:49:52 <boomanaiden154> There's a currently open MR to move dotnet6 to community if I recall correctly.
2022-03-27 23:50:03 <boomanaiden154> As well as a couple other open MRs to do things like add testing.
2022-03-27 23:50:43 <bl4ckb0ne> with msbuild and all the garbage microsoft pushes?
2022-03-27 23:51:00 <bl4ckb0ne> ill.give a try to jellyfin and see where it goes then
2022-03-27 23:52:12 <boomanaiden154> I haven't seen anything for msbuild, unless it's bundled with dotnet.
2022-03-28 00:17:49 <panekj> it should be bundled in dotnet already
2022-03-28 00:27:33 <zx2c4> ncopa: yea probably should
2022-03-28 00:27:44 <zx2c4> you're one step ahead of gentoo -- https://github.com/gentoo/gentoo/pull/24784
2022-03-28 00:27:57 <zx2c4> putting it in ~arch first, and then it'll gradually get stabilized there
2022-03-28 00:28:31 <zx2c4> it's in void's runit scripts, it's going into buildroot. any other non-systemd init system distros you can think of?
2022-03-28 00:48:18 <Hello71> all the musl ones, for a start
2022-03-28 00:49:58 <Hello71> i think there's somewhere between one and two dozen actively maintained ones, if you include "special-purpose" distros like openwrt and buildroot
2022-03-28 07:39:24 <ncopa> Seems like zlib 1.2.12 requires that we set -fPIC? https://tpaste.us/70Kd
2022-03-28 07:54:01 <Ariadne> haha wtf
2022-03-28 07:54:15 <Ariadne> i mean, yes, seems needed
2022-03-28 08:15:08 <ncopa> seems like there are some new symbols introduced as well
2022-03-28 08:15:22 <ncopa> https://github.com/madler/zlib/issues/608
2022-03-28 09:49:08 <ncopa> so, due to the zlib CVE i thought that i should do new stable releases today again. so yesterday i pushed the latest kernels to 3.15-stable and this morning i did 3.14, 3.13 and started tiwh 3.12
2022-03-28 09:49:21 <ncopa> and now there are new kernels again....
2022-03-28 09:49:29 <ncopa> happens every single time!
2022-03-28 09:51:38 <ikke> oof
2022-03-28 09:52:09 <Ermine> do release -> find out new cve -> patch -> goto 1
2022-03-28 09:54:49 <ncopa> problem is that I could save compile time if i knew the new kernel was going out today
2022-03-28 10:01:55 <psykose> there is a new libtool release after 7 years too
2022-03-28 10:02:22 <psykose> thankfully not a cve :p
2022-03-28 10:03:47 <Ermine> what a day
2022-03-28 10:07:50 <ncopa> i wish we could use slibtool instead
2022-03-28 10:17:23 <ncopa> seems like builders are busy with cromium and linux-edge. I guess the builders will not have time for a release today
2022-03-28 10:23:03 <psykose> they should be clear in an hour or two
2022-03-28 10:24:19 <ncopa> i just have 7 kernel builds in the pipeline
2022-03-28 10:25:02 <ikke> Maybe we should coordinate pushing large builds
2022-03-28 10:25:18 <ncopa> i think we should have a new build infra
2022-03-28 10:25:43 <ncopa> so we can push as much as we want and the build infra will queue it up and make sure nothing gets overloaded
2022-03-28 10:26:32 <ncopa> i also wonder if I could temporarily add my local i9 or m1 laptop as build power to the build pool
2022-03-28 10:30:58 <psykose> definitely not without rearchitecting our builders entirely
2022-03-28 10:31:23 <Ariadne> fwiw, i have an idea about how the stuff i am building at work could be used to handle APKBUILDs too
2022-03-28 10:31:38 <Ariadne> but that stuff requires k8s
2022-03-28 10:32:08 <Ariadne> i mean, i guess it does not *require* k8s, but k8s gives you all the scheduling stuff for free
2022-03-28 10:35:25 <psykose> i don't get paid enough to touch k8s
2022-03-28 10:35:29 <psykose> maybe for 20 million dollars
2022-03-28 10:35:39 <panekj> are you paid at all :p
2022-03-28 10:35:46 <psykose> no
2022-03-28 10:36:07 <Ariadne> in theory it would be possible to write an alternate scheduler on like, gitlab CI or something
2022-03-28 10:36:14 <Ariadne> i am already planning to do this anyway
2022-03-28 10:36:59 <ikke> Not sure if gitlab-ci is suited as builder
2022-03-28 10:37:36 <Ariadne> k8s + tekton is not too bad :)
2022-03-28 10:38:27 <ncopa> i have actually been thinking of k8s for building as well. it gives us the scheduling etc for "free"
2022-03-28 10:38:45 <ncopa> and it makes it relatively simple to add/remove builders to the pool
2022-03-28 10:40:10 <Ariadne> k8s + tekton + melange (with apkbuild support) is what i was going to propose, but melange is basically a from-scratch rewrite of abuild
2022-03-28 10:40:40 <Hello71> the "off the shelf" solution seems to be opensuse build service
2022-03-28 10:41:47 <Hello71> imo it is somewhat heavy but much less so than gitlab
2022-03-28 10:45:26 <ncopa> i think the downside with k8s that it makes it hard to bootstrap new architectures
2022-03-28 10:45:59 <ncopa> you need go, kublet, containerd, runc etc to add new architecture once we depend on k8s
2022-03-28 10:46:42 <Ariadne> i mean, are we planning to bootstrap new architectures that don't have those?
2022-03-28 10:46:56 <Ariadne> mips would have had them except wave technology sorta went bankrupt
2022-03-28 10:48:12 <ncopa> riscv?
2022-03-28 10:48:29 <ncopa> not sure if k8s runs on riscv
2022-03-28 10:48:36 <Ariadne> i think it does
2022-03-28 10:48:58 <ikke> k8s has been disabled on ppc64le
2022-03-28 10:49:14 <ikke> we only have it for 4 arches
2022-03-28 10:49:17 <ikke> https://pkgs.alpinelinux.org/packages?name=kubernetes&branch=edge
2022-03-28 10:50:09 <ncopa> its a tradeoff. k8s gives some benefits, but it also create a new set of problems
2022-03-28 10:50:23 <ncopa> and portability isnt that great of k8s
2022-03-28 10:50:44 <ncopa> they mainly support x86_64 and aarch64
2022-03-28 10:50:56 <Ermine> +: easy scheduling, easy to add new resources
2022-03-28 10:51:05 <Ermine> -: architecture support
2022-03-28 10:51:08 <Ariadne> i mean, it works fine on s390x
2022-03-28 10:51:14 <Ariadne> i have no idea why our package doesnt have it enabled
2022-03-28 10:51:51 <ncopa> what network driver do you use with s390x? calico does not work on s390x iirc
2022-03-28 10:52:00 <ncopa> and im not sure kube-router works either
2022-03-28 10:52:21 <ncopa> i dont think armv7 is great either
2022-03-28 10:53:01 <Ariadne> kube-router works okayish
2022-03-28 10:53:27 <Ariadne> anything involving eBPF is totally broken tho
2022-03-28 10:54:58 <ncopa> upstream kube-proxy image does not work with alpine's kernel since 3.15, due to compressed kernel modules with .gz
2022-03-28 10:55:42 <ncopa> because kube-proxy image is based on debian image and uses debians kmod/modprobe, which does not support .gz kernel modules. only .xz
2022-03-28 10:56:25 <psykose> that sounds 'easily' patched to replace the kmod
2022-03-28 10:56:40 <ncopa> so in general, k8s would bring some benefits, but there are also lots of things that will require significant amount of work, and maybe we need to support our own images etc
2022-03-28 10:56:55 <psykose> to be a bit more fair
2022-03-28 10:57:08 <psykose> moving to absolutely anything will have a large amount of things that will take work, and things that will be broken and need patching
2022-03-28 10:57:12 <psykose> this is true regardless of any choice
2022-03-28 10:57:13 <Ariadne> i think once musl has dns over tcp support, it should be possible to convince kube-proxy to switch to alpine image
2022-03-28 10:57:14 <ncopa> psykose: builing our own image based n alpine would solve it halve the size of it (more or less)
2022-03-28 10:57:26 <Ariadne> kubernetes people like apko :)
2022-03-28 10:58:11 <Ariadne> wait wtf
2022-03-28 10:58:21 <Ariadne> why is kube-proxy modprobe-ing shit
2022-03-28 10:58:42 <ncopa> Ariadne: welcome to the wonderful world of k8s....
2022-03-28 10:59:07 <ncopa> i believe it is iptables that pulls in some kernel modules
2022-03-28 10:59:09 <Ariadne> i'm well aware
2022-03-28 10:59:18 <ncopa> kernel modules autoloading
2022-03-28 10:59:33 <Ariadne> yeah makes since
2022-03-28 10:59:36 <Ariadne> ...
2022-03-28 10:59:37 <Ariadne> sense
2022-03-28 10:59:40 <Ariadne> thx phone
2022-03-28 10:59:46 <Habbie> -is- musl getting dns over tcp support? i read your blog post but do not recall it said it was
2022-03-28 10:59:58 <Ariadne> it's a "wanted" feature
2022-03-28 11:00:02 <ncopa> i am trying to find funding for getting it done
2022-03-28 11:00:34 <Ariadne> i can help there
2022-03-28 11:00:46 <Habbie> if there is a url i can share, i may also be able to help
2022-03-28 11:00:52 <ncopa> but er... anything that can not easily be calculated in specific $$$ number is challenging
2022-03-28 11:00:53 <Ariadne> $dayjob wants to remove any reason to "doubt" alpine images in k8s
2022-03-28 11:01:14 <Ariadne> ncopa: yes, i asked dalias for a $$$ figure and he was not forthcoming
2022-03-28 11:01:30 <Ariadne> if i had a $$$ figure this would be like
2022-03-28 11:01:41 <Ariadne> 10 minute google meet call and a wire transfer out the door
2022-03-28 11:02:23 <psykose> he said he gave ncopa a 1 month figure
2022-03-28 11:02:38 <psykose> unless that was not a money figure :p
2022-03-28 11:02:48 <Ariadne> yes, but i don't know how that translates to $$$
2022-03-28 11:02:51 <ncopa> that was not money figure
2022-03-28 11:02:51 <Ariadne> i guess i can ask
2022-03-28 11:02:55 <psykose> unlucky
2022-03-28 11:03:13 <Ariadne> i really would prefer to delay alpine 3.16 release if it is just "a month"
2022-03-28 11:03:14 <ncopa> it was more time estimate due to need to ask for mailing list feedback
2022-03-28 11:03:29 <ncopa> i think i'd rater backport it to 3.16-stable
2022-03-28 11:03:45 <Ariadne> sure
2022-03-28 11:04:04 <Ariadne> as long as it makes it there
2022-03-28 11:04:35 <Ariadne> i do not think the musl DNS resolver is good though
2022-03-28 11:06:38 <ncopa> i do not think ... DNS ... is good though
2022-03-28 11:06:43 <ncopa> :)
2022-03-28 11:07:06 <ncopa> Ariadne: i think i understand what you mean
2022-03-28 11:07:19 <Ariadne> i should say, i have a love-hate relationship with it
2022-03-28 11:07:44 <ncopa> that i completely understand
2022-03-28 11:08:14 <ncopa> i have more of a love-dislike relationship :)
2022-03-28 11:08:36 <Ermine> What about dnfunnel?
2022-03-28 11:08:50 <Ermine> dnsfunnel*
2022-03-28 11:10:03 <ncopa> looks like a hack
2022-03-28 11:10:52 <Ermine> It can serve at least as temporary workaround if it works, but one needs to test it
2022-03-28 11:11:30 <ncopa> having a separate daemon for it sounds inconvenient
2022-03-28 11:13:10 <Ariadne> Ermine: not a solution for the userbase which complains the most
2022-03-28 11:13:19 <Ariadne> unless you are proposing everyone put
2022-03-28 11:13:27 <Ariadne> CMD service dnsfunnel start && theirapp
2022-03-28 11:13:30 <Ariadne> in dockerfiles
2022-03-28 11:13:47 <Ariadne> which will basically give Canonical a great piece of FUD to work with
2022-03-28 11:14:28 <Ariadne> this is unfortunately an issue where we have to consider, very carefully, how a "workaround" would be perceived
2022-03-28 11:15:48 <Ermine> You've got a point
2022-03-28 13:32:07 <skarnet> ncopa: dnsfunnel *is* a hack, because working around broken DNS (or anything) software or configuration is always a hack
2022-03-28 13:32:47 <skarnet> but it's a hack that was written specifically for this use case and I'm pretty miffed it's viewed as a nonstarter because "onoes it requires an additional service"
2022-03-28 13:32:59 <skarnet> I wish I had known this *before* I wrote it tbh
2022-03-28 16:41:11 <Ariadne> zx2c4: do you plan to acquire a CVE for the openrc issue
2022-03-28 16:43:21 <zx2c4> Ariadne: i dont think it's necessary. It wasnt actually crediting the rng before, so getrandom(0) would still block until getting 256 bits of entropy.
2022-03-28 16:43:42 <zx2c4> The old behavior is definitely non optimal but it's not catastrophic
2022-03-28 16:45:26 <Ariadne> do you know if the openrc team is planning to acquire a CVE?
2022-03-28 16:46:10 <Ariadne> basically, i am just asking if there is going to be a surprise CVE that we will have to update the security database to address in the next few weeks :P
2022-03-28 16:50:18 <zx2c4> Ariadne: no, no cve here i dont think
2022-03-28 16:50:59 <zx2c4> Do something eventually. But if you need leisure, do it at your leisure. Focus on zlib instead :)
2022-03-28 16:52:27 <ncopa> zx2c4: I just pushed the zlib fixes to all our maintained branches and i also did openrc fix while at it
2022-03-28 16:52:42 <ncopa> didnt know how serious openrc issue was
2022-03-28 16:58:12 <skarnet> ncopa: friendly reminder to review my proposed additions to alpine-conf (I followed your suggestions) so I can keep working on the thing that depends on it
2022-03-28 16:59:26 <ncopa> yeah, i havent forgotten it (yet). just been busy with zlib cve and openrc backporting and a zilling of kernel updates
2022-03-28 17:00:16 <Ermine> skarnet: If you don't mind I'll open merge request to move mdevd to main (or community). setup-devd mentions it, so it would be nice to have 
2022-03-28 17:05:02 <skarnet> Ermine: please don't
2022-03-28 17:06:02 <skarnet> that's the work I'm mentioning, I have a big MR pending including the move to main, but it hits several places that need to be changed at the same time, it's a bit complex
2022-03-28 17:06:20 <skarnet> and I need the new alpine-conf version to be able to test everything
2022-03-28 18:29:00 <Hello71> i would also like to see https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/41 merged for 3.16. it is not very good to waste 20% of iso on nothing
2022-03-28 18:38:02 <Ariadne> nice
2022-03-28 18:52:09 <Hello71> although apparently i didn't actually apply the proposed change
2022-03-28 18:53:05 <Hello71> or, wait, i did? it is a gitlab bug i think
2022-03-28 19:16:14 <ncopa> i think im gonna tag the stable releases for zlib fix now
2022-03-28 19:17:03 <ncopa> i would appreciate we could hold big builds til release is done
2022-03-28 19:17:58 <minimal> ncopa: could you look at !32330 when you get a chance?
2022-03-28 19:18:57 <ncopa> is it a blocker for the release?
2022-03-28 19:25:38 <minimal> you mean 3.16?
2022-03-28 19:26:07 <minimal> its more a nice-to-have (especially so I can work on trying to get cloud-init working with mdev)
2022-03-28 19:28:54 <ikke> minimal: ncopa is just working on 3.15.3
2022-03-28 19:30:57 <minimal> ah ok, no its something I'd like to see in 3.16, no need for existing releases
2022-03-28 19:42:11 <ncopa> can someone please help me review? https://wwwtest.alpinelinux.org/posts/Alpine-3.12.11-3.13.9-3.14.5-3.15.3-released.html im tired and may have done stupid typos or mistakes
2022-03-28 19:46:52 <Hello71> s/Those/These/ is slightly more standard
2022-03-28 19:47:32 <Ermine> s/zlib/zlib's/
2022-03-28 19:49:28 <ncopa> thanks. fixed both. care to refresh?
2022-03-28 19:49:57 <Ermine> Ok
2022-03-28 19:50:09 <ncopa> thank you! appreciate!
2022-03-28 19:50:29 <Hello71> imo the original way without 's is more standard, but it's fine either way
2022-03-28 19:53:27 <ncopa> lets push it and get done with it. thank you for your feedback!
2022-03-28 20:32:17 <ikke> ncopa: apparently the signatures are still missing?
2022-03-28 20:55:58 <ncopa> i just got the 3.14.5 sigs
2022-03-28 20:56:12 <ncopa> had to eat something while waiting for the ppc64le upload
2022-03-28 20:56:31 <ikke> Nod
2022-03-28 21:03:55 <donoban> maybe it's not very relevant for new release but https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/133 seems working fine
2022-03-28 21:04:17 <donoban> time to time there is someone asking how to use apk cache on rootbld
2022-03-28 21:08:00 <donoban> also I have !31362 which removes pam dependency and runs the service as some user (it runned as 'nobody'), the patch removes permissions dropping which fails if not started as root, it lose built in chroot freature but I suppose that if someone wants to sandbox it will run in a container
2022-03-28 21:13:07 <ncopa> ikke: are you sending the email to announce mailing list?
2022-03-28 21:13:31 <ncopa> i can do it otherwise
2022-03-28 21:14:16 <ikke> Feel free
2022-03-28 21:14:57 <ncopa> ok.
2022-03-28 21:14:58 <ncopa> thanks
2022-03-28 21:22:58 <donoban> well, I guess it's pretty late for asking reviews :D
2022-03-28 22:06:48 <skarnet> minimal: please can this wait for my MR (after my alpine-conf modification is merged I'll have a big MR that moves mdev.conf and friends) else I'll have to do some annoying merging :(
2022-03-28 22:09:07 <skarnet> I am getting annoyed that every time I make a significant contribution to a project I get stuck in a low priority queue for weeks (or sometimes years)
2022-03-28 22:09:32 <skarnet> and then small increments overtaking mine add work burden
2022-03-28 22:10:07 <minimal> skarnet: I'd hoped my MR would have been merged by now
2022-03-28 22:10:46 <skarnet> created 6 days ago? I've been working on mdev.conf for 2 weeks
2022-03-28 22:13:49 <skarnet> istg working collectively in corporate environments was less frustrating
2022-03-29 01:47:49 <basicer> Would it be possible to start building the main/linux-lts for riscv before riscv becomes an official platform?  I've been using community/linux-edge and have already been bitten a few times now by how edge it is.
2022-03-29 04:43:00 <ikke> basicer: That will most likely be the case, and before we make an actual release, we want to build everything on actual hardware, rather then emulated via qemu
2022-03-29 06:47:12 <markand> ffmpeg4 has been renamed to ffmpeg right? (in 3.15)
2022-03-29 06:48:07 <markand> while building retroarch for 3.15 I've got an error saying that ffmpeg4-dev was not available
2022-03-29 07:02:02 <ikke> markand: afaik ffmpeg4 was introduced in edge for packages that are not compattible with ffmpeg5 yet
2022-03-29 07:02:28 <markand> okay
2022-03-29 07:02:46 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/commit/36b006d149324c1f499ce3a765692ed20094aa41
2022-03-29 07:02:49 <markand> when a new release is made I guess there is a mass rebuild, but retroarch should have failed in that case, there are no report to see what failed?
2022-03-29 07:02:55 <markand> since it's in community/
2022-03-29 07:03:13 <ikke> This was 2 weeks ago
2022-03-29 07:03:24 <ikke> but on 3.15, there is no ffmpeg4
2022-03-29 07:03:58 <ikke> so if you want to build it on 3.15, you need to change it to ffmpeg
2022-03-29 07:04:02 <markand> aaah I get it
2022-03-29 07:04:08 <markand> someone actually changed the aport to use ffmpeg4
2022-03-29 07:04:12 <ikke> yes
2022-03-29 07:04:18 <markand> okay
2022-03-29 07:04:20 <ikke> which works on edge, but not on 3.15
2022-03-29 07:04:30 <markand> thanks for the clarification
2022-03-29 07:04:46 <markand> so I guess my best bet is to use edge to build and submit aports
2022-03-29 07:05:56 <ikke> or use rootbld
2022-03-29 07:06:06 <ikke> though, not sure how to make sure rootbld uses edge repos
2022-03-29 07:06:27 <ikke> oh, I think that's determined by the aports tree
2022-03-29 07:12:58 <ikke> markand: yes, I think rootbld should just work oot
2022-03-29 07:13:00 <ikke> ootb
2022-03-29 07:25:00 <markand> okay let me try
2022-03-29 08:52:26 <ncopa> morning
2022-03-29 11:09:59 <omni> !29072 !31823 (=
2022-03-29 11:53:26 <adhawkins> Trying to write an openrc init script (for webhook). What's the easiest way to 'debug' this?
2022-03-29 11:53:56 <adhawkins> For example, I want to make sure a variable has been set, so when declaring all the variables I test it, and call 'eerror' if it's not set (and return). This doesn't seem to be working.
2022-03-29 11:58:05 <Ermine> Probably [ -n $var ] || einfo "not set"
2022-03-29 12:03:24 <adhawkins> Yeah, I've now worked out what the issue was Ermine, thanks. But would appreciate it if there's any way of doing the equivalent of 'sh -x'?
2022-03-29 12:03:38 <ikke> adhawkins: if you run it directly
2022-03-29 12:04:00 <ikke> /etc/init.d/foo -d
2022-03-29 12:04:11 <ikke> /etc/init.d/foo --help to see all options
2022-03-29 12:04:14 <adhawkins> Ah ok, thanks. The '-d' bit was what I was missing. Cheers.
2022-03-29 12:06:17 <Ermine> Btw I would eliminate possibilities of unset variables to simplify things if I were you
2022-03-29 12:06:37 <ikke> : ${foo:=default}
2022-03-29 12:07:46 <adhawkins> I did consider that, but it's a path to a file defining all the webhooks, so it really should be specified.
2022-03-29 12:08:29 <adhawkins> Comments appreciated: https://paste.debian.net/1235980/
2022-03-29 12:08:30 <adhawkins> :)
2022-03-29 12:23:45 <Ermine> You can setup a default directory like /etc/webhooks/
2022-03-29 12:58:39 <omni> ncopa: <3
2022-03-29 14:49:02 <skarnet> ncopa: thanks for the review! I fixed what you pointed out. :)
2022-03-29 15:15:30 <omni> something changed with gitlab so you cannot have "WIP:" as draft prefix and easily push a button to mark it as ready?
2022-03-29 15:15:48 <ikke> omni: they prefix changed to Draft:
2022-03-29 15:24:49 <omni> Draft: was available earlier to, you could choose
2022-03-29 15:25:43 <ikke> Yes, and now they removed support for 'WIP', which was already deprecated
2022-03-29 15:36:09 <Ermine> How should I report (probable) security problems?
2022-03-29 15:37:45 <ikke> Ermine: You can open an issue on gitlab aports. If it's something that's not yet public, you can make it a confidential issue
2022-03-29 15:39:09 <Ermine> Ok. This is public already, but I'm not sure whether it is applicable to Alpine
2022-03-29 15:39:49 <ikke> Feel free to open an issue, then we can verify
2022-03-29 15:41:08 <omni> meow, I'll start using Draft: then...
2022-03-29 15:46:20 <Ermine> Done
2022-03-29 21:27:49 <sl33nyc> (also asked in #alpine-linux) another question: from https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage, it's not clear to me how to install an init.d openrc script to autostart a process that doesn't come with its own init.d script.  how do i do so?
2022-03-29 21:29:33 <Habbie> (while i have no answers, i want to thank you for mentioning you asked in two places)
2022-03-29 21:31:17 <sl33nyc> :)
2022-03-29 21:31:40 <sl33nyc> now, it's a race between channels to find an answer
2022-03-29 21:31:54 <Habbie> at least effort won't be double :)
2022-03-29 21:31:55 <ikke> 
ACTION is doubting which channel to answer in

2022-03-29 21:32:01 <Habbie> ikke, that is a problem
2022-03-29 21:32:03 <Habbie> probably the other one
2022-03-29 21:36:00 <fluix> sl33nyc: I've used this https://github.com/OpenRC/openrc/blob/master/service-script-guide.md
2022-03-30 06:44:59 <ikke> Problems emerge for a unified /dev/*random: https://lwn.net/SubscriberLink/889452/953e190af78809a7/ (related to the seeding of random by openrc)
2022-03-30 07:49:04 <ikke> featuring Hello71 :)
2022-03-30 09:01:50 <ncopa> good morning
2022-03-30 09:02:02 <ncopa> i wonder if i should kick of a big openssl3 rebuild
2022-03-30 10:09:33 <donoban> ncopa: Could you check https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/133 and https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/31362 ? Both are pretty simple
2022-03-30 10:23:34 <ncopa> donoban: they both look like they break things
2022-03-30 10:25:11 <donoban> hmm, ngircd maybe breaks a already working config due permissions, but rootbld seems safe
2022-03-30 10:25:20 <donoban> what do you think it could break?
2022-03-30 10:25:30 <ncopa> what happens if you delete /etc/apk/cache?
2022-03-30 10:25:43 <ncopa> its a symlink
2022-03-30 10:25:49 <ikke> And not there by default even
2022-03-30 10:26:01 <donoban> I tried, it works as expected
2022-03-30 10:26:07 <donoban> I could check agian, let build some pacakge
2022-03-30 10:26:34 <ikke> Sadly rootbld is hard to test
2022-03-30 10:27:07 <donoban> I'm doing it, it just downloading all packages
2022-03-30 10:27:43 <ikke> I mean, automatically test in a test suite
2022-03-30 10:27:51 <donoban> it doesn't complain about missing cache
2022-03-30 10:38:22 <donoban> it's seems hard to find where --cache-dir is handled
2022-03-30 10:38:57 <donoban> ahh
2022-03-30 10:39:17 <donoban> it's probably because I'm on master, is it apk 3?
2022-03-30 10:40:13 <ikke> yes
2022-03-30 10:40:22 <donoban> well, switched to 2.12-stable and looks similar
2022-03-30 10:40:31 <donoban> regarding --cache-dir handling
2022-03-30 10:43:51 <donoban> it seems that it has already a hard coded "etc/apk/cache" which on rootbld case refers to the new chroot
2022-03-30 10:45:43 <donoban> https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/2.12-stable/src/database.c#L1643
2022-03-30 10:47:26 <donoban> if there is no avaiable cache, does it creates "var/cache/apk"? it will be lost after rootbld finishes
2022-03-30 10:49:23 <ncopa> I would like to change REPODEST default
2022-03-30 10:50:05 <ncopa> I'd like to use $HOME/packages/$git_branch as default
2022-03-30 10:50:28 <ikke> hmmm, that would make sense
2022-03-30 10:50:30 <ncopa> that way its easier to git checkout 3.15-stable
2022-03-30 10:50:36 <ncopa> and do various rebuilds
2022-03-30 10:50:46 <ncopa> and swap back to master
2022-03-30 10:50:48 <donoban> yeah, sounds good
2022-03-30 10:50:55 <donoban> but could that be handled on abuild instead apk?
2022-03-30 10:51:22 <donoban> i suppose that there is no other way
2022-03-30 10:51:22 <ikke> yes, that's in abuild.conf
2022-03-30 10:51:29 <ncopa> and to be honest, I'd like to rename git master branch to 'edge' instead of 'master' and have dl-master.a.o/alpine/3.15-stable/ as the repo
2022-03-30 10:51:47 <ikke> that would be a bigger change
2022-03-30 10:51:53 <ncopa> so the URL or repository path matches the exact git branch name
2022-03-30 10:51:57 <ncopa> yeah, I know
2022-03-30 10:52:10 <ncopa> but it might not be as bad as we may thing
2022-03-30 10:52:13 <ncopa> tink
2022-03-30 10:52:15 <ncopa> think*
2022-03-30 10:52:32 <ncopa> we could have a symlink master -> edge on the master mirror
2022-03-30 10:52:35 <ikke> there are probably things that assume alpine/<version>/..
2022-03-30 10:52:48 <ikke> master -> edge should not affect the mirrors
2022-03-30 10:52:51 <donoban> well, anyway I don't think that this rootbld fix could break anything
2022-03-30 10:52:57 <ncopa> we could have <version> -> <gitbranch> symlinks
2022-03-30 10:53:02 <ikke> yea
2022-03-30 10:53:08 <donoban> and people who switch from dabuild to rootbld will notify that it's veeery slow until they fix the cache
2022-03-30 10:54:43 <ncopa> my current problem is: i need to do work. to do that work I need to fix A. to fix a I need to fix B. to fix B i should probably completely rewrite C
2022-03-30 10:54:53 <ikke> ncopa: trying to think what could have a dependency on the branch name
2022-03-30 10:55:07 <ikke> ncopa: welcome to the wonderful world of yak shaving
2022-03-30 10:55:16 <ncopa> yup
2022-03-30 10:55:40 <ncopa> REPODEST default change would be a step in right direction i think
2022-03-30 10:56:02 <ikke> yes, that should be fairly trivial
2022-03-30 10:56:03 <panekj> rootbld is still quite not compatible to what dabuild offers
2022-03-30 10:56:14 <ikke> panekj: they were never meant to be compattible
2022-03-30 10:56:24 <ikke> rootbld already existed before dabuild afaik
2022-03-30 10:56:47 <panekj> sure, but I think there should be some functionality that exists between both of them
2022-03-30 10:57:02 <panekj> e.g. I don't expect rootbld to retain envvars yet it does
2022-03-30 10:57:30 <donoban> it even creates new users on your host passwd/group
2022-03-30 10:57:50 <ncopa> another option would be to leave REPODEST alone and introduce a new variable which, if set, can override REPODEST
2022-03-30 10:58:15 <ncopa> and ~/packages as out dir is somewhat non optimal. maybe should be  ~/.abuild/something
2022-03-30 10:58:17 <ncopa> i dunno
2022-03-30 10:59:07 <ncopa> or maybe /var/lib/abuild/ something
2022-03-30 10:59:18 <ncopa> users needs to be in the abuild group anyway
2022-03-30 10:59:19 <panekj> and stuff like T{,E}MP{,DIR} or {CARGO_,RUSTUP_}* leaks into rootbld
2022-03-30 11:01:00 <ncopa> maybe ABUILD_OUTDIR?
2022-03-30 11:01:19 <donoban> ncopa: could have a ~/.abuild/cache for abuild, indepent from /etc/apk/cache?
2022-03-30 11:01:32 <ncopa> possibly
2022-03-30 11:01:36 <donoban> wchich reates a ~/.abuild/cache/$branch/...
2022-03-30 11:01:38 <ncopa> whats the benefit?
2022-03-30 11:01:51 <ncopa> cache and REPODEST are completely different topics
2022-03-30 11:01:52 <donoban> fix rootbld cache in the way that you propose
2022-03-30 11:02:23 <ncopa> i think cache can be shared. its hashes so they dont clash cross branches
2022-03-30 11:02:59 <ikke> ncopa: one thing we need to address with rootbld as well is reusing packages from local "other" repos
2022-03-30 11:03:10 <donoban> so what is the problem with https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/133/diffs#adc2ae0a3e467606d17056e7a9ca547d89344d3b_2446_2444 ?
2022-03-30 11:03:39 <ncopa> donoban: I don't know. maybe nothing. I just dont have the mental energy for dealing with it right now
2022-03-30 11:04:02 <donoban> ok ok
2022-03-30 11:04:21 <ncopa> not clear to me what problem it solve either
2022-03-30 11:04:30 <donoban> without it
2022-03-30 11:04:36 <donoban> every time you run: "abuild rootbld"
2022-03-30 11:04:42 <donoban> it redownlaods all the dependnecys
2022-03-30 11:04:47 <donoban> redownloads*
2022-03-30 11:05:00 <ncopa> so rootbld caching is broken in other words?
2022-03-30 11:05:03 <donoban> yes
2022-03-30 11:05:06 <donoban> after investiating it
2022-03-30 11:05:12 <donoban> it seems that it creates a new cache every time
2022-03-30 11:05:17 <ikke> yes, because the packages remain in the chroot and are thrown away
2022-03-30 11:05:23 <donoban> it creates a cache inside the chroot
2022-03-30 11:05:27 <donoban> and then removes the whoel dir
2022-03-30 11:05:32 <ncopa> maybe kunkku can have a look at it. if he approves i'm ok to merge
2022-03-30 11:05:48 <donoban> great!
2022-03-30 11:05:57 <ncopa> woudl be good to have some unit/integration test to verify that it actually works
2022-03-30 11:06:11 <ncopa> there are some tests under tests/ dir
2022-03-30 11:06:27 <ncopa> but not sure how to test it properly (without being root)
2022-03-30 11:06:40 <ikke> and rootbld does not work in docker
2022-03-30 11:14:57 <donoban> it will need something like fakewrap
2022-03-30 11:19:47 <ncopa> hmm... i dont know how to deal with this openssl3 upgrade
2022-03-30 11:20:16 <ncopa> i guess i could use rootbld for it
2022-03-30 11:20:43 <ncopa> and remove ~/packages/* from my system /etc/apk/repositories
2022-03-30 11:22:34 <ikke> I need one more step for multi-stage builds in gitlab
2022-03-30 11:22:43 <ikke> That should make it feasible to do these things there as well
2022-03-30 13:56:14 <ncopa> 2 tests failed:
2022-03-30 13:56:14 <ncopa>     test_minidom test_xml_etree
2022-03-30 13:56:18 <ncopa> python3 build
2022-03-30 13:56:24 <ncopa> i wonder what caused it
2022-03-30 13:56:47 <ncopa> ah, expat upgrade(s)
2022-03-30 14:07:15 <donoban> probably its a stupid crazy idea, but if the problem with dnsfunnel is that it requires to modify containers entry points (also running another process/service but could be less problematic for end users than modify their Dockerfiles), could not it be started by the entry point process when performing first dns query?
2022-03-30 14:07:55 <ikke> would it make sense to run dnsfunnel as a dedicated container?
2022-03-30 14:09:15 <donoban> uhm, maybe too. But my idea was about being transparent to the end user which changes its Dockerfile from XXX to alpine
2022-03-30 14:35:53 <Hello71> then it will be running under whatever user happens to be the first one to make a dns request
2022-03-30 14:36:19 <Hello71> not to mention the environment and other process context, e.g. what if the process is sandboxed and cannot fork
2022-03-30 14:37:31 <Hello71> if a service user runs dnsfunnel, it will not be allowed to bind to 53. even if it is, then it would be able to monitor and hijack any dns queries made by anybody on the system
2022-03-30 14:38:44 <donoban> yep, it seems very worse than I thought :S
2022-03-30 14:39:01 <panekj> if users have problem with DNS, it should be up to them to fix it. I have never seen a clean rootfs container run a daemon
2022-03-30 14:39:30 <panekj> or have anything else that /bin/*sh as entrypoint
2022-03-30 14:39:40 <Hello71> in general the idea of "start on demand" is implemented by systemd, dbus, launchd, even windows has it. it's not a *terrible* one, but one, it needs a global daemon to provide a clean process context for launch, and two, some users prefer to manage services manually
2022-03-30 14:41:38 <panekj> not to mention that containers don't have a proper init which supervises processes
2022-03-30 14:41:50 <panekj> 
ACTION waves at s6

2022-03-30 14:51:37 <skarnet> what do you think s6-overlay is for ;)
2022-03-30 14:52:07 <panekj> 'tis why I'm waving :P
2022-03-30 14:52:32 <skarnet> wave harder for the people in the back!
2022-03-30 14:58:58 <Ermine> Aren't superservers invented for 'start on demand' things?
2022-03-30 14:59:52 <Ariadne> what if we switched to systemd
2022-03-30 14:59:53 <Ariadne> 
ACTION runs

2022-03-30 15:00:53 <panekj> I actually would like to run an OS based on glibc, systemd and apk
2022-03-30 15:05:50 <Ermine> Ariadne: this is a nightmare plot
2022-03-30 15:11:27 <Ariadne> panekj: $dayjob is working on one that has 2 out of 3 of those things
2022-03-30 15:12:52 <panekj> I mean, I would like to not run OS with glibc, but it's quite often necessary for many things, and systemd can be only replaced by s6 feature-wise iirc
2022-03-30 15:22:46 <skarnet> Ermine: the problem is that "start on demand" is badly defined. Nobody cares to pinpoint what exactly should be listening to what, and what should be "started". Generally "started" refers to a process, but on Unix you always have a listener process already, so it's not a meaningful definition.
2022-03-30 15:23:42 <skarnet> A more helpful way of seeing things is "only allocate on demande the heavy resources necessary to provide the service", in which case yes, superservers absolutely do that
2022-03-30 15:24:08 <skarnet> but some people will see a superserver process and squeak like sows
2022-03-30 15:25:13 <skarnet> people don't understand that a process that does nothing and doesn't commit a lot of RAM is harmless
2022-03-30 15:26:31 <Ariadne> all of this is pointless bikeshedding re: docker
2022-03-30 15:26:49 <Ariadne> if it does not fit the docker process model, it will not be adopted
2022-03-30 15:27:23 <Ariadne> so there is no point in bikeshedding solutions to self-inflicted problems that docker users don't want to solve
2022-03-30 15:30:02 <skarnet> I didn't even read above and what is that nonsense about dnsfunnel requiring modification of container entrypoints?
2022-03-30 15:30:28 <skarnet> could we please do without the FUD in this channel at least?
2022-03-30 15:31:54 <skarnet> if the problem is that people run their Alpine container with their own entrypoint, then of course you can't have a process pre-run in the container
2022-03-30 15:33:07 <skarnet> but I thought it was long established that not using a proper init system when entering a container was super restrictive on what you can do, and as soon as you want to have something a little more featureful than process state changes on steroids, you needed an init system
2022-03-30 15:33:44 <skarnet> so yeah, obviously if people want ENTRYPOINT ["my", "crappy", "service"] they'll get what they pay for
2022-03-30 15:35:48 <skarnet> and I don't think it's a good idea to bend backwards to accommodate that use, it's an okay use when you know what you are doing, it's not an okay use when you need workarounds
2022-03-30 15:37:20 <ikke> skarnet: That's how docker is used, dedicated single application containers
2022-03-30 15:37:43 <ikke> with at most a small init that does bare minimum init things
2022-03-30 15:38:08 <skarnet> docker is used in many ways, and "single application" does not mean 'single process'
2022-03-30 15:38:17 <ikke> So if you want a dnsfunnel service, it tends to be run in a dedicated container where other containers have access to
2022-03-30 15:38:47 <skarnet> I'm not sure how much clearer I can be about this
2022-03-30 15:38:58 <skarnet> I *don't want* a dnsfunnel service
2022-03-30 15:39:17 <skarnet> I want a workaround to the broken DNS resolver problem
2022-03-30 15:40:03 <ikke> skarnet: say people want to run nginx, a lot of times, people will just take a default nginx image
2022-03-30 15:40:07 <ikke> which _just_ runs nginx
2022-03-30 15:40:42 <skarnet> yup, and that's almost reasonable for a nginx service
2022-03-30 15:41:00 <skarnet> (less so if you take logging into account)
2022-03-30 15:41:36 <skarnet> but that's what I said: using containers as a deluxe process state change mechanism
2022-03-30 15:42:28 <ikke> But in that usecase, it's a lot more effort to expand the nginx image to include a supervisor and dnsfunnel and make sure everything runs
2022-03-30 15:42:54 <ikke> Nothing says that docker cannot be used that way, but solutions that require that will more often than not be dismissed
2022-03-30 15:44:25 <skarnet> tbh nothing is going to slam /etc/resolv.conf if only nginx is running in that container
2022-03-30 15:44:43 <skarnet> so in an environment where there's one container per service, they all have the same resolv.conf and it's static
2022-03-30 15:45:07 <skarnet> so it's entirely possible to make a container with a non-broken resolver in it
2022-03-30 15:45:28 <skarnet> the issue is when resolv.conf gets slammed by automatic overwrites
2022-03-30 15:45:49 <skarnet> so the Docker model isn't even a problem here
2022-03-30 15:46:20 <skarnet> the obstacle is more k8s imposing its own resolver to everything
2022-03-30 15:49:00 <ikke> obstacle to what exactly?
2022-03-30 15:49:46 <skarnet> to having working DNS resolution even with broken nameservers, isn't that what we're talking about from the beginning?
2022-03-30 15:51:18 <ikke> It started with the mention that the musl resolver was not good enough
2022-03-30 15:51:49 <ikke> To me, that sounds like a different issue from what's in /etc/resolv.conf
2022-03-30 15:52:41 <ikke> (or what would update it)
2022-03-30 15:52:45 <skarnet> there are two places where you can act
2022-03-30 15:53:43 <skarnet> the first one is the musl resolver, but you can only fix it by adding TCP, which will help for some stuff but won't solve the problem of servers returning incorrect results
2022-03-30 15:54:08 <skarnet> the second one is the cache pointed to by /etc/resolv.conf
2022-03-30 15:54:43 <skarnet> by running a cache that will actually work around the problems of the servers
2022-03-30 15:54:59 <skarnet> (that's what dnsfunnel does, except it's not a cache, just a dumb proxy)
2022-03-30 15:55:46 <skarnet> but if the infrastructure forcefully edits resolv.conf to point to its own caches that don't do the necessary workarounds, there's nothing we can do
2022-03-30 15:56:57 <ikke> even more if something would entirely bypass /etc/resolv.conf
2022-03-30 15:57:07 <skarnet> nothing is supposed to
2022-03-30 15:57:35 <skarnet> no client is going to come with its own resolving cache
2022-03-30 15:57:49 <skarnet> (and if one does, fixing DNS is entirely its responsibility)
2022-03-30 16:02:38 <ikke> But the problem you stated (things changing /etc/resolv.conf) is different from what was discussed (how to use dnsfunnel in the first place)
2022-03-30 16:03:02 <ikke> That's why I was confused
2022-03-30 16:05:21 <ikke> If something can just override /etc/resolv.conf, like you said, I don't think there is a lot you can do to prevent that
2022-03-30 18:06:00 <Ermine> Btw what is the problem with musl dns? Does it lack implementation of some part of dns, or is it buggy, or ist it not resilient enough against broken servers?
2022-03-30 18:07:48 <Habbie> it lacks implementation of DNS over TCP
2022-03-30 18:09:40 <ikke> meaning a response is limited to a single packet
2022-03-30 18:12:12 <Habbie> does it even do EDNS?
2022-03-30 18:15:59 <ikke> Apparently not
2022-03-30 18:16:28 <ikke> "The first issue is about the lack of support of musl libc, the C standard library that powers Alpine Linux, for DNS over TCP or EDNS (Extension Mechanisms for DNS)."
2022-03-30 18:32:54 <Habbie> oh right
2022-03-30 18:33:02 <Habbie> then the actual problem is "a response is limited to 512 bytes"
2022-03-30 19:02:45 <skarnet> ikke: there are two related but separate problems
2022-03-30 19:07:50 <ikke> musl not supporting tcp, and components modifying /etc/resolv.conf?
2022-03-30 19:08:22 <ikke> dnsfunnel attempts to fix the first, but the latter interferes with that?
2022-03-30 19:17:53 <skarnet> yes. (the first is musl not supporting tcp + some servers being broken, which is why dnsfunnel may still be relevant even after musl is fixed.)
2022-03-30 19:18:58 <skarnet> when software clobbers /etc/resolv.conf, they can send your clients pointing to a cache you haven't chosen to use, and that is a bad thing, and one I'm working on fixing at this moment.
2022-03-30 19:20:31 <ikke> Looking forward to see what you've come up with
2022-03-30 21:42:03 <Ariadne> Habbie: i just want dns over tcp, i don't want musl to use eDNS
2022-03-30 21:42:11 <Ariadne> i think eDNS is Bad Actually
2022-03-30 21:43:53 <Ariadne> especially since we have TCP Fast Open these days, there is literally no reason to do eDNS
2022-03-30 21:45:40 <Habbie> "have" is doing a lot of lifting in that sentence
2022-03-30 21:45:46 <Habbie> 8.8.8.8 had broken fast open until a few months ago
2022-03-30 21:46:02 <Habbie> not saying you're wrong, but the real world is a shitty place
2022-03-30 21:46:17 <panekj> imaginary worlds are also shitty
2022-03-30 21:46:57 <Habbie> another terrible reason is that TCP performance is terrible in some resolver stacks
2022-03-30 21:47:00 <Habbie> which should be fixed, of course
2022-03-30 21:47:03 <Habbie> but those stacks, for now, love EDNS
2022-03-30 21:51:27 <Ariadne> yes, im just saying from a client point of view, if you have good tcp performance, and you support TFO, ...
2022-03-30 21:54:10 <Habbie> yep
2022-03-30 21:54:11 <Habbie> not wrong :)
2022-03-30 21:56:00 <Ermine> Dns over quic is cursed I guess
2022-03-30 21:56:28 <Habbie> you'll need a quic stack
2022-03-30 21:56:32 <Habbie> in your libc
2022-03-30 21:56:35 <Habbie> in the distance, sirens
2022-03-30 21:56:45 <psykose> ikke: ah i see, setuptools 59 needs py3-more-itertools, but py3-more-itertools needs setuptools
2022-03-30 21:56:51 <Ariadne> amazing
2022-03-30 21:56:57 <Ariadne> python: the gift that keeps on giving
2022-03-30 21:57:25 <psykose> to be fair the list ends there
2022-03-30 21:57:34 <psykose> that's.. it
2022-03-30 21:57:53 <psykose> then setuptools 59 removes uhh
2022-03-30 21:58:01 <psykose> ssl_support and lib2to3
2022-03-30 21:58:08 <psykose> iirc nothing uses those except one thing
2022-03-30 21:58:20 <psykose> so it should be fine, just have to figure out how to solve this circle
2022-03-30 21:58:29 <psykose> i guess just dumping the files from pypi? :)
2022-03-30 21:58:55 <psykose> ole curl | unzip
2022-03-30 21:59:03 <panekj> why python stuff keeps having circular deps
2022-03-30 21:59:31 <psykose> the funniest thing in python to me is pyproject.toml being a standard yet at the time they made it one there was no toml parsed in std
2022-03-30 21:59:46 <psykose> 3.11 will add a toml parser, but it's still funny
2022-03-30 22:00:41 <Ermine> So how many standards python has now?
2022-03-30 22:50:37 <Hello71> but as we all know, python comes batteries included
2022-03-30 22:52:36 <Hello71> the batteries for the remote control are included, but you have to plug in the tv with six different adapters and it always feels like it's going to start a fire
2022-03-31 04:40:09 <ikke> psykose: note that setuptools does vendor these libs, but we explicitly remove that
2022-03-31 04:40:54 <psykose> ah, then i guess it's ok to just keep the vendor
2022-03-31 04:41:14 <ikke> makes bootstrapping simpler
2022-03-31 04:41:26 <ikke> they will become part of the package
2022-03-31 04:41:35 <ikke> but just as a vendor lib
2022-03-31 04:44:45 <boomanaiden154> The plan is just to take the hit on package size/less control over the dependencies?
2022-03-31 04:45:38 <ikke> there is no plan yet
2022-03-31 04:45:48 <ikke> just options
2022-03-31 04:46:54 <ikke> if we can build more-itertools without setuptools, that would be preferred
2022-03-31 04:47:09 <ikke> but not sure how to achieve that
2022-03-31 04:48:32 <boomanaiden154> Is the Jaraco dependency still an issue?
2022-03-31 04:48:38 <ikke> in 60
2022-03-31 04:48:49 <ikke> 59 not yet
2022-03-31 04:50:04 <ikke> or we need a setuptools that can be bootstrapped with minimal dependencies and then use that to bootstrap the latest one
2022-03-31 04:50:12 <ikke> to build the latest one*
2022-03-31 04:51:19 <ikke> setuptools-stage0
2022-03-31 04:51:28 <boomanaiden154> Yep. Probably the cleanest solution.
2022-03-31 04:52:07 <boomanaiden154> The only other way that I could think of would be to rewrite the setup scripts for the needed packages in shell or something and that would be a pain to maintain.
2022-03-31 04:52:18 <ikke> yeah
2022-03-31 06:38:46 <smcavoy> anything known to be wrong with the ppc64le builders? see https://gitlab.alpinelinux.org/smcavoy/aports/-/jobs/676068 (missing gpm-dev on ppc64le)
2022-03-31 07:25:46 <ncopa> smcavoy: 2cf47a8f695fd160a3c3572f0ee46cf8f6ab746b should fix that
2022-03-31 07:26:25 <ncopa> hum
2022-03-31 07:26:32 <ncopa> looks liek build-edge-ppc64le is MIA
2022-03-31 09:37:33 <omni> ncopa: !32655
2022-03-31 10:26:32 <ikke> ncopa: there is/was a site maintenance 
2022-03-31 10:26:36 <ikke> see #-infra
2022-03-31 10:26:49 <ikke> But it's taking longer than they initially mentioned
2022-03-31 10:27:16 <ikke> "we forgot to share; but there is a maintenance going on in the whole University which also affects our lab."
2022-03-31 12:09:20 <ncopa> im working on openssl3 upgrade
2022-03-31 13:26:42 <omni> !32594
2022-03-31 13:27:29 <omni> I used separate commits to enable on riscv64, thought it'd be easier to revert, is that ok?
2022-03-31 13:28:11 <ikke> sure
2022-03-31 13:28:27 <ikke> We do not have a policy of at most 1 commit per package
2022-03-31 13:29:33 <ncopa> hum. libbsd package is somewhat broken
2022-03-31 13:30:32 <ncopa> instead of shipping a /usr/lib/libbsd.so symlink pointing to they ship a GNU ld script that contains
2022-03-31 13:30:35 <ncopa> OUTPUT_FORMAT(elf64-x86-64)                                                                                                     
2022-03-31 13:30:35 <ncopa> GROUP(/usr/lib/libbsd.so.0.11.6 AS_NEEDED(-lmd))
2022-03-31 13:31:09 <ncopa> I guess that sort of works, but ti also means that abuild does not automatically pull in libbsd as a dependency for libbsd-dev
2022-03-31 13:31:31 <ncopa> and it also means that the libbsd.so is included in the libbsd package, not in libbsd-dev
2022-03-31 13:31:59 <ncopa> to me a awhile to find out because the static lib is included with libbsd-dev and pulled in, which gave missing symbols
2022-03-31 14:06:46 <ncopa> I can understand that openssl3 was problematic last time. There have been a handful of build errors or runtime tests that has failed so far
2022-03-31 14:07:02 <ncopa> but I have found patches from upstream or from fedora for most of it so far
2022-03-31 14:07:10 <ncopa> many of those patches are relatively new
2022-03-31 15:07:46 <Habbie> it helps that ubuntu 22.04 has openssl3
2022-03-31 15:24:17 <ncopa> it does
2022-03-31 15:24:35 <ncopa> and macos something, and fedora
2022-03-31 15:24:51 <ncopa> i found the first problematic package: openvpn
2022-03-31 15:25:33 <ncopa> it builds but tests fails
2022-03-31 15:25:48 <ncopa> https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1844760.html
2022-03-31 15:26:22 <ncopa> fedora cheats by not running make check https://src.fedoraproject.org/rpms/openvpn/blob/rawhide/f/openvpn.spec#_100
2022-03-31 16:11:32 <donoban> lol
2022-03-31 16:32:13 <donoban> ncopa: I think that most tests are related to deprecated ciphers "Support for these insecure ciphers will be removed in OpenVPN 2.7."
2022-03-31 16:32:41 <donoban> could just build it with they disabled and skip from tests?
2022-03-31 17:21:33 <ikke> ppc64le builder is back
2022-03-31 17:22:31 <Habbie> i'm seeing double!
2022-03-31 17:23:13 <ikke> in #-infra?
2022-03-31 17:23:22 <Habbie> no, in POWER Developer Exchange :D
2022-03-31 17:23:25 <ikke> ah
2022-03-31 17:23:29 <ikke> yeah