2022-10-01 08:30:43 PureTryOut: any thought on qt6.4? 2022-10-01 08:36:30 Does anyone have any idea why there doesn't seem to be an approval button anymore for MRs assigned to me on Gitlab? 2022-10-01 08:37:38 boomanaiden1542: Something changed in gitlab 15.2 2022-10-01 08:38:15 Fun. So to note that I approve changes to packages that I maintain I should just comment instead? 2022-10-01 08:39:04 boomanaiden1542: It appears that guest members do still see the merge request approval button. We have an idea to add every package maintainer as a guest to aports 2022-10-01 08:39:52 It would make sense that it's a permissions thing. Do you mind giving my account guest permissions? It should be @boomanaiden154 on Gitlab. 2022-10-01 08:40:42 done 2022-10-01 08:41:17 Back to being able to approve MRs. Thank you. 2022-10-01 08:43:18 Found it: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90681 2022-10-01 08:43:29 Had to dig into the changelog to find it 2022-10-01 08:44:11 This talks about authors, but apparently that also affects assignees 2022-10-01 08:52:45 @psykose sorry I haven't had the time to look at it yet. Currently watching a talk about Qt at a conference actually lol 2022-10-01 08:52:53 haha, how topical 2022-10-01 08:53:13 looks quite normal, just curious about the gles thing 2022-10-01 10:28:54 Yeah I don't understand how enabling GLES makes other issues appear 2022-10-01 10:29:24 But I rather have it enabled and if GLES isn't the cause of the problems, then I see no reason to not enable it 2022-10-01 10:42:38 ok, i'll toggle it on. if you run into anything let me know first to sanity check it 2022-10-01 10:44:28 also didn't change depends_dev as mesa-dev already pulls mesa-gles 2022-10-01 15:58:25 Yeah sure 2022-10-01 16:02:05 can merge it if you're fine with it 2022-10-01 16:10:05 thanks :) 2022-10-01 16:10:34 now someone should probably check out if the gles2 thing works for qt6 things on some phones 2022-10-01 16:10:39 np, thank you for figuring out the GLES thing! 2022-10-01 16:10:50 yeah will do once it's all built 2022-10-01 16:10:58 (for at least 1 phone) 2022-10-01 16:11:28 1 phone that doesn't support desktop gl would be quite representative (assuming currently you cannot use such apps at all) 2022-10-01 16:12:48 also, do you have any opposition to moving the vulkan* things to main? it would allow building the mesa zink driver 2022-10-01 16:12:56 basically no phone supports desktop GL. Well that's not entirely true, they support it partially 2022-10-01 16:13:05 yeah, exactly :) 2022-10-01 16:13:09 but just to be specific 2022-10-01 16:13:23 like freedreno only supports up to 1.something 2022-10-01 16:13:37 I have no problems with moving vulkan* no 2022-10-01 16:13:45 alright, will set that up 2022-10-01 16:13:50 oh sorry, freedreno supports up to 3.3 2022-10-01 19:03:19 sam_: don't suppose you know a thing about dbus/webkit by chance 2022-10-01 19:04:26 there's this thing https://gitlab.gnome.org/GNOME/epiphany/-/issues/1852 which has this https://gitlab.gnome.org/GNOME/epiphany/-/issues/1852#note_1563239 as some explanation (then a bunch of links) 2022-10-01 19:05:02 but even setting it to non-abstract (7c88121d0557c17b34c84bfa7f893faf4e26181a) doesn't actually work for epiphany via webkit2gtk still, though the error changes 2022-10-01 19:05:17 don't exactly have any ideas as to why 2022-10-01 19:07:15 beginning to suspect it's also a "not systemd" issue and not just some socket stuff 2022-10-01 19:13:01 (only present now with epiphany 43, since commit https://gitlab.gnome.org/GNOME/epiphany/-/commit/88cb0505cf55069f3aa36e50595cc2e32fc3bd38 which does some stuff via libportal that triggers all this) 2022-10-01 19:14:43 this very singular thing is blocking merging all of gnome 43 which is annoying 2022-10-01 21:32:15 went ahead without it i guess 2022-10-01 21:32:27 sam_: also have you tried a world dt_relr rebuild yet 2022-10-01 23:38:17 ah right, it was non-private /tmp not being mounted into sandbox 2022-10-01 23:38:21 not even sure how to fix that 2022-10-02 03:06:11 is it a reportable bug for -dev packages to lack static versions? 2022-10-02 03:06:21 i keep hitting this and it's really annoying 2022-10-02 03:07:04 in my case this time it's junk crate-like c++ libs (fmt and spdlog) which only make sense to static link, not dynamic, imo 2022-10-02 03:12:30 uhg who came up with ninja doing -j$ncpus+1 as default rather than -j1 ?? 2022-10-02 03:12:49 this is c++ junk, you can't do -j>1 because each process uses GBs of ram 2022-10-02 04:04:22 psykose: I get that same assertion we saw with mmsd-tng when running tests for libphonenumber: https://bpa.st/2PUQ 2022-10-02 04:04:35 so I think libphonenumber is busted on x86 or something 2022-10-02 04:36:47 static versions are intentionally removed 98% of the time, and for things like fmt it does not make sense to static link 2022-10-02 04:37:09 neither does compiling c++ take gbs of memory per thread, wtf are you compiling 2022-10-02 04:37:16 there's like ~10 programs for which that is true 2022-10-02 04:37:21 craftyguy: no, it's abseilf 2022-10-02 04:39:03 oh a bug in abseil? 2022-10-02 05:02:28 fixed 2022-10-02 05:08:31 psykose: huh? 2022-10-02 05:08:45 what's huh 2022-10-02 05:08:58 was that msg for me or ?? 2022-10-02 05:09:08 yea it's fixed 2022-10-02 05:09:14 oh nice! 2022-10-02 05:11:04 in that case, I think we can re-enable x86 for mmsd-tng and chatty 2022-10-02 05:11:18 assuming libphonenumber is happy 2022-10-02 05:11:38 if you want 2022-10-02 05:11:55 I'll update the libphonenumber MR, let's start with that :P 2022-10-02 05:15:42 I never would've expected compiling abseil with gcc would've fixed a failure. 2022-10-02 05:16:38 happens :) 2022-10-02 05:16:47 usually it's the other way around, but it comes and goes 2022-10-02 05:17:07 this week gcc is the best option, next week it's clang, rinse/repeat 2022-10-02 05:17:18 it's more of a statistical game 2022-10-02 05:17:30 99.5% of the repo is gcc, so, relatively.. sometimes there's an issue fixed with clang 2022-10-02 05:17:36 the other way rarely happens because it barely exists 2022-10-02 05:18:49 though if you consider "uses half the memory of gcc to compile c++" a win it's always fixing something 2022-10-02 05:18:55 nice, mmsd-tng and chatty built for x86 2022-10-02 05:20:05 psykose: thanks for figuring that out :D 2022-10-02 05:20:18 :) 2022-10-02 05:20:52 now if only people would figure out my issues instead for a change.. 2022-10-02 05:22:41 psykose: Right, but with abseil specifically being a Google library, I would expect clang to work better/produce less failures given Google does basically everything with clang/LLVM internlly. 2022-10-02 05:24:33 certainly, but it's x86 2022-10-02 05:24:36 True. 2022-10-02 08:48:43 hi, had to modify /usr/lib/cgit/filters/syntax-highlighting.sh a bit to make it work 2022-10-02 08:48:47 hope its not a bug ? <- https://tpaste.us/8b8b 2022-10-02 08:52:12 oh, with external css file it might work 2022-10-02 08:58:36 might be 2022-10-02 09:17:47 it might be better if /etc/cgitrc is moved to /etc/cgit/cgitrc, but requires source editing 2022-10-02 09:18:10 reason, "CGIT_CONFIG" then can be used to set as 'env' and use different cgitrcs' 2022-10-02 09:18:22 in lighty or nginx 2022-10-02 09:19:54 presently it cluters in /etc/ 2022-10-02 09:24:19 | /usr/bin/abuild: line 2867: syntax error: bad substitution 2022-10-02 09:24:53 that happens if you edit/save the abuild file during an abuild invocation 2022-10-02 09:24:57 or you found a bug 2022-10-02 09:25:01 but i always hit the former case 2022-10-02 09:25:09 it's in rootbld 2022-10-02 09:25:20 abuild as 2840 lines 2022-10-02 09:25:28 s/as/has 2022-10-02 09:25:34 the number is a lie 2022-10-02 09:25:38 can you reproduce it more than once 2022-10-02 09:25:40 abuild is a lie 2022-10-02 09:25:48 i can reproduce it all the time 2022-10-02 09:29:50 ah, just forgot to remove bashisms 2022-10-02 09:30:58 skill issue 2022-10-02 09:31:03 indeed 2022-10-02 09:36:46 do we keep-around more refs than needed? 2022-10-02 09:37:43 not really trying to grok git/gitlab but rather improve my git pull/fetch rate 2022-10-02 09:38:27 almost all patches/* are gone so it cannot be better than already is 2022-10-02 09:38:38 what refs you would like to see gone 2022-10-02 09:39:25 idk, so I just wondered if they were more numerous than they should 2022-10-02 09:39:33 there's billions 2022-10-02 09:39:36 or something 2022-10-02 09:39:37 so they say 2022-10-02 09:40:04 --prune or something like that 2022-10-02 09:41:45 it's just that it seems like it's fetch refs/keep-around/* that takes forever everytime I pull over ssh 2022-10-02 09:43:39 perhaps I should just fetch over https since that at least works every time 2022-10-02 11:08:14 is the gitlab sshd configured with AcceptEnv GIT_PROTOCOL? 2022-10-02 11:30:25 omni: no, not specifically 2022-10-02 11:30:27 Would that matter? 2022-10-02 11:30:53 https://docs.gitlab.com/ee/administration/git_protocol.html 2022-10-02 11:31:22 Apparently necessary for protocol v2 2022-10-02 11:34:31 omni: debug1: channel 0: setting env GIT_PROTOCOL = "version=2" 2022-10-02 11:34:36 apparently it's already used 2022-10-02 11:37:30 or maybe not 2022-10-02 11:47:06 need to restart gitlab 2022-10-02 11:52:54 omni: ok, enabled it now, seems to help 2022-10-02 11:53:15 before: git fetch upstream 1.39s user 1.56s system 121% cpu 2.424 total 2022-10-02 11:53:28 after: git fetch upstream 0.43s user 0.02s system 53% cpu 0.856 total 2022-10-02 11:53:38 (in both cases, there was nothing new to fetch) 2022-10-02 11:53:54 omni: does it help for you? 2022-10-02 12:06:45 thanks btw for mentioning it, was not aware that was missing / required for protocol v2 2022-10-02 13:47:02 The difference is that the client now can request specific refs to be sent, which indeed will help a lot in this case 2022-10-02 14:13:26 it's used yeah 2022-10-02 14:15:50 ptrc: can you check if it's faster for you as well now? 2022-10-02 14:24:16 oh huh, i missed the part where it was client-opt-in too 2022-10-02 14:24:22 more speed for me 2022-10-02 14:50:01 recent git clients should default to v2 2022-10-02 14:50:21 ie, it works for me without adding the config option 2022-10-02 14:53:51 ah 2022-10-02 14:53:54 makes sense 2022-10-02 16:10:42 can confirm too, it is a bit faster now 2022-10-02 16:10:54 or rather, feels like it, but i'm pretty sure it was slower before 2022-10-02 16:15:19 science 2022-10-02 16:35:36 ikke: thanks a lot, it's very fast now! 2022-10-02 16:37:16 thank omni :) 2022-10-02 16:52:21 Who needs science when you have feelings :) 2022-10-02 16:56:17 ikke: yes! huuge difference! thank you! 2022-10-02 16:56:42 before % GIT_TRACE_PACKET=1 git pull 2>&1 | rg keep-around | wc -l 2022-10-02 16:56:44 419887 2022-10-02 16:56:57 now % GIT_TRACE_PACKET=1 git pull 2>&1 | rg keep-around | wc -l 2022-10-02 16:56:59 0 2022-10-02 16:58:22 and doesn't take ten minutes or more to let you know if it was successful or fatal: the remote end hung up upon initial contact 2022-10-02 16:58:33 hmm, never had that myself 2022-10-02 16:59:10 my connection is not always good, probably plays its part 2022-10-02 17:09:37 the times when the fix is one line in the config somewhere are my favorite :) 2022-10-02 17:10:10 yup 2022-10-02 17:23:14 nice to know about protocol 2 2022-10-02 17:23:19 anyone on howto improve browser load speed for cgit, when enable-commit-graph=1 ? 2022-10-02 17:23:44 difference is around 6+sec 2022-10-02 21:14:32 oh, I just wish jirutka would at least comment on !27474 and !38362 2022-10-02 21:14:52 ACTION pokes algitbot 2022-10-02 21:14:58 algitbot? 2022-10-02 21:15:11 irc bot here 2022-10-02 21:15:34 It should fetch the titles of those issues and post them here + urls 2022-10-02 21:15:35 I know, just tried to poke too 2022-10-02 21:15:56 anyway community/luarocks: upgrade to 3.9.1 and community/nerd-fonts*: upgrade to 2.2.2 2022-10-02 21:16:19 w00t 2022-10-02 21:16:56 !27474 2022-10-02 21:16:59 that's better 2022-10-02 21:17:11 !38362 2022-10-02 21:18:19 hey if you want to update even more fonts you could do font-noto 2022-10-02 21:18:23 no idea what is even happening there 2022-10-02 21:19:18 except for being years out of date and missing entire sets 2022-10-02 21:25:43 that sounds like more than just bumping commit hash etc 2022-10-02 21:25:52 sorry, but I think I'll pass this time 2022-10-02 21:26:27 I'm interested in nerd-fonts since I use font-go-mono-nerd 2022-10-02 21:29:25 that and low-hanging fruit, usually 2022-10-02 22:36:28 hey, random idea that would imo really help alpine library package quality... 2022-10-02 22:36:57 would it be possible to make a wrapper for CC/CXX for badly packaged library packages that... 2022-10-02 22:37:30 when run with -shared to make a .so, automatically collects the same set of .o files and invokes ar to make a static .a version of the same library 2022-10-02 22:37:46 so that static libs are always available when the &%#()&%#() upstreams don't provide them 2022-10-03 08:38:43 inb4 libraries that dlopen themselves or something 2022-10-03 09:21:05 as i said they are intentionally removed even if they are there most of the time 2022-10-03 09:21:44 it is intentional there are almost no static libs, not the opposite due to upstreams not providing them or something 2022-10-03 09:22:04 it's a waste of mirror space for zero repo benefit except the off chance someone might want to use them for something 2022-10-03 09:22:57 so.. sometimes some are added, usually not 2022-10-03 09:23:23 if you have the ability to build things yourself you can make whatever kind of library you want, i'm not sure why there has to be a cc wrapper somewhere 2022-10-03 09:25:48 is it "low quality" to intentionally not ship static libs? maybe to you, but it is what it is 2022-10-03 09:26:41 same goes for global -dbg symbols, they're missing from the majority of places 2022-10-03 09:27:24 now if we could rearchitect all the builders and the way things are stored and not duplicate files all over the place and have 10x the storage.. maybe it would make sense to add both, but 2022-10-03 11:41:40 yes, we do dynamic link by default. and only add -static libs on request case by case 2022-10-03 11:42:29 im trying to follow up the qemu-riscv64 and rust thing. was it so that also golang deadlocks qith qemu-riscv64? 2022-10-03 11:43:23 i built rust with qemu-user for riscv64 in chimera just fine btw 2022-10-03 11:43:46 golang too 2022-10-03 11:44:06 and actually the whole repo 2022-10-03 11:44:29 who long time did it take? how many cores? 2022-10-03 11:44:31 only had issues with test suites occasionally falling on stuff where host arch leaks through 2022-10-03 11:44:47 -j32, about under two hours iirc 2022-10-03 11:45:54 on ryzen 5950x (so 16 cores/32 threads) 2022-10-03 11:46:22 maybe it's a host kernel or host hardware issue 2022-10-03 11:46:25 dod you build it in some container? 2022-10-03 11:46:29 we did migrate the latter, but 2022-10-03 11:46:31 or that 2022-10-03 11:46:43 ncopa: well, cbuild has containerization builtin 2022-10-03 11:46:45 through namespcaes 2022-10-03 11:46:55 what kind of container setup is it you your riscv 2022-10-03 11:47:00 for your* 2022-10-03 11:47:05 no special container setup 2022-10-03 11:47:14 i just have cbuild set up a riscv environment 2022-10-03 11:47:21 and then qemu-user takes care of running stuff transparently 2022-10-03 11:47:25 on ubuntu 20.04 host 2022-10-03 11:47:46 so there is no container setup at all, it's just a "native chroot" and running riscv binaries via user, right? 2022-10-03 11:47:55 or not even a chroot 2022-10-03 11:48:03 the "chroot" is a user namespace 2022-10-03 11:48:09 at low level implemented through bubblewrap 2022-10-03 11:48:19 ok, so it's bwrap 2022-10-03 11:49:13 only had issues with test suites occasionally falling on stuff where host arch leaks through 2022-10-03 11:49:17 oh and also unimplemented syscalls 2022-10-03 11:49:23 notably io_setup at least 2022-10-03 11:49:32 makes one openssl test fail 2022-10-03 11:49:39 right, though in our case we disable every test for riscv 2022-10-03 11:49:44 i guess it was the lazier choice at the start 2022-10-03 11:49:56 i run them because i want to see where stuff fails 2022-10-03 11:50:08 i would have too, i wasn't there to make the decision :) 2022-10-03 11:50:09 i then verify the failures case by case to determine if it's caused by emulation or if it's a real fail 2022-10-03 11:50:20 as far as i can tell it's pretty much all been emulation 2022-10-03 11:50:25 yep 2022-10-03 11:50:30 but yeah, that's some good info 2022-10-03 11:50:38 after my experience in void i'm pretty anal about having tests be run and pass 2022-10-03 11:50:48 it could be an lxc container issue (i don't think anyone has tried another method), or something in host kernel 2022-10-03 11:50:55 (for us) 2022-10-03 11:50:55 because it exposes a lot of bugs 2022-10-03 11:51:12 clang 15 now also exposes a lot of bugs 2022-10-03 11:51:27 it started outright rejecting passing pointers as integers implicitly 2022-10-03 11:51:27 yep 2022-10-03 11:51:36 and also -Wstrict-prototypes now includes empty argument lists in C 2022-10-03 11:52:05 i guess the riscv repo build also served to expose all the cases where people use this wrong 2022-10-03 11:52:44 anyway i'm almost to 100% coverage on riscv 2022-10-03 11:52:51 missing a single last package and that's firefox 2022-10-03 11:53:15 iirc some crates in the chain don't support it 2022-10-03 11:53:23 but it looked like for of an #ifdef arch thing 2022-10-03 11:53:32 we'll see 2022-10-03 11:53:35 worst case i'll mark it broken 2022-10-03 11:53:49 i saw that stuff like xptcall was implemented 2022-10-03 11:53:55 so in theory there is support 2022-10-03 11:54:26 maybe. i'd guess for such a huge project it's more piecemeal 2022-10-03 11:54:27 if somebody implemented it they must have tested it at some point 2022-10-03 11:54:35 so even with that impl it's just a piece 2022-10-03 11:54:41 could be 2022-10-03 11:54:57 i'm at the airport so i'll check the build after landing for layover 2022-10-03 11:55:07 i had to fix nodejs first which i did just now 2022-10-03 11:55:20 https://github.com/chimera-linux/cports/commit/4c1b1832867d477acd764b02bc2c3343c2cca352 more libatomic gcc cruft 2022-10-03 11:55:23 what version/build of qemu-riscv64 do you use? 2022-10-03 11:55:43 7.0 2022-10-03 11:55:45 self built 2022-10-03 11:55:53 as ubuntu's is ancient 2022-10-03 11:56:19 static build? where do you ahve the build script? 2022-10-03 11:56:22 i also highly recommend tweaking the binfmts to pass the preserve flag (if using new enough qemu, which is 6.0) 2022-10-03 11:56:44 because that will unfuck your argv[0] in emulated stuff (which is responsible for one class of test failures) 2022-10-03 11:57:09 ncopa: static yeah 2022-10-03 11:57:17 i just built is manually 2022-10-03 11:57:23 ok 2022-10-03 11:57:36 ./configure --prefix=/usr --static --disable-system --enable-linux-user 2022-10-03 11:57:37 make -j32 2022-10-03 11:57:39 make install 2022-10-03 11:58:01 actually i have an idea 2022-10-03 11:58:53 https://ftp.octaforge.org/q66/random/qemu-riscv64-static 2022-10-03 11:58:54 here 2022-10-03 11:58:58 since it's static you should be able to run it 2022-10-03 11:59:12 as long as your build host is x86_64 2022-10-03 11:59:19 it runs yeah 2022-10-03 11:59:19 ok. i will try in a bit. have a meeting now. thanks! 2022-10-03 11:59:26 at least there is hope to fix this 2022-10-03 11:59:44 yeah dunno 2022-10-03 11:59:52 since we don't know what the root of the problem is, it's hard to say 2022-10-03 11:59:55 but this could be one piece of it 2022-10-03 12:03:36 i did try debian-s qemu-riscv64-static though (7.1.0) , and it didnt make any noticeable difference 2022-10-03 12:26:07 there are too many variables, it could be something that shows only sometimes, it could be a kernel thing, it could be a qemu thing, it could be a rust bug that is highly dependent on the configuration (since mine is different), etc 2022-10-03 12:26:18 lemme know if you figure it out 2022-10-03 13:20:25 fyi, we did run in docker and lxc 2022-10-03 13:20:42 we did run on two different baremetal boxes 2022-10-03 13:20:59 and yes we use P for binfmt 2022-10-03 13:21:27 argv otherwise is an issue 2022-10-03 13:34:15 i guess we could try another kernel 2022-10-03 13:34:37 maybe with something as radical as running the same lxc container exported on ubuntu 2022-10-03 14:01:26 q66: can I see your rust build script? and what patches you use 2022-10-03 14:07:55 https://github.com/chimera-linux/cports/tree/master/main/rust 2022-10-03 14:08:57 of note cargo is split to https://github.com/chimera-linux/cports/tree/master/main/cargo because for some reason all-at-once doesn't work for them 2022-10-03 14:09:11 and half the patches are just for some cross-compile stuff that isn't needed for us either 2022-10-03 14:09:28 in the sense of i've used them before, but cross build without them fine so i never committed it 2022-10-03 14:12:44 aside from being built with llvm toolchain and splitting cargo it's the same thing with the same patches, minus the dynamic one (0008) 2022-10-03 14:12:52 maybe there's a legendary line i missed 2022-10-03 14:18:29 I would like to package https://github.com/sardemff7/purple-libnotify-plus/ which is a really small (~400lines) plugin for pidgin. Could it be directly added do pidgin package? If no, could it be directly to community? 2022-10-03 14:22:26 it's a separate project so it's a separate package 2022-10-03 14:22:30 and no, it goes to testing first 2022-10-03 14:22:38 ok 2022-10-03 14:23:09 look at anything else using meson for how to build it and that's about it 2022-10-03 14:24:13 yeah I just want to avoid to have another package for this simple "freature" 2022-10-03 14:25:51 there's no bottom size limit on packages :) 2022-10-03 14:26:42 :D 2022-10-03 14:31:00 meson.build:19:0: ERROR: Dependency "purple-events" not found, tried pkgconfig 2022-10-03 14:32:34 https://github.com/sardemff7/purple-events 2022-10-03 14:32:50 ouch 2022-10-03 14:33:01 these are very easy to package though :) 2022-10-03 14:34:05 I think that would be better to exec notify-send on new messages 2022-10-03 14:35:12 I wonder if pidgin3 has better integrated support for this 2022-10-03 14:48:26 ncopa: could you consider this for merge before 3.17? https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/2 2022-10-03 17:16:09 What's the proper way to create a symbolic link inside of an APKBUILD? 2022-10-03 17:18:07 from where to where 2022-10-03 17:18:12 I've tried ln -s "$pkgdir"/path/target "$pkgdir"/path/link and ln -s /path/target "$pkgdir"/path/link but in both cases I get an error where ln says "no such file or directory" 2022-10-03 17:18:29 latter is correct 2022-10-03 17:18:31 psykose: from /usr/bin/squeekboard to /usr/bin/osk-wayland 2022-10-03 17:18:45 wonder what I'm doing wrong then 2022-10-03 17:18:46 ln -sfv /usr/bin/squeekboard "$pkgdir"/usr/bin/osk-wayland 2022-10-03 17:18:50 usr/bin has to exist 2022-10-03 17:18:57 Newbyte: the target is what it should point to after being installed 2022-10-03 17:19:16 so not prefixed with $pkgdir 2022-10-03 17:19:33 Maybe I need to create /usr/bin then 2022-10-03 17:19:35 this sounds like an attempted implementation of default-programs 2022-10-03 17:20:19 it's much easier to do this of osk-wayland is a shell script that tries to find the others instead of links 2022-10-03 17:20:21 psykose: it's just what this executes: https://git.alpinelinux.org/aports/tree/community/phosh/sm.puri.OSK0.desktop 2022-10-03 17:21:22 psykose: it's actually a shell script currently, but I thought I would replace it with a symlink since it just tries to use an old keyboard that hasn't existed for years in case squeekboard doesn't exist 2022-10-03 17:21:24 so it's just broken 2022-10-03 17:21:49 but I could just simplify the shell script if that's preferred. it's always going to execute squeekboard however 2022-10-03 17:22:04 hm, maybe the service should be changed instea 2022-10-03 17:22:05 s/instea/instead/ 2022-10-03 17:22:06 that sounds like there's no point for the wrapper at all if you won't add other implementations 2022-10-03 17:22:16 if you would, then you could change the script to something else 2022-10-03 17:22:58 psykose: so, better to change sm.puri.OSK0.desktop then? 2022-10-03 17:23:16 currently there are two keyboards available for Phosh 2022-10-03 17:23:18 one is Squeekboard 2022-10-03 17:23:22 if you want no configuration and to have only one keyboard, sure 2022-10-03 17:23:24 the other is a debug keyboard that isn't even packaged in Alpine 2022-10-03 17:23:50 also the Phosh package hard depends on Squeekboard 2022-10-03 17:23:58 so it's always going to pick that with the current script anyway 2022-10-03 17:24:07 you already know what to do then :) 2022-10-03 17:24:14 maybe if more keyboards crop up in the future we can change this 2022-10-03 17:24:37 psykose: yes, fruitful discussion :) 2022-10-03 17:28:00 psykose: yeah you were right wrt firefox, the nix crate does not compile 2022-10-03 17:28:10 that one has support if you bump it iirc 2022-10-03 17:28:50 can't really bump it, firefox vendors crates 2022-10-03 17:28:55 but i could probably patch it in 2022-10-03 17:29:02 the c++ bits compiled without problems fwiw 2022-10-03 17:29:05 at least seemingly 2022-10-03 17:29:49 won't be patching that here anyway, the barcelona airport wifi sucks so hard it lags even ssh 2022-10-03 17:30:07 at least it does not reject non-http ports like the vienna airport wifi 2022-10-03 17:30:18 sure you can :) rm -rf; curl crates.io | tar; clear-checksums 2022-10-03 17:30:35 (that most likely doesn't work and i'm trolling, so i agree) 2022-10-03 17:30:47 patch is better 2022-10-03 17:30:54 though who knows if something else won't fail afterwards 2022-10-03 17:31:33 q66: maybe check Mozilla's Bugzilla for an already existing patch 2022-10-03 17:31:37 works 99% of the time for me 2022-10-03 17:32:48 mozilla's bugzilla is a mess and the patches posted there tend to be a bigger mess 2022-10-03 17:33:52 in any case, flight transfer in a few minutes anyway 2022-10-03 17:33:57 still better than google gerrit for any project, haha 2022-10-03 17:34:21 i stopped at a cafe for ice cream and waffle and coffee 2022-10-03 17:34:31 nom 2022-10-03 17:34:47 send me some in the mail 2022-10-03 17:34:57 already ate it 2022-10-03 17:35:18 it was speculoos caramel ice cream 2022-10-03 17:35:19 grr 2022-10-03 17:36:50 Hmm, dutch or belgian 2022-10-03 18:07:53 is there a style of dutch waffle other than the stroopwaffel thing 2022-10-03 19:10:27 .uptime 2022-10-03 19:10:29 [uptime] I've been sitting here for 0:00:22 and I keep going! 2022-10-03 19:40:23 .uptime waffle 2022-10-03 19:40:23 [uptime] I've been sitting here for 0:30:17 and I keep going! 2022-10-04 07:11:45 q66: have you been able to debug things when running in qemu-user? 2022-10-04 08:43:16 minimal: I will try get it included in 3.17 release 2022-10-04 08:43:55 q66: rust build deadlocks with your qemu-riscv64 too 2022-10-04 08:44:28 q66: do you think you could try our qemu-riscv64 build? it is also static 2022-10-04 08:44:55 it is a bit confusing because so far it looks like the problem has been in qemu, but I'm not so sure anymore 2022-10-04 08:50:02 ncopa: sorry, currently got my hands full fixing up firefox to build on rv64 :/ 2022-10-04 08:50:33 i can try later if i find some time though 2022-10-04 08:58:57 ncopa: i'd say it's still fairly likely the problem is in qemu 2022-10-04 08:59:06 it's just an emulator, so it's not perfect 2022-10-04 08:59:23 it could also be a bug in rust 2022-10-04 08:59:45 that is rare to reproduce and emulation + specific environment makes it more reproducible 2022-10-04 09:01:52 fwiw i've had qemu-user randomly "hang" at a random process with 0% CPU usage outside rust 2022-10-04 09:02:02 killing the build and restarting it fixed it 2022-10-04 09:02:14 it happened about 4 or so times during my whole repo build 2022-10-04 09:02:36 so a rather rare condition 2022-10-04 09:27:24 => Creating firefox-esr-102.2.0-r0.apk in repository /home/q66/cports/packages/contrib/.stage/riscv64... 2022-10-04 09:27:24 ha 2022-10-04 09:29:02 q66: do you have a lot of golang pkgs in your tree? 2022-10-04 09:29:09 no 2022-10-04 09:29:17 currently none 2022-10-04 09:29:31 that kind of explains why you dont see it deadlock that much 2022-10-04 09:29:42 i have the compiler because somebody else tried to add it and i didn't like the way it was done so i added it myself 2022-10-04 09:30:19 but i also saw gcc deadlock on its go part 2022-10-04 09:30:41 anything that touches golang can hang/deadlock 2022-10-04 09:31:51 gccgo is kinda broken and useless in general 2022-10-04 09:32:43 but i have no gcc so also no gccgo 2022-10-04 09:34:09 I wonder if this is related: https://gitlab.com/qemu-project/qemu/-/issues/358 2022-10-04 09:47:17 yeah, i can reproduce that and I believe that is our issue 2022-10-04 10:18:14 btw, riscv fixes for firefox if you want them https://github.com/chimera-linux/cports/commit/d05b95179d7eb1fa32931e332dd3ca79b0216b0c 2022-10-04 10:18:32 the bindgen thing is actually general llvm 15 fallout so you might not need that (forgot to mention that there) 2022-10-04 10:24:06 ncopa: could we try qemu-system perhaps? 2022-10-04 10:24:47 have fun with that 2022-10-04 10:24:49 sloooooow 2022-10-04 10:25:04 https://gist.github.com/q66/ec52e90c53e54eb293ebd6de8d58c435 2022-10-04 10:25:09 im trying to debug it with help from #qemu 2022-10-04 10:29:58 q66: yeah, that's really slow 2022-10-04 10:30:21 still faster than best native hardware 2022-10-04 10:30:28 but still too slow 2022-10-04 10:30:31 Would also be interesting to see it on aarch64 2022-10-04 10:30:45 idk aarch64 does not concern me too much 2022-10-04 10:30:59 i did this rudimentary benchmark because i wanted to compile my stuff on riscv so i was evaluating the best way to do it 2022-10-04 10:31:16 for aarch64 i have osuosl provide me with a nice vm 2022-10-04 10:31:32 I mean aarch64 as host 2022-10-04 10:31:48 I heard mps mentioning that it might be faster there 2022-10-04 10:31:55 ah, my best aarch64 hardware is honeycomb lx2 2022-10-04 10:31:59 right 2022-10-04 10:32:11 so i wouldn't expect too much performance from that 2022-10-04 10:32:21 We have a nice aarch64 server 2022-10-04 10:32:24 i built stuff on ryzen 5950x host because that's the fastest hw i have 2022-10-04 10:32:29 though the talos 2 is close 2022-10-04 10:32:49 but the ryzen has much better singlecore performance so that matters a lot here 2022-10-04 11:00:47 we are making progress on qemu deadlock 2022-10-04 11:00:52 may have workaround 2022-10-04 11:01:27 nice, post the patch once you have it 2022-10-04 11:01:40 i suspect what i was hitting in non-rust stuff is the same deadlock 2022-10-04 11:01:56 basically, --disable-plugins 2022-10-04 11:02:13 and export G_SLICE=always-malloc 2022-10-04 11:02:19 since we use glib 2022-10-04 11:02:33 seems like we have a winner actually 2022-10-04 11:03:04 alternatively build it without glib 2022-10-04 11:03:44 you can build it without glib? 2022-10-04 11:09:57 And that's for rust? 2022-10-04 11:12:58 i believe it will fix rust issue 2022-10-04 11:13:11 we are hitting https://gitlab.com/qemu-project/qemu/-/issues/285 2022-10-04 11:14:48 heh i was reading that specific issue 2022-10-04 11:14:53 seems very related 2022-10-04 11:20:59 nice work ncopa :) 2022-10-04 11:21:24 only needs some ducktape to get it working 2022-10-04 11:21:49 exporting G_SLICE in the outer environment is bad because it'll translate into whatever thing is running inside 2022-10-04 11:21:58 and i think it isn't really a reliable fix 2022-10-04 11:22:06 but good progress on finding the cause anyway 2022-10-04 11:24:32 q66: anything is better than needing to kick the builder x times a day 2022-10-04 11:24:49 but i agree, it needs to be some switch or related 2022-10-04 11:27:28 ncopa: what do you loose when disabling plugins? 2022-10-04 11:28:08 I guess we would need to have a custom qemu build for rv64 builder? 2022-10-04 11:29:20 i dont htink we have plugins, due to --static, so I don't think it makes any difference 2022-10-04 11:36:01 heh, things go quicker than expected :) 2022-10-04 11:38:28 ncopa: i guess https://gitlab.com/stsquad/qemu/-/commit/b2e79244f2d976fc41651aef04ead9e79960750a will fix the disable plugins 2022-10-04 11:52:18 i believe all we need to do is export G_SLICE=always-malloc in /etc/abuild.conf 2022-10-04 11:52:30 will check after lunch if i can build rust 2022-10-04 12:12:55 clandmeter: we can also create a wrapper script that exports G_SLICE and then exec qemu-riscv64.orig 2022-10-04 12:14:28 ok 2022-10-04 12:27:24 ncopa: did you apply the patch for the plugins to aports? 2022-10-04 12:27:41 no. i dont think its needed 2022-10-04 12:27:48 oh ok 2022-10-04 12:28:04 just the malloc 2022-10-04 12:28:07 yes 2022-10-04 12:28:18 nice 2022-10-04 12:28:23 its a good rv64 day 2022-10-04 12:28:38 ncopa: Thanks. There are also a couple of other unrelated MRs/Issues I've raised in alpine-conf & mkinitfs relating to Alpine installation problems that would be good to be resolved in 3.17 (especially the boot partition sizing one) 2022-10-04 12:28:41 i think danpb bumped into a different issue when trying to reproduce it 2022-10-04 12:28:52 minimal: yeah i will try solve those before 3.17 2022-10-04 12:29:07 but now riscv64 and rust has priority 2022-10-04 12:29:12 if this works, we can enable tests again 2022-10-04 12:29:33 i think this was the major blocker for it 2022-10-04 12:29:47 also setting the P flag helps 2022-10-04 12:30:16 almost like a real baremetal machine with this fix :) 2022-10-04 13:52:03 somthing has changed, who was it that changed the thing? 2022-10-04 13:54:54 it seems like it's not possible to build zfs-lts atm and I'm trying to figure out why 2022-10-04 13:57:42 zfs-rpi neither, except for aarch64 which is weird... 2022-10-04 14:00:18 something in the main repo since friday, since zfs-rpi was built successfully tthen 2022-10-04 14:00:22 bash 5.2? 2022-10-04 14:02:20 just guessing but it could be gcc update making the plugins in the kernel headers package incompatible, i can't build an out-of-tree module on edge now either. The kernel was built by: gcc (Alpine 12.1.1_git20220630-r6) 12.1.1 20220630 You are using: gcc (Alpine 12.2.1_git20220924-r2) 12.2.1 20220924 2022-10-04 14:07:40 i was planning to have a look at zfs upgrade with 5.15.72 2022-10-04 14:21:38 yes, please see if you can figure out what is going on !39768 2022-10-04 14:31:19 is boost still a dep for community/mtxclient ? 2022-10-04 14:33:19 pkgdesc should be 'Client API library for Matrix, built on top of libcurl' 2022-10-04 14:56:53 ncopa: what is the status now regarding rv64? 2022-10-04 14:57:10 will you apply some fix, or so we need to ducktape the builder? 2022-10-04 15:06:25 clandmeter: im still running a rust build in my dev env 2022-10-04 15:07:06 i think we can as first step simply add export G_SLICE=always-malloc to /etc/abuild.conf 2022-10-04 15:07:34 i'm working on a fix for glib/qemu build that will solve it without that env var 2022-10-04 15:15:50 ok let me add it and kick the builder 2022-10-04 15:17:03 poor builder 2022-10-04 15:22:18 ok added in buildozers abuild.conf 2022-10-04 15:25:35 ncopa: your build is single threaded? 2022-10-04 15:26:33 ikke: please help me remember we should enable tests again if this fix really works 2022-10-04 15:29:36 clandmeter: we should enable tests gain 2022-10-04 15:29:46 :P 2022-10-04 15:31:24 found your funny pants? :p 2022-10-04 15:33:00 Something like that :-) 2022-10-04 15:33:07 I think I'll just backport https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2799 2022-10-04 15:33:17 and rebuild qemu 2022-10-04 16:05:24 actually, I'll d a simpler fix that always use libc's malloc 2022-10-04 17:02:47 it's not a backport if it's not even merged :-) 2022-10-04 18:09:57 but yeah lgtm, feel free to patch it in 2022-10-04 18:10:10 doesn't sound like a downside to use system alloc here 2022-10-04 19:29:59 i went for a simpler patch. i think we can just remove the glice allocator completely. its just dead code now 2022-10-04 19:31:00 Let's see 2022-10-04 19:31:14 Do you think this could fix golang deadlocks as well? 2022-10-04 19:32:00 maybe, will have to see 2022-10-04 19:32:09 ncopa: aha, yep, that's as clean as it gets, nice :) 2022-10-04 19:33:07 to be completely clear this might be slower than the slice alloc- reading the threads they're only comparing to glibc, musl most likely would have completely different results for the general case 2022-10-04 19:33:10 but it should not cause any major issues 2022-10-04 19:46:24 axe programming is best programming 2022-10-04 19:47:40 it is 2022-10-04 20:16:49 ikke: looks like it’s still running 2022-10-04 20:18:33 you mean gcc? 2022-10-04 20:18:34 was the host upgraded with the changes 2022-10-04 20:22:30 In general 2022-10-04 20:23:25 yes, it's stuck like always on the same part for a bit or by chance 2022-10-04 20:23:42 i think it has done a few packages alraedy including golang ones 2022-10-04 20:23:46 seems to keep going 2022-10-04 20:24:03 the host didnt need an upgrade 2022-10-04 20:24:07 clandmeter: x86_64 is still building qemu 2022-10-04 20:24:13 riscv? there are no golang packages in main/ 2022-10-04 20:24:37 just export 2022-10-04 20:24:51 psykose: gcc has gcc-go :) 2022-10-04 20:25:01 or gccgo 2022-10-04 20:25:05 i feel like i'm listening to another language i don't understand 2022-10-04 20:25:21 communication is hard 2022-10-04 20:25:34 unfortunately 2022-10-04 20:25:48 but yeah it seems stuck on the same gccgo step as before 2022-10-04 20:25:57 even with the glib malloc export 2022-10-04 20:26:00 or it just needs another hour 2022-10-04 20:26:05 no its running 2022-10-04 20:26:22 20:26:12 up 6 days, 10:19, 0 users, load average: 13.17, 10.78, 8.64 2022-10-04 20:27:24 its building gcc go 2022-10-04 20:29:46 but it can still fail, previous log was around 14.2 mb 2022-10-04 20:29:49 its at 12.x now 2022-10-04 20:30:09 hopefully it passes 2022-10-04 21:12:06 clandmeter: passed gcc 2022-10-04 21:13:16 nice 2022-10-05 08:57:37 rv64 still going strong :) 2022-10-05 08:57:49 just has a lot to catch up on 2022-10-05 08:59:14 yup 2022-10-05 09:15:28 how do you display packages depending on a certain .so again? 2022-10-05 09:15:34 (thus packages needing a rebuild when it's dependency gets an update) 2022-10-05 09:17:21 apk list -d so:xyz.so.5 2022-10-05 09:18:18 ah thanks 2022-10-05 09:18:39 doesn't `apk info -r so:xyz.so.5` also do the job? 2022-10-05 09:19:03 I just realized I should've been searching for `so:xyz.so.5` and not `so:xyz.so.5.5.1` or whatever 2022-10-05 09:20:14 the info -r output is missing like 90% of them 2022-10-05 09:20:34 really? Strange 2022-10-05 10:06:30 because it only looks at installed packages? 2022-10-05 10:16:03 struggling with glib build from git. I get errors: 2022-10-05 10:16:15 ../glib/gfileutils.c:2540:22: error: 'G_DIR_SEPARATOR_S' undeclared (first use in this function); did you mean 'G_IS_DIR_SEPARATOR'? 2022-10-05 10:17:20 oh... 2022-10-05 10:17:31 its leftovers. never mind 2022-10-05 11:19:06 ok I have a patch that actually removes glib's slice allocator, and makes the API a wrapper around g_malloc 2022-10-05 11:19:19 saves a few kb in size 2022-10-05 11:48:06 you should have waited for upstream on that one 2022-10-05 11:48:12 especially because it even fails their tests :p 2022-10-05 11:49:18 though it's just a debug thing in any case 2022-10-05 17:47:28 The soldiers and participants of the ruling oppressors regimes all over the world now are required: 2022-10-05 17:47:28 To leave the government and leave army and leave their positions and to create strife, confusion and revolutions against the ruling regime in your country now using all means possible, otherwise they will be tormented with a greater punishment from God the redeemer and through the Messenger of God, Moses the Greatest . 2022-10-05 17:47:28 Moses of Elohim 2022-10-05 17:47:42 In your name, O God There is no God except you, the Greatest, the one, no partner exists to you 2022-10-05 17:47:42 O people, Avoid blasphemy and polytheism in God, which is infact taking equals with God, and nullifying all deeds and all that what has been given to man, so that you may escape from Gods eternal punishment 2022-10-05 18:06:56 skill issue 2022-10-05 19:50:11 i think the rv64 builder is MIA again 2022-10-05 19:54:21 [4/185] Automatic MOC for target Charts 2022-10-05 19:54:38 I see a number of sleeping moc processes 2022-10-05 19:54:45 yup 2022-10-05 19:54:50 nothing is going on 2022-10-05 19:54:56 at least no cpu 2022-10-05 19:55:06 s/sleeping/zombie 2022-10-05 19:55:06 ikke meant to say: I see a number of zombie moc processes 2022-10-05 19:55:33 im going to kill it 2022-10-05 19:55:42 is it buildng qtcharts/ 2022-10-05 19:55:57 yup 2022-10-05 20:01:05 skarnet: is it on purpose http://skarnet.com has different content from https://skarnet.com/ 2022-10-05 20:05:07 clandmeter: is it normal I still see processes prefixed with /usr/bin/qemu-riscv64 on the builder? 2022-10-05 20:05:22 yup 2022-10-05 20:05:29 ok 2022-10-05 20:12:11 Hi guys! Can someone take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/39389 2022-10-05 20:16:01 consus[m]: I think that's something ncopa himself needs to review, who is mostly online during CE(S)T working hours 2022-10-05 20:58:12 ikke: it's not on *purpose* per se, but it's expected 2022-10-05 20:58:31 It did confuse me for a bit :) 2022-10-05 20:58:49 bb httpd can't do virtual hosting so I'm doing ghetto virtual hosting via SNI on https 2022-10-05 20:58:53 can't do it on http 2022-10-05 20:59:08 ok 2022-10-05 20:59:32 basically the plaintext http there should never be used ^^' 2022-10-05 20:59:45 I did not use http on purpose 2022-10-05 20:59:57 I plan to change that in the near future with a very subtle and delicate hammer 2022-10-05 21:00:28 what if it slips and alyss ends up in a retirement home 2022-10-05 21:01:17 retirement home awaits all of us eventually. 2022-10-05 21:01:28 definitely untrue 2022-10-05 21:01:50 the ones for which it is untrue are the unlucky ones. 2022-10-06 11:33:41 is there an issue with libcrypto1.1 vs ca-certificates-bundle on 3.15-stable? 2022-10-06 11:34:06 !39853 2022-10-06 11:45:22 omni: It's a consequence of downgrading from edge 2022-10-06 13:47:44 ikke: only affecting 3.15 CI builders? 2022-10-06 13:48:43 We don't have dedicated ci builders per release 2022-10-06 13:49:18 CI is run in a docker container with an image that based on the target branch downgrades the system to a specific alpine release 2022-10-06 13:49:59 and until the ssl 3.0 upgrade had worked fine 2022-10-06 15:34:26 Code of conduct has been updated: https://alpinelinux.org/community/code-of-conduct.html 2022-10-06 15:36:02 thanks ncopa 2022-10-06 15:36:56 sorry for taking so long 2022-10-06 15:37:12 and thanks for all the help to get there 2022-10-06 16:20:37 I'm excited about idea of non-human contributions! 2022-10-07 06:39:33 morning, what would be a good way to detect if i booted the standard or extended iso. My current hacky way is checking size of /media/cdrom/apks but was wondering if there was a more robust way 2022-10-07 07:30:43 Maybe check if a certain package is avaialbe? 2022-10-07 07:50:24 thanks for updating the code of conduct! 2022-10-07 07:51:17 psykose: btw do you have a script for go rebuilds or do you just do ap revdep go and that apkgrel -a for all repos? 2022-10-07 07:51:22 s/and that/and then/ 2022-10-07 07:51:22 nmeum meant to say: psykose: btw do you have a script for go rebuilds or do you just do ap revdep go and then apkgrel -a for all repos? 2022-10-07 07:51:40 ap revdep go | xargs apkgrel -a 2022-10-07 07:52:00 apkgrel -a grafana-frontend 2022-10-07 07:52:01 that's it 2022-10-07 08:03:47 ikke i guess that would be another way but would that be stable enough for alpine-conf. context: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/105 2022-10-07 09:27:24 Hi all. Appreciate this isn't really the correct place to ask this, if anyone has a more appropriate place let me know. In a makefile, is there any way to specify a target that gets run automatically before every other target (without having to explicitly specify it as a dependency of each target) 2022-10-07 10:58:24 I've just installed Alpine 3.16 on zfs BOOT and ROOT partitions. It was AFAIK not supported by the setup-disk script. I'm just wondering if it would be a good thing to have support for zfs in setup-disk and if so if someone already is working on it? If it's a wanted functionality I might as well update setup-disk instead of writing my own article on how to do it manually. What 2022-10-07 10:58:25 does to community sat about this? :) 2022-10-07 10:58:34 say* 2022-10-07 12:17:39 Just read https://elou.world/en/kubernetes/crio-alpine-error-127 , is really needed to have chroot permission for installing a package? 2022-10-07 12:20:25 donoban: it’s needed for —root 2022-10-07 12:21:08 yeah it that case yes, but I doesn't seem enabled on the url 2022-10-07 12:21:17 maybe it's some bug from v3.12 2022-10-07 12:23:20 EvTheFuture: support for zfs ROOT in setup-disk sounds good to me. Maybe via env var ROOTFS. Not sure it makes sense to support separate ROOTFS in that case though 2022-10-07 12:24:45 donoban: exactly. Seems easy to fix if it not already is. 2022-10-07 12:26:37 I'm trying to reproduce but I don't know how to disable chroot on docker 2022-10-07 12:27:59 do alpine folks have a preference for how the lfs64 macro removal is done? 2022-10-07 12:28:31 chroot: can't change root directory to '.': Operation not permitted 2022-10-07 12:28:42 apk add curl worked perfeclty 2022-10-07 12:28:47 let's try 3.12.. 2022-10-07 12:29:09 it also works :\ 2022-10-07 12:32:53 dalias: have not followed that discussion. Where can I read up on it? 2022-10-07 12:34:08 dalias: in general, I trust what musl does. It is usually good :) 2022-10-07 12:37:47 https://www.openwall.com/lists/musl/2019/10/29/1 2022-10-07 13:16:17 ncopa, [musl] Revisiting LFS64 removal 2022-10-07 13:16:52 basically there are two proposals for removing the macros. removing everything immediately, or making them only visible under explicit _LARGEFILE64_SOURCE not under _GNU_SOURCE (so they don't appear by default in C++) 2022-10-07 13:17:24 the second option would give distros a window to find any packages that break and fix them with -D_LARGEFILE64_SOURCE temporarily while working with upstream to get the right fix in 2022-10-07 13:17:53 the first option would require some immediate manual work on any package that breaks to get it building again 2022-10-07 14:23:39 dalias, you around? Did you wrote a mail server, aren't you? 2022-10-07 14:24:39 yeah kinda :) 2022-10-07 14:24:53 https://github.com/richfelker/mxclient 2022-10-07 14:24:57 is this? 2022-10-07 14:25:07 well as it says in the name it's a client not a server :) 2022-10-07 14:25:12 yeah.. 2022-10-07 14:25:55 In order to get zfs on ROOT working there are a lot of packages that needs to be installed. I'm not familiar with the best practice of the setup-disk script, but is it allowed to install the necessary packages or should it just inform the user about the missing packages? 2022-10-07 14:26:06 the idea here is that the client and server really have nothing to do with each other and should not be part of the same software package (like they are with sendmail, exim, postfix, etc.) 2022-10-07 14:26:44 the only time client and server get used together is when you're routing mail, which is a horrible horrible legacy practice nobody should be doing this century 2022-10-07 14:29:05 if you're receiving mail, you should be storing it into some secure system, not bouncing it over smtp to some sketchy next hop where it gets burned into backups of some queue or whatever 2022-10-07 14:29:29 :) 2022-10-07 14:30:36 but fwiw you *can* hook up mxclient to a receiving smtp server as the command it uses to deliver mail O_o 2022-10-07 14:30:41 dalias: that secure system sounds way too much like a single point of failure :p 2022-10-07 14:31:09 you want single points of failure :) 2022-10-07 14:31:17 not distributed single points of failure :) 2022-10-07 14:31:53 failure is not an option! It's mandatory! ;-) 2022-10-07 14:32:04 but also there is entirely nothing wrong with senders queuing and retrying delivery of your mail for a few minutes or even hours if something is down 2022-10-07 14:32:33 in fact this can be even better ux 2022-10-07 14:32:46 because the sender can be notified after a while that the mail is delayed 2022-10-07 14:33:11 rather than it being accepted on some load-balancing queue belonging to the recipient domain, but unable to get the mail to the actual recipient's inbox where they can read it 2022-10-07 14:33:24 see also: backpressure is a good thing 2022-10-07 14:33:27 I think I'll stick with the current setup, couple of mail routers under my control that eventually deliver to final destination if and when that becomes available 2022-10-07 14:33:55 every mail router is a mitm who can read your mail :) 2022-10-07 14:34:06 including all your account reset tokens :) 2022-10-07 14:34:45 That's why the 'under my control' part 2022-10-07 14:34:58 on your physical premises? :) 2022-10-07 14:35:39 with your armed guards and deadman switches? ;-) 2022-10-07 14:36:07 in a rack in a cage somewhere. I don't consider email _that_ solid. 2022-10-07 14:36:32 i'm playing around, but really email and dns are the roots of all access control 2022-10-07 14:37:25 and i really do think "only accept delivery if you are really the final place the data will be held securely, otherwise let the sender be responsible for it" is the prudent design 2022-10-07 14:39:40 I beg to differ. e-mail has always been designed as store-and-forward, trying to turn that into end-to-end will not work. 2022-10-07 14:39:55 For end-to-end there are other solutions. 2022-10-07 14:40:02 dalias: any idea how many packages it affects? I guess if it is not many (~20?) we could handle it. If it was more, a -D_LARGEFILE64_SOURCE would be nice 2022-10-07 14:42:25 i don't know 2022-10-07 14:42:37 mercenary, but it *does* work 2022-10-07 14:42:53 store-and-forward is backwards thinking from the days of uucp 2022-10-07 14:43:13 there is utterly no reason to have it on a modern internet where all connections are permanent 2022-10-07 14:43:34 ACTION stares in French ISPs 2022-10-07 14:43:39 not all of the internet is modern, unfortunately. 2022-10-07 14:44:01 it will become relevant again very soon with generalized power cuts 2022-10-07 14:44:49 yes, a sender who has sporadic nonpermanent connection needs an outgoing store-and-forward point with a permanent connection 2022-10-07 14:44:53 did someone say power cuts? we are currently on 6 hours on, 2 hours off. So 'final destination' is down for the night :p 2022-10-07 14:45:47 dalias: I assume a -D_LARGEFILE64_SOURCE patch would not be too intrusive? We could may try without it initially, and if turns out to be problematic we can add a custom -D_LARGEFILE64_SOURCE patch to alpine's musl temprarily, which we remove after we have fixed all packages. 2022-10-07 14:45:51 but only if they can't make immediate delivery 2022-10-07 14:46:11 ncopa, it's completely non-intrusive. just removes the _GNU_SOURCE cases 2022-10-07 14:46:33 so only _LARGEFILE64_SOURCE is left in the #if's 2022-10-07 14:46:47 the full patch is more "intrusive" in removing all these blocks 2022-10-07 14:46:56 deprecate instead of remove sounds sane 2022-10-07 16:14:05 psykose: do we also want to rebuild testing with go 1.19.2? 🤔 2022-10-07 16:24:10 ey nmeum, have you thought about gcc-go security backporting for community? if libgo is a clone from official go, maybe is not so difficult to handle 2022-10-07 16:25:35 I can add another comment later, I think it is a lot of work and I am not sure if we want to invest that work just to workaround an upstream bug in community/go 2022-10-07 16:26:08 probably more work is fixing community/go :D 2022-10-07 16:26:32 I think we need to get upstream to fix it for us, don't really see us fixing this kind of issue downsteram 2022-10-07 16:29:56 too much years unfixed on a 5k+ issues repository... it semes unlikely, and it's a pretty corner case, even with glibc 2022-10-07 16:59:56 donoban: right, can be frustrating at times, but this is an upstream issue not something that is caused by stuff we are doing downstream 2022-10-07 17:00:11 with some upstream projects you need to submit patches in order to get them to fix stuff 2022-10-07 17:10:04 it's not exactly an issue for they, it's more like it doesn't work on different libc than glibc, which for their user base is extremely low for care... 2022-10-07 17:13:01 I understand that using gcc-go for it is not ideal, specially if it adds maintance work, but I don't see many alternatives 2022-10-07 17:39:34 panekj: We added -trimpath to GOFLAGS in https://gitlab.alpinelinux.org/alpine/abuild/-/commit/79624340a1ef4ef6aef7d6dc2cd24dba7e014237, but it does not give a motivation as to why 2022-10-07 21:03:35 nmeum: on edge yeah 2022-10-07 21:17:20 ACTION ♫ despite all my sage I'm still just a rack in a cage 2022-10-07 21:37:08 donoban: My scrollback doesn't go back far enough to see what the bug in Go is, but deploying Go binaries on Alpine in Docker is very popular. Getting Go to work with non-glibc is not a weird corner case that no one thinks about. 2022-10-08 09:46:38 psykose: ghostwriter has changed to be a KDE app and while doing so seems to have lost a version (current Alpine version is 2.2.0 and latest on invent.kde.org is 2.1.6). Do you mind if I take over maintenance and downgrade it to the latest KDE version? Or should we wait till they have re-released 2.2.0? 2022-10-08 10:43:33 2.2.0~really2.1.6? 2022-10-08 10:43:44 xordspar0: where the corner case I mean is building go libraries for dynamic loading on C programs, I only know pidgin & purple-gowhatsapp. Sure there are many others but I don't see something very common 2022-10-08 10:44:21 the bug is here https://github.com/golang/go/issues/13492 2022-10-08 11:31:10 PureTryOut: the 2.1.6 version had a bug fixed in 2.2.0 so it would make more sense to do nothing for now 2022-10-08 11:31:16 as for the rest, sure, take it if you wish 2022-10-08 11:33:29 Ah ok we'll wait then 2022-10-08 11:38:35 this is a very strange migration 2022-10-08 11:38:46 why did they remove all of the prior issues it's impossible to refer to now and lose a version 2022-10-08 11:40:21 I have no clue 🤷 2022-10-08 11:40:58 I doubt someone manually transferred the issues to KDE's Bugzilla 🤔 2022-10-08 14:13:32 nmeum: did you see https://lists.alpinelinux.org/~alpine/devel/%3CB923B294-DC86-47DF-B34D-107059863AFE%40kohlschutter.com%3E? 2022-10-08 14:49:04 aea2aa69733578f5742aa1e9ee00b9872b0033dc 2022-10-08 14:49:23 i made an mr for it 2022-10-08 16:04:14 donoban: Got it, thanks for sharing the bug. 2022-10-09 11:50:07 nmeum: sorry to message about this here but would you mind reviewing https://github.com/nmeum/android-tools/pull/78 ("Fix mkbootimg since 33.0.3 upgrade")? 2022-10-09 19:18:08 Hey guys, any ideas why the builder is compiling packages in the wrong order? 2022-10-09 19:18:11 https://gitlab.alpinelinux.org/dm1tz/aports/-/pipelines/139590 2022-10-09 19:19:02 dmitz: educated guess: cyclic dependency? 2022-10-09 19:21:26 you added something to testing/ and tried to depend on it in community/ 2022-10-09 19:21:46 that's another option 2022-10-09 19:22:01 main is built before community is build before testing 2022-10-09 19:22:36 oh, i see 2022-10-09 19:23:14 And the testing repo is not available for packages in community 2022-10-09 19:23:24 and testing+community repo is not available for packages in main 2022-10-09 19:24:24 huh, guess i need to split the MR into two then 2022-10-09 19:24:44 No, that would not work either 2022-10-09 19:24:54 you cannot depend on packages in testing from community 2022-10-09 19:27:11 got it 2022-10-09 19:27:53 So you would need to move pendulum to community 2022-10-09 19:27:57 so instead i move these two cyclic deps into community 2022-10-09 19:27:59 yep 2022-10-09 19:28:29 they're not cyclic 2022-10-09 19:29:28 i mean pgcli depends on pendulum and pendulum depends on pytzdata 2022-10-09 19:29:43 isn't that cyclic? 2022-10-09 19:29:45 No 2022-10-09 19:29:57 it would be cyclic if pytzdata would depend on pgcli 2022-10-09 19:30:45 This is just linear: pgcli -> pendulum -> pytzdata 2022-10-09 19:31:12 gotcha 2022-10-09 19:32:27 but i still have to move pytzdata to community too since it's a pendulum dependency, right? 2022-10-09 19:32:38 yes 2022-10-09 19:32:55 perfect, thanks a lot 2022-10-09 19:59:39 psykose: why did you get rid of the plugin splitting in fwupd...? 2022-10-09 20:00:40 !39956 2022-10-09 20:01:19 ah interesting, thanks 2022-10-09 20:02:05 it is backwards incompatible, i guess we could add a provides= farm too 2022-10-09 20:02:13 but.. eh, i dunno, is it particularly needed 2022-10-09 20:02:35 nah it's fine 2022-10-09 21:29:02 can abuild be easily used in a foreign distro? what does it need ? ( i got abuild+apk-tools setup ) 2022-10-09 21:30:11 building in a chroot (rootbld?) preferred 2022-10-09 21:31:27 on another note, ncopa _alice https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/libgit2/APKBUILD#L53-57 does nothing to the file as the targetted lines moved to tests/libgit2/CMakeLists.txt long ago 2022-10-09 22:06:20 where has the gl approve button gone? 2022-10-10 03:22:00 broken in this gitlab version 2022-10-10 03:48:11 gitlab ci: fatal: could not read Username for 'https://gitlab.alpinelinux.org': No such device or address 2022-10-10 04:26:43 psykose: not broken, it's deliberate 2022-10-10 04:27:41 they changed it that only members of a project can approve MRs 2022-10-10 04:29:08 yep 2022-10-10 04:29:22 hence, broken in this gitlab version (and future ones) 2022-10-10 04:29:23 :) 2022-10-10 04:29:55 it is the better approach though 2022-10-10 04:30:08 giving people a role makes it easy to @ them too 2022-10-10 04:33:04 yup 2022-10-10 04:33:17 It's just calling it broken has a different ring to it 2022-10-10 04:38:56 they don't call em breaking changes for nothin :p 2022-10-10 06:11:37 Is anyone already working on `ERROR: clang15-libclang-15.0.2-r1: trying to overwrite usr/lib/libclang.so.15.0.2 owned by clang-libs-15.0.2-r0.`? 2022-10-10 06:15:18 appears i missed a thing 2022-10-10 06:16:30 if you still have the logs could you post the transaction 2022-10-10 06:18:59 but yeah should be fixed in -r2 2022-10-10 06:19:04 and that should be the last of that 2022-10-10 06:42:07 Oh hey we passed the 40k merge requests on Gitlab 🎉 2022-10-10 06:45:55 indeed 2022-10-10 08:26:28 psykose: Seems to be fixed now. At least my second machine installed updates now just fine. Thx :) 2022-10-10 08:27:30 Where do I put a unsigned firefox extension, built by abuild, for it to be added in firefox? 2022-10-10 08:28:31 We have --with-unsigned-addon-scopes=app,system in firefox, but putting an xpi file in /var/lib/firefox/browser/extensions/.xpi doesn't work 2022-10-10 08:30:57 /usr/lib/firefox/browser/extensions probably 2022-10-10 08:31:37 i'm not sure what the point it 2022-10-10 08:31:39 is* 2022-10-10 08:32:21 *sorry I indeed put it in /usr/lib/firefox/... 2022-10-10 08:33:06 and it did not show up in firefox 2022-10-10 08:33:56 I'm trying to package a couple of firefox addons for my personal use, with a separate aports repository. 2022-10-10 08:34:44 probably needs --allow-addon-sideload or something 2022-10-10 08:35:48 Oh, it's regarding changing firefox flags. I'll look into it. Thanks for the pointer! 2022-10-10 08:36:41 FWIW, this is the extension in question https://paste.sr.ht/~dhruvin/e5363adb70c0e4be3ce68120f80f24a9ce6a8856 2022-10-10 08:37:29 all that gives me is a 502 2022-10-10 08:37:35 in any case you should try a "real" extension first 2022-10-10 08:37:43 build dark-reader from github or something and throw it in there 2022-10-10 08:38:20 to make sure it's not something else (i'm just guessing this is something you made yourself since i can't load it) 2022-10-10 08:38:30 ah, now it does 2022-10-10 08:38:36 ok, this looks fine 2022-10-10 08:38:44 no idea then, see if the extra arg works 2022-10-10 08:39:40 sourcehut gets sad when it has to render a large patch (for package-lock.json) 2022-10-10 08:39:51 Here's just the APKBUILD https://paste.sr.ht/~dhruvin/702b2dfd2a73c2f3223a2b0168539afb87a6d1f1 2022-10-10 08:41:01 re: try extra arg: ack 2022-10-10 15:28:28 i am planning to start work on the 3.17 builers this week 2022-10-10 15:28:51 im sending an email about expected feature freeze from next week in main and the week after that in community 2022-10-10 15:33:46 ncopa: what about outstanding MRs in mdev-conf, mkinitfs, alpine-conf repos? 2022-10-10 15:45:06 those are not critical for the builders. I will try get them fixed before the final release 2022-10-10 15:47:47 ncopa: I have a "chain" where an intended change to cloud-init depends on a mdev-conf MR being merged and then the mdev-conf version in Edge being updated... 2022-10-10 16:00:18 (and same with alpine-conf) 2022-10-10 16:50:59 fcolista: please check community/bareos and nextcloud23 for php81 - they are the only dependent on php8 in community, would be great to fix it before 3.17 freeze and get rid of php8 from community 2022-10-10 19:05:30 ACTION https://t.ly/BTD6 2022-10-11 03:56:21 i haven't looked at the mdev-conf MR -- but there is a possibility that this may require a change with tiny-cloud too - does anyone have a handy link to that MR (ncopa, minimal, etc.) 2022-10-11 04:11:46 https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/2 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/100 2022-10-11 06:16:05 psykose: that was quick! 2022-10-11 06:16:17 ~_^ 2022-10-11 06:16:44 there's a lewd joke in there somewhere 2022-10-11 07:41:53 had no comeback, sorry 2022-10-11 07:43:01 but I installed pgcli in a bare alpine:edge container and noticed that libpq was missing 2022-10-11 07:44:44 I see that py3-psycopg2 depend on libpq but not py3-psycopg (that pgcli depend on) 2022-10-11 07:45:38 both have libpq-dev in their makedepends 2022-10-11 07:46:01 so how is the dependency resolution handled? 2022-10-11 07:48:38 only for things that link it explicitly 2022-10-11 07:50:26 hmmm looks like mkdocs-material has change the distribution file, I can't get my source URL to work with https://pypi.org/project/mkdocs-material/ 2022-10-11 07:50:43 https://files.pythonhosted.org/packages/source/m/mkdocs-material/8.5.6.tar.gz ends in 404 2022-10-11 07:51:05 I don't get why files.pythonhosted.org is not browsable ._. 2022-10-11 07:52:55 just use github 2022-10-11 07:55:13 markand: if it is recently updated it can be that t hasn't landed at pythonhosted yet, I had that the other day and just had to wait a bit 2022-10-11 07:56:43 ah 2022-10-11 07:56:59 https://files.pythonhosted.org/packages/source/m/mkdocs-material/mkdocs_material-8.5.6.tar.gz 2022-10-11 07:57:00 there u go 2022-10-11 07:57:29 you always need the name on that tarball afaik but also they can tr - _ randomly 2022-10-11 07:59:03 I've went from github instead 2022-10-11 08:02:09 oh fun I have a package that fails to find `stdlib.h`. What the hell 2022-10-11 08:03:28 what package 2022-10-11 08:04:40 sometime they play too much with -isystem 2022-10-11 08:04:57 had this with an upgrade of meson in the past while doing my own distro 2022-10-11 08:05:06 meson was passing -isystem all over the place 2022-10-11 08:06:15 currently packaging kaldi (it's not in Alpine yet), https://github.com/kaldi-asr/kaldi 2022-10-11 08:06:51 can you show the build log? 2022-10-11 08:09:42 seems to be something in https://github.com/kaldi-asr/kaldi/tree/master/src/probe. 2022-10-11 08:09:45 ACTION sent a code block: https://matrix.org/_matrix/media/r0/download/matrix.org/DZrRtSFgHfmkbLUyWXQELsDE 2022-10-11 08:09:52 ^ relevant portions of the build log 2022-10-11 08:11:00 that doesn't even have the compiler invocation 2022-10-11 08:11:11 well no but that isn't printed either 😢 2022-10-11 08:11:42 make V=1 works half the time 2022-10-11 08:11:52 maybe not here 2022-10-11 08:13:10 make VERBOSE=1 with cmake 2022-10-11 08:13:19 "okay pee moss, duck you boot" 2022-10-11 08:13:20 or run cmake -DCMAKE_VERBOSE_MAKEFILES=1 2022-10-11 08:13:43 this is not cmake, just a configure 2022-10-11 08:19:32 this seems to be it. `g++ -M -std=c++14 -I.. -isystem /usr/include -O1 -Wall -Wno-sign-compare -Wno-unused-local-typedefs -Wno-deprecated-declarations -Winit-self -DKALDI_DOUBLEPRECISION=0 -DHAVE_EXECINFO_H=1 -DHAVE_CXXABI_H -DHAVE_CLAPACK -I../../tools/CLAPACK -msse -msse2 -g -fPIC -pthread -Os -fomit-frame-pointer -DKALDI_NO_EXPF const-integer-set-test.cc edit-distance-test.cc hash-list-test.cc kaldi-holder.cc kaldi-io-test.cc 2022-10-11 08:19:32 kaldi-io.cc kaldi-semaphore.cc kaldi-table-test.cc kaldi-table.cc kaldi-thread-test.cc kaldi-thread.cc parse-options-test.cc parse-options.cc simple-io-funcs.cc simple-options-test.cc simple-options.cc stl-utils-test.cc text-utils-test.cc text-utils.cc >> .depend.mk` 2022-10-11 08:21:18 looks fine at a glance 2022-10-11 08:22:05 try without -isystem /usr/include 2022-10-11 08:22:10 just by hand 2022-10-11 08:42:54 that does seem to fix it. Luckily I can just edit Makefiles to change that in the global build 2022-10-11 08:44:43 I could have bet my ass 2022-10-11 08:44:46 :-) 2022-10-11 08:44:59 those people who play with -isystem need a slap with a trout 2022-10-11 08:52:33 a lead-laden trout 2022-10-11 08:55:28 oh gosh why tiled guys have switched to qbs ._. 2022-10-11 09:16:32 markand: could you explain what `-isystem` does exactly? 2022-10-11 09:24:23 -I but as a "system include directory" 2022-10-11 09:24:35 and that means...? 2022-10-11 09:24:41 that is already in the list of default system directories and manually compiling code with that isystem doesn't change anything 2022-10-11 09:25:46 it basically override compiler search paths 2022-10-11 09:26:09 normally it's used by toolchains when they bootstrapping 2022-10-11 09:26:17 should not be used by end user 2022-10-11 09:28:04 hmm 2022-10-11 09:28:47 it only changes the order and doesn't override any path 2022-10-11 09:29:03 the reason it breaks is probably just because of fortify headers 2022-10-11 09:29:05 we all love those 2022-10-11 09:29:07 not 2022-10-11 09:30:37 interesting 2022-10-11 09:32:14 that is true (fortify-headers break more things than they solve), but independently of that, "-isystem /usr/include" is probably the most useless option you can give to a C or C++ compiler 2022-10-11 09:32:27 and in this case, harmful 2022-10-11 09:35:30 indeed 2022-10-11 10:58:15 rust tests fails on riscv64: https://tpaste.us/x5Yw 2022-10-11 10:59:03 that's fine 2022-10-11 10:59:06 32-bit arm is the same 2022-10-11 10:59:09 those are some sanity tests i left in 2022-10-11 10:59:20 the +crt-static case is just a sign that static linking won't work 2022-10-11 10:59:28 but nothing in aports uses that. it's just a user convenience 2022-10-11 10:59:35 (and not broken like the rustup binaries which can't do it at all) 2022-10-11 10:59:43 so, i guess on armhf/armv7/riscv64 it won't work, but that's ok 2022-10-11 11:00:11 oor 2022-10-11 11:00:21 yeah 2022-10-11 11:00:25 the -crt-static pass 2022-10-11 11:00:27 all good 2022-10-11 11:00:29 ship it 2022-10-11 11:13:36 i forget, didn't you only add that g-slice thing on edge and not the builder container for riscv running qemu? or does it only matter for the applications running inside on edge and not the qemu-user on top 2022-10-11 11:44:57 oh gosh so now python has a new way of building packages 2022-10-11 11:50:29 for 5 years, give or take 2022-10-11 11:50:38 slowly things move to it 2022-10-11 11:50:57 :P 2022-10-11 11:51:16 python is surely the most inconsistent ecosystem ever made 2022-10-11 11:51:45 everything using setup.py and now using a pep517 entrypoint is a lot more consistent than the 479 c/++ build systems out there 2022-10-11 11:52:10 but as a masochist, i do prefer the latter 2022-10-11 11:52:13 :p 2022-10-11 11:52:24 I do too 2022-10-11 11:52:49 it gets better over the years, now it's more like a large landscape with cmake and unfortunately meson 2022-10-11 11:53:07 more like landscape of meson and unfortunately cmake 2022-10-11 11:53:30 meson is too opinionated and rigid, basically Q: I want to do this; A: don't do that 2022-10-11 11:54:08 and in cmake it's Q: I want to do this; A: copy paste this FindAss.cmake from a random place on github and cause it to fail to compile anywhere except the developers pc 2022-10-11 11:54:09 :p 2022-10-11 11:54:33 i will also never understand those files 2022-10-11 11:54:38 100's of lines for what is 5 lines in .pc 2022-10-11 11:54:59 both have warts but at least CMake has the most comprehensive documentation and does not perform black magic 2022-10-11 11:55:39 cmake doesn't perform black magic? truly something i've never heard someone say before 2022-10-11 11:55:43 that is a new sentence in my life 2022-10-11 11:56:18 CMake does what you tell, the whole thing behind dependency() in meson is kind of black box 2022-10-11 11:56:29 we need a new one to cover them all 2022-10-11 11:56:36 https://xkcd.com/927/ 2022-10-11 11:56:37 [xkcd] Standards | Alt-text: Fortunately, the charging one has been solved now that we've all standardized on mini-USB. Or is it micro-USB? Shit. 2022-10-11 11:57:51 there is less black magic in the entire meson dependency() implementation than in any FindXYZ in cmake and i mean that sincerely 2022-10-11 11:57:54 it was written by people on drugs 2022-10-11 11:58:31 i've worked with it for years and i can confidently say i don't know it at all, which is impressive 2022-10-11 12:03:15 i never understood why cmake became as popular as it did, even autotools made more sense (the devil you know...) 2022-10-11 12:03:47 industry backing and multiplatform support 2022-10-11 12:04:12 even now it's a pretty good option to support linux+macos+windows+bsd 2022-10-11 12:04:21 i don't think mingw ever counted 2022-10-11 12:04:30 ah i see 2022-10-11 12:04:56 but it was also an improvement over what was before, i guess 2022-10-11 12:05:18 now that i am not so sure about :) 2022-10-11 12:06:17 all this could be fixed with 'amake' :D 2022-10-11 12:06:40 it's certainly better than autotools and the scons mess 2022-10-11 12:06:43 those are about the same time 2022-10-11 12:06:48 hmmpf abuild keeps complaining about a redundant rpath. I'm already executing `chrpath -d` on every file I can find in the directory it complains about but it doesn't help 2022-10-11 12:06:56 you can ignore redundant rpath 2022-10-11 12:07:06 !869462 works on my alpine aarch64 but not on the pipeline 2022-10-11 12:07:17 if it's cmake you can also add -DCMAKE_SKIP_RPATH=ON if you want, but eh 2022-10-11 12:07:29 well no as it complains about it 2022-10-11 12:07:32 no not cmake 2022-10-11 12:07:33 I mean !38299 2022-10-11 12:07:38 ah configure thing 2022-10-11 12:07:39 it doesn't fail on it 2022-10-11 12:07:51 redundant rpath is a meaningless warning 2022-10-11 12:08:02 `>>> ERROR: kaldi*: Has /home/... in rpath` 2022-10-11 12:08:04 yes it fails on it 2022-10-11 12:08:06 that's not redundant 2022-10-11 12:08:10 that is /home in rpath 2022-10-11 12:08:15 redundant is a completely different error 2022-10-11 12:08:18 oh sorry yes they are separate messages 2022-10-11 12:08:25 so uh yeah 2022-10-11 12:08:27 gotta delete that one 2022-10-11 12:08:32 I guess the qt6 version in edge has broken tiled 1.9.2 2022-10-11 12:08:38 yeah but no clue what file it's complaining about 2022-10-11 12:10:17 it would be nice if abuild just told you... 2022-10-11 12:10:58 markand: it's missing #include in the file 2022-10-11 12:12:07 and then more includes in other files after you add that 2022-10-11 12:12:20 QStringDecoder next 2022-10-11 12:18:38 sure but I'm surprised to see it's not in upstream 2022-10-11 12:18:45 or maybe no one use the very last version of qt 6 2022-10-11 12:19:36 I don't know if tiled supports Qt 6 officially, Arch folks still target Qt 5 2022-10-11 12:33:20 https://gitlab.alpinelinux.org/markand/aports/-/jobs/869504 what's happening with this pipeline? 2022-10-11 12:38:59 the branch is 30k commits behind 2022-10-11 12:41:40 ah 2022-10-11 12:41:48 let me rebase that 2022-10-11 15:22:30 tomalok: the mdev-conf MR is unlikely to affect tiny-cloud, it simply adds the creation of /dev/block/* and /dev/disk/by-* entries to mdev and mdevd, these are expected by some of cloud-init's modules that configure disks 2022-10-11 17:00:07 never knew that ncopa is ddevault :P 2022-10-11 17:00:46 > I, Natanael Copa, hereby re-license my contributions to the Alpine Linux wiki under the username Ddevault 2022-10-11 17:26:28 assimilation has begun 2022-10-11 17:26:48 :D 2022-10-11 17:35:49 just curious, how do you people feel about this: https://flathub.org/apps/details/io.github.paledega.alpine-rootfs 2022-10-11 17:35:56 surprised this passed review on Flathub 2022-10-11 17:41:12 hmm... it's pretty ironic, many people feel that flatpack bypasses the distribution role, and then flatpack packages a distribution 2022-10-11 17:41:23 Full circle 2022-10-11 17:41:38 It's packaging a distribution in a distribution-independent way 2022-10-11 17:41:48 :) 2022-10-11 17:41:52 you can't escape flatpakOS 2022-10-11 17:42:10 but, I'm more concerned about the branding 2022-10-11 17:42:30 not that it bothers me, but I thought it might bother someone here 2022-10-11 17:42:39 Hmm, it is under their own namespace 2022-10-11 17:43:04 something something logo usage 2022-10-11 17:43:28 the logo is cc-by-sa 2022-10-11 17:43:31 or something like that 2022-10-11 17:43:55 Yeah, the ID is. But it isn't very clear that this is an unofficial setup. However, maybe that doesn't matter? It's just Alpine Linux otherwise 2022-10-11 17:45:05 well, it is slightly worrying since it's not official tarball from alpine 2022-10-11 17:45:29 They could sneak in their own keys and repos 2022-10-11 17:46:30 yay, github is down 2022-10-11 17:46:51 it uses apk initdb to build first tarball, then overlays it with script that does more things 2022-10-11 17:47:39 https://github.com/flathub/io.github.paledega.alpine-rootfs/blob/master/io.github.paledega.alpine-rootfs.yaml 2022-10-11 17:48:09 ikke: ye I'm looking at source 2022-10-11 17:48:10 https://github.com/paledega/alpine-rootfs/blob/main/src/alpine.sh 2022-10-11 17:48:10 Note that there is also a wsl alpine distribution, which is similar 2022-10-11 17:48:21 https://github.com/paledega/alpine-rootfs/blob/main/.github/workflows/blank.yml 2022-10-11 17:48:48 which I believe someone from TSC did not have fond memories with 2022-10-11 17:49:13 I do use it :P 2022-10-11 17:49:24 (I use it too) 2022-10-11 17:49:57 We do not have any trademarks, and not any means to enforce it anyway 2022-10-11 17:50:13 so at most we can kindly ask to stop doing things if it's detrimental 2022-10-11 17:51:15 it's a bit different when technical users use something vs users who are not so technical 2022-10-11 17:52:38 I think (speaking for myself) as long as they are not claiming to be officially coming from the alpine linux project, it should not be an issue 2022-10-11 17:53:52 ikke: really? ariadne has been threatening an Alpine group on Telegram and talking about "marks". 2022-10-11 17:54:06 now, to be clear, I think those actions are justified given the behaviour of the owner of said group … 2022-10-11 17:54:13 Yes, I'm aware 2022-10-11 17:54:22 But 1. they claim to be Alpine Linux 2022-10-11 17:54:40 and 2. we cannot do anything more 2022-10-11 17:54:49 we do not hold any *registered* marks, but we do have marks. 2022-10-11 17:54:57 I see, thanks 2022-10-11 17:55:40 Newbyte: i only do this whenever i hear complaints about whatever piccoro has done this week 2022-10-11 17:56:04 our position has not changed, incidentally. we would like him to stop :) 2022-10-11 17:56:22 existing 2022-10-11 17:56:31 Ariadne: did you see his Alpine installation guide? it sucks. then when I helped him fix some missing parts he blamed it on libinput 2022-10-11 17:56:43 so it wasn't his own fault it was broken, it was libinput 2022-10-11 17:56:47 somehow 2022-10-11 17:56:48 great guy 2022-10-11 17:57:02 i mean, stuff like this is why he was asked to stop participating on our wiki. 2022-10-11 17:57:24 i mean, I already proved him couple of times how broken everything is made by him 2022-10-11 17:57:24 he threatened to sue us if we changed "his" documentation (e.g. to fix it so it was accurate) 2022-10-11 17:57:33 but then he shrugged off saying "it work on my pc" 2022-10-11 17:57:44 or "I have 100s of PCs not you" 2022-10-11 17:57:44 That's what lead to the wiki relicensing 2022-10-11 17:58:15 needless to say, we do not endorse nor recommend his alpine group on telegram. in fact, quite the opposite really. we recommend not joining it or interacting with him. 2022-10-11 17:58:27 unfortunately it's the top result if you search for Alpine on Telegram 2022-10-11 17:58:39 re: flatpak 2022-10-11 17:58:40 ¯\_(ツ)_/¯ 2022-10-11 17:58:41 full of scam accounts 2022-10-11 17:58:45 are there any other telegram groups that are better? 2022-10-11 17:58:52 there is one 2022-10-11 17:58:53 maybe we can recommend an alternative 2022-10-11 17:59:01 a friend of mine made one but it doesn't rank high enough so no one joins 2022-10-11 17:59:02 Interesting: https://t.me/alpinelinux 2022-10-11 17:59:06 reserver by Natanael 2022-10-11 17:59:10 though i would not like to recommend the use of proprietary services (like telegram) 2022-10-11 17:59:22 https://t.me/alpine_english 2022-10-11 17:59:34 ikke: yes. believe it or not, but I'm confident that isn't Gerhard/piccoro but rather some other jackass 2022-10-11 17:59:45 (i mean, i use proprietary services in my own personal capacity, but alpine should not recommend proprietary services/software) 2022-10-11 17:59:55 I agree 2022-10-11 18:00:01 let's start with getting rid of the twitter account 2022-10-11 18:00:13 ikke: this is a group that someone tried to pass as official one impersonating ncopa not so long ago 2022-10-11 18:00:13 t.me/NatanaelCopa 2022-10-11 18:00:19 yes 2022-10-11 18:00:23 was about to say 2022-10-11 18:00:27 ddevault: given the new ownership, i am far more in favor ;) 2022-10-11 18:00:48 was it bought already? 2022-10-11 18:00:57 panekj: He could no longer avoid it 2022-10-11 18:00:59 i dunno, i don't really pay attention anymore 2022-10-11 18:01:02 new ownership of what? 2022-10-11 18:01:04 twitter 2022-10-11 18:01:10 oh, right 2022-10-11 18:01:18 whatever, proprietary is proprietary 2022-10-11 18:01:18 what is this about? 2022-10-11 18:01:23 don't care what prick owns it 2022-10-11 18:02:17 at least Twitter has an API that lets you create open source clients (which they seem to hate nowadays) 2022-10-11 18:02:35 proprietary is proprietary 2022-10-11 18:02:41 we could have a mastodon or something if someone cares to maintain such a thing 2022-10-11 18:03:07 the last time i interacted with piccoro, it was because he was posting in his telegram group (which uses our logos/name/etc without permission) things intended to start a flamewar between alpine and void 2022-10-11 18:03:24 it sounds to me more like you're bothered that Twitter isn't decentralised. whether the backend service is proprietary or not isn't something you can verify. 2022-10-11 18:03:39 no, I don't like it beacuse it's non-free 2022-10-11 18:03:59 we can't objectively trust that whatever backend is running on a service is non-free 2022-10-11 18:04:04 but we can do a hell of a lot fucking better than twitter 2022-10-11 18:04:37 don't give me some bullshit take about how proprietary software is fine because magic hand wavy reasons 2022-10-11 18:09:52 i've also tried to reach out to telegram about piccoro's channel/group/whatever (he has multiple things on telegram, all of which are using our name/logos/etc), and they have never responded about it. i suspect they will only respond to a proper legal claim, which alpine does not have the resources to bring forward 2022-10-11 18:10:20 it's not the end of the world, just don't endorse it and move on imo 2022-10-11 18:10:27 right 2022-10-11 18:10:38 if they come into our spaces starting trouble e.g. with void then apply the CoC and, again, move on 2022-10-11 18:10:45 I think the problem is that people join it and get insulted by this jerk who can't articulate himself 2022-10-11 18:10:57 and then get that image of Alpine 2022-10-11 18:11:13 a public statement about it somewhere might be sufficient 2022-10-11 18:11:18 ddevault: he was already banned from alpine spaces a long time ago, the last of which being the wiki 2022-10-11 18:11:21 alpinelinux.org/posts 2022-10-11 18:11:28 oh, is it /that/ moron 2022-10-11 18:11:31 yes 2022-10-11 18:11:33 lol 2022-10-11 18:11:40 still, my comments remain unchanged 2022-10-11 18:11:54 i agree that a news post may be appropriate 2022-10-11 18:13:14 for instance recently I told someone in there to join the Alpine Matrix/IRC instead of asking their question in that group and I was told that this group is bridged to Matrix/IRC by another person in the group so I definitely think there is some misconception 2022-10-11 18:13:22 whether this is something to be concerned about, I don't know 2022-10-11 18:13:30 it isn't bridged to any of our IRC channels 2022-10-11 18:13:40 there was also another person that got insulted by mckay because they mentioned Windows 2022-10-11 18:13:41 yeah, it isn't. but that Telegram group is bridged to Matrix/IRC 2022-10-11 18:13:42 it's no one's responsibility to maintain a precense in unofficial spaces 2022-10-11 18:13:58 if it's stressing you out, drop it 2022-10-11 18:14:02 or just drop it unconditionally, whatever 2022-10-11 18:14:48 ^ i think we should just make a statement that alpine does not have any groups on telegram, and if you are told to join an "alpine" space on that service that it hasn't anything to do with the project 2022-10-11 18:27:15 https://paste.sr.ht/~sircmpwn/13930082b3ccfd55b39996a606fb5ea513f4f322 2022-10-11 18:28:21 worth mentioning that irc channels are bridged to matrix 2022-10-11 18:28:34 and that Alpine wiki is community-based documentation 2022-10-11 18:29:08 https://paste.sr.ht/~sircmpwn/589b6404e574c5d6f6570b0e676c8ad2ed9033ef 2022-10-11 18:29:11 Ariadne: he still opens an occasional Issue on gitlab 2022-10-11 18:29:28 and comments stupid stuff on PRs 2022-10-11 18:29:57 does he? can somebody report his comments to gitlab admins? 2022-10-11 18:30:00 it will be fixed :) 2022-10-11 18:30:17 done 2022-10-11 18:30:44 it has been made clear to him from multiple people involved in TSC and also Council that he is not welcome here 2022-10-11 18:31:19 https://gitlab.alpinelinux.org/mckaygerhard 2022-10-11 18:32:04 ah, he does not do in gitlab what he has done in other spaces 2022-10-11 18:32:13 hence why not reported 2022-10-11 18:36:00 it slightly tamed 2022-10-12 06:39:21 psykose: holy shit you got Electron working on Alpine? Nice! 2022-10-12 06:39:29 ages ago now 2022-10-12 06:39:30 but yeah 2022-10-12 06:40:42 I've only just seen it, awesome work! 2022-10-12 06:40:58 I see also Code-OSS is packaged. I wonder what the difference is with VSCodium which I normally use 2022-10-12 06:42:15 it's the same thing 2022-10-12 06:42:18 minus most of the patches 2022-10-12 06:42:49 VSCodium has less patches? What are the functional differences then? 2022-10-12 06:42:52 other way 2022-10-12 06:43:05 the one in the repo is just my weird version 2022-10-12 06:43:16 normal vscode with the same openvsx registry and the vscodium product.json 2022-10-12 06:43:25 and then some patched out telemetry 2022-10-12 06:43:30 vscodium has even more patches for that i guess 2022-10-12 06:43:45 as well as other small things 2022-10-12 06:43:46 https://github.com/VSCodium/vscodium/tree/master/patches 2022-10-12 06:45:31 ah ok interesting 2022-10-12 06:45:32 i also never use it myself i just saw someone using vscode from a debian chroot and passing stuff around to mount folders properly and went "nah" and added it to alpine instead 2022-10-12 06:47:23 I use it in an Arch Linux container using distrobox normally. Works pretty great but a native method is always better of course. I just need Flutter on Alpine now and I'm set 2022-10-12 06:47:37 Hmm CodeOSS misses a proper icon for me, it's just using the standard Wayland one 🤔 2022-10-12 06:47:58 yeah has no icon 2022-10-12 06:48:00 maybe i should add one 2022-10-12 06:48:25 and by add i mean fix the name 2022-10-12 06:49:55 lol. I wonder if we could use the VSCodium logo, it's quite good and imo better than the default VSCode one 2022-10-12 06:51:08 that would be a little strange as it's not actually vscodium 2022-10-12 06:52:22 can this be merge !38299 now that it's working? 2022-10-12 06:52:36 and thanks psykose who have packaged qbs for that! 2022-10-12 06:57:35 hm, for some reason the icon just refuses to load 2022-10-12 06:57:43 forgot how to debug these weird desktop file issues 2022-10-12 06:57:56 not the only thing with the same issue 2022-10-12 07:48:00 codeoss and vscodium are two different things? 2022-10-12 07:48:09 yes 2022-10-12 07:48:27 such a waste 2022-10-12 07:49:07 codeoss is what you get when you build vscode git repo 2022-10-12 07:49:17 vscodium does some stuff ontop of that 2022-10-12 07:49:46 ah so codeoss is vscode actually 2022-10-12 07:49:53 kind of 2022-10-12 07:50:05 I thought there was codeoss, vscode and vscodium 2022-10-12 07:50:08 vscode is codeoss + microsoft branding + VS online licence 2022-10-12 07:50:22 okay 2022-10-12 07:50:42 https://code.visualstudio.com/license 2022-10-12 07:50:44 I've tried vscodium once but I can't get out of my vim habits 2022-10-12 07:51:13 have you tried using some kind of vim plugin? 2022-10-12 07:51:23 yes but it is still somewhat limited 2022-10-12 07:51:32 and then you get troubles using the standard keybinds 2022-10-12 07:51:35 so was quite annoying 2022-10-12 07:52:14 depends on your needs (and os setup) you might like lapce 2022-10-12 07:52:52 I was learning vis 2022-10-12 07:54:26 has lapce fixed their awful ui rendering yet 2022-10-12 07:54:30 ACTION checks 2022-10-12 07:54:37 nope 2022-10-12 07:55:14 let see how black stars cargo needs to download 2022-10-12 07:55:48 psykose: what rendering 2022-10-12 07:58:00 the fonts look like they got passed through some antialiasing/subpixel/whatever from 2004 2022-10-12 07:58:18 throws me back to the windows xp days for sure 2022-10-12 07:58:33 sounds like you've got just some skil issue 2022-10-12 07:58:46 take screenshot 2022-10-12 08:00:11 https://usercontent.irccloud-cdn.com/file/iSzqX8bB/image.png 2022-10-12 08:00:39 that looks fine to me? 🤔 2022-10-12 08:01:07 (we fixed a lot of issues since 0.2.0, release soon™️) 2022-10-12 08:01:20 even in this picture it looks scuffed somehow 2022-10-12 08:01:25 but i did mean your screen and not the marketing 2022-10-12 08:01:38 it is my screen 2022-10-12 08:01:46 hmmmm 2022-10-12 08:01:56 post the font configuration of that 2022-10-12 08:02:03 https://usercontent.irccloud-cdn.com/file/SpFTykp4/image.png 2022-10-12 08:02:39 nah lil bro shopped for sure 2022-10-12 08:02:46 everyone knows you actually use eu-east aws 2022-10-12 08:02:46 some fonts are still scuffed 2022-10-12 08:03:09 but for real post the font settings 2022-10-12 08:03:14 I'm using ui: system, editor/terminal: FiraCode NF 2022-10-12 08:03:15 let me try the same 2022-10-12 08:03:17 okie 2022-10-12 08:10:45 if i copy the same it indeed looks like that 2022-10-12 08:10:49 guess that's as close as it would get 2022-10-12 08:11:09 as I said, some fonts still look scuffeed, it's wip 2022-10-12 08:11:34 i only had to navigate the other 10 ui issues to get that far /s 2022-10-12 08:11:40 but yeah it's better than 0.1.3 for sure 2022-10-12 08:11:40 gj 2022-10-12 08:11:58 it's even better on HEAD 2022-10-12 08:16:47 Updating git repository `https://github.com/VixieTSQ/tree-sitter-haxe` 2022-10-12 08:16:47 error: failed to get `tree-sitter-haxe` as a dependency of package `lapce-core v0.2.0 (/home/markand/downloads/lapce-0.2.0/lapce-core)` 2022-10-12 08:16:59 heh, this is why I don't do any language with centralized dependencies 2022-10-12 08:17:29 will be fixed once we have lazy loading implemented 2022-10-12 08:17:38 that's also a thing that I like with srpms, we have reproducible offline builds 2022-10-12 08:18:01 you can cargo vendor and it works fine 2022-10-12 08:18:03 I'd love to see a kind of .src.apk files 2022-10-12 08:18:21 might as well add that to ci 2022-10-12 08:19:19 for 0.2 you can just apk add lapce 2022-10-12 08:28:20 ugh, that UI 2022-10-12 10:16:37 Hello, question regarding move of package from testing to community: How long shall one wait after getting package into testing before moving it? Are some waiting periods described somewhere? 2022-10-12 10:29:51 i usually wait a few upgrade to see if the package is stable 2022-10-12 10:30:45 graywolf: there are no pre-defined criteria 2022-10-12 10:32:55 Hm, so I guess I'll wait until 3.17 is out and do it then. 2022-10-12 10:50:30 And since I'm here, anyone has idea how to handle if I need for package in main/ makedepends from community/ (https://lists.alpinelinux.org/~alpine/devel/%3CY0HjLSt0d27AjpWY%40ws%3E)? 2022-10-12 11:13:37 imo 2 would be the best option; you could open a MR with this new subpackage and moving emacs to main 2022-10-12 11:17:55 Depends on if we want to support emacs for 2 years 2022-10-12 11:46:43 psykose: man, you're faster with that merge button than i can write my explaining comments :) 2022-10-12 11:46:58 ^_^ 2022-10-12 11:47:22 it was either that or changing it to use /etc/ssl1.1/openssl.cnf and depending on the 1.1-compat version 2022-10-12 11:47:25 this seems a bit better 2022-10-12 11:47:30 i assume they can't read the openssl3 format of the cnf 2022-10-12 11:48:00 yeah, that's my assumption too 2022-10-12 13:19:03 cool, looks like riscv64 built community repo 2022-10-12 13:20:44 yeah it's all good 2022-10-12 14:05:52 oh it builds Rust again? 2022-10-12 14:06:53 i'll give it a 50% of breaking next release, but yeah 2022-10-12 14:06:57 the separate hanging issue was fixed 2022-10-12 14:11:09 well that's doable 😂 2022-10-12 14:11:43 Pine64 is releasing a RISC-V board which should be more powerful than the ones released so far afaik, hopefully that'd be a good first machine to act as a builder 2022-10-12 14:12:16 Interesting 2022-10-12 14:17:00 unless it's.. 2022-10-12 14:17:02 ACTION checks notes 2022-10-12 14:17:35 maybe 8x faster, it won't be faster 2022-10-12 14:30:21 Ah, the benchmarks from who was it again? 2022-10-12 14:30:28 q66? 2022-10-12 14:31:32 yeah 2022-10-12 14:32:05 the pine64 board doesn't look all that special 2022-10-12 14:32:05 it won't be very fast 2022-10-12 14:32:31 the first chance of something decent will come once something with horse creek comes out 2022-10-12 14:32:42 but as far as i know that'll be 4 cores only, so it still won't be very fast 2022-10-12 14:32:46 maybe raspberry pi 4 level 2022-10-12 14:34:55 so far it just looks like arm but worse 2022-10-12 14:35:09 can't wait to be proven right in 10 years 2022-10-12 14:37:23 the usual blogspam says it's cortex-a75 level so it might be a bit faster than the rpi 2022-10-12 14:42:11 Arm at least has servers with 128+ cores and plenty of memory 2022-10-12 14:43:52 sifive are long due for a new board 2022-10-12 14:44:00 maybe there's still hope to prove psykose wrong 2022-10-12 14:44:19 i mean it literally 2022-10-12 14:44:29 they're never going to beat arm in anything, just match it at some point 2022-10-12 14:44:49 with the exact same firmware blobs 2022-10-12 14:45:07 and the exact same 3-4-5-whatever company dominance 2022-10-12 14:45:23 but its freeeeeeee 2022-10-12 14:45:34 sadly the billions to set up a chip design isn't 2022-10-12 14:45:38 who could've predicted it 2022-10-12 14:46:17 it's an "improvement" but not for end-user personal computing hardware for sure 2022-10-12 14:46:22 nobody, probably 2022-10-12 14:46:40 certainly makes it easy to make small chips for small products without licencing 2022-10-12 15:27:46 psykose: https://mta.openssl.org/pipermail/openssl-announce/2022-October/000237.html 2022-10-12 15:28:01 nice 2022-10-12 15:28:13 where's the link to the regression tho 2022-10-12 15:28:16 classic openssl mailing 2022-10-12 15:28:26 the 1.1.1r changelog was just 'fix compilation issues' 2022-10-12 15:28:32 wtf did they mess up this time 2022-10-12 15:28:39 bytes 2022-10-12 15:28:45 ah i see 2022-10-12 15:28:48 they use 9bit bytes now 2022-10-12 15:28:52 profound! 2022-10-12 15:29:57 https://github.com/openssl/general-policies/pull/32 2022-10-12 15:30:08 thanks 2022-10-12 15:30:22 ++ to revert as php also fails one test 2022-10-12 15:30:27 like Look 2022-10-12 15:30:29 at This 2022-10-12 15:30:29 https://www.openssl.org/news/openssl-1.1.1-notes.html 2022-10-12 15:30:35 >Added a missing header for memcmp that caused compilation failure on some platforms 2022-10-12 15:30:37 that's all it is 2022-10-12 15:31:01 will revert in 5 seconds 2022-10-12 15:31:24 MemeSSL 2022-10-12 15:33:32 done 2022-10-12 15:35:16 https://github.com/openssl/openssl/issues/19389#issuecomment-1275517014 2022-10-12 15:35:17 icant 2022-10-12 15:35:33 the meme python crypto crate is better at this than openssl itself 2022-10-12 15:35:58 alpinessl when 2022-10-12 15:36:07 one day there will be a replacement 2022-10-12 15:36:08 one day 2022-10-12 15:36:46 but as it stands any replacement has to implement the full openssl api or a bunch of things would be unusable 2022-10-12 15:36:50 libressl isn't really much better 2022-10-12 15:36:57 that's the problem with openssl, yes: the api 2022-10-12 15:37:07 i don't care about the code 2022-10-12 15:37:12 else we could all use libtls-bearssl and the world would be puppies and rainbows 2022-10-12 15:37:38 alas, some programs written by masochistic baboons insist on using the OpenSSL API 2022-10-12 15:37:44 yes, but that's how it is 2022-10-12 15:38:12 porting them all to "something else" is just the standards meme 2022-10-12 15:38:14 it also already exists 2022-10-12 15:38:19 there are like 15 crypto libraries 2022-10-12 15:38:35 yes 2022-10-12 15:38:47 (and only 1 good one design-wise :P) 2022-10-12 15:39:10 is bearssl the one that breaks abi every release 2022-10-12 15:39:16 oh wait that's like half of them 2022-10-12 15:39:28 tbh I wish there were more bearssl releases 2022-10-12 15:39:46 me too, but it's just one of those crypto libraries you can't expect hundreds of things to use 2022-10-12 15:39:50 as always, i don't care about the code :p 2022-10-12 15:40:01 it's good that you don't, but it's good that I do 2022-10-12 15:40:05 indeed 2022-10-12 15:42:45 i would probably care more about the code if i could actually write any code 2022-10-12 15:42:45 alas 2022-10-12 15:44:56 you don't need to be an artist to be a good critic :) 2022-10-12 15:45:40 Oh, another fun one: https://gitlab.haskell.org/ghc/ghc/-/issues/22282 2022-10-12 15:45:47 "GHC 9.4.2 regresses being able to do math on aarch64" 2022-10-12 15:48:14 Luckilly we are far behind :P 2022-10-12 15:50:18 technically not, 9.0 is just the latest lts 2022-10-12 15:50:22 by stackage snapshot anyway 2022-10-12 15:50:30 i don't think half the things even build on 9.4 2022-10-12 15:50:36 ok 2022-10-12 15:50:48 We're still far-behind on purpose then :P 2022-10-12 15:51:01 :) that's better 2022-10-12 17:35:02 find it funny that when gcc segfaults it tells you to "just go submit a bug report with the preprocessed source", but clang actually dumps the source and the compiler args into a tmpdir file for you to do that with 2022-10-12 17:35:40 maybe one day i'll actually do it 2022-10-12 18:39:08 how did you manage to segfault gcc? are you compiling /dev/random? :D 2022-10-12 18:48:08 i do it all the time somehow 2022-10-12 18:48:20 in this case, random thing on riscv64 2022-10-12 19:48:31 there's -freport-bug but it's not as good as clang 2022-10-12 19:50:50 ah right 2022-10-12 19:50:57 does require to rerun it once though, so inconvenient /s 2022-10-12 19:51:26 hows it going in gentoo land 2022-10-12 19:51:27 anything fun 2022-10-12 21:11:55 honestly i'm just zonked af at the moment 2022-10-12 21:11:58 not much energy 2022-10-12 21:12:10 nothing bad, just tired 2022-10-12 21:12:17 the clang 16 mess is not helping 2022-10-12 21:12:21 how about you 2022-10-13 00:16:53 ah, clang 16 will be fun for sure : ) 2022-10-13 00:17:01 nah nothing fun here 2022-10-13 00:17:01 same old 2022-10-13 00:17:15 somehow still have the same energy 2022-10-13 00:17:19 wonder when that runs out 2022-10-13 00:37:01 when you get renovicted 2022-10-13 00:37:10 that's what ended my most epic coding binge 2022-10-13 00:50:21 Did anyone propse enabling ktls in nginx yet? 2022-10-13 00:54:05 it is 2022-10-13 00:54:09 valerius: hah, unfortunate 2022-10-13 00:54:42 it worked out... I moved 1700 miles and bought a house in cash, now my monthly living expenses are below $800 2022-10-13 00:54:46 best thing that ever happened to me 2022-10-13 00:54:49 ah, or is it 2022-10-13 00:55:16 Oh it should already be on? Or was that not in response to me? I'll test again then. 2022-10-13 00:56:55 i guess it actually wasn't, you could open an aports issue 2022-10-13 00:57:13 alright 2022-10-13 00:57:49 ooor 2022-10-13 00:57:51 idk 2022-10-13 00:57:52 test it 2022-10-13 00:58:09 ^^ 2022-10-13 00:58:15 the build guides don't even have a toggle for it 2022-10-13 00:58:21 they're just things for openssl itself 2022-10-13 00:58:23 and that has it enabled 2022-10-13 00:58:42 This page only has the openssl switch https://www.nginx.com/blog/improving-nginx-performance-with-kernel-tls/ 2022-10-13 00:58:47 --with-openssl-opt=enable-ktls 2022-10-13 00:58:52 yep 2022-10-13 01:00:07 nginx: [emerg] SSL_CONF_cmd("Options", "KTLS") failed (SSL: error:1414E180:SSL routines:SSL_CONF_cmd:bad value:cmd=Options, value=KTLS) 2022-10-13 01:00:48 did you modprobe tls first 2022-10-13 01:00:58 and are you on edge 2022-10-13 01:01:01 it's not in 3.16 2022-10-13 01:03:17 ah I'm not on edge 2022-10-13 01:05:59 ah it works on edge 2022-10-13 01:06:10 _how close is a stable release?_ 2022-10-13 01:06:41 wasn't there just one? 2022-10-13 01:08:16 and no errors in the log 2022-10-13 01:08:23 valerius: 2022-08-09 2022-10-13 01:09:47 damn that's fast 2022-10-13 01:10:07 just eyeballing ofc but like 2x 2022-10-13 01:10:55 or maybe the server just needed a reboot 2022-10-13 01:11:00 anyway, thanks for your help 2022-10-13 01:12:33 no, it was a while ago 2022-10-13 01:12:38 though the next one is in a month or so 2022-10-13 12:43:51 andypost[m], sorry for the delay. I've asked BareOS upstream if php 8.1 is fully supported. Re: nextcloud23, I'm not the maintainer 2022-10-13 14:29:52 why gcc for arm arches doesn't recognize -m32 and -m64 arguments? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/40126 2022-10-13 14:32:45 its 2 separate arch 2022-10-13 14:32:57 i dont think aarch64 can do 32 2022-10-13 14:38:08 and musl libc does not support multilib so you cannot really use -m32 anywhere 2022-10-13 14:38:12 yeah, this bulky makefile in the project has build targets for 32bit and 64bit arches. i say it to build 32bit executable for armhf, armv7 and x86 and 64bit executable otherwise. i guess -m32 and -m64 are just arch specific? 2022-10-13 14:57:02 ok, i figured it out - makefile for the project was not conceived for architectures other than x86, and the mandatory setting of -m32 and -m64 shouldn't have harmed, but in the case of arm, even though i set -m64 for aarch64, and -m32 for armhf and armv7, an error appeared; because, as bl4ckb0ne pointed out, architectures themselves are different in bitness and having these arguments in gcc does not 2022-10-13 14:57:08 make much sense 2022-10-13 19:18:58 simply always remove the -m 2022-10-13 19:19:02 :) 2022-10-13 19:43:04 ok 2022-10-13 20:33:36 Hmm a package (mozjs102) fails on riscv64, `usr/bin/strip: ./usr/lib/stFJKimH: not enough room for program headers, try linking with -N`. How can I fix that? 2022-10-13 20:43:05 let me see the binutils mailing list.. 2022-10-13 20:46:30 hm 2022-10-13 20:46:34 nothing jumps out sadly 2022-10-13 20:48:38 i'd guess it applies to anything built with clang and stripped with binutils strip on riscv64 2022-10-13 20:48:57 i'd also guess it's probably fixed on latest commit of binutils but that takes a while to check 2022-10-13 20:49:20 yeah... 2022-10-13 20:49:53 not the first riscv binutils issue 2022-10-13 20:50:20 i got a bit tired of looking at them 2022-10-13 20:50:29 the temp workaround was in testing/wpewebkit with !strip3 2022-10-13 20:50:33 !strip * 2022-10-13 20:50:58 no way to override the strip command for abuild to use something else 2022-10-13 20:52:40 hm, actually 2022-10-13 20:54:10 it's probably more about lld output on riscv64 not being able to be stripped 2022-10-13 20:54:39 q66: hey heard of any fixes for that ^ 2022-10-13 20:57:29 I'll add `!strip` to riscv64 for now then with a TODO 2022-10-13 20:58:36 what 2022-10-13 20:58:48 i wouldn't know about that 2022-10-13 20:58:51 i don't even have binutils 2022-10-13 20:59:52 i know 2022-10-13 22:01:21 fwiw i do have mozjs102 on riscv64 and it works just fine 2022-10-13 22:01:29 even stripped 2022-10-13 22:01:49 using elftoolchain strip 2022-10-13 22:02:13 and lld linker 2022-10-13 22:02:40 (chimera does not use llvm's tools as default binutils) 2022-10-13 22:11:57 yeah it works with any other strip but binutils xD 2022-10-13 22:49:09 fcolista: thank you! I filed #14262 to track state as it's only blocker to move php8 to community 2022-10-13 23:54:43 psykose: why do i feel like i've heard that before 2022-10-13 23:54:57 because it's always true sadly 2022-10-13 23:55:29 q66: oh yeah i was meaning to ask actually 2022-10-13 23:55:38 why you didn't use llvm-binutils as primary after bootstrap 2022-10-14 00:02:52 psykose: because llvm's "binutils" is not complete, it does not provide a libelf so i need an implementation of that anyway 2022-10-14 00:03:05 and at that point might as well have compiler-independent "binutils" too 2022-10-14 00:07:03 ah 2022-10-14 00:35:22 psykose: binutils actually does not provide libelf either, but elfutils does, and elftoolchain replaces both for me (minus linker) 2022-10-14 00:36:08 it also lets me see what software is stupid and relies on objdump during build, as elftoolchain does not implement it 2022-10-14 00:39:30 convenient ~_~ 2022-10-14 00:39:54 maybe i should make my own distro at some point so i can do my own memes 2022-10-14 00:42:25 it's not worth it for memes 2022-10-14 00:43:32 what makes you say that 2022-10-14 00:45:34 most of it involves fixing other people's shit software 2022-10-14 00:46:18 that's what i'm already doing 2022-10-14 00:47:24 that's the point 2022-10-14 00:47:37 if you want to make something actually unique, you end up doing that a lot more 2022-10-14 00:47:41 and if you don't, then it's just boring 2022-10-14 01:04:27 exactly :p i'd get to fix shit software in weird configurations 2022-10-14 01:04:34 but more realistically i would give up after 4 hours 2022-10-14 01:11:07 the bootstrapping part and making a build system would also take forever 2022-10-14 09:55:41 hi, trying to compile, https://github.com/pelya/android-shmem 2022-10-14 09:55:49 getting -- ./sys/shm.h:56:5: error: unknown type name '__uid_t' 2022-10-14 09:55:59 any suggestion/guide ? 2022-10-14 10:01:13 remove the __ 2022-10-14 10:04:51 thanks, it builds \0/ 2022-10-14 18:07:44 compiling android-shmem was to run postgresql on android, think I would wait till I compile kernel first, hopefully ;) 2022-10-14 21:03:24 bl4ckb0ne: anything special to test on this cemu thing 2022-10-14 21:03:29 just compiled it 2022-10-14 21:03:39 gz 2022-10-14 21:03:46 dunno, botw maybe 2022-10-14 21:04:00 i want to see the shrek mod running 2022-10-14 21:05:03 nice meme 2022-10-14 21:06:08 you can also close my cemu MR if you're pushing yours 2022-10-14 21:06:15 how did you managed to compile it? 2022-10-14 21:06:25 i stared at it really hard and it built 2022-10-14 21:06:30 but also they fixed a bunch of shit 2022-10-14 21:07:48 https://img.ayaya.dev/orjoAcHeFjml 2022-10-14 21:07:51 as you can see it's a work of art 2022-10-14 21:15:38 ship it 2022-10-14 21:15:44 what did you do for imgui 2022-10-14 21:17:29 usual git submodule 2022-10-14 21:17:59 https://gitlab.alpinelinux.org/psykose/aports/-/commit/3b934f9e3af1ad337c7861a4b7b3821ea1525dc9 2022-10-14 21:17:59 yikes 2022-10-14 21:18:02 test it all you want 2022-10-14 21:18:18 idk where to get the fell-off-the-back-of-a-truck stuff for now 2022-10-14 21:18:24 been awake for almost 30 hours 2022-10-14 21:18:42 for all the modules there there is zero point to have separate packages 2022-10-14 21:18:47 cubeb doesn't even have releases 2022-10-14 21:18:53 zarchive is literally a fork of something for this 2022-10-14 21:19:03 imgui is everyones small static linked weird thing 2022-10-14 21:19:07 i think you can get "games" on the internet 2022-10-14 21:19:11 my cousin told me that 2022-10-14 21:19:11 games sure 2022-10-14 21:19:16 the rest i'll do another time 2022-10-14 21:19:19 if you want to trudge the code 2022-10-14 21:19:20 the uhh 2022-10-14 21:19:23 resources folder 2022-10-14 21:19:32 has a shaderCache 2022-10-14 21:19:37 but ofc that isn't writable in usr/lib 2022-10-14 21:19:42 neat 2022-10-14 21:19:45 you can fix it up to use any other place 2022-10-14 21:19:47 quality software 2022-10-14 21:19:58 you're good at the programming stuff you'll manage 2022-10-14 21:20:06 the above builds fine 2022-10-14 21:20:31 ill try to get sometime 2022-10-14 21:20:33 you'll have to wait for wxwidgets/libzip to rebuild on builders first, that's about it 2022-10-14 21:20:47 i think i got about 15h sleep in the last 3 days 2022-10-14 21:20:55 that's epic nice i love that one 2022-10-14 21:33:21 of course it segfaults with wayland 2022-10-14 21:33:54 awesome 2022-10-14 21:35:06 usual wxwidgets issue 2022-10-14 21:35:18 swapping to qt6 for pcsx2 was poggers as everything just works after 2022-10-14 21:37:05 bro this botw thing is 10GB 2022-10-14 21:37:11 do u think internet speed grows on trees 2022-10-14 21:40:23 i live in a modern country 2022-10-14 21:41:51 psykose: https://link.springer.com/article/10.1007/s10570-019-02882-3 2022-10-14 21:41:52 Maybe? 2022-10-14 21:42:26 it needs love 2022-10-14 21:42:36 talk to it nicely and put your router in the sun 2022-10-14 21:43:00 how about i put you out in the sun 2022-10-14 21:46:14 also lots of water 2022-10-14 21:46:47 directly onto the PCB 2022-10-14 21:48:42 want me to offline that bad huh ;) 2022-10-14 21:48:58 As long as it's conformally coated. 2022-10-14 21:49:42 psykose: Python 3.11 is coming out in like ten days. Are you the one managing the rebuild this time? 2022-10-14 21:49:53 probably not until after 3.17 2022-10-14 21:50:03 but yeah i can do all of it np 2022-10-14 21:50:06 Oh, right. Release freeze. 2022-10-14 21:50:20 it might be right before the freeze or whatever, but last-minute is not a great time 2022-10-14 21:50:22 psykose: only if you go sleep for me 2022-10-14 21:50:27 probably 90 broken packages 2022-10-14 21:50:53 conveniently though 3.11 adds the toml thing so the gpep517 bootstrap path is like 2 packages 2022-10-14 21:51:23 bl4ckb0ne: smh 2022-10-14 21:51:25 Oh, nice. Not sure how that got solved with the current bootstrap, but it didn't look fun. 2022-10-14 21:51:36 it was ok 2022-10-14 21:51:43 no circles so it's alright 2022-10-14 21:51:58 Circles are definitely bad (and way too prominent in Python). 2022-10-14 21:52:19 the circle i'd love to solve is harfbuzz->freetype->harfbuzz 2022-10-14 21:52:57 What would be your best guess for the release of 3.17? 2022-10-14 21:53:08 probably a mont 2022-10-14 21:53:09 h 2022-10-14 21:53:15 maybe a bit less 2022-10-14 21:53:15 depends 2022-10-14 21:53:31 i'll just fix whatever like always, but i'm not the one driving it 2022-10-14 21:53:41 Okay. I have plenty of time to work on patching python packages in December if we're willing to wait until then. 2022-10-14 21:53:49 And I have all the tooling from the 3.10 update. 2022-10-14 21:54:02 Release notes also don't look too crazy this time (couple deprecations slated for removal in 3.13). 2022-10-14 21:54:23 lemme glance 2022-10-14 21:54:50 Decent number of deprecated packages that I'm not sure how ubiquitous they are though. 2022-10-14 21:56:53 binhex is used in a few places 2022-10-14 21:56:54 not many 2022-10-14 21:57:20 asyncio decorator too, not many 2022-10-14 21:57:26 Should be easy enough to ignore the deprecation warnings if upstream hasn't patched it by then. 2022-10-14 21:57:28 eh 2022-10-14 21:57:32 probably same shit like last release 2022-10-14 21:57:35 yeah 2022-10-14 21:58:05 did you get any time for the cura thing 2022-10-14 21:58:10 that's been sitting there forever 2022-10-14 21:58:19 Not yet. I might have some time to work on it this weekend. 2022-10-14 21:58:20 i think it didn't even need any of the weird conan stuff when i looked at it 2022-10-14 21:58:27 but it's been a while 2022-10-14 21:58:50 Yeah. I need to look at it again. 2022-10-14 21:59:03 The current MR that's sitting there just patches the CMakeFile to the old version which I'd like to avoid. 2022-10-14 21:59:12 all the qt6 stuff should be fine, not sure if it needed the pyside6 to match 2022-10-14 21:59:20 if so i have to fix that for 6.4 but that's about it 2022-10-14 21:59:44 I remember it needing the qt patched version of pyside6 or something like that. 2022-10-14 22:00:17 I'll look into it over the weekend. 2022-10-14 22:01:27 sure thing :) 2022-10-14 22:02:51 They have a USE_SYSTEM_LIBS flag in the CMake file, but of course it doesn't look like it does anything. 2022-10-14 22:04:02 which package specifically 2022-10-14 22:04:20 That's for CuraEngine. 2022-10-14 22:06:01 hmm 2022-10-14 22:06:08 it's probably in some other repo of cmake garbage 2022-10-14 22:06:15 but even the top-level thing is just regular find_package 2022-10-14 22:08:57 Huh. It seems like they might've changed that recently. Doesn't seem like it'll be as hard to patch as I thought it would be. 2022-10-14 22:10:15 they did i think yeah 2022-10-14 22:10:28 also looks like 5.2 will be soon 2022-10-15 04:16:25 hello everybody! 2022-10-15 09:31:04 hello! 2022-10-15 09:31:51 @omni how're you? 2022-10-15 09:32:46 @omni i've question: is this true that user with nick copy is copy.sh/v86 site developer? 2022-10-15 09:35:26 how would I know, did you ask copy? 2022-10-15 09:35:54 @emni is copy there? 2022-10-15 09:36:09 @copy you're here? 2022-10-15 09:37:01 They probably turned off name highlighting with a name like that 2022-10-15 09:37:25 who they? 2022-10-15 09:37:39 copy: hi! 2022-10-15 09:39:01 LinuxUserHaiku: send a private message instead, /msg copy hi! 2022-10-15 09:39:12 ok 2022-10-15 09:39:27 i can double-click on copy user 2022-10-15 11:15:49 psykose: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/168 2022-10-15 12:49:02 ddevault: We're migrating our infra off of nld3 to a new host (also lxc based). Is there anything we need to take care off, or can we just copy the container and repoint the dns records? 2022-10-15 13:36:05 I guess dlmopen is not available on musl? 2022-10-15 13:47:43 Nvmd. 2022-10-15 17:19:31 PureTryOut: do you know where one could find notes from this "BoF at Akademy"? https://mail.kde.org/pipermail/distributions/2022-October/001307.html 2022-10-15 17:19:58 I've only found it mentioned here https://web.archive.org/web/20221003094530/https://community.kde.org/Akademy/2022/AllBoF 2022-10-15 17:28:35 I mean, that specific one about the KDE Qt Patch Collection 2022-10-15 17:49:08 I wonder if the present distro people knew that you're not allowed to fetch commit tarballs when they thought the current status was "not too bad" 2022-10-15 18:00:20 I do not know sorry. If I were there (I was at the event but at the time of the bof I was back home) I would be one of the people that didn't know 💁 2022-10-15 21:03:21 ikke: should be fine but if you send me an email with the details I'll look over everything post migration 2022-10-15 21:03:36 ddevault: sure, will do 2022-10-15 21:04:01 ddevault: one thing I noticed when syncing is that there are some logs that don't appear to have been rotated and grew relatively large 2022-10-15 21:04:14 ACTION shrugs 2022-10-15 21:04:14 ¯\_(ツ)_/¯ 2022-10-15 21:04:19 trim them when the disk gets full 2022-10-15 21:04:55 I'd rather not have logs filling up my disks 2022-10-15 21:05:01 ACTION shrugs 2022-10-15 21:05:01 ¯\_(ツ)_/¯ 2022-10-15 21:05:04 set up logrotate then 2022-10-15 21:06:52 ever heard of that old sysadmin trick wherein you deliberately leave some large files lying around so you can rm them on ENOSPC to free up some space to work the problem with 2022-10-15 21:08:54 Yes, I've heard of it 2022-10-15 21:14:29 (not suggesting it here, just an anecdote) 2022-10-15 22:38:54 then you'd cross your fingers that the OMM killer won't shoot down your attempts at removing the file 2022-10-15 23:42:29 ENOSPC is not ENOMEM 2022-10-16 00:02:38 i have this great trick for not filling up disk with logs... :) 2022-10-16 00:04:41 of course not (unless you can set up something like that with a ram disk) just that a problem usually bring a friend or two 2022-10-16 00:08:20 monitoring with alerts is a pretty good trick 2022-10-17 06:34:19 morning! omni: thank you for updating the kernels 2022-10-17 15:30:04 ikke: armhf builder is stuck 2022-10-17 16:05:39 days since a builder has been stuck: 0 2022-10-17 16:49:29 i've been made aware that certain container scanners are "helpfully" scanning go binaries we ship for vulnerabilities using the embedded dependency data in the binary, thusly i plan to write a tool to strip that information 2022-10-17 16:51:25 wouldn't they be right 2022-10-17 16:56:19 in most cases, it just results in more noise to deal with 2022-10-17 17:11:25 for example, if you scan our community/go package with snyk, at the moment, it complains loudly because there is a package.json deep inside the package for a web profiling tool, which contains a vulnerable version of d3.js 2022-10-17 17:13:16 that's a file in the go package not embedded data in a go binary 2022-10-17 17:13:19 but yes, sounds useless 2022-10-17 17:14:37 unless it's also in the go binary itself as metadata given it's in a vendor directory.. that sounds like a lot of data to keep in a binary though 2022-10-17 17:15:32 maybe I'm misunderstanding you, but isn't everythign ending up in the go binary? 2022-10-17 17:16:43 i would imagine that random package.json doesn't 2022-10-17 17:17:05 depends if someone was crazy enough to embed it 2022-10-17 17:17:23 embed(./node_modules) 2022-10-17 17:17:41 🥲 2022-10-17 17:27:46 ikke: the issue is that certain scanners default to scanning everything deeply, even if it is a distro-provided binary 2022-10-17 18:40:37 I told the the person who impersonated me on telegram that I was uncomfortable with it, and he/she has now handed over the account to me. 2022-10-17 18:41:04 I also now control the @AlpineLinux channel on telegram 2022-10-17 18:42:16 delete it 2022-10-17 18:42:19 victory 2022-10-17 18:42:42 if I delete it someone else can grab it 2022-10-17 18:44:08 If possible, maybe direct to the official spaces 2022-10-17 18:44:25 don't know how to do that or if it is possible 2022-10-17 18:45:06 in any case, im relatively happy. I guess I can just mute it and forget about it 2022-10-17 18:45:06 you can probably prevent anyone from posting anything in the channel 2022-10-17 18:45:20 not actually a good idea probably but shrug 2022-10-17 18:54:15 ncopa: you can post message that alpine doesn't retain any official place on telegram other than that channel and link them to irc 2022-10-17 18:55:01 yeah I should 2022-10-17 18:55:37 ncopa: it's actually you? 2022-10-17 18:55:48 it is 2022-10-17 18:56:00 thanks, sorry about my attitude 2022-10-17 18:56:10 no worries. I understand 2022-10-17 18:56:27 what attitude was it 2022-10-17 18:56:28 and to be honest, this business has been pretty annoying for me too 2022-10-17 18:56:36 👁️ 2022-10-17 18:56:52 I said its the real ncopa and he was "yeah right..." 2022-10-17 18:57:00 which is kinda understanding :) 2022-10-17 18:57:03 i think it is the fake ncopa 2022-10-17 18:57:07 just like the ncopa in here right now 2022-10-17 18:57:13 send me $100,000,000 to prove otherwise 2022-10-17 18:57:17 ;) 2022-10-17 18:57:36 yeah right, because only the real ncopa would have that 2022-10-17 18:58:17 ncopa: you should be unbanned now 2022-10-17 18:58:37 xD 2022-10-17 18:58:58 Thanks 2022-10-17 18:59:42 https://usercontent.irccloud-cdn.com/file/ciq1GlKP/wonderful 2022-10-17 19:25:54 ncopa: np, but I didn't do it for 3.14 or 3.13 2022-10-18 09:14:03 hum 2022-10-18 09:14:10 i think we have a problem with gitea 2022-10-18 09:14:20 it modifies authorized_keys 2022-10-18 09:14:20 what kind 2022-10-18 09:14:30 hm 2022-10-18 09:14:31 in where 2022-10-18 09:14:46 in $HOME/.ssh/authorized_keys 2022-10-18 09:14:57 at startup? that would be normal 2022-10-18 09:15:04 i don't see the package doing anything special 2022-10-18 09:15:09 well, "normal" 2022-10-18 09:15:13 that's what they want to do so they do it 2022-10-18 09:15:17 # gitea public key 2022-10-18 09:15:17 command="/tmp/go-build2796933656/b855/models.test --config=/tmp/go-build2796933656/b855/custom/conf/app.ini serv key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDWVj0fQ5N8wNc0LVNA41wDLYJ89ZIbejrPfg/avyj3u/ZohAKsQclxG4Ju0VirduBFF9EOiuxoiFBRr3xRpqzpsZtnMPkWVWb+akZwBFAx8p+jKdy4QXR/SZqbVobrGw 2022-10-18 09:15:17 ip2UjSrri1CtBxpJikojRIZfCnDaMOyd9Jp6KkujvniFzUWdLmCPxUE9zhTaPu0JsEP7MW0m6yx7ZUhHyfss+NtqmFTaDO+QlMR7L2QkDliN2Jl3Xa3PhuWnKJfWhdAq1Cw4oraKUOmIgXLkuiuxVQ6mD3AiFupkmfqdHq6h+uHHmyQqv3gU+/sD8GbGAhf6ftqhTsXjnv1Aj4R8NoDf9BS6KRkzkeun5UisSzgtfQzjOMEiJtmrep2ZQrMGahrXa+q4VKr0aKJfm+KlLfwm/JztfsBcqQWNcTURiCFqz+fgZw0Ey/de0eyMzldYTdXXNRYCKjs9bvBK+6SSXRM7AhftfQ0Zuo 2022-10-18 09:15:17 W5+gtinPrnmoOaSCEJbAiEiTO/BzOHgowiM= user2@localhost 2022-10-18 09:15:31 looks like it is the testsuite that does it 2022-10-18 09:16:12 ah, probably the integration one 2022-10-18 09:16:37 the builders has those keys in their authorized_keys 2022-10-18 09:16:50 i think we may need to write protect authorized_keys 2022-10-18 09:17:34 there are also a bunch of 2022-10-18 09:17:35 buildozer/.ssh/authorized_keys_1588666484.gitea_bak 2022-10-18 09:17:35 buildozer/.ssh/authorized_keys_1588666490.gitea_bak 2022-10-18 09:18:05 not fantastic 2022-10-18 09:18:19 but that's just one of a list of maybe 300 things that are left over without some rootbld-like sandboxing 2022-10-18 09:18:29 which would solve all the issues at once 2022-10-18 09:18:51 yeah 2022-10-18 09:19:20 if we fixed that localrepo repositories rootbld issue, and the pkgusers/pkggroups one (root doesn't have the users made?), and maybe 1-2 other outstanding ones, it would be very usable 2022-10-18 09:19:20 im thinking of sandboxing with crun 2022-10-18 09:19:28 then i wouldn't mind just adding net where needed or whatever 2022-10-18 09:19:36 a bunch of tests would need fixing but i mean, we have to do it at some point 2022-10-18 09:19:43 yeah 2022-10-18 09:19:59 crun also works i guess, just a different format 2022-10-18 09:20:13 yup. its standard OCI format 2022-10-18 09:20:17 which is a standard 2022-10-18 09:20:51 that would be ok, but i would suggest sitting down and actually thinking about it some-time-not-now-after-release 2022-10-18 09:21:01 otherwise it's just going to be the 3rd rootbld implementation (after dabuild too) 2022-10-18 09:21:07 yup 2022-10-18 09:21:17 crun is a very nice tool in my experience 2022-10-18 09:21:46 not as light as just the bwrap sandbox, but light enough for "a build" with a lot of standard stuff 2022-10-18 09:21:55 not exactly running 500 of them 2022-10-18 09:22:35 im just thinking that using an established standard tool (crun or runc) may give us some benefits 2022-10-18 09:22:43 may be tooling we can use 2022-10-18 09:22:57 it would allow a much lighter implementation of dabuild without needing a running docker 2022-10-18 09:23:23 but there's still a lot of stuff to figure out like how to put the local repos into the image 2022-10-18 09:24:08 yeah. it will require some work 2022-10-18 09:24:08 psykose: what is the pkguser/pkggroup problem? 2022-10-18 09:24:25 user accounts are created in build environment 2022-10-18 09:24:33 yeah, I did it 2022-10-18 09:24:48 uhm do you mean inside the chroot? 2022-10-18 09:24:51 or in the "host"? 2022-10-18 09:24:59 on the host 2022-10-18 09:25:02 I fixed it 2022-10-18 09:25:05 is not merged ? 2022-10-18 09:25:12 unless you run in rootbld 2022-10-18 09:25:53 https://gitlab.alpinelinux.org/donoban/abuild/-/commit/84d7b7693d44a95d4aba4ea44bd768e2512d92cb 2022-10-18 09:25:55 is this ok? 2022-10-18 09:31:52 recently I need to add my local go version on rootbld, I think that it could be easily patched to use local repositories 2022-10-18 09:36:06 it already does but only from the same repo 2022-10-18 09:37:03 we are talking about when not running in rootbld or any container 2022-10-18 09:37:26 ah, sorry 2022-10-18 09:37:53 which currently is problematic 2022-10-18 09:37:55 so do you want to not create new users/groups when plain abuild? 2022-10-18 09:43:47 well, we should build each package in its own container 2022-10-18 09:44:03 we currently don't and that is the problem 2022-10-18 10:10:34 would be 'overkiller' some neutral "container layer" which could easily change the container tecnhology? 'abuild --container=[docker|runc|rootbld|...]' 2022-10-18 10:27:59 im thinking something like 'abuild --oci-runtime=crun|runc|...' 2022-10-18 10:29:00 i think there is an oci wrapper for bubblewrap 2022-10-18 10:32:41 and this is the reason why i'd like to use oci runtime, because then it would be relatively easy to replace the container tech 2022-10-18 10:34:03 could even use a microvm 2022-10-18 10:36:22 it sounds great 2022-10-18 10:48:20 psykose: you're too fast, i was about to update pixman when i saw you did it an hour ago 2022-10-18 10:49:14 xD 2022-10-18 10:49:20 bl4ckb0ne: I feel you ;( 2022-10-18 10:49:22 if you look at the commit theres a failing hash test 2022-10-18 10:49:25 uhh gotta go 2022-10-18 10:49:26 plane 2022-10-18 10:49:28 see ya in 6 hours 2022-10-18 10:49:43 whos gonna merge my commits 2022-10-18 11:01:01 Trying to upgrade 3.13 pkg, how can I solve this ci problem https://gitlab.alpinelinux.org/wener/aports/-/jobs/876764 2022-10-18 11:01:12 libcrypto1.1-1.1.1q-r0: trying to overwrite etc/ssl1.1/cert.pem owned by ca-certificates-bundle-20220614-r2 2022-10-18 11:01:29 There is another one https://gitlab.alpinelinux.org/wener/aports/-/jobs/876763 2022-10-18 11:05:04 after rebase, 3.13 works now, 3.15 still failed 2022-10-18 13:47:52 Any clue why zswap's z3fold module is only enabled in certain kernels? https://gitlab.alpinelinux.org/search?search=z3fold&nav_source=navbar&project_id=1&group_id=2&search_code=true&repository_ref=master notably it seems to be missing from lts, x86_64 2022-10-18 14:31:38 question for MR !40350, is it okay to disable previously enabled pro features? I'm okay with the proposed change, would to make sure this won't cause problems from alpine package policy perpective. thanks! 2022-10-18 14:31:58 s/would to/would like to/ 2022-10-18 14:31:58 mio meant to say: question for MR !40350, is it okay to disable previously enabled pro features? I'm okay with the proposed change, would like to make sure this won't cause problems from alpine package policy perpective. thanks! 2022-10-18 15:34:34 Is there any chance for backporting the same rsync upstream patches like Debian did (see https://github.com/WayneD/rsync/issues/356#issuecomment-1254159023) also to the Alpine rsync package in Edge and 3.16? This would fix rpki-client usage :) 2022-10-18 16:55:53 what is the procedure I should follow wrt CVEs in software I package? e.g. https://github.com/Nheko-Reborn/nheko/security/advisories/GHSA-8jcp-8jq4-5mm7 2022-10-18 17:20:21 Sheila: There is not an elaborate procedure. You upgrade the packages to a version with the fix (within the stable version), or patch it. If there is a CVE, you can add it to a secfixes section in the APKBUILD 2022-10-18 17:22:03 Okay. We’re already at the fixed version, but I figured I’d ask due to previous major Alpine releases including affected versions. 2022-10-18 17:23:54 nheko is in community, so you should backport it to 3.16 2022-10-18 17:24:11 Okay, will do. 2022-10-18 17:24:45 3.16 has 0.9.3, upgrading to 0.10.x should be done with care 2022-10-19 08:40:34 god, fuck python 2022-10-19 08:40:47 anyone dealt with pdm-based packages yet? 2022-10-19 08:49:51 I need python out of my stack ASAP 2022-10-19 09:18:14 They reinvented the wheel again? 2022-10-19 09:34:46 again, and again, and again, and again, and again 2022-10-19 09:36:38 how's that different from 95% of computer tech 2022-10-19 09:37:24 python is an extreme example 2022-10-19 09:37:30 it's much worse than any other community I care to think of 2022-10-19 09:38:01 in the past 2 or 3 years they've invented at least 15 new, stupid build systems and package managers, each incompatible with the others and non-backwards-compatible with anything 2022-10-19 09:40:11 https://www.jwz.org/doc/cadt.html is from 2003 2022-10-19 09:40:36 it's been 20 years and nothing has changed 2022-10-19 09:40:57 (admittedly I'm not helping because I, too, like to rewrite the world) 2022-10-19 09:41:14 I would expect a programming language to have strong enough upstream leadership to dictate norms and conventions for important core matters like build systems 2022-10-19 09:41:30 python takes a HORRIBLE approach of actively encouraging their community to build a billion broken ways of doing core things 2022-10-19 09:41:50 worst leadership approach even theoretically possible 2022-10-19 09:42:01 worse than absenteeism 2022-10-19 09:42:34 if they actively encourage it then indeed it's bad 2022-10-19 09:44:51 How do they actively encourage it? 2022-10-19 09:45:03 https://www.infoworld.com/article/3654196/pdm-a-smarter-way-to-manage-python-packages.html 2022-10-19 09:45:09 they have been pressed to deal with these problems 2022-10-19 09:45:17 and their official response is "let the community sort it out by building a package management zoo" 2022-10-19 09:45:48 it semes that they also reinvented git and branchs 2022-10-19 09:51:47 Has anyone dealt with the problem of adding 2 routes/addresses to the same interface/table and one of them failing due to the locking? 2022-10-19 09:51:51 ddevault: what problem are you having with this? it seems more likely a dev env for developers than a build/package system 2022-10-19 09:52:05 I fixed it by just excising all of the pdm-related crap from the pyproject.toml 2022-10-19 09:52:40 how about /py3-: drop 2022-10-19 09:52:48 someday... someday 2022-10-19 09:53:02 we started making a more concrete plan for getting rid of all of our python stuff 2022-10-19 09:53:11 who are "we" in this context? 2022-10-19 09:53:14 sourcehut 2022-10-19 09:53:22 I am trying to initialise a interface with ip addr/ip route and those run async, so they seem to randomly hit a condition where both actions happen at the same time and one fails because the other stuff is running, it's way more obvious on machines with many cpus rather than one 2022-10-19 09:54:36 I am not aware of any way to tell iproute2 to wait until it may execute the addition/removal rather than failing fast 2022-10-19 09:57:46 caskd: can't you rely on /etc/network.. ifup/down... 2022-10-19 09:57:48 ? 2022-10-19 09:58:28 that's kinda irrelevant but for my case i do not have ifupdown(-ng) 2022-10-19 09:58:33 so no 2022-10-19 09:59:26 i guess i could rely on some kind of file-based mutex 2022-10-19 09:59:37 but ideally i don't at all 2022-10-19 10:00:10 so i thought you might know more, this has been puzzling me for the past 24h 2022-10-19 10:04:57 uhM, so you launch them from different places? 2022-10-19 10:05:09 yeah 2022-10-19 10:05:16 caskd: if iproute2 doesn't have synchronization options then there's no other option than locking around the calls 2022-10-19 10:05:28 maybe you could create a fifo on /tmp/.. 2022-10-19 10:05:30 but it's a matter of a 2-line script 2022-10-19 10:05:37 one writes and the other reads 2022-10-19 10:05:44 the reader will wait until someone writes 2022-10-19 10:06:00 donoban: don't overengineer this :P 2022-10-19 10:06:23 skarnet: for reference, i am actually having the addtions as s6-rc services 2022-10-19 10:06:27 hehe 2022-10-19 10:06:29 don't ask why 2022-10-19 10:06:52 but how would that be 2 lines? 2022-10-19 10:07:23 caskd: since you're using s6, one line. :P Replace "ip" with "s6-setlock /tmp/ip.lock ip" 2022-10-19 10:07:43 oh wew 2022-10-19 10:07:49 great 2022-10-19 10:07:52 will try 2022-10-19 10:09:02 that's not perfect because it will also lock reading operations and nonprivileged operations 2022-10-19 10:09:18 ideally you'd take locks of various granularity depending on what you want to do 2022-10-19 10:09:28 but the ip command should really do it itself :/ 2022-10-19 10:09:31 skarnet: there will be next to no reading so it's fine 2022-10-19 10:09:53 i agree on ip doing that itself, i didn't even know the locking would fail if there would be any 2022-10-19 10:10:08 but i just noticed sometimes my v6 routes/addresses would just not appear 2022-10-19 10:10:10 or even v4 2022-10-19 10:10:22 depeding on which was first 2022-10-19 10:10:28 it was really fkd 2022-10-19 10:10:49 i'd rather have it do locking with optional timeout + fast fail 2022-10-19 11:24:17 i'd like to increase job timeout for a runner because i lack a couple of minutes for tests to finish on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/40391 2022-10-19 11:24:49 where should i set it? or do i even have permission to do that? 2022-10-19 11:27:51 https://gitlab.alpinelinux.org/grikir02/aports/-/settings/ci_cd 2022-10-19 11:28:52 There's Timeout field in General Pipelines section. 2022-10-19 11:29:05 It may help 2022-10-19 11:29:49 ty, i see it 2022-10-19 11:40:38 oh no, guess what 2022-10-19 11:40:45 I give up 2022-10-19 11:40:49 even locking the call still results in it failing 2022-10-19 11:40:56 sometimes 2022-10-19 11:54:42 ah nvm, it was colliding with another call 2022-10-19 11:58:07 grisha: you can also add like a -j4 to the ctest 2022-10-19 11:58:13 looks like the kind of testsuite that wont crash on it 2022-10-19 11:58:19 and the usual -G Ninja 2022-10-19 12:00:24 psykose: vfma.f32 would be a NEON instruction, right? 2022-10-19 12:03:40 ye 2022-10-19 12:03:45 Is it formalised somewhere that we don't allow NEON on armv7? 2022-10-19 12:03:49 in Alpine 2022-10-19 12:04:38 i asked once and got no response 2022-10-19 12:04:45 gcc doesn't have it so i assume no 2022-10-19 12:05:22 in reality it's inconsistent and i'd guess half the things that do anything mathematical add -mfpu=whatever on armv7 2022-10-19 12:05:44 would be great if we could formalise that NEON needs to be checked for at runtime on armv7 2022-10-19 12:05:48 or disabled 2022-10-19 12:06:27 ok. i have hereby formalised it 2022-10-19 12:06:31 no autochecks from me though 2022-10-19 12:06:33 🤔 2022-10-19 12:06:44 I mean, did you write it down somewhere? 2022-10-19 12:06:51 yeah right now right here 2022-10-19 12:07:10 thanks that will make a great reference in the future 2022-10-19 12:08:10 but on a more serious note, are these things written down somewhere for other architectures? 2022-10-19 12:16:29 would this be something for the TSC to look into? 2022-10-19 12:18:48 i wouldn't know sadly 2022-10-19 12:20:37 Hopefully someone else does 2022-10-19 13:46:44 psykose: okay, samuraified it. isn't there a variable for cpus count to specify instead of 4 in -j4? 2022-10-19 13:46:58 that usually just breaks most of the time ime 2022-10-19 13:48:09 okay, no -j then) 2022-10-19 13:49:33 -j4 would probably be fine 2022-10-19 14:50:24 Hmm I have a Rust package that after finishing building the install function fails with `File '' could not be found`, what could it mean and is there any obvious way to resolve it? 2022-10-19 16:24:35 https://pkgs.alpinelinux.org/contents?branch=edge&name=py3-fiona&arch=aarch64&repo=community conflicts https://pkgs.alpinelinux.org/contents?branch=edge&name=fio&arch=aarch64&repo=community 2022-10-19 17:42:46 it means something has a dt_needed on a .so that is not in the rpath of the executable 2022-10-19 20:39:16 hmm, a (sub)package can only have one replaces, right? 2022-10-19 20:45:14 nope 2022-10-19 20:45:23 replaces is an array 2022-10-19 20:47:05 right, it appears so: https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/apk_adb.c#L402 2022-10-20 04:46:33 psykose: ok so is there something I can do about it? 2022-10-20 11:00:43 well either you have to add an rpath somewhere or move some files around or ignore it 2022-10-20 11:00:47 i have no idea 2022-10-20 15:08:26 so msg.a.o is broken for now 2022-10-20 15:08:57 we locked it up a bit so not everyone can publish anything there 2022-10-20 15:09:03 but we need to fix a few things 2022-10-20 15:09:20 and its kinda hard to test 2022-10-20 15:09:33 and edge builders are busy 2022-10-20 15:09:40 and tomorrow I 2022-10-20 15:09:51 tomorrow I'm out for a half day 2022-10-20 15:10:12 so I guess we need to be patient 2022-10-20 15:10:33 evertying came at same time 2022-10-20 15:10:55 build 3.17, ppc64le machines and now msg grafitti 2022-10-20 15:11:02 build.a.o grafitti 2022-10-20 15:11:13 yup 2022-10-20 15:11:18 and I'm mostly out tomorrow as well 2022-10-20 15:12:16 and apparently this build.a.o "vulnerability" is sooooooooo important for this uber hacker that we need to drop everything in our hands and deal with it 2022-10-20 16:08:16 what is msg.a.o? 2022-10-20 16:09:33 our mqtt endpoint 2022-10-20 16:09:55 it's what triggers the builders, shows build status messages and more 2022-10-20 16:10:14 ouch 2022-10-20 16:11:43 It's mostly just anoying 2022-10-20 17:19:27 build.a.o vulnerability? :D 2022-10-20 19:50:57 haxx0rs gonna hax4te 2022-10-20 19:57:35 They apparently also tried all kinds of injections 2022-10-20 23:10:33 i'm surprised they didn't realize they could get algitbot to flood irc 2022-10-20 23:41:23 funnily that's probably the most impactful thing possible 2022-10-21 10:41:07 is there some issie with libicui18n? 2022-10-21 10:41:13 cant install a browser 2022-10-21 11:03:37 just a bunch of pending rebuilds 2022-10-21 11:03:49 now happily blocked on dotnet failing to build like any time the wind blows 2022-10-21 11:04:28 neat 2022-10-21 11:05:14 ill live in the tty for a bit longer then 2022-10-21 11:05:44 ive tried qutebrowser, chromium and firefox and they all depends on this 2022-10-21 11:10:45 yeah everything does 2022-10-21 13:18:56 When icu gets updated it's best to stay away from updates for at least a day 2022-10-21 13:19:59 im setting up a new alpine install 2022-10-21 13:22:28 Oh mb 2022-10-21 13:59:17 hello, short question. i am trying to build a package which requires /usr/bin/gencat from glibc. is there a way to go around this? i believe other software also uses gencat in the build process... 2022-10-21 14:34:02 ugh.. mosquitto sigpipe thingy 2022-10-21 14:34:36 we didn't backport the fix to stable branches to mosquitto, right? 2022-10-21 16:21:47 ok. i think everythign is ok now and i have started with bootstrapping 3.17 ppc64le 2022-10-21 18:27:48 whats the rule for moving a package that doesnt belong to me to community? 2022-10-21 18:56:32 bl4ckb0ne: ask the package maintainer? 2022-10-21 18:56:58 makes sense ty 2022-10-21 19:49:14 i wonder if there's a way to quickly see which mrs are holding up the ci workers without checking each individual mr 2022-10-21 19:49:46 not sure if https://gitlab.alpinelinux.org/alpine/aports/-/pipelines includes all pipelines 2022-10-21 20:36:44 knuxify: probably not. It would only show pipelines created by developers 2022-10-22 10:52:42 ikke: in usual fashion, 3.16-aarch64 is stuck on openjdk11 2022-10-22 10:56:23 kicked it 2022-10-22 11:13:57 I'm wondering whether stall detection would be automatable 2022-10-22 11:20:11 Checking if it's still writing to the log 2022-10-23 02:07:48 who do I need to talk to about how I've been getting 'package out of date' notifications for a package the same day as upstream releases a version? I don't mind getting pinged, but within 24 hours is a bit excessive. 2022-10-23 04:39:22 Had someone flag a package of mine a week before a new upstream release was out - didn't quite know where to go to unflag. 2022-10-23 09:47:15 and it's not the automatic package flagging by anitya/release-monitoring.org? 2022-10-23 14:37:28 for me it is. 2022-10-23 14:48:24 the automated one runs at like 1am utc daily with whatever is latest on release-monitoring 2022-10-23 14:49:14 you can nullroute pkgs@alpinelinux.org 2022-10-23 14:49:17 not much aside from that 2022-10-23 14:50:04 gettings email for prereleases is nice 2022-10-23 14:50:27 there was an attempt to filter that doesn't work, funnily 2022-10-23 15:03:50 would alpine be interested in carrying a patch to make use of strdupa a warning via some hack in order to evaluate how much work getting all the strdupa in the wild would be? 2022-10-23 15:07:15 that would require reading every build log to see that specific warning in the first place 2022-10-23 15:07:25 most builds have 90 million other warnings and so don't get read to begin with 2022-10-23 15:07:49 ok that's the kind of answer that's helpful. not the one i wanted to hear, but :-p 2022-10-23 15:08:35 according to nsz there are only 126 packages in debian code search using it, so probably working from that makes more sense 2022-10-23 15:08:40 regarding the ML discussion, it really depends on which of those 126 codesearch packages are even in alpine 2022-10-23 15:09:04 but he is right in that the failures would most likely be fixed by adding in the #define as a patch into whatever fails, and having it as a todo later 2022-10-23 15:09:33 *nod* 2022-10-23 15:09:38 the most proactive thing i can think of is going through that 126 list by hand outside of any packaging and just contributing things upstream ahead of time 2022-10-23 15:09:42 but that would take a while 2022-10-23 15:09:49 wouldn't be surprised if half of them would refuse to take it for some reason too 2022-10-23 15:13:46 :-p 2022-10-23 15:14:12 is strdupa universally available on non-glibc systems otherwise? (bsds, apple, etc?) 2022-10-23 15:14:51 it's not on macos, I just checked. 2022-10-23 15:15:16 weirdly, 'man strdupa' was already in my history so I must have looked a while ago too. 2022-10-23 15:32:56 sheila, ok, that's good to hear. it means only non-portable software can possibly be assuming its existence 2022-10-23 16:38:02 dalias: I'll add that it's not on FreeBSD either. 2022-10-23 16:39:09 :) 2022-10-23 16:40:11 in that case i would expect that all but a very minor number of packages that are "linux-only" (think stuff like util-linux, iproute2, etc -- not saying those do it tho, just that type of thing) already have configure checks 2022-10-23 16:40:26 and provide their own macro or (this would be ideal!) don't use it and malloc instead if it's not available 2022-10-23 16:40:53 that's what I would expect, yeah. 2022-10-23 16:41:14 so in that case, removing it might be completely nbd 2022-10-23 16:42:26 PureTryOut: if you put sources in dev.a.o archive, could you at least not make it writable only by you 2022-10-23 16:43:30 (so that anyone else can also put things in the same folder) 2022-10-23 16:43:45 your tarballs are also generated with all the .git data still in them 2022-10-23 16:44:02 you should use git archive or add --exclude-vcs to tar 2022-10-23 16:46:25 also you changed the checksums of all of those but the tarballs are still named the same so they will fail on rebuild because of cache 2022-10-23 16:47:47 I'm... Not doing that on purpose lol 2022-10-23 16:48:11 I don't think psykose thought you were, just wanted to make sure you were aware so you could fix it. :) 2022-10-23 16:48:16 I'm just using the rsync command as in the snapshot function. Any other way to do that? 2022-10-23 16:49:54 for the permissions.. not sure if you won't have to manually g+w the first time only, unless --chmod=775 works, but that probably makes the tarball itself 775 too 2022-10-23 16:50:01 it is only once though 2022-10-23 16:51:01 hmm ok something to take notice of then. Fixed it this one instance at least 2022-10-23 16:51:27 yeah it's just a tiny annoyance, haha 2022-10-23 16:51:30 as for the cache yeah I know. Not sure how to resolve that properly as I don't really want to rename the files 2022-10-23 16:51:38 as for tar just --exclude-vcs will remove the .git 2022-10-23 16:52:05 Hmm tried that just now, it seems to ignore the argument or something 2022-10-23 16:52:55 fwiw it only exists in gnu tar, not bb 2022-10-23 16:53:01 ah ofc, because it's not in busybox tar 2022-10-23 16:53:05 yeah just realized that lol 2022-10-23 16:53:15 I'll just do a `rm -r .git` first 2022-10-23 16:53:27 `git archive` isn't doable? 2022-10-23 16:53:47 I suppose it is, haven't used it before though 2022-10-23 17:05:05 https://img.ayaya.dev/nvLNKIyi08YK one example 2022-10-23 17:06:04 this does need xz installed, if you keep it gzip it would be the same as before in requirements 2022-10-23 17:07:06 the --prefix also correctly makes it match the default builddir 2022-10-23 17:07:48 default as in the one already there 2022-10-23 17:09:46 as for "why is it xz", the tarball goes from 65 to 46 mb for qtbase 2022-10-23 17:10:59 you can specify a custom command for `git archive`, incidentally, if you want to, say, have tar handle the compression part too. 2022-10-23 17:11:06 yep 2022-10-23 17:35:26 looking at it i think without specifying it defaults to gzip -6 which is far from ideal 2022-10-23 17:46:11 yeah. unfortunately the way to configure it is `git config tar.targz.command` which is also not ideal; it would be helpful if one could specify a command directly in `git archive`. 2022-10-23 17:46:26 PureTryOut: good work, by the way :) looks like that should clear up the issue they wanted 2022-10-23 17:47:07 Sheila: you can add `-9` to git-archive with the targz format and that works, i think 2022-10-23 17:47:36 yeah, but that's the only tuning you get. 2022-10-23 17:48:05 also that's specific to the zip format. 🙃 2022-10-23 17:48:53 psykose: yeah will do more packages when I touch them or see them being touched by others 2022-10-23 17:49:15 Sheila: I just pipe git-archive into xz now, works fine 2022-10-23 17:49:32 or the tar format 2022-10-23 17:49:32 yeah, fair enough. 2022-10-23 17:49:58 but yes, annoyingly there isn't a --use-compress-program like gtar 2022-10-23 17:50:22 ACTION changes all his packages that upload stuff to dev.a.o to use xz compression now 2022-10-23 17:50:27 hah 2022-10-23 17:50:54 check first the size of them, if the archive is huge -T0 -9 is a little suicidal 2022-10-23 17:50:58 also fixing those folder permissions while I'm at it 2022-10-23 17:51:18 it's around ~1.6GB per thread of memory use, which isn't actually hit when the size is small anyway 2022-10-23 17:51:21 biggest archive is 800+MB 2022-10-23 17:51:54 but for e.g. the electron snapshot (2.2G out, 12+ tar?) it's fully utilised 2022-10-23 17:52:02 lol Electron 2022-10-23 17:52:04 and also takes like 20 minutes with 48 threads 2022-10-23 17:52:07 that framework remains a joke to me 2022-10-23 17:52:12 damn 2022-10-23 17:52:35 I suppose it would reduce size a lot if it could use the system chromium somehow 2022-10-23 17:53:11 can't really as it's basically just a very big chromium patchset 2022-10-23 17:53:26 and then some more code on top of it 2022-10-23 17:55:44 ah damn it git-archive doesn't do submodules 2022-10-23 17:56:11 yeah at that point you want gnu tar and --exclude-vcs 2022-10-23 17:56:47 hm actually never looked up if there's a way around it 2022-10-23 17:57:15 nope, usual set of workarounds 2022-10-23 17:57:22 so the ole tar with exclude is the easiest 2022-10-23 17:57:43 yeah... to bad 2022-10-23 18:14:07 hmm seems `--exclude-vcs` makes it also ignore submodules, wtf 2022-10-23 18:14:51 xz will be gaining parallel decompression shortly too 2022-10-23 18:16:35 will they add the slabbing by default into the compression or will it have to be manual 2022-10-23 18:16:51 PureTryOut: ah, hmm.. 2022-10-23 18:16:56 right, didn't consider that 2022-10-23 18:17:02 i guess we have to look for one of the 50 other ways 2022-10-23 18:17:15 find(1) -delete .git :V 2022-10-23 18:17:53 :p 2022-10-23 18:18:35 https://github.com/Kentzo/git-archive-all hmmm. 2022-10-23 18:19:24 …and somehow not already packaged. 2022-10-23 18:19:35 I'll just delete the folder yeah lol 2022-10-23 18:19:40 I have use git-archive-all before actually 2022-10-23 18:19:53 how useful was it? 2022-10-23 18:20:27 I will package it if it'd be useful to you. 2022-10-23 18:20:50 well it did the job at the time haha 2022-10-23 18:21:13 but in this case it would only be useful for me in the community repo 2022-10-23 18:23:56 fair. *is* there some minimal period of time a package needs to exist before it can be promoted? 2022-10-23 18:24:10 been meaning to promote apache-mod-md but haven't gotten around to it. 2022-10-23 18:24:37 nope 2022-10-23 18:26:37 Not really. If the maintainer considers it stable and ready that's good enough. As a maintainer you should be willing to support it for half a year with every new Alpine release though 2022-10-23 18:28:27 yeah. I've been around again for over a year and I don't expect to leave again. 2022-10-23 18:37:47 never know 2022-10-23 18:37:52 life catches you real hard sometimes 2022-10-23 18:37:52 true. 2022-10-23 18:38:07 please sign the following insurance policy to verify ... 2022-10-23 18:38:08 (/s) 2022-10-23 19:12:49 … whee. how in the fuck this actually passes tests for the dev I'll never know, because bare pytest doesn't run any tests and the tox workflow just errors out. 2022-10-23 19:19:18 just pytest on that test* file should run it 2022-10-23 19:19:21 then the actual errors no idea 2022-10-23 19:19:36 tox doesn't really do anything except wrap things in an env and add 5 minutes of waiting and download 20 deps 2022-10-23 19:21:48 yeah. problem is, there *is* no test* file. 2022-10-23 19:22:15 there's test_git_archive_all.py, and it looks like it uses pytest 2022-10-23 19:22:32 that's not in the release tarball. 2022-10-23 19:22:38 CHANGES.rst MANIFEST.in README.rst git_archive_all.py* py.typed setup.py 2022-10-23 19:22:38 LICENSE.txt PKG-INFO git_archive_all.egg-info/ git_archive_all.pyi setup.cfg 2022-10-23 19:22:46 oh, the dev makes their own tarballs.. 2022-10-23 19:22:53 no, it's a pypi tarball 2022-10-23 19:22:57 with excluded tests 2022-10-23 19:23:01 right 2022-10-23 19:23:16 i never use them myself 2022-10-23 19:23:16 quality, let me switch to github's auto-generated ones. 2022-10-23 19:23:20 i'm pretty sure in that case it's best to just use the github tag tarballs 2022-10-23 19:23:39 how do i add a virtual package dep that's masked in @testing ? 2022-10-23 19:24:03 -t .xyz something@testing ? 2022-10-23 19:24:05 unless that doesn't work 2022-10-23 19:24:34 ERROR: 'libspnav-dev@testing' is not a valid child dependency, format is name([<>~=]version) 2022-10-23 19:24:37 ah 2022-10-23 19:25:20 i think that was indeed unimplemented 2022-10-23 19:25:27 i think i saw it in some issue but i can't find it now 2022-10-23 19:25:31 ahh, the virtual package needs to be masked 2022-10-23 19:25:33 then it works 2022-10-23 19:25:42 name the virtual package foo@testing 2022-10-23 19:25:59 hah 2022-10-23 19:26:07 never would have tried that 2022-10-23 19:26:08 fancy 2022-10-23 19:43:16 <3 this workflow for building stuff from source 2022-10-23 19:43:32 i could probably just have made an APKBUILD file to do it tho.. 2022-10-23 19:44:16 trying to build a modern openscad since there have been no tags in like 2 years or something 2022-10-23 19:48:51 yeah it's unfortunate :/ 2022-10-24 06:30:24 hm, after the apk upgrade today I got the following error message https://tpaste.us/1lzV what is that about? I installed libqrencode via `apk add cmd:qrencode` I don't understand why it requires me to select "one of the 'provided by' packages explicitly" if there is only one 2022-10-24 07:17:39 apk info --provides libqrencode 2022-10-24 07:17:39 libqrencode-4.1.1-r0 provides: 2022-10-24 07:17:39 so:libqrencode.so.4=4.1.1 2022-10-24 07:17:39 cmd:qrencode 2022-10-24 07:17:52 the cmd:qrencode is unversioned 2022-10-24 08:06:26 Has anyone looked into Chromium (and thus also qt5-qtwebengine) on RISCV64 yet? 2022-10-24 09:33:01 i havent 2022-10-24 09:33:30 i have trying to track down why docbook manpages fails 2022-10-24 09:33:36 and i think i finally found it 2022-10-24 09:33:44 84d02e8c3abb163d4ca89e62e831c4116b9ea195 2022-10-24 09:37:44 this one here: https://git.alpinelinux.org/aports/diff/main/docbook-xsl/docbook-xsl.post-upgrade?id=84d02e8c3abb 2022-10-24 09:38:49 as i understand, the xmlcatalog is so that http://docbook.../*.xsl gets replaced with /usr/share/docbook.../*.xsl 2022-10-24 09:39:03 the above commit replaced the http:// urls with https:// 2022-10-24 09:39:30 while in the xml docs everyhere there is still http://docbook.... 2022-10-24 09:40:10 with the aboce change it will no longer replace http://docbook with local file. it will only replace https://docbook 2022-10-24 10:12:55 dalias: when I build packages from source I often cd ~/sources/aports/community/whatever && abuild deps first, super fucking convenient 2022-10-24 10:13:33 including musl several times :) 2022-10-24 10:14:09 same here. i do: (cd ~/aports/*/whatever && abuild deps) 2022-10-24 10:14:22 then `head /etc/apk/world` is a good way of looking at which source projects I still have the dependencies sitting around for and can get rid of 2022-10-24 10:14:39 for that i do: apk del .make* 2022-10-24 10:14:41 with one command! 2022-10-24 10:15:00 usually I want to keep one or two of them, ncopa 2022-10-24 10:15:25 head /etc/apk/world was a very nice tip 2022-10-24 10:17:02 btw, the parenthesis around `( cd ~/aports/.... && abuild deps )` is so I dont need to `cd` back to where I were 2022-10-24 10:17:27 aye, subshell 2022-10-24 10:17:35 could make a little shell alias 2022-10-24 10:17:46 well, function 2022-10-24 10:18:05 echo 'deps() ( cd ~/sources/aports/*/$1 && abuild deps )' >> ~/.profile 2022-10-24 10:18:37 cool 2022-10-24 10:55:36 mhm I was auto-assigned for review on aports but I don't have permission to review/approve the MR 2022-10-24 10:56:25 That was changed in a recent gitlab version 2022-10-24 10:57:43 anything I can do here? :) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/40553 2022-10-24 11:15:22 Just do a thumps up or say you approe it 2022-10-24 11:50:23 a bit cumbersome imho 2022-10-24 11:50:37 yes 2022-10-24 11:50:57 The plan was to give all maintainers a guest role 2022-10-24 11:51:06 which would make it possible again 2022-10-24 11:51:19 it would be nice if it would be more visisble that the maintainer approved it 2022-10-24 11:51:29 maybe we could have a bot that created a tag or similar 2022-10-24 11:51:54 Having a guest role for them should fix it 2022-10-24 11:51:59 ok 2022-10-24 12:06:47 [19:16:35] <@psykose> will they add the slabbing by default into the compression or will it have to be manual 2022-10-24 12:06:49 default! 2022-10-24 12:35:05 nmeum: can we have 33.0.3p1 release of https://github.com/nmeum/android-tools? thanks :) 2022-10-24 13:44:27 sam_: ! that's nice 2022-10-24 13:45:41 nmeum: i forgot about this caveat- really old stale packages not rebuilt on edge in years don't have a version on the cmd: 2022-10-24 13:45:46 anything new does 2022-10-24 13:45:52 since we never bump edge stale 2022-10-24 13:46:06 and that apk .10 issue with unversioned provides exists, it's why we reverted the apk upgrade 2022-10-24 13:46:14 i thought i fixed every single one so i upgraded it again 2022-10-24 13:46:24 but i will look for every unversioned cmd: now and rebuild all 2022-10-24 13:51:18 there's over 700 of them :) 2022-10-24 13:51:24 yep 2022-10-24 13:51:31 but we had to fix that at some point 2022-10-24 13:51:39 so unless someone wants to wait more before rebuilding 700 things 2022-10-24 13:52:05 want to bet on how many things will fail to rebuild? :p 2022-10-24 13:52:16 for me, zero, as you'll fix them all, i'm sure 2022-10-24 13:55:42 anything in main/community failing is just fixing them ahead of time for the release too :p 2022-10-24 14:16:58 ikke: edge ppc64le/aarch64 have been stuck on openjdk again 2022-10-24 14:17:10 very fun 2022-10-24 14:30:17 any idea why openjdk fails? 2022-10-24 14:30:22 does it deadlock? 2022-10-24 14:31:52 openjdk fails because it's openjdk 2022-10-24 14:32:02 a concentrated fail 2022-10-24 14:33:51 error: module not found: jdk.hotspot.agent 2022-10-24 14:34:29 it deadlocks forever yeah 2022-10-24 14:34:40 any idea why? 2022-10-24 14:35:08 nope 2022-10-24 14:35:13 it's always at the same spot iirc 2022-10-24 14:35:27 if you look at where it's frozen in the build log 2022-10-24 14:35:37 i don't have access to the builders 2022-10-24 14:49:01 it's also only like 15% of the time 2022-10-24 14:49:15 and seemingly on any of them 10+ iirc 2022-10-24 14:59:26 Hello, I was wondering if there is anyway to store kernel messages upon a kernel panic? 2022-10-24 15:00:22 I am aware ubuntu has a package in which it stores the kernel panic logs under its swap partition that can be debugged later. I was wondering if alpine has anything similar? I would preferably like to see the stack trace that gets thrown out on the monitor too. 2022-10-24 15:11:06 dzilvys: i dont think we have a package for that, sorry 2022-10-24 15:11:12 but it sounds like a good idea 2022-10-24 15:15:32 Is there a way to do it without a package at the moment? syslog doesn't catch the kernel panic itself so I really am not able to debug what exactly is causing these kernel panics 2022-10-24 15:16:30 Everything happens too quickly to view and analyze. So I am stuck debugging something I can't see :D 2022-10-24 15:17:09 dzilvys: just maybe dmesg would catch it if you ssh'd from another machine and used dmesg -w 2022-10-24 15:22:20 orbea: -w is not in the current version of dmesg that we have installed. I tried watch dmesg with a low delay but still, nothing... 2022-10-24 15:24:30 you'd want util-linux-misc dmesg 2022-10-24 15:31:53 let me install it and see if it helps 2022-10-24 15:38:39 So is there a way to trust the edge repository? 2022-10-24 15:38:46 I keep getting an error that it is untrusted 2022-10-24 15:40:48 what version were you on 2022-10-24 15:41:13 of alpine or repo? 2022-10-24 15:41:30 yes 2022-10-24 15:44:23 I gave you options :D 2022-10-24 15:45:01 of alpine. 2022-10-24 15:45:15 #1-Alpine SMP Mon Feb 22 12:57:56 UTC 2021 x86_64 Linux 2022-10-24 15:45:42 Not of the kernel, but of distro. 2022-10-24 15:45:43 3.10.8 2022-10-24 15:45:44 3.10.9 2022-10-24 15:45:54 sorry, I was getting both if you were interested 2022-10-24 15:47:27 Keys were rotaded since then and 3.10 wasn't supported anyway at that point. If you want to uprade to edge, you may want to upgrade to 3.16 first and then upgrade to an edge 2022-10-24 15:47:30 that hasn't been supported for almost 2 years 2022-10-24 15:47:42 anyway if you upgrade to 3.13 first you'll have the keys for everything 2022-10-24 15:48:02 or maybe it was 3.14 2022-10-24 15:48:55 right okay, and to clarify there is no way to import the keys into an older version of alpine? 2022-10-24 15:52:25 apk add -U --repository https://dl-cdn.alpinelinux.org/alpine/v3.14/main alpine-keys 2022-10-24 15:52:46 or whatever version was the first to include the new keys 2022-10-24 15:53:39 Thank yo 2022-10-24 15:57:55 on 3.10 that dmesg is just in 'util-linux' without the -misc part 2022-10-24 17:13:46 fcolista: please commit !40584 as this is last blocker before 3.17 removal of php8 2022-10-24 19:00:27 h 2022-10-24 19:01:27 h 2022-10-24 19:01:37 h 2022-10-24 19:01:40 h 2022-10-24 19:01:55 ikke: do you have some time to shimmy the builders by chance 2022-10-24 19:06:30 (x86_64/aarch64 are stuck on openjdk, ppc64le has stray makedepends) 2022-10-24 19:09:43 Will look at it in a bit 2022-10-24 20:10:36 psykose: no stray makedepends on ppc64le 2022-10-24 20:10:47 huh that's weird 2022-10-24 20:10:57 edge, right? 2022-10-24 20:11:05 ye 2022-10-24 20:11:08 https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/hivex/hivex-1.3.21-r1.log if you look at this 2022-10-24 20:11:10 /etc/apk/world is clean 2022-10-24 20:11:14 there's almost nothing installed 2022-10-24 20:11:20 but a link fails that i can reproduce if i add gettext-dev 2022-10-24 20:11:23 because of no -lintl 2022-10-24 20:11:26 but by default it's not there 2022-10-24 20:11:31 let me check 2022-10-24 20:11:33 no stray gettext-dev installed by change via other means 2022-10-24 20:12:48 need the builder to be idle 2022-10-24 20:13:47 no, it's not installed 2022-10-24 20:15:00 weird 2022-10-24 22:45:47 dzilvys: alpine doesn't have prepackaged kdump, but you can enable pstore if you have a suitable backend 2022-10-24 23:43:24 I submitted an MR yesterday, new aport nsjail. Is there anything wrong with the MR, that is keeping it from being merged? 2022-10-24 23:55:14 thanks for the input. will start working on improvements now. 2022-10-25 01:07:50 ikke: just in case you're having too much fun on vacation, aarch64 is stuck on openjdk again ^_^ 2022-10-25 01:07:55 this issue is endlessly annoying 2022-10-25 04:39:53 psykose: I'm back home since yesterday 2022-10-25 05:03:00 ah :) 2022-10-25 05:03:03 how was vacation 2022-10-25 05:04:17 was visiting my parents, it was nice 2022-10-25 05:05:49 ^_^ 2022-10-25 05:19:40 non-unstable branch? :P 2022-10-25 05:19:51 https://gitlab.alpinelinux.org/alpine/aports/-/issues/14293#note_270329 2022-10-25 05:21:56 the stablest of branches indeed 2022-10-25 05:55:58 any ideas why openjdk no longer builds on ppc64le? I cannot see any significant changes recently 2022-10-25 05:56:16 Creating ct.sym classes 2022-10-25 05:56:16 error: module not found: jdk.hotspot.agent 2022-10-25 05:56:33 ncopa: maybe ask bratkart- 2022-10-25 05:58:38 ncopa: jdk.hotspot.agent has been disabled since the beginning 2022-10-25 06:03:51 ah i guess i misremembered and they did indeed never pass 2022-10-25 06:05:04 the make output is quite strange, doesn't look like an actual error 2022-10-25 06:05:37 just a bunch of warnings, but nothing serious until it cancels 2022-10-25 06:07:40 i'm currently trying to rebuild everything from 9 onwards, trying to figure out when and where it breaks 2022-10-25 06:08:44 yep 2022-10-25 06:09:33 i see that there is even a removal of jdk.hotspot.agent. so im a bit surprised that it looks for it all of a sudden 2022-10-25 06:09:56 thank you for looking at it 2022-10-25 06:10:27 the error is quite misleading here, yes 2022-10-25 06:13:09 andypost[m], bareOS devs has not reply about php8.1 support, why should we ship this package without upstream support? 2022-10-25 08:26:02 3.17 builders are up 2022-10-25 08:33:16 Morning psykose, just wanted to thank you for the help yesterday :) I got the correct version of dmesg installed without doing some weird key importing stuff. 2022-10-25 09:54:46 fcolista: I know it's weird to ship unsupported but we need to move php8 to testing as it does not support openssl3 and as 3.17 builders are up let's move them both to testing 2022-10-25 11:19:11 I suppose it's too late for python 3.11 :-) 2022-10-25 11:35:14 oh... 2022-10-25 11:35:20 yeah, i think so 2022-10-25 12:12:15 andypost[m], ok. We should put this on the release note i believe.. 2022-10-25 12:42:26 Interesting, Linus thinks about removing i486 support from the kernel 2022-10-25 13:51:19 I'm building a package, and `abuild -r` has somehow decided to upgrade my system packages. I didn't expect this - what's the reason it can happen? 2022-10-25 13:51:50 I did recently change my mirror, this may have something to do with it? 2022-10-25 14:00:36 fcolista: ++ to release notes, other option is move to testing as php8 will get 1y of seurity support but not openssl3 support 2022-10-25 14:00:43 https://www.php.net/supported-versions.php 2022-10-25 14:29:49 eddsalkield: it can happen when it needs to install packages that require newer dependencies. 2022-10-25 20:36:08 who can I talk to if I'd like commit rights for community to push/merge changes to packages I maintain? 2022-10-25 20:37:14 afaik there's no such thing, you either have push rights to whole of aports or none; i guess ikke would be the person to ask here 2022-10-25 20:37:37 ikke: hi 2022-10-25 20:37:40 I would like those permissions as well 2022-10-25 20:37:53 ptrc is right 2022-10-25 20:38:11 literally cannot contribute to aports, smh 2022-10-25 20:38:16 comprehensive permissions then, with the solemn promise not to use most of them 2022-10-25 20:39:26 eddsalkield: you should use rootbld if you don't want abuild to modify your host 2022-10-25 20:39:28 I would imagine that we could have some bot accepting commands 2022-10-25 20:40:36 can we not install a post-receive hook or some such 2022-10-25 20:41:18 that's more or less how "main branch push" privileges worked before 2022-10-25 20:41:24 yes 2022-10-25 20:41:34 but there were some issues with that approach 2022-10-25 20:42:10 what's the problem with gitlab? 2022-10-25 20:43:09 messy, convoluted and resource-heavy ruby-on-rails codebase, unless you mean something specific 2022-10-25 20:43:47 in any case, if these problems are blockers then the problem is likely to never be solved 2022-10-25 20:44:06 I don't think there are blockers 2022-10-25 20:45:19 ptrc: i dunno, it's not like there is an ongoing conversation about maintaining aports by not using gitlab directly 2022-10-25 20:45:44 i'm.. not sure what you mean? "not using gitlab directly"? 2022-10-25 20:48:19 ikke: what are the blockers? 2022-10-25 20:49:17 acceptence for a particular solution and time to implement said solution 2022-10-25 20:51:35 https://l.sr.ht/INeq.png 2022-10-25 20:53:52 in the absence of protest I'll assume that this is fine 2022-10-25 20:54:19 I think the priority is at the discretion of the TSC 2022-10-25 20:54:28 i don't really see the point 2022-10-25 20:54:41 more people with merge access to things is if anything a bad thing 2022-10-25 20:54:41 change it if you wish 2022-10-25 20:54:46 pushing buttons is trivial 2022-10-25 20:55:10 I wonder who is going to maintain such setup 2022-10-25 20:55:25 but if you'll pardon my impropriety 2022-10-25 20:55:26 ikke: i wonder actually if we should remove some push permissions from people that haven't used them in a year 2022-10-25 20:55:28 for safety 2022-10-25 20:55:31 it's about time for the TSC to actually do something useful 2022-10-25 20:55:47 and how is that useful? 2022-10-25 20:56:14 it's been sorely wanted and discussed many times across many years 2022-10-25 20:59:54 psykose: I was low-key thinking about that myself 2022-10-25 21:01:01 does it make sense to have alsa-utils-openrc installed but not alsa-utils? 2022-10-25 21:01:16 because according to apk list -I that's my setup 2022-10-25 21:01:55 unless you added it yourself or there's some other magic, no 2022-10-25 21:01:58 i don't think so, as the services uses executables from alsa-utils 2022-10-25 21:02:06 s/services/service/ 2022-10-25 21:02:06 ptrc meant to say: i don't think so, as the service uses executables from alsa-utils 2022-10-25 21:02:48 psykose: expanding on that: what justifies the current list of committers? it's just put into a box and not tnought about 2022-10-25 21:02:52 not thought about* 2022-10-25 21:03:35 Why do you say it's not thought about? 2022-10-25 21:03:43 nothing, we should remove every committer 2022-10-25 21:04:06 I see, thanks. I wonder how I ended up with this 2022-10-25 21:04:08 well, maybe it's thought about, but without rigor 2022-10-25 21:04:57 in general the way aports is set up and the repositories work doesn't really play very well with a lot of people being able to throw things into them 2022-10-25 21:05:11 maybe 30% of things i merge are things i have to somewhat change or fix in some way 2022-10-25 21:05:30 according to your personal sensibilities or according to a defined process or standards? 2022-10-25 21:05:46 former 2022-10-25 21:05:52 not ideal 2022-10-25 21:05:58 in what sense 2022-10-25 21:06:04 i don't care about the latter 2022-10-25 21:06:05 well, there's room for personal sensibilities 2022-10-25 21:06:19 but standards are helpful to understand the process 2022-10-25 21:06:28 i get paid $0 for this so i don't care about following someones corporate improvement plan 2022-10-25 21:06:40 ACTION rolls eyes 2022-10-25 21:07:13 alpine can't see past its own nose sometimes 2022-10-25 21:07:26 i do understand what you mean, but i honestly don't really think there is much benefit to people uploading their own changes 2022-10-25 21:07:32 at best it makes things a tiny bit faster 2022-10-25 21:07:39 i can't think of any other positive from it 2022-10-25 21:07:42 maybe there shouldn't be any committers, I dunno, sure 2022-10-25 21:07:52 but it would be nice /to know/ 2022-10-25 21:07:53 yes, end alpine, it's not worth ot 2022-10-25 21:08:09 psykose: and at worst some random person can introduce a backdoored package to people on edge 2022-10-25 21:08:11 stop committing, touch grass 2022-10-25 21:08:21 or forget to rebuild things on SONAME 2022-10-25 21:08:30 I don't think some random person should be given commit rights 2022-10-25 21:08:31 which happens all the time already from some developers 2022-10-25 21:08:57 checklists in hospitals save lives 2022-10-25 21:09:02 checklists keep the trains running on time in japan 2022-10-25 21:09:08 process can be helpful 2022-10-25 21:09:16 it is not a reflection on anyone's competence 2022-10-25 21:09:25 we all have our mental checklists, yes 2022-10-25 21:09:55 i'm curious what checklist you are proposing 2022-10-25 21:09:58 aye, and if your mental SONAME checklist was written down somewhere then we would be less likely to have developers forgetting to deal with it 2022-10-25 21:10:07 tbh, if it was guarded by a strict CI checking way more than it does now, i could see it work 2022-10-25 21:10:16 there's a lot of missing tooling 2022-10-25 21:10:19 but it would probably require some weird heuristic checks 2022-10-25 21:10:33 ptrc: plug-in GPT-3 and lets goooo 2022-10-25 21:10:38 in any case, discuss it, put your thoughts in the minutes, and I'll be happy 2022-10-25 21:12:37 I seem to recall the consensus about pmOS developers who wanted in was, let them in, it's a good idea 2022-10-25 21:12:41 good ideas should become done ideas 2022-10-25 21:12:44 not put into the box 2022-10-25 21:13:30 ptrc: do you think it's not possible to introduce backdoored packages right now? 2022-10-25 21:13:41 do you read through the source code of all new packages in Alpine? 2022-10-25 21:14:07 psykose: not at home but !40645 lgtm, ship it o7 2022-10-25 21:14:13 :) 2022-10-25 21:14:16 ite, wi;; wait for ci 2022-10-25 21:14:41 Newbyte: not via APKBUILD 2022-10-25 21:16:12 gesundheit psykose 2022-10-25 21:16:19 :3 2022-10-25 21:16:21 what does gesundheit mean again? 2022-10-25 21:16:24 I forgot 2022-10-25 21:16:34 go fuck yourself in german 2022-10-25 21:16:35 get healthy 2022-10-25 21:16:46 similar to 'bless you' 2022-10-25 21:16:48 conflicting answers 2022-10-25 21:16:55 I may have received some unreliable information 2022-10-25 21:16:56 both are true 2022-10-25 21:17:15 It literally means 'health' 2022-10-25 21:17:17 might we say.. ddv was backdoored in this information game? 2022-10-25 21:17:44 really makes you think 2022-10-25 21:17:55 *thonk* 2022-10-25 21:24:48 [23:16] get healthy 2022-10-25 21:24:53 it just means health 2022-10-25 21:25:00 That's what I mentioned after 2022-10-25 21:25:10 oh 2022-10-25 21:25:17 i was scrolled a little up 2022-10-25 22:15:26 good ideas should become done ideas 2022-10-25 22:15:29 not put into the box 2022-10-25 22:15:40 sounds like it's time for the ol' Aiken quote 2022-10-25 22:16:13 which I can attest is real, many many times over. 2022-10-26 05:23:50 ncopa: bootstrapping rust on ppc64le and armhf, stopped mqtt-exec.aports-build there 2022-10-26 05:32:45 tmhoang: seems like s390-tools fails on s390x, -Werror-array-bounds https://build.alpinelinux.org/buildlogs/build-3-17-s390x/main/s390-tools/s390-tools-2.21.0-r2.log 2022-10-26 05:49:13 ncopa: armv7 now as well 2022-10-26 06:36:38 morning! cool! it measn that main was built 2022-10-26 06:44:59 im building rust on aarch64 2022-10-26 07:07:10 finally i can reproduce the s390x failure with openjdk11 on my machine. now i just need to figure out a way how to debug and bt it with gdb running in a binfmt-qemu vm 2022-10-26 07:08:11 someone has done this before? i always end with "warning: ptrace: Function not implemented" 2022-10-26 07:08:49 is that qemu? 2022-10-26 07:20:14 ncopa: I think we can give bratkartoffel a container on the s90x machine? 2022-10-26 07:25:54 ncopa: yes, binfmt is based on qemu which i think is the problem. qemu doesn't implement ptrace functionality, so i have to do some weird remote-debugging stuff to get into it. but i haven't found a way to do this 2022-10-26 07:44:29 ikke: i was thinking the same. 2022-10-26 07:44:47 ikke: i think we should 2022-10-26 07:45:25 rust was bootstrapped on aarch64 2022-10-26 07:48:36 add commits rights to anyone so that alpine becomes the next AUR with random packages written by random people yay sure 2022-10-26 08:41:58 ikke how is rust bootstrap on armhf progressing? I don't see anything building there. you want me to take a look? 2022-10-26 08:42:16 ah, its done 2022-10-26 08:42:49 ikke: i reboot armhf. rust is built 2022-10-26 08:43:35 same on armv7. i clean it up and reboot 2022-10-26 08:45:40 ppc64le also done and rebooted 2022-10-26 08:52:21 ncopa: did you remove the extra dependencies? 2022-10-26 08:56:49 markand: no one suggested that and it is not helpful 2022-10-26 08:57:39 ikke: i think so 2022-10-26 09:31:37 hum. one of the glib-networking tests fails now. i wonder what happened 2022-10-26 09:34:53 this is the issue: https://gitlab.gnome.org/GNOME/glib-networking/-/issues/201 apparently the test is broken 2022-10-26 10:18:40 it looks like main/perl-server-starter is deadlocked on x86. I'll have a look 2022-10-26 10:21:24 heh... it just deadlocked on shutdown. now it continues 2022-10-26 10:30:19 x86 was set to continue on errors 2022-10-26 10:30:30 i suspect the build-3-16-x86 also does that 2022-10-26 10:30:54 it did, indeed 2022-10-26 10:32:16 aha 2022-10-26 10:33:05 i have adjusted it 2022-10-26 10:46:18 ncopa: dl-master.a.o has <10% <200G space free 2022-10-26 10:59:55 ikke: do you think we will run out of diskspace? 2022-10-26 11:01:11 might be tight 2022-10-26 11:01:43 btw, should I make the v3.17 directory already? 2022-10-26 11:01:49 builders cannot upload anything yet 2022-10-26 11:04:07 i already did 2022-10-26 11:04:10 and they uploaded main 2022-10-26 11:04:25 oh, missed it 2022-10-26 11:05:25 psykose: Thank you for your patience on rsync :) 2022-10-26 11:05:35 np :) 2022-10-26 11:10:24 package maintainer: person fixing other people's shit for a living ^W ^W fun ^W unknown reasons 2022-10-26 11:12:19 Piraty: tell me about it... 2022-10-26 11:15:44 i wonder what future encyclopediae will have to write about this kind of masochist 2022-10-26 11:17:46 is the aarch64/ppc64 edge builders hanging on building jdk? 2022-10-26 11:18:45 andypost[m]: possibly. let me check 2022-10-26 11:18:54 yeah, been stuck for a while 2022-10-26 11:19:12 but unpausing them will just have them fail in a loop until they get stuck again since it fails for other reasons instead as we found out 2022-10-26 11:19:40 it would let the builders progress though that would be nice 2022-10-26 11:23:14 bratkartoffel: are you able to work on openjdk build failures on aarch64 and ppc64le? do you mind if I disable those for now? 2022-10-26 11:23:52 i killed rebooted build-edge-ppc64le 2022-10-26 11:25:15 i also rebooted build-edge-aarch64 2022-10-26 11:25:39 we need someone who can follow up on openjdk build failures and deadlocks 2022-10-26 11:26:16 ikke: did you give bratkartoffel a s390x machine? 2022-10-26 11:26:57 ncopa: no, not yet, can arrange that 2022-10-26 11:30:40 thanks 2022-10-26 11:35:25 bratkartoffel has a container now 2022-10-26 11:37:35 thank you! 2022-10-26 11:44:28 i wouldn't disable them as a bunch of other things that need them will then fail 2022-10-26 11:44:38 it's fine if they hang out for a bit on edge 2022-10-26 11:44:41 and the 3.17 queue is huge 2022-10-26 11:49:01 re abuild.conf. I like the idea of /usr/share/abuild/abuild.conf with the defaults. and maybe an `abuild env` that prints the environment 2022-10-26 11:49:25 would be good to have the env in the build logs 2022-10-26 11:55:45 sounds good to me too 2022-10-26 11:57:56 I'd also like to redesign https://build.alpinelinux.org/ but I don't know how 2022-10-26 12:29:47 http://build.postmarketos.org 2022-10-26 12:34:33 build.voidlinux.org/ ;) 2022-10-26 12:35:02 ( don't actually use buildbot like this ) 2022-10-26 13:02:46 ncopa: could we get https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/111 merged before 3.17? 2022-10-26 13:11:59 ncopa: there's other stuff for 3.17 as well like https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/2 2022-10-26 13:12:18 oops, https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/2 2022-10-26 13:12:38 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/112 2022-10-26 13:13:12 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/109 2022-10-26 13:14:36 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/100 2022-10-26 13:49:15 ^ this 2022-10-26 14:04:07 yeah, thats next on my (unwritten) todo list 2022-10-26 14:12:57 ncopa: also consideration should be given to some fix for https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10536 in 3.17 2022-10-26 14:33:01 yeah. I intend to work on those now that the builders are up 2022-10-26 14:36:07 rust is also ready to build for all of them i think 2022-10-26 18:33:50 ikke: assuming there's some interface for doing it easily, you could give me the gitlab permissions to add guest tags to people 2022-10-26 18:34:01 i'd give people the tag so they can approve things where i see 2022-10-26 19:29:53 psykose: my idea was to have a dedicated group for them that we then add as guest to the aports project 2022-10-26 19:30:12 if you can make custom groups, sure 2022-10-26 19:30:58 similar to the team groups we already use 2022-10-26 19:31:42 But at some point, we don't want to keep maintaing that group manually 2022-10-26 19:46:01 psykose: regarding maintainers as guest, the quickest way to get something right now would be to open an MR here: https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf 2022-10-26 19:47:02 what would i add 2022-10-26 19:47:27 1) a new group (dedicated .tf file). 2) users in that group 2022-10-26 19:47:28 before i assume you manually pressed some buttons for that person you added 2022-10-26 19:47:56 There are users manually added as reporter to aports 2022-10-26 19:48:10 But all the team/* groups are managed this way 2022-10-26 19:49:04 psykose: something like this: https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf/-/blob/master/groups_developers.tf 2022-10-26 19:49:05 this one is a guest though https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/39958#note_267466 2022-10-26 19:49:13 there's already a group i assume 2022-10-26 19:49:23 no, no group exists yet 2022-10-26 19:49:30 then how does this person have a guest badge 2022-10-26 19:49:36 I manually added that one 2022-10-26 19:49:57 right. so how does one add things to that same guest badge instead of a manual group 2022-10-26 19:50:05 i don't really see a point to make a different-from-default-guest group 2022-10-26 19:50:08 that one has no permissions already 2022-10-26 19:50:20 There is no guest group 2022-10-26 19:50:31 it's a role 2022-10-26 19:50:35 role then 2022-10-26 19:50:43 you can either add users individually as a role, or a group 2022-10-26 19:50:59 what would the benefit of not using the role be 2022-10-26 19:51:38 We are using the role 2022-10-26 19:51:53 the difference is between adding users directly to aports, or via a group 2022-10-26 19:52:06 ah, ok 2022-10-26 19:52:14 right, i understand 2022-10-26 19:52:56 manually adding merges into gitlab-tf for every maintainer seems more cumbersome than adding them to aports with 3 clicks though 2022-10-26 19:53:21 But at the same time less transparent 2022-10-26 19:53:40 kind of, it shows up as an event in activity and also in the list of users 2022-10-26 20:07:32 Ideally, that group would be automatically populated 2022-10-26 20:11:07 bootstrapping rust on x86 2022-10-26 20:15:23 giving merge access to a token to add stuff into the .tf file sounds a bit harder than adding a role 2022-10-26 20:15:26 but eh 2022-10-26 20:15:51 I mean, I set it up and I'm administrator 2022-10-26 20:16:09 ofcourse it would be a lot easier for me to just click a few buttons on the interface 2022-10-26 20:16:43 But I felt that providing this as code would allow others to see how it's done, and provide MRs themselves to make changes 2022-10-26 20:16:53 without needing to directly give permissions to make the changes 2022-10-26 20:37:21 yeah, that part is nice. but if it's automated (i assume via maintainer email->account matching or something) that doesn't require them to do it to begin with 2022-10-26 20:37:29 but yeah, sure, i'll have a look and make a group when i find some time 2022-10-26 20:39:18 psykose: yeah, the goal is to automate it, but you wanted a quick solution, so I offered one 2022-10-26 20:59:31 x86_64 is done 2022-10-26 21:47:47 x86 is done as well 2022-10-26 21:50:53 epic 2022-10-27 00:23:50 what is CBUILD? I think I know what CTARGET and CHOST are 2022-10-27 00:24:30 current build machine arch 2022-10-27 00:24:48 host is target arch and target is target of generated executables for compilers etc 2022-10-27 00:24:51 wouldn't CBUILD be the current triple instead? 2022-10-27 00:24:54 and CARCH the arch 2022-10-27 00:24:57 yes 2022-10-27 00:25:08 but in generic terms, you know 2022-10-27 00:25:10 hum. the generated APKBUILD from newapkbuild passes --host=$CHOST to configure, but when I run configure --help: 2022-10-27 00:25:15 --host=HOST cross-compile to build programs to run on HOST [BUILD] 2022-10-27 00:25:21 which sounds a lot more like $CTARGET 2022-10-27 00:25:34 and no, carch is from chost 2022-10-27 00:25:49 nah 2022-10-27 00:25:55 ctarget is compiler target 2022-10-27 00:25:59 it's unused for 99.99% of programs 2022-10-27 00:26:04 ah, okay 2022-10-27 00:26:09 build=current host=target 2022-10-27 00:26:17 alright 2022-10-27 00:26:18 more words: https://mesonbuild.com/Cross-compilation.html 2022-10-27 00:26:25 this uses the correct terms for them all 2022-10-27 00:26:47 and yeah they're confusing and frequently confused 2022-10-27 00:26:51 next stop then is figuring out why configure is complaining that x86_64-alpine-linux-musl is an unrecognized system type 2022-10-27 00:26:57 people confuse both cbuild and ctarget as the 'target exe' 2022-10-27 00:27:01 aha 2022-10-27 00:27:07 you need update_config_guess/sub in prepare() 2022-10-27 00:27:13 or autoreconf the build system 2022-10-27 00:27:22 the autoconf files shipped with whatever you're building are too old 2022-10-27 00:27:29 or something along those lines 2022-10-27 00:27:43 oh my, so it is: 2022-10-27 00:27:47 they correspond to those autoconf config.guess config.sub files you see in the build dir 2022-10-27 00:27:51 # Generated by GNU Autoconf 2.69 for Angband 4.2.4. 2022-10-27 00:27:51 which contain some host definitions 2022-10-27 00:27:55 hmm 2022-10-27 00:28:13 although config.sub has: timestamp='2012-02-10' 2022-10-27 00:28:16 which *seems* pretty old 2022-10-27 00:28:22 yeah that's prehistory 2022-10-27 00:28:32 you can use newer autoconf without a newer gettext and gnuconfig which provides these files 2022-10-27 00:28:34 (not literally but yeah it's too old) 2022-10-27 00:28:54 if the rest of the macros were ok then just the config.guess/sub will fix that part and it should build 2022-10-27 00:29:15 in gentoo we have econf unconditionally blast config.guess and it's never caused a problem but it's not always enough unfortunately (sometimes you need like the libtool gunk in configure to be updated too) 2022-10-27 00:29:23 yep 2022-10-27 00:29:34 it's particularly bad on macOS because everyone hardcoded some stupid regex for the versioning 2022-10-27 00:29:39 lmao 2022-10-27 00:29:49 hows the gentoo macos support these days 2022-10-27 00:29:52 "omg apple started using major versions again" 2022-10-27 00:31:34 >>> angband-dev*: Running split function dev... 2022-10-27 00:31:48 is there a way to express in my apk that there is no corresponding dev package? 2022-10-27 00:32:08 remove -dev from subpackages 2022-10-27 00:32:48 aha, thanks 2022-10-27 00:41:11 replacing config.sub/guess is alright, at least you don't need to regen stuff 2022-10-27 00:43:06 worse is when you run into something like a bug in libtool where libtool forces -nostdlib into ldflags when linking c++ and then forgets to add some args back and then you have to regen autotools files for every single autotools-using c++ project in existence 2022-10-27 00:44:17 makes you think whether a build system that depends on projects shipping release tarballs with half of the build system pregenerated was really such a good idea 2022-10-27 00:44:43 is there any reason not to autoreconf everything other than it's slow and it might need the original autoconf version? 2022-10-27 00:44:55 s/autoconf version/autotools versions/ :| 2022-10-27 00:44:55 Hello71 meant to say: is there any reason not to autoreconf everything other than it's slow and it might need the original autotools versions? 2022-10-27 00:45:18 it's slow, does not always work, and is undesirable at least for any package that is in your bootstrap path 2022-10-27 00:45:34 also is not always a trivial matter like autoreconf -if 2022-10-27 00:45:43 projects sometimes ship cursed things 2022-10-27 00:47:02 the idea with not regenerating autotools is not needing autotools installed during build 2022-10-27 00:47:17 "00:44 makes you think whether a build system that depends on projects shipping release tarballs with half of the build system pregenerated was really such a good idea" ah, but, what if you need to compile on a system where you somehow have a C compiler and Bourne-like shell but can't install m4 for some reason 2022-10-27 00:51:10 if you add autotools dependencies in bootstrap path you are suddenly expanding it with specifically gnu-flavor m4 and other junk that should not be there 2022-10-27 00:53:40 e.g. my current path https://gist.github.com/q66/260f6a8d940617ac117786031ba24c2c vs if i add autotools somewhere late on https://gist.github.com/q66/404066ba79961808b8d429fc37dc8f5c 2022-10-27 00:56:40 hey if you update swig you can get that pcre to pcre2 2022-10-27 00:56:41 : ) 2022-10-27 00:56:43 i mean it's not much and *technically* not a problem 2022-10-27 00:56:52 but i'd rather shrink it than expand it 2022-10-27 00:57:12 psykose: considering the amount of stuff that still needs pcre i'm not in a rush 2022-10-27 00:57:19 it will be around for another 15 years 2022-10-27 00:57:26 at this rate 2022-10-27 00:57:27 oh, swig made a release with that 2022-10-27 00:57:30 ye 2022-10-27 00:57:35 fresh 2022-10-27 00:57:47 i looked about a week ago when i was checking whether it would be feasible to kill pcre 2022-10-27 00:57:53 wouldn' 2022-10-27 00:57:55 t be 2022-10-27 00:58:03 a ton of random shit needs it as you get to more packages 2022-10-27 00:58:12 well, at least out of my main/ 2022-10-27 00:58:16 ah, that yeah 2022-10-27 00:58:22 currently there are 5 things 2022-10-27 00:58:26 er, 4 2022-10-27 00:58:33 libusb-compat is another fun one 2022-10-27 00:58:33 swig, zsh, syslog-ng, and slang 2022-10-27 00:58:51 maybe i'll move zsh to contrib/ and deal with it that way 2022-10-27 00:59:23 what is libusb-compat used by? 2022-10-27 00:59:59 ACTION checks 2022-10-27 01:00:15 hm if i move zsh, update swig, then it'll be just syslog-ng and slang 2022-10-27 01:00:29 ah, practically nothing modern 2022-10-27 01:00:38 just random older software for niche things 2022-10-27 01:00:46 slang is horrible so if i could kill that that could solve that 2022-10-27 01:00:49 but it's needed by some things 2022-10-27 01:01:31 libcaca and newt 2022-10-27 01:01:35 newt is needed by nmtui in networkmanager 2022-10-27 01:01:43 libcaca is needed for funny backend in mpv i guess 2022-10-27 01:01:55 could easily kill the latter but i want to keep the former 2022-10-27 01:02:52 new mpv tag is almost here 2022-10-27 01:15:04 the package I'm making should have a doc subpackage, but how does abuild decide which files are the documentation? 2022-10-27 01:18:32 usr/share/doc gets moved automatically 2022-10-27 01:18:41 usr/share/man/ directories too (and get compressed) 2022-10-27 01:18:57 and some extras but you usually want one of those 2022-10-27 01:19:06 you can look at default_doc in /usr/bin/abuild 2022-10-27 01:19:44 oh ugh this ignores --mandir and --docdir entirely and drops its docs into the libdir, of all places 2022-10-27 01:19:48 no wonder it doesn't work 2022-10-27 01:20:02 :) fun 2022-10-27 01:20:11 that is probably a problem to fix upstream 2022-10-27 01:25:52 is there a best practice for optional dependencies? eg: this package can use SDL if present at runtime but doesn't require it. Add sdl-dev to depends-dev and leave it out of depends altogether? 2022-10-27 01:26:49 sdl2-dev 2022-10-27 01:26:55 if it's actually sdl1 then sdl12-compat-dev 2022-10-27 01:26:57 but yes 2022-10-27 01:27:08 generally though it would link to the library and depend on it anyway 2022-10-27 01:27:12 you can see in the tracing dependencies output 2022-10-27 01:27:20 also, depends_dev is for the -dev subpackage dependencies 2022-10-27 01:27:22 not many things that don't link but dlopen later 2022-10-27 01:27:28 build dependencies are makedepends 2022-10-27 01:27:42 aha, thanks 2022-10-27 01:28:17 ok, yes, it does link against sdl, it just then lets you choose not to use it at runtime 2022-10-27 01:28:23 makes sense 2022-10-27 01:36:57 psykose: it's not bad but it's such a pain with some of the random apple decisions 2022-10-27 01:37:08 like they recently just decided sprintf bad 2022-10-27 01:37:42 https://github.com/iains/gcc-darwin-arm64/issues/98 2022-10-27 01:38:13 hum, I really don't want to force people to install SDL and x11 just to play a roguelike 2022-10-27 01:39:33 psykose: like, think about it, with the implicit func. decl stuff, apple did that in advance of Clang proper and could've led an effort to fix things 2022-10-27 01:39:35 but nooooo 2022-10-27 01:39:46 they did it with 0 warning 2022-10-27 01:39:48 elly: it's automatic 2022-10-27 01:40:19 installing the deps is automatic, but it feels bad to make people pull in such a big dep for a game that has a perfectly good curses frontend 2022-10-27 01:40:36 libX11.so and libSDL is hardly a big dep 2022-10-27 01:40:42 can't speak for the whole tree though :p 2022-10-27 01:40:47 so it's hard doing anything "linuxy" on macOS because ultimately apple isn't interested 2022-10-27 01:40:51 libSDL is so common anyway, *even for headless use* 2022-10-27 01:40:54 sam_: you mean in their own code, or did they push it into mainline clang themselves 2022-10-27 01:40:57 hm, okay 2022-10-27 01:41:02 I did not have it installed until I tried just now 2022-10-27 01:41:10 elly: if it has configure options for x11/sdl support, you can build twice and make a subpackage, that's what some packages do already 2022-10-27 01:41:26 ptrc: yeah, it does - is there a good example I can look at of how to do that? 2022-10-27 01:41:26 but generally that approach is boring 2022-10-27 01:41:33 unless it can make two binaries by itself 2022-10-27 01:41:36 psykose: just apple clang but we're kind of dependent on apple clang because all the system headers use "Blocks" which gcc can't parse (https://clang.llvm.org/docs/BlockLanguageSpec.html) 2022-10-27 01:41:41 it cannot, I'd basically have to build twice 2022-10-27 01:41:42 ah... 2022-10-27 01:41:42 like technically we could build our own clang 2022-10-27 01:41:43 right 2022-10-27 01:41:46 but it's a pain in the butt 2022-10-27 01:41:51 makes sense, it's macos 2022-10-27 01:41:56 i've nearly done it but i keep getting bored because it takes a million hours to build llvm over and over 2022-10-27 01:42:02 I'll just depend on sdl and libx11 :) 2022-10-27 01:42:08 classic apple stuff i guess :) the walliest of gardens 2022-10-27 01:46:51 totally! 2022-10-27 02:08:40 is the comment on https://lists.alpinelinux.org/~alpine/aports about mail to that list going ignored for a while still current? 2022-10-27 02:19:02 yep 2022-10-27 02:19:06 just gitlab 2022-10-27 02:19:21 usual clone fork as public, use a feature branch, yada yada 2022-10-27 02:21:14 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/40686 hooray, I believe I have made my first alpine package :) thank you all for your help, especially you psykose 2022-10-27 02:22:19 `:) 2022-10-27 02:22:37 seemingly you forgot some test deps or similar 2022-10-27 02:23:29 oh, perhaps! 2022-10-27 02:24:24 hum, I don't know what that failure is, that's interesting 2022-10-27 02:25:24 assuming you don't get that locally 2022-10-27 02:25:25 hm 2022-10-27 02:25:28 could be graphical session 2022-10-27 02:25:48 or test parallelism, or some other weird stuff 2022-10-27 02:25:50 yeah, it works fine for me locally - the referenced file (constants.txt) is in lib/gamedata in the source tree 2022-10-27 02:25:54 for graphics you can use xvfb-run -a 2022-10-27 02:27:16 fails for me in full graphical too 2022-10-27 02:27:22 interesting! 2022-10-27 02:27:39 ah 2022-10-27 02:27:41 i assume you have it installed 2022-10-27 02:27:47 oh, yes, I do 2022-10-27 02:27:49 and so it passes the tests by opening constants.txt from usr/share 2022-10-27 02:27:53 right 2022-10-27 02:27:53 it can't find it in local dir 2022-10-27 02:27:54 :) 2022-10-27 02:28:24 two things to try then- one is seeing the loading code 2022-10-27 02:28:29 see if it has some override, options, whatever 2022-10-27 02:28:38 second is install to DESTDIR="$builddir/whatever" 2022-10-27 02:28:42 ah 2022-10-27 02:28:43 hm 2022-10-27 02:28:48 if it's build time that doesn't work and needs 2 builds 2022-10-27 02:28:48 alright, it fails for me now locally as well 2022-10-27 02:29:03 guess just the first part then 2022-10-27 02:29:18 I'm surprised the unit tests are actually trying to load that file to begin with 2022-10-27 02:29:25 if it's hardcoded to prefix then there's no way to run that without some overrides 2022-10-27 02:29:31 i'm guessing the tests use the full init code 2022-10-27 02:29:41 quite possible 2022-10-27 02:30:06 yeah, I can reproduce the same test failure upstream actually if I do `make tests` without the package also installed at $PREFIX 2022-10-27 02:30:09 hmph 2022-10-27 02:30:38 you know 2022-10-27 02:30:40 this also has a cmake build 2022-10-27 02:31:22 I do not at all trust the cmake build 2022-10-27 02:31:29 :p 2022-10-27 02:31:40 based on how fancy this autoconf is i assume there's something up with it 2022-10-27 02:31:48 generally i just pick whatever they actually use 2022-10-27 02:31:53 and cmake can use -G Ninja which is always nice 2022-10-27 02:32:06 it's not actually clear which one of the three (!) separate build systems here is the canonical one 2022-10-27 02:32:17 there's CMakeLists, there's a Makefile in the root, then *another* makefile in src 2022-10-27 02:32:31 they're all updated! 2022-10-27 02:33:38 ok, I think this test suite will not pass without the game data in $PREFIX so I'm going to disable it for the moment 2022-10-27 02:33:49 sure, that works 2022-10-27 02:34:11 I can fix it upstream to use the data files from the source tree rather than $PREFIX, that is probably most correct 2022-10-27 02:34:45 whatever they'd prefer 2022-10-27 02:35:36 well, in this case they is... me 2022-10-27 02:35:45 not entirely but I am one of the angband developers 2022-10-27 02:36:11 even better :p 2022-10-27 02:36:19 i think what they'd prefer is even more important then 2022-10-27 02:36:24 maybe! 2022-10-27 02:36:38 so lesson for next time, do not try to test your abuild with the package already installed or this can happen 2022-10-27 02:36:52 you can also use abuild rootbld 2022-10-27 02:37:04 does what i says i guess, +- some caveats you run into 2022-10-27 02:37:07 no networking by default either 2022-10-27 02:37:30 also useful to make sure you don't build against random hostdeps and you can see it pass before CI 2022-10-27 02:37:32 not that it's a requirement 2022-10-27 02:39:06 and you also have to squash commits into just new aport to keep your own history clean since we only do ff rebase merges 2022-10-27 02:39:47 yup 2022-10-27 02:40:38 psykose: is your first comment suggesting doing depends=""? 2022-10-27 02:41:19 you can just remove it, no empty var 2022-10-27 02:41:30 unless the game secretly uses the ncurses tools, then depends="ncurses" 2022-10-27 02:41:32 you'd know that more 2022-10-27 02:41:35 it does not 2022-10-27 02:41:44 I'm impressed/surprised that I can leave that out 2022-10-27 02:42:00 one of the few dt_needed tracing distros i suppose :) 2022-10-27 02:42:03 it's not that fancy 2022-10-27 02:42:08 thank you for the tip about rootbld, that's useful 2022-10-27 02:55:01 elly: fyi the 18d1:5026 titan key is in 70-u2f.rules from `libfido2` just with group=plugdev instead :) 2022-10-27 02:55:14 sadly none of that is documented anywhere for where anything comes from really 2022-10-27 02:56:24 that's good to know! I didn't know libfido2 existed 2022-10-27 02:56:34 nor really expect to need to install it for my security key to work 2022-10-27 02:56:55 there's a chance systemd has the rules somewhere in.. itself 2022-10-27 02:57:10 eudev isn't exactly up to date on any hwdb/rules definitions 2022-10-27 02:57:26 u2f rules instead seem to be shipped by libfido weirdly 2022-10-27 02:57:41 and even weirder there's actually a dupe https://pkgs.alpinelinux.org/contents?file=70-u2f.rules&path=&name=&branch=edge&arch=x86_64 2022-10-27 02:57:42 hah 2022-10-27 02:58:22 sounds like a helpless shrug situation to me, I'm just glad I was able to figure out what was wrong in the first place 2022-10-27 02:59:00 yep 2022-10-27 02:59:06 lots of these small pain points 2022-10-27 03:00:57 chrome://device-log is *invaluable* for figuring out why chromium is upset about things 2022-10-27 03:01:47 thank you for extremely quickly reviewing my PR! now I suppose some CI pipeline builds and publishes binaries and then they become installable? 2022-10-27 03:04:24 ah, there it is! excellent :D 2022-10-27 03:09:57 :) 2022-10-27 03:10:18 yeah, the builders are on build.alpinelinux.org 2022-10-27 03:10:25 not the greatest site but it's current progress 2022-10-27 03:10:30 (and currently half broken as you'd see) 2022-10-27 03:10:37 then repo sync is every 15 minutes or so 2022-10-27 03:10:58 after upload, upload at end of a repo build (i.e. community/ testing/ main/ etc) 2022-10-27 03:11:09 gotcha 2022-10-27 03:47:06 ncopa: fyi that gslice glib removal causes G_DEBUG=gc-friendly to segfault some apps using libadwaita gtk_text_view(or something like that) 2022-10-27 06:56:29 oh thats interesting. do you have a reproducer? 2022-10-27 06:59:24 hi all! I'm not sure, but it seems build-edge-aarch64 is stuck on community/dotnet6-build 6.0.110-r2: https://build.alpinelinux.org/ can maybe somebody check on the server if it's still running? 2022-10-27 07:19:56 ollieparanoid: seems like it continued now 2022-10-27 07:20:30 ah indeed, thanks 2022-10-27 12:46:18 elly: people are still playing - and maintaining - angband in 2022? that's wonderful! :D 2022-10-27 13:16:29 skarnet: oh yes :) 2022-10-27 14:13:33 ncopa: libadwaita testsuite, or G_SLICE=gc-friendly spot 2022-10-27 14:13:38 er 2022-10-27 14:13:40 G_DEBUG 2022-10-27 14:13:49 you can try things linked against libadwaita, half of them failed with it 2022-10-27 14:13:53 spot being apk add spot 2022-10-27 14:14:34 is there a good way to package things that have no actual release tarballs, but only a git repo? 2022-10-27 14:14:36 i'm not sure if it's an issue of some edge case hit with the gc-friendly 0 memset overwriting memory it doesn't own due to some size issues or if it's actually an application error and they pass the wrong size 2022-10-27 14:14:41 elly: what repo 2022-10-27 14:14:57 in this specific case, cproc: https://git.sr.ht/~mcf/cproc/tree 2022-10-27 14:15:00 (and if they pass the wrong size then it would zero some random stuff and fail, of course) 2022-10-27 14:15:26 you can get tarball from github 2022-10-27 14:15:33 elly: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/36355 2022-10-27 14:15:35 just copy that 2022-10-27 14:15:57 which above MR does 2022-10-27 14:16:00 even sr.ht does tarballs though i think 2022-10-27 14:16:09 i just forgot the syntax 2022-10-27 14:16:12 but that would mean connecting to sr.ht, ew 2022-10-27 14:16:54 ah, I didn't know you can get tarballs from github like that for packages with no releases 2022-10-27 14:17:14 convenient indeed 2022-10-27 14:17:22 they don't get any submodules or stuff of course 2022-10-27 14:17:25 just current git repo state 2022-10-27 14:17:28 you can get tarball for any ref 2022-10-27 14:17:35 so normally release tarballs would have actual autoconf already ran, etc 2022-10-27 14:18:02 right 2022-10-27 15:08:38 yeah, tarballs from github aren't a good idea for autotools-using programs if you want to avoid having autotools on your builder 2022-10-27 16:59:44 my package is currently failing to pass tests but only on 32 bit arm architectures 2022-10-27 16:59:45 https://gitlab.alpinelinux.org/eddsalkield/aports/-/pipelines/141582 2022-10-27 16:59:53 this is a known issue: https://github.com/jgaeddert/liquid-dsp/issues/146 2022-10-27 17:00:17 should I disable those arches, or somehow disable the checks on those ones? 2022-10-27 17:01:40 Is it the tests self that are broken, or would it affect the application itself? 2022-10-27 17:31:07 ncopa: also fyi gdc is broken due to whatever is happening in #14109 which means ldc fails to build on 3.17 2022-10-27 18:11:29 craftyguy: fyi community/tootle doesn't build with new vala anymore but it also seems to be archived and dead upstream 2022-10-27 18:14:12 great 2022-10-27 18:15:07 RIP useful mastodon client on linux mobile 2022-10-27 18:15:19 hmm no explanation about why it is archived 2022-10-27 18:15:23 Ah yes Tootle is a dead project 2022-10-27 18:15:51 DylanVanAssche: did you see that somewhere? 2022-10-27 18:16:06 or just inferred by the lack of upstream activity 2022-10-27 18:16:13 (and well, now that it's archived, heh) 2022-10-27 18:16:17 craftyguy: Ironically, it was on Mastodon posted by Linmob 2022-10-27 18:16:21 i can probably get it to compile if you really want me to :p 2022-10-27 18:17:16 DylanVanAssche: lol 2022-10-27 18:18:34 psykose: if you know of a "quick fix" for keeping it around, I'd be grateful. I'll consult with my pmOS colleagues about what to do, since I'm unaware of any other native mastodon client that's usable on phones, so dropping it would be unfortunate. but I don't think anyone wants to maintain a vala project... so... 2022-10-27 18:22:05 sure, fixed and merged :) 2022-10-27 18:22:40 ah :) 2022-10-27 18:48:21 the most active fork seem to be https://github.com/spaetz/tootle 2022-10-27 18:49:02 so maybe ask spaetz about it? 2022-10-27 18:50:24 hi all, is there a reason why gtk+2.0 hasn't yet been built for aarch64? 2022-10-27 18:52:34 craftyguy: https://github.com/spaetz/tootle/issues/5 2022-10-27 18:54:37 because the aarch64 builders are stuck on openjdk 2022-10-27 18:54:46 and in the middle of that i moved gtk so it got deleted first.. 2022-10-27 19:01:22 omni: thanks 2022-10-28 05:39:59 bratkart-: anything I can do to help with the openjdk builds? it is blocking our aarch64 and ppc64le edge builders 2022-10-28 05:47:03 looks like we have 12 different openjdk versions. openjdk7 -> openjdk19 2022-10-28 05:47:42 do we really have resources to maintain all that? 2022-10-28 06:02:29 ncopa: i'm currently looking into the s390 build error, haven't checked on the aarch64 / ppc64le builds yet 2022-10-28 06:02:48 so yes, some help with them would be highly appreciated 2022-10-28 06:04:05 as building openjdk X requires version (X-1) to build we have to keep them all up and building, sadly 2022-10-28 06:04:25 (why keeps my name changing, pretty annoying?) 2022-10-28 06:12:17 is openjdk 6 required to build 7? 2022-10-28 06:18:32 no. openjdk7 uses gcc 2022-10-28 06:21:53 ah ok 2022-10-28 06:21:54 "WARNING: C and C++ compiler have different version numbers" 2022-10-28 06:22:05 https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/openjdk10/openjdk10-10.0.2_p13-r4.log 2022-10-28 06:22:22 ti openjdk build for 3.16 does not have that warning 2022-10-28 06:22:28 https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/openjdk10/openjdk10-10.0.2_p13-r4.log 2022-10-28 06:22:45 https://build.alpinelinux.org/buildlogs/build-3-16-ppc64le/community/openjdk10/openjdk10-10.0.2_p13-r3.log 2022-10-28 06:23:37 i see the warning in both logs? 2022-10-28 06:24:20 ah, you are right 2022-10-28 06:24:48 have seen it a couple of times, i think it's a false positive as the version information also contains a disclaimer 2022-10-28 06:25:06 seems like that 2022-10-28 06:25:19 anyway, i've managed to track the s390 error back to a so called "SafeFetch32" function 2022-10-28 06:25:22 trying to reproduce the build fail in my dev env 2022-10-28 06:26:14 after patching that generated method to a static version (introduced in java 19) to actually get some insights, i've managed to get a SEGV 2022-10-28 06:26:26 and now i'm totally lost how this could ever work: https://pastebin.com/y3D2Jhmt 2022-10-28 06:27:05 SafeFetch32 (adr=0xabc0000000000abc, errValue=2748) <<-- access mem at 0xabc0000000000abc obviously is a segfault, so how could the test_safefetch32() even work? 2022-10-28 06:28:55 probably it is supposed to segfault 2022-10-28 06:30:49 how could this ever work? i mean, the test_safefetch32() is called from JavaMain -> InitializeJVM, so every new jvm would immediately crash. Or is there a way for an application I don't know to work around SEGV signal? 2022-10-28 06:32:02 strange, have to dig deeper 2022-10-28 06:40:39 ppc64le openjdk10 builds using openjdk9 from dl-cdn 2022-10-28 06:40:53 im rebuilding openjdk9 in my dev env now 2022-10-28 06:45:20 >>> Size difference for openjdk9-jre: 2136 KiB -> 2364 KiB 2022-10-28 06:45:27 >>> Size difference for openjdk9-jre-headless: 158 MiB -> 160 MiB 2022-10-28 06:45:37 >>> Size difference for openjdk9-jdk: 724 KiB -> 2180 KiB 2022-10-28 06:47:32 that is the diff of openjdk9 on dl-cdn and locally built 2022-10-28 06:48:20 i wonder how it can grow from 724 KiB -> 2180 KiB 2022-10-28 06:48:23 that is 3x 2022-10-28 06:49:59 changed gcc version? 2022-10-28 06:50:03 bratkartoffel: have you tried just continuing 2022-10-28 06:50:19 yes, crashing afterwards 2022-10-28 06:50:23 (as expected) 2022-10-28 06:51:13 another interesing thing is, that without the "statically implemented SafeFetch32" stuff, I get an corrupted stack 2022-10-28 07:12:19 Hi, I am trying to build kernel. When I am trying make command after setting up menuconfig, I am facing this error. 2022-10-28 07:12:19 make[1]: *** No rule to make target 'arch/x86/entry/syscalls/syscall_32.tbl', needed by 'arch/x86/include/generated/uapi/asm/unistd_32.h'. Stop. make: *** [arch/x86/Makefile:217: archheaders] Error 2 2022-10-28 07:13:45 I am using linux-headers-5.15.74.0-lts 2022-10-28 07:53:39 asdf: you shouldnt need linux-headers for building kernel 2022-10-28 07:54:30 it smells like a bug in linux sources 2022-10-28 07:56:05 ok, so openjdk10 problem on ppc64le 2022-10-28 07:56:16 rebuilding openjdk9 makes openjdk10 fail 2022-10-28 07:56:38 using current openjdk9 binary from dl-cdn makes build of openjdk10 work 2022-10-28 07:56:46 so, it seems like openjdk9 is broken 2022-10-28 07:57:02 i think same thing breaks aarch64 but with opendjk10 -> 11 2022-10-28 07:58:29 as far as i can see, openjdk9 9.0.4_p12-r6 didn't build for ppc and aarch yet 2022-10-28 07:58:47 on these arches r4 is still in use 2022-10-28 07:59:12 some some change between r4 and r6? maybe gcc or musl related? 2022-10-28 08:01:20 thats what im thinking 2022-10-28 08:01:29 i've also finally had some success: 11.0.15 (cc9165fa7980f9f8af4b85dd191710dde1b8d4b1) builds fine on s390x, but the upgrade to 11.0.16 (0061970b7afa17da007044973cb45245e6dad2be) broke it somehow 2022-10-28 08:02:23 huh 2022-10-28 08:03:14 ok, so it might be a regression in 11.0.16? 2022-10-28 08:03:40 looks like it, yes. i guess some changes from the giant "build.patch" didn't make it upstream, resulting in the failures. have to dig deeper this evening, now it's finally time to get to work 2022-10-28 08:04:25 that sounds plausible. thank you very much so far 2022-10-28 08:33:21 aha! 2022-10-28 08:33:47 i think i knokw what changed between the openjdk builds 2022-10-28 09:02:17 asdf: i think you need provide us with more detail on exactly what you are trying to do 2022-10-28 09:03:40 oh great... now also openjdk9 fails to build in my env 2022-10-28 09:05:41 i though it could be the bash 5.1 -> 5.2 that coul dhave triggered it, but now openjdk9 fails to build with bash 5.1.16 2022-10-28 09:44:19 i really wouldn't use bash 5.2 yet 2022-10-28 09:44:22 it's filled with bugs 2022-10-28 09:44:24 can you show me the lo? 2022-10-28 09:44:26 *log 2022-10-28 09:44:30 psykose: i forgot btw but DT_RELR is completely uneventful and good shit 2022-10-28 09:44:32 i forget im using it 2022-10-28 09:46:44 i don think its bash 5.2 this time 2022-10-28 09:46:57 it fails even with bash 5.1.16 2022-10-28 09:47:02 could you show me the log anyway? 2022-10-28 09:47:09 (but i definitely wouldn't put bash 5.2 in 3.17) 2022-10-28 09:47:24 https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/openjdk10/openjdk10-10.0.2_p13-r4.log 2022-10-28 09:47:52 aarch64 has similar error but when building openjdk11 2022-10-28 09:48:33 for ppc64le, when using openjdk9 from https dl-cdn to build opendjk10 it passes 2022-10-28 09:48:52 when rebuilding opendjk9 from edge and use that openjdk9 to build openjdk10, it fails 2022-10-28 09:49:05 huh 2022-10-28 09:49:17 so apparently, something is breaking openjdk9 2022-10-28 09:49:22 im testing older gcc now 2022-10-28 09:49:43 gcc was updated since previous successful build 2022-10-28 09:50:17 could also be things like sed or grep or file 2022-10-28 09:50:19 i dont know 2022-10-28 09:50:24 or binutils 2022-10-28 09:52:30 I wish the error was better 2022-10-28 09:52:38 it looks like alpine hit it before when googling, a year ago 2022-10-28 09:59:27 alright!!! 2022-10-28 09:59:43 building openjdk9 with gcc 11 makes openjdk10 build pass 2022-10-28 10:00:21 this start to smell like a gcc issue, or openjdk issu triggered with gcc update 2022-10-28 10:00:22 woah 2022-10-28 10:01:23 woah indeed 2022-10-28 10:02:06 building openjdk10 now with latest gcc but with openjdk9 built with gcc11 2022-10-28 10:10:58 ok, that passed 2022-10-28 10:27:18 testing to build openjdk9 with -O2 now 2022-10-28 10:32:05 ok, -O2 did not make any diff 2022-10-28 12:27:47 I hate so much packaging git only with subrepos 2022-10-28 12:31:21 java spits out this: https://tpaste.us/d4pw 2022-10-28 12:58:00 i wonder if could drop unsupported openjdks 2022-10-28 12:58:50 the entire java ecosystem should be dropped 2022-10-28 12:58:57 i dont think we can 2022-10-28 12:59:57 are there tools in our base that require java < 17 which are not retro compat? 2022-10-28 13:00:59 i have no idea 2022-10-28 13:01:12 but i think what we do now does not work 2022-10-28 13:14:56 bratkartoffel: i wonder if we could: 1) add provides=openjdk11-jdk-bootstrap to openjdk11 and then use that as dependency for openjdk11 2022-10-28 13:15:20 then we keep openjdk8, openjdk11 and openjdk17 and newer 2022-10-28 13:15:34 and drop 9, 10, 12, 13,14,15,16 2022-10-28 13:17:00 how can we handle new minor releases, like the currently running 3.17, then? 2022-10-28 13:17:38 i have not problem dropping unsupported versions, i'd love to get rid of them 2022-10-28 13:18:27 for openjdk11 on s390x: issue was introduced with https://github.com/openjdk/jdk11u/commit/987f7af5f2186426543f90c328d1ce018c66c37b 2022-10-28 13:18:53 the argument to alloca() could be 0, resulting in the stack smash / SEGV / stack guard fails as seen 2022-10-28 13:19:16 fixed only in openjdk17 (and not backported to openjdk11) with https://github.com/openjdk/jdk/commit/341f676066ab807d433f0f0b6c8356d2ad0e1cc9 2022-10-28 13:19:33 !37676 2022-10-28 13:22:04 bratkartoffel: you are a genious! 2022-10-28 13:23:16 thanks. i hope i won't have to bisect two java releases any time soon :) 2022-10-28 13:23:58 couldn't have done it without your lxc container, so thank you for that. you may take it down now if you need the ressources back 2022-10-28 13:24:08 that MR does not look correct 2022-10-28 13:24:27 yes, gitlab shows it really strance 2022-10-28 13:24:36 /s/strance/strange 2022-10-28 13:24:46 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/37676/diffs does not show the backport fix 2022-10-28 13:25:10 yes, but looking at the commit directly it shows the correct diff 2022-10-28 13:25:13 maybe a gitlab issue? 2022-10-28 13:25:33 apparently. i merged it 2022-10-28 13:25:36 *awesome* 2022-10-28 13:35:34 Is it the tests self that are broken, or would it affect the application itself? 2022-10-28 13:36:03 Looks like the application works (supposedly): https://liquidsdr.org/blog/raspberry-pi3-benchmarks/ 2022-10-28 13:36:22 It's the tests themselves that are broken (or edge cases of the software, I can't tell) 2022-10-28 13:38:46 ikke: do you think we should delete bratkartoffel's s390x machine? 2022-10-28 13:43:04 it wouldnt surprise me if this also solves teh openjdk9 and 10 2022-10-28 13:48:19 im literally holding my breath now... 2022-10-28 13:50:06 noooooooooo it didnt pass 2022-10-28 13:51:20 /o\ 2022-10-28 13:53:52 ncopa: it did on s390x, didn't it? 2022-10-28 13:54:30 as the introducing fix was only applied to 11 and 17, it won't fix the other issues on 9 and 10 i think 2022-10-28 14:17:18 so, i thought it might have to do with gcc optimizing out (or stop optimizing out) 2022-10-28 14:17:30 i think somethign like this could have caused segfault at runtime 2022-10-28 14:17:48 was s390x a buildtime error or runtime? 2022-10-28 14:22:01 but yeah 2022-10-28 14:25:22 oh, i can reproduce it byt rebuilding openjdk9 with itself. I dont need build openjdk10 2022-10-28 14:25:40 i accidentally built openjdk9 with openjdk9 instead of 8 2022-10-28 14:30:57 ncopa: the error was runtime 2022-10-28 14:31:42 I think I 'll create a container for you on the ppc64le host (unless ikke has time to do so) 2022-10-28 14:32:46 I'd have time in ~30 minutes 2022-10-28 14:33:41 👍 2022-10-28 14:34:36 https://twitter.com/strudlzrout/status/1585999488225005568I'll try those meanwhile 2022-10-28 14:34:54 right now i'm testing to commenting out the alloca and see what happens 2022-10-28 14:46:48 ok, simply commenting out alloca does not solve it 2022-10-28 15:05:34 YES!!!!!! 2022-10-28 15:05:38 \o/ 2022-10-28 15:07:21 -fno-delete-null-pointer-checks -fno-strict-aliasing seems to solve it 2022-10-28 15:16:50 w00t 2022-10-28 15:19:05 bratkartoffel: do you still need a ppc64le container? 2022-10-28 15:23:48 fyi, we're going to upgrade the ppc64le host, so it will be unvaiable for a bit 2022-10-28 15:26:58 👍 2022-10-28 15:27:11 i logged out 2022-10-28 15:49:55 ncopa: there's still the gdc issue for ldc 2022-10-28 16:02:07 ikke: i think i don't need the ppc64le container then 2022-10-28 16:02:14 bratkartoffel: alright 2022-10-28 16:02:29 ncopa: congratulations, so openjdk is unblocked again? 2022-10-28 16:03:17 i'll enable s390x for openjdk{12-19} again, should be fine now 2022-10-28 16:04:22 yup! openjdk should be unblocked now 2022-10-28 16:04:57 psykose: do you have the details for the gdc issue for ldc somewhere? in some issue? 2022-10-28 16:05:21 libgphobos.so is somehow missing a symbol 2022-10-28 16:05:24 from gdc 2022-10-28 16:05:25 https://gitlab.alpinelinux.org/alpine/aports/-/issues/14109 2022-10-28 16:05:31 not really more details than that 2022-10-28 16:05:50 then on build https://build.alpinelinux.org/buildlogs/build-3-17-x86_64/community/ldc/ldc-1.30.0-r0.log 2022-10-28 16:08:27 ok 2022-10-28 16:08:35 might have a look at that next week 2022-10-28 16:08:56 but, there is also an upcoming openssl sec fix next week 2022-10-28 16:09:04 so i think we need to make stable releases 2022-10-28 16:09:23 would be great if the stable builders are all idle on monday 2022-10-28 16:48:32 Is there any way to tell apk to ignore /etc/apk/interactive for this invocation only? 2022-10-28 17:08:19 don't think so 2022-10-28 17:18:07 yes|apk ... ? 2022-10-28 17:19:33 ah the classic 2022-10-28 17:19:36 :) 2022-10-28 18:01:42 sam_: yeah, sadly won't make it for 3.17 2022-10-28 18:01:46 but hopefully right after :) 2022-10-28 18:01:54 benign free optimisations are my favority 2022-10-28 18:01:56 favorite* 2022-10-28 18:02:28 sam_: have you tried passing it to RUSTFLAGS? RUSTFLAGS="-C link-arg=-Wl,.." or something 2022-10-28 18:02:39 since rust uses cc to link after and invokes a real linker in the end 2022-10-28 18:02:59 i'd assume rust exes can also end up with dt_relr savings 2022-10-28 18:03:11 wonder if go is implementing it? 2022-10-28 18:04:51 sam_: also, any really bad bash 5.2 bugs? we don't actually use it as a base shell or for anything really, aside from some builds, and so far for that it's fine, so if it's only some edgecases it would b ok 2022-10-28 18:05:13 i don't mind just backporting the 5.2.x whatever fixes after 2022-10-28 18:06:10 ncopa: improving openjdk to keep only lts versions has another bonus 2022-10-28 18:06:15 we can add it to riscv64 probably 2022-10-28 18:06:29 the current issue is gcj-compat needs gcc6, but gcc7 is the first version with riscv support 2022-10-28 18:06:48 if we do the copying each release of just 11, 17, etc then we only have to figure out some way to build it on riscv once 2022-10-28 18:06:56 and then we can get chromium on riscv i guess 2022-10-28 18:07:42 i guess i could try and figure out a riscv build (if it's even supported, didn't check), but it would require moving to this other system as a guarantee 2022-10-28 18:08:50 i guess we would keep 8,11,17 and the new 18,19 etc short-versions for convenience 2022-10-28 18:08:57 still a much smaller load than now 2022-10-29 06:18:06 openjdk is not yet supported on riscv64 now, but the port is in development: https://github.com/openjdk/riscv-port 2022-10-29 06:20:28 and, theoretically, adding a new arch should not be that hard. we only need a bootstrap jdk (usually version x-1) to build a jdk. but it's no problem to use a jdk from another arch as the compiled java classes are platform independant. so if we could get binfmt (qemu-static) and allow apk to install aports from other archs, then it shouldn't be that hard to make it work 2022-10-29 06:38:29 should i bump pkgrel when enabling jdk12+ on s390x? or will it also be built if pkgrel stays the same? 2022-10-29 06:41:46 It will build it if it's missing 2022-10-29 06:43:14 the riscv builder is already x86_64 with binfmt enabled 2022-10-29 06:46:32 installing packages from a different arch is less trivial, though 2022-10-29 07:47:08 ikke: great, that makes it easy to bootstrap openjdk riscv once it arrives 2022-10-29 12:42:37 !40772 is ready for merge, altough the pipeline fails on ppc64le (known) and x86_64 (unknown why, i think too large job) 2022-10-29 12:43:30 Why is it a known failure on ppc64le? 2022-10-29 12:44:17 ncopa was on it yesterday, wasn't he? 2022-10-29 12:46:05 In any case, maybe we want to wait for this until after the openssl fix? 2022-10-29 12:46:29 ie, to make sure the builders are idle on monday 2022-10-29 12:47:28 sure, openssl is way more important 2022-10-29 12:49:01 on x86_64, openjdk13 fails to build 2022-10-29 12:49:44 https://tpaste.us/x5x7 2022-10-29 12:56:55 have seen the "connection refused" before, but only sporadic and only on the gitlab pipeline 2022-10-29 12:57:18 haven't been able to reproduce it locally yet, gave up after 20 builds 2022-10-29 12:57:54 Any idea where it would be trying to connect to? 2022-10-29 12:58:13 has something to do with the "sjavac server" 2022-10-29 12:58:46 sjavac is a wrapper for javac to speed up building 2022-10-29 12:59:03 afaik only used within the jdk build itself, never seen it in the wild 2022-10-29 12:59:23 https://bugs.openjdk.org/browse/JDK-8203164 2022-10-29 13:01:27 That one is not listed to affect openjdk13 though 2022-10-29 19:34:07 the gitlab builders for 3.15 are still broken? 2022-10-29 19:34:52 !40384 and !40387 are ready for merge 2022-10-29 19:43:00 yeah, until ikke changes the container setup 2022-10-29 20:03:39 Or until we allow the packages to replace each other 2022-10-30 04:20:05 hmm, chromium is quite crashy 2022-10-30 04:20:14 I haven't yet been able to get a useful stack trace out of it 2022-10-30 04:21:58 there's like two crashes i've ran into in practice, one completely random and in some dns code, and one in the music player widget top right (drag it after opening near the controls) 2022-10-30 04:22:05 the former i haven't seen in ages 2022-10-30 04:27:59 I saw the dns one earlier today I think! 2022-10-30 04:28:40 unfortunately it's hard to know what causes it 2022-10-30 04:28:47 I should start running under a debugger 2022-10-30 04:30:10 start with ulimit -c unlimited and you'll get a core 2022-10-30 04:30:37 then just gdb /usr/lib/chromium/chrome corefile with chromium-dbg musl-dbg installed 2022-10-30 04:30:44 or lldb which probably works better here in my experience 2022-10-30 04:30:48 the symbols are very minimal 2022-10-30 04:31:03 not really sure what causes the dns one 2022-10-30 04:31:24 i walked the stacktrace in my head through the dns code and it all looked ok but i'm not experienced enough with it 2022-10-30 09:37:14 qutebrowser seems pretty stable 2022-10-30 12:51:00 Before I could press Run Pipeline on MRs if artifacts were removed, but now I get permission denied. Is this policy changed? 2022-10-30 12:53:10 No, nothing explicitly changed 2022-10-30 12:54:06 Ah I'm not a member of the aports repo, that might be it. 2022-10-30 12:54:44 yes, you'd only be able to do it for pipelines in your own project (even if the MR is against alpine/aports) 2022-10-30 12:55:17 Ah that might be why I'm confused about this 🙂 Thanks! 2022-10-30 14:51:30 ghc on x86_64 has test failures: https://tpaste.us/KeYg 2022-10-30 16:52:42 i'd assume there's a bit more context 2022-10-30 16:52:48 but i guess nmeum would have to look at them 2022-10-30 16:57:07 yes, but I lost the output 2022-10-30 16:59:04 i've not tried DT_RELR with rust yet btw 2022-10-30 16:59:08 have you tried it anywhere 2022-10-30 17:00:44 not yet 2022-10-30 17:02:45 my random http thing went from 788 to 751 K 2022-10-30 17:03:12 works 2022-10-30 17:03:13 :) 2022-10-30 17:03:36 RUSTFLAGS="-C link-arg=-Wl,-z,pack-relative-relocs" added 2022-10-30 17:11:32 i think the ppc64le is stuck again on openjdk13, can someone kill it please? 2022-10-30 17:12:41 it is, but it gets repeatedly stuck 2022-10-30 17:12:45 either fails or gets stuck 2022-10-30 17:12:53 been restarted a bunch of times even since the changes 2022-10-30 17:21:20 what .mailmap file in aports is for? 2022-10-30 17:30:12 https://git-scm.com/docs/gitmailmap 2022-10-30 17:49:36 ok lemme try it too 2022-10-30 17:52:08 136.89MiB -> 132.27MiB (-3.38%) for uutils 2022-10-30 17:52:09 nice 2022-10-31 03:39:08 ddevault: hare-ssh fails with https://build.alpinelinux.org/buildlogs/build-3-17-x86_64/community/hare-ssh/hare-ssh-0_git20220616-r0.log 2022-10-31 07:27:17 hare-ssh is packed for alpine? 2022-10-31 07:27:19 it's not done 2022-10-31 07:27:51 oh, yeah, for the ssh-agent feature, that does work 2022-10-31 07:27:57 will look into it 2022-10-31 07:30:58 morning 2022-10-31 07:31:26 i killed openjdk on ppc64le and will have a look at fixing it (soon) 2022-10-31 07:33:22 why is abuild's LDFLAGS written as if it will be passed to CC, not LD? 2022-10-31 07:47:36 psykose: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/40834 2022-10-31 08:17:23 ddevault: because LDFLAGS are usually passed to CC 2022-10-31 08:17:36 is there some other variable which is usually passed to LD? 2022-10-31 08:17:53 every hare aport is going to end up needing `unset LDFLAGS` 2022-10-31 08:17:59 pretty silly to pass LDFLAGS to CC imo 2022-10-31 10:32:22 ddevault: that's the autotools convention, because people usually don't invoke ld directly, but via gcc. Yeah it's silly, but it is what it is. 2022-10-31 10:32:35 what do you reckon hare should do about this, then 2022-10-31 10:32:39 it uses ld but not cc 2022-10-31 10:33:07 then you need to translate $LDFLAGS from gcc syntax to ld syntax 2022-10-31 10:33:13 that's fucking horrible 2022-10-31 10:33:19 yeah 2022-10-31 10:33:25 I refuse 2022-10-31 10:33:39 you also have $LIBS that contains -lfoobar -lbazqux things and that is given at the end of the cmdline 2022-10-31 10:34:39 maybe abuild could detect hare in the makedepends and unset or rewrite LDFLAGS to make sense 2022-10-31 10:34:46 or could detect autotools and rewrite LDFLAGS to not make sense 2022-10-31 10:35:17 honestly ld is super low level and is not intuitive at all to figure out for the user who just wants to build stuff, so I'm surprised you don't already have a higher level interface for linking hare 2022-10-31 10:35:54 ld being driven by the compiler isn't the worst thing ime 2022-10-31 10:36:12 it probalby should be CCLDFLAGS to pass them to CC 2022-10-31 10:36:16 probably* 2022-10-31 10:37:06 maybe? but at this point it's better to use a new variable 2022-10-31 10:37:12 LDFLAGS_REALLY_LD_NOT_CC 2022-10-31 10:37:28 "gnu did something stupid in the 80's" is not really a good rationale for anything 2022-10-31 10:37:57 I'm not going to defend gnu, but a convention is only as good as the number of people who follow it 2022-10-31 10:38:12 or as bad 2022-10-31 10:39:49 honestly I'd go with HARE_LDFLAGS for direct ld options, and a translator for compat LDFLAGS (with annoying warnings) 2022-10-31 10:39:57 the translation isn't that hard 2022-10-31 10:40:47 not going to add a translator 2022-10-31 10:40:58 might add a downstream hare patch which renames it to GNU_SUCKS_LDFLAGS or something 2022-10-31 10:42:29 go ahead, I have a header file named bsdsnowflake.h so I'm not gonna judge 2022-10-31 10:46:41 actually, this solution is untenable since third-party projects might incorporate LDFLAGS into a Makefile or something, including one of my own 2022-10-31 10:46:55 perhaps better to have abuild-hare, ala abuild-meson, which translates LDFLAGS via disgusting shell string munging 2022-10-31 11:18:44 POSIX requires that by default, make passes LDFLAGS to CC when compiling .c files: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html 2022-10-31 11:19:10 i'm inclined to say that gnu did not invent this convention 2022-10-31 11:24:03 yes. it is well established standard 2022-10-31 11:28:12 I agree that it is a *confusing* convention, and it would be better if the linker driver was called CCLD and its arguments were called CCLDFLAGS, but I reckon it's definitely too late to change make 2022-10-31 11:39:52 if I have two packages with `provides="foo=$pkgver"` with different $provider_priority can I depend on the virtual package foo with a version constraint (e.g. `depends="foo>=0.6.0"`? I would expect the apk solver to consider the version constraint first and if both packages match the version constraint I would expect the solver to select the one with the higher $provider_priority. does it 2022-10-31 11:39:52 work like that? 🤔 2022-10-31 11:43:34 ha, I didn't even think to check the posix make spec 2022-10-31 11:43:47 (most of the time it's useless) 2022-10-31 11:44:36 nmeum: no idea :) 2022-10-31 11:46:20 my experiments indicate that it does kind of work 2022-10-31 11:46:25 I guess i will need to read the apk code 2022-10-31 11:52:05 rbspy does not build at all with recent rust 2022-10-31 11:52:42 https://github.com/rbspy/rbspy/issues/368 2022-10-31 11:54:03 ncopa nmeum ghc had some test failures on x86_64 2022-10-31 11:54:16 when trying to bootstrap it 2022-10-31 11:55:12 during the cross-compiled build with bootstrap.sh? 2022-10-31 11:56:19 no, not cross-compiling 2022-10-31 11:56:35 building with ghc-bootstrap 2022-10-31 11:56:54 https://tpaste.us/KeYg 2022-10-31 11:56:58 I don't have any more output 2022-10-31 11:57:35 hm, the output is not very helpful :D 2022-10-31 11:59:29 I had it in a tmux session and the details were already out of the buffer 2022-10-31 12:02:01 where does ghc-bootstrap originate? is it a ghc version installed from edge or the cross-compiled version from bootstrap.sh? 2022-10-31 12:04:24 From edge 2022-10-31 12:05:27 I'll try again later and save the build log 2022-10-31 14:28:15 bratkartoffel: looks like we have another issue with openjdk15. when built with gcc12 it fails to build openjdk16 2022-10-31 14:28:36 seems like it gets int type mixed up somehow 2022-10-31 16:13:26 bootstrapping ghc on x86_64 again 2022-10-31 16:53:42 every single thing in aports sans some go and D stuff expects LDFLAGS to be passed to CC 2022-10-31 16:53:47 apologies but that's just how it is 2022-10-31 16:54:05 you'd have to go back 20 years to change that 2022-10-31 16:54:28 every distros LDFLAGS are the CC style, except for the ones that have a million of them with a lot of magic per language, etc 2022-10-31 16:55:38 (it's also literally what posix make does, so..) 2022-10-31 16:55:54 it's on you to change it to something else and not use LDFLAGS if it's not CC 2022-10-31 17:08:41 where I can find 3.17 release notes draft - gonna merge !40865 and mention there 2022-10-31 17:09:06 don't have one yet 2022-10-31 18:30:14 nmeum: https://build.alpinelinux.org/buildlogs/build-3-17-x86_64/community/ghc/ghc-9.0.2-r1.log