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_Tǅ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