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