2024-06-01 06:31:06 Hi 2024-06-01 06:31:23 It seems that last webkit2gtk upgrade is broken 2024-06-01 06:31:43 /usr/libexec/webkit2gtk-4.1/MiniBrowser 2024-06-01 06:31:43 ** (MiniBrowser:11630): WARNING **: 08:30:40.531: WebProcess CRASHED 2024-06-01 06:31:52 Doing nothing, just starting it 2024-06-01 07:42:06 Can somebody reproduce the issue? 2024-06-01 07:44:16 Yep, does the same crap here. 2024-06-01 07:48:39 ok, thanks zcrayfish :) 2024-06-01 07:54:17 np 2024-06-01 07:57:27 quinq: could you open an issue? 2024-06-01 08:08:54 Invalid login or password. 2024-06-01 08:08:55 :( 2024-06-01 08:10:32 Password is too short (minimum is 12 characters) 2024-06-01 08:10:41 Damn, who remembers 12-character passwords 2024-06-01 08:13:19 A password manager could be a good investment. 2024-06-01 08:14:00 oh, right, noting down passwords on a piece of paper :D 2024-06-01 08:14:36 lol 2024-06-01 08:15:44 “but my paper note is with my other password notes inside my safe that has a single other password!” 2024-06-01 08:16:15 "the dog ate my password" 2024-06-01 08:17:07 jaja yeah, the alternative is “I'm too drunk to remember my bank card pin and the machine ate it” 2024-06-01 08:19:24 Which project out of the ~100 available should I open the issue in? 2024-06-01 08:21:30 aports 2024-06-01 08:23:33 Thanks 2024-06-01 08:27:01 Done :) 2024-06-01 09:43:57 Hello, i have a question about the provided iso 2024-06-01 09:44:00 's 2024-06-01 09:44:17 Whats the problem with just starting net on boot? 2024-06-01 09:45:16 there's no config for how net should work though 2024-06-01 09:45:53 Huh? just setting eth0/wlan as up and starting dhcpcd should be enough, no? 2024-06-01 09:46:01 and then in the installation asking for wifi 2024-06-01 09:56:36 that would be undesired sometimes when you're setting up a server 2024-06-01 10:01:07 okay..... 2024-06-01 13:04:48 ptrc: is it maybe possible to move forgejo to community. now that 7.0.x has been released 2024-06-01 16:50:18 fossdd: actually, sure, i'll do one last sanity check if everything is alright ( service files, placement, etc. ) and move it 2024-06-01 16:51:25 ah, thats great! thanks 2024-06-01 17:58:22 celie: if you're curious https://lambdacreate.com/paste/sbcl-2.4.4-sb-ext-int-change.txt this commit from sbcl is the cause of the compilation issues with nyxt. 2024-06-01 17:58:49 we don't have a lot of lisp packages, but if you see something similar down the line there's a good chance that changing sb-ext to sb-int will fix it 2024-06-01 18:03:14 ptrc: please ignore the webkit2gtk flag, accidentally sent the unstable version 2024-06-01 18:05:30 sorry about that 2024-06-02 02:08:15 durrendal: Thanks :) 2024-06-02 10:42:49 ikke: could you also dd me to the guest role? would be pretty usefull ig 2024-06-02 10:42:56 sure 2024-06-02 10:43:17 done 2024-06-02 11:45:54 great thx 2024-06-03 11:50:08 i switched now my workflow to abuild rootbld 2024-06-03 15:39:19 Hello, hope this is the right place for this question, if not please let me know. I'm trying to use abuild-sign to sign a new index using a key I've installed manually (didn't use abuild-keygen). I've recently started getting an issue with the signature no longer being trusted. 2024-06-03 15:39:48 Mweya: one thing is to make sure the key names match 2024-06-03 15:41:38 Thanks for the super fast response! I'm pretty sure they do as this pipeline worked without issue recently, with no changes to it in the last year. Has something changed with regards to the process for installing keys as documented at the bottom of: https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers 2024-06-03 15:42:48 No, not that I'm aware of 2024-06-03 15:43:21 Alright, I'll have another look at this tomorrow then. Thanks for the help! 2024-06-03 18:37:55 Could someone look at this: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/164 2024-06-04 03:57:54 wiki says: To specify a conflicting package, add the package name prefixed with a '!'. 2024-06-04 03:58:43 what does "conflicting" mean? 2024-06-04 03:59:09 package that can't be installed at the same time 2024-06-04 04:01:29 what if two pkg both have one binary same name? 2024-06-04 04:02:46 I don't know alpine's policy but that's a common reason for making something conflict 2024-06-04 04:02:46 (policy as in like, renaming one to remove the conflict) 2024-06-04 04:06:10 If they have the same binary, then abuild will make them provide the same "cmd:", and through that, they will already be conflicting 2024-06-04 04:14:33 Anyway, if you're thinking about !67083, why don't you see if it's possible to install the binary as "pfetch-rs" instead? 2024-06-04 06:03:48 🤔 2024-06-04 07:32:10 cely: i have renamed, it is an easy way to solve conflict :) 2024-06-04 07:33:00 :) 2024-06-04 07:33:19 but still don't understand what is conflicting :( 2024-06-04 07:34:42 It just means, when i install this package, i don't want the "conflicting" package installed at the same time 2024-06-04 07:35:07 So, 2 conflicting packages cannot be installed at the same time 2024-06-04 07:36:54 qaqland: sorry, i was too vague; in this case, packages that provide the same executable cannot be installed together by default 2024-06-04 08:10:42 ptrc: Very glad you pointed out my problem! 2024-06-04 12:59:27 Hello! I've got an issue when using abuild-sign to sign a package, more specifically: abuild-sign -k ~/.abuild/mykey.rsa -p mykey.rsa.pub APKINDEX.tar.gz <- This results in: ERROR: mypackage_1.1.0_aarch64.apk: UNTRUSTED signature 2024-06-04 13:00:22 The keys I'm using to sign have been added manually, with the pub key being copied to /etc/apk/keys/ 2024-06-04 13:01:51 I've looked through the docs at https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers but haven't found a solution to this. What's weird is that this is part of a pipeline which hasn't had it's code changed in a year and has worked before, with my current suspicion being that something might have changed in the abuild-sign tool 2024-06-04 13:02:03 Has anyone had and solved this problem before? 2024-06-04 13:07:15 Oh, just realized the docs might be out of date, https://wiki.alpinelinux.org/wiki/Abuild_and_Helpers doesn't list the -e option which exists here: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild-sign.in?ref_type=heads#L60 2024-06-04 13:32:25 Ah, sorry, looks like I thought the error above came from the wrong command. It seems to actually be thrown by: apk index -o APKINDEX.tar.gz *.apk 2024-06-04 13:47:10 is celeste/cielesti around here somewhere? 2024-06-04 13:47:30 Yes 2024-06-04 13:47:40 colona: 2024-06-04 13:47:44 celie: 2024-06-04 13:48:12 (sorry not colona) 2024-06-04 13:48:14 dependencies for community/tlp are going to change next release https://github.com/linrunner/TLP/pull/740 2024-06-04 13:48:42 how about cely? 2024-06-04 13:50:57 anyways, we hilighted all possible canidates, so someone is hopefully gonna react 2024-06-04 13:58:34 Ok, flock can be removed from depends=, anything else that needs to be changed? 2024-06-04 14:00:52 i think thats about it 2024-06-04 14:01:38 Alright, will keep that in mind, but if i forget, feel free to remind me 2024-06-04 14:02:00 *thumbs up* 2024-06-04 14:02:22 and thanks for telling me about that 2024-06-04 14:24:37 Has there been a change in the index command that now requires the apks to be indexed, to be signed? If so, I think that might be the issue! 2024-06-04 14:53:44 dne, hi! any specific reason for !66981? I'm not opposed, but I usually only submit backports when CVEs are involved 2024-06-04 14:54:38 oh wait 3.20, not 3.19. sure. 2024-06-04 14:54:42 fresh enough 2024-06-04 14:55:06 right, bug fixes was my thinking 2024-06-04 15:05:00 yes, makes sense 2024-06-04 15:05:12 and cely merged already, nice 2024-06-04 15:05:32 thanks! 2024-06-04 15:05:40 You're welcome 2024-06-04 23:02:38 edge firefox (after rebuild) will get either better jpeg decoding, or more broken jpeg decoding 2024-06-04 23:02:59 ( it's been building for ages with vendored libjpeg without SIMD, now it's the system one ) 2024-06-04 23:03:09 Funny superposition 2024-06-04 23:03:32 in theory it should work faster :P 2024-06-04 23:04:16 it will crash.. faster 2024-06-04 23:05:28 the faster is better 2024-06-04 23:05:35 hm english is borked 2024-06-04 23:06:10 alice: faster crashing is still faster! 2024-06-04 23:06:22 that's the spirit 2024-06-05 00:45:56 For new versions, we also gained: Ruby 3.3.1, Nim 2.0.4, QEMU 9.0.0..ah, i see Jirutka has already added the first 2 to the Wiki 2024-06-05 00:45:58 zcrayfish: i think there is no problem in bypassing testing as it's a dependency of aports in community 2024-06-05 00:46:00 Mark it as Draft or stop me here in the meantime if you have second thoughts 2024-06-05 00:46:00 Though now that you've made me aware of that MR being a prerequisite to the LXQt upgrade, maybe i'll just merge it in the next half an hour or so 2024-06-05 00:46:02 zcrayfish: your riscv64 CI job timed out because the timeout is by default 1 hour, you have to increase that in the settings page 2024-06-05 00:46:02 Skimming through the changes, they look alright, though someone will have to actually try out the CI artifacts to be sure they work out in practice 2024-06-05 00:46:04 I'll assign it to the maintainer, and maybe we can wait a few days to see if there's a response 2024-06-05 00:46:04 but as 3.20 was just branched, if you think nothing is broken too badly, maybe it can just be merged, though there is issue of maintainer approval (but i don't think we waited for that during the last upgrades) 2024-06-05 00:46:05 rip 2024-06-05 00:46:06 Since that's the case i wouldn't mind getting the changes in after waiting a few days 2024-06-05 00:46:06 That's good 2024-06-05 00:46:08 Anyway, lxqt-themes will need its pkgrel reset to 0 2024-06-05 00:46:08 and i'm a bit interested in what errors you see when Perl isn't included in makedepends 2024-06-05 00:46:10 (just curious why it's needed with this upgrade) 2024-06-05 00:46:10 Sure, thanks 2024-06-05 00:46:12 There will be a Perl upgrade pretty soon, so maybe the LXQt upgrade can be coordinated with that to make sure it still builds with the new Perl (i'm not expecting such breaking changes though, so maybe it doesn't matter so much) 2024-06-05 00:46:53 Seems like the Perl script it wants to run is this: https://github.com/lxqt/lxqt-build-tools/blob/master/cmake/modules/LXQtTranslateDesktopYaml.pl 2024-06-05 00:46:53 Perhaps it's https://git.alpinelinux.org/aports/tree/community/qt5-qtbase/APKBUILD 2024-06-05 00:46:53 I wonder if Perl should be made a runtime dependency of lxqt-build-tools instead of being added to the other aports 2024-06-05 00:46:53 which has Perl in depends_dev 2024-06-05 00:46:53 Looking at the build log for lxqt-build-tools: https://build.alpinelinux.org/buildlogs/build-3-20-x86_64/community/lxqt-build-tools/lxqt-build-tools-0.13.0-r0.log it seems something is already pulling in Perl as a dependency during build time 2024-06-05 00:46:54 That could explain why Perl needs to be added to makedepends of LXQt aports when switching from qt5-qtbase-dev to qt6-qtbase-dev 2024-06-05 00:46:54 qt6-qtbase has Perl in makedepends instead 2024-06-05 00:46:56 Unless you can find some other LXQt aport besides lxqt-build-tools with Perl scripts, i'd say it's good to add to depends of lxqt-build-tools 2024-06-05 00:47:04 I'll just rename the file in the APKBUILD 2024-06-05 00:47:06 Please be more careful next time 2024-06-05 00:47:06 I had another concern while looking through your MRs a few days ago, but i've forgotten what it was now 2024-06-05 00:47:08 I think the conclusion then was that it would be better if version 3 was added as a new aport instead of an upgrade 2024-06-05 00:47:08 There was some discussion regarding taskwarrior in this channel a few weeks ago 2024-06-05 00:47:10 is added* 2024-06-05 00:47:14 I'm about to go AFK, but came on to say, Thermi, can you please check if grommunio-gromix can be enabled on armhf 2024-06-05 00:47:16 Your MRs mix disabling archs with other changes 2024-06-05 00:47:16 This is the concern i had regarding your MRs that i mentioned 2 days ago 2024-06-05 00:47:18 On armhf, that is 2024-06-05 00:47:18 So, from what i see, grommunio-gromox is being built in CI against an old version of grommunio-common 2024-06-05 00:47:22 So, while CI is green, when your MR gets merged, grommunio-gromox may be unable to find the grommunio-common that you've just disabled on armhf 2024-06-05 00:47:22 and if that happens, it will block the builders 2024-06-05 00:47:24 and now i go AFK, please be more careful 2024-06-05 00:47:32 durrendal: Thanks :) 2024-06-05 00:48:19 celie: I already fixed riscv64 2024-06-05 00:49:47 Pretty sure that's just their bouncer acting up 2024-06-05 00:50:57 yeah that makes sense 2024-06-05 01:46:06 ACTION signs 2024-06-05 01:47:47 Sorry about silly bouncer acting up again 2024-06-05 01:51:13 It's all good, I fell for it \o/ 2024-06-05 02:23:42 had a bit of déjà vu for a moment there, it's fine ^^ 2024-06-05 07:06:18 if the APKBUILD does nothing with "pkgusers" and "pkggroups" does it still make sense to have it there or can it be removed? 2024-06-05 07:58:50 anywone can remember me how can I download a MR from gitlab, fixing it locally and pushing it on the same branch? 2024-06-05 07:58:58 so that the author does not change? 2024-06-05 08:01:17 I use glab 2024-06-05 08:01:35 glab mr checkout 2024-06-05 08:02:49 I use git fetch 2024-06-05 08:02:54 But you can also do that yes 2024-06-05 08:03:11 git fetch git@gitlab.alpinelinux.org:/aports.git : 2024-06-05 08:03:11 glab does that, but then automated 2024-06-05 08:03:34 git switch 2024-06-05 08:03:51 do your changes and then amend the commit 2024-06-05 08:04:08 git push -f git@gitlab.alpinelinux.org:/aports.git HEAD: 2024-06-05 08:05:44 Though with git fetch you have to actually find the remote branch, and can't go by MR number 2024-06-05 08:07:23 ikke, i've glab too. But the checkout fails since it checks toward my project, rather the project is alpine 2024-06-05 08:07:29 I mean: 2024-06-05 08:07:34 this is the MR i want to download: 2024-06-05 08:07:34 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50233 2024-06-05 08:07:46 glab mr checkout 50233 rather goes to: 2024-06-05 08:07:51 https://gitlab.alpinelinux.org/api/v4/projects/fcolista/aports/merge_requests/50233 2024-06-05 08:08:00 There is a config option and enc variable to fix that 2024-06-05 08:10:16 -R alpine/aports 2024-06-05 08:10:22 Probably try that 2024-06-05 08:10:40 fcolista: export GITLAB_REPO=alpine/aports for the environment variable 2024-06-05 08:11:48 Uh 2024-06-05 08:11:48 Wait 2024-06-05 08:11:50 That's my MR 2024-06-05 08:12:01 Can it wait for Perl 5.40? 2024-06-05 08:12:31 5.40.0 rc2 has just been released 2024-06-05 08:12:43 I expect this 5.40.0 to follow soon 2024-06-05 08:12:45 -this 2024-06-05 08:13:50 Enabling -Duse64bitint will require a rebuild of everything linked to libperl.so, which i am doing for 5.40.0 2024-06-05 08:14:30 !66188 2024-06-05 08:18:26 ikke, thx! 2024-06-05 08:18:46 cely, fine. I'll wait then 2024-06-05 08:18:52 Thanks all for your valuable suggestions! 2024-06-05 08:18:58 cely: hm, what's the use64bitint for 2024-06-05 08:20:29 It makes Perl's int 64-bit 2024-06-05 08:21:39 https://bugs.debian.org/310995 2024-06-05 08:22:16 only for 32-bit systems you mean? 2024-06-05 08:22:40 There are a few other options, but it seems use64bitint is the one that doesn't break things (at least from what i've read) 2024-06-05 08:22:42 Yes 2024-06-05 08:22:50 For 64-bit archs, that's already enabled 2024-06-05 08:23:11 and Debian also has that turned on for all archs 2024-06-05 08:23:48 sure, it's a no-op on 64 afaict 2024-06-05 08:24:01 There are quite a number of perl-* aports with !x86 !armhf !armv7 in arch= that will be unblocked with -Duse64bitint 2024-06-05 08:24:09 unblocked for those archs* 2024-06-05 08:24:10 makes sense 2024-06-05 12:46:48 could anyone help merge !67083 2024-06-05 12:51:58 Hi qaqland 2024-06-05 12:59:36 hi cely, my net lost just after see your "Hi" XD 2024-06-05 13:02:41 Well..how about you give me a reason (considering we already have lots of Rust aports): grepping through aports i see many that are disabled on Loongarch due to the "nix" crate, but most of those are also disabled on s390x due to that 2024-06-05 13:03:48 So, let's confirm whether it is working on Loongarch first, so later on i won't be looking at another MR with "disable Loongarch" 2024-06-05 13:05:59 how could i check it 2024-06-05 13:08:35 oh, it has nix: https://github.com/Gobidev/pfetch-rs/blob/main/Cargo.lock#L574 2024-06-05 13:08:47 I'll ask in #alpine-loongarch 2024-06-05 13:32:28 night 9:30 local time, they should be off work 2024-06-05 13:33:10 does alpine have pipeline builder for loongarch now? 2024-06-05 13:35:08 No, i think we are waiting for N Copa to come back from holiday to set that up 2024-06-05 13:46:33 And we need to figure where to host those servers 2024-06-05 13:49:23 I thought that was already decided? 2024-06-05 13:49:56 I mean, i thought the servers were already ready, and N Copa was already given SSH access 2024-06-05 13:50:44 i (thought) too 2024-06-05 13:50:56 or are you talking about the latest development where moving the servers to Europe was being considered 2024-06-05 14:32:03 ikke: any thoughts about https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/46 ? I was hoping that could help maintenance 2024-06-05 19:33:18 It looks like afl++ cannot be installed. It depends on lld~17, but lld is in version 18. The package lld17 does not provide lld~17. I guess it should do so, right? 2024-06-05 19:53:02 yes 2024-06-05 19:55:30 Ariadne: could you please look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66400? 2024-06-05 19:58:39 Thanks! 2024-06-05 21:38:45 regarding loongarch, i do have some questions about the port 2024-06-05 21:39:18 for example, who controls/hosts the hardware, and what precautions have been taken to protect the signing keys against unauthorized access by a state actor 2024-06-05 21:39:51 (i would have these questions about any other state-sponsored architecture where the builders are not necessarily controlled by alpine developers) 2024-06-05 21:41:07 while alpine does have some good trusted-keyring hygeine (like only trusting the arch-specific signing keys by default), the idea of a state actor controlling any alpine signing key is somewhat concerning to me 2024-06-05 21:42:03 if an alpine developer does physically control loongarch hardware then obviously this is not a concern, but otherwise we probably should be careful 2024-06-05 22:02:50 loongarch is an odd situation where the company producing it is effectively a state actor, so we should insulate ourselves from that situation by ensuring that the build infrastructure is controlled by alpine developers 2024-06-05 22:04:40 what state do they represent? 2024-06-05 22:08:54 china, but that part does not matter. we should be equally mindful of any other situation where infrastructure might be controlled by an entity relating to a state actor. for example, we hopefully would not create a situation where the NSA controlled alpine signing key materials 2024-06-05 22:10:21 from a technical point of view, i think loongarch is neat 2024-06-05 22:10:31 i was just curious, but yes I agree that any state could plausibly offer conflicts of interest that would be concerning for regular people 2024-06-05 22:11:15 but we should make sure we don't create a situation where we are handing over alpine signing key materials to a state actor :p 2024-06-05 22:11:29 yea, that should be common sense :P 2024-06-06 01:39:00 Hello! Trying to create a custom repository. For index files, I get a warning that dependencies are missing (because they are in a different folder/repository on my server), how can I fix this? 2024-06-06 01:40:34 warning is > WARNING: Total of 3 unsatisfiable package names. Your repository may be broken. 2024-06-06 01:41:00 I imagine this is handled on alpine main/community somehow? 2024-06-06 02:53:12 what command are you running? is anything actually broken? 2024-06-06 04:21:31 idts 2024-06-06 04:21:48 i ran `apk index *.apk -o APKINDEX.tar.gz` 2024-06-06 04:37:31 Riolku: you need to add --rewrite-arch 2024-06-06 04:43:44 Ariadne: they are in the process of sending us 3 servers. 2024-06-06 08:42:16 hi, there is one guy that tries to move some aports to comunity, Im not sure what is the correct way to handle this kind of situation? 2024-06-06 08:42:33 I have been assigned, and it seems I have permission to close the MR, do I have it? 2024-06-06 08:42:45 !67106 2024-06-06 08:43:46 I mean, maybe he is right, but Idk, thats what I'd like to discuss if possible 😅 2024-06-06 08:49:16 hello good people! 2024-06-06 08:49:32 hi 2024-06-06 08:51:37 I am looking to use gcc or clang with -pg support for profiling and it's complaining at linktime that ld cannot find gcrt1.o 2024-06-06 08:51:56 Is this a known issue or some oversight that can easily be fixed? 2024-06-06 08:54:02 it's not implemented by musl 2024-06-06 08:54:14 -pg links the gcrt1.o crt that then requires libc support for stuff 2024-06-06 08:54:38 i just perf instead normally though without frame pointers it would be a bit challenging 2024-06-06 08:55:36 alice: thanks! How do you "perf instead normally"? 2024-06-06 08:55:48 ah, hmm 2024-06-06 08:56:12 this is for a fuse based filesystem if that helps any 2024-06-06 08:57:03 this is a quite complex subject hehe 2024-06-06 08:57:10 you can see some perf record examples in https://brendangregg.com/perf.html 2024-06-06 08:57:19 one does not simply perf normally 2024-06-06 08:57:21 you'll need debug data of whatever you're profiling and like 2024-06-06 08:57:38 perf record --call-graph dwarf -F 100 -p 2024-06-06 08:57:43 then perf report/ other tools later 2024-06-06 08:57:55 but well then you have all the usual sampling profiler pitfalls 2024-06-06 08:58:04 i think -pg is not sampling 2024-06-06 08:58:21 also --call-graph dwarf is pretty bad but not like there's frame pointers on alpine 2024-06-06 08:59:56 the sad reality is it might be impossible to actually profile what you want to 2024-06-06 08:59:56 alice: thanks! 2024-06-06 09:00:00 but give it a shot 2024-06-06 09:00:13 musl-dbg has the libc dbg and then the fuse thing may or may not have a -dbg so you might have to rebuild it 2024-06-06 09:00:39 yeah, I know. But I have a need to prove to management that it's not our code that's slow - it's the other end that is. and there's a lot of ins and outs. 2024-06-06 09:01:01 aha :) 2024-06-06 09:42:34 good morning! im back! 2024-06-06 09:43:09 I have had a 1+ week off. completely off. 2024-06-06 09:43:20 what has happened last week? 2024-06-06 09:50:52 Welcome back 2024-06-06 09:59:21 wb! 2024-06-06 10:05:29 thanks! 2024-06-06 10:05:43 something is broken on my desktop workstation 2024-06-06 10:05:50 keyboard stopped work completely 2024-06-06 10:06:03 bluetooth connectivity broke 2024-06-06 10:06:10 i plugged cable, still not working 2024-06-06 10:06:16 so i ssh in to it 2024-06-06 10:06:26 and tried reboot 2024-06-06 10:06:35 it has used 5 mins now to shut down 2024-06-06 10:06:48 oh.. ! now it actually shut down 2024-06-06 10:17:06 oh no 2024-06-06 10:21:04 ncopa: we need a snapshot release for edge to mark the version as _alpha again 2024-06-06 10:21:16 ncopa: we get quite some bug reports with version being 3.20 but they are on edge 2024-06-06 11:25:35 ok 2024-06-06 11:25:41 let me do that first then 2024-06-06 11:26:16 all edge builders are idle 2024-06-06 11:26:19 let me tag it now 2024-06-06 12:33:23 ikke: that doesn't seem to work. command is `apk index -o APKINDEX.tar. gz *.apk --keys-dir ~/.abuild --rewrite-arch x86_64` 2024-06-06 12:33:59 ik 2024-06-06 12:34:44 Riolku: this is what abuild does: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1914-1915 2024-06-06 12:34:54 sorry 2024-06-06 12:34:56 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1934-1935 2024-06-06 12:37:22 lmao `--no-warnings` 2024-06-06 12:37:25 ok ty 2024-06-06 12:40:05 doesn't do anything except print no warnings 2024-06-06 12:41:27 Right as it says on the tin :) 2024-06-06 13:08:46 seems like the edge snapshot was not built? 2024-06-06 13:25:11 What happened? 2024-06-06 13:26:42 not sure 2024-06-06 13:27:09 i think I should have done an annotated tag, which I didnt 2024-06-06 13:27:33 I deleted the remote v20240606 tag 2024-06-06 13:27:42 but I'm a git afraid what happens on all the git mirrors 2024-06-06 13:28:11 They would keep the old unannotated tag 2024-06-06 13:28:47 at most there will be a discrapancy 2024-06-06 13:29:02 ptrcnull: I just updated my edge installation, and seems like webkit processes are crashing. I'm trying to build 2.44.1 and see if that fixes it 2024-06-06 13:29:20 Do you happen to know anything that might have gone wrong with the last update? 2024-06-06 13:29:25 PabloCorreaGomez[m]: trying to look at that MR today 2024-06-06 13:29:32 I am not totally sure if I was in 2.44.1 before. I'm hoping 2024-06-06 13:29:47 looks like tag got deleted on the mirrors as well https://github.com/alpinelinux/aports/tags 2024-06-06 13:29:53 #16173 2024-06-06 13:30:09 https://git.alpinelinux.org/aports/refs/ 2024-06-06 13:34:51 ikke: thanks for both! 2024-06-06 14:15:56 Are the CMAKE_CROSSOPTS lines still needed (i'm looking at !67290)? i think i've seen them being removed for some aports 2024-06-06 17:49:52 Hello, can someone please elaborate how package building/signing happens at Alpine? Over at OpenWrt we're in the phase of switching to APK v3 and wonder how we coordinate signing within a distributed build setup. Many of our builders are one-shots and we don't want to juggle to many keys around. Thanks! 2024-06-06 17:50:35 With APK v3 individual packages are signed and not "just" the index. I understand that Alpine uses v2 but I assume there are ambitions and preparations to change eventually? 2024-06-06 17:58:07 yes, and for now, there is still an expectation each builder has the keys to sign it 2024-06-06 17:59:39 afaik, there is not much difference regarding that between v2 and v3 2024-06-06 18:00:17 I created https://gitlab.alpinelinux.org/alpine/infra/package-signer as a proof of concept 2024-06-06 18:37:45 Tja ja I’ll check that out 2024-06-06 18:37:52 *thanks 2024-06-06 18:38:55 :) 2024-06-06 18:39:04 FYI, it's a very rough proof of concept of an idea 2024-06-06 18:48:00 hey, somebody mind looking at !64102? 2024-06-06 19:00:49 ncopa: pretty please, merge https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66695 2024-06-06 19:01:08 (or you on the vacation still?) 2024-06-06 19:11:35 DavidHeidelberg: ncopa is back 2024-06-06 19:14:14 ACTION (Terminator theme plays in my head) 2024-06-06 19:19:49 cely: i guess it does no harm adding it, right? 2024-06-06 21:08:00 ikke: ok cool, i just wanted to confirm that we were not creating a situation where a state actor had indirect control over signing materials 2024-06-06 21:08:15 Ariadne: yes, we had similar concerns 2024-06-06 21:09:46 aparcar[m]: wolfi uses ephemeral keys for every CI run that generates packages, and then has a resigning job at the end of the pipeline 2024-06-06 21:11:14 aparcar[m]: https://github.com/wolfi-dev/os/blob/main/.github/workflows/build.yaml#L160 likely gives an idea of how you could do the same (though wolfi is on apkv2 for reasons) 2024-06-06 22:06:04 omni: re !65584, dracut (or mkinitcpio) is needed at runtime, why move it to makedepends? 2024-06-06 22:14:02 if you did that based on https://gitlab.alpinelinux.org/alpine/aports/-/issues/14004#note_402704, the guide uses prebuilt images and thus dracut isn't needed. if you're packaging it and using `generate-zbm`, you do need dracut (or mkinitcpio) to build the image 2024-06-07 01:31:46 fossdd: Yes, it won't hurt, but maybe you should add `local` to the variable, or use a leading underscore 2024-06-07 04:15:09 oh yeah good idea 2024-06-07 06:25:20 ikke: Re: package-signer, BTW in the current scenario, if threat actor gets to the build worker machine, they get access to the private signing key and can sign whatever they want. With the package-signer approach, they wouldn't get direct access to the private signing key, but they could still perform the HTTP POST from that machine to sign the malicious package and you would unlikely notice it on 2024-06-07 06:25:26 the package-signer server side (in the logs), would you? 2024-06-07 06:36:56 ikke: althought the package-signer approach improves the situation, it still just shifts the protection of the asset (private key) to the package-signer server, so if threat actor gets to that machine, they get access to the private signing key and can sign whatever they want 2024-06-07 06:38:34 my suggestion would be to use ephemeral keys on upload to some other service which checks and resigns them and then puts them in the actual repo 2024-06-07 06:39:47 there are ways to protect the signing keys (like using vault and short-lived signing jobs) in such a setup 2024-06-07 06:40:11 but my main concern was "we aren't handing a signing key directly to the CCP, right?" 2024-06-07 06:40:59 sorry, what is CCP? :) 2024-06-07 06:42:15 and can you expand more on that "vault, and short-lived signing jobs" part? 2024-06-07 06:42:20 So far, loongarch is still just 3rd party alpine port 2024-06-07 06:45:04 ynezz: the chinese communist party, the ruling party of the chinese state, who own loongson technology, creators of loongarch 2024-06-07 06:45:49 ah, ok 2024-06-07 06:46:05 to be clear, i would not like a situation where the NSA or some EU intelligence actor gained access to private keys either 2024-06-07 06:46:17 i just want to be extremely clear on that 2024-06-07 06:46:37 however, there have not been any NSA or EU intelligence-connected companies looking to port alpine to their ISA :p 2024-06-07 06:46:37 IMO it really doesn't matter if its nation, corporation or individual 2024-06-07 06:47:35 One concern i have is that using something like vault means we put all our eggs in one basket. 2024-06-07 06:47:55 BTW what vault is that exactly? 2024-06-07 06:47:59 well, you could always have each group of architecture maintainers run their own vault + signing service 2024-06-07 06:48:15 hashicorp vault, i guess there is a fork of it now 2024-06-07 06:48:20 but i only know about opentofu 2024-06-07 06:48:25 Openbao 2024-06-07 06:48:32 But still in alph 2024-06-07 06:48:34 Alpha 2024-06-07 06:50:47 ynezz: Hashicorp vault is a credential store with an api and policies and support for plugins for dynamic secrets 2024-06-07 06:51:19 yep, I know it, if you're not explicit, it can be ansible vault for example 2024-06-07 06:58:30 ynezz: in any case, if a builder is compromised, it can be coerced in producing validly signed packages, no matter what scheme. The only thing you can do is to make it harder for the actual keys to be compromised 2024-06-07 07:01:29 yep, thats basically why we want to move the keys to Nitrokey USB dongle for OpenWrt 2024-06-07 07:02:22 and additionally monitor the signing usage via rekor 2024-06-07 07:03:43 signing usage = there is a counter in the firmware of the MCU inside the USB dongle, so every usage of the key/signature is logged 2024-06-07 07:05:30 ynezz: that's not feasible for us 2024-06-07 07:14:43 yeah, its always about trade-offs 2024-06-07 07:43:12 celie: added the `local` to the variables 2024-06-07 09:16:31 Can I raise awareness of https://gitlab.alpinelinux.org/alpine/aports/-/issues/16060 ? 2024-06-07 09:19:05 There is currently a conflict between two packages. !64930 would resolve this. There would be a bit of duplication with two versions of biber being available, but users could pick if they want bleeding edge biber+biblatex or the version of biber from TeXLive with texmf-dist-bibtexextra (which provides biblatex among other things). 2024-06-07 09:21:10 Currently installing biblatex would overwrite the contents of texmf-dist-bibtexextra with a newer version of biblatex, but keep e.g. biblatex styles from texmf-dist-bibtexextra. This could risk interoperability issues between biblatex and the styles. Hence, I believe it would be best if users would decide to either go for the bare biblatex package (and no styles), or go for texmf-dist-bibtexextra (with additional stuff). 2024-06-07 09:21:58 Wow, that was quick :) Thanks! 2024-06-07 09:25:28 maribu: the changes seemed sane, and to be fair, you seemed to be the only person actually engaged in the issue, anyone else had a month to complain or come up with a better fix :) 2024-06-07 09:35:13 Indeed. It also doesn't rule out better fixes replacing the one just merged, if someone would come up with one. And in the meantime this is an improvement over the status quo :) 2024-06-07 10:03:03 However, it seems 32-bit ARM doesn't really agree with biber2.19 2024-06-07 10:09:58 a single test is failing, looks like some one-off-index issue 2024-06-07 10:10:29 ikke: all feedback in https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/46 applied, ready from my side 2024-06-07 10:10:35 Quite nice improvements and simplifications 2024-06-07 10:11:43 maribu:matrix.org: Would it be alright if you handled the Biber (and whatever else that was added in that MR) Perl 5.40 rebuild? 2024-06-07 10:12:02 If i saw that MR, i would've asked you to wait a day or two for Perl 5.40 to be released :) 2024-06-07 10:12:52 and i've probably already tied up the CI enough times rebuilding my Perl 5.40 MR (and don't really expect any significant changes between rc2 and the final release) 2024-06-07 10:15:27 Though i don't think it links to libperl.so, so a rebuild may not actually be needed (which probably means perl-dev can be removed from makedepends) 2024-06-07 10:15:59 Anyway, just letting you know, so you can try things out in a day or two, and see if it works with Perl 5.40 2024-06-07 10:17:09 About the one-off-index, i think there's something in prepare() disabling some tests for 32-bit 2024-06-07 10:17:20 Maybe something needs to be amended there 2024-06-07 10:17:34 Anyway, going AFK now, bye 2024-06-07 10:24:55 celeste: Thx for the heads up. I will check if `perl-dev` can be dropped from the make deps and additionally check if biber still works on a freshly updated edge system on Monday and Tuesday 2024-06-07 13:03:51 Thanks, i'll give you a mention when i merge Perl 5.40 2024-06-07 13:04:05 However, we still have to fix biber2.19 tests on 32-bit ARM first 2024-06-07 13:05:17 and i think i see another potential issue 2024-06-07 13:06:21 biber2.19 depends on biblatex~3.19, which is not provided by a subpackage of texmf-dist 2024-06-07 13:06:25 s/not/ 2024-06-07 13:06:29 s/not// 2024-06-07 13:07:06 so it is not provided at the toplevel, and from what i remember, this will cause issues with the build order 2024-06-07 13:08:26 I'm trying to remember the specifics 2024-06-07 13:10:09 Yes, lua-aports does not see provides in subpackages 2024-06-07 13:13:41 I think someone more familiar with the specifics of lua-aports will have to review https://git.alpinelinux.org/aports/commit/?id=b715b980bc to suggest a solution 2024-06-07 13:15:27 The provides is calculatef by forking out to gawk, so it cannot be placed at the toplevel 2024-06-07 13:15:33 calculated* 2024-06-07 13:16:54 I wonder if placing it in package() will allow lua-aports to see the provides, while at the same time allow it to be calculated through the use of gawk, but i'm not sure 2024-06-07 13:18:55 It won't 2024-06-07 13:19:33 lua-aports sources the APKBUILD and echoes the variables it needs 2024-06-07 13:19:48 So anything not declared in the global scope is not visible 2024-06-07 13:22:12 So, that's a problem 2024-06-07 13:22:29 The provides needs to be placed in global scope, but forking out is not allowed there 2024-06-07 13:23:15 and the subpackages of texmf-dist itself depend on an unversioned texmf-dist, so that may be something else causing issues 2024-06-07 13:24:13 I mean, even if we found a way to make texmf-dist provide biblatex~3.19, getting the correct subpackage would be an issue to do the unversioned depends 2024-06-07 13:24:27 s/to do/due to/ 2024-06-07 13:27:22 So, maybe we should defer !67374 until after this provides issue is solved, and now focus on fixing the failing tests 2024-06-07 13:30:36 and i think the 32-bit ARM CIs weren't green, but the build log has been archived: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/64930/pipelines 2024-06-07 13:30:47 Probably it's the same error we're now seeing on the builders 2024-06-07 13:31:18 Another reason not to rush us to merge things ;) 2024-06-07 13:32:11 lua-aports (and similar tools) are also the reason we avoid forking 2024-06-07 13:32:53 The meta-data should be static anyway 2024-06-07 13:32:57 Yeah, i think you've told me about that, something that i did (probably involved forking) broke lua-aports 2024-06-07 13:34:03 At best it will slow it down quite a bit 2024-06-07 13:34:17 I don't have 32-bit ARM handy, so i'll try to see if i can reproduce the failing test on 32-bit x86, probably try removing some of the sed substitutions in biber2.19's prepare() 2024-06-07 13:34:55 Oh wait 2024-06-07 13:34:59 biber2.19 has !x86 2024-06-07 13:35:21 Let me try anyway, maybe the failing tests are teh reason 2024-06-07 13:35:27 the* 2024-06-07 13:36:02 No, the reason stated in biber2.19/APKBUILD is "# biblatex" 2024-06-07 13:36:11 but that seems to be biblatex~3.20 2024-06-07 13:36:29 not the biblatex~3.19 in biber2.19 depends, and that is provided by the texmf-dist subpackage 2024-06-07 13:40:22 Yes, 32-bit x86 fails in the same places as the 32-bit ARMs 2024-06-07 13:42:51 and now i see the key to all this 2024-06-07 13:43:11 biber/APKBUILD has !check, but biber2.19/APKBUILD does not 2024-06-07 13:43:36 So, the sed stuff in prepare() is probably wrong, and should'nt have been copied over 2024-06-07 13:53:01 Not familiar with TeX, so i have no idea why the tests are failing on 32-bit archs 2024-06-07 13:55:44 maribu:matrix.org: Maybe we can just disable biber2.19 on 32-bit ARM? 2024-06-07 14:00:11 celeste: texmf-dist-bibtexextra should provide biblatex. See lines 295 to 299 in the APKBUILD of community/texmf-dist 2024-06-07 14:00:41 That change got only merged today, so it may just take a bit to reach the repos. 2024-06-07 14:01:02 No, maribu 2024-06-07 14:01:04 See the discussion above 2024-06-07 14:01:11 lua-aports does not see provides in subpackages 2024-06-07 14:01:45 Yes, it provides biblatex, but that's for normal users 2024-06-07 14:01:53 For the builders, there will be issues 2024-06-07 14:02:41 To be more specific, there will be issues when making a new release 2024-06-07 14:02:59 because lua-aports does not know to order texmf-dist before biber2.19 2024-06-07 14:03:26 a new release of Alpine, that is 2024-06-07 14:03:52 So, the builders may try building biber2.19 before texmf-dist 2024-06-07 14:05:34 Anyway, that's one issue, but the more "urgent" one for now is the failing tests on 32-bit ARM 2024-06-07 14:05:55 biber does not run tests at all 2024-06-07 14:06:01 but you've enabled tests for biber2.19 2024-06-07 14:06:10 and now they are failing on 32-bit ARM 2024-06-07 14:06:25 (as far as i can see, they never passed on the CI in the first place) 2024-06-07 14:06:44 OK, I see. Would adding just texmf-dist as makedepends be a viable work around? 2024-06-07 14:07:51 Perhaps texmf-dist-bibtexextra 2024-06-07 14:09:39 Anyway, what about the tests? 2024-06-07 14:09:52 They are now blocking the builders 2024-06-07 14:11:46 I would just disable that for now. 2024-06-07 14:12:08 The test or disable the whole aport for 32-bit ARM? 2024-06-07 14:16:04 If you want to have a look at the tests that fail in CI, try enabling x86 in !67374 2024-06-07 14:16:40 32-bit ARM does not have biblatex~3.19 because biber2.19 tests are blocking the builders 2024-06-07 14:17:01 but x86 has it 2024-06-07 14:17:12 and from what i tried locally, the same tests are failing on x86 2024-06-07 14:21:43 !67374 should contain the fixes needed 2024-06-07 14:22:25 Thank you 2024-06-07 14:24:35 Just fixed a typo found by the linter 2024-06-07 14:47:45 Will be adding a few more fixes before merging it 2024-06-07 14:59:49 Thx for cleaning that up :) 2024-06-07 15:02:59 No problem 2024-06-07 15:25:48 hey, apk question: when running a post-upgrade script, does apk provide the script with info on the old and new package versions, and if yes, how? not sure it's documented, and if nobody knows I'll go look at the source 2024-06-07 15:26:28 skarnet: yes, it does 2024-06-07 15:26:37 take a look at the nginx package for example 2024-06-07 15:27:11 $1 and $2 then, okay, thanks! 2024-06-07 15:39:24 is it allowed for an aport in main to have makedepends include aport in testing? 2024-06-07 15:40:12 no, and it will fail to build 2024-06-07 15:40:31 when building packages in main, only the main repo is enabled 2024-06-07 15:41:54 ok, that is what I expected, but wanted to check 2024-06-07 15:45:13 thanks 2024-06-07 15:52:00 j_v: testing/docbook2mdoc has no maintainer, so to move it into main, you'll probably need to take up maintainership of it 2024-06-07 15:57:24 cely: thanks for heads up. will probably do just that. it's developed by author and maintainer of mandoc, so the code should be rock solid. 2024-06-07 16:07:25 Can someone please merge !67380 when you have the time? just a bunch of abumps, nothing fancy. Thanks! 2024-06-07 16:44:53 skarnet:looks good 2024-06-07 16:59:31 Gitlab will upgraded and be briefly unavailable 2024-06-07 17:05:21 it's back 2024-06-07 17:06:37 powered by alpine 3.20 2024-06-07 17:07:02 hi 2024-06-07 17:07:13 \o/ 2024-06-07 17:07:48 https://wiki.alpinelinux.org/wiki/Architecture 2024-06-07 17:08:08 is armv7 there equivalent to armv7l / arm-linux-gnueabihf 2024-06-07 17:09:45 armv7l, yes 2024-06-07 17:10:15 ptrc, can apk be used in a custom directory 2024-06-07 17:10:20 yes 2024-06-07 17:10:22 yes 2024-06-07 17:10:24 apk --root 2024-06-07 17:10:31 so how does one bootstrap that 2024-06-07 17:10:47 oh wait i forgot one issue 2024-06-07 17:10:55 - `apk --root /place add --initdb` 2024-06-07 17:11:03 actually my issue is, the computer in question isn't alpine 2024-06-07 17:11:07 is apk available as a general package 2024-06-07 17:11:09 - create `/etc/apk/repositories` inside /place 2024-06-07 17:11:09 for other oses 2024-06-07 17:11:22 you can download the apk.static package for your architecture and then unpack it with tar 2024-06-07 17:11:35 its actually an old rooted phone 2024-06-07 17:11:46 i am not sure i can directly install alpine there 2024-06-07 17:11:52 but if apk is available separately 2024-06-07 17:11:56 i'd like to use it for packages 2024-06-07 17:12:04 since i am sick of manually cross compiling everything 2024-06-07 17:12:12 https://gitlab.alpinelinux.org/alpine/apk-tools/-/releases 2024-06-07 17:12:30 ikke, so for example i can install this on a non-alpine linux install? 2024-06-07 17:12:32 such as my phone? 2024-06-07 17:12:43 It's a static binary 2024-06-07 17:12:47 you download and execute it 2024-06-07 17:13:13 oh, very nice thanks 2024-06-07 17:13:44 so in theory, if I push this to my phone, then perform the initialization steps per ptrc , it should probably work out and i would be able to install armv7 packages on my phone? 2024-06-07 17:14:31 kinda, yes 2024-06-07 17:14:44 apk --root /place add --initdb --allow-untrustd -X https://dl-cdn.alpinelinux.org/alpine//main alpine-base 2024-06-07 17:15:00 --untrusted 2024-06-07 17:15:30 ptrc, whats the kinda part? 2024-06-07 17:16:07 well, it's might not be straightforward if you're dealing with a chroot on a phone 2024-06-07 17:17:12 whats the difference between sysv and gnu/linux? 2024-06-07 17:17:26 ptrc, its actually a proper root 2024-06-07 17:17:28 the phone is rooted 2024-06-07 17:18:45 oh, i mean stuff like "the data partition is actually mounted with nosuid" 2024-06-07 17:19:15 will stuff like that matter when apk and the file hierarchy exists in a custom dir inside my home? 2024-06-07 17:19:32 I don't know much about this topic so sorry if the questions sound stupid 2024-06-07 17:20:30 yes, a chroot does not invalidate nosuid, so any suid binary fails to run 2024-06-07 17:21:11 oh I see 2024-06-07 17:21:23 I will have to check if suid is allowed or not 2024-06-07 17:21:52 and this nosuid thing, is it a kernel compile configration rather than something i can change on a running os? 2024-06-07 17:23:36 It's a mount flag 2024-06-07 17:23:50 ikke, i can change fstab 2024-06-07 17:23:57 as I said I have proper root on the phone 2024-06-07 17:24:13 You can try 2024-06-07 17:24:22 first run `mount` to see if it's even the case 2024-06-07 17:24:24 wdym, is there any issue you had in mind 2024-06-07 17:24:51 I mean my prompt is #, when i create files and ls it, it shows the user as 'root' etc 2024-06-07 17:25:21 oh oops 2024-06-07 17:25:23 The kernel can still prevent root from doing certain things 2024-06-07 17:25:27 looks like i am on -devel 2024-06-07 17:25:44 strange, i meant to join the norml channel 2024-06-07 17:25:54 is this off topic here what i am discussing 2024-06-07 17:26:11 kinda 2024-06-07 17:26:34 anyways, i think that should be all for now. i will try this next time i am playing with that phone 2024-06-07 17:36:21 Good evening/day/night. If anyone could take a look at !64135 that wold be fantastic :) 2024-06-07 17:47:06 What is the canonical way to deal a patch outside of "$builddir"? Specifically, a package needs to archives, extracted in "$srcdir/foo" and "$srcdir/bar". "$srcdir/bar" is the builddir and most patches apply here. But one patch now needs to be applied to "$srcdir/foo". 2024-06-07 17:48:16 you can move them to builddir in prepare(), then call default_prepare 2024-06-07 17:48:17 Should I set "builddir=$srcdir"? That would be a bit of a pita, as now the package version would be part of the path specified in the patches. (As well as $builddir actually pointing to where it is most convnient.) 2024-06-07 17:48:42 default_prepare is the step where patches get applied, so you can just move stuff around before it 2024-06-07 17:49:06 ptrc: I think the issue is that patches are applied relative to "$builddir" 2024-06-07 17:49:18 so if you want to patch other directories, you need to manually do it 2024-06-07 17:49:42 yeah, but why would you want to patch something outside of builddir? the build system shouldn't go outside of it 2024-06-07 17:50:25 right 2024-06-07 17:50:27 sounds like an XY problem to me, the answer to "how to apply patches outside builddir" is "you don't, you move stuff inside instead" 2024-06-07 17:50:54 OK, I see. Thx 2024-06-07 18:05:24 Love this: https://gitlab.alpinelinux.org/alpine/ca-certificates/-/merge_requests/11/diff 2024-06-07 18:55:06 ikke: you missed an `s` at the end and this returns 404 :p 2024-06-07 18:55:27 https://gitlab.alpinelinux.org/alpine/ca-certificates/-/merge_requests/11/diffs 2024-06-07 19:04:03 ncopa: can we do something with llvm+lld packaging so that the versions are in sync? the default is still 17, but lld is 18 already and that broke both webkit (instant segfaults) and, more subtly, firefox (the image view didn't view images) 2024-06-07 19:04:36 for what it's worth, i have no idea *why* they broke - i just see that using lld17 for them actually fixed the issue 2024-06-08 03:47:14 j_v: i was going to tell you that you could do the move in the logcheck MR itself, but alright 2024-06-08 03:47:24 also, please do not cancel the CI pipeline 2024-06-08 03:53:22 and now that i've run the pipeline, i see there's an implicit declaration of `strtonum`, and some `basename`/`dirname` discarded qualifiers warnings, maybe you would like to have a look at those 2024-06-08 03:54:18 Hm, j_v is not here, will comment on the MR then 2024-06-08 08:55:29 ncopa: anything still blocking this or can we get it in? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61763 2024-06-08 09:37:37 abuild's default_dbg sets the debuglink to $subpkgdir/usr/lib/debug/${src#"$pkgbasedir"/*/}.debug . symbols don't seem to be found by gdb, i think because $subpkgdir needs to scrubbed from the debuglink. or could i doing something wrong with my gdb sessions? 2024-06-08 09:39:47 it should just find it 2024-06-08 09:47:28 yeah, thought so. i must be doing something wrong. 2024-06-08 10:13:39 working now. not sure how i was messing THAT up. 2024-06-08 13:37:08 rebooting x86 builder 2024-06-08 14:00:14 Trying to create a merge request on gitlab and getting a 500 error. Anyone help? 2024-06-08 14:01:08 adhawkins: let me check 2024-06-08 14:01:20 Thanks ikke 2024-06-08 14:02:29 adhawkins: It's a timeout. Did you by chance try to create a merge request against the wrong branch? 2024-06-08 14:02:57 I'm using the URL that git gives me when I push the branch. 2024-06-08 14:03:14 I've also clicked the 'create merge request' button in my dashboard where it says I've recently pushed to a branch. Same error. 2024-06-08 14:04:47 adhawkins: can you try to rebase the branch onto a more recent commit? 2024-06-08 14:04:55 2773 commits behind, 1 commit ahead of the upstream repository. 2024-06-08 14:05:10 The branch was only created about 30 minutes ago against an up-to-date master. Will try though. 2024-06-08 14:05:58 hmm, ok 2024-06-08 14:06:45 It says it's up to date with master in my local checkout. 2024-06-08 14:07:45 Ok. I re-synced master and it pulled down a commit. I've rebased against that, and pushed. I can now create the merge request. Odd. 2024-06-08 14:09:58 Sorry for the noise. 2024-06-08 14:12:50 No problem. Ideally it should work, but it happened more often that this causes issues 2024-06-08 14:23:57 rebooting x86_64 builder host 2024-06-08 14:24:10 Are they being upgraded to 3.20? 2024-06-08 14:24:14 yes 2024-06-08 14:24:38 Ok :) 2024-06-08 14:24:47 They're quiet now, so an ideaal moment 2024-06-08 14:30:23 Is it back online now? 2024-06-08 14:31:07 yes 2024-06-08 14:31:42 Alright, thanks 2024-06-08 22:36:43 I thinking if loongarch64 fixes should be within $CARCH case statements 2024-06-08 22:37:51 omni: re !65584, dracut (or mkinitcpio) is needed at runtime, why move it to makedepends? 2024-06-08 22:40:49 abby: there were some dependency issues 2024-06-08 22:41:50 I've been quite busy with other things lately and have had my mind elsewhere, so I'm sorry I can't give you a better answer than that at the moment 2024-06-08 22:42:52 when you have the time, feel free to reach out to me about zfsbootmenu, or ask us on #zfsbootmenu @ libera.chat 2024-06-08 22:43:29 i'm one of the upstream devs and we already do some testing on alpine, we could coordinate to get the package here up to speed 2024-06-08 22:44:22 there also seemed to be a fair amount of confusion in the package request thread on gitlab 2024-06-08 22:44:58 thanks, I will 2024-06-09 09:10:29 Hi, how does it works if I dont want that an aport that I maintain move to community? 2024-06-09 09:36:31 if you are the maintainer it shouldn't be moved without your consent 2024-06-09 09:57:32 ok cool that is it then 2024-06-09 09:57:33 thanks 2024-06-09 10:16:07 fabricionaweb: is it in testing now? Because packages should not perpetually remain in testing 2024-06-09 10:32:50 Yes, i think !67106 is what's being referred to 2024-06-09 10:33:34 fabricionaweb: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/2 2024-06-09 10:38:27 This is perfect thank I will read it all through later, I saw mentions of backports which is exactly the case I'm afraid of 2024-06-09 10:39:13 The nature of the apps I'm looking to is that it has good chances to stop working due apis or some other sensitive stuff 2024-06-09 10:39:26 community's only for 6 months (the duration of 1 stable release) though, unlike main's which is 2 years (4 stables) 2024-06-09 10:46:34 Is it difficult to upgrade those aports when they stop working (probably due to latest-stable not having the latest dotnet, or something)? 2024-06-09 10:53:34 it is usually very easy to upgrade, I have not faced many issues in a while 2024-06-09 10:55:42 fabricionaweb: I don't see an issue to keep it up-to-date to the latest version due to the nature of this kind of software 2024-06-09 10:55:46 similar to yt-dlp 2024-06-09 10:58:36 if you think theres no issue than you are problably right hahaha if its fine, thats ok to me 2024-06-09 11:00:42 my concern was like: later on, 3.21 _can_ have a broken version snapshoted, but if we are allowed to backport those kind of fix (if happenes) that is good enough 2024-06-09 11:04:20 Of course you can backport upgrades, you can backport any upgrade even if it doesn't fix bugs 2024-06-09 11:04:26 As long as that upgrade doesn't break anything else 2024-06-09 11:07:23 ok I dont know why I was thinking that isnt done LOL ok my concerns isnt valid 2024-06-09 11:07:45 thanks cely and ikke 2024-06-09 11:07:53 You're welcome 2024-06-09 11:51:53 has there been talk before about archictecture specific patches? 2024-06-09 11:52:40 I have myself added patches suffixed _patch and patched in $CARCH case statements in prepare() 2024-06-09 11:53:46 omni: for rv64, everything was just pushed in just a couple of patches 2024-06-09 11:53:52 whatever was necessary 2024-06-09 11:53:59 could of pushes* 2024-06-09 11:54:20 mass amounts of MRs per package 2024-06-09 11:54:26 +not 2024-06-09 11:55:22 That was before rust though and a lot less go packages 2024-06-09 11:55:28 which add friction here 2024-06-09 11:56:45 I did not think just about new targets here 2024-06-09 11:56:47 example https://git.alpinelinux.org/aports/tree/community/arti/APKBUILD#n33 2024-06-09 11:57:46 not sure how architecture specific patches would be handled, perhaps CARCH named subfolders with patches that would be picked up only for those architectures 2024-06-09 12:06:23 sorry, I misunderstood the question 2024-06-09 12:07:46 it's not unrelated, it would also help with adding new architectures 2024-06-09 12:08:12 yes, but this was a more specific question 2024-06-09 12:22:49 I opened https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10142 2024-06-09 15:18:05 I wonder why main pages of repositories doesn't load for me, like https://gitlab.alpinelinux.org/alpine/abuild and https://gitlab.alpinelinux.org/alpine/aports 2024-06-09 15:18:29 omni: what happens when you do? 2024-06-09 15:18:31 the top and sidebars load, but then it's just a spinning wheel in the middle 2024-06-09 15:18:47 do you have web workers disabled by an extension? 2024-06-09 15:21:21 not intentionally 2024-06-09 15:22:29 this is qutebrowser with qt5-qtwebengine 2024-06-09 15:22:50 Are there developer tools? 2024-06-09 15:23:22 works fine for me in qutebrowser 2024-06-09 15:23:26 with qt6 2024-06-09 15:26:39 alice: are you logged in or logged out when you test? 2024-06-09 15:26:44 out 2024-06-09 15:28:02 yeah, it works for me too with qt6-qtwebengine, but that's often too laggy for me to be usable, especially with pages like gitlab 2024-06-09 15:28:25 tried both logged in and out with qt5-qtwebengine and it doesn't load 2024-06-09 15:28:37 so it is there then 2024-06-09 15:29:19 --qt-wrapper PyQt5 2024-06-09 15:32:40 omni: cannot find anything in the logs indicating an issue 2024-06-09 15:33:20 chromium 87 not being able to load a webpage doesn't seem very surprising 2024-06-09 15:33:21 thanks for looking 2024-06-09 17:47:23 Tried to start kaidan, and it bugs out 2024-06-09 17:47:27 qrc:/qml/details/AvatarChangePage.qml:13:1: module "org.kde.kquickimageeditor" is not installed 2024-06-09 17:47:42 I suppose the packages is missing a dependency on kquickimageeditor 2024-06-09 17:59:45 Ah no, it was actually already installed, maybe rather a build issue 2024-06-09 18:30:34 hello, I'm trying to run monerod, I correctl installed 2024-06-09 18:33:04 it gives this error in runtime 2024-06-09 18:33:36 Error relocating /usr/lib/libboost_filesystem.so.1.84.0: statx: symbol not found 2024-06-09 18:43:47 that sounds like you mixed edge with stable 2024-06-09 18:48:00 they left already 2024-06-09 18:48:34 they left after alice's message :) 2024-06-09 18:50:10 Oh, they rejoined, but that was filtered out for me 2024-06-09 19:14:01 I tried to use irssi and I got banned from OFTC, how is that possible? 2024-06-09 19:16:25 anyway, I'm currently trying to run monerod and it gives a symbol not found error 2024-06-09 19:16:56 Error relocating /usr/lib/libboost_filesystem.so.1.84.0: statx: symbol not found 2024-06-09 19:17:19 I installed monerod from edge repository along with its dependences 2024-06-09 19:22:58 idkidk_: are you mixing repositories? 2024-06-09 19:23:09 trying to install something from edge while on 3.20 for example 2024-06-09 19:25:07 I am kinda forced to do it, monero is only on edge 2024-06-09 19:25:19 then you should switch completely to edge 2024-06-09 19:25:38 I installed all the dependences also from edge 2024-06-09 19:25:45 but not musl 2024-06-09 19:25:46 all the libboost 2024-06-09 19:26:00 oh... understood 2024-06-09 19:26:04 at which point, you should completly switch to edge 2024-06-09 19:28:11 Thank you, also it's the first time something like this happens, and I've got lots other alpine vms where I didn't switch entirely to edge(installed just some packages from there) 2024-06-09 19:28:49 I never had any problems, do you recommend to completely switch to edge also there? 2024-06-09 19:29:20 https://gitlab.alpinelinux.org/jvvv/aports/-/jobs/1416793 -- should i should restart the pipeline for that arch? all other arches passed. 2024-06-09 19:30:15 idkidk_: it's a matter of time for things to break 2024-06-09 19:30:34 j_v: yes 2024-06-09 19:30:57 thank u! 2024-06-09 19:31:00 Not sure why that happens 2024-06-09 19:32:07 i thought i remembered someone saying something about it. but i hate to put extra load on the builders 2024-06-09 19:33:17 This is justified 2024-06-09 19:34:58 how do I list all apk packages installed from edge? 2024-06-09 19:35:47 am I offtopic here? should I move to #alpine-linux 2024-06-09 19:35:48 ? 2024-06-09 19:37:17 #alpine-linux is beter suited for these kinds of questions 2024-06-09 22:10:19 can someone please look over !64102? would be nice :3 2024-06-09 22:31:04 otherwise !65251 and !64080 could benefit from some review :) 2024-06-10 02:26:46 ACTION is working on Perl 5.40.0 2024-06-10 03:08:01 Will probably be merging !66188 soon 2024-06-10 03:29:36 Merged 2024-06-10 03:35:58 Next up: the Rust 1.79.0 pre-release, which will probably be released later today 2024-06-10 04:42:10 armhf has just 2 aports left for main, and once it has finished that, Perl aports using XS and aports that link to libperl.so in community and testing will be broken for a few hours while the builder works through those 2 repos 2024-06-10 04:43:25 Same goes for all the other archs, as they follow armhf in completing main 2024-06-10 04:44:08 It looks like the next 2 to complete main will be aarch64 and s390x 2024-06-10 05:52:52 armhf has completed the Perl 5.40.0 rebuilds, armv7 should be next, hopefully followed by the rest :) 2024-06-10 07:28:15 Is the conflict between perl-doc and perl-test2-suite-doc (both providing identical files) already known? 2024-06-10 07:33:36 Haven't seen an issue about it 2024-06-10 07:37:27 OK, I'll take a look. 2024-06-10 07:43:35 Locally rebuilding perl fails :/ I guess I' 2024-06-10 07:43:55 ... ll try that in a fresh container instead. (Sorry, hit the return key by accident.) 2024-06-10 07:45:02 A new Perl has been pushed, so there may be a discrepancy between main and community 2024-06-10 07:53:20 It may also be that I have some headers / pkgconf locally available that perl tests for, but the implementation is not compatible with musl. The error I got on my host system was "... undefined reference to `getprotobyname_r'". It worked fine in a fresh container, though. 2024-06-10 08:09:38 Same issue with perl-term-table-doc and perl-doc. I hope this is not a game of whac a mole to solve these duplications... 2024-06-10 08:20:33 No, i'm on it 2024-06-10 08:21:01 You've reminded me of what i should've done upon seeing the file list diff for perl-doc :) 2024-06-10 08:21:02 Thanks 2024-06-10 08:23:15 celeste: Sorry, read your message only after I have opened !67478. Feel free to close that MR. 2024-06-10 08:31:28 My internet is slow again 2024-06-10 08:31:31 Can you please describe what you did? 2024-06-10 08:31:39 If you are doing a rebuild of Perl, please close that MR 2024-06-10 08:40:12 maribu: This issue keeps coming up, and people's first reaction is to modify main/perl, please remember that this is not the first choice if it can be solved in the individual aports, and remind others too if you come across anyone attempting this. Thanks. 2024-06-10 08:42:49 and actually, there is a hint for that this is not the preferred choice 2024-06-10 08:43:27 If it was, many other man pages would also have to be deleted from main/perl, but you don't see that 2024-06-10 08:56:28 Note that the man pages removed from main/perl-doc where documenting functions not included in main/perl. And the doc provided by perl-test2-suite-doc did document the perl code provided by perl-test2-suite. IMO it makes sense if foo-doc would contain the documentation for what pkg foo provides. 2024-06-10 08:58:46 Sorry, but a few months ago, i worked to remove all conflicting man pages from individual perl-* aports, following what was done before i did that 2024-06-10 08:59:30 Grepping for "provided by perl-doc" yields 16 results 2024-06-10 09:00:29 and "not included in main/perl" is not exactly accurate 2024-06-10 09:00:40 because main/perl does include Test2::Suite and Term::Table 2024-06-10 09:00:55 Is there an issue open upstream? IMO this is not something that distros should be bothered with. IMO upstream should make sure that installing docs does not install unrelated doc as well. 2024-06-10 09:01:16 maribu: main/perl includes perl-test2-suite and perl-term-table 2024-06-10 09:01:42 So, if anything, those aports should be deleted 2024-06-10 09:02:10 but it is not done, because sometimes they can be used to provide upgrades before they get into main/perl itself 2024-06-10 09:02:21 before those versions* 2024-06-10 09:02:51 Look at the contents of main/perl=5.40.0-r0 2024-06-10 09:02:58 There is a Test2/Suite.pm and a Term/Table.pm 2024-06-10 09:03:37 The reason those do not conflict with perl-test2-suite and perl-term-table is because the files in main/perl are in the "core_perl" directory, whole those in the individual aports are in the "vendor_perl" directory 2024-06-10 09:04:17 For man pages, they all go into the same directory, that's why they conflict 2024-06-10 09:04:33 OK, I see. 2024-06-10 09:04:40 Thank you. 2024-06-10 09:05:03 So, please remember that it is not without reason that i put in all that effort to do things this way. 2024-06-10 09:06:32 s/whole/while/ 2024-06-10 09:14:58 Maybe the easiest way to solve this would be to not let perl packages installing into vender_perl use the .3 postfix in man pages? E.g. BSD functions such as strlcat have their man pages as man3/strlcat.3bsd instead of man3/strlcat.3. This allows having both installed, and mandoc and the other man tools are prepared for this. (E.g. man strlcat or man 3 strlcat will open the BSD man page, if there is no strlcat.3. man 3bsd 2024-06-10 09:14:58 strlcat will open the BSD variant even if a strlcat.3 is there.) 2024-06-10 09:15:31 Sorry for the noise, btw. 2024-06-10 09:16:49 Sorry, but that is a very big change, so this is probably not the place and/or time to discuss that 2024-06-10 09:17:31 I have just finished the Perl rebuild, and am thankful that you pointed what i missed out, but to immediately think of doing another big undertaking like this 2024-06-10 09:17:34 That i cannot do, sorry 2024-06-10 09:19:09 (Big, because, it will require rebuilding all perl-* aports (more than what i just did for the rebuild), and also modifying their APKBUILDs) 2024-06-10 09:48:57 I'm not familiar with perl. From the packages I installed it looks like only the main perl package installs into core_perl, and all perl-* packages install into vendor_perl. Is that correct? 2024-06-10 09:49:49 Yes 2024-06-10 09:50:49 I have an idea how this could be solved easily. I think it is best to discuss this when I have a proof of concept. I'll ping you when I have a draft MR. 2024-06-10 09:51:53 Sorry, i think it is best to talk to upstream about this before you start anything. 2024-06-10 09:52:27 By the way, the man pages are actually just converted from Perldoc 2024-06-10 09:53:10 So, if they are not available, just running perldoc on the *.pm files should give you the same content (maybe a little different in presentation, but i think content is what matters here) 2024-06-10 09:53:45 and we keep /usr/bin/perldoc in the main/perl package itself, and not the perl-doc subpackage 2024-06-10 09:55:21 and sorry i am unable to discuss this with you further, i am about to go for a break 2024-06-10 09:57:30 but i really think you should talk to upstream about your concerns, it will be best if you can get your changes upstreamed, that way more people can comment on your work 2024-06-10 09:58:18 I think there aren't that many people working on Perl for Alpine, so you will definitely get better suggestions if you speak to upstream about this. 2024-06-10 10:00:14 and you will also get the benefit of having people who know more than me review what you are doing. 2024-06-10 10:00:31 so, please consider talking to upstream before you open an MR. 2024-06-10 10:01:39 ACTION goes AFK 2024-06-10 10:15:08 an added benefit of having more people review your changes is being able fo find someone with the time to do so, if you open an MR, you will be demanding my attention (i have already postponed my break by more than an hour), and in the coming month and a half, i am not certain how much time i will have that i am able to devote to MRs (i will be prioritizing those that are urgent fixes for something that is broken, so such improvem 2024-06-10 10:15:09 ents MRs will be put on the back-burner) 2024-06-10 10:16:58 so, i strong suggest that you go to upstream first, and once you have sorted out everything with them, then you ping me, i think it is only natural to be more willing to devote time to something that upstream has approved (so i hope you don't mind) 2024-06-10 10:17:25 ACTION goes AFK for real 2024-06-10 11:11:34 OK, I'll raise the issue on a perl mailing list. 2024-06-10 11:13:46 https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/297 is the proof of concept that would just rename usr/man/man3/foo.3pm.gz into usr/man/man3/foo.3vendor-pm.gz if the package is name perl-* as part of default_doc. That should allow dropping all the 20+ cases of manually handling the conflicts from aports, if consensus would be to follow that path. 2024-06-10 11:35:12 I'm afraid i will have to excuse myself from this discussion, as i mentioned above, unfortunately i have other priorities in life in the coming months, and i am very sorry that i missed removing those man pages, causing you to go to all this trouble 2024-06-10 11:36:18 Personally, i do not think such a modification is really that necessary, because to me the issue has been solved, but you still seem to have your concerns 2024-06-10 11:37:01 and i don't think Perl is going to add any new man pages soon 2024-06-10 11:37:44 and as i said, the man pages are converted from Perldoc, so they are actually a secondary source 2024-06-10 11:38:21 so i am not sure it is necessary to keep so many potentially duplicate documentation around 2024-06-10 11:39:26 We already have the primary Perldoc in the .pm files in main/perl, and the converted man pages in main/perl-doc, keeping the vendored man pages around would make that a total of 4 copies of very likely, the same thing 2024-06-10 11:40:50 Perhaps you could consider comparing the man pages from perl-doc with the ones you are renaming to 3pm-vendor, and turning them into a symlink if they are the same 2024-06-10 11:43:29 but i think that may be overcomplicating things, but maybe it is just me, i also think the man pages won't be changing so much, so if you really need to refer to something that changed, you will very likely know about looking for the primary source through `perldoc` 2024-06-10 11:46:31 By the way it seems you are renaming all perl-* man pages to 3pm-vendor 2024-06-10 11:46:56 Maybe you would want to consider renaming only those that conflict with something in perl-doc itself 2024-06-10 11:48:34 So, that's what i could come up with: (1) rename only those man pages that conflict with perl-doc, (2) for those man pages that conflict, if they are duplicates of what is in main/perl, then turn them into symlinks 2024-06-10 11:49:30 I think people who have perl-*-doc installed, should also have perl-doc installed (probably this is obvious, as this is how you came to know of the conflicting man pages in the first place) 2024-06-10 11:50:46 Anyway, that is all i have to offer, and also my apologies for making you chase this issue around like that (i should've looked more carefully and removed those man pages with the rebuild itself) 2024-06-10 11:51:06 celeste: Just to be sure: I'm not trying to critizie you. I'm just wondering if there is an easier to maintain solution. 2024-06-10 11:51:37 Arch Linux does something similar, but easier: https://gitlab.archlinux.org/archlinux/packaging/packages/perl/-/blob/main/PKGBUILD?ref_type=heads 2024-06-10 11:52:28 The keep the 3pm suffix for vendor modules, but rename man pages for core perl to 3perl (which, conveniently, is also alphabetically smaller than 3pm, so that the core man pages gets chosen over the vendor one). 2024-06-10 11:53:40 The easiest would be to just not package the aports that are already included in main/perl, and i think i have personally contributed a bit to that part by withholding an upgrade until Perl 5.40 got in, so that new dependent Perl module did not have to be added as a separate aport 2024-06-10 11:54:22 I think that is not right, the vendored man pages should be preferred 2024-06-10 11:54:28 because that is how Perl searches for packages 2024-06-10 11:54:35 First in vendor_perl then core_perl 2024-06-10 11:58:26 but personally, i think i have spent enough time on this issue, and have other things to attend to now, so i will probably not be commenting on this further, and leave the decision up to your discussions with upstream, and the maintainers of abuild (i don't have commit access to that) 2024-06-10 11:59:26 (also conveniently, for Perl documentation, i would first reach for `perldoc` instead of `man`, so however the man pages are named is not that much of a concern to me) 2024-06-10 12:00:10 thanks for all the background knowlege :) 2024-06-10 12:01:31 You're welcome 2024-06-10 13:02:20 In case someone whats to follow the upstream discussion: https://www.nntp.perl.org/group/perl.perl5.porters/2024/06/msg268256.html 2024-06-10 13:48:42 maribu: i see you closed the abuild MR (i thought you were going to help keep my workload low by solving this at the level of abuild?), so i just want to make it clear, that if this becomes an aports issue again, and requires a global rebuild of the >1000 perl-* aports, i am not going to support it, sorry. someone else will need to come up with the manpower required for such an undertaking. 2024-06-10 13:53:43 and now i'm looking at the Arch PKGBUILD, and see that renaming it in ./configure has a side effect, you need to then edit Config_heavy.pl after `make install` 2024-06-10 13:54:36 (to restore the usual names for man pages installed to vendor_perl) 2024-06-10 13:55:02 for modules installed to vendor_perl* 2024-06-10 13:55:56 I assume that will also be the case if we modify the man page directory (will have to edit something to restore vendor_perl man pages to their usual location) 2024-06-10 13:57:59 So, at this point, if the man pages in main/perl are such an eyesore, why don't we just completely remove all the man pages from perl-doc? no more conflicts, and no more renaming needed :) 2024-06-10 14:04:50 I guess i have also hinted by what i said above, that i would not want to do what Arch does, where ./configure is modified, then `make install` called, and then something else needs to be edited after that to return the usual values 2024-06-10 14:10:32 The reason I closed the MR to abuild is that instead of renaming the man pages of all perl-*-doc to not conflict with perl-doc (automated a abuild level), one could instead just rename the man pages in perl-doc (at APKBUILD level). The second option seems easier to me. 2024-06-10 14:11:16 or just deleting all the perl-doc man pages :) 2024-06-10 14:14:17 That would solve it from the packaging point of view. It may not be the best UX, though. 2024-06-10 14:15:12 I mean, now that the discussion has been moved upstream, why not wait for them to reply. 2024-06-10 14:15:13 Anyway, i hope you also see my point, that i do not want to ./configure with 1 value, and then have to sed replace it to its usual value after a `make install` 2024-06-10 14:17:06 Sure, but i hope we are on the same page that a sed replace is also error prone, and should be avoided 2024-06-10 14:24:27 So, yeah, a good fix for this would be support for renaming the man pages without needed that sed replace is added upstream 2024-06-10 14:24:33 Agreed. Just some `find "$subpkgdir/usr/share/man/man3" -name '*.3pm.gz' -exec ...` in the doc split function after `default_doc` would also do the trick. 2024-06-10 14:24:37 s/needed/needing/ 2024-06-10 14:57:50 Ah, now looking through the Makefile, we can just break `make install` up into `make install.perl` and `make install.man`, that would probably make it easier to override the default man page extension without needing the sed replace, i'll be going with this if in the end, the decision is made to rename the extension of the core_perl man pages 2024-06-10 15:37:12 I have an APKBUILD that's good to go once a suitable extension for the core_perl man pages is decided on 2024-06-10 16:43:35 got a package flagged by "noreply@example.com" 2024-06-10 16:43:36 sigh 2024-06-10 21:06:57 ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16192 2024-06-10 22:02:30 hi 2024-06-10 22:02:48 how do I add necessary modules to run waydroid on alpine linux-lts kernel? 2024-06-10 22:03:25 it's saying "module binder_linux" not found 2024-06-10 22:04:06 are you trying to run waydroid from the system package? 2024-06-10 22:04:23 installed from apk 2024-06-10 22:04:28 idk what you mean 2024-06-10 22:05:43 I heard linux-lts doesn't support by default those modules 2024-06-10 22:08:27 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12026 2024-06-10 22:08:45 or maybe it does support those, just not as modules 2024-06-10 22:09:08 I cannot quite undestand how to proceed 2024-06-10 22:19:44 is it correct that there's no actively-supported linux-zen kernel on alpine? 2024-06-10 22:32:16 linux-virt kernel doesn't have apparmor 2.4 compatibility patch 2024-06-11 02:40:05 waydroid from http://dl-cdn.alpinelinux.org/alpine/v3.19/community needs way too much dependences that it states 2024-06-11 05:51:01 What does that mean? 2024-06-11 12:33:12 hi 2024-06-11 19:03:10 is this up-to-date and should work with 3.20? https://github.com/ncopa/alpine-installer-testsuite 2024-06-11 19:09:29 How do we feel about proprietary apps that would require something like patchelf to run? (technically the license says lgpl, but the company has never released the actual source... I think because it's written with QT, but they don't want to pay or comply with the license) 2024-06-11 19:20:39 iggy: we require (with only few exceptions) packages to be built from source 2024-06-11 19:21:08 So if the source is not available, it's not eligible 2024-06-11 19:51:18 you can file the lawsuit to force them to disclose source 2024-06-11 20:16:09 I thought about reporting them to QT because they're clearly breaking some rules there 2024-06-11 20:16:44 what's the application? 2024-06-11 20:23:25 What does patchelf has to do with Qt licensing? 2024-06-11 20:23:28 have 2024-06-11 20:25:44 quinq: patchelf probably to make it work on musl systems 2024-06-11 20:26:06 which is necessary if you do not have the source to compile it against musl 2024-06-11 20:26:15 Sorry, I don't understand what you mean 2024-06-11 20:26:28 Ahh, it's about not having the source of that (mystery) software 2024-06-11 20:26:35 Not about patchelf, or Qt 2024-06-11 20:26:39 indeed 2024-06-11 20:26:42 ok, thanks :) 2024-06-11 20:27:35 iggy, indeed if they actually license their software under LGPL and they don't distribute the code, it's a breach of their licensing 2024-06-11 20:27:43 1/ don't even bother with their software at all 2024-06-11 20:27:48 2/ report them to the police 2024-06-11 20:27:54 chose 2024-06-11 20:28:16 If they are the copyright holder, they can do what they want 2024-06-11 20:28:28 They can change the license, yes 2024-06-11 20:28:30 Not lie about it 2024-06-11 20:29:58 They can put a label on it, but that does not necessarily give you those rights 2024-06-11 20:30:43 Since when? 2024-06-11 20:30:59 It's not a label, it's a legal contract 2024-06-11 20:32:45 The contract happens when you want to distribute the software that you do not have copyright to 2024-06-11 20:32:55 then you use the license to be able to do so 2024-06-11 20:33:21 If you receive the software from the copyright holder, the license is irrelevant 2024-06-11 20:34:27 It's just proprietary software in practice 2024-06-11 20:34:56 It doesn't matter how you got the software 2024-06-11 20:35:11 It matters how it's licensed, and the rights it grants the recipient 2024-06-11 20:36:12 Jusdt by downloading the software you don't become a licensee 2024-06-11 20:38:33 You become a licensee by redistributing software based on what the license allows you to do (there are 3 parties in play) 2024-06-11 20:40:09 With copyleft-style licenses, I'm only allowed to redistribute (read, as a non copyright holder) software if I my users receive the same rights as I did. 2024-06-11 20:40:29 part 1 is the copyright holder, party 2 is me, party 3 is my users 2024-06-11 20:42:00 Without the license, I would violate the copyright of party 1 2024-06-11 20:42:25 But the copyright holder does not need a license to distribute their own software 2024-06-11 20:48:36 So you mean that basically GPL can never be effective against closed-soruce binary distribution of a GPL-licensed software 2024-06-11 20:49:14 And its only use is if you got somehow a hold of a leaked source 2024-06-11 20:49:24 Then they couldn't ask you to “give it back” 2024-06-11 20:49:35 (or to not share it) 2024-06-11 20:50:35 Problem with leaked source is that you cannot prove that you have a valid license (they could argue you added the license yourself) 2024-06-11 21:00:33 Well, no, as they say publicly that they license it under GPL 2024-06-11 21:01:02 But sure, I can with your “not even” 2024-06-11 21:01:03 That's not a legal document 2024-06-11 21:01:09 or license 2024-06-11 21:01:14 That's just a lable 2024-06-11 21:02:19 So you mean that one could argue in court, that there's a world conspiracy where all actors got a leaked a code, and put a GPL file on the side 2024-06-11 21:02:50 But as the original author, you have the final say anyway and be right that they all lie, just because you can't empiricaly prove anything ever 2024-06-11 21:02:56 That's far-fetched :) 2024-06-11 21:03:03 Sorry court, “it's just a label” 2024-06-11 21:03:11 Well, you need to prove that you got a valid license, not the copyright holder 2024-06-11 21:03:34 No, the label does not provide the license 2024-06-11 21:03:38 Well then it's *never* possible to do if the other party refutes it 2024-06-11 21:04:16 How can you, ikke, prove that you got a valid license for your linux kernel? 2024-06-11 21:04:27 You can't if Torvals says you don't? 2024-06-11 21:05:36 I can prove that the source was provided on kernel.org including said license on a specific date 2024-06-11 21:05:58 how? 2024-06-11 21:07:26 Where you doing it alongside an legaly assermented third-party in the country where Torvalds registered his trademark? 2024-06-11 21:07:44 trademarks have little to do with this 2024-06-11 21:08:14 But it's besides the point. I you have never received a copy if the license agreement, you cannot claim you have a contract between the copyright holder and you 2024-06-11 21:10:09 Yeah ok, discard the trademark part, but don't discard the question :) 2024-06-11 21:10:13 Just labeling software with a tag does not constitute a license agreement, that's why every open source project includes a copy of the actual license (and per GPL standard, each source file even includes a header) 2024-06-11 21:10:50 You were talking about “proving” 2024-06-11 21:11:27 Just how you normally prove such things in courts 2024-06-11 21:11:31 That in order to claim your rights defended by the GPL, you have to *prove* that the software was released under GPL 2024-06-11 21:12:17 yes, you have to 2024-06-11 21:12:19 So it's fine then 2024-06-11 21:12:43 If you get leaked code of a software, that the author publicly claims as bein distributable under GPL, it's a proof 2024-06-11 21:12:49 being 2024-06-11 21:13:11 Of course, they could deny that's the source of the software 2024-06-11 21:13:31 But then you're fine as it's not that software anymore 2024-06-11 21:13:37 Obtaining a leaked copy of the source does not mean you have a valid license 2024-06-11 21:14:05 Of course you do, because it's under GPL 2024-06-11 21:14:10 No 2024-06-11 21:14:12 It doesn't matter *how* you got it 2024-06-11 21:14:15 yes 2024-06-11 21:14:27 Just a label stating 'GPL' does not automatically mean it's licensed under GPL 2024-06-11 21:15:16 Including a copy of the GPL license itself, alongside with the code (as is common) 2024-06-11 21:16:27 But if you don't include it, it's a breach of the GPL in itself 2024-06-11 21:16:41 ofcourse not, if you are the sole copyright holder 2024-06-11 21:16:58 Well, “you”'re not in this case 2024-06-11 21:17:37 Though I don't remember exactly how the GPL works regarding linking 2024-06-11 21:17:38 If you stole the source code (or obtained a leaked copy), you cannot prove you obtained a valid license 2024-06-11 21:18:00 It is like if you don't distribute it statically linked, you can have it closed-source? 2024-06-11 21:18:17 I mean Qt 2024-06-11 21:18:23 Or the opposite 2024-06-11 21:19:57 The whole linking part has, as far as I know, not been proven in court, so it's based on the interpretation of GNU 2024-06-11 21:20:05 /fsf 2024-06-11 21:21:29 quinq: just to make it clear, I have all this time only been talking in the case you are the sole copyright holder. If obtained code from someone else under an open source license, you have of course adhere to that license 2024-06-11 21:26:30 right 2024-06-11 21:29:10 I get what you mean, but I find a bit shady the part about having to prove that the owner gave you the source, alongside a copy of the GPL, willingly and when sane of mind 2024-06-11 21:29:17 but ok 2024-06-11 21:30:04 Isn't that normal? The default is copyright, you are violating that copyright, unless you have a valid license 2024-06-11 21:30:24 You have to prove that you have a valid license agreement 2024-06-11 21:33:58 I suppose 2024-06-11 21:34:02 Thanks for the discussion :) 2024-06-11 21:53:24 absolutely did not intend to stir up such a hornets nest with my question... Just because I saw a few things asked/mentioned: The software is a gui/user space driver for a drawing tablet. I'm using it because there is no open source alternative, and I don't really have the time to go about creating one. Fwiw, police wouldn't get involved in a copyright/contract dispute (at least 2024-06-11 21:53:26 not in my country). There is a copy of the LGPL included in the debian (and I assume rpm) packages that the company distributes. Someone else in the past tried to get the company to release the code and they declined. 2024-06-11 21:53:58 but yeah, the answer to my question is no "closed source" apps, thanks for the info and discussion 2024-06-11 21:55:29 iggy, would it be possible to know the name of the software, to put it on my “bad list”? :) 2024-06-11 21:55:53 (and no problem, at least on my side about the discussion, it was nice and interesting, sorry though if that distrubed the rest) 2024-06-11 21:57:59 it's a driver/gui for a Veikk drawing tablet, it doesn't really have a name per se 2024-06-11 21:59:01 I was able to get it to work on Alpine fine, so maybe I'll just document that procedure somewhere in case anyone else ends up with this thing 2024-06-11 22:02:08 ok :) 2024-06-12 13:45:46 c++ appears to be broken with fortify-headers 2.3 2024-06-12 14:07:35 i wonder if we should revert the fortify-headers-2.3. a lot is broken: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61763#note_412662 2024-06-12 14:16:17 i reverted it 2024-06-12 16:08:31 Error opening plugin module; module='cloud_auth', error='Error relocating /usr/lib/syslog-ng/libcloud_auth.so: _ZTVN10__cxxabiv117__class_type_infoE: symbol not found' 2024-06-12 16:21:56 hm, i'm guessing that should come from libc++? 2024-06-12 16:22:42 I guess? 2024-06-12 16:23:36 ftr, that's on 3.20 2024-06-12 16:29:23 sounds like some ABI breakage of some sort 2024-06-12 16:30:34 maybe we should rebuild syslog-ng? 2024-06-12 16:57:43 #16201 2024-06-12 17:10:40 i think its an underlinking issue 2024-06-12 17:11:13 why does the alpine externally-managed-environment thing for pip break with --user ?? 2024-06-12 17:11:22 it should only break for attempts to install system wide imo 2024-06-12 17:13:02 dalias: that's pip itself that decides that 2024-06-12 17:13:52 You can only mark it as externally managed 2024-06-12 17:13:59 it is? the text of the message seems to be provided by alpine 2024-06-12 17:14:04 *sigh* 2024-06-12 17:14:13 yes, we provide the file, but not the any logic 2024-06-12 17:14:37 is there a way to fix it in environment? 2024-06-12 17:14:47 i never run *anything* as root so --user is always in effect 2024-06-12 17:15:21 so it'd be nice to just make it ignore all that stuff 2024-06-12 17:15:27 you can remove the EXTERNALLY_MANAGED file iirc 2024-06-12 17:15:44 as in, /usr/lib/python3.12/EXTERNALLY-MANAGED 2024-06-12 17:17:22 hello, I'm trying to change group owner of a tty 2024-06-12 17:17:56 tty3 root:tty 0666 2024-06-12 17:18:37 seems that mdev doesn't change the group owner, I tried rebooting 2024-06-12 17:19:22 tty[0-2] root:root 0600 2024-06-12 17:19:28 tty[04-9] root:root 0600 2024-06-12 17:23:43 I also tried setting tty[0-9] root:tty 0600 with no luck 2024-06-12 17:30:49 hmm, fakeroot still seems to be broken for me in docker 2024-06-12 17:31:26 lovely 2024-06-12 17:32:11 dalias: need to confirm again, but last time I checked, it seemed to be closing fs infinitely 2024-06-12 17:36:29 https://tpaste.us/xy0w 2024-06-12 17:38:23 am I the only one with mdev misbehaving? 2024-06-12 17:40:05 duress421: are you sure mdev is in use and not forexample udev? 2024-06-12 17:49:21 isnt mdev the default on alpine? 2024-06-12 17:49:34 it is 2024-06-12 17:50:48 rc-status says it's started 2024-06-12 17:51:17 kdevtmpfs is running 2024-06-12 17:53:04 ncopa: are you working on syslog-ng? 2024-06-12 17:55:25 just found out that another alpine vm has only udev running, such switch is caused by installing specific programs requiring udev or ... ? 2024-06-12 17:57:41 setup-xorg-base would install it 2024-06-12 18:00:00 what could be the cause of mdev not setting the group owner? I need to output a program in a tty as unprivileged user 2024-06-12 18:07:44 I'm not that familiar with the rules 2024-06-12 18:26:57 ncopa: :D 2024-06-12 18:44:08 ikke: not any more... :) 2024-06-13 00:03:11 I guess it's not possible to fetch tarballs from pypi anymore? 2024-06-13 00:06:55 oh? 2024-06-13 00:06:58 wait, what happened 2024-06-13 00:07:20 did they deprecate all endpoints that don't use the weird hashes 2024-06-13 00:08:55 idk, `curl -L https://pypi.io/packages/source/s/setuptools/setuptools-69.5.1.tar.gz | file -` works just fine 2024-06-13 00:14:58 that didn't work with setuptools-scm tho 2024-06-13 00:15:43 https://files.pythonhosted.org/packages/source/s/setuptools-scm/setuptools-scm-8.1.0.tar.gz -> 404 2024-06-13 00:19:30 https://files.pythonhosted.org/packages/source/s/setuptools-scm/setuptools_scm-8.1.0.tar.gz works for me 2024-06-13 00:19:31 it's the normalisation thing, I guess 2024-06-13 00:25:27 thanks, that worked 2024-06-13 00:35:16 np 2024-06-13 07:21:42 do you guys have a builder script somewhere? 2024-06-13 07:21:49 i kinda want to rebuild the whole aports tree 2024-06-13 07:28:48 ah, found it 2024-06-13 07:28:51 https://gitlab.alpinelinux.org/alpine/infra/docker/aports-build 2024-06-13 07:50:03 You want build-repo from lua-aports if you want to build a complete repo 2024-06-13 07:53:16 ah 2024-06-13 07:53:17 thanks! 2024-06-13 09:54:28 i think i could make one meta package for vscode-remote dependences 2024-06-13 09:54:54 would it be accepted by aports? 2024-06-13 10:17:33 qaqland: perhaps as a subpackage? 2024-06-13 11:25:30 arent those closed source binaries? 2024-06-13 11:31:12 oh, perhaps 2024-06-13 18:15:58 Yeah, they're all closed source. You can still install them though if you change the package repository URL back to the default Microsoft maintained one. 2024-06-13 18:16:05 At least last time I tried. 2024-06-13 18:16:33 We can't use the default Microsoft extension repo because it's only supposed to be used for their distribution of VSCode. 2024-06-13 20:10:06 someone submitted a merge request with a monero mining pool 2024-06-13 20:10:06 can we use the same reasoning as with testing/activate-linux that it would be just a waste of space on the mirrors? 2024-06-13 20:12:21 how large is it? 2024-06-13 20:12:50 probably not that large 2024-06-13 20:14:38 less then 1mb 2024-06-13 20:19:45 just say you don't participate in scams 2024-06-13 21:07:43 q66: kinda want to avoid any potential cringe phoronix forum threads 2024-06-13 21:08:33 ptrc: does accepting the merge request avoid those 2024-06-13 21:08:48 it's a stalemate i guess 2024-06-13 21:09:12 sounds more like it'll bring more cringe people into the distro 2024-06-13 21:09:48 we already have some ethereum bullshit 2024-06-13 21:09:52 rip 2024-06-13 21:13:50 we removed most of the crypto packages on void and only got a few users complaining 2024-06-13 21:37:49 hey. anyone know which package has KDSingleApplication-qt6Config.cmake ? 2024-06-13 21:38:05 bumping nheko, and 0.12.0 is their first qt6 release. 2024-06-13 21:52:56 ptrc: lertting cringe phoronix forum threads decide policy probably isn't the best idea ;) 2024-06-13 21:53:09 oh, no, the issue is that there's no policy 2024-06-13 21:53:41 but going through the TSC to establish a policy is probably gonna take 3 months at least 2024-06-13 21:54:01 close away and let any complainers deal with summoning the TSC 2024-06-13 22:21:09 why would they mine on musl distro anyway? 2024-06-13 22:39:32 faster, probably. 2024-06-14 06:42:41 Makes installations of miner software easier also in Docker environments... 2024-06-14 12:58:11 vscode remote ssh test is done on x86_64 chroot 2024-06-14 12:59:24 now it only needs bash, curl, libstdc++, procps-ng 2024-06-14 13:00:21 microsoft has do special build for alpine :) 2024-06-14 13:20:46 so there is no need to pack these dependencies as meta-package 2024-06-14 15:34:49 ACTION 2024-06-14 16:20:14 could someone please take a second look at !67570? 2024-06-14 19:35:15 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/67704 yay another version :) 2024-06-15 11:28:02 Could I interest someone in reviewing !67391? It fixes #16190 (will also need a backport). 2024-06-15 11:29:36 I feel a bit guilty that I did not test installing a minimal TeXLive environment in a clean environment and what to at least have the fix out soonish :/ 2024-06-15 17:42:25 ptrc: just 3 months? 2024-06-15 21:34:06 panekj: i try to be optimistic :) 2024-06-15 21:36:41 i have trouble with nl.alpinelinux.org, upgrades timeout with bigger packages. when switching to a different mirror everything works fine. 2024-06-15 21:39:40 nl.alpinelinux.org resolves as t1.alpinelinux.org 147.75.40.42 2024-06-15 21:40:59 yMVV_HsHcX0: from where are you trying to download? 2024-06-15 21:41:20 These are servers with big pipes, spread over 3 locations 2024-06-15 21:53:27 i run wireshark and strace on them, and it looks like suddenly the transmission stops. 2024-06-15 21:53:57 you should use dl-cdn.a.o instead of nl.a.o 2024-06-15 21:54:23 ok, but that doesn't solve the problem that one of the servers has. 2024-06-15 21:54:37 my problem is solved by switching to a different mirror, no question. 2024-06-15 21:55:01 t1. is not really a mirror it's a source for everything else 2024-06-15 21:55:05 i just wanted to report that something weird os going on. 2024-06-15 21:55:30 s/ os / is / 2024-06-15 21:58:48 in my strace apk upgrade gcc the process was hanging in a read on fd 7 (the network socket), in my wireshark i saw no strange packets suddenly when the download stopped, no fins no rsts nothing else of interest 2024-06-15 22:01:03 yMVV_HsHcX0: what is the latency to t1.alpinelinux.org? 2024-06-15 22:01:14 (of course fins/rst would have closed the socket and aborted apk instead of hanging) 2024-06-15 22:01:41 ping says: 64 bytes from 147.75.40.42: seq=0 ttl=54 time=7.784 ms 2024-06-15 22:02:10 ok, so it does goes to the closest server as spected 2024-06-15 22:02:50 yMVV_HsHcX0: do you get the same issues if you download directly from nld.t1.alpinelinux.org? 2024-06-15 22:03:11 let me check a big file from there... 2024-06-15 22:11:59 i tried apk fix -r rust, and indeed the same symptom 2024-06-15 22:18:55 just downloaded a 1G file from there without issue 2024-06-15 22:18:57 https://nld.t1.alpinelinux.org/alpine/edge/community/x86_64/xonotic-data-0.8.6-r0.apk 2024-06-15 22:21:18 curl produces the same symptom for this file ^^^ 2024-06-15 22:21:43 after 21.1M 2024-06-15 22:22:40 hmm, 2nd attempt is better 2024-06-15 22:31:45 hi guys is gamescope package abandoned? 2024-06-16 15:31:34 hi 2024-06-16 15:33:07 greets 2024-06-16 15:34:29 how to contribute to alpine, it is necessary to have a professionnial level in programming ? 2024-06-16 15:35:18 Guest9800: Alpine Linux is not primarily a programming project 2024-06-16 15:35:52 Most people contribute by providing and maintaining packages 2024-06-16 15:37:30 the packages on alpine are the same than on others distributions no ? 2024-06-16 15:37:47 sorry for my english 2024-06-16 15:40:56 with aports ? 2024-06-16 15:42:28 i m not a professional and i search to understand the contribution system of linux distribution, in this case alpine because i have that 2024-06-16 15:42:38 what do you mean by "the same"? 2024-06-16 15:43:56 the packages on alpine is essentialy the same than others distribution 2024-06-16 15:44:04 for example 2024-06-16 15:44:07 well 2024-06-16 15:44:19 hexchat is available on debian fedora too 2024-06-16 15:44:21 generally distros patch packages and change things for their own purposes 2024-06-16 15:44:27 so things may be a bit different 2024-06-16 15:44:49 and not every distribution has the same set of packages 2024-06-16 15:44:52 yes 2024-06-16 15:45:06 it's that providing an maintaining packages 2024-06-16 15:45:15 not to mention different versions of packages, etc. 2024-06-16 15:45:27 the script is not the same 2024-06-16 15:46:33 ok it's essentialy sh ash script ? 2024-06-16 15:46:45 APKBUILDs are shell scripts, yea 2024-06-16 15:47:34 ok i understand 2024-06-16 15:49:15 programming knowledge can definitely be useful for package maintenance (particularly when trying to fix issues in packages), but it's not necessarily required 2024-06-16 15:49:37 it helps a lot though 2024-06-16 15:50:30 shell script is the principal tool to use 2024-06-16 15:51:17 yes, but at some point you'll find a bug in the package itself (not the APKBUILD) and being able to dig into code to debug it is invaluable in such cases 2024-06-16 15:51:35 just use the APKBUILD page on the wiki 2024-06-16 15:51:52 was good enough fornme to package my program on aports 2024-06-16 15:52:48 https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2024-06-16 15:52:59 also this 2024-06-16 15:53:00 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2024-06-16 15:53:02 thx 2024-06-16 15:53:28 just copy from others and you should be good 2024-06-16 15:54:14 send a merge request on GitLab, fix issues CI reports and repeat till your fix it, or until you give up :) 2024-06-16 15:54:35 my biggest piece of advice is: if you get stuck, ask 2024-06-16 15:55:23 Amen to that, only thing I got for asking questions was praise for contributing :) 2024-06-16 16:05:36 how many people contribute to alpine ? 2024-06-16 16:05:44 appoximatively 2024-06-16 16:33:15 based on the latest stable release notes, ~313? https://alpinelinux.org/posts/Alpine-3.20.0-released.html 2024-06-16 16:34:56 but there are more people silently maintaining packages that might not be listed if the packages haven't needed updating 2024-06-16 16:35:27 ah, they left ^^" 2024-06-17 06:33:43 Hello ! I would like to unlock my root drive using clevis with tang server pin which is inturn connected through internet (wan). I am unable to configure mkinitfs to load network and call clevis unlock. Would appreciate if somecan can guide me in the right direction 2024-06-17 14:31:25 hi, I've been porting some love games to mobile and I think they would be an interesting adition to postmarket os, however I'm not an alpine user and don't know how to build apk, maybe someone could build them so that it can be added to postmarket os app store? 2024-06-17 14:49:53 ikke: I have realized that MRs that I send as the maintainer of a package taken longer to be merged than when I somebody else sends an MR that I "approve" as a maintainer 2024-06-17 14:50:25 Is this something others are experimenting? Maybe would be worth to add "mainteiner-mr" label or something? 2024-06-17 14:55:26 I have not had a lot of time to look at MRs myself, but for me those are the first I'd look for and not hard to find 2024-06-17 14:56:15 Ok, thanks! 2024-06-17 14:57:51 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?scope=all&state=opened&draft=no&assignee_id=None 2024-06-17 15:02:33 I see, that's a lot 😅 2024-06-17 18:41:13 i thikn a "maintainer-mr" label would be helpful 2024-06-17 18:42:05 i wonder if you can approve it yourself, to flag it can be fast-tracked? 2024-06-17 19:01:37 that sounds like a good idea, maybe it would help reviews go more smoothly, there's some assurance that you're working directly with someone who owns the problem and is willing to fix it 2024-06-17 19:02:07 or rather not more smoothly, but push things to the top that are immediately actionable 2024-06-17 19:22:38 ncopa: it might be possible to self-approve MRs, but right now we don't assign maintainers if they are the authors of the MR 2024-06-17 19:23:01 So probably either we add a label, or we change the behavior. Both are pretty simple to do regardless 2024-06-17 20:45:39 what's broken with the 3.20 builders? 2024-06-17 20:46:30 err 2024-06-17 20:46:39 pkgs.a.o shows outdated info 2024-06-17 20:47:02 https://ptrc.gay/vetNMNYX 2024-06-17 20:47:10 even though it is 1.6.0 in the actual apkindex 2024-06-17 20:58:17 i guess something weird is also going on with the CI runners (!67808) 2024-06-17 20:58:38 fossdd: yeah, ptrc mentioned it in the #-infra channel 2024-06-17 20:58:44 one MR ate all inodes on the builders 2024-06-17 20:58:54 ooh, which one? :p 2024-06-17 20:59:06 Posted it in the other channel 2024-06-17 20:59:40 ah 2024-06-18 05:03:25 are there any particular guidelines about when i should make a request to move an aport i maintain from testing to community? 2024-06-18 05:04:46 (in my case it's a font, so there isn't much to test, but i am also curious if there are general guidelines) 2024-06-18 07:49:40 selene: there are no good reasons to delay it 2024-06-18 07:51:18 alright, just wanted to make sure 2024-06-18 07:51:24 thank you! 2024-06-18 08:01:03 i am slightly frustrated of the security.a.o UX. I have woerked on fixing a CVE in cups in all supported branches. Now that I am almost done, I discover that there were more open CVEs. I have solved those by updating to 2.4.9, but I havent updated the secfixes comment because I was not aware of it 2024-06-18 08:01:14 now I need to go back and fix 2024-06-18 08:02:46 actually, no. seems like it was updated 2024-06-18 13:57:12 ncopa: yeah secfixes doesn't need to be updated if you upgrade past the version tied to the CVE. so, if upstream fixes a change, you shouldn't need to put anything in secfixes. it's utility is for backporting patches to versions that are normally vulnerable, but some maintainers list all CVEs in secfixes 2024-06-18 13:57:54 s/it's/its/ 2024-06-18 14:22:36 There's a bit of a debate about that 2024-06-18 14:23:20 Technically it should not be necessary, but some scanners are 'stupid' and assume it's not fixed if we do not declare it as such 2024-06-18 14:27:04 ncopa: i have and still am trying to improve security.a.o 2024-06-18 14:28:17 One issue that I'm wondering about is that it unpublishes all but the latest versions of a package, which impacts what fixes are shown 2024-06-18 14:29:20 One thing that does not help either is that nvd mostly stopped augmenting cve data 2024-06-18 14:31:34 how does it impact which fixes are shown? 2024-06-18 14:34:30 does this look good? https://gitlab.alpinelinux.org/ncopa/alpine-mksite/-/blob/alpine-3.20.1/posts/Alpine-3.20.1-released.md 2024-06-18 14:35:07 ncopa: iirc, it only shows fixes for package versions that are marked as published 2024-06-18 14:36:15 so if version 1.0.1 contains the fix, and that package is in repo, it will show it, but it will remove it as fixed when 1.0.2 is pushed? 2024-06-18 14:36:36 do you think you could create a testcase for it in the testsuite? 2024-06-18 14:37:28 Either that, or it will only add fixes for a published version 2024-06-18 14:37:43 So if you add it to an older version, it will not be added 2024-06-18 14:38:00 oh, right 2024-06-18 14:38:33 I think it should keep a version as published once it's published 2024-06-18 14:39:07 how do we dealwith reverts? lets say a CVE fix is reverted due to a regression 2024-06-18 14:39:19 and the regression is worse than the CVE, which may be bogus 2024-06-18 14:40:16 anyone knows exactly which files/dirs wayland/sway need access to use the gpu? 2024-06-18 14:40:49 or if there's a way to run windows as another user(not root) in sway 2024-06-18 14:41:22 ncopa: we briefly talked about that earlier 2024-06-18 14:42:12 We have no way atm to mark a cve as rejected in our secdb 2024-06-18 14:51:59 i mean, unfix a CVE 2024-06-18 14:52:22 not reject the CVE as "wontfix" 2024-06-18 15:13:31 ncopa: I don't we have anything for that atm. If necessary we can manually remove it from the DB 2024-06-18 15:13:48 ok 2024-06-18 17:43:05 Hello amk. Could you approve !67760 please? 2024-06-18 18:40:09 raspbeguy: approved, sorry for the delay, home internet has been dead for a while 2024-06-18 19:03:44 amk: ouch, sad to hear 2024-06-18 19:31:33 ikke: can you help me with an announcement on fosstodon? 2024-06-18 19:31:39 yes 2024-06-18 19:48:03 ncopa: done 2024-06-18 19:48:19 https://fosstodon.org/@alpinelinux/112639345374380262 2024-06-18 19:48:48 amk: thanks. Hope you catch back your internet soon 2024-06-18 19:54:31 ikke: thank you! 2024-06-18 19:58:46 ncopa: grats on the release! \o/ 2024-06-18 20:03:43 thanks! finally got it out \o/ 2024-06-19 04:59:39 aports 2024-06-19 04:59:39 testing 2024-06-19 04:59:39 vim-airline 2024-06-19 05:01:07 sorry for multi-line but i find this port's last update is 3 years ago 2024-06-19 05:03:43 Last release of that project was in 2019, so not supprising 2024-06-19 05:04:09 https://github.com/vim-airline/vim-airline/releases/tag/v0.11 2024-06-19 05:07:24 according to the aports:README, should we move it from testing or just remove? 2024-06-19 05:10:01 qaqland: if it's working for you, you can propose to move it to community 2024-06-19 09:59:29 \o/ (late) 2024-06-19 10:04:43 \o/ 2024-06-19 10:04:59 Even the bot is happy about this new release :) 2024-06-20 08:41:34 i just noticed --security in abump, neat 2024-06-20 12:36:04 Habbie: thank you for sharing 2024-06-20 13:29:44 why do we only build compiler-rt and llvm-runtimes for the "default" llvm version? this pretty much breaks all other llvm versions that want to use compiler-rt 2024-06-20 13:51:28 back when it was added there was only one clang version 2024-06-20 13:51:41 you only need a matching compiler-rt per clang 2024-06-20 13:51:44 for some stuff 2024-06-20 13:52:22 so also when more clangs got added, those things didn't need it 2024-06-20 13:52:37 since the first reason to add an older clang was postgres 2024-06-20 13:53:08 you could make default build the default runtimes and the older ones build only compiler-rt and it should be fine 2024-06-20 13:53:13 libcxx/unwind can be left out 2024-06-20 13:54:17 ah, makes sense i guess 2024-06-20 15:53:45 Hi (maybe it's more appropriate here), are the Alpine releases build log available somewhere? More precisely, can I find how alpine-minirootfs-3.20.1-x86_64.tar.gz is build and what were the build logs for this release? 2024-06-20 16:02:03 lxdr742: I don't think we have logs for that 2024-06-20 16:22:35 if there's any dev 2024-06-20 16:22:39 please check this 2024-06-20 16:22:40 https://tpaste.us/KEqg 2024-06-20 16:22:56 I think latest virt-manager needs to be downgraded 2024-06-20 16:23:14 cannot install/import virtual machines 2024-06-20 16:23:31 previously it never happened 2024-06-20 16:23:49 4.1.0 2024-06-20 17:23:16 ok so I found the scripts (https://gitlab.alpinelinux.org/alpine/aports/-/tree/3.20-stable/scripts ; any clue for the logs ? I suppose it's not ran manually), and I think there's an issue: when building minirootfs (at least), apk add is run with --no-script (https://gitlab.alpinelinux.org/alpine/aports/-/blob/3.20-stable/scripts/genrootfs.sh#L33), 2024-06-20 17:23:16 but this means busybox.post-install is not executed, however this script contains user + group creation (https://gitlab.alpinelinux.org/alpine/aports/-/blob/3.20-stable/main/busybox/busybox.post-install), so in the end images created with this script are missing them 2024-06-20 17:23:24 I found about this because I'm building an app based on the Alpine Docker image using an user with fixed uid+gid, it was building fine a few weeks ago, but recently busybox was updated (https://gitlab.alpinelinux.org/alpine/aports/-/commit/1747c01fb96905f101c25609011589d28e01cbb8), and as I run apk upgrade, the busybox.post-upgrade script executes 2024-06-20 17:23:24 (https://gitlab.alpinelinux.org/alpine/aports/-/blob/3.20-stable/main/busybox/busybox.post-upgrade), creates the klogd uid+gid and my build fails as it reuses the same gid ; obviously the fixed uid+gid is my mistake, but the minirootfs should already contain this user+group, shouldn't it? Should I report this somewhere, and if so where? 2024-06-20 17:25:33 lxdr742: you can report it in the aports project 2024-06-20 17:39:19 lxdr742: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/genrootfs.sh#L33 2024-06-20 17:48:16 lxdr742: technically the output is logged, the problem is that it's overwritten 2024-06-20 18:54:45 who did the llvm 18 switch? 2024-06-20 18:55:19 because clang wasn't switched, and a lot of packages with "upgrade with llvm" weren't bumped either 2024-06-20 18:55:40 I recall that andypost[m] did it 2024-06-20 18:56:00 yeah, just found !66405 2024-06-20 18:57:15 should've been the same MR as llvm i guess.. 2024-06-20 19:37:13 Iirc ncopa decided to split before release 2024-06-20 19:37:21 Will it be ok if I upgrade existing skaware-man-pages aports and add new one (tipidee-man-pages) in a single pull request? 2024-06-20 19:44:10 sure 2024-06-20 20:50:43 ptrc: Heya, I think firefox cannot be rebuild anymore with current edge repo. Can I somehow verify it works? 2024-06-20 20:52:17 DavidHeidelberg: i'm currently on it, although the entirety of llvm ecosystem is in a bit of a mess right now, so it might take a moment 2024-06-20 20:53:07 depending on your use case you might try building it against 3.20 aports? it should still work there 2024-06-20 20:55:05 ptrc: good point, thanks, I'll try go against 320 2024-06-20 21:03:00 btw. LLVM at his best. I found lot of workflows are done under X11, we can probably switch PGO on Weston (depends if it'll work well) to get better perf for apps 2024-06-20 21:06:26 don't think you can run firefox headless under weston due to gtk3 seat stuff since weston doesn't implement them for headless 2024-06-20 21:06:29 see this ancient meme https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/209 2024-06-20 21:06:37 but cage or whatever might work 2024-06-20 21:06:57 if it was gtk4 or not gtk it would be fine 2024-06-21 06:47:51 ptrc: sorry for the llvm18/clang18 mess 2024-06-21 06:48:19 its significantly complex to maintain various version of llvm 2024-06-21 06:48:28 ptrc: and thank you for helping cleaning it up 2024-06-21 06:49:08 re for 3.20 release, we had the llvm18 MR open for months, but nobody had the time (or competence) to report the failing test issues upstream 2024-06-21 06:49:57 it was only sorted out after the 3.20 builders were almost done and at that point we thought it was too risky to make it default llvm/clang 2024-06-21 06:50:58 also the llvm18 MR was blocked by the riscv64 which had various emergencies 2024-06-21 07:08:21 What is the default provider_priority of a package? (E.g. when it is not explicitly set.) 2024-06-21 07:20:27 There is none 2024-06-21 07:20:49 They should always be set explicitly for virtual provides 2024-06-21 07:21:26 For concrete provides, the version is used primarily 2024-06-21 07:45:09 So a foo-git package in version 0_git202xxxx that would also provide foo would not be installed if I ask for package foo (which has, say 1.2.3 as version). But I could explicitly ask to install foo-git and that would replace foo and still satisfy dependencies to foo, correct? 2024-06-21 07:47:35 Depending on the situation, apk could show a conflict if there is nothing to decide the o priority 2024-06-21 08:17:43 OK, I think it will do what I want it to do. I'll just check to be sure. 2024-06-21 08:52:41 Just make sure you either use concrete provides, or virtual provides with a priority set 2024-06-21 13:13:32 im thinking of adding an autoinstall feature to tiny-cloud 2024-06-21 13:16:16 currently it is possible to do a fully unattended headless install with this user-data: https://tpaste.us/D71X 2024-06-21 13:16:56 i'd like to have a shortcut for the runcmd there 2024-06-21 13:17:34 Is it worth to try make something compatible or similar to ubuntu? https://canonical-subiquity.readthedocs-hosted.com/en/latest/reference/autoinstall-reference.html#storage 2024-06-21 13:19:15 or should we do our own simple thing? for example: https://tpaste.us/BJbk 2024-06-21 13:21:10 maybe something like this to disable swap, enable lvm and use xfs as root file system: https://tpaste.us/b1v1 2024-06-21 13:22:50 or do we want something that is similar to ubuntu: https://tpaste.us/7Mxo 2024-06-21 13:27:17 or do we want have something similar to arch linux: https://archinstall.archlinux.page/installing/guided.html#example-usage 2024-06-21 13:45:47 If you have any opinions on the config format, please add a comment: https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/issues/59 2024-06-21 20:18:48 ptrc: do you know if this line "LLVM Profile Error: Failed to write file "default_38062_random_12651472238175182002_0.profraw": Broken pipe" is OK? looking at https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/firefox/firefox-127.0-r0.log 2024-06-21 20:19:24 I switched the profiling to Weston, except few GDK warnings about grabbing keyboard it seems it passed (but that's probably because I do Wayland-only build & run) 2024-06-21 20:19:29 to be fair, i haven't had a profiling run where it doesn't happen 2024-06-21 20:19:34 i'm not sure what causes that 2024-06-21 20:19:41 haven't gotten around to debugging 2024-06-21 20:20:07 have you checked the profiling changes something within the build? 2024-06-21 20:20:13 (size, speed whatever)? 2024-06-21 20:26:57 what do you mean? 2024-06-21 20:27:22 in general, that binary differs in a "good way" from unoptimized binary 2024-06-21 20:29:37 did some checks, but it was ages ago 2024-06-21 20:36:34 then it's likely fine :) 2024-06-21 20:36:50 ACTION forgot to bump timeout to 2h and got timeouted on Firefox profiled build... 2024-06-21 20:46:16 oopsie, Debian doesn't even do PGO... and I'm just using the default Firefox build there..... 2024-06-21 22:44:16 https://gitlab.alpinelinux.org/dh/aports/-/jobs/1427655/artifacts/file/packages/community/aarch64/firefox-127.0-r1.apk w/o Wayland (-1M, just for fun if it'll work) and with weston perf optimizations.. need to check the perf somehow 2024-06-22 15:25:21 I'm in a bit of a bind here 2024-06-22 15:25:46 There's a Rust package, which seems to compile and work just fine 2024-06-22 15:26:01 But it has a lot of unsafe in it, and one of the 300 tests is segfaulting 2024-06-22 15:27:15 Would this qualify for !check? The tool is a formatter, so it's not _that_ critical 2024-06-22 15:28:04 it's just one test 2024-06-22 15:28:08 i would investigate that test 2024-06-22 15:28:13 and if i can't figure it out, maybe just skip it 2024-06-22 15:28:24 one test failing isn't worth disabling all of them 2024-06-22 15:28:59 I'll try to track down that test then 2024-06-22 15:29:21 what's the project and what's the segfault? 2024-06-22 15:31:48 dprint 2024-06-22 15:31:51 https://github.com/dprint/dprint/issues/864 2024-06-22 15:33:49 that doesn't look like a segfault 2024-06-22 15:33:55 > process didn't exit successfully: `/home/kaathewise/fork/dprint/target/debug/deps/dprint-ada9ff8ad2d279ac` (signal: 6, SIGABRT: process abort signal) 2024-06-22 15:33:59 says SIGABRT 2024-06-22 15:34:58 i'll try to reproduce it on my distro, but can't guarantee i'll get the same issue 2024-06-22 15:39:04 tests pass for me 2024-06-22 15:40:16 if you can grab a stacktrace that'd be useful 2024-06-22 15:44:51 This has to be a feature, because rust is the safest language and can't fail 2024-06-22 15:52:11 triallax: for some reason setting RUST_BACKTRACE doesn't change anything 2024-06-22 15:52:18 it's still the same sigabrt 2024-06-22 15:52:27 well 2024-06-22 15:52:30 ulimit -c unlimited 2024-06-22 15:52:32 rerun the tests 2024-06-22 15:52:42 then a corefile _should_ be spewed out somewhere, i hope 2024-06-22 16:05:05 No coredump, but I ran it under GDB, and it does indeed seem to be musl 2024-06-22 16:05:11 `__restore_sigs (set=set@entry=0x7ffff3f28f70) at ./arch/x86_64/syscall_arch.h:40` 2024-06-22 16:05:26 gimme the output of bt 2024-06-22 16:05:33 that line doesn't mean much, it's just related to the signal 2024-06-22 16:07:21 Oh, right, it's a completely separate thing 2024-06-22 16:07:59 https://paste.sr.ht/~kaathewise/18d04acbe3bef125bba9899a8abdd8bcf494f465 2024-06-22 16:08:48 that frankly looks utterly cursed 2024-06-22 16:08:56 The binary itself has 74 instances of unsafe 2024-06-22 16:10:29 Wait, am I reading this wrong, or did it panic twice? 2024-06-22 16:10:38 i don't know 2024-06-22 16:10:40 i'm not even trying to read that 2024-06-22 16:13:20 triallax: "Rust signatures are so thorough, they act as documentation" :D 2024-06-22 16:13:42 idk i'm not a rust person 2024-06-22 16:14:00 Well, it's kind of clear 2024-06-22 16:14:01 #47 0x0000555557d73abb in std::panic::catch_unwind>, ()> (f=) 2024-06-22 16:14:23 that is true 2024-06-22 16:14:34 so it's a segfault 2024-06-22 16:14:58 i don't know if it's useful, but maybe post the backtrace to the issue 2024-06-22 16:15:13 Why it happens though, might not be clear :D 2024-06-22 16:15:37 quinq: can you elaborate pls, I still can't make sense of the backtrace 2024-06-22 16:15:50 │ access memory at address 0x0 2024-06-22 16:15:50 > Cannot 2024-06-22 16:16:03 0x0, so NULL 2024-06-22 16:16:24 oh 2024-06-22 16:17:07 Looks like the clone syscall is mishandled 2024-06-22 16:28:56 I posted it, but given the amout of unsafe and the fact it only fails on Linux, I doubt much will come of it 2024-06-22 16:29:24 I think I'll just use Deno. Have you heard of this CTO blog post? 2024-06-22 16:29:50 *CDO 2024-06-22 16:30:02 i don't really bother with javascript in general 2024-06-22 16:31:08 I knew things were bad, but I didn't expect everything to be that bad 2024-06-22 16:31:25 At least Deno packages all of it into a single neat binary, which for now doesn't leak 2024-06-22 20:37:24 folks, /proc/slabinfo is missing 2024-06-22 20:37:30 at least on x86_64 2024-06-22 20:40:22 due to undefined CONFIG_SLUB_DEBUG 2024-06-22 21:11:17 It's not missing 2024-06-22 21:11:57 it's not there on linux-lts on 3.20 2024-06-22 21:12:27 Correct 2024-06-22 21:12:32 so it's missing 2024-06-22 21:12:39 No 2024-06-22 21:12:45 i'm confused 2024-06-22 21:12:48 It just doesn't exist 2024-06-22 21:13:00 well yeah, it breaks slab analysis 2024-06-22 21:13:05 and slabtop for example 2024-06-22 21:14:37 slabtop doesn't exist on alpine linux either 2024-06-22 21:14:43 what? 2024-06-22 21:15:07 /bin/slabtop is owned by procps-ng-4.0.4-r0 2024-06-22 21:15:16 Right, my mistake 2024-06-22 21:15:49 even without slabtop it's still a valuable data point and not having it enable is a big issue for us on servers 2024-06-22 21:19:59 Then that'd be a better way to formulate the request 2024-06-22 21:20:22 I suggest you open a ticket for that feature request, explaining why you'd like to have it integrated into the distro 2024-06-23 08:08:59 what's the deal with CMAKE_CROSSOPTS="-DCMAKE_SYSTEM_NAME=Linux -DCMAKE_HOST_SYSTEM_NAME=Linux" ? is it needed for anything? 2024-06-23 08:52:18 it's some cross compile thing but i'm pretty sure i removed them before and it still worked 2024-06-23 08:52:28 it would be pretty funny if cmake can't guess that 2024-06-23 09:29:50 at the very least the former definitely defaults to the latter 2024-06-23 09:34:53 Indeed 2024-06-23 09:34:54 CMAKE_SYSTEM_NAME is by default set to the same value as the CMAKE_HOST_SYSTEM_NAME variable so that the build targets the host system. 2024-06-23 09:35:12 And: CMAKE_HOST_SYSTEM_NAME, On systems that have the uname command, this variable is set to the output of uname -s. 2024-06-23 09:35:43 So unless you build without uname(1) support, it wouldn't be needed 2024-06-23 09:36:17 anyone up for dropping that from aports en masse and seeing what breaks? :-) 2024-06-23 09:37:30 Of course, that's from latest version documentation, who knows what happens on the version that apline distributes… 2024-06-23 09:39:23 ok, it seems to be the same for 3.29 2024-06-23 09:39:43 https://cmake.org/cmake/help/v3.29/variable/CMAKE_SYSTEM_NAME.html#variable:CMAKE_SYSTEM_NAME 2024-06-23 10:08:16 ovf: not sure if it would be properly tested, as by default we do not do any cross compilation 2024-06-23 12:26:10 ikke: does alpine ever cross compile things? 2024-06-23 12:53:02 Generally only the toolchain for new architectures 2024-06-23 16:18:01 why heredoc in post-install need to print to stderr 2024-06-23 16:18:54 thanks for the comment but I don't know why !68086 2024-06-23 18:22:21 Iat happened, I made account on the Alpine gitlab. 2024-06-23 18:22:27 \o/ 2024-06-24 21:39:02 so apparently even with llvm 18 rebuilt, firefox is still segfaulting in compiler-rt 2024-06-24 21:39:18 i'm running out of ideas how to debug this 2024-06-24 22:43:47 if it is a segfault in compiler-rt, it is likely because the input to one of the compiler runtime support functions was wrong 2024-06-24 22:43:58 i would look a few frames up the stack 2024-06-24 22:44:23 probably has nothing to do with llvm, probably an alignment issue 2024-06-25 01:01:00 Ariadne:can you share backtrace ? 2024-06-25 01:01:16 I mean ptrc 2024-06-25 06:51:34 ptrc: have you ever noticed some kind of memory leak in Firefox? I have a vm with 20G memory, and after a day of running, almost all memory has been eaten. Right now, firefox uses ~14G RSS 2024-06-25 07:09:17 i dont remember it being different with firefox 2024-06-25 07:09:43 i have to restart firefox every 2-3 hours because i only have 4G memory 2024-06-25 08:23:46 I noticed mirrors.bfsu.edu.cn removed the alpine mirror about 3-4 months ago. They return 301 and redirect to mirrors.tuna.tsinghua.edu.cn. Should it be removed from our mirror list? 2024-06-25 08:27:04 Our monitoring does not get a redirect 2024-06-25 08:27:26 Are subfolders redirected? 2024-06-25 08:31:37 oh, sorry, it's my browser's cache. Seems their add the mirror back recently. 2024-06-25 08:32:18 BTW, mirrors.hust.edu.cn sent a request to include their mirror, but hasn't get response: https://github.com/ust-open-atom-club/hust-mirrors/issues/13 2024-06-25 08:33:02 https://github.com/hust-open-atom-club/hust-mirrors/issues/13 2024-06-25 08:34:54 khem: https://ptrc.gay/GVIsawiA 2024-06-25 08:36:57 lindsay: sorry, yes, needed to still handle that 2024-06-25 08:40:38 ikke: it's been like that since forever really, even on other Linux distributions 2024-06-25 08:40:44 as in, firefox memleaking 2024-06-25 08:40:59 it shouldn't happen *that* fast though.. 2024-06-25 08:49:20 On this vm, it happens over night 2024-06-25 13:45:12 i gave up at some point in the past and use the official mozilla build (in my hillbilly glibc chroot). still crashes, but mostly with webrtc stuff (zoom.us) 2024-06-25 14:02:55 i've not seen anything i'd characterize as unusual memory consumption in librewolf. i tried forcing it by running various browser benchmarks and crap websites, but it seems fine... 2024-06-25 14:03:34 librewolf also works fine for me with glibc and musl on my gentoo systems 2024-06-25 16:57:15 ptrc: is PGO/LTO enabled for firefox build ? 2024-06-25 16:57:25 yes, both 2024-06-25 16:57:56 also, i'm pretty sure i figured out what was causing the issue with the weird segfaults 2024-06-25 16:58:34 it was building with rust built against llvm17, but using llvm18 itself 2024-06-25 17:05:08 hmm how would that happen the llvm .so are versioned 2024-06-25 17:06:51 clang is 18 2024-06-25 17:07:02 rust is llvm17 2024-06-25 17:07:08 that's what she means 2024-06-25 17:12:45 makes sense, although I would expect the rust compiler and clang compiler to be able to work with their own llvm libraries somewhere the cross is happening it seems 2024-06-25 17:13:58 afaict the issue is with compiler-rt 2024-06-25 17:14:11 i assume(?) rust just includes the code from its own compiler-rt when emitting objects 2024-06-25 17:14:22 and then firefox includes the other version of compiler-rt 2024-06-25 17:16:33 ye 2024-06-25 17:18:57 i c 2024-06-25 17:41:22 Hola 2024-06-25 17:41:42 It seems that mypaint is broken on edge 2024-06-25 17:41:43 ImportError: cannot import name '_mypaintlib' from 'lib' (/usr/lib/mypaint/lib/__init__.py) 2024-06-25 17:42:59 quinq: thanks for reporting, will have a check 2024-06-25 17:43:52 Thank to you, mio :) 2024-06-25 17:49:30 quinq: just wondering, when was the last time you ran a python-related upgrade? 2024-06-25 17:50:37 I upgrade daily 2024-06-25 17:50:39 have an older edge where the current version of mypaint runs without issue, so it's probably something changed recently 2024-06-25 17:50:55 There's no apk upgrade log, is there? 2024-06-25 17:53:57 it's fine then, will try to reproduce the issue 2024-06-25 17:54:27 Sorry I can't help more 2024-06-25 17:54:39 But if I can provide any kind of log, please tell! 2024-06-25 17:54:58 https://clbin.com/rvyAR 2024-06-25 17:55:06 Full output 2024-06-25 17:58:55 thanks, can reproduce a related error, will look into it 2024-06-25 18:14:22 ok :) 2024-06-25 23:22:42 quinq: just put in a MR which should fix the mypaint launch issue 2024-06-25 23:23:05 tested app launches locally 2024-06-26 13:54:39 any chance I could get !65663 and !67781 merged? 2024-06-26 14:22:15 celeste Newbyte: I finally took the time to write some small words on gnome-aports-utils: https://wiki.alpinelinux.org/wiki/GNOME#Updating_GNOME_packages Feel free to ping me if I should write better documentation/instructions in the repo or in the wiki 2024-06-26 14:22:35 Would be lovely if we could use them instead of pushing updates individually (though huge thanks celeste for pushing so many 46.2 updates!) 2024-06-26 14:29:22 How many cores does the builder have? 2024-06-26 14:29:40 kaathewise: depends on the arch 2024-06-26 14:30:24 ncopa: what about the 32bit ones: x86 and armhf? 2024-06-26 14:30:32 PabloCorreaGomez[m]: in the packages list, cheese is both in core apps and deprecated list, so it is deprecated or are there two versions? 2024-06-26 14:31:33 mio: I had some unpushed commits, thanks for the ping 2024-06-26 14:31:40 It's now remove 2024-06-26 14:33:37 okay. ^^ gnome-latex ... it's being renamed to gedit-tex? but maybe from GNOME ecosystem perspective, it's "archived"? 2024-06-26 14:35:33 are the deprecated packages being proposed for removal (e.g. due to no further development) or is it more like, not maintained by GNOME team but others are free to continue maintaining? 2024-06-26 14:35:51 kaathewise: x86: 48 2024-06-26 14:36:02 i think its 24 cores, 48 threads 2024-06-26 14:36:28 armhf: 80 2024-06-26 14:40:57 mio: you can continue maintaining in aports whatever you feel comfortable with :) I think that repository is mostly for "official" things 2024-06-26 14:41:25 PabloCorreaGomez[m]: okay, cheers ^^ 2024-06-26 14:41:42 And we did drew the line, that the alpine's gnome team responsibilities only reach up to core systems/libraries and things in apps.gnome.org/ 2024-06-26 14:41:47 ncopa: thanks! 2024-06-26 14:41:53 s/drew/draw/ 2024-06-26 14:42:36 This explains the OOM for Nushell. Cargo must be trying to launch 48 rustc's, which eat up all of the memory 2024-06-26 14:42:40 But that should not stop anybody from doing more things 2024-06-26 15:09:29 kaathewise: if it just runs out of memory (not being killed by OOM killer), it could also be running out of 32-bits address space 2024-06-26 15:10:16 it can also be out of vm.max_map_count but not in this case 2024-06-26 17:11:31 Thanks, it's a decent start. I'm not sure this is the best place for it however as the article otherwise is for end users as opposed to maintainers. 2024-06-26 17:11:59 But I don't know where we would put information for maintainers 2024-06-26 17:48:45 maybe in the related APKBUILD's, but this may be too much? 2024-06-26 17:58:37 Maybe we can put it at the end under a "maintainers" section? 2024-06-26 21:24:39 I (and at least one other) are getting "bad signature" errors when trying to install calls-46.0-r2 from the Alpine cdn mirror.. but seems to only be that package. Anyonr know what's up with that? 2024-06-26 21:48:42 craftyguy: Possibly CDN issue? I remember there was a command to tell the mirror to re-sync, but cannot find it :( 2024-06-26 21:50:47 seems weird that the signature would be wrong though 2024-06-26 21:51:20 unless what apk really means is that the package is corrupt 2024-06-26 21:57:11 it might be "the signature doesn't match what the APKINDEX says" 2024-06-26 21:57:16 which is very much CDN issue 2024-06-26 21:57:52 craftyguy: which arch and alpine version? 2024-06-26 22:00:09 edge, and x86_64 2024-06-26 22:00:32 aarch64 too 2024-06-26 22:00:44 and maybe other archs? (those are the only two I tested) 2024-06-26 22:03:51 ftr it's `repo-tools fastly purge pkg --release edge --repo community calls` 2024-06-26 22:04:19 does it on all architectures, also yeah i was able to reproduce it on x86_64 2024-06-26 22:05:05 seems to have fixed it 2024-06-26 22:05:10 nice, thank you :D 2024-06-26 22:05:55 do you have to do it for the subpackages too? I get "ERROR: calls-doc-46.0-r2: BAD signature" 2024-06-26 22:06:03 though calls now installs 2024-06-26 22:25:05 `--origin calls` should take care of it 2024-06-26 22:25:08 as in, all subpackages 2024-06-26 22:29:22 ok maybe it just took a minute to propagate or ??. seems to work now. thanks for the help :) 2024-06-26 23:35:22 ah, i meant that i redid the command with the `--origin` parameter :p 2024-06-26 23:35:37 originally only the main calls package was pruned from cache 2024-06-26 23:35:46 ohh ok, mystery solved :P 2024-06-27 00:06:50 Does anyone know if it's possible to use a private repo as a source in an apkbuild? I can't seem to find a reference anywhere to confirm 2024-06-27 00:24:51 durrendal: abuild needs to fetch the source. if it requires auth, you're going to have to include the username/password in the soruce URL 2024-06-27 00:25:03 (or you can fetch the source manually) 2024-06-27 00:31:33 I'm guessing git@ and ssh key auth isn't an option either 2024-06-27 00:37:33 Though actually, if it's all private packaging anyways, a regular old ftp site that my build system can hit locally would be fine. Thank you! 2024-06-27 04:47:07 heya, where is the repo where CI images get built? The stuff which built my pkg in aports repo 2024-06-27 04:47:40 I would like to add section for post build package removal and package installation, so only the main part is more easily available 2024-06-27 04:48:00 also when the built fails, I don't have to scroll trough "apk del" list 2024-06-27 04:59:21 DavidHeidelberg: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh 2024-06-27 05:00:29 DavidHeidelberg: the problem is that we do not control the output until after the build finished (`abuild -r`) 2024-06-27 05:01:44 There are ways around it, but it means manually running each step and making sure nothing is forgotten 2024-06-27 13:50:11 Is there a way to disable tests only for a certain arch? 2024-06-27 13:55:20 I don't have a specific example in mind, but I believe so. APKBUILDs are shell scripts and you can define `options` based on arch 2024-06-27 13:55:32 kaathewise: preferrably is to disable only specific tests, but that depends on the specific test framework. To disable checks completely you can do something like https://tpaste.us/kX17 2024-06-27 14:15:26 Got it, thanks! 2024-06-27 14:16:24 ikke: it seems that the tests are failing due to address exhaustion 2024-06-27 14:16:35 Oh, wait, if it's only one package, I might be able to disable it 2024-06-28 11:22:20 I'm looking for a way to get the nawk APKBUILD to run the tests against the previous version of nawk (the tests are expecting to compare runs by previous build vs new build). Adding nawk to checkdepends has not workded. 2024-06-28 11:29:02 I guess my best bet for now is to continue testing it by building it in clean build container with previous version already installed. This works fine. I could always script something up that will automate it better. 2024-06-28 12:44:31 this works: 'checkdepends="cmd:nawk"' 2024-06-28 12:45:36 What if we are rebuilding that package? 2024-06-28 12:46:23 What if we are bootstrapping a new release? 2024-06-28 12:47:35 yeah, good point 2024-06-28 12:47:44 not so good then 2024-06-28 12:48:04 i mean 'cmd:nawk' 2024-06-28 12:50:34 only thing that comes to mind is to add previous versions' source, built it prior to check then use the built binary from the $previous verion as the oldawk binary... not sure I'm making much sense 2024-06-28 12:52:16 it's a pretty small package, not much overhead to build, most of the overhead is in the tests/checks... would just be good if the tests were doing what upstream is targeting 2024-06-28 12:54:42 as it stands, the tests are comparing busybox's awk against onetrueawk's awk, which is not doing what the expect... checking for regressions since previous version 2024-06-28 12:57:46 I'd include a copy of the expected output instead 2024-06-28 12:59:13 oh, I didn't think of that... will look at doing that now. thanks 2024-06-28 13:03:49 Sometimes also called a golden copy 2024-06-28 13:21:27 Looks not too hard, just needs a script that spits out the test result from the saved run based on the input. And the golden copy, but that won't be hard to generate and will be well worth scripting for future when I need to update the aport again. 2024-06-28 13:50:43 any thoughts on the pidfile discussion/monologue :) in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/67692#note_413555 ? 2024-06-28 13:55:30 dne: i think it's a good solution. Having daemons handle pidfiles should only be done if they run as root, or can create it as root before dropping privileges 2024-06-28 13:56:10 (I don't know whether that's the case for nsd) 2024-06-28 13:57:21 dne: for reference https://github.com/OpenRC/openrc/blob/master/service-script-guide.md#pid-files-should-be-writable-only-by-root 2024-06-28 13:59:19 we were already disabling it via the initscript, so it might just as well be disabled by default 2024-06-28 14:00:00 I just tested on 3.20 and the pidfile got owned by nsd 2024-06-28 14:01:09 Then yeah, it's good to disable it then 2024-06-28 14:02:17 ok, thanks for your input 2024-06-28 15:17:23 2 long running MRs blocking all other MRs 2024-06-28 15:17:51 Why is openssl taking so long? 2024-06-28 18:01:10 ikke: I setup scripting and saved test results for golden copies, got it all to work. Storing the test results may be not so great: https://tpaste.us/JROa 2024-06-28 18:03:39 Ideally upstream should use this approach, but you could treat it as another source file (though that would need to be hosted somewhere) 2024-06-28 18:06:59 That is what I thought, also (abuild treating the results as a source file). I will have to look at options for where to have it hosted. I have a small vps, though it treat it more like a playground/testbed so probably not a good place to put it. 2024-06-28 18:07:08 abuild -> about 2024-06-28 18:07:25 got abuild on the brain 2024-06-28 18:09:03 There is no driving need to update nawk just yet, anyways. Thanks for your input, I appreciate 2024-06-28 18:52:49 I just got an automated message from a bot about a merge request I made a while ago. Patrycja had reviewed and suggested some changes, which I made, pushed and resolved. 2024-06-28 18:54:04 I figure people are busy, but the email implies that I should be doing something, and I'm not sure what. I believe I resolved all of the comments and pushed the changes, and I had been rebasing occasionally, but I thought the ball was now in the reviewers' court. 2024-06-28 18:54:19 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63562 2024-06-28 18:54:19 Which MR? 2024-06-28 18:54:21 ah 2024-06-28 18:54:44 ser: fyi, there is a bit of a backlog which we are working throughy 2024-06-28 18:54:54 Yah, I figured. 2024-06-28 18:55:08 It's not urgent -- it was just the bot made it seem like I needed to do something. 2024-06-28 18:56:15 Hmm, this may be something I'm even interested in 2024-06-28 18:56:16 and it's getting flagged as status:mr-stale ... is there something I should be doing? 2024-06-28 18:56:23 I just removed the label 2024-06-28 18:57:49 Thanks! It eases my mind out here in Alpine, where the distances are great and the scenery monotonous. 2024-06-28 18:58:26 Ok, maybe not an entirely appropriate quote, but one I love. 2024-06-28 18:59:50 Do you know if it supports yubikeys as an extra factor? 2024-06-28 19:00:02 It does not. 2024-06-28 19:00:25 I am not adverse to adding such support; I've been meaning to get a yubikey myself for a while. 2024-06-28 19:01:00 got a nitrokey and can highly recommend it! 2024-06-28 19:01:13 I'd need to check the keepass library I'm using, but the credentials API has more complexity that I'm not taking advantage of. 2024-06-28 19:01:39 So it might. I may just need to hook in an argument. 2024-06-28 19:03:15 I did want to get an actual biometric key. Anyway, that would be the underlying library that would have to support it, although I'd still have to make rook configure the credentials correctly if it did. 2024-06-28 19:03:49 Anyway: no. It does not currently support any second factor. Just a password. 2024-06-28 19:05:44 Ok, because I have a database that requires the 2nd factor, so it would not work with that 2024-06-28 19:07:52 Hm. Testing would be an issue. Let me check the library API. 2024-06-28 19:09:07 ser: I left some feedback 2024-06-28 19:10:13 Do the keys present as key files? 2024-06-28 19:10:44 s/keys/devices/ 2024-06-28 19:10:44 No, it uses a challenge / response mechanism 2024-06-28 19:10:53 Hm. 2024-06-28 19:13:44 Not very detailed, but: https://keepassxc.org/docs/#faq-yubikey-2fa 2024-06-28 19:15:18 Yeah, I mock-created a DB and got to that part; it must be part of the DB credentialling API, but I haven't found it and there are no outstanding tickets, and the library is actively developed. Seems like someone would have filed a ticket about it, so I may be missing something. 2024-06-28 19:16:22 From what I understood, they use it to augment the database key 2024-06-28 19:17:51 https://github.com/keepassxreboot/keepassxc/blob/develop/src/keys/CompositeKey.cpp#L84 2024-06-28 19:18:06 Yeah. The Credentials API is clear about the password and key file mechanisms; I just don't see anything about challenge/response. So either the response becomes part of the password, or it's used like a key file, or I haven't found it in the API yet, or it's not supported by the library. 2024-06-28 19:19:12 ser: The FAQ says there is a difference between keepassxc and keepass2 2024-06-28 19:19:37 I see your comment @ikke; I'll respond in the ticket. 2024-06-28 19:19:57 Which are you using? 2024-06-28 19:20:18 KeepassXC 2024-06-28 19:20:35 isn't keepass2 the original version that's in c# 2024-06-28 19:20:38 "Our implementation differs from how KeeChallenge handles YubiKeys. KeeChallenge uses the HMAC secret directly to enhance the database. To make this work, they need to store the secret in a side-car file, encrypted with the response of a challenge-response pair that is calculated ahead of time." 2024-06-28 19:23:41 Yeah, it looks like they're transforming the key in-place using the response. 2024-06-28 19:24:40 Srsly, it seems as if this is something the library should be doing. I'll look into it, honestly. It's been on my mind a while, as has adding keyfile support. I don't use it, so the itch-scratching motivation has been low. 2024-06-28 19:24:54 Those are good resources, tho, thanks. 2024-06-28 19:48:58 fossdd: are you using your NitroKey with a Keepass DB as a second factor? I wonder if it works the same. 2024-06-28 19:49:59 The keepassxc way of doing it is better, IMO, but if there's that much difference I should probably caveat that I'm focused on KeepassXC b/c that's what I use. 2024-06-28 19:52:14 Yeah, understood 2024-06-28 22:12:26 "/usr/lib/xorg/modules/dri/" shouldn't be it rather "/usr/lib/dri" as everywhere else? it's not xorg thing 😉 2024-06-28 22:16:36 just a legacy location 2024-06-28 22:16:39 should just work to move it tho 2024-06-29 09:52:12 could someone take a look at !68086 2024-06-29 10:42:15 thx ^-^ 2024-06-29 17:05:48 ikke: thanks 2024-06-29 17:40:50 mio: yw 2024-06-29 20:36:22 Hello ! I would like to unlock my root drive using clevis with tang server pin which is inturn connected through internet (wan). I am unable to configure mkinitfs to load network and call clevis unlock. Would appreciate if somecan can guide me in the right direction 2024-06-29 20:36:54 please don't spam multiple channels with questions 2024-06-29 20:37:21 this question belogs in #alpine-linux i guess 2024-06-29 20:38:47 yes 2024-06-29 21:24:36 ser: no. if i got time someday I could check it, but not rightnow. sorry 2024-06-29 22:01:56 do we have a loongarch64 minirootfs? 2024-06-29 22:01:59 or well, anything 2024-06-30 06:02:58 ptrc: https://dev.alpinelinux.org/~loongarch/edge/releases/loongarch64/ 2024-06-30 08:42:02 Anyone knwos a parameter expression which is not possix, supported by ash, but not ${foo/a/b} or ${foo:1:2}? 2024-06-30 09:13:28 phosh 0.40.0 is now ready: !68216 2024-06-30 14:00:17 When submitting a MR for an update to a package, does it need to be reviewed by the package maintainer first before it gets merged? 2024-06-30 14:00:55 jahway603[m]: yes 2024-06-30 14:06:58 ikke, ash.c says only posix ones plus the two you cited 2024-06-30 14:07:21 (well, ${v/p/r} plus ${v//p/r}) 2024-06-30 14:08:21 Yeah, that's what I thought 2024-06-30 14:09:36 https://github.com/koalaman/shellcheck/issues/2865 has a list of other features that bb ash support which are not posix 2024-06-30 14:13:22 I don't understand what that issue is trying to do though 2024-06-30 14:13:39 Isn't this shellcheck tool supposed to warn about non portable sh syntax? 2024-06-30 14:13:52 It doesn't matter what shell it is, there's only one portable standard 2024-06-30 14:14:44 it does do that, but idk if its fully comprehensive 2024-06-30 14:15:42 quinq: it's goal is not to enforce posix sh 2024-06-30 14:16:09 it's goal is to warn about things that do not work for the intended shell, as well as other pitfalls 2024-06-30 14:16:25 if you set the shebang to #!/bin/sh it does show at least some warnings about non-posix syntax 2024-06-30 14:16:33 yes 2024-06-30 14:16:51 This issue says it should also have a mode where you can declare that you use bb ash and use all the features that ash provides 2024-06-30 14:17:22 oh, haha 2024-06-30 14:17:29 "jahway603: yes" <- Is there a process to follow when the package's version hasn't been updated for 2 months, there have been 3 releases since the package's version, and there is a MR in Edge & 3.20-stable to upgrade it to the latest version? 2024-06-30 14:17:30 I'm specifically asking about the synapse package https://github.com/element-hq/synapse/releases/tag/v1.106.0 2024-06-30 14:17:30 Going down the well 2024-06-30 14:17:43 Are they also supporting different shell versions? 2024-06-30 14:17:50 How do they even verify that? 2024-06-30 14:18:07 No, they don't. They have to make some assumptions 2024-06-30 14:18:14 Or do they assume to always have only one release, being the one assumed by that tool 2024-06-30 14:18:18 Yeha… 2024-06-30 14:18:28 Typical of this kind of project 2024-06-30 14:18:32 They are quite conservative though 2024-06-30 14:18:52 Even with the release of posix 2024, they are hesitant to immediately allow the new features 2024-06-30 14:19:03 huh 2024-06-30 14:19:13 So they support different shell, but not different POSIX versions? 2024-06-30 14:19:23 correct 2024-06-30 14:19:31 I see 2024-06-30 14:19:46 Another joke 2024-06-30 14:20:00 Well, don't let perfect be the enemy of good 2024-06-30 14:20:11 shellcheck works well in my experience 2024-06-30 14:20:14 yeah 2024-06-30 14:20:38 my only gripe with it is that it's in haskell and therefore a pain to build because you also have to have ghc 2024-06-30 14:20:55 Yeah exactly 2024-06-30 14:21:00 kind of “you had one job” 2024-06-30 14:21:03 heh yes. I decided to just grab the statically compiled binary from their docker image 2024-06-30 14:21:11 Then for some reason they decided to support work-arounds 2024-06-30 14:21:19 i tend to use shellcheck.net :P 2024-06-30 14:21:44 quinq: mind you, the intended target was bash, not posix shell 2024-06-30 14:21:46 that was added later 2024-06-30 14:21:57 i've always used the posix mode 2024-06-30 14:22:08 And then it's just an average tool that will get people relying on it instead of reviewing, and then add some inline comment to disable checks 2024-06-30 14:22:29 ok ikke, makes sense 2024-06-30 14:22:33 quinq: by definition (of how shells work), you always have to use some judgements 2024-06-30 14:22:43 To verify what kind of extentions you're using etc. 2024-06-30 14:22:52 In general, it's good to quote variables that have spaces, but in some cases, you want the expansion 2024-06-30 14:22:55 So it's not really a shell syntax checker, but rather an extention verifier 2024-06-30 14:23:20 As one can't rely on having a stable non-standard API, like bashism 2024-06-30 14:23:24 It's to warn you about constructs that may work unexpected under circumstances 2024-06-30 14:23:38 But then it doesn't check the actual version, so not sure what's the usefulness 2024-06-30 14:23:39 not a syntax linter per-say 2024-06-30 14:23:59 warning about unquoted variables is not depending on what version of shell you use 2024-06-30 14:24:12 quinq: i don't think you can really judge how useful it is until you try it for yourself 2024-06-30 14:24:12 But then you don't need a tool for that 2024-06-30 14:24:46 quinq: you need a tool to do it consistently, for people who may not be aware 2024-06-30 14:24:49 triallax, of course I can, by knowing its concept, its scope and its limitations 2024-06-30 14:24:52 That you're exposing here 2024-06-30 14:25:00 meh 2024-06-30 14:25:10 Anyway, sorry if I hurt some feelings 2024-06-30 14:25:16 Thanks for explaining :) 2024-06-30 14:25:38 no feelings were hurt, it's just that saying a tool isn't useful with trying it seems a bit unwarranted 2024-06-30 14:25:44 but whatever 2024-06-30 14:25:52 s/with/without 2024-06-30 14:27:20 I mean sure, by definition anything that one can *use* is *useful*, that's why people are buying more things than they need 2024-06-30 14:27:45 Yes, it sounds like it's a companion tool when you're too lazy to review everything 2024-06-30 14:27:53 So it'll catch some problems 2024-06-30 14:27:59 A tool that warns you about dangerous constructs is usefull, even if it's not always perfect 2024-06-30 14:28:01 It's a helper 2024-06-30 14:28:29 even if you review things, it can sometimes catch things you accidentally overlooked 2024-06-30 14:28:36 exactly 2024-06-30 14:29:03 yeah when people make mistakes it's cause they're lazy 2024-06-30 14:29:07 genius analysis 2024-06-30 14:29:25 I don't think so 2024-06-30 14:29:32 But you're entitled to your opinion 2024-06-30 14:30:24 quinq: That's how disasters happen, when people are too confident in their abilities 2024-06-30 14:30:53 Well, you're right there, it goes both ways 2024-06-30 14:31:09 But reviews are there for that reason 2024-06-30 14:31:11 You cross-check 2024-06-30 14:32:27 shellcheck should not be used as a replacment to reviewing code, its complementary to the review process, not always correct, but often can lead to more robust scripts 2024-06-30 14:39:17 ^ 2024-06-30 14:43:15 That's why we run shellcheck in the aports pipelines, but still do a manual review as well 2024-06-30 15:42:57 how do people integrate shellcheck in local builds, is there some way to tell apkbuild-lint to use shellcheck? 2024-06-30 15:43:53 besides writing a custom script to do a quick check 2024-06-30 17:29:59 mio: I have shellcheck integrated in my editor 2024-06-30 18:59:50 ikke: good idea, thanks 2024-06-30 19:02:26 For vim: https://gitlab.alpinelinux.org/Leo/apkbuild.vim (though not maintained anymore) 2024-06-30 19:02:33 But I still use it 2024-06-30 19:02:49 checking in case there was an option in apkbuild-lint hadn't heard about, since ci has integration 2024-06-30 19:03:36 great, bookmarked 2024-06-30 19:03:50 In CI, it runs 3 thigns 2024-06-30 19:04:02 abuild sanitycheck, shellcheck and apkbuild-lint 2024-06-30 19:04:06 they're separate tools 2024-06-30 19:12:55 okay. helpful to know 2024-06-30 23:35:14 ikke: is there any particular reason !64743 isn't using version 16.4.1? that seems to be latest in pypi 2024-06-30 23:35:41 tests passed with 1 warning on x86_64 2024-06-30 23:36:09 could put in a MR if it helps but didn't want to overstep