2024-12-01 14:20:48 i dunno what's going on with librewolf these days. https://codeberg.org/librewolf/issues/issues/2144 2024-12-01 15:54:32 omni: thanks for all of my MR you merged. Would you be kind enough to give also a look on !73153 please? 2024-12-01 16:05:00 sure 2024-12-01 16:17:05 raspbeguy: I added a comment on the use of build time timestamp in the package, may be something we'd want to have a bit more static than that 2024-12-01 16:23:41 $SOURCE_DATE_EPOCH 2024-12-01 16:47:59 omni: thanks. I'll have a look later. 2024-12-01 17:24:32 mesa 24.3.1 will get released 2024/12/04, would it fit into Alpine 3.21? At least it would be Mesa with support, where 24.2 is EOL now 2024-12-01 17:30:22 So far tests are green for 24.3.0, and it'll bring OpenCL support for Adreno GPUs (guarded by env var), which could be pretty much useful in 3.21 cycle for phones/tablets for camera processing 2024-12-01 18:00:26 it's it'll be included in 3.21, i hope that .1 won't have that many regressions 2024-12-01 22:59:35 seems like abuild -r does git rev-list, and it gets lsow 2024-12-01 23:01:17 slow* 2024-12-02 04:51:05 if i want to run abuild locally with limited bandwidth for fetching deps, is there some setting I need to make so dep apk's get cached between runs? 2024-12-02 05:04:42 dalias: create a symlink from/etc/apk/cache to some directory 2024-12-02 05:06:20 ikke, what does that do? 2024-12-02 05:06:47 if /etc/apk/cache exists, the cached apks get saved there? 2024-12-02 05:06:54 does it work with rootbld? 2024-12-02 05:08:18 i suspect i need to do something different to use rootbld 2024-12-02 05:29:29 dalias, it seems to be documented by apk-cache(5) 2024-12-02 05:31:08 ok, looking 2024-12-02 05:32:40 where? 2024-12-02 05:33:23 that doesnt have anything about rootbld usage 2024-12-02 05:35:01 It has to do with your questoin about what it does 2024-12-02 05:44:24 ok 2024-12-02 05:44:36 yes tha thelps 2024-12-02 05:44:46 but practical conern is getting abuild rootbld to use it 2024-12-02 05:58:22 dalias, in the source (abuild.in), in rootbld(), it does: local qarch cachedir=/etc/apk/cache 2024-12-02 05:58:27 It seems to use it automatically 2024-12-02 05:59:31 (then calls apk add with ${cachedir:+--cache-dir $cachedir}) 2024-12-02 06:01:39 but if it's not writabel that wouldnt work 2024-12-02 09:12:16 https://ptrc.gay/duuOIRpz 2024-12-02 09:12:27 lol 2024-12-02 09:14:31 ah. funny failure state - installing apk-tools from just `doas make install` in git directory places the library in /lib 2024-12-02 09:14:45 which is more important than the one from the package in /usr/lib 2024-12-02 09:15:14 so then, doing `apk fix --reinstall apk-tools` would affect the library 2024-12-02 09:15:39 usrmerge would have avoided this :') 2024-12-02 10:48:21 I see the pipelines are looking different 2024-12-02 10:48:50 I've setup downstream pipelines 2024-12-02 10:49:05 Allowing us to dynamically generate ci config 2024-12-02 14:19:32 I just updated kernel and have zfs module crashes (edge/amd64) 2024-12-02 14:19:50 memcpy: detected field-spanning write (size 12) of single field "lr + 1" at /home/buildozer/aports/main/zfs-lts/src/6.12.1-2-lts/module/zfs/zfs_log.c:425 (size 0) 2024-12-02 14:19:57 Is that already known? 2024-12-02 14:20:49 quinq: i haven't seen reports about it 2024-12-02 14:22:02 https://github.com/openzfs/zfs/issues/16621 2024-12-02 14:22:22 looks like the last ZFS release doesn't support 6.11 or 6.12 2024-12-02 14:23:50 Thank you sam_ 2024-12-02 14:23:54 np 2024-12-02 14:24:26 “it's not a defect, rather a false positive in the kernel memory checker” ok 2024-12-02 14:47:42 I forgot that my lounge instance was still working, so looking back on the last *checks note* 4 months of messages. 2024-12-02 14:49:05 ncopa: dotnet6 was moved to testing while packages maintained by fabricionaweb moved to dotnet8. I'm planning to delete it once that's done. 2024-12-02 14:53:06 quinq: as far the issue you brought up on the 27th of september is concerned, I've made it easier for developpers to audit my tarballs for dotnet6 (and zotero, signal-desktop, electron, incidently) by having these tarballs generated using Forgejo Action workflows. Thus, it is easy enough to go check the logs for that workflow. Ideally, I'd like to 2024-12-02 14:53:06 be able to use Alpine's GitLab for generating and storing tarballs as a generic package, but alas it would use up space that I don't think if available. 2024-12-02 14:54:05 is available* 2024-12-02 14:56:03 PureTryOut: dotnet packages implemented a bootstrapping workflow that does exactly what you want, based on https://lists.alpinelinux.org/~alpine/devel/%3C33KG0XO61I4IL.2Z7RTAZ5J3SY6%408pit.net%3E 2024-12-02 14:59:12 The gist is that there's a `stage0` package that handles the bootstrapping. The package sets `provides=package-bootstrap=1.0.0-r0` and `provider-priority=1`. The main package needing bootstrapping can then also `provides=package-bootstrap=1.0.0-r0` but `provider-priority=100`. 2024-12-02 15:00:36 ayakael: yeah, at the moment our space for artifacts is quite limited 2024-12-02 15:01:42 I have ideas to change it, but nothing concrete yet 2024-12-02 15:03:39 I've been quite happy with my setup, so no rush on my side. Still about 6TB left for electron tarballs, so a whole year of releases! 2024-12-02 15:05:28 Another bonus with using workflows / CI is that it's all automated. I highly recommend other maintainers adopt the approach. 2024-12-02 15:08:08 For what exactly? 2024-12-02 15:10:40 The 6TB for electron was a joke. When compressed it's more like 2GB, but crazy big regardless. 2024-12-02 15:15:51 I meant the workflow / CI pary 2024-12-02 15:15:55 Part* 2024-12-02 15:23:29 Oh I see. Basically, a new release of, say, electron, automatically triggers a workflow on my Forgejo instance that generates the tarball, and compresses it an ungodly amount using xz and all of my homelab's cores. 2024-12-02 15:23:48 Thus, I don't have to manually do `abuild snapshot` and upload the artifacts from my laptop. 2024-12-02 15:28:08 Right, so only if you manually need to create source tarbals 2024-12-02 15:38:21 Yeah, which happens rarely, as forgejo workflows allows you to input arguments when manually triggering a workflow. This make the process automatic and auditable. Which means if TSC eventually created a rule requiring upstream tarballs, it could offer an exception by allowing usage of Alpine's GitLab and CI to generate auditable tarballs. 2024-12-02 15:39:26 I could write-up a proposal if y'all would like. 2024-12-02 15:39:31 (for TSC) 2024-12-02 16:54:43 im gonna tag rc2 now. too bad I wasn't able to update the rpi kernel yet 2024-12-02 17:08:11 quinq: there's been an increase of "not a bug" responses upstream to ... bugs. it's the new way of saying WONTFIX 2024-12-02 17:52:58 invoked, apparently that's been fixed already, just waiting for a release 2024-12-02 17:53:22 I haven't looked into the details though, just trusting them on their words (fatal error) 2024-12-02 18:33:24 Trying to enable shotcut on aarch64 again, it fails with: 'openglvideowidget.cpp:24:10: fatal error: QOpenGLFunctions_1_1: No such file or directory' ' 24 | #include '. Any idea why it cannot find that? 2024-12-02 19:44:31 fcolista: i wonder if you could help with creating a PR for osinfo db for alpine 3.21 2024-12-02 19:44:55 we could probably also add loongarch64 to the list 2024-12-02 21:08:55 recently started getting a crash in apk_sign_ctx_init when doing apk cache sync -a, known thing or worth investigating? 2024-12-02 21:09:15 ovf: Haven't heard about that yet 2024-12-02 21:12:02 ikke: cool, i'll take a look but here's an x86_64 core file for anyone who's also curious: https://0x0.st/X7ZG.core.zst 2024-12-02 21:20:08 my informed gut feeling points towards https://gitlab.alpinelinux.org/alpine/apk-tools/-/commit/be292bd5052276bc8ef7bbad22ce40f8882efa5f 2024-12-02 21:21:01 Please report it on https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues 2024-12-02 21:21:03 looks like this was first released in 2.14.5 which was pulled in (together with 2.14.6) on 29th of november, which feels about right timeframe wise for the crash 2024-12-02 21:47:00 can y'all tell me of your experiences with the riscv builder so far 2024-12-02 21:47:05 you have the milkv pioneer thing right 2024-12-02 21:47:09 for alpine builds 2024-12-02 21:47:31 what's the policy for header only libs? should the `-dev` dependency be listed in `depends` ? 2024-12-02 21:47:31 i'm thinking of grabbing one for chimera after all since our qemu-user builds are super annoyingly slow 2024-12-02 21:47:35 q66: so far, it hasn't been very stable 2024-12-02 21:47:42 what does that mean 2024-12-02 21:47:47 i'm also mostly interested about the performance 2024-12-02 21:48:20 Not sure if it's the specific SSD that's used, but there were hangs and even some filesystem corruption 2024-12-02 21:48:29 i did llvm 18->19 + rust 1.83 batch + necessary revdeps a couple days back, riscv64 has been going 55 hours and counting https://build.chimera-linux.org/#/builders/3/builds/1188 2024-12-02 21:48:46 Yeah, it's still our slowest architecture 2024-12-02 21:48:47 the second slowest builder (ppc64, 16vcore vm at osuosl power9) took "only" 10 hours for that 2024-12-02 21:49:38 the fastest ones (x86_64 which is some hetzner ryzen, and ppc64le which is my own colocated baremetal power9 box) took around 6hrs... 2024-12-02 21:50:37 i'd be happy if i could cut that down to like 20 hours or something 2024-12-02 21:50:40 q66: llvm19 build: https://build.alpinelinux.org/buildlogs/build-3-21-riscv64/main/llvm19/llvm19-19.1.4-r0.log 2024-12-02 21:50:56 but do you have any numbers relative to some other arch 2024-12-02 21:51:05 >>> llvm19: Build complete at Fri, 22 Nov 2024 08:18:02 +0000 elapsed time 2h 11m 14s 2024-12-02 21:51:08 fmt CI build: https://gitlab.alpinelinux.org/a16bitsysop/aports/-/pipelines/276076 2024-12-02 21:51:39 ncopa: if that's complete that's pretty good 2024-12-02 21:51:39 aarch64: >>> llvm19: Build complete at Wed, 20 Nov 2024 13:08:11 +0000 elapsed time 0h 18m 17s 2024-12-02 21:51:44 oh, so it's not 2024-12-02 21:51:51 what's the aarch64 hw? 2024-12-02 21:52:00 aarch64 is probably our fastest 2024-12-02 21:52:06 ampere altera i think? 2024-12-02 21:52:08 Yes 2024-12-02 21:52:11 But CI is a VM 2024-12-02 21:52:23 well i guess it would still be faster than what i have 2024-12-02 21:52:25 80 cores 2024-12-02 21:52:42 80 core altra is my main workstation 2024-12-02 21:52:43 it's really fast 2024-12-02 21:53:02 ppc64le: >>> llvm19: Build complete at Wed, 20 Nov 2024 12:20:41 +0000 elapsed time 0h 37m 37s 2024-12-02 21:53:05 so a riscv thing taking 6 times longer is fine 2024-12-02 21:53:13 or 7 2024-12-02 21:53:17 altra is amazingly fast 2024-12-02 21:53:23 too bad it has a broken pcie 2024-12-02 21:53:40 making gpus a pain on it 2024-12-02 21:54:06 i carry patches for it in our kernels but it's still janky as hell 2024-12-02 21:54:54 hm well i'll think about it 2024-12-02 21:54:55 i won 2024-12-02 21:54:58 won't buy anything now 2024-12-02 21:55:09 because if i did it would not arrive before i leave for vacation regardless 2024-12-02 21:55:22 i just got a hifive riscv64 p550 board 2024-12-02 21:55:29 that actually came out? 2024-12-02 21:55:32 which is marketed as the fastest something 2024-12-02 21:55:34 yup 2024-12-02 21:55:40 i have it on my desk right here 2024-12-02 21:55:44 i have strong doubts it's faster than the milkv thing 2024-12-02 21:55:58 https://fosstodon.org/@ncopa/113555469066695492 2024-12-02 21:56:02 i dont think it is 2024-12-02 21:56:05 it should be faster than hifive unmatched, but i wouldn't expect any more than rpi4 tier performance out of it 2024-12-02 21:56:07 its only quad core 2024-12-02 21:56:21 the k1x is octacore 2024-12-02 21:56:29 have a bpi3 here as well 2024-12-02 21:56:53 i bought the case for the p550, and got it earlier today. but its *huge* 2024-12-02 21:56:59 isn't it mini itx 2024-12-02 21:57:14 mini dtx, so slightly bigger than mini itx 2024-12-02 21:57:17 what's the k1x performance like? 2024-12-02 21:57:32 we th k1x in our CI 2024-12-02 21:58:09 https://gitlab.alpinelinux.org/admin/runners/209#/jobs 2024-12-02 21:58:10 i don't care about rvv at all ftr because we won't build with rvv anyway 2024-12-02 21:58:19 ncopa: that link is not public :P 2024-12-02 21:58:26 oh .. ok 2024-12-02 22:01:53 looks like the pioneer singlethread performance is slightly lower than pi4 singlecore performance from what i can find 2024-12-02 22:02:03 which is... not bad 2024-12-02 22:02:19 that sounds about right 2024-12-02 22:02:43 with 64 cores of those it does get the job done eventually 2024-12-02 22:02:54 right, the question is, how fast are the cores in the octacore one 2024-12-02 22:03:39 they are not 8x faster than the milkv 2024-12-02 22:04:00 well of course 2024-12-02 22:04:07 but still 2024-12-02 22:04:23 i dont have exact numbers 2024-12-02 22:04:57 the pioneer is quite expensive so i'm just wondering if it's worth spending 3k on 2024-12-02 22:05:07 oof, so expensive? 2024-12-02 22:05:13 it is 2024-12-02 22:05:15 well the whole box is 2024-12-02 22:05:19 the board alone is like 1.2k 2024-12-02 22:05:27 all that is without vat 2024-12-02 22:05:39 https://www.mouser.es/c/embedded-solutions/computing/single-board-computers/?m=Milk-V&series=Milk-V%20Pioneer 2024-12-02 22:05:46 1.4k for board 2024-12-02 22:05:53 2.3k for box 2024-12-02 22:06:00 probably makes more sense to just get the box 2024-12-02 22:06:25 since it comes with 128G RAM and a case and an SSD 2024-12-02 22:06:45 add 21% VAT to the price 2024-12-02 22:07:31 they're MILKing you for the money! 2024-12-02 22:09:32 for what it is, it's not a bad price really 2024-12-02 22:09:38 or well, not terrible 2024-12-02 22:09:50 but it's still quite expensive 2024-12-02 22:10:06 just joking 2024-12-03 01:11:58 nmeum, ncopa: !76289 adds gawk to makedepends and the commit message has a comment on why the busbox awk doesn't cut it 2024-12-03 01:20:43 not sure what I think of commit messages like these !76290 2024-12-03 01:21:12 beacause it's less searchable, and I think this one is also a bit long for a commit message 2024-12-03 01:22:09 I'm super fine with the style in merge reqest subjects, though, and often use it myself 2024-12-03 01:22:35 and I may just have to get over it? 2024-12-03 01:27:06 s/get/git/ 2024-12-03 01:27:18 heh 2024-12-03 02:04:10 proycon: can you take over the packages and maintain them? 2024-12-03 07:37:46 sure ncopa 2024-12-03 07:45:25 thanks! 2024-12-03 07:54:07 ok to get the osinfo-db merged upstream i need to generate the sha256sum of the iso, as well as putting in the xml file the release date and the eol date 2024-12-03 07:54:43 for loongarch, which flavor are we going to release? 2024-12-03 07:54:54 standard/virtual/extended ? 2024-12-03 07:58:01 only standard 2024-12-03 07:58:03 for now 2024-12-03 07:58:36 ok, so we cannot use the release candidates in the osinfo-db? 2024-12-03 07:58:49 oh, ok 2024-12-03 07:58:56 yes, i think so 2024-12-03 07:59:06 what about the release/eol date then? 2024-12-03 07:59:09 the iso yes 2024-12-03 07:59:42 the release date is on thursday (or tomorrow if possible) 2024-12-03 07:59:55 EOL is 1 Nov 2026 2024-12-03 08:00:01 ok 2024-12-03 08:00:11 I would put thursday 2024-12-03 08:00:21 sounds good 2024-12-03 08:00:23 in case I make another commit to update the date 2024-12-03 08:04:01 do we have riscv64 too? 2024-12-03 08:04:30 *dont' we 2024-12-03 08:05:12 we do, but no release iso (yet) 2024-12-03 08:05:13 or we stick to mini-root filesystem and no std release for it? 2024-12-03 08:05:19 ok 2024-12-03 08:05:19 correct 2024-12-03 08:06:11 we could probably do a rleaese iso for riscv64, but I havent figured out how yet 2024-12-03 09:26:26 What is the process to request a static version of a package? 2024-12-03 09:29:51 I would like there to be a -static version of libtorrent 2024-12-03 09:32:15 hello omni. About !73153 I added a TODO comment, and I think the issue should be created globally because we have a lot of packages already generationg the build date like that. So we need a clear guideline. 2024-12-03 09:42:47 txtsd: open a issue on https://gitlab.alpinelinux.org/alpine/aports/-/issues, or ideally send a MR in 2024-12-03 09:44:28 raspbeguy: ikke mentioned using $SOURCE_DATE_EPOCH 2024-12-03 09:45:34 yes, replied also to your comment 2024-12-03 09:46:10 i'm gonna try 2024-12-03 09:46:37 but still I think we need it in an official guideline if that's the correct solution 2024-12-03 09:47:20 Daanct12: If nobody else (like an actual wayfire user) wants to take it up, then sure, I can take over maintainership 2024-12-03 09:51:53 raspbeguy: maybe it is? it is mentioned in abuild(1), but could probably be added to the wiki 2024-12-03 09:54:15 oh then I'm a dummy 🙂 2024-12-03 09:55:17 not at all! 2024-12-03 09:55:31 I didn't know about it before ikke mentioned it 2024-12-03 09:56:31 and it probably should be mentioned elsewhere too 2024-12-03 10:14:42 raspbeguy: maybe you want to use "$(date -I -ud @$SOURCE_DATE_EPOCH)" ? 2024-12-03 10:16:34 I think SOURCE_DATE_EPOCH is derived from git log -1 --format=%cd --date=unix $(git rev-list -n 1 HEAD --) 2024-12-03 10:17:09 would this variable work when working from the release tarball? 2024-12-03 10:17:23 (so no git history) 2024-12-03 10:20:06 I tried with `date -u +"%Y-%m-%dT%H:%M:%SZ" -d @"$SOURCE_DATE_EPOCH"`, the date and time it gives me is the date of when I started the build 2024-12-03 10:22:10 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L113 2024-12-03 10:52:58 fossdd[m]: re `setup-desktop gnome`, this is what I do: 2024-12-03 10:53:06 qemu-system-x86_64 -m 8192 -serial stdio -cdrom ~/Downloads/alpine-virt-3.21.0_rc2-x86_64.iso 2024-12-03 10:53:23 login as root, type: setup-alpine -q 2024-12-03 10:54:02 then I edit /usr/sbin/setup-desktop and change setup-xorg-base to setup-wayland-base 2024-12-03 10:55:03 then I run setup-desktop, create a user 2024-12-03 10:55:21 and select gnome 2024-12-03 10:56:53 finally I start gdm 2024-12-03 10:57:21 setup-desktop only rc-update add's elogind and gdm 2024-12-03 10:57:26 did you start them manually? 2024-12-03 10:57:29 and watch the qemu graphical screen go black, with a cursor at the top left corner 2024-12-03 10:57:33 i start gdm 2024-12-03 10:57:45 alpine:~# /etc/init.d/gdm start 2024-12-03 10:57:45 [ ok ] 2024-12-03 10:57:45 * Caching service dependencies ... 2024-12-03 10:57:45 * Starting Display Manager ... 2024-12-03 10:57:46 [ ok ] 2024-12-03 10:58:04 gdm probably needs elogind to be started as well 2024-12-03 10:58:17 * WARNING: elogind has already been started 2024-12-03 10:58:21 hmm 2024-12-03 10:58:31 what do these setup- things do anyway 2024-12-03 10:58:32 i'll can take a look 2024-12-03 10:58:33 here it's just 2024-12-03 10:58:38 apk add gnome && dinitctl start gdm 2024-12-03 10:58:48 alpine:~# rc-status | tpaste 2024-12-03 10:58:48 https://tpaste.us/8BEk 2024-12-03 10:59:30 q66: we need swap out busybox mdev with udev for hotplug of keyboard/mouse work in xorg 2024-12-03 10:59:42 for wayland i dont know, but I suspect also wayland requires udev 2024-12-03 10:59:52 ncopa: that could be done by just pulling in correct dependencies, no? 2024-12-03 11:00:10 we dont auto start services when isntalling packages 2024-12-03 11:00:33 and we need to disable busybo mdev kernel listener when enabling udev 2024-12-03 11:00:35 also 2024-12-03 11:00:50 don't need to autostart services 2024-12-03 11:00:53 we used to have a "gnome" meta package, but lets say you want replace firefox with chromium 2024-12-03 11:01:06 gnome shouldn't depend on either 2024-12-03 11:01:17 arguably DE meta packages should be the minimum required to get a DE launching and not depend on apps 2024-12-03 11:01:22 Perhaps with a -minimal subpackage 2024-12-03 11:01:39 the most minimal gnome installation is just to install gnome-shell itsel 2024-12-03 11:01:40 Or better yet, an -extra instead 2024-12-03 11:01:47 setup-desktop will give you a complete desktop, including a web browser etc 2024-12-03 11:02:08 hm dunno, that seems to me like it should all be a single apk invocation 2024-12-03 11:02:29 we used to have that... 2024-12-03 11:02:35 but people were not happy 2024-12-03 11:02:39 ncopa: re that qemu launch argument, does it not hang on the qemu monitor for you? I just launched an aarch64 VM using your approach and connected to it through VNC but I just have the qemu console, it never actually boots into anything 2024-12-03 11:02:50 apk has a lot of fun bits and it feels like alpine is barely using them too 2024-12-03 11:03:05 PureTryOut: it works with a x86_64 one 2024-12-03 11:03:31 PureTryOut: i have gtk interface 2024-12-03 11:03:38 I don't have an x86_64 machine at hand currently so I rather not emulate that arch 😅 Is there a way to do the same with aarch64? 2024-12-03 11:04:12 probably 2024-12-03 11:04:19 i hope "i don't have an x86_64 machine at hand" becomes way more common 2024-12-03 11:04:36 yeah 2024-12-03 11:04:52 i have aarch64 in macos available 2024-12-03 11:05:01 Yeah this is a macbook of work 2024-12-03 11:05:13 though i'm not super happy about the replacement being a macbook 2024-12-03 11:05:24 alpine:~# cat /var/log/gdm/greeter.log 2024-12-03 11:05:24 Unable to run X server 2024-12-03 11:05:58 how do I configure gdm to use wayland? 2024-12-03 11:06:07 it will do it by default 2024-12-03 11:06:09 or should 2024-12-03 11:06:19 yes 2024-12-03 11:06:23 the snapdragon laptops are pretty good 2024-12-03 11:06:31 there is a udev rule which blocks wayland for some hardware 2024-12-03 11:06:32 how do I make gdm use the default? 2024-12-03 11:06:54 not super powerful but very capable for what i need most of the time 2024-12-03 11:06:59 how the fuck did i get setup-desktop gnome working.. 2024-12-03 11:07:17 what does gdm use as compistor? 2024-12-03 11:07:23 ncopa: if this is a vm it will disable wayland by default btw 2024-12-03 11:07:27 s/compistor/compositor/ 2024-12-03 11:07:33 PureTryOut: gnome-shell 2024-12-03 11:07:34 https://github.com/GNOME/gdm/blob/main/data/61-gdm.rules.in 2024-12-03 11:07:36 with mutter 2024-12-03 11:07:36 this is a vm 2024-12-03 11:07:44 qemu is a vm 2024-12-03 11:07:47 it does it for nvidia and for sw rendered stuff 2024-12-03 11:07:51 fossdd: interesting. I still need to get SDDM working with KWin, I had issues last time... 2024-12-03 11:08:00 we just do uh 2024-12-03 11:08:01 https://github.com/chimera-linux/cports/blob/master/main/gdm/template.py#L81 2024-12-03 11:08:35 because that udev rule has some really nasty edge cases 2024-12-03 11:09:09 like on ppc64le machines it denies you wayland always, because it finds that you have the aspeed 2d framebuffer and does not account for that you may *also* have a proper gpu in your system 2024-12-03 11:09:30 alpine:~# tpaste < /var/log/gdm/greeter.log 2024-12-03 11:09:30 https://tpaste.us/r56V 2024-12-03 11:09:43 oh huh 2024-12-03 11:09:53 and the rest it does is pretty much disable it for nvidia and whatever, which should nowadays be unnecessary but also for musl distros it does not matter because no proprietary driver 2024-12-03 11:09:59 I changed /etc/gdm/custom.conf and set WaylandEnable=true 2024-12-03 11:10:14 the udev rule will override everything 2024-12-03 11:11:09 i suggest you do the same thing in your gdm packages and just remove the rule 2024-12-03 11:15:00 i didnt have anything /run/udev/gdm-* 2024-12-03 11:15:10 we start udev, but dont re-run the triggers 2024-12-03 11:15:45 after I did a `udevadm trigger` I got a /run/udev/gdm-machine-has-hardware-gpu 2024-12-03 11:16:09 but nothing shows up on screen when restarting gdm 2024-12-03 11:16:20 ok. let me retry from scratch 2024-12-03 11:16:34 this gives me bad vibes... 2024-12-03 11:17:08 setup-desktop sway works out of the box 2024-12-03 11:17:17 but gnome is not so happy apparently 2024-12-03 11:17:37 gnome is probably punishing me for my choice of init system 2024-12-03 11:17:59 heh :p 2024-12-03 11:18:16 i remember setup-desktop gnome working some days ago 2024-12-03 11:18:19 but not sure how 2024-12-03 11:18:30 thought that setup-wayland-base did it 2024-12-03 11:18:41 i havent got it working in qemu 2024-12-03 11:19:13 maybe because you rebooted after installing to disk using setup-alpine? 2024-12-03 11:19:20 reboot will trigger udev 2024-12-03 11:20:29 maybe 2024-12-03 11:21:00 ok, still no go 2024-12-03 11:21:32 it tries to start xorg though 2024-12-03 11:21:48 Fatal server error: 2024-12-03 11:21:48 (EE) xf86OpenConsole: Cannot open virtual console 1 (Permission denied) 2024-12-03 11:23:24 yeah with setup-xorg-base it worked 2024-12-03 11:23:31 but not just with setup-wayland-base 2024-12-03 11:23:36 maybe that was my issue 2024-12-03 11:24:03 for me it didnt work with either 2024-12-03 11:24:14 at least not in qemu 2024-12-03 11:24:43 worked for me in qemu 2024-12-03 11:24:52 qemu-system-x86_64 -drive file=/home/achill/downloads/alpine-virt-3.20.3-x86_64.iso,format=raw,if=virtio -smp 12 -m 8192 -device virtio-mouse-pci -device virtio-keyboard-pci -netdev user,id=net -device virtio-net-pci,netdev=net -enable-kvm -cpu host 2024-12-03 11:24:52 roo 2024-12-03 11:24:53 did you install to disk? 2024-12-03 11:24:57 no 2024-12-03 11:25:27 Oh wow, just tried SDDM with Wayland (through KWin) and it "just works" ™️ That's different from last time 2024-12-03 11:26:02 kde and sway worked out of the box in qemu with 3.20.x as I remember 2024-12-03 11:27:01 I'd love an X11-less (except for XWayland) system. I'll see if I can make this work tonight 2024-12-03 11:27:07 PureTryOut: it should work if the pam and dbus setup is correct 2024-12-03 11:27:18 though sddm's architecture is garbage 2024-12-03 11:27:41 not that gdm is great either, though it's better 2024-12-03 11:28:04 but all the display managers are pretty much relic of old x11 times and carry a ton of misguided cruft 2024-12-03 11:28:44 oh no i was still on 3.20, after upgrading to edge it does not work anymore? 2024-12-03 11:29:59 cracklib trigger is slow 2024-12-03 11:30:34 do you have scudo preloaded :P 2024-12-03 11:30:36 yeah takes on my end almost as long as installing gnome itself 2024-12-03 11:30:41 that makes it really slow 2024-12-03 11:30:53 wait no i think that may be a different case 2024-12-03 11:31:04 though actually in your case the actual root cause may be the same 2024-12-03 11:31:05 ok, ran setup-alpine -q, added community repo, installed gdm 2024-12-03 11:31:14 deleted gdm udev rule 2024-12-03 11:31:32 changed /usr/sbin/setup-dekstop to run setup-wayland-base 2024-12-03 11:31:32 in our case, if you look at /usr/bin/cracklib-format, there is a sort -u 2024-12-03 11:31:35 and the input is really huge 2024-12-03 11:31:51 and with scudo and bsd sort, due to particular allocation strategy in the utility, it was taking up most of the time 2024-12-03 11:32:04 but in your case it may be busybox sort being slow instead 2024-12-03 11:32:17 set WaylandEnable=true in /etc/gdm/custom.conf 2024-12-03 11:32:30 you don't need to set that 2024-12-03 11:32:46 now im installing gnome 2024-12-03 11:33:11 ok i change it back 2024-12-03 11:33:20 it doesn't hurt anything but wayland is not off ootb 2024-12-03 11:33:29 it's only off if the udev rule overrides it, and then not even custom.conf will help you 2024-12-03 11:33:35 now its #WaylandEnable=true again 2024-12-03 11:33:46 i havent run udev triggers yet 2024-12-03 11:33:58 so udev hasnt run any rules AFAIK 2024-12-03 11:34:03 lets start gdm now 2024-12-03 11:34:17 same thing 2024-12-03 11:34:23 black screen 2024-12-03 11:34:24 it was really annoying to debug the udev rule being the source of wayland mysteriously getting disabled, particularly because once it runs, it leaves a file in /run which will then prevent gdm from starting with wayland no matter what, and there are very few logs 2024-12-03 11:35:17 # cat /var/log/gdm/greeter.log 2024-12-03 11:35:17 Unable to run X server 2024-12-03 11:35:24 gdm tries to start Xorg server 2024-12-03 11:35:42 which ofc fails since I replaced it with setup-wayland-base 2024-12-03 11:36:11 i change back: 2024-12-03 11:36:12 alpine:~# grep Way /etc/gdm/custom.conf 2024-12-03 11:36:12 WaylandEnable=true 2024-12-03 11:36:59 still black screen 2024-12-03 11:37:23 but log again shows libutter 2024-12-03 11:37:26 alpine:~# tpaste < /var/log/gdm/greeter.log 2024-12-03 11:37:26 https://tpaste.us/PQry 2024-12-03 11:38:00 (gnome-shell:3389): Gjs-CRITICAL **: 11:36:33.643: JS ERROR: Error: Requiring Shell, version 15: Typelib file for namespace 'NM', version '1.0' not found 2024-12-03 11:38:00 @resource:///org/gnome/shell/misc/dependencies.js:37:4 2024-12-03 11:38:00 require@resource:///org/gnome/gjs/modules/esm/gi.js:16:28 2024-12-03 11:38:12 whats that? 2024-12-03 11:38:16 networkmanager? 2024-12-03 11:39:04 probably 2024-12-03 11:39:06 hmm 2024-12-03 11:39:22 yup 2024-12-03 11:39:29 not I got the login screen 2024-12-03 11:40:22 but slow as crazy 2024-12-03 11:41:15 cpu as top, and it took 1-2 mins before "Welcome to Alpine Linux v3.21" message showed up 2024-12-03 11:41:22 at least it works 2024-12-03 11:41:31 because qemu default to one core ig 2024-12-03 11:41:46 weird, why does gnome-shell depend on networkmanager 2024-12-03 11:42:03 usually they just hide the networking info if they cant find networkmanager 2024-12-03 11:42:10 and i suppose gnome requires something faster than intel i9 2024-12-03 11:42:36 not really 2024-12-03 11:45:47 now I wonder why it didnt use wayland by default 2024-12-03 11:48:43 ah this commit (https://github.com/GNOME/gnome-shell/commit/c2c4d84fc15f5164ba86e2bcc2dfe20816f5186d) starts requiring nm if we also build with nm 2024-12-03 11:49:04 fossdd[m]: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/234 2024-12-03 11:49:06 i can open a MR 2024-12-03 11:49:21 actually 2024-12-03 11:49:21 i think we should rather add it as depend to gnome-shell 2024-12-03 11:49:23 yeah 2024-12-03 11:49:56 shoudl we also delete the udev rule? 2024-12-03 11:49:58 from gdm 2024-12-03 11:50:45 fine by me, but idk which effect it has on people's setups 2024-12-03 11:51:28 why doesnt gdm use wayland by default in qemu? 2024-12-03 11:53:21 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76366 2024-12-03 12:01:57 ncopa: just tried again with only setup-wayland-base and networkmanager and it works 2024-12-03 12:03:36 Just made https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76368 to start SDDM in Wayland when using KDE Plasma. I'd love for someone else to test this 2024-12-03 12:08:23 ikke: https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/11048 thanks 2024-12-03 12:12:41 ovf: and it has been fixed already 2024-12-03 12:13:09 that was fast 2024-12-03 12:13:37 nah, just the kind of service i've come to expect 2024-12-03 12:13:41 lol 2024-12-03 12:15:19 fabled: thanks! 2024-12-03 12:20:09 i suppose I just backport that commit? 2024-12-03 12:36:40 installing lm-sensors-detect pulls in perl-git, https://tpaste.us/meqV (3.18.6 x86) 2024-12-03 12:41:01 vkrishn: lm-sensors-detect depends on perl. perl-git is a set of extra git tools that only gets installed with git if you have perl installed 2024-12-03 13:07:14 ncopa, osinfo-db updated. Waiting from upstream to merge the patch 2024-12-03 13:58:54 ok, so who will package mangl? :D https://github.com/zigalenarcic/mangl 2024-12-03 13:59:09 (I packaged neovide just because I wanted smooth scrolling) 2024-12-03 14:06:12 i couldn't get neovide working decently. i am not 100% what was wrong, but i think neovide doesn't like my window manager. 2024-12-03 14:06:48 works fine for me with sway 2024-12-03 14:07:03 yeah, not so much with bspwm 2024-12-03 14:07:22 let me know if you figure out what the issue is 2024-12-03 14:07:33 if there is anything I can do 2024-12-03 14:09:38 sure will. not sure i will try again any time soon. nvim in terminal is nice enough for me. i was just curious to try it. 2024-12-03 14:11:14 i must admit, mangl looks pretty cool, but same thing applies there... man in terminal is generally good enough for me. 2024-12-03 14:15:02 How long should you wait for a response of a package maintainer on Gitlab before you can consider them inactive and their maintainership should be removed? 2024-12-03 14:15:46 I have 4 MR's against packages that had no response of their maintainers for a month, and I pinged them a week ago with no luck 2024-12-03 14:16:08 Including a package in main: asterisk 2024-12-03 14:17:36 I often look at user activity of the maintainer in gitlab.a.o and/or activity in git history 2024-12-03 14:18:40 Hmm this one user no activity for 2 years. I'll just consider them inactive... 2024-12-03 14:18:48 j_v: same for me, but I would love smooth scrolling in the terminal for when using the $EDITOR or $PAGER 2024-12-03 14:22:45 This one user has not done anything for at least a month, and last activity before that was 2 months earlier. Then 1 month earlier and then they were actually quite active. But not responding to pings now... 2024-12-03 14:24:21 I would say that is not long enough 2024-12-03 14:25:10 So the question was, how long is long enough? 😛 2024-12-03 14:25:11 sure, you can wish that maintainers are more active and responsive, but whatever can happen in life 2024-12-03 14:26:00 I have no good answer and I don't think we have any guidelines to it 2024-12-03 14:29:07 I think we have a few "maintainers" that haven't made any contributions for over ten years, those aports are usually maintained by others but should probably have the "maintainer" removed from the APKBUILD to make it obvious that there is none 2024-12-03 14:35:00 and if it is !74665 you're thinking of, I think it should at least wait till after 3.21 release 2024-12-03 14:35:49 are you using this aport? tests are disabled, have you properly tested that changing the locations won't break anything? 2024-12-03 14:37:42 I'm not, even more reason to wait for someone to review and test it. I'm not saying I want it merged now, I was just asking how long before you can consider the maintainer inactive. In this case it's fabled which is really active and I have no clue why they're not responding 2024-12-03 14:40:16 perhaps they are stressed enough by all the things they feel they need to manage and are even more stressed by the pinging? 2024-12-03 14:41:04 and, again, I think this "usr-merge" stuff has been moving a bit too fast and worry that it will break things for an unknown number of setups, we'll see how 3.21 release will pan out 2024-12-03 14:45:35 Fabled is focused on apk-tools. Not maintaining any aports 2024-12-03 14:49:57 I have very limited time currently and it's focused on apk-tools. I have done only a little bit of aports side work recently. Usually others have merged MRs for things I maintain before I get to them, so I have not recently looked MRs often. 2024-12-03 14:52:23 ACTION very sympathetic to the time problem 2024-12-03 15:03:24 anything else that i blocking rc3? 2024-12-03 15:03:41 otherwise I'll tag the rc3 as soon the builders are idle 2024-12-03 15:05:42 ncopa: I think !68589 is ready now, if you want 2024-12-03 15:08:52 ok 2024-12-03 15:09:53 thanks! <3 2024-12-03 15:15:51 wrt "usr-merge" I also want to say that I think a lot of related work that has gone into moving things to /usr is great, the efforts are commendable, I just think there are some parts that need more consideration, and I'm also one of those who doesn't think that everything has to go into /usr 2024-12-03 15:16:38 I wouldn't mind openrc, for example, to be in /sbin, /lib and /libexec (now it is in /sbin, /usr/lib and /usr/libexec) 2024-12-03 15:23:49 omni: my /var to /usr PR's are independent of the usr-merge work. 2024-12-03 15:24:04 ikke: but they are listed as the maintainer of that package. If they don't maintain any aports can someone else take over their packages then? 2024-12-03 15:24:31 (I'm not personally interested but it seems sensible to me) 2024-12-03 15:27:19 but moving things of /var to /usr is FHS related, as is "usr-merge", no? so prhaps I should have said "FHS" instead of "usr-merge" but it just feels like the same driving force 2024-12-03 15:27:49 Yes that part is true, they're both FHS related 2024-12-03 15:28:41 and in what way are they not maintaining their aports? 2024-12-03 15:29:05 by not keeping up with MRs? 2024-12-03 15:29:57 Basically, but I was mostly responding to ikke saying they don't maintain any aports. Aslo fabled themselves cofnirming they don't really look at aports MR most of the time 2024-12-03 15:30:36 I've been reviewing MR assigned to fabled 2024-12-03 15:31:16 I can understand that it is frustrating if you are trying to fix something that is broken on your system 2024-12-03 15:33:40 ncopa: thanks, removed "git" and lm-sensors-detect now only installs perl 2024-12-03 15:33:46 ikke: maybe you should take over maintainership of those packages then? 2024-12-03 15:41:19 I don't think alpine should be strictly FHS compliant 2024-12-03 15:41:24 guidelines > rules 2024-12-03 15:42:52 any suggestion on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74695 ? 2024-12-03 15:43:02 I wonder why this should be needed. 2024-12-03 15:43:37 Since we are not yet on usr-merge phase, and I don't know if we ever be 2024-12-03 15:44:53 umh 2024-12-03 15:44:55 neverming 2024-12-03 15:45:10 we are ok with moving forward with /usr merge 2024-12-03 15:50:14 im tagging -rc3 now 2024-12-03 15:50:23 or as soon builders are idle 2024-12-03 15:50:45 fcolista: also that's unrelated to the usr-merge 2024-12-03 15:51:20 omni: I respectfully disagree 😄 Anyway, it's not up to us anyway, that'd be a TSC decision 2024-12-03 15:52:30 -rc3 is out 2024-12-03 15:52:43 Noice! 2024-12-03 15:53:06 would be good if someone took over asterisk package 2024-12-03 15:58:01 drats 2024-12-03 15:58:08 i forgot https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76141 2024-12-03 16:00:53 -rc4 is out 2024-12-03 16:01:48 That was quick 😜 2024-12-03 16:04:44 when rc5 2024-12-03 16:10:18 depends if there are anythink to fix in rc4 2024-12-03 16:10:24 hopefully there will not be any rc5 2024-12-03 18:10:53 can `install_if` also do "if is **not** installed"? 2024-12-03 18:14:19 ncopa: we should probably also move asterisk to community 2024-12-03 20:26:54 PureTryOut: not that I know but it might be possible with !pkg 2024-12-03 21:04:05 omni: oh nice i saw you polished the release notes a bit. thanks! 2024-12-03 21:19:11 I was looking for the release notes but couldn't find them, where are they? 2024-12-03 21:21:02 https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.21.0 2024-12-03 21:24:32 there's a typo in the FTBS note, "We try to restore" should be "We will try to restore" 2024-12-03 21:25:54 what constitutes a noteworthy update? Would woodpecker qualify? 2024-12-03 22:03:13 durrendal: idk were mostly things that fell into my head. feel free to add it 2024-12-03 22:27:45 I find php84 is good enough to fit into 3.21 release 2024-12-04 01:18:27 Can someone please add the Labels tag:security to !76401? 2024-12-04 02:23:55 apk does not compile under mingw 2024-12-04 02:23:57 interesting 2024-12-04 07:15:53 is there any appetite for enabling HTTP/3 (and QUIC) for OpenSSL and libcurl? 2024-12-04 08:33:04 lets see if we can get 3.21 out today 2024-12-04 08:54:27 ¡Ánimo! 2024-12-04 09:41:48 \o/ 2024-12-04 10:48:11 omni: have you tested that alpine-xen boot image works? 2024-12-04 10:48:19 or anybody else 2024-12-04 11:03:10 ncopa: I have not tested the alpine-xen boot image, but I am running xen with both HVM and PV DomUs 2024-12-04 11:04:11 I don't think !74892 was ok 2024-12-04 11:05:22 neither moving files, without testing, nor moving from community/ because the maintainer is not active, the maintainer should have been removed from the APKBUILD instead 2024-12-04 11:06:12 quite a few "unmaintained" aports are maintained by us collectively, and that is perhaps something that should be addressed some other way, but not by moving to testing/ 2024-12-04 11:07:19 FHS compliancy and usr-merge is also not critical, but may be breaking in surprising ways if not tested thoroughly 2024-12-04 11:25:16 !70974 2024-12-04 11:25:57 as nmeum said, if it stays in main/ we have to support it for two more years, and it has been EoL for two years already 2024-12-04 11:28:05 https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.21.0#ISC_DHCP 2024-12-04 11:37:39 yes we should at least move it out of main 2024-12-04 11:40:30 at this point I'd be fine with that too, not least this close to release, just just don't forget to also move main/acf-dhcp 2024-12-04 11:44:21 apine-rpi-3.21.0_rc4-armhf works on Rpi1 2024-12-04 11:44:27 it boots at least 2024-12-04 12:02:46 alpine-rpi 3.21.0_rc4-aarch64 works on rpi3 2024-12-04 12:03:04 there is no GPU support though? 2024-12-04 12:27:37 have we ever had dri support in rpi images? 2024-12-04 12:28:07 isn't the official kernel tree for rpi still 6.6? 2024-12-04 12:28:15 it is 2024-12-04 12:28:16 i mean i know they maintain all of them 2024-12-04 12:28:24 but probably a bad idea to switch yet 2024-12-04 12:28:34 i already switched to 6.12 2024-12-04 12:28:36 boots 2024-12-04 12:28:58 the other trees usually aren't as well tested and not everything may work in them 2024-12-04 12:29:16 i also tested the 3.20 image and it is also lacking the /dev/dri 2024-12-04 12:29:28 well you just need a dtoverlay for that 2024-12-04 12:29:42 something like dtoverlay=vc4-kms-v3d 2024-12-04 12:29:45 for rpi4/5 2024-12-04 12:29:58 without it you indeed won't get a gpu device 2024-12-04 12:30:38 ok let me try that 2024-12-04 12:44:11 that did it, thanks 2024-12-04 12:44:19 yw 2024-12-04 12:44:28 there is a lot of stuff on rpi that is enabled with all these overlays 2024-12-04 12:44:36 there are so many of them and most functionality is off by default 2024-12-04 12:53:29 ok. the dri show up at least 2024-12-04 12:53:40 i wasnt able to run either sway or xfce or anything 2024-12-04 12:55:32 the only device i didnt test was rpi2 2024-12-04 12:55:39 because I dont have that device (yet) 2024-12-04 13:09:37 I may have one 2024-12-04 13:09:48 Forgot which versions I have 2024-12-04 13:10:04 But could only test it tonight 2024-12-04 13:22:49 im fairly confident it will work 2024-12-04 13:34:54 On the rpi1 and 6.12, sound is not loaded on boot so I must modprobe snd_bcm2835 2024-12-04 13:35:36 everything else seems to work fine 2024-12-04 14:00:16 nice 2024-12-04 14:00:23 i tagged -rc5 2024-12-04 14:33:51 i hope those empty folder got added, /lib/firmware/b43 , /lib/firmware/b43legacy/ 2024-12-04 14:37:22 release notes draft https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/91 2024-12-04 15:33:45 ncopa: should the section of people having / and /usr in different partitions be put in there too? 2024-12-04 15:33:51 Or at least a pointer? 2024-12-04 15:34:38 Though better comment in there, I guess 2024-12-04 15:39:19 <3 pablo! 2024-12-04 15:39:33 for the "Preparations for /usr-merge" section on the wiki page, would it be possible to omit the phrase "and it may be advisable to skip the 3.21 upgrade"? stable release should be in a ready state for everyone to use 2024-12-04 15:41:30 the wording to "proceed with care" should be adequate? 2024-12-04 15:46:22 I think that creates a greater risk than issues it solve 2024-12-04 15:46:56 Depends on what each person needs in the different partitions, requirements are different 2024-12-04 15:48:08 how much work is left until the /usr-merge is completed? 2024-12-04 15:48:27 agreed with mio, the wording to "skip" a stable release implies that the stable release is in fact not stable. 2024-12-04 15:48:38 a bit worried about the optics of suggesting a subset of users to skip the 3.21 upgrade. will they have to wait another 6 months to upgrade? 2024-12-04 15:49:04 durrendal: https://gitlab.alpinelinux.org/groups/alpine/-/milestones/16#tab-issues 2024-12-04 15:49:33 mio: possibly not. Hopefully the mkinitfs changes can be merged in the next weeks 2024-12-04 15:49:37 thanks fossdd[m] didn't realize there was a project for it. 2024-12-04 15:49:41 And maybe they can be backported 2024-12-04 15:50:20 The thing is, out of all the people in the world using alpine linux, we so far have 1 person with such setup testing it. Things went wrong, and we fixed part of it 2024-12-04 15:50:34 But needs a lot more testing that simply doesn't exist in the wild 2024-12-04 15:50:54 okay. maybe that could be clarified/included with an eta for those people, so they have more certainty for when they can upgrade? 2024-12-04 15:50:59 Right now the bug fix unfortunately is not merged 2024-12-04 15:53:01 Maybe? ETAs are always tricky, but maybe that makes sense 2024-12-04 15:53:15 I can point to the MR that should possibly be the end of the fix 2024-12-04 15:54:27 any additional information that can lead someone reading the announcement to make an informed decision sounds like a good idea to me 2024-12-04 15:55:02 that might be good. generally communicate to readers what signal(s) they should look for and where to know they can proceed, even if the eta is not a set date 2024-12-04 15:55:57 e.g. where to check for that update, if there will be an announcement on socials when that happens 2024-12-04 16:03:58 mio durrendal: what do you think? 2024-12-04 16:03:59 proceed with care. As part of the merge, /usr will be mounted from the initramfs to make sure everybody has all necessary binaries in place. However, there are currently some bugs being [https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/186 worked on]. Until those are worked out and backported, it is advisable to hold the upgrade back. If you have one of those setups, and want to help testing, you may 2024-12-04 16:03:59 open an [https://gitlab.alpinelinux.org/alpine/aports/-/issues/new issue] and ping @pabloyoyoista. 2024-12-04 16:03:59 A lot of preparations went into this release to ensure that the merge happens as smoothly as possible. That included moving the location of some binaries and many libraries from /bin, /sbin, and /lib to their counter-parts in /usr. Users with installations where / and /usr are on separate filesystems (partitions, volumes, disk drives or other) should 2024-12-04 16:04:45 Is that sensible? One thing missing there, is that people might have to also do some configurations to their systems 2024-12-04 16:05:03 Like, pass cryptsetup options, or add some extra modules 2024-12-04 16:14:53 it's better, explaining the current status more clearly. the mkinitfs MR title refers to init improvements, so maybe also refer to improvements rather than bugs, and advising users to wait for those improvements to be finalised in the coming [eta timeframe]. and where they can get a status update (i.e. is it ready as soon as MR is merged, will there be an announcement?) 2024-12-04 16:18:55 great that there is a point of contact both to help test but also for questions. hopefully if there is a place people can check back for status updates, e.g. the release notes page, socials, people can schedule their upgrades accordingly 2024-12-04 16:19:48 upgrade may be delayed, not skipped :) 2024-12-04 16:25:25 Thanks! I have updated the mkinitfs MR, since that's more appropriate 2024-12-04 16:26:42 And added that there will be further information published when the details are resolved 2024-12-04 16:26:58 Thanks for the feedback though :) 2024-12-04 16:27:27 Messaging is hard, and becomes very important in these topics where people have strong feelings, so really appreciated! 2024-12-04 16:28:16 you're welcome, thanks for working on the draft and revising the phrasing 2024-12-04 16:43:08 PabloCorreaGomez[m]: that wording is much better, mio beat me to the punch here, but I think this gets the message across much better! 2024-12-04 16:44:24 "We plan for the next Alpine Linux, version 3.22, to contain the /usr-merge." I think 'the /usr-merge' warants some explanation here? 2024-12-04 16:53:00 ikke: we need the post for it. It's been waiting for 3.21 to be out so people can rest and we can get to it 2024-12-04 16:53:57 It says that we'll provide more details at the end too 2024-12-04 17:02:37 Once 3.21 is out, could we start a draft for 3.22 release notes already? There is a sort-of significant change I want to make in KDE Plasma (dropping X11 support) and I rather have it written out in release notes early before I forget it 😅 2024-12-04 17:03:52 PureTryOut: yes 2024-12-04 17:05:32 upgrade to 3.21 is cautioned, but direct install would be ok? 2024-12-04 17:11:12 whole release sounds like an experimental release 2024-12-04 17:11:18 release notes^ 2024-12-04 17:37:38 for para jellyfin, https://tpaste.us/Xv0E 2024-12-04 17:40:06 https://tpaste.us/Lye6 , for Preparations for /usr-merge 2024-12-04 17:40:16 last line 2024-12-04 17:43:50 for OpenSSH service requires restart para, https://tpaste.us/ZK4g (just a thought for opening line) 2024-12-04 17:46:32 para, Preparations for /usr-merge 2024-12-04 17:46:42 Plans for /usr-merge is underway, and we should be able to finalize it in Alpine Linux, version 3.22. 2024-12-04 17:47:53 Lots of preparations has gone into this .... 2024-12-04 17:56:28 https://tpaste.us/lbVY , for para OpenSSH service requires restart 2024-12-04 17:57:06 if sounds ok, I can make changes in whole and post it 2024-12-04 18:01:37 or better of jellyfin para, 2024-12-04 18:01:42 Jellyfin-ffmpeg is jellyfin's recommended fork of ffmpeg. It is is available for all archs. 2024-12-04 18:17:30 not to be a pain but, is it at all feasible to finish the /usr-merge while 3.21 is still in rc? I know 3.21 has taken a lot longer to release than desired, but would waiting to release it until all of the changes are made be a better experience for the consumers of the stable branch? 2024-12-04 18:18:18 full changes, https://tpaste.us/do45 2024-12-04 18:18:33 it seems like the current state of the merge leaves us in a position where we have half a solution, which doesn't seem very stable. 2024-12-04 18:19:06 agree, it also makes bot 3.21 + 3.22 shaky 2024-12-04 18:19:09 both 2024-12-04 18:19:53 It was never the goal to do a complete usr-merge already 2024-12-04 18:20:57 not before 3.21 I mean 2024-12-04 18:22:34 I compiled a custom linux-lts kernel through aports, but I don't know how to get this new installed package to work with "kernel-hooks" 2024-12-04 18:22:36 yes, but the question is, can all users upgrade safely in the meantime, on day 1 of the 3.21 release? 2024-12-04 18:22:55 With the default kernel-hooks package it'd usually say like this "kernel-hooks: executing hook 50-secureboot.hook (lts, 6.12.1-3, )" 2024-12-04 18:23:28 But with my custom kernel it says this "kernel-hooks: executing hook 50-secureboot.hook (1-hardened, , 6.11.10-hardened1)" am i doing something wrong, it doesn't make an efistub that i need in my boot/efi folder for some reason 2024-12-04 18:24:12 yes i used hardened patch from here if that matters: https://github.com/anthraxx/linux-hardened/releases 2024-12-04 18:24:49 the page cautions upgrade, to suggest add like "New/fresh install of v3.21 should work out of the box." 2024-12-04 18:38:55 mio, durrendal: yes, most users can upgrade without issues. There has been multiple reports of small things broken by the changes regarding the /usr merge in edge, all fixed timely 2024-12-04 18:39:00 ikke: sure that makes sense, but if we need to carry such an explicit warning that upgrading to this stable release has a high likelihood to break your system, that feels less than stable. 2024-12-04 18:39:29 There's been 1 user with a very unconventional setup out of everybody running edge that has actually had issues, and that lead to that warning 2024-12-04 18:40:34 Not sure which is the percentage of machines running edge, but there's surely a lot. Seems a bit too much to say it's unstable for that. Specially when it's a very specific setup, which is documented 2024-12-04 18:40:48 PabloCorreaGomez[m]: that's good, if it's only small things broken, then maybe the messaging can convey more confidence that they are minor issues 2024-12-04 18:41:04 A setup that BTW is not even supported by setup-alpine nowadays 2024-12-04 18:43:19 Not sure if there's some way to message that only people with 2024-12-04 18:43:21 > Users with installations where / and /usr are on separate filesystems (partitions, volumes, disk drives or other) should proceed with care 2024-12-04 18:43:25 should be concerned 2024-12-04 18:43:34 uncertain if people reading the advisory will come away thinking upgrading will most likely break their systems if they had a split setup, compared with 1 edge case 2024-12-04 18:44:15 If they have a split setup, the chances are that upgrading will break your system, yes 2024-12-04 18:44:33 The reality seems to be, however, that very few people have split setup 2024-12-04 18:44:49 Else, I would have received a lot more hate 2024-12-04 18:45:54 And it's completely unsurprising that people don't have those setups. They are custom setups not supported by default by current installation methods 2024-12-04 18:46:15 Hating on things that are obviously going to be pushed through no matter what doesn't help, so people just deal with it. 2024-12-04 18:46:20 I'm just trying to understand a bit better, if we move this forward to the completion of the /usr-merge, will that setup still be broken in a way that the user will need to manually reconfigure their system? 2024-12-04 18:47:07 is there an alternative for those users in the meantime, e.g. would you recommend a reinstall like vkrishn mentioned? 2024-12-04 18:47:38 what mercenary said is valid, I think there are plenty of people here that aren't aware of the changes being made, or disagree with them but get shut down when they attempt to discuss them 2024-12-04 18:48:18 durrendal: users will need to configure their initramfs to mount /usr, as they currently do with / 2024-12-04 18:48:49 And yes, reinstalling will be an alternative 2024-12-04 18:49:09 At this point this does not seem to be a productive discussion though 2024-12-04 18:49:13 who has been shuyt down? 2024-12-04 18:49:15 So leaving for today 2024-12-04 18:49:16 shut* 2024-12-04 18:49:41 likewise wondering what the options are for those users if they want to get the benefits of 3.21, think offering those options just mentioned to people might provide some clarification on their upgrade path 2024-12-04 18:50:19 so that waiting isn't the only option 2024-12-04 18:50:28 ikke: my wording may be a bit strong, less shut down, more disengaged from discussing 2024-12-04 18:51:43 I am not implying that the /usr-merge, or the work done for it, is bad or without merit. I appreciate all the hard work that everyone has put into it 2024-12-04 18:53:49 but I am concerned that we have a large change that is half finished which appears like it could cause breaking changes, and the solution seems to be "don't upgrade or reinstall" 2024-12-04 18:54:12 all I really want to know is if that can be avoided by making changes to 3.21-rc before it is 3.21. 2024-12-04 18:54:42 and if the simple answer is "no" that's fine I guess, but I would like to understand why. 2024-12-04 18:56:43 durrendal: for the specific setup that PabloCorreaGomez[m] referred to, it would be the user that needs to make the changes, it's not something we can do for them 2024-12-04 18:58:56 The case where the user has a separate mount for /usr that before this change was not required to be present to boot 2024-12-04 18:59:56 it would be nice to not repeat grub fiasco as with 3.20 2024-12-04 19:00:16 The grub thing was solved before 3.20 2024-12-04 19:00:34 my broken machine would like to disagree with you 2024-12-04 19:02:00 ikke: so said user would need to add their /usr to /etc/fstab, and then the change made recently to mkinitfs takes care of it from there. 2024-12-04 19:02:52 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/commit/e1bed9ce3baf2c1fcf7aff17212139608f317342 2024-12-04 19:03:05 very noob and an over asked question, but im using https://webchat.oftc.net/ to view this irc, but i can't see old posts, is there a way to see archived old messages, or will i need to keep a computer on for this irc to see old messages, sorry 2024-12-04 19:03:18 I think we need to fix the mkinitfs MR to 2024-12-04 19:03:29 user83291037: https://irclogs.alpinelinux.org/ 2024-12-04 19:03:31 user83291037 irclogs.alpinelinux.org 2024-12-04 19:03:41 mount /usr 2024-12-04 19:03:54 someone thorough with breaking changes should attempt in writing a wiki page on " migrating methods to v3.21" 2024-12-04 19:04:02 ikke: thank you for clarifying, that's what I was looking for. 2024-12-04 19:04:03 (other option is join via matrix client and it will keep history) 2024-12-04 19:04:05 and backport it to 3.21 branch 2024-12-04 19:04:13 this is different from "upgrade methods" 2024-12-04 19:04:49 we need someone to test an co form that the fix actually works 2024-12-04 19:05:39 co form? 2024-12-04 19:05:49 confirm 2024-12-04 19:05:52 ah 2024-12-04 19:05:52 Confirm 2024-12-04 19:06:02 using phone 2024-12-04 19:06:05 np 2024-12-04 19:06:29 the fix was not merged because it is still draft 2024-12-04 19:06:51 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/186 2024-12-04 19:06:51 i will merge as soon someone says it’s ready to merge 2024-12-04 19:07:14 i Have si 2024-12-04 19:07:27 But that means you have to create a setup with a separate /usr mount? 2024-12-04 19:07:42 I have simply not had time to test it or work on it at all 2024-12-04 19:07:42 s/But / 2024-12-04 19:07:57 yeah I think so 2024-12-04 19:08:33 i wonder why it’s mounted as ro instead of just use the mount options from fstab 2024-12-04 19:08:51 probably for fsck? 2024-12-04 19:09:38 but then we also need implement that in the openrc script 2024-12-04 19:09:42 yes, it's needs to be ro to fsck 2024-12-04 19:09:44 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/186/diffs?commit_id=d3f9beaf87609261cf2c166ba5911874b668c145 2024-12-04 19:09:51 pablo does mention that in the commit 2024-12-04 19:10:10 sorry but i have a question on developing custom linux kernel for alpine, im not sure how to setup the kernel-hooks package for my custom kernel with a different name, i don't know if this is to specialized or something, but i renamed my kernel from lts to hardened i dont know how to make it work with a new name 2024-12-04 19:11:08 user83291037: I think the trigger only supports versions with 3 components 2024-12-04 19:11:31 From the message, it appears yours has 4? 2024-12-04 19:12:19 At least, it should match this pattern: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/kernel-hooks/kernel-hooks.trigger#L13 2024-12-04 19:12:59 user83291037: what does `uname -r` return for you? 2024-12-04 19:15:27 oh i haven't even loaded kernel maybe thats why, 6.6.61-0-lts, im gonna boot the new compiled kernel then 2024-12-04 19:17:48 I don't think that's required, the hook should run for newly installed kernels 2024-12-04 19:18:15 yes but thats what i get from uname -r 2024-12-04 19:19:33 so is https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/186 ready to merge? 2024-12-04 19:19:48 I'll merge it now and ship it with 3.21 if its ready 2024-12-04 19:19:56 ncopa: pablo mentioned that the user that was affected by it said it fixed their problem 2024-12-04 19:20:07 > Confirmed by the user whose system broke, that this solves mounting /usr from initramfs, and therefore the /usr-merge use-case for that 2024-12-04 19:20:15 I saw that 2024-12-04 19:20:21 and it does not break anything for anyone else? 2024-12-04 19:20:32 or do we hold the 3.21 release back for another week? 2024-12-04 19:20:46 which will lead to 2-3 weeks due to people pushing things to git master 2024-12-04 19:21:21 if we dont release tomorrow it will minimum need 1 more week, because i'm taking some days off 2024-12-04 19:21:58 if you are confident its ready to merge, and haveverified that the openrc script will remount it accorind fstab (I havent checked this) 2024-12-04 19:22:03 then I'll say we just merge it 2024-12-04 19:23:30 would have been good to have had this in the -rc s 2024-12-04 19:23:32 doesn't the init.d script need to remount /usr RW after the fsck is run? 2024-12-04 19:23:44 > and haveverified that the openrc script will remount it accorind fstab (I havent checked this) 2024-12-04 19:24:43 ah right, you did say that, sorry 2024-12-04 19:26:39 localmount does mount -at "$types" 2024-12-04 19:27:23 So if /usr is set to rw in /etc/fstab, it should be mounted rw, right? 2024-12-04 19:27:39 not sure if mount changes options on already mounted filystems 2024-12-04 19:29:35 I can tag another mkinifs release and do another -rc tonight 2024-12-04 19:29:57 Let's do that 2024-12-04 19:30:02 but then someone needs to take responsibility for https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/186 and remove the draft 2024-12-04 19:30:13 I'm reviewing each commit 2024-12-04 19:30:19 thanks 2024-12-04 19:30:39 we also need someone to test that it works afterwards 2024-12-04 19:30:58 I'll try to setup a vm with 3.20 and then upgrade 2024-12-04 19:32:10 ncopa: from my review, the changes of that MR should only have impact on systems with separate /usr mounts. 2024-12-04 19:32:30 either by having /usr in fstab, of by setting one of the new *usr kernel options 2024-12-04 19:32:51 yeah 2024-12-04 19:32:57 and currently its completely broken 2024-12-04 19:33:10 i mean that setup is currently completely broken 2024-12-04 19:33:32 So basically it can only be an improvement 2024-12-04 19:34:06 and I can run the installer tesetsuite to verify that it doesnt break anything after the -rc is out 2024-12-04 19:34:06 I'll test the changes after you tagged the -rc 2024-12-04 19:34:11 okl 2024-12-04 19:34:18 im setting up a vm now as well 2024-12-04 19:34:20 Does the test suite also test upgrading? 2024-12-04 19:34:53 thank you ikke ncopa, if I can help with testing or anything I'm happy to do so. 2024-12-04 19:37:33 no 2024-12-04 19:37:42 just fresh install 2024-12-04 19:37:52 Ok, then I'll test updating 2024-12-04 19:37:55 all combinations of disk storage, and filesystem 2024-12-04 19:38:24 durrendal: maybe you can also help with that, maybe with some different setups 2024-12-04 19:40:44 vms from the latest 3.20 work ok? or would physical hardware be better? 2024-12-04 19:42:34 i must say that i hate the special handling of /usr in initramfs 2024-12-04 19:42:40 but it is what it is 2024-12-04 19:43:28 in the idea world, mknitfs would be modular and it could be included as an optional module 2024-12-04 19:43:32 and add a cryptusr boot opt? 2024-12-04 19:44:08 should we add a crypthome and cryptopt cryptvar crypt as boot opt? 2024-12-04 19:45:07 why dont we have a single option with args? like cryptsomething=mount=/usr,...otheropt=.... 2024-12-04 19:46:08 I suppose because these are necessary to boot, while the rest can be unlocked later in the process? 2024-12-04 19:46:39 And making things more dry in shell script is a pain 2024-12-04 19:46:48 but is it currently possible have /usr as a separate encrypted partition? 2024-12-04 19:47:13 when are you prompted for password in that case? 2024-12-04 19:47:27 Before /usr was not required to boot 2024-12-04 19:47:46 yeah, but does it actually work currently? 2024-12-04 19:47:50 in 3.20 2024-12-04 19:47:51 I don't know 2024-12-04 19:48:17 Technically someone can manually run cryptsetup luksOpen after boot and mount it then 2024-12-04 19:49:00 yeah, but the openrc script support that in any way? 2024-12-04 19:49:11 or add that to a script in initramfs 2024-12-04 19:49:19 /etc/local.d 2024-12-04 19:50:03 there is no way we can do a clean upgrade based on anything in /etc/local.d 2024-12-04 19:50:06 i do that, from /etc/local.d in a strange /usr flip setup 2024-12-04 19:50:10 im thinking 2024-12-04 19:50:20 we can't really deal with it when upgrading 2024-12-04 19:50:27 so probably beter not support it 2024-12-04 19:50:27 ncopa: the problem is, before, /usr was presumably optional, now it's required for boot 2024-12-04 19:50:36 yes, i get that 2024-12-04 19:50:59 but i dont want introduce functionality in 3.21 that we need be backwards compat with for 3.22 2024-12-04 19:51:47 i want revert https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/186/diffs?commit_id=8800a2126c9f6a00304ad1eed025b3d6dd856dca 2024-12-04 19:52:41 rename it to KOPT_only_available_in_3_21_cryptusr 2024-12-04 19:52:41 i think this usr merge story require a complete rethink/reimplementation of initramfs 2024-12-04 19:53:07 i think i'll just revert it 2024-12-04 19:53:15 and everyone thought to do it in 6months 2024-12-04 19:53:31 and if someone report a broken system, i'll consider re-enabling it 2024-12-04 19:54:04 vkrishn: right now it is: "solve it before going to bed in 30 mins" 2024-12-04 19:55:09 yes, working in stress mode is not ok 2024-12-04 19:55:16 it is not 2024-12-04 19:56:24 ncopa: fyi, tomorrow in the afternoon I'm available to assist with the release 2024-12-04 19:56:52 i probably need to do the release in the morning 2024-12-04 19:56:58 in the afternoon i have meeetings 2024-12-04 19:57:03 ok 2024-12-04 19:57:27 i think the current most important thing is the release notes 2024-12-04 19:57:36 i was not able to write it properly 2024-12-04 19:57:47 i was out on a kubernetes meetup in oslo 2024-12-04 19:58:07 so it would be awesome if someone could finish it up properly 2024-12-04 20:01:06 i have done some changes, https://tpaste.us/do45 , see if ok, and update wiki page 2024-12-04 20:01:30 will think of other paragraphs that i left out 2024-12-04 20:02:42 vkrishn: very minor, "Plans for /usr-merge is underway" -> s/is/are/ 2024-12-04 20:03:13 "preparations has gone" -> s/has/have/ 2024-12-04 20:03:30 ok, just do new wiki page, will read the whole 2024-12-04 20:05:00 making critical last minute changes under stress late night when tired is the recipy for disaster 2024-12-04 20:05:33 i mean the release notes for press release 2024-12-04 20:05:51 "However, there are currently some bugs being [https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/186 worked on]" this been merged 2024-12-04 20:05:53 someething that fits in a tweet (xeet?) 2024-12-04 20:06:07 toot :P 2024-12-04 20:07:08 how long time will it take main/spirv-llvm-translator-19.1.2-r0 to finish? 2024-12-04 20:07:50 if the mkinitfs commit will support it, could a line about adding /usr to /etc/fstab be mentioned, as one of the options for upgrading, above the new/fresh install? i.e. what users with the split setups should do before upgrading. if that's not going to be available for 3.21 then never mind 2024-12-04 20:08:11 the only thin that can sink this is if someone push a heavy build 2024-12-04 20:08:27 similar to the iptables changes back in 3.20, about how to migrate the rules, that was helpful 2024-12-04 20:08:47 thanks so much for working on this! 2024-12-04 20:09:11 ok 3.21 buildes are idle 2024-12-04 20:09:35 I'm holding off 2024-12-04 20:09:52 here comes rc6 2024-12-04 20:10:57 ikke thank you 2024-12-04 20:11:02 mio thank you 2024-12-04 20:11:06 PabloCorreaGomez[m] thank you 2024-12-04 20:11:17 durrendal thank you 2024-12-04 20:11:30 we can do this 2024-12-04 20:11:33 thank YOU ncopa, please get some rest 2024-12-04 20:12:06 i will. i will just wait for the rc6 to be done and then i'll kick of the installer testsuite 2024-12-04 20:12:30 and then I'll rest 2024-12-04 20:12:35 good! and we can definitely do this, just takes patience, and a whole lot of effort. 2024-12-04 20:12:39 thanks ncopa! have a good day's rest when you do 2024-12-04 20:13:10 this one here will need some improvements: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/91 2024-12-04 20:13:12 and to ikke, everyone for testing and editing release notes 2024-12-04 20:13:42 we need to get the highlights for media from the wiki release notes into https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/91 2024-12-04 20:13:59 for example, i forgot the 6.12 kernel 2024-12-04 20:14:06 x86_64 is idle 2024-12-04 20:14:18 we should add a warning for users with separate /usr partition 2024-12-04 20:14:45 something like "it should work, but be careful and report back breakages" 2024-12-04 20:17:42 ncopa: I could upgrade a linode vm to 3.21 2024-12-04 20:17:46 booted without issue 2024-12-04 20:17:48 what went wrong? 2024-12-04 20:17:59 Nothing :) 2024-12-04 20:18:24 did i push the tag? 2024-12-04 20:18:41 yes 2024-12-04 20:18:46 * [new tag] v3.21.0_rc6 -> v3.21.0_rc6 2024-12-04 20:18:47 where is the _rc6 iso? 2024-12-04 20:18:54 https://dl-master.alpinelinux.org/alpine/v3.21/releases/x86_64/ 2024-12-04 20:19:55 it's on the builder 2024-12-04 20:20:03 alpine-netboot-3.21.0_rc6-x86_64.tar.gz 2024-12-04 20:20:10 alpine-standard-3.21.0_rc6-x86_64.iso.sha512 2024-12-04 20:20:23 (iso as well) 2024-12-04 20:20:25 this usually happens when the release fails to build 2024-12-04 20:20:30 mio, some general lines, https://tpaste.us/4vo1 2024-12-04 20:20:43 I don't see any logs regarding this 2024-12-04 20:20:54 thre is no -virt or -xen images 2024-12-04 20:21:00 somethign broke 2024-12-04 20:21:08 im debugging it 2024-12-04 20:21:32 the logging is ... not yet implemented 2024-12-04 20:21:37 heh 2024-12-04 20:23:00 but, kinda good we bumped into this today and not tomorrow 2024-12-04 20:23:41 oh 2024-12-04 20:24:10 sigh 2024-12-04 20:24:39 vkrishn: "if something does not work during upgrade" ... would it be preferable to have users report the issues to the issue tracker maybe? not sure about "migrating the same service/application" 2024-12-04 20:25:00 s/the issues/any issues they experience/ 2024-12-04 20:25:23 its this one that broke the iso https://gitlab.alpinelinux.org/alpine/aports/-/commit/785e5584c498a05a2a9f9815dd440ff260fa1149 2024-12-04 20:25:34 you mean user do a signups? 2024-12-04 20:25:49 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/mkimg.standard.sh?ref_type=heads#L44 2024-12-04 20:26:11 >>> mkimage-x86_64: --> apks x86_64 167e3daa413a221a6fe84b34e2afa44d01d56ff2 2024-12-04 20:26:11 dhcrelay: unable to select package (or its dependencies) 2024-12-04 20:26:11 dhcp: unable to select package (or its dependencies) 2024-12-04 20:26:43 are there any alternatives to dhcrelay? 2024-12-04 20:26:49 anyway 2024-12-04 20:26:57 its to late start think about that now 2024-12-04 20:27:02 the train has sailed 2024-12-04 20:27:31 vkrishn: what's the context for the sentence? is it to replace "Plans for /usr-merge is underway, and we should be able to finalize it in Alpine Linux, version 3.22."? 2024-12-04 20:28:10 mio, https://tpaste.us/MYkk 2024-12-04 20:29:56 mio, make changes that seems ok, will read the whole again 2024-12-04 20:30:46 btw 2024-12-04 20:31:03 we probably need to post the article about /usr merge at the same time 2024-12-04 20:31:06 as the release 2024-12-04 20:31:15 That would make sense 2024-12-04 20:32:05 ncopa: I think dhcp-helper might fill the same function as dhcrelay 2024-12-04 20:32:16 but am somewhat guessing. 2024-12-04 20:32:29 i was expecting the article sooner, had some stuffs cooking up, but kinda vanished now 2024-12-04 20:33:02 kinda scary to just remove a package that many probably are using 2024-12-04 20:33:10 i read the kea migration doc 2024-12-04 20:33:23 no way that users will do all that 2024-12-04 20:33:37 they just want the ip to be delivered 2024-12-04 20:33:46 like it has been done for the last 20 years 2024-12-04 20:34:12 i bet we will get request to get dhcp back 2024-12-04 20:34:47 But what if there's a critical vulnerability? Are we going to patch it? 2024-12-04 20:35:00 i have used debian for 20yrs+ al for 10+, only reported a handful of issues, rest just did some local workarounds that worked so far 2024-12-04 20:35:22 yeah, we will grab whatever patches other distros are using 2024-12-04 20:35:35 from debian or redhat 2024-12-04 20:37:13 rc7 is out 2024-12-04 20:38:11 it could be a strory page - "the night al went all rc's" 2024-12-04 20:38:52 heh 2024-12-04 20:38:58 and no beer 2024-12-04 20:39:07 lol 2024-12-04 20:39:12 if you only knew... 2024-12-04 20:39:23 :) 2024-12-04 20:40:20 whoops forgot to restart the build-3-21-x86_64 2024-12-04 20:41:04 vkrishn: okay, please give me a few minutes to edit 2024-12-04 20:41:14 ok, thanks 2024-12-04 20:43:58 for 3.22, i wonder if we can get rid of -extended iso? or -xen iso? 2024-12-04 20:44:01 probably not 2024-12-04 20:44:55 i think not, i do use them 2024-12-04 20:45:39 -extended kinda nice for making rescue disk base 2024-12-04 20:46:38 without -xen, gropping with wiki pages will become a users nightmare 2024-12-04 20:48:27 ok -rc7 is there 2024-12-04 20:48:40 running the test suite now 2024-12-04 20:48:46 have a good night everyone! 2024-12-04 20:49:04 ncopa: sleep well 2024-12-04 20:52:14 good night! 2024-12-04 21:02:28 vkrishn: https://0x0.st/X7Og.txt rephrased the /usr merge section, the rest are minor changes for typos 2024-12-04 21:02:55 feel free to reword of course, thanks! 2024-12-04 21:05:08 mainly to clarify the upgrade path for split / and /usr setups (changes users should do before upgrading, or do a new install) 2024-12-04 21:07:20 mio: nice, update wiki page pls 2024-12-04 21:14:38 night ncopa! 2024-12-04 21:15:57 ncopa: thanks for all your work. sleep well! 2024-12-04 21:16:16 probably half asleep 2024-12-04 21:20:40 ncopa: pls don't get rid of the -extended iso 2024-12-04 21:21:00 i'd rather have it be even more -extended 2024-12-04 21:21:15 just wondering, for what purpose? 2024-12-04 21:21:44 offline installs, rescue media with more useful tools, etc. 2024-12-04 21:21:54 with more i mean more as in quantity 2024-12-04 21:22:54 i could suggest to cut it to 700mb(cd size), and urge devs to spin a distro iso 2024-12-04 21:23:11 _more_ useful tools, *not* _more useful_ tools - is what i mean 2024-12-04 21:39:12 got a scary message about my changes being automatically identified as harmful, hope that wasn't too many edits in one action 2024-12-04 21:40:51 that is, when updating the release notes wiki page ... please feel free to edit/selectively apply suggested changes as needed 2024-12-04 21:41:05 I think, ikke and zcrayfish could help there 2024-12-04 21:41:38 try editing para wise 2024-12-04 21:42:14 mio: quickly looked over and seems good 2024-12-04 21:42:15 thx 2024-12-04 21:42:27 the changes were saved, just wasn't sure if did it according to procedure 2024-12-04 21:42:35 fossdd[m]: okay, thanks! 2024-12-04 21:42:44 think there isn't really a procedure 2024-12-04 21:42:54 but i do it it many smaller changes, like commits basically 2024-12-04 21:44:04 mio, https://tpaste.us/EbBJ 2024-12-04 21:44:27 i think saying that jellyfin-ffmpeg is available for all architecutes is rather confusing 2024-12-04 21:44:51 i don't think jellyfin-ffmpeg is (or should be) used other than by jellyfin itself 2024-12-04 21:45:20 ok 2024-12-04 21:45:55 so its not a noticiable user end thing 2024-12-04 21:46:00 yea 2024-12-04 21:46:00 backend 2024-12-04 21:46:32 then this like is confusing, Jellyfin was disabled for ARM architectures (aarch64 and armv7) and is only available for x86_64 2024-12-04 21:47:09 so what is enabled ? and what is dis-abled, and what works? 2024-12-04 21:47:35 there's a weird issue with some precompiled bins, something there before that an abuild release showed 2024-12-04 21:47:40 didnt had time to dive in 2024-12-04 21:48:24 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/74655 2024-12-04 21:48:28 was also gonna look into it, but havnt had the motivation to 2024-12-04 21:48:50 in the past jellyfin used to ship precompiled .so 2024-12-04 21:53:25 Ffmpeg now uses jellyfin-ffmpeg backend as default. Its now the recommended fork of ffmpeg. 2024-12-04 21:53:38 better 2024-12-04 21:55:55 or use word, 'variant' somewhere to describe it 2024-12-04 22:33:01 bit late, but regarding the extended iso topic from earlier... I ended up scratching my own itch for making an alpine rescue-usb with all the pkgs I tend to need, https://github.com/9001/asm 2024-12-04 22:33:23 the "obig" usb-image ends up around 300 MiB iirc, and for my specific purposes it's much more useful than the extended-iso (since it has even more recovery-oriented tools) -- I guess my point is it'd be really cool if there was a simpler way to assemble your own iso with just the stuff you need :-p 2024-12-04 22:33:46 tbh my approach is an absolute mess and it'd probably be much better to just use mkimage + makebootable + something to create the appropriate apkovl... 2024-12-05 02:41:01 Hi, I'm trying to use abuild to build from an apkbuild file. I downloaded the apkbuild file from gitlab, made a directory called the program name, cd into it, and tried to run abuild checksum and abuild -r. But I seem to be missing checksums, is there a step I'm skipping? Thanks 2024-12-05 02:43:05 Like are there other files I need to download into this directory other than the apkbuild file? 2024-12-05 02:50:31 what's the error 2024-12-05 02:53:32 When I run abuild checksum it tries to fetch a github .tar.gz file, but abuild-fetch says /var/cache/distfiles/mpv-a0fba7be57f3822d967b04f0f6b6d6341e7516e7.tar.gz.lock: Permission denied 2024-12-05 02:53:57 Then when I ran abuild checksum it said a .tar.gz file is missing in checksums 2024-12-05 02:55:54 did you add yourself to abuild group or otherwise give permissions to distfiles 2024-12-05 02:58:34 I added myself to the abuild group but I didn't reboot. I'll try that and if it doesn't work I'll come back. Thanks 2024-12-05 03:01:21 Okay so I was able to run it, but now it saays sha512sum: meson-libcaca-version.patch: No such file or directory 2024-12-05 03:01:28 >>> ERROR: mpv: sha512sum failed 2024-12-05 03:02:22 You'll need to download any files listed in the source in the apkbuild as well 2024-12-05 03:02:38 They should be in the same path as the apkbuild in gitlab 2024-12-05 03:04:37 I only see the apkbuild, but I see the source line in the apkbuild file, so I can try downloading it to the directory alongside the apkbuild file and see if that works 2024-12-05 03:04:45 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/mpv/meson-libcaca-version.patch 2024-12-05 03:05:13 This is what you're looking for :) and right, drop it in the same directory as your apkbuild 2024-12-05 03:07:58 How did you find that? The only thing I see in the source line of the apkbuild is what looks like a link to the original github release page 2024-12-05 03:08:05 also, thank you! 2024-12-05 03:18:22 Our sources are both links and local files 2024-12-05 03:18:25 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/mpv/APKBUILD#L64 2024-12-05 03:18:31 Or can be I mean 2024-12-05 03:18:39 So that line denotes the patch file in gitlab 2024-12-05 03:24:21 Thank you! The abuild commands worked, but when I checked my ~/packages I saw apk files that were similar but not what I was trying to install. Then I rechecked my apkbuild file and I swear it's different now. Before it was about 'mpvpaper' but now it's about just 'mpv' 2024-12-05 03:25:10 Different packages version and everything, I don't know how but somehow it changed my apkbuild and didn't install mpvpaper like I wanted. Not sure what went wrong 2024-12-05 03:31:39 I tried it again and it worked. Weird. Appreciate the help! 2024-12-05 03:33:52 Hmm well the resources I shared were for the mpv package since thats what the error line you shared made it seem like. But if you got it then awesome! 2024-12-05 05:49:39 Greetings!... (full message at ) 2024-12-05 05:54:25 > what packages should be installed 2024-12-05 05:54:27 When? 2024-12-05 05:54:43 > also *networking* is always ON? 2024-12-05 05:54:49 for building apks 2024-12-05 05:54:52 At the moment it is, but that may change in the future 2024-12-05 05:55:35 ildar[m]: alpine-sdk is expected to be installed, the rest should come via dependencies 2024-12-05 05:55:45 so is it written somewhere? Because I followed the wiki and found the reality is very different 2024-12-05 05:56:04 "should" but doesn't 2024-12-05 05:56:42 e.g. I see that `git` is there always 2024-12-05 05:57:23 check the dependencies of alpine-sdk 2024-12-05 05:58:17 em.. 1 second.. 2024-12-05 05:59:49 ah.. indeed. 2024-12-05 06:00:41 I still was surprised a package failed to build because expected networking available 2024-12-05 06:00:59 qemu on edge:... (full message at ) 2024-12-05 06:01:31 ildar[m]: _if_ you use rootbld, then network is cut-off unless you provide the 'net' option 2024-12-05 06:02:17 also is unprivileged LXC container ok for building? 2024-12-05 06:02:41 yes 2024-12-05 06:02:47 I build in one 2024-12-05 06:04:26 is this kinda all one needs to sucsessfully build any APKBUILD from the repo? 2024-12-05 06:04:49 Yes 2024-12-05 06:08:33 I'm currently struggling with reproducing dotnet8-stage0 build. And in a LXC container `msbuild` definitely befaves a little differently, rejecting some of its build files (aka csproj). 2024-12-05 06:09:02 Alpine definitely has it built in some point in the past 2024-12-05 06:11:18 Last month even: https://build.alpinelinux.org/buildlogs/build-3-21-x86_64/community/dotnet8-stage0/dotnet8-stage0-8.0.110-r0.log 2024-12-05 06:12:09 oh! thanks. I'll compare logs, maybe I'll find why 2024-12-05 06:34:53 Could somebody please merge this for me? 2024-12-05 06:34:53 !76452 2024-12-05 06:40:16 done 2024-12-05 07:17:46 Thank you! 2024-12-05 07:52:19 is there a point for rootbld to not have networking? i swear everytime someone wants to use it just ends up cursing because no one ever adds net option 2024-12-05 08:07:16 ncopa: I'm here this morning if you need help with the mkinitfs and communication 2024-12-05 08:10:52 Thanks for merging https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/186 2024-12-05 08:11:08 It was marked as Draft waiting for feedback (e.g: the crypt options on /usr), and your thoughts on https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/186#note_455673 2024-12-05 08:12:46 To the question of whether that will break something, most likely not. It indeed fixed the setup of the user that otherwise broke 2024-12-05 08:13:02 And doesn't affect regular setups 2024-12-05 08:13:51 jitsi-videobridge appears to hang on ppc64le? 2024-12-05 09:24:11 are some changes to mkinitfs very device specific ? 2024-12-05 09:29:24 no hooks feature yet 2024-12-05 09:44:19 without hooks, mobile device specific need would be difficult, unless pmOS wants to re-compile it 2024-12-05 09:46:11 pmOS has its own mkinitfs+initramfs for a reason. Putting together alpine flexibility, and pmOS crazy usecases for booting would be madness 2024-12-05 09:48:34 then i don't understand pmOS facination with AL, +mainline kernel. Will al kernel work there? 2024-12-05 09:48:55 They have divulged from way AL publishes downloads 2024-12-05 09:49:18 Pls be careful while trying to implement all features asked for 2024-12-05 09:50:12 in short they are new/distint distro, and have difficulty in supporting old devices 2024-12-05 09:50:35 They are not even publishing device specific modloop file 2024-12-05 09:50:49 ==================== 255 passed, 1 skipped, 517 warnings in 1642.90s (0:27:22) ===================== 2024-12-05 09:50:53 that was the rc7 2024-12-05 09:51:02 i say we are ready for release 2024-12-05 09:51:11 \o? 2024-12-05 09:51:17 \o/ 2024-12-05 09:51:38 the only thing that annoys me is busybox awk is broken 2024-12-05 09:52:54 ikke: were you able to test mount /usr on separate partition and upgrade? 2024-12-05 09:55:49 No 2024-12-05 09:57:08 ncopa: I'm on it, since I have my setup from last time 2024-12-05 09:57:30 I did test that it works 2024-12-05 09:57:48 But doing the upgrade now with rc7 2024-12-05 10:08:31 ncopa: works 2024-12-05 10:09:08 Indeed I bumped into an issue with alpine's default setup, because cut from busybox is in /usr by default 2024-12-05 10:09:24 That required some manual adjustments in 3.20 2024-12-05 10:09:25 i am not able to make a separate /usr work in 3.20 2024-12-05 10:09:36 Upgrading to 3.21 just fixes it 2024-12-05 10:09:47 what manual adjustment is needed in 3.20? 2024-12-05 10:10:32 For example cut. Some early init service needs it 2024-12-05 10:10:36 But it's in /usr 2024-12-05 10:11:06 So people with /usr on different partition will have manually copied it to /bin 2024-12-05 10:11:48 ok 2024-12-05 10:11:56 ACTION uploaded an image: (68KiB) < https://matrix.org/oftc/media/v1/media/download/ASHdU53wpWxChcK7nba_z67t2uW6s4DFk7_VL_niDCpC3WFAdV-9WuCWhAiYUR5JtdXT5pWfEfG9B68Wjk--b-FCeT3mcNYAAG1hdHJpeC5vcmcvQkF5bVVmQXBoaXFkd2VCTEhiWEN0U29M > 2024-12-05 10:11:57 it is basically not supported already 2024-12-05 10:11:59 That's fixed in 3.21 2024-12-05 10:12:18 yeah 2024-12-05 10:12:21 Not without a remarkable amount of manual intervention 2024-12-05 10:12:31 ok 2024-12-05 10:12:43 upgrading 3.21 did make things beetter indeed 2024-12-05 10:13:16 basically, separate /usr has not been supported in 3.20 2024-12-05 10:13:27 if you do that, you are basically on your own 2024-12-05 10:13:34 3.21 does make it better 2024-12-05 10:13:44 i did get a fsck error due to /usr being mounted though 2024-12-05 10:13:58 but it is still better that current 2024-12-05 10:14:03 alright 2024-12-05 10:14:08 PabloCorreaGomez[m]: good job 2024-12-05 10:14:11 thanks! 2024-12-05 10:14:41 thank you for your patience! 2024-12-05 10:14:48 writing a note on "how to migrate from 3.20 to 3.21" would help 2024-12-05 10:26:10 i sometimes to /usr re-mounts, and 2024-12-05 10:26:20 this /bin/busybox mkdir -p /usr/bin /usr/sbin 2024-12-05 10:26:29 and /bin/busybox --install -s 2024-12-05 10:26:33 helps 2024-12-05 10:26:54 and yes with corrent $PATH set 2024-12-05 10:26:59 correct 2024-12-05 10:29:22 i dont think we should spend too much time on something that is not even supported to begin with 2024-12-05 10:31:05 we would have users wanting to upgrade 2024-12-05 10:31:35 and some would definetly try upgrading SSH 2024-12-05 10:31:59 and get locked out of their remote boxs` 2024-12-05 10:37:14 upgrading openssh should not result in lock out. we made post-upgrade auto restart sshd if needed 2024-12-05 10:41:17 sounds things can be dealt with post-release 2024-12-05 10:48:11 atleast in main/ 2024-12-05 10:50:43 I renamed https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.21.0 (removed Draft) 2024-12-05 10:58:38 Para, Preparations for /usr-merge , seems does not concern users 3.21 2024-12-05 10:58:45 last line, Please note that this setup is already not supported. 2024-12-05 10:59:01 i added that 2024-12-05 10:59:02 maybe, Please note that this setup is currently not supported. 2024-12-05 10:59:13 👍 2024-12-05 10:59:14 thanks! 2024-12-05 10:59:41 i dont know if it ever has been 2024-12-05 10:59:53 "currently not supported" sounds like it will be supported in the future 2024-12-05 11:00:06 it was not supported in 3.20 and I dont think it ever has 2024-12-05 11:00:33 maybe: "Please note that this setup is not supported. " 2024-12-05 11:05:42 That could make sense. Maybe "officially" supported? 2024-12-05 11:06:11 good 2024-12-05 11:06:21 I have updated https://gitlab.alpinelinux.org/ncopa/alpine-mksite/-/blob/release-notes-3.21/posts/Alpine-3.21.0-released.md 2024-12-05 11:06:39 PabloCorreaGomez[m]: I included your suggestions but tried to shorten the text as much as possible 2024-12-05 11:06:56 ncopa: read, it looks good 2024-12-05 11:08:46 agree, looks good! 👍 2024-12-05 11:11:29 algitbot: fetch sofas+beer for all 2024-12-05 11:12:13 lol 2024-12-05 11:12:14 And thanks a lot for the help with this 2024-12-05 11:12:19 likewise 2024-12-05 11:21:55 ok I think the release notes are more or less done now 2024-12-05 11:30:45 Is anyone aware what apk-tools version 3 be in Alpine? 3.22, 3.23 or later? 2024-12-05 11:31:19 I guess the transition will be painful... 2024-12-05 11:32:06 ildar[m]: apk-tools v3 will still support apkv2 packages / indexes, so we will first upgrade to apk-tools v3 without changing the rest 2024-12-05 11:32:27 oh! great! 2024-12-05 11:32:47 So potentially in 3.22 2024-12-05 11:34:00 PabloCorreaGomez[m]: should I merge this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76438 2024-12-05 11:34:11 it takes 25 mins to build on riscv64 2024-12-05 11:34:20 which is acceptable 2024-12-05 11:34:48 im merging it 2024-12-05 11:37:59 ncopa: thanks! We could always backport 2024-12-05 11:38:11 But if it goes in, that's good 2024-12-05 11:39:20 less work to merge it now. so I did 2024-12-05 11:43:16 backporting a downgrade is tricky, since apk will not automatically downgrade packages 2024-12-05 12:08:28 Ok, thanks! 2024-12-05 12:10:44 All builders seem idle now :D 2024-12-05 12:14:57 they are 2024-12-05 12:16:21 Since you merged the GNOME Software upgrade, I wrote https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.21.0#GNOME_47 2024-12-05 12:18:40 alpine/aports:master | Natanael Copa | ===== release 3.21.0 ===== | http://dup.pw/alpine/aports/59962f87e460 2024-12-05 12:20:07 yay! 2024-12-05 12:21:17 Congrats everybody for the hard work! 2024-12-05 12:26:13 oh no, new kernels are coming up 2024-12-05 12:35:28 ok to merge https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/91 ? 2024-12-05 12:35:38 🎉 2024-12-05 12:36:01 ncopa: i think so 2024-12-05 12:36:16 Think so too 2024-12-05 12:39:27 thanks! 2024-12-05 12:39:36 i added the contributors at the bottom 2024-12-05 12:39:57 https://wwwtest.alpinelinux.org/posts/Alpine-3.21.0-released.html 2024-12-05 13:00:10 \o/ thanks for making the donuts, everybody 2024-12-05 13:01:49 I thought wlroots 0.18 was more interesting than sway 1.10, as it is used by several compositors 2024-12-05 13:02:19 perhaps could be added without removing sway from the list? 2024-12-05 13:06:57 create an MR 2024-12-05 13:07:25 i have no idea what the general crowd find important 2024-12-05 13:08:34 i dont know if people reading the news will see "wlroots 0.18" and think "Oh wow! they ship wlroot 0.18! maybe I should test Alpine" 2024-12-05 13:09:25 i can delete sway if sway 1.10 is uniniteresting 2024-12-05 13:09:34 i don't understand, what's the problem? (as someone who runs both sway and river) 2024-12-05 13:10:00 the problem is that we cannot list all 1000 packages. people will not be able to read it all 2024-12-05 13:10:05 the shorter list the better 2024-12-05 13:10:20 ah. i would say wlroots then 2024-12-05 13:12:14 looks like wlroots is a library? 2024-12-05 13:12:23 is it like qt? 2024-12-05 13:12:54 it is, but i suspect most people who are getting into things like sway care about that. 2024-12-05 13:13:12 i mean, gcc14 is a pretty big thing 2024-12-05 13:13:27 gnome 47 means something an KDE plasma 6.2 (I suppose) 2024-12-05 13:14:40 but who cares about things like: Noticable updates: libxt 1.3.1 2024-12-05 13:15:09 I have no idea 2024-12-05 13:15:42 I have to trust you on this. If you say that wlroots 0.18 is a big thing, equivalent to GNOME 47 and llvm 19, then I change it 2024-12-05 13:15:58 for someone booting into $fat_desktop_environment, they don't care, but the wlroots end of things is a different crowd 2024-12-05 13:16:10 just my opinion though 2024-12-05 13:17:08 this does not tell me anything https://gitlab.freedesktop.org/wlroots/wlroots/-/releases/0.18.0 2024-12-05 13:18:00 please note that the release notes is targeted for mass media 2024-12-05 13:18:20 where many dont even use Alpine 2024-12-05 13:19:11 well, there's a constellation of wlroots-based compositors... which was maybe omni's point, which if so, i agree with 2024-12-05 13:20:08 sorry for sidetracking you, sway is a compositor, wlroots is used by sway, cage, cagebreak, river, labwc and a couple of compositors in testing/ 2024-12-05 13:20:47 and wlroots 0.18 solved some issues I've been having for a couple of years as a sway user 2024-12-05 13:21:22 I added it to the wiki release notes draft because I thought it was interesting in a similar vein as KDE and Qt upgrades 2024-12-05 13:21:43 is this something that would be interesting for mass media? 2024-12-05 13:22:31 to that point, probably not imo 2024-12-05 13:22:46 i mean, we have sway in setup-desktop 2024-12-05 13:23:02 maybe if "mass media" includes phoronix, for example? 2024-12-05 13:23:34 again, sorry for sidetracking 2024-12-05 13:23:42 https://www.phoronix.com/news/Sway-1.10-Released 2024-12-05 13:23:52 it probably doesn't matter, people interested can read the more detailed release notes on the wiki 2024-12-05 13:24:10 https://www.phoronix.com/news/wlroots-0.18-Released 2024-12-05 13:24:17 yeah 2024-12-05 13:25:38 I just thought it curious to focus on sway (that I use and really like!) and not wlroots 2024-12-05 13:27:03 as I said, I have no clue 2024-12-05 13:27:10 i just copied from 3.20 2024-12-05 13:27:31 if sway continues to be in setup-desktop i think that decides it, probably. 2024-12-05 13:27:53 I think sway is fairly popular 2024-12-05 13:28:03 i just don't know if that itself (sway in setup-desktop) was a great idea :) 2024-12-05 13:28:16 i have no clue either :) 2024-12-05 13:28:54 i've mostly moved on to river, but sway anchors the whole wlroots scene 2024-12-05 13:30:44 @fluix, I got an MR here that upgrades fastapi and starlette so we can upgrade grommunio. Is that OK for you? !76517 2024-12-05 13:30:45 how about we do: sway 1.10 / wlroots 0.18 2024-12-05 13:30:52 *so we can move 2024-12-05 13:32:16 ncopa: imo just listing sway is fine. the others are more niche, and hyprland moved off wlroots. 2024-12-05 13:38:13 thanks 2024-12-05 13:39:15 alright, I'll publish it then 2024-12-05 13:53:14 wow... this was fast https://www.phoronix.com/news/Alpine-Linux-3.21 2024-12-05 13:54:03 lol 2024-12-05 13:54:32 Probably a notification from the rss feed 2024-12-05 14:00:54 phoronix is on top of things today haha 2024-12-05 14:04:20 I think it would be nice to have some public thing to compare package versions between releases, perhaps on pkgs.a.o, probably without pkgrel information 2024-12-05 14:04:59 as the release notes in the wiki aren't exhaustive either 2024-12-05 14:05:28 hmm yeah 2024-12-05 14:05:44 people can use apk version 2024-12-05 14:06:58 sure, but that just compares what you have installed to what is available in your configured repos, right? 2024-12-05 14:08:20 yea 2024-12-05 14:09:45 what I'm thinking of would be something that could also be linked to from release notes, like "see full list of upgraded aports: https://pkgs.a.o/something?3.20-stable..v3.21.0" 2024-12-05 14:10:42 is 3.21 out or is that post from future 2024-12-05 14:11:21 was just released :) 2024-12-05 14:11:21 I see its tagged 2024-12-05 14:11:34 \o/ congrats everyone for the hard work 2024-12-05 14:11:47 today the beer is on me, enjoy 2024-12-05 14:32:29 Congrats with the release everyone! 2024-12-05 14:43:13 worth to mention in the Release_Notes_for_Alpine_3.21.0 the net6 and some apps moved to from community? 2024-12-05 14:50:55 yeah 2024-12-05 14:55:33 can I do it or you do it? want to review the text before? 2024-12-05 14:58:08 please go ahead and do it 2024-12-05 14:58:11 i think you can just apply it 2024-12-05 14:58:15 yeah 2024-12-05 14:58:54 PureTryOut (matrix.org): FYI i created the release notes for 3.22.0 https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.22.0 2024-12-05 15:00:24 👍 2024-12-05 15:00:30 Thanks for calling it Draft 2024-12-05 15:00:44 At least one project on gh was confused and thought 3.21 was already released 2 months ago :P 2024-12-05 15:03:57 ok I added there, hope it looks good 2024-12-05 15:05:31 \o/ 2024-12-05 15:20:00 ikke: can you explain the rationale behind the email tags? https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/issues/37 2024-12-05 15:20:13 Seems like that behavior is indeed expected 2024-12-05 15:20:56 The goal was to match foo+tag@gmail.com if the user has foo@gmail.com as address 2024-12-05 15:21:12 (former in aports, latter in gitlab) 2024-12-05 15:22:52 why does kernel always release directly after alpine makes release 2024-12-05 15:24:50 it could be worse than the kernel :) like, another python 2024-12-05 15:25:57 coz, dev there are sure it works now, so lets push new one 2024-12-05 15:29:30 someone update channel topic pls 2024-12-05 15:31:50 ncopa: how do you know 6.12.x will be next lts ? 2024-12-05 15:32:07 vkrishn: usually last kernel of the year 2024-12-05 15:32:49 ok, interesting method 2024-12-05 15:34:10 ikke: right, question is which purpose does the tag provide? 2024-12-05 15:34:43 Why do those tags exist in the first place? To trick spammers? 2024-12-05 15:35:09 https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/blob/master/Services/AutoMaintainer/definition_test.go?ref_type=heads#L243 2024-12-05 15:35:20 PabloCorreaGomez[m]: generally not to trick spammers, but to find the source of spam 2024-12-05 15:35:35 spammers scrub those off their lists now 2024-12-05 15:35:41 fossdd: thanks, will start writing! 2024-12-05 15:36:00 ikke: so that means, aports-qa-bot does not need the tags at all then? 2024-12-05 15:36:39 for foo+tag@gmail.com we're returning two maintainers: foo+tag@gmail.com, and foo@gmail.com 2024-12-05 15:36:44 google is, in theory, adding aliases at some point, but at first that will only be for downloading apps off the store (delinking app publishers from google account credentials) 2024-12-05 15:37:09 I assume for your input, that then we can just do foo@gmail.com? 2024-12-05 15:38:03 PabloCorreaGomez[m]: yes, for gmail foo+bar@gmail.com will be sent to the inbox of foo@gmail.com 2024-12-05 15:38:47 PabloCorreaGomez[m]: I guess the logic is/was that it could be either address that is added on the account 2024-12-05 15:38:54 so it would look for which one matches 2024-12-05 15:39:38 some have foo+bar@gmail.com as their gitlab email address as well, so just checking for foo@gmail.com in that case would miss those 2024-12-05 15:39:46 Ok, then now I understand how to fix it. Thank you 2024-12-05 15:41:49 nice 2024-12-05 17:52:37 seems like 6.12 kernel is now the next official LTS 2024-12-05 17:53:16 https://www.kernel.org/category/releases.html 2024-12-05 17:53:22 Yes, it's listed there now 2024-12-05 18:07:40 nice 2024-12-05 18:15:23 yep 6.12 it is :) 2024-12-05 18:16:13 all kernel versions EOL is Dec, 2026 2024-12-05 18:16:20 including 6.12 2024-12-05 18:16:51 EOL dates can be extended 2024-12-05 18:26:23 Dec 2026 is the day linux dies 2024-12-05 18:34:47 seems like "year end predictive method" for making 6.13 lts did not work 2024-12-05 18:35:24 else might have to code on sofa on xmas day watching tv 2024-12-05 18:46:01 I think every LTS will be 2 years here on 2024-12-05 18:46:30 "The "projected EOL" dates are not set in stone. Each new longterm kernel usually starts with only a 2-year projected EOL that can be extended further if there is enough interest from the industry at large to help support it for a longer period of time." 2024-12-05 19:18:29 hmm we will have to see by 2026 I guess 2024-12-05 19:43:05 i suspect we may see docker release a new 27.x soon (just got notification for backports on 23.x and 25.x)... 🤷 2024-12-05 19:52:24 ikke: i have started to test with some dummy old data, https://b.infosight.in/alpine 2024-12-05 19:52:48 openpage Mqtt/Build 2024-12-05 19:53:23 will do other mqtt nodes and then gitlab api 2024-12-05 19:53:49 and analytics logic then 2024-12-05 19:59:55 formated data comes from redis 2024-12-05 20:01:23 need to figure out un-interrupted way to collect msg.a.o 2024-12-05 20:01:51 and filter duplicates 2024-12-05 22:19:26 is the amove function documented anywhere? Can't find it in https://wiki.alpinelinux.org/wiki/APKBUILD_Reference 2024-12-05 22:29:21 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L71 2024-12-05 22:54:14 ncopa: Regarding mkinitfs: I have tried to come up with a generic way to specify which (potentially nested) partitions should be mounted where. I haven't found a solution that seemed good enough. Should I create an issue with my current ideas so we can discuss this? (A solution should for example allow removing any /usr special casing) 2024-12-05 22:56:27 I unfortunatly missed the moment the cryptusr* options were added. 2024-12-06 00:28:20 fabricionaweb: thanks 2024-12-06 04:05:56 Thermi_: I've been busy with studying for the past months. I know this isn't good as a maintainer but for others: feel free to approve upgrades to my pkgs (or maintainer takeover requests) in the meantime. Hopefully whoever makes the MR + a dev is good enough review. I will be back in January to properly maintain stuff. sorry 2024-12-06 06:31:33 fluix: No worry, live happens. 2024-12-06 06:45:50 ty <3 2024-12-06 07:03:31 in gnome section on 3.21 release notes it's wrong link to gitlab issue 2024-12-06 07:04:01 "gnome-software has been held back to version 45, after several regressions in the apk plugin on update. See #16663 for more details." 2024-12-06 07:04:22 it's a package request 2024-12-06 07:04:39 ? 2024-12-06 07:07:05 is this the correct issue? https://gitlab.alpinelinux.org/alpine/aports/-/issues/16637 2024-12-06 07:28:33 pj: oh yes youre right 2024-12-06 07:33:23 hello, congrats for 3.21! now that release happended, could somebody merge !73153 please? 2024-12-06 10:09:50 with 3.21 out is 3.17 EOL ? 2024-12-06 10:10:11 yep 2024-12-06 10:26:48 to update lxc images https://github.com/lxc/lxc-ci/pull/860/files have I forget something? 2024-12-06 11:19:46 I'm writing an init.d script - looking at some of the others (e.g. seatd) they pass stderr to the syslogs but not stdout. Is there a reason for this? Where should users go if they want to inspect the stdout logs? 2024-12-06 12:15:06 services generally don't log to stdout, only syslog or stderr. stdout is rarely used. If you need two log channels (typically stderr and stdout) then you should probably write your script in a way that captures the second log channel manually. 2024-12-06 12:40:11 I can't find the apk-tools v3 (pre-)announcement. 2024-12-06 12:40:11 Q: what are the benefints of apk-tools v3 besides the new apk format? 2024-12-06 13:13:49 ildar: there isn't one 2024-12-06 13:14:10 benefits: binary db and package format, apk operations log 2024-12-06 13:16:19 newer hash format(s) 2024-12-06 13:17:45 (v2 is also binary, but it's just tar with custom headers, v3 will be just binary data) 2024-12-06 13:43:43 IC thank you 2024-12-06 14:26:47 TIL if you symlink repo2/package to repo1/package, abuild creates .apk files under repo2 still 2024-12-06 14:27:53 i guess it makes sense if it's using stat or something (haven't looked) to derive that information 2024-12-06 14:29:56 readlink. yep. 2024-12-06 15:59:05 Could anybody please review and merge !76517 Thanks! 2024-12-06 18:58:06 midasi: https://build.alpinelinux.org/buildlogs/build-edge-aarch64/testing/py3-fastapi/py3-fastapi-0.115.6-r0.log 2024-12-06 18:58:26 cyclic dependency 2024-12-06 20:04:48 done some basis metrics with mqtt top nodes, build/,git/, https://b.infosight.in/alpine/ 2024-12-06 20:05:12 raw data will be there for last 30days, https://m.insteps.net/mqtt/alpine/ 2024-12-06 20:06:29 ikke: having datestamp in there would be helpful 2024-12-06 20:08:54 any suggestions on improving UI or functionality is welcomed 2024-12-06 20:48:42 is there a syntax in apkbuild to recommend packages? 2024-12-06 20:48:46 or optional dependnecies 2024-12-06 20:51:30 no 2024-12-06 20:51:31 No, there is no such syntax 2024-12-06 20:52:11 bummer 2024-12-06 20:52:36 i guess i'll nuke the binutils depends in !76558 then 2024-12-06 20:53:54 you can do optional dependencies through install_if 2024-12-06 20:54:49 They would be opt-out though, not opt-in 2024-12-06 20:55:11 yeah which is the right way to do them 2024-12-06 20:55:45 if there's stuff that most people shouldn't have installed, then it should not be any kind of dependency in the first place 2024-12-06 20:56:17 opinion noted 2024-12-06 20:56:45 thanks for your review sertonix[m] 2024-12-06 21:04:19 and very more often than not there isn't much that 'should be' installed. 2024-12-06 21:15:33 omni/ikke: Thanks, will take care of it 2024-12-06 21:19:34 midasi: is py3-fastapi more than a test dependency for py3-sqlmodel? (the issue is that these two depend on eachother) 2024-12-06 21:20:24 omni: not sure, let me check 2024-12-06 21:21:27 on the topic of possibly unnecessary dependencies =) 2024-12-06 21:22:59 midasi: you added the py3-sqlmodel as it is needed for some new tests of the newer version of py3-fastapi, right? 2024-12-06 21:23:38 there are also other ways of skipping python tests than rm 2024-12-06 21:27:31 omni: yes, exactly 2024-12-06 21:31:37 midasi: so, if possible, py3-fastapi should be removed as a dependency for py3-sqlmodel 2024-12-06 21:32:05 and py3-sqlmodel tests that require py3-fastapi disabled 2024-12-06 21:34:29 omni: are you sure? sqlmodel is a part of fastapi (same author) and is used as DB layer for fastapi application 2024-12-06 21:34:58 wouldn't it make more sense to exclude the sqlmodel tests in py3-fastapi? 2024-12-06 21:35:36 I'm quite sure we can't have cyclic dependencies 2024-12-06 21:37:50 The dependency solver cannot handle it and the resulting order is undefined 2024-12-06 21:38:39 yes clear, the only question is how to resolve the dependency 2024-12-06 21:39:11 You have to remove one from the other 2024-12-06 21:39:30 but also not sure it should have been in $depends to begin with, but perhaps $checkdepends 2024-12-06 21:39:50 still wouldn't fix the issue, to move it there though 2024-12-06 21:39:55 indeed 2024-12-06 21:40:23 as mentioned above, sqlmodel is like a part of fastapi (db layer) and written by the same author 2024-12-06 21:40:51 the depencency solver doesn't care 2024-12-06 21:40:52 imho it would be better to remove the checkdependency in py3-fastapi 2024-12-06 21:41:09 Yeah, that's fine 2024-12-06 21:41:15 sure 2024-12-06 21:41:32 I just thought you added py3-sqlmodel to be able to run new py3-fastapi tests 2024-12-06 21:44:53 but looking at https://github.com/fastapi/sqlmodel/blob/main/requirements.txt I am not sure the $depends in py3-sqlmodel is correct 2024-12-06 21:45:28 that some should be moved to $checkdepends 2024-12-06 21:45:50 but I haven't looked deeper than at the requirements files 2024-12-06 21:46:50 perhaps the maintainer is sloppy and don't add things to requirements.txt because they're included through the inclusion of requirements-tests.txt 2024-12-06 22:00:07 omni: ok, we can do both 2024-12-06 22:05:23 midasi: you can skip tests by using `--ignore path/to/test-script.py` or `-k name_of_test and not name_of_other_test and not name_of_third_test` 2024-12-06 22:18:16 omni: good to know, thanks! 2024-12-06 22:39:09 omni: MR is ready !76594 2024-12-06 23:13:13 ikke: could you point to codes that pushes mqtt msgs like "building v20240923-4849-g09816f34442" pls ? 2024-12-06 23:32:38 omni: could you please merge as well !76605? Thanks 2024-12-06 23:47:35 hmm... 2024-12-06 23:48:13 midasi: I unbumped pkgrel, because checkdepends (and makedepends) are only used during build, thus no need to rebuild the package 2024-12-06 23:48:37 but then I saw that it doesn't depend on anything, I think it should at least depend on python3 2024-12-06 23:53:53 omni: yes, I guess you're right. Thanks for the change. 2024-12-06 23:56:33 np 2024-12-07 12:29:24 skarnet: thanks, makes sense that services only generally log to stderr 2024-12-07 12:31:14 omni: no need for that, abuild already figures out itself that it needs to depend on python3 when it finds Python scripts in the package 2024-12-07 12:37:21 hi, now that we have released 3.21, could someone review this one? !76378 2024-12-07 14:32:08 I still thought we had a policy in adding python3 to depends on all python aports anyway, if nothing has changed recently, I've seen it talked about multiple times 2024-12-07 14:34:48 That's how I've been handling my python aports. And ruby. It makes sense, you need the language interpreter to leverage the library. 2024-12-07 18:58:34 hey guys, I'm trying to use mkimage but when I run it with any profile I get "cp: can't stat ' ' : No such file or directory", does anyone know why it happends and how to fix it? 2024-12-07 19:28:23 ouch, could that too be a busbybox 1.37 regression? 2024-12-07 19:29:16 user32_dll: what if you try installing the coreutils package and try again? 2024-12-07 19:29:53 I can try that 2024-12-07 19:33:12 well, same error 2024-12-07 19:33:41 ok, yeah, so perhaps not busybox then 2024-12-07 19:33:53 this is mkimage from u-boot-tools, right? 2024-12-07 19:34:03 and btw busybox's version is 1.37.0-r8 2024-12-07 19:34:26 uh, no, the script from the git 2024-12-07 19:34:38 from aports 2024-12-07 19:35:39 oh, right :facepalm I jsut searched package contents for mkimage 2024-12-07 19:36:15 well, I guess I should have been more precise 2024-12-07 19:39:04 and how you run it used to work before? 2024-12-07 19:39:30 still, that error reminds me of things we've seen since the busybox 1.37 upgrade 2024-12-07 19:39:37 no, I never used it before lol 2024-12-07 19:39:46 I'm trying to figure out how to use it 2024-12-07 19:40:01 ah, so it *could* be user error ;D 2024-12-07 19:40:17 I'm not sure I've ever used that myself 2024-12-07 19:40:19 well ig I could downgrade it 2024-12-07 19:40:28 do you have the gawk package installed? 2024-12-07 19:41:13 I'm just guessing here (but the script does call awk, and we've had issues with busybox awk since the upgrade) 2024-12-07 19:41:45 gawk is installed 2024-12-07 19:41:58 ok, then it shouldn't be that either 2024-12-07 20:36:38 omni: so you have no idea of how to fix it? 2024-12-07 20:41:47 user32_dll: sorry, no, and I went back to doing other things 2024-12-07 20:41:53 I hope someone else will chime in 2024-12-07 20:45:51 omnin: ok, well, thanks for the help, and ig I'll ask tomorrow, not sure someone else will chime in 2024-12-07 20:45:58 I might also ask on the forum 2024-12-07 20:46:08 but for that I'll have to create an account 2024-12-07 20:46:12 you could also open an issue in our gitlab 2024-12-07 20:46:34 and for that I think you could use a regular github or gitlab.com account 2024-12-07 20:47:43 yeah good idea 2024-12-07 20:47:51 ig I'll create another gitlab account 2024-12-07 21:05:21 mkimages is working for me on 3.21 - I use it regularly to build customized alpine iso images 2024-12-07 21:06:13 liske: well, that's weird 2024-12-07 21:07:02 it is a CI job running in alpine:$RELEASE and it just installs these additional packages: alpine-sdk build-base apk-tools alpine-conf busybox fakeroot syslinux xorriso squashfs-tools mtools dosfstools grub-efi 2024-12-07 21:07:30 how do you call mkimages? 2024-12-07 21:11:59 hello 2024-12-07 21:13:34 the kernel issued me a warning and i don't know exactly how to proceed or what this is about 2024-12-07 21:13:37 cat /proc/sys/kernel/tainted 2024-12-07 21:13:39 512 2024-12-07 21:14:01 kernel: [19894.781653] WARNING: CPU: 0 PID: 3337 at drivers/gpu/drm/ttm/ttm_bo.c:252 ttm_bo_release+0x298/0x2f0 [ttm] 2024-12-07 21:14:23 the kernel was not tainted before 2024-12-07 21:42:24 liske: I just run ~/aports/scripts/mkimage.sh (but it's on another machine so I can't give you the full command) 2024-12-07 21:43:27 I followed https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image_with_mkimage 2024-12-07 21:45:13 well, gtg, cya! 2024-12-08 00:09:58 hey team, I'm trying to update the nimble package manager for the nim programming language, but the build system is a bit different, and the nim build system wants to build nimble by pulling it and its deps in at specific git tags (which has a different version number and is currently packaged separately). Annoying, but is this reasonable and is it ok to just replace the current nim + nimble packages with a single nim p 2024-12-08 00:09:58 ackage? 2024-12-08 01:18:35 tokyovigilante: I don't think so, but I have commented on your MR 2024-12-08 01:52:38 thanks, that’s really helpful. will work on it a bit and resend. 2024-12-08 10:46:42 ncopa: ping on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76662, it's blocking CI for some project 2024-12-08 12:31:21 hey guys! I created the issue https://gitlab.alpinelinux.org/alpine/aports/-/issues/16712 , help would be appreciated 2024-12-08 13:05:41 Hello :) 2024-12-08 13:10:07 I'm wondering about the solution for the abuild empty arch: https://gitlab.alpinelinux.org/alpine/aports/-/commit/26fa920b8980f36bbd12dd503a5533a1b577aeb7 2024-12-08 13:12:24 Could we check for error code from arch=$(abuild...) ? Another suggestion is to check for valid arches , and not just if the variable is empty? 2024-12-08 13:38:56 hello, could someone have a look at !73153 please? 2024-12-08 15:11:20 there seems to be a maintainer that still "maintains" even though they haven't contributed for 9 years. what's the approach in a situation like this? 2024-12-08 15:11:24 relevant: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66159#note_428349 2024-12-08 15:24:51 I don't think that's the only one 2024-12-08 15:25:14 and so far the approach has been to maintain such aports collectively 2024-12-08 15:25:44 that specific aport as an example https://git.alpinelinux.org/aports/log/?qt=grep&q=nagios-plugins 2024-12-08 17:38:33 Morning everyone. I'm trying to package gxlimg (https://github.com/repk/gxlimg) from a non-alpine distro, and using `rootbld` I get a weird error after it sets up the chroot: 2024-12-08 17:38:59 > bwrap: Can't chdir to /path-to/aports/testing/gxlimg: No such file or directory 2024-12-08 17:39:36 If that matters I'm using arch's abuild package 2024-12-08 17:48:38 f_: when you mentioned "/path-to/aports", is it in ~/aports? 2024-12-08 17:48:46 no 2024-12-08 17:48:49 that error occurs if it's not ~/aports 2024-12-08 17:48:58 Ah. 2024-12-08 17:49:19 abuild rootbuild sort of defaults to it 2024-12-08 17:49:38 IIRC you should be able to override it with APORTSDIR 2024-12-08 17:50:00 think in buildrepo it can be overrided, not sure for rootbld 2024-12-08 17:50:26 s/overided/overriden/ 2024-12-08 17:54:42 There it works now, thanks! :D 2024-12-08 18:02:12 thanks as well, didn't know it was an option in abuild 2024-12-08 18:13:53 great, looks like it all worked out and I now submitted !76721 🥳 2024-12-08 18:18:15 wow did that take a long time for me to get to it. 2024-12-08 18:21:17 not sure where's the right place to report this, but opening https://gitlab.alpinelinux.org/-/user_settings/active_sessions causes a 500 error for me 2024-12-08 18:25:29 kpcyrd: Works for me. 2024-12-08 18:25:54 The only thing I noticed not working for me is setting a profile picture - it results in a garbled image 2024-12-08 18:26:18 but that might just be me 2024-12-08 18:32:25 omni: I see. It's a little difficult because MRs might not get addressed, though, as only the maintainer gets assigned and thus pinged 2024-12-08 18:33:18 ping !75790 and !75949 then, I guess. not sure if they won't be seen if they're not pinged 2024-12-08 20:39:23 what would be TZ for git.a.o/aports ? its not UTC 2024-12-08 20:45:02 ah, i think TZ for mqtt service is more important 2024-12-08 20:47:07 We keep our servers on UTC 2024-12-08 21:20:18 ikke: thanks, will see if mosquitto_sub can use TZ 2024-12-08 21:21:57 if adding timestamp to msgs.a.o is not finalized, pushing same msgs to redis in append mode without any timestamp will also help 2024-12-08 21:22:29 redis can be RO for public 2024-12-08 22:17:08 I want to change my email in packages I maintain. Do I need to just change it in APKBUILDS or is there something else I need to do? 2024-12-08 22:57:28 you need to also bump pkgrel so that they are rebuilt and packaged witht the new information 2024-12-09 08:49:13 Hello, could someone have a look on !73153 and !74517 please? 2024-12-09 09:31:52 f_: I've setup my account with "login through github" and I tried to add an additional email for notifications, but when I noticed I can remove password-reset my account through this email I've removed it again. I don't know if the session-view was already broken before though. 2024-12-09 09:46:52 raspbeguy, I saw it was discussed but I still see it there the (whoami) and (hostname), cant it be just hardcoded? aports@alpine 2024-12-09 10:22:34 fabricionaweb: ok then 2024-12-09 10:24:21 fabricionaweb: fixed 2024-12-09 11:50:41 On the subject of Amlogic image builders I saw meson-tools in `testing`, and wondering if it could perhaps be moved to community 2024-12-09 11:51:30 f_: Ask the maintainer to move it (or make an MR yourself) 2024-12-09 11:51:31 just posting this here before doing anything, is there anything that would prevent that? I'll admit meson-tools hasn't seen commits for a long while though... but it still works just fine 2024-12-09 11:52:03 I don't see any other dependencies in testing 2024-12-09 11:52:18 Last build for edge was some time ago apparently 2024-12-09 11:52:30 I don't know the maintainer's IRC nick, wondering if they're joined here at all actually 2024-12-09 11:52:42 it seems like they didn't contribute in a while now 2024-12-09 11:53:00 At least according to their gitlab page https://gitlab.alpinelinux.org/cpixl 2024-12-09 11:53:31 I see 2024-12-09 11:53:45 Do you want to take over maintenance? 2024-12-09 11:53:50 sure 2024-12-09 12:04:41 Can I just send a MR taking over maintenance at that point? 2024-12-09 12:08:04 ptrc, maybe we should rename webkit2gtk-6.0 to webkitgtk-6.0, as this is upstream's new naming 2024-12-09 13:55:27 ikke: So if I understood correctly, all I have to do is send a merge request that adds me as maintainer for meson-tools. Right? 2024-12-09 13:55:41 (and remove Maintainer: line for the previous maintainer) 2024-12-09 13:56:08 I guess if they're still active at all they'll get pinged by the gitlab bot and from there they could comment on the change. 2024-12-09 14:38:49 quinq: tbh i don't see the reason to rename it for now 2024-12-09 14:39:04 it's mostly used as a dependency, and `webkit2gtk` is not too unintuitive 2024-12-09 14:39:40 f_: correct 2024-12-09 14:39:47 ty 2024-12-09 14:39:59 in this case, the last commit is from 2021 2024-12-09 14:40:21 so i'd just assume they're MIA 2024-12-09 14:46:51 Well, it is kind of unintuitive as it doesn't provide anything named webkit2gtk 2024-12-09 14:47:00 Starting with the pkg-config files 2024-12-09 14:49:03 it provides a webkit 2 port for GTK :p 2024-12-09 14:49:06 but yeah, i get what you mean 2024-12-09 14:53:56 :) 2024-12-09 15:18:59 anyone (maybe someone from desktop team) know how to disable dbus service activation? 2024-12-09 15:19:22 i fail to find any resources regarding this at all other than some systemd-specific hacks 2024-12-09 15:22:43 Those software are not designed in a way to be disable, that goes against their whole idea 2024-12-09 15:23:04 ffs 2024-12-09 15:23:09 dbus even have an automatic way of starting up from any call 2024-12-09 15:23:12 so no option beyond patching? 2024-12-09 15:23:16 Note that whatever is being spawned will not actually work 2024-12-09 15:23:20 But it's running anyway 2024-12-09 15:23:52 well, i have figured how to force it to behave under a supervised system 2024-12-09 15:24:09 but i still want to avoid spawning unsupervised and undesired services 2024-12-09 15:24:27 that's where the question comes from 2024-12-09 15:31:16 tbf, there might be an env variable that prevents that 2024-12-09 15:33:08 if there is, i am on the search for it 2024-12-09 15:34:47 good luck :/ 2024-12-09 15:39:14 i wonder if dbus-broker just has autoactivation disabled 2024-12-09 15:39:30 since that's a fork which is supposed to use systemd units but... well... there's no systemd 2024-12-09 15:57:39 okay, took over maintainership in !76760 2024-12-09 15:58:43 f_: missing a pkgrel bump, i think now you should also set the `maintainer=` field 2024-12-09 15:58:52 Of course :p 2024-12-09 15:58:59 I always forget pkgrel... 2024-12-09 15:59:08 wouldn't be the first time :p 2024-12-09 15:59:42 Maybe the last! ;) 2024-12-09 15:59:52 quinq: don't trust me on that 2024-12-09 16:00:17 Though I'm not sure about `maintainer=` 2024-12-09 16:00:35 Guess it was added just recently 2024-12-09 16:01:09 yep, "# Maintainer:" is apparently deprecated 2024-12-09 16:03:50 bl4ckb0ne: it's fixed 2024-12-09 16:04:23 I'll do the same for the gxlimg MR 2024-12-09 16:05:30 !76721 is now fixed too 2024-12-09 16:08:50 f_: got some linting to do now 2024-12-09 16:09:07 On which? 2024-12-09 16:09:22 Ah the meson-tools one 2024-12-09 16:09:41 Well I'm really just taking over maintainership of an existing package 2024-12-09 16:09:54 but sure I can fix that 2024-12-09 16:23:57 looks good now, did you get the ack from the current maintainer anywhere? 2024-12-09 16:24:50 bl4ckb0ne: Apparently the current maintainer is MIA 2024-12-09 16:24:57 No activity for a while now 2024-12-09 16:31:01 hm yeah, no activity for the past year 2024-12-09 16:38:19 merge 2024-12-09 16:38:32 gah saw too late that you could've squashed the commits 2024-12-09 16:38:33 anywya 2024-12-09 16:39:00 In this case it's not even that bad to have separate commits 2024-12-09 16:39:30 It's not a fixup commit or anything 2024-12-09 16:45:31 yeah, makes sense 2024-12-09 16:48:29 :p 2024-12-09 16:49:39 thank you bl4ckb0ne 2024-12-09 16:49:44 np 2024-12-09 17:46:57 And somehow setting a profile now works. nice 2024-12-09 17:47:10 could've been my browser \o/ 2024-12-09 17:51:47 Coming back to dbus-broker theme, it can basically do exactly what i desire with a fitting controller, so that's cool 2024-12-09 17:51:57 but i'm having issues finding a controller 2024-12-09 19:16:47 ping !53556 2024-12-09 19:22:26 witcher01: there is still one open thread, a thing that should be addressed 2024-12-09 19:23:07 ikke: oh, skipped this one while scrolling through, sorry. I'll try and check upstream, thanks 2024-12-09 19:23:39 I provided a link that should clarify it 2024-12-09 19:29:08 interesting. i've just had a look at the debian packaging of theirs and they specify "AGPL-3.0" instead of "AGPL-3.0+". I'll stick to what the debian package says and add "AGPL-3.0-only" to the APKBUILD 2024-12-09 19:32:08 *now* it should be ready :) thanks for the quick response and patience ikke 2024-12-09 19:32:44 Wouldn't that be misleading? 2024-12-09 19:33:40 With GPL, the source code header decides which applies 2024-12-09 19:34:14 So if the header says "or (at your option) any later version.", it should be AGPL-3.0-or-later 2024-12-09 19:35:17 IANAL so I don't feel qualified to comment on it any more than that the debian packaging is made by upstream so I trust they give the proper license there 2024-12-09 19:36:00 I don't care either way, I think both are fine 2024-12-09 19:38:05 https://gitlab.com/lava/lavacli/-/blob/v2.2.0/LICENSE?ref_type=tags#L627-646 2024-12-09 19:40:14 Fair enough, I changed it to -or-later 2024-12-09 22:18:04 should I add dhcpcd to rc boot level or just leave it default? 2024-12-09 22:19:12 anecdotally, it's been more reliable for me at default runlevel 2024-12-09 22:21:06 "it" = networking 2024-12-10 08:29:19 submitted a MR!240. Is there anything else to be done 2024-12-10 08:29:48 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/240 2024-12-10 09:26:58 ncopa how can we create an alias for this pkg? https://pkgs.alpinelinux.org/package/edge/community/x86_64/libqrencode-tools I think it can have "qrencode" as it is the binary and it is the common name in many distros 2024-12-10 09:29:02 provides="qrencode=$pkgver-r$pkgrel" 2024-12-10 09:29:22 would that be able to apk add qrencode ? 2024-12-10 09:29:28 Yes 2024-12-10 09:29:44 then its done 2024-12-10 09:30:59 !76791 2024-12-10 10:10:45 I have a question on gpep517 packaging 2024-12-10 10:11:29 what's the point of the "--output-fd 3 3>&1 >&2" boilerplate seen in almost all such aports? 2024-12-10 10:21:46 is the reason possibly related to this bug fix https://github.com/projg2/gpep517/commit/0db38beaec0658c618287fd689ec7125ebfb8460 ? 2024-12-10 10:22:40 The readme at the end also has a comment 2024-12-10 10:24:05 Although that's specific to capturing output in a subshell 2024-12-10 10:59:31 any updates on !72357 ? tested it and works well 2024-12-10 11:28:20 caskd: it's "Draft"? 2024-12-10 11:29:15 i assume because it expects a review 2024-12-10 11:29:20 but it works fine for me 2024-12-10 11:29:24 builds cleanly and functions 2024-12-10 11:36:29 Does anyone want to make completion of apk-tools for bash, zsh and fish together? 2024-12-10 11:36:51 i already wrote something for zsh 2024-12-10 11:37:10 you can take that and tweak as you desire or ask me about it 2024-12-10 11:37:16 it's part of apk-tools 2024-12-10 11:38:00 if we can generate them from source code https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10773#note_462742 2024-12-10 11:39:06 caskd: thanks :) 2024-12-10 11:52:57 I think we have an issue on abuild checksum, it is not updating my stuff LOL 2024-12-10 11:53:25 nevermind 2024-12-10 11:53:36 Im on the wrong folder wireless-tools vs wireguard-tools 2024-12-10 11:53:49 :) 2024-12-10 11:53:55 ACTION (╯°□°)╯︵ ┻━┻ 2024-12-10 11:57:16 ¯\_(ツ)_/¯ 2024-12-10 11:57:45 ACTION ┬─┬ノ( º _ ºノ) 2024-12-10 12:53:19 if i squashed the two, like ¯\_(°□°)_/¯¯ , what would it be ? 2024-12-10 12:56:15 or ¯\(°□°)_/¯ - walk like an egyption(song) 2024-12-10 13:05:50 ¯\(°□°)_/¯ 2024-12-10 13:05:59 ¯\_(°□°)_/¯ * 2024-12-10 13:06:24 But squashed what, actually? 2024-12-10 13:38:37 Hi there 2024-12-10 13:39:05 hello there 2024-12-10 13:39:30 I would like to push a few of apks that I use on a daily basis... so now all I have to do is make a push to upstream 1)send patch 2)create merge request on gitlab 2024-12-10 13:39:33 The GitLab workflow is similar to GitHub, in that you're supposed to fork the main repo, make your changes in a new branch, and from there create a merge request 2024-12-10 13:40:01 No idea about patches, apparently the gitlab integration has been down for a long while 2024-12-10 13:40:14 I've already pulled the aports repo 2024-12-10 13:40:19 (I mean no idea if email patches are accepted) 2024-12-10 13:40:39 And commited work there. but It's just for me I guess.. 2024-12-10 13:40:57 Then you can create a new merge request in the upstream repo 2024-12-10 13:41:17 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/ 2024-12-10 13:42:06 At the bottom of that page is info about sending email? 2024-12-10 13:44:32 Not an actual button just email? Is this the correct way? 2024-12-10 13:46:04 That's a method 2024-12-10 13:46:33 Most users push a branch to their fork and then create a merge request from that 2024-12-10 13:48:10 https://gitlab.alpinelinux.org/frojnd/aports/-/merge_requests/new 2024-12-10 13:49:43 I've pushed to that repo 2024-12-10 13:49:55 But this is not fork yet right? 2024-12-10 14:00:45 ikke: heads up: mark_great is a known telegram spammer 2024-12-10 14:10:41 Hello, could someone have a look on !73153 and !74517 please? 2024-12-10 14:49:41 ikke: btw, I sent https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/92 2024-12-10 14:54:56 PabloCorreaGomez[m]: yes, I saw it, thanks. Was reviewing it today 2024-12-10 15:24:40 ikke, the setup-desktop script adds fonts for all desktops except xfce. to fix this, i've submitted a MR https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/240 2024-12-10 16:10:44 prabu: ncopa will eventually take a look 2024-12-10 16:15:39 ikke, thanks. Is there anything else i've to do 2024-12-10 16:16:02 for the above MR 2024-12-10 16:16:23 prabu: no 2024-12-10 16:32:58 morning, is there anything else I need to fix in !76721 ? 2024-12-10 16:33:19 actually, nevermind 2024-12-10 16:34:06 there's a typo that prevents installing it 2024-12-10 16:35:18 ACTION facepalms 2024-12-10 16:44:02 okay now it works. 2024-12-10 16:49:15 ikke: thanks for reviewing !73153. Do you have an idea about the reason of the memory shortage on riscv64? If not, I'll just disable the package on this arch for now. 2024-12-10 16:49:43 No, not sure if it's actually a memory shortage, or some other issue 2024-12-11 06:48:27 I wonder if the test we've tried in !76828 wouldn't fail on 32bit arm with glibc 2024-12-11 07:06:39 Hey team, if I want to package a symlink, should I make it relative to $pkgdir or /? 2024-12-11 07:08:14 testing suggests relative to root... 2024-12-11 08:24:38 https://t.me/+32cFzLuOiacxZmM0 2024-12-11 08:24:38 Any Cashapp? Chime? Zelle? Btc? Usdt?Skrill? Apple Pay? Pay pal? Venmo? BOA? Wells Fargo? Join my channel 2024-12-11 08:24:38 
Got any of these
Chase?
BOA?
Wells Fargo?
Navy federal?
Capital one?
Truist?
Att &t?
PNC?
TD bank?
Credit union?
M&T bank?
Santander bank?
Northwest bank?
Or any other local Bank
JOIN THE CHANNEL NOW TO GET PAID💯 ✅ 2024-12-11 08:45:46 anyone got duplicated rules issues in nft when using wildcards? 2024-12-11 08:46:05 it seems like the wildcard matching doesn't filter duplicates and entries are added multiple times 2024-12-11 08:46:26 seems to be a new issue as with older nft versions it didn't occur 2024-12-11 08:55:33 seems to be a regression from 1.0.9 to 1.1.1 (v3.20 -> v3.21 respectively) 2024-12-11 08:55:55 tested with both and on the old one it doesn't occur 2024-12-11 09:02:55 seems to be related to 6ef04f99382c074c3669de31cf0a70651662b261 2024-12-11 09:03:13 i'll write a patch and test + upstream if it is 2024-12-11 09:24:55 well, it's a mix of both 302e9f8b3a1382cf09db32541693b5df7d80ca1e and 6ef04f99382c074c3669de31cf0a70651662b261 2024-12-11 09:36:58 g'morning 2024-12-11 09:37:00 can we merge !76595? 2024-12-11 09:39:55 can anyone ban sharonne[m]? 2024-12-11 13:00:48 Ok I've created a fork, created a branch, commited and pushed the branch and created a merge request within gitlab: !76856 I hope this is it? 2024-12-11 13:28:47 So now I just wait until someone accepts? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76856 2024-12-11 13:29:35 frojnd: correct 2024-12-11 13:30:10 quick look at it, commit should be "testing/lyrics-in-terminal: new aport" 2024-12-11 13:30:39 The `# Maintainer:` line is apparently deprecated and replaced by a $maintainer variable in APKBUILD 2024-12-11 13:31:09 so instead of `# Maintainer: Hose Amigo ` you'd have `maintainer="Hose Amigo "` 2024-12-11 13:33:17 Can you reject so I can fix it? 2024-12-11 13:35:38 It doesn't have to be rejected for you to fix it 2024-12-11 13:35:49 also f_ # Contributor is deprcrecated I guess? and it should be just contributor="..." 2024-12-11 13:35:56 The maintainer comment is still valid 2024-12-11 13:36:23 The decision to switch has been reverted for the time being 2024-12-11 13:37:23 Ok So I should just ammend for the same of the commit message? 2024-12-11 13:37:37 Can I even do that with no code change 2024-12-11 13:38:06 s/same/sake/ 2024-12-11 13:39:53 Yea 2024-12-11 13:40:10 git commit --amend 2024-12-11 13:40:53 git push --force-with-lease 2024-12-11 13:42:38 ikke: good to know 2024-12-11 13:43:11 frojnd: yeah just push to the branch again like what ikke told you to do 2024-12-11 13:45:36 But ammend and force push I do within lyrics-in-terminal branch in this case? 2024-12-11 13:45:50 I think yes 2024-12-11 13:47:14 git push --force-with-lease origin lyrics-in-terminal 2024-12-11 13:48:01 I think that's it 2024-12-11 13:56:17 Correct 2024-12-11 15:27:59 hi, I need someone to look to !76424 2024-12-11 15:31:43 just brainstorming here... does anyone have ideas about how Alpine could be adapted to do "fully hermetic /usr", where packages don't install to /etc but to /usr/factory/etc instead (and some tool is used to populate /etc on first boot) 2024-12-11 15:33:27 since obviously it would need to be optional 2024-12-11 15:42:36 "since obviously it would need to..." <- what is the use-case where you don't want this? just curious what you have in mind 2024-12-11 15:43:25 well having to run some utility to populate /etc from /usr/factory/etc either as a post-install step or during first boot is an additional step which people might not want to deal with 2024-12-11 15:44:11 maybe it could be integrated as a trigger or otherwise made to be not-too-annoying, but i can imagine people not wanting to deal with the additional complexity 2024-12-11 15:51:04 calebccff: `ln -s /etc /usr/factory/etc`? I'm not sure what the usecase is 2024-12-11 15:53:24 f_: that could maybe work while building images i guess x3 2024-12-11 15:53:42 Besides, I never saw /usr/factory/etc anywhere :) 2024-12-11 15:53:52 f_: the usecase is to eventually allow for the entire system to be in /usr, with everything else derived from there 2024-12-11 15:53:55 Though looking at file-hierarchy(7) I do see /usr/share/factory/etc/ 2024-12-11 15:54:09 so you can "build" it on first boot, and factory reset by wiping the root partition 2024-12-11 15:54:10 calebccff: ahh, makes sorta sense 2024-12-11 16:06:59 wheres my friend bot 2024-12-11 16:07:01 o/ 2024-12-11 16:07:22 bot is 🛏️ 2024-12-11 16:09:00 !76424 2024-12-11 16:13:13 thanksss 2024-12-11 18:01:26 Hi, i have bought myself a new dev machine. Unfortunately my wifi does not work. I have opened two MRs yesterday (!76801 and !76802). What could i do to get these merged soon? 2024-12-11 18:15:23 Hello to everyone 🤗... (full message at ) 2024-12-11 18:37:41 Hm for merge requests I just pushed today I see: Merge blocked 1 check failed Merge request must be rebased, because a fast-forward merge is not possible. With [rebase] [rebase without pipeline] options 2024-12-11 18:39:30 Should I ignore this or rebase the merge request? 2024-12-11 18:39:42 frojnd: you can ignore that 2024-12-11 18:39:43 errr rebase the commit 2024-12-11 18:39:57 it will be rebased before being merged 2024-12-11 18:40:33 Allright. So now I can move to main branch and git pull, and then create a new branch to move creating other pkgs? 2024-12-11 18:40:47 yes 2024-12-11 18:41:26 Thank you for helping me out ikke f_ 2024-12-11 18:41:35 no problem :) 2024-12-11 18:42:09 ugh, mark_great[m] spamming .. guess I'll report it 2024-12-11 18:44:01 About maintainer= field... https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76859 Simon Zeni told that alpine uses it now? Or are both ways acceptable? Also is contributor= field also present if both ways are valid? 2024-12-11 18:46:27 contributor is not a variable 2024-12-11 18:46:30 only a comment 2024-12-11 18:48:20 Ok 2024-12-11 18:50:45 Hello to everyone 🤗... (full message at ) 2024-12-11 19:02:54 Ok so what I did: git checkout master; git remote add upstream https://gitlab.alpinelinux.org/alpine/aports; git fetch --all; git rebase 2024-12-11 19:03:42 But when I do git log on a master branch I still see last commit: community/opencv: enable on riscv64 Date: Wed Dec 11 09:43:10 2024 +0000 as if I didn't properly sync with upstream? 2024-12-11 19:03:49 git rebase upstream master 2024-12-11 19:03:51 Do mind I did this on my fork branch 2024-12-11 19:03:59 Ah 2024-12-11 19:03:59 sorry 2024-12-11 19:04:02 git rebase upstream/master 2024-12-11 19:04:29 Oh nice 2024-12-11 19:06:35 frojnd: you may want to change the upstream for the master branch 2024-12-11 19:06:46 git branch --set-upstream-to=upstream/master master 2024-12-11 19:08:12 Ah so I don't have to type upstream/master all the time 2024-12-11 19:54:24 So one of the apks fails: https://gitlab.alpinelinux.org/frojnd/aports/-/jobs/1645495 it builds locally.. but fails in job. Looking at logs it seems it needs gnu sed? 2024-12-11 19:55:10 Yes 2024-12-11 19:55:17 so add sed to makedepends 2024-12-11 19:56:37 Yep 2024-12-11 19:57:03 My build setup is not ok I see,.. I guess I must have had sed installed locally and didn't noticed the makedepends need for sed 2024-12-11 19:57:10 Hm hm 2024-12-11 20:04:04 what could i do to get these (!76801 and !76802) merged soon? 2024-12-11 20:06:57 chereskata: ncopa was away for a couple of days, he should be back soon. Anyway, it would require bumping the krel for all the relevant out-of-tree kernel modules as well 2024-12-11 20:07:21 Ah okey thank you! Is there a script for doing this? 2024-12-11 20:11:56 ncopa probably has a script for it 2024-12-11 20:12:43 so i will just be patient and work some days from lan only :D. No need to rush! 2024-12-11 20:12:52 thanks :) 2024-12-11 20:24:03 'Error: "38093" is not less than "25584"' 2024-12-11 20:24:29 In what universe would that be correct? :P 2024-12-11 20:24:45 :D 2024-12-11 23:37:45 hello, trying to build my first package from `testing/xonsh` from aports, and it fails: [full log](https://dpaste.org/3LcRQ/raw). When I inspect it, I see things starting to go wrong aronud line 983 [zooming into the problem area](https://dpaste.org/AMs6k/raw). It looks like it's python failing on calling a `TemporaryDirectory()`. So, I tested on a simple python script (https://dpaste.org/fUmLN/raw) and confirm that on my system, if 2024-12-11 23:39:32 Is this a known issue? This is a fresh install of alpine, so I didn't expect strange things like that 2024-12-11 23:48:50 is it inside a VM 2024-12-11 23:50:17 no 2024-12-11 23:51:23 ok and /tmp is mounted ? it might be a permission issue to create files 2024-12-11 23:52:53 output of `mount | grep tmp` https://dpaste.org/Lt7A7/raw 2024-12-11 23:53:24 seems ok 2024-12-11 23:53:25 tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime) 2024-12-11 23:54:29 yeah, that should be unmodified, I didn't make any change to fstab 2024-12-11 23:54:57 the sample you posted also fails for you which is strange, it works ok here 2024-12-11 23:55:33 you can create files under /tmp ? 2024-12-11 23:55:40 *curses* 2024-12-11 23:55:58 yes I can 2024-12-11 23:56:01 with the same uid as the build is happening ? 2024-12-11 23:56:39 hmm then it might be something buggy perhaps 2024-12-11 23:57:19 by that, do you mean same user? if so, yes. 2024-12-11 23:57:36 my user, I added to `abuild` group 2024-12-11 23:57:42 and ran `abuild -r` 2024-12-11 23:57:54 (logged out first) 2024-12-12 00:02:48 I supposed without any leads on what is going on, I'll try rebooting into the ISO, and try from that environment 2024-12-12 01:19:08 flashed a new image of `alpine-standard-3.21.0-x86_64.iso`; booted; `setup-alpine` ... ; `apk add git alpine-sdk`; `git clone https://gitlab.alpinelinux.org/alpine/aports` ; `abuild-keygen -a -i` ; `cd aports` ; `abuild -r` - same error and same glitch with Python's `TemporaryDirectory()` function. Am I crazy here? 2024-12-12 01:20:24 anyone else getting their kernels tainted with 512 after the update? 2024-12-12 02:21:47 pltrz: fwiw, reproduced similar results 2024-12-12 02:23:40 good to know 2024-12-12 02:24:17 so it seems something is breaking Python 2024-12-12 02:26:33 edge x86_64 ... last time the package was rebuilt was around jul 22, dependencies may have upgraded since 2024-12-12 02:29:59 mio: you're referring to xonsh? or python? 2024-12-12 02:30:31 pltrz: xonsh ... just upgraded to 0.19.0, tests appear to be passing now 2024-12-12 02:30:55 testing that is, bumping the version up from 0.18.2 to 0.19.0 2024-12-12 02:31:11 I see 2024-12-12 02:31:33 4889 passed, 49 skipped, 2 deselected, 16 xfailed, 3 warnings 2024-12-12 02:31:48 rebuilt okay, so maybe just needs an abump 2024-12-12 02:31:50 That's strange, it seemed the Python function was failing regardless of the xonsh package 2024-12-12 02:32:28 perhaps it's my misunderstanding 2024-12-12 02:33:38 the source issue was python's TemporaryDirectory() function, that I noticed through trying to package xonsh 2024-12-12 02:34:34 I tried with something like this: https://dpaste.org/fUmLN/raw 2024-12-12 02:34:36 xonsh is already in the testing repo? or are you trying to package a variant? 2024-12-12 02:35:32 nope, I was trying to package vanilla, just getting familiar with aports 2024-12-12 02:36:43 okay 2024-12-12 02:38:25 with that script (https://dpaste.org/fUmLN/raw) python's TemporaryDirectory() function says it made a directory in /tmp, but when you go there it's not really there, the function fails somehow. 2024-12-12 02:39:44 mio: btw, what's the meaning of 'abump'? 2024-12-12 02:41:37 abump is an abuild command 2024-12-12 02:42:21 fetches the given version of an aport and updates the APKBUILD 2024-12-12 02:42:23 ah, thank you, +1 xp 2024-12-12 02:42:35 cool 2024-12-12 02:43:15 just meant colloquially in this case to bump up the aport version 2024-12-12 02:45:14 maybe the temporary directory is missing because it is automatically removed? 2024-12-12 02:45:41 https://stackoverflow.com/a/55104228 2024-12-12 02:46:11 ah ok, makes sense 2024-12-12 02:47:34 https://docs.python.org/3/library/tempfile.html#tempfile.TemporaryDirectory (more details) 2024-12-12 02:48:46 thank you 2024-12-12 02:49:20 you're welcome, thanks for reporting the xonsh build error 2024-12-12 02:49:22 one reason I was going to try to package it, was to add "install=" to the aport and make a merge request, since it seems to be missing that in the APKBUILD 2024-12-12 02:49:28 no problem! 2024-12-12 02:49:43 thought I might throw it in there as well 2024-12-12 02:49:54 it's skipping the 'post-install' etc 2024-12-12 02:50:56 it seems the shells are supposed to have that, i noticed it wasn't running the hook 2024-12-12 02:52:25 ah okay 2024-12-12 03:13:08 aleksi_: not tainted here. in the past, the only time i've seen a tainted kernel was when i used the proprietary nvidia driver and modules. 2024-12-12 07:30:35 good morning! im back. how is everythign going? 2024-12-12 07:33:04 ncopa: welcome back 2024-12-12 07:36:52 Things are going okay. A couple of bug reports / regression regarding 3.21 2024-12-12 07:37:04 MR queue has grown a bit 2024-12-12 07:40:57 ayakael, ping https://gitlab.alpinelinux.org/alpine/aports/-/issues/16727 2024-12-12 07:41:49 ncopa: morning! ☕ 2024-12-12 08:03:08 I don't have an alpine gitlab account, but fyi ventoy contains a bunch of precompiled artifacts/blobs https://gitlab.alpinelinux.org/alpine/aports/-/issues/16710 2024-12-12 08:04:54 abby: commented it 👍 2024-12-12 08:05:24 cheers 2024-12-12 08:06:59 the relevant issue is https://github.com/ventoy/Ventoy/issues/2795 2024-12-12 08:07:17 bit of a trashfire down thread though 2024-12-12 08:13:27 My god 2024-12-12 08:19:27 This was a great project, theres also netboot.xyz but its focused on pxe 2024-12-12 09:00:58 Good morning! 2024-12-12 09:02:08 So I get comments from nice people of Alpine. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76856 What do I do: 1) fix stuff 2) git add 3) git commit --amend (BUT what comment should I use? Same as previous one new aport? Or actually describing the fixes) 4) git -f push 2024-12-12 09:03:51 ikke: for bootchart2 I was pushing with updated APKBUILD but didn't change the git message 2024-12-12 09:12:27 Good morning. I am trying to upgrade `freerdp` 2.11.7 to 3.9.0. There are two options: create a `freerdp2` package and upgrade `freerdp` to v3, or create a `freerdp3` package and keep `freerdp` at v2. I am wondering which is better. 2024-12-12 09:13:39 i think the newer version should be without the version as pkgname 2024-12-12 09:15:23 lindsay: btw i've also made an attempt see https://gitlab.alpinelinux.org/fossdd/aports/-/commit/b673a22dcec038eddbdad335fbd729884102ced9 2024-12-12 09:15:41 but had no motivation to had another look 2024-12-12 09:19:30 Oh, thank you. 2024-12-12 09:24:38 If `freerdp` moved to `freerdp2`, do packages that depend on it need to be rebuilt? Since the dependencies are specified by soname, maybe this isn't needed? 2024-12-12 09:27:02 yes exactly, no need to rebuild, just change the pkgname in makedepends without a pkgrel bump. 2024-12-12 09:47:06 frojnd: you don't have to describe all the changes you made 2024-12-12 09:55:30 Ok thank you 2024-12-12 09:56:16 Could someone please look at this MR? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73213 2024-12-12 10:00:08 hmm... last activity from Martijn was 7 months ago 2024-12-12 10:47:39 good morning, would love someone to look to !76373 2024-12-12 11:10:55 hmm !76373 2024-12-12 11:11:07 -- !76373 -- 2024-12-12 11:11:26 I think algitbot probably doesn't like it in the middle/end of a message 2024-12-12 11:11:44 (which is strange, I know it used to work) 2024-12-12 11:12:00 I think it is 🛏️ 2024-12-12 11:12:15 o/ 2024-12-12 11:12:17 !76373 2024-12-12 11:12:33 algitbot: hi 2024-12-12 11:12:34 I don't think so, it still posts in #alpine-commits 2024-12-12 11:12:37 \o/ 2024-12-12 11:12:41 okay it is awol 2024-12-12 11:12:46 here specifically 2024-12-12 11:12:55 did anyone offend algitbot? 2024-12-12 11:13:02 :( 2024-12-12 11:13:16 algitbot: please behaave 2024-12-12 11:13:42 ncopa: it is probably sleeping, probably had a long day 2024-12-12 11:14:27 yeah 2024-12-12 11:14:36 let it rest a bit :D 2024-12-12 11:44:18 when adding a new contributor comment, its goes on top or bottom of the existing ones? 2024-12-12 11:50:07 i'd assume bottom 2024-12-12 11:50:17 but i don't think it's defined in any way 2024-12-12 13:05:49 we should not have shown algibot Linux EOL webpage 2024-12-12 13:08:21 algitbot: don't worry we will get you "asahi linux" 2024-12-12 15:00:20 Is there anything else I need to address in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76721 ? 2024-12-12 15:00:29 !76721 2024-12-12 15:20:22 No, it's just that there are many MRs open, so it might take some time 2024-12-12 15:20:34 Well, I see ptrc just left a note 2024-12-12 15:25:13 ikke: I'll let y'all focus on the other MRs then 2024-12-12 15:25:25 mine is not urgent so I don't mind if it takes time 2024-12-12 15:41:20 oh, 31 pages full of MRs.. yeah mine's definitely not urgent at all 2024-12-12 15:41:36 sorry for nagging, I won't do it again :p 2024-12-12 16:16:51 its holiday season 2024-12-12 16:43:44 Not according to the amount of MRs we receive :) 2024-12-12 17:44:10 I could help a bit with MRs 2024-12-12 17:44:38 I already help out with pmOS :p 2024-12-12 17:44:50 s/with // 2024-12-12 17:47:29 perhaps you can help with !76907 2024-12-12 17:48:34 !76907 2024-12-12 18:00:44 a new gitlab appear 2024-12-12 18:05:10 that aport bellow have been generated using the "apkbuild-cpan" shall it be cleaned? I mean remove the comment or its fine 2024-12-12 18:05:30 s/bellow/above LOL 2024-12-12 18:09:32 It's fine 2024-12-12 18:25:06 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76921 o.O 2024-12-12 18:25:41 f_: hm? 2024-12-12 18:26:24 ptrc: MR sender can approve their own merge request? 2024-12-12 18:26:36 if they're also the maintainer, why not? :3 2024-12-12 18:26:42 it's not really necessary 2024-12-12 18:26:48 approve my own work™ 2024-12-12 18:26:50 andypost is a developer 2024-12-12 18:27:06 He can merge it if he wants, but basically says: feel free to merge my MR 2024-12-12 18:27:08 that too 2024-12-12 18:27:26 yes, but I think I recall approving own MR was not possible, at least not in gitlab.com? 2024-12-12 18:27:50 in gitlab CE, anyone with some role in the project can approve MRs 2024-12-12 18:27:53 then again, possibly gitlab CE "chuggling along" .. or I'm misremembering 2024-12-12 18:28:08 Even a `guest` role 2024-12-12 18:29:00 Gotcha, thanks 2024-12-12 18:57:43 btw 2024-12-12 18:57:49 not sure who did the glibmm / pangomm version swap 2024-12-12 18:58:00 https://ptrc.gay/rLKJFJjr 2024-12-12 18:58:06 but that doesn't look right 2024-12-12 18:59:35 iirc ncopa did that 2024-12-12 20:28:42 Does anybody wanna have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/76448 ? 2024-12-12 20:36:47 checking 2024-12-12 20:50:47 Also, can we add to /usr merge milestone !76940 !74284 and !75080 2024-12-12 21:09:34 f_: Another thing you could help with is find MRs that are assigned to a maintainer where the ACKed the MR in some way 2024-12-12 21:49:59 i can look at my MRs, i think some are already ACKed 2024-12-12 21:52:11 ok only !74946 and !76671 2024-12-12 21:52:12 less than i thought 2024-12-12 21:55:31 !76595 2024-12-12 21:56:47 ikke: btw big thanks for checking the MR backlog today! 2024-12-12 21:57:21 you're welcome, still quite some to go 2024-12-12 22:11:01 Thanks a lot ikke!! 2024-12-13 08:13:52 Any chance someone could help me out by enabling a few wifi driver modules? I moved and no longer have hardwire access, and Alpine only supports a very old and slow 2.4GHz adapter for my HiFi out of what I have 2024-12-13 08:16:32 RTL8812BU (USB), RTL8812AU (USB), ATH10K (USB) are all faster/more stable options I have access to with kernel drivers that I can't use on linux-lts_x86-64 right now 2024-12-13 08:17:08 I can download the kernel on my phone and MTP it over if it gets built 2024-12-13 08:20:14 Saijin_Naib[m]: can you please create an issue with that info? I'll try build new kernel with those enabled 2024-12-13 08:20:24 add label "kernel" and assign to me 2024-12-13 08:21:12 thanks, nataneal. I tried to build locally and diff the config and I bricked my machine until just now, so I did something wrong 2024-12-13 08:24:17 I dont have permissions to assign or label 2024-12-13 08:24:24 !16703 2024-12-13 08:24:36 bah 2024-12-13 08:24:38 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16703 2024-12-13 08:28:33 Thanks! 2024-12-13 08:29:00 I'll try get it done for the next kernel version bump, if not before 2024-12-13 08:29:08 fossdd, thank you for all aports upgrades you have done 2024-12-13 08:30:02 I think issue is not ! but # #16703 2024-12-13 08:31:22 ncopaI can't thank you enough! Alpine and you all have been so great to me over the years 2024-12-13 08:31:32 fabricionawebAh, indeed! Thank you 2024-12-13 08:33:27 also related to wifi drivers !76801 2024-12-13 09:26:49 <@ikke f_: Another thing you could help with is find MRs that are assigned to a maintainer where the ACKed the MR in some way 2024-12-13 09:26:54 oops 2024-12-13 09:27:02 > f_: Another thing you could help with is find MRs that are assigned to a maintainer where the ACKed the MR in some way 2024-12-13 09:27:05 Gotcha 2024-12-13 10:53:35 Saijin_Naib[m]: Do you know the exact config settings for RTL8812BU (USB), RTL8812AU (USB)? 2024-12-13 10:55:12 I cant find anything except RTL8XXXU 2024-12-13 10:56:08 which does not seem to cover RTL8812*U 2024-12-13 10:59:27 slightly annoyed to spend time on researching this 2024-12-13 12:55:58 could someone take a look at this mr, I think it's ready: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75826 2024-12-13 13:05:09 it might be 88XXau, https://github.com/aircrack-ng/rtl8812au?ysclid=m4ndk5jnpo772001781 2024-12-13 13:17:25 probably not useful, https://www.realtek.com/Product/Index?id=579&cate_id=194&menu_id=391 2024-12-13 13:26:08 yeah, its not in mainline kernel 2024-12-13 13:26:44 i was guessing it 2024-12-13 14:06:49 "it might be 88XXau, https://..." <- That is in edge, outdated, and when bumped to latest, doesnt work as device just cycles constantly 2024-12-13 14:07:32 "slightly annoyed to spend time..." <- Apologies. Do you use menuconfig or else to change options? I can add the changed lines to my issue 2024-12-13 14:16:13 Saijin_Naib[m]: yes, add it or paste the diff in tpaste.us 2024-12-13 14:37:19 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16703#note_465634 2024-12-13 14:37:40 Sorry for the trouble. It was very late (early) and I wasn't following through properly 2024-12-13 14:51:50 if I want to use files under sysctl.d directory do I need to enable the sysctl rc? 2024-12-13 14:58:07 Saijin_Naib[m]: no worries. I pushed a kernel with ath10k usb at least 2024-12-13 14:58:33 will do the last with 6.12.5 whenever that comes out 2024-12-13 14:59:36 Thanks so much, and sorry again for wasting your time with a bad Issue 2024-12-13 15:05:12 no worries 2024-12-13 18:09:39 re: #16736, it seems rsync was never built for 3.21?! can't find build logs for either x86_64 or aarch64 anyway 2024-12-13 18:10:36 installing it in a 3.21 container yields a /usr/bin/rsync datestamped 2024-04-07 2024-12-13 18:11:16 dne: It's part of the bootstrap, so buildlogs are never written 2024-12-13 18:11:21 aah 2024-12-13 18:11:24 Was looking at it at well 2024-12-13 18:12:11 Was checking based on what ipv6 support is built or not 2024-12-13 18:12:30 right 2024-12-13 18:15:58 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16736 2024-12-13 18:16:00 wrong paste 2024-12-13 18:16:08 if (socket(AF_INET6, SOCK_STREAM, 0) < 0) 2024-12-13 18:23:46 dne: I suspect rebuilding it would fix it 2024-12-13 18:28:09 yep, but perhaps good to figure out why it happened 2024-12-13 18:28:21 yes 2024-12-13 18:33:15 oh huh, it does not even build atm 2024-12-13 18:34:03 'checking whether to enable ipv6... no' 2024-12-13 18:38:57 <@ikke> if (socket(AF_INET6, SOCK_STREAM, 0) < 0) 2024-12-13 18:39:11 way to leak a fd if the socket() call succeeds :P 2024-12-13 18:39:29 it's an autoconf check 2024-12-13 18:40:07 one day people will merge these into one process and hilarity will ensue 2024-12-13 18:47:48 Oh 2024-12-13 18:47:58 error: return type defaults to 'int' [-Wimplicit-int] 2024-12-13 18:48:21 the autoconf check fails due to -wimplicit-int 2024-12-13 18:55:27 gcc 14 strikes again 2024-12-13 18:59:53 ncopa just fixed the build failure due to awk on edge 2024-12-13 20:38:41 is there a way to make seeing why a compilation error happens easier? when i work in aports and then compile linux-lts, something in the .config file keeps breaking compilation, but it gives me a vague error "make: *** [linux-lts/src/linux-6.11/Makefile:224: __sub-make] Error 2" 2024-12-13 20:39:10 you need to read further up in the log 2024-12-13 20:39:21 its kinda all gone for me 2024-12-13 20:39:35 like my terminal doesn't scroll that far 2024-12-13 20:39:52 try with 1 makejob, however that's specified 2024-12-13 20:40:12 its abuild, i know like make can do -j1 but i dont't know how to with abuild 2024-12-13 20:41:48 oh wait i didn't know abuild can do -j1 2024-12-13 20:42:10 wait never mind 2024-12-13 20:42:25 Pursuable1652: you can provide -j1 to the make invocation 2024-12-13 20:43:16 is that in APKBUILD file? I see a make command in it 2024-12-13 20:43:23 yes 2024-12-13 20:43:54 You can also try to look for 'Error 1' in the output 2024-12-13 20:52:17 i'm trying to compile again and see if error 1 will pop up for me, my terminal doesn't scroll far again, last compile i tried doing "abuild -r -v | tee ./compile-debug.txt" seems not to even show error 2, not sure why it wont show me like everything with the tee command 2024-12-13 20:53:30 Pursuable1652: That would not capture stderr output 2024-12-13 20:53:55 abuild -r 2>&1 | ./compile-debug.txt 2024-12-13 20:54:01 abuild -r 2>&1 | tee ./compile-debug.txt 2024-12-13 21:00:46 Ok hopefully i get error 1 output thanks 2024-12-14 12:01:05 i find a bug on pkgs.a.o, when hover mouse on the Repository and Architecture, it shows wrong filter hint 2024-12-14 12:10:43 qaqland: could you open an issue here? https://gitlab.alpinelinux.org/alpine/infra/apkbrowser 2024-12-14 12:15:22 Yes, I should be there 2024-12-14 12:15:33 https://gitlab.alpinelinux.org/alpine/infra/apkbrowser/-/issues/13 2024-12-14 12:16:49 thanks 2024-12-14 19:35:41 Hi, how is the installation .iso generated? I'm facing an issue booting alpine-standard-3.21.0-loongarch64.iso and I have a suspicion what might be wrong, based on the Deepin .iso that does boot 2024-12-14 19:37:28 benpicco: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/mkimage.sh 2024-12-14 19:37:36 (and related scripts in the same directory) 2024-12-14 20:11:04 added new page https://b.infosight.in/alpine here, openpage > alpine/aports, would be updating with more leafnodes 2024-12-14 21:30:04 Is it possible to compile linux kernel on the gitlab with its CI/CD, or am I just causing trouble because its a big software to compile 2024-12-14 21:30:28 Currently I just compile using one of my computers 2024-12-14 21:30:41 But it's not a super fast one ;( 2024-12-14 21:47:18 Currently I'm trying to compile linux-hardened kernel, I've fixed two errors since compiling, just waiting on the next one ;(, here's my repo I'm using to compile if it matters, I hope to publish hardened kernel to repo one day: https://gitlab.alpinelinux.org/Pursuable1652/linux-hardened 2024-12-14 22:02:28 ikke: i ran out of Usage Limit: 10000 :( 2024-12-14 23:27:52 Finally finished compiling, and no errors, now just to test linux-hardened apk :D 2024-12-15 09:36:10 Anyone successfully using the "glab" command line tool to submit a merge request to the aports repo? I've tried twice and I get stupid messages like this one here: Failed to create merge request. Created recovery file: /home/chris/.config/glab-cli/recover/alpine/aports/mr.json Run the command again with the '--recover' option to retry. POST https://gitlab.alpinelinux.org/api/v4/projects/alpine/aports/merge_requests 2024-12-15 09:36:11 : 403 {message: 403 Forbidden} 2024-12-15 10:00:57 Turns out that the glab tool took some shits in my repo .git/config. Cleaned it up and I was able to submit https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77088 2024-12-15 20:14:42 ikke: how to get total closed MR/issues from gitlab api ? 2024-12-15 20:15:02 managed to get opened total for both 2024-12-15 20:15:46 With graphql it shoulds not be difficult 2024-12-15 20:16:48 ok will try, haven't used it, thanks 2024-12-15 20:18:33 It's scoped per project though 2024-12-15 20:33:45 its an application or just set api query rules ? 2024-12-15 20:34:20 apk search -d graphql, nothing in v3.18.x 2024-12-15 20:35:10 checking my-friendly site wikipedia 2024-12-15 20:35:27 hmm, api lang 2024-12-15 20:37:47 will check gitlab.com docs 2024-12-15 20:49:29 seems using it needs an account, GRAPHQL_TOKEN= 2024-12-15 20:51:58 will see more docs, if account is needed, then it fails the very purpose of base IO ReadOnly needs that api gives 2024-12-15 20:52:13 basic IO 2024-12-15 20:55:06 currently only need data/info what is availabe via webUI(public domain, no-login) 2024-12-15 21:02:57 "You can access some queries without authentication," :) 2024-12-15 21:55:17 looks like overly abstracted api, lost its simplicity 2024-12-15 22:10:22 ikke: i cannot get it going, any help appreciated, tried simple query, https://tpaste.us/e6nB 2024-12-15 22:32:02 curl https://gitlab.alpinelinux.org/api/graphql --json '{"query": "query{project(fullPath: \"alpine/aports\") { issues { count }}}"}' 2024-12-15 22:46:15 thanks 2024-12-16 00:28:51 btw, you can just use https://gitlab.alpinelinux.org/-/graphql-explorer 2024-12-16 00:29:02 gives you syntax highlighting + docs + etc. 2024-12-16 03:24:14 nmeum,ncopa: not sure if the busybox awk issue talked about in #16733, and mitigated by adding gawk to makedepends, was solved by !76979 or not 2024-12-16 06:53:57 omni: yea, we should backport that to 3.21 2024-12-16 07:31:41 nmeum: the awk patch is in both edge and 3.21, I was just not sure if it was used for those builds of gcc-avr 2024-12-16 07:32:05 ah, nvm then 2024-12-16 07:33:02 so, seems like some other busybox awk issue 2024-12-16 08:29:34 ptrc: thanks 2024-12-16 08:34:32 would be nice if a cli-tool for it is pkg'ed (graphql-explorer) 2024-12-16 08:37:53 found it, Graphene 2024-12-16 08:50:51 and others https://graphql.org/community/tools-and-libraries 2024-12-16 12:07:49 I just realized that I have no sound on my desktop computer anymore 2024-12-16 12:07:57 i dont know when I lost it 2024-12-16 12:09:05 use to go out to HDMI 2024-12-16 12:09:26 maybe muted in pavucontrol 2024-12-16 12:12:11 ha, yes indeed 2024-12-16 12:12:15 thanks 2024-12-16 15:38:43 PureTryOut: have you seen !76859 ? There's some discussions about `testing/skia-sharp` segfaulting 2024-12-16 15:39:49 I have not. Interesting though, another user of that package. I wouldn't mind if they took over maintenance of it 😅 2024-12-16 15:40:20 There was a reason I packaged that fork though... 2024-12-16 15:40:50 yeah, the use wrote a complete new package for it 2024-12-16 15:54:46 hello 2024-12-16 15:55:25 hi 2024-12-16 15:55:35 I have a question: is VDO (Virtual Data Optimizer) available in Alpine Linux ? Will it ever be ? 2024-12-16 15:56:16 It seems it's been merged with Kernel 6.6, there are apackages for Red Hat (and similar) distros 2024-12-16 15:57:21 I managed to use it on Alpine 3.12 (compiling kernel modules and hacking the sources) but it was kinda shaky 2024-12-16 15:58:02 sorry -it's been merged with kernel 6.9 not 6.6 2024-12-16 15:58:28 is it a kernel feature? 2024-12-16 15:58:46 It has been merged in 6.9 afaik 2024-12-16 15:59:04 https://docs.kernel.org/admin-guide/device-mapper/vdo.html 2024-12-16 16:01:08 # CONFIG_DM_VDO is not set 2024-12-16 16:01:40 VDO is currently available in Alpine 2024-12-16 16:02:02 it will likely be available at some poine 2024-12-16 16:02:05 point* 2024-12-16 16:02:58 great! 2024-12-16 16:03:13 I can try get it in with next kernel version bump if not before 2024-12-16 16:03:24 patches for the user space tools are welcome 2024-12-16 16:14:48 trying to compile them right now, got stuck at 2024-12-16 16:14:51 ./linux/blkdev.h:47:9: error: unknown type name 'loff_t'; did you mean 'off_t'? 2024-12-16 16:17:15 i think you can report that upstream 2024-12-16 16:17:31 i think off_t is safe to use with musl 2024-12-16 16:18:55 passing "-Dloff_t=off_t" parameter would be a workaround I read 2024-12-16 16:31:46 👍 2024-12-16 17:03:06 compiling vdo userland I incurred in the (infamous?) "strerror_r" problem: function in GNU-ish returns type "char *" while POSIX/musl returns type "int" (makefile passes -D_GNU_SOURCE) 2024-12-16 17:03:34 so it shits the bed while compiling with: "error: returning 'int' from a function with return type 'const char *' makes pointer from integer without a cast" obviously 2024-12-16 17:04:29 it's out of my league I guess 2024-12-16 19:38:54 Curious if possible to add a "setup-silentboot" script cause why not for Alpine, https://gitlab.alpinelinux.org/Pursuable1652/silentboot/-/blob/master/setup-silentboot, all it does is just append "quiet" to /etc/default grub, and appends "&> /dev/null" to each necessary line to /etc/inittab 2024-12-16 19:39:27 But if not that's fine 2024-12-16 19:40:10 Something like type "n" as argument would remove the silent boot, and type "y" would apply silent boot 2024-12-16 19:41:01 */etc/default/grub 2024-12-16 19:42:05 Basically just do what I wrote in this wiki but in a script: https://wiki.alpinelinux.org/wiki/Silent_boot 2024-12-16 19:56:37 or add a switch -q in script/bin calling inittab 2024-12-16 19:57:25 or 'superquite' in boot cmdline 2024-12-16 19:58:45 or direct everything to logs 2024-12-16 20:03:08 I completely forgot about system log files, maybe I'll look at arch wiki for how to use syslog or something 2024-12-17 03:21:58 oh my latest LXQt-related MR has a pleasing number. 77177 2024-12-17 08:47:11 need a little review here 😇 !76424 2024-12-17 12:10:12 could someone please review this? !75826 thank you! 2024-12-17 18:34:03 https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/doc/apk-package.5.scd?ref_type=heads#L47 2024-12-17 18:34:46 in the _suffix part, what does mean? it does not appear to mean that _0 is allowed 2024-12-17 18:59:24 Habbie: according to apk version -c it's not 2024-12-17 18:59:44 indeed, i tried that 2024-12-17 18:59:53 but that makes me wonder what is meant by 2024-12-17 19:00:22 This is what I've reverse-engineered based on output from apk version -c: https://gitlab.alpinelinux.org/alpine/go/-/blob/master/version/doc.go 2024-12-17 19:01:52 s/cvc/cvs/ i bet 2024-12-17 19:01:56 what's the pre/post distinctION? 2024-12-17 19:01:59 oops, shift 2024-12-17 19:02:12 Habbie: right 2024-12-17 19:03:38 notably, whatever no-suffix means appears to be missing from yours :) 2024-12-17 19:03:51 yes, since apk version -c does not allow it 2024-12-17 19:03:59 right :) 2024-12-17 19:04:09 so we're at "you very clearly see what i am seeing" 2024-12-17 19:04:11 which is nice 2024-12-17 19:15:26 How do I patch a patch file, I can't merge the patch files together because there's a downloaded one for a package 2024-12-17 19:17:09 And then when I do patch it by command, it says it is a symlink 2024-12-17 19:17:35 maybe you can show us what you have and what you tried on a pastebin 2024-12-17 19:17:41 because these words are not a clear story to me 2024-12-17 19:41:31 Ok here https://asciinema.org/a/YLsDrDrftARvJ3kAniX5DuGdr 2024-12-17 19:43:32 Also my APKBUILD: https://pastebin.com/RtTbnRrg 2024-12-17 19:50:28 Actually forget the pastebin just go here: https://gitlab.alpinelinux.org/Pursuable1652/aports/-/tree/master/testing/linux-hardened 2024-12-17 20:09:20 I'd like to raise a question from MR !77176 here. The context are the embedded toolchains (those targeting MCUs where 256 KiB RAM and 1 MiB flash are considered plentiful and no MMUs are used). Those are sadly painfully slow to build, especially on RISC-V. 2024-12-17 20:11:15 Some time ago we limited building of exotic targets to mainstream host systems to reduce the load on the CI and builders. I think that building the mainstream targets (ARM Cortex M + RISC-V MCUs) was disabled due to issues on RISC-V hosts. Is that correct and re-enabling them is fine? 2024-12-18 07:43:45 hey team, is there any reason why fmt being upgrade to v11 wouldn't trigger a rebuild of dependent packages? ie waybar and gnuradio still looking for v10 2024-12-18 07:56:01 The pkgrel for these packages needs to be bumped for the packages to be rebuilt. We try to make sure all dependent packages are included, but apparently some were missed 2024-12-18 08:17:02 I'll look at it 2024-12-18 08:17:25 and just merged open MRs with rebuilds of waybar and tiledb 2024-12-18 08:32:11 !77255 2024-12-18 18:32:20 If an app requires a binary version of itself for its builds, packaging it would require bootstrapping all the way from the beginning, right? 2024-12-18 18:34:37 yes that's correct, you'd probably end up with a -stage0 package and the package itself 2024-12-18 18:34:46 sbcl and sbcl-stage0 are a good example of this 2024-12-18 18:35:04 we use ecl to bootstrap sbcl-stage0 and then use sbcl-stage0 to build sbcl itself. 2024-12-18 18:37:10 I see, thanks 2024-12-18 18:38:01 Oh, and Bun apparently sources it's own version of Zig 2024-12-18 18:38:05 Pain 2024-12-18 19:24:31 omni: thanks! 2024-12-18 20:05:18 kaathewise: send them ken's "reflections on trusting trust" 2024-12-19 09:51:30 btw !77231 and !77107 are already acked 2024-12-19 09:59:33 thanks! 2024-12-19 12:51:35 hi, I need an approval here !76424 2024-12-19 14:44:40 So, for a while now KDE has had Alpine Linux CI to test builds with Musl. For that they create their own Docker image which just pre-installs most of the system dependencies they need. This works well enough but is a bit annoying with regards to Qt. They require specific versions of it and almost always the latest version available. To accomplish this I've made their Docker image use Alpine edge for now but this has the downside that 2024-12-19 14:44:40 there be a chance of being able to provide such a thing? I wouldn't mind maintaining those packages just like I do for regular stable and edge but I just need infrastructure to host it. I can see this being useful in wider Docker context as well. 2024-12-19 14:44:40 any other unrelated change also makes it into that image and sometimes causes breakage. For the other distros they test they add an additional repository that has the specific Qt version they need so they can just enable that on a stable version of the distribution. This repository is hosted/maintained by the distro, not by KDE. I'd love to do the same but currently Alpine doesn't have the infra for such kind of repositories. Would 2024-12-19 15:50:28 PureTryOut: you do not have an dev.a.o account? 2024-12-19 15:56:38 I do. I suppose that could be used for such a repo, but would that be ok? 2024-12-19 17:04:04 Sure 2024-12-19 17:04:24 as long as it’s not too much data 2024-12-19 17:04:48 storage is always a concern 2024-12-19 18:06:17 im trying to get greetd working. I get an error in cage.c:299 XDG_RUNTIME_DIR is not set in the environment 2024-12-19 18:06:33 i have set XDG_RUNTIME_DIR in the /etc/init.d/greetd 2024-12-19 18:07:54 and I have also verified that the /etc/pam.d/greetd pulls in base-session, which has -session optional pam_rundir.so 2024-12-19 18:08:51 ... which is not installed ... 2024-12-19 18:08:59 i need to install pam-rundir 2024-12-19 18:15:24 clandmeter: it'll take basically the same space as the Qt packages do right now. Should be fine then. Thanks for the suggestion! 2024-12-19 19:59:26 Are there any docs on how to use ap properly? Help doesn't tell me much, I can't find anything online and there are no manpages it seems 2024-12-19 20:01:21 Trying to use ap builddirs to get the order in which to build a bunch of stuff but I'm failing badly lol. 2024-12-19 20:01:46 Seems I need to pass the packages as a string otherwise it'll complain that it can't find the APKBUILD. However if I do it doesn't print any result 2024-12-19 20:03:06 Actually I passed -d wrong. It just always says it can't find the apkbuild... 2024-12-19 20:03:53 Oh, -d needs a full absolute path... 2024-12-19 22:00:05 what is current lowest/oldest cpu support for desktop (atleast xfce)? 2024-12-19 22:00:26 core2duo will work? 2024-12-19 22:00:42 i686 2024-12-19 22:01:20 i recall something about kms to be set in these cpu 2024-12-19 22:01:35 i am trying core2duo today 2024-12-19 22:03:54 its x86_64 (T5550) 2024-12-19 22:05:35 or nomodeset? 2024-12-19 22:34:16 ah, resorting to other bootable distros 2024-12-19 22:51:51 i think desktop setup in al is missing some steps 2024-12-19 22:52:15 or ignoring knowingly some 2024-12-19 23:09:23 its looking for fbdev 2024-12-19 23:30:16 ok, seems cannot figure out/setup graphics card for sis 2024-12-19 23:30:49 card0(xfce) or GPU not found (sway) 2024-12-19 23:31:34 modules seems loaded (sis_agp) 2024-12-19 23:58:33 not important, just suggesting fn name changing, want_tiny_cloud() to do_tiny_cloud() in mkinitfs/initramfs-init.in 2024-12-20 00:01:51 3DfX, S3 Savage, SiS, VIA, and Matrox really work quite badly, if at all, since around Kernel 6.3... Might consider using an older version of Alpine on that. 2024-12-20 00:14:41 T5550 would usually come with something like X3100 (gma965) 2024-12-20 00:15:22 lspci should tell you 2024-12-20 00:28:59 zcrayfish: thanks, will try next week, going to figure out sound in asus-notebook 2024-12-20 00:29:17 benpicco: thanks 2024-12-20 00:31:26 module gma500_gfx is there 2024-12-20 00:31:43 gma500_gfx is for Atoms with PowerVR GPU 2024-12-20 00:31:51 ok 2024-12-20 14:10:33 question about elogind (polkit-elogind) 2024-12-20 14:11:39 the https://wiki.alpinelinux.org/wiki/Greetd says that seatd is recommended. why? 2024-12-20 14:18:37 ncopa, as greetd is a lightweight greeter, seatd being the lightweight solution, it's referred there.. 2024-12-20 14:19:45 also both are from the same developer 2024-12-20 14:19:50 looks like elogind also has power down and reboot features. needed for xfce. does seatd has something similar? 2024-12-20 14:19:59 oh ok, interesting 2024-12-20 14:20:25 no, it does not do anything other than seat management 2024-12-20 14:20:58 "seat management" is a systemd concept, isnt it 2024-12-20 14:21:17 seat management is a requirement in wayland 2024-12-20 14:21:41 does it do it via dbus? 2024-12-20 14:23:38 only that much i know, here is the developer page https://sr.ht/~kennylevinsen/. 2024-12-20 14:24:10 since i use sway in desktop i do use dbus 2024-12-20 14:27:03 as per documentation, seatd does not depend on dbus i.e only on libc. 2024-12-20 14:37:32 ncopa, In #alpine-infra channel i suggested providing a search option to search all irclogs in irclogs.a.o with channel and time period as filters. This will help users to find previously answered questions/doubts. Since we currently do not have a forum, irc logs do have a lot of valuable information. Is this feasible? 2024-12-20 14:50:39 i dont have anything agianst it, but i also dont have time to work on somethign like that 2024-12-20 15:13:38 wayland doesn't explicitly (afaik) call for dbus, but there needs to be some ipc at the implementation level (to pass fds and whatnot), so it ends up being dbus. 2024-12-20 15:40:11 ncopa, for wayland XDG_RUNTIME_DIR is another mandatory requirement. mkrundir in testing from WhyNotHugo offers good solution, if seatd is to be used 2024-12-20 15:41:01 invoked: wayland handles passing fds just fine, this is how the client sends buffers to the compositor (and viceversa). 2024-12-20 15:43:01 ncopa: seat management is not done via dbus. seatd exposes a socket in /var/run/ 2024-12-20 15:44:07 If you have the time, see the faq: https://man.sr.ht/~kennylevinsen/seatd/ 2024-12-20 15:44:43 Essentially, seatd provides the compositor with access to the input and output devices, without the user needing to have access to the devices nodes directly. 2024-12-20 15:49:20 Strictly speaking you don't need d-bus at all for wayland. Some progams (e.g.: Firefox) implement screensharing via flatpak's xdg-desktop-portal (a dbus service) instead of using the wayland-native protocol. In these cases you need the xdg-desktop-portal, and a compositor-specific "portal backend" which works as glue between the compositor and the xdp. 2024-12-20 15:51:04 Compositors which use wlroots rely on libseatd directly for seat management. libseatd will use seatd or logind, whichever is available. 2024-12-20 15:55:56 WhyNotHugo, thank you for creating mkrundir. Why this is still in testing? 2024-12-20 15:56:57 prabu: I might still change how it work in backwards-incompatible ways. 2024-12-20 15:57:33 So don't want to put it in communiy as "something stable" yet. 2024-12-20 15:59:10 WhyNotHugo: yeah, that's what i was referring to (portals, et al) 2024-12-20 15:59:10 ok. thanks..looking forward to it in main so that it seatd+greeter can be a fully functional alternative for elogind+polkit 2024-12-20 16:00:29 s/greeter/greetd 2024-12-20 16:02:02 invoked: portals are not a wayland thing. They're a flatpak thing. But often times folks will send PRs to projects saying "this introduces wayland support" whereas it actually introduces "flatpak support". You can still use portals without flatpak, but they add like 3 layers of abstraction and intermdiate services to any operation. 2024-12-20 16:03:14 prabu: SOME polkit functionality relies exclusively on logind. Identifying users by group membership works anywhere, identifying users by "is logged in at the physical terminal" is tied to logind. 2024-12-20 16:03:16 but like you said, stuff like firefox is using portals now 2024-12-20 16:03:50 i guess it depends on how people look at it. i just look at it as "wayland ecosystem" 2024-12-20 16:03:50 invoked: yup, you need at least three additional services to screenshare on firefox. 2024-12-20 16:05:21 Er, no, you need four additional services, you also need pipewire. 2024-12-20 16:06:19 which also needs dbus :) 2024-12-20 16:06:32 Yup. You need dbus+xdp+xdp-impl+pipewire 2024-12-20 16:07:59 One of those intermediate services just uses the wayland-native screencopy protocol, which Firefox could just use directly by itself. 2024-12-20 20:02:11 setup-desktop xfce, using alpine-extended-3.20.3-x86.iso does not show login in old asus atom notebook 2024-12-20 20:02:59 v3.18.x is ok i think same issue , as in all new kernels and old hardware 2024-12-20 20:04:01 alpine-extended-3.20.3-x86_64.iso does not even boot 2024-12-20 20:04:55 but it went all ok (xfce setup) in 2nd generation i5 dell laptop 2024-12-20 20:07:49 thanks for fixing those battery indicators 2024-12-20 20:40:03 this mean by next al cycle, there will not be any desktop support for hardwares prior to yr.2014 2024-12-20 20:41:01 well cmd line still there, maybe play mpv via ssh 2024-12-20 20:41:42 or via a web-app 2024-12-21 08:13:37 ikke: can you rerun the renovate MR jobs on the `alpine/go` repo? The job logs have expired and I want to try to figure out why they failed 2024-12-21 11:38:03 iggy: I've removed the MRs and let renovate recreate them, since they were made before the bot token expired, so the user no longer exists 2024-12-21 11:50:53 iggy: I suspect golangci-lint needs to be updated, trying to figure out why renovate bot does not make MRs for that 2024-12-21 12:00:59 (expiring tokens are very anoying, especially when that means the bot user is removed) 2024-12-21 14:02:06 did, apk add xf86-video-fbdev xf86-video-sis xf86-video-vesa, now xfce starts and usual. wifi, sound, video ok (v3.18.6-x86, core2duo-T5550+sis graphics card) 2024-12-21 14:02:30 video playbacks' a little sluggish(due to larger/recent format). it shows some funny white blurr on screen edges when lightdm starts 2024-12-21 14:03:28 note, before doing "setup-desktop xfce" i add those xf86 pkgs 2024-12-21 14:03:39 it has asustek motherboard, with 4usb ports, thinking to convert it to a local nas/disk-sharing device. 2024-12-21 14:04:20 zcrayfish: ^ 2024-12-21 14:06:16 its kinda going nice, don't want to attempt v3.20 ;) 2024-12-22 00:12:00 is there a way to see what pmbootstrap is currently doing? It's been sitting at > (native) install android-tools for over an hour now 2024-12-22 00:16:35 ah nvm, there is --details-to-stdout 2024-12-22 00:49:51 What is currently the state of the usr-merge (or the current blockers)? I looked into https://gitlab.alpinelinux.org/alpine/tsc/-/issues/73 and a few of the linked issues but they pretty none of them had any activity in the last few weeks. Is there just no one working on it right now or is the work going on (behind the scenes) in some issues/PRs not referrenced there? 2024-12-22 08:13:00 "What is currently the state of..." <- i think people are just in the holidays 2024-12-22 08:13:47 btw issues/MRs related to the usr merge are also added to the milestone: https://gitlab.alpinelinux.org/groups/alpine/-/milestones/16 2024-12-22 13:25:45 getting error 500 on gitlab when trying to create MR, requestID=01JFQ8KGQQ1NHJJJJQP9GYG9W4, https://gitlab.alpinelinux.org/kaey/aports/-/merge_requests/new?merge_request%5Bsource_branch%5D=victoria-logs 2024-12-22 13:26:28 kaey_: That can happen when your branch is to far behind the upstream branch 2024-12-22 13:30:55 that worked, thanks 2024-12-22 14:33:59 says rndis was re-enabled, https://git.alpinelinux.org/aports/commit/?h=3.21-stable&id=728d9f9cef32d2e0f412317506369e3b122ed9ff 2024-12-22 14:34:42 probably was meant for v3.21.1 2024-12-22 15:52:03 don't understand the security reasons as why it was removed, host machine and always have firewalls 2024-12-22 15:52:33 seems the whole code got deleted even the legacy folder 2024-12-22 15:53:22 host machine can^ 2024-12-22 16:26:14 looks like another "game of control", this time a stupid one, it breaks billion devices 2024-12-22 17:24:50 https://pkg.go.dev/gitlab.alpinelinux.org/alpine/go@v0.10.1/version -- from this EBNF it seems like version can have more than one suffix? 2024-12-22 17:26:01 yes 2024-12-22 17:26:09 at least, to apk version -c 2024-12-22 17:26:34 apk version -c 123_git1_alpha2 2024-12-22 17:27:30 ok, til 2024-12-22 17:38:05 From output of apk version -t it seems that the last suffix determines how does it compare to version without suffixes? 2024-12-22 20:14:19 would anyone be able to look at this MR? It's been sitting for a while. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75466 2024-12-22 20:58:09 and also !75827 would be nice to have :) 2024-12-22 21:23:46 https://pastejustit.com/3zb8ipyqbv 2024-12-22 22:07:00 ncopa: ikke: https://packages.debian.org/buster/firmware-intel-sound , is this pkg'ed ? 2024-12-22 22:08:07 hmm, sorry, its in non-free category 2024-12-22 22:31:58 how to fix this, https://tpaste.us/5QX7 ? 2024-12-22 22:42:17 strange, firmware-nonfree-20240909/brcm/brcmfmac43340-sdio.ASUSTeK COMPUTER INC.-TF103CE.txt is pkg'ed 2024-12-22 23:02:24 probably can be packed, https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/intel/fw_sst_0f28.bin 2024-12-23 07:27:25 ncopa: there are plans to pkg full https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ ? 2024-12-23 07:40:46 these are noarch pkgs, why can't i just re-use it, its already signed by upstream, it would have been more useful if upsteam made a squashfs format available 2024-12-23 07:41:36 without having to put extra efforts on distro side 2024-12-23 07:42:52 just download/mount and bind required into current /lib/firmware 2024-12-23 07:44:58 alpine can store its checksum and/or sig and verify if required 2024-12-23 08:07:25 current download size of it is now 600Mb+ 2024-12-23 09:05:52 uhg that's ridiculous size 2024-12-23 09:45:49 It's nice of alpine to split that into target packages 2024-12-23 09:51:12 yes... i kinda wish there were an aggregate pkg for "everything reasonable size" tho 2024-12-23 09:51:43 so you could just get that and only need to individually select a couple big ones 2024-12-23 10:00:43 I agree, or even better, a tool that automatically probes and tells what's actually needed 2024-12-23 10:01:12 Maybe that already exists though ^^ 2024-12-23 12:53:02 its already being done on mobile divices, but then ... 2024-12-23 12:53:13 "these are fixed hardware devices, meaning even if you threw these divices in magic well for 100yrs their hardware profile will not change" 2024-12-23 13:29:07 patches are welcome... 2024-12-23 13:39:31 anyone have experience with greetd and wayland? im struggeling a bit to create a nice, working login manager config for xfce 2024-12-23 13:39:41 I got it working sort of 2024-12-23 13:39:55 but as soon as I start dbus, greetd no longer want start 2024-12-23 13:47:32 this is bcos of missing run dir.. please check greetd page in wiki 2024-12-23 13:48:33 the greetd user needs to have runtime dir 2024-12-23 13:50:26 a few solutions will solve this. pam-rundir or WhyNotHugo's mkrundir@testing 2024-12-23 13:51:38 I have pam-rundir installed 2024-12-23 13:52:00 so if I log in as user and run startxfce4 --wayland, it works 2024-12-23 13:52:12 if dbus service is not running, it also works 2024-12-23 13:52:39 The question is, how do I get openrc service to go via pam-rundir? 2024-12-23 13:53:11 it does not seem to help to set XDG_RUNTIME_DIR in init.d script either 2024-12-23 13:54:42 which greeter you're using.. is it gtkgreet 2024-12-23 13:55:31 yup 2024-12-23 13:56:04 and which compositor.. cage or sway 2024-12-23 13:56:27 here is a reproducer: https://tpaste.us/QKR8 2024-12-23 13:56:29 cage 2024-12-23 13:57:34 i faced some issues with cage and i reverted back to sway.. yes..some issue was there in cage. it failed for me too.. hence i updated wiki with instructions for sway 2024-12-23 14:01:18 ok. I am trying to fix those issues now 2024-12-23 14:05:54 sorry ncopa for not being able to help 2024-12-23 14:06:09 trying to figure out this is supposed to work 2024-12-23 14:08:37 when i looked at setup-desktop, sddm for kde, gdm for gnome, lightdm for mate/xfce and none for sway earlier..i was thinking about approaching you about a consistent lightweight default login manager for all 2024-12-23 14:09:36 I don't want KDE Plasma to use a different display manager than SDDM 2024-12-23 14:10:04 i think it makes sense to have different login managers for the different desktop envs 2024-12-23 14:15:28 If other login managers can start polkit and other needed things, maybe, but not as default. Took me too long to figure out lxdm didnt launch xfcepolkit and other important session stuff prior to setup-desktop existing 2024-12-23 14:15:55 NVM gdm and sddm not starting the xfce session at all 2024-12-23 14:17:26 seems like greetd requires systemd. or expects systemd 2024-12-23 14:17:48 elogind you mean? I doubt it actually needs the service manager 2024-12-23 14:18:20 it expects XDG_RUNTIME_DIR be set and created 2024-12-23 14:18:26 which is what systemd does 2024-12-23 14:18:46 it's set just fine with SDDM without systemd. Pretty sure elogind handles that part 2024-12-23 14:18:56 im talking about greetd 2024-12-23 14:19:07 I know, doesn't change my point 2024-12-23 14:20:19 then I am doing someting wrong, and I dont know what 2024-12-23 14:20:24 mkrundir@testing by WhyNotHugo handles XDG_RUNTIME_DIR for sway.. but did not work for cage 2024-12-23 14:21:01 greetd and cage works if system dbus is not running 2024-12-23 14:21:09 as soon I start dbus it fails to work 2024-12-23 14:21:29 and apparently I am doing something work since ssdm works just fine 2024-12-23 14:21:53 I dont understand how this is supposed to work 2024-12-23 14:22:04 i guess im just too stupid for wayland 2024-12-23 14:23:34 message+ 2497 1 0 10:29 ? 00:00:00 /usr/bin/dbus-daemon --system --nofork --nopidfile --syslog-only 2024-12-23 14:23:37 prabu 3423 3413 0 10:29 tty1 00:00:00 dbus-run-session sway 2024-12-23 14:24:03 i believe there are two dbus sessions.. one for user and other for system.. 2024-12-23 14:25:32 XDG_RUNTIME_DIR is independent from systemd though 2024-12-23 14:40:25 "exec dbus-launch startxfce4 --wayland", will also set XDG_RUNTIME_DIR for startxfce4 ? 2024-12-23 14:43:59 or export $(dbus-launch) before then exec .... 2024-12-23 14:53:12 hum 2024-12-23 14:53:23 elogind appears to automatically stop after a while 2024-12-23 14:54:20 no, it runs, its just openrc that thinks it is stopped 2024-12-23 14:54:31 alpine-vm:~# /etc/init.d/elogind status 2024-12-23 14:54:31 * status: stopped 2024-12-23 14:54:38 alpine-vm:~# ps xa | grep elogind 2024-12-23 14:54:38 3668 ? S 0:00 elogind-daemon 2024-12-23 14:57:44 i had this weirdeness for quite a while 2024-12-23 15:08:07 seems like greetd does nto work with elogind? 2024-12-23 15:08:27 I dont know how to redirect the error messages on vt1 to the serial console or file 2024-12-23 15:10:40 if i stop seatd and start elogind, i get error something like: libseat.c:79 No backend was able to open a seat 2024-12-23 15:11:02 backend/session/session.c:83 Unable to create seat: Function not implemented 2024-12-23 15:11:07 ... 2024-12-23 15:11:26 Failed to load session backend 2024-12-23 15:11:36 Failed to start a session 2024-12-23 15:11:55 failed to start a DRM session 2024-12-23 15:12:07 cage.c: Unable to create the wlroots backend 2024-12-23 15:14:25 If I start seatd, I gett the following error: ../cage.c:568 Unable to open Wayland socket: Invalid argument 2024-12-23 15:22:11 I found the problem 2024-12-23 15:22:14 Dec 23 15:17:53 localhost auth.warn elogind[3711]: Directory "/run/user" already exists, but has mode 0775 that is too permissive (0755 was requested), refusing. 2024-12-23 15:22:14 Dec 23 15:17:53 localhost auth.err elogind[3711]: Failed to create /run/user: File exists 2024-12-23 15:22:59 if I change the /run/user to 755 it wrks 2024-12-23 15:23:16 now to investigate what creates /run/user 2024-12-23 15:24:09 Ermine: on systemd, XDG_RUNTIME_DIR is set by pam_systemd 2024-12-23 15:34:30 ncopa, i tested with cage/gtkgreet-greetd/xfce4-wayland/pam-rundir works without issues 2024-12-23 15:35:28 yeah 2024-12-23 15:35:30 it works 2024-12-23 15:35:45 but something creates /run/user with wrong permissions 2024-12-23 15:35:54 and I dont know what 2024-12-23 15:36:25 where are you facing that error.. i don't even get that error message.. 2024-12-23 15:36:56 I enabled debug logging in seatd 2024-12-23 15:37:17 i think it is pam-rundir 2024-12-23 15:37:37 i suspect pam rundir 2024-12-23 15:48:54 yup. it was 2024-12-23 15:57:32 prabu: yes it works, and now I have also fixed pam-rundir 2024-12-23 15:59:35 but new problem: when logging out, I get error from greetd 2024-12-23 15:59:49 good ncopa, but i still don't see that error.. what actions trigger.. ofcourse i've not yet enabled debug in seatd 2024-12-23 16:00:24 Failed to open device /dev/dri/card0 resource temporarily unavailable 2024-12-23 16:00:40 for me xfce4-wayland works nearly perfectly.. 2024-12-23 16:01:01 except slowness due to my pc/hardware 2024-12-23 16:01:13 sounds like udevd setting wrong permisssions on /dev/dri/card0 2024-12-23 16:01:18 shoudl be in video group 2024-12-23 16:01:54 prabu: what happened was: I enabled pam-rundir. I did not rc-update add greetd, so I had to log in first 2024-12-23 16:02:02 i have util-linux-login, which is pam enabled 2024-12-23 16:02:14 so pam-rundir created /run/user 2024-12-23 16:02:18 with wrong permissions 2024-12-23 16:02:31 later elogind discovered that the directory already existed 2024-12-23 16:02:40 and backed out with the error 2024-12-23 16:03:09 rdBF5seCfwg: I just need to restart greetd and it works again 2024-12-23 16:03:37 I suspect that labwc is not completely shut down when greetd tries to take over again 2024-12-23 16:05:20 ok.. but i'm able to do everything you're explaining.. but not facing errors..have you made any change to anything.. 2024-12-23 16:05:45 you probably have elogind start with openrc at bootup? 2024-12-23 16:05:50 except restarting greetd after adding to default run-level 2024-12-23 16:07:58 no i don't have elogind.. it's not even running.. i checked a few times 2024-12-23 16:08:26 when i enabled it once.. and i noticed the error log in /var/log/message 2024-12-23 16:09:05 well, this solved it for me: dd93abfe56e03317779bee7b9acc8d8ebfab7baf 2024-12-23 16:09:29 https://git.alpinelinux.org/aports/commit/?id=dd93abfe56e03317779bee7b9acc8d8ebfab7baf 2024-12-23 16:10:07 prabu: maybe you use busybox login, which does not use pam 2024-12-23 16:10:48 true.. 2024-12-23 16:10:59 anyway, that problem is solved now 2024-12-23 16:11:19 and with this i dont need util-linux-login, and can use busybox login again 2024-12-23 16:11:35 because I dont need to do startxfce4 from CLI 2024-12-23 16:11:58 i've not changed the login eventhough i installed the util-linux-login as per your script 2024-12-23 16:13:45 I think I'm gonna create subpackages for greetd configs 2024-12-23 16:14:00 and dont ship any config at all with greetd 2024-12-23 16:14:30 so you woudl do: apk add greetd-config-gtkgreet 2024-12-23 16:14:40 or maybe the other way around, with install if 2024-12-23 16:15:27 if you install greetd and gtkgreet you also pull in a greetd-gtkgreet-config package 2024-12-23 16:18:06 do u intend to add cage as dependency 2024-12-23 16:18:22 which currently is not 2024-12-23 16:18:31 the idea is to make something that "just works" 2024-12-23 16:18:41 apk add and it just works 2024-12-23 16:19:15 currently, if you apk add greetd && /etc/init.d/greetd start 2024-12-23 16:19:18 it will not work 2024-12-23 16:19:43 so you go to the config file and see if you need configure anything 2024-12-23 16:19:51 and then you realize you need a greeter 2024-12-23 16:20:10 and then you need to configure it 2024-12-23 16:20:25 and you need configure either cage or sway or something else 2024-12-23 16:20:41 i want this to "just work" 2024-12-23 16:21:13 yes true.. it makes sense. i believe it should be cage then 2024-12-23 16:23:16 and without the patch dd93abfe56e03317779bee7b9acc8d8ebfab7baf itself, everyhing works here.. can you test one more time.. 2024-12-23 16:25:53 yeah, sure it works as long as you dont login first, with PAM 2024-12-23 16:26:09 but I have other issue now 2024-12-23 16:26:16 logout 2024-12-23 16:26:29 race condition on logout 2024-12-23 16:27:45 ok.. have you stopped lightdm already 2024-12-23 16:29:34 i'm not facing any of these behaviours even though i followed your steps. i'm having vanila 3.20 upgraded to 3.21 to edge now 2024-12-23 16:30:47 i reboot qemu, greeter welcomes me i login, work normally logout no issues and reboot the cyle continues 2024-12-23 16:32:44 and i removed util-linux-login as mentioned earlier.. that is the only change 2024-12-23 16:38:12 so, this is what, 'setup-desktop cage'? 2024-12-23 16:39:21 cage/et al 2024-12-23 16:39:56 or is this just for greetd? 2024-12-23 16:40:23 just for greetd.. it needs a wayland compositor 2024-12-23 16:41:09 if grapphical greeter is used 2024-12-23 16:41:18 like gtkgreet 2024-12-23 16:41:52 there are greeters that don't require wayland compositors... 2024-12-23 17:22:57 ncopa: greetd does not require systemd, nor elogind. 2024-12-23 17:23:02 The default greeters don't either. 2024-12-23 17:23:21 But ALL wayland compositors require XDG_RUNTIME_DIR, since the spec specifies that this is where the wayland socket is placed. 2024-12-23 17:24:06 I'm not entirely sure that pam_rundir will help for this particular use-case, because I don't think that the pam login sequence is executed for the greeter user (I might be wrong on this tho) 2024-12-23 17:30:09 greetd DOES use pam for the post-login user. But that's the user that executes the actual session. That's different from the user which executes the greeter itself. 2024-12-23 18:09:50 WhyNotHugo, pam-rundir seems to work for "greetd" -the greeter user too.. i thought this was not working a few days back.. seems like this works.. 2024-12-23 18:14:05 both in edge and 3.21 2024-12-23 18:15:29 thanks for confirming 2024-12-23 18:20:01 if you've time, please checkout https://tpaste.us/QKR8 by ncopa..with and without util-linux-login. 2024-12-23 18:23:19 to ensure greetd works out of the box without editing files manually 2024-12-23 19:00:46 is it possible to change mkinitfs /init script I tried putting it in /etc/mkinitfs/features.d/init.files, changing /etc/mkinitfs/mkinitfs.conf with features="init", and inside init.files is /init and /init is my custom script I want to do something while booting initramfs but it seems /init is unaffected, sorry this is an involved question 2024-12-23 19:08:42 I need initramfs to launch my script in /etc/scripts/my-custom-script.sh that does exist in the initramfs, so I wanted to modify /init to tell initramfs to launch that script 2024-12-23 20:21:19 Nevermind I figured it out, but had to edit /sbin/mkinitfs 2024-12-23 22:44:06 btw !76192 is ready to merge 2024-12-23 23:18:17 ncopa: will it be make sense to convert existing firmware pkgs to squashfs and mount in skel or not-so-big modloop ? 2024-12-23 23:19:09 its kinda simple, use full firmware upstream and extract its directory structure, build skel 2024-12-23 23:19:28 2. add any necessary firmwares fit 2024-12-23 23:19:57 3. apk add firmware adds it as mount on it 2024-12-23 23:21:27 its kinda lengthy to re-build modloop if missing firmware, or ping here to add 2024-12-23 23:22:50 3. if any of those squashfs file is in /boot dir its mounts it on boot 2024-12-23 23:47:23 should not require lots of changes, i write a POC scripts if it makes sense 2024-12-23 23:48:08 i can write some ^ 2024-12-24 06:10:58 I am assigned on !77110, and it looks great and I appreciate someone helping, but I can't approve anything 2024-12-24 06:11:05 Can someone smash that merge button? 2024-12-24 06:11:48 Just leaving a comment or a thumbs up suffices 2024-12-24 06:11:57 (which I see you've done) 2024-12-24 06:12:19 Ahh, okay, didn't know if something more was needed from my end 2024-12-24 08:28:03 vkrishn_: maybe? I dont know 2024-12-24 11:13:44 want help in python port !77397 , not sure if I am right 2024-12-24 11:15:02 ACTION bot: Draft: testing/{sqlfluff, py3-pytest-datadir, py3-diff-cover}: new aport https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77397 2024-12-24 12:01:30 BTW, is any plan upgrade python to 3.13 ? 2024-12-24 12:47:32 yeah, we will upgrade to python 3.13, but not sure when. we have literally thousansa of py packages and they all need to work with 3.13 2024-12-24 12:49:05 :/ 2024-12-24 12:49:20 i love how python constantly breaks things... 2024-12-24 12:49:33 3.12 was stressful 2024-12-24 12:50:02 C has like 1 or 2 very minor theoretically breaking changes that maybe affect 1 or 2 programs in a decade 2024-12-24 12:50:05 I dont know what the status is for other distros, but generally I don't want be the first distro 2024-12-24 12:50:10 python breaks everything every minor version 2024-12-24 12:50:21 yeah 2024-12-24 12:50:33 so gratuitously stupid 2024-12-24 12:50:47 gcc14 introduced lots of breakages 2024-12-24 12:50:59 warnings -> errors 2024-12-24 12:51:04 but not in the language 2024-12-24 12:51:14 the broken code was already invalid in the language for 30+ years 2024-12-24 12:51:28 yup 2024-12-24 12:51:41 valid programs didn't break, only invalid ones did 2024-12-24 12:51:49 but it still was lots of work to fix or work around it 2024-12-24 12:51:53 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16335 2024-12-24 12:52:00 archlinux apparently already ships python3.13 2024-12-24 12:52:11 vs python where version N is like "you should use the method called foo" and version N+1 says "no foo is gone now it's called fooo" 2024-12-24 12:57:15 dont get me started. they also implement API that is broken by design, and when trying make it "work" with musl they complain. 2024-12-24 13:03:27 apparently musl libc is not supported on python. https://github.com/python/cpython/pull/18380#issuecomment-1976807263 2024-12-24 13:05:29 ACTION facepalms 2024-12-24 13:07:43 *sigh* 2024-12-24 13:40:22 ncopa: 3 years then "too much code we won't merge this until we support musl officially" 2024-12-24 13:44:44 musl unsupported -> write code to support it -> too much code for an unsupported target -> musl unsupported 2024-12-24 13:44:47 catch 22 2024-12-24 13:45:33 there's really no special code needed to "support it" 2024-12-24 13:46:06 just do what's done on any of the countless systems python works on that aren't gnu/linux: 2024-12-24 13:46:30 don't offer interfaces that are gnu/linux specific and make gnu/linux assumptions 2024-12-24 13:46:52 like that cursed "get the path to the .so" one 2024-12-24 13:47:14 Lol TIL half of the world of Python servercode (if not more) runs on an unsupported setup 2024-12-24 13:47:40 since this PR exists, some code is needed, though it's because stuff is misdesigned 2024-12-24 13:47:40 :) 2024-12-24 13:47:58 well what's needed is to fix the code calling that function not to call it 2024-12-24 13:48:22 pretty much all the calls to it are cargo-culted, not because someone actually needed a path to do something with it 2024-12-24 13:53:10 dalias: agreed 2024-12-24 13:54:14 more people should use musl, Imo. Everytime I need to look at libc code I always look at musl, because it's quite readable and simple 2024-12-24 13:54:29 But I guess I'm not the only one who thinks that here :p 2024-12-24 13:54:38 ACTION too 2024-12-24 13:56:13 i mean it's crazy: http://bananas.debian.net/debian/libc/README.txt what they do? 2024-12-24 13:58:18 same thing with systemd 2024-12-24 14:00:09 it's all fine, stuff is moving in good direction 2024-12-24 14:04:28 "Lol TIL half of the world of..." <- they even have a own container image based on alpine 2024-12-24 15:02:47 dalias: most of the python breakages in the past 2 major versions have been the removal of modules that have been deprecated for something like 5-10 years 2024-12-24 15:04:25 so it's mostly old code that needs patching 2024-12-24 15:44:05 well that's good 2024-12-24 15:52:43 i think there is something not ok with current EFI boot in x86, best described here, https://tpaste.us/5QXx 2024-12-24 15:56:50 also x86_64 fails to boot on Atom Processor Z36xxx/Z37xxx, kali boot to x86_64 kernel 2024-12-24 16:07:22 slight changes, https://tpaste.us/voNk 2024-12-24 16:10:16 can it be reproduced in qemu? 2024-12-24 16:16:21 i need a template on how to boot with EFI 2024-12-24 17:17:19 what would me max RAM addressed by x86.iso boots ? its showing 3.1G 2024-12-24 17:46:33 Hi, I would like to submit an MR to alpine/aports to enable udmabuf support in kernels for alpine containers on gh workflows ci but I'm not sure if configuration for this section should have all the same options for lts/edge or if there are any platforms where it doesn't make sense to enable it 2024-12-24 17:47:38 I have forked and cloned aports, so I'm ready to write an MR, just not sure what it should look like for all the related dmabuf options in the udmabuf section 2024-12-24 18:11:21 I went ahead and created an MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/77572 2024-12-24 18:28:12 and I closed it because TIL the host OS needs the config, not the container (thanks minimal) 2024-12-24 20:45:43 "I went ahead and created an MR..." <- Might still be of interest for VMs and bare metal installs 2024-12-24 22:40:01 modemmanager's build produces libmm-glib as a subpackage, but it also has `libmm-glib=$pkgver-r$pkgrel` in its own makedepends, which wouldn't exist until after the build. So how does builder manage to build it? (I looked for MR pipeline logs but the newest one's logs have already been cleaned up) 2024-12-25 07:07:00 Arnavion: abuild will exclude any subpackages when calculating the build time deps https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L2375 2024-12-25 07:07:26 Thanks 2024-12-25 07:08:05 I think this dep is only to ensure that modemmanager has a versioned dependency. otherwise apk may be happy with an older version of the lib 2024-12-25 16:15:11 !76192 and !76245 are both ready i think 2024-12-25 16:23:48 !76192 2024-12-25 16:24:11 !76192 2024-12-25 16:24:23 !76245 2024-12-25 20:21:57 abuild takes a lot of time to start building a package due to git rev-list . Can something be done about that? 2024-12-25 20:23:55 Changing it `git rev-parse HEAD` 2024-12-25 20:25:50 But `git rev-list -1 HEAD` is fast for me as well 2024-12-25 20:27:00 Maybe with a bit of details about what's actually being done with rev-list there 2024-12-25 20:27:56 It's doing `git rev-list -1 HEAD -- $startdir` 2024-12-25 20:27:56 idk, abuild -r calls it 2024-12-25 20:29:11 Ermine: If you manually run that command, does it take a long time for you? 2024-12-25 20:29:37 This shouldn't take more than a few ms at worse 2024-12-25 20:29:52 nope 2024-12-25 20:30:26 Are you sure it's that com 2024-12-25 20:30:30 command that takes time 2024-12-25 20:30:37 How much time are we talking 2024-12-25 20:31:01 That's the only rev-list command abuild does 2024-12-25 20:31:29 Could have been in a package 2024-12-25 20:31:52 Because the question says *a* package, not packages in general 2024-12-25 20:31:55 But still unclear 2024-12-25 20:33:05 Also I'm asking about if it's that command for sure, not if it's that rev-list call 2024-12-25 20:34:00 when i run it manually, it runs slowly as well 2024-12-25 20:34:28 Maybe cleanup your git repository 2024-12-25 20:34:33 With gc 2024-12-25 20:49:12 doesn't seem to help: real 1m0.336s user 0m57.055s sys 0m3.227s 2024-12-25 20:50:08 1 minute oO 2024-12-25 20:50:16 btw, git rev-parse -1 HEAD is fast for me as well, but git rev-parse -1 HEAD -- $startdir (what abuild does) is slow 2024-12-25 20:51:52 Ahhh 2024-12-25 20:51:56 the first one gives the latest commit hash, while the second prints the letter 'z' 2024-12-25 20:52:58 Yeah, because it has to unroll all commits tree until it finds one with your path there 2024-12-25 20:54:43 And if your aport hasn't been touched in a long time… 2024-12-25 20:55:12 that's a new aport, so the path never was there in the first place 2024-12-25 20:55:56 Then that's weird 2024-12-25 20:56:23 while the second prints the letter 'z' 2024-12-25 20:56:46 You mean that "git rev-parse -1 HEAD -- path/new_port" litteraly prints 'z' only? 2024-12-25 20:56:55 yes 2024-12-25 20:56:57 hu 2024-12-25 20:57:30 let me check it though 2024-12-25 20:58:49 well, it prints nothing. Maybe I pressed 'z' accidentally and forgot about it :] 2024-12-25 20:59:30 ^^ 2024-12-25 20:59:43 Sorry but are you sure it's committed? 2024-12-25 21:00:01 the new aport? not yet 2024-12-25 21:00:18 Well.. 2024-12-25 21:00:26 You won't get a commit hash out of it if there's no commit 2024-12-25 21:01:02 That's why it's long, it basically runs over the full tree from last to initial commit, and finds nothing related to your new uncommitted aport 2024-12-25 21:03:51 Sounds reasonable. I'll commit the aport as a workaround 2024-12-25 21:04:28 There are only advantages about committing your work :) 2024-12-25 21:06:10 Though 1m for that still seems slow. `mkdir testing/foobarbaz; time git rev-list -1 HEAD -- testing/foobarbaz` on my system takes ~1.7s 2024-12-25 21:06:57 Maybe you're using an SSD 2024-12-25 21:07:56 I am, but if it was just because of disk speed then subsequent runs would be faster due to cache for Ermine too 2024-12-25 21:08:24 i have nvme 2024-12-25 21:09:48 Can you do `git reflog expire --expire=now; git gc --aggressive --prune=now; git gc --aggressive --prune=now` and see if it changes? 2024-12-25 21:10:12 Well, that is if you really want to get rid of your reflog 2024-12-25 21:10:20 Yes 2024-12-25 21:10:44 Just in case it's built up from lots of previous rebases and such 2024-12-25 21:10:54 The reflog isn't a problem 2024-12-25 21:11:24 I didn't say it is. The `gc` is more pertinent 2024-12-25 21:11:33 And I already suggested to gc the repo, I suppose either Ermine did it or did not want to 2024-12-25 21:12:21 i did git gc 2024-12-25 21:12:41 Yes, so try with `--aggressive --prune=now` 2024-12-25 21:40:48 Ermine, any luck? 2024-12-25 21:41:09 quinq: gc is still in progress 2024-12-25 21:51:46 git rev-list still takes around the same amount of time 2024-12-25 21:54:02 If gc also took 30 mins, then I guess your CPU and/or disk is just slower enough than mine to cause that difference 2024-12-25 21:55:00 gc aggressive takes a lot of time anyway 2024-12-25 21:56:04 Arnavion: i did your first command, which does gc twice, so one gc is around 15min 2024-12-25 21:56:32 Sure, but even then, one gc --aggressive takes ~70s for me 2024-12-25 21:56:45 O.O 2024-12-25 21:56:50 Though it's less comparable than rev-list because most of the gc --aggressive is parallelized so it depends on the number of cores 2024-12-25 21:57:01 i have 16 cores 2024-12-25 21:57:24 I have a 7950x so that's 32 CPUs (16 * 2) 2024-12-25 21:58:47 Regarding the number of commits there, it'll take quite some time on my dual core 2024-12-25 22:01:08 Anyway for your situation there's the obvious fix you already did of committing your directory, but otherwise it might also help to make a partial clone of aports using --depth instead of a full one 2024-12-25 23:59:40 I don't recall where i got this, probably ncopa, a decade back, it times full git object access , https://tpaste.us/oxgL 2024-12-25 23:59:49 probably useful 2024-12-26 01:09:10 is s390x builder busy or stuck? 2024-12-26 01:21:01 ci is offline. edge builder is fine 2024-12-26 01:21:34 known issue, waiting for a server reboot 2024-12-26 14:29:19 sertonix[m]: fakeroot failes to build to to a patch that does not apply 2024-12-26 15:22:49 that was probably my doing 2024-12-26 15:22:53 i rebased it 2024-12-26 15:28:56 oh ok 2024-12-26 19:48:10 The s390x ci builder is back 2024-12-26 20:29:57 awesome! thanks! 2024-12-26 21:54:01 Ermine: To skip `git ref-list` in abuild you can do `git=true abuild`. The resulting package will not include any commit information but that is fine for most cases. 2024-12-26 23:38:57 ncopa: pretty please, upgrade to https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75827 mesa 24.3.2+ ; mutter speedups, OpenCL for Adreno; squashed extra fix from upcoming 24.3.3 😉 (Christmas bonus) 2024-12-27 08:10:38 bug fun with busybox - part 1 , https://tpaste.us/knXa 2024-12-27 08:24:33 vkrishn: when kill the 'login -- toy' process, also kills the current root login session 2024-12-27 08:27:23 but why does it show in ps ? 2024-12-27 08:29:00 looks like cosmetic bug 2024-12-27 08:44:43 MR !77655 ready for review/merge to upgrade catfish to match rest of XFCE 4.20 release 2024-12-27 09:03:19 Had to fixup missing builddeps that didn't show up until run in the CI, but it is all green now 2024-12-27 09:07:25 vkrishn: could be, i may delve deeper if/when i find time 2024-12-27 09:50:19 vkrishn: i would say cosmetic. until bb login has failed 3 times, it won't exit back to getty, so it will retain it's argv and consequently the ps entry for it will still show the logname of the first attempt. 2024-12-27 09:51:37 that is how i read it, anyways 2024-12-27 10:36:55 Saijin_Naib[m]: merged it. maybe we can move it to community as well? 2024-12-27 13:02:40 Possibly already discussed but couldn’t find anything. Apart from dedicating resources to it, have it been considered to include https://wiki.alpinelinux.org/wiki/Immutable_root_with_atomic_upgrades in the installer? I’m aware it’s only PoC although the guide has been improved for a few years already. Or maybe I’ve set my hopes on how stable the PoC implementation is. 2024-12-27 13:52:24 Hi there, just wanted to check about an MR for adding a new package. It's been up for a month now and got marked stale, but it's been ready to merge since I made the MR. If it's just a matter of waiting no worries, I just wanted to check. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/75756 2024-12-27 14:32:04 looks like apkbuild-lint i've got from atools-20.2.2-r9 doesn't know about loongarch64. the gitlab ci lint thus must be using something else? 2024-12-27 14:39:10 yes, ci also has shellcheck 2024-12-27 14:40:05 ovf: It uses atools-go 2024-12-27 14:40:22 I didn't get to packaging it yet 2024-12-27 14:42:01 thanks! it's generally pretty sweet to have things matching ci as close as possible locally 2024-12-27 14:42:18 yes 2024-12-27 15:36:05 @ncopa ideally all of XFCE stuff should be there, but my concern as always is I am bad at this 2024-12-27 15:36:25 I will need help and guidance 2024-12-27 16:17:13 Saijin_Naib[m]: with what exactly? 2024-12-27 16:35:16 When to backport, how to do it, when to bump pkgrel to fix a build/dependency error if that happens on stable 2024-12-27 16:35:44 Stuff like that. I use my aports on edge for personal and family, not production 2024-12-27 16:36:00 I can deal with a breakage, you know? 2024-12-27 16:36:17 Just worried about the difference in process and expectations 2024-12-27 16:36:29 backporting is a matter of cherry-picking commits (or creating new commits even) on the relevant stable branch 2024-12-27 16:36:45 You generally backport security issues and bugfixes 2024-12-27 16:36:52 opinions vary but yeah, this isn't debian :) 2024-12-27 16:36:57 non-breaking feature releases may be backported as well 2024-12-27 16:38:13 where non-breaking is defined as: someone on a stable branch should be free to upgrade within a stable release without their setup breaking 2024-12-27 16:39:24 pkgrel should be bumped whenever the package should be rebuilt, but there is no new version 2024-12-27 16:39:26 Never done a backport, I am not a dev. I'm barely a packager 2024-12-27 16:39:32 no worry 2024-12-27 16:39:42 We can help you with that 2024-12-27 16:39:49 Hmm, when do I know the change is non-breaking? If it doesnt bump depends? 2024-12-27 16:40:09 Generally by reading changelogs 2024-12-27 16:40:45 Ah, okay. So this will require a bit more domain-knowledge to sniff things out 2024-12-27 16:41:18 Like my catfish bump... was that safe for latest-stable? 2024-12-27 16:43:06 Do I need to be using latest-stable to package and test? I use a ton from edge, so I am on edge 2024-12-27 16:43:28 catfish is still in testing, so there would not be anything to backport. This is a desktop application, so it's a bit more difficult to define what would be breaking 2024-12-27 16:44:12 changelog is here: https://gitlab.xfce.org/apps/catfish/-/blob/master/NEWS 2024-12-27 16:44:47 I don't see anything in the changelog that would be concerning 2024-12-27 16:45:00 Yeah, ported to meson, fixes. Only deps that changed were dropping some python ones from makedeps and adding others 2024-12-27 16:45:46 if you're a maintainer of a package, then you should consider the different ways your package will get used, and more fundamentally (imo) try avoid doing custom stuff if you can help it 2024-12-27 16:45:58 I guess I'm struggling with this isn't clear-cut, so I'm likely to make a mistake 2024-12-27 16:46:29 Makes sense. I want the stuff I package to work fully and as expected 2024-12-27 16:46:43 it's ok, stuff breaks sometimes which usually will not be any fault of your own, but you have to learn somewhere 2024-12-27 16:46:50 indeed 2024-12-27 16:47:15 Custom stuff I did for catfish was add plocate and zeitgeist to make search as fast as possible 2024-12-27 16:49:06 generally you want to stick to upstream defaults unless there's a really good reason 2024-12-27 16:49:20 (that everyone agrees on) 2024-12-27 16:49:30 They have them as optional build/run deps so 2024-12-27 16:49:41 It improves user experience a ton 2024-12-27 16:50:00 🤷 it was what I would want to use, I guess 2024-12-27 16:50:15 Some people prefer minimal setups though 2024-12-27 16:50:16 that might be ok. i don't know anything about catfish 2024-12-27 16:51:20 Cant please everyone 🤣 2024-12-27 16:51:51 that is the nature of this work 2024-12-27 16:52:08 Catfish is fs search tool that csn search in files and archived as well as across fs structure. Fast seemed good 2024-12-27 16:52:35 Thunar can also use it for searching 2024-12-27 16:53:09 Saijin_Naib[m]: The way it's generally solved is by having those dependency be optional (opt-in) 2024-12-27 16:53:56 Let apk trace them out for runtime deps and only set as builddeps? 2024-12-27 17:03:57 ovf: I've just pushed atools-go to testing, if you upgrade and have testing enabled, you should get apkbuild-lint from atools-go 2024-12-27 17:57:42 ikke: thanks! you probably meant to do replaces=? right now it conflicts with atools 2024-12-27 17:58:04 It needs replaces as well 2024-12-27 17:59:08 interestingly enough, apk fix figured it out 2024-12-27 17:59:26 yeah, it's just during upgrade that it complains 2024-12-27 17:59:34 (i'd have expected apk fix to be more idempotent w.r.t. things like upgrade -a) 2024-12-27 18:00:09 It has to do with the order of operations in the transaction 2024-12-27 18:00:43 i see you've retained the surprising behaviour of always requiring the filename :-) 2024-12-27 18:01:02 heh :D 2024-12-27 18:01:14 It _was_ supposed to be a drop-in replacement :-p 2024-12-27 18:02:46 ok, i'll just have 'alint' calling 'apkbuild-lint APKBUILD' :-) 2024-12-27 18:03:30 I can probably adjust that in a next release to use the APKBUILD file in the local dir if it exists 2024-12-27 18:05:44 https://gitlab.alpinelinux.org/alpine/infra/atools-go/-/issues/8 2024-12-27 18:11:17 thanks 2024-12-27 19:41:28 for catfish, when I move to community and simplify deps, do I put a post-install console message to add mlocate/plocate/zeitgeist to improve performance? 2024-12-27 19:41:36 Or is that abusing that functionality? 2024-12-27 20:37:17 No that's fine 2024-12-27 20:40:34 Hmm... Okay, I'll try that, though, for me, I appreciate not having to dig for everything. I guess optional runtime deps not being installed is more Alpinish 2024-12-27 20:40:56 User is expected to be a bit more motivated to discover, which is fine 2024-12-27 20:56:08 Tbh I'd like some way to automatically install optional deps as well, but yeah just not something Alpine has atm so things like this are the next best thing 2024-12-27 21:18:34 Saijin_Naib[m]: given that's a gui application, i feel it should be its responsibility to indicate its preference for optional tools in its ui 2024-12-27 21:24:46 Except that the application won't know what the names of the packages are in the distribution. And it would be nice if the distro could auto-install things like this if-so desired 2024-12-27 21:47:24 @ovf ui clutter is no bueno, imo. Tricky problemspace... 2024-12-27 22:33:00 sway terminal issue, https://tpaste.us/waae 2024-12-27 22:33:38 That's a shell feature, the terminal has nothing to do with ti 2024-12-27 22:34:19 ok 2024-12-27 23:05:52 Hi, I've been working on an APKBUILD for https://github.com/evilsocket/opensnitch, and was wondering if it's okay to use pip to install grcpio-tools to the build directory? There doesn't appear to be a package for py3-grcpio-tools, and it's required to build opensnitch's UI (Though not to install it). 2024-12-27 23:07:26 Correction, py3-grpcio-tools 2024-12-28 07:25:02 Aclide: It would be better to createa a package for it 2024-12-28 07:34:34 I see. That's kinda what I was concluding to when I was referencing other packages. 2024-12-28 07:34:56 As things stand right now, I got it working after version bumping py3-protobuf and patching py3-inotify to fix a bug with importing asyncore. 2024-12-28 07:38:01 I guess the next step would be changing the community/grpc APKBUILD to add a py3-grpcio-tools subpackage? 2024-12-28 08:49:38 Figured out what's going on. Turns out the tools are supposed to be included, but the make_grpcio_tools.py gets a non-fatal error 2024-12-28 15:38:14 Hello...HAPPY NEW YEAR IN ADVANCE... (full message at ) 2024-12-28 15:39:59 Hello...HAPPY NEW YEAR IN ADVANCE... (full message at ) 2024-12-28 16:56:00 👇♦FREE 💰 SIGNALS 👇... (full message at ) 2024-12-29 21:52:08 rndis_host.ko missing in 3.21-x86 iso 2024-12-29 21:53:24 you mean rndis_host.ko.gz? 2024-12-29 21:55:09 ls -aR /.modloop/ |grep ko | head 2024-12-29 21:55:21 no gz..s 2024-12-29 21:55:29 ah right 2024-12-29 21:55:34 the modloop decompresses them 2024-12-29 21:56:09 aaand apparently yeah, there's no any rndis modules 2024-12-29 21:56:41 but firmwares ?, ls -aR /.modloop/ |grep firmware | grep zst | head 2024-12-29 21:57:11 not only that, rndis_host.ko is the only module missing in drivers/net/usb :/ 2024-12-29 21:57:25 3.21.0-x86_64 has it magically though 2024-12-29 21:58:24 firmware get zst, but ko don't get gz 2024-12-29 21:59:04 it ok if they are in squashfs(no compressed) 2024-12-29 21:59:33 but in .apk files they would save space 2024-12-29 21:59:53 i mean, the modules are decompressed when building the .iso, because the entire modloop squashfs is compressed 2024-12-29 22:00:02 ok 2024-12-29 22:00:07 but anyway 2024-12-29 22:00:15 the .apk for linux-lts doesn't have the module either 2024-12-29 22:00:22 so it's not a modloop/iso issue 2024-12-29 22:00:42 ah 2024-12-29 22:00:43 i read about the current removals 2024-12-29 22:00:54 lts.x86.config doesn't have this line: `CONFIG_USB_NET_RNDIS_HOST=m` 2024-12-29 22:01:19 and lst.x86_64.config 2024-12-29 22:01:24 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16682 2024-12-29 22:01:29 on x86_64 it got re-enabled 2024-12-29 22:01:31 but not on x86 2024-12-29 22:01:35 you can comment on this issue 2024-12-29 22:01:38 ok 2024-12-29 22:13:33 is it ok if dbus sockets that lighttd creates in /tmp have perms srwxrwxrwx ? 2024-12-29 22:17:36 yes, socket permissions don't really matter (in general that's not where you do client access control) 2024-12-29 22:17:50 thanks 2024-12-29 22:18:13 i have a strange looking file in /tmp, 7d3a857b-d5bf-4079-9cc0-02dcded06a9a.zip 2024-12-29 22:18:28 that's just tmp 2024-12-29 22:18:33 lots of programs throw trash in there 2024-12-29 22:18:49 i've got like 15 different chromium directories and a file named `f79d601e26a782fd149b3ffb098aae9f-{87A94AB0-E370-4cde-98D3-ACC110C5967D}` 2024-12-29 22:19:17 we love UUIDs, don't we? 2024-12-29 22:19:36 ok, did not see any zips earlier 2024-12-29 22:19:58 content seems like monitor/graphics setup, eg. file, cfa1f744-3c4f-40de-98bb-068d238633d9.meta.json 2024-12-29 22:20:23 :) 2024-12-29 22:21:46 https://tpaste.us/Rooo 2024-12-29 22:32:46 looks like this wifi BCM943224HMS, cannot have support in linux (proprietory firmwares) 2024-12-29 22:33:08 and rndis is out for new kernel 2024-12-29 22:33:23 wifi is doomed on this devices 2024-12-29 23:14:24 /etc/init.d/wpa_supplicant service might be broken on edge, does not seem on start on x86 2024-12-29 23:16:08 re-trying 2024-12-29 23:27:02 its ok, some mistypes 2024-12-30 01:30:40 hmmm, asus-notebook, x205taw graphics now broken in v3.20+(x86) upto edge, don't know which new pkgs to add 2024-12-30 01:36:06 its not even i686 :( 2024-12-30 01:40:16 will give a try again tomorrow 2024-12-30 16:22:41 whats wrong with the builders 2024-12-30 16:28:32 for some reason /bin/sh points to /usr/bin/dash 2024-12-30 16:28:35 not sure why 2024-12-30 16:34:33 git blame 2024-12-30 16:35:13 we have some package that sets different /bin/sh 2024-12-30 16:35:23 i suppose some of the packages built pulled that in as a dependency 2024-12-30 16:35:27 and things wen south 2024-12-30 16:35:35 we need to build in containers 2024-12-30 16:36:29 sigh, i rebooted wrong machine 2024-12-30 16:36:33 i hope it comes back 2024-12-30 16:39:59 we've all been there 2024-12-30 16:40:08 its back 2024-12-30 19:06:35 it would be nice to either merge !77720 or !77765 sometime soon 2024-12-30 19:06:44 it broke a lot of packages on 3.21 2024-12-30 19:32:55 I merged the downgrade, let's not break ABI on stable. 2024-12-30 19:33:17 I'd be fine with you taking over maintainership btw. Be warned, they update a lot and like you've seen without ABI-breakage notice 😅 2024-12-30 19:33:54 yep, i noticed that... not really nice by them. thanks! 2024-12-30 22:11:33 ncopa: is there something else you'd like to do for 76847? also if you'd like someone else listed as 'maintainer' for that pkg then I could volunteer or I could help find someone else to :) 2024-12-30 22:12:39 !76847 (go bot go!) 2024-12-30 22:54:57 Hi. Has someone used libucontext recently? Since at libucontext-dev in version 1.2 installed the bits.h header into /usr/include/libucontext/bits.h. Since at least 1.3.1, it installs it into /usr/include/arch/common/libucontext/bits.h. This results in a compilation failure for me now without adding -I/usr/include/arch/common to CFLAGS. But that is not done with pkgconf --cflags libucontext. It looks like a bug to me. 2024-12-30 22:56:14 Ariadne: You will probably now best if I'm just holding it wrong, or whether this is a bug. 2024-12-30 22:57:53 that does seem like a bug, unfortunately i am on holiday and wont be able to fix it until i am back 2024-12-30 22:59:20 please allow ~48h for a fix :) 2024-12-30 23:01:41 removal of consolekit2 did not get to release-notes/upgrade pages in v3.21 2024-12-30 23:05:18 Ariadne: I don't think I'm in a position to grant or deny any vacation from unpaid work on open source software :'D But IMO 48 hrs is an excellent response time to a bug report even without being on vacation. (May employer gets worse response time for paid services.) So thanks a bunch for all your work and for looking into it and enjoy your days off :) 2024-12-30 23:06:53 Also: Adding a simple cflag is an easy work around. So no need to rush the fix ;) 2024-12-30 23:53:21 ncopa, ikke: can one of you kick this spam bot? ^^ 2024-12-30 23:53:35 ACTION not sure who else can op here 2024-12-30 23:54:45 ACTION doesn't see any spam at the moment (on the irc side) 2024-12-30 23:56:21 ah it's coming through on the matrix side only I guess :/ 2024-12-31 01:46:43 for those wanting to upgrade from v3.18.x to v3.21 (specially with desktop) 2024-12-31 01:46:51 1. consolekit2 is gone 2024-12-31 01:47:28 2. dbus+polkit may need to be restarted first time manually 2024-12-31 01:48:23 3. if having mesa pkgs related installs, may need to install them manually 2024-12-31 01:50:07 4. before upgrading kernel, first try a new boot using v3.21 cdrom, install newly your desktops and see i things work 2024-12-31 01:51:06 \o/, and now i have oldkernel+v3.21 pkgs on asus netbook running ok 2024-12-31 01:51:34 audio is still a problem 2024-12-31 01:52:05 thanks algibot, don't worry you can get new kernels 2024-12-31 01:59:42 bit silly question, is there a way to start getty[0-6] after full upgrade, without rebooting? 2024-12-31 02:02:32 https://ptrc.gay/MZaOFycK 2024-12-31 02:02:45 kinda cute how the bot addresses me as "team/rust" but does mention my personal packages as well as team's 2024-12-31 02:03:15 also, if there's those combined emails, should i still be receiving the individual ones? 2024-12-31 05:43:41 maribu: well technically i was intending to no longer be on holiday but i got caught up in a blizzard… heh 2024-12-31 08:00:37 Oh shit, that's tough luck. I hope you can enjoy new years eve despite the blizzard at least a bit. 2024-12-31 10:57:15 alr !77734 is ready to merge 2024-12-31 11:42:07 We need a mod on the Matrix side of this room... 2024-12-31 12:03:54 yeah the matrix spam is really growing massively 2024-12-31 12:10:37 It's atm just this one account. We banned it from all pmOS rooms and they're banned from OFTC but it seems the ban hasn't gone through to Matrix 2024-12-31 12:32:16 Can someone ban James idowu Toyin @jay.hay:matrix.org for spamming the Alpine dev and linux channels. TiA 2024-12-31 14:10:39 cyclisme24[m]: don't see the spam 2024-12-31 14:11:40 perhaps click `report` on each of their messages and hope the matrix.org folks clean it up 2024-12-31 14:12:30 Us Matrix bunnies are getting bombarded by the same fool endlessly. Been reporting for days 2024-12-31 14:13:05 I know the matrix.org folks are slower than usual due to newyears 2024-12-31 14:13:19 but there's nothing the IRC ops can do 2024-12-31 14:14:18 and the matrix bridge's check for IRC ban isn't very smart either 2024-12-31 14:21:18 Oh. Not only have they been banned from all of OFTC they also were banned from this IRC channel 2024-12-31 14:21:28 > #alpine-devel has JamesidowuToyin[m]!*@* banned by ikke!~kevin@ikke.user.oftc.net on December 28 2024 at 17:27 2024-12-31 14:22:08 :/ 2024-12-31 14:41:20 if only matrix was as enthusiastic about fixing its spam problem as it was about making bridges 2024-12-31 14:49:29 invoked: via email they did tell me they're a bit slow because of holidays. 2024-12-31 14:56:54 the main problem, as i see it, is that matrix from the start made bridges that weren't subordinate enough to the things they're bridging to. in other words, we're still waiting for their bridges to do the right thing. 2024-12-31 14:58:06 oh of course 2024-12-31 14:58:11 but it's getting a bit off-topic :p 2024-12-31 14:58:19 agree 2024-12-31 14:58:55 but what I was saying is that it will take time until matrix.org cleans up the mess 2024-12-31 17:37:16 yeah, couple of years 2024-12-31 17:47:27 Thanks for everyone doing the admin-,y stuff. 2024-12-31 19:34:05 pj: I'd say until next year. And I'm being very serious :p 2024-12-31 19:37:29 leap year? 2024-12-31 19:38:04 well in a few days after their holidays maybe 2024-12-31 19:38:13 Let's see! 2024-12-31 19:38:22 But it looks like the spam stopped anyway. 2024-12-31 19:46:41 I don't think deleting messages is of any benefit, any matrix chanop can do it 2024-12-31 19:47:10 Now if they fixed abuse and moderation 2024-12-31 19:47:15 And bridges 2024-12-31 19:47:19 And clients 2024-12-31 19:47:25 that would be somethng 2024-12-31 20:23:27 id be up to deal with spammers sometimes 2024-12-31 22:53:19 HappyNewYear: ?