2024-10-01 04:30:36 that shoudnt matter 2024-10-01 04:30:49 but you can change the timeout in your fork's project settings 2024-10-01 06:17:16 khem: its gobject-introspection scanner (1.82.0) that chokes on _Alignas. https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/520 2024-10-01 12:44:22 can someone merge the redis/redict MRs? 2024-10-01 12:44:39 for valkey i'd wait until they make a point release. should be later this day 2024-10-01 13:51:55 Would anybody be able to have a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72271 2024-10-01 13:52:16 Both Newbyte and me are happy with it, and seems to be affecting some users 2024-10-01 14:08:51 fossdd[m]: Ahh thanks for the tip 2024-10-01 14:22:02 hi. I am trying to create a simple package for alpine. here's the apkbuild: https://paste.opensuse.org/pastes/bcd6fb1954b4. the repo's dir is inside the src directory so I am getting this error: error: could not find `Cargo.toml` in `/home/packager/src` or any parent directory 2024-10-01 14:22:47 how do i clone the whole repo directly inside the src instead of it creating a folder of the repo? 2024-10-01 14:25:54 the builddir is the correct path but for some reason its not working 2024-10-01 14:35:39 look inside $srcdir and check how the dir is called, you should set this dir to $builddir="$srcdir/....". 2024-10-01 14:36:27 btw: pkgver's never start with v, you should remove the v and prepend it where nesessary (like in $source or $builddir) 2024-10-01 14:36:56 oh and instead of forcing the target, you should use --target="$CTARGET" 2024-10-01 14:43:35 !72047 is also ready to merge :> 2024-10-01 14:46:18 sandbag: maybe adjust the url to https://github.com/memorysafety/rav1d/archive/v$pkgver/rav1d-v$pkgver.tar.gz 2024-10-01 14:47:04 sandbag: and what fossdd[m] said about the $pkgver, remove the "v", that url worked for me, probably no need to set $builddir 2024-10-01 14:49:38 thank you fossdd[m] mio. that worked 2024-10-01 14:50:29 the v was not needed in the pkgversion 2024-10-01 14:55:26 install: can't stat 'target/release/rav1d': No such file or directory 2024-10-01 14:55:51 should i mention the whole path like "$pkgdir"/target/release/ ? 2024-10-01 14:56:13 i saw multiple rust APKBUILD using just target/release in install() 2024-10-01 15:00:06 oops, the binary name is different. sorry 2024-10-01 15:00:28 is it a good practice to copy everything from release and install it? 2024-10-01 15:21:21 is there any sort of loose timeline set for the next Alpine release? I see the release before last was December (not that Alpine follows a schedule per se). I'm wondering because I need to make some big(ish) changes to Ceph and wondering how much time I have since I missed the cutoff last release 2024-10-01 15:22:54 sandbag: release often contains misc stuff you most likely never need, so you would only copy the bin. If there are further docs like man-pages, or completions for shells, feel free to include them. But there is no need :) 2024-10-01 15:23:32 yeah, i just copied the binary and lib* 2024-10-01 15:24:04 iggy: alpine plans to release every may and november IIRC. https://gitlab.alpinelinux.org/groups/alpine/-/milestones/10 probably needs to be finished before a new release can be tagged 2024-10-01 15:25:22 sandbag: if the libs are relevent, yeah. but note that you should install them to /usr/lib 2024-10-01 15:26:18 iggy: releases are loosely scheduled at May and November 2024-10-01 15:28:27 perfect, thank you, now I need to get the new Ceph tested and expunge the old one 2024-10-01 15:31:10 I wonder if busybox 1.37 is going to be a part of that milestone (or I guess more generally how much are the milestones used to actually plan everything that goes into a release) 2024-10-01 15:31:37 iggy: it's not that strict 2024-10-01 15:31:43 the milestones are more like a reminder 2024-10-01 15:35:12 rgr 2024-10-01 15:56:20 CI is a bit busy atm 2024-10-01 16:06:11 what is the decision making criteria for what security fixes make their way to previous releases or not? or does everything with a CVE need it? 2024-10-01 16:06:34 We try to backport everything that is possible 2024-10-01 16:06:44 Generally only for supported releases 2024-10-01 16:06:53 For community that means only the last stable release 2024-10-01 16:07:49 ok got it. so if i'm updating a package i maintain for a new maintenance release with security fixes i should submit MR against master and also the 3.20-stable branch? 2024-10-01 16:08:09 Yes 2024-10-01 16:08:28 ok great thanks, will do 2024-10-01 16:55:29 why is gitlab so slow in forking (aports repo)? github forks almost instantly 2024-10-01 16:55:35 alpine gitlab* 2024-10-01 17:05:30 aports is pretty big repo with large history 2024-10-01 17:05:52 and alpine has less computational power than github 2024-10-01 17:36:19 Forking public repos in GH is basically a free action because all the forks share the same backing storage of git objects. GL might not be doing that. To be fair the GH behavior creates some surprises too around private <-> public repo conversions 2024-10-01 20:06:30 Apologies for the CI. I've underestimated the build time needed. Qt rebuilds :/ 2024-10-01 20:06:42 chromium is brutal 2024-10-01 20:07:05 Seems like there are no pending jobs anymore 2024-10-02 08:16:29 Hm been working on getting ffmpeg to compile as a part of !72806 with some success. Though since there's a new version, and it seems like fully getting it building is beyond the scope of updating vulkan I was thinking of kicking out the ffmpeg rebuild entirely and starting another issue/draft on it. 2024-10-02 08:28:38 once I tried to bump ffmpeg but that is way beyond my knowledge 2024-10-02 08:35:48 It's going on a couple of archs after some patches. 2024-10-02 08:36:13 Not sure how it compiled in the last bump since I had to backport patches from ffmpeg, and gentoo to fix unrelated errors 2024-10-02 09:35:42 i will start set up the 3.21 builders soonish. this or next week (?) 2024-10-02 09:35:55 do we have everythign we need in of toolchains? 2024-10-02 09:36:26 llvm 19 is out 2024-10-02 09:36:50 maybe we should prioritize get that working properly? 2024-10-02 09:37:03 are we going to kill net6 on that release? 2024-10-02 09:37:45 ncopa: i guess apkv3 will move to 3.22 2024-10-02 09:37:59 what is net6? 2024-10-02 09:38:15 if we can kill it we will kill it 2024-10-02 09:38:24 I mean dotnet6 2024-10-02 09:38:36 if we can we will 2024-10-02 09:38:41 i dont know if we can 2024-10-02 09:38:58 is dotnet6 still supported from upstream? 2024-10-02 09:39:08 until november 2024-10-02 09:39:18 the maintainer mailed me about it 2024-10-02 09:39:25 ok 2024-10-02 09:39:50 what happens if we delete dotnet6? 2024-10-02 09:39:51 https://devblogs.microsoft.com/dotnet/dotnet-6-end-of-support 2024-10-02 09:41:18 we should probably get some consensus of the python venv splitting before 3.21 2024-10-02 09:41:23 llvm 19 2024-10-02 09:41:36 can we delete some older llvm? 2024-10-02 09:41:56 we also need to start write release notes 2024-10-02 09:43:24 anything else that is emergent? 2024-10-02 09:43:26 I've hit a interesting bug with nlplug-findfs when there's a dm-crypt device on top of dm-raid 2024-10-02 09:43:37 what happens if we delete dotnet6? ayakael knows better, but we have some pkgs that uses it (honest its just 5 and 4 of them is on me) 2024-10-02 09:44:02 I'll look into it later, seems like nlplug-findfs seems to skip searching on the dm-raid device even though it has the parameters 2024-10-02 09:44:09 what about the armv7 page size? do we want bump page size to 32k for armv7 at linker level? 2024-10-02 09:44:46 there was this issue of docker images on some qnap NAS 2024-10-02 09:44:55 they bumped the page size to 32k in kernel 2024-10-02 09:45:24 older binutils had 64k page size, so binaires worked with 32k pages on that kernel 2024-10-02 09:45:40 but they fixed that in binutils and the binaries broke on that kernel 2024-10-02 09:46:00 do we want fix that? 2024-10-02 09:46:05 if so, now is the time 2024-10-02 09:46:20 before i start up the 3.21 builders 2024-10-02 09:46:41 ncopa: I've marked https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72703 as ready, since I'm now available to watch if anything breaks 2024-10-02 09:47:42 PabloCorreaGomez[m]: i trust you. hope nothing breaks... :) 2024-10-02 09:48:44 Hehe, that one I looked over with some care, and there the split-usr option that forces lookups on both /usr and /lib 2024-10-02 09:49:03 Of course there's always a risk, but seems pretty safe, I hope 2024-10-02 09:49:26 Else like in all the other ones, just ping me when people complain that things break 2024-10-02 09:49:53 thank you! 2024-10-02 09:50:43 caskd: there is a test suite for nlplug-findfs. can you try reproduce it there? 2024-10-02 10:00:57 ok. we cannot drop llvm15 due to ghc 2024-10-02 10:28:50 clandmeter: my new flagged out of date email starts with "Dear tvheadend" (the first aport out of date) instead of my name :) 2024-10-02 10:28:58 just wanted to let you know :) 2024-10-02 10:29:30 fossdd[m]: do you mind creating an issue here? https://gitlab.alpinelinux.org/alpine/infra/apkbrowser 2024-10-02 10:29:41 For me it was empty 2024-10-02 10:29:47 yep 2024-10-02 10:33:53 Hiya, would gxlimg be appropriate for alpine? It's a replacement tool for aml_encrypt_gxl, which is used for building images suitable to boot on Amlogic GXL boards. 2024-10-02 10:34:08 I see meson-tools is already packaged, which does the same thing but for GXBB boards. 2024-10-02 10:35:33 https://github.com/repk/gxlimg <- gxlimg repo 2024-10-02 11:08:21 FYI I already talked to the author, and he's fine with it being packaged in alpine. 2024-10-02 13:37:30 PabloCorreaGomez[m]: I think the eudev move broke FDE unlocking on postmarketos for me. Downgrading to old eudev and running mkinitfs fixes things. 2024-10-02 13:37:49 Yes, I know: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/5663 2024-10-02 13:38:04 I guess if it's not just me, I'm going to merge that one without reviews 2024-10-02 13:38:29 Unfortunately, I realized too late. And luckily alpine does not have udev in the initramfs 2024-10-02 13:38:35 So it's "only" downstream 2024-10-02 13:39:19 ah cool, thanks, sorry for "me too"-ing you. 2024-10-02 13:39:23 I think pkgs.a.o "required by" is broken, at least I cant see any 2024-10-02 13:39:56 ok noy any, I can see some, but not all 2024-10-02 13:40:33 elagost: no worries, it helps push up the priority of this 2024-10-02 13:43:17 thanks for your hard work on this - and that's the price I pay running edge, I guess! 2024-10-02 14:01:35 elagost: before I merge, do you have a chance of mrtesting https://gitlab.com/postmarketOS/pmaports/-/merge_requests/5663 2024-10-02 14:01:39 * elagost: before I merge, do you have a chance of mrtesting https://gitlab.com/postmarketOS/pmaports/-/merge\_requests/5663 ? 2024-10-02 14:02:11 PabloCorreaGomez[m]: will do, just got my chromebook back up and running, I'll test now. 2024-10-02 14:06:20 PabloCorreaGomez[m]: hey, it works, latest eudev + this mr makes things work again. 2024-10-02 14:06:43 Thanks a lot, I'm merging then! 2024-10-02 14:07:26 Awesome! Thank you for the quick turnaround. 2024-10-02 14:08:26 Jeje. I'm asking Natanael to merge those risky things the days I'm several hours in a row here exactly for this reason. So far, seems to be working out 2024-10-02 14:15:56 Gonna have to check the git log for your name next time I upgrade my edge machines ;) 2024-10-02 14:53:43 Haha 2024-10-02 14:59:37 i almost thought eudev had an update 2024-10-02 15:00:28 now im afraid of rebooting.... 2024-10-02 15:01:12 This was totally a downstream bug šŸ˜… 2024-10-02 15:01:25 alpine's side gonna come when we move mdev 2024-10-02 15:01:49 Since that one's indeed referenced by alpine's mkinitfs 2024-10-02 15:01:55 As udev is in pmOS 2024-10-02 15:02:18 I'd be very surprised if any alpine user has something as big as udev in the initramfs 2024-10-02 15:02:44 Which is dowstream mostly because android partition tables 2024-10-02 15:02:46 that would be surprising indeed :) 2024-10-02 15:03:18 what's the android partition tables peculiarity that requires udev? 2024-10-02 15:03:54 it is kind of annoying to realize that /dev in initramfs is different from the booted system the hard way, spoken as an udev user... 2024-10-02 15:04:33 skarnet: mr 5000 in pmaports 2024-10-02 15:04:46 thanks 2024-10-02 16:21:48 i trying to update fortify-headers again 2024-10-02 17:45:23 At last :D 2024-10-02 18:03:43 Gitlab has been upgrade to 17.3 2024-10-02 18:14:44 thank you! 2024-10-02 18:17:41 I was wondering do the musl patches related to chromium effect the role of the sandbox or does it work just as effectively as on glibc. <- also said on the other channels not sure what chategory this comes under 2024-10-02 18:24:40 You have to have a bit of patience, this is not some question anyone can answer 2024-10-02 18:27:20 ncopa: https://gitlab.alpinelinux.org/fossdd/aports/-/jobs/1541778 2024-10-02 18:27:25 possibly. looks like we allow a few more syscalls. we could probably deny other syscalls that musl don't need, but nobody has investigated that 2024-10-02 18:33:57 ikke: i pushed a fix for musl: 0920eac441c152c1feeeb8d04fe2930baedd8455 2024-10-02 18:34:06 not sure what version of fortify-headers 2024-10-02 18:40:02 Thanks ncopa 2024-10-02 18:40:39 but its still broken apparently 2024-10-02 18:42:20 https://build.alpinelinux.org/buildlogs/build-edge-x86/community/libindi/libindi-2.0.9-r1.log 2024-10-02 18:42:44 what patches do chimera use for fortify-headers? 2024-10-02 18:44:21 That's unrelated 2024-10-02 18:44:32 /home/buildozer/aports/community/libindi/src/indi-2.0.9/libs/sockets/select.h:190:43: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive] 2024-10-02 18:44:58 That's not the strnlen bug 2024-10-02 18:47:20 there is also https://build.alpinelinux.org/buildlogs/build-edge-loongarch64/community/networkmanager/networkmanager-1.48.10-r1.log 2024-10-02 18:47:31 and this https://gitlab.alpinelinux.org/Celeste/aports/-/jobs/1541735 2024-10-02 18:48:51 the networkmanager patch looks like it wasn't built with updated fortify-headers 2024-10-02 18:54:22 Oh, the revert is incomplete -_- 2024-10-02 18:54:32 Not tested :/ 2024-10-02 18:57:51 so fortify-headers is still broken? 2024-10-02 18:59:17 Sorry, give me a minute, it's kind of hard to test with the enforced system-wide fortify-header, need to rework a bit the setup 2024-10-02 19:01:37 It seems that the ā€œrevertā€ patch isn't a revert actually, it just modifies *some* code back, but not what the mentioned commit introduced 2024-10-02 19:01:56 Also, it missed some other instances of strnlen where it breaks C 2024-10-02 19:03:25 let me know if you have a fix. I can apply it tomorrow morning 2024-10-02 19:03:47 Just as a note, https://github.com/jvoisin/fortify-headers/ isn't the official upstream repo 2024-10-02 19:03:51 It's a development repo 2024-10-02 19:05:12 Well, IĀ don't want to interfere with jvoisin's work, I'll talk with him and see if he can push upstream directly 2024-10-02 19:13:21 ok, shared a patch 2024-10-02 20:33:04 ncopa: these https://github.com/chimera-linux/cports/tree/master/main/fortify-headers/patches but we use clang so the headers work differently 2024-10-02 22:30:42 is it the new fortify-headers networkmanager won't build with? 2024-10-02 23:52:14 not sure https://github.com/jvoisin/fortify-headers/commit/114b563adc2b942bc5abd4c5820507076d453f64 was the (right?) fix 2024-10-03 00:26:30 someone who knows anything about something would need to check me on this one https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72916/diffs?commit_id=d9312140aa375e37daec90095f2c4238925f01b0 2024-10-03 00:26:47 preferably a crescent moon source mage or other 2024-10-03 00:48:18 separate in !72919 2024-10-03 01:39:47 ok, I'll just... 2024-10-03 06:19:12 omni, it was incomplete, I already notified jvoisin yesterday, he should push the fix soon 2024-10-03 08:34:34 the FD_ISSET is broken with fortify-headers 2024-10-03 08:58:11 Sheesh 2024-10-03 13:08:51 abump -s CVE-2024-25590 pdns-recursor-5.1.2 2024-10-03 13:09:00 did not add a secfix 2024-10-03 13:09:02 am i holding it wrong? 2024-10-03 13:10:31 I don't think it supports updating the secfixes section 2024-10-03 13:10:44 oh! it affected the commit message 2024-10-03 13:10:46 got it 2024-10-03 13:11:14 nod 2024-10-03 13:22:43 yeah, i think -s was implemented before secfixes was a thing 2024-10-03 13:23:15 right 2024-10-03 13:46:46 Apparently there are still some fortify issues: https://gitlab.alpinelinux.org/fabricionaweb/aports/-/jobs/1542801 2024-10-03 13:47:32 ah yeah, that is unfortunatelly something I dont understand haha 2024-10-03 15:00:13 oh man.. the USE_NATIVE_CHECK seems to be completely broken 2024-10-03 15:01:58 the github runner for fortify-headers seems to be broken as well. It has a matrix of different gcc versions, but it seems to set a gcc binary for musl, and appears to ginore the complete matrix of ubuntu gcc versions. Running same musl gcc for each step 2024-10-03 15:02:35 it is also broken with -std=c99 2024-10-03 15:03:44 currently the gihub runner does not test it with FORTIFY_USE_NATIVE_CHK at all 2024-10-03 15:05:09 because it sets USE_NATIVE_CHK, which was renamed in https://github.com/jvoisin/fortify-headers/commit/459d202b1bbf7abb817a596ce9374edfb7b4da8f 2024-10-03 15:05:32 so the test suite does not really test much 2024-10-03 15:06:00 i feel this is so broken that I think we should probably revert the upgrade, again :-( 2024-10-03 15:09:23 this is blocking us and no response on anything yet 2024-10-03 15:20:12 ncopa: why do you care about native check stuff? musl does not have it so it's irrelevant 2024-10-03 15:20:58 i care because I want to run the tests when building package, and I want run it on each architecture we support 2024-10-03 15:21:54 i also care becase I want to run the tests on my work desktop which happens to be alpine 2024-10-03 15:22:12 and occasionally it is arm 2024-10-03 15:23:19 fortify-headers got reverted for now. will probably not have time to fix it til after 3.21 release 2024-10-03 15:23:43 and it does not seem like anyone else has the time to fix it either 2024-10-03 15:25:53 i reverted the upgrade for now 2024-10-03 15:36:05 ncopa: native check should not affect tests or whatever though 2024-10-03 15:36:18 that stuff should be always disabled on musl because musl does not have the chk funcs 2024-10-03 15:59:46 that fixed the go pipeline ncopa 2024-10-03 20:15:15 Oh that explains some stuff I was getting 2024-10-04 06:09:04 q66: aha, so FORTIFY_USE_NATIVE_CHK is useless for us 2024-10-04 07:14:25 dne, !72970 is not a security update - any reason you MRed it for 3.20? (i'm not opposed, just curious0 2024-10-04 07:19:47 It looks like a bugfix release? 2024-10-04 07:19:57 it is 2024-10-04 07:20:07 perhaps i'm unclear on backport policies in alpine 2024-10-04 07:20:38 It's not only security fixes that can be backported 2024-10-04 07:20:46 ack 2024-10-04 07:20:48 so less strict than Debian 2024-10-04 07:20:57 who will only backport bug fixes if there are loud debbug tickets ;) 2024-10-04 07:21:00 Bugfix releases are quite appropriate 2024-10-04 07:21:12 wonderful 2024-10-04 07:21:24 It's nice to be proactive 2024-10-04 07:21:37 ok, will keep that in mind 2024-10-04 07:22:49 Our principle is that users should feel safe to upgrade within a stable release 2024-10-04 07:23:27 yeah 2024-10-04 07:23:35 that's our principle too so 4.9.1 -> .2 should be safe 2024-10-04 07:23:40 Nod 2024-10-04 07:39:38 going to bump vaultwarden but I also want to change the way config files works, but will do that separately as I need to test it well 2024-10-04 07:39:57 Habbie: yeah, just nice to have the latest patch release in the current stable release (with quite small effort) 2024-10-04 08:04:22 my git is refusing to pull master changes LOL 2024-10-04 08:04:58 trying git gc 2024-10-04 08:18:30 fabricionaweb, it can sometimes take a while on aports, the master pull 2024-10-04 08:19:12 turns out was my yubi key hanging, somehow now after the sleep I need to reconnect it 2024-10-04 09:29:02 Huh, I have a package that fails to build on aarch64 due to manifest 'build.ninja' dirty after 100 tries. Is ninja broken somehow? 2024-10-04 09:30:51 and works fine on my local machine, also aarch64 šŸ¤” 2024-10-04 09:51:15 I've seen that as well in CI 2024-10-04 09:51:38 I recall it worked after retry, so something flaky 2024-10-04 12:31:01 ncopa: yes, always was and likely always will be as i don't see dalias impleemnting that 2024-10-04 12:31:18 just ignore it exists 2024-10-04 12:45:18 Hi, is this issue familar to anyone? https://gitlab.alpinelinux.org/alpine/aports/-/issues/16496 2024-10-04 12:45:22 Seems like quite a serious packaging regression which has recently affected 3.20 2024-10-04 12:45:58 PureTryOut, i just got an aarch64 failure that may be a hint for yours: tar: dnsdist-1.9.7/dnsdist.service.in: time stamp 2024-10-03 15:32:55 is 16549.735959538 s in the future 2024-10-04 12:46:03 https://gitlab.alpinelinux.org/Habbie/aports/-/jobs/1543811 2024-10-04 12:46:58 >>> dnsdist: Building community/dnsdist 1.9.7-r0 (using abuild 3.13.0-r5) started Thu, 03 Oct 2024 10:57:00 +0000 2024-10-04 12:47:21 i submitted that build 43 minutes ago :) 2024-10-04 12:47:35 hi, I generated the autotools project for APKBUILD with newapkbuild -a and after running it, it compiles properly. but it gives me a pkg folder inside my current directory. that pkg folder is pkg/sstp-client/usr/ (sstp-client is being built). how do i install all the files from the pkg/sstp-client/usr/? here's the APKBUILD file: https://paste.opensuse.org/pastes/9d21502fd8b3 2024-10-04 12:47:52 so, the clock on (that?) aarch64 builder is behind by over a day 2024-10-04 12:51:31 ikke: I've retried it like 10 times already, no luck 2024-10-04 12:51:41 but if the clock is behind, yeah that could explain things 2024-10-04 12:54:13 Time on the runner seems correct 2024-10-04 12:54:17 Fri Oct 4 12:53:44 UTC 2024 2024-10-04 12:57:32 on shared-runner (aarch64) EdbT1jxC2, system ID: r_uhTXjJKx4KiL 2024-10-04 12:58:02 now doing a new attempt on on shared-runner (aarch64) EdbT1jxC2, system ID: r_uhTXjJKx4KiL 2024-10-04 12:58:09 (so same) 2024-10-04 12:58:26 >>> dnsdist: Building community/dnsdist 1.9.7-r0 (using abuild 3.13.0-r5) started Thu, 03 Oct 2024 11:55:44 +0000 2024-10-04 12:58:32 https://gitlab.alpinelinux.org/Habbie/aports/-/jobs/1543836 2024-10-04 12:59:29 ncopa deployed an aarch64 runner, maybe that's the culprit 2024-10-04 13:49:59 hi, what did I do? 2024-10-04 13:50:17 ha 2024-10-04 13:50:28 hello VMs under macos 2024-10-04 13:50:54 time stand still when they are sleeping 2024-10-04 13:51:19 "Fixed pipeline" 2024-10-04 13:51:55 on shared-runner gitlab-runner-aarch64.che-ci-1 cL5nJ32U, system ID: r_jaiXxfQPMLsw 2024-10-04 13:55:28 i have updated the clock for now 2024-10-04 13:55:41 i dont know how to probably handle the clock in MVs 2024-10-04 13:55:47 VMs* 2024-10-04 13:59:54 Isn't there some virtio device to handle that? 2024-10-04 14:01:51 or just run NTP? 2024-10-04 14:07:35 somebody pointed out to me that that is not great for jumping clocks 2024-10-04 14:19:49 hardened-malloc seems broken after the recent updates in edge. maybe someone else can confirm 2024-10-04 14:20:56 invoked: make sure you upgrade with --available to make sure fortified-headers is properly downgraded 2024-10-04 14:21:05 i did 2024-10-04 14:21:22 (i saw the downgrade yesterday) 2024-10-04 14:36:42 i do run chrony for ntp 2024-10-04 14:36:43 for context, i have a couple instances where the user shells have LD_PRELOAD set in ~/.profile, and mostly everything fails with illegal instruction. beyond that i haven't had time to look yet. 2024-10-04 14:37:01 but i think it does not recover from sleeps because the jump is too big 2024-10-04 14:37:10 maybe I should just run sntpc 2024-10-04 14:39:01 ncopa: you can configure crony to allow it to jump 2024-10-04 14:46:00 i dont need to configure anything with sntpc hopefully 2024-10-04 14:57:35 reinitializing the clock after a reboot to get the clock closer to what it should be, so the NTP client can then resync without "time discrepancy too big" errors, is a classic workaround 2024-10-04 14:58:08 so yeah, use whatever one-time NTP client you have that will accept big jumps, *then* start chrony or whatever 2024-10-04 15:24:47 this does not happen after reboot. it happens after laptop wakes up after sleep 2024-10-04 15:25:39 but are you running aarch64 runners for gitlab on your laptop? 2024-10-04 15:25:48 yup 2024-10-04 15:25:51 ack 2024-10-04 15:26:26 and i havent figured out to prevent it from falling asleep either 2024-10-04 15:26:53 i just had a terrible realisation. for a random open source project, let's say hosted on github, finding linux arm64 CI is hard (if they don't want to spend money) 2024-10-04 15:27:02 but many projects do have that for themselves 2024-10-04 15:27:05 and abusing it is possible 2024-10-04 15:29:58 ncopa: /usr/bin/caffeinate? 2024-10-04 20:02:02 can anyone look at this update: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72674 2024-10-04 20:02:30 it will fix an issue that other members requested, i think it's good to go 2024-10-04 20:04:19 rdbo: rerunning the failed jobs, I suppose they should pass now 2024-10-04 20:04:38 nice 2024-10-04 20:05:46 yup, all green now 2024-10-04 20:07:53 sounds good 2024-10-04 20:11:20 ikke: thanks! 2024-10-05 10:17:35 Hi, I created a small package a while back in /testing and I was wondering what the process is to get it from there to /community? I believe the requirements from https://wiki.alpinelinux.org/wiki/Repositories are met. 2024-10-05 10:37:41 pu: check readme in aports 2024-10-05 10:56:02 clandmeter: I'm none the wiser, sorry... it says that packages should be moved from /testing to /community, but now how, unless I am supposed to create a MR for testing? 2024-10-05 10:56:21 community, not testing, sorry 2024-10-05 11:08:14 Create an mr 2024-10-05 11:08:36 thatā€™s the normal flow of any change in aports 2024-10-05 13:18:25 pu: to elaborate on the previous response, `git mv testing/$pkgname community/`, commit with a subject line like "community/$pkgname: move from testing" and open a MR with a matching title 2024-10-05 13:20:10 a bit late and maybe you already figured it out, but that's the basic procedure 2024-10-05 13:37:41 Thanks mio and clandmeter - currently brushing up my git-fu, will try right afterwards. 2024-10-05 13:41:35 pu: yw 2024-10-05 13:42:28 pu: np, feel free to ask if you have any other questions 2024-10-05 18:51:37 ok im done for the day with the ffmpeg 7 rebuild 2024-10-05 18:52:00 if someone wants to help, i tried to document some stuff here: https://pad.nixnet.services/i0v-WAxTTXa6PPUJBHgY1Q?both 2024-10-05 19:00:20 Thanks for the work!! 2024-10-05 20:54:14 fossdd[m]: I'm definitely interested. Thanks for sharing also I'd been wrestling with patches on ffmpeg 6 for the past few days. 2024-10-05 20:54:27 saves me some trouble there 2024-10-05 22:25:28 Seeing about firefox now 2024-10-06 06:50:18 this MR could be closed !62557 2024-10-06 06:51:27 we already have this port now 2024-10-06 07:45:00 hello, im having a weird issue when building a python package. after running abuild checksum, the hash is updated but the name of the package is not written there. it's only like this: version.zip" 2024-10-06 07:45:16 now, because of that python package is giving this error: "Project name python-openstackclient was given, but was not able to be found" 2024-10-06 07:46:01 here's the APKBUILD file: https://paste.opensuse.org/pastes/e52691e94cee 2024-10-06 07:47:47 any help would be appreciated. thanks 2024-10-06 07:53:22 ok i think it's because gitea is renaming the file with just version. is there a way to have checksum include the package name? 2024-10-06 07:54:53 sandbag: hi 2024-10-06 07:54:58 edit your builddir 2024-10-06 07:57:35 and rename your sources following wiki: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#source 2024-10-06 07:58:04 qaqland: what do i edit in builddir? 2024-10-06 08:00:31 you could rename in "source" field first and try to build 2024-10-06 08:01:43 i did, it's still the same error 2024-10-06 08:03:43 manually building it with same steps and it wasn't a problem 2024-10-06 08:16:57 sorry couldn't help you :( 2024-10-06 08:22:59 source="$pkgname-$pkgver.tar.gz::https://opendev.org/openstack/$pkgname/archive/$pkgver.tar.gz" builddir="$srcdir/$pkgname" 2024-10-06 08:26:37 qaqland: np 2024-10-06 08:27:39 psykose: the problem is that the python program requires ".git" directory which is not present while using tarball 2024-10-06 08:27:52 https://github.com/xrucka/cometblue/issues/4#issuecomment-1057353665 2024-10-06 08:29:11 i doubt it actually "needs" it 2024-10-06 08:30:03 (at least in a way that can't be patched or worked around) 2024-10-06 08:30:53 using the pypi sdist probably works 2024-10-06 08:31:32 abby: it works when i copy .git dir 2024-10-06 08:35:14 psykose: how do i use pypi sdist? 2024-10-06 12:00:34 o.o tomorrow is python 3.13 expected to be released 2024-10-06 12:01:18 Will probably too late for alpine 3.21 2024-10-06 12:03:01 yeah 2024-10-06 13:47:39 guys... i think there's an issue with `linux-edge` 2024-10-06 13:47:57 CONFIG_SECURITY_YAMA is disabled, won't that allow any process to ptrace each other? 2024-10-06 13:48:15 i didnt test yet, i'm just bringing it up 2024-10-06 13:51:56 only for same user 2024-10-06 13:52:01 but yes 2024-10-06 13:52:25 sounds a bit troublesome... i only noticed this bc i use a custom kernel, based from linux-edge 2024-10-06 13:52:50 and i noticed that i was being able to attach to any process created by my user with gdb, even though i wasn't running as root 2024-10-06 13:52:53 yama.ptrace_scope only allows for process children to be traced (for same user) 2024-10-06 13:52:58 most basic protection ever 2024-10-06 13:53:26 there are some other security stuff that dont match linux-lts, maybe should take a look at that as well 2024-10-06 13:53:48 you're not the first 2024-10-06 13:54:45 '-edge doesnt match -lts' is a recurring meme 2024-10-06 13:55:17 which is annoying because there's no latest-stable that is just the lts config but on the latest kernel 2024-10-06 13:56:30 i thought the configs were copied, but diff kernel version XD 2024-10-06 13:57:14 maybe the security still should match at least 2024-10-06 13:57:38 rdbo: Please open an issue on gitlab 2024-10-06 13:58:45 alright, will do 2024-10-06 13:58:46 there basically already is one in https://gitlab.alpinelinux.org/alpine/aports/-/issues/13588 2024-10-06 14:08:04 i created a separate issue since that one talks about landlock specifically: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16502 2024-10-06 14:11:46 fossdd[m]: Been running some builds on ffmpeg just so you can maybe just do a bump on them. Is just checking it off on the hedgedoc like I did a good way to keep you up to date? 2024-10-06 14:13:17 yeah sure. you can also add a comment there if there is something required 2024-10-06 14:16:34 Gotcha thanks 2024-10-06 15:36:33 anyone know how i can get a hold of mps? just wondering how to progress https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72477 2024-10-06 15:37:02 mail him? 2024-10-06 15:37:10 /whois mps 2024-10-06 15:37:21 lotheac: ftr, mps prefers issues over MRs 2024-10-06 15:37:49 (in the case of kernels) 2024-10-06 15:38:16 ikke: thanks. from history i could see that he wants to do the config changes by him/herself 2024-10-06 15:38:43 or any other amount of pronouns... sorry for my bad english 2024-10-06 15:51:33 lotheac, 'themselves' always works here 2024-10-06 15:52:23 you're right 2024-10-06 15:53:38 anyway, i sent them a mail. thanks y'all :) 2024-10-06 22:05:32 how I forgotten where to find the list of flagged packages? 2024-10-06 22:08:42 is the list removed because you're no longer allowed to manually flag aports? 2024-10-06 22:17:41 omni: there's a dropdown menu to filter for flagged state 2024-10-06 22:18:08 2nd last dropdown "All" from the right 2024-10-06 22:21:31 (and press "Search" to apply) 2024-10-06 22:43:16 ikke: ehh i guess you still have to press the trigger button for gitlab-tf? 2024-10-06 22:43:20 just a reminder :D 2024-10-06 22:49:31 mio: right, thanks <3 2024-10-06 23:38:24 :) 2024-10-07 08:44:41 Can someone advise me about how long it takes a patch merged into master to get backported into the 3.20 branch? 2024-10-07 08:48:54 that might depend a lot on whether you submit that backport i think :) 2024-10-07 08:51:18 I will happily do so if that is the workflow 2024-10-07 08:51:30 Do I just cherry-pick a commit onto a branch? 2024-10-07 08:51:58 that's how i do backports, yes 2024-10-07 08:52:07 note that i'm not with alpine, don't know what patch you mean, and can't tell you if it would be merged at all 2024-10-07 08:53:09 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73005 2024-10-07 08:53:14 !73005 2024-10-07 08:53:28 It is a regression in 3.20, so I am fairly confident it will be merged 2024-10-07 08:53:36 makes sense to me yes :) 2024-10-07 08:54:08 when a flat tar.gz (theres no folder) is extract direct into $srcdir how can I add it to a folder LOL 2024-10-07 08:54:19 I really thought it would create a dir 2024-10-07 08:54:39 MatthewPickering[m], i don't know if they'd want the gcc 14 fix too, but you'll find out :) 2024-10-07 09:02:16 interesting...the build-aarch64 gave me: 2024-10-07 09:02:17 ERROR: Clock skew detected. File /usr/bin/python3.12 has a time stamp 172049.0774s in the future. 2024-10-07 09:02:28 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1547154 2024-10-07 09:05:31 was that last week? 2024-10-07 09:05:46 ncopa, your clocks have slept again i think 2024-10-07 09:05:58 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73125 2024-10-07 09:06:03 Hope that looks right to people 2024-10-07 09:06:27 MatthewPickering[m], seems right 2024-10-07 09:09:35 I think we use different format for the title, but someone would fix if is the case, thanks for the patch 2024-10-07 09:10:58 And then once the patch is in the 3.20-stable branch, how long does it take until that is accessible to 3.20 users? 2024-10-07 09:12:13 Im not sure when the pipelines runs for this case, but it doesnt take longer 2024-10-07 09:18:42 thanks, I was wondering if there were lots more steps or not. 2024-10-07 10:51:00 fossdd[m]: It has been applied now, I needed to fix authentication 2024-10-07 11:30:01 thanks! 2024-10-07 11:50:56 Could anybody with permissions add to the /usr merge milestone (https://gitlab.alpinelinux.org/groups/alpine/-/milestones/16) the following 2024-10-07 11:51:00 https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/14 2024-10-07 11:51:06 https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/issues/60 2024-10-07 11:51:11 https://gitlab.alpinelinux.org/alpine/cloud/tiny-cloud/-/merge_requests/119 2024-10-07 14:09:20 Would be good to have llvm19 done this week. Anyone has time to work on that? 2024-10-07 15:15:18 I started on llvm19: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73161 2024-10-07 15:58:42 ptrc: you fixed the llvm mess last time. Do you think we we should create separate lld19, llvm-runtimes19, wasi-*19 packages? or do we continue with the current approach? 2024-10-07 15:59:15 i'm gonna put it into slightly different words: we should make sure we aren't mixing versions between llvm components 2024-10-07 15:59:21 as in, clang 19 with lld 18, etc. 2024-10-07 15:59:38 how we achieve that doesn't really matter that much 2024-10-07 16:05:02 any suggestion how we do that? 2024-10-07 16:30:47 i'd say the cleanest option is to indeed have a separate package per version for every llvm thing 2024-10-07 16:30:55 actually 2024-10-07 16:31:33 can we build lld as a subpackage of llvm 2024-10-07 17:14:12 maybe we should just use the 130MB source taball and build all in one go 2024-10-07 17:24:30 is ffmpeg up to date? caught an error about v4l2 while rebuilding it with libplacebo 7 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1547997 2024-10-07 17:28:28 please correct me if I'm wrong in !73164 2024-10-07 17:34:45 is ffmpeg up to date? > no, but there is a open MR from fossdd !73024 2024-10-07 17:35:36 yeah still need to patch some packages and upgrade vulkan-headers, then hopefully good to go 2024-10-07 17:35:44 im not 100% sure the issue is due to libplacebo 7 2024-10-07 17:36:16 fossdd[m]: fwiw you can probably update only the VK headers 2024-10-07 17:38:22 interesting 2024-10-07 17:41:02 i guess your build failure is due to gcc 14? 2024-10-07 17:44:46 you could probably upgrade to 6.1.2 to fix it quickly until my ffmpeg 7 mr is ready 2024-10-07 17:46:39 i dont mind waiting, its just libplacebo 2024-10-07 17:47:31 alr 2024-10-07 17:47:37 i got a "one or more package are out of date" from release-monitor so im going through it 2024-10-07 18:38:33 could I get permissions on Alpine's gitlab to self-assign issues? we're working through stuff required for /usr merge and it would be nice to know if an issue is 'taken' by someone else already :) 2024-10-07 18:39:51 hm, afaict the Reporter role should be enough to change assigned users 2024-10-07 18:39:55 ikke: ^ 2024-10-07 18:40:04 Done :P 2024-10-07 18:40:09 ( btw, who else has admin access to GitLab? ) 2024-10-07 18:41:01 Natanael, Carlo, Timo, Kaarle 2024-10-07 18:41:38 oh, that's plenty 2024-10-07 18:41:45 i didn't realize that 2024-10-07 18:42:45 ikke: is that only for pmaports or all projects? (some of the issues are in other things like mdev-conf, and so on) 2024-10-07 18:42:53 hah... aports... 2024-10-07 18:43:00 Hmm, for now just for aports 2024-10-07 18:43:07 can do other projects later, similar to PabloCorreaGomez[m] 2024-10-07 18:43:29 ah ok. np, no rush. I think most stuff is in aports. thanks! 2024-10-07 19:13:42 Could https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10154 be assigned to me (I can't seem to self-assign) and added to the usr-merge milestone? 2024-10-07 19:14:17 done 2024-10-07 19:14:46 šŸ‘ļø 2024-10-07 19:43:48 ikke: the abuild CI doesn't seem to be functioning. None of the jobs are being picked up by runners 2024-10-07 19:45:31 Instance runners were disabled in your fork 2024-10-07 20:15:13 Oh, huh 2024-10-07 21:14:59 mick_ibm: I'm working on llvm 19 and there are a few tests that fails on ppc64le. Do you think you could help with those? https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1548401#L3757 2024-10-07 21:17:43 >>> main/llvm19: build failed 2024-10-07 21:17:43 >>> main/spirv-llvm-translator: build failed 2024-10-07 21:17:43 >>> main/clang19: build failed 2024-10-07 21:17:45 >>> main/libclc: build failed 2024-10-07 21:17:47 >>> main/llvm-runtimes: build fa 2024-10-07 21:18:00 opps that paste did not work properly 2024-10-07 21:18:41 Failed Tests (4): 2024-10-07 21:18:41 LLVM :: tools/dsymutil/X86/DWARFLinkerParallel/odr-string.test 2024-10-07 21:18:41 LLVM :: tools/dsymutil/ARM/DWARFLinkerParallel/accel-imported-declarations.test 2024-10-07 21:18:41 LLVM :: tools/dsymutil/X86/DWARFLinkerParallel/odr-predictable-output2.test 2024-10-07 21:18:41 LLVM :: tools/llvm-dwarfutil/ELF/X86/dwarf5-loclists.test 2024-10-07 21:19:00 At least see if they are reported upstream 2024-10-07 21:19:23 with the llvm18 we simply disabled the ARM and X86 targets on ppc64le 2024-10-07 21:20:38 i suppose we could do that for llvm 19 as well, but it would be good to fix the issues if possible 2024-10-07 21:22:18 so this is the output from an aports build of llvm package (on ppc64le)? i just wanna make sure i understand so i can reproduce on my power box. bumping up teh version to 19? 2024-10-07 22:12:23 just in case: does abuild provide an environment variable telling the building script how many cpus the build has access to? (so I can use e.g. "make -j$NTHREADS") 2024-10-07 23:04:21 skarnet: $JOBS ? 2024-10-07 23:04:43 abuild sets that to the output of ncpus 2024-10-07 23:04:49 err, nproc I mean 2024-10-07 23:20:29 craftyguy: will try, thanks 2024-10-07 23:21:03 weird that JOBS doesn't appear anywhere in /usr/bin/abuild though 2024-10-07 23:25:01 it's in usr/share/abuild/functions.sh 2024-10-07 23:26:33 that's sourced by abuild 2024-10-07 23:27:03 oh, right, I forgot to look there. Thanks! 2024-10-07 23:31:21 yw :) 2024-10-08 04:17:35 this "/usr merge", that had totally passed me by until it started to happen, would that, amoung other things, mean that /bin, /sbin and /usr/sbin would be symlinks to /usr/bin ? 2024-10-08 04:17:54 just trying to mentally adjust to these ideas 2024-10-08 04:19:45 I've now read arguments like "doing what other distros do" and "what freedesktop.org suggests" 2024-10-08 04:25:26 it's probably a bit late now, but although moving things around may make things easier for some users, it may make it harder for others 2024-10-08 04:29:14 and where a bin/ is located, if there's one or several, I don't think I care too much about, as long as I have them in my $PATH 2024-10-08 04:31:40 and if I want to know where something in my $PATH is I'll do `which thing`, or other, and if I want to know what owns it I'll do `apk info -W $(which thing)` etc 2024-10-08 04:32:28 well, I should have left the keyboard hours ago, so ttyl :* 2024-10-08 07:42:56 omni: we talked yesterday that we should write a blog post. So this is very good input, I'll try to answer those questions :) 2024-10-08 08:56:11 omni: yes that's what it would mean. And since `/usr/bin` is already in your $PATH, it'll all be in there 2024-10-08 09:04:13 question about versioned dependencies 2024-10-08 09:04:20 I think it will take a bit of time for this to sink in, and I have some reading up to do 2024-10-08 09:04:54 but I don't have any modern arguments against it 2024-10-08 09:05:05 what I've thought of so far 2024-10-08 09:05:06 which is correct: makedepends="scuda-malloc~19" or makedepends="scuda-malloc=~19" ? 2024-10-08 09:06:41 we have a comunity/biber that has depends="biblatex~3.20 ..." 2024-10-08 09:07:41 and community/qalculate-gtk that has makedepends="libqalculate-dev=~${pkgver%.*}" 2024-10-08 09:07:56 so is it ~ or =~ ? 2024-10-08 09:10:17 now you brought up a third 2024-10-08 09:10:27 or, no? 2024-10-08 09:10:58 I found a third, ~= 2024-10-08 09:11:23 that is more common in APKBUILD files than =~ (that is rare) 2024-10-08 09:12:58 we should add a check in abuild for that 2024-10-08 09:13:06 but i dont know which is the correct :) 2024-10-08 09:13:13 and i cannot find the docs eit her 2024-10-08 09:14:26 i found the doc 2024-10-08 09:15:22 https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/doc/apk-world.5.scd?ref_type=heads#L60 2024-10-08 09:59:56 heads up: I'm renaming the term "sanitycheck" in abuild to "validate" 2024-10-08 10:01:51 ncopa: just ~ is the canonical form 2024-10-08 10:02:06 yup, i figured 2024-10-08 10:02:09 apk kinda accepts all of them though 2024-10-08 10:02:44 i think we should be consistent, so I'm thinking of adding validation of that in abuild 2024-10-08 10:03:27 I wonder if we should also update APKBUILD(5), perhaps with reference to apk-world(5) at at least "depends", under Optional Variables, that's where I looked 2024-10-08 10:04:28 yeah 2024-10-08 10:04:30 good idea 2024-10-08 10:05:04 as is adding validation of it in abuild =) 2024-10-08 10:05:27 so it can be fixed as upgrades/bumps happen 2024-10-08 10:05:45 yup 2024-10-08 10:11:10 PabloCorreaGomez[m], PureTryOut: it was #16454 that really got my attention, I first read it as /etc/os-release would be removed, but as long as there is always a symlink to a file with proper information I think I have no objections to the move 2024-10-08 10:12:23 my question is what happens when /etc/os-release has local modifications, and an upgrade replaces it with a symlink? 2024-10-08 10:12:43 if the upgrade contains a file, the file will be installed as /etc/os-release.apk-new 2024-10-08 10:12:54 but what happens when upgrade contains a symlink 2024-10-08 10:13:00 oh 2024-10-08 10:13:13 i suppose we just have to test 2024-10-08 10:14:28 when would you make local modifications to /etc/os-release, though? 2024-10-08 10:15:09 thats a different question, and yeah i don't it will affect many 2024-10-08 10:15:22 but we need to know what to tell the one person doing so :) 2024-10-08 10:15:30 } 2024-10-08 10:16:05 "but why" is a good answer 2024-10-08 10:16:19 (don't think I fully read the issue I referenced above, btw) 2024-10-08 10:21:29 also can't help but think "why not move /usr/*bin/ to /bin/?" ;) 2024-10-08 10:23:56 note that this is not a bin / sbin merge, /usr/{,s}bin both still exist 2024-10-08 10:24:23 The idea is that you can have a system where everything that apk needs to manage is in /usr/* 2024-10-08 10:24:59 that kinda makes sense 2024-10-08 10:26:27 also thinking of it as someone coming from other Unices, mainly FreeBSD and DragonflyBSD, where you have the "base" system install and then packages installed through ports (or nowadays also binary packages) goes into /usr 2024-10-08 10:26:58 there you also have /usr/etc 2024-10-08 10:27:44 and for additional things, installed manually and not through base or ports, go under /usr/local 2024-10-08 10:28:20 Not many linux systems make the first distinction 2024-10-08 10:28:20 but for alpine, what would be outside of /usr then? :D 2024-10-08 10:28:45 /tmp ? 2024-10-08 10:29:03 /boot, /var, /etc, virtual filesystems 2024-10-08 10:30:12 but apk manage things under /boot and /etc :p 2024-10-08 10:33:59 i have some legacy systems, where / is seperate partition from /usr and recently i have a lot of work with copying everything that initrd needs before mount -a int the /usr of / 2024-10-08 10:34:31 mostly modprobe,mount,fsck shared deps, and some of /usr/lib/rc/ 2024-10-08 10:36:12 bOR38552MJA: that is interesting. did it actually work to have /usr as a separate partition? 2024-10-08 10:37:04 since ever 2024-10-08 10:37:15 well not since a few years 2024-10-08 10:37:24 I think I too have run alpinelinux like that in the past, before I moved to zfs 2024-10-08 10:37:43 i think i read somewhere some time ago that it is not possible to have spearate /usr in modern linux systems anyway 2024-10-08 10:37:43 since iported zfs to musl/grsec my appetite for zfs diminished. 2024-10-08 10:38:28 well, good, these are not modern linux systems, they are all at least a decade old. ;) 2024-10-08 10:38:29 the claim was also that it is not possible to have a modern linux system with less than 500MB IIRC 2024-10-08 10:38:53 hehe 2024-10-08 10:38:55 I think those claims came when systemd did the /usr merge first time 2024-10-08 10:39:26 i think that it is not possible now is due to the /usr merge for systemd systems back then 2024-10-08 10:39:35 but then again, why would you want separate /usr? 2024-10-08 10:40:22 maybe not in the future, seeing how much trouble that is (although i believe uneccessary), but my old systems i'm not gonna reinstall because of this. 2024-10-08 10:40:37 and I remember having issues when archlinux switched to systemd, not only because of separate /usr though 2024-10-08 10:42:15 so every 1-2 years i repeatedly boot into init=/bin/sh, mount my usr into /mnt and copy files until the normal boot doesn't complain about missing symbols and fails. then it works for quite some time until one of the deps is updated and the cycle repeats, but most of these deps are quite mature, so this happens not so often. 2024-10-08 10:43:07 what are the typical things you need to copy over? 2024-10-08 10:43:26 with alpine 3.21 that will be significantly different 2024-10-08 10:43:31 as said the shared libs of modprobe,fsck,mount and most of /usr/libexec/rc 2024-10-08 10:43:45 ok 2024-10-08 10:43:49 from the top of my head libuuid libkmod libblkid libcrypto libz 2024-10-08 10:44:10 i'm on edge btw so dunno how much 3.21 affects me 2024-10-08 10:44:19 probably it already did. 2024-10-08 10:44:34 I saw an MR which proposed to mount /usr from initramfs 2024-10-08 10:44:37 if needed 2024-10-08 10:44:42 and probably that is why i had to do this dance just a few weeks ago. 2024-10-08 10:44:46 oh nice! 2024-10-08 10:45:02 yeah, thats why you need to do this dance 2024-10-08 10:45:22 i just didnt think that there was any installs with /usr as separate partition 2024-10-08 10:45:34 I did :D 2024-10-08 10:45:56 what about all those old installs that predate this newfangled fashion? 2024-10-08 10:46:09 we need find a way to handle those 2024-10-08 10:46:17 i think the mount /usr from initramfs will help 2024-10-08 10:46:33 but it also means we need to think how to do the fsck for those 2024-10-08 10:47:04 hmmm. true. 2024-10-08 10:47:11 i have seen suggestions that we should do fsck from initramfs 2024-10-08 10:47:27 well, how do you do fsck for /? 2024-10-08 10:47:29 since it is only ext4 that support do fsck online on readonly 2024-10-08 10:47:38 we mount it read-only early boot 2024-10-08 10:47:41 from initramfs 2024-10-08 10:47:49 i see, that could also work for /usr 2024-10-08 10:47:49 ext4 supports fsck on ro mounted 2024-10-08 10:47:52 yes 2024-10-08 10:47:56 but it only works for ext4 2024-10-08 10:48:00 afaik 2024-10-08 10:48:20 well, then it also only works if / is ext4 2024-10-08 10:48:21 andy yes, that is a good idea 2024-10-08 10:48:24 yes 2024-10-08 10:48:38 that is why i have seen suggestions on move that logic to initramfs 2024-10-08 10:48:50 and that it the current tendency: move everything to initramfs 2024-10-08 10:48:51 so then this solves the problem of / being !ext4 2024-10-08 10:48:58 yup 2024-10-08 10:49:50 i am slightly skeptic to this tendency of moving everything to initramfs 2024-10-08 10:49:53 it used to be simple 2024-10-08 10:50:06 agreed. 2024-10-08 10:50:08 the one and only task initramfs had was to mount the root fs 2024-10-08 10:50:24 now it is slowly getting more and more responsibility 2024-10-08 10:50:35 for me it would also work if the fsck/mount/modprobe stuff would be selfcontained on / 2024-10-08 10:50:52 and the openrc stuff that is needed before / mounts the rest 2024-10-08 10:50:57 yes, that was the old (current) thinking 2024-10-08 10:51:21 but it is not, now. on edge 2024-10-08 10:51:30 correct. due to /usr merge 2024-10-08 10:51:56 which again gives other benefits. it is sort of nice to have everything apk manages under /usr 2024-10-08 10:51:59 and thats it 2024-10-08 10:52:51 static fsck/modprobe/mount could also be a solution. or using busybox mount instead of /bin/mount 2024-10-08 10:53:30 static on / i mean 2024-10-08 10:54:21 btw are kernel mods and fw now also on /usr? 2024-10-08 10:54:23 i think mounting /usr from initramfs is what will happen 2024-10-08 10:54:28 will move there yes 2024-10-08 10:54:57 interesting. and probably also a problem for legacy systems 2024-10-08 11:55:42 which again gives other benefits. it is sort of nice to have everything apk manages under /usr 2024-10-08 11:55:43 What about /etc? 2024-10-08 11:56:30 And while perhaps sort of nice, what tangible benefits does it have? 2024-10-08 12:04:09 Hello, I'm trying to build a program which need a yarn build for its frontend. I stumbled on this error when fetching the dependancies. What I understand is that the pre-built binaries don't exist so it tries to build it itself, but its failing for some reason. Here is the log of the yarn step https://termbin.com/lntz 2024-10-08 12:16:53 humm: it may open up for doing file system snapshots before upgrade, and be able to rollback via filesystem revert 2024-10-08 12:22:56 you may need to build it from source raspbeguy, there is an env that you can use to force build it, try to see if it works for you 2024-10-08 12:24:05 fabricionaweb, well, that's precisely what it's trying to do already 2024-10-08 12:24:58 try the env "npm_config_build_from_source=true" for yarn 2024-10-08 12:25:56 ncopa: I see; for that, you just need all files managed by apk on one file system, not necessarily on /usr, right? 2024-10-08 12:26:06 s,on,in, 2024-10-08 12:28:04 fabricionaweb, I found this comment https://github.com/yarnpkg/yarn/issues/3507#issuecomment-304446339 which indicated that its using a bundled version of node-gyp. Trying what it says. 2024-10-08 12:46:16 seems to be working 2024-10-08 13:07:39 is there a way to specify a custom /etc/apk/repositories when using abuild rootbld ? I have a packages cache on my infra and I'd like abuild to use it 2024-10-08 13:25:31 raspbeguy: check .rootbld-repositories in each aports repo dir 2024-10-08 13:26:45 also, the `mirror` env is overridable 2024-10-08 13:26:54 as in, it takes the environment variable if it's set 2024-10-08 13:27:48 ikke, after reading https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2550 I tried so export a environment variable named mirror and apparently that does the trick 2024-10-08 13:27:50 e.g. i have an `export mirror=/var/lib/mirror` set in my .zshrc 2024-10-08 13:28:00 damn, i was too late :p 2024-10-08 13:28:37 ptrc, thank you too ā¤ļø 2024-10-08 13:29:18 I'll try the .rootbld-repositories way, can be more fit to me maybe 2024-10-08 13:37:49 ncopa bOR38552MJA: the patch for mounting /usr from initramfs is already merged: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/178 2024-10-08 13:38:21 And the question I have for bOR38552MJA why are / and /usr two separate partitions? 2024-10-08 13:39:04 Are so because of the very old rationale from the FHS (coming from the 80s?) that / does not have enough space to hold the system? 2024-10-08 13:41:36 it has saved my ass a few times that the partition/slice for / still had free space available when /usr got filled for whatever reason 2024-10-08 13:41:48 That rationale still applies. / does not grow faster than inflation. /usr does. 2024-10-08 13:41:53 with / holding system essentials and /usr not 2024-10-08 13:43:12 and I have been bitten when they have not been separate, although not in a long time 2024-10-08 13:47:04 last time I had a system disaster due to filling disk wasn't related to / and /usr not being separate, it was when I still was a QubesOS user and their choice of using LVM thing provisioning bit me, my daily driver wouldn't boot and I had to spend a few days to salvage as much data as I could 2024-10-08 13:47:40 then I switched to alpine also for desktop use, and after some time I started contributing 2024-10-08 13:55:14 i had a very similar thing happen with qubes 2024-10-08 13:58:41 in my case i assumed i shot myself in the foot making changes to dom0, didn't have time to rca it, went back to gentoo (at that time) 2024-10-08 13:59:12 i am slightly skeptic to this tendency of moving everything to initramfs 2024-10-08 13:59:20 you should be fully skeptic 2024-10-08 13:59:36 you know how this tendency ends 2024-10-08 13:59:54 soon we'll have full systems on initramfs and we'll need an initramfs to mount the initramfs 2024-10-08 14:00:16 just like some machines have Linux in their bootloader 2024-10-08 14:00:30 this is just bonkers 2024-10-08 14:01:02 the question should always be "what is the exact benefit of doing this" 2024-10-08 14:09:08 omni: the problem with defining system essentials is that nobody has a definition for it. It depends on every setup 2024-10-08 14:10:24 Also, simple rootfs on initramfs + everything under /usr is not very different to minimal initramfs, "system essentials" in /, the rest in /usr 2024-10-08 14:10:50 Depends on the perspective, maybe it's even simpler 2024-10-08 14:11:13 the difference is that initramfs is more difficult to access and modify than / 2024-10-08 14:11:27 it's hidden from the user at run time, essentially 2024-10-08 14:12:14 PabloCorreaGomez[m]: definition of system essentials: enough to bring up tty access, recover/replace failed disks, possibly network to pull in backups. Nothing more. 2024-10-08 14:13:28 Right, and that's HW/setup dependent. Which means either everybody tailors to their needs (not trivial, since you cannot change binaries from place trivially without rebuilding things), or it's wrong in most setups 2024-10-08 14:13:36 network access to pull in backups is bloat 2024-10-08 14:13:45 more like system fatssentials 2024-10-08 14:13:51 see? nobody agrees on the definition :p 2024-10-08 14:13:58 Thank you 2024-10-08 14:42:34 :B 2024-10-08 14:49:08 I also have this weird ass setup, not everywhere, where I have root on zfs but boot with syslinux, that doesn't know about zfs, so I need to have a separate /boot, that separate /boot is ext4 on md raid mirrored with a zvol on the same zpool as the rootfs dataset, so that I can do synchronized snapshots and rollbacks of /boot and the rootfs 2024-10-08 14:50:23 not separate /usr there either, but what I want to say is that you don't need to merge / and /usr to be able to do snapshots and rollbacks, and that cannot be true only for zfs 2024-10-08 14:57:23 omni: I agree with what you're saying, but your setup is indeed weird :D most people would just get a minimal initramfs to load the zfs modules so your kernel can boot your zfs root partition. (That's one of the legit uses of initramfs!) 2024-10-08 14:57:50 the fact that you want to keep your / and your booting partition in sync is what makes it more difficult. 2024-10-08 14:59:32 yeah, I don't ask anyone to support my particular setup I described above, but I had ideas on how and why I wanted to do that and it has been working for years 2024-10-08 15:00:03 although I also have a couple of systems where I use zfsbootmenu that is pretty neat 2024-10-08 15:00:33 which reminds me of how terribly I have packaged testing/zfsbootmenu 2024-10-08 15:01:41 where I actually use it I have loosely folowed https://docs.zfsbootmenu.org/en/v2.3.x/guides/alpine/uefi.html 2024-10-08 15:02:21 there you also have /usr/etc < This is on Linux too BTW. OpenSUSE already has it and started moving packages' "upstream default" configs to it. Fedora too, I think 2024-10-08 15:03:09 let's recon usr as UpStReam 2024-10-08 15:03:40 Arnavion: where do I have /usr/etc? 2024-10-08 15:04:20 oh, right 2024-10-08 15:04:26 it was a quote 2024-10-08 15:05:38 I first thought it was a comment zfsbootmenu 2024-10-08 15:09:09 but I assume that OpenSUSE doesn't have a separate /etc and /usr/etc (and /usr/local/etc) for if things belong to some notion of "base" or are installed through a package manager (or other, /usr/local) 2024-10-08 15:09:40 Right, it's not a separation of base vs ports. It's just a separation of system-managed vs administrator-managed 2024-10-08 15:10:21 so they do have a separation of /etc and /usr/etc? 2024-10-08 15:10:25 Yes 2024-10-08 15:11:25 /usr/etc is for system-package-provided configs, ie the upstream default configs for a particular package. /etc is for custom configs that the administrator writes. Or that is the goal anyway; only a few packages have started putting their default configs in /usr/etc so far, as I said 2024-10-08 15:12:25 oh, in that order 2024-10-08 15:12:46 Most put them in /usr/share nowadays afaik, things like Pipewire 2024-10-08 15:13:27 /usr/share is datadir, /etc or /usr/etc is sysconfdif. It depends on what the package wants 2024-10-08 15:13:32 sysconfdir* 2024-10-08 15:14:43 Also different semantics. /usr/share contains an example for people to read, and the software itself doesn't actually read it but just has the same defaults hard-coded in its binary. With /usr/etc the software actually reads the file to populate the defaults 2024-10-08 15:14:44 uhm.. could we not have --sysconfdir=/usr/share ? 2024-10-08 15:15:16 ...why would you want that? 2024-10-08 15:15:23 We still want the software to read /etc 2024-10-08 15:15:24 I wasn't saying we should šŸ˜‰ Just that some packages (and more and more nowadays) treat /usr/share as such upstream, like Pipewire. 2024-10-08 15:15:55 And yes /etc should always be read still, that's how a system administrator overwrites a distro default 2024-10-08 15:15:58 sorry, I mixed up who was writing what 2024-10-08 15:17:04 didn't read properly at all, I see now, scratch my sysconfigdir comment :D 2024-10-08 15:17:06 Arnavion: fact is that some packages already read `/usr/share` rather than just having it as an example. I mention Pipewire as an example but there are more and so far to me it seems preferred by people over `/usr/etc`. 2024-10-08 15:17:24 Yeah I guess there'll be exceptions either way 2024-10-08 15:17:41 PureTryOut: either those are files that shouldn't be edited by the user or the package is doing it wrong 2024-10-08 15:18:02 They shouldn't be edited by the user, indeed. If someone wants to overwrite it they copy it to /etc 2024-10-08 15:18:07 (This is /usr/etc on my OpenSUSE system https://paste.rs/6gY7U ) 2024-10-08 15:18:23 The distro is the only one that's supposed to touch config files in /usr/share 2024-10-08 15:28:55 The /usr/etc is an interesting concept. I wonder what will be result when we discuss it in the context of the FHS 2024-10-08 15:29:40 In a way, specially seeing what Arnavion you sent, it feels like a workaround for packages that have a single source of truth for configuration 2024-10-08 15:30:30 Most stuff nowadays can indeed fetch and merge configuration from /usr/share 2024-10-08 15:30:41 Slackware has /usr/man and /usr/doc rather than /usr/share/ :P 2024-10-08 15:31:03 But given FHS was abandoned and there's no cross-distro cross-project discussion on these things, everybody does whatever 2024-10-08 15:31:15 So even one for argument to try to come up with something useful out of it 2024-10-08 15:31:45 Upstreams seem very confused about this whole thing, and I totally would too 2024-10-08 15:32:04 Good news is there's both the autotools maintainer and a SUSE person involved 2024-10-08 15:33:02 orbea: I guess everything has a rationale, but that was in the spec for way longer, so that's possibly just not caring 2024-10-08 15:33:37 iirc slackware was doing that before it was more standardized 2024-10-08 15:33:43 it feels like a workaround for packages that have a single source of truth for configuration < The ideal is that software follows UAPI config spec which specifies the separation of OS vendor, sysadmin and ephemeral configs 2024-10-08 15:33:48 and it just stayed that way, if its not broken don't fix it 2024-10-08 15:34:19 So it's not a "workaround" for packages that only read one file. Even if a package reads /usr/etc, it is expected to read /etc first and only read /usr/etc as a fallback 2024-10-08 15:34:52 otherwise the whole point of "sysadmin can override OS vendor config" doesn't work 2024-10-08 15:35:50 Yes, what I meant is that a lot of software already does that with something under /usr/share 2024-10-08 15:36:17 What UAPI config spec does *not* specify is what the directory for "OS vendor config" should be, or even if it should be consistent. That's why you have some software reading /usr/etc, some reading /usr/lib (systemd), some reading /usr/share, ... 2024-10-08 15:37:00 True, also with /usr/lib xD 2024-10-08 15:37:30 I mean, this was the whole rationale why we moved /etc/deviceinfo to /usr/share in pmOS 2024-10-08 15:38:38 OpenSUSE started a library libeconf with the hope that it would standardize this but barely any software uses it, and its API is also too restrictive to be useful generally anyway (it requires the config file to be INI-like) 2024-10-08 15:39:53 But yes, either way, the goal is to have distro-provided files under /usr regardless of whether they're binaries or data or configs, and that works regardless of whether it's /usr/etc or /usr/share 2024-10-08 15:45:31 it sure is ironic that system-provided stuff go in the old user directory 2024-10-08 19:34:22 so a few months ago i introduced OpenPaX patch set to Alpine (see testing/linux-openpax) which restores PaX functionality. but we removed the PaX markings because they were cumbersome. 2024-10-08 19:35:01 i want to restore the PaX markings in a way that is easier to maintain. my thinking is to do something similar to Arch Linux's paxd here, but with a directory tree instead of a single config. 2024-10-08 19:35:26 problem is... if you add a PaX marking to a binary, `apk audit --system` will highlight that 2024-10-08 19:35:41 do we actually *care* about that though? 2024-10-08 19:35:58 maybe we teach apk-tools to ignore pax markings 2024-10-08 19:36:18 (my thought was to relabel the pax markings with an apk trigger) 2024-10-08 20:15:27 I'm puzzled, why is this suddenly now causing issues: https://gitlab.alpinelinux.org/andar1an/aports/-/jobs/1550055#L39 2024-10-08 20:15:57 The config is injected in the APKBUILD, but already since 2023 2024-10-08 20:19:42 ikke: are you referring to 9c497fa68472? that appends to an existing RUSTFLAGS, so it kinda seems like the env doesn't include RUSTFLAGS. in times like these, I throw a "export" into the APKBUILD :P 2024-10-08 20:20:06 craftyguy: yes, it tries to extend RUSTFLAGS, but it's not defined 2024-10-08 20:21:03 In our CI, we use `set -u`, so it would error out on unreferenced variables 2024-10-08 20:21:09 but that has been the case for years 2024-10-08 20:21:46 ya makes sense 2024-10-08 20:22:15 hmm, I think I know what changed 2024-10-08 20:23:08 Though, not sure why it suddenly now pops up 2024-10-08 20:23:34 what did you find? 2024-10-08 20:24:03 Our CI started sourcing /usr/share/abuild/default.conf in addition to /etc/abuild.conf to find the value of JOBS 2024-10-08 20:24:17 to get rid of a warning in a subshell 2024-10-08 20:24:26 (due to JOBS being moved to default.conf) 2024-10-08 20:25:41 https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/commit/ada28fa9764df8d29f9a6232730d7d30bcc97938 2024-10-08 20:43:28 tbh, I've never been a fan of neither SUSE nor RHEL (or derivatives), so I'm not too keen on the idea of looking there for guidance 2024-10-08 20:43:45 of course I'm aware of a lot of good software that comes out of those too, just not how to build or package an operating system 2024-10-08 20:44:56 I've enjoyed alpine as somewhat of an, still linux based, antithesis to those in some regards 2024-10-08 20:50:42 it's good to look at them for inspiration and reflection about what good policies are, why they made the choices they made and where they can be improved 2024-10-08 20:50:54 blindly following them is a different thing 2024-10-08 20:51:38 yes, I'm not saying not to look at them at all, and I chose the word "guidance" over "inspiration" in what I wrote 2024-10-08 20:52:48 yes :) 2024-10-08 20:54:51 I agree and enjoy alpine in the same way. 2024-10-08 21:02:17 and I'm sure that SUSE/RHEL etc are great for many people and organizations for the exact same reasons they are not great to me 2024-10-08 21:08:31 I suspect I would have had more issues setting up my weird ass setup, described earlier, with one of those distributions 2024-10-08 21:08:53 that alpine is more flexible and easy to tinker with 2024-10-08 21:10:45 and perhaps why we can target a bunch of architectures, embedded systems, containers, servers, desktop and mobile 2024-10-08 21:13:08 they could also target them pretty easily 2024-10-08 21:19:52 perhaps it's easier today to do minimalistic installs 2024-10-08 21:22:05 now I'm struggling with myself - on one hand I haven't run separate /usr in years, what do I care? on the other hand part of me would like for it to be possible 2024-10-08 21:24:58 well, I guess one could still make a minimal install, with what one considers to be bare essentials, and run the rest in containers or VMs on separate storage/partition/whatever 2024-10-08 21:50:23 imo, it's a boiling frog problem. bit by bit large commercial entities have gained leverage over everything 2024-10-08 21:51:20 this pot is still pretty cool, right? 2024-10-08 21:53:02 i'm not crying, my eyes are just a little sweaty today 2024-10-09 08:43:49 hmm, am i missing something with triggers? 2024-10-09 08:44:53 i would expect `triggers="paxrelabel.trigger=/usr/share/paxrelabel.d/*"` to cause `paxrelabel.trigger` to run when `/usr/share/paxrelabel.d/firefox` (for example) is installed 2024-10-09 08:46:29 hmm, it works without the `*` 2024-10-09 08:46:33 shrug... 2024-10-09 08:59:55 hey Ariadne! thank you for working on the pax kernel 2024-10-09 09:00:31 im sorry that i have not had capacity to get more involved. too busy with everything else. llvm 19, 3.21 builders etc 2024-10-09 09:01:18 i think triggers works on directories only 2024-10-09 09:01:22 or at least used to 2024-10-09 09:15:56 deno 2.0 is out, so many breaking changes LOL 2024-10-09 10:01:54 ncopa: i think we will be able to have hardened variant for 3.22 at least. maybe 3.21 if we have a new LTS in time. 2024-10-09 10:02:23 ncopa, Ariadne: yes, for file triggers we need https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/131 2024-10-09 10:02:33 Which I unfortunately did not get to finish 2024-10-09 14:24:41 hi, just wanted to say that i really dislike your getting rid of out-of-date package notifications in favour of anitya which has precious few packages and doesn't track alpine db for most of them anyway. 2024-10-09 14:25:21 (especially since much better release trackers exist which people here don't like for nebulous reasons) 2024-10-09 14:31:15 ovf: if you have a feature request, maybe open an issue in the apkbrowser repo? https://gitlab.alpinelinux.org/alpine/infra/apkbrowser/-/issues 2024-10-09 14:39:45 ovf: anitya has always been used 2024-10-09 14:40:45 The apkbrowser project did not have support for anything at all, and the feeling was that manual flagging was mostly misused 2024-10-09 14:40:50 user-submitted *legitimate* reports were always in the minority tbh 2024-10-09 14:41:01 "hi, just wanted to say that i..." <- From my experience the manual out-of-date triggers were mostly spam 2024-10-09 14:41:15 spam, or people misunderstanding the feature and reporting issues 2024-10-09 14:42:48 probably in the minority that thought manual flagging was useful for one-off notifications where there are gaps in anitya data, but understandably it's a non-trivial task to add it back, and in a way to mitigate spam 2024-10-09 14:43:29 i think we should rather focus on improving the anitya situation 2024-10-09 14:45:23 it's difficult for me to justify spending my personal time manually feeding things into anitya when the problem has been already solved, automatically and at scale, e.g. by repology.org 2024-10-09 14:45:54 this is compounded by the fact anitya bears no organisational relationship to alpine 2024-10-09 14:46:11 repology doesn't check upstream versiosn 2024-10-09 14:47:14 + IME is even worse than anitya when it comes to false-positives ( because some distro updated to a not-yet-released version and the one random guy hosting repology claims "but the tarball is there, so it's released" ) *and* false-negatives ( because no distro has updated to the latest version yet ) 2024-10-09 14:49:09 i'd say we could also roll out our own solution for ~70% of the packages we have, because it's just a matter of checking git tags / pypi released versions / etc. 2024-10-09 14:49:26 but that also yields some false positives 2024-10-09 14:52:50 ok, perhaps as a compromise we could at least do a mass linking of anitya packages to alpine? 2024-10-09 14:53:08 can't seem to find its db, or any method of doing that 2024-10-09 14:55:26 https://release-monitoring.org 2024-10-09 14:55:41 you add a mapping to projects like https://release-monitoring.org/project/5830/ after logging in to the name of the alpine package 2024-10-09 14:56:18 psykose: where do you get an account? 2024-10-09 14:56:30 it's a fedora account 2024-10-09 14:56:45 if you press fedora on https://release-monitoring.org/login you can then make a fedora one and it works 2024-10-09 14:56:53 technically any openid should work but i never tried 2024-10-09 14:56:59 in fact i tried openid earlier but that thing seems to have bitrotted to the core 2024-10-09 14:58:35 Not just Fedora login, I'm using an old Ubuntu One account I still had laying around. Anything OpenID will do 2024-10-09 14:58:58 psykose: i do understand how to do it by hand 2024-10-09 14:59:15 I've been linking my Alpine packages to Anitya for a while now, getting automatic emails when updates are released is a blessing 2024-10-09 14:59:34 i don't understand the issue then 2024-10-09 15:00:07 before anitya there was... nothing, since manual flags are a) also by hand, but every single time any release happens you have to do it instead of "just once" and b) 90% of the flags are spam 2024-10-09 15:00:36 Anitya is one of those projects that imo really benefits from cross distro collaboration 2024-10-09 15:00:53 is it annoying to go add 500 projects? yes, but before it was even worse, so i don't see what the core of the complaint is 2024-10-09 15:01:21 yeah me too 2024-10-09 15:01:23 it's not like something was made harder 2024-10-09 15:02:32 and it's not like there's much else to pick from 2024-10-09 15:02:38 distros like void have a repo-internal update check 2024-10-09 15:02:47 arch now uses some nvchecker thing that is also self-vendored files 2024-10-09 15:02:58 repology is not something that follows upstream so you can't actually use it 2024-10-09 15:03:02 i'm not aware of any other options 2024-10-09 15:04:46 ok, found the db: https://infrastructure.fedoraproject.org/infra/db-dumps/anitya.dump.xz 2024-10-09 15:09:33 the core of my complaint is that flagging packages out-of-date has been completely outsourced to a third-party tool that (in my opinion) does a very poor job of tracking releases, and is seemingly disinterested in spending any effort on supporting anything but fedora (judging by how repology was able to figure out distro db linking automatically) 2024-10-09 15:11:25 i look at repology every so often to compare versions and i always have to mentally filter out a few dozen packages that link to completely unrelated projects but happen to be matched by name or similar 2024-10-09 15:11:30 'figured out linking' is a stretch 2024-10-09 15:12:41 'outsourced to third party tool' would make sense as a criticism if it was some opaque actual outsourcing, but it's an open source tool you can go and edit mappings and rules in so the statement doesn't really make sense 2024-10-09 15:12:55 it could be an alpine-internal tool and have the exact same issues or lack thereof with the same editing requirement 2024-10-09 15:13:01 repology is also a third-party tool 2024-10-09 15:14:07 on the topic of 'mentally filter out packages'... another thing i notice in repology every time i look it is a separate set of yet again dozens of packages where the "newest" version is something that straight up does not exist 2024-10-09 15:14:31 but some distro happens to call some version of something they have that version that doesn't exist so it becomes the latest 2024-10-09 15:14:41 tracking distro versions only and not upstream detection is just inherently noisy 2024-10-09 15:15:35 and then don't get me started on the numerous things marked "out of date" on alpine because the apk version format is not the same as what the upstream version might be but there's nothing alpine can do about it and the maintainer refuses to make any changes for it 2024-10-09 15:19:31 Quite some CI backlog atm 2024-10-09 15:19:55 chromium + dotnet + qt6 2024-10-09 15:21:27 where does 7.5.0 come from? nobody knows, but it sure isn't an upstream version, and everyone else is "out of date" https://repology.org/project/bpftool/versions 2024-10-09 15:21:40 does 2.5.1 even exist? https://repology.org/project/collada-dom/versions answer: no https://github.com/rdiankov/collada-dom/tags 2024-10-09 15:22:07 i'm not suggesting alpine switch to repology, but the idea of having to populate a third-party database (i guess the fact that i've finally found the db dump url hardcoded in the anitya code does qualify it as 'open source') by hand is a bit revolting 2024-10-09 15:22:39 whatever method is used, a lot of handwork is required 2024-10-09 15:22:40 well before it existed there was nothing, so i'm not sure how that is more revolting than nothing 2024-10-09 15:24:08 And repeating all that work for each distro is rather wasteful 2024-10-09 15:26:00 unless the 'manual flagging thing' counted as not nothing, but that is even more manual and also even discounting all the spam the amount of legit updates in it was fewer than anitya has been for a long time.. so the current state is better than what that was 2024-10-09 15:47:40 i think we should definitely not use repology 2024-10-09 15:48:04 if anything we should add metadata to project APKBUILDs to monitor for releases ourselves 2024-10-09 15:49:02 the data quality is very questionable 2024-10-09 15:49:14 it's doable, but from experience of working with that you need multiple pieces and it can be quite verbose to put into every apkbuild 2024-10-09 15:49:47 i think itā€™s possible 2024-10-09 15:49:53 the baseline is some url and a regex pattern (or some other pattern); then as one step past that that is quite common is a way to remap versions from an upstream one to an apk one 2024-10-09 15:49:59 I used repology all the time, until I found Anitya and it's integration into pkgs.a.o šŸ¤· Most projects I package are already on there and I just have to map it to an Alpine package, and the few times that a package is not on there yet it's easy enough to add. It's definitely a better experience than repology 2024-10-09 15:50:35 yeah my suggestion is to supplement anitya with github and gitlab release monitoring 2024-10-09 15:51:08 what about harvesting debian/watch files? 2024-10-09 16:33:45 62 jobs pending.. 2024-10-09 16:36:30 I've personally not found either repology or anitya to be particularly good at flagging releases for me, and I maintain a non-trivial amount of packages. My solution has always been to do as ptrc described and check git release tags. 2024-10-09 16:37:10 that requires a little bit of manual work per package, but it's trivial to parse the rss/atom feeds once you know where to look, and results in far fewer false positives in my experience 2024-10-09 16:37:36 I generally subscribe to releases on the various forge platforms and use these other tools as backup 2024-10-09 16:38:02 anitya is checking the same tags (usually), so if it doesn't catch something then it merely means the pattern it matches needs changing or something 2024-10-09 16:50:06 q)count select from packages where distro_name like"Alpine" 2024-10-09 16:50:06 5090 2024-10-09 16:50:21 it's actually better (~one half?) than it feels like 2024-10-09 17:16:14 Could someone please merge !73306 whenever convenient? thanks! 2024-10-09 17:16:33 CI is kinda busy atm 2024-10-09 17:22:10 yeah I can see that XD "Whenever convenient" doesn't mean "now". ;) 2024-10-09 17:23:38 ahuh 2024-10-09 19:50:49 ptrc: what do you think about enabling media.webrtc.camera.allow-pipewire in the config of the firefoxes. could be as as seperate subpkg with install_if on firefox and xdg-desktop-portal 2024-10-09 19:52:50 hm 2024-10-09 19:52:55 does it have any drawbacks 2024-10-09 19:56:16 its still experimental 2024-10-09 19:56:40 see also https://gitlab.postmarketos.org/postmarketOS/pmaports/-/issues/3224 2024-10-09 19:57:13 Now more than ever I wished gitlab supported federation 2024-10-09 19:58:07 oh so true 2024-10-09 19:58:42 yea 2024-10-09 20:16:20 maybe we should figure out how to have pmOS and alpine in a single gitlab environment 2024-10-09 20:16:56 way back when we did not really have the infrastructure capability to do that, but i think we have a lot more capability now 2024-10-09 20:18:21 i imagine they aren't too interested in planning the next move when they just moved this week :D 2024-10-09 20:20:19 probably not :) 2024-10-09 20:24:42 on the other hand, maybe moving between selfhosted instances is less of a pain in the rear 2024-10-09 20:27:54 speaking of gitlab, anyone encountered this issue? https://ptrc.gay/ViAeWtYL 2024-10-09 20:27:58 We thought about it throughly (maybe even talked with some people?). But we felt we might risk making governance a lot harder for everybody. Like, e.g: we fear how things like systemd could affect how people view alpine, and the other way around 2024-10-09 20:28:08 the branch clearly does exist, as it shows the commit from said branch 2024-10-09 20:28:22 But also really wish we could federate :( 2024-10-09 20:31:01 afaik there are some efforts in federation for gitlab instances (esp universities as they ALL have their own instance). 2024-10-09 20:55:06 did gitlab get patched? 2024-10-09 20:55:40 invoked: are you referring to the latest security anouncement? 2024-10-09 20:55:53 yeah 2024-10-09 20:55:57 Working on it 2024-10-09 20:56:10 cool 2024-10-09 20:56:41 Waiting for the docker image to finish to build 2024-10-09 21:09:36 hmm, maybe i am doing this paxrelabel trigger wrong. maybe it shouldn't even be a trigger, but an apk post-commit hook 2024-10-09 21:09:51 because i just upgraded firefox, and now i need to relabel it 2024-10-09 21:43:41 looks like commit-hooks is the fix 2024-10-09 21:51:03 I think I was wrong about my description of the FreeBSD /etc vs /usr/etc vs /usr/local/etc earlier, I looks like it doesn't have a /usr/etc https://man.freebsd.org/cgi/man.cgi?hier(7) 2024-10-09 21:51:17 clearly it was too long since I managed FreeBSD systems on a regular basis 2024-10-09 21:52:53 and it looks like OpenBSD only uses /etc https://man.openbsd.org/hier 2024-10-09 21:53:41 I just read this comment https://lobste.rs/s/6ntl4g/modern_path_environment_variable#c_4glseu and am not sure what BSD system they refer to 2024-10-09 21:59:43 that is a pretty good generalized summary of all of the BSD systems 2024-10-09 21:59:55 though /usr/etc is obviously not a thing on BSD 2024-10-09 22:04:07 right, between when I read that comment and wrote about it I mentally added "/etc" to the three parts :D 2024-10-09 22:04:36 I should get more sleep than I have the past few nights 2024-10-09 22:06:18 oh, right, as mentioned on #alpine-security, we now have #alpine-hardened for defensive security features since it is a separate work stream from what the security team does 2024-10-09 22:15:17 Restarting gitlab for security updates 2024-10-09 22:19:22 gitlab is back 2024-10-10 07:38:42 friendly reminder to merge !73306 whenever the CI load permits it. 2024-10-10 08:57:06 skarnet: doesn't the skaware respect MAKEFLAGS? 2024-10-10 08:57:27 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/default.conf?ref_type=heads#L10 2024-10-10 09:08:53 it does, the -j additions are useless as psykose said 2024-10-10 09:10:29 you want me to change everything back *now*? sigh. 2024-10-10 09:27:52 there, all -j options removed. 2024-10-10 10:15:59 I've been having trouble taking proper care of osv-scanner recently, in case anybody wants to join as a co-maintainer that'd be much appreciated: tests are currently failing with "snapshot not found" https://gitlab.alpinelinux.org/kpcyrd/aports/-/jobs/1552719 / https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/69629 2024-10-10 10:23:08 ncopa: I got pinged on https://github.com/llvm/llvm-project/issues/55383, which addresses lldb support on rv64 2024-10-10 10:23:23 im having problems taking care of llvm19. there are some tests that fails on ppc64le and some tests that fails on 32 bit platforms. feeling a bit overwhelmed with the llvm stuf atm 2024-10-10 10:24:28 ikke: i will try look at lldb once i got llvm itself built properly 2024-10-10 10:24:33 on all arches 2024-10-10 10:25:57 ahuh, just wanted to be sure you were aware 2024-10-10 10:28:26 i wasnt. thanks 2024-10-10 10:28:52 where is mick_ibm when you need him 2024-10-10 10:29:09 would be awesome if we could get some help from real compiler ppl 2024-10-10 10:29:26 the tests are flaky 2024-10-10 10:29:50 i rerun the test suite and some tests passes on second un 2024-10-10 10:29:51 run* 2024-10-10 12:06:25 im pushing abuild 3.14.0_rc1 now. lots of changes. keep your eyes open for breakages 2024-10-10 12:07:58 here we go 2024-10-10 12:10:28 Ok, I'll make sure CI is updated as well 2024-10-10 13:33:03 "doas" only has etc/doas.conf but "setup-user" add line to etc/doas.d/doas.conf 2024-10-10 13:33:09 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-user.in#L159 2024-10-10 13:34:50 this caused me to modify the former and found it invalid because it was overwritten by the latter 2024-10-10 13:35:24 I havent followed there tbh. at some point there was someone with strong opinion that introduced /etc/doas.d/ 2024-10-10 13:35:36 We should have a patch to allow for that 2024-10-10 13:35:50 patches are welcome 2024-10-10 13:35:53 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/doas/configuration-directory.patch 2024-10-10 13:36:13 yeah, that one 2024-10-10 13:40:17 doas.d.5 should explain why this difference exists vs upstream 2024-10-10 13:40:26 it doesn't. 2024-10-10 13:40:48 iirc upstream has noted some annoyance with this change 2024-10-10 13:41:37 (probably because it breaks with the original upstream, openbsd) 2024-10-10 13:41:40 nod 2024-10-10 13:44:08 maybe create an issue and ping jirutka 2024-10-10 13:45:02 Better to make an MR 2024-10-10 13:45:05 https://github.com/Duncaen/OpenDoas/issues/61 2024-10-10 13:45:53 this was discussed to death a bunch of times pretty sure 2024-10-10 13:45:54 doas can't replace sudo in all cases, and it is not trying to. i'm not sure what doas.d solves 2024-10-10 13:46:32 That packages can provide drop-in config 2024-10-10 13:46:44 ah, ok. 2024-10-10 13:47:14 https://pkgs.alpinelinux.org/contents?file=&path=%2Fetc%2Fdoas.d&name=&branch=edge&repo=&arch=x86_64 2024-10-10 13:59:48 doas.d.5 should be patched to minimally explain what that means for package installs (potentially) 2024-10-10 14:00:03 although the idea of something automatically mucking with doas makes me queasy, personally 2024-10-10 14:01:27 that stuff imo should be in /share 2024-10-10 14:30:31 is there a valid SPDX value for "no license"? I have a dummy package with no source and just comments in the headers (mingw-w64-headers-bootstrap) 2024-10-10 14:31:10 No, there is none 2024-10-10 14:31:17 no license means we cannot distribute it 2024-10-10 14:32:13 (in general) 2024-10-10 14:34:14 there's `none` in the value and lint complains 2024-10-10 14:34:58 It looks at this list: https://spdx.org/licenses/ 2024-10-10 14:35:54 if its the apkbuild writing the files, does anything works? like GPL or CC-BY 2024-10-10 14:37:16 https://spdx.org/licenses/Unlicense.html maybe 2024-10-10 14:39:14 There is `custom` 2024-10-10 14:39:24 which is also what archlinux uses 2024-10-10 14:39:56 pmos uses gpl3 for meta packages 2024-10-10 14:40:59 void uses custom:Public Domain for meta/empty packages 2024-10-10 14:47:27 `license="custom"` could work 2024-10-10 15:09:57 oof, spdk MR has been running for 18h already :/ 2024-10-10 15:32:30 pretty sure that is stuck 2024-10-10 15:34:19 yup 2024-10-10 15:34:46 Had the job open for a while to verify 2024-10-10 16:06:19 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1553672 seem stuck as well 2024-10-10 18:15:20 If installing from substitutes, does Guix allow you to ignore build-time dependencies and only install runtime dependencies into the store? 2024-10-10 18:15:31 shoot. sorry. 2024-10-10 18:29:59 no worries 2024-10-10 18:59:18 Anyone know when the Alpine gitlab will be back up? https://downforeveryoneorjustme.com/gitlab.alpinelinux.org 2024-10-10 19:00:35 jahway603[m]: I'm looking into it, load is high atm 2024-10-10 19:02:39 i hope i didnt break it :p 2024-10-10 19:03:19 A lot of git operations waiting on IO 2024-10-10 19:06:54 stopping gitlab for a sec 2024-10-10 19:13:52 it's back 2024-10-10 19:14:07 nice thanks for the quick fix! 2024-10-10 19:15:53 Load average: 2.29 64.16 99.16 2024-10-10 19:17:06 oof 2024-10-10 19:17:28 It was higher 2024-10-10 19:23:51 Are we ever going the "no tests ran" warning into an error? :D 2024-10-10 19:24:03 it was just made 2024-10-10 19:24:13 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16519 2024-10-10 19:24:14 Oh wow, the timing. Nice! 2024-10-10 19:25:39 I think PureTryOut meant something different 2024-10-10 19:26:48 Independently from ctest. If a package has no tests, and it doesn't specify !check, abuild would warn you and tell you that in the future it'll be turned into an error. It has said that for literal years now 2024-10-10 19:29:43 ah that 2024-10-10 19:30:02 Still good that ctest not finding tests is turned into an error now though 2024-10-10 19:30:28 i mean, me and a few other people were adding `!check` for APKBUILDs with no check function for a while now 2024-10-10 19:30:48 So am I, it's more to prevent new stuff being added 2024-10-10 19:30:53 Not sure if there is a substantial difference between not running tests or having !check 2024-10-10 19:31:13 !check is explicit 2024-10-10 19:31:23 well at least the packager is consciously thinking about it 2024-10-10 19:31:25 not running any tests because there's no `check()` is less explicit 2024-10-10 19:31:49 check was originally permissive because it was the only way to get buy-in :p 2024-10-10 19:31:50 yeah and !check usually needs a reason 2024-10-10 19:32:33 half the reasons are just # too hard however 2024-10-10 19:32:42 options="!check" # tests fail 2024-10-10 19:32:44 # it failed 2024-10-10 19:32:48 # todo 2024-10-10 19:32:49 oh yeah those are the best 2024-10-10 19:32:56 i think alpine needs integration testing though, which cannot really be done in APKBUILD. in melange, we added a separate integration test definition for that 2024-10-10 19:33:26 (integration meaning: install the package, actually do something to exercise the package, uninstall package) 2024-10-10 19:33:57 a lot of upstream unit tests are just broken too 2024-10-10 19:34:06 like they assume they are running on the developer's machine and stuff 2024-10-10 19:34:33 TZ=America/Los_Angeles # fix tests 2024-10-10 19:34:52 i feel like a lot of integration tests would need various mocks, for network services, USB devices, etc. 2024-10-10 19:36:30 yeah, that's why it hasn't been done in alpine yet :P 2024-10-10 19:36:45 psykose: i'm sure if we looked at APKBUILDs we would find similar hacks :D 2024-10-10 19:36:46 A lot of work to get working and keep working 2024-10-10 19:36:57 maybe that alpaquita company can do it for us 2024-10-10 19:37:02 Would make sense for more critical packages 2024-10-10 19:37:05 since they bootleg off our free work 2024-10-10 19:37:09 and then talk shit about us 2024-10-10 19:37:11 :)))) 2024-10-10 19:37:16 do they 2024-10-10 19:37:20 they do 2024-10-10 19:37:20 (the talk shit part) 2024-10-10 19:37:30 all i know of alpaquita is one of the devs emailed me once 2024-10-10 19:37:47 https://bell-sw.com/blog/alpaquita-vs-alpine-a-head-to-head-comparison/ 2024-10-10 19:38:06 apparently alpine is GPL, and alpaquita is "EULA" 2024-10-10 19:38:12 i... don't think that works the way they think it does 2024-10-10 19:38:19 crack api 2024-10-10 19:39:58 the "musl perf" stuff violates glibc's LGPL license 2024-10-10 19:40:12 (they basically precompiled a bunch of string routines from glibc and bolted them onto musl) 2024-10-10 19:41:38 yea, paired with the ifunc patch so they can be loaded at all 2024-10-10 19:59:22 wow 2024-10-10 20:01:44 ok but alpaquita promises 100% license compliance 2024-10-10 20:01:55 by which they mean alpine doesn't! 2024-10-10 20:04:06 i think alpine takes licensing fairly seriously 2024-10-10 20:04:16 if it wasn't clear, i was joking 2024-10-10 20:04:18 though it is possible things have slipped through the cracks 2024-10-10 20:04:22 they have before 2024-10-10 20:06:03 ptrc: any plans to update firefox on 3.20? 2024-10-10 20:06:13 I see you pushed it for edge already 2024-10-10 20:06:19 bumped esr in 3.20 as well 2024-10-10 20:06:24 yup, saw that 2024-10-10 20:06:47 forgot to push the bump to stable, got a branch locally but i wasn't sure if it needs new nss or not 2024-10-10 20:06:57 nod 2024-10-10 21:10:03 Ariadne: Nice to have you back :) 2024-10-10 21:25:51 i agree :3 2024-10-10 21:55:58 Ariadne:it could have been made into a separate library just containing perf related files from glibc 2024-10-10 21:56:33 khem: it could have been many things, instead it is a tarball of .o files 2024-10-10 21:57:04 needs more ai 2024-10-10 21:57:35 hmm technically static linking should be fine but .o without sources I am not sure 2024-10-11 02:51:40 The MOVE_CACHES configuration on abuild-3.14.0_rc2 doesn't seem to work for go aports. 2024-10-11 02:51:42 If I uncomment it in abuild.conf, aports that don't have GOCACHE set (like forgejo-runner) will fail to build because of inexistence of $tmpdir. 2024-10-11 07:39:33 lindsay: could you please create an issue for that? 2024-10-11 07:40:03 ncopa: Ok 2024-10-11 07:40:28 https://gitlab.alpinelinux.org/alpine/abuild/-/issues 2024-10-11 07:53:29 https://gitlab.alpinelinux.org/alpine/abuild/-/issues/10156 2024-10-11 08:56:09 missing a backslash at https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L2542 2024-10-11 09:49:29 hi all, finally got to playing with mkimage.sh. what i have to pass to --repository? i tried https://dl-cdn.alpinelinux.org/alpine/v3.20 and 3.20 and got "cp: can't stat '': No such file or directory" 2024-10-11 09:51:47 Something seems busted with LLVM 18 stack clash protection -> rust -> librsvg on aarch64 if anyone has any ideas https://gitlab.alpinelinux.org/alpine/aports/-/issues/16520 2024-10-11 09:54:06 indy: you need the trailing /main 2024-10-11 09:55:32 ncopa, just tried ./mkimage.sh --repository https://dl-cdn.alpinelinux.org/alpine/v3.20/main and 3.20/main and same 2024-10-11 10:05:27 ncopa, maybe pipline which is using it should be good start :) 2024-10-11 11:12:04 ncopa, progress - failing on usr not in archive : https://dpaste.org/0bFtk 2024-10-11 11:46:13 ncopa, success, it was failing on apk fetch --stdout alpine-release | tar -xz -C "$tmp" etc/ /usr 2024-10-11 11:47:10 ncopa, as alpine-release has only etc/ it was failing 2024-10-11 11:53:28 I just upgraded abuild and now it complains that permission is denied to write to $HOME/packages. Did it change group or something? 2024-10-11 11:59:17 oh, only happens with rootbld 2024-10-11 13:18:30 indy: maybe use 3.20-stable branch for v3.20 repos 2024-10-11 13:20:59 ncopa, yes i've found that 2024-10-11 13:21:19 ncopa, thanks 2024-10-11 13:30:05 PureTryOut (matrix.org): possibly another issue and point it to @Sertonix? 2024-10-11 19:29:41 driveby bug report. in edge, utmpd,wtmpd,btmpd all failing now with 'start-stop-daemon: /bin/s6-ipcserver does not exist'. not sure what changed... will try to open an issue later 2024-10-11 19:30:14 oh usr merge probably 2024-10-11 19:30:39 anyways... will follow up later. 2024-10-11 19:32:54 should still exist in /bin: https://pkgs.alpinelinux.org/contents?file=&path=&name=s6-ipcserver&branch=edge&repo=main&arch=x86_64 2024-10-11 19:35:22 not on mine. it's in /usr/bin 2024-10-11 19:36:32 s6-ipcserver-2.13.1.0-r0 ... testing 2024-10-11 19:36:45 that's on me. 2024-10-11 19:36:51 "apk info -L s6-ipcserver" ? 2024-10-11 19:40:22 https://tpaste.us/e6aV in a meeting, bbl 2024-10-11 19:41:07 There's -r1 in the index 2024-10-11 19:41:33 that's 2.13.0.0 2024-10-11 19:43:43 oh ok 2024-10-11 19:49:54 did upstream change the install path? 2024-10-11 19:52:18 ya seems like the path changed upstream and some service files in aports need to be updated to use the new paths 2024-10-11 19:54:17 well sorta, d348893ddf28edb773ac69df7129b43b767d8418 2024-10-11 19:58:20 whoops 2024-10-11 19:58:24 I'll fix this right away 2024-10-11 19:58:46 73400 2024-10-11 19:58:49 skarnet: ^ 2024-10-11 19:58:59 erm, https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73400 2024-10-11 19:59:42 well you were fast 2024-10-11 19:59:46 thanks a lot :) approved 2024-10-11 20:00:53 (one convention I don't like in the initd files: full path to binaries instead of letting PATH do its job. And that's exactly why.) 2024-10-11 20:04:41 I have a package in testing, that has a dependency that's also in testing. How do I specify the dependency? abuild is looking only in world. This worked (and was accepted) in July, the last time I submitted it. 2024-10-11 20:08:09 Make sure you have the testing repo enabled 2024-10-11 20:09:31 Which would be the case for anyone installing this, since it's in testing, right? 2024-10-11 20:09:52 Hm. So, I'd need to enable it in the container. 2024-10-11 20:09:57 Kthx 2024-10-11 20:16:53 ikke: thanks, that did it. 2024-10-11 20:16:59 yw 2024-10-11 20:17:26 craftyguy: skarnet: thanks, all good now 2024-10-11 20:25:33 skarnet: yeah I agree. maybe that patch should have done away with the path entirely :P 2024-10-11 20:32:58 but that's not how other init.d services are written, is it 2024-10-11 20:38:23 Hi. :) How do I determine whats causing the pipelines to fail for my MR? https://gitlab.alpinelinux.org/forza/aports/-/pipelines/264555/failures 2024-10-11 20:39:27 clicking on one, I see: https://gitlab.alpinelinux.org/forza/aports/-/jobs/1555402#L86 2024-10-11 20:39:30 skarnet: most seem to use hard coded paths. I don't know what openrc recommends doing. some other init things require full paths to the service exe 2024-10-11 20:39:32 caddy.initd: FAILED 2024-10-11 20:39:33 sha512sum: WARNING: 1 of 1 computed checksums did NOT match 2024-10-11 20:39:59 Oh 2024-10-11 20:40:41 Didn't see i could click it. (On my phone). Ill have to fix the checksum. Thanks. 2024-10-11 20:51:28 Hm. I think I need help with this git squashing thing. Seems the updated apkbuild file isn't added to the mr 2024-10-12 09:33:25 I don't understand what happens with rootbld https://tpaste.us/knW6 2024-10-12 09:34:05 as a fast try for workaround '/home/donoban/packages/' has permissions 777 but stills failing 2024-10-12 09:44:24 It may be some FS weirdness. 2024-10-12 09:44:37 btw does plain `abuild -r` work? 2024-10-12 09:50:29 I would prefer to don't install deps on host 2024-10-12 09:50:42 will check later 2024-10-12 11:30:21 "as a fast try for workaround '/..." <- yeah its a known issue with rootbld 2024-10-12 11:31:13 you can workaround it locally if you add `\` to /usr/bin/abuild line 2542 2024-10-12 11:33:05 ahh lol 2024-10-12 11:33:07 ty 2024-10-12 11:36:01 ahora sip 2024-10-12 11:36:10 107MB/s 2024-10-12 11:56:50 lol wrong window 2024-10-12 14:45:28 hm, rootbld seems defunct rn 2024-10-12 14:46:36 "you can workaround it locally if you add `\` to /usr/bin/abuild line 2542 " 2024-10-12 14:46:56 Unless it's a different issue 2024-10-12 18:37:49 apkbuild-lint warns about the maintainer variable; should I use # Maintainer: in a new aport for now? 2024-10-12 18:39:14 krystianch: No, I'm just making an MR to fix it 2024-10-12 18:39:45 ok, thanks 2024-10-12 18:40:18 krystianch: Using a comment triggers a different warning, so you cannot make the linter happy anyway 2024-10-12 19:39:40 Has someone else issues with swaywm not starting after a recent update? (segfault in libwlroots according to dmesg, "Swapchain for output `eDP-1` failed to test" printed by sway to console prior crash) 2024-10-12 20:14:44 feel free to test !72645 I would like to merge busybox 1.37.0 sometime next week so let me know if anyone encounters any breakage :) 2024-10-12 20:15:08 I'll try it in my build container 2024-10-12 20:48:33 regarding the wlroots issue: The segfault is due to dereferencing a NULL ptr when handling switching back from a VT. 2024-10-12 20:50:15 Patching in the missing check for a NULL ptr fixes the segfault, but startup still hangs (no desktop is shown). 2024-10-13 07:40:20 yesterday I noticed that mosh sessions are not tracked by utmps, there is an option "--with-utempter write utmp entries using libutempter [check]" but is it compatible with utmps? 2024-10-13 07:43:04 uhm, maybe libutempter is already patched for it 2024-10-13 07:43:40 it's just build this way: make CFLAGS="$CFLAGS -I/usr/include/utmps" LDLIBS="-Wl,--no-as-needed -lutmps -lskarnet -Wl,--as-needed" 2024-10-13 07:46:47 checking for utempter_remove_record in -lutempter... yes 2024-10-13 07:55:20 meh, it doesn't work 2024-10-13 07:58:13 donoban pts/4 00:00 Oct 13 09:58:05 127.0.0.1 via mosh [6653] 2024-10-13 07:58:22 oh yes, it was downgraded maybe due autoupgrade process 2024-10-13 08:22:02 !73447 2024-10-13 12:13:57 ncopa: could https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/328 be merged? rootbld is currently broken and well it's the only way I build anything šŸ˜… 2024-10-13 14:00:32 is alpine's apkbrowser db up for grabs anywhere? 2024-10-13 14:11:23 not really 2024-10-13 15:10:35 ovf: its rather big 2024-10-13 15:12:16 i figured i can just as well parse apkindices (i mostly just need name+version+url, to correlate with anitya) 2024-10-13 15:12:44 you are writing something to map anitya? 2024-10-13 15:13:49 yes, as a follow-up to my expressing my dissatisfaction here the other day 2024-10-13 15:21:08 im reading it 2024-10-13 15:21:18 i kind of understand your pov 2024-10-13 15:22:04 but i still think aniya is the best way to track this 2024-10-13 15:22:19 and the false positives are annoying 2024-10-13 15:28:10 yep, i don't have anything against anitya itself, rather the fact that it lacks both alpine packages and upstream projects packaged by alpine, and doesn't have any bulk/automated way of improving that. so i want to start by getting a list of things missing from it 2024-10-13 15:28:36 If you don't need file listings, the apkindex is indeed a better option 2024-10-13 16:00:23 q)sum((un apk.url)in un projects.homepage)|(lower apk.name)in lower projects.name 2024-10-13 16:00:23 6298 2024-10-13 16:00:34 probably need to up my heuristic matching game 2024-10-13 16:15:36 anyone experiencing some weird memory leaks on a qemu guest as of recently? 2024-10-13 16:15:48 seems to be kernelspace but i cannot point where 2024-10-13 16:16:51 might be related to alpine but unsure 2024-10-13 16:19:44 or better said btrfs code... welp 2024-10-13 16:23:56 oh nvm, something got reset the wrong way 2024-10-13 16:24:00 false alarm 2024-10-13 16:50:52 regarding the issue I had with sway: fwupd was holding exclusive access to /dev/dri/card1 2024-10-13 17:32:45 Hello. I'm running Alpine Linux on Termux on my Samsung Galaxy S9+ phone and I currently don't come further. I want to compile Git from source for my phone with the increased performance for distribution packers. I was pointed by someone to https://git.alpinelinux.org/aports/tree/main/git but I don't really know how to apply the patch and which dependencies still to install except for makedepends=, I always 2024-10-13 17:32:45 get liblint.h gettext errors which cancels the build. If you're interested in the exact error message I'd first have to run the compile process again which might take a while before I get it. Thank you a lot for your help. 2024-10-13 17:34:49 it feels a lot like an XY problem 2024-10-13 17:34:58 are you using abuild to build it? 2024-10-13 17:36:39 ptrc: Thank you for your response. You're lucky I just started the build process again. Here's what I enter: localhost:/storage/0E9F-B9B4/Android/data/com.termux/files/git# nice -n -20 make NO_REGEX=NeedsStartEnd LDFLAGS="-lintl" prefix=/usr profile && nice -n -20 make prefix=/usr PROFILE=BUILD install 2024-10-13 17:37:52 why are you doing `LDFLAGS="-lintl"` in the first place? 2024-10-13 17:38:21 ptrc: I've let ChatGPT help me. 2024-10-13 17:38:42 did the autocorrect machine give you any reasoning for this 2024-10-13 17:39:05 Let me have a look at my chat history 2024-10-13 17:41:28 Check the library paths: 2024-10-13 17:41:28 Ensure that the linker can find the correct library. You may need to specify the library path manually: 2024-10-13 17:41:29 export LDFLAGS="-L/usr/local/lib -lintl" 2024-10-13 17:41:31 Adjust /usr/local/lib according to the directory where libintl is located. 2024-10-13 17:41:41 Sorry about that 2024-10-13 17:42:39 Well put that into the command because i didn't want to export it each time or write it into .profile 2024-10-13 17:44:59 I just got the error message: /usr/lib/gcc/aarch64-alpine-linux-musl/14.2.0/../../../../aarch64-alpine-linux-musl/bin/ld: libgit.a(rerere.o):/storage/0E9F-B9B4/Android/data/com.termux/files/git/gettext.h:52: more undefined references to `libintl_gettext' follow collect2: error: ld returned 1 exit status make[1]: *** [Makefile:2868: git-daemon] Error 1 2024-10-13 17:44:59 make[1]: Leaving directory '/storage/0E9F-B9B4/Android/data/com.termux/files/git' 2024-10-13 17:44:59 make: *** [Makefile:2392: profile] Error 2 2024-10-13 17:46:28 well 2024-10-13 17:46:39 easy fix for this would probably be setting `NO_GETTEXT=YesPlease` 2024-10-13 17:46:49 which you can see in aports/main/git/APKBUILD 2024-10-13 17:48:33 ptrc: That easy? Well i have to admit that i don't have so much build experience yet, although i already was into linux age 10, windows always pulled me back, born 1988 2024-10-13 17:49:26 ptrc: yes i some of these yesplease lines just didn't know what they might mean 2024-10-13 17:51:38 i mean, in this case, you can see the error being quite verbose about gettext 2024-10-13 17:52:14 Why arenā€™t you using abuild? 2024-10-13 17:54:04 Yes, i saw, just didn't really know what to do about this. I didn't abuild before because i only knew make until this point and i sometimes struggle with being overwhelmed when i see new instructions that come across difficult to me 2024-10-13 17:54:59 I'm German by the way 2024-10-13 17:56:04 I need to use keygen for what when i want to use abuild ? 2024-10-13 17:57:18 abuild-keygen, which will generate a signing key that is used to sign packages and the index 2024-10-13 17:58:11 ikke: but i'm not a distribution packer, i don't plan to upload the packages 2024-10-13 17:58:28 Or commit them 2024-10-13 17:58:50 If you want to install the packages locally, you'd need one as well 2024-10-13 17:59:25 ikke: ok 2024-10-13 17:59:34 `abuild-keygen -ain` will generate one and install it at the same time (given that doas is setup / working) 2024-10-13 18:00:57 doas is not needed, i'm supposed to work on a chroot, only need that if i would install alpine on my pc 2024-10-13 18:01:35 does your user have write access to /etc/apk/keys? 2024-10-13 18:02:36 I'm on a proot-distro chroot with full / directories 2024-10-13 18:02:45 Should work 2024-10-13 18:05:57 Yes i got write access to /etc/apk/keys 2024-10-13 18:09:56 ikke: key was written 2024-10-13 18:10:52 Now i can do abuild? 2024-10-13 18:11:09 also make sure you user is a member of the abuild group 2024-10-13 18:11:24 and as someone suggested before, make sure `alpine-sdk` is isntalled 2024-10-13 18:12:51 ikke: No worries already installed alpine-sdk 2024-10-13 18:14:03 alright 2024-10-13 18:15:58 ikke: what package do i need to add abuild to root? 2024-10-13 18:16:57 I currently didn't install this package because before i didn't even think i'd build software on this phone 2024-10-13 18:19:52 Shadow i guess 2024-10-13 18:20:29 Thank you guys, i think i'll take it from here 2024-10-13 18:20:52 Have a nice weekend yet 2024-10-13 18:21:00 Mine is nearly over 2024-10-13 18:21:30 I thought you're from US? 2024-10-13 18:23:04 Nope, EU 2024-10-13 18:24:17 Alright enjoy the rest of the weekend 2024-10-13 18:24:28 Take care guys 2024-10-13 18:24:37 o/ 2024-10-14 07:59:42 What do I have to add to abuild.conf again to enable ccache? 2024-10-14 09:55:09 PureTryOut: rtfs 2024-10-14 09:55:20 should be obvious 2024-10-14 09:56:10 What's the s in there? I looked on the wiki and for comments in the relevant files themselves, I couldn't find anything 2024-10-14 10:00:52 "source"? :p 2024-10-14 10:01:36 https://github.com/alpinelinux/abuild/blob/6e5cb0cfc13e73e54bab648344ab20665ca254b4/abuild.conf.in#L7 but yeah it's pretty obvious 2024-10-14 10:03:30 (answering rtf* still sucks when it's about an equivalent amount of effort to just link the thing) 2024-10-14 11:08:15 Huh that is not in my abuild.conf, not even commented. Strange. Thanks! 2024-10-14 11:09:30 PureTryOut: is there a .apknew file? 2024-10-14 11:10:58 No. I might've gotten rid of some point, idk šŸ¤· 2024-10-14 11:11:09 *rid of it at some point 2024-10-14 11:13:05 Anyone care to bump libgsf? It needs to be rebuilt against libxml (apparently some symbols disappeared without a soname change) 2024-10-14 12:23:57 im on it 2024-10-14 12:29:32 ikke: do you have any reference to the libxml2 disappearing symbols? 2024-10-14 12:31:07 ncopa: try ldd on libgsf 2024-10-14 12:33:51 thank you 2024-10-14 12:33:59 seems like nobody reported it 2024-10-14 12:34:08 upstream 2024-10-14 12:34:42 wixl from msitools is broken 2024-10-14 12:55:13 https://gitlab.gnome.org/GNOME/libxml2/-/issues/751 2024-10-14 14:28:29 hi everyone! i am trying to find a way to use Openmediavault alpine based, do you think it is doable? 2024-10-14 16:27:38 moving something from testing to community needs bump pkgrel? 2024-10-14 16:30:44 no it shouldn't 2024-10-14 16:30:53 ok ty 2024-10-14 16:31:05 np :) 2024-10-15 08:52:05 I noticed https://pkgs.alpinelinux.org/packages?name=sn0int&branch=edge&arch= lists 0.26.1 for all architectures but 0.26.0 for x86_64. I suspected a build failure but I found a successful build log here: https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/sn0int/sn0int-0.26.1-r0.log anything I can do? 2024-10-15 09:00:25 kpcyrd: there appear to be some issues with the new apkbrowser 2024-10-15 09:00:40 The latest version is on the mirrors 2024-10-15 09:05:34 ikke: I see, thank you for checking! 2024-10-15 11:10:31 the new gotosocial release depends on a precompiled ffmpeg-wasm (and related libararies) binary, which i assume isnt something that should be packaged, any thoughts on how to proceed with updating it? the new package being depended on is https://codeberg.org/gruf/go-ffmpreg 2024-10-15 11:13:26 should the gotosocial build also try to build its own ffmpeg to wasm or something? the path to the wasm file can be overridden at runtime 2024-10-15 11:37:12 amk: It's not something that has really come up yet 2024-10-15 11:37:39 our default_doc in abuild is painfully slow 2024-10-15 11:38:07 should probably rewrite it in C, an abuild-compress-manpages.c or similar 2024-10-15 11:38:39 but not today 2024-10-15 11:47:54 amk: I don't suppose it makes sense to build wasm binaries for each architecture 2024-10-15 11:50:11 ncopa: getting flashbacks from when i was writing my manpage recompressor now... 2024-10-15 11:56:13 ikke: yeah true, that wouldnt be ideal. i imagine itll also come up for anything using the sqlite-wasm go library also 2024-10-15 12:16:31 If I want to get to the point where I can run "abuild ckeck" manually, is "abuild -r deps fetch verify unpack prepare build" all that I need to do before? 2024-10-15 12:20:14 the 3.21 builders are almost done with the aports bootstrap 2024-10-15 12:20:43 only armv7 and riscv64 left now 2024-10-15 12:21:40 socksinspace: abuild deps unpack prepare build 2024-10-15 12:23:13 thanks :) 2024-10-15 12:26:26 libcbor needs a fix apparently. seems like it does not builds or runs the tests 2024-10-15 12:45:27 ncopa: I just took a look at default_doc and it looks like a lot of filesystem traversal, rewriting it in C would help *a bit* with shell inefficiencies but probably not as much as you want 2024-10-15 12:46:15 find looks like the limiting factor here 2024-10-15 12:48:23 i think it is the find -exec stat in the inner loop that does it 2024-10-15 12:48:35 and all the forks in that inner loop 2024-10-15 12:48:52 but I havent measured 2024-10-15 12:49:37 i think a C implementation could scan the filesystem once, and store the file names and stat info in a list 2024-10-15 12:49:44 and do the rest from there 2024-10-15 12:49:56 and maybe run the gzip stuff in parallel 2024-10-15 12:49:58 to remove the quadraticness? yeah mayber 2024-10-15 12:50:00 -r 2024-10-15 12:50:44 but not today. busy with getting the 3.21 runners up 2024-10-15 12:51:14 the lua-filesystem tests on riscv64 is dog slow as well 2024-10-15 19:33:32 fcolista: you updated tiff to 4.6.0t, but it seems that version does not exist? 2024-10-15 19:33:54 The link is a 404, https://download.osgeo.org/libtiff/ does not list it, neither does https://gitlab.com/libtiff/libtiff/-/releases 2024-10-15 19:36:02 it used to 2024-10-15 19:36:25 4.6.0 removed most of the tools, then iirc they quickly made a +t with them back in or something 2024-10-15 19:36:34 4.7.0 also has them and so they dropped the extra release 2024-10-15 19:36:39 or something 2024-10-15 19:36:43 ..i guess 2024-10-15 19:36:50 it's better than repurposing a version number, but also not great :) 2024-10-15 19:37:04 dunno why they removed it at all 2024-10-15 19:38:07 the alpine 3.21 builders are up and running now 2024-10-15 19:38:49 it means that we are effectively in a "feature freeze" now, and need to be a bit careful what we push 2024-10-15 19:39:55 major ABI breakages should be evaluated, if it makes sense to include for 3.21 or better to wait post 3.21 2024-10-15 19:40:34 I would like to prioritize fixing bugs and issues, and clean up things for 3.21 2024-10-15 19:41:47 ncopa: rust is being or has been bootstrapped on most arches 2024-10-15 19:42:27 oh! awesome! 2024-10-15 19:42:50 only riscv64 and loongarch64 are still missing 2024-10-15 19:43:04 aarch64 and s390x are in progress 2024-10-15 21:51:04 I guess I need to change maintainer comments to maintainer= variables now? 2024-10-15 22:44:19 May I ask you to review !70869 Real Quick? 2024-10-15 22:44:58 which is 75.1.0 by now 2024-10-15 22:46:59 Sorry for keeping it unresolved and feel free to send a performance improvement plan for me 2024-10-16 03:28:55 I suspect you don't really want it: https://github.com/pypa/setuptools/issues/4653 2024-10-16 03:32:54 void has seemingly been fine with 75.1.0 2024-10-16 03:41:56 you got lucky! 2024-10-16 04:04:37 i haven't ran into it either 2024-10-16 04:05:41 from the analysis that only breaks if some cache is used in parallel? i forget if portage parallel builds are reusing some global state for that 2024-10-16 04:05:57 for us, we just don't have parallel builds so no parallel distutils invocations in the same global context 2024-10-16 04:06:31 "us" being everyone else really, even when we build stuff in parallel it's separate buildroots or similar 2024-10-16 04:13:35 I _think_ it'll happen anyway because the issue depends on the layout of the package, not fs/anything global 2024-10-16 04:13:40 but you might be right in that it's interesting nobody else seems to have 2024-10-16 04:13:44 we only saw it on a few packages though 2024-10-16 04:15:07 lxml and cython 2024-10-16 04:15:11 would be interesting if you can't hit it in a loop with those 2024-10-16 04:15:29 i suppose we have it worse anyway though because it's about hitting it once on a builder for binary distros 2024-10-16 04:15:37 as opposed to the luck of all users from source 2024-10-16 04:55:29 yeah, many users paired with just 2 packages might be the reason too 2024-10-16 04:59:34 running like a hundred loops of lxml doesn't seem to hit it for me 2024-10-16 05:10:26 mio: thanks for !16361 2024-10-16 05:10:28 #16361 2024-10-16 05:12:44 ikke: you're welcome, though it's just my effort. it's also thanks to others who report issues :) 2024-10-16 05:12:52 s/it's/it's not/ 2024-10-16 05:14:42 that is to say, not just one person's effort (sed failed) :) 2024-10-16 05:16:46 Yes, but it also takes effort to collect everything in a single ticket 2024-10-16 05:26:09 glad to do it if helps any :) 2024-10-16 05:40:26 psykose: still remember why you marked efitools to depend on gnu-efi-dev<3.0.17 gnu-efi<3.0.17 in 55a04a2f809f8e2a8cea902744d4ca2f67f5d282? 2024-10-16 05:41:17 it didn't build on aarch64 or something similar 2024-10-16 05:41:34 the < is just for rebuild ordering to downgrade before the build 2024-10-16 05:41:38 was a workaround for something 2024-10-16 05:41:42 ok 2024-10-16 05:42:05 like, if you update gnu-efi and rebuild stuff and push it, then the first builds and the rebuilds fail 2024-10-16 05:42:17 then you push a downgrade.. but the upgraded package is still there and the downgrade is not installed 2024-10-16 05:42:40 have to finish upload to delete the newer one.. so need the < for it to work at all 2024-10-16 05:44:29 yeah, the newer one will remain available and be preferred 2024-10-16 05:56:53 hmm, still fails on aarch64 2024-10-16 05:57:02 !73572 2024-10-16 06:10:07 yeah, the reason it fails was never fixed 2024-10-16 06:10:16 gnu-efi is effectively a static lib, updating it always needs rebuilds for what uses it 2024-10-16 06:10:20 it's just .o's that are linked to make efis 2024-10-16 06:12:08 i could never figure out why the .o ends up giving Invalid DOS header magic when used on aarch64 2024-10-16 08:04:03 can we add "volatile source" lint for deb.debian.org 2024-10-16 08:04:20 especially when it pulls packages from sid 2024-10-16 08:09:40 sid? 2024-10-16 08:09:47 like debian 2024-10-16 08:10:12 oh, geez, u already said 2024-10-16 08:10:15 yeah :p 2024-10-16 08:14:10 ptrc: could you file an issue against atools-go? 2024-10-16 08:14:21 sure 2024-10-16 08:16:24 Is this about all types of source files? 2024-10-16 08:18:14 AL62 now only checks for *.patch and *.diff 2024-10-16 08:20:27 mostly about tarballs, both .tar.xz and .tar.gz 2024-10-16 10:10:06 hi, can a subpackage have a different version than the main package? I'm trying to build the nim programming language which optionally builds its package manager (nimble) which is at 0.16.1 for nim v2.2.0 2024-10-16 10:13:18 tokyovigilante: no, they are tied together 2024-10-16 10:14:31 could i make origin package as meta, depends on its subpackages 2024-10-16 10:14:46 sure 2024-10-16 10:16:11 ok thanks, currently nimble is separate, relatedly, can I pull in a build requirement from a git repo in the prepare() phase of a build? 2024-10-16 11:40:12 hi all, is /etc/secfixes.d/alpine from alpine-release used by apk or some tools in minimal image? 2024-10-16 11:52:17 tokyovigilante: generally no 2024-10-16 11:53:18 tokyovigilante: we prefer build dependencies to be separately packaged 2024-10-16 13:47:33 Trying to upgrade one of the aports I'm maintaining but it seems like there now are dependencies on more locales (available in glibc). Is there some package in Alpine that support for instance LC_MEASUREMENT? Or shall I simply remove this dependency with a patch? 2024-10-16 13:50:02 hello, can I be in the gitlab group to approve PRs that are assignated to me? 2024-10-16 15:05:23 Why does mkimage.sh rely on aports? Shouldn't it be possible to build images relying soley on the binary package repos? 2024-10-16 15:21:41 something is wrong with postgresql16 seems like sometthign with time zones is broken? 2024-10-16 15:22:10 yeah, there is an MR from jirutka that already shows it failing 2024-10-16 15:28:18 waybar also has issues with timezones. Discussions indicate that a recent version of the c++ stdlib has issues parsing timezones. 2024-10-16 15:28:28 postgres also has cpp, so there might be a correlation? 2024-10-16 18:13:39 Hi folks, could I get some help with 70759 ? helix is in community, and the current way that tree-sitter stuff is installed/provided is broken so that patch implements what upstream recommends. It would be nice to have this resolved in 3.21 2024-10-16 18:15:59 I thought here was a bot for making links to MRs... so I'll be the bot beep boop https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70759 2024-10-16 18:16:37 You missed the ! prefix ;) 2024-10-16 18:17:58 ahhh 2024-10-16 18:43:21 regarding efitools: https://github.com/ncroxon/gnu-efi/issues/7 2024-10-16 18:53:49 (I don't mean to be a pain about the helix MR, it seems like the maintainer is currently too busy and it would be nice to have soon :D) 2024-10-16 18:55:38 He's facing some rough time atm 2024-10-16 18:56:46 He gave green light to merge trivial updates, but this is not that 2024-10-16 19:02:10 psykose: found a fix for efitools on aarch64 2024-10-16 19:02:31 neat 2024-10-16 19:03:41 https://github.com/ncroxon/gnu-efi/issues/7#issuecomment-2122741592 2024-10-16 19:07:54 ikke: ok, I understand, and sorry to hear... hopefully things improve for him soon. 2024-10-16 19:14:26 ikke: does that patch for aarch64 suggest that the riscv64 patch might be off? 2024-10-16 19:15:19 I'm not certain 2024-10-16 19:15:52 This issue seems to only affect aarch64 2024-10-16 19:16:16 There is a similar section for arm as well 2024-10-16 19:16:48 and it does seem to work on armv7 (at least, no error) 2024-10-16 19:17:03 also, the nixos thread for that makes it look like it will also break syslinux; but they also have a fix 2024-10-16 19:17:52 https://github.com/NixOS/nixpkgs/pull/318981 2024-10-16 19:21:55 i'm not very familiar with nix, but it looks like they only distribute x86_64 and aarch64 2024-10-16 19:22:38 ikke: do you have any suggestion for what to do in this situation, since we're close to a release, and this community package isn't working correctly? I'm currently patching it manually on my system, which is fine for me, but would be nice to have in a stable release since I'm not the only one affected by it. I'd also be happy if there was an alternative solution to what I posted in the patch. This app is a very important tool for me,... 2024-10-16 19:22:43 ... and my goal is to just have it work correctly :) 2024-10-16 19:28:09 i note that debian includes patch very similar to ours for riscv64, but not aarch64 2024-10-16 19:28:26 What version of gnu-efi does debian have? 2024-10-16 19:29:42 looking 2024-10-16 19:30:13 3.0.18 2024-10-16 19:30:23 Hmm ok 2024-10-16 19:30:30 it would affect >3.0.17 2024-10-16 19:30:33 >= 2024-10-16 19:31:00 i could test building, but i don't have hardware to actually test 2024-10-16 19:31:23 would qemu be enough for testing? 2024-10-16 19:31:42 It does build in our CI now 2024-10-16 19:31:55 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73572 2024-10-16 19:32:58 Question is if it breaks anything 2024-10-16 19:33:01 but no clue how to verify 2024-10-16 19:34:24 well, unfortunately i trash a bunch of my testing vm's recently but i can spin up a riscv one this evening for testing booting. that's the best i could do to help i'm afraid 2024-10-16 19:34:40 i don't mind doing it tho 2024-10-16 19:35:17 Would need to verify aarch64 mostly 2024-10-16 19:35:31 It least, to the affect of that specific MR 2024-10-16 19:36:14 ok, aarch64 vm then, haven't set one up in a while but i have notes 2024-10-16 20:16:42 120 new MRs in 48 hours 2024-10-16 20:50:57 How does alpine get bootstrapped? 2024-10-16 20:51:41 For a new release or a new arch? 2024-10-16 20:51:41 do you mean new architectures? 2024-10-16 20:52:01 new release 2024-10-16 20:52:12 basically from edge 2024-10-16 20:52:51 If you read back the #alpine-loongarch irc logs, ncopa explains it 2024-10-16 20:56:01 got it, thank you 2024-10-16 21:00:26 i like some of the many new MRs, they will enable me to get rid of some shameful -Wno-error=incompatible-pointer-types that i have accumulated locally :D 2024-10-16 21:26:31 craftyguy: I know jirutka has strong opinions on that 2024-10-16 21:34:15 ncopa: Heya, pretty please, review for Mesa bump + enabling the tests :) https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72897 (pipeline w/ 24.2.4 passed, now it running new 24.2.5) 2024-10-16 21:55:49 ikke: ok, I understand. I'll patiently await his return :) 2024-10-16 22:05:34 the change is correct as is, you can't use system grammars for things as they're editor specific 2024-10-16 22:05:40 the system grammar files are pretty useless 2024-10-16 22:07:16 at best you can maybe have a system .so grammar but editor-shipped highlights/injections (.scm), if you get lucky and the versions match between all editors that might use it (spoiler: they don't) 2024-10-16 22:07:26 the existing setup is just broken and straight up doesn't work 2024-10-16 22:08:01 jirutka has been told that maybe 15 times over, but refuses to accept it because well.. it means things now ship their own grammars themselves and become 'bigger' 2024-10-16 22:08:04 there's no fixing that though 2024-10-16 22:08:12 can't change how the ecosystem went 2024-10-16 22:08:42 it'll probably move again, and things will download .wasm grammars directly instead of having it be prebuilt 2024-10-16 22:09:34 soon curl is only a .wasm so it can run on even more devices 2024-10-16 22:09:55 i see it already 2024-10-16 22:09:56 wasm runs on fewer devices than curl already does so not sure what that means 2024-10-16 22:30:52 ikke: successfully built efitools on aarch64. testing by following arch's wiki (https://en.wikipedia.org/wiki/Slop_%28artificial_intelligence%29). 2024-10-16 22:33:34 built the keys and certs per arch wiki, then ran the command from https://en.wikipedia.org/wiki/Slop_%28artificial_intelligence%29 2024-10-16 22:34:20 this is a wikipedia page 2024-10-16 22:34:49 is there a command on it 2024-10-16 22:35:41 psykose: sorry wrong paste, lemme get the right one 2024-10-16 22:36:29 https://github.com/ncroxon/gnu-efi/issues/7 2024-10-16 22:37:11 too much stuff in my clipboard and paste buffers 2024-10-16 22:38:07 and result: https://tpaste.us/j1Dq 2024-10-16 22:40:21 not sure about the gaps warnings, i can sign the grubaa64.efi and kernel image then reboot to test further 2024-10-16 22:48:11 ok, signed both the kernel and the grub efi image, rebooted, everything worked as expected 2024-10-16 22:52:57 ikke: near as i can tell, efitools works fine built per the MR 2024-10-17 00:15:15 i wonder if we should move from ext4 to xfs in alpine 3.22 as default fs 2024-10-17 00:15:23 that would allow us to do deferred fsck 2024-10-17 00:22:56 that sounds interesting, for xfs deferred fsck documentation, just look up xfs docs? 2024-10-17 00:28:44 ok, found it on kernel.org/doc 2024-10-17 00:30:46 some people might not like that xfs can't be shrunk 2024-10-17 00:38:27 filesystem shrinking is not really a supported thing for alpine installs anyway... 2024-10-17 00:40:36 supported? heh, i've shrunk my ext4 fs, then parts, though admittedly i did using the usual tools, not anything specific to alpine 2024-10-17 00:41:31 takes a bit of care to not mess things up, but not too hard either 2024-10-17 01:12:50 still, i've alway been intrigued by xfs reputation for stability. 2024-10-17 01:16:48 by supported what i mean is, if you do that, we assume you know what you're doing 2024-10-17 01:18:27 thusly... if you require an FS that supports shrinking, we assume you will use `setup-disk` with `ROOTFS=ext4` 2024-10-17 01:25:45 good point. the idea of supported with things like that are difficult for me to wrap my head around. i know what you mean on an effemeral level, and realize the you are right. i've been a do-it-myself kind linux user for so long, but i will try to get my thinking in line with that concept 2024-10-17 01:32:23 Ariadne: thank you for your patience with me... i think that i can be, well, difficult to interact with at times. 2024-10-17 01:32:40 i don't really understand :) 2024-10-17 01:35:15 well you made your point very succinctly and i appreciate it. i guess that's the long and the short of it. 2024-10-17 01:37:46 https://www.kernel.org/doc/html/latest/filesystems/xfs/xfs-online-fsck-design.html#id25 2024-10-17 01:38:14 that bit makes me wonder if xfs deferred fsck is right fit for me 2024-10-17 01:48:26 none of that is really different on other FSes 2024-10-17 01:48:33 xfs just tends to be honest and robust about its decisions and design 2024-10-17 01:48:40 but it's your system, of course 2024-10-17 01:51:28 i really should try it on one of my next installs 2024-10-17 04:44:48 j_v: thanks for confirming 2024-10-17 06:16:01 I'm trying to build util-linux in an alpine chroot and getting a bunch of "fatal library error, lookup self" during the check (host system is arch on x86_64) 2024-10-17 06:21:01 anyone has an idea of this error: 2024-10-17 06:21:01 ERROR: Clock skew detected. File /usr/bin/python3.12 has a time stamp 166726.7427s in the future. 2024-10-17 06:21:20 it appears on aarch64 builder with py3-numpy 2.1.2 2024-10-17 06:21:20 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1547264 2024-10-17 06:24:32 it was run on the 7th but in the log it says it is the 5th, so i think the ci has/had wrong time information 2024-10-17 06:25:56 that would approximately match the number of seconds too 2024-10-17 06:43:19 ncopa: ^ 2024-10-17 06:57:46 the CI clock appears to be correct 2024-10-17 06:57:57 Thu Oct 17 08:55:42 CEST 2024 2024-10-17 06:59:01 Thu Oct 17 06:58:46 UTC 2024 2024-10-17 06:59:01 and in the container: 2024-10-17 07:00:15 ok, this is interesting 2024-10-17 07:00:30 i mean, that was 10 days ago, might've been intermittent 2024-10-17 07:00:41 yeah, every meson configure would fail if that was still an issue 2024-10-17 07:01:10 looks at this though 2024-10-17 07:01:13 (3/17) Installing libffi (3.4.6-r0) 2024-10-17 07:01:13 # date && apk add python3 && ls -l /usr/bin/python3* 2024-10-17 07:01:13 (1/17) Installing libbz2 (1.0.8-r6) 2024-10-17 07:01:13 (2/17) Installing libexpat (2.6.3-r0) 2024-10-17 07:01:13 Thu Oct 17 07:00:50 UTC 2024 2024-10-17 07:01:14 (4/17) Installing gdbm (1.24-r0) 2024-10-17 07:01:14 (5/17) Installing xz-libs (5.6.3-r0) 2024-10-17 07:01:16 (6/17) Installing libgcc (14.2.0-r3) 2024-10-17 07:01:16 (7/17) Installing libstdc++ (14.2.0-r3) 2024-10-17 07:01:18 (9/17) Installing ncurses-terminfo-base (6.5_p20241006-r0) 2024-10-17 07:01:18 (8/17) Installing mpdecimal (4.0.0-r0) 2024-10-17 07:01:20 (10/17) Installing libncursesw (6.5_p20241006-r0) 2024-10-17 07:01:20 (11/17) Installing libpanelw (6.5_p20241006-r0) 2024-10-17 07:01:22 (12/17) Installing readline (8.2.13-r0) 2024-10-17 07:01:22 (13/17) Installing sqlite-libs (3.46.1-r0) 2024-10-17 07:01:24 (15/17) Installing python3-pycache-pyc0 (3.12.7-r0) 2024-10-17 07:01:24 (14/17) Installing python3 (3.12.7-r0) 2024-10-17 07:01:26 (16/17) Installing pyc (3.12.7-r0) 2024-10-17 07:01:26 (17/17) Installing python3-pyc (3.12.7-r0) 2024-10-17 07:01:28 OK: 115 MiB in 32 packages 2024-10-17 07:01:28 Executing busybox-1.36.1-r32.trigger 2024-10-17 07:01:30 lrwxrwxrwx 1 root root 10 Oct 17 07:00 /usr/bin/python3 -> python3.12 2024-10-17 07:01:30 -rwxr-xr-x 1 root root 67240 Oct 7 07:18 /usr/bin/python3.12 2024-10-17 07:01:32 the date of the symlink 2024-10-17 07:02:08 seems it gets created with current time 2024-10-17 07:02:18 seems so yes 2024-10-17 07:02:50 i think that's unrelated, since the symlink is unversioned but the meson check checks the full resolved path (the oct 7) 2024-10-17 07:03:02 ok 2024-10-17 07:03:06 or it could print not what it's checking but i'll assume it's correct 2024-10-17 07:03:45 and with that oct 7 and when the ci ran on oct 8, the date inside that container said.. oct 5 2024-10-17 07:03:46 or whatnot 2024-10-17 07:03:59 im restarting the job, assuming it was a temp issue, probably related that pyhon3 upgrade 3684db7d5a98ede0e87cce6001310d4f52787dcf 2024-10-17 07:04:25 it was reproducible multiple times but it's weird it wouldn't affect other mrs 2024-10-17 07:04:54 that ci runs in a vm on a mackbook, under macos 2024-10-17 07:05:20 it used to have problem with time when it went to sleep 2024-10-17 07:05:32 i guess it went to sleep for 2 days and then didn't advance time 2024-10-17 07:05:38 exactly 2024-10-17 07:05:44 i think that should be fixed now though 2024-10-17 07:05:47 yea 2024-10-17 07:06:31 i use sntpc, a stupid and simple ntp client that will just set the time every N seconds, but never let the time jump backwards 2024-10-17 07:06:57 -rw-r--r-- 1 root root 201 Oct 5 22:38 /etc/conf.d/sntpc 2024-10-17 07:07:03 and it was set up around that time 2024-10-17 07:07:37 it passed now 2024-10-17 07:09:22 Thx ncopa 2024-10-17 07:38:14 ikke: welcome, glad to help 2024-10-17 07:56:32 how long can tpaste store the msg? 2024-10-17 07:59:20 tpaste does not expire 2024-10-17 07:59:37 ok, got it 2024-10-17 08:09:00 what if you get out of space then? 2024-10-17 08:15:42 then we either add space or shut down the service 2024-10-17 08:16:00 or change the service to expire 2024-10-17 08:30:55 does anyone how could I set this patch for don't fail on each new version? https://tpaste.us/Dreq 2024-10-17 08:31:18 I could use 'sed' instead 2024-10-17 08:31:58 i use sntpc, a stupid and simple ntp client that will just set the time every N seconds, but never let the time jump backwards 2024-10-17 08:32:11 but what if a system clocks drifts *forward*? 2024-10-17 08:33:06 I know how backwards jumps are annoying, but if you're adjusting the time every few seconds, the jump can't be that bad, even if it's backwards 2024-10-17 08:39:18 well fixed, I just left the comment line untouched so patch doesn't deppend on the version number 2024-10-17 08:40:23 oh no, they are there -_- 2024-10-17 08:42:57 You could create the patch with -U0 2024-10-17 08:43:09 Not sure if that's a good idea though 2024-10-17 08:43:31 https://tpaste.us/BM6Y 2024-10-17 08:43:48 try? I was trying to do with sed but it seems more uggly 2024-10-17 08:45:20 donoban: sed in APKBUILDS can fail silently, whereas a patch will at least fail, forcing you refresh or fix it some other way, just my 2cents 2024-10-17 08:45:52 yeah I prefer to use the patch, it works fine with -U0 2024-10-17 08:46:09 is just a meson build option, hard that it messes something 2024-10-17 08:46:25 j_v: same for me 2024-10-17 09:10:06 -u or -U ? 2024-10-17 09:10:25 U 2024-10-17 09:10:51 is it for patch(1) ? 2024-10-17 09:11:20 diff 2024-10-17 09:11:26 aahhh ok thanks 2024-10-17 11:29:29 hello, can someone review !73153 please? 2024-10-17 12:50:14 i suspect that a recent tzdata update broke postgresql 2024-10-17 12:52:53 skarnet: if system clocks drifts forward you dont use sntpc. it was designed for VMs where time drifts backwards 2024-10-17 12:53:33 ncopa: we could try to revert c889907b048f8cc7ab42499b912348aa96dd1ee8 locally and see if psql builds 2024-10-17 12:53:50 let me try that locally 2024-10-17 13:52:23 hello again, can someone review this one too please? !73594 2024-10-17 14:17:45 PayPal... (full message at ) 2024-10-17 14:54:51 i tried to revert c889907b048f8cc7ab42499b912348aa96dd1ee8 and the tests for postgresql passes, but there are some tests that fails with libxml2 too 2024-10-17 15:22:11 sdl3 did a "preview" release, is it something that can get merged or we're waiting for a regular release? 2024-10-17 15:24:15 We're close to a new release, so I would not upgrade an existing package to a pre-release 2024-10-17 15:25:14 ack 2024-10-17 15:25:41 Except if it's in testing, then it would not matter a lot, but I assume that's not the case 2024-10-17 15:25:51 yeah the package is for testing 2024-10-17 15:26:17 nothing depends on it atm, i was using sdl3 for a project but i think im alone 2024-10-17 15:26:34 I mean, in the testing repository 2024-10-17 15:26:46 yep 2024-10-17 15:26:58 !73683 2024-10-17 15:27:08 Ok, then I see no harm 2024-10-17 15:28:03 the close notif from !62841 reminded me i had to update it 2024-10-17 15:29:32 ah 2024-10-17 15:59:53 i think i solved the postgresql issue(s) 2024-10-17 15:59:59 nice 2024-10-17 16:00:51 with help from #postgresql on Libera. they helped me find the commit 2024-10-17 16:05:36 i think port meilisearch can be removed in new release. long time no upgrade, long time to build :( 2024-10-17 16:09:52 https://github.com/meilisearch/meilisearch/issues/4377#issuecomment-1919331826 2024-10-17 16:10:10 hum. postgres have issues with xml 2024-10-17 16:10:15 I/O error : Attempt to load network entity: http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd 2024-10-17 16:10:15 postgres.sgml:21: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.5 2024-10-17 16:10:31 postgres.sgml:23: element book: validity error : No declaration for attribute id of element book 2024-10-17 16:10:31 ^ 2024-10-17 16:10:31 2024-10-17 18:11:41 PayPalā€ØCashappā€ØApple Payā€ØCpnsā€ØDave methodā€ØCoinbase loadingā€ØAirb&bā€ØVerizonā€ØiPhone 15 methodā€ØApple product methodā€ØVermont Rent reliefā€ØSba methodā€ØCardingā€Øcc sitesā€ØGas station Sauce ( free gas )ā€Øbank dropsā€ØWells Fargo Loan sauceā€ØShein methodā€Øhttps://t.me/+32cFzLuOiacxZmM0 PayPalā€ØCashappā€ØApple Payā€ØCpnsā€ØDave methodā€ØCoinbase loadingā€ØAirb&bā€ØVerizonā€ØiPhone 15 methodā€ØApple product method 2024-10-17 18:11:42 Vermont Rent reliefā€ØSba methodā€ØCardingā€Øcc sitesā€ØGas station Sauce ( free gas )ā€Øbank dropsā€ØWells Fargo Loan sauceā€ØShein methodā€Øhttps://t.me/+32cFzLuOiacxZmM0 2024-10-17 18:25:29 \o/ 2024-10-17 18:36:56 \o/ 2024-10-17 18:37:13 algitbot doesn't rejoice with us anymore :( 2024-10-17 18:38:26 maybe it is tired 2024-10-17 18:38:28 algitbot: please 2024-10-17 21:46:19 with https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/318 we should update CODINGSTYLE.md and probably other documentation 2024-10-17 21:58:06 on it 2024-10-17 22:30:06 <3 2024-10-17 22:31:29 included in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66219 2024-10-17 22:31:36 ncopa: what are your thoughts on switching from ext4 to xfs by default? 2024-10-17 22:39:21 fwiw we did it about a year? two years ago? for the handbook recommendation and had 0 complaints, we just made sure to state that shrinking means you should choose something else 2024-10-17 22:39:30 having reflinks and c_f_r is really nice 2024-10-17 22:39:42 nice to see it being considered here as well 2024-10-18 00:43:23 ncopa: any objections to !70567 2024-10-18 00:44:19 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70567 - community/qemu: enable xen support 2024-10-18 02:45:35 Hey team, why is abuild trying to run a git ls-files on my downloaded source archive (which isn't a git repo)? 2024-10-18 02:58:10 sorry, it was from the tool I'm building, not abuild 2024-10-18 09:11:15 this maintainer variable thing is a big change, that I don't think I disagree with but haven't followed the discussion leading to it 2024-10-18 09:12:05 as a replacement to # Maintainer: comments, it doesn't pop out as visibly to the human reader 2024-10-18 09:13:10 not sure about how to handle that, keep both? although that seems a bit redundant 2024-10-18 09:15:15 or perhaps could the maintainer variable always be preceeded by a # Maintainer: comment? (without the duplicate of name and email) 2024-10-18 09:19:36 I wouldn't mind, too much, dropping the # Contributor: comment, although it is a way to give people cred, it's use is quite random and there is always the git log (or git blame) if you're really interested 2024-10-18 09:25:28 something I've been missing is a way to have multiple maintainers for an aport, or perhaps a way for a maintainer to declare what changes to their aport they are fine with without being consulted or being able to respond within a certain time 2024-10-18 09:25:36 yeah, it was pushed the wrong way. that was my bad 2024-10-18 09:25:37 sorry 2024-10-18 09:26:52 I know that we want and need a responsible maintainer for an aport, but we work around the requirement of a single one by having teams for larger projects, for example 2024-10-18 11:02:11 i was a bit confused about that, since newapkbuild created a `maintainer=` line but apkbuild-lint complains about it: IC:[AL6]:./APKBUILD:1:prefix custom variable with _: maintainer= 2024-10-18 12:26:13 atools is archived? https://gitlab.alpinelinux.org/Leo/atools 2024-10-18 12:55:35 how long is a reasonable time to wait for a review of a MR? 2024-10-18 13:23:50 everybody is busy, forget i asked 2024-10-18 13:34:42 j_v if you're stuck and need help best to ping here and ask, but it's just busy lately. New aports take a while to be reviewed typically, where bumps to packages you maintain go through rather quickly if everything passes CI 2024-10-18 13:39:33 durrendal: thanks, i get it. it's not a new aport, but one that has gathered some dust and i'm trying to take maintainership of it. i've already emailed the current maintainer, no answer, no bounce, and no aports activity since 2018/2019. 2024-10-18 13:43:08 but like you said, it is very busy lately and likely to be until 3.21 posts, maybe longer, or so i would guess. it isn't that important to get taken care of right away. i am using the bumped and adjusted aport here from my private local repo. so it can wait. i tend to get impatient, but is good for me to practice patience. 2024-10-18 13:44:00 j_v: what's the MR? 2024-10-18 13:45:32 omni: !73446 2024-10-18 13:46:31 hmm, was expecting algitbot to show link, may i got the number wrong 2024-10-18 13:46:40 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73446 2024-10-18 13:46:41 I think algitbot is sleepy 2024-10-18 13:47:32 those pesky stable releases sure do slow us down :P I'm certain your MR will go through it's likely just a little buried right now 2024-10-18 13:48:50 yeah, thanks for encouragement. like i said, is good for me to practice patience. in grand scheme of things there are much more important things going on, like the usr-merge and such like 2024-10-18 14:14:20 no problem, and trust me, I am right there with you. I get pretty fired up about some of the things I maintain, it's easy to focus on that and put blinders up 2024-10-18 14:15:52 speaking of things taking a while, is the gitlab slow just for me or everyone today? 2024-10-18 14:16:15 yeah, was just going to say 2024-10-18 14:17:09 hmm yes I noticed the same thing as well 2024-10-18 14:17:39 ok, so i didn't refresh my tabs to often and got rate-limited :D 2024-10-18 14:18:41 hahaha no I don't think so 2024-10-18 14:23:23 well, i should stop doing that anyway, the email notifications should be enough, and i only need the git part, not the web part to work on my stuff 2024-10-18 14:25:34 gitlab has an API and a cli tool (glab), I don't use the web frontend very often myself, almost all of my workflow is cli driven 2024-10-18 14:27:01 gg 2024-10-18 14:27:44 something is causing quite some load. L 2024-10-18 14:27:55 Will check it in a bit 2024-10-18 14:29:32 i'm just cleaning up/collecting my patches for SuperH while i try to build the last "few" packages from main, so i really should have no need to look at the website all the time 2024-10-18 14:37:47 fossdd: i've made the changes, but something's not going right, could be i didn't rebase right, could be gitlab not updating the info, might be a mix of the above. will try to get glab cli working for me 2024-10-18 14:48:20 which scopes do i need to enable for the api token? 2024-10-18 14:48:39 Api and repo_write should ge sufficient 2024-10-18 14:49:12 thank you 2024-10-18 14:51:34 I'm getting 500s again on gitlab.a.o 2024-10-18 14:57:15 yeah gitlab is sluggish / unresponsive for me as well. 2024-10-18 14:59:40 ah seems some maintainance is going on 2024-10-18 15:01:11 Not by me 2024-10-18 15:01:36 Just got a message that it is booting up 2024-10-18 15:02:14 Possibly oom 2024-10-18 15:03:05 yeah 2024-10-18 15:08:38 Seems like something more profound. As the api is also non-responsive. 2024-10-18 15:09:22 I'm stopping gitlab now to help it recover 2024-10-18 15:09:51 Lots of git processes 2024-10-18 15:13:29 gitlab is up again 2024-10-18 15:14:08 Yep works for me. 2024-10-18 15:14:53 I have a feeling something triggers some extra load and it fails to recover from that 2024-10-18 15:16:13 uhh !73723 is kinda stuck i guess? 2024-10-18 15:17:26 appears so 2024-10-18 15:17:44 can you amend the commit and force push to see if that unstucks it? 2024-10-18 15:18:20 good idea. pushed 2024-10-18 15:18:31 yup, that helped 2024-10-18 15:18:37 ah yeah, thanks 2024-10-18 18:43:39 thanks fossdd[m], i appreciate your help 2024-10-19 01:10:12 ncopa: you added a patch to alpine to load linux-gnu.so and well as linux-musl.so modules in py3 in 6ad1b1f09f10f406e90ea8471fe5f3ff1942448b but this patch is now gone so is it fixed somehow in newer versions of python3 3.11+ 2024-10-19 09:58:26 where did the buttons for rerunning pipelines go? 2024-10-19 10:04:35 omni: after seeing your comment, i went into !73446 to see if i could rerun the failed jobs, and that worked. but perhaps that is not what you meant? 2024-10-19 10:06:25 oh, maybe you meant the ones that used to for rerunning to whole pipeline? 2024-10-19 10:08:02 yeah, sorry, don't see that anymore either 2024-10-19 10:10:05 I'm at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73739 and both at the failed pipeline symbol dropdown menu and at the top right corner of a failed job, https://gitlab.alpinelinux.org/kvendingoldo/aports/-/jobs/1564748 for example, is where I think I used to have a re-run pipeline button 2024-10-19 10:10:15 perhaps it's hidden from my browser 2024-10-19 10:17:20 i've tried both librewolf and firefox, and i don't see them in either 2024-10-19 10:17:54 i thought i'd seen them before 2024-10-19 10:19:35 gaslitlab 2024-10-19 10:22:09 frustrating, but i'm not sure what would be better without a huge amount of time investment to get running (not to mention the maintainence)... github is certainly not a better option imo 2024-10-19 10:25:18 omni: the mr was created from the master branch 2024-10-19 10:25:23 Which is protected 2024-10-19 10:30:03 ikke: I noticed, so I cannot rebase it etc, but is that also why I cannot rerun pipelines without doing changes? 2024-10-19 10:30:23 Yeah, that's linked 2024-10-19 10:31:45 ah, thanks 2024-10-19 10:34:42 and I see the buttons for other MRs, now when I look, sorry about that 2024-10-19 16:12:45 ncopa: figured, it your patch to py3 was ok for native case but since it checked build_os it did not work well when py3 was cross compiled because in cross compile case build_os != host_os but I see that its fixed upstream with https://github.com/python/cpython/commit/c163d7f0b67a568e9b64eeb9c1cbbaa127818596 2024-10-19 17:52:24 Hello guys. I'm here because I'm new on Alpine Linux (from Devuan), but I want to build LibreWolf from source. I know Alpine Linux uses Musl instead of GNU libraries, but I want to build it anyway. I think it's possible to do this because of the "librewolf" package of the "testing" repo.The thing is, what should I do if the `./mach bootstrap` command fails? 2024-10-19 17:52:57 ruikkaa: Look for existing patches that are applied 2024-10-19 17:53:54 @ikke: Such as https://github.com/8l/firefox_alpine/blob/master/alpine.patch ? 2024-10-19 17:54:51 https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/librewolf 2024-10-19 17:59:16 Going to do some maintenance on gitlab and it will be unavailable for a couple of minutes 2024-10-19 18:01:39 @ikke: Thank you for that link. It will be very useful :) 2024-10-19 18:12:32 gitlab is back 2024-10-19 18:40:37 ikke: quick work 2024-10-19 18:46:29 It's all automated, just need to kick it off :) 2024-10-19 18:53:14 ahhh, cool 2024-10-19 21:01:36 PureTryOut: messagelib keeps hanging on x86 2024-10-19 21:06:52 I noticed, not sure why. It got through at least once but had a test failing. That should be fixed but not sure why it keeps hanging 2024-10-19 21:08:01 Last log shows 132 - webengineviewer-webengineexportpdfpagejobtest (Failed) 2024-10-19 21:09:18 yeah I know, because qt6-qtwebengine is completely broken on x86. Personally I rather get rid of that package on that arch entirely but seems some people want it even though it's broken 2024-10-19 21:09:44 I just disabled the test šŸ¤· 2024-10-19 21:10:12 anyway, that's not what it's stuck on 2024-10-19 21:13:58 still fails 2024-10-19 21:21:47 mio: heh, just wanted to mark ruby-nokogiri as fixed, but you were just ahead of me :P 2024-10-19 21:21:59 ikke: :) 2024-10-19 21:23:45 will leave the honours to you next time 2024-10-19 21:23:54 no worry :) 2024-10-19 21:24:29 okay :) 2024-10-19 21:58:18 doesn't qutebrowser use qt6-qtwebengine or am i mistaken? if it does use qt6-qtwebengine, then i can report, that i'm happily using qutebrowser with that broken qt6-qtwebengine and have not noticed anything being broken. 2024-10-19 21:59:01 bOR38552MJA: are you using it on 32b x86? 2024-10-19 21:59:31 oh, no, x86_64. ah, that was not clear for me that this is 32 bit 2024-10-19 21:59:48 x86 on it's own is a bit ambigous 2024-10-19 22:00:29 sure, but I think we usually mean 32b here, since we have both 2024-10-19 22:00:56 but probably not always 2024-10-19 22:01:30 I try to be specific and say x86_64 when I'm talking about the 64b one 2024-10-19 22:01:30 interesting, wasn't aware that alpine uses x86 naked for 32bit, my bad. sorry for making noise 2024-10-19 22:02:07 not at all, probably good to clarify from time to time 2024-10-19 22:09:47 now with the maintainer variable, are MRs not auto-assigned? 2024-10-19 23:01:30 PureTryOut: khotoalbum passed in CI but looks like it keeps on failing on the armv7 package builder 2024-10-20 05:01:16 stopping gitlab really quick to fix a docker issue 2024-10-20 09:24:35 omni: just a note, whenever you see a package on armv7 fail with "xvfb-run: error: Xvfb failed to start", the solution is to add `-a` to the `xvfb-run` invocation. Strangely that's only required on armv7, no clue why 2024-10-20 09:25:36 Also omni, I pinged you on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73248. Could you help me out there with qt6-qtwebengine? 2024-10-20 09:35:00 sorry, missed that, I'll see if I have something 2024-10-20 09:39:26 PureTryOut: it looks like what I hit in https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72669 right? 2024-10-20 09:41:05 Ah yes, that's the same thing 2024-10-20 09:43:09 and I see that we're now on the 122-based branch 2024-10-20 09:45:35 Yes, but that doesn't fix the problem sadly. I don't see any patch for this in the Chromium package, neither when we still were around the 122 release 2024-10-20 09:59:54 yeah, the breaking change is likely in both branches 2024-10-20 10:00:04 huge repo is huge... 2024-10-20 10:09:07 Yeah... 2024-10-20 10:18:46 just pushed busybox 1.37.0 let me know if you notice any regressions 2024-10-20 14:21:44 ikke: thanks for the ifstate merges; sorry I forgot to add some details in the stable MR - I was in a hurry ;) 2024-10-20 14:22:08 np, I was asking just to be sure 2024-10-20 14:22:18 the changelog on the website stil misses 1.13 btw 2024-10-20 14:32:11 yes, updating website changelog+schema and schemastore MR is on my todo 2024-10-20 14:33:49 nod 2024-10-20 21:52:54 trying to get system init messages to hit both VGA and serial console -- but despite what https://docs.kernel.org/admin-guide/serial-console.html says, when I specify console=ttyS0,115200n8 console=tty0 on kernel command line, i'm only seeing output on serial until the boot switches to initrd. 2024-10-20 21:54:23 only have access to screenshot of VGA, so I only know that the init output ends up there, but don't know about the pre-initrd stuff 2024-10-21 00:36:26 andypost[m]: looks like the php83 upgrade is failing on the s390x package builder 2024-10-21 01:36:16 Hi šŸ‘‹... (full message at ) 2024-10-21 05:13:15 nmeum: I think I've hit a busybox awk regression https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73866 2024-10-21 05:14:00 (it was mio who brought my attention to it) 2024-10-21 08:10:32 How did loongarch64 pass 3.21 postgresql build while all other arch failed? 2024-10-21 08:10:49 !check 2024-10-21 08:11:01 same with riscv64 2024-10-21 08:11:18 Oh, so it is just broken on those arches. 2024-10-21 08:12:54 don't know if it is broken on loongarch64, huajingyun might know 2024-10-21 08:13:47 the test-image used in check doesn't cover loongarch64 was probably the reason for !check there 2024-10-21 08:16:39 nvm about test-image, that's a different aport 2024-10-21 08:16:51 only comment was broken tests 2024-10-21 09:57:15 im working on postgresql now. I think I finally have a fix for it 2024-10-21 09:57:26 its missing docbook-xsl in makedepends 2024-10-21 10:38:41 omni: I think it's better to disable failed tests for s390x if php83 still fail 2024-10-21 10:40:59 ncopa: roberto32[m] is a spammer 2024-10-21 10:52:15 f_: seems like im not at chan op currently 2024-10-21 10:52:27 will figure out how to become chan op when I get home 2024-10-21 10:52:36 > -ChanServ- 3: ncopa MASTER 2024-10-21 10:52:48 you seem to be MASTER so you should be able to /cs op #alpine-devel 2024-10-21 10:53:21 thanks! 2024-10-21 10:53:24 np 2024-10-21 10:53:56 be sure to kick them too .. seems to be a bridged matrix user and the bridge doesn't properly handle +b without a kick 2024-10-21 11:15:22 finally. postgresql is fixed 2024-10-21 11:17:33 \o/ 2024-10-21 11:23:14 \o/ 2024-10-21 12:57:36 omni: reported upstream and let's wait tests !73887 2024-10-21 13:04:11 šŸ‘ 2024-10-21 13:55:36 Could anybody click the button at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73826 ? 2024-10-21 14:31:17 which button 2024-10-21 14:36:05 The one they ncopa pressed 2024-10-21 14:36:13 that* 2024-10-21 14:38:34 thanks for pressed the button 2024-10-21 14:49:55 there are many things I'm not good at, but pressing buttons I can do. 2024-10-21 15:18:02 And you also know quite well what buttons to press 2024-10-21 15:20:03 thank you for your press of the button 2024-10-21 15:31:25 expertise work: 1 second to press the button, 20 years to learn what button to press and when 2024-10-21 15:46:48 ncopa: there are a couple trivial /usr merge patches ready from Clayton last week 2024-10-21 15:48:23 !73510 !73514 !73516 and !73519 2024-10-21 15:48:53 Not sure why algitbot no longer does that, let me take look 2024-10-21 15:48:55 take a look 2024-10-21 15:49:16 lake at took 2024-10-21 15:50:13 please take a look and press the appropriate buttons at the appropriate time :) 2024-10-21 15:51:13 algitbot: welcome back! 2024-10-21 15:51:18 !73510 !73514 !73516 and !73519 2024-10-21 15:51:27 algitbot: please behave 2024-10-21 15:57:09 welcome back algitbot \o/ 2024-10-21 15:58:51 Thanks both! 2024-10-21 17:10:17 algitbot: have you been taught yet to also act on the maintainer variable? 2024-10-21 17:10:55 Good question 2024-10-21 17:11:10 I suppose you mean aports-qa-bot 2024-10-21 17:11:31 I guess 2024-10-21 17:11:48 is this too related to the busybox upgrade: 2024-10-21 17:11:50 ERROR: Clock skew detected. File /bin/busybox has a time stamp 10777.4026s in the future. 2024-10-21 17:11:52 ? 2024-10-21 17:12:36 aports-qa-bot needs to be updated 2024-10-21 17:15:12 some additional eyes on !73884 could be good 2024-10-21 17:15:24 algitbot: :* 2024-10-21 17:18:29 I got stuck earlier and had to leave for a bit, will probably look at it again later 2024-10-21 17:18:48 but the sooner those could be upgraded the better, I think 2024-10-21 17:20:12 (there was no slug emoji so I had to retort to the šŸŒ) 2024-10-21 17:42:08 to confirm: we are not switching to the `gold` linker in alpine 3.21, right? it is effectively abandoned by google 2024-10-21 17:42:33 I have not seen any such change 2024-10-21 17:42:48 Nor was it discussed that I'm aware of 2024-10-21 17:42:49 ok, good :) i just saw something on #musl that was eyebrow raising 2024-10-21 17:44:30 epiphany and loupe passed in gitlab CI with busybox 1.37.0-r1 so perhaps not new busybox is to blame for why they fail on the package builders 2024-10-21 17:45:13 Let me check on the builder 2024-10-21 17:46:46 Modify: 2024-10-21 20:09:51.000000000 +0000 2024-10-21 17:46:53 mtime seems to be in the future indeed 2024-10-21 17:46:58 but time on the host is correct 2024-10-21 17:50:48 Not sure why, but the mtime of the busybox binary in the package is in the future 2024-10-21 17:51:58 omni: It does mean it will eventually be fixed later today 2024-10-21 17:54:45 nmeum: Any idea why the busybox binary has an mtime in the future? It happens accross multiple architectures (separate hosts). Maybe caused by the bb upgrade? 2024-10-21 18:21:54 fwiw mold is in good shape 2024-10-21 18:31:39 created #16551 2024-10-21 18:43:08 ikke: a couple of machines have started complaining about clock skew during boot, haven't seen that in a while, could it be related? 2024-10-21 18:43:28 nmeum: ^^ 2024-10-21 18:48:40 I explained it here https://gitlab.alpinelinux.org/alpine/aports/-/issues/16551#note_447979 2024-10-21 18:51:35 Hmm, so the commit is dated in the future 2024-10-21 18:51:44 yep 2024-10-21 18:52:24 because I have a post-commit hook which runs https://pkgs.alpinelinux.org/package/edge/community/x86_64/git-shuffle 2024-10-21 18:52:31 though I wasn't previously aware that it would result in issues like this 2024-10-21 18:53:00 meson is rather time sensitive 2024-10-21 18:53:37 ncopa had issues with a runner running on a vm on his laptop where the time ran behind due to it sleeping 2024-10-21 18:53:38 I don't think we should use the commit time for SOURCE_DATE_EPOCH 2024-10-21 18:53:49 but for now we could just rebuild busybox with a new commit 2024-10-21 18:53:53 or wait one hour 2024-10-21 18:54:05 It's one of the few sensical things for reproducable builds 2024-10-21 18:54:18 maybe we should have a test for this in CI 2024-10-21 18:54:27 verify that commit date is not in future 2024-10-21 18:54:59 ikke: yea, we should set it to something we control though 2024-10-21 18:55:59 The problem is that if others rebuild the package, it should have the same information 2024-10-21 18:56:14 *nod* 2024-10-21 18:57:07 nice typo 2024-10-21 18:57:15 aaarrgs 2024-10-21 18:57:52 shouldn't just take the first vim autocorrect match without double checking ':D 2024-10-21 18:58:37 anyway, good to know that git-shuffle causes issues here. I will keep this in mind and sorry for the confusion caused by this 2024-10-21 18:58:50 LOL 2024-10-22 04:23:36 Here are some of the things you can find on my channel:... (full message at ) 2024-10-22 07:40:43 I hate this matrix spam, just saying 2024-10-22 12:22:51 i thin kwe may have an issue 2024-10-22 12:23:04 we set various CARGO_* env vars 2024-10-22 12:23:38 but apparently some of those hurts the stack usage, which makes librsvg overflow the stack 2024-10-22 12:24:06 so maybe we should drop some of those settings 2024-10-22 12:24:47 but now we have are building world already, so I dont know if we want rebuild everything touching rust? 2024-10-22 12:26:51 how far are we on building world? aren't we stuck on main/ and most rusty aports are in community/ and testing/ ? 2024-10-22 12:34:37 #16520 2024-10-22 12:55:32 or we could only unset those for librsvg 2024-10-22 12:56:06 and hope nobody else calls rust code from threads 2024-10-22 12:59:26 what flags are we talking about? 2024-10-22 13:00:03 oh, now all of https://gitlab.gnome.org/GNOME/librsvg/-/issues/1132 loaded 2024-10-22 13:02:13 these are unset for a few aports already 2024-10-22 13:46:46 ha! 2024-10-22 13:47:02 unset CARGO_* does not work at all 2024-10-22 13:47:07 fun... 2024-10-22 13:47:33 because abuild-meson will source /usr/share/abuild/functions.sh and again set them 2024-10-22 15:32:53 not that many are set by default.conf and you many not want to unset them all 2024-10-22 15:55:00 here's the reasoning behind the defaults https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/135 2024-10-22 15:56:08 and https://doc.rust-lang.org/cargo/reference/profiles.html says "It is recommended to experiment with different levels to find the right balance for your project" (read "aport") 2024-10-22 16:07:33 what's up with 3.20 builders, looks like they stuck in pulling git 2024-10-22 16:15:23 seems like git pull is hanging for quite a long time 2024-10-22 16:16:53 seems like it's unstuck now 2024-10-22 16:21:56 ikke: thank you 2024-10-22 16:22:31 andypost[m]: I didn't do anything :P 2024-10-22 16:24:46 seems like presence is enough) 2024-10-22 20:49:45 ncopa: what are your thoughts on introducing something like eclasses to aports? 2024-10-23 06:59:11 Ariadne: avoiding eclasses was one of the original design goals 2024-10-23 06:59:41 eclasses makes it difficult and complicated to understand what is actually going on 2024-10-23 07:00:08 I remember I had to search through lots of different files, that pulled in stuff from other files again 2024-10-23 07:00:18 so it was difficult to see what was actually happening 2024-10-23 07:01:00 so I originally wanted the APKBUILDs to be simpler, even it meant redundant/repetitive APKBUILDs 2024-10-23 07:01:14 it becomes clear what is going on for first time users 2024-10-23 07:03:28 hello, please have a look on !73594 !73153 and !72559 (would be much appreciated) 2024-10-23 07:15:45 i have more than enough to do with fixing the existing stuff, so adding new is not a prio for me, sorry 2024-10-23 07:15:57 i also need to follow up whats going on the the rpi imager 2024-10-23 07:16:10 got an email "dont you use apk?" and never heard anything since 2024-10-23 07:16:30 xen is also broken with gcc 14, and it is non-trivial 2024-10-23 07:16:36 and blocks the 3.21 builders 2024-10-23 07:59:48 do we dare upgrade openssl 3.4 at this point? 2024-10-23 08:03:57 Not sure at this point in time 2024-10-23 08:14:09 ncopa, no problem 2024-10-23 09:25:06 something broke 2024-10-23 09:25:18 my aarch64 VM no longer boot? 2024-10-23 09:25:39 ^MLoading Linux virt ... 2024-10-23 09:25:39 EFI stub: ERROR: Failed to allocate memory 2024-10-23 09:25:39 ^MLoading initial ramdisk ... 2024-10-23 09:25:39 ^MEFI stub: Decompressing Linux Kernel... 2024-10-23 09:25:40 Error: Image at 0023A5EC000 start failed: Not Found 2024-10-23 09:25:40 error: start_image() returned 0x800000000000000e. 2024-10-23 09:25:42 ^M Failed to boot both default and fallback entries. 2024-10-23 09:33:41 Error: Image at 0043A2DE000 start failed: Not Found 2024-10-23 09:37:10 heads up! the 6.6.58 virt kernel does not boot on aarch64 for some reason 2024-10-23 09:37:18 only tested edge 2024-10-23 09:50:16 ok seems like it boots on 3.20 2024-10-23 09:50:18 phew 2024-10-23 09:51:40 i wonder if it may be related gnu-efi 3.0.17? 2024-10-23 10:21:59 How does gnu-efi affect the kernel image? 2024-10-23 10:23:10 generally doesn't 2024-10-23 10:23:41 was thinking grub did something with it, but even that does not make sense 2024-10-23 10:23:41 it could, if your kernel image was an EFI executable (like a UKI) made with a stub that was done with gnu-efi 2024-10-23 10:23:55 we did discover that the vmlinuz image was way too smal 2024-10-23 10:23:58 60k 2024-10-23 10:24:02 on aarch64 2024-10-23 10:24:09 while on 3.20 it was 900k something 2024-10-23 10:24:10 sounds wrong? it should be at least a few megs 2024-10-23 10:24:14 yup 2024-10-23 10:24:26 so something is wrong with the vmlinuz image 2024-10-23 10:24:31 on loongarch its' 44k 2024-10-23 10:24:35 need to investigate what is going on 2024-10-23 10:24:38 900k is too small too 2024-10-23 10:24:44 q66: it's the virt image 2024-10-23 10:24:50 virt kernel* 2024-10-23 10:25:03 maybe bb update? 2024-10-23 10:25:11 i guess you could it down to that 2024-10-23 10:25:17 but it does not happen with v3.20, where it works, so it must be something with the tools 2024-10-23 10:25:20 still sounds very small for a modern kernel though :P 2024-10-23 10:25:37 but yeah you can disregard gnu-efi these days 2024-10-23 10:25:48 the only thing that meaningfully uses it is fwupd efi capsule 2024-10-23 10:26:06 (ideally nothing should use it) 2024-10-23 10:26:18 too bad my aarch64 does not boot so i cannot test build it 2024-10-23 10:26:27 systemd moved on with their efi stubs a few releases ago fortunately 2024-10-23 10:27:11 ncopa: bb was updated 2 days ago 2024-10-23 10:27:17 ok 2024-10-23 10:27:21 scary 2024-10-23 10:27:31 maybe you are copying a wrong file on aarch64 2024-10-23 10:27:43 there is a whole bunch of them 2024-10-23 10:28:05 the one that makes sense for aarch64 is the raw vmlinux 2024-10-23 10:28:08 but why would that suddenly change, out of the blue 2024-10-23 10:28:12 wait, no 2024-10-23 10:28:16 it's boot/Image for aarch64 2024-10-23 10:28:38 sounds like some tool changed. maybe its busybox 2024-10-23 10:28:44 busybox sounds likely too 2024-10-23 10:29:04 can i see the template you use 2024-10-23 10:29:17 i dunno what it's called 2024-10-23 10:29:38 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/linux-lts/APKBUILD 2024-10-23 10:31:24 ok so you use zinstall which uses https://github.com/torvalds/linux/blob/c2ee9f594da826bea183ed14f2cc029c719bf4da/arch/arm64/Makefile#L191 2024-10-23 10:31:28 so it's the right image 2024-10-23 10:31:46 because CONFIG_COMPRESSED_INSTALL is not set in the dotconfig 2024-10-23 10:32:33 I'm building linux-lts in my aarch64 container 2024-10-23 10:36:31 check vmlinux size and then the arch/arm64/boot/Image 2024-10-23 10:36:57 if vmlinux is okay and Image is not, it's not busybox, because Image is created with objcopy 2024-10-23 10:37:04 could be binutils 2024-10-23 10:37:11 if you updated that 2024-10-23 10:49:01 binutils update is older 2024-10-23 10:49:14 would noticed with 6.6.57 2024-10-23 10:49:45 https://tpaste.us/nNM6 2024-10-23 10:50:21 that looks fine? 2024-10-23 10:50:31 (this is unstripped size i assume) 2024-10-23 10:50:33 that is lts? 2024-10-23 10:50:37 virt 2024-10-23 10:50:41 hum 2024-10-23 10:51:01 try running the steps after that (the installation, and then the strip) 2024-10-23 10:51:01 the build logs with the defect build: https://build.alpinelinux.org/buildlogs/build-edge-aarch64/main/linux-lts/linux-lts-6.6.58-r0.log 2024-10-23 10:51:10 also loongarch64 is affected by this 2024-10-23 10:51:31 running rootpkg now 2024-10-23 10:51:46 could it be fakeroot? 2024-10-23 10:52:04 can fakeroot affect filesizes? 2024-10-23 10:52:20 i dont know 2024-10-23 10:53:18 im buildin in a lxc container as well now 2024-10-23 10:54:26 fakeroot should not affect anything 2024-10-23 10:54:39 (besides making everything slower) 2024-10-23 10:58:07 after rootpkg: -rwxr-xr-x 1 build build 60.5K Oct 22 18:59 boot/vmlinuz-virt 2024-10-23 10:58:39 uhu 2024-10-23 10:59:16 I have to go now 2024-10-23 10:59:51 mee too 2024-10-23 10:59:53 thanks! 2024-10-23 12:21:01 we found it 2024-10-23 12:21:07 it is busybox hexdump that is broken 2024-10-23 12:21:26 and it makes the kernel image end up as 0 here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/libstub/Makefile.zboot?h=v6.12-rc4#n9 2024-10-23 12:39:51 ok, i need to go, and will be away til Monday 2024-10-23 13:37:11 I was able to git bisect the problem to https://git.busybox.net/busybox/commit/libbb/dump.c?h=1_37_stable&id=e2287f99fe6f21fd6435ad04340170ad4ba5f6b3 2024-10-23 13:37:34 unfortunately I really need to go now 2024-10-23 13:37:56 I have sent a testcase to busybox mailing list 2024-10-23 13:40:51 would be great if anybody has time to help follow it up, as currently machines gets unbootable. And I really need to go 2024-10-23 13:41:49 https://lists.busybox.net/pipermail/busybox/2024-October/090983.html 2024-10-23 16:36:55 Hi! I'm having troubles pulling the container image registry.alpinelinux.org/alpine/docker-abuild:edge, it fails with this error: 2024-10-23 16:36:55 Error: copying system image from manifest list: determining manifest MIME type for docker://registry.alpinelinux.org/alpine/docker-abuild:edge: reading manifest sha256:7d5846a39aa7256b14df2534745da83796783936a31db5064441a9ed6ac90a0f in registry.alpinelinux.org/alpine/docker-abuild: manifest unknown 2024-10-23 17:40:09 ncopa: I found that reverting this one line in the patch you blamed fixes the test you made: https://bpa.st/A7S64 2024-10-23 17:40:36 but I cannot for the life of me figure out how to reply to your mailing list thread when there's no header info or mbox thing on the list webpage 2024-10-23 17:41:29 (I hit this bug yesterday when building a pmOS kernel and spent many hours trying to figure out what I broke, didn't think it might be busybox šŸ˜…) 2024-10-23 17:46:08 craftyguy: the "mailto:" link at the top has a "In-Reply-To" 2024-10-23 17:49:33 ahhh nice, never knew that. thanks :) 2024-10-23 18:39:43 I don't really understand waht that byte_count_str thing is doing, and why removing the 1 added byte fixes the test. but hopefully it's more of a clue to the bb gods about what went wrong 2024-10-23 18:40:17 z3ntu: let me check 2024-10-23 19:23:18 trying to rerun the pipelines, but need to fix something because docker does not support loongarch yet 2024-10-23 19:24:28 ikke: thanks! 2024-10-23 19:34:06 z3ntu: let's hope this pipelines succeeds: https://gitlab.alpinelinux.org/alpine/docker-abuild/-/pipelines/267826 2024-10-23 19:36:13 edge finished, can you try? 2024-10-23 19:36:41 craftyguy: nice! seems like the od tests pass as well 2024-10-23 19:46:56 ikke: yep, works! `Trying to pull registry.alpinelinux.org/alpine/docker-abuild:edge...` 2024-10-23 19:47:01 dabuild works again :) 2024-10-23 19:47:01 cool thanks 2024-10-23 22:03:17 ncopa: yeah. I just have no clue what that extra byte that was added does, and if reverting just that one thing has other implications elsewhere :/ 2024-10-24 08:31:42 Hello 2024-10-24 08:32:28 The history button on GitLab sometimes works and sometimes doesn't. Is this the case for everyone? 2024-10-24 08:42:50 txtsd: its a feature ;-) 2024-10-24 08:42:59 lol 2024-10-24 08:43:04 Is it not taxing on the server? 2024-10-24 08:43:17 i think the underlying tech is timing out 2024-10-24 08:43:30 It's just `git log ${dir}`, yea? 2024-10-24 08:43:38 aports history is huge 2024-10-24 10:25:58 use git.alpinelinux.org, gitlab sometimes got 500 error 2024-10-24 13:12:49 will busybox chown support user.group syntax again, should aports affected wait for a fix? 2024-10-24 13:39:04 mio: Unless it's reported somewhere, I don't think anything will change 2024-10-24 13:39:34 mio: it does not seem to be in POSIX 2024-10-24 13:39:38 (https://www.man7.org/linux/man-pages/man1/chown.1p.html) 2024-10-24 13:42:49 ikke: okay, thanks. did confirm this was previously supported in an older version, just wondered if it will return 2024-10-24 13:48:47 found the changelog. in case anyone else had the same question, the syntax has been deprecated upstream and support removed 2024-10-24 13:48:57 "chown: stop accepting deprecated USER.GROUP syntax, only : separator is allowed" 2024-10-24 13:49:10 so it won't come back and any aports using it need to be fixed 2024-10-24 13:49:29 yes 2024-10-24 13:54:34 Seems like only ejabberd uses it 2024-10-24 13:55:25 community/bugsquish, community/madbomber 2024-10-24 13:55:53 ejabberd noted, thanks for that one 2024-10-24 13:56:15 any idea why index for x86_64 is not updating since 2024-10-08 19:56:42 ref https://pkgs.alpinelinux.org/packages?name=php84&branch=edge 2024-10-24 13:57:09 andypost[m]: https://pkgs.alpinelinux.org/packages shows the last update is 2024-10-24 09:00:50 2024-10-24 13:57:33 mio: I suppose the others use it in the Makefile ? 2024-10-24 13:58:17 ikke: maybe it's php84 which is only ignored? 2024-10-24 13:58:34 andypost[m]: There have been reported more issues with updating certain packages, but I have not had the time to dive into it 2024-10-24 13:59:35 ikke: yes 2024-10-24 14:01:09 ikke: good news that all mirrors reports updated version, except pkgs.a.o 2024-10-24 14:01:32 yeah, it's just the apk browser that's affected 2024-10-24 15:49:51 qaqland: Thanks. I just cloned locally to browse instead :) 2024-10-24 16:01:47 Peeps, what's the significance of the .rootbld-repositories, and how come my system cannot suddenly find it? 2024-10-24 16:44:21 fancsali[m]: abuild rootbld need it. maybe you run abuild rootbld outside ~/aports 2024-10-24 17:07:13 could the folks maintaining mdev-conf take a look at this? https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/14 2024-10-24 17:42:22 https://tpaste.us/ZKgz ehhhh, what? 2024-10-24 17:44:32 got a hanging parenthesis somewhere in an apkbuild? 2024-10-24 17:48:03 but it shouldn't choose the same APKBUILD first multiple times, shouldn't it, especially since i have still quite a few left to build 2024-10-24 17:49:59 ya I have no clue what you're trying to do, there wasn't really much info in the output you posted ;) 2024-10-24 17:50:39 but when I've seen abuild complain about stuff like that (I assume it's from abuild?), it's from some hanging parenthesis, or quotation mark, or something in an APKBUILD 2024-10-24 17:51:39 well, i am building my package repo for sh3, updated git, pulled my changes from the repo and then i wanted to run buildrepo again, with the following result 2024-10-24 17:52:11 weirdly it does it with "-n -k" too 2024-10-24 17:53:55 i'll figure it out at some point :] 2024-10-24 18:06:58 forgot an "esac" 2024-10-24 18:18:09 i guess buildrepo parses all apkbuilds at the start, so that it knows how much it has too build 2024-10-24 18:44:14 Good day all. I am having some problems coming up with a version spec for the APK build I'm making. 2024-10-24 18:45:32 https://wiki.alpinelinux.org/wiki/Package_policies mentions semantic versioning, and links to a spec, but it seems not to totally follow it. Specifically, semver supports "+" but apk seems not to like that. 2024-10-24 18:46:33 I have a component that is being used elsewhere, and they version it with a date/time stamp as their build number. I'm unable to find a pattern that will let me incorporate that into the version pkgver for apk 2024-10-24 18:47:58 How does the version look like? 2024-10-24 18:56:08 cross_: thanks for pointing this out ^^ the wiki is wrong here, the version format supported by apk-tools doesn't quite cover all of SemVer 2024-10-24 18:56:44 https://gitlab.alpinelinux.org/alpine/go/-/blob/master/version/doc.go 2024-10-24 18:58:03 Okay thanks. That will make it easier. 2024-10-24 18:58:44 Do you have any suggestions of how to replicate something like software-2.0-20241022.1613.wr_lts22.aarch64.rpm ? 2024-10-24 18:59:35 I mean, all components of that are not required I suspect, but. In this case the DATE.TIME is what we're using for build number elsewhere, including rpms. Then envinroment arc etc. 2024-10-24 19:00:19 Is there a way to code those other parameters into the name without them being in version? Or, is that not done because it's supposed to be covered by the package management system filing them away correctly? 2024-10-24 19:00:41 in case of dates in versions, we're usually doing it with Git archives, and that's then `X.Y.Z_gitYYYYMMDD` 2024-10-24 19:02:02 afaict you can use any of the suffixes like this (e.g. `_pre`, `_rc`, `_git`, `_p`, full list in apk-tools:src/version.c) 2024-10-24 19:02:30 Yeah, I was going to ask about that. I saw the `"_git" digits` spec. That was confusing to me since normally git uses checkins in hex. :-) 2024-10-24 19:03:09 The version spec is made so that versions can be reliably be compared 2024-10-24 19:03:18 I can use _gitDATE. It's not quite the same, but it's effectively the same. 2024-10-24 19:03:32 only significant difference is that they're sorted into two categories, pre-suffixes and post-suffixes; the "pre" ones count as "before" the proper version when comparing, the "post" ones are "after" 2024-10-24 19:04:17 so e.g. 2.0_gitYYYYMMDD would be an upgrade from 2.0, but 2.0_pre* wouldn't 2024-10-24 19:06:45 ptrc: Got it. In my case, it's a build identifier, so all will have it. So works fine. 2024-10-24 19:08:06 Hate to bring this up a year late, to the discussion. When the Hashicorp license lead to the removal of their products from Alpine, was there discussion of creating a non-free/proprietary repository for distributing packages that could be distributed but don't fit the normal Alpine licensing policies? 2024-10-24 19:08:40 We used to have a non-free repo, but it was mostly a wasteland 2024-10-24 19:08:42 it's relatively easy to create/operate your own local repo that packages whatever you want 2024-10-24 19:09:33 tbh it would be interesting to see something like AUR but for Alpine, with helpers for building stuff and possibly namespaced package names 2024-10-24 19:09:49 but that also sounds like a lot of effort, would need moderation and infra 2024-10-24 19:10:02 I think there's more trust from a top-level `non-free` repository than an AUR style repo. 2024-10-24 19:11:13 note that we do have opentofu in the repositories 2024-10-24 19:11:21 @craftyguy building lots of containers for cloud ops work there's a need to use the latest versions of lots of apps, and the Hashicorp products are in that set. Having it from Alpine as a trusted "vendor" has value. 2024-10-24 19:11:47 @ikke I need packer which doesn't have an open fork yet 2024-10-24 19:11:53 right 2024-10-24 19:13:01 the issue would be also relying on users to report breakages in the non-free stuff, as i don't think it would have a proper CI integration 2024-10-24 19:13:11 or if it did, it would have to exclude artifacts 2024-10-24 19:14:14 The only thing we would provide is an APKBUILD 2024-10-24 19:14:21 Not sure how that matters in terms of trust 2024-10-24 19:14:42 I'm not sure offerring any breakage support/remediation should need to be extended. Most of these packages are golang apps that having reasonable build robustness and folks using cloud stuff are likely always using the latest package versions. 2024-10-24 19:15:52 @ikke, hosting a repository like alpine/edge/non-free couldn't be added? 2024-10-24 19:16:15 who is going to maintain it? 2024-10-24 19:16:28 rcpage: we can't distribute non-free stuff without having a proper lawyer going over each package's license and making sure it's fine in our case 2024-10-24 19:16:37 @craftyguy the same folks that maintained it in community before it went non-free? 2024-10-24 19:17:14 maybe, but you'd have to ask them. also the legal aspect ^^ 2024-10-24 19:17:28 @ptrc there may be a class of licenses like BSL where it's permissive without involving a lawyer. 2024-10-24 19:18:20 rcpage: that's the problem, the packages weren't maintained 2024-10-24 19:19:01 @craftyguy if someone is volunteering to maintain a package, the licensing likely won't impact their desire to continuing maintaining it unless there's legal reasons they're not permitted. So if a class of licesnes such as BSL were identified as redistributable they could go in a non-free repo and end-users could be aware of their concerns while retaining access to the binaries 2024-10-24 19:19:03 from an Alpine build system 2024-10-24 19:19:12 note that we did not provide any packages for non-free 2024-10-24 19:19:51 Really? Because I see Mike Crute in the discussion of vault, suggesting he was actively maintaining it - https://gitlab.alpinelinux.org/alpine/aports/-/issues/15193 2024-10-24 19:20:09 That's when the packages were still in community 2024-10-24 19:20:16 and before the license changed 2024-10-24 19:20:54 @ikke and if there was an Alpine accepted repository for the code post-license change, they may have (and might again) consider to maintain the software 2024-10-24 19:21:33 If there's no repository for their contributions to go, it's natural for their maintenance to stop. Hence my asking if it was discussed creating a non-free/proprietary repository for these types of packages. 2024-10-24 19:24:41 rcpage: I'm in the same boat as you, I need the Hashicorp stuff as well. I have all of the APKBUILDs here, https://krei.lambdacreate.com/t-a-p/tports/src/branch/trunk/non-free, that's including packer. 2024-10-24 19:25:04 It's not as good as an official repo, but you can git clone and abuild -r them locally. 2024-10-24 19:25:21 https://tenejo.lambdacreate.com/edge/non-free/x86_64 2024-10-24 19:26:06 These aren't completely up to date (life has been busy) but I have prebuilt apks here as well if it helps. 2024-10-24 19:40:50 @durrendal I greatly appreciate the reference, but when I build things I try to avoid "AUR" / 3rd-party packaging/artifacts and use "distro trust" as my source of truth. 2024-10-24 19:41:49 Agreed entirely, which is why I setup my own repo when they were removed. 2024-10-24 19:42:24 I usually fall-back to github/vendor release packaging if the distro doesn't include the package. 2024-10-24 19:42:58 For what it is worth. The APKBUILDs are copied from aports. The only changes are the license, version, and maintainer info. But you can fetch these from aports' git history if that's preferable, your security posture is a valid concern. 2024-10-24 19:43:18 durrendal: what he wants is _us_ to provide the packages 2024-10-24 19:43:22 @ikke who/how are the ideas of adding a limited license non-free repo to alpine discussed/implemented? 2024-10-24 19:43:59 @ikke correct, Alpine to provide the build manifests and artifacts, community to provide the maintenance 2024-10-24 19:44:31 ikke: oh I know, me too, but I get why we won't. I just figured I'd at least provide what I have if it was helpful. 2024-10-24 19:44:33 To be fair, I'm asking if it was considered, and if not, how might such a proposal go forth for ratification. 2024-10-24 19:44:44 https://gitlab.alpinelinux.org/alpine/tsc/-/issues 2024-10-24 19:45:02 https://gitlab.alpinelinux.org/alpine/tsc/-/blob/master/workflow.md 2024-10-24 19:46:44 @ikke I appreciate your entertaining my questions and providing answers to all my questions! 2024-10-24 20:08:41 I'd just be happy if when there is a free alternative in place it didn't use the same name as the non-free stuff. 2024-10-24 20:09:17 It is great when you have like FindSomething.cmake stuff that finds the same library, and headers and links to some hostile libre stuff with the same name but not the exact same features/abi 2024-10-25 01:15:32 hi 2024-10-25 01:27:52 How do I build with PostgreSQL dependencies? - I've tried adding musl-dev libpq-dev postgresql16-dev. My error is /usr/lib/gcc/aarch64-alpine-linux-musl/13.2.1/../../../../aarch64-alpine-linux-musl/bin/ld: fe-secure-common.c:(.text+0x320): undefined reference to `pg_strerror_r' 2024-10-25 01:28:33 Here's my codebaseā€”see Dockerfile or GitHub Action for alpine usageā€”https://github.com/SamuelMarks/serve-actix-diesel-auth-scaffold 2024-10-25 12:41:41 https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/porla/porla-0.40.0-r0.log why I dont see this pkg on pkgs.a.o 2024-10-25 14:13:14 me neither, but I can find it on mirrors 2024-10-25 14:51:02 wth, twice now has newsboat crashed for me 2024-10-25 14:59:53 !74120 2024-10-25 15:24:46 are there any good examples of how to do architecture dependent dependencies and subpackages? (sh3 doesn't have rust and llvm, so i just ripped out a bunch of parts from the postgres apkbuilds, but that is hacky and not upstream-able) 2024-10-25 15:28:07 Mostly case $CARCH in foo) var="$var ..";; esac 2024-10-25 15:29:19 ok, so much the same as smaller architecture dependent changes 2024-10-25 21:16:25 socksinspace: keep in mind that architectures *must* support rust in order to be release-qualified as an effect of tsc#21 2024-10-25 21:23:03 Ariadne: i do not expect the alpine-linux project to build binaries for sh3 :) 2024-10-25 21:23:40 well, the changes to the APKBUILDs may not be accepted in that case :p 2024-10-25 21:24:15 i still hope to make them in such a quality that they theoretically could be 2024-10-25 21:25:07 also, gccrs will probably materialize in the next few years :P 2024-10-25 21:25:46 so rust support is not entirely impossible in the future 2024-10-25 21:27:03 [@_oftc_Ariadne:matrix.org](https://matrix.to/#/@_oftc_Ariadne:matrix.org): wern't you interested at one point in some kind of Alpine ports project? 2024-10-25 21:27:29 i could see sh3 and also archs like mips there 2024-10-25 21:27:32 fossdd[m]: yes, though there is a lot to think through about that 2024-10-25 21:27:41 yeah true 2024-10-25 21:27:48 (i do intend to revive the mips port at some point, but probably not as a release architecture) 2024-10-25 21:28:04 although tbh i think mips is obsolete by loongarch 2024-10-25 21:28:14 and to a lesser extent riscv 2024-10-25 21:28:37 yeah i also heard from some pmOS people that theyre interested in mips (esp for routers and such) 2024-10-25 21:28:53 and i'm also interested :) 2024-10-25 21:29:51 hmm, i think i have a mips based router too 2024-10-25 21:30:22 Ariadne: what hw would you build it on? 2024-10-25 21:30:31 or just emulated? 2024-10-25 21:30:59 that's the path i have taken for building 2024-10-25 21:40:29 some of the late octeon hardware probably has decent compiling abilities? 2024-10-25 22:32:46 I would also be interested in a MIPS release. If you're looking for people to help with such a thing 2024-10-25 22:43:24 ahhh you don't mask emails on the mailing list https://lists.alpinelinux.org/~alpine/devel/%3CCAMfPbcb4h2t5FbUfyARLw9Ybd7UeA%3DRm04F%2Bo8a6u03rObtX6w%40mail.gmail.com%3E 2024-10-25 22:44:55 hi 2024-10-25 22:45:18 Repeating my quesiton on the mailing-list - ahhh you don't mask emails on the mailing list https://lists.alpinelinux.org/~alpine/devel/%3CCAMfPbcb4h2t5FbUfyARLw9Ybd7UeA%3DRm04F%2Bo8a6u03rObtX6w%40mail.gmail.com%3E 2024-10-25 22:57:51 ikke: probably ubiquiti edgerouter infinity like last time. but not hosted in a coworking space for startups and rather in my house 2024-10-25 23:15:55 guys... i think there's something wrong with the dl-cdn? i hope i'm wrong 2024-10-25 23:16:06 https://dl-cdn.alpinelinux.org/alpine/edge/main/x86_64/ 2024-10-25 23:16:11 is this supposed to be empty? 2024-10-25 23:16:15 known issue, being restored 2024-10-25 23:16:26 oh good thing 2024-10-25 23:16:37 what happened though? 2024-10-25 23:32:12 rdbo: https://fosstodon.org/@alpinelinux/113370036561484573 2024-10-25 23:41:20 damn, strange thing 2024-10-25 23:41:26 thx for the info! 2024-10-26 10:34:07 do we collect the common set of architecture independent options we enable in linux-lts somewhere? 2024-10-27 02:10:12 "out of date" emails have the wrong command. They have "abump aport-version" instead of the actual aport and version. 2024-10-27 02:10:37 The email indicates that I should report inaccuracies to alpine-infra@alpinelinux.org, but that address bounced; it's only for subscribers. 2024-10-27 07:22:35 WhyNotHugo: https://gitlab.alpinelinux.org/alpine/infra/apkbrowser/-/issues 2024-10-27 09:20:59 WhyNotHugo: you need to replace it with the actual aport and new version 2024-10-27 09:21:17 as it now possible showa multiple aports 2024-10-27 09:21:22 instead of sending multiple emails 2024-10-27 15:19:05 andypost[m]: i think the strerror_r patch is wrong 2024-10-27 15:19:26 because the PG_STRERROR_R_BUFLEN define was coming from internal postgres headers, and same with the other function 2024-10-27 15:20:46 ptrc: totally agree, so I just replaced with 256 instead of hacking internal headers 2024-10-27 15:21:09 yeah, but it should not call the libc strerror_r function 2024-10-27 15:21:26 they were using the internal headers for some reason 2024-10-27 15:22:19 as I get because of different implementations 2024-10-27 15:22:30 mhm 2024-10-27 19:49:58 completion sub-packages for elvish, nushell and powershell? 2024-10-27 19:53:22 do any of our packages provide those yet? 2024-10-27 19:53:25 or have an option to do so 2024-10-27 19:57:05 I think some rust aports could 2024-10-27 19:59:58 I'm failing forward with packaging minijinja-cli and, built with --all-features, --generate-completions says possible values: bash, elvish, fig, fish, nushell, powershell, zsh 2024-10-28 03:14:42 Repeating my quesiton on the mailing-list - ahhh you don't mask emails on the mailing list https://lists.alpinelinux.org/~alpine/devel/%3CCAMfPbcb4h2t5FbUfyARLw9Ybd7UeA%3DRm04F%2Bo8a6u03rObtX6w%40mail.gmail.com%3E 2024-10-28 10:55:45 fossdd[m]: re: !74207 2024-10-28 10:56:18 fossdd[m]: for me it is easier and better to answer on irc than gitlab 2024-10-28 10:56:57 yeah np 2024-10-28 10:57:14 maintaining it is not 'big work' but requires nearly every week to do something 2024-10-28 10:58:42 hmm yeah 2024-10-28 10:58:47 but i think then its doable 2024-10-28 10:59:05 also will be very good and useful if you have all five arches installed, be it real hardware, lxc, qemu or even chroot with qemu user to test from time to time and when is needed 2024-10-28 10:59:54 also will be very good if you have push rights to aports 2024-10-28 11:00:49 you should check for new releases nearly every day and probably few times in day 2024-10-28 11:01:29 my personal 'advise' is "be conservative" what you enable or add 2024-10-28 11:05:37 yeah ive got VMs of some archs (that reminds me i should prolly look into a loongarch vm :) 2024-10-28 11:06:10 and im subscripted to kernel announcements, so hopefully i wouldnt miss them 2024-10-28 11:06:31 maybe it makes sense to make a somewhat automated tooling for updating configs and testing kernels 2024-10-28 11:06:58 maybe. though I don't like 'automation' too much 2024-10-28 11:08:22 for every upgrade I do it manually on all arches, usually not much work but sometimes you/I have to make human decisions 2024-10-28 11:08:58 and never know in advance when this will be needed 2024-10-28 11:09:04 yeah true 2024-10-28 11:09:48 I would call this task more 'responsible' than hard 2024-10-28 11:11:47 these are my personal views but everyone will have theirs, ofc 2024-10-28 11:16:17 btw, I will try to merge linux-starfive to linux-edge locally. If I succeed I will inform you or if someone else take linux-edge 2024-10-28 11:18:43 yeah sounds good šŸ‘ 2024-10-28 11:22:45 PureTryOut: gnome-shell still depends on networkmanager-common, that you removed 2024-10-28 11:24:52 btw, if anyone are ready to take maintainership of rust-bindgen and bcachefs-tools please do and thanks 2024-10-28 11:25:25 we've been talking about doing it as team/rust 2024-10-28 11:25:39 nice 2024-10-28 11:25:48 and thanks 2024-10-28 12:14:25 omni: ah thanks for the ping, fixed! 2024-10-28 12:43:39 i'd like to crosscompile aports packages on a foreign distro using `abuild rootbld` . apk chokes on missing db , can i get any guidance? alpine wiki is short of non-native compilation using abuild 2024-10-28 12:44:00 if you can run apk, you can do `apk add --initdb` 2024-10-28 12:44:24 but it should work in rootbld by default.. 2024-10-28 13:03:35 https://git.alpinelinux.org/abuild/tree/abuild.in#n2502 assumes a native apk install 2024-10-28 13:04:01 i switch die -> warning for now 2024-10-28 13:37:36 Could anybody have a look at !73893 and !73891 ? 2024-10-28 13:37:59 Seem to have blessing from maintainers/devs 2024-10-28 13:41:06 Merged both, thanks! 2024-10-28 15:08:43 With regards to the recent change to the # Maintainer comment, should I update all of my packages to comply with this new pattern? Is it acceptable to leave the comment and just add the variable? Asking because I currently use them Maintainer and Contributor comments to automate maintenance of my packages and what to know what to cut over to. 2024-10-28 15:12:19 durrendal: for now, it's okay to leave it as is 2024-10-28 15:12:45 Roger that, thanks for clarifying Ikke 2024-10-28 15:12:48 durrendal: the warning has been reverted (but not published yet) 2024-10-28 15:13:01 I've started adding the maintainer variable below the # Maintainer: comment 2024-10-28 15:14:20 I don't mind adding it to the APKBUILDs if I can still also have the comment in the APK, especially if it'll reduce load cutting over things later 2024-10-28 15:15:03 I've removed the old comment and added the variable to a bunch of my stuff already, I'd recommend anyone to do the same if they're touching a package anyway 2024-10-28 15:15:38 durrendal: you can update your script to also check the variable right? 2024-10-28 15:16:08 as a reviewer, I prefer if the order is maintainer, pkgname, pkgver, pgkrel, pkgdesc, since a diff will usually just show a couple of lines above and below the change, it makes it easy to see who is the maintainer and what the aport is about, when bumping pkgver and/or pkgrel, without having to expand the diff 2024-10-28 15:17:30 Yeah I add maintainer as the first line in the APKBUILD. Basically same position as before with the comment, just now a variable 2024-10-28 15:18:04 imo it would be nice if we had some linting to (softly) enforce a consistent order of standard variables 2024-10-28 15:18:11 and above and below that, order doesn't matter as much (to me) 2024-10-28 15:18:27 sure, it makes it easier too 2024-10-28 15:18:48 I try to have them as they are in most aports, look at others if unsure 2024-10-28 15:21:35 but comments at the top, if not too many lines, including a # Maintainer: one, could be ok also in the future? 2024-10-28 15:21:48 just that we, at one point, stop relying on them 2024-10-28 15:22:29 that the linter won't complain about a # Maintainer: comment, but suggest/complain about a maintainer variable being missing 2024-10-28 15:22:47 PureTryOut: certainly, and that's the plan anyways, I just wanted to know if that needed to be a now thing, or if I could wait until I had time to work on it. 2024-10-28 15:23:17 yeah you have some time still 2024-10-28 15:24:01 :) good, that means I can focus more on adding all of the ruby gems I need first. I'll start adding maintainer= though 2024-10-28 15:25:04 just do it as you go, then 2024-10-28 15:30:30 agreed, once I'm done with all of these gems I'll circle back to updating anything that lags behind there 2024-10-28 15:32:00 thanks for the clarification everyone 2024-10-28 15:36:23 omni: aside from organizing the apkbuild specifically, is there anything else that can be done to make it easier for you to review MRs? 2024-10-28 16:24:28 Anyone wants to proof-read this? https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/89 2024-10-28 16:24:29 following COMMITSTYLE.md and CODINGSTYLE.md, when in doubt look at git history too see what looks to be common, and links to release notes/changelog or similar in the MR description, so that the the one looking at it doesn't need to find that themselves 2024-10-28 16:39:24 ikke: added comments 2024-10-28 16:39:45 omni: saw it, thanks 2024-10-28 16:49:50 ouch, 41ab5aa740c8c827e490093874fbb65915b967e5 didn't work well when upgrading the package 2024-10-28 16:50:56 ERROR: compiler-rt-19.1.1-r1: failed to rename usr/lib/llvm19/lib/clang/19/lib/.apk.edab94cc5007502928fa108fed1ee0011fab 2024-10-28 16:50:59 a3ae3ef41894 to usr/lib/llvm19/lib/clang/19/lib/linux. 2024-10-28 16:55:04 hmm... 2024-10-28 17:05:08 `apk fix` fixes it, but how does one handle that? I forget 2024-10-28 17:06:12 it's a directory that is supposed to be replaced with a symlink in the -r0 -> -r1 upgrade 2024-10-28 17:22:31 Thanks all for your reviews, really appreciated 2024-10-28 17:25:50 thanks for writing a post mortem, it was an interesting read 2024-10-28 17:43:09 ikke: probably unrelated, but when I abuild a package with the wrong toolchain, with a triplet like x86_64-linux-musl instead of x86_64-alpine-linux-musl, it ends up with an empty $arch (and the .apk is shoved in the 'unknown' category instead of x86_64). Your article reminded me of that. 2024-10-28 18:20:15 skarnet: what a coincidence. This does happen on a higher level though, before any package is considered 2024-10-28 18:20:22 We suspect some hardware issue 2024-10-28 19:48:49 unrelated: !74290 whenever someone has the time 2024-10-28 19:53:17 Waiting for pipelines to finish 2024-10-28 19:53:40 ptrc: hey, why not keep forgejo package as LTS? 2024-10-28 19:53:56 https://wwwtest.alpinelinux.org/posts/2024-10-28-postmortem-edge-mirror.html 2024-10-28 19:55:02 ikke: good job! I think we can merge it to prod 2024-10-28 19:55:26 will do 2024-10-28 19:55:34 thank you for taking care of it! 2024-10-28 19:55:42 yeah didnt find any typos thanks! 2024-10-28 19:55:43 the whole incident 2024-10-28 19:56:57 https://www.alpinelinux.org/posts/2024-10-28-postmortem-edge-mirror.html 2024-10-28 19:57:36 ncopa: It was a team effort, without you finding those irc logs we would probably still be wondering what happened 2024-10-28 20:05:25 pj: my personal idea was that the recent releases are easy to backport are supported by upstream for 3 months. 2024-10-28 20:06:37 major releases? 2024-10-28 20:06:58 yeah the patches itself 2024-10-28 20:07:48 so alpine isn't doing "security fixes only" anymore? 2024-10-28 20:08:59 what do you mean? 2024-10-28 20:09:22 the security fixes from forgejo 9.0.1 were almost identical to the 7.0.x LTS ones 2024-10-28 20:09:58 But you still run a 2 major releases higher than what is LTS 2024-10-28 20:10:55 I find it weird that for a service that people would value stability, it's chosen to be bumped to whatever is bleeding edge 2024-10-28 20:12:26 History has shown for me that the stable released are pretty reliable. And they're pushing many bug fixes for stable releases. Critical bug fixes can still also be patched. 2024-10-28 20:13:22 I'm aware but forgejo has specifically an LTS version which support time covers Alpine's release cycle 2024-10-28 20:13:36 Some people value stability, some people need bleeding edge. We have both nodejs as nodejs-current 2024-10-28 20:13:40 but instead it's chosen to ride on less than (it's <4 for stable releases) 2024-10-28 20:14:27 ikke: to me the package doesn't strike as so necessary to have -lts variant 2024-10-28 20:14:41 but if it's something that maintainer is willing to do I'm fine 2024-10-28 20:35:54 its just a matter of who patches forgejo, either forgejo's releng team, or we downstream (i'd volunteer for that). 2024-10-28 20:36:07 either way it would be supported in Alpine for 6 months 2024-10-28 21:14:52 ncopa: linux-lts update to 6..6.58 broke netfilter tables 2024-10-28 21:15:30 https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=306ed1728e84 this one would fix it, right? 2024-10-28 21:15:35 yes 2024-10-28 21:16:28 just noticed because updated about an hour ago and rebooted 2024-10-28 21:17:16 imo it could be patched in aports 2024-10-28 21:18:32 Im fine with whatever way :> 2024-10-28 21:27:20 ah it will probably be in the next LTS, so i guess we can just wait: https://lore.kernel.org/stable/20241028062310.178366177@linuxfoundation.org/ 2024-10-28 21:34:56 pj: we're following forgejo "stable", i think that's fine 2024-10-28 21:35:21 as in, the upstream itself designates the branch as stable 2024-10-28 21:35:52 if it was named something like "edge" or "latest" then lts would probably be a better option 2024-10-28 23:56:45 jtest 2024-10-29 00:10:38 Hello. You know how the *BSD systems have a base system? I'd like alpine to have that too. It doesn't need to be as serious as those, but at least having a set of packages that allow one to start working offline (a compiler, window manager, documentation) and not depend on a working Internet connection would be awesome. I know of 2024-10-29 00:10:40 https://wiki.alpinelinux.org/wiki/How_to_make_a_custom_ISO_image. This is not it. 2024-10-29 00:12:44 we don't really make desktop ISOs or anything like that 2024-10-29 00:13:31 there's just 100 options and you can't avoid bikeshedding with this kind of stuff 2024-10-29 00:13:59 you add a compiler to a desktop image, and then someone complains that their 600MB GNOME install also contains 50MB of clang libraries and "it's bloat" 2024-10-29 00:14:40 oh no please not gnome 2024-10-29 00:15:02 case in point 2024-10-29 00:15:05 yeah that's also exactly what i'm talking about 2024-10-29 00:16:02 as i said, a (small) window manager would suffice. all the BSDs do it, and I can see alpine takes at least some inspiration from those. 2024-10-29 00:16:41 which one 2024-10-29 00:16:52 but i understand. you don't want to make desktop ISOs. 2024-10-29 00:17:25 wouldn't really say "don't want to" 2024-10-29 00:17:32 pretty sure there's a tracking issue open somewhere 2024-10-29 00:17:53 but currently we don't make them and there's no concrete plans to do so 2024-10-29 00:18:01 psykose: I'm mistaken actually. I don't think FreeBSD comes with a window manager (but it does have a base system, as all BSDs). That I know of OpenBSD comes with FVWM, cwm and another WM I can't remember right now. All in its base system. 2024-10-29 00:21:12 ptrc: oh okay. a base system wouldn't be a desktop ISO either. as FreeBSD's base system isn't so then came GhostBSD and made a desktop-focused system. 2024-10-29 00:27:21 That I know of, there is no "(complete) operating system" release of Alpine, only the installers, which makes us (the users) dependent on a working Internet connection and infrastructure to be working in order to set up ourselves our own full system, or at least what we need. 2024-10-29 00:29:48 the definition of ā€complete operating systemā€ is heavily subjective 2024-10-29 00:40:25 a desktop environment is separate from the operating system. 2024-10-29 00:41:24 lotheac: Yeah. Since Alpine uses busybox it already covers a lot of things. To be honest if it came with documentation and a c compiler it would be perfect for me. 2024-10-29 00:42:09 invoked: Indeed. 2024-10-29 00:44:03 aleksi_: you can use / install the extended image without internet though 2024-10-29 00:44:04 Here is an article that explains what a base system is: https://www.over-yonder.net/~fullermd/rants/bsd4linux/03 (note: I don't know who wrote it, just found that it explains what a base system is better than I could) 2024-10-29 00:46:41 ptrc: yeah, I prefer to use that image exactly for that reason, and of course, because my systems run on one of the two architecturessupported by extended. 2024-10-29 00:50:03 ā€base systemā€ as a term only makes sense in the presence of a non-base system, ie. ports. it does not mean anything by itself in contexts without that separation already 2024-10-29 00:50:09 imho 2024-10-29 00:52:56 i mean i guess in bsds it means ā€all the installed stuff we own and maintainā€, but that wouldnā€™t match alpine either if you stretched the definition: alpine relies on upstreams for many things, like busybox 2024-10-29 00:53:11 yes, you're right. 2024-10-29 00:53:31 every package is built from the aports tree 2024-10-29 00:54:35 linux is frankenstein compared to the bsds, but freebsd cosplays as linux a little bit. 2024-10-29 00:55:18 but look at slackware for example. it comes with all kinds of software that you can choose to install at installation time. 2024-10-29 01:06:45 any alpine people currently at open source summit japan? 2024-10-29 07:24:21 aleksi_: What is the expectation re: base system? The way FreeBSD implements it, it's cool if all your main tools are in base; otherwise, you have a lot of additional work to do to keep your ports/packages stable (since they're basically rolling). I think it's not the base/ports system you want, but just a simple way to mix *your* base system. 2024-10-29 09:42:37 I wonder if we should (can?) disable xml support in nginx for now. libxml2 appears to be an unreliable dependency breaking left and right on minor version bumps 2024-10-29 09:53:48 maybe open an issue or MR and ask maintainer (jirutka?) 2024-10-29 10:56:37 omni: I wonder if we can drop support for stubdomain 2024-10-29 10:56:40 in xen 2024-10-29 10:56:49 seems like suse dropped it: https://build.opensuse.org/projects/openSUSE:Factory/packages/xen/files/xen.spec?expand=1 2024-10-29 10:57:21 and what I heard from xen matrix channel is that the people who managed build xen 4.19 has dropped the mini-os stuff 2024-10-29 10:58:41 looks like we never supported it for aarch64/armv7 2024-10-29 11:33:15 ncopa: I need to look at it again, but I don't think that's where it's failing? 2024-10-29 11:34:07 I think it is failing on building their qemu-xen (that we package as xen-qemu) that is an old version of qemu not building with gcc14 on musl 2024-10-29 11:34:33 (if I have not mixed up things too much) 2024-10-29 11:35:31 I wouldn't mind dropping the stubdom stuff, if that is separate from qemu-xen/xen-qemu 2024-10-29 11:35:58 and also drop our xen-qemu subpackage, if we could move qemu to main 2024-10-29 11:37:37 I'll look at it again (stubdom/mini-os stuff) a bit later 2024-10-29 12:11:28 i have a fix for it i think 2024-10-29 12:11:45 i think it builds now, but without pvgrub 2024-10-29 12:11:52 not sure if we need pvgrub 2024-10-29 12:14:03 upstream xen devs have fixed pvgrub i think: https://old-list-archives.xen.org/archives/html/xen-devel/2024-10/msg01896.html 2024-10-29 12:48:33 i wonder if our gcc is broken wrt -fno-pie 2024-10-29 12:49:21 https://tpaste.us/qYKe 2024-10-29 12:49:33 I pass in -fno-pie, but it still fails 2024-10-29 12:53:33 ok, no I get lots of undefined refs 2024-10-29 12:53:40 ld: /home/ncopa/aports/main/xen/src/xen-4.19.0/extras/mini-os/xenbus.c:623:(.text+0x36): undefined reference to `malloc' 2024-10-29 12:53:53 omni: do we really need the stubdom and mini-os? 2024-10-29 12:54:09 it fails everywhere apparently 2024-10-29 13:41:23 when should I expect new kernel with the patched netfilter 2024-10-29 14:16:40 ncopa: idk, but if we drop them we should probably mention that in the 3.21 release notes 2024-10-29 14:18:22 < andyhhp> but I'm >< this close to just deleting stubdom/ from the tree. It's nothing but bitrot 2024-10-29 14:18:38 (#xen, 20240815) 2024-10-29 14:21:08 I'm not a fan of matrix (except the first, and only, movie) and they don't bridge with the irc-channels, but a couple of people still hang out in #xen@oftc and andyhop is very helpful 2024-10-29 14:23:22 I'm nuking stubdom 2024-10-29 14:24:38 we have somehting in xenstord.confd but i'll leave that as an excerise to the reader 2024-10-29 14:31:59 it's just about not building and packaging usr/lib/xen/boot/xenstore{,pvh}-stubdom.gz right? 2024-10-29 14:32:15 please let me review before you merge, though 2024-10-29 14:32:20 and I'll have to do that later 2024-10-29 14:37:15 im thinking, that if the CI passes I'll merge it sooner than later 2024-10-29 14:37:19 and you can test from edge 2024-10-29 14:37:45 and if we need it back, we add it back 2024-10-29 14:37:52 currently its blocking the 3.21 release 2024-10-29 15:28:04 I know, and I meant that I'll look at it before tomorrow 2024-10-29 15:39:50 ok, looked at it quickly now, it removes a bit more qemu-related things than I thought it would, not sure how much of that is related to dropping --enable-qemu-traditional or the upgrade itself 2024-10-29 15:40:49 i would think its due to qemu traditional 2024-10-29 15:43:21 ok, get it in and I'll try it later 2024-10-29 15:44:09 very nice to get rid of those stubdom related things, actually 2024-10-29 15:45:15 I've been thinking of how to use dependencies provided by us, instead, but never really about just dropping that 2024-10-29 15:46:50 I'll look into what can be done about xen-qemu later, because that is lagging behind upstream qemu 2024-10-29 17:08:56 sertonix[m]: once the x86_64 CI passes on that Nagios MR I'll take a look at the fix, at a glance I think it should work, but I'll let you know definitively 2024-10-29 19:20:06 ncopa: the http_dav_ext module requires libxml2 as well 2024-10-29 19:20:23 So I don't think we can disable it 2024-10-29 19:21:14 (regarding nginx) 2024-10-29 19:48:44 ikke: maybe just skip broken test ? 2024-10-29 19:48:58 i gave 3rd file opt to lbu diff , and got garbled text, maybe suppress it 2024-10-29 19:49:00 It's not a broken test 2024-10-29 19:49:43 Or rather, nit necessarily 2024-10-29 19:51:04 andypost[m]: it started failing after upgrading libxml2, the segfault happens in the actual nginx source code (not the tests). 2024-10-29 19:51:21 It either means the tests does something wrong, or nginx itself is brokenb 2024-10-29 19:59:26 andypost[m]: until we are certain it's the test that's at fault, we could just be hiding a real bug 2024-10-29 20:16:28 oh, its probably libxml2 that is doing nasty stuff 2024-10-29 20:16:59 ncopa: https://github.com/nginx/nginx/issues/251 2024-10-29 20:17:41 ikke: not clear how loongarch and armv7 passed 2024-10-29 20:19:16 could it be libxml2 that broke ABI? https://gitlab.gnome.org/GNOME/libxml2/-/issues/751 2024-10-29 20:19:51 9c68b359c3917339e9f11a50c682419401a9e631 2024-10-29 20:19:59 seems like I didnt bump pkgrel 2024-10-29 20:20:40 It seems that removing a free fixes it, so not sure if that's due to an ABI breakage 2024-10-29 20:20:47 - xmlFreeDoc(doc); 2024-10-29 20:21:02 But, what do I know :) 2024-10-29 20:21:12 (not sarcastic) 2024-10-29 20:21:37 memory corruption could lead to things go boom during free 2024-10-29 20:21:52 worth a try to rebuild, I suppose 2024-10-29 20:22:01 and ABI breakages (structs silently changing) could lead to memory corruption 2024-10-29 20:22:13 im trying to reproduce here 2024-10-29 20:23:00 but then again, it would only happen if libxml2 was built after something else 2024-10-29 20:23:12 libxml2 was built on the 15th 2024-10-29 20:24:31 my rebase was broken in 9c68b359c3917339e9f11a50c682419401a9e631 2024-10-29 20:24:33 bah 2024-10-29 20:24:38 it was already enabled 2024-10-29 20:24:51 in cc4baa617036b3a9712f4195fd13017a0a8c1db0 2024-10-29 20:29:18 ncopa: for the 3.21 builders, libxml2 was never upgraded 2024-10-29 20:29:58 and there we built everythign from scratch 2024-10-29 20:30:07 yes, exactly 2024-10-29 20:30:16 im testing something though 2024-10-29 20:30:18 which rules out ABI breaking, right? 2024-10-29 20:30:18 what if 2024-10-29 20:30:41 --enable-legacy touches the structs 2024-10-29 20:30:49 the public data structs 2024-10-29 20:31:07 libxml2 was first built without --enable-legacy 2024-10-29 20:31:13 ncopa: Note that it could be reproduced on freebsd 2024-10-29 20:31:31 Not sure if it was with or without --enable-legacy 2024-10-29 20:31:43 > I reproduced this in both alpine-based docker and FreeBSD with 2.13.4, looks like something has changed in libxml2 2.13. 2024-10-29 20:31:46 then libxslt was built with the new libxml2 structs (wihtout legacy) 2024-10-29 20:32:14 then we enabled legacy - but did not rebuild libxsl2 2024-10-29 20:32:18 libxslt 2024-10-29 20:32:51 *if* the public data struct changes without rebuilds, it may lead to memory corruption 2024-10-29 20:33:24 which is exactly why the silent ABI breakage in libxml2 is so severe 2024-10-29 20:33:28 But did that happen while the builders were building already? 2024-10-29 20:33:32 i dont know 2024-10-29 20:33:39 the commit is from the 15th 2024-10-29 20:34:06 im just saying, that I dont trust libxml2 at this point 2024-10-29 20:34:10 whatsoever 2024-10-29 20:34:11 me neither 2024-10-29 20:34:24 which is why I suggested disabling it for nginx 2024-10-29 20:35:07 But it goes further than just https://nginx.org/en/docs/http/ngx_http_xslt_module.html 2024-10-29 20:40:49 ncopa: locally the tests pass just fine 2024-10-29 20:43:34 ikke: maybe older version is installed on builders somehow... 2024-10-29 20:45:44 no 2024-10-29 20:46:16 (76/112) Installing libxml2 (2.13.4-r1) 2024-10-29 20:46:24 (81/112) Installing libxslt (1.1.42-r0) 2024-10-29 20:46:51 yep( and here it passed https://build.alpinelinux.org/buildlogs/build-3-21-armv7/main/nginx/nginx-1.26.2-r0.log 2024-10-29 20:47:22 exactly the same version of packages 2024-10-29 20:49:40 Hmm, the 3.21 builder does have an r0 package for libxml2 2024-10-29 20:49:48 (x86_64) 2024-10-29 20:50:26 armv7 just has r1 2024-10-29 20:50:29 ikke: comparing deps armv7 vs x86 https://gitlab.alpinelinux.org/-/snippets/1176 2024-10-29 20:51:10 ncopa: should I try to rebuild libxslt on x86_64? 2024-10-29 20:53:46 andypost[m]: non of those appear to be relevant 2024-10-29 21:00:33 ikke: I'd better bump libxml2 and make sure builders updated 2024-10-29 21:00:55 andypost[m]: the theory is that libxml2 got updated after libxslt was built 2024-10-29 21:01:34 Though, that appears not to be the case either: 2024-10-29 21:01:36 Oct 15 10:54 libxml2-2.13.4-r1.apk 2024-10-29 21:01:38 Oct 15 10:58 libxslt-1.1.42-r0.apk 2024-10-29 21:02:18 https://gitlab.gnome.org/GNOME/libxml2/-/issues/751#note_2254693 2024-10-29 21:03:07 We have --with-legacy 2024-10-29 21:04:27 cc4baa617036b3a9712f4195fd13017a0a8c1db0 2024-10-29 21:08:00 ikke: which version is installed on loogarch builder? still strange it passed 2024-10-29 21:15:18 filed !74355 as commit for libxslt went in before legacy option enabled 2024-10-29 21:17:38 andypost[m]: on x86_64 libxsl2 was built after libxml2 -r1 2024-10-29 21:20:32 ikke: I bet it for edge but there's no libxml at all https://build.alpinelinux.org/buildlogs/build-3-21-x86_64/main/ 2024-10-29 21:21:19 There are no logs, but I'm checking the package folder on the builder 2024-10-29 21:21:30 (no logs because it was built during bootstrap of the builder) 2024-10-29 21:22:35 then lets bump both) 2024-10-29 21:28:58 I'm not hopeful since it could bot reproduced on freebsd 2024-10-29 21:36:13 pu: As I said, I can very well make my own Alpine ISO using the wiki article I linked, but that's not the same as an OS delivering its own, official, base system. I feel like Alpine is lacking its own base system and I would like to help change that. I have personally used OSes based on the Linux kernel for over 5 years now. No experience maintaining/helping develop one, but I'm 2024-10-29 21:36:15 open to learn. 2024-10-29 22:02:06 ikke: s390x also passing somehow 2024-10-29 22:08:03 maybe the CI could have a soname compliance checker. that silent abi breakages will be noticed 2024-10-29 22:08:24 could be part of checkapk 2024-10-29 22:13:59 soname and abi are separate things 2024-10-29 22:14:34 and an abi check like libabigail abidiff requires debug info to be useful 2024-10-29 22:15:34 well, soname should change when abi changes. 2024-10-29 22:16:33 should, yes, but frequently things do a soname transition without any abi changes, or forget one when it did 2024-10-29 22:16:38 it's more of a pinky swear concept 2024-10-29 22:17:05 aleksi_: what do you mean by "base system"? 2024-10-29 22:20:15 Ariadne: like a *BSD base system. 2024-10-29 22:20:26 and why would alpine want that? 2024-10-29 22:21:10 i guess i am just trying to understand what problem you are trying to solve for :) 2024-10-29 22:22:23 because alpine clearly takes some inspiration from the *BSDs. Sorry, I have to go now. This article explains what a base system is: https://www.over-yonder.net/~fullermd/rants/bsd4linux/03 2024-10-29 22:22:44 i am well aware of what the BSD layout is 2024-10-29 22:23:27 Alpine would greatly improve from a base system because it has never shipped a full OS, only installers, which hinders offline work. I think it is very important to be able to have a complete system offline. 2024-10-29 22:23:34 Sorry, I'll be back later. 2024-10-29 22:24:15 well you install your required stuff and it's offline. a base system would install a lot of stuff you don't need, and miss stuff you need. 2024-10-29 22:25:11 alpine takes inspiration from anything that has good ideas that are useful to alpine 2024-10-29 22:25:26 i'm not convinced importing a bunch of source code into a BSD-like source tree is useful to alpine ;) 2024-10-29 22:25:48 even FreeBSD is trying to get away from the monolithic tree and use pkg(1) to manage the base system 2024-10-29 22:26:28 monolithic source trees are a nightmare to deal with 2024-10-29 22:27:18 yes. if anything, alpine should aspire to become even more modular than it already is. 2024-10-29 22:29:15 I think there are other, perhaps mostly historic, reasons why there's a base and then additional packages through ports or a package manager 2024-10-29 22:30:24 and I thought there was talk in, at least, FreeBSD of changing that 2024-10-29 22:31:01 yeah, bapt is still driving that work 2024-10-29 22:33:30 But if we're talking about offline installation, then there are two thoughts: 1) It may be nice having an image which contains every package that would be otherwise downloaded from the internet so installation can be completed without internet connection. But one would need to download additional stuff anyway to make something useful out of the freshlu installed system and that 2024-10-29 22:33:32 would require internet anyway... 2024-10-29 22:34:10 we can certainly generate ISOs with a snapshot of the entire alpine package collection 2024-10-29 22:34:22 that part is easy ;) 2024-10-29 22:36:28 2) I've played with Debian 3.0, and it has the perk of having everything on like 2 CDs, so you can have a system with DE and stuff without the internet. But nowadays... I don't think it would be feasible, unless one wants to dd the whole thing to a big enough HDD 2024-10-29 22:41:00 main is quite a managable size, while i'm not saying this is a good idea, it would be possible to build installation media wich have it included and configured as a local repo :D 2024-10-29 22:43:10 but the "machine without networking" usecase is rare enough that if someone has a need for it they can just cobble it together themselves 2024-10-29 22:45:35 that's how i test my SuperH port on real hardware, since i have no compatible network card 2024-10-29 22:48:21 mission creep. goes against both "small" and "simple" i don't see a bunch of people asking for this. 2024-10-29 22:59:25 i'm not really sure that is the mission anymore 2024-10-29 22:59:40 alpine has evolved into being a universal OS 2024-10-30 01:37:15 quite 2024-10-30 01:37:31 the project is not small and simple, but I still hope an installation can be 2024-10-30 02:15:32 hello 2024-10-30 07:30:28 Hi, I've created a Merge request for Oils, a Bash compatible alternative at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70331 2024-10-30 07:30:52 And I added a subpackage to replace /bin/sh, as this is possible with the shell 2024-10-30 07:31:18 Because I'd like to test the shell POSIX compliance, e.g. by trying to rebuild all of aports with it, etc. 2024-10-30 07:31:33 But I've seen that Bash itself doesn't provide `/bin/sh`. 2024-10-30 07:32:22 Was this just a maintainer decision, or is there some guideline to say when a package is "allowed" to provide `/bin/sh` apart from being POSIX compliant? 2024-10-30 07:32:33 e.g. it shouldn't be more than a certain size, etc. 2024-10-30 07:32:44 default /bin/sh on alpine is /bin/ash 2024-10-30 07:33:33 yes, but e.g. dash also provides a subpackage `/bin/sh`: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/dash/APKBUILD?ref_type=heads#L34 2024-10-30 07:33:35 it shouldn't be replaced 2024-10-30 07:34:01 but with a lower priority, so that users can replace busybox ash with dash if they like 2024-10-30 07:34:06 dash is posix compliant mostly while bash is not 2024-10-30 07:34:36 Bash is not?? That's news to me! 2024-10-30 07:35:32 I thought it's compliant but with a bunch of added bashisms 2024-10-30 07:36:17 never used bash so I don't know details 2024-10-30 07:39:20 hmm ok... But given that Oils wants to be POSIX compliant I think I'll leave the `/bin/sh` provides for my package request. Thanks anyway for your quick response! 2024-10-30 07:42:11 /bin/sh should not assume any non-posix extensions/features, it should be strictly posix as possible 2024-10-30 07:43:23 because this debian have dash 2024-10-30 07:43:47 that's not what posix compliant means 2024-10-30 07:52:33 right, but tried to summarize 2024-10-30 07:56:30 I think that's a bit up for debate, but I get the point. You don't want to write a script with `#!/bin/sh` shebang, accidentally use an extension because it works and when you run it on a different system it breaks 2024-10-30 07:56:54 But I thought debian has dash because it's also quite a bit faster than bash 2024-10-30 07:57:25 > Since it executes scripts faster than bash, and has fewer library dependencies (making it more robust against software or hardware failures), it is used as the default system shell on Debian systems. 2024-10-30 07:57:35 From the package description https://packages.debian.org/sid/dash 2024-10-30 07:58:19 right, but also because it is posix shell 2024-10-30 07:59:07 iirc bash could be forced to posix by something line 'bash --posix', not sure though 2024-10-30 07:59:09 Yeah but I'm very sure Bash is also posix compliant. It wouldn't be used as /bin/sh on RHEL otherwise 2024-10-30 08:00:11 portable is P in POSIX 2024-10-30 08:00:15 You're right https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html 2024-10-30 08:03:01 I just checked, when you run bash with `/bin/sh` as $0 it sets posix mode automatically on my machine 2024-10-30 08:03:51 So one could use bash as /bin/sh and alpine should just work fine 2024-10-30 08:04:17 I'm not sure this is good idea on alpine 2024-10-30 08:04:44 Yeah it doesn't really make sense, given alpine is built to be minimalistic 2024-10-30 08:06:57 Anyway I'd still like to be able to install Oils as `/bin/sh` in alpine, this would be a perfect test bed. Do you think my MR for Oils in testing would be accepted with a binsh subpackage? 2024-10-30 08:09:12 (MR is here, but currently a draft: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/70331 ) 2024-10-30 08:11:02 I have no idea (I don't use bash and probably will not use oils) 2024-10-30 08:11:50 OK, I'll see then what the reviewers will say :) 2024-10-30 08:12:15 fixed and posted patches for some pkgs which use bash as shell 2024-10-30 08:14:18 Just one last thing: is there a default `provider_priority` set? I'd add a subpackage `oils-bash` which has `provides=bash`, but obviously with lower priority than bash itself. But I'm not sure if I have to add a priority to the bash package as well 2024-10-30 08:15:34 man APKBUILD will tell 2024-10-30 09:15:51 i wanted to port simplex-chat to alpine linux pkgs, but seems it will only build with GHC==9.6.3, meanwhile the version on alpine repos is 9.8.2. In their build script, they manually bootstrap 9.6.3 from ghcup, should I do the same? or is there another way 2024-10-30 10:28:10 Not sure if it's good that it's so tightly bound to a specific compiler version 2024-10-30 10:33:06 nginx fix is coming up! 2024-10-30 10:59:35 ACTION is holding on 2024-10-30 11:00:19 omni: what is the status of llvm 19.1.2? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73931 2024-10-30 11:00:27 it looks like only riscv64 failed due to timeout 2024-10-30 11:02:01 do you think I can merge it? 2024-10-30 11:03:56 Or should we first fix https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/73884 2024-10-30 11:07:43 im merging 19.1.2 2024-10-30 11:17:27 ncopa: nice, I read the thread on gh 2024-10-30 11:18:59 ncopa: šŸ‘ 2024-10-30 11:23:25 ncopa: only puzzle for me is why I could not reproduce it in my container 2024-10-30 11:24:01 that is weird indeed 2024-10-30 11:42:59 ncopa: moreover 3 archs passed it too 2024-10-30 12:48:04 ncopa: I'm thinking, perhaps there should be a xen-openrc sub-package 2024-10-30 13:15:45 seeing two aports so far have this issue, should they be left as-is and wait until upstream fixes? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114970 2024-10-30 13:19:49 (seems to affect 32-bit arm only) 2024-10-30 13:21:44 "fancsali: abuild rootbld need it..." <- Yeah, I realised I was working in the `pmaports` tree ā€“ my bad! šŸ¤¦ā€ā™‚ļø 2024-10-30 14:01:23 ncopa: if your stress levels come down a bit, would be nice to get some feedback on 2024-10-30 14:01:37 https://gitlab.alpinelinux.org/alpine/mdev-conf/-/merge_requests/14 and https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/88 2024-10-30 15:09:05 huh, eudev r[34] removed split-usr support in two steps since end sept. which means upgrading on legacy systems with a split-usr layout will bork the system of the unwitting users. 2024-10-30 15:09:40 i do get it, future systems, and docker imgs don't care. but those systems that are old/legacy should not be broken by such changes in policy. 2024-10-30 15:10:51 actually r[45] did, the last good revision is r3 2024-10-30 15:12:49 Those systems will need to migrate after https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/88 2024-10-30 15:12:57 But I guess we shouldn't break them before 2024-10-30 15:13:46 Is it enough for you if we roll back the --split-usr option? 2024-10-30 15:13:51 what does migrate mean for systems that have small / and reasoably big /usr partitions? 2024-10-30 15:14:20 Being able to mount /usr from initramfs 2024-10-30 15:14:39 i tried first r4 which is only the --enable-split-usr but that was not enough, since in r4 the /lib/udev directory was already missing 2024-10-30 15:14:40 The patch that adds support for it is already merged, but not in a release 2024-10-30 15:15:27 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/72150 2024-10-30 15:15:35 i guess if mount /usr from initramfs could be a solution. 2024-10-30 15:15:52 If you can try with that patch, that'd be very welcomed 2024-10-30 15:16:03 Unfortunately I'm gone now until next Monday 2024-10-30 15:17:07 which patch? 72150? 2024-10-30 15:17:26 Yes 2024-10-30 15:17:44 i'll have a look. 2024-10-30 15:17:46 thx 2024-10-30 15:18:37 I'll ping you next Monday about it 2024-10-30 15:18:52 ack! 2024-10-30 15:19:09 enjoy your afk time! 2024-10-30 15:19:12 And thanks a lot for testing it and notifying for breaks in your setup 2024-10-30 15:19:49 Seems like if we manage to not break it, then it's unlikely we break others 2024-10-30 15:20:25 BTW, if your filesystems in / and /usr are different, you might need to modify your mkinitfs to add whatever is needed 2024-10-30 15:20:35 Leaving now, and thanks for the wishes! 2024-10-30 15:20:39 <3 2024-10-30 15:38:38 Alpine is mentioned in https://www.phoronix.com/news/Edera-OpenPaX-Announced 2024-10-30 15:39:35 yes 2024-10-30 15:39:40 see also #alpine-hardened :) 2024-10-30 15:40:08 it is my intent in alpine 3.22 to have a hardened variant that is roughly ~equivalent to alpine in the grsecurity days 2024-10-30 15:40:27 I see 'kaniini' in GH ;0 2024-10-30 15:40:32 uh 2024-10-30 15:40:42 s/;0/:)/ 2024-10-30 15:41:24 i just have not had a working situation for a long time where i could spend large parts of my time working on alpine 2024-10-30 15:41:35 so this has been a backburner item 2024-10-30 15:43:14 For the noob here, why is such a patch not upstreamed to mainline Linux? 2024-10-30 15:43:23 I'm loosing interests to such things though I think they should be default 2024-10-30 15:43:33 PaX changes the contract for userspace 2024-10-30 15:43:42 so it will be hard for it to go upstream 2024-10-30 15:43:46 i intend to try though :) 2024-10-30 15:44:00 ah yeah that makes sense, "don't break userspace" 2024-10-30 15:44:44 eh, except when it breaks ;) 2024-10-30 15:44:51 Oh wait you work for/are Edera, nice! 2024-10-30 15:45:11 yeah, "don't break userspace" is to Linux what "don't be evil" is to Google :P 2024-10-30 15:45:28 :) 2024-10-30 15:45:38 usr-merge is breaking userspace :p 2024-10-30 15:45:40 (for some) 2024-10-30 15:45:49 that's not a kernel thing though 2024-10-30 15:45:50 omni: for me 2024-10-30 15:46:07 I don't see how that breaks userspace. Also, Alpine is not the kernel 2024-10-30 15:46:56 W^X does break userspace in some cases (for example, JIT) 2024-10-30 15:47:56 though Linus has said he would accept PaX (without NX-bit emulation) before 2024-10-30 15:50:45 lol @ phoronix post 1st comment 2024-10-30 15:51:23 yes, going to create a kernel module and have it parse data in kernelspace without any checks 2024-10-30 15:51:25 they got me! 2024-10-30 15:56:20 :D 2024-10-30 16:04:08 also re "don't break userspace" --- my userspace-breaking patch is awaiting review 2024-10-30 16:10:33 I agree that most things should go into /usr, and a lot of the usr-merge work is cleanup, but moving everything will break setups and the way it is done feels a bit rushed 2024-10-30 16:11:36 My setup already got broken 2024-10-30 16:11:55 unfortunate 2024-10-30 16:13:28 i look forward to the angry blog post from brad 2024-10-30 16:13:57 isn't brad always angry 2024-10-30 16:14:03 he seemed to me that way 2024-10-30 16:14:30 pretty much. 2024-10-30 16:16:15 talking about it like that doesn't help, lumping people together who happen to have made similar choices, but perhaps for different reasons 2024-10-30 16:32:42 invoked: well, he could have just kept the grsecurity patch public, and then there wouldn't be any need :) 2024-10-30 16:33:04 but since he did not, then we have to reimplement it one piece at a time 2024-10-30 16:40:16 yeah. i'm not trying to stir the pot, i respect him. it's just ... unfortunate all around, the time lost 2024-10-30 16:43:46 i respect him as well, he is technically brilliant 2024-10-30 16:44:53 however, in order to maintain this, we need a patchset that is actually broken out 2024-10-30 16:45:01 otherwise rebasing is hell :) 2024-10-30 16:45:18 and... to get to broken out patches, that means you basically have to reimplement it 2024-10-30 18:05:25 regarding clang17 failing: https://github.com/llvm/llvm-project/issues/78691 2024-10-30 18:52:02 abseil-cpp is running already for 35 hours :| 2024-10-30 18:52:13 On rv64, and still continuing 2024-10-30 19:24:03 ikke: thats where using somethign like qemu-usermode could be faster than using embedded system SBCs 2024-10-30 19:25:59 We are not using SBCs 2024-10-30 19:27:45 cool, so what kind of h/w are you using ? or is it qemu 2024-10-30 19:27:55 milkv pioneer 2024-10-30 19:29:12 oh cool, that has a decent performance 2024-10-30 19:30:30 I have access to one of early ones 2024-10-30 19:40:58 the abseil-cpp ci job runs in a qemu vm on an M3 btw 2024-10-30 19:45:56 FYI the syntax-highlighting package seems to be corrupt(?) I'm not totally sure what's going on but it's reproducible for me and someone else located elsewhere (so probably not a http dl issue?): https://gitlab.alpinelinux.org/alpine/aports/-/issues/16574 2024-10-30 19:46:09 craftyguy: was just replying to your issue 2024-10-30 19:47:47 ahh ok, sorry for the noise here then :P 2024-10-30 19:49:03 Yeah, it installs fine from the master mirror 2024-10-30 19:51:05 craftyguy: installs fine now for me 2024-10-30 19:56:43 ikke: ya it's working now, thanks :D 2024-10-30 19:57:31 issue is that dl-cdn cached the old package, while the index has a new hash 2024-10-30 19:57:38 because the name does not change 2024-10-30 20:00:54 ahhh makes sense 2024-10-30 20:02:07 so generally it's not necessary to bump the pkgrel just to add a subpackage, because abuild detects that, but dl-cdn gives issues in that case 2024-10-30 20:19:04 i asked this a little earlier today, but had to leave. i'm attemping to port simplex-chat to alpine linux and it requires GHC 9.6.3 (even in their own builds they bootstrap it). should i bootstrap it also (downloading the binaries from haskell)? should i somehow get GHC 9.6.3 from aports (i couldn't figure out how, if that's possible)? 2024-10-30 20:19:28 my plan was going to just bootstrap, but i thought i should ask first 2024-10-30 20:27:32 rdbo: my feeling is whether it's a good idea to package something that needs a very specific compiler version 2024-10-30 20:29:29 i think it's a pretty solid app, currently i use it through flatpak. i'm new to haskell, but from what i read, it seems that the compiler changes can be a bit tricky and not backwards compatible 2024-10-30 20:30:43 i tried compiling with the latest version from aports, and unfortunately i couldn't get it working - seems some dependencies' versions are set as >= A and < B for versions, the later condition being an impeding factor 2024-10-30 20:33:44 maybe instead of bootstrapping it by hand, there should be a `ghcup` package 2024-10-30 20:41:27 Sure, but perhaps letting each user themselves run the specific setup on their system? 2024-10-30 20:44:33 what do you mean? 2024-10-30 20:47:54 i'm gonna try to compile again with the latest version just to make sure it's not my fault, but i suspect they are bootstrapping this specific version because of differences in the compiler 2024-10-30 20:50:18 rdbo: I looked at packaging simplex last year but gave up !49714 2024-10-30 20:51:31 hmmm, i'm gonna look into that 2024-10-30 20:53:36 I think I tried with both stack and cabal 2024-10-30 20:54:34 the thing is, i managed to build it by hand already using cabal, but i had to bootstrap 9.6.3 2024-10-30 20:54:36 perhaps someone has succeded in another distro and there are clues there on how to do it with the version of ghc we have 2024-10-30 20:54:45 with > 9.6.3 and < 9.6.3 it wasn't working 2024-10-30 21:03:35 https://aur.archlinux.org/packages/simplex-chat-git 2024-10-30 21:05:08 Though apparently archlinux still has 9.2 2024-10-30 21:05:11 (ghc) 2024-10-30 21:07:35 this one is using cabal instead of stack it seems 2024-10-30 21:07:44 actually the other way around 2024-10-30 21:42:51 omg i think i did it 2024-10-30 21:43:05 it's building this time, i bypassed my other error 2024-10-30 22:10:36 celebrated too early :'( 2024-10-30 22:38:26 WhyNotHugo: usbmuxd post-install is failing on install :/ 2024-10-30 22:38:31 https://build.alpinelinux.org/buildlogs//build-edge-riscv64/testing/ifuse/ifuse-1.1.4-r5.log 2024-10-30 22:38:53 and stderr is going to null, so we don't even know why 2024-10-30 22:42:48 ah. user already exists is exit code 1, which is why the scripts with adduser usually contain an `exit 0` 2024-10-30 22:42:53 it's not there in usbmuxd, i'll add it 2024-10-30 22:43:34 also i just realized i pinged the wrong person, the package changed hands today 2024-10-30 22:43:45 sorryy 2024-10-30 23:22:46 hmm.. I wonder if that testing/electron/musl-sandbox.patch does something we could add to community/qt6-qtwebengine/0007-musl-sandbox.patch ... 2024-10-30 23:22:56 PureTryOut: ^^ 2024-10-31 05:49:42 ptrc: no worries, glad you figured it out. 2024-10-31 10:47:37 Is there a command to remove a package from an index? i've got some old packages in a personal index i dont want in there anymore 2024-10-31 10:57:13 abuild removepkg and abuild removeoldpkg if you are in the directory with the APKBUILD 2024-10-31 11:00:06 oh cool, got it 2024-10-31 11:06:13 clean or remove 2024-10-31 11:06:37 ? 2024-10-31 11:17:16 you are right, clean 2024-10-31 11:17:21 cleanpkg, cleanoldpkg 2024-10-31 11:23:11 I daily use clean but thought maybe there is undocumented remove variant 2024-10-31 13:23:32 PureTryOut: I'll see if I can find some time some day and go through patches for various other chromium(-based) aports 2024-10-31 13:45:04 That'd be great, thanks! 2024-10-31 17:02:35 https://i.imgur.com/nM7jKqc.png 2024-10-31 17:26:50 is there a known issue with xsltproc? a number of aports are failing at generating manpages due to `I/O error : unsupported protocol: https` 2024-10-31 17:27:49 and `cannot parse http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl` 2024-10-31 17:28:22 checked 2 of the aports previously passed on 3.21 loongarch64 builder 2024-10-31 17:29:27 example error: https://build.alpinelinux.org/buildlogs/build-3-21-x86/community/glade/glade-3.40.0-r7.log 2024-10-31 17:29:40 and previously, on loongarch64: https://build.alpinelinux.org/buildlogs/build-3-21-loongarch64/community/glade/glade-3.40.0-r7.log 2024-10-31 17:33:03 (the url itself can be fetched with curl) 2024-10-31 18:14:47 someone mentioned there was probably something like it in postgresql17 that was reolved. looked around and found a patch to main/docbook-xsl, not sure if it's related or a similar fix could be applied to resolve for other aports https://git.alpinelinux.org/aports/commit/main/docbook-xsl?id=4e21aff3a888239f6776f3c84e09d48e5c3a40ae 2024-10-31 18:14:59 s/reolved/resolved/ 2024-10-31 19:42:29 on the docbook-xsl issue, downgrading to -r9 worked for me locally, rebuilding one of the affected aports was fine, while the error occurred with -r10