2024-07-01 07:30:28 <clandmeter> ikke: are all those docker compose services running?
2024-07-01 07:30:38 <clandmeter> gbr2-dev1
2024-07-01 07:30:45 <clandmeter> i guess we could cleanup some stuff
2024-07-01 07:58:28 <clandmeter> going to upgrade thelounge 
2024-07-01 08:33:02 <clandmeter> ikke: there are many defunct curl processes on this host
2024-07-01 08:33:56 <clandmeter> and there were 2 mqtt-publish processes taking a lot of cpu, no idea what the reason was.
2024-07-01 08:34:01 <clandmeter> I killed them
2024-07-01 08:34:52 <ikke> aports-turbo was also misbehaving (due to the permission issue) which was also using cpu and bandwidth 
2024-07-01 08:35:59 <clandmeter> i upgraded thelounge which should vacuum the db's 
2024-07-01 08:36:10 <clandmeter> i think this is the reason node is taking a lot of cpu atm
2024-07-01 08:36:24 <clandmeter> but if this does not fix later, we need to look at it
2024-07-01 08:37:05 <ikke> clandmeter: thanks
2024-07-01 08:38:02 <clandmeter> and i guess we could gzip the current txt logs
2024-07-01 08:41:11 <clandmeter> interesting, now it takes 20G instead of 18 heh
2024-07-01 10:17:41 <ikke> lol
2024-07-01 10:19:29 <ikke> clandmeter: Apparently something started doing periodic requests to gitlab
2024-07-01 10:21:09 <ikke> https://snipboard.io/GJz8ib.jpg
2024-07-01 10:22:40 <clandmeter> ikke: I also moved data to the compose dir for thelounge
2024-07-01 10:22:52 <ikke> ok
2024-07-01 10:22:52 <clandmeter> the seperation is confusing
2024-07-03 14:20:29 <mps> ncopa: et all, I'm using !67387 for three weeks and didn't noticed any proble
2024-07-03 14:21:12 <mps> problem*
2024-07-04 07:38:16 <ikke> clandmeter: ^
2024-07-04 11:35:05 <raspbeguy> > Hello, my MR adding new mirror has been merged 2 days ago, but it doesn't show on the mirror list https://gitlab.alpinelinux.org/alpine/infra/mirrors/-/merge_requests/10
2024-07-04 11:35:28 <raspbeguy> is still doesnt show
2024-07-04 11:35:35 <raspbeguy> it*
2024-07-04 12:34:29 <clandmeter> raspbeguy: it is still erroring out
2024-07-04 12:35:01 <raspbeguy> can we (or can I) do something about it?
2024-07-04 12:35:15 <clandmeter> looking
2024-07-04 13:02:29 <clandmeter> and having phone calls at at the same time
2024-07-04 13:10:12 <raspbeguy> ok thanks 🙂
2024-07-04 13:10:28 <clandmeter> raspbeguy: i did add the country last time around
2024-07-04 13:10:38 <clandmeter> I dont see any obvious issue
2024-07-04 13:11:53 <raspbeguy> what do you mean?
2024-07-04 13:12:12 <clandmeter> https://gitlab.alpinelinux.org/alpine/infra/mirrors/-/commit/335f99c88ec0fc37e4a48e8345eba457acd8dc89
2024-07-04 13:13:23 <raspbeguy> I didn't add the country because its georeplicated (france and canada), we have anycast dns so you get the right server for your location
2024-07-04 13:14:10 <raspbeguy> also adding the country didn't fix the issue
2024-07-05 18:48:40 <mps> ikke: iirc you are programming with go lang?
2024-07-05 18:48:50 <ikke> yes
2024-07-05 18:49:02 <mps> nice
2024-07-05 18:49:29 <mps> do you know for good guide about using standard crypto library
2024-07-05 18:49:58 <mps> (I have to program in go again after about 8 years)
2024-07-05 18:50:13 <ikke> No, nothing more than the standard documentation
2024-07-05 18:50:35 <mps> heh, I wouldn't call it documentation :)
2024-07-05 18:50:39 <ikke> Some posts from the maintainer: https://words.filippo.io/
2024-07-05 18:51:19 <mps> aha thanks, will read, maybe could be good starting point
2024-07-06 09:36:36 <mps> algitbot: retry 3.20-stable
2024-07-06 09:38:51 <mps> I've got mail that I must regenerate access tokens for gitlab.a.o. Is this real or someone broke gitlab?
2024-07-06 13:30:30 <ikke> Access tokens are set to expire, maximum of a year
2024-07-06 13:36:14 <mps> so I have to learn something more and useless
2024-07-06 16:14:03 <ikke> You would have already created that key before
2024-07-06 16:38:20 <mps> ikke: I did long ago. and don't understand why it ask me for it again
2024-07-06 16:38:46 <mps> 
ACTION was one of the first gitlab.a.o user

