2022-06-02 10:13:55 <psykose> algitbot: retry master
2022-06-02 13:29:25 <psykose> algitbot: retry master
2022-06-03 15:02:29 <fcolista> umh...
2022-06-03 16:17:53 <psykose> algitbot: retry master
2022-06-03 21:32:36 <psykose> algitbot: retry 3.16-stable
2022-06-04 11:48:30 <andypost[m]> algitbot: kick master
2022-06-04 12:47:20 <andypost[m]> algitbot: kick master
2022-06-07 19:56:05 <ikke> algitbot: retry master
2022-06-07 19:58:05 <psykose> algitbot: retry master
2022-06-07 20:35:51 <psykose> algitbot: kick master
2022-06-07 20:35:59 <psykose> algitbot: retry master
2022-06-07 22:48:05 <psykose> algitbot: retry master
2022-06-07 23:11:33 <psykose> algitbot: kick master
2022-06-07 23:11:41 <psykose> algitbot: retry master
2022-06-08 09:34:12 <psykose> algitbot: retry master
2022-06-08 09:41:56 <psykose> algitbot: retry master
2022-06-08 09:53:59 <psykose> ikke: could you look at that one above
2022-06-08 10:20:53 <ikke> psykose: what's up?
2022-06-08 10:21:00 <psykose> the apparmor test
2022-06-08 10:21:04 <psykose> on armv7
2022-06-08 10:21:10 <psykose> it passes on the others so it looks strange
2022-06-08 10:21:12 <psykose> not sure why it fails
2022-06-08 10:23:28 <ikke> so one failure is 10 apparmor denials versus 20?
2022-06-08 10:23:42 <psykose> seems to be
2022-06-08 10:25:22 <psykose> the other one compares like 1k chars
2022-06-08 10:25:45 <ikke> those are fun
2022-06-08 10:25:50 <ikke> oh, only 2 tests
2022-06-08 10:25:58 <ikke> but they are testing a bazillion thingsd
2022-06-08 10:26:16 <psykose> ah, it's also 10/20
2022-06-08 10:26:21 <rbq> Don't know if this is worth mentioning: I think our test-aa-notify patch is from https://gitlab.com/apparmor/apparmor/-/issues/220 , but the merge request that closes that issue is https://gitlab.com/apparmor/apparmor/-/merge_requests/848 which does things a little bit differently
2022-06-08 10:27:11 <psykose> that's related to some help output, i don't see why it would affect the 10/20 difference
2022-06-08 10:27:17 <psykose> well
2022-06-08 10:27:22 <psykose> the 'less strict' might make that pass too
2022-06-08 10:47:08 <psykose> algitbot: retry master
2022-06-08 10:47:20 <psykose> alas it was unrelated
2022-06-08 10:48:15 <psykose> algitbot: kick master
2022-06-08 10:48:19 <psykose> algitbot: retry master
2022-06-08 10:48:26 <psykose> algitbot: retry master
2022-06-08 11:20:46 <rbq> Ok, I ran `python3 test-aa-notify.py -v` to get verbose output, and the 2 tests that failed on armv7 (test_entries_since_login and test_entries_since_login_verbose) are actually skipped with the reason "Requires wtmp on system"
2022-06-08 11:23:04 <rbq> So, probably the question to ask is why test-aa-notify.py finds a /var/log/wtmp on the armv7 builder and doesn't skip the tests
2022-06-08 11:24:19 <psykose> it means something else just put it there ever once upon a time
2022-06-08 11:24:22 <psykose> it doesn't get cleaned or anything
2022-06-08 11:24:28 <psykose> sadly the builds are not clean chroots
2022-06-08 11:26:29 <PureTryOut> can't wait for the day it runs rootbld
2022-06-08 11:27:17 <psykose> if it didn't instantly start with the 'no network' requirement we could have probably deployed it ages ago and went from there
2022-06-08 11:27:37 <PureTryOut> We can fix the broken APKBUILDs with that easily though
2022-06-08 11:27:47 <psykose> yes, but so far it's been 90% of the bikeshed
2022-06-08 11:27:57 <psykose> we could have just.. not, and fixed it after, and it would be a nice improvement
2022-06-08 11:28:02 <PureTryOut> just add `options="net"` everywhere, at least then it's clear where the network is used as well and we can slowly get rid of it over time
2022-06-08 11:28:20 <psykose> there's also xvfb-run tests and the like, but yeah, you fix them one by one
2022-06-08 11:28:29 <PureTryOut> Yeah I'm saying start rootbld'ing everything first, fix issues when they come up. 3.16 is out so no release to care about atm
2022-06-08 11:28:41 <psykose> my thoughts too, best time to break everything
2022-06-08 11:28:50 <psykose> but everyone takes a vacation after release :)
2022-06-08 11:29:26 <rbq> I already know 2 aports that will be needing options="net"
2022-06-08 11:29:34 <PureTryOut> well then go add them!
2022-06-08 11:29:43 <PureTryOut> I always add it where I find it
2022-06-08 11:29:51 <PureTryOut> I've already done tons of packages over time
2022-06-08 11:30:18 <psykose> everywhere i've wanted to add it was either prepare() fetch (which is planned to be allowed but not implemented..) or go stuff (which we probably need to fix anyway..)
2022-06-08 11:30:20 <psykose> which is quite ech
2022-06-08 11:30:23 <psykose> aside from that, yeah
2022-06-08 11:30:59 <rbq> Just checking, options="net" is needed for check() too, right?
2022-06-08 11:31:13 <rbq> I mean, if the network access is done in check()
2022-06-08 11:31:25 <psykose> depends on what you want
2022-06-08 11:31:28 <psykose> sometimes yes, sometimes no
2022-06-08 11:31:37 <PureTryOut> yeah it's needed for check if tests require network access
2022-06-08 11:31:51 <psykose> sometimes the checks are really stupid so you just skip it, or skip those, etc
2022-06-08 11:31:51 <psykose> shrug
2022-06-08 11:31:54 <PureTryOut> in some cases only the tests require net, I'd love it to enable it just for that phase
2022-06-08 11:32:38 <rbq> I'm quite certain this check isn't skipped...because I put it in there, to make sure this particular aport is compatible with Busybox's wget
2022-06-08 11:34:39 <PureTryOut> Most of the time I skip tests if they require network access but sometimes you can't sadly
2022-06-08 11:41:15 <psykose> ikke: ^ seems it was /var/log/wtmp
2022-06-08 11:43:50 <ikke> apparmor? 
2022-06-08 11:47:09 <psykose> yeah
2022-06-08 11:47:50 <psykose> rbq: though, funnily, i have that file and didn't skip the tests and they also passed for me
2022-06-08 11:56:15 <rbq> How many tests are skipped? (3 for me)
2022-06-08 11:56:34 <psykose> lost the logs
2022-06-08 11:57:19 <rbq> I just created an empty /var/log/wtmp
2022-06-08 11:57:43 <rbq> and the tests are still skipped, for a different reason: "Could not find last login"
2022-06-08 11:58:12 <psykose> ah, that means not only is it there but it's not empty
2022-06-08 11:58:27 <psykose> and has some valid date
2022-06-08 11:58:31 <psykose> data
2022-06-08 11:58:35 <psykose> or whatever
2022-06-08 11:58:44 <rbq> Well, the 2 tests that are failing on armv7 (due to /var/log/wtmp) are skipped with that reason, the 3rd is skipped due to "Requires kern.log on system"
2022-06-08 11:59:09 <rbq> But I saw that there was 1 test skipped on armv7, so I assume that's the kern.log one
2022-06-08 12:03:54 <rbq> If I'm reading the Python right, it's running `aa-notify -f /var/log/wtmp -l` for test_entries_since_login and for test_entries_since_login_verbose an additional "-v" is added
2022-06-08 12:05:33 <rbq> So, the output with "20" instead of "10" is very likely generated by the aa-notify command
2022-06-08 12:05:58 <rbq> and that causes the tests to fail
2022-06-08 12:33:46 <rbq> As expected, I was not reading the Python properly, it is not running aa-notify on /var/log/wtmp, but on the test files, it's just that the tests are skipped if (1) wtmp is not found (2) wtmp exists, but get_last_login_timestamp(username) returns 0
2022-06-08 12:35:50 <rbq> and get_last_login_timestamp is from the apparmor.notify module
2022-06-08 12:38:11 <rbq> I created an empty /var/log/wtmp, and faked the value of get_last_login_timestamp, and now the tests are failing for me as well
2022-06-08 12:54:15 <rbq> Ok, whatever
2022-06-08 12:55:53 <rbq> Look at the timestamp of the build log, it says some time on 15 April 2022, I'm now faking values of get_last_login_timestamp (in Unix time)...and if it's past a certain value, the test fails (at least that's what I can conclude now)
2022-06-08 12:56:21 <rbq> I mean, the timestamp of the part where it says "AppArmor denials"
2022-06-08 13:05:55 <rbq> If the time since last login is more than 30 days, then the tests will fail
2022-06-08 13:10:53 <psykose> should just delete the log
2022-06-08 13:15:03 <rbq> Probably :)
2022-06-08 13:18:07 <psykose> iiikkeeeee
2022-06-08 13:26:08 <rbq> Alright, I roughly understand what's going on...each test log file is 33 lines long consisting of 10 lines that have the current timestamp, 10 lines that have are 30 days in the past, 10 lines that are 999 days in the past, and 3 "unrelevant entries"
2022-06-08 13:26:50 <rbq> So, that's where "10 denials" comes from
2022-06-08 13:27:14 <rbq> and if the last login time is over 30 days, then another 10 lines get added, and you get "20 denials"
2022-06-08 13:27:27 <rbq> s/get added/fit the criteria/
2022-06-08 13:27:45 <rbq> 
ACTION is speechless

