2024-09-01 03:08:16 Hey, this builds locally but fails on the CI 2024-09-01 03:08:18 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69597/diffs 2024-09-01 03:08:28 any idea what Im doing wrong? 2024-09-01 03:08:44 I tried it on a spare laptop I had and it builds 2024-09-01 03:11:25 sounds like you're not building it on edge with gcc13 2024-09-01 03:11:27 gcc14* 2024-09-01 03:15:11 ya, im using stable locally 2024-09-01 03:15:28 How do I force gcc14 on edge? psykose 2024-09-01 03:15:42 just be on edge and build it 2024-09-01 03:15:59 rootbld on master prolly does that 2024-09-01 03:16:00 forgot 2024-09-01 03:29:15 psykose: Im on stable and I *can* build it. Are the runners using edge? They cannot build it. 2024-09-01 03:29:33 the master branch of aports is edge, yes 2024-09-01 03:31:35 (if there is an mr to 3.21-stable then the runner would be building in 3.21 world, etc) 2024-09-01 04:06:03 huh 2024-09-01 04:06:23 I guess I will wait for next alpine release and see how haxe navigates it 2024-09-01 04:11:08 Habbie: the -latomic thing is incredibly painful because stdlib headers can just randomly decide to introduce atomic code from a distance and your code has no way of knowing 2024-09-01 04:11:28 or the compiler generates it because it wants to 2024-09-01 04:12:10 I think fundamentally it is foolish of the toolchain devs to not handle it the same way that -lgcc_s is handled by the gcc builtin specs 2024-09-01 06:08:10 abuild rootbld really helps, rust on my local is 1.78 while master(edge) is 1.80 2024-09-01 09:46:42 elibrokeit, ack 2024-09-01 17:01:28 Hi, if two packages are build from the same source and I update them both, do I still need to create two different PRs? 2024-09-01 17:02:20 wizzard: If you feel like it makes sense to put changes to multiple packages in one MR, you can do it. 2024-09-01 17:09:53 Thanks. That makes sense. 2024-09-01 17:13:41 I would be gratefull if MR !69824 could be reviewed or merged. 2024-09-01 17:13:41 The a2dp bug stops pipewire from crashing after suspend. 2024-09-01 21:06:35 I get a lot of glib warnings when packages get updated, like Warning: Schema “org.gnome.system.locale” has path “/system/locale/”. Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated. 2024-09-01 21:06:56 Is this something specific to the software itself, or the way it's packaged on Alpine? 2024-09-01 21:25:57 quinq: i looked that up, found a ref in gnome bugs to it and they know about. not just an alpine packaging issue 2024-09-01 21:26:27 unfortunately, i don't have a link nor do it remember the details 2024-09-01 21:27:11 but i do remember that i copy/pasted that error into web search and got to it from that search 2024-09-01 21:30:47 ok, thank you j_v :) 2024-09-01 21:31:19 I also get it for “org.freedesktop.ibus” 2024-09-01 21:32:49 Found the issue, “The warning happens since 2012” haha 2024-09-01 22:12:30 very serious software 2024-09-02 06:49:28 I was wondering if we can have digital ocean marketplace image for alpine linux 2024-09-02 06:49:53 https://marketplace.digitalocean.com/vendors 2024-09-02 06:50:16 Are we open to becoming a official vendor for alpine image there? 2024-09-02 06:51:10 I offer to coordinate, contribute, and maintain necessary packages/images to support this use-case 2024-09-02 07:00:47 I don't see other distros being offered on marketplace 2024-09-02 07:01:16 I'll explore more and share my findings. Is TSC a good place to create an issue for it? 2024-09-02 07:08:19 dhruvin: that should be ok i guess. we have an #alpine-cloud channel which may fit this discussion. 2024-09-02 10:59:44 -rw-r--r-- 1 buildoze buildoze 955.9G Sep 2 10:58 /var/cache/distfiles/buildlogs/build-edge-loongarch64/community/datovka/datovka-4.23.8-r0.log 2024-09-02 11:00:54 oof 2024-09-02 11:01:38 i think i copied this before, or it was a diff pkg 2024-09-02 15:28:11 if anyone is interested in helping, these are community build failures on loongach64, but probably also on other arches due to gcc 14 or other FTBFS. https://tpaste.us/YYQw 2024-09-02 16:54:30 clandmeter: i have fix for clamsmtp, mr forthcoming shortly 2024-09-02 16:58:56 i spent way too long wondering who's mister forthcoming 2024-09-02 16:59:27 mister premature 2024-09-02 17:01:23 🤔 2024-09-02 17:02:26 ouch 2024-09-02 17:02:41 shortly 2024-09-02 19:01:29 dalias, if i statically link musl, getaddrinfo() just works, right? 2024-09-02 19:01:57 same as normal 2024-09-02 19:02:10 oh i should just join #musl, this is rude 2024-09-02 19:02:13 psykose, thanks :) 2024-09-02 23:13:42 exit 2024-09-03 00:40:13 Can someone please add the tag:security to this MR? It's backporting the upgraded vim to resolve the indicated CVE's https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71312 2024-09-03 08:58:06 hello, I'm trying to compile Planify, a gtk4 planner for GNOME, written in vala https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71349 2024-09-03 08:58:36 at build time I've got some errors: Assignment: Cannot convert from `int64' to `time_t' 2024-09-03 08:58:47 do you know if that's something easily fixable 2024-09-03 09:44:33 raspbeguy: perhaps add samurai to makedepends? looks like it is failing when meson tries to run ninja, but i don't see either samurai or ninja-is-really-ninja in the makedepends for planify APKBUILD 2024-09-03 09:45:21 will try 2024-09-03 09:47:50 same probleù 2024-09-03 09:50:51 oh, looking farther up in build artifacts, i see ninja found, (i'm looking for error still) 2024-09-03 10:06:04 if i knew vala, i could maybe help. looking it up, as_timet_with_zone returns a long, so the assignment in question is actually an error. with older toolchains, probably just gives a warning. 2024-09-03 10:11:25 is see your issue at upstream. i would probably wait for upstream to address. though i do note that the variables that are being assigned to erroneously are referenced before the error, so i question if the time_t declarations are valid 2024-09-03 10:13:43 but, like i said, i don't actually know vala, i am looking at the code with 'c' colored glasses. 2024-09-03 11:25:08 raspbeguy: maybe you need to patch it for "start_time.as_timet_with_zone (system_timezone)" returns time_t instead int64 2024-09-03 11:26:39 check the sources 2024-09-03 11:27:59 donoban, I suspect start_time.as_timet_with_zone is not part of this project, I think it's in a standard lib 2024-09-03 11:31:37 https://valadoc.org/libical-glib/ICal.Time.as_timet_with_zone.html 2024-09-03 11:32:55 returns seconds converted _from_ time_t _to_ long 2024-09-03 11:35:01 hmm.. maybe the error is 'time_t start_unix', should be 'size_t'? 2024-09-03 11:36:22 is likely, not sure how it's used after 2024-09-03 11:36:33 after/later 2024-09-03 11:37:11 uhmm.. "The C documentation about date indicates that you can use the time_t type which expresses a date with the number of seconds elapsed since a specific date called Epoch." 2024-09-03 11:38:03 i think it is strange the the two variable names in question are referenced before that block that declares them, so not sure the safety of changing the code at that point 2024-09-03 11:40:04 but i agree, that removing the time_t or changing to size_t or ssize_t would make sense, from a 'c' point of view 2024-09-03 11:43:19 time_t looks fine for that purpose... the error seems to come from hardtyped int64 2024-09-03 11:47:40 if it were c code, i would agree, not sure about vala types. are they derived from c? 2024-09-03 11:49:13 I suppose that basic types should be equivalent but no idea 2024-09-03 11:50:54 yep, same here... 2024-09-03 12:14:15 a pkg i'm fixing has a maintainer that has not been active since 2019. would it be preferrable that i take maintainership of it as well? 2024-09-03 12:14:41 preferrable/acceptable 2024-09-03 12:22:17 did you try to mail the maintainer? 2024-09-03 12:22:37 no, but good point 2024-09-03 12:31:01 done 2024-09-03 18:46:07 i've seen somoeone trying to build/run/package gnustep for alpine, i'd like to join force 2024-09-03 22:09:32 tbh i've got a few APKBUILDs for the GNU Objective-C stuff that i never bothered to push 2024-09-03 22:09:59 mostly gnustep-base 2024-09-03 22:10:14 ptrc: that means also gnustep-make 2024-09-03 22:10:23 so only gnustep-gui and gnustep-back are missing? 2024-09-03 22:10:51 i've build the wayland backend as deb pkg on arm64, but i'd be interested in alpine, together with wlmaker 2024-09-03 22:11:18 i have yet to clone the apkbuilds to look at them and play 2024-09-03 22:12:25 i'm even more so interested, to continue aiei.ch/gnustep/ which stalled 10 years ago due to debian and iso building being constantly changing, and the mess with systemd 2024-09-04 01:57:29 raspbeguy: you can probably stick a (time_t) cast in front 2024-09-04 01:57:49 time_t is int64_t already so it's fine 2024-09-04 08:01:59 Admin please ban this shit @brayden_001:matrix.org  2024-09-04 10:58:50 psykose, that fixes it. However I wonder why nobody got this error before 2024-09-04 11:00:52 i dunno either 2024-09-04 11:02:37 as for _NL_TIME_FIRST_WEEKDAY it's indeed not a thing in musl at all 2024-09-04 11:39:19 it has annoyed me for a while that gtk gcalendar starts with Sunday instead of Monday 2024-09-04 11:39:52 yeah :( 2024-09-04 11:40:21 same for like `cal` and whatnot, they check for that at compiletime to use it at runtime with the right support 2024-09-04 11:40:43 only in like places that skip libc intl (like KDE) can you pick whatever 2024-09-04 11:41:56 apparently you can add a translation to change the first day: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkcalendar.c?ref_type=heads#L662 2024-09-04 11:43:09 en_GB should be monday then 2024-09-04 11:58:59 how do I set en_GB? 2024-09-04 11:59:12 LANG=en_GB xfce4-panel -r does not seem to do it 2024-09-04 12:01:04 that is pretty much how you set it 2024-09-04 12:01:25 but the things like the xfce panel cannot 'get first weekday of en_GB' cause the musl intl doesn't have it 2024-09-04 12:01:42 i'm guessing that gtk thing is some exception 2024-09-04 12:01:56 hmm 2024-09-04 12:02:21 yeah the panel isn't using gtk_calendar_init i don't think 2024-09-04 12:02:55 also po/nb.po seems to have the translasion, and my LANG was no_NB for norwegian bokmål 2024-09-04 12:03:17 yeah, that would be monday too 2024-09-04 12:03:25 so you need to run gtk_calendar_init 2024-09-04 12:04:23 hm it should get run cause the panel is probably using gtkcalendar after all 2024-09-04 12:04:34 gtk_calendar_init seems to be `static void` so it is not exported 2024-09-04 12:31:56 I tried to reach a maintainer by email but the email doesnt exists, should I try open an issue or what else 2024-09-04 13:30:01 do we have any s390x people from IBM here? the 6.6.49 kernel does not build on s390x 2024-09-04 13:30:46 looks like the same fix as f0bad214018954ee886fb2c11265586d2008a593 2024-09-04 13:31:47 ah guess not 2024-09-04 13:31:53 or uh 2024-09-04 13:31:58 dropping the patch would fix it 2024-09-04 13:40:10 thanks! 2024-09-04 15:20:54 annd mesa and friends seems like they have run into an issue during this process 2024-09-04 15:37:47 I dont understand why apprise fails on riscv64 and ppc64le. https://build.alpinelinux.org/buildlogs//build-edge-riscv64/community/apprise/apprise-1.9.0-r0.log 2024-09-04 15:37:57 i am not able to reproduce it either, in my dev containers 2024-09-04 15:45:49 maybe due to existing files in /tmp? 2024-09-04 15:50:28 i was to say that I have rebooted them, but i notice that rebooting does not wipe /tmp as expected 2024-09-04 15:51:55 Not tmpfs 2024-09-04 15:52:24 and the wipe-/tmp part of bootmisc is off by default 2024-09-04 15:59:05 looks like that was the issue, now it passed 2024-09-04 15:59:09 or it was a race 2024-09-04 15:59:12 and /tmp was slow 2024-09-04 15:59:21 due to way too many files 2024-09-04 15:59:51 ppc64le also passed after a reboot 2024-09-04 16:44:27 Haven't had much time to mess with it but mesa seems to be having issues. At least with amd anyway. Sway,kitty,etc all just garbled. I did a quick check to see if re-enabling swrast would fix it but no dice. 2024-09-04 16:47:15 does it show up in a screenshot 2024-09-04 16:48:39 for an aport, should the .conf file go to /etc/$pkgname/ ? 2024-09-04 16:53:30 can confirm. updated one of my desktops here and i'm seeing what xulfer is seeing, except with river and foot on amdgpu 2024-09-04 16:53:37 no bueno 2024-09-04 16:54:09 just blank windows. 2024-09-04 16:54:53 is it after a reboot 2024-09-04 16:55:03 yes. new kernel also 2024-09-04 17:33:39 it's strange. some things work. launcher doesn't display but it works. bar doesn't display. browsers seem to work. added alacritty and that works. at some random point the screen goes black and i have to quit river. 2024-09-04 17:34:08 I thought that what was interestng to show with secfixes was when, and with what verson of a package built by us, a CVE was addressed !71382 2024-09-04 17:34:14 i can't get any useful output to indicate what's going on. 2024-09-04 17:34:50 that's how I have treated "secfxes" and imagined I've seen others do 2024-09-04 18:31:54 fabricionaweb: It depends a lot on where the application expects the file 2024-09-04 18:51:29 is it possible to install alpine linux with GPT/ Bios legacy and lvm on LUKS along side? 2024-09-04 18:52:55 Please do not post the same question in multiple channels. This question is more suited for #alpine-linux 2024-09-04 18:56:42 Has somebody tried to upgrade vala to 0.56.17? I tried and there are now 10 failing tests 2024-09-04 18:58:16 Here is the failing tests log https://termbin.com/cp1l 2024-09-04 19:00:25 thanks ikke 2024-09-04 20:08:53 I just rebooted after updates and yeah, seeing a garbled sway mouse cursor and the modeline looks like unitialized graphics data on the top of each monitor 2024-09-04 20:09:50 oops, wrong channel, sorry about that 2024-09-05 01:53:54 FYI this fixes some regressions with recent changes to alpine-conf: 71449 2024-09-05 01:54:03 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71449 2024-09-05 02:01:29 ncopa ^^ 2024-09-05 05:08:07 miostreams: 2024-09-05 05:08:16 oops, sorry 2024-09-05 10:23:59 hi all, https://dpaste.org/MkM7h 2024-09-05 10:24:34 i'm trying to build kernel with rust support (based on linux-edge) 2024-09-05 10:40:14 https://gitlab.alpinelinux.org/indy/aports/-/commit/6e9170af677ed58065947bb96f0ec7562aa07bc3 2024-09-05 15:22:17 Hi all, I've not been able to get https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70132 reviewed, who can I ping to have it looked at? 2024-09-05 15:32:18 hm, it looks like the last activity from the package's maintainer was 2 years ago... 2024-09-05 15:34:24 would be nice if someone from IBM / OpenMainframeProject stepped up for this 2024-09-05 16:22:40 Any chance we could get this fix merged soon? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71449 2024-09-05 16:23:12 Without it, all alpine-conf scripts are broken (e.g. setup-timezone) 2024-09-05 16:24:39 oh ouch 2024-09-05 16:24:41 yeah 2024-09-05 20:24:42 Hey there! I wanted to let you know that I have a Telegram channel where I share some amazing Verified sauce and soft cashout... (full message at ) 2024-09-06 05:55:25 Hi, is anyone looking into the graphics issue on sway (at least with AMD GPUs) after a recent update? I see that xulfer said above that it likely was caused by a mesa update. 2024-09-06 05:58:07 is there a gitlab issue about it? 2024-09-06 06:00:48 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16422 2024-09-06 06:02:27 ptrc: Thx for reporting this! :) 2024-09-06 06:07:44 thanks! 2024-09-06 06:28:23 maribu: it was reported upstream to Mesa. I bet if someone could bisect mesa and blame a commit, it might help :P 2024-09-06 06:28:30 There is 2024-09-06 06:28:37 https://gitlab.freedesktop.org/mesa/mesa/-/issues/11846 2024-09-06 06:29:40 Sadly no traction there so far 2024-09-06 06:33:55 ya but it hasn't been bisected yet, there's no commit/patch blamed in that issue? 2024-09-06 06:34:38 it's kinda a lot of work to do that, but imho it can make it easier for mesa maintainers to identify/fix the problem if it's not obvious based on the issue report alone 2024-09-06 06:58:37 I also got the Sway issue today 2024-09-06 07:00:31 Amd gpu 2024-09-06 07:00:33 ? 2024-09-06 07:19:11 yap 2024-09-06 07:19:14 downgrading mesa worked 2024-09-06 07:19:21 thks ptrc ~ 2024-09-06 07:31:52 we need someone to git bisect it 2024-09-06 07:32:10 or 2024-09-06 07:32:22 just build it for latest mesa git, and see if problem is still there 2024-09-06 07:35:53 It's also not just wayland/sway 2024-09-06 07:36:10 it happens in X as well. Try kitty for instance. 2024-09-06 08:00:45 i'll try bisecting then 2024-09-06 08:00:54 and we might actually downgrade the version in aports for now.. 2024-09-06 10:50:43 ptrc: Yeah I was going to maybe MR that, but wasn't sure if since it's edge there might not be an expectation for it to be in a working state. 2024-09-06 10:51:47 You should expect things to brea, but they don't have to remain broken :p 2024-09-06 10:52:34 If no clear fix is in sight and it affects many users, reverting is perfectly fine (though it does require users to use --available to automatically downgrade) 2024-09-06 10:53:15 Ah good to know 2024-09-06 10:56:05 pushed a commit that disables LTO 2024-09-06 10:56:26 because apparently that fixes the issue for me on both machines 2024-09-06 10:57:14 Oh interesting 2024-09-06 11:07:44 Fix is working on my end as well. 2024-09-06 11:28:50 Hmm it seems odd to me that it seems like we have changes coming based on systemd filesystem documents. Even going so far as getting rid of /usr/sbin (which simplifies permissions imo). 2024-09-06 11:29:05 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/73 is what I'm referring to btw 2024-09-06 11:31:29 i think it's more that systemd is the only place which bothered to properly document it 2024-09-06 11:31:34 FHS has been dead for a long while 2024-09-06 11:31:41 xulfer: fyi, we're (or pmos actually) are trying to get the FHS updated so that there is qn actual standard 2024-09-06 11:31:59 ptrc: it's getting revived 2024-09-06 11:32:04 Also nothing should be moving away from POSIX 2024-09-06 11:32:33 POSIX doesn't define anything with /bin or /sbin AFAICT 2024-09-06 11:32:42 there's only /dev and /tmp 2024-09-06 11:32:51 im about to tag new stable releases now 2024-09-06 11:33:04 ncopa: 👍 2024-09-06 11:33:45 Yeah might have jumped the gun there :) 2024-09-06 11:34:03 I thought maybe /bin/sh, but even that is left open 2024-09-06 11:34:12 in that discussion for instance on sbin the justification is 'might as well, arch does it' 2024-09-06 11:34:35 and based on some systemd stuff that isn't even codified and maybe shouldn't be 2024-09-06 11:34:41 ( looking at POSIX 2024 XBD 11., very little is defined in POSIX itself, unless i'm missing some section ) 2024-09-06 11:35:04 FHS has been dead for a long while 2024-09-06 11:35:06 I wish 2024-09-06 11:35:08 ptrc: Yeah I misinterpreted something there. :/ 2024-09-06 11:35:59 skarnet: you probably mean implementation here, i mean how the spec has been left to rot :p 2024-09-06 11:36:03 ptrc: FHS is alive and well and packages will install their binaries in /bin or /usr/bin until the end of time despite it making upgrades a race condition every single time 2024-09-06 11:36:17 yeah 2024-09-06 11:36:37 the spec, well, it can keep rotting 2024-09-06 11:37:18 it's indeed unfortunate that systemd seems to be the only group caring about standardizing these things, because they're going to standardize the systemd way 2024-09-06 11:37:23 Well and it seems like a hassle to deal with all of those cases with little payoff or justification other than other people are doing it, and another distro is looking into systemd. 2024-09-06 11:38:00 skarnet: yeah unfortunate 2024-09-06 13:46:32 ptrc: xulfer: mesa-24.2.2-r0 working for me as well. thanks. (i'm assuming the issue carried over to 24.2.2.) 2024-09-06 13:47:44 the underlying cause was gcc LTO 2024-09-06 13:47:55 gcc with no LTO or clang with/without LTO works just fine 2024-09-06 13:48:56 yeah, so maybe toolchain, if it changed 2024-09-06 13:49:56 the previous mesa build was with gcc13 2024-09-06 13:50:10 the underlying issue of 'mesa with gcc lto breaks randomly sometimes' is known for years 2024-09-06 13:50:53 nobody has root caused it because to root cause it you need to be able to debug the broken state and know a lot of mesa internals and also know how the compiler misoptimises it so the amount of people capable of doing it is in the single digits 2024-09-06 13:51:13 gotcha 2024-09-06 13:52:34 i think the only consistency is that it's always been amdgpu that breaks 2024-09-06 13:53:53 do you know if llvm builds are more reliable? 2024-09-06 13:54:17 or i guess those don't have lto. 2024-09-06 13:54:23 nevermind 2024-09-06 15:18:59 is krupenik around? 2024-09-06 15:20:32 Never seen them here 2024-09-06 15:20:46 wanted ot move intel-compute-runtime to community 2024-09-06 15:21:43 i was in the middle of packaging it when I found out it was already there but under a different name 2024-09-06 15:22:45 wait how is it not in the repo anymore 2024-09-06 15:23:36 oh unmaintained, got removed 2024-09-06 15:23:56 in eb615cfe36e8ace329bc1ff3012d58811ef125fc 2024-09-06 15:24:37 i guess its mine now 2024-09-06 15:37:03 we dropped llvm14 right? 2024-09-06 15:41:59 b96225b647e750c99ac1caada9f58ace2ca05595 2024-09-06 15:42:41 ty 2024-09-06 15:44:08 looks like fedora builds it with 15 2024-09-06 15:44:38 But don't assume llvm15 will be around very long either 2024-09-06 15:45:06 ill take care of it later, people are already complaining about the old llvm dep in the intel-graphics-compiler 2024-09-06 15:45:49 i can also try to bump it to 16 and see how it goes 2024-09-06 16:09:21 handling llvm versions is a bloody mess 2024-09-06 16:10:51 i am happy alpine has llvm18 available as that let's me build zig from src w/o having to get it myself 2024-09-06 16:28:06 my mkimage error "wpa_supplicant=coreutils: unable to select package (or its dependencies)" 2024-09-06 16:30:27 the intel graphics compiler is a requirement to get qsv working on alpine, but its a lot of trouble to package it 2024-09-06 16:30:39 im following arch, they build everything locally 2024-09-06 16:30:57 and ill put pressure on the issue to get a more recent llvm version 2024-09-06 16:31:12 bl4ckb0ne: you mean through aur? 2024-09-06 16:31:14 (locally) 2024-09-06 16:31:21 https://gitlab.archlinux.org/archlinux/packaging/packages/intel-graphics-compiler/-/blob/main/PKGBUILD?ref_type=heads 2024-09-06 16:31:26 no, they get all the deps 2024-09-06 16:31:52 ah like that 2024-09-06 16:31:58 i can probably use the packaged spirv stuff 2024-09-06 16:32:04 but no chance for clang/llvm 2024-09-06 17:47:12 nice, there's a whole cross compiling setup in their test folder in the release 2024-09-06 17:50:16 im getting `Cannot utime: No such file or directory` when untaring, is there a way to pass the -m flag to tar? 2024-09-06 17:58:36 ikke: any thoughts on whether we want to do a world rebuild and upgrade to Go 1.22.7 or jump straight to 1.23.1? 2024-09-06 17:58:43 I think we could try Go 1.23 now 2024-09-06 18:01:43 Hello, could someone give an eye on !68908 and !69669 please? They are pretty old 2024-09-06 18:06:12 nmeum: i would say the latter, though that might mean some packages can fail to build 2024-09-06 18:06:33 ok, let's do it then 2024-09-06 18:09:15 lots of things have already moved on to 1.23 2024-09-06 18:34:37 ikke: is it even wortwhile to rebuild world just for a DOS in encoding/gob? the other CVE fixes in the current release just affect the toolchain 2024-09-06 18:35:02 what even is gob 2024-09-06 18:36:15 https://pkg.go.dev/encoding/gob 2024-09-06 18:36:21 I hadn't heard of it before either 2024-09-06 18:36:26 yeah but 2024-09-06 18:36:27 "Package gob manages streams of gobs" 2024-09-06 18:36:36 and 0 external links to anything 2024-09-06 18:36:44 like is this some Go-specific internal format or 2024-09-06 18:36:51 I have no idea 2024-09-06 18:37:04 sadly, the github issue for the cve is also not provide any useful information 2024-09-06 18:37:06 https://github.com/golang/go/issues/69139 2024-09-06 18:40:59 I should document my software like that 2024-09-06 18:41:18 package sblorf manages chunks of sblorfs 2024-09-06 18:42:24 do that 2024-09-06 18:43:50 looking at debian codesearch, there seem to be some packages which actually import this https://codesearch.debian.net/results/ba70f0c94f82422c/packages.txt 2024-09-06 18:47:33 the encoding/gob doc links to https://go.dev/blog/gob though which sorta explains the format, it seems to just be a convenient way to serialize a struct and then deserialize it without worrying about the format details 2024-09-06 18:49:16 that link is hidden all the way at the end of the summary which is .. yeah, not great documentation if you ask anyone 2024-09-06 18:53:45 nmeum: we could just rebuild those packages then 2024-09-06 19:29:37 ptrc: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20828#note_2263248 poked around while eating lunch and saw that. 2024-09-06 19:33:42 ptrc: nmeum gob is a go specific serializer 2024-09-06 19:34:31 that would explain why it manages streams of gobs 2024-09-06 19:35:05 (but so does a mop on the bar floor after a busy Saturday night) 2024-09-06 19:46:02 well, now we know what you'll be doing tomorrow night. 2024-09-07 01:24:45 LTO only failed recently though. Maybe worth a bisect still though much less necessary. 2024-09-07 14:06:54 The aports-qa-bot suggested I come here regarding MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68799#note_434558 2024-09-07 14:07:30 This MR is tied to a different MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/68837 , where the MATE package maintainer has given the green light to merge these two MRs into 3.20-stable. 2024-09-07 17:18:05 Hi, I want the linux-virt kernel for alpine, where can I get it 2024-09-07 17:18:25 I wish to implement a new system call and for that I need the kernel files to update the kernel 2024-09-07 17:19:30 mombasa: It's not a special kernel, it's the LTS kernel with a specific configuration 2024-09-07 17:20:04 I was checking the kernel on kernel.org, but they were huge files, unline the alpine linux iso 2024-09-07 17:21:02 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-lts/virt.x86_64.config 2024-09-07 17:22:11 yeah I had seen that, but that's only a config file right? 2024-09-07 17:23:56 Yes. The kernel itself is packaged in an apk file 2024-09-07 17:28:29 where can I find that apk file? 2024-09-07 17:29:50 https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/linux-virt-6.6.49-r0.apk 2024-09-07 17:29:53 for edge on x86_64 2024-09-07 17:30:48 Thanks so much, so now If I had to add my own ssytem call, how would I make those changes to the kernel? 2024-09-07 17:31:33 if you want to add a whole syscall surely you know how to do kernel development already? it's not something you should just do randomly 2024-09-07 17:32:52 yeah I could do it on ubuntu 2024-09-07 17:33:02 using this guide : https://medium.com/anubhav-shrimal/adding-a-hello-world-system-call-to-linux-kernel-dad32875872 2024-09-07 18:17:06 I know I have to build the apk file after I make the changes and then install it, but how am I going to make the changes? : https://wiki.alpinelinux.org/wiki/Custom_Kernel only briskly explains it 2024-09-07 21:10:35 mombasa: see the section "Building packages" here: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#Building_packages 2024-09-07 23:58:13 is there a way to not have a source unpacked in default_unpack? 2024-09-07 23:58:35 i have trouble unpacking the llvm-project archive in an APK 2024-09-08 00:22:40 you can define you own unpack, not call default_unpack. i've done it before with stuff i was playing around with. not sure how recommended it is, but can be done. 2024-09-08 00:36:46 yeah, iterating over $source will do 2024-09-08 01:14:32 Hey there! I wanted to let you know that I have a Telegram channel where I share some amazing Verified sauce and soft cashout
Here are some of the things you can find on my channel:
• Apple Pay
• Bank logs/ bank drops
• Chime transfer
• Cashapp
• Clone card
• Credit Cards( Cvv )
• CC sites
• PayPal transfer
• Wellsfargo sauce
I promise you that all the methods are real and legit. No scams 2024-09-08 01:14:32 here! And please don't worry about how much money you have. Just be honest and I'll try my best to help you out.
So, if you're interested, please join my channel through the link below. See you there ✅✅
https://t.me/+dqk4cMEewjAwZTdk
https://t.me/+dqk4cMEewjAwZTdk
https://t.me/+dqk4cMEewjAwZTdk
🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇🥇
💸💸💸💸 2024-09-08 01:36:12 geez, what a maroon 2024-09-08 01:38:56 can spammers from matrix be kicked and banned? 2024-09-08 02:13:11 share some amazing Ban sauce 2024-09-08 02:21:41 gah still getting `Cannot utime: No such file or directory` with tar and xz as deps and unpacking myself 2024-09-08 02:48:09 bl4ckb0ne: sounds like permissions or readonly filesystem type issue 2024-09-08 03:05:27 rootbld works 2024-09-08 03:05:51 other tarballs in the source too 2024-09-08 11:51:12 I update my MR !70186 because I emailed the original maintainer over three weeks ago but haven't received a reply 2024-09-08 12:01:02 qaqland: merged it 2024-09-08 12:02:24 thx :) 2024-09-08 14:26:16 abuild index started to give me "package file format error" for newly built packages 2024-09-08 15:47:31 Ermine: trying to track down the origin of the message leads me to apk-tools/src/io_archive.c, lines 61 and 154, which both lead to apk_tar_parse(). If the error is originating from line 154, then the apk has wrong tar magic, but the others could be any of apk_file_info struct's members. 2024-09-08 15:48:41 size, uid, gid, mode, mtime, name, uname, gname, device, xattrs 2024-09-08 15:52:14 tar is well-formed, so it can't be magic issue 2024-09-08 15:55:55 Ermine: What packages did you build? 2024-09-08 15:57:16 ikke: libxkbcommon. I'm trying to make it build library interface docs and split all docs into two packages: one for library documentation, and one for xkbcli documentation 2024-09-08 15:58:52 my patch looks like this: https://tpaste.us/7Mrj 2024-09-08 15:59:18 In Adélie the similar split works: https://cgit.adelielinux.org/packages/plain/user/libxkbcommon/APKBUILD?h=wayland/improvements 2024-09-08 16:04:05 It probably means one of the package fields does not match what apk expects, like j_v mentioned 2024-09-08 16:04:14 ok, with that patch, i get https://tpaste.us/1Xbz 2024-09-08 16:04:34 yes, this is what I get as well 2024-09-08 16:04:36 $pkgname=$pkgver-$pkgrel is wrong 2024-09-08 16:04:43 -r$pkgrel 2024-09-08 16:05:05 abuild doesn't validate it for ya 2024-09-08 16:06:17 ah, missed this one 2024-09-08 16:06:24 thank you all! 2024-09-08 16:07:05 geez, i looked right at it like deer in headlights, derp 2024-09-08 16:09:04 (now gotta figure out why it makes .so.0.0.0 libraries) 2024-09-08 16:09:29 because that's the version they set 2024-09-08 16:09:32 seems correct 2024-09-08 16:10:14 So it's something upstream 2024-09-08 16:10:28 yes, and it's not wrong 2024-09-08 16:12:10 is it just me that the 'package file format error' seem to not match the actual issue? 2024-09-08 16:12:26 they made it say .0.7.0 upstream but the part after the soname is not really relevant 2024-09-08 16:12:27 in https://github.com/xkbcommon/libxkbcommon/commit/ce32decc1a8ff9b070b5cd3ebbed4ab29f1a7e09 2024-09-08 16:13:38 j_v: it's the error message given when there's an invalid field so what else would the issue be 2024-09-08 16:14:38 well, that error message is about properly formatted archive, or so i thought... i'm probably not looking at it right 2024-09-08 16:15:03 would be cool if it could provide more detailed error message 2024-09-08 16:15:47 it does in v3 2024-09-08 16:16:21 oh, well, could apples and oranges then 2024-09-08 16:16:28 https://img.ayaya.dev/sQV43ZXQlWbU 2024-09-08 16:17:04 nice then 2024-09-08 16:17:53 yes, that message makes sense per the actual issue, no sense worrying about v2 issues of this nature maybe 2024-09-08 16:19:47 still gonna be a while before v3 gets to edge? the todo list, last i looked, seemed to say it's still wip 2024-09-08 16:20:56 i'm not pushing, just curious 2024-09-08 16:21:09 technically v3 is mostly drop-in and supports v2 packages, but there's a bunch of other stuff to fix that i forgot 2024-09-08 16:21:31 the fancy error is for new mkpkg v3 apks 2024-09-08 16:21:55 up until like a few days ago mkpkg/mkndx didn't even have help output 2024-09-08 16:22:17 the v3 format itself is mostly stable and has worked for a while 2024-09-08 16:22:33 still, what i saw looked like some real nice features adds 2024-09-08 16:23:13 are there 2024-09-08 16:23:20 it's mostly the same with some quirk changes 2024-09-08 16:23:20 well 2024-09-08 16:23:26 i guess v3 format supports zstd 2024-09-08 16:25:26 my impression was from 2/3 weeks ago or more and i didn't really delve very deep. and my memory is a bit spotty. 2024-09-08 16:25:49 i've dealt with v3 only in chimera for forever so i actually don't remember the differences offhand at all 2024-09-08 16:25:54 feels like the same apk user-side 2024-09-08 16:28:05 mkndx = make index? 2024-09-08 16:28:08 all the random small changes i can think of are basically 'shoulda worked in v2, but it was bugged lol then it got fixed' 2024-09-08 16:28:18 Ermine: yeah, what outputs apkindex.tar.gz 2024-09-08 16:28:26 which is not an actual .tar.gz anymore but the name is kept (?) 2024-09-08 16:28:35 some internal stuff is also not ported to adb still yet i think 2024-09-08 16:28:51 *sigh* 2024-09-08 16:28:55 :) 2024-09-08 16:29:04 it's simultaneously 90% done and also feels like it's not 2024-09-08 16:30:08 i was looking at the code for the adb. seems like an original format, but i kept loosing my place, didn't setup anything like ctags or suchlike 2024-09-08 16:30:53 so was hard for me to follow. i should go back and look with ctags/cflow setup 2024-09-08 16:38:45 its a custom format yes 2024-09-08 16:38:57 means you need `apk extract` to extract it instead of it being generic tar 2024-09-08 16:39:17 something i wish i had the knowledge and time to do is to add libarchive support for it so bsdtar could extract it too 2024-09-08 16:39:47 (but only because debuginfod uses libarchive and so then it would be possible to have a debuginfod deployment on an apk v3 repo without any extra effort) 2024-09-08 16:46:36 loosing the tar format is a little disappointing for me, simply because it has been a nice way to look at what was actually inside a package file. not the end of the world and not a game changer, tbh 2024-09-08 16:49:11 i never really found that useful personally because info -L always worked on installed apks (though not for non-installed) 2024-09-08 16:49:38 on v3 there's adbdump for the .apk files (which is overly verbose and also annoying to parse) and probably some list-files thing would be added eventually 2024-09-08 16:49:46 for everything else it seemed like more of a party trick 2024-09-08 16:50:06 like manually extracting an apk to actually install it without apk is uh, bad 2024-09-08 16:50:32 so the only benefit is grabbing a file out of it or something without having apk but with having tar 2024-09-08 16:50:43 not the most useful thing ever 2024-09-08 16:50:59 oh, yeah, manual extract to install, no to that here, just to inspect the contents without installing 2024-09-08 16:53:21 to look at things like rpath of a lib/bin, etc 2024-09-08 16:55:19 info -L would be useful for non-installed apks. I use that 2024-09-08 16:56:04 (so I'm using tar -tvf) 2024-09-08 16:58:21 i see that there is an extract applet in v3, just looking to see if it's enabled 2024-09-08 17:34:36 in v3 apk extract works nicely 2024-09-08 19:12:38 is there a way to apply a patch to a source different than the main? 2024-09-08 19:13:26 or just skip default_prepare, apply them myself 2024-09-08 19:23:05 figured it out 2024-09-08 19:35:12 The convention is to have the source file with an extension other than .patch (.nopatch or something) and then apply it manually 2024-09-08 19:39:46 i skipped default_apply since its the only patch 2024-09-08 19:40:11 should i keep default_prepare? 2024-09-08 19:40:11 That might introduce regression later 2024-09-08 19:41:01 Maybe just put a comment there or in the commit message as to why 2024-09-08 19:41:28 bl4ckb0ne: that makes it anoying if you have to add patches for the main source later 2024-09-08 19:44:27 ack 2024-09-08 20:33:17 alright, 1000 something files built before missing an include 2024-09-08 20:33:22 progress! 2024-09-09 08:26:02 Could somebody have a look at aports!71412 2024-09-09 08:26:11 and aports!71422 2024-09-09 08:26:26 Or suggest who should I ping to move them forward? 2024-09-09 08:26:39 I'm here the whole day today to fix anything I might possibly break :) 2024-09-09 10:52:08 doh, _that_'s why i was unable to login after updating just now :) elogind package not yet updated and thus my pam_elogind.so is in the wrong place 2024-09-09 10:54:52 the repositories uploading one at a time instead of all at once still a classic issue in 2024 2024-09-09 10:55:08 actually it's a constraint issue it seems, not an upload one 2024-09-09 10:55:51 you can theoretically fix it with manual constraints that would block an upgrade until they all upload.. or you can uh just upload main+community+testing and fix every one of these issues that happen all the time without any manual dependency constraint workarounds 2024-09-09 10:58:01 https://termbin.com/r5bn i'm not well versed in apk constraints but this looks like an inability to just upgrade the package 2024-09-09 10:58:37 this happens for instance every time there is a library soname transition on some library in main/ (like boost) and main upload first, then it starts building the rest of the owl in community/ and for roughly 12 hours until it's done building you cannot install any packages from community/ on edge that depend on boosts because main/ has already uploaded and the old boost is gone from the re 2024-09-09 10:59:00 aah I see what you mean now 2024-09-09 10:59:16 so in this case libpam was updated with a new pam libdir.. and so you upgrade to a new libpam from main 2024-09-09 10:59:23 but things havent rebuilt yet in community/testing and didnt upgrade 2024-09-09 10:59:25 etc 2024-09-09 10:59:54 you can spec out dependencies manually like 'everything that depends on it now depends on >=newversionoflibpam' but that is a lot of manual work that can be solved by not doing separate uploads 2024-09-09 11:00:11 seems there might be cirular dep... i'm able to remove elogind (and all of its dependencies) but unable to install the new version :) 2024-09-09 11:00:30 that sounds like an unrelated issue 2024-09-09 11:00:35 shrug 2024-09-09 11:00:55 sounds like i am downgrading linux-pam and trying again tomorrow 2024-09-09 11:00:56 like perhaps the mirror you are using hasn't updated yet 2024-09-09 11:01:08 the repos have all uploaded by now so dl-cdn would have everything updated 2024-09-09 11:01:47 mirror lag per upload just exacerbates the above but would also be fixed without individual uploads, etc 2024-09-09 11:01:59 thanks for the explanations psykose :) 2024-09-09 11:07:42 lotheac: I guess that might have been very unlucky timing. I just updated, and /lib/security is empty, while /usr/lib/security has elogind things 2024-09-09 11:07:45 Sorry for that :( 2024-09-09 11:08:14 don't worry about it. i'll bug you tomorrow if it turns out to not to have been timing ;) 2024-09-09 11:09:33 :) 2024-09-09 11:09:37 yeah, it was just real bad timing, 'apk update' followd by upgrade helped 2024-09-09 11:10:03 caching gets me every time ;) 2024-09-09 11:11:13 Good to know! 2024-09-09 14:12:59 bl4ckb0ne regard qbittorrent-nox, Im doing a clear setup here and I notice I can not see the default admin password because it prints to stdout but not added to qbit logs... do you think would be helpful to have a post-install message saying something like to run "doas -u ... before " or have the "output_log" on the conf.d? 2024-09-09 14:16:13 i just got the mail, ill have a look after my meeting 2024-09-09 14:39:19 so its basically the user not reading the doc right? 2024-09-09 14:39:40 ah 4.6 creates a random pass, it's not adminadmin anymore 2024-09-09 14:40:20 yes, and it prints to stdout not added to the qbit log file 2024-09-09 14:40:29 since running the rc doesnt have log you just dont see it xD 2024-09-09 14:40:30 hm thats annoying 2024-09-09 14:40:31 yeah, if you don't log it somewhere you i think have to look at the obtuse config file to find it 2024-09-09 14:41:11 if you run on tty you can see it, but tha would mess with permissions since rc runs in another user, so `doas -u` can work for it 2024-09-09 14:41:31 or add output_log to the conf.d rc file to save the stdout on disk 2024-09-09 14:41:33 does it even print it every time 2024-09-09 14:41:40 i thought it was like first start only lol 2024-09-09 14:42:02 just print until you change it and it keeps changing every session xD 2024-09-09 14:49:32 i guess a message post-install to say "hey launch the webui by hand first go get your generated password with this command" could do 2024-09-09 14:58:20 yes, and change the password, if dont change next running will be a different one again LOL 2024-09-10 02:29:19 pipeline lint and build-x86_64 stuck 2024-09-10 02:30:50 build.a.o shows idle 2024-09-10 03:31:32 Argentum is looking for experienced IRC operators to moderate our #politics channel on Snoonet. please /join #help on irc.snoonet.org for further details. 2024-09-10 03:39:21 Argentum is looking for experienced IRC operators to moderate our #politics channel on Snoonet. please /join #help on irc.snoonet.org for further details. 2024-09-10 05:32:42 ncopa, hi, what about !70554 - i'm thinking about something like debian/ubuntu has for python. (libpython3.N-minimal,....) 2024-09-10 06:03:01 hi indy, I havent looked closer to it yet. It is a scary change that will affect many users 2024-09-10 06:10:37 Yes, Indeed 2024-09-10 06:12:48 indy: 1) the CI is still red, 2) there is a merge conflict 2024-09-10 06:13:04 those are probably the reasons why I havent looked closer to it yet 2024-09-10 06:13:16 ncopa, i'll rebase it 2024-09-10 06:13:49 i also wonder who will deal with the users complaning of their broken pipelines 2024-09-10 06:15:09 what exactly is the motivation for this change? the referenced issue has no context 2024-09-10 06:17:05 the MR says "bundled setuptools and pip are sources of security issues for python3." 2024-09-10 06:17:26 exactly 2024-09-10 06:17:41 would be good to have the motivation in the commit message 2024-09-10 06:17:53 ok 2024-09-10 06:18:19 and we will need to have good reasons to break peoples pipelines and create frustration 2024-09-10 06:19:04 so it would be nice with some thing to back up the claim "bundled setuptools and pip are sources of security issues for python3." 2024-09-10 06:20:33 statistics, references, research papers whatever. something we can point the users who will claim that there are no security issues in bundled setuptools and pip 2024-09-10 06:21:45 we already build python with " --without-ensurepip" ? 2024-09-10 06:22:07 ncopa, actually i'm thinking to implement something like deb based distros have (python3, python3-minimal, python3-venv, libpython3-minimal, libpython3-stdlib) 2024-09-10 06:22:18 Does venv works well without setuptools? 2024-09-10 06:22:38 no, i dont think it does 2024-09-10 06:23:07 so python3 will be in fact virtual package having in dependencies all subpackages 2024-09-10 06:23:08 indy: would be great if we could make it backwards compatible 2024-09-10 06:23:14 that sounds good 2024-09-10 06:24:08 the naming conventions in alpine are usually closer to what fedora does than to what debian does 2024-09-10 06:25:27 so it would probably be something like python3-libs, python3-stdlib 2024-09-10 06:26:34 as fedora package maintainer i'm familiar with guidelines :) 2024-09-10 06:29:03 so python3-minimal, python3-stdlib, python3-venv would be sufficient as python3-minimal in debian is also virual package 2024-09-10 06:29:29 i'll check how fedora has python packaged 2024-09-10 06:29:37 https://src.fedoraproject.org/rpms/python3.13/blob/rawhide/f/python3.13.spec 2024-09-10 06:34:50 mio: this is a pretty impressive piece of work: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16335 2024-09-10 06:35:04 thank you for helping us keeping track of it 2024-09-10 06:45:56 ncopa, commented !70554 2024-09-10 07:01:57 hello, could you give an eye to !68908 please? Two month old now 2024-09-10 09:37:46 Still not sure why breaking up the python package is needed 2024-09-10 09:39:26 so someone can save 1kb of disk and appease a dumb security scanner at expense of every actual user of the package 2024-09-10 13:27:31 ncopa: you're welcome! 2024-09-10 14:40:42 I want to package whisper.cpp (https://github.com/ggerganov/whisper.cpp), but it seems to be library first, so I have two question 2024-09-10 14:41:15 If the built binary is simply called `main`, is it fine for me to rename it to `whisper.cpp`? 2024-09-10 14:43:36 It also has 11 models provided with it (9, discounting duplicates). Is it alright to create a separate subpackage for each? 2024-09-10 14:47:44 i think we already have an open MR for whisper? 2024-09-10 14:49:34 Ah, I missed it. But it seems to have gone stale 5 months ago 2024-09-10 21:56:53 We are looking for an experienced IRC operator to moderate our #politics channel on Snoonet. please see argentum in the channel #help on irc.snoonet.org for further details 2024-09-11 08:03:52 not allowed to rebase/push to !71817 2024-09-11 08:13:02 The fork is private 2024-09-11 09:23:36 Can someone check this issue, as this affects multiple approved merges related to docs.alpinelinux.org . https://gitlab.alpinelinux.org/alpine/docs/user-handbook/-/issues/6 2024-09-11 19:25:39 Is there anything that's still blocking !63296 ? 2024-09-11 20:33:39 >>> ERROR: virtualbox-guest-additions-x11*: Found textrels: <...> - what does that mean and what I should do about it? 2024-09-11 20:36:08 it means the binary has text relocations in it usually due to bad assembly 2024-09-11 20:36:33 i think musl can load a static binary with textrels but for a dynamic one it will just segfault as it intentionally doesn't support those 2024-09-11 20:37:00 you can figure out why they're there i guess, if it's static and doesn't crash it's technically ok to permit it 2024-09-11 20:37:05 for guest addons i guess they are static 2024-09-11 20:40:28 Well, I can try to patch it just in case 2024-09-11 23:40:40 omni: try now, I changed a setting in the MR itself 2024-09-11 23:50:49 thanks 2024-09-11 23:56:22 np 2024-09-12 03:06:57 Is there anything that's still blocking !68799 ? Both the separate MRs have been merged under this MR and the other one was closed. 2024-09-12 05:36:02 jahway603[m]: the pipeline is still failing 2024-09-12 05:47:21 `Maintainer: Name and email address of the maintainer of the project (not your package).` am I reading that wrong? 2024-09-12 06:08:38 ptrc, hi, i'm not familiar with install_if= (discussion in !70554) 2024-09-12 06:30:24 iggy: where are you reading that? 2024-09-12 06:30:46 indy: it's like a reverse dependency 2024-09-12 06:32:20 ikke: https://wiki.alpinelinux.org/wiki/APKBUILD_Reference it was added here https://wiki.alpinelinux.org/w/index.php?title=APKBUILD_Reference&diff=prev&oldid=25476 2024-09-12 06:33:28 It's a strange sentence, and it's not a variable anyway 2024-09-12 06:33:28 I stumbled on it because I was trying to figure out if it was valid to have 2 maintainers 2024-09-12 06:35:38 It's not 2024-09-12 06:38:18 I almost asked here first but figured I'd get an answer from you and didn't want to disturb you 2024-09-12 08:04:51 someone with permissions could close issue #16441 now 2024-09-12 08:20:21 need some review here, my MR is 🛏️ !70436 2024-09-12 08:21:05 ah, I notice the linter complains about variables without _ but that isnt mentioned on the guidelines, maybe we can update it 2024-09-12 08:32:03 It seems there is a "bug" regarding "install_if", version constraints here should be stricter. 2024-09-12 08:32:55 apk only checks pkgname-pkgver-pkgrel, it would be better if limit to the same repository 2024-09-12 08:34:32 I draw a diagram !71847 2024-09-12 08:35:45 qaqland: mixing repos like that is not supported anyway 2024-09-12 08:37:52 ikke: i see 2024-09-12 12:00:28 sbrivio: hi! 2024-09-12 12:00:32 hi omni! 2024-09-12 12:01:01 we're trying to figure out passt issues on ppc64le 2024-09-12 12:01:40 first noticed in !71896 where I add some very basic test of the binaries produced 2024-09-12 12:02:21 so, yeah, summary from https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1515365: close_range() seems to be returning ENOSYS, even though that system call is defined on ppc64le since 2021 2024-09-12 12:02:59 musl doesn't have its own version/wrapper, so we have one in passt(1)/pasta(1), which uses the right number also for ppc64le (I guess?): 436 2024-09-12 12:04:57 this, right? https://passt.top/passt/commit/?id=6e9ecf57410bd27cc48785125767f65e0455c76a 2024-09-12 12:05:21 correct 2024-09-12 12:06:18 and: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/syscalls/syscall.tbl#n529 2024-09-12 12:09:09 ikke: could you, or someone else, run `ausyscall close_range` on a ppc64le system and perhaps also produce strace output from passt and pasta? 2024-09-12 12:10:13 ...or alternatively tell me where I can find a ppc64le alpine image I can run with QEMU (TCG) 2024-09-12 12:10:19 close_range 436 2024-09-12 12:11:08 sbrivio: We do not have pre-installed qemu images for ppc64le 2024-09-12 12:11:44 looks like syscall filtering on ci that returns enosys for it if i had to guess 2024-09-12 12:11:46 the number looks correct... I wonder if passt/pasta are really getting ENOSYS 2024-09-12 12:12:09 it's docker after all, only weird that it's ppc64le only 2024-09-12 12:12:12 wait, you seccomp your CI? 2024-09-12 12:12:14 oh. 2024-09-12 12:12:39 yeah, the actual builders would pass if i had to guess since it's not wrapped in anything there 2024-09-12 12:13:11 I have an easy way of finding out :D 2024-09-12 12:14:00 seccomp filtering would return EPERM, wouldn't it? 2024-09-12 12:14:06 depends 2024-09-12 12:15:09 Note that we just use the default docker seccomp filters, nothing custom 2024-09-12 12:15:17 based on https://github.com/opencontainers/runc/issues/2151 i think enosys is correct because libc fallbacks are based on it 2024-09-12 12:15:24 in general 2024-09-12 12:15:43 you can return in several ways, for example with SECCOMP_RET_TRACE userspace gets ENOSYS 2024-09-12 12:16:41 the actual kernel definitely has it and it works on hardware (i checked) so it's specific to some filtering, 99% sure :D 2024-09-12 12:18:56 actually i say 'definitely has it' but maybe it's pre 5.9 since the ci output doesn't say which kernel version it is 2024-09-12 12:19:23 if it was pre-5.9, we would not call close_range() 2024-09-12 12:19:27 6.6.21-0-lts 2024-09-12 12:19:46 (https://passt.top/passt/commit/?id=6e9ecf57410bd27cc48785125767f65e0455c76a itself) 2024-09-12 12:20:48 that define would be set regardless of kernel though, it's not a runtime check 2024-09-12 12:20:51 unless i'm misreading it 2024-09-12 12:20:54 anyway, the kernel is 6.6 2024-09-12 12:25:13 https://github.com/moby/moby/commit/54eff4354b17a9c460b851300f28aed1408a8615 this adds close_range() to Docker's default profile 2024-09-12 12:25:54 psykose, right, sorry, it's just a build time check... even though I would assume that a CI builds and runs with the same kernel 2024-09-12 12:26:18 v23.0.0 was the first stable release I see 2024-09-12 12:26:33 We run docker 25.0 2024-09-12 12:28:22 it does build and run with the same kernel, but the defines are from kernel headers which don't come from the running kernel, i don't know of anyone that keeps linux-headers at the same version as the kernel they run since they're backwards compatible 2024-09-12 12:28:57 I usually keep them at the same version, but anyway, that doesn't matter 2024-09-12 12:29:43 so, I could patch passt to do nothing if close_range() returns ENOSYS, but that's a bit of a weakness if one can run it under Docker and skip stuff that's added to improve on the security posture in general 2024-09-12 12:33:49 but why is it only on our ppc64le? 2024-09-12 12:43:36 omni, different versions of Docker? can that be? 2024-09-12 12:49:55 Note that we have something similar with riscv64, where certain syscalls should be allowed, but still return EPERM by docker 2024-09-12 12:52:08 oh, because Docker (libseccomp? moby? not sure) doesn't know about those system calls? 2024-09-12 12:52:34 Well, the issue is that, according the commit log, they _should_ know about them 2024-09-12 12:53:31 I guess there's no easy way to fetch the BPF filter they're applying? 2024-09-12 12:53:35 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16181 2024-09-12 12:53:47 sbrivio: I have been trying to find out, but could not figure out a way 2024-09-12 12:55:00 I merged !71896 and it passed on the ppc64le builder, if anyone was in doubt, https://build.alpinelinux.org/buildlogs/build-edge-ppc64le/community/passt/passt-2024.09.06-r1.log 2024-09-12 12:57:07 I'm mostly concerned about breaking someones setup, since I'm considering upgrading passt on 3.20-stable 2024-09-12 13:12:48 hmm, okay... just let me know eventually if we should handle ENOSYS in passt 2024-09-12 13:28:37 we should also fix "tap.c:1282:24: warning: overflow in conversion from 'long unsigned int' to 'int' changes value from '2147767498' to '-2147199798' [-Woverflow]" I guess 2024-09-12 13:32:26 Ideally we find out why docker is blocking it when it shouldn't 2024-09-12 15:03:56 ncopa: if by any chance you get to look at aports!71694 be aware that I won't be here again until Monday 2024-09-12 15:04:24 So please comment instead of merge if you want me to take care of any possible breakage 2024-09-12 15:04:49 And then I could ping any other maintainer to merge when I can be sitting here monitoring the chat :) 2024-09-12 15:07:40 Or anyhow, let me know how should I do it, since I really wouldn't like that you or others have to spend a lot of time on my fault 2024-09-12 15:07:50 In case anything goes wrong 2024-09-12 15:14:27 Humm, could we rollback unconditionnal fortify until it's fixed? 2024-09-12 15:24:23 so, I could patch passt to do nothing if close_range() returns ENOSYS, but that's a bit of a weakness if one can run it under Docker and skip stuff that's added to improve on the security posture in general 2024-09-12 15:24:43 note that close_range() use is never a security feature and always a programming error 2024-09-12 15:24:52 (that's why musl doesn't have it) 2024-09-12 15:25:36 ah no, I'm mixing it with closefrom() 2024-09-12 15:25:50 close_range() *might* be okay if you own all the fds in the range 2024-09-12 15:26:32 which... if you do, you know all the fds you need to close, and close_range() is unnecessary (just a tiny speed optimization) 2024-09-12 15:31:23 PabloCorreaGomez[m]: ok lets do this on Monday. please ping me then 2024-09-12 15:45:12 ncopa: I noticed we enabled drbd in our kernel, but the in-tree version is an older version (v8), while v9 is available. I have an AKMS package to build v9, but modprobe prefers the already present version. Do you happen to know how to make sure the newer version is installed in the kernel? 2024-09-12 15:55:56 Thanks! 2024-09-12 17:27:11 skarnet, we use it because we do *not* know which files might have been leaked by the parent 2024-09-12 17:31:01 if it's for moby, I suppose that's a legit use 2024-09-12 17:31:03 I'm kind of concerned about the 3.21 roadmap regarding apk 3, and partially the /usr merge. Why would we be changing things, or hesitating on apk 3 for the sake of pmOS? 2024-09-12 17:31:40 and if we're going in lockstep with pmOS would that mean we're also prepping to move to systemd and, or catering to issues with their potential move to that as well? 2024-09-12 17:32:33 We are not hesitating with apkv3 due to anything related with the /usr merge 2024-09-12 17:33:22 I was more talking about considering another distribution in our decision making. 2024-09-12 17:34:16 being nice to downstreams is usually nice 2024-09-12 17:34:59 And work is being done to get the FHS updated, after which it's a matter of Alpine adhering to it 2024-09-12 17:35:56 We have a good relationship with the people from PMOS, they do tons of work for Alpine Linux 2024-09-12 17:37:34 and they have expressed they are probably going in a different direction on some things. 2024-09-12 17:38:33 Yes, they are free to do so 2024-09-12 17:40:33 Is alpine as well? systemd as an example. 2024-09-12 17:40:56 We are not switching to systemd 2024-09-12 17:41:38 But, the question is how long we can remain on openrc 2024-09-12 17:42:09 openrc is being maintained now, which gives a little more time 2024-09-12 17:44:56 And I'm not trying to be combative here. Concerned because I'm pretty invested. 2024-09-12 17:47:10 What's up next? dinit or s6 I guess? 2024-09-12 17:48:34 s6 has been ready to serve as init for years, the service manager is still lacking, but as I understand it the problem is more of an interface one than a functionality one because as is it's pretty much functionally equivalent to openrc 2024-09-12 17:49:05 so rather than trying to solve the problem space once and for all (and hit a difficulty wall) I'll focus on making a nice interface for people who are used to openrc 2024-09-12 17:49:23 so we can have something that actually works before a decade 2024-09-12 17:50:04 That does sound like a good plan 2024-09-12 17:58:30 Aren't some already using s6 with alpine currently? or is that only in addition to openrc rather than instead? 2024-09-12 17:58:38 in addition to. 2024-09-12 17:59:11 openrc is the chosen service manager for Alpine at the moment. s6 is packaged for it, it can serve as a process supervision system; it's not used as a service manager. 2024-09-12 17:59:58 s6 pairs well with openrc if the init scripts are written to take advantage of it (which, for now, very few do, because Alpine has been reluctant to add dependencies to s6) 2024-09-12 18:00:32 I've been very slow at writing the service manager part of s6 because I wanted it to be perfect, but I'm now realizing that perfect is very much the enemy of the good here 2024-09-12 18:37:35 skarnet, originally suggested by Podman developers, but it's for moby too 2024-09-12 18:38:52 yeah it makes sense for container managers 2024-09-12 18:39:04 that's about the only case where it does :P 2024-09-12 18:59:57 xulfer: fwiw i use alpine with s6 and s6-rc 2024-09-12 19:00:30 yeah it's doable but that's not something normies would do ;) 2024-09-12 19:02:17 Yes 2024-09-12 19:02:27 And you're on your own to provide service dirs 2024-09-12 19:11:49 reminds me of 25 years ago, writing daemontools dirs for the things on my freebsd box that mattered to me 2024-09-12 19:54:00 In this case, it's writing dirs for everything in your boot sequence 2024-09-12 23:53:54 hey, if you're nostalgic, I've packaged daemontools-encore 2024-09-12 23:57:57 no need to be nostalgic, s6 brings daemontools to the 21st century! :P 2024-09-13 00:01:11 if only djb would have written an init and a bootloader 2024-09-13 00:02:59 people still wouldn't have adopted it 2024-09-13 00:04:18 because 1. there would have been licensing issues for years, 2. people are incredibly reluctant to good ideas (whereas they binge on bad ideas like candy) 2024-09-13 00:06:20 probably true 2024-09-13 00:10:22 it's all about presentation 2024-09-13 00:10:39 "how I switched to s6 with this one weird trick" returns nothing 2024-09-13 00:23:06 yeah, there are no wikihows on migrating thousands of packages to a new service manager 2024-09-13 00:39:25 there won't be 2024-09-13 00:39:59 what's needed a success story 2024-09-13 02:08:41 think of djb software as reference implementations and you'll be at peace with this state of unaccepted because of public domain 2024-09-13 02:09:21 licensing is pointless and used for profiteering and division which creates artificial scarcity and pressure to compete for the same label and sticker 2024-09-13 02:09:45 all of the licensed produce is uniquely failing 2024-09-13 02:10:44 so they can and do implement what and how they like, at own premsies nobody can tell you what to not use, so businesses STEAL EVERYTHING and kill other businesses and individuals with the profiteeing power and control 2024-09-13 02:11:24 that proves licensing does not work and for criminals, it's the only help as an advantage 2024-09-13 02:12:28 the real problem is adapt and integrate into flavours of BSD, GNU and LieUNIX 2024-09-13 02:13:16 it's the same thing for cipher suites too, so work gets done, just for things they can NOT do on their own well 2024-09-13 02:14:01 these novice programming folk think they can do system ontogenesis and drink their own tears for generations 2024-09-13 02:14:30 that part is left to their own devises 2024-09-13 02:15:56 DNS and MAIL and SVC (supervisor) and NET (server/protocol tools) are enough to get serious work done 2024-09-13 02:16:21 cryptography routines and reference implementation too 2024-09-13 02:16:52 djb software is an enablement pack and is actually used a lot, internally and without much fuss and publicity 2024-09-13 02:18:31 only helpless people are left to the whim and wits of integrators who don't see a use for themselves since they do not work into the serious work getting done department, but in the integrator newpack of the day churning buring fuming rubber department 2024-09-13 02:19:07 churning-burning, sounds familiar? ;-) 2024-09-13 02:19:15 there you go fake browser vendors 2024-09-13 08:48:43 is it fine if my app grabs the web pre-built files instead of build it? The app is go, and it will still be compiled by the source, just grabbing two tarball and skip build web step 2024-09-13 08:57:49 What's the difference between being compiled but not built? 2024-09-13 09:03:22 the need of build the web files with nodejs - it is not working on s390x loongarch64 and riscv64 2024-09-13 09:03:31 although nothing crucial 2024-09-13 09:03:47 web files is in the end noarch 2024-09-13 09:35:25 fabricionaweb: the preference is to build from source, but there are more packages that use pre-built web archives because building proofed too problematic 2024-09-13 09:36:17 if is possible it could also have an carch case to build or not the web, not sure if worth actually 2024-09-13 10:24:46 my 2 cents as somebody not on any alpine team: i'd keep arch differences to things that are unavoidable; not for things that -can- be the same everywhere 2024-09-13 11:02:41 Thanks! I appreciate it 😊 2024-09-13 11:03:05 hi, i'm an alpine package maintainer and the package i maintain has been wrongly flagged out-of-date. How to i unflag it? 2024-09-13 11:10:26 kit_ty_kate: there's no way really, unless someone from the infra team removes it from the database 2024-09-13 11:10:34 but then, the flags also don't really matter that much? 2024-09-13 11:18:44 idk why you even have them 2024-09-13 11:18:57 imo is p pointless 2024-09-13 11:22:51 I kinda rely on the flagging through Anitya/release-monitoring.org, but I have no need for random users flagging stuff as outdated 2024-09-13 11:39:12 ptrc: arf, that's a shame. Thanks! 2024-09-13 11:40:37 the flags don't matter too much but they're still visible publicly on pkgs.alpinelinux.org and when users look for packages it appears red which feels like that package is badly maintained from the point of view of someone without knowledge of what is the latest version 2024-09-13 11:40:50 automated update checking is a much better approach 2024-09-13 12:18:11 It is in the works 2024-09-13 12:18:30 It’s actually already finished but not online yet 2024-09-13 12:19:44 New pkgs wil only have auto flagging via anyita 2024-09-13 12:20:48 And a request to add more matches on releases 2024-09-13 12:21:19 At fedora 2024-09-13 13:08:38 flatpak broke. OSTree:ERROR:src/libostree/ostree-fetcher-curl.c:534:sock_cb: code should not be reached 2024-09-13 13:09:42 yeah, curl 8.10 breaks it 2024-09-13 13:13:45 Wheej 2024-09-13 13:14:43 nobody reported it yet so now's ur chance 2024-09-13 13:14:51 it's either to ostree or to curl 2024-09-13 13:41:44 Curl already announced a patch release date, so any issues should be reported before that date 2024-09-13 14:14:52 flatpak + curl 8.10 work fine for me; I think it's the patch that was merged in 8.10-r1, right? 2024-09-13 14:17:03 that patch doesn't do anything except turn a segfault into an error 2024-09-13 14:17:22 pretty sure 2024-09-13 14:18:52 specifically it's `flatpak update` and anything that uses the network that breaks, not "using flatpak" 2024-09-13 14:19:00 installed apps work fine 2024-09-13 14:19:14 hmm 2024-09-13 14:20:58 you're right though, if i remove that patch it works 2024-09-13 14:22:27 sounds annoying to report 2024-09-13 14:54:39 ive seen a few SIGILL on loongarch CI, shoud those be addressed ? 2024-09-13 14:54:53 https://gitlab.alpinelinux.org/mio/aports/-/jobs/1517464 like here, it's triggered by a rebuild 2024-09-13 15:07:33 bl4ckb0ne: you could make an issue for it, then we could ask the loongarch people to look at it 2024-09-13 15:09:16 sounds good, thanks 2024-09-13 16:35:45 re: borked flatpak... upstream, this bug was filed https://github.com/ostreedev/ostree/issues/3299 2024-09-13 16:46:14 thanks 2024-09-13 16:46:26 invoked: hi, that's me! Feel free to chime in if there's not enough info there 2024-09-13 16:46:58 looks correct 2024-09-13 16:48:15 lgtm 2024-09-13 18:04:38 Couldn't find an issue for it, is it known distcc-pump is borked, at least on 3.20? And the distcc allowlist doesn't include the alpine toolchain either 2024-09-13 20:43:23 re: flatpak/ostree breakage, removing the '--with-curl' build option fixes the issue. Might cause others though. Is there a reason to build with curl? 2024-09-13 21:25:23 what does it use in place of curl if you build it without curl? when exactly does ostree use curl? 2024-09-13 21:25:35 updates 2024-09-13 21:26:00 (those are questions I would probably try to answer if I were trying to figure out what to recommend/do to work around it) 2024-09-13 21:26:05 or "fetch" i should say 2024-09-13 21:33:22 possibly uses "libsoup" for that purpose, it's mentioned next to it in some configure stuff. Still looking; possibly upstream will have an answer for me. 2024-09-13 21:34:23 interesting, default is not using curl: '--with-curl Use libcurl [default=no]' 2024-09-13 21:47:23 so we're building with curl+openssl for minimalism reasons: https://gitlab.alpinelinux.org/alpine/aports/-/commit/47c08525a632885fbd7c57195989c72f3a2628d5 2024-09-13 21:47:31 I'd probably try to use curl over libsoup if possible. libsoup has quite a few deps. 2024-09-13 21:47:48 Yeah makes sense 2024-09-13 21:48:17 but also libsoup was added back last year: https://gitlab.alpinelinux.org/alpine/aports/-/commit/f2c55a6e9069cd4ffad866273640cdc86c778d00 2024-09-13 21:49:18 Wasn't mentioned why, but I imagine removing it would have nontrivial impact. 2024-09-13 22:00:56 but I doubt we need both. 2024-09-13 22:14:21 Well you could always experiment some. 2024-09-14 01:08:40 submitted https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71974 for the flatpak thing; it seems to be a potential temporary fix. Still hoping to work with upstream and actually fix the issue though. 2024-09-16 07:15:49 we need to find a way to reproduce it in the ostree tests 2024-09-16 14:35:26 ncopa: I've had a bad start into the week, but I'm here if you're willing to go through usr-merge related MRs 2024-09-16 14:35:32 Else I'll be here again Wednesday 2024-09-16 14:36:21 aports!71907 and aports!71711 should be good to go 2024-09-16 16:31:55 Requesting a review: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71043 2024-09-16 17:25:06 dhruvin: merged before I could look, but just wanted to say thanks for packaging that, it'll be a nice addition to my alpine droplets :) 2024-09-16 20:04:28 What should I do to gain access to add neovim plugin packaging policy (#16021) to alpine wiki? 2024-09-16 20:07:17 you should just be able to create an account and start editing; but if the spam filter rules give you trouble, say something in #alpine-docs so the admins can deal with it 2024-09-16 20:08:48 Ack 2024-09-16 20:21:55 durrendal Do you use cloud-init? Did you use custom image or wiped an instance with one of the supported images? 2024-09-16 20:25:49 I don't use cloud-init, on my DO droplets at least. I use it pretty heavily at work, but that's AWS and Incus containers, so slightly different. 2024-09-16 20:26:39 I also use a custom image for my droplets. Doing that lets me embed my ssh keys, and then I just use terraform to launch them, ansible to configure them. 2024-09-16 20:33:52 durrendal Moving this conversation to #alpine-cloud 2024-09-16 20:34:11 oh there's an alpine-cloud channel, I didn't know that 2024-09-17 10:56:04 something broken with flatpak/bwrap? I got Vesktop and Steam that fails because of bwrap: Read-only file system 2024-09-17 10:56:15 today's upgrade 2024-09-17 11:06:45 staceee: do you still have a log of packages that have been upgraded? 2024-09-17 11:09:00 na 2024-09-17 11:09:03 nothing changed with bubblewrap and flatpak recently? wtf.. 2024-09-17 11:09:21 I should always log my upgrades 2024-09-17 11:10:23 staceee: It doesn't show what path is considered read-only? 2024-09-17 11:11:39 https://dav.missbanal.net/1db16b96-a439-4170-b0ba-799f7a92699d.png 2024-09-17 11:12:37 seems a lot of path are 2024-09-17 11:12:59 paths in the chroot apparently 2024-09-17 11:14:40 anyway to configure apk to logs somewhere? 2024-09-17 11:15:03 only with apkv3, which is not yet available 2024-09-17 11:16:30 apkv3? 2024-09-17 11:16:37 ACTION is now very curious 2024-09-17 11:16:42 https://discussion.fedoraproject.org/t/flatpak-all-apps-suddenly-broken-cant-mkdir-read-only-file-system/70739 2024-09-17 11:17:31 Old post: https://lists.alpinelinux.org/~alpine/apk-tools/%3C20201006161032.77adf2a2%40vostro.wlan%3E 2024-09-17 11:17:34 ah! I use --user too 2024-09-17 11:19:10 ah I might have broke something with a fucked up command earlier today 2024-09-17 11:19:29 some kind of miss-typed find ./ -type d -empty -delete 2024-09-17 11:21:48 ok fixed. Sorry for the alarm 2024-09-17 11:22:32 no problem 2024-09-17 11:22:42 What was the solution? 2024-09-17 11:23:05 flatpak --user repair --reinstall-all 2024-09-17 11:23:29 ah ok 2024-09-17 19:41:19 how does abuild(?) decide what to put in provides, like cmd: ? (i'll take any short pointer to code or a doc too) 2024-09-17 19:41:51 (the X in my X-Y: openwrt is working on switching to apk and it currently does not put cmd: in provides, and i'm wondering i can fix that) 2024-09-17 19:42:08 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1294 2024-09-17 19:42:22 perfect 2024-09-17 19:42:30 this url will no doubt answer my next two questions too once i have them 2024-09-17 19:42:32 thank you :) 2024-09-17 19:43:22 This is where the .provides-command file is read and converted into cmd: provides: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1576 2024-09-17 19:49:59 ah right 2024-09-17 19:50:18 openwrt currently calls 'apk mkpg' with a ton of --info 2024-09-17 19:51:01 right, that's apkv3, abuild still uses apkv2 2024-09-17 19:51:02 well that's how you create a v3 package 2024-09-17 19:51:28 indeed i have found that APKINDEX was replaced by something unreadable and .apk is no longer tar.something :) 2024-09-17 19:52:00 they are the same format 2024-09-17 19:52:10 the index and the package 2024-09-17 19:52:30 you can inspect them with `apk adbdump ` 2024-09-17 19:52:40 yeah, i noticed ADB in the .apk header 2024-09-17 19:52:41 thanks for that tip 2024-09-17 19:52:50 from what I understand it's something memory mapped 2024-09-17 19:52:52 i already noticed there was no 'adb' tool (which would be a bad name to squat anyway) 2024-09-17 19:53:09 ikke: it does not have to be but it can be 2024-09-17 19:53:25 but yes apk mmaps the data 2024-09-17 19:53:39 otherwise it's just a structured binary thing 2024-09-17 19:54:01 data streams are embedded as compressed chunks rather than the whole thing being compressed 2024-09-17 19:54:06 nice 2024-09-17 19:54:17 i wrote the zstd support in it 2024-09-17 19:54:43 also nice :) 2024-09-17 19:55:01 it made generating large packages like 20x faster :^) 2024-09-17 19:55:11 where i said 'apk mpkg' of course i meant 'apk mkpkg' 2024-09-17 19:55:13 wow 2024-09-17 19:55:15 and smaller? 2024-09-17 19:55:27 mostly smaller 2024-09-17 19:55:46 for the large packages that took long (kernel debug symbols) not much smaller though 2024-09-17 19:56:00 because you don't benefit much from compression on data that is largely random binary shit 2024-09-17 19:56:22 ack 2024-09-17 19:57:57 sigh i should get to testing the latest git changes and see if it completely breaks everything again :/ 2024-09-17 19:58:10 changes in what? or in git itself? 2024-09-17 19:58:17 in apk-tools 2024-09-17 19:58:31 last time we tried bumping apk (a few weeks ago) it irreparably broke indexes 2024-09-17 19:58:36 ouch 2024-09-17 19:58:38 q66: fun-times 2024-09-17 19:58:43 but most of that got fixed by now 2024-09-17 19:58:50 so i need to test everything and see if there are any regressions 2024-09-17 20:00:11 q66: I maintain the alpine go library that implements support to read apk packages / indexes. Do you think it's feasible to implement the apkv3 format in go, or would it be better of to use cgo and link to some library? 2024-09-17 20:00:34 looking at the gitlab urls ikke gave me, i noticed Dimitri John Ledkov as the last committer, and i was sure he worked for Canonical, which is of course possible, but funny 2024-09-17 20:00:39 feasible? probably not 2024-09-17 20:00:55 turns out he switched jobs half a year ago and now works on WolfiOS, which uses apk 2024-09-17 20:01:37 i mean it's possible but probably a pain to maintain 2024-09-17 20:02:30 though if your goal is to just read metadata then it's probably not super hard 2024-09-17 20:04:23 Mostly that, yes 2024-09-17 20:05:11 you'll probably introduce a bunch of the same bugs that were present in the apk implementation of it over time though... 2024-09-17 20:05:21 e.g. one thing i fixed was endianness 2024-09-17 20:05:48 is the apk/adb format defined with some stability? 2024-09-17 20:05:48 apkv3 was terribly broken on BE until sometime in 2022 2024-09-17 20:06:47 Habbie: i've been using it since 2021 and it has not broken and afaik there are no plans to break the format anymore, but it does not have a formal spec 2024-09-17 20:06:54 ack 2024-09-17 20:07:04 it does of course have an installed base that format changes/extensions cannot just break 2024-09-17 20:07:45 in v2, how do i (use apk to) inspect a .apk file i have? like the equivalent of 'apk info -a' 2024-09-17 20:08:03 apk manifest 2024-09-17 20:08:10 but it just shows the files, not the metadata 2024-09-17 20:08:22 you can extract the metadata file it's the first entry in the tar 2024-09-17 20:08:27 q66, oh that i did :) 2024-09-17 20:08:38 ikke, i see, thanks 2024-09-17 20:08:52 back when chimera was using apkv2 (which was for like half a year) i had cbuild manually generate the packages with python tarfile 2024-09-17 20:09:03 it's the second entry in the tar, btw 2024-09-17 20:09:08 the first is .SIGN.RSA... 2024-09-17 20:09:19 oh right, the signature stuff is funky in v2 2024-09-17 20:09:20 but it's clearly named .PKGINFO 2024-09-17 20:10:16 you first generate the data payload (3rd entry onwards), hash it, generate metadata file which has the payload hash, compress it, sign it, and then concat signature-metadata archive-payload archive 2024-09-17 20:10:25 and you get a contiguous tar that is signed but only the metadata is signed 2024-09-17 20:10:39 and the payload archive is trusted by being hashed in the signed metadata 2024-09-17 20:11:02 or something like that... i haven't worked with v2 in 3 years 2024-09-17 20:11:27 right, i see datahash in .PKGINFO 2024-09-17 20:12:28 https://gitlab.alpinelinux.org/alpine/go/-/blob/master/repository/apkindex.go?ref_type=heads#L274 2024-09-17 20:13:17 is that the code i'm using when i run abuild, or is that a compatible implementation? 2024-09-17 20:13:24 The latter 2024-09-17 20:13:27 abuild uses abuild-sign 2024-09-17 20:13:30 ack 2024-09-17 20:13:45 https://github.com/chimera-linux/cports/blob/bfc1e64847b60ad835a355e46fe9a0833bc94cf0/src/cbuild/apk/create.py 2024-09-17 20:13:57 v2 generator 2024-09-17 20:14:06 neat 2024-09-17 20:20:10 it was very slow 2024-09-17 20:22:04 the slowness was actually the main reason why i was so glad to drop it for v3 2024-09-17 20:24:30 there is no way to portably generate v2 packages with a regular tar tool, the metadata quirkiness requires some specific niche things from gnutar 2024-09-17 20:24:58 so doing it with tarfile was the only way except it was slow 2024-09-17 20:26:49 wow, this was an interesting commit b6af1e02efe594039707cd882517663d5370f375 2024-09-17 20:27:04 (2016) 2024-09-17 20:30:41 This is bound to happen again 2024-09-17 20:32:13 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/2 2024-09-17 20:33:43 https://gitlab.alpinelinux.org/alpine/infra/aports-testing-ttl 2024-09-17 20:47:11 sure, I just found it when trying to find when an aport was removed 2024-09-17 20:48:47 bulk (re)moves force me to improve my git-fu 2024-09-17 20:54:08 ikke: are the riscv64 and loongarch64 builders stuck? (sorry if it had something to do with pdsh) 2024-09-17 20:55:29 possibly 2024-09-17 20:56:01 I killed the build 2024-09-17 20:56:46 ikke: thanks 2024-09-17 20:57:34 it seemed to be stuck on awk piping to cat 2024-09-17 20:57:46 or at least, a cat being a child process of awk 2024-09-17 20:58:25 the riscv64 log was for an older commit, the error was fixed in a later one 2024-09-17 20:58:49 and loongarch64 ... not sure why it was stuck, it didn't happen on the other arches 2024-09-17 21:00:58 they were both stuck in the same state (apparently from the proces tree) 2024-09-17 21:04:36 okay, that's helpful to know, thanks 2024-09-17 21:28:14 ikke: would you happen to recall which file was involved in the awk piping? trying to narrow down the problem test 2024-09-17 21:28:33 sorry, did not save that 2024-09-17 21:28:39 C: msg must be a string literal. Since C23, this argument is optional. 2024-09-17 21:28:47 apk: static_assert(sizeof name->state_buf >= sizeof(struct ver_name_state)); 2024-09-17 21:29:03 no msg 2024-09-17 21:30:28 ikke: okay, no worries, thanks 2024-09-17 21:30:39 (is there a separate channel for apk?) 2024-09-17 21:31:36 Habbie: no, there is not 2024-09-17 21:32:09 alright 2024-09-17 22:10:11 Does anyone know how to reach Bart Ribbers (@PureTryOut)? I'm looking for him to approve !71982. He has no contact info on the Alpine Gitlab, but has made commits today, so does anyone have any ideas on how to reach him? Thx. 2024-09-17 22:11:34 you can try here 2024-09-17 22:11:45 idle 3 hours 2024-09-17 22:24:02 jahway603[m]: could you refresh the loongarch64 ci job for the dendrite edge upgrade? can close mine when it comes back green 2024-09-17 22:25:56 going to close my duplicated MR that is 2024-09-17 22:30:21 ikke: hope !72130 will unstuck pdsh 2024-09-17 22:42:01 mio: I'm confused about the dendrite edge upgrade as your pipeline passed the build-riscv64 ci job and mine failed that job yet we literally made the exact same changes to the APKBUILD. 2024-09-17 22:42:57 jahway603[m]: does it still fail? it failed for me in loongarch64 and riscv64 the first time, then was fine on retry. probably a flaky test 2024-09-17 22:58:25 mio: I'm retrying, but it did fail again for both loongarch64 and riscv64. Where are the CI tests located? 2024-09-17 23:14:49 jahway603[m]: https://github.com/matrix-org/dendrite/tree/v0.13.8/test ? but not sure why it's failing 2024-09-17 23:30:44 mio after a couple of retries those tests passed 2024-09-17 23:44:57 mio: both !71981 & !71982 have passed all pipeline tests, but I did have to retry the loongarch64 and riscv64 for them to pass. 2024-09-17 23:46:33 cool, cheers 2024-09-18 06:43:48 "Does anyone know how to reach..." <- > <@jahway603:meowchat.xyz> Does anyone know how to reach Bart Ribbers (@PureTryOut)? I'm looking for him to approve !71982. He has no contact info on the Alpine Gitlab, but has made commits today, so does anyone have any ideas on how to reach him? Thx. 2024-09-18 06:43:48 > 2024-09-18 06:43:48 You reached me here. Also since it's git, you can see my email in the commit author information 2024-09-18 06:44:36 I'll loom at the PR a bit later today 2024-09-18 06:44:46 s/loom/look/ 2024-09-18 06:46:12 PureTryOut: i merged them already 2024-09-18 06:46:29 oh ok 2024-09-18 06:46:56 morning, I have a MR forgotten in time !70436 2024-09-18 10:29:08 Thank you ncopa 2024-09-18 11:07:27 ncopa: I'm here if you feel like going through usr-merge stuff :) 2024-09-18 11:14:18 merged 2024-09-18 11:16:35 Thanks! 2024-09-18 11:16:44 I have the question of what do we want to do with aports!71694 2024-09-18 11:16:54 And mkinitfs!178 2024-09-18 11:17:23 No, https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/178 2024-09-18 11:18:03 If you think those should go early, if we should wait to talk next time, or if we should delay them until we have everything else in place 2024-09-18 16:15:00 terminus font has some patches in its repo to enable things like centered-tilde but they're not enabled on alpine's terminus font. If I wanted those patches available in the font, should I try and build subpackages on terminus, or just submit a new package with the patches enabled? 2024-09-18 16:35:36 elagost: i'd say you can run the idea by the maintainer, if they don't agree then a separate package 2024-09-18 18:25:37 you can spend a lot of time wondering how a newline got into your apk description before you realise adbdump switches syntax when your single line is longer than X chars 2024-09-18 18:29:24 oh, haha, that can trip you up 2024-09-19 08:40:14 Where is abuild-meson defined? 2024-09-19 08:43:10 /usr/bin/abuild-meson 2024-09-19 08:44:04 Not what I meant 😅 I meant what package or repo. But it seems to be just in the meson package 2024-09-19 08:45:06 yeah, it's in aports/main/meson/abuild-meson 2024-09-19 09:07:48 hey, can anyone look this PR? i think it's ready to merge: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/71444 2024-09-19 09:27:45 merged. thanks 2024-09-19 09:29:13 ty! 2024-09-19 17:37:44 hey, i guess !72170 and !72166 are ready to merge! thx :) 2024-09-19 18:50:02 in 10 minutes gitlab will be briefly unavailable to apply security upgrades 2024-09-19 19:22:08 setup-desktop is fragile 2024-09-19 20:55:38 i never got the setup-desktop to work with gnome 2024-09-19 23:51:04 if anyone is for or against openrc having dynamic services (similar to systemd's foo@.service), i'd like to ask for participation in https://github.com/OpenRC/openrc/discussions/749 2024-09-20 06:29:30 We have something like that for wireguard-tools 2024-09-20 06:54:16 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/wireguard-tools/wg-quick.initd 2024-09-20 08:36:01 this maintainer is unreachable can someone help me on the MR !71445 2024-09-20 08:57:40 fabricionaweb: the CI is not finished 2024-09-20 09:23:13 Thank you 2024-09-20 09:57:37 ncopa: weird i just tested setup-desktop with gnome and everything works as expected.. 2024-09-20 10:27:33 Which approach is better, do not include a source and always run the time and ressource intensive repo init and repo sync, or to make a git repo containing all files and link the tar.gz from there? 2024-09-20 10:27:33 This does not fit well into abpkbuild since, there is no tar.gz file. 2024-09-20 10:27:33 In order to fetch the sources, I need to run ` repo init -u https://android.googlesource.com/platform/manifest -b android-$sdkver --depth=1 && repo sync --current-branch -j4` 2024-09-20 10:27:33 Hi I am in the process of porting the android-sdk to aports with the goal of shipping a foss android-sdk. 2024-09-20 10:27:33 Google uses its internal tool called repo, which abstracts the management of many git repos. 2024-09-20 10:30:17 wizzard: how many individual repos are we talking about? 2024-09-20 10:31:18 1367 2024-09-20 10:31:42 oof 2024-09-20 10:32:48 I will try, if there is a undocumented way to reduce this. 2024-09-20 10:32:48 https://android.googlesource.com/platform/sdk/+/refs/tags/android-14.0.0_r74/README.txt 2024-09-20 10:33:26 My first idea, is to figure out which repos are really needed and to use submodules 2024-09-20 10:33:47 Yeah, that would help a lot, make it more managable 2024-09-20 10:33:59 Ok, I will see what I can do. 2024-09-20 10:36:10 My Plan B is to make a fork with a sane amount depencies which is not such a hassle. And use an external machine, to prepare the sources that are required 2024-09-20 11:56:07 \o/ my apk-tools MR was merged 2024-09-20 12:03:27 Yes, noticed it 2024-09-21 12:05:41 llvm19 may be needed for the next rust release 2024-09-21 12:09:16 the minimum is still 17 so how's that work 2024-09-21 12:09:19 i don't see an mr to raise it to 19 2024-09-21 14:00:02 Good day! I wanted to ask if someone with merge permissions has a bit of time to look at !72146 2024-09-21 14:01:06 Made the PR because there was a side change in that update I wanted to tinker with 2024-09-21 14:04:47 Hmm, it's waiting for approval from nibon7' 2024-09-21 14:05:53 psykose: I think it may be needed for riscv64 and loongarch64 2024-09-21 14:07:46 ptrc and celie probably know more about this 2024-09-21 14:14:00 maybe 2024-09-21 15:04:49 ikke: ah, I didn't think about it. The previous couple of versions were merged without their approval, so I presumed it wasn't strictly necessary 2024-09-21 15:40:25 gitlab is having issues at the moment. I'm investigating 2024-09-21 16:01:24 hi, https://alpinelinux.org "git" in the top right corner links to https://gitlab.alpinelinux.org which throws "404 page not found" 2024-09-21 16:01:34 should that point at git.alpinelinux.org ? 2024-09-21 16:02:05 kn: no 2024-09-21 16:02:22 kn: But there are some issues at the moment, I'm looking at it 2024-09-21 16:03:31 gitlab is back 2024-09-21 16:03:56 gitlab. 302 working now, thanks 2024-09-21 17:28:35 Hola 2024-09-21 17:29:11 Not that it's a big deal, but since a few kernel updates, it seems that the file /lib/modules/$kver/modules.weakdep isn't removed on update 2024-09-21 17:29:36 Is that something known? 2024-09-23 07:34:39 ncopa: would it be possible to make an edge snapshot so that we get a loongarch64 minirootfs? That will help switching over CI 2024-09-23 07:35:03 It's still building testing now, but maybe we can interrupt that for a bit 2024-09-23 07:38:21 yes. an edge snapshot would be good 2024-09-23 10:22:01 ncopa: should I temporarily disable testing on loongarch, then the builders should become idle 2024-09-23 10:22:14 altough, rv64 is now building gcc 2024-09-23 10:34:43 lets wait til gcc is done 2024-09-23 10:35:43 nod 2024-09-23 12:05:37 nmeum: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72325#note_438368 should be good to go from my side 2024-09-23 12:05:58 Specially if it causes extra issues, and does not regress on my intended behavior 2024-09-23 12:06:23 Then we can ask the maintainer to fix the pc file so we can remove the packaging 'hack' 2024-09-23 12:06:45 it's not super urgent as it only affects packages which statically link against utmps and skalibs 2024-09-23 12:07:02 the .pc file is also shipped by us downstream so "fixing" it should be easy 2024-09-23 12:07:41 ah, didn't realize that! 2024-09-23 12:07:54 also: the reasoning in your comment in regards to autoconf is correct, however, skalibs/utmps don't use autoconf. it's a custom shell script with autoconf-like longoptions 2024-09-23 12:08:28 Ah, right, I was confused about that when I tried to figure out which things to look for 2024-09-23 12:08:52 However, it might be the case that following autoconf conventions would make sense? 2024-09-23 12:08:59 Like if it uses the same kind of "api" 2024-09-23 12:09:50 you would need to convince skarnet then :) 2024-09-23 12:10:39 Let's see the answer in that thread then :) 2024-09-23 12:38:06 fossdd: maybe https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4279#note_2227114 is something we can do? 2024-09-23 12:38:35 I wouldn't feel uncomfortable piping the output of the call in the trigger to /dev/null 2024-09-23 13:53:00 yeah i think that should be possible 2024-09-23 13:53:05 i could do that tomorrow 2024-09-23 14:26:31 riscv is still building GCC 2024-09-23 17:29:31 riscv is still building GCC 3 hours later 2024-09-23 17:29:41 is it stuck? 2024-09-23 17:30:50 curious to know what this unpatched "GNU/Linux" unauthenticated RCE is about 2024-09-23 17:31:50 first i've heard of such a thing 2024-09-23 17:31:59 do you have any more information? 2024-09-23 17:32:01 https://x.com/evilsocket/status/1838169889330135132 2024-09-23 17:32:50 evilsocket is... well... i would not take what he posts at face value 2024-09-23 17:32:54 also, CVSS is bullshit 2024-09-23 17:33:10 yeah, like i said, just curious 2024-09-23 17:33:38 i think if it were true it would have fallen off a truck and into my inbox already 2024-09-23 17:33:53 i figured, which is why i asked about it when i saw you here 2024-09-23 17:36:22 anyway so far i got nothin 2024-09-23 17:36:32 if something falls off a truck and in my inbox, i'll deal with it then 2024-09-23 17:37:52 cheers. i forgot to put airquotes around "unauthenticated RCE" and the requisite disclaimer that i'm not raising an alarm. that's on me 2024-09-23 18:06:54 invoked: looked into it. there is a bug, but it's not likely to impact the typical alpine user 2024-09-23 18:09:51 roger that, thanks 2024-09-23 18:17:15 oh, did they disclose the details already? 2024-09-23 18:21:30 no 2024-09-23 18:21:41 i just asked some friends 2024-09-23 18:37:45 good afternoon 2024-09-23 18:49:50 bah the release scripts are broken 2024-09-23 18:49:55 awk: /tmp/tmp.fEdcNc/etc/os-release: No such file or directory 2024-09-23 19:00:21 ok I found it 2024-09-23 19:11:53 PabloCorreaGomez[m]: FYI: 57ad77e0bace8dee75a9625e7941f712af5b975b 2024-09-23 19:35:44 I'm tagging edge snapshot now. please hold your pushes for a few mins 2024-09-23 21:13:48 ncopa: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine/-/jobs/1528815#L51 2024-09-23 21:16:17 oh, may have been my own fault 2024-09-23 21:25:08 probably needs qemu-loongarch64 binfmt right? 2024-09-23 21:30:34 no, I accidentally pushed a single arch image to a manifest repo 2024-09-23 21:31:05 So now it only serves a single arch :p 2024-09-23 21:34:13 ah yeah. could probably use something like crane to combine the single-arch image builds into a manifest repo 2024-09-23 23:19:42 could someone take a look at this MR? Simple patch for a kind of annoying bug in waybar. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72039 2024-09-23 23:49:07 craftyguy: ^^ 2024-09-24 10:45:42 cbanta hasn't been involved for many years, right? perhaps their aports should be adopted, or at least made visibly lacking maintainer 2024-09-24 10:45:53 ncopa: thanks for the ping, I had no idea about those scripts until now. Will add them to my bucket list 2024-09-24 15:18:44 Pablo Correa Gomez: hmm just saw that glib outputs the warnings to stderr. not sure if supressing stderr is the best way... 2024-09-24 15:25:42 Mmm, why not? The trigger would still fail, and devs can totally run the compile-schemas manually 2024-09-24 15:25:56 Well, certainly best if it was sent to stdout, but not sure that's something we can fix 2024-09-24 15:37:29 oh true the exit code is still the same 2024-09-24 15:45:14 updated the MR now 2024-09-24 15:45:58 BTW could someone merge !72166? 😄 2024-09-24 15:47:16 fossdd[m]: yes, I post-poned it yesterday because I wanted the builders to be idle for a snapshot 2024-09-24 15:47:46 oh alrighty :) 2024-09-24 15:48:42 thx 2024-09-24 21:07:03 there seem to be some ghostscript{,-fonts} issues - #16376 #1682 #16465 2024-09-24 21:07:24 oups 2024-09-24 21:07:34 wrong issues 2024-09-24 21:09:02 #16376 #16382 2024-09-24 21:10:19 both with Cameron Banta as (inactive) maintainer 2024-09-24 22:52:35 How can I figure out which relocations in a binary are textrels? readelf -a doesn't seem to give any useful info 2024-09-25 05:30:20 Ermine:use scanelf 2024-09-25 05:30:47 https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide 2024-09-25 09:27:16 can there be "pseudopackages" on alpine linux? e.g packages that don't have any build() or package(), they just depend on other packages 2024-09-25 09:28:30 i was thinking of making one to resolve this issue, but i'm not sure the CI/CD will allow a content-less package, so that's why i'm asking: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72253 2024-09-25 09:44:36 rdbo: the minimum that is required is package() { mkdir -p "$pkgdir" } 2024-09-25 10:46:24 "rdbo: the minimum that is..." <- Is there any reason why we have this requirement btw? like if you just want a metapackage, why does abuild require a package function at all? 2024-09-25 10:48:11 implementation detail that it crashes when pkgdir doesn't exist and nothing makes it 2024-09-25 10:48:13 pretty sure 2024-09-25 10:50:02 Yeah, that would be my guess as well 2024-09-25 13:14:36 couldnt abuild just mkdir -p itself? 2024-09-25 14:17:07 khem: thank you! That's a nice guide 2024-09-25 16:47:50 I've got that guy scared, sorry 2024-09-25 16:47:59 heh 2024-09-26 15:35:44 any volunteers to help create a rpi-imager package? https://gitlab.alpinelinux.org/alpine/aports/-/issues/16476 2024-09-26 16:58:28 ncopa: i'm giving it a go 2024-09-26 17:12:59 there is no pkg for adguardhome, I think I will work on it 2024-09-26 17:13:16 planning in have an dedicated small pc to run it 2024-09-26 18:37:01 ncopa: i've got an initial aport for rpi-imager. it builds but needs work. i should be able to have it ready for testing tomorrow or day after that. 2024-09-26 19:28:19 Thanks for the work! 2024-09-26 22:58:24 fabricionaweb: you want a head start for adguardhome? 2024-09-26 23:00:41 thanks, anything helps, but Im doing some scratch here as well 2024-09-26 23:01:00 https://github.com/atlascloud/aports/tree/master/main/adguardhome 2024-09-26 23:07:55 oh nice, that is done just send the MR haha 2024-09-26 23:09:02 you can grab the frontend package from them so dont need to build it 2024-09-26 23:10:30 thank you, I will amend some stuff and I may send MR during weekend or so, would be amazing having your help 2024-09-26 23:14:21 that setcap is exactly what I was looking for, I started doing it as root but meeeh 2024-09-27 00:00:13 fabricionaweb: read the comment right above that... you have to rebuild the frontend because of an openssl issue 2024-09-27 00:01:16 they build the frontend with node14 or something which is incompatible with the openssl in alpine 2024-09-27 00:01:33 there's an issue in their tracker about it that has more detail 2024-09-27 00:10:41 hm but that is not what I meant... for frontend files this shouldnt be a thing 2024-09-27 00:11:16 they dont ship the frontend in the github tags snapshot so you need to build it or grab the "AdGuardHome_frontend.tar.gz" 2024-09-27 00:12:35 that openssl issue was fix recently it seems https://github.com/AdguardTeam/AdGuardHome/commit/1afe226ce8f8af179e1eacccf4cdd63823f0c358 2024-09-27 00:21:56 try it without, but I had to add that to be able to login 2024-09-27 00:24:01 I was getting the exact same issue as here https://github.com/AdguardTeam/AdGuardHome/issues/5559 404 when trying to login 2024-09-27 01:22:33 signal-desktop needs a bump. it's at 7.14 which the server rejects now. current is 7.24 2024-09-27 01:22:45 i'm out of time to open an issue though, sorry 2024-09-27 07:18:35 invoked: I was upgrading it but ended with a missing source from a strange domain 2024-09-27 07:18:42 https://ab-sn.lnl.gay/webrtc-$_webrtcver.tar.zst 2024-09-27 07:18:54 is it a known domain? I found it on few others packages 2024-09-27 07:19:12 https://tpaste.us/yBWl 2024-09-27 07:20:13 well this more accurately https://tpaste.us/YqJz 2024-09-27 07:21:01 # downloading tarball generated with abuild snapshot (with gclient dependencies fetched) 2024-09-27 07:21:02 lnl is a contributor 2024-09-27 07:22:08 And they vendor their own source archives? 2024-09-27 07:22:24 it seems an snapshot from a commit version 2024-09-27 07:22:28 they're not the only ones, sometimes it is necessary 2024-09-27 07:22:50 signal is simila to telegram, has a lot of git subprojects pinned to some commit version 2024-09-27 07:22:57 Is it necessary to do it from their domain, instead of having maybe a bit more controlled from alpine servers? 2024-09-27 07:24:05 unfortunately, access to dev.a.o is not available to contributors but only developers 2024-09-27 07:24:39 if you would like to propose a solution then go propose it to the TSC 2024-09-27 07:24:48 Are you saying that's a problem that needs to be solved? 2024-09-27 07:24:55 yeah 2024-09-27 07:25:30 i think having some way for contributors to upload snapshots would indeed be valuable to the project 2024-09-27 07:25:33 It could be part of the review process, as it is anyway 2024-09-27 07:26:04 Package needs vendoring code, then it's part of the review and the validating developer uploads the archive 2024-09-27 07:26:13 cool 2024-09-27 07:26:21 go propose that to the TSC then 2024-09-27 07:26:28 What's the TSC? 2024-09-27 07:27:09 if you don't know how the project makes decisions then maybe you should stop criticizing random contributors for doing things to make packages work 2024-09-27 07:27:22 Hold yer horses :) 2024-09-27 07:27:37 Don't take this as a personal negative criticism 2024-09-27 07:27:45 I'm pointing something out and proposing some solution 2024-09-27 07:27:59 yeah okay 2024-09-27 07:28:32 You agreed yourself it's a problem 2024-09-27 07:28:54 things can be problematic without applying breaking energy to the efforts of contributors 2024-09-27 07:28:55 I'll look into this TSC and see if I can send an email or something 2024-09-27 07:29:21 Yeah, I think that's the case indeed 2024-09-27 07:30:51 It's a gitlab project you can create an issue on 2024-09-27 07:30:52 (the solution imo is much simpler: make it easier to become a full developer, then they can upload their snapshots to alpine infrastructure directly) 2024-09-27 07:30:52 From the TSC: “We cannot tell other people what to do and what not to do, everyone is volunteering.” 2024-09-27 07:31:09 It looks like I should rather contact the target team, so it can be discussed in the TSC 2024-09-27 07:31:21 the TSC can set technical policy for what is acceptable in an APKBUILD 2024-09-27 07:31:33 in fact, this is one of the primary purposes of the TSC 2024-09-27 07:33:03 either way, there is no increase or decrease in risk from a security POV from a contributor vendoring a source snapshot on their own personal infrastructure or on dev.a.o 2024-09-27 07:33:18 at most, the risk is that the personal infrastructure may disappear in the future 2024-09-27 07:33:45 it is up to whoever approves and merges the APKBUILD to make that decision at present 2024-09-27 07:33:55 Technical Steering Committee 2024-09-27 07:34:04 i guess the full name gives some pointers 2024-09-27 07:34:44 so, i think asking the TSC "hey it would be cool if we had a source vendoring service for contributors to use" would actually be useful 2024-09-27 07:36:37 what i do not think is useful is to nitpick somebody's APKBUILD (which an alpine developer has signed off on) in IRC for using a personal domain for snapshots 2024-09-27 08:08:11 I think that's the exact same thing 2024-09-27 08:08:23 Just that one leads to the other 2024-09-27 08:09:00 And I don't think that being so defensive about IRC channel discussion is very useful either, especially when it's not aggressive 2024-09-27 08:09:32 Anyway, glad it might lead to improvement, back to work here 2024-09-27 08:25:15 if I add the options="setcap" do I still need to have the libcap-utils onto makedepends? 2024-09-27 08:25:34 options=setcap just makes the linter not tell you off and nothing else 2024-09-27 08:25:46 so if you want the cap to be there, probably yes 2024-09-27 08:25:53 thanks 2024-09-27 08:40:56 quinq: my issue is that while it is suboptimal that some alpine contributors feel the need to selfhost source code snapshots in order to make progress in maintaining their packages, it’s ultimately a nonissue. we are trusting that the snapshot has not been tampered with either way. 2024-09-27 08:42:10 a developer could upload a tampered snapshot to dev.a.o with a backdoor. or they could host that tampered snapshot on their own personal domain. it doesn’t matter. the security is determined based on the hash of the content. 2024-09-27 08:43:48 in the case of a non-developer contribution it is on the developer to make that trust decision. 2024-09-27 08:47:47 there are many examples of this in alpine. for example, dotnet packages are built from snapshots hosted by ayakael in new zealand, which are fairly large. from an infra POV it would be good to provide some way for contributors to publish the snapshots on alpine infrastructure so it can benefit from alpine’s infrastructure capabilities, but the package is not more or less trustworthy because of the DNS name 2024-09-27 08:48:38 i will concede that i am somewhat sensitive to criticisms lobbed at marginalized contributors though 2024-09-27 08:49:17 especially when security is the argument around those criticisms and the security model of the distribution does not support them :) 2024-09-27 08:50:14 we should however ask the TSC to prioritize a solution that is more robust than “contributors host their own snapshots” because contributors shouldn’t have to be doing this 2024-09-27 08:52:55 either way, responsibility for any security incident lies with the developer who accepts the MR which pulls in the tampered snapshot. i think if that were to ever happen there would be hard questions asked of that developer. the security team certainly would want to know why/how it happened. 2024-09-27 08:53:48 but… what DNS or server the snapshot comes from, unless we know the snapshot is tampered with, it doesn’t matter to the security team where it’s coming from 2024-09-27 08:56:03 on the other hand, offering an upload service carries high risk of abuse (people misusing it for distributing warez for example) 2024-09-27 09:24:14 as a side note, for some aports we do in fact have a process where the package maintainer ( who isn't a developer ) sends us files to put on dev.a.o that are later used during the build / package 2024-09-27 09:25:02 and the only meaningful difference between putting it on a third-party server, other than the fact that said server can go offline at some point, is that the maintainer can't run CI until we upload the files 2024-09-27 09:25:30 s/between/from/ 2024-09-27 09:26:29 j_v: thank you! seems sertonix did the same: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72585 2024-09-27 09:28:29 But snapshotting should be done as a last resort, not something that should be normalized. 2024-09-27 09:29:14 There should be pushback to upstream to provide usable source releases 2024-09-27 11:16:41 HRio: i rename bats to bats-core in !72618 2024-09-27 11:18:35 there should be no problem 2024-09-27 12:53:01 hey everyone, im new to alpine developer community, i wonder is there any guide to build a alpine linux distro from scratch? im currently interested in alpine on riscv, but i only find link here https://www.alpinelinux.org/downloads/ and only find the minimal rootfs for riscv. 2024-09-27 12:53:04 qaqland: will have a look, thanks 2024-09-27 12:54:31 pericycle: riscv booting depends very much on the board you are targeting. We currently don't have any general purpose flashable image 2024-09-27 12:54:43 so you are pretty much on your own 2024-09-27 12:55:17 we do have unofficial images for starfive2, and bananapi bpi-f3 2024-09-27 12:55:43 mps, how is active in #alpine-riscv64 has images as well 2024-09-27 12:55:52 im currently consider build for licheepi 3a which based on the same chip as bananapi-f3 2024-09-27 12:56:02 ok 2024-09-27 12:56:14 I have this one here https://dev.alpinelinux.org/~ncopa/riscv/ 2024-09-27 12:56:41 great 2024-09-27 12:58:37 it is based on the spacemit kernel https://git.alpinelinux.org/aports/tree/testing/linux-spacemit 2024-09-27 13:00:08 the licheepi 3a is also run on spacemit chip, maybe i can try to burn the image tomorrow:) 2024-09-27 13:00:38 ping me in #alpine-riscv64 I am curious how things goes 2024-09-27 13:01:54 ok 2024-09-27 13:28:59 ncopa: looks like sertonix solved what i was struggling with, getting rpi-imager to build without the bundled stuff. very cool. 2024-09-27 13:29:28 he did. very nice indeed 2024-09-27 13:29:48 it works as a charm, and I have been using it today 2024-09-27 13:31:14 i will give a run on my 2b, probably later today 2024-09-27 13:31:27 cool! 2024-09-27 13:31:38 i tested rpi5 and rpi1 2024-09-27 13:32:14 I think rpi-imager was slightly confusing when selecting where to write to 2024-09-27 13:34:22 i will let you know how it goes. i was planning to reinstall anyways, it's got 3.16 on it and i need to dust the cobwebs off 2024-09-27 16:22:19 ptrc: yeah that’s one of the main reasons why contributors self-host the files 2024-09-27 17:13:26 why would ifupdown-ng refuse to set the static address i configured? 2024-09-27 17:13:36 it just does nothing when upping the interface 2024-09-27 17:14:36 dalias: ifup -f ? 2024-09-27 17:17:19 it comes up but no addr gets set 2024-09-27 17:17:29 auto eth1 2024-09-27 17:17:29 addresss 192.168.42.66/24 2024-09-27 17:17:29 iface eth1 2024-09-27 17:18:24 that addresss has an extra s 2024-09-27 17:18:29 doesn't it 2024-09-27 17:18:39 lol 2024-09-27 17:18:57 thanks 2024-09-27 17:19:03 i can't read 2024-09-27 17:19:14 can 2024-09-27 17:19:18 typos are just hard to spot 2024-09-27 17:37:15 are the pipelines 🛏️ 2024-09-27 17:37:34 fabricionaweb: example? 2024-09-27 17:37:53 https://gitlab.alpinelinux.org/fabricionaweb/aports/-/pipelines/261502 2024-09-27 17:38:08 registry.gitlab.org on 8.8.8.8:53: no such host 2024-09-27 17:39:08 Shoudl be fixed, if you rebase your branch 2024-09-27 17:39:51 ugh that was quickly I made the branch not even 3min ago ahhaha 2024-09-27 17:40:16 thanks 2024-09-27 17:40:21 Made a booboo 2024-09-27 17:40:34 no one noticed, move on 2024-09-27 17:41:27 gitlab.alpinelinux.org + registry.alpinelinux.org -> registry.gitlab.org :D 2024-09-27 17:44:55 for a moment i thought a legit gitlab thing was down 2024-09-27 17:45:07 fixing loongarch 2024-09-27 17:49:51 dalias: in future, ifquery and ifup -v may help 2024-09-27 17:52:28 Ok, loongarch64 now works as well 2024-09-27 17:52:38 Ariadne: That means CI now officially switched over to the official builder 2024-09-27 17:52:46 excellent 2024-09-27 17:53:03 lets get rid of the tmp one :D 2024-09-27 17:57:23 i tried -v but it didn't say anything about addresss being wrong :-p 2024-09-27 22:05:45 Any thoughts what to do when riscv64 build times out? 2024-09-27 22:05:54 asking for !72641 2024-09-27 22:06:51 You can change the timeout in your project settings 2024-09-27 22:06:54 of your fork 2024-09-28 10:42:05 fossdd: I was stuck with gitlab.com max of 3h 2024-09-28 10:42:18 Just updated it 2024-09-28 10:42:30 Let's see if it passes in 6 hours... 2024-09-28 10:42:56 i wish you luck 🙏 2024-09-28 10:43:49 Also, thanks! 2024-09-28 11:38:16 Does anyone know what this means? ERROR: electrum-gui-4.5.5-r1.apk: package file format error 2024-09-28 11:39:24 i'm trying to separate the gui() from the main electrum package due to requests by other users, and i have this as the gui() subpackage: https://pastebin.com/UPxFePpM 2024-09-28 11:39:45 rdbo: usually that there is something wrong with the package metadata that apk does not accept 2024-09-28 11:40:12 install_if="$pkgname=$pkgname-r$pkgrel" 2024-09-28 11:40:16 should be 2024-09-28 11:40:19 install_if="$pkgname=$pkgver-r$pkgrel" 2024-09-28 11:41:34 oh, i missed that, thanks! now it worked 2024-09-29 12:42:16 Is there some easy command to use to find the package owning a certain file on disk? 2024-09-29 12:43:02 apk info --who-owns 2024-09-29 12:43:26 Ah cool thanks 2024-09-29 14:34:12 Would anybody be able to have a look at !72704? Seems trivial and is blocking further work for me 2024-09-29 15:07:18 what happened to java on edge? i can't upgrade my system, because it wants to pick java8 coretto, which is conflicting with.. my currently installed java 8 2024-09-29 15:08:34 ptrc: what is the exact error message you get? 2024-09-29 15:08:43 ERROR: unable to select packages: 2024-09-29 15:08:43 openjdk8-corretto-jre-lib-8.422.05.1-r0: 2024-09-29 15:08:43 breaks: openjdk8-jre-base-8.422.05-r0[openjdk8-jre-lib=8.422.05-r0] 2024-09-29 15:11:00 it's happening on just `apk upgrade -ai`, and i can't figure out which package would want *specifically* java8 corretto, and not be satisfied by openjdk8-jre 2024-09-29 15:15:52 huh, nevermind, just doing `apk upgrade -i`, then `apk upgrade -ai` solved my issue 2024-09-29 15:15:54 weeeeird 2024-09-29 15:16:19 in my orphaned packages there's only mesa makedepends and fluffychat, nothing java 8 related 2024-09-29 15:17:05 curious 2024-09-29 15:33:08 ncopa: could you take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72741? Simple change 2024-09-29 15:42:15 I'm thinking of dropping pastebinc. Has not been updated in ages, last aports commit is 2 years ago 2024-09-29 15:42:21 does not build with gcc14 2024-09-29 16:04:15 it's in testing as well, seems like a no-brainer to me 2024-09-29 16:05:57 !72745 2024-09-29 16:16:27 ikke: didn't you at some point mention that you wanted to actively start dropping packages that were in testing for a while without being moved to community? 2024-09-29 16:17:05 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/2 2024-09-29 16:17:27 Ah thanks, will read 2024-09-29 16:19:57 Ah, nothing really happened with the proposal then, although most people seemed to be in favour of it 2024-09-29 16:20:12 https://gitlab.alpinelinux.org/alpine/infra/aports-testing-ttl 2024-09-29 16:30:41 Cool, now let's use it 😄 2024-09-29 16:30:47 ACTION moves some of his own stuff to community 2024-09-29 16:42:23 good idea 2024-09-29 16:42:29 ACTION is guilty as well 2024-09-29 16:52:37 Ugh 2024-09-29 17:05:42 > tmw I set pkgrel to 10 rather than 0 when updating pkgver... https://git.alpinelinux.org/aports/commit/testing/calligra?id=14728804c78cad7d30341171a3cfed6d5c25abd0 2024-09-29 17:11:11 lol 2024-09-29 19:11:29 posting this here (again?) for visibility #16335 2024-09-29 19:12:24 if your package is on the list and not checked yet, probably means it is still ftbfs, if you pushed a fix please feel free to check off as done 2024-09-29 19:14:02 have already started reaching out to maintainers to arrange a course of action, but the loongarch64 builder is blocked on ~60 testing/ aports of which the gcc 14 ones form a fraction 2024-09-29 19:16:23 today will look into broken aports without maintainers, to hopefully give people time to check and upgrade/action on their aports 2024-09-29 19:20:15 thanks everyone 2024-09-29 20:44:44 So are we going so far as to do away with /bin/sh as abuild:308 seems to indicate? If so that seems like a gift that will keep on giving heh 2024-09-29 20:46:10 /bin/sh will still exist as a symlink 2024-09-29 20:47:35 Ah okay. Seemed like the intention was to have abuild have a problem with writing anything to /bin 2024-09-29 20:47:57 well, yes, the symlink is /bin -> /usr/bin 2024-09-29 20:48:05 so packages itself would not contain /bin anymore 2024-09-29 20:49:06 Ah ha. Well now I just feel silly. Now I'm caught up. :) 2024-09-29 20:50:53 is there a rationale why the link would be this way instead of the other way /usr/bin -> /bin ? 2024-09-29 20:51:48 The idea is that /usr can be a separate RO mount 2024-09-29 20:52:04 ............ 2024-09-29 20:52:23 yeah. That was the idea behind having /bin and /usr/bin *separate* in the first place. 2024-09-29 20:52:33 usrmerge goes *against* the idea. 2024-09-29 20:53:15 I saw some stuff that wanted to merge sbin too which I kind of think is silly. Just makes management more tedious. 2024-09-29 20:54:00 making /usr the canonical path is better because it allows properly and simply separating mutable and immutable stuff 2024-09-29 20:54:09 ^ 2024-09-29 20:54:14 there is like no way in which doing the other way around would be anyhow beneficial 2024-09-29 20:54:25 oh so you mean / should be mutable? 2024-09-29 20:54:29 yes 2024-09-29 20:54:40 meanwhile /usr can be like a single ro mount 2024-09-29 20:54:41 so... no support for read-only rootfs anymore 2024-09-29 20:55:06 it can be too 2024-09-29 20:55:51 ... 2024-09-29 20:55:58 please make it make sense 2024-09-29 20:55:59 this just means that instead of having several dirs in your rootfs that package manager writes to you mostly have one 2024-09-29 20:56:16 (plus mutable data in /etc and /var) 2024-09-29 20:56:37 so no /lib anymore either? 2024-09-29 20:56:57 idk what alpine wants to do but in all usrmerge systems i've seen /lib is a symlink 2024-09-29 20:57:12 yup 2024-09-29 20:57:28 and what about /usr/local, is it on a different mount so people can actually write to it 2024-09-29 20:57:38 or is it a link to /var/local or something 2024-09-29 20:57:48 uh, how you set up your mounts is still entirely up to you? 2024-09-29 20:58:26 then how is usrmerge making anything simpler ; ; 2024-09-29 20:58:54 by having fewer paths where stuff gets installed? 2024-09-29 20:59:14 ikke: are you gonna merge bin and sbin too 2024-09-29 20:59:16 oh, is it "the package manager will never touch anything outside /usr" ? 2024-09-29 20:59:31 (some distros don't, some do) 2024-09-29 20:59:37 q66: not atm 2024-09-29 20:59:38 Merging sbin seems silly. There is a point where less paths isn't simpler. 2024-09-29 20:59:38 "... except stuff in /etc and /var, because of course" 2024-09-29 21:00:03 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/73 2024-09-29 21:00:05 merging sbin is good because then nobody has to worry about whether shit goes in one or the other 2024-09-29 21:00:11 There is a reason why we have paths in the first place rather than just you know... files 2024-09-29 21:00:37 the distinction between what's sbin and what's bin has always been fuzzy anyway 2024-09-29 21:01:05 and has only resulted in annoying cases of "oh, this program is not runnable as my user even though it should be" 2024-09-29 21:01:21 ikke: what I get from it is 1. "everyone is doing it" and 2. "because systemd" 2024-09-29 21:01:22 great 2024-09-29 21:01:24 just great 2024-09-29 21:01:30 so merge it for people that are confused by permissions 2024-09-29 21:01:57 idk what permissions have to do with it 2024-09-29 21:02:41 not runnable as my user even though it should be 2024-09-29 21:02:42 for any executable installed by package manager that is not suid, permissions are effectively inconsequential 2024-09-29 21:02:58 oh I see 2024-09-29 21:03:11 xulfer: this refers to leaving sbin out of PATH for non-root -users 2024-09-29 21:03:11 might as well make them all root:root 0755 2024-09-29 21:03:33 at least there's a good case for merging /sbin and /bin: there's no reason to have /sbin in the first place, root-only binaries can be chmodded 0700 if users need to be prevented from running them - but that's pretty uncommon anyway 2024-09-29 21:03:34 Just as the statement about however you sort out your mounts is up to you. Can say the same for path 2024-09-29 21:03:35 yes, i always found it very annoying on debian etc 2024-09-29 21:03:58 skarnet: chmodding them to 0700 is entirely meaningless 2024-09-29 21:04:07 you can always get the package, extract it, and run the binary 2024-09-29 21:04:17 it helps uncluttering completion when you tab 2024-09-29 21:04:17 for any non-suid binary, permissions don't matter at all 2024-09-29 21:04:44 if you gonna merge sbin and bin, I don't want my completion being filled with binaries I can't run 2024-09-29 21:04:57 but it's minor 2024-09-29 21:05:06 it's _really_ minor 2024-09-29 21:05:07 apk is in /sbin, but you can run it fine as a non-root user 2024-09-29 21:05:13 It adds tedioum for the sake of having 'less directories' 2024-09-29 21:05:19 and less directories isn't inherently simpler 2024-09-29 21:05:21 ikke: sounds annoying 2024-09-29 21:05:24 ikke: yeah it should never have been in /sbin in the first place :P 2024-09-29 21:05:25 xulfer: what kind of tedium? 2024-09-29 21:06:22 q66: at least in alpine, sbin is part of PATH 2024-09-29 21:06:26 for normal users as well 2024-09-29 21:06:34 then sbin is completely useless 2024-09-29 21:06:38 ^ 2024-09-29 21:06:57 eh fine 2024-09-29 21:08:03 tbf, i've had weird chroot cases where /etc/profile didn't get sourced, and then /sbin wasn't in PATH when running as regular user 2024-09-29 21:08:05 imo as far as directory org goes either you keep it as simple as possible and have exactly one possible location for system-installed binaries, or you do the other way around and separate every single one of them 2024-09-29 21:08:19 anything inbetween is complicating it and is a net bad for UX 2024-09-29 21:08:29 (and for packaging and everything else) 2024-09-29 21:08:36 I'd rather have less large directories 2024-09-29 21:09:17 then you too can join the crusade against FHS 2024-09-29 21:09:22 but we're not winning today 2024-09-29 21:09:24 I have a system that implemented usrmerge many years ago, and never noticed any significant difference 2024-09-29 21:09:42 skarnet: FHS is likely going to be updated to include usrmerge 2024-09-29 21:09:46 skarnet: chimera has never been fhs compliant so 2024-09-29 21:09:55 mostly because i never bothered to check what being fhs compliant involves 2024-09-29 21:10:16 ikke: yeah and it will still be just as bad, usrmerge doesn't solve anything significant with FHS, on the contrary it makes it *worse* 2024-09-29 21:10:17 I think skarnet means slashpackage 2024-09-29 21:10:34 It's always nice when you need to resort to patterns to find a file that should be trivial to find. 2024-09-29 21:10:37 Ermine: that's one of several better options yes 2024-09-29 21:10:57 But you know the directory can't even be comprehensively viewed without a PAGER involved 2024-09-29 21:10:59 sounds simple 2024-09-29 21:11:21 do you often do ls /usr/bin ? 2024-09-29 21:11:34 I do, but I'm special 2024-09-29 21:11:39 Yes 2024-09-29 21:12:08 i do sometimes but there has never been a single instance of usrmerge making that less convenient for me so 2024-09-29 21:12:34 "more binaries in /usr/bin" isn't a good argument against usrmerge 2024-09-29 21:12:34 why would you do that 2024-09-29 21:12:51 less directories isn't a good argument for it imo 2024-09-29 21:13:11 indeed it isn't 2024-09-29 21:13:31 that's why this conversation is so infuriating 2024-09-29 21:14:04 it's all tweak around the edges because other people are doing a thing and we have to follow and somehow the community has decided that it would be the right thing 2024-09-29 21:14:52 but there never was a real written down plan or a discussion table to list exactly what we expect from a filesystem hierarchy and how usrmerge gets us closer or further from that state 2024-09-29 21:15:17 what is the exact semantics of these directories we're merging or not merging 2024-09-29 21:15:20 what do they achieve 2024-09-29 21:15:31 etc. 2024-09-29 21:15:59 what are tl;dr goals actually? 2024-09-29 21:16:30 One of them was to make a downstream project's transition to systemd easier. 2024-09-29 21:16:42 make your own mind about https://gitlab.alpinelinux.org/alpine/tsc/-/issues/73 2024-09-29 21:17:09 personally I find having "it is basically what everybody else is doing." as the first bullet point is a terrible reason to perform a change 2024-09-29 21:18:04 Most of the projects listed have very different goals than alpine has/had. I mean the goals can always change of course. 2024-09-29 21:18:08 Isn't that what the FHS was about in the first place, have at least some standardization? 2024-09-29 21:18:22 i disagree, making things similar between distributions sounds like a decent enough reason 2024-09-29 21:18:40 especially when it brings an additional benefit of "less random places where executables can be" 2024-09-29 21:19:10 Let's all jump together off the cliff \o/ 2024-09-29 21:19:19 where did that come from 2024-09-29 21:19:26 ikke: what's the standardization for /media and /srv 2024-09-29 21:19:33 and FHS hasn't even ratified these things anyway. Imagine if they don't heh 2024-09-29 21:21:55 benefit of usrmerge: you get a single path where distro installs files you are not supposed to change which is useful because unlike other paths that path can always be deterministically recreated from world 2024-09-29 21:22:00 drawback of usrmerge: ????? 2024-09-29 21:22:26 there are no good technical reasons to separate /bin and /usr/bin anymore. The /usr merge has some benefits and is important for pmOS, and pmOS is important for alpine. they also offered the help to do the actual work and are pushing it forward 2024-09-29 21:22:42 everyone is being like "nooooo you can't just make changes for the sake of making changes" but i've yet to see anybody provide a single good reason to keep it split 2024-09-29 21:22:44 ????? = you can't have separate /usr anymore 2024-09-29 21:22:50 all it does is make things *more* complicated 2024-09-29 21:22:58 less directories isn't simpler. it's just less directories. directories are a *feature* for separating files into logical groupings. 2024-09-29 21:23:02 What's the solution actually? 2024-09-29 21:23:09 To put everything in /bin, or in /usr/bin? 2024-09-29 21:23:19 everything in /usr/bin 2024-09-29 21:23:28 q66: looking at the amount of usrmerge-related MRs to aports, i'd say the drawback is the initial cost of making sure everything installs to /usr 2024-09-29 21:23:43 Ermine: if you mean separate /usr where / is still a "working" rescue system, that hasn't been properly possible for ages anyway and was always more of a theoretical scenario than a practical one 2024-09-29 21:23:43 and /bin is symlink pointing to /usr/bin 2024-09-29 21:23:50 and the downstream trouble it will possibly cause 2024-09-29 21:23:59 there are lots of blog posts on this subject 2024-09-29 21:24:00 but after that's done, it's pretty much the same thing as making sure packages don't install into /opt or some other weird place 2024-09-29 21:24:00 to like yocto/poke which I'm sure we'll hear about soon enough heh 2024-09-29 21:24:48 xulfer: wait, how is yocto downstream from alpine 2024-09-29 21:25:00 a lot of bitbake users use apk 2024-09-29 21:25:20 downside with usrmerge: changes are always risky. things breaks in unexpected ways 2024-09-29 21:25:20 Some people actually use yocto? 2024-09-29 21:25:36 you mean apk-tools, or apks from Alpine repos? 2024-09-29 21:26:14 both. just add alpine repos along with your own 2024-09-29 21:26:36 drawback, it works as it already is 2024-09-29 21:26:47 other downside: the work to deal with it 2024-09-29 21:27:06 none of the complainers are doing any of the work so that's not a downside 2024-09-29 21:27:30 pmOS has agreed to do the actual work 2024-09-29 21:27:38 yeah and they are not complaining about it 2024-09-29 21:27:40 complainers being the one wanting to change the existing? 2024-09-29 21:27:48 Not to change 2024-09-29 21:27:51 no, the ones not doing any work atm 2024-09-29 21:28:10 just to make it clear, I'm pretty indifferent to usrmerge, this will not impact me either way. But given how conservative Alpine has always been with big system changes (and with good reason), I'm really surprised at how usrmerge seems to have been widely and quickly agreed upon with so little technical analysis. 2024-09-29 21:28:13 so people who wouldn't work on it naturally because they oppose it not because they're lazy 2024-09-29 21:28:17 Well, it's past working hour in half the world 2024-09-29 21:28:34 q66: I'm pretty sure there are people who are ready to insert WORKSFORME remark at this point 2024-09-29 21:28:47 it really sounds like a political decision more than a technical one, and that is pretty disappointing to be honest 2024-09-29 21:28:55 i mean i don't really care myself because i have no stakes in this since i don't even use alpine 2024-09-29 21:29:00 i just find it very funny 2024-09-29 21:29:01 alpine is not the first distro to do this. 2024-09-29 21:29:02 For me it makes technical sense as well 2024-09-29 21:29:41 hence the doing any of the work, got it 2024-09-29 21:29:44 "none of the complainers are doing any of the work" is not a really good attitude 2024-09-29 21:29:54 I think that was a self-reference 2024-09-29 21:29:56 ikke: then can you please explain? shouldn't the burden of proof be on the side of people who want the change? that's what I was told, anyway. 2024-09-29 21:30:03 Not intended to others 2024-09-29 21:30:07 q66 already explained it 2024-09-29 21:30:39 but that wasn't convincing at all! (sorry q66) 2024-09-29 21:31:03 you won't find it convincing regardless of what i say 2024-09-29 21:31:20 I very much doubt that 2024-09-29 21:31:21 besides, as i said, i have exactly 0 stakes in this 2024-09-29 21:31:36 Yet you've been it's biggest advocate in the conversation thusfar 2024-09-29 21:32:09 the argument was "package managers will now install in /usr only" except no they won't, and "it will make /usr RO-mountable" except it already can be 2024-09-29 21:32:35 both "it will simplify things for users" and "you decide where your mountpoints are" at the same time? 2024-09-29 21:32:50 It's more that you can provide a complete system in /usr that is immutable 2024-09-29 21:33:14 a/b style boots become a lot easier 2024-09-29 21:33:24 package manager will install files that you are not expected to change in a single location only 2024-09-29 21:33:26 that part is true 2024-09-29 21:33:50 except you need a/b configuration too, and that's in /etc, so you need /etc immutable too, etc. 2024-09-29 21:34:32 just be honest and say it will make life easier for package managers 2024-09-29 21:34:33 /etc is mutable so it's treated specially, even by apk 2024-09-29 21:34:35 not for users 2024-09-29 21:35:32 also idk about alpine but myself i've been generally working towards making package-manager-managed /etc not a thing 2024-09-29 21:35:33 q66: and /var as well because packages need /var/lib, including apk 2024-09-29 21:35:59 yeah I agree that /etc should ideally be out of bounds for a package manager, but it's hard for basic stuff 2024-09-29 21:36:03 I guess another symlink 2024-09-29 21:36:32 in general in my own stuff i've been following the system "have an immutable config somewhere, have /etc override it if needed" 2024-09-29 21:36:32 what I was most afraid of re usrmerge was time needed to be spent on fixing things that unexpectedly breaks, and time spent on discussions like this 2024-09-29 21:37:26 ncopa: discussions like this happen because there's no evidence they have ever taken place 2024-09-29 21:37:32 as for /var, most of it is already not managed by package manager in my case 2024-09-29 21:37:45 other systems like sd-tmpfiles handle that 2024-09-29 21:37:58 Also discussing is usually sane, if not treated as a was 2024-09-29 21:38:00 and a lot of people don't follow TSC 2024-09-29 21:38:01 s/was/war/ 2024-09-29 21:38:12 skarnet: hence results of such discussions should be outside of IRC 2024-09-29 21:38:13 and a lot of people pushing for it in TSC were doing so for a distribution that is not alpine 2024-09-29 21:38:20 Ermine: agreed 2024-09-29 21:38:56 in general in my own stuff i've been following the system "have an immutable config somewhere, have /etc override it if needed" 2024-09-29 21:38:56 OF course you're right though 2024-09-29 21:39:02 yeah I like that idea 2024-09-29 21:39:52 i just checked and my apk-managed /var stuff is already very slim and i can probably just get rid of the rest too 2024-09-29 21:40:01 for /etc it's going to be more complicated but a lot of it can be addressed 2024-09-29 21:40:11 do you have /etc/foobar.conf as a symlink to e.g. /usr/etc/foobar.conf, and the user can write their own /etc/foobar.conf instead if they want? or something similar? 2024-09-29 21:40:13 and then... it will really be true that there is only a single (and immutable) path that is managed by package manager 2024-09-29 21:40:35 no the /etc path just does not exist and if the user wants to tweak it they copy the /usr file to /etc and modify it 2024-09-29 21:41:04 then if you want to e.g. diff it, you easily can 2024-09-29 21:41:15 without needing to have the package manager create backup files 2024-09-29 21:41:18 but it means the software has to support the absence of a config file 2024-09-29 21:41:24 and have sane defaults 2024-09-29 21:41:31 sure 2024-09-29 21:41:34 as it should 2024-09-29 21:41:48 and then wireplumber broke it's config format... 2024-09-29 21:41:56 anyway it's continuous work, and usrmerge is one prerequisite for it 2024-09-29 21:41:56 s/it's/its/ 2024-09-29 21:42:18 but again, i have no idea what alpine wants to do in long term so 2024-09-29 21:42:38 skarnet: /etc would just be another high prio location where the config could be 2024-09-29 21:42:39 and I apologize if I seem antagonistic. Not my intention by any means. 2024-09-29 21:43:10 q66: I do like that setup myself 2024-09-29 21:43:11 not my intention either, I just like it when big changes are backed up by technical arguments 2024-09-29 21:43:24 this kind of system also makes it easy to e.g. mask system-provided files rather than change 2024-09-29 21:43:32 you just create the right thing in /etc by making it a /dev/null symlink 2024-09-29 21:43:47 (or an empty file) 2024-09-29 21:44:08 skarnet: well, at this point there are technical arguments 2024-09-29 21:44:18 ikke: i've been wanting that + atomic apk transactions for a long time 2024-09-29 21:44:25 Ermine: not very good ones, but, yeah 2024-09-29 21:44:38 my apk transactions are already mostly atomic (packages have no pre/post hooks except like 3 rare cases) 2024-09-29 21:44:42 Sounds like we're talking about another distribution than alpine though 2024-09-29 21:44:55 q66: atomic package manager changes are just not possible with FHS 2024-09-29 21:45:19 well "atomic" is not accurate 2024-09-29 21:45:21 but rather 2024-09-29 21:45:25 if you have several binaries to install in /usr/bin, there *will* be a window where you have one and not the other 2024-09-29 21:45:26 spending as little time as possible doing the fs commit 2024-09-29 21:45:55 all you can do is save the old binaries somewhere and have a good rollback procedure 2024-09-29 21:45:58 not sure what does it have to do with 'atomic' 2024-09-29 21:46:02 if anything goes wrong 2024-09-29 21:46:06 when you have no hooks, apk will generally extract its stuff in a temp location and then just migrate everything at the very end (before triggers are run) so there is less time during which it can go wrong 2024-09-29 21:46:17 when you have hooks, it has to do that before running every hook 2024-09-29 21:46:35 so like, it extracts stuff for 20 packages, runs a hook, then spends time installing another 20 2024-09-29 21:46:57 "less time during which it can go wrong" is good, but if you want safety, you also need "rollback if something does go wrong" 2024-09-29 21:47:09 yes of course, this is just about increasing robustness a bit 2024-09-29 21:47:27 and reducing the amount of bad patterns while at it, because pre/post hooks should rarely be a thing 2024-09-29 21:47:37 instead reimagining things around triggers is usually much better 2024-09-29 21:47:40 it's so much easier conceptually to have something like slashpackage where an upgrade *is* atomic 2024-09-29 21:48:12 of course it has other drawbacks but it makes package management such a breeze 2024-09-29 21:48:42 right now i have 2 cases where hooks are still used: 1) kernel backup hooks ( :( ) and 2) the 3 packages where you need to install a suid binary that is owned by a particular group to prevent others from running it ( :( ) 2024-09-29 21:50:28 hooks are unavoidable in some cases 2024-09-29 21:50:38 I don't think they're evil 2024-09-29 21:50:44 just inconvenient 2024-09-29 21:50:59 well the two cases above are the only ones where they've been unavoidable 2024-09-29 21:51:08 and i have plans to address both 2024-09-29 21:51:30 I'd like to see what you come up with 2024-09-29 21:51:52 for the former i don't have anything specific yet, but long term solution will involve a feature in apk 2024-09-29 21:51:58 for the latter the main one is dbus 2024-09-29 21:52:04 the idea is to get rid of the current implementation of dbus 2024-09-29 21:52:10 I guess it might be worth it to continue this discussion in chimera spaces? 2024-09-29 21:52:33 this is cross-distro talk 2024-09-29 21:52:39 yeah i'd say this is all cross-distro 2024-09-29 21:52:46 but if you want me to shut up i can 2024-09-29 21:53:05 you just said "get rid of the current implementation of dbus", so please go on 2024-09-29 21:53:32 I have no authority on shutting up people here 2024-09-29 21:53:34 i'll probably adopt dbus-broker in short term (short term being next 3 weeks) which does not have a suid launch binary because it delegates dbus services all to service management 2024-09-29 21:54:01 service manager already runs as root, and the bus does not (even with the "normal" implementation) 2024-09-29 21:54:27 so basically replacing suid with longrun services 2024-09-29 21:54:31 which is a good thing 2024-09-29 21:54:35 the older impl solves it with a suid launch helper, the newer impl solves it by configuring dbus policy to let the bus process and bus process only access a privileged interface that can run services 2024-09-29 21:55:05 yeah 2024-09-29 21:55:40 I'm not sure you'll be able to do that with every suid instance you package though 2024-09-29 21:55:53 it's a good thing in two ways, one is not having suid binary, the other is actually supervising the services rather than spawning them and not caring further 2024-09-29 21:56:12 definitely 2024-09-29 21:56:42 there are 3 binaries i've run into that were like this, dbus launch helper is one, the other two are qemu bridge helper and one of the wireshark binaries, there probably aren't many more but yeah there may be unavoidable cases 2024-09-29 21:56:46 i'm not yet sure how to address the other two 2024-09-29 21:57:22 i don't expect to be able to address everything and anything, but i want to at least reduce the amount of suspects 2024-09-29 21:57:34 mainly due to my hatred of suid binaries and their implications 2024-09-29 21:57:36 the main problem I've had with turning suid into services is when you need a terminal 2024-09-29 21:57:53 terminal-less programs can be converted quite easily 2024-09-29 21:58:09 yea 2024-09-29 21:58:13 but as soon as you have terminals in the picture, you need some kind of forwarder or idk 2024-09-29 21:58:20 that becomes ugly fast 2024-09-29 21:58:30 sure 2024-09-29 21:58:56 i wish for a future where suid can be disabled in the kernel 2024-09-29 21:59:22 or at least one where you can mount / nosuid and expect everything to work :) 2024-09-29 21:59:38 that's why I'm not entirely convinced by full suidless... for controlled, server-like or embedded-like environments? sure, no problem. For general usage distros with desktops and stuff? I'm not sure. 2024-09-29 22:00:00 well the forwarder can work 2024-09-29 22:00:04 it's just a pain to implement 2024-09-29 22:00:29 yeah 2024-09-29 22:01:49 if i could divide myself a few times i'd probably do all this stuff 2024-09-29 22:02:08 as it is i can just do it little by little 2024-09-29 22:04:03 you and me both lol 2024-09-29 22:05:17 well time to ditch apk-managed /var directories now :P 2024-09-29 23:38:06 skarnet: re /usr merge it's been being discussed for almost a year, I wouldn't call that fast... im also not sure what aspect of it you think is political? You said yourself you're "indifferent to it" so i gotta ask what the deal is here 2024-09-29 23:40:51 on packages putting stuff in /etc, you're on point with default config files being moved to /usr, but rather than making /etc a symlink you'd use something like systemd-tmpfiles to populate /etc on first boot. At that point you can essentially implement "factory reset" by just shipping a /usr partition and creating the entire root partition on 2024-09-29 23:40:51 first boot. Just delete the root partition to start fresh 2024-09-30 00:31:37 see, that's exactly what I mean 2024-09-30 00:31:46 "just delete the root partition" sounds BONKERS to me 2024-09-30 00:32:53 I *am* indifferent to usrmerge, I am however interested in the underlying technical justifications for it and implications on our systems 2024-09-30 00:33:33 and a world where users have to "just delete the root partition" to "factory reset" isn't a world I want to live in 2024-09-30 00:34:20 turning /usr into the managed firmware, ok, I can understand that 2024-09-30 00:34:46 i don't see the issue with it being possible to delete the root partition and it being made for you as a reset method 2024-09-30 00:34:53 sounds better than it not being possible? 2024-09-30 00:35:31 because it makes initramfs mandatory? 2024-09-30 00:36:20 I want things to evolve towards less moving part and less complex necesary infrastructure 2024-09-30 00:36:43 oh we're still arguing if initrd's are bad 2024-09-30 00:36:44 carry on 2024-09-30 00:37:01 initramfs != initrd, but that's not even the question, no 2024-09-30 00:37:14 the question is if initramfs becomes *mandatory* 2024-09-30 00:38:12 essentially you're moving the real / into a space where it is more difficult to audit and modify for users 2024-09-30 00:39:03 it does not "become mandatory", it is "mandatory" for that "feature" if someone "implements the feature" 2024-09-30 00:39:10 like how currently it is mandatory to have on pmOS already 2024-09-30 00:39:26 i phrased it like that because it has nothing to do with the discussion, it's just sidestepping it to some unrelated initrd bad thing 2024-09-30 00:40:47 it has everything to do with the discussion: if we want /usr to be firmware then initramfs needs to be firmware as well, and / is user-controlled... that, uh, looks back asswards to me 2024-09-30 00:41:17 why not make / firmware and /config or /etc or whatever user-controlled 2024-09-30 00:42:01 I was doing that 15 years ago and it was working pretty well, with A/B booting and stuff 2024-09-30 00:42:27 but apparently I'm old and useless now and the cool kids have moved on to something So Much Better (tm) 2024-09-30 00:42:47 so much better it disempowers users much more but who cares about that 2024-09-30 00:46:17 yeah, users are very disempowered because files are in /usr/bin instead of /bin 2024-09-30 00:46:19 what am i reading 2024-09-30 00:46:45 you should try actually using linux sometime instead of windows, maybe it will make more sense then 2024-09-30 00:55:46 skarnet: the technical justifications are explained pretty clearly. to reiterate a few things... it simplifies a looot of packaging (so many symlink hacks in APKBUILD's atm) and simplifies things for users 2024-09-30 00:56:11 more importantly though 'a world where users have to "just delete the root partition" to "factory reset" isn't a world I want to live in' -- what's with all the FUD? 2024-09-30 02:09:50 calebccff: it's literally what you said, but in the name of dedramatization: what I mean is I really don't think making / volatile and /usr immutable makes anything easier than having / immutable and the mutable data somewhere else. 2024-09-30 02:10:44 Regarding "simplifies a lot of packaging", yeah, I get it. It makes it easier for packagers. Which is a good argument in itself. But I still don't see that it makes it any easier for users. 2024-09-30 02:12:12 psykose: user disempowerment comes from systems being too complex to handle manually and having to rely on another party to do things for them (here, the other party being the distro). Having to use an initramfs when their setup would make it otherwise unnecessary is user disempowerment. This has nothing to do with /usr/bin vs. /bin. 2024-09-30 02:13:28 sorry for putting vague language where clarity and technical accuracy is super important. 2024-09-30 02:13:59 i must've missed the part where the /usr merge was actually about discussing making an initramfs mandatory in alpine 2024-09-30 02:18:19 If /usr is where the distro does its stuff and / is entirely mutable to the point of being able to be deleted, then / is unsuitable for booting as is, it needs to be a tmpfs or equivalent, and that implies that you have to boot on an initramfs. 2024-09-30 02:21:03 which, for a distro, you kinda already have to do in order to support modules to mount / and stuff, but if nobody mounts / directly anymore (and, worse, read-only), how long until this becomes deprecated? 2024-09-30 02:21:30 that's the kind of thing I'm concerned with (but I agree it does not concern Alpine directly). 2024-09-30 06:46:52 initramfs is already mandatory anyway. And yes, there's a patch already merged to mount /usr from it 2024-09-30 06:48:21 Hello, I am reading a security advisory about Alpine Linux and I have a question about how I should gather information about source packages. 2024-09-30 06:48:21 For example, if I read https://security.alpinelinux.org/vuln/CVE-2024-6119, I see that the source package name: openssl provided in 3.20-main is fixed in source package version: 3.3. 2-r0. 2024-09-30 06:48:21 So, how can we use the apk command to collect information about the source package? 2024-09-30 06:48:23 If I use `$ apk list --installed`, I get something like “libssl3-3.3.2-r0 x86_64 {openssl} (Apache-2.0) [installed]”, which can be interpreted as {}. but the source package version is not known. 2024-09-30 06:49:11 If this question is on the wrong channel, I would appreciate it if you could direct me to the appropriate channel. 2024-09-30 06:49:38 the versions are matching 2024-09-30 06:49:55 xyz-version {abc} means abc is also -version 2024-09-30 06:50:06 in alpine's case, at least 2024-09-30 06:50:26 technically the origin doesn't have to be matching, so you would need an extra lookup, but for alpine they do 2024-09-30 06:59:13 In alpine linux, if source pakcage name: abc and source package version: 0.0.1, can I understand that all binary packages (sub packages) of abc are version 0.0.1? 2024-09-30 06:59:42 yes 2024-09-30 07:00:17 Thank you for your quick reply! 2024-09-30 07:57:07 hello, is there a way to build a package with a specific version of go? I tried `makedepends="go=1.22"` but thats fails 2024-09-30 07:57:38 breaks: world[go=1.22] 2024-09-30 07:57:38 ERROR: unable to select packages: 2024-09-30 07:57:38 go-1.23.1-r0: 2024-09-30 07:57:38 ``` 2024-09-30 07:57:38 ``` 2024-09-30 08:03:39 raspbeguy: no, since we only ship one version per branch 2024-09-30 08:04:34 ok. That's a shame because I cannot update some packages 2024-09-30 08:07:10 which packages? 2024-09-30 08:22:03 testing/mimir 2024-09-30 08:54:48 Seems like it is already fixed upstream 2024-09-30 12:02:01 hello, I've just received a notification that one of my merge request is going to be closed: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69804#note_440980 2024-09-30 12:07:51 the merge was an attempt at submitting my game "Spinny the runner" so that it can be added to postmarket os, unfortunatelly I don't know how to progress in this attempt, is anyone interested on building the apk and submitting it for me feel free to do it, the website of the game can be found here: https://glitchapp.codeberg.page/_boxclip/ 2024-09-30 14:05:43 > Seems like it is already fixed upstream 2024-09-30 14:05:43 yes. but we'll have to wait for next release 2024-09-30 14:06:16 nothing stops you from backporting patches 2024-09-30 14:14:00 how does the default_doc works 2024-09-30 14:15:08 ok I found it, nvm https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1956 2024-09-30 14:28:23 Looks like the loongarch CI is being wonky, it's failing to update its repos, example: https://gitlab.alpinelinux.org/durrendal/aports/-/jobs/1538583 2024-09-30 14:51:23 durrendal: it's a known issue, and will be fixed as soon as the testing repo for the loongarch64 builder is unblocked 2024-09-30 14:52:00 makes sense, thanks ikke 2024-09-30 17:22:29 PureTryOut: why was the merge canceled on !72789 ? 2024-09-30 17:22:59 I think that happened since it was an automatic merge and I merged something in between 2024-09-30 17:23:13 makes sense 2024-09-30 17:23:25 ty 2024-09-30 17:23:34 I don't like automatic merges because of that, I rather wait manually on the CI to complete 2024-09-30 17:23:43 will keep an eye next time 2024-09-30 18:13:19 maybe a silly question, but my google-foo is failing me, is there a way to load an env file into an openrc init script? In a way similar to how systemd EnvironmentFile works essentially 2024-09-30 18:13:46 durrendal: it's a shell script, so you could just source it 2024-09-30 18:14:09 But variables are not automatically exported 2024-09-30 18:14:14 there is set -a to do that 2024-09-30 18:14:44 durrendal: more commonly is to set those in the conf.d file 2024-09-30 18:15:41 rg 'set -a' led me to minio's conf.d :) back on the right track 2024-09-30 18:16:43 thank you ikke, very much appreciate it! woodpecker removed their -env-file flag so my init scripts are broken, but it seems like adding a conf.d is the fix which works well for me 2024-09-30 19:15:32 ncopa: i asked in the introspection chat room and apparently they don't seem to care about 32-bit support 2024-09-30 19:17:32 fossdd[m]: bigger reason to not revert 2024-09-30 19:17:45 we can maybe git bisect it 2024-09-30 19:17:46 yeah true 2024-09-30 19:19:42 meh 2024-09-30 19:19:55 ncopa-edge-x86:~/src/gobject-introspection$ abuild-meson -Db_lto=true . output 2024-09-30 19:19:55 -ash: abuild-meson: not found 2024-09-30 19:20:37 the reason I in the past tried to avoid things like abuild-meson 2024-09-30 19:21:21 it comes from meson so if it's not found then meson isn't installed either? 2024-09-30 19:21:29 oh. i just had to install the deps ... 2024-09-30 19:21:32 im stupid :) 2024-09-30 19:21:41 haha 2024-09-30 19:21:46 btw thanks for taking a look into it 2024-09-30 19:25:05 the syntax error is there in gobject-introspection-1.80.1 too, but it does not make the test fail 2024-09-30 19:25:35 uhh weird 2024-09-30 19:26:30 and I get build error when building from git 2024-09-30 19:26:34 ../tests/meson.build:21:23: ERROR: File ../gobject-introspection-tests/regress.c does not exist. 2024-09-30 19:27:01 did you clone the submodules 2024-09-30 19:32:47 nope 2024-09-30 19:32:58 i just git bisec bad'ed it 2024-09-30 19:33:05 and found the problem 2024-09-30 19:33:16 https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/520#note_2235872 2024-09-30 19:33:22 problem is deeper 2024-09-30 19:34:52 I wonder if this has ever worked properly 2024-09-30 19:35:25 yeah i think they "just" dont support _Alignas 2024-09-30 19:57:51 they shouldn't need to support _Alignas, or anything that is _ prefixed. It is for internal use 2024-09-30 19:58:10 do they support other _ stuff? 2024-09-30 19:59:45 or other libc internals? 2024-09-30 20:01:57 i think that it happens on 32 bit is irrelevant, so "we don't care about 32 bit" does not count 2024-09-30 20:02:14 Hm if I have a version bump that will cause a bunch of rebuilds it's generally preferred to have the pkgrel bumps in the same MR yeah, or no? 2024-09-30 20:03:26 xulfer: yes 2024-09-30 20:03:39 Otherwise the repo would be broken for some period 2024-09-30 20:04:15 Yeah that's what I thought. Poor builders though. 2024-09-30 20:04:23 They have seen worse 2024-09-30 20:09:35 _Alignas is definitely something a bindings generator has to be aware of though 2024-09-30 20:10:31 in c11 it was `alignas` as a macro and that's just what it expands to 2024-09-30 20:10:44 in c23 it becomes a specifier 2024-09-30 20:10:53 it's not internal to something 2024-09-30 20:28:32 actually there was no alignas in c11, i was thinking of c++ :D 2024-09-30 20:28:39 same thing in the end tho 2024-09-30 20:29:19 Hm I learned something. I didn't think the standard specified it to be a macro. 2024-09-30 20:32:11 it doesn't, i just thought it existed and was one 2024-09-30 20:32:14 it did not 2024-09-30 20:32:21 Ahh gotcha 2024-09-30 20:32:43 actually no it does 2024-09-30 20:32:52 i can't read the correct page cause i've been awake too long 2024-09-30 20:33:10 yeah what i originally said is true instead 2024-09-30 20:33:24 https://en.cppreference.com/w/c/language/_Alignas docs are very hard 2024-09-30 21:24:22 ncopa: that code should only trigger when using -std less than c11 2024-09-30 21:24:37 do you have full compiler cmdline when it fails ? 2024-09-30 23:05:30 Hmm well I had a bunch of stuff rebuilding for community and it got terminated for taking too long. Is it helpful to break it up into individual commits rather than just one for community/* in most cases?