2024-04-01 09:09:53 good point 2024-04-01 10:42:48 It does mean all the buildlogs will be redirected to https as well 2024-04-01 10:43:20 I could limit the redirect to ' 2024-04-01 10:43:23 '/' 2024-04-01 10:43:38 Though, not sure for build logs it matters too much 2024-04-01 12:49:37 im working on build-edge-aarch64 2024-04-01 13:19:42 ssh: Could not resolve hostname build-3-19-x86_64.nld9.alpin.pw: Name does not resolve 2024-04-01 13:19:49 this was not the day I wanted DNS to be broken 2024-04-01 13:19:56 makes scripting stuff harder 2024-04-01 13:21:20 alpin.pw 2024-04-01 13:21:30 That was the same thing that cause the Curl tests issue, right? 2024-04-01 13:23:19 !62791 2024-04-01 13:24:13 and https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10818 2024-04-01 13:31:56 but looking through irc logs, it seems it's always been alpin.pw, so i guess that's the correct one instead of alpine.pw? 2024-04-01 13:41:09 Yes 2024-04-01 14:27:48 alright. i think we have fixed all APKINDEX for all branches and all achitectures 2024-04-01 14:30:01 Thanks! 2024-04-01 15:13:44 now it is really fixed 2024-04-01 15:13:51 and verified to be fixed 2024-04-02 11:29:34 ikke: ping. I am in place5/Schwanden at the moment and if you want to, I could recable the server to the ipv4-only/nat44 network and try to hack some kind of tunnel to give you access to the server for reconfiguration 2024-04-02 11:29:48 telmich: yes, please go ahead 2024-04-02 11:30:10 ack, eta 1-1.5h 2024-04-02 11:30:28 ok, I'll be availabe to test / reconfigure myself after 5pm 2024-04-02 11:31:22 ack 2024-04-02 11:31:48 can you quickly just let me know, which IPv6 address it should have at the moment? 2024-04-02 11:32:20 2a0a:e5c1:517:cafe:da5e:d3ff:fee6:1f28 2024-04-03 09:21:57 ikke, telmich: the arm box is online again? 2024-04-03 09:22:29 I haven't heard anything yet 2024-04-03 11:01:11 telmich: can you give an update please? 2024-04-03 17:05:55 Ramereth: when you have time, could you check our ppc64le machine? It still responds to ping, but is further unresponsive 2024-04-03 19:07:06 ikke: checking now 2024-04-03 19:07:41 Ramereth: thanks 2024-04-03 19:07:57 ikke: is it alpine-p9.osuosl.org? 2024-04-03 19:08:12 Yes, should be 2024-04-03 19:08:39 console isn't responding, okay if I reset? 2024-04-03 19:09:16 yes 2024-04-03 19:09:46 done, watching it boot now 2024-04-03 19:12:34 should be back 2024-04-03 19:13:04 Getting data again 2024-04-03 19:15:01 Ramereth: thanks 2024-04-04 20:40:41 algitbot: retry master 2024-04-05 06:36:46 telmich: can you please give us an update? 2024-04-05 07:16:17 clandmeter: good morning! when would be a good time to update kernel and reboot the riscv64 machines? 2024-04-05 07:16:38 probably monday 2024-04-05 07:16:50 I am in office now but not for long 2024-04-05 07:18:23 err Tuesday 2024-04-05 07:18:54 or you can do it now, but i can only check around 12 2024-04-05 07:19:12 maybe need an backup kernel in case of fire 2024-04-05 07:20:01 lets do it next week 2024-04-05 07:27:27 anyone noticed mdev segfault, I've got it in aarch64, have to check on armv7 and riscv64 2024-04-05 08:27:08 i havent seen. but i think there was a recent busybox update with backported fixes 2024-04-05 08:48:22 on armv7 it works fine, will test on another aarch64 machine 2024-04-05 08:48:51 maybe it is something with my patches on m1 2024-04-05 10:47:16 hm, false 'alarm' mdev works fine on other aarch64 machine (only fails on m1) 2024-04-08 06:49:46 Already dealt with it 2024-04-08 06:51:26 thank you! 2024-04-08 11:23:28 anyone could help me to make dbg subpackage for community/svxlink. I've built it with '-DBUILD_TDžPE=Debug' but abuild can't make -dbg pkg 2024-04-08 11:24:07 TYPE* 2024-04-08 11:26:36 oh, nvm 2024-04-08 11:27:18 subpackage name should be '$pkgname-dbg' and not '$pkgname-deb' :) 2024-04-08 12:05:50 lol 2024-04-09 10:52:01 ncopa: you want to reboot the box? 2024-04-09 10:53:58 aw. aw. forgot about that 2024-04-09 10:56:45 ok, it seems there are no new changes in sophgo kernel 2024-04-09 11:05:13 clandmeter: can i try reboot nld-bld-2 now? 2024-04-09 11:05:30 what was the ip? 2024-04-09 11:05:55 172.16.30.3 2024-04-09 11:06:05 found it 2024-04-09 11:06:45 ok lets try 2024-04-09 11:07:04 rebooting in 10.. 2024-04-09 11:07:05 9 2024-04-09 11:07:06 8 2024-04-09 11:07:07 ... 2024-04-09 11:07:26 were we go 2024-04-09 11:07:46 i dont know 2024-04-09 11:08:23 clandmeter: [offtopic] have you experience with tinkerbell? 2024-04-09 11:08:28 im playing with it now 2024-04-09 11:08:40 nope, i know it but didnt touch it. 2024-04-09 11:09:19 equinix provisioner 2024-04-09 11:09:37 yup. it has pretty neat "actions", which will stream a disk image to disk 2024-04-09 11:09:52 and mount the disk, and update cloud-init config et 2024-04-09 11:09:55 etc 2024-04-09 11:10:00 i was actually looking into a solution like this. 2024-04-09 11:10:13 but those "actions" are pretty powerful 2024-04-09 11:10:19 i am looking for a simple solution to push disk images to servers 2024-04-09 11:10:36 preferable gui based as its used by others 2024-04-09 11:10:41 bare metal? 2024-04-09 11:10:45 or vms 2024-04-09 11:10:46 yes 2024-04-09 11:10:49 metal 2024-04-09 11:10:54 we sell metal :) 2024-04-09 11:10:57 :) 2024-04-09 11:11:05 so, tinkerbell does this 2024-04-09 11:11:16 but is pretty bare-bones 2024-04-09 11:11:47 the major selling point for tinkerbell is that it fits well with kubernetes. so if you are used to kuberentes, its gonna be great 2024-04-09 11:12:27 or if you are looking for how to provision kubernetes to bare-metal, then i'd say tinkerbell is a good way to go 2024-04-09 11:12:51 but it is just one component, and not a full solution 2024-04-09 11:13:18 if you want a full solution, and no kubernetes, then MAAS might be worth looking at 2024-04-09 11:13:34 im not really looking for a solution for k8s 2024-04-09 11:13:44 push os and test things 2024-04-09 11:13:58 maybe have some images with pre installed stuff 2024-04-09 11:14:17 but i was thinking for equinix, and tinkerbell. we ship disk images for equinix right? 2024-04-09 11:14:35 but with tinkerbell actions, we dont really need the disk images 2024-04-09 11:14:47 we can generate the "disk image" on the fly with actions 2024-04-09 11:15:52 brb. lunch 2024-04-09 11:39:15 nld-bld-2 [~]# uname -a 2024-04-09 11:39:15 Linux nld-bld-2 6.1.80-0-sophgo #1-Alpine SMP PREEMPT Fri, 29 Mar 2024 13:52:24 +0000 riscv64 Linux 2024-04-09 11:39:20 reboot was success 2024-04-09 11:39:54 the gitlab-runner has been up for 54 years 2024-04-09 11:40:03 thats impressive :) 2024-04-09 11:40:50 cool 2024-04-09 11:59:56 ncopa-edge-riscv64:~# cat /etc/resolv.conf 2024-04-09 11:59:56 search alpine.pw 2024-04-09 12:00:13 clandmeter: the DHCP server sets `search alpine.pw` which is wrong 2024-04-09 12:06:31 ncopa: can you login to .30.1? 2024-04-09 12:07:52 nope. it asks for password 2024-04-09 12:35:26 oh ok 2024-04-09 12:35:36 you need to fix it in the router 2024-04-09 12:37:26 ncopa: dnsmasq updated 2024-04-09 12:37:30 typo fix 2024-04-09 12:38:20 thank you sir! 2024-04-09 12:38:42 ncopa: you can now login to .1 2024-04-09 12:38:47 i added youir keys 2024-04-09 12:40:09 thank you sir! 2024-04-09 12:43:29 ncopa: i guess you will also update the first one? 2024-04-09 12:47:10 ncopa: we also need to keep the bootloader uptodate for the dtb. https://github.com/sophgo/bootloader-riscv/actions/runs/8609334180 2024-04-09 13:37:11 clandmeter: can I reboot the first machine now? 2024-04-09 14:58:58 ncopa: sure go ahead 2024-04-09 14:59:12 I will be here for another 20 min 2024-04-09 15:24:53 I missed that window. lets try tomorrow then 2024-04-10 13:29:13 ncopa: you want to reboot now? 2024-04-10 14:07:37 yes 2024-04-10 14:07:42 clandmeter: can i reboot? 2024-04-10 14:07:50 go ahead 2024-04-10 14:08:44 rebooting 2024-04-10 14:19:05 i guess its not coming back? 2024-04-10 14:44:23 ncopa: something is wrong with this box 2024-04-10 14:49:39 network is up 2024-04-10 14:49:41 ssh is running 2024-04-10 14:49:49 firewall is off 2024-04-10 14:49:55 but no ssh access 2024-04-10 14:52:17 it also seems the kernel crashes on something 2024-04-10 14:56:09 hum 2024-04-10 16:04:02 so the nld-bld-1 (riscv64) is down til tomorrow 2024-04-10 16:40:12 so, rv64 containers don't work now? 2024-04-10 16:46:34 also, should we set this new sec flaw in kernel named BHI to on, off or auto for alpine? 2024-04-10 16:50:27 not heard of it 2024-04-10 16:51:30 it is new intel CPU sec flaw related to spectre 2024-04-10 16:51:49 is 6.6.25 fixing that? 2024-04-10 16:51:50 updated kernel are released about hour ago 2024-04-10 16:52:21 https://lwn.net/Articles/969354/ 2024-04-10 16:53:00 here is short intro https://lwn.net/Articles/969210/ 2024-04-10 16:54:14 I decided to set it to on, to not have option for someone to say alpine kernels are insecure 2024-04-10 16:54:46 though I expect some performance impact 2024-04-10 16:55:18 other arches are safe from this 2024-04-10 19:19:57 is build-edge-x86 stuck? 2024-04-11 05:15:48 gitlab security upgrade 2024-04-11 06:28:21 morning! omni: seems so yes 2024-04-11 11:17:33 mps: can you please do me a favor? upgrade scribus to 1.6.1 (or latest) 2024-04-11 11:17:45 its blocking my python 3.12 upgrade project 2024-04-11 11:18:06 storage issues on the x86_64 CI builder? 2024-04-11 11:19:09 avail: 20G 2024-04-11 11:19:27 So only projects that require an unreasonable amount of space will fail :P 2024-04-11 11:19:54 k 2024-04-11 11:19:55 dotnet, chromium: im looking at you 2024-04-11 11:20:09 ncopa: you said what I thought :P 2024-04-11 11:22:44 Total reclaimed space: 165.7GB 2024-04-11 11:31:54 ncopa: I tried few weeks ago but it failed and I didn't looked deeply in 2024-04-11 11:32:13 will try to find some time later today 2024-04-11 11:32:27 or I will remove it 2024-04-11 11:32:39 ofc, if can't upgrade 2024-04-11 11:35:51 scribus is example for me how it could be bad idea to be kind to someone, I added because someone asked me to do and tell he will continue to maintain it, but he went to hospital and after that I didn't heard a word from him 2024-04-11 11:36:26 be kind related to distro, I mean 2024-04-11 11:47:05 understood 2024-04-11 11:47:23 happens pretty often. contributors want to be helpful and add new stuff 2024-04-11 11:47:34 and then expect other people to maintain it 2024-04-11 11:55:30 what we do nowadays when execinfo is needed 2024-04-11 11:56:02 disable it / patch it out 2024-04-11 11:57:22 ok, will try 2024-04-11 12:50:46 i think the patch will be rebased 2024-04-11 12:51:07 mps: i got approx to where you are now before i pinged you :) 2024-04-11 12:57:51 ncopa: what? 2024-04-11 12:58:08 about what you are talking 2024-04-11 12:58:41 i tried to aubmp scribus 2024-04-11 12:58:45 abump* 2024-04-11 12:58:46 aha 2024-04-11 12:58:56 removed the exedcinfo patch 2024-04-11 12:59:02 because it didnt apply 2024-04-11 12:59:16 and at that point i figured I'll ask the maintainer 2024-04-11 12:59:21 I simply removed execinfo.h includes 2024-04-11 12:59:38 in source 2024-04-11 12:59:59 but there are other issues 2024-04-11 13:00:38 /home/mps/aports/community/scribus/src/scribus-1.6.1/scribus/util.cpp:905:28: warning: comparison of integer expressions of different signedness: 'int' and 'quint32' {aka 'unsigned int'} [-Wsign-compare] 905 | if (strData.size() != bytesLen) 2024-04-11 13:01:03 stupid C++ 2024-04-11 13:01:47 and 2024-04-11 13:02:08 /home/mps/aports/community/scribus/src/scribus-1.6.1/scribus/util_debug.cpp:60:22: error: 'backtrace' was not declared in this scope 60 | trace_size = backtrace ( trace, nFrames + 1 ); 2024-04-11 13:14:55 ncopa: aha, rebasing no execinfo patch and removing poppler patches seems to work 2024-04-11 13:15:50 but I found this, https://gitlab.archlinux.org/archlinux/packaging/packages/scribus/-/blob/main/scribus-1.6.1-poppler-24.03.patch?ref_type=heads in arch linux 2024-04-11 13:16:01 not sure to include it or not 2024-04-11 13:18:09 thats the nice thing with having maintainers. I don't need to make those decisions or worry about it :) 2024-04-11 14:18:10 hm, https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1339139#L65 2024-04-11 14:18:27 so we have to disable scribus on s390x 2024-04-11 14:19:15 thats fine 2024-04-11 14:19:37 the less we have to build on s390x the better 2024-04-11 14:25:28 :D 2024-04-11 14:43:56 some CIs are loaded or don't work https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/225730 2024-04-11 14:44:36 Some long running jobs 2024-04-11 14:44:45 chromium 2024-04-11 14:46:15 ah 2024-04-11 16:38:46 ncopa: pushed scribus to builder, lets hope for it 2024-04-11 20:02:57 chromium pipelines keeping CI blocked nearly all day 2024-04-11 22:53:35 it is almost as if web browsers should have their own infrastructure to build on 2024-04-11 22:54:38 I'm holding off the chromium upgrades on 3.19-stable until the edge builders are done 2024-04-11 22:56:03 and also refrain from opening chromium security upgrade MRs for qt6-qtwebengine until chromium and electron (also chromium) are done 2024-04-12 07:31:04 good morning 2024-04-12 07:31:44 i was thinking that we should maybe have some additional CI runners. low powered, low memory. (eg rpi level performance) 2024-04-12 07:32:02 and then we could have a tag on MR, "ci-light" 2024-04-12 07:32:16 which would be sceduled on those low powered runneres 2024-04-12 07:32:55 they would be a fast-track lane for lightweight stuff 2024-04-12 07:32:58 eg noa-rch 2024-04-12 07:33:01 noarch 2024-04-12 07:33:15 we coudl limit those to 10min run time 2024-04-12 07:33:57 we could have a few vm's or containers, allocate 4 vcpus, 2G ram or something 2024-04-12 07:35:45 alternatively we could do the opposite, have multiple low-powered runner (4G ram something?) with low timeout (10-15 mins?) as the default runner, and you would have to tag the MR 'ci-heavy' to get a big CI runner 2024-04-12 07:36:28 best woudl be if we set the build weight in APKBUILD somehow. 2024-04-12 08:09:30 I have been thinking about the past 2024-04-12 08:10:10 The problem is that we can only effectively do this for some arches 2024-04-12 08:16:27 i was actually thinking earlier this morining that for arm* we could add a couple of RPI's 2024-04-12 08:16:44 and for riscv64 I have a vision five 2 board we could use 2024-04-12 08:17:24 also, we could allocate a lxc container, or docker container, and limit the memory and cpu usage 2024-04-12 08:17:50 also FYI: https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10820 2024-04-12 08:18:11 the official x86_64 is no longer keeping up with the chromium security fixes 2024-04-12 08:18:43 Yup, saw that issue 2024-04-12 08:32:47 which makes most sense? default big CI machines and mark light build jobs, or the opposite, default small CI machines, and mark heavy jobs? 2024-04-12 08:33:15 do we have any stats of the CI jobs? 2024-04-12 08:33:49 eg how many % of the CI jobs takes less than 10 mins, etc 2024-04-12 08:38:14 ncopa: you could look at admin/jobs 2024-04-12 08:40:17 👍 2024-04-12 09:01:03 It probably means we need to dynamically generate pipelines to target different runners 2024-04-12 09:01:36 ncopa: how do we deal with dependencies in case of multiple packages 2024-04-12 09:02:08 They probably all need to go to the heavy CI 2024-04-12 09:18:08 yeah 2024-04-12 09:18:44 question is if heavy CI or light CI is the exception 2024-04-12 09:25:13 I'd say heavy 2024-04-12 14:37:18 Ooh 2024-04-12 14:37:23 clandmeter: ^ 2024-04-12 14:37:44 telmich: seems like our server is reachable again 2024-04-12 15:15:29 hmm 2024-04-12 15:15:50 no, no data yet 2024-04-12 17:53:01 omni: you fixed util-linux. thank you very much (I couldn't do much in last few days because I've got strong cold and my nose is like faucet, and have headache) 2024-04-12 18:00:08 no problem, get well 2024-04-12 18:03:58 I'm trying, thanks 2024-04-12 19:35:50 clandmeter & ikke I'm on my way to place5, will recable vigir23 and remove the VPN and reconfigure vigir23 to get its /48 prefix routed instead. Best case, ipv6 addresses stay the same. 2024-04-12 19:39:42 Created route6 2a0a:e5c1:517::/48 from AS199553 - waiting a bit for propagation 2024-04-12 19:41:01 Reconfigured server138 to announce 2a0a:e5c1:517::/48 2024-04-12 19:41:30 Route seems to be propagating according to... (full message at ) 2024-04-12 19:42:11 Reconfiguring vigir23 to assign transfer IPv6 address on wan6 interface 2024-04-12 19:43:25 Route is now also propagated by server137 2024-04-12 19:43:39 vigir23 is reconfigured, missing is physical recabling and disabling of wireguard - ETA 1.5h 2024-04-12 20:10:37 vigir23 pings now in the transfer network 2024-04-12 20:11:51 Disabling wireguard on vigir23 2024-04-12 20:14:42 Verified that 2a0a:e5c1:517:cafe:da5e:d3ff:fee6:1f28 is reachable world wide - arm box in place5/switzerland is back online 2024-04-12 20:21:05 telmich: confirmed, i have access again, thanks a lot] 2024-04-13 14:33:26 seems like build-edge-x86* are stuck on py3-fakeredis 2024-04-14 02:31:21 CI build-armhf: 2024-04-14 02:31:22 Connecting to github.com (140.82.121.3:443) 2024-04-14 02:31:34 wget: can't connect to remote host (140.82.121.3): Network unreachable 2024-04-14 14:10:41 is build-3-19-armv7 stuck? 2024-04-15 06:06:21 morning. I 'm having a look at build-3-19-armv7 2024-04-15 06:16:20 maybe it was actually running. but painfully slow 2024-04-15 06:16:36 and I aborted it :/ 2024-04-15 06:21:10 looks like it does not parallelize the work 2024-04-15 06:55:11 ncopa: same problem with old firmware 2024-04-15 06:55:37 for rv64 2024-04-15 06:59:37 ok 2024-04-15 06:59:49 so maybe it is the wardware? 2024-04-15 07:06:05 or a regression in the kernel 2024-04-15 07:11:10 should we try downgrade to the last known working kernel? 2024-04-15 08:12:07 i guess thats the most easy way forward 2024-04-15 08:12:15 but ill be gone this week 2024-04-15 08:12:28 so we should fix it before 13:00 to try 2024-04-15 08:29:32 im building it on the other machine now 2024-04-15 08:29:41 linux-sophgo-6.1.72_git20240119 2024-04-15 09:14:49 clandmeter: I have a kernel on 172.16.30.3:/var/lib/lxc/ncopa-edge-riscv64/rootfs/home/ncopa/packages/testing/riscv64/linux-sophgo-6.1.72_git20240119-r7.apk but I don't know how to transfer it 2024-04-15 09:20:10 kernel is available at repo http://172.16.30.102:8000/testing 2024-04-15 09:25:40 I'd like to set up the build-edge-loongarch64 now. I need a subnet for dmvpn, which I'll set up later 2024-04-15 09:25:52 can I use 172.16.31.0/24? 2024-04-15 10:14:45 ikke: is 172.16.31.0/24 free for loongarch builder? 2024-04-15 10:14:58 i dont have net box here handy atm 2024-04-15 10:15:22 or should we use 172.16.32,33,34? I think he said they have 3 boxes 2024-04-15 10:55:49 ncopa: I wonder if these boxes are share the same LAN or not 2024-04-15 13:41:01 build-edge-armv7 and build-edge-x86_64 are stuck 2024-04-15 16:57:13 ncopa: you can install it and try to reboot 2024-04-15 16:57:43 but i can only fix things on monday ealiest, but could be a week later 2024-04-15 16:59:35 i think i may also have some old kernels in my container 2024-04-16 01:06:14 more than 20 new users created within an hour, huh 2024-04-16 02:09:43 what's with build-edge-riscv64 now then? 2024-04-16 05:50:31 clandmeter: seems like nld-bld-2 is unreachable 2024-04-16 06:40:43 would it help if I spun up two disc machines on scaleway? for temp CI? 2024-04-16 06:42:05 I think the nld-bld-1,2 will be away for a week 2024-04-16 07:11:14 so, no all dependant pkgs are rebuilt with python 3.12 2024-04-16 07:18:39 ikke: 62.210.163.140 and 62.210.163.34 are riscv64 from scaleway. your keys should be there. if you have time to set them up as temp CI. I'm gonna be AFK til afternoon. 2024-04-16 07:22:56 ikke: I can power toggle the machines, not sure it will help 2024-04-16 07:23:22 can you reach the router? 2024-04-16 07:24:55 Yes 2024-04-16 07:29:42 algitbot: retry master 2024-04-16 07:30:32 so both are offline now right? 2024-04-16 07:30:43 i mean 1 has not ssh 2024-04-16 07:30:47 2 is offline 2024-04-16 07:36:11 Nod 2024-04-16 07:39:41 It appears to be back 2024-04-16 07:52:41 it is probably nvme delays 2024-04-16 08:17:25 clandmeter: have you heard about others having similar issues with the pioneer machines? Could it be hardware problems with the nvme? 2024-04-16 09:35:53 ncopa: its a common problem 2024-04-16 09:36:01 not sure if its the nvme or the controller 2024-04-16 09:36:25 some of the OS's have a cmdline option added 2024-04-16 09:39:05 I have a samsung ssd to try 2024-04-16 10:26:15 telmich: should there still be nat64 active? Setting the nameserver to 2a0a:e5c0:0:a::a, we get nat64 addresses back, but they appear to be unroutable 2024-04-16 11:34:34 "nico🇨🇭: should there still be..." <- That is correct and that is a bug, I have also seen this right now. Should be fixed in about 24h. 2024-04-16 11:34:45 telmich: alright, thanks 2024-04-16 12:07:23 do we keep track so no-one is mining shitcoins on our CI infrastructure? 2024-04-16 12:07:58 also thinking of those 20+ users created within an hour 2024-04-16 12:19:56 omni: that is a gitlab glitch 2024-04-16 12:20:14 omni: i do keep track of new users created 2024-04-16 12:21:19 omni: https://gitlab.alpinelinux.org/alpine/infra/gl-usr-mgmt 2024-04-16 12:24:25 👍 2024-04-16 12:24:35 thanks 2024-04-16 12:26:54 Sometimes gitlab reports ~100 users more. Not sure why 2024-04-16 13:52:59 ikke do we need extra machines for riscv64 CI? 2024-04-16 13:53:51 I haven't checked yet 2024-04-16 13:54:10 Are there many jobs pending? 2024-04-16 13:56:42 2 riscv64 2024-04-16 13:57:22 8 aarch64 2024-04-16 13:58:30 13 x86_64 2024-04-16 14:00:06 seems like x86_64 CI is progressing. just dead slow 2024-04-16 14:00:51 seems liek al CIs are running slow 2024-04-16 14:01:02 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1347026 2024-04-16 14:04:58 maybe they're just exhausted and need to lie down on the couch for a while 2024-04-16 14:06:12 im gonna mercy kill some of the jobs 2024-04-16 14:06:35 installing mariadb should not tak 358 minutes 2024-04-16 14:08:08 this is whats eating up our resources https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/64288/diffs 2024-04-16 14:13:52 i dunno what to do. maybe we just killall running jobs? 2024-04-16 14:16:12 and there aren't things outside of alpine/aports CI jobs hogging resources? 2024-04-16 14:19:21 difficult to know. is probably a good reason to kill all the jobs to find out whats happening on the servers 2024-04-16 14:22:16 like kill all CI jobs related to alpine/aports and see what's left? 2024-04-16 14:22:32 users can run their own pipelines, right? 2024-04-16 14:27:51 Yes, but I did not see any suspicious jobs running 2024-04-16 14:38:33 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60879/diffs 2024-04-16 14:40:13 i think its those two build jobs that eating the resources. kde rebuild + abseil-cpp 2024-04-16 14:41:08 what host is s390x ci 2024-04-16 14:43:48 s390x-ci.a.o iirc 2024-04-16 14:49:55 load average: 12.44, 12.41, 11.13 2024-04-16 15:29:17 ikke: We just checked and the nat64 translator in place5 has an issue and will need to be replaced in addition to fixing the dns64 prefix. Hardware should arrive in the next 2 days and hopefully nat64 will be working by end of week again. 2024-04-16 15:29:39 Alright, thanks for the update 2024-04-16 15:29:46 (nobody noticed until now, as all other services in place5 are now ipv6 only) 2024-04-16 15:30:02 telmich: Thank you! 2024-04-16 15:31:15 I think I have resurected the other riscv64 machine. nld-bld-1 is up and running avter I downgraded the kernel 2024-04-16 15:31:38 aha ok 2024-04-16 15:31:51 I'm going to upgrade / reboot the aarch64 CI vm on che-bld-1 2024-04-16 15:32:01 👍 2024-04-16 15:32:26 maybe just check that there is no huge job that is almost finished 2024-04-16 15:33:16 Yes, I was doing that 2024-04-16 15:33:51 https://gitlab.alpinelinux.org/knuxify/aports/-/jobs/1347628 is basically ready, but hanging on checkapk 2024-04-16 15:39:11 all other looks green so I'd say just reboot 2024-04-16 15:39:33 fun: https://tpaste.us/Vq1N 2024-04-16 15:40:02 alright.... 2024-04-16 16:20:38 hmm, not sure why I'm getting those errors, tried to run apk fix linux-virt, but that did not seem ot help 2024-04-16 16:20:40 to 2024-04-17 07:53:11 looks like maintainer of putty is not active. I think we should merge !64344 and probably backport 2024-04-17 07:54:26 also, how we can build all commits in one branch and not one by one 2024-04-17 07:59:58 mps: what do you mean? 2024-04-17 08:01:43 ikke: I have branch with changes to 6 pkgs. is there way to build locally all with one command and not repeat abuild -r 6 times 2024-04-17 08:05:53 You can create a shell oneliner to do that 2024-04-17 08:07:56 I know but I thought we ready-made tool for this 2024-04-17 08:10:52 we hav* 2024-04-17 08:10:59 have* 2024-04-17 08:13:00 We have building blocks 2024-04-17 08:13:30 ap builddirs lists provided packages in build order 2024-04-17 08:13:46 buildrepo will try to build all packages 2024-04-17 08:14:36 mps: in CI, we use git diff combined with ap builddirs 2024-04-17 09:17:00 ikke: thanks for info, in my case shell will be enough 2024-04-17 10:12:12 seems like x86_64 CI runner is MIA 2024-04-17 10:20:18 It's runnign 2 builds? 2024-04-17 10:26:36 seems so yes, but its missing in the list of runners in new MRs 2024-04-17 10:27:09 Example? 2024-04-17 10:27:46 sorry my bad. i didnt scroll 2024-04-17 10:27:48 ok 2024-04-17 10:27:49 im losing it 2024-04-17 10:31:00 ncopa: please take care 2024-04-17 10:32:18 do we want set up build-3-20-riscv64 on same machine as build-edge-riscv64? or the other? 2024-04-17 10:32:30 i think the other for now, since edge build is busy 2024-04-17 10:32:41 ikke: i hear you 2024-04-17 10:34:03 ncopa: yeah, nld-bld-1 would make sense 2024-04-17 10:45:41 im gonna reconfigure the network on nld-bld-1. Do we have ability to remove power-cycle it in case I mess up? 2024-04-17 10:46:12 *remote 2024-04-17 10:46:20 i need to set up a bridge 2024-04-17 10:46:27 carlo can 2024-04-17 10:46:59 both will go offline 2024-04-17 10:47:23 ncopa: maybe schedule a reboot that you can cancel? 2024-04-17 10:48:12 good idea 2024-04-17 10:49:25 i think I messed it up 2024-04-17 10:50:06 btw, i had to modify the network on #2 2024-04-17 10:50:22 disabling the bridge 2024-04-17 10:50:28 ok? 2024-04-17 10:50:32 as it was a weird issue 2024-04-17 10:50:34 with the kernel 2024-04-17 10:50:40 it didnt bring up the bridge 2024-04-17 10:50:41 im trying to enable the bridge now 2024-04-17 10:51:08 alright, thats what is happening now then 2024-04-17 10:51:10 I paused the arm* runners on che-ci-1 for now 2024-04-17 10:51:12 they keep hanging 2024-04-17 10:51:24 nld-bld-1 [~]# sh -c "ifdown eth0 && ifup br0" 2024-04-17 10:51:34 and it stopped respond to ping 2024-04-17 10:51:45 it will reboot now-ish (2 mins) 2024-04-17 10:51:54 but it will configure the bridge during boot 2024-04-17 10:52:14 so I suppose I just killed the nld-bld-1 for a couple of weeks 2024-04-17 10:54:58 seems like we will have to wait with the riscv64 for 3.21 2024-04-17 10:59:47 uhm 2024-04-17 11:00:17 no one is able to come there and boot it 2024-04-17 11:00:48 and no out-of-band access 2024-04-17 11:03:40 probably monday i can fix it 2024-04-17 11:06:43 clandmeter: im sorry 2024-04-17 11:17:12 sorry im not available 2024-04-17 13:57:46 i have set up build-3-20-riscv64 on the nld-bld-2 machine. poor little thing 2024-04-17 14:24:25 better than nothing 2024-04-17 15:19:42 are we also running CI jobs on it? 2024-04-17 15:20:54 yes 2024-04-17 15:26:17 would it be an idea to not do that until it catches up? 2024-04-17 15:27:53 ncopa arranged 2 servers on scaleway, I can setup CI there 2024-04-17 15:31:45 ncopa: did you still have those 2 servers? 2024-04-17 18:52:49 Seems like x86_64 CI is struggling (memory) 2024-04-17 19:09:05 i took them down. I can re-create them 2024-04-17 19:09:39 do we have swap enabled on x86_64 ci? maybe we should kill the swap 2024-04-17 19:10:15 There is swap 2024-04-17 19:10:45 just 2G 2024-04-17 19:10:53 ran swapoff -a 2024-04-17 19:14:58 riscv64 machiens for CI: 62.210.163.140 and 62.210.163.196 2024-04-17 19:15:14 do we expect those to be up more than 2 weeks? 2024-04-17 19:15:26 i wonder if i should do monthly or hourly billing 2024-04-17 19:18:05 The idea is to offload the rv machines we have, right? 2024-04-17 19:18:10 Not sure for how long that's required 2024-04-17 19:18:11 yes 2024-04-17 19:18:37 i was thinking for up til the 3.20 is out 2024-04-17 19:18:53 alright, lets see how it goes 2024-04-17 19:19:08 maybe we could also ask if they can sponsor us 2024-04-17 19:19:15 They did in the past, but they canceled it 2024-04-17 19:19:23 yeah 2024-04-17 19:19:59 62.210.163.196 connection refused 2024-04-17 19:20:14 ah, now it's available 2024-04-17 19:20:18 its still being provisioned. 2024-04-17 19:20:26 they say it can take up to one hour 2024-04-17 19:20:31 they're both available now 2024-04-17 19:21:12 could you script the setup? then we can take them down and up as needed 2024-04-17 19:22:09 I guess so 2024-04-17 19:22:12 We are having ipv6 issues from the arm machine: 2024-04-17 19:22:22 >>> fortify-headers: Fetching http://dl.2f30.org/releases/fortify-headers-1.1.tar.gz 2024-04-17 19:22:22 wget: can't connect to remote host: Host is unreachable 2024-04-17 19:22:22 Connecting to dl.2f30.org ([2001:19f0:6c01:2782:5400:3ff:fe0f:6f7f]:80) 2024-04-17 19:22:30 which runner? 2024-04-17 19:23:13 it is the build-3-20-a* machines 2024-04-17 19:24:09 They do have an ipv6 address 2024-04-17 19:24:48 I think that's site is broken 2024-04-17 19:24:55 it has an AAAA record but it's not working 2024-04-17 19:29:53 i should set up DISTFILES_MIRROR 2024-04-17 19:41:31 oh whoops 2024-04-17 19:41:52 there was a kernel update in my current git that I forgot about 2024-04-17 19:42:16 poor builders will have to deal with kernel builds in addition to chroumium and firefox 2024-04-17 19:43:01 and gcc for bootstrapping 3.20 builders 2024-04-17 19:54:25 ncopa: I've registered one and it immediately picks up jobs :) 2024-04-17 19:57:19 ncopa: https://tpaste.us/z5Za 2024-04-17 19:59:54 https://tpaste.us/Xyx1 2024-04-17 20:17:38 https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf/-/merge_requests/32 2024-04-17 20:24:16 So both runners have been registered, I've paused the runners on the pioneer boxes 2024-04-18 18:53:33 mps: bind fails to build due to new checks in abuild 2024-04-18 18:53:53 bind? 2024-04-18 18:54:01 sorry, that was not pushed by you 2024-04-18 18:54:09 got confused because you pushed linux starfive just after 2024-04-18 18:54:18 np 2024-04-19 19:40:49 Tried to upgrade t1, but the kernel crashes on boot "unable to handle page fault for address: 0000000000001118" :( 2024-04-19 19:42:27 https://tpaste.us/yYLn 2024-04-19 19:59:37 downgraded the kernel to the one from 3.18, which works 2024-04-21 20:45:40 caly said something about it earlier, but 404 https://build.alpinelinux.org/buildlogs/build-3-20-riscv64 2024-04-21 20:46:04 probably why it looks weird at https://build.alpinelinux.org/ 2024-04-21 20:46:39 are the logs lost then? 2024-04-21 20:46:58 cely* 2024-04-21 20:47:30 the logs are still on the builder 2024-04-21 21:21:08 good 2024-04-22 00:28:26 It seems build-3-20-armhf has been stuck on py3-pexpect since yesterday, and build-3-20-aarch64 and build-3-20-x86 on perl-server-starter 2024-04-22 08:00:41 im having a look at it 2024-04-22 08:02:39 building py3-pexpect passed locally. i killed python3 on build-3-20-armhf 2024-04-22 08:02:56 my guess is that the test is buggy and deadlocks 2024-04-22 08:03:35 running perl-server-starter locally now to test if it deadlocks 2024-04-22 08:08:50 ncopa: shall we quiclkly check the servers? 2024-04-22 08:08:59 sure! 2024-04-22 08:09:21 which servers? :) 2024-04-22 08:11:42 rv? 2024-04-22 08:11:53 i thought you wanted me to look 2024-04-22 08:11:56 yes 2024-04-22 08:12:04 i was not sure you talked about arm server or risc 2024-04-22 08:12:05 as you broken the network ;-) 2024-04-22 08:12:19 let me check 2024-04-22 08:19:08 build-3-20-riscv64 is acting strange too 2024-04-22 08:20:38 im investigating build-3-20-riscv64 now 2024-04-22 08:28:48 problem with build-3-20-riscv64 was that REPODEST was not set 2024-04-22 08:29:38 clandmeter: seems like you got it up again 2024-04-22 08:29:43 no 2024-04-22 08:29:47 bridge init fails 2024-04-22 08:30:01 any idea why? 2024-04-22 08:30:04 ip: ioctl 0x8913 failed: No such device 2024-04-22 08:30:30 found it 2024-04-22 08:30:36 ok? 2024-04-22 08:30:42 why is bridge not part of lxc-bridge?> 2024-04-22 08:30:43 we didnt install bridge-utils or similar? 2024-04-22 08:30:59 lxc-bridge? 2024-04-22 08:31:59 i dont know what was installed 2024-04-22 08:32:05 but bridge was missing 2024-04-22 08:32:45 lxc-bridge is what we would need for for bridging with lxc i guess 2024-04-22 08:34:10 crap 2024-04-22 08:34:20 so i rebooted it just to make sure it will come back online 2024-04-22 08:34:26 which of course didnt happen 2024-04-22 08:34:45 i am bumping to an issue i have had before 2024-04-22 08:35:04 after init of the gpu, the kernel just hangs and stops booting 2024-04-22 08:35:11 need to power toggle it 2024-04-22 08:35:57 those machines are difficult to get running properly 2024-04-22 08:37:01 reminds me, we need to add a patch for the kernel, so kernel does not says it has rvv 1.0 2024-04-22 08:38:09 i lost the patch i think 2024-04-22 08:39:59 ok its back now 2024-04-22 08:41:07 oh! and br0 is up as well 2024-04-22 08:41:09 wonderful 2024-04-22 08:41:27 what pulls in bridge? 2024-04-22 08:41:37 cause bridge-utils also doesnt do that 2024-04-22 08:42:03 ifupdown-ng? 2024-04-22 08:42:09 nope 2024-04-22 08:42:18 looks like only network-extras 2024-04-22 08:42:26 then there is nothing pulling it in 2024-04-22 08:42:36 or its an install-if 2024-04-22 08:42:46 i doubt 2024-04-22 08:43:09 so when setting up a bridge one always needs to manually install it 2024-04-22 08:43:19 i think so yes 2024-04-22 08:43:36 but im kinda surprised we actually need bridge-utils 2024-04-22 08:43:49 do we need it? 2024-04-22 08:44:20 i dont know? 2024-04-22 08:44:31 me neither 2024-04-22 08:44:35 :) 2024-04-22 08:44:36 but for sure bridge 2024-04-22 08:45:03 and i think we might want to add it to lxc-bridge also 2024-04-22 08:45:30 in this case we dont need lxc-bridge as that part is handled by the router 2024-04-22 08:45:48 oh, we have a package `bridge` 2024-04-22 08:45:54 yes 2024-04-22 08:45:57 the network scripts 2024-04-22 08:46:23 brctl 2024-04-22 08:46:46 looks like somebody is already looking at it 2024-04-22 08:47:39 bridge uses brctl, which is provided by both bridge-utils and busybox 2024-04-22 08:47:44 i dont think we need bridge-utils 2024-04-22 08:47:49 nod 2024-04-22 08:48:01 if we dont move it out someday 2024-04-22 08:48:26 lxc-bridge is only needed when using lxcbr0 with dnsmasq 2024-04-22 08:48:31 which we currently dont do 2024-04-22 08:48:40 thats what i just said :) 2024-04-22 08:49:13 so basically we only need to apk add bridge for basic bridge support 2024-04-22 08:51:22 bridge could be set using 'ip' tool 2024-04-22 08:51:54 yeah, thats why i asked if we needed bridge-utils 2024-04-22 08:51:59 the scripts are oldish 2024-04-22 08:52:04 i just had a delay on ps 2024-04-22 08:52:12 seems nvme related 2024-04-22 08:52:22 [Mon Apr 22 08:51:24 2024] nvme nvme0: I/O 0 QID 1 timeout, completion polled 2024-04-22 08:53:20 I've set not simple bridges on two routers with ip in script which run on boot 2024-04-22 09:56:59 mps: you did it with the ip util from bb? 2024-04-22 10:13:00 i guess not, it seem ip util from bb is limted 2024-04-22 10:21:13 clandmeter: I forgot but I think this could be also done bb ip 2024-04-22 10:21:40 by bb ip* 2024-04-22 10:22:26 i doubt it 2024-04-22 10:22:41 the adv bridge settings options are missing 2024-04-22 10:23:00 busybox ip link 2024-04-22 10:23:03 https://manpages.debian.org/testing/iproute2/ip-link.8.en.html#BRIDGE 2024-04-22 10:23:22 only basic bridge setup 2024-04-22 10:23:48 I will check when I have to reboot one of these routers 2024-04-22 10:24:03 for instance ageing_time 2024-04-22 10:24:08 its not in ip from bb 2024-04-22 10:24:18 but need the use brctl 2024-04-22 10:24:26 at least if i read the source correctly 2024-04-22 10:25:51 ncopa: so i think if we would want to convert the scripts to use ip util, we need to depend on iproute2 2024-04-22 10:26:09 yes, iproute2 pkg is more powerfull ofc 2024-04-22 10:43:24 i wonder if I should move build-3-20-riscv64 to the other machine 2024-04-22 11:42:55 ncopa: so the vector stuff is still causing issues? 2024-04-22 11:43:05 i see a lot of errors in ringbuffer 2024-04-22 11:43:22 i guess its vector related 2024-04-22 11:47:11 i think it does 2024-04-22 11:47:30 i saw a patch for kernel at some point but I dont know where it is 2024-04-22 11:47:42 yes i copied it to you i believe 2024-04-22 11:48:15 https://lore.kernel.org/linux-riscv/20240223-tidings-shabby-607f086cb4d7@spud/ 2024-04-22 12:01:15 thanks! 2024-04-22 14:50:32 It looks like build-3-20-x86 is still stuck on perl-server-starter 2024-04-22 14:58:29 perl-builder-blocker 2024-04-22 15:06:56 https://tpaste.us/vNnO 2024-04-22 15:39:57 whoops I forgot build-3-20-x86 2024-04-22 15:40:01 got distracted 2024-04-23 04:20:16 I think build-3-20-x86_64 has gotten stuck on py3-future 2024-04-23 07:04:56 im moving build-3-20-riscv64 to nld-bld-1 now 2024-04-23 07:23:25 build-3-20-riscv64 now runs on nld- bld-1 2024-04-23 08:18:33 ncopa: 👍 2024-04-23 15:43:12 build-3-20-armhf may be stuck on nqp (this usually builds in under a minute) 2024-04-24 05:38:17 I think build-3-20-armhf is definitely stuck on nqp, and maybe build-edge-riscv64 is stuck on openscad 2024-04-24 06:01:50 restarting it 2024-04-24 06:01:52 armhf 2024-04-24 07:32:53 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1359138#L57 look like on riscv64 CI python is not upgraded 2024-04-24 07:35:41 mps: the builder is still stuck 2024-04-24 07:35:55 aha, ok 2024-04-24 07:36:32 so python rebuild is not finished and uploaded 2024-04-24 08:34:13 ncopa: sorry to bother you because I know you have a lot of works these days. But I prepared qemu 9.0.0 MR !64761 to have it in 3.20-stable 2024-04-24 08:35:24 and while looked through aports git log for it I noticed that CVE-2021-20255.patch is probably not needed so I think we should remove it 2024-04-24 08:36:24 more is here https://bugzilla.redhat.com/show_bug.cgi?id=1930646 2024-04-24 08:42:43 mps: thank you! yes qemu 9 would be great to include 2024-04-24 08:43:28 'yes' means you agree to remove mentioned patch? 2024-04-24 08:44:07 i mean t it would be nice to have qemu 9 included in 3.20. re the patch, we need to investigate if its needed or not 2024-04-24 08:44:14 and I would appreciate if you could help with that? 2024-04-24 08:44:48 why was it added in the first place, was the issue reported upstream? is the issue resolved upstream? how did upstream resolve it? 2024-04-24 08:45:05 it is old from 2021 year, and qemu devs ignored it because it is low risk 2024-04-24 08:45:19 lets keep it then 2024-04-24 08:45:41 does redhat still use it? 2024-04-24 08:45:46 ok, anyway I don't see problem if we keep it 2024-04-24 08:45:49 maybe aske upstream what they think? 2024-04-24 08:46:05 thank you for following that up! 2024-04-24 08:46:06 maybe, I will ask later today 2024-04-24 08:47:01 'we don't like much patching' I remember old saying for alpine 2024-04-24 10:09:36 ncopa: it is not needed https://gitlab.com/qemu-project/qemu/-/commit/7d0fefdf81f5973334c344f6b8e1896c309dff66 2024-04-24 10:09:49 this is merged with qemu 8.2.0 2024-04-24 10:10:14 very nice. remove the patch and add link in commit message 2024-04-24 10:10:28 good job! 2024-04-24 10:10:31 ok 2024-04-24 10:10:46 feels good to delete patches, doesnt it :) 2024-04-24 10:10:59 qemu devs confirmed this, it is not my 'discovery' 2024-04-24 10:11:14 ncopa: yes, always :-) 2024-04-24 10:11:22 you did the job asking qemu devs 2024-04-24 10:11:27 and followed it up 2024-04-24 10:12:14 right, my 'grain of salt' to make alpine soup more tasty 2024-04-24 10:17:44 its delicious .) 2024-04-24 10:18:20 ;-) 2024-04-24 10:21:10 I have question, does anyone work on telegram-desktop, it is outdated. It is not problem for me because I build latest versions regularly for me on my machines. just curious 2024-04-24 10:23:16 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/64569 2024-04-24 10:23:50 ikke: ah, ok 2024-04-24 13:05:39 404 https://build.alpinelinux.org/buildlogs/build-3-20-armhf 2024-04-24 13:26:50 omni: there was a config error. should be fixed now 2024-04-24 16:03:45 do the logs for builds that where completed before the directories where created need to be manually copied from the build servers? 2024-04-24 16:04:43 omni: probably. we do have a sync job, but I don't think that has been installed on all builders yet 2024-04-24 16:06:53 saw that there is only buildlogs/build-3-20-armhf/main/postgresql16/ in main/, possibly some missing for build-3-20-riscv64/main/ too? since that too was added later, right? 2024-04-24 16:07:05 yeah 2024-04-24 16:07:20 Will look at that later 2024-04-24 16:55:44 can I upload to https://dev.alpinelinux.org/archive/qt5-qtwebengine/ or could anyone do that for me? 2024-04-24 16:56:28 I'd like to have https://chromium.googlesource.com/catapult/+archive/13025491e512e6e7b4c7fca376267fb82acad09b.tar.gz there for !64367 2024-04-24 16:59:39 qt5-qtwebengine currently doesn't build with python 3.12 2024-04-25 10:18:07 is there heavy load on the ppc64le CI builder? 2024-04-25 10:46:22 There is one job running 2024-04-25 10:51:35 ok, !64840 is taking a very long time to build openjdk11, it took ten minutes on ppc64le for 3.18-stable and 3.19-stable 2024-04-25 16:16:16 we will get problems with disk space 2024-04-25 16:16:32 yes 2024-04-25 16:16:45 so should we start removing community from old builders? 2024-04-25 16:17:12 i think we should archive some old builders 2024-04-25 16:23:35 most old builders are <10G, so would not add up to a lot 2024-04-26 00:11:19 Hmm 2024-04-26 05:03:34 sgp1.t1.alpinelinux.org is out of date 2024-04-26 07:07:57 clandmeter: I switched sgp.t1.a.o to mirror from nld.t1.a.o because syncing with dl-master.a.o takes too long 2024-04-26 12:12:27 ncopa: k0sctl apply fails to install on an alpine linux system because /etc/machine-id or /var/lib/dbus/machine-id does not exist 2024-04-27 01:33:55 mps: https://build.alpinelinux.org/buildlogs/build-3-20-x86_64/community/bcachefs-tools/bcachefs-tools-1.3.3-r0.log 2024-04-27 01:34:04 It seems the source URL is no longer valid 2024-04-27 01:35:39 The build log shows "bad address", but when i visit it in browser, it shows "unsupported snapshot format" 2024-04-27 17:16:36 celie: I have no idea why this happens. this plg is not good one to maintain 2024-04-27 21:54:20 i have no idea how long i was gone from here lol 2024-04-27 21:54:21 but also 2024-04-27 21:54:23 ikke: mkdir: can't create directory '/builds/alpine/aports/community/audacity/src': No space left on device 2024-04-27 21:54:32 armhf CI 2024-04-27 21:54:33 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1364055 2024-04-27 22:01:27 ptrc: fixed 2024-04-27 22:01:32 thanks ^^ 2024-04-28 09:51:34 are the builders and the CI using different riscv64 hardware? 2024-04-28 09:51:59 because on the CI I sometimes see "illegal instruction" faults in the riscv64 chez-scheme test suite, but does don't seem to happen on the builders 2024-04-28 09:52:28 nmeum: I think hardware is same, Pioneer V 2024-04-28 09:52:28 so my current guess is that the CI and the builders support different riscv64 extensions or something? 2024-04-28 09:52:40 hm, interessting… 2024-04-28 09:52:52 maybe kernels or toolchain are different 2024-04-28 11:41:22 maybe CI was switched back to emulated when one of the pioneers wasn't available 2024-04-28 12:01:05 omni: oh, looks like you are right 2024-04-28 12:45:18 omni: It's on scaleway 2024-04-28 12:45:26 Not emulated 2024-04-28 22:59:23 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65004#note_400062 2024-04-28 23:52:58 I think build-3-20-ppc64le is stuck on keycloak-config-cli 2024-04-29 09:55:57 Oof 2024-04-29 09:56:04 ncopa: ^ 2024-04-29 09:58:04 alright... 2024-04-29 10:00:16 we store buildlogs other place, right? 2024-04-29 10:12:00 im copying out build-3-?-x86 to a local disk here now 2024-04-29 10:35:00 ncopa: yes. deu5 (distfiles.a.o) 2024-04-29 10:35:21 but for x86, not all logs were synced due to config issue, so we need to make sure they are synced before removing 2024-04-29 14:00:24 i am deleteing build-3-[0-9]-x86 2024-04-29 14:00:28 i have backed them up 2024-04-29 14:19:50 Alright 2024-04-29 17:12:34 ikke: is it only the riscv643 CI that is running on scaleway or are the builders also using that? 2024-04-29 17:13:31 only CI 2024-04-29 17:14:58 ah, that would explain why I only see the illegal instruction error on the CI 2024-04-29 17:15:10 do you, by any chance, know what hardware scaleway is using? 2024-04-29 17:17:19 isa : rv64imafdcvsu 2024-04-29 17:17:35 mmu : sv39 2024-04-29 17:18:53 it seems there are using a T-Head 1520 SoC 2024-04-29 17:21:14 community/highway tests gives (ILLEGAL) errors on the pioneer machine 2024-04-29 17:23:00 it is due to RVV 1.0 use 2024-04-30 06:10:03 morning! whats up with the x86_64 CI? 2024-04-30 06:33:31 where runs the x86_64 CI? 2024-04-30 06:40:19 I did a `docker system prune` on the x86_64 ci machine 2024-04-30 07:19:44 👍 2024-04-30 07:20:11 I need to increase the frequency for the scheduled job that does that 2024-04-30 07:29:37 looks like it runs daily? 2024-04-30 07:30:12 oh... looks like it is supposed to run daily, but cron does not run 2024-04-30 07:31:22 cron runs now 2024-04-30 07:41:16 Thanks!