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.