2024-03-01 09:09:43 Seems like os-prober needs 'fuse' module to be loaded for proper functioning. But if os-prober is triggered after kernel upgrade, it would not be possible to load any modules until reboot, so os-prober will find nothing and grub boot menu would be unpopulated 2024-03-01 09:27:56 i just pushed musl 1.2.5 2024-03-01 09:41:07 nice 2024-03-01 10:28:14 <_rsp_> Hey everyone! I'm trying to build an armv7 cross compiler for Alpine 3.19.1 with bootstrap.sh, which fails (at the moment) because openssl cannot link against libatomic. Can someone give me any hint on how to fix this? I use the build-base container from https://hub.docker.com/r/alpinelinux/build-base with package sources downgraded to v3.19 and I checked out the tag v3.19.1 of aports. 2024-03-01 10:29:52 <_rsp_> Alternatively, if there are pre-built cross compilers or a different approach to building them, I'm grateful for any hints on that as well :) 2024-03-01 10:37:52 _rsp_: we do not provide general purpose cross-compilers 2024-03-01 10:42:09 <_rsp_> ikke: how do I build software I want to run on Alpine and armv7? Should I fully integrate it into the aports structure? 2024-03-01 10:45:16 qemu-user is a good option 2024-03-01 10:46:01 If you have aarch64 hw, you can also use 32bits containers if the cpu supports that 2024-03-01 10:46:53 <_rsp_> okay, right now I can't build with qemu involvement, so I was looking at bootstrap.sh. So my understanding is that the bootstrap script isn't really the way to go, right? 2024-03-01 10:55:26 We only use it on edge, and even there it constantly needs to be fixed 2024-03-01 10:55:57 we build all our architectures natively. no cross compiling 2024-03-01 10:56:18 riscv64 currently is built in qemu-user, but we are working on setting up real hardware for that 2024-03-01 10:56:42 reason is that we want to run the test suites for each package 2024-03-01 10:58:16 We only use the bootstrap compiler for bootstrapping ;-) 2024-03-01 10:58:48 <_rsp_> ah cool, so you have actual hardware for each architecture, on which you build and test all packages? 2024-03-01 10:58:56 correct 2024-03-01 10:59:00 <_rsp_> very nice! 2024-03-01 10:59:16 except riscv64, which is work in progress 2024-03-01 10:59:48 that said, if you do find a bug in boostrap.sh *and* a fix, please feel free to submit a MR 2024-03-01 11:00:03 <_rsp_> sure, will do :) 2024-03-01 11:00:10 <_rsp_> thanks a lot both of you for the background information 2024-03-01 11:00:34 we actually have binutils-cross 2024-03-01 11:03:07 <_rsp_> I'll take a look at two paths, one is to check whether I can in fact use qemu for building (the build environment is constructed for cross compilation right now) and the other is to see if I can create a gcc based on musl with other tools and maybe make use of binutils-cross 2024-03-01 11:14:58 i thikn binutils-cross is someone overkill. ther eis a binutils-x86_64 on x86_64, which is sort of meaningless? 2024-03-01 12:45:08 _rsp_: it may be worth noting that the postmarketos folk have prebuilt cross compiler packages in their repos, you could grab then from there if you wanted. 2024-03-01 12:45:12 https://pkgs.postmarketos.org/packages?name=*-aarch64&branch=master&arch=x86_64&origin= 2024-03-01 12:46:20 Why don't we have general cross compilers packaged anyways? Is the effort just not worth it since we're primarily natively compiling things, or has nobody come forth with MRs to add and maintain them? 2024-03-01 12:49:04 Combination of both 2024-03-01 12:49:42 Most aports are not setup for cross-compilation as well 2024-03-01 13:00:06 <_rsp_> durrendal: thank you very much, added to my TODO list :) 2024-03-01 13:09:51 I was fighting with the bootstrappers recently as well, running into the same libatomic issues. It didn't seem like an easy problem to solve unfortunately 2024-03-01 13:10:52 ikke: that makes sense. The postmarketos packages seem to just be slightly modified versions of our musl, binutils, etc packages. But other aports not being setup for cross compilation is another issue. 2024-03-01 13:21:34 which pkg would solve this? -> error opening directory "/usr/local/share/glib-2.0/schemas": No such file or directory 2024-03-01 13:24:46 vkrishn: none, packages should not install anything in /usr/local 2024-03-01 13:26:26 yes, i recall that, will try to clone aports and try the normal way 2024-03-01 13:28:06 diffuse 0.8.2 might be having bugs, 0.7.7 seems ok 2024-03-01 13:29:47 vkrishn: you may need to set --prefix /usr or something like that when building 2024-03-01 13:30:25 ok, thanks 2024-03-01 16:25:05 <_rsp_> Did someone at some point find a solution for relinking issues with bootstrap.sh and (in my case) binutils? I'm getting an error because apparently an attempt is made to involve /usr/lib/libc.so in the cross build, which obviously cannot work 2024-03-01 17:35:47 nmeum: rv64 fix has been merged and will be backported 2024-03-01 17:37:36 yea, see !61378 2024-03-01 17:38:51 πŸ‘ 2024-03-01 18:55:41 how to disable appstream ? https://d.insteps.net/diffuse.messon.0.txt 2024-03-01 18:56:25 does your apkbuild have the `net` option ? 2024-03-01 18:58:22 i have limited net access, already have downloaded src's in /distfiles and all /main /community apks 2024-03-01 19:01:07 and not using 'rootbld', just abuild -r 2024-03-01 19:01:26 do i need to do, "apk add abuild-rootbld" ? 2024-03-01 19:07:06 keep getting, https://tpaste.us/KEJo 2024-03-01 19:07:47 i have created directory, /home/vkrishn/packages/[main,community,testing] 2024-03-01 19:09:57 vkrishn: those are just warnings, you can ignore them 2024-03-01 19:10:02 ok 2024-03-01 19:10:12 It just means your local package repos are still empty 2024-03-01 19:18:59 validation should be dependant on special 'net' connection and worst 3rd-party other than AL 2024-03-01 19:22:14 can't i just have metadata installed locally, using appstream-utit ? 2024-03-01 19:23:54 appstream-util ^ 2024-03-01 19:42:43 found this https://tpaste.us/ogLk , data/meson.build 2024-03-01 19:46:54 awesome !!, just removed appstream from makedepends, and it builds 2024-03-01 19:57:19 is this public "aports" same as one used by devs/builders ? 2024-03-01 20:02:17 this builds/installs and works, https://tpaste.us/j4Zv 2024-03-01 20:09:49 tests, https://tpaste.us/D7p0, i think v0.7.7 is working ok 2024-03-01 20:37:31 not digging into details as what appstream does, but here are some stats, https://tpaste.us/BJ7n 2024-03-01 20:42:57 It provides metadata for appstores 2024-03-01 20:52:43 maybe build appstore..apk and .appstore..apk 2024-03-01 20:53:57 any online appstore can pull/update appstore..apk meta whenever desired 2024-03-01 20:54:31 .appstore..apk can have multiple files .json .yaml .toml ... etc 2024-03-01 20:56:26 any more than that is ${work}, and should not be aports 2024-03-01 20:57:32 https://appstream.alpinelinux.org/ 2024-03-01 20:58:28 fyi, I don't know all the details 2024-03-01 21:17:41 appstore is a proprietory+lock-down kinda model, and from my understading it does not carry open-source zeal, its more a You-build<-I.earn model 2024-03-01 21:18:58 Appstore is not the right word. Just graphical interfaces to install packages 2024-03-01 21:37:26 is there any reason why we don't make use of gitlab issue templates to make sure that reports specify certain information to allow us to extract metadata such as: "which aport is affected"? 2024-03-01 21:37:40 having that metadata would also enable us to automatically assign the issue to the package maintainer etc 2024-03-01 21:38:29 is just that noone has gotten around to it or is did we decided against using those at some point? 2024-03-02 02:35:18 imo that would be nice as options available to users, but definitely not as the only option 2024-03-02 02:35:29 if default, could save a bit of time 2024-03-02 09:13:22 ptrc: 100% aggree, we should definitly allow people to just write text directly without any template but for the use case "report an issue in a specific aport" it would be nice to have a consistent way of specifying the affected aport 2024-03-02 09:13:50 https://docs.gitlab.com/ee/user/project/description_templates.html 2024-03-02 09:14:06 looks like gitlab allows reporters to choose different templates including the option "no template" 2024-03-02 09:15:31 and as soon as we have better metadata for issues, we could automatically assign issues to maintainers, then (at some point) cleanup maintainer comments (i.e. remove people that are no longer active) and that hopefully results in a better bug reporting experience for users 2024-03-02 10:06:43 I came up with three sample templates (package issue, package upgrade request, package request): !61558 2024-03-02 10:06:51 let me know what you think πŸ€— 2024-03-02 11:57:09 nmeum: will implementing the templates need database changes ? 2024-03-02 11:57:25 no, these are just markdown files in the repo 2024-03-02 12:01:01 if not using them later will not cause confusion , then why wait for it 2024-03-02 23:20:37 this should be difficult to fix, probably editing rc file, https://tpaste.us/padw ? 2024-03-02 23:23:15 should'nt^ 2024-03-02 23:36:28 diakonos error - https://tpaste.us/WxLM 2024-03-02 23:42:21 ptrc: thanks for the review/merge 2024-03-02 23:42:31 :) 2024-03-02 23:42:36 you're welcome 2024-03-02 23:45:35 ^^ 2024-03-03 00:01:08 mupdf does not start 2024-03-03 00:01:29 probably install more deps 2024-03-03 02:28:13 hey everyone, i'd appreciate if some of you could take a look and leave some feedback on https://gitlab.alpinelinux.org/alpine/aports/-/issues/15827 :) 2024-03-03 02:43:54 i agree, however i don't use firefox at all for reasons like that. but then librewolf exists 2024-03-03 02:55:24 lol, that seems like a misfeature 2024-03-03 02:55:30 the top stories 2024-03-03 02:57:50 why cant they just focus on writing browser code and not try to be a news aggregator? 2024-03-03 03:01:59 their search deal with google isn't going to go on forever, so they're desperate to have the money coming in some other way. 2024-03-03 03:02:02 orbea: i guess because the news stuff comes from Pocket, a separate team at Mozilla 2024-03-03 03:02:09 but also yeah, another source of income 2024-03-03 03:02:24 at the cost of annoying users who don't know how to turn it off 2024-03-03 03:04:12 yea, that makes sense, didn't think of that, but still seems like an less than ideal setup. Code silly features or lose funding 2024-03-03 03:04:52 they're going to lose it anyway, with google. firefox is ~2% market share now 2024-03-03 03:05:13 in general, or on desktop? 2024-03-03 03:05:24 across all 2024-03-03 03:06:45 well, that's gonna be heavily skewed by chrome being the default browser on android :/ 2024-03-03 03:07:09 for what google makes on firefox defaulting to google, it probably doesn't offset what they pay mozilla 2024-03-03 03:07:27 imo it's cover for chrome being a monopoly 2024-03-03 03:07:58 otherwise i suspect google would have stopped years ago 2024-03-03 03:12:00 to be fair, would firefox switch the default search engine to anything else if google stopped paying? 2024-03-03 03:12:45 but then, that's getting a bit offtopic :p 2024-03-03 03:12:55 they could just leave it unset and prompt the user to pick one 2024-03-03 03:16:21 (imo) this is a slow burn for mozilla, they'd be better to rip the bandaid off, restructure, refactor firefox into something less dependent on mozilla 2024-03-03 03:16:32 what were they using before google started paying them? 2024-03-03 03:17:14 it's been google as far back as i remember ( 3.6-ish ) 2024-03-03 03:17:19 same 2024-03-03 03:31:38 altavista? :D 2024-03-03 03:32:46 what are the privacy implications of leaving it enabled? does firefox prefetch the content? 2024-03-03 03:35:51 it referring to the rfc question. another consideration is whether it will be significant effort for the maintainer to keep a patch for the about:config settings, if the nodes occasionally change 2024-03-03 03:36:41 mio: i'm not sure yet, i'd have to check in the source code; also, would be nice to keep discussion in the issue for others to be able to read later ^^ 2024-03-03 03:55:37 ptrc: sure. tentatively in support of disabling, but also interested in counterpoints for leaving it be. stock experience or something 2024-03-03 03:56:21 yeah, what i'm most concerned is "where's the border between disabling obvious anti-features like sponsored content and actual features, even if annoying" 2024-03-03 14:07:53 'abuild rootbld' fails for testing/gamescope: https://paste.sr.ht/blob/574f47926c1e249e74bed3f8de46832872e747d6 2024-03-03 14:08:01 Is this just me? I'm on edge 2024-03-03 14:08:35 Oh, wait, that didn't fail, nvm 2024-03-03 15:19:12 alpine should add this patch for busybox: http://sprunge.us/Kd7xLC 2024-03-03 15:19:33 it fixes a regression that silently starts corrupting users' timestamps on fatfs filesystems 2024-03-03 15:20:17 see https://www.openwall.com/lists/musl/2024/03/03/3 2024-03-03 15:25:05 nmeum: ^ 2024-03-03 15:28:07 has this been reported to busybox upstream? 2024-03-03 15:31:16 they were cc'd on the email 2024-03-03 15:31:37 *nod* 2024-03-03 15:32:03 both toybox and busybox seem to have a weird policy on this type of thing "we want to actively reject the choices of the OS and try to undermine it to behave like GNU/Linux instead" 2024-03-03 16:12:46 why does using the "kernel-timezone functionality" break fatfs timestamps? also I don't get why busybox upstream decided to add special handling for musl to hwclock in the first place, would prefer if this would be sorted out upstream 2024-03-03 16:22:29 its intentional O_o 2024-03-03 17:42:51 nmeum, i dunno if any changes have been made upstream on kernel side, but historically, any mounted fat-based fs silently offset all its timestamps by the kernel timezone 2024-03-03 17:43:27 presumably based on an assumption you want to share it with windows using localtime in the same timezone 2024-03-03 17:43:59 if an option appeared to override/disable that or control it separately, i never saw it 2024-03-03 17:44:42 Alpine's installer assumes (based on how it sets up a bootloader) it is the only OS on a machine 2024-03-03 17:44:47 in any case this is something like -fno-math-errno also making gcc assume malloc doesn't modify errno >_< 2024-03-03 17:45:16 (linking two settings that should have nothing to do with each other in very broken ways) 2024-03-03 19:17:20 Any reservations on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/54061 ? 2024-03-03 21:35:12 I'd like it in 2024-03-03 21:35:51 !54061 2024-03-03 21:36:26 (for those who don't want to have to follow a link) 2024-03-03 21:37:29 so (unrelated) 3.17 was the last release with mtxrun in it? 2024-03-03 21:38:17 maribu: nothing you've been missing, I assume 2024-03-05 01:09:32 me neither, apparently, haven't used it for years 2024-03-05 12:03:25 fabled: Is it on purpose that '1.2.3_' is considered a valid version, but '1.2.3_-r1' is not? 2024-03-05 15:07:29 i'm edit on APKBUILD, if bash is both needed in depends and makedepends, how should I do 2024-03-05 15:08:29 should I add it in both? 2024-03-05 15:24:02 In that case, you'll only need it in depends 2024-03-05 16:11:51 got it, thx 2024-03-05 16:26:41 Is there anything else !59786 that needs improvement, if I may ask? 2024-03-05 23:46:53 pabloyoyoista: so about trying to fix https://gitlab.alpinelinux.org/alpine/aports/-/issues/15834 ... 2024-03-05 23:47:35 I made an appstream0 package for <1.0.x as we discussed elsewhere, but I'm unable to build gnome-software against it because other deps require appstream 1.0.x: https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/1294486#L1662 2024-03-05 23:55:24 ah this is because of a conflict with the cmd that each installs... /me still struggles interpreting apk errors 2024-03-05 23:59:21 Oh yeah, I guess libadwaita should temporarily also be switched back to 0... 2024-03-06 00:01:27 ok, that was my next question :) 2024-03-06 00:13:25 pabloyoyoista: ok it all built successfully now 2024-03-06 00:16:32 could an Alpine developer take a look at this soon? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61707 (not being able to install gnome-software or upgrade a system w/ it installed is kinda annoying :P) 2024-03-06 00:16:58 sure, looking rn 2024-03-06 00:17:15 thank you! 2024-03-06 00:20:08 hm, those are gonna be mutually exclusive 2024-03-06 00:20:21 they both provide cmd:appstreamcli 2024-03-06 00:20:25 is that okay? 2024-03-06 00:20:54 I'm not sure how short term this is, until GNOME 46? pabloyoyoista ? 2024-03-06 00:21:00 Probably appstream0 should not, I guess 2024-03-06 00:21:18 Would be fine to have both, but then libadwaita apps won't install on plasma 2024-03-06 00:21:19 appstreamcli is called in the post-* and trigger scripts 2024-03-06 00:21:44 Then leave it, and Bart can leave with the fallout 2024-03-06 00:21:49 I thought about renaming it "appstreamcli0" XD 2024-03-06 00:21:56 Should not take long to get rid of this, just a couple of weeks 2024-03-06 00:22:24 ok so to answer ptrc's question, it's OK they are mutually exclusive, right? 2024-03-06 00:24:06 pabloyoyoista: ^ 2024-03-06 00:24:13 I thin kso 2024-03-06 00:24:48 alrighty, worst case i'll try to mitigate any issues after merging :p 2024-03-06 00:25:40 thanks, ya I hope this is very temporary and doesn't cause any major problems 2024-03-06 00:30:37 seems x86_64 finished, i'll look at the dot graphs 2024-03-06 00:31:36 ah 2024-03-06 00:31:37 flatpak 2024-03-06 00:31:59 anything depending on libadwaita now conflicts with flatpak ;; 2024-03-06 00:36:12 uuuughhhh yeah I just ran into that 2024-03-06 00:37:18 so can I just rename appstreamcli --> appstreamcli0 and update the package's post-* files to call that instead? 2024-03-06 00:38:40 oh pabloyoyoista told me in a DM that this won't work... some apps call the cli app and don't use the library 2024-03-06 00:38:54 But we can probably split it into subpackages 2024-03-06 00:39:04 does the CLI thingy change much at 1.0? 2024-03-06 00:39:23 as in, could we try just using the 1.0 CLI for most stuff 2024-03-06 00:39:25 It's probably only alpine-appstream-downloader that needs the CLI for runtime 2024-03-06 00:39:35 Yes, we could 2024-03-06 00:39:49 yeah I have no idea if the cli app from 1.0 is compatible with <1.0 ? 2024-03-06 00:41:26 It should, they didn't break anything obvious there 2024-03-06 00:41:38 ptrc: I can try to send a patch for this if you want 2024-03-06 00:41:39 Everybody uses the CLI to validate appstream metadata in apps 2024-03-06 00:41:50 Would be shooting one-self in the foot 2024-03-06 00:43:09 a patch that: 1) drops the cli app from appstream0, 2) packages the cli app from 1.0 into a new appstream-cli subpkg, 3) updates alpine-appstream-downloader to depend on appstream-cli 2024-03-06 00:45:19 You might bump into problems of failing tests with 1), as the CLI is used on many tests 2024-03-06 00:45:44 Some of those might check for the existence of the cli tool before, so might be good 2024-03-06 07:48:42 ikke: that seems like a bug.Β  _ should not be considered a valid version token at any time, but afaik our version parsing just halts after it hits an unknown condition 2024-03-06 07:58:25 I've created https://gitlab.alpinelinux.org/alpine/go/-/raw/master/version/doc.go 2024-03-06 07:58:55 Tried to document the specification 2024-03-06 11:29:02 i have enabled riscv64 CI runner by default now 2024-03-06 12:51:22 anybody has a good tip how to generate a list of packages that needs to be rebuilt with python 3.12 upgrade? 2024-03-06 12:52:40 i'd say any package containing anything `/usr/lib/python3.*`, but how do I generate a list from that? 2024-03-06 13:01:34 The only place i know that has a file index is pkgs.a.o 2024-03-06 13:10:36 currently doing: https://tpaste.us/PEVD 2024-03-06 13:12:22 is there some way i can query pkgs.a.o in shell? 2024-03-06 13:13:38 There is no api 2024-03-06 15:19:23 ncopa: perhaps `apk list -P 'py3.11:*'`? 2024-03-06 15:19:43 or just `apk list -d 'python3'` - might catch some false-positives, but that's better than missing some 2024-03-06 15:57:38 ptrc: thats a good one! thanks! 2024-03-06 16:36:08 ncopa: do you think it's wortwhile to rename all our deamons users for consistency reasons? I feel like it does not matter much whether the klog users is called klog or klogd 2024-03-06 16:47:07 i'd say the user change may be ok. We havent pushed that to any stable release, right? 2024-03-06 16:47:20 i mean, i dont mind if we keep it as is either 2024-03-06 16:48:02 but i think renaming the init.d scripts is not worth it 2024-03-06 16:48:08 it does create problems when users upgrade 2024-03-06 16:48:39 IIRC i renamed chrony to chroynd or similar and it caused a lot problems 2024-03-06 16:50:41 and i think we could create the user(s) for the daemons in the `busybox-openrc` package 2024-03-06 16:51:06 so we avoid creating them for docker users 2024-03-06 17:10:19 ncopa: I don't mind creating the users in the busybox-openrc scripts. I am really not sure about renaming and deleting users from package upgrade scripts, this can cause issues as well when there are still files chowned to that users on the system etc 2024-03-06 17:11:29 sure, we haven't pushed the klog user to stable yet but ideally I would also want to prevent potential fallout in edge 2024-03-06 17:14:31 and there are also other daemon users which are inconsistently named and already in -stable so then the question is what do we do about those 2024-03-07 00:59:09 heeeey PureTryOut there's actually 54 packages enabled on x86 that have missing dependencies 2024-03-07 00:59:49 some of the missing ones being: plasma-framework5-dev, akonadi-calendar-dev, purpose5-dev, kjs-dev, syntax-highlighting5-dev 2024-03-07 01:00:01 libreoffice can't build 2024-03-07 01:00:09 mauikit can't build 2024-03-07 01:00:59 x86_64 has.. a bit less 2024-03-07 01:01:10 but there's a ton of missing rebuilds, broken dependency chains, etc. 2024-03-07 01:43:07 aaaalso qtwebengine doesn't install properly on x86 2024-03-07 01:43:10 https://pkgs.alpinelinux.org/contents?file=Qt6WebEngineCoreConfig.cmake&path=&name=qt6-qtwebengine-dev&branch=edge 2024-03-07 01:43:21 the cmake files literally don't exist 2024-03-07 01:43:38 = nothing of the kde stuff that uses cmake can link against it 2024-03-07 01:47:23 https://ptrc.gay/rpcKDPSa 2024-03-07 01:47:24 erm. 2024-03-07 02:05:42 PureTryOut: git show 5c9c1b91c9e9ed1e2250146ffeab3ec83719cf1b -- community/qt6-qtwebengine/ 2024-03-07 02:05:45 🀨 2024-03-07 02:08:22 not quite sure why that patch was removed.. 2024-03-07 02:20:02 anyone mind taking a look at !61309 curious if there's anything else that needs to be done there 2024-03-07 07:32:57 nmeum: ok. if you'd like to prevent potential fallout in edge, then we shouldnt rename the users. 2024-03-07 07:33:35 and if users are inconsistently named in -stable, then lets try keep it as is 2024-03-07 07:35:05 re future of busybox tsc issue, https://gitlab.alpinelinux.org/alpine/tsc/-/issues/55, what do we need to do to close it? 2024-03-07 07:35:21 maybe we should doc a statement somewhere, but where 2024-03-07 07:36:15 my take on it is that busybox is a box full of tools. you get the box and you get all the tools, regardless if you want them all or not 2024-03-07 07:37:01 you can override them, by adding packages, but you cannot really remove anything from busybox 2024-03-07 07:37:09 thats the binaries 2024-03-07 07:38:59 for the busybox-openrc, there is a wish to individually pick which busybox services should be in use and which should be overridden. There was a request to make it possible to remove individual openrc scripts and configs from busybox-openrc 2024-03-07 07:39:31 im not sure that is a good idea 2024-03-07 07:40:27 i think it would be nice to keep it simple. you get the bulk of openrc scripts, you get them all, or you get none (apk add !busybox-openrc) 2024-03-07 07:41:40 but I don't think we should splitting it up in 13+ subpackages. 2024-03-07 07:41:58 we get simplicity at a cost of having a few unused extra files on the system 2024-03-07 07:42:10 88k 2024-03-07 07:57:53 ncopa, without having the actual details, that idea of keeping it simple this way sounds sane 2024-03-07 07:58:35 For utilities, there's already a system to override them with other implementations, so doesn't sound like a problem 2024-03-07 07:58:50 For openrc scripts, isn't there a danger of conflict though? 2024-03-07 07:59:04 Or would they be prefixed with β€œbusybox-$service” or something? 2024-03-07 07:59:15 yes. i think there is a conflict for at least one service 2024-03-07 08:01:43 acpid 2024-03-07 08:03:13 i'd prefer not rename them as it causes headaches for upgraders 2024-03-07 08:03:21 I also don't like the idea of removing individual openrc scripts and configs. I feel like it doesn't matter much if you have a few KiB of config files around which you don't use 2024-03-07 08:03:29 exactly 2024-03-07 08:08:39 so to conclude: i think I'd like the busybox-openrc package to be a bulk package. you get them all, or you get none. you are free to disable the service but you cannot uninstall individual services 2024-03-07 08:09:06 re https://gitlab.alpinelinux.org/alpine/tsc/-/issues/55#note_355596 2024-03-07 08:09:36 +1 2024-03-07 08:09:38 I'd like to document somewhere that busybox is expected to be there. you may uninstall it if you want, but then you are on your own 2024-03-07 08:09:46 we dont support it 2024-03-07 08:10:10 so I dont think we should have individual providers for each tool 2024-03-07 08:10:49 User handbook? 2024-03-07 08:11:02 we should not need to add a depends=cmd:sed if an install script uses sed 2024-03-07 08:11:12 it is expected to be there 2024-03-07 08:11:57 Same with /bin/sh 2024-03-07 08:12:02 ikke: its more to set the scope for devs and contributors, who invest time in creating MRs for splitting it up 2024-03-07 08:12:03 bascially these are also questions raised in the original tsc/55 issue description, right? I think it would be great if we get around to resolving this issue in the sense that there is a response to each of the questions raised here which would allow us to close the issue for now 2024-03-07 08:12:41 ncopa: then it would be the developer handbook 2024-03-07 08:13:02 the tsc/55 has multiple questions. I have tried to close some of them. I am not sure the busybox-openrc split is covered though 2024-03-07 08:15:10 I'm around if you want to discuss it, but (I think) my positions are clear 2024-03-07 08:17:47 skarnet: thanks, and yes, your position is crystal clear 2024-03-07 08:19:02 nmeum: would it help if we had a separate TSC issue for splitting busybox-openrc? or do you think tsc/55 covers it? 2024-03-07 08:19:46 my reading is that the second questions in the listing of the tsc/55 issue description "Do we want split busybox into multiple pieces?" covers this already 2024-03-07 08:19:56 ok 2024-03-07 08:21:22 it also seems that Dermot Bradley (who was pushing for this split) was frustrated with the handling of this issue and unfourtunately stopped their alpine involvement just now https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61211#note_382289 2024-03-07 08:21:57 might be related to the prior discussion here https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55129#note_381360 2024-03-07 08:28:32 yes, thats why i spend time on this now (instead of other things i'd like to work on). we need get a conclusion and document it so we stop waste peoples time 2024-03-07 08:29:51 yea, I think that would be good 2024-03-07 10:08:48 im having issues with compiling the kernel in 3.19-stable. I get gcc crashing. a continued build usually make it pass 2024-03-07 10:09:00 i dont know if it is related my hardware or a bug in gcc 2024-03-07 10:29:49 /home/ncopa/aports/main/zfs-lts/src/zfs-2.2.2/6.6.21-0-lts/../module/nvpair/nvpair.c:548:1: internal 2024-03-07 10:29:49 compiler error: Segmentation fault 2024-03-07 10:29:49 | ^ 2024-03-07 10:29:49 548 | } 2024-03-07 10:29:49 CC [M] /home/ncopa/aports/main/zfs-lts/src/zfs-2.2.2/6.6.21-0-lts/module/zstd/lib/decompress/zstd 2024-03-07 10:29:50 _decompress.o 2024-03-07 11:15:12 that usually means hw, unfortunately 2024-03-07 11:17:56 yeah. whats a bit weird is that it appears only to happen in an lxc container with 3.19-stable. it usually builds fine from edge on the same machine 2024-03-07 11:21:08 any ideas what I can do to troubleshoot? memcheck? replace CPU fan? (in case it is caused by overheated cpu) 2024-03-07 11:21:47 hmm... also llvm17 testsuite failed. after a re-run it passed 2024-03-07 11:34:09 python 3.12 time test fails: 2024-03-07 11:34:15 File "/builds/alpine/aports/main/python3/src/Python-3.12.2/Lib/test/test_time.py", line 143, in test_clock_settime 2024-03-07 11:34:15 time.clock_settime(time.CLOCK_REALTIME, t) 2024-03-07 11:34:15 OSError: [Errno 38] Function not implemented 2024-03-07 11:34:48 CLOCK_REALTIME, "Function not implemented" seems not so good 2024-03-07 11:35:12 maybe the kernel lacks CLOCK_REALTIME someething? 2024-03-07 11:37:05 maybe its a docker issue 2024-03-07 11:43:49 ncopa: I'd do memtest first then also remove any dust and maybe reapply thermal paste 2024-03-07 11:43:58 let memtest run overnight (As long as you can) 2024-03-07 11:45:39 will https://pyropus.ca./software/memtester/ be good enough or should I do the boot memtest thingy 2024-03-07 11:47:57 i think I saw some alpine issue or mergerequest wrt memtest but i dont know where. if it was mkinitfs or aports 2024-03-07 15:23:34 is there a way to change the default dl-cdn repos urls in "abuild rootbld" ? 2024-03-07 16:30:05 found it, export mirror= 2024-03-07 16:35:14 should we do a world-rebuild for Go 1.22.1 today? I will be gone over the weekend and won't be able to cleanup build failures, and I suspect there will be a lot of them since this would be the first Go 1.22 rebuild 2024-03-07 16:37:14 are there significant changes in 1.22.1? 2024-03-07 16:48:53 Hello 2024-03-07 16:49:22 ncopa: do you know why the package lvm2-extra depends on bash and coreutils ? 2024-03-07 16:58:44 raspbeguy: lvm_import_vdo is a bash script apparently 2024-03-07 16:59:06 3e16db39083a627392784154ee98222a404ca38d 2024-03-07 17:02:42 If I understand correctly this commits makes the script compatible with POSIX bash. So I guess we could remove those dependencies right? 2024-03-07 17:03:11 *POSIX shell 2024-03-07 17:03:23 that's about lvresize 2024-03-07 19:02:55 ikke: what do you mean 2024-03-07 19:03:47 ikke: no, but we just haven't rebuild with Go 1.22 yet 2024-03-07 19:04:10 nmeum: aha 2024-03-07 19:04:24 so all the Go 1.22 stuff (e.g. CGO_ENABLE) will need patching 2024-03-07 19:04:43 nod 2024-03-07 19:06:00 I guess I will wait with the rebuild until monday, I have more time to deal with the fallout next week 2024-03-07 19:59:01 but we dont need to wait with merging go 1.22.1, right? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61727 2024-03-07 20:40:43 Any plans to adopt https://discourse.llvm.org/t/llvm-18-1-0-released/77448 2024-03-07 20:42:19 absolutely! 2024-03-07 20:42:47 .1 will be in like 2 weeks though 2024-03-07 20:43:46 will take a few days to get it all up. upgrading to .1 will be trivial after that 2024-03-07 20:43:51 no need to wait 2024-03-07 20:44:24 however, i have just started with python 3.12, i should probably finish that first 2024-03-07 20:44:55 we should have llvm18 for alpine 3.20 2024-03-07 22:37:59 Started !61796 2024-03-08 02:07:50 Hi, can anyone look at !60050, it was not marked as Draft by @SadieCat who opened the MR 2024-03-08 02:31:45 ikke: you were the one who marked it as draft, any specific reason? 2024-03-08 03:05:54 danieli: i am interesting in taking over community/erlang, and have opened !61811 2024-03-08 03:06:42 ptrc: ppc64le CI failed once, but succeeded on retry, and i guess the Draft status was not removed after that 2024-03-08 04:59:31 ptrc: usually when there are pipeline failures 2024-03-08 06:20:49 s/interesting/interested/ 2024-03-08 10:36:10 andypost[m]: thank you! 2024-03-08 18:42:47 did someone from alpine reach out to codeberg regarding https://codeberg.org/alpine/alpine-wiki ? 2024-03-08 18:51:42 https://codeberg.org/alpine/alpine-php kek APKBUOLD 2024-03-08 18:52:10 https://codeberg.org/alpine/alpine-wiki#social-network-and-contact thats bad 2024-03-08 18:57:51 all of it is atrocious 2024-03-08 19:02:40 ew 2024-03-08 20:46:06 You didn't allow me to write bullshit on alpine wiki, so I made my wiki, with blackjack and hookers 2024-03-08 20:48:35 Imo it's up to council to decide if action should be taken 2024-03-09 06:04:42 I feel like this is right on the line of making it clear that it's unofficial vs. not 2024-03-09 11:34:19 I'm not sure I understand the comment in #15712 2024-03-09 12:04:53 i understand it and consider it invalid :) 2024-03-09 12:42:50 and your reply is how I understand things, thanks 2024-03-09 12:45:57 I think the comment is about mixing testing with a stable release 2024-03-09 12:48:30 which of course is not supported, but i think that's how lots of people use packages in testing 2024-03-09 12:50:03 and was probably the reasoning behind !57204 (exception being made for moving an aport to community in 3.19, after 3.19 was released) 2024-03-09 12:51:56 I sort of understand it as mixing edge/testing with stable is easier to do than mixing edge/community with stable 2024-03-09 12:53:34 once we upgrade to python 3.12, I expect a lot of people coming with broken dependencies 2024-03-09 12:58:10 I think i have said something along those lines a while ago when lots of Python aports were moved to community before 3.19 (having those aports in community gives them a "version" that will continue to work with 3.11 after the big 3.12 rebuild) 2024-03-09 13:04:12 Anyway, i think what Simon said in #15712 about moving aports to community close to the next stable release has made quite an impression on me, which is why i am holding out on moving some aports (Coq, for example) that i think people are using in CI 2024-03-09 13:10:42 A user once emailed me after i moved a font to community, saying (paraphrase) that it was like changing date of birth 2024-03-09 13:24:11 wat 2024-03-09 13:26:50 :) 2024-03-09 13:28:49 They probably had automated scripts to install the font from testing, which stopped working after the move 2024-03-09 15:06:31 Would be useful to have /usr/bin/python3.11 and /usr/bin/python3.12. 2024-03-09 20:59:14 restarting gitlab to perform upgrades 2024-03-09 21:03:32 Back again 2024-03-10 15:55:45 kernel modules packed in initramfs should reflect in lib/modules/6.1.75-0-lts/modules.order right ? 2024-03-10 15:55:56 pls see, https://tpaste.us/z5vZ 2024-03-10 16:15:59 ok its same as in full /.modloop 2024-03-11 08:17:28 ncopa: tagged apk-tools 2.14.1, will probably abump it on edge a bit later today 2024-03-11 08:25:01 awesome! thanks! do you want me to bump it now? 2024-03-11 08:27:38 im bumping it. lets see what breaks... 2024-03-11 08:59:04 For xz 5.6, there was some discussion about amending the license in !61302 2024-03-11 09:04:48 (but xz has now been upgraded without updating the license) 2024-03-11 09:35:10 anyone can look at !61318 ? thanks 2024-03-11 09:54:49 any additional comments on !61558 otherwise I will probably move forward with it today 2024-03-11 10:04:28 nmeum: Looks good to me. Maybe longer-term, it might be beneficial to provide a script which users can run to capture {meta,useful}data (such as logs, enabled repositories, etc.), especially if that's required boilerplate they can just paste in to the issue details. 2024-03-11 10:09:52 rr !61941 : are such loongarch enablement patches needed? We don't have loongarch ci, do we? 2024-03-11 10:10:33 Ermine: it's in progress 2024-03-11 10:12:57 celie: whoops 2024-03-11 10:12:58 Ah ok 2024-03-11 10:13:26 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/72 2024-03-11 10:18:29 celie: thank you! 2024-03-11 10:19:06 duckl1ng: It should not be needed to rebuild as far I can see. at least not on x86_64 2024-03-11 10:42:00 I think we either have to fix busybox wget or revert 20c1bf07870c961d1b506e6d6861329910e2f1df 2024-03-11 10:42:30 wget https://www.netfilter.org fails 2024-03-11 10:46:38 ncopa: works for me 2024-03-11 10:49:58 Ermine: busybox wget? 2024-03-11 10:50:41 gnu wget, will check with bb wget right now 2024-03-11 10:51:16 Ermine: can you please check if GNU wget adds `Accept:` header to the request? 2024-03-11 10:51:34 details here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/15861 2024-03-11 10:52:54 ncopa: yes, it has Accept: */* 2024-03-11 10:55:51 thanks! 2024-03-11 12:34:30 nmeum: Now i remember, besides Ginkgo (indirectly through Buildah), that ppc64le linking error was also noticed in a1e7aa393ca 2024-03-11 12:36:23 oh 2024-03-11 12:36:35 so yea, probably a Go 1.22 regression 2024-03-11 12:49:26 Hmm, it seems the Ginkgo vendored in Buildah is version 1, while community/ginkgo is version 2, and version 2 does not have the ppc64le linking error 2024-03-11 13:01:56 Ah, i was wondering why lego didn't have CGO_ENABLED=0 removed, that's because it has !61147, and there was a request to exclude it from !61172 2024-03-11 13:03:08 celie: could you link the buildah build failure in #15862? 2024-03-11 13:03:49 That's in !61262 2024-03-11 13:04:24 but i took a closer look, and Buildah vendors version 1 of Ginkgo 2024-03-11 13:04:30 version 2 seems unaffected 2024-03-11 13:05:49 right, but that's not neccesairly relevant for the regression report 2024-03-11 13:06:25 Anyway, the Buildah issue was solved by not building the vendored Ginkgo, so it's not a blocker there, but might give some clues to look into 2024-03-11 13:06:50 *nod* 2024-03-11 13:17:53 xz fails to install on the armv7 CI due to a bad signature: https://gitlab.alpinelinux.org/raspbeguy/aports/-/jobs/1299534 2024-03-11 13:19:03 Not sure if retrying the pipeline will solve it, or if xz needs a pkgrel bump after the earlier revert 2024-03-11 13:47:01 i'd like to tag edge snapshot once the builders are idle 2024-03-11 13:54:42 celie: yeah, reverting requires a new pkgrel 2024-03-11 14:05:52 !61964 2024-03-11 14:09:41 Was pkgrel 1 already used before? 2024-03-11 14:09:56 no, it was 0 before 2024-03-11 14:10:59 It was reverted, and then upgraded again with the same pkgrel=0 2024-03-11 14:13:51 So happens armv7 is the first to get the bumped xz, so https://gitlab.alpinelinux.org/raspbeguy/aports/-/jobs/1299534 can now be retried 2024-03-11 14:53:03 sorry about that... 2024-03-11 16:05:12 nmeum: we could maybe ask mick_ibm to help us with the ppc64le issues? https://gitlab.alpinelinux.org/alpine/aports/-/issues/15862 2024-03-11 16:07:49 mick_ibm: do you have a user account to our gitlab so we can ping you there and maybe assign ppc64le related issues to you? 2024-03-11 16:10:20 ncopa: mick created an account the other day 2024-03-11 16:10:39 mtarsel 2024-03-11 16:21:14 yes i have a gitlab account @mtarsel 2024-03-11 16:24:21 awesome! thanks! 2024-03-11 16:27:22 np :) 2024-03-11 16:31:20 i have another weird issue with ppc64le: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1296617 it passes on all other architectures 2024-03-11 16:32:37 i was not able to reproduce it in my lxc container, but it happens in CI, under docker. So I suspect that this may be something introduced musl 1.2.5, maybe a new syscall is used and docker's libseccomp denies it 2024-03-11 16:32:48 just a wild guess, but it needs investigation 2024-03-11 16:36:33 this was on my radar for python3, also a wild guess: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/main/python3/APKBUILD#L105 2024-03-11 16:36:44 or maybe a piece of the puzzle 2024-03-11 16:42:41 oh, that looks a bit scary 2024-03-11 17:18:20 @ncopa have you hit the basename() API issues yet with musl 1.2.5 ? 2024-03-11 17:18:37 I have fixed bunch during last yocto upgrade cycle but not all 2024-03-11 19:45:05 khem: hi! not bumped into that yet 2024-03-11 19:45:17 link? 2024-03-11 19:46:18 ncopa: https://git.musl-libc.org/cgit/musl/commit/?id=725e17ed6dff4d0cd22487bb64470881e86a92e7 2024-03-11 19:47:23 this has caused several apps fail to build but maybe it was latest clang that was more fussy about it because it was now finding that signature of function is different and hence break builds 2024-03-11 19:47:32 it finds a genuine issue though 2024-03-11 19:48:45 resulted in fixes like - https://sourceware.org/git/?p=elfutils.git;a=commit;h=a2194f6b305bf0d0b9dd49dccd0a5c21994c8eea 2024-03-11 19:49:58 oh right, that one. I kinda expected that break builds yes 2024-03-11 19:51:49 indeed. its good to have those fixed 2024-03-11 19:57:42 I am still carrying lot of fixes for this issue in yocto locally, see - https://github.com/YoeDistro/poky/compare/9d58234ef177026f67c15118c37edc99a4e68e36...5b1fcb38a4dad7f141a4eb1123522c5ec4666541 2024-03-11 20:07:07 wow. this will help us a lot 2024-03-11 20:07:23 we will build world from scratch in April something 2024-03-11 20:07:39 maybe we should try get the builders up early because there will bemoan issues to fix 2024-03-11 20:10:53 h 2024-03-11 20:11:15 I'm looking for info about license file but I can't find that in alpine wiki 2024-03-11 20:11:50 I can't find info about adding license file in APKBUILD source variable 2024-03-11 20:12:24 (in case there is not a -doc subpackage) 2024-03-11 20:13:25 (because existing packages examples show no license file shown in source variable when there is a -doc subpackage) 2024-03-11 20:13:31 Any ideas about that? 2024-03-11 20:24:25 ncopa: im taking a look now. i was going to start with community/opencv issue on ppc64le since its the oldest (3 months ago) unless that golang is higher priority. im focused on another bug right now (not alpine related) but can work 1 of the issues into my rotation now :) 2024-03-11 20:25:47 goimapnotify, buildah, or opencv issues for ppc64le 2024-03-11 20:29:51 also, I still get remote: HTTP Basic: Access denied. The provided password or token is incorrect or your account has 2FA enabled and you must use a personal access token instead of a password. 2024-03-11 20:30:17 but I actually use a personal access token, I dont' understand 2024-03-11 20:30:22 any ideas about that? 2024-03-11 21:01:19 timlegge: is there a reason perl packages ignore the existing CFLAGS `export CFLAGS=$(perl -MConfig -E 'say $Config{ccflags}')`? 2024-03-11 21:05:32 s390x runner seems out https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1299930 2024-03-11 21:06:07 Funny, it sends a message to gitlab that it connot connect to gitlab :P 2024-03-11 21:06:26 oh wait it is 2024-03-11 21:06:36 well 2024-03-11 21:06:42 i should learn how to read some day 2024-03-11 21:07:14 There is some network flakyness from time to time 2024-03-11 21:07:36 It seems to be building now: https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1300070 2024-03-11 21:08:39 And finished 2024-03-11 21:10:14 mick_ibm: no opinion which you prio 2024-03-11 21:10:59 ok 2024-03-11 21:15:34 =25 2024-03-11 22:09:00 so i guess CRLs will start updating at least weekly starting march 15. 2024-03-11 22:15:36 boost asio is not packaged ? 2024-03-11 22:16:06 there is asio pkg in community/ 2024-03-11 22:18:32 botan could make use of asio 2024-03-11 22:26:51 if things are on super breakage/upgrade mode, then main/bridge-utils is deprecated in favour of iproute2 2024-03-12 00:46:03 any reason why cgit is build against older version of git ? 2024-03-12 01:08:09 ikke: thanks 2024-03-12 08:51:23 ncopa: I would have just reported the ppc64le issue to upstream go 2024-03-12 08:53:00 I just need access to a ppc64le lxc to gather the needed information 2024-03-12 09:05:03 fabled you maintain Plymouth in Alpine, have you actually been able to get it running with mkinitfs? I can't seem to find instructions to do so 2024-03-12 09:07:10 iirc mkinitfs only supports busybox fbsplash splashscreens 2024-03-12 09:08:52 yeah I thought so, so is there any way to get it running currently? 2024-03-12 09:09:42 I was hoping to use booster for this but it doesn't seem to support Plymouth either atm 2024-03-12 09:10:09 nmeum: seens like you have an ppc64le lxc on 172.16.15.42 2024-03-12 09:10:49 oh indeed 2024-03-12 09:11:27 great, I will report it to Go upstream later today then (CC: mick_ibm) 2024-03-12 09:22:42 PureTryOut: get what running? mkinitfs with Plymouth or with fbplash? (booster doesn't support any bootsplash things right now) 2024-03-12 09:23:43 for fbplash in mkinitfs you just need to set the splash kernel parameter https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in?ref_type=heads#L811-L838 2024-03-12 09:29:14 nmeum: I never mentioned fbsplash, you did, so obviously I'm talking about getting Plymouth running πŸ˜‰ 2024-03-12 09:29:38 it has been packaged in community for a while but I've never been able to get it to work 2024-03-12 10:32:22 Ariadne: I'd like to bump gcc snapshot. Do you think you could walk me through how to do so? 2024-03-12 10:40:10 nevermind, i think i got it 2024-03-12 10:51:06 ncopa: be careful if you're thinking of moving to gcc-14, I've heard they're changing the default to error on some categories of what are currently warnings 2024-03-12 10:51:29 so some builds will definitely break with it and will need fixing 2024-03-12 10:59:24 I am reading https://gcc.gnu.org/gcc-14/porting_to.html as we speak 2024-03-12 11:16:26 it's good that they fully document it, at least 2024-03-12 11:21:27 i think clang already does a lot of this? 2024-03-12 11:25:13 Haven't seen clang documenting such stuff, but afaik they track gcc behaviour 2024-03-12 11:33:02 i've been dealing with at least some of these failures when testing clang 2024-03-12 16:39:20 !60430 and !62031 have gotten the thumbs up from their respective maintainers 2024-03-12 16:42:51 ncopa: https://wiki.gentoo.org/wiki/Modern_C_porting 2024-03-12 16:42:53 but i think ncopa was referring to gcc snapshot for released versions (tracking stable branches), although maybe I'm wrong 2024-03-12 16:42:57 although it would be good if alpine started testing gcc 14 anyway as it's out soon 2024-03-12 16:43:45 https://gitlab.alpinelinux.org/alpine/alpine-gcc-patches 2024-03-12 17:04:22 Hey there. Hopefully quick question if anyone has the time. Trying to install a custom kernel on alpine, but am falling short. I have the '/lib/modules/custom' staged, have 'vmlinuz-custom' under boot. Generally I am familiar with importing on various distros, primarily using dracut/grub. I've been troubleshooting for a few days but cant seem to get appropriate answers, even from offline LLMs. Does anyone have advice here? 2024-03-12 17:05:09 what's the actual issue here? 2024-03-12 17:05:24 as in, do you get any error? what's the outcome you're getting? 2024-03-12 17:06:22 Seems all my attempts at generating the initramfs-custom (initramfs for custom kernel) are falling short / unbootable / incomplete generation 2024-03-12 17:06:38 The actual error, give me a second 2024-03-12 17:07:42 Tried with installing dracut as well as the mkinitfs command, where i ran `mkinitfs -o /boot/initramfs-custom` 2024-03-12 17:08:46 hmm, are you passing the version parameter to mkinitfs? 2024-03-12 17:09:09 Believe i am doing something fundamentally silly, and if this needs to be moved elsewhere, please let me know. the last thing i want to do is disrupt this channel 2024-03-12 17:09:33 and yes i was passing the version. in this case i was just putting instead of the KVER, but its version 6.6.18 2024-03-12 17:10:02 or is there an actual param i need to pass instead? my mkinitfs very well could be incomplete 2024-03-12 17:10:35 technically this would be better suited for #alpine-linux rather than #-devel 2024-03-12 17:10:48 like with dracut, id typically run 'dracut --kver 6.6.18', but i am a bit sloppy with mkinitfs 2024-03-12 17:11:15 Ah understood. I can bring it up there if that's preferred. apologies for the noise here 2024-03-12 17:11:35 yeah, let's move there 2024-03-12 17:12:17 Sounds good, thank you! 2024-03-12 17:14:17 celie: Do you happen to know if overwriting CFLAGS in perl packages (by the generator) is on purpose? We have a linting rule that warns when ignoring the existing CFLAGS value 2024-03-12 17:15:14 I think it has something to do with Perl modules wanting to be compiled with the exact CFLAGS that the Perl interpreter used 2024-03-12 17:16:27 Not sure if it has to be really exact, but i think some modules will complain if there's a difference, but i don't have all the details on hand atm 2024-03-12 17:18:12 ok 2024-03-12 19:27:55 could alpinelinux be upgraded to 3.x in about->preferences->general - Firefox Upgrades 2024-03-12 19:42:13 how does one keep track of latest timepps.h in main/chrony/APKBUILD ? 2024-03-12 19:44:26 maybe build pps-tools-dev pkg, and cp it during build (if possible) 2024-03-12 20:28:23 yeah gcc 13 snapshot. I want to test if it solves the armv7 llvm issue 2024-03-12 20:54:29 is alioth.debian.org still a thing 2024-03-12 20:54:48 might have moved to salsa 2024-03-12 21:27:13 omni: I tuned !61981 but somehow s390x fails in CI, maybe options="net" required? 2024-03-12 21:27:53 maybe better to disable it meantime as it fails all builders 2024-03-12 21:28:43 Neither builders nor CI use rootbld, so options="net" does nothing 2024-03-12 21:29:49 thanks, then something different 2024-03-12 21:35:25 ikke: any idea what's wrong with DNS in RV64 CI https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61375#note_383867 2024-03-12 21:35:47 it resolves non-existing address and test fails 2024-03-12 22:03:15 my guess is that it uses google or cloudflare dns or some dns service that helpfully resolve and redirect non-existing addresses to their services 2024-03-12 22:05:48 google and cloudflare do not do that 2024-03-12 22:40:53 just a thought, would it be a good idea to publish checksums of current APKINDEX.tar.gz for all repos ? or its already done 2024-03-13 06:35:22 btw this strange DNS resolution happening only in CI and only rv64, probably test should be changed from random domain to .invalid 2024-03-13 07:47:44 ncopa: i'll probably go ahead and implement the version epoch thing in apk-tools. i think the only sane character to use instead of : for filenames is +. but i'm wondering if the character should be translitterated, or if the actual epoch separator in version string should be also + ? 2024-03-13 07:49:45 thats a good question. I dont know tbh 2024-03-13 07:50:22 seems both dpkg and pacman use ':' as epoch separator, so probably better go with that in version number 2024-03-13 07:51:06 does pacman use : in filename as well? 2024-03-13 07:51:12 interesting in debian the docs say epoch is heavily discouraged. and before using it permission should be asked from debian-devel 2024-03-13 07:51:35 I wonder why that is 2024-03-13 07:53:08 arch also uses : in filename 2024-03-13 07:53:22 reading about it, I wonder if it really is a good idea to introduce epoch 2024-03-13 07:53:55 i think its just annoying/confusing for user if there's extra 1: or 2: in front of the version 2024-03-13 07:54:58 its more than that 2024-03-13 07:55:24 https://chat.openai.com/share/b372dfdd-31e6-4a86-8430-66536e43945d 2024-03-13 07:56:38 i think i will try avoid use of epoch in alpine 2024-03-13 07:58:08 "epochs add complexity, are irreversible, can lead to confusion in version comparison, create potential issues with upstream compatibility, and are intended as a last-resort solution for versioning problems." 2024-03-13 07:58:19 yes 2024-03-13 07:58:36 so i suppose alpine can make policy decision to not allow epoch? in that case we can just keep the ':' in filename too? 2024-03-13 07:58:50 that could work 2024-03-13 07:59:07 though, "apk upgrade -a" allows things to work when epoch is dropped 2024-03-13 07:59:24 that is was about to say 2024-03-13 07:59:33 apk has something debian does not 2024-03-13 07:59:55 apk works differently and tracks the global state 2024-03-13 08:00:18 with apk you can do `apk upgrade -a`. I don't think you can do that with dpkg 2024-03-13 08:00:39 which will force downgrade packages that no longer exist in index 2024-03-13 08:02:56 my point is: do we reallky need epoch when we have apk upgrade -a? 2024-03-13 08:03:20 in alpine, no. but seems other distroes want it 2024-03-13 08:04:26 is this the place where it was discussed? https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10533 2024-03-13 08:07:15 also https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10830 2024-03-13 08:09:25 also in https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10972 2024-03-13 08:18:02 do you have a link to the debian docs that says its use is heavily discouraged? 2024-03-13 08:20:05 found it 2024-03-13 08:21:00 for record here: https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly 2024-03-13 08:21:58 they do encourage the even uglier "1.1+really1.0" to indicate that maintainer reverted to older version 2024-03-13 08:43:52 vkrishn: does the alpine version in firefox really matter? afaict it's only used for printing it there and in the About wint 2024-03-13 08:43:54 window* 2024-03-13 09:02:51 ncopa: i assume you have no objection for the optional "~commithash" version component just before -r0 component? 2024-03-13 09:40:50 ncopa: created https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/156 for the commit hash 2024-03-13 09:43:45 fabled: I tried to document the version specification https://gitlab.alpinelinux.org/alpine/go/-/raw/master/version/doc.go 2024-03-13 09:45:18 @ikke: the letter can exist only in one spot, just before suffix, so something like: 2024-03-13 09:45:47 oh, wait, need to reread my ebnf skills 2024-03-13 09:47:31 at least "[ letter, digits ]" -> "[ letter ]" 2024-03-13 09:47:56 yes, there are currently alpine packages with letter followed by number, but those are technically invalid 2024-03-13 09:48:10 no objection to commit hash. only question about how they are compared 2024-03-13 09:49:46 seems like it is string compare? https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/tt-version-commithash/test/version.data#L737 2024-03-13 09:53:41 yes, its string compare 2024-03-13 09:53:56 alternative would be to consider them always equal, but not sure if that helps 2024-03-13 09:54:44 im just thinking if/how it can be abused :) 2024-03-13 09:54:50 That's unpredictable though 2024-03-13 09:55:05 if it is an actual commit hash, yes 2024-03-13 09:56:10 im thinking: tcptraceroute 1.5~b7 2024-03-13 09:56:14 We could just make it a text entry that can contain any letters and keep the string sort 2024-03-13 09:56:48 Now it is 0-9a-f. But could make it 0-9a-z 2024-03-13 09:57:24 hmm 2024-03-13 09:57:40 a commit hash is technically a hexadecimal number 2024-03-13 09:57:48 an id number 2024-03-13 09:57:58 not inteded for version compare 2024-03-13 09:58:24 so we could treat it as a "tag" only, and exclude it from the comparison 2024-03-13 09:58:51 or, we could allow 0-9a-z and do string sort 2024-03-13 09:59:12 which could be handy for ["letter", "digit"] case 2024-03-13 09:59:49 Isn't that already supported 2024-03-13 10:00:01 > yes, there are currently alpine packages with letter followed by number, but those are technically invalid 2024-03-13 10:00:32 it is supported but if we allow ~ then we could drop that support 2024-03-13 10:01:08 fabled: i think your current implementation is good. https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/156 2024-03-13 10:01:08 Is there a reason to do so? 2024-03-13 10:02:14 i'd say to avoid confusion for things like opensmtpd 7.4.0p1 2024-03-13 10:02:22 which technically should be _p1 2024-03-13 10:03:26 fabled: i think allowing only hex is strict and good. and we can expand it later if needed. its always more difficult to restrict afterwards 2024-03-13 10:04:01 ikke: see https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10972#note_381644 2024-03-13 10:05:06 i think allowing is fine, it just makes it easy to confuse the meaning of 2024-03-13 10:08:23 community/librasterlite2 1.1.0b1 uses wrong suffix 2024-03-13 10:09:07 it should be _beta 2024-03-13 10:10:32 i wonder if we should make abuild reject , and have an option to allow it. eg options="allow-version-suffix" 2024-03-13 10:11:27 and let abuild give an explanation how it is supposed to be 2024-03-13 10:15:32 or at least give a warning on [abp][0-9] suffixes, (did you mean _alpha, _beta, _p?) 2024-03-13 10:16:10 lets start with a warning 2024-03-13 10:22:02 oh, we already do that 2024-03-13 10:45:10 ptrc: no, but do if it can be changed easily without issues, then yes 2024-03-13 10:46:04 is it firefox.desktop file ? 2024-03-13 11:10:31 hmmm, its not in esr, so 'not important', hmmm, did not notice setup-desktop installs firefox and not firefox-esr 2024-03-13 11:18:05 btw, un-installing firefox (in xfce) and adding firefix-esr breaks link in bottom-launcher toolbar 2024-03-13 11:32:28 looks like its comming from distribution.ini ( easy to edit ) 2024-03-13 13:05:12 anyone has experience with building mesa? I noticed that upgrading v3.19 to edge it loses vp9 codec support, I rebuilded 23.3.6 based on edge, and it works again https://tpaste.us/j4Vv so I suppose that is the upgrade to 24.0.2 what broke it 2024-03-13 13:29:17 hi all, will land musl 1.2.5 in 3.19? https://github.com/koverstreet/bcachefs-tools/issues/213 2024-03-13 13:29:48 no. musl-1.2.5 will be included in alpine 3.20 (May this year) 2024-03-13 13:30:51 we coudl consider backporting pwritev2 support if needed 2024-03-13 13:31:05 that would be great :) 2024-03-13 13:31:21 i'm trying to build bcachefs-tools 1.6.4 2024-03-13 13:36:37 can you please create an issue and explain why we need to backport it, and why it cannot wait for alpine 3.20 https://gitlab.alpinelinux.org/alpine/aports/-/issues 2024-03-13 13:36:54 so I have something to mention in the commit message on why it was done 2024-03-13 13:51:57 it seems that it works just explicity adding it https://tpaste.us/D7J0 2024-03-13 14:02:55 !62092 2024-03-13 14:26:07 hmm... any problem enabling all codecs as psykose suggests? 2024-03-13 14:51:32 vkrishn: it's gonna have to be edited with every single alpine release 2024-03-13 14:51:44 not even mentioning that i'm pretty sure it can't really be "edge" 2024-03-13 18:09:18 "hmm... any problem enabling..." <- That would be amazing 2024-03-13 18:09:30 Nulo: Yes, via matrix even 2024-03-13 18:52:03 ptrc: if abuild is aware of build version, then sed(change) it after install, it can be "edge" but maybe not "Edge" 2024-03-13 20:11:40 andypost[m]: thank you 2024-03-13 21:03:40 is gdbus packaged ? seems dbus-glib is deprecated (homepages says, object model is rubbish) 2024-03-13 21:06:24 oh, its in glib 2024-03-13 21:09:24 looks like removing dbus-glib would not be easy -> required by 29pkgs 2024-03-13 21:10:12 install size 160K vs. 3.7Mb 2024-03-13 21:16:36 main/daq should be libdaq (cough, sounds strange though), maybe libdaqs 2024-03-13 21:20:25 another, main/confuse should be libconfuse 2024-03-14 00:00:23 isc-dhcp had its EOL in 2022, seems it not that easy to move it to community and replaced by kea 2024-03-14 02:15:35 why is getting so hard to switch to ipv6 completely ? 2024-03-14 02:17:08 atleast every human and their devices can then have a fixed ip and easy to track by AIs ;) 2024-03-14 02:18:36 vkrishn, that's underestimating the competence of some ISPs 2024-03-14 02:18:47 DHCPv6 \o/ 2024-03-14 02:40:23 vkrishn, v6 lets you pick if you want that. see temporary addresses 2024-03-14 02:43:04 Also your web trojan modern app will not track you by IP address, but by the info that the webbrowser is leaking 2024-03-14 08:28:19 dnsdist 1.9.1 is releasing today, and i'll be abumping the port. the only reason for the release is bumping the version of a dependency (quiche) because it had CVEs 2024-03-14 08:28:26 the aport for dnsdist does not have any of that code 2024-03-14 08:28:35 should i still add secfixes to APKBUILD, or not? 2024-03-14 08:55:05 Habbie: why is the rebuild necessary, ABI change? 2024-03-14 08:55:31 the rebuild is necessary because -we- can't ship new deb/rpm packages without tagging a new version 2024-03-14 08:55:41 it is entirely useless busywork for many distributions that ship dnsdist 2024-03-14 08:55:50 freebsd just bumped libquiche.so and is done, functionally speaking 2024-03-14 09:28:11 seeing the commits just made to aports, is loongarch64 going to be a supported architecture soon? 2024-03-14 09:29:20 seems so 2024-03-14 09:30:18 interesting 2024-03-14 09:30:35 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/72 2024-03-14 09:34:09 im hoping that we can get a riscv64 stable release as well 2024-03-14 09:37:48 that'd be great! 2024-03-14 09:42:06 i am currently stuck with python 3.12 rebuilds 2024-03-14 09:42:17 py3-lxml fails and I have no idea how to fix it 2024-03-14 09:43:16 https://tpaste.us/b1kD 2024-03-14 09:54:55 oh, they use cython... 2024-03-14 09:55:00 Is it expected to use packages from python3.11? 2024-03-14 09:59:29 ikke: according to their home pages, it doesn't depend on other python packages 2024-03-14 10:02:09 I mean, in the buildlog, it refers to /usr/lib/python3.11 2024-03-14 10:19:26 hum 2024-03-14 10:19:46 also cython 0.29 2024-03-14 10:23:57 ah. its the added py3-html5lib that needs to be rebuilt first 2024-03-14 11:03:28 alright, only a single test fails now: https://dpaste.com/F9J3RTZWJ.txt 2024-03-14 11:08:11 and foudn a fix upstream. progress! \o/ 2024-03-14 11:08:28 nice 2024-03-14 11:17:37 I also have this which im currently ignoring, but will have to deal with eventually: https://github.com/dgibson/dtc/issues/123 2024-03-14 11:18:35 right now i bumped in to a test failure in py3-future that is verifying that an exception is caught before C stack is overflowed 2024-03-14 11:19:21 which is slightly worrying 2024-03-14 13:12:20 By applying the patch from the pull requests mentioned in !61506, i managed to get testing/opa to build, but the patch is a big one, so i've not imported it into aports 2024-03-14 13:12:44 !62143 should allow the x86_64 builder to upload testing 2024-03-14 13:37:52 thank you cely! 2024-03-14 13:38:13 You're welcome 2024-03-14 13:55:10 how could I increase the size of root tmpfs in diskless mode? it seems to be half ram by default and I'd like to increase it by a gig 2024-03-14 13:57:21 rootflags kernel cmdline 2024-03-14 13:57:46 which probably means you need to adjust the configration on the boot medium 2024-03-14 13:58:24 thanks! 2024-03-14 13:58:57 rootflags=size= 2024-03-14 13:59:44 and that would be in bootloader configuration on the boot medium, correct? 2024-03-14 14:00:01 yes 2024-03-14 14:00:16 thanks 2024-03-14 14:01:43 ncopa, https://gitlab.alpinelinux.org/alpine/aports/-/issues/15875 2024-03-14 15:21:36 indy: thanks! I saw something about some followup to that syscall in musl, i dont remember where I saw it. Maybe IRC 2024-03-14 15:22:18 in other news, I have now re-built all packages in main for 3.12 (except kea and dtc) 2024-03-14 15:22:45 How did you solve the lxml issue? 2024-03-14 15:23:38 cely: https://tpaste.us/paNw 2024-03-14 15:24:19 i think i found the patch in upstream git 2024-03-14 15:24:36 Ok, thanks 2024-03-14 15:24:56 maybe I should push what I have to the python 3.12 draft MR 2024-03-14 15:25:04 in case someone else whats to help out 2024-03-14 15:25:52 I was wondering if the fix involved building with Cython 3 instead of 0.29 2024-03-14 15:25:59 hum only kstars is failing on edge builder now 2024-03-14 15:26:02 it probably was 2024-03-14 15:28:22 I think lxml upstream is building the 5.x branch with Cython 3 2024-03-14 15:28:37 yes. and I upgraded cython to cython 3 2024-03-14 15:28:53 Ah, okay 2024-03-14 15:29:13 ncopa: I was looking at kstars 2024-03-14 15:29:17 though, got distracted 2024-03-14 15:29:19 So, it will be a Python 3.12 and Cython 3 rebuild 2024-03-14 15:37:14 yes 2024-03-14 15:37:23 here is the WIP: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57355 2024-03-14 15:37:59 need to fix dtc and kea and then I can move on to community 2024-03-14 15:44:59 I guess kstars is some floating point difference 2024-03-14 15:45:13 thats what it looks like 2024-03-14 15:45:26 QTest::newRow("NGC4535-3-FOCUS") << "ngc4535-autofocus3.fits" << FITS_FOCUS << 126 << 1.254911; 2024-03-14 15:47:24 maybe we simply just disable that specific test? 2024-03-14 15:47:43 Yeah, sounds like the best option to me 2024-03-14 15:47:54 I guess we should report it 2024-03-14 15:51:13 would be good yes 2024-03-14 16:12:00 alright, have a fix for kea also. python 3.12 rebuild of main is complete (unless I missed someething) 2024-03-14 16:25:56 curious, kstars is 3.6.9, but the aports renames the builddir to 2.6.9 2024-03-14 16:26:07 or rather, the version downloaded 2024-03-14 16:26:38 Ok, apparently upstream bug in the source 2024-03-14 16:45:46 !62155 2024-03-14 16:49:34 i think we can just merge it, as it blocks the builder 2024-03-14 16:49:48 thanks! 2024-03-14 17:23:43 ncopa: builders are idle now 2024-03-15 00:59:00 just a thought, is it possible to move codes like https://tpaste.us/ggrv in separate repo, eg. aports-misc, with no branch folder, eg, gpsd/timepps.h 2024-03-15 02:59:16 apache-mod-auth-openidc 2.4.15.5 tarball has been deleted, and it is blocking the builders, so i've opened !62186 2024-03-15 07:45:44 hi all, any example of building rust cdylib libxxx.so and packaging it? 2024-03-15 07:51:19 morning. and now the builders are no longer idle. i missed the window.. :-/ 2024-03-15 07:53:41 πŸ˜₯ 2024-03-15 07:54:12 shouldnt be too difficult to get there again 2024-03-15 07:54:43 We probably have to disable element-web on armhf 2024-03-15 07:55:14 It was already on armv7 according to cely 2024-03-15 07:56:26 Do the builders have to do something when you tag a snapshot? 2024-03-15 07:57:15 Build images 2024-03-15 07:57:22 minirootfs 2024-03-15 07:57:28 Ok 2024-03-15 07:57:47 seems like biuld-edge-riscv64 is emulated also 2024-03-15 07:59:05 cely: do you think you could help with modernizing py3-xlib? 2024-03-15 08:01:44 I'm about to go AFK, let me see if i can do something quick 2024-03-15 08:12:57 oh, dont worry if you are busy 2024-03-15 08:13:38 thank you! 2024-03-15 08:14:46 Oops, you've merged it, but i forgot to bump pkgrel 2024-03-15 08:15:30 my bad :) 2024-03-15 08:15:52 i think its fine. it was for my python 3.12 rebuild 2024-03-15 08:16:10 Yes, i figured 2024-03-15 08:16:31 so it will be rebuild anyways soonish 2024-03-15 08:17:40 but thanks. it did unblock the rebuilds 2024-03-15 08:17:57 That's good, you're welcome 2024-03-15 08:47:10 anybody has idea why py3-virtualenv test fails with python 3.12? https://tpaste.us/wxKX 2024-03-15 08:47:21 adding py3-setuptools to makedepends or checkdepends does not solve it 2024-03-15 09:21:18 idle! im tagging! hold you pushes for a few mins 2024-03-15 09:27:05 tagged 2024-03-15 09:37:44 maribu:matrix.org: I think your message isn't getting over to the IRC side (it doesn't appear on irclogs.a.o, i can see it as this client is on Matrix too) 2024-03-15 09:38:32 Maybe you need to re-identify to Nickserv 2024-03-15 09:40:35 (maribu's message: "I guess the intel-ucode update should be backported. Is there any script that can automate the creation of backport MRs?") 2024-03-15 10:03:30 Not aware of any 2024-03-15 12:25:21 maribu:matrix.org: You're welcome, however your message is still not appearing on irclogs.a.o 2024-03-15 13:00:30 I think a channel mode was added recently that made it necessary for you to be identified to Nickserv to speak 2024-03-16 12:20:19 Does anyone have huge initrds generated since ~6.7-6.8 and later? 2024-03-16 12:20:59 I usually build my own custom kernel and thought it might be on my side only but also linux-edge creates a huge initrd which easily eats the 512M allocated for /boot 2024-03-16 12:21:48 In fact, it runs out of space, while previous versions only use ~60M at most 2024-03-16 12:23:14 caskd: I recall some debugging symbols being enabled that increased the kernel size 2024-03-16 12:23:33 Not sure if it was around that time though 2024-03-16 12:24:29 well, 6.8 surely behaves like that 2024-03-16 12:25:45 On my laptop the /boot is 44M 2024-03-16 12:26:01 oh wait what the heck 2024-03-16 12:26:06 nvidia firmware 2024-03-16 12:27:01 On my laptop I'm using lts though 2024-03-16 12:27:32 well, i found the reason 2024-03-16 12:27:37 nod 2024-03-16 12:27:43 somehow the nvidia firmware gets included in the initrd 2024-03-16 12:27:53 which is huge and not required 2024-03-16 12:28:02 O_o 2024-03-16 12:28:10 cat /etc/mkinitfs/mkinitfs.conf 2024-03-16 12:28:38 features="ata base lvm cryptsetup cryptkey ext4 kms btrfs nvme keymap kms mmc scsi usb virtio" 2024-03-16 12:29:21 all previous versions don't include it 2024-03-16 12:29:26 both upstream and my self-builts 2024-03-16 12:29:35 where in the initramfs are the nvidia drivers? 2024-03-16 12:29:49 /lib/firmware/nvidia 2024-03-16 12:30:00 wait that's firmware 2024-03-16 12:30:27 ./lib/modules/6.8.1-0-edge/kernel/drivers/gpu/drm/nouveau 2024-03-16 12:30:34 oh is this because nouveau uses them now? 2024-03-16 12:30:56 oh yeah 2024-03-16 12:31:17 it references the firmware in the modinfo 2024-03-16 12:31:29 so i guess mkinitfs pulls that and includes it 2024-03-16 12:31:49 that's unexpected at best... 2024-03-16 12:33:53 oh wait, but older versions also reference it 2024-03-16 12:39:05 https://files.catbox.moe/m7uc2f 2024-03-16 12:39:11 here's the diff of the 2 initrds 2024-03-16 12:46:30 okay so, the 6.8 has new firmware 2024-03-16 12:46:46 diff'd the modinfo and it shows the new files that are huge 2024-03-16 12:50:10 well, this is awkward as i think most people have linux-firmware installed and as per most recommendations no one excepts that much to be crammed in a initrd 2024-03-16 12:50:37 as most info online for beginners and otherwise point that 512M should be more than enough 2024-03-16 12:56:04 seems like the blobs are mostly identical so a simple workaround would be to compress them and unpack? 2024-03-16 12:56:34 or to compress the entire initrd 2024-03-16 13:01:21 oh yeah 2024-03-16 13:01:22 okay 2024-03-16 13:01:32 so in firmware, the files are symlinked 2024-03-16 13:01:45 but during cpio creation the files are dereferenced 2024-03-16 13:01:55 negating the space savings 2024-03-16 13:02:04 and creating a bloated cpio archive 2024-03-16 22:01:45 skarnet: ur website could be down 2024-03-16 22:03:16 worksforme 2024-03-16 22:09:04 vkrishn: works for me as well 2024-03-16 22:12:22 yes, thanks, seems cannot access from my current ip, rechecking my firewalls 2024-03-16 22:23:47 git.s.o works ok, so problem solved 2024-03-17 15:44:18 yuzu is shutdown, this aport maybe could close !48261 2024-03-17 23:35:44 skarnet: can i get APKBUILD for tipidee if possible ? 2024-03-18 07:21:36 vkrishn: yeah I'll package it soon 2024-03-18 09:34:43 I don't think your messages are getting over to IRC 2024-03-18 09:35:18 You can check them here: https://irclogs.alpinelinux.org/%23alpine-devel-2024-03.log 2024-03-18 09:37:48 This probably has something to do with the +M mode set on this IRC channel, which only allows people who are identified to Nickserv to send messages 2024-03-18 09:38:47 However, as your question is about risc-v, maybe you can try #alpine-riscv64 (which doesn't seem to have +M set) 2024-03-18 11:16:31 cely: was that maribu again? 2024-03-18 11:34:13 @ikke: No, that was "Ingwie Phoenix" this time. I treat the matrix bridge now as "read-only" and will write from IRC directly :) 2024-03-18 11:36:53 I removed the +M for now, so messages should at least appear again 2024-03-18 11:45:26 Thx :) It is a pity that the matrix bridge doesn't implement error reporting with a useful hint how to fix the issue. (And I'm not sure if I really was just to stupid or whether it was an issue with the Matrix Bridge that I could identify to NickServ via Matrix, but still wasn't seens as maribu in this room when posting from Matrix.) 2024-03-18 11:46:23 Strange. Now I do appear as maribu even in the IRC log despite using the Matrix bridge. 2024-03-18 11:47:54 11:42 -- Guest3075 is now known as maribu 2024-03-18 12:04:19 I did reidentify with NickServ from Matrix after having identified with NickServ when directly using IRC. Maybe this "turning it off and on again" did the trick. 2024-03-18 15:46:45 v4l2loopback-src kernel-hook is failing. Known? 2024-03-18 15:47:03 implicit declaration of function 'strlcpy' 2024-03-18 15:57:23 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-03-18 16:00:08 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-03-19 01:24:00 ikke: You've assigned #15884 to me, but there is something not quite right with it 2024-03-19 01:24:24 Erlang 26.2.3-r1 is only available on Edge 2024-03-19 01:24:43 So, this is very likely a case of mixing Edge with 3.18 2024-03-19 04:57:00 "I may have a theory about what's..." <- No, I did not. I just contacted nickserv with register/identify. Will give it a shot! 2024-03-19 06:46:54 some time ago, jdk.java.net used to offer "*.musl_bin.tar.gz" tarballs and called them "for alpine". these are apparently no longer offered. is there a story behind this? 2024-03-19 06:47:24 (they were under Early Access) 2024-03-19 08:02:45 According to https://wiki.openjdk.org/display/Build/Supported+Build+Platforms the Alpine-musl builds are maintained by SAP -> https://sap.github.io/SapMachine/ does seem to offer sapmachine-jdk-21.0.2_linux-x64-musl_bin.tar.gz etc 2024-03-19 08:28:23 maybe they dropped musl support? you'll have to ask SAP 2024-03-19 08:58:25 You're lying, Java is portable! 2024-03-19 09:32:18 portable != supported 2024-03-19 09:32:52 portable = multiple debug target 2024-03-19 09:45:14 Yeah ncopa, that's the joke ^^ 2024-03-19 09:47:42 sorry :) 2024-03-19 09:48:49 na :) 2024-03-19 15:03:09 hello, I am a new user (on wsl2) and I think I am having a bug in ash, doing cd ~ takes me to my user's home directory, but doing it again result an error: here is the output: https://paste.debian.net/1311258/ 2024-03-19 15:04:48 grep ali /etc/passwd 2024-03-19 15:04:50 please 2024-03-19 15:04:57 okay, 2024-03-19 15:05:22 ali:x:1000:1000:Linux User,,,:./ali:/bin/ash 2024-03-19 15:05:54 btw, it is an issue because when I did add `bin` directory to my path like this: PATH=~/bin:$PATH I got a weird output 2024-03-19 15:06:05 your homedir should not be ./ali 2024-03-19 15:06:07 it should be /home/ali 2024-03-19 15:06:14 https://paste.debian.net/1311262/ 2024-03-19 15:06:16 also, this question belongs in #alpine-linux 2024-03-19 15:06:22 oh okay. 2024-03-19 15:06:31 brb 2024-03-19 15:30:53 q: are "we" trying to patch these types of errors out -> "warning: `iwconfig' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211 2024-03-19 15:31:16 i didn't see anything on gitlab about it. but linus seems to feel these warnings are for distros 2024-03-19 17:17:24 ive updated a package yesterday and some archs still dont have it 2024-03-19 17:17:39 i dont see it on the builder list, is there a way to restart a build? 2024-03-19 17:18:37 algitbot: retry master 2024-03-19 17:18:56 but except x86 and riscv64, the builders are idle 2024-03-19 17:24:17 maybe its in the queue then, those are the 2 arches that are failing because the package is not there 2024-03-19 17:24:21 its py3-glad-2.0.6 2024-03-19 17:25:30 yeah, webkit2gtk is failing on those arches 2024-03-19 17:25:49 webkit2gtk-4.1 2024-03-19 17:27:01 i'm still on it btw! it's just that, nobody really seems to have this issue.. worst case i'll just disable them for a second so they don't block the builders 2024-03-19 17:27:41 ( well, it's surprisingly hard to find a distro that builds modern stuff for i386 nowadays ) 2024-03-19 17:28:00 yeah, we're one of the last hold-outds 2024-03-19 17:28:03 hold-outs 2024-03-19 18:49:07 What are your plans? 2024-03-19 18:49:30 on i386 2024-03-19 20:30:50 Ermine: For now we'll still support it 2024-03-19 20:57:29 ptrc: as I see x86 builder finished webkit-4.1 but how that was fixed? 2024-03-19 20:59:22 6ac1a60697be269de429404a602aaeb44ffe1149 nice! 2024-03-19 21:07:38 now th 6.0 version is failing 2024-03-19 21:08:35 Same failure, so I suppose the fix is the same 2024-03-19 21:11:00 hi there! I'm just trying to package an alpine package that executes a post install script and pulls in some dependencies, but does not add files by itself. The resulting PKGINFO file has a size = 0 entry. When the size is 0, the post install script is not being executed (even if I add empty files to the package). at the moment where size is > 0, the post installation scripts work as expected. Is 2024-03-19 21:11:06 this a bug in APK or is this an expected behavior? 2024-03-19 21:11:52 devfbe: iirc, pkgsize = 0 means it's a virtual package 2024-03-19 21:12:43 ok, that means that virtual packages cannot have a post install script? 2024-03-19 21:13:17 indeed. Just to verify, what filesystem do you use? 2024-03-19 21:13:19 (in this case, how do you create a package that just creates a specific user? just add the user creation script to the package and invoke it in the post install script instead of invoking everything directly in the postinstall)? 2024-03-19 21:13:42 Currently i'm running everything in a docker container (host running on btrfs) 2024-03-19 21:13:53 right, I recall this being an issue on btrfs 2024-03-19 21:14:01 well, my pipeline is ext4 -> overlayfs 2024-03-19 21:14:01 :> 2024-03-19 21:14:13 hmm 2024-03-19 21:14:38 devfbe: not sure if you do that already, but you should at least do mkdir -p "$pkgdir" in the package stage 2024-03-19 21:15:31 Not sure if that happens :| I use nfpm for packaging the alpine packages (but it's reproducible that the archive with the same metadata and ONLY different size entry behaves different) 2024-03-19 21:16:01 I'll try to figure out whats going on in the apk-tools source 2024-03-19 22:21:03 looks webkit on RV known one https://bugs.launchpad.net/ubuntu/+source/webkit2gtk/+bug/2008798 2024-03-20 10:07:13 seems like python tests that are testing for warnings are not passing: https://github.com/RDFLib/rdflib/issues/2748 2024-03-20 10:07:28 there was other package with similar tests that failed earlier this week 2024-03-20 10:07:38 it happens with alpine edge 2024-03-20 10:07:44 and also with my python 3.12 rebuilds 2024-03-20 10:08:13 not sure what is going on. any python experts can help analyze what is happening? 2024-03-20 10:09:30 here is the other one. I think they are related. https://github.com/horejsek/python-fastjsonschema/issues/184 2024-03-20 10:39:41 its depressing how many packages needs to be rebuilt for python 3.12 2024-03-20 10:40:07 i have done 1.5 "pages" of ~17-18 2024-03-20 10:41:11 ~120 packages of ~1440 2024-03-20 10:41:18 Oof 2024-03-20 10:41:23 and this is community only 2024-03-20 10:41:27 main is done already 2024-03-20 10:42:23 and I must do daily rebases and rebuild whatever was updated in git master 2024-03-20 10:43:49 so I wonder if I should just push when main and community is done, and let the builders chew on that, while I start on testing 2024-03-20 10:44:06 because there will be build failures that I have missed 2024-03-20 10:44:29 there's a reference to this in the latter example: https://docs.pytest.org/en/latest/how-to/capture-warnings.html#additional-use-cases-of-warnings-in-tests 2024-03-20 10:45:27 so it is introdoced with a newer version of pytest? 2024-03-20 10:45:36 makes sense 2024-03-20 10:46:29 pytest 8 it seems 2024-03-20 10:46:32 would be awesome if someone could help follow up on those. If I am to follow up on everything I'm not gonna be ready with python 3.12 until end of 2026 2024-03-20 10:47:00 and nothing else will be done (busybox issues, slibtool, llvm18...) 2024-03-20 10:47:20 ncopa: maybe we should make an issue for it 2024-03-20 10:47:51 i need to create an issue for slibtool today, for TSC 2024-03-20 10:48:06 someone needs to drive slibtool project 2024-03-20 10:48:19 which is a pretty big and intrusive thing 2024-03-20 10:48:33 but it is absolutetly a good thing 2024-03-20 10:49:15 busybox issue is a TSC issue assigned to me. I just need to write up what I think we should do forward with it 2024-03-20 10:50:01 llvm has tests failing on armv7, but I dont trust the compiler there, so I think we should focus on other arches, like ppc64. maybe mick_ibm can help with that 2024-03-20 10:50:17 the failing tests needs to be reported upstream 2024-03-20 10:50:52 this is the MR for llvm18: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61796 2024-03-20 10:54:06 looks like the python-fastjsonschema issue has an unreleased fix already: https://github.com/horejsek/python-fastjsonschema/pull/180 2024-03-20 10:54:10 i think we need to postpone gcc14 til after alpine 3.20 2024-03-20 10:54:58 dne: do you have time to create an MR with that patch backported? 2024-03-20 10:55:07 or anybody else 2024-03-20 10:55:24 sure 2024-03-20 10:55:39 thank you! appreciate! 2024-03-20 11:14:46 !62558 2024-03-20 11:40:34 thank you! 2024-03-20 12:45:00 aws-cli also has similar pytest8 issue 2024-03-20 12:54:54 and aws-cli does not support python 3.12 at all. I will disable it for now 2024-03-20 13:00:35 "interesting" - v1 supports it but not v2 2024-03-20 13:17:51 py3-glad still at 2.0.5 on riscv but 2.0.6 on x86 o/ 2024-03-20 13:18:53 yeah, rv64 is kinda stuck 2024-03-20 13:19:05 *still* on it :p 2024-03-20 13:19:09 still building webkit2gtk? 2024-03-20 13:19:19 https://build.alpinelinux.org/ 2024-03-20 13:19:34 fixing webkit2gtk 2024-03-20 13:19:55 dont worry, the shaderc update can wait 2024-03-20 13:20:19 ikke: yeah i have the tab open, I saw the 6/70 on rv64 2024-03-20 15:21:32 i suppose I should move the build-edge-riscv64 to the bare metal machine 2024-03-20 15:21:54 but im kinda busy with the python 3.12 upgrade 2024-03-20 16:34:20 ikke: is something wrong with build-base docker images? the x86 image tag has not been updated for a while: https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/container_registry/29?orderBy=NAME&sort=asc&search[]=latest-x86&search[]= 2024-03-20 16:35:53 ikke: stale x86 build-base causes the apk-tools build static image fail due to compiler being older than what was used to build static libzstd 2024-03-20 16:36:26 fabled: let me take a look 2024-03-20 16:37:26 its weird because the CI job looks like it worked, but the registry tag just isnt updated 2024-03-20 16:37:38 Yeah, indeed 2024-03-20 16:41:57 The manifest also refers to the old image 2024-03-20 16:42:32 hmm... it should be using the docker hub image? the apk-tools CI jobs says image "alpinelinux/build-base:latest-$ARCH" ? 2024-03-20 16:42:33 i have calculated how long time its gonna take to finish the python 3.12 rebuilds in community repo 2024-03-20 16:43:32 ikke: this is how the apk CI fails: https://gitlab.alpinelinux.org/alpine/apk-tools/-/jobs/1312202 2024-03-20 16:43:41 if I'm able to spend 100% time on this, its gonna take ~24 work days 2024-03-20 16:44:00 ncopa: ouch 2024-03-20 16:44:18 So this needs to be distributed / coordinated 2024-03-20 16:45:30 problem is that I am so busy running by the side of the bicycle that I dont have time to stop and jump up on it 2024-03-20 16:45:54 not sure how to distribute it, as we need dependencies 2024-03-20 16:46:19 i mean i don't know how to distribute it due to dependencies 2024-03-20 16:46:41 automate? 2024-03-20 16:46:56 ikke: or is it the gitlab runner just not refreshing the docker tag properly? 2024-03-20 16:46:57 fabled: this is with automation 2024-03-20 16:47:21 the time is spent on reporting issues upstream and find fixes for python 3.12 / pytest 8 issues 2024-03-20 17:01:55 would it help to package pytest 7 separately? 2024-03-20 17:06:16 possibly 2024-03-20 17:06:29 Maybe I should just disable lto for the static build CI job 2024-03-20 17:06:32 pytest7 can be installed in parallel, right? 2024-03-20 17:13:49 maybe not… but either you use/install one or the other I'd guess? 2024-03-20 17:26:07 =/23 2024-03-20 17:33:06 fabled: I saw that rv64 had the same issue 2024-03-20 17:37:17 ikke: Seems so. I just made apk upgrade compiler first. But definitely something strange on the image tags not refreshing somewhere 2024-03-20 17:37:34 yeah, trying to reproduce it on the hosts 2024-03-20 17:47:46 ncopa: im trying to find more info about ppc64le and LLVM right now for those 3 test failures on ppc64le https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61796#note_382930 2024-03-20 17:48:12 im not an expert in that kind of stuff but i think i found the right team to chat with now 2024-03-20 19:03:34 fabled: I 'fixed' it by forcing docker build to pull a new image and not using any cache 2024-03-20 19:03:42 not sure why it happened in the first place 2024-03-20 19:38:47 mick_ibm: thank you for following that up! 2024-03-20 19:55:54 fabled: all images are up-to-date again, thanks for letting me know 2024-03-21 01:49:11 https://redis.com/blog/redis-adopts-dual-source-available-licensing/ 2024-03-21 04:12:41 fluix: saw it, very sad 2024-03-21 04:14:12 indeed 2024-03-21 06:16:54 seems gitlab - alpine/alpine-gcc-patches, is no longer active 2024-03-21 08:24:42 any objection to merge openssl 3.2? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/58461 2024-03-21 08:25:52 related unrelated, the qa-bot in that thread suggested pinging @ariadne, which seems wrong to me 2024-03-21 08:26:06 (unless i missed an update) 2024-03-21 08:26:55 ncopa, how can i test my aports with 3.2? just checkout the MR, abuild, test, then abuild my stuff (so it's actually built against 3.2), test again? 2024-03-21 08:27:07 oh, i just heard Arch did it in December and nobody noticed 2024-03-21 08:27:39 ariadne is still the official maintainer, which is wrong 2024-03-21 08:27:48 right, so the problem is not in the bot 2024-03-21 08:28:00 nice to hear about Arch, then maybe I just push it and we can test from edge 2024-03-21 08:28:47 neat 2024-03-21 08:33:58 im also taking over the maintainership of it 2024-03-21 08:35:02 congrats / good luck :) 2024-03-21 08:48:31 this is blocking me right now: https://github.com/jaraco/inflect/issues/207 2024-03-21 08:50:51 oh no.... https://github.com/pydantic/pydantic/issues/7689#issuecomment-1739627354 2024-03-21 09:00:53 if anybody wants to help: I wonder if we can upgrade pydantic to 2.x. What would break? 2024-03-21 09:04:25 there's 1-2 imports that changed between pydantic v1 and v2 2024-03-21 09:05:24 https://docs.pydantic.dev/2.0/migration/ 2024-03-21 09:05:44 maybe a bit more 2024-03-21 09:06:12 ah but you can import things from pydantic.v1 as an easy fix 2024-03-21 09:12:01 we had a draft for that 2024-03-21 09:12:06 but last time i checked, it was a bit annoying 2024-03-21 09:35:39 patch submission url in main/gcc/APKBUILD also needs changing 2024-03-21 10:06:51 ncopa: i should have more time soon to contribute to alpine again :) 2024-03-21 10:08:12 oh thats great! 2024-03-21 10:08:46 Ariadne: do you mind that I take over openssl meanwhile? 2024-03-21 10:09:48 re pydantic, the simplest way forward is to fix https://github.com/pydantic/pydantic/issues/7689 2024-03-21 10:10:28 it is a bug in pydantic 1.10.14. fixing it will make py3-inflect build again 2024-03-21 10:11:42 all the proposed solutions are "downgrade to pydantic 1.10.12" 2024-03-21 10:12:17 sure. i took openssl3 maintainership while it was still experimental. fabled didn’t want to have it 2024-03-21 10:12:52 πŸ‘ 2024-03-21 10:36:45 ptrc: I think I'll re-open https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/48650 2024-03-21 10:44:42 drats. the commits disapeared 2024-03-21 10:45:10 that's an awesome algitbot feature :D 2024-03-21 10:47:06 ptrc: you dont happen to have the commits locally somewhere? 2024-03-21 10:50:39 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/48650/diffs?commit_id=0e0b272e08e11114c042b2104e8e73d8fac6f29b 2024-03-21 10:58:18 thanks! 2024-03-21 11:09:06 hum. i think py3-pytest7 may be helpful 2024-03-21 11:10:19 ncopa: I can work on that 2024-03-21 11:16:15 new pydanitc upgrade MR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62600 2024-03-21 11:16:28 it looks like pytest8 failures of tests 2024-03-21 11:18:01 ncopa: do we need py3-pytest7 in main, or is community sufficient? 2024-03-21 11:30:58 community is more than enough 2024-03-21 11:31:21 i am currently disabling the tests that fails with pytest8. its usually not all of them 2024-03-21 11:31:34 but with pytest7 we may make all tests pass quicker 2024-03-21 11:31:59 and it will make it relatively easy to grep pytest7 and get a list of things people can help fix 2024-03-21 11:32:59 !62603 2024-03-21 11:33:16 Just copied the last version before upgrading to 8 2024-03-21 11:38:36 thank you 2024-03-21 11:39:05 and the nightmare continues. py3-pydantic introduces a new check dependency, py3-dirty-equals 2024-03-21 11:39:22 which depends on pypydantic. so a circular dep. great.... 2024-03-21 11:39:25 :/ 2024-03-21 11:39:51 how lovely 2024-03-21 11:41:35 Just sow they can do assert 1 == IsPositive 2024-03-21 11:41:45 ? 2024-03-21 11:41:53 That's what py3-dirty-equals provides 2024-03-21 11:42:28 Not just that, but that style of comparisson 2024-03-21 11:42:46 i'll break circular deps in py3-dirty-equals 2024-03-21 11:43:29 ncopa: I'm gonna take a shot at trying to divide these packages up 2024-03-21 11:43:57 But wondering if there is a nice grouping (instead of a lop of overlap) 2024-03-21 11:44:06 looks liek py3-dirty-equals has an easy fix: --ignore tests/test_other.py 2024-03-21 11:49:39 FAILED tests/test_datetime.py::test_is_datetime[unix-int] - assert 946684800 == IsDatetime(approx=datetime.datetime(2000, 1, 1, 0, 0), unix_number=True) 2024-03-21 11:49:39 FAILED tests/test_datetime.py::test_is_datetime[unix-float] - assert 946684800.123 == IsDatetime(approx=datetime.datetime(2000, 1, 1, 0, 0), unix_number=True) 2024-03-21 11:49:45 is what i get next 2024-03-21 11:49:53 from py3-dirty-equals 2024-03-21 11:52:03 No details of why it thinks they are not equal? 2024-03-21 11:52:23 date -d @946684800 2024-03-21 11:52:27 Sat Jan 1 00:00:00 UTC 2000 2024-03-21 12:33:51 no idea, i have reported it upstream and disabled the tests 2024-03-21 12:34:23 im downgrading py3-catalogue to 2.0.x. the 2.1 has not had any commits or releases for ages 2024-03-21 12:47:40 py3-email-validator-2.1.0.tar.gz: FAILED 2024-03-21 12:47:40 sha512sum: WARNING: 1 of 1 computed checksums did NOT match 2024-03-21 12:47:44 lovely 2024-03-21 13:14:19 anybody volunteering bump py3-dnspython while I have lunch? https://github.com/JoshData/python-email-validator/issues/132#issuecomment-2012249513 2024-03-21 13:14:54 πŸ‘ 2024-03-21 13:17:12 I'll also backport py3-email-validator to 3.19-stable and change the license (CC0 -> Unlicense in 2.1.1) 2024-03-21 13:21:20 fun, pyproject.toml is invalid 2024-03-21 13:22:52 and I got a 500 on gl.ao :p 2024-03-21 13:24:22 doing what? 2024-03-21 13:24:56 going to the automatic MR link from a git push. it tries to create it from my branch to master instead of 3.19-stable which is probably super large and crashes 2024-03-21 13:25:14 ah ok 2024-03-21 13:25:15 adding &merge_request[target_branch]=3.19-stable fixes it 2024-03-21 13:35:48 !62614 2024-03-21 13:37:50 <3 2024-03-21 13:38:10 rv64 builder still on webkit2gtk? 2024-03-21 13:38:32 its forever there til someone fixes the build 2024-03-21 13:38:33 does the failure means the rest of the things queued are not processed? 2024-03-21 13:38:38 alright 2024-03-21 13:39:12 i wonder if we should just disable webkit2gtk there for now, as its blocking the builder 2024-03-21 13:39:30 or temporarily to clear the queeu 2024-03-21 13:41:26 we should also move build-edge-riscv64 to one of the new machines 2024-03-21 13:48:22 andypost[m]: thank you for helping me merge stuff <3 2024-03-21 13:56:05 bl4ckb0ne: it will randomly build packages, but a repo only gets uploaded once everything is finished (succeeds to build) 2024-03-21 13:56:42 ugh, py3-hatchling is in community 2024-03-21 13:56:48 why py3-dnspython is in main 2024-03-21 13:57:12 while* 2024-03-21 14:01:41 required by samba? 2024-03-21 14:01:44 ikke: I've been trying to move py3-hatch* to main to upgrade py3-iniconfig for about a month now, haven't gotten any real traction on the MR 2024-03-21 14:01:54 yeah, ^ 2024-03-21 14:02:05 durrendal: link? 2024-03-21 14:03:20 I've gotten this from s390x a couple times now: fatal: unable to access 'https://gitlab.alpinelinux.org/fluix/aports.git/': Failed to connect to gitlab.alpinelinux.org port 443 after 131471 ms: Couldn't connect to server 2024-03-21 14:03:32 !61309 2024-03-21 14:03:46 for py3-hatchling 2024-03-21 14:05:21 For py3-pygments, i've managed to just patch out hatchling: !55747 2024-03-21 14:05:50 Maybe that can be replicated with py3-dnspython 2024-03-21 14:05:59 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61309 2024-03-21 14:06:15 that's the current one ikke I closed a previous MR looks like 2m ago 2024-03-21 14:06:37 oh celie beat me to it, thank you ^^ 2024-03-21 14:06:52 You're welcome 2024-03-21 14:07:47 The close MR is !58704, but you probably know better if there's anything there worth looking at 2024-03-21 14:07:53 closed* 2024-03-21 14:11:35 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-03-21 14:12:03 yeah and it's a direct dep for iniconfig now, which underpins damn near everything it seems 2024-03-21 14:34:03 durrendal: can you please rebase https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61309? 2024-03-21 14:35:10 is py3-iniconfig breaking API? Its a major release, so how much breaks with this? 2024-03-21 14:41:57 ncopa: is it possible to share your progress so far 2024-03-21 14:46:05 i could push it to git branch, and rsync my ~/packages 2024-03-21 14:46:21 but I'm afraid of needlessly use CI resources 2024-03-21 14:46:49 ncopa: it won't start any pipelines unless you make an MR 2024-03-21 14:46:52 aha 2024-03-21 14:46:58 let me push then 2024-03-21 14:47:05 i'll just rebase first 2024-03-21 14:47:42 most fixes and upgrade are going to git master first 2024-03-21 14:47:55 my changes for python 3.12 is mostly bumping pkgrel 2024-03-21 14:48:14 nod 2024-03-21 14:48:22 makes sense to push those fixes already 2024-03-21 14:48:51 makes it easier to rebase also 2024-03-21 14:48:55 nod 2024-03-21 14:52:48 https://gitlab.alpinelinux.org/ncopa/aports/-/commits/python-3.12 2024-03-21 14:53:33 Do you plan to squash all those commits? (Unsquashed they would number in the thousands, right?) 2024-03-21 14:53:51 no plans to squash currently 2024-03-21 14:53:59 makes it a nightmare to rebase 2024-03-21 14:54:23 yes, ~1400 or so maybe? 2024-03-21 14:54:25 probably more 2024-03-21 14:54:29 this is excluding testing 2024-03-21 14:54:34 ncopa: yes absolutely, I'll do so in just a minute 2024-03-21 14:55:11 ikke: https://dev.alpinelinux.org/~ncopa/py3.12/ 2024-03-21 14:55:14 Alright 2024-03-21 14:55:19 ncopa: thanks 2024-03-21 14:55:43 celie: It may make sense to squahs all the commits in main, right before I push 2024-03-21 14:55:50 and maybe similar with community 2024-03-21 14:55:53 and testing 2024-03-21 14:55:56 I think that's what celie meant 2024-03-21 14:56:00 yeah 2024-03-21 14:56:17 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-03-21 14:56:22 i might give it a try 2024-03-21 14:56:43 ncopa: also to answer the api question, it should not be, it's expected to be compatible per the changelog 2024-03-21 14:56:45 celie: thats a good question 2024-03-21 14:56:45 https://github.com/pytest-dev/iniconfig/blob/main/CHANGELOG#L1-L16 2024-03-21 14:57:10 durrendal: would appreciate if you mentioned that in commit message, and maybe added a link to changelog 2024-03-21 14:57:39 celie usually add a link to the changelog/whatsnew in MRs. its very helpful 2024-03-21 14:57:49 yup 2024-03-21 14:57:58 ncopa: roger that! 2024-03-21 14:58:47 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-03-21 15:00:04 good point celie. it makes it convenient to run the tests locally 2024-03-21 15:00:14 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-03-21 15:08:07 honestly this MR has been a little bit more than I expected it to be, and I didn't really like the idea of removing all of the checks anyways. 2024-03-21 15:08:32 I have absolutely no issues adding the check functions back to the apkbuilds, the reasoning is very sound 2024-03-21 15:08:54 appreciate you helping with this 2024-03-21 15:11:39 No problem at all, I'm happy to help however I can. 2024-03-21 15:16:35 celie: !62614 can you check if that looks right? 2024-03-21 15:18:01 Oh, so you patched it 2024-03-21 15:18:05 yes 2024-03-21 15:18:22 I thought !61309 with the hatchling to main move was almost ready to be merged 2024-03-21 15:19:18 ah ok 2024-03-21 15:19:22 that's also possible 2024-03-21 15:20:41 I see a patch to the APKBUILD in build-with-setuptools.patch 2024-03-21 15:21:06 but i think if hatchling is going into main soon, it is probably better to wait for that 2024-03-21 15:21:20 celie: yeah, noticed that, had removed it already 2024-03-21 15:21:42 I looked into the Git history of dnspython, and it seems before hatchling, they were using poetry 2024-03-21 15:22:08 So, it isn't like pygments, where they were using setuptools before that (so easy to revert that change) 2024-03-21 15:22:32 i'd say we merge as is instead of waiting for !61309 2024-03-21 15:22:43 especially if its easy to revert later 2024-03-21 15:23:12 I just finished modifying it, I added the check functions back to the various packages 2024-03-21 15:23:36 the gitlab runners are running hot :) 2024-03-21 15:23:55 they certainly are 2024-03-21 15:31:06 !61309 should be set now, just needs to finish CI 2024-03-21 15:34:21 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-03-21 15:38:50 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-03-21 15:39:33 (oh, and i'm still on pytest 7, in case anyone decides to try the tests with pytest 8 and something fails) 2024-03-21 16:03:30 i joined curl meetup 2024-03-21 16:03:36 thanks everyone for the assistance with the py3-iniconfig, feels good to have it merged :) 2024-03-21 16:03:48 likewise! 2024-03-21 16:04:57 ok, I'll undo the hatchling patch for pythondns then 2024-03-21 16:19:45 im in here now: https://github.com/curl/curl/wiki/curl-distro-discussion-2024 2024-03-21 19:02:29 i'm having some issues to build alpine packages on my local system 2024-03-21 19:03:06 i'll paste the logs but it is a bit wacky 2024-03-21 19:05:18 http://paste.debian.net/plain/1311550 2024-03-21 19:05:29 I have no clue what this error is about 2024-03-21 19:05:53 I have setup ~/packages and .abuild again, generate a new key, place it on /etc/apk/keys 2024-03-21 19:06:09 *generated 2024-03-21 19:13:10 What happens if you run `abuild-apk add --wait 30 --repository /home/eletrotupi/packages//main --repository /home/eletrotupi/packages//community --virtual .makedepends-prometheus --quiet --simulate build-base go npm bash` 2024-03-21 19:33:00 ncopa: we are attempting to build llvm on ppc64le now :) hopefully i can post some status by the end of this week. FYI the 3 tests that failed on alpine for ppc64le did not fail on ubuntu 20.04 2024-03-21 19:33:06 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61796#note_382930 2024-03-21 19:40:47 oh thats interesting 2024-03-21 19:44:33 hi. can anyone look into this MR and maybe try to get it moving? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/57900 2024-03-21 19:44:50 it has only one thread related to properly set license variable, i'm not sure i did it correctly 2024-03-21 19:47:06 jenneron[m]: if it has a MIT license, _that_ file does need to be packaged 2024-03-21 19:52:51 ikke: the repository doesn't have a license file, but each file has its own licence, it seems that some of them are MIT and some are GPL2 2024-03-21 19:53:27 Hmm ok 2024-03-21 19:54:04 The license stipulates that the license should be included 2024-03-21 19:55:01 so i have to report it upstream and ask them to include license file before we can package it? 2024-03-21 19:55:15 Or we have to extract it somehow 2024-03-21 19:56:01 e.g. this file seems to be MIT https://github.com/grate-driver/libvdpau-tegra/blob/master/src/media.c#L4 2024-03-21 19:56:55 As these seems to be difference 'licenses' we even have to ship each of them 2024-03-21 19:56:59 the copyright header is different' 2024-03-21 19:57:07 "Copyright (C) 2018 Paul Kocialkowski 2024-03-21 19:57:09 " 2024-03-21 19:57:19 "Copyright Β© 2009 Intel Corporation" 2024-03-21 19:57:32 "Copyright Β© 2008 Red Hat, Inc. 2024-03-21 19:57:47 i'm not sure i understand "extract it somehow" part 2024-03-21 19:58:47 "The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software." 2024-03-21 19:59:18 so something like head -23? 2024-03-21 19:59:34 Yup. something like that 2024-03-21 19:59:42 i see 2024-03-21 20:01:30 when i shut down the system, init restarts getty on tty1, so i see a login prompt after the compositor exits. 2024-03-21 20:01:50 running getty via openrc fixes this. is there any reason to use inittab by default instead of running getty via openrc? 2024-03-21 20:08:50 WhyNotHugo: you always want at least one tty supervised, in order to be able to recover from kill -9 -1 or botched shutdown or similar pathological case 2024-03-21 20:11:43 skarnet: oh, thanks for the warning there 2024-03-21 20:18:42 i guess it would be weird for the default config to run N ttys via openrc and a single one via inittab 2024-03-21 20:29:49 depends on the distro policy. AdΓ©lie does it just like you say, for instance. 2024-03-21 20:49:24 ikke: it complains about No such file or directory on those directories (even though they exist, although empty) and Install the makedepends-prometheus 2024-03-21 21:03:34 Do I want to ask questions related to abuild here, or in #alpine-linux? 2024-03-21 21:03:57 ser: you can ask them here 2024-03-21 21:06:46 K. First, I want to prefix that I'm trying to do this on Arch, 'cause. I _am_ testing in an Alpine container, but most of the APKBUILD testing and running abuild is in Arch, which has packages for most of the alpine packaging dev environment. So, I don't know how much that's contritubing to my issue. But: `abuild checksum` appears to work, but I'm sure it's not downloading the 2024-03-21 21:06:48 archive and it certainly isn't updating the checksum in the APKBUILD. 2024-03-21 21:07:43 Is there something that people commonly miss? I've been following the package build tutorial. 2024-03-21 21:09:29 make sure /var/cache/distfiles exists and your user has write permissions 2024-03-21 21:10:12 (or whatever SRCDEST is set to) 2024-03-21 21:12:19 Yes, it does and I do... however, I'm just now seeing that a file by the archive name exists but is not the right file -- it's an HTML, probably something that got downloaded when I was first messing around. If the source file exists, does abuild checksum skip downloading it again? 2024-03-21 21:12:44 it does 2024-03-21 21:12:56 abuild cleancache 2024-03-21 21:16:57 (silence because I think that was it -- verifying) 2024-03-21 21:21:10 Okay, so it's downloaded the correct file now (again, that was probably my fault by earlier giving it the wrong source URL), but it's still not updating the APKBUILD 2024-03-21 21:22:35 It's like I'm missing a -w parameter, or something. 2024-03-21 21:23:25 no, `abuild checksum` should update it 2024-03-21 21:23:34 oh, SOB. 2024-03-21 21:24:05 try abuild -v checksum 2024-03-21 21:24:40 I somehow got stuck on sha256sum. 2024-03-21 21:25:24 Ok, it looks like I've addressed the PEBCAK issue; I'll try submitting again. Thank you @ikke 2024-03-21 21:42:01 anybody wants to bump py3-responses to 0.25.0? this might be needed as well: https://github.com/getsentry/responses/issues/706 2024-03-21 21:47:39 this is also needed for python 3.12: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/50883 2024-03-22 07:20:23 here is how package maintainers can help: 2024-03-22 07:20:52 make sure that your py3-* packages builds with current git master 2024-03-22 07:21:06 myaports=$(grep Maintainer.*Natanael py3-*/APKBUILD | cut -d/ -f1) 2024-03-22 07:21:06 failed=""; for i in $myaports ; do (cd $i && abuild -rk || failed="$failed $i"); done; echo "$failed" 2024-03-22 07:21:37 and fix all that that currently fails 2024-03-22 07:27:49 ncopa: i've left some comments on !62689 with how to make the tests pass 2024-03-22 07:28:51 briefly, either add `py3-pytest-tornasync` to checkdepends, or add `py3-pytest-asyncio` to checkdepends + patch in the pytest.mark.asyncio marker 2024-03-22 07:44:43 would be helpful if you created a new MR 2024-03-22 07:47:30 here is how maintainers can test build all your py3-* packages: for i in $(grep Natanael py3-*/APKBUILD | cut -d/ -f1); do (cd $i && abuild -rk) || break; done 2024-03-22 07:52:15 those fails: py3-libarchive-c py3-logbook 2024-03-22 07:54:50 Will open another MR for py3-responses, now looking into enabling the other tests 2024-03-22 08:10:38 ncopa: !62691 2024-03-22 08:30:55 this is brilliant! thanks! 2024-03-22 08:31:12 need to step out for a few hours 2024-03-22 08:35:05 You're welcome 2024-03-22 08:36:06 I've looked through my Python aports, and found 2 that fail tests: py3-django-hatchway and py3-aioquic 2024-03-22 08:39:03 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-03-22 08:39:58 So, i'm not sure if this means django-hatchway is broken in other ways besides the test due to Pydantic 2 2024-03-22 08:42:23 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-03-22 08:58:39 I’m on a train right now. I’ll continue when I get home 2024-03-22 09:21:59 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-03-22 09:22:23 or rather, chaing py3-pytest to py3-pytest7 in checkdepends 2024-03-22 09:22:33 changing* 2024-03-22 11:44:41 ncopa: I'm reading https://www.geeksforgeeks.org/articulation-points-or-cut-vertices-in-a-graph/ to see if that helps us dividing the python packages 2024-03-22 11:49:17 probably 2024-03-22 11:49:26 i saw some simple implementation in python some time ago 2024-03-22 12:01:49 googling dependency graph parallel jobs 2024-03-22 14:08:52 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-03-22 14:09:18 https://github.com/watchexec/clearscreen/pull/15 2024-03-22 14:11:18 ok thanks celie 2024-03-22 14:12:05 You're welcome 2024-03-22 14:12:55 celie, so in the github issue you submitted the problem is that one test job is failing because of nix update, right? 2024-03-22 14:13:12 s/submitted/posted 2024-03-22 14:13:51 I didn't submit it, it is by dependabot update 2024-03-22 14:14:18 yeah that was my bad english skills 2024-03-22 14:14:26 Don't worry 2024-03-22 14:14:59 Anyway, it just means clearscreen is not compatible with nix 0.27, which iirc is the version that fixes the issus with s390x 2024-03-22 14:15:29 oh Isee 2024-03-22 14:15:40 so the problem thinkens 2024-03-22 14:16:08 *thikens 2024-03-22 14:17:29 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-03-22 14:18:11 yep, so to solve ruff we need to solve clearscreen first 2024-03-22 14:24:55 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-03-22 14:26:35 oh! pytest 8.1.1 does fix things! \o/ 2024-03-22 14:27:00 this may be the breakthrough needed for getting this done in time 2024-03-22 14:27:05 Probably there is some other terminal screen clearning library that can be used 2024-03-22 14:29:41 So, i guess upstream finally fixed things after yanking pytest 8.1.0 2024-03-22 14:36:30 at least py3-fonttools passed 2024-03-22 14:51:38 Hm. Ok, another speedbump. abuild sets $builddir, but it ends up being wrong because the archive unpacks into $pkgname-v$pkgver, not $pkgname-$pkgver. 2024-03-22 14:52:41 ser: then you have to manually set builddir 2024-03-22 14:52:51 k, thanks. 2024-03-22 14:54:07 i have moved build-edge-riscv64 to the bare metal machine 2024-03-22 14:54:13 lets see how it goes 2024-03-22 14:54:16 Ah, right. The CODINGSTYLE says it's OK to set manually if necessary. 2024-03-22 15:02:04 boomanaiden1548: its you who maintain py3-matplotlib? I see it is a bit outdated. 3.8.2 is available, but it kinda depends on -images something in github? 2024-03-22 15:03:43 3.8.3 that is 2024-03-22 15:34:48 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-03-22 15:35:59 I think py3-setuptools-rust 1.7.0 is required for !62609 2024-03-22 15:43:04 maybe I was too optimistic... packages still fails 2024-03-22 15:52:10 So, again, I'm on Arch. I have this Alpine Docker container in which I'm running all of the linters and everything, to test abuild in a real Alpine environment. I'm getting different output from the linters than what's coming up in the pipeline, though. For instarnce, abuild sanitycheck in the container generates no warnings and exits with 0. 2024-03-22 15:52:12 Yes, so maybe py3-pytest7 is still a good temporary fix 2024-03-22 15:52:41 Is the pipeline run with different parameters, or something? Like a --strict flag? 2024-03-22 15:53:43 My docker linter didn't warn me that "maintainer" isn't a custom variable, but the pipeline is giving me grief about it. 2024-03-22 15:55:51 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-03-22 15:56:05 Maybe I'm asking the wrong question. Pipeline is running in a container, right? Which container, and is it public? Can I use it as my base container? 2024-03-22 15:57:06 alpinelinux/build-base 2024-03-22 15:57:24 But that does not run linting 2024-03-22 15:58:03 That linting that you see is done by atools apkbuild-lint 2024-03-22 15:58:11 And shellcheck 2024-03-22 15:58:18 Hm. Ecosia thinks apkbuild-shellcheck is in atools, but it asn't. 2024-03-22 15:58:33 Yeah. 2024-03-22 16:00:05 apkbuild-lint is a container? 2024-03-22 16:00:19 It's not a package, or at least, apk can't find it. 2024-03-22 16:06:40 atools is a package 2024-03-22 16:07:11 alpinelinux/apkbuild-lint-tools contains the l inting tools 2024-03-22 16:08:56 ser: try this to search bin $ apk search cmd:apkbuild-lint 2024-03-22 16:15:02 Shoot, sorry, I wrote apkbuild-lint, but I meant apkbuild-shellcheck 2024-03-22 16:15:21 I am not very good at context switching :-/ 2024-03-22 16:16:21 The Pipeline is running shellcheck, which I can't find (thank you @qaqland), and the linters are giving me different outputs in my container than I'm seeing in the pipeline. 2024-03-22 16:17:17 I just went down a small rabbit hole trying to use alpinelinux/apkbuild-lint-tools, but ran into a whole host of issues just getting the environment set up, so I gave up exploring that. 2024-03-22 16:24:34 Ok -- so what I've figured out is that to emulate the pipeline, I need to run several different docker containers: the linting is doing linting -- and ONLY linting -- in aplinelinux/apkbuild-lint-tools. 2024-03-22 16:25:48 So to verify I'm going to get past the linter, I need a docker container just for linting; if I wanted to check each architecture, I'd need to run those separately, but those are derivative so really it's just the linting that is special 2024-03-22 16:25:57 Does that sound right? 2024-03-22 16:42:33 Hah! Yeah, that was it. I'm able to replicate the Pipeline linter. I still don't understand why the linters behave differently when installed from the packages in alpine:latest, but I guess I don't care that much. 2024-03-22 16:42:38 linting is not arch specific 2024-03-22 16:47:16 Oh, I wasn't questioning the value of doing it. I was only wondering why the linter programs were behaving differently. 2024-03-22 16:47:29 behaving differently in what way? 2024-03-22 16:47:46 For example, I had a maintainer variable defined that the linters entirely ignored, but the pipeline complained bout. 2024-03-22 16:48:02 ser: if you mean abuild sanitycheck, that's not complete linting 2024-03-22 16:48:20 ser: You'll notice that the linting part is a separate job from building the package 2024-03-22 16:49:21 apkbuild-lint, aports-lint, abuild sanitycheck all passed in atools/apk-tools from alpine:latest, but I got different errors from apkbuild-lint-tools 2024-03-22 16:50:07 @ikke: yup, I figured that out eventually -- what confuses me is that the linter programs give different outputs. 2024-03-22 16:50:33 Ignoring that apkbuild-shellcheck apparently exists only in the linter container. 2024-03-22 16:51:24 It's an easy test: make an APKBUILD with a maintainer="..." variable, and all of the linters that are available from aports will let it past. 2024-03-22 16:53:19 There were other examples... the use of braces in variables: no warnings from the apkbuild-lint in alpine:latest, but warnings in the apkbuild-lint-tools. 2024-03-22 16:53:41 https://tpaste.us/KElo 2024-03-22 16:54:32 https://tpaste.us/og6k 2024-03-22 16:55:11 and the "custom variable prefix" error was also reported by apkbuild-lint in apkbuild-lint-tools, but were let past by the version in atools(?). 2024-03-22 16:55:44 As you see, I get that message with apkbuild-lint from atools 2024-03-22 16:56:01 The version I get in the alpine:latest container doesn't. 2024-03-22 16:56:28 apk version atools 2024-03-22 16:56:29 (docker.io/alpine:latest) 2024-03-22 16:57:07 atools-20.2.2-r5 2024-03-22 16:57:08 Here is the Dockerfile for apkbuild-lint-tools: https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools/-/blob/master/Dockerfile?ref_type=heads 2024-03-22 16:57:34 Ah. 2024-03-22 16:58:05 Interesting. So the linter is using alpine:edge -- but the other ones aren't. 2024-03-22 16:58:15 the other ones? 2024-03-22 16:58:28 The arch-specific containers. 2024-03-22 16:58:45 they are based on alpine:edge 2024-03-22 16:58:48 I know this only because edge has Go 1.22, but latest has 1.21. 2024-03-22 16:59:01 https://gitlab.alpinelinux.org/alpine/infra/docker/build-base/-/blob/master/Dockerfile 2024-03-22 16:59:19 alpine:lastest is v3.19 2024-03-22 17:00:31 but atools did not have any significant changes that it would behave differently from v3.19 2024-03-22 17:01:58 https://tpaste.us/j4wv 2024-03-22 17:02:04 Oh. I was looking for the failed pipeline, but I think I was just seeing the error locally, because my Dockerfile uses :latest. 2024-03-22 17:02:25 So, to simulate what's going on in the pipeline, I should use edge? 2024-03-22 17:02:37 yes 2024-03-22 17:02:56 though, if you are targetting a stable branch, the pipeline will downgrade 2024-03-22 17:03:17 πŸ–’ 2024-03-22 17:03:30 But for linting, it should not matter at all 2024-03-22 17:03:38 Well, I was following a tutorial, and it said to start in testing 2024-03-22 17:03:52 yes, for new packages 2024-03-22 17:04:02 For submitting new packages 2024-03-22 17:04:09 Coolio. 2024-03-22 17:04:52 Is targetting different branches something that happens by someone official, or is it something I have to worry about? 2024-03-22 17:05:11 Anyone can make MRs targetting stable branches 2024-03-22 17:05:25 For bugfixes or security upgrades 2024-03-22 17:06:57 I think i've got it 2024-03-22 17:07:37 https://github.com/rust-lang/rust/blob/1.77.0/library/std/src/sys/pal/unix/args.rs#L109 2024-03-22 17:08:04 "glibc passes argc, argv, and envp to functions in .init_array, as a non-standard extension" 2024-03-22 17:08:15 Does musl do that? 2024-03-22 17:08:28 You could ask #musl on libera.chat 2024-03-22 17:09:57 Maybe later, i will put all my findings in an MR first 2024-03-22 17:25:06 Thanks for your help, @ikke 2024-03-22 17:25:38 np 2024-03-22 17:45:20 looking at build log of webkit on new server it looks like it fails because of warnings /cc ncopa 2024-03-22 18:08:36 Alright, looks like pyskose has confirmed my findings in !62723 2024-03-22 18:09:10 So, if any of those aports are needed for the Python 3.12 rebuild, at least they are there 2024-03-22 18:14:29 whats the issue with webkit2gtk on rv? 2024-03-22 18:17:57 oh there's https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62553 already 2024-03-22 19:20:54 ncopa: i'm trying to prepare alpine-baselayout for the directory ownership, and noticed that it does not ship all directories expected such as /etc and /usr/bin. the package creates it, but abuild strips it at https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in?ref_type=heads#L1791-1795 2024-03-22 19:22:16 fixing that and adding replaces_priority to alpine-baselayout should make things good 2024-03-22 19:23:24 not sure if abuild should special case alpine-baselayout, or add an option to not try to delete those dirs 2024-03-22 19:25:34 ptrc: rv64 seems stuck for !62553 2024-03-22 19:25:37 An option sounds better 2024-03-22 19:33:37 bl4ckb0ne: huh, you're right, i didn't even notice 2024-03-22 19:35:27 well, let's just hope it's not gonna get stuck on the builders 2024-03-22 19:38:47 created https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/253 for abuild 2024-03-22 19:39:56 fabled: would be good to add a testcase for that as well 2024-03-22 19:56:34 ikke: amended the MR with a test case now 2024-03-22 20:06:12 and created https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62727 for the baselayout fixup, but depends on abuild being udpated first, and apkbuild-lint 2024-03-22 20:10:51 apkbuild-lint is just a warning, can be fixed later 2024-03-22 20:23:03 thanks for the fix ptrc 2024-03-22 20:33:02 community/erlang currently has a 27.0-rc2 change that makes docs generation use a remote binary, if you agree this is bad, you can comment at https://github.com/erlang/otp/issues/8295#issuecomment-2015744223 , it would affect the Alpine package once 27.x is used 2024-03-22 20:33:56 If it even works on alpine (due to musl) 2024-03-22 20:34:30 did the debian maintainer package the binary, or build it? 2024-03-22 20:35:08 Habbie: supposedly the debian maintainer was using the same process in the makefile that download the remote binary, at least based on the info there 2024-03-22 20:35:16 > The debian package maintainer has decided to create packages for each of the ex_doc dependencies and build the docs from source and that seems to be working well from what I can tell. 2024-03-22 20:35:38 ikke, i read that quote, just was not entirely sure what to make of it 2024-03-22 20:35:59 i triggered on "may not be as concerned" and i was like "that does not sound very debian of them" 2024-03-22 20:36:13 I may have misinterpreted it 2024-03-22 20:36:34 I associate debian with Ubuntu and snapd, etc. 2024-03-22 20:37:30 debian is certainly not that 2024-03-22 20:37:43 indeed it is not 2024-03-22 20:38:01 Ubuntu is a debian derivative 2024-03-22 23:20:29 i could suggest redis3 and redis5 to be packaged too, and wait a bit for a redis fork to happen 2024-03-22 23:26:54 or v4 and v6 2024-03-22 23:40:46 already happened: https://redict.io/ 2024-03-22 23:52:36 super. i liked some of earlier versions between v1 an v2, small and simple and seemed faster for routers 2024-03-22 23:53:57 for encryption, all i needed to do is pre-encrypt text, with pre-distributed keys 2024-03-23 00:34:20 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-03-23 00:43:28 and as the ex_doc binary is BEAM vm bytecode, musl compatibility doesn't come into the picture 2024-03-23 00:57:02 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-03-23 01:09:02 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-03-23 01:10:08 then we should be checksuming the remotely downloaded ex_doc indirectly by checksuming the whole Erlang release tarball 2024-03-23 02:09:21 celie: I was hoping they would improve the situation upstream gradually, but I am not sure if they would want to, their view generally in the past is that security is required for reliability/fault-tolerance to be possible, so they should improve it when they are able to 2024-03-23 02:18:26 https://github.com/erlang/otp/blob/master/otp_build#L1013-L1034 is what checks the checksums 2024-03-23 03:02:31 Alright, so just wondering what you would suggest, that upstream doesn't use ex_doc, 2024-03-23 03:03:04 or that they build it from source (which i guess would mean they need to build elixir too)? 2024-03-23 03:25:33 celie: I meant that I was hoping they would improve the situation for the 27.0 release, or a separate 27.x release later (i.e., a change in the master branch of https://github.com/erlang/otp/), if Ericsson sees value in the change to improve security for the future 2024-03-23 03:28:53 the https://github.com/erlang/otp/blob/master/make/ex_doc_link file contains the link https://github.com/elixir-lang/ex_doc/releases/download/v0.31.2/ex_doc_otp_26 as the single binary escript used for ex_doc and that has a separate release process done by the creator of elixir https://github.com/josevalim based on the commit history 2024-03-23 03:35:30 celie: the https://github.com/erlang/otp/ repository isn't using ex_doc in the maint-26 branch for the 26.x releases which is where the current 26.2.3 release is coming from, the ex_doc changes would only be used once Alpine starts using a 27.x release 2024-03-23 03:36:11 but 27.0 is currently pre-release as 27.0-rc2 2024-03-23 03:39:09 celie: a specific solution to the problem is something that is likely difficult to agree on, I know you can convert Elixir to Erlang with https://github.com/okeuday/reltool_util/blob/master/ex2erl but Elixir macro use requires elixir as a dependency available at runtime and there is likely Elixir source code being used, since they wouldn't want to include Elixir in the repository, it is a difficult situation 2024-03-23 03:42:09 I am not attempting to suggest that ex_doc isn't used, just that it is used in a way that is built locally or required as a build dependency that configure checks for 2024-03-23 03:44:56 doing either ensures things are transparent and don't require binary blobs 2024-03-23 04:15:11 Yes, i know ex_doc is something new to Erlang 27 and isn't used in 26.2.3 2024-03-23 04:15:22 I'm maintaining community/erlang now :) 2024-03-23 04:19:21 Isn't there a `command -v` check for ex_doc in https://github.com/erlang/otp/blob/master/make/ex_doc_wrapper ? 2024-03-23 04:20:12 However, for Alpine, having a locally built ex_doc would introduce a circular dependency 2024-03-23 04:20:38 Unless we keep an old version of Erlang and Elixir that doesn't depend on ex_doc around to build ex_doc.. 2024-03-23 05:04:48 celie: circular dependencies are best to avoid, the best solution is likely to rewrite ex_doc in Erlang, or create something similar written in Erlang, with that source code living in the erlang repository 2024-03-23 05:08:52 that would help to avoid the problem and it would be similar to Elixir being written in Erlang, but that might not be desirable by the ex_doc development, not sure 2024-03-23 05:16:41 Yes, that's quite a big change and is not likely to happen 2024-03-23 05:17:29 Circular dependencies are not allowed in Alpine at all, because each stable release is bootstrapped from scratch 2024-03-23 05:29:07 celie: will see what Ericsson says in the erlang repo, they probably want to improve it in the future 2024-03-23 05:34:41 if Alpine needs to stick to 26.x for awhile, that doesn't seem like a problem to me, that would allow time for a larger change in 27.1 or later 2024-03-23 05:57:44 ncopa: Yes. Different architectures have slightly different test images, so fail unless the images are generated per-arch (the ones it ships with only work with x86 from what I remember). 2024-03-23 05:58:21 The images come from https://github.com/boomanaiden154/matplotlib-test-images, which is essentially just CI scripts to run the builds and collect the images to catch regressions. Not sure how useful it actually ended up being in practice and it definitely increases the amount of maintenance... 2024-03-23 05:59:26 Probably should orphan most of the packages that I'm listed as the maintainer for as I haven't maintained them at all for a while. :pensivebread: 2024-03-23 06:06:46 okeuday: I will wait for the aports that depend on Erlang to support 27.x before upgrading to that, and as i think Alpine 3.20 is planned for May or June, most likely i will wait for that to be branched as well 2024-03-23 06:07:56 celie: ok, thanks for the info and maintaining the erlang package 2024-03-23 06:08:28 You're welcome 2024-03-23 06:17:11 does ntfs3 module support deleting ? tried couple of times using this process, https://tpaste.us/paste , any test git repo could be used there 2024-03-23 06:17:28 https://tpaste.us/D7l0 2024-03-23 06:38:45 could be a limitation on AL, recall(not tested yet) as working on Knoppix-8.6 2024-03-23 06:51:33 yay! seems like webkit got built on the new riscv64 machine 2024-03-23 06:55:54 Someone on the mailing list mentioned issues on milkv duo boards 2024-03-23 06:55:59 ncopa: nice! 2024-03-23 07:16:43 anybody can help me bump py3-trio to 0.25.0? 2024-03-23 07:17:22 ack 2024-03-23 07:19:20 quite some releases behind 2024-03-23 07:33:34 and it was non-trivial version bump 2024-03-23 07:36:32 yup, need to switch to gpep517 as well 2024-03-23 07:42:28 running tests is giving issues 2024-03-23 07:59:25 ikke: How is your progress with py3-trio? 2024-03-23 07:59:57 celie: still lots of test failures, some because of missing dependencies (ruff, which is in testing), and others 2024-03-23 08:00:02 I can push what I have now 2024-03-23 08:01:13 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62746 2024-03-23 08:02:08 for ruff 2024-03-23 08:02:08 There's !62711 2024-03-23 08:02:51 celie: I had to explicitly target .testenv for the tests, because otherwise it would discover tests in both .testenv and src, which conflict 2024-03-23 08:06:07 I will tpaste what i've done, and you can have a look at what's different 2024-03-23 08:19:28 ikke: https://tpaste.us/BJln i didn't reset pkgrel back to 0 though 2024-03-23 08:19:45 Originall, i targetted only the tests under .testenv/lib/python3.*/site-packages/trio/_tests 2024-03-23 08:19:57 Originally* 2024-03-23 08:20:19 with that, the tests pass, but targetting the whole .testenv catches some other tests that fail 2024-03-23 13:23:37 PureTryOut: why does extra-cmake-modules depend on (both qt6 and qt5) qttools-dev? afaict no other distro does this 2024-03-23 13:27:17 ( i'm asking, because apparently installing both Qt5 and Qt6 dev files makes some packages prefer one over the other ) 2024-03-23 14:16:53 celie: I tried your changes, but I still get a lot of "fixture 'client_ctx' not found" errors 2024-03-23 16:24:04 Yes, i think what i did was get ruff working, that's the difference from yours that i wanted you to see 2024-03-23 16:24:30 ok 2024-03-23 16:24:50 I saw the ruff MR got merged 2024-03-23 16:25:16 That's good 2024-03-23 16:25:25 but i think ruff is still not available on s390x 2024-03-23 16:25:48 So, maybe that will require conditionally ignoring the ruff tests on there 2024-03-23 16:26:34 and adding ruff to checkdepends depending on $CARCH too :/ 2024-03-23 16:26:58 I'm just wondering why linting tools are part of testing 2024-03-23 18:54:59 ptrc: because ECM is used to compile both Qt5 and Qt6 stuff and it's CMake modules require both for it 2024-03-23 18:55:22 once we're rid of KF5 completely I'll remove the qt5-qttools 2024-03-23 18:55:25 idunno, i checked even KDE neon, and they don't have a hard dependency on either 2024-03-23 18:55:27 *from the deps 2024-03-23 18:56:28 and you usually need the correct version of Qt as a makedependency anyway 2024-03-23 23:01:25 https://gitlab.alpinelinux.org/Ermine/aports/-/jobs/1316506 -- why does it think xvfb does not exist? 2024-03-23 23:03:45 you have the right package name? 2024-03-23 23:04:13 yesyes 2024-03-23 23:04:18 yes* 2024-03-23 23:04:23 it builds locally 2024-03-23 23:05:24 Ah, xvfb is in community, and libxkbcommon is in main 2024-03-23 23:07:12 So I either patch out tests requiring x server, or bring it to main 2024-03-23 23:14:18 its a testdep right? 2024-03-23 23:17:36 yes 2024-03-23 23:27:36 dunno if its worth pulling xvfb to main just for that 2024-03-24 00:58:12 what happens when not adding it as a checkdependency? 2024-03-24 02:56:29 Could i get !62676 merged? It solves a test failure in this Python aport that i maintain, and should help with the Python 3.12 rebuild 2024-03-24 02:58:48 Tests won't pass for riscv64 on the CI because new py3-cryptography hasn't been uploaded yet, and the old dependency versions seem to cause the tests to hang, so i'll be cancelling the riscv64 pipeline in a few minutes to avoid tying that up 2024-03-24 07:15:05 ikke: I hope you don't mind that i've opened !62777 2024-03-24 07:15:26 nope 2024-03-24 07:15:45 If you look at the CI output from your MR, you'll notice that all tests that fail are under .testenv/lib64 2024-03-24 07:15:50 .testenv/lib64 is a symlink to .testenv/lib 2024-03-24 07:15:56 So, the tests were being run twice 2024-03-24 07:16:11 right 2024-03-24 07:16:23 that matches what I found online about this error 2024-03-24 07:17:10 `pytest .testenv/lib` seems to work the same way as `pytest --pyargs trio` (from https://github.com/python-trio/trio/issues/2903), so i've used the latter 2024-03-24 07:17:29 yeah, looks nicer 2024-03-24 07:17:31 and by using --skip-optional-imports, no new checkdepends need to be added 2024-03-24 07:17:46 Ruff/Black tests are skipped automatically 2024-03-24 07:17:51 very well 2024-03-24 10:42:24 anybody with time and energy can help bump py3-flexmock-0.12.0 and follow up https://github.com/flexmock/flexmock/issues/157? 2024-03-24 11:31:38 ncopa: I've tried it, and it works, both with Pytest 7, Pytest 8.0.2, and Pytest 8.1.1 2024-03-24 11:32:01 or rather, not both, as it's 3 versions 2024-03-24 11:35:19 !62783 2024-03-24 11:44:44 and i also sort of understand the problem 2024-03-24 11:45:31 s/with/will/ 2024-03-24 11:45:31 with investigate a little more 2024-03-24 11:54:44 Thanks 2024-03-24 11:59:38 Ok, left a comment on the Github issue 2024-03-24 14:25:14 other packages that are currently failing with python 3.12 (i havent checked with py 3.11): borgmatic bullet caribou 2024-03-24 14:25:27 and ceph17 2024-03-24 14:27:38 ceph17 needs backport the cython3 patch 2024-03-24 18:49:54 a question 2024-03-24 18:50:38 how to bump a package if it requires a bumped veersion of another package? 2024-03-24 18:51:19 (bumping the dependency package does not solve this issue, since building uses the old version of the dependency) 2024-03-24 18:51:25 Any ideas? 2024-03-24 18:51:40 *version 2024-03-24 19:15:16 uh, i don't know enough about aports compared to other system, but maybe you can put a version number in the dependency? 2024-03-24 19:17:06 I would also like more details, what aport, dependency and versions? 2024-03-24 19:17:48 Packages are built in dependency order 2024-03-24 19:18:19 ikke, and I've done so 2024-03-24 19:18:35 (btw, it doesn't work, as I said) 2024-03-24 19:19:00 need more info 2024-03-24 19:19:45 Habbie, I think you're right but when building many packages one-by-one, I don't need to change APKBUILD 2024-03-24 19:20:15 omni, I'm trying to build coreimage and corefm but they require libcprime as dependency 2024-03-24 19:20:23 and I've already built libcprime 2024-03-24 19:20:39 4.4.0->4.5.0 2024-03-24 19:21:28 coreimage and corefm require libcprime 4.5.0 2024-03-24 19:22:08 Habbie, any other ideas? 2024-03-24 19:23:03 i didn't get why my idea was not suitable, sorry 2024-03-24 19:23:16 (i also don't have other ideas) 2024-03-24 19:25:44 ok 2024-03-24 19:26:46 Habbie, I mean, if libcprime-4.5.0 is located in alpine repositories there is no need to set number for that in coreimage or corefm apkbuilds 2024-03-24 19:27:30 then, I should revert apkbuilds for those packages in case libcprime is bumped in alpine repositories 2024-03-24 19:29:35 thanks, that made it a bit more clear to me 2024-03-24 19:30:09 wait, libcprime makedepends on and provides libcprime-dev? 2024-03-24 19:30:41 yes 2024-03-24 19:31:40 makedepends="qt5-qtbase-dev libcprime-dev cmake ninja" 2024-03-24 19:31:51 (from libcprime apkbuild) 2024-03-24 19:31:58 yes, that's what I saw 2024-03-24 19:32:41 subpackage required from package for building the package itself 2024-03-24 19:34:02 how was that bootstrapped? or what am I missing? 2024-03-24 19:34:10 this is probably not related to your issue 2024-03-24 19:35:26 omni, should I remove libcprime-dev from libcprime apkbuild? 2024-03-24 19:35:37 (I mean a new mr about libcprime 4.4.0) 2024-03-24 19:35:54 *libcprime-dev from makedepends 2024-03-24 19:36:32 (and updating pkgrel to 1) 2024-03-24 19:46:09 idk 2024-03-24 19:46:30 just looked like a circular dependency 2024-03-24 19:48:04 omni, so, is that not needing a fix? 2024-03-24 19:49:45 Dependency cycles would need to be fixed 2024-03-24 19:50:33 but it looks like it's been there since the aport was introduced, so I may not fully understand how that would work 2024-03-24 19:52:13 ikke, omni, it's not clear if it's required or not 2024-03-24 19:52:33 I could ignore that dependency if it's not an issue 2024-03-24 19:53:09 *if a fix it's 2024-03-24 19:53:12 you could try without and if it works it should be fine 2024-03-24 19:53:30 ok, I prepare another branch 2024-03-24 19:53:54 building libcprime 4.4.0 without -dev in makedepends 2024-03-24 19:54:11 *withut libcprime-dev 2024-03-24 19:57:16 yes, but then you wanted to also upgrade all the cubocore aports to 4.5.0, right? 2024-03-24 19:57:55 omni, yes, I was doing that, but upgrading all the cubocore packages depends from fixing libcprime first 2024-03-24 19:58:15 so, two MRs 2024-03-24 20:00:42 could be separate commits in the same MR 2024-03-24 20:01:26 when built in the same MR the newly built dependencies will be immediately available for subsequent builds in the MR 2024-03-24 20:02:50 omni, then, cubocore packages have options="!check" but just some packages have # No tests 2024-03-24 20:03:10 see !33232 2024-03-24 20:04:20 ok but these are just two upgrades commits 2024-03-24 20:04:44 it was mostly to show that it could be done in the same MR 2024-03-24 20:04:56 ok 2024-03-24 20:05:24 omni, I wonder if # No tests is required for all cubocore packages 2024-03-24 20:05:59 (the ones that have options=!check 2024-03-24 20:06:12 (the ones that have options="!check") 2024-03-24 20:06:16 we prefer if options="!check" is accompanied by a comment as to why, as the "# No tests", for example, if no tests are provided upstream 2024-03-24 20:06:51 otherwise I've to add those ones in the second commit, or adding a third commit 2024-03-24 20:07:08 (r leaving things as is) 2024-03-24 20:08:44 things after a # are not interpreted 2024-03-24 20:10:16 yup 2024-03-24 20:10:17 options="!check" is to tell the build process not to run the check() function, if defined in the APKBUILD, or for the linter to not complain about it being missing 2024-03-24 20:10:33 (I can't find tests in source code or build files) 2024-03-24 20:10:46 so I guess the reason 'no tests' can be applied to all 2024-03-24 20:11:16 omni, yup, apkreference explains that very well 2024-03-24 20:11:17 sure, and preferrably such a comment could be added then 2024-03-24 20:11:24 ok 2024-03-24 20:11:50 depending on who you ask, you may not need to have separate commits for adding such comments 2024-03-24 20:12:21 I'll add those in the second commit (the one about upgrading) 2024-03-24 20:14:00 comments make it easier for us to know where to look when thinking about why tests, for example, are disabled 2024-03-24 20:20:38 ok 2024-03-24 20:24:16 omni, I can't reach gitlab.alpine from the new branch, but I can do that from master 2024-03-24 20:24:18 weird 2024-03-24 20:24:30 fatal: unable to access 'https://gitlab.alpinelinux.org/cristian_ci/aports.git/': Could not resolve host: gitlab.alpinelinux.org 2024-03-24 20:30:34 ok, it seems I've made the first commit (about libcprime) 2024-03-24 20:30:47 now, I've to make all the other 21 commits about upgrading 2024-03-24 20:31:29 (I use abump, btw) 2024-03-24 20:33:27 (in this case, not) 2024-03-24 21:18:22 (libcprime successfully upgraded, two commits done) 2024-03-24 21:18:39 now, the third commit, upgrading all the other packages 2024-03-24 22:39:22 coreimage building still fails 2024-03-25 08:07:10 Hello, anybody has time to review !62449? 2024-03-25 08:07:19 or !45752 2024-03-25 08:08:11 or !60192 2024-03-25 08:47:54 !45752 is a lot to review 2024-03-25 08:48:43 yes, indeed 2024-03-25 08:51:44 added a comment about spaces vs tabs in !60192 2024-03-25 08:52:26 alright my python 3.12 adventures continues 2024-03-25 08:52:29 these kind of webapps are much more suitable for containers 2024-03-25 08:53:32 py3-pytest-lazy-fixture does not work with pytest8, and is abandoned upstream 2024-03-25 08:53:34 https://github.com/TvoroG/pytest-lazy-fixture/issues/65 2024-03-25 08:53:52 we have 6 packages using it, 3 in community and 3 in testing 2024-03-25 08:54:27 apache-arrow, httpie and py3-prettytable3 2024-03-25 08:55:01 there is another project named py3-pytest-lazy-fixtures (note the s at the end) which is maintained 2024-03-25 08:55:14 but the we need to create a package for it 2024-03-25 08:55:47 ncopa: thanks, we will take care of your comment asap 2024-03-25 08:56:10 midasi: feel free to ping me again and I'll have a second look 2024-03-25 08:56:30 ok thanks 2024-03-25 09:00:58 ok looks like we have to add py3-pytest-lazy-fixtures https://github.com/jazzband/prettytable/commit/0fb1c7ca9f5f091f4e6a3892d5caddbb28b2f665 2024-03-25 11:07:55 fmt,gmp pkgs in main/ should have lib prefix 2024-03-25 11:09:31 docbook-xsl/APKBUILD has strange patch name 2024-03-25 14:06:19 sigh py3-httpbin: options="!check" # tests broken 2024-03-25 14:06:57 later py3-pytest-httpbin tests fails because py3-httpbin have missing dependencies 2024-03-25 14:07:29 py3-httpbin is broken 2024-03-25 15:48:55 ncopa: is the py3.12 repo a fully functioning repo, or does it need to be used together with another mirror? 2024-03-25 15:49:57 needs to be together with edge/mainm edge/community 2024-03-25 15:50:30 it only has the rebuilds from my python-3.12 branch 2024-03-25 15:52:41 alrighty 2024-03-25 15:53:09 thinking of adding them to .rootbld-repositories 2024-03-25 16:04:42 ncopa: Sorry, i'm replying from semi-AFK mode, so may not have had enough time to look into this issue, but i think !62848 needs a newer version 2024-03-25 16:05:21 See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056450#41 2024-03-25 16:07:43 Also according to Debian, Flasgger is using old Mistune, so py3-mistune1 for us, instead of py3-mistune 2024-03-25 16:08:11 celie: thank you very much for your hints! 2024-03-25 16:08:40 Np 2024-03-25 16:11:27 For the record, we also have an MR to replace Mistune 2 with the (yet again) backward-incompatible version 3: !54481 2024-03-25 16:37:04 where is that py3.12 rebuild repo? 2024-03-25 16:38:25 https://dev.alpinelinux.org/~ncopa/py3.12/ 2024-03-25 16:38:36 thanks! 2024-03-25 16:41:04 celie: i found a patch from fedora that makes flasgger dep optional. it helps me move forward 2024-03-25 16:57:03 bah, now I bump into by3-httpcore failure -> py3-anyio failure due to updated py3-trio: AttributeError: module 'trio' has no attribute 'MultiError' 2024-03-25 16:57:12 so py3-anyio needs to be updated as well 2024-03-25 16:57:15 nightmare 2024-03-25 16:57:53 py3-anyio needs modernization due to setup.py no longer exists 2024-03-25 18:14:16 why has xfce4-docklike-plugin package remained in the "edge" repository so long? 2024-03-25 18:19:49 Is there something inherently unstable about it? 2024-03-25 18:27:14 perhaps no-one has suggested for it to be moved from testing/ to community/ yet 2024-03-25 18:27:33 (discussion is happening in #alpine-linux) 2024-03-25 18:27:38 omni, is that because of known issues? 2024-03-25 18:29:55 nevermind, I've been informed it's in testing... I digress 2024-03-25 20:38:41 drats. to fix py3-httpcore i think we need to upgrade py3-anyio to 4, which has lots of non backwards compatible changes 2024-03-25 20:38:53 any volunteers to help sort that out? 2024-03-25 20:56:16 so it's basically about updating anyio and everything dependent on it? 2024-03-25 21:26:52 yeah, but I already made a MR 2024-03-25 21:26:59 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62883 2024-03-25 21:27:13 this is a nightmare. seems like every single package needs some kind of fixing 2024-03-25 21:27:22 which is all fine if its <10 packages 2024-03-25 21:27:47 but when its 1000+ and you have less than a week to complete it, its no longer fun 2024-03-25 21:28:21 next to fail is py3-uvloop 2024-03-25 21:41:45 cython3 issues. but I also have some teset_getaddrinfo_8 failing. dunno if its something on my network setup or something broken with musl 1.2.5 or something else 2024-03-25 21:43:40 rebuilding unit locally with py3.12 I has some test failures but after net.ipv6.conf.all.disable_ipv6=1 tests passed 2024-03-25 21:47:12 so it depends on the network setup 2024-03-25 21:49:00 finally... my rebuild script is moving forward... 2024-03-25 22:30:46 this is the second time i'm finding a missing include for basename(), did something change in the headers recently? 2024-03-25 22:37:23 oh 2024-03-25 22:37:28 ptrc: Looks openssl 3.2.1 added new props https://github.com/php/php-src/issues/13806 2024-03-25 22:37:30 there's some glibc-specific bullshit involved 2024-03-25 22:39:23 yes basename is a bit nasty 2024-03-25 22:50:43 btw, ncopa: i'm rebuilding all my packages in community against 3.12, will let you know if there's any failures or if they all succeed :) 2024-03-25 22:52:11 my setup's a little clunky though, using rootbld and hardcoded `python3~3.12` to make sure i get all the correct versions 2024-03-25 22:52:59 how did you added 3.12 repo for rootbld? 2024-03-25 22:53:57 put https://dev.alpinelinux.org/~ncopa/py3.12/{main,community} in .rootbld-repositores for community 2024-03-25 22:57:37 great it works 2024-03-25 23:00:52 can't exactly get it to follow the correct order 2024-03-25 23:01:00 but meh 2024-03-25 23:01:01 it works 2024-03-25 23:03:25 it's too late here, I will try to help a bit tomorrow 2024-03-25 23:27:17 alright, rebuilt some of my packages, put them in https://dev.alpinelinux.org/~ptrc/py3.12/ 2024-03-25 23:27:31 found maybe 5 or 6 failures, will fix tomorrow morning 2024-03-26 00:29:05 Oops, usually Exiftool with a version like 12.80 would be a production release, but not this time: https://exiftool.org/history.html 2024-03-26 00:29:35 but !62881 has already been merged, so i guess never mind 2024-03-26 00:39:35 and maybe !62819 can just have the failing tests disabled (i think it's just 2) instead of a full !check 2024-03-26 07:02:33 does main/gst-plugins-base still require pkging ? 2024-03-26 07:26:06 can checkdepends= for main/ be in community, eg main/gtk+3.0 ? 2024-03-26 07:26:50 vkrishn: for the latter, yes 2024-03-26 07:26:59 oh, wait 2024-03-26 07:27:13 you mean checkdepends in a package in main, referencing something from community? 2024-03-26 07:27:14 then no 2024-03-26 08:03:15 morning, yes, we should avoid disable all checks 2024-03-26 08:14:04 gummiboot https://cgit.freedesktop.org/gummiboot/log/ is obsolete, maybe move to community/ 2024-03-26 10:18:49 hello, I am trying to enable python3 wrappers on community/re2. for that I created a subpackage py3-re2. How can I enable the *-pyc subpackage for that subpackage ? 2024-03-26 10:25:59 might be enough to just add subpackages=".... py3-re2-pyc:pyc" 2024-03-26 10:28:29 will try 2024-03-26 10:32:52 ncopa, nope, it tried to locate usr/lib/python* in the main package directory, and not on the python subpackage 2024-03-26 10:39:41 celie: what's happening with the ocaml dependencies? they seem.. quite long, is that intended? 2024-03-26 10:39:46 as in 2024-03-26 10:41:03 https://tpaste.us/D7lR 2024-03-26 10:46:29 anyone with time and energy can help followup fix build of borgmatic? 2024-03-26 10:50:40 hm, i wonder - would it be possible to spin up the 3.20 builders and feed them python 3.12, so that we have everything from edge but we can use good hardware for building everything and see build errors from all architectures? :p 2024-03-26 11:01:48 sounds complicated. would need to follow a different branch 2024-03-26 11:03:42 i was thinking of just throwing python 3.12 into world with manually installed apk 2024-03-26 11:03:49 and then the rest goes from master 2024-03-26 11:08:55 i'd suggest throwing the whole update into edge already and fixing rebuilds as they happen, but after *just* recovering from something like that.. :/ 2024-03-26 11:14:25 ncopa: borgmatic works if you run it with the patched flexmock 2024-03-26 11:14:26 ( https://github.com/flexmock/flexmock/pull/158 ) 2024-03-26 11:14:33 or if you build flexmock with gpep517 2024-03-26 11:16:46 ptrc: !62755 introduced automatic dependency tracing 2024-03-26 11:18:10 oh, huh 2024-03-26 11:18:16 missed it somehow 2024-03-26 11:18:32 and well, there's already some missing dependencies 2024-03-26 11:19:51 e.g. `ocaml-cppo-ocamlbuild` on aarch64: https://tpaste.us/BJlq 2024-03-26 11:20:43 oh, ouch 2024-03-26 11:21:04 we saw something similar on another arch 2024-03-26 11:22:28 7e5b7375ffae0a92228995c856ddb105abc10e6d was to make it pass on the ppc64le builder but we didn't think that a pkgrel bump was needed at the time 2024-03-26 11:22:48 and the actual solution may be something else 2024-03-26 11:23:47 I think it is `dune runtest` that is sometimes messing things up 2024-03-26 11:24:32 that it should be run with --build-dir=.testenv to avoid this 2024-03-26 11:29:51 ptrc: thank you! 2024-03-26 11:43:07 gnome-shell depends on caribou which is archived upstream: https://gitlab.gnome.org/Archive/caribou 2024-03-26 12:22:01 ncopa, is it a bad practice to create a new package using same sources than existing package? I can't find a way to add a pyc sub-subpackage 2024-03-26 12:25:00 pyc subpackage should be made from the same build, otherwise the metadata does not match 2024-03-26 12:27:12 raspbeguy: I think you can solve your issue by making sure the pyc split function is run before the python split function 2024-03-26 12:27:22 (ie, mentioning it earlier in subpackages) 2024-03-26 12:27:42 let's try 2024-03-26 12:30:45 ikke, still no 2024-03-26 12:31:24 raspbeguy: can you share your APKBUILD? 2024-03-26 12:31:53 "pyc subpackage should be made from the same build, otherwise the metadata does not match" ikke I wanted to create a dedicated package for python wrapper that would have pyc subpackage 2024-03-26 12:32:45 ikke, https://termbin.com/l35k 2024-03-26 12:38:21 raspbeguy: It's because you only install the files in the py3 split function 2024-03-26 12:38:34 You should install the files in the package function, and then amove them in the py3 function 2024-03-26 12:40:59 https://tpaste.us/b17e 2024-03-26 12:52:18 1056 packages left to rebuild. progressing... 2024-03-26 12:52:30 ptrc: What are you using to find the missing dependencies? 2024-03-26 12:52:55 apk dot --errors 2024-03-26 12:54:12 Thanks 2024-03-26 12:55:07 ikke, thanks, will try 2024-03-26 12:55:53 Maybe cppo-ocamlbuild should just be disabled (so only the cppo binary remains), as i don't think any aport depends on that, would probably be better than rebuilding ocamlbuild, and finding out that lots more stuff have to be rebuilt 2024-03-26 12:57:16 now shiboken2 is not playing nice. it has no tests, i had to patch it to "support" python 3.12, and now py3-pyside2 builds segfaults 2024-03-26 12:57:47 fedora's shiboken is removed. dead.package 2024-03-26 12:58:16 shiboken2 has no maintainer either. maybe we shoudl just remove it 2024-03-26 13:01:38 fedora also removed pyside2 2024-03-26 13:03:02 this affects: https://tpaste.us/7Mad 2024-03-26 13:28:49 During the 3.19 rebuild, i sort of remember something about provides messing up the build order of aports, is there something like that? 2024-03-26 13:35:01 What i think i remember from the 3.19 rebuild was that if an aport had as makedepends something that was "provided", then sometimes the build would fail, as that makedepends had not yet been built 2024-03-26 13:41:02 I'm trying to figure out why some archs built ocaml-cppo with the old ocaml-ocamlbuild-dev (this is in makedepends of ocaml-cppo, and is provided ocaml-ocamlbuild) 2024-03-26 13:42:54 This means that ocaml-ocamlbuild was not detected as a dependency of ocaml-cppo, and so in a rebuild bumping pkgrel of both, ocaml-cppo is built before ocaml-ocamlbuild even though it has a makedepend on it 2024-03-26 13:44:30 lua-aports does not see provides in subpackages, so does not know what package provides those 2024-03-26 13:44:54 Ok, that would explain it 2024-03-26 13:44:54 makedepends should be on concrete packages anyway 2024-03-26 14:59:40 Core was generated by `python3 test.py'. 2024-03-26 14:59:40 Program terminated with signal SIGSEGV, Segmentation fault. 2024-03-26 14:59:45 not good 2024-03-26 14:59:54 its py3-qtgraph 2024-03-26 15:08:21 8e312ccf083f84653a848a22e9893f7482453249 2024-03-26 15:08:37 seems like it segfaults on x86 too 2024-03-26 15:45:10 clojure hangs on build-3-19-ppc64le. I dont know how to deal with it. mick_ibm would you be available to have a look at it? 2024-03-26 15:53:40 it already did in CI, so it is reproducible on 3.19-stable 2024-03-26 17:21:41 When doing apk operations from a container image (e.g. alpine:edge) are you supposed to run apk upgrade or so before doing much else? Right now the openssl package in the base image is too old for e.g. libcurl that is being apk add'ed on top so there's the error /usr/lib/gcc/x86_64-alpine-linux-musl/13.2.1/../../../../x86_64-alpine-linux-musl/bin/ld: /usr/lib/libcurl.so.4: undefined reference to SSL_get0_group_name@OPENSSL_3.2.0'` 2024-03-26 17:22:18 Or is in this example the new libcurl package suppose to depend on a recent openssl version to satisfy the library? 2024-03-26 17:22:44 That error particularly does mean that libcurl should have a >= on its libssl dep 2024-03-26 17:22:58 But in general for any container builds, I always run the distro's equivalent of `apk upgrade` first, yes 2024-03-26 17:36:09 Arnavion: Not even "official" CI scripts do that though ^^ https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/.gitlab-ci.yml?ref_type=heads#L14 2024-03-26 17:37:15 Ok for the problem at hand, do I just add e.g. `depends="libssl3>=3.2.1-r1"` to the libcurl subpackage? Since libssl3 comes from auto depends I guess I can overwrite it though? 2024-03-26 17:39:34 imo probably abuild should auto-add these dependencies, so the required libraries are >= the library it was built against, since I can imagine this is a relatively common thing 2024-03-26 17:43:16 That already happens with the so: dependencies 2024-03-26 17:43:48 But this seems to be 2024-03-26 17:43:50 curl-8.6.0-r1 depends on: 2024-03-26 17:43:50 so:libcurl.so.4 2024-03-26 17:44:18 And libcurl itself? 2024-03-26 17:44:19 ugh nvm wrong one 2024-03-26 17:44:25 libcurl-8.6.0-r1 depends on: 2024-03-26 17:44:25 so:libssl.so.3 2024-03-26 17:44:29 this one I wanted to post 2024-03-26 17:46:09 So the soname remains the same but it seems to use versioned symbols 2024-03-26 17:46:51 To my understanding of sonames, library are totally allowed to add new symbols, just not change existing ones 2024-03-26 19:43:14 ncopa: tested my packages, all seem to build 2024-03-26 19:46:44 will it not help to stop testing/ builds, stall community/, build main/ to solve py issue ? 2024-03-26 19:50:48 vkrishn: they are not yet pushed to the builders 2024-03-26 19:50:50 maybe build main/ twice (not fun), before switching community/ back on 2024-03-26 19:52:55 noticed, testing/py3-sphinxcontrib* just so. ah, ok then 2024-03-26 19:54:38 above also means, not fixing any py issues in testing/ at the moment 2024-03-26 21:04:36 ikke: thanks! <3 2024-03-26 22:08:04 less than 1000 packages left in community now. moving forward 2024-03-26 23:53:23 is there still a need to pkg "haveged" in .iso, as kernel version 5.4+ has related algo inbuilt in them 2024-03-27 00:02:03 someone should try dnsmasq in a router running with a different dns server + 2-wifis (sta+ap) setup, seems it freezes the wifis or router after couple of days 2024-03-27 00:03:35 even with just sta setup, i noticed excess cpu usage 2024-03-27 00:26:10 Has anyone done any Pydantic patches for the Python aports? I think i've only noticed !62632 2024-03-27 00:26:31 Pydantic-related* 2024-03-27 00:48:19 I have !62693, which should fix the last of my Python aports 2024-03-27 08:02:04 new kernels fails to build: /home/ncopa/aports/main/linux-lts/src/linux-6.1/tools/include/linux/btf_ids.h:7:9: error: unknown type name 'u32' 2024-03-27 08:02:18 how where do we report emergency bugs in kernel? 2024-03-27 08:09:47 https://bugzilla.kernel.org/show_bug.cgi?id=218647 2024-03-27 09:43:15 anyone knows how apk *really* generates the checksums for APKINDEX.$hash.tar.gz? 2024-03-27 09:43:39 people say it's `echo -n $url | sha1sum | head -c 8`, but that.. doesn't work for https://dev.alpinelinux.org/~ncopa/py3.12/main 2024-03-27 09:45:25 the naive approach returns 7c15c762, the actual hash is 59e4daa2 - could it be because of the tilde? 2024-03-27 10:02:30 no idea 2024-03-27 10:07:52 It's the 1st 4 bytes of the repo checksum 2024-03-27 10:11:11 But not sure over what the checksum is calculated 2024-03-27 10:11:56 it's supposedly over the repo 2024-03-27 10:12:09 as in, full repo url 2024-03-27 10:12:38 oh, it changed in newer apk versions.. 2024-03-27 10:14:24 furthermore 2024-03-27 10:14:32 $7 = {len = 69, ptr = 0x7fffffffd8a8 "https://dev.alpinelinux.org/~ncopa/py3.12/main/x86_64/APKINDEX.tar.gz"} 2024-03-27 10:14:35 that's.. very wrong. 2024-03-27 10:14:44 it's apparently reading way past the URL 2024-03-27 10:15:06 wait no 2024-03-27 10:15:22 it's appending the arch and filename, that's why the length is longer 2024-03-27 10:15:28 meh py3-pikepdf checksum is broken again 2024-03-27 17:34:28 ncopa: libcurl depends on a new symbol of libssl which does not get upgraded automatically because the soname is the same 2024-03-27 17:34:51 so curl is broken atm in docker without upgrading libssl 2024-03-27 17:47:35 yeah that's a problem with the soname only keeping the major in semver, additions are a minor bump since they don't break existing code, but package managers can't automate bumping 2024-03-27 17:58:10 that applies to edge only, right? 2024-03-27 17:58:50 we should tag new edge snapshot 2024-03-27 17:58:56 but I broke the builders 2024-03-27 17:59:22 with the jupyter-nbconvert push. I think I saw it green on the CI 2024-03-27 17:59:31 ncopa: yup, edge only 2024-03-27 18:00:00 quick fix is to add a depends="libssl>=3.2" 2024-03-27 18:00:07 yes, indeed 2024-03-27 18:00:30 we dont track that, to keep things simple 2024-03-27 18:00:49 it is kind of expected that you also upgrade the deps 2024-03-27 18:01:26 It's not common to do so in docker 2024-03-27 18:01:40 yup. its the price we pay for simplicity 2024-03-27 18:02:06 the proper way would be to store all the symbols provided and all the symbols needed, and make sure they mach up 2024-03-27 18:02:29 but it complicates things significantly 2024-03-27 18:02:36 that would mean the apkindex size would increment quite a bit I gather 2024-03-27 18:02:50 we could store the info in aports git or something too 2024-03-27 18:03:04 but even that woulddnt work, due to it may be arch dependant 2024-03-27 18:03:32 years ago I settled with the current approach as "good enough" 2024-03-27 18:03:45 but that was before docker 2024-03-27 18:04:06 still, it is still significantly simpler to apk upgrade in docker than implement a proper fix on alpine side 2024-03-27 18:04:15 I mean, even apk add -u curl fixes it 2024-03-27 18:04:22 yup 2024-03-27 18:04:33 it does? 2024-03-27 18:04:35 yes 2024-03-27 18:04:37 cool 2024-03-27 18:05:02 i can continue bang my head into jupyter-nbconvert then 2024-03-27 18:05:04 " -u, --upgrade Upgrade PACKAGES and it's dependencies" 2024-03-27 18:05:04 oh 2024-03-27 18:05:19 we also have a problem with openjdk on ppc64le i think 2024-03-27 18:05:22 it hangs 2024-03-27 18:05:32 clojure? 2024-03-27 18:05:32 clojure continue hanging 2024-03-27 18:05:37 right 2024-03-27 18:05:46 yeah, i saw other project do similar 2024-03-27 18:05:55 9ee12ab9ed691c0fed5ad5178d68869d247be084 2024-03-27 18:06:00 java was running 2024-03-27 18:06:13 java is broken on ppc64le basically 2024-03-27 18:06:35 mick_ibm: help! 2024-03-27 18:06:44 Maybe brattkartofel as well 2024-03-27 18:06:50 He's the java expert 2024-03-27 18:07:16 Should create an issue 2024-03-27 18:07:37 ikke: can you help with that? i broke builders by pushing something stupid 2024-03-27 18:07:52 ncopa: yes 2024-03-27 18:08:08 hello! i was working on llvm https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/61796#note_382930 2024-03-27 18:08:23 there was something about openjdk i thought i saw in the comments 2024-03-27 18:09:09 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/openjdk11/APKBUILD#L258 2024-03-27 18:17:56 -O2 usually has fewer bugs than -O3 2024-03-27 18:19:49 it is openjdk8 that is problematic now i think. even for 3.19-stable 2024-03-27 18:20:34 no 2024-03-27 18:20:42 clojure uses openjdk21 2024-03-27 18:21:20 oh 2024-03-27 18:21:40 except on ppc64le, where openjdk21 is disabled 2024-03-27 18:22:52 so on ppc64le it uses different openjdk version 2024-03-27 18:31:08 im gonna call it a day. i need to wait for builders to build py3-gobject3 so we can merge gst-* upgrade so I can continue with python 3.12 upgrade 2024-03-27 18:31:50 nite 2024-03-27 18:52:06 ncopa: how did you fix that kernel u32 issue? i see 6.8.2 in aports but nothing in the commit looks like it would fix that 2024-03-27 19:09:35 i havent fixed the kernel issue 2024-03-27 19:09:47 i havent been able to have a look at it yet 2024-03-27 19:10:07 was kinda hoping someone else would fix it for me before I reach to look at it 2024-03-27 19:10:27 that said it does look like a missing #include soemthing 2024-03-27 19:11:32 hum but i see https://gitlab.alpinelinux.org/alpine/aports/-/commit/5b0dbf5b07b904a4bf12f75c1a4761e4ad0014a8 2024-03-27 19:11:48 thats not me who maintains that 2024-03-27 19:11:59 i would guess it does not enable bpf 2024-03-27 19:14:11 on void we're seeing it on 6.{1,6,7,8} 2024-03-27 19:25:11 It's a specific tool that doesn't compile. Do you need it for building the kernel itself? 2024-03-28 07:58:28 morning, does anybody have time to review MR !60197 2024-03-28 07:58:46 moreover, we have 2 MRs where we claim the maintainership of a package, but the current maintainers don't answer our request. How should we proceed there? 2024-03-28 07:58:50 !59477 2024-03-28 07:58:55 !60199 2024-03-28 08:14:58 midasi, I've sent a couple of comments your way about piler 2024-03-28 08:16:30 as for the other two, I'd wait few more days for the maintainers to answer 2024-03-28 08:28:50 rnalrd: thanks for the review findings, we will take care of them 2024-03-28 08:30:14 As for the other two, we contacted the maintainers by email about 4-6 weeks ago. But ok, let's give them few more days. 2024-03-28 08:35:24 I see that we reached them out from our Gitlab instance only few days ago. Let's give them some more time. 2024-03-28 08:39:53 i think we can merge it. The maintainer has no activity in gitlab at all. an email was sent few weeks ago without any response 2024-03-28 08:40:19 if maintainer shows up and objects we can always revert the maintainer change, but that is unlikely 2024-03-28 08:43:36 ncopa: sure, we would be happy as well to hand it back over to the old maintainer 2024-03-28 10:29:13 got 2098 py3.12 packages rebuilt locally, about 360 left because of missing dependencies or something actually failing 2024-03-28 10:44:35 335 packages: https://dev.alpinelinux.org/~ptrc/pending_rebuild.txt 2024-03-28 11:01:46 ptrc: awesome! 2024-03-28 11:08:47 wow, nice. All failing from testing? I checked some and no one was on community 2024-03-28 11:20:41 donoban: there's quite a bit of failures in community unfortunately 2024-03-28 11:21:32 ptrc: did you patch some of those 2098 packages? 2024-03-28 11:21:44 anything i had to patch would be already in master 2024-03-28 11:21:55 except one or two packages that were actually breaking 3.11 to fix 3.12 2024-03-28 11:22:46 this is great 2024-03-28 11:23:30 im about to rebase my python-3.12 branch and (re) build where i stopped yesterday 2024-03-28 11:23:43 community/py3-fsspec was last failure yesterday 2024-03-28 11:23:52 looks like you already fixed it 2024-03-28 11:24:55 been fixing kernel build this morning 2024-03-28 11:25:39 https://lore.kernel.org/bpf/20240328110103.28734-1-ncopa@alpinelinux.org/T/#u 2024-03-28 11:36:16 ptrc: did gnuradio pass? there is one test that fails for me 2024-03-28 11:36:28 passed for me 2024-03-28 11:37:09 ah, no 2024-03-28 11:37:21 i'm skipping all 3.12-rebuilt stuff, and apparently there's one in your repo 2024-03-28 11:37:43 yeah, i think I skipped the checks for gnuradio 2024-03-28 11:38:10 might go over some more packages later 2024-03-28 11:45:50 hum... this kind of change hides bugs from us: ffdfbc22d6710c0567c3edf35f3d24c6ab4054c2 2024-03-28 11:45:59 sporry 2024-03-28 11:46:01 sorry 2024-03-28 11:46:10 the options="!check" 2024-03-28 11:47:18 probably myself who did it. 2024-03-28 11:48:22 found it: 475ecae21c2ca7340bfd158dc9774ca1d2f18f89 2024-03-28 12:28:32 py3-ldap fails for me with python 3.12 2024-03-28 12:37:40 same here, spams "Can't contact LDAP server" 2024-03-28 12:37:45 perhaps needs disabling 2024-03-28 12:37:52 s/$/ tests/ 2024-03-28 12:55:39 should be reported upstream 2024-03-28 13:12:50 before you start working on making qt5-qwebengine build with python 3.12, I'm working on a qtwebengine-chromium security upgrade where this is included https://invent.kde.org/qt/qt/qtwebengine-chromium/-/commit/68302c9ea158fbc83cd28570a0560e5a892b45e8 2024-03-28 13:20:22 ptrc: i'm looking through pending_rebuild.txt, what's wrong with slidge and slidge-matridge? 2024-03-28 13:20:47 ah, slidge is just because rootbld doesn't work properly with users for some reason 2024-03-28 13:21:10 You mean pkgusers/pkggroups? 2024-03-28 13:21:13 i might be using an older abuild version though 2024-03-28 13:21:13 yes 2024-03-28 13:21:53 Maybe that's also why synapse is on the list 2024-03-28 13:22:02 How about pantalaimon and weechat-matrix? 2024-03-28 13:23:19 pantalaimon missing py3-janus 2024-03-28 13:23:30 and md2gemini is on the list, but it's been disabled since py3-mistune was upgraded from v2 to v3 2024-03-28 13:24:42 weechat-matrix is because i missed weechat-python on the rebuild list 2024-03-28 13:25:26 i updated the list btw 2024-03-28 13:25:33 down to 314 packages 2024-03-28 13:29:00 Oh, i maintain py3-janus too, what's up with that (just downloaded the updated list, and that seems to be the last one on the list that i maintain) 2024-03-28 13:30:38 Hmm, i see it's checkdepends, py3-pytest-regtest on the list, so that's probably it 2024-03-28 13:30:43 its* 2024-03-28 13:31:54 and py3-pytest-regtest's makedepends, twine is on the list 2024-03-28 13:33:20 https://github.com/python-ldap/python-ldap/issues/560 2024-03-28 13:33:27 Btw, md2gemini is still on the list with 314 packages 2024-03-28 13:34:31 because it exists in the index 2024-03-28 13:34:50 dunno, i never remember how to actually remove a package from the index 2024-03-28 13:35:58 ptrc: if you still have an apkbuild for it: abuild cleanpkg cleanoldpkg 2024-03-28 13:36:09 i mean on the mirrors :p 2024-03-28 13:36:21 Maybe it needs a pkgrel bump? 2024-03-28 13:36:34 It already has arch= commented 2024-03-28 13:36:48 a pkgrel bump should do it 2024-03-28 13:39:12 done 2024-03-28 13:40:03 note that the indexes are only updated when the builders finish a repo 2024-03-28 13:42:11 well, even more of an incentive to fix the stuff i accidentally broke >.< 2024-03-28 13:48:11 hmm, sopel probably requires pyasynchat 2024-03-28 13:48:31 Regarding python-ldap, could it be that the ldap server the tests run got killed? 2024-03-28 13:49:52 Can't reproduce it with Python 3.11, but i killed the ldap server while the tests were running, and i get that error 2024-03-28 13:56:16 slightly odd that it happens both for me and ncopa on 3.12 2024-03-28 13:56:28 https://github.com/python-ldap/python-ldap/pull/537 (Test with Python 3.12) is included in 3.4.4 2024-03-28 13:58:21 Maybe looking through upstream's 3.12 CI jobs will give a clue about this (maybe some dependencies are of a different version) 2024-03-28 13:58:49 Hmm, i think they're running their tests with Tox 2024-03-28 14:02:20 cely: all your packages rebuilt successfully :) 2024-03-28 14:03:23 Thanks 2024-03-28 14:03:43 for sopel I found a patch that switches from asynchat to asyncio, but that does not apply cleanly on the latest release 2024-03-28 14:10:25 ncopa: do you remember by any chance why you made VLC depend on the dejavu font when you introduced the package 14 years ago? πŸ˜… 2024-03-28 14:15:05 Looking at the commit you mentioned, i see a link to #14028 2024-03-28 14:17:00 $ all-indexes | tmp-filter-py3.12 | wc -l 2024-03-28 14:17:00 299 2024-03-28 14:17:00 πŸŽ‰ 2024-03-28 14:23:29 i think it is a timing issue of some sort 2024-03-28 14:23:40 re the python-ldap issue 2024-03-28 14:24:15 tests that fails will pass if they are run individually 2024-03-28 14:24:28 PYTHONPATH=./build/lib.linux-x86_64-cpython-312/ python -m unittest discover -v -s Tests -p 't_*' -k 't_ldap_syncrepl.TestSyncrepl.test_refreshAndPersist_poll_only' 2024-03-28 14:25:04 so implicit dependencies 2024-03-28 14:42:32 alright, it is one of the tests that leaves things in a broken state 2024-03-28 14:43:12 If I skip Tests.t_ldap_syncrepl.TestSyncrepl.test_refreshAndPersist_cancelled it all works 2024-03-28 14:54:23 test test 2024-03-28 15:03:41 PureTryOut: i think vlc needed some kind of font for something 2024-03-28 15:03:46 might be its no longer needed 2024-03-28 15:05:03 I hope not, it messes up my emoji font configuration πŸ˜… 2024-03-28 15:05:21 i think you can remove the dep 2024-03-28 15:05:30 I made https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63064 2024-03-28 15:06:22 lets merge it. if something breaks later we fix it when it pops up 2024-03-28 15:06:34 thanks πŸ‘ 2024-03-28 15:07:48 PureTryOut: I'd appreciate if you could prio the py3- MRs assigned to you. just approving helps if you dont have time to merge 2024-03-28 15:08:18 yeah I know, I will when I actually have free time. This is just small stuff that I can quickly do in between while at work lol 2024-03-28 15:09:00 oh sorry I misread. I'm already approving and merging those 2024-03-28 15:32:57 334 2024-03-28 15:32:57 $ ps auxf | rg swtpm | wc -l 2024-03-28 15:33:11 sounds like a lot of processes 2024-03-28 15:33:12 some package is misbehaving and spawning a bunch of swtpm processes for testing 2024-03-28 15:33:15 and then not cleaning them up 2024-03-28 15:34:11 this? https://github.com/stefanberger/swtpm 2024-03-28 15:40:19 i'd say it's rather py3-tpm2-pytss that's doing this 2024-03-28 15:45:35 we should run the entire build in a namspace and then kill all process in that at end 2024-03-28 15:45:40 or at least the tests 2024-03-28 15:45:53 there are multiple packages doing similar 2024-03-28 16:41:43 ptrc: did py3-dask build for you? 2024-03-28 16:41:51 i have one test that fails 2024-03-28 16:42:00 i have.. a bit more that fails 2024-03-28 16:42:15 actually no 2024-03-28 16:42:19 dask/dataframe/tests/test_accessors.py::test_dt_accessor\ 2024-03-28 16:42:30 and when trying to upgrade to 2024.3.1 alot more fails 2024-03-28 16:42:39 and that's because https://stackoverflow.com/a/45671804 2024-03-28 16:42:45 so maybe we could just patch that one out to work properly 2024-03-28 16:44:30 okay, i think i've got something 2024-03-28 16:48:19 ncopa: !63079 2024-03-28 16:48:36 testing it locally rn 2024-03-28 16:51:22 still fails here 2024-03-28 16:55:44 ah, forgot an import 2024-03-28 16:58:23 updated, try now 2024-03-28 17:18:31 Is jitsi-videobridge having the same problem on edge as clojure is having on 3.19-stable? 2024-03-28 17:18:57 The maven/openjdk problem 2024-03-28 17:38:06 what do you mean? 2024-03-28 17:42:43 Hasn't the ppc64le builder been stuck on jitsi-videobridge for sometime? 2024-03-28 17:43:04 clojure 2024-03-28 17:43:14 Edge too 2024-03-28 17:43:37 The last 2 aports it built were on the 27th of March 2024-03-28 17:43:43 So, it's been stuck for about a day 2024-03-28 17:45:41 jitsi-videobridge is newly enabled on ppc64le, i think 2024-03-28 17:46:15 it's a new package 2024-03-28 17:46:59 I think x86_64 has a few previous versions 2024-03-28 17:47:10 but the other archs are new 2024-03-28 17:47:48 !60192 2024-03-28 17:48:12 Seems it passed 3 weeks ago 2024-03-28 17:48:22 ok 2024-03-28 17:48:33 but the last CI run from 2 days ago exceeded max execution time for ppc64le 2024-03-28 17:49:33 Yeah, mick mentioned there was a comment in the openjdk apkbuild that tests take ~15 times as long on ppc64le 2024-03-28 17:50:50 Ok, but if it's going to be like clojure on 3.19-stable, that's been stuck for a long time.. 2024-03-28 17:54:26 At least it's new on ppc64le, so can probably be disabled as a last resort 2024-03-28 17:54:56 I don't think a lot of people will use jitsi on ppc64le 2024-03-28 19:12:32 yeah, lets disable jitsi on ppc64le 2024-03-28 19:12:42 the clojure thingy in 3.19 is more tricky 2024-03-28 19:12:45 yup 2024-03-28 19:12:54 i wonder if we should disable it for now 2024-03-28 19:13:03 any clojure dependencies? 2024-03-28 19:13:10 possibly 2024-03-28 19:13:26 but they are not affected until they are updated 2024-03-28 19:13:27 pkgs.a.o says nothing requires it runtime 2024-03-28 19:13:52 i suspect openjdk11 is broken on ppc64le 2024-03-28 19:15:29 No package has it in makedepends either? 2024-03-28 19:15:48 -? 2024-03-28 19:16:46 if we disable it in arch, will it delete it from mirrors? 2024-03-28 19:16:55 from what I understood, not immediately 2024-03-28 19:17:02 only after a pkgrel / pkgver bump 2024-03-28 19:17:08 ok 2024-03-28 19:17:18 lets disable it temporarily 2024-03-28 19:17:28 so we get the other fixes out for ppc64le 2024-03-28 19:17:51 but somethign is likely very broken in openjdk11 on ppc64le 2024-03-28 19:17:55 yup 2024-03-28 19:19:29 seems like openjdk17 and 21 have ppc64le disabled in 3.19 2024-03-28 19:40:39 next new pytnon 3.12 failure was niaaml-gui 2024-03-28 19:40:43 im gonna postpone it as well 2024-03-28 19:47:16 weirdest thing. second run it passed 2024-03-28 19:47:20 its probably just flaky 2024-03-28 20:54:55 okay, pushed all my rebuilds into https://dev.alpinelinux.org/~ptrc/py3.12/ 2024-03-28 20:55:17 [~/public_html/py3.12]$ find . -name '*.apk' | wc -l 2024-03-28 20:55:17 3193 2024-03-28 20:55:20 that's quite a bit 2024-03-28 20:56:29 most of the remaining failures are either random tests failing, imp/distfiles missing or missing dependencies 2024-03-28 20:58:07 actually yeah, out of the 219 failures almost exactly half (110) is because another package is failing 2024-03-29 00:31:22 Err, Clojure already has the pkgver bump, so !ppc64le in arch= would probably remove it from the mirror straight away 2024-03-29 00:32:58 and changing pkgver back to the old one would affect all the other archs 2024-03-29 00:34:28 So, there was this trick we used on riscv64 (during the big Rust upgrade when something was blocking main on riscv64), which is to set pkgver back to the old one conditionally based on $CARCH 2024-03-29 00:43:45 yes 2024-03-29 02:09:35 like this !63092 2024-03-29 04:10:55 urls for main/ imap,iniparser needs checking 2024-03-29 04:11:22 iniparser should be libiniparser 2024-03-29 04:22:33 if possible move community/iperf to main/iperf2 2024-03-29 07:17:24 both main/ isl25,isl26 is needed ? 2024-03-29 07:20:22 isl25 does not create isl-dev pkg 2024-03-29 08:01:52 im tagging an edge release snapshot with openssl 3.2 2024-03-29 08:26:45 al moved from yasm->nasm 2024-03-29 08:35:00 ncopa: nice 2024-03-29 08:42:50 next im gonna try find otu why gst-libav test fails on riscv64 2024-03-29 09:03:33 ffmpeg has riscv64 assembly that is not supported by sophgo cpu. 2024-03-29 09:04:23 sigh.. ffmpeg has: options="!check" # tests/data/hls-lists.append.m3u8 fails 2024-03-29 09:28:02 so, sophgo implements RVV 0.71 2024-03-29 09:28:11 and ffmpeg is built for RVV 1.0 2024-03-29 09:28:21 vector instruction set 2024-03-29 09:28:59 we can either disable the test, and let sophgo crash, saying that we dont really support this hardware 2024-03-29 09:29:35 or, we could disable RVV assembly for riscv64 (I think ffmpeg has a HAVE_RVV) 2024-03-29 09:29:41 does the sophgo cpu not implement the vector instruction set extension? 2024-03-29 09:29:52 or completely disable assemly on riscv64 2024-03-29 09:30:00 it does, just a different revision of the spec 2024-03-29 09:30:11 it implements RVV 0.71 2024-03-29 09:30:30 it chokes on vsetivli 2024-03-29 09:30:46 its a known issue 2024-03-29 09:31:02 yea, that was a common issue during standardization of the v extension. somehow vendors started implementing it before the spec was frozen 2024-03-29 09:31:05 https://github.com/FFmpeg/FFmpeg/commit/676b08cb703d412e4b60a598615365928489300b#diff-e5cde7d4013ad43742edcebab324bb3a78abdff7da54af41492103aa133a9729R25 2024-03-29 09:31:51 we could also refactor the func(s) to use vsetvli instead of vsetivli 2024-03-29 09:32:09 which, if I understand correctly does not take an immediate value 2024-03-29 09:35:21 is there actually any hardware out there which already implements version 1.0 of the V extension? 2024-03-29 09:38:34 looks so: https://www.reddit.com/r/RISCV/comments/17lfr5p/rvv_10_board_has_arrived/ 2024-03-29 09:40:14 would actually be nice to try support sophgo 2024-03-29 09:41:25 And we probably only need use a temp register for the immediate value. chatGPT can help: https://chat.openai.com/share/014d72c1-cb64-45fc-8ea7-3ae9c911371b 2024-03-29 09:41:50 i am not familiar with the convetions, can we just use t0, without caring about saving restoring its value? 2024-03-29 11:09:07 vkrishn_: I dont think both isl25 and isk26 are needed anymore. They were needed during isl26 upgrade 2024-03-29 11:13:09 ok, thanks 2024-03-29 11:15:42 nmeum: v1.0 discussion related https://code.videolan.org/videolan/dav1d/-/merge_requests/1629 2024-03-29 13:08:13 !63116 - MR for Kamailio 5.8.0 2024-03-29 13:09:32 never mind - MR failed 2024-03-29 14:14:24 py3-dbus-next needs some work apparently. something with asyncio 2024-03-29 14:29:59 anybody know how to skip a specific test with `meson test ...`? 2024-03-29 14:32:16 I think community/nautilus has something for that 2024-03-29 14:33:58 thanks 2024-03-29 14:34:09 Np 2024-03-29 14:35:30 ncopa: https://github.com/mesonbuild/meson/pull/11502 2024-03-29 14:35:34 working on it... 2024-03-29 14:42:19 elibrokeit: nice! 2024-03-29 14:42:58 jtojnar is worried that it is not "useful enough" if it doesn't support wildcards to match other recent additions to meson test. 2024-03-29 14:43:16 I'm trying to be convince him that is not necessary to be useful to distros... 2024-03-29 14:44:37 yeah, disabling tests should be avoided, so not supporting wildcards may be a good thing 2024-03-29 14:45:03 and wilcard support could be added later too 2024-03-29 14:45:30 maybe you could comment in support of that :) 2024-03-29 14:49:37 πŸ‘ 2024-03-29 14:56:09 I ended up not needed include any tests. i fixed ffmpeg instead, so test now passes 2024-03-29 14:56:19 exclude* 2024-03-29 14:58:24 ncopa: fwiw, /me checked all packages I maintain - none use pytest. 2024-03-29 15:01:40 nangel: thank you! 2024-03-29 15:43:15 ratbag needs a backport of this patch for python 3.12: https://github.com/libratbag/libratbag/commit/27b0d4a2d9cd21fa9f11a0770d94c578db6324d1 2024-03-29 15:43:22 does not apply clean 2024-03-29 15:46:13 kamailio APKBUILD actually passed lint. The ugliest APKBUILD (after rust) ... wow. :) 2024-03-29 15:51:48 :) 2024-03-29 16:17:52 ncopa: https://www.openwall.com/lists/oss-security/2024/03/29/4 2024-03-29 16:20:29 0oof 2024-03-29 16:20:36 > c 70 sp 180 2024-03-29 16:20:40 > 2024-03-29 16:20:42 The upstream xz repository and the xz tarballs have been backdoored. 2024-03-29 16:26:19 whoops 2024-03-29 16:37:45 what happens if we delete those files when building xz? 2024-03-29 16:39:56 this is the account behind the backdoor(s) https://github.com/JiaT75 2024-03-29 16:45:17 yikes 2024-03-29 16:45:33 we're shipping 5.6.1 which is one of the affected versions? 2024-03-29 16:48:59 the backdoor is only in the official tarball, no? 2024-03-29 16:49:52 it's highly likely not to affect alpine: if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then 2024-03-29 16:50:03 s/affect/be activated on/ 2024-03-29 16:50:31 Ariadne: correct 2024-03-29 16:50:42 git archive tarball is fine 2024-03-29 16:51:03 i guess my question now is, which are we using? because the GH releases do have tarballs 2024-03-29 16:53:27 the release tarball, which contains the backdoor: https://git.alpinelinux.org/aports/tree/main/xz/APKBUILD#n12 2024-03-29 17:23:58 OK... finally... 2024-03-29 17:24:10 !63130 2024-03-29 17:41:56 https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757 - i wonder if Arch noticed something fishy 2024-03-29 17:46:54 We were using the tarballs from tukaani.org until 5.4.6 when, i think the link stopped working, and we switched to the Github release artifact, Arch also switched to Github with 5.4.6: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/1b45569c2 2024-03-29 17:55:58 Tukaani's xz page also contains a notice that the source code archives Github generates automatically from the repo should be ignored: https://github.com/tukaani-project/tukaani-project.github.io/blob/dc14a229c/index.html#L87-L91 2024-03-29 17:56:08 It was known before today, under embargo 2024-03-29 17:57:04 Ok 2024-03-29 17:59:48 celie: yes, but we should use them and autoreconf ourselves 2024-03-29 17:59:57 i am working on it 2024-03-29 18:04:31 I've let my guards down and stopped reviewing updates for packages I maintain... 2024-03-29 18:04:46 who didnt 2024-03-29 18:04:52 re arch linux, "improve reproducibility by running autogen.sh ourselves" 2024-03-29 18:05:12 i think this shows the value of reproducible builds 2024-03-29 18:08:05 well that is reproducible source tarballs 2024-03-29 18:08:10 which is also important 2024-03-29 18:08:19 usually we find out this type of thing much later than this, so lucky break 2024-03-29 18:09:17 I wonder how did that code sneak in in the first place 2024-03-29 18:09:46 one of the project maintainers committed it 2024-03-29 18:10:28 I never meant to imply that we shouldn't use them, just that it sort of comes from the "official source" that we should be using the release tarballs, not to mentioned that they are PGP-signed too :/ 2024-03-29 18:11:05 it is maddening how many projects have source tarballs that don't come straight from their git and are generated via a process you can't do yourself 2024-03-29 18:11:07 there's always a risk someone's keys get compromised 2024-03-29 18:11:28 By the way, i think i've noticed that Codeberg's auto-generated source archives sometimes change checksums 2024-03-29 18:11:33 people read too much into signing imo 2024-03-29 18:12:37 in this case it was done by the person who signs the releases regardless 2024-03-29 18:13:08 Didn't investigate further if it was due to the release being retagged 2024-03-29 18:14:56 all i know is it's just the tukaani.org tarballs, not the github ones. 2024-03-29 18:15:51 no, it is both 2024-03-29 18:16:13 I think the tukaani.org tarballs for newer versions of xz are now being redirected to Github 2024-03-29 18:16:25 there are 2 sets of tarballs on github, one is generated from the git repo itself by github, the other is generated by automake and uploaded by the maintainer 2024-03-29 18:17:34 yeah, that's what i meant -- the github generated ones. 2024-03-29 18:27:57 celie I think it is likely due to retagging 2024-03-29 18:28:06 If not, it should be reported to forgejo 2024-03-29 18:34:47 I think i've seen it in xmppc, the checksums for 0.1.2 has changed (at least) 3 times: https://gitlab.alpinelinux.org/alpine/aports/-/blame/master/community/xmppc/APKBUILD#L40 2024-03-29 18:37:19 Hmm, maybe not 3 times, out of the 3, the first and last are the same, so it has changed back to the original one 2024-03-30 03:10:09 someone mentioned on https://gitlab.alpinelinux.org/alpine/aports/-/commit/982d2c6bcbbb579e85bb27c40be84072ca0b1fd9 that xz is still -r1 on aarch64 2024-03-30 03:12:34 Yes, i mentioned that on #alpine-infra as well 2024-03-30 03:12:50 but i guess...timezones 2024-03-30 03:13:01 ACTION joins 2024-03-30 03:15:30 https://github.com/tukaani-project/xz/ lol 2024-03-30 03:15:36 it's disabled now 2024-03-30 03:20:24 not super surprising 2024-03-30 03:46:36 Yeah, new builds will fail anyway because the tarball link is now that "repo has been disabled" web page 2024-03-30 04:06:01 It's already cached on distfiles: https://distfiles.alpinelinux.org/distfiles/edge/xz-5.6.1.tar.gz 2024-03-30 04:52:04 Okay. Will still affect the downgrade MR though ( https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63132 ) 2024-03-30 05:20:32 Only on the CI, there's an xz-5.4.6.tar.xz on distfiles.a.o too 2024-03-30 05:21:49 Ah, derp. I checked .tar.gz, not .tar.xz 2024-03-30 05:21:59 and if the decision was made to downgrade, source= could be pointed to distfiles before running the CI again 2024-03-30 05:22:43 Yes, .tar.gz is the Github generated source archive 2024-03-30 05:23:09 .tar.xz are/were the "official" tarballs 2024-03-30 07:48:14 lol, I've just compared 'ldd sshd' between alpine and centos7... 4 vs 49 2024-03-30 09:35:03 donoban: linking to libsystemd is "required" in order to write the string "READY=1" into a the readiness socket (which could have been an fd passed down by the parent). 2024-03-30 09:46:49 I feel that it's time to reinstall this server :) 2024-03-30 12:03:33 If anyone can glance at !63032 it would be appreciated :) 2024-03-30 22:44:11 Could someone have a look at !61355? 2024-03-31 04:41:29 ncopa: the new mbedtls LTS branch is 3.6, 2.28 will be maintained until the end of 2024, perhaps we should see if we could upgrade before 3.20 2024-03-31 04:41:32 https://github.com/Mbed-TLS/mbedtls/blob/v3.6.0/BRANCHES.md 2024-03-31 08:39:05 sounds like a good idea 2024-03-31 08:51:07 pkg main/jansson - should be libjansson 2024-03-31 08:51:18 json-c - should be libjson-c 2024-03-31 08:51:46 krb5-conf - will removing heredoc /etc/krb5.conf to separate file make sense 2024-03-31 08:52:02 and libldns.pc - to separate file 2024-03-31 10:40:00 Hi all, I'm packaging a game for Alpine Linux and I'm not sure how I should package an additional theme for it. Should I package it in a separate APKBUILD or should I package it as a subpackage in the games APKBUILD? 2024-03-31 10:40:25 This is what my APKBUILD looks like right now: https://gist.github.com/ungeskriptet/3ba0b9abe807aec6e72ce9ee156180b3#file-apkbuild 2024-03-31 10:41:32 The theme has separate versioning, if that matters 2024-03-31 10:42:30 ungeskriptet: then it would make sense to create a separte APKBUILD for it 2024-03-31 10:46:23 ikke: Alright will do that then 2024-03-31 10:46:33 ACTION forgot depends= exists 2024-03-31 14:14:28 ungeskriptet: why so many vendored deps? 2024-03-31 14:16:30 orbea: The source code has many submodules which is needed for building 2024-03-31 14:16:39 Is there a different way to handle that? 2024-03-31 14:19:29 we already have packages for ffmpeg, libpng, etc etc - you can just depend on them 2024-03-31 14:19:56 (unless the package really does require specific revisions of them, which would be unusual) 2024-03-31 19:10:07 i'm curious: does anybody else experience https://gitlab.gnome.org/sophie-h/glycin/-/issues/50 with loupe? 2024-03-31 19:10:28 i'm wondering whether it was something specific to my laptop and main pc, or whether it's worth backporting the patch to alpine 2024-03-31 19:27:29 oh, yup, here's a convo about it: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/62225#note_389791 2024-03-31 19:39:50 opened https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/63211 2024-03-31 19:39:57 ~~"fix sandbox issue" probably sounds terrifying especially re: the recent security fiascos :D~~ 2024-03-31 19:42:24 oh nvm there's a new release. oops 2024-03-31 19:43:54 wait no, it's a new release of the library. no such thing for loupe... and i applied the patch to the wrong apkbuild. lol, this is why i shouldn't hurry such things