2022-06-09 00:42:13 <Ariadne> charming
2022-06-09 00:51:29 <Ariadne> all of this because openwrt people don't know how to use SONAMEs smh
2022-06-09 06:20:16 <psykose> algitbot: kick master
2022-06-09 06:20:23 <psykose> algitbot: retry master
2022-06-10 09:06:25 <PureTryOut> algitbot: retry master
2022-06-10 09:21:59 <psykose> algitbot: retry master
2022-06-10 09:27:51 <psykose> algitbot: retry master
2022-06-10 10:26:35 <andypost[m]> algitbot: retry master
2022-06-10 10:42:46 <andypost[m]> algitbot: retry master
2022-06-10 11:28:09 <PureTryOut> algitbot: retry master
2022-06-10 11:37:53 <PureTryOut> algitbot: retry master
2022-06-10 11:38:09 <PureTryOut> algitbot: retry 3.16
2022-06-10 11:38:14 <PureTryOut> * retry 3.16-stable
2022-06-10 11:38:21 <PureTryOut> algitbot: retry 3.16-stable
2022-06-10 12:03:01 <PureTryOut> algitbot: retry master
2022-06-10 12:12:15 <andypost[m]> algitbot: retry master
2022-06-10 12:18:23 <andypost[m]> algitbot: retry master
2022-06-10 12:40:50 <andypost[m]> algitbot: retry master
2022-06-10 13:23:46 <PureTryOut> algitbot: retry master
2022-06-10 13:56:33 <psykose> algitbot: retry master
2022-06-10 14:51:46 <psykose> algitbot: retry master
2022-06-10 15:42:50 <psykose> algitbot: retry master
2022-06-10 16:29:07 <psykose> algitbot: retry master
2022-06-10 19:32:22 <psykose> ikke: you left the echo in there :)
2022-06-10 19:32:40 <ikke> ouch
2022-06-11 00:16:23 <rbq> Hmm, are tests disabled by default for riscv64?
2022-06-11 00:20:06 <rbq> perl-ldap failing on riscv64 seems to be due to perl-text-soundex not being installed, it is listed as checkdepends...probably that is wrong, and it should be depends instead
2022-06-11 05:25:45 <andypost[m]> algitbot: retry master
2022-06-11 06:14:43 <ikke> rbq: yes, they are
2022-06-11 06:15:24 <ikke> rbq: ABUILD_BOOTSTRAP is set on riscv64, which results in checks not being run
2022-06-11 06:23:38 <ikke> rbq: hmm, it seems to have fixed itself?
2022-06-11 06:39:53 <ikke> algitbot: retry master
2022-06-11 07:53:59 <rbq> I'll try to have a look at whether perl-ldap is usable without perl-text-soundex as depends later on, however, I don't use ldap, so I don't know how well my judgment is in this area...perhaps perl-ldap's maintainer should be notified about this?
2022-06-11 07:55:16 <rbq> Looking at the build logs, perl-ldap's install script is still trying to install Text::Soundex by itself...it's just that it no longer causes the whole build to fail
2022-06-11 07:55:44 <rbq> s/well/good/
2022-06-11 08:29:20 <rbq> Judging from how Text::Soundex is loaded, it doesn't seem to be a hard requirement...
2022-06-11 08:40:26 <rbq> and perl-ldap's APKBUILD contains comments on how confusing all this is (make installs soundex to usr/local, and make check removes it)...oh well, I guess nothing much can be done about it
2022-06-11 13:39:13 <psykose> ikke: seems busybox is stuck
2022-06-11 13:42:09 <psykose> algitbot: retry master
2022-06-11 13:47:31 <ikke> That never happened before
2022-06-11 13:53:51 <psykose> not once!
2022-06-11 14:13:40 <andypost[m]> Yep, all builders stuck on it for ~10 hours
2022-06-11 14:15:11 <psykose> i picked a real good time to go to bed then :)
2022-06-11 14:18:36 <rbq> I was wondering why r1 of perl-ldap only appeared on riscv64...now I know what happened
2022-06-11 14:24:14 <ikke> So, what are we going to do about it?
2022-06-11 14:24:25 <ikke> It's anoying that it happens every time
2022-06-11 14:24:48 <ikke> (symptom: SIGPIPE gets ignored)
2022-06-11 14:27:29 <ikke> algitbot: retry master
2022-06-11 14:28:56 <rbq> It seems s390x and riscv64 were not affected?
2022-06-11 14:29:06 <ikke> correct
2022-06-11 14:29:47 <ikke> We did notice in the past that mqtt-exec, through use of mosqtuitto, did ignore SIGPIPE, which children inherited
2022-06-11 14:29:51 <ikke> that was fixed
2022-06-11 14:29:57 <ikke> But it still happens
2022-06-11 15:19:16 <ikke> psykose: the grub issue might also be a gcc bug: project/submodule/.git/
2022-06-11 15:19:27 <ikke> http://dup.pw/alpine/aports/e827b100297b
2022-06-11 15:19:36 <ikke> sorry, a cannot compute today
2022-06-11 15:19:39 <ikke> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853
2022-06-11 15:20:24 <psykose> ah, maybe, though it's the same thing as before for u-boot
2022-06-11 15:21:50 <psykose> algitbot: retry master
2022-06-11 15:23:42 <psykose> also looks like bb is stuck again anyway, hehe
2022-06-11 15:23:58 <ikke> And it will be stuck until we fix it
2022-06-11 15:28:19 <psykose> if by fix it you mean restart it ~2 more times until the next month :p
2022-06-11 15:29:12 <ikke> It's not random
2022-06-11 15:30:04 <psykose> it has been so far, though
2022-06-11 15:36:30 <ikke> So right now on x86_64, I see buildrepo (and all children) ignoring SigPipe
2022-06-11 15:36:49 <ikke> So no matter how often I kill the build, it will keep stuck, unless I kill buildrepo as well
2022-06-11 15:37:55 <ikke> So something is triggering sigpipe being ignored in buildrepo
2022-06-11 15:43:06 <psykose> yeah, but what i mean is we've been in this state before
2022-06-11 15:43:20 <psykose> and then after 2 hours of debugging it, you randomly kill it and the sigign is gone and it passes
2022-06-11 15:43:36 <psykose> we've been through this rodeo like 4 times since after the original sigign fix
2022-06-11 15:43:43 <ikke> I can just restart mqtt-exec and it will probably go through
2022-06-11 15:43:46 <psykose> mhm
2022-06-11 15:44:10 <ikke> In that sense, it's not random
2022-06-11 15:44:26 <ikke> It will fail until it's reset
2022-06-11 15:45:01 <ikke> Something that nmeum was thinking of last time is if buildrepo through some mechanism uses mosquitto
2022-06-11 15:45:11 <ikke> which is what caused the issue in mqtt-exec
2022-06-11 15:46:40 <psykose> mhm
2022-06-11 15:46:59 <nmeum> what's the process hierarchy again?
2022-06-11 15:47:02 <nmeum> I keep on forgetting
2022-06-11 15:47:32 <nmeum> maybe we should open an issue on gitlab somewhere to collect this sort of information about this bug
2022-06-11 15:56:56 <nmeum> so, aports-build has a dependency on lua5.2-mqtt-publish which in turn uses mosquitto (which will ignore sigpipe) but how this relates to the process hierarchy spawned by the builder
2022-06-11 15:57:06 <nmeum> s/but/but not sure/
2022-06-11 16:07:04 <ikke> nmeum: https://tpaste.us/gZp6
2022-06-11 16:07:55 <ikke> build-edge-x86_64 [~]# sign 61417
2022-06-11 16:07:57 <ikke> SigIgn: 0000000000000004
2022-06-11 16:08:48 <ikke> build-edge-x86_64 [~]# sign 61545
2022-06-11 16:08:50 <ikke> SigIgn: 0000000000001006
2022-06-11 16:10:22 <nmeum> I created https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10758 to collect more info
2022-06-11 16:12:56 <nmeum> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/aports-build/report-build-errors.lua
2022-06-11 16:12:59 <nmeum> how is this invoked?
2022-06-11 16:13:13 <nmeum> > publish.single(topic, payload, nil, true, conf.mqttbroker)
2022-06-11 16:14:04 <nmeum> ^ this line might ignore sigpipe depending on how lua5.2-mqtt-publish works (haven't looked that up yet)
2022-06-11 16:14:39 <ikke> usr/share/buildrepo/plugins/report-build-errors.lua
2022-06-11 16:15:21 <nmeum> is this called from aports-build or how does this work?
2022-06-11 16:15:21 <ikke> nmeum: it's a drop-in plugin for buildrepo
2022-06-11 16:15:43 <nmeum> ah
2022-06-11 16:15:45 <ikke> nmeum: https://gitlab.alpinelinux.org/alpine/lua-aports/-/blob/master/bin/buildrepo.lua#L38
2022-06-11 16:16:22 <nmeum> ok, but the postbuild function is run in the same process that later forks() to execute abuild -r?
2022-06-11 16:16:39 <ikke> I think so, buildrepo is just a single process
2022-06-11 16:17:11 <ikke> (btw, this also answers a question I had, as the plugin used to be placed in /etc/buildrepo/plugins, but apparently is not necessary anymore)
2022-06-11 16:17:12 <nmeum> because in this case what might be happening is: (a) a build fails (b) postbuild is run (c) postbuild runs publish.single from report-build-errors.lua (d) publish.single ignores SIGPIPE (e) the next build executed by buildrepo runs with SIGPIPE ignored
2022-06-11 16:17:27 <ikke> Sounds plausible
2022-06-11 16:17:27 <nmeum> which could also explain why it doesn't happen when you restart mqtt-exec
2022-06-11 16:19:13 <ikke> Why is it a good idea that invoking some mosquitto function can cause the process to ignore sigpipe
2022-06-11 16:19:56 <nmeum> well, yeah that's why it is not a good idea to modify the signal ignore mask in a library
2022-06-11 16:20:02 <ikke> nod
2022-06-11 16:20:39 <nmeum> I mean we could complain to the mosquitto folks about this but I doubt that they will listen ':D
2022-06-11 16:21:17 <nmeum> we could also restore the default sigpipe signal handler in the lua wrapper for mosquitto https://github.com/flukso/lua-mosquitto/blob/master/lua-mosquitto.c#L287-L300
2022-06-11 16:21:27 <nmeum> but not sure when ctx_destroy is invoked actually
2022-06-11 16:21:33 <ikke> nmeum: We can at least try :)
2022-06-11 16:22:02 <nmeum> do we have a testbed were we can easily reproduce this to see what changes fix the issue?
2022-06-11 16:22:28 <nmeum> so testbed should be: build fails -> afterwards sigpipe is in SigIgn
2022-06-11 16:22:50 <nmeum> build successeds -> report-build-errors.lua is not invoked and sigpipe should not be in sigign
2022-06-11 16:23:38 <ikke> We can setup a dummy builder somewhere
2022-06-11 16:25:21 <nmeum> if that's not a lot of work that might be an idea
2022-06-11 16:25:31 <ikke> :D
2022-06-11 16:26:39 <nmeum> I mean if it is difficult to setup a dummy builder then we might as well just patch lua-mosquitto
2022-06-11 16:27:02 <nmeum> we can also add a dependency on luaposix to aports-build and reset the default SIGPIPE handler from there
2022-06-11 16:28:10 <ikke> nmeum: so the idea is to setup a builder that fails building a package, we then fix it, and then try to build something that would invoke something like yes 'foo bar' | head -n10, right?
2022-06-11 16:28:37 <nmeum> basically yes
2022-06-11 16:28:45 <ikke> Should be doable
2022-06-11 16:28:50 <nmeum> but I am like 70% sure that my assesment of the issue is correct
2022-06-11 16:29:03 <ikke> To me, it at least sounds plausible
2022-06-11 16:29:21 <nmeum> so if no new buildrepo process is spawned after a build failure then the problem really is report-build-errors.lua
2022-06-11 16:29:50 <nmeum> I think I can also just do some tests with lua-mosquitto directly without setting up a dummy builder
2022-06-11 16:30:01 <ikke> ok
2022-06-11 16:30:47 <ikke> On an idle builder, there is no buildrepo process
2022-06-11 16:31:03 <ikke> So as soon as all packages have been built, everything stops except mqtt-exec
2022-06-11 16:31:17 <nmeum> but if 5 new packages are pushed these are all build by the same buildrepo process?
2022-06-11 16:31:31 <ikke> yes, and I think even new packages pushed afterwards
2022-06-11 16:31:35 <nmeum> so if package 3 fails to build package 4 will be invoked with an ignored sigpipe
2022-06-11 16:31:39 <ikke> yes
2022-06-11 16:31:47 <ikke> hmm
2022-06-11 16:32:16 <ikke> If a package fails, I think buildrepo stops
2022-06-11 16:32:20 <ikke> (unless -k is provided)
2022-06-11 16:33:19 <ikke> hmm
2022-06-11 16:33:30 <ikke> Now only mqtt-exec is left
2022-06-11 16:33:43 <ikke> algitbot: retry master
2022-06-11 16:34:57 <ikke> nmeum: after retrying, immediately buildrepo is ignoring sigpipe
2022-06-11 16:35:09 <nmeum> hm, maybe that's not it then
2022-06-11 16:35:13 <ikke> https://tpaste.us/k6Y6 
2022-06-11 16:35:19 <nmeum> did mqtt-exec spawn a new buildrepo instance?
2022-06-11 16:35:33 <ikke> yes, compare the pids
2022-06-11 16:37:35 <nmeum> buildrepo is the first process with sigpipe ignored though, right?
2022-06-11 16:38:12 <nmeum> so I strongly suspect that it called some mosquitto mqtt function (maybe that can be checked somehow by setting a breakpoint in buildrepo, I don't know how one debugs lua code)
2022-06-11 16:38:38 <ikke> nmeum: the builder does publish to build.a.o
2022-06-11 16:38:43 <ikke> so maybe that is causing it?
2022-06-11 16:38:56 <ikke> though, it would not explain why restart mqtt-exec would fix it
2022-06-11 16:41:44 <nmeum> we can also just patch mosquitto to never ignore SIGPIPE and be done with it 😈
2022-06-11 16:42:01 <ikke> Totally fine with me 🤐
2022-06-11 16:42:39 <ikke> It should be the service that determined whether to ignore it
2022-06-11 16:42:48 <ikke> determines*
2022-06-11 16:44:05 <nmeum> probably not a good idea though as doing that will also affect other applications using mosquitto
2022-06-11 16:55:04 <nmeum> ikke: I opened an issue upstream https://github.com/eclipse/mosquitto/issues/2564
2022-06-11 17:00:49 <nmeum> let's hope the 3.16 builder doesn't get stuck too :S
2022-06-11 20:28:33 <andypost[m]> algitbot: retry master
2022-06-14 04:57:57 <psykose> algitbot: kick master
2022-06-14 10:30:58 <ikke> algitbot: retry master
2022-06-14 10:31:04 <ikke> algitbot: retry 3.16-stable
2022-06-14 10:31:06 <ikke> algitbot: retry 3.15-stable
2022-06-15 05:57:34 <psykose> algitbot: retry master
2022-06-15 07:18:28 <psykose> algitbot: retry master
2022-06-15 14:34:06 <psykose> algitbot: retry master
2022-06-16 02:04:32 <rbq> What a coincidence, the test/ssl/peer_certificate.pem included in libtorrent-rasterbar expired 4 days ago
2022-06-16 02:13:06 <rbq> ...and the certificates have been rebuilt upstream: https://github.com/arvidn/libtorrent/pull/6925
2022-06-16 07:24:02 <ikke> rbq: pushed ^
2022-06-16 09:36:48 <PureTryOut> algitbot: retry master
2022-06-16 09:41:26 <mps> nmeum: thank you
2022-06-16 09:42:05 <nmeum> why was this backported?
2022-06-16 09:42:12 <nmeum> mps: for what? :D
2022-06-16 09:45:27 <mps> nmeum: I thought you backported but later saw that was ncopa 
2022-06-16 09:45:42 <nmeum> why does it need to be backported though?
2022-06-16 09:46:46 <mps> nmeum: when I upgrade linux-edge in edge I usually (always)  just cherry-pick it to latest stable
2022-06-16 09:47:30 <mps> without this backport I will have always to make change manually
2022-06-16 09:48:01 <nmeum> ah
2022-06-16 10:09:33 <PureTryOut> algitbot: retry master
2022-06-16 21:50:06 <andypost[m]> algitbot: retry master
2022-06-17 09:36:34 <ikke> algitbot: retry master
2022-06-17 10:23:58 <ikke> algitbot: retry master
2022-06-17 10:32:04 <ikke> algitbot: retry master
2022-06-17 10:42:04 <ikke> algitbot: retry master
2022-06-17 10:51:17 <ikke> algitbot: retry master
2022-06-17 11:57:54 <psykose> algitbot: retry master
2022-06-17 15:37:15 <psykose> algitbot: retry master
2022-06-19 07:24:55 <psykose> algitbot: retry master
2022-06-20 16:47:23 <psykose> algitbot: retry master
2022-06-20 16:54:43 <psykose>  algitbot retry master
2022-06-20 16:54:48 <psykose> algitbot: retry master
2022-06-21 06:50:02 <rnalrd> ikke, msg.alpinelinux.org outage?
2022-06-21 07:02:50 <fcolista> umh, seems also gitlab.a.o is down
2022-06-21 07:05:07 <fcolista> ah...it seems a dns issue
2022-06-21 07:05:15 <rnalrd> works here
2022-06-21 07:05:31 <fcolista> it's cached then
2022-06-21 07:06:41 <rnalrd> it resolves from non cached hosts
2022-06-21 07:07:06 <fcolista> To me fails from 8.8.8.8but works from 208.67.220.220
2022-06-21 07:07:27 <rnalrd> no problem from 8.8.4.4
2022-06-21 07:07:48 <fcolista> https://tpaste.us/endX 
2022-06-21 07:08:12 <rnalrd> frmo my local 8.8.4.4, could be a local google server issue
2022-06-21 07:09:06 <fcolista> must have been a glitch on google dns
2022-06-21 07:09:07 <fcolista> https://tpaste.us/k6vw 
2022-06-21 07:09:13 <fcolista> now works
2022-06-21 07:09:39 <psykose> probably related to the current cloudflare outage, given the timing..
2022-06-21 07:09:49 <psykose> or just a hell of a coincidence :p
2022-06-21 07:11:15 <fcolista> https://tpaste.us/OqBX 
2022-06-21 07:11:16 <fcolista> umh...
2022-06-21 07:17:17 <rnalrd> anyway msg.a.o does not work
2022-06-22 10:46:14 <ikke> ncopa: fyi, the [pwd] in the script section is just because it's required to have a script section in gitlab (for now).
2022-06-22 10:47:25 <ncopa> oh, ok. so its not executed?
2022-06-22 10:48:47 <ikke> ncopa: the image sets an entrypoint
2022-06-22 10:48:49 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/abuild-ci/-/blob/master/overlay/entrypoint
2022-06-22 10:49:58 <ikke> maybe better to get rid of that
2022-06-22 10:50:27 <ikke> or at least, forward "$@" to sh
2022-06-22 10:55:54 <ncopa> im not able to reproduce the failure locally
2022-06-22 10:57:02 <ncopa> i suspect it has to do with permissions or similar. what user checks out the git tree?
2022-06-22 10:58:50 <ikke> ncopa: I believe root
2022-06-22 10:59:32 <ikke> ncopa: git config --global safe.directory *
2022-06-22 11:11:17 <ncopa> no the problem was my cp .abuild .
2022-06-22 11:18:12 <ikke> Ah
2022-06-22 11:18:40 <ncopa> slightly annoyed that kyua didn't print what was on stderr
2022-06-22 15:20:27 <andypost[m]> algitbot: retry master
2022-06-22 17:03:48 <psykose> algitbot: retry master
2022-06-22 21:42:56 <psykose> algitbot: retry master
2022-06-24 16:15:15 <psykose> algitbot: retry master
2022-06-27 19:31:18 <ikke> algitbot: retry master
2022-06-28 06:49:43 <psykose> algitbot: kick master
2022-06-28 06:49:51 <psykose> algitbot: retry master
2022-06-28 16:12:35 <psykose> algitbot: retry master
2022-06-28 16:28:30 <psykose> algitbot: retry master
2022-06-28 16:35:31 <psykose> algitbot: retry master
2022-06-28 16:39:33 <psykose> algitbot: retry master
2022-06-28 16:44:24 <psykose> algitbot: retry master
2022-06-28 16:45:55 <psykose> algitbot: retry master
2022-06-28 19:32:52 <ikke> algitbot: retry master
2022-06-30 05:17:57 <psykose> algitbot: kick master