2024-05-01 03:06:19 I think build-3-20-ppc64le is stuck on keycloak-config-cli and build-3-20-riscv64 on php83-pecl-imagick 2024-05-01 04:19:21 ncopa, gdk-pixbuf is “broken” with the last release, support for XPM format has been dropped 2024-05-01 04:19:39 Default configuration has changed upstream in last release, but XPM support wasn't enabled back in the aport 2024-05-01 04:19:45 https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/commit/e052a112075a19fb75f1f2ff3de4c82923de13f2 2024-05-01 04:23:34 quinq: would it be possible to open an issue so that is not forgotten? 2024-05-01 04:23:47 Seems like adding "-D others=enabled" to the build() would fix it 2024-05-01 04:26:03 ok, I'll try to get the time register to the gitlab tomorrow 2024-05-01 05:33:20 riscv64 is going to be a bottle neck for the release 2024-05-01 09:10:58 ikke, ncopa, https://gitlab.alpinelinux.org/alpine/aports/-/issues/16078 2024-05-01 09:11:29 Why do gitlab eat newlines :/ 2024-05-01 09:13:47 quinq: it's markdown 2024-05-01 09:14:52 Yeah I'm reading that 2024-05-01 09:15:09 hahaha “Need more control over line breaks or soft returns? Add a single line break by ending a line with a backslash” 2024-05-01 09:15:20 So… In order to get a newline, you need to escape a newline -_- 2024-05-01 09:15:28 That's completely the opposite of what escaping is 2024-05-01 09:16:01 Anyway, done 2024-05-01 09:16:25 (from there https://docs.gitlab.com/ee/user/markdown.html#newlines) 2024-05-01 09:17:27 quinq: 2 spaces at the end work as well 2024-05-01 09:17:49 Thanks for creating the issue 2024-05-01 09:18:14 No need, thank you (collectively) for maintaning those packages :) 2024-05-01 09:20:12 Small pedantic question about the Issue template 2024-05-01 09:20:24 It asks for the package version: *Version as obtained by `apk info`* 2024-05-01 09:21:12 What's expected from that, the full version returned by apk info, or an edited one? 2024-05-01 09:21:22 Like gdk-pixbuf-2.42.11-r0 or 2.42.11-r0 2024-05-01 09:21:27 Or it doesn't matter :) 2024-05-01 09:24:41 Either is fine 2024-05-01 09:27:06 ok, thanks 2024-05-01 10:33:37 ncopa, thanks for the fix 2024-05-01 11:59:47 Is there a specific reason why linux-lts and linux-edge in alpine are not using the default for FAT_DEFAULT_IOCHARSET? 2024-05-01 12:01:25 mps, ncopa: those seem to have been like that since the kernels exist in aports, and the "utf-8" values go against upstream default 2024-05-01 12:02:11 I'm hitting a problem where mounting the ESP in my device should make the fs case-insensitive, but it's case-sensitive 2024-05-01 12:02:31 The question is if we should change the defaults, or I should instead modify the mount command 2024-05-01 12:02:44 Background: https://gitlab.com/postmarketOS/pmaports/-/issues/2782 2024-05-01 16:45:50 I dont remember why we chose utf8 as default. fedora uses CONFIG_FAT_DEFAULT_IOCHARSET="ascii" 2024-05-01 16:47:08 arch linux also uses CONFIG_FAT_DEFAULT_IOCHARSET="ascii" 2024-05-01 16:56:27 Debian apparently used to have utf8 so maybe you got it from there 2024-05-01 17:03:43 As for ascii vs iso8859-1, Arch used to be on the latter but then switched to the former to line up with Fedora ( https://wiki.archlinux.org/title/Talk:FAT#c-Nl6720-2022-01-21T08:52:00.000Z-Lacsap-2022-01-20T15:29:00.000Z ) 2024-05-01 18:05:20 hey, could somebody review 2024-05-01 18:05:21 !64102 2024-05-01 18:05:24 :) 2024-05-01 19:27:12 remembered difftool, now i can use meld, using `git difftool -y -t meld` , removing local build of diffuse 2024-05-01 22:10:03 ncopa: I think we'd be happy with "ascii" too. Would you want me to send an MR, or rather fix yourself in next update? 2024-05-01 22:32:43 flakey CI is flakey 2024-05-02 00:27:55 could someone take a look at !61057 2024-05-02 01:06:30 also !65224, a tiny bugfix. Thanks! 2024-05-02 06:26:57 PabloCorreaGomez[m]: I'm just not sure how it will work with the boot media. do we have any packages on release iso with weird names? Unfortunately I don't think I have enough time to test it out 2024-05-02 13:40:29 Hi all. Silly question about SONAME changes: 2024-05-02 13:40:32 ~/gitroot/aports/main/opus $ checkapk 2024-05-02 13:40:32 >>> Size difference for opus: 400 KiB -> 412 KiB 2024-05-02 13:40:32 --- filelist-opus-old 2024-05-02 15:31:30.317935762 +0200 2024-05-02 13:40:32 +++ filelist-opus-new 2024-05-02 15:31:30.317935762 +0200 2024-05-02 13:40:32 @@ -2,4 +2,4 @@ 2024-05-02 13:40:33 usr/ 2024-05-02 13:40:35 usr/lib/ 2024-05-02 13:40:37 usr/lib/libopus.so.0 2024-05-02 13:40:39 -usr/lib/libopus.so.0.9.0 2024-05-02 13:40:41 +usr/lib/libopus.so.0.10.1 2024-05-02 13:40:43 SODIFF: 2024-05-02 13:40:45 -usr/lib/libopus.so.0.9.0: SONAME libopus.so.0 2024-05-02 13:40:47 +usr/lib/libopus.so.0.10.1: SONAME libopus.so.0 2024-05-02 13:40:49 REBUILDS: 2024-05-02 13:40:53 *** 34 packages linked against libopus.so.0 need to be rebuild! 2024-05-02 13:40:55 >>> Size difference for opus-dev: 200 KiB -> 208 KiB 2024-05-02 13:40:57 >>> No soname differences for opus-dev. 2024-05-02 13:40:59 >>> No size differences for opus-doc. 2024-05-02 13:41:01 >>> No soname differences for opus-doc. 2024-05-02 13:41:03 DOH, wrong paste :/ 2024-05-02 13:41:05 sorry 2024-05-02 13:41:07 this one: https://tpaste.us/8Mpb 2024-05-02 13:41:20 which is the same :) 2024-05-02 13:41:32 now, afaik, this is not a SONAME change. 2024-05-02 13:42:11 since libopus.so.0 remains the same. It changes if would have been libopus.so.1 2024-05-02 13:42:14 correct 2024-05-02 13:42:27 ok. 2024-05-02 13:42:33 Sometimes upstream does ABI incompatible changes without bumping soname 2024-05-02 13:42:50 Let's hope not this time 2024-05-02 13:42:50 Then the message is not correct: 2024-05-02 13:42:52 *** 34 packages linked against 2024-05-02 13:43:00 cely, how do I figure that? 2024-05-02 13:43:06 Which version of abuild are you using? 2024-05-02 13:43:33 abuild-3.12.0-r0 2024-05-02 13:43:55 I think that message has been removed in 3.13.0 2024-05-02 13:44:22 ok.. 2024-05-02 13:44:29 I'm on 3.19 2024-05-02 13:46:05 As for the ABI incompatible changes, i guess you could try running an aport that uses libopus 2024-05-02 13:46:11 ah ok 2024-05-02 13:46:46 Our users will tell us if it is something more serious :) 2024-05-02 13:47:54 mpg123 has .0 soname(s) too, and i remember once when a global rebuild was required 2024-05-02 13:48:23 but that should hopefully be rare 2024-05-02 14:02:59 I thought that "-buildmode=pie requires external (cgo) linking, but cgo is not enabled" was fixed 2024-05-02 14:07:48 In which aport are you seeing that? 2024-05-02 14:12:35 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1369634 2024-05-02 14:15:01 I see CGO_ENABLED=0 in the build log 2024-05-02 14:15:09 yes, it's in a cmake file 2024-05-02 14:15:12 I patched it now 2024-05-02 14:16:05 Yeah, that's how the problem was fixed, all aports setting that in Makefiles were patched 2024-05-02 20:21:43 I'm blocking from editing the wiki. Intended blockee: 172.16.6.4 2024-05-02 20:21:47 Autoblocked because your IP address has been recently used by "QualityBacklinkschecker". 2024-05-02 20:22:28 Removed 2024-05-02 20:22:44 that looks like a private ip. i don't think the bot intended to block that. 2024-05-02 20:22:58 thnx 2024-05-02 20:23:26 er, block's still there 2024-05-02 20:24:37 It's an internal IP, it doesn't see the proper external address 2024-05-02 20:24:59 ok, now it's properly gone 2024-05-02 20:25:51 works, thanks 2024-05-03 14:12:06 I'm struggling a bit with install_if. I have a package that had some really hacky bash testing for various tools (rofi, fzf, etc) before installing helper scripts for the main program. A reviewer commented that I should be installing them unconditionally, and then adding subpackages with install_if. I don't understand the pattern. 2024-05-03 14:12:59 The unconditional install would put them in the package. Somehow, install_if would then add them to the user's system IFF the dependencies exist -- is that the way this is supposed to work? 2024-05-03 14:15:41 That sounds right 2024-05-03 14:16:48 From the docs and what I can see in other packages (which hasn't always been an infallible help, IME), you make other helper functions for the helper scripts and use install_if to define dependencies on the (in my case) rofi/xsel/whatever packages? 2024-05-03 14:20:02 install_if installs the subpackage if you already have the packages installed, but if you want to make the subpackage installable by itself, (as far as i know) you will need a separate depends in the split function for that 2024-05-03 14:20:14 The copy/paste development pattern is super-unhelpful here ;-) 2024-05-03 14:21:05 Hm. In my case, the subpackages are useless without the main package. 2024-05-03 14:21:22 So that's not a permutation I have to worry about. 2024-05-03 14:22:25 The question is, do you want to make `apk add $pkgname-subpackage` work, or do you want to rely on `apk add $pkgname ` to pull in the subpackage automatically via install_if 2024-05-03 14:22:33 I have a tool X that's a CLI, and some helper scripts Y and Z that use X in an Xorg session to provide some convenience functions. 2024-05-03 14:22:56 2024-05-03 14:24:43 No to 1, yes to 2... except it's not so much _a_ dependency, as a half-dozen other utilities, mostly X related. 2024-05-03 14:25:16 xdotool, rofi, xprop, yad. The convenience script is only useful if all of those are installed. 2024-05-03 14:26:15 Is the convenience script in 1 file or a few? 2024-05-03 14:26:40 On Arch, I just brute-forced it in the install() section with a long, ugly series of `type` commands, and installed the utility script if that all succeeded. But the Alpine model is different. 2024-05-03 14:26:52 There are two scripts. 2024-05-03 14:27:10 Independent, though, so they'd be two different subpackages. 2024-05-03 14:27:17 If I can do one, I can do the other. 2024-05-03 14:27:50 Oh. But, no, they're both single-file scripts. 2024-05-03 14:31:06 Also, it isn't clear from https://wiki.alpinelinux.org/wiki/APKBUILD_Reference whether you put a bunch of install_if's in series if there are multiple dependencies, or if you separate the dependencies in the one string argument with some separator. 2024-05-03 14:31:25 Anyway, i am working with a really crappy internet connection right now, so not sure i will be able to access the gitlab.a.o web UI to have a look at your merge request 2024-05-03 14:31:59 but maybe you could point me to your Arch PKGBUILD, so i can see how you do things over there 2024-05-03 14:32:37 I could ask Patrycja, but I really hate to ask for tutorial-like help in the MR comments :-/ 2024-05-03 14:32:54 She did the review. 2024-05-03 14:33:08 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63562 2024-05-03 14:33:57 She is here on IRC, you can always ping here, but not sure if you'll be at the computer at the same time she is 2024-05-03 14:34:09 ^She^They^ sorry about the gender-assumption 2024-05-03 14:36:29 Hm. She did her initial review around 8pm my time; I can be around then. 2024-05-03 14:38:24 Oh! Are the arguments in install_if -- after the package declaration -- just all of the dependencies‽ 2024-05-03 14:38:40 That would make it all make sense! 2024-05-03 14:39:14 There's an install=, and an install_if= 2024-05-03 14:39:32 install= is usually used in global scope, while install_if= is used inside the split functions 2024-05-03 14:39:47 Yeah 2024-05-03 14:40:42 I figured that one out from looking at other packages that use it. But my ability to intuit rules from examples is failing me in this case :-/ 2024-05-03 14:44:11 Patrycja suggested install_if, but could I just simplify this (for myself) by using depends within the subpackages? Or would that force the dependencies to be installed by the subpackage? 2024-05-03 14:45:18 I guess -- at this point -- I care less about the helper scripts being installed IFF the user eventually happens to install all of the dependencies of the helpers. I just don't want the helpers installed unless the tools they need are already installed. 2024-05-03 14:46:45 I think install_if will do the latter -- install the helpers if conditions get met at some point. Is there a more easy-to-understand way to just make sure the scripts aren't installed if the tools they need aren't already installed? 2024-05-03 14:46:52 Yes, you can use depends within split functions for the subpackages, and that would mean those dependencies get installed when users do `apk add rook-subpackage` 2024-05-03 14:47:02 Ooooh. 2024-05-03 14:47:20 Huh. Maybe that would work. It seems easier for me to understand, anyway. 2024-05-03 14:50:10 What happens if I figure out `install_if` and do it that way, and users call `apk add rook-subpackage` -- how does apk behave differently than if the dependencies are listed in `depends` 2024-05-03 14:51:18 I think you can use both install_if and depends 2024-05-03 14:51:37 depends will make `apk add rook-subpackage` install the dependencies 2024-05-03 14:51:55 install_if will make `apk add rook` install the subpackage if users already have the dependencies for it installed 2024-05-03 14:51:57 install_if is a reverse dependency 2024-05-03 14:52:09 Hm. Maybe that's better, anyway. Users only need the convenience scripts if they plan to calling them explicitly anyway. 2024-05-03 14:52:09 But also conditional 2024-05-03 14:53:16 s/to calling/to call/ 2024-05-03 14:57:54 K, thanks. I'm going to submit using `depends` and pester Patrycja when I see her. I'm just too shaky on `install_if`. 2024-05-03 14:59:01 Sure, that sounds good, and i think it will work 2024-05-03 14:59:14 Thank you for your guidance! 2024-05-03 14:59:26 You're welcome 2024-05-03 15:02:05 omni: i opened a new MR for qt5-qtwebengine before taking a look at !64367, and it seems out of the 2 patches i have in my MR, python3.12-imp.patch is already in your MR 2024-05-03 15:02:46 I'm not sure what issues you ran into with that MR.. 2024-05-03 15:05:34 but the builders have been stuck on qt5-qtwebengine for a while, so i'm hoping that python3.12-six.patch that i found from Debian will help the build pass 2024-05-03 15:06:36 Debian seems to be using an older commit of 87-based qtwebengine-chromium from last year though 2024-05-03 15:10:35 More specifically, i'm not sure what the "catapult" thing in your MR is, if it is something that was added with a newer git revision of qtwebengine-chromium (that your MR upgrades to) or if it is already present in what we currently have in the APKBUILD 2024-05-03 15:12:14 Ah, now looking at the build log, i see it is most likely related to those "SyntaxWarning: invalid escape sequence" messages 2024-05-03 15:15:09 Grepping through the build log, i see many other places where that SyntaxWarning appears 2024-05-03 15:23:14 Anyway, i see the x86_64 has passed for my qt5-qtwebengine MR 2024-05-03 15:23:36 So has the x86 CI 2024-05-03 15:23:57 good 2024-05-03 15:24:12 cely: You can close the issue I created then 2024-05-03 15:24:50 Should i merge it, or should i wait for Bart or omni? 2024-05-03 15:25:28 tough question, qt5-webengine failing wastes a lot of CPU 2024-05-03 15:25:54 The patch does not seem intrusive 2024-05-03 15:26:06 It isn't really an upgrade, but more of a build fix of what is currently available 2024-05-03 15:26:27 Yes 2024-05-03 15:27:01 Generally we don't wait for maintainers to approve straight-forward fixes of build failures 2024-05-03 15:27:16 But that's mostly adding missing dependencies, disabling arches, updating checksums 2024-05-03 15:29:22 An additional consideration is, once this build issue with Python six is solved, i think very soon omni will follow up with the MR to upgrade the chromium revision used 2024-05-03 15:29:22 for security upgrades 2024-05-03 15:29:59 there is already a draft MR, right? 2024-05-03 15:30:11 Yes, so, if anything in my MR needs to be modified, it can be done then 2024-05-03 15:30:22 Can they be combined? 2024-05-03 15:30:31 and my MR will make the build pass for Alpine 3.20 2024-05-03 15:30:42 It doesn't touch edge 2024-05-03 15:30:51 right 2024-05-03 15:31:07 I'd say go for it 2024-05-03 15:31:58 and as far as i know, community hasn't been uploaded for Alpine 3.20, so what i did won't be used by users 2024-05-03 15:31:59 Ok 2024-05-03 15:32:18 it is more for all the other dependencies of qt5-qtwebengine that are currently blocked by it 2024-05-03 15:32:52 I think i'll let omni do the security upgrade, since that will involve a pkgrel bump, and so will affect edge as well 2024-05-03 15:34:03 With the fix from my MR, i think the security upgrade should be unblocked, unless omni still wants to fix the SyntaxWarning from catapult, but i think it is not only catapult that has the issue 2024-05-03 15:34:27 So, if you really wanted to fix it, you would have to fix quite a few vendored packages 2024-05-03 15:40:37 Right now, we just need it to pass the build 2024-05-03 15:42:13 Oops, looks like the aarch64 CI has failed 2024-05-03 15:42:48 g 2024-05-03 15:42:51 ++: fatal error: Killed signal terminated program cc1plus 2024-05-03 15:42:53 oom 2024-05-03 15:42:58 Yeah 2024-05-03 15:55:02 Anyway, i have updated my MR with the remove imp patch from omni's !64367 2024-05-03 15:55:18 Probably won't be around to see the CI finish though 2024-05-03 15:55:49 I will 2024-05-03 15:56:38 Alright, so i guess that means you will get it in if it succeeds? 2024-05-03 15:57:10 (Well, unless in the meantime, someone comes up with something better, or maybe a reason why that shouldn't be merged.) 2024-05-03 16:01:28 Maybe mark it as ready in that case? 2024-05-03 16:01:49 Sure 2024-05-03 16:04:11 hmm, failed again 2024-05-03 16:04:48 ModuleNotFoundError: No module named 'six.moves' 2024-05-03 16:06:17 Maybe it would be better to just add a makedep on py3-six 2024-05-03 16:08:54 But here we are talking about a vendored py3-six 2024-05-03 16:09:51 I wonder why it didn't fail the first time 2024-05-03 17:01:22 ncopa: after a fast look at the iso, I've seen nothing weird. And in general I've seen 0 files/binaries in boot that were not ascii characters (in general it's only people with i18n that use those characters?). But I probably have too little experience, I guess 2024-05-03 17:01:36 We can work-around it downstream 2024-05-03 17:06:54 cely: looks like it was easier than I thought, I just didn't have the energy to figure out what was needed for 87-based qtwebengine-chromium to build, thanks! 2024-05-03 17:07:14 Did it work? 2024-05-03 17:07:14 well, more simple at leaste 2024-05-03 17:07:32 I was distracted by something else, checked the pipeline with glab, and saw that it was cancelled 2024-05-03 17:07:38 uhm, oh, I assumed since it was merged 2024-05-03 17:07:51 I thought that meant it was cancelled because it was failing, so no point wasting CI time 2024-05-03 17:07:58 but apparently, it was cancelled because it was merged 2024-05-03 17:09:02 Immediately after it was merged, ikke said it failed on 'six.moves', which i misunderstood as it failing in CI 2024-05-03 17:09:05 yes... 2024-05-03 17:09:24 it did fail in CI 2024-05-03 17:09:46 Ok 2024-05-03 17:09:54 it failed on build-3-20-x86, not sure if that build was before or after the merge 2024-05-03 17:09:57 So, i was wondering why it passed the first time 2024-05-03 17:10:07 Did it fail in CI for all archs? 2024-05-03 17:10:17 I think the first run of CI only failed on aarch64 due to OOM 2024-05-03 17:10:33 I looked into #alpine-commits history, and didn't see anything mentioning webengine after the merge 2024-05-03 17:15:58 I rebased mine and removed the catapult updates and we'll see how that goes in CI 2024-05-03 17:16:01 cely: it failed on multiple arches (most) 2024-05-03 17:17:48 the ones where it wasn't disabled, right? 2024-05-03 17:18:06 probably 2024-05-03 17:18:24 The first time it only failed on aarch64 like cely mentioned 2024-05-03 17:19:30 huh, right, ok... 2024-05-03 17:19:54 maybe it does work then 2024-05-03 17:20:31 I think I was on the wrong path thinking that catapult needed to be updated anyway 2024-05-03 17:21:54 Tell me if you find out why it passed on the first run 2024-05-03 17:22:03 The only change i made was switching from my remove imp patch to yours 2024-05-03 17:22:18 and as far as i see, they are the same 2024-05-03 17:22:43 There's a pkgver; there's no pkgdate -- is there a best practice for specifying this sort of thing in the variables? 2024-05-03 17:23:37 Are you building a git revision or something? 2024-05-03 17:23:53 no, man pages. 2024-05-03 17:24:16 The date in man pages is usually the date that the tool was tagged for the version. 2024-05-03 17:24:29 cely: perhaps you got lucky 2024-05-03 17:24:52 it actually built on build-3-20-aarch64 https://build.alpinelinux.org/buildlogs/build-3-20-aarch64/community/qt5-qtwebengine/qt5-qtwebengine-5.15.16-r7.log 2024-05-03 17:26:31 I remember something about SOURCE_EPOCH_DATE, but i haven't used that, and am not sure if that's what you're looking for 2024-05-03 17:27:12 omni: Does this mean it will build sometimes and fail other times? 2024-05-03 17:28:14 I sure hope not 2024-05-03 17:32:18 So, i guess build-3-20-aarch64 has now started building all the revdeps of qt5-qtwebengine 2024-05-03 17:33:34 and it seems build-3-20-armv7 too 2024-05-03 17:36:25 at last! 2024-05-03 17:36:41 ACTION find community/task is out of date for two years 2024-05-03 17:37:47 cely: but I didn't have the python3.12-six.patch, other than in the catapult update? haven't looed closer at it now but I think that was one of the reasons why I tried to update catapult 2024-05-03 17:38:02 ant that may have introduced other issues, why mine didn't built 2024-05-03 17:38:12 Ok 2024-05-03 17:38:36 qaqland: there are... some larger changes... 2024-05-03 17:38:56 qaqland: You are always welcome to open an MR if you get a working upgrade 2024-05-03 17:40:04 omni: Now looking at what you wrote in the commit log, i guess py3-six was the main reason 2024-05-03 17:40:16 but i see some SyntaxWarnings too, and maybe you were trying to solve that too 2024-05-03 17:40:41 Probably some regex changes in Py 3.12 2024-05-03 17:41:08 we did talk about taskwarrior around when the 3.0.0 release came out, the issue is that users need to migrate to the new task databae https://github.com/GothenburgBitFactory/taskwarrior/releases/tag/v3.0.0 2024-05-03 17:42:17 Now build-3-20-armhf has finished qt5-qtwebengine 2024-05-03 17:42:30 So, hopefully it is working on more architectures than not 2024-05-03 17:42:45 cely: I'm happy to forget whatever it was, not least since your cleaner aproach worked 2024-05-03 17:43:20 I think it will build on all 2024-05-03 17:44:32 cely: this package is hard for me to upgrade :( 2024-05-03 17:44:45 By the way, there is #16082 (since you worked on the Boost upgrade) 2024-05-03 17:46:09 Last commit in gpick repo was in June last year 2024-05-03 17:46:40 Maybe this is one aport we'll have to build with boost1.82-dev for now 2024-05-03 17:47:44 If that still works (i didn't try it) 2024-05-03 17:48:50 qaqland: omni mentioned the issues with upgrading it (i wasn't aware of that) 2024-05-03 17:49:04 Anyway, perhaps the new version can be added as a new aport? 2024-05-03 17:51:42 I wonder if !65308 failing on riscv64 has something to do with changes to the riscv64 CI 2024-05-03 17:52:29 (A test is killed with SIGABRT) 2024-05-03 17:54:29 Will look into it more tomorrow (if it is something i can look into anyway, not having a riscv64 to try things out on) 2024-05-03 17:59:19 I think maybe build-3-20-x86 is stuck on py3-tqdm, i've merged !65305 deselecting the failing test (it was originally deselected, before i enabled it with the upgrade as it passed on the CI) 2024-05-03 17:59:46 Seems like it still causes issues on the builders (though it was alright for edge) 2024-05-03 18:01:57 Alright, will be going AFK, bye 2024-05-03 18:11:38 omni: personally i'm not wild about taskwarrior-3 and i'd rather not upgrade until i'm ready to, and it's settled down. it'd be nice if it was a separate port from 2. 2024-05-03 18:12:31 i'm not certain but i'd guess there will be others like me. 2024-05-03 22:47:22 1 2024-05-03 23:51:16 I've started to review MRs of new aports. Are there any guidelines such as adding label or something in particular to look for? 2024-05-04 00:22:27 EvTheFuture: maybe look at ones that were merged already to see if they had any feedback 2024-05-04 00:24:37 from the MR list, you can see which ones had comments pretty easily and you can search for MRs with the 'aports:add' label 2024-05-04 00:28:57 iggy: shall/can I add the label aports:add as well? 2024-05-04 00:30:20 iggy: I've done that so far and also used the experience from feedback to my own new aports. Just wanted to know if there were any general guidelines I should follow that I had missed to read up on. Thank you for the feedback 2024-05-04 00:45:04 WHat if a MR of a new aport looks perfectly fine. Is there any way to mark it ass "looks good" so other people know it has been looked at? 2024-05-04 00:47:04 EvTheFuture: if you have some spare time, you can look for author:fossdd and give some feedback for some stuff :) 2024-05-04 06:37:00 EvTheFuture: Thanks for helping reviewing the MR queue. The most help is needed with reviewing new aports. 2024-05-04 06:37:41 Currently the focus is on building 3.20, so there is less focus on these MRs 2024-05-04 06:44:13 ikke: I'm happy to help, just haven't known how to before. I also have a couple of new aports in the review queue. 2024-05-04 12:01:43 I don't seem to be allowed to do anything with !64897 2024-05-04 12:03:30 You don't see links to rebase? 2024-05-04 12:04:16 no, and also: 2024-05-04 12:04:19 remote: You are not allowed to push code to this project. 2024-05-04 12:06:56 "Allow commits from members who can merge to the target branch" is disabled 2024-05-04 12:18:18 omni: Please mr-hold !65375 2024-05-04 12:32:16 I think build-edge-riscv64 may be stuck on testing/trunk 2024-05-04 12:36:53 The builder host is unreachable 2024-05-04 12:37:30 Ok 2024-05-04 12:59:03 Got a bit of an "interesting" question? How would one re-build an alpine install CD for i686 (currently the x86 release I believe requires SSE2, etc)? 2024-05-04 12:59:47 I've been reading about `abuild` and how to use a chroot to build stuff 2024-05-04 13:00:08 The last time I built a system "almost from scratch" was with Gentoo, long ago 2024-05-04 13:05:31 lmk: do you want to build a complete repo, or just an ISO? 2024-05-04 13:05:38 And yes, SSE2 support is required 2024-05-04 13:07:01 new target: x86_nosse2 :B 2024-05-04 13:09:19 I understand the reasons why we moved to requiring sse2, but I am also sad that I have no good suggestion for an alternative distro to run on x86 hardware without it 2024-05-04 13:17:14 hey can I see an example of using AppStream data to make the APKBUILD? 2024-05-04 13:18:14 DaKnig[m]: Sorry, I'm not sure what you are asking about 2024-05-04 13:18:56 I feel like I have most of the info I need for APKBUILD inside the metainfo.xml file 2024-05-04 13:19:02 do I really need that duplicated? 2024-05-04 13:19:09 is there a way to make APKBUILD from metainfo.xml file? 2024-05-04 13:19:28 I found this https://wiki.alpinelinux.org/wiki/AppStream but it's quite confusing. 2024-05-04 13:20:03 I'd like to see a package that actually uses that. see, I am shipping my app DewDuct to alpine. 2024-05-04 13:22:11 The appstream we provide is generated from packages, so the package is already built 2024-05-04 13:22:14 it's not used as a source 2024-05-04 13:24:00 that is strange. gnome programs using libadwaita embed appstream files at compile time and use them to display information like "about" 2024-05-04 13:24:45 like [here](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/ctor.AboutWindow.new_from_appdata.html) 2024-05-04 13:28:13 ikke: potentially every package? but I would expect the first step would be to get a bootable system 2024-05-04 13:28:47 lua-aports provides a command called build-repo, which can build all packages in a repostiry in build-order 2024-05-04 13:35:14 ikke: what about this? https://github.com/alpinelinux/aports/blob/master/scripts/bootstrap.sh 2024-05-04 15:49:34 ncopa, fossdd: there has been some upstream progress https://github.com/scipy/scipy/pull/20607 2024-05-04 15:49:47 perhaps 1.13.1 will be ready for use 2024-05-04 15:50:08 ah thats nice 2024-05-04 15:50:09 when it is released 2024-05-04 17:17:16 Can someone take a look to my PR at !62362 ? 2024-05-04 17:17:37 NekoCWD[m]: What about it, it has been merged? 2024-05-04 17:17:46 sorry, !64586\ 2024-05-04 17:19:16 huge screenshots 2024-05-04 19:09:24 hola 2024-05-04 19:09:29 Got a kodi crash 2024-05-04 19:09:35 Fatal Python error: PyImport_AppendInittab: PyImport_AppendInittab() may not be called after Py_Initialize() 2024-05-04 19:09:46 It's right at startup 2024-05-04 19:40:39 quinq: Did you check the kodi bug tracker? 2024-05-04 19:40:50 May be some python 3.12 incompattibility 2024-05-04 19:46:41 I did, doesn't seem to have anything opened there 2024-05-04 19:48:09 Similar error: https://github.com/lincolnloop/pyuwsgi-wheels/issues/20 2024-05-04 19:48:50 Sorry, I misread 2024-05-04 19:48:57 I didn't check kodi tracker, only Alpine 2024-05-04 19:49:26 Possibly related to uwsgi 2024-05-04 19:49:43 https://github.com/xbmc/xbmc/issues/24069 2024-05-04 19:50:04 Seems it's happening when trying to fork 2024-05-04 19:50:13 crash starts in __clone() 2024-05-04 19:50:25 https://github.com/xbmc/xbmc/commit/4bf9de87e700f0de56ef698a8d8d6eb7d4ff9050 2024-05-04 19:50:47 Looks like it :) 2024-05-04 19:52:45 Though that commit is more than a year old 2024-05-04 19:54:31 Ah ok, it's only been released for a month 2024-05-05 10:54:24 Valery Kartel doesn't seem to have been active for the past couple of years, perhaps their aports should be adopted by others who are more active 2024-05-05 10:54:35 Yes 2024-05-05 10:58:00 I think they never even have logged into gitlab 2024-05-05 11:00:06 12 aports in main, 17 in community and 5 in testing 2024-05-05 11:05:41 omni: was this triggered by the logwatch bugreport? 2024-05-05 11:18:27 no, by !654011 2024-05-05 11:18:37 !65401 2024-05-05 11:19:00 and I've thought of it before 2024-05-05 11:20:19 ok, because logwatch is also maintained by vaka 2024-05-05 11:21:05 Dmitry Romanenko hasn't been active for a couple of years either, one aport in main, seven in community and one in testing 2024-05-05 11:22:20 and that I saw from that tests for py3-coverage are disabled since checkdepends are in community, a couple of them where Dmitry is maintainer 2024-05-05 13:50:48 I see @nmeum has fixed tpm2-abrmd and tpm2-tss-engine, even though i have !64820, so i will close my MR. By the way, gnome-remote-desktop will most likely need a similar fix. 2024-05-05 13:51:22 sorry, didn't see your mr. just went through the build failures in #alpine-commits 2024-05-05 14:56:51 Hi. I need to update an APKINDEX file for a repository but currently do not have access to an Alpine install or docker container. Is there a way to rebuild the index with tools available on MacOS or Windows? 2024-05-05 14:57:28 alpine WSL? 2024-05-05 14:58:19 I do not have admin access on the machine I am working on, so I won't be able to set up any new software outside of those that does not need to be installed to run 2024-05-05 14:58:55 Looks like you'll have to wait to get your hands on a proper computer :/ 2024-05-05 14:59:15 I feared as much :( 2024-05-05 15:00:26 Does the apk index command add any magic to the resulting tar.gz file? I am wondering if I can just update an old APKINDEX file, tar it and call it a da 2024-05-05 15:00:33 Call it a day * 2024-05-05 15:01:05 Well, technically you could do that manually I suppose 2024-05-05 15:01:17 https://wiki.alpinelinux.org/wiki/Apk_spec 2024-05-05 15:04:41 That's some very handy info. Thank you very much, I think that will work for me :) 2024-05-05 15:06:47 Onlything else it does is signing the index, which is a bit tricky to do manually 2024-05-05 16:38:57 2 large CI jobs are blocking rv64 CI 2024-05-05 16:47:22 Just curious, what are they? 2024-05-05 16:51:27 proj and qt6 2024-05-05 17:43:54 rv64 has 2800 packages to go 2024-05-05 17:46:08 For better news, i think we are just 1 or 2 packages away from s390x uploading 3.20 community 2024-05-05 17:52:27 and that may be solved by !65425 and !65433 2024-05-05 22:46:10 why isn't /usr/share/examples/$pkgname included in $pkgname-doc? 2024-05-06 02:34:45 4 more aports to go for build-3-20-armhf to upload community: git-branchless, helix, rnp, virt-manager 2024-05-06 03:21:46 rnp has !65414, git-branchless !65321 2024-05-06 03:24:12 virt-manager: #15924 (upstream: https://github.com/virt-manager/virt-manager/issues/648) 2024-05-06 03:28:27 helix test failures was noticed in !64458 2024-05-06 04:08:01 To that 4, it seems armv7 and ppc64le add another 2, but they're different 2024-05-06 04:11:35 armv7 adds jellyfin and rkward; whereas ppc64le adds ncspot and wezterm (these 2 are very likely failing due to changes in Rust 1.78, as the other archs built them successfully with 1.77, ppc64le was a bit behind when the new Rust was merged, so did not get to these aports until after that) 2024-05-06 04:28:43 To summarize again, the failing aports for the archs with less than 10 left should be: 2024-05-06 04:29:19 armhf (4): git-branchless, helix, rnp, virt-manager 2024-05-06 04:29:52 armv7 (6): git-branchless, helix, rnp, virt-manager, jellyfin, rkward 2024-05-06 04:30:06 ppc64le (6): git-branchless, helix, rnp, virt-manager, ncspot, wezterm 2024-05-06 04:31:16 x86 (8): git-branchless, helix, rnp, virt-manager, rkward, cargo-edit, pcc-libs, pcc 2024-05-06 04:32:20 aarch64 (9): git-branchless, helix, rnp, virt-manager, jellyfin, rkward, ezstream, neo4j, jellyfin-web 2024-05-06 05:38:26 does someone here know how to claim a user account on the gitlab install? i noticed i already have an account (https://gitlab.alpinelinux.org/fusl) but no way to sign in since i never signed up there and always used to pr my changes back at github 2024-05-06 05:39:31 (i tried a password reset using the email address i used to put into my maintained packages but that never arrived) 2024-05-06 05:42:33 Fusl: I'll pm you 2024-05-06 06:12:17 I think build-3-20-x86_64 may be stuck on community/deno 2024-05-06 07:27:53 looks like yes 2024-05-06 08:06:48 hello, this is not strictly an alpine question, but can someone explain to me how to bootstrap either gcc with ada support or gnat-gpl on musl? 2024-05-06 08:07:04 like, how did the alpine team managed to compile gcc[ada] on musl? 2024-05-06 08:07:42 for the records this is for a musl installation of gentoo with the llvm toolchain 2024-05-06 08:07:43 oh thats a good question. probably somebody managed to cross compile build it? 2024-05-06 08:08:02 huh 2024-05-06 08:08:15 well cross compiling is a bit hacky, isn't it? 2024-05-06 08:08:32 I would guest host would be glibc/llvm and target musl libc? 2024-05-06 08:08:36 im looking at the git log 2024-05-06 08:08:43 which pkg? 2024-05-06 08:08:47 gcc 2024-05-06 08:08:55 let me look at it too 2024-05-06 08:09:10 81a0e21b890d05d0012d2c6a16e955bdca66da49 2024-05-06 08:09:54 somebody built a cross compiled gcc with ada support 2024-05-06 08:10:06 note that this happened before we switched to musl libc 2024-05-06 08:10:52 so you suggest that the most painless way would be to cross compile gcc? 2024-05-06 08:11:08 do I use buildroot or crossdev? 2024-05-06 08:11:18 i dont think you have many other options 2024-05-06 08:11:25 no idea what you use for that 2024-05-06 08:11:41 well i'll try to "brute force" it with crossdev 2024-05-06 08:11:42 i think we used our own bootstrap script 2024-05-06 08:11:56 uh where do I find those? 2024-05-06 08:12:11 scripts/bootstrap.sh 2024-05-06 08:12:18 in the gcc git repo? 2024-05-06 08:12:55 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/scripts/bootstrap.sh?ref_type=heads 2024-05-06 08:13:36 thanks 2024-05-06 08:15:58 time to spin up an alpine container 2024-05-06 08:17:08 do I just ./bootstrap.sh gcc x86_64 or do I need to take some extra steps? 2024-05-06 08:22:18 hi, can anyone look into this one and suggest what is the best way to do it? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62446 2024-05-06 08:29:28 It helps to add more context to the MR why a separate package is needed (which needs to be kept up-to-date) 2024-05-06 08:44:12 ikke: i asked the author to add context to MR description. this is needed on some ARM SoCs for hardware accelerated video decoding. there are 2 APIs for this: v4l2m2m (supported in upstream ffmpeg) and v4l2-request (needs this fork) 2024-05-06 08:44:34 https://wiki.postmarketos.org/wiki/Hardware_video_acceleration has a bit info about this 2024-05-06 09:00:36 just updated MR !62446 descrition with brief details too 2024-05-06 09:33:01 topologic-hydra: it's not really hacky 2024-05-06 09:33:03 it's just how it works 2024-05-06 09:33:09 you can just do it via crossdev and it should work fine.. 2024-05-06 09:33:15 (I think I mentioned this to you before) 2024-05-06 09:33:22 if you want to use the alpine binary though, you can, it's just "less pure" 2024-05-06 09:33:32 (you're already relying on whatever binaries for your system, but now you're relying on alpine ones too) 2024-05-06 10:07:02 looks like the CVE in !63398 didn't got backported to older versions. is there a reason or was this just forgotten? 2024-05-06 10:10:50 otherwise i could create MRs for it 2024-05-06 10:16:04 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65087 is finally building on all arches, including a test-fix upstream. Would be lovely if somebody could have a look 2024-05-06 10:21:36 thats nice! 2024-05-06 11:39:44 Could someone have a look at !64741? Alpine 3.20 is due in around a week and I would like for this to get some testing before upgrading to GNOME Session 46 (which I would like to have in Alpine 3.20) 2024-05-06 12:29:34 I got libgbinder packaged mentioned in index not found when aarch64 apk upgrade 2024-05-06 12:29:40 known? 2024-05-06 12:42:25 Is something happening to the index again? 2024-05-06 12:44:13 I think there was !65484 which mentioned a bad signature error 2024-05-06 12:49:38 staceee: libgbinder on aarch64 edge works for me 2024-05-06 12:49:44 unless you meant some different Alpine version 2024-05-06 12:51:52 edge 2024-05-06 12:52:48 https://paste.sr.ht/~stacyharper/331c3160838bb60549899c86b775d9d8dc31f615 2024-05-06 12:53:15 oh, where did you get dl-4 from? 2024-05-06 12:53:25 apk policy libgbinder only speak about 1.1.38-r0 2024-05-06 12:53:30 that mirror has been deprecated ages ago 2024-05-06 12:53:34 oh 2024-05-06 12:53:52 but then, hm, maybe eu.edge.kernel.org is behind 2024-05-06 12:54:42 dl-4 points to our t1 infra, so that should be up-to-date 2024-05-06 12:54:45 I've removed this dl-4, had some mesa downgrade, but nothing changed for libgbinder 2024-05-06 12:55:03 I don't think dl-4 is the issue 2024-05-06 12:55:39 mirror.missbanal.net is my personal repo, but never had libginder 2024-05-06 12:56:19 ah now apk policy libgbinder say that eu. got 1.1.39 2024-05-06 12:56:43 maybe they did a partial sync somehow? 2024-05-06 12:56:51 updated APKINDEX, but not the .apks 2024-05-06 12:57:14 yap it does not contains 1.1.39-r0 2024-05-06 12:57:20 only .38 2024-05-06 16:01:04 why remote-file in source needs to rename like $pkgname-$pkgver.tar.gz? 2024-05-06 16:01:27 for caches? 2024-05-06 16:10:46 Yes, filenames must be unique 2024-05-06 16:11:00 1https://distfiles.alpinelinux.org/distfiles/ 2024-05-06 16:11:51 Also each builder caches archives 2024-05-06 16:16:40 got it :) 2024-05-07 06:01:45 Is the x86_64 builder stuck again (both edge and 3.20)? 2024-05-07 06:22:35 seems so yes 2024-05-07 06:26:40 im somewhat confused 2024-05-07 06:27:12 By what? 2024-05-07 06:27:19 the py3-django-q2 aport uses valkey server for testing 2024-05-07 06:27:38 but on build-edge-x86_64 I see a redict server running 2024-05-07 06:27:41 no valkey 2024-05-07 06:28:06 6795 buildoze 20:37 redict-server *:6379 2024-05-07 06:30:55 Does the time match? 2024-05-07 06:31:08 I mean, the time when the redict-server was started, and when py3-django-q2 started running tests 2024-05-07 06:34:57 i dont know I rebooted it 2024-05-07 06:35:07 i suspect it is a leftover from something else 2024-05-07 06:35:19 Very likely so 2024-05-07 06:35:33 deno build on build-3-20-x86_64 is not stuck. it is just slow 2024-05-07 06:36:11 Ok, i think the last time build-3-20-x86_64 tried to build it, it eventually got stuck somewhere 2024-05-07 06:36:39 Hopefully, this time it is able to complete the build 2024-05-07 06:37:37 it is rust, so it is slow 2024-05-07 12:00:11 ncopa: clang18 looks ready !61853 I set it non-default and the only question is lld 2024-05-07 12:30:22 oh nice! what about lld? 2024-05-07 13:00:21 do we have an already-done script that splits the -doc subpackage when it's too large? 2024-05-07 13:16:04 hello, I'm trying to upgrade py3-twisted 2024-05-07 13:17:30 checks were disabled, but since we are hopping two years of releases I figured out that I could try to run them 2024-05-07 13:18:54 --wheel-dir .dist \ 2024-05-07 13:18:54 ``` 2024-05-07 13:18:54 I'm using the check method that is suggested in python apkbuild templates, which is: 2024-05-07 13:18:54 --output-fd 3 3>&1 >&2 2024-05-07 13:18:54 gpep517 build-wheel \ 2024-05-07 13:18:54 ``` 2024-05-07 13:19:40 and I have some "import file mismatch" errors 2024-05-07 13:22:50 Maybe try --pyargs 2024-05-07 13:23:02 here is the build log https://termbin.com/wwd2 2024-05-07 13:25:37 oh, I didn't paste the correct function, I did paste the build function instead of check 2024-05-07 13:25:56 python3 -m venv --clear --without-pip --system-site-packages .testenv 2024-05-07 13:25:56 .testenv/bin/python3 -m installer .dist/*.whl 2024-05-07 13:25:56 .testenv/bin/python3 -m pytest 2024-05-07 13:25:59 Oops, fcolista, there is !65294, but it's in draft waiting for perl-sys-virt 2024-05-07 13:35:35 hehe, so you said py3-twisted, i tried py3-django instead 2024-05-07 13:37:02 It would make it easier if you pushed a branch with your changes 2024-05-07 13:39:04 but don't worry, i have it working 2024-05-07 13:43:40 ncopa: lld probably needs llvm18 as default 2024-05-07 13:44:21 here's tests !61854 2024-05-07 13:51:19 yea, we should probably wait with bumping that til llvm18 is the default 2024-05-07 13:56:11 we could probably make llvm18 the default, if we could ping the dotnet to a specific llvm version 2024-05-07 13:56:20 pin* 2024-05-07 13:58:31 cely, I didn't push anything because it's not working yet, and the file is a mess after I started editing it 2024-05-07 13:59:35 but anyway, here is the file https://termbin.com/a7o5 2024-05-07 14:00:16 I've already started the process of pushing a branch with my changes so you can have a look at it 2024-05-07 14:00:47 https://gitlab.alpinelinux.org/Celeste/aports/-/commits/upgrade-py3-twisted 2024-05-07 14:01:13 I'll leave it up to you to find out if test_main.py still needs to be rm'ed 2024-05-07 14:01:23 (in prepare()) 2024-05-07 14:01:57 The main solution was what i first said, add `--pyargs` 2024-05-07 14:01:58 also there is a bunch of patchs that I need to check if they are still useful 2024-05-07 14:06:50 anyway thanks cely 2024-05-07 14:10:54 You're welcome 2024-05-07 14:17:05 ncopa: lld is green and I just polished a bit it, why dotnet needs llvm17? 2024-05-07 15:14:01 Is build-3-20-x86_64 still building deno? I wonder if it taking so long has something to do with Rust 1.78 (build-3-20-aarch64 built deno with 1.77) 2024-05-07 15:15:19 still building deno 2024-05-07 15:15:25 I see a lot of zombie processes 2024-05-07 15:15:51 ACTION sighs 2024-05-07 15:15:51 many of these kinds of logs in the buildlog: 2024-05-07 15:15:53 test lsp::lsp_completions_complete_function_calls has been running for over 60 seconds 2024-05-07 15:16:06 (zombie processes are all deno) 2024-05-07 15:16:52 the test_server process seems to be waiting for something 2024-05-07 15:19:55 oh, funny, killing the test server let everything continue 2024-05-07 15:20:09 At least, I think 2024-05-07 15:20:33 oh no, it did fail 2024-05-07 15:24:31 :( 2024-05-07 15:37:39 i think we now only have community/gpick that does not build with boost1.84 (in main+ community). Maybe we can delete both boost1.82 and gpick? 2024-05-07 15:37:59 Newbyte: PabloCorreaGomez[m] seems to be some gnome related CVEs regarding gdbus https://www.openwall.com/lists/oss-security/2024/05/07/5 2024-05-07 15:38:05 to avoid have to provide security fixes for 2x boost for 2 years 2024-05-07 15:43:58 mold on rv64 gets sigterm, is the timeout for the build 1h? 2024-05-07 15:45:13 "Newbyte: Pablo Correa Gomez..." <- thanks, can't look right now but I'll do later today if I remember 2024-05-07 15:47:10 The timeout is based on the repository the CI job runs under 2024-05-07 15:47:22 I think the default is 1h 2024-05-07 15:47:44 make sense, build ends at 1h 2024-05-07 15:48:13 ha missed it 2024-05-07 15:48:17 > Timeout: 2024-05-07 15:48:18 1h (from project) 2024-05-07 15:48:19 but alpine/aports has 6h as the timeout 2024-05-07 15:48:58 thats a user submitted MR, do they have to manually increate the limit? 2024-05-07 15:51:19 Yes 2024-05-07 15:51:34 or you can rebase it, and it should run under alpine/aports with the 6h timeout 2024-05-07 15:51:52 good idea, will do 2024-05-07 15:51:59 thanks 2024-05-07 15:52:09 You're welcome 2024-05-07 16:32:09 afaik only developers can run pipelines in the upstream project 2024-05-07 16:34:01 we'll see in 20 mins if https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1377073 fails 2024-05-07 16:34:35 is the rv64 builder short on cpu power? all of the other pipelines finish quite fast 2024-05-07 16:35:00 Yes, I had encountered a similar thing on gitlab.com. When my fork's settings had pipelines disabled, they also did not run on my MRs to the parent project. But a developer of the parent project could force the pipeline to run in which case it would run in the context of the parent project 2024-05-07 17:30:50 90 mins! but it ultimately failed 2024-05-07 19:45:24 we need add stuff to the release notes for 3.20 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.20.0 2024-05-07 20:29:41 maybe noting that aws-cli has been removed due to py3.12 incompatibility issues, might be an issue for some people who need it to access EC2 instances using AWS session manager. 2024-05-07 20:29:59 or temporarily disabled until fixed by upstream, would be a better wording 2024-05-07 21:09:12 good idea, i'm adding this. 2024-05-07 21:18:04 i'm thinking to add also a note for other packages that got disabled because of py 3.12 like streamlink 2024-05-07 21:19:26 like a general python 3.12 note 2024-05-07 22:33:54 A general py3.12 note is a great idea I think. Also hacks for adding the aws-cli note :) 2024-05-07 23:18:24 hey, I am trying to create an iso with my own initramfs-init; how can I control the mkinitfs process in mkimage.sh (from aports)? 2024-05-08 02:25:56 is there a big difference between alpine:edge and alpinelinux/alpine-gitlab-ci:latest ? 2024-05-08 03:50:17 bl4ckb0ne: the latter is rebuilt weekly 2024-05-08 03:51:45 https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/Dockerfile?ref_type=heads 2024-05-08 03:52:27 https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/-/blob/master/Dockerfile?ref_type=heads 2024-05-08 09:29:38 hi, I have installed "abuild" package on my box where I build/test aports before submit the MR. The "abuild" have tar as dependency but seems the pipelines doesnt have it (tar package not the busybox one)... I was facing an weird issue and install tar as make-dependency solve it, is it fine to leave it there? 2024-05-08 09:41:02 What issues were you facing? 2024-05-08 09:45:24 https://gitlab.alpinelinux.org/fabricionaweb/aports/-/jobs/1377897#L222 2024-05-08 09:47:25 ikke: related to the gdbus CVEs, Newbyte sent !65622 and !65524 2024-05-08 09:47:41 looks like something went wrong with the second one 2024-05-08 09:47:44 No, !65624 sorry 2024-05-08 10:59:52 What should we do with codeblocks? It applies quite some patches directly from github (which is a volatile source) and the checksum has changed 2024-05-08 11:05:31 ugh 2024-05-08 11:05:47 can we see what the changes are? 2024-05-08 11:06:43 I suppose we could make a copy of the patches 2024-05-08 11:09:33 seems like there havent been any releases in 4 years. maybe we can delete it? 2024-05-08 11:27:11 what's the policy on unmaintaining packages in the testing repo - should i just unmaintain them, or drop them entirely? 2024-05-08 11:38:02 you can unmaintain then, eventually someone else is picking them up again 2024-05-08 11:38:47 I'd day just drop it 2024-05-08 11:38:51 say* 2024-05-08 11:52:24 ah, I sort the issues I said early, was not tar... seems the cmake parallel was having race conditions, I changed to single thread and it solved 2024-05-08 12:42:57 knuxify: ncopa was just asking yesterday whether gpick could be deleted (as it seems to be the only aport in main+community that can't be rebuilt with boost 1.84) 2024-05-08 12:44:25 (For context, gpick is included in !65629) 2024-05-08 12:46:44 but gpick is in community, and you were asking about testing.. 2024-05-08 12:48:43 yeah, that's kind of what prompted this cleanup mr :p 2024-05-08 13:02:32 can someone merge this for alpine's cgal package, or update it? 2024-05-08 13:02:34 https://github.com/CGAL/cgal/commit/294f5b76527aad1ba69196639d2abaab9df61b9a 2024-05-08 13:02:49 it's broken with latest boost that's now packaged 2024-05-08 13:02:56 because boost loves to gratuitously break shit 2024-05-08 13:21:34 ikke: ty 2024-05-08 13:21:59 do you know if some big changes have been merged since the image was last rebuilt? 2024-05-08 13:22:41 we got a test failure for mold on rv64 in teh ci, and the maintainer cant reproduce on alpine:edge with `--platform riscv64` 2024-05-08 13:22:50 builder is still qemu or is it real hw now? 2024-05-08 13:26:19 Real hw now 2024-05-08 13:27:10 We have 2 runners on scaleway and 2 on milkv pioneer 2024-05-08 13:28:36 nice! 2024-05-08 13:28:54 i suspect some diff between the VM and the hw 2024-05-08 13:29:02 or maybe solar flares acting up 2024-05-08 17:11:53 Hi all. I know this was asked the other day, but I’m really keen to try and help with triaging new aport requests. Things move too slowly, there’s many say there probably in a good state, but I appreciate there’s likely other priorities. How do you envisage someone like myself triaging these? Clearly something needs to change to move things along. 2024-05-08 17:14:52 I really want to help. I know I need to earn my stripes before I get anywhere. I’m happy to do so. But I’m not sure how. The process itself is woefully under-documented. Something I’d like to change once I know more. Discovering this stuff on the wiki is guesswork. 2024-05-08 17:44:13 once you figure it out, documenting it on the wiki so that folks who have not figured it out yet (e.g. me) can contribute too would be awesome. 2024-05-08 17:54:55 zcrayfish: Sure. This is more of an end result to what I’m referring to. 2024-05-08 18:35:26 tadam: what's your metric for fast/slow 2024-05-08 18:35:34 just curious. 2024-05-08 18:37:11 invoked: Those MRs which pass lint checks, yet sit there for weeks. 2024-05-08 18:41:08 for MRs you've had sit for a while, have you asked anyone to review it for you? There's only a handful of reviewers currently, so working through several hundred commits that is constantly growing is a pretty arduous task, but the times where I've had something sit for a bit I've gotten traction pretty quickly by just asking 2024-05-08 18:41:27 ok. passing the linter is one thing. more eyeballs are welcome. if the xz vuln taught us anything, though, speed isn't really the goal imo 2024-05-08 18:45:09 durrendal: I have, yes. My point though is we can do much more with CI to move things along more predictably than how they are at the moment. From what you’re saying there’s still that manual reliance on a group of people whom clearly are constrained themselves, otherwise they would have moved things along already. 2024-05-08 18:49:09 Would you mind elucidating on what you think could be done differently? Note also, I'm not part of the core team I'm just a maintainer myself, but I'm interested to know what you think 2024-05-08 18:52:06 Well. I could say for those MRs which pass CI checks to automatically go into a separate repo such as “stage” which could give reviewers greater control over the review? Plus, it could widen testing before reaching Testing? Not everyone will be monitoring Testing, so this could make sense. 2024-05-08 18:57:48 i'm not on the team either, (but was on gentoo and freebsd before). as a suggestion, how this might work better, is ask the team what help they need most, and try to pitch in on whatever that is. changing the workflow (they're in the middle of 3.20 right now) is a big ask 2024-05-08 19:00:25 I'd second invoked comment. To give context or color, I had a MR for py3-iniconfig that sat for about 2 months. On the surface that looks deathly slow. What wasn't available in that MR was that py3.12 upended everything and several thousand python packages needed to be rebuilt simultaneously, of which iniconfig underpins a lot, but is a small drop in a very large bucket. 2024-05-08 19:01:18 And for new packages, there are things that CI check 2024-05-08 19:01:33 - Can we distribute the package 2024-05-08 19:01:41 - Do we even want the package 2024-05-08 19:02:01 Well, the last one is different. 2024-05-08 19:02:22 The first one… how is that not covered from CI? 2024-05-08 19:02:51 licencing? 2024-05-08 19:03:20 licensing is complex, not something that can be exhaustively by covered by CI 2024-05-08 19:03:39 inclusion of prebuilt objects, you may end up with an apkbuild that "builds" insofar as the CI is concerned, but doesn't match the ethos of Alpine the distro 2024-05-08 19:03:57 Malicious users trying to get packages into alpine 2024-05-08 19:04:20 Ok. So licensing is a manual check. But you can still validate that through CI as best-guess. 2024-05-08 19:04:51 CI does check if the listed license is part of the spdx license list 2024-05-08 19:04:54 but that's all it can do 2024-05-08 19:05:03 All I’m advocating for here, is a more streamlined approach. 2024-05-08 19:05:14 ikke: I know. 2024-05-08 19:05:42 But anyway, a separate staging environment is not really that will help us getting MRs passed faster 2024-05-08 19:05:42 i'm most concerned about malicious crap getting in the tree 2024-05-08 19:05:52 s/that/what/ 2024-05-08 19:07:40 I’m not talking about crap being let through. 2024-05-08 19:08:19 ikke: from your perspective, what would be most beneficial? I feel like I keep decent track of my pile of packages, but if there's something else that people could do in general, or that you need volunteers for? 2024-05-08 19:10:18 tadam: nobody knew xz was crap though, in part because nobody was really looking at it closely. we got lucky 2024-05-08 19:11:31 invoked: That’s not a pathological example. 2024-05-08 19:12:18 hard to know 2024-05-08 19:12:40 but i feel reasonably sure that if we try to speed up that it's not going to be better. 2024-05-08 19:12:51 speed vs bandwidth 2024-05-08 19:13:53 I haven't personally contributed with package maintenance outside of Alpine, what's the normal wait time from MR -> testing on other distros? and if it's meaningfully different what do they have or are doing that we're not? 2024-05-08 19:14:30 those feel like meaningful things to discuss. Debian is massive, I imagine they have more volunteers and can deal with more, but I don't know if that's true 2024-05-08 19:15:01 certainly true. 2024-05-08 19:15:36 debian also gets into a lot of backporting. 2024-05-08 19:17:01 One thing to take into account is that boundless growth is not necessarily good 2024-05-08 19:19:13 What is a reviewer going to different to the basic CI checks? The license? Maybe? To check !check? Maybe? To audit the code for vulnerabilities like invoked suggests? No. It’s minimal. Therefore, the barrier to entry is already bottlenecked. Plus, new contributors like myself can’t meaningfully review new aports as we’ve not earned our proverbial stripes yet. 2024-05-08 19:23:49 i don't think we need to escalate port reviews to the level of security audits. but looking at diffs and what those changes mean rather than blindly abumping: probably. 2024-05-08 19:24:12 I’m not saying that either. 2024-05-08 19:26:26 tadam: I've been around for about 5 years now, in that time the way I've seen people move from newbie to contribution has been to maintain what they feel is important to learn how the current workflows work, and get an understanding of what a good package looks like. 2024-05-08 19:26:55 from there they typically just start, of their own volition, making suggestions on other people's MRs suggesting things to fix 2024-05-08 19:27:17 I’m could start leaving comments on existing PRs such as, “LGTM” if there’s nothing obvious to change. Is that going to help? 2024-05-08 19:27:48 Not necessarily, what is going to help is commenting on things that need to be improved 2024-05-08 19:27:49 there's an actual approve button which helps with that, you just need to ask for it to be enabled. 2024-05-08 19:28:11 For us, approve is only usefull for maintainers to approve changes to their packages 2024-05-08 19:28:15 the rest just adds noise 2024-05-08 19:28:26 yes, that's the most helpful. If someone makes a mistake (bad license, incorrect var use, anything really) then it saves the folks with merge capabilities from having to do that bit 2024-05-08 19:28:32 durrendal: Well, that’s all arbitrary superficial. 2024-05-08 19:29:23 So now, durrendal’s advice contradicts yours, ikke? 2024-05-08 19:29:26 Hmm 2024-05-08 19:29:41 Well. Best of luck. 2024-05-08 19:29:49 tadam: what durrendal says is true, there is an approve button 2024-05-08 19:30:12 But having all kinds of MRs getting approved distracts from the MRs where it actually counts 2024-05-08 19:31:13 ikke is an official maintainer. Please consider his opinion above mine. I've just been here for a while, and have been in your shoes as someone who sincerely wants to help, but didn't know what to do 2024-05-08 19:33:04 my opinion, for whatever it is worth, is that the only thing that needs speed is security fixes. everything else isn't (or shouldn't be) time bound 2024-05-08 19:33:58 ikke: Can you quantify that? 2024-05-08 19:33:59 And something that also needs to happen, but is not a fun job, is to go through the long tail of open MRs 2024-05-08 19:34:20 There are 220 draft MRs 2024-05-08 19:34:49 ikke: So the people that can do that are checking for what? This is a circular argument for me. 2024-05-08 20:33:05 just as I go through https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?draft=no&page=19&scope=all&state=opened I think the problem is that an MR is opened (for a new aport, some change, etc.), comments are left, and then they stop progressing 2024-05-08 20:33:38 either the author doesn't reply and nothing moves forward, the reviewer doesn't come back to it, or something else 2024-05-08 20:34:11 There is one author that refuses to adhere to the aports codestyle and keeps doing their own thing 2024-05-08 20:34:48 yeah I saw that 2024-05-08 20:35:33 huh I didn't realize just how many MRs are opened every day, 15 pages in that search are MRs with updates in the last month 2024-05-08 20:36:30 ikke: is it like a tabs vs spaces thing? I know when I started I couldn't keep it straight until I adjusted my emacs config to force it to adhere 2024-05-08 20:36:46 for more complicated or, maybe "important" MRs, I think there's an overall difficulty in making a decision (I'm thinking the Grub problems) 2024-05-08 20:37:10 durrendal: I believe it's this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29138 2024-05-08 20:37:10 Not tabs vs spaces, but other things 2024-05-08 20:48:21 Hmm yeah theres a few strange things in that MR. 2024-05-08 20:49:03 If the contributor doesn't reply for 2 years and adjust it though, should it auto close? If you're not willing to correct the problem it can't actually be merged 2024-05-08 20:54:16 fluix: it's either that, or the MR is large/non-trivial in scope and none of the developers want to review it immediately, so it falls into obscurity 2024-05-08 20:55:10 as for the contributor who disabled lint rules so their MRs report lint as successful, there was multiple attempts at reasoning with them 2024-05-08 20:55:22 none worked 2024-05-08 20:56:00 I would say, quite confortably, you could probably auto-close now, those MRs which haven't seen an update from feedback in the last six months -- if the original contributor cared, they'd reopen it. That would certainly help reduce the set of things to review. 2024-05-08 20:56:38 Why the hell would someone argue against linting rules? Christ, that's a no-brainer. 2024-05-08 20:57:47 consistency in such a huge codebase is so important and under-estimated 2024-05-08 21:00:04 But you don't even need to fight against linting rules -- fix them, and move on. If there's a case for changing those rules, however, that's different, but I'd still argue that's always going to be the exception rather than the rule. 2024-05-08 21:00:25 for more context, you can go check out https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/39752 or some of the resolved threads on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/30450 2024-05-08 21:00:55 ACTION nods 2024-05-08 21:01:50 yeah closing some MRs is probably worthwhile, but again someone has to go through them and do so :) 2024-05-08 21:02:05 I shall, thanks. 2024-05-08 21:06:36 if i red correctly, he did write the draft for the codingstyle but then he doesn't want to stick to it?? Weird 2024-05-08 21:09:46 fossdd: the draft is actually quite different than the codingstyle that went into effect 2024-05-08 21:10:03 ahh, okay 2024-05-08 21:10:38 afaict the current one was modeled after a style that most APKBUILDs were already using 2024-05-08 21:47:23 Ah those MRs are a bit frustrating. Certainly the exception though. 2024-05-08 21:48:39 If someone doesn't conform to the project guidelines though, and willful refuses it makes sense to close their MRs, but that may not be practical if the package is needed. 2024-05-08 22:01:17 gcc 13.3 soon https://gcc.gnu.org/pipermail/gcc/2024-April/243860.html 2024-05-08 22:08:30 community/docker-registry hasn't had a maintainer for over three years 2024-05-08 22:59:41 ptrc: just to confirm, because the only reason for the makeclapman was to get it out of the rook build: it'll get found even though it's in testing/ ? 2024-05-08 23:00:08 they're both in testing, aren't they? 2024-05-08 23:00:14 Y 2024-05-08 23:00:27 So testing/ finds deps in testing/ ? 2024-05-08 23:00:33 testing/ gets deps from all 2024-05-08 23:00:37 community only from community and main 2024-05-08 23:00:39 main only from main 2024-05-08 23:00:40 Cool. 2024-05-08 23:01:45 Are you the only reviewer for testing/ or just unlucky to get stuck reviewing all of my submissions? 2024-05-08 23:06:59 there's around 10+ reviewers, but i might be one of the only ones that have enough time lately to review stuff 2024-05-08 23:07:50 Well, thanks for that. 2024-05-09 04:34:13 Is build-3-20-x86_64 stuck on grass-gis? 2024-05-09 05:07:55 seems to be 2024-05-09 06:29:27 im working on zlib-ng and rvv 2024-05-09 09:42:18 Has anyone tried running `/usr/lib/llvm18/bin/llvm-config --link-shared --libs`? 2024-05-09 09:42:57 I'm getting "llvm-config: error: libLLVM-18.so is missing", even with llvm18-libs installed 2024-05-09 09:44:56 and it seems llvm18-libs only contains symlinks now, and they are wrong 2024-05-09 10:11:51 yes, i've got the same error 2024-05-09 10:28:23 and llvm18-dev is installed as well? 2024-05-09 10:31:32 Yes 2024-05-09 10:32:10 llvm 18 changed the library name pattern, whoever did the update probably failed to account for it 2024-05-09 10:33:02 https://github.com/chimera-linux/cports/commit/6457f74b7c7c2b6d31fe4ccdd25652ffc3bbf985#diff-79659071b385ed4c6fd871ddc808a6120c7f1db5dddbe9a20c34249a5d12819cL571 2024-05-09 10:34:21 lrwxrwxrwx 1 root root 15 Apr 20 19:49 /usr/lib/libLLVM-18.so -> libLLVM.so.18.1 2024-05-09 10:34:22 lrwxrwxrwx 1 root root 15 Apr 20 19:49 /usr/lib/libLLVM.so -> libLLVM.so.18.1 2024-05-09 10:34:23 -rwxr-xr-x 1 root root 142305688 Apr 20 07:55 /usr/lib/libLLVM.so.18.1 2024-05-09 10:34:57 lol 2024-05-09 10:39:06 So, it's Apr 20 that triggers algitbot 2024-05-09 10:39:19 yes 2024-05-09 10:39:28 The bot is not very sophisticated 2024-05-09 10:51:11 ha 2024-05-09 10:51:46 algitbot: can you please behave 2024-05-09 11:07:39 how about Apr 4711 2024-05-09 11:09:39 Aissue 123 2024-05-09 11:09:55 Tissue 404 2024-05-09 11:10:04 Hmm 2024-05-09 11:12:01 dansguardian 2024-05-09 11:12:04 that takes me back 2024-05-09 11:13:53 we do still have it in the repo, in main/ 2024-05-09 11:15:34 Oh no, did i just give omni something to move elsewhere 2024-05-09 11:15:49 lol 2024-05-09 11:17:32 ACTION blames the bot, why couldn't you ignore 123 just like 404 2024-05-09 12:06:50 could someone review !65382 and !65382? 2024-05-09 12:06:59 o 2024-05-09 12:07:07 !65608 2024-05-09 12:36:17 does it need to change the pkgrel (to rebuild) because of the maintainership? 2024-05-09 12:38:22 yes, so that pkgs.a.o is updated 2024-05-09 12:40:41 The maintainer is included in the index 2024-05-09 12:42:27 would make more sense that maintainer is a variable 2024-05-09 13:15:02 thanks! 2024-05-09 13:46:25 ptrc: Thank you. 2024-05-09 14:05:06 bl4ckb0ne: It seems 1 libei test is timing out on riscv64 https://build.alpinelinux.org/buildlogs/build-3-20-riscv64/community/libei/libei-1.2.1-r0.log 2024-05-09 14:05:43 libei sounds like libegg in dutch :D 2024-05-09 14:05:58 I have increased the timeout multiplier for riscv64 in 0cc922d58099 2024-05-09 14:06:04 but that didn't seem to do the trick 2024-05-09 14:06:43 So, probably time for you to look into it, maybe that test needs to be disabled for riscv64 2024-05-09 14:08:42 I think there was some discussion about disabling specific meson tests in this channel last month, but if you want quick examples of other aports that do that, i think you can look at community/nautilus and community/libqmi 2024-05-09 15:26:18 cely: thats annoying, ill try to reproduce locally 2024-05-09 16:40:05 It appears deno is hanging again 2024-05-09 16:40:26 on 3-20-x86_64 2024-05-09 20:29:55 I wonder if some in linux-firmware-other shouldn't bee moved to their own sub-packages 2024-05-09 20:30:22 like the iwlwifi ucodes 2024-05-09 20:30:50 or at least that 2024-05-09 20:30:53 perhaps only that 2024-05-10 07:20:14 morning 2024-05-10 07:20:22 im working on libei. i think i found the issue 2024-05-10 07:20:25 https://bugs.gentoo.org/916777 2024-05-10 09:38:30 rnp and virt-manager are current blockers 2024-05-10 14:30:00 omni: regarding !65162 would it be possible to automatically bump it when ever a new version of the linux-edge is available? Or do I do this myself locally with some scripts? What is the best solution in your opinion? 2024-05-10 14:31:12 EvTheFuture: ncopa has a script he uses for the lts kernel 2024-05-10 14:31:40 mps is familiar with that process as well 2024-05-10 14:53:42 EvTheFuture: Have you tested if zfs module works with linux-edge? 2024-05-10 14:54:19 IIRC there was some config option linux-edge enabled that dramatically reduces the size of kernel, but makes it impossible to use 3rd party modules 2024-05-10 16:28:46 could someone look at !65539? would be great to have this merged before Alpine 3.20 2024-05-10 16:32:12 done 2024-05-10 16:33:19 ncopa: opa: I boot my laptop on linux-edge and I boot it using zfsbootmenu. Everything except the EFI is on ZFS so yes it works. 2024-05-10 16:42:33 "done" <- thank you! 2024-05-10 18:16:52 +1 for splitting out iwlwifi-ucode 2024-05-10 18:50:24 Can I interest anyone in !65710? It's a boring 2 lines diff upgrade :) 2024-05-10 20:00:12 test 2024-05-10 20:00:16 huh 2024-05-10 20:00:43 my matrix client doesn't receive new messages since yesterday :/ 2024-05-10 21:25:28 here, https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in?ref_type=heads#L445, maybe 2024-05-10 21:25:34 "# read the kernel options. we need to set values like:" 2024-05-10 23:24:56 wtf 2024-05-10 23:25:06 my dropbear is not starting because it has #!/sbin/runscript in the service file 2024-05-10 23:25:14 and there is no such command 2024-05-10 23:25:19 what happened to cause that?? 2024-05-10 23:27:16 ahhh 2024-05-10 23:27:23 it's old and wasn't updated because i edited it 2024-05-10 23:27:24 n/m 2024-05-10 23:43:06 good old openrc 2024-05-11 00:18:17 :) 2024-05-11 06:05:46 restarting gitlab for security upgrades 2024-05-11 06:07:31 ikke: how long does it usually take? 2024-05-11 06:08:18 <5 minutes 2024-05-11 06:08:25 It should be back in a bit 2024-05-11 06:09:02 It's back 2024-05-11 06:11:40 thanks! 2024-05-11 07:05:32 timlegge: i'm doing a test rebuild of perl-* aports with *.so files in preparation for Perl 5.40, and testing/perl-net-amqp-rabbitmq (maintained by you) is failing tests 2024-05-11 07:06:00 (i think it may be due to some changes in newer versions of OpenSSL) 2024-05-11 07:06:22 It would be nice if someone could look into merging !63893 before Alpine 3.20 as otherwise we will just have a broken ssh agent in GNOME 2024-05-11 07:57:28 Newbyte: merged 2024-05-11 07:57:58 thanks again :) 2024-05-11 08:00:00 oof, phosh fails to build 2024-05-11 08:00:13 so:libjxl.so.0.9 (no such package): 2024-05-11 08:01:08 That's odd, the dependencies of Phosh didn't change 2024-05-11 08:01:13 required by: webkit2gtk-6.0-2.44.1-r0 2024-05-11 08:01:20 Unrelated to phosh 2024-05-11 08:02:00 I guess that means webkit2gtk just needs to be rebuilt? 2024-05-11 08:02:32 so:libjxl.so.0.9 2024-05-11 08:02:47 libjxl-0.9.1-r0 provides: 2024-05-11 08:02:49 so:libjxl.so.0.9=0.9.1 2024-05-11 08:03:25 ah, sorry 2024-05-11 08:03:30 needed to an apk upgrade 2024-05-11 08:03:37 libjxl-0.10.2-r0 provides: 2024-05-11 08:03:39 so:libjxl.so.0.10=0.10.2 2024-05-11 08:03:41 so yes 2024-05-11 08:04:05 Okay, should I handle that or will you do it? 2024-05-11 08:04:18 I can do it 2024-05-11 08:04:22 Sure, thanks 2024-05-11 08:04:45 Seems like the 6.0 version was forgotten in !63811 2024-05-11 09:00:48 Cely I will look today 2024-05-11 10:50:32 Cely: that package was requested under #13147 I don't really use it but... The tests are failing because of an authentication issue against a hosted rabbitmq - the credentials changed and will not work again 2024-05-11 10:51:10 The options are - disable the tests or remove the package - I can send a PR for either 2024-05-11 13:11:58 timlegge: i think disabling the tests should be alright, and not require a pkgrel bump 2024-05-11 16:02:57 fossdd: is there any difference between GPLv3 and GPL-3.0-only? 2024-05-11 16:09:47 the former is not a valid spdx license 2024-05-11 16:10:15 It's either GPL-3.0-only or GPL-3.0-or-later. GLPv3 is ill specified 2024-05-11 16:46:59 qaqland: https://spdx.org/licenses/ for a list of valid license identifiers 2024-05-11 17:02:50 However, i think what qaqland is asking about is how to determine what to use 2024-05-11 17:03:27 https://github.com/dnote/dnote/blob/master/pkg/cli/main.go 2024-05-11 17:04:08 It contains "or (at your option) any later version" 2024-05-11 17:04:29 So, it should actually be GPL-3.0-or-later 2024-05-12 02:25:33 thx :) 2024-05-12 02:27:09 You're welcome 2024-05-12 02:29:22 https://spdx.org/licenses/GPL-3.0-or-later.html and https://spdx.org/licenses/GPL-3.0-only.html also show you the difference between them 2024-05-12 02:29:44 but you have to scroll all the way to the bottom to the "Standard License Header" section 2024-05-12 05:58:48 And that's also the only place you can tell the difference, in the source files 2024-05-12 07:20:17 Can someone please review !63332. I've been running it on my device for a couple of weeks now and it works well. 2024-05-12 09:04:29 ikke, celeste: Thanks! 2024-05-12 09:04:40 You're welcome 2024-05-12 10:31:02 the aarch64 pipeline seems to be ☠️ 2024-05-12 10:31:54 How so? 2024-05-12 10:35:31 It's busyb building electron 2024-05-12 10:35:41 https://gitlab.alpinelinux.org/selfisekai/aports/-/jobs/1382131 2024-05-12 10:45:33 ah ok 2024-05-12 10:56:23 I have one stale mr, the maintainer didnt show up, if someone could take a look !63762 2024-05-12 11:38:36 Looking for opinions about aport name, as I see other distros using uv instead of py3-uv - which one is better !65643 2024-05-12 11:39:30 andypost: i'd say uv, there was a discussion about yq-go that i remember 2024-05-12 11:39:48 where @jirutka argued that the py3- prefix is for libraries, not programs 2024-05-12 11:40:24 so py3-uv could be subpackage as actually the binary will be used 2024-05-12 11:41:30 and looks provides=CMD also not for that 2024-05-12 12:52:04 I wonder if it was this change cd19e6674fe3c44ce1c3476269150d3558b2bfd5 that had xen pci-passthrough stop working when booting linux dom0 with lockdown=confidentiality (or integrity) in cmdline 2024-05-12 12:57:55 did the lockdown knob previously not do anything? 2024-05-12 13:15:41 hmm... I also have apparmor configured from some previous experiment, could be there I need to adjust something 2024-05-12 13:43:28 damn go, Im having some tests failing because the logger prints the "namespace" (not sure if is called that) and the test just expect the filename 2024-05-12 13:43:55 expected: " INF oxy_test.go:21 > foo\n" 2024-05-12 13:43:55 actual : " INF github.com/traefik/traefik/v3/pkg/logs/oxy_test.go:21 > foo\n" 2024-05-12 16:23:05 I just skip and let commented there saying reason and that Im not able to fix it 2024-05-12 16:23:41 managed to build traefik for all platforms, but needed to skip one test that fails due max int 2024-05-12 21:27:58 Thinking about working on LXQt 2.x after 3.20 is released... Can an aport in community have a build dependency on an aport which is in testing? 2024-05-12 21:32:48 no 2024-05-12 21:36:30 bummer. LXQt forked libdbusmenu-qt (their version is called libdbusmenu-lxqt) and it isn't backwards compatible either. 🤔 2024-05-12 21:36:50 zcrayfish: - I'm facing a similar issue. kamailio is in main, but really, really could benefit from some dependencies in community. 2024-05-12 22:12:29 does kamailio have to be in main/? 2024-05-12 22:19:40 omni: we have a ML thread about this 2024-05-12 22:24:53 ok, never mind then, if it's already been raised 2024-05-12 22:26:06 I haven't been much a of a mailing list person, or emailing in general, the past 15 years 2024-05-12 22:27:04 and I don't mind kamailio being in main/ if people want/need that 2024-05-13 08:23:27 ikke: When I fail to unlock GPG (which I used for SSH authentication) git falls back to password login. You might want to disable SSH password login for Alpine's git server, though. 2024-05-13 10:02:11 Hi, I want to report a security issue in a package (3.19.1). How to report it? 2024-05-13 10:17:39 step 1: wait longer than 2 minutes before leaving afte asking a question 2024-05-13 10:19:58 :) 2024-05-13 12:18:00 seems like dotnet is broken on 3.20 2024-05-13 12:18:46 who can take care of that? 2024-05-13 12:38:50 I cant help on dotnet itself, but for the jellyfin package that is broked I made the bump mr 2024-05-13 12:40:54 ah 2024-05-13 12:41:04 good 2024-05-13 12:41:06 phew 2024-05-13 12:44:41 fabricionaweb: thank you! 2024-05-13 12:45:04 you welcome 2024-05-13 13:04:24 Are the ARM builders for 3.20 down? 2024-05-13 13:07:57 Looking at the log from #alpine-infra, i guess the answer is yes 2024-05-13 13:14:38 Indeed 2024-05-13 13:15:23 fabricionaweb: The usual convention is to place Contributor lines above Maintainer, so the Maintainer is visible in diff's default 3 line context during a pkgrel bump 2024-05-13 13:15:58 ooohhh my bad 2024-05-13 13:20:01 I merged it so my bad. and i didnt pay attention to that :) 2024-05-13 13:22:20 i would like to get the 3.20 builders complete this week, and have 3.20 rc1 out this week 2024-05-13 13:22:38 and do 3.20 release next week 2024-05-13 13:22:54 do 3.19 community aports go out of security support the moment you release 3.20? 2024-05-13 13:23:00 yes 2024-05-13 13:23:18 that's a freedom, i love it :D 2024-05-13 13:23:41 we can do sec fixes in community on request 2024-05-13 13:23:46 Habbie: Maybe you'd be interested in the MR to bring back h2o 2024-05-13 13:23:49 sure, i've gone further back on occasion 2024-05-13 13:23:53 cely, hmM/ 2024-05-13 13:23:55 oops 2024-05-13 13:23:57 hmm? 2024-05-13 13:24:19 !65782 2024-05-13 13:24:52 that looks like a bad idea 2024-05-13 13:24:59 I remember that you worked on that because it was a dependency of dnsdist 2024-05-13 13:25:02 yes 2024-05-13 13:25:25 i also MRed its removal 2024-05-13 13:25:38 this is unmaintained software 2024-05-13 13:25:54 Yeah, probably not a good idea to bring it back, especially with the Maintainer line still empty 2024-05-13 13:26:12 indeed :) 2024-05-13 13:26:25 but even with, that maintainer would have to somehow maintain security of this old h2o version 2024-05-13 13:28:00 want me to comment on the MR? 2024-05-13 13:28:39 If you don't mind, sure 2024-05-13 13:28:46 ok, will do in a bit 2024-05-13 13:59:38 Both build-3-20-x86_64 and build-3-20-riscv64 are building aports that use Rust.. 2024-05-13 14:07:40 Just tried Deno in CI, and it passes on aarch64 (so the issues it's running into on x86_64 is probably not due to the new Rust) 2024-05-13 15:44:36 any chance someone could take a look at !65438 it's ready to go, and is just a minor tweak of the existing salt package to build against their LTS version. 2024-05-13 15:55:44 im currently prioritizing everything that helps us get the 3.20 release out 2024-05-13 15:59:16 libopenraw fails to build 2024-05-13 16:13:36 If a package needs libexecinfo.h, is there anything that can be done beyond patching the package? 2024-05-13 16:17:41 ncopa: no worries, makes total sense :) 2024-05-13 16:46:18 ncopa: !65849, i think it's due to some change in Rust 1.78 (just a theory because it didn't seem to be a problem with Rust 1.77, and i can reproduce the problem with old Rust by adding --respect-source-config, so i guess it's due to that being the default now) 2024-05-13 16:47:07 Very hacky solution, but that's what i could manage for now 2024-05-13 16:51:31 I'll let you merge it in case someone else comes up with a better solution in the meantime 2024-05-13 16:59:25 Ah...i've just realized why Deno kept passing on aarch64 but not on x86_64 2024-05-13 16:59:43 it's because aarch64 doesn't run tests 2024-05-13 17:11:19 thanks for the jellyfin contrib fabricionaweb and fossdd 2024-05-13 17:12:35 Is Alpine 3.20 still tomorrow? 2024-05-13 17:12:57 s/still/releasing/ 2024-05-13 17:13:02 you welcome! 2024-05-13 17:24:16 no problem. ;) 2024-05-13 17:29:47 Newbyte: Yes, waiting for the last builders to finish 2024-05-13 17:30:18 ikkeall right, thanks :) 2024-05-13 17:31:28 great! 2024-05-13 17:33:24 is anybody using the alpine-gitlab-ci to build aports locally? 2024-05-13 17:35:49 I had done it last year when the ARM CI was down for three weeks 2024-05-13 17:37:27 im looking for a way to build aports from another distrib and i cant figured the permissions on the podman volume 2024-05-13 17:40:14 Ah, well I was doing it with rootful docker so I didn't have any problems with that 2024-05-13 18:22:51 Newbyte: i dont think the builders will be ready til tomorrow 2024-05-13 18:23:03 we should also do release candidates 2024-05-13 18:24:19 really what I'm wondering is if I can sneak in the GNOME Clocks 46 upgrade before it branches 2024-05-13 18:24:25 it was missed somehow 2024-05-13 18:26:47 I wanna bump up LXQt after the release. should be a fun project. \o/ 2024-05-13 18:39:56 $ rg "sed -" | wc -l 2024-05-13 18:40:05 1171 2024-05-13 18:41:00 I prefer patches but I guess they too can bite you in the ass 2024-05-13 18:47:56 on void we have a sed wrapper that checksums the files before/after and errors if it doesn't change, which is a minor improvement but patches are still better (less side-effects, more defined) 2024-05-13 18:49:08 cool 2024-05-13 18:49:32 Newbyte: rg 'pkgver=45\.' 2024-05-13 18:50:27 oh, baobab too 2024-05-13 18:50:30 thanks 2024-05-13 18:51:34 and a few others, no? 2024-05-13 18:52:50 or are they covered in other MRs? 2024-05-13 18:53:24 omni yes, sushi too. gnome-software and gnome-remote-desktop are too much effort to get done for Alpine 3.20, eog is not actively maintained, the rest aren't really that important I don't think 2024-05-13 18:54:13 or not my responsibility 2024-05-13 19:06:52 Created !65858. Let's hope they build on other arches than x86_64 too. 2024-05-13 19:13:10 and they did, great 2024-05-13 19:18:19 we are moving forward 2024-05-13 19:18:47 please be careful with what you push to git master now 2024-05-13 19:19:05 avoid pushing huge time consuming builds if possible 2024-05-13 19:19:20 like 3 x webkit rebuilds 2024-05-13 19:19:48 ask yourself if it can wait a couple of weeks, til after 3.20 release 2024-05-13 19:30:02 how do I update cabal.config? https://build.alpinelinux.org/buildlogs/build-3-20-x86_64/community/hledger-stockquotes/hledger-stockquotes-0.1.2.2-r2.log 2024-05-13 19:33:49 omni are you still working on !64439? A new version of gdcm is available, I could include your changes in that MR 2024-05-13 19:48:41 I wonder if we could fix the setup-desktop script to setup wayland instead of x11? 2024-05-13 19:49:04 Can it be a choice? 2024-05-13 19:49:22 at least, an option to still install x11 if desired? 2024-05-13 19:50:15 i was thinking for the desktop environments that supports wayland at least 2024-05-13 19:50:47 maybe we can do something like: setup-desktop --x11 or something 2024-05-13 19:50:58 but I have no idea how to set up wayland 2024-05-13 19:51:19 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-desktop.in?ref_type=heads 2024-05-13 19:52:49 here is a WM with wayland: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/188 2024-05-13 19:52:58 many things are taken from setup-xorg-base 2024-05-13 19:54:29 AFAIK wayland is much easier to setup than xorg, and only requires the WM/DE without any external server 2024-05-13 19:55:16 ah! wonderful! 2024-05-13 20:18:40 question re encrypted disk. https://gitlab.alpinelinux.org/alpine/alpine-conf/-/issues/10575 2024-05-13 20:19:14 we should either automatically enable LVM when disc encryption is selected, or we should disable swap by default 2024-05-13 20:19:20 which do we prefer? 2024-05-13 20:49:47 I think swap is silly, but I'm a (neo)vim user 2024-05-13 20:52:17 I'd say disable swap, it's easy enough to setup zram post install or add a swapfile later. It's less easy to convert and LVM partition into non-LVM down the road 2024-05-13 20:58:09 🖢 2024-05-13 21:02:36 if I don't get swap when I boot my Alpine machine, I can't build a gcc or a kernel on it 2024-05-13 21:02:59 I would see it as a regression 2024-05-13 21:13:13 you can still have swap if you want to? 2024-05-13 21:18:29 ... and people can enable LVM if we want to? 2024-05-13 21:18:33 we're talking about defaults 2024-05-13 21:19:06 if they* want to 2024-05-13 21:21:23 ok, I never do anything default when it comes to alpine and setup-disk so perhaps I should stay out of this 2024-05-13 21:27:16 I only have swap because I think zfs maybe wants it for something, I had an issue with zfs on a FreeBSD fileserver without swap some 12 years ago and adding swap mitigated that, so I have some symbolic swap via zram-init 2024-05-13 21:29:26 Im failing miserably to add a secfix comment to my package LOL 2024-05-13 21:30:43 ah it was the colun 2024-05-13 21:31:07 colon 2024-05-13 21:31:17 ACTION goes home 2024-05-13 21:47:09 ncopa: tomorrow is Firefox release day, do you think we still have time to get latest versions into 3.20? should take at most 40min per package to build 2024-05-13 21:47:26 they usually cut the release in the afternoon 2024-05-13 22:45:46 what was that about release candidates? 2024-05-14 02:35:48 So, Anitya finally caught up, and dumped a few days' worth of outdated packages onto pkgs.a.o/flagged 2024-05-14 02:36:40 ACTION doesn't want to be distracted, so closes that page 2024-05-14 06:48:16 ptrc: would be good to include it. It is enabled on riscv64? Maybe have a look at build.alpinelinux.org and if/when it clear that it will finish before Friday morning you can just go ahead and push Firefox 2024-05-14 06:49:12 I see we have MR with chromium as well, but I don’t think we have chromium for riscv64 2024-05-14 06:59:27 If build-3-20-riscv64 has less than 300 packages to build by the end of the day you can just go ahead and push Firefox. Otherwise maybe wait til after rc1 is out 2024-05-14 07:57:25 build-3-20-aarch64 has been unblocked, and is now uploading community 2024-05-14 07:57:55 my contrib to traefik will be out of the party this time 🤣 2024-05-14 07:58:20 for aports, will 3.20 branch off from master today-ish? 2024-05-14 07:59:30 No, riscv64 still has about 500 aports left to build 2024-05-14 08:01:21 So, the big blocker left for x86_64 is probably Deno, which i suspect succeeded on aarch64 because it has !check there 2024-05-14 08:02:58 ah, let me rephrase 2024-05-14 08:03:03 the core of my question was not the date, but the action 2024-05-14 08:03:17 because i didn't spot a 3.20 branch yet 2024-05-14 08:03:28 and i know other distros (like openwrt) create that branch months before release 2024-05-14 08:03:30 and then backport a lot 2024-05-14 08:03:43 I think we only branch at the moment the release is created 2024-05-14 08:03:46 ok, neat 2024-05-14 08:03:48 very clean again 2024-05-14 08:04:33 but this also allows that issues in last-minute-commits are also available in the release 2024-05-14 08:04:41 Yes 2024-05-14 08:05:23 For Alpine 3.19, main/ada was upgraded very close to the release, but nodejs was not rebuilt against it (nodejs-current, however, was) 2024-05-14 08:06:02 So, i think, the very night before 3.19 was released, some issues with aports using nodejs started coming up, but it was solved by using nodejs-current instead 2024-05-14 08:06:17 and we only found out what was wrong and fixed nodejs after 3.19 was released 2024-05-14 08:10:52 right :) 2024-05-14 08:10:58 and -that- you had to backport 2024-05-14 08:14:46 We branch only at release because then it becomes in everyone’s interest to get the release out 2024-05-14 08:14:56 makes sense 2024-05-14 08:15:24 What is needed to move an aport from testing to community? is this a good time or better wait since we are already cooking 2024-05-14 08:15:57 actually forget, if it uses pnpm its on edge it wont be possible 2024-05-14 08:23:35 Im looking to npm aport to and I saw this `depends="cmd:node"` how is it different from `depends="nodejs"`? 🤔 2024-05-14 08:24:06 depends a bit. if it is a small/trivial package, just go ahead with an MR to move it 2024-05-14 08:24:23 if its good reasons to include it in 3.20, then go ahead 2024-05-14 08:24:54 if it will require time to review, fix, and etc and it can wait a couple of weeks, then maybe wait 2024-05-14 08:25:47 it would be for autobrr, its just go package I maintain, but it is currently using pnpm on makedepedns, not sure iof this affect 2024-05-14 08:25:53 go app* 2024-05-14 08:26:11 well so many typos there, sorry 🤣 2024-05-14 08:29:06 yeah :D i have no idea what you talk about :D 2024-05-14 08:29:19 lol 2024-05-14 08:37:46 no, as pnpm is in only in testing. you'd first have to move pnpm to community. 2024-05-14 08:54:42 hi all is planned to add support for rust in kernel packages? 2024-05-14 08:55:52 eventually yes. but not today 2024-05-14 08:59:57 That will very likely require keeping multiple versions of Rust in aports 2024-05-14 09:01:30 ugh. 2024-05-14 09:01:36 thats a no-go 2024-05-14 09:02:10 we have circular dep: docker-cli -> docker-cli-buildx 2024-05-14 09:03:09 For example, !62337 no longer builds with newer versions of Rust 2024-05-14 09:03:19 that needs to be fixed upstream 2024-05-14 09:04:04 what do we do with docker-cli-buildx? 2024-05-14 09:09:53 no, as pnpm is in only in testing. you'd first have to move pnpm to community. > thanks, I will be working on that, I see margin to improve, its missing -doc for MIT and -completions 2024-05-14 09:10:30 ncopa: i thought that was fixed by moving the depend= into docker-cli-buildx's package()? 2024-05-14 09:10:53 https://build.alpinelinux.org/buildlogs/build-3-20-riscv64/community/dockviz/dockviz-0.6.4-r14.log 2024-05-14 09:11:45 docker was built, but docker-cli-buildx was not 2024-05-14 09:12:40 i suppose we could bundle the docker-cli-buildx in docker APKBUILD 2024-05-14 09:13:40 there is no way to find out that docker-cli-buildx needs to be built before docker package is usable 2024-05-14 09:15:30 seems like I need to reolve that manually 2024-05-14 09:16:18 Can we add buildx as a makedepends to docker? 2024-05-14 09:17:06 docker-cli is a runtime dep to buildx so it becomes a circular buildtime dep 2024-05-14 09:17:23 i wonder if we could use some install_if trick 2024-05-14 09:23:51 cely, whould be that problem? i have in jfrog repos multiple versions of one package very often 2024-05-14 09:24:22 i solved it by building buildx manually. im also bootstrapping openjdk21 now 2024-05-14 09:25:06 how do we fix deno? 2024-05-14 09:25:16 indy: Rust is big, and i think it's been discussed before, and we would prefer not to maintain multiple versions of Rust 2024-05-14 09:25:50 indy: it is a resource problem. we dont have resources to maintain limitless number of rust version 2024-05-14 09:26:35 (Rust also has a very strict bootstrap requirement, a particular version of Rust can only be built with that version itself, or the version prior) 2024-05-14 09:29:40 I think for Deno, for the time being, we can let x86_64 join aarch64 (which has !check) 2024-05-14 09:30:02 :) 2024-05-14 09:30:06 I tried the latest version, and while it doesn't get stuck, tests still fail 2024-05-14 09:30:23 but thats progress 2024-05-14 09:30:35 maybe we can bump the version, and disable a few failing tests? 2024-05-14 09:30:41 and i see the same smartstring error message which is the reason checks are disabled on aarch64 2024-05-14 09:32:19 I can create an MR for the bump, but i'm probably not up for disabling tests, as Deno is Rust+v8, so doubly complex 2024-05-14 09:32:47 do you have a local commit? 2024-05-14 09:33:02 git format-patch -1 --stdout | tpaste 2024-05-14 09:34:34 im testing the current version on my local aarch64 machine now 2024-05-14 09:34:52 I have a branch: https://gitlab.alpinelinux.org/Celeste/aports/-/commits/upgrade-deno 2024-05-14 09:35:07 that works. thanks! 2024-05-14 09:35:17 but in the latest commit, i disabled x86_64 to run tests on aarch64 2024-05-14 09:35:41 and as you can see both commits are red 2024-05-14 09:35:56 ncopa, cely: i know 2024-05-14 09:42:19 The smartstring crate doesn't seem to be active upstream: https://github.com/bodil/smartstring 2024-05-14 09:42:42 So, there's no easy version bump to fix the error 2024-05-14 09:49:13 Hmm, i'm not sure if Deno follows the even number = stable branch versioning scheme 2024-05-14 09:50:45 If that's the case maybe the upgrade should be to 1.42.4 instead 2024-05-14 09:52:20 Anyway, i'm going AFK, so hopefully some of what i've done can help with the 1.42.4 upgrade 2024-05-14 10:01:30 I sent the MR for pnpm, I'd like to try move to community if it meets the criteria (the tests is like npm, not much can be done) !65878 2024-05-14 12:49:39 hello, I'm currently trying the alternate init system testing/dinit and I must say that I like it very much so far. Would it be ok if I systematically add a *-dinit subpackage for each package I'm maintainer of? 2024-05-14 12:58:24 is it worth to bump nodejs-current ? I think nodejs dont worth because it is written to not bump for odd numbers and it is the case 2024-05-14 12:59:44 I mean it is a minor version, 20.13.1, maybe worth? 2024-05-14 13:09:32 Maybe, but you must be mindful that 6 copies of it will build at the same time on the ARM builder, which could bring it down like WebkitGTK did 2024-05-14 13:12:44 ok that sounds like not a good time, I think theres no cve involved (if I checked right) no needs to rush 2024-05-14 13:12:48 fabricionaweb: are you sure you mean current? 2024-05-14 13:13:10 ( it's pending an upgrade to 22, but there's build failures and it's not too urgent ) 2024-05-14 13:13:35 yeah seems like not a easy job, let it for the pros 2024-05-14 13:14:03 raspbeguy: you'd have to fight some maintainers in alpine 2024-05-14 13:14:24 funnily enough, ones that aren't even here 2024-05-14 13:15:08 ptrc, well I don't want to change default init 2024-05-14 13:15:25 neither did !64741 2024-05-14 13:15:26 and yet 2024-05-14 13:21:18 ptrc, well, I guess I will try to propose dome dinit service files with my next package upgrade, will see what happens ¯\_(ツ)_/¯ 2024-05-14 13:25:34 you might also take a look at https://gitlab.alpinelinux.org/alpine/tsc/-/issues/78 2024-05-14 13:27:58 yep, did that already 2024-05-14 13:28:47 honestly I'm not very happy with the "slippery slope" argument, but whatever. 2024-05-14 13:41:40 Hmm, someone has flagged Perl outdated on pkgs.a.o, with the latest dev version as suggested upgrade, and mentioning CVE-2023-47100 that seems to be very similar to CVE-2023-47038 which we already have in secfixes 2024-05-14 14:33:32 raspbeguy: i would prefer you didn't add *-dinit. not yet at least 2024-05-14 14:36:24 ncopa, raspbeguy, just a thought, ignoring any timing inconveniences - debian has a orphan-sysvinit-scripts package where all the rc.d scripts go that were dropped from actual packages 2024-05-14 14:37:05 a similar dinit-scripts package may or may not make sense here? 2024-05-14 14:38:08 once we open that box we will have *-runit, *-s6, *-systemd subpackages in addition 2024-05-14 14:38:27 we will get bug reports "this does not work on -systemd, please compile with..." 2024-05-14 14:38:30 ah! i'm not suggesting subpackages, i'm suggesting *one* grand dinit-scripts package 2024-05-14 14:38:36 i also get 'no' 2024-05-14 14:38:38 ncopa, and would it be bad ? 2024-05-14 14:38:45 same way we (powerdns) go 'no' to 'please put sysv back into the .deb' 2024-05-14 14:38:52 we will have to spend time on it. I dont think we have resources currently 2024-05-14 14:39:03 Habbie: that may be a better way to do it 2024-05-14 14:39:21 which? the one package? 2024-05-14 14:39:40 raspbeguy: i think we want keep things simple. supporting multiple init systems will complicate things 2024-05-14 14:39:42 i like it because it's clear where the responsibility lies 2024-05-14 14:39:52 and we will spend lots of time discussing this 2024-05-14 14:39:53 ncopa, allright, that's fair 2024-05-14 14:40:01 the one package may work 2024-05-14 14:40:45 I think I will maintain my custom repository then 2024-05-14 14:40:56 sond slike a good idea 2024-05-14 14:40:58 at least for now 2024-05-14 14:41:06 the one package approach might also simplify your custom repo 2024-05-14 14:41:11 as it avoids patching various packages 2024-05-14 15:05:46 ncopa: swap (larger than size of ram) is needed for hibernate, yes? 2024-05-14 15:06:01 i don't use hibernate myself, but just noting... 2024-05-14 15:18:38 i would think so 2024-05-14 15:26:38 aws-c-io has a few failing tests 2024-05-14 16:25:07 does https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62514#note_400758 count as approval? (= 2024-05-14 16:32:32 oh this is very good stuff, did not it exists before? I remember I have used somethig, maybe was just a custom rc 😅 2024-05-14 16:33:35 omni: doubtful, was just an answer to a specific question 2024-05-14 16:34:02 ikke: yes, yes, I know... I'm just biased 2024-05-14 16:34:12 I get your feeling 2024-05-14 16:44:55 ncopa: !65899 i probably won't be around to CI finish, but i think (and hope) it will be green 2024-05-14 16:45:00 s/to/to see/ 2024-05-14 16:48:37 ACTION crosses fingers 2024-05-14 16:53:25 fabricionaweb: i simply setup wg quick up in /etc/network/interfaces. 2024-05-14 16:53:35 maybe this was also what you did 2024-05-14 17:00:12 ncopa: im focusing back on opencv and buildah failures for ppc64le from a couple months ago… I have 2 interns this summer that will be focused on ppc64le development for alpine linux so if there is a larger task to focus on for ppc64le please let me know :) 2024-05-14 17:00:43 buildah: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61262 opencv: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15494 2024-05-14 18:47:45 buildah is enabled again on ppc64le since 910debb0ac407f6d7994adeeb4215888739802b7 2024-05-14 18:49:11 oh sweet 2024-05-14 19:17:27 oh nice! I think some openjdk version has ppc64le disabled 2024-05-14 19:18:01 maybe they were fixed 2024-05-14 19:18:46 yup, seems so 2024-05-14 19:20:00 grep '!ppc64le' */APKBUILD shows a long list of packages 2024-05-14 19:20:03 oh ok great! so any other tasks that would be helpful to focus on for ppc64le this summer? i recommended we just look at what packages are disabled for ppc64le and work on those 2024-05-14 19:20:07 haha yup ^ 2024-05-14 19:20:39 luajit would be nice, but might be advanced 2024-05-14 19:22:41 i disabled various targets for llvm on ppc64le 2024-05-14 19:22:59 might have been to reduce number of test failures 2024-05-14 19:23:22 i dont know if ppc64le is a common platform where you do crosscompilation from 2024-05-14 19:38:04 ncopa: what about to merge !61853 before release? 2024-05-14 19:38:44 the !61854 probably can wait 2024-05-14 19:44:07 ncopa: FWIW the clang18 patch looks good to me 2024-05-14 19:45:52 andypost[m]: I think the lld patch look ok too, you might consider that too, will be good for riscv support 2024-05-14 19:50:38 thanks 2024-05-14 19:50:46 andypost[m]: thanks for the reminder. 2024-05-14 19:51:02 im merging it 2024-05-14 19:51:29 nmeum: cyclone stopped to build on riscv64. apparently it built before? 2024-05-14 19:51:48 looks like similar issue as on s390x https://github.com/concurrencykit/ck/issues/178 2024-05-14 19:54:41 i think i need to disable riscv64 for now to unblock the builders 2024-05-14 19:59:24 yes, feel free to disable it for now 2024-05-14 19:59:27 I will revisit it later 2024-05-14 20:02:32 thanks! 2024-05-14 20:02:53 also: we will need to do Go rebuilds for 3.20 (which will probably also block the riscv64 builders for a while) but I guess I can wait with that until the first RC 2024-05-14 20:08:00 hum... 2024-05-14 20:08:27 i want the 3.20 release out short after rc1 2024-05-14 20:08:44 maybe not postpone too much til after rc1 either 2024-05-14 20:09:01 are there sec issues with go? 2024-05-14 20:12:05 I think you can just push if it is a sec issue and it must be fixed before 3.20 2024-05-14 20:13:27 andypost[m]: clang18 faild on aarch64 2024-05-14 20:15:10 it's just a DOS in the dns parser (CVE-2024-24788) https://groups.google.com/g/golang-announce/c/wkkO4P9stm0 2024-05-14 20:15:33 but not super critical imho 2024-05-14 20:19:03 ncopa:can you point to fail logs for aarch64 ? 2024-05-14 20:19:46 https://build.alpinelinux.org/buildlogs/build-3-20-aarch64/main/clang18/clang18-18.1.5-r0.log 2024-05-14 20:21:19 [01m[Kg++:[m[K [01;31m[Kfatal error: [m[KKilled signal terminated program cc1plus 2024-05-14 20:21:28 seems the build machine ran out of memory 2024-05-14 20:23:35 yeah, 256G of memory is a bit on the low side 2024-05-14 20:25:16 usually thats what is the reason I have seen for g++ to terminate like it, if you can extract some system logs it might tell us more on why it ead killed 2024-05-14 20:25:32 yeah, it's what happened 2024-05-14 20:25:43 Out of memory: Killed process 56741 (cc1plus) total-vm:1443148kB, anon-rss:1129624kB, file-rss:14104kB, shmem-rss:0kB, UID:1000 pgtables:2856kB oom_score_adj:0 2024-05-14 20:25:51 :) 2024-05-14 20:26:17 dont underestimate the power of bloat 2024-05-14 20:26:20 Any push will trigger 6 builders atm 2024-05-14 20:26:44 3 x edge + 3 x 3.20 2024-05-14 20:27:48 and clang uses ninja which wants to use all the resources on system so it can really pound it 2024-05-14 20:28:14 Almost any build tool will use all cores 2024-05-14 20:28:28 > dont underestimate the power of bloat 2024-05-14 20:28:30 ha 2024-05-14 20:29:13 khem: I'm gonna steal that 2024-05-14 20:31:50 :) 2024-05-14 23:00:56 Heya! I guess u know, but just for the sure - aarch64 CI runners seems to be overloaded or NA? 2024-05-15 05:14:33 build-3-20-x86_64 has been unblocked, and is now uploading community 2024-05-15 05:15:04 So, what's left is the 300 aports to go for riscv64 2024-05-15 05:30:03 Thank you whoever fixed the CI. 2024-05-15 05:44:22 \o/ 2024-05-15 05:46:31 !62724 2024-05-15 05:46:31 I hope Jirutka doesn't mind that i backported the JDK 17.0.10 compatibility patch from upstream for openjdk-mandrel and just got it in (without going through an MR) 2024-05-15 05:47:53 ncopa: looks like it's finally ready ^^ 2024-05-15 06:09:21 indeed \o/ 2024-05-15 06:10:02 lets help the riscv64 builder to cross the finish line 2024-05-15 06:13:27 is anything up with the a* builders? 2024-05-15 06:14:07 they shouldn't be idle now 2024-05-15 06:14:38 They're down, i think it was mentioned earlier 2024-05-15 06:14:45 oh 2024-05-15 13:07:22 ooh, git vulnerabilities 2024-05-15 13:07:34 eish 2024-05-15 13:07:34 is someone already packaging 2.45.1? (https://github.blog/2024-05-14-securing-git-addressing-5-new-vulnerabilities/) 2024-05-15 13:08:30 !65930 2024-05-15 13:09:09 !65933 2024-05-15 13:09:14 aha, cheers 2024-05-15 14:06:46 reading about those git vulns yesterday wore me out. like "if you're on a case-insensitive filesystem that support symlinks..." (can we just say macos please) 2024-05-15 14:13:31 NTFS also supports symlinks 2024-05-15 14:19:19 !62514 is ready to merge :) 2024-05-15 14:22:30 it isnt just me that struggle to approve mr 😅 2024-05-15 17:03:59 x86_64 edge builder stuck on chromium? 2024-05-15 18:08:51 I'd like to learn about how Alpine configures/manages runners for gitlab.alpinelinux.org, is there a good place to start? (i.e. is it documented somewhere or the config in some public repo?) 2024-05-15 19:13:37 here are a few repos that might help you out: https://gitlab.alpinelinux.org/alpine?filter=runner 2024-05-15 19:24:03 fossdd: thank you! 2024-05-15 19:26:59 craftyguy: https://gitlab.alpinelinux.org/alpine/infra/compose/gitlab-runner-alpine-ci 2024-05-15 19:27:22 Note that this is still using the old way of registering runners, I need to update it to work with the new flow 2024-05-15 20:08:45 ikke: ohh this is helpful, thank you! 2024-05-15 20:09:43 omni: thanks 2024-05-15 20:24:14 omni: FYI. I disabled arti on riscv64. 2024-05-15 20:46:22 Did traefik pass? If it's holding us there's an open mr _trying_ to fix but if even that don't work we can disable id say, few days ago it was disabled anyways 2024-05-15 20:46:50 ptrc: i believe the riscv64 will be able to complete 3.20 builds before Friday morning. I think you can push firefox 2024-05-15 20:47:10 fabricionaweb: failed on s390x https://build.alpinelinux.org/ 2024-05-15 21:20:21 I want peoples opinion on switching back yq to yq-go: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16052#note_404924 2024-05-15 21:26:50 It seems it passed lol 2024-05-15 21:27:00 After 30 failures or so 2024-05-15 21:43:57 ptrc: thanks 2024-05-15 21:44:09 ^^ 2024-05-15 21:51:38 ^^ 2024-05-15 22:08:58 ncopa: ok, it's fine, I'll look at it later 2024-05-16 06:18:10 build-3-20-riscv64 is uploading community packages \o/ 2024-05-16 06:22:44 \o/ 2024-05-16 06:22:47 Now it's done 2024-05-16 06:24:28 x86_64, on the other hand, is now building 2 copies of Deno 2024-05-16 06:24:48 Hopefully it is able to complete that 2024-05-16 06:27:24 ny opinion on yq? https://gitlab.alpinelinux.org/alpine/aports/-/issues/16052#note_404924 2024-05-16 06:33:39 ncopa, the 3 sounds best, although I don't use either, but it makes things clearer 2024-05-16 06:35:03 The real problem being projects wanting to grab an already existing project name for themselves 2024-05-16 08:05:42 arms! \o/ 2024-05-16 08:15:43 what the SIGILL means on riscv64 pipeline? 2024-05-16 08:16:41 illegal instruction 2024-05-16 08:17:13 in this case.. probably some edge case where the hardware doesn't expect something 2024-05-16 08:17:23 fun, it was working before 😅 2024-05-16 08:21:04 we have had issues with the milk-v pioneer machines due to the implement RVV 0.7.1 instruction set, and not the official 1.0 2024-05-16 08:21:29 and then it claims to have RVV support. When software tries to use RVV, they expect 1.0 2024-05-16 08:21:42 and use 1.0 intructions, and ends with illegal intruction 2024-05-16 08:22:15 we added patch to a few packages that has runtime detection of RVV, like ffmpeg 2024-05-16 09:14:06 ncopa, you said on another MR that vaultwarden needs a new maintainer, can I pick it up? not as I know much about rust but I can help somehow 2024-05-16 09:17:08 sure 2024-05-16 09:35:25 Hi, i am working on !65744 and glibmm2.66 does not set $pkgdir correctly 2024-05-16 09:35:32 how could i fix this 2024-05-16 09:35:35 ? 2024-05-16 09:40:27 i had to add `mkdir -p "$pkgdir" || return 1 and `cd "$srcdir/builddir"'' before calling meson for this to work 2024-05-16 09:44:21 chereskata: it's expected that $pkgdir gets created by whatever is trying to install to it 2024-05-16 09:45:30 okey interesting to know. The package should'nt have worked previously but worked before i tried to rename it from glibmm 2024-05-16 09:45:46 ikke: thanks :) 2024-05-16 09:46:58 Note that usually the build system does that 2024-05-16 09:47:14 in that case it is meson 2024-05-16 09:47:23 So sounds like a problem there 2024-05-16 09:47:50 thought so. normally the package() is a oneliner for meson builds 2024-05-16 10:52:45 I would like a curl/libcurl sub-packge that supports looking up .onion 2024-05-16 10:53:16 probably needs to be built without c-ares since that too disallows .onion lookups 2024-05-16 11:35:50 chereskata: "$srcdir/$builddir" is not the usual way of doing things, builddir itself should include $srcdir 2024-05-16 11:36:21 I see my error, thank you! 2024-05-16 11:39:06 You're welcome 2024-05-16 11:46:39 omni: can't curl do `--socks5-hostname localhost:9050`? 2024-05-16 11:48:04 https://ptrc.gay/kuGYkTLD 2024-05-16 11:48:06 it can :3 2024-05-16 11:48:23 https://mastodon.social/@bagder/112449877410134861 2024-05-16 11:48:27 ACTION loved the tld 2024-05-16 13:20:49 nice feature 2024-05-16 13:24:02 Is this the correct room to ask questions about community aport package development? or should I be asking in a different room? 2024-05-16 13:24:55 here is fine 2024-05-16 13:35:45 I'm working on upgrading Nextcloud-28 to Nextcloud-29 in Edge, but I'm having trouble getting one of the patch files to be successful, even though the patch is correct. I've put it up here, https://gitlab.alpinelinux.org/jahway603/nextcloud29, to get feedback on how to fix that 1 patch file. 2024-05-16 13:41:54 ptrc: it's for when you "can't", when you're doing transparent proxying 2024-05-16 13:42:05 oh, hm 2024-05-16 13:43:31 and if that is set up by someone else you can't 2024-05-16 13:44:05 I and others have come with suggestions for solving this 2024-05-16 13:45:01 but perhaps because some have been rude, upstream is not too keen on providing a "knob" to allow .onion lookups 2024-05-16 13:45:52 so I just want to provide it to people through alpine as replacement packages 2024-05-16 13:47:00 so that you, for example, can work with git against repos hosted as onion services 2024-05-16 13:47:25 like http://eweiibe6tdjsdprb4px6rqrzzcsi22m4koia44kc5pcjr7nec2rlxyad.onion/tpo/core/arti 2024-05-16 14:00:54 a thread about it https://lists.torproject.org/pipermail/tor-dev/2023-November/014862.html 2024-05-16 14:06:27 jahway603 > rnalrd is the maintainer, cant he help you? also notice he is working on the 29 as well 😅 2024-05-16 14:07:30 It seems your patch file is just corrupted, it is missing an space as first character on every line (the one on aports repo works) 2024-05-16 14:09:07 (the one on aports repo works) -> no, forget this part, I was wrong 2024-05-16 14:16:20 fabricionaweb: I started working on it as I saw that it needed to be done & looked at it as a learning experience. How can I see that the maintainer, rnalrd, is working on it? 2024-05-16 14:16:36 that would make sense to communicate with them 2024-05-16 14:16:49 I just opened his profile there :P 2024-05-16 14:21:22 4179c05acede218b5848535596bed52f812302b2 2024-05-16 14:25:20 was this pushed without mr? 2024-05-16 14:26:25 Probably, sometimes this is done, especially when CI is busy 2024-05-16 14:27:53 or when there is little chance that it fails on other arches then you test on (though CI can still help you catch mistakes) 2024-05-16 14:33:47 I didn't realise it was there, first saw I thought it was his fork 😅 so he isnt working, he worked already 😂 sorry jahway603 to ruin the fun 😭 2024-05-16 14:50:52 lol, well it wasn't there yesterday :) 2024-05-16 14:52:33 it was pused 6h ago 2024-05-16 14:52:38 pushed* 2024-05-16 14:59:02 rnalrd: Shouldn't this be 28 and not 27? https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/nextcloud/APKBUILD?ref_type=heads#L6 2024-05-16 14:59:19 29 replaced 28, not 27 - or am I mis-reading this? 2024-05-16 15:03:33 alpine 3.19 contains nextcloud 27, so I guess that's the package being replaced 2024-05-16 15:05:04 But, the nextcloud27 package is still missing 2024-05-16 15:12:50 "npm error code ETIMEDOUT" on my pipeline, would this be related to our machines being busy? 2024-05-16 15:13:28 ikke: there's a new nextcloud28 package in edge as of today and edge had 28.x, so that's why I'm asking 2024-05-16 15:15:35 Yes, but what I mean to say is that the goal most likely is to help users upgrading from 3.19 to 3.20 2024-05-16 15:15:42 those users would never have seen 28 2024-05-16 15:18:43 and the only benefit of that is that apk will not complain about conflicting files when switching between different packages, not for upgrading 2024-05-16 15:19:03 So just upgrading the package will not need that provision 2024-05-16 15:19:15 but switching between nextcloud and nextcloud27 would 2024-05-16 15:24:56 3.20 will be a future snapshot of edge, right? Is it worth the time & effort to upgrade nextcloud to 28.x on 3.19 and create a nextcloud27 package or not? Then 3.19 users would have seen nextcloud 28 2024-05-16 15:25:36 Yes, 3.20 will be a snapshot of edge 2024-05-16 15:25:48 but no, we should not upgrade nextcloud in 3.19, users are not expecting that 2024-05-16 15:26:43 nextcloud can't be upgraded directly from 27->29, it's needs to be upgraded 27->28->29 2024-05-16 15:26:59 So we need to add a nextcloud28 package to edge 2024-05-16 15:27:14 and nextcloud28 was added today to edge 2024-05-16 15:27:56 Ok, in that case, _replaces_ver should indeed be 28 2024-05-16 15:28:07 that's what I thought, I'll submit a MR 2024-05-16 15:28:37 What about _replaces_ver in nextcloud28? 2024-05-16 15:29:15 _replaced_ver* 2024-05-16 15:29:24 cely: I suppose that one should be empty 2024-05-16 15:29:46 right now it's set to 27 https://gitlab.alpinelinux.org/jahway603/aports/-/blob/master/community/nextcloud28/APKBUILD?ref_type=heads#L7 2024-05-16 15:29:54 Maybe nextcloud28 could use "replaces=nextcloud<28" (if this is allowed)? 2024-05-16 15:30:51 It's not about the version but about the package name, to facilitate switching between nextcloud and nextcloud 2024-05-16 15:31:15 Ok 2024-05-16 15:31:39 When you upgrade from 3.19 to 3.20, you'll get nextcloud 29 2024-05-16 15:31:45 that won't work, like jahway603 said 2024-05-16 15:32:02 so you need to first install nextcloud28, migrate, and then switch back to nextcloud to get 29 2024-05-16 15:32:38 ikke: that's why I was asking about creating a nextcloud27 in 3.19 and then upgrading nextcloud pkg there to 28 2024-05-16 15:32:51 jahway603: But you don't want to break users on 3.19 2024-05-16 15:33:05 I see what you mean 2024-05-16 15:33:37 people should feel safe to upgrade their systems 2024-05-16 15:33:43 But if users just do an `apk upgrade` (without manually upgrading to nextcloud28 first) it would be broken too, right? 2024-05-16 15:34:07 cely: yes, when upgrading to alpine 3.20 2024-05-16 15:34:18 It has been like this for quite some time now 2024-05-16 15:34:30 Ok 2024-05-16 15:35:33 There is an old post-upgrade script to warn about it, but that's for 3.12 -> 3.13 2024-05-16 18:36:28 Just jumping in quickly to say: builders are now idle..time to tag rc1? 2024-05-16 19:48:47 oh my 2024-05-16 19:48:52 everything is idle? 2024-05-16 19:49:35 The servers are desparate, they have not clue what to do with their lives now 2024-05-16 19:49:45 lol 2024-05-16 19:50:26 i have been out most of the time today due to an emergency 2024-05-16 19:51:02 ncopa: Oh, sad to hear, I hope nothing too severe? 2024-05-16 19:51:44 well sort of, but I'm ok. I just very tired now 2024-05-16 19:51:57 Do we need to donate blood and/or kidneys? :p 2024-05-16 19:52:20 well, its too late now 2024-05-16 19:53:10 :( 2024-05-16 19:54:11 yeah 2024-05-16 19:55:26 But the people need to be taken care of is taken good care of. So I'm glad I don't need to stress with that. 2024-05-16 19:56:24 anyways... im thinking rc1 now 2024-05-16 19:56:37 there are some MRs in alpine-conf we should get in first I think 2024-05-16 19:57:13 i had planned to look at that yesterday and today, but other things needed to prioritized 2024-05-16 19:57:32 i thikn we need to make a 3.19.2 too? 2024-05-16 19:57:58 some sec fixes in busybox and openssl. 2024-05-16 19:58:14 just need verify that all needed fixes are in 3.19-stable branch 2024-05-16 19:58:43 openssl has not been upgraded yet 2024-05-16 19:58:51 no release was made, so we need to backport the commits 2024-05-16 19:59:06 At least, if you are referring to the slow parsing of DSA keys 2024-05-16 20:02:10 if I have package in "main", I cannot include dep from "community", right? 2024-05-16 20:02:21 Nope 2024-05-16 20:02:33 packages in main can only depend on other packages in main 2024-05-16 20:02:39 so, as a part of the package I need to move the dep into the main 2024-05-16 20:02:50 Or move that package to community 2024-05-16 20:02:56 it been moved from main like "Date: Thu Mar 14 14:47:43 2024 +0100" 2024-05-16 20:03:08 can't do... mesa (gpu driver :D ) 2024-05-16 20:03:11 heh 2024-05-16 20:03:20 Which package was moved? 2024-05-16 20:03:35 since 24.1 we have py3-ply dep for Intel GRL 2024-05-16 20:07:06 to be correct we had it before, but I think now something is default on in the build 2024-05-16 20:08:51 moved from main as part of the 3.12 upgrade 2024-05-16 20:15:24 Ok, Intel Vulkan RayTracing got enabled by default.. that's why (on x86_64) 2024-05-16 20:15:43 as a part of the upgrade MR so far I'm moving it to main again... :) 2024-05-16 21:06:46 oh no, the builders are no longer idle... 2024-05-16 21:11:28 dot dot dot 2024-05-16 21:19:13 dat not dot rot? dat dot bot! 2024-05-16 21:23:49 do you do rc_ releases in edge often or it's more like stable rel thing? 2024-05-16 21:46:41 well, if you want, there is probably last RC of mesa 24.1-rc4 (has nvk modifiers and EGL+x11 transparency fixes), pretty cool release thou, so far it builds with one extra patch which should get into the final 24.1 2024-05-16 21:47:01 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66034 2024-05-16 21:47:55 this would be a bad time to put anything experimental in edge 2024-05-16 21:48:10 Alpine 3.20 is branching soon 2024-05-16 21:49:01 when? the final release is most likely 2024/05/25 2024-05-16 21:49:53 ... and as some XZ developer and fake users would said: "these cool features needs to get in" :D 2024-05-16 21:49:59 ACTION couldn't help himself 2024-05-16 22:20:51 we shouldnt push anything to git master that we wouldnt push to a stable branch at this point 2024-05-16 22:20:58 think feature freeze 2024-05-16 22:21:42 kk, then I can relax :) 2024-05-16 22:27:22 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65955 is all stable release updates 2024-05-16 22:27:47 Would be helpful if it'd be merged, as we'd otherwise have to send it against both edge and 3.20 branches 2024-05-17 07:31:27 dotnet6-build appears to be deadlocked 2024-05-17 07:31:42 good timing... i wanted to tag RC1 2024-05-17 07:32:09 if its *not* deadlocked and I kill it it will take all day to rebuild it 2024-05-17 07:32:35 I dont know what to do :-/ 2024-05-17 07:36:15 revert, kill, tag, revert? 2024-05-17 07:37:29 But there are 10 other aports (maybe more now) in the queue 2024-05-17 07:40:40 Wouldn't reverting mean the other archs will now attempt to build the previous version? 2024-05-17 07:43:04 i killed it 2024-05-17 07:43:28 it started 11 hours ago 2024-05-17 07:43:36 build-edge-armv7 completed same build in 1.5 hours 2024-05-17 07:49:26 If it has already completed on some arches then we cannot revert indeed 2024-05-17 07:54:24 electron has also built all night. has still 10000 cxx files to build 2024-05-17 07:58:34 At least build-2-20-armv7 had uploaded main 2024-05-17 07:58:42 Now 23 aports in community 2024-05-17 07:58:56 and it got back to dotnet6 2024-05-17 09:15:30 the riscv is something isnt "npm error Cannot read properties of undefined (reading 'os')" 2024-05-17 09:19:26 retry worked 2024-05-17 10:18:27 alright! we are ready for RC1 2024-05-17 10:18:36 almost. I found a bug in alpine-conf 2024-05-17 10:20:17 oh no, they are releasing new stable kernels... 2024-05-17 10:24:13 oh no, so close 2024-05-17 10:33:47 yeah. kernels will take an other hour or so 2024-05-17 10:33:52 but im working on it 2024-05-17 11:44:43 https://gitlab.alpinelinux.org/ovf/aports/-/jobs/1388585 -- something is up with the aarch64 runner? 2024-05-17 11:46:43 no, sorry, disregard me. some aarch64-specific gles problem 2024-05-17 12:05:49 oh no i guess my thinkpad broke 2024-05-17 12:05:52 its not starting anymore 2024-05-17 12:56:59 cely: thanks 2024-05-17 12:59:14 What do i do? :) 2024-05-17 12:59:25 Are you referring to xterm? 2024-05-17 12:59:33 s/do/did/ 2024-05-17 13:01:48 yes ^^ 2024-05-17 13:02:19 it's a bit of a last-minute send so appreciate you and others on the team still reviewing the queue 2024-05-17 13:02:36 You're welcome :) 2024-05-17 13:02:52 alright, i pushed rpi kernel. i think this is the last bit before 3.20.0 RC1 2024-05-17 13:03:32 Anyway, we aren't braching 3.20 yet, so whatever is merged between RC1 and the actual release will still get into 3.20 2024-05-17 13:03:47 correct 2024-05-17 13:04:04 please be careful with what you push now 2024-05-17 13:04:27 if you can wait an hour with pushing, please do so 2024-05-17 13:19:23 I hope py3-pandas isn't stuck.. 2024-05-17 13:22:07 I dont think it is, it is only painfully slow 2024-05-17 13:22:12 same with py3-zeroconf 2024-05-17 13:22:20 looks like it does not parallelize the builds 2024-05-17 13:23:22 i have now tagged 3.20.0_rc1 and I'm just waiting for the builders to go idle. please dont push anything now til after 3.20.0_rc1 are uploaded 2024-05-17 13:24:16 Hmm, ok, they use Cython, and py3-pandas doesn't run tests (i was thinking tests were what slowed it down) 2024-05-17 13:24:17 Alright, noted on my end 2024-05-17 13:27:43 i didnt have patience to wait on build-edge-x86_64 and pushed the 3.20.0_rc1 tag 2024-05-17 13:30:38 Do the edge builders have to do anything, considering this is 3.20? 2024-05-17 13:31:42 Well, 3.20 hasn't branched, but if edge has to do something, i'm wondering how it doesn't duplicate what the 3.20 builders do 2024-05-17 13:31:54 it doesnt, which is why i pushed the tag 2024-05-17 13:32:31 Ok 2024-05-17 13:40:38 alright! the 3.20.0 RC1 is uploaded! \o/ 2024-05-17 13:41:14 :) 2024-05-17 13:41:22 \o/ 2024-05-17 13:43:01 o/ 2024-05-17 13:43:10 whooo 🥳 2024-05-17 13:48:58 \m/ 2024-05-17 13:59:18 thanks!! 🍻 2024-05-17 14:04:06 🎉 2024-05-17 14:19:36 \o/ 2024-05-17 14:37:27 \o/ 2024-05-17 14:42:03 woop! 2024-05-17 15:51:39 Great! \o/ 2024-05-17 16:48:16 I'm looking at an issue I filed a few months back (#15501) which still seems to be present in 3.20 RC1. I think it's a build issue but I can't reproduce that locally using the procedure described in the "Creating an Alpine package" page. So I reckon the official builders are doing something _else_ than that procedure implies. I think that would be obvious if I could look at the build logs for the package in question from the official builder; are 2024-05-17 16:48:16 they available somewhere? 2024-05-17 16:51:22 https://gitlab.alpinelinux.org/ovf/aports/-/jobs/1388781#L588 -- looking at (what i think is) the relevant cmake file, this is failing a basic compiler invocation. something up with aarch64? i think it worked before, and also on other architectures 2024-05-17 18:07:40 ovf: this seems to only happen with the newest version 2024-05-17 18:10:10 ovf: 1.3.2 reports Performing Test HAVE_STDATOMIC - Success 2024-05-17 18:12:13 ovf: same with 1.4.5: Performing Test HAVE_STDATOMIC - Success 2024-05-17 18:12:21 so it's something that happened in 1.5.0 2024-05-18 04:58:17 3.20 it's branched, it's good time to merge new stuff? 2024-05-18 04:59:20 No it has not been branched 2024-05-18 04:59:29 rc1 is a tag, not a branch 2024-05-18 05:00:55 kk,thx 2024-05-18 07:26:21 SWagner is maintainer of 17 aports but hasn't been active for five years and a half 2024-05-18 07:26:28 grep -r "Maintainer: Stefan Wagner" 2024-05-18 07:27:55 I guess it would be good if they were adopted by more active participants 2024-05-18 07:28:48 I'll take irssi-xmpp and xdotool 2024-05-18 07:43:19 I could take macchanger 2024-05-18 08:39:38 !66120 2024-05-18 08:40:41 How can I help testing the 3.20 rc? Also I noticed the build on the tag failed for x86_64, but I'm sure it didn't go unnoticed 2024-05-18 08:45:55 Where are you sseing that it failed? 2024-05-18 08:47:16 seeing* 2024-05-18 08:52:56 witcher: if you have a 3.19 installation you could try doing a regular upgrade, that is changing 3.19 to 3.20 in your /etc/apk/repositories file and then run `apk upgrade --available`, and report any issues you run into during or after the upgrade 2024-05-18 08:54:40 cely: https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/234836 2024-05-18 08:55:01 omni: cool, will do, thanks 2024-05-18 09:02:07 I don't think the CI pipeline for the tag matters, and i think no one else has brought this up 2024-05-18 09:03:10 I don't think the CI is used to build the release, which is why it doesn't matter 2024-05-18 09:05:45 sure, but I'm assuming it serves *some* purpose, otherwise it wouldn't run. I'd have downloaded a 3.20 rc ISO to test installing from ISO, which is what I'm guessing that pipeline would have produced 2024-05-18 09:06:10 I don't think the pipeline produces the ISO 2024-05-18 09:06:44 seems like you're correct 2024-05-18 09:07:18 The ISOs are available at https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/ 2024-05-18 09:08:24 how is building them triggered? 2024-05-18 09:09:35 Someone else will have to answer that question :) 2024-05-18 09:10:00 alright :D thanks! 2024-05-18 09:10:29 but what i know is, the CI is only for testing your commits, it catches most mistakes 2024-05-18 09:10:41 When your MR is merged, it then gets built on the builders 2024-05-18 09:11:12 Which you can view the status of at https://build.alpinelinux.org/ 2024-05-18 09:15:37 yeah I know about aports building the packages, just curious how the image building process goes 2024-05-18 09:16:05 also curious if there are any automated tests for newly built images 2024-05-18 09:17:35 I think it is the builders that build the images too after a tag is pushed 2024-05-18 09:18:08 At least, you can see messages about the images being built in build.a.o 2024-05-18 09:18:30 s/in/on/ 2024-05-18 11:16:52 if i try to set up raid with setup-disk on 3.20rc1 i get a segfault in mdraid. also tested this on with 3.19.1 without issues 2024-05-18 11:17:44 mdadm* 2024-05-18 11:18:29 ncopa: pinging because you're the maintainer of the mdadm package 2024-05-18 11:34:20 Could it be basename-related? !63509 2024-05-18 11:34:33 Sorry 2024-05-18 11:34:37 !63905 2024-05-18 11:35:37 running with gdb i get "src/string/strlen.c: No such file or directory" 2024-05-18 11:37:03 so i don't think so? i'm not sure 2024-05-18 11:37:44 Maybe you could try the patch from that MR? (the one that adds libgen.h) 2024-05-18 11:38:32 sure i'll try building the MR and using that binary 2024-05-18 11:41:54 that seems to fix it yeah 2024-05-18 11:43:40 thanks cely! 2024-05-18 11:44:28 hm I already wrote up an issue about it. thinking about posting it and closing with a reference to the MR so it's documented. is that okay? 2024-05-18 12:04:20 ikke: thanks! i guess i'll need to find an aarch64 box to figure this one out 2024-05-18 12:04:55 ovf: if there is something you like me to test, let me know 2024-05-18 12:28:15 witcher: I rebased !63905 to trigger a rebuild so that you could download and install the build artifact package if you want 2024-05-18 12:29:29 and an issue referencing it doesn't hurt 2024-05-18 12:41:03 #16122 2024-05-18 12:41:43 omni: already built it locally and tried after installation, but i appreciate it, thanks! 2024-05-18 12:56:33 witcher: the same way as it is builtin that MR or just with the basename patch, without upgrade etc? 2024-05-18 12:57:43 the same was as is built with the patch, i.e. abuild -r and i took mdadm-*.apk from ~/packages/main, copied it to my testing machine and installed it there 2024-05-18 12:58:10 the same as with the whole MR* 2024-05-18 13:06:35 ok, thanks 2024-05-18 13:21:56 hi, could !65967 get merged? 2024-05-18 13:35:20 i'm wondering if something's missing for !63709. it's been open for a while now 2024-05-18 13:48:09 I tried looking to see if there's something in upstream about basename for a few aports 2024-05-18 13:48:41 rdma-core: https://github.com/linux-rdma/rdma-core/pull/1443 - PR Closed 2024-05-18 13:53:28 ofono: https://lore.kernel.org/connman/20240102015917.3732089-1-raj.khem@gmail.com/T/ 2024-05-18 13:57:28 obexd-enhanced: https://github.com/bluez/bluez/issues/843 2024-05-18 15:09:20 Are there additional requirements for adding new aports? I made a PR a week ago, but now I'm starting to wonder if I should've done anything else 2024-05-18 15:10:54 kaathewise: no, it's just release time 2024-05-18 15:12:32 There's a bit of a backlog atm, people focussing on getting the release out (and thus fixing issues / build failures) 2024-05-18 15:13:49 The usual "https://github.com/hellux/jotdown/archive/v$pkgver.tar.gz" returns 2024-05-18 15:13:51 # 404 for some reason. 2024-05-18 15:14:06 Is that because you add the 'v' while upstream does not have that prefix? 2024-05-18 15:44:31 ikke: got it, thanks! 2024-05-18 16:16:10 ikke: I wasn't able to figure it out. I think it's the tags, yeah. I saw a couple more repos in aports, lemme look it up 2024-05-18 16:17:13 kaathewise: https://github.com/hellux/jotdown/archive/0.4.0.tar.gz returns 200 for me 2024-05-18 16:17:19 ie, without the v 2024-05-18 16:17:43 I could've sworn I tried it, but I must've made a typo elsewhere 2024-05-18 16:30:59 On the note of Cargo: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65810#note_405810 2024-05-18 16:31:29 There are half a dozen packages in the tree, which still rely on the outdated "# limited by cargo" info 2024-05-18 16:31:35 Would it be fine for me to open a PR for which? 2024-05-18 16:31:56 Or should I hold it off until after the 3.20 release, to avoid spamming the PRs 2024-05-18 16:33:02 I'd do that 2024-05-18 16:34:35 Sry, but does "that" refer to the first option, or the second one? 2024-05-18 16:34:40 the latter 2024-05-18 16:34:49 got it 2024-05-18 16:45:02 I wonder if build-3-20-aarch64 is stuck on py3-virtualenv 2024-05-18 16:51:48 appears so 2024-05-18 16:53:33 Thanks a lot for the help! 2024-05-18 17:04:40 np 2024-05-18 18:22:02 Is it still possible to merge package upgrades for 3.20? I would love it if one of my packages was upgraded. 2024-05-18 18:22:23 hjaekel: As long as it's not intrusive / requires a lot of rebuilds 2024-05-18 18:24:05 It is not intrusive, but it requires some rebuilds. I am talking about !64681. Do you think that's too big to be merged now? 2024-05-18 18:32:03 Hmm, takes ~8h on rv64 2024-05-18 18:33:26 yes, it does 2024-05-18 18:34:21 I think it can still be merged 2024-05-18 18:34:39 Especially now in the weekend 2024-05-18 18:36:01 I would be happy if we could find a slot. Especially because there will be no more updates for 3.8.x. 2024-05-18 18:56:28 hjaekel: small detail, the description of the cmake_destination patch was copied from the soversion patch 2024-05-18 18:56:56 If you provide a patch I can apply that when merging 2024-05-18 18:57:46 (package libqb3) 2024-05-18 18:57:48 good point, I will change that 2024-05-18 19:05:27 nice, gitlab now has x/c shortcuts for quickly navigating to previous / next commit when reviewing individual commits in a merge request 2024-05-18 19:06:44 ikke, I corrected the description 2024-05-18 19:06:48 Yes, saw it 2024-05-18 19:12:57 hjaekel: merged 2024-05-18 19:13:21 checked to be certain all depending packages were included to be rebuilt 2024-05-18 19:14:07 oh my, that's gonna block the builders for.. a while 2024-05-18 19:14:25 Thank you ikke! 2024-05-18 19:15:03 ptrc: should be finished by tomorrow 2024-05-18 19:15:17 hopefully : 2024-05-18 19:15:20 :p * 2024-05-18 19:15:41 In CI, the longest was rv64, which took 8 hours 2024-05-18 19:15:53 the rest was all ~1h 2024-05-18 19:16:23 Is there a list of open issues for 3.20 that I could help with? I have some time right now. 2024-05-18 19:16:36 https://gitlab.alpinelinux.org/groups/alpine/-/milestones/6 2024-05-18 19:17:39 At least the builders are no longer blocked on git-lfs2 2024-05-18 19:35:32 having a simple build issue on the builder but can't seem to replicate it locally https://gitlab.alpinelinux.org/mio/aports/-/jobs/1390203#L1308 sh can't find a script and the tests fail, but tried locally and the error doesn't occur 2024-05-18 19:35:58 (tests pass without issue) 2024-05-18 19:40:49 mio: I can reproduce it in the alpinelinux/build-base image 2024-05-18 19:41:24 script starts with: '#!/bin/bash' 2024-05-18 19:41:28 which is not present by default 2024-05-18 19:41:34 ikke: thanks for confirming. just upgraded to latest edge, same abuild version ... ah! 2024-05-18 19:41:57 great catch, thanks! 2024-05-18 19:41:57 so add bash to checkdepends 2024-05-18 19:42:24 mio: usually a mistic "cannot find file" error when tryin to execute something means the interpreter cannot be found 2024-05-18 19:42:39 either the dynamic loader for executables or the interpreter for scripts 2024-05-18 19:42:46 mysterious* 2024-05-18 19:43:35 mio: a cursory look seems to indicate it's not even using bash specific syntax 2024-05-18 19:43:42 so you can also patch it to use /bin/sh instead 2024-05-18 19:46:53 ikke: thanks for the tips! would it be better to replace on the fly in a prepare() block or keep it as a separate patch instead? since it's a very small change 2024-05-18 19:47:39 to potentially have it use /bin/sh that is 2024-05-18 19:48:14 mio: patches are preferred because it's more clear what is changed (no accidental changes on different places), and it makes noise when something changes 2024-05-18 19:49:35 okay, thanks ^^ 2024-05-18 20:53:13 ptrc: hjaekel all arches except rv64 already finished already (rv64 I'm not sure) 2024-05-19 04:17:04 build-edge-riscv64 has probably gotten stuck on testing/git-bug 2024-05-19 05:50:43 no more 2024-05-19 05:55:31 Ok 2024-05-19 13:44:02 whats the available memory for the armv7 ci? it cant build jellyfin-web 😞 2024-05-19 13:53:36 fabricionaweb Number of Cores: 32; Memory: 31.2867 Gb 2024-05-19 13:56:40 thats a lot, shouldnt fail due memory LOL 2024-05-19 13:56:59 fabricionaweb: most likely runs out of 32-bits address space 2024-05-19 13:57:26 which is ~4G 2024-05-19 13:57:43 thats not a lot, that explains why its failing 2024-05-19 13:57:56 That's inherrent to 32-bits arches 2024-05-19 13:58:57 JavaScript heap out of memory 2024-05-19 13:59:49 That's not necessarily not being able to locate more memory 2024-05-19 13:59:55 https://stackoverflow.com/questions/38558989/node-js-heap-out-of-memory 2024-05-19 14:00:01 s/locate/allocate 2024-05-19 14:00:19 I tried some of that space size, still no bueno :/ 2024-05-19 14:01:24 lemme try a little bit again, thanks 2024-05-19 14:17:34 no, none of this worked, I give up 2024-05-20 07:45:56 omni I was under impression jellyfin and jellyfin-web could be merged in one package and sub-packages, but not sure, so bl4ckb0ne would knows better 😅 2024-05-20 07:51:09 fabricionaweb: I was just momentarily blind to the "-web" part and thought they were MRs for the same aport 2024-05-20 07:51:33 perhaps both changes could go into the same MR, though 2024-05-20 07:52:28 yes thats fair 2024-05-20 07:55:34 omni: can you please fix mdadm basename patch? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63905#note_406300 2024-05-20 07:56:28 Looks like there's a Redis 7.2.5.. 2024-05-20 08:18:43 ncopa: there, thanks 2024-05-20 11:50:00 fabricionaweb: i usually update them in one mr but they should be seperate packages 2024-05-20 11:50:15 they are different sources 2024-05-20 15:04:51 fluix: !64402 2024-05-20 18:28:01 can you please hold your git pushes for a few mins. I'd like to tag RC2 2024-05-20 18:33:50 alright, rc2 is tagged 2024-05-20 18:53:23 woop 2024-05-20 19:02:13 i really really rrrrrrrrrrrrreally want tag 3.20 tomorro 2024-05-20 19:03:03 and im prepared to git rm -r -r -r -r -r -r -r -r -rrrrrrrrrrrr anything that comes in the way 2024-05-20 19:04:19 is there a way to do "dep1 OR dep2" in an install_if? 2024-05-20 19:05:33 Not sure if it works, but I suppose only if either package have the same provides 2024-05-20 19:06:59 nice, saidly I still have some opened mr 2024-05-20 19:39:16 ncopa, question: what actually "happens" between rc2 and .20? 2024-05-20 19:40:12 we fix all the open issues we can 2024-05-20 19:40:27 we verify that the issues reported against rc1 are fixed 2024-05-20 19:40:40 like mdadm 2024-05-20 19:40:47 i run alpine-installer-testsuite 2024-05-20 19:40:47 right 2024-05-20 19:40:52 and try fix whatever shows up 2024-05-20 19:41:00 was just wondering, i bet the tag makes images appear etc.? 2024-05-20 19:41:09 yes 2024-05-20 19:41:14 it should be automatic 2024-05-20 19:41:17 ack 2024-05-20 19:41:32 i'm used to leaving RCs (of software, not distributions) out there for weeks, which is why the day raised questions :) 2024-05-20 19:41:38 we also need to create a release notes MR, so people have a chance to add/comment etc 2024-05-20 19:41:44 right 2024-05-20 19:42:13 the problem is that git master is a moving target 2024-05-20 19:42:23 new breakages are introduced faster than we are able to fix 2024-05-20 19:42:50 i also had plans to work on tiny-cloud for 3.20 release, and was hoping to have some free time after RC1 was out 2024-05-20 19:42:56 but i think i will have to scrap that 2024-05-20 19:49:55 of course many things can go into a 3.20.1 2024-05-20 19:51:55 great /tmp/ccMbHPAb.s: Fatal error: can't write 3840 bytes to section .data.rel.local of epan/dissectors/CMakeFiles/dissectors.dir/packet-acr122.c.o: 'No space left on device' 2024-05-20 19:52:06 "stupid reasons my build failed, #3" 2024-05-20 20:38:39 release notes for 3.20: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/77 2024-05-21 00:35:42 For new versions, we also gained: Ruby 3.3.1, Nim 2.0.4, QEMU 9.0.0..ah, i see Jirutka has already added the first 2 to the Wiki 2024-05-21 03:16:47 I have bad news 2024-05-21 03:17:50 I'm trying the TAP driver example from https://www.gnu.org/software/automake/manual/html_node/Use-TAP-with-the-Automake-test-harness.html 2024-05-21 03:20:28 The example is also available in /usr/share/info/automake.info-2 (from automake-doc), starting at around line 1500 2024-05-21 03:21:20 In case there are any differences between the webpage and automake.info-2, i copy-pasted the example from automake.info-2 2024-05-21 03:23:33 Apparently, one of the Busybox awk patches from !66280 broke error reporting with automake's tap-driver.sh 2024-05-21 03:25:04 It is working with gawk and busybox 1.36.1-r26 2024-05-21 03:25:10 but not r27 2024-05-21 03:28:33 Just tried `make AWK=mawk check` and `make AWK=nawk check` (./configure was originally run with Busybox awk) 2024-05-21 03:28:37 and they work 2024-05-21 03:29:25 So, tap-driver.sh is alright with AWK=gawk, AWK=mawk, and AWK=nawk; but not AWK="busybox awk" where busybox=1.36.1-r27 2024-05-21 03:31:34 This will break tests for aports that use automake's tap-driver.sh, and do not have another AWK implementation in depends 2024-05-21 03:32:29 (for example !66090, that almost caused me to block the builders as i didn't expect something to change within the past 3 days that would cause the build to fail) 2024-05-21 05:29:37 hey cely! good you caught that! lets see if we can find a fix in busybox git 2024-05-21 05:38:37 6I think i've found it 2024-05-21 05:38:46 This is a precedence issue 2024-05-21 05:39:00 So, it seems the precedence of the ternary operator has been messed up 2024-05-21 05:40:04 COOKED_PASS = expect_failure ? "XPASS": "PASS"; (line 496 of /usr/share/automake-1.16/tap-driver.sh) 2024-05-21 05:40:33 Instead of being parsed as `COOKED_PASS = (expect_failure ? "XPASS": "PASS");` 2024-05-21 05:40:46 it is being parsed as `(COOKED_PASS = expect_failure) ? "XPASS": "PASS";` 2024-05-21 05:41:50 (When i said i found it, i meant this, not that i found a fix in busybox git) 2024-05-21 05:49:03 Yes, tested with a simple example, the precendence of the ternary operator in busybox 1.36.1-r27 awk is wrong 2024-05-21 05:49:35 or rather, its precendence when used together with = 2024-05-21 05:57:16 facepalm 2024-05-21 06:00:56 I guess we'll always have a bug found before release day :) 2024-05-21 06:01:49 For 3.19, it was NodeJS (not being rebuilt against main/ada), and now it's this Busybox awk precedence thing 2024-05-21 06:19:23 oh! good find! 2024-05-21 06:19:48 we need to fix it 2024-05-21 06:19:58 i also pushed this to 3.9-stable :-( 2024-05-21 06:22:21 do you have a reproducer? I'm not able to reproduce it 2024-05-21 06:22:29 awk 'BEGIN { a = 0 ? "yes": "no"; print a}' 2024-05-21 06:26:22 cely: can you please share the simple example? 2024-05-21 06:35:15 Sorry, got distracted by something else, and may also go AFK shortly 2024-05-21 06:35:20 but that's the reproducer 2024-05-21 06:35:28 What does it print for you? 2024-05-21 06:36:02 It should print "no" but on the patched busybox, it prints "0" instead 2024-05-21 06:36:46 If you still get "no", maybe you haven't upgraded busybox, or you have another AWK implementation as /usr/bin/awk 2024-05-21 06:38:43 busybox awk 'BEGIN { a = 0 ? "yes": "no"; print a}' 2024-05-21 06:38:44 0 2024-05-21 06:38:48 for me 2024-05-21 06:38:57 Thanks 2024-05-21 06:39:06 That's the bug 2024-05-21 06:39:22 busybox-1.36.1-r27 2024-05-21 06:39:28 Yes 2024-05-21 06:43:35 ah, i used wrong awk 2024-05-21 06:43:48 thank you cely! this is very helpful 2024-05-21 06:45:25 No problem 2024-05-21 06:45:44 I guess you have to get something helpful out of almost blocking the builders ;) 2024-05-21 06:47:13 This is also a funny correspondence with the 3.19 NodeJS issue, back then we sidestepped it by using NodeJS-current 2024-05-21 06:47:26 Now i've sidestepped the Busybox awk bug by using gawk 2024-05-21 06:47:49 he. i have forgot about that 2024-05-21 06:48:05 that said. i usually prefer to fix things over sidestepping them :) 2024-05-21 06:50:07 Sure (though i think both times the problem was only detected once it hit the builders, so something had to be done quick :)) 2024-05-21 06:50:23 yeah, it happens... 2024-05-21 08:11:06 hi all, i spotted tag v3.20.0_rc2, any time frame for 3.20? 2024-05-21 08:12:27 can I get a review for !65997 2024-05-21 08:27:35 indy: ncopa wants to tag it today 2024-05-21 08:41:03 Not sure we will make it. Need to try fix busybox awk 2024-05-21 08:44:55 And I need to go out for a couple of hours 2024-05-21 09:40:59 Does `abuild rootbld` allow me to specify the path to the chroot? 2024-05-21 10:33:06 busybox awk apparently has a pretty baroque parser. for something of this complexity i'd have probably expected recursive descent. 2024-05-21 10:35:43 It is recursive? 2024-05-21 10:38:35 no, it's a hand-written state machine 2024-05-21 10:53:18 well, no, it's partially recursive 2024-05-21 11:45:49 nmeum: sorry for incorrect assigning you, somehow I thought it was about busybox tar 2024-05-21 11:46:58 all good, happens :) 2024-05-21 11:47:53 we need algibot to do issue assignments for us at some point 2024-05-21 11:47:56 https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/issues/33 2024-05-21 11:48:03 just haven't had the time to work on this sadly 2024-05-21 11:48:18 Yes, I have been focussing on getting useful data on secfixes.a.o again 2024-05-21 11:48:45 ovf: busybox has a few extremly awful parsers. the posix shell parser is also an absolute hellhole for example 2024-05-21 11:50:12 I guess the good thing about most busybox parsers (awk, shell, …) is that they dont (usually) process untrusted input though 2024-05-21 11:51:56 curl | sh :D 2024-05-21 12:49:54 i think we need to revert the busybox CVE fix which introduced awk regression 2024-05-21 13:23:43 Yeah 2024-05-21 13:23:53 That's probably the best way forward for now 2024-05-21 13:25:17 I think it's only CVE-2023-42364-CVE-2023-42365.patch though, the other use after free patch seems alright 2024-05-21 13:38:53 yeah 2024-05-21 13:38:59 im pretty sure that is the case 2024-05-21 13:39:50 the upstream busybox commit that introduces the regression is generally questionable: http://lists.busybox.net/pipermail/busybox/2024-May/090764.html 2024-05-21 13:40:50 but it also means that we get the use-after-free back 2024-05-21 13:41:35 it is a nightmare bug 2024-05-21 13:48:30 That is quite a number of messages to the Busybox list in a day, too bad it doesn't look like there will be a fix in time for 3.20 2024-05-21 14:01:15 yeah, its kinda sad that we will ship alpine 3.20 with know CVE 2024-05-21 14:08:13 cely: if you have time to help me. can you help me find a smaller reproducer of https://bugs.busybox.net/show_bug.cgi?id=15871 There are a POC awk and inputfile. Run it under valgrind and you'll see invalid writes (use-after-free). 2024-05-21 14:08:49 but the POC awk is a bit big. would be nice with a smaller reproducer 2024-05-21 14:20:27 *if* you have time. the invalid write happens after returning from POC.awk: global_state_p(flags), line 98. 2024-05-21 14:22:31 Hmm, actually, i don't know much about awk, and that's a pretty complicated awk script 2024-05-21 14:22:39 Seems like it comes from GCC 2024-05-21 14:23:16 it is complicated, indeed. but you wre pretty good in finding it out earlier today :) 2024-05-21 14:23:28 nevermind. I'm on it 2024-05-21 14:23:55 im just commenting out lines til i find what makes it go bad 2024-05-21 14:26:28 do we have loongarch64 support now? 2024-05-21 14:26:35 not yet 2024-05-21 14:26:48 so !66246 is relevant even though the lint fails 2024-05-21 14:27:00 I'm looking at a newer verison of the file 2024-05-21 14:27:33 and global_state_p has `var_name(flags) != ""`, != instead of -= 2024-05-21 14:28:02 version* 2024-05-21 14:28:08 i am looking at exact those lines 2024-05-21 14:28:34 this does nto trigger it: return flags -= "" 2024-05-21 14:29:18 this triggers it: return var_name(flags) -= "" 2024-05-21 14:29:43 even if var_name is: function var_name(flags) { return flags } 2024-05-21 14:31:30 bl4ckb0ne: it is relevant because even though the builder isn't online yet, the Loongarch people are building aports and opening MRs for things that fail on that arch 2024-05-21 14:32:29 alright so it's all planned 2024-05-21 14:33:02 Yes, originally planned for 3.20, but we already had too much for that, so moved to 3.21 instead 2024-05-21 14:33:04 i was thrown off by the lint saying it's not a valid arch and thought it was somebody on their own trying to make loongarch64 a thing on their end 2024-05-21 14:33:39 I think that's the impression of many maintainers who aren't aware of the TSC decision to support Loongarch 2024-05-21 14:33:52 yeah i missed that 2024-05-21 14:34:02 any relevant place I should subscribe to not miss those? 2024-05-21 14:34:15 https://gitlab.alpinelinux.org/alpine/tsc ? 2024-05-21 14:35:48 Probably at least scheming through the meeting minutes helps, if you don't want to look through the issues where things can get verbose with all the debates and so on 2024-05-21 14:36:44 hm cant get notif on new push 2024-05-21 14:37:41 s/scheming/skimming/ 2024-05-21 14:39:41 Hmm, i've suddenly thought of something looking at the awk script 2024-05-21 14:40:44 If the precedence issue is assignment vs comparison operators 2024-05-21 14:42:04 Maybe the commit that seemed to fix it is turning `var_name(flags) -= "" || ...` into `(var_name(flags) -= "") || ...` instead of `var_name(flags) -= ("" || ...)` 2024-05-21 14:42:24 yeah, i think that may be the case 2024-05-21 14:42:58 but `var_name(flags) -= ""` is probably wrong anyway, as newer versions of that file have changed it to != 2024-05-21 14:43:48 i thikn it is supposed to exit with "Unexpected token" or similar 2024-05-21 14:44:02 but it doesnt. and ends up with a use-after-free 2024-05-21 14:58:56 Perhaps the part of the patch (that you reverted) around "FIXME: this is the place to detect and reject assignments to non-lvalues" contains what is needed to fix the use-after-free 2024-05-21 14:59:13 dalias, have you ever heard of LMDB locking problems between glibc and musl processes? because we are at at least two observations now - https://github.com/PowerDNS/lightningstream/issues/75#issuecomment-2122533369 2024-05-21 14:59:31 cely: that is very possible. been thinking that too 2024-05-21 14:59:41 i have a fairly small reproducer now 2024-05-21 15:03:50 https://tpaste.us/O8Db 2024-05-21 15:13:25 valgrind busybox awk 'function f1(v) { return v } function f2(a) { return f1(a) -= 0 } function f3(a) { return missingfunc(a) } BEGIN { f2() || f3() }' 2024-05-21 15:21:33 and I have a new fix! 2024-05-21 15:23:17 ncopa: I thought you would rm everything that was in the way of a release today :P 2024-05-21 15:24:48 yeah 2024-05-21 15:36:59 never get between a tech lead and a release 2024-05-21 15:43:04 habbie, what kind of lock? 2024-05-21 15:43:28 dalias, fcntl on ranges 2024-05-21 15:43:57 ah ok i tjought you meant like shared mem pthread locks 2024-05-21 15:44:04 tjose def wont worl 2024-05-21 15:44:11 but fcntl should 2024-05-21 15:44:13 right 2024-05-21 15:44:22 on linux i think lmdb also uses shared mem pthread locks 2024-05-21 15:44:23 lol 2024-05-21 15:44:34 and just you reminding me of that explains a lot 2024-05-21 15:44:40 i knew this earlier today, before the dots were connected 2024-05-21 15:44:47 dalias: For a second I was pretty sure you needed to change password 2024-05-21 15:44:52 lol 2024-05-21 15:44:59 in general you can't use shared memory between processes with mismatching ABIs 2024-05-21 15:45:03 yeah 2024-05-21 15:45:09 now that i connected all the dots, this is obvious to me 2024-05-21 15:45:12 (glibc vs musl, 32-bit vs 64-bit, qemu-user-hosted vs native, etc) 2024-05-21 15:45:36 thanks! 2024-05-21 15:45:38 np 2024-05-21 15:45:46 if those can be disabled and just use fcntl, it may work 2024-05-21 15:46:07 yes, that's a clear question to investigate for me :) 2024-05-21 16:55:18 This AWK precedence thing is hard to get right :( 2024-05-21 16:56:49 Now a Busybox test is failing because `echo -ne 'foo' | awk '$1==$1="foo" {print $1}` doesn't return "foo" 2024-05-21 17:18:49 traefik has cve fixes but on rc only, anything to do or just wait for their release it? 2024-05-21 17:19:29 https://www.cve.org/CVERecord?id=CVE-2024-28869 2024-05-21 17:20:28 guess it doesnt affect is since its pointing >= rc1 and we dont have it 2024-05-21 17:21:49 If no versions that we have packaged are affected, we do not need to do anything indeed 2024-05-21 17:24:03 nice, no work is the best work 2024-05-21 17:24:52 affected at < 2.11.2 2024-05-21 17:25:16 If we have 2.11.1 or lower somewhere, it's affected as well 2024-05-21 17:25:40 oh yes on 3.19 2024-05-21 17:25:50 and below 2024-05-21 17:26:23 Since it's in community, only 3.19 is supported 2024-05-21 17:29:06 now I have more questions 2024-05-21 17:30:55 the package 3.19 is parked on 2.10.6, since then there is more CVE, now if I send the MR for 2.11.3, shoud I mention all cve fixed in the same 2.11.3? or I list it on respective versions even if didnt have been release (from our side)? 2024-05-21 17:32:17 The former 2024-05-21 17:32:45 We specify the first package version that contains the fixes 2024-05-21 17:33:24 When upgrading from 2.10 to 2.11, make sure there are no breaking changes or gotchas for users of the package 2024-05-21 17:39:47 it seems it have some notes indeed 2024-05-21 17:40:31 https://doc.traefik.io/traefik/migration/v2/#v211 2.11, 2.11.1 and 2.11.2 all of it have some notes ☠️ haha 2024-05-21 17:41:30 "The following ciphers have been removed from the default list:" can be considered breaking 2024-05-21 17:41:56 Same with minimum tls version 2024-05-21 18:11:01 Could somebody please click the magic button in this MR? It's been waiting for some weeks. !64960 2024-05-21 18:12:29 done 2024-05-21 18:13:14 Thermi: I've added you as guest to the project so that you can approve MRs assigned to you 2024-05-21 18:13:19 ikke, if you dont mind take a look !66338 2024-05-21 18:13:32 ikke, that is very kind of you, thank you 2024-05-21 18:14:36 fabricionaweb: since there are potentially breaking changes, we have to wait for fcolista 2024-05-21 18:14:50 yes, sure 2024-05-21 18:14:53 thank you 2024-05-21 18:15:30 https://www.cve.org/CVERecord?id=CVE-2024-24788 seems to be a go related issue 2024-05-21 18:15:46 not traefik 2024-05-21 18:16:23 hmmm indeed 2024-05-21 18:17:05 dfa5f0fb3956cb94f6840ec1c3cc3d4544a0852a 2024-05-21 18:17:14 traefik was also already rebuilt 2024-05-21 18:18:28 Only CVE-2024-28869 is related to traefik itself 2024-05-21 18:19:52 ah ok cool, so let me think what to do now 🤣 2024-05-21 18:20:17 fabricionaweb: check if there is a patch specific to that CVE and see if you can just apply that 2024-05-21 18:34:16 it seems too much changes by what I could see (they reververted a feature) 2024-05-21 18:51:21 anyway the package dont built it requires go 1.22 that isnt on 3.19 ☠️ 2024-05-21 19:11:27 :/ 2024-05-21 19:34:32 cely: thats why he ended up “fixing” precedence 2024-05-21 23:22:39 looks like lld for llvm18 was previously given the green light for main but it isn't available yet, question mark? 2024-05-22 02:24:41 timlegge: i've included a commit to disable tests for testing/perl-net-amqp-rabbitmq in !66183 (i also took the opportunity to recreate it with apkbuild-cpan template 4, and amend the license to its proper SPDX identifier) 2024-05-22 02:25:28 cely thanks - sorry I did not get to that 2024-05-22 02:27:15 I just looked and it looks great 2024-05-22 02:28:10 No problem 2024-05-22 02:28:59 Disabling it during the rebuild also sort of gives it some context 2024-05-22 02:29:58 Anyway, that should be the only aport in the MR which has other changes besides a pkgrel bump 2024-05-22 04:37:59 fluix: i think for most Python aports, we have been relying on gpep517 to install a license file 2024-05-22 04:38:38 thanks, so the one under site-packages right? 2024-05-22 04:38:46 Yes 2024-05-22 04:39:09 and i don't think we insist on having a license file anyway, except for MIT-licensed aports 2024-05-22 04:39:41 yep, but these are both MIT 2024-05-22 04:39:53 At least, it's been determined that MIT license files need to be included, and that's been documented on the wiki 2024-05-22 04:40:28 Hmm, as it's Python, maybe the license is already included in a header in the .py files 2024-05-22 04:40:49 If it is, perhaps that could be considered included 2024-05-22 04:41:14 well gpep puts it in dist-info so I figure that's definitely included, right? 2024-05-22 04:41:29 In most cases, yes 2024-05-22 04:42:06 (can't recall a specific case where it wasn't, but i'm not really the license police ;)) 2024-05-22 04:42:49 yeah I'm not sure how it goes about finding it and/or what happens if there's multiple, etc. 2024-05-22 04:42:52 either way, thanks, and gn 2024-05-22 04:43:30 You're welcome 2024-05-22 04:43:51 oh maybe it handles multiple fine: https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/1393980#L267 2024-05-22 04:43:56 anyways 2024-05-22 04:44:08 :) 2024-05-22 08:17:36 Regarding the unit test failure of the mangohud package on s390x: Does anyone have access to an s390x machine with and AMD GPU connected? If so, I would be highly interested in the contents of the gpu_metrics file ($ find /sys/devices -name gpu_metrics). That file would contain, as the name suggest, GPU metrics such als load, temperature, etc. I don't think it would contain sensitive data not fit for sharing. 2024-05-22 08:50:08 ok its time for release 2024-05-22 08:50:20 \o/ 2024-05-22 08:50:29 \o/ 2024-05-22 08:50:31 so pnpm wont go to community this time 2024-05-22 08:56:09 \o/ 2024-05-22 08:57:21 maribu: i guess here are not many people using s390x. maybe ask in the mailing list or ask in some s390x forums if its not alpine specific 2024-05-22 09:06:51 maribu: s390x is a mainframe architecture, I very much doubt there is any such machine that has any use of Mangohud. I wouldn't bother and just disable the package for it 2024-05-22 09:18:25 yeah just disable package for s390x 2024-05-22 09:43:37 OK, makes sense :) 2024-05-22 09:44:38 too bad the CI is superbusy at this point 2024-05-22 09:44:48 I cannot merge curl 8.8 2024-05-22 09:45:03 or anything 2024-05-22 09:46:13 :( 2024-05-22 09:46:22 thats life 2024-05-22 09:46:33 im tagging now 2024-05-22 09:47:29 alright 2024-05-22 10:26:33 Is this ok? https://gitlab.alpinelinux.org/ncopa/alpine-mksite/-/blob/release-notes-3.20/posts/Alpine-3.20.0-released.md 2024-05-22 10:28:01 i'm fine with it 2024-05-22 10:34:20 on no... 2024-05-22 10:34:23 https://dl-master.alpinelinux.org/alpine/v3.20/releases/ 2024-05-22 10:34:35 where is riscv64? 2024-05-22 10:37:28 It does exist on the builder 2024-05-22 10:40:03 let me rsync that manually 2024-05-22 10:40:45 maybe verify if other packages are synced as well? 2024-05-22 10:42:52 looks like they are 2024-05-22 10:47:43 linux-edge (no such package): 2024-05-22 10:47:43 ERROR: unable to select packages: 2024-05-22 10:47:43 required by: world[linux-edge] 2024-05-22 10:48:13 i think it failed to create the alpine-standard.iso due to kernel is not in main 2024-05-22 11:03:29 \o/ 2024-05-22 11:03:38 ACTION likes how the bot repeats these, cute. 2024-05-22 11:31:15 Hello from Alpine 3.20! All systems operational 2024-05-22 11:44:21 \o/ 2024-05-22 11:44:36 \o/ \o/ \o/ 2024-05-22 11:44:44 Uh oh 2024-05-22 11:46:41 \o/ 2024-05-22 11:46:48 \o/ 2024-05-22 11:50:55 \o/ 2024-05-22 11:51:06 \o/ 2024-05-22 11:54:42 \o/ 2024-05-22 11:56:34 thanks everyone 2024-05-22 11:56:40 nice work 2024-05-22 11:57:15 thank you everyone, indeed 2024-05-22 12:03:44 Congrats on the release! 2024-05-22 12:06:36 \o/ 2024-05-22 12:07:11 \o/ 2024-05-22 12:14:45 \o/ 2024-05-22 12:16:40 Significant changes 2024-05-22 12:16:41 Initial support for 64 bit RISC-V was added. 2024-05-22 12:16:59 \o/ 2024-05-22 12:16:59 Oh. Forgot that was just in edge before. :o 2024-05-22 12:19:00 \o/ 2024-05-22 12:20:25 \o/ 2024-05-22 12:21:38 Thanks to all the maintainers, it's such a huge amount of work to get here every time, and you still continue managing!! 2024-05-22 12:28:25 ACTION upgraded. Rebooting ... 2024-05-22 12:32:07 Upgrade successful \o/ 2024-05-22 12:41:13 I wonder if I can get help from everybody with the last checkbox: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16119 2024-05-22 12:41:16 \o/ 2024-05-22 12:43:16 Wait, > 2024-05-22 12:43:21 > Make sure pkgs.alpinelinux.org syncs the new release 2024-05-22 12:43:44 What does this mean? Potential I didn't get all the upgrades just now? 2024-05-22 12:45:52 \o/ 2024-05-22 12:46:56 Sofia: no, mirrors are up to date, it's just about indexing the new packages 2024-05-22 12:52:09 ACTION is unsure what this index involves if not the index apk just used to upgrade everything. 2024-05-22 12:52:24 it is the cache 2024-05-22 12:52:29 or it is the dns 2024-05-22 12:52:50 the apk index doesn't have file contents 2024-05-22 12:53:04 pkgs.a.o uses an sqlite database to hold all the info so it's faster to query 2024-05-22 12:53:18 because otherwise you'd have to go through every single .apk to find which package provides a file 2024-05-22 12:57:01 Ah, that index. I see. 2024-05-22 13:02:04 I'll set that up this evening (after work) 2024-05-22 13:32:38 Hehe, the irony, looking through the latest MRs, i see some that enable archs, and others that disable an arch 2024-05-22 13:41:42 congrats 2024-05-22 13:44:20 cely: quite a few enabling of the enabling MRs is me bulk uploading, now that 3.20 is out 2024-05-22 13:44:55 Although, while Cargo does support all of the archs now, quite a few of the libc-wrapping Rust crates do not 2024-05-22 13:50:24 What do you mean? 2024-05-22 13:51:58 is the lld-18.xxx pkgs missing? 2024-05-22 13:57:23 Actually, i think most of the issues with the Rust crates have been solved in their latest versions 2024-05-22 13:57:30 It's just a question of whether `cargo update`'s dependency resolution allows them to be updated to those versions 2024-05-22 13:58:03 If you look at some of the Loongarch MRs, that's what they've been doing 2024-05-22 13:58:20 `cargo update`ing the `libc` crate to a version with Loongarch support 2024-05-22 14:01:45 cely: oh, really? Didn't know that. That'd require an upstream PR, though 2024-05-22 14:02:23 For now my primary goal is mostly to purge the "limited by cargo" comment from aports, since I've incorrectly relied on it 2024-05-22 14:02:34 before being informed that it's outdated in this chat 2024-05-22 14:04:24 I don't think an upstream PR is _required_, while it'd be nice, what if upstream decides that they can't afford to support those rarer archs 2024-05-22 14:06:02 I don't think I'll be adding additional build steps, esp given that I'm not the maintainer 2024-05-22 14:06:17 the x86_64 ci runner seems offline 2024-05-22 14:06:52 To be honest, it'd be nice to have guidelines on building software made with the most popular languages 2024-05-22 14:07:34 Anyway, my point is, just like the Loongarch MRs, most of the time we can just run a `cargo update` and patch the "Cargo.lock" file 2024-05-22 14:08:38 For example, wherever to use `cargo` or `cargo-auditable`, how to set the env variables, and such 2024-05-22 14:08:49 dne: yes, will look in a bit 2024-05-22 14:09:01 cely: yeah, but I don't want to introduce patches to packages I don't own 2024-05-22 14:09:04 btw, on the topic of Loongarch MRs (and slightly derailing the conversation), perhaps we could move atools to alpine/infra/? 2024-05-22 14:09:29 we have a bunch of pending MRs to improve/fix lints 2024-05-22 14:09:35 and Leo doesn't seem very active 2024-05-22 14:10:00 ikke: 👍 2024-05-22 14:10:03 kaathewise: Fair enough :) 2024-05-22 14:10:21 dne: Do you have the py3-requests MR in mind? 2024-05-22 14:11:10 that's just what made me notice it, not in a hurry 2024-05-22 14:12:06 ptrc: https://gitlab.alpinelinux.org/alpine/infra/atools-go 2024-05-22 14:13:26 ooh, do you mind if i try and port the remaining rules? 2024-05-22 14:13:46 On a related note, if a RISC runner has been running for 1 hour with no progress, it's probably hanging, right? 2024-05-22 14:14:23 ptrc: not at all 2024-05-22 14:14:31 Oh, _literally the moment_ I sent this message it finished 2024-05-22 14:14:36 Finished `release` profile [optimized] target(s) in 27m 33s 2024-05-22 14:14:43 If you are talking about Rust aports, maybe 1 hour is still within expectation 2024-05-22 14:14:54 :) 2024-05-22 14:15:06 cely: yeah, turns out reqwest is pretty beefy 2024-05-22 14:16:25 ptrc: it should have everything from apkbuild-lint though 2024-05-22 14:17:19 I should remove the 'proof of concept' part from the description 2024-05-22 14:17:38 It's been running in CI for a couple of weeks now 2024-05-22 14:22:12 ohhh, so that's why it gave different errors than apkbuild-lint from old atools 2024-05-22 14:23:07 also, ah, the issues aren't "the rule isn't there", they're fixing said rules 2024-05-22 14:35:04 What issues are you referring to? 2024-05-22 14:35:26 Perhaps the ones in Leo/atools? 2024-05-22 15:53:55 nope, the two issues in atools-go 2024-05-22 15:58:56 a release! \o/ 2024-05-22 15:59:03 ACTION being late to the party 2024-05-22 16:00:07 ptrc: feel free to address them if you fancy 2024-05-22 16:02:34 now we can start recklessly beaking things in edge again 2024-05-22 16:17:08 omni: or in 3.20, apparently :p 2024-05-22 16:17:10 ( see #-commits ) 2024-05-22 16:34:32 nevermind, looks like lld-18.x is in progress, will wait https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61854 2024-05-22 16:36:34 Congrats everyone on the release! 2024-05-22 16:36:45 \o/ 2024-05-22 16:44:01 \o/ 2024-05-22 16:56:02 \o/ 2024-05-22 16:57:50 when the docker images get tagged? 2024-05-22 17:38:25 https://github.com/docker-library/official-images/pull/16801 2024-05-22 17:42:35 noice 2024-05-22 18:10:28 ouch, just entered on alpinelinux.org for download an iso and noticed the new release. Congrats! 2024-05-22 18:11:08 :) 2024-05-22 19:05:52 it's OK to have two changes in one MR? (package move to main and bumping package which need the dep)? 2024-05-22 19:06:34 yes 2024-05-22 19:42:21 aarch64 and armv7 builder stuck? 2024-05-22 19:48:39 builders or ci runners? 2024-05-22 19:49:28 ci-build 2024-05-22 19:49:59 they're busy 2024-05-22 19:50:04 For an hour?! 2024-05-22 19:50:17 and just the armv7 and aarch64 ones? 2024-05-22 19:50:29 the riscv64 one wasn't picked up until i stopped and started the job 2024-05-22 19:51:32 building chromium and perl rebuilds 2024-05-22 19:51:37 and yes for more then one hour 2024-05-22 19:53:25 Oh I see, thank you 2024-05-22 19:54:35 load average: 46.37, 43.49, 40.36 2024-05-22 19:54:40 on a vm that has 32 cores 2024-05-22 19:59:14 up, I have two pkgs waiting for them too 2024-05-22 20:01:16 (well, mesa3d 24.0.8 for stable and 24.1 for edge.. so one package :P ) 2024-05-22 20:14:52 btw. you MAY want to limit concurrent jobs on riscv runners. I'm seeing timeouts on job which sometimes manage to completly within 10 minutes https://gitlab.alpinelinux.org/okias/aports/-/jobs/1395222 2024-05-22 20:16:01 (not within this run - only one failure so far, but I seen the problem before too on riscv) 2024-05-22 21:21:26 Now that 3.20 is out, I'd like to see about tackling updating the LXQt packages. 2024-05-22 21:21:28 Biggest hurdle is libdbusmenu-lxqt, which would be a new package... It's a qt6 fork of libdbusmenu-qt. I'm wondering about the possibility of sending it straight to community and bypassing testing. 2024-05-22 21:21:52 https://git.alpinelinux.org/aports/tree/community/libdbusmenu-qt/APKBUILD 2024-05-22 21:21:54 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65828/diffs?commit_id=62866fac6edb4a1dbb7e07fd648baa31555db2ac 2024-05-22 21:22:07 it's a dependency for the 2.x/qt6 versions of LXQt stage IV packages (i.e. these: https://github.com/lxqt/lxqt/wiki/Building-from-source#iv---all-remaining-packages-in-any-order ) 2024-05-22 21:22:17 (also oops for posting in the wrong channel to begin with, go me!) 2024-05-22 21:32:07 git diff 3.19-stable..3.20-stable main community | rg " pkgname=" | wc -l 2024-05-22 21:32:10 4349 2024-05-22 21:33:03 git diff 3.19-stable..3.20-stable main community | rg " pkgname=|\-pkgver|\+pkgver" | less 2024-05-22 21:33:45 do you do anything similar to get a rough idea? 2024-05-23 00:49:01 zcrayfish: i think there is no problem in bypassing testing as it's a dependency of aports in community 2024-05-23 00:56:35 Though now that you've made me aware of that MR being a prerequisite to the LXQt upgrade, maybe i'll just merge it in the next half an hour or so 2024-05-23 00:57:26 Mark it as Draft or stop me here in the meantime if you have second thoughts 2024-05-23 01:50:07 Alright, i'll be making slight style modifications to !65828 and merging it, you may move it to community in a separate MR, or as part of the LXQt upgrade 2024-05-23 02:58:29 ls 2024-05-23 02:58:32 whoops 2024-05-23 04:07:24 celie: got distracted by the kiddo, thanks though! When he goes to sleep I'll poke around at it \o/ 2024-05-23 04:08:30 You're welcome 2024-05-23 05:48:28 dalias, turns out the lmdb people already knew this, even between 32 and 64 bit glibc sharing mutexes breaks :) 2024-05-23 08:49:29 libmount contains /lib/libmount.so.1.1.0 (file) and /lib/libmount.so.1 (symlink), but util-linux-dev provides /usr/lib/libmount.so (symlink) 2024-05-23 08:49:35 is this intentional/correct? 2024-05-23 08:52:39 Yes 2024-05-23 08:53:02 When you have util-linux-dev in makedepends, you can link -lmount 2024-05-23 08:53:53 and through that solink, it will find the soname, which will then be what the automatic dependency tracer adds to depends 2024-05-23 08:58:55 I was thinking of splitting mount-dev out of util-linux-dev. The latter has like two dozen dependencies which get pulled in A LOT of unecessary builds 2024-05-23 09:02:08 You'll then probably have to check every aport that uses util-linux-dev to see if you need to add/replace that with mount-dev 2024-05-23 09:04:41 anyone running alacritty on edge? I started to get 'segfault' on starting it but it doesn't look recently upgraded, maybe some dep... 2024-05-23 09:27:15 Alacritty edge on top of a stable system runs fine for me 2024-05-23 09:28:05 Someone in #alpine-linux said "mesa 24.01 broke firefox" 2024-05-23 09:28:12 So it might be the culprit here 2024-05-23 09:28:32 uhm.. let's try to downgrade 2024-05-23 09:33:16 yeah, it downgraded some packages from v3.20 and it works again 2024-05-23 09:38:24 I installed alacrity this week but before 3.20. runs fine for me 2024-05-23 09:39:52 it seems broken only on edge 2024-05-23 09:41:37 I tried to debug it but since it SIGSEGV on startup it needs something special for catch it 2024-05-23 10:44:20 Huh. Yeah I'm getting segfaults on qutebrowser. Seems to be a trend today. 2024-05-23 11:04:52 oh man... its time consuming to write documentation 2024-05-23 11:15:48 I tried using an llm for that at some point. Unfortunately didn't turn out well. 2024-05-23 11:20:38 Not surprising 2024-05-23 11:27:10 i have used it too 2024-05-23 11:27:20 it does maybe 50-60 % of the job 2024-05-23 11:27:26 it can give ideas how to write it 2024-05-23 11:27:50 but its time consuming to reformat it and fix it 2024-05-23 11:54:03 By the time I found an issue with mesa it had already been fixed. Morning is off to a pretty good start. *knocks on wood* 2024-05-23 12:23:28 fyi, dl-master is down atm, so no packages will be synced 2024-05-23 13:29:52 fluix: could you please take another look at !66336 2024-05-23 14:18:41 Are the riscv64 builders for edge and 3.20 stuck? 2024-05-23 14:23:04 hmm, the lxc containers are stopped 2024-05-23 14:24:01 I see the hosts were rebooted yesterday 2024-05-23 14:27:00 The 3-20 builder does not get an ip address from dhcp 2024-05-23 16:41:40 Hm well the mesa issue is back for me somehow. Did the fix get rolled back? 2024-05-23 16:42:04 no 2024-05-23 16:42:39 xulfer: maybe you are missing what triggers it into a bad state? 2024-05-23 16:44:16 Welp trying to get a dump out of it fixed it for now. I'll take what I can get. 2024-05-23 16:56:45 heisenbug 2024-05-23 16:57:17 I didn't have the issue with firefox before the last mesa upgrade (though, just tested it four a couple of seconds) 2024-05-23 17:03:49 midasi: yep, will try tonight or tomorrow. thanks for working on it :) 2024-05-23 17:22:13 The Neovim situation makes me want to yell at clouds 2024-05-23 17:23:17 Just stick to plain old vim :P 2024-05-23 17:23:22 no enshittification 2024-05-23 17:23:36 is this the lpeg thing i keep hearing about 2024-05-23 17:23:48 lpeg? 2024-05-23 17:24:01 then what is it, i'm curious 2024-05-23 17:24:26 ikke: idk i just heard a few people bumping neovim talking about it, haven't looked into it further 2024-05-23 17:24:27 neovim now having a hard dependency on treesitter-grammar* 2024-05-23 17:24:42 Neovim 0.10 now crashes because Lua syntax requires a tree sitter 2024-05-23 17:24:48 #16132 2024-05-23 17:24:50 ah i heard about that 2024-05-23 17:24:58 It's not even a hard dependency. It can be fixed with one `pcall` 2024-05-23 17:25:59 It's a hard dependency _right now_ :) 2024-05-23 17:26:28 is it just lua? 2024-05-23 17:26:32 yes 2024-05-23 17:26:34 for now 2024-05-23 17:26:35 i recall hearing it's for a couple other things as well 2024-05-23 17:26:38 3 languages, actually 2024-05-23 17:26:45 Lua, Vim doc help, and Type-something 2024-05-23 17:26:55 query 2024-05-23 17:26:57 treesitter query files 2024-05-23 17:27:07 i think 2024-05-23 17:27:14 https://gitlab.alpinelinux.org/alpine/aports/-/issues/16132#note_407152 2024-05-23 17:27:25 rip 2024-05-23 17:28:18 Luckily, it's easily patchable. Unbreaking Neovim should be allowed as a backport, right? 2024-05-23 17:28:47 yeah 2024-05-23 20:51:53 ptrc: Heya 2024-05-23 20:52:54 Could you a bit describe me f287fcd420abe9ce67e24422568a79eeab01f296 ? I haven't found anything relevant in mesa/mesa, the patch is very old, and I see you directly pushed (I could find MR in aports) 2024-05-23 20:54:43 maybe ask q66, who authored the patch 2024-05-23 20:55:27 is it because of this: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10988 ? 2024-05-23 20:56:30 Most likely 2024-05-23 20:59:33 So it's time for ptrc and/or q66 put some links and description to the patch. Opening mesa/mesa MR (even marked as "Draft: workaround for musl-libc...." would be also very nice I think. 2024-05-23 21:02:12 DavidHeidelberg: i am using that patch on gentoo, psykose showed it to me when I asked about segfaults with musl and mpv in #dri-devel 2024-05-23 21:02:30 tl;dr mesa 24.1.0 tries to use even more of the stack than before, which exceeds musl's limits; we didn't need the patch before that, but lately there's been some people here and in aports issues mentioning crashes 2024-05-23 21:02:46 basically the musl default stack size is much smaller than the glibc stack and it segfaults if it exceeds it 2024-05-23 21:02:51 yup 2024-05-23 21:02:55 hm? 2024-05-23 21:03:00 I get why the patch is there (..now), but I would love to have it documented 2024-05-23 21:03:00 ah 2024-05-23 21:03:05 also note for vulkan programs it needs to be fixed inside of the app and not mesa 2024-05-23 21:03:21 and also probably talk with Mesa devs, since you DONT want to carry something like that downstream. 2024-05-23 21:03:37 upstream response is "don't use musl for gaming" 2024-05-23 21:03:38 when every distro using musl-libc using that anyway, it can be as a build option or something in Mesa 2024-05-23 21:03:45 ptrc: where? 2024-05-23 21:03:58 the issue you linked yourself 2024-05-23 21:04:04 Do I look like I'm saying that? I'm playing games on musl-libc 2024-05-23 21:04:19 ptrc: that's one dev who doesn't give a shit about musl-libc, and? 2024-05-23 21:04:36 also I don't see any MR 2024-05-23 21:05:02 so, no-one rejected any solution, which would help integrate Mesa with musl-libc so it would work properly 2024-05-23 21:05:30 you mentioned talking with mesa devs, so that's why i'm mentioning this 2024-05-23 21:05:48 DavidHeidelberg: here is one issue related to this, but I dont recall if the issue for opengl was also made? https://gitlab.freedesktop.org/mesa/mesa/-/issues/10488 2024-05-23 21:05:53 i'm not sure if the patch would be up to upstream's standards, it looks pretty hacky 2024-05-23 21:06:13 ptrc: you can still drop it as a starter for the discussion how to do it properly 2024-05-23 21:06:15 DavidHeidelberg: you should understand that submitting patches for fixing stuff on musl is often an uphill battle so it's perfectly reasonable not to want to be pressured into submitting them 2024-05-23 21:06:25 it's not exactly a very motivating thing to do 2024-05-23 21:06:40 yeah, people wasn't extremely cheering when I added Alpine into CI... and it's there. 2024-05-23 21:07:36 we build for f** Android or Windows, I don't see reason to not have properly non-patched Mesa for Linux based on musl-libc 2024-05-23 21:08:07 it especially makes me want to submit patches when there's always some asshat like that guy 2024-05-23 21:08:41 q66: just get their perspective, they care about Ubuntu, SteamOS, and that's why pays their bills... 2024-05-23 21:08:49 no 2024-05-23 21:08:57 you shouldn't expect everyone will care about your usecase 2024-05-23 21:09:03 i don't 2024-05-23 21:09:06 it's one thing to care, it's another to dismiss 2024-05-23 21:09:14 well, thanks for being a part of nice community 2024-05-23 21:09:14 i expect them not to be outright dismissive 2024-05-23 21:09:22 and assume "gaming" when it wasn't even mentioned 2024-05-23 21:10:08 give yourself a slap and work on stuff you care instead of saying how people are mean. You have person with commit access talking to you now. 2024-05-23 21:10:23 ... who also cares. 2024-05-23 21:11:33 wow dude you so nailed it 2024-05-23 21:12:17 Please remain respectful to eachother 2024-05-23 21:13:24 DavidHeidelberg: fwiw i appreciate mesa devs looking at this, watching graphics channels for a long time its obvious that a lot of people are busy with other priorities and dont have much time 2024-05-23 21:13:28 please do consider that we're doing quite a bit of stuff besides Mesa-related things, and (i'd say) the issue has already been properly reported = there could be some expectation that upstream would pick it up at some point and apply a proper fix 2024-05-23 21:14:36 yes, but if you prepare patch, you trying to do it properly. So reference bugs, write the commit msg so people will understand, discuss... even with people which doesn't share your opinion. I know it costs a time and lot of effort... 2024-05-23 21:14:44 but see the open source... that's how we got here. 2024-05-23 21:14:56 Diplomacy is a important part how to progress. 2024-05-23 21:15:22 Sorry for maybe sounding too harsh, but I wanted to stay on technical level topic. 2024-05-23 21:15:35 you still need to understand that people like me and ptrc deal with a huge amount of different software and there isn't enough time and motivation to submit everything outright while at the same time dealing with dismissive people throwing obstacles in the way 2024-05-23 21:15:51 so yea some things linger downstream a while 2024-05-23 21:15:52 big deal 2024-05-23 21:15:59 q66: I understand you, don't worry :) 2024-05-23 21:16:21 Nobody prevents you from submitting the patch yourself. 2024-05-23 21:16:29 there is that too 2024-05-23 21:16:29 I just wanted to get the stuff addressed properly and in benefit of all... mostly musl-libc based linuxes 2024-05-23 21:17:25 Ermine: I cannot fight ALL battles, I'm trying to help where I can. Thou my knowledge of how musl-libc stack behaves isn't great, so it's better if the author or someone with higher level submits 2024-05-23 21:17:34 it's as q66 said :) 2024-05-23 21:17:44 DavidHeidelberg: https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread-stack-size 2024-05-23 21:18:27 ikke: this part look good, right? "Since 1.1.21, musl supports increasing the default thread stack size via the PT_GNU_STACK program header, which can be set at link time via -Wl,-z,stack-size=N." 2024-05-23 21:18:49 IIRC that works for the main thread, but not threads created later 2024-05-23 21:18:59 ptrc: nah, that's for threads 2024-05-23 21:19:07 disregard main thread, you cannot control the stack size of that from within the program 2024-05-23 21:19:08 You're trying to convince people who fought a myriad of such battles to engange in yet another one. 2024-05-23 21:19:12 because the kernel sets it up for you 2024-05-23 21:19:24 and it's always like 8M 2024-05-23 21:19:29 ah, huh 2024-05-23 21:19:40 the way the tag works is basically like 2024-05-23 21:19:45 it's embedded in the executable or dso 2024-05-23 21:19:53 the musl dynamic linker reads them all when opening the dsos 2024-05-23 21:20:04 then picks the largest one and uses that as default stack size for threads 2024-05-23 21:20:23 that said, it's not a good option for mesa 2024-05-23 21:20:49 unless you want any program linked to libgl/libgbm/whatever common lib mesa provides to run with a big stacksize for all its threads 2024-05-23 21:20:53 it's a bit of a big hammer 2024-05-23 21:20:53 Ermine: sure, but I can help here. I know it's hard battle, I did upstreamed some patches for musl-libc myself ;-) 2024-05-23 21:21:12 so setting the size for pthreads explicitly is a better idea 2024-05-23 21:21:32 tbh i'd probably also drop the #ifdef __GLIBC__, and just always set the thread stacksize 2024-05-23 21:21:34 that is how it was fixed in RMG, set the stacksize for the specific thread 2024-05-23 21:21:44 upstreams often don't like that but there is no good reason why 2024-05-23 21:21:51 if the program needs a large stack, it should ask for one 2024-05-23 21:22:30 https://github.com/Rosalie241/RMG/commit/b86f520ee72010a5023d3ab6f2b6d33ee8c08e27 2024-05-23 21:24:17 the win32 ifdef is probably superfluous too 2024-05-23 21:24:21 as i said, just always set :) 2024-05-23 21:24:34 but yea i've seen upstreams be opposed to that for vague reasons 2024-05-23 21:25:37 tbf i've mostly had issues with upstreams simply not having enough people to properly test incoming patches 2024-05-23 21:25:50 yea, i wasn't sure about the win32 ifdef, but I cant test windows so :shrug: 2024-05-23 21:26:21 for the Mesa3D part, I built for that Alpine CI (except another selling point, which was failing our CI fast and container size) 2024-05-23 21:26:30 orbea: windows thread stacksize is 1M iirc 2024-05-23 21:26:37 mac is 512k 2024-05-23 21:31:01 btw. the 1M could be safe option, mesa is not very often well tested on Mac 2024-05-23 21:40:18 ptrc: thanks for the comment :) 2024-05-23 21:49:07 cely: When you get a chance, what do you think about this draft? Thanks https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66455 2024-05-23 22:23:17 btw. could you give me a hand here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29054 please? when doing build in our CI with full-lto, I'm getting failure here. So this is a hack, how to do it, so compiler doesn't complain.. but I need somehow detect the musl or something which needs this different definition 2024-05-23 22:29:28 "The solution is obvious, musl should increase its default stack size." 2024-05-23 22:29:42 and then you wonder why we're not exactly motivated to work with upstreams :') 2024-05-23 22:30:20 ... yeah.. I know, sometimes I get... nicely said "very upset" about reactions 2024-05-23 22:31:03 thou as a old mage within discussions, I can say I mainly don't care. I just continue doing what seems right to me 2024-05-23 22:31:34 that's why I added Marek, because continuing with Venemo won't lead to anywhere :P 2024-05-23 22:32:49 I though would be interesting have test, which utilize stack in the way how the NIR does it... then it would nicely failed on Alpine in CI, but after it gets fixed, it's probably not needed (I guess?) 2024-05-23 22:32:54 *unittest 2024-05-23 22:36:28 ptrc: Venemo has been reasonable in the past ime, I dont think it would be considered offensive to argue alternative approaches as DavidHeidelberg already did :) 2024-05-23 22:38:38 orbea: to be more precise, I meant more within context of this discussion :P I think Venemo sees musl-libc as something underrepresented and early-stage I guess (at least it feel like it) 2024-05-23 22:43:42 probably not entirely wrong, there are significantly more glibc users, it makes sense to prioritize them. Regardless I think it makes a codebase more robust be tested against alternative libc implementations :) 2024-05-23 22:45:49 glibc is not always optimal in its behavior and its good to have competition, gcc and clang helped each other improve for example 2024-05-23 22:46:22 it's one thing to approach same problem in 2 different ways 2024-05-23 22:46:26 musl and glibc are not that 2024-05-23 22:46:26 orbea: i feel like "the libc should change its defaults to accomodate us" is quite a silly response nonetheless 2024-05-23 22:49:51 yea, i disagree with that response too, but can just say that instead of being discouraged. I've dealt with some truly hostile upstreams before, mesa is pretty good for such a large project with busy devs 2024-05-23 23:24:51 Haha, my bets on Marek was good bet :P 2024-05-23 23:25:24 > Feel free to create a MR that allocates linkage_info dynamically. 2024-05-23 23:51:12 something seems wrong in a subtle way with riscv64 2024-05-23 23:51:36 https://pkgs.alpinelinux.org/package/edge/main/riscv64/sqlite-tcl 2024-05-23 23:51:37 https://pkgs.alpinelinux.org/package/edge/main/x86_64/sqlite-tcl 2024-05-23 23:51:44 the origin for the riscv64 package is sqlite-tcl 2024-05-23 23:51:50 even though it should be like in x86_64, sqlite-tools 2024-05-23 23:52:30 did it not pick up the latest changes? 2024-05-23 23:53:19 ohhhh nevermind it's been stuck on community and didn't get the chance to build master 2024-05-24 00:01:25 turns out the assumption "an APKBUILD for a package origin will exist" is not quite correct in some cases.. 2024-05-24 00:04:08 I need a hand with !64868 to merge it. Could somebody please do that for me? 2024-05-24 00:04:55 (Also !65925 and !65927, please) 2024-05-24 00:12:30 Thank you! 2024-05-24 00:48:24 zcrayfish: your riscv64 CI job timed out because the timeout is by default 1 hour, you have to increase that in the settings page 2024-05-24 00:50:47 I'll see if I can find the option and rerun the riscv64 job 2024-05-24 00:53:31 Skimming through the changes, they look alright, though someone will have to actually try out the CI artifacts to be sure they work out in practice 2024-05-24 00:56:53 but as 3.20 was just branched, if you think nothing is broken too badly, maybe it can just be merged, though there is issue of maintainer approval (but i don't think we waited for that during the last upgrades) 2024-05-24 00:58:11 I'll assign it to the maintainer, and maybe we can wait a few days to see if there's a response 2024-05-24 00:58:24 That sounds like a good idea, I'd rather play it safe. 2024-05-24 00:58:48 I built these packages locally and use them as a daily driver as well; so if there's some kind of issue, it should definitely pop up by then 2024-05-24 00:59:03 That's good 2024-05-24 00:59:53 Since that's the case i wouldn't mind getting the changes in after waiting a few days 2024-05-24 01:00:57 Anyway, lxqt-themes will need its pkgrel reset to 0 2024-05-24 01:02:06 and i'm a bit interested in what errors you see when Perl isn't included in makedepends 2024-05-24 01:02:31 dang, good catch on the pkgrel. 2024-05-24 01:02:37 (just curious why it's needed with this upgrade) 2024-05-24 01:02:39 I'll try to pastebin the perl stuff in a moment. 2024-05-24 01:02:54 Sure, thanks 2024-05-24 01:06:45 https://tpaste.us/rj0j 2024-05-24 01:06:56 There will be a Perl upgrade pretty soon, so maybe the LXQt upgrade can be coordinated with that to make sure it still builds with the new Perl (i'm not expecting such breaking changes though, so maybe it doesn't matter so much) 2024-05-24 01:13:03 Seems like the Perl script it wants to run is this: https://github.com/lxqt/lxqt-build-tools/blob/master/cmake/modules/LXQtTranslateDesktopYaml.pl 2024-05-24 01:18:51 I wonder if Perl should be made a runtime dependency of lxqt-build-tools instead of being added to the other aports 2024-05-24 01:21:03 I think that would be reasonable 2024-05-24 01:24:39 Looking at the build log for lxqt-build-tools: https://build.alpinelinux.org/buildlogs/build-3-20-x86_64/community/lxqt-build-tools/lxqt-build-tools-0.13.0-r0.log it seems something is already pulling in Perl as a dependency during build time 2024-05-24 01:26:18 Perhaps it's https://git.alpinelinux.org/aports/tree/community/qt5-qtbase/APKBUILD 2024-05-24 01:26:25 which has Perl in depends_dev 2024-05-24 01:26:51 qt6-qtbase has Perl in makedepends instead 2024-05-24 01:27:33 ah. the qt6 change strikes again. 2024-05-24 01:27:37 That could explain why Perl needs to be added to makedepends of LXQt aports when switching from qt5-qtbase-dev to qt6-qtbase-dev 2024-05-24 01:29:19 Unless you can find some other LXQt aport besides lxqt-build-tools with Perl scripts, i'd say it's good to add to depends of lxqt-build-tools 2024-05-24 01:42:36 Ok, i've assigned it, let's wait a few days, and if there's no reply then i think it can just be merged, considering that you're already using LXQt 2 as daily driver 2024-05-24 01:45:21 sounds like a plan. Much appreciated :) 2024-05-24 01:51:51 You're welcome 2024-05-24 07:38:25 hi, regard the issue !16142 I also participate in giving it the suggestion, in order to learn within the report, is it applicable to have a post-upgrade message for such scenarios? 2024-05-24 07:38:38 that is no the issue ☠️ 2024-05-24 07:56:49 #16142 2024-05-24 07:58:51 thanks I was about to try with # 2024-05-24 08:00:52 and btw, do we have defined somewhere (or thinking in have) about the /usr/share/webapps ? because I seen lots of apps using (that is where I gave the suggestion) and I also personally think it is amazing 2024-05-24 08:02:06 i think a post-upgrade is useless because the user should always review the .apknew files when changing packaged files 2024-05-24 08:03:35 but for other changes probably requiring user interaction I'd but it to the post-upgrade 2024-05-24 08:07:07 hier(7) shows a typical unix filesystem hierachy which is a nice overview where to put stuff to (altough i did not find /usr/share/webapps there?) 2024-05-24 08:13:22 looks like a lot of people are affected by the aws-cli removal, but still nothing we could do than wait for upstream 2024-05-24 08:15:01 Ahuh 2024-05-24 08:18:28 DavidHeidelberg: I think you are right. https://gitlab.freedesktop.org/mesa/mesa/-/issues/10988#note_2425832 needs to be fixed and it needs to be fixed upstream. 2024-05-24 08:19:02 if mesa would have been an application, i would have been okish to increase the stack size. but mesa is a *library* 2024-05-24 08:19:55 also, fixing the issue may increase performance as well for upstream 2024-05-24 08:21:05 i have seen it before. allocating (smaller) vars on stack instead of malloc does increase performance. so people end up putting everythign on stack. also big blocks 2024-05-24 08:21:54 but it also results in cpu cache misses 2024-05-24 08:22:23 so the things that actually needs the stack (push/pop registers, return address from function calls etc) gets slower 2024-05-24 08:22:43 and in the end it all becomes slower as a result 2024-05-24 08:23:26 (all the above is just my beliefs, without any scientific evidence) 2024-05-24 08:23:53 but i have seen that moving big allocs from stack to malloc, increase performance 2024-05-24 08:26:00 looks like a lot of people are affected by the aws-cli removal, but still nothing we could do than wait for upstream > I saw that too 2024-05-24 08:26:19 the aport is without maintainer but someone provided two patches 2024-05-24 08:32:38 yes, aws-cli is a mess to work with 2024-05-24 08:32:50 i may have some time to look into that 2024-05-24 08:33:55 they have opened MR but seems dont care enough, idk 😅 2024-05-24 09:11:12 there are so many patches to take care of, i hate it 2024-05-24 09:13:31 the aur guy said he applied two, isnt enough? 2024-05-24 09:28:01 no apparently not 2024-05-24 09:28:23 the AUR package also has a lot of other patches applied 2024-05-24 09:29:05 uh... Im not sure what change that much about python 3.12 2024-05-24 09:29:54 you need the two botocore batches too for 3.12 so it's like 4 total pretty sure 2024-05-24 09:30:07 and then more patches if you want to fix the tests 2024-05-24 09:30:39 ACTION !check 2024-05-24 09:31:04 i did that back when i maintained it once and the failed checks actually said that it was broken :P 2024-05-24 09:31:14 they are useful if you actually spend the time 2024-05-24 09:33:56 indeed, I have recently enabled some tests in some aports, pretty nice 2024-05-24 10:03:25 yeah, I think !check is the last of the last resort 2024-05-24 10:03:52 i usually prefer to disable the package rather than disable the tests 2024-05-24 10:04:01 better to not ship anything than ship broken 2024-05-24 10:16:17 I wonder if somebody who had meson segfaulting could test if this patch solves it? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29375 2024-05-24 10:17:47 I'd rather not allocate 8M stack for mesa as in f287fcd420abe9ce67e24422568a79eeab01f296 2024-05-24 10:18:30 i think android has 1 or 2MB default thread stack size, and windows has 1MB 2024-05-24 10:18:53 8m just matches glibc so it's the safe default 2024-05-24 10:19:02 i usually pick 2 if i'm not upstreaming it though 2024-05-24 10:19:03 yeah, i know 2024-05-24 10:19:16 i think also macos uses 8M nowadays 2024-05-24 10:19:38 heh wheredya see that 2024-05-24 10:19:40 would surprise me a bit 2024-05-24 10:20:00 i have just a vauge memory of that 2024-05-24 10:21:06 https://developer.apple.com/library/archive/qa/qa1419/_index.html 2024-05-24 10:21:17 it used to be 512k 2024-05-24 10:23:25 i've seen the 512 before yea 2024-05-24 10:26:35 ncopa: patch works for me 2024-05-24 10:26:58 first crashed it and saw https://img.ayaya.dev/GOxMU9rSKp1r and now can't repro it anymore 2024-05-24 10:27:01 so looks ok 2024-05-24 10:31:00 awesome! care to comment that on https://gitlab.freedesktop.org/mesa/mesa/-/issues/10988 ? 2024-05-24 10:31:04 thanks! 2024-05-24 10:31:47 i'll comment on the mr instead but sure 2024-05-24 11:02:41 ptrc: I replaced the mesa patch in 62bf7796809f2ffee4dda963c20dc8ea744ffde2 2024-05-24 11:13:41 oh, thanks :) could you also replace it in 3.20? 2024-05-24 11:14:13 wait for merge first 2024-05-24 11:53:40 fossdd, I want say sorry If i caused mess with the suggestion on jellyfin-web 😅 2024-05-24 11:54:28 dont worry, was a good suggestion 2024-05-24 13:04:19 Is libreoffice calc on edge hanging for anyone else on start? Does not get past the splash screen 2024-05-24 13:09:42 alright, i got aws-cli working with only 6 tests failing. i'll try to continue if i get back home 2024-05-24 13:12:57 fossdd: you are awesome! 2024-05-24 13:14:29 thanks haha 2024-05-24 13:15:02 (1/2) Installing libreoffice-calc (7.6.7.2-r0) 2024-05-24 13:15:06 seems to work for me 2024-05-24 13:16:11 Terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' 2024-05-24 13:19:00 ncopa: what jre do you have installed? 2024-05-24 13:22:47 none apparently 2024-05-24 13:26:16 Hmm, ok 2024-05-24 13:27:38 I guess that's just a warning that happens if it's not installed, the exception happens whether its installed or not 2024-05-24 16:00:21 Any chance I could get !65438 merged now that 3.20 is live? 2024-05-24 16:12:55 ncopa: thank you! 2024-05-24 16:13:37 I also have some opened mr that I think was waiting for 3.20 but is also testing so not sure this affect 😅 2024-05-24 16:33:36 ncopa: thank you very much for the mesa stack size fix <3 2024-05-24 16:34:47 The packages between the arches are unsynced and some runners have network issues 2024-05-24 16:35:10 I think these issues might be related 2024-05-24 16:35:49 re https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66496: anyone know if a file isn't in source and then gets removed, does the package need a pkgrel bump? 2024-05-24 16:35:55 now pkgs.alpinelinux.org is unreachable it seems 2024-05-24 16:36:07 or very very slow. Maybe package loss issues in the DC. 2024-05-24 16:36:28 package loss? pkgs.alpinelinux.org is just generally slow sometimes 2024-05-24 16:36:54 yeah but not just slow but no reply for many many seconds 2024-05-24 16:37:03 right now grommunio-gromox is unsynced between the arches: grommunio-gromox 2024-05-24 16:37:05 https://pkgs.alpinelinux.org/packages?name=grommunio-gromox 2024-05-24 16:38:14 isn't that because it just takes time for packages to actually be built? https://build.alpinelinux.org/ 2024-05-24 16:39:08 yes and no. usually the builders for these packages are equally fast 2024-05-24 16:39:16 well, in the order of magnitude at least 2024-05-24 16:40:56 fluix, I see now that the x86_64 builder was busy with chromium 2024-05-24 16:41:22 where do you see that btw? 2024-05-24 16:41:49 alpine-commits has status messages from the builders 2024-05-24 16:41:57 ah thanks 2024-05-24 16:42:07 18:39 CEST: edge/main/x86_64: uploaded 2024-05-24 16:52:37 Funny companies scraping cgit.a.o 2024-05-24 16:52:47 well, here's some http 429 for you 2024-05-24 16:54:59 I prefer 418 2024-05-24 16:56:46 Sadly that's only valid for HTCPCP 2024-05-24 17:03:18 restarting gitlab for security updates 2024-05-24 17:07:09 RE discussion in #alpine-commits: to fix the issue we need these MRs due to dependency hell: could somebody then please merge these MRs: !could somebody then please merge these MRs: !65923 then !66498 2024-05-24 17:07:14 argh 2024-05-24 17:07:33 !65923 and !66498 2024-05-24 17:07:49 gitlab is restarting 2024-05-24 17:07:52 yeah 2024-05-24 17:07:57 I was arghing about my double copy paste 2024-05-24 17:07:58 ah 2024-05-24 17:10:28 gitlab is back 2024-05-24 17:10:55 !65923 !66498 2024-05-24 17:11:48 Good Gateway 2024-05-24 17:15:03 I woke up, looked at Mesa discussion and found fix was merged. Thank you a lot guys :) 2024-05-24 17:15:14 s/guys/all/ :P 2024-05-24 17:16:11 feel free to ping me if something like: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21291 would be beneficial to you or it's more like cosmetics 2024-05-24 17:31:55 DavidHeidelberg: fwiw there is also #musl-distros @ OFTC, they might also have good feedback? 2024-05-24 17:45:05 orbea: thanks 2024-05-24 17:45:15 btw. https://gitlab.alpinelinux.org/okias/aports/-/jobs/1397314 aarch64/armv7 seems to be dead 2024-05-24 18:20:06 !66492 riscv builder is too slow 2024-05-24 18:28:18 Thermi: It's not that we can magically make it any faster 2024-05-24 18:28:32 not? 2024-05-24 18:28:35 sad 2024-05-24 18:29:10 Just wanted to point out that it's a problem. Maybe it's new, maybe it's old. 2024-05-24 18:29:33 It's known that riscv is slower as the other arches 2024-05-24 18:29:45 We just have to deal with it 2024-05-24 18:29:52 You can increase the timeout on your repo 2024-05-24 18:30:31 that's a good idea, thank you 2024-05-24 18:30:40 I did not consider that it runs in the context of my own repo 2024-05-24 18:40:37 That's under the CI/CD settings somewhere, right? 2024-05-24 18:40:44 I didn't get around to increasing mine last night 2024-05-24 18:41:15 yes 2024-05-24 18:41:56 CI/CD -> General Pipelines > Timeout 2024-05-24 18:43:15 thanks! 2024-05-24 19:27:58 hey guys, i was wondering if there is any interest in making alpine use squashfs + overlayfs instead of the apkovl it currently uses? 2024-05-24 19:28:28 i think i brought this up before but at the time i hadn't been able to do it 2024-05-24 19:39:53 i ask because i have done it now and maybe could help with a possible change to squashfs 2024-05-24 19:42:20 rdbo: see https://gitlab.alpinelinux.org/ptrcnull/alpine-live 2024-05-24 19:42:48 having some images as a side project, nothing official tho 2024-05-24 20:06:59 ptrc: oh yeah, i did something similar. i made a distro based from alpine using squashfs + overlayfs (which i'm using rn), and i was thinking that maybe the official project could benefit from using that instead of apk overlay 2024-05-24 20:07:33 since it will cut down memory usage and time to boot (no need to install packages on memory) 2024-05-24 20:11:28 also for the installer, it could just copy the readonly mounted squashfs into the new root 2024-05-24 20:11:42 (at least that's what i did in my project) 2024-05-24 20:37:02 im gonna be afk for a week or two. have a nice weekend everyone! 2024-05-24 20:37:04 you rock! 2024-05-24 20:38:42 ncopa: Enjoy your well deserved time off 2024-05-24 20:38:58 enjoy 2024-05-24 20:41:38 ncopa: I replied to that e-mail from Klatt 2024-05-24 20:49:46 Take it easy ncopa! 2024-05-24 21:07:56 ncopa: enjoy! 2024-05-24 21:34:24 ncopa: :* 2024-05-24 21:56:14 enjoy it ncopa!! 2024-05-25 06:55:35 what's up with loongarch? is it proceeding and we should accept patches for it before even CI builders are up or not? 2024-05-25 06:57:12 Yes, we have been accepting patches for it 2024-05-25 06:57:14 fluix: yes 2024-05-25 06:57:59 The Loongarch people will take care of making sure it works on that arch even though CI for it is not set up 2024-05-25 06:58:24 And we're in the process to setup builders / CI 2024-05-25 07:00:10 oki, thx 2024-05-25 07:00:15 nn 2024-05-25 10:49:02 should other aports be upgraded to 18.1.6 now that lld is? 2024-05-25 10:55:15 main/{scudo-malloc,llvm-runtimes,libclc,wasi-compiler-rt,wasi-libcxx} and community/{lldb,openmp} 2024-05-25 10:58:41 !66404 !66405 2024-05-25 10:58:59 but they don't cover all of the above 2024-05-25 11:03:32 got aws-cli working with all tests, see !66481 2024-05-25 11:03:40 i'll be backporting it for 3.20 2024-05-25 11:06:21 btw is there a way i could get permissions for closing issues on docker-alpine? 2024-05-25 11:06:28 there are a lot of issues i wanted to work on 2024-05-25 11:43:56 aws-cli for 3.20: !66562 2024-05-25 15:00:45 timlegge: i noticed that perl-xml-easy uses a Unicode function removed in Perl 5.38, so i'll be applying https://sources.debian.org/patches/libxml-easy-perl/0.0011-4/uvuni_to_utf8_flags.patch to fix that in my Perl 5.40 rebuild 2024-05-25 15:02:53 Oops, added an extra zero, the correct link is https://sources.debian.org/patches/libxml-easy-perl/0.011-4/uvuni_to_utf8_flags.patch 2024-05-26 03:22:41 I just realized that testing/py3-pyinstaller has a Contributor line but no Maintainer line 2024-05-26 11:34:47 cely: looks fine 2024-05-26 12:41:56 Ok :) 2024-05-26 12:51:01 what's the convention for handling package names when upstream renames a series of packages? amtk is now libgedit-amtk and tepl is libgedit-tepl upstream 2024-05-26 12:53:19 looking at upgrading tepl, per !54977 it now also depends on two other libgedit-* libs not yet packaged 2024-05-26 12:56:21 this is in order to upgrade gedit. could take maintainership of the gedit + libgedit-* if no one else wants? would need to know what names to send the other two new lib packages 2024-05-26 12:58:32 Does libgedit-amtk still use the same soname? 2024-05-26 12:58:44 is it okay to rename to follow upstream name? it looks like gnome-latex is the only not-gedit package that depends on tepl 2024-05-26 12:59:54 will have to double-check ... only recalled that newer gedit wouldn't build with amtk as is, it looks for libgedit-amtk-5 2024-05-26 13:00:19 which would make me guess the soname may have changed 2024-05-26 13:00:33 let me check my local build 2024-05-26 13:02:09 yes, packages to /usr/lib/libgedit-amtk-5.so.0 2024-05-26 13:03:04 current amtk in the repo is /usr/lib/libamtk-5.so.0 2024-05-26 13:04:35 they were polite to rename it :P 2024-05-26 13:04:39 should be trivial 2024-05-26 13:05:10 alice: great to see you back ^^ 2024-05-26 13:05:20 jus chattin 2024-05-26 13:05:45 chatting is still a welcome sight ^^ 2024-05-26 13:06:20 but yes, hopefully! tested only on x86_64, but seems okay 2024-05-26 13:07:45 only thing is to update gnome-latex as well 2024-05-26 13:44:33 the two new libs would be in testing, but tepl is in community, is there a way to expedite moving the new libs to community or should tepl (and gedit) be moved back to testing? 2024-05-26 13:45:54 (gnome-latex is still in testing so there should be no issue there) 2024-05-26 13:51:31 If the new libs are dependencies of something in community, then they may be added straight to community 2024-05-26 13:52:20 but if you're going to take maintainership of the new libs + gedit, then it's up to you whether you want to move them back to testing if you feel they need more testing 2024-05-26 13:53:16 mio: ah did you think you have to rename tepl to libgedit-tepl? they're separate libs 2024-05-26 13:54:02 alice: are they hard forks? thought upstream just said they renamed it 2024-05-26 13:54:26 it's a hard fork yes 2024-05-26 13:54:31 that's why the name is different 2024-05-26 13:54:37 gnome-latex did want tepl rather than libgedit-tepl, but seems to be content with libgedit-tepl as well 2024-05-26 13:54:42 original tepl/amtk still exists 2024-05-26 13:55:00 i would not trust the changes 2024-05-26 13:56:00 ah, thanks for letting me know ... gedit looks for new soname though, so separate packages or ...? 2024-05-26 13:56:38 cely: thanks for the explanation ^^ 2024-05-26 13:56:48 yea separate 2024-05-26 13:59:34 okay, no problem. will treat them all as new libs and reset them all to testing, just in case 2024-05-26 13:59:58 will leave gnome-latex on the other tepl 2024-05-26 14:02:48 thanks for catching that ^^ 2024-05-26 14:09:53 alice: one more thing ^^" when you mentioned not trusting the changes, what did you mean? 2024-05-26 14:11:38 it's a fork for gedit only so i doubt there is any care for if it works or not with anything else 2024-05-26 14:17:29 understood, thanks 2024-05-26 14:38:57 interestingly, latest tepl (not libgedit-tepl) is looking for libgedit-gtksourceview rather than gtksourceview 2024-05-26 14:41:17 ah hm 2024-05-26 14:41:36 i guess it is just renamed 2024-05-26 14:41:54 i might be wrong then and you want to just replace old tepl and whatnot then 2024-05-26 14:42:04 think that and the info page on the libgedit society repos is what confused me initially 2024-05-26 14:42:13 yea i think you're right 2024-05-26 14:42:19 but libgedit-sourceview is definitely separate 2024-05-26 14:45:11 okay, maybe better to not remove old ones and ship libgedit-* versions alongside the existing ones? 2024-05-26 14:45:52 the existing ones have no maintainer, would be easier then to see which ones have no dependents 2024-05-26 14:46:19 but noted for gtksourceview, will leave separate versions of that 2024-05-26 14:48:16 and potentially remove the orphaned ones except gtksourceview 2024-05-26 14:50:45 though aside from gtksourceview, should be okay to direct replace. more just to be safe 2024-05-26 17:22:15 weird decision to mention yq rename on release post but not the grub issue? 2024-05-26 18:06:56 panekj: grub issue was resolved 2024-05-26 18:07:03 I forgot to update the wiki 2024-05-26 18:43:59 good evening 2024-05-26 18:44:11 Could somebody please hit automerge on this MR? !66493 2024-05-26 18:44:50 I think this MR would also profit from it: 66498 2024-05-26 18:44:52 !66498 2024-05-26 18:45:30 ikke: 👍 2024-05-27 01:41:04 somebody please remove this tar from distfiles: https://distfiles.alpinelinux.org/distfiles/edge/py3-requests-gssapi-1.3.0.tar.gz 2024-05-27 01:52:32 I'll just rename the file in the APKBUILD 2024-05-27 01:52:36 Please be more careful next time 2024-05-27 01:54:21 I had another concern while looking through your MRs a few days ago, but i've forgotten what it was now 2024-05-27 03:59:10 mio: Regarding your gedit MR, i think you should use `xvfb-run -a` instead of a plain `xvfb-run`, and you're running `meson compile` under xvfb-run instead of `meson test` 2024-05-27 04:00:13 cely: thanks for the feedback, fixing 2024-05-27 04:00:19 Also, i don't think you need to include the LGPL licenses in the .apk files 2024-05-27 04:00:23 Only MIT needs that 2024-05-27 04:00:43 At least, MIT is what we've determined needs that, for now 2024-05-27 04:02:42 ah okay ... thought it applied to most copyleft licenses with some form of "include notice of license with distributed files". can remove, sure 2024-05-27 05:13:21 cely: fixed, thanks for review and merge on the other package 2024-05-27 05:19:47 No problem 2024-05-27 05:20:40 ^^ 2024-05-27 05:58:38 iirc it would be any license with the copyright statement 2024-05-27 05:58:48 though i'm not sure if anything besides MIT uses one 2024-05-27 05:59:05 BSD? 2024-05-27 05:59:52 (oops) 2024-05-27 05:59:57 ACTION closes pandora's box 2024-05-27 07:26:28 Ariadne: any chance you could review https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66400? 2024-05-27 07:59:05 next time just use !66400 and bot would show link for you :) 2024-05-27 08:48:37 ey ptrc , would you like to move 'nvtop' to 'community'? I use it on my desktop and would like to use also on some servers without pinning from testing :) 2024-05-27 08:57:51 qaqland: I don't see a need when I already had the page open and could way quicker just copy paste it 🤷 2024-05-27 10:09:23 ikke: I'm back at aports-qa-bot. Do you think you want help with the maintenance of that thing? e.g: merging auto-updates and similar? 2024-05-27 10:24:52 PabloCorreaGomez[m]: Sure, yes, that's fine. I've made you developer so that you can merge MRs 2024-05-27 10:26:03 ikke: should I add you as reviewer of MRs I send so I'm not making anything stupid? 2024-05-27 10:26:21 Yeah, that's alright 2024-05-27 10:28:25 ikke: perfect, thanks! Let's see if this week I finally get to implement the "maintainer-feedback" thing I've been procrastinating for so long 2024-05-27 10:28:33 heh :) 2024-05-27 10:28:54 I'm currently focussing on the secfixes tracker, which is currently not getting good data 2024-05-27 11:57:18 donoban: sure, i'll move it in a sec 2024-05-27 12:00:11 oh thanks! 2024-05-27 12:38:30 cely: thanks for merge ^^ if all goes well, the libgedit deps when in community should be able to unblock gnome-latex upgrade 2024-05-27 13:57:05 You're welcome 2024-05-27 14:51:16 Can we merge this one? It unbreaks using gpg with usb: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66568 2024-05-27 14:53:14 !66568 2024-05-27 14:54:58 WhyNotHugo: nope, `_unpack_build_dist` is essentially an `install`, and we avoid installed in split functions for subpackages 2024-05-27 14:55:11 s/installed/installs/ 2024-05-27 15:14:30 but that wasn't an answer to your question here :) 2024-05-27 15:15:15 Sorry, working preferentially from the terminal as internet connection is rubbish 2024-05-27 16:00:58 ikke: I think third try: https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/46 for the "needs maintainer feedback" label 2024-05-27 16:01:36 It needs work still, will continue Wednesday. But at least has the basics, I believe. Let me know if you have a look at it, if it makes sense to you 2024-05-27 17:49:32 ncopa: gentle ping on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66592 :P (trying to make point here we don't have to workaround it in the Mesa :P ) 2024-05-27 17:50:27 DavidHeidelberg: ncopa is on vacation 2024-05-27 17:51:01 oh, who can merge on his behalf (ffmpeg)? 2024-05-27 17:51:43 All developers can 2024-05-27 17:51:51 Depending on the type of change 2024-05-27 17:53:00 VA-API in ffmpeg, bug-fix, behaviour which is triggered by recent Mesa 2024-05-27 17:54:46 Yeah, that should not be an issue 2024-05-27 17:54:53 the patch is already upstream 2024-05-27 17:57:54 not yet. Thou it got LGTM tag :) 2024-05-27 17:58:18 and it got tested also on Intel impl. 2024-05-27 18:04:15 Ok, so a change in mesa triggers a bug in ffmpeg. Mesa could work around it, but it should be fixed in ffmpeg anyway 2024-05-27 18:08:33 yup 2024-05-27 18:08:49 and AMD devs are like "let's workaround, distros will not patch" :D 2024-05-27 18:09:24 (or get recent ffmpeg version, but that's logical) 2024-05-27 19:10:15 if a package has a test suite in the source repo but the release tarballs do not, should the repo be fetched instead or is it still okay to keep using the tarball without running the test suite? 2024-05-27 19:14:15 mio: can you use the direct repo source instead of manually uploaded tarballs instead? 2024-05-27 19:14:27 is it hosted on github? 2024-05-27 19:15:00 yes, it's on github. just that the package currently uses tarballs 2024-05-27 19:15:31 I mean, a project can either upload their own tarballs, but there are also git archive generated tarballs 2024-05-27 19:15:50 If the tests are in the repo, they should be in those automatically generated tarballs 2024-05-27 19:16:59 What's the project? 2024-05-27 19:19:28 https://github.com/GothenburgBitFactory/taskwarrior 2024-05-27 19:20:04 ah, get what you mean ... /archive/ ? /release/ does not have it 2024-05-27 19:20:54 * /releases/ 2024-05-27 19:21:10 yes, indeed 2024-05-27 19:21:33 though, using /archive/ probably means some other thing is missing 2024-05-27 19:22:37 some other thing? 2024-05-27 19:22:53 maybe a file containing the version of autoconf files 2024-05-27 19:23:01 s/of/or/ 2024-05-27 19:23:40 thanks, will try the archive tarball first and see if it works 2024-05-28 01:07:12 There was some discussion regarding taskwarrior in this channel a few weeks ago 2024-05-28 01:09:22 I think the conclusion then was that it would be better if version 3 was added as a new aport instead of an upgrade 2024-05-28 01:09:35 is added* 2024-05-28 02:06:22 celie: ah. would ncopa be interested in maintaining it as well? 2024-05-28 02:09:00 the tests pass on x86_64, was going to put in a draft to upgrade and check if the tests run on the other arches 2024-05-28 02:10:19 or did anyone else express interest in taking it up? 2024-05-28 02:14:23 hadn't meant to overstep existing efforts to upgrade ^^" 2024-05-28 02:18:58 I don't remember anyone expressing interest in maintaining it 2024-05-28 02:19:19 So, if you like, you can probably put yourself as maintainer 2024-05-28 02:19:58 It will be an MR after all, and if there's anyone else who's been working on it, they can leave a comment there 2024-05-28 02:22:55 and don't worry about N Copa (avoiding a mention as he is on vacation), he has lots to maintain already, so probably wouldn't mind others picking up something (especially considering taskwarrior 3 will be a new aport) 2024-05-28 02:47:50 okay. didn't see an open MR for it in the queue. was just trying to upgrade it, so if someone were interested in picking it up, would be happy to put their name as maintainer instead. could put my name in as maintainer, but only if there are no takers ^^" 2024-05-28 02:49:45 the new aport would be task3, or ...? 2024-05-28 02:53:46 Hehe, don't ask me, i don't use taskwarrior :) 2024-05-28 02:54:05 Anyway, the person who brought it up a few weeks ago was qaqland 2024-05-28 02:54:36 So, maybe you could talk with them to see what they would prefer 2024-05-28 03:05:27 okay, thanks ^^ 2024-05-28 03:09:01 No problem 2024-05-28 03:14:45 Hello! I'm looking into alpine linux packaging and am curious how subpackages work. Specifically, how does e.g. https://git.alpinelinux.org/aports/tree/main/openrc/APKBUILD know to install the docs only if `docs` is installed, and the bash completion only if (bash? bash-completion?) is installed? 2024-05-28 03:14:58 I read through https://wiki.alpinelinux.org/wiki/APKBUILD_Reference but am still confused 2024-05-28 03:19:38 It does that via install_if, which is like a reverse dependency 2024-05-28 03:21:17 Probably openrc isn't the most straightforward APKBUILD to read through as an example 2024-05-28 03:21:34 probably not 😄 2024-05-28 03:21:48 i dont see install_if in either openrc apkbuild or https://git.alpinelinux.org/aports/tree/main/docs/APKBUILD 2024-05-28 03:24:16 https://git.alpinelinux.org/abuild/tree/abuild.in?h=3.13.0#n1961 2024-05-28 03:26:43 ooh! 2024-05-28 03:26:46 In practice, you don't have to bother with all this, look 3 lines below that line, on line 1964 2024-05-28 03:27:01 There's a list of directories that default_doc() automatically moves into the -doc subpackage 2024-05-28 03:27:30 Very cool 2024-05-28 03:27:31 So, all you have to do is put the files in those directories in the package() function, and add "$pkgname-doc" to subpackages= 2024-05-28 03:27:38 and default_doc() does all the work for you 2024-05-28 03:28:05 thanks for the explanation 😄 2024-05-28 03:28:32 Same thing with the shell completions, that's handled by the default_bashcomp(), default_fishcomp(), and default_zshcomp() functions in abuild 2024-05-28 03:28:34 You're welcome 2024-05-28 17:04:06 https://github.com/cosmtrek/air/blob/v1.52.0/.github/workflows/smoke_test_reuse_job.yml#L28 2024-05-28 17:05:04 upstream test with nohup, how could i use it in APKBUILD's check? 2024-05-28 17:57:03 I'm about to go AFK, but came on to say, Thermi, can you please check if grommunio-gromix can be enabled on armhf 2024-05-28 17:57:25 This is the concern i had regarding your MRs that i mentioned 2 days ago 2024-05-28 17:57:56 Your MRs mix disabling archs with other changes 2024-05-28 17:58:41 So, from what i see, grommunio-gromox is being built in CI against an old version of grommunio-common 2024-05-28 17:58:51 On armhf, that is 2024-05-28 17:59:37 So, while CI is green, when your MR gets merged, grommunio-gromox may be unable to find the grommunio-common that you've just disabled on armhf 2024-05-28 18:00:19 and if that happens, it will block the builders 2024-05-28 18:01:28 and now i go AFK, please be more careful 2024-05-29 06:45:53 Hello, somebody submitted a MR for one of the packages I am maintainer of, in which they disable arch loongarch64. But I checked on the repo and saw that this arch wasn't supported anyway by alpine linux. We don't have loongarch64 builders to my knowledge anyway. On the other side I noticed that some other aports explicitely activated or deactivated this arch. Can someone explain the situation with 2024-05-29 06:45:53 loongarch please? 2024-05-29 06:47:24 https://wiki.alpinelinux.org/wiki/Loongarch64 2024-05-29 06:47:29 it's not an official target, but people do build for it 2024-05-29 06:47:38 and i guess having ports be aware of whether that works makes sense 2024-05-29 06:50:45 It is going to be an official target 2024-05-29 06:51:22 It was almost included in 3.20, but there was already too much to do for it 2024-05-29 06:51:39 So, now the schedule has been moved forward to 3.21 2024-05-29 06:52:25 and N Copa will probably bring CI and builder for that online when he comes back from vacation 2024-05-29 06:54:48 right, then it definitely makes sense that a port knows it doesn't build for loong right now 2024-05-29 06:56:36 raspbeguy: If it's a trivial disable arch, then you should just acknowledge the changes, and let us merge it, otherwise in a month's time CI for that aport may be red :) 2024-05-29 06:57:28 ok thanks cely Habbie 2024-05-29 06:58:28 As far as i know, we have 5 people from Loongson working on the Loongarch port: @huajingyun01, @znley, @yzewei, @qiangxuhui, and @zhaixiaojuan 2024-05-29 07:00:32 Any MR that comes from them should take care of getting the aport in shape for Loongarch, as before the CI/builder comes online, we rely on them to test the aports out on Loongarch 2024-05-29 07:01:21 and even when CI/builder does come online, they will still be around to fix Loongarch issues 2024-05-29 07:02:53 celie: could you please take another look at !66772. The archs and dependencies have all been fixed, including the dependent py3 packages. 2024-05-29 07:04:42 Does disabling an arch need pkgrel increment? 2024-05-29 07:05:48 midasi: Sorry, i've had a long day, and that MR is rather big, so i would suggest you ask someone else, sorry 2024-05-29 07:06:08 sure, thanks anyway 2024-05-29 07:06:57 raspbeguy: If it has not been built, then pkgrel doesn't need to be incremented, you disable and increment only when you want to remove something that has already been built (so it will be removed from pkgs.a.o) 2024-05-29 07:07:17 ok 2024-05-29 07:07:50 For Loongarch, nothing has been built officially, so no pkgrel changes are needed 2024-05-29 07:22:00 cely, and in the case previous official arch have been disabled and then we activate it again, it need increment reight? 2024-05-29 07:22:03 cely, and in the case previous official arch have been disabled and then we activate it again, it need increment right? 2024-05-29 07:23:11 Not really 2024-05-29 07:23:30 ok 2024-05-29 07:24:40 Your best bet would be to check https://build.alpinelinux.org/buildlogs/ for the particular arch you are thinking about 2024-05-29 07:24:57 and if the log for that pkgrel is missing, or it ends in an error 2024-05-29 07:25:17 then that pkgrel has never existed for that arch, and enabling it doesn't require a pkgrel bump 2024-05-29 07:28:35 Another way to check is to open an MR enabling that arch, and look at CI, if it doesn't say "package is already in index", then a pkgrel bump isn't needed 2024-05-29 07:29:42 doesn't say that for the arch you enabled* 2024-05-29 07:29:59 It will of course say that for other archs that are already enabled 2024-05-29 07:35:54 Anyway, if anyone's interested, this is the TSC issue where Loongarch support was discussed: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/72 2024-05-29 07:37:38 and i notice that the last message there is from almost 3 months ago, however, that's probably because the discussion has moved to the #alpine-loongarch IRC channel 2024-05-29 07:40:54 and now i'll go AFK, bye 2024-05-29 08:00:58 could somebody please merge !66772 2024-05-29 10:22:57 ikke: https://gitlab.alpinelinux.org/alpine/infra/aports-qa-bot/-/merge_requests/46 (for adding "maintainer feedback" label) is ready 2024-05-29 10:23:15 Hopefully I understood the requirements correctly :) 2024-05-29 10:25:25 PabloCorreaGomez[m]: FYI, the autolabeler is disabeled at the moment. The reason is that either due to refactoring or a gitlab upgrade, for certain MRs the bot kept adding and removing the same label over and over 2024-05-29 10:27:16 Do you have logs? I think it's pretty useful for the new functionality. I'd be happy to look into it 2024-05-29 10:27:42 sadly it was a long time ago 2024-05-29 10:28:37 Having a fast look at it, it's listening to "Update" events on the MR, and updating the MR in the process. So I can see how that can trigger an infinite loop :) 2024-05-29 10:28:43 Probably also with my own code 2024-05-29 10:30:37 Maybe filter out updates from the bot itself? 2024-05-29 10:31:11 I'll take a more indepth look this evening 2024-05-29 10:31:14 That's probably going to work, yes. Do you have the bot id? I wonder if I should hard-code it, or add it as an option 2024-05-29 10:31:56 FYI, these days I'm working on FOSS Mondays, Wednesdays, and Thursdays, and Wednesdays I'm only available regular European working hours :) 2024-05-29 10:32:25 I'm not sure we can hardcode it. The bot is created through an access token, has a limited lifetime 2024-05-29 10:32:32 since gitlab 16, max of 1 year 2024-05-29 10:32:49 But isn't there an account for it? 2024-05-29 10:32:57 Or does the account also expires? 2024-05-29 10:33:10 yup 2024-05-29 10:33:13 they are tied together 2024-05-29 10:33:36 Fun. Ok, I'll add it as an option 2024-05-29 10:34:41 does the api have some field to indicate it's a bot or something? 2024-05-29 10:36:35 there is a `bot` attribute 2024-05-29 10:41:14 hello, if I'm adding a new (Python) package I assume I would put myself as contributor/maintainer? 2024-05-29 10:41:25 yes 2024-05-29 10:41:30 thanks! 2024-05-29 10:58:38 ikke, abby: I pushed a commit adding an option. I'm happy to remove it if there's some way to clearly identify the bot without hard-coding a value 2024-05-29 10:59:14 I don't think the attributes are supported yet: https://pkg.go.dev/github.com/xanzy/go-gitlab#EventUser 2024-05-29 10:59:38 Maybe we can match against "name", but I'm assuming ID is a bit more safe 2024-05-29 10:59:55 Specially since we're using the bot downstream too :) 2024-05-29 11:00:54 I don't see anything indicating it's a bot in the webhook payload 2024-05-29 11:01:20 So it would at least require another API call 2024-05-29 11:19:58 That might be a lot more annoying from the code perspective. But I guess you decide how annoying it would be to have to update the field regularly 2024-05-29 11:20:23 If you think I should implement it, then I can go ahead 2024-05-29 12:06:38 could someone merge !66567? 2024-05-29 12:14:53 ikke: can we get https://gitlab.alpinelinux.org/alpine/infra/atools-go/-/merge_requests/42 merged and released? :) 2024-05-29 12:19:19 thx 2024-05-29 12:43:13 ptrc: yes, i have that on my to-do list 2024-05-29 13:09:34 okie 2024-05-29 14:08:15 2 more interns are likely going to be focused on ppc64le in alpine this summer :D is this an updated list of issues? https://gitlab.alpinelinux.org/alpine/aports/-/issues/?sort=created_date&state=opened&search=ppc64le&first_page_size=20 2024-05-29 14:08:35 or should we just continue to focus on the package builds for ppc64le? we are focusing on the luajit package now...thanks! 2024-05-29 14:15:07 Hi 2024-05-29 14:15:08 What about s390x? 2024-05-29 14:18:17 I mean, i may have found something going with Rust, LLVM 18.1.6, and s390x, but that's a combination way above my ability to debug :) 2024-05-29 14:24:13 !66627, that MR used to also include a switch to LLVM18 (`_llvmver=18` on line 11 of the APKBUILD), but i noticed an occasional SIGILL on s390x (though it went away after retrying the pipeline) 2024-05-29 14:26:02 To be safe, i tried the latest Rust beta (1.79.0-beta.7), and with that, s390x seems to consistently fail to build 2024-05-29 14:27:19 I went on to downgrade LLVM back to 18.1.5, and the issue seems to go away 2024-05-29 14:28:50 does https://github.com/llvm/llvm-project/commit/9f85bc834b07ebfec9e5e02deb9255a0f6ec5cc7 fix it 2024-05-29 14:29:26 though i don't see why it'd affect s390x so prolly not 2024-05-29 14:29:33 can't think of anything else that regressed in .6 2024-05-29 14:30:10 if .5 works and .6 fails then just bisect these https://github.com/llvm/llvm-project/compare/llvmorg-18.1.5...llvmorg-18.1.6 2024-05-29 14:30:39 https://github.com/llvm/llvm-project/commit/9acb41b1e4bb897cbc70301824acf1da4c46a51d is s390x specific 2024-05-29 14:30:44 so try revert just that first 2024-05-29 14:32:13 I noticed that commit as well, but will have to try it out in the CI 2024-05-29 14:32:36 if it fixes it then get a real backtrace of the crash and open an issue 2024-05-29 14:32:41 and tag the person that made it ig 2024-05-29 14:32:43 should get fixed 2024-05-29 16:46:18 Anyone with cmake experience has a clue why https://github.com/netdata/netdata/commit/2a04a06569cec70da71d04a58954a030384b4cf7 results in https://tpaste.us/9M6n? 2024-05-29 16:46:59 Reverting the change in packaging/cmake/Modules/NetdataProtobuf.cmake makes it build again 2024-05-29 16:47:36 cely: i dont have access to that hardware. right now on ppc64le we are focusing on luajit and python3 2024-05-29 16:49:19 ikke: what's the full g++ invocation look like 2024-05-29 16:50:13 https://tpaste.us/nk0x 2024-05-29 16:51:35 hm where did the -D go 2024-05-29 16:51:45 ah 2024-05-29 16:52:37 It's there twice? 2024-05-29 16:52:49 one time with and one time without -D 2024-05-29 16:58:39 hrm i'm as confused as you 2024-05-29 16:59:06 ${PROTOBUF_CFLAGS_OTHER} should have something like -DPROTOBUF_USE_DLLS in it 2024-05-29 16:59:16 i'm not sure why it appears a second time with the -D dropped 2024-05-29 17:02:07 -- NETDATA_PROTOBUF_CFLAGS_OTHER="PROTOBUF_USE_DLLS" 2024-05-29 17:02:10 ah 2024-05-29 17:02:13 well there's your issue 2024-05-29 17:02:20 hmm 2024-05-29 17:02:23 i wonder where it comes from 2024-05-29 17:02:34 cmake interface defs don't usually have the D 2024-05-29 17:02:49 like in protobuf-targets.cmake it's INTERFACE_COMPILE_DEFINITIONS "PROTOBUF_USE_DLLS" 2024-05-29 17:02:58 but this does not translate to CFLAGS and shouldn't just be put in them 2024-05-29 17:03:04 maybe it's a bug in whatever sets them 2024-05-29 17:03:08 not sure what does tho 2024-05-29 17:03:13 could just be an upstream protobuf issue 2024-05-29 17:25:59 alice: I suppose for now I just revert that line 2024-05-29 17:26:15 sure 2024-05-29 17:26:24 after reverting it can you see the g++ invocation line and diff them 2024-05-29 17:26:42 It does not print the line then 2024-05-29 17:26:46 only when it fails 2024-05-29 17:31:28 midasi: i'm afraid i'll have to disappoint you again, i'm having internet issues, and have been trying to merge something without success for the past half an hour 2024-05-29 17:31:39 yeah you'll need either to build with -v or to look at the build.ninja for the invocation 2024-05-29 17:32:11 midasi: and to be frank, i don't think i'm up to the task of reviewing such a big MR 2024-05-29 17:37:08 midasi: i know a few contributors have been helping to review things (look at the MR list for MRs with many comments, maybe you can consider pinging them instead, sorry) 2024-05-29 17:41:43 Without that change, it only contains a single instance of -DPROTOBUF_USE_DLLS 2024-05-29 17:46:35 hm okie 2024-05-29 17:49:05 cely: thanks 2024-05-29 17:50:22 No problem (now you know that was what i've been trying to merge for the past half an hour) :) 2024-05-29 17:51:54 ouch (hope that means the internet issues will go away soon) ^^" 2024-05-29 17:53:27 (if it finally went through) ^^ 2024-05-29 18:05:47 Not really, i'm waiting to see the first few lines of a CI log, and then i'm off to do something else 2024-05-29 18:12:09 aww okay 2024-05-30 08:48:27 i'm on my way to the GPN22, is someone here someone I could meet with and chat a little? 2024-05-30 12:03:15 Hi all, I'm the maintainer for librdkafka. It's been flagged out of date but I think this is a mistake and the version looks odd (2.4.0.2), but I can't figure out where the mistake has come from. 2024-05-30 12:03:59 There isn't a new release available. I've been digging around trying to figure out if there was a release made by the librdkafka guys by mistake but haven't been able to confirm. 2024-05-30 12:16:58 jxanthony: https://release-monitoring.org/project/12573/ 2024-05-30 12:17:16 apparently 2.4.0-2 which got rewritten to 2.4.0.2 2024-05-30 12:46:34 Looks like it points to the same commit (and has the same checksum) as 2.4.0, both released 3 weeks ago 2024-05-30 14:27:46 I must be stupid, but how do I build a custom APKBUILD file into an APK? Do I actually need to clone aports and setup a local repository? 2024-05-30 14:28:10 I can't seem to figure out how to do that... I just want to build a small package for personal use into an APK and install it on my system 2024-05-30 14:28:21 Riolku: you don't necessarily need to clone apk 2024-05-30 14:29:03 just a single package in a directory and run abuild -r should work (assuming you have installed alpine-sdk, generated a signing key and added your user to the abuild group) 2024-05-30 14:29:10 This also assumes an alpinelinux system 2024-05-30 14:30:07 In general, for packages that contain Rust code, does alpine prefer vendored dependencies or having "options="net"" 2024-05-30 14:34:04 Seems there were some errors in my apkbuild file - it seems to work now ty 2024-05-30 14:38:16 I think the former. There is a wish to be able to fetch these dependencies right before the network is removed (without options="net"), but that requires abuild to be adjusted 2024-05-30 14:41:34 Ok, thanks! 2024-05-30 14:42:19 I'll adjust my app later, will still send a first path with options="net", just to get it in :) 2024-05-30 14:42:48 It's just a warning now anywayy 2024-05-30 14:48:29 Perfect, thanks :) 2024-05-31 02:09:22 cely: thanks for transferring that issue to me :) 2024-05-31 02:12:46 You're welcome 2024-05-31 17:19:41 Hi guys 2024-05-31 17:19:58 I have a package where I'm specified as a maintainer 2024-05-31 17:20:13 However since I have no rights to push/resolve threads I cannot do anything 2024-05-31 17:20:27 What is the proper way to do things now? 2024-05-31 17:20:36 Should I contact some proxy? 2024-05-31 17:22:08 which MR 2024-05-31 17:31:53 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/66259 2024-05-31 17:35:02 if you're happy with the changes and the trhead is resolved i can merge it 2024-05-31 17:35:25 yeah, please do 2024-05-31 17:35:28 lgtm 2024-05-31 17:37:05 Given the somewhat dead status of the upstream I'm not sure I'll have to touch this package again soon enough, but just in case: what do I do then? 2024-05-31 17:38:01 is it used? 2024-05-31 17:38:12 Well, I guess 2024-05-31 17:38:33 then not much i guess 2024-05-31 17:38:45 I mean what do I do to resolve requests 2024-05-31 17:38:54 Like go to IRC and ask someone to merge? 2024-05-31 17:39:05 Or maybe there is a label for such things? 2024-05-31 17:39:24 Or some piece of devdoc I've totally missed >_> 2024-05-31 17:39:29 <_< 2024-05-31 17:39:48 you can approve merge requests 2024-05-31 17:40:02 Gitlab tells me otherwise 2024-05-31 17:43:01 thats unfortunate, i guess asking on irc will do 2024-05-31 17:58:49 thx 2024-05-31 20:25:33 consus: even adding a comment that you agree with it would suffice 2024-05-31 20:28:05 consus: I've added you as guest to the project, which will allow you to approve merge requests 2024-05-31 20:31:20 thanks!