2019-10-01 10:51:04 <ncopa> algitbot: retry master
2019-10-01 11:05:03 <ncopa> that mesa failure on ppc64le smells like a parallel build issue
2019-10-02 07:04:24 <clandmeter> should stop now
2019-10-02 07:18:49 <clandmeter> algitbot: retry 3.9-stable
2019-10-02 07:22:21 <clandmeter> algitbot: retry 3.9-stable
2019-10-02 07:28:11 <clandmeter> algitbot: retry 3.9-stable
2019-10-02 07:30:52 <clandmeter> _ikke_: i think we have an issue with mqtt
2019-10-02 07:31:38 <clandmeter> lxc also acting strange
2019-10-02 07:32:35 <clandmeter> ncopa: ping
2019-10-02 07:38:51 <clandmeter> algitbot: retry 3.9-stable
2019-10-02 07:40:50 <clandmeter> algitbot: retry 3.9-stable
2019-10-02 07:59:16 <ncopa> pong
2019-10-02 07:59:19 <ncopa> morning
2019-10-02 07:59:33 <clandmeter> hi
2019-10-02 07:59:57 <clandmeter> ncopa: after rebooting armv7 server it causes issues with builders
2019-10-02 08:00:27 <clandmeter> one was in some loop and kept spamming mqtt
2019-10-02 08:00:35 <ncopa> ok
2019-10-02 08:00:40 <ncopa> i have seen that before
2019-10-02 08:00:49 <ncopa> not sure why it happens
2019-10-02 08:00:55 <clandmeter> I restarted 2 of them
2019-10-02 08:01:04 <ncopa> but just stop mqtt-exec and start it again normally helps
2019-10-02 08:01:04 <clandmeter> but now some packages dont want to get build
2019-10-02 08:01:11 <ncopa> on arm?
2019-10-02 08:01:14 <ncopa> or on others?
2019-10-02 08:01:21 <ncopa> looks like 3-10 builders hangs on python
2019-10-02 08:01:29 <clandmeter> arm
2019-10-02 08:01:30 <clandmeter> build-3-9-armv7
2019-10-02 08:01:38 <clandmeter> it doesnt want to build exim
2019-10-02 08:01:45 <clandmeter> and its not yet build
2019-10-02 08:03:36 <ncopa> i'll have a look
2019-10-02 08:03:54 <clandmeter> i upgraded usa4 yesterday
2019-10-02 08:04:11 <clandmeter> and i played with qemu on aarch64
2019-10-02 08:04:17 <clandmeter> but its a bit...
2019-10-02 08:04:43 <clandmeter> im not sure its smart to run docker in qemu on other arches 
2019-10-02 08:08:37 <clandmeter> what did you do?
2019-10-02 08:10:24 <ncopa> i logged into build-3-9-armv7, had a look at the running processes and installed packages
2019-10-02 08:10:27 <ncopa> uninstalled vim
2019-10-02 08:10:31 <ncopa> and rebooted
2019-10-02 08:10:42 <clandmeter> i only installed vim 2 min ago
2019-10-02 08:10:47 <ncopa> ha!
2019-10-02 08:11:00 <clandmeter> ok maybe 10
2019-10-02 08:11:03 <clandmeter> :p
2019-10-02 08:11:04 <ncopa> Could not resolve host: hostap.epitest.fi
2019-10-02 08:11:13 <ncopa> looks like dns may be broke?
2019-10-02 08:11:17 <clandmeter> i did not reboot the container again
2019-10-02 08:11:45 <clandmeter> i dont know
2019-10-02 08:12:29 <clandmeter> nah its aslso broke for me
2019-10-02 08:12:38 <clandmeter> ERR_NAME_NOT_RESOLVED
2019-10-02 08:12:51 <ncopa> so its broken by upstream
2019-10-02 08:13:01 <clandmeter> so you did nothing except just reboot build-3-9-armv7
2019-10-02 08:13:10 <ncopa> correct
2019-10-02 08:13:21 <clandmeter> no problem analysis 
2019-10-02 08:13:25 <ncopa> well, i first checked if it was "safe" to do so
2019-10-02 08:13:39 <ncopa> the mqtt-exec service was stopped
2019-10-02 08:13:45 <ncopa> nothing was running
2019-10-02 08:13:53 <clandmeter> yes i was playing with it
2019-10-02 08:14:00 <clandmeter> to enable logging
2019-10-02 08:14:09 <clandmeter> i think we should turn that on anyways
2019-10-02 08:14:25 <ncopa> ok
2019-10-02 08:15:47 <ncopa> i have seen mqtt-exec go into some strange loop when host reboots
2019-10-02 08:16:06 <ncopa> i have never taken the time to analyze what is actually going on
2019-10-02 08:16:13 <clandmeter> maybe thats when it previously crashed
2019-10-02 08:16:16 <clandmeter> but not it will be restarted
2019-10-02 08:16:25 <clandmeter> s/not/now
2019-10-02 08:16:48 <ncopa> it smells like some bug or race or something in mosquitto
2019-10-02 08:17:02 <clandmeter> maybe its actually restarting all the time?
2019-10-02 08:17:09 <clandmeter> didnt check
2019-10-02 08:17:17 <ncopa> no, i dont think so
2019-10-02 08:17:47 <ncopa> and i think it happens when there are two mqtt clients on same host starting at the same time or similar
2019-10-02 08:18:14 <clandmeter> heh it actually still works? 
2019-10-02 08:18:20 <clandmeter> i was in the middle to edit the init.d
2019-10-02 08:18:23 <clandmeter> it has leftovers
2019-10-02 08:18:54 <ncopa> sorry, i didnt know you were analyzing it
2019-10-02 08:21:39 <clandmeter> ncopa: any comment regarding qemu?
2019-10-02 08:22:16 <ncopa> <@clandmeter> but its a bit...
2019-10-02 08:22:27 <ncopa> what is it a bit? compliated?
2019-10-02 08:22:35 <clandmeter> limited
2019-10-02 08:22:39 <clandmeter> and more complicated for sure
2019-10-02 08:22:41 <ncopa> how is it set up?
2019-10-02 08:22:53 <clandmeter> undocumented also
2019-10-02 08:23:17 <ncopa> you create a vm where you run docker?
2019-10-02 08:23:52 <clandmeter> i didnt even run docker yet
2019-10-02 08:24:04 <clandmeter> qemu on arm works different
2019-10-02 08:24:07 <clandmeter> had to do some digging
2019-10-02 08:24:13 <clandmeter> so i ended up doing:
2019-10-02 08:24:16 <clandmeter> qemu-system-aarch64 -m 32G -machine virt,gic-version=3 -enable-kvm -cpu host -smp cores=64 -nographic -nic user,model=virtio -drive format=raw,file=/dev/sdb -bios ./QEMU_EFI.fd -device virtio-rng-pci -device virtio-gpu-pci
2019-10-02 08:24:36 <ncopa> and it boots?
2019-10-02 08:24:41 <clandmeter> sure
2019-10-02 08:24:46 <ncopa> so you use raw disk image
2019-10-02 08:24:51 <clandmeter> you can boot very easy with kernel and initrd
2019-10-02 08:25:06 <clandmeter> but if you want to use disk you need to use a boot loader
2019-10-02 08:25:11 <clandmeter> thats first issue
2019-10-02 08:25:15 <clandmeter> we dont not have one
2019-10-02 08:25:26 <ncopa> huh?
2019-10-02 08:25:47 <clandmeter> efi boot loader for qemu
2019-10-02 08:25:55 <clandmeter> we only build it for x86
2019-10-02 08:26:00 <ncopa> oh
2019-10-02 08:26:08 <clandmeter> so i got it somewhere else
2019-10-02 08:26:25 <clandmeter> so when it starts it didnt have display..
2019-10-02 08:26:30 <clandmeter> found out later why
2019-10-02 08:26:44 <clandmeter> qemu aarch64 does not have a display by default
2019-10-02 08:26:51 <clandmeter> needs -device virtio-gpu-pci
2019-10-02 08:27:33 <clandmeter> and with aarc64 you need to specify machine
2019-10-02 08:27:51 <clandmeter> which virt is the best option if you want kvm
2019-10-02 08:27:58 <clandmeter> but that limits you to 8 cpus
2019-10-02 08:28:26 <ncopa> how do you connect to the display?
2019-10-02 08:29:22 <clandmeter> you dont 
2019-10-02 08:29:30 <clandmeter> its stdout
2019-10-02 08:29:32 <mps> clandmeter: why do you use display on qemu? to see early boot messages?
2019-10-02 08:29:48 <clandmeter> -nographic
2019-10-02 08:29:59 <clandmeter> im doing it over ssh
2019-10-02 08:30:08 <ncopa> so you get serial console on stdout?
2019-10-02 08:30:19 <clandmeter> yes
2019-10-02 08:30:41 <clandmeter> i think with gpu option you can also run vnc
2019-10-02 08:30:45 <clandmeter> but i found that out later
2019-10-02 08:31:33 <clandmeter> to unlock thje 8 cpu limit i had to use another option
2019-10-02 08:31:46 <clandmeter> gic-version=3
2019-10-02 08:32:02 <mps> i got it working with qemu u-boot but only serial console
2019-10-02 08:32:34 <clandmeter> mps: yes its documented that qemu on aarch64 does not emulate a video adapter by default
2019-10-02 08:33:05 <clandmeter> i didnt test it, but i think -device virtio-gpu-pci should fix it.
2019-10-02 08:33:28 <mps> iiuc, you are trying to make it for CI
2019-10-02 08:33:53 <clandmeter> ncopa: what i noticed when using gic version 3 is that it boots slower
2019-10-02 08:34:32 <clandmeter> and there is not much information to be found on this interrupt controller 
2019-10-02 08:36:41 <clandmeter> so it took me a few hours to get this far
2019-10-02 08:37:02 <clandmeter> and i think it will take me days before getting this far on s390x and power9
2019-10-02 08:37:13 <clandmeter> if its even properly supported 
2019-10-02 08:43:30 <ncopa> im talking with mort___ here now....
2019-10-02 08:43:50 <clandmeter> ?
2019-10-02 08:44:10 <ncopa> he sits 1-2 meter from me. im in cambridge
2019-10-02 08:44:43 <ncopa> maybe we should move the discussion to #alpine-infra
2019-10-02 08:44:55 <clandmeter> ah this is commits
2019-10-02 08:44:57 <clandmeter> sure
2019-10-03 07:32:53 <fcolista> clandmeter, can you (or who have access) delete the downlaoded py3-aiofiles-0.4.0.tar.gz fomr distfiles ?
2019-10-03 07:33:04 <fcolista> Appears to be already downloaded in the past...
2019-10-03 07:33:27 <fcolista> but the new one, same version, has a different checksum
2019-10-03 09:54:28 <Cogitri> algitbot: retry master
2019-10-03 10:12:12 <Cogitri> algitbot: retry master
2019-10-06 21:33:37 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130594238
2019-10-06 21:45:04 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| fixup! init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130594687
2019-10-06 21:49:24 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| fixup! fixup! init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130594888
2019-10-06 21:53:45 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130595069
2019-10-06 21:56:24 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130595164
2019-10-06 21:57:34 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130595209
2019-10-07 18:01:46 <mps> tcely: regarding !296 yes I missed to upgrade post-upgrade
2019-10-07 18:02:00 <mps> wrong channel, sorry
2019-10-07 21:30:50 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130814760
2019-10-07 22:03:31 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130818291
2019-10-08 08:18:08 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130870279
2019-10-08 12:17:48 <nmeum> huh?
2019-10-08 12:18:10 <nmeum> ncopa: ^ could you take a look at this looks like an issue with the previous build
2019-10-08 12:18:28 <nmeum> fails to cleanup the $srcdir
2019-10-08 12:31:22 <clandmeter> nmeum: we have a fix for that
2019-10-08 12:31:27 <clandmeter> check minio apkbuild
2019-10-08 12:32:23 <nmeum> oh
2019-10-08 12:32:39 <nmeum> just suprised because it didn't happen locally but maybe that's due to abuild rootbld
2019-10-08 12:33:05 <clandmeter> thoses files are explicitly set to ro by go
2019-10-08 12:34:19 <nmeum> clandmeter: terraform already has the same cleanup function as minio
2019-10-08 12:34:29 <ncopa> i'll have a look at it after lunch
2019-10-08 12:34:46 <nmeum> thanks
2019-10-08 12:35:12 <nmeum> the entire go rebuild fiasco definitly takes more time than expected
2019-10-08 13:18:26 <travis-ci> mkinitfs:zfs [failed] |Rasmus Thomsen| init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.com/Cogitri/mkinitfs/builds/130956574
2019-10-09 14:13:40 <travis-ci> mkinitfs:master [failed] |Rasmus Thomsen| init: add support for force importing ZFS pool and ZFS native encryption | https://travis-ci.org/alpinelinux/mkinitfs/builds/595641254
2019-10-09 20:38:11 <Cogitri> algitbot: retry master
2019-10-10 06:35:33 <Cogitri> algitbot: retry master
2019-10-10 07:12:29 <clandmeter> Cogitri: i think i know whats wrong
2019-10-10 07:14:57 <Cogitri> Oh? :o
2019-10-10 07:15:17 <Cogitri> Had hoped it fixed itself over night 😅
2019-10-10 07:15:57 <clandmeter> its a computer, it will stay like this forever :p
2019-10-10 07:16:20 <clandmeter> there is one little difference between builders and local build
2019-10-10 07:16:53 <clandmeter> buidlers dont have a tty
2019-10-10 07:16:58 <clandmeter> so there is no stdout
2019-10-10 07:17:08 <Cogitri> Huh, but why would this only happen now then?
2019-10-10 07:17:34 <Cogitri> Ninja worked well before
2019-10-10 07:17:44 <clandmeter> check what has changed in the project
2019-10-10 07:18:08 <Cogitri> Did a diff, nothing much that would trigger it
2019-10-10 07:18:25 <clandmeter> what happens if you revert?
2019-10-10 07:18:47 <Cogitri> Can try on the builders, but ninja debug tells me  ninja explain: output build.ninja older than most recent input ../../../../../../../../dev/stdout (1570689391270569359 vs 1570689391677239578)
2019-10-10 07:18:55 <Cogitri> which doesn't seem like something a project change would do
2019-10-10 07:19:10 <clandmeter> maybe ninja got updated
2019-10-10 07:20:43 <Cogitri> Last update was April 26th
2019-10-10 07:20:54 <Cogitri> I'll try the diff method, let's see if that does something
2019-10-10 07:22:17 <clandmeter> Cogitri: im not sure im right about it, but anytime a local build works and on a builder it doesnt and there is something shown about stdout it smells like this.
2019-10-10 07:24:59 <clandmeter> i can also reproduce it locally if i detach the build
2019-10-10 07:25:17 <Cogitri> Oh huh
2019-10-10 07:25:27 <Cogitri> It's odd that this hasn't occured previously then though :o
2019-10-10 07:25:39 <Cogitri> Thanks for looking into it. Not quite sure what to do about it now though
2019-10-10 07:27:46 <clandmeter> found out where ninja explain: output build.ninja older than most recent input ../../../../../../../../../../dev/stdout (1570692001367809384 vs 1570692001587806708)
2019-10-10 07:27:47 <clandmeter> happens
2019-10-10 07:28:33 <clandmeter> i think its meson
2019-10-10 07:28:40 <clandmeter> upgraded oct 8
2019-10-10 07:29:38 <Cogitri> Ah, possibly
2019-10-10 07:30:19 <clandmeter> i havent touched those a lot
2019-10-10 07:30:28 <clandmeter> so im not your best resource
2019-10-10 07:30:43 <Cogitri> I'll look into it later
2019-10-10 07:58:54 <Cogitri> What do you use for detaching? nohup or smth?
2019-10-10 08:01:49 <clandmeter> exec
2019-10-10 08:09:36 <Cogitri> Ah, easy enough
2019-10-10 08:12:12 <Cogitri> Huh, it works with exec
2019-10-10 08:14:15 <Cogitri> (for me at least) ^ clandmeter
2019-10-10 08:14:37 <ncopa> how can i reproduce it locally?
2019-10-10 08:26:05 <clandmeter> i did it with exec abuild -rf &> /tmp/build2.log
2019-10-10 08:34:11 <ncopa> build-edge-x86_64:~/aports/community/mutter/src/mutter-3.34.1$ sprunge < output/build.ninja 
2019-10-10 08:34:11 <ncopa> http://sprunge.us/wECMny
2019-10-10 08:34:31 <ncopa> note that ninja says that /dev/stdout is a build depedency
2019-10-10 08:37:51 <ncopa> build build.ninja: REGENERATE_BUILD ../meson.build  ... .../dev/stdout
2019-10-10 09:06:10 <Cogitri> Hm, before I go into debugging this, it's not possibly to give the builders the TTY which would fix this, right?
2019-10-10 13:45:09 <Cogitri> algitbot: retry master
2019-10-10 13:57:43 <Cogitri> algitbot: retry master
2019-10-10 13:57:53 <Cogitri> (the real master this time now that mutter has failed)
2019-10-11 20:42:19 <_ikke_> algitbot: retry master
2019-10-11 22:48:50 <PureTryOut[m]> algitbot: retry master
2019-10-11 22:50:56 <mps> algitbot: retry master
2019-10-12 10:13:10 <PureTryOut[m]> algitbot: retry master
2019-10-12 10:59:43 <nmeum> hm, somehow the builders are currently stack at "Signing the index..."
2019-10-12 10:59:57 <nmeum> or it just takes forever currently for some reason?
2019-10-12 11:07:11 <_ikke_> nmeum: Where do you see that?
2019-10-12 11:08:14 <nmeum> oh
2019-10-12 11:08:16 <nmeum> my fault sorry
2019-10-12 11:08:26 <nmeum> I thought they were stuck because an uploaded message was not output by algibot
2019-10-12 11:08:33 <nmeum> e.g. for kbd
2019-10-12 11:08:42 <nmeum> but that's probably the case because it's currently building something else
2019-10-13 00:05:31 <travis-ci> apk-tools:master [errored] |nrybowski| test build | https://travis-ci.org/nrybowski/apk-tools/builds/597126014
2019-10-13 00:22:33 <travis-ci> apk-tools:travis [errored] |nrybowski| Attempt to fix travis build | https://travis-ci.org/nrybowski/apk-tools/builds/597130700
2019-10-13 00:39:42 <travis-ci> apk-tools:travis [errored] |nrybowski| Attempt to fix travis build x2 | https://travis-ci.org/nrybowski/apk-tools/builds/597133343
2019-10-13 01:02:17 <travis-ci> apk-tools:travis [errored] |nrybowski| Attempt to fix travis build x4 | https://travis-ci.org/nrybowski/apk-tools/builds/597137812
2019-10-13 01:17:53 <travis-ci> apk-tools:travis [errored] |nrybowski| Attempt to fix travis build x5 | https://travis-ci.org/nrybowski/apk-tools/builds/597139856
2019-10-13 01:29:00 <travis-ci> apk-tools:travis [errored] |nrybowski| Quick fix of travis builds - ppc64le still failing | https://travis-ci.org/nrybowski/apk-tools/builds/597142200
2019-10-13 20:09:14 <mps> algitbot: retry master
2019-10-14 06:19:40 <clandmeter> maxice8: ^
2019-10-14 06:19:47 <maxice8> thanks
2019-10-14 06:19:55 <clandmeter> my pleasure
2019-10-14 08:13:05 <clandmeter> algitbot: retry 3.10-stable
2019-10-14 09:03:23 <clandmeter> algitbot: retry master
2019-10-14 10:51:02 <PureTryOut[m]> algitbot: retry master
2019-10-14 12:41:49 <fcolista> that's quite bad...
2019-10-14 12:41:58 <fcolista> kubernetes with 1.13 doesn't work :-/
2019-10-14 12:42:42 <fcolista> https://github.com/kubernetes/kubernetes/issues/83124
2019-10-14 12:42:48 <fcolista> gotta disable for now..
2019-10-14 18:59:09 <clandmeter> algitbot: retry master
2019-10-15 14:13:42 <clandmeter> ncopa: i pushed an updated version of ovmf
2019-10-15 14:13:48 <clandmeter> i hope i didnt break things 
2019-10-15 14:13:55 <clandmeter> it includes aarch64 now
2019-10-15 14:14:11 <mps> clandmeter: \o/
2019-10-15 14:14:59 <clandmeter> 👊
2019-10-15 17:13:08 <travis-ci> apk-tools:master [errored] |nrybowski| Quick fix of travis builds - ppc64le still failing | https://travis-ci.org/nrybowski/apk-tools/builds/598251146
2019-10-15 17:17:03 <travis-ci> apk-tools:master [errored] |nrybowski| Adding test case for --ignore flag | https://travis-ci.org/nrybowski/apk-tools/builds/598251865
2019-10-15 17:19:10 <travis-ci> apk-tools:travis [passed] |nrybowski| travis fix attempt | https://travis-ci.org/nrybowski/apk-tools/builds/598251534
2019-10-17 07:55:42 <_ikke_> algitbot: retry 3.10-stable
2019-10-17 13:29:45 <travis-ci> apk-tools:fix-travis [failed] |nrybowski| Fix travis build by updating alpine-chroot-install to v0.11.0 and Ubuntu distro to bionic | https://travis-ci.org/nrybowski/apk-tools/builds/599157085
2019-10-17 13:35:34 <travis-ci> apk-tools:fix-travis [errored] |nrybowski| Fix travis build by updating alpine-chroot-install to v0.11.0 and Ubuntu distro to bionic | https://travis-ci.org/nrybowski/apk-tools/builds/599159709
2019-10-17 14:07:24 <Cogitri> algitbot: retry master
2019-10-17 14:08:48 <Cogitri> 
ACTION shakes fist at texlive's build race conditions