2024-07-06 16:56:45 <mps> I must be stupid but I don't understand what I have to do
2024-07-06 17:14:42 <ikke> If you don't use it, you don't need to do anything
2024-07-06 17:15:38 <mps> I think I use it because I set 2FA long ago
2024-07-06 17:17:37 <mps> gitlab shows 'in 6 days' in Expires column
2024-07-06 17:22:13 <ikke> Has nothing to do with 2fa
2024-07-06 17:23:11 <mps> ok, I will not annoy you more, lets wait and see what will happen when it expires
2024-07-06 17:23:47 <ikke> You can use it to fetch/push via https or to authenticate against the API 
2024-07-06 17:25:24 <mps> If I couldn't use gitlab.a.o after this then I will have looooong vacation :)
2024-07-08 06:38:30 <ikke> clandmeter: can you check that box?
2024-07-08 07:11:27 <clandmeter> ikke: rebooted both, seems to be online again.
2024-07-08 07:11:44 <clandmeter> but nvme is still an issue
2024-07-08 07:21:14 <ncopa> seems like build-edge-riscv64 was not configured to autostart. I have fixed that now
2024-07-08 07:24:00 <clandmeter> ncopa: there is a new branch for sophgo
2024-07-08 07:24:03 <clandmeter> https://github.com/sophgo/linux-riscv/commits/sg2042-dev-6.6-acpi/
2024-07-08 08:44:44 <ncopa> wanna give it a test run? I can try build a new kernel this week
2024-07-08 11:34:48 <clandmeter> im here so i can support
2024-07-08 11:35:09 <clandmeter> just need to make sure i have rescue usb 
2024-07-08 12:06:39 <ncopa> i dont think i will have time to work on it today. maybe tomorrow
2024-07-09 08:02:44 <tmhoang> Hi guys, been a while, hope everything still running
2024-07-09 08:14:24 <mps> tmhoang: \o
2024-07-09 08:37:45 <clandmeter> hi tmhoang 
2024-07-09 08:37:49 <clandmeter> ltns
2024-07-09 09:17:17 <ikke> clandmeter: Would you have an opportunity to check why otlabs is not receiving notification e-mails from gitlab?
2024-07-09 09:17:41 <clandmeter> what is otlabs?
2024-07-09 09:18:35 <ikke> a user
2024-07-09 09:19:30 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68946#note_419750
2024-07-09 09:19:54 <clandmeter> ok checking
2024-07-09 09:21:03 <clandmeter> he is using gmail
2024-07-09 09:25:26 <ikke> Maybe ask him to verify they're not ending up in his spam box
2024-07-09 09:25:44 <clandmeter> looks like our SPF and DKIM are not working
2024-07-09 09:26:41 <clandmeter> are we sending out with domain gitlab.alpinelinux.org ?
2024-07-09 09:27:19 <ikke> clandmeter: ah, it's something I changed in the config but not yet active
2024-07-09 09:27:20 <clandmeter> looks like it
2024-07-09 09:27:36 <ikke> It used to be gitlab@alpinelinux.org
2024-07-09 09:27:39 <clandmeter> aha
2024-07-09 09:27:54 <clandmeter> so dkim is also failing
2024-07-09 09:28:09 <clandmeter> which is setup in rspamd
2024-07-09 09:28:22 <ikke> My experience with dkim is basically 0
2024-07-09 09:28:25 <clandmeter> why did you change the domain?
2024-07-09 09:28:37 <clandmeter> dkim just signs the mail
2024-07-09 09:28:45 <ikke> yes, I understand the concept
2024-07-09 09:28:55 <clandmeter> so we have a signature for alpinelinux.org
2024-07-09 09:29:02 <clandmeter> but i guess not for gitlab.a.o
2024-07-09 09:29:26 <clandmeter> i guess we can fix SPF first
2024-07-09 09:29:54 <ikke> clandmeter: my spam filter flagged e-mails from gitlab to a alpinelinux.org address
2024-07-09 09:30:36 <clandmeter> so your idea is to seperate the domains to prevent spam records?
2024-07-09 09:41:43 <ikke> Either way is fine for me
2024-07-09 09:44:13 <ikke> rspamd flags it as FORGED_RECIPIENTS
2024-07-09 09:44:37 <clandmeter> dkim?
2024-07-09 09:45:07 <clandmeter> gitlab	v=spf1 ip4:147.75.101.119 ip4:213.219.36.190 ip6:2a01:7e00:e000:2fc::20	1 hour
2024-07-09 09:45:11 <clandmeter> i just added this
2024-07-09 09:45:13 <ikke> No, I think a discrapency between the envelope address and the FROM address
2024-07-09 09:45:17 <clandmeter> its the same as main tld
2024-07-09 09:45:24 <clandmeter> but for gitlab subdomain
2024-07-09 09:46:14 <clandmeter> probably the first ip can be removed
2024-07-09 09:47:13 <ikke> The records are managed with terraform
2024-07-09 09:47:39 <clandmeter> oh i forgot
2024-07-09 09:50:33 <clandmeter> looks like not all of them 
2024-07-09 09:51:44 <ikke> https://gitlab.alpinelinux.org/alpine/infra/linode-tf/-/blob/master/domains_mail.tf?ref_type=heads#L2
2024-07-09 11:08:35 <clandmeter> ikke: im not sure how to handle it with terraform, so i will add it manually for now.
2024-07-09 11:47:07 <clandmeter> ikke: i guess the switch of domain will also break ppl's filters
2024-07-09 11:58:31 <clandmeter> ikke: the reply to domain is still alpinelinux.org
2024-07-09 13:55:31 <ncopa> tmhoang: I was thinking of updating the s390x machines now
2024-07-09 14:00:28 <ncopa> tmhoang: I'm upgrading 148.100.88.62 to 3.20
2024-07-09 14:03:43 <ncopa> and it was successfully rebooted
2024-07-09 14:03:55 <ncopa> Linux gitlab-runner-s390x 6.6.37-1-lts #2-Alpine SMP 2024-07-05 09:26:24 s390x Linux
2024-07-09 14:12:40 <ncopa> I rebooted .88.57 now
2024-07-09 14:12:49 <ncopa> and its back
2024-07-09 14:15:38 <ncopa> ths s390x machines are successfully upgraded to alpine v3.20
2024-07-09 14:26:55 <clandmeter> \o/
2024-07-09 14:40:35 <ikke> ncopa: thanks so much
2024-07-09 14:40:59 <ikke> I'm always afraid these machines never come back after an upgrade
2024-07-09 14:55:22 <tmhoang> ncopa, ikke: Thanks a lot for keeping those running for years
2024-07-09 14:56:21 <tmhoang> I'm very much confident it will boot back. I have upgrade my x86 alpine box from 3.15 - 17 - 18 - 20 via initramfs+sshd+luk2 sysroot, never had a problem  
2024-07-09 14:56:34 <ikke> ok, good to know
2024-07-09 15:25:15 <ncopa> what is the appropiate action for spam bots in gitlab? delete user?
2024-07-09 15:25:35 <ncopa> do I need to manually delete the content or will it be deleted when deleting the user?
2024-07-09 15:34:23 <ptrc> yeah, delete user
2024-07-09 15:34:26 <ptrc> and latter
2024-07-09 15:34:35 <ptrc> content gets either removed or transferred to a "ghost user"
2024-07-09 16:16:33 <ikke> ncopa: I regularly delete these spam bots, there is a button to remove it with all content
2024-07-10 12:23:16 <ncopa> I managed to delete the user, but the content remains: https://gitlab.alpinelinux.org/-/snippets/1150#note_413302
2024-07-10 12:23:36 <ncopa> and I am not able to delete the content either?
2024-07-10 12:46:32 <ikke> Did you use 'Delete user and contributions'?
2024-07-10 17:13:27 <ncopa> only delete user. i didnt see any "delete user and contributions"
2024-07-10 18:25:07 <ikke> https://about.gitlab.com/releases/2024/07/10/patch-release-gitlab-17-1-2-released
2024-07-10 18:25:57 <ikke> The new version is already being built
2024-07-10 19:36:10 <ikke> gitlab has been upgraded
2024-07-11 07:00:31 <clandmeter> ikke: you are back alraedy?
2024-07-11 07:24:50 <ikke> Not yet
2024-07-11 19:56:08 <mps> my lxx on pioneer is not accessible again
2024-07-11 19:58:46 <mps> lxc*
2024-07-11 20:20:50 <mps> algitbot: retry master
2024-07-12 06:43:36 <ncopa> mps: it should be back now
2024-07-12 06:43:50 <ncopa> it didnt start up after last reboot for some reason
2024-07-12 06:54:18 <mps> ncopa: thanks
2024-07-12 07:23:13 <mps> hwmon driver is added to asahi kernel and just in day when I'm packing things for travel to vacation, huh
2024-07-12 07:34:21 <ikke> ncopa: happened last time as well
2024-07-12 18:41:29 <ikke> fossdd: Are you still using ^
2024-07-12 18:55:14 <fossdd> oh no lol you can remove him
2024-07-12 18:55:32 <fossdd> not at the computer atm
2024-07-12 18:55:42 <ikke> poof
2024-07-12 19:04:55 <fossdd> thx
2024-07-13 21:08:25 <ikke> mps: could you take a look at !61380?
2024-07-17 16:52:04 <ncopa> i pushed aports-build / lua-aports with lua 5.4. I don't think there will be any issues, but if you see anything, please let me know
2024-07-17 21:11:12 <ikke> nu_: Wondering, how is it going with our matrix setup?
2024-07-17 21:13:47 <ptrc> i was gonna ask the same thing, because of https://gitlab.alpinelinux.org/alpine/aports/-/commit/5a3d8fe0ca545a5fda8ec42e9b21728b62074ab0
2024-07-18 06:50:46 <nu_> sry >< i've been very effective at inventing distractions
2024-07-18 07:00:43 <ikke> There are plenty of distractions for sure
2024-07-18 07:00:54 <nu_> on the flip side, i managed to quit my job that made me not want to touch computers after work, aaand i'll have a whole month in september to recover and to finish the setup :>
2024-07-18 07:02:19 <nu_> also i've sourced new sfp-s and cabled the mgmt port for the builder. i only need to setup vpn/routing to give you access
2024-07-18 07:02:59 <ikke> cool
2024-07-21 07:34:44 <ikke> raspbeguy: Found out why mirror-status has issues with OVH: it does not prive the last-modified header, and the mirror status page assumes it's present
2024-07-21 10:16:30 <ikke> clandmeter: it appears the generate-json.lua script does not get the status of any other mirror as well when this happens
2024-07-21 10:17:10 <clandmeter> aha good catch
2024-07-21 10:17:23 <clandmeter> but its weird they dont provide it
2024-07-21 10:17:36 <ikke> s/prive/provide
2024-07-21 10:18:30 <clandmeter> so we need an alternative way to see how old it is
2024-07-21 10:18:44 <clandmeter> or just skip them
2024-07-21 10:19:06 <clandmeter> i actually looked for the issue few times but couldnt find it problem
2024-07-21 10:19:12 <clandmeter> -it
2024-07-21 10:21:19 <ikke> I found it by changing the cqueue loop with a normal function
2024-07-21 10:21:35 <ikke> and removing all mirrors except dl-cdn and ovh
2024-07-21 10:21:54 <ikke> That gave me a stack trace that pointed to the issue
2024-07-21 10:22:26 <clandmeter> i guess they do provide etag
2024-07-21 10:22:55 <ikke> I think that won't suffice. It's not to determined whether  to fetch the repo, but to determine when the index as last modified to determine staleness
2024-07-21 10:23:22 <clandmeter> i know
2024-07-21 10:23:37 <ikke> < Etag: "669c1ffc-7387d"
2024-07-21 10:23:38 <clandmeter> but they will consider etag is mandory for caching 
2024-07-21 10:23:46 <ikke> sorry, that was from dl-cdn
2024-07-21 10:23:47 <clandmeter> mandatory..
2024-07-21 10:23:54 <ikke> no etag
2024-07-21 10:24:03 <clandmeter> not?
2024-07-21 10:24:12 <ikke> no
2024-07-21 10:24:39 <clandmeter> we could email them and point it out
2024-07-21 10:24:44 <ikke> https://tpaste.us/ogRn 
2024-07-21 10:25:10 <clandmeter> they do have age
2024-07-21 10:25:39 <clandmeter> but thats kind of ueseless anyway
2024-07-21 10:26:13 <clandmeter> i guess we can remove this mirror and report it upstream 
2024-07-21 10:26:44 <clandmeter> or do you want to add a feature to support mirrors without it, but then wihtout the status stuff?
2024-07-21 10:30:14 <ikke> It should at least no fail completely if there is a mirror without it
2024-07-21 10:30:40 <ikke> So I'd say log a warning, don't show  status
2024-07-21 10:30:54 <ikke> And then separately we could report it
2024-07-21 10:34:16 <clandmeter> 👍
2024-07-23 11:38:49 <ncopa> I have powered off nld8-dev1, and will power off nld9-dev1 in a bit
2024-07-23 18:31:52 <tomalok> ikke: going to release the new set of cloud images -- will let you know when they're all queued up
2024-07-23 18:42:19 <tomalok> ikke: new images should all be queued
2024-07-23 19:05:11 <ikke> Will sync it in a bit 
2024-07-23 19:12:27 <ikke> tomalok: syncing 3.20 now
2024-07-23 19:21:46 <ikke> syncing 3.19
2024-07-23 19:58:33 <ikke> 3.18 and 3.17 have been synced as well
2024-07-23 20:30:14 <tomalok> ikke: thanks, here's https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/81
2024-07-23 20:34:58 <ikke> tomalok: pushed
2024-07-23 20:35:08 <ikke> / published
2024-07-23 21:03:52 <tomalok> ikke ty!
2024-07-23 21:07:56 <mps> for those who use alpine on apple silicon with new kernel hwmon works
2024-07-23 22:37:06 <raspbeguy> ikke: thanks. Will forward to the right guy
2024-07-23 22:37:06 <raspbeguy> > raspbeguy: Found out why mirror-status has issues with OVH: it does not prive the last-modified header, and the mirror status page assumes it's present
2024-07-23 22:40:03 <raspbeguy> But I can't see this header on https://dl-cdn.alpinelinux.org/alpine/
2024-07-24 04:26:48 <ikke> raspbeguy: https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz has it
2024-07-24 06:53:03 <mps> src url for email is suspicious http://www.cleancode.org/projects/email
2024-07-24 07:17:05 <mps> do we still need lxcfs in aports?
2024-07-24 07:17:20 <mps> s/aports/alpine/
2024-07-24 10:19:55 <ikke> mps: my browser even blocks it. Apparently we put the source itself on dev.a.o
2024-07-24 10:20:58 <mps> makes sense, imo
2024-07-24 10:52:28 <ikke> clandmeter: can you take a look at the pioneer boxes?
2024-07-24 11:39:35 <clandmeter> ikke: they both go offline at the same time?
2024-07-24 11:59:38 <mps> riscv64 hang?
2024-07-24 11:59:59 <mps> riscv64 CI*
2024-07-24 12:01:24 <clandmeter> yes i killed them
2024-07-24 12:01:27 <clandmeter> restarting now
2024-07-24 12:01:44 <clandmeter> they are both behind the same wireless socket
2024-07-24 12:01:56 <clandmeter> so if i want to reboot them, its all or nothing :)
2024-07-24 12:18:16 <clandmeter> ncopa: ping
2024-07-24 12:18:29 <clandmeter> the kernel is still troubeling on one of the rv boxes
2024-07-24 12:18:44 <clandmeter> nld-bld-2
2024-07-24 12:25:49 <ncopa> ok. maybe we should try the 6.6 kernel?
2024-07-24 12:26:03 <ncopa> but looking at the git log, i dont really have any high expectations
2024-07-24 12:34:01 <clandmeter> yeah
2024-07-24 12:34:04 <clandmeter> me neither
2024-07-24 12:34:13 <clandmeter> i just wonder why there is a diff between the 2 boxes
2024-07-24 18:28:43 <mps> so, pioneers are not up or devs LXCs not started?
2024-07-24 18:30:03 <ikke> The one where your container is located is working, but containers stopped
2024-07-24 18:30:09 <ikke> something prevents them from automatically starting
2024-07-24 18:30:56 <mps> could someone start it 'by hand'
2024-07-24 18:31:13 <mps> someone is ikke ofc, ;-)
2024-07-24 18:31:28 <ikke> I did start it, but for some reason the containers are not receiving an ip address yet
2024-07-24 18:34:02 <ikke> Ok, I found clandmeters previous fix, now it has an ip
2024-07-24 18:35:31 <mps> ping still doesn't work
2024-07-24 18:38:41 <ikke> should work now
2024-07-24 18:41:47 <mps> works. thanks
2024-07-24 18:42:11 <ikke> iptables -P FORWARD ACCEPT :P
2024-07-24 18:45:19 <mps> heh, so simple
2024-07-24 18:45:49 <mps> interesting, still iptables? no nft
2024-07-24 18:46:10 <ikke> We still use awall, which only has iptables support
2024-07-24 18:52:12 <mps> riscv64 builder didn't start linux-edge build
2024-07-24 18:52:44 <ikke> the edge builder is on the other host that is currently not working
2024-07-24 18:52:53 <mps> aha, ok
2024-07-24 18:59:08 <clandmeter> i will look at it again tomorrow
2024-07-24 18:59:20 <clandmeter> its just weird
2024-07-25 07:43:59 <clandmeter> ncopa: i tried to build 6.6 again
2024-07-25 07:44:02 <clandmeter> for rv
2024-07-25 07:44:16 <clandmeter> according to upstream we did not apply the patches
2024-07-25 07:44:27 <clandmeter> but 6.6 fails for me with current config
2024-07-25 07:45:18 <clandmeter> https://github.com/sophgo/linux-riscv/issues/117#issuecomment-2249256370
2024-07-25 10:29:00 <clandmeter> ncopa: if  you can build the latest 6.6 or so, i can try to update it again.
2024-07-25 10:32:51 <ncopa> ok. I 'll have a look at it
2024-07-25 10:42:06 <ncopa> the riscv64 machine nld-bld-2 is down?
2024-07-25 10:42:17 <ncopa> ssh: connect to host 172.16.30.3 port 22: Connection refused
2024-07-25 10:43:12 <ikke> yes
2024-07-25 10:43:19 <ikke> the other one is running though
2024-07-25 10:46:12 <ikke> The kernel seems to be running though since it responds to ping
2024-07-25 11:19:16 <clandmeter> Yes it’s known
2024-07-25 11:39:24 <clandmeter> ikke: we did not add the pioneers to netbox?
2024-07-25 11:39:46 <ikke> Don't think so yet
2024-07-26 09:38:29 <clandmeter> ncopa: will you build a new kernel?
2024-07-26 09:38:50 <clandmeter> or should i try the one in our repo current?
2024-07-26 09:38:56 <clandmeter> currently*
2024-07-26 13:25:36 <ncopa> im AFK til tuesday
2024-07-26 13:31:30 <ikke> Enjoy
2024-07-29 06:37:51 <mps> <grumpy hat on> (I feel that the alpine ruined more with a lot of newcomers)
2024-07-29 09:44:49 <clandmeter> nld-bld-2 [~]# uname -a
2024-07-29 09:44:49 <clandmeter> Linux nld-bld-2 6.1.80-0-sophgo #1-Alpine SMP PREEMPT Mon, 29 Jul 2024 07:55:17 +0000 riscv64 GNU/Linux
2024-07-29 10:50:42 <ikke> clandmeter: did that kernel crash, or did you upgrade to that kernel?
2024-07-29 10:56:30 <clandmeter> not sure i understand the quiestion
2024-07-29 10:56:47 <clandmeter> but i build a new kernel from the latest sources for 6.1
2024-07-29 10:56:54 <clandmeter> and installed it and it booted now
2024-07-29 11:00:54 <ikke> so the latter I suppose, upgraded to that kernel you mention
2024-07-29 11:01:06 <ikke> question was related also to bld-2 being unreachable
2024-07-29 11:05:30 <clandmeter> the kernel was crashing and the host is updated
2024-07-29 11:05:42 <clandmeter> even you can ping, the console was unresponsive 
2024-07-29 11:05:57 <clandmeter> this kernel does not show an error on boot
2024-07-29 11:06:11 <clandmeter> i wonder if the kernel ncopa build is faulty 
2024-07-29 11:06:25 <clandmeter> upstream mentions it still has the bad commits
2024-07-29 11:07:01 <clandmeter> ncopa also upgraded it to .90 which upstream has not done yet, maybe for a reason. 
2024-07-30 07:37:12 <omni> riscv64 comments from alice https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69311#note_424042
2024-07-30 07:37:18 <omni> what is the status on that?
2024-07-30 07:51:11 <mps> !69311
2024-07-30 07:51:34 <clandmeter> omni: i commented
2024-07-30 07:52:41 <omni> thanks
2024-07-30 10:26:49 <ikke> note that we have 2 ci servers on scaleway as well
2024-07-30 10:35:48 <clandmeter> ikke: weirdly my runner is still not showing me version and host
2024-07-30 10:36:20 <clandmeter> and we only have one active on scaleway it seems
2024-07-30 10:36:24 <clandmeter> one is paused
2024-07-30 10:39:17 <ikke> It does show it under Runners > details
2024-07-30 10:41:06 <ikke> I've set a description now
2024-07-30 10:42:37 <clandmeter> ah its just a description which is manual?
2024-07-30 10:42:46 <clandmeter> or it was automatic previously
2024-07-30 10:44:06 <ikke> Previously it was provided when registering
2024-07-30 10:44:14 <ikke> in the new flow, you have to provide it in advance
2024-07-30 10:44:45 <clandmeter> nod
2024-07-30 10:45:34 <ikke> I can't find a way to modify the kernel cmdline on the scaleway servers, so I suppose ncopa needs to do that
2024-07-30 10:55:02 <clandmeter> ikke: is that needed?
2024-07-30 10:55:11 <ikke> The kernel cmdline?
2024-07-30 10:55:14 <clandmeter> yes
2024-07-30 10:55:26 <clandmeter> i think its pioneer only 
2024-07-30 10:55:29 <ikke> ah ok
2024-07-30 10:55:49 <ikke> Wasn't sure
2024-07-30 10:56:00 <clandmeter> as the cpu says it supports it but it actually only supports the older version
2024-07-30 10:56:06 <ikke> yeah
2024-07-30 10:56:17 <ikke> So the segfault (signal 11) is unrelated
2024-07-30 10:56:40 <clandmeter> without knowing what it relates to i dont know
2024-07-30 10:57:45 <clandmeter> if we can connect the date with the build, then we could exec it again and see where it fails
2024-07-30 11:00:03 <ikke> Logs don't go back that dar
2024-07-30 11:00:05 <ikke> far
2024-07-30 11:00:22 <clandmeter> for the builder?
2024-07-30 11:00:33 <clandmeter> or ci?
2024-07-30 11:00:54 <ikke> dmesg logs on the host
2024-07-30 11:01:26 <clandmeter> are you checking builder or ci?
2024-07-30 11:02:49 <clandmeter> ah they both run ci
2024-07-30 11:03:03 <ikke> yes
2024-07-30 11:03:59 <clandmeter> but we can check CI 
2024-07-30 11:04:10 <clandmeter> anything related with QT
2024-07-30 11:04:16 <clandmeter> which has failed
2024-07-30 11:11:15 <clandmeter> im checking py3-qt6
2024-07-30 11:14:42 <ikke> thanks
2024-07-31 11:28:41 <clandmeter> ikke: we need to check what the security implications are when disabling seccomp
2024-07-31 11:37:16 <clandmeter> https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10828
2024-07-31 11:42:59 <ikke> Probably should only enable the ones that are causing issues at the moment rather than disabling everything 
2024-07-31 11:44:36 <ikke> #16181
2024-07-31 11:47:28 <ikke> That mentions RISCV_FLUSH_ICACHE. The related docker issues imply this should have already been fixed in docker / runc, but it's apparently still causing issues for us
2024-07-31 11:56:46 <clandmeter> ok i referred the issue 
2024-07-31 15:41:53 <ikke> che-bld-1 is unreachable
2024-07-31 15:43:59 <ikke> nu_: We can no longer reach our build host
2024-07-31 15:49:38 <ncopa> and we can no longer reach nu_ :)
2024-07-31 15:50:46 <ikke> I have a feeling that is related
2024-07-31 15:53:06 <ikke> ok, it's back
2024-07-31 15:55:08 <celie> mick_ibm: Could i have your opinion on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116007 ? We are building gcc13 gfortran with quadmath support on ppc64le, but it seems that no longer builds with gcc14 (tried it out in !69862)
2024-07-31 15:56:47 <celie> My impression from reading the GCC bug report, is that the recommendation is to just disable quadmath support
2024-07-31 15:59:05 <celie> So, i would like to know if disabling quadmath is also what you recommend, or if there is another way to work around that "unable to emulate 'TF'" error
2024-07-31 16:16:17 <mick_ibm> and to clarify, gfortran was building successfully with gcc13 and quadmath support? no other specific ppc64le configure flags with previous gcc version builds?
2024-07-31 16:16:42 <mick_ibm> il bring it up with compilers team and get back to you but just wanna make sure i fully understand
2024-07-31 16:33:56 <celie> mick_ibm: Yes, i didn't change any configure flags for gcc14
2024-07-31 16:40:28 <celie> That is also observed in the GCC bug report, Comment 11: "the 13 branch is the last one that builds libquadmath without the compiler supporting TF mode emulation"
2024-07-31 16:43:23 <celie> So, this is a new requirement for GCC 14, which in turn needs something that musl doesn't support..probably we will end up just disabling quadmath