2024-11-01 02:15:29 fedora drop neofetch 5 months ago https://src.fedoraproject.org/rpms/neofetch 2024-11-01 09:45:02 Im using fastfetch 2024-11-01 09:45:10 me too 2024-11-01 13:53:29 btw will the loongarch ISOs be ready for 3.21? 2024-11-01 13:56:44 It will be part of the stable release, but no idea what release media will be generated 2024-11-01 13:57:11 ah yeah 2024-11-01 13:57:12 cool 2024-11-01 16:44:03 an ISO will need to be generated, its the only way to boot these things (except for the embedded boards which support u-boot) 2024-11-01 17:12:42 heh, didn't know I'm so good https://www.phoronix.com/news/Ubuntu-Mainline-PPA-2024-Break 2024-11-01 17:13:29 and Alpine also, btw 2024-11-01 17:14:09 i also love how alpine doesnt add a lot of patches to the kernels 2024-11-01 17:14:47 afaik ubuntu add a lot of stuff to their trees 2024-11-01 17:16:43 did you looked at first versions of linux-starfive or current linux-spacemit :) 2024-11-01 17:17:18 yeah ok fair enough 2024-11-01 17:17:24 but not to the stable kernels 2024-11-01 17:17:32 like -lts or -edge 2024-11-01 17:17:38 anyone seeing 502 error here, https://git.alpinelinux.org/aports/commit/?id=415a46b70115f9e8e8eda575006998af7d24f645 ? 2024-11-01 17:17:39 that's true 2024-11-01 17:18:02 vkrishn: yeah probably down again 2024-11-01 17:18:14 other links work 2024-11-01 17:18:35 btw, for long I have linux-rc locally but didn't dared to push it to aports 2024-11-01 17:19:05 ah good to know, because i wanted to look into that 2024-11-01 17:19:05 vkrishn: you have to try again in a bit 2024-11-01 17:19:12 ok 2024-11-01 17:54:26 S390x builder running out of disk space 2024-11-01 17:54:37 working on it 2024-11-01 18:38:05 how can pass '-lfts' to linker in APKBUILD 2024-11-01 18:38:29 export LDFLAGS="$LDFLAGS -lfts"? 2024-11-01 18:41:11 did but doesn't work 2024-11-01 18:42:25 means whatever you're building ignores LDFLAGS 2024-11-01 18:42:30 from the env 2024-11-01 18:43:03 psykose: looks so 2024-11-01 18:45:31 '/usr/lib/gcc/aarch64-alpine-linux-musl/14.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: /home/mps/aports/community/vboot-utils/...' 2024-11-01 18:48:52 oh LDLiBS 2024-11-01 18:49:01 LDLIBS* 2024-11-01 18:49:48 'export LDLIBS="$LDLIBS -lfts"' 2024-11-01 18:50:52 I think you can directly set that, since abuild does not use LDLIBS 2024-11-01 18:51:03 export LDLIBS="-lfts" 2024-11-01 18:53:04 will try 2024-11-01 18:53:17 though it works with above 2024-11-01 18:55:42 It's exactly the same, just a tidy bit simpler 2024-11-01 18:59:52 yes, but have to test with so strange vboot-utils pkg 2024-11-01 19:00:38 huh, and TEXTREL in it 2024-11-01 20:08:45 `apk version -t 6310032 20210101` show '<'. this means that 20210101 higher and will replace pkg version 6310032 2024-11-01 20:08:48 ? 2024-11-01 20:09:26 yes 2024-11-01 20:09:38 ikke: nice, thanks 2024-11-01 20:39:57 could we have source without checksum in APKBUILD? 2024-11-01 20:40:23 I know answer but have a hope 2024-11-01 20:44:07 No, abuild does not support it 2024-11-01 20:46:02 what to do with pkg which changes checksum on every download 2024-11-01 20:46:38 Potentially host it somewhere 2024-11-01 20:48:22 with such license https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/master/LICENSE 2024-11-01 20:48:59 alpine doesn't have lawyer afaik 2024-11-01 20:49:18 that's just bsd-3-clause 2024-11-01 20:49:34 not explicit 2024-11-01 20:49:42 ? 2024-11-01 20:49:48 that's literally the bsd-3-clause licence text 2024-11-01 20:49:58 https://spdx.org/licenses/BSD-3-Clause.html 2024-11-01 20:50:46 IANAL 2024-11-01 20:51:32 You don't have to be a laywer to see that it's the same license 2024-11-01 20:51:52 don't want to risk 2024-11-01 20:52:01 what risk? 2024-11-01 20:52:20 But more important, if we could not host the source somewhere, we certainly could not host the binaries built from that source 2024-11-01 20:53:33 So if you say it's fine to redistribute binaries, you should feel safe to host the source somewhere as well 2024-11-01 20:54:43 ok, will someone upload https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+archive/bcc837446605fe65c0ce4e860777461ae23702b9.tar.gz somewhere 2024-11-01 20:55:13 uh, not this 2024-11-01 20:56:03 https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+archive/506d9df62d10ad0fde2d8d96b25b194d749262ff.tar.gz 2024-11-01 20:59:50 https://dev.alpinelinux.org/archive/vboot_reference/vboot_reference-506d9df62d1.tar.gz 2024-11-01 21:00:55 ikke: you are so fast. thanks 2024-11-01 21:12:04 here it is !74518 2024-11-01 21:12:47 algitbot doesn't work 2024-11-01 21:13:00 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74518 2024-11-01 21:13:40 If you use vboot_reference, shouldn't the license be adjusted? 2024-11-01 21:15:09 don't know, TBH 2024-11-01 21:19:53 The license in that archive is BSD-3-Clause 2024-11-01 21:20:15 https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/main/firmware/lib/gpt_misc.c#2 2024-11-01 21:20:51 https://chromium.googlesource.com/chromiumos/platform/vboot_reference/+/refs/heads/main/firmware/lib/cgptlib/crc32.c has a difference license, though 2024-11-01 21:22:42 ha, do you know that right now Mars, Jupiter and Saturn are on night sky 2024-11-01 21:22:49 :) 2024-11-01 21:23:08 No, was not aware 2024-11-01 21:23:35 sorry, couldn't resist (though they are) 2024-11-01 21:23:56 all this with licenses is to much complicated to me 2024-11-01 21:24:49 The current specified license might not even be eligible for Alpine while BSD-3-Clause is 2024-11-01 21:25:26 so we should remove vboot-utils 2024-11-01 21:26:55 The source itself literally says it's BSD licensed 2024-11-01 21:28:16 I understand and trust you, but ....... 2024-11-02 00:43:38 re: ^"could we have source without checksum in APKBUILD?" <= one solution is to have alias entry for source, APKBUILD gets the source checksum and matches true if any one matches 2024-11-02 00:44:19 but thats a feature, and its can lead to clutter 2024-11-02 00:47:49 Just off the cuff here, but couldn't this be solved with just using VCS tags? 2024-11-02 00:52:07 googlesource generates tarballs on the fly 2024-11-02 00:52:19 in void we use content checksums to get around this 2024-11-02 01:25:01 a practice of adding full content checksum by orig author to source vcs would be something 2024-11-02 01:25:43 but maintaining checksums in distro specifi branch is also ok 2024-11-02 01:25:59 specific^ 2024-11-02 03:32:02 i think i managed to make a simplex-chat package, finally 2024-11-02 03:32:13 was a bit annoying due to GHC versions 2024-11-02 04:13:00 there we go: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74530 2024-11-02 13:20:38 Does alpine/go/repository work with apkv2, or apkv3, or both? 2024-11-02 13:20:46 apkv2 2024-11-02 13:20:49 no v3 support yet 2024-11-02 13:24:24 Ok, thank you 2024-11-02 14:40:29 mio: does vboot-utils still fail on 3.21 builders? 2024-11-02 14:45:58 mps: last built 02 Nov 2024 12:25:03 +0000, maybe it just needs to retry one more time 2024-11-02 14:46:31 if you refresh the build log url and it passes, then it's okay :) 2024-11-02 14:46:57 mio: no, it need fix source or '-Wno-implicit-function-declaration' in CFLAGS 2024-11-02 14:47:14 will use later now and make MR 2024-11-02 14:48:59 ah, nvm, thought you had already pushed the change 2024-11-02 14:49:51 actually pushed to builders 2024-11-02 14:50:16 That's not an actual fix though 2024-11-02 14:50:46 Generally you want to include the actual header that provides the missing function 2024-11-02 14:50:47 mio: no, last night I tried new version and it is on CI. It builds but segfaults 2024-11-02 14:51:28 ikke: yes right. I wrote fix source or .... 2024-11-02 14:52:10 though also later fixes build 2024-11-02 14:58:58 mps: just checked the relbumped url, not found, so probably hasn't been rebuilt yet. will let you know if it rebuilds on one of the arches or fails 2024-11-02 14:59:42 mio: it passed edge 2024-11-02 14:59:50 haven't noticed any error notifications yet, so it's probably okay 2024-11-02 14:59:59 if it passed edge builders 2024-11-02 15:01:31 I tested first on edge locally 2024-11-02 15:02:37 okay 2024-11-02 15:03:20 i was looking at gmp package, it looks like it doesn't have /usr/lib/libgmp.so, only /usr/lib/libgmp.so.10 2024-11-02 15:03:23 is that intended? 2024-11-02 15:03:45 gmp-dev has /usr/lib/libgmp.so though 2024-11-02 15:05:50 i noticed that because my build with makedepends="gmp" failed to link gmp with -lgmp 2024-11-02 15:07:53 rdbo: https://pkgs.alpinelinux.org/contents?file=&path=&name=gmp-dev&branch=edge&repo=&arch= 2024-11-02 15:08:14 So yes, that's intentional 2024-11-02 15:10:26 ikke: isn't -dev supposed to add just headers files, and regular will have the library? 2024-11-02 15:10:49 rdbo: The .so file is only meant to build against 2024-11-02 15:10:59 The final binary should be linked to the versioned .so.* file 2024-11-02 15:11:17 *.so are symlinks to the versioned *.so.* 2024-11-02 15:11:22 right 2024-11-02 15:11:30 oh ok, that makes sense 2024-11-02 15:12:09 so i should add `gmp-dev` to makedepends and `gmp` to depends right 2024-11-02 15:12:28 you do no need to add gmp to depends 2024-11-02 15:12:33 abuild traces that automatically 2024-11-02 15:12:40 so you only need to add gmp-dev to makedepends 2024-11-02 15:13:50 oh, that's convenient. will update here 2024-11-02 15:21:55 one more question, when the project has AGPL-3.0 license and doesn't mention if it's -only or -or-later, do I assume -only? 2024-11-02 15:24:19 That's the safest bet 2024-11-02 15:24:54 alright 2024-11-02 16:33:37 https://quakeone.com/forum/quake-talk/quake-central/284400-project-to-add-more-map-formats-to-quake 2024-11-02 16:33:55 android___: is that relevant to Alpine Linux? 2024-11-02 16:34:11 ikke, yes: I want it compiled statically 2024-11-02 16:34:14 alpine can do that 2024-11-02 16:34:17 debian cannot 2024-11-02 16:34:32 I'm tired of having to make a binary for every fucking distro 2024-11-02 16:34:43 (the source is included but no one bothers to compile it) 2024-11-02 16:35:12 so alpine is the only way I've been told because regular Gnu tools gcc setup is against static linking and makes it impossible 2024-11-02 16:35:37 glibc has some components that depend on dynamic loading 2024-11-02 16:36:31 yes, so I can't achieve it on regular linux distros 2024-11-02 16:36:43 but I have been told that alpine is statically linked and is the solution 2024-11-02 16:36:52 notice how windows binaries work forever 2024-11-02 16:36:59 because the old ones were statically linked 2024-11-02 16:37:21 Alpine Linux is not statically linked, but musl does support it 2024-11-02 16:41:03 ikke, so can I just compile the engine on Alpine Linux and the binary will be staically linked? 2024-11-02 16:41:16 or is it difficult? 2024-11-02 16:41:20 Not automatically. You need to tell the compiler to make a static build 2024-11-02 16:44:44 is that easy to do? 2024-11-02 16:44:49 with GCC it's impossible 2024-11-02 16:44:52 Depends on the project 2024-11-02 16:45:08 gcc is perfectly capable of providing statically build binaries 2024-11-02 16:45:35 I've been told again and again that static linking is effectivly impossible on regular linux distros 2024-11-02 16:45:40 and everyone is against it 2024-11-02 16:45:50 and Alpine is the only way 2024-11-02 16:45:52 android___: they were probably referring to glibc 2024-11-02 16:46:47 ikke: can you take months of your life and throw them away to implement more 3d map formats for quake in the C programming language? 2024-11-02 16:46:48 https://quakeone.com/forum/quake-talk/quake-central/284400-project-to-add-more-map-formats-to-quake 2024-11-02 16:47:02 no 2024-11-02 16:47:08 I threw away a month of 12 to 16 hr days for WolfenstineEnemyTerritory format 2024-11-02 16:47:28 and 2 weeks for various obj export formats from minetest/minecr*ft and bzflag 2024-11-02 16:47:39 and then 2 extra weeks for the gamecode for those 2 2024-11-02 16:47:48 12-16 hr days for the C code 2024-11-02 16:47:54 ikke, could you please do the same? 2024-11-02 16:47:59 no 2024-11-02 16:48:02 (all GPL'd as quake demands) 2024-11-02 16:48:05 ikke, why not? 2024-11-02 16:48:23 ikke, I'm just asking you to work for free for months, all waking hours, as we enter WW3 2024-11-02 16:48:41 like linus did for years for people before kicking them out of kernel development 2024-11-02 16:48:55 (ex: the russians he kicked out, and the anti-feminists he CoC'd out) 2024-11-02 16:49:05 ikke, why don't you want to work for free? 2024-11-02 16:49:25 ikke, and then get kicked in the face while I continue to use your work 2024-11-02 16:49:40 ikke, how about you work for free for months and then I libel you? 2024-11-02 16:49:44 that's the opensource way 2024-11-02 16:49:47 how about it? 2024-11-02 16:49:57 oh and then I'll ban you from the project you worked on 2024-11-02 16:50:02 doesn't that sound good? 2024-11-02 16:50:13 and if you say anything on twitter I don't like 2024-11-02 16:50:14 android___: I feel some frustration, but please, this is not the right place to vent it 2024-11-02 16:50:18 instant ban from your code 2024-11-02 16:50:20 can someone take a look at this MR? i wanted to see if it's good before i start trying to build the desktop GUI: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74530 2024-11-02 16:50:41 ikke, :) 2024-11-02 16:51:37 rdbo: We do not accept aports that download pre-compiled binaries, which I think you are doing? 2024-11-02 16:51:55 hmm i see 2024-11-02 16:52:05 the only other alternative i can think of is to build haskell from source though 2024-11-02 16:52:27 ikke, I distribute my game via ISO 2024-11-02 16:52:32 it contains the full source code 2024-11-02 16:52:33 just ban the troll already 2024-11-02 16:52:40 psykose, fuck you 2024-11-02 16:52:51 ChaosEsque Anthology is the project 2024-11-02 16:54:07 ikke, should i try to build ghc from source or maybe there's another way 2024-11-02 16:54:27 convince upstream to support a more recent GHC 2024-11-02 16:55:08 in the short term that could work, but only until GHC gets updated again i think 2024-11-02 16:55:31 their minor releases introduce breaking changes, because they follow another system different than SemVer 2024-11-02 16:55:48 anoying, not a good platform to build on 2024-11-02 16:56:15 agreed, but i think this software is too good to be left out 2024-11-02 16:59:00 another solution i can think of is to provide another ghc package like ghc9.6.3 or something, but that feels overkill 2024-11-02 17:03:10 I doubt we want a package just for a specific minor version 2024-11-02 17:04:17 they do MAJOR.MAJOR.MINOR, so maybe ghc9.6, and the .3 is minor so doesn't matter 2024-11-02 17:04:41 How is it going to be bootstrapped? 2024-11-02 17:05:16 a lot less effort to just update the program 2024-11-02 17:05:18 i was thinking to make a separate package ghc9.6, and then i add it to the makedepends 2024-11-02 17:05:39 iirc postgresql has many versions too, so maybe this wouldn't be forbidden 2024-11-02 17:06:03 It's not forbidden, but discouraged if possible 2024-11-02 17:06:05 postgres requires multiple versions to use it 2024-11-02 17:06:38 psykose, i thought so too, but the haskell ecossystem is weird 2024-11-02 17:07:03 it's not even simplex who is limiting the haskell version as far as i can tell, there is a dependency somewhere which requires haskell == 9.6 2024-11-02 17:07:08 ghc* 2024-11-02 17:08:13 if there was to be a ghc9.6 package, would it be a subpackage of the regular ghc APKBUILD? or completely separate thing 2024-11-02 17:08:50 Completely separate 2024-11-02 17:09:08 A package only has a single version 2024-11-02 17:09:34 got it 2024-11-02 17:09:45 but ghc itself needs to be bootstrapped somehow 2024-11-02 17:10:32 i would do just like the ghc package, but pulling from 9.6.X instead 2024-11-02 17:10:49 and then add that to the `makedepends` of the simplex-chat package 2024-11-02 17:11:52 you could also just not package it 2024-11-02 17:13:14 i've come this far already, what would be an extra building ghc from source XD 2024-11-02 17:13:17 packaging a whole toolchain esp. one like ghc for the sake of 1 program that's gonna have 1 user and can be installed from flathub seems dumb 2024-11-02 17:16:30 it will def be a tough task, but i think it's worth it, there's no other chat like it 2024-11-02 17:16:52 yeah no other chat with a client that requires a specific ghc version 2024-11-02 17:17:17 lol 2024-11-02 17:17:50 tbf 9.8 and 9.6 are different major versions 2024-11-02 17:18:15 so it's not completely irrational 2024-11-02 17:18:42 How long is simplex-chat planning to remain on 9.6? 2024-11-02 17:19:21 i dont know how long they plan to use that version, but i can find out how long they've been using it so far 2024-11-02 17:23:52 sertonix[m]: o/ mind if I pick your brains about cross compiling? What's your setup for this? 2024-11-02 17:24:52 GHC 9.6.3 came out in 2023-09-25, they've been using it since 2023-11-08 2024-11-02 17:25:03 and their previous version was 8.8.something iirc 2024-11-02 17:25:22 my guess is they will update when 10.something comes out 2024-11-02 17:26:44 they went: 8.10.7 -> 9.6.2 for very little time -> 9.6.3 2024-11-02 17:33:29 my proposal is: `ghc` package remains up-to-date to the latest version, `ghc-MAJOR.MAJOR` subpackages can only exist if there is another package depends on it, avoiding binary bootstrapping ghc and avoiding spamming ghc versions on every sub-major (?) release 2024-11-02 18:42:13 Huh, that android weirdo was in Libera with the same nick, also spewing slurs and other stuff 2024-11-02 18:42:31 Did someone deal with it? 2024-11-02 18:43:02 They were k-lined 2024-11-02 18:43:16 Also banned from the specific channel where I was 2024-11-02 18:43:20 good 2024-11-02 18:44:05 Yeah, just feel sorry for whoever reads their messages :/ 2024-11-02 18:45:29 sertonix did some hacking around and I got something kinda working, I needed to patch the abuild-meson wrapper like this though:... (full message at ) 2024-11-02 18:46:32 Running abuild like this:... (full message at ) 2024-11-02 18:53:40 is there a naming convention for neovim plugin aports? i noticed that all or most of them are named "nvim-${plugin_name}" 2024-11-02 18:54:26 Probably a defacto standard 2024-11-02 18:56:29 ok, thanks 2024-11-02 19:02:49 iirc we have someone who maintain ppc64le for alpine (or, we had them) 2024-11-02 19:03:23 mick_ibm: 2024-11-02 19:04:10 aha, mick_ibm: could you luck at this problem, please https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1578283#L865 2024-11-02 19:04:40 I have no idea why it fails on ppc64le and pass all other 2024-11-02 19:10:29 ok sure i can take a look 2024-11-02 19:11:13 mick_ibm: thank you 2024-11-02 19:45:29 caleb: Adding sys_root to abuild-meson sounds good! The c_args change is not specifc to meson so it should be appended to CFLAGS. Could you tell me which packages you are encountering issues with so I can test them too? 2024-11-02 19:46:19 sertonix I'm currently trying to build unl0kr which is only packages in pmOS, and needs a small patch to its meson.build 2024-11-02 19:55:44 sertonix pushed what I've got here https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/merge_requests/2474 and https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/5755 2024-11-02 19:59:36 caleb: When you set CHOST=aarch64 you can leave CARCH unset. And this is my current script to setup cross compiler and sysroot: https://paste.sr.ht/~sertonix/04f0b29fd17dcfe92d08371cb9e6c955fcadac71 2024-11-02 20:21:01 sertonix ok good to know, thanks. last thing I'm a bit confused about, how does abuild -r know which dependencies to install in which root? e.g. "meson" needs to get installed on the native machine but some library needs to be in the sysroot 2024-11-02 20:26:23 The relevant code is here: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L2349 2024-11-02 20:26:23 Essentially you need to split makedepends into makedepends_build="meson scdoc" (installed natively) and makedepends_host="eudev-dev ..." (installed to sysroot). When the package isn't cross compiled abuild will automatically install everything natively. 2024-11-02 20:28:58 sertonixahh ok, didn't see that in the APKBUILD spec :P 2024-11-02 20:29:43 i just tried building mutter and meson is now failing to find "getrandom", it does a test to see if /sys/random.h contains getrandom() but the build command it runs doesn't set up the include paths 2024-11-02 20:29:48 https://p.calebs.dev/485ec3@raw 2024-11-02 21:08:19 caleb: When I try to build mutter meson crashes :P "mtk/mtk/meson.build:58:28: ERROR: Unhandled python exception" 2024-11-02 21:29:02 "caleb: When I try to build..." <- yeah thats what i see too i think, well an assert related to LONG_MAX 2024-11-02 21:48:08 Getting something to compile. Now it errors with "undefined reference to `main'" 2024-11-02 21:57:23 hello, could someone explain to me exactly why we're doing the /usr merge? 2024-11-02 21:58:14 Make things simpler, support some additional use case 2024-11-02 21:58:18 use cases 2024-11-02 21:59:11 Follow FHS (which most likely is going to be updated to include usr merge) 2024-11-03 00:05:30 ikke: to follow the FHS shouldn't we technically wait for it to be updated? anyways. 2024-11-03 00:07:41 as for the use cases we're removing the use case of having a minimal / for recovery and the use case of /usr in a different partition, arent't we? 2024-11-03 00:09:57 does anyone do that? 2024-11-03 00:12:01 the minimal/recovery environment is often the initramfs these days 2024-11-03 00:22:35 I do that, but I'm probably the only one in the world, so, 2024-11-03 00:24:14 I don't "do" that but I have done it before and found it very useful. 2024-11-03 00:26:56 it also feels like it's making alpine (and all the other distros) move away from unix/the unix philosophy. 2024-11-03 00:32:19 we left unix behind long ago 2024-11-03 00:34:13 still 2024-11-03 00:35:08 unfortunately i just don't see this as a good change 2024-11-03 00:51:00 i'm doing that, and the latest eudev r4 and r5 break this for me, but i was pointed at this patch that lands rsn (TM) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72150 /usr will be mounted from initramfs right after / if in fstab 2024-11-03 00:51:06 i'm testing it right now. 2024-11-03 00:51:59 despite having that patch on my system, eudev does not do what its supposed, so i'm digging in 2024-11-03 00:59:52 after udev started i get a bunch of "invalid ELF header magic: != ^?ELF" messages in my dmesg, despite /usr being mounted rw right after / from initramfs 2024-11-03 01:34:19 ok, i was told the invalid elf magic is unrelated and a known bug with efforts to fix upstream. 2024-11-03 05:22:30 whats the riht way to make middle button emulation work on libinput ? 2024-11-03 05:51:55 https://wayland.freedesktop.org/libinput/doc/latest/middle-button-emulation.html 2024-11-03 05:52:13 there's links in that, one for wayland and one for xorg 2024-11-03 06:41:40 aleksi_: people like to fix things which are not broken, and just for change (something which works fine for 50+ years) 2024-11-03 06:42:02 childplay with clocks 2024-11-03 07:27:23 mps this is terrible. 2024-11-03 07:29:39 from what i've read this is a postmarketos request so they have better systemd support? why don't they change it downstream? also the "everyone else is doing it" argument is really bad. 2024-11-03 07:31:36 btw the Alpine TSC approved this change 2024-11-03 07:31:44 aleksi_: it is, but I don't want waste energy and time on preventing this. hope it make world worse and I will laugh looking at it from the side 2024-11-03 07:32:21 though it is funny already 2024-11-03 07:35:11 aleksi: _we_ are updating the FHS, so there's no point in waiting tbh. it's not like we'll get halfway through it and be like "oopsie the way we want to do usr merge is all wrong." we aren't making this up as we go, other distros have solved this stuff years ago 2024-11-03 07:38:17 ACTION fetches popcorn 2024-11-03 07:40:27 Ermine: give me some ;) 2024-11-03 07:40:43 heh, put your popcorn away. there's really nothing to debate here :P 2024-11-03 07:43:36 craftyguy: what is the Alpine TSC? 2024-11-03 07:46:06 >[...]the way we want to do usr merge is all wrong[...] 2024-11-03 07:46:08 it's not about the way, it's doing it itself that is all wrong. but as you said. there's nothing to discuss here. it will be done and we will be happy. 2024-11-03 07:47:34 Technical Steering Committee (TSC) 2024-11-03 07:47:53 Carlo Landmeter? 2024-11-03 07:48:03 read all about it: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/73 2024-11-03 07:49:10 https://gitlab.alpinelinux.org/alpine/tsc/-/blob/master/minutes/2024-08-15.md?ref_type=heads#implement-usr-merge-73 2024-11-03 07:57:42 it is a shame really 2024-11-03 07:59:58 lol k 2024-11-03 08:04:22 ACTION fetches popcorn for mps 2024-11-03 08:05:12 Ermine: thank you very much :) 2024-11-03 08:19:20 aleksi_: i don’t see the point in your complaining. if an open source project which you are using makes a conscious choice which you disagree with, you always have the option to switch to using something else, or to fork and maintain your own copy. complaining on irc after the fact is usually not very productive 2024-11-03 08:36:32 lotheac: https://lwn.net/ml/debian-ctte/tslpm714fj6.fsf%40suchdamage.org/ 2024-11-03 08:45:22 what’s the point of trying to convince anyone when the decision has been made earlier? and what’s the point of trying to convince me, i’m just a random community member :D 2024-11-03 08:49:28 who said i was trying to convince you? and mistakes can be corrected. 2024-11-03 08:52:14 if you weren’t, i don’t get why you are posting that link 2024-11-03 08:52:37 but ah well I can see we’re talking past each other so, have a nice day 2024-11-03 09:00:41 my main fear is that alpine will become bad like other distros if follows their path 2024-11-03 09:07:20 Some people say this has already happened. 2024-11-03 09:08:30 yes, my interest to alpine fading away, slowly though 2024-11-03 09:09:05 good to see you back here though. voice of reason was missed 2024-11-03 09:09:24 mercenary: heh, thanks 2024-11-03 09:11:11 also, I remember you as reasonable person though we didn't agreed always 2024-11-03 09:17:52 I may not always agree with you, but I see your point of view. But I remember you occasionally reminding people about 'small, simple, secure' 2024-11-03 09:18:30 right 2024-11-03 09:19:17 "small, simple, secure" is main strong point of alpine 2024-11-03 09:21:38 Having less paths to install things to makes things simpler 2024-11-03 09:21:44 from private communication I know some knowledgeable people left alpine just because this, and a lot don't like new changes 2024-11-03 09:22:27 ikke: it worked 50+ years well 2024-11-03 09:23:45 'well' 2024-11-03 09:24:07 but all these changes is understandable for those who studied sociology seriously 2024-11-03 09:24:29 Alpine Linux does not exist in a vacuum 2024-11-03 09:25:59 anyone ever have seen vacuum, (speaking with quantum physic hat) 2024-11-03 09:27:29 but ok, I will leave again this channel, just waiting if ppc64le person found fix for dosbox-staging 2024-11-03 09:28:25 RN, time for another coffee ;) 2024-11-03 10:03:43 does this /usr merge mean less number of paths search in env $PATH var ? 2024-11-03 10:05:12 which means if some application relied on this layering of paths search may have issues 2024-11-03 10:15:13 it seems that this discussion stems back from the unix wars. sysv vs bsd. sysv already did the /usr merge. if so, it's not that bad. and having the possibility to mount practically the whole OS read-only and be able to network share it isn't that bad either. 2024-11-03 10:21:58 25 years ago I create debian fully read only for routers without any problem and without usr-merge 2024-11-03 10:22:21 not big effort 2024-11-03 10:30:39 not a very bright idea, but having /usr/system/[s]bin and symlink them to root folder would have worked 2024-11-03 10:37:08 Lots of ways of implementing it. I don't care if it's one way or the other. But after n decades, everything knows how to deal with it as-is (maybe except systemd, but that should be a non-issue). So change for the sake of 'it's fashionable'. 2024-11-03 10:41:04 mercenary: IMO it is just this - "change old good sandals because they are not fashionable" 2024-11-03 10:42:21 also, long ago dalias wrote short and good explanation about newcomers wanting changes 2024-11-03 10:48:15 consumers mentality pollution to $distros 2024-11-03 10:52:34 I just feel like time is a bit tight. 2024-11-03 10:52:45 3.21 is comming 2024-11-03 10:54:26 The change will not happen before 3.21 2024-11-03 10:54:31 Only preparation 2024-11-03 10:55:20 3.21 will be released near end of this month I presume 2024-11-03 10:56:13 Yeah, there are still quite some build failures that need to be addressed 2024-11-03 10:56:35 though I fell alpine should switch to yearly release with such big number of packages 2024-11-03 10:57:33 That would make the amount of changes and things to fix only bigger 2024-11-03 10:58:16 ah, monthly release then maybe :p 2024-11-03 10:59:02 though I don't care, I use edge nearly everywhere 2024-11-03 11:00:13 imo not the hill worth of dying on 2024-11-03 11:00:37 maybe could turn stable release into a paid service ;) 2024-11-03 11:25:13 you joke. Redhat built a 4bln company on that concept, so there seems to be a market for it. 2024-11-03 11:32:45 linux-lts can be bumped to 6.6.59 2024-11-03 11:32:51 includes fix for netfilter 2024-11-03 11:33:14 it is for edge 2024-11-03 11:33:30 in stable 2024-11-03 13:40:19 Looks like build-3-21-x86_64 builder hangs in venv build second day 2024-11-03 13:40:58 kicked it 2024-11-03 14:00:33 mps: "my main fear is that alpine will become bad like other distros if follows their path" why the FUD? if we thought the /usr merge didn't have a lot of technical merit we wouldn't have done it. 2024-11-03 14:01:39 i find it kinda insulting to suggest that postmarketOS is just following a trend ( dragging alpine along with us) and that no actual research or thought went into this decision 2024-11-03 14:12:23 caleb_m: by research you can make result you want. Think deeply is something else 2024-11-03 14:12:41 vkrishn: you often still need non-merged dirs in PATH so it doesn't break things like sshing into non-merged systems 2024-11-03 14:14:16 mps: thats an accusation you shouldnt have said 2024-11-03 14:14:32 why 2024-11-03 14:14:57 I have no right to say truth 2024-11-03 14:15:12 you dont know how much thought went into this 2024-11-03 14:15:29 very little 2024-11-03 14:15:50 ??? 2024-11-03 14:16:03 mps: That's quite disrespectful 2024-11-03 14:16:03 thought was "other do this" 2024-11-03 14:16:57 ikke: I don't want to offend anyone, and especially you 2024-11-03 14:23:53 Just to be clear, we expect everyone to be respectful towards eachother and implying someone is not thinking is not respectful 2024-11-03 14:33:48 it's not the first time 2024-11-03 14:34:52 also not the 2nd time, and not 3rd time 2024-11-03 14:45:11 in the world we find ourselves in, the ”everyone is welcome by default” moderation might not make as much sense as it did 2024-11-03 14:45:38 so… more than ever, ignore the trolls 2024-11-03 14:59:53 As the /usr merge question is being asked endlessly, is it worth putting together a note/post on the website stating the ask, reasons and logic plus the timeframe? It may be better to point people to a url with Q&A here if necessary. 2024-11-03 15:02:44 Is it not put together already on TSC or aports issue tracker? 2024-11-03 15:03:09 if it was up to me, i would say no. i don’t believe it would reduce the incidence, and it would increase confusion in people trying to find other information 2024-11-03 15:03:33 it’s just a technical detail almost nobody needs to care about 2024-11-03 15:04:16 ”incidence of people showing up to lament”, i meant 2024-11-03 15:05:12 Partially agree, it is important once the /usr merge happens for all the users so it's necessary that this information will appear timely in changelog before upgrading Alpine 2024-11-03 15:05:50 as evidenced today: people show up and complain without even knowing what tsc is. i don’t think an announcement will help 2024-11-03 15:05:57 But fully agree that currently it's only been a bickering here and not much will change with links or FAQ 2024-11-03 15:06:03 There is a post in the making 2024-11-03 15:06:07 People that don't want to listen and/or understand, will nto 2024-11-03 15:06:19 s/nto/not 2024-11-03 15:08:20 ikke: nice _b 2024-11-03 15:08:54 pj: will bump stable kernels tomorrow. Didn’t reach it last Friday 2024-11-03 15:09:10 ah, thank you a lot <3 2024-11-03 15:11:23 I'm currently in no rush since I've dealt with the issue (compiled patched kernel+zfs for my server) but would like to not hold on long onto pinned package 2024-11-03 15:13:50 Re usr merge blog post. Its my fault and only mine that it hasn’t happened yet. 2024-11-03 15:15:51 It’s not a valid excuse, but i simply didn’t have enough energy to deal with it 2024-11-03 15:18:11 ncopa: please do not beat yourself because of it, as none of this is your fault 2024-11-03 15:18:30 ncopa: i don’t think a blog post would have prevented these comments though :) 2024-11-03 15:19:32 there are a number of change-resistant people in any community… whether or not the change has merit 2024-11-03 15:20:04 Change is always difficult 2024-11-03 15:20:24 and the older you get the harder it is with changes 2024-11-03 15:21:00 yeah. and i can relate, having been that grumpy old person many times in the past 2024-11-03 15:21:12 Problem is, this is not just "change-resistant" people, there are certain toxic individuals that have been somewhat prominent in maintaining Alpine but also harrassing people 2024-11-03 15:25:53 Yeah, that’s not acceptable 2024-11-03 15:28:35 «My main fear is that …» was not across the line though. The rest was 2024-11-03 15:30:58 And it may be quite right that the TSC, or at least myself, has not thought of all corner cases 2024-11-03 15:31:27 but at some point you have to trust the people who have done the thinkiy 2024-11-03 15:31:39 thinking* 2024-11-03 15:32:18 and I am confident that pmOS devs has thought it carefully through 2024-11-03 15:32:56 that was why TSC agreed, trusting that pmOS had thought carefully of it 2024-11-03 15:33:16 and that i know you have 2024-11-03 15:34:13 so the accusation that you haven’t been thinking was disrespectful 2024-11-03 15:34:56 For me it's a matter of having already been through such a transition, so I know it can be done and work 2024-11-03 15:37:18 If there are any concerns held by anyone, they should go to TSC issue (or other relevant issue that's tracked via usr-merge gitlab project) and describe it (without any emotional or personal attacks) 2024-11-03 15:37:37 So that we can have documented the problems and possibly answered or resolved them 2024-11-03 15:39:34 Quite possibly most of the concerns are already present on gitlab.a.o and might just need to be clarified 2024-11-03 15:40:15 But this should also serve as a proof that people will disagree for the sole reason of disagreeing 2024-11-03 15:40:36 It was not unexpected 2024-11-03 15:41:34 some people would do well to remember that it is called "unix philosophy", not "unix law" or "unix religion" ;) 2024-11-03 15:42:21 Heh indeed 2024-11-03 15:42:39 anyway I need break in weekend 2024-11-03 15:43:55 While blog post will be nice and concise notice of the project status, it should be the issue/project tracker as definitive place to discuss and workout all the wrinkles, so please do make a space for that or point to appropriate tracking issues (which could possible turn into FAQ) 2024-11-03 15:46:19 pj: like https://gitlab.alpinelinux.org/groups/alpine/-/milestones/16? 2024-11-03 15:46:30 yes 2024-11-03 15:47:49 I would love get some help with that. The follow up with FAQ part 2024-11-03 15:48:04 I don't think linking exactly to project will be best, probably the original TSC issue could serve as further discussion place (even though it's already closed) 2024-11-03 15:48:33 i'd just like to thank you all for your hard work on alpine <3 2024-11-03 15:48:49 unless you have better idea how to handle that 2024-11-03 15:50:36 re usr-merge i couldn't care less, if it is documented well, for new systems. but for already installed systems that have split partitions for small / and bigger /usr there should be a solution to support them, without having them reinstall the whole system with repartitioning. 2024-11-03 15:51:27 I believe this is the part that will be handled by the "do-usr-merge" tool 2024-11-03 15:51:40 linked in the milestone/project tracker 2024-11-03 15:51:53 do-usr-merge will repartition my disks? 2024-11-03 15:52:47 and resize the fs on them? 2024-11-03 15:52:50 I recommend reading the issue as nothing is done in that regards yet(afaik) 2024-11-03 15:52:58 And should not 2024-11-03 15:53:10 But if you already have a bigger /usr, then there should not be an issue 2024-11-03 15:53:29 There is a link to Gentoo wiki that describes the migration part 2024-11-03 15:53:35 https://wiki.gentoo.org/wiki/Merge-usr 2024-11-03 15:57:49 currently there is still issues with this. as booting doesn't work, due to / not having all the libs for fsck/modprobe and some openrc miscellania. there is this patch for mkinitfs that mounts /usr in from initrd, but there is still problems, i'm still debugging why eudev messes up permissions (and thus also breaks x11 and possibly wayland for non-root users) 2024-11-03 15:58:23 this patch: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72150 2024-11-03 16:28:32 Do I read correctly that Alpine's usr-merge will not include sbin-merge? 2024-11-03 16:37:19 pu: for now it is not planned, yes. It will probably happen later when the new FHS spec includes it. 2024-11-03 16:45:54 just do it now 2024-11-03 16:46:10 lol @ pretending to follow an FHS spec 2024-11-03 16:46:13 sertonix[m]: OK thanks. I saw that Gentoo also has a tool for that, and the-init-system-that-must-not-be-named mutters something about "tainted: unmerged-bin", hence my question ;-) 2024-11-03 16:46:39 leaving it for later just means giving everybody pain twice 2024-11-03 16:53:14 fake hierarchy specification 2024-11-03 16:54:49 debian didn't do the bin merge yet either 2024-11-03 16:55:42 debian also had the dpkg devs rebel when they tried to usrmerge, so alpine's doing pretty well so far 2024-11-03 17:13:38 ikke: yeah and they are also wrong 2024-11-03 17:15:49 i thought the plan was to do it now as well 2024-11-03 17:16:44 "The TSC does not want to merge /sbin and /bin for now" 2024-11-03 17:20:34 Note that abuild does warn about /usr/sbin, https://gitlab.alpinelinux.org/alpine/abuild/-/commit/da9269ba62b60757663ff8761ff7e218d1ab498c 2024-11-03 17:20:48 oh wait nvm, it got removed in the end I guess 2024-11-03 17:20:58 it was in the original patch anyway, but never got merged I see now 2024-11-03 17:21:29 personally I rather do it now as well, might just move everything at once rather than having to move stuff again in the future 2024-11-03 17:24:56 hmz, when i try to join the main #alpine-linux it says im unable to join because i need a regged nick? 2024-11-03 17:25:16 JohannesJacobs[m]12: We had to enforce it due to a spammer 2024-11-03 17:25:21 Yeah, it's +R 2024-11-03 17:25:21 I'll remove it again 2024-11-03 17:25:56 Done, but it's better to register your nick and to identify 2024-11-03 17:27:12 Even Fedora 41 does not have the sbin-merge (yet - planned for 42 now). 2024-11-03 17:27:42 void has had sbin merge since 2015 ^^ 2024-11-03 17:30:52 ikke: thanks! im on matrix, so im not even sure i can register a nick :) 2024-11-03 17:31:05 You can 😉 2024-11-03 17:31:56 ok well, thats for later to find out :) i finally managed to get synapse installed directly on alpine without the use of docker, thats enough for today :) 2024-11-03 17:32:32 registering a nick always goes through nickserv, and you can chat with it the same way. @_oftc_NickServ:matrix.org 2024-11-03 17:32:58 Without the use of Docker? That's like the opposite of what I would want 😛 2024-11-03 17:33:30 but its what i want ;-) 2024-11-03 17:37:04 PureTryOut: I noticed your merge request for "testing/avara" with regard to /usr vs /var. Thank you for your time on this effort. Is there anything I can do to help you there? 2024-11-03 17:37:26 JohannesJacobs[m]12: you'd first need to send "!irc nick " 2024-11-03 17:37:42 here or "!nick " in PM to @oftc-irc:matrix.org 2024-11-03 17:37:47 then you can register your nick 2024-11-03 17:38:09 hmz, maybe we should create a wiki for that, so others can know too 2024-11-03 17:38:42 [@_oftc_shrizza:matrix.org](https://matrix.to/#/@_oftc_shrizza:matrix.org) are you the maintainer of that package? If so, giving your approval would help 😄 2024-11-03 17:39:25 [@johannes:jhjacobs.nl](https://matrix.to/#/@johannes:jhjacobs.nl) tbh I don't think it makes sense on the Alpine wiki. And afaik the wiki of the actual bridge software already has the info 2024-11-03 17:39:56 shrizza: ^ 2024-11-03 17:40:10 PureTryOut: your ping translated very weirdly. I see > PureTryOut [@_oftc_shrizza:matrix.org](https://matrix.to/#/@_oftc_shrizza:matrix.org) are you the maintainer of that package? 2024-11-03 17:40:10 well, i couldn't find it :) 2024-11-03 17:40:25 markdown link to something 2024-11-03 17:40:54 it's fine 2024-11-03 17:41:19 Yes, but since committing that package I've since blown away my aports-related environment. I can login to the gitlab site though if there's any action I can perform there. 2024-11-03 17:41:23 it's just matrix annoyance 2024-11-03 17:41:58 How do I approve on the website? 2024-11-03 17:43:05 I don't think you have the rights for it, but you can just leave a comment 2024-11-03 17:48:22 pj: okay 2024-11-03 17:51:34 Should I click "close merge request"? 2024-11-03 17:53:45 No 2024-11-03 18:45:50 for updating and taking maintainership of an aport, is it better to do that in 2 commits or 1? 2024-11-03 18:51:21 2 commits 2024-11-03 18:53:31 thanks 2024-11-03 18:59:26 is there an issue with the riscv64 runner? 2024-11-03 18:59:47 always 2024-11-03 19:06:58 https://gitlab.alpinelinux.org/jvvv/aports/-/jobs/1588972 2024-11-03 19:07:10 Yes. It seems to work sometimes when you restart it. 2024-11-03 19:10:05 thanks for the heads up. i didn't want to just keep restarting it in case that put too much load. but it succeeded to run on try 6 or 7. 2024-11-03 19:27:53 Not sure yet why that's happening 2024-11-03 19:29:16 it's weird. that last mr i submitted, i lost count how many times i restarted. 2024-11-03 19:30:15 i'm sorry if that is wrong, and will handle it different if i am told to 2024-11-03 20:54:14 re usr-merge what i disliked the most out of this was the lack of transparency from the alpine team. it all started confidentially, then after two months it was made public and the next thing you know is the TSC has already approved it. if I wasn't exploring the gitlab I'd only know about it after it was done. 2024-11-03 20:56:40 confidentially in what sense 2024-11-03 20:56:47 none of it was secret 2024-11-03 20:57:09 The initial tsc request was made confidential by PMoS because they did not announce their plans yet 2024-11-03 20:58:10 yes, i understand that. but after it was made public the team should have been more transparent and announced it publicly. 2024-11-03 21:00:08 psykose: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/73 read it. it started confidentially. 2024-11-03 21:00:17 i have read it 2024-11-03 21:00:39 i also knew about the plans since before the issue was opened and i'm not an insider in any sense.. 2024-11-03 21:01:27 it is accurate that it's not publicly announced i guess on some website 2024-11-03 21:04:33 on "some" website huh. so how did you know about the plans since before the issue was opened if the pmOS team hadn't announced it yet? 2024-11-03 21:19:31 one just exists in spaces with developers and talks 2024-11-03 21:21:50 also where was the "lack of transparency" from alpine team, since I don't see how confidential issue that was opened 10 months ago and TSC accepting usr-merge proposal in August was "lacking in transparency" 2024-11-03 22:25:12 pj: to the users. as i said, and i'm going to repeat myself: if I wasn't exploring the alpine git, I would only have known about this after the change had affected my system. The issue, regardless of when it was opened, was confidential and that in itself has its bad implications. and TSC, after accepting usr-merge in August and only reporting so within the proposal, to the ones 2024-11-03 22:25:14 interested in having this change failed in writing a blog post to make the users and bigger community aware was indeed "lacking in trasparency". they knew it would lead to some resistence, and instead of laying out the techical advantages (linking to that same old freedesktop.org article, that links to systemd.io that we see everywhere we look about this change), making 2024-11-03 22:25:16 everything clear and open, it started confidentially, then the change was made and I'm sure that the average Alpine user/sysadmin (not the ones that "just exists in spaces with developers and talks", the ones that exist in other spaces. yes there are other spaces and even spaces exactly like the one you described but not relating to Alpine) still have no idea that this change is 2024-11-03 22:25:18 bound to happen. 2024-11-03 22:28:36 And it should not matter to them, because they will know about it from changelog 2024-11-03 22:28:43 if you run edge in production without keeping informed that is not really the devs problem, same goes for not reading release notes before updating 2024-11-03 22:29:35 You're talking about it how it's the end of the world, but way more changes like this happened before and surprise, we're still here 2024-11-03 22:30:30 The only reason it's so controversial is because it's semi-related to systemd for which everyone with "unix purism" mindset has such hate boner 2024-11-03 22:35:18 well it *is* generally a good idea to question what systemd does rather than following it. It's not about having a hate boner, it's just that systemd will do what is best for *itself*, and distributions that don't use it don't have to follow the trend. 2024-11-03 22:35:34 in the usrmerge case it's not very important. 2024-11-03 22:36:42 The only thing that has been decided is that alpine linux will use a usr-merged layout by default. There are various ways someone can take part in the discussion to have the end result fit their needs (as long as they are interested in finding a solution) 2024-11-03 22:36:45 (I personally don't care either way, but I *was* annoyed that the decision was initially made to accommodate the systemd way of doing things.) 2024-11-03 22:37:39 >You're talking about it how it's the end of the world[...] 2024-11-03 22:37:41 I'm really not. I'm talking about it like I saw something wrong with this, and I'm trying my best in making clear what the issue is. Now if you're reading this in a voice that sounds like what you're describing maybe the problem isn't how I'm talking about it. You also don't seem to be very interested in the issue itself, but insist and use very coersive language in trying to 2024-11-03 22:37:43 downplay what I'm presenting. And no, it's not "semi-related" to systemd. It's directly related to systemd because it only started from the wishes of the PostmarketOS devs to use systemd. 2024-11-03 22:39:35 skarnet: I feel the very same way. I don't find the usr-merge to be of big importance anymore and personally don't care, as I stated previously after researching on this, and to be honest I'm still a little annoyed it was made to accomodate systemd. 2024-11-03 22:40:39 welcome to Cassandra-land. I've been living here for 25 years. It's not very pleasant, but you get used to it. :P 2024-11-03 22:41:22 "personally dont care" preceded by 10 pages of concern trolling is quite the juxtaposition 2024-11-03 22:41:27 I'm just trying to talk and solve what I found to be wrong. 2024-11-03 22:41:30 i wonder if after all these months someone will come up with something new to say 2024-11-03 22:41:43 psykose: i'm not trolling. 2024-11-03 22:41:55 skarnet: Cassandra-land? 2024-11-03 22:43:16 the place where you constantly warn people of slippery slopes and bad decisions and things getting worse and enshittification, and nobody listens, and you were right the whole time but you can't point it out because nobody likes a downer self-righteous smartass. 2024-11-03 22:43:48 everything I'm saying is in good faith, and if it concerns you then maybe it's not as small an issue as you're trying to make it out to be. 2024-11-03 22:44:18 I'm only trying to talk here because I care. 2024-11-03 22:45:38 I totally get you. 2024-11-03 22:46:19 the thing is, once someone makes a decision, they'll always get criticism, one way or another, justified or not 2024-11-03 22:46:28 skarnet: I can totally relate to Cassandra-land. how do you live in it? this really sucks. 2024-11-03 22:46:29 so they have to stick to it and ignore the criticism 2024-11-03 22:46:41 because doing otherwise is a fast lane to insanity 2024-11-03 22:47:06 and it's frustrating when you honestly disagree with the decision, but that's how it goes 2024-11-03 22:48:56 how do I live in it? I try to disentangle myself from emotional attachment to other people's choices by having my own ecosystem where I do things exactly my way. It doesn't go very far, or very fast, but it's satisfying to the soul, and that gives me the necessary energy to interact with other ecosystems. :) 2024-11-03 22:49:07 skarnet: you're right. I'm not going to touch on the subject anymore, as it seems to take some people very personally, or really against their interests. 2024-11-03 22:50:07 >[...]by having my own ecosystem where I do things exactly my way.[...] 2024-11-03 22:50:09 funny thing, I was trying to develop on the exact same idea. 2024-11-03 22:50:33 you really do get me 2024-11-03 22:50:44 now kith 2024-11-03 22:50:55 and they call me a troll. 2024-11-03 22:50:59 pj: don't be jealous. Someone will love you someday. 2024-11-03 22:51:11 No, I will not allow that 2024-11-03 22:52:31 aleksi_: even among people who generally agree with the decisions made by their communities, there are *a lot* of pet personal projects, because everyone has an itch they need to scratch and that existing ecosystems do not address 2024-11-03 22:52:33 that's sad really. i hope for you the best in life and I'm sure you deserve love pj. 2024-11-03 22:52:43 so it's a very common and natural thing 2024-11-03 22:53:07 I'm emotionally detached from everything, helps a lot when getting berated by people for doing own thing 2024-11-03 22:54:43 So far I have been able to modify alpine linux to fit my needs but that was only possible by being involved (or at least notified) about most changes. This has unfortunately an immense time effort. 2024-11-03 22:54:52 pj: I love you friend. Life's just difficult like that. Don't give up. Everything is going to be okay. 2024-11-03 22:56:20 Seriously doubt it 2024-11-03 22:56:57 It's true. 2024-11-03 22:59:03 damn, if I'm so loved, can I add systemd to alpine then? 2024-11-03 22:59:28 last time I tried I didn't receive enough love 2024-11-03 23:00:36 Your machine is yours and you're free. 2024-11-03 23:00:54 no, no, to aports 2024-11-03 23:07:17 pj: maybe ask the pmOS devs how they implemented it, contrary to what some people here might think they put a whole lot of consideration and work into it, and they are a friendly and helpful bunch ;) 2024-11-03 23:09:10 very true, thought I was just trying to get some love that I've been hearing about 2024-11-03 23:09:42 though* 2024-11-03 23:10:25 >to aports 2024-11-03 23:10:27 That is not my decision to make. 2024-11-03 23:11:01 But you can voice your concerns 2024-11-03 23:11:11 pj: i give you permission to add systemd to aports 2024-11-03 23:12:58 "I didn't get love last time I sent a dick pic to a woman, maybe this time will be different?" 2024-11-03 23:14:09 anti-systemd people come up with best analogies 2024-11-03 23:14:23 STDs, dick pics, I sense some connection 2024-11-03 23:14:54 I don't remember mentioning STDs 2024-11-03 23:15:18 Which is why I said "people" and not you specifically 2024-11-03 23:15:21 SysTemD 2024-11-03 23:15:53 abby: it's right in the name, WAKE UP SHEEPLE 2024-11-03 23:17:47 anyway, i gotta sleep, try not to have too much drama here, it's hard to catch up with in the morning ;P 2024-11-03 23:18:32 I see no drama 2024-11-03 23:19:09 well, there's still somewhere between 6 and 9 hours for that to appear 2024-11-04 05:05:02 Heh, is this like The Bold & The Beautiful 2024-11-04 08:10:25 BTW, to stay on top of things: TSC minutes are available on gitlab which means you can subscribe to its RSS feed. 2024-11-04 08:11:16 I don't hang out in these spaces much but I was aware what was on the horizon since I follow those. 2024-11-04 08:54:08 weowzers 2024-11-04 08:56:03 skarnet: rather than rambling for hours on IRC why don't you publish your /usr merge critique in a blog post so we can have some civilised discourse. If there are real technical issues here that somehow every other distro and hundreds of engineers have totally looked past im sure we'd all love to know about it 2024-11-04 09:03:22 was paging through irssi and thought this was a DM directed at me for a second there 2024-11-04 09:03:29 also hi :) 2024-11-04 09:04:25 If I'm successful at rebuiling the ports tree for more systems you might be talking to the future Alpine SPARC maintainer ;) 2024-11-04 09:04:42 once I learned about how cool and simple the Alpine ports tree is, I realized that I may never have to use Gentoo ever again :) 2024-11-04 09:05:34 Python for package managers, not even once 2024-11-04 09:06:11 so far apk has been fast and boring (a good thing) 2024-11-04 09:07:22 currently running a Sway compositor fork named SwayFX on an original 2013 Surface Pro and loving Alpine so far. Busybox and open-rc are a match made in heaven :) 2024-11-04 09:08:22 I don't want to enter this argument, but I will say, doesn't artix implement usr-merge too, despite being against systemd? 2024-11-04 09:08:50 (full disclosure: I don't care about usr-merge much) 2024-11-04 09:09:11 wouldn't they just get it "for free" by virtue of being based on Arch? 2024-11-04 09:09:22 the usr-merge hasn't broken anything on my Arch systems 2024-11-04 09:09:37 ...yet 2024-11-04 09:09:39 ;) 2024-11-04 09:09:45 it's been a few years 2024-11-04 09:09:46 Newbyte: Pretty much. But so far no one complained, from what I can tell. 2024-11-04 09:10:08 ¯\_(ツ)_/¯ 2024-11-04 09:10:10 targetdisk: it's been over a decade now even 2024-11-04 09:10:13 yeah 2024-11-04 09:11:15 targetdisk: I kind of miss my Surface Pro 3. It sucked, but it was really nimble. I unfortunately dropped it one day and the frame got bent. It still works, technically, but one corner of the screen is dead. 2024-11-04 09:11:41 I liked this thing so much that I ordered its better Dell cousin ;) 2024-11-04 09:11:47 it's on its way 2024-11-04 09:12:21 found a beat-up one of these on eBay for $80: https://www.notebookcheck.net/Dell-Latitude-5290-2-in-1-i5-8350U-Convertible-Review.290788.0.html 2024-11-04 09:13:11 when I realized that the screen resolution on the eBay listing wasn't a typo I got *really excited* (1920x1280, 3:2) 2024-11-04 09:13:33 has battery I can replace without melting glue :) 2024-11-04 09:14:36 I've decided that I will just have smol laptops and thin clients at the desk and just shell into my compute/server/NAS infra across my local Google KCMO "fiberhood" 2024-11-04 09:33:59 thats what i like alpine for, then clients :) 2024-11-04 09:34:06 its really thin! 2024-11-04 11:04:58 targetdisk: re sparc: that's pretty cool, i kinda ran out of steam with my superh port, so it is good to see people have success with similar undertakings :) 2024-11-04 13:05:12 ncopa: pgsql17 fails only on x86_64 builder but mysql in CI all arches... 2024-11-04 13:24:27 bOR38552MJA: I'm back alive 2024-11-04 13:25:28 I've seen in the backlog that you've been debugging your issues. Do you have any thoughts about what might have gone wrong? 2024-11-04 13:26:48 sertonix: regarding https://gitlab.alpinelinux.org/alpine/aports/-/issues/16514 I think I generally agree with you 2024-11-04 13:27:39 Main reason we didn't go with that path from the beginning is https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/155 2024-11-04 13:28:35 That suggestion you do is how we started implementing it downstream in postmarketOS 2024-11-04 13:29:21 But things broke when APK removed symlinks: 2024-11-04 13:29:38 something was supposed to be installed in /lib, but /lib was a symlink, and APK removed the symlink, breaking the whole thing 2024-11-04 13:30:20 I'm not exactly sure if that happened with any package, or if there were some specifics that had issues (busybox being one of them) 2024-11-04 13:30:42 Anyhow, I'm very happy that you are being so propositive about this 2024-11-04 13:31:49 It's possible there were some subtle problems that could be fixed in different way than what we are doing now 2024-11-04 13:32:24 If you want, then I'm happy if we take some time aside and do some planning session together of alternatives that could work 2024-11-04 13:34:55 caleb_m: why are you highlighting me? it sounds like you believe I did something when I did not 2024-11-04 13:50:49 PabloCorreaGomez[m]: first of all i think when you mount /usr from initrd it should be ro not rw, since this will prohibit later fscking this partition ever, /usr should be remounted rw after fsck was done. 2024-11-04 13:52:44 second i have run multiple times eudev-..-r3 successfully, and multiple times eudev..-r5 including your mkinitfs /usr mount patch unsuccessfull. my canary was /dev/dri/card0 which should be owned by the video group, as mandated by [/usr]/lib/udev/rules.d/50-udev-default.rules:33 2024-11-04 13:54:27 when testing this, i also run in single mode and while still in initram i noticed that /dev/dri/card0 had the correct group (due to /etc/mdev.conf) but that was then broken when continuing boot and having eudev..-r5 take over. 2024-11-04 13:55:16 /dev/dri/card0 is quite important, as without the video group it has only 0600 rights and is owned by root, precluding any user to run their x11/wayland setup. 2024-11-04 13:56:14 when running udevadmin trigger manually /dev/dri/card0 got its correct rights, but curiously /dev/dri/renderD128 did not. 2024-11-04 13:57:59 i also enabled udev_debug in /etc/conf.d/udev, and generated full logs with both the working and the broken setup. these logfiles are available on request. the broken setup produces a logfile that is 10% size of the correct setup with eudev..-r3 2024-11-04 13:59:37 That and dmesg might be useful, yes 2024-11-04 14:00:20 dmesg looks ok. 2024-11-04 14:00:59 In your current setup, with minimal / chainloading to /usr, I guess openrc localmount is the service responsible for mounting /usr and continuing boot? 2024-11-04 14:01:27 how can i dm you? you are on matrix, me on irc. 2024-11-04 14:02:33 Bridge work! 2024-11-04 14:09:58 i not against /usr merge, but theoritically nothing needs changes in source, doing /sbin /bin /lib symlink or mount --bind during early boot have done it 2024-11-04 14:11:15 mount --bind could solve /lib or firmware issues 2024-11-04 14:11:49 unless /root is pure ground not be polluted with directories 2024-11-04 14:13:46 which means everything gets installed in /usr (physically) so RO argument solved 2024-11-04 14:17:41 also leaving empty folder in /usr/system/[s]bin could leave room for purist who have to mount partitions onto it 2024-11-04 14:18:06 thereby old FHS just remains as is 2024-11-04 14:18:55 strong point is everything goes to /usr, but not source code changes needed except "init" script 2024-11-04 14:19:04 but no^ 2024-11-04 14:19:21 If you really have a better suggestion for implementation, please comment on the corresponding issues as Sertonix did 2024-11-04 14:20:04 PabloCorreaGomez[m]: none, i am not opposing /usr merge 2024-11-04 14:20:16 go ahead 2024-11-04 14:20:42 You are presenting a suggestion for the implementation. Please don't dump it here where we can't follow-up 2024-11-04 14:23:16 agreed JohannesJacobs[m]12 :) 2024-11-04 14:23:26 l 2024-11-04 14:23:33 oop 2024-11-04 14:26:13 omg I hate the split sbin PATH in Debian, please don't infect Alpine with that crap 🙏 2024-11-04 14:27:31 would think to add user comment, let the article(FAQ) planned get published first (with links post where) 2024-11-04 14:45:31 i want to make a package, it would patch to a file from another package if installed, is this legal? 2024-11-04 14:46:09 imo, this is under "more linux ... change for change's sake" but where it concerns alpine i just hope this is the last layout change for the next (n) years 2024-11-04 14:55:08 that's an offshoot of large layoffs, now good engineers dont' know what to do 2024-11-04 14:57:15 now ai is comming too, be prepared fo more changes, what to do... what to do... 2024-11-04 14:58:06 well economically breaking things can create jobs 2024-11-04 15:00:23 software engineering/methods are practically at its pinacle, hardware may not be 2024-11-04 15:02:44 i am currently re-testing it in a clean container instead of my old dusty chroot, but we may have some breakage in the bootstrap process, specifically gcc-pass2- 2024-11-04 15:16:25 addendum to my "hope" above -- like /usr/etc is floating around out there (eg suse) and perhaps more i don't even know about. whatever the decisions, just imo, i want the layout to be change-free for the next ~5 years, regardless of what goes in now. 2024-11-04 15:33:47 i won't be surprised if whole /usr(ro,encrypted) moves to cloud and thin boot in mobiles mounts it from cloud, super-proprietary 2024-11-04 15:34:24 even if the /usr code is open-source, who whould know 2024-11-04 15:39:05 sim cards are now coming in-build, wakey-wakey 2024-11-04 15:39:14 software engineering/methods are practically at its pinacle - that is what we thought in '85, when waterfall was perfected, and Gane/Sarson and Yourdon ruled. 2024-11-04 15:40:24 mercenary: that's was when obfuscated codes/blobs were considered good as it ran faster 2024-11-04 15:41:03 if you starting unit functional codes, its almost narrowed down 2024-11-04 15:41:52 how mayways can one write a byte/bit to human-readable MB,GB functions - just example 2024-11-04 15:42:40 but if you mix that function (obfuscate,encrypt) same can be done in hundereds of ways 2024-11-04 15:45:02 only things that is left is AI's ML, mimicking human brains 2024-11-04 15:46:01 more advanced enryptions is another 2024-11-04 15:46:05 The only constant is change. On the hardware side, you will see a constant oscillation between parallel and serial. MFM/IDE/uwSCSI, SATA/SAS, and now fast USB has 4 parallel channels again. 2024-11-04 15:47:45 well some yrs back they thought copper wire has reached its max, but then it turned out 1GB was possible (iirc), but then optics took over 2024-11-04 15:48:35 my comments were meant to avoid polluting the gitlab issue with hopes & dreams, but i feel like this is unproductive conversation. 2024-11-04 15:48:38 major factor is market/economic control needs to be done 2024-11-04 15:48:53 ok, i am out 2024-11-04 15:57:31 is there a way to cross compile with abuild rootbld ? 2024-11-04 16:01:18 not sure if cross-compile, probably only when bootstrapping? 2024-11-04 16:01:30 there's definitely emulated builds with rootbld 2024-11-04 16:12:22 bl4ckb0ne: use CBUILD and qemu-user ? 2024-11-04 16:18:13 ikke: what's the abuild change you mentionned in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73478#note_447955 ? 2024-11-04 16:24:13 bl4ckb0ne: I believe this one: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/283/ 2024-11-04 16:25:02 ty 2024-11-04 16:26:26 ie, it was always shown as an error, but the error was masked, so the build continued 2024-11-04 16:27:50 would it be possible to get the file causing the error? or getting more logs from the CI? 2024-11-04 16:29:06 Perhaps with some scanelf invocation? 2024-11-04 16:29:32 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1590484#L252 im only getting this, and only on arm 2024-11-04 16:39:36 Pablo Correa Gomez: I think the issue with those apk-tools patches is more subtle... But it's quite clear that it's not a sustainable approach 2024-11-04 16:41:26 sertonix[m]: any thoughts on what could cause the fail only on arm? 2024-11-04 16:42:13 skarnet: well this is the second time (that i've seen) where you're in here moaning about how you've managed to do this and that fancy thing without the /usr merge and that you think it's a "bad direction" or whatever. frankly it's just a downer. I'd rather engage on technical terms in a more productive format, or i'd rather you stopped with the FUD 2024-11-04 16:53:19 but are you even paying attention to what you're reading or what 2024-11-04 16:53:58 I came here *once*, like a month ago if not more, and moaned about it, yeah, because I had just discovered the decision 2024-11-04 16:54:32 yesterday it's *not at all* what happened, but apparently since I intervened in the discussion you decided to latch onto me 2024-11-04 16:55:36 so if you want to engage on technical terms in a more productive format (sic), maybe start by not lying and accusing people of doing what they didn't do? 2024-11-04 17:07:27 IRC can be a bit ephemeral at times, this is why people suggested you make a blog post or use mailing lists skarnet :) 2024-11-04 17:07:50 for instance, I just joined last night :) 2024-11-04 17:10:05 mercenary: Are you meaning PCIe/TB/USB4, cause those are multiple lanes of a packet-based serial protocol with differential signalling, no? I've been living under a rock but from what I've read that's roughly how PCIe works 2024-11-04 17:11:10 it's "parallel" in that the lanes can be aggregated together, but it is still very much a serial bus if I understand the nomenclature of EE correctly 2024-11-04 17:12:14 When I think of a parallel bus, I think more of our double-data rate DRAM buses or of the legally encumbered shitshow that is HDMI (DVI with extra steps) 2024-11-04 17:13:08 parallel busses are "parallel" in the sense that they are wired up to transfer an entire "word" at a time with parallel signal paths 2024-11-04 17:13:14 at least that's how I understand it 2024-11-04 17:13:38 targetdisk: various multi-lane strategies. The point is the it starts out parallel, then things get faster and PCB design and lenght-matching gets too difficult so it goes serial, then some advances in signal processing and suddenly a couple of serial things can be paralleled again 2024-11-04 17:13:39 I am not a *real* EE, just a self-taught computer engineer that is starting to play with FPGAs and micros 2024-11-04 17:13:49 sure 2024-11-04 17:14:05 I *really* want to design a custom board around surplus M1 SoCs ;) 2024-11-04 17:14:27 I'll have to pair them with the matching fingerprint sensors if they came from a MacBook or something tho 2024-11-04 17:15:08 I really like the M1 "SoC" that has the DRAM on the substrate 2024-11-04 17:15:49 I bet I could get some Chinese factory to help build custom M1-based UMPCs that run macOS/Asahi Linux 2024-11-04 17:15:51 Designing boards for those speeds is above my pay-grade. Up to 100 or 200MHz, fine, that you can still eyeball and trial/error. Above that, needs $$$ field solvers to be sure 2024-11-04 17:16:14 the schematics for my M1 MBA already "fell off a truck" 2024-11-04 17:16:35 I'd just have to handle power management, external I/O, and SSD traces 2024-11-04 17:16:46 no fast parallel bus layout req'd 2024-11-04 17:17:01 M1 substrate has all that on the giant BGA package for you ;) 2024-11-04 17:18:02 quite varied interests between this and sparc :D 2024-11-04 17:18:15 I pick the right trash computers for the job 2024-11-04 17:18:36 I am a hacker, but like in the classical sense ;) 2024-11-04 17:19:12 ahhh, i see, i do the opposite, i pick the wrong ones ;P 2024-11-04 17:19:16 hehe 2024-11-04 17:20:11 I also really like studying Apple's stuff with the intent of "stealing" every insanely great idea they've ever had for free software/OSHW 2024-11-04 17:21:01 I'm at least friends with Zoë the lead dev of ravynOS :) 2024-11-04 17:21:38 I want to make a parallel system that runs on the Linux kernel and has wider driver support without the bullshit BSD licensing restrictions that FreeBSD imposes on their system 2024-11-04 17:22:07 I think the world needs a serious alternative to Qt. GTK ain't it. Qt is fast, but ugly and not flexible enough 2024-11-04 17:22:24 Cocoa/GNUStep are things I want to run with 2024-11-04 17:23:06 I even got the creator of advanced macintosh substitute (my friend Josh) to collab with her on it :) 2024-11-04 17:23:18 https://arstechnica.com/information-technology/2019/01/emulator-project-aims-to-resurrect-classic-mac-apps-and-games-without-the-os/ 2024-11-04 17:28:56 also re sparc: i didn't know there was musl for sparc 2024-11-04 17:30:18 but then again i am entirely unaware of what exist out of tree 2024-11-04 17:31:51 I have started to shake some trees here, https://not.insteps.net/, 2024-11-04 17:31:59 and some mobile related codes https://git.insteps.net/ , the codes have some generic functions that can be tried on exotic alpine installations. 2024-11-04 17:39:08 shit there's even GRUB for SPARC now 2024-11-04 17:39:25 I'll need to submit a patch to KVM if I want hypervisor support on SPARC tho 2024-11-04 17:40:13 KVM definitely supports POWER, PowerPC, aarch64, and x86_64. It may also support RISC-V now, haven't been keeping up 2024-11-04 17:40:21 but SPARC and KVM aren't friends yet 2024-11-04 17:41:04 which is a real shame, because my two SPARC boxen have 128 threads of awesome and 128 GiB of ECC DDR3 memory 2024-11-04 17:41:21 the 128 threads are from 8-way SMT on 16 core CPUs 2024-11-04 17:41:55 imagine having 128 Pentium III cores duct-taped to 128 GiB of DDR3. That's about what it performs like 2024-11-04 17:42:05 bl4ckb0ne: It looks like the file is linked differently there. This is what I extracted from the the current alpine edge packages:... (full message at ) 2024-11-04 17:45:49 libc.so.6 is also glibc only. So definitely trying to build for glibc instead of musl libc. 2024-11-04 17:55:50 Hm am I missing something on why we have so many versions of lua? And why some ports are requiring specific older versions just because I guess they have to be updated by hand? 2024-11-04 17:56:45 lua version bumps require actual work in software that depends on it 2024-11-04 17:56:52 they're not automatically compatible 2024-11-04 17:57:46 I bumped some of the packages that worked fine. So I guess they have to be done on a case by case basis... every single time? 2024-11-04 17:58:01 and so just a normal install having 3-4 versions of lua at once is just the norm? 2024-11-04 17:58:51 5 if you count jit :) 2024-11-04 17:59:28 but what Habbie says is correct, there a plenty of Lua applications/modules out there that are 5.3 and later compatible only 2024-11-04 17:59:32 Yeah I saw that one too, but since it's in main, I just gave it the benefit of the doubt. 2024-11-04 18:00:37 between 5.2 and 5.3 lua changed the way they handle bitwise operators for example. So in 5.3 and later things like >> are valid, but won't work on 5.1/5.2 and sometimes jit which sort of does its own thing and is 5.1 based. 2024-11-04 18:00:42 If you install the main package it will pull in all the available lua versions. You can install lua modules for only specific versions through the `lua-` subpackages. 2024-11-04 18:01:33 That's the opposite of what I'd want 2024-11-04 18:01:35 if there is no difference and a lua package is actually compatible between versions then it can be installed into lua/common, that would be the preference 2024-11-04 18:01:53 xulfer: If you tell me which packages you are referring too I could take a look at them 2024-11-04 18:02:32 I can bump them myself, and have. It just seems tedious, and I'd rather not have to track and pester people each time there's a lua bump to also bump their packages. 2024-11-04 18:03:00 I'll just handle it. Seems disappointing to be taking the 'just install everything' approach though. 2024-11-04 18:04:18 Because I don't care about the newer lua. I just want one lua. 2024-11-04 18:04:56 if you really wanted to you could patch them until they work across all the different lua versions, but this is a lot more effort 2024-11-04 18:05:25 Yeah that's my plan. Anything else would just be pushing the tedium onto others who have better things to do. :) 2024-11-04 18:05:31 sertonix[m]: so that would be an actual jellyfin issue/ 2024-11-04 18:05:38 s/\//? 2024-11-04 18:06:10 let me know if you'd like some help with that xulfer I maintain quite a few lua packages and have been slowly working towards moving things into common where I can. 2024-11-04 18:06:20 I too would like it to be a little cleaner. 2024-11-04 18:10:23 xulfer: The thing I said about lua packages wasn't correct. The main package doesn't install everything. It only installs the subpackages that belong to lua versions already installed. 2024-11-04 18:10:57 Oh okay. That's handy. 2024-11-04 18:11:48 I didn't notice the difference cause I have almost all lua versions installed ;) 2024-11-04 18:16:06 bl4ckb0ne: I would guess that it is ether a dotnet or a jellyfin issue. 2024-11-04 18:27:47 ran it with diag verbosity, didnt expect that many output 2024-11-04 18:28:22 > Job's log exceeded limit of 104857600 bytes. 2024-11-04 18:45:11 trying to remember the right way to create a "virtual APK" subpackage that just pulls in a collection of other APKs... 2024-11-04 18:47:02 Do you mean a virtual package? 2024-11-04 18:47:22 apk add -t _virtual_package pkg_dep_1 pkg_dep_2 pkg_dep_3 2024-11-04 18:47:44 yeah, no... more along the lines on how to set up the APKBUILD 2024-11-04 18:48:12 this package has a bunch of optional subpackages -- i want a virtual subpackage that pulls in all the subpackages 2024-11-04 18:48:54 would you just add them as depends to the virtual subpackage? 2024-11-04 18:49:02 You can create a package that doesn't contain files but depends on a list of packages. 2024-11-04 18:49:40 got that, but there's also an install script 2024-11-04 18:51:06 complains there's a missing $HOME/aports/main/$package/pkg/$subpackage/ -- prepare_subpackages failed 2024-11-04 18:52:46 ok, got it... just needed to create an empty $subpkgdir 2024-11-04 19:00:12 ok tomalok :) 2024-11-04 19:43:13 sertonix[m]: can i convince you to have a look at #16588, it appears to have been introduced by the gcc modernization/simplification 2024-11-04 19:45:30 bot sleepy, or just the comma? #16588 2024-11-04 19:59:14 socksinspace:is that dir empty /home/socksinspace/aports/main/gcc/pkg/gcc-pass2-x86/usr/i586-alpine-linux-musl/lib/ 2024-11-04 19:59:42 !16588 2024-11-04 20:00:03 algitbot is asleep perhaps 2024-11-04 20:00:07 khem: after the failed bootstrap? 2024-11-04 20:00:19 yes 2024-11-04 20:01:30 ahhh, let me see, might take a sec, i was trying different commits to narrow down the cause 2024-11-04 20:02:12 a sec being around ten minutes 2024-11-04 20:02:15 perhaps add a check for that dir to be not empty before doing the mv 2024-11-04 20:07:06 maybe, gcc packaging is far from my expertise, i just run `bootstrap.sh` and `buildrepo` while hoping for the best :) 2024-11-04 20:10:27 the question is: what should be there and why is it not there when building a cross compilier 2024-11-04 20:11:05 It's possible that I messed something up there. 2024-11-04 20:16:43 from my perspective it is not too urgent, but i would be happy to have a working bootstrap path when the next release gets forked so i can have a slower moving base for my experiments :) 2024-11-04 20:25:50 regarding the question khem asked: that directory doesn't exist, in `aports/main/gcc/pkg/gcc-pass2-x86/usr/` there are `bin` `lib` and `libexec` at that point 2024-11-04 21:43:35 sertonix[m]: thanks for poking at the jellyfin arm issue 2024-11-04 22:46:10 1:04 AM If I'm successful at rebuiling the ports tree for more systems you might be talking to the future Alpine SPARC maintainer ;) 2024-11-04 22:46:18 there is no musl port to sparc 2024-11-04 22:49:49 i am also extremely skeptical that a sparc port could meet release qualification 2024-11-05 10:11:46 Extremely specific request: 2024-11-05 10:11:46 Please keep the modules/drivers/firmware for rtl8811cu and rtl8821cu 2024-11-05 10:12:21 It's extremely annoying now that not only are they completely excluded, USB thethering isn't something that easily done by default either 2024-11-05 10:13:38 All I can find are these: rtw88_8821c and rtw88_8821ce 2024-11-05 10:59:06 re gcc-pass2-: the only theory i have so far is that maybe the mv in line 471 shouldn't run for the nolibc bootstrap, so i'm currently testing that 2024-11-05 11:23:42 ERROR: libgnat-static-14.2.0-r4: trying to overwrite usr/lib/libgnarl.a owned by gcc-x86-14.2.0-r4. 2024-11-05 11:23:52 that's progress :) 2024-11-05 11:24:48 DaeDae[m]: where are they excluded? 2024-11-05 11:27:13 ncopa: this is a follow-up from the discussion in #alpine-linux where CONFIG_RTW88_8821CU isn't present in the config files for the linux kernel abuilds, where rtl8821cu is apparently equivalent to rtl8811cu 2024-11-05 11:27:38 and daedae was troubleshooting network issues for the rtl8811cu 2024-11-05 12:54:19 i think https://gitlab.alpinelinux.org/alpine/aports/-/issues/9074 shoud probably be moved to the TSC? or should I just open a nother issue and reference to it? 2024-11-05 13:32:29 tethering via usb can be a problem, some basic method is here, https://git.insteps.net/mobile/mobile/tree/data/alpine/bin/recovery/tethering.rndis.sh 2024-11-05 13:38:11 got 2024-11-05 13:38:17 rm: cannot remove '/boot/initramfs-edge': No such file or directory 2024-11-05 13:38:25 twice, when upgrading linux-lts 2024-11-05 14:32:35 a quick correction for my previous messages: i was informed that the full configurations for the kernel should be referenced from /boot/config-* files instead of the repo's abuild config files, so the message about it can be disregarded 2024-11-05 14:34:10 additionally i was informed that CONFIG_RTW88_8821CU is disabled by default in the kernel and is not an alpine-specific configuration 2024-11-05 15:03:14 $ grep RTW88_8821CU /boot/config-6.6.59-0-lts 2024-11-05 15:03:14 # CONFIG_RTW88_8821CU is not set 2024-11-05 15:03:21 seems to be correct yes 2024-11-05 15:09:12 mebious: feel free to open an issue ow what ckernel modules you want to enable 2024-11-05 15:09:36 $ grep RTW88 /boot/config-6.6.59-0-lts | tpaste 2024-11-05 15:09:37 https://tpaste.us/j1x1 2024-11-05 15:10:16 does anyone have time to help find out whats wrong with the postgresql17 tests? something with timezone if going wrong 2024-11-05 15:10:23 mariadb appears to have similar problem 2024-11-05 15:10:50 it is likely something in recent tzdata that no longer matches the postgresql17 expectation 2024-11-05 15:11:37 and I suspect it may be related to day light saving, as the tests passed before we switched to winter time 2024-11-05 15:12:08 maybe it will start work again when US switched to winter time as well. I dont know 2024-11-05 15:12:32 the issue is blocking the 3.21 release so help is highly appreciated 2024-11-05 15:13:12 mariadb issue: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74618 2024-11-05 15:15:41 Us already switched this weekend 2024-11-05 15:24:46 ncopa: possibly related? https://openbsdmailbox.blogspot.com/2024/11/timezone-etcgmt1.html 2024-11-05 15:30:19 maybe https://github.com/postgres/postgres/commit/af2115226831 2024-11-05 15:36:10 seems to have been it, based on local build test. making PR 2024-11-05 15:37:36 ncopa: !74693 for pg. don't have time to look at mariadb 2024-11-05 15:38:17 Potentially stupid question related to daylight saving time - shouldn't the default crontab avoid scheduling between 2:00 and 3:00? I don't have a default install but I think this was the case by default. 2024-11-05 15:39:32 "between 2:00 and 3:00" is not universal for when the switch happens 2024-11-05 15:40:09 so it's not really possible to avoid cron scheduling problems by avoiding certain timeslots if you insist on using local time for it 2024-11-05 15:40:15 lotheac: anything that prevents cron jobs to run twice, or not at all 2024-11-05 15:40:45 my advice is to keep your crond's in TZ=UTC and set TZ=whatever in your local user shell init files or something similar 2024-11-05 15:41:04 but not everyone agrees of course 2024-11-05 15:41:12 lotheac: OK makes sense 2024-11-05 15:41:30 https://utc-or-gtfo.creator-spring.com/ 2024-11-05 15:41:33 sorry :) 2024-11-05 15:42:19 becoming slightly offtopic but this was enlightening https://ssoready.com/blog/engineering/truths-programmers-timezones/ 2024-11-05 16:01:35 suspected it was something like that. thank you very much! 2024-11-05 16:09:41 broke: localtime, woke: UTC, bespoke: TAI-10 2024-11-05 19:01:27 mps: i got the same build error on my ppc64le. previous version of dosbox worked, but 0.82.0 failed on my box as well 2024-11-05 19:01:39 (ppc64le box) 2024-11-05 19:02:15 im guessing a build flag is missing because the error is related to gcc :/ 2024-11-05 19:07:22 it's just src/cpu/meson.build detecting ppc wrong and defining the 32-bit define for 64-bit ppc 2024-11-05 19:07:29 you can delete the line with 'POWERPC' on it and it probably works 2024-11-05 19:09:03 ohh that makes sense 2024-11-05 20:09:30 Is there a reason we have start to remove instances of installation/directory creation in /var/lib /var/log in APKBUILD files? 2024-11-05 20:09:46 s/have start/have started/ 2024-11-05 20:11:36 Specifically in instances where /var/lib is used correctly. I understand moving read-only data into /usr/share is FHS compliant, and is not what I'm referring to. 2024-11-05 21:08:59 durrendal: it's not FHS compliant (because files installed by packages are by definition not "variable"). It's perfectly fine to use /var/lib, but it's not something the package should provide. Instead it's something the software itself should create or the init file 2024-11-05 21:10:12 PureTryOut: The anoying thing is that you need to make sure that the directories exist, which you especially run into with docker 2024-11-05 21:11:07 So with woodpecker specifically I should add checks to create the directories in the openrc script when the service is first run, even if those directories are empty? 2024-11-05 21:11:17 That's what the init file is for. And imo if you have a Docker image to run that software, you have to make sure yourself that the directory is created in the image. 2024-11-05 21:11:56 Still, it's anoying you have to repeat that every time you install a specific package 2024-11-05 21:12:01 durrendal: ah I see you're the one that responded to my MR. I just answered there, me removing `/var/lib/woodpecker` from the checkpath calls in the init files was a mistake and I just restored them 2024-11-05 21:12:01 I think that's a pretty poor way to package software frankly. Containerization is not going to just go away, and a primary use case of Alpine is in containerized applications where an init system cannot always be ensured 2024-11-05 21:12:05 ie, manually finish the installation 2024-11-05 21:13:04 I don't think people only install packages from the repositories when they use Docker images. They always install just the dependencies from the repositories and then "manually" install the actual software they have the Docker image for. It's not at all strange to then also do a mkdir in that same Dockerfile 2024-11-05 21:13:18 And such directories are often mounted from outside the container anyway 2024-11-05 21:13:23 (since containers are supposed to be immutable) 2024-11-05 21:18:25 Sure it might not be strange to add another command to a dockerfile, ansible playbook, or some other configuration management system to check that a path exists 2024-11-05 21:19:02 but I think it's a failure for us to acknowledge a directory must exist for a system to run properly, and then not ensure that that exists in our own configuration 2024-11-05 21:19:41 it isn't a matter of whether the consumer can check for the directory and make it, they should, but so should we when it's needed. 2024-11-05 21:20:26 I disagree that we don't ensure that. We do through the init file. And like I said in Dockerfiles nobody just does `apk add woodpecker` and then run that. They'll do `apk add ` and then manually copy in the code, compile the thing and run it. Part of that process is ensuring the directories it needs exist. And `/var` is something that should be mounted into the container anyway, since it's runtime _variable_ 2024-11-05 21:20:27 data that should not be wiped when the container is. 2024-11-05 21:20:53 PureTryOut: I regularly just install the package from aports 2024-11-05 21:20:59 your assumption is incorrect 2024-11-05 21:21:06 that is WHY I package these things for Alpine 2024-11-05 21:21:07 case in point, gitlab-runner is just installed from apk 2024-11-05 21:21:17 so that my resulting dockerfiles will be smaller, and I can benefit from the ecosystem 2024-11-05 21:21:44 And there is still a difference between making sure /var/lib/woodpecker exists in a package and actually installing files to it. I can sort of see a use-case for the former (although I personally disagree with it) but the later is just wrong 2024-11-05 21:22:34 Ok interesting, I suppose I personally just disagree with that way of working then and there are different points of view on that specifically. Fair enough. Still, we shouldn't actually install files to those directories when they are meant to be somewhere in /usr instead 2024-11-05 21:23:17 to clarify, I think you change moving the files from /var/www/ to /usr/share is valid 2024-11-05 21:23:53 I'm specifically disagreeing that creating directories in /var/log and /var/lib goes against FHS compliance, and that those should be kept in APKBUILDs 2024-11-05 21:24:00 Great, as that's my main point. I don't agree with making /var/lib/woodpecker in a package personally but I suppose I see why people would want it 2024-11-05 21:24:09 empty directories that are then populated by the application at run time are within FHS compliance 2024-11-05 21:24:52 As long as we keep them empty, I'm happy for now to keep creating them. Even though I still think it's not the proper way to do it 2024-11-05 21:26:21 I appreciate that, and would be happy to approve the MR if you made those changes. And would encourage you to consider the use case suggested above the next time you run across something like this. 2024-11-05 21:26:30 which you will, when you look at salt or grlx probably 2024-11-05 21:27:49 I just think Docker images should be immutable, you should be able to docker rm them and recreate it and it should run without any differences. Keeping /var just inside the image works against that, it should be mounted from outside in which case it doesn't help creating the directory from apk. But alas, matter of opinion it seems 2024-11-05 21:28:00 (no clue what salt or grlx is btw) 2024-11-05 21:28:35 yes, but the directory should exist with the right permissions for volumes to create on 2024-11-05 21:29:08 If the directory exists and has the proper permissions, the volume with take that over 2024-11-05 21:29:16 Yes, and that's for the one to run the image to figure out. It's impossible to do that from within the Dockerfile anyway when it's being mounted from outside 2024-11-05 21:29:31 There is the VOLUME directive 2024-11-05 21:29:41 But again, matter of opinion. We can keep discussing this but I don't think it helps anyone right now 😛 2024-11-05 21:30:31 durrendal: pushed the changes, `/var/log/woodpecker` is kept now 2024-11-05 21:30:42 PureTryOut: I just meant that it seemed you were systematically going through aports changing them, and would eventually run into other places I had followed the same logic, that's all. 2024-11-05 21:30:47 Thank you 2024-11-05 21:30:59 I am indeed, I did not realize those are packages I still have to get too 2024-11-05 21:31:18 Taking my time though, there is no hurry in this imo 2024-11-05 21:32:19 small nit, can you change the directory argument in both initd's back to /var/lib/docker? 2024-11-05 21:32:25 after that it should be set. 2024-11-05 21:33:07 What does that variable do exactly? I assumed it was meant to point to the install location 2024-11-05 21:33:37 Oh actually, that's not where it pointed too before either 2024-11-05 21:33:44 Yeah I'll change it back, I read that wrong 2024-11-05 21:34:38 Done 2024-11-05 21:35:02 Yeah it's where woodpecker is supposed to operate in, where /usr/share/webapps/woodpecker would be the frontend static web content 2024-11-05 21:35:42 Does the variable actually do anything though? It's not being referenced anywhere 2024-11-05 21:36:00 Thank you again, and I appreciate you being open to discussing it and not just merging the change in 2024-11-05 21:37:14 Np, thanks for providing the feedback! 2024-11-05 22:17:47 Re the variable, that's correct. 2.7.2 was just released and I'm fixing up the package to get it ready to move to community. So while removing it now wouldn't break anything, I'd just be adding it back. 2024-11-05 22:19:53 Sure 👍️ 2024-11-06 01:05:41 ncopa: i'll leave that to daedae if they want to pursue that since they have the rtl8811cu. i don't have the device myself so it doesn't concern me 2024-11-06 08:19:17 guessing most of these should be possible to switch to gpep517 packaging https://pkgs.alpinelinux.org/contents?file=*&path=/usr/lib/python*/site-packages/*egg-info 2024-11-06 08:21:22 some may still be more tricky than others 2024-11-06 08:21:34 Oh there are still packages on Python 3.11? That should be fixed... 2024-11-06 08:24:06 ACTION makes MR in a bit 2024-11-06 08:32:14 not on 3.11, but packaged the old way 2024-11-06 08:34:57 No several packages are definitely still on 3.11 2024-11-06 10:59:10 PureTryOut (matrix.org) durrendal: maybe one option is to create those `/var` dirs in post-install scripts? 2024-11-06 10:59:58 I'm not sure if there's technically a difference 2024-11-06 11:02:19 Maybe it does when there are permissions that should be enforced? 2024-11-06 11:02:34 Any 'go' packaging experts here? Getting an error with my webhook package, which I'm managed to 'fix', but I don't really know 'go', so not sure if what I've done is 'the done thing'. 2024-11-06 11:19:44 During the tests, it uses this method to build a helper go app: https://github.com/adnanh/webhook/blob/master/webhook_test.go#L201 2024-11-06 11:20:23 However, at line 217, it looks like 'runtime.GOROOT()' is returning an empty string, so it tries to execute 'bin/go build...' which doesn't work. 2024-11-06 11:20:42 I've gound setting 'GOROOT' to '/usr/lib/go' makes it work, but not really sure if this is the right thing to do. 2024-11-06 11:21:38 The MR as it stands currently (draft) is here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74745 2024-11-06 11:31:27 adhawkins: maybe not an expert either, but your fix seems unobtrusive, and if the result is that the tests run and pass I don't think there's anything wrong with it 2024-11-06 11:31:49 I'm checking 2024-11-06 11:32:11 Thanks durrendal. I wonder whether the issue actually lies in the way upstream is building these helpers. Wondering if I should report it there if there's a 'better' way? 2024-11-06 11:33:12 `go env GOROOT` in the check function reports the correct value 2024-11-06 11:34:09 PabloCorreaGomez[m]: sure, I would be amenable to that. The result would be functionally the same. All I care about is creating the directories during installation, before first run of the service. 2024-11-06 11:34:58 ikke So that suggests that the 'runtime.GOROOT()' in buildHookecho is doing something odd? 2024-11-06 11:37:04 are there C or C++ libraries to deal with apkv2? 2024-11-06 11:38:38 Ermine: there is libapk 2024-11-06 11:41:56 adhawkins: curious, if I run the tests with dlv, it seems to pass 2024-11-06 11:42:06 the value of binpath is correct 2024-11-06 11:42:14 (dlv -> delve, the go debugger) 2024-11-06 11:42:21 Oh ok. Was about to ask that :) 2024-11-06 11:44:08 adhawkins: maybe to do with the other environment variables we set 2024-11-06 11:44:11 let me test 2024-11-06 11:44:43 Thanks ikke, appreciate it. 2024-11-06 11:47:17 Nope, it still passes with those variables exported 2024-11-06 11:48:26 Hmm, even `go test -v .` in the directory passes 2024-11-06 11:50:09 Ah! 2024-11-06 11:50:14 -trimpath in GOFLAGS 2024-11-06 11:50:56 GOFLAGS=-trimpath go test -v . reproduces it 2024-11-06 11:53:59 so I suppose `GOFLAGS="${GOFLAGS/-trimpath/}" go test -v .` should make the tests pass 2024-11-06 13:49:06 Why is trimpath set in GOFLAGS then? 2024-11-06 14:58:19 because it removes buildinfo and makes it reproducible 2024-11-06 14:59:34 that test should be disabled or otherwise modified so it doesn't use GOROOT 2024-11-06 15:38:13 ikke: ok, thank you, will look at it 2024-11-06 15:41:07 in I guess Alpine's go package doesn't provide any means to see what files does .apk have? 2024-11-06 16:08:59 Ok pj, I've modified it to remove the trimpath flag during testing 2024-11-06 17:15:53 could we get this merged? the maintainer approved it :) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74673 2024-11-06 17:20:42 thanks ikke :D 2024-11-06 23:21:49 ooh new LXQt to work on when I get my 2 days off from work 2024-11-06 23:22:41 https://github.com/lxqt/lxqt-wayland-session <-- the most important part. Will be a new package. 2024-11-07 02:42:45 how can i use qt-creator built-in documention feature, pressing f1 doesn't take me to documentation. it seems by default qt-creator package doen't include documentaion. so its help tab is completely empty. i need this badly. or please give me instruction to how to build it myself qt-creator with documentaion feature turned on with musl/alpine. 2024-11-07 08:56:19 prosenjit: you need to have qt docs installed 2024-11-07 11:51:28 Any updates on that issue I had with the RTL8811CU/RTL8821CU ?? 2024-11-07 11:51:28 Would really like to know :) 2024-11-07 11:55:37 DaeDae[m]: https://tpaste.us/knyw 2024-11-07 11:56:09 So basically, you should open an issue on https://gitlab.alpinelinux.org/alpine/aports/-/issues 2024-11-07 11:56:58 # CONFIG_RTW88_8821CU is not set needs to be set to yes. 2024-11-07 11:56:58 And I'm not really familiar with gitlab. Is it similar to GitHub? 2024-11-07 11:57:04 quite similar 2024-11-07 11:57:11 Okay 2024-11-07 11:57:15 s/#// 2024-11-07 11:57:39 ncopa likes to have an issue as a record of the module being requested 2024-11-07 11:59:03 its mostly to not forget it. I like to do it together with kernel upgrades 2024-11-07 11:59:11 add tag "kernel" 2024-11-07 11:59:34 I'll take care of that, you need to be a member of the project to be able to do that 2024-11-07 11:59:49 (reporter or higher) 2024-11-07 12:14:52 i guess this is an openrc question, but it's about something that just annoyance. see: https://bpa.st/QCDF4 would it make sense to add /etc/conf.d/sysctl (or something) to pass sysctl(8) params, or alternatively patch /etc/init.d/sysctl so that quiet="-q -e"? i assume either way we'd want it upstream. 2024-11-07 18:45:04 I am getting emails regarding a package I maintain being out of data though it is a beta release: `ansible current: 10.5.0-r0 new: 11.0.0b2` 2024-11-07 18:46:50 would releasing the beta in edge be a solution? 2024-11-07 19:12:19 I would ignore those. That's what I currently do. 2024-11-07 19:12:27 Beta isn't a release it's a test. 2024-11-07 19:14:41 maybe open a draft MR and see if the tests are all green? 2024-11-07 19:21:18 smcavoy: https://gitlab.alpinelinux.org/alpine/infra/apkbrowser/-/issues/10 2024-11-07 19:21:53 bl4ckb0ne: this would certainly be nice to catch bugs earlier 2024-11-07 23:09:23 has anyone recently used alpine ipxe? The default ipxe.efi results in an error related to certs: https://ipxe.org/err/0216eb 2024-11-08 07:35:15 hi all, does anybody has github runner working in alpine? 2024-11-08 08:08:56 Yes, our CI runs on that 2024-11-08 08:13:49 ikke: Do we have a github CI runner? I thought it was only on gitlab 2024-11-08 08:14:26 Sorry, I read gitlab runner 2024-11-08 08:47:54 gitlab seems to be very busy, got some http 500 and git pull is slow 2024-11-08 09:05:36 i'm not sure if anyone will see it: i reopened MR !53556 but it won't show as updated in the MR list so i'm leaving this here before it gets lost :( 2024-11-08 09:08:40 err, sorting why "recently updated" helps 2024-11-08 09:30:41 do we already stop to use the comments in the apk head file? 2024-11-08 13:14:40 fabricionaweb: not yet definitely 2024-11-08 13:50:57 so that PR is missing it xD 2024-11-08 14:40:45 FYI an email to help@alpinelinux.org has bounced 2024-11-08 19:58:55 PureTryOut (matrix.org): Regarding the `/var` directories removal: When these directories are packages it is easier to use apk audit to detect which data belongs to removed packages (In that case the `var/lib/*` directory isn't owned by anything) and data that is probably still in use cause the package is still installed (In that case the `/var/lib/*` directory is owned by the package it belongs to). If you plan on removing more 2024-11-08 19:58:55 (empty) directories from `/var` could you create a discussion so people have the opportunity to find a solution that fits everyone? 2024-11-08 19:59:55 I stopped removing empty directories from /var 🤔 Just moving the files away now 2024-11-08 20:04:42 Ok 2024-11-08 20:08:54 Just out of curiosity, was there a benefit you saw from not creating these? I am wondering whenever or not apk should have an option to ignore specific files/directories from packages. 2024-11-08 20:36:30 [off-topic] sertonix[m]: since I can find you here :P please test execline's forx and forstdin, I made the changes you wanted, but implemented them in a different way 2024-11-08 20:37:38 Personally? Immutability, keeping the package manager confined to /usr (as much as possible anyway, I don't know how to do it with /etc yet) so that can be read-only and /var can be mounted later in boot, shared between different systems, etc. 2024-11-08 20:41:21 it's pretty illusory to think that a package manager will be entirely confined to /usr 2024-11-08 20:41:30 for package data, sure 2024-11-08 20:41:48 but programs need run-time settings and run-time places to write things 2024-11-08 20:41:59 so *some* stuff will be in /etc/ and /var, that's unavoidable 2024-11-08 20:42:12 you can't prepare all the sub-hierarchies of /var in advance 2024-11-08 20:43:25 potentially you could reserve /var/lib/$package so it's a special case 2024-11-08 20:43:25 ikke: please kick build-3-21-armhf builder hanging 3rd day 2024-11-08 20:44:06 and then the distro manages /var/empty and equivalent 2024-11-08 20:44:16 but then again sometimes you also need /run/$package 2024-11-08 20:44:38 (granted, the package manager should never do anything about that one) 2024-11-08 20:45:00 point being, be practical about this 2024-11-08 20:52:49 it may be handy if package manager creates /run/$package in the docker image use case 2024-11-08 20:59:44 skarnet: I think translating forx -P 0 to forx -P 1 is something that most people wouldn't expect. I suggest to ether error in that case or consider it to be the max value. Additionally I am not a fan of arbitrary limits (like maxpar <= 10000) but you seem to like them a lot. 2024-11-08 21:05:09 https://www.hyperbola.info/news/hyperbola-the-support-for-32bit-and-debian/ 2024-11-08 21:32:51 sertonix[m]: practicality. Spawning more than 10k processes in parallel isn't the gain you seem to think it is. :P 2024-11-08 21:34:41 also, "-P 0" naturally interprets as "no parallelism", which is the same as -P 1. Setting it to "maximum parallelism" is specialcasing, it requires more cognitive burden from the user. 2024-11-08 21:40:16 skarnet: Depends on the use case ;) When the processes are expected to idle most of the time many processes may not be a problem. Or processes 1 to 10000 need process 10001 to finish causing an unexpected deadlock. In my opinion it is more robust and future proof without the limit. 2024-11-08 21:53:20 samu, zlib and ctest considering 0 to be maximum/automatic parallelism so I am uncertain if it is a cognitive burden. But it is your decision in the end. 2024-11-08 22:00:02 in APKBUILD, for pkgrel, most of the suffixes seem to have a corallation to either vcs or prerelease type (alpha,beta,rc,pre), but the 'p' suffix does not seem so obvious to me. Any one know what the 'p' suffix for pkgrel is alluding to? 2024-11-08 22:01:20 pkgrel is unrelated to any of that 2024-11-08 22:02:21 you seem certain. have APKBUILD.5 open in another terminal, what i just described is in there 2024-11-08 22:02:56 oh, crap... right, pkgver 2024-11-08 22:03:00 sorry 2024-11-08 22:05:42 so, with s/pkgrel/pkgver/g applied to my botched question, any idea what the p suffix alludes to for pkgver? 2024-11-08 22:09:24 My guess is that it is short for "patch". For example when upstream has special releases just to fix things without changing the main version. For example openssh: https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/ 2024-11-08 22:10:57 ok, that makes more sense than anything i was coming up with, thanks 2024-11-08 22:11:55 It is also sometimes used if upstream has versions like 2024.10-1 which aren't valid apk versions so they are converted to 2024.10_p1 2024-11-08 22:13:00 cool, good stuff to be aware of 2024-11-09 01:10:36 Hi, just wanted to report that after an usual apk upgrade a bit ago (I think the kernel got updated) my machine is black during boot and the only way to shut it down is to ho ld the power button for many seconds. I won't stick around to look at answers but I'll come back later and read the log and all pointers are hugely appreciated. Thanks! 2024-11-09 01:11:29 what colour was it before the update? 2024-11-09 01:49:27 lol 2024-11-09 02:00:27 now that we all had a giggle at the phrasing: when during the boot process does your screen turn off, do you get any output before? 2024-11-09 02:03:29 the left 13 seconds after sending that 2024-11-09 02:24:00 woke left 2024-11-09 08:21:28 so if i add a new port to aports and there isn't anyone that contributed except me, who is also the maintainer, do i put the maintainer var and comment at the top, only one of those, or should there also be a "contributor" comment somewhere? 2024-11-09 08:21:59 i'm confused about the comments from fabricionaweb and ikke. from what i've seen only the "maintainer" var is needed? could be wrong 2024-11-09 08:28:46 Basically yes. We used to do the contributer comment but honestly it's unnecessary info as it's already in git. 2024-11-09 08:29:11 I'd only use the maintainer variable 2024-11-09 10:22:11 craftyguy[m]: It should work again 2024-11-09 10:42:53 is article on /usr merge published ? adding those comments earlier i made would be nice 2024-11-09 10:43:16 i have some more cooked up 2024-11-09 10:45:20 Not published yet 2024-11-09 10:48:54 adding a section there as why change was needed in AL from PmOs perspective would be nice 2024-11-09 10:53:26 also a section from Phantom/future FHS that's being prior implemented 2024-11-09 10:57:23 rootbld broken for anyone else? bwrap: Can't mount proc on /newroot/proc: Operation not permitted 2024-11-09 13:25:45 ikke: working here, will try apk update to see if anything breaks it 2024-11-09 13:31:29 nope. curious about permissions of /var/tmp, still have sticky bit set? 2024-11-09 13:34:40 but that error message does not look like file permissions but execution permission, so that is probably not the cause 2024-11-09 13:45:45 I tried pruning the supplimental groups for my user. only group that had any effect was abuild, but that stopped it at /var/cache/distfiles access 2024-11-09 15:35:30 Hello 2024-11-09 15:36:20 Does anyone know how how I can build gcc with `-m32` support under alpine? 2024-11-09 15:43:47 you need to teach it to build 32bit libgcc. And you'll be able to produce static binaries only, since musl doesn't support multilib 2024-11-09 15:50:17 It kinda does though? 2024-11-09 15:51:37 You just need a kernel with 32bit ABI and dynamic linker 2024-11-09 15:55:09 https://0x0.st/XDEB.txt 2024-11-09 15:55:34 kernel part is here, but dynamic linker is provided by musl... 2024-11-09 15:55:48 does 32bit zsh work? 2024-11-09 15:56:12 fyi /alpine32 is a chroot with x86 alpine. 32 libraries are symlinked to /usr/lib32 and /lib32 2024-11-09 15:56:23 yes they both work 2024-11-09 15:56:52 there's no way to teach gcc that -m32 means "i mounted a 32-bit chroot somewhere and symlinked stuff to /usr/lib32, make it work" 2024-11-09 15:57:11 for glibc, it supports actually installing those side by side, that's what multilib is 2024-11-09 15:57:33 musl doesn't have such a thing; you have separate-arch chroots 2024-11-09 15:57:48 if you use /alpine32/usr/bin/gcc it is the -m32 you want 2024-11-09 15:58:06 Eh? 2024-11-09 15:59:25 Let's say I don't have /alpine32 2024-11-09 15:59:44 The reason why I do is obvious, it's to be able to properly manage it with apk. 2024-11-09 16:00:10 But I very easily could just put actual libraries, not their symlinks at /usr/lib32 2024-11-09 16:00:25 and 32 binaries would dynamically link them 2024-11-09 16:01:33 It knows to lookup /usr/lin32 and /lib32 because I defined those paths in /etc/ld-musl-i386.path 2024-11-09 16:03:21 Either way 2024-11-09 16:03:56 what I want is to use /usr/bin/gcc to compile 32 bit binaries. Not the gcc from chroot 2024-11-09 16:42:41 Wow, that's fun 2024-11-09 16:43:28 Because alpine's GCC is stripped from any 32 bit support on x86_64 I can't even compile a version of GCC which doesn't have it stripped 2024-11-09 21:26:40 I am very confused, what forbidden magic causes this https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/vim/APKBUILD#L197 to only work when the pkgname is vim? 2024-11-09 21:27:30 simpler testcase in the last two commits here https://gitlab.alpinelinux.org/socksinspace/aports/-/commits/novim/ and log http://socks-in.space/pub/whattheheck.txt 2024-11-09 22:42:00 An Java 21 library is failing to load for me due to missing symbols and a rebuild doesn't seem to fix it. Error relocating /usr/lib/jvm/java-21-openjdk/lib/libjimage.so: JVM_LoadZipLibrary: symbol not found 2024-11-09 22:42:07 Does anyone know what's up with that? 2024-11-10 07:30:12 Hey, is there any way to have abuild build the apkbuilds and resolve dependencies in order? 2024-11-10 07:57:58 anjan: buildrepo from lua-aports can do that 2024-11-10 08:07:42 !74938 I'm not sure if nvim-plugin is suitable to port 2024-11-10 09:31:35 qaqland: I want to make sure you are aware that I'm not trying to be a jerk about my last comment. I'm interested to hear if there is a concensus about nvim plugins, or at least some more opinions. I actually appreciate your bringing it up, as it could save me time and effort. So, this is my roundabout way of thanking you. 2024-11-10 10:38:26 j_v: AFAIK there is no concensus about them, it is only my suggestion 2024-11-10 10:39:02 thanks for your work :) 2024-11-10 11:52:39 oh, i think i wrapped my brain around my issue with builddirs, abuild doesn't set the name of the top-level sources directory, the tarball does :D 2024-11-10 12:24:26 not possible to me to commit to another users forks right? 2024-11-10 13:57:49 should modloop=http://x.x.x.x/modloop-lts cause the network to be brought up? I am seeing modloop not downloaded, if I bring up the network I am able to download / mount.. 2024-11-10 15:29:40 Can anyone help? https://0x0.st/XD5y.c this program segfaults when compiled on x86 musl. Apparently it's a stack corruption. 2024-11-10 15:30:07 Why? It works just fine on a glibc system. It also runs fine on x86_64 musl. So what's wrong? 2024-11-10 15:31:03 got gdb output? 2024-11-10 15:31:40 Program received signal SIGSEGV, Segmentation fault. 2024-11-10 15:31:42 __stack_chk_fail () at src/env/__stack_chk_fail.c:26 2024-11-10 15:31:44 26 a_crash(); 2024-11-10 15:33:02 it runs here on x86 musl 2024-11-10 15:33:10 in alpine:edge 2024-11-10 15:33:19 huh 2024-11-10 15:33:42 verifying that it runs -correctly- becomes easier when i put %o in the printf 2024-11-10 15:33:48 # ./foo /etc/passwd 2024-11-10 15:33:50 100644 2024-11-10 15:34:03 note, this is inside docker on an amd64 machine, but: foo: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-i386.so.1, BuildID[sha1]=1e0df3650e1710d11603abf2965097058b0a6575, with debug_info, not stripped 2024-11-10 15:34:23 valgrind has no complaints 2024-11-10 15:34:29 I have an x86 chroot 2024-11-10 15:34:35 Running on x86_64 host 2024-11-10 15:34:38 ok, so similar setup 2024-11-10 15:34:54 what version of alpine? 2024-11-10 15:35:07 uh, should be edge iirc 2024-11-10 15:35:14 ok 2024-11-10 15:35:19 how do you build? 2024-11-10 15:35:34 gcc -m32 -g test.c 2024-11-10 15:35:51 works too 2024-11-10 15:36:07 (as does cc foo.c -o foo which 'make foo' without a Makefile gave me) 2024-11-10 15:36:13 how..? Can you share built binary? 2024-11-10 15:36:15 sure 2024-11-10 15:37:42 http://lorentz.7bits.nl:8000/ 2024-11-10 15:37:49 a.out is from 'gcc -m32 ..' 2024-11-10 15:38:40 Yours works 2024-11-10 15:38:47 Is my gcc bad lmao? 2024-11-10 15:38:57 i have no idea 2024-11-10 15:39:17 Yeahh, well thanks anyway, that's a good enough clue 2024-11-10 15:39:23 alright 2024-11-10 15:39:24 good luck 2024-11-10 15:39:27 thx 2024-11-10 15:39:38 try 'file' and 'ldd' to look for obvious differences 2024-11-10 15:44:13 (i turned the webserver off now) 2024-11-10 15:44:15 ja 2024-11-10 15:44:21 Ok I found the problem 2024-11-10 15:44:55 It works when I call gcc while chrooted. Calling it via $chroot/usr/bin/gcc was the problem 2024-11-10 15:45:14 oh fun 2024-11-10 15:50:15 qaqland: i've decided to go ahead with the nvim plugin aports i have started. it's not that many, are related in some way, and seem to be fairly stable. 2024-11-10 15:52:10 qaqland: i will give some serious thought about your point before starting any more new nvim plugin ports. though i will probably be working on the existing nvim aports 2024-11-10 19:43:21 ACTION sent a code block: https://matrix.org/oftc/media/v1/media/download/AVeSJzvqHmfkBzBnaSYdL1MkavSxdlevp6KOXDGRg-LnwqK7T-nLeZD2LxFm0Y82Z3vZi1jYb36VNZ6C9dNj_HhCeTX7M2qwAG1hdHJpeC5vcmcvRWNnY3pFcGJtUGxwbW5IUUNaTUlSUHJn 2024-11-10 19:43:34 Can someone explain why knewstuff-dev is pulling in qqc2-desktop-style in that log? ^ 2024-11-10 19:44:08 As far as I can see there is no dependency on it whatsoever so I can't explain why it's there. It also pulls in the wrong version (6.8.0 rather than a 9999_git variant) 2024-11-10 19:52:41 it has install_if=kirigami 2024-11-10 19:56:01 Ah, indeed it has. And the 9999_git one doesn't. Ugh, I'd love it if apk would tell me this in apk info -r... 2024-11-10 22:08:42 ptrc: can you please take a look at: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65322 2024-11-10 22:08:47 I fixed the ci issues 2024-11-11 01:18:59 https://rubenerd.com/a-bsd-pserson-trying-alpine-linux/ 2024-11-11 03:37:19 omni: thanks for catch my mistake on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74939 2024-11-11 03:47:03 ikke: how do I use buildrepo to do that? 2024-11-11 03:47:37 like I want to build ocaml-rresult in my testing repo and I want buildrepo to build the dependancies for it (which are not compiled on stable) 2024-11-11 03:57:41 j_v: np 2024-11-11 04:09:21 mps is not around at the moment? I was wondering if we can enable CONFIG_VIDEO_INTEL_IPU6 in linux-edge to enable the newer cameras? I got two laptops with them and since 6.10 the module is now in the mainline 2024-11-11 04:17:02 Added https://gitlab.alpinelinux.org/alpine/aports/-/issues/16608 for tracking 2024-11-11 05:45:38 telmich_: mps is no longer interested in maintaining linux-edge (the is an MR for that) 2024-11-11 07:58:16 Can anybody else not get abuild to build & pass it's tests (on edge) or do i just have a strong case of "brain is tired"? 2024-11-11 08:46:56 something is wrong tiwh the py3-virtualenv. seems like py3-hatchling has a missing dep or something 2024-11-11 10:28:05 upstream hatchling v1.26.1 bumped the dep on packaging to >=24.2 (aports currently has v24.1): https://github.com/pypa/hatch/pull/1788 2024-11-11 10:38:05 and packaging v24.2 added the packaging.licenses module 2024-11-11 10:41:49 !74972 2024-11-11 16:59:02 does apk index provide any package ordering guarantees in APKINDEX.gz? 2024-11-11 17:59:43 Ermine: no. And that format is being deprecated in future. 2024-11-11 19:29:49 I don't care about apkv3 for the time being 2024-11-11 22:23:27 fabled: where can I read more about it? 2024-11-11 22:44:48 aleksi_: https://gitlab.alpinelinux.org/alpine/apk-tools/-/tree/master 2024-11-11 22:46:05 is it expected that installing e2fsprogs-extra results in /usr/bin/chattr being the e2fsprogs version and /bin/chattr being busybox? craftyguy and I are a bit confused 2024-11-11 22:46:20 my understanding was that tools overriding busybox applets would replace all the versions 2024-11-11 22:46:42 in which case I'd guess this is a side-effect of the /usr merges changes to the e2fsprogs package? 2024-11-11 22:47:07 the apkbuild for e2fsprogs{-extra} doesn't override the busybox symlink in /bin/chattr, so whichever chattr you get depends on ordering in PATH? 2024-11-11 23:37:46 been that way for a long time for a bunch of those tools, yeah 2024-11-11 23:39:19 is this a packaging bug? like, ideally it should replace the bb symlink with one to the 'real' version of the app binary? 2024-11-12 06:12:09 craftyguy[m]: yes, as far as I know, the bb symlinks should be located at the location the actual binary usually is 2024-11-12 08:05:06 I just checked https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests and see that a lot of version bumps are there and was wondering if I can help out somewhere to move things forward, ikke & ncopa ? 2024-11-12 08:06:52 12 in the last hour 2024-11-12 08:16:47 A lot of those are me catching up, I apologize for the load 2024-11-12 08:23:45 Version bump MRs are quickly handled 2024-11-12 08:23:54 (by maintainers) 2024-11-12 08:54:02 telmich: right now the 3.21 release is priority, so anything that helps us fix the build failures would be good https://build.alpinelinux.org/ 2024-11-12 08:54:16 I also think that helping MRs that are m 2024-11-12 08:54:26 marked "draft" 2024-11-12 08:54:55 ncopa: Oh, nice! 2024-11-12 08:55:15 help the draft MRs to either close or fix whatever the issue 2024-11-12 08:55:41 telmich: and thank you for helping! it is appreciated 2024-11-12 08:56:20 Looking for those now and looking forward to 3.21 2024-11-12 10:00:36 telmich: list of build issues with 3.21: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16361 2024-11-12 10:13:52 omg 2024-11-12 10:14:16 yesterday I noticed this with imv: Assertion failed: success (/home/buildozer/aports/community/libheif/src/libheif-1.19.2/libheif/bitstream.cc: BitstreamRange: 166) 2024-11-12 10:14:42 hmm.. it seems that happens with some unexpected file 2024-11-12 14:17:56 Anyone else use abump? Is there a GitHub Action to run it on releases? 2024-11-12 14:33:52 (1) i do (2) i don't know but you have my interest 2024-11-12 14:34:58 it's a script, you can run it as script 2024-11-12 14:35:58 i think it's mostly designed to use interactively. Especially opening MRs, rebasing patches, verifying changelogs,... 2024-11-12 14:36:42 agreed 2024-11-12 22:00:21 https://git.alpinelinux.org/aports/log/ 502 2024-11-12 22:00:49 interesting is https://git.alpinelinux.org/aports works, how ? 2024-11-12 22:02:11 'ghost in a url' 2024-11-12 22:03:15 uhmm... likely not ok nginx conf routes 2024-11-12 22:04:53 seems fixed now 2024-11-13 03:05:57 Hello, I'm struggling with strange feedback... abuild and stuff on edge... the edges the limits... 2024-11-13 03:08:39 It says /home/devel/packages/main doesn't exist... while it's there with even 777 credential full path (absolute) from root, ROOT 2024-11-13 03:08:53 wth did I miss... 2024-11-13 03:09:00 please halp me 2024-11-13 03:10:22 wannu hack, but stuff doesn't want me to hack in :D 2024-11-13 03:10:49 hOwever, HOWEVER 2024-11-13 03:11:00 pacges building :D 2024-11-13 03:11:07 packages building :D 2024-11-13 03:11:14 strangely 2024-11-13 03:13:37 please HALP, the fith element. 2024-11-13 03:14:32 should I roll down to stable? 2024-11-13 03:14:57 or should I hack in directly into abuild :D 2024-11-13 03:15:20 gimme direction 2024-11-13 03:15:58 I'm flipping on myslef trying to make sens in the game of life 2024-11-13 03:16:22 let's make a round up flipping together 2024-11-13 03:16:40 over and over 2024-11-13 03:17:39 I'm flipping alone... sounds vanishing :D 2024-11-13 03:17:48 OVER TIME 2024-11-13 03:17:58 TIMELINE 2024-11-13 03:18:08 the smell 2024-11-13 03:18:13 of time 2024-11-13 03:18:28 damn no smell... it's a feel 2024-11-13 03:19:00 I still need help 2024-11-13 03:19:31 over an existing directory that doesn't exist in the coding 2024-11-13 03:19:55 exceptional 2024-11-13 03:20:25 that's really the best ever feedback I got lately 2024-11-13 03:20:59 I'm just imprgnating myself after an long pause (again) 2024-11-13 03:21:12 spongy 2024-11-13 03:21:21 absorb 2024-11-13 03:30:25 meh, gotta scrap it 2024-11-13 03:31:11 c U, kIss. thx really appealing. 2024-11-13 03:54:52 kek wtf 2024-11-13 06:59:25 If I want to add some build options to VTK for a new aport I want to add, who reviews? There isn't an assigned maintainer 2024-11-13 07:01:46 if you depend on it, you could take over maintainership 2024-11-13 07:03:43 Not sure I am ready for community yet, I'm barely keeping up with testing, which is where the new aport is headed 2024-11-13 07:03:51 it is for f3d and exhibit, 3d model viewing tools 2024-11-13 07:04:41 Saijin_Naib[m]: any developer can review, but new aports are low priority at the moment 2024-11-13 07:05:41 ikkemakes sense, didn't know if the contributors needed to be looped in in the absence of a maintainer 2024-11-13 09:05:05 So I have a package that requires bootstrapping. I have it bootstrapped just fine but now when using it non-bootstrapped it requires a dep that while bootstrapping is provided by a bootstrapping version. Since depends are also installed while building the 2 deps are now conflicting with each other. How do you usually resolve these things? 2024-11-13 10:52:58 RIP dotnet6 2024-11-13 11:14:57 can we bury dotnet6? \o/ 2024-11-13 11:27:31 mate-desktop build failure is a bit worrying 2024-11-13 11:28:00 the proper fix is to fix the startup-notification, but it will break ABI 2024-11-13 11:42:06 oh, I have reported it in the past of https://gitlab.freedesktop.org/xdg/startup-notification/-/issues/6 2024-11-13 14:56:24 too bad dotnet6 died apparently. 2024-11-13 14:56:27 \o/ 2024-11-13 18:04:52 Im the only one with aports on net6 2024-11-13 18:23:37 So are there any instructions somewhere on how to write aports that need bootstrapping? 2024-11-13 18:23:53 As in, how do you make things depend on one thing while bootstrapping, and another while bootstrapped and ready to use? 2024-11-13 18:34:47 fabricionaweb: there is also testing/openra 2024-11-13 18:35:07 that I wouldn't mind having in community/ but first https://github.com/OpenRA/OpenRA/pull/21577 or somethine 2024-11-13 19:55:41 PureTryOut (matrix.org): don't know of a guide, but looking at binutils at the time I learned that during bootstraping there's a `BOOTSTRAP` variable 2024-11-13 19:56:02 You can use that to dynamically adjust makedepends, build options and the like 2024-11-13 19:56:16 Do you know of an example? 2024-11-13 19:56:26 Yes, binutils :P 2024-11-13 19:56:37 Ah ofc 😛 2024-11-13 19:56:46 And how do you invoke the bootstrap build? 2024-11-13 19:57:29 export BOOTSTRAP=1 I guess? 2024-11-13 19:57:53 ah just an env variable? 2024-11-13 19:58:18 man abuild seems to have some explanation of it 2024-11-13 19:58:58 > This flag only has an effect on a few select packages 2024-11-13 19:59:19 Exactly, the packages that test for it :P 2024-11-13 19:59:31 Won't change anything when building gnome-control-center 2024-11-13 19:59:35 Oh derp yeah ok haha 2024-11-13 19:59:40 It will change something when building binutils 2024-11-13 21:14:56 Hi, does anyone what is going on with !72313 or jirutka? Bit frustrating that first the stalebot comes because the PR hasn't been reviewed and now a rebased without any further comments. 2024-11-13 21:25:12 famfo: The maintainer for that package is quite busy, I suspect he forget to follow through after rebasing 2024-11-13 21:26:29 and it looks like more than a simple minor bump, so i can see how a bit of time to review can be hard to find for somebody 2024-11-13 21:26:43 (that also means it looks like great work by famfo!) 2024-11-13 21:32:39 fair enough 2024-11-13 21:33:57 i also understand your frustration ;0 2024-11-13 21:33:59 :) 2024-11-13 21:38:09 yea, anyways, thanks for also taking a quick look at it :) 2024-11-13 21:38:20 if i used atuin, i'd post a review 2024-11-13 22:15:31 PureTryOut: i don't think the bootstrap variable has any special magic in it, just passing an environment variable, gets used for gcc and musl too, where more an more complete versions get built with each invocation of abuild, so more of a system bootstrap/cross compile thing, "regular" gcc itself also is built in stages internally, but that happens on the makefile level, not in 2024-11-13 22:15:33 the packaging 2024-11-13 22:20:02 ptrc: sorry for delay in replying to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74614#note_454966 2024-11-13 22:41:52 ncopa: could you have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75080 tomorrow? 2024-11-13 22:43:17 Or any other day this week for what matters 2024-11-13 22:43:47 Initial testing of the usr-merge Gentoo script seems to also trigger on that one :) 2024-11-13 23:00:40 when i build abuild by doing `APKBUILD=~/code/aports/main/abuild/APKBUILD abuild -r` it fails the majority of tests, but when i cd into the folder and then just do `abuild -r` all but one test pass??? what the heck 2024-11-14 09:00:03 Hi all. Been years since I was here. 2024-11-14 09:00:03 Not exactly devel but related to GitLab. Who would be best contact if it comes to managing GL, in particular user accounts? 2024-11-14 09:13:37 Me 2024-11-14 09:54:30 we need get qt6-qtwebengine fixed 2024-11-14 11:34:24 yes. I haven't had the capacity to properly look into it, but I think there can be hints on how to solve it in the chromium aport and other chromium based aports 2024-11-14 11:35:55 somewhere, a dependency got updated that broke it and I'm not exactly sure what 2024-11-14 11:36:43 possibly llvm/clang 18->19, but I don't think it's possible to build with 18, due to some other dependencies 2024-11-14 11:43:55 Does regular Chromium (the aport, outside of Qt) build at this point? 2024-11-14 11:45:26 It did 1 week ago 2024-11-14 11:45:45 yes, and I think most/all of the other chromium based aports 2024-11-14 11:46:23 Ok, that's good I guess 2024-11-14 11:46:34 i think it is the loongarch patches that makes it fail 2024-11-14 11:46:44 im working on it now 2024-11-14 11:46:53 <3 2024-11-14 11:48:04 whats up with the checksum error for libfilezilla 2024-11-14 11:48:07 perhaps there aren't that many chromium based aports, but electron, right? 2024-11-14 11:48:26 we have way too many chromium forks 2024-11-14 11:49:10 webkitgtk* chromium* electron* flutter* qt6 webkit engine qt5 webkitengine and probably more 2024-11-14 11:49:20 everybody forks chromium nowadays 2024-11-14 11:50:17 I agree, it's annoying. Sadly at least Qt can't just embed the system Chromium. It's way too version specific 2024-11-14 11:50:27 And I guess that's with every fork, Chromium changes too much between releases 2024-11-14 11:50:43 Maybe people should reconsider building on top of it then :P 2024-11-14 11:51:04 Definitely, but that's not up to you or me lol 2024-11-14 11:51:13 I' 2024-11-14 11:51:16 I'm painfully aware 2024-11-14 11:51:23 I don't think there is anything better atm if you want to embed browser stuff. Gecko is even more of a pain I hear. 2024-11-14 11:51:34 Maybe Ladybird or Servo gets useful for that in the future 2024-11-14 11:53:59 chromium also vendors some stuff, that we already have packaged at up-to-date versions, that often is what needs to be patched to build 2024-11-14 11:54:29 not sure unvendoring would make anything easier, though 2024-11-14 11:57:21 there are various aports that uses distfiles.a.o as srouce 2024-11-14 11:57:23 source* 2024-11-14 11:57:25 not good 2024-11-14 11:57:41 distfiles is not upstream sources, it is a cache of upstream sources 2024-11-14 12:00:58 acme-client. someon should email the author that the README points to a 404 URL 2024-11-14 12:01:35 only six aports, right? but sure 2024-11-14 12:02:18 i fixed two earlier today, copied the missing sources to ev.a.o 2024-11-14 12:02:23 dev.a.o/archive 2024-11-14 12:04:43 font-parisienne I think is because the upstream file will differ unsignificantly every time you download it, so unstable checksum, typical uncaring google 2024-11-14 12:08:42 I'll look at openzwave 2024-11-14 12:17:17 thank you 2024-11-14 12:23:35 Does anybody have pointers on how to make initramfs echo output to serial console? 2024-11-14 12:24:05 I have removed quiet, and added console=/dev/ttyS0 to /boot/extlinux.conf 2024-11-14 12:24:29 Still initramfs does not print to the console :( 2024-11-14 12:25:22 I do have ebegin eend things in dmesg 2024-11-14 12:26:03 But no echo or other message gets printed, even when debug_init does set +x 2024-11-14 12:26:29 s/+x/-x/1 2024-11-14 12:58:42 isnt it console=ttyS0 ? 2024-11-14 13:06:47 why was !75163 auto-assigned to PureTryOut? the aport has no maintainer 2024-11-14 13:43:55 ncopa: that worked, thanks a lot! 2024-11-14 13:47:56 py3-ansible-compat has checksum errors 2024-11-14 14:21:39 ncopa, oh i bet it is yes, without /dev/ 2024-11-14 14:27:32 Habbie: PabloCorreaGomez[m] already confirmed 2024-11-14 14:27:41 oops, i see 2024-11-14 16:58:52 sertonix: I spent some time creating a test suite to hopefully help validate whatever thing we use in Alpine for converting installs to usr merge, I would appreciate your thoughts on it. Currently it's just using a modified version of the script Gentoo used for doing usr merge, but it should be able to test any utility we come up with. https://gitlab.postmarketos.org/craftyguy/merge-usr/-/merge_requests/1/diffs 2024-11-14 16:59:16 the output is here: https://gitlab.postmarketos.org/craftyguy/merge-usr/-/jobs/1285947 (that one failure it found should be fixed by https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75080) 2024-11-14 16:59:48 I definitely need help creating more test cases 😅 2024-11-14 17:00:33 ncopa: FYI since I think you and Pablo talked about this recently ^^ 2024-11-14 17:03:55 (as for the location, I just threw it in the pmos gitlab because it was easiest and I don't feel bad about (ab)using our runners for this early stuff :P) 2024-11-14 17:06:21 mick_ibm: do you think you can help find out whats wrong with webkit builds? https://build.alpinelinux.org/buildlogs/build-3-21-ppc64le/community/webkit2gtk-4.1/webkit2gtk-4.1-2.44.4-r0.log 2024-11-14 17:06:39 'musttail' attribute for this call is impossible because external calls can not be tail called on PPC 2024-11-14 17:24:23 there are newer versions of wegbit available https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72149 2024-11-14 17:49:01 craftyguy[m]: trying to get the 3.21 release out first 2024-11-14 17:49:35 anything getting in the way of getting 3.21 out the door is at risk to be deleted 2024-11-14 17:50:55 ncopa: ya no problem, I totally understand and it's fine waiting for the coreutils thing (I was just pointing out how the test suite I made already found a real usr merge bug :P) 2024-11-14 19:10:29 oh no, chromium updates 2024-11-14 19:24:32 mick_ibm: i have a fix for webkit2gtk-4.1 2024-11-14 19:24:45 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75208 2024-11-14 21:19:14 Wut, the loongarch patches broken all arches for qt6-qtwebengine...? Ugh 2024-11-14 21:22:05 yes, so sometimes it's better to apply architecture specific patches only for that architecture, I often do that in a case statement and suffix the patches _patch instead of .patch 2024-11-14 21:33:01 ncopa: im tryin to build that patch on my ppc64le alpine box now. im seeing some weird builddeps errors so might take a little more time than expected 2024-11-15 00:53:12 https://github.com/lxqt/lxqt-wayland-session/blob/master/LICENSE ugh license galore... 2024-11-15 00:53:54 I'm assuming something along the lines of: license="LGPL-2.1-only, MIT, BSD-3-Clause, GPL-3.0-only, GPL-2.0-only, CC-BY-SA-4.0" 2024-11-15 01:30:47 oh, is it because I have linux-edge-dev installed that I get "rm: cannot remove '/boot/initramfs-edge': No such file or directory" twice when upgrading linux-lts? 2024-11-15 03:43:09 I wonder if this is still valid now on 19.1.x https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61854/diffs#605cc08a2c82f6cdf4167d0ca3a406c85c1cb623_45_48 2024-11-15 03:43:26 algitbot: no 2024-11-15 06:17:55 poor algitbot trying its best 2024-11-15 06:44:48 JOIN NEW SAUCE METHODS... (full message at ) 2024-11-15 10:52:44 in !72669 it built for loongarch64 on the third attempt and on x86 on the sixth, but CI builders often OOM kill the qtwebengine builds where the package builders don't 2024-11-15 10:53:23 I would like it in, but it hasn't completed on armv7 yet and I am not sure when I'll be around again, if it would fail on the package builders 2024-11-15 11:43:29 gitlab 🛏️ 2024-11-15 11:44:53 ? 2024-11-15 11:45:57 works on my side 2024-11-15 11:47:07 yeah, for me as well 2024-11-15 11:49:23 500: We're sorry, something went wrong on our end 2024-11-15 11:49:25 ugh 2024-11-15 11:50:40 For what page / requesT? 2024-11-15 11:51:05 new mr 2024-11-15 11:51:09 worked now 2024-11-15 11:53:59 it can happen if your fork is quite behind in commits 2024-11-15 11:54:35 usually keeping master in sync with alpine/aports prevents that 2024-11-15 12:10:43 It was updated i think but i will rebase to confirm 2024-11-15 12:10:45 Thanks 2024-11-15 12:28:49 famfo: maybe more architectures could enable in !72313 2024-11-15 21:59:13 I may have finally "fixed" the 32 bit arm bootstrap, i still don't like it and will have to test the result actually works, but at least it builds start to finish, if it works that should also fix SuperH, which i'll be happy about, and m68k, which apparently someone tried to make work last year 2024-11-15 23:27:44 qaqland: maybe, currently don't have the motivation to test 2024-11-16 01:49:21 that's ok :) 2024-11-16 05:56:41 Can someone please merge this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69597 2024-11-16 12:22:59 why does installing/uninstalling linux-lts-dev trigger mkinitfs? 2024-11-16 12:36:24 because it puts something in the trigger folder 2024-11-16 13:31:00 can someone merge phosh 0.43? !75233 2024-11-16 17:02:19 has the user @goshhhy aka linear aka linear-cannon been seen since they attempted an m68k port around a year ago? 2024-11-16 17:02:43 socksinspace: that name does not ring a bell, so I suppose not 2024-11-16 17:04:24 ok, maybe they will react to my ping on the gitlab, maybe not :) 2024-11-16 18:22:49 the paths /usr/lua5.{2-4}/{include,lib} seem wrong to me. i wonder if they are really necessary. lua5.1 has nothing like that. 2024-11-16 18:24:23 where else would they be 2024-11-16 18:25:45 just /usr/{include,lib}/lua5.{2-4}, seems more expected. 2024-11-16 18:27:29 it's functionally identical for things that use pkgconf 2024-11-16 18:27:35 and cmake finds either too i think 2024-11-16 18:27:50 though yeah, makes more sense that way 2024-11-16 18:30:52 ok, it's not a huge deal, and not worth me getting in a twist about. just caught my attention when i did a 'apk info -L lua5.2-dev' to see the headers it installs 2024-11-17 01:24:24 hm.... qt6 6.8.0 seems to break LXQt via the layer-shell-qt package. 2024-11-17 01:30:48 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16617 2024-11-17 01:36:33 it's using private qt api, it just needs to be rebuilt 2024-11-17 01:37:33 just raising the pkgrel should do the trick? 2024-11-17 01:38:18 probably, though i don't know alpine's protocols 2024-11-17 01:50:27 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75340 2024-11-17 01:50:52 And now the waiting begins \o/ 2024-11-17 03:39:29 how do i set alpine bootup not to block on dhcp/wifi? 2024-11-17 04:33:31 dalias: someone did a write up about doing what you are looking for. i'm trying to jog my memory. i think ptrc had a post about it. 2024-11-17 04:33:57 ah, found it... https://ptrcnull.me/posts/openrc-async-services/ 2024-11-17 04:35:10 probably a better solution than rc_parallel for many people. :p 2024-11-17 04:36:58 agreed 2024-11-17 21:50:56 reminder: if you have something noteworty for the release notes => https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.21.0 2024-11-18 01:30:20 this MR is ready to merge. Can someone take a look? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69597 2024-11-18 05:57:09 Linux 6.12 released: https://lwn.net/Articles/997958/ 2024-11-18 08:14:50 i wonder if we dare upgrade linux-lts to 6.12? 2024-11-18 08:15:00 would be great to shipe 3.21 with linux 6.12 2024-11-18 08:36:23 That'd be great imo 2024-11-18 08:47:37 is zfs compatible with it yet? 2024-11-18 08:49:14 2.3.0 might be but it's not out yet 2024-11-18 08:53:56 i see some 6.12 compat commits but nothing is advertised as supporting it yet because it wasn't released until now 2024-11-18 08:57:44 then it has to be called mls(mainline) and not lts ;) 2024-11-18 09:23:04 hmmm.. "64-Bit Arm kernels can now run as a guest on protected KVM systems", in 6.12 2024-11-18 09:27:19 if going there, maybe enable "Tomoyo" module for devs wanting to tinker 2024-11-18 09:56:32 it could likely give mobile devs point to celebrate 2024-11-18 10:29:45 ok zfs is a problem for 6.12 kernel 2024-11-18 10:30:25 nothing ever perfectly lines up 2024-11-18 10:30:26 sadness 2024-11-18 11:32:01 all the more happiness when it does (: 2024-11-18 14:55:16 yes, I've tried adding zfs-openpax, doesn't seem to work with zfs 2.3.0-rc3 either 2024-11-18 14:58:54 there's 6.12 patches in https://github.com/openzfs/zfs/pull/16720 2024-11-18 14:58:56 seems like our building infra is not able to keep up 2024-11-18 14:59:18 and the 3.21 builds is not able to complete 2024-11-18 14:59:31 new merge requests comes in faster than the infra is able to build 2024-11-18 14:59:53 we need to get the 3.21 builds done this week 2024-11-18 15:00:24 i think I will just cancel anything that gets in the way for that 2024-11-18 15:02:49 q66: yes, but it's a rathe large patchset and I would rather see it in an upstream release, but I could try it in my MR (when I get time) and see if it at least builds 2024-11-18 15:03:28 the 6.12 patches are clearly marked, there is about 5 of them and they are all small 2024-11-18 15:03:41 you can just pick them on top of 2.2.6 2024-11-18 15:03:58 all the kernel support patches are always marked 2024-11-18 15:08:16 q66: thanks! 2024-11-18 15:11:22 q66: that patch is huge 2024-11-18 15:39:16 ncopa: the 5 6.12 patches are tiny 2024-11-18 15:39:19 mostly buildsystem stuff 2024-11-18 15:54:09 ncopa: isn't 6.12 mainline, not longterm? 2024-11-18 15:54:45 it'll be longterm 2024-11-18 15:56:33 currently building it to test the zfs patches 2024-11-18 15:57:31 oh ok 2024-11-18 15:59:55 fabled: is the list of issues that need resolving for APKv3 in https://gitlab.alpinelinux.org/alpine/apk-tools/-/milestones/1#tab-issues accurate? 2024-11-18 16:00:34 I'm not sure if with my skill level I may annoy more than help 2024-11-18 16:00:46 But given that APKv3 is right now a requirement for the /usr merge 2024-11-18 16:00:56 I'd be very interested in help you move it forward if that's possible 2024-11-18 16:00:58 why would it be a requirement 2024-11-18 16:01:33 chimera had usrmerge from the beginning and we used apk2 for about a year 2024-11-18 16:02:16 its not a list written in the stone written. but i'm trying to get the release still this year. i also have already mostly done commit that should resolve#10769, #10787 and #10816 2024-11-18 16:02:55 q66: We need to move the library location, and I don't feel very comfortable doing it while APK keeps writing to /lib 2024-11-18 16:03:17 For new installs, sure 2024-11-18 16:03:19 if symlink lib -> usr/lib, the write goes to right place anyways 2024-11-18 16:03:37 yeah if anything it should matter less with usrmerge 2024-11-18 16:03:40 hmm BOOTSTRAP doesn't seem to be available inside build functions 🤔 2024-11-18 16:06:59 APKv2 DB still holds the lock under /lib/apk/db, means trying to move the lock while holding it 2024-11-18 16:07:30 If you think that and everything related is sane, then maybe 2024-11-18 16:07:37 But feels like an unnecessary risk 2024-11-18 17:39:38 q66: is it just those five 6.12 patches at the end of that PR? do they exist anywhere outside of that patchset? 2024-11-18 18:23:40 I wonder how many aports there are in need of a rebuild after the Qt6 6.8.0 upgrade and if there is an easy way to find out 2024-11-18 18:25:46 on void we separate out the private headers into their own devel packages so anything that uses private api is known 2024-11-18 18:27:39 clever 2024-11-18 18:28:17 once that's done, you have to rebuild everything and fix up the makedeps 2024-11-18 18:29:19 yes, so probably not something to do this close to release 2024-11-18 18:29:39 but it's a good idea! 2024-11-18 18:32:41 well, you only have to rebuild everything locally to find dep changes. it'll be a smaller number that need to be rebuilt on the builders 2024-11-18 18:33:58 I currently don't have a local system able to rebuild everything 2024-11-18 18:35:31 and I have not myself run into any issues after the upgrade, but I only use a small subset of the dependants 2024-11-18 18:36:19 but I've seen issues mentioned here and in the issue tracker since the upgrade 2024-11-18 18:37:19 and I assume the 3.21 builders have processed a lot of the dependants beore the Qt6 6.8.0 upgrade 2024-11-18 18:42:15 omni: i don't think so, but it's just those 5 yeah 2024-11-18 18:42:24 i looked over the others and it's just various fixes and so on 2024-11-18 18:44:34 q66: I just quickly tried to apply them on zfs 2.2.6, some failed and I haven't looked more into it now 2024-11-18 18:45:14 but I'm assuming they apply cleanly on top of those other changes in the patchset 2024-11-18 18:45:25 i'll finish building the kernel and look at it 2024-11-18 18:45:43 <3 2024-11-18 18:46:50 what would be super nice would be a zfs 2.2.7 release, or 2.3.0 even, with those changes any day this week :B 2024-11-18 19:17:10 abby: I opened #16624 to not forget about it, didn't know if you wanted to be mentioned or not but please chime in if you have anything to add 2024-11-18 19:18:21 feel free to ping me on irc if you have questions 2024-11-18 19:18:53 i didn't come up with the scheme but if there are questions i could maybe pass them on 2024-11-18 19:19:04 sure! 2024-11-18 19:58:53 omni: https://gist.github.com/q66/4b2d817dd640e4c92a7e69a16450e9f5 2024-11-18 20:00:20 https://github.com/chimera-linux/cports/pull/3190 here you can take patches from it if you like 2024-11-18 20:01:19 <3 2024-11-18 20:01:20 only minor adjustments needed 2024-11-18 20:01:26 in the patches compared to what's in the batch 2024-11-18 20:01:45 mostly some fuzz + one file got refactored a bit 2024-11-18 21:15:36 thank you q66! 2024-11-18 21:15:54 im having some weird error though 2024-11-18 21:16:14 make -C /usr/src/linux-headers-6.12.0-0-lts \ 2024-11-18 21:16:14 make[3]: Entering directory '/usr/src/linux-headers-6.12.0-0-lts' 2024-11-18 21:16:14 M="$PWD" CONFIG_ZFS=m modules 2024-11-18 21:16:14 make[5]: *** No rule to make target '/home/ncopa/aports/main/zfs-lts/src/zfs-2.2.6/6.12.0-0-lts/module/os/linux/spl/spl-atomic.o', needed by '/home/ncopa/aports/main/zfs-lts/src/zfs-2.2.6/6.12.0-0-lts/module/spl.o'. Stop. 2024-11-18 21:16:14 \ 2024-11-18 21:17:44 on what arch 2024-11-18 21:17:49 the patches don't touch that at all 2024-11-18 21:17:52 x86_64 2024-11-18 21:17:58 hm that builds fine for me 2024-11-18 21:18:00 yea, i dont think its the patches 2024-11-18 21:18:00 i haven't checked others 2024-11-18 21:18:07 happened without hte patches as well 2024-11-18 21:18:22 i build out-of-tree 2024-11-18 21:18:36 hm i don't think you are supposed to 2024-11-18 21:18:43 in a subdir i do: ../configure ... 2024-11-18 21:18:49 right, it's probably that 2024-11-18 21:20:03 it did work with the 6.6.y kernel though 2024-11-18 21:20:28 probably breaks specifically because of some compat bit added inbetween 2024-11-18 21:20:35 i do it that way because i have two different kernel configs, one for linux-lts and one for linux-virt 2024-11-18 21:20:58 yeah, building it in-tree works 2024-11-18 21:21:07 anyway probably breaks similarly with 6.11 at least 2024-11-18 21:21:10 i'll have to copy the source tree 2024-11-18 21:21:24 yeah in my case i have a separate template for each kernel so 2024-11-18 21:21:52 and the module is built through ckms 2024-11-18 23:15:16 ncopa: why was webkit2gtk removed? we have some stuff that still needs it 2024-11-18 23:15:29 e.g. gnucash, elementary-photos-publishing and cinny 2024-11-18 23:21:26 hey, friendly reminder again to merge !75233? :p 2024-11-18 23:54:14 fossdd[m]: done ^^ 2024-11-18 23:54:40 wow tyvm 2024-11-19 00:39:26 fossdd[m]: failing to fetch https://sources.phosh.mobi/releases/phoc/phoc-0.43.0.tar.xz due to certificate errors 2024-11-19 00:40:50 Not valid after: Nov 17 20:02:22 2024 GMT 2024-11-19 00:58:57 oof 2024-11-19 02:20:32 rehosted on dev.a.o, hopefully temporarily 2024-11-19 02:29:17 oh, I just !75438 2024-11-19 02:30:02 but sloppily, it seems 2024-11-19 02:32:08 ptrc: could you also do it for phosh-mobile-settings and phosh itself? 2024-11-19 02:33:31 I thinks it's only those three that are needed now 2024-11-19 03:24:48 omno: I think gitlab.gnome.org is the new upstream for phosh stuff so maybe it shouldn't be a temporary change? 2024-11-19 03:26:13 craftyguy[m]: the tarballs didn't have the similar enough content and ptrc fixed the issue by hosting at dev.a.o 2024-11-19 03:28:05 I'm a bit confused by that, but 🤷‍♂️ 2024-11-19 03:28:06 and https://phosh.mobi/releases/rel-0.43.0/ point to https://sources.phosh.mobi/releases//phosh/phosh-0.43.0.tar.xz 2024-11-19 03:28:17 so it doesn't look like that has changed 2024-11-19 03:36:53 ok, my attempt in !75405 failed too, I have stared myself blind at that APKBUILD and am obviously missing something 2024-11-19 03:37:47 adding uutils-coreutils (while having docs and uutil-linux installed) still installs uutils-coreutils-more-doc and purges util-linux-doc 2024-11-19 03:38:34 perhaps I should just remove the uutils-coreutils-more-doc sub-package, it isn't that important 2024-11-19 03:39:50 but I thought util-linux-doc would win over it 2024-11-19 03:56:29 omni: oh ya ignore me, I think the phosh.mobi is correct 2024-11-19 04:10:18 perhaps their git was hosted elsewhere previously? 2024-11-19 07:59:18 Yeah it was at purism, then IIRC at gnome's gitlab (but maybe I'm wrong) 2024-11-19 08:03:15 The problem with gnome gitlab tarballs is that they are not generated with meson dist 2024-11-19 08:03:30 And Phosh/Phoc need often some submodules vendored 2024-11-19 08:04:06 The GNOME place for it is https://download.gnome.org/sources 2024-11-19 08:27:42 the 6.12 kernel didnt work on my x86_64 desktop 2024-11-19 08:27:51 didnt boot 2024-11-19 08:28:01 it loaded kernel but hang on loading initramfs 2024-11-19 08:28:03 dunno why 2024-11-19 09:01:36 i wonder why util-linux started to fauilb build all of a sudden 2024-11-19 09:17:50 https://lwn.net/Articles/990750/ , It is no longer possible to mount a filesystem on top of any of the ephemeral files in /proc 2024-11-19 09:19:31 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d80b065bb172 2024-11-19 09:43:37 debugging could become easier, "It is now possible to set up the tracing ring buffer" 2024-11-19 09:46:08 i think, upgrading to 6.12 would need other relevant code changes to some main packages to work optimally 2024-11-19 09:47:16 maybe delay al-v3.21 2024-11-19 09:58:58 introducing linux-lts-rt kernel with new RT feature could be useful 2024-11-19 10:01:05 It is already delayed, and not ready soon 2024-11-19 10:01:15 Still too many packages failing 2024-11-19 10:05:32 there was an argument couple of days back to increase the cycle period, maybe introduce [delayed,late]-release version 2024-11-19 10:05:46 instead of permanent cycle change 2024-11-19 10:07:12 TC needs to vote on it first 2024-11-19 10:10:49 some rule could be, 1. % affected pkgs in /main 2024-11-19 10:11:40 2. previous delays, backlogs 2024-11-19 10:17:02 3. cut builds in /testing, /community during 1st 6months in this late-cycle 2024-11-19 10:25:09 I've thought of the idea of "just" doing a test cut (rebuild off everything) half-way between releases, but with less stakes than the actual release-cut, to get a heads-up 2024-11-19 10:25:33 vkrishn: testing/ is not included in stable releases 2024-11-19 10:27:49 but build during edge period 2024-11-19 10:28:00 till its cut 2024-11-19 10:28:47 omni: we already kind of did that with the loongarch64 rebuild, but enough failures remained 2024-11-19 10:29:41 and new build failures were introduced 2024-11-19 10:33:10 true, but we won't introduce a new architecture twice a year, will we? =) 2024-11-19 10:34:15 new build issues are always introduced and unevenly over the year, it's hard to plan for 2024-11-19 10:35:41 perhaps do test rebuilds of everything when certain software is upgraded? like gcc and llvm and a few others 2024-11-19 10:35:52 just throwing ideas 2024-11-19 10:40:15 we need fix ghc 2024-11-19 10:40:29 and util-linux. no idea why it started to fail 2024-11-19 10:40:45 does coreutils build ? 2024-11-19 10:40:53 qt6-qtwebengine fails on aarch64 2024-11-19 10:41:05 vkrishn: no idea. i assume it does 2024-11-19 10:44:05 I think I know why util-linux started to fail, and I think it is my fault 2024-11-19 10:45:14 util-linux has coreutils in checkdepends, but installs uutils-coreutils 2024-11-19 10:45:52 am I not understanding provider_priority or is it something else? 2024-11-19 10:50:03 perhaps add replaces_priority too? 2024-11-19 10:55:50 !75456 2024-11-19 10:56:08 not sure it is the right fix, please help me make this right 2024-11-19 10:58:04 I am dog-fooding uutils-coreutils myself, but it is not my intention that it should replace coreutils unless you actively choose to 2024-11-19 11:00:06 is it "replaces" I got the wrong idea about and should never have used in the community/uutils/APKBUILD? 2024-11-19 11:15:29 aha! i would never have guessed that 2024-11-19 11:17:21 omni: replaces is only to tell apk-tools it's fine that a package has the same file as another package that has not been removed yet (but will be) 2024-11-19 11:17:39 It's to prevent apk complaining about file conflicts while one package replaces another 2024-11-19 11:17:48 !75459 2024-11-19 11:19:06 omni: You are mixing concrete and virtual packages (with provides) 2024-11-19 11:19:27 cureutils is a concrete package, while you do provides=coreutils (without version) which makes it a virtual package 2024-11-19 11:19:37 That's afaik undefined 2024-11-19 11:21:34 so I should also do provides="coreutils=$pkgver-r$pkgrel"? 2024-11-19 11:22:22 yes, but be aware that that means that provider_priority is no longer relevant 2024-11-19 11:22:41 I'm sorry, I stared myself blind on that APKBUILD over the weekend, but thought I had gotten it right 2024-11-19 11:22:43 It would just be the version that is the decider (highest versiion wins) 2024-11-19 11:23:42 why do we need provides=coreutils ..? 2024-11-19 11:24:05 I suppose they want to be able to use uutils instead of coreutils 2024-11-19 11:24:10 if anything has a hard dep of coreutils you normally want the GNU coreutils 2024-11-19 11:24:11 yes 2024-11-19 11:24:24 nothing preventes you to use uutils instead of coreutils? 2024-11-19 11:24:40 can you just apk add uutils? 2024-11-19 11:24:42 Except for things pulling in coreutils 2024-11-19 11:24:43 if they have conflicting files? 2024-11-19 11:25:59 the things pulling in coreutils doesn't really need GNU coreutils? 2024-11-19 11:26:27 "Cross-platform Rust rewrite of the GNU coreutils " 2024-11-19 11:26:36 So it's supposed to be a drop-in replacement 2024-11-19 11:27:15 ok 2024-11-19 11:27:39 so util-linux should build with uutils then 2024-11-19 11:27:52 no 2024-11-19 11:27:59 or yeas 2024-11-19 11:28:03 sorry 2024-11-19 11:28:28 Seems like output difference: 2024-11-19 11:28:30 -cp: cannot create regular file '/dev/zero': Permission denied 2024-11-19 11:28:32 +cp: /dev/zero: Permission denied (os error 13) 2024-11-19 11:30:08 but some things doesn't seem to be there yet with uutils-coreutils, I've put the /bin/stat symlink in a separate -stat sub-package, for example 2024-11-19 11:30:51 how can I enforce use GNU coreutils if that is the implementation I want? 2024-11-19 11:30:59 for things like util-linux 2024-11-19 11:31:15 ncopa: with virtual packages you'd use provider_priority to give one precedence 2024-11-19 11:31:21 If you manually install the other, it will use that 2024-11-19 11:31:34 But in this case, it's mixing virtual and concrete packages 2024-11-19 11:31:35 or set specific version in checkdepends? 2024-11-19 11:32:26 until I have sorted out my mess 2024-11-19 11:32:29 at least 2024-11-19 11:32:53 i suggest reverting the addition of provides= 2024-11-19 11:33:03 til you have figured out how to solve it 2024-11-19 11:33:13 i suppose we could rename coreutils to gnu-coreutils 2024-11-19 11:33:33 the problem is that uutils is in community/ and we are stuck on main/, so I think main/util-linux has to be adjusted 2024-11-19 11:33:34 and I add checkdepends="gnu-coreutils" to util-linux 2024-11-19 11:35:17 coreutils=~9 would work 2024-11-19 11:35:44 or coreutils>1 2024-11-19 11:36:01 (as a work around to get things building again) 2024-11-19 11:36:25 i don't like it 2024-11-19 11:36:29 !75461 2024-11-19 11:37:00 ncopa: if you would go that route, you could add provides=coreutils; provider_priority=100 2024-11-19 11:37:12 ncopa: neither do I, and I am very sorry about this, but when main is built uutils can be fixed 2024-11-19 11:37:45 and the specific coreutils version in checkdepends be reverted 2024-11-19 11:38:02 ah, right, we cannot revert due to main is built first 2024-11-19 11:38:08 i got it 2024-11-19 11:42:42 hmm.. two tests failed for aarch64 in the above MR, https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1610962 2024-11-19 11:43:00 i suppose we can just add !uutils-coreutils 2024-11-19 11:43:40 I guess that would work too, but I don't intend to re-introduce this issue! :D 2024-11-19 11:43:43 yup, that would work 2024-11-19 11:44:57 but it also has me thinking, should main/-builds be able to install aports from anything other than main/ ? 2024-11-19 11:45:07 omni: maybe provides="coreutils=0.$pkgver-r$pkgrel" to keep the version in there but force it to always be lower 2024-11-19 11:46:16 isn't the main issue my use of "replaces"? 2024-11-19 11:46:22 no 2024-11-19 11:46:26 oh 2024-11-19 11:46:35 replaces does not cause packages to be installed instead of others 2024-11-19 11:46:46 provides does 2024-11-19 11:46:57 omni: all "replaces" does is allow a package to install even if it has file conflicts 2024-11-19 11:47:18 The issue is provides="coreutils" 2024-11-19 11:47:45 I think even provides="coreutils=0-r0" would fix the issue 2024-11-19 11:48:00 it would 2024-11-19 11:48:21 thats a better solution 2024-11-19 11:48:33 i pushed ae4aadbce739309b838a0e749bb152461cb6fae3 2024-11-19 11:48:48 ncopa: I think we should remove the community repo from the edge builder repositories file 2024-11-19 11:49:43 but why would apk choose a lower version? 9.5-r1 > 0.0.28-r3 2024-11-19 11:49:53 i dont think we can, or we have to add logic to included it for testing repo 2024-11-19 11:50:03 ok 2024-11-19 12:03:11 For CI, we do have that logic 2024-11-19 12:04:55 PureTryOut: qt6-qtwebengine fails to build on aarch64 after d7ce3631f86a3b97dd5623adc3dc1ea77e2b0e12 2024-11-19 12:05:37 $ curl --silent https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/qt6-qtwebengine/qt6-qtwebengine-6.8.0-r0.log | grep 2024-11-19 12:05:37 ../../../../../src/3rdparty/chromium/third_party/xnnpack/src/src/amalgam/gen/neonfp16arith.c:12614:44: error: passing argument 1 of 'vld1q_dup_f16' from incompatible pointer type [-Wincompatible-pointer-types] 2024-11-19 12:05:37 error: 2024-11-19 12:11:03 ffs 2024-11-19 12:11:07 CC omni 2024-11-19 12:12:59 I have nothing 2024-11-19 12:13:42 i bit more context: https://tpaste.us/YqoM 2024-11-19 12:14:13 a* 2024-11-19 12:17:32 https://bugreports.qt.io/browse/QTBUG-129985 2024-11-19 12:18:05 https://bugreports.qt.io/browse/QTBUG-129985 2024-11-19 12:18:09 oh yeah I just found that haha 2024-11-19 12:18:46 I guess we'll apply that workaround for now 2024-11-19 12:20:44 I wonder if we can apply it without bumping pkgrel, so we dont need to rebuild on all arches 2024-11-19 12:20:52 trying to save some CPU cycles 2024-11-19 12:21:15 but I dont know what happens on 32 bit arm though 2024-11-19 12:21:33 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75464 2024-11-19 12:21:44 I was hoping to do it without bumping pkgrel as well 2024-11-19 12:21:53 if you apply it conditionally for just aarch64 to begin with? 2024-11-19 12:22:06 >>> ERROR: qt6-qtwebengine: 0016-Workaround-for-arm-build-failure.patch is missing in checksums 2024-11-19 12:22:39 or it is pretty arm specific already 2024-11-19 12:22:44 well 2024-11-19 12:23:17 yeah yeah I noticed the checksums 😅 2024-11-19 12:23:32 it's definitely an ARM specific patch 2024-11-19 12:24:15 unless that cpu variable contains arm64 this patch might not even help 2024-11-19 12:24:42 also this just disables a feature 🤷 As long as we get it compiling for now I suppose 2024-11-19 12:26:16 I guess it's fixed upstream already and Chromium just needs to ship a newer version of their dep? 2024-11-19 12:26:16 https://github.com/google/XNNPACK/issues/987 2024-11-19 12:27:30 i thikn that is different issue 2024-11-19 12:28:14 Hmm with patch it fails build differently now 2024-11-19 12:28:18 ACTION sent a code block: https://matrix.org/oftc/media/v1/media/download/ARmlp8ZMunouUPRzRYeCsJsm3HkA-u9-dpbOdcbV8MhHQBgFvz6uKaDm--g-xbvcHfwP3aRe8GBzJKfMDAaopBtCeTjH4o_QAG1hdHJpeC5vcmcvT2ZkT0ZEeXRERGxBQmRPVnJTTGhBeURv 2024-11-19 12:28:57 although I don't see what the error has to do with the patch... 2024-11-19 12:29:13 i have also weird errors in my aarch64 env 2024-11-19 12:30:06 but I think it may be due to qt6-qtbase 6.8 is not yet built 2024-11-19 12:30:32 oh maybe 2024-11-19 12:33:09 In that case... Just push/merge it I guess? 2024-11-19 12:33:54 yeah 2024-11-19 12:33:56 im just merging it 2024-11-19 12:34:08 just verified that it start building on x86_64 at least 2024-11-19 12:35:24 looks like celeste managed to do the last bit to make it build on loongarch64 again !75296 2024-11-19 12:36:49 and the loongarch64 patches are only applied for that architecture this time 2024-11-19 12:37:06 ah nice 2024-11-19 12:37:15 I hope they get it upstream soon 2024-11-19 12:37:46 cant get upstreamed if they only are applied to loongarch 2024-11-19 12:44:13 Hmm why not? 2024-11-19 12:47:54 ncopa: I meant, in this MR loongarch64 patches are only applied to loongarch64, with case "$CARCH" in loongarch64) 2024-11-19 12:50:12 somethign is broken. baloo-widgets tests seems to deadlock 2024-11-19 12:50:41 i saw some other test suite deadlock the other day 2024-11-19 12:51:19 i wonder if those are related to https://gitlab.alpinelinux.org/alpine/aports/-/issues/16626 2024-11-19 12:51:29 no. probably not 2024-11-19 12:54:34 strawberry seems to be hanging as well 2024-11-19 12:57:42 does !75459 look ok now? so we can get it in before I have broken more stuff 2024-11-19 13:11:04 PureTryOut: qt6-qtwebengine passed on aarch64. thank you for quick response! 2024-11-19 13:12:55 ikke: yup strawberry tests also hangs 2024-11-19 13:15:10 seems like it happens with xvfb-run 2024-11-19 13:16:49 Awesome, np! 2024-11-19 13:17:13 and it hangs without xvfb-run as well 2024-11-19 13:23:22 plasma-workspace tests also hangs 2024-11-19 13:23:27 on armv7 2024-11-19 13:25:54 was uutils-coreutils installed? -__- 2024-11-19 13:26:35 no 2024-11-19 13:27:10 so far, it seems to only affect things that uses xvfb-run, qt and cmake 2024-11-19 13:27:26 xvfb-run depends on coreutils 2024-11-19 13:27:34 i dont think it is xvfb-run itself, as I was able to reproduce it on my dekstop 2024-11-19 13:27:58 i suspecte there is something in recent qt6 that makes it deadlock 2024-11-19 13:28:08 when running the tests 2024-11-19 13:28:41 and you didn't get infected by uutils-coreutils? 2024-11-19 13:29:46 correct. no uutils whatsoever 2024-11-19 13:29:51 I'm more relaxed now, but what an embarrassing ride 2024-11-19 13:29:58 same thing now happens on korganizer 2024-11-19 13:30:47 omni: no worries. it happens, and now it is resolved - without me git rm -r uutils :) 2024-11-19 13:31:09 but something seems to be broken with qt6 6.8 and tests 2024-11-19 13:31:46 I should have saved some of the logs from utils-linux failing, I think it failed differently for loongarch64, for example 2024-11-19 13:33:17 but upstream know they're not there yet https://github.com/uutils/coreutils?tab=readme-ov-file#gnu-test-suite-compatibility 2024-11-19 13:33:25 getting closer, though! 2024-11-19 13:34:14 now, let's do the same for toybox vs busybox! 2024-11-19 13:35:15 ncopa: thank you for your patience 2024-11-19 13:39:44 rnalrd: incus-feature fails to build on 32 bit: https://build.alpinelinux.org/buildlogs/build-edge-x86/community/incus-feature/incus-feature-6.7.0-r0.log 2024-11-19 13:40:35 https://github.com/lxc/incus/issues/1395 2024-11-19 13:40:41 just upgraded uutils-coreutils to 0.0.28-r4 and still got uutils-coreutils-more-doc as util-linux-doc, even with provides="util-linux-doc=0.$pkgver-r$pkgrel" 2024-11-19 13:41:27 what am I missing? 2024-11-19 13:44:22 yep, fix pushed (hopefully). tnx ncopa 2024-11-19 14:27:20 omni: if i install util-linux-doc, I do get that package 2024-11-19 14:35:58 rnalrd: thank you for quick fix 2024-11-19 14:39:10 what do we do with hanging tests? 2024-11-19 14:39:44 does kde/plasma etc actually work with qt 6.8? 2024-11-19 14:58:52 thanks for the incus fix rnalrd! 2024-11-19 15:49:58 lvm binary segfaults for me in a VM after upgrading and rebooting 2024-11-19 15:50:10 Getting dropped in an emergency shell 2024-11-19 15:57:13 ncopa: Seems a lot of qt6 applications hang when QDBusConnectionManager destroying, including pinentry-qt, wireshark, fcitx5-qt6-immodule-probing. 2024-11-19 15:57:29 I reported it at https://gitlab.alpinelinux.org/alpine/aports/-/issues/16619 2024-11-19 15:58:02 ncopa: yes KDE works with Qt6.8, they're always the first to update to a newer Qt version and upstream CI is already switched to it for a while. I'm using it on my x86_64 desktop just fine 2024-11-19 16:00:02 https://tpaste.us/5QVE 2024-11-19 16:05:59 lvm on edge is broken 2024-11-19 16:06:26 no bueno. what version is that specifically 2024-11-19 16:06:43 2.03.28-r0 2024-11-19 16:07:34 i think i booted ok on bare metal. let me (re)test it 2024-11-19 16:08:15 Fails when I install it in docker and execute it 2024-11-19 16:10:41 the update dropped the toolcontext.c patch 2024-11-19 16:10:42 it's ok on my bare metal installs. 2024-11-19 16:10:49 lindsay: aha. so thats why the testsuites are hanging. Thank you for reporting it 2024-11-19 16:11:05 https://tpaste.us/voZZ 2024-11-19 16:11:30 try apply the top part of https://github.com/chimera-linux/cports/blob/e2873398575b39acdc9799d6cc51c519538da78d/main/lvm2/patches/fix-stdio-usage.patch and check again 2024-11-19 16:12:02 So everything for lib/commands/toolcontext.c? 2024-11-19 16:13:23 building 2024-11-19 16:14:17 psykose: yeah, that seems to fix it 2024-11-19 16:14:38 thanks 2024-11-19 16:16:15 psykose: thank you! 2024-11-19 16:16:20 np :) 2024-11-19 16:16:30 I wonder why that patch was dropped 2024-11-19 16:17:02 alpine/aports!75396 2024-11-19 16:17:09 looks like it didnt apply 2024-11-19 16:18:25 lindsay: could you please share the qt hello world? 2024-11-19 16:19:11 lindsay: never mind... 2024-11-19 16:21:51 thats what I have chatgpt for... 2024-11-19 16:26:29 I just found a random github repository: https://github.com/iTrooz/Qt6-HelloWorld.git 2024-11-19 16:27:00 PureTryOut: qt6-qtbase is definitively broken. https://gitlab.alpinelinux.org/alpine/aports/-/issues/16619 2024-11-19 16:31:37 It's not broken on 3.20 2024-11-19 16:31:57 but its not qt 6.8 on 3.20? 2024-11-19 16:32:06 Sorry, was talking about lvm 2024-11-19 16:32:10 :) 2024-11-19 16:32:40 alpine/aports!75476 2024-11-19 16:39:54 alright, I asked in #musl for help with qt 6.8 exit handler 2024-11-19 16:40:16 next up is lua-system, which for some reason appears to build with old lua.h 2024-11-19 16:40:35 is that why teal fails? 2024-11-19 16:40:42 resulting in this https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/teal/teal-0.24.1-r0.log 2024-11-19 16:40:42 yes 2024-11-19 16:41:16 if lua5.4-system was build with lua.h from lua 5.4, that symbol should be a define 2024-11-19 16:41:19 but it isnt 2024-11-19 16:42:03 the build log of lua-system indicates that -I/usr/include/lua5.4 is there, 2024-11-19 16:42:13 so im not sure what is going on 2024-11-19 16:42:25 but I believe it was introduced with the recent lua-system upgrade 2024-11-19 16:42:32 and now I have to go 2024-11-19 16:52:48 we don't have a 3.22 milestone or label, but do we have some other way of tagging something post upcomming release? 2024-11-19 17:11:36 ikke: but if you install uutils-coreutils util-linux-doc will be replaced by uutils-coreutils-more-doc, won't it? it does for me, even when removing and re-adding uutils-coreutils (the only uutils aport I have mentioned in my /etc/apk/world) 2024-11-19 18:13:30 Just confirmed, my system is currently running Qt 6.8 with the entirety of KDE just fine 🤔 2024-11-19 18:13:58 pinentry-qt, as mentioned in the bug report, also works just fine 2024-11-19 18:16:28 ncopa: even your reproducer doesn't have the problem for me 2024-11-19 18:33:07 Is $BOOTSTRAP not supposed to survive into the actual build function? No matter what I do it's undefined when abuild actually gets to build() 2024-11-19 18:35:44 I rebuilt community/pinentry-ui (and testing/qt6ct) against Qt6 6.8.0 yesterday 2024-11-19 18:36:59 //init ? https://pkgs.alpinelinux.org/contents?name=s6-overlay 2024-11-19 18:38:59 PureTryOut: oh, pinentry was mentioned in the issue that was then re-opened, sorry about the noise 2024-11-19 18:39:41 but ncopa said he had a small reproducer. That didn't do it for me either 2024-11-19 18:52:59 but the reporter mentioned also another aport with issues 2024-11-19 20:23:48 PureTryOut what arch did you test on? What version of glib and musl? 2024-11-19 20:27:30 ncopa: sertonix btw has a fix for teal 2024-11-19 20:29:41 ncopa: x86_64, whatever is in edge right now 2024-11-19 20:33:20 PureTryOut: that is interesting. so under certain circumstances it works and under others it does not 2024-11-20 05:31:52 ok I'm very confused about how fc50f09a was merged in aports. I submitted that patch a few weeks ago in MR 74567, but I don't think the version merged (which was authored by someone else) was ever an MR(?) that I had to approve. Maybe it wasn't assigned to me because the maintainer email is the kde team? 2024-11-20 05:43:58 It was part of !74829 2024-11-20 05:47:30 I should have caught that it was a different maintainer 2024-11-20 07:08:31 craftyguy[m]: I hope it didn't cause any issues? 2024-11-20 08:10:59 Hi, Im trying to package something that needs /usr/include/xlocale.h . It turns out that xlocale.h is the same as locale.h (provided by the musl-dev package). 2024-11-20 08:11:22 how can I "provide" xlocale.h so this all builds? 2024-11-20 08:11:29 https://github.com/snikket-im/snikket-sdk?tab=readme-ov-file#alpine-linux 2024-11-20 08:12:06 can you just patch source to use locale.h? 2024-11-20 08:12:25 Was about to suggest that 2024-11-20 08:13:03 git greping for locale.h doesnt return anything ikke fossdd[m] 2024-11-20 08:13:12 anything I can patch that is 2024-11-20 08:21:52 it comes from https://github.com/HaxeFoundation/neko 2024-11-20 08:22:27 ah 2024-11-20 08:22:33 ok, let me take a look 2024-11-20 08:22:46 thank you! 2024-11-20 10:20:11 alright! I have a solution for qt 2024-11-20 10:51:38 ncopa: > recent bug reports have shown other 2024-11-20 10:51:38 platforms (Solaris, MUSL libc) that, 13 years after the ratification of 2024-11-20 10:51:38 the standard, still have broken support, 2024-11-20 10:51:42 That's not great to hear 😢 2024-11-20 10:52:04 KDE CI was also failing on this so I'm glad you found the fix 2024-11-20 10:52:22 Link? 2024-11-20 10:52:41 https://github.com/qt/qtbase/commit/334a3922c0b0cf1c829a49ba3e05471159a70b54 2024-11-20 11:03:44 yeah does not sound good. not sure what they talk about, but I forwarded it to #musl 2024-11-20 11:04:49 testing/haxe was added in 89c0b1b4f478cb99ec6cf3a5242e753c44f04896 2024-11-20 11:04:52 but 2024-11-20 11:05:16 529a36cf0212c83830aedd069c17820a8322a66a 2024-11-20 11:05:54 and 65a24e839148896d1d3686ca03c59c2049b66c50 2024-11-20 11:12:20 oh well 2024-11-20 11:26:13 that's fine though no? Whatever was the reason for disabling it originally, now it's needed and works again 2024-11-20 11:28:04 except that it fails to build on every single architecture https://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/haxe/haxe-4.3.6-r0.log 2024-11-20 11:34:10 Oh huh, it worked on CI 2024-11-20 11:36:03 !69597 2024-11-20 11:38:28 Hmm can't find neko, but that's added in the same PR? 2024-11-20 11:40:32 Yes, it was 2024-11-20 15:44:21 minetest-mineclone2 has checksum errors and certificate errors 2024-11-20 15:44:32 curl: (60) SSL: no alternative certificate subject name matches target hostname 'git.minetest.land' 2024-11-20 15:44:32 More details here: https://curl.se/docs/sslcerts.html 2024-11-20 15:52:46 ncopa: it doesn't seem to happen consistently 2024-11-20 15:53:07 yesterday only happened in aarch64 ci, then pushed another commit and it was fine 2024-11-20 15:53:20 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75497 2024-11-20 15:53:42 dunno. but the checksum error of the cachec file in distfiles? 2024-11-20 15:54:03 commit pushed a few minutes ago and it was fine, but yes, there's a checksum mismatch issue 2024-11-20 15:54:30 upstream renamed the project, which likely affected the directory name inside the tarball 2024-11-20 15:54:35 so the checksum is different 2024-11-20 15:55:05 renamed as in renamed the project name and repo 2024-11-20 15:56:10 updating the checksum in the APKBUILD should resolve it 2024-11-20 15:57:01 and maybe a different tarball name 2024-11-20 16:10:22 ACTION laughs: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75528 2024-11-20 16:10:47 armhf could have been enabled 2 years ago \o/ 2024-11-20 16:11:32 pretty sure the reason it was disabled was never fixed 2024-11-20 16:12:10 something more than extra-cmake-modules not being built on that arch? 2024-11-20 16:12:31 running actual qt apps never worked 2024-11-20 16:13:04 ah, well that would do it. :x 2024-11-20 16:13:40 or maybe it was just for qt5 2024-11-20 16:14:17 i don't think https://bugreports.qt.io/browse/QTBUG-65246 ever got fixed for 6 either though 2024-11-20 16:14:28 people just started enabling it because it "looks nicer" but i don't think anyone uses it 2024-11-20 16:24:52 deployed a new version of aports-qa-bot, if you notice anything strange, let me know 2024-11-20 16:58:14 it seems quiter 2024-11-20 16:58:36 Yeah, I found a bug already 2024-11-20 16:59:41 bot bitten by bug(4bs) 2024-11-20 17:00:07 he 2024-11-20 17:42:08 im working on the 6.12 kernel 2024-11-20 17:42:17 and was thinking about kernel module compression 2024-11-20 17:42:48 we want that enabled for arches yes? 2024-11-20 17:43:23 look slike that is what we currently do 2024-11-20 17:54:15 with it networking should improve, less heat on cpu 2024-11-20 18:21:42 how much of effort/waste would it be if current mqtt msgs are parallel push to redis server ? 2024-11-20 18:21:56 thinking of build a web interface on it 2024-11-20 18:22:32 You are aware of build.alpinelinux.org, right? 2024-11-20 18:22:50 yes, it consumes mqtt.a.o 2024-11-20 18:22:57 Not directly anymore 2024-11-20 18:23:05 Well, the frontend doesn't 2024-11-20 18:23:07 the backend still does 2024-11-20 18:26:39 it was using paho, before iirc 2024-11-20 18:27:42 mqtt over websocket 2024-11-20 18:28:45 ok 2024-11-20 18:29:40 Right now it's using a custom backend to persist the last 3 messages for each builder 2024-11-20 18:29:49 Before, if you refreshed the interface, you lost all state 2024-11-20 18:34:46 analytics on history msgs not possible with it 2024-11-20 18:36:10 The goal is/was to store it somewhere (was also thinking redis) 2024-11-20 18:39:26 it should not require much edits on current script, but need to add timestamp to msgs path before pushing it to redis 2024-11-20 18:39:43 if still thinking, would be nice 2024-11-20 18:40:58 Yes 2024-11-20 18:41:09 Having timestamps in there has been a todo for me 2024-11-20 18:41:13 i use a modified mqtt client for all this, it creates static files on disk, that can then be re-consumed 2024-11-20 18:41:17 https://git.insteps.net/gh/insteps/mqtt-dirpub.git/ 2024-11-20 18:41:52 it not be update for awhile, so probably not usable with current mqtt version 2024-11-20 18:41:57 If you feel up to it, you could add that to build-server-status 2024-11-20 18:42:09 (timestamps, redis) 2024-11-20 19:55:19 ikke: something like, https://m.insteps.net/mqtt/alpine/ 2024-11-20 19:56:13 find this nil.msg strange, https://m.insteps.net/mqtt/alpine/20241121/git/aports/ 2024-11-20 19:58:11 and mater.msg, https://m.insteps.net/mqtt/alpine/20241121/git/aports/ 2024-11-20 20:01:49 vkrishn: probably caused by what people ask algitboit 2024-11-20 20:01:58 algitbot: retry vkrishn 2024-11-20 20:02:25 Or maybe publish directly 2024-11-20 20:04:58 i was then thinking to use this as input to a web-interface 2024-11-20 20:05:11 but with same data in redis 2024-11-20 20:05:25 What would the webinterface show? 2024-11-20 20:05:30 runing on al infra :) 2024-11-20 20:07:12 Just showing what messages are published is not that interesting 2024-11-20 20:07:17 not decided yet, but a mixed input from gitlab's api+mqtt converted to current activity 2024-11-20 20:07:32 similar to what gitlab does but fast view(readonly) 2024-11-20 20:08:44 kinda experiment, for same reason i stated how much of effort/waste, earlier 2024-11-20 20:09:05 some analytics can be derived from it 2024-11-20 20:11:03 redis also comes with some inbuild fn, iirc 2024-11-20 20:11:28 still a vague brew thoughts 2024-11-20 20:14:41 since all history is there 2024-11-20 20:16:12 currently running it from ram, so no disk wear-n-tear 2024-11-20 20:16:54 one days all msgs max to about 5Mb 2024-11-20 20:17:27 Currently the most interesting thing to know is how long something has been building 2024-11-20 20:17:43 msgs in it can be re-consumed 2024-11-20 20:18:05 yes, possible if data is there in it 2024-11-20 20:18:35 i have tried jq on it before 2024-11-20 20:19:11 it's not published on mqtt (you just get a message when a builder starts to build) 2024-11-20 20:19:20 So it needs to be added 2024-11-20 20:19:58 currently i can say build-edge-aarch64 is busiest 2024-11-20 20:20:05 just by looking at file size 2024-11-20 20:21:20 it spewed 17 errors in last 5mins 2024-11-20 20:22:00 Doesn't help that it gets retried about every minute 2024-11-20 20:22:17 so it keeps repeating the same error over and over 2024-11-20 20:23:34 yes, can be improved, just got started 2024-11-20 20:26:21 if msgs get timestamp on orig side, that would improve 2024-11-20 20:27:16 i can add timestamp via mqtt client to incoming msgs, but that would be not ok 2024-11-20 20:31:34 omni: thanks for the merge sweep 2024-11-20 20:34:24 looks like someone being talking to algibot, https://m.insteps.net/mqtt/alpine/20241121/git/aports/master.msg ;) 2024-11-20 20:35:47 yeah hi 👋 2024-11-20 20:36:04 :) 2024-11-20 20:36:10 i'm just booping the builders so that maybe they finish 3.21 before december 2024-11-20 20:36:39 ok, did know about the hidden protocol/rpc 2024-11-20 20:36:46 did not^ 2024-11-20 20:37:01 bl4ckb0ne: np 2024-11-20 20:37:11 what is going on here? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75372/diffs 2024-11-20 20:37:16 it doesn't look like that locally 2024-11-20 20:37:20 to be fair, the mqtt broker had a lot of funny things back in the day 2024-11-20 20:37:40 you used to be able to send a message to #alpine-commits pretending to be a commit 2024-11-20 20:37:53 nevermind, it actually looks ok now 2024-11-20 20:37:59 ptrc: not sure it helps too much atm 2024-11-20 20:38:25 oh, did you enable the thing where builders just keep going after a failure? 2024-11-20 20:38:48 i don't remember if it was a buildrepo flag or something else 2024-11-20 20:39:05 it's a buildrepo flag 2024-11-20 20:39:18 But I have feeling it is keeping failing on the same packages over and over 2024-11-20 20:40:01 i've been watching once in a while and the numbers do go down 2024-11-20 20:40:06 mostly aarch64 to be fair 2024-11-20 20:40:11 it's been stuck for a while 2024-11-20 20:40:43 omni: it looks good to me, what's the issue? 2024-11-20 20:40:57 Probably an outdated diff 2024-11-20 20:41:11 it's just moves + edits, except for the .confd where git just thinks the file is different enough that it doesn't recognize the move 2024-11-20 20:43:16 ptrc: it just looked super weird, htpdate/htpdate.conf showed up as htpdate/htpdate.init and htpdate/htpdate.init as htpdate/htpdat 2024-11-20 20:46:09 I think it's just me being tired 2024-11-20 20:51:56 could also be some weird gitlab thing 2024-11-20 20:52:50 that's what I first thought too, but it could very much just be me being tired 2024-11-20 20:52:55 i still dislike its web frontend 2024-11-20 20:53:32 it's not great, but MS GitHub is getting even worse lately 2024-11-20 20:53:42 not as if that would be an alternative 2024-11-20 20:53:45 those massive async calls can mess things 2024-11-20 20:55:02 i would suggest use NoScript and enable gitlab.a.o 2024-11-20 20:55:35 on new PrivateBrowse window 2024-11-20 20:55:59 to be fair, a static frontend for gitlab-specific stuff as an extension of cgit would be really cool 2024-11-20 20:56:30 I should just look into using glab more 2024-11-20 20:56:37 might try to tinker with at least read-only capabilities at some point, i've been plenty annoyed at how gitlab works really slow 2024-11-20 20:56:59 glab is not exactly better, in the sense that the gitlab API is also terribly slow 2024-11-20 20:57:17 ( and, just to be clear, it's not gitlab.a.o-specific, it's just gitlab ) 2024-11-20 20:59:34 also, maybe i should post my tools somewhere 2024-11-20 20:59:42 i have a bunch of cursed scripts to help reviewing MRs 2024-11-20 21:00:29 including one that shows the MR diff, then searches the logs for the checkapk output, and does rebase+merge when confirmed 2024-11-20 21:00:54 fyi, checkapk output is stored as an artifact as well 2024-11-20 21:01:03 oh! didn't realize 2024-11-20 21:01:05 try editing about:config and nulling out calls to gadzillian mozilla urls and it gadzallion subdomains 2024-11-20 21:01:17 well that makes my life a lot easier 2024-11-20 21:01:32 bet add those to hosts file pointing to localhost 2024-11-20 21:01:37 best^ 2024-11-20 21:01:42 vkrishn: at this point you can just try and yoink the librewolf configs 2024-11-20 21:01:52 it speeds things up 2024-11-20 21:01:56 ah, yes 2024-11-20 21:01:58 ptrc: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1612446/artifacts/raw/logs/checkapk-libinput.log 2024-11-20 21:02:01 blocking random domains will inevitably break small things 2024-11-20 21:02:13 but not when the artifacts are too large sadly) 2024-11-20 21:09:20 you would be surprised if you connect to some home page of user in GH and take a peek at "sensors" 2024-11-20 21:11:04 what do you mean? 2024-11-20 21:14:30 cpu excess use 2024-11-20 21:15:31 seems less/okish on AL compiled recent browsers (v114+) 2024-11-20 21:17:00 i sometimes test my web apps on older browser as far as v68, they used to be fine on GH, now horendous 2024-11-20 21:18:38 ptrc: would love to see those cursed MR review scripts of yours, they sound awesome to me :) 2024-11-21 01:13:37 Hey ptrc, any reason why the CI passed but the builders dont like it? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69597#note_457439 2024-11-21 01:15:31 ikke: sorry for the extremely delayed response, no merging that kstars upgrade didn't cause any issues 😁 I was just surprised by it and was only curious what happened heh 2024-11-21 07:34:41 Perhaps is a little bit OT, but... 2024-11-21 07:34:42 https://linuxiac.com/openwrt-adopts-apk-as-new-package-manager/ 2024-11-21 07:34:44 <3 2024-11-21 07:35:24 "In a bold and unexpected move" 2024-11-21 07:35:34 how much unexpected was it 2024-11-21 07:49:50 pretty much unexpected 2024-11-21 08:02:06 It was in the works for quite some time already 2024-11-21 08:14:31 only 3+ years 2024-11-21 08:15:47 Hi, can i install openwrt packages on alpine? 2024-11-21 08:15:51 ACTION hides 2024-11-21 08:16:47 someone was already asking that on openwrt forum 2024-11-21 08:16:48 so they ported apk to the various mips flavor too... 2024-11-21 08:18:00 apk was already supported on mips though? 2024-11-21 08:18:58 not by us afaik 2024-11-21 08:19:13 it was but was dropped 2024-11-21 08:19:27 alpine had mips 2024-11-21 08:19:39 we used to 2024-11-21 08:19:40 https://build.alpinelinux.org/ 2024-11-21 08:19:42 but the hardware was dying and it was decided to stop supporting it 2024-11-21 08:19:47 no longer mips in the builders 2024-11-21 08:20:02 k 2024-11-21 08:20:11 we only had one machine, and it was kind of... 2024-11-21 08:20:18 and the arch was eol anyways 2024-11-21 08:20:31 long and behold loongarch 2024-11-21 08:20:45 it was looong ago 2024-11-21 08:20:49 ..sorry 2024-11-21 08:20:54 :D 2024-11-21 08:21:05 hey, I've tried installing http://dl-cdn.alpinelinux.org/alpine/v3.20/community/aarch64/lapce-0.4.0-r0.apk on my openwrt and it didn't work, can you fix that pls 2024-11-21 08:21:39 hehehe..wondering how many of these requests we will get 2024-11-21 08:24:20 even if it technically would work, it would not install anyways 2024-11-21 08:25:09 we are one of the only distributions using apk v2 2024-11-21 08:30:12 Ermine: but lapce-proxy is what you need to setup remote edit xD 2024-11-21 08:31:08 tried that too and it didn't work either 2024-11-21 08:41:44 except you won't be able to use system installed lapce-proxy 2024-11-21 08:42:12 I don't know why it's packaged, it cannot be used at all 2024-11-21 08:52:53 yes, it checks ~/.local/share/{}/proxy/lapce 2024-11-21 08:53:07 not usr/bin/lapce-proxy 2024-11-21 10:11:48 x86 CI reports - No space left on device 2024-11-21 11:17:11 i think I may have solved it by running docker system prune 2024-11-21 11:17:22 Total reclaimed space: 165.5GB 2024-11-21 11:29:19 ikke: these msgs are not informative, https://m.insteps.net/mqtt/alpine/20241121/rsync/dl-master.alpinelinux.org/edge/ 2024-11-21 11:30:04 think algibot ate its tail 2024-11-21 11:35:34 fossdd: any clue of what might be going on in here? https://gitlab.alpinelinux.org/pabloyoyoista/aports/-/jobs/1613759 2024-11-21 11:36:05 meson is in the makedepends, and obviously abuild is installed... But maybe not through APK? 2024-11-21 11:43:53 hmm, let me check 2024-11-21 11:50:31 should be solved by https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75590 2024-11-21 12:41:15 fossdd: yeah, that works! 2024-11-21 12:41:21 Thanks for the fast fix! 2024-11-21 15:25:48 what's the arch used for the x86 builder? i686? 2024-11-21 15:27:02 --with-arch=pentium-m --with-fpmath=sse 2024-11-21 15:29:39 so that's i686 2024-11-21 15:44:26 omni, you can drop https://git.alpinelinux.org/aports/tree/community/passt/include-linux-types.h.patch (I think) 2024-11-21 15:45:17 apparently its i586 2024-11-21 15:45:18 fun 2024-11-21 15:45:42 it's not, pentium-m/sse2 is required 2024-11-21 15:46:17 welp thats what the mold cmake is printing out 2024-11-21 15:48:06 printing it doesn't mean much 2024-11-21 15:48:23 for a linker they're all basically the same 2024-11-21 15:50:34 that was for enabling tests for mold 2024-11-21 15:50:44 https://github.com/rui314/mold/blob/main/test/CMakeLists.txt#L21 2024-11-21 15:50:55 MACHINE value was i586 2024-11-21 15:51:06 yet it enables i686 tests and they run fine 2024-11-21 15:51:13 (yes i reported the issue on the repo) 2024-11-21 15:51:39 its doing some weird shit with cc to get the arch, might be that 2024-11-21 15:53:08 that's the normal way to get the arch 2024-11-21 15:53:15 you haven't even said what the issue is 2024-11-21 15:53:50 as for the patch uh 2024-11-21 15:53:55 you want "i?86" 2024-11-21 15:55:23 that seems reasonably shorter than checking every variants 2024-11-21 15:55:39 the default for MATCHES is "regex", i forget if you want ? or .? or whatever 2024-11-21 15:55:51 find out in rp as they say 2024-11-21 15:56:36 we'll see in a few minutes 2024-11-21 15:59:48 Are there aports in need of a maintainer? I have some free capacity to spare. 2024-11-21 16:02:15 Definitely, but we don't have a list. You can start looking for aprts where the # Maintainer comment (or maintainer variable) is empty 2024-11-21 16:02:24 how does apk (or abuild) figure out which files to overwrite on package upgrade and which to not touch and instead put the apk-new file ? 2024-11-21 16:02:29 But there are also plenty of aports with one listed who is not active anymore 2024-11-21 16:03:23 Piraty: There's /etc/apk/protected_paths.d, but '/etc/*' is hardcoded 2024-11-21 16:03:28 iirc 2024-11-21 16:03:37 @ikke: Thanks I will check these. 2024-11-21 16:50:07 psykose: you got the syntax right first try 2024-11-21 16:50:14 neat 2024-11-21 18:16:02 i will push linux-lts 6.12 now 2024-11-21 18:18:07 with tomoyo module? 2024-11-21 18:22:37 # CONFIG_SECURITY_TOMOYO is not set 2024-11-21 18:37:12 sbrivio__: thanks, !75606 2024-11-21 18:51:48 community/vtk fails to rebuild without a maintainer; should we move it to testing? 2024-11-21 18:52:27 its required by community/opencascade 2024-11-21 18:52:52 for a second i thought the lack of a maintainer was the issue 2024-11-21 18:53:07 wait, is it in a MR? 2024-11-21 18:53:12 can't find it on #-commits 2024-11-21 18:53:51 no just tested it locally since it need to be rebuilt with ffmpeg 6/7 in !73024 2024-11-21 18:54:18 ah 2024-11-21 20:03:37 nmeum: it looks like ghc fails to build from source now. do you have time to help solve it? 2024-11-21 20:03:55 it is one of many blockers for 3.21 release 2024-11-21 20:04:16 We should start making issues and assign them 2024-11-21 20:55:39 running another ghc build here locally so I can create a proper bug report 2024-11-21 21:53:03 it appears yesterday's update of libinput from 1.26.2 to 1.27.0 broke my thinkpad trackpad 2024-11-21 21:53:38 i can still use the mouse nub but the trackpad itself is no longer responsive to moving or clicking the pointer 2024-11-21 21:54:45 i'm running GNOME with wayland, please let me know if there's any other info i can provide that may be useful 2024-11-21 22:27:33 zram-init (zramctl) is failing 2024-11-21 22:27:36 zramctl: /dev/zram0: failed to set algorithm: Invalid argument 2024-11-21 22:28:10 related to linux 6.12? 2024-11-21 22:32:02 which algorithm 2024-11-21 22:33:57 can check /proc/config.gz after modprobe configs for the full config and see if it's enabled 2024-11-21 22:34:10 bit hard to see that directly from the repo since the 'diff only' config change 2024-11-21 22:38:58 zstd 2024-11-21 22:39:08 # CONFIG_KERNEL_ZSTD is not set 2024-11-21 22:39:20 ? 2024-11-21 22:40:08 yeah looks like it's disabled :) 2024-11-21 22:41:12 what's the proper procedure for updating kernel config without loosing stuff? 2024-11-21 22:42:09 on the plus side, zfs-lts seems to be working with linux 6.12 2024-11-21 22:48:40 lz4 is also disabled 2024-11-21 22:54:57 the default is not losing stuff 2024-11-21 22:56:02 i.e. `cp lts.x86_64.config .config` and then typing `make defconfig` just prompts you for new stuff and does not unset anything that was set unless it was straight up removed 2024-11-21 22:56:25 for things that got renamed or whatnot it would prompt you as if it was a new option 2024-11-21 22:56:57 the reason things like this get lost is because the lts.x86_64.config is not the whole config but just a 'diff on top of defconfig' and that extra step to generate it might maybe lose something 2024-11-21 22:57:00 i forgot how it was done 2024-11-21 22:58:20 er, oldconfig not defconfig 2024-11-21 23:01:43 if i had to guess the olddefconfig might break have broken it since it doesn't prompt you for anything, so when things get shuffled around it just picks the defaults which is off half the time 2024-11-21 23:01:58 not sure why the apkbuild has that instead of oldconfig 2024-11-21 23:02:25 ah, prepareconfigs is only for build 2024-11-21 23:02:39 then no idea :D 2024-11-22 01:08:51 or add in aports(staging) and use diffuse or meld to figure out anything amiss 2024-11-22 01:09:54 sometimes gitk can be useful 2024-11-22 01:41:10 is it CONFIG_ZRAM_BACKEND_ZSTD I am missing? 2024-11-22 05:05:49 natsuni, same with my GeoBook touchpad, I mistakenly thought it was a kernel config regression, but I think you are right that it is libinput 2024-11-22 05:28:00 hi, this mentions allows network access in rootbld: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference#options 2024-11-22 05:28:03 what is rootbld 2024-11-22 05:42:37 A way to build a package in an ephemeral chroot with bubblewrap 2024-11-22 05:45:07 ikke: my build passed on ci but it failed on the builder. afaik, the build does need the internet. 2024-11-22 05:45:46 If I didnt specify the net option, could that be the reason the build passed in ci but didnt pass in the builder? 2024-11-22 05:48:31 anjan: no, the builder does not use rootbld yet 2024-11-22 06:00:48 anjan: which package failed? 2024-11-22 06:01:24 ikke: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69597#note_457439 2024-11-22 06:02:07 ikke: haxe. I tried making a v2 of the package and it builds again on the ci but fails on the builders: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75623 2024-11-22 06:02:18 ti havn no clue on how to proceed 2024-11-22 06:24:04 I noticed it touches .profile during build, it should not do that 2024-11-22 06:24:37 anjan: I reproduce it by manualla running abuild build on the builder, is there anything that I should check? 2024-11-22 06:26:06 hmmm not sure 2024-11-22 06:27:58 ikke: maybe you need to change back to the default .profilt/ 2024-11-22 06:28:12 I wonder if the other ocaml builders change .profile 2024-11-22 06:28:36 I did, but that did not fix it 2024-11-22 06:28:55 does haxe / ocaml cache files somewhere? 2024-11-22 06:38:05 try it 2024-11-22 06:38:05 ikke: https://opam.ocaml.org/doc/man/opam-clean.html 2024-11-22 06:38:05 Yes 2024-11-22 06:38:05 Opam has not been initialised, please run `opam init' 2024-11-22 06:38:05 maybe add it to the apkbuild 2024-11-22 06:38:05 is that what opam clean didt/ 2024-11-22 06:38:06 right after I do opam init 2024-11-22 06:39:40 It keeps returning 'OpamSystem.File_not_found("/home/buildozer/.profile")' after I emptied it 2024-11-22 06:41:02 maybe touch that file? ikke 2024-11-22 06:41:45 It exists, just empty 2024-11-22 06:43:37 It doesn't like the file being read-only 2024-11-22 06:43:54 opam clean didn't help 2024-11-22 06:45:21 so the builders are different than the machines that run CI 2024-11-22 06:45:52 CI runs in a docker container 2024-11-22 06:46:03 ah 2024-11-22 06:46:17 there is something effemeral that is causing an issue 2024-11-22 06:47:23 lemme look around my machine 2024-11-22 06:47:27 for ocaml stuff 2024-11-22 06:53:29 ikke: try rm -rf ~/.opam 2024-11-22 06:56:14 -ENOFILE 2024-11-22 06:56:33 huh? 2024-11-22 06:57:16 I already checked for that, does not exist 2024-11-22 06:58:09 can you temporarily enable the bublewrap for this build somehow? 2024-11-22 06:58:32 No, it's not an option to enable or disable 2024-11-22 06:59:11 can you do a find -iname opam 2024-11-22 06:59:18 in the home directory? 2024-11-22 06:59:28 maybe theres multiple opam caches 2024-11-22 06:59:40 or it's been configured to another path 2024-11-22 07:00:29 nothing 2024-11-22 07:00:41 find . -name '*opam*' 2024-11-22 07:00:56 (same with iname) 2024-11-22 07:01:14 and adding net to options doesnt fix it on the builder? 2024-11-22 07:01:21 if you added net to the apkbuild 2024-11-22 07:01:35 No, without rootbld, that doesn't have any effect 2024-11-22 07:01:41 I have to go now 2024-11-22 07:01:47 ah right 2024-11-22 07:01:56 ok nw. thank you for trying with me 2024-11-22 09:58:14 ncopa: I cannot use zramctl with zstd nor lz4 with the new kernel 2024-11-22 09:58:33 other than that, it seems to work fine for me, also with root on zfs 2024-11-22 10:01:35 I've been skimming diff of boot/config-6.6.61-0-lts and boot/config-6.12.0-0-lts a bit and there may be other things missing, like usbnet, hostap, and a few others 2024-11-22 10:10:02 i noticed the usbnet as well, but thought it may have been enabled by default? 2024-11-22 10:10:21 in any case, I tested an eth over usb dongle I have here, and it works 2024-11-22 10:10:35 so I figured people will ask to enable stuff they are missing 2024-11-22 10:12:32 I should enable zram and zstd? 2024-11-22 10:23:13 for all arches and both lts and virt? 2024-11-22 10:26:08 that would be nice, but no rush, we could try to figure out if there are other things missing that could be of value 2024-11-22 10:26:18 I think lz4 for zram could be of interest for some people too 2024-11-22 10:28:35 comparing the configs now 2024-11-22 10:28:51 $ grep _ZRAM_ .config | tpaste 2024-11-22 10:28:51 https://tpaste.us/knkw 2024-11-22 10:29:14 the zram def comp is now lzo-rle 2024-11-22 10:29:24 which I think is the default 2024-11-22 10:29:29 from defconfig 2024-11-22 10:30:48 https://tpaste.us/OvQX 2024-11-22 10:31:01 gotta go, bbl 2024-11-22 10:34:19 ncopa: i'm missing my laptop touchpad driver on the 6.12.0 2024-11-22 10:34:35 Someone else as well 2024-11-22 10:34:38 it was perhaps a bit premature update for -lts 2024-11-22 10:34:54 it likely will be the lts, but is not announced as such yet 2024-11-22 10:36:49 alright, let me fixt that right away. does linux-edge kernel work for you meanwhile? 2024-11-22 10:39:29 fabled any idea which driver it may be? https://tpaste.us/OvQX 2024-11-22 10:40:27 i think its missing the designware i2c driver at least 2024-11-22 10:40:52 so i2c-designware-pci at least is needed 2024-11-22 10:41:15 i would recommend just reverting the commit (locally) and then redoing the oldconfig 2024-11-22 10:43:58 looked at the diff, thats the only module that stands out. i know for sure that designware i2c needed for my dell laptop touchpad 2024-11-22 10:44:31 # CONFIG_I2C_DESIGNWARE_SLAVE is not set 2024-11-22 10:44:49 was disabled in 6.6. i suppose we dont need the slave thingy 2024-11-22 10:45:30 CONFIG_I2C_DESIGNWARE_PLATFORM=m is needed, if it depends on that, then yes, its needed 2024-11-22 10:56:24 omni: just curious, what do you use zram for? 2024-11-22 11:11:27 on my knoppix it shows like, https://tpaste.us/ 2024-11-22 11:11:36 if its related ;) 2024-11-22 11:11:38 fabled: I'm building it locally now and will push as soon I have confirmed it boots up on my machine 2024-11-22 11:12:13 vkrishn: looks like you miss the suffix in the url 2024-11-22 11:12:15 oops, https://tpaste.us/waPJ 2024-11-22 11:12:34 https://tpaste.us/waPJ 2024-11-22 11:12:43 so you use it for swap sapce 2024-11-22 11:13:24 i think it was meant for that, compressed ram, i am not aware of current status 2024-11-22 11:13:49 there is also zswap 2024-11-22 11:13:57 ok 2024-11-22 11:14:18 i was wondering if it woudl make sense to use zram for things like /tmp 2024-11-22 11:16:26 then we need a wiki on it, there is for zram, https://wiki.alpinelinux.org/wiki/Zram 2024-11-22 11:22:40 zwap is inbuild, must be better tested 2024-11-22 11:22:51 zswap 2024-11-22 11:23:45 can zram-init deal with it too ? 2024-11-22 11:27:20 https://github.com/xvitaly/zswap-cli 2024-11-22 11:29:22 hmmm, zramctl can handle it 2024-11-22 11:32:41 don't know what it does, https://github.com/bluerider/zswap/blob/master/zswap.sh ;) 2024-11-22 11:33:27 i read the fedora doc https://fedoraproject.org/wiki/Changes/SwapOnZRAM 2024-11-22 11:33:44 and I think we maybe should consider enabling that by default as well 2024-11-22 11:33:54 from setup-alpine 2024-11-22 11:34:23 the problem with swap on disk is that it may contain sensitive data 2024-11-22 11:34:47 with swap on zram we avoid this 2024-11-22 11:35:45 https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_not_zswap? needs disk 2024-11-22 11:37:06 maybe they need to redo the wiki page, ;) 2024-11-22 11:37:08 https://www.kernel.org/doc/Documentation/vm/zswap.txt 2024-11-22 11:38:37 zswap is a work in progress and should be considered experimental 2024-11-22 14:10:14 ncopa: thanks, fixed my touchpad. the needed module seems to be only i2c_designware_platform 2024-11-22 14:33:41 PureTryOut: did you rebuild anything with libdisplay-info 0.2? there's a SONAME change 2024-11-22 14:47:36 ncopa, linux-lts-6.12.0-r1 fixes my touchpad on my geobook as well, thanks! 2024-11-22 14:49:43 zswap got removed? I was making use of that on my craptop as it helps a bit with my 4GB setup-alpine swap partition 2024-11-22 14:51:12 might have been unintentional removed. please file an issue so I dont forget to add it back 2024-11-22 14:51:57 you could also consider using zram instead 2024-11-22 14:52:10 but we should probably add it back anyway 2024-11-22 16:01:17 all is good 4me w/ 6.12.0-1-lts with zfs bits on edge; thanks 2024-11-22 16:08:20 Ugh… I broke stuff 2024-11-22 16:08:39 osv scanner. But it built locally 2024-11-22 16:11:09 and the 3.21 build failed anyway 2024-11-22 16:14:53 Seems to happen more often 2024-11-22 16:48:58 Maybe we just disable check on osv-scanner as it’s flaky 2024-11-22 16:49:05 at least for now 2024-11-22 16:49:23 im not by the keyboard atm 2024-11-22 17:47:26 fwiw I noticed this musl build fix patch for lvm2 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/lvm2/fix-implicit-basename.patch however upstream fixed it in a slightly different way https://github.com/lvmteam/lvm2/commit/f98d2ffe8753895c84160a7abce4223bd127cd9e 2024-11-22 17:56:35 orbea: thanks! https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75644 2024-11-22 17:56:44 :) 2024-11-22 18:03:59 ncopa: thanks for merging that libgit2 mr! If you know off the top of your head any other pain points that are blocking the release let me know, happy to help where needed 2024-11-22 18:30:14 "might have been unintentional..." <- Disregard, user error 😑 2024-11-22 18:46:13 durrendal: appreciate! 2024-11-22 18:46:47 current pain points are the build failures for 3.21 https://build.alpinelinux.org/ 2024-11-22 18:46:59 i just reported uvicorn upstream 2024-11-22 18:47:10 and disabled it in aports for now 2024-11-22 18:47:32 #16361 has a collection of them 2024-11-22 18:49:33 ah, there was a unicorn MR to skip 2 tests 2024-11-22 18:50:05 (or xfail them) 2024-11-22 18:50:57 guess could close it if it's disabled 2024-11-22 19:02:44 can someone please take a look at !75377 !75224 !74436 ? thanks 2024-11-22 19:14:40 mio: i cant thank you enough for helping with those issues 2024-11-22 19:18:48 mio: please feel free to ping me anytime if you have MRs that fixes builds for 3.21. there are tons of MRs and I can easily miss those 2024-11-22 19:22:17 there are more rust "time" upgrades needed. https://build.alpinelinux.org/buildlogs/build-3-21-armhf/community/ncspot/ncspot-1.1.0-r0.log 2024-11-22 19:22:23 ncopa: you're welcome. it's not much, just trying to help a bit. okay, thanks 2024-11-22 19:22:41 working on it, unfortunately a time crate bump didn't fix it 2024-11-22 19:23:04 notify-rust is also broken (or probably outdated crate) 2024-11-22 19:23:13 but it means alot, because I feel a bit overwhelmed with all the build failures and november is soon over 2024-11-22 19:23:35 and sometimes it feels that everyone is mostly interested in adding new stuff (and introduce new breakages) 2024-11-22 19:24:11 and the build infra is barely holding it. new MRs comes in almost faster than the curent builds are done 2024-11-22 19:24:30 and the CI machines are often pending, due to huge builds 2024-11-22 19:24:38 3.21-aarch64 is also stuck again 2024-11-22 19:24:53 yes, py3-pyppeteer stuck for ~3rd time 2024-11-22 19:25:02 so seeing someone helping moving things forward is very motivating for me 2024-11-22 19:25:15 alright, let me unblock it 2024-11-22 19:26:04 sorry to hear. agreed it's a lot to juggle 2024-11-22 19:28:07 ncspot does have an upgrade, but existing patches will probably need a refresh 2024-11-22 19:28:29 what, i killed chromium and python3 and py3-pyppeteer succeeded 2024-11-22 19:28:38 instead of failing 2024-11-22 19:28:46 we probably need to fix something there 2024-11-22 19:28:59 but at least it is unblocked for now 2024-11-22 19:32:05 now it is weekend. badly needed weekend 2024-11-22 19:32:12 o/ 2024-11-22 19:32:14 Enjoy 2024-11-22 19:32:19 thanks everyone! 2024-11-22 19:46:08 ncopa: I'll take a look and see what I can do to help. Enjoy your weekend! 2024-11-22 19:47:36 have a good weekend 2024-11-22 20:07:10 really impressive what you are all doing! 2024-11-22 20:07:35 i've been thinking if maybe 2 releng managers would be a good idea 2024-11-22 20:07:56 for one improving the bus factor and also preventing burnout and such 2024-11-22 20:44:57 ncopa: zram-init, so swap and /tmp (and I usually have /var/tmp as a symlink to /tmp) 2024-11-22 20:45:53 and from /etc/conf.d/zram-init: 2024-11-22 20:46:06 # Size: zstd (best) > lzo > lz4. Speed: lz4 (best) > zstd > lzo 2024-11-22 20:46:18 why they all three are interesting to have 2024-11-22 20:47:13 that comparison shows that lzo is not interesting at all 2024-11-22 20:47:37 meow meow 2024-11-22 20:47:39 ok 2024-11-22 20:47:40 :D 2024-11-22 20:48:20 What are the actual margins? 2024-11-22 20:48:55 but for a minute, lzo was the only one available, until zstd and lz4 were made available again 2024-11-22 20:51:59 swap is mostly symbolic, since I had weird issues randomly showing up, after months to years of uptime, with zfs on fbsd without swap some 10+ years ago 2024-11-22 20:57:21 the downside, as I've understood it, compared to regular tmpfs, is that this will allocate a static chunk of ram, whereas regular tmpfs (still as I recall) allocates and frees what is needed (please correct me if I'm wrong) 2024-11-22 20:57:56 it definitely doesn't allocate a static chunk of ram 2024-11-22 20:58:04 or at least i'm not sure what that would look like 2024-11-22 20:58:30 having zram for /tmp is not very useful 2024-11-22 20:58:42 having just a regular tmpfs will already swap to zram that is enabled 2024-11-22 21:00:17 and in a better way, because it only occurs on swap 2024-11-22 21:00:29 zram on tmp would pay the compression penalty on any access 2024-11-22 21:01:43 sometimes I'm fine with spending cycles for imagined space 2024-11-22 21:02:04 not sure i conveyed what i'm saying correctly 2024-11-22 21:02:20 having zram as swap and zram on tmp both can compress things for tmp 2024-11-22 21:02:30 the former is just more efficient because it only happens when it needs to 2024-11-22 21:02:56 zram swap compresses any memory, tmpfs is memory 2024-11-22 22:17:03 ncopa, can we put lz4 and zbud back into the kernel for zswap/zram/etc? Both seem to be missing from the linux-lts v6.12 config, even if forced from the grub bootcmd. Not major, but they can be a bit faster/ligther for older/slower machines to use vs zstd/lzo/et al, and zsmalloc/z3bud 2024-11-22 22:20:17 lz4 zram was enabled in 6.12.0-r1 i think. can you please file an issue with the exact details on what is still missing. I'll try to have a look at it next week 2024-11-22 23:07:53 Thanks so much, and have a good wee o,ilbhjnng 2024-11-22 23:33:58 have a good wee o,ilbhjnng too 2024-11-23 00:17:14 Toddler was helping me type, haha 2024-11-23 00:17:19 I will :P 2024-11-23 02:04:17 z3fold is deprecated now, and according to https://lore.kernel.org/lkml/20240904233343.933462-1-yosryahmed@google.com/ zbud is not useful either 2024-11-23 02:05:36 "natsuni, same with my GeoBook..." <- it seems you were right, today's r1 update sorted the trackpad 2024-11-23 02:06:06 afaik lz4 is still useful though, for faster/less compressed compared to zstd, but there's no reason to use lzo/gzip if interoperability is not a concern (like memory compression) 2024-11-23 04:44:18 "z3fold is deprecated now, and..." <- Fair enough, thanks for the info. I was going off the kernel docs and arch wiki, which are missing this context 2024-11-23 04:44:58 "afaik lz4 is still useful though..." <- Yeah, if possible, I think lz4 would still be nice to have, especially for zswap/zram useage at least 2024-11-23 07:25:58 hey, ikke, if youre able to ssh into the build machine, can you please make this change and try to build haxe? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75623/diffs#d78bdaa0c37814871e17b5bbc10150a114e14693_59_58 2024-11-23 07:26:13 Just remove the --disable-sandboxing flag 2024-11-23 07:26:46 I was able to reproduce the bug yall have been having on the build machine on builds.sr.ht and it works if I remove that flag 2024-11-23 07:26:59 however, docker wont build with that flag removet 2024-11-23 07:39:31 haxe builds fine on build.sr.ht 2024-11-23 08:04:54 anjan: https://tpaste.us/PQKe still seems to fail with the same error 2024-11-23 08:07:05 ikke: abuild clean && a build -r? 2024-11-23 08:07:17 I wonder if there's anything leftover 2024-11-23 08:08:02 also, the docker looked like it failed with he same error till I looked closer and there were new lines explaining some kernel flags were not set (IG theyre not set on docker) 2024-11-23 08:08:27 anyways, is there anything like that on the build machine? 2024-11-23 08:09:54 tps://tpaste.us/6KPa 2024-11-23 08:09:56 https://tpaste.us/6KPa 2024-11-23 08:14:01 There has to be some caching or something going on here 2024-11-23 08:14:04 try eval $(opam env --switch=ocaml-system) 2024-11-23 08:14:11 it keeps asking us to 2024-11-23 08:15:34 and is the .profile "well sourced"? 2024-11-23 08:16:08 for a functional programming language they seem to maximize side effects in their build system. good grief 2024-11-23 08:18:13 .profile is sourced by ash for login shells 2024-11-23 08:18:25 anjan: that change does not help 2024-11-23 08:19:29 ok, I dont know and it's hard for me to debug if I dont have the machine. 2024-11-23 08:19:44 Is there anything I can do to get this building? 2024-11-23 08:21:07 Does ptrc have ssh access ikke? If they have a moment and have a huge heart, maybe they could ssh in and take a look? 2024-11-23 08:21:17 no, ptrc has not 2024-11-23 08:21:23 They did help me with alot of this build and reviewed my latest MR 2024-11-23 08:22:00 Later today I have some more time to look into it 2024-11-23 08:22:32 Ok, thank you so much. Please keep me posted ikke 2024-11-23 08:22:46 and let me know if I can help in anyway 2024-11-23 08:27:52 will do 2024-11-23 08:30:32 i've been looking at !16361, specifically at the aercbook APKBUILD. there is a github by the author for that but has no tags. since the sr.ht repo is gone, hard to tell if it is up to date. not sure whether to switch the source to a commit based tarball or just leave it alone 2024-11-23 08:30:46 damn, not that one 2024-11-23 08:31:01 https://gitlab.alpinelinux.org/alpine/aports/issues/16361 2024-11-23 08:32:19 j_v: # for issues 2024-11-23 08:32:55 ahh, thanks... you may have told me that before. if so, sorry for forgetting 2024-11-23 08:37:49 for the pcc-libs 404, that is common for pcc download site to be down for varying periods, so not sure what is can be done outside of mirroring the source... same should be true of pcc also 2024-11-23 11:22:44 mplayer and mingw* may be fixed/workedaround with -fpermissive 2024-11-23 12:21:38 Is it possible to build armhf and armv7 aports on aarch64 or x86_64 without involving qemu? 2024-11-23 12:22:30 You can on aarch64 if the processor supports 32-bits 2024-11-23 12:22:40 That's how we build armv7 and armhf 2024-11-23 12:23:45 How is it done? Just setting CHOST / CTARGET? 2024-11-23 12:24:51 Running a chroot with linux32 2024-11-23 12:25:57 You want a relevant chroot to get the correct compiler / libraries 2024-11-23 12:26:12 or lxc / docker container 2024-11-23 12:27:34 Thank you. I guess a Raspberry Pi would be slow but sufficient? 2024-11-23 12:29:36 As long as it supports 32-bits 2024-11-23 16:57:40 ncopa: thank you for getting the zram compression options back, works with zstd again 2024-11-23 17:48:14 PureTryOut: kodi failed to build in !75668 and is now failing to build on the package builders 2024-11-23 17:56:12 hi, question about abuild, is there a command for resigning an existing .apk file? 2024-11-23 18:01:45 handlerug: I don't think so 2024-11-23 18:02:23 Here's how the packages are signed and created: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1878-1884 2024-11-23 18:03:10 I think you could untar the apk file, sign the control.tar.gz again with abuild-sign, and then concatenate things together again 2024-11-23 18:03:52 it doesn't seem like it's easy to get control.tar.gz out of the .apk file, tar -tf just shows the whole concatenated archive 2024-11-23 18:04:07 I assume I need to look for gzip bitstream boundaries like apk is doing 2024-11-23 18:04:31 right 2024-11-23 18:06:09 what's with this? https://build.alpinelinux.org/buildlogs//build-edge-riscv64/community/avfs/avfs-1.1.5-r3.log 2024-11-23 18:08:37 The file is 0 bytes 2024-11-23 18:12:24 ok, fixed 2024-11-23 20:54:17 craftyguy[m]: do you have any chance to look at the kodi build failures? 2024-11-23 21:38:59 ikke: same with https://build.alpinelinux.org/buildlogs//build-edge-riscv64/community/delfin/delfin-0.4.8-r0.log 2024-11-23 21:39:26 what's with the double-slash in the url, btw? 2024-11-23 21:39:42 omni: probably a trailing slash in the config that gets concatenated 2024-11-23 21:40:44 hmm, it's empty again.. 2024-11-23 21:41:30 and the double-slash is in both log URLs above, but not for the other ones on https://build.alpinelinux.org/ 2024-11-23 21:42:05 not even build-3-21-riscv64 2024-11-23 21:43:10 yeah, just a config difference 2024-11-23 21:44:04 but /etc/ssl/certs/ca-certificates.crt becoming empty is more concerning 2024-11-23 23:18:17 omni: sorry for the delay, I'm not as available on weekends. ya I can take a look 2024-11-23 23:20:57 oh you have a MR already 2024-11-23 23:21:15 ohhh and it's failing for some other reason than what happened on the builder 🤦 2024-11-23 23:27:12 that's just werror which you can probably remove with -DCORE_COMPILE_OPTIONS="" 2024-11-24 03:54:30 I can't push to omni's branch so I'm not sure how I can help 2024-11-24 03:55:25 later I might be able to try building it locally w/ that var unset 2024-11-24 03:57:05 craftyguy[m]: after your local changes, can't you do a git format-patch and send omni that? 2024-11-24 04:04:41 craftyguy[m]: you can also open a separate MR, if you'd like 2024-11-24 04:05:19 but I also pushed a change with the flag psykose suggested 2024-11-24 04:30:22 I might temporarily disable kodi to get !75723 in 2024-11-24 05:48:51 there we go 2024-11-24 08:00:35 ncopa: I can look into fixing the ghc build. I just currently have a fever. so it might take some time 2024-11-24 08:01:11 nmeum: no worry, take care 2024-11-24 08:01:19 ikke: a user in msgs.a.o in git/aports/master , https://tpaste.us/VY78 would correspond to user in gitlab ? 2024-11-24 08:02:05 ikke: thanks 2024-11-24 08:03:08 vkrishn: https://gitlab.alpinelinux.org/alpine/infra/compose/webhook/-/blob/master/config/scripts/mqtt-publish.lua 2024-11-24 08:05:03 what I mean is, a push in aports may not have a corresponding MR in Gitlab ? 2024-11-24 08:05:11 correct 2024-11-24 08:05:47 like, in eg. https://tpaste.us/VY78, larena pushed directly to aports 2024-11-24 08:05:49 thanks 2024-11-24 08:08:49 it's curious that community/mingw-w64-gcc has so few patches compared to main/gcc. both use same tarball source 2024-11-24 08:19:28 ah, the difference is in the targets 2024-11-24 08:35:59 these msgs are not easy to tag/bind them with gitlab/aports for analytics, but doable 2024-11-24 08:37:09 having timestamp in msgs, would help, coz retained msgs can give strange analytics 2024-11-24 08:37:56 also if mqtt_sub get reconected 2024-11-24 08:41:43 does running zabbix also gives these analytics ? 2024-11-24 08:46:07 would be save some scripting 2024-11-24 08:46:35 would save some scripting 2024-11-24 13:48:20 algitbot's, best-friends circle is growing , https://m.insteps.net/mqtt/alpine/20241124/git/aports/master.msg 2024-11-24 17:53:26 looks like the turnstile package installs pam_turnstile.so into /usr/lib/security/, but every other pam .so file lives in /lib/security 2024-11-24 17:53:33 is this intentional, or a mistake? 2024-11-24 17:53:59 turnstile doesn't function correctly on my system unless I `ln -s /usr/lib/security/pam_turnstile.so /lib/security` 2024-11-24 18:16:54 This is likely an artifact of the ongoing usr merge. My guess is that some, but not all, of the packages that install into /lib/security have been changed to use /usr/lib/security 2024-11-24 18:17:45 nah, it was broken because the package was installed from edge onto stable where the stable linux-pam loads from /lib/security while edge packages are using /usr/lib/security 2024-11-24 18:51:26 That would definitely do it. Good example of why mixing edge packages with a stable install shouldn't be done 2024-11-24 18:54:29 absolutely 2024-11-24 21:31:38 I was aware that mixing edge packages is a bad idea, but I'm yet to find a good solution for people like me who a) want to use packages like turnstile and b) don't want to have to deal with potentially breaking changes every day as on edge 2024-11-24 21:32:09 why for instance do we not build testing for latest-stable? 2024-11-24 21:32:57 it's surely not just a me problem to want new packages from time to time 2024-11-24 21:46:16 Then the package should be moved to commuunity 2024-11-24 21:46:18 community 2024-11-25 08:26:36 kodi fixed with !75834 2024-11-25 09:03:54 nmeum: dont worry about alpine. get well soon! 2024-11-25 10:00:07 trying to bump one of my packages but failing because of generated .so "locally" so abuild parses it on my $HOME and fails :( 2024-11-25 10:31:16 hi all, in which alpine release will be used apk v3? 2024-11-25 10:31:38 i noticed, that openwrt already switched to apk v3 2024-11-25 11:17:23 indy: not yet decided, keep an eye on our gitlab TSC project for more details. 2024-11-25 11:35:14 tsc stands for technical steering committee? :) 2024-11-25 11:39:37 yes 2024-11-25 12:41:19 why was ifupdown deemed unmaintained? it had two releases the same year, before it was removed, and thre releases this year 2024-11-25 12:42:06 afaik the goal is for apk v3 to be used in Alpine 3.22. 3.21 was tried but the freeze deadline wasn't reached 2024-11-25 12:43:05 Iirc fabled also recommended not switching just yet 2024-11-25 12:47:19 (not suggesting bringing old ifupdown back, unless someone asks for it) 2024-11-25 12:51:07 ifupdown-ng, otoh, hasn't had a release for two and a half years, but commits as late as april this year 2024-11-25 13:56:46 ncopa: what do you think about me taking over maintainership of kodi? i've already been fixing the last two build failures. 2024-11-25 13:58:27 fossdd[m]: feel free to open an MR. Generally ncopa does not mind 2024-11-25 13:58:42 alr 2024-11-25 14:09:09 i'd be happy if you could take over kodi! thank you for stepping up! 2024-11-25 16:34:08 <3 2024-11-25 17:14:47 !75711 for when it comes up again on the x86_64 builder 2024-11-25 17:42:10 !75864 fixes ppc64le failure for py3-statmake 2024-11-25 17:48:23 i think ppc-libs needs to be hosted at dev.a.o 2024-11-25 17:48:43 source is down 2024-11-25 18:11:53 heh community/zk failure is funny 2024-11-25 18:11:54 https://chaos.social/@fossdd/113544937866554634 2024-11-25 18:12:56 wait do they check if a certain date is 14 years ago today? 2024-11-25 18:13:02 yeah 2024-11-25 18:13:06 oof 2024-11-25 18:17:33 that's like openjdk checking if a date is within 10 years or something 2024-11-25 18:24:36 i mean 2024-11-25 18:24:53 it kinda makes sense if they take current year, subtract 14, and then check if that formats to "14 years ago" 2024-11-25 18:25:01 the question is why did they hardcode the rest of the date elements 2024-11-25 18:28:57 it was originally not even dynamic :) https://github.com/zk-org/zk/commit/7ba9df6526d45a6f7000e4e48fe62f57430ba415 2024-11-25 18:30:26 tee hee https://github.com/zk-org/zk/commit/142b636342c7f1b3d7160f56c90acc9b4b7482ee 2024-11-25 18:31:12 lol 2024-11-25 23:27:08 fossd: thanks for fixing kodi :D 2024-11-26 06:55:12 no problem :) 2024-11-26 11:44:37 fossdd[m]: how are you doin? you had a rather unpleasant interaction on gitlab 2024-11-26 11:50:20 and to everyone contributing to Alpine: remember that you don't owe anyone anything. We do appreciate your help moving this distro forward 2024-11-26 12:08:31 yeah that was not a nice interaction, but i'm fine now 2024-11-26 12:08:37 thanks for handling it :) 2024-11-26 14:39:27 talking to a hare dev and it seems like it is qbe that needs patching to solve the issue of the failing hare tests on aarch64 2024-11-26 14:40:33 omni: thanks for looking at that 2024-11-26 14:42:16 https://lists.sr.ht/~mpu/qbe/patches/54249 should fix it 2024-11-26 14:42:44 I could look at it later, but feel free to beat me to it 2024-11-26 15:08:51 cool that worked see !75936 2024-11-26 15:14:07 is anyone working on the digikam build? i've found upstream patch the should fix current build issue. if no one is working on it, i will work it now. 2024-11-26 15:42:44 im currently looking at gbinder, but I dont understand how I make cython to use ghe glib.h types guint64, gsize 2024-11-26 15:43:06 i think im just gonna disable it on 32 bit 2024-11-26 15:44:40 biber is also somewhat tricky. seems to be two different providers 2024-11-26 15:54:40 j_v: I say go for it, I don't think anyone has had a chance to look into that one so if you have a fix it's very welcome 2024-11-26 15:55:49 ncopa: I was looking at biber the other night, but wasn't certain where the conflict was coming from. Do you have an idea what the other provider is? 2024-11-26 15:58:03 durrendal: thanks for the encouragement, appreciated 2024-11-26 16:07:22 $ apk search biblatex 2024-11-26 16:07:22 biblatex-3.20-r2 2024-11-26 16:07:22 texmf-dist-bibtexextra-2024.0-r6 2024-11-26 16:08:03 Even more explicit: apk list -qP biblatex 2024-11-26 16:08:10 $ apk info --provides texmf-dist-bibtexextra 2024-11-26 16:08:10 biblatex=3.19.2024.0-r6 2024-11-26 16:08:10 texmf-dist-bibtexextra-2024.0-r6 provides: 2024-11-26 16:11:00 So due to the version, textmf-dist-bibtexextra always has priority 2024-11-26 16:13:14 Perhaps something like https://tpaste.us/Lywl 2024-11-26 16:14:51 could probably work 2024-11-26 16:15:23 Similar to what we did the other day 2024-11-26 16:22:08 ncopa: question is why apk is selecting texmf-dist-bibtexextra when an explicit version is requested 2024-11-26 16:22:34 Shouldn't the version constraint cause it to select biblatex? 2024-11-26 16:34:59 Does apk already select the provider based on version before even considering any package constraints? 2024-11-26 16:45:15 i dont knkow 2024-11-26 16:48:23 'satisfies: texlive-luatex-20240210.69778-r7' 2024-11-26 16:48:26 this has something to do with it 2024-11-26 16:51:21 bibtext -> texlive-luatex -> texmf-dist-bibtexextra !> bibtex 2024-11-26 16:53:54 So this means that bibtex can never be installed 2024-11-26 16:54:26 heh, just wat maribu posted in the issue 2024-11-26 17:01:58 Maribu is looking at it :) 2024-11-26 17:55:41 Sorry for being less responsive these days. In my new job I no longer can work from my private machine with software of my choice on it. Before it was relatively easy and low overhead to use the time my machine was compiling to work on aports. Now the overhead to work on aports is higher and the "compilation breaks" are a lot shorter due to faster hardware, which makes using them for working on aports impossible. 2024-11-26 18:08:26 maribu: no worry, we appreciate everything you are able to do 2024-11-26 18:14:47 <3 2024-11-26 19:24:19 exit 2024-11-26 19:26:00 hah 2024-11-26 19:26:12 hate it when that happens 2024-11-26 19:26:57 I call that a dramatic exit :P 2024-11-26 21:23:47 unfortunately hare is still failing on the aarch64 package builder, even though it passed in CI 2024-11-26 21:24:23 https://c9x.me/git/qbe.git/commit/?id=90050202f57b22243f5d3dd434a81df2f89de9ed perhaps? 2024-11-26 21:24:53 just glanced at https://c9x.me/git/qbe.git 2024-11-26 21:57:33 maribu: btw, do you expect texmf-dist-bibtexextra to be used by default? Because due to it's version, it will always be preferred by APK 2024-11-26 21:58:11 (provides=biblatex=$pkgver-r$pkgrel) 2024-11-26 22:04:59 Yes, I think this is what most users will want. E.g. extra biblatex styles and language support is in there, which is not provided by plain biblatex. If one would use English and the default style only, biblatex should be fine, though. 2024-11-26 22:13:45 !75832 2024-11-26 22:15:59 (latest error on the 3.21 aarch64 builder) 2024-11-27 02:33:09 anyone running alpine on 32-bit arm? 2024-11-27 03:04:46 Mangix: yes, as my daily driver I use a droid 4 + a lapdock. 2024-11-27 04:37:28 i wonder if hare failing on aarch64 has anything to do with that it needs harec to build and the harec used to build hare probably isn't built with patched qbe? 2024-11-27 04:38:31 maybe bumping harec so it gets rebuilt could fix hare build on aarch64? 2024-11-27 06:54:56 hey ikke did you get a chance to look at that haxe build failure? 2024-11-27 08:06:00 omni: The culprit is more likely https://c9x.me/git/qbe.git/commit/?id=bb8de8c63362b7234db02482240d5600203225d9. I've tested qbe with and without this commit with default abuild CFLAGS (gcc -Os) and hare tests do fail without the patch. QBE should probably just release a new version 2024-11-27 08:25:36 yyp: but we did patch with that https://git.alpinelinux.org/aports/commit/?id=3ebbffafea639addf271b65c9d35344ced448ade 2024-11-27 08:25:47 and tests are still failing https://build.alpinelinux.org/buildlogs/build-3-21-aarch64/community/hare/hare-0.24.2-r0.log 2024-11-27 08:26:02 oh 2024-11-27 08:26:54 but not in CI, only on the package builder 2024-11-27 08:27:21 anjan: something came up, but I'll have more time tomorrow afternoon 2024-11-27 08:29:46 is it possible to run a build in package builder environment and extract the test binary to diff against CI? 2024-11-27 08:53:30 ncopa: i didn't know you are working on openrct2. but perhaps take a look at !75973, it should be good to go 2024-11-27 12:02:43 ncopa: well, now you need to disable all the hare* aports 2024-11-27 12:02:57 have we tried patching qbe with https://c9x.me/git/qbe.git/commit/?id=90050202f57b22243f5d3dd434a81df2f89de9ed yet? 2024-11-27 12:03:15 to make hare build on the aarch64 package builder 2024-11-27 12:21:42 !75981 2024-11-27 12:29:45 well, i don't understand how to go about working on fixing a build when the ci doesn't work the same as the builders... very frustrating 2024-11-27 12:33:51 yeah, that was dumb... was looking at the wrong build log 2024-11-27 12:38:45 what wrong build log? 2024-11-27 12:41:31 oh, i was looking for the new build logs for openrct2, but i was looking at an old one, thinking it was a new one... just me being obtuse 2024-11-27 12:48:34 i just like to double check that changes i make don't blow up in my face, and if they do, to try to fix my mistakes promptly 2024-11-27 12:58:35 gavl is driving me nuts now. i want nuke it 2024-11-27 13:02:45 i can take a look if you want a break from it 2024-11-27 13:05:59 waait a minute.. what if harec too needs to be rebuilt after the qbe patching... 2024-11-27 13:22:11 that was not it either... 2024-11-27 13:22:23 j_v: thanks! 2024-11-27 13:23:34 would it be possible to get the qbe packages built on build-3-21-aarch64 even though they aren't uploaded yet? 2024-11-27 13:23:46 qbe-1.2-r2 and qbe-1.2-r3 2024-11-27 13:24:59 sure 2024-11-27 13:25:17 both qbe-1.2-r2 and -r3? 2024-11-27 13:25:20 or only -r3 2024-11-27 13:26:21 both, I think 2024-11-27 13:26:51 will wait til build-3-21-aarch64 is idle 2024-11-27 13:27:18 would you put them publicly so they can be shared with staceee and others? 2024-11-27 13:30:09 oh, you just want the binaries, not have them built on build-3-21-aarch64 specifically? 2024-11-27 13:31:31 I just assume they are already built there and the package builder is waiting to upload the latest of them 2024-11-27 13:32:25 looks like you are right 2024-11-27 13:33:33 onmi: here you go: https://dev.alpinelinux.org/~ncopa/qbe/ 2024-11-27 13:33:40 <3 2024-11-27 13:40:32 ncopa: !75987 2024-11-27 13:40:56 no rush on my account 2024-11-27 13:41:37 oh man... i feel stupid 2024-11-27 13:41:41 thank you <3 2024-11-27 13:42:02 i was so close 2024-11-27 13:42:07 naw, and i cheated. i looked at gentoo and arch 2024-11-27 13:42:57 naw to feeling stupid... 2024-11-27 13:51:26 omni, and others: I have no much clue to help on this. This built qbe cause hare check failure here too. Looks like its recipe is great. I confirm the patch alone on v1.2 should works. 2024-11-27 13:51:38 The only thing I got, maybe there is hare cache somewhare in the filesytem? 2024-11-27 13:52:05 generally located at ${XDG_CACHE_HOME:-$HOME/.cache}/hare/ 2024-11-27 13:52:36 if this survive accross rebuilds, I explain why we struggle on the same checks 2024-11-27 13:53:30 no need to rebuild harec on this qbe 2024-11-27 13:53:55 hare use harec to build qbe internal language. hare use both to build binaries 2024-11-27 13:55:21 disabling the checks would ofc works, but I would really not trust this hare. I would prefer to disable optimization 2024-11-27 13:57:14 so at last ressort, try to rebuild qbe without -Os, and probably hare make checks should works 2024-11-27 14:10:48 https://dl-cdn.alpinelinux.org/alpine/v3.21/community/ is missing x86_64, riscv64, and aarch64 2024-11-27 14:16:42 i think that is why ghc is failing, needs ghc-bootstrap-$_bootstrapver, which is just an alias so ghc can build itself with itself (using provides) 2024-11-27 14:20:30 j_v: they are only uploaded once the builders are finished with the repos 2024-11-27 14:20:52 ghc has test failures on x86_64 2024-11-27 14:22:39 yep, but it needs itself to build, not sure how it can do it presently 2024-11-27 14:23:12 #16638 2024-11-27 14:23:20 j_v: we do it by hand 2024-11-27 14:23:33 Install ghc-bootstrap from edge 2024-11-27 14:23:47 ah, ok. thanks for the heads. that makes sense. 2024-11-27 14:25:01 staceee: but you say the qbe we have built still has issues? both -r2 and -r3? 2024-11-27 14:25:42 heads* up 2024-11-27 14:26:08 though it doesn't seem to be working, based on the 3.21 build log 2024-11-27 14:29:46 but i will try looking at it... pretty sure nmeum would do better at it than me, but i will see if i can come up with something. i'm assuming he is still not feeling well 2024-11-27 14:36:54 staceee: build environment is stateful 2024-11-27 14:41:25 ikke: soo.. that means that hare could be reusing things from before qbe was patched? 2024-11-27 14:41:52 iirc at some point there was some HARE_CACHE env on the recipes 2024-11-27 14:44:28 !61207 2024-11-27 14:45:01 HARECACHE* 2024-11-27 14:45:30 right this also works 2024-11-27 14:47:13 381364e1f60e66afeeb5767be64fa90f979ec0ad 2024-11-27 14:47:22 that's where it was added 2024-11-27 14:48:10 staceee: but perhaps it would be better to use the HARECACHE var? 2024-11-27 14:55:07 !75989 perhaps 2024-11-27 14:56:50 the config.mk changed at some point? 2024-11-27 14:58:00 the HARECACHE is still there 2024-11-27 14:59:48 still where? 2024-11-27 14:59:54 what config.mk? 2024-11-27 14:59:58 on the upstreams config.mk ya 2024-11-27 15:00:24 I find no config.mk in the hare tarball 2024-11-27 15:02:44 mhh it is, in builds/. On my machines, I had to rm -rf ~/.cache/hare/ to test those qbe 2024-11-27 15:03:10 maybe the "make check" doesn't use the HARECACHE from the config.mk 2024-11-27 15:03:34 if you guys succeed with the XDG_CONFIG_HOME, this is probably the case 2024-11-27 15:04:19 configs/linux.mk perhaps? 2024-11-27 15:04:36 yes 2024-11-27 15:09:01 ah, not I see that it is copied in the APKBUILD file 2024-11-27 15:15:19 but the build just creates a .cache/ in $PWD 2024-11-27 15:17:28 ikke: if this is a rebuild, would the $builddir/.cache still be there? 2024-11-27 15:31:04 No 2024-11-27 15:31:45 so that shouldn't be it either... 2024-11-27 15:46:00 is 3.17 considered end-of-support now, or not until 3.21 is released? 2024-11-27 15:53:13 The latter 2024-11-27 15:53:24 thanks, thought so 2024-11-27 16:09:06 omni: if you want me to check something now, I'm available 2024-11-27 16:12:03 ikke: well, I am a bit curious if there is something in ~/.cache/hare on the package builders =) 2024-11-27 16:12:31 yes, it exists 2024-11-27 16:12:42 and has some dirs in it 2024-11-27 16:13:14 thansk 2024-11-27 16:13:29 *phanx 2024-11-27 16:14:10 I think we may need to have a default HARECACHE for hare aports 2024-11-27 16:14:23 Note that, especially for arm* builder, we regularly nuke almost everything from $HOME which is not essential 2024-11-27 16:15:05 see my latest iteration of !75989 2024-11-27 16:15:42 I could try it out on the aarch64 builder 2024-11-27 16:15:50 good news is that it seems like the impact was only on tests 2024-11-27 16:17:06 hare itself was built correctly after qbe was patched and subsequent hare aports that were rebuilt with it won't need rebuilding 2024-11-27 16:17:34 after I disabled tests for hare 2024-11-27 16:18:17 omni: tests pass with that patch 2024-11-27 16:18:21 without that patch, they fail 2024-11-27 16:19:07 cool, that fits with expectations 2024-11-27 16:19:59 then I can remove the pkgrel bump 2024-11-27 16:24:04 Just to be clear, I tested it on aarch64 2024-11-27 16:24:25 I'm thinking about how how we can improve our rebuild detection, using the binary hash, to be sure to rebuild if qbe changed in bewteen. But I also think setting up XDG_CACHE_HOME to something clean on abuild would be great 2024-11-27 16:25:06 For go, we stored everything in $srcdir, so that it would be cleaned up after building 2024-11-27 16:25:14 (go-based packages) 2024-11-27 16:57:25 FYI, I've adjusted the aports CI structure a bit to use downstream pipelines, this will allow us to have more flexibility in the job config 2024-11-27 16:57:50 Let me know if you encounter anything unexpected 2024-11-27 17:06:48 export HARECACHE="${HARECACHE:-"$srcdir/hare-cache"}" 2024-11-27 17:06:51 ? 2024-11-27 17:07:08 bl4ckb0ne: ^^ 2024-11-27 17:07:26 similar to one of those that we set on many golang aports 2024-11-27 17:09:49 but yea, a global XDG_CAHE_HOME="$srcdir/cache" or something could be something 2024-11-27 19:01:43 omni: does !75989 fixes the issue? 2024-11-27 19:04:28 Don't mean to rush anyone in these busy Alpine 3.21 release times, but is there someone available to merge !75937 ? It should be ready to go and the downstream postmarketos package is merged already. 2024-11-27 19:07:03 checking 2024-11-27 19:08:00 thanks! 2024-11-27 19:09:06 \o/ 2024-11-27 19:52:31 bl4ckb0ne: yes, the issue was with the tests using an old cache, so hare built without tests should be fine and there is no rush, if you want to take your time and think about it 2024-11-27 19:52:49 ikke: tbh the new CI structure is way more cumbersome when it comes to UX of checking logs 2024-11-27 19:52:58 nah that's fine, thanks for taking care of it 2024-11-27 19:53:14 it used to be possible to just click on the icon on the MR list, and from there directly go to 'build-x86_64', for example 2024-11-27 19:53:18 ill ship it 2024-11-27 19:53:25 now it's a multi-step process of clicking through menus 2024-11-27 19:54:32 There's no way to have apk preserve edits to /usr/lib/$whatever if the package that provides it gets updated, right? The .apk-new backup thing only happens for /etc/$whatever ? 2024-11-27 19:55:07 Arnavion: there is /etc/apk/protected.d where you can add more paths that counts for 2024-11-27 19:55:56 /etc/apk/protected_paths.d* 2024-11-27 19:56:23 ptrc: Not sure what to do about it, we kind of need this for all kinds of things 2024-11-27 19:56:36 yeah, no, makes sense :P it's more of a gitlab issue, if anything 2024-11-27 19:56:44 yup 2024-11-27 19:57:03 Yes, I see it. Thanks 2024-11-27 19:57:10 It's strange it would not show a popup from the downstream pipeline 2024-11-27 19:57:14 bl4ckb0ne: HARECACHE could be set to something else, like what I wrote above, and as long as it is in $srcdir it won't survive between upgrades or rebuilds 2024-11-27 19:57:44 and HARECACHE should probably be set for hare-aports 2024-11-27 20:01:10 so we do want to share HARECACHE for all aports? 2024-11-27 20:02:06 bl4ckb0ne: no, in $srcdir, it gets removed after the aport has been built 2024-11-27 20:03:39 cache per aport, gotcha 2024-11-27 20:20:52 oh, also 2024-11-27 20:21:02 https://ptrc.gay/ZVAbDlDj 2024-11-27 20:21:16 the emails now just say that "build-jobs" failed, rather than architecture :/ 2024-11-27 20:22:00 hmm, oh that's quite anoying 2024-11-28 00:51:11 glycin-loaders (dependency of loupe) is depending on a bunch of its makedepends like pkgconfig and pc:gtk4.0. I'm guessing it's because it now contains both libglycin-gtk4-1.so and libglycin-gtk4-1.so.0 and so on. Needs a -dev subpackage? 2024-11-28 01:01:48 Well that fixes it and loupe still works, so I assume I didn't break anything 2024-11-28 07:49:32 JOIN NEW SAUCE METHODS... (full message at ) 2024-11-28 08:44:15 anyone working on nemo-qml-plugin-calendar? 2024-11-28 08:45:39 I was working on upgrading it which I hoped would help but I've been stuck on one of it's dependencies that also needed to be updated 2024-11-28 08:47:25 https://gitlab.alpinelinux.org/PureTryOut/aports/-/commits/community_nemo-qml-plugin-calendar/?ref_type=heads 2024-11-28 08:48:25 it looks like mkcal package is broken 2024-11-28 08:50:31 Cflags: -I${prefix}/_EGPF_TARGET_INCLUDE_DIRS-NOTFOUND -I${prefix}/include/mkcal-qt5 2024-11-28 08:55:18 im on it 2024-11-28 08:57:19 oh, I see that you have mkcal upgrade in your branch as well 2024-11-28 08:57:32 Yeah 2024-11-28 08:58:09 maybe we can only upgrade mkcal for now, I haven't tried that yet 2024-11-28 08:58:19 let me cherry-pick your commit 2024-11-28 08:58:32 👍️ 2024-11-28 08:59:37 updated https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76044 2024-11-28 08:59:45 i think this will bring us one step forward 2024-11-28 09:00:06 You should probably bump nemo-qml-plugin-calendar, at least to see if it builds in CI 2024-11-28 09:42:58 i cannot reproduce the problem in my dev machine 2024-11-28 09:43:00 edge is ok 2024-11-28 09:43:16 but on the 3.21 builder it fails to create the .pc file probperly 2024-11-28 09:43:19 dont know why 2024-11-28 09:43:41 build-3-21-aarch64 [~/aports/community/mkcal/src/mkcal-0.7.26]$ grep Cflags build/src/libmkcal-qt5.pc 2024-11-28 09:43:41 Cflags: -I${prefix}/_EGPF_TARGET_INCLUDE_DIRS-NOTFOUND -I${prefix}/include/mkcal-qt5 2024-11-28 09:47:36 https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/v5.47.0-rc1/modules/ECMGeneratePkgConfigFile.cmake#L159 2024-11-28 09:48:18 one of the EGPF_INCLUDE_INSTALL_DIR fails for some reason 2024-11-28 09:48:33 I wonder if it is due to some recent cmake update :-/ 2024-11-28 09:50:21 a wild guess is that this introduced it: https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/85aa50ba8193f986a8548ed144f81cc2b3f42c85 2024-11-28 09:51:56 maybe this is the fix: https://invent.kde.org/frameworks/extra-cmake-modules/-/commit/57bcb93d9676f7af24e0d73e2deba82ec3a8fb99 2024-11-28 10:00:17 Hmm, perhaps 2024-11-28 10:00:46 New frameworks release is due in a week. We should backport the patch, let's not wait on that 2024-11-28 10:01:29 I currently have a mechanic over fixing my unstable internet connection so I can't really do much atm (am working on a mobile connection currently) 2024-11-28 10:42:50 no it doesn't solve it 2024-11-28 10:43:37 i dont know what is wrong but im pretty sure the extra-make-modules is broken 2024-11-28 15:10:38 ncopa: you solved that problem for now, but now the mkcal upgrade isn't compatible with nemo-qml-plugin-calendar. As I said you should've bumped it in the PR to at least verify it builds with it 😅 It think we should downgrade mkcal again 2024-11-28 15:19:05 alright 2024-11-28 15:19:12 i think busybox awk is broken 2024-11-28 15:20:34 i think busybox awk brakes gcc cross compile 2024-11-28 15:51:42 ncopa: did adding gawk fix the template-id errors in g++-cross-embedded? 2024-11-28 15:55:01 mingw-w64-gcc had similar template-id errors, so wondering if will also fix mingw* as well 2024-11-28 16:02:19 just saw the commits, thanks for finding that! 2024-11-28 16:04:35 yes 2024-11-28 16:05:03 the problem was that the CXXFLAGS was wrong 2024-11-28 16:05:33 and xgcc ended up with wrong -std=* arg 2024-11-28 16:05:43 and fell back to -std=c++17 2024-11-28 16:05:55 which caused those template errors 2024-11-28 16:06:14 it should have been built with -std=gnu++98 2024-11-28 16:06:53 I believe some script using awk ended up setting the CXXFLAGS wrong 2024-11-28 16:07:18 so somethign is still broken in busybox awk, but I don't know what 2024-11-28 16:07:49 having any other awk implementaion installed made the build succeed. gawk, mawk, nawk 2024-11-28 16:09:19 bow im testing if that also applies to ghc 2024-11-28 16:13:17 yeah, saw it fell back to -std=c++17 but had trouble overriding it 2024-11-28 16:14:22 I was wondering what were the reasons behind disabling lto/cfi on chromium 2024-11-28 16:15:00 what does the commit message say? 2024-11-28 16:15:19 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/chromium/APKBUILD#L693 2024-11-28 16:15:46 have it ever been enabled? 2024-11-28 16:16:11 git blame / git log will tell you when it was introduced 2024-11-28 16:16:11 I don't think it was ever enabled that is why I was asking :'D 2024-11-28 16:16:46 the it was likely because because cfi was not supported back then. I dont know if it works with musl today though 2024-11-28 16:17:10 I was doing some work with getting it to compile against musl and lto+cfi 2024-11-28 16:17:24 it compiles perfectly fine but on runtime there are errors and causes a segfault 2024-11-28 16:17:40 maybe a few tweaks and extra patches could resolve this? 2024-11-28 16:17:50 possibly, i have no idea 2024-11-28 16:18:07 although I am not on alpine linux so I don't know whats the best way to help out 2024-11-28 16:19:06 I will probably just email the maintainer thanks ncopa 2024-11-28 16:28:37 Ah that timing with the upstream ECM fix haha. 2024-11-28 16:32:33 indeed :) 2024-11-28 17:01:20 alright! we are making progress! 2024-11-28 17:15:19 anjan: I did take a look, but could not find anything relevant yet 2024-11-28 17:23:59 the greetd-phrog MR looks ready to go !75971 2024-11-28 17:25:23 It fixes the build for sure, but let's hope they didn't hardcode the version upstream for a good reason... 2024-11-28 17:58:45 i wonder if I should just merge the ghc update. it passes on my machine 2024-11-28 18:04:53 or host on alpine..sw/~ncopa/ for testing 2024-11-28 18:19:01 worth a shot, maybe it also fixes git-annex 2024-11-28 19:20:51 Are there any intention to offer debuginfod endpoint for main+community alpine packages? 2024-11-28 19:21:01 or just *-dbg 2024-11-28 20:21:17 caskd: theres been some discussion about it: https://gitlab.alpinelinux.org/alpine/aports/-/issues/10603 2024-11-28 20:21:56 but fwiw i'd be totally down 2024-11-28 20:27:10 i do agree with the concerns but i think dbg should be a optional build component 2024-11-28 20:27:35 like every package that can have it should have it in the APKBUILD BUT- not be built by default 2024-11-28 20:29:07 so something like default_dbg only being present on DEBUG=1 2024-11-28 20:29:14 only running* 2024-11-28 20:29:32 the idea with edge only containing dbg also sounds cool 2024-11-28 20:29:54 as edge is huge and people on thin storage limits would probably mirror only last 4 stables 2024-11-28 20:30:57 i was asking this as right now i want to collect traces for community/ceph18 but without debug symbols they are meaningless 2024-11-28 20:31:02 so i am rebuilding it 2024-11-28 20:31:11 but the original package had no -dbg 2024-11-29 04:56:38 ikke: can you please try this aport? It works locally https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76096#dd1140ddc6cbb1e1275ccc626419e28395cec97f 2024-11-29 04:57:02 I got the same error as the build machine and I fixed it by using this aport... 2024-11-29 06:05:24 anjan: seems to work 2024-11-29 06:05:38 ikke: yay! 2024-11-29 06:05:47 please merge when u can 2024-11-29 06:42:27 anjan: passed now on the builders 2024-11-29 09:56:56 build-3-21-riscv64 is done! 2024-11-29 10:01:12 only ~25 pkgs left for x86_64 2024-11-29 10:49:46 oh wow! good work 2024-11-29 11:18:14 ikke: 🎆 thank you!! 2024-11-29 14:15:41 got other clue about the broken busybox awk 2024-11-29 14:15:56 https://github.com/raspberrypi/linux/issues/6503#issuecomment-2507879882 2024-11-29 15:06:29 ncopa: I had to add gawk as a dependency for rset after busybox was upgraded to 1.37 !73866 2024-11-29 15:08:20 but I missed nmeums comment after I merged it 2024-11-29 15:18:54 ikke: it seems like pipeline views have the topic of the last commit subject, not of the MR 2024-11-29 16:49:04 ncopa: i only saw 356b5ee0 after i had found the fix that led to !76111, sorry i didn't get to it sooner 2024-11-29 16:52:15 im cheating with deno. im skipping the tests so package gets built 2024-11-29 16:52:46 j_v: thanks! 2024-11-29 16:53:34 should i work on imageflow? or leave it until after release? 2024-11-29 16:54:18 whatever you prefer 2024-11-29 16:54:39 ok, will give it a try 2024-11-29 17:07:15 used a flag for now, haven't found patches yet !76110 2024-11-29 17:08:35 was going to report the issue upstream 2024-11-29 17:55:07 do we dare upgrade apk-tools at this point? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74317#note_460798 2024-11-29 17:56:16 fabled did revert some commits today 2024-11-29 17:57:00 ok, also for 2.x branch? 2024-11-29 17:57:23 ah, no 2024-11-29 18:00:23 i have used apk-tools 2.14.5 since then 2024-11-29 18:00:26 i think it should be ok 2024-11-29 18:03:15 im merging it... 2024-11-29 18:22:01 ncopa: ok for @chereskata to take over gnome-passwordsafe? 2024-11-29 18:23:59 3.21 uploading! congrats! 2024-11-29 18:24:54 w00t 2024-11-29 18:25:05 uploading! 2024-11-29 18:25:10 finally! 2024-11-29 18:25:19 yay! 2024-11-29 18:25:48 i should tag rc1 now, but im tired and its soon weekend 2024-11-29 18:27:11 no worries 2024-11-29 18:29:15 ncopa: could you ack !72080? 2024-11-29 18:31:34 approved 2024-11-29 18:31:46 need to make mkinitfs release as well 2024-11-29 18:31:50 ncopa: thanks 2024-11-29 18:35:44 >>> mkimage-x86_64: --> kernel x86_64 lts b8686053840d00e1ba7826f1cbd652a9d922e41d linux-lts linux-firmware wireless-regdb xtables-addons-lts 2024-11-29 18:35:44 1% ## Segmentation fault 2024-11-29 18:35:50 something is broken 2024-11-29 18:35:58 ouch 2024-11-29 18:36:19 Core was generated by `apk add --quiet --cache-dir /etc/apk/cache -p /tmp/update-kernel.RYZrQ3/root --'. 2024-11-29 18:36:32 never a dull moment in apk updates 2024-11-29 18:46:28 ncopa: you have backtrace? 2024-11-29 18:46:55 Or the exact command line to reproduce? 2024-11-29 19:19:25 ncopa: seems to be update-kernel using fakeroot+apk 2024-11-29 19:31:34 backtrace here: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11044 2024-11-29 19:31:52 it happened when I tried to build a test boot iso 2024-11-29 19:32:01 is there a file transfer limit for busybox's cp ?, i am getting 11.7Gb limit hit, tried twice 2024-11-29 19:32:21 $ tpaste < mkrelease.sh 2024-11-29 19:32:21 https://tpaste.us/yBpk 2024-11-29 19:32:47 will try with different disk, this was internal ssd -> usb-adapter(m.2 ssd) 2024-11-29 19:33:18 even wget give same limit 2024-11-29 19:33:38 vkrishn: what happens after you reach that limit? 2024-11-29 19:34:50 ncopa: i think i know whats going on 2024-11-29 19:35:09 wget error out 2024-11-29 19:35:13 apparently it's usage of fakeroot + sharing the non-writable main cache-dir 2024-11-29 19:35:15 what error? 2024-11-29 19:35:27 cp uhmm, forgot, let me see shell history 2024-11-29 19:40:10 ncopa: https://git.alpinelinux.org/apk-tools/commit/?id=167c154800b7 should fix it 2024-11-29 19:41:42 this is from busybox-extra httpd running on internal ssd and fetch by busybox wget, https://tpaste.us/YqEM 2024-11-29 19:42:00 re-started cp, will get back with its error 2024-11-29 19:42:36 note, creating a 32GB file on m.2 with dd is ok 2024-11-29 19:43:08 mounting that file and rsync'ing it to full using busybox rsync went ok 2024-11-29 19:43:20 Sounds like disk issues? 2024-11-29 19:43:41 no, just did full 32Gb rsync transfer 2024-11-29 19:44:03 small file transfer goes ok 2024-11-29 19:44:09 fabled: thanks, but i dont think it does 2024-11-29 19:44:17 also reverting to 2.14.4 does not seem to help 2024-11-29 19:44:23 i dunnot what wrong today 2024-11-29 19:44:27 will try with other disk, report back 2024-11-29 19:46:10 ncopa: how did you test? 2024-11-29 19:46:16 it solves it for me 2024-11-29 19:46:23 oh no 2024-11-29 19:46:26 there's another segfault 2024-11-29 19:52:10 probable ntfs issue, been noticing it on alv3.18.3 , as it has a 32GB ext3 file on it 2024-11-29 19:52:33 mounting and rsyncing it works 2024-11-29 19:52:47 copying it fails at 11.7Gb 2024-11-29 19:53:29 retrying with another 32Gb file 2024-11-29 19:56:30 very likely ntfs3 issue, sadly can;t do away with it, will try to reduce the windows partition (to os required) 2024-11-29 20:01:06 well, i finally managed to get imageflow to build, but it's git tip, so maybe leaving it disabled until someone with more rust knowledge than myself can do better 2024-11-29 20:01:35 fabled: apparently the aarch64 apk does not segfault? 2024-11-29 20:01:45 i know the other issue now 2024-11-29 20:01:49 ok 2024-11-29 20:01:52 it depeneds whether all the packages needed are in cache or not 2024-11-29 20:02:14 so if I disable the cache it will pass? 2024-11-29 20:02:30 seems i messed up the backport of the verify patch. the _tee function was more brittle than expected, and it works differently in the master branch 2024-11-29 20:02:36 i'll have a fix in a momemnt 2024-11-29 20:03:45 ikke: thank, its ntfs issue, fsck runs ok on that file 2024-11-29 20:03:55 disabling the cache indeed makes it work 2024-11-29 20:04:55 coz, cp of another 32Gb file now at 15GB+ 2024-11-29 20:05:51 actually, i think this path is probably broken in older releases too 2024-11-29 20:08:02 will upgrade to v3.21 when released and recheck with ntfs3 module 2024-11-29 20:10:48 fabled: I think you're right. i tdidnt help to revert to 2.14.4 2024-11-29 20:16:14 ncopa: i'm testing now https://tpaste.us/5QnE and will probably commit that soon 2024-11-29 20:17:39 no stress, i have a work around 2024-11-29 20:17:51 im fightin mkinitfs 2024-11-29 20:30:39 ncopa: pushed now with few additional fixes 2024-11-29 20:30:46 i should probably tag a new stable release while at it 2024-11-29 20:32:06 done 2024-11-29 20:33:03 thanks 2024-11-29 20:33:32 i wonder whats wrong with initrmfs. now it complains that nlplug-findfs is missing 2024-11-29 20:34:14 When building or when generatoring an image? 2024-11-29 20:34:24 when booting the cdrom 2024-11-29 20:34:32 the strange thing is that it booed once 2024-11-29 20:35:30 oh ofc 2024-11-29 20:35:34 not enough mem 2024-11-29 20:36:04 it does not boot with 256MB 2024-11-29 20:36:25 ncopa: thanks for all the work you're doing! i know its not easy, but you rock! 2024-11-29 20:36:44 thanks! 2024-11-29 20:38:24 i just want get this -rc1 out the door 2024-11-29 20:40:53 256MB mem boot error was something i noticed way back in v3.12, or was it v3.9, even qemu did not boot with 128M after v3.9 2024-11-29 20:41:17 yeah, i just forgot -m 1024 2024-11-29 20:41:39 im past the stage when i do too much stupid mistakes. i should really rest 2024-11-29 20:42:07 512Mb kinda works 2024-11-29 20:45:22 would it be okay to bump firefox-esr now? would block the builders for about an hour 2024-11-29 20:46:44 Maybe wait for the -rc to be tagged 2024-11-29 20:47:02 rc2 got tagged a moment ago 2024-11-29 20:47:09 mkinitfs 2024-11-29 20:47:14 unless that's not what you mean 2024-11-29 20:47:20 mkinitfs? 2024-11-29 20:47:35 alpine/mkinitfs:master | Natanael Copa | ==== release 3.11.0_rc2 ==== 2024-11-29 20:47:39 ahh 2024-11-29 20:47:43 right 2024-11-29 20:49:38 yeah, please hold it for a few more mins 2024-11-29 20:51:10 i think everything is ready for -rc1 2024-11-29 20:52:15 just want doublecheck that nothing breaks in the release script 2024-11-29 20:53:29 fabled: thank you very much! 2024-11-29 20:56:50 ok. it passed 2024-11-29 20:56:57 im tagging 3.21.0_rc1 now 2024-11-29 20:58:07 here we go... 2024-11-29 20:58:15 Nice 2024-11-29 20:58:20 🎉 2024-11-29 20:58:52 🎉 2024-11-29 20:58:59 🎉 2024-11-29 20:59:19 \o/ 2024-11-29 20:59:25 \o/ 2024-11-29 20:59:28 🎆 2024-11-29 20:59:32 \o/ 2024-11-29 20:59:33 ncopa: thanks a lot for your work on this! 2024-11-29 20:59:44 mio: likewise! i couldnt done it without you 2024-11-29 21:00:41 just pitching a bit, it's a group effort too. shoutout to the infra team for keeping the builders going 2024-11-29 21:00:52 oh yeah! 2024-11-29 21:01:05 they are doing amazing work 2024-11-29 21:01:28 ptrc: I suppose the builder-bumper script can be stopped now too 2024-11-29 21:01:37 oh yeah, you're right 2024-11-29 21:02:14 btw, i have also added a new name for dl-cdn 2024-11-29 21:02:32 https://cdn.alpinelinux.org/v3.21/main 2024-11-29 21:02:49 equals https://dl-cdn.alpinelinux.org/alpine/v3.21/main 2024-11-29 21:02:53 just shorter url 2024-11-29 21:03:06 ooh, nice 2024-11-29 21:03:20 though i feel like cdn. might lead to some confusion at some point 2024-11-29 21:03:30 ( over something like "mirror." ) 2024-11-29 21:03:33 still need a small change in fastly config so it shares the same backend 2024-11-29 21:03:46 you think cdn will create confusion? 2024-11-29 21:03:50 how so? 2024-11-29 21:04:53 dunno, it's mostly that usually i've seen subdomains like that be used for website assets and other things 2024-11-29 21:04:56 rather than packages 2024-11-29 21:05:45 though it might be just me :p 2024-11-29 21:06:03 the rc1 was successful! 2024-11-29 21:06:11 too bad its too late for beer now 2024-11-29 21:06:16 worth celebrate 2024-11-29 21:06:51 ptrc: feel free to push whatever now 2024-11-29 21:07:01 thank you for asking before you merged 2024-11-29 21:07:09 alrighty, though i'll wait for CI to finish ^^ 2024-11-29 21:08:55 lets do the release notes and release next week 2024-11-29 21:10:46 https://fosstodon.org/deck/@alpinelinux/113568293880729433 2024-11-29 21:10:49 i agree, i'd guess that mirror is a more common subdomain for packages and stuff, but having cdn already and the not the alpine subdir is already great. 2024-11-29 21:11:30 Heck yeah 3.21-rc1! It has been an uphill battle. Super excited to see it cross the finish line! 2024-11-29 21:12:02 thanks everyone who tiredlessly has helped get it this far 2024-11-29 21:12:16 its insane the amount of work that has been done 2024-11-29 21:13:17 Absolutely 2024-11-29 21:13:24 oh yeah, hope nobody burnt out during the builds 2024-11-29 21:15:13 Probably not a discussion for right this minute, but maybe it's worth going over what slowed this release cycle down and see if there's anything we can collectively do to prevent it going forward. 2024-11-29 21:15:33 It seemed like we gotten eaten up by tons of little issues that prevented us from addressing the larger ones. 2024-11-29 21:15:50 s/gotten/got/ 2024-11-29 21:19:42 yeah. i think it was mostly due to gcc 14 being more picky, and llvm, rust and go slowly becoming more and more work to maintain 2024-11-29 21:19:49 rust/go apps 2024-11-29 21:20:07 same with python packages 2024-11-29 21:20:18 Everything becomes more and more rigid 2024-11-29 21:20:23 yeah 2024-11-29 21:20:36 and eats more and more space 2024-11-29 21:20:45 100M here and 100M there 2024-11-29 21:21:09 then you multiply with thousands of packages, 5 branches and 8 architectures 2024-11-29 21:21:54 and we are not able to pay off the tech dept we are collecting 2024-11-29 21:22:58 Can we default on our debt? 2024-11-29 21:24:23 i suppose shut down alpinelinux.org and tell everyone use debian would work :) 2024-11-29 21:24:35 but now its weekend 2024-11-29 21:24:54 thank you everyone for all the hard work, and for helping 2024-11-29 21:25:03 and for being nice people 2024-11-29 21:25:12 have a nice weekend! 2024-11-29 21:25:23 You too 2024-11-29 21:27:21 omni: do you have an example (re pipeline titles)? 2024-11-29 21:38:36 ikke: https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/276550 2024-11-29 21:39:09 from !76105 2024-11-30 00:23:14 ok, I have a regression 2024-11-30 00:24:08 I rebooted for the first time in one or two days (perhaps?) and instead of getting a prompt for disk passphrase, I got a segfault and was dropped to a shell 2024-11-30 00:25:43 when I then unlocked the disk with cryptsetup and imported the zpool and mounted the zfs data sets, and then exited the shell, it failed on me 2024-11-30 00:26:47 don't remember exactly how and didn't take a picture, but some busybox message about switching root, I think, it rebooted soon after 2024-11-30 00:28:07 I then, instead, next time I ended up in the emergency shell, rolled back the rootfs dataset to latest snapshot and here I am 2024-11-30 00:38:47 ok, so the snapshot is from a couple of hours into the 26th, and I had all (edge) packages up-to-date, so something somewhere after that 2024-11-30 00:39:21 maybe it's as easy as mkinitfs 3.11.0_rc2 2024-11-30 00:39:33 I could try upgrading everything except that 2024-11-30 00:57:35 ok, that was it, mkinitfs=3.10.2-r1 and all other packages at their latest and I get to enter the passphrase and boot as usual 2024-11-30 00:57:39 ncopa: ^^ 2024-11-30 01:11:26 is there a good way of keeping up with the releases for packages one maintains? I only have a few, but "hope the project has an RSS feed for releases" is getting unsustainable. 2024-11-30 01:19:32 elagost: I use rss/atom feeds for projects o almost all of the aports I maintain, just a few don't have any, most are on github or gitlabs and those have feeds 2024-11-30 01:21:21 there's also repology.org and a few others, don't follow any feeds from there 2024-11-30 01:25:38 and there's https://pkgs.alpinelinux.org/packages?flagged=yes 2024-11-30 01:28:08 omni: thanks, I'll see about repology, probably going to have to re evaluate having a separate config for my rss reader for just the software releases. 2024-11-30 02:08:18 I have also upgraded a couple of 3.20 VMs to 3.21_rc1, and they seem to work fine 2024-11-30 02:08:45 only that I get 25 lines of: 2024-11-30 02:08:47 mdev: unknown user/group 'root:uucp' on line 53 2024-11-30 02:09:18 before 2024-11-30 02:09:20 OpenRC 0.55.1 is starting up Linux 6.12.1-1-virt (x86_64) [XENU] 2024-11-30 04:28:21 Heads up, on edge the initramfs generation seems to be broken / results into segmentation fault on reboot 2024-11-30 04:28:29 Ah, already known 2024-11-30 04:32:01 telmich: I created this issue https://gitlab.alpinelinux.org/alpine/mkinitfs/-/issues/75 you could add to it, if you have additional information 2024-11-30 04:32:46 and also give a heads-up in #alpine-linux, if you want 2024-11-30 07:51:56 omni: can you please test if mkinitfs-3.11.0_rc3 works? 2024-11-30 08:09:58 i think we should refactor the release process 2024-11-30 08:10:21 how the release images are generated 2024-11-30 08:10:23 and from where 2024-11-30 10:37:59 ncopa: mkinitfs-3.11.0_rc3-r0 works 👍 2024-11-30 13:35:22 mkinitfs-3.11.0_rc3-r0 working here as well, updated a few machines (all cryptsetup,cryptkey,nvme,lvm,etc,et al) 2024-11-30 13:37:31 just created qemu vim with 3.21.0_rc1 iso, crypt root, mkinitfs-3.11.0_rc3-r0 working 2024-11-30 13:39:57 i don't have a syslinux install to test anymore, though. :( 2024-11-30 13:42:31 smh at my own typs... not sure what a qemu vim is, but i meant vm 2024-11-30 13:42:41 typo*s 2024-11-30 13:44:05 It's a rule that you must mistype typo after you made a typo 2024-11-30 13:51:26 yep, and it got me again 2024-11-30 19:11:29 could CI run for this #76156 ? if works it should be backported at least for 3.21 2024-11-30 19:13:20 i wanted to run CI for download the artifact and test locally, it will take huge time here and need to prepare a x86 build env first (only interested on x86) 2024-11-30 19:14:18 donoban: There is no need yet to backport for 3.21 2024-11-30 19:14:32 it still tracks master up until it's actually releassded 2024-11-30 19:15:18 ah ok 2024-11-30 19:15:51 and a 3.21-stable branch has been forked from master 2024-11-30 19:16:34 !76156 2024-11-30 19:17:00 wops yep 2024-11-30 19:17:09 donoban: You need to bump pkgrel 2024-11-30 19:17:15 ahh ouch 2024-11-30 19:17:22 without a change to an APKBUILD file, it will not build the package 2024-11-30 19:17:33 better if disable other archs until final version? 2024-11-30 19:17:53 oh, and the patch also needs to be included in the source ofcourse 2024-11-30 19:18:43 yeah sorry, i did both things 2024-11-30 19:18:51 but didn't commit before pushing 2024-11-30 19:18:54 :) 2024-11-30 19:19:03 :) 2024-11-30 21:43:23 ayakael: I missed that the contents (and checksum) of git-annex-10.20241031-edge.cabal had changed, it is now failing on the builders because they use the cached version of that file 2024-11-30 21:46:46 omni: I can rename / remove that file 2024-11-30 21:47:59 ikke: oh, that would work 2024-11-30 21:48:49 but we don't want to make it a habit/expectation of that option being available, do we? 2024-11-30 21:49:38 ideally the filename would change 2024-11-30 21:49:56 yes 2024-11-30 21:51:31 I'm a bit too tired to look at if that file could easily have another name, and I should also go and do some other things 2024-11-30 22:28:31 Danct12: I upgraded the wayfire packages, since you're the original maintainer you may want to take a look (and ideally, test): https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76171