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 just straight alpine i think 2024-08-08 19:56:15 oh wow, you're brave :) 2024-08-08 19:56:26 pmOS makes embedded alpine a lot easier 2024-08-08 19:56:31 nooo, i'm stupid, those are very different 2024-08-08 19:57:18 the libucontext SuperH port i have never actually tested with musl, it was for a federal project involving vxworks 2024-08-08 19:57:44 i do like pmOS tho, cool people, i have one decrepid device port to my name there 2024-08-08 20:15:31 time to see if mips and ppc fail in exactly the same way too 2024-08-08 20:25:03 oh my god, a 32 bit port that doesn't fail at building the native binutils, i can't believe it 2024-08-08 23:38:49 bootstrap.sh sadly only gets repaired whenever someone needs it 2024-08-09 05:58:14 time for unit tests? 2024-08-09 06:50:01 fair, that's why i'm fixing it too :D 2024-08-09 06:52:53 actually i had a crazy/genius idea late at night yesterday, couldn't we just rip out mkinitfs from the bootstrap path, sure, it is part of a full system, but is it needed to run abuild, probably not? 2024-08-09 08:20:54 by that logic we could also remove openssh but that doesn't tend to be problematic and its' utility is very obvious 2024-08-09 11:56:10 hi all, 'C:' in apkindex stands for what? 2024-08-09 12:35:28 I don't really know what else i can do for !70155 All remaining problems, i would say, need to be solved in the offending packages, not in bootstrap.sh 2024-08-09 12:50:31 ikke, ncopa ^^ 2024-08-09 12:50:45 i was looking to apk-tools but without success :/ 2024-08-09 12:54:43 indy: IIRC it is the checksum 2024-08-09 12:57:02 if i will have same package in two repos, that checksum reveal it? 2024-08-09 13:59:22 see C here: https://wiki.alpinelinux.org/wiki/Apk_spec#APKINDEX_Format 2024-08-09 16:10:31 is there something big hogging the arm CI? got 2 time outs in a row 2024-08-09 16:46:13 qaqland, thanks for wiki page 2024-08-09 17:15:57 the arm machine is having some issues I think 2024-08-09 17:16:08 builder or CI? 2024-08-09 17:16:15 CI apparently 2024-08-09 17:16:24 CI 2024-08-09 18:20:30 ptrc: can we throw new Minetest RC it into the edge, so people can test before the final release? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55520 2024-08-09 18:21:48 just realized I could also enable tests, give me a sec 2024-08-09 18:22:45 not sure what's the policy for RCs in aports 2024-08-09 18:25:15 bl4ckb0ne: shouldn't be edge kinda edge? :P but if only final is allowed, then ok 2024-08-09 18:33:40 DavidHeidelberg: do you think the final release will be coming before october (next alpine release-ish)? in any case, i'll mark it as a todo so i don't forget about it (this time) :p 2024-08-09 18:34:38 they wrote in few days 2024-08-09 18:38:42 alright, then i'll take one last look at it later and merge 2024-08-09 18:44:32 ACTION just trying find where the binaries are before they get packaged 2024-08-09 18:47:04 for some reason, having it in the build directory wouldn't make sense, so it's in the main dir. 2024-08-09 18:50:05 good, tests passed (at least on x86_64 for now, until other archs catch up) 2024-08-10 08:30:20 hi there! I've submitted a game to alpine but unfortunatelly I did not manage to make it build or be accepted, I'm sorry I'm not very experienced with git or alpine packages, if anyone is interested feel free to give hints on what I should do or even feel free to submit the game yourself, for reference here is thelast issue: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69804 and here is the game which 2024-08-10 08:30:20 works on a variety of mobile operative systems including postmarket os: https://glitchapp.codeberg.page/_boxclip/ 2024-08-10 09:11:39 glitchapp: hi, here is my comment for other PR, but it will help you https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70195#note_426078 2024-08-10 09:12:52 thanks qaqland, will see what I can do, but I don't really use alpine as a main system, I only have it on a virtual machine for building packages so it will take me a while 2024-08-10 09:19:25 I guess, the chroot created by abuild-rootbld is not supposed to download things from the internet... 2024-08-10 09:19:57 ... at least it does complain to me about not being able to resolve github.com when trying to build stellarium. 2024-08-10 09:43:14 Maybe I shuld use the "net" option? ;) 2024-08-10 09:56:45 arm CI is back online 2024-08-10 10:34:04 Raised the Geary issue, just for good measures: https://gitlab.com/postmarketOS/pmaports/-/issues/3088 :) 2024-08-10 10:34:13 "arm CI is back online" <- Brilliant, thanks! 2024-08-10 17:04:26 fancsali[m]: correct, rootbld does not allow network 2024-08-10 18:38:51 "fancsali: correct, rootbld..." <- With `options="net"` however... 😉 2024-08-10 18:40:59 That should only be used if absolutely necessary though 2024-08-10 18:41:32 Usually it means some project is downloading some dependency itself insstead of having it provided through apk 2024-08-10 20:35:52 loongarch ci is now enabled, so no need for manual mode. 2024-08-10 20:56:12 "That should only be used if..." <- Yeah, I figured that - felt awkward... 2024-08-10 20:56:51 "Usually it means some project is..." <- Fair point... 2024-08-10 20:58:29 ikke: Wondering how the build worked before... cmake build scripts download a lot of things, and also the build fails on a missing function due to C standard not being specified. Bit puzzled, still investigating. 2024-08-10 20:59:23 Would the builders on GitLab allow network access? I thought they are also building in chroots... 2024-08-10 22:31:40 fancsali[m]: that is part of why the options='net' thing exist, afaik, so that the container can have the network shared with the parent process 2024-08-10 22:33:15 most container instantiaters that i am aware of allow to specify which namespaces to unshare (isolate) 2024-08-10 22:39:10 personally, i don't have must trust for any build setup that needs to download anything during the build process, but i don't have to like it to understand it is needed sometimes... i just think that stuff like go and rust (certainly others) have gotten devs used to this insecure practice 2024-08-10 22:41:52 getting down off my pulpit, sorry 2024-08-11 01:23:57 option=net only affect rootbld, builders in CICD use abuild -r 2024-08-11 01:24:42 many aports use cargo or go doesn't set option=net 2024-08-11 01:31:08 didn't realize that CICD builder use abuild -r 2024-08-11 01:32:32 yeeeah, it's still in progress 2024-08-11 01:34:33 not surprised i'm wrong about the cargo and go aports, is an impressed i formed when their popularity first started to grow 2024-08-11 01:35:25 rootbld read APKBUILD twice, there may be side effects :) 2024-08-11 01:36:13 s/impressed/impression/ 2024-08-11 01:36:50 makes sense, once outside the container, and once inside 2024-08-11 03:29:07 In CI, it already runs the job in a clean container, so rootbld has little benefit 2024-08-11 07:57:45 I found out why I had trouble with the amdgpu firmware loading when doing an apk upgrade in 3.20 2024-08-11 09:06:36 Is there a reason why testing/wabt forces LTO? It builds a few static libraries (libwabt, libwasm-rt) and they end up containing LLVM bytecode files with .o extension instead of actual object files, causing linkers to get confused 2024-08-11 09:44:49 I just was able using abuild to package my tool penguins-eggs, ha same troubles but it's normal - I'm a newbye here. Now I have a curious fact: abuild answer me the packa 2024-08-11 09:44:55 >>> penguins-eggs: Package is up to date 2024-08-11 09:45:09 but ehere is the package? 2024-08-11 09:46:34 To be honest I'm on a VM with the package already manually installed... but I wat to have same sort of package to install. 2024-08-11 09:47:07 Where I'm wrong? 2024-08-11 09:47:15 with the default config abuild stores packages in $HOME/packages, see if you have anything there 2024-08-11 09:48:11 >>> YES, great thanks! :-D 2024-08-11 21:47:58 are new ports allowed in the *-stable branches? it would be cherry-pick and is required by two packages,which are effectively broken right now on 3.20 2024-08-11 21:58:03 here we go anyway 2024-08-11 21:58:13 PureTryOut: might be interesting to you https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70419 2024-08-12 04:26:54 ptrc: fixup for armhf/armv7 failing test (well, we do same thing as Debian, disable the test, because what else we can do): https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70424 2024-08-12 06:50:13 there is a security upgrade to vaultwarden, which brances should I backport it? 2024-08-12 06:51:08 fabricionaweb: it's in community, so just 3.20-stable and edge 2024-08-12 07:02:48 thanks, should I update the maintainer in the stable branch (as it is on master) or doesnt matter after all? 2024-08-12 07:03:54 You can update it 2024-08-12 07:08:56 eeehh, not so smooth hahaha it needs newer rustc 1.79 and 3.20 is on 1.78 2024-08-12 07:10:26 Fun 2024-08-12 07:24:02 Can't wait for rust to be standardized and stable 2024-08-12 07:24:33 Wonder if that will ever happen 2024-08-12 07:24:55 anything I can do or just cry? 2024-08-12 07:25:04 can you backport the fix? 2024-08-12 07:27:41 I think its two releases ahead, not sure I can but let me see 2024-08-12 07:27:56 Maybe also check other distros if they have patches 2024-08-12 07:32:41 DavidHeidelberg: thanks! 2024-08-12 07:52:10 fabricionaweb: and it's not as easy as just reverting to rust-version = "1.78.0" in Cargo.toml? 2024-08-12 07:52:37 that is what Im trying now to see if it build or needs to update the cargo lock as well 2024-08-12 07:52:45 but since my sandbox is on edge, doing some here there to try it 2024-08-12 07:54:41 then try it in the MR? 2024-08-12 07:55:30 because, if your sandbox has rust 1.80.1 I don't think the crates will break even if you lower the requirement, right? 2024-08-12 07:55:50 yes, but I get a way to downgrade it to 1.78 2024-08-12 07:55:54 but I will send 2024-08-12 07:56:55 thanks 2024-08-12 08:04:39 fingers crossed 2024-08-12 08:16:09 rust *smh my head* 2024-08-12 08:16:41 I hope that keeping rust at the release it's at when we're cutting a release won't cause too many issues (1.78 for our 3.20-stable, 1.76 for 3.19-stable etc), as it could be hard to impossible to upgrade due to bootstrapping and its dependencies, not least llvm 2024-08-12 08:17:34 ptrc: is it normal for aarch64 it takes so long to propagate? -mtls-dialect=desc 2024-08-12 08:17:39 - https://pkgs.alpinelinux.org/packages?name=minetest&branch=edge 2024-08-12 08:18:06 oops, s/-mtls-dialect=desc/minetest link/ :) 2024-08-12 08:21:56 that seems to worked omni! 2024-08-12 08:22:11 \o/ 2024-08-12 13:33:21 hi all, can i put own requires provides in this shape: "api:open62541=1.3"? 2024-08-12 16:54:17 PureTryOut: you may want to cherry-pick 50b38001922c57ada5f29f40c37a0d9d19dacc3a onto aports master (where i should have PR'd it to first, i guess?) 2024-08-12 17:05:53 Piraty: oh yes I didn't even notice it was for 3.20 only. Please do master first next time and say in MR it should be backported 2024-08-12 17:23:11 will do, 2024-08-12 17:23:39 didn't occur to me , some "whatever reason"(tm) 2024-08-12 18:52:20 python3 build is single threaded? 2024-08-12 19:26:42 que? 2024-08-12 19:37:31 cannot confirm 2024-08-12 21:12:38 its slow to build, using a single core it seems. 2024-08-12 23:01:10 I mean it's python 2024-08-12 23:10:04 but presumably most of the python -build- is C? 2024-08-13 13:10:21 xulfer: did you get to give my bootstrap.sh fixes a try already? 2024-08-13 13:10:35 Oh no I didn't. Let me check them out 2024-08-13 13:10:40 Good timing. 2024-08-13 13:12:23 yeah, i saw you in offtopic so i thought i'd poke you :D 2024-08-13 16:55:54 if [ "$ARCH" != "s390x" ]; then 2024-08-13 16:55:54 I’m working on a PR for bluez-alsa that adds a dependency not available for s390x. Should I remove support for s390x since IBM Mainframes typically lack Bluetooth, or is there a workaround? 2024-08-13 16:55:54 --enable-ldac 2024-08-13 16:55:55 I want to conditionally exclude libldac-dev and the --enable-ldac option for s390x. How can I use this approach with APKBUILD build function? 2024-08-13 16:55:55 Hi everyone, 2024-08-13 16:55:55 fi 2024-08-13 16:55:55 How can I remove libldac-dev as a makedependency for s390x in the APKBUILD? 2024-08-13 16:55:57 Thanks for your help! 2024-08-13 16:55:57 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69824 2024-08-13 16:57:03 wizzard: You can use $CARCH 2024-08-13 16:58:59 wizzard: look at https://git.alpinelinux.org/aports/tree/community/gjs/APKBUILD#n28 for an example on how to do this kind of stuff 2024-08-13 17:18:04 Thank you. That solved my issue 2024-08-13 17:27:26 Should I care about CFLAGS as it already is in the APKBUILD? 2024-08-13 17:27:26 Is there a reason why apkbuild-lint only shows these errors in CI? 2024-08-13 17:27:26 MC[AL31]:APKBUILD:57:2:variable CFLAGS must not have capital letters 2024-08-13 17:27:26 MC[AL31]:APKBUILD:59:2:variable CONFIGURE_OPTIONS must not have capital letters 2024-08-13 17:30:02 I think I'll disable that one. To be honest, in CI it runs a different implementation that I still need to package 2024-08-13 20:25:46 Is there something going wrong with gitlab that I've missed? 2024-08-13 20:25:47 I'm getting 500 error when trying to create a new MR against aports 2024-08-13 20:26:11 PabloCorreaGomez[m], just to check - is your fork behind upstream a lot? 2024-08-13 20:26:25 does the 500 take long or does it come quickly? 2024-08-13 20:26:33 Habbie: might be? It does take a while 2024-08-13 20:26:36 (i haven't used alpine gitlab today so i just have these questions) 2024-08-13 20:26:46 i once was behind a lot and somebody in here mentioned that that really doesn't help 2024-08-13 20:27:42 Aaaah, right. Thanks a lot! Works now! \o/ 2024-08-13 20:29:37 yay! 2024-08-14 08:39:39 can someone merge !70454? 2024-08-14 09:00:04 Actually that MR might not be ready for merge... Yesterday the builders were failing to fetch tarballs from sources.phosh.mobi... But today a new and exciting error has appeared: "ERROR: libphosh-0.40.0-r1.apk: package file format error" 2024-08-14 09:17:13 riscv job keeps erroring with 'Could not resolve host: gitlab.alpinelinux.org'. Even after retries. 2024-08-14 09:17:15 https://gitlab.alpinelinux.org/WhyNotHugo/aports/-/jobs/1482791 2024-08-14 09:18:30 weird, the host does resolve the address 2024-08-14 11:00:51 Since setting up abuild as documented in the wiki installs the key from `~/.abuild/` in `/etc/apk/keys/`, what do we think about just removing this line https://gitlab.alpinelinux.org/alpine/aports/-/blob/d48bf38dfe584013d9cb15fc5d52467382166c18/scripts/bootstrap.sh#L77 2024-08-14 11:01:12 thank you bot, very helpful 2024-08-15 07:31:17 i have looked some more into the bootstrap problems for all arm32 architectures some more, if i revert main/binutils to 7f90875cc450c2c38292536ba4125bfc929fec5c or earlier the binutils build successfully, but then util-linux fails in much the same way 2024-08-15 07:33:34 s/revert/restore 2024-08-15 08:10:06 nfs-utils build failure is probably due to cfdb1b6dd1831b40f98d9972886ce449d0b9069b 2024-08-15 08:12:05 so it was binutils-2.37 that broke it? e9003d6ebb2a82f42ee3115d677d732406406bfa 2024-08-15 08:13:52 well, since util-linux breaks in the same way i'd say both are just a symptom not the cause 2024-08-15 08:14:41 god knows what the underlying problem actually is 2024-08-15 08:15:47 i'm no toolchain expert, i just bash my head against problems until they go away :D 2024-08-15 08:18:41 maybe someone can try bootstrap for armhf on armv7 or the other way around, to see if that has the same problem, since i only tested on x86_64 and aarch64 2024-08-15 08:28:31 2.36.1 also fails 2024-08-15 08:29:11 in the same way, so it's probably not just because i haphazardly patched it into the APKBUILD 2024-08-15 08:48:25 same for 3.36 which somehow wasn't on the sourceware site so i didn't test it at first 2024-08-15 09:16:28 i think we need to do something about kde on riscv64 2024-08-15 09:16:35 it has been blocking the builders for a while now 2024-08-15 09:16:46 we have to either fix it or disable kde on riscv64 2024-08-15 09:16:55 annybody runs kde on rv? 2024-08-15 09:17:07 no idea 2024-08-15 09:17:26 you must be really dedicated to do so :) 2024-08-15 09:21:34 i found kde5 quite serviceable on a core2duo, running it on some of the better rv socs doesn't seem *that* outlandish 2024-08-15 09:36:16 hi all, python3 package contains module called ensurepip, which bundles setuptools and pip whl files. on debian based distros this is distributed using pythonX.Y-venv package which is usable for development 2024-08-15 09:37:27 on production servers, i don't see any purpose for that. in fact it is undesired feature 2024-08-15 09:45:58 the problem with debugging late at night is that i tend to forget what i did to make something work by the time i wake up the next day 2024-08-15 09:46:27 ncopa, ^^ 2024-08-15 09:50:12 indy: feel free to create a MR 2024-08-15 09:51:16 ncopa, working on that :) 2024-08-15 10:05:31 ncopa, !16374 2024-08-15 10:05:50 oops 2024-08-15 10:05:55 ncopa, https://gitlab.alpinelinux.org/alpine/aports/-/issues/16374 2024-08-15 10:37:06 #16374 2024-08-15 11:24:16 that's not a MR :) 2024-08-15 11:25:06 correct 2024-08-15 12:17:58 !70554 2024-08-15 12:55:53 indy: please fix typo in the MR) 2024-08-15 12:57:55 and it's not a venv https://pkgs.alpinelinux.org/contents?file=&path=*venv*&name=python3&branch=edge&repo=main&arch=x86_64 2024-08-15 13:10:25 andypost[m], typo (copy-pasto) fixed :) 2024-08-15 13:10:49 andypost[m], ensurepip would be good? 2024-08-15 13:11:05 or py3-ensurepip? 2024-08-15 13:15:47 Doesn't this break venvs? 2024-08-15 13:17:07 Yes, it does: https://tpaste.us/LRDp 2024-08-15 13:21:56 bacause you need to install python3-venv first… but tbh I don't see the point of having it in a subpackage 2024-08-15 13:22:28 so keep venv, but add there venv and ensurepip folders? 2024-08-15 13:22:32 No, it works with just python3 2024-08-15 13:24:56 dne, security. 1.) no need to have it on production server, 2.) pip and setuptools are sources of cves for whole python3 package. 2024-08-15 13:47:12 having cved python code in some zip file somewhere is not actually a vulnerability 2024-08-15 13:52:22 psykose: I bet that would not prevent security scanners from complaining about it 😑 2024-08-15 14:01:47 yeah prolly not 2024-08-15 14:18:33 ikke, exactly :) 2024-08-15 14:19:17 It's just that I can feel the frustration of yet another change that breaks existing setups 2024-08-15 14:28:27 yeah i guess this change would break A LOT 2024-08-15 15:33:03 something is broken. my lxc and incus containers does not get the network up 2024-08-15 15:33:14 it looks like ifupdown-ng got uninstalled for some reason 2024-08-15 15:33:59 In the container? 2024-08-15 15:37:30 yes 2024-08-15 15:37:47 ncopa-edge-x86-64 [~]# ifup eth0 2024-08-15 15:37:47 ifup: too few parameters for line "iface" 2024-08-15 15:38:04 so apparently I had ifupdown-ng at some point, but it got uninstalled 2024-08-15 15:38:19 noticed the same on build-edge-loongarch64 2024-08-15 15:42:39 openrc should pull in ifupdown-ng 2024-08-15 15:42:49 upgraded my dev container, but it's still installed 2024-08-15 15:42:56 yes i also noticed it 2024-08-15 15:43:55 i noticed it when i did an upgrade -a 2024-08-15 15:44:00 on lxc 2024-08-15 15:44:53 i guess its pulled in by openrc 2024-08-15 15:46:05 yes, but shouldn't the container have openrc? 2024-08-15 15:46:23 it does 2024-08-15 15:46:26 it has openrc 2024-08-15 15:47:06 i was not sure if it was due mixing of bootstrap stuff and half backed main 2024-08-15 15:47:16 so i didnt put attention to it 2024-08-15 15:49:03 something probably installed busybox-ifupdown 2024-08-15 15:50:16 yeah, i had busybox-ifupdown installed for some reason 2024-08-15 15:50:23 so the dependency was satisfied 2024-08-15 18:10:20 i have a question regarding the license field in APKBUILD: how should i format the field in case there are 2 licenses (one for the main software and one for a dependency), both having an SPDX identifier? 2024-08-15 18:11:18 (i initially formatted it as 2 identifiers in the string separated with spaces, like this: "Unlicense MIT", and i'm not sure if that's a correct way) 2024-08-15 18:11:41 you can do `AND` and `OR` if needed 2024-08-15 18:12:12 thanks :3 2024-08-15 18:12:27 in this case it would be AND 2024-08-15 18:12:32 (if it was not obvious) 2024-08-15 18:12:36 good to know :3 2024-08-15 18:12:37 like `license="MIT OR (GPL-2.0-or-later AND GPL-3.0-or-later)" 2024-08-15 18:12:58 so it should be "Unlicense AND MIT", right? 2024-08-15 18:13:14 whats the package? 2024-08-15 18:13:47 magmaus3: based on what you mentioned, yes 2024-08-15 18:14:13 bl4ckb0ne: zpaq 2024-08-15 18:15:19 also, if a package has no dependencies, should the variable be omitted? 2024-08-15 18:15:48 yes, you can only specify the makedepends 2024-08-15 18:15:54 dependancies are automatically filled 2024-08-15 18:15:55 good to know, thank you :3 2024-08-15 18:38:16 the absolute clusterfsck of an armv7 bootstrap is done, i'm not too positive about the odds of me being able to reproduce it tho ;D 2024-08-15 18:41:01 not like it solves the underlying problem anyway 2024-08-16 02:46:55 I'm thinking of creating an alternative zfs kernel module package that will build the modules for zfs using akms. As previously discussed, it is a hazzle to keep zfs-edge and linux-edge in sync. 2024-08-16 02:49:01 Any objections or what's your point of view towards to this? 2024-08-16 03:09:17 isn't testing/zfs-src that already 2024-08-16 03:09:52 has an akmbuild and does exactly that 2024-08-16 04:22:53 Haven't seen that one. I'll take a look, thanks. 2024-08-16 05:36:59 Is the matrix bridge awol? 2024-08-16 05:37:14 at least some users are gone 2024-08-16 05:38:35 Aug 13 [15:42:30-04:00] <-- trinity-1686a (~trinity-1@0002c89e.user.oftc.net) Quit (Quit: Bridge terminating on SIGTERM) 2024-08-16 05:38:58 recently the bridge changed to only add puppets for active users 2024-08-16 05:39:15 right, I've been noticing (users just joining before they talk, replying to things) 2024-08-16 05:39:43 yeah anyone who's been idle since the restart won't join until they say something 2024-08-16 06:23:16 yeah, i'm there, just idle 2024-08-16 07:04:33 does the gitlab instance hate me specifically or is it just a bit slow at the moment? 2024-08-16 07:07:43 it's pretty slow for me too 2024-08-16 07:07:48 https://gitlab.alpinelinux.org/socksinspace/aports/-/commits/bootstrap-hell this didn't end up as horrible and hacky as i thought it would be, but very much not upstreamable 2024-08-16 07:08:13 oh hey clayton, i got the arm bootstrap up again, not sure if the result works yet 2024-08-16 07:09:27 works for armel (armv5) too, if someone wants to play around with that :D 2024-08-16 07:10:41 i seem to recall that there was some interest from parts of the postmarketOS community at some point 2024-08-16 07:12:24 oh wow, armv5 😅 2024-08-16 07:12:54 you could probably even get that to armv4 with some tweaks in abuild and apk-tools 2024-08-16 07:17:51 there must be someone with a openmoko or sth that i can nerdsnipe into giving armel a go 2024-08-16 07:24:59 if you're on mastodon, make a post about that :P 2024-08-16 07:25:20 true 2024-08-16 07:39:17 Jeff Bilyk/JBilyk has not been active for nine years, aports that could need a new maintainer: main/{sqsh,nrpe,nagios-plugins,sendpage} and community/{cacti,irrlicht} 2024-08-16 07:53:22 yo, can now somebody merge !70320? 2024-08-16 08:05:48 oh damn, it actually works https://paste.tchncs.de/upload/monkey-fly-bat 2024-08-16 08:08:30 to prove that there are no shenanigans here ;P https://paste.tchncs.de/upload/monkey-shark 2024-08-16 08:39:18 wow thats cool 2024-08-16 08:43:38 in the process of rebasing on that i may have screwed up my SuperH work a bit :D 2024-08-16 08:43:52 oh well, you win some, you loose some 2024-08-16 08:46:43 i really hope this makes the SuperH bootstrap possible too, since it failed in the same way 2024-08-16 08:47:58 i wonder why you want to booystrap superh 2024-08-16 08:49:46 because i want a proper distro with a package manager, not buildroot 2024-08-16 08:51:13 yeah but which device of yours uses superh 2024-08-16 08:51:26 oh, i have a hp jornada 680 2024-08-16 08:51:54 for now i target qemu tho, to get the main problems sorted before i go to slow hardware 2024-08-16 08:52:31 ahh thats cool, i hope you succeed 2024-08-16 08:54:48 that was my original motivation for sorting out the bootstrap process 2024-08-16 10:01:50 the (hopefully) final version of !70155 should land in about an hour, depending on how fast or slow my computer is today 2024-08-16 11:15:03 Can someone take a quick look at !70571? Not sure if that workaround for cargo-auditable is warranted, or it would be better to use regular cargo build instead? 2024-08-16 11:58:54 If someone wants to merge !70155 or give some feedback, that would be pretty cool 2024-08-16 13:26:11 'Ello frends. I wonder if anyone can give me some advice on what causes the error "ERROR: libphosh-0.40.0-r1.apk: package file format error"? My websearch-fu is failing me here. And in fact, that error message itself is elusive in the source (it's not in "master", but I see it in older tags) 2024-08-16 13:26:37 Context: I'm trying to update the "phosh" package to also yeet out "libphosh-*" packages in !70454 2024-08-16 13:50:11 abuild autodetects the sofile so:libphosh.so.0_40 and assigns it version 0_40 which is not a valid package version (_40 is not an expected suffix) which in turn causes apk to explode 2024-08-16 13:58:18 Ah-ha, I see. Thanks for the clear explanation and pointing me in the right direction. I'm gonna go absorb Alpine docs on soversioning ... but maybe you can save me the effort and let me know how I might resolve this? Is there a way to convince abuild to make peace with this soversioning, or do I need to carry a patch that changes the soversion produced by the build? 2024-08-16 13:58:36 I'm currently testing a fix 2024-08-16 13:58:44 (and building phosh broke my audio :/) 2024-08-16 14:00:41 hehe yeah, Phosh tests run in nested Wayland and all sorts of shenanigans ensue. Every time I test something on my GNOME desktop the lock shortcut stops working until session restart, and idle inhibitor gets confused and never idles 🙈 2024-08-16 14:01:02 And cool, I appreciate you doing that, that's more than I dared to ask/hope for :D 2024-08-16 14:04:44 I thought a provides="so:libphosh.so.0_40=$pkgver" in libphosh() would do the trick, but it doesn't seem to overpower dependency auto-detection 2024-08-16 14:05:51 I'm not sure why the underscore scheme was chosen ... Phosh upstream is quite close to Debian, so maybe it's some kind of requirement coming from there 2024-08-16 14:06:45 I'm going to just patch it to use a dot instead, and see if maybe that can go upstream 2024-08-16 14:07:47 not sure honestly, there are a lot of shared libraries that have multiple version components after .so 2024-08-16 14:09:57 Yeah, I just checked an Alpine install and it's _only_ dots, no underscores to be seen 2024-08-16 14:10:12 i have never seen underscores being used in that contet 2024-08-16 14:11:41 Well, now you have (https://gitlab.gnome.org/World/Phosh/phosh/-/blob/main/meson.build#L11) :) What has seen can never be un-seen 🙃 2024-08-16 14:11:49 +been 2024-08-16 14:13:24 was added in 095f29c3a46df3f8d5fdc1d2d11cf688be91a44d 2024-08-16 14:13:59 i would talk to upstream about this 2024-08-16 14:14:17 https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1463 2024-08-16 14:14:32 i saw that, but there doesn't seem to be any justification for using _ 2024-08-16 14:16:23 Agree. I also just checked a trixie chroot and it's all dots in those soversions too 2024-08-16 14:16:43 i didn't mean that there's no possible reason, just that they don't bring it up 2024-08-16 14:17:28 I think it's more that we just made up a soversion on the spot and didn't realize it might run afoul of tooling like this :D Since I don't see underscores in Debian and I'm active upstream I shall propose the patch there 2024-08-16 14:18:14 But since 0.41 was cut yesterday and I'd _really_ love for libphosh 0.41 to exist in Alpine so I can package my project, phrog (https://github.com/samcday/phrog), I'll also update the aports MR with the patch 2024-08-16 14:18:33 Thanks so much for the help <3 2024-08-16 14:47:54 samcday: I just found a better way of fixing versions: somask="libphosh.so.0_40" at the top level followed by provides="so:libphosh.so.0_40=$pkgver" inside libphosh() 2024-08-16 14:48:37 Well that's a huge relief because upstream seems to wanna fight on the dots issue (https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1497#note_2198503) and I am a pacifist ;) 2024-08-16 14:49:57 Provides should include -r$pkgrel 2024-08-16 14:50:39 i too once dabbled in pacifism 2024-08-16 15:04:04 gotta wonder where using _ is even documented, its not here as far as I can tell... https://semver.org/ 2024-08-16 15:06:49 Guido clarified his position, I couldn't resist the "okay but I don't get it and don't agree" snipe, but he does have solid reasoning: https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1497#note_2198518 2024-08-16 15:07:14 (Bringing a "libphosh" into existence is something he's doing very, _very_ carefully, which I _do_ understand and respect 100%) 2024-08-16 15:08:20 without more info it looks like something he just made up with no precedent 2024-08-16 15:08:27 ikke: Thanks, I included this in the latest revision of !70454 - which is now making _everyone_ happy. I owe yyp a or ten 2024-08-16 15:11:45 orbea: The context here is that I don't think Guido really wants to be producing this libphosh at all since Phosh is still under very active development, with monthly releases. Adding worrying about ABI compatibility to the ever-growing list of concerns for Phosh ecosystem maintenance is not desirable. But making libphosh available makes it possible to ship a greetd greeter, and Guido _does_ want to see that happen, so here we are :D 2024-08-16 15:12:47 So I guess there isn't really a typical precedent here ... we're trying to make a libfoo available without really wanting many/any libfoo consumers just yet 🙈 2024-08-16 15:13:43 what is the point of publishing before having something you're happy with and can commit to keeping somewhat stable? 2024-08-16 15:13:56 Because perfect is the enemy of good? :) 2024-08-16 15:14:23 yeah but if the API is already "good" then by definition it should be worth using 2024-08-16 15:14:38 skarnet: By that logic no 0.x semver software should ever be published to any registries/repositories anywhere, or maybe I'm misunderstanding you 2024-08-16 15:15:41 I'm not far from believing this tbh :P but even 0.x semver software doesn't often outright say "we don't want any users" XD 2024-08-16 15:15:45 skarnet: The API is decidedly _not_ good yet, that's the point. The background story is a Phosh-based greeter already exists, phog (https://gitlab.com/mobian1/phog). The problem is that was built by forking the phosh codebase and taking a chainsaw to it, which means it's already very far behind latest Phosh releases (it was forked back in 0.29.x and now Phosh is at 0.41.x) 2024-08-16 15:15:50 he could just declare that 0. releases may not preserve API compat 2024-08-16 15:16:01 and wait till 1. when its more stable 2024-08-16 15:16:05 ^ 2024-08-16 15:16:24 So Guido asked the phog maintainer to consider using libphosh (https://gitlab.com/mobian1/phog/-/issues/5), and that's where I come in. We are actively stabilizing and refining this libphosh in the process of making phrog exist. 2024-08-16 15:16:46 orbea: But yes, this is essentially what I said here: https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1497#note_2198525 2024-08-16 15:18:36 So right now I'm in the unenviable position of being caught between rock + hard place 2024-08-16 16:23:28 samcday: you're welcome for the illuminating example 2024-08-16 16:26:15 Nothing like some evocative imagery to convey salient points. I'm a fan of your style m8 ;) 2024-08-16 16:28:00 I do my best... 2024-08-16 16:28:27 NOTICE: Future-deprecated features used: 2024-08-16 16:28:27 * 1.6.0: {'"shared_library" keyword argument "soversion" Invalid Shared library version "7_8_9". Must be of the form X.Y.Z where all three are numbers. Y and Z are optional.'} 2024-08-16 16:28:45 samcday: I have implemented a possible meson improvement that Guido may not like... 2024-08-16 16:29:20 currently this exists only on my laptop, debating whether to merge it into meson 1.6.0 2024-08-16 16:29:37 sam_: thoughts??? :D 2024-08-16 16:30:53 Hah, interesting! I didn't realize what a can of worms I've opened here. The funny thing is I was originally planning to just statically link libphosh in my project and call it a day, but some senior folks in Fedora-land caught wind of that and Expressed Feelings in my direction and that brings us to now. 2024-08-16 16:32:47 Personally I'm a fan of that, since as I noted in that Phosh MR, it seems that quite a few (most? all?!) libs are using a regular "x.y.z" of some kind. And since, as you've pointed out, the soversion is actually just the Wild West with some unwritten (?) rules, I think it makes sense for Meson to strongly encourage people one way. But of course if we put 10 devs in the room to discuss this we'll emerge with 11 distinct opinions on the... 2024-08-16 16:32:53 ... matter.. 2024-08-16 16:37:26 oh dear 2024-08-16 16:38:13 elibrokeit: yes, _ is going to break any number of things, although for e.g. libc++ we do force in a libcxx suffix somewhere 2024-08-16 16:48:38 elibrokeit: fwiw semver says letters and hyphens are acceptable too, see point 11 https://semver.org/ 2024-08-16 16:50:39 orbea: great! if only soname versioning was based on the semver standard 2024-08-16 16:51:45 do you have a different standard? 2024-08-16 16:51:50 as I noted in the MR, the compiler has no standard and permits -Wl,-soname=💩 and as long as it makes a file on disk that will actually pass the loader 2024-08-16 16:52:09 ah 2024-08-16 16:52:17 however, the standard which people assume and make use of is that it is "dot-separated integers", not semver 2024-08-16 17:18:41 seems like the aarch64 edge builder is stuck? 2024-08-16 17:21:31 craftyguy: stuck on elisa and ktexttemplate 2024-08-17 04:42:29 👋 I shall gift one (1) virtual cookie to the hero that can get !70320 merged :> 2024-08-17 05:37:51 well now you owe ikke one cookie :p 2024-08-17 05:45:30 ikke: 🍪 2024-08-17 05:46:20 nom nom nom 2024-08-17 05:50:31 Glad you enjoyed that. You'll be pleased to know there's _more_ where that came from. This time I'm doubling the caloric bounty. TWO (2) cookies for a merge of !70454 :o 2024-08-17 06:19:15 it's waiting for approval from the maintainer 2024-08-17 06:24:37 Oh? Where do you see that info? 2024-08-17 06:25:04 Asignee: Newbyte 2024-08-17 06:25:21 but please don't harass maintainers... 2024-08-17 06:25:37 lmao 2024-08-17 06:25:50 .. 2024-08-17 06:33:54 🤷 2024-08-17 06:34:49 samcday closed 5 minutes ago 2024-08-17 06:34:52 welp 2024-08-17 07:05:06 i sent email to the maintainer on Aug 15th, but there was no reply !70186 2024-08-17 08:41:34 emmm, i got warning and error in cicd, but it still shows green 2024-08-17 08:42:19 https://gitlab.alpinelinux.org/qaqland/aports/-/jobs/1486681#L1015-L1044 2024-08-17 08:42:52 ">>> ERROR: the built package (bats) is already in the repo" This is a non-fatal error from check-apk 2024-08-17 08:43:06 Warnings from apk do not fail the build 2024-08-17 08:43:25 warnings from abuild* 2024-08-17 09:41:18 thanks, i see 2024-08-17 17:40:20 How would you turn "1.13.45bc" into a version that abuild accepts? Just removing the letters at the end isn't ideal as then there is no clear way of indicating which version the package contains as they use those as part of the version, but maybe it's the only way? 2024-08-17 17:43:28 https://gitlab.alpinelinux.org/alpine/go/-/blob/master/version/doc.go 2024-08-17 17:43:59 There is no room for multiple arbitrary letters 2024-08-17 18:06:37 Newbyte: does it always end in letters? 2024-08-17 18:07:14 craftyguy: More or less: https://github.com/BelledonneCommunications/sofia-sip/tags 2024-08-17 18:08:30 always bc it seems 2024-08-17 18:08:53 Just noticed that as well. I suppose it's fine to remove it then. 2024-08-17 18:08:54 one release without it 2024-08-17 18:08:55 yeah, so maybe it can be chopped 2024-08-17 18:09:14 1.13.27, but all others have it 2024-08-17 18:38:19 do we have everything for intel qsv in ffmpeg or is it blocked because of nonfree software? 2024-08-18 21:45:53 I have unfortunately been going down the init system rabbit hole lately. (Long story.) s6's learning curve was too steep for me, so I was excited for https://skarnet.com/projects/service-manager.html . Can someone tell me its status? 2024-08-18 21:46:39 (Not sure if this is the right place, but https://ariadne.space/2021/03/25/lets-build-a-new-service-manager-for-alpine/ linked to it. 2024-08-18 21:46:56 gdh: you know that you're still welcome in #s6, right? ;) 2024-08-18 21:47:05 I thought I wasn't. 2024-08-18 21:47:19 you decided that you weren't and you left. 2024-08-18 21:47:51 in alpine the current push is in decoupling service management from alpine-base, allowing the user to ultimately select what type of service management they want 2024-08-18 21:48:51 the short answer regarding s6-rc v1 is: it's actually a *massive* undertaking, more complex by one or two orders of magnitude than what I thought it was, and so the work needs to be broken down into a lot of things, and incremental approaches like what Ariadne is doing are probably best 2024-08-18 21:48:51 Ariadne, so multiple inits are available? 2024-08-18 21:49:04 so it will still happen, but it will take a lot of time. 2024-08-18 21:49:24 At this point, it's been a couple years. How many years more? 2024-08-18 21:49:47 dunno. Probably not that many once I decide I'm ready to tackle it and stop procrastinating. 2024-08-18 21:50:00 Oh, are you not getting funded anymore? 2024-08-18 21:50:04 gdh: today, yes, if you are willing to do some surgery. by 3.21 release it is hoped that the TSC will approve my proposal that will allow for this more cleanly. 2024-08-18 21:50:21 gdh: not this year, no. Hopefully will be again next year. 2024-08-18 21:50:34 skarnet, that's too bad. 2024-08-18 21:51:16 Ariadne, that sounds awesome. Alpine might be my plan B. 2024-08-18 21:51:32 Yup. One year is fine; what I fear is if the source dries up permanently, I'll have to go back to contracts to sustain myself, which will further slow me down. 2024-08-18 21:53:45 skarnet, on the other topic, I guess I should admit that yes, you are right; I left. But it was because I felt I was on thin ice or already unwelcome. I won't say anything further to derail discussion, but yes, you are right. 2024-08-18 21:55:44 as long as we stick to purely technical discussions, hop by whenever. :) 2024-08-18 22:14:32 Thinking about supporting multiple service management systems has me a bit worried about how we would handle disagreements between systems in a somewhat seamless way. Probably over thinking it. Was thinking about target sync points and the like. 2024-08-18 22:14:58 and how I wouldn't want packages I'm using to have similar behavior to the systemd targets on my current setup 2024-08-19 10:07:48 is setup-alpine available on gitlab? 2024-08-19 10:18:08 fabricionaweb: https://gitlab.alpinelinux.org/alpine/alpine-conf/ 2024-08-19 10:19:17 thank you 2024-08-19 10:22:37 doing a new setup here, the APK Mirror step feels a little off to me personally, as it suggests [1] the selected but it only displays an list of letters, I didnt get what is [1] maybe it should be [f] ? 2024-08-19 10:22:39 https://files.catbox.moe/h584ar.png 2024-08-19 10:23:57 It used to provide a list of mirrors to select from, not sure why it doesn't 2024-08-19 11:10:47 https://matrix.to/#/#_utopia_:matrix.org 2024-08-19 11:51:33 should main/linux-firmware be kept up-to-date on all stable releases? 2024-08-19 11:52:07 amd-ucode got me thinking about it 2024-08-19 14:13:00 dunno. maybe? 2024-08-19 19:28:57 It lives https://tpaste.us/NBgB 2024-08-19 19:49:11 socksinspace, ohh nice. how does one get shell on a fritzbox these days? 2024-08-19 19:49:11 https://matrix.to/#/#_utopia_:matrix.org 2024-08-19 19:54:17 oh that's not on the fritzbox, that's just from the home network (though openwrt has some decent instructions for many models) 2024-08-19 19:55:47 but what it is, is the first signs of life from my SuperH port 2024-08-19 20:03:13 abuild can automatically install dependencies from packages, but is there a tool that automatically builds them if they are not yet available, or do i just have to manually force my way through until i reach something like buildrepo? 2024-08-19 20:03:43 buildrepo can build an entire repo in order 2024-08-19 20:03:51 (from lua-aports) 2024-08-19 20:04:00 ok, so i have to go until i have lua by hand 2024-08-19 20:04:08 yes 2024-08-19 20:07:49 though, you'd have to mount it to copy data into it 2024-08-19 20:08:53 what is "it" in that context? 2024-08-19 20:09:18 the qcow disk 2024-08-19 20:09:35 i'm doing qemu chroots for now :) 2024-08-19 20:09:53 you mean qemu-user? 2024-08-19 20:09:58 yes 2024-08-19 20:10:00 aha ok 2024-08-19 20:10:15 but then you don't have any vm to deal with yet 2024-08-19 20:10:31 yep, no kernels either :D 2024-08-19 20:11:13 https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html#example-creating-a-disk 2024-08-19 20:11:27 wrong chat 2024-08-19 20:11:46 yes 2024-08-19 20:11:58 thanks, I was confused :D 2024-08-19 20:34:22 https://tpaste.us/xygD hmmm, that doesn't seem right 2024-08-19 20:42:43 ah, that minirootfs is a bit borked 2024-08-19 22:08:52 hey, could someone merge !70612? that'd be great! 2024-08-20 09:30:12 ok Im trying to add an -doc package and Im having an issue that Im totally lost 2024-08-20 09:30:58 https://gitlab.alpinelinux.org/fabricionaweb/aports/-/jobs/1489032#L502 2024-08-20 09:33:14 s/license/licenses/ 2024-08-20 09:33:15 damn typo 2024-08-20 09:33:23 also damn regex 2024-08-20 18:03:03 Is there a reason rsync.alpinelinux.org is IPv4 only? 2024-08-20 18:04:23 was migrating some stuff around and put the rsync job on a ipv6 only node but now it fails 2024-08-20 18:04:29 :/ 2024-08-20 19:06:13 caskd: it's behind an anycast address 2024-08-20 19:06:46 I'm not sure we have one for ipv6 2024-08-20 19:15:08 is it a good idea to use ipv6 only 2024-08-20 19:30:12 fabricionaweb: if all you need is ipv6 then yeah, otherwise you may require legacy ip 2024-08-20 19:37:49 fabricionaweb: it's okay as long as you don't need microsoft (github) or some other services that are purely ipv4 2024-08-20 20:05:49 ikke: is there any direct ones i could use? full sync is done so all i do is deltas 2024-08-20 20:05:58 s/is/are 2024-08-20 20:06:27 caskd: (nld|usa|sgp).t1.a.o 2024-08-20 20:06:44 ty ^w^ 2024-08-20 20:07:20 wait, they as well have no v6 2024-08-20 20:07:25 :/ 2024-08-20 20:08:46 Hmm, I'll add the records 2024-08-20 20:08:48 2604:1380:4601:dc00::1/127 2024-08-20 20:08:50 is nld 2024-08-21 05:52:19 ncopa: I'm currently creating an aport for streamlink but are dependent on py3-trio-websocket which was removed by commit 16c818e837ee45ede77266e6c2e7aed926cd70b5 due to an upstream problem with the tests on newer versions of trio. I just want to check if I need to wait for an upstream fix or if we could re-add the package with the failing tests disabled? I also made my own 2024-08-21 05:52:21 pacakge of py3-trio-websocket before I realized it had once upon a time existed. 2024-08-21 07:06:57 IIRC the failing tests made other stuff break 2024-08-21 07:07:07 or hang 2024-08-21 07:08:27 https://github.com/python-trio/trio-websocket/issues/187 says it's not safe with new trio 2024-08-21 07:19:56 I dont think trio-websockets work with trio 0.25 yet. This needs to be merged first: https://github.com/python-trio/trio-websocket/pull/188 2024-08-21 07:28:48 Im looking to the open issues, I saw this one, #16384, the version of yarn that exists in aport is the v1, (I had never notice that they call it "berry"), aur have it, by what I saw it should be very similar to the APKBUILD v1 npm or pnpm 2024-08-21 07:29:09 does it make sense to make an aport for it calling yarn-berry to run the latest? 2024-08-21 07:29:46 #16384 2024-08-21 07:29:53 how to mention issues hahaha 2024-08-21 09:01:22 i think it only works with merge requests 2024-08-21 09:02:14 !68950 2024-08-21 09:02:25 or doesn't at all 2024-08-21 09:02:35 oh well 2024-08-21 09:32:04 bot is 🛏️ 2024-08-21 09:53:25 I made the MR !70772 but Im not sure about the usage of "replaces" so It would be welcome a review 2024-08-21 09:55:58 i think replaces is meant as a rename case where a old package was named differently, and should be omitted here 2024-08-21 09:56:39 replaces is about ownership of files 2024-08-21 09:57:02 oh, to avoid collison? 2024-08-21 09:57:10 Yes 2024-08-21 09:59:00 in this case both yarn and yarn-berry packages have the same binaries 2024-08-21 09:59:15 i guess it makes sense 2024-08-21 10:15:29 If yarn still exists, a conflicts (depends="!yarn") makes more sense 2024-08-21 10:18:22 and remove the replaces? but keep the provides 2024-08-21 10:19:08 does yarn 4 work on projects with a yarn.lock made with v1? 2024-08-21 10:20:45 not sure let me confirm, I think it is not but I want confirm 2024-08-21 10:23:56 they are not backward comaptible that is why both still exists o/ 2024-08-21 10:24:39 depends="!yarn" seems to make sense yes 2024-08-21 10:26:07 hm, should remove the provides="yarn" as well ? 2024-08-21 10:27:17 Depends on whether you want apk to install yarn-berry if something (make)depends on yarn or not 2024-08-21 10:27:42 but it should be a concrete provides: `provides="yarn=$pkgver-r$pkgrel" 2024-08-21 10:27:44 ` 2024-08-21 10:28:04 it should definitely not install by default for yarn 2024-08-21 10:28:58 i would probably rename it and have no conflicts but i dunno how the two yarn/yarnpkg things interact with eachother 2024-08-21 10:34:30 ACTION regrets 2024-08-21 10:35:25 if they must hold the same /usr/bin name, then add a conflict, and add replaces for the other both ways 2024-08-21 10:35:38 so it can swap between them without breaking 2024-08-21 10:35:49 just replaces=yarn-berry replaces=yarn in each or so 2024-08-21 10:43:30 psykose: doesn't that result in apk allowing both to be installed at the same time? 2024-08-21 10:43:49 (unless you have the conflicts) 2024-08-21 10:44:04 i did say add a conflict 2024-08-21 10:44:07 ok 2024-08-21 10:44:20 not sure what happens without it 2024-08-21 10:44:28 add a conflict is "depends=!yarn" right? 2024-08-21 10:44:30 probably can install both and the second install replaces files with no warnings 2024-08-21 10:44:32 yea 2024-08-21 10:44:33 fabricionaweb: yes 2024-08-21 10:44:43 psykose: yes, I've seen that with openssl vs openssl3 2024-08-21 10:45:13 one package inherrits the files, and when you uninstall it, the files are removed, cripling the other package 2024-08-21 10:45:46 yep 2024-08-21 10:47:28 And I _think_ that with a conflict, the replaces is not necessary, since the package will be removed before installing the other package 2024-08-21 10:49:14 hm it depends, somehow i've seen the order be wrong when doing it in the same transaction but i forgot the specific case 2024-08-21 10:49:36 these days on apk3 it seems to work fine to do that with no replaces at all 2024-08-21 10:53:04 ok so I added the conflict and replaces on both sides, and the new one have the provides $pkgver-r$pkgrel if I get it correct, because that is confusing LOL 2024-08-21 10:53:38 not sure what you mean 2024-08-21 10:53:47 caskd: fyi, the *.t1.a.o domains should have an AAAA record now 2024-08-21 10:53:50 there is an implicit cmd:yarn=pkgver-rpkgrel but it's not the same thing 2024-08-21 10:54:21 fabricionaweb: From what I understood, the provides is undersired 2024-08-21 10:54:36 ok remove provides 2024-08-21 10:54:48 ikke: thank you! 2024-08-21 10:54:52 tbh even the implicit cmd: is broken and at least somebody definitely used that 2024-08-21 10:55:00 you should really look at if it's possible to rename it 2024-08-21 10:55:26 psykose: you mean renaming the binary? 2024-08-21 10:55:41 yea 2024-08-21 11:08:23 upstream they are the same, I dont think that would be good idea 2024-08-21 11:10:03 this is a case where they have nothing to do with eachother :) 2024-08-21 11:10:23 it's the same as if /usr/bin/echo was replaced with a command that recorded your microphone and played it back to you 2024-08-21 11:10:38 they have no compatibility so they are different commands 2024-08-21 11:12:04 I see, and I agree 2024-08-21 11:12:53 I guess that is one case that yarn v2+ isnt ported its a mess... 2024-08-21 11:13:21 last i checked any of this was like 2/3 years ago when it was like.. yarn 2/3 and you couldn't even use a system version (?) 2024-08-21 11:13:26 it had to be some local per-project installed thing 2024-08-21 11:13:29 forgot why 2024-08-21 11:13:39 i guess for 4 they made it global again 2024-08-21 11:14:02 i just ended up using pnpm at the time 2024-08-21 11:15:09 hm wonder what corepack does 2024-08-21 11:43:21 ok I figured that using yarn 1 you can swap versions using `yarn set version` so that aport dont seem useful anyways 2024-08-21 11:54:25 with corepack you can also --install-directory ~/somelocalbininpath and then the `yarn` automatically does that based on what a given project uses when you invoke it i think 2024-08-21 11:54:45 but only nodejs-current has it because jirutka removed it from main/nodejs :P 2024-08-21 11:55:37 yeah, but the yarn policies set-version can work even without corepack - it just pop a little warn 2024-08-21 11:56:04 I think thats fine I will suggest it to the person that requested the new version 2024-08-21 11:57:04 yea 2024-08-21 12:19:49 thanks you all for the insights pyskose ikke caskd 2024-08-21 12:20:20 I typo one 2024-08-21 12:21:14 i forgor set existed honestly haha 2024-08-21 12:30:20 ncopa: ok 2024-08-21 13:38:48 could someone point me to the go-1.23 issue/mr? 2024-08-21 13:39:25 i'm assuming there is one. 2024-08-21 14:45:46 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?scope=all&state=opened&search=community%2Fgo 2024-08-21 14:56:35 dne: thanks 2024-08-22 08:52:10 I bumped into somehting interesting(?): vboot-utils seem to have a few hiccups: on my Chromebook crossystem returns execv() error. It seems to need the mosys command/package. 2024-08-22 08:53:28 So I started to look into this, and found a few more oddities: the package is rather outdated, so I am trying to update the code. But then I found, there's a patch to make the builds non-static, and then the package provides and _s (so a dynamically linked and a statically linked variant)> 2024-08-22 08:53:38 s/>/.../ 2024-08-22 08:54:46 ... but then if you do ldd crossystem and ldd crossystem_s, they both return the same: /lib/ld-musl-armhf.so.1 and libc.musl-armv7.so.1. So what gives? Does anyone has any background on this? 2024-08-22 12:10:43 pnpm added self-update command but theres no way to disabled it yet 2024-08-22 13:44:22 fancsali[m]: to be fair, the current package maintainer has last touched it in 2020, the rest was just minor fixes or rebuilds 2024-08-22 13:44:34 though it worked for me a while ago 2024-08-22 13:54:23 Well, it seems they've dropped the whole static thing, so that should be fine – at least until I can build it with the default Makefile in the first place... 2024-08-22 16:28:34 why dont we have ffmpeg 7 ? Just wondering 2024-08-22 17:02:22 nobody bothered yet, i think 2024-08-22 17:02:51 mostly because every single ffmpeg update is like a million breakages 2024-08-22 17:15:55 only practical way is to have ffmpegN packages 2024-08-22 17:22:14 6->7 is an easy port 2024-08-22 17:22:17 only need an ffmpeg4 2024-08-22 17:23:03 a lot easier to make ffmpeg6 libs than port stuff though for sure 2024-08-22 17:33:07 yea we have ffmpeg4 and ffmpeg6 on void 2024-08-22 17:44:32 Looks like we have nothing that depends on ffmpeg4 2024-08-22 17:50:03 I saw omni tried before 2024-08-22 17:50:17 !63713 2024-08-22 17:50:33 bot is 🛏️ 2024-08-22 17:54:10 there are a ton of things using ffmpeg4 though 2024-08-22 19:59:54 does someone object against removing default network from libvirt from autostart? 2024-08-22 20:00:19 even if disabled, it's just a symlink reinstalled by apk 2024-08-22 20:00:42 and it nukes away my nftables rules at boot replacing them with the stupid ones they provide 2024-08-22 20:01:06 what happens if it's removed and you also don't have your own nftables rules 2024-08-22 20:01:46 well, it would not add any unless the network is started 2024-08-22 20:02:02 i'm more afraid of breaking it for people that rely on it to autostart 2024-08-22 20:02:15 which would be most people 2024-08-22 20:02:22 hm. 2024-08-22 20:03:03 i guess i could maybe replace the symlink with a empty file and apk shouldn't touch that as it's in etc, right? 2024-08-22 20:03:13 think so 2024-08-22 20:03:24 not the cleanest solution, but i'll take it 2024-08-22 20:23:41 hm. apparently i built an apk that after installing, corrupts the installed db 2024-08-22 20:28:47 https://ptrc.gay/xBCwIpup 2024-08-22 20:28:52 i don't think this is supposed to happen 2024-08-22 20:31:26 there's a lot of errors like this throughout the entire linux-lts-doc entry 2024-08-22 20:31:33 filesystem corruption perhaps? 2024-08-22 20:40:57 ziwhat package? 2024-08-22 20:45:16 ziwhat 2024-08-22 20:45:37 linux-lts-doc 2024-08-22 20:45:57 could be related to the fact that my installed db is almost 2**32 bytes long? 2024-08-22 20:52:33 No corruption here at least 2024-08-23 05:08:17 ptrc: could you pass your world? i wanna see if i can replicate it 2024-08-23 05:11:23 tbh i think it was something messed up on my end 2024-08-23 05:11:36 because some of my packages were also broken 2024-08-23 05:11:54 like gcc segfaulting on very basic stuff until i reinstalled it 2024-08-23 05:14:44 also ptrc, when is a package "worthy" of community? 2024-08-23 05:14:58 i dont know what the criteria is to move it 2024-08-23 05:15:03 at a later time 2024-08-23 08:12:59 hi, could someone take a look at !70186 , i feel it is ready :) 2024-08-23 08:22:10 would it be possible to put the BATS_LIB_PATH=/usr/lib/bats in /etc/profile.d/bats.sh instead of just mentioning that in the post-install script? 2024-08-23 08:31:05 !70186 2024-08-23 08:32:57 !70186 2024-08-23 08:33:02 now it's working 2024-08-23 08:33:39 yyp: https://github.com/bats-core/bats-core/blob/190c7c9e793d93eed3ab873f5b6b6c790df44045/man/bats.7.ronn?plain=1#L248 2024-08-23 08:35:28 function should be use together with this ENV 2024-08-23 12:20:46 Hello there, 2024-08-23 12:22:07 I'm trying to build k9s and it's failing with the following message. FAIL 2024-08-23 12:22:09 >>> ERROR: k9s: check failed 2024-08-23 12:22:11 >>> k9s: Uninstalling dependencies... 2024-08-23 12:22:14 (1/3) Purging .makedepends-k9s (20240823.110834) I'm not if I'm missing something here. I'm running inside a chroot environment and building the package using `abuild -r` command inside community/k9s directory from aports repo. 2024-08-23 12:23:09 "check failed", you need to look at the output to see what test failed 2024-08-23 12:25:08 Yes, some of the checks are failing but on upstream everything is passing. I'll take a deeper look into test by manually cloning the repo inside the chroot environment. 2024-08-23 12:27:15 but have u changed something? 2024-08-23 12:32:28 No, I've changed nothing. 2024-08-23 12:43:22 Hey there, Sorry for the confusion. I had to join again using hexchat client. 2024-08-23 12:43:22 I'm trying to package a new go package for alpine and I'm facing some issues with development setup. I've used https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package this my guide and facing some issues during compilation. For example, I'm trying to build `oras` package and that is failing with following message: 2024-08-23 12:43:22 ```bash 2024-08-23 12:43:22 $ abuild -r 2024-08-23 12:43:22 # truncated output 2024-08-23 12:43:24 >>> oras-cli: Updating the community/aarch64 repository index... 2024-08-23 12:43:26 ERROR: oras-cli-1.2.0-r0.apk: UNTRUSTED signature 2024-08-23 12:43:28 ERROR: oras-cli-bash-completion-1.2.0-r0.apk: UNTRUSTED signature 2024-08-23 12:43:30 ERROR: oras-cli-fish-completion-1.2.0-r0.apk: UNTRUSTED signature 2024-08-23 12:43:32 ERROR: oras-cli-zsh-completion-1.2.0-r0.apk: UNTRUSTED signature 2024-08-23 12:43:34 >>> ERROR: oras-cli: Failed to create index 2024-08-23 12:43:38 >>> oras-cli: Uninstalling dependencies... 2024-08-23 12:43:40 ERROR: No such package: .makedepends-oras-cli 2024-08-23 12:43:42 ``` 2024-08-23 12:43:44 Any guidance would be extremely helpful here. 2024-08-23 12:46:01 Guest1238: you need to add your public key to /etc/apk/keys with something like `doas cp ~/.abuild/*.pub /etc/apk/keys` 2024-08-23 12:48:03 I switched from normal user to root user and even with root user I'm not able to do that. 2024-08-23 12:48:03 ``` 2024-08-23 12:48:03 ```bash 2024-08-23 12:48:03 sudo doas cp ~/.abuild/*.pub /etc/apk/keys 2024-08-23 12:48:03 doas: Operation not permitted 2024-08-23 12:49:06 with root, you don't need doas 2024-08-23 12:49:24 but you need to adjust the path to copy it from your users home dir 2024-08-23 12:53:01 With normal user as well, it says operation not permitted. I think I'm missing something here. The normal user is part of wheel group. 2024-08-23 12:54:47 With root user, I tried full user path as well and it still says operation not permitted. 2024-08-23 12:54:47 ```bash 2024-08-23 12:54:47 doas: Operation not permitted 2024-08-23 12:54:47 doas cp /home/ria/.abuild/*.pub /etc/apk/keys/ 2024-08-23 12:54:48 ``` 2024-08-23 12:58:09 By default doas is not configured to allow anyone to use it. You need to configure it 2024-08-23 12:58:55 Can you guide me on how can I do that? Any reference would suffice. I'm searching as soon as I finish this message. 2024-08-23 12:59:45 # echo "permit persist :wheel" >>/etc/doas.conf 2024-08-23 12:59:46 echo 'permit :wheel' > /etc/doas.d/doas.conf 2024-08-23 12:59:50 I think this should be it. 2024-08-23 12:59:53 yup 2024-08-23 13:02:02 ria:~/aports/community/oras-cli$ abuild -r 2024-08-23 13:02:02 >>> oras-cli: Updating the community/aarch64 repository index... 2024-08-23 13:02:02 >>> oras-cli: Signing the index... 2024-08-23 13:02:12 Yay, looks like it's good now. 2024-08-23 13:04:29 I've built a package now and it's there. How can I add it and test out if things are good or not. For example, I want to check if version settings via ldflags are correct or not. 2024-08-23 13:06:12 Guest1238: the package is placed in /home//packages/. You can add that path to /etc/apk/repositories so that you can directly install packages from it 2024-08-23 13:09:34 ria:~/aports/community/kubectx$ cat /etc/apk/repositories 2024-08-23 13:09:34 ria:~/aports/community/kubectx$ sudo apk update 2024-08-23 13:09:34 http://dl-cdn.alpinelinux.org/alpine/latest-stable/community 2024-08-23 13:09:34 http://dl-cdn.alpinelinux.org/alpine/latest-stable/main 2024-08-23 13:09:34 fetch http://dl-cdn.alpinelinux.org/alpine/latest-stable/main/aarch64/APKINDEX.tar.gz 2024-08-23 13:09:38 fetch http://dl-cdn.alpinelinux.org/alpine/latest-stable/community/aarch64/APKINDEX.tar.gz 2024-08-23 13:09:40 WARNING: opening /home/ria/packages/community/aarch64: No such file or directory 2024-08-23 13:09:42 v3.20.2-168-gb223e202b56 [http://dl-cdn.alpinelinux.org/alpine/latest-stable/main] 2024-08-23 13:09:44 v3.20.2-167-gd360ba6e891 [http://dl-cdn.alpinelinux.org/alpine/latest-stable/community] 2024-08-23 13:09:46 OK: 24040 distinct packages available. 2024-08-23 13:10:20 I think I'm again doing something wrong here. The packages are there in /home/ria/packages but are not recognized by apk as of now. Maybe the entry is wrong. 2024-08-23 13:11:33 got it, removing arch from the entry 2024-08-23 13:14:25 Thanks for your guidance @ikke, with things working now, I'm looking forward to adding some packages to the repo. 2024-08-23 13:33:28 Guest1238: You're welcome, enjoy your endeavors 2024-08-23 14:19:19 is gitlab okay? I get 500s 2024-08-23 14:21:04 For what url? 2024-08-23 14:23:32 https://gitlab.alpinelinux.org/Ermine/aports/-/merge_requests/new?merge_request%5Bsource_branch%5D=py3-setuptools 2024-08-23 14:24:07 right, it's a known issue when your source repo is out of date enough 2024-08-23 14:24:26 It's just for that specific page 2024-08-23 14:25:38 ACTION rebases 2024-08-23 14:32:06 psykose: do you remember some references for this change? https://gitlab.alpinelinux.org/alpine/aports/-/commit/85bd91240811560ba9717200abced86a0d7350b7 2024-08-23 14:32:52 recently Mesa got detection mechanism https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30599/diffs?commit_id=cc2dbb8ea5329b509d79eedb6c0cbb9a1903b5ad 2024-08-23 14:38:03 ikke: ok, thank you 2024-08-23 14:49:34 if the gnu2 will still not work, we may extend the list by gnu too then. So the order would be "gnu2, gnu, desc" 2024-08-23 16:22:38 they all get detected so that doesn't do much 2024-08-23 16:22:45 or well, anything 2024-08-23 16:22:55 DavidHeidelberg: https://gitlab.alpinelinux.org/alpine/aports/-/issues/14140#note_260250 2024-08-23 16:23:34 it might also magically be fixed in new binutils 2024-08-23 16:23:39 grab an armv7 device and find out 2024-08-23 16:27:22 psykose: thanks, too late today, but I'll check tomorrow, maybe throw new mesa at someone with armv7 phone at hand (Hi from Kyoto) 2024-08-23 16:27:28 :) 2024-08-23 16:27:30 enjoy 2024-08-23 16:27:56 ACTION can eat 1 ton of Sushi at once. Just the wallet gets sad afterwards 2024-08-23 16:29:24 What I'm thinking is to implement some mesa tests (at least with llvmpipe), this stuff would get caught by the build) 2024-08-23 16:30:18 Debian does them, but I haven't looked how it's done yet 2024-08-23 18:27:37 hello, can anyone tell me why https://alpinelinux.mirrors.ovh.net/ doesn't appear in the list of mirrors? raspbeguy told me it had to do with the lack of "Last-Modified" header but I fixed this more than 24 hours ago, do i need to wait some more? 2024-08-23 18:28:28 sbraz: raspbeguy didn't let us knwo 2024-08-23 18:28:32 we need to re-add the mirror 2024-08-23 18:29:06 ikke: oh I didn't know I needed to notice you after fixing it 2024-08-23 18:29:33 We needed to remove it because it prevented the mirrors to be updated 2024-08-23 18:31:00 oh sorry about that :) 2024-08-23 18:31:59 i came here as it seemed better to directly contact you without bothering raspbeguy :) (sup raspbeguy, how are you?) 2024-08-23 18:32:27 sbraz: I'm fine. 2 weeks off 2024-08-23 18:32:46 i know, that's why i tried to avoid bothering you :D 2024-08-23 18:33:25 That's ok. Alpine isn't part of my work duties so I'm still here 2024-08-23 18:33:53 ikke: if you need anything about our mirror, feel free to ping me here or on freenode, and i think we also provided an email alias which my colleagues and i read 2024-08-23 18:34:54 thank you. I'm trying to run the mirror update cron now to see if it works 2024-08-23 18:35:08 s/freenode/libera/ doh 2024-08-23 18:35:43 heh :D 2024-08-23 18:40:14 https://mirrors.alpinelinux.org/#mirror86 2024-08-23 18:41:08 beautiful :D 2024-08-23 18:42:17 weird that it says we have 10h old content as we sync twice a day and the last sync was 2 hours ago 2024-08-23 18:43:41 is the list somehow sorted or do newer mirrors go to the end? 2024-08-23 18:44:50 Yes, it's in the order we add them to a yaml file 2024-08-23 18:45:02 So new mirrors just get appended 2024-08-23 18:51:15 ikke: can you tell me which file is checked for each version? i'd like to check my http logs to understand why edge appears so outdated 2024-08-23 18:51:41 sbraz: It checks the APKINDEX 2024-08-23 18:51:55 It compares it against dl-cdn 2024-08-23 18:53:06 Thats a lot of mirror 2024-08-23 18:53:48 ikke: is that a curl from a UK host? the last one was done at 14:00 UTC which could explain the delay? 2024-08-23 18:55:29 No, the request is done from deu1-dev1.alpinelinux.org, from frankfurt 2024-08-23 18:56:02 sbraz: I just ran it 2024-08-23 18:56:14 before I gave the link 2024-08-23 18:56:47 ah right i see it now from a lua-http UA 2024-08-23 18:57:00 nod 2024-08-23 18:58:43 stat -c %y v3.20/main/x86/APKINDEX.tar.gz → 2024-08-23 06:29:13.815309588 +0000 2024-08-23 18:58:53 so the mirror we rsynced from is not fresh, weird 2024-08-23 18:59:27 rsync.alpinelinux.org resolves to 147.75.40.42 on the host running rsync, at least it did right now 2024-08-23 19:01:46 and last-updated was modified on 2024-08-23 16:00:00.585626555 +0000 2024-08-23 19:02:57 rsync rsync://rsync.alpinelinux.org/alpine/v3.20/main/x86/APKINDEX.tar.gz → "-rw-r--r-- 469,733 2024/08/23 06:29:13 APKINDEX.tar.gz" 2024-08-23 19:03:50 ikke: so the issue is that this rsync server is out of date? 2024-08-23 19:04:22 But that's the same server that backs dl-cdn 2024-08-23 19:04:31 servers* 2024-08-23 19:04:36 It's an anycast address 2024-08-23 19:04:53 i tried from Canada and India i get the same result 2024-08-23 19:05:58 USA and Australia too for good measure: it's still this morning's file 2024-08-23 19:07:16 sorry that's not the community file 2024-08-23 19:08:39 OK all good, sorry for the noise, v3.20/community/x86/APKINDEX.tar.gz was updated at 16:50 and the sync was just before this 2024-08-23 19:09:06 ah, so unfortunate timing 2024-08-23 19:09:25 so because we sync twice a day, the age could be almost as much as 24 hours 2024-08-23 19:09:55 Yeah, but that's fine 2024-08-23 19:11:21 i'm gonna disconnect from the work computer, thanks for your help and have a great weekend :) 2024-08-23 19:12:17 You enjoy your weekend as well 2024-08-24 08:08:00 gitlab has been upgraded to 17.2 2024-08-24 08:08:10 o/ 2024-08-24 08:08:23 \o/ 2024-08-24 08:10:23 \o/ 2024-08-24 10:01:47 \o/ 2024-08-24 12:22:04 elly: would you mind cleaning up your dev container on nld-dev-1 a bit? 2024-08-24 13:03:31 hey there, I'm trying to fix something in uv package which was recently merged into main branch. This is the topmost commit on aports repo. 2024-08-24 13:03:31 ```bash 2024-08-24 13:03:31 The job is passing on GitLab https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1492916 but when I try to run `abuild -r` in `community/uv` directory, I'm running into following errors. 2024-08-24 13:03:31 This means that I'm not understanding something `abuild -r` is my primary way to build package in any directory where I've a `APKBUILD` file and it's working for some go package bu failing for this one. 2024-08-24 13:03:32 📡 Using build options bindings from pyproject.toml 2024-08-24 13:03:34 error: rustc 1.78.0 is not supported by the following packages: 2024-08-24 13:03:36 cache-key@0.0.1 requires rustc 1.80 2024-08-24 13:03:38 distribution-filename@0.0.1 requires rustc 1.80 2024-08-24 13:03:40 distribution-types@0.0.1 requires rustc 1.80 2024-08-24 13:03:42 install-wheel-rs@0.0.1 requires rustc 1.80 2024-08-24 13:03:44 once-map@0.0.1 requires rustc 1.80 2024-08-24 13:03:46 pep440_rs@0.6.0 requires rustc 1.80 2024-08-24 13:03:48 pep508_rs@0.6.0 requires rustc 1.80 2024-08-24 13:03:50 platform-tags@0.0.1 requires rustc 1.80 2024-08-24 13:03:52 pypi-types@0.0.1 requires rustc 1.80 2024-08-24 13:03:54 requirements-txt@0.0.1 requires rustc 1.80 2024-08-24 13:03:58 uv@0.3.3 requires rustc 1.80 2024-08-24 13:04:00 uv@0.3.3 requires rustc 1.80 2024-08-24 13:04:02 uv-build@0.0.1 requires rustc 1.80 2024-08-24 13:04:04 uv-cache@0.0.1 requires rustc 1.80 2024-08-24 13:04:06 uv-cli@0.0.1 requires rustc 1.80 2024-08-24 13:04:08 ``` 2024-08-24 13:05:50 what does `apk version rust` return? 2024-08-24 13:05:57 (and please, use a paste service next time) 2024-08-24 13:10:38 Thanks ikke, Please find more details here https://paste.mozilla.org/8AcBZRnZ 2024-08-24 13:11:21 What is the contents of /etc/apk/repositories? 2024-08-24 13:12:36 https://paste.mozilla.org/GEAOaXWG (this looks normal) 2024-08-24 13:12:51 `latest-stable` 2024-08-24 13:12:56 You need to use edge 2024-08-24 13:13:29 Alpine 3.20 only has rust 1.78 2024-08-24 13:19:47 I think the takeway for me is that, I'll have to put append edge repositories into /etc/apk/repositories while I build packages using `abuild -r`. 2024-08-24 13:22:25 Just adding those repos is not enough and might lead to things breaking 2024-08-24 13:22:33 You need to make sure all packages are upgraded 2024-08-24 13:24:43 Yes, I ran apk update after adding edge repositories. I hope that suffice for building all packages. 2024-08-24 13:27:02 apk upgrade --available as wlel 2024-08-24 13:28:23 thanks, noted!! 2024-08-24 13:35:48 The alternative is to build in the 3.20-stable branch instead of edge 2024-08-24 13:36:04 (master) 2024-08-24 13:43:34 thanks noted. I'll clone the git repo using `git clone -b 3.20-stable` and every invocation of `abuild -r` should work. But given I want to build packages and contribute, I think cloning master and adding patches would be more ideal. But I'll try out both before I make my mind on which one to use. 2024-08-24 13:44:49 If you want to contribute to `edge`, you should build on edge/master 2024-08-24 13:45:21 You could also use abuild rootbuild (after installing abuild-rootbld) to build in a dedicated (temporary) chroot 2024-08-24 13:45:50 But that makes it harder to debug things when they fail 2024-08-24 13:47:46 I probably want to contribute to some packages in testing directory as my starting point so I'll clone master and send a patch to master branch. For now, I'm sticking for `abuild -r` and after I'm done with doing some patches, I'll try out abuild rootbuild for sure once I start feeling a bit comfortable. 2024-08-24 21:03:40 Can any room admins/mods on the Matrix side please kick & ban these spambots? 2024-08-24 21:12:27 There are no Matrix-side admins or mods 2024-08-24 21:12:28 Hi jahway603[m], how are you? I am curious, what does the [m] stand for by nicknames on IRC? 2024-08-24 21:12:39 A Matrix user 2024-08-24 21:12:48 Using IRC channels inside matrix? 2024-08-24 21:12:55 Yes, through a bridge 2024-08-24 21:14:57 BlueCrayon: Yes, the [m] means I'm a Matrix user bridged to this IRC channel. 2024-08-24 21:17:40 :) 2024-08-24 21:18:26 jahway603: note that in a IRC-first channel like this you should refrain from using features that IRC doesn't support like replies as they don't transfer well 2024-08-24 21:19:28 that reply transferred fine though 2024-08-24 21:19:56 it's mostly multiline/quote/edit that don't 2024-08-24 21:20:32 I guess they changed that replies no longer quote the orignal message on irc 2024-08-24 21:20:36 PureTryOut (matrix.org) alright, I will remember that. 2024-08-24 21:21:15 I guess they changed it, but I'd still recommend against using them to be safe. No worries about Matrix-first rooms though 👍️ 2024-08-24 21:49:00 Interesting 2024-08-25 05:14:58 I have serious question for zsh users: why isn't "apk add alpine-zsh-config" default in Alpine? The zsh experience without it is painful and it's just few default settings happily adjusted by anyone.. but still better than default: no-history, no-shortcuts IMHO 2024-08-25 05:23:15 i just checked default zsh and C-r history works, which kind of history do you mean 2024-08-25 05:51:19 maybe arrows? 2024-08-25 05:54:45 take cover! 2024-08-25 06:01:42 also does 2024-08-25 06:12:27 No history, no ctrl-[left|right] arrow, IMHO it's not unreasonable to expect this as a default, at least Debian and all bashes I ever used offer it 2024-08-25 06:15:04 I thought it was bug, but as I get it, it's just empty config to start with 2024-08-25 07:11:33 I never used that pkg it didn't know about it, let me check what it does 2024-08-25 07:18:12 Or maybe oh my zsh overwritten some default, but still don't happen on other distros. If someone has better insight, I can try help figure it out, but in general I'm middle of fixing other stuff, so I'll just try my best 2024-08-25 09:20:12 i think it 2024-08-25 09:20:47 it's unreasonable to provide a custom config with a package by default, as i generally just have my own config 2024-08-25 09:21:22 so i'd have to overwrite those defaults instead of overwriting the zsh defaults which are same everwhere 2024-08-25 09:42:17 caskd: i think that is a good point 2024-08-25 10:14:39 the cross compiled part of the SuperH port boots on real hardware \o/ 2024-08-25 10:17:08 cool 2024-08-25 10:17:30 i mean, we all know that that was the easy part :D 2024-08-25 16:44:10 about the yarn-berry aport, previous week discussion we had, the issue is under moving on discussion but I dont know what to say 2024-08-25 16:44:41 #16384 2024-08-25 17:20:01 Does someone one how to contact @jirutka? I wrote him a email a week ago but got no response... 2024-08-25 20:01:34 Can someone point me to a contributing guide for apk packages? I found one that’s not in any repositories yet. 2024-08-25 20:01:34 In addition, is it possible to create some kind of a “local” repository that I hook up to apk and where I put the instructions to build/install. 2024-08-25 20:01:34 I maintained some FreeBSD ports several years ago and I’m wondering whether Alpine’s packaging system and contributing to it works similar. 2024-08-25 20:05:35 https://wiki.alpinelinux.org/wiki/Developer_Documentation 2024-08-25 20:07:45 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2024-08-25 20:10:13 Appreciated! 2024-08-25 20:17:22 there's also the .md files in the root of the aports repo 2024-08-26 01:18:26 hey folks, would you accept a patch to abuild to disable specific dependency tracing? My usecase is that I'm trying to package multiple versions of the python interpreter (like deadsnakes on debian/ubuntu). The python dependency tracer identifies that each version requires /usr/bin/python3 to link to its version of python, although this isn't correct. It would be nice to disable that tracer specifically; rather than my current 2024-08-26 01:18:26 workaround of building it with tracing enabled, copying the other inferred dependencies, and then rebuilding. I'm open to other approaches, either for a patch or a workaround. 2024-08-26 01:25:15 what's not correct about it? 2024-08-26 01:27:37 if the package itself has a /usr/bin/python3 -> 3.something symlink then it sounds normal that that package owns /usr/bin/python3, and you probably want to delete that symlink and keep only the versioned name 2024-08-26 01:27:51 i don't think abuild does any magic tracing there 2024-08-26 01:28:38 i.e. the inferred dependency list doesn't include anything involving /usr/bin/python3 2024-08-26 01:34:19 The package itself does not have that symlink. There's a flag for compiling python to enable/disable that specifically (`--enable-shared` will create the symlink). The main alpine package has that enabled, and the packages I'm building do not. 2024-08-26 01:34:19 The dependency is inserted in abuild.in in the function scan_python3_dependency (line 1734 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L1734). It doesn't check specifically for a linked /usr/bin/python3, but checks (in effect) for installed pythons 2024-08-26 01:35:22 but it's only checking what is in the pkgdir isn't it 2024-08-26 01:35:27 why are there multiple python versions installed in there 2024-08-26 01:35:44 you should have a separate build per version 2024-08-26 01:37:50 i assume you're getting bitten by the if [ "$dir_count" -gt 1 ]; error 2024-08-26 01:41:14 if you have a template for "python3.10" and it builds "3.10" and installs it and there is a python3.10 in site-packages and /usr/bin/python3.10 and nothing else, that package will correctly have a 'python3.10 dependency' (effectively on itself, but harmless) and that doesn't break anything 2024-08-26 01:41:58 and i think if you had multiple python versions in the same template, and all in a separate subpackage, it also works because it's only scanning individual subpackages 2024-08-26 01:42:08 so the only way i see this doesn't work is if the same package has multiple python versions in the pkgdir 2024-08-26 01:42:13 yeah, it's only scanning the packagedir, and there aren't multiple python versions in it. I've got a separate build per version. It actually builds fine, but there's a constraint that shouldn't be there. Each package doesn't touch /usr/bin/python, only /usr/bin/python3.9 . But there's still a constraint generated resulting in python39-3.9.19-r1[python3~3.9], which prevents it from being installed (conflicts with the main 2024-08-26 01:42:13 python3 package) 2024-08-26 01:42:28 ah i see 2024-08-26 01:43:13 you probably want to change 2024-08-26 01:43:14 if [ -n "$pyver" ] && [ "${subpkgname:-$pkgname}" != python3 ]; then 2024-08-26 01:43:19 to do != python3* 2024-08-26 01:43:22 (however that works) 2024-08-26 01:43:32 then the 'python39' 'python3.9' or whatever packages will skip this 2024-08-26 01:43:37 and i think that should work :) 2024-08-26 01:44:05 i wrote this code but didn't think people were building separate python versions to parallel install on their own 2024-08-26 01:47:02 writing the actual glob sounds annoying, maybe && [ "${${subpkgname:-$pkgname}%python3*}" == "" ] 2024-08-26 01:47:05 i don't like it either 2024-08-26 01:47:19 but you'll figure it out 2024-08-26 01:47:54 or well, != 2024-08-26 01:49:31 neat, that's a more robust change. I'll work away at the glob. Thanks! 2024-08-26 01:49:32 i guess making it use an options= value makes more sense as you suggest 2024-08-26 01:50:17 if i was still working on it i would do that and then put the options="!tracepython" on main/python3 and then you could reuse it 2024-08-26 01:50:22 but open an abuild issue/mr and go from there 2024-08-26 01:50:40 i can see the glob being bad because there are packages that start with python- or python3- and it would catch them all and remove the trace 2024-08-26 02:00:55 oh, yeah, that's true. The glob would have to exclude those. I guess we could filter on packages that are just "python" followed by digits, but that imposes more constraints. I'll open issues for both and we'll go from there 2024-08-26 08:55:26 Anyone else for which the shortcuts `c` and `x` (next / previous commit) on a page like https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70784/diffs?commit_id=fb117120d943fed86a178e8322c5e2ab20b809b2 does not work? 2024-08-26 09:13:59 not work here too (win firefox) 2024-08-26 15:20:21 fossdd: why the backport for 3.20 for jellyfin 10.9.9? 2024-08-26 15:52:19 because the changes are just minor patches and i thought they didn't hurt on 3.20 2024-08-26 18:14:21 wfm 2024-08-26 18:15:01 i usually dont bother with 3.20 if it's not CVE, but if you send them ill merge them 2024-08-26 18:28:24 It's not a problem to backport bugfixes and non-breaking improvements either 2024-08-26 18:29:46 yeah, i was just curious about the motivation because it's usually something i overlook 2024-08-26 20:18:48 yeah i also often forget that but i think its nice to backport bugs fixes from time to time 2024-08-26 20:19:56 yup 2024-08-26 20:26:01 indeed, my server is on 3.20 and i was happy to get the 10.9 update, there's been a warning on my clients for a while 2024-08-26 21:48:23 isn't -Wno-implicit-function-declaration more of a workaround than a fix? 2024-08-27 01:08:49 omni: you mean the option as a whole ? 2024-08-27 01:13:24 I mean #16335 and !70998 and !70999 2024-08-27 01:30:46 omni: yes, it is a workaround until you have the configure scripts regenerated with latest autoconf where the configure tests are fixed to use proper function signatures 2024-08-27 01:34:16 see https://github.com/autotools-mirror/autoconf/commit/bf5a75953b6d504f0405b1ca33b039b8dd39eef4 2024-08-27 01:38:13 ok, I haven't really followed this more than seen that most fixes seem to have been more involved patches https://git.alpinelinux.org/aports/log/?qt=grep&q=fix+build+with+gcc+14 2024-08-27 04:35:03 -Wimplicit-function-decleration is not about function signatures 2024-08-27 04:35:14 or rather, incorrect signatures 2024-08-27 09:08:00 i'm having trouble trying to get a branch from gitlab locally 2024-08-27 09:08:08 git fetch --all doesn't get it 2024-08-27 09:08:31 i only have up to 3.18-stable but want 3.20-stable 2024-08-27 09:08:49 anyone know why the ref isn't fetched? 2024-08-27 09:09:25 i pull via ssh but i assume it wouldn't change anything 2024-08-27 09:11:56 git branch -r doesn't list the 3.20-stable, neither 3.19-stable 2024-08-27 09:14:42 which remote do you fetch? 2024-08-27 09:15:21 f9bb1c560eaeea6ed220dc36bd95f2cedff4f8ae introduced a circular dep: kirigami -> qqc2-desktop-style -> kirigami 2024-08-27 09:51:32 caskd: if you cloned with --branch, the default fetchspec is set to ever only fetch that branch 2024-08-27 10:03:26 i didn't though 2024-08-27 10:03:33 i also did fetch --all 2024-08-27 10:03:44 so i'd assume everything would be 2024-08-27 10:04:13 wrt implicit above: that is also an assumption that in this case the configure scripts are even the issue 2024-08-27 10:04:17 i fetch remote ssh://gitlab.alpinelinux.org/alpine/aports 2024-08-27 10:04:28 anyway there's patches, as I've said before, available in gentoo/fedora at least for anything popular now 2024-08-27 10:04:36 (and upstreamed) 2024-08-27 10:06:05 re-cloning the repo anew provides me the 3.20 2024-08-27 10:06:08 so i'm confused 2024-08-27 10:08:11 okay, so the issue was https://stackoverflow.com/questions/11623862/fetch-in-git-doesnt-get-all-branches 2024-08-27 10:08:56 i had it the same as top answer 2024-08-27 10:18:24 caskd: yes, what I said, fetched with --branch or --depth 2024-08-27 10:18:56 caskd: fetch --all means fetch from all remotes, not fetch all references 2024-08-27 10:21:39 welp... 2024-08-27 10:21:55 i don't recall only fetching master but it might've been a long time ago 2024-08-27 10:22:11 sorry, s/fetched/cloned 2024-08-27 10:44:59 ptrc: seems like forgejo-runner moved to code.forgejo.org, source is currently 404 (the entire repo is gone) 2024-08-27 11:03:48 will the CI be unhappy if i introduce a check for a CARCH which is not yet known to apk-tools and abuild? 2024-08-27 11:03:57 in an APKBUILD 2024-08-27 11:05:27 No 2024-08-27 11:06:04 oh, ok, ngl, I was expecting a yes :D 2024-08-27 11:06:34 It does not really care if you check for something that will never evaluate to true on Alpine Linux 2024-08-27 11:16:41 should enabling tests for some architectures result in a increased pkgrel? 2024-08-27 11:17:12 no 2024-08-27 11:17:26 or depends 2024-08-27 11:17:41 If you want to make sure those tests run and pass on the builders, you have to 2024-08-27 11:21:20 hmmmm, i think i'll leave that up to whoever decides to merge it 2024-08-27 11:28:51 unaproved bashisms :O 2024-08-27 11:32:19 but it passed on the architectures i touched :) 2024-08-27 11:33:13 huh, that's unexpected 2024-08-27 11:34:05 what? 2024-08-27 11:34:10 the unapproved bashism 2024-08-27 11:34:19 it should not trigger on '=' 2024-08-27 11:34:21 i did a == the first time around 2024-08-27 11:34:27 ah ok :D 2024-08-27 11:34:34 good then 2024-08-27 11:34:49 i could also fix the tabs vs spaces, but i din't introduce that ;) 2024-08-27 11:35:04 yeah, understood 2024-08-27 11:35:13 should i? 2024-08-27 11:37:52 ok, lint deserves to be happy 2024-08-27 11:40:30 x86_64 failed, wtf 2024-08-27 11:40:46 oh, connection issue 2024-08-27 11:48:05 riscv segfaulted for some reason 2024-08-27 18:09:19 when trying to build perl (for sh3, obviously ;D ) i get a bunch of "File foobar is read-only; trying to patch anyway" during the prepare phase, what's that all about? 2024-08-27 18:09:51 $ apk version -t 2024.8.8 2024.08.14 2024-08-27 18:09:51 > 2024-08-27 18:10:06 bleh... why does apk think that 8 > 08 2024-08-27 18:14:56 also ikke: thanks for the hint ^^ 2024-08-27 19:30:01 pretty sure it compares versions lexicographically so '8' > '0' and thus "8" > "08" 2024-08-27 19:59:44 no, 8 > 08 is an exception 2024-08-27 20:02:48 I think it comes from: 1.1 > 1.0001 2024-08-27 20:03:11 1.1 > 1.0002 2024-08-27 20:03:43 1.1 > 1.002 2024-08-27 20:03:47 1.1 > 1.02 2024-08-27 20:03:55 1 > 02 2024-08-27 20:07:34 which also means that 8 > 08 2024-08-27 20:07:53 yeah, that makes sense. Just checked version.c and it opts in to strcmp when comparing numbers with leading zeros 2024-08-27 20:39:07 oh 2024-08-27 20:39:10 that's kinda silly 2024-08-27 21:25:33 i think it was added as some exception for like readline versioning 2024-08-27 21:25:37 but i forget now 2024-08-27 21:52:55 i wonder if there is anyone actually using these DDX modules 2024-08-27 21:53:02 like xf86-video-rendition 2024-08-28 00:20:04 Ariadne: i've been occasionally using xf86-video-tdfx :D 2024-08-28 08:43:41 ncopa: I made an initial MR to get abuild to warn about the non-usr locations as agreed by the TSC https://gitlab.alpinelinux.org/alpine/tsc/-/blob/master/minutes/2024-08-15.md?ref_type=heads#implement-usr-merge-73 2024-08-28 08:54:22 great! 2024-08-28 08:54:40 we probably need to announce it somewhere 2024-08-28 08:54:57 Uh I meant https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/308 2024-08-28 09:06:21 ncopa: a blog post on https://alpinelinux.org/posts/ I guess? 2024-08-28 11:19:35 i just ran into a very annoying problem while building gcc for sh3, after successfully comparing stage 2 and 3 a bunch of segfaults, all within go-related parts so far, could i still be able to salvage this, since we do not have checks on gcc? 2024-08-28 13:20:36 There are people that want wayland-1.23.1 in 3.20. May I push it there? 2024-08-28 13:22:06 looks like we currently have wayland 1.22 there, why do they need 1.23.1? 2024-08-28 14:46:28 ncopa: wayfire wants it for their Alpine-based CI 2024-08-28 15:00:08 and they don't want to go edge because they catched a clang bug in edge 2024-08-28 15:58:17 ikke: would it be possible to use predictable ids for the elements from https://mirrors.alpinelinux.org/? i assume #mirror2 would become #mirror1 if #mirror1 were removed, which is not ideal if we want some kind of permalink 2024-08-28 15:59:56 incidentally it looks like the link to our (OVHcloud) mirror's status is broken href="#mirror87" when the id is 86 2024-08-28 17:12:28 nmeum: not sure if you have already done so, but I've beeing going through community and testing to test packages against go1.23 2024-08-28 17:13:11 did you find anything? 2024-08-28 17:13:15 Yes 2024-08-28 17:13:20 I've already created some tickets 2024-08-28 17:13:22 we actually had a regression with go1.23 at $dayjob 2024-08-28 17:13:31 hence I was reluctant to update so far 2024-08-28 17:13:34 https://gitlab.alpinelinux.org/alpine/aports/-/issues/?sort=updated_desc&state=opened&search=go1.23&first_page_size=20 2024-08-28 17:13:44 nmeum: ah ok, what kind of regression? 2024-08-28 17:13:54 some sort of deadlock in the runtime that needs to be debugged further 2024-08-28 17:14:00 oh, that's anoying 2024-08-28 17:14:23 in general my impression so far was that the .0 Go releases are not suppeerr well tested 2024-08-28 17:15:01 I also came accross a patch from you fixing go 1.23 compattibility somewhere :) 2024-08-28 17:16:23 Oh no, gcc 14 compat 2024-08-28 17:16:25 https://github.com/containers/storage/commit/27a6e9a5ac6f9241779dbb3125f02c6f0efc819c 2024-08-28 17:16:42 do we just want to push the 1.23 update though or still wait a bit? 2024-08-28 17:17:26 good question, maybe wait a bit? the loongarch builder is already backlogged due to gcc 14 build issues 2024-08-28 17:17:37 But it would be nice to have 1.23 as well 2024-08-28 17:18:06 yea 2024-08-28 18:13:25 i've had a dayjob thing require 1.23 recently and that works ok (hence why i was asking about it before) 2024-08-28 18:14:27 small thing though. 2024-08-28 18:20:32 we had like 30-40 ancient go packages ftbfs on 1.23, and maybe 1-2 actual failures (on void) 2024-08-28 20:22:01 psykose: Heya. I found commit 8077faa5845929d2532312f1add8d33b72595bd5 in aports, it point to my MRs (one closed thou) about enforcing using SSE2 fpu operation mode, which... improves reliability and precision of Mesa (in test suites), can you be more specific whats wrong with it? IMHO problem is that LTO is generally unstable with mesa :( https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21371 2024-08-28 20:22:41 back then that didn't build 2024-08-28 20:23:49 forgot what error it was 2024-08-28 20:32:32 I'll keep it for r0 since it's bump, but after few weeks (to prevent bogus reports, I would try re-enable LTO, if it'll compile) 2024-08-29 02:17:23 Hey folks, when I'm trying to build my own copy of a package from aports I'm getting an error Is $builddir set correctly. Any idea where I should be looking for that, I can't seem to find any documentation on that variable/env-var? I'm getting the same result from abuild rootbld and abuild -r 2024-08-29 04:24:51 jaitaiwan[m]: usually means the $builddir path doesn't exist 2024-08-29 04:25:19 by default $builddir is $srcdir/$pkgname-$pkgver 2024-08-29 04:25:19 Where’s that supposed to be set though? 2024-08-29 04:25:25 in the apkbuild 2024-08-29 04:25:56 Doesn’t seem to mention builddir 2024-08-29 04:25:56 Is it specified in a variable? I’m working off a copy of main/openrc 2024-08-29 04:26:38 e.g. https://wiki.alpinelinux.org/wiki/APKBUILD_examples:Simple 2024-08-29 04:27:13 it's an optional field in that if the default path exists, then it doesn't need to be set 2024-08-29 04:28:02 example when it's needed is when the source directory extracted from the tarball has a different name than $pkgname 2024-08-29 04:28:38 Cheers appreciate the breadcrumbs, that will help me to understand why it’s not being created or referenced properly 2024-08-29 04:29:38 you're welcome ... for other variables they're covered in https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2024-08-29 04:30:05 Champion, thanks 2024-08-29 06:56:27 pnpm self upgrade feature dont work (as expected) should I patch it to disabled it? dont think they are thinking in disable it upstream 2024-08-29 13:34:28 4 chromium pipelines have been running for 12 hours.. 2024-08-29 15:08:42 chromium 2024-08-29 16:06:12 Where can I offer wishes for the list of packages of which are missing in the official repository? 2024-08-29 16:08:51 The question has already answered ... Thank you! 2024-08-29 16:28:41 17:58 < sbraz> ikke: would it be possible to use predictable ids for the elements from https://mirrors.alpinelinux.org/? i assume #mirror2 would become #mirror1 if #mirror1 were removed, which is not ideal if we want some kind of permalink 2024-08-29 16:28:45 17:59 < sbraz> incidentally it looks like the link to our (OVHcloud) mirror's status is broken href="#mirror87" when the id is 86 2024-08-29 16:34:13 Hi, I need some help on this issue #16384 and the MR 2024-08-30 13:57:10 raspbeguy: do you know who else handles the mirror status page? regarding my question from yesterday 2024-08-30 13:59:08 sbraz: clandmeter, and sorry, I've been a bit distracted 2024-08-30 14:07:57 ikke: no problem at all, i can file a bug report or something if it helps 2024-08-30 14:08:55 the idea behind permalinks to each mirror's status would be to have some kind of index page listing all the mirrors we manage along with a "mirror status" page for each of them, ubuntu, debian, arch, etc. 2024-08-30 14:15:03 Yes, understood 2024-08-31 07:57:42 https://tpaste.us/lgxa 1. why the heck does building apk-tools involve other parts of the aports tree? 2. I also had errors about atomic stuff when trying to build openssl for the first time, but i resolved them, why are they cropping back up now? 2024-08-31 07:58:33 other parts of aports tree in what sense 2024-08-31 07:58:54 /usr/lib/gcc/sh3-alpine-linux-musl/14.2.0/../../../../sh3-alpine-linux-musl/bin/ld: /home/socksinspace/aports/main/openssl/src/openssl-3.3.1/crypto/threads_pthread.c:905:(.text+0x8d4): undefined reference to `__atomic_load_8' 2024-08-31 07:59:02 like that 2024-08-31 07:59:24 not sure i understand 2024-08-31 07:59:32 you mean the fact it prints the /home path? 2024-08-31 08:00:06 i'm building aports/main/apk-tools, why does it have aports/main/openssl in there? 2024-08-31 08:00:36 you're asking why the linker is telling you that? 2024-08-31 08:00:52 because the debug paths contain the whole filepath unless remapped from where it's built 2024-08-31 08:00:57 ahhh 2024-08-31 08:00:58 ok 2024-08-31 08:01:15 normally you fix it with something like https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10104 2024-08-31 08:01:48 as for atomic it looks like your architecture has a separate libatomic or something and is not linking it 2024-08-31 08:01:58 you can see the full linker invocation and see if -latomic is there 2024-08-31 08:02:01 was something like that 2024-08-31 08:03:12 gonna guess the gcc enable-autolink-atomic doesn't trigger for superh or something 2024-08-31 08:12:16 how do i find out how exactly the linker was called, abuild -v doesn't give any more verbose output in that specific area 2024-08-31 08:13:49 except that it was during the build of the static apk-tools, but i knew that already 2024-08-31 08:16:40 for apk, change the apkbuild to add V=1, or use something like extrace 2024-08-31 08:58:32 ok so i tried alpine linux and i like it. but it's missing some software i want, i just skimmed through developer reference... modplug123, detox, far2l, fnt, ruptime, w, dict, finger... 2024-08-31 09:00:14 detox and finger are in the testing repos, as for the others i dont know but you're free to package it :) 2024-08-31 09:00:25 aren't you the author of modplug123 yourself 2024-08-31 09:00:42 psykose: yes 2024-08-31 09:01:16 so in /etc/apk/repositories i have main and community, i just add testing? or does it work different? 2024-08-31 09:01:43 psykose: was it here, i can't package my own stuff, then i'll want opencubicplayer 2024-08-31 09:01:47 yeah, but you should be on the edge channel 2024-08-31 09:03:06 perfect that works :) 2024-08-31 09:05:40 https://tpaste.us/d1mj ok, after first putting the V=1 with the apk-specific things i realised you meant i should put it with the `make` invocations. I do not see any calls to ld here, or should the -latomic be with the flags passed to gcc? 2024-08-31 09:11:14 aha i can't find libbz2-dev :( 2024-08-31 09:12:19 bzip2-dev? 2024-08-31 09:13:19 and i was search bunzip but tried bzip but found no -dev, but installing it just worked 2024-08-31 09:26:02 i'm running out of places to cram "-latomic" into 2024-08-31 14:58:55 socksinspace, some days i wonder if we should have stuck that into libc 15 years ago 2024-08-31 15:42:26 too late to worry about that now :P 2024-08-31 15:43:12 i'll figure it out eventually ... or at least i hope so 2024-08-31 15:44:42 yeah 2024-08-31 15:44:58 i just feel stupid every time i add a few lines of autoconf or meson to handle -latomic 2024-08-31 15:46:41 It seems that fortify-headers + gcc is broken 2024-08-31 15:46:56 /usr/include/fortify/string.h:297:36: error: implicit declaration of function 'strnlen'; did you mean 'strlen'? [-Wimplicit-function-declaration] 2024-08-31 15:46:56 /usr/include/fortify/string.h: In function 'strncat': 2024-08-31 15:47:32 This is with a simple file that includes string.h and call strncat, built with c99 -O1 f.c 2024-08-31 16:08:30 Seems to be caused by d259429, which introduces a non-STDC function without guard 2024-08-31 19:13:42 i ran out of ideas, for now i just skip building static apk-tools, not like anyone else does sh3 anyway