2025-07-01 06:32:30 Can a package have multiple replaces? Just space-divided like all other variables? 2025-07-01 07:32:53 PureTryOut: yes, check postmarketos-base for an example 2025-07-01 11:23:47 achill: did you report the execinfo.h kernel build issue upstream? 2025-07-01 11:24:04 I'm about to send an email to stable 2025-07-01 11:24:32 i did even fix it 2025-07-01 11:25:57 I saw you sent the fixing patch, but i cant find the report 2025-07-01 11:32:36 i didnt report it, i just tried sending the patch. 2025-07-01 11:32:46 it got picked by andrew morton but now it got dropped again 2025-07-01 11:33:22 ok 2025-07-01 11:33:31 i'm gonna ask again because right now the workflow is really not friendly 2025-07-01 11:37:40 I'm reporting it too 2025-07-01 11:38:42 sending a patch to the kernel is even worse than i expected it to be 2025-07-01 11:45:44 https://lore.kernel.org/stable/DB0OSTC6N4TL.2NK75K2CWE9JV@pwned.life/T/#t 2025-07-01 11:51:45 thanks 2025-07-01 11:51:55 there was a tool to find the right maintainer for a given file 2025-07-01 11:52:19 yeah but the file is maintained by nobody 🙃 2025-07-01 11:53:26 ➜ linux git:(linux-6.15.y) ./scripts/get_maintainer.pl tools/include/linux/kallsyms.h 2025-07-01 11:53:26 linux-kernel@vger.kernel.org (open list) 2025-07-01 11:53:35 scripts/get_maintainer.pl 2025-07-01 11:54:36 gentoo sam recommended me to cc andrew, and also i've red that andrew merges stuff without a maintainer, but somehow he also doesnt "care" 2025-07-01 11:55:18 I'm trying to get Greg's attention 2025-07-01 11:56:59 yeah funnily enough greg responded to my v1 and said i need something more in the commit message, but apparently didnt red my v2.. 2025-07-01 11:57:49 the amount of emails and patches they have to deal with is insane 2025-07-01 11:58:12 so many patches yet so few maintainers to take care of all of them 2025-07-01 11:58:15 thats true indeed 2025-07-01 12:08:29 ncopa: about linux-rpi - According to upstream https://www.raspberrypi.com/documentation/computers/linux_kernel.html they state that their offical rpi kernel may lag behind vanilla linux. So I wonder if it would be OK for alpine to also lag behind linux-lts (so we don't have to bother with merge conflicts downstream) 2025-07-01 12:18:51 I soppse we dont have much choice if we dont have time to deal with the conflicts 2025-07-01 12:19:22 alright, linux kernel report sent. now its time to merge apk 3 2025-07-01 12:20:36 the latest kernel package on rpios is 6.12.25 and based on the stable_20250428 tag 2025-07-01 12:21:45 looks like rpi-6.12.y is already rebased on .35 2025-07-01 12:21:45 git head seems to get patches all the days long - IMHO it doesn't look stable without a official tag 2025-07-01 12:22:15 achill: yes but there are some rpi specific patches and reverts on top 2025-07-01 12:40:38 I'd appreciate to be in the loop of changes to aports I'm the maintainer of, the exception I'm fine with being non-breaking security fixes 2025-07-01 12:44:08 sure 2025-07-01 12:57:22 omni: thanks for letting us know 2025-07-01 12:57:36 and thanks for taking good care of the packages you maintain 2025-07-01 13:37:39 I merged apk-tools 3 2025-07-01 14:17:42 PureTryOut: Do you think you can help follow up the breeze-icons? you need backport the two(?) patches listed here: https://tpaste.us/5Qej 2025-07-01 14:53:13 trying to determine how to replicate abuild check errors that happen on builders, but can't reproduce here or in CI 2025-07-01 14:53:33 it's weird how consistent the errors are on the builders 2025-07-01 14:56:34 jvvv: which package? 2025-07-01 14:56:56 tree-sitter-vimdoc 2025-07-01 14:58:54 ncopa: oh there are fixes for it upstream already? nice! 2025-07-01 15:20:30 ncopa: I backported those commits and it fixed it, the builders are working through the rest of the queue now 2025-07-01 15:32:29 thanks! 2025-07-01 16:21:27 achill: I've just replied to your kernel patch. FWIW this issue could be fixed by simply disabling CONFIG_X86_DECODER_SELFTEST in the config 2025-07-01 16:21:56 (but you probably already knew that :-) ) 2025-07-01 16:22:44 fossdd: hey, chill out 2025-07-01 16:23:30 i already saw the build fail and am working on it 2025-07-01 16:23:49 my toes are starting to hurt 2025-07-01 16:25:56 oh no pressure, i had hoped -vim would work, but ehh 2025-07-01 16:26:16 hopefully with abuild rootbld on a new builder setup we can have builds more reproducible 2025-07-01 16:26:27 this different setup between builder and ci is really annoying 2025-07-01 16:26:54 henrix: didnt knew that, but also didnt look since its an actual issue that should get fixed 2025-07-01 16:29:30 achill: ah, yes, absolutely! I'm just not sure it's worth having it enabled for distro kernels, since it's a debug thing AFAIU 2025-07-01 16:32:32 > 2025-07-01 16:32:32 Perform x86 instruction decoder selftests at build time. 2025-07-01 16:32:32 decoder code. 2025-07-01 16:32:32 idk sounds useful if its only at build time and doesnt effect the user 2025-07-01 16:32:32 This option is useful for checking the sanity of x86 instruction 2025-07-01 16:44:07 yeah, maybe. definitely not my area. I know it's not enabled at least in some distros (debian for ex) 2025-07-01 16:44:24 ... and if x86 instructions aren't being properly generated, that's something that will be easily picked by other means :-) 2025-07-01 16:44:41 ACTION goes back under is rock 2025-07-01 16:52:20 Hello, is here an appropriate place to ask questions about apk-tools codebase ? 2025-07-01 17:47:34 Congrats everybody on the APKv3 getting merged 🥳 2025-07-01 17:56:01 fossdd: oh, you tried that and got nowhere? ugh 2025-07-01 17:56:15 fossdd: I can try ping as well (not that I'm special, but it may look better if someone else does it in short order) 2025-07-01 18:42:58 yeah that might help i guess 2025-07-01 19:06:04 will do 2025-07-01 19:08:20 thanks 2025-07-01 19:08:47 18:52 Hello, is here an appropriate place to ask questions about apk-tools codebase ? 2025-07-01 19:09:02 there's ircs://irc.oftc.net/#apk-tools for that 2025-07-01 19:09:27 but I think here is fine too 2025-07-01 19:09:55 weird that andrew picked it up and it got lost?? 2025-07-01 19:10:07 he normally sends an email when he has to do that 2025-07-01 19:10:11 "OK, thanks for the reminder, I restored this." 2025-07-01 19:10:23 oh sick 2025-07-01 19:10:24 https://lore.kernel.org/stable/DB0OSTC6N4TL.2NK75K2CWE9JV@pwned.life/T/#m859d45c920cd84afee4d3ff58d1ae875133d5616 2025-07-01 19:10:26 amazing timing 2025-07-01 19:10:41 (page was cached for me, shows up on refresh) 2025-07-01 19:10:44 :-) 2025-07-01 19:11:30 oh nice 2025-07-01 19:11:50 sam_: probably lost in some rebasing or something 2025-07-01 19:37:00 thanks _f. I managed to find an answer to my questions but i've joined #apk-tools just in case for the future 2025-07-02 11:40:44 ncopa: btw akpm picked it into mm-hotfixes-unstable again, idk how it will get into linus' tree, but i think its on its way up there 2025-07-02 12:00:20 I saw this https://lore.kernel.org/stable/20250701120920.49cd122526b3032a4db1e218@linux-foundation.org/ yes 2025-07-02 12:00:29 I wonder where I can find it restored? 2025-07-02 12:01:04 here https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/kallsyms-fix-build-without-execinfo.patch or https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-hotfixes-unstable&id=03f24c814303ac27575ddfa7c285719ce3f1c981 2025-07-02 12:02:10 alright. seems like they will accept your fix. which is good 2025-07-02 12:04:57 yea 2025-07-02 12:20:45 the scary part is not them rejecting it 2025-07-02 12:20:50 it's that patches can and do fall through the cracks somehow 2025-07-02 12:20:53 in the biggest foss project we have 2025-07-02 12:20:58 it's all MLs and bandages 2025-07-02 12:21:00 crazy 2025-07-02 12:44:46 yeah, until its in linus tree, i dont get too excited 2025-07-02 12:45:12 it makes me wonder if that happend before and nobody noticed 2025-07-02 13:05:45 well, if something falls through the cracks and nobody notices... it's probably because it wasn't very important in the first place :-) 2025-07-02 13:08:43 not if people rely and trust on the subsystem maintainer to get stuff upstream and dont drop it without further notice 2025-07-02 13:09:53 sure, I agree the process can fail (specially with stable kernels). 2025-07-02 13:10:05 and things work differently depending on the subsystems 2025-07-02 13:11:48 there's code that don't even have a maintainer assigned ;-) 2025-07-02 14:22:32 i don't think it's at all unlike any other large carefully curated collection of code, like say a distribution 2025-07-02 14:23:01 processes differ, things happen, releases eventually get made anyway 2025-07-02 14:24:32 "nobody's perfect" is my point (: 2025-07-03 10:35:23 hi all 2025-07-03 10:42:33 hi 2025-07-03 10:43:02 yay kid i am just been elect back as United Nations Chief Executive Board 2025-07-03 10:43:03 hi bkil 2025-07-03 10:43:03 so how are you all here 2025-07-03 10:43:03 We are releasing AstaraOS-FreeBSD-v15 now 2025-07-03 10:43:03 my name is yohanes patra aka skraito 2025-07-03 10:43:04 nice to meet you all 2025-07-03 10:43:06 hi ncopa 2025-07-03 10:43:27 nice to meet you all 2025-07-03 11:51:35 hi all back ... . 2025-07-03 12:13:33 any ideas why tree-sitter-vim fails on the builders? 2025-07-03 12:20:07 I am not able to reproduce it 2025-07-03 12:33:04 i am losing my mind. why am i not able to reproduce the tree-sitter-vim check error? 2025-07-03 12:33:09 it happens on all builders 2025-07-03 13:00:10 The `Substitute command` test wasn't even run in MR CI, what the hell 2025-07-03 13:02:56 same, tried locally and the two tests that failed didn't run for me 2025-07-03 13:03:46 as in, it didn't run at all, total count at the end was 269, not 271 as the numbering suggests is the total number of tests 2025-07-03 13:06:11 the tests were supposed to be skipped though from the APKBUILD 2025-07-03 13:07:57 "Substitute command" does not even exist in tree-sitter-vim-0.5.0.tar.gz 2025-07-03 13:08:23 oh, my tree is out of date *facepalm* 2025-07-03 13:14:37 those failing tests are supposedly disabled in check() https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/tree-sitter-vim/APKBUILD?ref_type=heads#L20-L22 2025-07-03 13:20:00 i can get the failure to happen locally with aports at 5bd4139d669427b41a683011ef167045cce08c03 (but not at master -- 0.6.0-r0 was reverted and re-updated between 5bd413 and master) 2025-07-03 13:20:49 so... is it possible that the builders' aports checkout is behind? 2025-07-03 13:24:37 !86374 - reverted in 033444aeef559bd30b5e43b523e69c6b156e105b - redone (with test disabling) in !86392 2025-07-03 14:36:41 ncopa: the log is still from a few days ago and not updated 2025-07-03 14:36:56 I know what going on and I will push a fix soon 2025-07-03 14:37:00 ah nice 2025-07-03 14:37:22 tree-sitter stores in XDG .cache 2025-07-03 14:37:30 builders keept old state 2025-07-03 14:37:33 and goes boom 2025-07-03 14:37:37 CI is clean and passes 2025-07-03 14:37:40 oh wow 2025-07-03 14:37:44 yeah 2025-07-03 14:37:55 got help from tree-sitter-vim dev on matrix 2025-07-03 14:38:09 in the future(tm) we'll hopefully be able to build in rootbld 2025-07-03 14:38:19 we need to set HOME or XDG_somthing in abuild-tree-sitter 2025-07-03 14:38:36 we should probably also consider set HOME in abuild 2025-07-03 14:38:41 or at least XDG_HOME 2025-07-03 14:39:03 but for now: we need to set HOME or XDG_somthing in abuild-tree-sitter 2025-07-03 14:39:09 i need a 10 min break 2025-07-03 14:43:27 yeah you deserved it 2025-07-03 14:43:43 but that the logs at build.a.o are out-of-date is really annoying 2025-07-03 14:58:27 its a "break" to deal with other urgent matters 2025-07-03 15:08:24 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86501 we probably need to do this for all tree-sitter-* 2025-07-03 15:08:49 build-edge-armv7 [~/aports/community/tree-sitter-vim]$ ls ~/.cache/tree-sitter/lib 2025-07-03 15:08:49 php.so query.so vim.so yaml.so 2025-07-03 15:08:49 hcl.so php_only.so terraform.so vimdoc.so 2025-07-03 15:12:18 not sure we should set XDG_* in abuild 2025-07-03 15:18:42 maybe together with MOVE_CACHES 2025-07-03 15:24:05 ncopa: thank you for looking into tree-sitter build issues 2025-07-03 15:24:56 jvvv: no worries. I think we may need to similar hack for the other tree-sitter-* packages til we have this sorted out properly in abuild 2025-07-03 15:26:03 i can get mine right now. if the other tree-sitter-* maintainers don't mind, i can work adjusting more 2025-07-03 15:26:26 or we can wait til they also break... :) 2025-07-03 15:27:51 i'm ok with that... i see you mentioned maybe putting it in abuild-tree-sitter, so i am in no hurry, just have available time 2025-07-03 15:28:43 I was wrong. the tests does not run with abuild-tree-sitter, so we cant fix it there 2025-07-03 15:29:06 ah, true, it's 'tree-sitter test ...' 2025-07-03 15:29:13 but we can export the XDG_.. vars in abuild where we also define e.g. the go cache 2025-07-03 15:29:23 yeah 2025-07-03 15:29:44 we could consider override HOME ... 2025-07-03 15:29:53 from abuild 2025-07-03 15:30:31 just my opinion, but i think fixes like this are better in the APKBUILD's themselves, otherwise the 'issue' is glossed over 2025-07-03 15:33:56 in waht folder of aports there is libx11-dev? 2025-07-03 15:34:16 the apkbrowser is your friend: https://pkgs.alpinelinux.org/packages?name=libx11-dev&branch=edge&repo=&arch=x86_64&origin=&flagged=&maintainer= 2025-07-03 15:34:26 its main/libx11 2025-07-03 15:35:09 thanks but often the link is the whole aport 2025-07-03 15:35:45 what? sorry, i dont understand what you mean 2025-07-03 15:36:34 the link in Git repository Git repository 2025-07-03 15:36:37 have a look at "Origin" 2025-07-03 15:37:36 `apk policy libx11-dev` will tell you which repo it comes from (eg main or community) 2025-07-03 15:37:46 the subpackages e.g. libx11-dev are built with the APKBUILD of the origin package (here libx11) which is also the name of the directory in aports 2025-07-03 15:38:36 `apk search --origin libx11-dev` will tell you the aport pkgname the (sub)pkg came from. the "origin" 2025-07-03 15:40:58 there is also a git hash in the apk meta data. you can also use that to find the directory in aports tree 2025-07-03 15:41:33 but I dont know if apk exposes the git hash anywhere 2025-07-03 15:43:52 git show $(apk fetch --stdout libx11-dev | tar -zx -O .PKGINFO | awk '$1 == "commit" {print $3}') 2025-07-03 15:43:56 hackish :) 2025-07-03 15:45:52 thanks. FYI here fatal: not a git repository (or any parent up to mount point /) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). 2025-07-03 15:47:19 the git thingy kinda assumes you have the aports tree checked out already 2025-07-03 16:59:16 has anyone made a tool to translate the isc dhcpd leases file to the format used by another dhcp server yet? 2025-07-03 17:29:38 i dont know any such tool 2025-07-03 17:30:32 Habbie perhaps? 2025-07-03 17:31:38 hi 2025-07-03 17:31:42 i have not 2025-07-03 17:32:31 It is, of course, possible to rewrite the configuration file manually; however, ISC has developed the Kea Migration Assistant (or "KeaMA") tool to make it easier for users to translate their configuration files from one format to the other. (See below for more details about KeaMA.) 2025-07-03 17:32:38 is this anything? 2025-07-03 17:32:45 Hi! Regarding the /usr merge, would some of the alpine devs have thoughts about how to move forward with the implementation: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85504#note_521743 ? 2025-07-03 17:33:01 There's basically a decision to make, on whether migrations should be automatic or manual 2025-07-03 17:33:10 And then the work would be different 2025-07-03 17:33:18 ncopa: this one's probably good for you to have a look 2025-07-03 17:33:25 it is, at least, a more standalone version of the isc dhcpd config parser 2025-07-03 17:33:43 and the output is JSON. Maybe not the JSON you want, but JSON is always a good start 2025-07-03 17:35:22 i cobbled this together: https://gist.github.com/kaniini/821a9eedee96e060ad46fe44393f5148 2025-07-03 17:35:32 i don't want to use Kea 2025-07-03 17:35:40 i figured 2025-07-03 17:35:53 you want to use dnsmasq? 2025-07-03 17:36:06 yes 2025-07-03 17:36:11 i was not expecting that 2025-07-03 17:36:28 why? it's small 2025-07-03 17:37:43 yes, it is. i also found it to not be very good for DHCP. IIRC it can, depending on settings, give out IPs at a max rate of one per 3 seconds 2025-07-03 17:38:01 i like odhcpd, but it's very tied to openwrt 2025-07-03 17:38:21 if i find myself dissatisfied, i can always change it again :p 2025-07-03 17:39:07 yes 2025-07-03 17:39:22 anyway, so, the kea migration assistant looks like a standalone tool, that emits JSON 2025-07-03 17:39:58 i already swapped to dnsmasq 2025-07-03 17:40:17 kea is basically the direct opposite of what i want in a dhcp server, it seems very Enterprise 2025-07-03 17:40:22 i feel there is some miscommunication. I'm not suggesting Kea. I'm suggesting the tool might be useful for your conversion 2025-07-03 17:40:32 but looking at timestamps, I think you cobbled it together after you asked here 2025-07-03 17:40:37 and thus there is nothing left to be done 2025-07-03 17:40:44 right :) 2025-07-03 17:41:20 but for next time i get this question, i'll now know about the kea converter :D 2025-07-03 17:41:37 i migrated from isc dhcpd to kea once, but i did not know about the tool. i did not have static leases anyway 2025-07-03 17:42:55 oh this was just for dynamic ones, i just don't want the IPs to change 2025-07-03 17:43:13 oh wait. i totally skipped that part of the question 2025-07-03 17:43:17 not even sure the kea tool handles that then 2025-07-03 19:08:58 Ariadne: if you got time after fixing your network, I think your feedback on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85504#note_521743 might also be very useful 2025-07-03 20:24:35 pabloyoyoista: i responded but you probably won't like my vote 2025-07-03 20:25:23 in general, i am hesitant to automatically force merged /usr on pre-existing installations, there's too many unknowns to have any confidence in the safety of that approach 2025-07-03 20:28:35 the whole reason for creating a test suite for the merge script, having the script in testing, and so on is so that we can find these unknowns and get confidence that this works 2025-07-03 20:29:00 I mean, in a way if you all think it's better for alpine users to take ownership of their migration like this, that's fine. But that also assumes that if issues araise, or people don't read the release notes and things go south, then we don't take ownership of those failures 2025-07-03 20:29:12 how did Debian handle th is? 2025-07-03 20:29:14 *this 2025-07-03 20:29:45 go look it up :P 2025-07-03 20:29:48 You could do it manually for a while, but then was forced on you 2025-07-03 20:29:56 right 2025-07-03 20:30:27 Or maybe upgrade failed at some point if you hadn't done it? 2025-07-03 20:30:47 are we at the "you can do it manually" phase? 2025-07-03 20:31:18 Don't think so, since the design is not finalised 2025-07-03 20:32:35 But anyway, Ariadne thanks for your answer 2025-07-03 20:34:46 craftyguy[m]: i support the existence of the script, but not the automatic use of it. 2025-07-03 20:35:41 the reality is, people don't read release notes, and people make modifications to their systems which break assumptions *already* 2025-07-03 20:35:45 so we need to support Alpine installs that never have usr merge? 2025-07-03 20:37:26 Ariadne: but then I'm confused. If people don't read release notes, then the responsibility cannot be placed on the users? 2025-07-03 20:37:27 we have to provide partial support for those installs anyway for at least 4 release cycles 2025-07-03 20:37:50 because it won't be backported to previous releases 2025-07-03 20:38:25 my suggestion: new installs are merged-usr, old installs can be merged-usr if users want that. 2025-07-03 20:38:55 Forever? 2025-07-03 20:39:05 of course not 2025-07-03 20:39:19 so if not forever, then... until when? :P 2025-07-03 20:39:36 until there are no actively supported branches where merged-usr isn't the default 2025-07-03 20:40:15 but if we aren't auto-merging existing installs then isn't that "forever" ? 2025-07-03 20:40:34 what i propose is: if you start on alpine 3.23, you are in a merged-usr world. if you upgrade from 3.{19-22} to 3.23, then you decide when you want to enter that merged-usr world. 2025-07-03 20:40:48 once those branches are EOL, then merged-usr is required 2025-07-03 20:40:53 like if you have 3.22 on your system, and 4 years from now still haven't run merge-usr, then your system is still not /usr merged even if new installs for every supported release is producing merged usr installs 2025-07-03 20:41:28 ok when merged usr is required.. then do we auto-merge? or just put it in the release notes that this is now required and hope folks read it? 2025-07-03 20:41:42 the latter IMO. 2025-07-03 20:41:50 pmOS, can of course, do whatever it wants 2025-07-03 20:42:06 yaa I'm talking specifically about Alpine, since this is alpine-devel :D 2025-07-03 20:42:07 and we can use that data to gauge the safety of auto-merge over time 2025-07-03 20:42:28 this seems reasonable to me 2025-07-03 20:42:55 basically what i am saying is auto-merge is not a good idea at this time, lets revisit it in 2 years once we fully understand the risks 2025-07-03 20:43:00 debian kinda had a disaster trying to support merged and non-merged installs at the same time, but maybe it'll be OK on Alpine 2025-07-03 20:43:35 define support? 2025-07-03 20:43:41 https://lwn.net/Articles/890219/ 2025-07-03 20:43:52 i think it is okay for non-merged installs to have degraded experience 2025-07-03 20:44:44 IIUC there was some bug with building packages on merged usr systems that broke unmerged systems, but tbh that lwn article kinda breaks my brain (their style of writing is hard for me to follow sometimes 😅) 2025-07-03 20:45:34 anywho, I guess there could be some weirdness that comes up from trying to not break unmerged systems 🤷‍♂️ 2025-07-03 20:45:52 i think it is acceptable to say "if you have problems, switch to merged-usr" 2025-07-03 20:45:57 during the transition period 2025-07-03 20:46:09 yeah this sounds reasonable 2025-07-03 20:46:17 yeah ^^ 2025-07-03 20:46:27 my point is that the system administrator should provide explicit consent to having their filesystem layout changed 2025-07-03 20:46:33 since it has risks 2025-07-03 20:47:28 yeah that makes sense. I think we understand that, but at the same time we don't want to forever "support" unmerged installs. I think what you described is a good compromise 2025-07-03 20:48:35 for example, i am aware of an alpine deployment in the field that involves tens of thousands of embedded ARM boards with cellular modems collecting telemetry 2025-07-03 20:48:56 if we break those deployments, someone has to go out into the rainforest to fix it 2025-07-03 20:49:15 times whatever thousands of sensors they have at this point 2025-07-03 20:49:45 on the other hand, that research was funded by the US government, and maybe the entire project is abandoned now since it was related to climate change tracking 2025-07-03 20:49:57 oof 2025-07-03 20:50:02 but there's many more examples of that sort of deployment 2025-07-03 20:50:04 😂 2025-07-03 20:51:08 ya, as someone with a background in supercomputing stuff, I totally understand your concern there... 2025-07-03 20:52:02 I had an interview question once about designing a system for a remote update on the Moon 2025-07-03 20:52:19 I don't remember the details but it was pretty tricky to get right 2025-07-03 20:52:24 was the correct answer "you don't"? :P 2025-07-03 20:52:55 that's obviously the first thing I said but they asked me to proceed like it wasn't an option :P 2025-07-03 20:53:02 I feel like I'd fail that question because I'd volunteer to go to the moon to fix a computer 🤣 2025-07-03 20:53:16 not on a starship... 2025-07-03 20:53:20 brb going to the moon to upgrade alpine linux 2025-07-03 20:53:36 oh yeah, dust off a saturn V 2025-07-03 20:53:42 flying cars 2025-07-03 20:53:51 Thanks a lot for your thoughts. The way you've put it indeed makes sense to me. Specially the responsibilities and expectations 2025-07-03 20:53:57 sorry, usrmerge failed, the moon is now planned to crash on Earth in a couple million years 2025-07-03 20:54:29 We should totally document that. So that if people complain about their degraded experience after moving to v3.23, we can point them somewhere 2025-07-03 20:54:32 oh there's still time to fix the usrmerge on the moon 2025-07-03 20:54:35 actually we never have to worry about that due to tidal forces "pushing" the moon away from us 2025-07-03 20:54:57 i think i still have one of the prototype sensor boards for that experiment somewhere around here 2025-07-03 20:55:10 i had to hand-solder like 100 of them :D 2025-07-03 20:56:36 If only it were in the alps really :p 2025-07-03 20:56:46 yikes. smd? 2025-07-03 20:57:20 nah, it was just fixing some GPIO pins that were not included on the board from factory 2025-07-03 20:57:28 because the requisition got screwed up 2025-07-03 20:57:45 they thought the pins were nostuff initially 2025-07-03 20:58:12 ah, so rework stuff. still brutal 2025-07-03 20:58:23 oof. 2025-07-03 20:58:32 pabloyoyoista: we should add a warning to some prominent places (e.g. homepage of alpinelinux.org) to have a global warning for everyone who uses alpine 2025-07-03 20:59:08 so basically, lets not start with auto-merge, but we can incrementally work towards it over releases 2025-07-03 20:59:14 yeah 2025-07-03 21:00:53 One thing that this makes a bit harder, is that we have to wait 2 years to drop lots of packaging hacks 2025-07-03 21:01:13 But that's just me being impatient 🤣 2025-07-03 21:01:21 not really 2025-07-03 21:01:37 we can drop then in edge, if the intent is to support merged usr in 3.23? 2025-07-03 21:01:54 like i said, i think it is valid to say "if you don't switch to merged-usr and it doesn't work for you, then switch to merged-usr" 2025-07-03 21:02:24 what is not valid is doing something automatically which could break prod 2025-07-03 21:02:38 because "prod" is different for every site 2025-07-03 21:03:13 but isn't just dropping packaging hacks and mostly not supporting split-usr very well (recommending folks to go the merged-usr route) also possibly breaking prod? 2025-07-03 21:03:16 and so teams need to evaluate and test the impact of switching to merged-usr, e.g. lab it and then implement it in prod 2025-07-03 21:03:43 f_: yes, but the larger risks are mitigated 2025-07-03 21:04:10 if someone accidentally upgrades prod, they should still be in a recoverable state, where they can downgrade or switch to merged-usr 2025-07-03 21:05:23 OK, so that means that outside /lib/firmware and musl, we could move busybox scripts to /usr 2025-07-03 21:05:31 yes 2025-07-03 21:05:43 That makes me feel a lot more at ease 2025-07-03 21:08:45 Ariadne: as always, your feedback and patience is amazing, thank you :) 2025-07-03 21:09:12 It means we can promise to fix most of the packaging bugs, without committing to still be here in 2.5 years, and thus not risk dumping the issue to you 2025-07-03 21:09:12 +1 2025-07-03 21:09:35 i don't want to see us here in 0.5 years much less 2 2025-07-03 21:10:09 but i also don't want to see broken deployments ;) 2025-07-04 11:54:10 this MR adds support for an extra arch to a port. I suspect this wants a pkgrel bump, is that right? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/86005/diffs#note_522067 2025-07-04 12:01:10 For just adding an extra arch, that's not necessary 2025-07-04 12:01:14 ah 2025-07-04 12:01:22 will it get built? 2025-07-04 12:02:00 Yes, since the builder will notice the package is missing 2025-07-04 12:02:07 ah, that's a neat approach 2025-07-04 12:02:12 thanks. I've approved the MR 2025-07-04 12:50:18 and the user has marked it as ready :) 2025-07-04 13:14:30 Could somebody add these 3 MRs to the /usr merge milestone? 2025-07-04 13:14:31 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/85504 2025-07-04 13:14:31 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/205 2025-07-04 13:14:41 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/260 2025-07-04 13:21:28 And we got 3 related and simple MRs to fix packaging bugs still pending in https://gitlab.alpinelinux.org/groups/alpine/-/milestones/16#tab-merge-requests if somebody wanna have a look 2025-07-04 13:28:44 dont have permissions for mkinitfs or alpine-conf, but added the aports MR to the milestone 2025-07-04 17:49:32 how can i test package https://gitlab.alpinelinux.org/alpine/aports/-/work_items/17311 2025-07-04 17:49:46 is there an existing gcc15 pcakage for testing? 2025-07-04 18:08:50 you can use mrtest for !86313 or download the artifcats and manually install it 2025-07-04 19:07:29 achill, what I do not understand is: How can this missing rebuild leak from edge into 3.22? Are the packages for a new major release just taken from edge without a new build? 2025-07-04 19:16:30 no, but once the package is re-built on 3.22, commits from master still land in 3.22 until its branched off 2025-07-04 19:25:36 now I understand thank you. The package upgrade was merged on 10 May, and 3.22 was released 12 May. 2025-07-04 19:28:06 Maybe your script could be added to the CI pipeline to detect missing rebuilds. This does not help if the pipeline is skipped, but some cases will be found 2025-07-05 12:03:18 if someone is bored, here is a list of missing rebuilds (https://tpaste.us/waJ9). it would be nice to rebuild them and get figure out how they were missed in the first place 2025-07-05 13:18:51 It seems to be common to not check revdeps when bumping libraries. Also apk dot --errors is underrated 2025-07-05 13:23:15 I think we should try to make the CI fail when something isn't provided anymore but still used 2025-07-05 16:23:55 oh didnt know about apk dot --errors 2025-07-05 16:23:57 thats nice 2025-07-05 17:28:49 enabling tests for all tree-sitter grammars: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57359#note_522457 2025-07-06 02:38:31 hi all cartel here ... . how are you all ... . 2025-07-06 14:03:19 Hey, I was just wondering if there are plans for a minor release within v3.22. Not trying to be pushy or anything, I'm just planning to do a fresh install and I've figured that it would be worth waiting for the next release 2025-07-06 14:06:43 all minor releases do is add a snapshot of the current state of particular packages, so there's no reason to wait. 2025-07-06 14:07:08 I see, thanks! 2025-07-06 14:34:06 and they are created only for security patches 2025-07-06 15:13:45 and they are created only for security patches 2025-07-06 15:13:45 on the very base package set e.g. preinstalled on a docker image 2025-07-06 15:13:53 or for the ISOs 2025-07-06 15:14:18 thats basically the only reason the the minor releases, so they get rebuild with security fixes. 2025-07-06 15:54:44 If I want to upgrade vtk and enable more build options, drop some unneeded patches, and drop the largedata archive, do I need to submit in the same MR bumps for freecad and other things that depend upon vtk, or does the builder automatically bump them? 2025-07-06 15:55:11 I'm working with one of the main devs of vtk to get our package current so I can package F3D and Exhibit 3D model viewers 2025-07-06 16:00:25 yeah you need to bump the pkgrel of the packages linking against vtk's libs in the same MR 2025-07-06 16:04:15 mmm, okay. And in pkgs.alpinelinux.org for VTK under the field that shows required by, that covers all of the ones I need to hit? 2025-07-06 16:16:07 in this case, yeah. basically only freecad, opencascade. and in testing, gdcm and pcl 2025-07-06 16:17:26 for packages in testing/ its fine if the rebuild is delayed e.g. in another MR, i think gdcm is currently broken because i forgor 2025-07-07 06:04:57 How do I add reviewers/assignees for the packages affected by a package bump I'm doing? 2025-07-07 06:05:07 Do I just at them if I know their handle? 2025-07-07 06:05:17 !86759 2025-07-07 06:06:29 holy, that s390x runner is fast 2025-07-07 06:18:25 Saijin_Naib[m]: you'd have to ping them 2025-07-07 06:51:59 that will be a challenge, I don't know any of them, haha 2025-07-07 06:55:48 I can't find maintainers @ on gitlab for freecad and pcl 2025-07-07 06:55:54 pinged the other two 2025-07-07 07:26:32 maribudo you have a chance to look at bumping mangohud? It does not seem to work for me locally, and bumping to v0.8.1 fails because meson complains that vulkan-headers is not buildable 2025-07-07 07:30:15 I sadly do not have the time right now to look into it. I wonder why it was not flagged out of date. https://release-monitoring.org/project/138139/ does display that 0.8.1 is the most recent version and Alpine is shown in there 2025-07-07 07:38:30 I just added the mapping a few minutes ago when I attempted to build ir 2025-07-07 07:38:53 I try and make sure any aport I touch has a mapping 2025-07-07 07:57:33 Thanks for doing that. Getting a mail when packages are in need of updates is really helpful :) 2025-07-07 09:18:59 i'm merging the llvm split from llvm20. the symlinks for default llvm is now in a separate subpackage 2025-07-07 09:19:11 sorry a separate package/APKBUILD 2025-07-07 10:04:38 nice 2025-07-07 14:18:50 @maribu its the least I can do if the package is too difficult for me to help with 2025-07-07 18:23:05 Hello everyone! I wish to work towards adding support to alpine for initramfs hooks (like arch, postmarketos, systemd), so we may be able to have nice things like automatically decrypting devices with TPM using clevis, having a nice splash screen with plymouth or even having a touch screen input for unlocking encrypted LUKS devices with unl0kr. I will be showing my progress here, and if you like you can point me to any 2025-07-07 18:23:05 resources that may be useful. thanks :) 2025-07-07 18:24:16 angeloverlain[m]: I suppose it may be a good idea to discuss this with the maintainer (ncopa) so that your ideas align with his 2025-07-07 18:24:46 okay sure. how may I contact him? I hear he's a busy person 2025-07-07 18:25:16 He responds here, mainly during CE(S)T working hours 2025-07-07 18:25:43 One thing that would be very welcome is to improve the current test suite 2025-07-07 18:26:08 Which is what would help gaining confidence in accepting changes 2025-07-07 18:26:09 anyway, a bit of background with this, I wanted to just add support for clevis (https://wiki.alpinelinux.org/wiki/User:Vixalien/Clevis) and plymouth (WIP), but I figured having something extendable would be nicer. 2025-07-07 18:26:22 ikke: okay. maybe they shall see this tomorrow. 2025-07-07 18:27:00 about the test suite, I will definitely work on them, but currently I have not looked into how the current testsuite in mkinitfs is... 2025-07-07 18:27:35 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/tests/initramfs-init.test 2025-07-07 18:28:17 Basically a lot of mocking and verifying initramfs-init does the right thing 2025-07-07 18:32:11