2022-03-01 03:06:38 <psykose> algitbot: retry master
2022-03-01 03:07:18 <psykose> i'm pretty sure that was purged already, and the distfiles tarball does match the checksum, and what fetch() gives..
2022-03-01 16:23:41 <psykose> algitbot: kick master
2022-03-01 16:23:44 <psykose> algitbot: retry master
2022-03-01 16:23:53 <psykose> algitbot: retry master
2022-03-02 13:56:15 <ikke> psykose: openvdb seems to have passed now
2022-03-02 13:56:24 <psykose> yeah cause i disabled the check
2022-03-02 13:56:43 <psykose> if it didn't run all the tests as 'one' test i would have found the specific one :p
2022-03-02 13:57:08 <psykose> really wish people had at least some long timeouts on their testsuites
2022-03-03 16:30:07 <nmeum> please don't fail on the builders 🙏
2022-03-03 16:56:53 <nmeum> does it hang? this is taking longer than expected
2022-03-03 16:57:38 <nmeum> algitbot: kick master
2022-03-03 16:57:48 <ikke> nmeum: that would only affect riscv64
2022-03-03 16:57:53 <nmeum> ah :(
2022-03-03 16:58:02 <nmeum> can you check what is doing at the moment?
2022-03-03 16:58:26 <ikke> 14885 buildozer   20   0  1600    16     0 R 100.  0.0 26:11.64          │                       └─ yes The quick brown fox jumps over the lazy dog
2022-03-03 16:59:15 <nmeum> Oo
2022-03-03 16:59:22 <nmeum> that's from the md5sum tests it seems
2022-03-03 16:59:29 <nmeum> can you access the log?
2022-03-03 17:00:12 <ikke> https://tpaste.us/Rx0v 
2022-03-03 17:00:17 <ikke> Or do you want the full log?
2022-03-03 17:01:44 <nmeum> looks like it's hanging on the md5sum test indeed
2022-03-03 17:01:59 <nmeum> that should be the next after the md5sum-verifies-non-binary-file file
2022-03-03 17:02:53 <nmeum> https://git.busybox.net/busybox/tree/testsuite/md5sum.tests#n29
2022-03-03 17:03:03 <nmeum> > text=`yes "$text" | head -c 9999`
2022-03-03 17:03:07 <nmeum> how is it even possible for this to hang?
2022-03-03 17:04:02 <ikke> It seems to be never ending
2022-03-03 17:04:24 <ikke> It does receive SIGPIPE
2022-03-03 17:04:35 <ikke> so is it ignoring SIGPIPE for some reason?
2022-03-03 17:05:09 <ikke> https://tpaste.us/9bD0 
2022-03-03 17:06:20 <nmeum> is there a parent process or something that catches sigpipe?
2022-03-03 17:06:31 <nmeum> didn't we have an issue like that on the builders in the past?
2022-03-03 17:06:34 <ikke> └─ /bin/sh /home/buildozer/aports/main/busybox/src/build-dynamic/testsuite/md5sum.tests
2022-03-03 17:06:41 <ikke> don't recall
2022-03-03 17:07:13 <ikke> https://tpaste.us/nV1E 
2022-03-03 17:07:21 <nmeum> the m4 testsuite had a similar issue
2022-03-03 17:07:31 <nmeum> where a sigpipe test case only failed on the builders
2022-03-03 17:08:45 <ikke> can parents prevent children from receiving signals?
2022-03-03 17:11:15 <nmeum> I think the signal handlers are inherited during fork, right?
2022-03-03 17:12:50 <nmeum> how does the builder setup work? is it mqtt-exec -> buildrepo -> abuild?
2022-03-03 17:14:12 <ikke> yes
2022-03-03 17:14:41 <ikke> aports-build in between as well
2022-03-03 17:14:50 <ikke> mqtt-exec -> aports-build -> buildrepo -> abuild
2022-03-03 17:15:59 <ikke> mqtt-exec only has handlers for this: signal(SIGCHLD, SIG_IGN);
2022-03-03 17:16:10 <nmeum> yeah, that shouldn't be a problem
2022-03-03 17:16:53 <ikke> The rest are shell or lua scripts
2022-03-03 17:24:20 <nmeum> but if there is no signal mask and no custom signal handler for SIGPIPE than the signal should, by default, result in program termination
2022-03-03 17:24:49 <ikke> hmm, anything else that could inhibit that
2022-03-03 17:30:34 <nmeum> can you figure out the PID of the low-running yes command and check /proc/[pid]/status?
2022-03-03 17:30:54 <nmeum> that file should contain the list of signals blocked, ignored and caught
2022-03-03 17:30:59 <nmeum> SigBlk, SigIgn, SigCgt
2022-03-03 17:31:50 <ikke> https://tpaste.us/zQWJ 
2022-03-03 17:32:33 <nmeum> now I just need to figure out how to parse this ':D
2022-03-03 17:32:37 <ikke> yeah
2022-03-03 17:33:59 <ikke> man 7 signal has a table I believe
2022-03-03 17:34:14 <ikke> but that's just the signal numbers
2022-03-03 17:35:05 <ikke> nmeum: https://stackoverflow.com/a/61365083/20261
2022-03-03 17:35:16 <nmeum> >>> import signal
2022-03-03 17:35:22 <nmeum> >> 0x0000000000001004 & signal.SIGPIPE
2022-03-03 17:35:26 <nmeum> 4
2022-03-03 17:35:31 <nmeum> so it's ignored?
2022-03-03 17:35:34 <ikke> I guess?
2022-03-03 17:35:46 <nmeum> but why??
2022-03-03 17:36:40 <ikke> going up the process tree
2022-03-03 17:37:27 <nmeum> good idea
2022-03-03 17:39:58 <ikke> buildrepo has SigIgn: 0000000000001006
2022-03-03 17:40:18 <ikke> then abuild: SigIgn: 0000000000001004
2022-03-03 17:44:38 <nmeum> hm, maybe we are also interpreting this value wrong
2022-03-03 17:45:08 <ikke> the link I shared has a script to decode it
2022-03-03 17:46:28 <ikke> nmeum: http://jeff66ruan.github.io/blog/2014/03/31/sigpnd-sigblk-sigign-sigcgt-in-proc-status-file/
2022-03-03 17:48:56 <ikke> so I suppose only sigint and sigquit are ignored
2022-03-03 17:50:53 <ikke> Oh, I think sigpipe as well
2022-03-03 17:51:01 <ikke> 0b1000000000110
2022-03-03 17:51:06 <ikke> sigpipe is 13
2022-03-03 17:51:14 <nmeum> yeah, sigpipe is 13
2022-03-03 17:51:55 <ikke> so that's the most significant bit that is set
2022-03-03 17:53:13 <nmeum> right, it seems to be ignored indeed?
2022-03-03 17:53:23 <nmeum> when I run abuild locally I get `SigIgn:	0000000000000004`
2022-03-03 17:56:55 <nmeum> so if it is blocked and the sigign is inherited from the parent, what is the first process where sigpipe is ignored in that hierarchy?
2022-03-03 17:57:53 <ikke> mqtt-exec apparently
2022-03-03 17:58:08 <ikke> 62977: SigIgn:  0000000000011000
2022-03-03 17:58:55 <nmeum> and mqtt-exec is forked by supervise-daemon so maybe supervise-daemon is setting this up?
2022-03-03 17:59:05 <ikke> perhaps
2022-03-03 17:59:46 <nmeum> https://github.com/OpenRC/openrc/blob/master/src/rc/supervise-daemon.c#L311
2022-03-03 17:59:51 <nmeum> it does seem to configure a signal mask
2022-03-03 17:59:55 <nmeum> but not sure if that's related
2022-03-03 18:00:11 <nmeum> would be kind of weird if it would always ignore SIGPIPE, no?
2022-03-03 18:00:28 <ikke> for a daemon?
2022-03-03 18:00:53 <nmeum> can you configure the mqtt-exec service to not use supervise-daemon?
2022-03-03 18:01:00 <ikke> nmeum: was thinking about that
2022-03-03 18:02:21 <nmeum> maybe also compare to sigign on the ci for example (where the busybox tests pass) to ensure we are not debugging this in an entirely wrong direction
2022-03-03 18:02:43 <nmeum> I am somewhat confused atm
2022-03-03 18:03:06 <ikke> about what is setting that signal mask?
2022-03-03 18:03:10 <ikke> or ignoring it?
2022-03-03 18:03:27 <nmeum> hm? you mean in the openrc code?
2022-03-03 18:03:38 <ikke> no, was wondering what you were confused about
2022-03-03 18:03:53 <nmeum> ah
2022-03-03 18:04:11 <nmeum> just in general, because if SIGPIPE is always ignored on the builders than I would expect us to have run into that sooner
2022-03-03 18:04:23 <ikke> yea
2022-03-03 18:05:02 <ikke> on CI we are directly invoking abuild though, no mqtt-exec, no buildrepo, no aports-build
2022-03-03 18:06:03 <nmeum> right, if SigIgn doesn't include SIGPIPE on the CI we could at least "confirm" that this does seem to be an isue introduced by mqtt-exec, buildrepo, or aports-build (or supervise-daemon)
2022-03-03 18:08:20 <ikke> SigIgn: 0000000000011000, when executing mqtt-exec manually in a docker container
2022-03-03 18:09:30 <nmeum> so sigpipe also ignored there?
2022-03-03 18:09:57 <ikke> 24    rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fc8c9906c8a}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
2022-03-03 18:10:02 <ikke> from strace
2022-03-03 18:10:39 <ikke> nmeum: mind you, when running mqtt-exec, not in our CI process
2022-03-03 18:10:49 <nmeum> right
2022-03-03 18:11:04 <nmeum> that is the trace of mqtt-exec?
2022-03-03 18:11:07 <ikke> yes
2022-03-03 18:11:24 <nmeum> > sa_handler=SIG_IGN
2022-03-03 18:11:26 <nmeum> well
2022-03-03 18:11:35 <ikke> yes
2022-03-03 18:11:58 <ikke> But I only see mqtt-exec setting a handler for SIGCHLD
2022-03-03 18:12:42 <nmeum> ohhh
2022-03-03 18:12:46 <ikke> https://github.com/ncopa/mqtt-exec/blob/master/mqtt-exec.c
2022-03-03 18:12:47 <nmeum> it uses  mosquitto
2022-03-03 18:12:53 <nmeum> maybe mosquitto sets a signal handler
2022-03-03 18:13:08 <ikke> right
2022-03-03 18:13:14 <nmeum> ohohhh
2022-03-03 18:13:15 <nmeum> it does
2022-03-03 18:13:15 <nmeum> wtf
2022-03-03 18:13:50 <nmeum> https://github.com/eclipse/mosquitto/blob/d5970ca9985f4d3193fe7a359707723090bb13e9/lib/mosquitto.c#L112-L114
2022-03-03 18:14:00 <nmeum> https://github.com/eclipse/mosquitto/blob/d5970ca9985f4d3193fe7a359707723090bb13e9/src/mosquitto.c#L413
2022-03-03 18:14:02 <nmeum> I think we found it
2022-03-03 18:14:15 <ikke> 🤦
2022-03-03 18:14:21 <nmeum> beatiful
2022-03-03 18:14:52 <nmeum> we can install the default handler again in mqtt-exec, but not sure if that breaks mosquitto
2022-03-03 18:15:12 <nmeum> but wow: that really means SIGPIPE just doesn't work as expected on the builders
2022-03-03 18:15:42 <ikke> very interesting
2022-03-03 18:16:57 <nmeum> how do we fix this? :D
2022-03-03 18:17:11 <ikke> very good question
2022-03-03 18:17:26 <nmeum> mosquitto even mentions it in their changelog
2022-03-03 18:17:28 <nmeum> > - Ignore SIGPIPE to prevent unnecessary client quits in threaded mode.
2022-03-03 18:17:35 <nmeum> present since 2012
2022-03-03 18:18:05 <nmeum> we can try adding:
2022-03-03 18:18:06 <nmeum> > signal(SIGPIPE, SIG_DFL);
2022-03-03 18:18:10 <nmeum> to mqtt-exec
2022-03-03 18:18:16 <nmeum> after the SIG_IGN for SIGCHLD
2022-03-03 18:19:04 <nmeum> just two problems with this: 1) I don't know if any of the mosquitto functions called after overwrite this and b) not sure what impact this has on mosquitto
2022-03-03 18:19:29 <ikke> mosquitto_connect is called after setting the signal handler in mqtt-exec
2022-03-03 18:19:50 <nmeum> I think the signal handler is set by mosquitto_new, not mosquitto_connect
2022-03-03 18:19:58 <ikke> ok
2022-03-03 18:20:07 <nmeum> and mosquitto_new is called before signal(3) in the mqtt-exec code
2022-03-03 18:20:18 <nmeum> so, should at the very least be worth trying (:
2022-03-03 18:20:25 <ikke> yes, I think so
2022-03-03 18:21:31 <nmeum> ah, we can also change the signal mask in a different process in the procses hierarchy like aports-build or buildrepo
2022-03-03 18:21:50 <nmeum> though not sure how you would go about doing that from lua
2022-03-03 18:22:03 <ikke> aports-build might make sense
2022-03-03 18:22:13 <ikke> that would be sh
2022-03-03 18:22:33 <ikke> trap '' 13?
2022-03-03 18:22:57 <nmeum> yeah, maybe
2022-03-03 18:23:19 <nmeum> worth a try I guess
2022-03-03 18:23:45 <ikke> rt_sigaction(SIGPIPE, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
2022-03-03 18:23:47 <ikke> rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1 RT_2], sa_flags=SA_RESTORER, sa_restorer=0x7f6197326c8a}, NULL, 8) = 0
2022-03-03 18:26:59 <nmeum> that is using the mqtt-exec change?
2022-03-03 18:27:32 <ikke> nmeum: that's just a test script with `trap '' 13` in it
2022-03-03 18:28:11 <ikke> algitbot: retry master
2022-03-03 18:28:55 <ikke> nmeum: I've hotpatched aports-build, seems to help
2022-03-03 18:29:36 <ikke> oh, no, still set :(
2022-03-03 18:29:46 <ikke> SigIgn: 0000000000001004
2022-03-03 18:31:05 <nmeum> in your strace testscript output sigpipe is first set to the default handler and then ignored, no?
2022-03-03 18:31:18 <ikke> yes
2022-03-03 18:31:49 <nmeum> so that's why it doesn't work i guess
2022-03-03 18:31:59 <ikke> nmeum: yup
2022-03-03 18:32:14 <nmeum> have you tried the mqtt-exec change?
2022-03-03 18:32:21 <ikke> not yet
2022-03-03 18:32:31 <ikke> hotpatching aports-build is easier
2022-03-03 18:32:35 <nmeum> right
2022-03-03 18:33:30 <ikke> ah, trap - 13
2022-03-03 18:33:37 <ikke> Now I only see the DFL
2022-03-03 18:34:31 <ikke> algitbot: retry master
2022-03-03 18:36:04 <ikke> hmm, still 0000000000001000
2022-03-03 18:40:58 <nmeum> hm
2022-03-03 18:41:04 <ikke> https://tpaste.us/X0ql
2022-03-03 18:41:25 <nmeum> looks good
2022-03-03 18:42:57 <nmeum> should even be able to test that in a docker container just running mqtt-exec
2022-03-03 18:43:10 <ikke> right
2022-03-03 18:43:13 <nmeum> like run sleep 10000 using mqtt-exec and check sigign
2022-03-03 18:46:57 <ikke> nmeum: :(
2022-03-03 18:47:05 <nmeum> doesn't work? :O
2022-03-03 18:47:11 <ikke> SigIgn: 0000000000001006
2022-03-03 18:47:49 <nmeum> can you check with strace if there is a second call to rt_sigaction which overrides the SIG_DFL again?
2022-03-03 18:51:58 <nmeum> I just checked locally with mqtt-exec. I get SigIgn: 0000000000011000 (without the patch -> signal 17 and signal 13 ignored) and SigIgn: 0000000000010000 with the patch (only signal 17 ignored)
2022-03-03 18:52:19 <nmeum> (17 should be SIGCHLD btw)
2022-03-03 18:52:55 <ikke> rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fe52d851c8a}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7fe52d851c8a}, 8) = 0
2022-03-03 18:53:55 <ikke> nmeum: hmm, right
2022-03-03 18:54:03 <nmeum> the rt_sigaction looks good
2022-03-03 18:54:10 <ikke> SigIgn: 0000000000010000
2022-03-03 18:54:18 <nmeum> yeah, that's what we want
2022-03-03 18:54:20 <ikke> testing on the builder
2022-03-03 18:57:13 <ikke> this is on the builder now: SigIgn: 0000000000010000
2022-03-03 18:57:19 <ikke> so looks good
2022-03-03 18:57:26 <nmeum> nice, but it still fails?
2022-03-03 18:57:36 <ikke> No, need to restart the build
2022-03-03 18:57:39 <nmeum> ah
2022-03-03 18:57:41 <ikke> algitbot: retry master
2022-03-03 19:00:37 <ikke> \o/
2022-03-03 19:00:37 <psykose> clear :)
2022-03-03 19:00:42 <psykose> grats
2022-03-03 19:00:53 <nmeum> yeaaahhh
2022-03-03 19:01:08 <nmeum> lovely debugging session as always ikke ;)
2022-03-03 19:01:11 <ikke> heh
2022-03-03 19:01:13 <ikke> :)
2022-03-03 19:01:19 <nmeum> the m4 tests should also pass now I think
2022-03-03 19:01:32 <ikke> nmeum: do you want to officially patch this?
2022-03-03 19:02:01 <nmeum> I think it would be preferable to not do it in mqtt-exec since it might affect mosquitto connection handling
2022-03-03 19:02:10 <nmeum> but I also don't have any better idea for now
2022-03-03 19:03:14 <ikke> me neither
2022-03-03 19:03:26 <ikke> maybe a wrapper program?
2022-03-03 19:03:27 <nmeum> maybe we just keep it in mqtt-exec as a test run for now
2022-03-03 19:04:50 <nmeum> ^ this should pass too know i think
2022-03-03 19:04:54 <nmeum> s/know/now/
2022-03-03 19:05:33 <ikke> fyi, I've only patched the x86_64 builder
2022-03-03 19:05:55 <nmeum> oh
2022-03-03 19:06:12 <nmeum> we could make aport-build depend on luaposix
2022-03-03 19:06:13 <nmeum> and use https://luaposix.github.io/luaposix/modules/posix.signal.html#signal
2022-03-03 19:08:08 <ikke> algitbot: retry master
2022-03-03 19:08:37 <ikke> nmeum: you didn't bump pkgrel
2022-03-03 19:08:42 <nmeum> oh oops
2022-03-03 19:09:04 <nmeum> should I?
2022-03-03 19:09:13 <ikke> if you want to test the test suite
2022-03-03 19:09:13 <nmeum> or do we first want to patch all builders by having a patch for this in aports.git?
2022-03-03 19:09:45 <nmeum> right, just wondering if we want to fix it on all builders first (:
2022-03-03 19:09:52 <ikke> yes, that would help
2022-03-03 19:09:58 <ikke> most of them are stuck anyway now
2022-03-03 19:10:28 <nmeum> so changing this in mqtt-exec yeah or nay?
2022-03-03 19:10:40 <nmeum> that would certaintly be the easiest for now
2022-03-03 19:10:47 <ikke> I think it's fairly innocent right?
2022-03-03 19:10:53 <nmeum> yes
2022-03-03 19:10:54 <ikke> At most mqtt-exec could exit
2022-03-03 19:11:09 <nmeum> in which case it would be restarted by supervise-daemon
2022-03-03 19:11:12 <ikke> yes
2022-03-03 19:11:19 <nmeum> I think we do that for now and come up with something more fancy latter?
2022-03-03 19:11:23 <ikke> yes
2022-03-03 19:11:26 <nmeum> ok
2022-03-03 19:11:46 <nmeum> I will push a quick patch to mqtt-exec and create a gitlab issue
2022-03-03 19:11:58 <ikke> 👍
2022-03-03 19:20:20 <ikke> nmeum: is it not possible for mqtt-exec to reset it for child processes only?
2022-03-03 19:20:29 <ikke> or would that complicate things?
2022-03-03 19:20:40 <nmeum> oh right
2022-03-03 19:20:43 <nmeum> we can do it after the fork
2022-03-03 19:20:45 <nmeum> that should work
2022-03-03 19:20:47 <ikke> yea
2022-03-03 19:20:58 <nmeum> will do
2022-03-03 19:21:07 <nmeum> I will just push that to aports.git if it doesn't work we fallback to the old solution :D
2022-03-03 19:21:32 <ikke> fine with me
2022-03-03 19:25:37 <nmeum> ikke: ^
2022-03-03 19:25:56 <nmeum> do you need to update the builders manually?
2022-03-03 19:26:24 <ikke> nmeum: I need to restart mqtt-exec
2022-03-03 19:26:51 <ikke> nmeum: I can check x86_64 to be sure
2022-03-03 19:27:03 <nmeum> *nod*
2022-03-03 19:28:59 <ikke> Hmm, nothings building atm
2022-03-03 19:29:04 <ikke> so cannot check child processes
2022-03-03 19:29:11 <nmeum> I can bump pkgrel of m4
2022-03-03 19:29:18 <ikke> I'll check another builder
2022-03-03 19:29:36 <nmeum> ok
2022-03-03 19:32:06 <ikke> (need to restart it one more time)
2022-03-03 19:32:19 <ikke> algitbot: retry master
2022-03-03 19:32:57 <ikke> 0000000000000004
2022-03-03 19:32:59 <ikke> looks good
2022-03-03 19:33:37 <nmeum> sweet
2022-03-03 19:33:46 <nmeum> so I guess just deploy it on all builders and we are done?
2022-03-03 19:33:59 <nmeum> maybe wait to see if busybox build passes on aarch64
2022-03-03 19:34:13 <ikke> ^
2022-03-03 19:34:57 <nmeum> nice, ship it then 🚢
2022-03-03 19:42:24 <ikke> algitbot: retry master
2022-03-03 19:50:55 <ikke> nmeum: all have passed now
2022-03-03 19:51:06 <ikke> maybe you can bump m4 now?
2022-03-03 19:51:50 <nmeum> yes
2022-03-03 19:56:29 <nmeum> seems to have passed
2022-03-03 19:56:30 <nmeum> nice
2022-03-03 19:57:23 <ikke> yup
2022-03-03 19:58:31 <ikke> nice collaboration :)
2022-03-03 19:58:49 <nmeum> yeah, thanks!
2022-03-04 09:55:40 <psykose> sure
2022-03-04 15:04:27 <mps> when will be ppc64le removed? https://gitlab.alpinelinux.org/alpine/aports/-/jobs/650672
2022-03-04 15:07:15 <mps> fcolista: are you working on nftables upgrade?
2022-03-04 15:08:03 <mps> new release now 'makedepends' on self
2022-03-04 15:18:58 <fcolista>  mps hi!
2022-03-04 15:19:02 <fcolista> I do
2022-03-04 15:19:55 <mps> fcolista: ok, thanks. I started but didn't want to mess your package
2022-03-04 15:20:18 <mps> problem is in aports pkg can't makedepends on self
2022-03-04 15:25:41 <fcolista> mps, don't worry. If you are on it, go ahead. 
2022-03-04 15:31:55 <mps> fcolista: I stopped because have no idea how we should solve this makedepends problme. nftables-dev is subpkg, but it is needed now, and abuild doesn't allow this
2022-03-04 15:32:11 <fcolista> yes, I fixed it
2022-03-04 15:32:16 <fcolista> let me show you
2022-03-04 15:32:26 <mps> nice
2022-03-04 15:32:32 <fcolista> https://tpaste.us/lVaN
2022-03-04 15:32:42 <mps> just push it, I'll see in aports
2022-03-04 15:32:42 <fcolista> basically it's about the path for that include
2022-03-04 15:33:24 <mps> aha, that is solution I thought to do but was not sure, thanks
2022-03-04 15:34:35 <mps> so we have similar idea, good, I hope you will merge it
2022-03-04 15:34:46 <mps> heh, too fast ;)
2022-03-04 15:35:11 <fcolista> I'm going to send it upstream anyway
2022-03-04 15:35:26 <mps> yes, that is good idea
2022-03-05 04:45:36 <psykose> x.x
2022-03-05 11:14:11 <nmeum> algitbot: retry master
2022-03-05 11:19:00 <nmeum> :(((
2022-03-05 11:20:11 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/31666
2022-03-05 11:22:30 <ikke> https://tpaste.us/DBke 
2022-03-05 11:24:20 <PureTryOut> libbpf used to be 0.7.0 before  but got downgraded
2022-03-05 11:24:46 <PureTryOut> so I'm assuming it still has a tarball for 0.7.0 in it's cache and the upstream tarball changed for some reason
2022-03-05 11:25:10 <ikke> algitbot: retry master
2022-03-05 11:26:00 <nmeum> 🥳
2022-03-05 11:26:06 <PureTryOut> 🎉
2022-03-05 11:26:20 <ikke> renamed the file on distfiles
2022-03-05 11:26:34 <ikke> Hmm
2022-03-05 11:26:47 <ikke> is it suspicous that the diff contains 
2022-03-05 11:26:49 <ikke> +} LIBBPF_0.6.0;
2022-03-05 11:26:51 <ikke> 0.6.0
2022-03-05 11:26:54 <ikke> not 07.0?
2022-03-05 11:27:04 <PureTryOut> Yeah strange
2022-03-05 20:45:58 <psykose> look who's here
2022-03-05 20:46:14 <ikke> curious
2022-03-05 20:46:17 <psykose> :3
2022-03-05 20:48:48 <ikke> sadly no dmvpn
2022-03-05 20:48:54 <ikke> so I cannot access the host
2022-03-05 20:49:57 <ikke> https://github.com/Osse/git-stuff/blob/master/rebase-origin.txt
2022-03-05 20:50:05 <ikke> wrong chan
2022-03-06 17:13:43 <psykose> algitbot: retry master
2022-03-06 17:17:12 <psykose> algitbot: retry master
2022-03-06 17:50:11 <psykose> algitbot: retry master
2022-03-06 20:33:26 <ikke> oh, fun, segfault
2022-03-06 20:33:42 <ikke> build/lib.linux-i686-3.10/borg/testsuite/archiver.py::RemoteArchiverTestCase::test_recreate_target Fatal Python error: Segmentation fault
2022-03-06 20:34:43 <ikke> algitbot: retry master
2022-03-06 20:35:48 <psykose> i love those
2022-03-06 21:03:23 <psykose> magic self-fixing segfault :)
2022-03-06 21:03:31 <ikke> I love those even more
2022-03-06 21:04:39 <psykose> glslang is now ready too
2022-03-06 23:25:13 <psykose> lol
2022-03-06 23:27:48 <psykose> it built on ci, and then they removed the upstream tag
2022-03-06 23:28:12 <psykose> why is it _always_ python upstreams
2022-03-07 05:45:47 <psykose> algitbot: retry master
2022-03-07 05:55:58 <psykose> algitbot: retry master
2022-03-07 10:44:17 <psykose> ncopa: you missed a few new requested options for -lts
2022-03-08 08:14:13 <PureTryOut> psykose: gdal blocked by gdal?
2022-03-08 08:14:32 <psykose> i amended it in the next commit
2022-03-08 08:15:16 <psykose> libkml
2022-03-08 08:15:54 <PureTryOut> ah sorry missed that one
2022-03-08 08:16:11 <psykose> it was my mistake :)
2022-03-08 08:16:21 <psykose> i had just gotten out of a warm shower and had a light head x.x
2022-03-09 01:02:31 <psykose> algitbot: retry master
2022-03-09 13:55:17 <PureTryOut> when in doubt about breakage, update the pkgver 😄
2022-03-09 13:58:30 <psykose> haha
2022-03-09 13:58:37 <psykose> it didn't actually fix the arm32 failures
2022-03-09 13:58:42 <psykose> but i saw the upgrade while passing them
2022-03-09 15:53:20 <psykose> algitbot: retry master
2022-03-09 16:06:12 <ptrc> algitbot: retry master
2022-03-09 16:08:25 <psykose> algitbot: retry master
2022-03-09 16:30:56 <psykose> algitbot: retry master
2022-03-09 16:37:38 <psykose> algitbot: retry master
2022-03-09 16:59:06 <psykose> algitbot: retry master
2022-03-09 17:09:04 <psykose> mm
2022-03-10 22:42:12 <psykose> algitbot: retry master
2022-03-12 02:26:04 <psykose> algitbot: retry master
2022-03-12 09:17:57 <psykose> algitbot: retry master
2022-03-13 15:23:59 <psykose> mps: think you forgot that cgroup option
2022-03-13 15:41:14 <mps> psykose: uhm, yes
2022-03-13 15:41:19 <mps> sorry
2022-03-13 15:41:30 <psykose> it's okay :)
2022-03-13 15:43:25 <mps> I thought to wait for tomorrow 5.18 release and upgrade 5.17 anymore, but contemplated a little about that the 5.16.14 have important sec fixes and upgraded without looking at my notes
2022-03-13 15:43:40 <mps> s/5.18/5.17/
2022-03-13 15:44:37 <mps> heh, I'm using 5.17-rc for more than a month so consider it as stable release :)
2022-03-13 15:45:52 <mps> psykose: you probably noticed that I was busy with asahi testing
2022-03-13 15:45:58 <psykose> mhm :)
2022-03-13 15:46:13 <psykose> much testing
2022-03-13 15:46:25 <mps> too much
2022-03-13 15:47:00 <mps> I will add CGROUP_BPF later at evening
2022-03-13 15:48:49 <psykose> sure thing
2022-03-13 15:48:52 <mps> do we need it also for -edge4virt
2022-03-13 15:49:10 <psykose> if someone wants to run containers on virt, sure
2022-03-13 15:49:36 <psykose> it's already enabled
2022-03-13 15:51:21 <mps> psykose: I see CONFIG_CGROUP_BPF already enabled on x86_64
2022-03-13 15:51:34 <psykose> everywhere except riscv and the regular arm
2022-03-13 15:51:55 <mps> aieee
2022-03-13 15:52:43 <mps> config-edge.aarch64:# CONFIG_CGROUP_BPF is not set
2022-03-13 17:02:34 <mps> psykose: ^
2022-03-13 17:02:38 <psykose> thaanks ~
2022-03-13 17:02:43 <mps> np
2022-03-14 09:17:35 <mps> algitbot: retry 3.13-stable
2022-03-14 18:03:13 <ikke> ^textrels
2022-03-14 18:08:34 <Ariadne> heh
2022-03-14 18:50:28 <ikke> algitbot: retry master
2022-03-15 12:02:07 <psykose> algitbot: retry master
2022-03-15 13:37:29 <mps> algitbot: retry 3.13-stable
2022-03-15 13:37:39 <mps> algitbot: retry 3.12-stable
2022-03-15 13:38:40 <mps> algitbot: retry 3.12-stable
2022-03-15 13:39:16 <ikke> algitbot: retry master
2022-03-15 13:41:33 <mps> algitbot: retry 3.13-stable
2022-03-15 16:30:57 <psykose> algitbot: retry 3.13-stable
2022-03-15 16:43:50 <psykose> algitbot: retry master
2022-03-15 19:43:00 <ikke> algitbot: retry master
2022-03-15 22:31:11 <mps> algitbot: retry 3.12-stable
2022-03-15 22:31:46 <mps> algitbot: retry 3.12-stable
2022-03-15 22:32:43 <mps> algitbot: retry 3.12-stable
2022-03-15 22:35:30 <mps> algitbot: retry 3.12-stable
2022-03-16 17:05:58 <ikke> psykose: I suppse ^ was for fixing #13602?
2022-03-16 17:06:13 <psykose> that's what it says
2022-03-16 17:06:21 <ikke> ah, right
2022-03-16 17:06:47 <psykose> i merely forgot to bump like 3 things that had ffmpeg-dev in depends_dev instead of makedepends, this is the last one
2022-03-16 17:07:13 <psykose> (checked everything else that had -dev in depends_dev now)
2022-03-16 17:08:31 <psykose> actually, two more
2022-03-16 18:56:57 <psykose> algitbot: retry master
2022-03-17 12:29:44 <ikke> algitbot: retry master
2022-03-17 14:46:57 <ikke> algitbot: retry master
2022-03-17 14:49:27 <psykose> algitbot: retry 3.12-stable
2022-03-17 14:49:33 <ikke> d'oh :P
2022-03-17 14:49:35 <ikke> I meant that :D
2022-03-17 14:49:41 <psykose> it was both
2022-03-17 14:49:43 <psykose> 3.13 and 3.12
2022-03-17 14:49:54 <psykose> oh
2022-03-17 14:49:55 <psykose> lol
2022-03-17 14:49:59 <psykose> algitbot: 3.13-stable
2022-03-17 14:50:03 <psykose> algitbot: retry 3.13-stable
2022-03-17 14:50:08 <psykose> one day i will be able to type
2022-03-17 14:50:19 <ikke> you and me both
2022-03-18 05:53:36 <ikke> algitbot: retry master
2022-03-18 05:58:41 <ikke> algitbot: retry master
2022-03-18 06:18:50 <ikke> algitbot: retry master
2022-03-18 12:25:55 <Ariadne> algitbot: retry 3.13-stable
2022-03-18 20:20:10 <psykose> algitbot: retry master
2022-03-19 11:31:29 <psykose> algitbot: ping
2022-03-19 13:12:29 <psykose> algitbot: kick master
2022-03-19 13:12:36 <psykose> algitbot: retry master
2022-03-19 15:35:20 <ikke> algitbot: retry master
2022-03-19 15:47:10 <ikke> algitbot: retry master
2022-03-19 15:52:00 <ikke> algitbot: retry master
2022-03-19 15:56:20 <ikke> algitbot: retry master
2022-03-19 16:10:13 <psykose> algitbot: retry master
2022-03-19 18:45:01 <psykose> algitbot: retry master
2022-03-19 18:57:55 <psykose> algitbot: retry master
2022-03-19 19:29:16 <psykose> algitbot: retry master
2022-03-19 20:00:35 <psykose> algitbot: retry master
2022-03-20 03:14:04 <psykose> algitbot: retry master
2022-03-20 04:06:53 <psykose> algitbot: retry master
2022-03-20 05:02:09 <psykose> algitbot: retry master
2022-03-20 05:11:50 <psykose> algitbot: retry master
2022-03-20 05:19:55 <psykose> algitbot: kick master
2022-03-20 05:20:38 <psykose> algitbot: kick master
2022-03-20 06:09:00 <psykose> algitbot: kick master
2022-03-21 15:40:30 <psykose> fcolista: think you forgot to bump `evolution` in those (duplicate data-server commit)
2022-03-21 15:41:06 <fcolista> psykose, you are right
2022-03-21 15:41:50 <fcolista> just doing right  now...i didn't commit it (and I wonder why...)
2022-03-21 15:42:24 <psykose> it's okay :)
2022-03-21 15:42:33 <psykose> just making sure in case you had forgotten it
2022-03-21 15:42:48 <fcolista> and that was the case :D
2022-03-22 07:45:39 <fcolista> the ppc64le issue for kubernetes appears to be the same mentioned here: https://bugzilla.redhat.com/show_bug.cgi?id=1953551
2022-03-22 07:45:40 <fcolista> https://github.com/golang/go/issues/45850
2022-03-22 07:48:28 <fcolista> and https://github.com/golang/go/issues/45564
2022-03-22 09:30:06 <ikke> fcolista: good find!
2022-03-22 19:40:52 <psykose> algitbot: retry master
2022-03-23 16:57:42 <ikke> algitbot: retry 3.12-stable
2022-03-23 16:57:46 <ikke> algitbot: retry 3.13-stable
2022-03-23 20:40:22 <ikke> algitbot: kick master
2022-03-23 20:40:32 <ikke> algitbot: retry master
2022-03-24 00:06:16 <psykose> algitbot: retry master
2022-03-24 19:05:10 <psykose> algitbot: kick master
2022-03-24 19:05:16 <psykose> algitbot: retry master
2022-03-25 05:57:08 <psykose> algitbot: retry master
2022-03-25 05:59:24 <psykose> E       FileExistsError: [Errno 17] File exists: '/tmp/pytest-of-buildozer/pytest-421/test_install_galaxy_role_no_ch0' -> '/home/buildozer/.ansible/roles/acme.foo'
2022-03-25 05:59:35 <psykose> lmao did this leave some dirty state since the first build
2022-03-25 06:00:24 <ikke> mktemp exists
2022-03-25 06:02:56 <ikke> algitbot: retry master
2022-03-25 06:07:01 <ikke> algitbot: retry master
2022-03-25 06:07:24 <psykose> are you deleting some stuff on one of them
2022-03-25 06:08:23 <psykose> heh, it's the same locally
2022-03-25 06:08:28 <psykose> passes first time, all three fail forever after
2022-03-25 06:08:31 <ikke> I deleted /tmp/pytest-of-buildozer on all of them
2022-03-25 06:08:44 <psykose> i can also just throw in a disable
2022-03-25 06:09:11 <ikke> :-/
2022-03-25 06:10:27 <ikke> i'd say broken tests
2022-03-25 06:10:41 <psykose> think they leave it in the home folder too, the python link there is backwards
2022-03-25 06:10:50 <psykose> https://img.ayaya.dev/nL3gCEPXg6Xz.png
2022-03-25 06:11:10 <psykose> so now you have a nice ~/.ansible filled for you
2022-03-25 06:11:11 <psykose> very nice
2022-03-25 06:11:29 <psykose> algitbot: retry master
2022-03-25 06:12:08 <psykose> and with ansible and tmp deleted they pass again
2022-03-25 06:41:47 <ikke> nope, again stuck :sigh:
2022-03-25 06:45:29 <psykose> wao
2022-03-25 06:45:37 <ikke> ahuh
2022-03-25 06:45:57 <ikke> not sure if it matters, but I explicitly stopped mqtt-exec first, instead of just restarting it (the service)
2022-03-25 06:46:39 <psykose> a restart should probably load the new binary off disk..
2022-03-25 06:47:03 <psykose> maybe openrc restart does something special? but afaik it does actually restart, as i use restart for service upgrades and they come up to new version
2022-03-25 06:50:49 <ikke> honestly I would not expect a difference
2022-03-25 06:53:41 <psykose> me either
2022-03-25 14:28:20 <ikke> fatal error: linux/random.h: No such file or directory
2022-03-25 14:30:51 <ikke> ncopa: ^
2022-03-25 14:38:40 <ncopa> 
ACTION slaps himself with rootbld

2022-03-26 19:29:08 <psykose> algitbot: kick master
2022-03-26 19:29:15 <psykose> algitbot: retry master
2022-03-27 04:17:03 <psykose> algitbot: kick master
2022-03-27 04:17:09 <psykose> algitbot: retry master
2022-03-27 10:42:21 <psykose> algitbot: retry master
2022-03-29 11:09:59 <ikke> ncopa: I suppose we should add that to the release notes for 3.16?
2022-03-29 11:15:08 <ncopa> ikke: yes, I think that is a good idea
2022-03-30 09:08:18 <ikke> ncopa: ^ something something rootbld?
2022-03-30 09:08:35 <ikke> hmm, gpm-dev is missing
2022-03-30 09:08:54 <ikke> It's in testing
2022-03-30 09:09:50 <ncopa> hum
2022-03-30 09:09:51 <ncopa> ok