2024-04-01 01:21:11 omni: thanks \^o^/ 2024-04-01 01:36:35 np 2024-04-01 06:40:31 in light of the recent xz fiasco: is it really neccessary that our openssh package unconditionally links to utmps+skalibs? can/should we at least provide a flavor without it? 2024-04-01 06:40:32 see https://cybervillains.com/@djm/112192735215160932 2024-04-01 06:41:05 also: our openssh package carries a suprising amount of patches, including some (e.g. the dns thing) which were never reported upstream 2024-04-01 06:41:15 nmeum: so about a year ago 2024-04-01 06:41:27 we spent a few days figuring out our openssh patches and tossing as many as we could and doing digging for why the ywere added 2024-04-01 06:41:31 in gentoo, i mean 2024-04-01 06:41:33 it was completely worth it 2024-04-01 06:42:07 yea, I think our ssh package is in need of a cleanup as well 2024-04-01 06:44:49 I believe we should also not link against utmps+skalibs statically so that we can easily verify that unrelated binaries (e.g. ssh-client) are not linked against it 2024-04-01 09:09:07 utmps was added for `who` support. musl only provides stubs 2024-04-01 09:09:23 nmeum: thank you for cleaning up 2024-04-01 09:10:33 cleanup is still in progress, currently debugging fix-verify-dns-segfault.patch (I believe it actually worked around a musl bug and shouldn't be needed anymore) 2024-04-01 09:11:04 I understand why utmps was added, it's just that we should maybe reconsider if we want to ship that by default or if it should be a flavor instead 2024-04-01 09:11:40 nmeum: can you explain how it relates to the xz thing? 2024-04-01 09:12:48 it pulls in extra code that one has to consider when reviewing the ssh package (I am not trying to say that utmps is inherently bad) 2024-04-01 09:13:29 ideally, I would like the default openssh package to have as few dependencies as possible (see https://cybervillains.com/@djm/112192735215160932) 2024-04-01 09:15:27 there are zillions of packages with complex dependencies and you are singling utmps+skalibs out 2024-04-01 09:16:48 you are not trying to say that utmps is inherently bad, but you *are* effectively saying that skaware is just as unreliable as xz 2024-04-01 09:17:21 I just don't get the hostility. I don't get it. 2024-04-01 09:17:27 an optional flavor 2024-04-01 09:17:27 I am not singling out utmps+skalibs, my observation is just "other distros patched openssh to introduce an unexpected dependency on libsystemd -> liblzma" so I looked at our aport and noticed that we also patch it to introduce a dependency on utmps. other than utmps+skalibs there are really not a lot of dependencies in the openssh package and even kerberos support is 2024-04-01 09:18:32 but idk, just wanted to put this up for debatte (if it is just me we can also just leave it as is) 2024-04-01 09:20:38 I mean, in theory, fair, but compared to openssh itself, utmps+skalibs is what, 3% of the complexity? 2024-04-01 09:21:56 I can prove scientifically that skaware isn't vulnerable to the same attacks that xz was and that it's not going to endanger anything, but frankly I'm tired of being on the defensive all the time 2024-04-01 09:22:05 I didn't interpret nmeum as hinting anything about skalibs. Just a question if we can reduce dependencies if possible 2024-04-01 09:22:06 do whatever you feel is best 2024-04-01 09:22:27 yeah yeah you need to reduce size, complexity, dependencies, all that 2024-04-01 09:22:34 and the first thing you go for is utmps 2024-04-01 09:22:59 I just don't get it and I'll probably never get it 2024-04-01 09:24:16 as I said: I was just looking at the openssh package for extra dependency, I am not trying to get rid of skawares specfically (and my original question/suggestion was just adding a flavor without it) 2024-04-01 09:24:25 *dependencies 2024-04-01 09:29:14 the thing that kills me is the spectre of auditing, used as a possibility or a threat instead of an actual thing. You say "if we need to audit openssh, then utmps is one more thing we need to audit". 2024-04-01 09:29:27 and I'm saying, PLEASE audit my software. PLEASE do it. 2024-04-01 09:29:45 I'm *dying* to prove that it can be trusted. 2024-04-01 09:30:46 and it's so. easy. to. audit. compared to whatever's out there, especially if you think stuff like openssh, liblzma or libsystemd. 2024-04-01 09:32:19 I want to work in an atmosphere of trust, not of constant defiance. 2024-04-01 09:33:21 and of course verification is needed, blind trust is an obvious no-no. So please, verify. 2024-04-01 09:34:34 i believe nmeum was looking for low-hanging fruit 2024-04-01 09:34:54 I did not mean to critize you or your software personally and I am sorry if it came across that way, I just saw the referenced djm toot and was looking at ways our ssh package differs from upstream 2024-04-01 09:35:41 the patches are one aspect (which I am currently working on), the utmps thing was just another part I noticed and which I therefore posted here 2024-04-01 09:36:29 about utmps, the question is whether you want to have utmp working with musl or not, and I think it should be handled transversally across packages, as an extension to the libc, rather than as a dependency to openssh 2024-04-01 09:37:41 I don't think it's a good idea to have an openssh package without it if login(1) works with it, and login(1) is busybox 2024-04-01 09:38:31 because you'd have inconsistent utmp databases, recording local logins and not remote ones 2024-04-01 09:40:03 one thing we could do is have an openssh flavour with utmps support (similar to how we handle kerberos support in openssh rn) and then have an install_if rule which automatically install the utmps flavour if the utmps package is installed (thereby ensuring that the utmps openssh version is only installed if the system actually makes use of it) 2024-04-01 09:40:35 that could work indeed 2024-04-01 09:41:59 except that often openssh is the first thing one installs over serial console, then (using ssh) the rest of the packages gets installed. 2024-04-01 09:43:04 I think install_if applies retroactively, doesn't it? e.g. if you install a package and afterwards install the docs metapackage the -doc subpackages for already installed packages will be pulled in, no? 2024-04-01 09:43:10 wouldn't apk auto-upgrade ssh once utmps gets installed? the next ssh session would use the new one 2024-04-01 09:43:18 yeah that 2024-04-01 09:44:19 but again, nmeum: then you'll say that busybox is linked to utmps+skalibs, and that's an added dependency, that you'll need to question, and we're going to go through the whole circus again 2024-04-01 09:45:45 I think there is an argument to be made that the openssh package deserves special treatment since the threat model is a bit more advanced here compared to busybox for example 2024-04-01 09:47:01 if I have a supply chain attack in utmps I can make login(1) call home and install a RCE 2024-04-01 09:47:49 Could a someone take a look at !63130 please? Thanks! 2024-04-01 09:49:00 I would argue that if login starts making weird network connections, then this is more likely to get noticed compared to the subtle RCE added to a network facing deamon like openssh by the xz thing 2024-04-01 09:49:32 that would probably be more noticeable than a 0.5s delay, yes :) 2024-04-01 09:51:13 but my point is that dependencies are dependencies and it doesn't really matter what the top package is, the important part is to be able to trust the lower levels 2024-04-01 09:51:34 removing dependencies is mitigation 2024-04-01 09:53:12 it makes the package tree easier to audit, but it's still unknowns until you actually audit 2024-04-01 09:54:45 some government employees will get a performance review this week 2024-04-01 09:54:49 nangel: im on it 2024-04-01 09:54:52 yea it's a mitigation, but fundamentally, the xz thing is a supply chain attack. reducing dependencies means less attack surface and less supply chain attacks 2024-04-01 09:58:40 yup, and if the first thing you want to reduce the risk of a supply chain attack from is my software, at the cost of consistent functionality in the distro, then I'm rightfully going to feel mistrusted, especially since I think in two weeks the thing will be more or less forgotten and no other dependency will ever be removed 2024-04-01 10:00:52 I think we are going in circles. this is just a deviation from the upstream openssh version and we can reduce this diviation *without* breaking functionality through a flavour and an install_if rule 2024-04-01 10:01:10 in terms of reducing deviations from upstream openssh: I managed to get rid of another patch !63238 2024-04-01 10:02:38 install_if is fine with me but I still think it's all theater 2024-04-01 10:24:55 https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1325713 2024-04-01 10:25:16 did handling of virtual packages/provides change with apk-tools 2.14.2 or why is it no longer able to find a package providing openssh-client? 2024-04-01 10:26:41 nmeum: openssh does not seem to exist anymore 2024-04-01 10:26:47 except for on arm 2024-04-01 10:26:50 ttps://pkgs.alpinelinux.org/packages?name=openssh*&branch=edge&repo=&arch=&maintainer= 2024-04-01 10:26:53 https://pkgs.alpinelinux.org/packages?name=openssh*&branch=edge&repo=&arch=&maintainer= 2024-04-01 10:27:12 well that aint good 2024-04-01 10:27:20 I also get: 2024-04-01 10:27:24 > (1/1) Upgrading bubblewrap (0.8.0-r1 -> 0.9.0-r0) 2024-04-01 10:27:25 > ERROR: bubblewrap-0.9.0-r0: BAD signature 2024-04-01 10:27:29 when attempting to update 2024-04-01 10:27:46 as do several of us 2024-04-01 10:28:25 yes, I was looking at bubblewrap 2024-04-01 10:28:54 WARNING: opening /home/buildozer/packages/main: No such file or directory 2024-04-01 10:28:55 apk-tools upgrade was pushed two hours ago so that's why I thought there might be a regression 2024-04-01 10:29:21 unfourtunately, I can't downgrade because it tries to enforce the bubblewrap upgrade first (which fails) :D 2024-04-01 10:30:14 you could use a less up-to-date mirror 2024-04-01 10:30:26 if you don't store your apk files locally 2024-04-01 10:31:20 I've verified the bubblewrap package checksum matches everywhere, so it seems the signature in the index is not matching 2024-04-01 10:33:17 hum 2024-04-01 10:33:48 bubblewrap also fails with 2.14.1 2024-04-01 10:34:26 https://tpaste.us/VqxN 2024-04-01 10:35:12 maybe an issue with how the index is created by 2.14.2 then? (just a wild guess) 2024-04-01 10:35:24 yes, that's what I would guess 2024-04-01 10:35:55 yes 2024-04-01 10:35:58 likely that 2024-04-01 10:36:07 i'm on it. sorry for the mess 2024-04-01 10:36:24 might also explain why the openssh package is gone all of the sudden 2024-04-01 10:36:26 no worries, happens 2024-04-01 10:37:00 The apk files still exist on the builder 2024-04-01 10:39:13 In the worst case, we would revert to 2.14.1 2024-04-01 10:39:20 the bad news is that i pushed same code to many stable branches 2024-04-01 10:39:28 oh 2024-04-01 10:39:33 should I revert? 2024-04-01 10:39:53 give me a minute 2024-04-01 10:40:14 Alright 2024-04-01 10:40:33 openssh at least still seems to exist in the stable branches 2024-04-01 10:40:47 I thinkt here was nothing pushed to the stable branches since the apk-tools upgrade 2024-04-01 10:41:07 so the index wasn't recreated with the new version yet and it should be fine 2024-04-01 10:44:16 But the index after the next upgrade would be 2024-04-01 10:46:24 yep, so better not push anything rn 2024-04-01 10:46:51 ah you mean after the apk-tools fix 2024-04-01 10:46:51 well… 2024-04-01 10:47:32 yup 2024-04-01 10:51:50 sound slike we are having a blue monday 2024-04-01 10:52:06 so it seems to be indeed in the index generation the issue 2024-04-01 10:52:16 It is April 1... Usually April 1 jokes are funny. :( 2024-04-01 10:52:59 everybody running in post-xz-apocalypic panic, apk is eating our indexes, and nobodu know if we are trying to fix real issues or 1 april jokes... 2024-04-01 10:53:04 I have previously installed Alpine Linux on a USB stick with XEN using a mini PC and then booted it successfully from the USB stick. I booted the install ISO from a USB stick when i first set it up. Now i wanted to make another installation on the same hardware but when the installer boots it gives the following error: "ERROR: modloop failed to start" and when reaching the login 2024-04-01 10:53:07 prompt the keyboard doesnt work (which it does when GRUB is loading and also when booting from my XEN USB stick). If someone could point me in a direction on how to solve this I'd appreciate it, because so far none of the things I've tried has helped. 2024-04-01 10:53:40 EvTheFuture: Seems more appropriate for #alpine-linux tbh 2024-04-01 10:53:56 sounds like a good idea to take the day off and enjoy the sunshine 2024-04-01 10:54:04 ncopa: you deserve it 2024-04-01 10:54:15 btw, using v3.19 repos should work right? since it seems to be an index error 2024-04-01 10:54:17 No sunshine here :( 2024-04-01 10:54:37 I forgot my gloves at home so I have pretty red hands now from the sun :=) 2024-04-01 10:54:44 rdbo: until someone pushes new updates to the stable branches 2024-04-01 10:54:58 rdbo: but for now, it should work 2024-04-01 10:55:12 sounds good 2024-04-01 10:58:39 so I shouldnt push anything to edge either for now I suppose? 2024-04-01 10:58:56 i think all branches with updated apk is affected, index generation is not working as expected :( 2024-04-01 10:59:46 fabled: anything I can do to help? Or we just wait? 2024-04-01 11:00:50 i probably have a fix soon 2024-04-01 11:07:18 👍 2024-04-01 11:09:36 ok, i think i have a fix, but want to verify it still a bit more 2024-04-01 11:10:31 i really look forward to moving to apk3 format where these things dont happen... 2024-04-01 11:17:23 should i tag a version right away? 2024-04-01 11:25:08 maybe test that the fix works first? eg add a patch to apk-tools in edge, verify it works, tag release 2024-04-01 11:35:36 hum 2024-04-01 11:35:41 its still not good :( 2024-04-01 11:43:37 actually it should work 2024-04-01 11:43:47 seems that getting apk upgraded on builders may require manual steps 2024-04-01 11:45:32 ok, could try this now 2024-04-01 11:50:48 fabled, doesn't seem to work 2024-04-01 11:51:01 i think builder still needs manual fixing 2024-04-01 11:51:06 (still bad signature) 2024-04-01 11:51:12 the index needs regeneration 2024-04-01 11:51:54 ncopa: ikke: do i still have access for the builders? 2024-04-01 11:54:37 fabled: most likely not 2024-04-01 11:56:12 would definitly love to see the apk3 format on the roadmap for the 3.21 release 2024-04-01 11:57:05 i've started tagging _preX releases for apk3 now 2024-04-01 11:57:27 i'll just ship the new binary format, and do the remainder of internals conversions on a later release 2024-04-01 11:59:51 ikke: who would have that access? who do we ping? 2024-04-01 12:10:17 switching to new index format is going to mean pain for all the third party stuff that parses the indexes btw 2024-04-01 12:10:22 i.e. repology and the likes 2024-04-01 12:11:18 i dealt with it by adding a limited v2 index generator to our apkbrowser like https://pkgs.chimera-linux.org/apkindex/current/main/x86_64 2024-04-01 12:12:25 it works by dumping the information straight from the web interface's database 2024-04-01 12:12:50 and caches it based on database timestamp 2024-04-01 12:18:46 fabled: ikke and ncopa have access 2024-04-01 12:21:34 i've verified the fix in various ways, and will push it. the sad part is that builders need to be manuall fixed for it 2024-04-01 12:34:18 im back from a long walk in the sun 2024-04-01 12:34:35 fabled: how do I fix? 2024-04-01 12:37:00 Just noticed another project that puts out a notice not to use the Github autogenerated source archive: https://github.com/FreeTDS/freetds/releases/tag/v1.4.11 2024-04-01 12:37:21 interesting 2024-04-01 12:53:58 supposedly common for C projects that run autoconf themselves or something? 2024-04-01 12:58:44 salt has such a warning, darktable as well 2024-04-01 12:58:56 Probably also those that vendor git submodules in the final tarball 2024-04-01 13:08:29 im updating pango and the soname changed from `libpango-1.0.so.0.5100.0` to `libpango-1.0.so.0.5200.2`, that requires a rebuild right? 2024-04-01 13:10:44 The soname is still the same, though it's a .0 2024-04-01 13:14:56 Looking through pango's changelog, i see "Add pango_font_map_reload_font" (usually rebuilds are needed only when a function is removed); and "Update to Unicode 15.1" (not sure whether this would require a rebuild, probably not..) 2024-04-01 13:39:07 there's only 8 packages that need a rebuild, I could take care of that if needed 2024-04-01 13:39:23 otherwise !63249 looks green (pending aarch64) 2024-04-01 14:37:06 has the index been fixed? 2024-04-01 14:37:18 most yes, i think few are still missing 2024-04-01 14:38:08 great and thanks for coming up with a quick fix! 2024-04-01 14:45:22 sorry for the mess. i actually did test indexing during the development cycle several times, but it was one final adjustment that broke it... sigh. bad monday on several levels 2024-04-01 14:46:01 ACTION offers a blanket and some hot cocoa 2024-04-01 14:48:48 yay, bubblewrap installed for me, now i can keep working on my distro 2024-04-01 14:48:53 thanks for your work guys! 2024-04-01 14:51:16 fabled: no need to apologize you do lots of great work on apk! mistakes like this happen :) 2024-04-01 14:51:31 thanks 2024-04-01 14:52:18 for background, the past 1-5 years have been on and off on apk for various reasons (personal/family, work, etc) depending on the year. i'm finally getting to spend my $-work time on apk3 again, and hope to get it into a reasonable state this year 2024-04-01 14:52:26 i really wanted that to happen like 5 years ago 2024-04-01 14:52:45 Looking forward to it! 2024-04-01 14:53:06 > i really wanted that to happen like 5 years ago 2024-04-01 14:53:11 life is sometimes like that 2024-04-01 14:53:20 no need to beat yourself over it 2024-04-01 14:55:28 fabled: that's really great news :D 2024-04-01 14:56:38 happy to hear that, really looking forward to apk3 landing in alpine in the (hopefully not so distant) future 2024-04-01 14:57:22 What i'm most excited for is that it will likely be easier to hook into it and write APIs to build cool stuff with and around apk 2024-04-01 14:57:36 Unlike now, where it takes quite a bit of effort 2024-04-01 14:58:29 for what it's worth, i think that apk is the best package manager out of all distros. i'm sure there's been a lot of work from many devs here to make it that good 2024-04-01 14:59:00 There's still room for improvement if you look deep enough, but comparably it's quite good 2024-04-01 14:59:38 performance-wise, quite shocking the first time i used it. feature-wise, i'm using it to build the squashfs for my distro quite easily. i'm sure apk3 will be even more awesome tho 2024-04-01 15:10:33 all the apk indexes should be fixed now 2024-04-01 15:10:42 i just pushed the last fixes for riscv64 2024-04-01 15:12:08 it is sort of lucky that it was on a holiday and not tomorrow 2024-04-01 15:12:14 less activity today 2024-04-01 15:25:40 Could someone have another look at !57900? 2024-04-01 15:25:47 does this look ok? https://wwwtest.alpinelinux.org/posts/XZ-backdoor-CVE-2024-3094.html 2024-04-01 15:26:46 It also only included the malicious code in RPM and DEB packages. Not sure if it's worth mentioning though. 2024-04-01 15:27:42 I just went through all of our ssh patches, 4 of them can just be removed. the remaining patches are required for utmps support (see the prior discussion) or only change the configuration 2024-04-01 15:32:13 ok pushed 2024-04-01 15:32:44 https://alpinelinux.org/posts/XZ-backdoor-CVE-2024-3094.html 2024-04-01 15:37:19 "immediately to xz-6.5.1-r2 or newer" : typo, FWIW 2024-04-01 15:40:06 thanks! how is it spelled? 2024-04-01 15:40:21 I could not find the typo 2024-04-01 15:40:35 isn't it 5.6.1? 2024-04-01 15:40:53 ah yes 2024-04-01 15:41:04 oh.. 2024-04-01 15:41:46 Sorry, should have been more obvious. Yes, it's the version number I was pointing out. 2024-04-01 15:42:05 thanks fabled, fixed for me too 2024-04-01 15:43:00 small mistake, the post looks good otherwise ncopa! 2024-04-01 15:44:05 fabled: thank you writing the best package manager ever 2024-04-01 15:44:17 typo should be fixed now 2024-04-01 15:44:56 yep, thanks 2024-04-01 15:48:31 anyone knows where 'jgs' stands for in the output of `apk fetch -f coffee`? 2024-04-01 15:51:27 i think its the author of the ascii art 2024-04-01 15:51:34 ah 2024-04-01 16:08:46 got bubblewrap-0.9.0-r0: BAD signature 2024-04-01 16:08:49 known? 2024-04-01 16:09:26 looks like it is from #alpine-linux 2024-04-01 16:10:46 staceee try apk update. i was getting it too but now it worked 2024-04-01 16:11:50 yeah, should be fixed now, maybe you need to wait for your mirror to update first 2024-04-01 16:12:00 +1 2024-04-01 16:12:25 staceee: a bug in apk-tools affecting index generation 2024-04-02 00:41:29 omni: thanks ^^ 2024-04-02 01:16:40 np 2024-04-02 03:54:39 To unblock the builders !63309 and !63311 2024-04-02 03:56:46 The latter cannot pass CI due to dependencies not being uploaded yet, and in case my patch is still not able to fix the tests, and i'm not around to look into it further, then just disable tests for the time being 2024-04-02 11:31:11 i am making a package for hexedit. it has a 'press F1 for help' which depends on its man page 2024-04-02 11:31:27 do i leave the man page in the 'hexedit' package or should it be on 'hexedit-doc' 2024-04-02 11:39:22 we usually put it in -doc 2024-04-02 11:39:51 alright, will do that 2024-04-02 11:42:47 anybody volunteering update py3-pylint to 3.1.0? seems to be lots of test errors 2024-04-02 12:05:29 OK i created a merge request for the hexedit apk: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63348 2024-04-02 12:05:33 let me know if i need to change anything 2024-04-02 12:08:45 oof, lint issue. let me fix that 2024-04-02 12:11:50 alright, now we should be good to go 2024-04-02 12:14:38 TIL that when updating zstd we also need to rebuild py3-zstandard 2024-04-02 12:14:50 E ImportError: zstd C API versions mismatch; Python bindings were not compiled/linked against expected zstd version (10506 returned by the lib, 10505 hardcoded in z 2024-04-02 12:14:50 std headers, 10505 hardcoded in the cext) 2024-04-02 12:15:17 ncopa: re pylint, I already have a working 3.1.0 version. I think we only updated the py3-astroid package first and after that the pylint tests completed successfully. Let me know if you need help 2024-04-02 12:16:06 i saw the py3-astroid update. can you please create an MR with with working py3-pylint? 2024-04-02 12:17:35 sure, can do that 2024-04-02 12:19:30 thanks! 2024-04-02 12:20:21 ah I see we added as well two dependencies 2024-04-02 12:20:39 thank you for taking care of that ;) 2024-04-02 12:31:55 meh.. py3-zstandard uses bundled headers but links to system lib 2024-04-02 13:30:37 Do we by any chance distribute the tcb nss+pam utils via any package? I fell into a weird case where i tried passwd and forgot that 2 years ago i tried openwall/tcb and that doas+sudo use it by default to authenticate but neither coreutils passwd nor busybox passwd changes it if present 2024-04-02 13:31:04 So i just kept trying passwd until i gave up and strace'd it 2024-04-02 13:31:17 It was a very weird case 2024-04-02 13:32:27 If not, i should package those, i completly forgot about this and it came biting back 2 years later for being forgotten ^^' 2024-04-02 13:55:55 correction for the wiser: yes i do mean musl and not just doas+sudo :P 2024-04-02 15:40:02 i think this is ready to go (i did fixes suggested by Celeste, but needs a final review): https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63348 2024-04-02 17:04:11 what's the general policy for using a git version vs a release? 2024-04-02 17:04:17 for example, there's the 'yambar' package 2024-04-02 17:04:35 it has had many, many fixes since the last release. but the dev hasn't released a minor version 2024-04-02 17:04:52 would it be prefered to wait or to make a git-based package update? 2024-04-02 17:05:10 i'm asking because i will make an update for myself, and if it's desired, i could put it on aports too 2024-04-02 17:22:55 Did you ask the developer to cut a release? He just released foot a few hours ago so he's reachable at least 2024-04-02 17:23:58 Arnavion: yeah, not only me: https://codeberg.org/dnkl/yambar/issues/348 2024-04-02 17:24:24 first comment was 3 months ago. repo is still active (had commit yesterday), but no response about this 2024-04-02 17:24:44 Try asking on IRC (#yambar on libera I think) 2024-04-02 17:25:04 aight, will give it a try 2024-04-02 17:25:17 If not that, then #foot 2024-04-02 17:25:27 either way, i made a pkg for my own use, updated with git 2024-04-02 17:25:36 let me know if you guys want me to make a mr 2024-04-02 17:32:49 i reached out to the yambar developer on irc, if he responds i'll let you guys know 2024-04-02 20:28:17 Hi, I think something is wrong with gitlab. It just returned me a 500 when I tried to create a merge request 2024-04-02 20:28:37 It's working again, but it took a very long time before and one request eventually returned a 500 2024-04-02 20:31:56 Seems like gitaly timed out 2024-04-02 20:32:44 But I don't see an excess of 500 responses for gitlab 2024-04-02 21:09:03 Thermi: sometimes happens when you try to merge two branches that have significant commit differences. if you're targetting master, rebase your local copy first, and if you're targetting another branch add &merge_request[target_branch]= so it doesn't first try and make it to master 2024-04-02 23:40:00 Does anyone have bandwidth to help me investigate why libcaesium (rust library) is failing to package? End-goal is packaging Caesium Image Compressor for edge, since it (IMO) is in a class of its own for image compression/conversion, especially where large libraries are concerned. 2024-04-02 23:40:02 https://github.com/Lymphatus/libcaesium/issues/19 2024-04-03 09:43:52 argh! I hate circular dependencies 2024-04-03 15:55:05 is somebody taking care of removing redis from main? 2024-04-03 15:55:52 i saw there's already a MR for redict, it should replace it imo 2024-04-03 15:57:03 Lets first git redict merged and ready for main 2024-04-03 15:57:06 s/git/get 2024-04-03 15:57:26 ill give it a review after lunch 2024-04-03 16:31:07 yes, i wasnt sure if I should immediatly replace redis with redict 2024-04-03 16:37:29 Not immediately, but before the next release at least (in may) 2024-04-03 16:38:42 alright 2024-04-03 17:02:25 thanks for the package fossdd, i was about to do it myself and for once I thought about checking the opened MR 2024-04-03 17:03:21 yeah, haha 2024-04-03 17:07:57 posix shell question 2024-04-03 17:08:23 i I have lots of lines with spaces, how do I convert those to args. 2024-04-03 17:08:45 eg: set -- $(something_that_generates_multiplelines) 2024-04-03 17:08:59 xargs 2024-04-03 17:09:54 fossdd: did you just copy the redis apkbuild and s/redis/redict ? 2024-04-03 17:10:06 so: something_that_generates_multilines | xargs? 2024-04-03 17:10:09 ncopa: if you are very certain you control the input and its all safe: eval "set -- $foo"; echo "$@" 2024-04-03 17:10:13 bl4ckb0ne: yes more or less 2024-04-03 17:10:23 ncopa: V 2024-04-03 17:10:25 set -- $(printf 'a\nb\nc\n' | xargs) 2024-04-03 17:10:27 please no eval. eval is evil 2024-04-03 17:10:57 ill let a second reviewer go over it but I approved it 2024-04-03 17:11:08 nice 2024-04-03 17:12:09 Or `tr '\n' ' '` 2024-04-03 17:12:31 ikke does not seem to work 2024-04-03 17:12:38 ERROR: glib:glib+core test name does not match any test 2024-04-03 17:13:00 $ meson test --list -C output/ 2024-04-03 17:13:00 ninja: nothing to do 2024-04-03 17:13:00 glib:glib+core / asyncqueue 2024-04-03 17:13:00 glib:glib+core / array-test 2024-04-03 17:13:01 ... 2024-04-03 17:13:21 What's the actual string and what do you want the executed command to be 2024-04-03 17:13:22 I tested what I pasted and $1, $2 and $3 were set 2024-04-03 17:13:56 i need to filter the list and then: meson test -C output/ "glib:glib+core / array-test" "glib:glib+core / asyncqueue" 2024-04-03 17:14:13 but I think I can xargs it 2024-04-03 17:14:29 there is an xargs -0 something 2024-04-03 17:14:42 that requires the input to also have 0-bytes 2024-04-03 17:15:59 ncopa: so the list contains lines like "glib:glib+core / array-test"? 2024-04-03 17:16:49 xargs also splits on spaces 2024-04-03 17:17:07 yes 2024-04-03 17:17:10 but 2024-04-03 17:17:12 argh 2024-04-03 17:17:22 xaaaaaaargh!!!!! 2024-04-03 17:17:37 please someone stop me before I throw the computer out the window 2024-04-03 17:17:45 ERROR: glib:glib+core / array-test test name does not match any test 2024-04-03 17:17:47 not one xaaarg, but multiple xaaargs 2024-04-03 17:18:06 how do I skip tests with meson? 2024-04-03 17:18:36 Post somewhere that meson is inferior because it cannot skip tests 2024-04-03 17:18:51 see how soon people react: P 2024-04-03 17:20:11 Putting it into google and noticing the first SO link, I now see exactly the path that ncopa has followed :D 2024-04-03 17:20:12 could you set $IFS to \n only? 2024-04-03 17:20:44 liske: IFS does not affect xargs 2024-04-03 17:21:08 On bash I'd split the string on newlines into an array, then splat that array into the meson invocation. Don't know about posix sh 2024-04-03 17:21:33 The only array you have in posix is $@ 2024-04-03 17:21:39 Right 2024-04-03 17:21:43 and you use set to manipulate it 2024-04-03 17:23:52 OIFS=$IFS; IFS=$'\n'; for t in $(..); set -- "$@" $t; done; IFS=$OIFS 2024-04-03 17:23:59 Something like that? 2024-04-03 17:25:16 That does work for me 2024-04-03 17:25:29 IFS=$'\n'; for x in $(printf 'abc / def\nghi / jkl\n'); do set -- "$@" "$x"; done 2024-04-03 17:25:42 ($'\n' is not posix, but ash supports it) 2024-04-03 17:30:35 I guess ncopas pc is RIP 2024-04-03 17:31:02 ikke: IFS=$'\n'; set -- $(printf 'abc / def\nghi / jkl\n') <= should create the same, shouldn't it? 2024-04-03 17:31:49 liske: probably yes 2024-04-03 17:32:21 yup, it does 2024-04-03 18:14:17 ncopa: tbh I get pinged for meson mentions but you can ping me directly 2024-04-03 18:14:31 this is a UX issue although I'm not sure how to solve it better 2024-04-03 18:15:06 meson is saying, the test is subproject="glib"; suite=["glib", "core"]; name="array-test" 2024-04-03 18:15:34 the --list output is unfortunately NOT suitable as input to `meson test ...` 2024-04-03 18:15:43 (it would be nice if it was) 2024-04-03 18:16:50 you want `meson test glib:array-test glib:asyncqueue` 2024-04-03 18:17:15 hey, if I try to index a apk I get 'package file format error'. any clue what the hell apk wants from me? 2024-04-03 18:17:23 logs here: https://gitlab.alpinelinux.org/fossdd/aports/-/jobs/1329026 2024-04-03 18:17:55 fossdd: might be a bug in apk-tools 2024-04-03 18:18:06 a new version was just released this week 2024-04-03 18:18:09 huh 2024-04-03 18:18:30 ikke: tell jtojnar on https://github.com/mesonbuild/meson/pull/11502#discussion_r1538214710 that you want it rebased and merged anyway? :D 2024-04-03 18:21:28 elibrokeit: what I'm trying to do is skip a few tests that requires apps that again needs glib (hello darkness my old circular friend...) 2024-04-03 18:24:11 fossdd: can you share the apk that it fails to index? 2024-04-03 18:25:19 should be in the job artifacts: https://gitlab.alpinelinux.org/fossdd/aports/-/jobs/1329026/artifacts/download 2024-04-03 18:56:17 oh was a problem upstream! 2024-04-03 18:56:25 oh? 2024-04-03 18:56:48 yeah hiredict forgot to update the HIREDICT_SONAME variables for the new release 2024-04-03 19:22:41 have you guys considered using compressed firmware on `linux-firmware` package? 2024-04-03 19:23:02 i haven't tried doing that, but might be worth a try 2024-04-03 19:23:08 1.1G /lib/firmware/ 2024-04-03 19:27:50 whoa what if we used XZ compression 2024-04-03 19:28:40 (too soon?) 2024-04-03 19:29:21 rdbo: in seriousness, linux-firmware pulls in everything. we split it up so that you can do `linux-firmware-radeon` for example 2024-04-03 19:30:31 rdbo: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/60282 2024-04-03 19:51:20 hmm 2024-04-03 19:54:45 Arnavion interesting, looks like what i would want. usually i would use xz but uhhh... maybe zstd is the right choice lol 2024-04-03 20:26:27 zstd is probably the move at this point, more eyeballs, sponsored by facebook etc 2024-04-03 20:28:28 on the contrary, there's never been a better time to stick with xz 2024-04-03 20:28:42 xz will get *a lot* of scrutiny now 2024-04-03 20:29:03 for all the wrong reasons, obviously, but that's what will happen 2024-04-03 20:29:57 Someone needs to take it over first and gather support for their takeover, because current maintainers' (plural) credibility is shot 2024-04-03 21:11:31 skarnet, reminds me of the series of openssl fiascos, after which it in some ways became a better choice 2024-04-03 21:15:22 failure-driven development 2024-04-03 23:12:48 I found zstd a few years ago when I found xz to be way too slow for my purposes 2024-04-03 23:14:04 xz used to be my goto compression algo 2024-04-04 01:54:36 don't know if important , redict seems to have commits order but tags/branches are missing during cloning process 2024-04-04 01:57:10 nope, not original fork 2024-04-04 04:50:02 Isn’t the container format for xz also a mess? 2024-04-04 09:03:07 Hi, can i get !63392 merged please, i've already given it my approval, but can't seem to get rid of the unresolved thread 2024-04-04 10:20:09 celie: merged 2024-04-04 10:21:06 fossdd: redict fails to build: https://build.alpinelinux.org/buildlogs/build-edge-x86_64/testing/redict/redict-7.3.0-r1.log 2024-04-04 10:32:28 oh, i look into it 2024-04-04 11:22:45 ikke: i couldn't reproducicle the issue. I guess a rebuild might fix it. 2024-04-04 11:23:11 also weird is that is only affects x86_64 2024-04-04 11:29:11 can be some race condition 2024-04-04 11:29:48 yes matbe 2024-04-04 11:29:50 *maybe 2024-04-04 11:30:43 It will be rebuild soon 2024-04-04 11:32:26 alright thx 2024-04-04 13:09:34 autojoin add 2024-04-04 17:21:26 did redict now rebuild? because the log still has the issue 2024-04-04 17:22:18 It's blocked by code-oss atm 2024-04-04 17:22:26 ah 2024-04-04 17:22:42 You can see the status at https://build.alpinelinux.org/ 2024-04-04 17:23:07 yes just wasn't sure 2024-04-04 17:23:10 np 2024-04-04 19:26:44 I'm currently tinkering with https://github.com/davmac314/dinit on my alpine 2024-04-04 19:26:53 and I have a running system with it 2024-04-04 19:27:03 it's very convenient, well documented and easier to use than s6 2024-04-04 19:27:10 could be a good opportunity for a openrc replacement 2024-04-04 19:27:18 most services are 3 lines files 2024-04-04 20:00:49 that looks neat 2024-04-04 20:00:57 can it run as PID 1? 2024-04-04 20:15:04 yup, it boots my laptop right now 2024-04-04 20:27:15 neat 2024-04-04 21:17:33 ERROR: gobject-introspection-1.78.1-r0: trying to overwrite usr/lib/girepository-1.0/GLib-2.0.typelib owned by glib-2.80.0-r0. 2024-04-04 21:17:35 anyone? 2024-04-04 21:18:33 surprisingly, seems to happen only on aarch64 2024-04-04 21:20:45 ptrc: i think it's everywhere: https://pkgs.alpinelinux.org/contents?file=GLib-2.0.typelib&path=%2Fusr%2Flib%2Fgirepository-1.0&name=&branch=edge 2024-04-04 21:23:41 yeah. 2024-04-04 21:24:45 https://bpa.st/CLOQ is my output 2024-04-04 21:28:00 ah 2024-04-04 21:28:03 hm 2024-04-04 23:50:12 my glib-2.78.4-r1 doesn not have that file 2024-04-04 23:53:39 something with 66e193260a0c97dd8274841ecb3712782215e152 I assume? 2024-04-04 23:54:26 oh !63522 2024-04-05 10:38:05 i think glib needs replaces=gobject-introspection 2024-04-05 10:38:47 or soemthing 2024-04-05 10:39:08 i need to take an alpine free day. please feel free to merge whatever is needed 2024-04-05 10:40:23 ncopa: enjoy, and try to not get too stressed about things 2024-04-05 11:52:53 wftfy 2024-04-05 12:02:08 !63371 has been merged 20h ago but there is still no apk for x86_64. Did something go wrong or do I need to be more patient? 2024-04-05 12:03:00 The other platforms are all complete. 2024-04-05 12:06:02 fraolt: the builder was blocked 2024-04-05 12:06:12 3 / 12 (25%) 2024-04-05 12:06:50 after that is finished, it should become available (but it's now building electron, which takes a while) 2024-04-05 12:08:16 ikke: Thank you for unblocking! :) 2024-04-05 12:14:46 fraolt: if you enjoy watching paint dry, you could monitor build progress at https://build.alpinelinux.org/ 2024-04-05 12:20:49 ovf: Very calming. :) Thanks for the link! 2024-04-05 12:21:49 presumably i guess logs could be streamed live, which would be more entertaining 2024-04-05 12:22:17 They kind of were for x86_64 (because that builder was hosting them), but that's no longer the case 2024-04-05 12:34:38 Well, if you click on an activity you can see the logs. Currently, two packages are "Signing the index..." 🤞 2024-04-05 12:34:53 Yes, but only after the package has been built 2024-04-05 12:34:54 not during 2024-04-05 12:35:37 Ah ok! I see. So "Signing the index..." means done. 2024-04-05 12:35:51 I thought there were three builds in parallel. 2024-04-05 12:36:18 signing the index is the last operation of the build 2024-04-05 12:36:27 So that means it's finished 2024-04-05 12:36:36 The builders are sequential, only build one package at the time 2024-04-05 12:36:53 Building packages in parallel is hard to do 2024-04-05 12:37:11 Ok. 2024-04-05 12:38:13 by the way i also felt that perhaps there could be a more obviously terminating line in the logs, like "done". 2024-04-05 12:38:39 especially the ellipsis in "signing the index..." make it look like there's more coming 2024-04-05 15:13:24 How am I supposed to use the musl-dbg package? Should I just make /lib/ld-musl-x86_64.so.1 a link to /usr/lib/debug/lib/ld-musl-x86_64.so.1.debug? or is there a less invasive way of using the debug version locally for one process? 2024-04-05 15:14:00 (or should I do everything in a /usr/lib/debug chroot?) 2024-04-05 15:14:19 skarnet: they are detached dwarf files 2024-04-05 15:14:32 skarnet: your debug info consumer is supposed to know about separate debuginfo 2024-04-05 15:14:54 please speak to me in layman's English 2024-04-05 15:15:11 gdb and perf should magically just do the right thing and pick those up 2024-04-05 15:15:11 skarnet: gdb knows to look for that file to find the debug symbols for musl 2024-04-05 15:15:48 does it mean that once I've installed the package, I have nothing to do and gdb will automatically use the file? 2024-04-05 15:16:07 given that you run gdb after you installed the package 2024-04-05 15:16:19 ... yes, running gdb is the plan. 2024-04-05 15:16:26 hey, is there someone who could merge !57928? 2024-04-05 15:16:33 if it's automagic, that's awesome. Thanks! 2024-04-05 15:16:56 skarnet: I meant that if you install it while gdb is running, you need to tell it somehow to reload the symbols 2024-04-05 15:17:57 i understand it might be out of scope for alpine, but i'd still like 0) debug packages for everything 1) either include source in those or have yet another split package with it 2024-04-05 15:18:18 debugging is a bit more fun with source code 2024-04-05 15:18:19 ovf: despite popular believe, storage is not cheap 2024-04-05 15:19:16 skarnet: also, the -dbg package needs to match the installed musl version 2024-04-05 15:19:16 storage or bandwidth? 2024-04-05 15:19:21 ovf: storage 2024-04-05 15:19:34 We don't generally have bandwidth issues 2024-04-05 15:20:15 storage IS cheap. Hosted, redundant storage, on the other hand... 2024-04-05 15:20:31 skarnet: the kind that matters in practice 2024-04-05 15:20:56 for distribution storage purposes, yeah, definitely 2024-04-05 15:21:54 i think typically others (e.g. archlinux) only host debug packages on a few 'cheap' (read: donated) mirrors, which somewhat solves the cost problem (or at least stops it from being passed on to every mirror) 2024-04-05 15:22:20 it's just that when people (me included) say "storage is cheap" we mean local disk in comparison to RAM, we don't mean that adding a 1 TB drive to your server is cheap 2024-04-05 15:23:28 i'll be happy to chip in a bit (either opex or capex) if there's general interest 2024-04-05 15:23:55 Most servers we have have <500G of storage 2024-04-05 15:23:58 there are execptions 2024-04-05 15:24:30 ovf: the main challenge is our build architecture 2024-04-05 15:25:38 at the moment, the builders keep all built packages locally 2024-04-05 15:26:24 There is a desire to change it, but it's challenging 2024-04-05 15:29:51 hm, and looks like the recently created alpine-adjacent distribution which i probably shouldn't name here builds everything with debuginfo, though of course their repositories are way smaller (both in terms of package count and lack of stable releases) 2024-04-05 15:31:40 i have to say i'm very grateful for alpine's build infra as it is -- i even get a free ride when submitting patches to gitlab. 2024-04-05 15:32:52 ikke: gdb doesn't print any more information when going into musl functions after installing musl-dbg 2024-04-05 15:33:01 there must be an additional step 2024-04-05 15:33:34 skarnet: do you see that it mentions loading debug info? 2024-04-05 15:35:03 no, but it's ok, my bad, pebkac issues. I'll fix my shit and get back to you if needed. :) 2024-04-05 17:26:16 Ariadne: Any objection to !61521 2024-04-05 19:43:54 no :) 2024-04-05 20:25:18 Ariadne: thanks 2024-04-06 11:09:06 How would I go about creating a new team on the Alpine GitLab? 2024-04-06 11:10:00 look at my MR to https://gitlab.alpinelinux.org/alpine/infra/gitlab-tf 2024-04-06 11:10:24 thanks 2024-04-06 15:23:01 !63636 if anyone's interested in picking that up 2024-04-06 18:19:57 omni: I dont mind picking it up. Seems like an interesting project. 2024-04-06 18:20:32 Huh why is my nick wrong 2024-04-06 18:23:45 Guest16: if you picked a nick that's already in use, you get renamed to Guest 2024-04-06 18:24:54 Just checked the oftc buffer and saw this 2024-04-06 18:24:57 #alpine-offtopic You may not change nickname while banned or moderated on a channel (+b/+q/+m/+M/+R) 2024-04-06 18:25:28 Not entirely certain how I would have been banned, or what for. (This is durrendal btw) 2024-04-06 18:25:47 Guest16: We added +M/+R on some channels to reduce spam 2024-04-06 18:25:57 Guest16: are you identified with nickserv? 2024-04-06 18:27:34 Yes I should be. I have a regain and SSL cert auth on my nick. It is from a few days ago though. Let me reconnect and see if that fixes it 2024-04-06 18:28:12 Maybe? 2024-04-06 18:28:18 now it's good 2024-04-06 18:28:34 :) thank you ikke. Haven't run into that one before 2024-04-06 19:06:04 fakeroot seems to hang for me in docker. It appears to close file descriptions forever 2024-04-06 19:06:06 I keep running into issues like this, heh. 2024-04-06 20:21:37 omni: thanks 2024-04-06 20:41:25 -*+-+*-+ 2024-04-06 21:05:52 oops.. 2024-04-06 21:10:45 ¨°Oo._ 2024-04-06 22:06:21 I have some packages that are in testing for quite a while. Should I move them to community? 2024-04-06 22:08:24 sure 2024-04-06 22:09:54 btw, when should I move redict to main? I guess before the May release, right? 2024-04-06 22:10:23 maybe not yet, test the package a bit 2024-04-06 22:10:31 remplacing redis will take time 2024-04-06 22:10:46 okay, sure 2024-04-06 22:11:28 and testing 2024-04-06 22:12:14 could probably go incrementally, move it to community and start replacing redis mentions to redict on testing/community 2024-04-06 22:13:19 ah, mhmm 2024-04-06 22:36:03 got the list of python 3.12 rebuilds down to around 130 today 2024-04-06 22:36:07 https://dev.alpinelinux.org/~ptrc/pending_rebuild.txt 2024-04-06 22:36:21 only 11 fail on build 2024-04-06 22:36:49 most of them because there's some native compilation error i wasn't able to figure out 2024-04-06 22:37:43 fairly confident we can fix the rest of them before the next alpine release :) 2024-04-06 22:43:58 if anyone wants to throw some ideas my way, the logs are in https://dev.alpinelinux.org/~ptrc/py3.12_logs/ 2024-04-06 22:44:48 can you point to an example that fails? 2024-04-06 22:45:19 https://dev.alpinelinux.org/~ptrc/py3.12_logs/aws-cli.log 2024-04-06 22:47:16 i've got no clue :) 2024-04-06 23:00:22 fwiw, if anyone wants to help with the rebuilds, the following kinda works: https://gitlab.alpinelinux.org/-/snippets/1148 2024-04-07 02:14:57 fossdd: it's always a good idea to take a look at build output of MRs, not just that they're green, the !63649 had a soname change and that means that aports depending on that need rebuilds 2024-04-07 02:16:07 you can find out which ones with, in this case, `apk list --depends so:libyang.so.2` 2024-04-07 11:15:05 oh, yes, I forgot to do that 2024-04-07 11:52:46 as did ptrc ;) 2024-04-07 11:54:30 happens every now and then, but since you're knew I thought you maybe even didn't know to look 2024-04-07 12:01:35 yes i usually ripgrep'ed aports, but apk list --depends is also pretty cool 2024-04-07 13:22:47 ncopa: what was the reason for upgrading cython on your py3.12 branch to 3.x? it breaks almost everything that uses cython currently 2024-04-07 13:23:09 as in, can we do the 3.12 upgrade without it? 2024-04-07 13:43:35 Maybe it was due to lxml 5? i think upstream uses Cython 3 for that but i've never looked into whether it would still build with the old Cython 2024-04-07 13:44:54 Also related to Cython 3, i've come across: https://github.com/MagicStack/httptools/issues/98 seems like Fedora just unpinned the Cython version 2024-04-07 13:48:54 Ah, looking through the open MRs mentioning Cython: !59224 2024-04-07 13:49:35 and it seems SciPy too now requires Cython 3: !63594 2024-04-07 14:10:15 *requires* Cython 3, huh 2024-04-07 14:10:18 wel 2024-04-07 14:10:20 well* 2024-04-07 14:10:49 maybe it would be better to actually relax the dependencies a bit and see if everything actually works with Cython 3 2024-04-07 14:23:09 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63703 re-applies a patch for an old CVE 2024-04-07 14:23:20 !63703 2024-04-07 14:24:51 been awhile - forgot the ! 2024-04-07 14:25:19 no worry 2024-04-07 14:25:34 ikke: I can submit for the previous stables - how far back? 2024-04-07 14:25:47 3.16 2024-04-07 14:25:53 k 2024-04-07 14:27:01 let me know if you need any changes to it 2024-04-07 14:27:37 pkgrel bump 2024-04-07 14:28:05 of course will do 2024-04-07 14:30:28 fixed 2024-04-07 14:32:34 You may also want to add secfixes 2024-04-07 14:32:39 https://security.alpinelinux.org/vuln/CVE-2013-4407 is funny 2024-04-07 14:35:42 ikke: okay - the CVE details are inaccurate - a message was sent to oss-security this morning from cpan-security 2024-04-07 14:36:36 You can at least declare what alpine versions have the fix 2024-04-07 14:38:29 with the secfixes you mean or in the MR? 2024-04-07 14:43:50 secfixes in the MR 2024-04-07 14:44:26 our secdb extracts that information and security.a.o ingests that 2024-04-07 14:47:31 !63705 and !63703 updated with secfixes - I believe that's correct 2024-04-07 14:47:53 Yes, noticed it 2024-04-07 15:17:12 !63708 and !63710 for 3.17 and 3.16 2024-04-07 15:21:06 merged 2024-04-07 15:41:56 could we introduce cython3 and gradually move aports over? 2024-04-07 20:25:57 i mean, stuff doesn't link / depend on cython, does it? 2024-04-07 20:26:04 having both would be the best here imo 2024-04-07 20:26:25 i agree 2024-04-07 21:04:48 Does anyone recall there being some (build) issues with a recent libxml upgrade? (!63383) 2024-04-07 22:04:39 ikke: on void we saw a bunch of issues because they reorganised a bunch of headers 2024-04-08 05:16:47 fossdd: ansible lint upstream checksum has changed apparently 2024-04-08 05:20:23 retagged, only change is the git_archival.txt file 2024-04-08 05:32:27 Moved the cached version on distfiles 2024-04-08 05:40:52 good morning! ptrc: there was some dep that required cython 3. I don't remember which. I think I eevn tried to fix somethig of cython 0.x but realized that it woudl be a fight against upstram which moved to cython 3. 2024-04-08 05:41:35 so we are basically bumping into issues due to python 3.12, pytest 8 and cython 3. Its probably the reason why we have 3 times more breakages than usual 2024-04-08 05:45:44 ncopa: we're not the only ones struggling 2024-04-08 05:45:47 gentoo and arch as well 2024-04-08 05:50:15 it is worse than usual atm 2024-04-08 05:50:18 definitely 2024-04-08 05:50:33 plus gcc 14 upcoming... 2024-04-08 05:53:22 im glad we didnt aim for gcc 14 2024-04-08 05:54:05 i mean, i think we did mention gcc 14 early, but we cannot do that until after 3.20 2024-04-08 05:55:03 its actually good that gentoo and arch and alpine are in this together. and put preasure on upstream to no simply lock their version dependcies to python 3.11, pytest7 and cython <3. 2024-04-08 05:56:19 ptrc: im am so grateful for your help with python 3.12 2024-04-08 06:15:01 yes, so important we work together on stuff like this 2024-04-08 06:15:59 ikke: yes noticied. thanks! 2024-04-08 06:17:14 do we have any contact for s390x? 2024-04-08 06:17:31 its currently blocking a security fix: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63725 2024-04-08 06:26:19 so we have a pytest7, incase there are any "unfixable" python packages. Looks like we have use for it: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63717 2024-04-08 06:35:48 seems to be an insane amount of work that has happened over the weekend! you people rock! 2024-04-08 06:57:04 re cython, I think we can add a cython0 if needed 2024-04-08 08:56:29 nmeum: any interest in pushing river to community? 2024-04-08 09:12:30 invoked: yes, but it requires pushing zig to community first and given the current instability of zig I am not sure if we want to include it in a -stable release 2024-04-08 09:14:57 not sure what lauren (the current zig maintainer) thinks about this, maybe consider opening an issue so that it can be discussed there 2024-04-08 09:36:02 ptrc: I may have messed up https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63055 while repasing it 2024-04-08 09:36:22 oh, it was already messed up 2024-04-08 09:36:25 seems like it does need the patches I removed 2024-04-08 09:36:28 or something 2024-04-08 09:36:40 as in, the upgrade can't go through, and i was thinking of patching the current version instead 2024-04-08 09:36:52 ok 2024-04-08 09:36:56 at least until the nitrokey stuff supports the new version 2024-04-08 09:37:20 ok. 2024-04-08 09:37:35 I tried to build it from git master but it failed 2024-04-08 09:37:49 but I see no why it failed: NO TESTS RAN 2024-04-08 09:39:48 Ran 0 tests in 0.000s 2024-04-08 09:40:00 when it passes on edge with python 3.11 2024-04-08 09:41:03 yeah, 0 tests wasn't a failure case back with 3.11 2024-04-08 09:41:08 it started failing with 3.12 2024-04-08 09:44:36 there are a few tests that are failing if I switch to pytest, but majority passes 2024-04-08 10:04:32 ocrmypdf fails in current git master. seems like tessereact is broken 2024-04-08 10:05:29 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62113 2024-04-08 12:01:27 It seems upgrading py3-apsw to the latest version (which also matches the version of sqlite) fixes the failing test: !63752 2024-04-08 12:02:32 and i found a patch from a pull request for !63753, not sure if it fixes all the errors on Python 3.12 though 2024-04-08 12:24:56 ncopa: Maybe you're also working on this, but i have !63754 (tested it locally, and it should fix !63749) 2024-04-08 12:33:28 cely: ah! nice 2024-04-08 12:34:15 ptrc: i know why cython was upgraded. cython 0.x.y: ModuleNotFoundError: No module named 'imp' 2024-04-08 12:34:35 ah, i can probably patch that out 2024-04-08 12:35:19 i think a cython0 package could be useful 2024-04-08 12:36:37 https://dev.alpinelinux.org/~ptrc/py3.12_logs/py3-hglib.log seems to be an error in mercurial hg 2024-04-08 12:37:18 Should be related to: https://github.com/dgrunwald/rust-cpython/issues/294 2024-04-08 12:37:27 i think we can delete py3-hglib. nothing uses it 2024-04-08 12:37:42 and it appears to be dead upstream 2024-04-08 12:37:53 Unfortunately, https://github.com/dgrunwald/rust-cpython now displays a warning that Python 3.12 is not supported 2024-04-08 12:38:35 and rust-cpython is used in mercurial 2024-04-08 12:38:45 So, mercurial is very likely also not working for Python 3.12 2024-04-08 12:38:51 At least, the Rust part 2024-04-08 12:38:54 lets delete mercurial 2024-04-08 12:38:56 :) 2024-04-08 12:39:01 Hehe 2024-04-08 12:43:19 i am half serious 2024-04-08 12:47:01 https://repo.mercurial-scm.org/hg/file/6.7.2/rust/README.rst#l36 2024-04-08 12:47:09 "If the environment variable ``HGWITHRUSTEXT=cpython`` is set, the Rust extension will be used by default unless ``--no-rust``. 2024-04-08 12:47:23 One day we may use this environment variable to switch to new experimental binding crates like a hypothetical ``HGWITHRUSTEXT=hpy``." 2024-04-08 12:47:43 I guess we'll just have to build mercurial with --no-rust for Python 3.12, as cpython doesn't support it 2024-04-08 12:47:59 sounds good 2024-04-08 13:07:51 Seems like --no-rust is used while running hg, but i think there's no point building the Rust extensions for Python 3.12 if they're not going to work anyway: !63757 2024-04-08 13:08:05 Marked as draft because i'm not sure if we want that now, or only when Python 3.12 lands 2024-04-08 13:34:55 !63755 2024-04-08 13:35:22 If someone can take a look, thanks 2024-04-08 18:24:48 Hi, I have done one thing but I may need assistance now 2024-04-08 18:25:06 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63762 upgrade thelounge app and some refactor 2024-04-08 18:25:31 I could enable "all" arch but at cost of compiling the sqlite3 (using the "npm_config_build_from_source" worked) 2024-04-08 18:26:02 but I can not test it on other platforms rather than x86_64 and Im not sure about the package size/contents, well I hope it is fine 2024-04-08 18:27:35 Would be good to get feedback from the maintainer 2024-04-08 18:30:44 ah yes nice, thanks, lets wait for it as well, hope I didnt messup 2024-04-08 18:31:40 fabricionaweb: would be good to explain what the goal of refactoring is (in the MR) 2024-04-08 18:36:19 yeah I will improve the description for that! thanks 2024-04-08 18:56:24 ikke: thanks for merge 2024-04-08 18:57:17 yw 2024-04-08 19:50:18 I updated the mr description 2024-04-08 20:14:40 Pipeline status updates are not working sometimes in the "pipelines" view, but in the specific pipeline view they are shown correctly 2024-04-08 20:15:23 (popup on "Stages" shows pipelines paused/waiting (https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/45752/pipelines), but view here shows only riscv64 is waiting https://gitlab.alpinelinux.org/Thermi/aports/-/pipelines/225133) 2024-04-08 20:15:45 Known issue, it's some caching 2024-04-08 20:15:56 Thank you 2024-04-08 20:16:12 I also see it on another gitlab instance 2024-04-08 20:30:53 has anyone reported this on gitlab yet? https://mastodon.gamedev.place/@amonakov/112237430408232869 2024-04-08 20:34:32 ptrc: not yet, but maybe similar issue I noticed with fakeroot 2024-04-08 20:34:46 hmm, or not 2024-04-08 20:35:07 but, I have not seen any report yet 2024-04-08 20:39:58 ncopa, ptrc: https://github.com/projg2/unittest-or-fail/blob/master/unittest_or_fail.py is used on gentoo to guarantee that "zero tests" successfully fails 2024-04-08 20:41:15 i mean, we're seeing the same behaviour by just running unittest with py3.12 2024-04-08 20:41:29 maybe we should have adopted that / something similar 2024-04-09 02:12:32 right, it's only used for python less than 3.12 here 2024-04-09 02:12:55 though Gentoo does support many versions of python at the same time 2024-04-09 02:13:49 in theory it might be useful to quickly filter what's not a problem because it was fine on 3.11 vs "real regressions" 2024-04-09 02:13:59 in practice it is likely easy to eyeball 2024-04-09 08:34:25 ptrc: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15966 2024-04-09 09:03:33 Btw: Is there a tool I could use after having a commit that upgrades libfoo to bump the pkgrel in all APKBUILDs that depend on libfoo-dev and create one commit per bump with sensible commit messages (e.g. community/bar: rebuild against libfoo)? 2024-04-09 12:10:22 py3-networkx does not build. any volunteers? 2024-04-09 12:11:16 it coudl be updated to 3.3, but needs fix tests 2024-04-09 12:11:51 hm, it built for me, but i might have skipped the tests 2024-04-09 12:11:57 don't remember exactly 2024-04-09 12:12:06 but then, the tests for all packages dependent on it have passed 2024-04-09 12:17:46 maribu: i usually create a shell oneliner 2024-04-09 12:28:34 could be some dep to py3-networkx that changed recently 2024-04-09 12:30:18 26 tests fails 2024-04-09 12:30:31 and they dont pass with pytest7 2024-04-09 16:00:43 Must say, I love fzf --preview 2024-04-09 17:20:56 ncopa: could you ping https://github.com/protocolbuffers/protobuf/issues/8460? AFAICT it wasn't fixed: https://ptrc.gay/hHTHGtHs 2024-04-09 17:22:31 ( as in, i built this *just now* on Alpine edge x86 chroot and it still fails in the exact same way ) 2024-04-09 17:22:58 just that one test though, so we can slim down the `skip-failing-tests.patch` a little 2024-04-09 18:45:34 Could somebody please review these two aport add MRs? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61489 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62090 2024-04-09 19:49:21 package up for adoption: !63831 2024-04-09 19:49:34 if anyone uses hime and would want to maintain that + libchewing, that would be nice ^^ 2024-04-09 19:49:50 ( maintainer of hime seems inactive ) 2024-04-09 20:02:58 how are we dealing with CVEs give NVD database situation 2024-04-09 20:04:14 what nvd database situation? 2024-04-09 20:07:29 https://nvd.nist.gov/general/news/nvd-program-transition-announcement 2024-04-09 20:09:13 So mostly about analysis of CVEs 2024-04-09 20:09:25 Which we are not relying on 2024-04-09 22:10:31 ncopa: taskwarrior 3 seems brakey https://taskwarrior.org/docs/upgrade-3/ 2024-04-09 22:11:46 so I wonder if current taskwarrior should first be bumped with an informational dialogue about running `task export > all-tasks.json` before taskwarrior 3 upgrade 2024-04-09 22:13:10 or perhaps a task2 aport should be made available for people to be able to get out of a pickle 2024-04-09 23:10:40 as a taskwarrior user, the task2 way makes more sense to me 2024-04-09 23:11:11 but i don't think we can gracefully move people to task2, can we 2024-04-09 23:11:21 in some automagic way 2024-04-09 23:13:06 no.. the way I thought it would that the taskwarrior 3 upgrade would come with a notice to install task2 to make a backup with `task2 export > all-tasks.json` 2024-04-09 23:13:07 i run taskd too, and i suspect other people who run taskd aren't going to want to move to task3 anytime soon. 2024-04-09 23:15:05 ah. well the problem with that is it sounds like taskd isn't in the build anymore, so that's another thing. 2024-04-09 23:15:46 oh wait, that's separate anyway, right? nevermind, i'm high (low oxygen level). 2024-04-09 23:15:57 yeah... I currently don't use it myself, but thought about it and wanted to give ncopa a heads-up in case someone opened an MR for an upgrade 2024-04-09 23:17:57 it just won't use taskd anymore, which is fine. but once the user runs 'task' (if they didn't read), it's too late. 2024-04-09 23:20:08 i'll have to test that and see what it actually does. it sounds like it just changes the data on first run automatically. 2024-04-09 23:20:44 (which, if unprompted, is unfortunate) 2024-04-09 23:21:29 this comment made it seem like data wouldn't be gone https://lobste.rs/s/zhbe55/taskwarrior_3_0_released#c_jfvbyw 2024-04-09 23:21:43 just inaccessible with the new taskwarrior 3 2024-04-09 23:23:14 yeah, that's ok then. 2024-04-09 23:23:32 what you suggested (task2) would probably be best then 2024-04-09 23:25:11 it'd be nice if we can just do a package rename and take everyone to it. 2024-04-09 23:25:45 i don't know these things about apk. 2024-04-10 01:55:21 re^ taskwarrior, would suggest, keep task.apk as is for al.v3.20, add task3.apk. Move task.apk to testing/task2.apk and task3 to community/task.apk in al v3.21, any additional update/upgrade msg should be helpful 2024-04-10 01:55:58 optionally, task3 can go in testing/ 2024-04-10 04:51:44 Can I interest anyone in !62101? 2024-04-10 05:12:00 Not sure if this would be the right place, but there's an issue with the setup-disk script that for some reason is causing corruption to the Alpine Linux system. What I mean is, if you want to install to a specific partition on a hard drive already pre-made and formatted with ext4 (512 gb), this assumes that you've already ran setup-alpine, and you decide to setup a desktop, it simply won't work. The thing is, I tested 2024-04-10 05:12:00 lightdm on the USB directly and it worked, but after installing to the partition using setup-disk -m sys /mnt AS IS, it does not work because of the accountsservice package not providing any .service files or whatever. Even after reinstalling the issue still persists, even reinstalling lightdm, and the xfce packages. These issues only started occurring after running ``setup-disk -m sys /mnt``, and the way I mounted the 2024-04-10 05:12:01 partition was ``mount /dev/sda4 /mnt``. I've even launched KDE Plasma (x11) directly through xinit, and it worked, although launching Firefox did not work (it was continually stopping and starting firefox sub-processes, no webpages could be viewed it was just a blank white screen) so in turn it could also cause a heap of other issues. 2024-04-10 05:16:53 To be more specific, and straight to the point, lightdm on the USB works, but it doesn't after running setup-disk and rebooting to alpine. 2024-04-10 05:21:36 This was done using 3.19.1 version of Alpine, by the way. Downgrading to 3.18.6 did not fix this issue. 2024-04-10 06:17:32 sounds like it stores state that is not transferred when doing setup-disk 2024-04-10 06:17:59 by default setup-disk will use lbu to collect data to transfer to disk, and lbu will ignore anything under /var 2024-04-10 06:18:29 so you could check what is under /var 2024-04-10 06:19:08 and the do something like: lbu include /var/lib/foo 2024-04-10 06:19:15 before running setup-disk 2024-04-10 06:19:35 or simply: lbu include /var 2024-04-10 09:09:48 would be nice if anybody could investigate how to move forward with xz https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63132 2024-04-10 09:10:54 i heard someone freebsd (or some one else?) reverted to 5.4.x + backported the new symbols so it was ABI compatible with current 5.6.x. That would be the best way forward short time 2024-04-10 12:48:16 a question I never figured the answer to: is there an equivalent to dpkg -S for apk? iow: given a file of unknown provenance in my filesystem, do I have a simple way of knowing whether it belongs to a package installed by apk (and if yes, which one)? 2024-04-10 12:49:20 I suppose I can apk manifest the world and grep for my file, but is there a more efficient way? 2024-04-10 12:49:33 apk info --who-owns 2024-04-10 12:49:40 ah, thanks :D 2024-04-10 12:49:45 Or -W for short 2024-04-10 15:11:54 Looks like quite a number of aports will not build properly with mbedtls 3.6.0 2024-04-10 15:12:23 Then I suppose we should not upgrade anytime soon to mbedtls 3.6.0 2024-04-10 15:12:32 I've managed to patch main/bctoolbox, community/dillo, and possibly testing/dislocker as well 2024-04-10 15:13:19 and very likely the latest testing/hiawatha (there's a domain change notice on hiawatha-webserver.org) will also work 2024-04-10 15:13:31 ncopa: alpine doesn't want to get into backporting, does it? debian calls it "5.6.1+really 5.4.5-1" but that's normal for debian. i think arch and gentoo just went with 5.6.1 unpatched 2024-04-10 15:14:10 The thing is, mbedtls 3.6.0 is the latest LTS, and if we don't get it into Alpine 3.20, we will have to support the previous LTS for 2 years 2024-04-10 15:14:13 i can't look at gentoo right now because they've got infra problems 2024-04-10 15:14:25 as mbedtls is in main/ 2024-04-10 15:14:44 celie: I was expecting as much, but do we have the bandwidth to handle another high impact upgrade? 2024-04-10 15:15:02 ncopa wants to setup the new builders soon 2024-04-10 15:15:52 Maybe if we upgrade main/mbedtls to 3.6.0 and move all aports that succeed to that (only other aport in main is bctoolbox), and add a community/mbedtls2 for the others that don't work with 3.6.0 2024-04-10 15:16:08 That could buy us some time 2024-04-10 16:07:03 Anyway, i've put what i've done so far regarding mbedtls 3.6.0 (and switching the aports that fail to a community/mbedtls2 aport) into a branch, and passed it on to omni (who has opened !63205) 2024-04-10 16:08:36 If omni does not have time/interest to pursue this (to get it in in time for 3.20), then probably i won't push for it myself 2024-04-10 16:18:47 invoked: I have not had the time to investigate what it would take to downgrade. As I could understand, downgrading would require to either rebuild everything linked to xzlibs, or we'd need to backport the introduced symbols. I'd prefer do the latter 2024-04-10 16:19:03 but as said, I have not had the time to look into it 2024-04-10 16:19:43 it woudl be great if someone (who know what they are doing) has the time to follow that up 2024-04-10 16:29:06 cd .. 2024-04-10 16:38:06 ncopa: now that gentoo's stuff is back up, the log shows they went back to 5.4.2 (the last release signed by lasse collin) 2024-04-10 16:40:15 i'm not a fan of backporting but in this case, i dunno 2024-04-10 16:40:42 kind of an exceptional situation. 2024-04-10 16:49:56 i heard some rumors, dont remember from who, that freebsd (?) did the same, but added a patch to keep the ABI compatible, so they didnt need to rebuild everythink linked to it 2024-04-10 16:50:08 thats what I'd like to do if possible 2024-04-10 16:50:56 If you trust the original maintainer, he's been making commits to undo the malware so you could upgrade instead of downgrade 2024-04-10 16:52:15 that would be the best 2024-04-10 16:54:18 https://cgit.freebsd.org/src/commit/?id=2f9cd13d6c1824633251fb4267c9752d3b044a45 2024-04-10 16:54:26 https://cgit.freebsd.org/src/commit/contrib/xz?id=5ffb19ac36c4b5c9e72d69048250c8e56acff739 2024-04-10 16:55:20 https://cgit.freebsd.org/src/log/contrib/xz 2024-04-10 16:55:34 New to IRC, has anyone responded to the issue that I've stated? 2024-04-10 16:57:37 zeroxvm: Yes, but you had quit before they answered https://paste.rs/LvpnD 2024-04-10 16:58:33 Appreciated, Arnavion. ^^ 2024-04-10 17:17:34 thank you omni 2024-04-10 17:18:26 iirc nothing actually used the symbol which gets lost 2024-04-10 17:18:29 so it's not a problem in reality 2024-04-10 17:18:32 just xz used it, so.. 2024-04-10 17:20:09 so we could just downgrade, and we should be fine? 2024-04-10 17:20:20 yes 2024-04-10 17:20:31 i had the same reservations as you but i couldn't find anything using it 2024-04-10 17:21:00 could you please add a comment on that on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63132? 2024-04-10 17:21:41 ok 2024-04-10 17:23:42 thanks! 2024-04-10 17:56:50 Update on my situation; checked the logs of both sddm and lightdm and they aren't having the issues that they were having before, however the main issue is still prevalent (on-going) where I cannot get into sddm or lightdm once installed onto the partition. I have ran ``lbu include /var`` before setup-disk, and I also ran setup-desktop before-hand. 2024-04-10 17:57:37 Though after some tinkering with .xinitrc, I was able to launch plasma X11 once, yet Firefox still had that issue. Tab crashing. 2024-04-10 18:02:43 Here's my sddm.log file from /var/log/sddm.log: https://paste.rs/EG0Qh.txt 2024-04-10 18:44:23 zeroxvm: but it does work before installing it to disk? 2024-04-10 18:44:57 maybe you should create an issue on gitlab.a.o so its not forgotten. we are kinda busy with the 3.20 release now, and python 3.12 upgrade 2024-04-10 18:46:13 github is giving me 500 2024-04-10 18:46:32 and now I have a test error: E urllib.error.HTTPError: HTTP Error 500: Internal Server Error 2024-04-10 18:46:42 maybe the test is trying to fetch from github? 2024-04-10 18:48:42 yup. i think it was 2024-04-10 18:48:54 now it passed 2024-04-10 19:00:24 ncopa: I believe it does, I didn't check that right now, but before, it would work before installing to disk. So I am highly certain it is ``setup-disk``. Thanks for providing support anyways! ^^ 2024-04-10 19:07:25 Should I create the issue on the project alpine-conf? 2024-04-10 19:08:59 yes, that would be the appropriate place 2024-04-10 20:59:54 thinking of adding some stuff to codingstyle.md to basically codify more of the existing aports-wide style 2024-04-10 21:00:12 but while some stuff is very easy to put into writing, some stuff is just.. "it looks wrong" 2024-04-10 21:00:25 like putting the options= line before depends 2024-04-10 21:18:12 You could just enforce it via CI lint and not bother documenting it 2024-04-10 21:34:16 on void we have our linter enforce variable order, it's reasonable to write out the order in your style guide 2024-04-10 21:35:37 The problem is that the variability is high atm 2024-04-11 05:55:05 I am guessing its intentional to keep pkgver of linux-headers at 6.6 and linux-lts at 6.6.26 2024-04-11 06:01:04 pkgs libkcapi, liblognorm, libotr, libpcap - url= needs updating 2024-04-11 06:33:01 vkrishn: it's rare that linux-header patches are used, and they are meant to be mostly forward compatible, so it makes no sense 2024-04-11 06:48:31 ok, noticed some new .h files, not in linux-headers.apk or linux-lts-dev, https://tpaste.us/NBQZ 2024-04-11 07:43:10 ok, im stuck at py3-thinc. it appears to require cython<3 2024-04-11 07:43:24 and cython<3 does not work on python 3.12 2024-04-11 07:44:57 maybe build 3.20 twice, once with old deps, once with new deps, remove old deps 2024-04-11 08:03:07 and re-enabling checks where possible 2024-04-11 09:42:40 hi, I see there were 3 pathes for CVE-2024-25629 (main/c-ares) but I dont see one for 3.19, it doesnt affect 3.19? just wondering 2024-04-11 09:43:15 patches* 2024-04-11 09:49:09 ah ok I see, it were upgraded in another moment https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62873 2024-04-11 09:56:31 i wonder when I should merge the python 3.12 branch 2024-04-11 09:57:01 i have 86 packages to build and then I'm ready with community repository 2024-04-11 09:57:07 i wonder if I can merge at that point 2024-04-11 09:57:16 all testsing packages will be broken if I do 2024-04-11 09:57:29 but then it should be easier for people to help clean it up 2024-04-11 09:58:04 and we will have a window when main repo is built and uploaded and before community is done, where repos will be "broken" 2024-04-11 09:58:55 it is also high risk that something broke last two weeks, if dependency got updated or similar, or that untested arch breaks 2024-04-11 09:59:16 but the sooner I push, the sooner other will be able to help with fixing 2024-04-11 10:01:13 maybe I should try push tomorrow, so the breakage happens over a weekend 2024-04-11 10:02:46 or should I try finish the testing repo as well? 2024-04-11 10:03:47 IMHO, there's no guarantee testing works at all. That is why it is called testing. I would be in favor of pushing this weekend. 2024-04-11 10:04:34 ncopa: i've been fixing breakages in testing, there should be at most 30 broken packages in testing/ by my estimates 2024-04-11 10:05:56 and the goal now is to get 3.20 release out, which will not include testing repo 2024-04-11 10:06:33 so I can try rebuild testing repo locally while builders chew on main and community repos 2024-04-11 10:08:18 ptrc: thank you for helping fixing python breakages! 2024-04-11 10:08:28 did you bupm into community/rbtools? 2024-04-11 10:08:55 just tried a rebuild of community, yup 2024-04-11 10:09:20 i still have ~20 packages in community/ that don't build 2024-04-11 10:09:54 incl. stuff like kodi, krita, or aws-cli 2024-04-11 10:16:44 ok 2024-04-11 10:17:13 https://dev.alpinelinux.org/~ptrc/py3.12-community.html 2024-04-11 10:17:18 kodi, krita is also on my deal-with-later-list 2024-04-11 10:17:20 posted all logs as well 2024-04-11 10:17:48 i deleted some of those packages 2024-04-11 10:17:55 some of them are very annoying, like scribus and PyUnicode_AS_UNICODE in C code 2024-04-11 10:18:13 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63922 2024-04-11 10:19:05 i only skip 3 right now: kicad, krita and kodi 2024-04-11 10:19:14 saw there was a new version of kodi upstream 2024-04-11 10:21:44 im on redshift now. last upstream commit was 4 years ago 2024-04-11 10:23:53 oh, its py-compile thats outdated 2024-04-11 10:25:42 autoreconf -vif fixes that 2024-04-11 10:36:07 help! checksum error in scapy! 2024-04-11 10:36:42 oh, that must be new 2024-04-11 10:37:37 checking 2024-04-11 10:38:59 ...they have autogenerated stuff in the tarball 2024-04-11 10:39:14 https://ptrc.gay/OoefCqpE 2024-04-11 10:39:21 https://tpaste.us/xyEr 2024-04-11 10:39:29 lol 2024-04-11 10:39:31 nice timing 2024-04-11 10:40:00 git automatically deciding hashes need more digits to remain unambiguous 2024-04-11 10:40:42 yeah, but this is entirely the developers' fault 2024-04-11 10:40:48 they're using the same stuff octoprint did 2024-04-11 10:40:53 ( https://github.com/OctoPrint/OctoPrint/issues/4908 ) 2024-04-11 10:41:12 yeah, seeing that one more often 2024-04-11 10:45:25 i am in a `git rm -r` mode now. lets delete it til they fix it upstream 2024-04-11 10:56:49 i.. we can just rebuild it with the new source 2024-04-11 10:57:29 and that should last for, well, until they get another $large_number of commits so that git has to make the sha less ambiguous 2024-04-11 10:57:57 and hopefully until then we can just get the developers to get rid of git embedded metadata 2024-04-11 11:00:08 You can even explicitly set the amount of characters it should use 2024-04-11 11:00:49 should I avoid merging py3- upgrades? 2024-04-11 11:02:40 really doubt they would break anything 2024-04-11 11:02:47 as in, should be fine 2024-04-11 11:06:29 ok, thanks 2024-04-11 11:08:41 ptrc: seems like %(describe) should be used rather than %d 2024-04-11 11:31:55 ok, now its sopel (ikke is maintainer). 2024-04-11 11:32:02 ModuleNotFoundError: No module named 'asynchat' 2024-04-11 11:32:07 right 2024-04-11 11:32:14 Do we want to separately package that? 2024-04-11 11:32:22 i dont know 2024-04-11 11:32:22 There is a polyfill 2024-04-11 11:32:30 no idea 2024-04-11 11:33:13 https://pypi.org/project/pyasynchat/ 2024-04-11 11:33:16 woudl be nice if the problem woudl have "fixed itself" next time I rebase git master 2024-04-11 11:33:19 I'll package that to make it work with 3.21 2024-04-11 11:33:21 :) 2024-04-11 11:33:30 thanks! 2024-04-11 11:33:50 i think sopel APKBUILD coudl also have use for a modernization 2024-04-11 11:40:50 !63864 seems to add python 3.12 support 2024-04-11 11:56:26 What package provides this import? "from test import support" 2024-04-11 11:57:02 " 2024-04-11 11:57:04 The test package is meant for internal use by Python only. " 2024-04-11 11:57:19 I guess I'll disable the tests 2024-04-11 12:19:50 What was the fix again when tests fail because it finds 2 definitions of the same test? 2024-04-11 12:20:13 import file mismatch 2024-04-11 12:26:57 ikke: i think that would be something like in !63699 2024-04-11 12:28:51 ptrc: thanks, that worked 2024-04-11 12:40:51 !63930 2024-04-11 12:47:14 i know have 17 packages left... 2024-04-11 12:47:46 ncopa: does that include sopel? 2024-04-11 12:47:54 exclude 2024-04-11 12:48:18 and excluding krita kicad and kodi 2024-04-11 12:48:51 also excluding streamlink https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63928 2024-04-11 12:49:33 there is a separate package for asyncore as well 2024-04-11 12:49:43 sounds fun :) 2024-04-11 12:50:06 thank you for helping me though. i really appreciate it 2024-04-11 12:56:54 ncopa: updated 2024-04-11 13:05:09 ikke: thanks. now it fails on import imp 2024-04-11 13:05:15 :/ 2024-04-11 13:05:23 I guess that's now importlib 2024-04-11 13:10:21 yup 2024-04-11 13:10:27 https://github.com/sopel-irc/sopel/commit/596adc44330939519784389cbb927435305ef758 2024-04-11 13:12:23 does not seem to apply clean :-/ 2024-04-11 13:12:50 THere's https://github.com/sopel-irc/sopel/pull/2474 that tried to backport it, trying it now 2024-04-11 13:12:53 maybe we just delete sopel til python 3.12 is pushed? 2024-04-11 13:13:23 Fine with me, we're not actively using it anyway 2024-04-11 13:17:28 ikke: thank you for your help 2024-04-11 13:17:33 np 2024-04-11 13:20:25 we have mirror on github so they will get notified that we deleted it 2024-04-11 13:27:05 could we perhaps just update sopel to git? 2024-04-11 13:27:12 there hasn't been a release in 2 years 2024-04-11 13:27:21 sounds like something to delete 2024-04-11 13:27:34 we can add it back when new release comes out 2024-04-11 13:28:01 i'd prefer `arch=""` instead of removing stuff, if we can add it back 2024-04-11 13:28:19 ptrc: there is an MR for the 8.0 changelog one month ago 2024-04-11 13:28:26 oh, hm 2024-04-11 13:28:49 even more so 2024-04-11 13:28:58 im in a delete-evertying-in-the-way-for-python-3.12 mode 2024-04-11 13:29:04 git revert it easy 2024-04-11 13:29:13 but then the blame and git history gets messy :p 2024-04-11 13:29:39 thats the price for getting in the way :) 2024-04-11 13:30:12 alright 2024-04-11 13:30:24 i assume you have all the deletions on the branch in your git fork? 2024-04-11 13:30:47 lets make a deal, we do arch="" now, and before we branch 3.20 we delete everything with arch="" 2024-04-11 13:31:03 i have some, not all 2024-04-11 13:31:25 guess what 2024-04-11 13:31:32 my rebuild script completed 2024-04-11 13:32:12 only the skipped ones are left 2024-04-11 13:32:20 7 2024-04-11 13:32:26 did you skip py3-simpleparse, or remove it? 2024-04-11 13:32:37 oh 2024-04-11 13:32:41 i just grepped aports 2024-04-11 13:32:41 i dont remember. i think i may have fixed it 2024-04-11 13:32:54 removed yesterday 2024-04-11 13:32:58 no simpleparse was deleted 2024-04-11 13:32:58 yes 2024-04-11 13:33:01 nothing used it 2024-04-11 13:41:21 maybe I should just merge now and hope that the remaining 7 package fixes themselves eventually? 2024-04-11 13:43:38 tbf it's stuff like kodi, krita or kicad 2024-04-11 13:43:46 would be nice to not have them broken 2024-04-11 13:46:08 indeed 2024-04-11 13:46:16 kodi has a new version 2024-04-11 13:46:30 but also, in testing there's exactly 100 packages that don't build now 2024-04-11 13:47:39 actually less than that 2024-04-11 13:47:46 let them burn 2024-04-11 13:48:24 can we build krita without python? 2024-04-11 13:48:52 ptrc: i dont think i can tell you enough how thankful I am that you helped us get this far with python 3.12 2024-04-11 13:49:03 i suppose we can. thats a good idea 2024-04-11 13:49:12 i'm just glad i can help ^^ 2024-04-11 13:49:17 im looking at kicad now 2024-04-11 13:49:45 there is only 42000+ commits in kicad. one of them must haf the correct fix... 2024-04-11 13:50:03 i'd look at anything that touches CMakeLists.txt 2024-04-11 13:50:10 unless we're getting different errors 2024-04-11 13:52:02 qa_pcbnew test fails on git master currently 2024-04-11 13:52:26 i think we are looking at same error and I am looking at CMakeList.txt git log 2024-04-11 13:52:39 CMake Error at CMakeLists.txt:949 (message): 2024-04-11 13:52:39 wxWidgets 3.2.0 or greater is required 2024-04-11 13:52:49 which does not happen with python 3.11 2024-04-11 13:52:53 which is sort of weird 2024-04-11 13:53:29 actually, im lookt at wrong file: cmake/FindwxPython.cmake:87 2024-04-11 13:55:35 there is another way instead delete, make branch at pre py.3.12, rename it to main, but haven't tried something like this 2024-04-11 13:56:23 then build, merge from old line as needed, when done delete old line (ahem cough), should work 2024-04-11 13:57:23 oh, it is a real issue with kicad 2024-04-11 13:57:42 $ python -c "import wx;print(wx.wxWidgets_version.split(' ')[1])" 2024-04-11 13:57:42 3.2.4 2024-04-11 13:57:42 Segmentation fault 2024-04-11 13:57:43 rename it to master ^ 2024-04-11 13:57:59 https://gitlab.com/kicad/code/kicad/-/blob/master/cmake/FindwxPython.cmake?ref_type=heads#L78 2024-04-11 13:58:15 disabled krita python stuff btw 2024-04-11 13:59:19 thank you! 2024-04-11 13:59:42 let me do the same with kicad 2024-04-11 14:00:41 Not sure if i should mention this, as the Python 3.12 stuff is more important, but i've built on what omni did and attempted to get mbedtls 2 out of main/, so we don't have to support it for 2 years 2024-04-11 14:01:11 celie: that is good news! 2024-04-11 14:01:25 I think omni mentioned that upstream will pull support for mbedtls 2 at the end of this year 2024-04-11 14:01:30 good job! 2024-04-11 14:01:36 yeah, i heard/saw somewhere 2024-04-11 14:01:40 !63885 2024-04-11 14:01:52 I still need to add a community/mbedtls2 aport though 2024-04-11 14:01:54 so its good to get most hings over to medtls 3. 2024-04-11 14:02:20 as there are 4 aports in community/ that need to be migrated to mbedtls 3 at the same time 2024-04-11 14:02:42 celie: thank you for taking care of that 2024-04-11 14:02:54 Sure, you're welcome 2024-04-11 14:04:30 I probably cried wolf to omni (privately) too many times while working on that, but i think it is in good order now, and i've considered most of the obvious stuff 2024-04-11 14:05:35 Probably one of the major steps left would be to have fcolista review the Linphone suite changes 2024-04-11 14:16:05 my efforts were at best half-assed 2024-04-11 14:24:23 Looking through the old MRs, i see you've tried the mbedtls 3 upgrade before, about 3 years ago, but back then there was probably no mbedtls 3 LTS, and the mbedtls 2 end-of-life date was still far away back then 2024-04-11 14:27:16 yes, I think I just wanted to try, or had not yet seen that it wasn't LTS, that I had just seen it flagged 2024-04-11 14:27:58 I like https://pkgs.alpinelinux.org/flagged but it is often wrong 2024-04-11 14:28:40 ugh... we build 3 flavors of kodi 2024-04-11 14:29:00 vfs and pvr? 2024-04-11 14:29:19 build-x11, build-wayland, build-gbm 2024-04-11 14:29:22 ah ok 2024-04-11 14:29:30 maybe I should just delete it... 2024-04-11 14:29:46 Delete kodi? 2024-04-11 14:31:07 yeah.. 2024-04-11 14:31:13 its in the way 2024-04-11 14:31:26 and im in a delete-everything-I-can mode :) 2024-04-11 14:31:57 hehe 2024-04-11 14:32:12 can I delete rust in gitlab? it's in the way 2024-04-11 14:32:24 oh! please do! 2024-04-11 14:32:31 and everyting that depends on it 2024-04-11 14:33:32 Been fighting this for a couple of weeks now (gitlab fails to build) 2024-04-11 14:33:53 Because they decided it was necessary to rewrite some extensions in rust 2024-04-11 14:33:58 I wonder if the Gitlab rust directory issue can be reproduced with upstream's rustc 2024-04-11 14:35:50 I can probably unpack upstream's rustc in an APKBUILD to produce a .apk if you're interested in trying it out 2024-04-11 14:36:47 At this point I'm willing to do anything 2024-04-11 14:36:59 Was working on a minimal reproducer 2024-04-11 14:38:49 I guess you're probably using our main/rust to build the Gitlab stuff now, right? 2024-04-11 14:38:59 correct 2024-04-11 14:39:09 and llvm 2024-04-11 14:39:12 Do you use any other subpackage of main/rust besides cargo? 2024-04-11 14:39:19 just cargo 2024-04-11 14:39:27 Upstream rustc uses their own vendored LLVM 2024-04-11 14:39:31 ok 2024-04-11 14:39:37 and clang as well I suppose? 2024-04-11 14:50:26 I think it still uses gcc 2024-04-11 15:06:32 celie, gr8 job with linphone suite 2024-04-11 15:21:20 maribu: 'I can't find the format file `pdflatex.fmt'!' 2024-04-11 15:21:22 for texlive 2024-04-11 15:27:19 oooh 2024-04-11 15:29:12 It will be generated by the trigger. It fails in the texlive check function currently because in the check install the trigger fails. 2024-04-11 15:29:33 It should be fixed by !63938 2024-04-11 15:32:51 fcolista: Thanks 2024-04-11 16:22:22 so then its only kodi left for python 3.12 merge? 2024-04-11 16:25:00 gitlab.alpinelinux gives me 500s on the 'open MR' page 2024-04-11 16:25:39 Piraty: I suppose you follow the link provided when you use git push while trying to make an MR for a stable branch? 2024-04-11 16:25:52 probably 2024-04-11 16:26:00 You need to change the target branch 2024-04-11 16:26:15 i read that as to use the manual process, will do 2024-04-11 16:26:50 You can adjust the url, but forgot the name of the parameter 2024-04-11 16:26:54 i guess default merge branch is master which won't work . 500 is silly though 2024-04-11 16:27:06 i'll figure it out from the web page 2024-04-11 16:27:08 yes 2024-04-11 16:27:14 it's 500 because gitally times out 2024-04-11 16:27:29 It's not the best though 2024-04-11 16:52:48 ikke: thank you for helping out 2024-04-11 16:52:55 np 2024-04-11 16:53:51 ncopa: what does the kodi build issues look like? 2024-04-11 16:53:54 aerdan here? 2024-04-11 16:54:31 i wouldn't work on the nheko apkbuild any further though 2024-04-11 16:55:08 Don't think so 2024-04-11 16:57:48 maribu: that fixed it :) 2024-04-11 17:27:02 Hurray :-) 2024-04-11 18:20:26 in ~10 minutes I will upgrade gitlab 2024-04-11 18:26:30 will the ML ever be revived? 2024-04-11 18:26:50 which one? 2024-04-11 18:27:01 or is this gitlab-first from now on? 2024-04-11 18:28:04 ah i read posts to ML on sourcehut are created as gitlab MR but there is no sync to ML afterwards, so discussion must be on gitlab 2024-04-11 18:28:43 Someone needs to fix or build an alternative integration 2024-04-11 18:31:05 restarting gitlab 2024-04-11 18:31:37 yeah, I've been working through the wiki docs, trying to figure out what "the true path is" - and AFICT, ML is dead, and /me needs to explain how to "how to use gitlab for mortals" 2024-04-11 18:33:34 I have a bunch of notes in my "Pragmatic Guide to Git" book. But bottom line, Piraty, my bad. 2024-04-11 18:34:12 :) 2024-04-11 18:35:50 gitlab has been upgraded :) 2024-04-11 18:36:04 \o/ 2024-04-11 18:41:35 i've experienced painful upgrades of local gitlab instances before. therefore: congrats 2024-04-11 18:43:31 Funilly, the upgrades themselves are smooth. We had issues building gitlab due to ruby gems with rust extensions 2024-04-11 18:48:51 Hmm. Could it be that it just takes a bit of time until all the texmf-dist subpkgs are available, or is the approach to extend the $subpackages within package() I used not valid? 2024-04-11 18:49:24 subpackages should be available at the same time as the main package 2024-04-11 18:51:07 A pity :-/ I'll update this then. 2024-04-11 18:51:21 maribu: you cannot extend subpackages in the package function 2024-04-11 18:51:47 You _can_ extend them, it needs to be done in the global scope 2024-04-11 18:52:41 though, you should also not exec in the global scope 2024-04-11 18:52:51 so things like find and awk 2024-04-11 18:53:46 The intent was to extend them to match the collections in the texlive package manager database, which is a source file that is not available at global scope. I guess I have to maintain the list of subpackages by hand. I could add a check() hook to see if the subpackages are still in sync with the collections, though. 2024-04-11 19:29:31 !63949 changes the behavior to not extend $subpackages at runtime, but only check() if the subpackages are in sync with their corresponding collections they pack. 2024-04-11 21:34:27 got the total amount of py3.11 packages down to 59 2024-04-11 21:35:10 of which over half is because they're blocked on some other dep 2024-04-12 07:18:33 can somebody merge !63707 ? 2024-04-12 07:30:55 thanks! 2024-04-12 07:36:57 morning! I have only kodi upgrade left before I can push python 3.12 2024-04-12 07:37:42 will still need to rebase, and maybe squash the commits, so I push 3-4 commits instead of 1700 2024-04-12 07:39:36 oh ptrc handled kodi for me! thanks! 2024-04-12 07:44:05 ncopa: i think !63885 is also looking good, i managed to bring the mbedtls 2 aports back down to 7, with the majority of them (5) in testing/ 2024-04-12 07:47:37 It seems the mbedtls LTS support cycle is 3 years long, so 2.28 is expected to go out of support in December this year, which would give us some time to decide what to do with the mbedtls 2 aports 2024-04-12 07:51:37 good! 2024-04-12 07:51:49 so we ust wait for the CI to be green 2024-04-12 08:27:59 i am more or less ready to push python 3.12, but I dont know if I should wait til chromium build is done 2024-04-12 08:28:09 will probably take rest of the day 2024-04-12 08:33:51 Maybe having the other 6 builders working on Python 3.12 could still be good 2024-04-12 08:34:09 yeha 2024-04-12 08:37:40 The riscv64 builder has finally finished building webkit2gtk after 8 hours, hopefully that also means the CI jobs on pioneer2 will get a speed boost now 2024-04-12 08:37:58 yup 2024-04-12 08:38:13 the other pioneer2 machine is down currently (i think) 2024-04-12 09:20:02 alright, im gonna push 3.12 now I think 2024-04-12 09:23:36 \o/ 2024-04-12 09:36:53 ncopa: i think CI for mbedtls 3.6.0 is also going to finish soon (probably 2 or 3 aports left), so assuming CI for that is green, should it go in at the same time as Py 3.12 or wait for later? 2024-04-12 09:37:17 can you please hold any git pushes for the next 30 mins? 2024-04-12 09:37:38 python 3.12 merge? 👀 2024-04-12 09:37:50 yes 2024-04-12 09:37:57 i am squashing the commits 2024-04-12 09:38:20 and i dont want to deal with 1000 changes merge conflict 2024-04-12 09:41:49 Oops, 1 aport failed in the mbedtls MR 2024-04-12 09:43:36 However, it's the librist test, which i think is very load sensitive (and it was competing with webkit2gtk) 2024-04-12 09:45:49 So, not sure if i want to rerun the riscv64 CI, as this last run took 4.5 hours (and now additionally it will be competing with Py 3.12) 2024-04-12 09:57:48 CONFLICT (content): Merge conflict in community/py3-joblib/APKBUILD 2024-04-12 09:57:48 error: could not apply b130137bdcc... community/*: rebuild against python 3.12 2024-04-12 09:57:50 argh 2024-04-12 09:58:17 Yeah, that was just upgraded 2024-04-12 09:58:42 happnd while i was merging the commits into fewer 2024-04-12 09:58:50 i should have just pushed the 1700+ commits 2024-04-12 10:01:37 main and community pushed. should be ok to push now 2024-04-12 10:01:50 there may be one or two packages that I missed in the rebases 2024-04-12 10:04:05 Are you working on Py 3.12 in testing now or will that be later? 2024-04-12 10:07:47 Anyway when you're free to look at the mbedtls MR again, do tell me whether to rerun the riscv64 or not (i expect that the librist test will fail again, considering the builder will now be busy with Py 3.12) 2024-04-12 10:07:58 But maybe that can wait for later 2024-04-12 10:08:08 We already have the first anomaly 2024-04-12 10:08:23 libxml2 was built before python3 on armhf and armv7 2024-04-12 10:08:31 but for the other archs is is being built after 2024-04-12 10:08:57 ugh 2024-04-12 10:09:20 Now, riscv64 failed onefetch, so a "retry master" now will get Py 3.12 on it 2024-04-12 10:09:33 I started to work on testing 2024-04-12 10:09:48 but we should prio getting the builders move forward 2024-04-12 10:10:15 That was moved to the python3-tests subpackage, right? 2024-04-12 10:10:15 libxml2 is failing due to not finding unittest 2024-04-12 10:12:11 I would consider opening an MR for adding python3-tests to libxml2, but i don't think i can trust CI now, as it'll still have Py 3.11 2024-04-12 10:13:16 oh no. thats gonna break alot 2024-04-12 10:13:39 Maybe you should consider not moving unittest to -tests? 2024-04-12 10:14:01 but why did it pass here locally? 2024-04-12 10:14:41 Maybe you're using a Py 3.12 that was built before you added that amove? 2024-04-12 10:14:49 (Just a wild guess) 2024-04-12 10:14:58 yeah, that is likely what happened 2024-04-12 10:15:03 what a nightmare 2024-04-12 10:15:42 I think i brought that up when i first looked at the changes to main/python3, and probably should've pursued it further 2024-04-12 10:16:56 im rebuilding python 3.12 again locally 2024-04-12 10:20:27 im on it 2024-04-12 10:23:20 we may need to revert that, i think unittest is assumed to be with the runtime 2024-04-12 10:25:33 and its only 1.2MB 2024-04-12 10:25:43 compared to tests, which is 132MB 2024-04-12 10:25:47 Yes, that was what i had in mind when i brought that up 2024-04-12 10:26:04 A lot of aports just use unittest assuming it will be there, unlike py3-pytest which is added explicitly 2024-04-12 10:28:41 and the 3 aports that failed as a result of that, libxml2 and dtc (use unittest from Makefile), and gtest (from ctest) so it will not be easy to find all the aports that need python3-tests (if unittest were split into that) 2024-04-12 10:30:00 yeah 2024-04-12 10:30:08 i have already updated python3 package 2024-04-12 10:30:25 we can revisit this later, after alpine 3.20 if needed 2024-04-12 10:30:28 but 2024-04-12 10:30:37 libxml2 is built before python? 2024-04-12 10:30:41 not good 2024-04-12 10:30:56 Only on armhf and armv7 (from what i managed to see) 2024-04-12 10:31:02 which is why it didn't fail there 2024-04-12 10:31:20 it happens on x86_&4 now 2024-04-12 10:31:27 it means we have a circular dep somewhere 2024-04-12 10:31:35 python probably depends on libxml 2024-04-12 10:31:39 python probably depends on libxml2 2024-04-12 10:32:01 yes it does 2024-04-12 10:33:16 ugh, if -z BOOTSTRAP 2024-04-12 10:33:28 this is gonna be fun 2024-04-12 10:33:45 Does python3 depend on libxml2? 2024-04-12 10:33:49 yes 2024-04-12 10:34:08 indirectly 2024-04-12 10:34:08 I can't find libxml when i look through the python3 buildlog 2024-04-12 10:34:31 $ ap recursdeps python3 | tpaste 2024-04-12 10:34:31 https://tpaste.us/KEYP 2024-04-12 10:34:45 maybe gettext or libunistring 2024-04-12 10:34:55 gettext 2024-04-12 10:36:18 but the python3 APKBUILD has !gettext-dev in makedepends 2024-04-12 10:41:36 that doesnt matter 2024-04-12 10:42:35 oh 2024-04-12 10:42:37 maybe it does 2024-04-12 10:44:12 maybe build order resolver pulls it in to the dependency graph? 2024-04-12 10:44:45 or any of the other dependencies to python3 needs gettext 2024-04-12 10:45:16 xz? 2024-04-12 10:45:32 indeed 2024-04-12 10:45:34 xz it is 2024-04-12 10:46:33 introduced by this 982d2c6bcbbb579e85bb27c40be84072ca0b1fd9 2024-04-12 10:47:05 Oh my 2024-04-12 10:47:58 Can it use gettext-tiny? 2024-04-12 10:48:58 most of the subpackages for texmf-dist are missing for x86_64 arch not other enabled arches. any way to access build logs to see if something happened? 2024-04-12 10:49:53 No, apparently not, po4a requires gettext 2024-04-12 10:51:55 it is autoreconf that needs some m4 macro provided by gettext 2024-04-12 10:52:26 we could maybe ship that macro in separate package 2024-04-12 10:52:27 and gettext has xz in depends_dev, but not sure if that affects dependency resolution 2024-04-12 10:52:41 as depends_dev is not included in makedepends 2024-04-12 10:53:17 i think we need the pregenerated configure script of xz 2024-04-12 10:53:36 it is designed for this problem 2024-04-12 10:54:03 ship everythign in generated scripts so you dont have any external dependencies 2024-04-12 10:55:50 So, you'll have to pregenerate it and upload the tarball to dev.alpinelinux.org? (unless upstream has sorted out the situation, and we want to trust their tarball again) 2024-04-12 10:58:14 gettext-tiny has some m4 stuff in usr/share, is the macro included there? 2024-04-12 11:00:19 Now i see the circular dependency, xz has gettext-dev in makedepends, while gettext has xz in depends_dev 2024-04-12 11:03:13 and we also have po4a dep 2024-04-12 11:03:45 i think we should revert xz to 5.4.x and use pregenerated tarballs again 2024-04-12 11:04:27 No wait, the circular dependency is gettext->libxml2-dev->xz-dev->gettext-dev 2024-04-12 11:05:39 and po4a just adds a second circular dep between xz and gettext 2024-04-12 11:05:44 Wow 2024-04-12 11:08:30 Never expected the xz issue to affect python3 2024-04-12 11:14:29 Do you think autopoint can just be patched to use `busybox xzcat` instead of `xz -d -c`? 2024-04-12 11:18:21 I'm trying to build xz without po4a, and with gettext-tiny replacing gettext 2024-04-12 11:19:35 I think it actually works 2024-04-12 11:19:58 fwiw we're using the pregenerated one in 5.4.2 and i have no qualms about tha 2024-04-12 11:19:59 t 2024-04-12 11:20:14 if you want, you can autoreconf -fi or whatever and diff it 2024-04-12 11:21:28 !63978 2024-04-12 11:23:20 Oh, all the localization files are gone 2024-04-12 11:24:27 That's probably due to not having po4a 2024-04-12 11:24:53 thats fine 2024-04-12 11:24:58 thank you! 2024-04-12 11:25:07 You're welcome 2024-04-12 11:26:26 Hmm, i tried it with gettext-dev, and the localization files are there, so not sure what po4a was for 2024-04-12 11:26:56 but i guess it is an alright compromise for now to solve the circular dep 2024-04-12 11:28:31 oh yeah, absolutely 2024-04-12 11:28:34 this is great 2024-04-12 11:30:40 a package's upstream version is v2.0.0-10, but abuild say it is not valid 2024-04-12 11:31:31 I just saw an example of that this morning, let me try to remember 2024-04-12 11:31:45 community/inxi 2024-04-12 11:32:21 Set _pkgver=2.2.0-10 and then use pkgver=${_pkgver/-/.} 2024-04-12 11:32:38 thx :) 2024-04-12 11:42:17 I just check the package contents of xz for v3.19, and no localization files there too, also using gettext-dev causes xz to be linked to libintl.so.8, so good that we've done away with that 2024-04-12 12:30:01 whats up with util-linux? 2024-04-12 12:30:33 seems like a test fails on 32 bit 2024-04-12 12:32:01 and tests are disabled on ppc64le and x86 2024-04-12 12:32:25 the test lsfd/mkfds-rw-character-device is also failing on aarch64 2024-04-12 12:32:52 but not in my local lxc x86_64 2024-04-12 12:33:35 we need find out if it is a bug in test or in code 2024-04-12 12:35:42 I'm looking at !63120, it is failing on x86 and ppc64le 2024-04-12 12:45:55 Oh, it's util-linux 2024-04-12 12:46:22 I think that has some basename issues 2024-04-12 12:46:45 Probably fixed in 2.40 2024-04-12 12:59:16 ncopa: I enabled all tests but two on ppc64le and they seem to pass on all architectures, except riscv64 that hasn't run yet 2024-04-12 13:05:03 good 2024-04-12 13:05:36 anybody has time and energy to investigate why nginx tests fails with openssl 3.3? 2024-04-12 13:05:49 wait, one last fix... 2024-04-12 13:06:31 Didn't mps mentioned in !63210 that mount segfauls on aarch64? 2024-04-12 13:06:38 Sorry, !63120 2024-04-12 13:06:59 which is why it hasn't been merged yet 2024-04-12 13:08:09 I read that as the current version was segfaulting 2024-04-12 13:14:31 qaqland: So, the _pkgver thing was in one of my aports. Thanks :) 2024-04-12 13:27:16 cely: get one trick today <3 2024-04-12 14:45:27 !63993 2024-04-12 14:48:50 !63988 2024-04-12 15:06:55 also probably time for !63757 as Python 3.12 has been merged, which means the Rust extensions are now broken 2024-04-12 15:18:51 how to access build logs to see if something happened to cause a package and/or subpackage to not be available at mirrors? 2024-04-12 15:19:10 build logs? 2024-04-12 15:19:46 Maybe https://build.alpinelinux.org/buildlogs/ 2024-04-12 15:21:25 I think there are only 2 blockers left for main/ of 32-bit ARM, and they should be solved by the main/libxml2 and main/gobject-introspection MRs i mentioned above 2024-04-12 15:23:43 cely: thanks 2024-04-12 15:24:01 You're welcome 2024-04-12 15:28:13 Ok, 32-bit ARM is going to get Python 3.12 now, prepare for Python aports in community/ and testing/ to be broken 2024-04-12 15:28:13 that helps. packages I'm looking for yet to build. not an issue then. thanks again. 2024-04-12 16:33:43 ncopa: CI has finally passed for !63885, though i'm not sure if you want to wait for all the Python 3.12 stuff to go through first (the MR touches testing/py3-mbedtls, but you haven't pushed a pkgrel bump for that yet) 2024-04-12 19:11:53 cely: i merged it so you dont need to rebase 2024-04-12 19:12:10 ok py3-build is failing. i wonder what I did to make it pass last time 2024-04-12 19:13:36 iirc i didn't have to do anything and it was passing 2024-04-12 19:13:40 might be some deps 2024-04-12 19:15:41 could be, or maybe i did a temp options="!check" abuild and forgot about it 2024-04-12 19:16:22 i dont think i did many of those, and hopefully i went back and fixed them all 2024-04-12 19:16:34 i maaybe did 3 or 4 2024-04-12 19:16:39 definitely one for the ovos stuff 2024-04-12 19:16:51 but that's testing 2024-04-12 19:16:56 + i think i opened an issue 2024-04-12 19:17:04 RuntimeError: uv executable not found 2024-04-12 19:19:35 I dont seem to have anything here either: https://gitlab.alpinelinux.org/ncopa/aports/-/blob/python-3.12/community/py3-build/APKBUILD 2024-04-12 19:19:52 I also upgraded py3-build, after that it was failing more tests until I disabled them 2024-04-12 19:19:58 in case i messed up some rebase 2024-04-12 19:20:22 as in deselected the failing tests, for now 2024-04-12 19:21:05 https://src.fedoraproject.org/rpms/python-build/blob/rawhide/f/python-build.spec#_50 2024-04-12 19:21:22 https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/py3-build/py3-build-1.1.1-r0.log 2024-04-12 19:21:26 fedora also disables a number of tests. That is probably what I did, but lost it during rebase 2024-04-12 19:21:42 oh 2024-04-12 19:21:53 we should have done what gentoo did btw 2024-04-12 19:21:57 !64020 2024-04-12 19:22:09 https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/build/build-1.1.1.ebuild#n59 2024-04-12 19:22:15 they have a 'not network' 2024-04-12 19:23:40 looks like they deselect the tests that were failing for us too, with 1.1.1 2024-04-12 22:09:05 I'm about to package some drivers for my new hardware which requires the use of akms as far as I understand. Are there any rules to what to call the package since I see some have the suffix -src, however in this case my guess is there would be better to simply name the package tucedo-drivers 2024-04-12 22:09:21 tuxedo-drivers* 2024-04-12 22:09:39 Any thoughts? 2024-04-13 05:48:03 !64040 and !64041 2024-04-13 06:46:28 whoops i already pushed arandr fix 2024-04-13 06:47:56 the py3-pytest-tmp-files worries me a bit. I don't see why those tests would fail. I think something is broken 2024-04-13 06:48:16 gajim also needs follow up. b4bda0e5a47541c5eeec2f534a514c0ba7ffd979 2024-04-13 06:48:46 the comment there says that the disabled tests should not fail. ever. on anything 2024-04-13 06:49:05 # This probably won't fail on *any* locale, ever, again because the 2024-04-13 06:49:11 should be reported upstram at least 2024-04-13 06:58:15 pytest-tmp-files is only used by borg-space, which had other issue earlier. not sure if they are related. https://github.com/KenKundert/borg-space/issues/13 2024-04-13 06:58:39 now I need to make breakfast. Have a nice weekend everybody! 2024-04-13 08:18:25 !64042 and !64044 2024-04-13 08:28:30 I wonder if the riscv64 builder is stuck on py3-pexpect, it seems it's been working on that for more than an hour 2024-04-13 08:49:40 Seems so, and failed before that anyway. 2024-04-13 08:54:58 x86* is probably also stuck on py3-fakeredis 2024-04-13 09:12:16 ncopa: pytest-tmp-files looks need upgrade pyfakefs 2024-04-13 11:02:20 and fyi edge util-linux doesn't currently build correctly. also any edge install (tried one fresh as well) will not boot if util-linux is installed and fsck isn't explicitly disabled on filesystems in fstab. 2024-04-13 11:11:07 We may have been too quick with the util-linux upgrade 2024-04-13 11:11:25 It just seems the old version and the new old are broken, probably in different ways 2024-04-13 11:11:34 s/new old/new version/ 2024-04-13 11:15:18 #15923 2024-04-13 11:15:29 So, it's a pick your poison sort of situation 2024-04-13 11:15:52 and that issue probably needs to be re-opened 2024-04-13 11:19:38 yeah I was going to track it down but I kind of want to wait until some of the build dust settles. 2024-04-13 11:21:56 I kind of wonder if splitting the util-linux might help as well. Since util-linux can be pulled in just via dev packages and have some pretty sweeping implications that one may not intend. 2024-04-13 12:48:00 I opened #15981 because my machine failed to boot. Should I close for supporting old one ? 2024-04-13 12:50:14 lindsay: In my opinion, no, the old one was for the previous version of util-linux 2024-04-13 12:51:53 omni: i guess this means you probably misread mps's statement, and the segfault is for the current version of util-linux (though very likely it's a different segfault) 2024-04-13 12:52:14 The old version was segfaulting on su/runuser 2024-04-13 12:52:34 Maybe the new one fixed that, but seems to have introduced segfaults in even more critical places 2024-04-13 12:53:40 lindsay: Does mount from util-linux segfault as well? 2024-04-13 12:59:40 no `mount -a` command work fine 2024-04-13 13:00:44 Ok, thanks 2024-04-13 13:01:36 (i think mps mentioned that the mount segfault was happening on aarch64) 2024-04-13 13:01:53 So, probably that means it's alright on x86_64 2024-04-13 13:13:49 pkgs.a.o ktistec is still old version, but pr merged 15 hours ago 2024-04-13 13:15:06 qaqland: Yes, ktistec is in testing, and only enabled for aarch64 and x86_64 2024-04-13 13:15:23 both those archs are now stuck on Py 3.12 in community 2024-04-13 13:15:41 So, will probably take a while to reach testing 2024-04-13 13:15:57 https://build.alpinelinux.org/ 2024-04-13 13:16:29 oh, builders are busy 2024-04-13 13:16:43 Yes, big Python 3.12 rebuild 2024-04-13 13:26:13 here's the thread https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63120#note_389452 2024-04-13 13:27:08 and I read that as both said that they had no segfaults with 2.40 2024-04-13 13:27:46 not sure if either installed 2.40 from build artifacts, though 2024-04-13 13:29:03 Yes, the su/runuser thing is very likely solved by 2.40 (it was due to basename, i think) 2024-04-13 13:29:15 but there are new segfaults now 2024-04-13 13:36:27 mhm 2024-04-13 13:36:44 Maybe we need to downgrade to 2.39 and backport https://github.com/util-linux/util-linux/pull/2615 (to keep #15923 closed) 2024-04-13 13:37:47 That is, if 2.39 is not also affected by #15981 2024-04-13 13:40:43 Hmm, but 2.40 is a security upgrade 2024-04-13 13:40:46 So that would complicate things 2024-04-13 13:41:50 fsck in 2.40 fails on abuild rootbld for me, and on a fresh vm. 2024-04-13 13:41:57 with a segfault 2024-04-13 13:42:28 Maybe https://github.com/util-linux/util-linux/commit/404b0781f52 is enough to address the security issue fixed by 2.40 2024-04-13 13:43:19 long list of changes https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.40/v2.40-ReleaseNotes 2024-04-13 13:43:38 Yes, but i guess the important thing is the CVE fix 2024-04-13 13:43:47 abuild fails in lsblk/lsblk tests. which coincidentally is where the backtrace of the boot fsck segfaults leads too... well libblkid so perhaps the same. 2024-04-13 13:44:49 So, maybe the basename-su and the CVE fix applied to 2.39.3 is good enough for us for the time being 2024-04-13 13:45:28 Until a new version of util-linux is released, hopefully with the new segfaults fixed 2024-04-13 13:46:04 sounds good to me 2024-04-13 13:48:02 maybe this? https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=7e357241b413a01c37b0b4d064bc0a47e3259361 2024-04-13 13:48:17 Probably pkgrel would have to be 3, so 2.39.3-r3, as r2 was used during the Python 3.12 rebuild 2024-04-13 13:49:59 ..but we have libeconf, don't we? 2024-04-13 13:52:21 Unless we have time to debug (or find out if upstream has already fixed this somewhere in pull requests or commits) in the midst of the Python 3.12 rebuild, and the Alpine 3.20 builders coming on maybe next week, 2024-04-13 13:52:42 i think our best bet is a 2.39.3-r3 with basename and CVE fix backported 2024-04-13 14:08:23 omni: From the strace log, I found blkid exit after trying to load blkid.conf: https://tpaste.us/pa4g 2024-04-13 14:08:24 and build with this commit locally, seems the problem be fixed 2024-04-13 14:12:01 great! 2024-04-13 14:22:20 !64061 2024-04-13 15:15:44 one down 2024-04-13 15:21:27 what's the other? 2024-04-13 15:21:37 fsck 2024-04-13 15:23:43 and perhaps it's just me but lsblk/lsblk still fails the check phase during rootbld 2024-04-13 15:24:07 bad test though methinks 2024-04-13 15:28:39 let me double check though in case somehow this made me a big fat phony 2024-04-13 15:30:53 ACTION <-- phony; disregard! 2024-04-13 15:31:20 So, fsck is also fixed? 2024-04-13 15:31:33 Yep as far as I can tell. 2024-04-13 15:31:55 That's good news 2024-04-13 15:32:04 \o/ 2024-04-13 16:07:25 any hint how patches here, https://dev.alpinelinux.org/archive/rpi-patches/ are generated ? 2024-04-13 16:55:34 if wanting to free some space, then https://dev.alpinelinux.org/archive git.bundles could be deleted 2024-04-13 19:12:14 Soo, python setuptools now have their own tar implementation 2024-04-13 19:14:06 Ermine: the python tarfile module? 2024-04-13 19:14:26 No 2024-04-13 19:16:22 They implemented the whole thing themselves. They imported few constants from tarfile though 2024-04-13 19:22:16 wow 2024-04-13 19:37:34 cloning from github is becoming fun 2024-04-13 19:46:59 is it? 2024-04-13 19:59:40 tried https://github.com/raspberrypi/linux twice and twice with --depth 1224070 2024-04-13 20:00:16 if someone can clone and tar it somewhere, would be helpful 2024-04-13 20:01:40 some private owned github gitbundle service used to exist yrs back 2024-04-13 20:03:50 cloning 2024-04-13 20:08:32 vkrishn, is there an issue? 2024-04-13 20:10:21 could not clone, errors' out at end index creation or in between, some curl error, don't know 2024-04-13 20:11:08 lost those msgs in terminal scroll back 2024-04-13 20:19:33 Do you have compression enabled in your curl config? 2024-04-13 20:26:00 no, did not have a need to do it, trying it 2024-04-13 20:27:26 cloning llvm worked 2024-04-13 20:32:42 vkrishn: https://dev.alpinelinux.org/~kevin/linux-rpi.bundle 2024-04-13 20:35:43 thanks 2024-04-13 21:39:57 vkrishn, actually there is (was?) an issue with curl compression option and I thought disabling it could unlock the problem 2024-04-13 21:48:37 quinq: thanks, that reminded me to read docs for newer options available , both in git (eg --server-options) and curl 2024-04-13 21:49:29 :) 2024-04-14 03:11:10 llvm14 keeps failing on riscv64 https://build.alpinelinux.org/buildlogs//build-edge-riscv64/main/llvm14/llvm14-14.0.6-r18.log 2024-04-14 06:36:58 Hello everyone. I've got a problem while trying to package/build some kernel drivers with akms. When akms start to build it ends up in some weird cyclic recursive loop so when it has compiled everything in one directory it creates a new directory with the same name inside the main directory and starts to compile the files in there. Then it does it again and again and again until 2024-04-14 06:37:01 i abort it manually. Ending up with i build tree very deep... Anyone seen this behaviour before or have any ideas on what I shall look for? 2024-04-14 06:37:53 EvTheFuture: Haven't experienced that. Is that with a specific module? 2024-04-14 06:39:44 I'm trying to package this: 2024-04-14 06:39:48 https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers#building 2024-04-14 06:40:36 ikke: it happens for each subdirectory inside the src tree. I'll upload a make.log 2024-04-14 06:50:22 This is the output from akms build: https://tpaste.us/WxpL 2024-04-14 06:51:37 And this is the output of ls -alR inside /var/lib/akms/tuxedo-drivers/4.4.0-r0/build: https://tpaste.us/ggnr 2024-04-14 06:52:00 after I've hit Ctrl+C 2024-04-14 06:59:16 we should disable riscv64 on llvm14, or maybe even just delete llvm14 2024-04-14 08:22:58 Can I somehow see the build queue for the build-edge-x86_64 builder? 2024-04-14 08:23:38 I want to understand if py3-maturin is queued for a rebuild or not. 2024-04-14 08:25:34 It is queued 2024-04-14 08:25:56 It also keeps failing tests (i think) on aarch64 2024-04-14 08:27:12 So, now maturin has tests conditionally disabled for aarch64 2024-04-14 08:28:47 thanks cely. checking whether it is queued or not is not something that i can do myself, right? 2024-04-14 08:30:11 You can check https://build.alpinelinux.org/ (same place i am looking at) 2024-04-14 08:31:06 but that only displays the last 3 aports built, so i know about maturin only because i'm checking that page constantly 2024-04-14 10:33:41 The build queue itself is not exposed indeed 2024-04-14 10:46:06 WhyNotHugo: current queue: https://tpaste.us/ePRW 2024-04-14 10:46:23 for x86_64 2024-04-14 10:58:24 I'm not at all familiar with the build system for the kernel and the kernel modules. I added -d to the "make" comman in AKMBUILD in order to see if I could figure out why it continously recurse deeper and deeper. However I'd highly appreciate if anyone could help me take a look at the gigantic output to see if anything looks out of the ordinary? https://tpaste.us/kX44 2024-04-14 10:59:25 The driver seems to use Kbuild files to tell the build system which modules to compile and my guess is that this is where things go wrong, when the build system try to figure out what to compile next... 2024-04-14 11:27:43 I'm so happy that all those py3-* packages now depend on a compatible python3 version. I'm always unware of the update of python3 and the major rebuild of all the py3-* pkgs is happening. This is the first time I don't have two days of broken python3 modules while I wait for all the py3-* stuff I am using to be rebuild :) 2024-04-14 12:15:25 I've made some debugging... I added some printout from the top level Kbuild file: https://tpaste.us/wx45 and in the second level i also added some print out: https://tpaste.us/JRyv However when looking at the output: https://tpaste.us/O8Km we can see that it print out the infomation from the top level Kbuild file every time and when that file is executed it thinks it is actually 2024-04-14 12:15:28 inside the top level directory as well. We can also see that the gcc commands being executed add one level each iteration... 2024-04-14 12:15:34 Anyone having any ide? 2024-04-14 12:16:11 idea* 2024-04-14 12:34:47 !64097 2024-04-14 12:59:36 The x86_64 builder keeps coming back to openvdb, and it takes quite a while before it finally finishes building and errors out in the python() split function 2024-04-14 13:02:00 due to there being something in the builder's /usr/lib/python3.11, which the amove with absolute patch matches 2024-04-14 13:03:12 cely: is that a bug in amove? 2024-04-14 13:03:30 I would not expect it to look at files from the root 2024-04-14 13:03:42 No idea, but i have always avoided using absolute paths with amove 2024-04-14 13:03:54 or maybe escape the * should be escaped 2024-04-14 13:03:59 -escape 2024-04-14 13:04:52 ah right 2024-04-14 13:05:42 that's the issue 2024-04-14 13:05:57 because it exists, that gets matched 2024-04-14 13:05:58 Yes, a pattern with an absolute path 2024-04-14 13:06:07 An absolute path with no pattern is no problem 2024-04-14 13:06:10 or I must say, expanded 2024-04-14 13:06:29 *mandatory whining about the fact that builders use something which isn't rootbld, or conversely that i can't build in the same environment as builders* 2024-04-14 15:43:39 if a package maintainer change email addresses (both for communications when flagged as outdated or in gitlab.al.o), do you need to followup with .mailmap patch? 2024-04-14 15:43:43 (see !64110 and !42977) 2024-04-14 18:18:08 can you not? 2024-04-14 18:23:54 ajhalili2006: .mailmap is optional, it's not used by pkgs.a.o 2024-04-14 18:25:01 xulfer: who/what? 2024-04-14 18:32:19 Oh sorry. A response to something in backlog that I didn't realize was so old. 2024-04-14 18:33:11 ah, that's alright then 2024-04-14 20:15:45 I worked around the Kbuild problem and created a MR !64135 2024-04-14 21:10:29 Could someone look at !63787? I've submitted the patch upstream and been given no respond as well as tried DM:ing Martijn (the maintainer) directly but he has some beef with me so I doubt he'll review it in any reasonable timeframe. 2024-04-14 21:10:35 response* 2024-04-14 22:37:35 any opinion on https://github.com/openwrt/packages/pull/23929 ? 2024-04-14 22:38:44 the alpine solution seems simpler 2024-04-15 09:56:39 i have reported riscv64 py-cpuinfo: https://github.com/workhorsy/py-cpuinfo/issues/214 2024-04-15 10:11:13 https://boehs.org/node/everything-i-know-about-the-xz-backdoor 2024-04-15 10:39:19 rnalrd: yup. that's one of the better resources about the xz backdoor. I haven't checked it lately 2024-04-15 14:29:20 ptrc: re llvm14 on riscv64, i disabled it because there were tests that failed 2024-04-15 14:29:40 and i want delete llvm14 2024-04-15 14:30:30 hm, we'd need to move stuff to new llvm then 2024-04-15 14:30:34 mostly postgresql 2024-04-15 14:30:46 i had a MR with that 2024-04-15 14:30:58 but also, clang14 2024-04-15 14:31:30 actually nothing uses clang14 on riscv64, sure 2024-04-15 14:31:31 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54473#note_392615 2024-04-15 14:32:47 i want delete llvm14. and im am tempted to delete everyhing depending on llvm14 2024-04-15 14:33:25 we have llvm 14, 15, 16, 17 and now also 18 2024-04-15 14:33:34 this insanity needs to stop 2024-04-15 14:33:54 true 2024-04-15 14:34:17 i'd go as far as to say we don't need 3 different versions of postgres 2024-04-15 14:34:26 i think we only need two 2024-04-15 14:34:55 two versions in stable releases is plenty already 2024-04-15 14:35:12 it is 2024-04-15 14:35:55 getting rid of llvm14 is a priority 2024-04-15 14:49:44 also, regarding the py3.12 testing/ rebuilds: do you think i can push some to master right now? 2024-04-15 14:50:02 sorting them out into pieces that would build separately would be a lot of effort 2024-04-15 14:50:11 so i'd just shove one big commit to master and see what happens 2024-04-15 14:55:45 Well, i've already opened !64214, so if those 2 are included in the big commit, i'd appreciate it if you also remove py3-pytest-regtest from py3-janus checkdepends 2024-04-15 14:59:33 shouldn't be too hard to rebase mine i guess 2024-04-15 16:33:30 ikke: I guess gitlab-tf!30 still requires a manual trigger, right? 2024-04-15 16:55:27 re, deleting llvm14, suggestion, build it first under ALv3.20 , when ok, delete it before al release 2024-04-15 16:56:10 just llvm14 stack 2024-04-15 18:00:38 fossdd: oh, I may have forgotten that, thanks 2024-04-15 18:01:43 What's gitlab-tf!30 about? 2024-04-15 18:02:04 I'm guessing it's probably not that ^ 2024-04-15 18:02:38 celie: adding a team for phosh 2024-04-15 18:04:34 Ah, i see 2024-04-15 18:14:52 "fossdd: oh, I may have forgotten..." <- thanks for finalising it! 2024-04-15 18:15:38 ah nice thanks! 2024-04-15 19:25:15 so apparently util-linux-misc dropped the "col" executable and nothing provides it anymore.. 2024-04-15 19:25:42 curious 2024-04-15 19:28:12 oh, no 2024-04-15 19:28:16 *our package* doesn't have it 2024-04-15 19:28:21 arch does, and they have the same version 2024-04-15 19:28:29 ok, so it needs to be enabled somehow 2024-04-15 19:28:33 they use meson though, not autotools 2024-04-15 19:29:32 I would not expect different build systems would provide different binaries 2024-04-15 19:30:51 ah, what i mean is that i can't strictly compare the build parameters 2024-04-15 19:30:57 because the meson ones are slightly different 2024-04-15 19:31:00 right 2024-04-15 19:31:24 UL_REQUIRES_COMPILE([col], [#include ], [__GLIBC__], [building for glibc]) 2024-04-15 19:31:24 UL_BUILD_INIT([col], [check]) 2024-04-15 19:31:34 okay this is.. what 2024-04-15 19:31:44 do they only build col when it's glibc because they need... limits.h..? 2024-04-15 19:32:51 https://github.com/util-linux/util-linux/commit/8886d84e25a457702b45194d69a47313f76dc6bc 2024-04-15 19:33:02 > col is deprecated anyways 2024-04-15 19:33:51 :D 2024-04-15 19:38:52 oh.. https://build.alpinelinux.org/buildlogs/build-edge-x86/testing/xonsh/xonsh-0.15.1-r1.log 2024-04-15 21:23:26 it may now be down to just testing/gdcm 2024-04-15 21:32:51 that, and the 50-ish packages that didn't build for me even locally 2024-04-15 21:33:23 because fun fact, all those build failures were introduced in between today and a week ago :p 2024-04-15 21:33:48 ( as in, everything that i bumped was previously successfully built, excluding maybe 2 packages where i had to disable tests ) 2024-04-15 21:34:28 yes, and I'm sure we've not seen the end of it 2024-04-15 21:35:18 even when these are done 2024-04-15 21:35:26 will they build agan? 2024-04-15 21:37:02 fwiw, i checked with aarch64 ( which supposedly built testing/ ) and it's about 70 packages 2024-04-15 21:37:48 76 if we include so:libpython3.11.so.1.0 2024-04-16 01:44:06 Hello! When someone's up, please take a look at !64233. 2024-04-16 01:44:39 I'm assuming the builders are super heavily loaded these days, because it's a small job but my pipeline timed out 3 times 2024-04-16 01:45:51 the latest version is still running atm but I'm going to sleep, but all the archs pass 2024-04-16 01:47:08 CI builders may be a bit busy but the package builders aren't, except riscv64 2024-04-16 01:47:23 I added a comment in the MR about abuild being wrong when it says chown/chmod should be done in APKBUILD instead of post-install 2024-04-16 01:47:34 that's not doable with dynamically added users 2024-04-16 01:48:21 a chown in APKBUILD can only be done on a super restricted set of users (the ones that are guaranteed to exist on the builder), and unless it's something like "nobody" then it probably shouldn't happen 2024-04-16 01:48:33 I've noticed that the ARM CI sometimes hangs like what the s390x CI did a few months ago 2024-04-16 01:49:42 Does pkgusers/pkggroups not work for what you want to do? 2024-04-16 01:52:32 I wasn't aware of this, if it works that's cool, but... how can it guarantee that the files will be chowned to the actual uid created on the target at pre-install time? 2024-04-16 01:52:49 aren't the files stored with numerical uid/gids in the tar.gz? 2024-04-16 01:54:24 in any case I need to crash, I'll take a look tomorrow but intuitively this cannot work unless major voodoo is happening behind the scenes 2024-04-16 01:54:47 I don't think they're stored numerically 2024-04-16 01:56:44 if apk maintains a list of human-friendly users/groups to chown files to after they're extracted, then that's great 2024-04-16 01:57:32 I'll check that tomorrow and update the MR if needed, thanks for the pointer 2024-04-16 02:13:33 skarnet: tar header stores both uid + gid integers as well as uname + gname strings. Extraction will prefer to use uname + gname if those exist on the system, otherwise it will use uid + gid 2024-04-16 05:53:42 skarnet: what Arnavion says, it's tar that stores the names and maps it to the system users 2024-04-16 10:18:59 Hi, i wanted to kindly ask someone to merge some non recent MRs: !63857 !63784 !63780 !63778 !62399 !61763 !60475 !60474 !60473 !60451 !60410 2024-04-16 11:53:22 I rebased a few of them, to make sure that they still build, and updated the 3.19-stable gstreamer one, that was previously not merged because it failed to build 2024-04-16 11:57:22 Is it normal that my pipelines remain pending for such a long time? #227090 2024-04-16 11:57:41 oh, algitbot, you disappoint me. https://gitlab.alpinelinux.org/skarnet/aports/-/pipelines/227090 2024-04-16 11:58:15 I haven't been able to get one completed since yesterday, some builder always times out at the 1 hour mark 2024-04-16 11:59:11 if they're that busy I'll stop overloading them, but you'll have to take my word for it that everything passes (each try passed on a few archs and the successes overlap) 2024-04-16 12:03:24 I don't think you need to worry about that, it's not like you're building a web browser 2024-04-16 12:03:55 no, just a web server :D 2024-04-16 12:04:06 also, your previous pipelines are canceled when you push changes and new ones are scheduled 2024-04-16 12:04:35 yeah but even the ones I let run get stalled for 1hr+ 2024-04-16 12:04:41 and #number is for gitlab issues, not pipelines 2024-04-16 12:04:59 it's the first time it happens to me and yeah my stuff is small so I'm wondering 2024-04-16 12:05:21 it's due to stuff other than yours 2024-04-16 12:05:28 are the builders super overloaded today 2024-04-16 12:07:10 see, that pipeline started 43 minutes ago and the job is still pending on 4 arches (including 32-bit x86 so it's not just an arm thing) 2024-04-16 12:07:26 in 17 minutes I'll get an e-mail saying it failed 2024-04-16 12:07:49 like, no, *you* failed to run it, builder :P 2024-04-16 12:15:52 yes 2024-04-16 12:16:24 it should say "I failed you"? 2024-04-16 12:21:24 chereskata: For the libpeas2 thing, gjs isn't the only failing test, C and py also fail, but that also happens with libpeas 2024-04-16 12:22:42 What are the CI busy with? We only have 8 ish copies of chrome, 5 copies of llvm and more and more rust projects 2024-04-16 12:23:39 For the ARM CI, i've noticed that they are having network issues, resulting in a situation, that to me, looks similar to what happened with s390x a few months ago 2024-04-16 12:25:17 ncopa: I'm not criticizing, just curious! 2024-04-16 12:25:47 although "I failed you" would indeed be a nice error message ;) 2024-04-16 12:30:53 What is th CI chewing now? 2024-04-16 12:31:48 ncopa: i think it has to do with our ARM ci server 2024-04-16 12:31:55 Some jobs seem to hang 2024-04-16 12:37:05 It reminds me of apk-tools#10947 (apk hangs on lossy network) 2024-04-16 12:44:35 cely: thank you for pointing the libpeas2 test failures out 2024-04-16 13:59:54 yeah there's something weird with the aarch64 builder. https://gitlab.alpinelinux.org/skarnet/aports/-/jobs/1347378 2024-04-16 14:01:31 in any case I fixed my MR to take last night's suggestions into account (thanks cely, Arnavion, ikke), now it passes everything including lint, stalled builders notwithstanding 2024-04-16 14:01:43 so someone please merge !64233 at your convenience :) 2024-04-16 14:03:00 You're welcome 2024-04-16 15:06:32 skarnet: just as an fyi, when gitlab says it needs to be rebased because it's behind, that's not somehting you need to care about, we'll rebase right before we merge. Only time it concerns you is when there are conflicts 2024-04-16 15:07:22 skarnet: we maintain linear history with aports, so every MR is rebase and ff-merged 2024-04-16 15:08:27 ikke: yeah, you already told me, but I want to be sure it's up-to-date because I could be working on a dependent thing in parallel (it has happened) 2024-04-16 15:08:35 call it paranoia on my part 2024-04-16 15:09:22 (paranoia is good, it's saved me a couple times when there actually were conflicts) 2024-04-16 15:13:43 right now I have no idea if https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/64233 passed CI or not 2024-04-16 15:14:42 no, some jobs were skipped 2024-04-16 15:15:12 But, in aggregate I guess all jobs passed once 2024-04-16 15:19:56 could there be dangling pipeline jobs? that aren't properly aborted when MRs are merged or changes pushed 2024-04-16 15:20:21 no, i think there are just big jobs 2024-04-16 15:20:30 3 huge jobs running at the same time 2024-04-16 15:20:53 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/64309 2024-04-16 15:22:49 no, its 4 2024-04-16 15:43:52 i think current priority is help build-edge-riscv64 move forward 2024-04-16 15:59:49 it's on py3-scipy again and that took a long time on the other builders 2024-04-16 16:17:06 yay, all jobs in my pipeline completed! thanks to whoever unclogged the pipes :) 2024-04-16 16:32:56 Ugh... Electron. 2024-04-16 18:10:05 Anyone have any objections or suggestions to this new aport? !64135 2024-04-16 18:31:39 any thoughts on adding lttng-modules ? 2024-04-16 18:33:21 o/ 2024-04-16 18:51:37 how does apk do the python dependency resolution? 2024-04-16 18:51:51 I had the disabled and removed md2gemini and py3-language-server packages installed 2024-04-16 18:52:30 so I only got some of the rebuilt packages upgraded 2024-04-16 18:53:17 before I removed those two 2024-04-16 19:41:36 pythpn subpackages of rebuilt aports may have been held back and just didn't pay attention 2024-04-16 20:29:49 hi! there's some security-related patches in tdesktop. the existing security bug (1-click RCE) only affects Windows (as it's the only one where the .pyzw extension is used) but it would be good to do the upgrade https://github.com/telegramdesktop/tdesktop/commit/49c9e08b6ce251d172cbe5afaaad5a76a69301e4 2024-04-16 20:30:30 i'm still marked as maintainer but as i've said, i'm no longer maintaining the package. it's unclear to me what the procedure is to abandon maintainership for a package 2024-04-16 21:14:44 any interest in packaging valkey? (or even replacing Redis with it?) 2024-04-16 21:42:05 you're free to package it, but probably not replace redis 2024-04-16 21:42:14 redis is still in the repos, and there's other alternatives too (redict) 2024-04-16 21:52:57 Nulo: it is usually to create an MR, or create an issue 2024-04-16 21:55:54 things said on IRC will be forgotten 2024-04-16 21:56:14 29a663950e8ae40666799971e5013aac64b39698 2024-04-16 22:01:24 The whole replacing packages due to future licensing thing can be a bit of an issue yeah? Vectorscan vs Hyperscan has that too atm. Some of these forks aren't even claiming api/abi stability. so just providing another fork with the same libs and such seems a little irresponsible. 2024-04-16 22:04:00 well it would be a big commitment to guarantee *future* api stability as well. you'd have to essentially do black box reverse engineering and clean room development to re-implement the same features under your new license 2024-04-16 22:04:05 s/new/own/ 2024-04-16 22:04:30 so ultimately you don't see these projects get replaced. people just move over to using the new project 2024-04-16 22:04:44 Yeah. That's why I'm kind of not a fan of trying to replace them. Especially if it uses the same name and such for I guess some notion of easy of transfer. 2024-04-16 22:05:09 Since things like cmake and such will sometimes like to whatever lib of that name it finds. 2024-04-16 22:05:36 and in cases like redis it's probably looking for redis not a fork. 2024-04-16 22:10:21 I hear you, but I do think at some point Redis will have to go away. I don't see upstream doing any more releases (even for security issues), and it'll slowly bitrot... 2024-04-16 22:10:48 but there's probably a decent bit of time before that eventuality comes to pass 2024-04-16 22:12:51 and as far as redict goes, I don't see that becoming the predominant fork unless something crazy happens 2024-04-16 22:17:44 "29a663950e8ae40666799971e5013aac..." <- yipee, thanks! i didn't know you could just blank out the Maintainer field 2024-04-16 22:19:49 in theory we should also bump pkgrel so package gets rebuilt, but i was afraid it will fail to build and dont have time to clean up 2024-04-16 22:20:21 im trying to run the scipy tests in verbose mode but I'm strugling 2024-04-16 23:42:47 hmm, the valkey devs install symlinks from redis* utils to valkey equivalents... I wonder if that's wise in this case (conceivably someone could install redis and valkey on the same system) 2024-04-16 23:46:53 I guess because they want to make it easy for the people who just want to switch and not have to update their scripts etc 2024-04-17 01:01:02 iggy: yeah that would be my concern 2024-04-17 01:01:51 because a lot of build tools that expect the abi/api to be the same in whatever case just check for the existence of say a library, binary, header, etc. 2024-04-17 01:02:23 and if that fork has no intention of maintaining compatibility which most aren't then that could cause some problems. 2024-04-17 02:07:11 can someone please revoke my maintainership of py3-virtualenv? 2024-04-17 07:10:26 Xe_: can you please create an issue for it? 2024-04-17 07:11:00 i think its good to have a reference in the commit message 2024-04-17 11:04:10 !62289 some django aports getting orphaned 2024-04-17 12:40:58 im bootstrapping the 3.20 builders now 2024-04-17 12:41:11 except riscv64, which I dont know what to do about 2024-04-17 12:41:14 nice 2024-04-17 12:54:42 now that it all passes, could someone please merge !64233 before it gets lost in the weeds? thanks ^^" 2024-04-17 13:01:32 skarnet: thanks for tipidee 2024-04-17 13:02:04 thank me when it's in XD 2024-04-17 13:02:42 ;), ok 2024-04-17 13:15:19 go build needs amd64 but $CARCH is x86_64 2024-04-17 13:16:07 is there any trick to solve this diff? 2024-04-17 13:17:53 Something like https://git.alpinelinux.org/aports/tree/community/go/APKBUILD#n191 ? 2024-04-17 13:43:08 libreoffice-common-7.6.4.1-r3.apk in the edge repo is weird 2024-04-17 13:44:02 there are lots of files but only the dependencies install with 'apk add' 2024-04-17 13:44:26 'apk info -L' shows it's empty 2024-04-17 13:44:42 in addition, there is a core dump file inside the .apk 2024-04-17 13:45:50 kunkku: there is an issue about it 2024-04-17 15:51:14 celie: thx but it's "CTARGET_ARCH", does it equal "CARCH" ? 2024-04-17 15:52:18 qaqland: CTARGET_ARCH is used for cross compilation 2024-04-17 16:00:53 in APKBUILD, do i need to consider cross compilation ? 2024-04-17 16:02:30 qaqland: For most packages, no 2024-04-17 16:06:17 got it :) 2024-04-17 17:09:57 i'm looking at this package https://github.com/dnote/dnote which cli and server bin have different version for release 2024-04-17 17:10:27 qaqland: then I'd package them separately 2024-04-17 17:11:17 their sources are in the same repo 2024-04-17 17:16:48 the same thing as proot and care 2024-04-17 18:56:37 Anyone up to verify !63886 if it's good to merge? Thanks in advance 2024-04-17 18:57:37 lassebq: I've added a suggestion for a fix 2024-04-17 18:57:58 Since wine is a concrete (not virtual) package, you need to specify an actual version number that is provided 2024-04-17 18:58:15 Alright 2024-04-17 18:59:00 lassebq: it's also good to provide the reasoning that you are adding it 2024-04-17 19:00:53 winetricks has wine as a dependency, although I'm pretty sure it just needs any wine. I did mention that it fixes #15932 in commit desc 2024-04-17 19:01:27 I mean MR desc, sorry 2024-04-17 19:01:28 right 2024-04-17 19:04:24 By the way, not sure if the commit guidelines mention it but should you make proposed changes in the same commit or just make another commit on top? 2024-04-17 19:04:47 The commit should be amended 2024-04-17 19:05:23 How exactly is that done? git reset and recommit? That's what I do at least 2024-04-17 19:05:32 git add && git commit --amend 2024-04-17 19:05:52 Thanks, learning new things about git every day :D 2024-04-17 19:06:06 While you're at it, you can adjust the message to 'testing/wine-staging: provide wine' 2024-04-17 19:06:17 focusses more on the goal rather than the code change 2024-04-17 19:07:55 I read your message too late :P 2024-04-17 19:08:51 Anyway, did that change too 2024-04-17 22:21:01 in case someone has free cycles. fakeroot has a failing test now. its a blocker for the 3.20 bootstrap. I'll have a look at it tomorrow unless someone does it while I'm a sleep 2024-04-18 00:26:57 ncopa: the t.tar test is sketchy, it compares the list of files in a tar-done-in-fakeroot with a list of files in a preexisting tar. I checked and all the files are there, just in a different order. 2024-04-18 00:27:32 I don't think there's a guarantee on the file order in an archive you create from a directory hierarchy, it depends on the filesystem and stuff 2024-04-18 00:27:52 so if the preexisting tar was made with a different tar version than the one we use, discrepancies might happen 2024-04-18 00:28:25 the correct test would be to make a tar on the spot *outside* of fakeroot, then make the same tar on the spot *inside* of fakeroot, and compare the two 2024-04-18 00:28:49 but the build machine should make both tars instead of comparing the inside tar with a premade thing 2024-04-18 00:29:07 so I suggest ignoring the test for now and reporting the bug to fakeroot upstream. 2024-04-18 01:10:20 Is this related to what was reported in https://bugzilla.redhat.com/show_bug.cgi?id=1601392 ? 2024-04-18 01:13:42 Hmm, that was due to user/group differences 2024-04-18 01:26:53 not looking into details: yeah, files in a directory aren't guaranteed to have a specific order 2024-04-18 01:42:36 it looks like fakeroot's test harness attempts to sort the files when comparing them, though 2024-04-18 01:42:43 (in test/compare-tar) 2024-04-18 01:45:54 yeah, there are other problems but I'm not sure whether it's fakeroot or the tartest script doing the wrong thing 2024-04-18 01:46:14 because the tartest script is doing weird stuff that's hard to read 2024-04-18 01:48:21 it's quite annoying to debug it 2024-04-18 01:48:24 my suspicion is that it's more likely that problems happen at file creation time than archive creation time 2024-04-18 01:48:45 and I wouldn't be surprised if a change in coreutils or whatever was at the source of it 2024-04-18 01:48:52 with all the cp/mv/chown going on 2024-04-18 01:49:39 it's very possible that there's still a bug with fakeroot, not implementing a new syscall used in a new coreutils tool or something like that 2024-04-18 01:50:24 but my unsubstantiated, unproven nose feeling is that we can clear tar 2024-04-18 01:51:16 and this is why tests are useless when they're actually harder to read than the code they're supposed to test! 2024-04-18 01:51:24 the owner/group are wrong 2024-04-18 01:51:51 https://bpa.st/PA5Q finally managed to get some debug output out of it 2024-04-18 01:51:58 you mean in 2.file and 4.file? yeah 2024-04-18 01:52:00 (hacked export VERBOSE=1 into test/defs) 2024-04-18 01:52:12 and a few other files too, yeah 2024-04-18 01:52:15 but it may be because of the chown $FILES earlier 2024-04-18 01:52:18 that's my point 2024-04-18 01:52:30 yeah 2024-04-18 01:53:13 I'm puzzled as to what this is trying to test exactly 2024-04-18 01:53:36 Earlier versions of Fedora has this patch: https://src.fedoraproject.org/rpms/fakeroot/blob/epel7/f/relax_tartest.patch 2024-04-18 01:53:41 s/has/had/ 2024-04-18 01:54:21 elly: it's creating a bunch of silly stuff with wild permissions and shoving it all into a tar, to check that the calls made by fakerooted tar don't mess up anything 2024-04-18 01:55:03 but I can't tell whether the issues happen at silly stuff creation or at tar time 2024-04-18 01:55:20 and stuff creation feels more likely 2024-04-18 01:55:47 in any case I need to go to sleep, so have fun if you're diving further into it 2024-04-18 07:35:21 thank you for analyzing that 2024-04-18 07:36:47 now we also have py3-pychaos hanging during test. it feels like someone backdoored a bitcoin miner in tests/test_stress.py, but it could also be something else 2024-04-18 07:38:39 its caused by scipy upgrade 2024-04-18 07:55:40 does anybody has free cycles to help follow up chaospy tests failing and hanging? It may be related scipy upgrade: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63594#note_396187 2024-04-18 08:10:49 Hi, anyone know why the aarch64-virt (6.6.27) linux kernel is compiled with CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity", but CONFIG_SECURITY_LOCKDOWN_LSM is not set? (while on x86_64 it's CONFIG_SECURITY_LOCKDOWN_LSM=y). 2024-04-18 09:29:27 no idea but a wild guess is that someone wanted a change, sent an MR and didnt bother to change the other arch 2024-04-18 09:30:16 or the architectures has different defconfig 2024-04-18 09:59:53 the fakeroot thingy seems to be a real bug 2024-04-18 10:01:15 i wonder if the fakeroot was causing this: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63669 2024-04-18 10:06:53 aw. i think this is pretty serious 2024-04-18 10:29:24 ncopa: one thing I recently noticed in fakeroot is that it was hanging and trying to close all FDs into infinity 2024-04-18 10:33:05 if I understand the test correctly, it sets permissions on files, move files around and then creates a tar archie and check if the permissions are correct 2024-04-18 10:33:07 they are not 2024-04-18 10:33:52 so our fakeroot may set the permissions on files in the .apk file wrong, to something unpexpected 2024-04-18 10:33:54 which is bad 2024-04-18 10:34:01 Does this mean we need to audit packages to confirm permissions are correct? 2024-04-18 10:34:27 would be good. but. how do we know what the permissions are supposed to be? 2024-04-18 10:34:58 Not something easy to do 2024-04-18 10:35:27 for long term: we need to have some sort of machine readable list for expected permissions of each file 2024-04-18 10:35:32 so we can audit 2024-04-18 10:35:59 that said, if this happens to be true, i don't think it affect many packages, if any 2024-04-18 10:36:01 sounds similar in scope as selinux / apparmor 2024-04-18 10:36:24 we usually dont set permissions and then move files around, do we? 2024-04-18 10:36:29 maybe we do, in subpackages 2024-04-18 10:36:37 yeah, amove et al 2024-04-18 10:37:36 so we could limit the search. APKBUILDs with pkgusers/groups, and verify permissions in subpackages 2024-04-18 10:37:47 but first we need to fix fakeroot 2024-04-18 10:37:56 which likely is going to be non-trivial 2024-04-18 10:40:46 is it guaranteed subpackages are always going to have the same version? or is the commit id the better key to identify an "origin" release? 2024-04-18 10:41:48 i think it is supposed to be guaranteed that subpackages has exacly same version as origin 2024-04-18 10:42:00 ok thanks :) 2024-04-18 10:42:16 but there have been attempts to "fix" that, so subpackages could have any version 2024-04-18 10:42:26 ok, I'm going to use the commit id then 2024-04-18 10:42:47 might be hacked APKBUILD that force set different versions to subpackages 2024-04-18 10:43:22 but if they do things will break, as subpackages are expected to have same version 2024-04-18 10:43:44 we should probably do a check in abuild to verify that version is exactly the same on all subpackages 2024-04-18 10:43:50 Yeah, lua-aports execpts that 2024-04-18 10:43:51 yeah, Arch has this too (setting $pkgver from inside a package_foo() function) 2024-04-18 10:44:09 going for the commit seems to be the more future proof approach 2024-04-18 10:44:19 yeah 2024-04-18 10:44:40 there is an open MR for adding support to set subpkg version to anything, but I dont like that idea 2024-04-18 10:44:41 kpcyrd: I'm still not following what the goal is? 2024-04-18 10:44:55 ikke: context is importing alpine into https://whatsrc.org/, showing common build inputs of Linux distros 2024-04-18 10:46:03 for example, this APKBUILD: https://git.alpinelinux.org/aports/tree/community/cmatrix/APKBUILD?id=dcf926d126ee921df71282780cae6c160fe30783 2024-04-18 10:46:04 oh thats cool 2024-04-18 10:46:09 is referencing this sha512: 1aeecd8e8abb6f87fc54f88a8c25478f69d42d450af782e73c0fca7f051669a415c0505ca61c904f960b46bbddf98cfb3dd1f9b18917b0b39e95d8c899889530 2024-04-18 10:46:24 which is also what Debian, Arch Linux and Fedora are using: https://whatsrc.org/artifact/sha512:1aeecd8e8abb6f87fc54f88a8c25478f69d42d450af782e73c0fca7f051669a415c0505ca61c904f960b46bbddf98cfb3dd1f9b18917b0b39e95d8c899889530 2024-04-18 10:47:14 ncopa: thanks :) 2024-04-18 10:47:31 so you could compare which distros uses exactly the same source 2024-04-18 10:47:40 yes 2024-04-18 10:47:46 there may be patches on top of course 2024-04-18 10:48:25 but quite often they have some kind of consensus on "what's the source code of $asdf" 2024-04-18 10:49:03 so if it is proven that one source tarball is backdoored, it is trivial to find out exactly which distros uses it 2024-04-18 10:50:51 for example, yes. I noticed the project is quite difficult to explain, even to other programmers. it barely solves any problem, it's more like a documentation effort. 2024-04-18 10:51:57 it can also tell if the tarball is likely autotools pre-processed: https://whatsrc.org/artifact/sha256:99032a437fbcb38a37f35f23712bbeb6489be112450e02443e16786d3d745b31 2024-04-18 10:53:21 cool 2024-04-18 10:53:41 I still haven't found any other ecosystem that pre-processes their source code like this, often it's a 1:1 VCS snapshot 2024-04-18 10:54:02 s/often/usually/ 2024-04-18 10:54:23 btw. pre-processed autotools scripts are very useful, specially when bootstrapping from scratch 2024-04-18 10:54:30 less external dependencies 2024-04-18 10:54:36 and less circular deps 2024-04-18 10:54:53 but it comes with a pricetag ofc :) 2024-04-18 10:55:18 whatsrc.org is very cool! 2024-04-18 10:56:22 the pre-processing makes it very difficult to secure unfortunately (on top of m4 being very hard to read) :S I'm hoping bootstrappable.org can figure something out for this 2024-04-18 10:56:45 yeah, thats the price 2024-04-18 10:58:09 in some cases I can cross-reference Arch Linux data to find the (supposedly) upstream and I'm planning to render it on the website somehow (after I verified everything checks out) 2024-04-18 10:58:38 (upstream repo including the relevant git tag/commit) 2024-04-18 10:59:14 im scratching my head on a fakeroot bug now 2024-04-18 10:59:31 really confused what introduced it 2024-04-18 11:06:45 i found it 2024-04-18 11:06:54 coreutils 9.5 + fakeroot = broken 2024-04-18 11:07:12 so more fall-out from coreutils 2024-04-18 11:07:43 skarnet allready suggested it 2024-04-18 11:09:28 ah, i missed that part 2024-04-18 11:10:24 i believe it is a real bug in fakeroot, triggered by new coreutils 2024-04-18 11:10:55 unfortunally it is not trivial 2024-04-18 11:11:06 ...to report it upstream 2024-04-18 11:11:15 no idea where they track fakeroot bugs 2024-04-18 11:12:01 yeah, me neither 2024-04-18 11:12:05 was looking for something 2024-04-18 11:12:34 there is an email address 2024-04-18 11:12:58 but its not trivial to get access to the inbox for that email to look if it has been reported before :) 2024-04-18 12:07:27 how do you get CBUILD= working again? I have qemu- installed and restarted binfmt but it does not seem to matter 2024-04-18 12:08:19 Ah got it, I was missing qemu-openrc 2024-04-18 13:16:32 Is !64441 a good way of solving things, or should i just add options="!fhs"? 2024-04-18 13:16:59 New fhs checks were introduced in https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/254 2024-04-18 13:31:22 i'd say that's better than !fhs 2024-04-18 13:31:33 especially if it's being made by the openrc service file anyway 2024-04-18 13:33:34 what about docker? 2024-04-18 13:36:21 you mean, if someone's running mongooseim in docker? 2024-04-18 13:37:03 yes 2024-04-18 13:37:46 Does Docker not use the service file? 2024-04-18 13:37:51 No 2024-04-18 13:37:57 docker does not use services at all 2024-04-18 13:38:01 usually when people write dockerfiles, they don't use a service manager 2024-04-18 13:38:08 You just run the process 2024-04-18 13:41:43 I had a look at mongooseimctl, and it seems there is a test for whether /var/lock/mongooseim/ctl exists: https://github.com/esl/MongooseIM/blob/master/rel/files/mongooseimctl#L200 2024-04-18 13:42:47 CONNLOCKDIR is set to /var/lock/mongooseim/ctl 2024-04-18 14:12:57 wow, whatsrc is neat - and mitigates the annoyance of "where the heck did debian get this from? ... ... ... oh no, sourceforge" 2024-04-18 14:37:26 that looks pretty great indeed, but I don't see links to the actual source packages? 2024-04-18 14:37:49 e.g. https://whatsrc.org/search?q=coreutils doesn't say that the source for Debian coreutils is ftp.gnu.org? 2024-04-18 14:40:05 (also tbh sourceforge nowadays is probably less risky than having github as the main repo...) 2024-04-18 14:42:37 sourceforge could do with a usable web interface 2024-04-18 14:47:29 yeah, it looks like they have copies of the tarballs hosted locally instead 2024-04-18 14:58:48 well it would be nice to have the source for the _orig's 2024-04-18 14:59:32 I trust debian not to modify them because they already add so much shit to make the non-orig tarballs, they don't need to modify the orig 2024-04-18 14:59:42 but that doesn't tell me where the orig comes from 2024-04-18 15:14:38 package's test needs PostgreSQL running background, dont know whether abuild support this kind of test? 2024-04-18 15:17:17 Oh no, does #16017 mean we'll have to rebuild Python yet again? 2024-04-18 15:18:30 The last time i applied a version constraint on openssl (!57528), i did it for libssl3, libcrypto3, and even openssl-dev, just to be safe 2024-04-18 15:23:21 qaqland: Usually, for those kinds of tests, we just disable them. 2024-04-18 15:29:22 got it :) 2024-04-18 15:37:21 cely: it looks to like libssl3 should depend on verioned libcrypto3 2024-04-18 15:38:02 I've seen that discussed somewhere 2024-04-18 15:40:14 ce9fe873f850cb0c44db559e3b9d4678e9e27dd4 2024-04-18 15:40:21 we should do the same with libssl 2024-04-18 15:46:16 !64447 2024-04-18 15:47:18 However, i can't remember if there were any reasons for not having this from the last time this issue was brought up 2024-04-18 15:49:07 I guess if there're any good reasons, we'll know once this is merged :) 2024-04-18 16:21:05 i think nobody thought about it last time 2024-04-18 16:21:46 re fakeroot bug, its triggered by recent coreutils, so it only affects packages that uses pkgusers/pkggroups, subpackages and coreutils 2024-04-18 18:16:19 Is it a requirement for CI to be sucessful on a MR for it to be merged? Or is ok when there's a timeout failure? 2024-04-18 18:16:42 Or when it's expected to fail for certain architectures ig? 2024-04-18 18:18:48 lassebq: builders are pretty loaded atm, timeouts are to be expected, you can relaunch the jobs on the archs that timed out until every arch passes 2024-04-18 18:19:24 Ok, so it's preferred for them to be successful on a MR? 2024-04-18 18:19:46 Even if the MR doesn't modify much 2024-04-18 18:20:17 not a core dev, but I assume a patch won't get merged if it doesn't build, yes ^^' 2024-04-18 18:22:08 Alright 2024-04-18 19:19:47 How much behind is the riscv64 builder? I am missing a package (mbedtls2) that was added on 10 April. 2024-04-18 19:20:03 53 / 627 (8%) 2024-04-18 19:20:08 https://build.alpinelinux.org/ 2024-04-18 19:29:03 Is it possible to see the full queue for the riscv64 builder? I would like to know if mbedtls2 still in the queue 2024-04-18 19:29:15 I can find ouyt 2024-04-18 19:31:45 hjaekel: https://tpaste.us/Z5Y4 2024-04-18 19:31:59 mbedtls2 is in there 2024-04-18 19:32:28 great, thank you. Then I just have to be patient 2024-04-18 20:18:11 right now it is scipy and/or chaospy that is blocking 2024-04-18 20:19:05 something broke with recent scipy update and chaospy deadlocks in tests 2024-04-18 20:19:10 happens also on x86_64 2024-04-18 20:58:42 argh! how hard can they make it to git bisect coreutils 2024-04-18 20:58:51 gnulib is getting in the way 2024-04-18 20:59:55 make[2]: *** No rule to make target 'lib/skipchars.c', needed by 'lib/libcoreutils_a-skipchars.o'. Stop. 2024-04-18 21:00:16 what where who says lib/libcoreutils_a-skipchars.o is needed by anything? 2024-04-18 21:00:30 ncopa-desktop:~/src/coreutils ((no branch, bisect started on master))$ rg skipchars 2024-04-18 21:00:30 ncopa-desktop:~/src/coreutils ((no branch, bisect started on master))$ 2024-04-18 21:00:37 no trace of skipchars 2024-04-18 21:01:22 ok `ag` found it 2024-04-18 21:01:27 lib/gnulib.mk 2024-04-18 21:06:26 anybody any clue how to git bisect a project using gnulib? 2024-04-18 21:10:38 sigh i neeed too bootstrap gnulib. takes 5-10mins to do so 2024-04-18 21:28:46 the wonderful world of understanding what's going on with GNU software :/ 2024-04-19 02:10:44 indeed 2024-04-19 07:15:46 morning. i found the commit introducing fakeroot breakage 2024-04-19 07:15:53 193449b17334649a2abcbca589544d858fca92a1 2024-04-19 07:16:57 is that a commit in fakeroot? 2024-04-19 07:18:37 coreutils 2024-04-19 07:19:08 i found that it happens with fakeroot 1.32, 1,33 or 1,34 2024-04-19 07:19:22 but never with coreutil 9.4. only 9.5 2024-04-19 07:19:29 so i bisected coreutils to: 2024-04-19 07:19:32 https://github.com/coreutils/coreutils/commit/193449b17334649a2abcbca589544d858fca92a1 2024-04-19 07:29:38 makes no sense 2024-04-19 07:37:39 it is definitively related `env` binary 2024-04-19 07:39:25 whatta 2024-04-19 07:39:44 this is *weird* makes no sense whatsoever 2024-04-19 07:40:02 i bisected it to the commit pointing to env 2024-04-19 07:40:26 i have coreutil 9.5 installed on my system from apk, so running `make check` fails 2024-04-19 07:40:48 when bisecting I did: PATH="$HOME/src/coreutils/src:$PATH" make check 2024-04-19 07:41:12 so the binaries from coreutils git gets preference 2024-04-19 07:41:21 thats how I found the commit 2024-04-19 07:42:21 so, in coreutils git source tree, I `rm src/env` to delete the offending binary. and run PATH="$HOME/src/coreutils/src:$PATH" make check from fakeroot 2024-04-19 07:42:25 and it passes! 2024-04-19 07:43:26 problem is, that I'd expect it to fall back to the apk provided binary from coreutils 9.5 2024-04-19 07:55:05 oh.... 2024-04-19 07:55:07 what if 2024-04-19 07:55:24 what if the problem is in gnulib, and not coreutils? 2024-04-19 07:55:38 nightmare scenario 2024-04-19 08:01:14 it's never not gnulib 2024-04-19 08:01:32 have fun bisecting that though 2024-04-19 08:01:41 they update it in bulk 2024-04-19 08:02:00 still got nightmares about that one time i was bisecting guile 2024-04-19 09:00:23 ncopa: were you building coreutils with the same options as in the APKBUILD? because in the APKBUILD env is built as a separate binary 2024-04-19 09:00:40 no idea 2024-04-19 09:00:45 I don't know how it would make a difference, but at this point every difference could be relevant 2024-04-19 09:01:56 but I dont htink it is env 2024-04-19 09:02:35 i was able to rebuild coreutils from same bad commit, and now it passes 2024-04-19 09:02:51 so what was the bisecting factor 2024-04-19 09:03:26 building coreutils from git requires you to fetch and install gnulib from internet somewhere 2024-04-19 09:04:10 when bisecting, i occationally had to refresh gnulib, because there were leftovers 2024-04-19 09:04:19 ugh 2024-04-19 09:04:21 make failed because of missing C files 2024-04-19 09:04:32 ugh indeed 2024-04-19 09:04:40 the coreutils APKBUILD doesn't mention gnulib though 2024-04-19 09:04:52 does coreutils provide a vendored one? 2024-04-19 09:04:57 because for release tarballs they embed that with the tarball 2024-04-19 09:04:57 yes 2024-04-19 09:05:01 xz style 2024-04-19 09:05:11 so it would be the vendored one in 9.5 that's at fault 2024-04-19 09:05:23 that is what i am thinking now 2024-04-19 09:05:53 and i wonder if i should try figure how those gnulib git submodules works and try build new coreutils with old gnulib and vice versa 2024-04-19 09:06:25 gnulib is integrated with autoconf macros somehow 2024-04-19 09:06:36 so if you touch one, you will likely break the other 2024-04-19 09:06:42 are there no numbered standalone releases for gnulib that people could use instead of vendoring or messing with git submodules 2024-04-19 09:06:56 maybe 2024-04-19 09:07:06 there is a gnulib-tool too 2024-04-19 09:07:46 time for me to suggest napalm 2024-04-19 09:07:47 this some seriously dark code and i dont know if i have the mental strength for it 2024-04-19 09:07:51 and by that I mean 2024-04-19 09:07:59 burn it with fire 2024-04-19 09:08:06 yes but in this precise case 2024-04-19 09:08:23 would fakeroot work with busybox instead of coreutils 2024-04-19 09:08:32 I suppose not if it's in the deps 2024-04-19 09:08:45 but it might be simpler to find where the coreutils dep is 2024-04-19 09:09:22 it's probably a cp --lame-long-option somewhere 2024-04-19 09:10:04 unvendor all the things 2024-04-19 09:10:10 yes 2024-04-19 09:10:25 so I thought about foce use busybox. i suppose the fakeroot tests will need some patching for that to work. after all there is a reason why coreutils was pulled in as checkdepends 2024-04-19 09:10:55 but that would only hide the real problm 2024-04-19 09:11:24 that's true, fakeroot should work whether or not coreutils is installed 2024-04-19 09:11:33 if we later woudl build an apk, wich has coreutils in dependency chain, we'd silently end up with wrong permissions in apk 2024-04-19 09:11:37 yeah 2024-04-19 09:11:55 so we must fix it with coreutils 2024-04-19 09:12:02 or at least find out exactly whats going on 2024-04-19 09:12:26 i mean, could easily be caused by a backdoor sneaked into gnulib 2024-04-19 09:12:49 build latest coreutils from git which has a recent gnulib that makes fakeroot work, until coreutils 9.6 which will vendor a working gnulib? 2024-04-19 09:12:51 perfect hiding spot. nobody would ever want look there 2024-04-19 09:13:35 how do i use different version of gnulib with coreutils? 2024-04-19 09:13:54 you said coreutils git fetches one 2024-04-19 09:14:19 i did, and I also dont want find out how this mess works 2024-04-19 09:14:23 its a dark place 2024-04-19 09:14:25 :) 2024-04-19 09:14:39 I mean when bisecting you started with the latest coreutils 2024-04-19 09:14:52 oh but maybe that's the one that failed 2024-04-19 09:14:59 and old ones worked 2024-04-19 09:15:05 i started with v9.5 bad and 9.4 good 2024-04-19 09:15:09 yeah 2024-04-19 09:15:18 im gonna bang my head into this 2024-04-19 09:15:24 quick fix 2024-04-19 09:15:30 for bootstrap, pin coreutils to 9.4 2024-04-19 09:15:47 was thinking simply untar 9.4 and 9.5 and diff -r gnulib/ 2024-04-19 09:16:21 or diff the configure log from 9.4 and 9.5 2024-04-19 09:16:36 sure, my point is, if bootstrap is being blocked, you can start the bootstrap build with coreutils 9.4 and debug while metal is chugging 2024-04-19 09:17:00 yeah thats a possibility 2024-04-19 09:17:05 downgrade to 9.4 2024-04-19 09:17:19 but 9.5 fixes a CVE, so that is not optional either 2024-04-19 09:17:42 i think there is only one way 2024-04-19 09:17:46 and that is forward 2024-04-19 09:17:49 GNU code don't have CVE impossible challenge 2024-04-19 09:18:52 sure, bring in 9.4 gnulib, unless the CVE was precisely in there 2024-04-19 09:18:59 see if it makes fakeroot work 2024-04-19 09:19:41 and if it does, send the whole shit to gnulib people with a nice gift wrap and a ribbon 2024-04-19 09:19:52 happy Easter, fix your stuff 2024-04-19 09:20:32 every day i become happier about my decision to eliminate coreutils from my life 2024-04-19 09:20:56 you and me both 2024-04-19 09:21:20 what coreutils equivalent are you using in Chimera? 2024-04-19 09:21:32 lucky you 2024-04-19 09:21:49 we have a suite of tools ported from latest version of freebsd 2024-04-19 09:21:54 it covers not only coreutils but a lot more stuff 2024-04-19 09:22:43 huh, interesting 2024-04-19 09:22:43 diffutils, findutils, sh, portions of util-linux, grep, vi, m4, patch, awk, tip/cu, etc 2024-04-19 09:23:02 alpine uses busybox. but problem is we give our users the option to use GNU coreutils 2024-04-19 09:23:14 giving users options is what is killing me 2024-04-19 09:23:18 i occasionally expand it with more stuff 2024-04-19 09:23:36 ncopa: ah, if only there wasn't that problem of having users 2024-04-19 09:23:38 ;) 2024-04-19 09:23:40 lol 2024-04-19 09:23:48 exactly 2024-04-19 09:23:53 though lately not because it's pretty complete 2024-04-19 09:26:34 reminds me i should look into updating fakeroot though 2024-04-19 09:26:44 i'm still on 1.25.3 because i found any newer version totally busted 2024-04-19 09:27:45 there is the RiiR uutils-coreutils 2024-04-19 09:27:54 $ diff -u coreutils-9.4-r2.log coreutils-9.5-r0.log | tpaste 2024-04-19 09:27:54 https://tpaste.us/MR6D 2024-04-19 09:28:12 I have packaged it so that it can co-exist with coreutils but maybe I should change that so that it can instead provides="coreutils"? 2024-04-19 09:28:29 well, even that version is kinda busted under regular invocation because it breaks priority of LD_LIBRARY_PATH 2024-04-19 09:28:35 but newer versions were busted in a worse way 2024-04-19 09:28:44 configure log may reveal if coreutils swapped some gnulib func with musl or other way around 2024-04-19 09:30:07 doesn't seem to have anything obviously bad 2024-04-19 09:30:17 there's a new qsort_r test 2024-04-19 09:30:34 yeah but i don't see how that'd interfere with fakeroot 2024-04-19 09:30:51 oh that's interesting, there's also a qsort_r signature test 2024-04-19 09:30:53 good stuff 2024-04-19 09:33:53 + CC src/libsinglebin_chgrp_a-coreutils-chgrp.o 2024-04-19 09:34:05 that's new stuff 2024-04-19 09:35:15 -checking for statx... no 2024-04-19 09:35:15 +checking for statx... yes 2024-04-19 09:35:45 hm 2024-04-19 09:35:58 that could definitively cause soemthing like this 2024-04-19 09:36:19 i think we patch out the statx stuff in fakeroot 2024-04-19 09:37:12 ac_cv_func_statx=no ? 2024-04-19 09:37:17 statx was added to musl 2024-04-19 09:38:02 so we probably need remove the xstat patch from fakeroot? 2024-04-19 09:38:22 removing the xstatjunk.patch makes 5 tests fail instead of 1 2024-04-19 09:38:38 not the same stuff 2024-04-19 09:39:00 xstat and statx? 2024-04-19 09:39:24 right 2024-04-19 09:39:51 statx is very likely the cause 2024-04-19 09:39:51 how could I possible mix up those two? stupid me 2024-04-19 09:40:20 I'll test ac_cv_func_statx=no 2024-04-19 09:40:22 good idea 2024-04-19 09:40:26 people are so good at naming 2024-04-19 09:41:05 wow, ac_cv_func_statx=no makes 6 tests fail for me 2024-04-19 09:41:08 but but but 2024-04-19 09:41:28 i did test fakeroot in alpien 3.19 branch 2024-04-19 09:41:31 with old musl 2024-04-19 09:41:43 urge to rewrite fakeroot rising 2024-04-19 09:41:55 and i observed the same there. coreutils 9.4 works, 9.5 fails 2024-04-19 09:41:58 with same old musl 2024-04-19 09:42:08 so it's not musl-related 2024-04-19 09:42:23 and not statx related either then? 2024-04-19 09:42:30 well it could still be 2024-04-19 09:42:45 but why do more tests fail without than with 2024-04-19 09:44:14 I need to shower and to eat something, please have a genius idea and fix everything before I'm back and decide to start a fakeroot replacement 2024-04-19 09:56:29 fakefakeroot 2024-04-19 10:01:04 what would be more usefult than a new fakeroot would be a `tar --permissions-from-file=list-with-owners-and-permissions-for-files-in-tar` 2024-04-19 10:01:34 so you could set the owner in tar archives for given files to something else than found on file system 2024-04-19 10:01:40 then we wouldnt need fakeroot 2024-04-19 10:02:17 you could even do this in postprocessing 2024-04-19 10:02:27 as in, read the tar file made by actual tar and just update ownership 2024-04-19 10:02:37 though i'm not sure if it's doable with tar(1) itself 2024-04-19 10:06:28 im sure it was not possible to do it with tar itslef 10-15 years ago, which is why i went for fakeroot 2024-04-19 10:08:57 tar has --owner-map and --group-map, but nothing for individual files afaik 2024-04-19 10:08:59 hm, there's something like owner-map, but it just maps uids to other uids 2024-04-19 10:10:05 It can run output through a pipe, with owner/group/mode etc. in environment vars. That could be abused for this. 2024-04-19 10:12:52 need to fix fakeroot anyway. there is my focus now 2024-04-19 10:15:31 how do I set the git commit for a git submodule? 2024-04-19 10:15:40 diff --git a/gnulib b/gnulib 2024-04-19 10:15:40 @@ -1 +1 @@ 2024-04-19 10:15:40 +++ b/gnulib 2024-04-19 10:15:40 --- a/gnulib 2024-04-19 10:15:40 index bb5bb43a1..259829e78 160000 2024-04-19 10:15:41 -Subproject commit bb5bb43a1ebb9f502b5ce38c0b8c8778d13b9f6e 2024-04-19 10:15:41 +Subproject commit 259829e78b9e434771388269cd7ff3f55ce74057 2024-04-19 10:16:02 i want revert the submodule to bb5bb43a1ebb9f502b5ce38c0b8c8778d13b9f6e 2024-04-19 10:17:27 git checkout in that dir 2024-04-19 10:17:28 cd $submodule && git checkout $commitid 2024-04-19 10:17:44 sure, but 2024-04-19 10:17:49 ncopa-desktop:~/src/coreutils ((HEAD detached at v9.5))$ make 2024-04-19 10:17:49 make: *** [Makefile:8901: aclocal.m4] Error 1 2024-04-19 10:17:49 aclocal-1.16: error: aclocal: file 'm4/snan.m4' does not exist 2024-04-19 10:17:49 CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/home/ncopa/src/coreutils/build-aux/missing' aclocal-1.16 -I m4 2024-04-19 10:17:50 or git submodule update if you want to match what's in the tree 2024-04-19 10:18:01 so i need to re-run the ./bootstrap 2024-04-19 10:18:11 and guess 3 times what ./bootstrap will do? 2024-04-19 10:18:22 checkout a submodule? 2024-04-19 10:18:28 ./bootstrap: getting gnulib files... 2024-04-19 10:18:28 Submodule path 'gnulib': checked out '259829e78b9e434771388269cd7ff3f55ce74057' 2024-04-19 10:19:09 Then you'd need to commit that change 2024-04-19 10:19:23 aha 2024-04-19 10:19:41 just need to wait for the bootstrap to finish 2024-04-19 10:19:59 it takes a while, even on this i9 with 64G ram 2024-04-19 10:23:56 who would have guessed commiting in coreutils was so difficult 2024-04-19 10:24:07 1 # commit-msg: invalid first word(s) of summary line: #, commit-msg 2024-04-19 10:24:07 3 gnulib: revert to old gnulib 2024-04-19 10:24:07 2 # commit-msg: missing colon on first line of log message 2024-04-19 10:24:15 --no-verify 2024-04-19 10:24:31 and now I'm stuck in vim 2024-04-19 10:24:36 i cannot exit vim 2024-04-19 10:25:03 ZZ? 2024-04-19 10:25:39 brings me back to vim 2024-04-19 10:25:43 ncopa: it's not possible to provide tar with a list of owners+permissions to encode into the archive, but it *would* be possible for abuild to store such a list in a special file alongside the archive and have apk update the archive perms at install time 2024-04-19 10:26:28 of course being able to encode stuff directly into tar would be better, but, fiddling with GNU code again, uh, no 2024-04-19 10:28:06 ncopa: what about :cq 2024-04-19 10:28:12 make vim exit with an error code 2024-04-19 10:30:05 i managed to write a commit message that this dragon would accept 2024-04-19 10:32:40 what a day 2024-04-19 10:32:44 ahuh 2024-04-19 10:32:49 And it's just afternoon 2024-04-19 10:33:10 "Captain, it's noon" 2024-04-19 10:33:30 yeah, was thinking about that 2024-04-19 10:33:32 lol 2024-04-19 10:34:08 https://imgflip.com/i/8nbee1 2024-04-19 10:34:23 LOL 2024-04-19 10:35:20 perfect 2024-04-19 10:36:44 src/basenc.c:1292:17: error: 'isubase64' undeclared (first use in this function); did you mean 'isbase64'? 2024-04-19 10:37:11 i suppose there is a reason they updated gnulib version 2024-04-19 10:43:28 "I sub as e64", okay e64, gimme your number 2024-04-19 10:44:39 lib/exclude.c:39:10: fatal error: mbuiter.h: No such file or directory 2024-04-19 10:45:11 https://github.com/coreutils/gnulib/blob/master/lib/mbuiter.h 2024-04-19 10:46:59 its a deep and dark hole 2024-04-19 10:47:07 lib/mbuiter.h:105:10: fatal error: mbchar.h: No such file or directory 2024-04-19 10:47:20 lib/mbschr.c:23:10: fatal error: mbuiterf.h: No such file or directory 2024-04-19 10:47:41 I'll never understand how people think it's acceptable to ship a project in such a state of unusability 2024-04-19 10:48:12 ncopa: I've imported alpine edge main, import of community is going to start in 12min :) 2024-04-19 10:48:49 kpcyrd: sweet! 2024-04-19 10:49:01 you can now do things like: https://whatsrc.org/diff-sorted/sha256:1e5cc328eee2bd1acff89f860e3179ea24b85df3ac483433f92a29977b14b045/sha512:f98d4a4370954969d0ae16993d80ca5ce48670a711f17445de979513ac9caf2b197291732d937ae07d48709ded660ea09601b3a41ad7c48b3abb87e7a67deb65 2024-04-19 10:49:17 --- is fedora, +++ is alpine 2024-04-19 10:50:23 looks like we are using release tarball and fedora git 2024-04-19 10:50:51 kpcyrd: are you the person behind whatsrc? 2024-04-19 10:51:09 ncopa: yes, if you click on "diff from" and "diff to" you can also see it detected one of them as autotools pre-processed 2024-04-19 10:51:16 kpcyrd: can you see what other distros uses coreutils 9.5? and if there are any diff in the tarballs for coreutils 9.5? 2024-04-19 10:51:23 skarnet: yes 2024-04-19 10:51:47 ncopa: https://whatsrc.org/search?q=coreutils 2024-04-19 10:52:13 ncopa: Alpine, Arch and Fedora all agree on the source code: https://whatsrc.org/artifact/sha256:cd328edeac92f6a665de9f323c93b712af1858bc2e0d88f3f7100469470a1b8a 2024-04-19 10:52:29 kpcyrd: i suspect there is a bug in coreutils 9.5 and now I suspect it is something in gnulib, which is an imported/bundled external project from git submodule 2024-04-19 10:52:39 oh... 2024-04-19 10:52:46 arch uses coreutils 9.5 2024-04-19 10:52:59 does fakeroot testsuite pass on arch linux? 2024-04-19 10:53:18 ncopa: it seems so, yes: https://gitlab.archlinux.org/archlinux/packaging/packages/coreutils/-/blob/main/PKGBUILD?ref_type=heads#L45 2024-04-19 10:53:23 kpcyrd: that's super neat, thanks for this! I have a feature request: when you get vendored sources like Debian _orig.tar.gz files, would it be possible to look in the copyright file to see where the original archive comes from, and display that info? I know that's distro-specific but that would be super helpful :) 2024-04-19 10:53:41 kpcyrd: git bisecting coreutils is a nightmare due to the bundled gnulib code 2024-04-19 10:54:03 i'd say gnulib is a perfect hiding spot for backdoors 2024-04-19 10:54:42 bundled or not, gnulib is ubiquitous and obscure enough to be a good attack target 2024-04-19 10:55:41 skarnet: you're welcome! the codebase is full of distro specific code, you're welcome to open github issues over here: https://github.com/kpcyrd/what-the-src 2024-04-19 10:56:30 is the information of "this .tar.gz was downloaded from this url" available in Debian? 2024-04-19 10:56:41 or is it just some homepage url? 2024-04-19 10:56:41 yes, in the copyright file under debian/ 2024-04-19 10:57:23 idr exactly but it should definitely be there 2024-04-19 10:57:50 skarnet: do you have an example page? https://metadata.ftp-master.debian.org/changelogs//main/h/htop/htop_3.3.0-4_copyright 2024-04-19 10:59:36 what do you mean an example page? 2024-04-19 11:01:16 urldir=`grep ^Source: $pkgname_$pkgversion-$pkgrelease_copyright | cut -d' ' -f2` would probably be enough :) 2024-04-19 11:01:46 (using the alpine variable names here, you get the gist of it) 2024-04-19 11:02:42 ./bootstrap: done. Now you can run './configure'. 2024-04-19 11:02:43 real 4m 5.16s 2024-04-19 11:03:14 im gonna try another git bisect 2024-04-19 11:04:02 config.status: creating po/Makefile 2024-04-19 11:04:02 real 1m 0.53s 2024-04-19 11:04:28 make[1]: Leaving directory '/var/ncopa/src/coreutils' 2024-04-19 11:04:28 real 0m 3.57s 2024-04-19 11:08:56 skarnet: I'd prefer to only use urls if it's a direct download link, or something like git+https://, things that can easily get verified with no human interaction :) 2024-04-19 11:10:11 this kind of info is available from other distros (Alpine or Arch Linux) and can get cross-referenced from there through the hash 2024-04-19 11:11:21 kpcyrd: it is a direct dl link, the tarball is under the given directory 2024-04-19 11:11:49 add the tarball name to $urldir (without the _orig) and you got it 2024-04-19 11:12:32 that's why the Source: line for the htop package has /releases on its github url 2024-04-19 11:16:13 is it possible to have wildcards in replaces=""? 2024-04-19 11:16:39 trying to learn how things work !64489 2024-04-19 11:19:10 Has anyone taken a look at the Debian fakeroot bug tracker to see if maybe there's something related there: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=fakeroot 2024-04-19 11:21:04 cely: i had a quick look at it yesterday, but all those bugs seems old 2024-04-19 11:22:01 How about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031355 ? 2024-04-19 11:22:32 i just realized the order is backwards 2024-04-19 11:22:44 i was looking at the top, which is the old onw 2024-04-19 11:23:06 I mean order is not backwards, when I was expecing it to be backwards 2024-04-19 11:23:24 alos looking at the commits in gnulib 2024-04-19 11:23:31 $ git log --format=oneline bb5bb43a1ebb9f502b5ce38c0b8c8778d13b9f6e..259829e78b9e434771388269cd7ff3f55ce74057 | wc -l 2024-04-19 11:23:31 635 2024-04-19 11:23:37 only 635 commits 2024-04-19 11:24:01 $ git log --format=oneline bb5bb43a1ebb9f502b5ce38c0b8c8778d13b9f6e..259829e78b9e434771388269cd7ff3f55ce74057 | tpaste 2024-04-19 11:24:01 https://tpaste.us/EJe5 2024-04-19 11:59:01 aha! fakeroot fails on arch linux as well 2024-04-19 11:59:52 kpcyrd: do you know if arch linux use tarballs created under fakeroot? 2024-04-19 12:00:38 im pretty sure that fakeroot in arch linux is broken after the coreutils 9.5 update 2024-04-19 12:02:44 https://man.archlinux.org/man/PKGBUILD.5 under the "package() Function": "The packaging stage is run using fakeroot to ensure correct file permissions in the resulting package." 2024-04-19 12:03:46 cely: thank you! im pretty sure that may be broken since coreutils 9.5 2024-04-19 12:08:45 What would be an example Arch package to download to see this bug in action? 2024-04-19 12:20:49 i built fakeroot from git in arch linux after updating coreutils to 9.5 2024-04-19 12:21:22 but the arch ppl are not able to reproduce when building fakeroot package 2024-04-19 12:21:52 Ok.. 2024-04-19 12:22:53 So, how does this affect us? Are packages getting user/group wrong now? 2024-04-19 12:23:03 I think you said packages that have coreutils in the dependency chain 2024-04-19 12:23:20 potentially yes. 2024-04-19 12:23:34 i think it can happen. but i have no proof that it has happened 2024-04-19 12:23:43 ncopa: is there a link to a packge tracking this bug I could share in the arch packaging channel? 2024-04-19 12:24:07 kpcyrd: i asked in #archlinux on libera and they were not able to reproduce 2024-04-19 12:24:15 mhm I see 2024-04-19 12:24:33 cely: this may indicate that it actually happens: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63669 2024-04-19 12:25:00 kpcyrd: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16016 2024-04-19 12:25:07 Ah yes, i think you've mentioned that merge request before 2024-04-19 12:25:09 im preping a dockerfile 2024-04-19 12:28:32 but i don't think coreutils is pulled in as dependency while building alpine-baselayout.. 2024-04-19 12:29:38 true 2024-04-19 12:29:41 god point 2024-04-19 12:30:03 ok I have a reproducer 2024-04-19 12:30:05 in docker 2024-04-19 12:30:18 $ tpaste < Dockerfile 2024-04-19 12:30:18 https://tpaste.us/0lMz 2024-04-19 12:32:39 Did you discover this fakeroot issue while bootstrapping the 3.20 builders? 2024-04-19 12:33:26 yes 2024-04-19 12:33:36 all arches choked on fakeroot test 2024-04-19 12:44:07 i have a new bisect with different result 2024-04-19 12:44:12 new offending commit 2024-04-19 12:44:23 5a1d00e4504204dc4c84eb641abb961e8074a218 mv: treat --exchange more like non-exchange 2024-04-19 12:44:26 this makes more sense 2024-04-19 12:45:08 yes 2024-04-19 12:45:15 renameatu 2024-04-19 12:46:47 havent read everythign but this looks relevant? https://groups.google.com/g/linux.debian.bugs.dist/c/kW96ZXwRDI0 2024-04-19 12:57:37 im gonna celebrate with a frozen pizza. i think things are starting to make sense. we are making progress. 2024-04-19 12:59:47 you're out of icecream? 2024-04-19 13:03:28 lol 2024-04-19 13:27:18 bingo! 2024-04-19 13:27:24 we have a winning commit 2024-04-19 13:27:41 https://github.com/coreutils/coreutils/commit/5a1d00e4504204dc4c84eb641abb961e8074a218 2024-04-19 13:42:48 grats to the winner! 2024-04-19 13:43:07 "rename at you" 2024-04-19 13:46:57 i bet musl does not implement renameat2 and it falls back to use direct syscall, undermining fakeroot, or similar 2024-04-19 13:48:20 checking for renameat2... no 2024-04-19 14:24:25 ncopa: nice find 2024-04-19 14:28:56 yup, grats on the detective work 2024-04-19 14:29:19 good help you you ppl 2024-04-19 14:29:34 and arch linux ppl 2024-04-19 14:29:43 and help from daliaas to figure out how to solve it 2024-04-19 14:29:49 dalias* 2024-04-19 15:47:05 i think we have circular dep in cmake again 2024-04-19 15:47:21 >>> gtest: Analyzing dependencies... 2024-04-19 15:47:21 .makedepends-gtest-20240419.154552: 2024-04-19 15:47:21 ERROR: unable to select packages: 2024-04-19 15:47:21 masked in: cache 2024-04-19 15:47:21 satisfies: world[.makedepends-gtest=20240419.154552] 2024-04-19 15:47:23 cmake (no such package): 2024-04-19 15:47:23 required by: .makedepends-gtest-20240419.154552[cmake] 2024-04-19 15:47:25 >>> ERROR: gtest: builddeps failed 2024-04-19 15:48:16 No recent changes that seem to introduce it 2024-04-19 15:49:14 gtest -> cmake soemthing 2024-04-19 15:50:29 $ ap recursive-deps gtest | tpaste 2024-04-19 15:50:29 https://tpaste.us/qE65 2024-04-19 15:50:44 gtest has gtest-dev higher up in dependency chain 2024-04-19 15:52:30 Could it be due to gmock? 2024-04-19 15:55:03 does not look like 2024-04-19 15:56:05 c-ares needs gtest 2024-04-19 15:59:26 we need a tool to detect circular deps 2024-04-19 16:01:01 ncopa: ptrc made one 2024-04-19 16:01:20 https://gitlab.alpinelinux.org/ptrcnull/apkcircledep 2024-04-19 16:01:42 but it does not detect anything 2024-04-19 16:03:39 so we have a tool for circular deps, but not yet a tool that detects circular deps :) 2024-04-19 16:04:48 it cannot look into subpackage dependencies 2024-04-19 16:04:56 because we still have not defined a way to do so 2024-04-19 16:06:17 i think i found it 2024-04-19 16:07:19 cmake -> nghttp2 -> c-ares -> gtest -> cmake 2024-04-19 16:08:16 It's anoying that gtest needs to be in makedepends 2024-04-19 16:08:30 it is in checkdepends 2024-04-19 16:08:50 makedepends="gtest-dev" 2024-04-19 16:08:53 in c-ares 2024-04-19 16:09:03 oh, ok 2024-04-19 16:10:00 f0462f510d2808a3045e31c4f9c0151d078dae7b 2024-04-19 16:10:14 but, shouldn't both make and checkdepends of dependencies be irrelevant? 2024-04-19 16:10:24 they should 2024-04-19 16:10:35 we run the tests when building so they are both needed at build time 2024-04-19 16:11:21 installing c-ares-dev does not pull in gtest 2024-04-19 16:11:23 gtest-dev 2024-04-19 16:12:19 found it 2024-04-19 16:12:22 0046e0b75eef1997357debf243d4896186be13f7 2024-04-19 16:12:30 that is what introduces it 2024-04-19 16:13:00 But why is gtest even being pulled in? 2024-04-19 16:13:36 If locally I install deps of cmake, I don't see gtest-dev being pulled in 2024-04-19 16:14:21 because it is not a runtime dep 2024-04-19 16:14:25 its a build time dep 2024-04-19 16:14:31 and build time circular dep 2024-04-19 16:14:32 abuild deps 2024-04-19 16:14:35 does not install it 2024-04-19 16:15:02 because it is not needed at runtime by c-ares 2024-04-19 16:15:07 only at build time 2024-04-19 16:15:15 once its built it is no longer a dep 2024-04-19 16:15:54 It's a build-order thing 2024-04-19 16:16:12 which should be built first? 2024-04-19 16:16:17 nod 2024-04-19 16:16:23 understand it now 2024-04-19 16:16:26 cmake -> nghttp2 -> c-ares -> gtest -> cmake 2024-04-19 16:17:21 we have two options: 1. disable tests for c-ares. 2. use bundled nghttp2 for cmake 2024-04-19 16:18:21 3. disable tests only on bootstrap (but then we should run tests later again) 2024-04-19 16:18:46 that means a two pass build 2024-04-19 16:18:51 yup 2024-04-19 16:19:12 i want avoid go there if possible 2024-04-19 16:19:16 curl already does that 2024-04-19 16:19:55 i think that is for crosscompile bootstrap 2024-04-19 16:20:02 ? 2024-04-19 16:20:19 I guess, is that what's setting BOOTSTRAP=1? 2024-04-19 16:20:53 i guess so. i dont know 2024-04-19 16:21:05 how would we know what to rebuild? 2024-04-19 16:21:27 anything that checks for BOOTSTRAP 2024-04-19 16:21:38 in the curl case, ap will pick it up by looking for the missing subpackages 2024-04-19 16:21:50 but I dont want to go there if possible 2024-04-19 16:22:22 completely disabling tests also does not sound like a good idea 2024-04-19 16:22:34 once we make that convenient for upstream will end up rebuilding the world twice for every single package 2024-04-19 16:23:14 and its a bit complicated 2024-04-19 16:23:25 lets say we do it, for c-ares 2024-04-19 16:23:59 then there is an update for c-ares. it has option="2pass-build" 2024-04-19 16:24:04 should it build once or twice? 2024-04-19 16:24:26 it depends 2024-04-19 16:25:13 if cmake or gtest or nghttp2 is in the same build job, it may need to. if they are not, it may be enough with a single build 2024-04-19 16:25:43 if all the dependencies in the dep circle are there, we may not need build it twice 2024-04-19 16:26:07 but what if we have a rebuild due to an ABI breakage? 2024-04-19 16:26:21 shouldn't this only matter at bootstrap? 2024-04-19 16:26:39 what if you push an ABI breaking change? 2024-04-19 16:27:21 we actually have that exact problem for gcc and isl or gmp 2024-04-19 16:27:51 I guess then we get what happened in libxml, which was rebuilt before python? 2024-04-19 16:27:54 aren't toolchains at the very bottom of a bootstrap list? 2024-04-19 16:27:54 if you bump isl to new ABI version, you may end up breaking gcc 2024-04-19 16:28:05 yes 2024-04-19 16:28:07 and yes 2024-04-19 16:28:08 or top, depending on how you see it 2024-04-19 16:28:45 the bottom line (or top line depending on how you see it) is: circular deps makes everything complicated 2024-04-19 16:29:01 yes, they always do 2024-04-19 16:29:02 imho you should make the package building toolchain in a completely independent circuit 2024-04-19 16:29:15 sure. in this case it is not toolchain 2024-04-19 16:29:26 it is c-ares 2024-04-19 16:29:35 well it is package toolchain. cmake 2024-04-19 16:29:56 cmake and c-ares suck, for different reasons :/ 2024-04-19 16:30:08 but it becoming pretty popular to introduce cirular deps nowadays 2024-04-19 16:30:12 python libxml did it 2024-04-19 16:30:20 cmake does it all the time 2024-04-19 16:30:26 yeah I never understood why people think it's a good idea 2024-04-19 16:30:29 glib did it 2024-04-19 16:30:43 skarnet: I think they don't even think 2024-04-19 16:30:46 because it is convenient for them 2024-04-19 16:30:55 solving it is other peoples problem 2024-04-19 16:31:08 its convenient to use cmake, meson 2024-04-19 16:31:11 "What's the issue, you can just download these pre-compiled binaries" 2024-04-19 16:31:25 or more like 2024-04-19 16:31:34 well exactly that 2024-04-19 16:31:35 ikke: idk, langdev people love being self-hosted, for Very Smart independence reasons or whatever 2024-04-19 16:31:49 why depend on another language when we can provide bootstrap binaries 2024-04-19 16:31:51 they like their language, so they want the compiler in their language 2024-04-19 16:31:53 they usually have shorter circle 2024-04-19 16:32:13 in this case it is c-ares who want to use gtest for their tests 2024-04-19 16:32:20 ikke: of course, but the compiler needs to be bootstrapped one way or another 2024-04-19 16:32:50 perl does it right with miniperl 2024-04-19 16:34:01 problem is not when a language wants to build itself. they are usually aware of it and have a bootstrap path 2024-04-19 16:34:39 problem is when projects introduces new deps and without know introduce circular dep, or does not care 2024-04-19 16:34:49 yeah, two different classes of problems 2024-04-19 16:35:12 and I agree the latter is harder to solve 2024-04-19 16:35:30 gtest: "i want use cmake." "No dont! it introduces a cirular dep!" gtest: "maybe for you, but not for me" 2024-04-19 16:35:48 repeat with c-ares and nghttp2 2024-04-19 16:35:51 big "I'm not gay but my boyfriend is" energy 2024-04-19 16:36:01 :) 2024-04-19 16:36:08 well 2024-04-19 16:36:15 atleast cmake has a solution for it 2024-04-19 16:36:23 they bundle all their deps 2024-04-19 16:36:26 problem solved 2024-04-19 16:36:49 bundle all the things 2024-04-19 16:37:03 in the cmake case i think it makes sense 2024-04-19 16:37:19 then can all their deps use cmake as they want 2024-04-19 16:39:19 can't have a bootstrap problem if you vendor the whole world 2024-04-19 16:55:53 it's genius 2024-04-19 16:56:31 want to see some incredible vendoring? https://source.chromium.org/chromium/chromium/src/+/main:third_party/angle/third_party/dawn/third_party/angle/third_party/dawn/third_party/angle/third_party/dawn/third_party/angle/ look at this 2024-04-19 16:56:40 mutually recursive vendoring :D 2024-04-19 16:56:45 lol 2024-04-19 16:56:59 how does the cycle break? 2024-04-19 16:57:08 I'm actually unsure 2024-04-19 16:57:30 maybe one of them is secretly a symlink back to the root 2024-04-19 16:58:32 LOL 2024-04-19 16:59:23 I think it's called mutual assured vendoring 2024-04-19 17:00:57 you can't vendor me if I vendor you first 2024-04-19 17:01:22 i can't? hold my beer... 2024-04-19 17:01:34 haha 2024-04-19 17:01:42 thats crazy 2024-04-19 17:02:06 I was trying to get a program that builds with bazel to work on alpine recently and I knew I was entering the shadow realm when I ran bazel and it proceeded to download a full copy of glibc and gcc 2024-04-19 17:02:23 it downloaded like, 2GB of binaries in order to build something 2024-04-19 17:02:24 elly: may I steal that chromium link? 2024-04-19 17:02:28 sure, go for it 2024-04-19 17:03:01 ha, at least it didnt download qmeu binary and installed windows on it 2024-04-19 17:03:29 I really do not like bazel 2024-04-19 17:19:07 oh no 2024-04-19 17:19:35 seems like the entire world is in the dependency chain to abuild 2024-04-19 17:20:27 clang llvm cairo cython font-liberation vala rust 2024-04-19 17:20:31 https://git.savannah.gnu.org/cgit/gnulib.git 2024-04-19 17:20:51 ncopa: oof 2024-04-19 17:20:53 hi vkrishn! hi killed that dragon today 2024-04-19 17:21:01 ok 2024-04-19 17:21:31 ncopa: so at the point you can finally start using abuild, you no longer need it? :D 2024-04-19 17:21:41 exactly 2024-04-19 17:23:21 i think its maybe git? 2024-04-19 17:25:38 i think I'm gonna do the bootstrap dance 2024-04-19 17:25:45 the twopass bootstrap dance 2024-04-19 17:29:57 do we call it APORTS_BOOTSTRAP or ABUILD_BOOTSTRAP 2024-04-19 17:30:21 some tools will be built without docs and or reduced number of subpackages 2024-04-19 17:30:58 ABUILD_BOOSTRAP disables tests 2024-04-19 17:31:09 So APORTS_BOOTSTRAP 2024-04-19 17:32:24 I suspect ABUILD_BOOTSTRAP was designed for this? 2024-04-19 17:32:42 do we actually use it anywhere nowadays? 2024-04-19 17:33:15 https://gitlab.alpinelinux.org/alpine/abuild/-/commit/834cb718f62879ea5e68342ff81e66fb7c9f760d 2024-04-19 17:33:20 ncopa: we used it for rv64 2024-04-19 17:33:43 but no longer 2024-04-19 17:34:18 alright. lets rename it to ABUILD_NOCHECK? 2024-04-19 17:34:41 or maybe i just use APORTS_BOOTSTRAP 2024-04-19 17:34:42 What if others are using it? 2024-04-19 17:34:53 yeah 2024-04-19 17:35:12 And it makes sense, we are bootstrapping aports, not abuild 2024-04-19 17:35:33 well, maybe in this case we are 2024-04-19 17:35:40 well, technically I'm bootstrapping abuild 2024-04-19 17:48:09 im adding APORTS_BOOTSTRAP. the rules will be that you must build with reduced set of subpackages, so it gets rebuilt after aports is bootstrapped 2024-04-19 17:48:17 otherwise there is no way to trigger a rebuild 2024-04-19 17:50:19 sounds reasonable 2024-04-19 18:04:22 ncopa-desktop:~/aports/main (master)$ ap recursive-deps abuild | wc -l 2024-04-19 18:04:22 ncopa-desktop:~/aports/main (master)$ APORTS_BOOTSTRAP=1 ap recursive-deps abuild | wc -l 2024-04-19 18:04:22 173 2024-04-19 18:04:22 301 2024-04-19 18:04:33 almost half deps 2024-04-19 18:05:27 ! 2024-04-19 18:05:38 ‼️ 2024-04-19 18:06:37 i can reduce it more in cmake, but cmake is already built i think 2024-04-19 18:07:04 is that like the number of packages needed to assemble rootbld 2024-04-19 18:07:46 i think so 2024-04-19 18:07:52 that's so many 2024-04-19 18:07:53 i wonder how much i have 2024-04-19 18:08:06 q66@chimera: /home/q66/cports$ ./cbuild print-build-graph main/base-cbuild|wc -l 2024-04-19 18:08:08 110 2024-04-19 18:08:09 hah 2024-04-19 18:08:09 i win 2024-04-19 18:08:44 base-cbuild includes the tool to build .apk? 2024-04-19 18:09:05 it's the package that is installed to assemble the container in which everything happens 2024-04-19 18:11:21 the graph does not include everything installed in it 2024-04-19 18:11:32 but includes everything that is built from scratch with empty repo 2024-04-19 18:11:33 https://gist.github.com/q66/4633b36cd4f694e5fc59911a1bb82f9e 2024-04-19 18:13:14 ncopa: are you trying to reduce deps of abuild? or make it easier to bootstrap a new system? 2024-04-19 18:13:47 making it easier to bet the alpine builders up 2024-04-19 18:13:53 get* 2024-04-19 18:13:55 ahh 2024-04-19 18:14:13 once thye are up, they will rebuild a nahdfule packages with more deps 2024-04-19 18:14:26 * a handful of packages 2024-04-19 18:14:31 i cant type anymore 2024-04-19 18:15:29 one of those days i will eliminate ncurses 2024-04-19 18:15:42 sounds like a good plan 2024-04-19 18:16:00 is ncurses in the build dependencies? 2024-04-19 18:16:04 er abuild dependencies 2024-04-19 18:16:12 presumably yes 2024-04-19 18:16:15 pretty sure it is 2024-04-19 18:16:24 i don't see how it wouldn't be 2024-04-19 18:16:38 it's pretty difficult to build any system without ncurses 2024-04-19 18:17:37 I wonder what uses it in that dependency set 2024-04-19 18:17:39 i'd try bringing up netbsd-curses on linux properly but i'd have to plumb in a mouse implemnetation and a less cursed terminfo database (i.e. ncurses-compatible that is not just a single binary file) or i wouldn't be happy 2024-04-19 18:39:36 ncopa: heh, using -dbg as a trigger to rebuild 2024-04-19 18:39:49 ;) 2024-04-19 18:40:43 util-linux is broken though 2024-04-19 19:21:30 i don tknow whats wrong with util linux but i need to take weekdn. i was hoping to get the builders up before weekend but I have to give up 2024-04-19 19:21:52 it simply fails with APORTS_BOOTSTRAP=1 abuild -r 2024-04-19 19:22:03 something with parallel builds? 2024-04-19 19:22:20 seems like something deletes tools/all_syscalls when running in parallel 2024-04-19 19:22:27 Please do take the weekend off, you deserve it. The builders can wait until monday 2024-04-19 19:23:15 we also need patch abuild to pass APORTS_BOOTSTRAP to the recursive abuild call 2024-04-19 19:24:08 for rootbld? 2024-04-19 19:24:22 yes 2024-04-19 19:24:47 yes, please don't overload yourself. :) 2024-04-19 20:27:28 What's wrong with util-linux now? I thought we fixed it. 2024-04-19 20:29:34 xulfer: ncopa tried to adjust the APKBUILD to require less dependencies at bootstrap time 2024-04-19 22:12:43 i figured it out. it was a real bash dependency 2024-04-19 22:12:53 sometimes a break makes wonders 2024-04-19 22:12:58 good night 2024-04-20 01:09:52 take uninterrupted weekend off, then make more wonders 2024-04-20 05:25:29 ncopa: If I need a patch to the Linux kernel in order for some hardware to work properly, would it be accepted to submit a MR to the package linux-lts or do I need to build a custom kernel myself each time there is an update? The patch in question is this one: https://github.com/tuxedocomputers/linux/commit/9c7dc5a139550426a03b99b1d2c935a959f4c4bf 2024-04-20 07:17:22 EvTheFuture: its perhaps good to submit it upstream and see if it is accepted and maybe then request a backport to stable kernels 2024-04-20 07:48:28 EvTheFuture: we try to avoid those custom patch. getting it upstream is absolutetly the best way. backporting to alpine kernel is ok too 2024-04-20 07:49:23 once we introduce a patch for hardware its difficult to get rid of it (unless it is upstream) 2024-04-20 07:51:43 i pushed boost 1.84. this is the list that needs to be rebuild in case someone wants to help: https://tpaste.us/YYy4 2024-04-20 08:20:31 3.20 builders are up 2024-04-20 10:02:03 I'll see how many I can get through 2024-04-20 11:09:33 @ncopa: I nuderstand. I'll start by talking to the manufacturer and check what their plans are. 2024-04-20 11:46:42 @ncopa: How can I help with the list? I mean, what shall be done? 2024-04-20 12:46:42 It seems the 3.20 aarch64 builder is set up to use distfiles.a.o/edge 2024-04-20 12:47:21 Resulting in things like https://build.alpinelinux.org/buildlogs/build-3-20-aarch64/main/icu/icu-74.2-r0.log 2024-04-20 12:49:06 I think the checksum was amended without renaming the file 2024-04-20 12:49:22 (and very likely, pkgrel was also not bumped) 2024-04-20 12:51:08 I compared the two files, and it seems the earlier file (the one on distfiles.a.o/edge) has a broken symlink for LICENSE, and that was fixed in the reuploaded file 2024-04-20 12:52:25 Usually, we would just rename the file, but as i noticed it is using distfiles.a.o/edge, i thought of asking first 2024-04-20 12:52:29 Hey all. FYI, I’m working on bringing DisplayLinkManager and hence evdi to Alpine. Hope that’s okay. So far it’s an interesting battle. I’ll be documenting my steps as I go. So even if this can’t be added to aports, someone will find it useful. 2024-04-20 14:16:10 Anything else I should do about !63886? 2024-04-20 14:16:38 Also, a small patch to check() !64402 2024-04-20 14:20:26 Also, I kind of messed up by making my first MR on master branch, but I hope you can merge it so I can use master branch in the local repo freely 2024-04-20 14:22:47 It is difficult to merge an MR with master as source 2024-04-20 14:22:51 Are you able to rebase it? 2024-04-20 14:23:48 As far as i know, master is protected by default, and you cannot rebase it 2024-04-20 14:26:02 I have a separate remote with alpine's repo url 2024-04-20 14:26:25 so I do `git fetch upstream` and `git rebase upstream/master` whiled checked out on master 2024-04-20 14:26:45 Can you then push what you have rebased? 2024-04-20 14:27:00 Ok, one moment 2024-04-20 14:31:19 rebased 2024-04-20 14:32:16 on MR 64402 too 2024-04-20 14:35:50 My internet connection is absolutely terrible today, but i tried to merge the wine MR, and it won't go through 2024-04-20 14:35:55 Please try rebasing again 2024-04-20 14:36:22 That's the problem with MRs made from master, we can't rebase it for you 2024-04-20 14:37:44 Hmm, there were some commits 11 minutes ago, that's the problem 2024-04-20 14:38:03 Or not? 2024-04-20 14:38:43 Yes, however we are able to rebase MRs made from branches other than master, which Gitlab protects by default 2024-04-20 14:39:24 I see, that was quite dumb of me to make a MR on master branch 2024-04-20 14:39:44 Rebased. again 2024-04-20 14:39:57 Maybe you can try unprotecting your master branch, but i am unable to give you the exact instructions to do that as Gitlab is very slow for me today 2024-04-20 14:39:59 Nope nvm 2024-04-20 14:40:23 Okay rebased now for sure 2024-04-20 14:45:02 I am still unable to merge it, sorry, maybe someone with higher privileges can override the protection for master and merge it, but we are pretty busy now that the builders for 3.20 are online. 2024-04-20 14:46:29 Damn, well, I'll unprotect it for now 2024-04-20 14:46:46 So merge it whenever you have time 2024-04-20 15:05:51 ty 2024-04-20 15:25:03 how long do new aports generally sit in testing? 2024-04-20 15:28:22 If you are asking about your own aport, then you may move it to community once you feel that it is stable enough (other criteria include, having tests enabled, and being enable for all architectures supported by upstream) 2024-04-20 15:28:53 If you are asking about an aport maintained by someone else, then you will have to ask the maintainer 2024-04-20 15:31:57 it's a new one I wrote for valkey 2024-04-20 15:32:28 Additionally, with the move to community, you are also indicating that you are able to support it with bug and security fixes for half a year (the duration of 1 Alpine stable release) 2024-04-20 15:32:56 Moving to main means supporting it for 2 years (4 Alpine stable releases) 2024-04-20 15:33:55 rgr 2024-04-20 15:40:34 what if we just disable the tests for botan & botan3 on riscv64? 2024-04-20 15:45:21 tests are disabled on other architectures 2024-04-20 16:21:10 I think at this point the people interested in riscv64 would be fine with disabling anything that needs to be disabled to get riscv64 into 3.20 2024-04-20 16:21:59 getting a stable release with riscv64 is holding up a bunch of other stuff (some k8s images, etc) 2024-04-20 16:46:30 If anyone could glipse at !64135 would be fantastic, so I have time to adjust it if needed :) 2024-04-21 00:05:00 Well, i think i've found another issue, https://build.alpinelinux.org/buildlogs/ 2024-04-21 00:05:34 There doesn't seem to be directories for build-3-20-armhf and build-3-20-riscv64 2024-04-21 07:25:33 Hi, https://gitlab.alpinelinux.org/donoban/aports/-/jobs/1354314#L3970 is probably due OOM? Other archs are fine. Is there some simple workaround for this? 2024-04-21 07:27:32 you can try to reduce concurrency 2024-04-21 07:32:09 uhm, it has some flags on linker 2024-04-21 07:32:13 LDFLAGS="$LDFLAGS -Wl,-z,stack-size=1024768" \ 2024-04-21 07:32:58 Those are linker flags, it did not get to linking yet 2024-04-21 07:35:41 wops rigth, so something like EvTheFuture LDFLAGS="$LDFLAGS -Wl,-z,stack-size=1024768" \ 2024-04-21 07:35:44 ups 2024-04-21 07:35:56 export MAKEFLAGS="$MAKEFLAGS -j$((JOBS<16 ? JOBS : 16))" 2024-04-21 07:36:12 how much jobs use aarch64 CI? 2024-04-21 07:36:25 donoban: as much as there are cores 2024-04-21 07:36:30 which you see at the start of the CI job 2024-04-21 07:37:02 oh yeah thanks 2024-04-21 07:37:07 so let's try with 16 2024-04-21 07:39:26 got lint-warning in #64578 :( 2024-04-21 07:39:45 oh, it is !64578 2024-04-21 07:41:17 qaqland: You can ignore this one 2024-04-21 07:44:55 got it, thank you :) 2024-04-21 07:48:06 ncopa: after seeing the list of aports affected (https://tpaste.us/5Xy9 posted by ptrc), i think /var/run should be removed from FHS checks, at least for now. it seems @sertonix (commenting on abuild!281) also doesn't object to this change 2024-04-21 07:53:25 ikke: great -> Job succeeded 2024-04-21 08:03:11 I think I'm for adding options="!fhs" instead so that we can keep track of and fix packages that create directories under /run or /var/run, because they should not be expected to survive a reboot 2024-04-21 08:05:19 Now everyone using docker needs to figure out what directories are expected to exist and manually create them 2024-04-21 08:09:34 always was the case already 2024-04-21 08:10:57 There're a few other new directories in the FHS check besides just /run and /var/run 2024-04-21 08:12:14 Since we already have a list of aports with /var/run, why not allow that, at least for 3.20; which means 3.20 would catch all the other new directories 2024-04-21 08:12:39 would still* 2024-04-21 08:14:14 I mean that they should be amended to also create the directories by other means, to work on systems where /var/run is a tmpfs or cleared at reboot by other means 2024-04-21 08:15:13 and we now have a way to keep track of for what aports we need to do this, even if hacky 2024-04-21 08:16:28 Ok 2024-04-21 08:20:43 Anyway, the check also catches a few other directories besides /var/run, it's just that, so far, /var/run seems to be the most common 2024-04-21 08:30:08 Is there any policy in regard to debug subpackages? Like when to add, whether or not to add -g1? 2024-04-21 08:32:33 maribu: adding a -dbg subpackage automatically sets -g1. Because debug packages tend to use a lot of space, we enable them on a case-by-case bases (and disable it when no longer necessary) 2024-04-21 08:35:47 Thx. I was unaware that -g1 is done automatically. Good to know :) 2024-04-21 08:38:03 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L2972 2024-04-21 08:38:11 it's just -g, not -g1 2024-04-21 08:40:32 ok im reverting the /var/run check. thanks! 2024-04-21 08:49:37 perhaps the fhs check should only warn, but then it may be missed because pipelines are 9✓green 2024-04-21 09:56:45 Omni: yes, I think that makes sense 2024-04-21 10:20:52 When should I move a package from testing to community? After testing or something else? 2024-04-21 10:22:20 NekoCWD[m]: Yeah, when you or someone else confirmed the package is working properly 2024-04-21 10:23:12 ikke: Thanks 2024-04-21 10:47:38 btw, which home path should i set for service-user 2024-04-21 10:51:09 In most cases, none are explicitly set 2024-04-21 10:51:20 which means it will have the default value, but it's not created 2024-04-21 11:03:45 ncopa: !64571 or clear the cached distfiles for icu 74.2? 2024-04-21 11:16:46 it's /me, the nitpicker, what do you think about "enable check()" or "add check()" vs "enable tests" in commit messages? 2024-04-21 11:37:02 omni: probably same thing as in my case: a maintainer suggested to change commit message from "add provides=wine" to "provide wine" 2024-04-21 11:37:10 ikke: would it make sense to also add -g1 automatically? The downside of it is that inspecting variables from GDB won't work with -g1, but it is good enough for a backtrace to report unpstream. 2024-04-21 11:37:16 Reason being it focuses more on the change than on code 2024-04-21 11:38:12 The message should focus on the goal rather than the means 2024-04-21 11:38:27 There also is CTF as an alternative to DWARF, which claims to be a lot smaller. Support in GNU tools was announced in 2019: https://lwn.net/Articles/795384/ 2024-04-21 11:39:04 I also want commit messages doing similar changes be as similar as possible 2024-04-21 12:08:52 ikke: I took a look in the case of testing/gmsh, which is 22.4 MB in size (main package). The -dbg subpackage ends up 415.4 MB in size with -g, 70.8 MB with -g1, 2.9 MB with -gctf2 and also 2.9 MB with -gctf1. 2024-04-21 12:11:53 So: There is an immense potential to shrink the -dbg package. There are indeed features lost. If I would intent to actually fix a package myself, I would definitly want the -g, so that I can do inspection of the program state from GDB. For backtraces, -g1 and -gctf1 should be enough (but given that -gctf2 seems to add little in size, adding the type info seem to come almost for free). 2024-04-21 13:00:04 mangohud has packaging problems 2024-04-21 13:00:19 upstream does this: sed -i 's:/usr/\\$LIB:/usr/lib/mangohud/\\$LIB:g' "$PWD/build/release/usr/bin/mangohud" 2024-04-21 13:00:34 And APKBUILD is missing that, which leaves \$LIB in the script 2024-04-21 13:01:10 Wonder why they don't use the build system for that 2024-04-21 13:01:30 Dunno, but that part in in build.sh 2024-04-21 13:01:36 is in* 2024-04-21 13:05:10 what does this mean exactly? https://gitlab.alpinelinux.org/witcher/aports/-/jobs/1355205#L58 only happens for riscv as well 2024-04-21 13:05:29 Habbie: I disabled a test in pdns and pdns-recursor and allowed for tests in the latter to fail as the failing syncres_ccX tests are numerous !64579 !64582 for the builders to move on and catch up 2024-04-21 13:07:28 I don't know what made these tests start to fail 2024-04-21 13:08:02 doesn't seem to have been boost1.84 since I also tried with 1.82 2024-04-21 14:01:45 omni, i saw the email, thanks. I'll have a look, one of those tests seemed important ;) 2024-04-21 14:09:57 I recently introduced testing/py3-git-versioner and testing/py3-pip-system-certs because the former is a dependency for building the latter, and the latter is a runtime dependency for testing/anki-24.04. 2024-04-21 14:10:57 Now there is a new version of anki-24.04.1 that no longer needs py3-pip-system-certs. So I don't have any use for the two packages above. 2024-04-21 14:11:26 Should I create a MR to remove those? 2024-04-21 14:17:53 fraolt: something else may depend on them, or rather the packages being in the ecosystem may be a contribution in and of itself outside of Anki. Are you just not interested in maintaining them if they aren't part of Anki's deps? 2024-04-21 14:20:46 There are no packages in master depending on them. I'm okay with maintaining them but there's probably not much interest in those packages, so we might as well drop them. 2024-04-21 14:31:35 For the life of me, I cannot understand why re-running rootpkg fails with this error 2024-04-21 14:31:37 mv: can't rename '/media/Stuff/git/aports/community/mangohud/pkg/mangohud/usr/share/doc': Directory not empty 2024-04-21 14:32:22 Why does mv fail? Why does it need to be empty? Isn't the whole point of renaming is to move contents with it? 2024-04-21 14:36:46 lassebq: it's the target directory that is not empty 2024-04-21 14:38:25 Oh. Is it expected for all packages with -doc? 2024-04-21 14:39:26 rm -rf pkg/ and it should work 2024-04-21 14:40:15 thanks, it works 2024-04-21 17:02:24 Habbie: yes, I'm a bit worried something may actually be broken now 2024-04-21 17:02:49 but most tests are successful! 2024-04-21 21:49:56 re: the boost 1.84 upgrade, it seems all subpackages now depend on boost1.84-libs so that installing one of them pulls in all the others too, which might not be intentional? 2024-04-21 21:50:18 example: https://pkgs.alpinelinux.org/package/edge/main/x86_64/boost1.84-date_time 2024-04-21 23:41:14 it does look odd 2024-04-21 23:41:51 https://pkgs.alpinelinux.org/package/edge/main/x86_64/boost1.82-libs > Required by (2) 2024-04-21 23:42:11 https://pkgs.alpinelinux.org/package/edge/main/x86_64/boost1.84-libs > Required by (35) 2024-04-21 23:47:08 33bcec9e7b4372044cd0d75bef288f97b295a426 2024-04-22 00:04:25 Shouldn't we be able to just remove boost1.82 in that case since the boost1.84 package advertises to provide it? At least if memory serves. 2024-04-22 00:09:35 Oops, looks like @jirutka merged his valkey MR first, probably without noticing the earlier !64554 2024-04-22 00:15:34 celie: Isn't that one of the conflicting forks? *checks* 2024-04-22 00:16:19 Valkey is a fork of Redis, not sure what conflicting refers to 2024-04-22 00:16:54 also using the name redis which can cause things to link to it thinking it is redis. When it has no promises of being api/abi compatible with redis. 2024-04-22 00:17:12 Ah, ok 2024-04-22 00:20:42 Silly meson,cmake,etc finding a redis soname and thinking it's redis heh 2024-04-22 03:54:46 there isn't a library installed with valkey? 2024-04-22 06:25:18 morning! di dI break the world with boost? 2024-04-22 06:48:00 yeah, i did. 2024-04-22 06:55:12 im working on a fix 2024-04-22 06:56:37 maybe the lazy !64625 wasn't it 2024-04-22 06:57:17 since it just reverted the change and kept using $origsubpackages 2024-04-22 06:58:32 yeah, but I think it would be a nice thing to remove the origsubpackage. it is only used once 2024-04-22 06:59:10 omni: the icu upgrade, did you test locally if it builds? 2024-04-22 06:59:18 i'd love to have tha change in asap 2024-04-22 07:00:19 the icu upgrade itself built, but I didn't let the rebuilds with it run on CI and haven't tried locally, no 2024-04-22 07:00:35 but I don't want to do it if it introduces hard-to-solve problems 2024-04-22 07:00:44 ok. last time i had problems with libreoffice 2024-04-22 07:00:52 and no real support from upstream 2024-04-22 07:00:59 even for upstream it was hard to solve 2024-04-22 07:01:15 I understand 2024-04-22 07:01:32 i think we should at least try build all the 128 packages 2024-04-22 07:01:51 my hands are full right now 2024-04-22 07:02:06 I opened it since I didn't know what to do about the icu build on 3.20 anyways, some checksum issues, and since it was going to be rebuilt anyways 2024-04-22 07:02:23 yeah, understand. and i agree 2024-04-22 07:02:28 woudl be nice to have it in 2024-04-22 07:02:35 sooner than later 2024-04-22 07:02:59 just slightly risky now that there are so many other things in the air at the same time 2024-04-22 07:04:10 omni, i saw you mention that the pdns failures reproduce on boost 1.82; i also have confirmation that our stuff works fine with 1.84 on freebsd 2024-04-22 07:04:20 omni, so indeed it might be something else 2024-04-22 07:05:37 omni, oh - that user doesn't use the dnssec bits. anyway, i'll find out :) 2024-04-22 07:08:32 I also mentioned it because I wanted to say "I wouldn't say break the world" wrt the boost upgrade =) 2024-04-22 07:09:29 because I don't think things stopped working with the unintentinally introduced dependencies 2024-04-22 07:11:33 to reproduce, i would get aports master, remove your test-removal patch, and do abuild -r? 2024-04-22 07:21:09 omni: What about the icu checksum issues? 2024-04-22 07:21:57 I mean, upstream released a new tarball for that version 2024-04-22 07:22:43 From what i could see when i looked into, the only change is to put the correct LICENSE back into the tarball 2024-04-22 07:23:36 The previous version had a broken symlink for LICENSE 2024-04-22 07:26:10 some icu 74.2 build log for 3.20 I looked at showed at least one checksum mismatch for the cached tarball(s) but I don't see that in https://build.alpinelinux.org/buildlogs/build-3-20-x86_64/main/icu/icu-74.2-r0.log 2024-04-22 07:26:18 so it's sorted now? 2024-04-22 07:26:42 If the archs were it was failing before, have now switched to distfiles.a.o/v3.20 then it should be solved 2024-04-22 07:26:49 s/were/where/ 2024-04-22 07:28:55 The checksum was updated to the new tarball with correct LICENSE, but pkgrel was not bumped 2024-04-22 07:29:37 So, we never found out until now that the file was not renamed together with the checksum change 2024-04-22 07:30:21 distfiles.a.o/edge has the old file, so the 3.20 builders that use that have a checksum mismatch 2024-04-22 07:30:36 ok 2024-04-22 07:31:37 Anyway, it seems the 3.20 builders for aarch64, armhf, and x86 are stuck 2024-04-22 07:32:41 Habbie: I have resource constraints locally so I mostly use the gitlab CI 2024-04-22 07:33:07 It's building some Python and Perl modules so shouldn't take that long 2024-04-22 07:33:09 but yeah, removing the patch should allow you to reproduce it 2024-04-22 07:35:55 It also seems the 3.20 builders are still using abuild 3.13.0-r2 (which disallows /var/run) 2024-04-22 07:49:01 \o/ llvm14 is gone \o/ 2024-04-22 07:49:10 im so happy \o/ 2024-04-22 07:51:56 \o/ 2024-04-22 07:54:12 checking for /include/openssl/ecdsa.h... no 2024-04-22 07:54:14 well that explains things 2024-04-22 07:58:59 pkg-config libcrypto --variable=prefix 2024-04-22 07:59:01 3.19: /usr 2024-04-22 07:59:04 edge: [nothing] 2024-04-22 08:00:26 so i'm guessing the openssl bump from 3.1 to 3.3 'broke' this 2024-04-22 08:00:28 bbl 2024-04-22 08:03:04 alpine/aports$ rg llvm14 | wc -l 2024-04-22 08:03:07 16 2024-04-22 08:03:52 scripts/bootstrap.sh and some haskell aports 2024-04-22 08:04:35 and main/llvm1?/install-prefix.patch 2024-04-22 08:08:52 they will be dragged out the window with llvm14 unless unless they lose any ties to llvm14 2024-04-22 08:12:46 ghc was built with llvm15 with the 9.8.2 upgrade b057ba90f2220987f0d26a4a933f522c4dab3903 2024-04-22 08:13:35 the haskel aports are only setting the PATH, right? do they still build? do we need to update the path? can we remove the PATH line? 2024-04-22 08:16:58 dunno, trying to see if I can figure it out 2024-04-22 08:19:09 for community/alex it was added with d3a77b49d9ec162941d27ebf12e402fbbdba7cca 2024-04-22 08:26:26 Hi, i experience a boost dependency issue: 2024-04-22 08:26:33 https://paste.gnome.org/x2eCaXGzz 2024-04-22 08:34:30 yeah, same here 2024-04-22 08:34:43 thats why i asked if I had broken the world with boost 2024-04-22 08:34:49 I think they're just lagging 2024-04-22 08:35:03 no, i think inkscape needs rebuild 2024-04-22 08:35:06 among others 2024-04-22 08:35:14 im working on incskape now 2024-04-22 08:35:18 ok 2024-04-22 08:35:34 I don't think aports in testing are rebuilt against boost1.84 yet 2024-04-22 08:36:46 oh, right, I looked at the wrong ones 2024-04-22 08:37:28 there are a bunch of pacakges in community that needs rebuild still 2024-04-22 08:38:06 but you're just doing inkscape now? 2024-04-22 08:38:21 yes 2024-04-22 08:44:39 thanks 👍 2024-04-22 09:02:14 !64639 2024-04-22 09:06:46 thanks all :) 2024-04-22 09:09:05 I'll open one for testing/* a bit later 2024-04-22 10:21:42 omni: so you know if py3-scipy/chaospy was fixed? 2024-04-22 10:59:30 can the go font family MR 62729 be merged? it had been marked as stale despite no aports maintainer noticing it 2024-04-22 11:00:03 !62729 2024-04-22 11:02:12 sewn: left one fix 2024-04-22 11:02:35 oh woops sorry 2024-04-22 11:02:40 No worry 2024-04-22 12:05:42 ncopa: I don't 2024-04-22 12:05:47 know 2024-04-22 12:06:28 and I've been distracted by other things 2024-04-22 12:07:10 haven't followed up on !64489 either, recommendations welcome 2024-04-22 12:07:53 would sertonix suggestion there work? 2024-04-22 12:09:10 Been a little while since I needed to update one of the packages I maintain. I'm now finding that dabuild is complaining that it can't find any of the dependencies of my package (these include python3!) 2024-04-22 12:09:18 Has something changed in dabuild that mean I need to update it? 2024-04-22 12:10:59 https://termbin.com/x5sj 2024-04-22 12:11:37 That's the output of dabuild -rf 2024-04-22 14:05:39 It builds fine if I use the ci tools, but they require me to have done the git commit first. No big deal, but I've always been in the habit of using dabuild to get the package 'right', then using the CI stuff as a final check. 2024-04-22 14:29:52 I didn't look at why these failed https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/64639#note_397711 some or all of them may need to be rebuilt as well 2024-04-22 14:36:58 hi all! wrote a few days ago to the manainers of RPI Imager, the software for writing SD cards for Raspberry Pi mini computers, about adding Alpine to their list of distros offered to their users for the PIs.They're opened to accept Alpine, but someone from Alpine team should maintain the integration... If you're interesed, here is the git ticket I opened: https://github.com/raspberrypi/rpi-imager/issues/850#issuecomment-20689 2024-04-22 14:36:58 81935 2024-04-22 15:14:55 I'm a bit worried that the openssl 3.3 upgrade broke more aports than just pdns* but I don't know 2024-04-22 15:17:43 I recall mostly tests that fail because new fields in certs are returned now 2024-04-22 15:22:57 https://github.com/PowerDNS/pdns/issues/14084 2024-04-22 16:25:32 anyone having connection issues for rust apps with rootbld? added the net option, removed frozen but nothing rust builds (e.g. bandwhich). no issues with go apps though... 2024-04-22 16:53:21 I am also having connectivity issues, so if anyone wants to remove the provides in mbedtls2 (last few comments in !63885), just go ahead (though mbedtls2 will only be supported until the end of the year, so not sure if it should still be included in Alpine 3.21) 2024-04-22 17:14:27 !16049 2024-04-22 17:14:41 ehm, err 2024-04-22 17:14:49 #16049 2024-04-22 17:18:18 celie: something something provider_priority? 2024-04-22 17:18:30 still not too confident in how these work 2024-04-22 17:20:22 provider_priority is required when you have a virtual provides 2024-04-22 17:20:32 higher priority wins 2024-04-22 17:23:16 but the mbedtls2 provides is versioned, so not virtual 2024-04-22 17:24:00 and anyway, according to those comments in that MR, the 2 versions of mbedtls can co-exist 2024-04-22 17:24:48 At least until something tries to load both versions at the same time, that probably won't be good 2024-04-22 17:27:16 ikke: it's a tiebreaker, last resort thing 2024-04-22 17:27:31 if the provider versions differ then the newer one is taken by default regardless of priority 2024-04-22 17:27:52 hence it being required for virtual providers, which by definition do not have a version 2024-04-22 17:28:11 unversioned virtual providers require you to pick one explicitly 2024-04-22 17:28:20 versioned virtual providers follow the standard rules 2024-04-22 17:28:30 i don't think unversioned ones account for priority 2024-04-22 17:28:37 apk will just ask you pick one of them manually 2024-04-22 17:28:59 virtual providers absolutely can have a version 2024-04-22 17:30:39 I think what's being requested, in the case of mbedtls 2 vs 3, is for both to be installable at the same time, so probably something to be solved rather by the absence of providers 2024-04-22 17:31:18 i think if you provide two names virtually the provider priority does not really matter, you will still get asked 2024-04-22 17:31:34 though if i'm wrong that gives me some packaging ideas 2024-04-22 17:31:41 i'll test it i guess 2024-04-22 17:32:26 q66: I have this example: https://gitlab.alpinelinux.org/kdaudt/apkgquery#provides-virtual-package-without-setting-a-provider_priority 2024-04-22 17:32:36 because this case caused issues 2024-04-22 17:33:07 i'm testing it now 2024-04-22 17:34:46 ikke: celie: hey you are right https://gist.github.com/q66/5c16a661e936a69651aa2c16078474e7 2024-04-22 17:34:48 that's pretty neat 2024-04-22 17:34:49 TIL 2024-04-22 21:49:36 I am updating abuild on the 3.20 builders 2024-04-22 21:49:44 so they no longer fail on /var/run 2024-04-23 03:08:35 I will very likely be merging !64687, !64690, and !64691 to hopefully allow the 3.20 ARM builders to proceed to community 2024-04-23 03:16:18 also !64692, which is probably the last blocker for 3.20 ARM 2024-04-23 03:17:08 logcheck seems to fail due to fhs check? 2024-04-23 03:17:24 Yes, it's /var/lock this time, and not /var/run 2024-04-23 03:17:30 There's an issue for it #16050 2024-04-23 03:18:42 That's why i didn't bump pkgrel, i expect that, if a better solution comes out of issue 16050, it would involve bumping pkgrel 2024-04-23 03:18:46 oh, I read s/fhs/the/ 2024-04-23 03:29:32 Ok, CI has passed, let's get some of the 3.20 builders to move onto community.. 2024-04-23 04:37:21 morning! great job celie! 2024-04-23 04:46:15 I'm sure there were lots of fixes by others before me, i just happened to be around for the last 4 (and managed to find ways to fix them) :) 2024-04-23 04:46:17 (i've killed the py3-future tests) 2024-04-23 04:48:27 It seems the 3.20 builders have finished 100+ aports in community without erroring out 2024-04-23 04:48:29 3.20 ARM* 2024-04-23 05:29:08 For bluez, there is https://github.com/bluez/bluez/issues/683 where removing "-flto" was suggested as a solution for fixing the failing test 2024-04-23 06:50:14 i tried disable -flto=auto in blue but test still fails 2024-04-23 07:49:59 i think we need help build-edge-riscv64 pass the finish line of community repo 2024-04-23 08:02:34 The riscv64 pipeline has failed for https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/64665 . Is there anything I need to do? Seems to be a python issue? 2024-04-23 08:15:47 it's the one mentioned above, build-edge-riscv64 isn't done with community/ yet so the python 3.12 rebuilt community/ aports are not yet available in CI, or anywhere 2024-04-23 08:19:00 Ok, thanks omni. Looks like it was just merged anyway. I'll go get back in my box :) 2024-04-23 08:19:45 Anyone comment on why I was having issue with dabuild? I've always used it as the 'first' step in updating packages, and once they pass with dabuild I run them through the CI containers locally. Yesterday dabuild was failing to find python dependencies, but the CI containers worked just fine. 2024-04-23 08:21:34 adhawkins: yes, I just assumed it will also pass on the riscv64 package builder, where the rebuilt dependencies should be available, otherwise I'll nudge you with a build log for py3-parametrize-from-file 2024-04-23 08:22:03 Thanks omni. 2024-04-23 09:14:13 adhawkins: also, your issues that you don't see in CI could be that the mirror you are using has not yet caught up 2024-04-23 09:14:48 !64448 should help move the 3.20 package builders, where some seem to have issues with main/bluez 2024-04-23 09:15:53 omni: Ah yes, it's using 'http://dl-cdn.alpinelinux.org' so I guess that's possible. 2024-04-23 09:16:39 But then again, so is the 'CI' container... 2024-04-23 09:17:27 it was just a guess 2024-04-23 09:17:34 maybe you ran it earlier 2024-04-23 09:18:21 I've just run both within a few seconds of each other to check. It's no big deal, it's just *slightly* quicker to run dabuild as you don't have to keep committing to git. 2024-04-23 09:18:59 besides bluez, procps-ng and gnutls has issues 2024-04-23 09:19:48 there is !62724 2024-04-23 09:22:48 ptrc: oh, you made it pass with 3dc2aa8cf2428397415b271291c4020c76af3469 2024-04-23 09:23:08 yeah, kinda 2024-04-23 09:23:11 i still don't like it 2024-04-23 09:23:19 but if it unblocks the builders.. 2024-04-23 10:33:00 omni, will you be going over other openssl consumers to see if they also need some /usr help? 2024-04-23 10:44:55 maybe, not sure I will, but I think it would be a good thing to do 2024-04-23 10:46:51 I mean, I'm not sure how I would go about doing it and there are often other things that draw my attention 2024-04-23 10:47:42 and perhaps it should be addressed in the openssl aport instead 2024-04-23 10:49:23 https://github.com/openssl/openssl/issues/23569 2024-04-23 11:02:18 Anyway, it probably doesn't matter now as +M has been removed (hopefully it doesn't need to be added again soon due to spammers) 2024-04-23 11:02:18 I may have a theory about what's happening with Matrix. maribu, IngwiePhoenix[m]: did you visit https://services.oftc.net/ to verify your nickname? (iirc, you have to solve a Captcha) 2024-04-23 11:02:22 ikke: You've assigned #15884 to me, but there is something not quite right with it 2024-04-23 11:02:22 Erlang 26.2.3-r1 is only available on Edge 2024-04-23 11:02:24 So, this is very likely a case of mixing Edge with 3.18 2024-04-23 11:03:12 !61309 2024-04-23 11:03:14 for py3-hatchling 2024-04-23 11:03:14 For py3-pygments, i've managed to just patch out hatchling: !55747 2024-04-23 11:03:16 Maybe that can be replicated with py3-dnspython 2024-04-23 11:03:16 You're welcome 2024-04-23 11:03:18 The close MR is !58704, but you probably know better if there's anything there worth looking at 2024-04-23 11:03:18 closed* 2024-04-23 11:03:20 but i've seen more and more projects moving to hatchling, so it's probably just a matter of time before it gets into main 2024-04-23 11:03:24 Do you plan to squash all those commits? (Unsquashed they would number in the thousands, right?) 2024-04-23 11:03:26 So, unittest was amove'd to the tests subpackage, does that mean we'll need to add python3-tests to checkdepends to use unittest now? 2024-04-23 11:03:26 Alright 2024-04-23 11:03:28 because the circular dep thing only comes into play when bootstrapping a new release, so you can still run `abuild check` locally at other times 2024-04-23 11:03:28 For !61309, maybe it makes sense to leave check() in place (not trying to give you more things to do though, so if you think it's better to remove then ok) 2024-04-23 11:03:32 Oh, so you patched it 2024-04-23 11:03:32 I thought !61309 with the hatchling to main move was almost ready to be merged 2024-04-23 11:03:34 but i think if hatchling is going into main soon, it is probably better to wait for that 2024-04-23 11:03:34 I see a patch to the APKBUILD in build-with-setuptools.patch 2024-04-23 11:03:36 So, it isn't like pygments, where they were using setuptools before that (so easy to revert that change) 2024-04-23 11:03:36 I looked into the Git history of dnspython, and it seems before hatchling, they were using poetry 2024-04-23 11:03:38 py3-cryptography is needed for the dnssec tests, it's in community, but i guess we are in no hurry to enable all the tests anyway 2024-04-23 11:03:38 I've also enabled tests and ran them locally for !62614, and it looks fine (as Cython is no longer supported, you can probably remove it from makedepends, and set the arch back to "noarch") 2024-04-23 11:03:40 (oh, and i'm still on pytest 7, in case anyone decides to try the tests with pytest 8 and something fails) 2024-04-23 11:03:55 celie: I didn't look to deep in that issue 2024-04-23 11:04:01 omni, i do think it would be better to address in the aport, or upstream, yes 2024-04-23 11:04:04 briefly, either add `py3-pytest-tornasync` to checkdepends, or add `py3-pytest-asyncio` to checkdepends + patch in the pytest.mark.asyncio marker 2024-04-23 11:04:04 ncopa: i've left some comments on !62689 with how to make the tests pass 2024-04-23 11:04:06 Will open another MR for py3-responses, now looking into enabling the other tests 2024-04-23 11:04:06 ncopa: !62691 2024-04-23 11:04:08 I've looked through my Python aports, and found 2 that fail tests: py3-django-hatchway and py3-aioquic 2024-04-23 11:04:08 You're welcome 2024-04-23 11:04:10 So, i'm not sure if this means django-hatchway is broken in other ways besides the test due to Pydantic 2 2024-04-23 11:04:10 django-hatchway seems to be related to the Pydantic 2 upgrade yesterday, i've managed to patch the test in !62693 but looking through Github, it seems upstream has postponed the Pydantic 2 upgrade (https://github.com/andrewgodwin/django-hatchway/issues/5) 2024-04-23 11:04:12 As for py3-aioquic, i have !62676, but it seems the upgrade is even worse and tests just hang now, it's been almost 3 hours, so i'll go cancel the pipeline now 2024-04-23 11:04:12 I think !62695 would be good to have, i ran into some packages/file conflicts while running `abuild deps` after adding py3-pytest7 to checkdepends 2024-04-23 11:04:14 changing* 2024-04-23 11:04:14 or rather, chaing py3-pytest to py3-pytest7 in checkdepends 2024-04-23 11:04:16 raspbeguy: i investigated the ruff-nix-s390x issue in !58433, if my findings are not outdated now after more than 2 months, this is related to: 2024-04-23 11:04:16 https://github.com/watchexec/clearscreen/pull/15 2024-04-23 11:04:18 I didn't submit it, it is by dependabot update 2024-04-23 11:04:18 You're welcome 2024-04-23 11:04:20 Don't worry 2024-04-23 11:04:22 If you search for "nix" in ruff's Cargo.lock, you'll see that it's only used by clearscreen: https://github.com/astral-sh/ruff/blob/v0.3.3/Cargo.lock#L393 2024-04-23 11:04:22 Anyway, it just means clearscreen is not compatible with nix 0.27, which iirc is the version that fixes the issus with s390x 2024-04-23 11:04:24 or maybe find out which part of ruff needs clearscreen, grepping through the source, i think it is only used here: https://github.com/astral-sh/ruff/blob/v0.3.4/crates/ruff/src/printer.rs#L451 2024-04-23 11:04:26 Probably there is some other terminal screen clearning library that can be used 2024-04-23 11:04:26 So, i guess upstream finally fixed things after yanking pytest 8.1.0 2024-04-23 11:04:28 I think boomanaiden1548 also maintains py3-setuptools-rust, and there have been past attempts by ptrc and me to upgrade that, but i think it has some failing tests 2024-04-23 11:04:28 I think py3-setuptools-rust 1.7.0 is required for !62609 2024-04-23 11:04:30 At least i have some better news, i tested !62676 locally with py3-cryptography 42.0.5 built with py3-setuptools-rust 1.7.0 and all tests pass with py3-pytest 8.0.2 2024-04-23 11:04:30 Yes, so maybe py3-pytest7 is still a good temporary fix 2024-04-23 11:04:32 I think i've got it 2024-04-23 11:04:34 https://github.com/rust-lang/rust/blob/1.77.0/library/std/src/sys/pal/unix/args.rs#L109 2024-04-23 11:04:34 "glibc passes argc, argv, and envp to functions in .init_array, as a non-standard extension" 2024-04-23 11:04:36 Maybe later, i will put all my findings in an MR first 2024-04-23 11:04:36 Does musl do that? 2024-04-23 11:04:38 So, if any of those aports are needed for the Python 3.12 rebuild, at least they are there 2024-04-23 11:04:38 Alright, looks like pyskose has confirmed my findings in !62723 2024-04-23 11:04:40 and as the ex_doc binary is BEAM vm bytecode, musl compatibility doesn't come into the picture 2024-04-23 11:04:40 I guess i can't really solve the problem by packaging ex_doc, because that would introduce a circular dependency, erlang -> elixir -> ex_doc -> erlang 2024-04-23 11:04:41 celie: is your bouncer acting up? 2024-04-23 11:04:42 I also see ex_doc.sha1sum and ex_doc.sha256sum files in https://github.com/erlang/otp/tree/master/make , so if those are also included in the Erlang 27 release tarball (i will look at the rc2 tarball shortly) 2024-04-23 11:04:42 So, on a brief look, i don't think i can do much, short of getting upstream to change their decision, which is probably not very likely to happen 2024-04-23 11:04:44 Alright, so just wondering what you would suggest, that upstream doesn't use ex_doc, 2024-04-23 11:04:44 then we should be checksuming the remotely downloaded ex_doc indirectly by checksuming the whole Erlang release tarball 2024-04-23 11:04:46 or that they build it from source (which i guess would mean they need to build elixir too)? 2024-04-23 11:04:46 Yes, i know ex_doc is something new to Erlang 27 and isn't used in 26.2.3 2024-04-23 11:04:48 Isn't there a `command -v` check for ex_doc in https://github.com/erlang/otp/blob/master/make/ex_doc_wrapper ? 2024-04-23 11:04:48 I'm maintaining community/erlang now :) 2024-04-23 11:04:50 However, for Alpine, having a locally built ex_doc would introduce a circular dependency 2024-04-23 11:04:50 Unless we keep an old version of Erlang and Elixir that doesn't depend on ex_doc around to build ex_doc.. 2024-04-23 11:04:52 Yes, that's quite a big change and is not likely to happen 2024-04-23 11:05:55 matrix troubles? 2024-04-23 11:06:16 oh wow 2024-04-23 11:06:18 whoops 2024-04-23 11:06:40 I've seen it before 2024-04-23 11:06:57 old conversations are replayed 2024-04-23 11:07:28 ah 2024-04-23 11:21:17 Sorry about that bouncer fail 2024-04-23 13:01:56 celie: No, I did not. I'll give it a try 2024-04-23 13:03:30 I did so now :) 2024-04-23 13:09:00 and /whois now show that you are "identified and verified with services", so that means it has worked 2024-04-24 03:43:22 With !64756 (this test was last disabled on x86, and s390x before that; this is also the first time tests are running on the riscv64 builder), i think and hope build-3-20-riscv64 can now proceed to community 2024-04-24 03:49:25 Ok, build-3-20-riscv64 is now uploading main 2024-04-24 03:50:59 That leaves 3 archs still on main, x86_64 and x86 (stuck on bluez), and ppc64le (stuck on procps-ng) 2024-04-24 04:43:19 what if a package is download directly, no source no build only binrary, does aports accept this kind? 2024-04-24 04:48:51 no 2024-04-24 04:48:59 because we don't package nonfree software 2024-04-24 04:49:15 and if it's free software it ought to be source buildable 2024-04-24 05:23:18 is there any repo like aur to put nonfree package 2024-04-24 05:26:18 I don't know of one 2024-04-24 05:30:40 You can always start your own repo 2024-04-24 05:33:31 would non-commercial be considered non-free by Alpine? Like the XMAME license for instance. 2024-04-24 05:42:47 there are a very small handful of CC-NC licensed packages that I see 2024-04-24 05:44:49 really very few though 2024-04-24 06:32:30 what is the status of py3.12 for riscv64? 2024-04-24 06:38:49 https://build.alpinelinux.org/ 2024-04-24 06:39:21 its building 6/75 so 69 left to build 2024-04-24 06:43:43 We've mostly just been merging Python aports that fail on riscv64 if they succeed on all the other archs 2024-04-24 06:44:35 Especially if the aport depends on other aports in testing, then the backlog will be much more than the 70 aports in community 2024-04-24 06:56:23 does numactl make any sense on riscv64? Why disable tests instead of just disabling the arch completely? 2024-04-24 06:57:15 There are 4 aports that depend on it 2024-04-24 06:57:39 s/4/3/ 2024-04-24 06:57:44 and that's in main 2024-04-24 06:57:54 hwloc, irqbalance, and pmacct 2024-04-24 06:58:19 If we disable numactl, we'd have to disable those 3 from main 2024-04-24 06:58:23 and lots more in community 2024-04-24 06:58:36 ahh, that's unfortunate 2024-04-24 06:58:38 The main one (from looking through the Git history) is qemu 2024-04-24 07:00:41 sounds like I wasn't the first person to think of that, so I'll go back to lurking and leave this to the pros 2024-04-24 08:37:25 iggy: nah, it was good that you asked, now more people know 2024-04-24 08:53:56 guess 3 times why libmarisa get the word size wrong on riscv64: https://github.com/s-yata/marisa-trie/blob/master/include/marisa/base.h#L31 2024-04-24 09:01:12 Lesigh 2024-04-24 09:01:42 Will also affect loongarch then 2024-04-24 09:04:39 isnt that the same as mips64 ? 2024-04-24 09:06:47 mips64 is in the list 2024-04-24 09:08:55 there are 4 other issues/PRs. apparently it is a difficult problem to solve 2024-04-24 09:19:04 btw if php8x will fail on some openssl33 tests, please just add this tests to disabled list 2024-04-24 09:34:41 👍 2024-04-24 09:35:18 bluez failure is a problem. x86* is one of the slowes builders we have, and its far behind now 2024-04-24 09:35:53 I'm tempted to merge !64448 for it 2024-04-24 09:36:21 but would also like build-edge-riscv64 to complete and upload community/ 2024-04-24 09:40:58 maybe it won't slow it down that much 2024-04-24 09:41:07 and is worth it 2024-04-24 09:45:28 hello, on a new edge VM I have this apk error: ERROR: kactivities5-libs-5.115.0-r1: BAD signature 2024-04-24 09:45:38 oops wrong chan, sorry 2024-04-24 09:58:43 ok, let's go 2024-04-24 10:01:17 another blocker is procps-ng, FAIL: library/tests/test_pids 2024-04-24 10:04:45 omni: thats only ppc64le, right? 2024-04-24 10:04:59 yes, just saw that 2024-04-24 10:05:06 thought it was on others too 2024-04-24 10:05:35 build-3-20-x86* uploading packages to main 2024-04-24 10:06:14 ERROR:src/shared/tester.c:949:test_io_recv: assertion failed (len == iov->iov_len): (5 == 6) 2024-04-24 10:06:20 sounds a bit scary 2024-04-24 10:06:20 yes 2024-04-24 10:09:11 upstream asked for valgrind/asan/ubsan 2024-04-24 10:09:13 has anyone done that yet? 2024-04-24 10:09:30 does musl have support for asan? 2024-04-24 10:11:22 yes, it works fine 2024-04-24 10:12:00 libsanitizer sometimes doesn't build on other non-amd64 arches on musl, depending on changes (like the LFS stuff) 2024-04-24 10:12:06 but that's all 2024-04-24 10:25:11 I have not done that 2024-04-24 10:25:44 omni: i think you've got ---timeout-multiplier and -print-errorlogs 2024-04-24 10:25:50 in !64769 2024-04-24 10:26:15 dammit 2024-04-24 10:26:17 thanks 2024-04-24 10:26:23 np 2024-04-24 12:42:55 ncopa: !64777 2024-04-24 12:43:53 includes upstream patch for sqlite 3.45.3 compability 2024-04-24 12:44:43 without which tests have been failing on the riscv64 package builder 2024-04-24 13:25:55 thank you! 2024-04-24 13:29:13 there may be just down to fixing ocrmypdf and mopidy for riscv64 to complete and finally upload community/ 2024-04-24 13:29:57 don't let !64743 or !64778 stop anyone else from trying! 2024-04-24 13:45:28 15353eee6c7224c25aff910e9daba303e5aafdea 2024-04-24 13:45:34 i love the commit message :) 2024-04-24 13:45:50 :P 2024-04-24 13:49:16 3 / 18 2024-04-24 13:49:22 on build-edge-riscv64 2024-04-24 13:49:41 im gonna celebrate when its done with community repo 2024-04-24 13:50:55 I wonder how many surprises awaits in testing.. 2024-04-24 13:51:46 i'll worry about that after i have celebrated :) 2024-04-24 13:52:03 :) 2024-04-24 13:52:14 at least it should fix the CI for riscv64 2024-04-24 13:52:53 At least for the aports that don't depend on anything in testing 2024-04-24 13:53:50 This is probably the longest time riscv64 has been blocked on uploading community since the CI for it was enabled by default 2024-04-24 14:06:52 it definitively is 2024-04-24 14:07:18 i think it is the longest any arch has blocked on uploading community, ever 2024-04-24 14:15:05 does LTO work at all on riscv64? 2024-04-24 14:15:37 afl++ tests fails on llvm with LTO 2024-04-24 14:16:08 $ ../afl-clang-lto -o test-persistent ../utils/persistent_mode/persistent_demo.c 2>&1 | tpaste 2024-04-24 14:16:08 https://tpaste.us/xyXw 2024-04-24 15:31:38 I have a question regarding my MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61652 2024-04-24 15:31:38 I ran the lint manually on my machine without any issues. 2024-04-24 15:31:38 The lint job failed due to a segmentation fault. Is this related to the new APKBUILD I added or can I ignore this? 2024-04-24 15:32:54 You can ignore it, I will investigate 2024-04-24 15:33:08 Thanks 2024-04-24 15:33:20 fyi, I switched the linting tool in CI to an improved version 2024-04-24 15:34:14 marcoSch: fyi, the preference is to have patch files instead of using sed to modify files 2024-04-24 15:34:54 I will change this 2024-04-24 15:49:41 marcoSch: it has to do with the ${pkgdir////\\/} parts in the sed commands that triggers this 2024-04-24 15:54:10 As two of the three files I changed with sed, are config files, would it be ok to include them in git or should I also create patches for them? 2024-04-24 15:57:25 It's a trade-off, because including them in aports means that you may forget keeping the config in sync 2024-04-24 15:58:05 The benefit of patches is that the patch will fail to apply if the file changes where the patch interacts 2024-04-24 16:13:37 mopidy, ocrmypdf, py3-corner have failing tests on build-edge-riscv64, possibly also on other architectures if rebuilt 2024-04-24 16:13:51 1/4 2024-04-24 16:14:06 wonder what the fourth is 2024-04-24 16:45:05 now 3.20 builders are catching up with what I discovered in !64367 2024-04-24 17:52:59 Just checking in very briefly, the 4th aport for riscv64 community is probably py3-mopidy-youtube that depends on mopidy 2024-04-24 17:54:26 and i wonder if py3-corner also needs the py3-scipy<1.13 constraint like chaospy and scikit-plot 2024-04-24 18:06:28 can someone look over !64425 ? 2024-04-24 18:06:54 i tried backporting to 3.19 but there are some DB schema changes so i left it to the pros here. :) 2024-04-24 20:18:31 marcoSch: filed a bug for the shell parser that I use 2024-04-24 20:35:00 whohoo! build-edge-riscv64 completed community! 2024-04-24 20:35:02 \o/ 2024-04-24 20:36:46 🎉 2024-04-24 20:38:58 yippie!! 2024-04-24 23:15:17 fossdd: was it the patch you tried to backport or a full upgrade to 1.105.1? 2024-04-24 23:16:03 do you know if there are any breaking changes between 1.96.1 and 1.105.1? 2024-04-25 03:50:43 https://build.alpinelinux.org/buildlogs/build-3-20-s390x/community/memtester/memtester-4.6.0-r1.log 2024-04-25 03:52:53 pyropus.ca redirects to pyropus.ca. which causes certificate verification to fail 2024-04-25 03:57:25 Using `curl -Lv`, i see `subjectAltName: host "pyropus.ca." matched cert's "pyropus.ca"` 2024-04-25 03:57:49 and adding curl to makedepends allows the source tarball to be downloaded successfully 2024-04-25 03:58:40 Does certificate verification in busybox wget (or is it ssl_client here) need to be patched to match curl's behavior? 2024-04-25 03:59:42 I guess what i am really asking about for the moment is, how to fix this? Adding curl to makedepends would be the easy fix.. 2024-04-25 04:30:39 omni: not sure, I only tried to backport the security fix. 2024-04-25 08:16:42 re qt5-webengine. maybe this works? https://codereview.qt-project.org/gitweb?p=qt%2Fqtwebengine-chromium.git;a=commit;h=3664134f749f4851a14ab1953a9ee460a1fe0b68 2024-04-25 08:33:59 ncopa: that I have already tried, what I got stuck on is that six bundled by the bundled catapult needs to be upgraded to 1.6.0 2024-04-25 08:34:33 that is sorted for 112-based qtwebengine-chromium that out qt6-qtwebengine uses 2024-04-25 08:35:00 but not yet 87-based qtwebengine-chromium that qt5-qtwebengine uses 2024-04-25 08:35:54 I did a naive attempt at just adding py3-six to makedepends but, of course, that didn't work 2024-04-25 08:37:05 and stupid googlesource.com still to this day cannot give you a tarball without timestamp that will change checksum every time you download it 2024-04-25 08:37:24 so I cannot add https://chromium.googlesource.com/catapult/+archive/13025491e512e6e7b4c7fca376267fb82acad09b.tar.gz to source 2024-04-25 08:40:56 that is why I figured the "easy" way would be to do something like !31794 again 2024-04-25 08:44:16 if that commit tarball above could be uploaded to https://dev.alpinelinux.org/archive/qt5-qtwebengine/ 2024-04-25 10:33:17 that may not be the right archive... 2024-04-25 13:21:46 celie: what's the reason for !64829 ? 2024-04-25 13:23:07 bl4ckb0ne: most commonly it's the index lines that change due to extra ccommits being added to the repo causing git to use longer hashes to remain unambiguous 2024-04-25 13:23:50 i mean the reason to bring the patch into the repo rather than fetching it 2024-04-25 13:24:03 To avoid it changing again 2024-04-25 13:24:04 bl4ckb0ne: checksum failrue 2024-04-25 13:24:16 The patch changed causing a checksum failure 2024-04-25 13:24:31 I'm not sure if it will happen again, so to prevent that, import it into the repo 2024-04-25 13:24:41 personally I'm in favor of including patches anyway to make it more visible 2024-04-25 13:24:56 I'm sorry if you wanted to review that MR before i merged it 2024-04-25 13:25:19 but the patch looked like it was just changing comments, so didn't look like it would cause any trouble 2024-04-25 13:26:06 celie: its okay that you merged it, dont worry 2024-04-25 13:26:35 bl4ckb0ne: our CI already warns for including patches from github and gitlab 2024-04-25 13:26:42 That was the second patch changing causing a checksum failure i fixed today, so i may have been a bit quick with it 2024-04-25 13:29:48 i didnt know about the CI warning, i'll pull them in the repo next time 2024-04-25 13:29:54 thanks for taking care of this cely 2024-04-25 13:32:06 No problem 2024-04-25 13:32:27 I think usually we pull it into the repo, unless it is a few hundred KB 2024-04-25 13:33:10 For big patches, sometimes ikke puts them on dev.alpinelinux.org instead 2024-04-25 13:53:26 im often too lazy and just slap the url 2024-04-25 13:53:30 i wonder why the checksum changed 2024-04-25 13:54:35 Usually, it's the commit hash, but i also see a version string included in the footer for the hare-riscv64 patch 2024-04-25 14:01:02 cannot find a copy of the original patch anymore 2024-04-25 14:02:55 Yeah, i tried looking on distfiles.a.o, and couldn't find it 2024-04-25 14:04:16 I also checked both rv64 builders, but the 3.20 builder only has the new patch 2024-04-25 14:06:14 The patch was added on 1st March, did we switch from emulated riscv64 to the pioneers after that? 2024-04-25 14:06:28 probably 2024-04-25 14:07:43 https://tpaste.us/yYLx 2024-04-25 14:09:31 So, the version string in the footer changed 2024-04-25 14:10:19 so another reason for patches to change 2024-04-25 14:10:44 and also more likely to happen more often 2024-04-25 15:19:22 Hi, could someone take a glimpse over my "pipeline passed" MRs for merging them? I have marked these, that i think are merge ready with 👍 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?author_username=chereskata&scope=all&sort=popularity&state=opened 2024-04-25 15:20:52 thanks :) 2024-04-25 16:04:28 np. thank you! 2024-04-25 16:14:14 my pleasure 2024-04-25 20:34:33 ncopa: thanks again for the python 3.12 cloud-init test bug report 2024-04-25 20:34:41 ncopa: just merged the fix 2024-04-25 20:36:37 ncopa: we just added alpine to our ci pipeline, so we should catch this upstream next time :) 2024-04-25 22:29:19 minor annoyance : https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/285 2024-04-26 03:11:31 Hmpf..Does anyone feel like fixing the patch checksums for community/codeblocks? 2024-04-26 03:11:41 There are like..13 of them :/ 2024-04-26 03:13:33 I think maybe CI lint needs to display a very very big warning when there are so many volatile patches 2024-04-26 03:14:15 At this point, it would probably be better to just build the git revision that has all those patches included 2024-04-26 06:13:48 holman: thank you! 2024-04-26 11:36:26 celie: are you around? 2024-04-26 11:36:53 cely: ^ 2024-04-26 12:34:53 Hello, I upgraded mautrix-signal 10 days ago adding support for riscv64, but I still don't see riscv64 builds on pkgs.a.o 2024-04-26 12:35:28 Is that expected behaviour? 2024-04-26 12:35:34 https://pkgs.alpinelinux.org/packages?name=mautrix-signal 2024-04-26 12:35:50 Kladky: testing has nog been uploaded yet 2024-04-26 12:35:59 build-edge-riscv64: failed to build onnxruntime: https://build.alpinelinux.org/buildlogs//build-edge-riscv64/testing/onnxruntime/onnxruntime-1.17.1-r1.log 2024-04-26 12:38:41 And that is blocking other packages from being built? 2024-04-26 12:39:37 not from being build, but from being uploaded. The builders only upload completely built repos 2024-04-26 12:47:31 Is there a limit on how long a build job can run? 2024-04-26 12:48:18 I want to package a program written in Crystal, but because the compiler is single-threaded, building it takes at least half an hour (at least on my machine) 2024-04-26 12:50:13 kaathewise: what kind of program is that? 2024-04-26 12:50:18 kaathewise: no, some packages take multiple hours to compile 2024-04-26 12:50:43 but it should be reasonable 2024-04-26 13:03:26 ptrc: https://github.com/elbywan/crystalline 2024-04-26 13:06:05 timlegge: i am now 2024-04-26 13:06:34 oh, i guess we can excuse the long build time 2024-04-26 13:06:39 though builders are quite beefy 2024-04-26 13:06:45 so it might actually take less, maybe even half the time 2024-04-26 13:09:00 Got it, thanks! 2024-04-26 13:18:13 I get "Something went wrong. Please try again." when trying to rebase !64897 2024-04-26 13:20:23 On a related note, what is the best way to contact a package maintainer? Would sending an email be fine? 2024-04-26 13:20:35 either that or opening an issue 2024-04-26 13:21:21 Just wondering, what do you want to contact them about? 2024-04-26 13:22:03 ikke: TY 2024-04-26 13:23:09 cely: the package for Crystal removes some object files for LLVM. I'm not sure what's their exact purpose, but Crystalline fails to build without them. 2024-04-26 13:23:40 Ah, so i guess the maintainer you're talking about is Jirutka 2024-04-26 13:24:08 So, I want to ask why they aren't packaged and if a sub-package with them could be added 2024-04-26 13:24:13 cely: yeah 2024-04-26 13:32:18 timlegge: Your ping sounded urgent, i wonder what's the matter.. 2024-04-26 13:51:34 cely nothing wrong - I am at the Perl PTS in Lisbon. I have been taliking the some SUSE and Fedora people about how to improve generating dependencies for perl modules from CPAN 2024-04-26 13:53:22 Would you be interested in being involved. We are potentialy looking at a CPAN module that would abstract the depedency and probable provide some of the license information and so on 2024-04-26 13:58:10 That's interesting 2024-04-26 13:59:51 I'm not sure if i will be able to help with anything there though 2024-04-26 13:59:55 Will you be involved? 2024-04-26 14:10:27 Yes, I plan to be 2024-04-26 14:11:27 cely: I will keep you posted and send you info when/if we make progress 2024-04-26 14:11:46 That sounds good 2024-04-26 14:11:46 Thanks 2024-04-26 16:54:29 In 5 minutes I will upgrade gitlab and it will be briefly unavailable 2024-04-27 00:23:42 The x86 builder seems to have run out of space 2024-04-27 15:30:45 I have #12413 issue. Could anyone look into it and reopen if they're able to reproduce it? 2024-04-27 15:31:35 There's one more person who had the same issue as seen here https://irclogs.alpinelinux.org/%23alpine-linux-2024-04.log at 2024-04-02 09:38:09 2024-04-27 16:03:00 Hi all. I appreciate this probably isn’t a priority, but could someone comment on MR !63977 on case there’s any feedback? I’ve already left a comment there myself for consideration. 2024-04-27 16:35:50 there's a new fun message on the ~users ML 2024-04-27 16:35:58 and.. does anyone know what is "Alpine 18" 2024-04-27 16:36:12 ...oh, nevermind, they probably mean 3.18 2024-04-27 17:45:00 ncopa: Thank you for pointing out v9.0.0 of QEMU. I've now closed MR !64945 If you (or anyone else) have the opportunity to glance at !64135 it would be highly appreciated. 2024-04-28 11:32:42 ncopa: I think icu 75 may have to wait till after 3.20 release due to the new C++17 equirement, several aports need to catch up upstream or be patched 2024-04-29 04:18:46 `testing/fcitx5` in the mirror still keep at 5.1.8 on riscv64. 2024-04-29 04:18:50 The latest version (5.1.9) built on 04.25, and doesn't seem to have build errors: https://build.alpinelinux.org/buildlogs/build-edge-riscv64/testing/fcitx5/fcitx5-5.1.9-r0.log 2024-04-29 04:23:25 lindsay: see https://build.alpinelinux.org/ 2024-04-29 04:23:48 the builder is still stuck at the testing repo 2024-04-29 04:33:00 I thought the existence of the compilation log meant it had been packaged. 2024-04-29 04:33:02 Thanks ikke. 2024-04-29 04:36:45 The compilation log means it's been built, but doesn't guarantee that the .apk has been uploaded. 2024-04-29 07:24:56 omni: ok 2024-04-29 07:26:26 i wonder how to deal with aports that specifies a specific git hash. https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65002#note_400124 2024-04-29 07:27:04 makes it relatively easy to intentionally sneak in an older , vulnerable version and hide it with a "new" pkgver 2024-04-29 07:27:27 !65002 2024-04-29 07:27:44 yup 2024-04-29 07:31:02 im open to ideas 2024-04-29 07:31:44 Wouldn't it be better to ask upstream for a proper release? 2024-04-29 07:31:53 Perhaps `abuild checksum` could be made to find the date of the commit and update pkgver, but that still doesn't rule out people manually editing the APKBUILD 2024-04-29 07:32:10 It will however prevent honest mistakes 2024-04-29 07:38:52 Could someone with merge rights please look at !63332 ? I've been test-driving it for a week now and it works well. 2024-04-29 07:39:06 asking upstream for a proper release would absolutely be the best 2024-04-29 08:44:44 hey! I have an app I wanna upload to alpine testing or whatever, can somebody please help? 2024-04-29 08:45:52 my own app. I have an APKBUILD file. tested on my phone, works fine with a touch screen or without, based on gtk. 2024-04-29 08:46:14 (in rust) 2024-04-29 08:47:14 other questions: are Cargo.toml respected? should I compile with -Oz or -O3 or ..? should I use LTO? I have tested and found the optimal combination that produces smallest binary on my machine, should I enforce that in the build script? 2024-04-29 08:48:02 (btw for minimal size, it's LTO+-Os+codegen-units=1) 2024-04-29 08:48:32 https://github.com/DaKnig/DewDuct/ <- link to app 2024-04-29 09:01:00 You can open an MR to aports 2024-04-29 09:03:44 DaKnig[m]: maybe you can take a look at other rust aports to see how they are packaged (though they are statically linked) 2024-04-29 16:34:02 made an MR for adding my app into alpine. 2024-04-29 16:34:02 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/65095 2024-04-29 16:34:39 app named DewDuct, has screenshots and all, works great on my phone running alpine derivitive 2024-04-29 16:35:28 DaKnig[m]: what phone are you using? assuming the alpine derivative is postmarketos? 2024-04-29 16:40:57 pinephone and yes 2024-04-29 16:41:14 this app does not rely on anything from pmos directly so should fit fine in alpine 2024-04-29 16:41:57 very nice! the app looks really cool :) 2024-04-29 16:45:22 thanks! check it out and make issues! I promise to prioritize what users want (as long as it falls within the scope...) 2024-04-29 21:30:51 what is wrong here? https://gitlab.alpinelinux.org/Piraty/aports/-/jobs/1366693 2024-04-29 21:35:40 Hmm, not sure, no indication 2024-04-29 22:11:02 hi 2024-04-30 08:42:59 ptrc: i see you just mergedthe MR to remove testing/libhandy, any ideas if tau and lightdm-mobile-greeter from #16063 can be switched to libhandy1 too? 2024-04-30 08:43:14 oh, damn it 2024-04-30 08:43:16 i missed that 2024-04-30 08:43:22 No problem 2024-04-30 08:43:25 I've disabled them anyway 2024-04-30 08:44:14 I guess this just means they're going to be removed faster if no one ports them to libhandy1 2024-04-30 08:44:34 as far as i can tell, porting to libhandy1 isn't very hard 2024-04-30 09:31:50 what's libhandy1? if you dont mind me askig 2024-04-30 09:32:31 gtk widget library 2024-04-30 09:33:22 or framework or something, it's from gnome 2024-04-30 09:33:48 yes, but how is that different from libhandy 2024-04-30 09:34:55 sorry, completely misunderstood. please ignore. 2024-04-30 09:36:42 just a different version 2024-04-30 09:42:29 Old basically 2024-04-30 15:40:40 HRio: Do you mind taking over netplan? 2024-04-30 15:40:48 I'm not that interested in maintaining it anymore 2024-04-30 15:41:10 And it needs some love switching to the new build system 2024-04-30 17:03:35 Would anybody have some hints on how to debug a situation where build is failing in some arches only? 2024-04-30 17:03:35 https://gitlab.alpinelinux.org/pabloyoyoista/aports/-/jobs/1367575#L3032 2024-04-30 17:04:10 The weird thing is that it's complaining about a missing structure, from a header that is actually included 2024-04-30 17:04:21 (by the info printed later) 2024-04-30 17:04:59 @PureTryOut:matrix.org it's qt6, so maybe you've seen something similar? 2024-04-30 17:05:40 Yeah, KdenLive. OpenGL issue 2024-04-30 17:05:47 Idk how to solve it properly though. 2024-04-30 17:05:55 Any clue how to fix it 2024-04-30 17:06:11 arm Qt is built with OpenGLES rather than proper OpenGL and some things don't like that 2024-04-30 17:06:50 Is there no way clients can detect it? 2024-04-30 17:07:14 Idk, seems it's required to know at compile time 🤷 2024-04-30 17:12:09 Right. And does qt6 not export some define to say "I suppport GLES instead of GL"? 2024-04-30 17:16:09 Anyway, going to try disable x11 support 2024-04-30 17:16:12 Thanks! 2024-04-30 18:03:54 Would anybody be able to have a look at 2024-04-30 18:03:55 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/64677 2024-04-30 18:04:10 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/64678 2024-04-30 18:04:28 Took a bit to fix, but they have completely broken GNOME Software 2024-04-30 18:04:58 s/but they/but without them we/ 2024-04-30 18:10:44 Peeps, I am somewhat stuck...... (full message at ) 2024-04-30 18:14:50 I guess it's fine to update the patch files 2024-04-30 18:15:09 The original patch is always visible in the git history 2024-04-30 18:48:13 opinions on !64356?