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