2024-08-01 04:35:32 ptrc: mqtt-exec process had crashed for some reason 2024-08-01 04:36:05 and continues to 2024-08-01 04:41:22 Ok, it's building now 2024-08-01 04:55:30 ptrc: it's building rust now 2024-08-01 06:34:42 ikke: it crashed again? 2024-08-01 06:37:49 iptables rule was missing 2024-08-01 06:37:57 We need to fix that 2024-08-01 06:46:48 im confused, mqtt-exec crashes due to iptables? 2024-08-01 06:52:44 It cannot connect to msg.a.o 2024-08-01 07:32:38 im working build-edge-x86 2024-08-01 07:35:48 Ok 2024-08-01 07:40:44 any opinion on this aport !69979 ? they just tag the develop branch weekly to release, when I was doing some aports I tried to focus on stable ones, so Im just not sure if is all right or not 2024-08-01 09:25:10 i wonder what to do with plasma-desktop on 32 bit arches 2024-08-01 09:25:12 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16330 2024-08-01 09:25:44 we could disable the failing test, but that is no good long-term solution 2024-08-01 09:26:08 it is also unclear if the problem is in qt6-qtbase or on plasma-desktop, or some other dependency 2024-08-01 09:28:21 ncopa: ftr, yesterday we noticed another failing test was already disabled 2024-08-01 09:29:34 seems like gentoo has disabled this test as well. apparently it deadlocked in earlier versions 2024-08-01 09:29:36 https://bugs.gentoo.org/646890 2024-08-01 09:40:22 Ie. There are 2 tests that segfault, one of which has already been disabled 2024-08-01 09:43:21 ok, maybe we just disable this test too for now, to unblock the builders 2024-08-01 10:02:58 ciao ncopa 2024-08-01 10:03:15 maybe you have some direct advice here, I'm a bit lost with the tinycloud stuff 2024-08-01 10:03:28 it "works" a bit inconsistently 2024-08-01 10:09:52 is it possible that we somehow introduced a regression in the mkimage scripts between 3.19 and 3.20? the 3.20 images fail to boot for me on a legacy BIOS system (mounting boot media failed) they work fine on an UEFI system though. also the 3.19 image still work for me via legacy boot 2024-08-01 10:10:31 not sure if nobody is using legacy boot anymore and therefore we didn't notice it until now or if it is some sort of edge case of my legacy bios hardware 2024-08-01 10:11:39 i have installed from a 3.20 iso on x86 (32 bit) just a few weeks ago 2024-08-01 10:11:50 hi aparcar[m] 2024-08-01 10:12:31 nmeum: I boot legacy BIOS in qemu all the time 2024-08-01 10:13:10 i am running into this on x230, I guess I will have to debug it further at some point 2024-08-01 10:13:36 do you get an emergency shell? 2024-08-01 10:13:48 yea 2024-08-01 10:14:16 does the boot media block device show up there? 2024-08-01 10:14:24 what do you boot from? USB? 2024-08-01 10:14:34 yep usb 2024-08-01 10:15:22 can you try set usbdelay=10 or something? 2024-08-01 10:15:36 boot option 2024-08-01 10:15:46 yea, I will try that later this week. will open an issue on gitlab with more info 2024-08-01 10:15:53 I am just setting up new laptop for $dayjob (via uefi, hence it's not an issue there) 2024-08-01 10:16:25 i suspect it is the usb host controller that is slow to initialize. I think we only give it a single second by default, which may not be enough 2024-08-01 10:16:44 and maybe uefi initalizes the usb host controller so it is faster with uefi? 2024-08-01 10:16:48 just a wild guess... 2024-08-01 10:17:11 hm. maybe but the 3.19 image boots fine via usb on the x230 and I don't think we changed the timeout since? 2024-08-01 10:17:58 I was about to say that maybe we have different kernel, but seems like we use same kernel version 2024-08-01 10:21:02 I suspect it has more to do with kernel config, and timing, than boot loader. But I don't know 2024-08-01 10:21:14 dmesg will probably tell 2024-08-01 10:23:17 ncopa: using a raw script works as expected, bummer 2024-08-01 10:35:12 simple is often the best :) 2024-08-01 11:56:59 Whoever fixed the armv7 build being stuck – thank you. 🙏 2024-08-01 11:57:27 Well, it's not quite there yet, there are still packages failing :) 2024-08-01 11:57:48 but ncopa patched the hanging build 2024-08-01 12:44:05 atleast it finished main and community 2024-08-01 15:45:47 How do I get aports-qa-bot to assign MRs for a package I am now maintaining? Is there a method to submit a request for that bot to do that moving forward? 2024-08-01 16:10:59 one of the packages I maintain is outdated on riscv64, how can I check why it failed 2024-08-01 16:14:59 or is it just still running? just need to wait? https://build.alpinelinux.org/ 2024-08-01 16:26:50 jahway603[m]: your e-mail in gitlab (or one of them) must match what's in the maintainer field 2024-08-01 17:12:34 "jahway603: your e-mail in gitlab..." <- it does match, so not sure why it's not working 2024-08-01 17:12:56 I'll check in a bit 2024-08-01 17:12:59 do you have an MR? 2024-08-01 17:27:27 jahway603[m]: note it will not assign MRs you creaated yourself 2024-08-01 17:28:43 ikke: Ok, I did not know that. Thank you for the clarification. 2024-08-01 17:29:57 That's how we can easily identify MRs that come from the maintainer, verses MRs coming from someone else 2024-08-01 20:58:24 anyone know how alpine handles this? https://github.com/openwrt/openwrt/issues/16032 2024-08-01 20:58:56 apparently golang blows up with default-pie gcc because it produces non-pie .o files then calls gcc to link with default -pie 2024-08-01 20:59:13 i'm trying to figure out what to tell the openwrt folks to do to get it to stop being stupid 2024-08-01 21:00:15 you just need to always pass -buildmode=pie 2024-08-02 07:23:37 dalias: we set GOFLAGS="-buildmode=pie" https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/default.conf?ref_type=heads#L5 2024-08-02 09:22:33 y'all move so fast, i can barely keep up with rebasing my mr on master ;D 2024-08-02 09:27:04 do i need to do anything about this https://gitlab.alpinelinux.org/socksinspace/aports/-/pipelines/251027/ ? 2024-08-02 09:39:24 socksinspace: you don't need to keep your MRs up-to-date. They'll be rebased before merge 2024-08-02 09:40:15 yeah, mine just wen out of date between me rebasing and doing the push and opening the mr :D 2024-08-02 09:45:48 it can sometimes get conflict due pkgrel bump, but thats easy to solve 2024-08-02 10:22:08 https://gitlab.alpinelinux.org/socksinspace/aports/-/jobs/1470806 damn, timed out mere minutes before it probably would've finished 2024-08-02 10:37:08 so close 2024-08-02 10:37:14 yet so far away 2024-08-02 10:40:00 maybe natanael thinks it is close enough :) 2024-08-02 10:40:37 fingers crossed, knock on wood 2024-08-02 12:03:36 I think I'll merge gcc 14.2 now 2024-08-02 12:12:24 oh, exciting times :D 2024-08-02 12:32:02 ncopa: didn't you want to make an edge snapshot, if you haven't already? 2024-08-02 13:06:48 i'd like to do edge snapshot but it seems like riscv64 needs to complete first 2024-08-02 13:07:25 i dont think we will do a world rebuild with gcc14? 2024-08-02 13:54:13 ncopa, thanks 2024-08-02 13:54:21 psykose, yes. i was wondering where that was fixed. 2024-08-02 13:54:40 in abuild conf seems insufficient tho since users running go themselves will get broken binaries 2024-08-02 13:55:14 it really needs to be forced in the go tooling, either made to always do pie or so setting buildmode!=pie forces -no-pie onto link command line 2024-08-02 13:56:54 somehow my go binaries are totally fine 2024-08-02 13:58:50 Yup, same here 2024-08-02 14:55:58 im merging gcc14. we will have to fix broken packages as they show up 2024-08-02 15:44:57 kinda wish we had another builder / machine purely for doing massive rebuilds like this and seeing what comes up 2024-08-02 15:50:46 seems like suse has patches for packages 2024-08-02 16:31:28 still no luck with pnpm for riscv64 but it didnt finish yet right? 2024-08-02 16:33:11 Nope 2024-08-02 16:33:18 https://build.alpinelinux.org/ 2024-08-02 16:34:11 thanks 2024-08-02 16:34:39 I thought no one uses it but I got an email from china asking to upgrade it hahaha 2024-08-02 18:21:02 celie: hey so i got a better understanding of that libquadmath issue. i saw it was merged into aports too 2024-08-02 18:21:47 celie: so it looks like musl on power*-linux doesnt seem to support the two 128-bit floating point formats, ibm double double and ieee. this means the long double is really a 64-bit long double. so gcc14 now enables 128 bit double soo we need to override this using —with-long-double-128 which gives us back the long double == 64-bit double. 2024-08-02 18:22:06 Also note that unknown configure options (say like --with-long-double-64) are silently ignored. this should be updated in the documentation :) 2024-08-02 18:22:21 so have you tried building this using —with-long-double-128 instead of disabling libquadmath? 2024-08-02 20:07:29 is it intended that ci pipelines run on my forked repos? 2024-08-02 20:07:53 yes 2024-08-02 20:08:21 you don't have permissions to run pipelines in alpine/aports, so they run in your fork 2024-08-02 20:14:25 ok, i just hadn't expected that us "normal folk" can use up your resources :D 2024-08-02 20:14:59 Well, we do want to make sure the merge requests actually do build 2024-08-02 20:15:08 And manually running each pipeline would cost too much time 2024-08-02 20:15:27 It works quite well 2024-08-02 20:16:01 this was when i rebased my fork of apk-tools, no merge requests from my side 2024-08-02 20:16:18 https://gitlab.alpinelinux.org/socksinspace/apk-tools/-/pipelines/251102 2024-08-02 20:16:50 right, apk-tools runs pipelines on branches, not on merge requests 2024-08-02 20:17:45 ok, i'll take that as a "don't worry about it" :) 2024-08-02 20:18:36 yup 2024-08-02 20:19:34 i can barely tell my hand from my foot with this coding business, less things to worry about are always good ;P 2024-08-02 20:53:52 Is mps not here any more? 2024-08-02 20:54:05 he wasn't in here since forever 2024-08-02 20:54:25 Thanks 2024-08-02 20:54:27 He's in #alpine-infra 2024-08-02 20:55:36 Thanks, I'll have to rejoin that room. Looks like I was kicked due to inactivity. 2024-08-02 20:57:42 i'm getting kicked out of #-infra every single time my bouncer restarts 2024-08-02 20:57:56 because oftc auth is... something 2024-08-02 20:58:17 Yeah it just kicked me out again 2024-08-02 20:58:27 I guess I have to do something IRC something something 2024-08-02 21:00:43 I've removed +R 2024-08-02 21:01:17 oftc still does not support sasl, and certfp triggers too latea 2024-08-02 21:01:19 late 2024-08-02 21:28:51 skarnet, better host :) 2024-08-02 21:29:15 ? 2024-08-03 02:19:34 Have the issues with the riscv64 builder been causing build failures as well? Haven't been following as closely as I should. 2024-08-03 08:19:30 main/attr fails to build due to basename 2024-08-03 09:26:55 ncopa: mr for attr submitted 2024-08-03 09:27:36 !70097 2024-08-03 13:32:55 It seems that Kaidan is still broken, although the missing dependency was added 2024-08-03 13:33:19 Now it apparently can't find domain “resolver functions”, is it not linked against libc? :p 2024-08-03 13:33:35 “[client] [warn] Lookup for domain example.com failed: Resolver functions not found” 2024-08-03 14:13:52 what should i do if a project using its patched library :( 2024-08-03 14:14:19 Appartenly it wat fixed in 5.12 (https://bugreports.qt.io/browse/QTBUG-74844) but maybe that's something else 2024-08-03 14:14:40 qaqland, your sentence didn't compute 2024-08-03 14:16:48 haha, of course those guys limited the fix to “on FreeBSD” -_- 2024-08-03 14:22:23 What's strange though is that it seems to be working for Bart Ribbers, I wonder how 2024-08-03 14:28:46 idk, maybe ask him ;) 2024-08-03 14:30:42 j_v: thanks! 2024-08-03 14:30:54 glad to help 2024-08-03 14:35:48 socksinspace, done 2024-08-03 14:42:02 quinq: well I don't use Kaidan, but other Qt applications using networking work fine 💁 2024-08-03 14:43:53 since lemonbar needed a new maintainer, is it safe to assume that other aports that were maintained by lemonbar's previous maintainer are in the same state? 2024-08-03 14:45:59 or maybe doesn't use Lemonbar anymore. 2024-08-03 14:46:59 PureTryOut, their example reproduces the issue: https://raw.githubusercontent.com/davidebeatrici/qdnslookup_test/ 2024-08-03 14:47:19 Sorry, wrong address: https://github.com/davidebeatrici/qdnslookup_test 2024-08-03 14:48:21 xulfer: could be... was just wondering because that maintainer hadn't made any changes in long time. and i will scoop up xtitle if need be since i use it in my xorg setup 2024-08-03 14:49:07 Yeah that makes sense 2024-08-03 14:49:55 j_v: Yes 2024-08-03 14:50:16 ikke: thanks 2024-08-03 15:56:29 would anyone care to inlude Python-3.x/Tools/gdb/libpython.py in /usr/lib/python3.x/ in the python3-dev package? that module is extremely handy in debugging python scripts via gdb while attaching to the running python process 2024-08-03 16:05:23 yMVV_HsHcX0, why not rather in the dbg package? 2024-08-03 16:11:54 also acceptable 2024-08-03 16:12:12 actually better! since it needs the dbg symbols anyway 2024-08-03 16:27:22 :) 2024-08-03 16:34:49 is it just loongarch64, or are loongarch32/x32 also targets of interest? 2024-08-03 16:36:44 Just loongarch64 2024-08-03 16:38:22 ok, thanks 2024-08-03 17:01:51 is there any docs on setting up gitlab-runner 2024-08-03 17:01:53 ? 2024-08-03 17:42:14 j_v: other than the default gitlab documentation, no 2024-08-03 17:52:39 ok, the gl docs are pretty circular in how the process of registration is done... ie they don't come right out and specify exactly how to register a project runner... or, at least, my tired eyes aren't grokking it right now. will come back to it after some sleep 2024-08-03 17:54:26 Under the CI/CD settings of your project, there is a runners section. There is a new project runner button. If you follow that, you'll get a token that you can provide to the runner 2024-08-03 17:57:39 What are the requirements for moving a package from testing to community? 2024-08-03 17:57:57 I have one I've been using and maintaining for past 10 months and want to move over 2024-08-03 18:27:55 Just make an MR 2024-08-03 20:09:15 git it 2024-08-03 20:09:22 *got it 2024-08-03 20:10:06 git will be involved :P 2024-08-03 20:34:03 aah, i found libpython.py in the cython package. 2024-08-03 20:40:42 looking for efs-utils APK in edge-community -- not showing up in the repo? was merged about a week ago -- !69542 2024-08-03 21:56:12 main/expect fails to build with gcc16. arch linux has patches 2024-08-03 21:56:30 https://gitlab.archlinux.org/archlinux/packaging/packages/expect 2024-08-04 01:49:47 !70131 2024-08-04 02:20:55 ikke: thanks for the help! got a runner setup, wasn't so hard after you pointed me to the right place. 2024-08-04 07:55:28 i'm making new aport, but package's test need root or sudo, can i skip this test? 2024-08-04 15:43:44 decided that i wasn't going to get "bootstrap.sh" fully working for now, so here's a mr with the current state of affairs !70155 2024-08-04 15:45:04 ptrc: Heya, restored the libclc tests, if you want to look at it. It's at expense of dropping unused clspv, I checked with mesa devs, it shouldn't be used anywhere FOSS https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70029 2024-08-04 21:23:21 If package B v1 has `replaces="A"` to override a file from package A, and then B v2 stops doing that, just upgrading B from v1 to v2 doesn't restore the file from A until I also do `apk fix --reinstall A`. Is there a way to have it be done automatically as part of the B upgrade? 2024-08-04 21:43:06 huh, apparently limnoria just always builds master 2024-08-04 21:43:18 as in, testing/limnoria 2024-08-05 09:36:24 curl 8.9.1 raises SIGPIPE, breaks some softwares, like transmission: https://github.com/curl/curl/issues/14344 2024-08-05 09:46:33 i fear that various configure scripts will make wrong decision due to change behavior in gcc 2024-08-05 09:46:58 for example the zip configure script does almost every detection wrong 2024-08-05 10:10:02 we did make lots of announcements about it including ways to help detect it 2024-08-05 10:10:09 several LWN articles too 2024-08-05 10:10:14 also mentioned in the gcc release notes 2024-08-05 10:10:24 yes, it is a problem though 2024-08-05 10:15:29 i also generally recommend you check what we and fedora did 2024-08-05 11:18:45 it's always been pretty easy to check the exact effects of the change, too, without waiting for the 14.x release 2024-08-05 11:19:14 this allows those who are truly worried to start fixing things several years in advance 2024-08-05 11:20:58 (it is a large job though. no denying that.) 2024-08-05 13:07:19 I have a cert error with curl and wget https://people.redhat.com/sgrubb/libcap-ng/ but it seems to be ok from firefox 2024-08-05 13:07:23 not sure why 2024-08-05 13:08:52 firefox has its own CA store 2024-08-05 13:10:23 i guess we don't have "DigiCert Global G2 TLS RSA SHA256 2020 CA1" in our ca-certificates..? 2024-08-05 13:11:00 we do have "DigiCert Global Root G2" 2024-08-05 13:11:04 but redhat isn't sending the full chain 2024-08-05 13:11:20 Ah yeah, classic 2024-08-05 13:12:33 to be fair, they do point to the "G2 TLS RSA ..." in their certificate (http://cacerts.digicert.com/DigiCertGlobalG2TLSRSASHA2562020CA1-1.crt) 2024-08-05 13:12:46 but tools like curl or wget aren't gonna download a random certificate over http 2024-08-05 13:13:42 and well, it's gonna be pretty much impossible to get a hold of someone who can fix their server to send fullchain 2024-08-05 13:40:31 it is reproducible with fedora curl 2024-08-05 13:40:36 docker run --rm -it fedora:latest curl https://people.redhat.com/sgrubb/libcap-ng/ 2024-08-05 13:44:18 Yes, if they don't send intermediates, curl is not going to be able to verify the chain 2024-08-05 13:51:54 can be reported on bugzilla.redhat.com apparently 2024-08-05 14:41:46 fwiw got the same error for the audit package 2024-08-05 14:42:12 (sorry, main/audit) 2024-08-05 14:43:01 curl was unable to fetch https://people.redhat.com/sgrubb/audit/audit-4.0.1.tar.gz 2024-08-05 18:59:26 we should report it to redhat 2024-08-05 21:53:40 I think i have bootstrap.sh fixed about as far as i can get it myself with !70155 the remaining problems are probably going to need someone familiar with the specific broken parts, i.e arm32 binutils, ghc, rust, and, well, i'm not that person :D 2024-08-05 21:57:19 But that means that the bootstrap process is now in slightly better shape than it was before the upgrade to gcc14, which is still quite nice 2024-08-06 05:51:58 socksinspace: thanks for working on that! 2024-08-06 06:51:48 Im not super familiar with "man" so I have a question, hope isnt silly, is it a problem that the man is in .gz format? Will it work fine? 2024-08-06 06:55:59 the man utility knows how to extract it 2024-08-06 07:01:07 thanks! 2024-08-06 07:48:46 fabricionaweb: abuild automatically compresses man pages even 2024-08-06 08:02:51 hi all, after apk update, do i find somewhere 'unpacked' or 'post-processed' apkindexes from APKINDEX.deafbeaf.tar.gz? 2024-08-06 08:12:51 No, apk deals directly with those indexes in-memory 2024-08-06 10:18:03 ikke, thanks, i was not sure :) 2024-08-06 10:20:03 i have apkindex question, which fields are mandatory and which are not? 2024-08-06 10:20:52 which characters are invalid for any type of value? 2024-08-06 10:22:20 I'm not aware of any official specification 2024-08-06 10:23:17 Also note that the the apkv2 format is legacy and Alpine Linux will probably soon switch to apkv3 2024-08-06 10:23:48 so i can expect new problems with jfrog? :) 2024-08-06 10:24:56 It might be that for the time being, we will still use tha apkv2 index format which apkv3 still supports 2024-08-06 10:33:04 another question: how to map 'hash' in name to line in /etc/apk/repositories? 2024-08-06 10:37:37 It should be the first 4 bytes of the sha1 hash of the full url 2024-08-06 10:37:43 (encoded as hex) 2024-08-06 10:38:08 full url to the specific index 2024-08-06 10:50:27 grep -vE '^($|#)' /etc/apk/repositories | while read repo; do hash=$(printf '%s/%s/APKINDEX.tar.gz' "$repo" "$(apk --print-arch)" | sha1sum | cut -b -8); printf "% -64s APKINDEX.%s.tar.gz\n" "$repo" "$hash"; done 2024-08-06 10:52:49 ikke, thanks, that was exacly what i was lokking for :) 2024-08-06 10:53:09 what about those non-mandatory fields? 2024-08-06 11:37:46 indy: do note that the index and package format are due to be changed 2024-08-06 11:38:12 I just mentioned that 2024-08-06 11:38:39 for current moment i need only v2 2024-08-06 11:38:54 a test fails for main/icu. No idea why or how to fix :-/ 2024-08-06 11:44:54 ikke: sorry, somehow my irc client had lost history above few lines... and now its back 2024-08-06 11:51:08 ncopa: icu-74-2.r0? 2024-08-06 11:52:21 *icu-74.2-r0? 2024-08-06 12:01:00 interesting, it succeded in my chroot but failed on an actual alpine install 2024-08-06 12:02:20 and they are only two commits out of sync 2024-08-06 12:02:34 > libfakeroot internal error: payload not recognized! 2024-08-06 12:02:38 anyone got this before when building? 2024-08-06 12:02:45 also 2024-08-06 12:02:45 > touch: setting times of '.SIGN.RSA.alpine@ptrcnull.me-61a99abb.rsa.pub': No such file or directory 2024-08-06 12:03:02 ptrc: yes, no clue why tho 2024-08-06 12:03:07 oh 2024-08-06 12:03:13 i think i race conditioned abuild 2024-08-06 12:03:27 because there's no lock on signing 2024-08-06 12:09:55 yes, icu-74.2 2024-08-06 12:10:07 I also tested icu-75.1. same thing happens there 2024-08-06 12:11:30 oh, it passes in rootbld 2024-08-06 12:13:15 you'd think a chroot would be more likely to experience issues 2024-08-06 12:20:17 At least i would since i have just had the opposite happen to me with util-linux 2024-08-06 15:59:20 chroots have less going on (well assuming you're using it just to build the one package). 2024-08-06 16:03:01 mine got punished quite heavily while i was sorting out the bootstrap process 2024-08-06 16:05:42 I don't really have much of a process. I should come up with something. 2024-08-06 16:06:18 bootstrap process as in "scripts/bootstrap.sh" 2024-08-06 16:08:30 Yeah I looked at that and just ended up doing it by hand. Saw some people working on it though maybe I should try it again. 2024-08-06 16:09:18 i'll update my mr with a nice idea drom sertonix and then it should be mostly good to go again 2024-08-06 16:09:22 *from 2024-08-06 16:09:51 ghc and rust are still borked, but that is above my level 2024-08-06 16:12:45 buildlab seems handy to use as well, but didn't work for me out of the box. Should probably get this sorted rather than continuing to use my methods. Otherwise I might become the 'It works for me.' guy. 2024-08-06 16:15:01 socksinspace: is your mr mostly good to go at the moment? 2024-08-06 16:15:10 might try it out if so 2024-08-06 16:18:46 should be, if you find any issues please tell me :) 2024-08-06 16:19:28 Yeah I just pulled it up! I'll try it in just a few moments. 2024-08-06 16:20:15 armhf and armv7 have issues, everything else should work (excluding the stuff i just separated out into COMPILER_PKG) 2024-08-06 16:20:40 actually go works fine too, that just got into there by association :D 2024-08-06 16:22:28 god i hope it works for you i really want to stop carrying this branch around :] 2024-08-06 16:31:34 quick, someone merge it before xulfer has time to find any issues /j 2024-08-06 19:25:56 Are there any plans on supporting proper kexec rebooting? 2024-08-06 19:27:27 Nothing concrete afaik 2024-08-06 19:28:39 On systemd based distros all it takes is `kexec --command-line='root=/dev/sdX rw otheroptions' /boot/vmlinuz-linux` and it properly shuts down and unmounts all volumes before loading new kernel 2024-08-06 19:29:19 but the wiki mentions some weird jumping through the hoop via && openrc shutdown and kexec -e 2024-08-06 19:30:05 which I honestly don't even know how to perform because last time I tried it I think I couldn't run anything 2024-08-06 19:30:43 And a service running every reboot is even less favorable 2024-08-06 19:42:50 Something that may be relevant: busybox's reboot doesn't support -k flag 2024-08-06 19:43:18 There is a patch set afaik but idk where the conversation went and why it isn't upstream yet 2024-08-06 22:10:57 socksinspace: I ran into a missing terminfo bit with ncurses. I can look into it later since it probably has little to do with your script. Have you tried riscv64? 2024-08-06 22:11:26 Actually I know it has nothing to do with your script heh. Sorry post nap haze 2024-08-06 22:14:35 I noticed apk 3 is on the roadmap for 3.21. Is it worth me poking around on now, or better to just leave it for later? 2024-08-06 22:17:43 xulfer: i tested from x86_64 to aarch64, loongarch64, ppc64le, riscv64, s390x, x86 sucessfully (with kernel stuff and llvm disabled to cut the compiling time down a good bit) 2024-08-06 22:18:07 Yeah lgtm 2024-08-06 22:18:41 i assume the apk3 question was not related to my MR 2024-08-06 22:18:52 Yeah just in general 2024-08-06 22:29:17 V-T60 > Hello. How do I switch from Pipewire to Alsa without Pipewire removal (it is a part of Sxmo) 2024-08-06 22:29:30 Check out https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11015 2024-08-06 22:31:11 whoops wrong channel lol 2024-08-06 22:32:30 I wish I had a server where I could run irc bouncher on, because I am viewing logs at irclogs.alpinelinux.org 2024-08-07 03:07:06 want get more comments !70186 :) 2024-08-07 06:03:17 🦇 2024-08-07 07:16:35 ncopa: thanks, i'll ask upstream 2024-08-07 07:24:30 Does anyone still have some wishes that i should adress in !70155 ? Did you run into any troubles with it xulfer ? 2024-08-07 09:20:20 oh no plasma was merged 2024-08-07 09:20:47 i wanted to clean up and fix the edge builders so I could tag an edge snapshot 2024-08-07 09:21:02 been weeks without all builders being idle 2024-08-07 09:28:26 Oh sorry 🙈 2024-08-07 09:28:45 well I suppose I'm glad I got it in before the snapshot lol 2024-08-07 09:38:49 well, it only means that snapshot will not happen today 2024-08-07 09:39:07 no chance that riscv64 will be able to catch up 2024-08-07 09:40:07 but not your fault really. its just difficult to do releases for an airplane in the air 2024-08-07 09:40:34 but why does restic fail to build? 2024-08-07 09:40:55 what in the heck is that restic build error on build-edge-armhf, is my browser just being weird about displaying it? 2024-08-07 09:41:20 it looks ... unhealthy 2024-08-07 09:41:30 im messing with it 2024-08-07 09:41:38 trying to figure out why it fails 2024-08-07 09:41:56 it is a unit test that fails, when it tries to overwrite xattrs 2024-08-07 09:42:09 it does not fail in my dev container on same host 2024-08-07 09:43:07 hm, i don't know about any of that stuff, i just saw that my browser can't even render all those characters 2024-08-07 09:43:30 {"name":"","type":"","mtime":"0001-01-01T00:00:00Z","atime":"0001-01-01T00:00:00Z","ctime":"0001-01-01T00:00:00Z","uid":0,"gid":0,"linktarget":"v_l_d \t __i__de \n ___in_","content":null} 2024-08-07 09:43:30 ok github.com/restic/restic/internal/repository/pack 0.139s 2024-08-07 09:43:30 node_xattr_all_test.go:35: xattr mismatch got [] expected [{user.foo [98 97 114]}] 2024-08-07 09:43:30 {"name":"","type":"","mtime":"0001-01-01T00:00:00Z","atime":"0001-01-01T00:00:00Z","ctime":"0001-01-01T00:00:00Z","uid":0,"gid":0,"linktarget":"\u0000\u0001\u0002\ufffd\ufffd\ufffd","linktarget_raw":"AAEC+vv8","content":null} 2024-08-07 09:43:30 --- FAIL: TestOverwriteXattr (0.00s) 2024-08-07 09:43:31 FAIL github.com/restic/restic/internal/restic 1.065s 2024-08-07 09:43:31 FAIL 2024-08-07 10:26:42 Has anyone else heard about problem loading amdgpu firmware after standard apk update / apk upgrade in 3.20.2 ? 2024-08-07 10:27:01 Have not heard any reports 2024-08-07 10:27:09 I created an issue and hope it's just my laptop and not a genreral problem 2024-08-07 10:27:22 !16349 2024-08-07 10:27:29 ! -> # 2024-08-07 10:27:54 #16349 2024-08-07 10:28:31 I'm currently on a mobile connection on the road, so a bit unstable connection ;) 2024-08-07 10:29:56 I will rolback my snapshot and do the pgrade again to see if it is repeatable 2024-08-07 10:30:11 rollback* 2024-08-07 10:34:41 maybe we need update the firmware? 2024-08-07 10:35:04 I think I finally know why resstic fails 2024-08-07 10:37:17 its because we mount /tmp as tmpfs 2024-08-07 10:37:23 but user extended attributes are not permitted. 2024-08-07 10:37:23 The tmpfs filesystem supports extended attributes (see xattr(7)), 2024-08-07 10:37:30 thats why 2024-08-07 10:49:01 Interestin, I rolled back and saw I actually had a newver version of the firmware I built for 3.20 (since I have hue problems with the amdpu driver on my new hardware), and I also reinstalled some other packaes (-a) and then it booted and loaded the firmware... I will try to updatethe firmware and ssee if it is a problem loadin newer firmware files... 2024-08-07 10:55:52 ncopa: did you see !70170? 2024-08-07 10:56:01 i feel like this might break lts modules 2024-08-07 10:57:10 oh, since they have not been rebuilt 2024-08-07 11:22:52 yeah, i saw and I think it may break the lts modules 2024-08-07 11:23:31 I can rebuild the module package 2024-08-07 11:24:04 tricky when packages are tied to the C compiler version 2024-08-07 11:24:25 similar problem with LTO and static libs 2024-08-07 11:24:39 you need same gcc version as the static lib was compiled with 2024-08-07 11:25:10 so when we upgrade gcc, every -static package which has LTO enabled may break 2024-08-07 11:51:25 FYI: I Build linux-firmware for 3.20 and upgraded all the relevant firmware files and it still loads correctly. I will close the issue. 2024-08-07 11:55:34 maybe it was due to we enabled compression of firmware in edge? 2024-08-07 12:10:18 gcc packaging question: Do i understand correctly that you make use of the fact that you don't support multilib, to make splitting off things like libgcc easier? 2024-08-07 14:05:19 EvTheFuture: ptrc: 👀 Hello. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70029 pretty please :) trying to improve reliability of OpenCL building blocks for broader adoption :) 2024-08-07 14:05:47 ptrc: 👀 Hello. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70029 pretty please :) trying to improve reliability of OpenCL building blocks for broader adoption :) 2024-08-07 14:06:05 * Mesa/OpenCL 2024-08-07 14:09:51 oh, sorry! i swore to myself i'll review it after the weekend, and then promptly forgot about it.. 2024-08-07 14:09:58 looking over it now :p 2024-08-07 14:15:29 Thank you 💙 I have open MR in our CI to utilize this package, so testing gives me more confidence I'll have no issues with later updates :P 2024-08-07 15:43:52 is there a preferred porting strategy for apps that need sys/queue.h ? 2024-08-07 15:45:12 specifically noticed that tcl/tk 9.0b3 now requires it. 2024-08-07 16:08:41 fwiw : i just copied the netbsd queue.h into tcl9.0b's compat folder and patched the include in the offending file. will need to run tests to see if that is "the way" 2024-08-07 16:23:47 builders are idle! I'm tagging a snapshot 2024-08-07 16:25:33 🏃 2024-08-07 16:26:14 nice 2024-08-07 17:36:12 and I did the wrong thing but it still worked, correct solution is to install bsd-compat-headers. 2024-08-07 19:21:43 Ariadne: can i ask you to have a look at an issue when building libucontext for SuperH with gcc 14? 2024-08-07 19:42:35 ncopa: Do we have any opinion regarding TLS1.0 and TLS1.1 support in openssl? https://www.openwall.com/lists/oss-security/2024/08/06/1 2024-08-08 02:55:45 socksinspace: it depends on the issue 2024-08-08 07:19:41 Do we have package for fonts? Can I work on this issue request? #16329 2024-08-08 07:27:43 fabricionaweb: there are lots of font-* 2024-08-08 07:28:51 I was searching for fonts* so I didnt found hahaha ok thanks ifs fine I may pick it up later 2024-08-08 07:31:01 ikke: no idea about TLS1.0 and TLS1.1. Does libressl have those enabled? 2024-08-08 07:31:14 no 2024-08-08 07:32:26 hola abby :,) 2024-08-08 07:34:12 already, with v3.8.2, and labelled it "Security fixes".") 2024-08-08 07:34:12 (source: https://www.openwall.com/lists/oss-security/2024/08/07/7 "Then again it must be said that LibreSSL disabled TLSv1.0 and v1.1 2024-08-08 07:36:35 ok. good 2024-08-08 07:39:09 i think it is fine to not care about tls 1.0/1.1 2024-08-08 07:39:13 almost everything speaks tls 1.2 2024-08-08 07:39:32 also mentioned in the thread was browsers turning off tls <1.2 in 2020 2024-08-08 10:50:23 Ariadne: https://termbin.com/puh3 The easiest way to replicate it, that I can come up with (unless you already have a gcc14 toolchain targeting SuperH) would be using https://codeberg.org/socksinspace/musl-cross-make `make -j8 TARGET=sh4-linux-musl` takes about 15 minutes on my laptop `make install` `cd ../libucontext` `make ARCH=sh 2024-08-08 10:50:25 CC=../musl-cross-make/output/bin/sh4-linux-musl-gcc-14.2.0` 2024-08-08 17:55:26 socksinspace: this seems to be unrelated to libucontext and is likely a bug in musl's arch/sh/bits/signal.h header 2024-08-08 17:58:09 socksinspace: try https://tpaste.us/BJN9 2024-08-08 17:59:20 i am not really sure why it complains though; SuperH is ilp32 is it not? 2024-08-08 19:00:58 That seems plausible, but my only qualification in this area is being stubborn and having too much time on my hands, so i'd have to ask the experts, the patch certainly works for the "minimal" way to replicate the error, i'll see if it can get my attempt to make use of my recent bootstrap.sh changes any further :) 2024-08-08 19:04:58 gitlab has been upgraded to 17.1 :) 2024-08-08 19:32:13 ikke: I just had to update a few our our CE instances yesterday to 17.2.2 2024-08-08 19:46:17 There must be something cursed about the bootstrap process, or my setup, all 32 bit architectures besides x86 that i tried so far (armhf, armv7, and now sh4) fail in exactly the same way at exactly the same point 2024-08-08 19:51:18 Ariadne: someone in linux-sh knew the right place to look, INT_TYPE_SIZE is defined as 32 2024-08-08 19:51:44 riveting tale 2024-08-08 19:52:04 did you try the patch, or not? 2024-08-08 19:52:13 yes, worked :) 2024-08-08 19:52:19 awesome, i'll merge it then 2024-08-08 19:52:21 thanks :) 2024-08-08 19:53:34 (though i wonder why Alpine on SuperH? isn't SuperH basically dead at this point?) 2024-08-08 19:53:58 i got fed up with buildroot 2024-08-08 19:54:25 and yes, this definitely is software necromancy 2024-08-08 19:54:31 yeah i feel that in my bones, that's how alpine grew an octeon port 2024-08-08 19:55:30 and yes, bootstrap.sh is somewhat cursed 2024-08-08 19:55:33 i got a hp jornada 680 because i saw that someone had fixed linux support for it, and it was all downhill from there :P 2024-08-08 19:55:55 ah, so you are going to use pmOS to port alpine to the jornada 2024-08-08 19:55:58 got it 2024-08-08 19:56:07