2019-10-17 15:57:41 <_ikke_> algitbot: retry master
2019-10-17 16:44:12 <PureTryOut[m]> algitbot: retry master
2019-10-18 08:05:08 <travis-ci> apk-tools:fix-travis [errored] |nrybowski| Fix travis build by updating alpine-chroot-install to v0.11.0 and Ubuntu distro to bionic | https://travis-ci.org/nrybowski/apk-tools/builds/599159709
2019-10-19 11:51:42 <clandmeter> algitbot: retry master
2019-10-19 11:56:27 <clandmeter> algitbot: retry master
2019-10-19 16:03:33 <_ikke_> wxWidgets wx/version.h file not found in
2019-10-21 13:39:28 <ncopa> algitbot: retry 3.10-stable
2019-10-22 10:15:07 <PureTryOut[m]> algitbot: retry master
2019-10-23 14:38:26 <maxice8> foobar uploaded :D
2019-10-24 19:08:03 <Cogitri> algitbot: retry master
2019-10-24 19:08:28 <Cogitri> Damnit rustc
2019-10-24 19:21:37 <_ikke_> Cogitri: ok, now it seems to continue
2019-10-24 19:21:43 <_ikke_> What makes it flaky?
2019-10-24 19:31:20 <Cogitri> _ikke_ Our rustc likes to SIGSEGV on projects using gtk-rs since that's such a massive project. Not sure what causes it, Void suffers from the same thing
2019-10-24 19:31:32 <_ikke_> ok
2019-10-26 18:50:30 <_ikke_> algitbot: retry mater
2019-10-26 18:50:32 <_ikke_> algitbot: retry master
2019-10-26 18:58:53 <_ikke_> algitbot: retry master
2019-10-26 19:01:34 <_ikke_> Strange, it seems like it still uses busybox cpio after installing the cpio package
2019-10-26 19:39:35 <_ikke_> algitbot: retry master
2019-10-26 19:42:27 <_ikke_> algitbot: retry master
2019-10-26 20:48:42 <_ikke_> algitbot: retry master
2019-10-26 21:01:04 <_ikke_> algitbot: retry master
2019-10-29 09:53:03 <maxice8> algitbot: retry master
2019-10-29 11:32:30 <_ikke_> maxice8: re nmap: http://tpaste.us/5Ev7 
2019-10-29 11:32:39 <_ikke_> algitbot: retry master
2019-10-29 11:32:45 <_ikke_> algitbot: retry 3.9
2019-10-29 11:32:48 <_ikke_> algitbot: retry 3.9-stable
2019-10-29 11:33:53 <_ikke_> maxice8: hmm, ok, 2nd time it succeeded