2024-07-01 07:30:28 ikke: are all those docker compose services running? 2024-07-01 07:30:38 gbr2-dev1 2024-07-01 07:30:45 i guess we could cleanup some stuff 2024-07-01 07:58:28 going to upgrade thelounge 2024-07-01 08:33:02 ikke: there are many defunct curl processes on this host 2024-07-01 08:33:56 and there were 2 mqtt-publish processes taking a lot of cpu, no idea what the reason was. 2024-07-01 08:34:01 I killed them 2024-07-01 08:34:52 aports-turbo was also misbehaving (due to the permission issue) which was also using cpu and bandwidth 2024-07-01 08:35:59 i upgraded thelounge which should vacuum the db's 2024-07-01 08:36:10 i think this is the reason node is taking a lot of cpu atm 2024-07-01 08:36:24 but if this does not fix later, we need to look at it 2024-07-01 08:37:05 clandmeter: thanks 2024-07-01 08:38:02 and i guess we could gzip the current txt logs 2024-07-01 08:41:11 interesting, now it takes 20G instead of 18 heh 2024-07-01 10:17:41 lol 2024-07-01 10:19:29 clandmeter: Apparently something started doing periodic requests to gitlab 2024-07-01 10:21:09 https://snipboard.io/GJz8ib.jpg 2024-07-01 10:22:40 ikke: I also moved data to the compose dir for thelounge 2024-07-01 10:22:52 ok 2024-07-01 10:22:52 the seperation is confusing 2024-07-03 14:20:29 ncopa: et all, I'm using !67387 for three weeks and didn't noticed any proble 2024-07-03 14:21:12 problem* 2024-07-04 07:38:16 clandmeter: ^ 2024-07-04 11:35:05 > 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 is still doesnt show 2024-07-04 11:35:35 it* 2024-07-04 12:34:29 raspbeguy: it is still erroring out 2024-07-04 12:35:01 can we (or can I) do something about it? 2024-07-04 12:35:15 looking 2024-07-04 13:02:29 and having phone calls at at the same time 2024-07-04 13:10:12 ok thanks πŸ™‚ 2024-07-04 13:10:28 raspbeguy: i did add the country last time around 2024-07-04 13:10:38 I dont see any obvious issue 2024-07-04 13:11:53 what do you mean? 2024-07-04 13:12:12 https://gitlab.alpinelinux.org/alpine/infra/mirrors/-/commit/335f99c88ec0fc37e4a48e8345eba457acd8dc89 2024-07-04 13:13:23 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 also adding the country didn't fix the issue 2024-07-05 18:48:40 ikke: iirc you are programming with go lang? 2024-07-05 18:48:50 yes 2024-07-05 18:49:02 nice 2024-07-05 18:49:29 do you know for good guide about using standard crypto library 2024-07-05 18:49:58 (I have to program in go again after about 8 years) 2024-07-05 18:50:13 No, nothing more than the standard documentation 2024-07-05 18:50:35 heh, I wouldn't call it documentation :) 2024-07-05 18:50:39 Some posts from the maintainer: https://words.filippo.io/ 2024-07-05 18:51:19 aha thanks, will read, maybe could be good starting point 2024-07-06 09:36:36 algitbot: retry 3.20-stable 2024-07-06 09:38:51 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 Access tokens are set to expire, maximum of a year 2024-07-06 13:36:14 so I have to learn something more and useless 2024-07-06 16:14:03 You would have already created that key before 2024-07-06 16:38:20 ikke: I did long ago. and don't understand why it ask me for it again 2024-07-06 16:38:46 ACTION was one of the first gitlab.a.o user 2024-07-06 16:56:45 I must be stupid but I don't understand what I have to do 2024-07-06 17:14:42 If you don't use it, you don't need to do anything 2024-07-06 17:15:38 I think I use it because I set 2FA long ago 2024-07-06 17:17:37 gitlab shows 'in 6 days' in Expires column 2024-07-06 17:22:13 Has nothing to do with 2fa 2024-07-06 17:23:11 ok, I will not annoy you more, lets wait and see what will happen when it expires 2024-07-06 17:23:47 You can use it to fetch/push via https or to authenticate against the API 2024-07-06 17:25:24 If I couldn't use gitlab.a.o after this then I will have looooong vacation :) 2024-07-08 06:38:30 clandmeter: can you check that box? 2024-07-08 07:11:27 ikke: rebooted both, seems to be online again. 2024-07-08 07:11:44 but nvme is still an issue 2024-07-08 07:21:14 seems like build-edge-riscv64 was not configured to autostart. I have fixed that now 2024-07-08 07:24:00 ncopa: there is a new branch for sophgo 2024-07-08 07:24:03 https://github.com/sophgo/linux-riscv/commits/sg2042-dev-6.6-acpi/ 2024-07-08 08:44:44 wanna give it a test run? I can try build a new kernel this week 2024-07-08 11:34:48 im here so i can support 2024-07-08 11:35:09 just need to make sure i have rescue usb 2024-07-08 12:06:39 i dont think i will have time to work on it today. maybe tomorrow 2024-07-09 08:02:44 Hi guys, been a while, hope everything still running 2024-07-09 08:14:24 tmhoang: \o 2024-07-09 08:37:45 hi tmhoang 2024-07-09 08:37:49 ltns 2024-07-09 09:17:17 clandmeter: Would you have an opportunity to check why otlabs is not receiving notification e-mails from gitlab? 2024-07-09 09:17:41 what is otlabs? 2024-07-09 09:18:35 a user 2024-07-09 09:19:30 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68946#note_419750 2024-07-09 09:19:54 ok checking 2024-07-09 09:21:03 he is using gmail 2024-07-09 09:25:26 Maybe ask him to verify they're not ending up in his spam box 2024-07-09 09:25:44 looks like our SPF and DKIM are not working 2024-07-09 09:26:41 are we sending out with domain gitlab.alpinelinux.org ? 2024-07-09 09:27:19 clandmeter: ah, it's something I changed in the config but not yet active 2024-07-09 09:27:20 looks like it 2024-07-09 09:27:36 It used to be gitlab@alpinelinux.org 2024-07-09 09:27:39 aha 2024-07-09 09:27:54 so dkim is also failing 2024-07-09 09:28:09 which is setup in rspamd 2024-07-09 09:28:22 My experience with dkim is basically 0 2024-07-09 09:28:25 why did you change the domain? 2024-07-09 09:28:37 dkim just signs the mail 2024-07-09 09:28:45 yes, I understand the concept 2024-07-09 09:28:55 so we have a signature for alpinelinux.org 2024-07-09 09:29:02 but i guess not for gitlab.a.o 2024-07-09 09:29:26 i guess we can fix SPF first 2024-07-09 09:29:54 clandmeter: my spam filter flagged e-mails from gitlab to a alpinelinux.org address 2024-07-09 09:30:36 so your idea is to seperate the domains to prevent spam records? 2024-07-09 09:41:43 Either way is fine for me 2024-07-09 09:44:13 rspamd flags it as FORGED_RECIPIENTS 2024-07-09 09:44:37 dkim? 2024-07-09 09:45:07 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 i just added this 2024-07-09 09:45:13 No, I think a discrapency between the envelope address and the FROM address 2024-07-09 09:45:17 its the same as main tld 2024-07-09 09:45:24 but for gitlab subdomain 2024-07-09 09:46:14 probably the first ip can be removed 2024-07-09 09:47:13 The records are managed with terraform 2024-07-09 09:47:39 oh i forgot 2024-07-09 09:50:33 looks like not all of them 2024-07-09 09:51:44 https://gitlab.alpinelinux.org/alpine/infra/linode-tf/-/blob/master/domains_mail.tf?ref_type=heads#L2 2024-07-09 11:08:35 ikke: im not sure how to handle it with terraform, so i will add it manually for now. 2024-07-09 11:47:07 ikke: i guess the switch of domain will also break ppl's filters 2024-07-09 11:58:31 ikke: the reply to domain is still alpinelinux.org 2024-07-09 13:55:31 tmhoang: I was thinking of updating the s390x machines now 2024-07-09 14:00:28 tmhoang: I'm upgrading 148.100.88.62 to 3.20 2024-07-09 14:03:43 and it was successfully rebooted 2024-07-09 14:03:55 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 I rebooted .88.57 now 2024-07-09 14:12:49 and its back 2024-07-09 14:15:38 ths s390x machines are successfully upgraded to alpine v3.20 2024-07-09 14:26:55 \o/ 2024-07-09 14:40:35 ncopa: thanks so much 2024-07-09 14:40:59 I'm always afraid these machines never come back after an upgrade 2024-07-09 14:55:22 ncopa, ikke: Thanks a lot for keeping those running for years 2024-07-09 14:56:21 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 ok, good to know 2024-07-09 15:25:15 what is the appropiate action for spam bots in gitlab? delete user? 2024-07-09 15:25:35 do I need to manually delete the content or will it be deleted when deleting the user? 2024-07-09 15:34:23 yeah, delete user 2024-07-09 15:34:26 and latter 2024-07-09 15:34:35 content gets either removed or transferred to a "ghost user" 2024-07-09 16:16:33 ncopa: I regularly delete these spam bots, there is a button to remove it with all content 2024-07-10 12:23:16 I managed to delete the user, but the content remains: https://gitlab.alpinelinux.org/-/snippets/1150#note_413302 2024-07-10 12:23:36 and I am not able to delete the content either? 2024-07-10 12:46:32 Did you use 'Delete user and contributions'? 2024-07-10 17:13:27 only delete user. i didnt see any "delete user and contributions" 2024-07-10 18:25:07 https://about.gitlab.com/releases/2024/07/10/patch-release-gitlab-17-1-2-released 2024-07-10 18:25:57 The new version is already being built 2024-07-10 19:36:10 gitlab has been upgraded 2024-07-11 07:00:31 ikke: you are back alraedy? 2024-07-11 07:24:50 Not yet 2024-07-11 19:56:08 my lxx on pioneer is not accessible again 2024-07-11 19:58:46 lxc* 2024-07-11 20:20:50 algitbot: retry master 2024-07-12 06:43:36 mps: it should be back now 2024-07-12 06:43:50 it didnt start up after last reboot for some reason 2024-07-12 06:54:18 ncopa: thanks 2024-07-12 07:23:13 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 ncopa: happened last time as well 2024-07-12 18:41:29 fossdd: Are you still using ^ 2024-07-12 18:55:14 oh no lol you can remove him 2024-07-12 18:55:32 not at the computer atm 2024-07-12 18:55:42 poof 2024-07-12 19:04:55 thx 2024-07-13 21:08:25 mps: could you take a look at !61380? 2024-07-17 16:52:04 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 nu_: Wondering, how is it going with our matrix setup? 2024-07-17 21:13:47 i was gonna ask the same thing, because of https://gitlab.alpinelinux.org/alpine/aports/-/commit/5a3d8fe0ca545a5fda8ec42e9b21728b62074ab0 2024-07-18 06:50:46 sry >< i've been very effective at inventing distractions 2024-07-18 07:00:43 There are plenty of distractions for sure 2024-07-18 07:00:54 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 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 cool 2024-07-21 07:34:44 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 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 aha good catch 2024-07-21 10:17:23 but its weird they dont provide it 2024-07-21 10:17:36 s/prive/provide 2024-07-21 10:18:30 so we need an alternative way to see how old it is 2024-07-21 10:18:44 or just skip them 2024-07-21 10:19:06 i actually looked for the issue few times but couldnt find it problem 2024-07-21 10:19:12 -it 2024-07-21 10:21:19 I found it by changing the cqueue loop with a normal function 2024-07-21 10:21:35 and removing all mirrors except dl-cdn and ovh 2024-07-21 10:21:54 That gave me a stack trace that pointed to the issue 2024-07-21 10:22:26 i guess they do provide etag 2024-07-21 10:22:55 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 i know 2024-07-21 10:23:37 < Etag: "669c1ffc-7387d" 2024-07-21 10:23:38 but they will consider etag is mandory for caching 2024-07-21 10:23:46 sorry, that was from dl-cdn 2024-07-21 10:23:47 mandatory.. 2024-07-21 10:23:54 no etag 2024-07-21 10:24:03 not? 2024-07-21 10:24:12 no 2024-07-21 10:24:39 we could email them and point it out 2024-07-21 10:24:44 https://tpaste.us/ogRn 2024-07-21 10:25:10 they do have age 2024-07-21 10:25:39 but thats kind of ueseless anyway 2024-07-21 10:26:13 i guess we can remove this mirror and report it upstream 2024-07-21 10:26:44 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 It should at least no fail completely if there is a mirror without it 2024-07-21 10:30:40 So I'd say log a warning, don't show status 2024-07-21 10:30:54 And then separately we could report it 2024-07-21 10:34:16 πŸ‘ 2024-07-23 11:38:49 I have powered off nld8-dev1, and will power off nld9-dev1 in a bit 2024-07-23 18:31:52 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 ikke: new images should all be queued 2024-07-23 19:05:11 Will sync it in a bit 2024-07-23 19:12:27 tomalok: syncing 3.20 now 2024-07-23 19:21:46 syncing 3.19 2024-07-23 19:58:33 3.18 and 3.17 have been synced as well 2024-07-23 20:30:14 ikke: thanks, here's https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/81 2024-07-23 20:34:58 tomalok: pushed 2024-07-23 20:35:08 / published 2024-07-23 21:03:52 ikke ty! 2024-07-23 21:07:56 for those who use alpine on apple silicon with new kernel hwmon works 2024-07-23 22:37:06 ikke: thanks. Will forward to the right guy 2024-07-23 22:37:06 > 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 But I can't see this header on https://dl-cdn.alpinelinux.org/alpine/ 2024-07-24 04:26:48 raspbeguy: https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz has it 2024-07-24 06:53:03 src url for email is suspicious http://www.cleancode.org/projects/email 2024-07-24 07:17:05 do we still need lxcfs in aports? 2024-07-24 07:17:20 s/aports/alpine/ 2024-07-24 10:19:55 mps: my browser even blocks it. Apparently we put the source itself on dev.a.o 2024-07-24 10:20:58 makes sense, imo 2024-07-24 10:52:28 clandmeter: can you take a look at the pioneer boxes? 2024-07-24 11:39:35 ikke: they both go offline at the same time? 2024-07-24 11:59:38 riscv64 hang? 2024-07-24 11:59:59 riscv64 CI* 2024-07-24 12:01:24 yes i killed them 2024-07-24 12:01:27 restarting now 2024-07-24 12:01:44 they are both behind the same wireless socket 2024-07-24 12:01:56 so if i want to reboot them, its all or nothing :) 2024-07-24 12:18:16 ncopa: ping 2024-07-24 12:18:29 the kernel is still troubeling on one of the rv boxes 2024-07-24 12:18:44 nld-bld-2 2024-07-24 12:25:49 ok. maybe we should try the 6.6 kernel? 2024-07-24 12:26:03 but looking at the git log, i dont really have any high expectations 2024-07-24 12:34:01 yeah 2024-07-24 12:34:04 me neither 2024-07-24 12:34:13 i just wonder why there is a diff between the 2 boxes 2024-07-24 18:28:43 so, pioneers are not up or devs LXCs not started? 2024-07-24 18:30:03 The one where your container is located is working, but containers stopped 2024-07-24 18:30:09 something prevents them from automatically starting 2024-07-24 18:30:56 could someone start it 'by hand' 2024-07-24 18:31:13 someone is ikke ofc, ;-) 2024-07-24 18:31:28 I did start it, but for some reason the containers are not receiving an ip address yet 2024-07-24 18:34:02 Ok, I found clandmeters previous fix, now it has an ip 2024-07-24 18:35:31 ping still doesn't work 2024-07-24 18:38:41 should work now 2024-07-24 18:41:47 works. thanks 2024-07-24 18:42:11 iptables -P FORWARD ACCEPT :P 2024-07-24 18:45:19 heh, so simple 2024-07-24 18:45:49 interesting, still iptables? no nft 2024-07-24 18:46:10 We still use awall, which only has iptables support 2024-07-24 18:52:12 riscv64 builder didn't start linux-edge build 2024-07-24 18:52:44 the edge builder is on the other host that is currently not working 2024-07-24 18:52:53 aha, ok 2024-07-24 18:59:08 i will look at it again tomorrow 2024-07-24 18:59:20 its just weird 2024-07-25 07:43:59 ncopa: i tried to build 6.6 again 2024-07-25 07:44:02 for rv 2024-07-25 07:44:16 according to upstream we did not apply the patches 2024-07-25 07:44:27 but 6.6 fails for me with current config 2024-07-25 07:45:18 https://github.com/sophgo/linux-riscv/issues/117#issuecomment-2249256370 2024-07-25 10:29:00 ncopa: if you can build the latest 6.6 or so, i can try to update it again. 2024-07-25 10:32:51 ok. I 'll have a look at it 2024-07-25 10:42:06 the riscv64 machine nld-bld-2 is down? 2024-07-25 10:42:17 ssh: connect to host 172.16.30.3 port 22: Connection refused 2024-07-25 10:43:12 yes 2024-07-25 10:43:19 the other one is running though 2024-07-25 10:46:12 The kernel seems to be running though since it responds to ping 2024-07-25 11:19:16 Yes it’s known 2024-07-25 11:39:24 ikke: we did not add the pioneers to netbox? 2024-07-25 11:39:46 Don't think so yet 2024-07-26 09:38:29 ncopa: will you build a new kernel? 2024-07-26 09:38:50 or should i try the one in our repo current? 2024-07-26 09:38:56 currently* 2024-07-26 13:25:36 im AFK til tuesday 2024-07-26 13:31:30 Enjoy 2024-07-29 06:37:51 (I feel that the alpine ruined more with a lot of newcomers) 2024-07-29 09:44:49 nld-bld-2 [~]# uname -a 2024-07-29 09:44:49 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 clandmeter: did that kernel crash, or did you upgrade to that kernel? 2024-07-29 10:56:30 not sure i understand the quiestion 2024-07-29 10:56:47 but i build a new kernel from the latest sources for 6.1 2024-07-29 10:56:54 and installed it and it booted now 2024-07-29 11:00:54 so the latter I suppose, upgraded to that kernel you mention 2024-07-29 11:01:06 question was related also to bld-2 being unreachable 2024-07-29 11:05:30 the kernel was crashing and the host is updated 2024-07-29 11:05:42 even you can ping, the console was unresponsive 2024-07-29 11:05:57 this kernel does not show an error on boot 2024-07-29 11:06:11 i wonder if the kernel ncopa build is faulty 2024-07-29 11:06:25 upstream mentions it still has the bad commits 2024-07-29 11:07:01 ncopa also upgraded it to .90 which upstream has not done yet, maybe for a reason. 2024-07-30 07:37:12 riscv64 comments from alice https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69311#note_424042 2024-07-30 07:37:18 what is the status on that? 2024-07-30 07:51:11 !69311 2024-07-30 07:51:34 omni: i commented 2024-07-30 07:52:41 thanks 2024-07-30 10:26:49 note that we have 2 ci servers on scaleway as well 2024-07-30 10:35:48 ikke: weirdly my runner is still not showing me version and host 2024-07-30 10:36:20 and we only have one active on scaleway it seems 2024-07-30 10:36:24 one is paused 2024-07-30 10:39:17 It does show it under Runners > details 2024-07-30 10:41:06 I've set a description now 2024-07-30 10:42:37 ah its just a description which is manual? 2024-07-30 10:42:46 or it was automatic previously 2024-07-30 10:44:06 Previously it was provided when registering 2024-07-30 10:44:14 in the new flow, you have to provide it in advance 2024-07-30 10:44:45 nod 2024-07-30 10:45:34 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 ikke: is that needed? 2024-07-30 10:55:11 The kernel cmdline? 2024-07-30 10:55:14 yes 2024-07-30 10:55:26 i think its pioneer only 2024-07-30 10:55:29 ah ok 2024-07-30 10:55:49 Wasn't sure 2024-07-30 10:56:00 as the cpu says it supports it but it actually only supports the older version 2024-07-30 10:56:06 yeah 2024-07-30 10:56:17 So the segfault (signal 11) is unrelated 2024-07-30 10:56:40 without knowing what it relates to i dont know 2024-07-30 10:57:45 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 Logs don't go back that dar 2024-07-30 11:00:05 far 2024-07-30 11:00:22 for the builder? 2024-07-30 11:00:33 or ci? 2024-07-30 11:00:54 dmesg logs on the host 2024-07-30 11:01:26 are you checking builder or ci? 2024-07-30 11:02:49 ah they both run ci 2024-07-30 11:03:03 yes 2024-07-30 11:03:59 but we can check CI 2024-07-30 11:04:10 anything related with QT 2024-07-30 11:04:16 which has failed 2024-07-30 11:11:15 im checking py3-qt6 2024-07-30 11:14:42 thanks 2024-07-31 11:28:41 ikke: we need to check what the security implications are when disabling seccomp 2024-07-31 11:37:16 https://gitlab.alpinelinux.org/alpine/infra/infra/-/issues/10828 2024-07-31 11:42:59 Probably should only enable the ones that are causing issues at the moment rather than disabling everything 2024-07-31 11:44:36 #16181 2024-07-31 11:47:28 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 ok i referred the issue 2024-07-31 15:41:53 che-bld-1 is unreachable 2024-07-31 15:43:59 nu_: We can no longer reach our build host 2024-07-31 15:49:38 and we can no longer reach nu_ :) 2024-07-31 15:50:46 I have a feeling that is related 2024-07-31 15:53:06 ok, it's back 2024-07-31 15:55:08 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 My impression from reading the GCC bug report, is that the recommendation is to just disable quadmath support 2024-07-31 15:59:05 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 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 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 mick_ibm: Yes, i didn't change any configure flags for gcc14 2024-07-31 16:40:28 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 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