2021-01-01 07:51:16 morning 2021-01-01 07:59:55 good morning and happy new year 2021-01-01 08:10:03 morning 2021-01-01 08:10:20 Didn't sleep so functionally useless 2021-01-01 10:12:31 Looks that Siemens is using Alpine... 2021-01-01 10:12:32 https://download.industrysoftware.automation.siemens.com/open-source/alpine-docker-Build-3.10.3.html 2021-01-01 10:14:40 morning 2021-01-01 10:24:26 morninΓ€ 2021-01-01 10:24:56 already first thing I write this year has typo 2021-01-01 10:26:58 fun, I think mallocng finds more bad behavior 2021-01-01 10:33:55 hmm, not sure if it's the application 2021-01-01 11:49:22 fcolista: they should upgrade to 3.12 though :D 2021-01-01 12:46:06 nmeum, :D 2021-01-01 12:48:25 sed -i unit-tests/Makefile \ 2021-01-01 12:48:25 AinNero-e "/deptgt-delete_on_error/d" 2021-01-01 12:48:27 oops 2021-01-01 12:54:17 heh 2021-01-01 12:55:10 still better than all the hilights i got from people talking about the monero currency 2021-01-01 12:57:39 hmm, how come a patch like this https://gitlab.gnome.org/GNOME/msitools/-/commit/12c03162920e4f7f5049d8608f70278a2d951277.patch causes gobject-introspection start to complain about missing packages? 2021-01-01 12:59:53 https://tpaste.us/K5no 2021-01-01 13:03:43 That's valac complaining, not g-i I think 2021-01-01 13:03:57 And that's definitely not caused by that patch 2021-01-01 13:04:18 Cogitri: the only diffence between it building and not building is adding that patch 2021-01-01 13:05:25 Huh 2021-01-01 13:05:50 Cogitri: my thoughts exactly 2021-01-01 13:05:58 I really don't see how that'd cause valac to fail to compile the project 2021-01-01 13:07:35 me neither 2021-01-01 13:08:28 does just `touch`ing the files create an error? 2021-01-01 13:08:55 it might use some binary cache? 2021-01-01 13:09:55 afontain_: which file? 2021-01-01 13:10:11 I use abuild -r every time, so it builds from scratch 2021-01-01 13:10:12 the files changed by the patch 2021-01-01 13:10:21 (if you remove the patch, that is) 2021-01-01 13:19:13 that seems to be it 2021-01-01 13:19:32 strange 2021-01-01 13:31:48 I think it generates .h when a stamp file does not match 2021-01-01 13:32:41 so they ship pre-generated header files that get rebuild if you touch the source 2021-01-01 13:33:24 if I touch the stamp and the source file at the same time, it continues 2021-01-01 13:33:49 Cogitri: any idea how I could those vala errors? 2021-01-01 13:39:11 Sorry? I think that sentence is missing a few words πŸ˜… 2021-01-01 13:41:29 resolve 2021-01-01 13:42:30 This is the command that fails https://tpaste.us/oPyk 2021-01-01 13:44:28 so it's passing those packages as --pkg flags 2021-01-01 13:53:17 Cogitri: do you know what it looks for when you specify --pkg foo? 2021-01-01 13:55:30 a .pc file apparently 2021-01-01 13:58:06 or .vapi 2021-01-01 14:01:48 Yes. You can specify additional dirs it looks in with --vapidir 2021-01-01 14:02:14 They probably forgot to add --vapidir $SRCFOLDER since that common and config vapi are probably vendored by them 2021-01-01 14:02:23 I think it's becuase gobject-introspection is missing 2021-01-01 14:02:28 there are no .vapi files 2021-01-01 14:02:30 as for libmsi-1.0, no clue what provides that to be honest 2021-01-01 14:02:42 Ah, config and common are probably handwritten files 2021-01-01 14:02:45 libmsi1.0 is part of the project 2021-01-01 14:02:58 The config.vapi is like a config.h for C projects 2021-01-01 14:03:09 It's not generated 2021-01-01 14:04:27 now there is libmsi-1.0.vapi file 2021-01-01 14:05:57 but common / config.vapi are still missing 2021-01-01 14:07:21 sigh 2021-01-01 14:07:30 still complaining about symbol Libmsi missing :( 2021-01-01 14:08:34 FUN 2021-01-01 14:18:13 Ah 2021-01-01 14:18:17 found a clue 2021-01-01 14:18:19 if VAPI 2021-01-01 14:18:25 in the makefile 2021-01-01 14:22:56 finally 2021-01-01 14:23:21 hmm, config remains :( 2021-01-01 14:37:37 Cogitri: is there something that would normally generate a config.vapi file? 2021-01-01 14:37:46 I cannot find any reference 2021-01-01 14:38:31 Nop, normally that's handwritten 2021-01-01 14:39:12 uf 2021-01-01 14:39:30 The file would usually just be 2021-01-01 14:39:30 namespace Config { 2021-01-01 14:39:30 ``` 2021-01-01 14:39:30 public static string VERSION; 2021-01-01 14:39:30 // Some more static strings here for other things 2021-01-01 14:39:30 } 2021-01-01 14:39:30 ``` 2021-01-01 14:39:43 Yes, I found example 2021-01-01 14:39:47 examples* 2021-01-01 14:39:54 just wonder how upstream does it if the file is not there 2021-01-01 14:40:08 Yup, that's weird indeed 2021-01-01 14:40:45 They switched to meson in master 2021-01-01 14:41:45 Wise choice 2021-01-01 14:56:52 https://gitlab.gnome.org/GNOME/msitools/-/blob/master/config.vapi 2021-01-01 14:57:04 they added it when they switched to meson :/ 2021-01-01 15:06:22 Cogitri: i think i know how to reproduce the gnome-software issue 2021-01-01 15:06:40 just bump pkgrel on gnome-software and rebuild 2021-01-01 15:11:32 Yes, the new meson version probably changed how pkgconfig files are generated 2021-01-01 15:11:44 Have you tried the suggestion I posted on the issue? 2021-01-01 15:12:07 static: true? yes 2021-01-01 15:12:11 it didnt work 2021-01-01 15:12:24 manually adding all the deps did work though 2021-01-01 15:15:55 Cogitri: ok, managed to get it to work now 2021-01-01 15:15:57 Cogitri: thanks 2021-01-01 15:16:08 I copied the config.vapi from the master branch 2021-01-01 15:35:53 Okie πŸ‘ 2021-01-01 15:36:40 the other issues disappeared when I did the full ./autogen.sh 2021-01-01 16:22:27 ncopa: why kernels have installkernel in makedepends 2021-01-01 16:45:05 it copies from arch/x86/boot/bzImage to /boot/vmlinuz 2021-01-01 16:46:11 I don't see it in abuild 2021-01-01 16:51:55 https://github.com/torvalds/linux/blob/master/arch/x86/boot/install.sh 2021-01-01 16:55:40 if [ -x /sbin/lilo ]; then 2021-01-01 16:55:53 :) 2021-01-01 16:56:36 no, I'm talking about installkernel in APKBUILD makedepends for linux-* 2021-01-01 16:57:58 isnt installkernel script for making modloop etc thing with rpi stuff? 2021-01-01 16:58:44 /sbin/installkernel is script and it quite short to read 2021-01-01 16:59:04 it just copies few files 2021-01-01 16:59:51 I don't see where it is used in building kernels 2021-01-01 17:05:03 ah ye, sorry, mixed it with "update-kernel" ... my bad! 2021-01-01 17:06:38 np 2021-01-01 17:11:44 https://github.com/torvalds/linux/blob/master/arch/x86/boot/install.sh#L37 2021-01-01 17:13:25 is it used in alpine 2021-01-01 17:14:05 huh? 2021-01-01 17:23:46 I can't find that /sbin/installkernel is used anywhere 2021-01-01 17:24:24 it is used in install.sh 2021-01-01 17:24:26 as i said 2021-01-01 17:26:01 where? 2021-01-01 17:29:54 https://github.com/torvalds/linux/blob/master/arch/x86/boot/install.sh#L37 2021-01-01 17:31:25 huh, I'm not talking about linux install.sh, but about installkernel alpine pkg 2021-01-01 17:33:34 I don't see in APKBUILD definition of INSTALLKERNEL variable 2021-01-01 17:33:58 nor in /usr/bin/abuild 2021-01-01 17:47:31 it's only me that lxc-create for alpine fails with mknod: dev/zero: File exists ? 2021-01-01 17:47:42 usgin alpine template 2021-01-01 17:48:06 lxc-create -n test -t alpine 2021-01-01 17:48:20 lxc-4.0.5-r0 2021-01-01 17:48:31 edge 2021-01-01 17:48:45 lxc-templates-legacy-alpine-3.0.3-r1 2021-01-01 17:50:19 mps: ok, I walk this through one step at a time. https://git.alpinelinux.org/aports/tree/main/linux-lts/APKBUILD calls "make install" (except arm/arm64). this target is defined in https://github.com/torvalds/linux/blob/master/arch/x86/boot/Makefile, which calls https://github.com/torvalds/linux/blob/master/arch/x86/boot/install.sh. install.sh checks if /sbin/${INSTALLKERNEL} exists, which 2021-01-01 17:50:20 expands to /sbin/installkernel using the definition at https://github.com/torvalds/linux/blob/master/Makefile#L452 exported at https://github.com/torvalds/linux/blob/master/Makefile#L510 2021-01-01 19:02:09 Hello71: right, and this is why I'm not sure we need it installkernel in makedepends 2021-01-01 19:02:50 I'm testing linux-elm build without it, and it works fine 2021-01-01 19:05:48 fcolista: looks like bug somewhere 2021-01-01 19:18:50 fcolista: i use lxc-download now 2021-01-01 19:19:03 fcolista: lxc-create -t download -- -a amd64 -d alpine -v edge 2021-01-01 20:08:34 mps: no, it is required 2021-01-01 20:13:40 Hello71: it can work without it but decided to keep it to be 'in-line' with linux-lts 2021-01-01 20:14:29 well i think it will not install to syslinux expected location 2021-01-01 20:19:18 for linux-elm it is not needed, because kernel instalation is specific on these chromebooks 2021-01-01 20:44:22 could be 2021-01-01 20:44:59 I think "correct" solution would be to make installkernel-elm 2021-01-01 20:45:16 but probably too much work 2021-01-01 20:53:17 yes 2021-01-01 21:25:03 HRio: merged 2021-01-01 22:43:04 mps: big thanks! 2021-01-01 23:38:29 HRio: np 2021-01-02 12:06:00 !15635 is (finally) ready. I'd like it in Alpine 3.13 if possible still. CI currently only fails because of too large artifacts to upload 2021-01-02 12:09:54 done 2021-01-02 12:10:01 Oh awesome, thanks for the quick reply! 2021-01-02 12:10:05 :) 2021-01-02 12:10:23 Ikke, you still using mkmr and mgmr ? 2021-01-02 12:10:29 maxice8: once in a while 2021-01-02 12:11:05 I saw your note 2021-01-02 12:25:42 PureTryOut[m]2: is it a mistake that there is a pacakge called itinerary in testing with pkgname kitinerary? 2021-01-02 12:27:17 Sounds like it, huh. If pkgname doesn't equal the directory name, then yes that's a mistake 2021-01-02 12:27:43 :) 2021-01-02 12:40:07 PureTryOut[m]2: what should happen with it? 2021-01-02 12:41:25 I'll make a MR to fix it 2021-01-02 12:42:16 ok 2021-01-02 13:04:39 ikke: !16355 2021-01-02 13:05:14 so they have both kitinerary and itinerary? 2021-01-02 13:06:16 PureTryOut[m]2: 'kpublictransport-dev (no such package):" 2021-01-02 13:08:27 Wait for the builders to catch up 2021-01-02 13:08:39 that package hasn't appeared in the repos yet but is in aports 2021-01-02 13:08:57 And yes, itinerary depends on kitinerary. The former is an end-user application, the latter a library 2021-01-02 13:09:06 I get the confusion πŸ˜‰ 2021-01-02 13:09:24 :) 2021-01-02 13:29:25 built locally 2021-01-02 13:34:06 I'll disable it on s390x 2021-01-02 13:34:28 πŸ‘οΈ 2021-01-02 13:35:30 and mips64 2021-01-02 16:33:56 PureTryOut[m]2: kgpg is failing on aarch64 and ppc64le, kosmindoormap is faiiling on x66 2021-01-03 14:37:18 !16388 2021-01-04 07:31:04 morning 2021-01-04 07:34:24 Morning 2021-01-04 07:40:21 hi 2021-01-04 07:42:02 seems like crystal built? i wonder if it was related the musl update 2021-01-04 07:45:43 musl is updated? didn't noticed. nice if crystal is fixed 2021-01-04 07:51:38 only mips64 is left now 2021-01-04 07:52:03 seems like all other arches are idle for 3.13 2021-01-04 07:54:33 Hooray 2021-01-04 07:55:55 is 'freeze' planed on some date? 2021-01-04 08:01:30 we have been in a "soft freeze" for some time already 2021-01-04 08:01:48 i think we'll do rc1 today 2021-01-04 08:02:59 is that (rc1) some kind of freeze 2021-01-04 08:04:07 I planned to move few pkgs from testing to community and upgrade and test some pkgs, but didn't find enough time (yet) 2021-01-04 08:07:12 so, what we want avoid now is breakages that slows us down 2021-01-04 08:07:53 you can upgrade things that are low risk, or if you know that you have time to follow up breakages 2021-01-04 08:08:06 within reasonable time (not weeks) 2021-01-04 08:08:22 i'm just waiting on dalias to tag 1.2.2 2021-01-04 08:08:28 thats all for 3.13 :) 2021-01-04 08:09:40 looks like `convert` cannot generate png files on mips64 2021-01-04 08:10:31 likely endianness 2021-01-04 08:11:52 !16352 looks like it doesn't breaks things, but not sure. and it is not yet officially announced though they have more than a year of fixes 2021-01-04 08:15:24 also, looking at kernel -rc looks like 5.10 (-lts) will have some important fixes for amd gpu fixes (5.10.6 probably) 2021-01-04 08:16:36 but yes, fixes and bugs will be always around 2021-01-04 08:22:35 morning 2021-01-04 08:24:44 ikke: \o 2021-01-04 08:29:34 ncopa: PureTryOut[m]2 had an MR for kosmindoormap 2021-01-04 08:30:09 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12254#note_133404 2021-01-04 08:30:27 ncopa: are you sure crystal pass checj. just tried on x86_64 and got '..Invalid memory access (signal 11) at address 0x7fb1a0a33538' 2021-01-04 08:30:40 s/checj/check/ 2021-01-04 08:30:40 mps meant to say: ncopa: are you sure crystal pass check. just tried on x86_64 and got '..Invalid memory access (signal 11) at address 0x7fb1a0a33538' 2021-01-04 08:31:15 junk 2021-01-04 08:32:34 now trying more conservative build 2021-01-04 08:55:20 oh, i forgot to check for MRs 2021-01-04 08:56:30 mps: libpcap/tcpdump can be merged 2021-01-04 08:56:42 just remove the "draft" in the MR 2021-01-04 09:10:31 hmm, no more WIP, now it Draft :) 2021-01-04 09:10:35 removed 2021-01-04 09:13:22 and merged 2021-01-04 09:14:42 thanks 2021-01-04 09:15:31 np 2021-01-04 09:16:15 thank you for encouragement :) 2021-01-04 09:16:37 mps: yes, gitlab feels 'Draft' is more easily understood and does not indicate you are working on it 2021-01-04 09:18:55 hmm, when the people stop to change words especially established ones and well understood 2021-01-04 09:19:51 will stop* 2021-01-04 09:20:45 oh yes, they want/need more commits to be hired :) 2021-01-04 09:37:09 is the gitlab stuck on something? I pushed new MR but it doesn't appears in web ui 2021-01-04 09:38:17 Does it appear now? 2021-01-04 09:39:11 not yet 2021-01-04 09:43:28 would be 'git push --force mps' of help 2021-01-04 09:44:14 force only works if there is something to push 2021-01-04 09:44:25 Can you check if the branch is visible in your fork 2021-01-04 09:44:30 aha 2021-01-04 09:44:53 will now 2021-01-04 09:45:31 yes, it is https://gitlab.alpinelinux.org/mps/aports/-/tree/svxlink-move2community 2021-01-04 09:46:03 Then you should be able to create an MR from there 2021-01-04 09:47:52 aha, I see 2021-01-04 09:48:11 thanks 2021-01-04 10:03:46 would be bpfmon of use in community for 3.13 release? 2021-01-04 10:04:00 would be nice to have 2021-01-04 10:04:52 ok, will move after breakfast 2021-01-04 10:14:53 I ran glxgears and the window content stood still 2021-01-04 10:15:09 only when I resized the window did the gears move 2021-01-04 10:15:20 could anyone help with this? 2021-01-04 10:15:32 GL_RENDERER = Mesa Intel(R) UHD Graphics 620 (WHL GT2) 2021-01-04 10:15:33 GL_VERSION = 4.6 (Compatibility Profile) Mesa 20.0.7 (git-53b2b224dc) 2021-01-04 10:15:33 GL_VENDOR = Intel 2021-01-04 10:16:30 under what desktop, etc 2021-01-04 10:16:34 ok 2021-01-04 10:16:46 note that #alpine-linux is a better channel for these kinds of questions 2021-01-04 10:17:06 UHD620, X.Org X Server 1.20.10, MATE 1.24.0, everything vanilla 2021-01-04 10:17:12 and no relevant configs changed 2021-01-04 10:17:37 ikke: got it, however my problem seems to be a GL redrawing bug borking my 3d accel, so I came to this channel 2021-01-04 10:19:12 ACTION thinks it would be an actual bug... 2021-01-04 10:23:26 what's the policy about backporting a package from edge/testing to a stable release like 3.12 ? 2021-01-04 10:26:58 I don't think we commonly do those kinds of backports 2021-01-04 10:32:09 ok, that is what I suspected...thx 2021-01-04 10:34:49 ikke, moving a package from testing to package needs a bump of pkgver? 2021-01-04 10:34:53 I always forget this... 2021-01-04 10:35:04 No, not required 2021-01-04 10:35:22 ok, thanks! 2021-01-04 10:35:45 (the only reason to do this would be to force an upgrade for some reason) 2021-01-04 11:10:29 i think we can do exceptions and add new packages to 3.12-stable, if they already are in edge/{main,community} and are tested and known to work 2021-01-04 11:10:54 its better to backport a package than mix v3.12 + edge repos 2021-01-04 11:11:08 yes, the latter is error prone 2021-01-04 11:12:01 I agree 2021-01-04 11:12:33 but we should be careful when backporting 2021-01-04 11:13:35 yes, but adding new packages should be relatively harmless 2021-01-04 11:15:29 it should be, but again carefully 2021-01-04 11:18:21 +1 2021-01-04 11:19:01 \o/ mips64 builder is uploading 3.13 2021-01-04 11:19:11 we shoudl be able to do rc1 today 2021-01-04 11:22:57 nice 2021-01-04 11:23:32 I wonder how crystal pass in builders but not in my dev lxc /o\ 2021-01-04 11:23:49 good question 2021-01-04 11:23:56 did you update musl version? 2021-01-04 11:24:01 yes 2021-01-04 11:24:14 updated everything 2021-01-04 11:24:49 but ok, we can disable compiler check if it fail at final release build, I think 2021-01-04 11:25:50 I didn't got any answer from boehm gc developers not from crystal 2021-01-04 11:26:17 i dont think problem is in boehm gc 2021-01-04 11:26:30 maybe it is not 2021-01-04 11:27:36 we have this for long time #10918 2021-01-04 12:15:05 ncopa: thanks for the merge 2021-01-04 12:18:40 too late for busybox upgrade? 2021-01-04 12:38:49 busybox upgrade? sounds risky. they tend to break stuff 2021-01-04 12:39:46 last-minute busybox upgrade might not be a good idea... 2021-01-04 12:40:03 one minor inconsistency would ruin something 2021-01-04 12:42:44 ncopa: also to me, current patches in aports need review. yes, after release 2021-01-04 12:48:25 tpanmajia: did you remove nomodeset from kernel command line 2021-01-04 12:48:58 Hello71: wait I didn't 2021-01-04 12:49:23 Hello71: any method for permanently remove this kernel param 2021-01-04 12:52:20 tpanmajia: yes, edit /etc/update-extlinux.conf 2021-01-04 12:53:33 mps: got it 2021-01-04 12:53:45 Hello71, mps: actually is grub managed by this config? 2021-01-04 12:54:48 or for grub /etc/default/grub 2021-01-04 12:55:02 but these questions are for #alpine-linux 2021-01-04 12:55:18 bruh 2021-01-04 12:55:45 mps: I didn't find nomodeset in /etc/default/grub though 2021-01-04 12:56:19 what says 'cat /proc/cmdline' 2021-01-04 12:57:07 mps: it has nomodeset 2021-01-04 12:57:25 alpine 10-linux.sh reads /etc/update-extlinux.conf 2021-01-04 12:57:44 Hello71: oh thx 2021-01-04 12:57:51 Hello71: it's sourced as a shell script 2021-01-04 12:58:00 going to restart 2021-01-04 12:58:21 but this is for syslinux, not grub afaik 2021-01-04 14:17:51 im gonna tag 3.13.0_rc1 now 2021-01-04 14:18:15 \o/ 2021-01-04 14:27:38 hum... i think i messsed up 2021-01-04 14:45:39 looks like things are broken 2021-01-04 14:46:25 what kinds of things? 2021-01-04 14:46:46 Signing: /tmp/update-kernel.jMiiHO/boot/modloop-lts 2021-01-04 14:46:46 gzip: invalid magic 2021-01-04 14:46:46 tar: Error is not recoverable: exiting now 2021-01-04 14:46:46 tar: Child returned status 1 2021-01-04 15:46:30 ncopa: Should we wait with !16405 until post 3.13? 2021-01-04 15:46:46 Technically we should, but that does fix a lot of stuff 2021-01-04 15:46:58 We could wait and then backport it if it's fine in edge too 2021-01-04 15:47:51 Also, I only know learned about https://pkgs.alpinelinux.org/flagged, that's pretty nifty :D 2021-01-04 16:05:21 i dont mind merging !16405 once the first release candidate is out - as long as nothign breaks 2021-01-04 16:05:49 oh... i thikn i know why the release fails 2021-01-04 16:10:26 does anybody mind if I just go ahead and merge https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/76 ? 2021-01-04 16:15:36 probably ok. it wil not break armv6? 2021-01-04 16:26:35 ncopa: Okie, I'll wait until the RC is fixed then, thanks 2021-01-04 16:57:54 ncopa: don't think so, if riscv64-alpine-linux-musl is present the config.sub should be new enough to also contain armv6-alpine-linux-muslgnueabihf 2021-01-04 17:00:54 looks like musl discovered bug in dovecot, 'Error: mmap_anon(.test_file_cache, 4096) failed: Out of memory' 2021-01-04 17:01:14 and 'Error: mremap_anon(.test_file_cache, 8192) failed: Out of memory' 2021-01-04 18:32:01 i pushed rc2 2021-01-04 18:37:08 I see. does it means that the commits to edge don't go to 3.13 now 2021-01-04 18:56:18 mps: They still do, there's no 3.13-stable branch yet 2021-01-04 18:57:40 huh, just created !16429 not sure should I merge it 2021-01-04 18:58:02 ncopa: ^ 2021-01-04 18:58:09 mps: ncopa said that, as long as it's low risk (ie, not breaking something, not breaking the build), you can still merge things 2021-01-04 18:58:26 And we would want a minor upgrade + cve fixes in 3.13 anyway 2021-01-04 18:58:34 yes 2021-01-04 18:59:07 Just avoid doing upgrades that would affect a lot of packages 2021-01-04 18:59:12 it pass on my dev lxc and on CIs 2021-01-04 18:59:32 dovecot shouldn't affect any 2021-01-04 18:59:40 except self :) 2021-01-04 19:00:13 And you can always revert if it's broken 2021-01-04 19:00:34 and pleasure is work on fixing bugs with dovecot upstream author (cmouse on #dovecot) 2021-01-04 19:01:34 no, everything looks ok, but I think some configs are changed in this 'major' release, which is normal 2021-01-04 19:31:15 merged riscv abuild patches 2021-01-04 19:31:17 *the 2021-01-04 19:33:59 3.12.3 -> 3.13.0_rc2 "Linux 5.10.3-0-rpi4 #1-Alpine SMP PREEMPT Mon Dec 28 09:29:44 UTC 2020 aarch64 GNU/Linux" 2021-01-04 19:34:25 looks like working fine on rpi4 :) no issues with upgrade 2021-01-04 19:34:25 whee 2021-01-04 20:13:29 is it normal that there are two different versions of same package like this? 2021-01-04 20:13:33 https://pkgs.alpinelinux.org/packages?name=cpupower*&branch=edge&arch=x86_64 2021-01-04 20:14:36 no, that's not normal 2021-01-04 20:15:16 seems that for some reason, the old package was never removed 2021-01-04 20:15:34 oh, thought I rly have to install -openrc package manualy 2021-01-04 20:16:42 but then new one doesnt provide any cpupower.initd or cpupower.confd 2021-01-04 20:16:50 hmm, seems like that cpupower-5.10.1-r0.apk is out-of-place 2021-01-04 20:17:37 that was first issue with rpi4... is slow because cpu frequencies are all time low 2021-01-04 20:18:08 without cpupower-openrc package of course 2021-01-04 20:18:10 aha 2021-01-04 20:18:13 I see what happened 2021-01-04 20:18:28 there is a cpupower package, but also a cpupower subpackage from linux-tools 2021-01-04 20:18:38 which is quite confusing :) 2021-01-04 20:18:38 linux-too.. 2021-01-04 20:19:41 yeah 2021-01-04 20:19:47 now I see that too 2021-01-04 21:32:35 just in case, created issue #12272 2021-01-04 21:36:25 MY-R: thanks 2021-01-04 21:39:46 :) 2021-01-04 22:39:45 hmm, hmmmm, #12272 2021-01-04 22:40:24 old one should be remove 2021-01-04 22:40:29 ? 2021-01-04 22:42:33 but what to do with nls.patch 2021-01-04 22:49:26 both provide same things if not count extra -openrc files 2021-01-04 22:50:15 hmm, need check maybe patch is in newer version already 2021-01-04 22:50:52 no, it is old version 2021-01-04 22:51:55 I mean maybe newer version was already patched by upstream 2021-01-04 22:52:34 cpupower-libs.patch 2021-01-04 22:56:22 dunno, cpupower from linux-tools working for me just fine 2021-01-04 22:57:17 other one is outdatet, from 5.4.xx 2021-01-04 22:57:26 yeah 2021-01-04 22:57:29 outdated* 2021-01-04 22:58:44 but people who using cpupower-openrc service after upgrade will lost that "function" or will be wondering why the hell their computers are slower or dunno, overheating :P 2021-01-04 22:58:59 i'm working on it, have to conclude how to add -openrc to subpkg 2021-01-04 22:59:19 I dont really need that init.d script, just added cpupower to local.d 2021-01-04 22:59:46 though maybe it should be set by end users in /etc/local.d/ 2021-01-04 23:00:10 eh, you read my mind or I yours :) 2021-01-04 23:00:29 is some old gentoo script but working fine too 2021-01-04 23:01:06 heh 2021-01-04 23:02:16 I could put all services in local.d like in bsd style daemons and have got full control and predictable start order 2021-01-04 23:02:23 I think I got it, i.e. build cpupower-openrc from linux-tools 2021-01-04 23:02:52 that is what I'm missing in ifupdown-ng now because cant tell interface with dhcp to start last after my local network interface :\ 2021-01-04 23:02:54 yes, that is what I do in some cases where need more control 2021-01-04 23:03:48 ye another reason why I have to say sorry to "runit" init 2021-01-04 23:04:18 dont like when all stuff start in same time because not all are wroten good enough to do such a crazy things ;) 2021-01-04 23:04:44 a supervision suite is not a service manager 2021-01-04 23:04:50 those do very different things 2021-01-04 23:05:01 runit can have 'need' iirc 2021-01-04 23:05:09 runit is not a service manager, which is why it yolos everything at the same time 2021-01-04 23:05:14 no 2021-01-04 23:05:39 if there's an ordering in runit services it's a function of the service manager it's paired with 2021-01-04 23:06:26 long time ago read about it and never tested, so probably you are right 2021-01-04 23:07:28 I know... a thing or two about that space 2021-01-04 23:08:26 I think so :) 2021-01-04 23:08:51 I thought I knew your nick from somewhere... skarnet do you have something common with supervision@list.skarnet.org ? :D 2021-01-04 23:09:07 MY-R: yup, and I'm the s6 guy 2021-01-04 23:09:19 :) 2021-01-04 23:10:06 MY-R: :D 2021-01-04 23:10:37 MY-R: !16438 2021-01-04 23:10:53 there is cpupower-openrc 2021-01-04 23:12:01 mps: sweet, so now 3.13 can be released ;) 2021-01-04 23:12:18 mps: thanks btw 2021-01-04 23:12:45 today you are in good mood :) 2021-01-04 23:13:24 :P 2021-01-04 23:13:29 but I have to go to bed, too late is now, good night 2021-01-04 23:13:38 sleep well! 2021-01-04 23:13:50 thanks. will try 2021-01-05 08:01:42 morning 2021-01-05 08:01:47 morning 2021-01-05 08:06:51 πŸ‘‹ 2021-01-05 08:17:09 good morning 2021-01-05 08:17:45 ncopa: !16438 duplicate package in community fix (or try to fix) 2021-01-05 09:08:53 a lot of changes of just released ppp, not sure should we upgrade for 3.13 2021-01-05 09:11:51 here is MR for review !16441 2021-01-05 09:21:24 mps: hold until post-3.13 2021-01-05 09:31:13 makes sense, we already have CVE-2020-8597 in current in aports 2021-01-05 09:31:33 I fixed this cve 2021-01-05 09:37:58 'vlan' package shouldnt be removed from .iso/tar.gz images since ifupdown-ng provide that function? 2021-01-05 09:43:30 and 'bridge' package too 2021-01-05 09:53:26 aaaand 'bonding' 2021-01-05 09:56:12 hmm those are pulled by meta pkg 'network-extras' 2021-01-05 10:05:07 bridge and bonding should stay, vlan not. 2021-01-05 10:05:23 ifupdown-ng has vlan built in, but we haven't switched to ifupdown-ng bridge/bond yet 2021-01-05 10:08:35 oh ok :) 2021-01-05 10:10:24 Ariadne: I guess we can mention that in the release notes? 2021-01-05 10:12:41 https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.13.0#Switching_from_busybox_ifupdown_to_ifupdown-ng 2021-01-05 10:48:01 I have no luck with -openrc packages :D 'murmur' pkg doesnt install automaticly 'murmur-openrc', mps did you touch it? ;) 2021-01-05 10:49:16 It's because someone created that subpackage manually 2021-01-05 10:49:28 so it does not have the auto install logic 2021-01-05 10:49:36 ugh... backporting osinfo-db is messy. its not just to add patches 2021-01-05 10:49:51 ikke: ye in 3.12 there wasnt -openrc package 2021-01-05 10:50:00 I'm looking at edge 2021-01-05 10:50:27 https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/mumble/APKBUILD#L94 2021-01-05 10:50:47 I think the contents can just be replaced with `default_openrc` 2021-01-05 10:51:03 I can't remember, last time I touched murmur is cd745397ee4b343e63305461c9187035f48a67ba 2021-01-05 10:51:47 ye, Im just testing 3.13rc2 and that is second service which didnt start because "missing" -openrc :) 2021-01-05 10:53:16 MY-R: something like this should work: https://tpaste.us/maNL 2021-01-05 10:54:47 fcolista: i added an MR for alpine https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/264 2021-01-05 10:54:54 to osinfo-db 2021-01-05 10:55:16 ikke: yeah 2021-01-05 10:55:41 ncopa, cool. 2021-01-05 10:55:53 I can babysit it 2021-01-05 10:56:56 I don't see aarch64 2021-01-05 10:57:07 because we dont provide any .iso 2021-01-05 10:57:21 ah that is for ISO only? 2021-01-05 10:57:33 osinfo only detects iso and disk images 2021-01-05 10:57:37 ok, I missed it 2021-01-05 10:58:04 its really difficult to test the osinfo-db 2021-01-05 10:58:26 its not just to create patches to community/osinfo-db 2021-01-05 10:58:43 dockerize the apk and test against the new-iso? 2021-01-05 10:58:58 no 2021-01-05 10:59:07 apk containing the support of new alpine versions 2021-01-05 10:59:29 the genereated db does not include the makefile so the patched .xml.in is not included in .apk 2021-01-05 10:59:52 so im runnining make, and uploading the tarball to dev.a.o 2021-01-05 11:00:07 they dont do tags in their git repo either 2021-01-05 11:00:39 so basically, we need get things upstream to be able to get the data 2021-01-05 11:01:14 ok 2021-01-05 11:01:26 we should also add tests to upstream 2021-01-05 11:01:44 there is a script for that in scripts/ 2021-01-05 11:02:14 https://gitlab.com/ncopa/osinfo-db/-/blob/master/scripts/osinfo-db-add-iso.py 2021-01-05 11:02:18 we can do something like this, for alpine: 2021-01-05 11:02:18 https://gitlab.com/libosinfo/osinfo-db/-/blob/master/scripts/updates/nixos.py 2021-01-05 11:02:23 yeah 2021-01-05 11:02:58 but i dont have time to mess around with it. i already spent more time that i should on this, because i wanted virt-manager to detect 3.13 2021-01-05 11:03:28 btw, libvirtd for 3.13 is not fixed yet 2021-01-05 11:04:13 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12007#note_119129 2021-01-05 11:04:56 does it still happen with 3.13? 2021-01-05 11:05:25 its kind of expected with 3.12, which does not work with malloc after fork 2021-01-05 11:05:40 and qemu does alot of that 2021-01-05 11:06:05 which is why we decided to work around it in musl. the workaround has not been backported to 3.12 2021-01-05 11:06:31 ah ok. I remember that malloc issue, but I didn't know that there was a workaround for 3.13 2021-01-05 11:08:09 finally.. 2021-01-05 11:08:12 $ osinfo-detect ~/Downloads/alpine-virt-3.13.0_rc2-x86_64.iso 2021-01-05 11:08:12 Media is bootable. 2021-01-05 11:08:12 Media is an installer for OS 'Alpinelinux 3.13 Virtual (x86_64)' 2021-01-05 11:08:33 \0/ 2021-01-05 11:08:40 2021-01-05 11:08:42 we need to get it upstreamed 2021-01-05 11:09:07 so we needto wait for them to merge your patches 2021-01-05 11:10:30 i think they will request more patches with tests 2021-01-05 11:10:34 before they merge 2021-01-05 11:10:52 but lets see 2021-01-05 11:11:23 i'm glad if you can try follow it up in the future 2021-01-05 11:11:38 make sure that osinfo-detect works on our images 2021-01-05 11:11:53 i think we may want add back the virtio devices for alpine too 2021-01-05 11:14:19 heh... fcolista: do yo think you can help me with https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/264#note_478231680 2021-01-05 11:14:29 actually, i should follow upt this time 2021-01-05 11:16:54 hmm we don’t provide iso for aarch64? i’m pretty sure i installed from an ISO on my honeycomb 2021-01-05 11:18:34 oh virt 2021-01-05 11:20:57 what's this then https://dl-cdn.alpinelinux.org/alpine/v3.12/releases/aarch64/alpine-standard-3.12.3-aarch64.iso 2021-01-05 11:21:00 fcolista: maybe we should add aarch64 to there 2021-01-05 11:22:06 ncopa: ping 2021-01-05 11:22:21 ah he is here already :) 2021-01-05 11:22:32 ncopa: did we set repos already to https? 2021-01-05 11:23:13 by default i mean 2021-01-05 11:23:16 clandmeter: doesn't that depend on what mirror is selected from mirrors.a.o? 2021-01-05 11:23:43 for docker, we did 2021-01-05 11:23:47 does it? 2021-01-05 11:23:56 does it not auto select http? 2021-01-05 11:24:16 maybe, I don't know how it behaves when there is both http and http(s) 2021-01-05 11:24:24 s/(s)/s 2021-01-05 11:24:24 ikke meant to say: maybe, I don't know how it behaves when there is both http and https 2021-01-05 11:24:29 im asking because on for instance on linode it is still using http 2021-01-05 11:24:48 and i have a feeling (like ncopa mention before) there is some black magic going on when using http. 2021-01-05 11:25:04 so updating indexes is slow on http 2021-01-05 11:26:12 and now that dl-cdn has https support, i think we could make it the default. 2021-01-05 11:27:10 clandmeter: It uses this list: https://mirrors.alpinelinux.org/mirrors.txt 2021-01-05 11:27:45 so we need to fix alpine-mirrors to return https when available 2021-01-05 11:28:42 But I'm wondering what you mean with "updating indexes is slow on http" 2021-01-05 11:34:36 apk update 2021-01-05 11:35:47 is that a libfetch issue? 2021-01-05 11:35:53 I wonder how https can be faster 2021-01-05 11:36:29 i think we use https by default for docker at least 2021-01-05 11:36:35 yes, we do 2021-01-05 11:36:43 on edge, not yet on 3.12 2021-01-05 11:37:05 i thiknw e shoudl use https by default everywhere 2021-01-05 11:37:28 i have a feeling that there are intecepting proxies that injects stuff when using http 2021-01-05 11:39:26 re: https: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/18 (same applies to 3.12.3 notes, I guess due to copy/paste) 2021-01-05 11:56:02 clandmeter: https://gitlab.alpinelinux.org/alpine/infra/mirror-status/-/merge_requests/4 2021-01-05 11:56:11 (untested) 2021-01-05 12:08:57 fcolista: re osinfo-db, we should have a script that fetches latest-releases.yaml, and then fetches all *.iso images and generates test data for osinfo-db 2021-01-05 12:12:33 similar to this: https://github.com/alpinelinux/docker-alpine/blob/master/fetch-latest-releases.lua 2021-01-05 13:04:02 ncopa, I can do that 2021-01-05 13:04:08 (back now from lunch) 2021-01-05 13:35:04 Ariadne: if you have few minutes can you check https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16341 one-line change 2021-01-05 14:43:27 ncopa: minor issue in your os-info MR, file alpinelinux-3.13.xml.in has 'upgrades' and 'derives-from' tags referencing 3.11 rather than 3.12 2021-01-05 15:52:27 minimal: thanks for the review. will update 2021-01-05 18:17:25 PureTryOut[m]: kclock currently fails to build on the builders 2021-01-05 18:17:35 just FYI 2021-01-05 18:19:44 I saw it, not sure why as it built locally and on CI. Not currently on a PC to fix it 2021-01-05 18:20:19 > No rule to make target 'src/org.kde.kclockd.KClockSettings.xml', needed by 'src/kclock/kclocksettingsinterface.cpp'. 2021-01-05 18:20:28 could be a parallel build issue 2021-01-05 18:20:45 not urgent either way :D 2021-01-05 19:08:09 im trying to fix the scripts/bootstrap.sh, but im getting libtool related errors now. not sure why it happens or what the proper fix is: 2021-01-05 19:08:18 make[3]: Leaving directory '/home/ncopa/aports/main/pcre/src/pcre-8.44' 2021-01-05 19:08:18 /usr/lib/libgcc_s.so.1: file not recognized: file format not recognized 2021-01-05 19:08:18 make[2]: *** [Makefile:1538: install-libLTLIBRARIES] Error 1 2021-01-05 19:08:18 libtool: error: error: relink 'libpcreposix.la' with the above command before installing it 2021-01-05 19:08:18 collect2: error: ld returned 1 exit status 2021-01-05 19:08:42 looks like /usr/lib/libgcc_s.so.1 (not from sysroot) gets pulled in for some reason 2021-01-05 19:12:06 at a guess, it's "libtool sucks" :p 2021-01-05 19:15:42 Probably :D 2021-01-05 19:16:46 :/ 2021-01-05 19:16:59 the host environment is leaking into the build somehow 2021-01-05 19:19:30 yeah. i wonder how/why 2021-01-05 19:20:06 i "fixed" brotli package by changing to cmake 2021-01-05 19:22:02 i suppose i could use slibtool 2021-01-05 19:25:00 does it not know you're cross compiling? 2021-01-05 19:30:21 it should yes 2021-01-05 19:31:42 libtool: install: (cd /home/ncopa/aports/main/pcre/src/pcre-8.44; /bin/sh "/home/ncopa/aports/main/pcre/src/pcre-8.44/libtool" --silent --tag CC --mode=relink armv7-alpine-linux-musleabihf-gcc -fvisibility=hidden --sysroot=/home/ncopa/sysroot-armv7/ -Os -fomit-frame-pointer -version-info 0:7:0 --sysroot=/home/ncopa/sysroot-armv7/ -Wl,--as-needed 2021-01-05 19:31:42 -o libpcreposix.la -rpath /usr/lib libpcreposix_la-pcreposix.lo libpcre.la -inst-prefix-dir /home/ncopa/aports/main/pcre/pkg/pcre) 2021-01-05 19:32:07 it knows, the --sysroot is there 2021-01-05 19:32:10 is the tuple the same as host tho? 2021-01-05 19:32:29 just sysroot doesn't imply cross compiling and libtool probably won't honor it to avoid pollution from host 2021-01-05 19:32:39 no, this is on an x86_64 machine 2021-01-05 19:32:45 weird 2021-01-05 19:32:58 how did -rpath /usr/lib get there? 2021-01-05 19:33:15 i think libtool adds it 2021-01-05 19:38:30 what is pulling li libgcc_s though? 2021-01-05 19:45:28 + eval 'cmd="$CC' -shared '$pic_flag' '$libobjs' '$deplibs' '$compiler_flags' '$wl-soname' '$wl$soname' -o '$lib"' 2021-01-05 19:45:28 + cmd='armv7-alpine-linux-musleabihf-gcc -shared -fPIC -DPIC .libs/libpcreposix_la-pcreposix.o -L/home/ncopa/aports/main/pcre/pkg/pcre/usr/lib -L/usr/lib -lpcre --sysroot=/home/ncopa/sysroot-armv7/ -Os --sysroot=/home/ncopa/sysroot-armv7/ -Wl,--as-needed -Wl,-soname -Wl,libpcreposix.so.0 -o .libs/libpcreposix.so.0.0.7' 2021-01-05 19:45:28 + IFS=' 2021-01-05 19:45:50 it adds -L/usr/lib 2021-01-05 19:46:00 i wonder what does that and how to prevent it to 2021-01-05 19:50:52 ikke: on the draft release notes wiki page, you say `making it unsuitable to link it to packages with a GPG incompatible license` ... did you mean GPG? 2021-01-05 19:51:39 It should be GPL 2021-01-05 20:01:58 ok, its the -rpath thingy that causes the problem 2021-01-05 20:02:05 now i wonder where the -rpath comes from 2021-01-05 20:04:47 368:am_libpcreposix_la_rpath = -rpath $(libdir) 2021-01-05 20:06:32 what does it mean -fstrict-aliasing is on by default now? it is enabled by -O2 and has been for a long, long time: https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html 2021-01-05 20:09:28 Hello71: I think alpine generally uses -Os 2021-01-05 20:09:47 should be same 2021-01-05 20:34:39 Hello71: Ok, I mostly just write the things I catch being mentioned here 2021-01-05 20:36:53 Hello71: thanks for fixing up the release notes 2021-01-05 21:05:24 fun, docker-compose on 3.12 is broken 2021-01-05 21:16:37 Python stuff? 2021-01-05 21:19:35 yeah, it uses platform.linux_distribution(), which has been removed 2021-01-05 21:19:46 https://github.com/docker/compose/commit/a62a1e1d6273d1b2021b072603ee9ffc86afc5c5 2021-01-05 21:19:50 backporting that 2021-01-05 21:21:52 Yuck 2021-01-05 21:22:26 It has been deprecated since python 3.6 already 2021-01-05 21:24:25 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16483 2021-01-05 21:28:17 I'm yakshaving an adjustment to CI to skip uploading the artifacts when they are too large 2021-01-05 21:29:00 Cogitri: btw, I still have a commit that was not pushed yet to store parts of the build output in files 2021-01-05 21:29:34 That'd still be nice to have :) 2021-01-05 21:30:02 ok 2021-01-05 21:30:21 Trying to remember why I did not push that yet 2021-01-05 21:30:26 Thanks for looking into it 2021-01-05 21:30:43 Heh 2021-01-05 21:31:36 Hm, I don't think you mentioned something specific why you didn't push that change yet last time you wrote about it 2021-01-05 21:31:43 Just that it's WIP 2021-01-05 21:32:14 ok 2021-01-05 21:32:34 Well, I'm working on CI for that part as well 2021-01-05 21:34:46 CI for the CI? 2021-01-05 21:35:04 For that docker image 2021-01-05 21:35:09 testing the build.sh script 2021-01-05 21:35:42 https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/jobs/286276 2021-01-05 21:36:19 https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/limit-artifact-upload/overlay/usr/local/bin/test-build.sh 2021-01-05 21:38:27 It's turtles, all the way down 2021-01-05 22:05:17 Cogitri: it worked now :) https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/jobs/286416 2021-01-05 22:29:29 Hello71: i'll merge it later today 2021-01-05 22:37:44 ok 2021-01-06 07:53:34 good morning! 2021-01-06 07:55:22 Morning 2021-01-06 07:56:49 rust fails to build from scripts/bootstrap.sh 2021-01-06 07:57:11 Assembling stage1 compiler (aarch64-alpine-linux-musl) 2021-01-06 07:57:11 Building stage1 std artifacts (aarch64-alpine-linux-musl -> x86_64-alpine-linux-musl) 2021-01-06 07:57:11 error: process didn't exit successfully: `/home/ncopa/aports/community/rust/src/rustc-1.47.0-src/build/bootstrap/debug/rustc -vV` (exit code: 101) 2021-01-06 07:58:03 Ah, did someone adjust the rust APKBUILD to actually be cross-compileable ? 2021-01-06 07:58:39 I think Ariadne tried but gave up for the time being because of some linker errors 2021-01-06 08:02:02 ikke: now that the alpine-gitlab-ci job worked does that mean that new CI jobs for aports store parts of the build output already? 2021-01-06 08:02:25 sorry, no 2021-01-06 08:02:51 not yet 2021-01-06 08:03:04 Will try to finish it tonight 2021-01-06 08:03:11 that was just a CI job for a feature branch 2021-01-06 08:03:59 Oh okay, no need to rush, thanks for working on it :) 2021-01-06 08:07:51 Ariadne: do you mind take maintainership of libtls-standalone again? #11695 2021-01-06 08:11:50 ncopa: sure 2021-01-06 09:44:12 thanks! 2021-01-06 09:56:53 hum, xorg-server moved to community. setup-xorg-base no longer works 2021-01-06 09:57:07 setup-xorg-base needs to add community repo 2021-01-06 09:57:22 or should we add community repo by default? 2021-01-06 10:02:09 Sounds good to me, most users will want it anyway 2021-01-06 10:03:14 I think it might be better to not enable community by default 2021-01-06 10:03:28 so that you by default, you have 2 years support 2021-01-06 10:03:43 if you manually modify it, you only get 6 months support 2021-01-06 10:04:15 And setup-xorg-base could ask to add the community repo 2021-01-06 10:04:42 i think it shouldnt ask. i think it should just do it 2021-01-06 10:05:09 Should it silently add the community repo with the privision that you just mentioned? 2021-01-06 10:05:13 provision 2021-01-06 10:06:12 well, if you decide to install xorg, you'll get community. it is still something you will need to actively do 2021-01-06 10:06:35 That assumes the person who runs it is aware of that fact 2021-01-06 10:06:57 Good thing to mention in the release notes, that xorg has moved 2021-01-06 10:06:57 the user will see the apk update line 2021-01-06 10:07:04 but yeah. its a good point 2021-01-06 10:07:40 my thinking is, you get 2 year support by default, unless you install xorg 2021-01-06 10:10:41 telling that on setup-xorg-base startup wouldn't hurt "This will add community repo. See: for details" 2021-01-06 10:11:29 yeah 2021-01-06 10:13:59 https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.13.0#xorg-server_has_moved_to_community 2021-01-06 10:14:26 πŸ‘ 2021-01-06 10:36:05 db is still not removed, just deprecated 2021-01-06 10:36:52 maxice8: feel free to adjust 2021-01-06 10:38:49 i think we also re-enabled busybox smtp 2021-01-06 10:39:11 im testing xfce install in a vm. seems to work pretty nice 2021-01-06 10:39:31 ncopa: so sendmail? 2021-01-06 10:39:51 3e2e759e8b3a6e05e81daabba4657d1f70813ff7 2021-01-06 10:39:58 ok 2021-01-06 10:40:25 updated 2021-01-06 10:40:28 i updated the wiki 2021-01-06 10:40:29 :) 2021-01-06 10:40:34 updated 2021-01-06 10:41:18 πŸ‘ 2021-01-06 10:41:39 fcolista: re osinfo-db, I think it would be nice if the alpine-virt variant used virtio by default 2021-01-06 10:44:53 ncopa: yesterday I upgraded xfce on my daughter x86_64, works ok except pool-tumblerd segfaults 2021-01-06 10:45:51 mps: file an issue for that 2021-01-06 10:46:32 anybody knows what i need to do to let my 'ncopa' user do shutdown from xfce with elogind? do i need to be in a group? 2021-01-06 10:48:32 no, I don't care for this bug to investigate it is not important, just wanted to inform you 2021-01-06 10:49:02 I'm in mid of backporting some packages for my servers, so too busy 2021-01-06 10:49:08 idea with filing issue is to let someone else debug and fix 2021-01-06 10:50:10 you think I will not try to fix it if I make bug report :) 2021-01-06 10:52:31 'abuild rootpkg' doesn't work if there are user and/or groups defined 2021-01-06 10:57:29 https://wiki.alpinelinux.org/wiki/Xfce_Setup#Allowing_shut_down_and_reboot recommends uninstall elogind? 2021-01-06 11:11:49 Probably some user not knowing about polkit-elogind 2021-01-06 11:12:18 If you have polkit installed it'll try to authenticate via ck2, so you either need polkit x ck2 or polkit-elogind x elogind 2021-01-06 11:12:53 Not sure if we can make apk install polkit-elogind when installing elogind and polkit is installed? 2021-01-06 11:13:07 Maybe we should add a blocker on ck2 for elogind too 2021-01-06 11:14:42 i updated the wiki 2021-01-06 11:14:59 also with a new screenshot of xfce 4.16 :) 2021-01-06 11:16:25 πŸ‘Œ 2021-01-06 11:17:19 im gonna test rpi now 2021-01-06 11:17:48 i wonder if it would make sense to ship alpine-rpi as raw disk image instead of tar.gz? 2021-01-06 11:18:21 i dont think it would be too difficult 2021-01-06 11:20:21 here is how I make mmc for it http://arvanta.net/alpine/flash-rpi-zero/ 2021-01-06 11:22:48 idea is to create a alpine-rpi.*.img so you can simply use dd 2021-01-06 11:23:38 it will create a smallish fat partition, which can be re-used as /boot and free space to create an ext partition of the rest 2021-01-06 11:23:39 yes, I understood you 2021-01-06 11:24:06 like Armbian 2021-01-06 11:24:36 i believe that is how most other distros out there does it 2021-01-06 11:25:18 alarmpi used to do that, but they switched to tar files 2021-01-06 11:25:34 https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-4 2021-01-06 11:25:59 alarm (Arch) use tarballs for all arms, iirc 2021-01-06 11:26:03 yes 2021-01-06 11:26:11 they used to have raw images 2021-01-06 11:26:23 to me this looks better than images 2021-01-06 11:28:44 user can choose FS type, size and other things when making/flashing mmc 2021-01-06 11:35:15 ok. I'm not gonna spend time on it then 2021-01-06 11:35:24 tarballs are convenient 2021-01-06 11:35:57 except when you don't have access to a full system to install it 2021-01-06 11:36:31 dd is easier than prepare + untar 2021-01-06 11:36:41 imo, tarballs are more flexible. only what we are missing is some guides 2021-01-06 11:37:06 skarnet: thats why i brought it up, dd is easier for user, tarballs are easier for us 2021-01-06 11:37:18 that is what I started to write on above link/s 2021-01-06 11:37:34 #whynotboth 2021-01-06 11:37:43 skarnet: my thoughts 2021-01-06 11:37:53 human resources 2021-01-06 11:38:03 I don't think these images are that big? 2021-01-06 11:38:34 89MB 2021-01-06 11:38:44 i'd prefer not do both 2021-01-06 11:38:51 ok 2021-01-06 11:38:54 images could be made small, and users will ask 'why you made so small FS' 2021-01-06 11:39:28 mps: that only matters for a disk setup, right? 2021-01-06 11:40:10 not only this, you know that users want 'different' setups 2021-01-06 11:41:59 creating fat FS on an mmc should and extracct a tarbbal should be possible from both windows and macos, right? 2021-01-06 11:42:03 and linux 2021-01-06 11:43:43 I think so 2021-01-06 11:44:17 do not have much experience with macos nor windows 2021-01-06 11:44:22 why not both: if we do both we (I) would need time to work on the release scripts, would need time to maintain both in the future, and would need to test both for every future release, and we'd need document how to use both and maintain boh documentation 2021-01-06 11:44:28 so i'd prefer only do one 2021-01-06 11:45:24 also I 2021-01-06 11:46:19 and I prefer tarballs, alpine is still used mostly by people who can do little more complicated things than 'dd' 2021-01-06 11:49:44 ncopa: I think most distros use a img.xz 2021-01-06 11:49:59 anecdotal data point: the lack of image and the lack of easily accessible documentation is why I installed raspbian on my pi instead of alpine 2021-01-06 11:50:24 I had never installed a rpi before and Alpine gave exactly *zero* hint on how to do this 2021-01-06 11:50:37 and I didn't want to invest any time in this 2021-01-06 11:50:42 debian was the easy way 2021-01-06 11:51:11 things would have been very different with an image, *or* with the documentation that you like to say saving time on images would allow you to write 2021-01-06 11:51:35 lol for me its the inverse 2021-01-06 11:51:49 really like the alpine way 2021-01-06 11:52:01 the lack of documentation incited you to install Alpine? now that's something else 2021-01-06 11:52:15 no thats is not an image 2021-01-06 11:52:40 just a tar.gz to unpack on the first partion of the microSD 2021-01-06 11:52:48 I can partition how I like before 2021-01-06 11:52:58 yes 2021-01-06 11:53:13 I the distro makes does not choose for me\ 2021-01-06 11:53:22 if only there were one single line of text with the .tar.gz that says exactly what you said 2021-01-06 11:53:23 s/makes/makers/ 2021-01-06 11:53:23 HRio meant to say: I the distro makers does not choose for me\ 2021-01-06 11:53:34 "unpack that .tar.gz on the first partition of the microSD" 2021-01-06 11:53:39 that would help 2021-01-06 11:54:00 this certainly seems obvious to you 2021-01-06 11:54:09 I can assure you that it is NOT obvious to a lot of people 2021-01-06 11:55:50 If we would have better docs on this, would you prefer tar.gz or a full image that includes a fixed partition table? 2021-01-06 11:56:02 I probably wouldn't care 2021-01-06 11:56:09 skarnet: would something like this help you http://arvanta.net/alpine/flash-rpi-zero/ 2021-01-06 11:56:39 mps: sorry, but no 2021-01-06 11:57:04 I don't trust scripts from the Internet that come with no context 2021-01-06 11:57:29 I didn't meant to run script blindly 2021-01-06 11:57:50 more as a hints 2021-01-06 11:58:08 if the point of Alpine is to allow users to work in an enlightened way by understanding what they are doing, then it should make it easy for users to get enlightened 2021-01-06 11:58:24 throwing scripts at them with "use the source Luke" is not it 2021-01-06 11:58:35 proper documentation and tutorials would be better 2021-01-06 11:59:01 yes, it's harder 2021-01-06 11:59:09 and I'm one to talk because I'm terrible at writing tutorials 2021-01-06 11:59:11 again, human resources 2021-01-06 11:59:31 you mean the human resources that we love to spend arguing on irc instead of doing productive things? 2021-01-06 11:59:36 One of the hardest things about documentation is makin sure they are kept up-to-date 2021-01-06 12:00:10 true 2021-01-06 12:00:13 yes, we need some kind of relaxation, and irc is good one :) 2021-01-06 12:00:32 I'm right now doing productive things, while on IRC :) 2021-01-06 12:02:30 IRC is productive and funny at same time, though depends on ones POV 2021-01-06 12:05:04 the arch linux arm install instructions may be a good inspiration https://archlinuxarm.org/platforms/armv7/ti/beagleboard 2021-01-06 12:05:37 yes, already linked to the rpi4 one 2021-01-06 12:05:41 afontain_: they are for me already 2021-01-06 12:06:40 I'm preparing guide for chromebook and think I will take some 'things' from alarm 2021-01-06 12:07:29 btw, alarm guides helped me to install alpine on 3 chromebooks three years ago 2021-01-06 12:07:47 three different* 2021-01-06 12:08:05 hmm, 3 different* 2021-01-06 12:11:17 ikke: is your last message about arch arm? 2021-01-06 12:11:33 if then, sry, I must have missed it in the backlog 2021-01-06 12:11:33 yes 2021-01-06 12:15:30 just wonder how long https://wiki.alpinelinux.org/wiki/Raspberry_Pi has been there... 2021-01-06 12:16:07 " 20:13, 28 September 2015β€Ž Summer (talk | contribs | block)β€Ž . . (97 bytes) (+97)β€Ž . . (Created a tutorial for Raspberry Pi)" 2021-01-06 12:16:48 ah there was the page info 2021-01-06 12:28:38 ugh 2021-01-06 12:29:16 n/m 2021-01-06 12:30:41 seems like qt5 5.15 will not receive new commits 2021-01-06 12:31:01 only for paying customers 2021-01-06 12:32:09 Yup, they did the last free commit yesterday 2021-01-06 12:32:41 and that's the version that will be in alpine 3.13 2021-01-06 12:32:52 https://lists.qt-project.org/pipermail/development/2021-January/040798.html 2021-01-06 12:33:39 Yeah, the current situation is less than optimal with Qt 5 being paying customers only and no application being on Qt 6 yet because not all modules are ported over yet 2021-01-06 12:35:46 ncopa: busybox 1.32.1 is released https://git.busybox.net/busybox/log/?h=1_32_stable 2021-01-06 12:35:54 some fixes 2021-01-06 12:36:38 but your 0001-Revert-ash-jobs-Only-clear-gotsigchld-when-waiting-f.patch doesn't apply, need some changes 2021-01-06 12:37:10 do you think we should have 1.32.1 in 3.13 2021-01-06 12:38:24 It is a bugfix release, so it would make sense 2021-01-06 12:47:04 ncopa, re alpine-virt use virio by default. So far, according with your patch, everything is inherited by (.*) 2021-01-06 12:48:56 I will check how to provide virio for virtual specific flavor. Which device should I use with virtio? network, disk..what else? 2021-01-06 12:52:15 fcolista: virtio-rng? 2021-01-06 12:55:18 is it needed by default? 2021-01-06 12:55:58 needs to find where to put these info in an xml like this: https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/alpinelinux.org/alpinelinux-3.13.xml.in 2021-01-06 12:58:11 rngd is not started by default so i think it will not be used even if it is needed 2021-01-06 13:00:10 Hello71, yes I agree 2021-01-06 13:03:13 does the kernel not consume virtio-rng on its own? 2021-01-06 13:06:19 it is same as other external hwrngs 2021-01-06 13:06:23 only rdrand is special 2021-01-06 13:08:20 blk and net are most important for speed, but also balloon, crypt, rng, input, serial, fs, scsi are interesting 2021-01-06 13:12:40 is it not automatic if linux detects the virtio-rng and it can be seen in /sys/devices/virtual/misc/hw_random/rng_available ? 2021-01-06 13:13:32 (not sure as I am not using kvm) 2021-01-06 13:13:40 well it says "available" so right off the bat I would assume no 2021-01-06 13:14:26 avail list all avail, /sys/devices/virtual/misc/hw_random/rng_current lists the selecte 2021-01-06 13:14:31 selected 2021-01-06 13:15:42 if rng_current shows virtio I think the kernel uses it 2021-01-06 13:15:56 it uses it... for /dev/hwrng 2021-01-06 13:16:34 which is not connected to anything in kernel 2021-01-06 13:17:11 ah OK 2021-01-06 13:32:52 Marian: thanks for your Pipewire work! I just switched my laptop to it in combination with pipewire-pulse and it works well and without any issues! 2021-01-06 13:33:19 I was wondering however, do you know if it's possible to use Pipewire to connect to a PulseAudio server on the network, or some Pipewire exclusive equivalent of it? 2021-01-06 13:37:45 is someone of busybox devs here? 'tar tvf /var/cache/distfiles/busybox-1.33.0.tar.bz2' => 'dr-xr-xr-x root/root 0 2020-12-29 16:46 busybox-1.33.0/examples/shutdown-1.0/script/' 2021-01-06 13:37:58 dir is not writeable 2021-01-06 13:41:28 PureTryOut: That is a good question. I sadly have no idea :-( 2021-01-06 13:42:42 Also, I'm trying out video sharing now with Firefox 84 on a KDE Plasma Wayland session and am so far having no luck 😒 2021-01-06 13:43:45 mps: seems fine here 2021-01-06 13:44:27 xdg-desktop-portal seems to be running however 2021-01-06 13:45:14 checked with busybox tar, gnu tar, bsdtar 2021-01-06 13:47:37 hmm, not in my lxc 2021-01-06 13:49:00 Hello71: hah, redownloaded it and it is ok. 2021-01-06 13:49:16 looks like they are fixed it in meantime 2021-01-06 13:49:39 thanks for idea to redownload 2021-01-06 13:55:32 mps: seems there where some busybox devs here listening in :-) 2021-01-06 13:57:04 https://busybox.net/downloads/ [ ] busybox-1.33.0.tar.bz2 2021-01-01 10:27 2.3M 2021-01-06 13:57:28 seems unlikely unless they manually adjusted the mtime 2021-01-06 13:57:44 yes 2021-01-06 13:58:02 seems more likely your ram is bad, since w is just one bit flip away 2021-01-06 14:06:18 Hello71: you are kidding, aren't you :) 2021-01-06 14:07:36 I did that on alpine developers box, and with APKBUILD, after redownload I see checksum is changed 2021-01-06 14:08:16 HRio: nick? 2021-01-06 14:23:26 Looks mips builders are hangs 2021-01-06 14:51:46 build seems even awol 2021-01-06 14:51:52 builder 2021-01-06 14:52:50 Ariadne: ^ 2021-01-06 15:19:27 ncopa: nodejs currently has a checksum mismatch on both armv7 and armhf, that's suspicious 2021-01-06 15:20:01 "Partial download found, trying to resume" 2021-01-06 15:20:11 Looks like they are clobbering eachother 2021-01-06 15:20:58 that's for armv7, armhf just shows a checksum mismatch 2021-01-06 15:21:25 so looks like armhf started, and armv7 tried to write to the same file as armhf? 2021-01-06 15:35:03 fcolista: re osinfo-db and virtio, see who voidl inux does. i think they have lines to enable virtio devices 2021-01-06 15:35:16 add those to our alpine-virt flavor 2021-01-06 15:35:29 ncopa, thats' a good suggestion. Thanks 2021-01-06 15:37:47 ncopa: are the any plans to compile alpine packages with clang's CFI, and if so, any way to help? 2021-01-06 15:52:53 like build all the package with clang? 2021-01-06 15:53:35 i dont think we have any specific plan for that currently. not sure what the current state for clang is 2021-01-06 15:53:57 does it generate good code for all our architectures? including s390x, ppc64le and mips64? 2021-01-06 15:54:06 can we build the linux kernel with clang? 2021-01-06 15:54:12 and future riscv 2021-01-06 15:54:24 the linux kernel is almost buildable iirc 2021-01-06 15:54:40 but yeah, it answers my question pretyt much, thanks :) 2021-01-06 15:55:05 how hard is it to bootstrap it from scratch? (eg fix our scripts/bootstrap.sh to use clang instead of gcc) 2021-01-06 15:55:37 personally i think it would be nice to swap to clang as system compiler, but im not sure its worth it (yet) 2021-01-06 15:58:53 mh, apparently, gcc supports cfi as well 2021-01-06 15:59:43 via `-fcf-protection` 2021-01-06 16:00:52 https://clangbuiltlinux.github.io/ 2021-01-06 16:12:16 do we want stable or experimental? 2021-01-06 16:14:33 experiment for future is not bad thing, if someone has time for it =) 2021-01-06 16:38:31 jvoisin: well no clang sanitizers support musl now 2021-01-06 16:38:42 meowray is working on it, possibly for next llvm 2021-01-06 16:42:57 I think the general agreement is gcc generates superior code to clang at -O2, but gcc is overenthusiastic on -Os, so maybe clang -Os can do better (as opposed to -Oz) 2021-01-06 16:43:36 iirc for clang -Os = -O2 2021-01-06 16:43:51 in either case, clang as system compiler will not happen for 3.13 2021-01-06 16:45:41 no, it was -O1 = -O2, but I think that is no longer the case 2021-01-06 17:24:37 ok 2021-01-06 17:25:29 I doubt that clang could be used even for 3.15 2021-01-06 17:27:22 ncopa: busybox 1.32.1 is out, your patch 0001-Revert-ash-jobs-Only-clear-gotsigchld-when-waiting-f.patch fails on two 'hunks' 2021-01-06 17:28:11 serpentos tried to have clang as system compiler, but there were some incompatibilities, so they switched to clang+gcc 2021-01-06 17:28:12 ok. it may need some attention then 2021-01-06 17:28:30 freebsd i think builds all packages with clang though 2021-01-06 17:28:38 so you know where to steal patches ;) 2021-01-06 17:29:52 ncopa: that is rejects https://tpaste.us/LwnK 2021-01-06 17:30:48 I looked at this but don't understand what and why you made this change 2021-01-06 17:31:20 ofc, I don't say that they are bad, just I don't understand them 2021-01-06 17:31:26 yes, basically take all of the dumb -fno-common and musl 1.2 bugs and add them together 2021-01-06 17:33:41 mps: 7e8d5484c6301602a2bdde9433b569d2bafa2226 2021-01-06 17:33:59 thats what git log told me about the patch. i dont remember a thing :) 2021-01-06 17:34:48 :) 2021-01-06 17:35:24 mps: i think we can test build busybox-1.32.1 without that patch, upgrade and then test if stunnel testsuite stil hangs 2021-01-06 17:35:46 https://bugs.busybox.net/show_bug.cgi?id=13116 2021-01-06 17:36:05 or look at the busybox log to find out what they changed 2021-01-06 17:36:15 I did already, but didn't know for stunnel bug 2021-01-06 17:37:00 they didn't changed much, some bugfixes only 2021-01-06 17:37:17 https://git.busybox.net/busybox/log/?h=1_32_stable 2021-01-06 17:37:21 i think they fixed the stunnel hang 2021-01-06 17:40:15 how to test? 'abuild -r' without without mentioned patch? 2021-01-06 17:40:31 maybe you remember 2021-01-06 17:40:35 abuild 1.32.1 without the patch 2021-01-06 17:40:47 it passed in lxc 2021-01-06 17:40:47 the update and build stunnel 2021-01-06 17:40:50 actually 2021-01-06 17:41:00 aha, ok 2021-01-06 17:41:17 should probably first remove the patch with 1.32.0 and update 2021-01-06 17:41:20 and test build tunnel 2021-01-06 17:41:24 stunnel 2021-01-06 17:41:30 to verify that it still happens 2021-01-06 17:41:35 lets try 2021-01-06 17:41:38 then update to 1.32.1 and verify that it fixes it 2021-01-06 17:43:30 already upgraded bb to 1.32.1 on my dev lxc 2021-01-06 17:43:42 without the patch? 2021-01-06 17:43:51 and stunnel builds? 2021-01-06 17:43:53 yes. without it 2021-01-06 17:44:03 yes stunnel passed abuild -r 2021-01-06 17:45:09 but before MR will do that once more 2021-01-06 17:45:28 or, you will? 2021-01-06 17:47:31 tested here. owrks 2021-01-06 17:47:33 works 2021-01-06 17:47:36 will you push it? 2021-01-06 17:48:36 let me finish linux-elm first 2021-01-06 17:48:48 I'm in mid of it 2021-01-06 17:49:12 ok. i have it ready to push here otherwise, in 5ish mins 2021-01-06 17:49:30 go ahead 2021-01-06 17:50:48 I'm not in race for commit numbers ;) 2021-01-06 17:54:55 pushed 2021-01-06 17:55:24 good, I see it 2021-01-06 17:56:03 so I can later work on 1.33.0 2021-01-06 17:57:15 I'd like to fix linux-rpi kernel so it can be installed on a mounted /boot I dont think it works currently 2021-01-06 17:57:41 umm? 2021-01-06 17:57:49 afaik no 2021-01-06 17:58:06 I have upgraded latest kernels on traditional sys installation 2021-01-06 17:58:39 yes, on sys they work 2021-01-06 17:59:27 iirc problem is modloop 2021-01-06 17:59:40 update-kernel works on non-sys, if workdir for modloop creating etc is something else than that low-memory thing 2021-01-06 18:00:07 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11052 2021-01-06 18:00:33 https://termbin.com/i3cu 2021-01-06 18:00:47 aah that one too 2021-01-06 18:01:24 didn't rememeber that I've done that copying manually 2021-01-06 18:01:31 interesting, should find time to test 2021-01-06 18:03:10 was https://termbin.com/i3cu added to alpine-conf git repo? 2021-01-06 18:03:37 i just tagged alpine-conf-3.10.0 release with a bunch of MRs merged 2021-01-06 18:03:58 afaik no, I did that when upgraded my run-from-memory rpi3 some days ago 2021-01-06 18:04:34 i need to go out, but i think we should add that update-kernel fix 2021-01-06 18:04:52 i think i saw an issue with problem of /tmp running out of space 2021-01-06 18:05:12 artok: can you create an MR and I'll have a look at it tomorrow 2021-01-06 18:05:12 it's on gitlab.a.o on my fork, so MR is not far awa 2021-01-06 18:05:23 sur 2021-01-06 18:17:38 ncopa: can there be some kind of race condition in abuild-fetch? 2021-01-06 18:31:16 just testing a controversial opinion: any thoughts on moving chromium and kodi from testing/ to community/ in order to release 3.13 without python2? 2021-01-06 18:31:47 python2 has been eol for over a year now i think and we are not really good at updating chromium in the stable branches anyhow, kodi can be moved back after they added python3 support 2021-01-06 18:32:10 you mean from community to testing? 2021-01-06 18:32:22 otherwise it would not make sense to me :P 2021-01-06 18:32:44 ooppps 2021-01-06 18:32:44 yes 2021-01-06 18:34:37 Means people who use chromium / kodi on a stable release are out of luck 2021-01-06 18:37:14 I think people who are using chromium on alpine are out of luck anyhow as we really struggle with keeping it up to date 2021-01-06 18:37:23 current version is 87.X we still package 86.X 2021-01-06 18:39:40 Yup, the Chromium situation is suboptimal either way 2021-01-06 18:43:21 nmeum: +1 2021-01-06 18:44:25 I will just open an MR, let's see if someone complain about it :D 2021-01-06 18:58:35 hmm, just in time zfs with a lot of fixes https://github.com/openzfs/zfs/releases/tag/zfs-2.0.1 2021-01-06 18:59:14 hmm, someone reported regressions with zfs 2021-01-06 18:59:35 but I don't have experience with zfs, so someone else should look at it 2021-01-06 18:59:47 112278 2021-01-06 18:59:50 !12278 2021-01-06 18:59:56 ugh 2021-01-06 19:00:03 #12278 2021-01-06 19:00:41 the problem with moving python2 to testing really is qt5-qtwebengine, it still requires it as a compile-time dependency and we can't really move it as many packages in community depend on it. I guess we really have to wait until chromium upstream (where qt5-webengine copies the blink webengine from) supports python3 2021-01-06 19:01:42 fun 2021-01-06 19:04:06 i wonder why I don't see much problems with one of most hated language called perl :) 2021-01-06 19:04:30 I need python2 at least in community for 3.13 2021-01-06 19:04:41 mps: nobody is using it :P 2021-01-06 19:05:03 mps: the meme outgrew the language, but it's quite fine, is quite stable and is installed everywhere 2021-01-06 19:05:16 ikke: why we have then so much pkgs in aports, I wonder :P 2021-01-06 19:05:32 mps: because some people still believe ;-) 2021-01-06 19:07:09 aports/main > ap revdep perl | grep -v '^perl' 2021-01-06 19:07:30 103 2021-01-06 19:07:39 mps: you didn't even use perl for that? :P 2021-01-06 19:07:43 sorry 2021-01-06 19:08:04 hehe 2021-01-06 19:08:32 community => 131 2021-01-06 19:09:07 hmm, testing is bad, just 61 2021-01-06 19:10:07 54, 157, 172 for python3 respectively 2021-01-06 19:10:07 but yes, perl uses braces and ';' which is hard to comprehend :) 2021-01-06 19:11:07 so perl is doubled py in main 2021-01-06 19:11:58 perl had/has problems similar to python when it comes to incompatibilities between major releases, at least I do still recall these perl5/perl6 shenanigans 2021-01-06 19:12:26 isn't that why they renamed perl6? 2021-01-06 19:12:32 yeah, i think they did 2021-01-06 19:12:38 perl5 and perl6 are different languages 2021-01-06 19:12:39 rakudo 2021-01-06 19:12:40 wikipedia says it's called raku now 2021-01-06 19:14:28 and obligatory https://xkcd.com/224/ :) 2021-01-06 19:14:28 https://xkcd.com/224 | Lisp | Alt-text: We lost the documentation on quantum mechanics. You'll have to decode the regexes yourself. 2021-01-06 19:15:09 ) 2021-01-06 19:15:54 nmeum: are you from russia? 2021-01-06 19:16:31 why? 2021-01-06 19:17:01 we use ) instead of :) 2021-01-06 19:17:08 https://xkcd.com/859/ 2021-01-06 19:17:09 https://xkcd.com/859 | ( | Alt-text: Brains aside, I wonder how many poorly-written xkcd.com-parsing scripts will break on this title (or ;;"''{<<[' this mouseover text." 2021-01-06 19:17:28 insep_: no, i am not :p 2021-01-06 19:45:30 Cogitri: firefox-esr fails 2021-01-06 20:06:03 `g++: fatal error: Killed signal terminated program cc1plus` 2021-01-06 20:06:10 I guess it even OOMs on the builders now? :D 2021-01-06 20:06:26 Time to give it another go, seems like it worked on 3.12 so maybe just bad timing with FF and FF-esr being built on 3.12 3.12 and edge 2021-01-06 20:06:29 algitbot: retry master 2021-01-06 20:06:52 Probably because you pushed both master and 3.12 2021-01-06 20:06:55 at the same time 2021-01-06 20:06:57 Yup 2021-01-06 20:07:11 Let's restart 3.12 once master went through 2021-01-06 20:07:48 I saw some other messages as well, but that was probably noise 2021-01-06 20:08:27 {standard input}:481586: Error: expected symbol name 2021-01-06 20:08:50 {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive 2021-01-06 20:09:54 build systems should be prohibited to output error unless something is an actual error 🀐 2021-01-06 20:10:46 I consider warning as error 2021-01-06 20:11:01 then most programs are broken 2021-01-06 20:11:15 yes, they are 2021-01-06 20:11:46 ACTION adds -Wpedantic -Werror to standard alpine flags 2021-01-06 20:12:17 without that there are so much of them 2021-01-06 20:15:52 ACTION adds -Wall and -Wextra as well 2021-01-06 20:16:28 Good luck, the next 10 years before we do another release :P 2021-01-06 20:17:37 good, we have time to make clang as system compiler! 2021-01-06 20:18:36 :) 2021-01-06 20:21:57 and phase out python2, as well as python3, replaced every library with a rust variant, redefine the concept of a distro. 2021-01-06 20:24:56 filesystem so that it won't allow creating folder named node_modules 2021-01-06 20:25:13 ha! 2021-01-06 20:25:25 Just map node_modules to /dev/null 2021-01-06 20:25:36 Should be just about enough storage 2021-01-06 20:26:12 ikke: that one is probably also OOM 2021-01-06 20:59:05 Cogitri: now it fails on aarch64 during config. It tries to find nss, and the match function returns some exception 2021-01-06 21:13:39 Yikes 2021-01-06 21:15:58 Pushed fix, needed newer version of nss on 3.12 2021-01-06 21:20:40 huh, wanted to ask on #alpine-linux but there is a rush. which pkg provides default symlinks in /etc/runlevels 2021-01-06 21:21:11 not sure they are provided by a package 2021-01-06 21:22:25 so, how to set them with apk add --arch arch --root /mnt 2021-01-06 21:24:06 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-alpine.in#L153 2021-01-06 21:25:00 nice, looked already earlier 2021-01-06 21:25:28 but have no idea how to do that with 'apk add --arch arch --root /mnt' 2021-01-06 21:28:25 you need to add install openrc 2021-01-06 21:28:39 and then add the desired services to the correct runlevels 2021-01-06 21:28:41 I did 2021-01-06 21:28:46 (so basically chroot into it) 2021-01-06 21:29:16 ok, I have script to run from chroot for this, but had a hope I can do that without chroot 2021-01-06 21:29:34 You can just create the symlinks manually without a chroot 2021-01-06 21:29:52 maybe I will add to install symlinks to install script 2021-01-06 21:30:12 ikke: yes, understand that, (as a last resort though) 2021-01-06 21:30:17 ls -s /etc/init.d/networking /mnt/etc/runlevels/boot/ 2021-01-06 21:30:53 ln -s* 2021-01-06 21:31:13 sure 2021-01-06 21:31:27 oh, networking is in default, not boot 2021-01-06 21:33:09 this is not the main part though 2021-01-06 21:33:14 core services are enabled in mkinitfs 2021-01-06 21:33:50 Hello71: right, suspected as much 2021-01-06 21:34:12 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L623 2021-01-06 21:34:21 hmm, mkinitfs run and created initramfs but not symlinks 2021-01-06 21:34:23 heh 2021-01-06 21:34:36 initramfs-init 2021-01-06 21:35:00 but that's only relevant if you boot a kernel 2021-01-06 21:35:19 not for lxc containers for example 2021-01-06 21:35:22 so, add initramfs-init? 2021-01-06 21:35:43 mps: is this something you want to boot? 2021-01-06 21:35:52 yes 2021-01-06 21:36:15 working on script to install alpine for arm on mmc 2021-01-06 21:36:25 You need to make sure /etc/.default_boot_services exists 2021-01-06 21:37:30 then, at boot time, it will enable those services the first time, and then remove that file 2021-01-06 21:38:18 note that this does not include networking, which you would still need to enable (or let setup-alpine handle that) 2021-01-06 21:40:37 initramfs-init (no such package): 2021-01-06 21:40:57 it's not a package you install 2021-01-06 21:41:01 it's part of mkinitfs 2021-01-06 21:41:45 aha, touch /etc/.default_boot_services ? 2021-01-06 21:41:58 yes 2021-01-06 21:42:10 thanks 2021-01-06 21:45:25 hmm, our /etc/securetty missing ttyS0 2021-01-06 21:47:13 Hmm, but I've never had issues with logging in as root via serial 2021-01-06 21:48:02 aha: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L122 2021-01-06 21:48:27 initramfs-init automatically adds the blockdevice specifyed via console to /etc/securetty 2021-01-06 21:49:17 huh, have bad crc on gpt table, probably mmc card issue 2021-01-06 22:14:18 hmm, /etc/.default_boot_services doesn't work 2021-01-06 22:15:17 but it boots 2021-01-06 22:19:17 I would expect it to work 2021-01-06 22:21:23 will left for some other day 2021-01-06 22:22:00 heh, initramfs-init also just creates symlinks 2021-01-06 22:22:24 not armv7 3.12 2021-01-06 22:22:48 I mean, the way it would add services 2021-01-06 22:22:56 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L94 2021-01-06 22:23:31 that is last part what missing on my test 2021-01-06 22:23:43 but some other day 2021-01-06 22:26:05 but I nearly finished script to install armv7 on mmc in sys mode 2021-01-06 22:26:33 and script could be extended to some kind of guide for alpine users 2021-01-06 22:26:36 What prevents alpine from providing a sys install by default? 2021-01-06 22:27:08 well, complicated for SBCs with usually just one mmc slot 2021-01-06 22:29:04 right, you cannot really install it to some available persistent storage 2021-01-06 22:29:38 most other distros you would just boot an already installed system 2021-01-06 22:30:04 if there is usb port then could be installed on it and then copied to mmc and set boot loader 2021-01-06 22:30:32 but a lot of work, especially for unexperienced 2021-01-06 22:31:05 here is my WIP shell script https://tpaste.us/ZEZl 2021-01-06 22:32:29 I do wonder if run=from=rame is the best default for these sbcs wwhich usually already have limited ram 2021-01-06 22:33:12 how to update kernel on SBC hundreds or thousands km away 2021-01-06 22:34:51 with a sys install, it should be trivial 2021-01-06 22:34:59 send satellite into space 2021-01-06 22:35:32 better NLO 2021-01-07 03:01:22 Could a kind soul with dev.alpinelinux.org/archive access create a new snapshot of https://gn.googlesource.com/gn/ head ? It has to contain the .git directory so normal snapshot() does not work. 2021-01-07 03:05:23 TBK[m]: how to do that? 2021-01-07 03:08:07 'git clone https://gn.googlesource.com/gn' and create tarball of dir? 2021-01-07 08:26:08 morning 2021-01-07 08:27:18 good morning 2021-01-07 08:27:42 Morning 2021-01-07 09:01:21 howdy 2021-01-07 10:17:49 mps: yes, clone and tarball it all :) 2021-01-07 10:32:47 TBK[m]: git log shows last commit date 'Tue Dec 22 01:37:16 2020 +0000'. what should be tarball file name 2021-01-07 10:34:11 gn-0_git20201222.tar.gz ? 2021-01-07 10:34:44 mps: gn-0_git20201222.tar.gz would be perfect :) 2021-01-07 10:34:55 ok 2021-01-07 10:40:01 hmm, looks like I don't have rights to put files in /archive/gn/ 2021-01-07 10:40:43 Cogitri: is owner 2021-01-07 10:41:58 gn dir needs group write flag 2021-01-07 10:52:41 mps: will fix it 2021-01-07 10:52:59 it should have a sticky bit set so that the group remains 2021-01-07 10:53:44 it have it 2021-01-07 10:55:59 added write permissions to the group now 2021-01-07 11:02:45 ikke: thanks 2021-01-07 11:03:12 TBK[m]: there is it. if it is not ok tell us 2021-01-07 11:03:28 mps: thanks 2021-01-07 11:23:46 TBK[m]: np 2021-01-07 11:36:22 good day 2021-01-07 11:44:14 hi 2021-01-07 11:44:23 o/ 2021-01-07 11:45:09 ncopa: if you have some time could you take a look at !16536 ? 2021-01-07 11:46:58 um sure 2021-01-07 11:48:05 its just that I may want to update while update kernel 2021-01-07 11:48:33 its easier for me to just do it myself than try coordinate that MR together with my own fixes for linux-rpi 2021-01-07 11:48:58 i'd like to push linux-lts separately and linux-rpi separately 2021-01-07 13:58:26 Hi. Is anyone using pulseaudio with modern bluetooth audio devices, who cares about sound quality and doesn't want to switch to pipewire? If so, I would be happy to hand over maintainership for `testing/pulseaudio-modules-bt` - an downstream bluetooth module with modern bluetooth audio codec support. See https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16555 2021-01-07 14:34:50 someone posted this to me yesterday i dont remember who... https://termbin.com/i3cu 2021-01-07 14:39:12 ncopa: think that was either artok or mps 2021-01-07 14:39:33 was part of the RPI discussion 2021-01-07 14:39:47 artok 2021-01-07 14:42:45 sigh.. i think im losing it... 2021-01-07 14:42:56 :( 2021-01-07 14:43:23 ncopa: re you mention of the linux-rpi DTBS issue yesterday, I was working on moving the DTBS files to a separate sub-package of linux-rpi so that it could be depended on by linux-rpi/linux-rpi2/linux-rpi4 before Xmas but got waylayed into other unrelated stuff at Xmas so need to get back to it again now. I assume you were intending to address this issue after 3.13 rather than as part of it, correct? 2021-01-07 14:44:35 spent much of today to test the linux-rpi on /boot (eg move /boot/dtbs-$flavor/* to boot/) so i know what is needed. then I went ahead and updated the linux-rpi kernel without doing anything at all with it 2021-01-07 14:44:54 i was about to push when i realized that i hadnt done what i was upposed to do 2021-01-07 14:45:22 Well, it's hard to keep track of all details 2021-01-07 14:46:08 i need to be much better at ignore issues that i cannot handle atm. like the zfs on root thing that i found this morning when looking over MRs for alpine-conf 2021-01-07 14:47:53 ncopa: was your linux-rpi change to avoid duplicate packaging of the DTBS files? A checksum shows those files are the same regardless of armv7/aarch64 and rpi/rpi2/rpi4 2021-01-07 14:49:56 no, its so you can mount /boot as boot partition and then do apk add linux-rpi and the dtbs files are where they are supposed 2021-01-07 14:50:11 there is an MR for it 2021-01-07 14:50:11 hullo! 2021-01-07 14:50:38 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11052 2021-01-07 14:56:35 ncopa: yupe I'm aware of the MR, I commented on it several times a while ago. The underlying issue is that the files were never put in /boot as files of the same name as contained in multiple packages (linux-rpi/rpi2/rpi4) - but there's no reason for those files to be packaged separately as they're the same contents, so if the dup packaging is removed then there's no reason why they can't be installed directly in /boot anymore 2021-01-07 15:32:44 ncopa: !11 , was there some scripts calling update-kernel ? as Hello71 suggest that it would be mandantory setting 2021-01-07 15:32:59 duh.. not that aports 11, alpine-conf 11 =D 2021-01-07 15:33:09 algitbot only supports aports 2021-01-07 15:33:36 narrow minded bot =) 2021-01-07 15:34:01 patches welcome: https://gitlab.alpinelinux.org/alpine/infra/compose/algitbot/-/blob/master/sircbot/scripts/sircbot.lua :P 2021-01-07 15:38:00 oh.. lua 2021-01-07 15:58:02 Hello71: do you think you can make a patch for https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/11? 2021-01-07 16:00:11 yeah, I did that purely so that without setting, it would act as before 2021-01-07 16:21:32 ncopa: preferences on mktemp -t vs ${TMPDIR:-/tmp}? only difference is that coreutils says that mktemp -t is deprecated 2021-01-07 16:31:07 is the -t option deprecated, or the fallback to /tmp? 2021-01-07 16:36:16 the coreutils manual says "This option is deprecated; the use of -p without -t offers better defaults (by favoring the command line over TMPDIR) and more flexibility (by allowing intermediate directories)." 2021-01-07 16:37:04 not sure that first part makes sense 2021-01-07 16:43:30 I dont have any tbh 2021-01-07 16:51:10 oh, now i see what you mean: mkdir -p "${TMPDIR:-/tmp}" "$SCRIPT.XXXXXX" 2021-01-07 16:52:14 s/mkdir/mktemp/ 2021-01-07 16:52:14 ncopa meant to say: oh, now i see what you mean: mktemp -p "${TMPDIR:-/tmp}" "$SCRIPT.XXXXXX" 2021-01-07 18:05:04 ikke: last night I couldn't sleep so I finished script to install alpine by using 'apk add --root $dir --arch $arch ...'. I tested on allwinner A20 (old leemaker bananapi) and it works fine. sure will need some tweaks and maybe features but 'base' is ok 2021-01-07 18:19:29 mps: does it build up from a minirootfs? 2021-01-07 18:20:01 wsinatra: no, as wrote above 'apk add --root $dir --arch $arch ...' 2021-01-07 18:20:31 wsinatra: here it is https://tpaste.us/Yox4 2021-01-07 18:20:47 rough as you can see, but worked 2021-01-07 18:21:34 hmm very interesting though, I've done similar for my droid by I used a minirootfs, this seems to cut out some steps 2021-01-07 18:21:43 I like the initial version :) 2021-01-07 18:22:35 I will try to 'polish' it somewhat and put somewhere on inet 2021-01-07 18:23:04 as usual, any comments and helps are welcome 2021-01-07 18:24:17 and this could be user as method for other arches, I plan to test it for arm64 chromebook 2021-01-07 18:31:29 I'd definitely like to see the end results, seems like a useful method for installing to sbcs and other strange hardware 2021-01-07 18:33:22 yes, it is extensible to the need or use cases for end users 2021-01-07 18:33:32 wsinatra: I have something similar but more extensive/complex: Ansible playbook to build disk images for RPI as well as x86_64 physical and VM images 2021-01-07 18:33:52 meh, ansible ;) 2021-01-07 18:34:24 minimal: sorry, couldn't resist 2021-01-07 18:35:11 mps: I know, my Ansible playbook ssh'ed in to you to trigger that reaction ;-) 2021-01-07 18:35:55 minimal: no, it is not, I did this long time ago 2021-01-07 18:36:22 I meant your "meh, ansible" statement lol 2021-01-07 18:36:37 but found some time (insomnia) to make it as script 2021-01-07 18:37:00 I'm a bit surprised to see "Ansible" and "minimal" together 2021-01-07 18:37:12 :) 2021-01-07 18:37:58 afontain_: true. In that case its more a situation of "portable" (I'm also building Debian images from the same playbook) 2021-01-07 18:39:07 minimal: I do the same thing at work for the few rpi4 & compute stick systems I have running alpine :) 2021-01-07 18:39:17 Ad hoc provisioning stuff is neat 2021-01-07 18:39:21 and I'm also generating non-Linux/Unix configs with Ansible as well for things like switch config 2021-01-07 18:40:09 wsinatra: you might like the idea of the small cloud-init partition I have on my RPI images for bootstrapping the hostname/IP config/etc upon 1st boot 2021-01-07 18:41:17 oooh I DO like that idea 2021-01-07 18:41:26 I might have to steal that ;) 2021-01-07 18:41:52 I've been looking at ansible wondering if I can configure my Mikrotik's with it too, +1 for the switch configs 2021-01-07 18:42:00 "dd" the image onto several SDcards, then on each edit network-config.yaml and user-data.yaml accordingly and stick them in several machines and turn them on 2021-01-07 18:42:59 wsinatra: re switches, using Jinja templates for Cisco-style config files (not Cisco kit tho) which for new switches are TFTP downloaded to the switch 2021-01-07 18:44:36 We're running a mix of Meraki's and Mikrotiks on my end, and I would LOVE an easy way to provision the merakis in particular. I need to spend more time investigating this 2021-01-07 18:46:35 do either of them support TFTP? are their using Cisco-like clis? can you use a command like "copy tftp startup-config"? 2021-01-07 18:47:58 a couple of the switches I have support initial autoconfig via DHCP options to find fireware and initial config. For the others just need to manually give then an IP and run the command to download initial config from TFTP. Of course the TFTP and DHCP server is an Alpine box :-) 2021-01-07 18:49:53 wsinatra: just remembering, are the Meraki's only with cloud-based provisioning? Seem to remember Cisco messed up their backend storage a year or 2 ago and "lost" many of their customer's configs. So no CLI on them at all? 2021-01-07 18:50:34 Yeah the meraki's are entirely locked down, only cloud based that I know of. I think they provide an API or some sort, but I haven't gotten a chance to play with it 2021-01-07 18:51:12 wsinatra: won't touch a cloud-only-provisioned device with a bargepole 2021-01-07 18:51:31 for the Mikrotiks they check all the boxes, robust cli, traditional configuration. So the TFTP system works perfect, I could tie that into my existing alpine based PXE infra easily, already using tftp to host legacy bios pxe 2021-01-07 18:51:45 I feel that on SO many levels. 2021-01-07 18:52:17 The mikrotik's were introduced because of me, meraki's were chosen by my boss, I just need to work around the painful web interface provisioning haha 2021-01-07 18:52:53 did a quick search on Mikrotiks and notice they talk about "binary" files written/read from TFTP 2021-01-07 18:53:29 so sounds like you couldn't template config files to then load, you'd have to instead inject the sequence of commands via SSH 2021-01-07 18:54:59 I know they expose a way to export configurations and apply them via a template, but it would likely still be via SSH. Which isn't a huge issue 2021-01-07 18:55:12 extra steps, and better than web interfaces 2021-01-07 18:55:27 looks like I misread - there's a distinction between "backup" (binary file) and "export" (text) 2021-01-07 18:57:06 I'm still working on my switch config automation but for now think its easier to completely work on templated files so changes are applied by loading the new file rather than trying to use SSH for issuing commands to apply changes (and so have to work out commands needed for delta from current config) 2021-01-07 18:58:57 haven't found a single TFTP daemon for Linux/Alpine that does what I want so currently using 2 different daemons (one for read-only, other for write-only) 2021-01-07 19:15:53 It would definitely be nice to just blow in one of the backup files and have everything restored, but I'm fairly certain for Mikrotiks you need to use one of their imaging tools for that 2021-01-07 19:16:41 the exported configuration files are really DSL command calls. Same thing as issuing things from the CLI/SSH, but less effort/moving parts to just upload it, which is good for networking gear 2021-01-07 19:24:52 that's the way most switches work - the config files saved to TFTP are just a sequence of CLI commands 2021-01-07 20:21:38 hello, I'm looking for someone to talk to about how the databases at https://secdb.alpinelinux.org/ are made 2021-01-07 20:23:21 https://gitlab.alpinelinux.org/alpine/infra/docker/secdb 2021-01-07 20:23:38 Every APKBUILD has a section for secfixes 2021-01-07 20:23:45 we have a set of scripts that extracts those 2021-01-07 20:30:28 ah, okay. I frequently run into issues parsing those files because they do odd things. I'll see if I can lua enough to improve that verify function 2021-01-07 20:33:16 I've tried to get 9pfs working with xen, but then it dawned on me that perhaps xen is built without support for it 2021-01-07 20:33:21 https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/configure;h=8a708e9baa85a5ff8336a4dacb897453cb43c358;hb=HEAD#l1508 2021-01-07 20:36:06 see here https://git.alpinelinux.org/aports/tree/main/xen/APKBUILD 2021-01-07 20:37:11 yeah, I did, just am not sure how qemu is "default" configured 2021-01-07 20:37:41 ah OK, so qemu is needed for 9pfs ? 2021-01-07 20:37:52 I don't know 2021-01-07 20:37:56 ( I am not using qemu with XEN myself ) 2021-01-07 20:38:32 I beleive I am for hvm domus, but I want to use this with pv(h) ones as well 2021-01-07 20:38:32 Alpine domUs works in pvh mode without qemu 2021-01-07 20:38:48 I do not use hvm 2021-01-07 20:39:11 I do for pci passthrough, if I'm not mistaken and it is not needed there 2021-01-07 20:39:27 not needed 2021-01-07 20:39:44 pci passthrough works in pv mode as well 2021-01-07 20:40:14 but qemu is needed if you are running an OS with a GUI 2021-01-07 20:41:17 hmm... ok... I'll need to investigate this 2021-01-07 20:41:27 like windows server, but it was many years since I used that, think I was running Alpine 3.8 in the hypervisor with that HVM guest 2021-01-07 20:41:37 either way, I'll open a ticket for --enable-9pfs 2021-01-07 20:43:20 OK, can you try to investigate if that is something that requires qemu? 2021-01-07 20:45:45 perhaps I'm just failing... 2021-01-07 20:46:02 yeah, I'll hold off with the report a bit 2021-01-07 20:46:27 "Explicitly enable 9pfs support in QEMU build" 2021-01-07 20:46:59 it's just that I've tried and thought that, aha, this might be it 2021-01-07 20:50:44 alpine xen doesn't use system qemu 2021-01-07 20:57:48 but it probably should 2021-01-07 20:58:54 nliadm: are these issues by chance already listed here? https://gitlab.alpinelinux.org/alpine/infra/docker/secdb/-/issues 2021-01-07 21:00:24 yeah, that empty values one, but also I've duplicate version entries before 2021-01-07 21:00:30 seems there are 9pfs releated .c files in qemu-xen in edge 2021-01-07 21:00:56 specifically in the yaml output. maybe some yaml libraries are nice and merge them for you 2021-01-07 21:01:31 e.g src/xen-4.14.1/tools/qemu-xen/hw/9pfs/xen-9p-backend.c 2021-01-08 08:10:18 morning 2021-01-08 08:11:27 hey 2021-01-08 08:11:40 \o :) 2021-01-08 08:11:44 morning 2021-01-08 08:12:36 Morning 2021-01-08 08:13:19 i think i may have fixed rpi support for setup-disk 2021-01-08 08:13:55 That would be nice 2021-01-08 08:13:59 on thing im considering is to unmount the boot media so you can do sys install on it 2021-01-08 08:14:10 currently setup-disk will not list mounted disks 2021-01-08 08:14:30 right, so you first use the bootmedia for the setup, and then overwrite it with the actual installation 2021-01-08 08:14:38 yup 2021-01-08 08:15:27 i think you can do so already now, but then you need to 1) manually modprobe all needed kernel modules (ext4?) 2) manually stop modloop "service" and umount the mmc 3) start setup-disk 2021-01-08 08:16:40 btw, i fixed the wifi configuration from setup-alpine earlier this week 2021-01-08 08:16:49 should be pretty ok now 2021-01-08 08:18:12 f2fs is better than ext4 for mmc, ime 2021-01-08 08:20:53 mps: why? do you have any references to article with numbers explaining why? 2021-01-08 08:21:47 I read dispersed article over inet but I don't have any 'under fingers' 2021-01-08 08:22:18 and f2fs is designed flash friendly FS 2021-01-08 08:22:54 and as I wrote above, 'IME' 2021-01-08 08:22:56 f2fs has internal wear leveling which controller-less flash doesn't have 2021-01-08 08:23:59 I use it for long time on all mmc, usb flash disks and all ssd 2021-01-08 08:24:38 Cogitri: that's ubifs 2021-01-08 08:24:56 though as everything, there is no perfect one 2021-01-08 08:25:13 at least controller-less part 2021-01-08 08:26:20 Oh, right 2021-01-08 08:26:35 f2fs just tries to optimize write cycles and whatnot to save flash 2021-01-08 08:26:38 new kernels are now do some of these 'wear' tasks 2021-01-08 08:26:51 comes with compression too 2021-01-08 08:32:16 f2fs seems to have good write performance as well 2021-01-08 08:32:53 however, we already use ext4 as default for everythign else so it does nto require any more work from my side 2021-01-08 08:33:53 good, I don't propese change, just noted 2021-01-08 08:34:25 what kernel version is on CIs 2021-01-08 09:00:23 omni: have tested the plan9 stuff with a dom0 running Alpine 3.11 and a 3.13 guest, seems to be working fine. But we need new dev depends for the xen package to be able to build the bundled qemu with 9pfs support 2021-01-08 09:03:45 if someone want to merge !16592 then should look does bluez and ofono need to be rebuilt 2021-01-08 09:32:48 omni: its quite slow even with a simple seq write test and the dom0 takes a cpu load hit during the test. 2021-01-08 09:51:48 do we want swap enabled on rpi? I'd guess that we dont? 2021-01-08 09:52:46 I don't think so either 2021-01-08 09:52:54 swap on flash doesn't sound like a good idea 2021-01-08 10:08:52 πŸ‘ 2021-01-08 10:15:43 \o/ finally setup-disk worked! 2021-01-08 10:15:54 now i'll only test lvmsys install 2021-01-08 10:15:59 \o/ 2021-01-08 10:17:24 TIL that rpi wont boot if partition type is 83 (linux). needs to be 0c / W95 FAT 32 (LBA) 2021-01-08 10:23:16 I have this in script to flash rpi 'parted -s $device unit s -- mkpart primary fat32 2048 526335' 2021-01-08 11:29:58 if doing sys install on microSD you should use at least a A1 speed class microSD https://www.sdcard.org/developers/overview/application/index.html 2021-01-08 11:30:37 testing tool https://github.com/raspberrypi-ui/agnostics/blob/master/data/sdtest.sh 2021-01-08 11:34:50 depends, few years ago I installed one alpine on sdcard class 4, still works fine for job it is made 2021-01-08 11:35:48 If you have a system that does not do a lot of disk writes, it should not matter a lot 2021-01-08 11:36:05 yes 2021-01-08 11:36:11 sure but why not run from ramfs and commit with lbu then? 2021-01-08 11:36:21 memory 2021-01-08 11:36:41 Your storage is constrained by memory 2021-01-08 11:36:48 upgrade kernel on run-from-ram 2021-01-08 11:36:53 sure but if you do not write... 2021-01-08 11:37:18 need persistent log 2021-01-08 11:38:01 HRio: it's not about data, but about installed programs 2021-01-08 11:38:13 someone on #alpine-linux could not install chromium by default due to this 2021-01-08 11:38:48 the desktop use case is one of A1 or A2 speed class 2021-01-08 11:44:01 persitent log can be solved with run from ramfs plus a log parttion or with syslog as well, but sure sys is a way as well 2021-01-08 11:45:07 (remote syslog) 2021-01-08 11:46:15 everything can be solved, except unsolvables 2021-01-08 11:47:36 running desktop on A1 is not 'pleasant' though it works, I have one 2021-01-08 11:48:25 i'll stick to actual NVMe storage 2021-01-08 11:48:38 raspi is not interesting to me except for small appliances 2021-01-08 11:49:00 like i have a console server on rpi4 2021-01-08 11:49:01 if machine have one, then I would also 2021-01-08 11:49:03 at my colo 2021-01-08 11:52:20 yes for me rpi is for small jumphosts and ntp servers. 2021-01-08 11:56:30 I'd love to be able to easily install to disk/sdcard on ARM devices including the RPi, I don't want the in-memory approach 2021-01-08 11:56:57 should be easier now with the new changes 2021-01-08 11:57:12 PureTryOut[m]2: yesterday I posted script here for this 2021-01-08 13:32:39 the guide in the wiki also works for RPI with some side effects and small issues 2021-01-08 14:38:06 HRio: how did you get it to work? I tried with 'p9 = [ "backend=dom0,path=/path/to/dir,security_model=none,tag=p9test" ]' in domu xl.cfg 2021-01-08 14:38:50 mps: I tried using f2fs for SDs and SSDs a while ago but it doesn't "like" that the rootfs is initially mounted read-only, I had to modify /etc/conf.d/fsck to add "-f -a" to the fsck_args as otherwise it didn't work right 2021-01-08 14:42:32 however this forces a fsck every boot :-( Its been raised by others in the past on the f2fs email list. 2021-01-08 14:45:01 this is a problem of copying and pasting ext* methods to other filesystems. ext* is the exception where fscking read-only is fine, because of historical reasons (predating initrd). really everyone should be using initramfs for fsck 2021-01-08 14:45:08 debian and rh already do this 2021-01-08 14:53:30 Hello71: do you think you could create an issue for that? i think openrc does the fsck as ro 2021-01-08 14:53:42 one challenge is that we may not have frambuffer console at that time 2021-01-08 14:53:55 so its not possible to see the fsck progress 2021-01-08 14:54:42 well it's fine on ext4 because it's designed for it. btrfs, xfs, zfs etc are designed to not require offline fsck. fat, ntfs etc need offline fsck but nobody would be crazy enough to use it as root (cough) 2021-01-08 14:57:52 omni: new qemu-system-i386 in /tmp and overriding with 'device_model_override = "/tmp/qemu-system-i386' in xl.cfg 2021-01-08 15:13:46 ncopa: yupe openrc does not the fsck as ro, that's the issue - f2fs's fsck expects the fs to be mounted rw when it runs, with the "-f -a" flags it forces it to do a fsck regardless rather than do one only if needed 2021-01-08 15:14:18 s/not the fsck/the fsck/g 2021-01-08 15:14:19 minimal meant to say: ncopa: yupe openrc does the fsck as ro, that's the issue - f2fs's fsck expects the fs to be mounted rw when it runs, with the "-f -a" flags it forces it to do a fsck regardless rather than do one only if needed 2021-01-08 15:24:29 wait what 2021-01-08 15:46:19 Hello71: normally during boot with a F2FS rootfs when fsck.f2fs runs the minute it sees that fs is RO it refuses to do any checks and so the rootfs is never sanity checked. The only way to get fsck.f2fs to do any sanity checking of the fs is to force it to do a fsck regardless of whether it is needed or not. 2021-01-08 15:46:36 you are supposed to *un*mount it, not mount it rw 2021-01-08 15:47:03 this is before Alpine remounts it "rw", its "ro" during that stage of the boot 2021-01-08 15:48:00 ncopa: on what platforms is this the case? and if so then how do you recover from other initramfs errors 2021-01-08 15:50:30 this is for a SYS Alpine setup where the initramfs and kernel are on the rootfs which therefore has been ro-mounted during early boot. Before the initramfs remounts root RW in order to bring up the full OS it first wants to do a fsck check on the rootfs - fsck.ext2/3/4 don't have an issue with rootfs being RO at that point, fsck.f2fs basically refuses to even determine if fs is clean or not and so Alpine will then continue on to 2021-01-08 15:50:30 remount F2FS in that case even if its potentially unclean. 2021-01-08 15:50:50 /etc/conf.d is totally unrelated to initramfs 2021-01-08 15:51:17 Its why I switched back to EXT4 from F2FS for my RPIs 2021-01-08 15:53:26 Hello71: its after initramfs has run and then full OS starts up - the fsck in full OS happens before rootfs is remounted RW 2021-01-08 15:54:49 yes, this is totally different from what you said, which is actually wrong in another way: it is the kernel's responsibility to determine if the filesystem cannot be safely mounted rw 2021-01-08 15:55:51 my downstream kernel used in pmOS requires dtc with MAX_SRCFILE_DEPTH set to 200: https://github.com/dgibson/dtc/blob/f7e5737f26aa7198db476c94463766910db48941/srcpos.c#L23 how would I go about upstreaming it to alpine package (before potentially doing so in the upstream dtc itself) 2021-01-08 15:56:16 ignapk: uh... why? 2021-01-08 15:56:51 s/said/previously said/ 2021-01-08 15:56:52 Hello71 meant to say: yes, this is totally different from what you previously said, which is actually wrong in another way: it is the kernel's responsibility to determine if the filesystem cannot be safely mounted rw 2021-01-08 15:56:52 Hello71: I'm working from my recollection from about 4-5 months ago. My memory isn't perfect :-) The basic point is that if I didn't add the force flags to /etc/conf.d/fsck then fsck.f2fs did not bother to check the root FS during boot 2021-01-08 15:56:58 it's just a sanity check to detect infinite recursion so it shouln't hurt to increase it 2021-01-08 15:57:06 ignapk: right, but... why 2021-01-08 15:57:29 i agree that this is a low risk change but what kind of ridiculous tree do you have 2021-01-08 15:57:50 https://github.com/Dil3mm4/labyrinth_kernel_prague 2021-01-08 15:58:41 does that have 100 layers deep directories? 2021-01-08 15:58:47 Hello71: "it is the kernel's responsibility to determine if the filesystem cannot be safely mounted rw" - isn't such a decision based on the exit code of the fsck? fsck.f2fs was indicating a problem when encountering a RO rootfs" 2021-01-08 15:59:05 that's not the kernel then 2021-01-08 15:59:46 you could implement such a policy but i doubt alpine/openrc does 2021-01-08 15:59:51 I never said anything about the kernel - I simply pointed out there was a fundamental issue with using F2FS as a rootfs due to how fsck.f2fs dealt with a RO-mounted rootfs 2021-01-08 16:01:36 again... you are supposed to fsck it from initramfs. ext* is a historical oddity that allows repairing ro fs 2021-01-08 16:01:56 the fsck.f2fs patches allow *checking* ro mounted filesystem 2021-01-08 16:02:03 In the past I worked around this by adding the "-f -a" flags to /etc/conf.d/fsck which did ensure that fsck.f2fs sanity checked the rootfs at boot but also had the undesirable side-effect of a full fsck occurring ever boot (which sort of negates the point of using F2FS to reduce writes on a device) 2021-01-08 16:03:00 Hello71: just checked and maximum directory depth is 12, that's weird 2021-01-08 16:03:41 Hello71: which fsck.f2fs patches? The Alpine f2fs-tools package doesn't apply any patches to upstream code 2021-01-08 16:04:19 but you're right I should first correctly diagnose why the limit is reached in the first place, I already tried counting dts files in arch/arm64 but it's still way below 100 2021-01-08 16:08:29 meh, I already lost it 2021-01-08 16:09:05 int https://sourceforge.net/p/linux-f2fs/mailman/linux-f2fs-devel/thread/e8884c8d-9009-cb70-bdf1-73fc38e83abc%40GMail.com/ it was reported that checking ro fs doesn't work 2021-01-08 16:09:42 my link was stuck again so I'm 'out of discussion', but after about 3 years (at least) using f2fs as root never had these problems so I don't know for them 2021-01-08 16:10:21 the communication from f2fs devs is not good here. to repair mounted fs, you must communicate your changes to the kernel to keep fs state consistent. e2fsck has this communication (in some circumstances), but i doubt fsck.f2fs does 2021-01-08 16:10:36 the best mode is always to run fsck with filesystem unmounted 2021-01-08 16:10:41 Hello71: I'm not necessarily disagreeing as to whether fsck should occur in initramfs, I'm merely pointing out the current situation 2021-01-08 16:10:48 (what I didn't seen by my eyes this doesn't exist, and I doubt even these I seen with my eyes) 2021-01-08 16:11:19 or be designed to not require fsck (btrfs, xfs, zfs) 2021-01-08 16:12:51 Hello71: that link exactly makes the same point as I did - with that code change you need to pass "-af" to fsck, which is what I originally said I'd had to do in /etc/conf.d/fsck. I've previously read various reports of this issue such as the link and I agree that the F2FS Devs responses didn't give me a good feeling - that's why I switched back to ext4 2021-01-08 16:13:36 the f2fs devs are saying "we have fixed it, it is now possible to fsck ro mounted fs". but they neglected to clearly communicate "you should not do this if possible" 2021-01-08 16:13:41 they thought that putting it under -f was sufficiently clear 2021-01-08 16:15:28 obviously it was not 2021-01-08 16:17:07 Hello71: again I'm not disagreeing with you - merely pointing out the current situation on Alpine. I don't remember hitting a similiar issue in the past with XFS and there isn't a "real" fsck for BTRFS, so I've not seen this RO issue with other FSs before. 2021-01-08 16:17:43 anyways, fsck is less necessary with any remotely recent filesystems (e.g. ext4), since they have in-kernel journal replay 2021-01-08 16:17:49 fsck.xfs is also a no-op 2021-01-08 16:18:20 there is xfs_check but as the man page says it is not supposed to be run regularly 2021-01-08 16:18:32 so we're coming full circle that the issue is only currently apparent with a F2FS rootfs 2021-01-08 16:19:08 yes, i said that 1.5 hours ago 2021-01-08 16:19:09 which is why I'd chipped in after the earlier discussion about using a F2FS rootfs 2021-01-08 16:19:15 ok... i think im pretty happy with setup-disk + rpi. it will ask to unmount the /media/ and retry 2021-01-08 16:19:22 14:54 well it's fine on ext4 because it's designed for it. btrfs, xfs, zfs etc are designed to not require offline fsck. fat, ntfs etc need offline fsck but nobody would be crazy enough to use it as root (cough) 2021-01-08 16:19:25 then it will copy the kernel modules to tmpfs 2021-01-08 16:19:55 it means you can install alpine to the mmc you booted from if there are no other available disks 2021-01-08 16:20:09 ncopa: cool 2021-01-08 16:20:17 sys install works and lvmsys also tested and works 2021-01-08 16:20:49 ncopa: this will be usable, really 2021-01-08 16:21:09 i think this option should still be available if other disks are installed though? rpi is most common case but i think some people may want this on other archs too 2021-01-08 16:21:32 if we consider this a minirootfs alternative 2021-01-08 16:21:52 the question will come up when there are no free disks found 2021-01-08 16:22:03 so not only for rpi 2021-01-08 16:22:22 right. but what if there is some other disk but for some reason the user still wants to "in-place" install 2021-01-08 16:22:45 then user will have to manually unmount the disk before running setup-disk 2021-01-08 16:23:21 you can answer ! on any of the questions and you'll get a shell 2021-01-08 16:23:47 hm. not sure I understand your explanation of the UX here, but probably it would be faster to push code and then review instead of back-and-forth 2021-01-08 16:24:00 i cleaned up the scripts a bit 2021-01-08 16:24:06 i have pushed the code 2021-01-08 16:24:23 and im pretty happy with the behavior 2021-01-08 16:24:48 its also "new" that you can answer ! on any question and get a shell 2021-01-08 16:25:07 and then come back to the setup script 2021-01-08 16:25:32 it was possible from some of the questions before, but now it should be possible from every 2021-01-08 16:36:46 I've submitted a MR for a new aport so obviously it will go into "testing" initially. This package can be used by an existing other package with is in "main" - is there a procedure for dealing with this eventual "need" for such a new package to work its way from "testing" to "main" in order to enable functionality in an existing package in main? 2021-01-08 16:38:11 once its tested that the package works, you can create an MR where you simply move it to main (or community) 2021-01-08 16:38:24 im gonna tag rc3 now 2021-01-08 16:38:32 every binary in can be used by 'one' pkg in main :) 2021-01-08 16:38:45 in testing* 2021-01-08 16:38:56 (I need coffee) 2021-01-08 16:40:08 ACTION wonders why alpine nowadays have separate subrepos 2021-01-08 16:40:34 rhetorical question, answer is not asked for 2021-01-08 16:42:52 ncopa: I thought as much, in this case its a very small library, !16589, with no tools of its own so not sure how to test it works. The intention is that it will be used by rng-tools (it simply needs rebuilt once library dependancy added) 2021-01-08 16:44:55 and I'm thinking to remove librtlsdr from rng-tools 2021-01-08 16:46:02 mps: too large for you? 2021-01-08 16:46:06 minimal: that is what actually happened to rng-tools when librtlsdr deps added (speaking guilty for that) 2021-01-08 16:46:46 minimal: I looked around and noticed that not much people use rtl sdr devices 2021-01-08 16:47:12 minimal: merged. 2021-01-08 16:47:45 jitterentropy could be more useful than librtlsdr 2021-01-08 16:48:01 this is my impression 2021-01-08 16:48:09 ugh.. i didnt pay attention to the "Apply 1 suggestion(s) to 1 file(s)" 2021-01-08 16:48:09 but time will show 2021-01-08 16:48:24 mps: I can understand the usefulness of RTLSDR is debateable, the usefulness of jitterentropy is that it can be assumed to always be available. Without jitterentropy if you run rngd on a machine with no TPM, no hwrng, no rand instruction then rngd has no entropy source as all 2021-01-08 16:48:36 mps you could update rtl-sdr to 0.7 i've done long ago: https://github.com/aports-ugly/aports/blob/master/ugly/rtl-sdr/APKBUILD 2021-01-08 16:48:43 those messages are not useful at all. should have squashed them and rebased it 2021-01-08 16:49:04 yZ5vlALg86lP: thanks for notice, will look 2021-01-08 16:49:25 minimal: yes, that is what also think 2021-01-08 16:49:49 minimal: the two first commit messages does not make much sense in the bigger picture: https://git.alpinelinux.org/aports/log/ 2021-01-08 16:50:01 mps the main repo changed, and the old you're tracking is not being updated anymore... 2021-01-08 16:50:24 yZ5vlALg86lP: aha, that explains 2021-01-08 16:50:34 it was my fault. i shouldnt have merged :-/ 2021-01-08 16:50:41 ncopa: sorry, first time I've used the "change suggestion" in Gitlab, didn't realise it would generate those entries 2021-01-08 16:51:00 neither did I. it was my fault though. 2021-01-08 16:51:02 normally I've have made changes locally and squashed them. 2021-01-08 16:51:21 i shouldnt look at tiwhile tagging release on a friday night when im tired... 2021-01-08 16:51:31 yeah, squshing them is the correct way 2021-01-08 16:51:40 Is this a new Gitlab feature? Likely others will use it as well and cause the same messages 2021-01-08 16:52:08 gitlab is stupid 2021-01-08 16:52:20 github does probaly the same 2021-01-08 16:52:24 as every gui :) 2021-01-08 16:52:31 perhaps you should disable that feature if possible 2021-01-08 16:52:39 might be a good idea 2021-01-08 16:54:39 ncopa: so how long should I wait before submitting another MR to move jitterentropy-library from Testing to Main? I'm in no big rush and don't want to interfere with 3.13 release (its branched, right? so MRs don't accidently go into that?) 2021-01-08 16:54:44 i think the problem is that github (and microsoft in general) are favoring stickynes (aka vendor lock-in). they want users to stick to github, so they make it convenient to store all the useful info in the discussions instead of the commit messages, so you end up depend on github 2021-01-08 16:55:02 minimal: feel free to do so, but i'm not gonna deal with it today 2021-01-08 16:55:12 im tired. should have stopped long time ago 2021-01-08 16:56:03 _rc3 is out 2021-01-08 16:57:01 mps: if rngd gets jitterentropy-library support added then there's no need in theory for the jitterentropy-rngd package anymore. Currently I use jitterentropy-rngd for machines with no hwrng and rngd for those that do. 2021-01-08 16:58:11 isn't jitterentropy upstream in 5.9 or something 2021-01-08 16:58:42 hopefully it should be better in kernel than in userspace 2021-01-08 16:59:15 even if the premise is questionable, surely kernel can measure more things 2021-01-08 17:00:25 ugh.. pipewire failed on mips64 2021-01-08 17:00:33 so rc3 is not on mips64 2021-01-08 17:02:30 i woudl love some help with testing the installer scripts, since they have some major code cleanups. try to input bad data etc 2021-01-08 17:02:50 try help different disk installs (sys, lvm, raid, data etc) 2021-01-08 17:03:30 Hello71: there is a jitterentropy RNG kernel module but I don't believe it updates the kernel's entropy pool. Its written by the same guy who wrote jitterentropy-library and jitterentropy-rngd 2021-01-08 17:03:52 pretty sure updating entropy estimate was the only point of adding it 2021-01-08 17:04:07 over the objections of tytso etc 2021-01-08 17:04:34 Hello71: From the kernel Kconfig: "This Jitterentropy RNG registers with the kernel crypto API and can be used by any caller" 2021-01-08 17:04:36 as a reaction to widespread use of getrandom during boot 2021-01-08 17:06:10 my interest for adding entropyjitter support to rngd is that currently you can't run rngd on every machine as if there's no entropy source (i.e. hwrng) it exits. With jitter source always available then rngd can be run on all machines knowing that it run regardless of hwrng presence/absence. 2021-01-08 17:06:25 Hello71: /crypto/Kconfig:config CRYPTO_JITTERENTROPY 2021-01-08 17:09:05 ah, my mistake. 5.4 added a separate jitterentropy 2021-01-08 17:09:17 iirc yes 2021-01-08 17:09:37 not sure why they didn't hook up crypto jitterentropy instead... 2021-01-08 17:10:40 since it seems that crypto/jitterentropy is stronger than the basic timer-based one in try_to_generate_entropy 2021-01-08 17:11:04 CRYPTO_JITTERENTROPY is selected by 'CRYPTO_DRBG [=y] && CRYPTO [=y] && CRYPTO_DRBG_MENU [=y]' 2021-01-08 17:12:35 its an alternative to things like haveged 2021-01-08 17:16:10 mps: I thought about packaging up rtl_entropy - that would do a similar job to the rngd RTLSDR source but via a separate package 2021-01-08 17:21:27 Hello71: one last thought about moving fsck into the initramfs - the usual /etc/init.d/fsck runs after clock to ensure the system time is correct, if fsck would be run in initramfs then potentially it would have to load any RTC modules first and set system clock 2021-01-08 17:22:59 and how would that work for SBCs with no RTC? Would initramfs also need to try NTP sync as well? 2021-01-08 17:25:15 speaking about rtc, somebody told me to get rid of "hwclock" service once rtc will work on early boot and replace it with "osclock" but I cant disable hwclock at all, it always start when booting rpi4 2021-01-08 17:25:27 MY-R: that would have been me :-) 2021-01-08 17:25:38 probably! 2021-01-08 17:25:50 https://lore.kernel.org/lkml/CAHk-=whz7Okts01ygAP6GZWBvCV7s==CKjghmOp+r+LWketBYQ@mail.gmail.com/ seems like torvalds basically complained "yes, crypto/jitterentropy does more, but is it actually better" 2021-01-08 17:26:06 not sure it is a convincing argument though 2021-01-08 17:26:21 which Alpine version are you on? There was a change to the osclock init.d so that it "provides: entropy" 2021-01-08 17:26:25 even though in his defense I think he made it before actually committing try_to_generate_entropy 2021-01-08 17:26:47 minimal: 3.13rc2 so ye rtc working now much earlier than before 2021-01-08 17:27:14 minimal: ugh, rpi nonsense 2021-01-08 17:28:16 minimal: in mine "/etc/init.d/osclock" is only provide clock 2021-01-08 17:28:46 MY-R: so you've tried "rc-update add osclock boot" and "rc-update del hwclock boot"? 2021-01-08 17:29:09 My-R: sorry I meant "clock", not "entropy".....to much entropy discussion going on currently :-) 2021-01-08 17:29:14 minimal: yes, and both starting 2021-01-08 17:29:38 is more like it adding automaticly by self because after reboot need del hwclock again 2021-01-08 17:29:55 the "rc-update del hwclock boot" should mean it doesn't start anymore 2021-01-08 17:30:12 is this a "sys" disk image or a run-from-memory? 2021-01-08 17:30:13 after reboot is again back in boot 2021-01-08 17:30:19 from memory 2021-01-08 17:30:31 well did you lbu commit 2021-01-08 17:30:33 so is some hardcoded dependency probably 2021-01-08 17:30:41 of course :) 2021-01-08 17:30:44 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L728 2021-01-08 17:30:57 ah, that's the likely issue then..........don't use run-from-memory here. I guess you need to use something like LBU to write the change so it will be "remembered" 2021-01-08 17:31:02 oh yeah 2021-01-08 17:31:12 ye 2021-01-08 17:32:08 Hello71: rpi nonsense? 2021-01-08 17:32:26 well, rpi is main no-rtc platform 2021-01-08 17:32:53 ask mps: there's plenty of non-rpi SBCs with no RTC 2021-01-08 17:33:03 sure 2021-01-08 17:33:27 but how many running alpine 2021-01-08 17:34:09 minimal: I wasnt sure if is correct behavior but all working fine so I dont care much :) 2021-01-08 17:35:06 Hello71: but even forgetting machines with no RTCs, what about the matter of needing to load RTC modules (e.g. on non-x86/x86_64 servers which have multiple various RTC modules) and setting the system clock in initramfs before trying fsck? 2021-01-08 17:35:20 ugh. 2021-01-08 17:35:34 minimal: I don't think you can disable merge request suggestions 2021-01-08 17:35:47 does f2fs fsck actually check rtc 2021-01-08 17:35:53 or applying them through the interface 2021-01-08 17:36:08 ikke: Fun, expect various people to use that "useful" feature lol 2021-01-08 17:36:17 Yes, I've already seen it 2021-01-08 17:36:35 It's not new btw 2021-01-08 17:37:33 e2fsck specifically checks if clock is before year 2010 2021-01-08 17:38:00 and anyways I think it should not be required for fsck except for setting last mount/last write time 2021-01-08 17:39:05 for f2fs it seems used for "quota grace time" 2021-01-08 17:39:08 Hello71: general when an FS is properly unmounted the data/time is stored so then when its fsck'ed if the time is "in the future" due to clock beig wrong then fsck generally isn't happy, things like "UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY" 2021-01-08 17:41:07 i think this was true of old e2fsck 2021-01-08 17:42:11 https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=177839e24 very old e2fsck 2021-01-08 17:42:40 without correct time then settings like the interval between checks will not work as expected 2021-01-08 17:43:26 that's set to 0 nowadays anyways 2021-01-08 17:44:41 and looking at pre-177839e24, it wasn't UNEXPECTED INCONSISTENCY, it was just running checks every boot 2021-01-08 17:45:48 by default you mean? Any when someone sets it using tune2fs to something like 30 days.....but finds it doesn't work as expected if initramfs runs fsck without setting clock first? 2021-01-08 17:46:13 and what about other FSes apart from EXT2/3/4? how do they react if system time is "in the past"? 2021-01-08 17:46:15 yes, I mean by default 2021-01-08 17:46:28 idk, check what debian does 2021-01-08 17:47:13 apparently periodic checking has also been off by default for 10 years: https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=3daf59264 2021-01-08 17:47:27 in general fsck tools rely on system time as being correct so if the fsck is moved into the initramfs then it follows that the system time setup needs to also move into initramfs 2021-01-08 17:47:45 surely fsck relies more on the fs being unmounted than the system clock 2021-01-08 17:48:23 i'll concede that the system clock is sometimes used, but in that case swclock is useless 2021-01-08 17:48:28 as you've said yourself earlier that depends on each of the various fsck tools 2021-01-08 17:50:55 there's no point to set the system clock to the shutdown time before running fsck 2021-01-08 17:51:01 it that was useful then the fsck could just do that itself 2021-01-08 17:51:10 for swclock I agree and in the no-RTC scenario is already an issue earlier in the boot sequence than swclock - OpenRC itself relies on the system time being correct as it checks the file timestamps of cached config files at startup - on a SBC you'll see "clock skew" messages from OpenRC early in the boot process (even if they have a RTC with a module driver and the kernel module loading is run later by OpenRC) 2021-01-08 17:51:21 if you want the clock to be accurate without rtc, then you need ntp (or similar) 2021-01-08 17:51:45 and https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-ntp.in#L53 starts ntp daemon at default, not sysinit 2021-01-08 17:52:27 /boot, which is presumably where you would need it to be for it to be ready before fsck 2021-01-08 17:53:24 re: NTP - again the NTP daemon is run by OpenRC after OpenRC has already complained about the system time ("clock skew") message 2021-01-08 17:53:28 so i'm not sure your concern is actually addressed by the current system either 2021-01-08 17:53:40 yes, but we're talking about fsck now 2021-01-08 17:54:32 yes and /etc/init.d/fsck defines "after clock" so whether clock is fulfilled by "osclock", "hwclock", or "swclock" the fsck happens after the clock is somehow set 2021-01-08 17:55:16 if you move the fsck action to the initramfs then you'll still need to satisfy the "set the system clock before running fsck" but inside initramfs instead 2021-01-08 17:55:22 right, but my point is that there's no point running swclock before fsck 2021-01-08 17:55:44 hwclock could be useful 2021-01-08 17:56:35 agreed that swclock is a kludge - it "sort of works" when you reboot a machine as the time ends up being less than a minute wrong. 2021-01-08 17:56:53 well i think the idea is to avoid time going backwards 2021-01-08 17:57:18 which is the main problem because it breaks make-style freshness check 2021-01-08 17:58:11 I agree that machines really should have a RTC - all my RPIs do and its why I got the fix into the linux-rpi so that the RTC driver was built into the kernel so that the kernel would set system time from RTC in early boot rather than Alpine needing to do so (and then "osclock" is only a stub to satisfy the "after: clock") 2021-01-08 18:01:02 but as I explained earlier there is more than just the non-RTC machine scenario to consider - x86/x86_64 is standardised on 1 RTC driver, rtc_cmos, and its compiled into the kernel. On Arm server machines (e.g. AWS, Packet.net, etc) there can be a variety of RTC chips as its not standardised and so their kernel modules need to be loaded and system time set from RTC afterwards during boot before fsck is run 2021-01-08 18:01:28 but that's not swclock or ntp, that's hwclock 2021-01-08 18:02:46 yes, as I have explained there are *multiple* scenarios that moving fsck to initramfs will impact - (1) non-RTC machines, and (2) machines with RTCs whose drivers are loaded as kernal modules 2021-01-08 18:08:12 and as I explained before the swclock, ntp, and hwclock functionality would then need to move to initramfs to happen before fsck 2021-01-08 18:09:09 and as I said already, ntp doesn't run before fsck. chrony doesn't work right on ro fs anyways 2021-01-08 18:10:40 yupe and as I said already I agreed that non-RTC machines are generally problematic 2021-01-08 18:24:29 . 2021-01-08 18:24:43 Hey not sure exactly what's etiquette and protocol here but I've got three questions, that I'm hoping this is the right place. 2021-01-08 18:25:02 1) How do I go about getting a change to a testing aport merged? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16281 2021-01-08 18:25:24 The initial commit to add it was just picked up reviewed by someone, but this one hasn't. 2021-01-08 18:28:06 there is some busyness related to 3.13 release soon(tm) 2021-01-08 18:29:15 Ah ok, so process is someone will pick it up eventually things are just busy right now. I can wait :) 2021-01-08 18:32:10 Question 2) I've been looking at further improvments to that package but it uses protoc which currently needs (https://github.com/sgerrand/alpine-pkg-glibc) installed as a workaround. While that repo does have an APKBUILD it's not in aports, not sure what's best in terms of using that in my APKBUILD? I can just redefine deps/undeps to sudo 2021-01-08 18:32:10 install/uninstall from that repo, or I could submit that APKBUILD to aports? 2021-01-08 18:32:35 And question 3) Another dependency of the pulumi package is dotnet. There's no aport for that and it feels a bit uh for me to just claim the dotnet aport. Any guidance here? I think I could write the APKFILE for it but feels a bit iffy submitting the aport for something so major... 2021-01-08 18:33:37 I do currently have a workaround for 3 where dotnet can install locally into src, so that's probably the best course to take but thought I'd just check out thoughts here. 2021-01-08 18:48:14 Well, I doubt anyone is interested in maintaining dotnet when no one introduced the APKBUILD for it yet 2021-01-08 19:36:44 Frassle: protoc ? 2021-01-08 19:38:36 protoc, protobuf stuff is neatly packaged on alpine 2021-01-08 20:28:14 Hello71: so I made some research and no, my kernel doesn't have 100 layer deep directories, but the dts files that get compiled have each above 100 nested include files (with max 119), don't know if they're all really needed or is it just bad design, but yeah seems like I do need to increase the MAX_SRCFILE_DEPTH limit 2021-01-08 20:29:59 so repeating my question, how would I go about making my case to change the upstream alpine dtc to increase that limit, can I just make a MR somewhere? 2021-01-08 20:53:46 100 layers deep or 100 entries each 2021-01-08 21:02:09 ignapk: An MR or issue will work 2021-01-08 21:02:40 artok: It's because it's using the Grpc.Tools nuget package which has its own protoc built in which needs glibc and won't run on alpine. 2021-01-08 21:03:15 https://github.com/grpc/grpc/issues/18428 2021-01-08 21:05:12 Hello71: each dts includes dtsi files which in turn include other dtsi files etc and summing up all the includes for each dts files accounts for just over 100 2021-01-08 21:05:16 ikke: Ok 2021-01-08 21:06:13 ah, it is actually a bug 2021-01-08 21:07:12 MAX_SRCFILE_DEPTH is actually just the number of includes 2021-01-08 21:07:47 yes 2021-01-08 21:08:40 probably it would be better to fix that 2021-01-08 21:08:45 or at least rename it if there is no fix 2021-01-08 21:56:12 maxice8: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16443#note_134875 but then people who install only mumble client (not murmur server) will have unnecessary initd file or no? 2021-01-08 21:56:55 MY-R: you can add default_openrc in that function it will move it to the subpackage 2021-01-08 22:01:57 hmm, until that work then is fine :) but would be good to fix that before release 3.13 so people after upgrade (like me :D) wont be wondering why their 'init.d/murmur' gone :P 2021-01-08 22:09:23 too late but, if machine doesn't have RTC and battery (and both works) there is no final solution to set clock on boot. network? it it works 2021-01-08 22:10:09 you need ntp at that point, not? 2021-01-08 22:10:27 if net works yes 2021-01-08 22:11:03 (but these people like 'yak shaving') 2021-01-08 22:11:56 isnt like clock then is set up based on some files modification date/time? 2021-01-08 22:12:15 isnt accurate but at least not year 1970 2021-01-08 22:12:22 I wanted to say that there is no perfect solution to that problem 2021-01-08 22:12:30 ye that for sure 2021-01-08 22:13:05 that is why I cant understand why producing devices without rtc :\ 2021-01-08 22:13:15 there is fakeclock somewhere, which remembers last time when machine saves datetime and read it on boot 2021-01-08 22:13:32 yeah, that's the only option without network 2021-01-08 22:14:03 not perfect (or good well) but usable for fsck problem 2021-01-08 22:14:33 because fsck is based on time? 2021-01-08 22:14:39 fsck schedule 2021-01-08 22:14:56 for some old FS it was based on time 2021-01-08 22:15:15 nowadays they use the amount of mounts, right? 2021-01-08 22:15:54 long time I didn't saw 'XXX days pass from last fsck, running fsck /dev/hda2' (or something similar 2021-01-08 22:16:55 I'm not sure even number of mounts is used nowadays, but probably could be set by 'tunefs' type tools 2021-01-08 22:17:35 with journals this is not needed 2021-01-08 22:17:46 nod 2021-01-08 22:18:06 I read somewhere today that kernels can do journal replays 2021-01-08 22:18:13 in case of serious FS corruption user will be informed by 'harsh' message 2021-01-08 22:18:46 and then offline fsck could help, as it helped me few times 2021-01-08 22:19:48 yes, at least ext4 fs driver can 'replay' (and it does) uncommited journals 2021-01-08 22:23:47 @mps: I did have an openrc patch for non-RTC devices I used for a short time myself to set the system clock from the timestamp of the file openrc touches during shutdown - it got rid of the "clock skew" messages during boot but having system time "slightly wrong" isn't much of an improvement from it being completely wrong - so I never bothered to submit an MR with the patch 2021-01-08 22:24:57 minimal: I don't think such change is needed for alpine, sorry if I look harsh 2021-01-08 22:25:57 like you I agree machines should all have RTCs, heck its only approx $2 for the ones I fit to RPIs. 2021-01-08 22:26:25 yes, agree 2021-01-08 22:26:47 and we are not 'universal OS' 2021-01-08 22:27:31 I didn't raise an MR for it as I didn't feel completely happy with the "hack" myself and expected it to meet resistance. Instead I got the main RTC driver used by 3rd party RPI addons built into the kernel and so it became a non-issue for RPIs with RTCs fitted. 2021-01-08 22:27:56 minimal: btw, I will try to find time over weekend to look at jitterentropy problem and solution. but couldn't promise solution 2021-01-08 22:28:08 which problem? 2021-01-08 22:28:21 ikke: after excessive testing, I found that docker clock_gettime64 can be reproduced with raspbian + docker.io official "convenience install script" 2021-01-08 22:28:24 jitterentropy-rngd 2021-01-08 22:28:44 Hello71: haa 2021-01-08 22:28:45 mps: what's the problem? The updated version I submitted was merged. 2021-01-08 22:28:46 aha* 2021-01-08 22:28:59 it works fine with alpine 3.12 and alpine edge docker 2021-01-08 22:29:02 minimal: merged, then ok 2021-01-08 22:29:13 unfortunately they don't have deb-src so idk how their package is different 2021-01-08 22:29:16 Hello71: you mean as a host? 2021-01-08 22:29:20 yes 2021-01-08 22:29:23 ok 2021-01-08 22:29:32 Did you try overriding the seccom profile? 2021-01-08 22:29:58 I've also had jitterentropy-library merged - I need to get that into "main" so then I can raise a rng-tools MR so that rngd will use it (rngd's jitter entropy source needs that library) 2021-01-08 22:31:54 not yet, it works with seccomp=unconfined 2021-01-08 22:32:07 right, 2 others confirmed that as well 2021-01-08 22:32:08 minimal: I just created rng-tools upgrade MR 2021-01-08 22:32:21 Hello71: did you override it on dockerd level, or just that specific container? 2021-01-08 22:32:31 --security-opt=seccomp=unconfined 2021-01-08 22:32:36 some CIs looks stuck 2021-01-08 22:32:42 mps: I raised rng-tools upgrade MR 5+ hours ago 2021-01-08 22:32:47 ok, can you try to start dockerd with --seccomp-profile 2021-01-08 22:33:01 (passing it the latest profile) 2021-01-08 22:33:04 minimal: too late ;) 2021-01-08 22:33:11 also I was thinking maybe it is related to kernel config? 2021-01-08 22:33:23 minimal: number? 2021-01-08 22:33:24 yes, that was my next step, but need to head out atm 2021-01-08 22:33:30 mps: it was me who got 6.11 released upstream today, I'd asked the author to do so 2021-01-08 22:33:46 !16605 2021-01-08 22:33:51 Hello71: lol, everyone seems to stall at that step :P 2021-01-08 22:33:58 heh, you should tell here 2021-01-08 22:34:16 !67348 2021-01-08 22:34:20 mps: there are some long running jobs 2021-01-08 22:34:28 but they seem to still continue 2021-01-08 22:34:50 !16620 2021-01-08 22:36:37 mps: the PIC patch isn't needed anymore, I confirmed with author and also I made various other changes - i.e. the RTLSDR stuff wasn't actually enabled despite the make-depends as it needed "--with-rtlsdr" to enable it 2021-01-08 22:37:23 so my MR is more comprehensive than yours 2021-01-08 22:38:10 minimal: yes. and your MR looks more complete, only -openrc part doesn't look good (too much imo) 2021-01-08 22:38:57 made the MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16621 2021-01-08 22:39:11 mps: so you'll close your MR? As for the config - trying to ensure that (a) it works out of box but also (b) is easy to tweak config 2021-01-08 22:39:31 I kind of suspect I will be told to go directly to the upstream itself but doesn't hurt trying 2021-01-08 22:39:33 minimal: small, simple ... 2021-01-08 22:40:06 mps: as I was saying a little earlier I held back one change as the new jitterentropy-library needs to get into "main" first before rng-tools can use it 2021-01-08 22:40:20 minimal: no, I like to keep useless open MRs around :P 2021-01-08 22:40:53 where is jitterentropy-library 2021-01-08 22:41:22 its a new aport - was merged earlier today into "testing" 2021-01-08 22:42:04 aha, iiuc you want it moved to main before rng-tools upgrade 2021-01-08 22:43:43 mps: nope! the rng-tools upgrade will go ahead. After that at some point I will move jitterentropy-library to main and then raise new rng-tools MR to make-depend on it to enable the jitter source. I guess I could disable rtlsdr in the same future MR, especially if I manage to package up rtl_entropy instead 2021-01-08 22:45:42 minimal: understand. for such changes I wouldn't mess before asking maintainer 2021-01-08 22:46:06 minimal: ds3231 with small battery which fit to rpi is for 1$ and when taking more then those are cents :\ 2021-01-08 22:47:12 mps: agreed. In general I've found some (other) maintainers unresponsive - I emailed a couple about 4 weeks rather than just raising MRs on their packages but never heard back 2021-01-08 22:48:16 minimal: such mails should be 'Cc'-ed to alpine-devel ML 2021-01-08 22:48:28 MY-R: depends on which country your in etc. I bought another 5-pack before Xmas for approx $7 (I'm not in USA) 2021-01-08 22:49:04 me either, east europe 2021-01-08 22:49:21 mps: didn't know that. Will consider resending them perhaps. Was mainly about suggesting taking over maintainership of some out-of-date packages 2021-01-08 22:50:19 MY-R: you are in country of saunas, iirc 2021-01-08 22:50:44 mps: one of the issues I wouldn't CC to the list as its around license issue - wanted to talk directly to maintainer but never heard back 2021-01-08 22:50:50 more like country of alcoholics and thieves :D 2021-01-08 22:50:59 MY-R: moi! 2021-01-08 22:51:08 :) 2021-01-08 22:51:35 .pl 2021-01-08 22:52:09 MY-R: I thought you are in finland 2021-01-08 22:52:24 nope 2021-01-08 22:52:45 mps: maybe you misunderstood when he said he was finnished ;-) 2021-01-08 22:52:53 ps so how is with firefox currently? stable? crashing? :\ 2021-01-08 22:52:57 hehe 2021-01-08 22:52:57 :D 2021-01-08 22:53:33 minimal: good joke, I have to keep stomach 2021-01-08 22:54:06 long time I didn't saw stable FF 2021-01-08 22:54:28 though it works most of time, on edge and 3.12 2021-01-08 22:54:28 mps: so what happens if your rng-tool MR gets merged rather than mine? 2021-01-08 22:54:49 minimal: I will hold my for now 2021-01-08 22:55:02 thanks 2021-01-08 22:56:04 I only asked the upstream author for a new release once I'd spent a couple of days testing my changes locally - was trying to avoid someone seeing the upstream release and pushing an MR before I got mine out :-) 2021-01-08 22:56:12 but please, try to make -openrc changes smaller 2021-01-08 22:57:00 minimal: also I have some mails exchanged with rng-tools upstream 2021-01-08 22:57:27 mps: what would you suggest? I could remove some of the (verbose) text - its not necessary but was trying to make things self explanitory - I have to trawl through the code to find which source were default enabled/disabled for example 2021-01-08 22:58:10 s/have/had/g 2021-01-08 22:58:11 minimal meant to say: mps: what would you suggest? I could remove some of the (verbose) text - its not necessary but was trying to make things self explanitory - I had to trawl through the code to find which source were default enabled/disabled for example 2021-01-08 22:58:15 minimal: and look at my commit message 2021-01-08 22:59:01 mps: saw it, was there something I'd missed? 2021-01-08 22:59:13 minimal: yes, these 'self explanatory' is what looks not nice to me 2021-01-08 22:59:52 minimal: no, everything is ok with your MR, except -openrc 2021-01-08 23:00:45 huh, midnight passed, time to stop babbling here 2021-01-08 23:01:15 mps: I'll reduce the text as part of the next MR which will also enable jitter source and probably disable rtlsdr 2021-01-08 23:01:36 yupe, its late here too 2021-01-08 23:04:42 minimal: overall your changes are good, and I'm not against that you take maintainership 2021-01-08 23:06:25 mps: for rng-tools, that was a thought but didn't suggest it yet to current maintainer. Was referring to a couple of other, unnamed packages, that I did ask their maintainers if they were willing for me to take over 2021-01-08 23:12:09 anybody tested the rc3 extended iso? does not work at all for me, seems the kernel package is not in place (no /lib/modules/ etc), and quite a lot of warnings during boot 2021-01-08 23:12:57 if you pass a partion with an fs on it (the one you would like to install to) it seems its mounted already during boot and overwriten 2021-01-08 23:13:23 but too late in the night for me now to continue 2021-01-08 23:14:02 (with pass, I am refering to a virtual disk as I am testing in a VM) 2021-01-09 00:41:14 ikke, ncopa: finally figured this shit out. you need docker 19.03.9 *and* libseccomp 2.5.0 2021-01-09 00:47:26 2.4.2 i mean 2021-01-09 00:48:14 and debian buster is stuck on 2.3.3 2021-01-09 01:19:18 grumble grumble grumble 2021-01-09 01:31:41 dammit and I already deleted my raspbian :/ 2021-01-09 01:52:49 Just stumbled upon https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/587 2021-01-09 03:42:59 ok, the workaround in https://github.com/docker/for-win/issues/8326 does in fact work on Linux too 2021-01-09 03:43:03 unsurprisingly 2021-01-09 06:36:06 are old alpine packages archived someplace? 2021-01-09 07:15:32 ah I guess getting it from a stable release branch is good enough 2021-01-09 08:16:19 Hello71: Nice find! 2021-01-09 08:41:36 TBK[m]: i don't see the relevance -- alpine does not (and will not) support the proprietary nvidia driver 2021-01-09 08:47:07 seems that py3-sip needs some care to get updated to 6.0.0. py3-sip-qt5 is now and independent package 2021-01-09 08:48:00 this affects also how py3-qt5 is built 2021-01-09 09:28:13 I'm not sure if we even want to upgrade to 6.0.0? 2021-01-09 09:28:41 Qt6 seems to be very incomplete and I don't think applications will start porting to it before 6.1 because of that 2021-01-09 09:56:35 most likely, we will ship qt5/qt6 simultaneously 2021-01-09 09:56:54 but, qt really needs to be forked 2021-01-09 09:57:01 the qt company is not a responsible steward 2021-01-09 09:57:24 if a qt fork happens, i doubt many will care about qt6 2021-01-09 09:57:52 and it is looking like a fork may happen due to dropping qt non-commercial LTS in favor of "lol jump on board the broken qt6 train" 2021-01-09 09:58:55 Yes, we'll have to ship qt5&qt6 simultaneously, but I don't think we'll have to do it before qt6.1 2021-01-09 09:59:29 Well, Qt5 OSS is basically unmaintained now AFAIU 2021-01-09 09:59:54 Other than things like Qt5WebEngine 2021-01-09 10:04:49 qt should go to /dev/null long ago 2021-01-09 10:10:54 lots of software depending on qt in some form 2021-01-09 10:14:09 yes, and that is also not good 2021-01-09 10:14:11 mps: it is still better than gtk 2021-01-09 10:14:52 yes, and that is also not good 2021-01-09 10:14:55 :) 2021-01-09 10:15:24 i think qt under real community governance would be fine 2021-01-09 10:15:37 I agree with this 2021-01-09 10:15:43 the real problem is that the Qt company has fucked over the community hardcore 2021-01-09 10:15:50 with qt6 and trying to 'monetize' 2021-01-09 10:16:11 KDE folks want to fork Qt 5.15 2021-01-09 10:16:20 and seem skittish on Qt 6 2021-01-09 10:16:38 actually I never tried to 'use' qt because of mentioned company 2021-01-09 10:37:16 ikke: there's gtk->qt shim 2021-01-09 10:37:20 if you want more 2021-01-09 10:37:46 https://github.com/e8johan/gtk-made-qt 2021-01-09 10:55:05 insep_: "This is very far from production ready. Feel free to improve!" 2021-01-09 10:55:27 so, a nice poc, but still needs work 2021-01-09 10:58:47 But GTK's nice :D 2021-01-09 11:03:30 no it's not 2021-01-09 11:04:54 I guess it would be best for KDE to fork Qt 2021-01-09 11:07:33 GTK is great if you're a "GNOME app" 2021-01-09 11:07:43 if you are not, it becomes not great very quickly 2021-01-09 11:07:59 gtk is great, though it is bad 2021-01-09 11:08:59 "We're also considering switching Docker Desktop to using a dynamically-linked dockerd, which would allow Desktop to bump the libseccomp version in our Dockerfile without worrying about effects on armhf" 2021-01-09 11:09:17 Projects discoverying there _is_ merrit to dynamic linking 2021-01-09 11:09:25 wow! shocked!! 2021-01-09 11:19:54 jokes aside, but I think gtk is less bad of all gui toolkits we have 2021-01-09 11:20:07 least* 2021-01-09 11:20:36 but we do not decide what toolkit projects use 2021-01-09 11:21:06 yes, but we can decide what to 'git rm' 2021-01-09 11:22:02 We would drop gnome, kde, and with that, also what pmos does 2021-01-09 11:22:10 I don't think deleting things which use Qt is an option 2021-01-09 11:22:46 Anyway, let's see how this develops, I do hope the KDE project will make a Qt5 fork, would suck if every distro managed their own bunch of downstream patches 2021-01-09 11:23:20 unfortunately you are right 2021-01-09 11:24:54 ~1200 packages have some dependency on qt5 2021-01-09 11:25:46 in community 2021-01-09 11:33:38 mps: Could you take a look at !16605 2021-01-09 11:41:26 Hello71: do you happen to know what specific change in libseccomp fixes this issue? 2021-01-09 11:42:20 Can we actually use `tox` in python tests? AFAIU tox sets it own virtualenv up and doesn't use our own python packages, or does it? 2021-01-09 11:42:22 ACTION has no clue about python 2021-01-09 11:43:27 I think it can run tests on the system as well 2021-01-09 11:48:06 https://pypi.org/project/tox-current-env/ plugin is needed 2021-01-09 11:49:53 "Well, it turns out that tox became too popular and gained another purpose." 2021-01-09 11:54:45 nicely put 2021-01-09 11:57:57 heh 2021-01-09 11:58:05 ikke: Could you test !16046 on armhf? 2021-01-09 12:03:26 Cogitri: ok, let me try 2021-01-09 12:03:56 When projects use tox, you can most of the time still just run pytest 2021-01-09 12:06:46 Okie, I guess would be best to just do that then 2021-01-09 12:07:33 How about I close all the sec issues for Alpine 3.8 + 3.9 ? They're unsupported by now anyway. 2021-01-09 12:10:41 3.9 officially is still supported until 3.13 is released :) 2021-01-09 12:15:05 bind release model update: https://www.isc.org/blogs/2021-bind-release-model/ 2021-01-09 12:15:14 ikke: We should update https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases then 2021-01-09 12:15:27 The dates are generally guides 2021-01-09 12:20:53 Cogitri: building zstd now on armhf 2021-01-09 12:21:06 Cogitri: I looked last night and waiting for minimal to clean init script, and to contact maintainer. I don't think it is good idea to make such big change without maintainer consent 2021-01-09 12:36:57 I guess since 3.13rc3 is already out 3.9 will be EOL in a few days though 2021-01-09 12:37:11 yeah, would not take long 2021-01-09 12:37:17 mps: Ah okay, I was just confused since we have two MRs for the same thing 2021-01-09 12:45:04 Cogitri: I keep my in 'hold' just in case if the minimal does not fix his in reasonable time 2021-01-09 12:47:05 though I proposed he should take maintainership because current maintainer didn't answered minimals private mail for more than a month (as minimal told last night here) 2021-01-09 12:49:28 so much new games in MRs, averts me from useful ones 2021-01-09 12:50:16 maybe is time to create 'useless' subdir in aports ;P 2021-01-09 12:50:48 :D 2021-01-09 13:04:01 Cogitri: Bus error (core dumped) 2021-01-09 13:06:19 Ah, zstd on armhf? 2021-01-09 13:06:34 yes 2021-01-09 13:06:43 How weird, we're getting the same failure w/ rav1e on aarch64 and ppc64le, I wonder if there's an error elsewhere 2021-01-09 13:06:47 Is there a coredump somewhere? 2021-01-09 13:07:14 I'd need to enable them, let me do that 2021-01-09 13:07:53 oh, ulimit -c was already unlimited 2021-01-09 13:08:05 ./src/zstd-1.4.8/tests/core 2021-01-09 13:08:13 so yes, there is a coredump 2021-01-09 13:10:14 Could you get backtrace of that? 2021-01-09 13:10:26 mps: !16162 how come you only approved it and didn't merge it? 2021-01-09 13:10:56 Cogitri: need to figure out what executable produced that coredump 2021-01-09 13:12:07 I think dmesg logs that 2021-01-09 13:12:49 zstd -f tmp from the playtests.sh 2021-01-09 13:13:24 ok, can repro it 2021-01-09 13:14:08 https://tpaste.us/zxOa 2021-01-09 13:14:56 OK, thanks, posted it on the MR 2021-01-09 13:15:38 trying to build it with no optimizations 2021-01-09 13:16:39 aaaand no more coredump 2021-01-09 13:18:21 Huh 2021-01-09 13:18:26 As in it works? 2021-01-09 13:18:53 zstd -f tmp 2021-01-09 13:19:10 that first gave a bus error, now no longer does, trying to increase optimization step by step 2021-01-09 13:19:14 see if that makes a different 2021-01-09 13:19:23 difference 2021-01-09 13:20:09 PureTryOut[m]2: Could you take a look at https://build.alpinelinux.org/buildlogs/build-3-12-aarch64/community/systemsettings/systemsettings-5.18.6-r0.log ? 2021-01-09 13:22:06 I already did while it failed on CI and had no luck so far. Why did it get merged with broken CI? 2021-01-09 13:22:33 :/ 2021-01-09 13:23:02 Merged by Rasmus Thomsen 1 hour ago 2021-01-09 13:23:52 I guess revert it 2021-01-09 13:23:54 mps: and lots of them (games) use sdl1, I which they were all flatpak so it wouldn't be our problem and would just work 2021-01-09 13:24:12 Yuck, somehow I thought I checked out CI and it only failed due to upload size 2021-01-09 13:24:28 But I guess that was the other KDE MR 2021-01-09 13:24:39 Maybe you could mark known broken MRs as WIP though 2021-01-09 13:28:27 Want me to revert it? 2021-01-09 13:28:30 Well when I made it I didn't know it was broken πŸ˜‚ But will mark it in future later 2021-01-09 13:28:33 Yes please, for now 2021-01-09 13:29:33 PureTryOut[m]2: ftr, I'm working on CI not trying to upload artifacts if it know's they're too big 2021-01-09 13:30:08 Cogitri: interesting, it looks like make check builds everything again, and then it gives the error 2021-01-09 13:30:23 Huh 2021-01-09 13:31:13 if I run abuild build and then do ../zstd -f tmp, it goes through 2021-01-09 13:31:52 testing now make check again 2021-01-09 13:32:51 yes 2021-01-09 13:33:16 so abuild -r -> coredump; followed by abuild build -> success; followed by make check -> coredump 2021-01-09 13:35:19 Cogitri: might have to do with the flags being passed 2021-01-09 13:35:46 make check needs the same flags as make 2021-01-09 13:37:23 Cogitri: re !16162 I wait for 3.13 builders to finish with crystal 2021-01-09 13:38:04 build fails in my dev lxc but ncopa told that it somehow passed builders 2021-01-09 13:38:32 in meantime I forgot this MR 2021-01-09 13:38:42 Cogitri: updated MR 2021-01-09 13:38:45 comment 2021-01-09 13:39:03 always fun with make 2021-01-09 13:39:35 Cogitri: I will merge it and pray ;) 2021-01-09 13:41:05 huh, interesting commit msgs 'alpine/aports:master | Eric Tian | Apply 1 suggestion(s) to 1 file(s) |' 2021-01-09 13:42:38 mps: that means someone pressed the 'apply suggestions' button after a reviewer added a suggested edit 2021-01-09 13:43:15 whatever, but msgs are bad 2021-01-09 13:43:23 yes, blame gitlab 2021-01-09 13:43:44 And there is no way that you can force someone to at least supply a sane commit message 2021-01-09 13:43:58 So we need to be dilligent to review the commit messages as well 2021-01-09 13:44:36 hmm, that means 'burden on commiters back' 2021-01-09 13:45:07 well, you need to verify the commit messages anyway 2021-01-09 13:45:46 inbefore CI for commit messages 2021-01-09 13:46:06 Yes, forgot to check the squash commits button, sorry 2021-01-09 13:46:30 Thought Gitlab did that automatically when you apply suggestions 2021-01-09 13:46:34 nope 2021-01-09 13:46:40 it just appens useless commits 2021-01-09 13:46:42 appends 2021-01-09 13:46:44 :/ 2021-01-09 13:47:50 The only thing you can do is to override the commit message template 2021-01-09 13:49:05 https://ibb.co/NTH9P26 2021-01-09 13:49:52 Doesn't look too helpful either :/ 2021-01-09 13:49:55 nope 2021-01-09 13:51:57 https://gitlab.com/gitlab-org/gitlab/-/issues/25381 2021-01-09 13:54:53 I can modify our update hook to look for these kinds of messages 2021-01-09 14:07:13 ikke: https://github.com/seccomp/libseccomp/commit/bf747eb21e428c2b3ead6ebcca27951b681963a0 but i couldn't find anyone backporting it past the official 2.4.2 2021-01-09 14:07:40 I also updated the draft release notes and commented on the two aports issues. I think they can be closed now 2021-01-09 14:22:58 Hello71: thanks 2021-01-09 14:24:30 ubuntu backported libseccomp 2.4.3 in https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055 2021-01-09 14:37:33 ah but wait, there is a third compatibility quirk. it needs to be libseccomp 2.4.2 or greater *compiled against Linux headers 5.4 or greater* 2021-01-09 14:37:42 as pointed out in the ubuntu bug I didn't actually read 2021-01-09 14:38:09 which means that Arch doesn't work either despite having up-to-date libseccomp 2021-01-09 14:46:38 wait, no, I just didn't pass -t x86 2021-01-09 14:46:41 -a 2021-01-09 14:52:09 mps: I made some minor changes to my rng-tools MR last night, mainly to address an issue around rngd's parsing of command-line options. As part of the changes to the MR, !16605, I reduced the text in the conf.d file by approx 1/3 - not sure if this is enough to make you happy ;-) 2021-01-09 14:53:23 mps: BTW I didn't yesterday that the rng-tools maintainer has not responsive, I was referring to some other maintainers. Anyway I've just sent the rng-tools maintainer an email and CC'ed alpine-dev (as you suggested). 2021-01-09 14:53:37 s/has/saw/g 2021-01-09 14:53:38 minimal meant to say: mps: BTW I didn't yesterday that the rng-tools maintainer saw not responsive, I was referring to some other maintainers. Anyway I've just sent the rng-tools maintainer an email and CC'ed alpine-dev (as you suggested). 2021-01-09 14:53:46 s/saw/was/g 2021-01-09 14:53:46 minimal meant to say: mps: BTW I didn't yesterday that the rng-tools maintainer was not responsive, I was referring to some other maintainers. Anyway I've just sent the rng-tools maintainer an email and CC'ed alpine-dev (as you suggested). 2021-01-09 14:56:19 https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.13.0#musl_1.2 this section is now growing longer and longer 2021-01-09 15:12:42 minimal: still looks too big for me, both init and conf files 2021-01-09 15:14:47 our moto is: small, simple, secure^W 2021-01-09 15:15:27 in other word: minimal :) 2021-01-09 15:17:18 mps: well I can shrink the conf.d if I take out most or all of the comments but I can't really shrink the init.d any more as that would affect the configuration functionality 2021-01-09 15:19:01 yes, too much comments (and long ones) are not needed, imo. people can read docs if they need understanding config options 2021-01-09 15:19:34 mps: docs for rngd aren't great, I had to read the code itself to figure out the default enabled sources for example 2021-01-09 15:20:00 then you can extend docs 2021-01-09 15:21:29 I'm really disappointed by postfix default files in /etc/postfix 2021-01-09 15:22:19 not to talk about vim default installed files 2021-01-09 15:23:08 mps: so if I shrink conf.d more but leave init.d as is that make you happy? 2021-01-09 15:23:37 minimal: I'm already happy, no worries :) 2021-01-09 15:24:41 minimal: and I don't want to force you to do anything, just expressing my POV 2021-01-09 15:25:24 any other developer is free to merge MR, I will not object 2021-01-09 15:26:56 minimal: and I have tell again, your work on rng is really good imo 2021-01-09 15:27:05 mps: understand, I'm trying to compromise too as realise that things in Alpine need some form of group consensus to work 2021-01-09 15:28:08 mps: thanks, hopefully the existing maintainer will agree to me taking over - looks like his email address in the APKBUILD has a typo, so had to resend my email to him 2021-01-09 15:30:23 noticed that 2021-01-09 16:07:51 ikke: oh awesome! Yeah it's a bit annoying if CI basically succeeded but then fails because of something I can't do anything about 2021-01-09 16:09:27 Yeah, and it should prevent these kinds of issues where people just assume the pipeline faild due to this 2021-01-09 16:09:39 πŸ‘οΈ 2021-01-09 16:09:40 Kind of defeating the purpose 2021-01-09 16:27:23 anybody that have tested a rc3 x86_64 installer yet? 2021-01-09 16:28:09 get no souch file or directory from modprobe during boot (/lib/modules is missing on the iso) 2021-01-09 16:28:32 HRio: not yet, but let me try 2021-01-09 16:28:41 s/souch/such/ 2021-01-09 16:28:41 HRio meant to say: get no such file or directory from modprobe during boot (/lib/modules is missing on the iso) 2021-01-09 16:30:14 /etc/apk/world shows only alpine-base and openssl as installed 2021-01-09 16:31:01 on the installed system? 2021-01-09 16:31:11 directly after boot 2021-01-09 16:31:19 before running setup-alpine 2021-01-09 16:31:50 no .ko files found in this system, so does not even have support for ext4 and can not load it 2021-01-09 16:32:24 boot from iso? 2021-01-09 16:32:27 ys 2021-01-09 16:32:29 yes 2021-01-09 16:32:31 ok 2021-01-09 16:32:37 tried boot iso boot in xen and in kvm 2021-01-09 16:32:59 trying it now in kvm 2021-01-09 16:33:48 HRio: noticing the same 2021-01-09 16:34:17 mount /dev/loop0 on /.modloop failed: invalid argument 2021-01-09 16:34:46 yes see that as well 2021-01-09 16:40:37 could it be something caused by this change perhaps? https://gitlab.alpinelinux.org/alpine/aports/-/commit/83f9f23d95c58c6c956d33b1141c971b4922a712 2021-01-09 16:41:11 not sure if that is used when packing iso 2021-01-09 16:41:21 no 2021-01-09 16:41:45 bootstrap should not be used for that 2021-01-09 16:41:54 k 2021-01-09 16:45:11 the files on the iso are the same 2021-01-09 16:47:27 seems same on the standard iso 2021-01-09 16:48:21 yes, I'm using standard 2021-01-09 16:48:31 The issue is that it cannot mount modloop for some reason 2021-01-09 16:54:19 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/commit/30e6933e71fc18ff5bcb5a7d9dad105e464272bf seems to have been merged yesterday 2021-01-09 16:55:21 ncopa did have some issues with the modloop 2021-01-09 16:55:24 https://gitlab.alpinelinux.org/alpine/aports/-/commit/da0e91f15ec8b8babbd76ae3205bfdac9765a188 2021-01-09 17:05:38 HRio: unsquashfs has no issues reading the modloop file 2021-01-09 17:06:01 check dmesg 2021-01-09 17:06:51 yes, was thinking about that 2021-01-09 17:07:22 no output 2021-01-09 17:07:39 /proc/filesystems lists squashfs 2021-01-09 17:08:18 ah, ncopa merged the old version... 2021-01-09 17:08:29 or did I push the old version 2021-01-09 17:08:48 nah, I pushed the old version :( 2021-01-09 17:08:53 oof 2021-01-09 17:09:02 of alpine-conf? 2021-01-09 17:09:06 -nopad makes it impossible to mount 2021-01-09 17:09:12 ouch 2021-01-09 17:10:48 I fixed it but then accidentally re-added it when fixing ncopa comments 2021-01-09 17:11:19 HRio: would you mind opening an issue for this? 2021-01-09 17:13:39 https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/13 2021-01-09 17:13:53 big oof, sorry all 2021-01-09 17:14:07 #12285 2021-01-09 17:14:15 HRio: thanks 2021-01-09 17:16:29 it's not just standard and extended, it should be broken on all isos on all archs -.- 2021-01-09 17:17:19 real big oof 2021-01-09 17:19:39 at least with tar you can easily work around it though, just pad the sfs end out to 4k 2021-01-09 17:23:33 s=$(stat -c %s modloop); truncate -s $((s+4096-s%4096)) modloop 2021-01-09 20:29:19 What reason we have to keep security issues private ? 2021-01-09 20:30:27 maxice8: heh, was wondering the same 2021-01-09 20:30:31 Well, I know the reason 2021-01-09 20:30:44 maxice8: this is regarding the dovecot issue, right? 2021-01-09 20:30:47 yes 2021-01-09 20:31:33 The official reason is that it doens't become a repository of unpatched issues in Alpine 2021-01-09 20:31:33 to be members of 'security theater' 2021-01-09 20:32:15 But I was wondering if we should reconsider this 2021-01-09 20:32:42 not if we get sec info in advance 2021-01-09 20:32:59 sure, but that's not the case for most of the issues 2021-01-09 20:33:17 true 2021-01-09 20:33:32 I don't remember us receiving any embargoed vulnerabilities in advance 2021-01-09 20:33:34 and dovecot is already known 2021-01-09 20:33:56 We're not on the list, so to speak 2021-01-09 20:34:32 well, I don't have idea what is proper action for these things 2021-01-09 20:35:00 Archlinux has public issues for public vulnerabilities 2021-01-09 20:35:52 personally I'm for 'openness', when we know something don't hide it 2021-01-09 20:37:36 but if open everything we know we could be 'attacked' in press/media as irresponsible 'team' 2021-01-09 20:37:40 I think it's still a good idea to have it hidden 2021-01-09 20:38:16 So users can't search for tag:security in issues and see every sec issue 2021-01-09 20:38:56 Cogitri: users are not problem, dark side/net usually knows these in advance 2021-01-09 20:39:04 can't they already search for cves 2021-01-09 20:39:08 yes 2021-01-09 20:39:09 or other distros issues 2021-01-09 20:39:13 there is software that does all that 2021-01-09 20:39:20 Yes, but we don't have to make it easier than it has to be 2021-01-09 20:40:25 If we do or job good, the list of unpatched vulns should be small 2021-01-09 20:42:01 Yes, but tbh we don't do a too great job for the oldest and second oldest stable releases usually 2021-01-09 20:42:09 because it's so much effort to port things back 2021-01-09 20:42:25 And testing stuff is annoying too when backporting isn't trivial :3 2021-01-09 21:57:39 Ariadne, ncopa, dalias: is there any reason not to use -fno-plt, considering we are already using -z now? 2021-01-09 22:18:16 not afaik 2021-01-09 22:26:16 uh, i mean default-pie and default -z now 2021-01-09 23:19:20 also, how is the decision made to put things in *FLAGS vs builtin specs 2021-01-10 04:32:17 Hello71: basically anything that does not get in the way of people using alpine's toolchain for their personal use goes into specs, otherwise into CFLAGS etc on builder. 2021-01-10 08:23:37 good morning and happy new year folks 2021-01-10 08:24:02 someone got time to check !15294? 2021-01-10 08:25:03 bratkartoffel: can that perhaps wait until after the 3.13 release? 2021-01-10 08:25:44 ah yes, forgot about the announcement. sure 2021-01-10 08:25:50 bratkartoffel: happy new year 2021-01-10 11:12:55 Hello71: I'm thinking about moving the docker time_t issues to a dedicated wiki page and then link to there in the release notes 2021-01-10 12:46:11 rust is used as pretext for https://xkcd.com/303/ 2021-01-10 12:46:11 https://xkcd.com/303 | Compiling | Alt-text: 'Are you stealing those LCDs?' 'Yeah, but I'm doing it while my code compiles.' 2021-01-10 12:47:02 :) 2021-01-10 12:49:15 Rust compile times aren't great (mainly linking) but C++ with loads of STL can be equally bad (currently working on that at work, it's so annoying when a full rebuild needs like a full hour on an 8 core...) 2021-01-10 12:50:56 this is understandable, rust is made to replace c++, compiling speed is achieved :) 2021-01-10 12:53:42 lol 2021-01-10 12:53:49 Heh 2021-01-10 13:08:45 ikke: yes, I was thinking about it too 2021-01-10 13:09:00 but then I was thinking that wiki is not goos 2021-01-10 13:09:12 d 2021-01-10 13:14:32 anyone knows is lxcfs used for anything now 2021-01-10 13:35:26 Hello71: We need to make it good :-) 2021-01-10 13:36:35 Hello71: need to fight the broken window syndrome 2021-01-10 14:17:50 ikke: where to start with making it "good" 2021-01-10 14:18:21 exception: somewhere, anywhere 2021-01-10 14:19:29 So there is a wiki and the (newer) handbook. Are they supposed to co-exist? 2021-01-10 14:19:37 yes 2021-01-10 14:20:04 I see 2021-01-10 14:21:15 no! :) 2021-01-10 14:21:39 wiki should go to /dev/null or gitlab.a.o 2021-01-10 14:42:59 mps: we have docs.a.o 2021-01-10 14:43:47 yes, we have it but I'm talking about wiki 2021-01-10 14:44:34 would be nice if u can just commit to the wiki with git 2021-01-10 14:45:09 exception: we have docs repo 2021-01-10 14:45:19 but what is supposed to go where 2021-01-10 14:45:24 and #alpine-docs channel 2021-01-10 14:45:37 I will just ask it there then, ty 2021-01-10 14:45:50 docs should be official documentation 2021-01-10 14:46:28 and wiki (ofc on gitlab.a.o) random wiki pages 2021-01-10 14:49:00 problem with the wiki on gitlab is that you don't really have merge commits 2021-01-10 14:49:08 merge requests* 2021-01-10 14:49:31 So only members of the project can push to the wiki repo, and without any review 2021-01-10 16:27:22 ncopa I noticed the Vbox kernel modules have been missing since 3.09. Is that intentional? 2021-01-10 16:27:23 The userspace components are still acive in the current 3.13 repo. 2021-01-10 16:31:30 Got another case of CI only failing because of too big artifacts πŸ˜› !16569 is ready for merging 2021-01-10 16:34:01 ACTION carefully examines CI logs 2021-01-10 16:34:02 :D 2021-01-10 16:34:36 lol 2021-01-10 16:35:29 jammers: what modules? and what is 3.09 2021-01-10 16:36:31 Haha 2021-01-10 16:38:53 Hello71: the only reference I could find about the missing modules is here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/8630 There was no reply there, and now it seams all virtualbox-guest-modules are missing currently. 2021-01-10 16:40:11 3.12 still has virtualbox-guest-modules-* https://pkgs.alpinelinux.org/packages?name=virtualbox*&branch=v3.12 2021-01-10 16:40:25 edge doesn't have it because of https://git.alpinelinux.org/aports/commit/community/virtualbox-guest-modules-lts?id=fe84974d3e260868d5475b26ba02436b97d42e5f 2021-01-10 16:40:49 The kernel now has guest-module built-in 2021-01-10 16:41:11 and looking at https://pkgs.alpinelinux.org/contents?file=vbox*&path=&name=linux-virt&branch=edge it can be seen that linux-virt has vboxsf and vboxvideo 2021-01-10 16:41:15 and vboxguest 2021-01-10 17:02:50 I'll update my repo entries and try again in 3.12, maybe something was wrong there. 2021-01-10 17:02:51 I was headed down the Vbox path as an alternative for chroot testing some armv71 building on X86.-64 2021-01-10 17:02:53 Wanted to use qenu-arm in the arm chroot, but its not fully static, (still dynamically linked to musl), so it fails in the arm chroot. 2021-01-10 17:02:54 ldd shows: qemu-arm: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, stripped /lib/ld-musl-x86_64.so.1 (0x7fadd5749000) 2021-01-10 19:05:57 Hey. I just cut a new release of all my packages, and fyi, !16685 is the MR that bumps all the related apks for Alpine. :) 2021-01-10 19:11:01 I don't like idea to run random software from internet on my computers :) 2021-01-10 19:11:20 ? 2021-01-10 19:11:36 jk with skarnet 2021-01-10 19:12:35 I hope you tell the same joke to every upstream you have 2021-01-10 19:13:25 no, just those who told they don't want to run 'random script from Inet' few days ago :P 2021-01-10 19:13:47 ah yes, the great petty saltiness 2021-01-10 19:14:14 np, as wrote just kidding. your software is ok 2021-01-10 19:23:34 https://github.com/Rust-GCC/gccrs 2021-01-10 19:23:41 gcc front-end for rust 2021-01-10 19:44:04 Ariadne: what do you reckon about the risks of -fno-plt then? 2021-01-10 20:19:08 Looks few builders stuck on building stunnel 2021-01-10 20:19:51 :/ 2021-01-10 20:24:45 weird\ 2021-01-10 20:25:05 I straced an orphaned process which seems to have segfaulted, and afterwards everything seems to continue 2021-01-10 20:44:31 Now it passed, thanks! Please check ruby build on 3.12 if possible 2021-01-10 20:54:00 seems to be deadlocked :-/ 2021-01-10 20:54:15 https://bugs.ruby-lang.org/issues/17189 2021-01-10 20:54:19 I guess that 2021-01-10 20:54:54 although, 3.12 is still musl 1.2 2021-01-10 20:54:59 although, 3.12 is still musl 1.1.24 2021-01-10 21:29:51 with latest firefox (also -esr) i cannot open https pages, if i do, wireshark shows me that firefox sends a tls alert: bad certificate - is this known, or anyone an idea what could go wrong here? 2021-01-10 21:30:00 http pages work though. 2021-01-10 21:30:34 yZ5vlALg86lP: haven't heard about this yet 2021-01-10 21:30:58 84.0.2-r0 2021-01-10 21:36:48 somebody with main write permissions please accept !16700 2021-01-10 21:36:58 thanks 2021-01-10 21:53:44 don't merge it before !16685 though, else you'll have to rebuild it again 2021-01-10 21:59:54 skarnet: it was merged after ;) 2021-01-10 22:44:08 Anyone with avahi-ui experience ? !16694 2021-01-10 23:48:39 <[[sroracle]]> regarding libseccomp problems, this might also be an issue https://github.com/seccomp/libseccomp/pull/306 2021-01-11 02:58:14 gcc-10.2.1_pre1-r2 depends on: 2021-01-11 02:58:14 binutils 2021-01-11 02:58:14 libgomp=10.2.1_pre1-r2 2021-01-11 02:58:14 libatomic=10.2.1_pre1-r2 2021-01-11 02:58:16 hmm 2021-01-11 02:58:26 depends are being polluted from subpackages it seems 2021-01-11 03:10:02 dunno, this is some ncopa-level shit 2021-01-11 03:32:14 looks right to me? 2021-01-11 03:32:30 notwithstanding the questionable nature of gcc depending on binutils to start with 2021-01-11 04:10:31 the libgphobos is not right 2021-01-11 04:10:56 only gdc should depend on that. 2021-01-11 06:17:30 Is the size of /dev/shm fixed? I got a test suite here that puts its runtime files into /dev/shm and the suite fails during runtime because /dev/shm is full 2021-01-11 06:17:57 Seems like the test suite needs at least 253.6 MiB of space in /dev/shm 2021-01-11 06:18:27 The default is 64M 2021-01-11 06:18:55 My box has 32GiB of memory, so seems like it's fixed. 2021-01-11 07:54:23 ncopa: mps thoughts? 2021-01-11 08:08:25 ncopa, re osinfo-db: - the script should be integrated in docker-alpine? 2021-01-11 08:08:25 - the script should create a MR to libosinfo? 2021-01-11 08:11:12 morning 2021-01-11 08:11:26 morning 2021-01-11 08:11:33 _0/ 2021-01-11 08:11:48 ncopa: rc3 is broken in case you missed it 2021-01-11 08:12:08 fcolista: no, we should not integrate osinfo-db in docker alpine 2021-01-11 08:12:12 ikke: oh how so? 2021-01-11 08:12:25 ok so is a standalone script 2021-01-11 08:12:28 ncopa: Hello71 accidentally sent the wrong ersion of a patch 2021-01-11 08:12:38 -nopad breaks the modloop (cannot be mounted) 2021-01-11 08:13:11 hum.. i thought i tested that 2021-01-11 08:13:20 lets revert it 2021-01-11 08:13:36 ncopa: Hello71 sent an MR 2021-01-11 08:13:57 ncopa: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/13 2021-01-11 08:14:48 so we need an rc4... 2021-01-11 08:14:57 is rc3 completely broken on all arches? 2021-01-11 08:15:33 I haven't tested other arches 2021-01-11 08:15:41 but at least x86_64 2021-01-11 08:16:07 you already see it when you want to boot from the iso 2021-01-11 08:16:58 known meme: don't make releases on friday :) 2021-01-11 08:17:57 Thermi: what about? my inet link is unstable in last days so I don't see context 2021-01-11 08:18:44 Thermi: about /dev/shm ? 2021-01-11 08:18:49 mps: yes 2021-01-11 08:19:49 what pkg use /dev/shm as storage? that package is 'bad', to not use more harsh words 2021-01-11 08:19:51 thats embarrasing 2021-01-11 08:20:28 mps: Well, I'm putting it together right now 2021-01-11 08:20:36 mps: it's the test suite of libmdbx that does that 2021-01-11 08:20:51 I could just sed all the paths, TBH. Is /tmp better? 2021-01-11 08:21:16 sure, /tmp is intended for such things 2021-01-11 08:21:30 mps: what is /dev/shm intended for? 2021-01-11 08:22:03 ikke: mostly for IPC 2021-01-11 08:22:31 aha 2021-01-11 08:23:19 unix from beginning have /tmp for files 2021-01-11 08:24:46 and idea with /dev/shm is/was for small files used for interproccess communication 2021-01-11 08:25:35 The reason I guess people want to use /dev/shm is because not until fairly recent, /tmp was just a directory, rather than tmpfs, so IO was slow 2021-01-11 08:26:17 also, this is my 'impression' 2021-01-11 08:56:30 there's something weird with gcc dependency, libgphobos winds up being a dependency of gcc even though it is only a dependency of gdc 2021-01-11 09:17:41 mps ncopa ikke ariadne kindly take a quick look at the APKBUILD and please tell me if there any obvious no-nos. :) 2021-01-11 09:18:02 The massive patch file adds the test suite for build time checking 2021-01-11 09:18:55 Immediately found an issue. 2021-01-11 09:18:56 %) 2021-01-11 09:20:20 fiiiixxxxxeeeddd 2021-01-11 09:23:11 oh ffs 2021-01-11 09:29:21 would someone want to work with me on this? https://gitlab.alpinelinux.org/alpine/aports/-/issues/12176 2021-01-11 09:30:02 workarounds should be mentioned in 3.13 release notes unless there is a fix 2021-01-11 10:46:58 whats up with gcc? 2021-01-11 10:47:57 ncopa: From what I read is that the dependency from gcc on libgphobos is unexpected 2021-01-11 10:49:22 ncopa: https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/minicom/minicom-2.8-r0.log 2021-01-11 10:51:09 seems like armhf and armv7 still clobber eachother 2021-01-11 10:51:32 looks like that yes 2021-01-11 10:51:37 i think i need to fix gcc first 2021-01-11 10:51:40 sure 2021-01-11 10:51:47 just wanted to point it out 2021-01-11 10:51:54 armv7 says it found a partial download 2021-01-11 10:52:27 did libucontext ABI change? 2021-01-11 10:56:06 yes it did 2021-01-11 10:56:19 $ apk info --provides libucontext 2021-01-11 10:56:19 libucontext-0.13.1-r0 provides: 2021-01-11 10:56:19 libucontext-1.0-r0 provides: 2021-01-11 10:56:19 so:libucontext.so.1=1 2021-01-11 10:56:19 so:libucontext.so.0=0 2021-01-11 10:56:19 so:libucontext_posix.so.1=1 2021-01-11 10:57:11 if any of the gcc dependencies has a ABI breakage, special handling is needed 2021-01-11 10:59:32 its the same for isl d1f8d455bebf7d8b2f87f2bd75c53b9d0ff76a24 , gmp cb8fc691289c17163bef935c5bdef160c15f9423, mpfr 1a495321f9047492196280b09534c6d1478f2bcd 2021-01-11 11:00:36 so if gcc now also depends on libucontxt, then special care is needed when upgrading ABI breaking changes 2021-01-11 11:01:33 So all gcc dependencies should be explicitly versioned? 2021-01-11 11:01:36 Ariadne: is 9486c3a6cfe02daf4237c42d63b20102ddc41a67 really necessary? 2021-01-11 11:01:38 yes 2021-01-11 11:02:37 it broke ABI for a gcc dependency right after what I hoped to be the last release candidate before a release. what could possibly go wrong? 2021-01-11 11:03:02 im sorry if im a bit grumpy today. my monday could have been better 2021-01-11 11:03:25 Should it be reverted? 2021-01-11 11:04:00 (today i also fell on the ice on my way home to buy gread for breakfast - thin layer of snow on top of the ice so it did not look slippery) 2021-01-11 11:04:47 oof 2021-01-11 11:04:54 thats why im asking if the change was necessay. since it was pushed so close to a release I assume that it contains something important 2021-01-11 11:05:27 i suppose i need to spend time on reading the libuconxt gitlog to find out 2021-01-11 11:06:07 :( 2021-01-11 11:10:13 https://github.com/kaniini/libucontext/blob/master/NEWS#L14 2021-01-11 11:10:43 is the libucontext needed for gcc 2021-01-11 11:10:54 its used by s390x and mips64 2021-01-11 11:11:09 better question will be 'why' 2021-01-11 11:11:22 no clue 2021-01-11 11:11:40 my guess is that D needs it 2021-01-11 11:12:02 ahmm 2021-01-11 11:13:25 :D lang 2021-01-11 11:16:16 ncopa: ariadne wondered why subpackage dependencies leaked to main gcc 2021-01-11 11:16:44 i think it is due to a bug in abuild 2021-01-11 11:17:28 the split function for gdc sets depends which is a global variable 2021-01-11 11:17:47 but hum.. does not really make sense 2021-01-11 11:20:19 ncopa: go to some martial art course where you can learn to fall safely (aikido, judo or similar) 2021-01-11 11:21:26 the abuild bug is bad news 2021-01-11 11:21:39 im pretty sure fixing it will break other stuff 2021-01-11 11:22:02 ncopa: What is the bug? 2021-01-11 11:22:15 It looks like subpackage function are run in a subshell 2021-01-11 11:22:26 setting depends in a split function should not set the global depends 2021-01-11 11:22:29 it looks like it does 2021-01-11 11:22:36 https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L859 2021-01-11 11:23:02 Sounds like something we could confirm in an abuild test 2021-01-11 11:23:22 I think 2021-01-11 11:23:45 good idea. exactly what we should do 2021-01-11 11:52:22 yeah the problem is with gcc dependencies being leaked 2021-01-11 11:52:36 that needs fixed, then we just temporarily disable D on mips64/s390x 2021-01-11 11:53:42 i think i fixed the libucontext by adding libucontext0 with the .so.0 only 2021-01-11 11:54:01 yeah that's fine for now 2021-01-11 11:54:09 im building gcc on x86_64 now to investigate how the depends leaks 2021-01-11 11:54:29 yeah good plan, because ada stuff also leaks through 2021-01-11 11:56:13 (and yes, D falls back to libucontext when there is no native implementation available) 2021-01-11 11:59:58 i am afraid we cannot fix the leaking 2021-01-11 12:00:08 im pretty sure it will break other stuff that depends on it 2021-01-11 12:00:41 Should we fix it at some point? 2021-01-11 12:00:45 yes 2021-01-11 12:01:28 i think first step is to create a testcase in abuild.git/tests 2021-01-11 12:01:36 nod 2021-01-11 12:01:44 with the behavior we want 2021-01-11 12:01:54 then we fix the packages that depends on broken behavior 2021-01-11 12:02:11 i wonder if we should consider reworking APKBUILD format in general 2021-01-11 12:02:33 but thats a longer term conversation for sure 2021-01-11 12:02:35 we shoudl have done that long time ago 2021-01-11 12:02:38 but yes 2021-01-11 12:02:52 Ariadne: what do you have in mind? 2021-01-11 12:02:59 What do you have in mind for a rework? 2021-01-11 12:03:02 lol 2021-01-11 12:03:03 Ah, ikke was faster :D 2021-01-11 12:03:14 i have been thinking of reworking the APKBUILD format for a long time, the problem is that i dont have any good ideas 2021-01-11 12:03:32 and we need to do the change incremental 2021-01-11 12:03:51 with backwards compatibility 2021-01-11 12:04:19 the ability to have something more capable than posix shell scripting would be nice 2021-01-11 12:04:32 yup 2021-01-11 12:04:48 Should be something fairly self-contained though 2021-01-11 12:04:55 So something like flatpak yaml/json? 2021-01-11 12:05:03 meh 2021-01-11 12:05:06 I have a few ideas: first adding a option to disable build-base and second to have a option for depends not be installed at build time 2021-01-11 12:05:20 i'm thinking "makefiles, but with YAML front matter" 2021-01-11 12:05:41 if you have a common "runner" you can support the current format alongside the new one 2021-01-11 12:06:03 yaml is nice for metadata, but not for build instructions 2021-01-11 12:06:04 caskd: The latter should be the default in a new value 2021-01-11 12:06:25 anyway, i think we should prioritize fixing the builders and getting rc4 out 2021-01-11 12:06:31 and 3.13.0 2021-01-11 12:06:35 then we can discuss new format 2021-01-11 12:06:55 YML is OK for building simple builds but it'd probably be hell for chromium :D 2021-01-11 12:07:08 oh yeah 2021-01-11 12:07:26 i do think it would be good if we all can have it in the back of our minds, and if we have good ideas, write them down or prepare a presentation 2021-01-11 12:07:39 Cogitri: hince yaml for data and makefile syntax for the actual steps 2021-01-11 12:07:43 maybe we should have some video call at some point for brainstorming 2021-01-11 12:07:51 i can mock up an example of what i have in mind 2021-01-11 12:07:58 inheritance would also be nice 2021-01-11 12:07:58 that would be perfect 2021-01-11 12:08:06 mockups are good 2021-01-11 12:08:09 Is Makefile syntax an improvement on poxic sh? 2021-01-11 12:08:15 posix* 2021-01-11 12:08:18 ikke: yes, we can do inheritance with it 2021-01-11 12:08:36 alpine 1.8 had makefiles 2021-01-11 12:08:49 package manager syntax is... complicated 2021-01-11 12:09:04 the problem was (is) that its complicated and difficult for people to understand 2021-01-11 12:09:17 difficult to debug 2021-01-11 12:09:34 also, my experience with yaml was netplan, and it was not a good experience 2021-01-11 12:09:47 the "posix" shell syntax is dead simple and transparent about what is happening 2021-01-11 12:09:52 (well, what i really mean is shell fragments) 2021-01-11 12:10:10 shell fragments are good 2021-01-11 12:10:16 oh no, reinvent the world again 2021-01-11 12:10:19 i have been thinking in the direction rpm's .spec format or maybe even bash (ala void) 2021-01-11 12:10:35 mps: as long as the wheel is not round, it's bound to get reinvented on a regular basis 2021-01-11 12:10:45 rpm spec is probably the worst option 2021-01-11 12:11:04 to the pointed of squared wheel 2021-01-11 12:11:20 point* 2021-01-11 12:11:34 rpmbuild is basically a glorified preprocessor that spits out a shell script and runs it 2021-01-11 12:11:45 way back when, it took me a day to get the first .spec working properly. It took 10 minutes to get the first APKBUILD working. 2021-01-11 12:11:47 if in doubt, do the opposite of whatever RPM does ^_^ 2021-01-11 12:12:00 ha 2021-01-11 12:12:32 tbh I find the APKBUILD format pretty comfortable and pleasant to use, if there are drawbacks they're not in the UI, but in the abuild internals 2021-01-11 12:12:34 (having changelogs would be nice as well β™₯ ) 2021-01-11 12:13:06 for me APKBUILD is good 2021-01-11 12:13:08 nix anyone? 2021-01-11 12:13:14 skarnet: the problem is that right now, to extract metadata from the APKBUILDs, you have to source them into a running shell process and then dump the vars 2021-01-11 12:13:15 detha: thank you. I think i needed to hear that today (my monday has been suboptimal so far and I really needed to hear something good) 2021-01-11 12:13:23 insep_: you are kidding with us 2021-01-11 12:13:38 Ariadne: agreed, APKBUILD is good for building, but not for interacting with other tools that need package data 2021-01-11 12:13:49 ncopa: same experience for me: packaging with APKBUILD has been a breeze compared to Debian. 2021-01-11 12:13:53 yes 2021-01-11 12:13:55 detha: that was exactly the goal of the the APKBUILD format 2021-01-11 12:14:09 jvoisin: ok, we can go back to alpine 1.8 :D 2021-01-11 12:14:24 detha: I had same experience from debian build system to apkbuild 2021-01-11 12:14:55 Ariadne: not bad idea :) 2021-01-11 12:15:06 alpine 1.8 was makefiles 2021-01-11 12:15:06 have the vars and the functions be in separate files, and automation that just need the files can read the vars file with something like envfile to avoid a shell? :P 2021-01-11 12:15:08 like debian 2021-01-11 12:15:08 :P 2021-01-11 12:15:19 that just need the var data* 2021-01-11 12:15:23 ncopa: APKBUILD as-is is easy to work with for the 'occasional user'. simple things are simple, complicated things are possible. No idea what 'advanced users' friction points are 2021-01-11 12:15:39 skarnet: my idea was to just have the shell fragments as metadata under `phases` or whatever 2021-01-11 12:15:44 i think the major challenge with the current APKBUILD format is how to set the metadata for subpackages. they need to be parsed in global scope 2021-01-11 12:16:17 so i'd like a way to set things like dependencies and provides and things like that in global scope 2021-01-11 12:16:25 yep 2021-01-11 12:16:30 ncopa: you can do syntactic wonders with eval 2021-01-11 12:16:34 i know 2021-01-11 12:16:37 and by wonders, I mean marvels of ugliness 2021-01-11 12:16:46 but i dont really dont want go that route... 2021-01-11 12:16:50 eval is evil :) 2021-01-11 12:16:56 skarnet: i think we should avoid lowering the bus factor of abuild to 1 person 2021-01-11 12:16:58 :P 2021-01-11 12:17:08 you mean it's greater than 1 right now? :P 2021-01-11 12:17:13 yes 2021-01-11 12:17:15 mostly 2021-01-11 12:17:37 but add eval stuff and only the person who wrote that stuff will ever truly know what it was meant to do :) 2021-01-11 12:18:09 or - hear me out - the thing could, maybe, perhaps... be documented? 2021-01-11 12:18:22 docuwhat 2021-01-11 12:18:26 *insert meme with skarnet being thrown out the window* 2021-01-11 12:18:34 :D 2021-01-11 12:18:36 that sounds like fancy google shit 2021-01-11 12:18:58 any idea what's wrong with libucontext on s390x https://gitlab.alpinelinux.org/andypost/aports/-/jobs/290954 2021-01-11 12:19:25 we fixed it already 2021-01-11 12:19:26 andypost[m]: yeah. fix is in the oven 2021-01-11 12:19:33 well 'fixed' 2021-01-11 12:19:34 07b24a1af666200053ac6be89579ce6a4e579350 2021-01-11 12:19:59 the real problem is abuild dependency pollution 2021-01-11 12:20:09 causing deps to trickle where they shouldn't be 2021-01-11 12:20:25 how does that happen? 2021-01-11 12:20:27 depending on how you see things, the fundamental underlying problem was the abi breakage in libucontext 2021-01-11 12:20:37 or in the dependency pollution 2021-01-11 12:21:01 i dunno how the depds polution happened. the abuild script run the split function in a subshell 2021-01-11 12:21:09 well, the soname bump was unfortunate indeed 2021-01-11 12:21:10 so something does not works as expected 2021-01-11 12:21:24 thank you, threading is fragile everytime 2021-01-11 12:21:27 yes, i expected it to not be needing special handling due to it only being gdc 2021-01-11 12:21:44 and then i found out libgphobos is a dep on gcc itself 2021-01-11 12:21:50 needless to say, that was surprising 2021-01-11 12:21:52 imho, the abi breakage was the problem, depends leak in gcc package separate issue 2021-01-11 12:22:27 in fairness when libucontext was packaged, i was not expecting it to become a dependency of gcc :P 2021-01-11 12:22:41 understandable. i dont blame anyone 2021-01-11 12:22:42 otherwise i would have packaged as libucontext0 to begin with 2021-01-11 12:23:07 this one of those things to keep in mind when messing with gcc 2021-01-11 12:23:13 ah yes, package managers that cannot handle several versions of the same package 2021-01-11 12:23:31 yup. its a design thing 2021-01-11 12:23:37 and that need naming shenanigans, thus delegating management to maintainers 2021-01-11 12:23:42 we intentionally imlemented it like that 2021-01-11 12:24:02 I honestly can't fathom why 2021-01-11 12:24:26 mostly because that's the behavior of other managers (primarily apt) that we wanted to model 2021-01-11 12:24:32 more than a decade ago. when things were truly small and simple 2021-01-11 12:24:44 sigh 2021-01-11 12:24:59 we were ofc aware of the problem it caused, but had workarounds (rename package) 2021-01-11 12:25:18 fwiw that might get revisited for apk3 2021-01-11 12:25:19 and believe me, the package manager is complicated enough as it is 2021-01-11 12:25:31 im not sure its worth it 2021-01-11 12:25:49 it creates a new set of problems 2021-01-11 12:25:55 it is true that tracking multiple packages for a given apk_name is a problem 2021-01-11 12:26:02 to support several versions of the same package being installed on the same machine you'd need to have a not-fhs layout anyway 2021-01-11 12:26:11 and you're not ready for that :P 2021-01-11 12:26:49 well, in reality, i think too much stuff is distributed using apk that should be distributed using flatpak instead 2021-01-11 12:27:23 apk (and other package managers like it) were built to maintain system images 2021-01-11 12:27:26 people like apk because it's fast 2021-01-11 12:27:38 end-user applications should be containerized imo 2021-01-11 12:29:57 The problem is how to make sure dependencies are kept up-to-date 2021-01-11 12:31:07 At least now, there is some pressure make sure things work together 2021-01-11 12:31:29 yeah 2021-01-11 12:32:41 anyone want to help make atest case for the leaking deps? abuild git repo abuild/tests 2021-01-11 12:33:49 ncopa: I'm interested, but it would be tonight 2021-01-11 12:34:19 ok. thanks 2021-01-11 12:34:45 i think i'm gonna be busy with the modloop issue and kernel upgrade anyways 2021-01-11 12:34:48 will try get rc4 out today 2021-01-11 12:35:01 Just wondering how we would verify this 2021-01-11 12:35:10 Just build a package and verify dependencies? 2021-01-11 12:35:14 yeah 2021-01-11 12:35:16 ok 2021-01-11 12:35:51 build package and verify that the dependencies are the way they should 2021-01-11 12:37:29 oh, btw, another anoyance, ruby is hanging on 3.12 2021-01-11 12:38:17 https://bugs.ruby-lang.org/issues/17189 mentions musl-1.2.1, but that is musl-1.1.24 2021-01-11 13:23:24 all done peeps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16709 2021-01-11 13:29:40 checking backlog... ncopa: rc3 should be broken on all archs except if modloop happens to be exactly a multiple of 4096 bytes. it's a really big oof from me there, sorry 2021-01-11 13:32:07 Hello71: yeah. i must admit I was not very happy this morning, felt it was my fault that rc3 broke. But no worries, it happens. I merged the fix and have tested it. will try push rc4 today. 2021-01-11 13:33:23 my 2c regarding makefiles... anybody spending enough time with buildroot (or !@#$ing openjdk) knows that debugging complex makefiles sucks. gnu make does not provide adequate tools for debugging macro expansions 2021-01-11 13:36:28 nightmare scenario for alpine: https://bugs.openjdk.java.net/browse/JDK-8255732. imagine actually thinking https://github.com/openjdk/jdk/commit/184db64d is reasonable 2021-01-11 13:37:39 Hello71: What is nightmarish about that? 2021-01-11 13:37:59 i mean if alpine packages were implemented in this language 2021-01-11 13:38:22 its a nightmare to try understand how it actually works, and debug things when they dont work 2021-01-11 13:38:36 Hello71: Ah, missed your first message 2021-01-11 13:38:53 and its a nightmare to review patches from people not understaning how things works 2021-01-11 13:43:45 i think it could be possible if make were improved to provide better macro expansion debugging, but honestly i'm pretty sure it would still be worse than shell 2021-01-11 13:44:26 if you wanted to go in the direction of make-style orchestration, a ninja generator might make sense 2021-01-11 13:44:49 Ariadne: what about nix? 2021-01-11 13:45:25 ncopa: btw, I cleaned up the 3.13.0 milestone 2021-01-11 13:45:30 imo the concept of nix is good, but ime the current implementation is far too heavy. OOMs for me just installing base system on 512 MB RAM 2021-01-11 13:45:35 awesome! thanks! 2021-01-11 13:45:35 there are a few items left 2021-01-11 13:46:09 We should keep the milestones clean to things we actually intend to fix in that milestone 2021-01-11 13:46:19 There are lots of issues which just get bumped from milestone to milestone 2021-01-11 13:48:53 imo if you want nix, you should go run nix 2021-01-11 13:50:12 well the problem as i said is that the current nix implementation is too heavy 2021-01-11 13:51:48 in case it's not clear, i'm not suggesting alpine use nix. just wondering what you think about nix philosophy 2021-01-11 13:55:31 software and philosophy :D 2021-01-11 13:56:06 foolosophy 2021-01-11 13:56:23 Hello71: I don't intend to insult you 2021-01-11 13:57:17 this was just 'shlagwort' for me 2021-01-11 13:57:27 schlagwort* 2021-01-11 13:57:51 Hello71: i mean, alpine has iterated on emdebian, then replaced all of the emdebian stuff with ebuilds, and then with APKBUILDs 2021-01-11 13:58:13 mmhmm 2021-01-11 13:58:28 if you're looking for alpine to become nix-like, i don't see it happening 2021-01-11 13:58:39 no 2021-01-11 13:58:43 we seem to be solidly in the "debian, but not built on 1990s technology" lane 2021-01-11 13:59:27 yes, bourne shell is from 1970s :p 2021-01-11 14:00:13 regarding nix itself: i think the ability to have a description of a desired system state including configuration is neat 2021-01-11 14:00:27 unfortunately, that comes at a high price 2021-01-11 14:01:02 in nix, you don't just go and build stuff, you have to do it the nix way 2021-01-11 14:01:27 which is cool 2021-01-11 14:03:16 I have two problems with nix: 1. mechanism and policy are intimately intertwined and you can't abstract it. 2. the nix management itself is super heavy. 2021-01-11 14:03:24 Apart from that, it's a good system. 2021-01-11 14:04:09 last time I tried it the docs were also severely lacking, although maybe that's gotten better since then 2021-01-11 14:31:21 ncopa: I assume you killed ruby on 3.12-x86? 2021-01-11 14:35:51 ikke: i did 2021-01-11 14:35:54 and restarted it 2021-01-11 14:36:56 ok 2021-01-11 15:13:48 mps: existing rng-tools maintainer agreed for me to take over. Will now tweak !16605 to reflect this. 2021-01-11 15:22:45 i think we have a problem with ruby on 3.12-stable. i suspect its the malloc-after-fork problem 2021-01-11 15:23:47 minimal: good news 2021-01-11 15:24:25 (except I broke important key on my workstation keyboard) 2021-01-11 15:26:51 mps: I was considering removing rtlsdr support (which would remove librtlsdr and libusb deps) as expected to package rtl-entropy as an alternative - however just noticed rtl-entropy author abandoned that a month ago :-( Wondering whether in future its worth creating an additional rng-tools subpackage with more sources enabled in it 2021-01-11 15:27:55 so rng-tools package would remain small and rng-tools-kitchensink would have everything in it ;-) 2021-01-11 15:28:12 minimal: I'm ok with this 2021-01-11 15:31:20 mps: cool. suggestions for naming the kitchensink sub-package? rng-tools-complete? rng-tools-extra? 2021-01-11 15:31:40 -extra 2021-01-11 15:34:08 jvoisin: my thoughts as well, will go with that 2021-01-11 15:35:41 or -bloat if you want to be passive-aggressive :P 2021-01-11 15:35:50 -huge 2021-01-11 15:37:39 kitchensink looks good 2021-01-11 15:39:35 minimal: whatever you name it I'm ok, now that you are maintainer I don't have to 'keep eye' on it :) 2021-01-11 15:40:57 have to look at some other 'fine' pkgs :] 2021-01-11 15:41:52 ncopa: new seabios -128K is bigger that 128KB in new release 2021-01-11 15:42:14 about 135KB 2021-01-11 15:42:31 mps: Finally got a reply from another package maintainer, so another one I'm taking over - like Pokemon, gotta catch them all :-) 2021-01-11 15:45:15 'can be only one' 2021-01-11 15:54:19 fwiw 2021-01-11 15:55:00 if they do not respond, you can make your case in the MR why you should take over the package(s) 2021-01-11 15:55:13 if somebody agrees, it will be merged :P 2021-01-11 15:56:20 Ariadne: yeah, I guess I prefer talking directly to an existing maintainer first (if possible) to sound them out 2021-01-11 15:56:36 I have been thinking of dealing with maintainers 2021-01-11 16:01:19 oh no 2021-01-11 16:01:44 I mean contacting ones that we have reason to believe are inactive 2021-01-11 16:01:54 i'm going to wake up after 3.13 is released 2021-01-11 16:02:00 and every APKBUILD i open 2021-01-11 16:02:02 it's going to be 2021-01-11 16:02:06 and removing maintainership from the ones that do not get back in contact in $PERIOD_OF_TIME 2021-01-11 16:02:07 # Maintainer: Leo <...> 2021-01-11 16:02:22 I don't even want to maintain my own packages 2021-01-11 16:02:53 honestly mood 2021-01-11 16:03:31 Don't worry it is just a contact and ask if people are still intersted and update maintainership state 2021-01-11 16:07:11 If you want maxice8 to maintain a package, just amke sure it's flagged as outdated on repology :P 2021-01-11 16:08:52 i wonder what to do with the 3.12-stable and ruby. we also have issues there with libvirt and malloc after fork 2021-01-11 16:10:17 dalias: we have musl 1.1.24 in alpine 3.12-stable, and are bumping into malloc after fork issues. I wonder if it would be an idea to backport the fixes from musl-1.2.x? 2021-01-11 16:12:59 ncopa: did the mt-fork patch fix the test suite in ruby for 1.2? 2021-01-11 16:13:18 i think it did 2021-01-11 16:13:33 oh 2021-01-11 16:13:42 i havent renabled the tests 2021-01-11 16:16:41 in any case, the test_thread.rb deadlocks with musl 1.1.24 (alpine 3.12-stable) 2021-01-11 16:17:51 yeah, would be a good indicator whether the mt-fork patch fixes it 2021-01-11 16:17:59 ncopa: those changes depend on a lot of stuff. i think it would be basically equivalent to upgrading musl in 3.12 2021-01-11 16:18:16 or maybe even higher risk 2021-01-11 16:19:19 probably the best solution would be to eol 3.12, but i think it might be a little too early :p 2021-01-11 16:20:10 Rolling Release Alpine 😎 2021-01-11 16:20:26 edge is the rolling variant 2021-01-11 16:20:30 ^ emoji with sunglasses for the deficient of emojis 2021-01-11 16:20:52 :) 2021-01-11 16:21:07 πŸ‘ 2021-01-11 16:21:09 the ruby tests passes on x86_64 2021-01-11 16:21:37 if patching ruby is a pain, what if we just don't update it in 3.12 2021-01-11 16:21:57 same with libvirt 2021-01-11 16:22:06 it's not just about updating 2021-01-11 16:22:18 I can imagine this leading to bugs / hangs for end-users too 2021-01-11 16:22:35 we have open bugs for libvirt already 2021-01-11 16:22:42 We notice it with gitlab too 2021-01-11 16:22:49 gitaly-ssh 2021-01-11 16:22:58 does gitaly-ssh work with current edge? 2021-01-11 16:23:04 haven't tested it yet 2021-01-11 16:23:11 hard to test 2021-01-11 16:23:22 tell them to use 3.13. prerequisite: get 3.13 out 2021-01-11 16:23:36 ikke: try install musl from edge 2021-01-11 16:24:06 Hello71: we still need to maintain 3.12, add security fixes there etc 2021-01-11 16:24:33 idk, is it more work to fix the malloc after fork or to pull a debian 2021-01-11 16:25:02 currently 20 gitaly-ssh processes (hanging?) 2021-01-11 16:25:31 so, my thinking is that maybe we could backport the malloc stuff ffor maul 1.1.24 2021-01-11 16:25:46 s/maul/musl/ 2021-01-11 16:25:47 ncopa meant to say: so, my thinking is that maybe we could backport the malloc stuff ffor musl 1.1.24 2021-01-11 16:26:36 but i'd like to hear dalias opinion on what options we have 2021-01-11 16:27:59 ncopa: Should I restart gitlab after upgrading musl? Wondering whether there could be issues with running processes using the old version 2021-01-11 16:28:34 does anyone just happen to have pre-1.9 copy aports? 2021-01-11 16:28:46 would like to see how those makefiles looked lik 2021-01-11 16:28:47 e 2021-01-11 16:31:43 I guess that was in svn? 2021-01-11 16:35:03 cannot find anything 2021-01-11 16:40:20 it was in svn yes 2021-01-11 16:40:30 We imported svn iirc 2021-01-11 16:40:31 i dont htink i have the svn history anywhere 2021-01-11 16:42:43 might be i have it on a cdrom somewhere 2021-01-11 16:43:25 insep_: also, back thn we built alpine packages using gentoo's ebuild 2021-01-11 18:05:09 ncopa, hm? 2021-01-11 18:07:09 hi dalias! hope you are doing good :) 2021-01-11 18:07:23 there is definitely not any trivial backport, and i'm not sure why a backport involving significant subtle interactions would be expected to be less invasive/more stable than just upgrading musl 2021-01-11 18:08:15 ok. so there is no easy way to backport the fixes for malloc-after-fork? 2021-01-11 18:08:40 i suppose thats what i expected, but i just wanted to confirm 2021-01-11 18:14:28 i don't think it's easy. at least there are a fair number of other changes/fixes it depends on 2021-01-11 18:14:39 if i were trying to bring this into an old stable dist.. 2021-01-11 18:14:56 3.12 is not old :P 2021-01-11 18:15:29 i would build musl 1.2.2 --with-malloc=oldmalloc (assuming you want to avoid changes there) and ship the headers from 1.1.24 as the dev package still 2021-01-11 18:15:42 :-P 2021-01-11 18:16:12 as this isn't a bugfix but a change that improves compat with buggy software, and a somewhat spread-out change 2021-01-11 18:16:26 if you want you could try making a list of related changes for backport and see if it looks plausible 2021-01-11 18:16:58 but i think i'd be more worried about breakage from botching that than about breakage from upgrading to latest 2021-01-11 18:17:14 I don't think we can 2021-01-11 18:17:20 it would break all 32-bits arches 2021-01-11 18:18:24 no, that's why i said shipping the 1.1.24 headers as dev package 2021-01-11 18:18:48 there is no abi breakage in existing abi going from 1.1.x to 1.2.x 2021-01-11 18:19:01 ah ok 2021-01-11 18:19:26 but is this really getting hit in real world now? 2021-01-11 18:19:45 libvirt, ruby 2021-01-11 18:19:47 if not, and it's just the ruby testsuite doing bogus stuff, i'd just leave it alone unless someone complains (and disable the test) 2021-01-11 18:20:00 dalias: I'm not certain, but we seem to be hitting it in gitlab 2021-01-11 18:20:21 gitaly-ssh processes getting stuck for FUTEX_WAIT 2021-01-11 18:20:40 I've upgraded musl in the gitlab container to see if that solves it 2021-01-11 18:23:04 I guess this is the libvirt issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12007 2021-01-11 19:08:18 Rough list of all maintainers that had were not authors or committers for 60 days: http://ix.io/2LGf 2021-01-11 19:08:26 bound to have fun false positives like fcolista's gmail 2021-01-11 19:09:17 yay, I'm in there 2021-01-11 19:09:40 with 2 different e-mail addresses no less 2021-01-11 19:10:11 Congrats 2021-01-11 19:19:18 a better list might be "all maintainers that made at least one commit *ever* that didn't make any commit in the last 60 days" 2021-01-11 19:19:25 as a first pass 2021-01-11 19:29:20 Don't think it will change all that much 2021-01-11 19:29:36 I now have to remove false positives then look at the packages of each remaining maintainer and contact them 2021-01-11 19:42:46 also i'm listed with one character in real name :) 2021-01-11 19:43:13 wrong character* 2021-01-11 19:43:42 Extracted from Maintainer: field of APKBUILDs 2021-01-11 19:43:58 huh, lets fix it 2021-01-11 20:28:32 does this looks ok for merge !16718 2021-01-11 20:28:44 it was already merged 2021-01-11 20:28:58 ikke: this one is for 3.12 2021-01-11 20:29:01 aha 2021-01-11 20:29:47 I still feel fear of merging on previous releases 2021-01-11 20:30:19 looks ok 2021-01-11 20:30:23 it's an upstream patch 2021-01-11 20:30:38 yes 2021-01-11 20:30:58 just talked with upstream on #irssi 2021-01-11 21:25:00 heh, I'm not in the list because I did a tiny change :P 2021-01-11 21:49:14 I need help writing nice emails 2021-01-11 22:04:39 "Dear sir/madam," 2021-01-11 22:08:47 I'd like to inform you of a fire 2021-01-11 22:16:52 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12293 :D 2021-01-11 22:21:29 Quite a task 2021-01-11 22:21:40 yes 2021-01-11 22:23:03 My only fear is not replacing the $VARIABLES in the mail template 2021-01-11 22:23:20 heh 2021-01-11 22:26:56 What packages do you have for me btw? 2021-01-11 22:27:39 I was supposed to ? 2021-01-11 22:28:22 no, sorry 2021-01-11 22:28:34 I meant something different 2021-01-11 22:28:42 but I can just check the e-mail addresses 2021-01-11 22:34:48 :D you going to help ? 2021-01-11 22:35:22 It's too late for me, I'm not explaining myself well 2021-01-11 22:35:38 Around 22:35 ? 2021-01-11 22:35:48 I was just cruous what packages I maintained that were flagged 2021-01-11 22:35:51 yes 2021-01-11 22:35:58 no packages were flagged 2021-01-11 22:36:16 mentioned in that list then :P 2021-01-11 22:37:14 I'm not flagging packages, I'm flagging maintainers that didn't author or commit anything in the last 60 days and checking if they have alternate emails (most likely your case), checking if the packages they maintain have other people committing to it or if the packages are outdated 2021-01-11 22:37:50 yes, understood, I was interested what packages that I maintain were not updated by me in the last 60 days 2021-01-11 22:37:55 by me 2021-01-11 22:38:10 not touched, likely one you have an old email 2021-01-11 22:38:38 yes, updating them now 2021-01-11 22:38:42 community/markdown for me@ikke.info 2021-01-11 22:38:57 right, but that package does not have any updates either 2021-01-11 22:39:16 piknik pugixml flickcurl colord-gtk for ops@ikke.info 2021-01-11 22:39:24 right 2021-01-11 22:39:47 last commits to markdown were all metadata fixes 2021-01-11 22:42:23 heh 2021-01-11 22:42:24 got my first reply 2021-01-11 22:42:32 nice 2021-01-11 22:47:02 h1-cli lives! 2021-01-11 22:53:09 and another answered, didn't use for 2-3 years 2021-01-11 22:53:18 [Alpine Linux] being the thing used in this case 2021-01-11 22:55:43 font-api source is awol 2021-01-11 22:55:47 ipa 2021-01-11 22:55:55 heh 2021-01-11 22:56:36 disabled 2021-01-11 22:59:53 I have an MR to update all my maintainer adresses 2021-01-11 23:01:41 ty 2021-01-11 23:01:43 sigh 2021-01-11 23:01:52 checking build system type... Invalid configuration `x86_64-pc-linux-musl': machine `x86_64-pc-linux' not recognized 2021-01-11 23:02:07 and config.sub + config.guess are already being updated 2021-01-11 23:02:14 oh, not sub 2021-01-12 00:17:06 ddevault: Was it a mistake in 6c6ed7f62bd62650c5196315d1c8a67d8a0b9991 to set BartΕ‚omiej as the maintainer? 2021-01-12 00:17:31 how should I know 2021-01-12 00:17:36 that was more than 2 years ago 2021-01-12 00:17:40 presumably I asked first 2021-01-12 00:18:15 since that was the only change it probably would not have passed review otherwise 2021-01-12 03:07:33 the big As are done 2021-01-12 03:24:52 Left instructions on how to do it for https://gitlab.alpinelinux.org/alpine/aports/-/issues/12293 2021-01-12 07:03:12 morning 2021-01-12 07:03:22 anybody know what this is about? go: github.com/Masterminds/semver/v3@v3.1.0: Get "https://proxy.golang.org/github.com/%21masterminds/semver/v3/@v/v3.1.0.mod": dial tcp: lookup proxy.golang.org on 172.16.10.1:53: read udp 172.16.10.3:56433->172.16.10.1:53: i/o timeout 2021-01-12 07:07:47 dn lookup failed for some reason 2021-01-12 07:07:58 i suspect the request timed out 2021-01-12 07:21:04 ikke: im killing ruby on the 3.12 builders 2021-01-12 07:21:21 looks like you are running a gdb there 2021-01-12 07:23:08 im disabling the ruby tests 2021-01-12 07:30:32 ncopa: thanks, yes, was doing that in deed 2021-01-12 07:30:47 feel free to kill it 2021-01-12 07:32:27 ncopa: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/85 2021-01-12 08:17:37 nice! thanks 2021-01-12 08:27:21 i want to tag rc4 now 2021-01-12 08:30:02 builders are churning on plasma atm 2021-01-12 08:33:00 Should go through without problems though, was only URL fixes 2021-01-12 08:33:57 ok good 2021-01-12 08:34:00 on #musl dalias wrote that the 1.2.2 will be released soon 2021-01-12 08:34:19 yesterday 2021-01-12 08:34:23 "today" 2021-01-12 08:34:45 announced yesterday, I mean 2021-01-12 08:35:01 Soryr, yes, it was not a reaction to you 2021-01-12 08:35:16 last night actually 2021-01-12 08:35:30 ikke: ah, sorry then 2021-01-12 08:54:23 ncopa: stunnel has something strange on the builders. One process seems to segfault and gets orphaned, but make is still waiting on it. When I strace the orphaned process, I see it segfaulted, but when, I exit strace, the process disappears and make continues 2021-01-12 08:54:29 I saw this on several builders 2021-01-12 08:54:34 (just an fyi) 2021-01-12 09:07:37 ncopa: except for edge/mips64, all builders seem idle now 2021-01-12 09:23:44 ok. lets tag rc4 then 2021-01-12 09:24:07 i suspect the stunnel problem is related busybox update 2021-01-12 09:24:27 s390x is having network issues lately 2021-01-12 09:24:52 ncopa: do you remember why we have seabios in two sizes, 128k and 256k 2021-01-12 09:35:04 mps: i dont. wgat does git log say? 2021-01-12 09:35:30 i think there might been somethign that might have needed 128k at some point, but i dont remember 2021-01-12 09:43:21 ikke: I bet network issues could be solved with options="net" for golang pkgs 2021-01-12 09:44:02 andypost[m]: why would that help? 2021-01-12 09:44:16 The builders are not using rootbld 2021-01-12 09:44:23 It's just random timeouts 2021-01-12 09:44:54 Got it, thanks for explanation 2021-01-12 09:45:19 If you look at the last build, you see it managed to download a couple of go packages, but then it received a timeout 2021-01-12 09:45:58 ncopa: would it help to install a caching dns forwarded on the s390x builder host? 2021-01-12 09:46:29 We already have dnsmasq 2021-01-12 09:48:38 possibly 2021-01-12 09:48:53 we could use unbound or something 2021-01-12 09:49:23 dnsmasq should do caching as well, right? 2021-01-12 09:49:37 the edge builder is using the local dnsmasq as resolver 2021-01-12 09:49:56 I did add extra nameservers to the host (it had only one) 2021-01-12 09:51:21 "read udp 172.16.10.4:41454->172.16.10.1:53: i/o timeout" 2021-01-12 09:51:38 172.1.6.10.1:53 is dnsmasq on the host, strange 2021-01-12 09:58:20 IP conflict ? 2021-01-12 10:01:08 ncopa: git log doesn't tell anything. maybe it is made small to fit in some flash devices 2021-01-12 10:01:48 whatever reason was new release doesn't fit to 128KB 2021-01-12 10:02:16 maybe could if some things 'trimmed out' 2021-01-12 10:04:46 Ariadne: does not look like it 2021-01-12 10:18:55 ncopa: from seabios Kconfig 'Currently SeaBIOS will easily fit into 256 KB. To make it fit it into 128 KB (which was big enouth for a long time) you'll probably have to disable some featues such as xhci support.' 2021-01-12 10:19:37 seabios 1.14.0 2021-01-12 10:51:52 rc4 is out. this should be the last rc hopefully. are there anything that you think should be fixed before the 3.13.0? 2021-01-12 10:52:15 ncopa: do we want to wait on the musl 1.2.2 official release? 2021-01-12 10:52:22 or do we just upgrade it once released 2021-01-12 10:52:40 depends. if its released to day we include it 2021-01-12 10:52:53 i dont think we will wait another week for it 2021-01-12 10:53:22 https://gitlab.alpinelinux.org/alpine/aports/-/issues/11695 2021-01-12 10:53:24 ? 2021-01-12 10:53:47 it has not happened so i guess we post pone it 2021-01-12 10:53:58 ok 2021-01-12 10:54:01 there are a lot of things I want to fix/change, but this will always be, so release it this week 2021-01-12 10:54:28 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12176 2021-01-12 10:54:40 oh, we shoudl clean up the broken deps 2021-01-12 10:54:46 or make alpine rolling distro only :) 2021-01-12 10:55:13 mps: just use edge :) 2021-01-12 10:55:50 I do, mostly, except on important servers 2021-01-12 10:56:12 even on servers I backport some pkgs 2021-01-12 10:56:51 hum #12176 might be tricky 2021-01-12 11:04:24 $ apk dot --errors --repositories-file /dev/null --repository https://dl-cdn.alpinelinux.org/alpine/v3.13/main --root /tmp/apk --keys-dir /etc/apk/keys/ | tpaste 2021-01-12 11:04:24 https://tpaste.us/jn5l 2021-01-12 11:06:09 interesting that llvm10 depends on llvm10-dev 2021-01-12 11:06:33 perl-lwp-protocol-https should be moved to main, due to abuild depends on it 2021-01-12 11:10:44 we also need to move wireguard-tools 2021-01-12 11:10:56 which makes sense now that we have wireguard in mainline kernel 2021-01-12 11:18:08 Ariadne: i move batctl to main, due to ifupdown-ng depends on it. we cannot have packages in main depend on packages in testing 2021-01-12 11:18:46 ok that's fine 2021-01-12 11:18:52 it does work fine 2021-01-12 11:19:00 and kernels do support it 2021-01-12 11:37:26 strange, for some reason, tcpdump is only showing me the request packets, I don't see any responses coming in 2021-01-12 12:20:48 tcpdump from which side 2021-01-12 12:22:23 from the host, but I just wrote it to a file and analized it with wireshark 2021-01-12 12:22:37 mps: Maybe I'm reading the post on the ML wrong, but how would you move a package from unmaintained when it has been removed from the repo entirely 2021-01-12 12:23:13 Cogitri: ah, I thought it is still in unmaintained 2021-01-12 12:23:30 why OP didn't told name of pkg 2021-01-12 12:24:26 Dunno, but since they said the thing was purged in https://git.alpinelinux.org/aports/commit/?id=3ce3c4fd596debefbad77328a9b62a39eccf753c I assume the APKBUILD is no more 2021-01-12 12:27:02 yes, I see 2021-01-12 12:27:44 so Carl wants to move back all these pkgs removed with 3ce3c4fd596debefbad77328a9b62a39eccf753c :) 2021-01-12 12:29:06 I don't hate much things (if anything) but I really dislike alpine ML (please do not comment) 2021-01-12 12:30:27 I've come to accept it for discussions, but +1 on that for patches on the ML 2021-01-12 12:31:26 But fortunately we won't have to interact with it any more soon thanks to ddevault's work 2021-01-12 12:56:50 https://blog.gtk.org/2021/01/12/gtk-4-0-1/ 2021-01-12 13:15:45 I'm thinking to add /etc/man.conf to mandoc. It is in mentioned FILES in man.1 2021-01-12 13:15:55 any objections 2021-01-12 13:23:24 ncopa: any suggestions on things to try or look at/into are welcome, wrt #12176 2021-01-12 13:23:53 I mentioned it in #openzfs yesterday but no response yet 2021-01-12 13:29:41 have you tried this? https://gitlab.alpinelinux.org/alpine/aports/-/issues/12176#note_134334 2021-01-12 13:31:11 gah! you can't search the zfs manpages any longer since they're split up! 2021-01-12 13:31:47 ncopa: no, I haven't 2021-01-12 13:34:58 I think there were reasons as to why I didn't want to, although I assume it to work (seem to work for adiz0r) 2021-01-12 13:35:28 I'd like to know why it worked before and what's changed since 2021-01-12 13:37:09 ('zgrep legacy /usr/share/man/man*/z{fs,pool}*' is what you have to do now) 2021-01-12 14:18:54 ikke: you mean for the dns? 2021-01-12 14:20:08 In wireshark I do see both request and response 2021-01-12 14:27:16 any objections to merging !16738 ? 2021-01-12 14:33:26 hmm, no, I still do not see the response from the external DNS server 2021-01-12 14:37:40 what external DNS are you using 2021-01-12 14:37:48 in this case 1.1.1.1 2021-01-12 14:37:50 9.9.9.9 is what i recommend 2021-01-12 14:37:53 ok 2021-01-12 14:39:07 has anyone seen stwa around recently? 2021-01-12 14:39:42 not around here 2021-01-12 14:40:04 nor gitlab 2021-01-12 14:40:37 i trust cloudflare more than quad9 for privacy and security 2021-01-12 14:40:37 all right, thanks 2021-01-12 14:40:53 also for competent users at least use 9.9.9.10 2021-01-12 14:41:06 what's the difference? 2021-01-12 14:41:16 in any case, it does not make a lot of difference 2021-01-12 14:41:18 no filtering 2021-01-12 14:42:16 mainly i don't trust that their filter matches what i want to filter, plus the failure mode is confusing 2021-01-12 14:42:22 s/confusing/ambiguous/ 2021-01-12 14:42:22 Hello71 meant to say: mainly i don't trust that their filter matches what i want to filter, plus the failure mode is ambiguous 2021-01-12 14:42:47 dns query from a builder takes 5 seconds 2021-01-12 14:43:34 fairly consistently (for uncached records) 2021-01-12 14:44:05 let's move this to #alpine-infra 2021-01-12 14:46:17 mps: already upgraded gtk4.0 :) 2021-01-12 15:13:44 Cogitri: to 4.0.1? 2021-01-12 15:16:05 Yup, updated a few mins after release, was just in the middle of updating other GNOME 3.38.3 stuff anyway 2021-01-12 15:16:44 aha, very well 2021-01-12 16:38:33 clandmeter: !16750 2021-01-12 19:30:32 clandmeter: ping 2021-01-12 20:00:52 maxice8: pong 2021-01-12 20:01:30 Can you ok the move on !16750 ? 2021-01-12 20:02:48 Yes looks good. 2021-01-12 20:03:02 Although I'm on mobile 2021-01-12 20:03:20 Thanks! 2021-01-12 20:03:22 The first comment is more than enough 2021-01-12 20:17:24 Have you considered using Marge Bot for merging on GitLab? I remember hearing complaints about the need to rebase, wait for CI, then merge. Marge Bot seems to work around that by doing it for you after you assign the MR to it (though it is admittedly a bit awkward that a bot is necessary for something like this). 2021-01-12 20:19:10 ideally, CI would not even run after rebase (after it passed before) 2021-01-12 20:19:20 depending on the kind of change 2021-01-12 20:19:52 but that's technically more challenging 2021-01-12 20:23:02 if the package passed CI recently, and there are not further changes (ie, merge conflicts), then there is little reason why CI would not pass the 2nd time 2021-01-12 20:23:56 Even if CI failed, that wouldn't really help us, would it? 2021-01-12 20:24:05 Since we'd notice the failure on the builders 2021-01-12 20:42:39 Ping Cogitri 2021-01-12 20:42:55 Newbyte: Gitlab has merge trains but only for EE 2021-01-12 20:43:08 And they don't have a rebase method merge like Github 2021-01-12 20:47:18 Pong? 2021-01-12 20:48:37 Matrix mobile was being suboptimal 2021-01-12 20:48:39 Not very self-confident 2021-01-12 20:50:58 Yeah, it likes doing that 2021-01-12 20:51:06 Fluffychat has been pretty nice recently though 2021-01-12 20:57:58 neochat is definitely faster than element in sending messages, but also has its own weak points 2021-01-12 21:06:20 with meson / abuild-meson, how do I disable optimisation? 2021-01-12 21:06:26 just CFLAGS? 2021-01-12 21:07:06 Yup, we do buildtype=plain so no additional flags should be set 2021-01-12 22:24:45 What should we do with testing/bieaz? It is a newly added, the maintainer has deleted his/her gitlab account and deleted the upstream release used in the aport (a newer version is out). 2021-01-12 22:25:15 delete the source file ? 2021-01-12 22:25:19 deleted* ? 2021-01-12 22:25:37 yes, it is the reason for -> build-edge-mips64: failed to build bieaz: https://build.alpinelinux.org/buildlogs/build-edge-mips64/testing/bieaz/bieaz-0.0.19-r0.log 2021-01-12 22:25:47 nuke 2021-01-12 22:26:47 k, I will remove it. 2021-01-12 22:35:22 Thanks 2021-01-12 22:41:08 https://aur.archlinux.org/cgit/aur.git/log/?h=bieaz lol 2021-01-12 22:45:04 heh 2021-01-12 22:45:07 better commit messages than my dotfiles 2021-01-13 01:28:46 Last commits did break gettext 2021-01-13 02:17:53 break ? It shouldn't break as it only changed the Maintainer field 2021-01-13 02:29:15 ncopa: I think I found the culprit in nlplug-findfs #12176 2021-01-13 02:32:59 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12295 andypost 2021-01-13 03:14:45 algitbot: retry master 2021-01-13 07:08:25 maxice8, going to fix my maintainer's email 2021-01-13 07:31:57 morning 2021-01-13 07:36:22 cloud images on the downloads page: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/19 2021-01-13 07:36:41 morning o/ 2021-01-13 07:39:01 so we do 3.13.0 today? 2021-01-13 08:05:29 after we fix gettext 2021-01-13 08:06:34 A failure in the test suite 2021-01-13 08:17:40 caskd: how is the Telegram stuff going? 2021-01-13 08:18:10 haven't had time to take care of anything tg related 2021-01-13 08:18:22 currently migrating my prodution servers to alpine 2021-01-13 08:18:48 i'm planning to cleanup the code sometime to have everything external link against system libs 2021-01-13 08:19:42 I wonder why it was giving you out of memory errors on x86_64 though? 2021-01-13 08:20:02 on the pipeline? 2021-01-13 08:20:04 yes 2021-01-13 08:20:10 looks like it was doing fine apart from that 2021-01-13 08:20:26 probably they changed something and now it builds even more stuff so it runs out of mem 2021-01-13 08:20:54 it builds fine on armv7 which is 32-bit 2021-01-13 08:21:34 yeah but the x86_64 has more cores afaik so it does more stuff in parallel 2021-01-13 08:21:50 oh, that could be true 2021-01-13 08:23:14 oh, the x86_64 builder only had 2GB of RAM, whereas e.g. the aarch64 builder had 32GB of RAM 2021-01-13 08:23:23 presumably that's why then 2021-01-13 08:23:33 well that's odd 2021-01-13 08:24:01 anyways, it's mostly OOM on builds due to parallelism or sometimes even just simple linking 2021-01-13 08:31:21 our 86_64 CI host has 64G of ram 2021-01-13 08:31:32 but, it has 128 cores 2021-01-13 08:31:46 so about 512M per core :P 2021-01-13 08:31:52 https://gitlab.alpinelinux.org/caskd/aports/-/jobs/283021#L1 2021-01-13 08:32:06 > Memory: 1.95343 Gb 2021-01-13 08:32:20 and 2 cores? 2021-01-13 08:33:09 that runner should not have run CI builds (only things like linting) 2021-01-13 08:33:13 fixed it 2021-01-13 08:35:10 caskd: maybe just try giving the x86_64 CI another spin for !16345 then? 2021-01-13 08:35:19 sure 2021-01-13 08:35:50 I just restarted that job 2021-01-13 08:36:06 ah, thanks 2021-01-13 08:36:17 It does fail on s390x as well though 2021-01-13 08:36:58 I think it's disabled for s390x 2021-01-13 08:37:00 you mean ppc64le? 2021-01-13 08:37:08 s390x is disabled 2021-01-13 08:37:08 yes 2021-01-13 08:37:34 yeah it's related to protobuf being downgraded sometime, should fix it 2021-01-13 08:37:57 tg_owt should be rebuilt against .24 instead of .25 2021-01-13 08:38:49 I wonder if we should just build Telegram against Google's WebRTC instead of tg_owt 2021-01-13 08:39:07 tg_owt just seems to be a frozen fork of Google's WebRTC with CMake files added 2021-01-13 08:39:12 we probably should considering that they consider tg_owt as a toy 2021-01-13 08:39:21 but someone has to create a aport for that 2021-01-13 08:39:30 toy? 2021-01-13 08:40:00 well, https://github.com/desktop-app/tg_owt/issues/36#issuecomment-726718262 2021-01-13 08:40:20 oh, that one. I expect it to stay open till the end of times 2021-01-13 08:40:52 and yes, that comment wasn't very inspiring 2021-01-13 08:41:23 yeah... arch linux also builds against tg_owt since a few months so there might be some incompatiblity somehow... 2021-01-13 08:41:46 Fedora does it as well 2021-01-13 08:41:51 they already had libwebrtc originally so idk why they changed 2021-01-13 08:41:59 x86_64 now passed 2021-01-13 08:42:23 I think it may just be that they want to "follow upstream", but in this case upstream's method is dubious 2021-01-13 08:43:04 they have been under pressure to say the least due to the boom tg has and the features they want to add and the build system turned to something that reminds me of chromium 2021-01-13 08:43:48 that's why i said i want to clean it up sometime by just removing everything i can as long as it still builds 2021-01-13 08:43:59 and then relink against everything upstream 2021-01-13 09:54:44 I wonder what broke gnulib (gettext package) 2021-01-13 09:55:46 ncopa: I've added some details to the ticket 2021-01-13 09:55:49 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12295 2021-01-13 09:56:24 i came to the same conclusion with pritf debugging :) 2021-01-13 09:56:43 s/pritf/printf/ 2021-01-13 09:56:44 ncopa meant to say: i came to the same conclusion with printf debugging :) 2021-01-13 09:56:53 ikke: good job 2021-01-13 09:57:23 but, this passed when i set up the builders. so i wonder what changed. it could be recent musl 2021-01-13 09:59:30 I have a simple c program that shows this as well 2021-01-13 10:01:41 isn't musl realpath changed in last week or two 2021-01-13 10:04:53 changed in nov 2021-01-13 10:05:32 master has not been updated in 4 weeks 2021-01-13 10:06:05 huh, I don't paste link where dalias posted changes 2021-01-13 10:06:16 don't have* 2021-01-13 10:06:17 im looking at the canonicalize_file_name implementation in gnulib 2021-01-13 10:06:52 one thing i discovered was that it does not detect PATH_MAX, which only is exposed with _GNU_SOURCE 2021-01-13 10:07:23 so im currently rebuilding getttext with CFLAGS="$CFLAGS -D_GNU_SOURCE" 2021-01-13 10:07:48 should make it detect more stuff from libc rather than use gnulib 2021-01-13 10:09:34 I beleive I've had the zfs import error messages I mention since I began booting from zfs with alpine a year ago, but didn't care much since it worked https://gitlab.alpinelinux.org/alpine/mkinitfs/-/merge_requests/78 2021-01-13 10:09:58 !78 2021-01-13 10:10:23 mps: isn't that just for alpine/aports? 2021-01-13 10:10:30 omni: yes 2021-01-13 10:10:57 algitbot should go in school 2021-01-13 10:11:21 it should now which project you thought of 2021-01-13 10:11:54 something like 'mkinitfs!78' 2021-01-13 10:12:41 same syntax as gitlab uses 2021-01-13 10:13:25 omni: that makes sense to me 2021-01-13 10:18:34 ncopa: I'm thinking if mkinitfs-init should do zfs import at all, since it's already done by nlplug-findfs, if at least force import should be kept or if that too should be moved to nlplug-findfs 2021-01-13 10:19:16 either way I think it's safe to keep mkinitfs-init as is and just patch nlplug-findfs 2021-01-13 10:20:18 yeah, that makes sense. thanks alot for your work on this 2021-01-13 10:20:30 i guess I need to use 3.12, set up a vm with zfs root 2021-01-13 10:20:32 and test upgrade? 2021-01-13 10:20:34 that something was introduced recently that made ro mount of zroot to /sysroot stop working 2021-01-13 10:20:48 my guess is that zfs 2.0.0 introduced it 2021-01-13 10:21:35 yeah, but it is weird to me that you're allowed to mount zroot read-write at /sysroot when it is already mounted at / 2021-01-13 10:21:50 -N Import the pool without mounting any file systems. 2021-01-13 10:22:22 right, I copy-pasted that line in the commit & MR messages =) 2021-01-13 10:22:24 i think that makes sense anyway, since nlplug-findfs is not expected to mount the root, right? 2021-01-13 10:23:25 i have zfs root on my laptop, but i think i'd like to test it in a vm first 2021-01-13 10:23:59 i need to 1) reproduce the error, 2) apply the fix, 3) test that the fix solves the issue 2021-01-13 10:24:06 and then I'd like to verify the fix on my laptop 2021-01-13 10:24:06 ncopa: I built a separate initramfs and manually chose that to boot with 2021-01-13 10:25:53 well, I built nlplug-findfs and did 'doas cp nlplug-findfs $(which nlplug-findfs' first and then 'doas mkinitfs -o /boot/initramfs-zfs $(/bin/ls /lib/modules)' 2021-01-13 10:26:56 and then edited and replaced initramfs-lts with initramfs-zfs at boot 2021-01-13 10:28:45 (I also made a copy of the provided /sbin/nlplug-findfs before I replaced it with my patched one) 2021-01-13 10:43:58 ncopa: I'm curious how you haven't bumped into this yet, if you run edge/v3.13.0_rcX on zfs root 2021-01-13 10:44:41 do you use grub? not that I think that should change anything..? 2021-01-13 10:45:12 I use zfs root too on my NAS 2021-01-13 10:45:16 just works on edge 2021-01-13 10:45:27 But I use rEFInd instead of syslinux 2021-01-13 10:46:36 omni: i havent updated my laptop in a while 2021-01-13 10:47:36 ah (= 2021-01-13 10:50:10 Cogitri: I haven't tried/used rEFInd, does it use initramfs-init? 2021-01-13 10:53:54 Cogitri: your zfs root doesn't happen to have mountpoint=legacy or none? 2021-01-13 10:59:54 Ah, I think I have mointpoint=legacy 2021-01-13 11:36:32 ncopa: any idea about realpath? 2021-01-13 11:37:00 ah, just saw the messags in #musl 2021-01-13 11:57:39 I created !16771 but still wonder is the lxcfs needed anymore 2021-01-13 11:58:17 Cogitri: if so, then nlplug-findfs won't mount at import and you duck this 2021-01-13 12:31:43 ikke: let me test on *bsd and glibc 2021-01-13 12:36:27 ikke: technically the gnulib test suite is wrong, but I think the best solution is to fix musl 2021-01-13 12:37:00 dejura standard versus defacto standard 2021-01-13 12:39:11 or, wrong implementation 2021-01-13 12:42:57 according to https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13, it's for the implementation to decide 2021-01-13 12:43:47 "If a pathname begins with two successive characters, the first component following the leading characters may be interpreted in an implementation-defined manner, although more than two leading characters shall be treated as a single character." 2021-01-13 12:44:15 ikke: I'm on #musl, seen that 2021-01-13 12:44:32 saw? 2021-01-13 12:45:48 "I have seen that", or "I saw that" 2021-01-13 12:46:20 "i've seen that" 2021-01-13 12:46:54 heh, why 'I', I'm writing in my name not someone else :) 2021-01-13 12:47:31 'seen' is a lot shorter, though 'sin' is more :) 2021-01-13 12:52:33 ikke: thanks for explanations :) 2021-01-13 12:53:25 huh, so 3.13 will be released without waiting for musl 1.2.2 2021-01-13 12:53:29 mps: btw, why did you assign the lxc MR to me? 2021-01-13 12:53:49 mps: depends on how quickly 1.2.2 is releaed 2021-01-13 12:53:52 released* 2021-01-13 12:54:28 because you best know should it be merged before 3.13 release, you keep all builders 2021-01-13 12:54:56 The builder hosts are not even on 3.12 yet :P 2021-01-13 12:55:20 I want to upgrade them after 3.13 is released, though 2021-01-13 12:55:32 ah, that's why we have so much issues with them ;) 2021-01-13 12:55:37 :D 2021-01-13 12:56:42 ok, I will remove assignment and merge 2021-01-13 14:01:01 ncopa: will you apply that musl patch locally? 2021-01-13 14:02:16 And do we know why this suddenly is an issue? 2021-01-13 14:06:20 i just made a patch for gettext. I want hear from musl devs before I add it to alpine. https://www.openwall.com/lists/musl/2021/01/13/1 2021-01-13 14:06:39 Yes, read it 2021-01-13 14:06:46 it happened due to musl reimplemented realpath relatively recent 2021-01-13 14:06:58 the re-implementation is good as it does not depend on /proc being mounted 2021-01-13 14:07:00 ah, ok, and I guess gettext was not rebuilt since then? 2021-01-13 14:07:10 yes, i think so 2021-01-13 14:07:39 and i think i used old musl when bootstrapping the builders 2021-01-13 14:07:55 and gettext was not rebuilt since then 2021-01-13 14:08:08 Ah, fixing the gnulib test suite to allow for "//" as well 2021-01-13 14:08:28 yeah. according posix it depends on implementation 2021-01-13 14:08:48 so musl behavior it not wrong, technically 2021-01-13 14:08:53 its just inconvenient 2021-01-13 14:09:20 I tested it on a number of systems: https://www.openwall.com/lists/musl/2021/01/13/2 2021-01-13 14:12:09 looking for some help regarding defining package/sub-package dependancy. I've overhauled the rng-tools package into a rng-tools main package and rng & rng-extras sub-packages (both of which provide differently built rngd binaries). I've tried defining "provides: rng-any" for both rngd and rngd-extras also with differing provider_priority values. The issue is that when the main rng-tools package is installed I want this to pull in rngd 2021-01-13 14:12:09 subpackage unless rngd-extras is already installed. I can't put a "depends: rngd-any" for rng-tools as abuild complains. Any suggestions? 2021-01-13 14:12:13 And it's even a special case in the code that adds this behavior 2021-01-13 14:13:36 I don't think we need rng-any 2021-01-13 14:14:37 mps: I tried having rngd and rngd-extras both defined "provides: rngd" (with and without version/rel nums) and that didn't work either - an "apk add rng-tools" gave errors 2021-01-13 14:14:37 rng-tools and rng-tools-(extra|all|full) is ok to me 2021-01-13 14:17:53 rng-tools package contains rngtest binary, rngd & rngd-extras both contain rngd binary 2021-01-13 14:19:01 minimal: rng-tools contains rngd 2021-01-13 14:19:42 mps: in the current version, yes - I'm talking about the changes I'm working on in an MR 2021-01-13 14:19:58 it should be as it is 2021-01-13 14:20:21 least surprise principle (for users) 2021-01-13 14:21:11 indeed it should - that's why I want rng-tools to automatically drag in rngd except if rngd-extras is already installed 2021-01-13 14:21:23 I'm trying to maintain backwards compatibility 2021-01-13 14:22:17 that can be solved to having rng-tools-full which conflicts with rng-tools 2021-01-13 14:23:37 and also move rngtest out of rng-tools? Its not strictly necessary for rngd to function - I've done it other way around, moved rngd out of rng-tools 2021-01-13 14:24:24 no, backward compatibility shouldn't be broken without good reason 2021-01-13 14:25:31 so if rngd-extras is install then you'll not be able to install rngtest as that's in rng-tools which would conflict with rngd-extras 2021-01-13 14:26:21 that's why I'd seperated rngtest from rngd - so you could have either version of rngd binary installed together with rngtest 2021-01-13 14:26:37 my advice is keep rng-tools as it is now, only remove librtlsdr deps, and make rng-tools-full with all things 2021-01-13 14:27:02 you misunderstood me I think 2021-01-13 14:27:05 mps: and how to solve rngtest issue in that scenario? 2021-01-13 14:27:27 rng-tools-full will replace rng-tools on install 2021-01-13 14:27:48 are you suggesting I put rngtest binary in both packages? 2021-01-13 14:27:54 yes 2021-01-13 14:28:02 and rngd in booth 2021-01-13 14:28:38 they need to be linked with extra libs 2021-01-13 14:28:46 I was trying to avoid duplication - also trying to ensure "normal" rngd package would be "minimal" by installation of rngtest being optional 2021-01-13 14:29:32 it will not work, I think. prove me wrong and I will amend your changes 2021-01-13 14:30:13 -rwxr-xr-x 1 root root 39320 Jun 19 2020 /usr/bin/rngtest 2021-01-13 14:30:22 39KB 2021-01-13 14:30:57 my plan was that rng-tools would only contain rng-test but through dependancy installing or upgrading rng-tools would drag in the rngd subpackage - but if you'd instead decided to explicitly install only rngd then you could do so 2021-01-13 14:31:53 sorry, have to go out, do whatever you want 2021-01-13 14:32:00 mps: 39KB? The other day you weren't happy about the 1.2KB of comments I'd planned to add to the conf.d file ;-) 2021-01-13 15:34:56 Cogitri: i think this is wrong: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/commit/edad1469ace201e53f05ceeae2b779ac12c33990#1187d04399f559e39041f15bc35251c44c78daae_282_287 2021-01-13 15:35:27 because nlplug-findfs.c will run zpool import 2021-01-13 15:36:29 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/nlplug-findfs.c#L1016 2021-01-13 15:37:08 Oh, sorry, I guess nlplug-findfs.c should have support for force importing and that thingie I added shpuld be removed 2021-01-13 15:37:25 I only ever use legacy mounting, that's probably why it worked for me 2021-01-13 15:38:16 i think i did have issue with the force thingy some time ago, due to dual boot on my macbook 2021-01-13 15:38:23 but i had other workaround for that 2021-01-13 15:38:52 why is -d /dev needed? 2021-01-13 15:39:37 btw, i think mountpoint=legacy is required for rootfs 2021-01-13 15:40:12 we need to be able to mount it with legacy tools, like `mount` and `mount --move` for doing the switchroot 2021-01-13 15:40:14 Not sure what's the right ZFS terminology, but you can make zfs volumes look as if they're an entire drive and not just a volume 2021-01-13 15:40:25 FreeBSD's virtualization thingie uses that 2021-01-13 15:40:40 and without -d /dev it wouldn't find disks that have that setup for me 2021-01-13 15:40:40 mount is "legacy" ? 2021-01-13 15:40:58 according zfs manpage it is :) 2021-01-13 15:40:58 Yeah, zfs uses its own stuff for mounting apparently 2021-01-13 15:41:03 who decided that? lennart? 2021-01-13 15:41:06 oh 2021-01-13 15:41:09 zfs.. 2021-01-13 15:41:27 so i meant "legacy" tools 2021-01-13 15:41:56 Anyway, that force_import thingie is something we should handle one way or another, otherwise we throw users into an emergency shell every time their volume is mounted by other computer/os :/ 2021-01-13 15:43:09 was thrre a realpath problem? 2021-01-13 15:44:12 dalias: yes 2021-01-13 15:44:26 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12295 2021-01-13 15:44:57 summary: musl realpath does not normalize "//" into "/", while other implementations do, and gnulib test suite verifies it does 2021-01-13 15:45:22 eew 2021-01-13 15:45:29 dalias: also: https://www.openwall.com/lists/musl/2021/01/13/1 2021-01-13 15:45:40 what happens when gnulob test fsils? 2021-01-13 15:46:12 It failed on our builders 2021-01-13 15:46:25 But ncopa now patched it to accept both "//" and "/" 2021-01-13 15:47:22 https://www.openwall.com/lists/musl/2021/01/13/2 ncopa verified behavior on a variety of systems: https://www.openwall.com/lists/musl/2021/01/13/2 2021-01-13 15:50:55 yes im aware but this is intentional 2021-01-13 15:51:45 dalias: what happened was that all builds of gettext package failed on the alpine builders and we had to spend time on figuring out what went wrong instead of tagging the 3.13 release 2021-01-13 15:52:52 dalias: what is the rationale for that behavior? 2021-01-13 15:53:09 to allow system to treat // specially 2021-01-13 15:53:24 what system needs that? 2021-01-13 15:53:31 midipix was planning to do that but dropped it 2021-01-13 15:53:44 as I understand cygwin does and z/OS 2021-01-13 15:53:53 even if system doesnt distinguish / and // there is no requirement on realpath not to have redundant / in result only no . .. or symlink 2021-01-13 15:54:10 so gnulib is just wrong here 2021-01-13 15:54:22 and i worked around it by patching gnulib 2021-01-13 15:54:36 i know gnulib is technically wrong 2021-01-13 15:54:56 musl is not glibc. it doesnt maintain identical details that apps cannot correctly depend upon for the sake of bug compat 2021-01-13 15:55:10 but i find the musl behavior unexpected and slightly annoying 2021-01-13 15:55:53 because it triggers bugs in bad software, and people blame musl (or alpine) for it 2021-01-13 15:56:05 "too much hazzle. lets use gnu linux" 2021-01-13 15:56:43 "works on ubuntu, works on macos, works on openbsd, fails on alpine" 2021-01-13 15:58:01 i'd kinda like to have //foo resolve to /foo if they can be determined to be the same but that's somewhat heavier 2021-01-13 15:58:30 requires stat comparison and one nice thing about new realpath is no stat 2021-01-13 15:59:35 does it depend on kernel (eg linux) or on the filesystem (eg ext4/zfs/whatever)? 2021-01-13 15:59:58 isn't the only problem with stat that it's slow? considering that // -> / is "wrong" anyways 2021-01-13 16:00:07 i dont think stock linux can distinguish them but im not sure 2021-01-13 16:00:24 its not "wrong". i think both are allowed 2021-01-13 16:00:25 hello71, it doubles the size for static link 2021-01-13 16:00:42 since stat is huge due to having to translate kernel crap 2021-01-13 16:00:43 also, fwiw, the man-pages realpath(3) says "resolves references to ... extra '/' characters" 2021-01-13 16:01:49 it doesn't actually define what "extra" means, but a reasonable developer would almost certainly interpret this to mean that it would translate // to /. it also doesn't say anything about that being implementation-specific 2021-01-13 16:02:06 what happens when gnulib test fails? does it try to do a broken replacement? 2021-01-13 16:02:32 make check fails 2021-01-13 16:02:47 so build fails with error 2021-01-13 16:03:19 ok so just error in tests? 2021-01-13 16:03:24 yup 2021-01-13 16:03:31 and the test is wrong, technically 2021-01-13 16:03:47 i read test as configure-time test 2021-01-13 16:03:54 and was confused 2021-01-13 16:04:05 its not configure test 2021-01-13 16:04:17 yes its wrong and breaks on some real world systems, no? 2021-01-13 16:04:38 what breaks where? 2021-01-13 16:05:38 i dont think it breaks on any real world system 2021-01-13 16:05:44 there is an #ifdef 2021-01-13 16:06:04 for at least one known system where it differs 2021-01-13 16:06:21 #ifndef __MVS__ 2021-01-13 16:06:35 But there might be more applications that assume this behaviour 2021-01-13 16:07:02 that was my concern too 2021-01-13 16:07:16 but i doubt there are many of them 2021-01-13 16:07:25 if any 2021-01-13 16:07:57 it shouldnt really matter 2021-01-13 16:08:14 im mostly annoyed that this pops up now, the day i was about to do 3.13 release 2021-01-13 16:08:28 :p 2021-01-13 16:21:53 Cogitri: do you know if other distros has an zfs_force boot option? 2021-01-13 16:22:12 Everything that uses dracut has that option 2021-01-13 16:22:25 So e.g. Fedora has it 2021-01-13 16:24:34 looks like arch linux has it also 2021-01-13 16:26:23 looks like other option is to set hostid boot option spl.spl_hostid=0x0a0af0f8 2021-01-13 17:13:51 fun, quickjs is failing now on x86_64 2021-01-13 17:27:25 it says to build with -fPIC, but that does not seem to help (CLFAGS) 2021-01-13 17:29:17 Does it make sense to build with both -static and -shared? 2021-01-13 17:30:35 no 2021-01-13 17:31:02 tackling emby 2021-01-13 17:31:12 seems like it hardcodes a soname dependency, 2021-01-13 17:31:18 ? 2021-01-13 17:32:22 !16778 2021-01-13 17:44:39 In my opinion emby should be replaced with jellyfin (https://github.com/jellyfin/jellyfin) since the latest versions are no longer open source. 2021-01-13 17:46:04 the quickjs issue is a bit over my head 2021-01-13 17:47:01 ikke: could you take a look at #12297 ? 2021-01-13 17:47:31 TBK[m]: later tonight 2021-01-13 18:02:39 @TBK:matrix.org: agreed, Emby should really be dropped. Jellyfin is the FOSS-fork and continuous to be updated 2021-01-13 18:06:47 eggdrop failure looks bogus, not even related to the software but something in the alpine build system 2021-01-13 18:06:58 (why would it decide bind-libs is a conflicting package??) 2021-01-13 18:14:36 Oh, separately from the conflict, bind-libs being terr is my fault, was troubleshooting dns issues on the s390x builder 2021-01-13 18:14:53 there* 2021-01-13 18:15:07 :D 2021-01-13 18:15:17 :D 2021-01-13 18:15:55 so setup-disk has changed so setup-disk -m sys /mnt doesn't work anymore on rpi =/ 2021-01-13 18:16:35 ikke, :) 2021-01-13 18:23:45 MY-R: my syslinux on efi is over 2021-01-13 18:24:36 main mistake is testing on old macbook instead on 'normal' pc notebook 2021-01-13 18:25:28 finally found that ssd 3 is to fast for old macbook, had to force it to 3GB 2021-01-13 18:25:38 too* 2021-01-13 18:25:58 (never will learn these 'fine' points of english) 2021-01-13 18:26:43 mps: native speakers are general the worst for using the correct form of a language 2021-01-13 18:27:00 so, yes, alpine can boot with syslinux in efi mode on old macbook, also on 'normal' PCs 2021-01-13 18:30:58 oh that script is more intelligent nowadays.. all good 2021-01-13 18:40:39 mps: so syslinux working fine with efi, I will keep that in mind, thanks! 2021-01-13 18:47:59 MY-R: yes, I'll clean script I used and add some notes. basically it is steps described in slackware guide I posted yesterday here 2021-01-13 18:48:37 mps: so soon wiki update? :) 2021-01-13 18:49:30 I think it will appear here http://arvanta.net/alpine/ :) 2021-01-13 18:49:55 I don't know to use wikis 2021-01-13 18:51:35 oh ok 2021-01-13 18:52:48 ikke: How about we make the group which beginners can ping (and that aports-qa-bot tells them) now and you add me for the time being? 2021-01-13 18:53:14 So aports-qa-bot doesn't tell everyone to ping `@developers` 2021-01-13 18:54:38 mps: finished work on !16605, would be great if you could have a look at it 2021-01-13 18:55:37 minimal: will try to find some time before bed this evening 2021-01-13 18:56:53 minimal: about sizes, size of binaries is not same as size in /etc/conf.d, i.e. different 'things' 2021-01-13 19:03:20 mps: no rush, still waiting for existing maintainer to publically agree to the change in maintainership 2021-01-13 19:12:06 mps: upstream rng-tools author is *very* responsive, I'm getting responses and fixes/merges within minutes. 2021-01-13 19:13:27 any ipxe script expert around? Any idea on how I can instruct alpine to download and execute a binary/script ? 2021-01-13 19:18:16 well you can't run ipxe scripts not in ipxe 2021-01-13 19:19:05 so I should ship a custom apkovl 2021-01-13 19:19:45 no way to instruct ipxe to wget/exec a binary file, for example 2021-01-13 19:23:04 a linux file? 2021-01-13 19:23:08 yes 2021-01-13 19:23:15 static binary 2021-01-13 19:24:51 how would it do it without linux 2021-01-13 19:25:45 static only allows you to run without libc, you still need a kernel 2021-01-13 19:27:18 no you're right...i was wondering some sort of injection during the boot process 2021-01-13 19:27:53 I should put it in the init or with a custom apkovl 2021-01-13 19:28:10 *initramfs 2021-01-13 19:31:57 hum, there are more tests that fails now. tinc-pre, nbd 2021-01-13 19:34:39 πŸ€” 2021-01-13 19:36:20 ncopa, re: musl release, day before yesterday i talked about rolling it and got prelim stuff writeups etc done but didnt quite finish, then had dentist appt yesterday and felt bleh :-p 2021-01-13 19:36:44 i can roll today if there's nothing blocking 2021-01-13 19:36:51 ouch. Hope you have shiny healthy teeth now. :D 2021-01-13 19:36:52 that would be nice 2021-01-13 19:37:19 skarnet, well one that had been needing a crown for a long time finally chipped in a way that was really annoying so... :-p 2021-01-13 19:37:20 yeah, i hope you feel better today 2021-01-13 19:38:01 temp crown doesn't really feel good, can't bite down on it, but at least process to fix right is started 2021-01-13 19:40:25 clandmeter: do you mind if we drop the tinc-pre package? seems like there are no tinc-1.1 release since 2018 2021-01-13 19:43:44 Ok 2021-01-13 19:44:36 seems like there have been a few commits in 2020 though 2021-01-13 19:56:34 would be great if the builders were idle tomorrow morning so we could tag the release 2021-01-13 19:56:51 i think the nbd fail is due flaky test 2021-01-13 20:20:08 Cogitri: How would we call this group? 2021-01-13 20:20:19 Note that we have all our 'user' groups in teams/* 2021-01-13 20:20:29 group for what 2021-01-13 20:21:03 Who users can ping for help 2021-01-13 20:21:32 helpers ? 2021-01-13 20:21:36 i suggested mentors before 2021-01-13 20:21:51 since the goal is not to just provide help, but also guide them through the process of gaining commit privs 2021-01-13 20:21:55 guides? since this is Alpine linux :D 2021-01-13 20:22:04 that could work 2021-01-13 20:22:23 guides sounds more like tutorials 2021-01-13 20:22:43 gitlab-org has 'coaches' 2021-01-13 20:23:57 I don't have a strong opinion, we just need to choose something 2021-01-13 20:25:25 mentors 2021-01-13 20:26:11 Naming things is always the hardest part :D 2021-01-13 20:26:30 Mentors or Coachers sounds good 2021-01-13 20:27:27 charismatic leaders 2021-01-13 20:28:23 Lords, gods, saviours 2021-01-13 20:28:42 https://gitlab.alpinelinux.org/groups/team/mentors 2021-01-13 20:29:05 πŸ‘ 2021-01-13 20:29:07 team/apkbuild? :D 2021-01-13 20:29:26 I've added you, Cogitri, and I'm by default part of it as well :P 2021-01-13 20:29:47 how can one apply to this group? :D 2021-01-13 20:30:12 Well, first you need to become a developer yourself before you can mentor others 2021-01-13 20:31:17 And now, quickjs 2021-01-13 20:31:30 i wrote one apkbuild back in a day, fixed one in alpine and reviewed one for alpine, does that count? :D 2021-01-13 20:31:48 insep_: it's a start :P 2021-01-13 20:32:04 ikke: Another thing: Could you make a MR to https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/.gitlab/aports-qa-bot.json#L5 to change `@developers` to the new group handle? 2021-01-13 20:32:58 ikke: :D 2021-01-13 20:34:04 Cogitri: that message only contains a placeholder 2021-01-13 20:35:45 Oh 2021-01-13 20:35:47 whoops :D 2021-01-13 20:36:14 Sorry, a bit brain-drained today, did some 5K LOC changes at work today :D 2021-01-13 20:36:44 I debugged some ruby code the entire day :P 2021-01-13 20:36:53 (chef related) 2021-01-13 21:28:55 just upgraded one box to edge from 3.12 and noticed that perl-io-compress conflicts with perl 2021-01-13 21:29:48 it's no longer in edge even 2021-01-13 21:30:15 https://pkgs.alpinelinux.org/packages?name=perl-io-compress&branch=edge 2021-01-13 21:31:44 https://pkgs.alpinelinux.org/packages?name=perl-io-compress&branch=edge 2021-01-13 21:31:48 2aa6d4ad481e1c4c405d8d8089ae6171d9d697ca 2021-01-13 21:31:56 apparently it has been integrated into perl 2021-01-13 21:32:02 yes 2021-01-13 21:32:22 but apk upgrade -a don't know this 2021-01-13 21:32:34 Shouldn't perl have gotten a provides and replaces for it then? 2021-01-13 21:32:52 that's not the issue 2021-01-13 21:33:00 it's the fact that the package stil exists 2021-01-13 21:33:06 on 3.12 2021-01-13 21:33:27 although, a replaces might fix it 2021-01-13 21:34:02 not sure how replaces interacts when the package still exists 2021-01-13 21:46:32 seems like 3.13 builders all passed 2021-01-13 21:46:38 nice 2021-01-13 21:46:57 should I do rc5 now, before I go to bed? or we just tag 3.13.0 tomorrow morning 2021-01-13 21:47:06 do rc5 :D 2021-01-13 21:54:08 ok, here comes rc5 2021-01-13 21:57:25 everyone hold their horses :P 2021-01-14 00:58:29 !16793 2021-01-14 03:00:11 rc5 works for me 2021-01-14 06:42:58 good morning! 2021-01-14 06:43:03 morning 2021-01-14 06:43:45 ncopa: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/20 2021-01-14 06:43:49 i was about to say that builders are idle, but they arent 2021-01-14 06:44:13 nope, just a stream of commits were pushed 2021-01-14 06:45:21 ikke: wonderful! thanks for preparing the release notes! 2021-01-14 06:45:32 i also see that 5.10.7 is out 2021-01-14 06:45:38 lets update that first 2021-01-14 06:46:03 Not s 2021-01-14 06:46:09 not all details are there yet 2021-01-14 06:46:17 musl-1.2 upgrade notes 2021-01-14 06:47:11 In my defense it is still not morning here 2021-01-14 06:47:21 :D 2021-01-14 06:47:37 03:47 AM 2021-01-14 06:48:12 thats morning. just very very early :) 2021-01-14 06:57:07 fair 2021-01-14 06:57:23 on the plus side I got a few upgrades that had CVE fixes 2021-01-14 06:57:34 which means we won't have to backport something to 3.13-stable 5 seconds after releasing it 2021-01-14 07:00:37 maxice8: you are optimist :) 2021-01-14 07:01:28 I'm just pretending 2021-01-14 07:01:42 If you knew how bad things really are 2021-01-14 07:02:19 also gptfdisk also has a new release with CVE fix but it breaks our patch and the fix doesn't work for us :shrug: 2021-01-14 07:14:28 ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12299 2021-01-14 07:32:45 ikke: i added a line and changed the title 2021-01-14 07:32:48 thanks! 2021-01-14 07:33:04 huh, openresolv site was awol few days, and now it is available. to late for upgrading openresol, ncopa ? 2021-01-14 07:33:31 and u-boot is just released, 2021.01 2021-01-14 07:33:36 its ok as long as it does not break anything or take alot of time to build 2021-01-14 07:34:23 and you want to break tradition, release on fridays :) 2021-01-14 07:47:49 ncopa: nice 2021-01-14 08:00:55 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12293 if anyone wants to help contacting the maintainers 2021-01-14 08:16:30 andypost[m]: what is your 'note' for openresolv 2021-01-14 08:17:05 sorry, I notised it too late, just after merge 2021-01-14 08:18:55 I just rebased 2021-01-14 08:20:11 ah, ok 2021-01-14 08:41:29 im gonna move https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases to https://alpinelinux.org/releases 2021-01-14 08:41:37 and have the raw data in yaml 2021-01-14 08:42:08 ncopa: ok 2021-01-14 08:42:29 We can at some point render it into something nicer from the raw data 2021-01-14 08:42:39 what is python pkg_resources, https://gitlab.alpinelinux.org/mps/aports/-/jobs/292845#L1697 2021-01-14 08:42:44 ikke: thats what im working on right now 2021-01-14 08:42:48 ncopa: ok, nice 2021-01-14 08:42:58 which module should be added to makedeps 2021-01-14 08:43:12 py3-setuptools 2021-01-14 08:43:23 aha, lets try 2021-01-14 09:11:55 ikke: som packages supports importlib-metadata instead of the full py3-setuptools https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13942/diffs#d659c4a0f7c57263535792720cb710787d3005fc 2021-01-14 09:12:08 s/som/some/ 2021-01-14 09:12:08 HRio meant to say: ikke: some packages supports importlib-metadata instead of the full py3-setuptools https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13942/diffs#d659c4a0f7c57263535792720cb710787d3005fc 2021-01-14 09:12:46 aha ok, but you patched rdiff-backup there? 2021-01-14 09:14:41 backport from rdiff-backup master 2021-01-14 09:15:27 so I would not need py3-setuptools and all boxes running 3.11 2021-01-14 09:15:35 s/and/on/ 2021-01-14 09:15:35 HRio meant to say: so I would not need py3-setuptools on all boxes running 3.11 2021-01-14 09:16:52 sorry forget det 3.11 part rememebered wrong about this specific commit 2021-01-14 10:11:54 ok, i have a generated releases page that im relatively happy with 2021-01-14 11:19:22 ncopa: need any help with something? 2021-01-14 11:19:41 I'll work on improving the release notes 2021-01-14 11:26:06 in a call. will tag in a sec 2021-01-14 11:36:39 ncopa: What do we mention for musl 2021-01-14 11:36:49 1.2.2? 2021-01-14 11:40:45 i think we can say 1.2.x 2021-01-14 11:41:07 we should mention the time64 thingy 2021-01-14 11:41:12 Yes, was just working on that 2021-01-14 11:41:37 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0 2021-01-14 11:41:43 ok. let me tag the release now 2021-01-14 11:45:08 what we do with ipv6? https://gitlab.alpinelinux.org/alpine/aports/-/issues/10237 2021-01-14 11:45:14 move to 3.13.1 or 3.14? 2021-01-14 11:45:17 i guess 3.14 2021-01-14 11:45:47 It's not really tied to an alpine release I guess, so it does not matter that much 2021-01-14 11:48:58 ncopa: I've updated https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0 2021-01-14 11:49:01 I have to go now 2021-01-14 13:40:30 πŸ‘ 2021-01-14 13:40:52 ikke: are yo working on the release notes? 2021-01-14 13:41:03 no, not at the moment 2021-01-14 13:41:12 I see some suggestions were made 2021-01-14 13:41:15 ok let me push force a minor fix 2021-01-14 13:41:18 those suggestions 2021-01-14 13:43:41 zstd support in mkinitfs is pretty cool, could be worth a mention 2021-01-14 13:44:14 3.13 also contains k3s 2021-01-14 13:44:33 really like this 2021-01-14 15:02:53 release notes is merged 2021-01-14 15:03:16 nice 2021-01-14 15:03:24 nice 2021-01-14 15:24:35 https://wwwtest.alpinelinux.org/ 2021-01-14 15:25:09 note that i changed the top menu a bit. "home" is gone, "releases" pages is added. on downloads there is "cloud images" link 2021-01-14 15:25:20 and the 3.13.0 release notes is there too 2021-01-14 15:25:42 ncopa: nice, week ago I wanted ask why "release" wiki page isnt on main alpine site or at least in downloads 2021-01-14 15:25:57 https://wwwtest.alpinelinux.org/releases/ is supposed to replace the wiki 2021-01-14 15:26:31 And icons? 2021-01-14 15:26:34 I think dates with numbers only looks better 2021-01-14 15:26:41 ohy no, they were already there 2021-01-14 15:26:47 There is a typo "for Alpine Linux abailable at the same time" (srry to be that guy) 2021-01-14 15:27:08 exception: this is wwwtest, so good that you catch it there :) 2021-01-14 15:27:17 I mean End of support dates could looks same as Branch date 2021-01-14 15:27:21 exception: ah.. thanks! 2021-01-14 15:27:22 more readable 2021-01-14 15:28:32 i didnt take the time to make the dates green/yellow/red 2021-01-14 15:29:10 ncopa: you were reading my mind :P 2021-01-14 15:29:14 aaand "repository is supported til next stable" should be "till" ? 2021-01-14 15:29:16 ncopa: would have been nice to see mention of new cloud-init packages (as distinct from the Alpine cloud images) 2021-01-14 15:29:16 but I was refraining myself 2021-01-14 15:29:56 minimal: * cloud-init support? 2021-01-14 15:29:57 or similar 2021-01-14 15:30:11 isn't cloud-init a building block for cloud images? 2021-01-14 15:30:27 i havent tested it myself yet, unfortunately, so i don't know how well it works 2021-01-14 15:31:01 i think mcrute (who is maintaining cloud images) is going to take a look at cloud-init 2021-01-14 15:31:38 ikke: yes it is but (a) its not currently used for the new cloud images, and (b) the new cloud images are AWS-only for now whereas cloud-init supports (from memory 20+ providers) so anyone can make their own cloud images for any of those providers 2021-01-14 15:32:25 the nice thing with cloud-init is that most cloud provides have drivers for it 2021-01-14 15:32:29 ncopa: I've reached out to him several times in the past couple of months and had no response :-( 2021-01-14 15:33:02 he is in different timezone 2021-01-14 15:33:36 yupe, tried adding comments to an issue in his project's Github and pinged him on IRC as well 2021-01-14 15:34:44 typos are fixed https://wwwtest.alpinelinux.org/ 2021-01-14 15:35:23 re: 3.13, with cloud-init packaging added in this release someone could make their own Digital Ocean/Hetzner/whatever cloud images today 2021-01-14 15:35:54 do we have any documentation how to do that? 2021-01-14 15:36:20 I can put some together 2021-01-14 15:36:59 ok if I point users who ask for cloud-init in your direction? 2021-01-14 15:37:03 ncopa: I did sent you some notes on this a couple of months ago 2021-01-14 15:37:29 ncopa: sure, I am the package maintainer after all :-) 2021-01-14 15:37:47 yeah, I never took the time to look closer at it. it got down-prioritized, sorry :-( 2021-01-14 15:38:43 in summary: there's a distinction in provided cloud images and providing the tools to build your own cloud-images - 3.13 provides both 2021-01-14 15:39:27 ncopa: "til" -> "till" but imho "until" sounds better 2021-01-14 15:40:40 MY-R: where? 2021-01-14 15:40:47 releases 2021-01-14 15:40:59 MY-R: i do think "till" is correct? 2021-01-14 15:41:07 but im not native english speaking 2021-01-14 15:41:11 I agree until sounds better 2021-01-14 15:41:24 in writing 2021-01-14 15:42:16 https://wwwtest.alpinelinux.org/releases/ updated 2021-01-14 15:42:46 minimal: I added cloud-init to release notes. looks ok? https://wwwtest.alpinelinux.org/posts/Alpine-3.13.0-released.html 2021-01-14 15:42:50 until -> 'until the'? 2021-01-14 15:43:28 This is unrelated to this page but is there a reason for not adding a link in the navbar to the docs site? 2021-01-14 15:44:00 oh, right 2021-01-14 15:44:02 we shoudl do that too 2021-01-14 15:44:12 ncopa: not sure I agree with the wording but let's leave it at that (no point flogging a dead horse) 2021-01-14 15:44:28 what do you suggest? 2021-01-14 15:44:56 not sure what you mean by initial - the packages are complete (until either bugs appear or the next release comes out) 2021-01-14 15:45:39 i mean that this (v3.13) is the first time we support cloud-init 2021-01-14 15:46:17 ok, sorry, misunderstood the wording 2021-01-14 15:46:22 initially in alpine, I guess 2021-01-14 15:47:17 I'm open to better suggestions. if its not clear for you, then its not clear for others 2021-01-14 15:47:48 i added link to docs: https://wwwtest.alpinelinux.org/ 2021-01-14 15:47:59 at the top right navbar 2021-01-14 15:48:09 perfect is enemy of good enough 2021-01-14 15:48:25 exactly :) 2021-01-14 15:48:27 something like "cloud-init packages added to this release to enable building of custom Alpine cloud images" 2021-01-14 15:49:05 ncopa: nice, I wanted to mention docs.a.o earlier but forgot 2021-01-14 15:49:23 minimal: can it be shorter? 2021-01-14 15:49:26 minimal: too much words 2021-01-14 15:49:29 :) 2021-01-14 15:49:30 ha 2021-01-14 15:49:33 btw any reason why links point to git.a.o and not to gitlab.a.o? 2021-01-14 15:49:51 historical i guess 2021-01-14 15:50:02 MY-R: gitlab.a.o is crawling repo 2021-01-14 15:50:17 git.a.o is much faster 2021-01-14 15:50:38 "cloud-init added for building custom cloud images" 2021-01-14 15:50:59 thats better :) 2021-01-14 15:51:27 minimal: with cloud-init you can build something else than cloud images? :P 2021-01-14 15:51:32 word "custom" used to try and avoid confusion with the official cloud images 2021-01-14 15:51:57 mps: yes 2021-01-14 15:52:30 the reasoning behind "inital support" is that it soudns like its not finished. I don't want make people believe that its fully supported, fully working and documented, when its not 2021-01-14 15:52:59 with "initial support ..." it indicates that this is the start, and that there is more to come 2021-01-14 15:53:23 it is ok as it is now, ime 2021-01-14 15:53:24 git.a.o link on 3.13 release page is http not https 2021-01-14 15:53:39 dne: thanks! 2021-01-14 15:53:51 (pet peeve) 2021-01-14 15:54:01 hmm, it is https 2021-01-14 15:54:20 not under CHANGES 2021-01-14 15:55:16 re git vs gitlab 2021-01-14 15:56:02 i think in youg people's minds git == github, so i think it may make sense to use gitlab 2021-01-14 15:56:07 but we have bugs there 2021-01-14 15:56:15 hmm, click on it opens https 2021-01-14 15:56:30 mps is right, git. working faster but maybe just add (GitLab) links after .git 2021-01-14 15:56:46 mps: yeah it redirects 2021-01-14 15:57:24 v3.13 | 2021-01-14 | 3.13-stable (GL-link) | 3.13.0 2021-01-14 15:57:39 not in creating logs for repo 2021-01-14 15:57:58 i'll change "bugs" -> "issues" which points to gitlab 2021-01-14 15:58:11 and keep "git" point to cgit 2021-01-14 15:59:16 please refresh https://wwwtest.alpinelinux.org/ 2021-01-14 16:01:07 one thing on the 3.13 release notes, there are two references to "extended release notes" but they point to different places 2021-01-14 16:04:18 just cosmetic but on https://git.alpinelinux.org/ the address in "Mirror of https://gitlab.alpinelinux.org/alpine" could be link/clickable 2021-01-14 16:05:00 MY-R: can you create an issue for that in infra proj? 2021-01-14 16:05:30 is https://wwwtest.alpinelinux.org/posts/Alpine-3.13.0-released.html good enough now? 2021-01-14 16:06:18 i don't think it's possible (easy) 2021-01-14 16:07:11 ncopa: sure 2021-01-14 16:10:04 im pushing the site updates now to prod 2021-01-14 16:10:10 succes :) 2021-01-14 16:12:41 unrelated issue: someone's just reported an issue on 3.12->3.13 upgrade with a couple of packages I maintain. Seems related to the recent changes/updates to the s6 and skalibs packages. Looking inside one of the packages at the .PKGINFO file I do see a "depend = so:libskarnet.so.2.9" line so wondering why a dependency on skalibs doesn't show up on pkgs.alpinelinux.org 2021-01-14 16:13:30 basically these packages should have been rebuilt when skalibs was updated. 2021-01-14 16:20:27 downloads page still points to 3.12 2021-01-14 16:21:53 waiting till people upgraade vim 2021-01-14 16:31:32 ikke: can you take care of the sync pkgs? 2021-01-14 16:31:41 yes 2021-01-14 16:31:45 working on it now 2021-01-14 16:32:17 ncopa: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/issues/4 ok done, no problem! 2021-01-14 16:33:02 before I raise a MR to force a rebuild of just-envdir & s6-overlay-preinit in build, is there something else I need to do to ensure dependancies are being correctly picked up? The abuild log at the time correctly showed the deps being detected (and so written to .PKGINFO) 2021-01-14 16:33:14 s/build/Edge/g 2021-01-14 16:33:14 minimal meant to say: before I raise a MR to force a reEdge of just-envdir & s6-overlay-preinit in Edge, is there something else I need to do to ensure dependancies are being correctly picked up? The aEdge log at the time correctly showed the deps being detected (and so written to .PKGINFO) 2021-01-14 16:33:49 minimal: bumping it should be enough 2021-01-14 16:34:20 ah, why it posted in "alpine-mksite" and not directly in /infra/ issues, my bad :\ 2021-01-14 16:34:27 ikke: ok. Will do. Still confused why pkgs.alpinelinux.org doesn't show those deps 2021-01-14 16:35:28 ook, sorry and thank you whoever moved it! 2021-01-14 16:36:28 MY-R: not sure if we can make it clickable 2021-01-14 16:37:40 damn, rly? 2021-01-14 16:37:59 limitations of cgit? 2021-01-14 16:39:46 yup 2021-01-14 16:40:22 ikke: ah, so just close it, I thought it would be simple cosmetic change 2021-01-14 16:40:41 I tried it with an tag, but it's escaped 2021-01-14 16:40:49 it's just a field in an ini file 2021-01-14 16:41:17 ncopa: any proof of the last checklist item? :P 2021-01-14 16:51:26 another point to checklist? "Add new release to https://mirrors.alpinelinux.org/" ? :P 2021-01-14 16:52:10 That should happen automatically 2021-01-14 16:52:25 Let me check 2021-01-14 16:54:13 minimal: is there a way to automatically say "rebuild all packages that depend on this shared library"? Because it's a problem I keep running into and I can't be the only one. 2021-01-14 16:54:41 what is the standard operating procedure when a library changes sonames? 2021-01-14 16:56:01 ikke: btw non of the mirrors got version 2.x Alpine, maybe could remove 4 columns to save space? 2021-01-14 16:56:10 skarnet: don't know either. I'm having more issues/fun as a simple rebuild of justc-envdir has failed with an implicit declaration error did not occur previously :-( 2021-01-14 16:56:48 skarnet: use ap recursive-revdeps skalibs-dev 2021-01-14 16:56:51 from lua-aprots 2021-01-14 16:56:56 lua-aports 2021-01-14 16:57:31 I'm not keen on needing lua to handle my packages 2021-01-14 16:57:52 I'd rather recursively grep the aports source 2021-01-14 16:58:47 minimal: send me the error message, I'll be able to tell you where the problem is (if it's in justc-envdir, though, I won't be able to fix it) 2021-01-14 16:59:05 skarnet: Its visible here: https://gitlab.alpinelinux.org/dbradley/aports/-/jobs/293125 2021-01-14 16:59:18 its in justc-envdir itself however 2021-01-14 16:59:34 right, it just hasn't been converted to skalibs-2.10 yet 2021-01-14 16:59:42 converted? 2021-01-14 16:59:55 some APIs have changed (this is what a major bump means) 2021-01-14 17:00:15 it's still using the 2.9 API 2021-01-14 17:00:34 doh! 2021-01-14 17:00:54 pin it to 2.9 until upstream fixes it 2021-01-14 17:00:56 skarnet: this is using the_silver_searcher: ag -G APKBUILD 'makedepends=".*skalibs-dev' 2021-01-14 17:01:10 I guess you can do something with find + grep as well 2021-01-14 17:01:10 skarnet: seems someone flagged this about a month ago: https://github.com/just-containers/justc-envdir/pull/2 2021-01-14 17:01:53 minimal: ah, that's the one. I'll ping them to say the release has been done. 2021-01-14 17:02:16 I'll have to check s6-overlay as well to see if it needs changes too 2021-01-14 17:03:08 IIRC s6-overlay is only scripting, so no problems with skalibs; it may need a few changes to the s6 invocation though 2021-01-14 17:03:38 I'll ping jprjr as well 2021-01-14 17:04:19 skarnet: yeah, I meant s6-overlay-preinit 2021-01-14 17:04:37 I... don't know what that is 2021-01-14 17:05:07 Hi, I'm wondering, is there any reason for the existence and adoption of ifupdown-ng? 2021-01-14 17:05:08 simple priviliged binary for changing uid/gid 2021-01-14 17:05:41 What was the problem with busybox ifupdown or other existing ones? 2021-01-14 17:05:56 sluggo: https://github.com/ifupdown-ng/ifupdown-ng/blob/master/doc/ADMIN-GUIDE.md 2021-01-14 17:06:03 minimal: ah, I see the GH issue on s6-overlay-preinit 2021-01-14 17:06:53 minimal: sorry, I must have somehow missed your messages did you per-chance email me? mike@crute.us 2021-01-14 17:07:05 skarnet: you do? seeing no issues on s6-overlay-preinit 2021-01-14 17:07:29 minimal: in any case ncopa is correct, we're going to start getting cloud-init in the images ready for 3.14... didn't have time to land it for the 3.13 cycle 2021-01-14 17:07:41 ikke I saw that page, but was interesting in some further reading. I'll check their IRC 2021-01-14 17:08:06 mcrute: nope, I'd DM-ed you on IRC in early Dec but also had commented in at least 1 of your projects discussions (about the growpart package) back in Nov from memory 2021-01-14 17:08:09 minimal: no, this is unrelated, it's an old issue that just got reopened 2021-01-14 17:08:14 minimal: oh yeah, I'm in PST so while I hang out here I don't often overlap with most of the dev team... email is best if you don't get a response here 2021-01-14 17:08:36 mcrute: ok, I'll pop you an email 2021-01-14 17:10:26 skarnet: so I'll add that justc-envdir PR patch to the package for now to get it to build. Do you want to raise a PR there for a new version release or want me to do so? 2021-01-14 17:10:40 minimal: yeah I try to be around here but can be hit or miss because of the time diff (most devs are CET I think) 2021-01-14 17:10:48 minimal: looking at the code (it's very small), s6-overlay-preinit should have no problems related to the skalibs API changes 2021-01-14 17:11:29 minimal: in either case would be totally happy to work with you on it... we're planning to build a cloud-init variant of AWS for 3.14 as well as launch GCP and Azure images... tons of stuff to do there and cloud-init will help a lot 2021-01-14 17:11:47 I would have used it for the AWS inmages initially but Alpine support wasn't there and I didn't have time to add it 2021-01-14 17:11:58 skarnet: cool. Haven't tried a s6-overlay-preinit rebuild yet, the justc-env issue got in the way lol. You think there might be some script mods needs for just-overlay as well? 2021-01-14 17:12:25 looking atm 2021-01-14 17:12:39 mcrute: yeah it took a lot of work to get c-i into shape for Alpine and to get it upstreamed. 2021-01-14 17:13:21 skarnet: Just to correct myself, you would want revdep for ap, not recursive-revdeps 2021-01-14 17:13:44 minimal: Thanks! it's great to see that upstreamed, it'll make so much of the cloud image stuff a lot easier :-) 2021-01-14 17:15:02 minimal: for justc-envdir, xpathexec_r() -> xmexec_fm() and that should be it 2021-01-14 17:15:20 now looking at the scripts in s6-overlay 2021-01-14 17:17:07 thanks 2021-01-14 17:19:47 skarnet: atm, these are the revdeps for skalibs-dev: https://tpaste.us/6PLZ 2021-01-14 17:20:53 ikke: thanks. So we have them all: apart from justc-envdir and s6-overlay-preinit, they're all mine and have been bumped at the same time. 2021-01-14 17:27:02 minimal: I see nothing in s6-overlay that needs to be changed immediately, but there *might* be subtle breakage in the execline scripts - not likely, but possible. 2021-01-14 17:27:21 I'll open an issue for jprjr to check all the instances where a change has taken place (I'll help him with that) 2021-01-14 17:27:35 but that shouldn't prevent you from bumping s6-overlay, if there are bugs we'll fix them 2021-01-14 17:28:19 skarnet: thanks for your help 2021-01-14 17:28:45 np, I like to fix the stuff that breaks because of me >.> 2021-01-14 17:28:52 seems from ikke's list that my packages are the only one's depending on your packages 2021-01-14 17:28:57 yes 2021-01-14 17:52:11 minimal: fyi, my message to jprjr: https://github.com/just-containers/s6-overlay/issues/317 2021-01-14 17:53:09 thanks 2021-01-14 17:55:56 Oh nice 3.13.0 is released 2021-01-14 17:55:59 time to upgrade lua :D 2021-01-14 17:56:07 skarnet: re: soname rebuilds 2021-01-14 17:56:31 you can search for those that depend on the soname provided by the package. 2021-01-14 17:56:41 apk list --depends so:libfoo.so.1 2021-01-14 17:57:19 maxice8: thanks, it's exactly what I was looking for :) 2021-01-14 17:58:09 conclusion: please also rebuild libutempter 2021-01-14 17:58:13 I have a script 2021-01-14 17:58:40 http://ix.io/2M1C 2021-01-14 17:59:17 oh, and speaking of utmp, coreutils who *is* linked against utmps now, but it still prints nothing because login is bb's and bb is *not* linked against utmps, so no record is ever written to the db ^^ 2021-01-14 18:00:26 (neither is sshd) 2021-01-14 18:06:19 ncopa: the lua5.4 MR is ready 2021-01-14 18:06:28 skarnet: re: utmp, yeah I started work locally on test-building bb to enable utmp support before Xmas and I think looked at sshd too. Need to get getty (I think) using utmp 2021-01-14 18:13:50 I can never remember if it's getty or login, but anyway it's busybox 2021-01-14 18:14:03 congratulations to the 3.13 release \o/ 2021-01-14 18:14:30 login 2021-01-14 18:16:47 I don't think it is good idea to link anything with utmps lib by default 2021-01-14 18:16:47 skarnet: well I've looked (slightly) into it and if I find the time to get it working I'll raise MRs for it :-) 2021-01-14 18:17:19 mps: by default no, but nothing to stop the adding of an extras subpackage with support 2021-01-14 18:17:31 minimal: that's ok 2021-01-14 18:22:01 well for login and sshd it's either you do or you don't 2021-01-14 18:22:08 and if you're going to support utmp then you need it everywhere 2021-01-14 18:22:20 I don't care either way, but if you're going to do it you better be doing it right 2021-01-14 18:22:33 the plan is Ariadne's btw 2021-01-14 18:23:12 yes, I remember 2021-01-14 18:23:57 this was discussed many times here 2021-01-14 18:25:36 alpine 3.13 announce on phoronix https://www.phoronix.com/scan.php?page=news_item&px=Alpine-Linux-3.13-Released 2021-01-14 18:34:36 clandmeter, you around? 2021-01-14 18:34:36 mps: did you see the 1st question on Phoronix? What's our revenue model? Not sure if is a troll.... 2021-01-14 18:34:40 I've a question re: https://github.com/clandmeter/alpine-netboot/blob/master/boot.ipxe 2021-01-14 18:34:56 how is the item "latest-stable" automatically filled? 2021-01-14 18:34:57 minimal: yes :) 2021-01-14 18:35:48 fcolista: latest-stable on the repos at least is a symlink 2021-01-14 18:36:29 https://dl-cdn.alpinelinux.org/alpine/latest-stable/ 2021-01-14 18:36:39 but how ipxe automatically "fills" that entry in the menu? 2021-01-14 18:37:09 I don't see any reference to latest-stable in the ipxe 2021-01-14 18:39:08 What I read: 2021-01-14 18:39:14 There is a menu with 2 items 2021-01-14 18:39:43 the choose command returns the first element from the item you selected and assigns that to version 2021-01-14 18:40:21 ah ok. 2021-01-14 18:41:19 So the magic happens with "choose". Still I wonder how this can be already filled in the menu if you choose *after* 2021-01-14 18:41:39 What do you mean, "filled in the menu"? 2021-01-14 18:42:32 when ipxe starts and shows the menu, is already written "3.12.3". 2021-01-14 18:42:40 aha 2021-01-14 18:42:42 So the value of lastest-stabile is "filled" with the version 2021-01-14 18:42:49 but this happens *before* you choose. 2021-01-14 18:43:20 Sounds like this ipxe does not provide that 2021-01-14 18:43:24 ipxe script 2021-01-14 18:43:50 phoronix wants to know what alpines revenue model is 2021-01-14 18:44:05 Ariadne: yeah, was mentioned in #alpine-linux 2021-01-14 18:44:15 "johncall" 2021-01-14 18:45:07 fcolista: http://boot.alpinelinux.org/boot.ipxe 2021-01-14 18:48:20 ok so when ipxe starts, enumerates alle the value before showing the menu. Takes that information from boot.alpinelinux.org/boot.ipxe 2021-01-14 18:49:39 not phoronix but one commenter 2021-01-14 19:09:15 "Join Date: Mar 2020" "Posts: 1" 2021-01-14 19:09:16 uh 2021-01-14 19:11:12 hackernews discussion: https://news.ycombinator.com/item?id=25778590 2021-01-14 19:11:12 fcolista: probably you should see https://gitlab.alpinelinux.org/alpine/infra/alpine-netboot instead 2021-01-14 19:11:56 !16545 anyone mind if I hog the edge builders with it ? 2021-01-14 19:12:04 !16546 err 2021-01-14 19:12:11 this one ^ includes libreoffice rebuild, very fun 2021-01-14 19:12:26 yaay 2021-01-14 19:12:36 I guess things are settled now 2021-01-14 19:13:45 is libreoffice working now? i thought it was still broken 2021-01-14 19:14:10 no, it was fixed 2021-01-14 19:14:12 no clue, it builds apparently 2021-01-14 19:14:19 8fac12716006b0f8fdf1a01812f65310e33b7c6c 2021-01-14 19:14:41 Timo Terras worked on that 2021-01-14 19:14:43 ah, ok :) 2021-01-14 19:15:16 i think it's still out of date but that's an improvement 2021-01-14 19:15:35 Updating it is another can of worms 2021-01-14 19:16:19 hm, I forgot to mention... I think docker alpine:edge is broken by default? /etc/apk/repositories has https, but seems like https certificates are not installed by default? 2021-01-14 19:16:33 at least a week ago i had this issue 2021-01-14 19:16:37 I've never had issues with it 2021-01-14 19:16:42 I use alpine:edge a lot 2021-01-14 19:17:01 odd. maybe pebkac then 2021-01-14 19:17:20 is https repository supposed to work ootb? 2021-01-14 19:17:25 yes 2021-01-14 19:17:35 it's using letsencrypt certs 2021-01-14 19:18:35 release date is wrong on main web, 2021-10-14 2021-01-14 19:18:55 heh. we are bleeding edge distribution! 2021-01-14 19:19:08 lol 2021-01-14 19:19:36 Alpine is ahead of the curve 2021-01-14 19:20:00 omni: it is not, all digits are there, though order is somewhat strange :) 2021-01-14 19:20:46 I think that is ISO 8601 2021-01-14 19:24:49 btw, today is first day of new year for julian calendar 2021-01-14 19:25:35 so, happy new year alpine release :) 2021-01-14 19:31:05 can we get the abuild stuff merged now that 3.13.0 is gone ? 2021-01-14 19:48:34 Hello71 thanks for the suggestion 2021-01-14 19:49:05 ok I think i've almost done...something that can be improved is having alpine_repo supporting multiple repositories 2021-01-14 19:49:22 for netboot 2021-01-14 19:49:58 Or I should try http://$fqdn/.boot_repository 2021-01-14 19:50:46 no can't work 2021-01-14 19:50:46 find /media/* -name .boot_repository 2021-01-14 19:53:33 'who' is this rapidswitch in list of our sponsors 2021-01-14 19:53:45 They provide gbr1 2021-01-14 19:53:52 aha 2021-01-14 19:54:07 but I don't see packet.com there 2021-01-14 19:54:13 what's happened 2021-01-14 19:55:05 Don't know, packet was still there in the 3.12 release notes 2021-01-14 19:55:16 but they were bought by equinix 2021-01-14 19:55:26 ah, that explains 2021-01-14 19:55:36 Oh, packet is still there 2021-01-14 19:55:46 "Thanks to GIGABYTE, Linode, Fastly, IBM, Packet, vpsFree and RapidSwitch for providing us with hardware and hosting." 2021-01-14 19:56:19 https://alpinelinux.org/sponsors/ 2021-01-14 19:56:35 right, that's now equinix|metal 2021-01-14 19:57:10 ok, thanks 2021-01-14 20:17:09 lua5.4 is merged 2021-01-14 20:20:44 wow ! 2021-01-14 20:22:10 Next up is poppler (libreoffice rebuild), then boost (massive rebuilds) 2021-01-14 20:22:16 and finally python3 -> 3.9.1 2021-01-14 20:22:34 Ariadne: py3-certifi is good to go ? You asked for it to be held until 3.13.0 is released 2021-01-14 20:24:14 yes 2021-01-14 20:27:01 silly: could the next release have additional numbers of pi instead of point releases? 3.14, 3.141, 3.141, 3.1415, 3.14159.. 2021-01-14 20:27:18 omni: all for 2021-01-14 20:28:15 Hi team, just upgraded a couple of my test systems to 3.13 and have found some packages with wrong signatures, in particular: graphite2, soxr, pcre, p11-kit, libssl1.1, libcrypto1.1. This has happened before a couple of times with the CDN, I think ncopa fixed it last time. 2021-01-14 20:28:30 Terror: do you use latest-stable? 2021-01-14 20:28:38 I do 2021-01-14 20:28:44 right, that explains 2021-01-14 20:28:51 so yes, we need to purge it still 2021-01-14 20:29:11 I'll write something that purges everything 2021-01-14 20:29:16 for latest-stable 2021-01-14 20:29:36 Yup, that did it btw (thank goodness for fast internet) 2021-01-14 20:31:39 Changing to v3.13 I mean. 2021-01-14 20:32:36 omni: isn't next alpine 4 ? 2021-01-14 20:42:27 ddevault is so quick 2021-01-14 20:43:03 it's my job 2021-01-14 20:43:34 what did I miss? 2021-01-14 20:43:48 less than 1 minute to approve MR 2021-01-14 20:43:52 aha 2021-01-14 20:43:59 approve-mr any% 2021-01-14 20:44:31 I can assure you that I'm even faster at reviewing emails ;) 2021-01-14 20:44:48 is self-approving allowed? 2021-01-14 20:44:53 Yes 2021-01-14 20:45:04 though, it inflicts a 7 day delay 2021-01-14 20:45:04 I do like to post the Obama giving Obama the medal image whenever someone does that though 2021-01-14 20:46:20 Self-approval strat, which saves over half a second and first was implemented in an actual run by Obama 2021-01-14 20:46:37 https://ficklemind.com/wp-content/uploads/2019/07/Best-Of-Obama-Awards-Obama-A-Medal-Memes-from-reddit-11.jpg 2021-01-14 20:46:38 But first, we need to learn how time is counted 2021-01-14 20:46:55 s390x is big endian correct? 2021-01-14 20:47:03 yes 2021-01-14 20:47:30 thanks 2021-01-14 20:48:52 Gitlab checks for new approvals every 5 seconds, so runner needs to be fast enough to fit into that timeframe. Imagine it like a bus stop, where bus arrives every 5 seconds. If you got just in time, you won't lose any time, but if you get late by one second, you will lose 5 seconds 2021-01-14 20:49:06 i think that might have been too long of a message for irc 2021-01-14 20:52:17 any objections to !16546 ? 2021-01-14 20:52:25 It will block the builders for a bit with the huge libreoffice rebuild 2021-01-14 20:52:37 go ahead 2021-01-14 20:53:27 done 2021-01-14 21:02:13 maxice8: I've just seen ppl talk about 3.14 2021-01-14 21:03:00 gitlab Dark Mode really is alpha, everything is fine except the header that is light on light background 2021-01-14 21:03:36 is it ? I see nothing wrong except they use blue instead of purple for merged MRs 2021-01-14 21:04:42 ye it is 2021-01-14 21:05:24 I logged out and in again and it's fine now 2021-01-14 21:08:24 ah so not that 2021-01-14 21:08:40 I have here after parent: some weird colors: https://i.imgur.com/VivECPN.png 2021-01-14 21:09:17 same here 2021-01-14 21:26:25 https://lists.alpinelinux.org/~alpine/devel/%3C86c7a81e-1640-7f82-9e13-dfdbe1aad07b%40gmail.com%3E Any more consensus on this ? 2021-01-14 21:29:02 is this useful 2021-01-14 21:30:02 to quote 'as other distros'. do we need to do things as other distros? 2021-01-14 21:30:26 sometimes yes, sometimes no 2021-01-14 21:30:51 in exceptional cases, libusb0 2021-01-14 21:31:09 which doesn't work well, btw 2021-01-14 21:32:01 I think from a library standpoint, there is no reason why you couldn ot have 2 version of a library installed, rihgt? 2021-01-14 21:32:10 they already have versioned names 2021-01-14 21:32:35 yes for most of them 2021-01-14 21:32:35 the major drawback atm is that we need to duplicate APKBUILDs 2021-01-14 21:33:22 the benefits and drawbacks are mostly described in the original mail 2021-01-14 21:33:34 skimming through it 2021-01-14 21:33:40 a question, i write some library, from a distro packaging PoV what would you prefer, language bindings (py, php, js, etc) in the same git repo, or separately? 2021-01-14 21:34:08 Ikke: libraries with different major versions are meant to be parallel-installable, unfortunately only Freedesktop libraries care abou it, which is why you see libfoo-1.0.so.1 (the 1.0 being a namespace) and they also install headers in foo-1.0 and have pkgconfig handle the correct include. 2021-01-14 21:34:48 everything have benefits and drawbacks. we should 'know' what we want: small, simple or something else 2021-01-14 21:34:51 but what about having libfoo.so.1 and libfoo.so.2? 2021-01-14 21:34:55 I know for me 2021-01-14 21:35:56 Ikke: that will have problems if foo-1.0 suddenly has to upgrade their ABI 2021-01-14 21:36:45 yZ5vlALg86IP: depends, are the bindings official and upgraded in lockstep with the project ? 2021-01-14 21:36:51 ok, so I see i'm conflating things 2021-01-14 21:37:48 yeah, official and matching with the project of course, if in the same repo. if separate repos, i guess the coupling would be less strict... 2021-01-14 21:38:21 then It would be best if they could be built together with the main project --enable-python-bindings or something similar 2021-01-14 21:38:56 what does the minor version in a soname signify? 2021-01-14 21:39:04 libfoo.x.y 2021-01-14 21:39:33 I have no clue I guess ABI changes that do not break backwards compat (like adding new symbols) 2021-01-14 21:40:13 usually yes 2021-01-14 21:45:34 Meson projects always increment the so version to mirror the project version 2021-01-14 21:45:39 (by default at least) 2021-01-14 21:45:57 So libfoo.so.2.4.1 was built by foo v2.4.1 2021-01-14 21:46:31 right, but that implies the project is using semver 2021-01-14 21:46:39 on an ABI level 2021-01-14 21:46:44 Yup 2021-01-14 21:57:58 yes 2021-01-14 22:20:08 why is tmpfs rootflags set to mode=0755? https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L578 2021-01-14 22:20:47 is it mostly a placeholder for when $KOPT_rootflags isn't set or does it have another purpose? 2021-01-14 22:22:18 I'm looking at it to see if I should do something similar for overlaytmpfs 2021-01-14 22:24:39 hmm.. introduced here https://gitlab.alpinelinux.org/alpine/mkinitfs/-/commit/666c4d431cd585ce45df93bef58ada648bf88b55 2021-01-14 22:25:00 so I think I understand why and this should also be implemented for overlaytmpfs 2021-01-14 22:26:05 I think..? 2021-01-14 22:36:14 I want to merge !16850 in a few hours 2021-01-14 22:39:19 aarch64/armv7 builder is 'load average: 52.17, 20.15, 9.39' so I don't plan to do any work on them 2021-01-14 22:39:44 so, do it 2021-01-15 00:48:50 boost rebuild in 12 minutes 2021-01-15 01:04:22 started with the right foot lol 2021-01-15 01:10:13 yZ5vlALg86lP: this isn't really a linux distro question, it's more of a software design question. if you put it in the same repository it has "tight coupling", and generally needs to match the same version. if you put it in a separate repository then it has "loose coupling", and you generally need to define a stable API and have API version checks and whatnot 2021-01-15 01:11:03 ikke: afaik the only rule on Linux is that you can't mix major versions. I think on some old Unix-like systems there is some effect 2021-01-15 01:16:07 algitbot: retry master 2021-01-15 01:51:17 algitbot: retry master 2021-01-15 01:58:21 maxice8: lucene++'s src url has the version hardcoded 2021-01-15 01:58:51 noted 2021-01-15 02:14:46 congrats on the release 2021-01-15 02:14:52 :D 2021-01-15 02:15:25 sorry i didnt get 1.2.2 official out in time; sorting thru new sponsors for credit got drawn out longer than i expected 2021-01-15 02:15:29 which is a good thing :) 2021-01-15 02:16:22 up to 19 who get credit in release announcements now 2021-01-15 02:19:10 grats on the new sponsors 2021-01-15 02:19:22 also poor builders, just finished libreoffice and now must rebuild all boost reverse dependencies 2021-01-15 02:19:58 Unfortunately I won't have python3.9 (which requires all python-modules to be rebuilt) in time to chain them 2021-01-15 02:20:03 boost your CPU usage 2021-01-15 02:20:43 I'm already playing a Paradox Interactive Grand Strategy in the background 2021-01-15 02:20:47 my CPU is abused enough 2021-01-15 04:00:55 algitbot: retry master 2021-01-15 04:11:46 algitbot: retry master 2021-01-15 04:39:27 huh 2021-01-15 04:39:32 /usr/lib/gcc/i586-alpine-linux-musl/10.2.1/../../../../i586-alpine-linux-musl/bin/ld: cannot find -lbz2 2021-01-15 04:39:32 /usr/lib/gcc/i586-alpine-linux-musl/10.2.1/../../../../i586-alpine-linux-musl/bin/ld: cannot find -llzma 2021-01-15 04:45:04 Doesn't happen on x86_64 2021-01-15 04:45:14 algitbot: retry master 2021-01-15 04:54:44 i really need to figure out how to get alpine to let me upgrade packages :/ 2021-01-15 04:55:16 afaict any -dev package permanently holds back the base package at the version of the -dev 2021-01-15 04:55:40 until you find all the offending -dev packages and upgrade them in unison, or remove them 2021-01-15 05:01:15 algitbot: retry master 2021-01-15 05:01:29 CMake needs a Requires: 2021-01-15 05:05:46 musl 1.2.2 release is now up :) 2021-01-15 05:06:04 Ariadne ^ 2021-01-15 05:12:10 shouldn't it be `parent' in this part of the WHATSNEW ? -> fork of process with active aio could deadlock or crash paren 2021-01-15 05:14:00 algitbot: retry master 2021-01-15 05:14:34 How do i change font size (increase) 2021-01-15 06:12:46 I figured it out 2021-01-15 06:12:49 I created a file called usercfg.txt and put in hdmi_group=2 (new line) hdmi_mode=3 2021-01-15 06:16:38 algitbot: retry master 2021-01-15 07:54:38 I forgot for yesterday notes about exfat drivers and tools change 2021-01-15 07:55:23 hope it will work 'out-of-the-box' on upgrades 2021-01-15 08:02:24 morning 2021-01-15 08:02:58 0o/ 2021-01-15 08:23:14 Hi team, seems util-linux-2.36.1 have a bug that stop cifs mounts 2021-01-15 08:23:37 CIFS: Unknown mount option "symfollow" 2021-01-15 08:26:13 There's a patch: https://github.com/karelzak/util-linux/commit/76bb9b30cfcf54b59591a57a3d2a747e514469b2 2021-01-15 08:26:30 aha, so an upstream issue 2021-01-15 08:26:47 Can you make an issue on https://gitlab,alpinelinux.org/alpine/aports? 2021-01-15 08:26:58 Or make a merge request 2021-01-15 08:27:01 I can try, of course 2021-01-15 08:30:19 Is there a simple way to sync my aports fork with upstream (sorry, not a git person :o) 2021-01-15 08:30:48 git remote add upstream git@gitlab.alpinelinux.org:alpine/aports.git 2021-01-15 08:30:52 So you have your own branch with custom changes? 2021-01-15 08:30:56 git pull upstream master --rebase 2021-01-15 08:31:00 Oh, you mean gitlab fork 2021-01-15 08:31:07 Yup, gitlab 2021-01-15 08:31:17 I contributed some aports in the past 2021-01-15 08:31:20 (blame github for overloading the word fork) 2021-01-15 08:34:24 OK, I'll try that. There should be a way that doesn't require to pull and push half a gig of data. 2021-01-15 08:47:59 hey there! i've been maintaining a few packages in alpine for about 8 months, and was wondering what the process is to become an alpine committer 2021-01-15 08:48:36 (community/doctest, community/notcurses, testing/growlight) 2021-01-15 08:48:55 sosodank: you are nick black? 2021-01-15 08:49:14 i am 2021-01-15 08:49:19 hi :) 2021-01-15 08:49:33 hello mps, thanks for all the merges :) hello also to Ariadne and a few others 2021-01-15 08:49:34 sosodank: continue contributing, review other merge requests 2021-01-15 08:49:55 there is no 'process' to get commit rights 2021-01-15 08:49:57 sosodank: we have a new (starting team) called team/mentors on gitlab 2021-01-15 08:49:57 cool, is it more of a nomination model ala arch/freebsd than a procedural model ala debian? 2021-01-15 08:49:59 ok got it 2021-01-15 08:50:06 Failed (did I mention that me and git don't get along?). I'll remove my gitlab fork and start from scratch (my usual MO when it comes to git). 2021-01-15 08:50:27 sosodank: We are still figuring out how to do it in the future 2021-01-15 08:50:27 that's what i figured =] ok, i shall continue doing what i'm doing then =] thanks for the unique and useful take on linux, and congrats on the 13.0 release! 2021-01-15 08:50:38 but right now it's indeed nominotional 2021-01-15 08:51:19 sosodank: fixing issue and helping on fixing bugs, improvement of pkgs and other helps are what counts 2021-01-15 08:51:20 sounds good, thanks for the clarification all, and also thanks for the kindness and patience on gitlab. help from alpine found and eliminated a deep bug in notcurses, for which i'll be forever grateful 2021-01-15 08:51:25 y'all have a good evening, hack on 2021-01-15 08:51:54 [22:05] <e91e63dalias> musl 1.2.2 release is now up :) 2021-01-15 08:52:03 I'll deal with it when I wake up 2021-01-15 08:52:04 Ariadne: yes 2021-01-15 08:52:11 Ariadne: nice 2021-01-15 08:52:56 not sure could it be 'simply' backported to 3.13 2021-01-15 08:53:10 mps: we are effectively already using 1.2.2 2021-01-15 08:53:16 minus a few commits perhaps 2021-01-15 08:53:21 except _Fork 2021-01-15 08:53:44 hmm? 2021-01-15 08:53:46 which is important change 2021-01-15 08:54:40 'The release adds the _Fork function from the upcoming edition of POSIX' 2021-01-15 08:54:41 You mean the mt-fork fix? 2021-01-15 08:54:47 aha 2021-01-15 08:55:18 anyway, worth to try to backport it 2021-01-15 08:56:01 and I will try for sure, but not right now. have other things to do 2021-01-15 08:57:47 'wcsnrtombs' is fix for CVE, have to look is it already in current musl in 3.13 2021-01-15 09:02:28 Issue created: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12306 2021-01-15 09:05:06 Can somebody point me to an explanation of "Berkley DB has been deprecated due to licensing issues." in https://alpinelinux.org/posts/Alpine-3.13.0-released.html ? 2021-01-15 09:06:37 it's AGPL now 2021-01-15 09:07:03 we can't ship that as AGPL it would make everything that touches it also AGPL 2021-01-15 09:08:50 Ariadne: can you take a look at boost on mips64 ? https://build.alpinelinux.org/buildlogs/build-edge-mips64/main/boost/boost-1.75.0-r2.log 2021-01-15 09:08:56 morning 2021-01-15 09:09:03 morning ncopa 2021-01-15 09:09:19 Ariadne: eh, no. If that was true no Linux distro could ship AGPL-3 code 2021-01-15 09:09:47 but thanks for explaining the reasoning 2021-01-15 09:10:20 we can ship AGPL-3 code that isn't a library 2021-01-15 09:10:23 it's our policy 2021-01-15 09:10:46 too much for me to catch up in the channel :) 2021-01-15 09:11:12 don't sleep too much :) 2021-01-15 09:11:14 ncopa: TLDR I am doing the boost rebuild 2021-01-15 09:11:44 ikke: i celebrated yesterday by turning off the compputer. I think I'll continue the celebration today by skiing. its beautiful weather today 2021-01-15 09:11:44 the builders will keep trying master until build success rates improve 2021-01-15 09:12:15 maxice8: i saw the email about keep the major version number in libraries package names 2021-01-15 09:12:40 i will respond eventually, but in general, i don't want to do that always, for everything 2021-01-15 09:13:02 but it definitively makes sense for some packages 2021-01-15 09:13:12 and for gcc dependencies it is a requirement 2021-01-15 09:13:28 Like boost and packages that upstream supports it fully like GNOME libraries 2021-01-15 09:13:34 or anything in the build-base 2021-01-15 09:13:38 @ncopa enjoy the snow 2021-01-15 09:14:08 skarnet: apk list --depend is what I use for finding what needs to be rebuilt on ABI breakage 2021-01-15 09:14:12 terror: thanks 2021-01-15 09:14:26 uh, that reminds me that I didn't went to skiing in last four years 2021-01-15 09:14:32 http://ix.io/2M1C I have this scripts to print them neatly 2021-01-15 09:14:40 in a for-loopable way 2021-01-15 09:14:58 If someone can take a look and merge https://gitlab.alpinelinux.org/alpine/aports/-/issues/12306 it'd be great. It's quite a blocking bug (no CIFS mounts) 2021-01-15 09:15:02 and this season ski center are closed 2021-01-15 09:15:24 for pkg in $(depends so:libfoo.so.1); do apkgrel -a $(find_repo $pkg); done 2021-01-15 09:15:28 i pipe it to sed soemthing and | xargs ap builddirs, which gives me the list of aports in build order 2021-01-15 09:16:08 http://ix.io/2M5h this is `find_repo` 2021-01-15 09:16:09 terror: can you post a link to where the patch is upstream? it saves time for us 2021-01-15 09:16:38 Done 2021-01-15 09:17:12 #12306 2021-01-15 09:17:13 maxice8: i am thinking of writing tools for parsing the aports tree in go, so we dont depend on a zillion lua dependencies 2021-01-15 09:17:46 terror: i'll have a look at it now 2021-01-15 09:18:04 oh, one thing more... 2021-01-15 09:18:19 *thank you* to everyone helping getting 3.13 out 2021-01-15 09:18:58 it was a bit tricky to get get it out, late unexpected breakages etc, and a fight against the clock, but thanks to all of you we made it a success :) 2021-01-15 09:19:01 hmm, why? it is our pleasure 2021-01-15 09:19:09 ncopa: good to know about the go-tooling 2021-01-15 09:22:31 mps: i must admit that the 3.13 release made me feel a bit stressed, and it is very nice to have "helping hands", feel that someone is supporting. means alot to me 2021-01-15 09:24:54 whoops, i pushed the util-linux to 3.13-stable 2021-01-15 09:24:55 I understand your care for your 'baby' 2021-01-15 09:25:27 sometimes it feels like we are waling in mud, uphill 2021-01-15 09:25:38 things breaks faster than we manage to fix 2021-01-15 09:26:25 Thanks @ncopa!! 2021-01-15 09:26:34 also I care (or at least trying) but there are no perfect things, everything have some quirks and sometimes serious problems and we have to learn to live with them 2021-01-15 09:26:36 sometimes it is due to upstream, sometimes it is due to unexperienced contributors, sometimes its lack of tooling, sometimes its pure "unluck" 2021-01-15 09:26:57 yeah, exactly. the trick is to find where "good enough" is 2021-01-15 09:27:05 You run a tight ship. Been my daily driver for 5 or 6 years now and wouldn't change Alpine for any other distro I've used. 2021-01-15 09:27:49 terror: im glad you like it 2021-01-15 09:28:19 only for me, I will try to keep it small, simple and secure as much as it is possible nowadays 2021-01-15 09:32:38 ncopa: not a bad plan :) 2021-01-15 09:33:59 ncopa: for atools-go, I already have some code that statically parses sh files 2021-01-15 09:34:11 including evaulation global variable values 2021-01-15 09:35:39 @ncopa, that fix worked fine. CIFS is back. 2021-01-15 09:35:44 delete mode 100644 main/boost/boost-fiber-mips64-ftbfs.patch 2021-01-15 09:35:45 uhhh 2021-01-15 09:36:32 terror: awesome. i love trivial fixes :) 2021-01-15 09:37:01 Ariadne: fun 2021-01-15 09:38:21 well, hopefully that is all that is needed 2021-01-15 09:39:09 thanks 2021-01-15 09:41:52 pushing musl 1.2.2 to edge, DO NOT backport this one because it enables faccessat2 2021-01-15 09:44:32 doing a separate 1.2.2 backport to 3.13 2021-01-15 09:46:17 ok. Thank yo ufor taking care of it 2021-01-15 09:47:31 Is there a way to make build.alpinelinux.org stop moving the builder view up and down 2021-01-15 09:47:52 build-edge jumps from #1 -#7 to the last fields and I need to scroll up and down whenever it happens 2021-01-15 09:50:22 its javascript 2021-01-15 09:50:28 pretty simple scripts 2021-01-15 09:50:34 they could need some love... 2021-01-15 09:51:10 i wonder what to do with dovecot security issues https://gitlab.alpinelinux.org/alpine/aports/-/issues/12274 2021-01-15 09:51:41 we could upgrade to 2.3.13 on 3.11-stable and 3.10-stable 2021-01-15 09:51:58 or we could find the patch for CVE-2020-24386 2021-01-15 09:52:04 finding the patch does not seem to be trivial 2021-01-15 09:53:31 Some projects just don't want to be secure 2021-01-15 09:54:02 unfortunately for us, dovecot is the only imap server worth a shit 2021-01-15 09:54:14 CVE-2020-24386 for dovecot is not serious, so we don't need to hurry 2021-01-15 09:54:15 i think upstream sometimes wants downstream to push new features 2021-01-15 09:54:42 mps: ahh, but the FUD people will shame us 2021-01-15 09:54:42 I will ask upstream today later 2021-01-15 09:54:49 i want fix dovecot today 2021-01-15 09:54:55 they will be like 2021-01-15 09:55:05 ALPINE HAS OPEN CVEs USE UBUNTU INSTEAD 2021-01-15 09:55:07 just update to latest unstable 2021-01-15 09:55:10 ha 2021-01-15 09:55:21 now I'm busy with some important job 2021-01-15 09:55:35 (gee, no idea where those people come from) 2021-01-15 09:55:52 (hint: the people paying for that astroturfing have a jet with a dragon mascot on it) 2021-01-15 09:56:12 who cares for them :P 2021-01-15 09:56:29 sometimes people buy into the FUD 2021-01-15 09:56:37 it is a concern 2021-01-15 09:57:10 there is also "alpine doesn't have a security database" even though ours is the only machine readable one you don't have to pay for 2021-01-15 09:57:31 maybe thats the problem. thy dont need to pay for it 2021-01-15 09:57:49 ok we charge for it and become gartner magic quadrant leader 2021-01-15 09:57:56 :) 2021-01-15 09:57:57 lol 2021-01-15 10:01:08 oh, there are more unresolved dovecot issues 2021-01-15 10:01:17 i think I'll just upgrade it 2021-01-15 10:02:06 debian has patched it in 1:2.2.27-3+deb9u7 and 1:2.3.4.1-5+deb10u5 2021-01-15 10:10:23 https://salsa.debian.org/debian/dovecot/-/commit/06dd33e4a2bc54bebe1db002ef8db84a3c5eff9d#ea8c8cccfa102e9509b18836683bce08bfaa68fd 2021-01-15 10:11:47 now that's some magic quadrant leadership 2021-01-15 10:16:08 Why is docker not part of the 1.13 release when it's available in 1.12 and edge? https://pkgs.alpinelinux.org/packages?name=docker&branch=v3.13&arch=x86_64 2021-01-15 10:16:22 My bad 3.13 2021-01-15 10:19:34 hc-hmk: apparently still need to fix something for pkgs.a.o 3.13 2021-01-15 10:19:38 https://pkgs.alpinelinux.org/packages?name=&branch=v3.13 2021-01-15 10:19:41 it lists no packages at all 2021-01-15 10:19:49 although syncing finished 2021-01-15 10:20:59 Okay, so docker *is* available, the online package viewer is just broken? 2021-01-15 10:25:41 not up-to-date 2021-01-15 10:34:25 Gitlab user search or our instance's is so bad 2021-01-15 10:34:36 it is frustratingly terrible 2021-01-15 10:35:12 The issue is that gitlab only autocompletes project members 2021-01-15 10:38:14 so unfortunate 2021-01-15 10:39:40 You can mention everyone, but you have to explitily type out their username 2021-01-15 10:41:36 Yes which is unfortunate because some people commit under X and their username is completely unrelated 2021-01-15 11:00:38 hc-hmk: can you check if its ok now? 2021-01-15 11:05:12 clandmeter: It works just fine now. Thanks! 2021-01-15 11:05:36 FYI the wiki hasn't been updated yet. https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases 2021-01-15 11:09:16 should be part of the release process. 2021-01-15 11:09:32 ncopa: ^ 2021-01-15 11:09:40 I've added it to the checklist 2021-01-15 11:10:01 it was not on it yet? 2021-01-15 11:10:06 i remember it was on the old wiki 2021-01-15 11:22:16 Is chromium 86 on 3.13 built with ozone / wayland support enabled? I cant tell from either the log or git tree 2021-01-15 11:22:33 It's built w/o Ozone 2021-01-15 11:22:41 Since Ozone still seems to be kind of crashy on X11 2021-01-15 11:24:12 Aw, that's unfortunate. 2021-01-15 11:26:04 According to some posts on reddit, some builds can enable and disable Ozone with a command line flag at runtime. Is it possible for you to enable that feature on the alpine build? 2021-01-15 11:26:45 To be honest, dunno, maybe you could look into that :) 2021-01-15 11:27:26 clandmeter: it's not that it was forgotten, just that it was not clear how to properly do i 2021-01-15 11:27:28 it 2021-01-15 11:27:41 Or maybe a separate package, chromium-ozone? I remember seeing it on either redhat repos or aur 2021-01-15 11:28:17 That won't fly, we already have trouble keeping chromium up-to-date 2021-01-15 11:28:29 So unless someone steps up to maintaining both chromium and that new variant it wont happen 2021-01-15 11:30:29 Fair 2021-01-15 11:32:47 I found the switches for enabling ozone. Adding the following to APKBUILD at line 251 should do the trick. use_ozone=true \ ozone_platform_wayland=true \ ozone_platform_x11=true \ ozone_auto_platforms=false 2021-01-15 11:33:15 If I can get local builds to work on alpine with ozone, will you accept a merge request for the feature? 2021-01-15 11:34:44 hc-hmk: ozone is compiled by default in v87+ 2021-01-15 11:36:49 Yep, I know. It can be explicitly enabled on 86 with a few flags. 3.13 uses 86. 2021-01-15 11:37:32 i thought it's either ozone or x11 backend 2021-01-15 11:38:12 so they're mutually exclusive 2021-01-15 11:40:11 in other words, 87 is the version that supports building both the ozone and x11 backends 2021-01-15 11:40:12 That may very well be. 2021-01-15 11:41:34 Is there anything preventing us from updating chromium from 86 to 87, aside from putting in the work? 2021-01-15 11:41:42 Nop 2021-01-15 11:42:00 An active maintainer for Chromium would be pretty neat in general 2021-01-15 11:42:08 So if I get 87 running, based on the current patchset and APKBUILD script, that'd be good? 2021-01-15 11:42:48 Sure 2021-01-15 11:43:16 But I can assure you that you'll probably need to adjust the patches, they usually don't apply with new versions 2021-01-15 11:44:35 I get that. Probably especially the musl stuff, since 3.13 ships with musl 1.2 2021-01-15 11:45:05 I don't think musl 1.2 made that any harder than older musl versions 2021-01-15 11:45:43 I'm not at all familiar with the alpine APKBUILD system. Is the build procedure just running the APKBUILD script? 2021-01-15 11:46:07 abuild is the script you run, it uses the APKBUILD 2021-01-15 11:46:37 I dont see a file named abuild in the tree. Is it a separate program? 2021-01-15 11:46:40 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package 2021-01-15 11:46:44 hc-hmk: yes 2021-01-15 11:46:49 Alright 2021-01-15 12:02:50 I updated https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases 2021-01-15 12:03:08 its now generated and moved to https://alpinelinux.org/releases 2021-01-15 12:05:01 https://dl-cdn.alpinelinux.org/alpine/v2.1/ 2021-01-15 12:05:08 it seems that some old versions aren't on some mirrors 2021-01-15 12:08:30 2.x is only on ancient 2021-01-15 12:10:57 ikke: did you purge latest-stable on dl-cdn? 2021-01-15 12:11:03 ncopa: not yet 2021-01-15 12:12:48 ikke: is really hard to find this link http://ancient.alpinelinux.org could be in 'release' page and in 'downloads' 2021-01-15 12:13:10 ikke: i have this script: https://tpaste.us/Lwam 2021-01-15 12:13:47 and it looks like I have some work-in-progress for a go implementation 2021-01-15 12:16:12 MY-R: oh god i've been looking for this 2021-01-15 12:16:19 thanks!!!!!!!!!!!!!!!!!! 2021-01-15 12:16:43 i'd like to move it to a place with better bandwidth before we make it more visible 2021-01-15 12:18:03 iso for alpine 1.1 is missing though :( 2021-01-15 12:20:38 ikke: im purging dl-cdn cache now 2021-01-15 12:20:52 insep_: any good reason to use the first release 1.1 ? 2021-01-15 12:21:36 i'm just interested in such historic relic 2021-01-15 12:23:32 i think i have a cdrom somwhere around here with alpine 1.0 2021-01-15 12:23:34 so maybe not missing but wasnt even generated in that time 2021-01-15 12:23:54 damn... 2021-01-15 12:24:46 found this: old/backup/alpine-0.1.0-20050105.iso 2021-01-15 12:24:48 :) 2021-01-15 12:25:58 is there a tool to auto bump pkgrel? 2021-01-15 12:26:42 ncopa: museum.alpinelinux.org would be good link for that :D 2021-01-15 12:27:59 afontain_: apkgrel -i 2021-01-15 12:28:22 basically, a lot of packages haven't been bumped since boost 1.75 2021-01-15 12:29:08 Ariadne: where can I find it? 2021-01-15 12:32:21 ah, abuild package 2021-01-15 12:37:49 https://dev.alpinelinux.org/~ncopa/alpine/alpine-0.1.0-20050105.iso 2021-01-15 12:38:52 afontain_: abump -h 2021-01-15 12:38:53 I'd like to report that libmodbus, which we requested be added to alpine somewhere late 2019, has been working flawlessly since we put it into use. It's still in the testing repo though, which I don't think is necessary any more. If someone would like to move it to main or community, I think it's more than ready. 2021-01-15 12:54:43 hc-hmk: moved libmodbus 2021-01-15 12:54:45 to community 2021-01-15 12:55:11 Great :) 2021-01-15 12:55:38 will be avilable in alpine 3.14 unless i backport it to 3.13 2021-01-15 12:58:20 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16873 2021-01-15 13:09:52 dalias: I think you can do this with apk upgrade -l 2021-01-15 13:19:22 just noticed, screen depends on utmps, not good change 2021-01-15 13:20:01 and coreutils, even worse 2021-01-15 13:23:51 as I recall, you don't have to actually *use* utmps 2021-01-15 13:29:31 even if the clients are linked against utmps, if the daemons are not running, nothing will happen 2021-01-15 13:29:42 the function will just return nothing, just like the musl stubs 2021-01-15 13:29:57 so it's safe 2021-01-15 13:33:21 if I was satisfied with (unneeded) 'dependencies hell' on debian I wouldn't switch to alpine 2021-01-15 13:35:11 anyone against reverting these things 2021-01-15 13:47:01 we can transition it to static linking 2021-01-15 13:49:58 I'm not in hurry, though maybe sounded that I'm angry. I'm not no worries 2021-01-15 13:50:55 we can look what option we have, to have utmps and to not install it 'by default' 2021-01-15 13:51:48 wouldn't static linking increase the install size 2021-01-15 13:57:22 can someone tag !16816 and !16857 so as to be included in 3.13.1? 2021-01-15 14:52:15 [07:51] wouldn't static linking increase the install size 2021-01-15 14:52:17 minimally 2021-01-15 14:53:26 well I'm saying if your concern with the deps is the increased size 2021-01-15 14:53:38 then wouldn't static linking make it worse 2021-01-15 14:54:05 i don’t think that’s the concern 2021-01-15 14:54:23 i think it is β€œhaving to bump all these things due to utmps” 2021-01-15 14:55:32 I guess there's different expections/concerns depending on use - for a desktop system utmps might not be of interest to people, for server use I'd expect some, if not many, would like to have working utmps support. 2021-01-15 14:57:46 is utmps expected to frequently change abi? i would have expected it to remain relatively static considering that the api is basically fixed 2021-01-15 15:22:49 Hello71_: don't think utmps' ABI will change often. mps' point was one of increased size of coreutils/busybox/sshd/other packages if/when utmps is added (whether size refers to binary size when statically linked or disk size due to increased dependant packages installed) 2021-01-15 15:23:55 minimal: not much increased size (it is minimal, :-) ) but why to have installed packages which are mostly not needed 2021-01-15 15:41:35 Then everything would have to be split into foo and foo-utmps packages, with utmps being a magic package like docs that pulls in *-utmps 2021-01-15 15:44:42 detha: right option is to patch musl, but I doubt it will happen 2021-01-15 15:45:22 (and not complicate things too much) 2021-01-15 15:45:54 if we 'want' utmp support on alpine 2021-01-15 16:02:02 It was one of the first things I missed in a default install, but everybody's use case differs 2021-01-15 16:10:08 also this was one of the first my questions when I switched to alpine, but after reading daliass reasoning about this I didn't asked for it anymore 2021-01-15 16:11:01 I was one of the 1st things I noticed too, after having to get used to using "poweroff" rather than "shutdown" :-) 2021-01-15 16:15:31 utmps definitely won't change ABIs often, it's just that once in a while skalibs does and needs a soname bump. libutmps depends on skalibs, but not on a part of it that is likely to change 2021-01-15 16:16:17 tbh you could probably link against libutmps+libskarnet statically and it would be a *very* minimal size increase 2021-01-15 16:17:18 also I keep getting baffled by the wishy-washiness of this community 2021-01-15 16:17:56 are you as hesitant and unsure about all the other software you are integrating? 2021-01-15 16:18:21 do you keep saying yes, then backing up, then going forward again, but with a half-step? 2021-01-15 16:18:54 wishy-washiness? Like most communities there's a range of viewpoints and of uses being made of Alpine so there's a natural "conflict" between some peoples' wishes 2021-01-15 16:20:19 its trying to find a reasonable midpoint - I want utmpx for audit purposes on servers but realise that some/many people using desktops or embedded systems don't want it or like any complexity it might add 2021-01-15 16:21:34 again, the client library is super simple, adds a few kB at most if you link statically, and won't do anything if the daemons aren't running 2021-01-15 16:21:35 utmps is happening, but static linking is probably the best way 2021-01-15 16:21:46 people who don't want it just don't have to run the daemons 2021-01-15 16:22:02 and everything will 'work' like before, doing nothing 2021-01-15 16:22:03 i wonder though if dalias would be open to integrating the client side into musl directly now 2021-01-15 16:22:06 at least it's not pam… 2021-01-15 16:22:51 dne: I tried doing the same thing with pam as I did with utmp, and my part is working, but it cannot be used by most pam users 2021-01-15 16:22:53 anyway mps complaint is about depgraph size not disk size 2021-01-15 16:23:30 dne: the problem with pam is that applications *rely on* libpam being in the same address space and doing global data modification, so isolating libpam actually breaks them 2021-01-15 16:24:24 skarnet: I'm not actually disagreeing with you (I have the utmpx daemons already running here), just pointing out the range of viewpoints 2021-01-15 16:24:44 right (anyway I don't have a problem with utmps) 2021-01-15 16:28:14 ariadne, i haven't looked at the protocol enough to give an answer 2021-01-15 16:30:26 dalias: hmu some time next week, but I don't think integrating stuff into the libc just because a distro looks down on one dependency is a good precedent 2021-01-15 16:32:35 Ariadne: it's precisely about depgraph size that I find mps (and maybe others) unjustifiably timid 2021-01-15 16:32:59 are they complaining that util-linux relies on, uh, libblkid, libfdisk, libmount, libsmartcols and libuuid? 2021-01-15 16:33:19 that coreutils depends on libacl and libattr? 2021-01-15 16:33:36 imo very few things have legitimate cause to use utmp at all and i tend to like the assurance that you're not leaking data in utmp unless you intentionally link against a library to do it 2021-01-15 16:34:07 that the freaking *kernel* needs perl to build? 2021-01-15 16:34:56 the truth is that every time I interact with Alpine devs, I feel like 'muh dependencies' is nothing but a pretext to gatekeep 2021-01-15 16:36:14 heh 2021-01-15 16:38:14 yes, I want a lot of pkg have a lot less deps, but to achieve that for small number of them I would only argue on IRC and didn't work on anything :) 2021-01-15 16:38:30 i really do hate dep creep and these uselessly general single-consumer libraries util-linux and such have 2021-01-15 16:38:41 dalias: exactly 2021-01-15 16:39:01 and the one dependency that utmps has is far from single-consumer 2021-01-15 16:39:03 but until something is done about them it's disingenuous to complain about a small number of things linking a small library for utmp 2021-01-15 16:39:52 thank you, someone understands 2021-01-15 16:40:12 dalias: you know, if you don't complain for small, complaining to big will be too late 2021-01-15 16:41:18 it's already too late :-p 2021-01-15 16:42:01 sounds to me like Pandora letting all the demons out of the box, and frantically closing it at the end, locking in Hope 2021-01-15 16:43:11 dalias: :) 2021-01-15 16:44:05 skarnet: Hope is the scariest of all daemons 2021-01-15 16:44:42 heh 2021-01-15 16:45:10 mps: if that's how you see my software then I obviously have nothing more to say to you 2021-01-15 16:46:06 skarnet: it is not about your software at all 2021-01-15 16:46:20 is it really not? because it definitely feels like it 2021-01-15 16:46:23 well anyway, utmps is something that most people want 2021-01-15 16:46:35 I'm talking about alpine 'process' 2021-01-15 16:46:45 the process has been followed 2021-01-15 16:47:03 Ariadne: hmm 2021-01-15 16:47:44 skarnet: be assured that my complain is not about your software 2021-01-15 16:48:01 your complaint is that alpine does not do what you want 2021-01-15 16:48:28 well, at least till the moto is: small, simple 2021-01-15 16:48:50 if we want to change that I'm ok 2021-01-15 16:48:55 if you want absolutism on small, simple, there are better distributions 2021-01-15 16:49:04 that has never been intended to be absolute 2021-01-15 16:49:36 Ariadne: I don't think that the 'there are better distributions' is good for discussion 2021-01-15 16:49:55 i'm just telling it like it is 2021-01-15 16:50:58 hmm, there are a log better things in the world, not only distros, but telling that doesn't make sense here and now 2021-01-15 16:51:28 my point is that alpine is pragmatic, not absolutist 2021-01-15 16:52:11 which POV of pragmatic 2021-01-15 16:52:26 and my point is that questioning my software on smallness when you don't question the rest of what's already in Alpine is absolutely disingenuous 2021-01-15 16:52:27 your or mine 2021-01-15 16:52:44 your view is absolutist, not pragmatic 2021-01-15 16:52:53 heh 2021-01-15 16:53:01 I see it a pragmatic 2021-01-15 16:53:15 it is also flawed, if you really wanted absolute small and simple, you would go use landley's aboriginal linux and call it a day 2021-01-15 16:53:32 but we went out of the good talk, see you later 2021-01-15 16:53:52 alpine is small and simple, but in the context of providing what people actually *want* 2021-01-15 16:53:58 and that includes utmp 2021-01-15 18:12:32 Why do we still have https://git.alpinelinux.org/aports/tree/main/pth/APKBUILD#n6 in the repo? 2021-01-15 18:30:59 I refuse to belive x86 already finished the boost rebuild 2021-01-15 18:31:31 also armhf seems to be having distfile issues 2021-01-15 18:50:16 fwiw libblkid and libuuid are actually somewhat useful 2021-01-15 18:50:56 pretty sure udev uses libblkid 2021-01-15 18:52:34 what's ridiculous is things like column being in util-linux and com_err being in e2fsprogs 2021-01-15 18:58:21 PureTryOut[m]2: it was even recently added again: 56689d27fd383beba312b63d5439ea08b67d5a3f 2021-01-15 18:58:42 But uclibc is not used anymore 2021-01-15 19:02:16 Β―\_(ツ)_/Β― 2021-01-15 19:09:48 !15863 got an inactivity warning from algitbot but CI is green and no changes were requested so should be good to go 2021-01-15 19:36:09 maxice8: !16874 2021-01-15 19:39:35 The ones I have missed? 2021-01-15 19:40:22 yup 2021-01-15 19:46:36 uhg how do i unbreak alpine's inability to upgrade anything?? 2021-01-15 19:47:29 apk fix 2021-01-15 19:47:36 ? 2021-01-15 19:47:43 run 'apk fix' 2021-01-15 19:47:43 apk fix is a nop 2021-01-15 19:47:50 the problem is not broken packages 2021-01-15 19:48:00 it's some web of -dev package versions blocking upgrade of anything 2021-01-15 19:48:03 ah, what is problem? 2021-01-15 19:48:45 apk update ; apk upgrade -a (or apk upgrade -a -s) -s simulate 2021-01-15 19:49:05 the problem is forgotten pkgrel bump 2021-01-15 19:49:23 http://ix.io/2M8w 2021-01-15 19:49:25 hm, how 2021-01-15 19:49:30 first commadn it what i'm trying to install 2021-01-15 19:49:36 it can't install because some boost lib is being held back 2021-01-15 19:49:48 trying to force the boost package to update gives the huge error spam 2021-01-15 19:49:50 boost is being ubilt 2021-01-15 19:49:54 built* 2021-01-15 19:50:06 this isn't related to current build 2021-01-15 19:50:34 dalias: one by one, 'apk add openvdb-dev@testing 2021-01-15 19:50:34 ERROR: unsatisfiable constraints: 2021-01-15 19:50:40 muh 2021-01-15 19:50:52 dalias: one by one, 'apk add -u openvdb-dev@testing' 2021-01-15 19:51:00 i'm considering saving the list of -dev packages in world, apk del them all, upgrade stuff, then re-add all the removed -dev packages 2021-01-15 19:51:11 huh 2021-01-15 19:51:25 it's probably a bad idea 2021-01-15 19:51:32 usually in such cases I fix one by one 2021-01-15 19:51:42 at least now you have some dev packages 2021-01-15 19:51:48 the underlying problem is that when apk wants to upgrade a library package as a dep for something else that needs the newer library version 2021-01-15 19:51:59 well, nevermind, it wouldn't change anything 2021-01-15 19:52:01 the =x.y.z dep in the -dev package keeps the main library package held back 2021-01-15 19:52:10 rather than just forcing the -dev package to update too 2021-01-15 19:52:35 in -dev cases I simply upgrade -dev and rest is pulled automatically 2021-01-15 19:52:44 basically automatic dep resolution for upgrades just doesn't work if you have any -dev packages 2021-01-15 19:52:50 for a single -dev that works 2021-01-15 19:52:58 but this is a huge web of 30+ -dev packages 2021-01-15 19:53:06 i even tried upgrading them all: 2021-01-15 19:53:18 apk add -ul $(grep -- '-dev' /etc/apk/world) 2021-01-15 19:53:26 and it still fails 2021-01-15 19:53:59 and boost and python3 are involved in the web making it a huge mess 2021-01-15 19:54:00 dalias: isn't that because some package hadn't been rebuilt against boost-1.75? 2021-01-15 19:54:13 maybe 2021-01-15 19:54:25 but the upgrade request should just upgrade anything else that needs to be upgraded at the same time 2021-01-15 19:54:36 not hold the whole system back with unintelligible conflict errors 2021-01-15 19:55:20 well, it's not a bad idea to hold the system back here 2021-01-15 19:55:29 hmm, ime it ok, not to do what I don't ask 2021-01-15 19:55:42 i asked it to upgrade package x 2021-01-15 19:55:58 yes, but it's not possible if the repos are inconsistent 2021-01-15 19:56:06 it is possible 2021-01-15 19:56:16 but it detects some pkgs 'hold' it to do that 2021-01-15 19:56:18 if i did apk upgrade it would almost surely work 2021-01-15 19:56:28 you can try 2021-01-15 19:56:36 after waiting 24+ hours and running out of disk space upgrading unrelated stuff i dont care about 2021-01-15 19:56:53 :-p 2021-01-15 19:57:02 i'm going to just try purgine the -dev packages and re-adding them 2021-01-15 19:57:16 removal of -dev packages should not break anything runtime 2021-01-15 19:57:58 but my guess is that you can't update X if you need to update boost for that, as you have packages that are only built against the old boost soname 2021-01-15 19:58:15 Could NOT find Lua (missing: LUA_LIBRARIES) (found suitable version "5.3.6", minimum required is "5.3") 2021-01-15 19:58:34 Β―\_(ツ)_/Β― why cmake 2021-01-15 19:58:59 half of the problem is that alpine doesn't keep the old version of the libs; half of the problem is that Alpine fucks up its dependencies rebuild often D: 2021-01-15 19:59:35 btw, there are like 3 packages that are not building against the new version of boost 2021-01-15 19:59:39 see #alpine-commits 2021-01-15 19:59:43 it is not only 3 2021-01-15 19:59:46 I am monitoring the situation 2021-01-15 19:59:52 and suffering because of CMake 2021-01-15 20:00:03 right, at least 3 :-/ 2021-01-15 20:00:14 oof 2021-01-15 20:00:23 things will fail a lot more before they get better 2021-01-15 20:00:35 can I try to fix another package to help ya? 2021-01-15 20:00:35 it is the nature of big rebuilds, just you wait until python3 3.9 comes 2021-01-15 20:00:42 yes 2021-01-15 20:00:42 (I need hammers instead of fingers for this keyboard on old macbook :) ) 2021-01-15 20:00:49 go wild, ping me on your MRs 2021-01-15 20:01:03 several of the aports that fail have upgrades available... 2021-01-15 20:01:19 I am working on domoticz atm 2021-01-15 20:02:46 having a look at horizon 2021-01-15 20:03:51 I have an MR for horizon 2021-01-15 20:03:56 just need Ariadne to give the ok 2021-01-15 20:04:06 and for it to actually build 2021-01-15 20:05:02 works fine locally on my x86_64 somehow it breaks the compiler in CI ?? 2021-01-15 20:05:53 looking at icinga2 2021-01-15 20:08:52 maxice8: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-analyzer/icinga2/files/icinga2-2.12.1-boost-1.74.0.patch 2021-01-15 20:09:29 Yes 2021-01-15 20:09:46 my lookup table is Arch->Gentoo->Fedora->Debian 2021-01-15 20:10:47 I have the same list plus freebsd, openwrt and void 2021-01-15 20:17:56 go ahead and push it 2021-01-15 20:17:59 once it builds in CI :P 2021-01-15 20:19:06 still working on this mess... 2021-01-15 20:19:34 on what mess 2021-01-15 20:19:51 unintelligible package conflicts 2021-01-15 20:20:09 i removed a bunch of stuff i dont actually want/need and now i'm making some progress 2021-01-15 20:20:18 libffi seems to be at the core of it 2021-01-15 20:20:34 libffi is always the core of it 2021-01-15 20:20:41 i sooooo wish alpine would just static link all libs without long term stable soname/abi 2021-01-15 20:20:51 there's no reason at all to be using dynamic libffi 2021-01-15 20:21:12 same for boost 2021-01-15 20:42:31 The source for https://pkgs.alpinelinux.org/package/edge/main/aarch64/lua-luaxml seems to be done. How did the 3.13 builders manage to build it? 2021-01-15 20:44:11 Year ago PHP core started to require libffi otoh it could use bundled source 2021-01-15 20:46:40 PureTryOut[m]2: https://distfiles.alpinelinux.org/distfiles/v3.13/lua-luaxml-130610.tar.gz 2021-01-15 20:48:32 Oh, why doesn't the APKBUILD have that as the source then? 2021-01-15 20:48:45 PureTryOut[m]2: the builders are setup to first try distfiles 2021-01-15 20:49:38 Hmm, but now you can't just compile it locally. Mind if I edit the APKBUILD to use it directly? 2021-01-15 20:51:43 I suppose not 2021-01-15 21:09:47 still going 2021-01-15 21:10:05 found a bunch of bogus py-* and python meta packages holding back ancient python2 package versions *sigh* 2021-01-15 21:10:18 these were probably deleted ages ago but with no automated procedure for fixing the dep web 2021-01-15 21:10:36 and now everything finally seems unblocked 2021-01-15 21:10:45 yeah, I should have know 2021-01-15 21:11:36 static boost and libffi in packages that depend on them would be a huge help for this tho 2021-01-15 21:11:45 (avoiding forcing large unrelated upgrades in sync) 2021-01-15 21:13:32 boost is pretty big though, and i'm skeptical that it has good static linking size properties 2021-01-15 21:14:09 anything using boost is gigantic anyway, and likely doesn't use all of it, just parts 2021-01-15 21:23:19 uhg now some of the boost libs are missing/unavailable 2021-01-15 21:23:22 is that a builder problem? 2021-01-15 21:24:23 side-effect of Alpine not keeping old packages around 2021-01-15 21:24:57 I should have pushed boost1.75 harder 2021-01-15 21:25:03 :( 2021-01-15 21:25:31 so now i guess i just have a broken system til something happens..? 2021-01-15 21:25:37 boost-date_time is missing 2021-01-15 21:25:45 it should have the new boost-libs 2021-01-15 21:25:47 but not the old ones 2021-01-15 21:26:28 it doesnt have the new one 2021-01-15 21:27:27 oh no it's just that libreoffice hasn't been updated and depends on a boost version that no longer exists 2021-01-15 21:27:30 *sigh* 2021-01-15 21:27:35 *please* make boost static linked everywhere 2021-01-15 21:27:51 *please don't use boost 2021-01-15 21:28:12 jvoisin, alpine is a distro not a rewriter of every junk c++ application out there so.... 2021-01-15 21:28:55 *sigh* like everything still depends on 1.72 but 1.75 is all that's there now 2021-01-15 21:29:19 so i got from a useless state of being stuck with 1.69 that didn't satisfy any deps i needed because it was too old 2021-01-15 21:29:33 to a useless state of being stuck with 1.75 that doesn't satisfy any deps because it's too new 2021-01-15 21:34:01 and i broke a bunch of self-compiled stuff because soname of libprotobuf changed 2021-01-15 21:34:14 just hex editing the DT_NEEDED *sigh* 2021-01-15 21:44:38 Having a versioned boost package seems better than static linking tbh 2021-01-15 21:44:51 well yes that would be great too 2021-01-15 21:45:02 but it would be a lot larger 2021-01-15 21:45:17 because you'd have many full copies of boost on the system 2021-01-15 21:45:26 rather than just one copy of the relevant parts per program using it 2021-01-15 21:46:05 you seem to be optimistically assuming that it won't just pull in the whole library by transitive dependencies 2021-01-15 21:46:59 looking at gnuradio 2021-01-15 21:47:10 You'd only have a max of 2 boost copies on your system 2021-01-15 21:47:27 and that only temporarily while stuff is still rebuilding 2021-01-15 21:51:27 that's assuming you constantly upgrade everything 2021-01-15 21:51:50 hmm would it work to have a cronjob that hardlinks all libraries from /usr/lib into another lib dir.. 2021-01-15 21:51:59 and add that other lib dir to ldso path 2021-01-15 21:52:06 so nothing ever gets lost 2021-01-15 21:52:27 yes this is a stupid solution but... 2021-01-15 21:53:05 But I wanna known if it works 2021-01-15 21:53:45 for what use? 2021-01-15 21:54:08 morbid curiosity 2021-01-15 21:55:37 oh i thought you were asking if gnuradio works 2021-01-15 21:55:43 do you mean by hardlink hack? :-p 2021-01-15 21:56:06 yes 2021-01-15 21:59:20 really stupid idea too... 2021-01-15 21:59:38 installing no -dev packages on real alpine edge host, instead -dev packages from a stable release in a chroot 2021-01-15 21:59:49 and adding those dirs to ldso path 2021-01-15 22:00:29 and using those paths for any self-compiled software 2021-01-15 22:01:12 this sounds increasingly like nix 2021-01-15 22:01:20 yes 2021-01-15 22:01:55 is there musl-based nix repo? 2021-01-15 22:02:00 maybe i should just use that.. 2021-01-15 22:20:08 Well, in theory, things should go fine if we don't forget a third of boost-related rebuild 2021-01-15 22:21:34 There are people inside Nix that want musl support and they had an RFC for one, they even had a patched systemd 2021-01-15 22:21:38 I don't know how far they got though 2021-01-15 22:23:13 some arches finished the boost rebuild 2021-01-15 22:23:26 i heard that excising systemd from nix is quite painless 2021-01-15 22:23:50 I thought it was tied to it with lots of nix assuming it and making use of it 2021-01-15 22:23:56 yeah i wouldn't care about anything systemd related from nix 2021-01-15 22:24:09 basically there are two completely independent sets of packages i'm interested in 2021-01-15 22:24:23 (1) system components / stuff i'd call part of "the OS" 2021-01-15 22:24:26 (2) application programs 2021-01-15 22:24:46 basically i'm very happy with (1) from alpine but (2) is a huge problem of constant breakage 2021-01-15 22:24:59 time to make Alpine Silverblue :D 2021-01-15 22:25:06 and (2) should never be touching systemd 2021-01-15 22:39:16 (1) should never be touching systemd either. :P 2021-01-15 22:39:22 skarnet, :) 2021-01-15 22:39:56 i should have phrased it as "(2) should never be touching anything related to the init system" 2021-01-15 22:40:17 that's right 2021-01-15 22:45:12 how long does it normally take for packages that depend on a no-longer-available soname version to be rebuilt? 2021-01-15 22:45:16 is it automated? 2021-01-15 22:45:48 depends on the package we bump the `pkgrel` and the builder rebuilds it 2021-01-15 22:45:58 we normally do it in one go 2021-01-15 22:46:09 but it requires manual intervention? 2021-01-15 22:46:32 an upgrade of a library package that changes soname doesn't auto-bump pkgrel of everything that depends on it? 2021-01-15 22:46:44 no it doesn't 2021-01-15 22:46:48 :( 2021-01-15 22:46:50 it is on the maintainer to bump the pkgrel 2021-01-15 22:46:58 so that leaves everything broken until maintainer notices? :( 2021-01-15 22:47:07 0bf72f4ee7c03e74ba7b5260027fe67748037f81 f14316ecad37a49ccc81e95d12bb26e64ea3596e 9233749896bdaf3cedbca27e08018b96115ccf5c a63eefda9db2caba26cb68982ea3d7615c8160dc 2021-01-15 22:47:08 yes 2021-01-15 22:47:13 Yes, and that has happened before 2021-01-15 22:47:48 the rebuilding infra is suboptimal, Void Linux holds packages until it has been all rebuild 2021-01-15 22:48:16 our builders only upload after things are finished as well 2021-01-15 22:48:27 the whole "uploaded" message 2021-01-15 22:48:36 from algitbot in #alpine-commits 2021-01-15 22:50:04 but depending programs need to be explicitly bumped 2021-01-15 22:50:17 otherwise, no one would ever get these upgraded packages 2021-01-15 22:50:20 (rebuilt) 2021-01-15 22:50:43 so it's the responsibility of the one who is upgrading libraries to make sure all depending packages are bumped 2021-01-15 22:53:17 openvdb is one i need that looks like it's likely to be overlooked 2021-01-15 22:56:34 It was rebuilt in a later commit 2021-01-15 22:56:45 oh it's done now? yay 2021-01-15 22:57:01 i've got a big reinstall of all the -dev packages i purged going on now 2021-01-15 22:57:05 no no, there is a commit that bumped the pkgrel it is still not done doing all the rebuilds 2021-01-15 22:57:11 ah 2021-01-15 22:57:14 ok 2021-01-15 22:57:22 algitbot: retry master 2021-01-15 22:57:30 well maybe by the time this reinstall of *-dev finishes it'll be done :-p 2021-01-15 22:58:01 i wonder if i should just do things the other way around... 2021-01-15 22:58:24 use a long term stable as main dist, with edge in a chroot just for firefox, gcc, etc. 2021-01-15 22:58:40 and add the latter to my path/ldsopath 2021-01-15 23:02:01 hmm libtbb-dev package seems to lack a .a file :( 2021-01-15 23:02:41 Is it a matter of --enable-static ? 2021-01-15 23:02:53 probably 2021-01-15 23:02:55 or s/--disable-static// 2021-01-15 23:03:01 it is a makefile 2021-01-15 23:03:05 i'm not sure 2021-01-15 23:03:26 and the non-dev package has .so symlinks 2021-01-15 23:03:33 contrary to policy aiui 2021-01-15 23:03:53 (policy i disagreed with but .. :-p) 2021-01-15 23:04:50 Need better enforcement 2021-01-15 23:05:06 Β―\_(ツ)_/Β― I'll write an abuild rule for it lets hope it gets merged 2021-01-15 23:05:56 dalias: by tbb you mean threadingbuildingblocks ? 2021-01-15 23:06:30 i guess, whatever libtbb is 2021-01-15 23:06:36 i just added it as a dep 2021-01-15 23:06:52 and want to static link now, to avoid breaking on next upgrade, but can't because the .a is missing 2021-01-15 23:08:17 I don't even see support for making it .a in its cluster of makefiles 2021-01-15 23:10:05 I really don't feel like messing with makefiles, hopefully they use meson in the future 2021-01-15 23:10:52 x86_64 is done 2021-01-15 23:14:05 :/ 2021-01-15 23:14:20 c++ programmers use the worst junk libraries 2021-01-15 23:14:20 :\ 2021-01-15 23:14:33 it's as bad as node 2021-01-15 23:15:13 piles of poorly engineered libraries with broken build systems and distro channels to do something that takes like 5 lines with the stdlib 2021-01-15 23:20:00 at a guess, part of the reason is that msvc c sucks 2021-01-15 23:35:48 cgal hasn't been updated for new boost either :( 2021-01-15 23:40:51 lost evening trying to use dendrite, at the end removed supervise option and it started to work 2021-01-15 23:41:56 now will set it to use runit run script 2021-01-15 23:43:03 yay it's working after update 2021-01-16 01:54:53 huh 2021-01-16 01:55:05 make and /bin/sh are getting Operation not permitted errors 2021-01-16 02:03:16 yep, CI is broken 2021-01-16 02:14:07 looks gcc is broken not CI 2021-01-16 02:16:33 I don't know 2021-01-16 02:16:50 I just rebuilt with latest everything on edge and I can't reproduce the errors CI gets while building CMake 2021-01-16 02:17:29 In fact I'm almost done building CMake 3.19.3 locally :D 2021-01-16 03:36:08 maxice8 dalias a nix variant that comes with runit instead of systemd: https://github.com/cleverca22/not-os 2021-01-16 03:37:22 fancy 2021-01-16 04:13:41 i would just use nix for apps not system i think 2021-01-16 05:30:04 dalias: !16894 2021-01-16 05:44:52 !16892 will be fun to merge and manage 2021-01-16 06:38:25 https://lists.alpinelinux.org/~alpine/devel/%3Cd0c4cab578c513f312390679680eb1cf31690a05.camel%40gmail.com%3E 2021-01-16 07:23:42 maxice8: long time I'm proposing removal of -static, and put .a in -dev. you wrote it well. I vote for that 2021-01-16 12:56:24 maxice8: already discussed in #-linux, some kind of docker crap 2021-01-16 12:57:02 docker+libseccomp 2021-01-16 12:57:11 but I cannot reproduce it myself on the CI hosts 2021-01-16 12:59:38 my guess would be different image version 2021-01-16 12:59:54 or running apk upgrade first 2021-01-16 13:10:02 Hello71_: thanks for getting me straight 2021-01-16 13:10:08 I indeed forgot to upgrade musl 2021-01-16 13:10:14 looking at https://gitlab.alpinelinux.org/mpolanski/aports/-/pipelines/68152 only ppc64le CI runner works fine 2021-01-16 13:10:23 Hello71_: faccessat2(AT_FDCWD, "/bin/sh", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted) 2021-01-16 13:10:29 :) 2021-01-16 13:10:33 Then the fix is trivial 2021-01-16 13:11:41 Newer versions of runc are going to fix this 2021-01-16 13:12:00 so that we don't have to update the secommp profile every time a new syscall is added 2021-01-16 13:12:12 are they? 2021-01-16 13:12:58 oh, I missed the last comment on the issue 2021-01-16 13:13:31 Hello71_: link? Was trying to find it again 2021-01-16 13:14:01 https://github.com/opencontainers/runc/issues/2151 2021-01-16 13:15:20 https://github.com/opencontainers/runc/pull/2737 2021-01-16 13:18:02 yes i held back faccessat2 until after 3.13 2021-01-16 13:18:34 figured now was a better time to deal with it :P 2021-01-16 13:18:38 right, but now I need to make sure container are allowed to call it 2021-01-16 13:18:43 containers* 2021-01-16 13:18:54 until runc is fixed 2021-01-16 13:23:15 :( 2021-01-16 13:23:47 sigh 2021-01-16 13:25:01 dare I upgrade our x86_64 CI host to 3.13? :P 2021-01-16 13:28:35 Ariadne: btw, did you see the ifupdown-ng issue regarding ifenslave? 2021-01-16 13:29:07 no 2021-01-16 13:29:37 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12319 2021-01-16 13:31:03 oh that's easy to fix 2021-01-16 13:31:10 we just need to deprecate bonding 2021-01-16 13:31:20 and use the ifupdown-ng version 2021-01-16 13:31:51 it's because ifupdown-ng is rewriting the bond-slaves term internally to bond-members 2021-01-16 13:32:01 and the old bonding script doesn't know bond-members 2021-01-16 13:32:08 "The bridge and bond packages are still required." 2021-01-16 13:32:13 from our release notes on the wiki 2021-01-16 13:32:16 yeah 2021-01-16 13:32:22 just fix bond for now 2021-01-16 13:32:31 to look for bond-members 2021-01-16 13:32:34 I'll fix it 2021-01-16 13:32:36 ok 2021-01-16 13:33:50 We use it on our packet/equinix hosts as well, so I guess we would be affected? 2021-01-16 13:34:38 would it help to do s/bond-slaves/bond-members on /etc/networking/interfaces? 2021-01-16 13:37:54 seems like bb ipcalc is broken 2021-01-16 13:37:58 (in 3.11) 2021-01-16 13:38:49 nah its 1 line fix 2021-01-16 13:39:12 i just forgot to update the alpine script 2021-01-16 13:39:58 ok, I'll wait for the package to be available 2021-01-16 13:40:05 I wanted to upgrade the CI host to 3.13 2021-01-16 13:40:22 which also has bond-slaves 2021-01-16 13:40:45 But it should be bond-members, right? 2021-01-16 13:41:04 it should be, but ifupdown-ng will just rewriite it internally 2021-01-16 13:41:19 0.11 will have iflint which will tell you about these things :) 2021-01-16 13:41:20 nod, but then I will udpate it as it should be 2021-01-16 13:42:04 you'll need the fixed bonding package for now 2021-01-16 13:42:22 the ifupdown-ng one is better, but i wanted to be conservative for 3.13 :P 2021-01-16 13:42:49 ok 2021-01-16 13:47:23 ok, rebooting now 🀞 2021-01-16 13:52:26 "Welcome to grub" -> nothing :-/ 2021-01-16 13:55:15 try rebooting again 2021-01-16 13:55:22 yes 2021-01-16 13:55:33 turn it off and on again 2021-01-16 13:56:43 :p 2021-01-16 13:59:06 "Enter User password" .... 2021-01-16 14:04:38 heh 2021-01-16 14:05:27 It did not do that the first reboot 2021-01-16 14:05:39 "HDD is locked" : 2021-01-16 14:10:12 ram issues? 2021-01-16 15:23:20 If a package changes its name, should the paths the package installs files in correspond to this change? 2021-01-16 15:23:27 And if so, how would this be handled? 2021-01-16 15:25:00 Newbyte: depends 2021-01-16 15:25:06 can you give a concrete example? 2021-01-16 15:25:28 !16473 2021-01-16 15:28:00 Newbyte: I guess upstream should already have renamed the package files, correct? 2021-01-16 15:29:15 I see in the buildlog it's still called riot-web? 2021-01-16 15:30:14 Upstream just provides a tarball with the web app. No particular directory structure. 2021-01-16 15:30:21 And the installation is just done by copying files 2021-01-16 15:30:44 So the riot-web path comes from the APKBUILD 2021-01-16 15:30:49 aha ok 2021-01-16 15:31:17 It would make sense to rename it 2021-01-16 15:31:33 How should that be handled in the APKBUILD? 2021-01-16 15:31:38 for what dummy pkgs are built? 2021-01-16 15:31:44 for non-config files, you don't need to do anything 2021-01-16 15:31:57 config files (/etc/*) are more tricky 2021-01-16 15:32:07 i.e. is there a way to not make main pkg and just subpkgs 2021-01-16 15:32:13 non-configuration files are removed automatically? 2021-01-16 15:32:18 Newbyte: yes 2021-01-16 15:32:38 otherwise packages could leave a lot of lingering files behind 2021-01-16 15:33:58 replaces + provides like gjabel mentions helps with upgrading 2021-01-16 15:34:03 Makes sense. I'll make it do that with the web content then 2021-01-16 15:35:09 How would I go about doing it with the configuration file though? 2021-01-16 15:35:48 I suppose we don't guarantee stability for things like this between releases and on Edge, so I guess it would be fine to just move that as well? 2021-01-16 15:35:55 Feels suboptimial though 2021-01-16 15:36:16 And by move I mean put it in a different location 2021-01-16 15:37:16 Though, the configuration file in /etc is just a symlink. Would the old symlink be kept if the package starts installing the configuration file somewhere else? 2021-01-16 15:37:36 If so you'd just have the configuration file exposed in 2 locations in /etc which doesn't sound too bad 2021-01-16 15:37:55 When people upgrade, that is. New installations should only have the new one 2021-01-16 16:23:39 any idea why make: /bin/sh: Operation not permitted on !16898 2021-01-16 16:24:11 timlegge: yes 2021-01-16 16:24:21 Something I need to fix (and working on 2021-01-16 16:24:51 basically docker/seccomp issue 2021-01-16 16:24:58 docker/runc/seccomp 2021-01-16 17:08:11 could alpine busybox package increase CONFIG_FEATURE_EDITING_MAX_LEN ? 2021-01-16 17:08:37 haven't looked at what it is now but i've hit it many times trying to c&p gcc command lines from make output 2021-01-16 17:08:44 i think it's 256 or something small 2021-01-16 17:20:55 ikke: thanks 2021-01-16 17:22:04 why not apk add vim? 2021-01-16 17:22:41 it's 18 MB but if you're already installing gcc anyways 2021-01-16 17:25:07 vim?? 2021-01-16 17:25:15 this is for shell not editor 2021-01-16 17:25:28 and "why not use bash?" is not an answer because bash sucks, ash is so much better 2021-01-16 17:25:54 dalias: what is actually being limited? 2021-01-16 17:26:10 ikke, line length 2021-01-16 17:26:11 Never ran into this 2021-01-16 17:26:25 it stops accepting characters after the limit (keypresses are ignored) 2021-01-16 17:26:33 just hold down a and see where it stops 2021-01-16 17:26:56 (if only ash had completion :<) 2021-01-16 17:27:04 dalias: lol, I was just doing that :D 2021-01-16 17:44:31 jvoisin: ash have completion, not as 'big' ones though 2021-01-16 17:45:03 path and filename, enough 2021-01-16 17:47:57 zsh 2021-01-16 17:48:16 hm, I think ash max line len is around 2000 2021-01-16 17:48:35 in alpine, I mean 2021-01-16 17:48:53 tcsh 2021-01-16 17:49:34 tcsh is small but have all 'bells and whistles' needed for normal interactive use 2021-01-16 17:51:59 if only ash had !pattern 2021-01-16 17:52:20 That alone is enough to not be usable for interactive work 2021-01-16 17:54:10 and alt+. 2021-01-16 17:54:54 what is 'alt+' 2021-01-16 17:55:03 in which shell 2021-01-16 17:55:28 alt + 2021-01-16 17:55:32 bash, zsh 2021-01-16 17:55:42 recall last argument 2021-01-16 17:56:20 ah, emacs mode 2021-01-16 18:26:06 detha, ! is the absolute worst anti-feature of bash and must be nuked with set +H if running bash 2021-01-16 18:26:51 it causes catastrophic unintended command execution for perfectly well-defined commands containing ! even in quoted contexts, up to and including possible accidental rm -rf / 2021-01-16 18:40:11 dalias: it is a 'do what I say, not what I mean' feature. 2021-01-16 18:41:04 However, not having it means unlearning 20+ years of muscle memory. I'll take the risk. 2021-01-16 18:42:23 If I want belts and suspenders, I'll do the centos thing and alias rm='rm -i' 2021-01-16 18:42:39 it's not about belts and suspenders but behaving contrary to spec and least-surprise 2021-01-16 18:43:09 i pity folks who learned on that badness and rightly dont want to spend effort unlearning it :-p 2021-01-16 18:45:41 Matter of taste I guess, least surprise for me is ! just working like it should :p 2021-01-16 20:03:17 How could ! turn into an accidental rm -rf /? 2021-01-16 20:12:18 if 'rm *' is the most recent thing starting with r, 'cd /; !r' would do that. 2021-01-16 20:12:29 Why someone would type that is another question 2021-01-16 20:18:27 [10:26:52] (if only ash had completion :<) 2021-01-16 20:18:42 i have some patches halfway done for that 2021-01-16 21:38:04 !16894 2021-01-17 01:40:18 opinions on https://lists.alpinelinux.org/~alpine/devel/%3Cd0c4cab578c513f312390679680eb1cf31690a05.camel%40gmail.com%3E ? 2021-01-17 07:10:48 Ariadne: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12320 should we remove amavis ? 2021-01-17 07:18:16 Ikke: isn't the docker/libseccomp a matter of adding faccessat2 to the list of allowed syscalls ? at least temporariliy ? 2021-01-17 07:18:26 maxice8: I tried that 2021-01-17 07:18:31 oh 2021-01-17 07:18:59 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#time64_requirements has some more details 2021-01-17 07:23:06 huh, the ppc64le builder seems to be working 2021-01-17 07:23:10 :D python3 worked 2021-01-17 07:23:51 https://gitlab.alpinelinux.org/Leo/aports/-/jobs/295560 :D 2021-01-17 07:31:52 maxice8: so that's why I decide to upgrade the x86_64 ci host 2021-01-17 07:31:55 and the rest is history 2021-01-17 07:32:11 huh 2021-01-17 07:32:35 https://ibb.co/KqPHHNZ 2021-01-17 08:05:58 maxice8: I'm in favor of removing -static for static libs and keeping it only for static binaries 2021-01-17 08:06:49 Yeah looking at it I should have been clearer that when I said -static I meant the static libraries not the static binaries 2021-01-17 08:06:52 I always had the impression those were pointless, and it create issues 2021-01-17 08:06:59 https://gitlab.alpinelinux.org/alpine/aports/-/issues/11592 2021-01-17 08:07:02 It can possibly implicitly be infered from the fact I praised static linking on Alpine Linux 2021-01-17 08:36:27 also I 'advocating' this for about two years 2021-01-17 08:37:25 even 'vetoed' -static for libs I maintain 2021-01-17 10:50:11 hm, is the gitlab ci broken atm? 2021-01-17 10:50:27 Yup 2021-01-17 10:50:30 > The C compiler "/usr/bin/gcc" is not able to compile a simple test program. 2021-01-17 10:50:31 ah 2021-01-17 10:50:38 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12321 2021-01-17 10:51:25 something something faccessat2 2021-01-17 10:51:43 (libseccomp actuall) 2021-01-17 10:53:27 I thought this wasn't an issue with recent containerd verison? 2021-01-17 10:53:28 https://github.com/containerd/containerd/commit/6a915a1453a5bfd859664679e1ac478a7022c7f6 2021-01-17 10:53:30 etc pp 2021-01-17 10:55:43 most CI hosts are still Alpine 3.11 2021-01-17 12:37:31 [01:37:21] even 'vetoed' -static for libs I maintain 2021-01-17 12:37:38 agree. -static is bad. i have done the same 2021-01-17 13:11:49 nmeum: also as I explained in 3.13 release notes (although according to aria 2021-01-17 13:12:15 dne, this shouldn't affect 3.13), you need new libseccomp too 2021-01-17 13:15:46 Are the x86_64 builders doing okay? 2021-01-17 13:16:32 The x86_64 CI job for !16473 keeps failing due to the job timing out 2021-01-17 13:28:40 Hello71_: this should be new enough, right? https://pkgs.alpinelinux.org/packages?name=libseccomp&branch=v3.11 2021-01-17 13:29:01 Hello71_: somehow, even with the latest seccomp (passed as --seccomp-profile to dockerd), it was still blocked 2021-01-17 13:29:10 but I did not do the other debugging command that you listed on the wiki yet 2021-01-17 13:29:19 ikke: you can adapt the scmp_sys_resolver 2021-01-17 13:33:26 ikke: libseccomp needs to be 2.4.4+ 2021-01-17 13:33:29 for faccessat2 2021-01-17 13:33:39 "syscalls: update the syscall table for Linux v5.8.0-rc5" 2021-01-17 13:33:49 Hello71_: aha 2021-01-17 13:33:58 Hello71_: htanks 2021-01-17 13:34:01 thanks* 2021-01-17 13:34:04 we can probably safely backport that 2021-01-17 13:39:34 Hello71_: I need an incentive to upgrade our hosts :P 2021-01-17 13:39:43 mmhmm 2021-01-17 13:39:58 (and break them in the mean time) 2021-01-17 15:32:58 ikke: that "HDD is locked" looks like the drive has hardware encryption enabled and has been locked as the wrong password/no password was entered from the BIOS/UEFI during hardware boot 2021-01-17 15:33:25 minimal: yes, indeed looks like it 2021-01-17 15:35:58 other possibility is that its password protected/locked by BIOS rather than the drive itself 2021-01-17 15:36:45 We provisioned a new server 2021-01-17 15:38:08 well hdd password long predates hardware encryption 2021-01-17 15:41:24 last time I looked it seemed many of the implementations of drive encryption had "issues" - some security research picked holes in various vendors' drives that rendered the encryption ineffectual 2021-01-17 15:41:41 does not supprise me one bit 2021-01-17 15:43:18 ikke: darn, I meant to start the conversation with "Hello IT, have you tried turning it off and on again?" as per "IT Crowd" :-) 2021-01-17 15:43:39 haha :D 2021-01-17 15:44:30 my point is that hdd password is a basic part of ata security spec supported by the majority of consumer drives since... long long time ago 2021-01-17 15:45:00 it was later overloaded by decryption password entry 2021-01-17 15:47:10 Hello71_: yeah the Opal drive encryption is a more modern thing. Never had an Opal-capable spare drive to actually try it out 2021-01-17 15:49:57 Question: what's the difference between 3.13 and 3.13-stable with regard to MRs? 2021-01-17 15:50:36 minimal: euhm? 2021-01-17 15:50:42 do you mean branch name? 2021-01-17 15:50:51 there should only be 3.13-stable as a branch 2021-01-17 15:51:49 had a MR to fix a problem in Edge that also was applicable to 3.13, was told in the MR it had been backported to 3.13 and that I needed to make seprate MRs for 3.13-stable as well 2021-01-17 15:52:32 It needs to be backported to Alpine Linux 3.13, in order to do that, you need to make a merge request against the git branch called 3.13-stable 2021-01-17 15:52:57 sounds like typo 2021-01-17 15:53:24 right but seems Leo has done that, so not sure what his comment then meant. !16816 2021-01-17 15:53:39 yeah 2021-01-17 15:53:41 perhaps 3.12? 2021-01-17 15:54:10 although that does not make sense either 2021-01-17 15:54:15 maxice8: what did you mean? ^ 2021-01-17 15:54:40 doesn't apply to 3.12 - the issue was trigger by skalibs ABI change in Edge just before 3.13 was made (and therefore the same skalibs change went into 3.13) 2021-01-17 15:55:09 yeah 2021-01-17 15:56:21 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) :( 2021-01-17 15:57:26 missing initramfs 2021-01-17 15:57:29 ikke: seems like you're having a run of bad luck 2021-01-17 15:59:04 I did add lvm vgchange --sysinit --activate y to mkinitfs-init 2021-01-17 16:22:04 ACTION slaps minimal around a bit with a large trout. 2021-01-17 16:22:10 hard drives smh 2021-01-17 16:22:46 minimal nice reverse dns btw 2021-01-17 16:53:14 It means in the future instead of me merging it and the back porting myself it would be easier and faster if you opened MRs with backports to 3.13 alongside yours for edge 2021-01-17 16:54:30 aha 2021-01-17 17:02:29 maxice8: haven't done a backport before so wasn't clear on the procedure 2021-01-17 17:07:26 so separate MRs for Edge/master and for 3.13-stable? 2021-01-17 17:07:40 yes 2021-01-17 17:07:50 the stable branches are separate branches based of master 2021-01-17 17:07:51 Impossible not to be 2021-01-17 17:08:12 you basically need to cherry-pick in order to backport 2021-01-17 17:08:26 An MR needs a target branch 2021-01-17 17:12:13 which defaults to master 2021-01-17 17:13:09 Which can't be more than 1 branch 2021-01-17 17:14:02 yeah, just getting the steps clear in my head 2021-01-17 17:16:58 BTW who looks after security issues? 2021-01-17 17:19:30 The maintainer of the respective package does 2021-01-17 17:21:35 Cogitri: I meant is there an Alpine security team 2021-01-17 17:21:57 https://gitlab.alpinelinux.org/team 2021-01-17 17:24:09 ikke: Thanks. No specific team for security there, guess I'll ping ncopa direct 2021-01-17 17:31:33 maxice8: going back to the 3.13-stable discussion, should a MR header then be something like "[3.13-stable] community/whateverpackage: change message" to distinguish it in the Gitlab UI from the Master MR? 2021-01-17 17:31:52 No, gitlab itself distinguishes it 2021-01-17 17:32:16 ok 2021-01-17 17:32:33 check the open merge requests for openjdk 2021-01-17 17:32:47 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&search=openjdk7 2021-01-17 17:34:27 got it. thanks 2021-01-17 17:34:54 although, you see they did add a prefix to the MR title as well 2021-01-17 17:35:32 My tooling (mkmr, agl) would prefix it automatically, easier to spot than looking at the half the size branch name 2021-01-17 17:36:11 ikke: that was my point - I see the actual commits had no prefix, wasn't sure if Gitlab would add a prefix to the title automatically 2021-01-17 17:36:29 The commits at least should not have it 2021-01-17 17:36:34 the MR title is optional 2021-01-17 17:43:10 never put the prefix in the commits 2021-01-17 17:48:26 can someone please merge !15297 and !15298? edge is already updated, just the backports are missing 2021-01-17 17:49:11 bratkartoffel: lol, I just linked to those 2021-01-17 17:49:18 (unrelated, but still) 2021-01-17 17:50:28 oh, haven't read the scrollback :) 2021-01-17 17:50:37 np 2021-01-17 18:06:12 Ok, we have an x86_64 runner again 2021-01-17 18:06:33 Hurray 2021-01-17 18:08:10 so, now, do I dare to do x86 as well? :P 2021-01-17 18:08:16 I must be an expert at this point 2021-01-17 18:08:31 to 3.12 for now 2021-01-17 19:08:17 ikke: runing into the make: /bin/sh: Operation not permitted in a local docker container - do you know what the issue might be? 2021-01-17 19:08:45 timlegge: outdated docker / libseccomp 2021-01-17 19:09:14 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#time64_requirements 2021-01-17 19:10:08 for faccessat2 (the issue you are running into), you need at least 2.4.4 2021-01-17 19:10:13 for libseccomp 2021-01-17 19:10:15 timlegge should really read Release Notes :-) - Thanks 2021-01-17 20:13:11 that issue only effects edge anyway 2021-01-17 20:13:17 i held back faccessat2 in 3.13 2021-01-17 20:13:30 nod 2021-01-17 20:13:43 but, it affects users who use alpine:edge 2021-01-17 20:20:48 what for is 'Lock merge request' in gitlab web ui 2021-01-17 20:21:58 probably preventing non-contributors to comment 2021-01-17 20:22:16 "Lock this merge request? Only project members will be able to comment." 2021-01-17 20:22:44 In case you get a lot of off-topic / low value comments on a certain MR 2021-01-17 20:23:08 aha, good to know, thanks 2021-01-17 20:23:31 now I have tool to (over)use :) 2021-01-17 20:24:33 testing it here !16940 2021-01-17 20:25:10 huh, now see wrong commit msg, s/aports/aport/ 2021-01-17 20:27:33 !16940 2021-01-17 20:27:46 meh 2021-01-17 20:43:55 https://gitlab.alpinelinux.org/mps/aports/-/jobs/295926#L134 'make: uname: Operation not permitted' 2021-01-17 20:44:03 uname also 2021-01-17 20:44:33 yes 2021-01-17 20:44:37 working on it 2021-01-17 20:44:47 no worries 2021-01-17 20:44:49 x86 should be fixed soon as well 2021-01-17 20:44:59 lots of issues related to this 2021-01-17 20:45:11 I follow your effort, sorry I can't help 2021-01-17 20:45:27 no problem 2021-01-17 20:45:37 x86 went noticibly faster than x86_64 :P 2021-01-17 20:45:44 though, I still had to reinstall the host 2021-01-17 20:49:50 ok, new x86 runner is online 2021-01-17 20:50:20 what is with x86_64 2021-01-17 20:50:32 that it took longer? 2021-01-17 20:50:49 aha, ok, no hurries 2021-01-17 20:50:52 no 2021-01-17 20:51:07 first, the physical disks were locked 2021-01-17 20:51:12 so we had to provision a complete new server 2021-01-17 20:51:35 then I apparently run into a bug with alpine 3.13 (or rather, the kernel) that fails to find the lvm volumes at boot 2021-01-17 20:51:55 but apparently it does work on the x86 host (with efi) 2021-01-17 20:51:59 yes, I follow -infra 2021-01-17 20:52:09 heh 2021-01-17 20:52:15 so fun 2021-01-17 20:52:40 I don't have access to these consoles I think 2021-01-17 20:52:54 no 2021-01-17 20:53:23 good 2021-01-17 21:55:44 can someone fix horizon failure, /home/buildozer/aports/testing/horizon/src/horizon-0.9.6/./3rdparty/json.hpp:8494:24: error: comparison is always true due to limited range of data type [-Werror=type-limits] 2021-01-17 21:59:08 -Wno-error :D 2021-01-17 21:59:27 heh 2021-01-17 21:59:57 funny is comparison there :) 2021-01-17 22:00:49 basically, is c between value a and b 2021-01-17 22:01:37 I don't understand for what data type this would be always true 2021-01-17 22:02:15 oh, it's complaining about '\x00' <= c 2021-01-17 22:02:42 so that part could be easily patched out 2021-01-17 22:03:20 heh, signal is getting so popular, we got a patchset for signal-cli 2021-01-17 22:03:44 heh 2021-01-17 22:04:09 The compiler probably optimizes that comparison away anyway 2021-01-17 22:04:21 (So it's warning because that comparison is useless and probably wrong) 2021-01-17 22:05:00 yup 2021-01-17 22:05:15 https://tpaste.us/oPdB 2021-01-17 22:06:25 Huh, `and` instead of `&&` is a thing in C++ 2021-01-17 22:06:35 Learning some new oddness about C++ every day, I suppose :D 2021-01-17 22:06:40 wtf 2021-01-17 22:06:41 heh, didn't even occur to me 2021-01-17 22:06:44 why 2021-01-17 22:06:46 :) 2021-01-17 22:06:53 it looks to me the author is a python programmer 2021-01-17 22:06:56 just wait until they get rid of the preprocessor in C++23 2021-01-17 22:07:22 if a <= b <= c: 2021-01-17 22:08:43 Cogitri: what isn't a thing in C++ ? 2021-01-17 22:09:06 the code uses 'and' instead of '&&' 2021-01-17 22:09:25 why is this not failing in my container? 2021-01-17 22:11:00 tehcloud: Would be very nice if we can abandon the preprocessor and headers in C++, it's such a pain 2021-01-17 22:11:15 it's on the table 2021-01-17 22:11:28 was having a little chat with someone who is on the committee last week 2021-01-17 22:11:35 Yeah, but it'll take some time for everything to get to c++20 2021-01-17 22:13:48 Ariadne: would that patch make sense? 2021-01-17 22:30:53 Cogitri: reminds me of a funny I saw in ##c++: int const typedef bitand foo; foo x = 3; cout << x; 2021-01-17 23:26:41 ikke: would what patch 2021-01-17 23:26:58 ikke: yes, seems reasonable 2021-01-17 23:43:26 https://github.com/nlohmann/json/issues/1939, https://github.com/nlohmann/json/pull/2144, https://github.com/nlohmann/json/commit/23051df2c71dd3f9698e01de3cbfab0034c6e50e 2021-01-17 23:44:23 that's another reasonable patch 2021-01-17 23:45:33 https://tpaste.us/oPdB has unintended logic on signed char platforms 2021-01-17 23:46:58 yes, but none of our platforms are signed char ^_^ 2021-01-17 23:48:21 Is there a programmatic way to get dependencies in CMake like with pkgconf --print-requires 2021-01-17 23:48:36 ? 2021-01-17 23:57:49 Ariadne: uh 2021-01-18 00:03:36 Ariadne: i wish 2021-01-18 01:54:16 one can dream 2021-01-18 01:54:34 it is true, s390x and powerpc are signed char 2021-01-18 01:54:42 i think x86 is unsigned tho 2021-01-18 06:16:57 there's -f-signed-char, but I don't know if it's relevant 2021-01-18 06:17:23 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16965 2021-01-18 07:13:26 good morning 2021-01-18 07:13:53 morning 2021-01-18 07:39:20 !16894 2021-01-18 08:32:18 morning 2021-01-18 08:34:23 clandmeter: goede morgen :) 2021-01-18 08:35:04 was there a way to get the origin/subpkgs from apk? 2021-01-18 08:40:51 maxice8: i think you didnt bump pkgrel for some lua pkgs 2021-01-18 08:40:58 not sure there are more 2021-01-18 08:41:11 oof 2021-01-18 08:41:23 I'll check the lua commits, currently reviewing PureTryOut MR 2021-01-18 08:41:33 i purged a few 2021-01-18 08:41:51 ERROR: lua-socket-3.0_rc1_git20160306-r2: BAD signature 2021-01-18 08:41:51 ERROR: lua5.2-socket-3.0_rc1_git20160306-r2: BAD signature 2021-01-18 08:41:51 ERROR: lua5.2-sec-0.9-r0: BAD signature 2021-01-18 08:41:51 ERROR: lua5.1-socket-3.0_rc1_git20160306-r2: BAD signature 2021-01-18 08:42:07 lua5.x is a subpkg of lua-X 2021-01-18 08:42:15 we have lua-X and create lua$LUAVER-X 2021-01-18 08:43:09 yes, but sec is not a subpkg 2021-01-18 08:44:01 i was wondering if i could get all subpkgs from any pkgname and let apk return it 2021-01-18 08:44:12 so i could make a simple script to PURGE them. 2021-01-18 08:50:58 unfortunately I don't think so 2021-01-18 08:51:11 if you're making an script you can source the APKBUILD and echo $subpackages 2021-01-18 09:01:01 maxice8: still a challenge if i only know subpkg name 2021-01-18 09:01:41 apk list -o ? 2021-01-18 09:02:42 hmm 2021-01-18 09:02:53 that does seem to list them all 2021-01-18 09:03:15 i think ive used this before, but its not very obvious :) 2021-01-18 09:03:26 i would expect apk info to help me. 2021-01-18 09:05:15 uhm, it only works for the origin pkg. 2021-01-18 09:07:17 dalias: !16975 postfix upstream finally merged musl DANE fix patch :) 2021-01-18 09:30:45 rnalrd: would you mind if I take maintainership of u-boot? most commits and changes in last two years are mine, and also for uboot-tools. I would feel more comfortable for next changes/upgrades/fixes like this one !16940 2021-01-18 09:33:10 mps, pls go ahead, thanks! 2021-01-18 09:33:45 rnalrd: thank you 2021-01-18 11:45:37 mps: could you perhaps take a look at dovecot on 3.12? 2021-01-18 11:45:42 it fails on 32-bits arches 2021-01-18 11:50:34 hmm, who merged it, it didn't worked on CI 2021-01-18 11:51:11 will look in a few hour, I'm now busy with $job 2021-01-18 11:51:25 hours* 2021-01-18 11:51:41 6bd01a05ab9aa278c9113f3f81f32f55cde5f990 2021-01-18 11:51:43 sure 2021-01-18 11:52:05 I just noticed that on build.a.o these were marked as failed 2021-01-18 11:52:10 although already looked at builder logs, and have idea what should be fixed 2021-01-18 11:52:30 ncopa: did you already perge latest-stable on fastly? 2021-01-18 12:38:59 https://lists.alpinelinux.org/~alpine/devel/%3Cbf7ab4943efc85b6139bc34d038c15620bbac45b.camel%40gmail.com%3E 2021-01-18 12:42:23 maxice8: good, but we shouldn't change pkgs which have -tools like names upstream 2021-01-18 12:43:56 ? 2021-01-18 12:44:58 alsa-tools will not become alsa-utils 2021-01-18 12:46:11 never talked about -tools in the email 2021-01-18 12:46:28 then all is ok 2021-01-18 12:48:29 not sure what about util/s which contain just one util, singular or plural name 2021-01-18 12:48:51 plural 2021-01-18 12:52:34 i think these rules don't apply when upstream has a special name. i think it is supposed to apply when alpine packagers create a "new" package 2021-01-18 12:53:35 hmm, I though that relates to alpine derived names only 2021-01-18 12:53:52 thought* 2021-01-18 12:54:24 first alpine rule in pkg names is 'follow upstream' 2021-01-18 12:57:55 Yes, that's what is the plan in the RFC 2021-01-18 12:58:27 To only rename subpackages Alpine created, so we have a consistent naming scheme for subpackages 2021-01-18 14:04:01 ikke: i did 2021-01-18 14:12:05 ncopa: would you mind to look at !16940 2021-01-18 14:14:56 maxice8: found gptfdisk cve reference, will add it after finishing with dovecot for 3.12-stable 2021-01-18 14:52:25 ncopa: ok 2021-01-18 15:07:19 mps: if you do take over u-boot then could you take a look at !15746 ? 2021-01-18 15:08:58 What's the practice for vendering deps? I'd like to make a go package not require the network while building and I basically have the deps sources vendored, but not sure where to place the end result so the APKBUILD can use it 2021-01-18 15:11:21 minimal: will look for sure, but not now, I'm overloaded these days. sorry 2021-01-18 15:11:41 no problem 2021-01-18 15:12:00 if I forgot please remind me 2021-01-18 15:24:06 So I made a PoC to build a Go package without network access and I'd like some feedback on it, !16983 2021-01-18 16:01:28 I cannot upgrade my 3.12 nextcloud to 3.13 as it skips one major (18 -> 20), which is not supported. Any idea how to get the upgrade cleanly done? 2021-01-18 16:01:44 We've got to be more careful about nextcloud updates in the future... 2021-01-18 16:07:10 rnalrd: ping as you're the maintainer for nextcloud 2021-01-18 16:10:13 maybe we should provide versioned packages? 2021-01-18 16:11:02 bratkartoffel, that is what nextcloud19 package is for 2021-01-18 16:11:07 transitional package 2021-01-18 16:13:07 it's not an in-place upgrade, you have to remove all nextcloud packages and install nextcloud19 2021-01-18 16:14:22 pls let me know your experience, I'm in the middle of the migration too, but I've found issues with my install (which could not replicate with a clean nextcloud19 installation) 2021-01-18 16:16:41 there you should be a post-upgrade msg that tells you to use nextcloud19 when updating from ver < 20 2021-01-18 16:16:53 there should be* 2021-01-18 16:17:51 rnalrd: At least one user here had had troubles, expecting that installing nextcloud19 would upgrade it (but it would just result into file conflicts) 2021-01-18 16:18:49 ncopa: I built a go utility that downloads the indexes from the mirror and then (will) purge all the packages 2021-01-18 16:19:54 yeah, setting provides for "nextcloud" would pull version 20 anyway, so it would not help 2021-01-18 16:20:03 rnalrd: thanks for clarification. i'm using a docker container which installs nextcloud, so no message for me 2021-01-18 16:20:07 rnalrd: and replaces? 2021-01-18 16:20:16 i'll retry the upgrade this night and post any issues i encounter 2021-01-18 16:20:19 ikke if you have an idea how to make an in-place upgrade I'd happy to do it. :) 2021-01-18 16:20:51 hum, right I should try, replaces.. 2021-01-18 16:21:23 bratkartoffel, right, that another use case... hum 2021-01-18 16:21:30 And I guess nextcloud-20 should then replace nextcloud19 2021-01-18 16:21:36 yup 2021-01-18 16:27:01 bratkartoffel, sound like your suggestion to use package versioning could be a good solution 2021-01-18 16:27:37 we will face this problem every once in a while because NC is released more often than AL 2021-01-18 17:11:41 ikke: do I need bump pkgrel for dovecot fix to push 2021-01-18 17:12:12 I think yes, because it is already built on 64bit arches 2021-01-18 17:12:19 if it's just a simple fix that fixes the build failure but does not significantly change what's built, then no 2021-01-18 17:12:42 but if you think it significantly changes what's built, then yes 2021-01-18 17:12:56 if you are unsure this affects other arches, you could bump it, just to be sure 2021-01-18 17:13:03 but then versions will be different in archives 2021-01-18 17:13:21 like I said, it depends on the kind of change 2021-01-18 17:13:53 hmm, when in doubth "BUMP" :) 2021-01-18 17:13:58 ye 2021-01-18 18:52:43 ikke: looks like dovecot passed 3.12 builders 2021-01-18 18:52:53 mps: yes, thanks for working on that 2021-01-18 18:53:07 only ppc64le is still working 2021-01-18 18:53:10 np 2021-01-18 18:53:34 as it says: pleasure is mine :) 2021-01-18 18:54:05 but have to say thanks (I did ofc) to upstream for fast fix 2021-01-18 18:54:48 Yes, that's always nice 2021-01-18 18:55:22 whoever says IRC is not good for development should be slapped daily by big trouts ;) 2021-01-18 18:56:00 give me irc any day over other chat systems 2021-01-18 19:03:01 IRC is still king yes 2021-01-18 19:24:55 <[[sroracle]]> PureTryOut[m]2: this is essentially what i had in mind 2021-01-18 19:25:28 <[[sroracle]]> note that the sha512sums doesn't match the source currently (deps.tar.gz instead of $pkgname-$pkgver-deps.tar.gz) 2021-01-18 19:29:55 [[sroracle]]: checksums were doomed to fail. What was added there was a local test and meant to be changed 2021-01-18 19:33:45 PureTryOut[m]2: snapshots ('the snapshot function') does not scale 2021-01-18 19:34:25 Well I'm all ears for a different way to do it. This was just a PoC 2021-01-18 19:38:41 Thinking a bit about it 2021-01-18 19:38:50 normally the fetch function fetches the source 2021-01-18 19:39:02 but to know what to fetch, you need to look inside the source 2021-01-18 19:44:21 fwiw i think alpine should focus on dhcpcd moving forward 2021-01-18 19:45:41 moving forward where? 2021-01-18 19:49:21 ikke: I'm just looking at how others distributions do it. Some seems to generate an extra tarball with the deps and put it next to the build file for example. I believe openSUSE does this 2021-01-18 19:51:36 But that involves distributing these tarballs somewhere 2021-01-18 19:52:31 ikke: 3.14 and later 2021-01-18 19:52:44 we're starting to see network deployments that are IPv6-first 2021-01-18 19:52:56 anyway i explained it on devel :) 2021-01-18 19:54:24 what's wrong with udhcpc6 (that isn't also wrong with udhcpc)? 2021-01-18 19:56:17 ikke: well yes, like I said openSUSE puts them next to the build file. In our case that would be next to the APKBUILD. I can imagine not liking that, but besides that and vendoring them on a source mirror, I'm not sure how to solve it 2021-01-18 19:57:08 yeah, we don't want binaries in our aports tree 2021-01-18 19:57:36 this is not isolated to go btw 2021-01-18 19:57:47 rust, haskell and maybe other languages as well 2021-01-18 19:59:05 PureTryOut[m]2: having the go.mod / go.sum file in the tree would already be enough, though 2021-01-18 20:00:48 Yeah I know about other languages, I just thought of a way to do it with Go so decided to tackle that one first 2021-01-18 20:01:15 We _could_ put `go.mod` in our tree indeed, but I'm not sure how that would allow us to cut network access to the build? The deps still need to be fetched 2021-01-18 20:01:43 well, you'd vendor the deps somewhere in the fetch phase already 2021-01-18 20:03:40 Yes, ideally we'd just allow net in a fetch phase where we download the deps and then we have the build process without net afterwards 2021-01-18 20:04:08 I don't think there's an alternative approach to handling Rust & Go deps without it becoming a huge pain when every second package wants a different versioh 2021-01-18 20:04:49 [13:54] what's wrong with udhcpc6 (that isn't also wrong with udhcpc)? 2021-01-18 20:05:02 from ifupdown perspective it is preferable to have a single client which does both 2021-01-18 20:06:01 that way we can treat it as a single operation 2021-01-18 20:06:28 Well I'm trying to cut network access as a means to eventually have something like reproducible builds. For this, you need static deps. I don't think allowing network access like that helps with that 2021-01-18 20:06:33 Ariadne: how do you deal with android clients in a ipv6 dhcp world? 2021-01-18 20:06:50 beyond that dhcpcd is better maintained 2021-01-18 20:06:59 dunno, not my problem :p 2021-01-18 20:07:06 PureTryOut[m]2: Go and Rust builds are reproducible even with net 2021-01-18 20:07:11 PureTryOut[m]2: for go itself it would not matter a bit 2021-01-18 20:07:12 As long as the deps are binned 2021-01-18 20:07:20 probably 464xlat 2021-01-18 20:07:27 which at least with Rust they're basically always are via Cargo.lock 2021-01-18 20:07:36 versioned is pinned and everything is checksummed 2021-01-18 20:07:44 with go modules as well 2021-01-18 20:07:58 if you use go.mod, you automatically get a go.sum 2021-01-18 20:08:04 Then why are distros like Debian and openSUSE making such an issue out of it? 2021-01-18 20:08:11 as i said on twitter i think ipv4 flag day is a pipe dream 2021-01-18 20:08:25 but it makes sense to start taking an ipv6-first approach 2021-01-18 20:08:53 PureTryOut[m]2: We do the same with our sources, we do not distribute it ourselfs primarily, but we just checksum the source 2021-01-18 20:09:17 which is also not like debian does it 2021-01-18 20:09:35 as long as you trust the checksums, that part is reproducable 2021-01-18 20:10:12 PureTryOut[m]2: what we are not protected against is sources going missing 2021-01-18 20:10:29 maybe that's the reason other distros vendor everything 2021-01-18 20:10:56 Hmm 2021-01-18 20:11:14 At least it would be nice if we could enforce `options="net"` for Go, Rust and Haskell packages 2021-01-18 20:12:10 you mean options="!net" :) 2021-01-18 20:14:04 Hmm? No to allow those to build with rootbld, they need net 2021-01-18 20:14:16 And that also marks them, makes it easier to find when needing to change it later 2021-01-18 20:14:34 (right now I'm literally building everything in all 3 repos to find which packages are missing the flag) 2021-01-18 20:14:40 doesn't 'net' mean they are allowed to download things from the net? 2021-01-18 20:15:04 Yes 2021-01-18 20:15:13 That means they can at least be build with rootbld 2021-01-18 20:15:29 oh, now I understand what you mean 2021-01-18 20:15:49 Seems nobody except me uses rootbld πŸ€·β€β™‚οΈ 2021-01-18 20:16:05 It does not work in LXC without more permissions 2021-01-18 20:16:32 and rootbld in docker does not make a lot of sense either 2021-01-18 20:17:01 (apart from the disabling of the network during build) 2021-01-18 20:17:48 Well on my setup I love to be able to build things without needing Docker and it not messing up my system too much πŸ˜‰ 2021-01-18 20:18:17 And the net option is a thing, so please just use it lol 2021-01-18 20:20:17 Also, there are quite a few Python packages in main which download setuptools_scm, which we actually have packaged in community 2021-01-18 20:20:19 maybe abuild should assume option="net" if go / rust / ghc is in makedepends 2021-01-18 20:20:33 for the time being I mean 2021-01-18 20:22:06 That would work too I guess 2021-01-18 20:27:43 as long as it could be overridden with options=!net 2021-01-18 20:28:00 Hello71_: yeah, that was my idea in that case 2021-01-18 20:36:47 Ariadne: of recent(-ish) archs, x86, mips, sh, sparc are all signed char 2021-01-18 20:37:31 x86-32 and x86-64 2021-01-18 20:37:40 according to gcc 2021-01-18 20:39:10 Hello71_: so there are no recent arches that have unsigned char? 2021-01-18 20:39:57 well as we found the other day, arm is unsigned char 2021-01-18 20:40:09 ah ok 2021-01-18 20:40:24 so the json patch makes sens then 2021-01-18 20:40:27 and strictly speaking they all *have* unsigned char. what i'm referring to is whether char is signed or unsigned. strictly strictly speaking it's still a distinct type from signed and unsigned char 2021-01-18 20:40:58 but that last part is almost never relevant 2021-01-18 20:42:32 arm(32/64), riscv, ppc, s390x all signed char by default 2021-01-18 20:42:54 signed or unsigned? 2021-01-18 20:43:08 ohg, signed, yes 2021-01-18 20:43:10 so simply removing the c<0 will result in improper behavior 2021-01-18 20:43:15 yes 2021-01-18 20:43:19 uh, unsigned 2021-01-18 20:43:22 for the last one 2021-01-18 20:43:42 yes 2021-01-18 20:43:47 so the upstream patch is better 2021-01-18 20:43:51 so c<0 is no-op for those archs, which is why it failed on builders there but worked on x86 etc 2021-01-18 20:44:17 aaaah 2021-01-18 20:44:25 that explains why it worked in my container :P 2021-01-18 20:44:29 I thought it failed on all arches 2021-01-18 20:46:16 Hello71_: thanks for explaining 2021-01-18 20:46:48 guys, seems m4 is broken in armv7 repo 2021-01-18 20:46:59 ozzz: docker? 2021-01-18 20:47:09 no, arm tablet 2021-01-18 20:47:17 broken in what way? 2021-01-18 20:47:50 well the right answer is probably not to use werror :/ 2021-01-18 20:47:50 if I try to install it, it says - ERROR: m4-1.4.18-r1: BAD signature 2021-01-18 20:48:32 I tried to recompile it from source - FAIL: test-canonicalize-lgpl 2021-01-18 20:48:58 hmm 2021-01-18 20:49:09 gettext had the same failure 2021-01-18 20:49:19 did you try rm /etc/apk/cache/*; apk update 2021-01-18 20:49:31 ikke: i think this is that gnulib realpath("//") nonsense 2021-01-18 20:49:35 yes 2021-01-18 20:49:41 I removed using apk, but I'll try now 2021-01-18 20:49:42 Oh and when are we going to enforce having either tests or !check set? abuild has been warning about it for ages 2021-01-18 20:49:50 PureTryOut[m]2: heh 2021-01-18 20:49:56 ozzz: check the gettext aport 2021-01-18 20:49:59 it has a patch 2021-01-18 20:50:03 ok 2021-01-18 20:51:48 rm /etc/apk/cache/*; apk update - that helped 2021-01-18 20:51:58 thanks a lot! 2021-01-18 20:55:42 Hello71_: why does deleting the cache help? 2021-01-18 20:56:18 corrupted cache? or whatever required purging latest-stable 2021-01-18 20:56:41 oh, I missed the remark about bad signature 2021-01-18 20:59:26 ok :) 2021-01-18 20:59:44 I was thinking it somehow relating to the m4 issue 2021-01-18 21:03:22 mmhmm 2021-01-19 06:11:14 is the webfrontend for lists.alpinelinux.org no longer available? 404's here 2021-01-19 06:11:44 Working here 2021-01-19 06:15:42 ah, now it works here too. maybe it was just briefly offline 2021-01-19 07:41:46 I had bad experience with dhcpcd, it likes to mess with manually configured things 2021-01-19 10:08:51 morning 2021-01-19 10:09:55 ikke: i started on a go tool for purging dl-cd cache some time ago, but never finished it 2021-01-19 10:10:05 ikke: do you have the tool in git somewhere? 2021-01-19 10:13:50 ncopa: not yet, will finish it somewhere this week and will do that 2021-01-19 10:14:05 care to share what you have so far? 2021-01-19 10:14:14 $ tpaste < purge-dlcdn-cache.go 2021-01-19 10:14:14 https://tpaste.us/DMad 2021-01-19 10:16:06 ncopa: https://tpaste.us/BEab 2021-01-19 10:29:05 ncopa: I was thinking to create a namespace for go on gitlab 2021-01-19 10:29:16 and then to create a redirect from alpinelinux.org/go to there 2021-01-19 10:29:57 Then you can import alpinelinux.org/go/apk/<..> and it automatically owrks 2021-01-19 10:46:44 rnalrd: the nextcloud upgrades from 18 -> 19 -> 20 worked fine, just some additional occ-commands where needed to get it fully running again. Maybe we should add a note on the release notes for these cases? Do we have other aports which have problems when skipping a major version? 2021-01-19 10:53:36 bratkartoffel: Not aware of any 2021-01-19 10:53:46 does nextcloud itself has documentation on this? 2021-01-19 10:56:25 don't know, but i've found a bugreport from 2017 which had the same error message. so i guess it's well known? 2021-01-19 10:56:43 https://docs.nextcloud.com/server/latest/admin_manual/maintenance/upgrade.html 2021-01-19 10:58:35 even version 9 (the first version i found a manual for online) has a note about skipping major versions not beeing supported: https://docs.nextcloud.com/server/9/admin_manual/maintenance/upgrade.html 2021-01-19 11:22:47 bratkartoffel: maybe you can add a small section here: https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0 2021-01-19 11:43:06 ncopa: this is the latest version: https://tpaste.us/byqW 2021-01-19 11:43:09 i've added a section for nextcloud, thanks for the link ikke 2021-01-19 11:43:12 the previous one was an older version 2021-01-19 11:46:24 bratkartoffel: thanks 2021-01-19 12:15:22 maxice8: CVE-2021-0308 (gptfdisk) is only on Androids, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-0308 2021-01-19 12:16:04 we don't need to backport it, noticed that after backported to 3.12 and 3.13 2021-01-19 13:03:03 ikke: i'd like the ParseIndex function take an io.Reader instead of an array of strings 2021-01-19 13:08:56 Good idea, I did however wanted to decouple the downloading / extracting the archive from parsing the index 2021-01-19 13:10:39 You don't want errors from download / tarring showing up when parsing the index (which I think can happen when they are chained) 2021-01-19 13:12:28 yes, we shoudl ecouple downloading and decompressing from parsing th eindex, but i think we should use streams for it 2021-01-19 13:13:43 so we dont need to have a copy of everythign in memory, and can process the arrived data while waiting on network io 2021-01-19 13:15:02 My idea was also to have a separate library project for parsing things like the apkindex that can be reused in other projects 2021-01-19 13:15:16 exactly 2021-01-19 13:15:38 i'd want an api that does streams 2021-01-19 13:16:01 im not sure how we should output the Packages though 2021-01-19 13:18:30 in my implementation i sent them to a chan 2021-01-19 13:22:23 which means go routines are required 2021-01-19 13:27:29 go routines are more for parallel 'processes' 2021-01-19 13:30:01 if you use io.Reader (which could be 'slow') than sending data from it over chan to another go routine makes sense 2021-01-19 13:30:55 this models reminds me of wiring circuits 2021-01-19 14:06:07 https://alpinelinux.org/releases/ 2021-01-19 14:06:13 it would be nice if this page linked to the release notes 2021-01-19 14:06:40 i think it does 2021-01-19 14:06:47 also, it seems that the nginx changes were not detailed in the release notes 2021-01-19 14:07:13 oh, the minor release links are links to the release notes 2021-01-19 14:07:16 that was not obvious, thanks 2021-01-19 14:08:07 looks like some links are missing for the minor releases notes 2021-01-19 14:23:37 damn, lot of CVEs in dnsmasq: https://www.thekelleys.org.uk/dnsmasq/CHANGELOG 2021-01-19 14:23:56 MY-R: yes 2021-01-19 14:24:01 noticed them 2021-01-19 14:26:19 dnsmasq is a trashfire :/ 2021-01-19 14:26:40 the only reason it's not fuzzed to death by OSS-Fuzz is because the code is too awful and full of global states 2021-01-19 14:27:49 nmeum: hopefully my reply explains my motivations :) 2021-01-19 14:28:19 nmeum: fwiw i am not adamant about dhcpcd being the solution to this problem, but i want to have a "correct" answer for this scenario 2021-01-19 14:29:09 do we have tool to automatically add CVEs to APKBUILD 2021-01-19 14:30:24 Ariadne: sure, will read it later. thanks for expanding on your inital mail 2021-01-19 14:33:21 i wonder if a drop-in replacement for dnsmasq would be helpful 2021-01-19 14:33:43 yes. 2021-01-19 14:57:02 ncopa: if it should be streamed (which I agree with), but decoupled from download / untar, I guess it means it does need to be buffered in memory. Otherwise it has to be coupled 2021-01-19 15:06:52 dnsmasq does dns cache + dhcp client, right? 2021-01-19 15:07:11 yes 2021-01-19 15:07:35 +tftp 2021-01-19 15:07:38 and that is why many people using it :P and probably all soho routers 2021-01-19 15:08:08 are you saying people *like* software that doesn't really know its purpose? 2021-01-19 15:09:29 there is #alpine-offtopic channel 2021-01-19 15:10:36 that is hardly off-topic. Ariadne was wondering if a drop-in replacement for dnsmasq would be helpful and I'm looking at the specs here 2021-01-19 15:11:38 if we have suitable backends it should be possible to do a wrapper using dnsmasq config and delegating functionality to the real software behind it 2021-01-19 15:12:18 people like it because it automaticly setup up local domain names for clients using dhcp 2021-01-19 15:12:29 dnsmasq is long time in use and ofc far from perfect but people use it on different purposes 2021-01-19 15:15:35 afaik only software without sec bugs is djbdns, though long time ago read about something suspicious even about it 2021-01-19 15:19:40 djbdns has always been fine (the story you read about was about 32-bit overflow and there's ways to mitigate that) 2021-01-19 15:20:47 dnscache is entirely suitable as a backend for the dns part of dnsmasq, the only reason why it's not suitable (these days) as a generic dns cache is that it doesn't talk ipv6 2021-01-19 15:21:12 so if you want to put a cache on a v6 address, dnscache won't work 2021-01-19 15:21:15 I used djbdns as DNS server and cache for more than 10 years, but switched to other for practical reasons 2021-01-19 15:21:22 dnsmasq doesn't have dhcp client? 2021-01-19 15:21:26 or tftp client for that matter 2021-01-19 15:21:48 Hello71_: it have both 2021-01-19 15:21:52 unless you count dhcp relay which is technically client but not in the conventional sense 2021-01-19 15:22:03 mps: dnscache and tinydns have never failed me in 20+ years of use ^^ 2021-01-19 15:22:09 dnsmasq has dhcp and tftp *server* but last i checked no client 2021-01-19 15:22:17 Hello71_: sorry, wrong 2021-01-19 15:22:37 yes, servers not client 2021-01-19 15:22:58 still a kitchen sink :P 2021-01-19 15:23:28 https://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html says also pxe and ra, but pxe is technically just some dhcp options + tftp 2021-01-19 15:24:04 yes, right, I played a little with its RA but not much 2021-01-19 16:21:09 anyway, given that numerous alpine users use dnsmasq, and dnsmasq is basically mordor when it comes to security, i believe this to be a reasonable on-topic discussion 2021-01-19 16:22:13 https://xkcd.com/2347/ :) 2021-01-19 16:22:13 https://xkcd.com/2347 | Dependency | Alt-text: Someday ImageMagick will finally break for good and we'll have a long period of scrambling as we try to reassemble civilization from the rubble. 2021-01-19 16:22:32 imagemagick was solved by graphicsmagick but nobody seems to have noticed 2021-01-19 17:37:16 cloud-init upgrade to fix security issue just pushed to Edge (!17022) and 3.13 (!17023) - tried pinging ncopa on IRC a couple times the past few days to discuss it (I had advance warning of the issue as maintainer). Is there any plan for a formal process to handle security issues/embargos preparations? 2021-01-19 17:39:05 minimal: We have confidential issues on gitlab 2021-01-19 17:39:44 ikke: How do I create one? 2021-01-19 17:40:00 It's an option when you create it 2021-01-19 17:40:24 "This issue is confidential.." 2021-01-19 17:40:47 doh! had missed that 2021-01-19 17:41:37 ok. I'd assumed there would be security team to contact 2021-01-19 17:45:55 PureTryOut[m]2 is now a developer, welcome! 2021-01-19 17:49:40 Thank you! 2021-01-19 17:50:36 πŸŽ‰ 2021-01-19 18:26:51 yay 2021-01-19 18:29:41 heh, now alpine and pmOS are merged :) 2021-01-19 18:30:44 jk, PureTryOut[m]2 is careful and works fine, 2021-01-19 18:31:46 PureTryOut[m]2: welcome 2021-01-19 18:33:19 ACTION merges the Windows 10 source code to Alpine 2021-01-19 18:33:48 Microsoft 2021-01-19 18:33:52 Alpine tm 2021-01-19 18:36:17 kdbus is now part of linux-lts 2021-01-19 18:36:31 :) 2021-01-19 18:51:25 boost1.75-date_time-1.75.0-r3: 2021-01-19 18:51:25 conflicts: boost-date_time-1.72.0-r6[boost-date_time=1.75.0-r3] 2021-01-19 18:51:34 i wonder if the provides was not done right 2021-01-19 19:30:42 PureTryOut[m]2: congratulations on becoming an alpine developer :) 2021-01-19 19:50:44 Yup, congrats and thanks for the work on KDE :) 2021-01-19 19:51:34 Congrats 2021-01-19 19:56:29 congratz 2021-01-19 20:18:43 :D 2021-01-19 20:27:37 what to do for #12329 2021-01-19 20:28:52 for 3.10-stable I mean, to make patch for backport will be a lot of work, or to simply upgrade dnsmasq 2.83 2021-01-19 20:30:32 and 3.11-stable, ofc 2021-01-19 20:31:22 so from 2.80 to 2.83 2021-01-19 20:33:09 Just upgrade it imho 2021-01-19 20:33:47 ikke: right 2021-01-19 20:34:26 Cogitri: and that is what 'hold' me from 'Just upgrade' 2021-01-19 20:35:15 I don't have so old system to test will it break something if jumped to 2.83 from 2.80 2021-01-19 20:35:27 "Remove DSA signature verification from DNSSEC" in 2.81 2021-01-19 20:36:01 That seems the only backwards incompattible change 2021-01-19 20:36:17 yes 2021-01-19 20:37:17 hmm, I will make MR for 3.11 and assign to maintainer, he should decide what to do 2021-01-19 20:50:20 maxice8: did you have a proposal somewhere about adding version numbers to libraries so they can be installed in parallel? 2021-01-19 20:51:06 im searching in my inbox with 50k+ messages, and im not sure what i shoudl search for 2021-01-19 20:51:41 i should set up a serach filter based on list-id, but its a bit inconvenient in claws-mail 2021-01-19 20:53:36 ncopa: this one? https://lists.alpinelinux.org/~alpine/devel/%3C86c7a81e-1640-7f82-9e13-dfdbe1aad07b%40gmail.com%3E 2021-01-19 20:58:20 thanks 2021-01-19 20:58:37 managed to set up a filter in claws-mail on list-id and found it 2021-01-19 20:58:38 ikke: I tested idea of crystal bootstrap from self, i.e. using provides 2021-01-19 20:58:52 use mutt Luke :) 2021-01-19 21:00:31 ikke: solutions to bootstrap is too much simple that I'm disappointed, I wanted to discover something cleaver and shiny :) 2021-01-19 21:00:46 hehe :P 2021-01-19 21:15:17 ikke: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.9 and commit f1cd8c40936ff2b560e1f35159dd6a4602b558e5 2021-01-19 21:15:36 Ariadne: speaking of dhcpcd, Roy is fighting for his life. Might want check if there is someone helping him with dhcpcd maintenance. https://roy.marples.name/blog/posts/cancer/ 2021-01-19 21:15:43 maybe it is related to problem you had with upgrade 2021-01-19 21:17:09 ugh. my time is up. didnt even have time to read that versioned names proposal :-( 2021-01-19 21:18:37 in general, im afraid of ending up need to provide security patches to N different versions of each library for 5 git branches 2021-01-19 21:19:48 Then you should stop being afraid because I never even alluded to that in the proposal 2021-01-19 21:22:17 mps: talks about discovery controllers 2021-01-19 21:22:26 and smart, not sure if it's related 2021-01-19 21:23:16 ncopa: I had issues booting alpine 3.13 on a server with lvm volumes 2021-01-19 21:23:42 nvme-fc: avoid calling _nvme_fc_abort_outstanding_ios from interrupt context 2021-01-19 21:24:08 not sure, though 2021-01-19 21:28:16 too technical to know if it's linked 2021-01-19 21:28:32 especially because I have no clue what is causing it in the first place 2021-01-19 21:28:44 but switching kernels makes a difference 2021-01-19 21:30:20 nvm(e) :) 2021-01-19 21:31:08 lol 2021-01-19 22:43:17 <[[sroracle]]> bratkartoffel: ikke: it is known that nextcloud only supports major upgrade N from previous major version N-1. they say this somehwere in their website and docs 2021-01-19 22:54:09 "calls" is currently broken in edge. can somebody take a look at this MR, which will fix it? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17034 2021-01-19 22:55:06 Making food 2021-01-19 22:58:23 am looking at wiki now, thinking what to do about it 2021-01-19 22:59:55 i think what we need to do is focus exclusively on alpine-specific stuff, and point everything generic to Arch wiki. we don't have manpower to keep generic articles up to date, and imo it's a waste of time anyways when 90%+ is same across all distros (except debian which is persistently ancient) 2021-01-19 23:00:31 rfc: ^ 2021-01-19 23:21:17 gitlab seems to have gone to lunch 2021-01-19 23:21:36 builds consistently give that error: fatal: could not read Username for 'https://gitlab.alpinelinux.org': No such device or address 2021-01-19 23:27:10 hmmm, weird, looks like it only does it for my fork, not for alpine/aports 2021-01-19 23:27:33 anyway, dnsfunnel is ready for beta testing: !17040 2021-01-19 23:29:47 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17040/diffs?commit_id=da875e21d18105249c0062b00c393b196dccadec 2021-01-19 23:29:58 new aport 2021-01-19 23:30:48 COMMITSTYLE.md 2021-01-19 23:32:38 not sure about copyright for dnsfunnel.initd 2021-01-19 23:33:23 psh. who cares for how small it is. ISC like upstream, if that's okay? whatever makes Alpine happy. 2021-01-19 23:34:00 other things looks good, except maybe add comment after 'options="!check"', why check is disabled 2021-01-19 23:34:47 ok, will edit 2021-01-19 23:34:47 as they say, ianal, so don't know really 2021-01-19 23:35:35 but I usually don't assing copyright to self in scripts 2021-01-19 23:35:46 or anything in alpine 2021-01-19 23:35:49 uuuuh, there *is* a copyright in dnsfuinnel.initd 2021-01-19 23:35:59 so I don't get your comment 2021-01-19 23:36:11 you mean I should remove it? I originally copied it from another package 2021-01-19 23:36:45 (and then copied the copy, the original was from a long time ago, so no, I can't tell you what package it was) 2021-01-19 23:36:59 as I wrote, ianal, so really don't know, but most of us don't assign copyright in init scripts 2021-01-19 23:37:25 if it's important you can remove it for all I care, I'm not going to sue anyone over that file 2021-01-19 23:37:42 :) 2021-01-19 23:41:42 added a comment after !check. It's enlightening. 2021-01-19 23:42:28 :) 2021-01-19 23:44:40 I didn't learned (and probably never will) to make comments directly in gitlab MRs 2021-01-19 23:46:00 I just made a new commit locally and pushed it 2021-01-19 23:46:07 okay, so gitlab *does* have a problem 2021-01-19 23:46:25 >>> dnsfunnel: Checking sha512sums... 2021-01-19 23:46:25 dnsfunnel-0.0.1.0.tar.gz: FAILED 2021-01-19 23:46:31 the tarball has not changed 2021-01-19 23:46:37 what is it smoking? 2021-01-19 23:47:14 also, it is not applying the previous upgrades, so it builds dnsfunnel with the old versions of its dependencies, which will make a buggy binary 2021-01-19 23:47:59 anyway I'm dumping this all to you folks, and I'm going to do something else before sleep :P 2021-01-20 01:11:36 looks s390x builders hangs 2021-01-20 07:39:51 I like this changelog, very short. 2021-01-20 07:39:57 `Many fixes. Can't bother to list them. You can get the list of changes from git.` 2021-01-20 08:31:04 More honest way of saying 'bug fixes and performance improvements" 2021-01-20 08:32:34 My favorite 2021-01-20 08:34:11 this one 'All users of the 5.10 kernel series must upgrade' 2021-01-20 09:52:33 ncopa: ping 2021-01-20 10:02:55 morning 2021-01-20 10:03:13 maxice8: pong 2021-01-20 10:07:02 ncopa: Is it possible to have boost-dev be a metapackage that depends="boost1.75=$pkgver-r$pkgrel" or that also runs into ordering problems ? 2021-01-20 10:09:44 I think that should work 2021-01-20 10:17:42 Is there a way to test it 2021-01-20 10:17:52 !17094 ? 2021-01-20 11:13:40 hehe, https://lwn.net/Articles/843169/ 2021-01-20 11:13:52 not totally OT 2021-01-20 11:15:05 I like this "Aaaaaah! The sky is falling, upgrade NOW!" 2021-01-20 11:22:14 Some embargoed CVE? 2021-01-20 11:24:55 Seems like libgit2-static is just broken 2021-01-20 11:25:08 maybe -static is fine :D 2021-01-20 11:25:38 using -DUSE_HTTP_PARSER=system seems to prevent http_parser symbols from being included in the static archive 2021-01-20 11:47:51 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12335 2021-01-20 11:47:59 can someone decipher what is happening here ^ 2021-01-20 11:52:04 πŸ€” 2021-01-20 11:52:58 We have p11-kit 0.33.22, and it needs to be upgraded to 0.33.22? 2021-01-20 11:53:38 23.22 but yes 2021-01-20 11:53:54 I think the reporter confused secfixes with where there are security issues and thinks there is a new version that has those fixes ? 2021-01-20 11:54:56 0.23.22 is the latest upstream release 2021-01-20 12:30:38 Hi. I currently have a problem with ci on aports. The job fails because of 'make: /usr/bin/make: Operation not permitted' in cmake while checking the compiler. My immediate thought was, that it might have to do something with file permissions, although I have no idea what I should do to fix this issue. Here's the link to the job: 2021-01-20 12:30:39 https://gitlab.alpinelinux.org/lmarz/aports/-/jobs/298457 2021-01-20 12:32:37 Hello71_: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12311 2021-01-20 12:35:07 ikke: I highly doubt this issue is seccomp related 2021-01-20 12:35:16 Yes, me too 2021-01-20 12:36:06 there is at least one thing the reporter is hiding or highly misled about: the code says [[ but the error says sh 2021-01-20 12:36:55 This error happens before user code is executed 2021-01-20 12:37:00 also the error is invalid argument, not permission denied 2021-01-20 12:37:23 Ie, gitlab runner is trying to invoke a shell I guess 2021-01-20 12:37:44 Hello71_: I ran into this in november (and even before that) 2021-01-20 12:37:50 with alpine:edge at that time 2021-01-20 12:38:09 ikke: see lmarz, I thought you upgraded x86_64? 2021-01-20 12:38:10 even 'echo hello world' would give the same error 2021-01-20 12:38:29 Hello71_: to 3.12, so it does not have libseccomp 2.4.4 yet 2021-01-20 12:38:55 wait then what were you upgrading it for 2021-01-20 12:39:13 I wanted to upgrade it to 3.13 2021-01-20 12:39:29 but ran into some issues related to the kernel 2021-01-20 12:39:39 (which took all weekend to find out) 2021-01-20 12:39:51 x86 is 3.13 already 2021-01-20 12:40:30 ah 2021-01-20 15:25:07 Hello71_: Note that we have the same issue at $work on specific runners 2021-01-20 15:25:22 but on a runner I control with docker 19.03 and libseccomp 2.4.3, it works 2021-01-20 15:26:10 well starting from the assumption that it's got nothing to do with the posted code, i think the first question is to investigate what sh is writing to 2021-01-20 15:26:53 I was trying to look in the gitlab-runner code 2021-01-20 15:27:10 in particular it's interesting that the error is "Invalid argument". this excludes for example "Bad file descriptor" 2021-01-20 15:28:15 ah, the github issue is more helpful 2021-01-20 15:32:53 hm.... maybe TIOCGWINSZ is failing? 2021-01-20 15:35:32 ikke: try the following: echo true | sh; echo echo hello | sh; echo true | strace sh; echo echo hello | strace sh 2021-01-20 15:35:48 you can probably go from the end and see which one succeeds first 2021-01-20 15:37:01 not sure why that would be different between 3.13 and edge though, hm 2021-01-20 15:37:23 ah, they say it doesn't work on 3.13 2021-01-20 15:38:53 I already had the same issue before 3.13 was released on edge 2021-01-20 15:39:04 I don't think it executes anything you provide yet 2021-01-20 15:39:09 It seems to fail before that 2021-01-20 15:39:35 Hello71_: I have 'echo hello world' it failed before even executing that 2021-01-20 15:40:04 aha, i think it is failing to write to /dev/tty 2021-01-20 15:40:18 which unfortunately makes it a little hard to diagnose 2021-01-20 15:40:33 what happens if you just put true 2021-01-20 15:40:51 Hello71_: let me try 2021-01-20 15:41:25 Hello71_: I can also try to provide an entry point text 2021-01-20 15:41:33 instead of using script: 2021-01-20 15:42:39 first check script: true. if that fails then it's almost certainly failing to write to /dev/tty 2021-01-20 15:43:29 But why would the alpine version matter? 2021-01-20 15:43:36 it works for 3.12 2021-01-20 15:43:56 well that's the next question :) 2021-01-20 15:45:11 Fails as well 2021-01-20 15:46:14 try image:entrypoint: /bin/true then 2021-01-20 15:49:14 also what arch and docker version are you using 2021-01-20 15:50:37 x86_64 2021-01-20 15:51:22 I don't know the docker version, have to ask 2021-01-20 15:52:19 That entrypoint works 2021-01-20 15:54:38 Setting the entrypoint to /bin/sh -c fails with the same error 2021-01-20 15:57:45 try /usr/bin/strace /bin/sh -c true 2021-01-20 15:58:17 The image has no strace 2021-01-20 15:59:29 I can do /bin/sh -c 'apk add strace', and even get output 2021-01-20 16:00:39 what do you mean by 2021-01-20 16:00:41 15:54 <@ikke> Setting the entrypoint to /bin/sh -c fails with the same error 2021-01-20 16:03:25 entrypoint: [/bin/sh, -c] 2021-01-20 16:04:15 (I have to provide a script section as well, with an empty string as first element 2021-01-20 16:04:54 hm... maybe docker is upset about {iov_base=NULL, iov_len=0} 2021-01-20 16:08:14 but that didn't change in musl 1.2 2021-01-20 16:08:54 dunno, i don't have enough information to diagnose the issue. it could be kernel version related too 2021-01-20 16:18:48 I haven't seen it yet on any of the alpine systems 2021-01-20 16:18:53 alpine CI 2021-01-20 16:19:23 Hello71_: Do you think it would help to have an image with strace and then try to run sh -c there? 2021-01-20 16:19:30 probably 2021-01-20 16:19:49 if you can find out how to actually invoke it 2021-01-20 16:20:36 yea 2021-01-20 16:20:49 maybe an entrypoint 2021-01-20 16:22:57 Hello71_: thanks for your helpt btw 2021-01-20 16:24:40 i asked for docker version and docker info in the github issue, since it seems that you can't get it atm 2021-01-21 00:03:57 Is there a preferable date and time for me hogging the builders for the python3 3.8->3.9 transition ? 2021-01-21 01:28:14 maxice8: now is a good time 2021-01-21 01:28:50 I'm not ready 2021-01-21 01:30:16 lets aim for friday evening 2021-01-21 01:30:29 or do you need more time/ 2021-01-21 01:30:53 Can be 2021-01-21 04:33:34 Ariadne: can you ok !17127 ? 2021-01-21 04:41:26 ty 2021-01-21 04:41:52 though we should move these tools out of aports 2021-01-21 04:41:53 imo 2021-01-21 04:42:04 oh derp, we forgot the checksum 2021-01-21 04:42:21 feel free to fix it 2021-01-21 04:42:35 I'm not at my computer right now 2021-01-21 04:42:35 phew 2021-01-21 04:42:42 I was worried there was a sniper dot pointing at me 2021-01-21 04:43:43 fixed 2021-01-21 05:44:18 What is the version I put stuff we are not affected by 2021-01-21 05:44:56 maxice8: ? 2021-01-21 05:45:08 pdns has 3 CVEs which are present if one has --enable-experimental-gss-tsig, we don't have that enabled 2021-01-21 05:45:15 https://doc.powerdns.com/authoritative/security-advisories/powerdns-advisory-2020-06.html 2021-01-21 05:46:57 version 0? :P 2021-01-21 05:47:12 ncopa recommended as far as I remember 2021-01-21 06:28:20 maxice8: https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/68810 2021-01-21 06:29:00 Yes? 2021-01-21 06:29:09 notice something? 2021-01-21 06:30:50 It's all green which is suspect consdering how the CI currently is 2021-01-21 06:31:38 maxice8: then inspect further 2021-01-21 06:34:01 ? 2021-01-21 06:39:55 You said it was suspect 2021-01-21 06:40:19 yes 2021-01-21 06:40:27 if you look at the jobs, does it look bogus? 2021-01-21 06:40:43 no 2021-01-21 06:40:47 so.. 2021-01-21 06:42:02 so nothing 2021-01-21 06:42:04 Β―\_(ツ)_/Β― 2021-01-21 06:42:34 sad trombone 2021-01-21 06:43:05 I've changed the seccomp profile on the runners so they no longer block faccessat2 2021-01-21 06:43:28 oh 2021-01-21 06:43:42 that's good 2021-01-21 06:43:47 yes :) 2021-01-21 06:56:33 wondering whats up with dnsfunnel 2021-01-21 06:56:46 I'll look at it later 2021-01-21 08:16:44 Hello71: https://tpaste.us/OQOb strace output where the write error occurs 2021-01-21 09:57:34 fcolista: you upgraded re2 a few hours ago, but note that several packages need rebuilds because of that 2021-01-21 09:58:02 See https://git.alpinelinux.org/aports/commit?id=f444918c4e22dbe1224e0c3aa779f6093c2b717f 2021-01-21 11:12:45 ikke: yes, i replied in #musl 2021-01-21 11:12:47 thanks 2021-01-21 11:51:35 I just did my first merge! Not sure if I like the anxiousness that came from it lol 2021-01-21 11:51:58 PureTryOut[m]2: heh :P 2021-01-21 11:52:16 PureTryOut[m]2: congrats 2021-01-21 11:52:28 CI was green but still I'm thinking, "but what if it breaks on the builders?!" 2021-01-21 11:52:30 PureTryOut[m]2: after more than 2 years I still feel it :) 2021-01-21 11:52:37 Haha good to know 2021-01-21 11:53:02 A health dose of cautiousness is never a bad thing 2021-01-21 11:54:25 Definitely 2021-01-21 11:55:16 I'm always scared merging MRs with multiple commits with "squash on merge" checked since I once messed up selecting the right commit for the new commit msg 2021-01-21 11:56:05 I don't like squash on merge tbh. If they should be squashed, do it before merging. Imo anyway 2021-01-21 11:56:45 I could just disable it :P 2021-01-21 11:57:03 Btw should !17195 wait for the builders to catch up? CI won't be green except for some arches as most arches still haven't caught up with the upgraded packages 2021-01-21 11:57:32 https://ibb.co/BG7zGY5 2021-01-21 11:57:50 Personally I'd be in favor of disabling that option altogether yes 2021-01-21 11:57:55 PureTryOut[m]2: maybe for piece of mind :) 2021-01-21 11:57:58 But others might disagree 2021-01-21 11:58:01 Would be best to not need squash on merge, but some contributors which are only starting to use git(lab) don't really get how to squash things 2021-01-21 11:58:15 Cogitri: luckily we can squash locally 2021-01-21 11:58:27 It's just less things that can go wrong if you're forced to not use the web UI for it 2021-01-21 11:58:32 Yeah, but that take more time 2021-01-21 11:58:42 which apparently is not a bad thing :P 2021-01-21 11:58:48 Yeah 2021-01-21 11:59:05 You can inspect the results before pushing it 2021-01-21 11:59:21 Exactly 2021-01-21 11:59:43 PureTryOut: builder-breaking worry never goes away 2021-01-21 12:04:05 it does transform though 2021-01-21 12:07:21 ikke: this is good idea, do it :) (please) 2021-01-21 12:07:55 I'll do it with enough consensus 2021-01-21 12:08:14 do it 2021-01-21 12:08:44 what!? my vote is not enough to prevail all :D 2021-01-21 12:09:14 never was 2021-01-21 12:09:22 That's at least 3 votes in favor already 2021-01-21 12:10:51 The community repository is only supported for one release right? There is a security issue open for a community package in 3.12, should I still bother fixing it? 2021-01-21 12:11:48 We do not prohibit it 2021-01-21 12:12:01 (some people lost sense of humor) 2021-01-21 12:12:23 PureTryOut: no promises of support for that but feel free to fix it if you wish 2021-01-21 12:12:27 PureTryOut[m]2: it's basically a best effort from that point 2021-01-21 12:13:42 Well I have no desire to fix it tbh. Only if we still actively support the branch 2021-01-21 12:13:57 Can be closed then 2021-01-21 12:14:16 Good 2021-01-21 12:47:07 ikke: do you know the kernel version of the mips64 builder? 2021-01-21 12:47:50 It's some bsp mernel 2021-01-21 12:47:54 Kernel 2021-01-21 12:48:17 I can verify later which 2021-01-21 12:49:22 I am asking because of -https://gitlab.alpinelinux.org/alpine/aports/-/issues/12327#note_137460 2021-01-21 12:54:48 Not something trivially to change 2021-01-21 12:56:07 yeah... 2021-01-21 12:58:00 I have been trying to track down what of the cavium's octeon III patches got accepted, it is a mess... 2021-01-21 12:58:34 *kernel patches 2021-01-21 13:10:02 @PureTryOut[m]2, I know and I've done a bump pkgrel for the related packages 2021-01-21 13:11:08 see commit: 165eace3025c63e9ca6e7469200fab119ed3aff1 and 3d22763916798cebc43eb84cc9bb2bdc9baa7b5c 2021-01-21 13:11:21 Oh huh, I missed those 2021-01-21 13:11:26 In that case, ignore me πŸ˜‰ 2021-01-21 13:11:31 the only one I couldn't bump the pkgre was for qt5-qtwebengine 2021-01-21 13:11:49 https://www.qt.io/blog/problem-with-open-source-downloads 2021-01-21 13:12:04 https://twitter.com/qtproject/status/1351838327520026625 2021-01-21 13:12:37 download.qt.io is down 2021-01-21 13:16:13 Oh ouch 2021-01-21 13:16:21 And exactly qt5-qtwebengine is the one of my MR's needs... 2021-01-21 13:19:13 yes...untli the download.qt.io is not up, we cannot bump the pkglre... 2021-01-21 13:19:20 Yeah 2021-01-21 13:19:21 Darn it 2021-01-21 13:19:49 if you still have copy then could put it on alpinelinux site 2021-01-21 13:20:27 distfiles.a.o probably has it 2021-01-21 13:20:29 nope...I don't think is a good idea 2021-01-21 13:20:55 So on the builders it would just work 2021-01-21 13:21:50 they should fix quite soon since is already 2 days that they are down. I would not modify the APKBUILD to point to distfiles andthen put again download.qt.io 2021-01-21 13:22:55 The builders transparently download it from distfiles 2021-01-21 13:25:03 done 2021-01-21 13:26:31 I was just about to ask why it got committed anyway haha. Good job 2021-01-21 13:27:57 vecause ikke's comment 2021-01-21 13:27:58 *because 2021-01-21 13:28:28 Yeah I know, I read the backlog before I was about to ask πŸ˜‰ 2021-01-21 13:28:40 that's a good habit ;-) 2021-01-21 13:51:46 ikke, ncopa: regarding busybox regression, should we backport busybox or musl patch, or both? 2021-01-21 13:52:33 i think these patches are both fairly low risk (assuming dalias approves musl patch), and i think we should apply at least one soon 2021-01-21 14:02:26 Hello71: I think we should backport to alpine edge, have someone to test and then backport to 3.13 2021-01-21 14:02:44 i can do that, (once this meeting im in is over) 2021-01-21 14:03:47 but which one? or both? i feel like i've tried to ask "should we do a or b" and your answer is "yes" :p 2021-01-21 14:04:28 I can test it on edge 2021-01-21 14:15:22 musl should be fixed, and bb fix probably will not hurt 2021-01-21 14:20:58 ikke: if you have some time can you test http://lists.busybox.net/pipermail/busybox/2021-January/088491.html and https://bpa.st/SVMAO? 2021-01-21 14:22:53 i pushed it to alpine edge 2021-01-21 14:23:44 ok :) 2021-01-21 14:23:45 which one 2021-01-21 14:24:06 ah, only busybox patch 2021-01-21 14:24:30 i think we probably need to apply musl patch too. there's most likely other broken software out there, just not reported yet 2021-01-21 14:24:39 but that one can wait until dalias reviews 2021-01-21 14:37:17 scrolling in firefox sometimes makes my X11 crash with intel GPU... i suppose some alpine users also had this problem - anyone remembers how and if this was fixed in alpine ? 2021-01-21 14:38:28 sh4rm4^bnc: some of specific gpu? 2021-01-21 14:40:32 it's an intel 965 iirc, but it dont see anything in dmesg that would confirm that 2021-01-21 14:40:49 ah, [ 3.036420] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device 2021-01-21 14:41:44 this also happened on my 10 year old laptop with another older intel chip, but much less frequently 2021-01-21 14:42:14 3.181556] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device 2021-01-21 14:42:45 old macbook pro, FF works without problem 2021-01-21 14:43:14 i've yet to catch the crash with eth0 and openssh activated since it seems the network is still up then, even though all input devices and graphics are dead after the crash, to get a look into Xorg.log 2021-01-21 14:43:42 mps: i suspect alpine had this fixed somehow years ago 2021-01-21 14:44:13 sh4rm4^bnc: ah, you are on something other than alpine? 2021-01-21 14:44:24 yeah, sabotage (my own distro) 2021-01-21 14:44:45 ah, yes I remember (you told me earlier) 2021-01-21 14:44:54 so it's one developer vs dozens behind alpine :) 2021-01-21 14:45:11 you are calling me to join :) 2021-01-21 14:45:17 :))) 2021-01-21 14:45:47 I looked at it to some degree but didn't tried to boot 2021-01-21 14:48:30 sh4rm4^bnc: btw, my wife also run alpine on one old intel notebook and it works fine 2021-01-21 14:48:49 s/run/use/ 2021-01-21 14:48:49 mps meant to say: sh4rm4^bnc: btw, my wife also use alpine on one old intel notebook and it works fine 2021-01-21 14:48:56 most people discard sabotage when they realize that some components aren't bleeding edge... 2021-01-21 14:49:21 i personally value stability way more 2021-01-21 14:49:44 I don't run bleeding edge on production systems 2021-01-21 14:49:56 also I 2021-01-21 14:50:36 when i look at void linux it appears obscene tbh, they push updated pkgs 5 minutes after something had a new release 2021-01-21 14:50:50 if I want 'featurist' OS I would use ubuntu or similar 2021-01-21 14:51:31 heh, because that we have stable releases 2021-01-21 14:53:20 even long time sabotage followers are like "gosh why do you use lxde version from 2014?" and even if i tell them that i fixed all bugs, it's super stable and doesn't depend on QT they don't get it... "but... it's so old!!!1" 2021-01-21 14:53:51 yes, NG people 2021-01-21 14:54:05 (Not Good, ofc :) ) 2021-01-21 14:54:09 :) 2021-01-21 14:54:59 I use 'slim' DM which is also from 2012 or 2014 2021-01-21 14:56:01 removed udev and dbus, also 2021-01-21 14:56:06 after sabotage booted up and the default LXDE desktop is loaded, it uses a total 12MB of RAM 2021-01-21 14:56:41 till you run firefox :) 2021-01-21 14:56:49 i don't think you could get it much slimmer than that without heavily compromising user XP 2021-01-21 14:57:02 heh yeah 2021-01-21 14:57:43 actually i run palemoon but firefox had the same problem in the past so i'm pretty certain it's got to do with the way the ff engine renders/uses X11 2021-01-21 14:58:18 could that be your issue, firefox don't like to compromise your work for small system and it crashes :) 2021-01-21 14:58:33 maybe :> 2021-01-21 14:59:14 I thought to package palemon for alpine but license stopped me 2021-01-21 15:01:05 And palemoon last I checked wasn't interested in musl compat 2021-01-21 15:01:59 is firefox ? i apply the same patches to palemoon that i used to use for FF 52.9-esr 2021-01-21 15:02:02 maxice8: also this 2021-01-21 15:06:24 i use palemoon because it doesn't require rust. but it also has other advantages, like building in a 1/3th of the time of FF 52 2021-01-21 15:18:02 does palemoon backpoort security fixes from firefox? 2021-01-21 15:18:17 pretty sure it's diverged too much 2021-01-21 15:18:39 if it were easy then mozilla would do it themselves 2021-01-21 15:25:28 > i apply the same patches to palemoon that i used to use for FF 52.9-esr doesn't suggest that > it's diverged too much 2021-01-21 15:26:01 are there firefox security fixes for 52.9-esr 2021-01-21 15:26:29 postfix appears to be newer in 3.12 than in 3.13, cc ncopa 2021-01-21 15:27:37 does palemoon backpoort security fixes from firefox? 2021-01-21 15:27:56 yeah, those that apply to their codebase. they also have a "defense in depth" idiom 2021-01-21 15:29:22 hmm, didn't I backported postfix, lets see 2021-01-21 15:30:32 huh, I forgot 2021-01-21 15:33:34 how does that > "defense in depth" idiom materialize? 2021-01-21 15:39:58 Hi all. Considering trying to package up emborg (a borgbackup front end) for Alpine. I see one of the options for abuild is to build packages that install from PyPi. Is this a 'good' approach to take? 2021-01-21 15:40:25 Installing packages from pypi on the package ? 2021-01-21 15:41:20 maxice8: No. From https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package: "apkbuild-pypi ease the generation of APKBUILD files for python packages from PyPi." 2021-01-21 15:41:38 emborg is already on PyPi, so I wondered if that might make building a package for alpine easier? 2021-01-21 15:42:12 No, it is just expected, fetch the source from pypi (or the main source if pypi tarball doesn't include tests) and build them like any other package. 2021-01-21 15:42:33 Ariadne: ping, tomorrow night is the py3.9 transition ? 2021-01-21 15:42:49 Oh ok. I'll have a play then and see how far I get. 2021-01-21 15:44:40 Is that the best document to work from, or is there a more comprehensive 'newbie' tutorial? 2021-01-21 16:05:52 ncopa: bb started to give Stat usage output on upgrade btw 2021-01-21 16:08:22 ncopa: seems it works 2021-01-21 16:08:41 When I upgrade bb in the entrypoint, it goes through 2021-01-21 16:23:38 ddevault: looks like postfix-3.5.9 was pushed to 3.13-stable 2021-01-21 16:23:48 thanks 2021-01-21 16:28:26 hello71, the musl patch introduces crash into valid programs on oom 2021-01-21 16:28:33 so don't include it 2021-01-21 16:28:37 ugh 2021-01-21 16:28:47 what else do you do in that case 2021-01-21 16:28:55 free it later? 2021-01-21 16:29:18 we could arrange to try freeing it later but that's nontrivial 2021-01-21 16:31:03 we could re-queue it to a free group list to just keep using it (but it might not be suitably sized), or we could linear search all existant groups to see if it's immediately following one, and if so, increase that one's map length to encompass it so it gets freed when that one does 2021-01-21 16:31:33 but a program in this state is likely on the verge of critical OOM'ing anyway and not going to make much forward progress 2021-01-21 16:32:12 you just want to ensure it doesn't crash so it can handle that and exit safely without loss of data/unrestored state 2021-01-21 16:32:52 i don't think it's worth putting a lot of effort, code size, and bug surface into accounting for and freeing the memory that failed to unmap 2021-01-21 16:34:14 anyway i would do just the busybox patch for now 2021-01-21 16:34:43 this is a busybox bug -- there is no current standard that requires free to preserve errno, and the "if (errno)" idiom is almost universally wrong anyway 2021-01-21 16:35:05 this is classic busybox "let's save 10 bytes of .text by doing something wrong" 2021-01-21 16:35:43 and the only possible motivation for "if (errno)" rather than "if (r i already pushed a patch to alpine edge, sent a fix upstream (which also saves 8 bytes), and will back port it once its tested 2021-01-21 16:36:34 busybox patch http://lists.busybox.net/pipermail/busybox/2021-January/088491.html 2021-01-21 16:36:53 :) 2021-01-21 16:36:55 ncopa: I tested it 2021-01-21 16:36:58 yay 2021-01-21 16:37:07 saving 8 bytes will at least ensure they accept it :-P 2021-01-21 16:37:10 :D 2021-01-21 16:37:31 that was the reason, to improve changes that they will accept it :) 2021-01-21 16:38:06 chances* 2021-01-21 16:38:22 s/changes/chances/ 2021-01-21 16:38:22 ncopa meant to say: that was the reason, to improve chances that they will accept it :) 2021-01-21 16:39:04 heh i want a bot that understands the replacement* notation 2021-01-21 16:39:55 The format is underspecced, though :P 2021-01-21 16:40:29 (look for lowest-levenshtein-distance match, resolve ambiguities with some sort of markov chain model for which instance is likely wrong :) 2021-01-21 16:40:53 partly because it would be hilarious when it makes the wrong replacement and we'd get to laugh at "lol look how idiotic ai is" :-p 2021-01-21 16:41:44 ai... lol 2021-01-21 16:42:05 ncopa: docker run -it --rm alpine:edge apk add -u busybox 2021-01-21 16:43:07 of course it's not really "ai", just an optimization problem with basic text algorithms and markov chains 2021-01-21 16:43:18 What's the difference? :P 2021-01-21 16:43:23 exactly :) 2021-01-21 16:44:15 but i mean there's no tensorflow or GPUs or ... :-P :-P :-P 2021-01-21 16:47:04 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12311#note_137667 2021-01-21 16:47:17 Is it correct what I've written there? 2021-01-21 16:48:52 looks correct, yes. thanks! 2021-01-21 16:49:29 yes 2021-01-21 16:50:40 dalias can you please alos give a quick look at http://lists.busybox.net/pipermail/busybox/2021-January/088491.html i think its correct but... 2021-01-21 16:51:52 LGTM 2021-01-21 16:52:00 πŸ‘ 2021-01-21 16:52:05 thanks 2021-01-21 16:52:13 and yay i'm still subscribed to busybox list. hadn't opened the folder in a couple years i think :-p 2021-01-21 16:53:56 i think we should do 3.13.1 early next week 2021-01-21 16:54:30 the apk-tools fix, busybox fix and greg's "all users must upgrade" 2021-01-21 16:54:32 I wonder what we should do with the docker faccessat2 issues 2021-01-21 16:54:49 I have solved it now for our CI,but lots of users run into issues as well 2021-01-21 16:54:58 looks like glibc has same problem nowdays 2021-01-21 16:55:30 i havent digged into the dirty details yet, but from reading the comments, it looks complicated to solve it 2021-01-21 16:55:30 runc is fixing it, but takes time before everyone has that version 2021-01-21 16:55:45 https://github.com/opencontainers/runc/pull/2737 2021-01-21 16:56:34 Hello71: Do you know what the consequences are from switch the default seccomp action from SCMP_ACCT_ERRNO to SCMP_ACCT_TRACE? 2021-01-21 16:57:32 well it makes the seccomp not a security boundary 2021-01-21 16:57:45 so if it's blocking things that would compromise the host, now they're no longer blocked 2021-01-21 16:57:48 Hi. Getting this when trying to run apkbuild-pypi: https://termbin.com/wv9f 2021-01-21 16:57:59 dalias: right, I figured as mutch 2021-01-21 16:58:08 s/mutch/much/ 2021-01-21 16:58:08 ikke meant to say: dalias: right, I figured as much 2021-01-21 16:58:55 can you add a second seccomp filter inside the container to block new syscalls right? 2021-01-21 16:59:56 Is this an appropriate place to ask newbie packaging questions by the way? Happy to be pointed to somewhere more appropriate. 2021-01-21 17:00:05 adhawkins: yes, certainly 2021-01-21 17:00:18 Don't need to ask to ask if you ask in the wrong place we will just redirected to the correct place 2021-01-21 17:00:23 adhawkins: hi welcome! 2021-01-21 17:01:13 dalias: I guess, no clue 2021-01-21 17:02:56 i'm not sure how nesting seccomp works 2021-01-21 17:04:15 The problem is that even though with an updated seccomp profile with faccessat2, it's still blocked due to an outdated libseccomp 2021-01-21 17:04:56 It apparently needs to know about new syscalls as well 2021-01-21 17:07:45 timlegge: do you know what that error means? ^^ 2021-01-21 17:09:18 maxice8: yes, lets do it tomorrow night 2021-01-21 17:09:55 right, i'm wondering if there's something you can do inside the container since the container runtime is broken 2021-01-21 17:10:15 anyway 2021-01-21 17:10:35 i'm kind of surprised that the seccomp filters still haven't been updated 2021-01-21 17:10:43 i held faccessat2 back 4 months ago 2021-01-21 17:10:43 Ariadne: that's not the issue 2021-01-21 17:10:49 they _have_ been updated 2021-01-21 17:10:52 but it's not enough 2021-01-21 17:10:57 In that case, can anyone help with why apkbuild-pypi is generating these errors? https://termbin.com/wv9f 2021-01-21 17:10:58 hmmph 2021-01-21 17:11:20 adhawkins: timlegge does a lot with perl, so maybe he can help 2021-01-21 17:11:32 pypi is not cpan :P 2021-01-21 17:11:41 Ariadne: no, but that script is written in perl 2021-01-21 17:11:58 Ah, didn't realise that. Presumably some missing perl dependency then? 2021-01-21 17:12:13 Ariadne: apparently you need at least libseccomp 2.4.4 for faccessat2 2021-01-21 17:12:18 yes, missing IPC::System::Simple 2021-01-21 17:12:32 Unfortunately apkbuild-pypi is not maintained like apkbuild-cpan 2021-01-21 17:12:43 ikke: i am really starting to become skeptical about seccomp ;/ 2021-01-21 17:12:50 Ah ok. Not sure it would actually give me very much anyway. 2021-01-21 17:12:53 only starting? 2021-01-21 17:12:58 what held you back? 2021-01-21 17:13:07 ok, i've been skeptical all along :P 2021-01-21 17:13:12 Is there an easy way to ensure that nobody has packaged up the following pypi modules? arrow inform quantiphy shlib 2021-01-21 17:13:12 but now i'm really skeptical 2021-01-21 17:13:13 any opinion about this !17032 objections or ....? 2021-01-21 17:13:31 apk show py3-$(module) doesn't show anything for them, but want to be sure the name hasn't been changed slightly. 2021-01-21 17:13:53 in theory, seccomp sounds nice, but in practice, it seems very fragile 2021-01-21 17:13:54 Sorry, that should have been apk info py3-$(module) 2021-01-21 17:14:09 and, there is the possibility that you can defeat it by owning the BPF VM 2021-01-21 17:14:10 ikke: what is the question about this script 2021-01-21 17:14:23 mps: adhawkins ran into an error 2021-01-21 17:14:30 ah 2021-01-21 17:14:34 https://termbin.com/wv9f 2021-01-21 17:14:40 Ariadne: dnsfunnel has been merged (thanks Leo), in testing/ atm, for betatesting, if you know caches/servers with answers that need truncation or with wrong nxdomains 2021-01-21 17:14:48 I've tested the normal case reasonably well 2021-01-21 17:14:55 Was the CI issue with dnsfunnel fixed? 2021-01-21 17:15:03 yes 2021-01-21 17:15:07 ah, what was it? 2021-01-21 17:15:17 Ariadne: already answered :) I think 2021-01-21 17:15:25 ikke: which one? there were several XD 2021-01-21 17:15:41 skarnet: I recall you mentioning 2 issues 2021-01-21 17:15:54 checksum mismatch 2021-01-21 17:15:58 and outdated dependencies 2021-01-21 17:16:00 adhawkins: how you invoke this command 2021-01-21 17:16:01 ikke: are you Leo? 2021-01-21 17:16:03 skarnet: no 2021-01-21 17:16:09 maxice8 here is Leo 2021-01-21 17:16:12 ooooh 2021-01-21 17:16:12 I am 2021-01-21 17:16:24 mps: The command line is shown in the pastebin. 2021-01-21 17:16:31 maxice8: thanks for the push, you woke up earlier than me 2021-01-21 17:16:34 Whoops, sorry, no it's not. 2021-01-21 17:16:41 well maxice8 fixed them, not sure how 2021-01-21 17:16:41 :) 2021-01-21 17:16:42 i think for example, seccomp should allow syscalls by default 2021-01-21 17:16:48 mps: apkbuild-pypi create emborg 2021-01-21 17:16:53 and you just specify the ones that are evil 2021-01-21 17:16:58 But if I just run 'apkbuild-pypi' I get the same error 2021-01-21 17:17:02 but that's not how they do it 2021-01-21 17:17:04 soooooo 2021-01-21 17:17:22 general wisdom of allowing is better then denying 2021-01-21 17:17:28 I suppose the build issue was fixed by pushing the s6-dns upgrade first, updating the gitlab builder, and *then* pushing dnsfunnel 2021-01-21 17:17:49 it should work in a single CI build 2021-01-21 17:17:57 thanks for reminding me of need to update dnsmasq 2021-01-21 17:17:58 :) 2021-01-21 17:18:04 unless you try to depend on something in testing from community 2021-01-21 17:18:07 update it to something thatis not dnsmasq 2021-01-21 17:18:20 at least it runs in unprivileged sandbox but it's still a pretty bad issue 2021-01-21 17:18:21 like systemd-resolvd 2021-01-21 17:18:23 maybe i should write a shit simple dhcp server 2021-01-21 17:18:27 ikke: well it didn't work for me, not sure what happened, but my interactions with gitlab are never smooth 2021-01-21 17:18:32 lol 2021-01-21 17:18:39 who needs it for dhcp?? udhcpd does fine 2021-01-21 17:18:45 it's dns it's needed for 2021-01-21 17:18:48 needs v6 I suppose 2021-01-21 17:18:51 i assume that is what most people use dnsmasq for 2021-01-21 17:18:53 and there are no non-awful alternatives 2021-01-21 17:18:54 skarnet: welcome 2021-01-21 17:18:58 sure there is 2021-01-21 17:19:01 there's unbound 2021-01-21 17:19:01 skarnet, radvd is all you need for ipv6 2021-01-21 17:19:17 unbound is a decent alternative 2021-01-21 17:19:17 unbound is huge and has full recursive support 2021-01-21 17:19:18 unbound is not-awful but is also not-good 2021-01-21 17:19:28 i just want a dnssec validating proxy 2021-01-21 17:19:28 adhawkins: for now 'sudo apk add perl-ipc-system-simple' 2021-01-21 17:19:29 there's also skarnet's dnsfunnel 2021-01-21 17:19:41 dnsfunnel is not validating afaik 2021-01-21 17:19:49 in beta, doesn't cache, doesn't validate, just forwards 2021-01-21 17:19:53 (and not intended to be) 2021-01-21 17:19:57 adhawkins: and python3 2021-01-21 17:20:03 ok 2021-01-21 17:20:06 systemd-resolved it is 2021-01-21 17:20:10 lol 2021-01-21 17:20:12 ACTION switches alpine to systemd 2021-01-21 17:20:23 don't worry i am just kidding 2021-01-21 17:20:25 I can write a dns cache, even a dnssec validating one 2021-01-21 17:20:32 but not for free, hint hint 2021-01-21 17:20:50 ACTION nudges nudges 2021-01-21 17:20:59 dnsmasq is the only software whose intended usage model matches mine, without loads of YAGNI generality and bloat 2021-01-21 17:21:02 skarnet, :) 2021-01-21 17:21:21 inbefore dalias starts charging for musl :P 2021-01-21 17:21:34 dalias: but dnsmasq is already full of yagni generality 2021-01-21 17:21:50 dnsmasq is full of security holes 2021-01-21 17:21:55 that too 2021-01-21 17:22:00 we should really have a "musl community bounty board" or something 2021-01-21 17:22:26 Thanks mps 2021-01-21 17:22:28 if the bounty board is aligned on those out there, no way it will be worth it 2021-01-21 17:22:32 but seriously, dnsmasq needs to die 2021-01-21 17:22:55 open to posting by ppl who have contributed to community in significant ways (bug reporting, patches, distro integration, ...) and subject to a CoC 2021-01-21 17:23:21 "i want to make a [X] but this would be a significant amount of work. anyone want to fund it? this is minimum i'd need." 2021-01-21 17:23:23 ikke: he kinda is, that's what sponsors are for 2021-01-21 17:23:56 adhawkins: if that is a perl module its apkbuild-cpan you need 2021-01-21 17:24:31 dalias: that would be really nice 2021-01-21 17:24:32 dalias: flat rates are dangerous unless you already know *exactly* where you're going 2021-01-21 17:26:47 yeah. it requires good ability to estimate time and have a billable-hours rate in mind to figure from 2021-01-21 17:27:07 i've gotten pretty good at it 2021-01-21 17:27:17 maybe i should do a blog post or something on the topic 2021-01-21 17:28:04 please do, I'm always interested in peeks into the business side of things 2021-01-21 17:28:09 Ariadne: just out of curiosity, is there anything happening with getting vanilla linux to work for the mips builders? 2021-01-21 17:28:16 ikke: LOL 2021-01-21 17:28:29 Ariadne: libseccomp was updated ages ago. problem is that docker ppa doesn't have libseccomp 2021-01-21 17:28:30 err, i mean 2021-01-21 17:28:33 not yet :))) 2021-01-21 17:28:40 Ariadne: :D 2021-01-21 17:28:41 docker... ppa? 2021-01-21 17:28:50 why would we be using a PPA? 2021-01-21 17:28:57 Not us, other people 2021-01-21 17:29:05 who use ubuntu as docker host 2021-01-21 17:29:06 i was going to say 2021-01-21 17:29:09 I DEMAND ANSWERS 2021-01-21 17:29:46 ubuntu has backported libseccomp... problem is they only backported like 2.4.2 or something and we need 2.4.4 or something 2021-01-21 17:30:04 yes, but we wouldn't be using ubuntu in our infrastructure 2021-01-21 17:30:15 Ariadne: and we only have libseccomp 2.4.4 in 3.13 2021-01-21 17:30:18 allegedly the libseccomp model does not easily allow negating filter 2021-01-21 17:30:29 right, almost nobody has backported 2.4.4 2021-01-21 17:30:33 can we backport it to 3.12? 2021-01-21 17:30:37 or does it involve ABI break 2021-01-21 17:30:46 plus those who do may not have compiled it against 5.10 headers 2021-01-21 17:31:03 ah 2021-01-21 17:31:09 so you have to backport linux-headers too 2021-01-21 17:31:11 i think libseccomp 2.5 does not require headers anymore 2021-01-21 17:31:16 meh 2021-01-21 17:31:33 I ran into the issue with a Ubuntu hosts and managed to work around it with the details of from the release notes 2021-01-21 17:31:48 timlegge: did you switch the default action? 2021-01-21 17:31:53 timlegge: yes, 3.13 release notes should be complete... for 3.13. this is for 3.14 2021-01-21 17:32:10 yes 2021-01-21 17:32:14 well 2021-01-21 17:32:22 can't hold faccessat2 back forever 2021-01-21 17:32:27 dalias: afaik you can nest seccomp if the filter allows running seccomp, but cannot remove seccomp 2021-01-21 17:32:29 Yes for my purposes it worked fine 2021-01-21 17:32:39 Hello71: Shouldn't we warn that changing the default seccomp action to SCMP_ACCT_TRACE effectively disables it? 2021-01-21 17:33:05 Could be a little delayed on replies my main laptop is having issues 2021-01-21 17:34:14 ikke: your message on #12311 is little confused, it says >4.4 2021-01-21 17:34:43 Hello71: how so? 2021-01-21 17:34:51 also i'm confused why you would need to apk add -u busybox, shouldn't it be in the new alpine:edge 2021-01-21 17:35:03 Hello71: not until ncopa makes a new snapshot 2021-01-21 17:35:04 ah, you mean >, not >= 2021-01-21 17:35:07 yes 2021-01-21 17:35:15 i think other people will be confused about this too :p 2021-01-21 17:35:23 also technically it is not right, since e.g. 4.4.1 is not ok 2021-01-21 17:35:25 I'll change it 2021-01-21 17:35:50 also your command i think has an error, you probably missed > before /dev/null? 2021-01-21 17:36:05 Thanks, yes 2021-01-21 17:37:46 Hello71: if you don't upgrade bb in the entrypoint, it already fails before you have the opportunity to update it 2021-01-21 17:37:52 yeah 2021-01-21 17:38:02 the alpine:edge image still contains the unpatched version 2021-01-21 17:38:10 i was under the impression that ncopa updated alpine:edge, but if not then you are right 2021-01-21 17:38:21 He pushed the patched version to edge 2021-01-21 17:38:41 but once in a while he snapshots edge, and from that tag, new images are made 2021-01-21 17:39:08 so alpine:edge is not automatically updated weekly or something like that 2021-01-21 17:39:20 hello71, does docker's seccomp filter allow you to use seccomp inside? 2021-01-21 17:39:25 no idea 2021-01-21 17:40:44 Hello71: if SCMP_ACCT_TRACE effectively disables seccomp, couldn't we as well just tell the to disable seccomp (which is more explicit in what's happening) 2021-01-21 17:40:52 uh 2021-01-21 17:40:56 well i didn't realize it would do that 2021-01-21 17:41:00 is the problem 2021-01-21 17:41:06 according to dalias it does 2021-01-21 17:41:20 yes i think he's right. not 100% but seems right 2021-01-21 17:41:36 So having that in our release notes without any warning does not seem right 2021-01-21 17:41:48 assuming so, then yes i agree 2021-01-21 17:42:31 *nod* 2021-01-21 17:42:56 trace is "disable seccomp, but log things that would have been violations" and users probably do not understand that, so "disable" is more honest 2021-01-21 17:43:06 dalias: exactly 2021-01-21 17:43:39 now is more quiet here, so to repeat 'any opinion about this !17032 objections or ....?' 2021-01-21 17:43:45 ncopa: ^ 2021-01-21 17:44:14 you are maintainer 2021-01-21 17:52:19 dalias: i don't think that's right. that's SCMP_ACT_LOG 2021-01-21 17:52:41 https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#time64_requirements 2021-01-21 17:53:20 ah, yes. "If there is no tracer present, the system call is not executed and returns a failure status with errno set to ENOSYS." 2021-01-21 17:54:12 ikke: ^ also 2021-01-21 17:54:37 hmm 2021-01-21 17:56:25 Hello71: Where did you find that? 2021-01-21 17:56:32 man seccomp 2021-01-21 17:57:40 ok, so that does work as expected that 2021-01-21 17:58:58 ohh really? 2021-01-21 17:59:11 if that's true then trace does fix it 2021-01-21 17:59:16 does "tracer" mean ptrace? 2021-01-21 18:01:24 "A tracer will be notified if it requests PTRACE_O_TRACESECCOMP using ptrace(PTRACE_SETOPTIONS)." 2021-01-21 18:02:28 i think i was previously confused about if it was possible to misbehave if dockerd was being debugged or something, but i don't think so 2021-01-21 18:03:22 i think it implies that if a tracer does not request PTRACE_O_TRACESECCOMP, then the system call is not executed and returns a failure status with errno set to ENOSYS. 2021-01-21 18:04:29 sounds like a reliable fix 2021-01-21 18:04:50 That's what I used for our CI hosts (that do not run alpine 3.13 yet) 2021-01-21 18:04:54 effectively it's just "change EPERM to ENOSYS" 2021-01-21 18:07:21 yes. i think the only problem with this fix is that it changes some places that really should be EPERM to ENOSYS too 2021-01-21 18:07:48 Hello71: right, was thinking about that 2021-01-21 18:07:51 which is part of the reason why i recommended updating libseccomp/docker first, and this as a workaround 2021-01-21 18:08:16 hello71, i don't find any of the arguments that that's problematic compelling 2021-01-21 18:09:05 replacing an error that indicates need for fallback with one that indicates a fatal problem (what runc is doing) is a breaking change 2021-01-21 18:09:30 well it's fine for syscalls that have a fallback 2021-01-21 18:09:46 replacing an error that indicates a fatal problem with one that indicates a need for fallback at worst obscures the cause of breakage or causes spurious fallback sequence that also fails with errors 2021-01-21 18:10:04 but it doesn't break anything 2021-01-21 18:10:26 i think someone said somewhere (yes, very specific i know) that there is actually some broken software 2021-01-21 18:10:38 if (errno == EPERM) etc 2021-01-21 18:10:51 but what doess it do on the else condition? 2021-01-21 18:11:31 dunno 2021-01-21 18:11:57 i can't imagine how "executing the else condition rather than the EPERM condition" is going to be catastrophic 2021-01-21 18:12:12 it's an operation that's expected to fail just failing in a different way 2021-01-21 18:12:20 rather than an operation that's expected to succeed failing 2021-01-21 18:13:58 fail, succesfully 2021-01-21 18:16:56 idk, "else put file somewhere else instead"? 2021-01-21 18:17:39 i don't think that's correct, but assume that some other program may be broken in a way that happens to work here 2021-01-21 18:18:17 considering that most of the idea of docker is "put this crap in a box and make sure it doesn't get everywhere" that seems plausible 2021-01-21 19:51:15 unexpected/undocumented failure due to bdb deprecation: my cyrus-sasl database was just dropped on the floor and had to be remade from scratch 2021-01-21 19:51:31 and naturally the saslauthdb service starts up without complaints and doesn't fail until someone tries to send an email with it 2021-01-21 19:55:28 i'm inclined to say that it should be possible to convert it 2021-01-21 19:55:34 but i suspect cyrus doesn't support it 2021-01-21 19:56:00 I didn't have time to seek out an elegant situation, it caused an outage in a mission critical service 2021-01-21 19:56:07 perhaps if I had been forewarned by the release notes ;) 2021-01-21 19:56:42 i think this is maxice8's fault 2021-01-21 19:57:00 not pointing fingers, but the changelog should be updated and a lesson learned for next time 2021-01-21 19:57:13 except that when maxice8 made the commit the release notes didn't exist yet 2021-01-21 19:57:54 i think what maxice8 probably thought was "i should write this down. is there a place to write this down? not yet?" then forgot about it 2021-01-21 19:59:43 ddevault: added it now, thanks 2021-01-21 19:59:59 thanks Hello71 2021-01-21 20:00:38 ddevault: someone has to be that guy, so I will. Why do you have mission-critical services relying on bdb? :P 2021-01-21 20:01:01 my guess would be that ddevault didn't know that cyrus used bdb on alpine 2021-01-21 20:01:05 ^ 2021-01-21 20:01:10 makes sense 2021-01-21 20:01:14 and for storing <20 username/password combos, who cares? 2021-01-21 20:01:31 I was able to deal with the migration for postfix without any issues because it was documented in the release notes 2021-01-21 20:01:43 <20 pairs? explicit text backend 2021-01-21 20:01:45 i think other distros switched to gdbm a while ago 2021-01-21 20:02:05 skarnet: does cyrus support that 2021-01-21 20:02:20 it really doesn't matter 2021-01-21 20:02:25 there was no need to exercise discretion here 2021-01-21 20:02:35 I had no way of predicting that the defaults would be a source of issues in the future 2021-01-21 20:02:42 Hello71: I don't know, but if it doesn't, it's trash. ;) 2021-01-21 20:03:14 ddevault: not paranoid enough yet 2021-01-21 20:03:21 welcome to mail software 2021-01-21 20:03:22 it sucks here 2021-01-21 20:03:32 yup 2021-01-21 20:03:45 if you want to avoid trash then you're going to spend the next 20 years rewriting the stack 2021-01-21 20:04:48 well *transport* is unavoidable trash, but *storage* is doable 2021-01-21 20:05:07 including credentials storage 2021-01-21 20:05:08 good luck 2021-01-21 20:05:11 give me a call when you're done 2021-01-21 20:05:21 I'm not saying I'm doing it 2021-01-21 20:05:30 I'm saying it's possible to do it without being trash 2021-01-21 20:05:39 dovecot has a passwdfile backend for instance 2021-01-21 20:08:08 yeah but is it really an improvement over cyrus 2021-01-21 20:08:37 skarnet supposes that if you stack shit high enough it'll solve any problem 2021-01-21 20:08:47 huh? 2021-01-21 20:08:54 dovecot is also a buggy pile of shit 2021-01-21 20:08:58 cyrus is a buggy pile of shit 2021-01-21 20:09:02 postfix is a buggy pile of shit 2021-01-21 20:09:10 under every overturned stone is more shit 2021-01-21 20:09:37 what part of "it's possible to do credentials storage without being shit" is unclear 2021-01-21 20:10:00 okay 2021-01-21 20:10:01 ACTION crosses one problem off the list 2021-01-21 20:10:06 the list is still very long 2021-01-21 20:10:11 oh definitely 2021-01-21 20:10:41 and transport being unavoidably shit is the reason why I'm never touching MTA stuff 2021-01-21 20:11:13 deprecating and removing BDB was a good first step 2021-01-21 20:11:22 sorry that it caused downtime though ddevault 2021-01-21 20:11:29 shit happens 2021-01-21 20:12:08 we were in a shit situation though, our BDB was vulnerable and Oracle made it difficult to backport a secfix 2021-01-21 20:12:18 and, well, we shouldn't negotiate with terrorists, right? 2021-01-21 20:13:03 I'm not miffed about the bdb deprecation, it was annoying but the right call 2021-01-21 20:13:16 the only issue is that the conseqeunces of it were not fully explored and documented 2021-01-21 20:13:31 ddevault: what about the OpenBSD one? OpenSMTPD 2021-01-21 20:13:49 we should do a sprint with 3.14 to fully flesh out the release notes i think 2021-01-21 20:13:50 OpenBSD is also an exercise in shit-stacking 2021-01-21 20:15:15 haha 2021-01-21 20:15:16 plan9 upas? 2021-01-21 20:15:21 please no 2021-01-21 20:15:43 https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/ looks sane-ish 2021-01-21 20:15:49 upas may be the only thing in plan 9 which is rotten 2021-01-21 20:16:10 hehe 2021-01-21 20:16:33 postfix is at least mostly reasonable to admin 2021-01-21 20:16:48 postfix just werks once you get it werking, and life is too short to configure two mail servers 2021-01-21 20:21:16 i just use postgres with postfix and dovecot 2021-01-21 20:21:32 even though it's just me, but that way if i want to add anyone else, it is just an sql query 2021-01-21 20:25:51 global warming thanks you :P 2021-01-21 20:32:56 i think for future releases we should have a place for draft notes up early so that people don't think "i should write this down... do we have a place? no? maybe later then" and then forget about it. it doesn't have to be good but the irc is not a reliable storage medium 2021-01-21 20:37:20 We have that in the wiki 2021-01-21 20:39:58 hm... my mistake, it was created July 2020 2021-01-21 20:45:43 do we have tool in alpine which can remove PMBR (Protective MBR) on disks 2021-01-21 20:46:02 'dd', fdisk doesn't work 2021-01-21 20:46:26 gptfdisk can but is cumbersome 2021-01-21 20:46:30 Hello71: the deprection of bdb was the first thing I've added to that wiki page 2021-01-21 20:46:36 yes i saw that 2021-01-21 20:46:53 mps: wipefs (util-linux) 2021-01-21 20:47:18 if you need to do it frequently probably use dd 2021-01-21 20:48:13 Hello71: doubt that wipefs will work if dd doesn't but will try 2021-01-21 20:48:35 well i mean if dding the whole disk doesn't work then your problem isn't the mbr 2021-01-21 20:48:45 maybe you actually want partprobe 2021-01-21 20:49:10 I did my best to start early with the release notes to capture as much as possible 2021-01-21 20:49:12 for 3.13 2021-01-21 20:49:47 yes i do recall this 2021-01-21 20:49:54 so... we are back to blaming maxice8? :p 2021-01-21 20:50:27 need to create a habbit of documenting these things 2021-01-21 20:50:52 Hello71: partprobe after changing or dd-ing also doesn't help 2021-01-21 20:51:39 https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0 :) 2021-01-21 20:52:01 Should be early enough now :P 2021-01-21 21:05:28 mps: what exactly is your problem 2021-01-21 21:05:55 trying to remove PMBR from disk, that is. 2021-01-21 21:07:43 if you remove first 460 bytes from disk then there is no mbr at all, am I missing something? :\ 2021-01-21 21:08:13 I thought so but osX doesn't 2021-01-21 21:08:37 lets see what parted can do 2021-01-21 21:08:44 there is also mbr security in old bios'es maybe that is the problem 2021-01-21 21:11:47 MY-R: no in that case, macbook pro (old one) 2021-01-21 21:11:58 but parted solved problem :) 2021-01-21 21:12:13 MY-R: that's pretty ancient. not sure such machines can run unmodified syslinux though 2021-01-21 21:12:18 ahh no 460 but better just zero first 512 2021-01-21 21:14:03 Hello71: ye is very ancient :) 2021-01-21 21:20:27 i don't think i ever saw such machines, but heard of them 2021-01-21 21:24:40 really? 2021-01-21 21:25:38 I saw it many times but those were old machines in age of bios and also in old laptops 2021-01-21 21:34:51 yeah but problem is i'm only in early 20s years old. i think those machines with mbr lock were like mid 90s-early 2000s 2021-01-21 21:35:38 I think last one I saw was some Dell from 2002 2021-01-21 21:36:22 yeah, so pretty obsolete :p 2021-01-21 21:37:04 bios-only i'm quite familiar with, but those later machines didn't have "boot record security" anymore 2021-01-21 21:40:54 eh, Im just old :\ whatever, EOT :) 2021-01-21 23:08:41 maxice8: are you around? 2021-01-22 01:48:45 mps: pong 2021-01-22 07:24:09 morning 2021-01-22 07:24:56 ikke: good to start planning for the 3.14 release notes 2021-01-22 07:26:30 i was thinking that we could maybe have a form for MR where one of the entries is "Should this be mentioned in the release notes? [no]" and if its set, the title of the MR will be used for release notes. 2021-01-22 07:29:17 A tag would probably be easier to search for 2021-01-22 07:43:05 Morning all. I'm in the process of packaging emborg, a Python front end to borgbackup. 2021-01-22 07:43:45 I've read that it's preferred that a PR is made.for each new package. However, emborg depends on some other Python packages that aren't in alpine yet. 2021-01-22 07:44:22 Is it ok to make one PR for all of these new packages, as long as there's a separate commit for each package? 2021-01-22 07:46:13 Yes, that is the preferred method 2021-01-22 07:46:32 Packages added as a dependency of a desired package should be separate commits under the same Mr 2021-01-22 08:04:34 That's great, thanks maxice8 2021-01-22 09:04:24 maxice8: sorry, I went to sleep 2021-01-22 09:06:06 wanted to ask you do we need to add CVE in secfixes again for !17252 2021-01-22 09:06:29 no 2021-01-22 09:06:51 I think no, because they already there, though on 'patch' version 2021-01-22 09:07:07 It was fixed in 2.0.4-r1 (or whatever release), changing the fix from a trivial backport from upstream to a new version released from upstream doesn't change the fact it was fixed in 2.0.4-r1 2021-01-22 09:07:50 yes 2021-01-22 09:08:39 another question, I see this in source 'CVE-2021-3181.patch::https://gitlab.com/muttmua/mutt/-/commit/c059e20ea4c7cb3ee9ffd3500ffe313ae84b2545.patch' for 2.0.4-r1 2021-01-22 09:09:41 do we have somewhere 'policy' that we can use this format for patches and maybe other things in source? 2021-01-22 09:10:08 if yes, would be nice if it is written somewhere 2021-01-22 09:10:08 No, we just warn against using pull request patches 2021-01-22 09:10:30 Because those can change as the contributor pushes changes, thus changing the checksum 2021-01-22 09:10:38 aha, ok 2021-01-22 09:10:47 AL60 something I think 2021-01-22 09:10:53 Around 55 to 60 2021-01-22 09:11:57 Anyone here familiar with packaging python modules? The package I've created has both an 'inform' and 'inform-1.23.0-py3.8.egg-info' directory under site-packages. Should both of these be installed? 2021-01-22 09:12:29 It looks like they are for other packages I already have installed. 2021-01-22 09:58:31 Yes, if you're packaging the inform module 2021-01-22 10:11:40 I am maxice8, thanks. 2021-01-22 10:11:52 Anyone prepared to 'review' some packages from a first-timer? 2021-01-22 10:20:41 We have a @team/mentors group you can tag 2021-01-22 10:23:24 Where do I do that ikke? Sorry, new to this. 2021-01-22 10:23:37 In Gitlab 2021-01-22 10:23:48 So this is when I submit the MR? 2021-01-22 10:23:52 In the comments of your MR 2021-01-22 10:23:55 Yes 2021-01-22 10:24:21 Ok. Was hoping someone might be able to look at it before it got to that stage. Hate to waste people's time if I've made a rookie mistake. 2021-01-22 10:25:32 Do not worry about that 2021-01-22 10:25:47 You could mark the MR as draft 2021-01-22 10:26:59 Ok. Will have a go. The document I've been using mentions making a PR in GitHub. Is that out of date? 2021-01-22 10:27:28 https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package: "Because you do not have push rights to the Alpine aports repository you need to create a pull request to Alpine's mirror on GitHub (read instructions here)." 2021-01-22 10:27:46 Ah, yes 2021-01-22 10:28:01 Good. I've done all the work in GitLab :) 2021-01-22 10:28:09 I'll create a merge request and see how I get on. Thanks ikke. 2021-01-22 10:29:16 adhawkins: yes both of those should be installed 2021-01-22 12:35:29 ncopa: you maintain libnl. I have a package depending on it and it fails to compile. It _seems_ because of libnl rather than the package itself, but I'm not sure what to do about it. Incoming error: 2021-01-22 12:35:32 ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/pgLdzTXILDWBpkGWdPhZiHnG/message.txt > 2021-01-22 12:39:28 seems suspiciously like problem with your linux headers 2021-01-22 12:39:49 which alpine release 2021-01-22 12:42:32 actually, hm.... 2021-01-22 12:44:22 Edge 2021-01-22 12:44:33 `netlink-kernel.h` comes from libnl btw 2021-01-22 12:45:07 yeah i got that 2021-01-22 12:53:31 what i'm confused about is how this works at all on alpine 2021-01-22 12:54:48 it doesn't define __u32 or include 2021-01-22 12:58:05 Exactly. I couldn't find anything about it anywhere 2021-01-22 12:59:30 Hi all. Trying to set my fork of aports so that it updates automatically. However, if I go into 'Mirroring repositories' and enter the URL of the 'real' aports (https://gitlab.alpinelinux.org/alpine/aports.git) it won't let me change the 'Mirror direction' to 'Pull'. Anyone assist with this? 2021-01-22 13:01:41 Oh seems our libnl is way outdated. Newest is 3.5.0 2021-01-22 13:01:55 It appears it might be because of the GitLab plan alpine is on perhaps? 2021-01-22 13:01:58 Other distros seems to have the version we ship as libnl1 still for legacy compatibility 2021-01-22 13:02:06 So I might just rename our package to do the same 2021-01-22 13:02:20 Oh wait, we have libnl3 as well 2021-01-22 13:04:09 Yeah that's the one I need. Let's just ignore libnl, it's legacy anyway 2021-01-22 13:04:36 PureTryOut[m]2: libnl3 2021-01-22 13:05:37 that is, we have versioned libs already :) 2021-01-22 13:06:18 Yeah I just found that 2021-01-22 13:06:43 The non-fuzzy search on https://pkgs.alpinelinux.org messed me up lol 2021-01-22 13:07:07 I usually search aports repo 2021-01-22 13:07:22 lot more data for grep 2021-01-22 13:07:51 ikke: Could you take a look over https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17298 and let me know if it looks like I've made any major screw ups? 2021-01-22 13:09:34 Don't be so afraid of making mistakes πŸ˜‰ 2021-01-22 13:09:45 You seem to have every commit in that MR twice? 2021-01-22 13:10:22 They don't show in the original branch PureTryOut[m]2? 2021-01-22 13:10:26 https://gitlab.alpinelinux.org/adhawkins/aports/-/commits/emborg 2021-01-22 13:10:28 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17298/diffs#cb8ed1578aed2eaf4449c7779748addac0f0728d 2021-01-22 13:10:45 Yeah they do 2021-01-22 13:10:51 There are just 3 unrelated commits inbetween 2021-01-22 13:10:55 Oh wait, yes they do. I did a rebase, is that where I screwed up? 2021-01-22 13:11:00 Seems like it 2021-01-22 13:11:19 your master branch is not up-to-date 2021-01-22 13:11:22 Damn. My git skills obviously failing me. 2021-01-22 13:11:23 I think you can just drop the old ones and it should be fine 2021-01-22 13:11:32 maxice8: I did update the master and then rebase the branch against it. 2021-01-22 13:11:43 Use https://git-rebase.io/ 2021-01-22 13:11:58 I'm currently reviewing it locally, a rebase against an up-to-date master is all that needed 2021-01-22 13:12:39 You don't have to rename the source packages btw, you can just download from https://github.com///archive//-.tar.gz 2021-01-22 13:14:06 Does that look better PureTryOut[m]2 and maxice8? 2021-01-22 13:14:19 Yup! 2021-01-22 13:14:21 (I think I've done the rebase) 2021-01-22 13:15:23 Someone has commented that some of them aren't running tests. Can some assist with what I've done wrong? 2021-01-22 13:20:16 Not every package might have tests 2021-01-22 13:20:25 Also, I would recommend running Python tests with `pytest` rather than with setup.py 2021-01-22 13:20:57 They have added some patches to get the tests running. Will give them a go. 2021-01-22 13:21:25 Add `py3-pytest` to checkdepends (create the variable if it does not exist yet) and run `pytest` in the check function 2021-01-22 13:22:41 Btw Leo on Gitlab is maxice8 here 2021-01-22 13:35:35 Thanks. Added the patches to make it check. Getting a new failure in quantiphy. Beyond my python knowledge here sadly, so appreciate any suggestions. 2021-01-22 13:36:07 https://termbin.com/wtsy 2021-01-22 13:37:53 Well for one, multiple missing modules 2021-01-22 13:39:11 `py.test-3` is such a weird binary name... 2021-01-22 13:39:13 quantiphy_eval? 2021-01-22 13:39:17 Yeah 2021-01-22 13:39:23 Not sure where it should come from though 2021-01-22 13:39:55 It seems to be a package in its own right: https://pypi.org/project/quantiphy-eval/ 2021-01-22 13:40:07 Ah. Well easy solution then, package it πŸ˜ƒ 2021-01-22 13:41:45 https://github.com/KenKundert/quantiphy/blob/master/tox.ini 2021-01-22 13:41:56 quantiphy_eval and rkm_codes 2021-01-22 13:48:36 adhawkins: is apkbuild-pypi working okay for you. I believe I made last changes to it over a year ago feel free to improve it 2021-01-22 13:49:42 timlegge: I gave up on it in the end. Just starting from scratch 2021-01-22 13:50:57 That's too bad it makes it a lot easier once it works I don't create python packages but if I get sometime I will take a look 2021-01-22 13:52:12 timlegge: unfortunately it is lagging behind apkbuild-cpan in terms of features and policy compliance 2021-01-22 13:52:17 I use apkbuild-cpan for Perl modules and it really makes keeping them up-to-date a lot easier 2021-01-22 13:52:37 apkbuild-cpan is a godsent, don't even manually touch perl APKBUILDs 2021-01-22 13:53:44 maxice8: that is my goal with it I still have a couple of nagging things to look at but for the most part it works great 2021-01-22 13:54:16 yes, only problem I found is duplicate dependencies 2021-01-22 13:55:30 Wait, what does apkbuild-cpan do and what should apkbuild-pypi do? 2021-01-22 13:55:54 apkbuild-cpan queries metacpan and fills in license, dependencies and other stuff 2021-01-22 13:56:02 basically an automatic perl APKBUILD creator by interacting with metacpan API 2021-01-22 13:56:16 apkbuild-pypi is s/perl/python/ and s/metacpan/pypi/ 2021-01-22 13:56:22 Oh interesting 2021-01-22 13:56:28 both are writte in Perl though and apkbuild-cpan has more work on it 2021-01-22 13:56:31 I just copy comparable APKBUILDs and modify what's needed πŸ€·β€β™‚οΈ 2021-01-22 13:56:36 Ew Perl 2021-01-22 13:56:39 πŸ˜‚ 2021-01-22 13:57:00 timlegge: apkbuild-pypi need perl-ipc-system-simple in deps 2021-01-22 13:57:14 mps: make an MR :D 2021-01-22 13:57:48 maxice8: I don't like to touch anything py related :) 2021-01-22 13:58:14 mps: it is the abuild APKBUILD, apkbuild-pypi is a subpkg 2021-01-22 13:58:26 ah 2021-01-22 13:58:39 LOL I will spend days working on a script to remove 2 minutes of work if I have to repeat that two minutes on a regular basis 2021-01-22 13:58:40 didn't know, I thought it is separate apk 2021-01-22 13:58:59 It's the application of Applied laziness 2021-01-22 13:59:39 yes, script are safer than manual work, less chances to make errors 2021-01-22 14:03:25 I forgot apkbuild-pypi was written in perl. I will put it on my list to update 2021-01-22 14:05:51 maxice8: I updated !17255 2021-01-22 14:08:15 maxice8: PureTryOut[m]2: I think I've addresssed all the comments regarding testing and licences now. Would appreciate confirmation if you get chance. 2021-01-22 14:33:31 Think I've got those last couple of dependencies too. Lesson learned, check setup.py a bit more closely! 2021-01-22 14:38:33 Well mainly just run the build locally 2021-01-22 14:38:52 Also, use either `docker-abuild` or `abuild-rootbld` to make sure locally installed stuff on your machine isn't in the way 2021-01-22 14:42:43 Ooh, docker-abuild sounds interesting. Not too concerned about locally installed stuff as it's a clean VM running alpine that I'm using. 2021-01-22 14:42:52 Installed next to nothing other than the abuild stuff. 2021-01-22 14:56:35 In that case docker-abuild will help you not need a VM anymore 2021-01-22 15:18:26 Well, all my network is VMs, so it's no big deal. Will have a look at docker-abuild though. 2021-01-22 15:18:38 Getting pipeline build failures, could this be due to the ordering of my commits? 2021-01-22 15:18:44 https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/301722 2021-01-22 15:22:17 It seems to be failing to find quantiphy when building quantiphy-eval 2021-01-22 15:23:07 Check if there are no circular dependecies 2021-01-22 15:26:49 py3-quantiphy needs py3-quantiphy-eval and py3-quantiphy needs py3-quantiphy-eval 2021-01-22 15:27:21 disable tests on py3-quantiphy since it only needs py3-quantiphy eval for tests while py3-quantiphy-eval needs py3-quantiphy to actually run (according to setup.py) 2021-01-22 15:34:34 Ok. I seem to recall seeing I need a specific comment to indicate why tests are being disabled. 2021-01-22 15:35:34 generally it is better to fix tests 2021-01-22 15:35:39 or exclude specific tests if possible 2021-01-22 15:40:37 Hello71: I'm not familiar with Python testing frameworks. How would I exclude the tests? 2021-01-22 15:41:15 dunno 2021-01-22 15:41:27 Ok, I'll do some research. Thanks. 2021-01-22 15:41:40 if it's a command as opposed to a make target then usually ./run_tests --help is useful 2021-01-22 15:44:14 How does this look? https://paste.debian.net/1182254/ 2021-01-22 15:44:32 It excludes the test, just double checking that's an appropriate comment to indicate why it's being skipped? 2021-01-22 16:07:12 pytest can exclude tests 2021-01-22 16:07:21 And yes that looks fine 2021-01-22 16:09:10 --deselect 2021-01-22 16:09:17 call --deselect how many times you need 2021-01-22 16:12:11 The pipeline build is now passing. Is that paste Ok do you think maxice8, or should I be excluding specific tests? 2021-01-22 16:13:29 Specific tests would be nicer, but this is fine as well 2021-01-22 16:13:45 (at least, when those specific tests is not just the whole file) 2021-01-22 16:17:19 This is the test file PureTryOut[m]2: https://termbin.com/lr5h 2021-01-22 16:17:47 It's test_manual that isn't working. I've tried '--deselect test_manual' and '--deselect manual' but it still runs it. 2021-01-22 16:18:51 Use `-k 'not test_manual'` instead 2021-01-22 16:19:29 But that won't help in this case, as it'll break on the import on line 3 already 2021-01-22 16:19:35 So just exclude the whole file 2021-01-22 16:41:11 Oh ok, thanks. 2021-01-22 16:41:36 Actually, no. These tests are for the quantiphy package itself. 2021-01-22 16:42:56 PureTryOut[m]2: ERROR: Wrong expression passed to '-k': not test manual: at column 10: expected end of input; got identifier 2021-01-22 16:43:01 PYTHONPATH="$PWD/build/lib" py.test-3 -k 'not test manual' # --ignore=tests/test_doctests.py 2021-01-22 16:43:20 You forgot the underscore 2021-01-22 16:43:26 "not test_manual" 2021-01-22 16:43:43 Basically copy the function name that you want to skip 2021-01-22 16:44:43 Doh, thanks. Tests now completing. Appreciate the help PureTryOut[m]2. 2021-01-22 16:46:25 No problem! 2021-01-22 17:00:13 So, couple of questions about the merge request (feel free to point me to an FAQ or similar). 1. How long is it likely to be before this is merged? 2. How long is it likely to be before this becomes available in a 'release' of alpine? 3. What's the process for getting the packages moved out of 'testing'? 2021-01-22 17:01:45 adhawkins: if packages are ok, they're usually merged withing 1 day - 1 week 2021-01-22 17:01:56 packages in testing are not part of a release 2021-01-22 17:02:09 so they need to moved to community (or main) first 2021-01-22 17:02:23 An alpine release is created every half year 2021-01-22 17:02:52 so packages in community and main now will be part of the next release 2021-01-22 17:03:01 ikke: Ok. Is this move to community / main automatic? If not, what needs to be done to facilitate this? 2021-01-22 17:03:09 No 2021-01-22 17:03:22 After the package is built on the builders 2021-01-22 17:03:28 you can verify it works properly 2021-01-22 17:03:38 after that, you can create a merge request to move it 2021-01-22 17:04:05 So this would just be moving all the directories I've created into community rather than testing? 2021-01-22 17:04:25 yes 2021-01-22 17:04:39 Ok great. Is there any sort of notification once this build process is complete? 2021-01-22 17:06:02 You can watch https://build.alpinelinux.org 2021-01-22 17:06:09 or watch #alpine-commits 2021-01-22 17:07:15 Excellent, thanks for that info ikke. 2021-01-22 17:07:48 You can also look at https://pkg.alpinelinux.org 2021-01-22 17:07:54 if it appears there 2021-01-22 17:08:16 I get an error from that link. 2021-01-22 17:09:31 sorry, forgot an 's' 2021-01-22 17:09:33 https://pkgs.alpinelinux.org/ 2021-01-22 17:09:40 That's better :) 2021-01-22 17:10:55 Ok, final (possibly!) question for now. Is there any documentation on getting docker-abuild up and running? I've found the GIT repo but there isn't a whole lot of information about getting started with it. 2021-01-22 18:14:58 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16099#note_137898 2021-01-22 18:15:21 the wording of this comment is fairly aggravating if the submitter is not actually responsible for the delay 2021-01-22 18:16:33 i understand the intention of not wanting to have old mrs sitting around forever but this message seems to imply that it's my fault somehow 2021-01-22 18:17:40 just noticed "env: can't execute 'bash': No such file or directory" in the build pipeline logs for multiple archs of a MR I submitted. It doesn't appear to be affecting the builds however 2021-01-22 18:20:44 probably should add bash to (make)?depends 2021-01-22 18:21:14 The CI images do not have bash installed 2021-01-22 18:26:06 afontain_: that's what I assumed, but then wouldn't expect it to build if bash was actually required. Plus I didn't see any (obvious) use of bash in the package's makefile 2021-01-22 18:26:57 `abuild rootbld` is a good way to catch those 2021-01-22 18:27:15 or in this specific case, grep '#!/usr/bin/env bash' :P 2021-01-22 18:28:22 afountain_: had already searched package source for bash, only refs are in Markdown docs. So unless one of the pulled in (golang) files needs bash.... 2021-01-22 18:31:02 weird 2021-01-22 18:31:18 you can still try to abuild rootbld 2021-01-22 18:32:31 I'll have a look at that, locally I'm building inside my own Docker setup so will have to tweak that accordingly 2021-01-22 18:33:00 for this package also had to disable armv7 and x86 archs - looks like there's code that's not 32bit clean :-( 2021-01-22 18:38:10 you can also try to build it in the alpinelinux/alpine-gitlab-ci image 2021-01-22 18:41:23 from Docker hub? Is there a source Dockerfile for that somewhere? 2021-01-22 18:42:42 ideally I should finally get around to setting up cross-compile environment locally 2021-01-22 18:57:31 Someone mentioned docker-abuild earlier. Sounds like a good approach to me, but can't find much information on how to set it up. Anyone point me to something useful? 2021-01-22 18:59:05 adhawkins: https://gitlab.alpinelinux.org/alpine/docker-abuild 2021-01-22 18:59:50 I haven't used it myself but I'm using something similar (using qemu-user inside docker so I can do multi-arch package builds) 2021-01-22 19:07:34 Yeah, I found that minimal, but it doesn't give much information on how to get started with it. 2021-01-22 19:09:45 adhawkins: think this is what my own setup was based on originally: https://github.com/andyshinn/docker-alpine-abuild 2021-01-22 19:10:14 the docs there give an example 2021-01-22 19:12:34 |Thanks minimal, will take a look. 2021-01-22 19:15:23 maxice8: I'm not sure I fully understand your latest comment on my PR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17298#note_137902 2021-01-22 19:15:23 minimal: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci 2021-01-22 19:15:38 there is a line commented `# shlib` 2021-01-22 19:15:41 I don't think that is supposed to be there 2021-01-22 19:17:08 Ah, good spot maxice8. That was my list of dependencies that I also needed to package. I obviously forgot to remove it! 2021-01-22 19:18:45 ikke: thanks, will have a look. I spotted that my local docker abuild setup does have bash installed so that would (partly) explain why I don't see that warning locally. However I'm still confused as to what in the particular package I was building uses bash, but that's a different issue 2021-01-22 19:19:15 Now fixed maxice8, thanks for that! 2021-01-22 19:19:39 welcome 2021-01-22 19:26:04 Marian[m]: ping 2021-01-22 19:26:59 Well, I can install emborg from my packages directory with a combination of community and testing, so hopefully that means the MR is good to go! 2021-01-22 19:34:21 Ooh, just seen a load of entries in alpine-commits with my name on. Does that mean it's merged? 2021-01-22 19:34:59 adhawkins: yes 2021-01-22 19:35:20 So now I just need to wait for it to be built presumably? 2021-01-22 19:36:22 fcolista: bareos is failing because chromium-chromedriver is missing 2021-01-22 19:36:55 for most arches 2021-01-22 20:18:32 Woot: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/emborg 2021-01-22 20:18:44 adhawkins: nice 2021-01-22 20:18:48 Thanks all for your assistance in getting these in. Will test and then look to have them move to community. 2021-01-22 20:18:49 congrats with your first package! 2021-01-22 20:19:05 first packages 2021-01-22 20:19:12 right 2021-01-22 20:19:14 When I do that, do I need to bump up the pkgrel? 2021-01-22 20:19:24 no 2021-01-22 20:19:48 Can I do the same thing as before, a single MR with one commit for each package to move it? 2021-01-22 20:19:58 yes 2021-01-22 20:20:03 see an MR as a transaction 2021-01-22 20:20:13 we want to move these things in a single transaction 2021-01-22 20:20:23 Excellent. That's what I thought, it wouldn't make sense to move each package individually, as they depend on each other to a certain extent. 2021-01-22 21:16:34 It looks like edge-ppc64le builder hanging whole the week 2021-01-22 21:16:49 let me take a look\ 2021-01-22 21:16:55 I've been a bit busy 2021-01-22 21:20:21 andypost[m]: not sure what I did (well, I did strace the processes), but it seems to continue now 2021-01-22 21:20:36 andypost[m]: was it stuck on botan all week? 2021-01-22 21:20:58 yep, botan and the same 45% 2021-01-22 21:21:37 percantage does not change per package 2021-01-22 21:21:50 it's jyst based on the amount of packages 2021-01-22 21:21:55 but it seels to have finished now 2021-01-22 21:22:16 now thing-provisioning-tools that does not know about ppc64le 2021-01-22 21:22:27 "Invalid configuration `powerpc64le-unknown-linux-musl': machine `powerpc64le-unknown-linux' not recognized" 2021-01-22 21:22:49 and update_config_{guess,sub} is already called 2021-01-22 21:23:21 asked bot to retry, and now it builds 2021-01-22 21:23:37 ikke: thank you 2021-01-22 21:24:49 Hello71: re !16099 2021-01-22 21:25:09 ACTION wonders why it is not merged for 3.13 2021-01-22 21:25:20 anyone know answer? 2021-01-22 21:25:30 ACTION is puzzled how stracing processing unstucks them 2021-01-22 21:25:36 I have seen that multiple times now 2021-01-22 21:26:27 yes, puzzles everywhere around us, God of AI shows to us but we are blind :) 2021-01-22 21:26:30 observer effect 2021-01-22 21:26:40 also this 2021-01-22 21:27:07 famous cat 2021-01-22 21:28:21 ACTION changes nick to SchrΓΆdinger :) 2021-01-22 21:35:11 ikke: it sends a signal 2021-01-22 21:35:26 all system calls are terminated with EINTR 2021-01-22 21:35:58 aha, ok 2021-01-22 21:36:06 Was not aware 2021-01-22 21:36:42 well, all blocking system calls. most system calls are atomic and cannot be interrupted. like, you can't kill -9 a process waiting on hard nfs, you can't strace it either 2021-01-22 21:36:53 (i think...) 2021-01-22 21:37:11 Right, uninteruptable sleep 2021-01-22 21:37:31 but if they're stuck in the kernel you can just ask the kernel where they are with cat /proc/x/{stack,wchan} or echo w > /proc/sysrq-trigger 2021-01-22 21:38:49 specifically i think strace needs to send SIGSTOP to all threads. so for poking a process kill -STOP; kill -CONT should be equivalent 2021-01-22 21:39:20 except i think it might have different effects on controlling terminal? not sure 2021-01-22 21:55:59 not ok 362 - udp_multicast_join6 2021-01-22 21:56:07 libuv fails on ppc64le 2021-01-22 23:56:03 Whoops. Looks like when I changed the licence I didn't pick the correct wording. I've used 'GPL-3.0-or-newer' when it should in fact be 'GPL-3.0-or-later'. Should I do this as a separate change, or roll it into the rename from testing to community do you think? 2021-01-23 00:04:47 usually in git it's better to make change and move separate commits 2021-01-23 00:08:29 Yeah, I was thinking the same. I'll do a correction to the licence issue. Is there any guidance as to what the commit message should look like for a package modification? 2021-01-23 00:09:12 git log 2021-01-23 00:09:19 i think is also in CODINGSTYLE.md or somesuch 2021-01-23 00:10:44 COMMITSTYLE.md iirc 2021-01-23 00:11:52 'fix license to SPDX' is enough 2021-01-23 00:12:09 or something like this 2021-01-23 01:34:48 made some updates to apkbuild-pypi still need some work and not fully tested https://gitlab.alpinelinux.org/timlegge/abuild/-/blob/apkbuild-pypi/apkbuild-pypi.in 2021-01-23 01:53:51 what triggers an update of APKINDEX.tar.gz? 2021-01-23 01:53:57 trying to find the optimal time to update my mirror 2021-01-23 02:13:48 did someone mention that there is a docker image setup for abuild/aport dev instead of using a VM 2021-01-23 02:30:42 timlegge: https://gitlab.alpinelinux.org/alpine/docker-abuild 2021-01-23 02:31:48 thanks TBK[m] 2021-01-23 05:07:02 Aeiadne: can we postpone the python rebuild to end of Sunday m 2021-01-23 05:07:22 Bureocratic medical situation got me 2021-01-23 06:32:19 works for me 2021-01-23 07:08:25 https://github.com/dense-analysis/ale/pull/3424#event-4241203185 2021-01-23 07:08:40 Yaaay 2021-01-23 07:15:41 ALE upstream now has APKBUILD support 2021-01-23 08:15:07 it is not that that the vim is good but alternatives are worse 2021-01-23 10:12:56 ikke, thanks for bareos, didn't notice that 2021-01-23 10:16:58 fcolista: np 2021-01-23 11:27:31 Need to make some changes to my new packages because I messed up the licence string. There were some other comments too that I might address. Is it ok to do more than one thing to the same package in an MR, or should they be separate? 2021-01-23 11:27:51 If they can be in the same one, how should the commit message look? 2021-01-23 11:29:58 adhawkins: depends how changes are big, reviewers usually don't like big changes 2021-01-23 11:30:45 but that is left to 'common sense' of author of changes/MRs 2021-01-23 11:37:09 They wouldn't be big. Little things like using pytest instead of py.3test (something like that!) and changing the source URL format. 2021-01-23 11:37:25 So can I do multiple commits in the same MR? 2021-01-23 11:40:16 Yes 2021-01-23 11:42:14 Of course you can 2021-01-23 11:46:08 Thanks. I realised it was technically possible, just wanted to make sure it was 'the done thing' 2021-01-23 12:59:18 Schroedingers cat again but I built apple M1 preloader on alpine using only alpine tools. have to check which tools are minimally needed 2021-01-23 13:59:04 rebooting the x86_64 CI host 2021-01-23 13:59:12 CI is quiet atm 2021-01-23 14:00:55 not for long, I'm preparing MR which will take a full day to finish :) 2021-01-23 14:01:13 Too late :P 2021-01-23 14:01:23 not full but probably half of day 2021-01-23 14:01:38 (or rather, I'm early enough) 2021-01-23 14:01:52 no, np, everything is ok 2021-01-23 14:02:51 I didn't finished yet, and intend to create late at this night 2021-01-23 14:03:06 to not block other works 2021-01-23 14:05:52 Nice, x86_64 host is alpine 3.13 now, with the 3.12 kernel 2021-01-23 14:06:36 CI or builder 2021-01-23 14:06:41 CI 2021-01-23 14:06:48 the one I had issues with last week 2021-01-23 14:07:18 aha, kernel still make problem with lvm 2021-01-23 14:07:29 I think so 2021-01-23 14:07:45 This at least proves it's somehow related to the kernel 2021-01-23 14:07:54 3.12 with 3.13 kernel -> problem 2021-01-23 14:08:02 3.13 with 3.12 kernel -> no problem 2021-01-23 14:08:28 I haven't tried 5.10.9 yet though 2021-01-23 14:09:21 I saw some fixes for nvme in 5.10.9, though not sure will it fix problem you encountered 2021-01-23 14:10:20 I could try 5.10.9 2021-01-23 14:11:31 I missed to see, did ncopa upgraded -lts to 5.10.9 2021-01-23 14:11:45 only on edge 2021-01-23 14:11:49 but yes 2021-01-23 14:12:43 uhm, this reminds me that linux-tools 'must be upgraded' :) for 3.13 2021-01-23 14:12:44 3.13 is on 5.10.7 2021-01-23 14:13:18 hope will not forget tomorrow 2021-01-23 14:21:06 5.10.9 does not work either 2021-01-23 14:24:28 in about month we will have 5.11.x :) 2021-01-23 14:24:40 Ok, I've made some changes on one of the packages. Appreciate it if someone can give it a quick look over? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17352 2021-01-23 14:25:03 !17352 2021-01-23 14:25:12 Whoops, Forgot to update the package version. 2021-01-23 14:26:15 Ok, all done hopefully. 2021-01-23 14:26:55 looking now, all this could be in one commit 2021-01-23 14:26:57 adhawkins: our commit subjects (first line) are lower case 2021-01-23 14:27:38 and should be 'upgrade to $version' 2021-01-23 14:28:13 adhawkins: can I advice you to read COMMITSTYLE.ml 2021-01-23 14:28:23 The source package version hasn't changed. This is just changes to the packaging. 2021-01-23 14:29:06 then it is pkgrel 2021-01-23 14:29:40 usually 'bump pkgrel to $reason' 2021-01-23 14:30:40 and as ikke say, lower cases 2021-01-23 14:30:44 There are a number of small changes in that change set. I've changed all the commit messages. 2021-01-23 14:32:12 (huh, time to consider BSD, but I know conclusion already) 2021-01-23 14:32:42 alpine is not good but other alternatives are worse 2021-01-23 14:33:32 as everything in life, always choose less worse 2021-01-23 14:34:23 mps: where is that a reaction to? 2021-01-23 14:34:54 ikke: to what? I don't follow 2021-01-23 14:35:25 "(time to consider BSD .." 2021-01-23 14:35:45 mps: The reason I split it across a number of commits was to avoid a commit message that said "Do this, and this, and this, and this" 2021-01-23 14:35:59 that's good 2021-01-23 14:36:07 If it's preferable as a single commit I can squash them? Discussion earlier suggested that individual commits were acceptable 2021-01-23 14:36:17 But we do not require every change to be summarized in the commit message 2021-01-23 14:36:28 Yeah, it's somewhat a trade-off 2021-01-23 14:36:45 ikke: Oh, I thought that was the point of the commit message? 2021-01-23 14:37:03 adhawkins: the commit message tells you mostly why a certain change is done 2021-01-23 14:37:10 adhawkins: what is changed can be seen in the diff 2021-01-23 14:37:46 So would something like "correct licence text and consolidate packaging changes" be the way to go? 2021-01-23 14:37:52 Or just "correct licence text"?| 2021-01-23 14:38:18 correct license field 2021-01-23 14:38:28 And not mention the other changes? 2021-01-23 14:39:06 ikke: BSD is (nowadays called) meme when I'm irritated with linux distros 2021-01-23 14:39:36 entioning incrementing pkgrel, unless there is an explicit reason (say, to make sure it's rebuilt against a new lib), is not necessary 2021-01-23 14:39:40 mentioning 2021-01-23 14:39:53 Ok. I'll squash them all up into a single commit then 2021-01-23 14:40:17 I think this could be a separate commit still: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17352/diffs?commit_id=ba40b07aea827c9204841060b1472a8718179169 2021-01-23 14:41:06 Why that one in particular ikke? 2021-01-23 14:41:44 Because it might not be immediately obvious to others why it's done 2021-01-23 14:41:50 Ok. 2021-01-23 14:42:39 Ok, updated. How does that look? 2021-01-23 14:43:09 fine for me 2021-01-23 14:43:23 x86_64 CI host is back 2021-01-23 14:44:12 That's great ikke. Will wait and see if it gets merged and then repeat the process with the other packages I created yesterday 2021-01-23 14:44:57 it seems to fail on ppc64le / s390x 2021-01-23 14:45:15 py3-inform being unavailable 2021-01-23 14:46:10 Could that be because it hasn't been build from when I added it yesterday? 2021-01-23 14:46:50 yes, those builders are stuck on other packages 2021-01-23 14:47:07 Ah ok. So will it retry the build if I don't make any changes? 2021-01-23 14:47:25 yes, it will be built eventually 2021-01-23 14:48:00 Ok. 2021-01-23 14:48:54 ppc64le is the same it would appear. 2021-01-23 14:49:15 Is there any point me proceeding with similar changes to the other packages? 2021-01-23 14:49:30 sure 2021-01-23 14:49:40 Ok. I'll continue then. Thanks for the help. 2021-01-23 15:01:14 Same thing for one of the other packages. If this one looks Ok I'll proceed with the others in the same way: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17353 2021-01-23 15:05:10 when I started to 'contribute' I read some different pkgs and read git log to get idea how should I work, I called that 'learning from masters' 2021-01-23 15:05:36 That's a good idea mps. I'll have a dig around. 2021-01-23 15:05:55 That latest one is failing the same two builds for a similar reason (one of the new packages I did yesterday not found) 2021-01-23 15:09:16 before pushing anything that is not simple upgrade to aports I usually build pkg on local builders (and different arches) even install and test locally 2021-01-23 15:10:00 call me 'too conservative' but I'm ok with this 2021-01-23 15:10:06 These should be fairly simple. I am building locally on a single arch, I think the only reason for the issue is that I've done it before all the 'new' packages are fully built from yesterday. 2021-01-23 15:10:23 How would I go about building on different arches out of interest? 2021-01-23 15:10:34 adhawkins: np, we all make mistakes 2021-01-23 15:10:39 I did test locally before doing yesterday's merge request. 2021-01-23 15:12:30 believe or not, but I have pkgs in my local repo old more than 2 years and I use them daily but still didn't pushed 2021-01-23 15:13:13 Yeah, I did consider that mps. But I figured if they were useful to me they were probably useful to others. The driving force was emborg, the other packages are its dependencies that weren't already packaged. 2021-01-23 15:13:50 adhawkins: we have our CI to build it on multiple arches 2021-01-23 15:14:09 adhawkins: I didn't wanted to say anything against your effort and pkgs 2021-01-23 15:14:24 Yeah, but that only comes in to place when I actually submit the MR. If I could short circuit that by testing myself I'd be happy to do that. 2021-01-23 15:14:55 adhawkins: It's not wrong to do, but we do not expect everyone to test things on every arch (which would be unreasonable) 2021-01-23 15:14:57 No offence taken mps. Appreciate I'm new at this (hadn't even considered making a new package until someone suggested it when I asked someone to package emborg!), so happy to elicit advice. 2021-01-23 15:15:15 just grumbling old Jon Postels robustness principle 2021-01-23 15:15:43 adhawkins: And we're always happy to guide new users to do this 2021-01-23 15:15:53 I've noticed :) 2021-01-23 15:16:50 some of expect that newcomers are willing to learn, but this is not addressed to adhawkins :) 2021-01-23 15:16:57 of us* 2021-01-23 15:17:33 Thanks mps. WIll leave those two MRs for now. Might do the rest tomorrow. Thanks again both. 2021-01-23 15:18:26 adhawkins: all good and no worries, I see you as perspective contributor/developer 2021-01-23 15:19:12 you are not trying to impose your POVs 2021-01-23 15:26:09 Far too new for that mps! 2021-01-23 15:28:11 adhawkins: when I started to use alpine and fix bugs, help other users, and even made some pkgs I never thought that I will be developer 2021-01-23 15:28:51 even didn't had any intention to become one, but life doesn't ask us what will happen :) 2021-01-23 15:29:29 and I still wonder why I'm developer 2021-01-23 15:31:30 (probably because I'm babbling much) 2021-01-23 15:43:16 I don't know if I can commit that amount of time, and I'm not a serious enough alpine user to motivate me enough. I only use it as the basis of an emborg container I put together, so I thought I'd try to package emborg up to make the container a little more self-contained. 2021-01-23 15:50:05 if I was looking for a default python build check package template for an update apkbuild-pypi would one from one of the new py3 package be fine 2021-01-23 15:51:56 is it possible to cherry-pick pkg from edge to stable (3.13-stable for example) 2021-01-23 15:54:38 I've cherry picked from completely different repos before 2021-01-23 16:06:53 mps: is that a question? 2021-01-23 16:08:52 ikke: nvm, I done it 'by hand' !17355 2021-01-23 16:09:18 mps: ok, but it is possible to cherry-pick, given that there have not been too many changes 2021-01-23 16:10:22 yes, but looks like complicated and risky (for us not expert with git) 2021-01-23 16:11:10 mps: you can try, if it runs into conflicts, just abort 2021-01-23 16:13:13 that is point after which I asked here :) 2021-01-23 16:14:21 now I need about 8 hours for MR, how to set it? 2021-01-23 16:15:05 settings CI/CD on your fork 2021-01-23 16:15:24 General Pipelines section 2021-01-23 16:17:22 ikke: thanks, found it, 10h is ok? 2021-01-23 16:17:41 sure 2021-01-23 16:17:51 this is complete cross-embedded tools 2021-01-23 16:18:02 that needs time 2021-01-23 16:40:31 ikke: 5.10.10 kernel is released but no mentions of nvme 2021-01-23 16:41:50 there's that nvme power saving thing, but i don't think that's a new-kernel thing 2021-01-23 16:42:18 https://wiki.archlinux.org/index.php/Solid_state_drive/NVMe#Controller_failure_due_to_broken_APST_support 2021-01-23 16:42:36 Hello71: mps is referring to the issue we have with 5.10 not finding our lvm volumes on boot 2021-01-23 16:42:39 yeah 2021-01-23 16:46:03 I can't tell, ikke knows does this is related to issue he had 2021-01-23 16:46:25 I'm not sure it's even related to nvme 2021-01-23 19:17:28 #12329 2021-01-23 19:17:40 3.11 is also fixed 2021-01-23 19:18:23 updated 2021-01-23 19:18:29 3.10 not yet? 2021-01-23 19:18:40 and !17318 wait for 3.10 2021-01-23 19:19:06 any reason not to merge? 2021-01-23 19:19:39 no, except I'm not behind machine with my keys from which I can merge 2021-01-23 19:20:00 ok, I can merge it 2021-01-23 19:20:17 will be in a hour or two if someone doesn't merge in meantime :) 2021-01-23 19:21:15 done 2021-01-23 19:21:50 checksum failed on armv7 2021-01-23 19:22:12 curl: (22) The requested URL returned error: 404 2021-01-23 19:27:27 ikke: also #12238 not that I ignore you but I don't know what I can tell about it 2021-01-23 19:27:54 reporter didn't persuaded me that this change is needed 2021-01-23 19:28:42 and I don't like to fall in trap 'whatever users ask we have to obey' 2021-01-23 19:29:48 right, but it seems like they need it for their hardware to properly work? 2021-01-23 19:31:14 looks like it is true, but there is no 'strong or any' evidence that can't be done with initramfs 2021-01-23 19:31:31 or maybe modloop is problem, idk 2021-01-23 19:31:48 ok, maybe suggest that in the issue? 2021-01-23 19:31:52 user didn't reported how it use machine with alpine 2021-01-23 19:32:25 'it' is s/he 2021-01-23 19:33:10 That's why I use they 2021-01-23 19:33:50 I use linux on few chromebook and never need such options 'in kernel', they works nice as modules 2021-01-23 19:35:10 well, 'they' to me sounds 'few of them' while 'it' is singular and better fit in my brain wiring 2021-01-23 19:35:37 but 's/he' is best 2021-01-23 19:35:41 in english, it refers to things 2021-01-23 19:36:30 yes, but I don't think in english (and I can't), I always have to translate in head 2021-01-23 19:37:03 using 'it' for people in english is considered quite rude 2021-01-23 19:37:11 huh 2021-01-23 19:37:38 english should be fixed then :P 2021-01-23 19:38:24 'a person or animal whose sex is unknown or disregarded', emphasis on the last word 2021-01-23 19:39:04 huh (again) 2021-01-23 19:39:15 language is weird 2021-01-23 19:39:38 better to use '...' in such cases 2021-01-23 19:40:12 or simple '?', or $somevar 2021-01-23 19:40:38 "they" is ok 2021-01-23 19:40:50 but I think I'm not right person to fix these problems, ignore me 2021-01-23 19:41:05 yeah, 'they' has traction 2021-01-23 19:41:13 but it's also ambiguous 2021-01-23 19:41:23 hah 2021-01-23 19:41:57 lol that sentence was unintentionally ambiguous as well 2021-01-23 19:59:17 English is fun 2021-01-23 20:00:43 It certainly is 2021-01-23 20:01:59 They certainly is 2021-01-23 20:02:11 :D 2021-01-23 20:04:23 I sorry we don't use some of old (not used as living lang) langs like latin or sanskrit for communications 2021-01-23 20:05:56 Binary esperanto for all AL documentation 2021-01-23 20:06:35 uh no, esperanto is 'constructed' and as such not good 2021-01-23 20:09:02 latin and sanskrit are rich in grammar and expressing thoughts, maybe old greek also but I don't know much about it/they :) 2021-01-23 20:09:04 rms suggests perse :^) 2021-01-23 20:09:16 nah i use they/them too 2021-01-23 20:09:39 most people understand, the people who think its awkward are just pedants ime 2021-01-23 20:10:18 Lisp so one can communicate with the machine spirit 2021-01-23 20:10:31 maxice8: :) 2021-01-23 20:10:36 gendered language sucks and it sucks we have to live with the assumptions it made in the modern information era, where we cant be sure of an object's gender as well as we may used to be 2021-01-23 20:11:01 i awkwardly worded that but you get the idea 2021-01-23 20:11:16 opal: yes, and bad one 2021-01-23 20:11:44 myabe we should take this to #-offtopic 2021-01-23 20:11:51 Yes 2021-01-23 20:12:18 too many offtopic channels 2021-01-23 20:12:44 heh 2021-01-23 20:32:40 https://gitlab.alpinelinux.org/mps/aports/-/jobs/302742#L384 2021-01-23 20:32:51 limit in bytes 2021-01-23 20:34:50 hmm 2021-01-23 20:38:24 it's a runner limit 2021-01-23 20:39:27 can it be increased? 2021-01-23 20:39:46 s/it/they/ 2021-01-23 20:39:46 mps meant to say: can they be increased? 2021-01-23 20:39:52 lol 2021-01-23 20:41:10 mps: any idea how big the logs are? it's already 4M 2021-01-23 20:42:11 huh, no 2021-01-23 20:42:41 I only know that I built in all previous night in devs lxc 2021-01-23 20:43:12 oh, we even have it set to 10M 2021-01-23 20:43:15 and log is 'big big big' I think 2021-01-23 20:43:48 maybe I should split MR to 5 2021-01-23 20:44:03 and do one by one 2021-01-23 20:44:14 sorry, it's in kb, it's 100M 2021-01-23 20:44:44 104857659 this is the log size of that job 2021-01-23 20:44:55 yes 2021-01-23 20:45:09 100M of logs.. 2021-01-23 20:45:21 but easy, this is not important much 2021-01-23 20:45:54 will consider to split it 2021-01-23 21:11:19 wow. finally the "original" at&t ksh93 builds with musl! https://github.com/ksh93/ksh.git 2021-01-23 21:11:40 i just managed to build it on alpine! 2021-01-23 21:11:50 been dreaming about this for years 2021-01-23 21:21:43 adhawkins: if you are still adding python packagege you may want to try apkbuild-pypi again from https://gitlab.alpinelinux.org/timlegge/abuild/-/tree/apkbuild-pypi let me know if you need more changes 2021-01-23 21:41:11 I might do that timlegge. Thanks 2021-01-23 21:55:21 just pushed new testing/linux-gru for all of you who have gru-kevin chromebook. enjoy and report bugs or fixes 2021-01-23 22:28:36 Since I created my couple of MRs earlier, master has moved on, so it says they need rebasing on GitLab. Do I need to keep rebasing them as master changes, or isn't this necessary? 2021-01-23 22:32:20 adhawkins: it could be rebased before merge, not needed before that, usually 2021-01-23 23:03:45 algitbot needs to be fixed to not do https://gitlab.alpinelinux.org/users/root/activity. seems like out of top 20, more than half are waiting on maintainer 2021-01-23 23:03:51 not submitter 2021-01-23 23:14:59 mps So I don't need to keep rebasing the MR branch until it's actually merged? 2021-01-23 23:15:08 no 2021-01-23 23:15:29 aports-qa-bot automatically enables collaboration on all MRs so developers can rebase and then merge 2021-01-23 23:15:34 Ok. So whoever actually merges it will.do that at the point of merging? 2021-01-23 23:15:52 yes 2021-01-23 23:15:58 Ok, understood 2021-01-23 23:16:06 rebasing is only necessary if there are conflicts that cannot be resolved automatically 2021-01-23 23:17:13 One other thing, there's.been a comment on the rkm-code MR about the name of the downloaded file. Do these need to follow a particular convention? I've changed the URL so that GitHub provides what I think is an appropriately named file. 2021-01-23 23:18:48 if that is the case then feel free to ignore it 2021-01-23 23:19:12 rkm_codes-v0.5.tar.gz in this instance 2021-01-23 23:20:12 yeah that is a good name, some GitHub urls return only v0.5.tar.gz 2021-01-23 23:20:17 which can conflict with other sources 2021-01-23 23:22:14 source="https://github.com/KenKundert/rkm_codes/archive/v$pkgver/rkm_codes-v$pkgver.tar.gz" 2021-01-23 23:23:26 Ok. How best.to 'ignore' that comment in the MR so it doesn't look like there's more work to do? 2021-01-23 23:24:24 Should I just resolve that thread in the MR? 2021-01-24 00:33:06 adhawkins: I usually do 'git fetch upstream' and 'git rebase upstream/master' before I push to my origin and create a MR 2021-01-24 00:34:35 most of the time I tend to create a branch just for the package I am working on that way any MRs are seperate (unless the packages are related) 2021-01-24 07:49:00 https://pip.pypa.io/en/stable/news/#id1 2021-01-24 07:49:07 pip dropped support for python2 2021-01-24 07:49:25 oh nice 2021-01-24 08:28:44 adhawkins: #12337 could be closed as 'fixed'? 2021-01-24 08:29:33 nice day will be when I see 'git rm py*' :) 2021-01-24 08:30:21 at the same day we will do git rm perl* :P 2021-01-24 08:30:50 if we do this then we must do 'git rm *' ;P 2021-01-24 08:32:06 btw, I closed this big cross-embedded MR 2021-01-24 08:32:12 ok 2021-01-24 08:33:11 do you delete artifact for such big and bad things by hand or wait till they expire 2021-01-24 08:33:50 if they take disk you can delete them manually right now, they are not needed 2021-01-24 08:34:36 (going to make big coffee, didn't slept well) 2021-01-24 08:37:20 We just let it expire 2021-01-24 08:40:03 ok 2021-01-24 08:53:39 looking at dovecot for 3.11-stable, only sane option is to upgrade to latest stable release, i.e. 2.3.13 2021-01-24 08:54:28 and we should use stone and write on it that for 'important' pkgs we 'must' use only lts versions 2021-01-24 09:28:34 Yes 2021-01-24 09:29:13 There was some suggestion for per package version policies 2021-01-24 10:08:41 mps Yes it could. I could probably have done that through the commit message? 2021-01-24 10:09:29 Have another 4 or 5 packages to fix like the two I did yesterday. Can they be done in one MR, or do I need to keep them split? 2021-01-24 10:10:05 adhawkins: yes. with 'fixes: #12337' in one of lines in commit msg 2021-01-24 10:38:30 Thanks mps. How about doing multiple changes like yesterday in a single MR? Is that the done thing, or should I split them? 2021-01-24 10:39:15 If they are unrelated, separate MRs are better 2021-01-24 10:39:49 Then one does not have to block the other 2021-01-24 10:54:01 Understood ikke. I'll continue using that scheme then. 2021-01-24 10:59:35 What's the difference between a package in 'community' and 'main'? The community repo doesn't get enabled by default during an install does it? What's the procedure for getting in to 'main'? 2021-01-24 11:00:02 Difference is how long we support packages 2021-01-24 11:00:36 Main receives support for 2 years, community only 6 months 2021-01-24 11:00:57 community is basically only supported for the latest -stable release 2021-01-24 11:01:20 Ah ok. So what qualifies a package to move to 'main'? 2021-01-24 11:02:27 i think we don't have an "offical policy" on this but if we can't support it for two years it doesn't go into main think complex software like webbrowser et cetera 2021-01-24 11:03:36 It also depends a bit on how implortant the package is for a base system 2021-01-24 11:03:51 Important* 2021-01-24 11:04:22 Ok, understood. 2021-01-24 11:04:49 Is 'community' enabled by default? It is on my installation, but can't remember if I changed that. 2021-01-24 11:05:19 Not by default on installations you install wit setup-alpine 2021-01-24 11:06:17 we should probably add a "do you want to enable the community repository? [y/n]" dialog to alpine-conf at some point 2021-01-24 11:06:58 Yeah, that might be an idea. If there's a lot of 'useful' stuff in community it'd be nice if it were more discoverable. 2021-01-24 11:07:43 yep, every now and then people also open issues in the bug tracker because they are lacking a package which is actually available but only in community/ 2021-01-24 11:11:10 It should also make the differences between these repositories clear 2021-01-24 11:13:00 It may well already be covered on the website somewhere, I have to admit I didn't look :) 2021-01-24 11:19:16 I've just set my IRC client to highlight my nme in #alpine-commits. Is it Ok to post a quick 'test' message in there to see if it works? 2021-01-24 11:19:43 Sure 2021-01-24 11:20:00 Hmm, might not work if I make the post I guess... 2021-01-24 11:20:12 Oh well, I'll just wait and see when my name next comes up :) 2021-01-24 11:20:36 adhawkins: I just mentioned your name 2021-01-24 11:20:36 Yep, worked. Thanks ikke :) 2021-01-24 11:21:05 Yep, highlight worked. That'll help pick out when my changes are merged and built. 2021-01-24 11:42:36 enabling repos are described in installation wiki pages 2021-01-24 11:48:19 and move pkg to main should be done when it is *really* necessary 2021-01-24 11:49:12 Ok, I understand. As nmeum said earlier, having a step in the installer asking whether they want to enable Community (and why it's probably a good idea) would be useful I think. 2021-01-24 11:49:51 yes, till someone ask why it is not enabled by default 2021-01-24 11:51:31 Well, that's a different question I guess. But bringing it to people's attention at install time would be good, otherwise they may not even know it exists, and wonder why they can't get at a lot of packages. 2021-01-24 11:52:54 make splash screen with complete wiki and docs.a.o for setup-alpine :) 2021-01-24 11:56:14 Think I need to look into some docker based build system moving forward. I'll add that to my todo list. 2021-01-24 12:01:56 About splash screens, has anyone ever gotten Plymouth to work on Alpine? There is a package for it, but no instructions on how to enable it at all anywhere 2021-01-24 12:02:01 I doubt mkinitfs has support for it? 2021-01-24 12:02:21 there is support for splashscreens in mkinitfs 2021-01-24 12:02:24 through busybox fbsplash 2021-01-24 12:03:05 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L646-662 2021-01-24 12:03:07 Not with Plymouth though? 2021-01-24 12:03:18 As I want Plymouth, not fbsplash 2021-01-24 12:03:27 I don't think so 2021-01-24 12:04:39 'use win/macos Luke' 2021-01-24 12:07:03 never could understand why people wants (and pays for them) useless things 2021-01-24 12:10:04 some useless things are for mental health 2021-01-24 12:10:16 :D 2021-01-24 12:10:36 that is, rendering them useful =) 2021-01-24 12:11:38 totally useless to have dynamic motd that outputs ansi colorcoded ascii graphics, but still I've done it on each of my linux boxes =) 2021-01-24 12:12:23 for mental health a glass of red wine is better (a lot) ;) 2021-01-24 12:14:09 sure, but watching that ansi graphics while drinking red wine just makes nostalgic feeling, like being back in 90's BBS 2021-01-24 12:14:45 and without non-free brcm firmware, ssh into rpi4 feels like that 2400bps modem anyway =D 2021-01-24 12:15:32 artok: I fully understand you, even forgot that BBS existed. thanks for reminding me 2021-01-24 12:17:27 my first bought modem was 2400bps, before that I had two made myself, 300bps and 1200bps 2021-01-24 12:20:29 Anyone here use dabuild? How to pass '-r' to the build in the container? It's failing saying the dependencies aren't available 2021-01-24 12:20:58 https://termbin.com/cp6y 2021-01-24 12:22:23 Ah, as simple as running 'dabuild -r' :) 2021-01-24 12:25:48 mps: bad for physical health though, increases cancer risk 2021-01-24 12:26:51 Hello71: what is bad? 2021-01-24 12:26:58 modems? ;P 2021-01-24 12:27:02 alcoholic begerages 2021-01-24 12:27:24 possibly modems are bad for mental health nowadays but depends on personality 2021-01-24 12:29:02 actually life is bad for health, increases cancer risk :) 2021-01-24 12:29:49 and no, wine is good for health, ime 2021-01-24 12:30:42 I use it as only medicine and didn't had to go to doctor/medic for more than 20 years 2021-01-24 12:31:30 but, everyone is free to have its religion 2021-01-24 12:34:52 Well, getting dabuild running was easy enough! 2021-01-24 12:42:17 β†’ #-offtopic 2021-01-24 12:43:34 jvoisin: wine is never OT :) 2021-01-24 13:27:15 oxygen also increases cancer risk :P 2021-01-24 13:28:43 huh, what is this!? https://gitlab.alpinelinux.org/mps/aports/-/jobs/303367#L21 2021-01-24 13:29:27 shellcheck output? 2021-01-24 13:29:37 please remove this obscene wording 2021-01-24 13:30:03 'Names commonly chosen instead of 'master' are 'main', 'trunk' and....' 2021-01-24 13:30:13 aha, 2021-01-24 13:30:15 that's git itself 2021-01-24 13:30:28 latest version of git 2021-01-24 13:30:31 kill the git 2021-01-24 13:30:39 :) 2021-01-24 13:31:00 we'll just add init.defaultBranchname=master to the global git config 2021-01-24 13:31:42 yes, I know and that is last corner of 'sane' world. Thanks ikke 2021-01-24 13:44:51 TBK[m]: Could you try to refork apkbuild-lint-tools to see if you inherrit the image builders now? 2021-01-24 13:49:42 ikke: I deleted, reforked and manually ran a job - https://gitlab.alpinelinux.org/TBK/apkbuild-lint-tools/-/pipelines 2021-01-24 13:49:42 status: stuck 2021-01-24 13:50:17 ikke: pushed latest in list for #12274 2021-01-24 13:50:35 TBK[m]: ok, anoying 2021-01-24 13:50:39 huh, merged :) 2021-01-24 13:50:56 TBK[m]: the image builder runners are intentionally limited to the alpine/infra/docker group 2021-01-24 13:51:07 But I read somewhere that forks should still inherrit them 2021-01-24 13:52:20 k, I will research it tonight when I got some time. 2021-01-24 13:54:13 "Whenever a project is forked, it copies the settings of the jobs that relate to it. This means that if you have shared Runners set up for a project and someone forks that project, the shared Runners will also serve jobs of this project." 2021-01-24 13:54:24 only talks about shared runners, but they should be available anyway 2021-01-24 13:56:36 `https://gitlab.com/groups/gitlab-org/-/epics/3278 2021-01-24 14:34:41 timlegge: when you find some time please help me with !16549 it works in lxc but fails on CIs, probably tty related but I'm not sure 2021-01-24 14:39:11 mps just glanced on my phone. can look closer later today or tonight AST 2021-01-24 14:41:32 yeah, most likely the lack of tty 2021-01-24 14:43:53 try running in "script"? 2021-01-24 14:46:12 timlegge: np, when you find time, we are not in a hurry, so easy 2021-01-24 14:54:02 Hi all. Working through updating my packages the same as the couple I did yesterday. First one is !17385 2021-01-24 15:01:08 !17386 2021-01-24 15:05:25 !17387 2021-01-24 15:08:22 mps: looks related to https://rt.cpan.org/Public/Bug/Display.html?id=128806#txn-1838418 can be reproduced locally with export set TERM="" 2021-01-24 15:08:47 looks like the builders might not have a TERM set properly in the ENV 2021-01-24 15:09:05 There is no TERM 2021-01-24 15:09:10 and no term either :) 2021-01-24 15:09:34 On the builders, these builds are triggered by cron 2021-01-24 15:10:52 on CI, they are run on docker containers, also without controlling TTY 2021-01-24 15:11:33 !17388 2021-01-24 15:13:03 timlegge: interesting. it passed CIs in previous version without problem and now don't. that is what confuses me 2021-01-24 15:13:27 maybe new tests were added? 2021-01-24 15:13:46 ikke: this is probable reason 2021-01-24 15:14:19 so solution is simple "!check" :) 2021-01-24 15:14:33 so either disable these tests, or find a workaround (like Hello71 suggested with `script`) 2021-01-24 15:15:10 I didn't understood what Hello71 means by 'script' 2021-01-24 15:15:38 script provides stdin/stdout for commands that run under it 2021-01-24 15:15:52 https://stackoverflow.com/questions/32910661/pretend-to-be-a-tty-in-bash-for-any-command 2021-01-24 15:17:03 reading.... 2021-01-24 15:17:12 !17389 2021-01-24 15:20:35 Once they're all merged I'll thoroughly test locally and then move to community. 2021-01-24 15:25:13 When I move emborg and all its new dependencies from testing to community, this will be a single MR, but should it be a commit per package, or one commit for them all? 2021-01-24 16:16:43 one commit per package 2021-01-24 16:17:56 mps ikke so 1.37 made a change to make it work better for automated testers like cpantesters seems to have failed for alpine builder. I can look closer 2021-01-24 16:19:13 timlegge: thanks 2021-01-24 16:21:21 Thanks ikke, will do. Just need to wait for those other MRs to complete then will get it done. 2021-01-24 16:56:45 Is it possible to use the Alpine Linux builders or Gitlab CI to build a package? 2021-01-24 16:56:45 I want to apply a patch to the `linux-rpi` package but building it locally on my hardware is a bit hard in terms of resources and arch ... 2021-01-24 16:57:17 DylanVanAssche_: You can submit an (draft) MR to test the build 2021-01-24 16:57:41 but generally it is preferred to reserve builders for changes which you actually want to put in alpine 2021-01-24 16:57:52 right 2021-01-24 16:57:58 if it is a personal patch you can set up cross compile 2021-01-24 16:58:34 Yes, at some point I want to land them in Alpine, or even better: upstream the patch to the Linux kernel. 2021-01-24 16:58:34 However, before I do, I need to be able to test the patch πŸ™‚ 2021-01-24 16:59:09 With a MR, is there a way to extract the `.apk` file from the CI? 2021-01-24 16:59:20 yes 2021-01-24 16:59:30 it will be available as artifact 2021-01-24 16:59:59 Ah okay, great! Thanks! 2021-01-24 17:04:56 DylanVanAssche_: it is totally possible, on github you can do that. check out https://github.com/jirutka/user-aports jirutka uses ci for building his packages 2021-01-24 17:05:22 only problem is that there is a timelimit for ci jobs, and if your build does not finish in time, it's lost entirely. 2021-01-24 17:05:49 i do the same, but i actually ran into this time limit issue on my repo 2021-01-24 17:06:18 It's a Linux kernel so I may hit the time limit as welll 2021-01-24 17:06:20 apparently jirutka uses travis-ci, which is quite troublesome to use nowadays 2021-01-24 17:06:30 this might sound petty, but what shall I do to get https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16784 merged? 2021-01-24 17:06:53 Nothing really 2021-01-24 17:07:03 I don't get notifications when someone approves the merge request 2021-01-24 17:07:11 so it can be missed entirely 2021-01-24 17:07:50 is coming on irc to ping op acceptable? 2021-01-24 17:07:58 sure 2021-01-24 17:08:02 Yes 2021-01-24 17:08:10 as long as it's reasonable 2021-01-24 17:08:29 ok, thanks 2021-01-24 17:09:21 !16784 2021-01-24 17:09:56 this is good MR, remove deps is always good 2021-01-24 17:10:25 unless we then get spammed by users about breaking their setup :) 2021-01-24 17:10:38 but, alas 2021-01-24 17:10:45 I'll be happy to handle the spam due to this MR 2021-01-24 17:11:17 jvoisin: one thing, you can use keywords `closes` or `fixes` following by #issuenum and GitLab will automatically close the issue when the commit is accepted 2021-01-24 17:11:38 oh, right 2021-01-24 17:11:39 ikke: who cares if the patch is good 2021-01-24 17:11:41 liborcus tests on mips64 fails due to this: "what(): boost::filesystem::status: Function not implemented: "../../test/css/invalids/1.css"" 2021-01-24 17:12:15 maxice8: aren't they present? 2021-01-24 17:13:28 ? 2021-01-24 17:14:17 I see " 2021-01-24 17:14:20 closes #12284 2021-01-24 17:14:25 both in the commit message as in the description 2021-01-24 17:15:02 they are, but I pushed that sneakily 2021-01-24 17:16:02 Wow, that was fast! All merged already bar !17388 2021-01-24 17:16:22 also, it would be nice to have a "low hanging fruit"/"easy" label for issue: https://gitlab.alpinelinux.org/alpine/aports/-/labels 2021-01-24 17:16:34 (since I have a bit of free time, and would like to give a hand to Alpine) 2021-01-24 17:17:21 Once that last one is done I can test and make a start on the move to community. 2021-01-24 17:27:47 maybe there is 'trick' to make more branches from range of commits in one branch? 2021-01-24 17:32:45 Is the `aarch64` CI runner out of service? The build seems to be waiting for such a runner 2021-01-24 17:32:45 https://gitlab.alpinelinux.org/dylanvanassche/aports/-/jobs/303630 2021-01-24 17:33:19 hmm, it should be running 2021-01-24 17:34:05 According to Gitlab the runner was last seen 3 hours ago 2021-01-24 17:34:09 yes 2021-01-24 17:34:16 the runner is not able to connect back for some reason 2021-01-24 17:39:02 DylanVanAssche_: restarting the runner fixed it. Somehow docker dns did not work 2021-01-24 17:41:03 Ah okay, thanks! 2021-01-24 17:45:50 Someone here experienced with boost? 2021-01-24 17:48:36 ikke: link? 2021-01-24 17:48:51 Hello71: hold on, creating an issue for it with the details 2021-01-24 17:50:18 Hello71: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12349 2021-01-24 17:54:58 well "Function not implemented" is ENOSYS 2021-01-24 17:55:07 aha 2021-01-24 17:55:17 I think 2021-01-24 17:55:35 so I would recommend strace 2021-01-24 17:55:58 statx(AT_FDCWD, "../../test/css/invalids/1.css", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_TYPE|STATX_MODE, 0xfffffd7d08) = -1 ENOSYS (Function not implemented) 2021-01-24 17:56:02 Hello71: was alreayd on it :P 2021-01-24 17:56:12 so statx 2021-01-24 17:57:19 Hello71: I guess that's due to the kernel being too old 2021-01-24 17:57:37 "Since linux 5.5" 2021-01-24 17:57:53 yes. but why doesn't it fall back? 2021-01-24 17:58:04 maybe same if (errno) issue... 2021-01-24 17:58:24 madvise(0xffebd69000, 4096, MADV_FREE) = 0 2021-01-24 17:58:26 I bet 2021-01-24 17:58:33 that is the next system call 2021-01-24 18:06:09 what now? :-p 2021-01-24 18:06:19 dalias: liborcus / boost 2021-01-24 18:06:32 broken in what way? 2021-01-24 18:06:43 it tries `statix` 2021-01-24 18:06:47 `statx` 2021-01-24 18:06:55 that returns ENOSYS 2021-01-24 18:07:29 Next systemcall is madvise, with the MADV_FREE flag, same as happened with busybox echo 2021-01-24 18:08:16 (kernel is 4.9) 2021-01-24 18:09:07 It happens after `fs::is_regular_file` 2021-01-24 18:11:40 ikke, where is statx being called from? if it's the libc stat function it should just use a different syscall after ENOSYS 2021-01-24 18:11:49 are they doing their own call to it with no fallback ?? 2021-01-24 18:12:07 dalias: was trying to find the source 2021-01-24 18:16:34 dalias: https://github.com/boostorg/filesystem/blob/develop/src/operations.cpp#L2585 lol 2021-01-24 18:16:58 if (statx at compile time) then { statx at run time! } 2021-01-24 18:17:04 lol wtf is this shit 2021-01-24 18:17:13 we *dont* have statx 2021-01-24 18:17:27 there's a pending patch to add it 2021-01-24 18:18:05 and this bug does raise an important point: the patch as submitted is not ok 2021-01-24 18:18:20 https://github.com/boostorg/filesystem/blob/b4d606cdd08640c9bca68f7e97b52245aeef398d/src/operations.cpp#L365 2021-01-24 18:18:35 if (kinda have statx) then { make us have statx harder! } 2021-01-24 18:20:52 it should call fstatat and convert results if requested info is baseline, or as fallback (reporting non-support for extended info) if SYS_statx fails 2021-01-24 18:27:24 any objections to merge !16022 2021-01-24 18:31:10 mps: i gotta test if this breaks my setup, give me about 10 mins 2021-01-24 18:31:40 caskd: ok 2021-01-24 18:31:56 if plain `startx` as normal user is still working (which you have tested), then fine with me 2021-01-24 18:32:46 *nod* 2021-01-24 18:33:55 someone should file a bug against boost 2021-01-24 18:34:01 like 365 is horribly wrong 2021-01-24 18:34:04 line* 2021-01-24 18:34:28 you can't emulate the function with the syscall because the emulation doesn't have a fallback path 2021-01-24 18:35:19 i would just patch that out for now 2021-01-24 18:35:58 Make sure that code is not included? 2021-01-24 18:36:03 #if 0 2021-01-24 18:36:09 well rather 2021-01-24 18:36:14 undefine BOOST_FILESYSTEM_HAS_STATX_SYSCALL 2021-01-24 18:36:21 it's used elsewhere too 2021-01-24 18:36:27 right 2021-01-24 18:36:51 unfortunately this is kinda ABI breaking 2021-01-24 18:36:57 sigh 2021-01-24 18:36:59 i think 2021-01-24 18:37:04 as an alternative you could fix their fallback 2021-01-24 18:37:09 at line 369 2021-01-24 18:37:13 check for errno==ENOSYS 2021-01-24 18:37:21 and call fstatat instead, converting the struct 2021-01-24 18:37:54 that would be non-ABI-breaking and acceptable for upstream i think 2021-01-24 18:38:20 it's the inverse of the conversion in musl's src/stat/fstatat.c 2021-01-24 18:38:34 dalias: from struct stat to struct statx? 2021-01-24 18:38:35 and musl will need this inverse conversion too if we add statx() function 2021-01-24 18:38:37 yes 2021-01-24 18:39:17 converting the dev_t fields is the only nontrivial part 2021-01-24 18:39:25 it needs makedev()/major()/minor() 2021-01-24 18:39:32 i think this statx code is internal to boost lib 2021-01-24 18:39:37 because the kernel folks gratuitously split them out 2021-01-24 18:39:43 oh ok 2021-01-24 18:39:48 if it's internal then just disable it 2021-01-24 18:39:52 because it's useless 2021-01-24 18:40:32 https://github.com/boostorg/filesystem/search?q=statx 2021-01-24 18:40:37 no results in .hpp 2021-01-24 18:41:15 https://github.com/boostorg/filesystem/issues/173 2021-01-24 18:41:28 so just delete https://github.com/boostorg/filesystem/blob/6b5e38134a336b6ea777cd8a69b6ae929819db7e/build/Jamfile.v2#L57 2021-01-24 18:41:38 https://github.com/boostorg/filesystem/issues/172 2021-01-24 18:42:07 boost people never heard of docker i guess 2021-01-24 18:42:49 and this is no even docker 2021-01-24 18:42:56 but linux-headers are way newer than the kernel 2021-01-24 18:43:43 funny thing is (until recently) libseccomp needs new uapi headers 2021-01-24 18:44:17 so really the answer is fuck boost 2021-01-24 18:45:08 change looks fine, had to update my init script though as i call the server directly (i enjoy pain) 2021-01-24 18:47:27 caskd: yes, I run X for long time without suid set 2021-01-24 18:48:12 mps: how do you give the user running it permission to take over the tty? 2021-01-24 18:48:31 but I don't know are there some corner cases where it need to stay 2021-01-24 18:48:43 caskd: modern way, elogind 2021-01-24 18:48:57 old way, udev + add user to video group 2021-01-24 18:49:02 no, I use startx or slim DM 2021-01-24 18:49:21 ah, yes, or dm 2021-01-24 18:49:29 Hello71: and to input group 2021-01-24 18:49:31 Hello71: elogind can do that? could you give me a resource about that or tell me how? 2021-01-24 18:49:59 mps: i think technically that doesn't count but yes 2021-01-24 18:50:51 i currently run elogind only for the power saving stuff, nothing more... would be cool if i could make it more useful 2021-01-24 18:51:56 (those who don't understand unix are doomed to invent it, poorly) 2021-01-24 18:59:17 mps, found the cause of my heisenbug Xorg crashes: https://github.com/sabotage-linux/sabotage/commit/2f4f4ebf149bca3cd1f6e80a8e7486f95edc5bd0 2021-01-24 18:59:38 basically xf86-video-intel's sna (sandybridge acceleration) is buggy 2021-01-24 19:00:13 shouldn't this be configured in xorg.conf? 2021-01-24 19:00:49 i dunno, do you ? 2021-01-24 19:01:11 or better, use modesetting. xf86-video-intel is basically abandonware 2021-01-24 19:01:38 modesetting has good hw accel ? 2021-01-24 19:01:53 sh4rm4^bnc: oh, I thought that only palemon crashes, not X 2021-01-24 19:01:59 anything that still uses xrender is fast enough on cpu 2021-01-24 19:02:27 mps: no, it tore down the whole desktop, having to reboot due to keyboard no longer responding 2021-01-24 19:02:44 uhh, not good 2021-01-24 19:03:13 Hello71: building boost1.75 now on the mips builder with that line removed 2021-01-24 19:03:20 but as Hello71 says, modesetting is quite fine 2021-01-24 19:03:51 https://git.alpinelinux.org/alpine-conf/commit/?id=5847d54be1636f87d16e445e0a903d2e411f7c1c 2021-01-24 19:04:03 links are backwards but doesn't really matter 2021-01-24 19:06:15 ah so this is why i couldnt find any info on this bug. nobody is using xf86-video-intel anymore. 2021-01-24 19:06:44 let me see on old macbook 2021-01-24 19:12:38 hmm, it works with both, modesetting and intel 2021-01-24 19:13:10 the links in above commit point out that the driver is buggy for newer GPUs only 2021-01-24 19:14:23 could be, in last few kernel releases I see a lot of fixes for intel gpu 2021-01-24 19:14:51 kernels* 2021-01-24 19:15:43 i actually updated from 4.14 to 5.4 due to this issue, but didnt help 2021-01-24 19:16:49 iirc, 5.4 also had/have this problem 2021-01-24 19:17:39 I remember that with 5.4 I had some X crashes 2021-01-24 19:18:38 my debugging results were almost always crashes in pixman code called from sna_accel.c, and sometimes on free() in musl in a pixman_destroy codepath 2021-01-24 19:18:57 so i'd guess there's just some memory corruption in the userspace driver 2021-01-24 19:19:36 but for one year I use arm64 workstations 2021-01-24 19:19:50 one should probably compile this code with asan on glibc and check whether it points out some offending code 2021-01-24 19:20:35 how's arm64 perf compared to x86_64 ? 2021-01-24 19:20:56 actually retired last intel about year ago, I use arm workstations for about 5 years 2021-01-24 19:22:08 sh4rm4^bnc, nobody is using xf86-video-intel anymore ?? 2021-01-24 19:22:13 sh4rm4^bnc: I don't do any benchmarks (they are useless imo) but my experience is good 2021-01-24 19:22:14 what does one use instead then? 2021-01-24 19:22:57 modesetting, apparently 2021-01-24 19:22:58 xf86-video-modesetting 2021-01-24 19:23:19 hello71, i don't understand "modesetting". aiui all drivers use kernel mode setting nowadays but they still have all the userspace driver crap 2021-01-24 19:24:24 mesa-dri-intel also 2021-01-24 19:25:17 but I'm not 'graphic man' so don't know much about fine points 2021-01-24 19:25:46 it looks like my xorg finds both intel and modesetting but uses intel 2021-01-24 19:25:49 should i change that? 2021-01-24 19:26:24 if you don't have issues probably not 2021-01-24 19:26:25 (is there any modern documentation on this stuff??) 2021-01-24 19:27:47 well enabling glx makes the x server crash :/ 2021-01-24 19:27:52 i'd like to be able to enable it 2021-01-24 19:28:46 and then disable clients' access to dri crap 2021-01-24 19:29:26 what's bad about dri ? 2021-01-24 19:29:43 i recall i had once to disable dri3 because i would get crashes otherwise 2021-01-24 19:29:43 broken privilege model, requires dynamic linking 2021-01-24 19:30:09 if you have working glx you could literally just static link mesa glx backend 2021-01-24 19:30:17 interesting 2021-01-24 19:31:56 in theory 2021-01-24 19:32:13 i actually have no idea if the protocol supports modern features or if it's bitrotted beyond usability or whatever 2021-01-24 19:32:20 but i want to test it 2021-01-24 19:34:51 uhm, ppc64le CI https://gitlab.alpinelinux.org/mps/aports/-/jobs/303692#L264 2021-01-24 19:35:05 make: /bin/sh: Operation not permitted 2021-01-24 19:35:39 ah, I don't think we ran into that before fore ppc64le 2021-01-24 19:36:03 first time see that on ppc 2021-01-24 19:38:14 should be fixed now 2021-01-24 19:41:51 thanks, restarted job 2021-01-24 19:55:31 Watching mips64 build is like watching paint dry 2021-01-24 20:03:15 Hello71: dalias # PASS: 10 FAIL: 0 2021-01-24 20:06:51 dalias: in this context i mean xf86-video-modesetting, which i think uses glamor (opengl) as a backend for xrender 2021-01-24 20:07:37 the theory being that 3d accel is better maintained than 2d, so just use 2d commands in 3d mode 2021-01-24 20:08:45 also i think glx will also become poorly maintained as time goes on, since it is not compatible with wayland 2021-01-24 20:16:15 Hello71: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17410 2021-01-24 20:18:33 ikke: commented 2021-01-24 20:18:58 thanks 2021-01-24 20:19:28 python3.9.1 is coming later today 2021-01-24 20:20:09 maxice8: I was trying to get the builders green again before that 2021-01-24 20:20:24 Makes sense 2021-01-24 20:20:24 I have one fix for boost 2021-01-24 20:20:31 that fixes mips64 2021-01-24 20:20:32 if the builder isn't green I can delay it 2021-01-24 20:20:46 or rather, should 2021-01-24 20:23:15 vamp-sdk is holding up s390x 2021-01-24 20:23:17 Also this will help with the py3-setuptools 52 which removes easy_install 2021-01-24 20:23:22 vamp-sdk should be disabled 2021-01-24 20:23:26 ok 2021-01-24 20:24:13 our certificates don't include the ones used by vamp-sdk 2021-01-24 20:24:21 works in the web browser with its own certificates 2021-01-24 20:24:21 vamp-sdk is required by some pacakges 2021-01-24 20:24:24 packages* 2021-01-24 20:24:35 I guess it does not include the intermediate 2021-01-24 20:24:41 no it doesn't 2021-01-24 20:25:08 shakes fist at MS 2021-01-24 20:26:23 also doesn't work on my Fedora Silverblue's curl 2021-01-24 20:26:27 so no clue what the deal is 2021-01-24 20:27:21 certificates should include the entire chain, excluding the root cert 2021-01-24 20:28:22 but it does seem to have build for other arches 2021-01-24 20:30:58 Do I need to do anything to close a MR after it has been merged? 2021-01-24 20:31:08 Nop 2021-01-24 20:31:32 Ok, will leave well alone then. Thanks cogitri 2021-01-24 20:34:22 maxice8: I think I just fixed vamp-sdk (by setting DISTFILES_MIRROR on s390x 2021-01-24 20:34:29 but you disabled it already 2021-01-24 20:36:49 I did it sometime ago 2021-01-24 20:36:53 ok 2021-01-24 20:37:13 the reason it did not work on s390x is because it did not have that setting 2021-01-24 20:37:18 while the others had 2021-01-24 20:37:30 so s390x was never fetching from distfiles ? 2021-01-24 20:37:45 correct 2021-01-24 20:38:02 it's not a durable solution, but for the time being, it works 2021-01-24 20:43:36 maxice8: mips64 and ppc64le still have a bit to build 2021-01-24 20:44:20 I see 2021-01-24 20:44:29 37% and 29% 2021-01-24 20:44:51 and mips64 will be stuck on liborcut until boost is merged 2021-01-24 20:51:07 boost is merged, so liborcut should not be a blocker anymore 2021-01-24 20:51:16 it would probably help a lot if the builders always ran latest kernel and docker host 2021-01-24 20:51:30 so as not to hit stupid syscall errors 2021-01-24 20:51:38 dalias: we're kind of stuck with mips 2021-01-24 20:51:46 :/ 2021-01-24 20:51:47 the builder is running a BSP kernel 2021-01-24 20:51:54 eeeewww 2021-01-24 20:52:05 They need to reverse engineer the network driver 2021-01-24 20:52:16 I'm working on upgrading the rest 2021-01-24 20:52:31 Most CI hosts run 3.13 already 2021-01-24 20:53:09 lol is it gpl infringing?? 2021-01-24 20:53:20 dalias: I have no clue 2021-01-24 21:02:57 Ariadne has details, but afaik they have the source but it's terrible 2021-01-24 21:03:05 so they are rewriting it... slowly 2021-01-24 21:03:51 its so awful of linux to have your API level tied to your hardware support layer 2021-01-24 21:04:23 i mean the question is who would maintain the old versions 2021-01-24 21:04:27 like, what version of syscall api you have and what version of hardware drivers and architecture abstraction you have should be completely unrelated things 2021-01-24 21:04:58 the windows alternative is not much better, with microsoft releasing new apis every couple years because everybody is too scared to touch the old ones for fear of backward compat 2021-01-24 21:05:19 indeed 2021-01-24 21:05:47 mac just says "fuck ur 'backwards compat'" 2021-01-24 21:06:18 dalias: I guess that's the consequences of a monolithic repo 2021-01-24 21:06:24 s/repo/kernel 2021-01-24 21:06:25 ikke meant to say: dalias: I guess that's the consequences of a monolithic kernel 2021-01-24 21:06:32 so yeah it kinda sucks but i don't see a better way, unless someone really wants to pour in what would probably be millions of dollars to maintain the old apis 2021-01-24 21:06:43 and right, at that rate you might as well finish hurd 2021-01-24 21:13:50 ikke: several of the Octeon III kernel patches stranded in review, I am guessing because Cavium got acquired by Marvell and Marvell is more interested in ARM... 2021-01-24 21:20:38 "maintain the old apis" seems to be assuming some implementation strategy i'm not assuming 2021-01-24 21:23:00 How would it work then? 2021-01-24 21:23:17 You would need some stable API for drivers to work against 2021-01-24 21:23:43 py3-twisted failing on ppc64le 2021-01-24 21:23:45 twisted.internet.error.CannotListenError: Couldn't listen on fe80::fc8c:47ff:fe3a:fa24%eth0:0: [Errno 99] Address not available. 2021-01-24 21:24:29 dadfailed 2021-01-24 21:26:26 removed the address from the interface 2021-01-24 21:30:34 ikke, the stupid monolithic-kernel-like way to do it is the other way around. HAL kernel lives *under* the kernel layer that hosts applications 2021-01-24 21:31:30 so you just keep running the 3.x crap or whatever on the hardware, but applications are running on a 5.10 version of the process environment 2021-01-24 21:31:51 think uml-like 2021-01-24 21:32:03 this is not the good secure factorization where drivers are unprivileged 2021-01-24 21:32:34 but this _does_ require some interface between the 2 2021-01-24 21:32:50 yes 2021-01-24 21:33:10 and you cannot change this interface 2021-01-24 21:34:14 !17288 !17287 2021-01-24 21:34:34 some discussions will never end ;) 2021-01-24 21:35:17 maxice8: kunkku maintains both 2021-01-24 21:55:31 maxice8: py3-usb fails on ppc64le 2021-01-24 21:56:07 WARNING: The wheel package is not available. 2021-01-24 21:56:13 /usr/bin/python3: No module named pip 2021-01-24 22:00:26 oh 2021-01-24 22:01:42 missing py3-setuptools_scm 2021-01-24 22:01:59 py3-setuptools 52 no longer provides easy_install and thus will fail whenever a dependency is missing 2021-01-24 22:02:22 sounds like a good thing 2021-01-24 22:02:46 it basically broke loads of APKBUILDs that silently relied on easy_install 2021-01-24 22:02:55 I plan on fixing them as part of the python3.9 transition 2021-01-24 22:03:59 at least dependencies are explicit 2021-01-24 22:04:04 then 2021-01-24 22:04:12 dalias: firecracker? 2021-01-24 22:05:03 https://github.com/void-linux/void-packages/blob/master/common/build-style/python3-pep517.sh 2021-01-24 22:09:28 ? 2021-01-24 22:11:45 python3 ecosystem is moving to those fancy pep517 and all the poetry/flint stuff 2021-01-24 22:11:53 one day Alpine Linux will have to start packaging it too 2021-01-24 22:16:51 if there's anything python ecosystem is known for, it's not quickly moving to new systems 2021-01-24 22:26:06 I wonder how setuptools_scm actually works for us I think it doesn't 2021-01-24 22:26:28 actually my current plan is to backport mips64 kvm support to the bsp kernel 2021-01-24 22:27:45 sl 2021-01-24 22:28:02 So the builders will run in a VM? 2021-01-24 22:49:14 yes 2021-01-24 22:51:25 ooh nice 2021-01-24 22:51:45 yeah that's roughly the factorization i had in mind 2021-01-24 22:51:48 just stated better 2021-01-24 22:52:50 ahd possible 'today' 2021-01-24 22:52:52 :) 2021-01-24 22:53:50 Ariadne: does it not support xen? 2021-01-24 22:54:11 xen is not ported to mips at all 2021-01-24 22:54:15 ah 2021-01-24 22:55:08 apparently there is actually a port. for one cpu. from 2014. 2021-01-24 22:57:05 hmm, qemu-system-mips64 is there so missing part is kvm part in kernel iiuc 2021-01-24 22:58:05 does it makes sense to run qemu-system-mips64 on some other arches with superfast host 2021-01-24 22:58:38 depends on how good the emulation is 2021-01-24 22:59:39 last time I looked (about 5 years ago) mips ISA is not much too complicated 2021-01-24 23:00:35 though I never programmed anything in its assembler, just few simple exercises for my daughter faculty 2021-01-24 23:04:19 well the problem isn't implementing add or sub 2021-01-24 23:05:37 it's implementing floating point math, interrupts, hardware emulation, vector (and other) isa extensions... 2021-01-24 23:06:49 Hello71: no worries, I didn't raised my hand for this job ;) 2021-01-24 23:08:58 plus trying to do all of that *fast* 2021-01-24 23:36:42 py3-inform missis pytest-runner 2021-01-24 23:37:54 fixed 2021-01-24 23:38:07 thanks Ikke and py3-setuptools=52.0.0-r0 2021-01-24 23:41:31 yeah add and sub are only hard on cisc ;-) 2021-01-24 23:43:35 movfuscator etc :p 2021-01-25 00:18:18 maxice8: bah, you beat my by a few seconds to that MR for porting those plugins to posix sh 2021-01-25 00:18:26 :P 2021-01-25 00:18:42 :^) 2021-01-25 00:18:50 mps: ikke: not sure if it is acceptable but adding export TERM=xterm-256color to the check seems to work -> !17415 2021-01-25 01:18:19 [15:55:05] apparently there is actually a port. for one cpu. from 2014. 2021-01-25 01:18:23 probably not the cpu we have :))) 2021-01-25 04:35:40 oh we are missing py3-pytest-runner a lot 2021-01-25 04:36:54 I feel like the python3.9 rebuild is gonna be a lot of red fun :D 2021-01-25 06:15:41 timlegge: Yeah, I don't see why that should be a problem 2021-01-25 06:56:17 morning 2021-01-25 06:57:29 maxice8: are you working on python 3.9? I wonder if we should update the triplet 2021-01-25 06:57:52 I have an MR for it 2021-01-25 06:58:07 Just not the massive rebuilds necessary 2021-01-25 06:59:57 "checking for the platform triplet based on compiler characteristics... x86_64-linux-gnu" 2021-01-25 07:00:10 i wonder if we may want to change that 2021-01-25 07:01:56 dalias: IIRC you once mentioned that it maybe was not a good idea to build python as x86_64-linux-gnu? 2021-01-25 07:02:59 i also wonder if we could make python wheels work properly, the precompiled modules 2021-01-25 07:04:40 basically, i'm interested in fixing this: https://lih-verma.medium.com/alpine-makes-python-docker-builds-way-too-50-slower-and-images-double-2-larger-61d1d43cbc79 2021-01-25 07:11:55 I had planned to do it yesterday near midnight but the builders aren't green yet 2021-01-25 07:14:15 i'd like to investigate if we need to build python differently to get musl wheels 2021-01-25 07:14:51 As far I understand (not a whole lot) we would need pypa or whatever authority manages pypi to host those like they host for manylinux 2021-01-25 07:15:40 Or host our own precompiled wheels and configure pip to look for them 2021-01-25 07:16:02 https://github.com/pypa/manylinux/issues/37 2021-01-25 07:18:30 there is a warning here about alpine linux https://realpython.com/python-wheels/#the-manylinux-wheel-tag 2021-01-25 07:19:07 but really, we don't want alpine to build those binary python wheels. we want upstream do it themselves, just like they build for manylinux 2021-01-25 07:19:26 we should find a solution for musllinux or similar 2021-01-25 07:20:02 and maybe provide docker images so its trivial for python devs to add alpine to their CI 2021-01-25 07:21:21 but i think first step is to investigate how pip can tell the difference if its gnu vs musl linux 2021-01-25 07:28:29 here is another discussion about the topic: https://mail.python.org/archives/list/distutils-sig@python.org/thread/H3323AXRRLJAYOY2XZKS74IOUQMJUOYD/ 2021-01-25 07:29:33 mips64 and ppc64le are still rolling 2021-01-25 07:43:21 maxice8: I'd like to know if we should build python in different way to help https://mail.python.org/archives/list/distutils-sig@python.org/thread/H3323AXRRLJAYOY2XZKS74IOUQMJUOYD/ move forward 2021-01-25 07:43:45 I have no clue about all that 2021-01-25 07:46:52 maybe dalias knows? 2021-01-25 07:47:17 in either case, i'd like to make sure that we build python 3.9 properly 2021-01-25 07:47:39 sounds good, I'll delay the upgrade until this is sorted out 2021-01-25 07:48:13 ncopa: can you take a look at abuild MRs ? 2021-01-25 07:59:30 https://mm.icann.org/pipermail/tz-announce/2021-January/000065.html 2021-01-25 08:02:50 it's a pity earth is not flat and sun doesn't have light switch, all these TZ nonsense would disappear 2021-01-25 08:05:07 you just made the best pro-flatearth argument ever 2021-01-25 08:05:41 :) 2021-01-25 08:06:56 morning coffee is a strong inspiration for a lot of ideas 2021-01-25 08:07:58 and Brazilian ones, ofc ;) 2021-01-25 08:09:27 oh, not to forget Dutch tobacco 2021-01-25 08:30:58 timlegge: thanks. I wanted to merge your MR but it have WIP so I merged mine 2021-01-25 10:10:45 !17437 2021-01-25 10:10:52 The final step hopefully! 2021-01-25 10:17:49 adhwankins you need to move py3-arrow as well 2021-01-25 10:18:54 That's not one of my packages maxice8. Good point though, let me check all the dependencies. 2021-01-25 10:19:14 It isn't but if you don't move it then your MR is moot and broken 2021-01-25 10:19:21 Fair point. Thanks. 2021-01-25 10:19:22 put a commit to move it and tag the maintainer 2021-01-25 10:19:33 How do I do that maxice8? 2021-01-25 10:19:56 the top of the APKBUILD has the maintainer name and email (hopefully in the future we will be able to quickly map that to gitlab username too) 2021-01-25 10:20:22 And how do I 'tag' them? 2021-01-25 10:20:32 @username 2021-01-25 10:20:36 just did it 2021-01-25 10:21:31 Ok, I've added the commit. 2021-01-25 10:22:05 #12274 should be closed, yesterday pushed fixes for last two releases 2021-01-25 10:22:16 Will go round and double check there are no others. 2021-01-25 10:46:09 Ok, been through all the packages checking their dependencies, and they're all available in either community or main. Thanks for spotting that maxice8, should be good to go now. 2021-01-25 10:54:11 CI should catch that as well, btw 2021-01-25 10:54:25 if you try to build something in community, the testing repo is not available 2021-01-25 10:54:31 so the build should fail 2021-01-25 10:56:46 Ah ok, that's good to know. 2021-01-25 10:58:44 Any way I could catch that in a local build ikke? 2021-01-25 10:58:53 I'm using dabuild at the moment. 2021-01-25 10:59:26 adhawkins: I guess not easily. I assume all 3 repos are enabled in the dabuild image 2021-01-25 11:02:28 ikke: Yes you're right, all three repos enabled. 2021-01-25 11:03:29 The only easy way to catch this is to remove the not required repo 2021-01-25 11:03:45 Yeah, that'd be easier to do if I weren't running in docker I suppose. 2021-01-25 11:04:07 I might add it as a feature suggestion on dabuild, sounds like it could be useful? 2021-01-25 11:04:45 adhawkins: It could probably use the same logic as we do in our CI 2021-01-25 11:06:45 Yeah, that sounds like a good plan. 2021-01-25 11:06:57 https://gitlab.alpinelinux.org/alpine/docker-abuild/-/issues/70 2021-01-25 11:31:09 mps no worries glad it worked 2021-01-25 11:32:16 ncopa: I wonder how to debug an issue we have on one of the packet hosts we have. Details are here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12325, but summary: on the latest kernels (5.10.x), during boot, it fails to activate the lvm volumes (nlplug-findfs). When I run the same command in the emergency shell, it works 2021-01-25 11:34:20 ikke: what was the result of adding sleep? 2021-01-25 11:34:48 Hello71: Maybe I should have added more sleep, but 10/15 seconds didn't seem to help 2021-01-25 11:44:38 wondering if this is related to that linux uevent add/bind change... 2021-01-25 11:45:16 no, that was 4.12... 2021-01-25 11:52:39 I can only tell that 5.9.9-0-edge kernel works on one of the servers I maintain, with nvme 2021-01-25 11:52:57 though no lvm 2021-01-25 11:52:58 hm, does nlplug-findfs really use 100% cpu while polling? 2021-01-25 11:53:31 mps: it works on another server we have, but it uses efi boot, not legacy boot 2021-01-25 11:53:50 There might be other differences 2021-01-25 11:54:32 aha, yes also 'my' use uefi 2021-01-25 11:55:50 ikke: maybe you can try libahci.ignore_sss=1 2021-01-25 11:56:05 as kernel parameter? 2021-01-25 11:57:30 this is kernel cli parameter 2021-01-25 11:58:00 hm, not strictly 'cli' but command line, so 'cl' 2021-01-25 11:58:19 I'll try later 2021-01-25 11:58:35 how many disks does your server have? 2021-01-25 11:58:50 and are they real HDDs 2021-01-25 11:59:00 4, all either nvme or ssd 2021-01-25 11:59:07 so nothing to spin up 2021-01-25 11:59:46 and the boot output indicated the kernel at least detected the disks before nlplug-findfs was run 2021-01-25 12:01:18 hm... maybe try that, and also try sticking partprobe in somewhere 2021-01-25 12:01:37 the ignore_sss? 2021-01-25 12:01:47 also try replacing nlplug-findfs call with sh, then running nlplug-findfs manually 2021-01-25 12:01:50 yeah 2021-01-25 12:01:54 or some combination of those 2021-01-25 12:19:45 if remove ifupdown-ng what is intended to start 'lo' interface 2021-01-25 12:20:54 write new 'networking' init script? 2021-01-25 12:22:34 /etc/init.d/loopback 2021-01-25 12:46:14 ikke: we have a place where to reproduce and debug it in peace? 2021-01-25 12:46:54 ncopa: usa7, which means, taking x86_64 ci down for a bit 2021-01-25 12:48:58 maybe we can have a look at it tomorrow? 2021-01-25 12:49:04 today is busy 2021-01-25 13:20:11 in the meantime, what's wrong with the builders? 2021-01-25 13:41:28 Looks like py3-arrow has been in 'testing' for several months. How long would packages usually stay there before moving? 2021-01-25 13:42:44 no specific time 2021-01-25 13:43:54 Ok. Just to migrate emborg py3-arrow also needs to migrate. Wondering how long it'll hold it up. 2021-01-25 14:28:01 depends on reasons and maintainer 2021-01-25 14:34:42 could someone merge !17310? 2021-01-25 14:45:52 what is fine difference between words could and would? 2021-01-25 14:45:53 mps Yes, understood. Hopefully the maintainer of py3-arrow will respond in a timely fashion. 2021-01-25 14:46:22 Could means it's possible to do, would means you are going to do it if conditions allow. 2021-01-25 14:46:43 So a 'would' is more of an intention to actually do it. 2021-01-25 14:46:49 :) 2021-01-25 14:47:01 that was ironical question 2021-01-25 14:47:08 differehttps://www.learnersdictionary.com/qa/How-to-Use-Could-Would-and-Should#:~:text=Could%20is%20used%20to%20say,is%20not%20going%20to%20happen. 2021-01-25 14:47:24 adhawkins: sorry 2021-01-25 14:47:28 mps: Apologies. Wasn't sure if you were a non-native English speaker asking for a clarification :D 2021-01-25 14:47:29 mps: could/should/would - increasely degrees of likelyhood of something to happen :-) 2021-01-25 14:47:29 My bad! 2021-01-25 14:48:12 I'm self taught in english, and obviously not good teacher :) 2021-01-25 14:48:48 regression in firefox since upgrading to 84: getaddrinfo result order is not honored 2021-01-25 14:49:02 thus firefox is making ipv6 connections over 6to4 rather than usign ipv4 results 2021-01-25 14:49:23 because its own resolver is shit and doesn't follow rfc 3493 2021-01-25 14:49:37 looks like even 'ping' likes this 2021-01-25 14:51:00 ? 2021-01-25 14:51:09 how so? 2021-01-25 14:51:23 adhawkins: if there no blocker for moving pkg from testing to community you can create MR and assign it to maintainer 2021-01-25 14:51:54 dalias: ping prefer ipv6 over ipv4 2021-01-25 14:52:20 even if routing doesn't work 2021-01-25 14:52:51 it's enough for it to see ipv6 in dns response 2021-01-25 14:54:17 this ipv6 'switch' reminds of famous anecdote about british to switch to drive on the 'right' side 2021-01-25 14:54:32 mps, doesn't seem to 2021-01-25 14:54:43 $ ping google.com 2021-01-25 14:54:43 PING google.com (172.217.164.142): 56 data bytes 2021-01-25 14:54:50 ye in many apps ip6 > ip4, first trying ip6 then fallback to ip4 2021-01-25 14:55:01 hmm, in my case it tries over ipv6 2021-01-25 14:55:05 ye because got ping6 for ip6 2021-01-25 14:55:16 mps, presumably because you have a preferable route for v6 2021-01-25 14:55:21 no ping6, but ping 2021-01-25 14:56:19 ye ping by default trying ip6 first too 2021-01-25 14:56:37 need use ping -4 to force ip4 2021-01-25 14:57:36 hmm, yes ipv6 is 'preferred medium', didn't noticed 2021-01-25 14:58:10 the problem is that firefox seems to be doing its own idiotic thing ignoring the results of getaddrinfo 2021-01-25 14:58:41 dalias: ye that is why I disable ipv6 in firefox :P when of course dont have ipv6 network 2021-01-25 14:59:20 dalias: from this https://github.com/libuv/libuv/issues/2225 I'm guessing Firefox is assuming glibc behaviour: "That means musl by default returns addresses that may be unreachable from the current machine whereas glibc won't." 2021-01-25 14:59:50 minimal, nope 2021-01-25 15:00:20 there is no problem with unreachable addresses here 2021-01-25 15:00:25 the problem is not honoring the preference order 2021-01-25 15:00:56 hmm, what order? 2021-01-25 15:00:59 (which is the same as the nodejs bug, but i'm not sure if the mechanism is the same (wrongly resorting them itself) or different (e.g. bypassing getaddrinfo entirely) 2021-01-25 15:01:18 getaddrinfo returns results sorted by routability preference 2021-01-25 15:01:42 if one family is routable and the other isn't, the one that is will be first 2021-01-25 15:01:56 but also if individual addresses are not routable they'll be last 2021-01-25 15:02:24 and if individual addresses are tunnel (6to4) themselves or are routed out over an address that's a tunnel, they're de-preferred 2021-01-25 15:03:22 something happpened in the rough range 69..84 to break this 2021-01-25 15:05:03 and it's really annoying because, aside from impacting performance, google throws a captcha nag at you every time you make a search query over 6to4 2021-01-25 15:05:10 lying that it's deprecated 2021-01-25 15:06:01 network.dns.ipv4OnlyDomains = google.com should fix it for now.. 2021-01-25 15:06:13 everytime like every single use or after when rerun firefox? 2021-01-25 15:06:19 every single use 2021-01-25 15:06:42 not 100% but not just once per restart 2021-01-25 15:06:56 basically their abuse prediction AI just treats 6to4 as sus 2021-01-25 15:07:12 maybe just your range 2021-01-25 15:07:12 ye weird, normaly would use cookies to avoid that 2021-01-25 15:07:24 I'm assuming musl doesn't support gai.conf 2021-01-25 15:07:25 With abfe51e79a7a833c2c0e4210e6ecddd42d7285ca pkgrel did not get reset (https://git.alpinelinux.org/aports/tree/main/linux-lts/APKBUILD?id=abfe51e79a7a833c2c0e4210e6ecddd42d7285ca#n10) and all the kernel packages are looking for 5.10.10-r0 2021-01-25 15:07:26 they probably dont have cookies 2021-01-25 15:07:33 could be mtu but I don't think so 2021-01-25 15:07:57 minimal, gai.conf is only needed to *change* this behavior not to get the right default we should be getting (and are getting when gai is called and results are used right) 2021-01-25 15:08:41 dalias: yeah I know - I was bringing up a side issue 2021-01-25 15:09:11 I know that problem with huricane electric ipv6 tunnels but I had private mode enabled so my ipv6 address was different every reboot and then google was asking me to confirm that Im not a bot... 2021-01-25 15:11:37 yeah it's really hostile 2021-01-25 15:12:20 and ye google reCaptcha using cookies 2021-01-25 15:17:21 TBK[m]: so modules need to be fixed to use the correct rel 2021-01-25 15:19:17 my-r, i'm not sure it even has access to cookies 2021-01-25 15:19:35 ncopa: ping 2021-01-25 15:19:48 i use firstparty isolate, so i'm not sure if searches from url bar get the google.com cookies or an empty context 2021-01-25 15:19:58 for the initial search query that is 2021-01-25 15:20:06 once google.com is up in the tab it's the google.com isolate 2021-01-25 15:20:51 hmm as an aside, i should use container tabs for google too 2021-01-25 15:21:19 so just my gmail container tab is logged into google and default is not logged in or logged in as junk account 2021-01-25 15:21:35 but i'm not sure if you can do stuff like turning off personalization and history if not logged in.. 2021-01-25 15:23:25 BTW Google's anonymising of IPv6 addresses is not correct anonymisation - they use a /48 mask whereas some ISPs handle out /48 blocks to end customers 2021-01-25 15:24:16 yep 2021-01-25 15:24:57 haven't seen anyone pull them on this yet (i.e. a EU Data Protection Authority re GDPR) 2021-01-25 15:32:19 mps: Your English is a million times better than my (insert whatever your native language is) 2021-01-25 15:32:37 And I've already created an MR moving this package over (along with all of mine) and the maintainer is mentioned in it. 2021-01-25 15:33:20 Looks like Leo was the last person to touch it though, they did the last upgrade. 2021-01-25 15:44:02 dalias: that is why you have recaptcha so often, I have recaptcha too when remove cookies, and yes it is good idea to use extension like "Firefox Multi-Account Containers" 2021-01-25 15:46:52 my-r, no, i don't get it when gai results are used correctly 2021-01-25 15:47:06 only now that firefox is wrongly connecting over 6to4 2021-01-25 15:50:05 dalias: I wouldnt be suprised if firefox just started ignore what is in gai.conf :\ 2021-01-25 15:53:57 ^ or maybe that: https://gist.github.com/e00E/70bcb5f7f0db216739029a7b7e342fdf 2021-01-25 15:57:49 actually i think firefox doesn't use gai 2021-01-25 15:58:06 something about dns ttl 2021-01-25 16:00:11 isn't there a knob in firefox to use the gai instead of its own cruft? 2021-01-25 16:01:13 MY-R: that link does bring up the general question that if you have machines with only IPv6 ULA and you're using either IPv6-prefix-mapping (so NAT-ting between global and ULA prefixes) or general NAT6 whether this will work as expected in general 2021-01-25 16:02:16 detha, that's what i'm looking for... 2021-01-25 16:02:54 only ipv6 just isn't viable yet 2021-01-25 16:03:01 you need some shitty ipv4 nat too 2021-01-25 16:03:05 until all sites support v6 2021-01-25 16:03:22 ACTION wonders where network.dns.disabled does 2021-01-25 16:03:32 *what 2021-01-25 16:03:37 detha, it's for use with tor when you want to be really sure you don't make dns queries 2021-01-25 16:03:47 dalias: sorry I was unclear, I wasn't talking about IPv6-only but rather in a IPv6 context where the only IPv6 address machines have is a ULA, so no global address 2021-01-25 16:04:05 minimal, that can just be normal NAT'd tho, no? 2021-01-25 16:04:44 i.e. nat works without also requiring forgery of dns results 2021-01-25 16:05:34 well that was my point - there's to ways to NAT - either map ULA prefix to global prefix (so rest of address is same) or do general NAT6. That like that MY-R posted seemed to imply that the RFC/GAI rules might cause issues with such NAT scenario 2021-01-25 16:05:45 s/to ways/two ways/ 2021-01-25 16:05:45 minimal meant to say: well that was my point - there's two ways to NAT - either map ULA prefix to global prefix (so rest of address is same) or do general NAT6. That like that MY-R posted seemed to imply that the RFC/GAI rules might cause issues with such NAT scenario 2021-01-25 16:09:20 Where a destination host has both IPv4 & IPv6 and where my local machine has IPv4 & ULA IPv6 and I have some form of IPv6 NAT in place and my app looks up a DNS name that returns both A and AAAA records will I be able to make a IPv6 connection to the destination? 2021-01-25 16:13:58 dalias: which goes back to my earlier "question", does musl support reading a gai.conf file? (which might be needed to fudge around such a NAT6 issue if it exists) 2021-01-25 16:16:05 no, musl does not support gai.conf, but it's not needed for this 2021-01-25 16:16:14 sorting by routability will automatically handle it 2021-01-25 16:17:33 and the routability handles the "IPv6 ULA address but no IPv6 global address" situation with NAT6 ok? 2021-01-25 16:20:30 yes. the nat6 isn't important, just that your host has a route to the ipv6 result 2021-01-25 16:20:54 ok. thanks. 2021-01-25 16:21:06 if your routing tables are misconfigured and claim there's a route to it, but the router won't in turn route them, then you'll have problems 2021-01-25 16:21:17 but that should not happen under normal ipv6 autoconfig 2021-01-25 16:21:41 (i.e. assuming routers are not advertising routes they don't actually intend to honor) 2021-01-25 16:37:51 dalias: I'm using ULA internally mainly for servers to communicate between themselves so using static config (don't want internal-only traffic to fail due to a dynamic announcement (DHCP/RA/whatever) failing). 2021-01-25 16:41:15 *nod* 2021-01-25 16:41:36 heh our getaddrinfo tries to compute routability on :: and 0.0.0.0 2021-01-25 16:41:58 this should probably be dropped 2021-01-25 16:45:58 well default route should be taken in account as in the above scenario those machines with ULA-only IPv6 addresses have a IPv6 default route pointing to the boundary router/firewall which will be doing IPv6 NAT6 to global addresses 2021-01-25 16:47:45 yes 2021-01-25 16:48:46 need a coffee now - too much IPv6 discussion makes my head hurt lol 2021-01-25 16:48:52 :) 2021-01-25 16:49:36 oh yes, for ipv6 need special mood :D 2021-01-25 16:51:46 dalias: so if it isnt about ula etc why you need gai.conf at all? 2021-01-25 16:53:48 ahh 4to6 ok ok nevermind :) 2021-01-25 16:53:52 well i need the default sorting without gai.conf 2021-01-25 16:55:04 maxice8: pong 2021-01-25 16:55:43 Linux-lts pkgrel wasn't reset 2021-01-25 16:56:24 ugh. i messed up the rebase 2021-01-25 16:56:59 im fixing it 2021-01-25 17:26:03 someone please merge !17448 so I can pretend a few embarrassing bugs never happened :) 2021-01-25 17:27:05 any ABI changes? :) 2021-01-25 17:27:46 looks like it doesn't 2021-01-25 17:29:33 merged 2021-01-25 17:30:54 no, it's a pure bugfix release, no api changes at all 2021-01-25 17:30:57 thanks 2021-01-25 17:32:53 :) 2021-01-25 18:48:31 oof, gitlab is down 2021-01-25 18:52:00 I was just about to say the same thing :) 2021-01-25 18:52:26 Our monitoring warned me :) 2021-01-25 18:53:24 If only the monitoring could fix it too! ;) 2021-01-25 18:56:16 seems like network issues 2021-01-25 18:58:41 https://status.linode.com/incidents/dm9mc14kv2t4 2021-01-25 18:58:44 yup 2021-01-25 19:01:06 While we've all got nothing to do, is the CI / build stuff available for me to run locally? 2021-01-25 19:01:21 Would be nice to know I've got dependency issues before submitting a MR and looking like a fool :) 2021-01-25 19:02:10 Let me guess, I can find it on gitlab? :) 2021-01-25 19:05:23 πŸ˜‰ 2021-01-25 19:07:01 Is it the sort of thing I could run locally on a specific branch of my aports fork? 2021-01-25 19:07:50 The docker image is available 2021-01-25 19:08:14 but, it requires you to setup to run like it would locally 2021-01-25 19:08:18 I mean, on CI 2021-01-25 19:08:26 alpinelinux/alpine-gitlab-ci 2021-01-25 19:09:54 Yeah, I've found that on Google but obviously can't see the details at the moment. 2021-01-25 19:10:09 How much setup does it need? 2021-01-25 19:10:30 It needs some environment variables set 2021-01-25 19:10:53 Oh ok. That doesn't sound too onerous. 2021-01-25 19:11:14 I might have a look once gitlab returns. Would be a nice tool to add to the arsenal before submitting a MR. 2021-01-25 19:11:38 https://tpaste.us/E19R 2021-01-25 19:11:56 Not sure if there is a lot of difference with dabuild 2021-01-25 19:14:06 The main issue I head earlier was that dabuild has all the repositories listed, and I'd neglected to move a dependency from testing to community. 2021-01-25 19:14:25 dabuild worked, because it found the dependency in testing when building my package in community. 2021-01-25 19:15:59 Looks like 'set_repositories_for' will re-write /etc/apk/repositories appropriately. 2021-01-25 19:16:19 yes 2021-01-25 19:16:29 that's what I was talking about earlier 2021-01-25 19:17:01 Cool. So as long as I can duplicate that behaviour it would do what I want hopefully. 2021-01-25 20:04:47 gitlab is back (for now) 2021-01-25 20:44:24 ikke: Where do I find 'setup.sh' in https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci ? 2021-01-25 20:47:00 I guess I could just pull the container image from Docker hub. 2021-01-25 21:04:05 Ok, making some progress. What should the variable 'CI_MERGE_REQUEST_PROJECT_URL' be ikke? 2021-01-25 21:14:39 Doesn't look like my 'environment' is set up correctly. What should the filesystem look like when I run the docker image? Should I be in the directory that contains my changes? 2021-01-25 21:15:29 Looks like I need to see the docker invocation to see what filesystems are passed through. 2021-01-25 22:28:13 Hello71, it seems the latest xf86-video-modesetting release is 6+ years old. am i missing something, or how it could it properly support latest GPUs ? 2021-01-25 22:30:52 oh, tracing back all the git mirrors to gitlab.fdo.org i found this "modesetting driver development history; driver is now included with xorg/xserver" 2021-01-25 22:31:09 sh4rm4^bnc: it is dummy package 2021-01-25 22:33:04 /usr/lib/xorg/modules/drivers/modesetting_drv.so is owned by xorg-server-1.20.10-r0 2021-01-25 22:33:41 sigh. i just updated to xorg-server 1.18.4 two days ago 2021-01-25 22:34:49 i really hate messing around with these components, but the performance of the intel driver with sna disabled is awkward 2021-01-25 22:35:42 for me best working is intel driver with accel 'uxa' and disabled dri3 2021-01-25 22:36:03 at least dont have any screen tearing in window mode and in full screen 2021-01-25 22:36:29 MY-R: do you need any special settings to use the exa mode ? 2021-01-25 22:36:53 sh4rm4^bnc: nothing special, just file in /etc/X11/xorg.conf.d/ 2021-01-25 22:37:04 would you mind pasting that ? 2021-01-25 22:37:11 sure, one sec 2021-01-25 22:38:40 sh4rm4^bnc: https://tpaste.us/0Ea6 2021-01-25 22:39:17 thanks, gonna try that 2021-01-25 22:39:39 sh4rm4^bnc: but all depends from your igpu 2021-01-25 22:39:55 it's 915 from 2018 era 2021-01-25 22:40:26 so is basically very new :) 2021-01-25 22:40:35 and yours ? 2021-01-25 22:40:42 mine is from haswell hd 4600 2021-01-25 22:40:57 that's older than, i suppose ? 2021-01-25 22:41:01 ye 2021-01-25 22:42:16 rebooting X... 2021-01-25 22:42:18 but modesetting didnt work great, I had screen tearing in firefox videos then switched to intel and was something else, that is why changed to uxa and still wasnt perfect, some weird lags and then found that disabling dri3 can help aaaand helped... annoying 2021-01-25 22:42:45 does dri3 need to be disabled at build time or in that config ? 2021-01-25 22:43:04 dri "2" option disabling dri3, by default dri3 is turned on 2021-01-25 22:43:24 (another odd thing, since i updated xorg to 1.18.4 my mpv doesn't work anymore with -vo=xv) 2021-01-25 22:43:34 sh4rm4^bnc: and good 2021-01-25 22:43:43 you shouldnt use xv vo but "gpu" 2021-01-25 22:44:01 xv used to work super fast on my old laptop 2021-01-25 22:44:16 almost 0% cpu use, even with CPU at 800mhz 2021-01-25 22:44:39 gpu will use intel acceleration but for that need use vaapi or newer if your cpu support it 2021-01-25 22:45:40 with -vo=gpu as soon as i move the mouse over mpv window, it starts lagging 2021-01-25 22:45:46 you can use "vaapi/media driver" only too then wont touch your cpu too but with vo=gpu it will use just little cpu 2021-01-25 22:46:01 sh4rm4^bnc: then you need install vaapi/media driver stuff to suport it 2021-01-25 22:46:18 is that some binary driver stuff? 2021-01-25 22:46:53 sh4rm4^bnc: https://wiki.archlinux.org/index.php/Hardware_video_acceleration#Intel 2021-01-25 22:47:20 sh4rm4^bnc: https://01.org/linuxmedia/vaapi 2021-01-25 22:48:27 sh4rm4^bnc: if it would be binary then wouldnt work in Alpine because of musl I guess :) 2021-01-25 22:49:08 hurr. this stuff needs to built into Xorg or ffmpeg or how does it kick in? 2021-01-25 22:50:51 it working in Alpine, just need install packages 2021-01-25 22:51:07 sh4rm4^bnc: go to #alpine-linux lets not spam dev channel 2021-01-25 22:51:20 i'm doing my own distro sabotage, so i need some bg info :) 2021-01-25 22:52:04 anyway i'm gonna restart X to try your uxa settings... 2021-01-25 22:52:41 sabotage has that awesome theme song 2021-01-25 22:52:54 I love an OS with a theme song 2021-01-25 22:55:37 sh4rm4^bnc: if you have broadwell cpu or newer then need "intel-media-driver" 2021-01-25 22:55:49 sh4rm4^bnc: with older is probably enough to install "mesa-dri-intel" and "libva-utils" and check with "vainfo" if working 2021-01-25 23:00:32 uxa settings seem to work, browser appears slightly more responsive 2021-01-25 23:01:28 for example on this page scrolling with the mouse is still very laggy https://gta.fandom.com/wiki/Civil_Asset_Forfeiture_Impound#Car_List_3 2021-01-25 23:02:09 sh4rm4^bnc: firefox? 2021-01-25 23:02:16 palemoon 2021-01-25 23:02:48 while using the sna driver (which crashed the whole sys every few minutes) scolling around was a lot quicker 2021-01-25 23:04:54 sh4rm4^bnc: did you try with "layers.acceleration.force-enabled = true" in "about:config" and restart browser 2021-01-25 23:06:50 hey wow, that makes a huge difference 2021-01-25 23:06:57 ofc 2021-01-25 23:07:07 do you have a solution for any problem ? :) 2021-01-25 23:07:18 but I think latest firefox got it already enabled by default 2021-01-25 23:07:54 the option is called slightly different in palemoon (just force) but it was disabled 2021-01-25 23:07:59 forcing layers working fine but if wanna fire up gpu/igpu then enabling webrender doing best job but accelerating layers only is fine enough 2021-01-25 23:09:38 and layers are safer, webrender was abble to crash from time to time but ye, acceleration stuff is from what I start when installing any distro and windows 2021-01-25 23:10:07 cool, this is really helpful. thanks! 2021-01-25 23:10:24 gonna try the intel vaapi stuff when mpv lag annoys me enough 2021-01-25 23:10:30 sh4rm4^bnc: on Arch wiki can find some stuff from what can start 2021-01-25 23:11:05 optimally i'd just find out why -vo=xv no longer works and get it re-enabled... 2021-01-25 23:11:42 mpv with "gpu" and working acceleration should working great especially on newer cpu's 2021-01-25 23:12:44 i see. kinda logical if they build mpeg accel stuff into the GPU. 2021-01-25 23:13:27 yep 2021-01-25 23:14:07 need try everything to find golden solution 2021-01-25 23:15:51 i was actually about to start debugging the SNA driver to find out where the memory corruption comes from, eventually spending days... 2021-01-25 23:16:02 sh4rm4^bnc: install "libva-utils" and use "vainfo" command to check if video decoding working 2021-01-25 23:16:25 I didnt have luck with sna too 2021-01-25 23:17:55 the firefox acceleration option fix is more than sufficient, so no need to dig into the messy driver anymore 2021-01-25 23:19:06 glad I could help you, I know how annoying it can be when things working like on 15 years old computer 2021-01-25 23:20:33 indeed, the performance of the browser was equivalent to my 10 year old PC which i shelved last week 2021-01-25 23:23:16 sh4rm4^bnc: oh that package is for older "libva-intel-driver" and that is for broadwell+ cpus "intel-media-driver" 2021-01-25 23:23:41 to have vaapi support in mpv/firefox etc 2021-01-25 23:25:00 my cpu seems to be name kaby lake 2021-01-25 23:27:42 sh4rm4^bnc: then install intel-media-driver 2021-01-25 23:28:27 restart xorg and check what got in "vainfo" 2021-01-25 23:28:55 hmm, looks like "layers.acceleration.force-enabled = true" also helps with panfrost driver 2021-01-25 23:37:49 :] 2021-01-25 23:39:58 so I can use panfrost by default now, except st is more lags, but will see 2021-01-25 23:40:06 hmm.. i'll leave that va stuff for another, there's a sufficient amount of dependencies that this will take a couple hour to steal and integrate the recipes into my distro 2021-01-25 23:40:12 *another day 2021-01-26 00:41:33 xv is very obsolete 2021-01-26 00:42:02 most likely why xv appears faster is because it's producing a vastly inferior result 2021-01-26 00:42:16 bilinear scaling etc 2021-01-26 00:44:39 i really don't mind that - i only watch documentaries and that in 640x400 2021-01-26 00:58:40 what would you prefer over bilinear? 2021-01-26 01:05:53 hm... actually bilinear is still the default with gpu without other options. --profile=gpu-hq --sclae=ewa_lanczossharp is recommended by mpv 2021-01-26 01:06:15 gpu-hq sets --scale=spline36 which is rated as "Mid quality and speed" by the manual 2021-01-26 01:06:28 s/sclae/scale/ 2021-01-26 01:06:29 Hello71 meant to say: hm... actually bilinear is still the default with gpu without other options. --profile=gpu-hq --scale=ewa_lanczossharp is recommended by mpv 2021-01-26 01:08:03 the mpv manual also says that "xv [...] is the most compatible VO on X, but may be low-quality, and has issues with OSD and subtitle display." and that "This driver is for compatibility with old systems." 2021-01-26 01:10:08 if your gpu is newer than 2010 then playing 640x480 video should be entirely fast enough with vo=gpu and no hwdec 2021-01-26 01:10:40 ewa_lanczossharp will kill that igpu 2021-01-26 01:10:58 ah, i wasn't clear. for that last part i meant "with the defaults" 2021-01-26 01:11:33 but if you watch low resolution stuff then can think about better downscaling setting 2021-01-26 01:11:46 downscaling? 2021-01-26 01:12:09 ye 2021-01-26 01:12:12 does anyone actually use mpv with monitors outputting less than 640x480? 2021-01-26 01:12:23 think you are confused about direction 2021-01-26 01:12:58 wait, ye 2021-01-26 01:13:43 upscaling is for low resolution videos on high resolution screen 2021-01-26 01:14:01 right? or I just drank too much coffee.... 2021-01-26 01:18:22 yeah so scale=spline36 will make videos just a little sharper without loosing performance, just checked it in my mpv config 2021-01-26 01:43:40 hello71, bilinear is default because it's the only reasonable one :) 2021-01-26 01:49:53 many gamers like those fancy hq2x etc scalers e.g. shipped in dosbox 2021-01-26 01:50:38 yeah but they dont work on video 2021-01-26 01:50:44 only on pixel art 2021-01-26 01:58:26 the manual says that bilinear is the default for backwards compatibility only 2021-01-26 01:59:16 i.e. some computers are too shit to do anything good 2021-01-26 01:59:42 well that's wrong. the "good" ones are just shit :) 2021-01-26 02:00:56 also movies != videos etc 2021-01-26 02:02:54 no. the best scaler is the one that comes closest to the original signal, before sampling (nyquist etc). the definition of "closest" is somewhat subjective but it's not "whichever one is blurriest" 2021-01-26 02:04:32 that's not really a well-defined metric 2021-01-26 02:05:59 frequency-domain stuff on video isn't really sound to reason from because signals aren't band limited, at least not anywhere near the resolution you sample at 2021-01-26 02:06:14 they have what are essentially sharp discontinuities 2021-01-26 02:26:16 right, but that only says that you can't perfectly reconstruct the original signal 2021-01-26 02:26:35 but there's still a right answer 2021-01-26 02:27:44 and image and video processing regularly works in the frequency domain 2021-01-26 02:28:08 as an old example, jpeg dct 2021-01-26 02:28:46 it works decently as a form for efficient approximation, especially if you can represent the error well too 2021-01-26 02:38:44 but re:scaling, it's trivial that any filter with negative taps will do wrong things 2021-01-26 07:22:42 Hi there. I am trying to setup a Dell server here with Alpine Linux + fakeraid + LVM + LUKS2, with an encrypted /boot partition. From the install guide, there is this statement: "If using at least Alpine v3.11 and GRUB2 with encrypted /boot, the following should be used instead (because GRUB2 does not yet support LUKS2 containers):". So is GRUB2 officially supported now, for encrypted /boot? 2021-01-26 07:59:44 50c2367aa4d added an options= overriding the previous options= 2021-01-26 08:00:13 50c2367aa4df5edf1cc098bd1cccd58b16bb1af3 2021-01-26 08:19:52 ncopa: ping, I mentioned you in some abuild MRs that I think are ready for final-review and merge 2021-01-26 08:54:55 morning 2021-01-26 08:55:05 I'll have a look at it soon(ish) 2021-01-26 09:05:20 morning, thanks 2021-01-26 09:05:55 If we can get a new release would be great because apkbuild-pypi has been substantially improved 2021-01-26 09:09:31 about python3.9, any plans for fixing the triplet ? 2021-01-26 09:14:26 im working on alpine 3.13.1. i doubt i will have time for abuild release today. will try get it done later this week 2021-01-26 09:14:59 i'd like to discuss how to do the python 3.9 with dalias. didnt have time to follow that up yesterday sorry 2021-01-26 09:16:26 we should investigate if we need to make changes in our python build to be able to support precompiled python wheels with musl 2021-01-26 09:16:36 just made MR for dnsmasq upgrade 2.84, there are some bugfix, should that be backported to 3.13.1? 2021-01-26 09:16:43 sure 2021-01-26 09:16:47 ok 2021-01-26 09:18:50 i had a look at the python wheels yesterday but didnt come to any conclusion 2021-01-26 09:19:31 the whole thing seems a bit messy, and it seems like it is convenient for python community to simply ignore musl 2021-01-26 09:23:31 heh 2021-01-26 09:37:49 ikke: do you have tim to have a look at #12325 now? 2021-01-26 09:53:20 ncopa: sadly no 2021-01-26 09:53:49 ok. im investigating myself then 2021-01-26 09:54:00 i'd like to reproduce the problem in a vm if possible 2021-01-26 09:54:21 looks like there are 4 disks in the vg0 2021-01-26 09:55:24 It seems somewhat hardware related, though not sure 2021-01-26 09:55:59 i think what happens is that vgchange is called from nlplug-findfs before all disks are available 2021-01-26 09:56:18 that should be reproducible in a vm 2021-01-26 09:56:53 I don't see vg_change called at all 2021-01-26 09:57:18 I should've included a bit more logs 2021-01-26 10:26:33 Looks like my latest MR has been merged. Didn't see any response from the maintainer of py3-arrow though. 2021-01-26 10:26:44 !17437 2021-01-26 10:38:36 Looks like the build has failed on all architectures though. Looks like the git checkout failed. 2021-01-26 10:40:47 adhawkins: don't see it failed, do you have log url 2021-01-26 10:41:21 https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/305110 2021-01-26 10:41:42 hmm, ppc64le builder is stuck at testing/bpytop 1.0.60-r0 2021-01-26 10:41:47 At the top of the merge request, it says the build and lint both failed. Build looks to have failed on all architectures. 2021-01-26 10:41:57 it was already merged 2021-01-26 10:42:10 don't worry about it 2021-01-26 10:42:10 adhawkins: this is not builders 2021-01-26 10:42:23 the builders are here: https://build.alpinelinux.org/ 2021-01-26 10:42:27 and on #alpine-commits 2021-01-26 10:42:40 yes, #alpine-commits show these passed 2021-01-26 10:42:48 Ah, apologies. Wrong terminology. 2021-01-26 10:43:03 I saw the messages in alpine-commits, which was why I went back to look at the MR and found these failures. 2021-01-26 10:43:11 all looks good, no worries 2021-01-26 10:43:45 Ok. This still shows it in testing. https://pkgs.alpinelinux.org/packages?name=&branch=edge&arch=x86_64&maintainer=Andy+Hawkins 2021-01-26 10:44:24 need some time to synchronize all things 2021-01-26 10:44:44 Thought that would be the case. Thanks for my continued education maxice8 and mps :) 2021-01-26 10:48:10 ncopa: (yes, you are busy but who is not) I think to merge !16940 and add fixes later, to not wait too long for these changes 2021-01-26 10:50:02 I need to clean local branches to work further on cross-embedded tools, they are needed for building 'boot loader' for apple M1 2021-01-26 10:50:30 I would like to run alpine RSN on this machine 2021-01-26 10:50:55 (at least to try) 2021-01-26 11:26:10 ncopa: I have some time now 2021-01-26 11:32:08 rebooted usa7 with 5.10 kernel 2021-01-26 11:43:19 ncopa: interestingly, now when I run nlplug-findfs manually, it no longer seems to discover the lvm volumes 2021-01-26 12:04:21 try running it again 2021-01-26 12:04:41 did you try the other things i suggested? 2021-01-26 12:07:27 Hello71: not yet 2021-01-26 12:07:39 But I forgot to provide the rootfs 2021-01-26 12:07:46 Hello71: check https://gitlab.alpinelinux.org/alpine/aports/-/issues/12325#note_138465 2021-01-26 12:25:15 Hello71: I did not have a lot of time so I could not try a lot of things, just wanted to get more logging first 2021-01-26 12:25:19 - 2021-01-26 12:25:21 ok 2021-01-26 12:26:06 The issue contains logging with quiet removed and debug_init=1 2021-01-26 12:26:14 I'm not sure what's going on here, but your ahci enumeration is quite slow. probably that is a factor 2021-01-26 12:30:35 maybe nlplug-findfs is losing events? 2021-01-26 12:32:41 https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/nlplug-findfs.c#L421 2021-01-26 12:32:58 512/16=32 2021-01-26 12:34:00 32 events? 2021-01-26 12:35:26 apparently 2021-01-26 12:35:52 https://git.busybox.net/busybox/tree/util-linux/mdev.c#n1154 says that's way too small 2021-01-26 12:39:01 but it also says that kernel should set ENOBUFS in that case which we don't seem to get 2021-01-26 12:39:29 maybe because we are using recvmsg? 2021-01-26 12:39:40 doesn't add up 2021-01-26 12:42:11 could be worth increasing it 2021-01-26 12:52:02 Yeah 2021-01-26 12:58:03 Anyone familiar with how the CI stuff works help me running a similar build locally? I've got the Docker container but can't work out how to set it up to build against a local tree or specific branch. 2021-01-26 13:04:15 I have time later today 2021-01-26 13:06:55 That'd be great ikke, thanks. 2021-01-26 13:11:55 Just thought I'd say I now have a Docker build based on Alpine that installs emborg from the 'community' tree. Thanks to everyone who helped me get this far. I'll do my best to keep on top of the packages and keep them updated. 2021-01-26 13:44:23 adhawkins: not sure if you are aware of https://repology.org/repository/alpine_edge you can search for packages you maintain by your email address and it makes it easier to know when to update them 2021-01-26 13:45:19 Oooh, that's useful timlegge. I've just been subscribing to their github repos. Will take a look at that site. 2021-01-26 13:46:29 That does rely on other projects updating it first 2021-01-26 13:48:29 hmm. I guess in my case most of the packages are perl so they are updated on CPAN first - python would likely be similar if it is released on PYPI but I guess that is an issue I never thought of... 2021-01-26 13:51:23 yeah, there are also some wiki like projects that are fairly quick for most projects 2021-01-26 13:52:41 They have per maintainer RSS feed 2021-01-26 13:55:29 It looks like it might not have 'matched up' a couple of my packages, as it has no 'latest' version listed for them. 2021-01-26 13:55:37 Pretty sure they're all on PyPi 2021-01-26 13:56:07 Interestingly. they both have a '-' in their names. Think upstream uses an '_'. Should I have matched that? 2021-01-26 14:05:23 The two packages are python.quantiphy-eval and python.rkm-codes 2021-01-26 14:05:59 These are https://pypi.org/project/quantiphy-eval/ and https://pypi.org/project/rkm-codes/ respectively 2021-01-26 14:06:13 Looking at them, they do use a '-' after all... 2021-01-26 14:08:18 Repology has rules to match package names to upstream names 2021-01-26 14:08:37 There is a repo on github that contains those rules 2021-01-26 14:10:49 Ah ok. I'll take a look. 2021-01-26 14:12:11 There doesn't appear to be any other mentions of 'quantiphy' on there to match up to (for the quantiphy-eval package) 2021-01-26 14:12:37 Similarly the rkm codes one. 2021-01-26 14:14:53 I've submitted an issue on there, will see what happens. 2021-01-26 14:17:18 Note that there are also generic rules, so specific packages do not necessarily be mentioned 2021-01-26 14:18:42 But if I search repology.org for 'quantiphy' or 'rkm' it doesn't bring up any other versions of the package as far as I can see. 2021-01-26 14:18:50 So it's as if it hasn't even found them on PyPi. 2021-01-26 14:19:39 Or you are the first one to package it 2021-01-26 14:19:45 They're on PyPi 2021-01-26 14:19:54 Repology says it indexes PyPi too. 2021-01-26 14:19:59 Hmm 2021-01-26 14:21:18 python:quantiphy 2021-01-26 14:22:51 Yes, but there's also python:quantiphy-eval (they're different packages) 2021-01-26 14:22:57 It's matched up the first one, but not the second. 2021-01-26 14:23:22 https://pypi.org/project/quantiphy/ 2021-01-26 14:23:31 https://pypi.org/project/quantiphy-eval/0.1.0/ 2021-01-26 14:32:00 Guest69607: version of GRUB2 in Alpine is 2.04 (from July 2019). There has been no upstream release of GRUB2 since then and so unfortunately there is currently no support for LUKS2 in Alpine's GRUB2. As upstream only appear to do even-numbered releases (e.g. there was no GRUB 2.01 release) then it will appear in GRUB 2.06 (likely April/May 2021). Current GRUB2 in Alpine does have encrypted boot support so you can use that with LUKS1 2021-01-26 15:24:38 Hello all! I solved battery discharging value by setting max CPU freq limit. 2021-01-26 15:25:30 maybe it helps somebody: sudo echo 700000 > /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq 2021-01-26 15:25:47 It must be done for all cores 2021-01-26 15:25:55 ozzz: are you on intended channel 2021-01-26 15:26:04 sorry.... 2021-01-26 15:30:52 ozzz: ofcourse, thottling your CPU will reduce battery usage :) 2021-01-26 15:31:14 You might also set a specific govenor to achieve the same 2021-01-26 15:32:47 especially 'printf 0 > /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq' :) 2021-01-26 15:33:09 mps: what that actually do something? 2021-01-26 15:33:11 zero ) Is it possible anyway? 2021-01-26 15:33:53 you people lost sense of humor ;) 2021-01-26 15:34:21 mps: No, I found it funny, just wondering what it would even do 2021-01-26 15:34:26 ikke: I just left it working, until whole alpine repo won't be recompiled 2021-01-26 15:34:37 sorry guys, I turned it into gentoo :) 2021-01-26 15:34:38 ikke: no '0' is possible 2021-01-26 15:36:16 cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_available_frequencies, will tell possible ones 2021-01-26 15:36:32 cpu3 is cpuX 2021-01-26 15:37:50 with 1300mgz it sucks out a life from battery 2021-01-26 15:38:55 cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors, and select one which will be good for use case 2021-01-26 15:39:30 printf it to /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor 2021-01-26 15:40:05 ondemand is what most 'people on battery' likes 2021-01-26 15:41:00 mps: great! Thanks! 2021-01-26 15:41:51 ozzz: np 2021-01-26 15:43:59 also, on different kernel builds not all governors enabled by default, usually they are in modules which needs to be explicitly loaded (modprobe) 2021-01-26 15:52:42 mps: sure. I enabled it. It was fun to setup/compile. Frontswap helped a lot, tablet has only 1gb of ram. 2021-01-26 15:53:42 ozzz: build on tablet, you are brave 2021-01-26 15:54:46 :) seems yes. /var/cache /var/tmp on NBD, tmpfs for /tmp, swap over nbd 2021-01-26 15:55:25 I hope compilation wont kill ecc flash 2021-01-26 15:57:03 but sometimes I build some things on arm SBCs with FS on mmc and 1GB RAM 2021-01-26 15:58:52 uh, 'Job's log exceeded limit of 104857600 bytes.' on CI. will it pass on builders? 2021-01-26 16:52:35 adhawkins: ping 2021-01-26 16:53:31 Here ikke. 2021-01-26 16:54:22 ok, so the main idea behind how that image works is that it detects what it needs to build by comparing the current branch against a target branch 2021-01-26 16:54:42 I get that. What I couldn't work out was what I needed to pass into the container to get it to run. 2021-01-26 16:54:52 I assume I need to mount a git checkout, and then run the command. 2021-01-26 16:54:57 you run the build.sh script 2021-01-26 16:55:35 Yes, but presumably I need to have mounted the git repo somewhere for it to find it? 2021-01-26 16:55:44 This is as far as I got: docker run -e CI_DEBUG_BUILD=1 -e CI_PROJECT_DIR=/home/andy/alpine-packaging/aports/emborg/ -e CI_MERGE_REQUEST_TARGET_BRANCH_NAME=master -e CI_MERGE_REQUEST_PROJECT_URL=origin -v /home/andy:/home/andy alpinelinux/alpine-gitlab-ci:latest-x86_64 /usr/local/bin/build.sh 2021-01-26 16:56:04 adhawkins: it expects the repo to be PWD 2021-01-26 16:56:17 so add -w /home/andy 2021-01-26 16:56:29 What does -w do? 2021-01-26 16:56:41 set the working dir 2021-01-26 16:56:48 the CI_PROJECT_DIR needs to be the root of the repo 2021-01-26 16:56:59 you cannot specify just a single package to build 2021-01-26 16:57:18 That dir is the root of the repo I called the local dir 'emborg' as that's what I was working on. 2021-01-26 16:57:29 So -w should point to the top of the repo? 2021-01-26 16:57:37 yes 2021-01-26 16:58:23 Ok, it's doing something now. Looks like it's building perl? 2021-01-26 16:58:48 Do I need to make sure my repo's master matches edge/master? 2021-01-26 16:59:24 Should the -w include the 'community' part? Or should it point to the directory above? 2021-01-26 16:59:30 the directory above 2021-01-26 16:59:47 It expects the repository to be checked out at the branch with commits you want to build 2021-01-26 16:59:51 Ok, that's what I've done. It's building lots of stuff... 2021-01-26 17:00:06 it looks at git diff --name-only master...HEAD 2021-01-26 17:00:24 Let me make sure I've updated master to upstream. 2021-01-26 17:01:19 the build.sh script should make sure the target branch is up-to-date: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L141 2021-01-26 17:03:14 Where should CI_PROJECT_DIR point to? 2021-01-26 17:03:30 the same as you pass to -w 2021-01-26 17:03:46 (these variables normally come from gitlab) 2021-01-26 17:04:03 What about CI_MERGE_REQUEST_TARGET_BRANCH_NAME and CI_MERGE_REQUEST_PROJECT_URL 2021-01-26 17:04:09 I have them set to 'master' and 'origin'. 2021-01-26 17:04:15 Should work 2021-01-26 17:04:22 Should origin actually be upstream (the main alpine aports repo) 2021-01-26 17:04:27 origin is my fork of that. 2021-01-26 17:05:05 should be the main aports repo, otherwise, if your forks master is behind, it will build too much :) 2021-01-26 17:05:13 That could be why. 2021-01-26 17:05:31 so https://gitlab.alpinelinux.org/alpine/aports.git 2021-01-26 17:05:48 That's the 'upstream' remote in my local repo 2021-01-26 17:06:04 'origin' is 'https://gitlab.alpinelinux.org/adhawkins/aports.git' 2021-01-26 17:06:16 Ok, that looks to have worked! 2021-01-26 17:06:25 docker run -e CI_DEBUG_BUILD=1 -e CI_PROJECT_DIR=/home/andy/alpine-packaging/aports/emborg/ -e CI_MERGE_REQUEST_TARGET_BRANCH_NAME=master -e CI_MERGE_REQUEST_PROJECT_URL=upstream -v /home/andy:/home/andy -w /home/andy/alpine-packaging/aports/emborg/ alpinelinux/alpine-gitlab-ci:latest-x86_64 /usr/local/bin/build.sh 2021-01-26 17:08:20 Only errors I'm seeing are 'build package already in repo' which I guess is Ok. 2021-01-26 17:08:30 Let me move one of the dependencies back to testing and see if it picks that up. 2021-01-26 17:09:53 Ah, but that won't work because that dependency is actually available in community now... 2021-01-26 17:10:18 Oh well, looks like it's doing the 'correct' thing. Will give it a try if I need to make any changes. 2021-01-26 17:10:32 I was nearly there, just missing a couple of key pieces of information. Thanks again ikke. 2021-01-26 17:10:39 no problem 2021-01-26 17:22:10 Regarding repology.org, it seems the process that looks for 'interesting' modules on PyPy is run manually. The admin of repology has kicked that process off, and it's now picked up one of the two packages it knew nothing about. I assume the other will follow as the process continues. 2021-01-26 17:22:36 aha 2021-01-26 17:23:29 probably means you will not get usefull version update information for those packages 2021-01-26 17:27:47 No, I think it's just the first time it realises that package is of interest. I guess it doesn't monitor *every* package on PyPi, only those that are also packages elsewhere. 2021-01-26 17:28:00 The process that realises it's packaged elsewhere too is the one that had to be run manually I think. 2021-01-26 17:28:12 https://repology.org/projects/?maintainer=andy%40gently.org.uk&inrepo=alpine_edge&newest=1 2021-01-26 17:28:42 You can see it now knows that quantiphy-eval is used in 2 places (alpine and PyPi) but rkm-codes only 1 (currently alpine, but I assume as it indexes PyPi it will spot it there too) 2021-01-26 17:29:05 maybe it will start look for version bumps for those packages now 2021-01-26 17:29:52 That's what I'm hoping, yes. 2021-01-26 17:29:57 ncopa, what is the python issue? 2021-01-26 17:30:31 heh 2021-01-26 17:30:31 Right, time to prepare food. Thanks again for the assistance ikke. I'll probably disappear for a while now until I start getting notifications that there are new upstream versions of those packages. 2021-01-26 17:30:50 I at least have a docker container running emborg that just installs it from 'community' now. 2021-01-26 17:30:51 I don't know all the details, but it's about what triplet we should use for python, something to do with python wheel supporting musl 2021-01-26 17:31:10 python wheels* 2021-01-26 17:32:15 gcc -dumpmachine ? 2021-01-26 17:32:33 https://tpaste.us/QWal 2021-01-26 17:32:47 part of relevant chat log 2021-01-26 17:33:13 oh gosh it has also that old .guess 2021-01-26 17:33:30 "@ncopa β”‚ dalias: IIRC you once mentioned that it maybe was not a good idea to build python as x86_64-linux-gnu?" 2021-01-26 17:34:01 ah yes 2021-01-26 17:34:15 indeed that's going to make it pull glibc binaries 2021-01-26 17:34:27 from pip's binary repos 2021-01-26 17:36:21 right, but we'd still have to convince those projects to build for musl as well 2021-01-26 17:36:41 well, if they don't it should grab source and build from source 2021-01-26 17:36:53 which is much better than trying to pull glibc binaries 2021-01-26 17:36:55 I think that's part of the issue 2021-01-26 17:37:03 ? 2021-01-26 17:37:20 @ncopa β”‚ basically, i'm interested in fixing this: https://lih-verma.medium.com/alpine-makes-python-docker-builds-way-too-50-slower-and-images-double-2-larger-61d1d43cbc79 2021-01-26 17:40:22 sure, slower build time, but that "big image" is just because there is no proper purge 2021-01-26 17:41:36 yes, that's clear 2021-01-26 17:41:43 nowadays you'd even use build stages 2021-01-26 17:41:51 so that you can leave the mess behind in the build container 2021-01-26 17:41:57 *nod* 2021-01-26 17:42:53 https://github.com/pypa/manylinux/issues/37 2021-01-26 17:42:55 did docker not have build stages in Feb 5, 2020? 2021-01-26 17:43:18 Hello71: many python people don't know how to use 'em 2021-01-26 17:43:30 17:41 <@ikke> nowadays you'd even use build stages 2021-01-26 17:43:59 well, before you had to clean it up manually 2021-01-26 17:44:18 build wheels on first stage, install 'em on virtual env, start new stage, install python, copy the virtual env. 2021-01-26 17:44:33 artok: why not copy the wheels over? 2021-01-26 17:44:34 and cleaning was needed on same run command 2021-01-26 17:44:47 ikke: because that copy layer is saved on image 2021-01-26 17:44:54 Also didn't remove the build dependencies 2021-01-26 17:45:26 RUN apk add -t build-depends foo bar && ... && apk del build-depends 2021-01-26 17:45:29 hehe 2021-01-26 17:45:30 if you copy wheels, one layer has whl files that are then installed, even they're not needed after that 2021-01-26 17:45:48 right 2021-01-26 17:46:08 what is the way now? 2021-01-26 17:46:11 Β―\_(ツ)_/Β― 2021-01-26 17:47:43 that's why I tend to install thingies into /opt/service, then copy that over to last stage, do readelf recursively to check what libraries are needed, and install, and also purge any unneeded data (in single run command) 2021-01-26 17:49:10 last stage is then: FROM, COPY, RUN, ENTRYPOINT, CMD 2021-01-26 17:49:12 one of each 2021-01-26 17:52:02 sounds suspiciously like nix 2021-01-26 17:52:23 except nix is crazy enough to just grep for dependencies 2021-01-26 18:04:07 I'll run test for that same package 2021-01-26 18:18:29 it's just that /opt and nix share the common concept of using filesystem structure as a way to store metadata, and only FHS is small-brain enough as to... not do that 2021-01-26 18:22:15 I want to upstream `feedbackd-device-themes` to Alpine, normally new packages should go to `testing`, but `feedbackd` (in `community`) depends on it. Should I put it directly in `community` then? 2021-01-26 18:22:44 DylanVanAssche_: yes 2021-01-26 18:23:02 ikke: Ok, thanks! 2021-01-26 18:23:03 Please add that to the commit message 2021-01-26 18:23:40 can we grab sudo 1.9.5p2 for 3.13? Real nasty bug just got published as CVE-2021-3156 2021-01-26 18:24:03 c705: details? 2021-01-26 18:24:09 CVE-2021-3156 2021-01-26 18:24:58 https://www.sudo.ws/alerts/unescape_overflow.html 2021-01-26 18:25:01 https://www.openwall.com/lists/oss-security/2021/01/26/3 2021-01-26 18:26:16 ouch 2021-01-26 18:27:02 don't use sudo :/ 2021-01-26 18:27:21 I'm switching to doas 2021-01-26 18:27:37 why is it & in one place and ISSET in another anyways 2021-01-26 18:28:07 bugs happen. let's just patch it up and move on 2021-01-26 18:30:41 "Unfortunately, this initial technique failed [...] Fortunately, however, our brute-forcer produced dozens of unique Sudo crashes and gdb backtraces" -.- 2021-01-26 18:31:11 "...among these, three caught our attention, and" 2021-01-26 18:31:11 we eventually exploited all three. 2021-01-26 18:31:40 No backports either 2021-01-26 18:48:00 kdaudt are sudo 'p' safe to upgrade ? 2021-01-26 18:48:04 on backports 2021-01-26 18:48:22 I have no idea 2021-01-26 18:48:30 I would assume so 2021-01-26 18:48:32 patch releases 2021-01-26 18:49:22 It's listed under stable releases: https://www.sudo.ws/stable.html 2021-01-26 18:49:36 would be much more convenient if I could update 3.12 which is on 1.9.0 to 1.9.5p2 2021-01-26 18:50:10 yeah, I think it's stable 2021-01-26 18:50:26 don't see why that would be an issue. thought 3.12 was EOL anyways 2021-01-26 18:50:49 no 2021-01-26 18:50:54 not for secfixes 2021-01-26 18:51:00 when does it EOL? 2021-01-26 18:51:01 packages in main down to 3.10 are stil supported 2021-01-26 18:51:12 https://alpinelinux.org/releases/ 2021-01-26 18:51:17 i did not know that. good to know 2021-01-26 18:51:35 thanks 2021-01-26 18:53:01 is adding #12294 really necessary on the 1.9.5p1->1.9.5p2 transition ? 2021-01-26 18:53:10 I mean, secfixes 2021-01-26 18:53:23 It's not necessary 2021-01-26 18:53:33 but it would need to be added eventually 2021-01-26 18:53:49 it is already present in the secfixes of edge 2021-01-26 18:54:22 oh, I'm blind 2021-01-26 18:56:39 armv7 has a chronic problem with invalid distfiles 2021-01-26 18:56:52 maxice8: yes, it's a race condition between armv7 and armhf 2021-01-26 18:57:12 abuild-fetch should account for that, but there seems to be a bug 2021-01-26 18:57:23 (those 2 arches share the same distfiles mount) 2021-01-26 18:58:01 maxice8: oh, you're already backporting it 2021-01-26 18:58:17 feel free to do 3.11 and 3.10 :D 2021-01-26 18:59:10 thanks folks 2021-01-26 18:59:32 1.8.x is the -legacy- branch which means they don't get the secfixes 2021-01-26 19:04:20 fun times 2021-01-26 19:05:55 maybe it's time to demote sudo to community :-) 2021-01-26 19:06:06 DDEVAULT 2021-01-26 19:06:09 DOAS TIME TO STRIKE 2021-01-26 19:06:39 yes? 2021-01-26 19:06:39 nagios-plugins in main depends on it 2021-01-26 19:06:44 oh, yes 2021-01-26 19:06:47 doas good, sudo bad 2021-01-26 19:07:03 πŸ˜ŽπŸ‘οΈ 2021-01-26 19:07:06 getting rid of suid better 2021-01-26 19:07:11 service! 2021-01-26 19:07:57 just run everything as root, no privilege escalation possible 2021-01-26 19:08:15 that's galaxy brain level right there 2021-01-26 19:09:39 polkit is now mandatory 2021-01-26 19:12:00 uhg wtf 2021-01-26 19:12:10 on alpine?? 2021-01-26 19:12:17 i went to so much trouble to purge that shit last time 2021-01-26 19:12:21 mandatory for what? where? how? 2021-01-26 19:13:21 I guess that was a reaction to our sudo remarks? 2021-01-26 19:13:47 ah maybe 2021-01-26 19:14:01 don't do that to our fragile hearts, please 2021-01-26 19:14:07 :D 2021-01-26 19:14:25 Wait until April 1st 2021-01-26 19:14:30 maxice8: :) 2021-01-26 19:15:01 or use 'faketime' utility 2021-01-26 19:15:02 >_< 2021-01-26 19:15:25 i cant believe linux added time namespaces without actually enabling them to fake the time *sigh* 2021-01-26 19:15:41 (they can fake boot/monotonic time only, not real... *facepalm*) 2021-01-26 19:15:59 time namespaces... without the ability to fake time? 2021-01-26 19:16:37 apparently they only cared about using it for checkpoint/resume where monotonic absolutely must not go backwards 2021-01-26 19:17:01 ohey guize I'ma host a masquerade ball, but for security reasons everyone will have to wear a badge with their ID 2021-01-26 19:17:34 i think the problem is trying to support changing real time from inside 2021-01-26 19:17:36 or somesuch 2021-01-26 19:18:07 either it just should fail from inside, or it should adjust an offset from monotonic within its namespace 2021-01-26 19:18:15 ^ 2021-01-26 19:21:12 ikke: so no option to increase size of build log on CI? 2021-01-26 19:21:29 I have to adjust it on each runner 2021-01-26 19:21:37 uh 2021-01-26 19:22:09 I'll just merge and risk 2021-01-26 20:15:02 ddevault: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12357 2021-01-26 20:16:25 Oh, tbk already pinged you in the issue 2021-01-26 21:48:56 anyone know what is with ppc64le builder? it show building bpytop for more than a day 2021-01-26 21:50:17 hanging on a test apparently 2021-01-26 21:53:21 aha 2021-01-26 21:53:40 hmm, uninterruptable sleep 2021-01-26 21:54:21 strace keeps hanging as well 2021-01-26 21:55:59 I wrote this on the subject of doas vs sudo: https://paste.sr.ht/~sircmpwn/c6478737cfb459f84e22737f45cd0b6912e52055 2021-01-26 21:56:16 ACTION uninstalls sudo-doc again 2021-01-26 21:57:31 heh, despair 2021-01-26 22:01:09 mps: lxc is acting up 2021-01-26 22:01:27 kill switch :) 2021-01-26 22:03:35 just read on #asahi channel that the apple will release soon 11.2 of macos for M1, so would be nice to boot alpine on it soon, and cross-embedded needs to be finished for this 2021-01-26 22:07:35 "Stopping LXC containers ..." 2021-01-26 22:11:06 ok, had to force stop all containers 2021-01-26 22:11:13 hope it will stop in next morning at coffee time 2021-01-26 22:11:34 My patience ran out 2021-01-26 22:11:42 :) 2021-01-26 22:11:43 seems to be working again 2021-01-26 23:24:13 ddevault: i think it would be good to deprecate sudo in alpine 2021-01-26 23:32:00 move it to community and have doas as the one used where required by AL ? 2021-01-26 23:42:08 yes, i think so. but that should be discussed on list first. 2021-01-26 23:48:53 is there a "more official" doas port to linux? 2021-01-26 23:49:37 not so far as I'm aware, no 2021-01-26 23:52:05 does anything actually call sudo? 2021-01-26 23:52:32 abuild 2021-01-26 23:53:07 oh, not anymore 2021-01-27 00:30:59 <[[sroracle]]> only abuild-keygen -i calls sudo anymore and that is trivially replaceable 2021-01-27 06:50:26 it already has an environment variable that you can set to switch it 2021-01-27 06:51:13 nagios-plugins-openrc depends on sudo atm 2021-01-27 06:51:16 in main 2021-01-27 06:52:19 ncopa: apparently the ppc64le 3.7 builder was stuck for quite some time. Due to an lxc issue, I restarted all containers, and now it's building quite a lot 2021-01-27 07:51:56 whoops :) 2021-01-27 07:52:01 good morning 2021-01-27 07:53:50 πŸ‘‹ 2021-01-27 07:58:40 Morning 2021-01-27 08:08:21 Just had a thought. When one of my packages receives an upstream upgrade, should I do it straight in community, or should I first create a package in testing to prove it, before then moving that to community? 2021-01-27 08:10:07 You just update the existing package 2021-01-27 08:10:35 In community in this case 2021-01-27 08:44:14 Ok, understood. Was just worried that might potentially break it temporarily if someone updates. 2021-01-27 08:47:48 Updates should be tested locally and edge is all about testing updates 2021-01-27 09:10:17 Hello 2021-01-27 09:25:23 Hello, I just spent 6 months building a desktop env on alpine, I have some APKBUILD I'd like to contribute to the community, how would one get access to the staging repo? 2021-01-27 09:26:17 What is "the staging repo"? 2021-01-27 09:26:33 Normally you just submit the APKBUILD to the testing folder in the aports repo, master branch 2021-01-27 09:26:54 Ahh 2021-01-27 09:27:09 alex_y: 6 months and didn't read how alpine development work? 2021-01-27 09:28:14 alex_y: to contribute one makes merge requests against https://gitlab.alpinelinux.org/alpine/aports/ 2021-01-27 09:28:20 mps: sorry no, I just started today 2021-01-27 09:29:00 alex_y: ah, that is something else then 2021-01-27 09:29:58 alex_y: I would start from https://wiki.alpinelinux.org/wiki/Category_talk:Developer_Documentation 2021-01-27 09:34:04 mps: it's been a long deep dive into the desktop env, building and fine tuning the auto install script for ZFS root booting from a thin mbr/grubx64.efi into a luks lvmcrypt/cryptsetup, that alone took 2 months to fine tune 2021-01-27 09:35:53 kept waiting for true luks2 support from grub2 (current luks2 support is struct only, doesn't actually support the new encryptions), would have used something else but grub2 has the best zfs support 2021-01-27 09:36:02 alex_y: okay okay, I misunderstood you 2021-01-27 09:36:37 I have gone through hours and hours of pain to get a desktop installation installed and running smoothly, I'd like to save other people some time ;) 2021-01-27 09:36:44 mps: thank you sir 2021-01-27 09:37:03 :) 2021-01-27 09:39:00 alex_y: looks like your endeavor with settings all this will be good for any exhaustive article 2021-01-27 09:39:10 Some desktop apps stubbornly requires glibc and can only be launched from a docker container with another x11 wm inside, don't think those can make it into the repo anytime soon 2021-01-27 09:39:17 s/any/an/ 2021-01-27 09:39:18 mps meant to say: alex_y: looks like your endeavor with settings all this will be good for an exhaustive article 2021-01-27 09:39:56 mps: hmmm.. now that you've mentioned it 2021-01-27 09:43:21 On https://wiki.alpinelinux.org/wiki/Development_using_git:Developer_repositories 2021-01-27 09:43:36 It reads " Some git repositories of Alpine developer are hosted at git.alpinelinux.org. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, integration managers, can review and pull from this or can choose to reject if the changes needs more fixing." 2021-01-27 09:44:22 I was wondering what it means by a "developer aports repo" as a "staging area" 2021-01-27 09:44:24 alex_y: this docs are outdated, but some basic things there are still useful 2021-01-27 09:44:42 alpine moved development to gitlab 2021-01-27 09:44:56 i.e. gitlab.alpinelinux.org 2021-01-27 09:45:03 I was thinking along the lines of maybe I have to register an account somewhere and push the commit somewhere 2021-01-27 09:45:06 ahhhh 2021-01-27 09:45:22 btw the ZFS installation wiki needs massive update ;) 2021-01-27 09:45:51 wiki needs to be removed, imnsho 2021-01-27 09:46:00 ohh 2021-01-27 09:46:33 alpine needs better official docs, starting point is docs.alpinelinux.org 2021-01-27 09:47:04 but we are too small and not have much 'man power' to work on this 2021-01-27 09:48:16 (except we have a man power for useless babbles ;) ) 2021-01-27 09:48:40 I am interested to contribute towards the desktop area in a foreseable future, if the community accepts it :) 2021-01-27 09:48:58 been exciting to see a security focused linux WITHOUT systemd 2021-01-27 09:49:08 but ok, we are not commercially related to anything so we have freedom for this ;) 2021-01-27 09:49:09 that actually gained real traction (due to docker) 2021-01-27 09:49:54 ahh 2021-01-27 09:51:01 That 5mb alpine docker image is just beautiful ;) 2021-01-27 09:53:43 any(n)one knows why build.a.o is so heavy for browsers, my FF often segfaults when opening it 2021-01-27 09:55:07 Cogitri: Absolutely, would be testing locally. Mistakes do happen though sadly. 2021-01-27 09:57:12 mps: can not reproduce, build.a.o seems quite light even 2021-01-27 10:08:05 PureTryOut[m]2: yes, interesting that this happens for me only on one machine, two other works fine 2021-01-27 10:08:24 Maybe something wrong with that machine? 2021-01-27 10:09:20 strange is it doesn't crash on heavy pages like gitlab.a.o 2021-01-27 10:41:16 dalias> indeed that's going to make it pull glibc binaries 2021-01-27 10:41:16 dalias> from pip's binary repos 2021-01-27 10:41:39 dalias: do you have any suggestions or ideas how we prevent our python build to pull in glibc binaries? 2021-01-27 10:42:20 also, do you remember if there are any issue reported somewhere, with the details or how to reproduce? 2021-01-27 10:42:51 HΓ©lio folks 2021-01-27 10:44:09 My friends, I am New working Wittel Alpine and. Dockers 2021-01-27 10:44:36 But I am Senior Engineer in Network 2021-01-27 10:44:54 I have studied about Decker networks 2021-01-27 10:44:56 What's the procedure for packaging something where the upstream seems to have disappeared? The package is available in Debian. Is it Ok to use the debian 'orig' tarball as the source? 2021-01-27 10:45:28 adhawkins: yes, I use it for weex 2021-01-27 10:45:46 But I am Worth dificult in a single step 2021-01-27 10:45:58 Ok, I'll do that then, thanks mps 2021-01-27 10:48:26 I am creating a new network in Docker. When I create and attach a container The port exposed Not works properly. When I restart the Alpine all start works well 2021-01-27 10:49:15 I believe that is Not a correct behavior 2021-01-27 10:49:46 Someone could help me? 2021-01-27 10:50:49 Hi, I need to get a specific file from a gitlab pipeline. I can move the file to any destination I want. Is it possible to get the file then somehow? The runner fails and the log contains debug information. 2021-01-27 10:51:05 It's that pipeline: https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/305866 2021-01-27 10:56:46 Thermi: in one of these paths: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/.gitlab-ci.yml#L37 (relative to the root of the repo) 2021-01-27 10:57:45 Hi, what is the structure of apk public keys again? It's -.rsa.pub? 2021-01-27 10:57:55 Is the 'build' function inside the APKBUILD file executed from within $builddir? It doesn't seem to be for me. If I do a 'pwd' inside it, I'm in src/ not the directory below where the tarball is extracted. 2021-01-27 10:58:15 aparcar[m]: it doesn't matter that much, what matters is that the name is the same as the key you built it with 2021-01-27 10:58:23 https://paste.debian.net/1182916/ 2021-01-27 10:58:33 adhawkins: it is, but only when $builddir exists 2021-01-27 10:58:34 prepare|build|check|package 'cd' to $builddir before running themselves 2021-01-27 10:58:56 adhawkins: $builddir defaults to $srcdir/$pkgname-$pkgver 2021-01-27 10:59:02 https://termbin.com/a63g 2021-01-27 10:59:10 ikke: thank you 2021-01-27 10:59:27 Aha. _ and not '-'. 2021-01-27 10:59:28 Thanks ikke 2021-01-27 10:59:53 adhawkins: so set builddir as a global variable to the correct name 2021-01-27 11:00:32 builddir="$srcdir/$pkgname_$pkgver" 2021-01-27 11:00:44 Yep, just done that ikke. I thought I had, but I'd used an '_' instead of a '-' (the filename contains '_', but the tarball itself contains '-') 2021-01-27 11:01:01 oh, if it's the default, then you should leave it out even :) 2021-01-27 11:01:07 (our linting warns about that) 2021-01-27 11:01:20 Theres an 'orig' in there though too, so not quite default. 2021-01-27 11:01:28 ah, ok 2021-01-27 11:02:17 Hello, I am attempting to push an APKBUILD to the testing repo, I've added my ssh key to gitlab.alpinelinux.org 2021-01-27 11:02:49 alex_y: did you fork the aports project? 2021-01-27 11:02:52 I am unsure as to what to do next, I've tried ssh into git@git.alpinelinux.org, but resulted in "No more authentication methods to try" after trying the pub key 2021-01-27 11:03:07 ikke: no 2021-01-27 11:03:07 alex_y: you cannot push to repo, you have to create merge request in your forked repo 2021-01-27 11:03:14 ahhh 2021-01-27 11:03:17 but authentication should work first 2021-01-27 11:05:22 let me try again 2021-01-27 11:15:09 Anyone familiar with autoconf and the like help with these errors? https://termbin.com/gjna 2021-01-27 11:15:18 It's a very old package so it's possible that's why it doesn't build. 2021-01-27 11:16:42 adhawkins: it looks like a log of a successful apk add? 2021-01-27 11:17:21 Ah, I guess the control characters have truncated it somehow. 2021-01-27 11:17:30 Can abuild provide 'clean' output? 2021-01-27 11:17:39 ikke: what variable hols the path of the repo? Or is it just ~= 2021-01-27 11:17:42 *? 2021-01-27 11:17:49 -m by the look of it, let's try. 2021-01-27 11:18:44 Thermi: $CI_PROJECT_DIR 2021-01-27 11:18:50 Ty, need to export it? 2021-01-27 11:18:58 ikke: ^ 2021-01-27 11:19:02 No, it's provided by gitlab 2021-01-27 11:19:58 Ok, this one looks better: https://paste.debian.net/1182919/ 2021-01-27 11:22:34 adhawkins: no it doesn't :) 2021-01-27 11:22:41 it is html 2021-01-27 11:22:53 adhawkins: apk add tpaste 2021-01-27 11:22:59 Not here it's not mps 2021-01-27 11:23:17 and, echo 'hello' | tpaste 2021-01-27 11:23:28 https://paste.debian.net/plain/1182919 2021-01-27 11:23:38 huh 2021-01-27 11:23:43 I'm not building on an alpine box, I'm using a docker container. 2021-01-27 11:23:53 https://paste.debian.net/1182919/ is html 2021-01-27 11:23:58 adhawkins: I've had many battles with autoconf, one of them was solved by putting the autoconf version outside of a () :/ 2021-01-27 11:24:11 alex_y: I'm not sure what you mean? 2021-01-27 11:24:20 adhawkins: if you paste the APKBUILD I can have a go at it :) 2021-01-27 11:24:39 https://paste.debian.net/1182921/ 2021-01-27 11:24:46 ok 2021-01-27 11:26:43 It's a package that hasn't been touched since 2004, be warned! 2021-01-27 11:28:00 'cat something | curl tpaste.us -F tpaste=\<-' 2021-01-27 11:28:22 adhawkins: have you tried replacing: 2021-01-27 11:28:26 "autoreconf && ./configure --prefix=/usr && make" 2021-01-27 11:28:28 with: 2021-01-27 11:28:36 "./autogen.sh && ...." ? 2021-01-27 11:28:47 Tried that, similar errors. 2021-01-27 11:29:12 ok digging... 2021-01-27 11:30:23 adhawkins: when I tried that it worked, then it stopped on: 2021-01-27 11:30:27 /usr/bin/abuild: cd: line 2374: can't cd to /alpine/update/repo/custom/build/test/pkg/libunac-dev: No such file or directory 2021-01-27 11:31:09 maybe it doesn't have .h etc? 2021-01-27 11:31:43 yes, you can remove $pkgname-dev from subpackages in that case 2021-01-27 11:32:32 if i remove -dev and -doc from subpackages, then it stops at : 2021-01-27 11:32:35 /usr/bin/abuild: cd: line 2374: can't cd to /alpine/update/repo/custom/build/test/pkg/libunac: No such file or directory 2021-01-27 11:32:54 that means nothing is installed at all 2021-01-27 11:33:15 because package() is empty 2021-01-27 11:37:26 ikke: Seems like copying worked, but the artifacts section is empty. Does the file need to end with .apk or something? 2021-01-27 11:37:26 give this one a try 2021-01-27 11:37:31 https://paste.debian.net/1182923/ 2021-01-27 11:37:59 Thermi: no, it should upload everything in that directory 2021-01-27 11:38:11 ikke: Well, it doesn't. :| 2021-01-27 11:38:23 Oooh, thanks. Will have another try alex_y. 2021-01-27 11:38:31 no probs :) 2021-01-27 11:38:32 There will be .h, need to sort that 2021-01-27 11:38:34 There should be the file here: https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/305936 2021-01-27 11:38:48 adhawkins: With that it reaches >>> libunac: Signing the index... 2021-01-27 11:38:52 > cp /tmp/mdbx-test.db /tmp/mdbx-test.log.gz $CI_PROJECT_DIR/packages/ 2021-01-27 11:38:53 adhawkins: on my end 2021-01-27 11:39:02 I'm sure I tried that. Will rty again 2021-01-27 11:39:49 adhawkins: yeah the -doc and -dev requirement came back after the earlier issue was bypassed 2021-01-27 11:40:12 Thermi: https://docs.gitlab.com/ee/ci/yaml/#artifactswhen 2021-01-27 11:40:27 Let me try again alex_y. I'm sure I tried autogen.sh 2021-01-27 11:40:41 is BKPepe sometimes here? 2021-01-27 11:40:43 ikke: Yeah well, I need it when the check fails 2021-01-27 11:40:49 wrong channel sorry 2021-01-27 11:40:53 Otherwise this is an exercise in futility 2021-01-27 11:40:58 Thermi: understood, but that's the reason it does not work now 2021-01-27 11:41:08 ikke: Okay, ty, can you change it? 2021-01-27 11:41:13 adhawkins: after that it needs "make DESTDIR="$pkgdir" PREFIX=/usr install" in the package(){} 2021-01-27 11:42:34 Thermi: We've something planned that we could use for this 2021-01-27 11:47:07 Thermi: If you rebase your branch on the latest master, you can put your files in a logs/ dir 2021-01-27 11:47:23 ikke: Relative to $CI_...? 2021-01-27 11:47:29 yes 2021-01-27 11:47:47 And I then get the file when the pipeline fails?= 2021-01-27 11:47:50 *-= 2021-01-27 11:48:01 https://git.alpinelinux.org/aports/commit/?id=57a7f1223f71 2021-01-27 11:48:20 Ah, ty, will rebase 2021-01-27 11:49:07 I don't get it build with autogen.sh alex 2021-01-27 11:49:16 config.status: error: Something went wrong bootstrapping makefile fragments 2021-01-27 11:49:35 adhawkins: what happens when you try [ https://paste.debian.net/1182923/ 2021-01-27 11:49:54 adhawkins: it built the package on my end 2021-01-27 11:51:38 adhawkins: with a package containing the following: https://paste.debian.net/1182924/ 2021-01-27 11:54:46 alex_y: https://paste.debian.net/1182925/ 2021-01-27 11:56:34 Wonder if it's because I'm using dabuild? 2021-01-27 11:56:42 Trying on an actual alpine box 2021-01-27 11:58:50 Odd, that works. Ok, so what's going wrong with dabuild? 2021-01-27 11:59:42 hmm, not sure, autogen.sh looks vanilla also 2021-01-27 12:00:09 I've had build failed because it was in a different shell 2021-01-27 12:00:35 not sure if it applies here 2021-01-27 12:01:38 adhawkins: wonder what happens if you remove --gnu from automake inside autogen.sh 2021-01-27 12:02:14 Must be a missing build dependency I'm guessing. 2021-01-27 12:03:25 ls 2021-01-27 12:03:39 adhawkins: does it do anything if you add this line: 2021-01-27 12:03:42 sed -i 's/--gnu / /' $builddir/autogen.sh 2021-01-27 12:03:52 above the ./autogen.sh && line? 2021-01-27 12:04:24 Same error. 2021-01-27 12:04:33 damn 2021-01-27 12:04:45 Let me see what packages are installed on the alpine box. Must be one of those making it work I guess. 2021-01-27 12:04:51 Lunch time here. 2021-01-27 12:04:55 Back later :) 2021-01-27 12:05:06 enjoy :) 2021-01-27 12:48:18 Is there a command that will list all installed packages? 2021-01-27 12:48:44 `apk list -I` 2021-01-27 12:52:21 Thanks, will give that a go. 2021-01-27 13:04:27 Hmmm, nothing obvious. Any thoughts for candidates alex_y? 2021-01-27 13:05:12 This is the packages in the docker container build: https://termbin.com/7q0a 2021-01-27 13:05:22 And this on the 'real' machine: https://termbin.com/s0fp 2021-01-27 13:15:08 let's take a look 2021-01-27 13:16:51 Pasing '--disable-dependency-tracking' to configure gets past this error, but now I've getting: 2021-01-27 13:16:55 config.status: executing libtool commands 2021-01-27 13:16:55 make: /bin/sh: Operation not permitted 2021-01-27 13:16:55 make: *** [Makefile:688: config.h] Error 127 2021-01-27 13:17:33 That bit of the Makefile is: 2021-01-27 13:17:34 config.h: stamp-h1 2021-01-27 13:17:34 @test -f $@ || rm -f stamp-h1 2021-01-27 13:17:34 @test -f $@ || $(MAKE) $(AM_MAKEFLAGS) stamp-h1 2021-01-27 13:17:41 The first 'test' command is the referenced line number. 2021-01-27 13:17:59 ash / bash? 2021-01-27 13:18:07 upgrade libseccomp 2021-01-27 13:18:09 and docker 2021-01-27 13:19:04 adhawkins: the only interesting diff appear to be : atools-19.8.6-r0 x86_64 {atools} (MIT) [installed] 2021-01-27 13:19:55 Was that for me Hello71? The box I'm running this on is a Debian box. 2021-01-27 13:20:22 alex_y: That same package is installed on both I think? 2021-01-27 13:20:41 adhawkins: it's not on your docker list 2021-01-27 13:21:07 Let me try. 2021-01-27 13:21:15 yup 2021-01-27 13:23:40 Same error alex_y :( 2021-01-27 13:23:45 damn 2021-01-27 13:23:58 can you paste your docker file? 2021-01-27 13:24:03 I'll try it in docker as well 2021-01-27 13:24:09 I'm using dabuild. 2021-01-27 13:24:16 cd 2021-01-27 13:24:19 Whoops. 2021-01-27 13:25:23 alex_y: https://gitlab.alpinelinux.org/alpine/docker-abuild.git 2021-01-27 13:26:20 what happens if you also add this to the docker side? -> 2021-01-27 13:26:38 alpine-base-3.13.0-r0 x86_64 {alpine-base} (MIT) [installed] 2021-01-27 13:28:04 Same error with dependencies. 2021-01-27 13:28:07 ncopa: why does alpine 3.8/3.9 have libseccomp 2.4.2 but alpine 3.10 has 2.4.1? https://repology.org/project/libseccomp/versions 2021-01-27 13:28:42 If I add --disable-dependency-tracking to configure it gets past that but then fails at the 'executing libtool commands' phase. 2021-01-27 13:28:54 Can I force the build system to use bash instead of ash? 2021-01-27 13:29:06 Is that likely to be an issue? 2021-01-27 13:29:28 i had problem building outside ash in earlier days 2021-01-27 13:31:02 no longer had issues after the os was installed from scratch and doesn't have ash 2021-01-27 13:31:14 everything under bash 2021-01-27 13:31:29 adhawkins: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0#faccessat2 2021-01-27 13:31:51 adhawkins: I am not familiar with docker-abuild, how do I get to where you are at? 2021-01-27 13:32:09 alex_y: I just cloned the repo, ran 'make' and then put dabuild in my path. 2021-01-27 13:32:19 ahh 2021-01-27 13:32:24 Then to run it, you just run 'dabuild' instead of 'abuild' (using the same arguments) 2021-01-27 13:32:31 ok let me try 2021-01-27 13:33:35 Hello71: Ok. Is that likely to affect this particular case do you think? 2021-01-27 13:33:42 sigh 2021-01-27 13:34:09 what part of "requires" is not clear 2021-01-27 13:34:23 Ok, understood Hello71. 2021-01-27 13:35:02 I'll try running docker on my alpine host. 2021-01-27 13:36:00 note that 3.12 doesn't work 2021-01-27 13:36:11 gonna open an issue to backport 2.4.4 2021-01-27 13:37:52 actually wait it doesn't have the needed docker either 2021-01-27 13:37:59 I'm on 3.13 2021-01-27 13:38:50 Ok. That builds, thanks *so* much Hello71. 2021-01-27 13:39:08 Fails at the 'dev' part, but that's another issue. 2021-01-27 13:40:26 adhawkins: what params did you run dabuild with? -vxxxx? 2021-01-27 13:41:10 -rfKm 2021-01-27 13:41:21 But see above, it seems it's an issue with me using an older Docker. 2021-01-27 13:41:27 ahh 2021-01-27 13:41:30 If I run it in docker on Alpine it builds Ok. 2021-01-27 13:44:19 yup it built 2021-01-27 14:03:00 Hello71: looks like it is due to CVE-2019-9893 2021-01-27 14:03:05 9092d9ca814a141dbcee7a97070ff4bd93f78e10 2021-01-27 14:03:31 i realized that those old versions don't have new docker anyways 2021-01-27 14:03:57 upgrade from libseccomp 2.3 -> 2.4 2021-01-27 14:04:09 i'm not sure that was a good idea 2021-01-27 14:04:21 iirc it breaks ABI 2021-01-27 14:04:35 or introduces a performance regression 2021-01-27 14:05:29 the 3.10-stable probably already had libseccom 2.4 and was not upgraded 2021-01-27 14:07:07 meh 2021-01-27 14:14:18 Hello71: Just updated my Debian to docker 20.10.2 and getting the same issue. 2021-01-27 14:16:03 Looks like it doesn't have the appropriate seccomp support. 2021-01-27 14:20:46 Regarding the "arch" field in an APKBUILD; the wiki says that: 2021-01-27 14:20:46 arch 2021-01-27 14:20:46 Package architecture(s) to build for. Can be one of: x86, x86_64, arm7, armhf, aarch64, ppc64le, s390x, mips64, all, or noarch, where all means all architectures, and noarch means it's architecture-independent (e.g., a pure-python package). 2021-01-27 14:21:06 I assume it is actually wrong, it can be a combination of at least one of: [...] 2021-01-27 14:21:24 Question is if it's space seperated or any other character? 2021-01-27 14:21:31 Space separated 2021-01-27 14:21:32 isn't it an array 2021-01-27 14:21:39 wait 2021-01-27 14:21:46 too much arch :/ 2021-01-27 14:22:02 are you talking about this libseccomp issue? https://github.com/moby/buildkit/issues/1946 2021-01-27 14:22:54 Okay, ty. Can I use ! for negation? E.g. arch="all !ppc64le"? 2021-01-27 14:23:00 Yup that works 2021-01-27 14:23:11 Ty. Who wants to fix that part of the wiki for me? :P 2021-01-27 14:23:18 "Build for all arches except ppc64le" 2021-01-27 14:23:20 its a wiki ;) 2021-01-27 14:23:24 You can do it yourself? 2021-01-27 14:23:40 ncopa: No. I'm running dabuild on a debian host. At the 'executing libtool commands' of a configure, I get: 'make: /bin/sh: Operation not permitted make: *** [Makefile:688: config.h] Error 127' 2021-01-27 14:23:47 If I do the same using dabuild under alpine, it works fine. 2021-01-27 14:24:07 Hello71 says it's due to this: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0#faccessat2 2021-01-27 14:24:25 Which requires either an up-to-date libseccomp2 (which Debian doesn't have) or some modifications (which I'm not sure I know how to do!) 2021-01-27 14:25:04 PureTryOut[m]2: Ah, I assumed it was restricted to registered accounts of developers or something 2021-01-27 14:25:24 It wouldn't really be a proper wiki if that were the case πŸ˜‰ 2021-01-27 14:33:07 Hello71: Where do I put the 'default.json' file that I need to download? Or do I just provide a full path to it on the dockerd command line? 2021-01-27 14:33:24 anywhere 2021-01-27 14:35:13 " A brief description of the abuse rule which your action matched is: New users are not allowed to add ip addresses and phone numbers within 5 hrs of account creation" 2021-01-27 14:35:19 -.- 2021-01-27 14:35:39 The edit contains none of these 2021-01-27 14:37:45 It does not look at the edit text 2021-01-27 14:38:54 Ok, thanks Hello71. Now to work out how to do that with Debian's systemd :) 2021-01-27 14:39:37 ikke: Why does it then report that 2021-01-27 14:39:52 It looks at the entire page 2021-01-27 14:40:00 So if anything already exists, it would block it 2021-01-27 14:41:07 Thermi: you should be able to edit it now 2021-01-27 14:41:11 'should' 2021-01-27 14:49:11 Ok, think I've got it sorted now Hello71, thanks again for the assistance. 2021-01-27 14:51:19 Cogitri: gnome-podcasts has test failures 2021-01-27 14:54:25 Yikes, worked locally 2021-01-27 14:55:31 At work right now, could you disable the tests for the time being so I can take a look at it later? 2021-01-27 15:35:57 ddevault: what slightly depresses me is https://twitter.com/canadianbryan/status/1354256433798377475 2021-01-27 15:36:49 I don't use PAM, either, thank god 2021-01-27 15:37:11 <@ncopa> dalias: do you have any suggestions or ideas how we prevent our python build to pull in glibc binaries? 2021-01-27 15:37:21 by not calling it x86_64-linux-gnu (gnu means glibc) 2021-01-27 15:37:37 instead call it x86_64-linux-musl 2021-01-27 16:30:35 anyone good with POSIX shell? Trying to figure out the equivalent of this Bash logic: if [ ! "$NFS_VERSIONS" =~ [234]+ ]; then 2021-01-27 16:30:48 minimal: use case 2021-01-27 16:31:20 though, not sure if you can match only numbers 2021-01-27 16:31:26 shellcheck tells me its not valid POSIX - which is good, but its Wiki page on its error code doesn't give any pointers to a POSIX-compliant alternative 2021-01-27 16:32:00 posix sh only has wildcard matching 2021-01-27 16:32:05 ikke: have a variable might should contain only the numbers 2, 3, or 4, or combinations of those 2021-01-27 16:32:15 yes, I figured 2021-01-27 16:32:40 use case 2021-01-27 16:33:06 I don't think you can match on 1 ore more numbers with case 2021-01-27 16:33:17 s/ore/or/ 2021-01-27 16:33:17 ikke meant to say: I don't think you can match on 1 or more numbers with case 2021-01-27 16:34:04 I'm sure I could come up with a messy way to do it, from a quick online search couldn't see any "elegant" way to do it 2021-01-27 16:34:55 I can only think of grep -qx 2021-01-27 16:35:09 (or sed or awk) 2021-01-27 16:37:12 will play around with sed. Usually the shellcheck docs are good at pointing to drop-in Posix alternatives 2021-01-27 16:37:37 the fact that non are listed is already an indication that there is not a straight-forward alternative 2021-01-27 16:38:46 done in case 2021-01-27 16:38:54 ikke: that particular error code covers various Posix issues but that webpage doesn't mention the regex scenario at all, let alone give alternative 2021-01-27 16:39:14 http://ix.io/2Nu4 2021-01-27 16:40:16 maxice8: thanks. 2021-01-27 16:44:14 welcome 2021-01-27 16:57:01 i don't think that's even valid bash 2021-01-27 16:57:12 it needs to be [[ 2021-01-27 16:57:53 indeed 2021-01-27 17:00:02 Hello71: True, I have a bad habit of using "[" instead of "[[" for Bash (shellcheck usually keeps me right). In this case however I was writing something intended for sh/ash... 2021-01-27 17:01:36 abuild should be rewritten in perl 2021-01-27 17:02:20 no pls :P 2021-01-27 17:02:50 miniperl actually 2021-01-27 17:53:32 Who do I need to contact to get this MR going? 2021-01-27 17:53:32 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15863 2021-01-27 17:58:17 !15863 2021-01-27 17:59:28 various people raising issues with installing on RPIs... 2021-01-27 18:03:12 minimal: with libcec? The normal package doesn't work as RPis need some special API against which libcec needs to be compiled. 2021-01-27 18:03:33 minimal: nope, just installing on RPI in general 2021-01-27 18:04:34 minimal: Ah, well I use postmarketOS with Kodi on the RPi but I try to upstream my changes where possible. 2021-01-27 18:04:35 yes, people bought this bad SBCs 2021-01-27 18:05:40 I got it for free back in the day without knowing how much trouble there's with it ☹️ 2021-01-27 18:06:41 its partly a Alpine wiki/documentation issue 2021-01-27 18:06:41 fix for pmOS doesn't necessary needs to be in alpine 2021-01-27 18:07:34 Well, it's not a pmOS specific thing as it's for Kodi in Alpine actually. 2021-01-27 18:07:34 I just use the pmOS tools to install it on the RPi 2021-01-27 18:08:05 I don't have to say anything bad for pmOS, but pmOS is not alpine and alpine is not pmOS 2021-01-27 18:09:20 That's true πŸ™‚ I can keep it on pmOS only as well if that's preferred 2021-01-27 18:10:07 and please don't use these emojis, this is IRC 2021-01-27 18:10:33 mps: will keep it in mind 2021-01-27 18:10:48 DylanVanAssche_: thanks :) 2021-01-27 18:12:32 DylanVanAssche_: so, if the problem/bug related to alpine than it appreciate if you report it, and even better if you made MR (as you did) 2021-01-27 18:12:48 s/than/then/ 2021-01-27 18:12:48 mps meant to say: DylanVanAssche_: so, if the problem/bug related to alpine then it appreciate if you report it, and even better if you made MR (as you did) 2021-01-27 18:13:45 but keep in mind that alpine devs are usually busy and can't respond quickly 2021-01-27 18:14:43 about half of listed alpine devs are actually inactive 2021-01-27 18:32:30 mps: Alright. I didn't know that, I started with Alpine a couple of months ago. In general, I really like Alpine so I try to contribute where I can 2021-01-27 18:38:07 DylanVanAssche_: thanks for understanding 'state' of alpine project (huh, what a word) 2021-01-27 18:47:42 Hello, I am having problem with one of the steps on: https://wiki.alpinelinux.org/wiki/Creating_patches 2021-01-27 18:48:00 git clone git@gitlab.alpinelinux.org:$USER/$REPO.git results in "Permission denied" 2021-01-27 18:48:23 what is the full error and the invocation ? 2021-01-27 18:48:24 where $USER and $REPO is my nick and "aports" on gitlab 2021-01-27 18:49:00 I seem to have entered the wrong password, am I supposed to enter the same password as the one on gitlab? 2021-01-27 18:49:33 maxice8: Permission denied, please try again. 2021-01-27 18:49:34 git@gitlab.alpinelinux.org's password: 2021-01-27 18:50:32 ssh -Tvvvv git@gitlab.alpinelinux.org also failed 2021-01-27 18:50:48 I have added a SSH key 2021-01-27 18:51:02 i tried both the SSH key's password and gitlab's password, still couldn't login 2021-01-27 18:59:14 all works fine here. probably you put wrong username or uploaded wrong key 2021-01-27 18:59:27 or your key is world-readable or somesuch 2021-01-27 19:00:06 alex_y_If it's asking for the password for git@gitlab, sounds like it's not trying to use a key, or that key is being rejected. 2021-01-27 19:00:40 Perhaps try 'ssh -v git@gitlab.alpinelinux.org' and see if that gives any more info? 2021-01-27 19:00:51 I wouldn't expect you to get a shell, but it'll at least tell you if it authenticates 2021-01-27 19:02:10 in ~/.ssh/config I added "Host git.alpinelinux.org\n Preferredauthentications publickey \n IdentityFile ~/.ssh/pub_key" 2021-01-27 19:02:28 to force ssh to use the pub_key for all git.alpinelinux.org connections 2021-01-27 19:02:57 I don't think that's how it works. The 'host' bit is an alias, then there should be a line that gives the actual host name isn't there? 2021-01-27 19:03:17 Doesn't seem to be working, ssh -v shows logs like "id_rsa: No such file or directory" 2021-01-27 19:03:25 it's looking for the wrong keys 2021-01-27 19:03:58 See above regarding entries in config 2021-01-27 19:04:12 adhawkins: thanks, I'll try 2021-01-27 19:07:50 Ahh, "Host git.alpinelinux.org" should be "gitlab.alpinelinux.org" 2021-01-27 19:08:05 now getting other errors, working through 2021-01-27 19:09:24 pub in pub_key? 2021-01-27 19:09:58 priv_key? 2021-01-27 19:10:38 debug1: Server accepts key: /home/x/.ssh/test.pub ED25519 SHA256:QEi9S8bC+/Z5oydBgnXk53dRjIoTSB1Tpj52Y06xgu8 explicit 2021-01-27 19:10:41 debug3: sign_and_send_pubkey: ED25519 SHA256:QEi9S8bC+/Z5oydBgnXk53dRjIoTSB1Tpj52Y06xgu8 2021-01-27 19:10:44 debug3: sign_and_send_pubkey: signing using ssh-ed25519 SHA256:QEi9S8bC+/Z5oydBgnXk53dRjIoTSB1Tpj52Y06xgu8 2021-01-27 19:10:47 Load key "/home/x/.ssh/test.pub": invalid format 2021-01-27 19:10:52 mps: test.pub is the pubkey 2021-01-27 19:11:35 public key is what you put on remote, and use private key on your side to connect 2021-01-27 19:12:17 doh 2021-01-27 19:12:21 Ah yes. IdentityFile should point to the private key. 2021-01-27 19:12:38 "Welcome to GitLab" 2021-01-27 19:12:45 thank you all :) 2021-01-27 19:13:18 adhawkins: how did your dabuild go?:) 2021-01-27 19:13:24 mps: thank you 2021-01-27 19:13:49 Hello71: thank you :) 2021-01-27 19:16:03 heh, you give me idea to reverse keys ;) 2021-01-27 19:16:11 lol 2021-01-27 19:16:22 alex_y: All sorted now I think. Thanks a lot for your help. 2021-01-27 19:16:23 would be funny it works 2021-01-27 19:16:33 s/it/if/ 2021-01-27 19:16:34 mps meant to say: would be funny if works 2021-01-27 19:16:38 adhawkins: nice 2021-01-27 19:16:46 Reconfigured my docker as per the instructions pointed to by Hello71. 2021-01-27 19:17:21 dalias: looks like its not possible to set the triplet. Its detected from compiler defines https://github.com/python/cpython/blob/master/configure.ac#L714 2021-01-27 19:18:00 i suppose we should file a bug upstream, but I don't know the details or how to reproduce it 2021-01-27 19:21:57 uhg wtf 2021-01-27 19:22:03 after rebooting X doesn't support keyboard 2021-01-27 19:22:14 do you have udev running? 2021-01-27 19:22:15 did anything change in this area recently? 2021-01-27 19:22:59 i know udev is needed for input device hotplugging in xorg 2021-01-27 19:23:48 yes seems to be running 2021-01-27 19:24:01 xf86-input-keyboard was removed upstream at some point 2021-01-27 19:24:03 mice work 2021-01-27 19:24:36 is there a way to check which event device it is? 2021-01-27 19:24:46 do you have xf86-input-evdev installed? 2021-01-27 19:25:06 yes 2021-01-27 19:25:09 i wonder why we still have xf86-input-keyboard. isn't it broken? 2021-01-27 19:30:22 any other ideas to check? 2021-01-27 19:30:52 guess i'll upgrade xorg server to latest 2021-01-27 19:32:50 lovely now mouse doesnt work eithe 2021-01-27 19:34:57 dalias: are you in input group 2021-01-27 19:35:52 and xf86-input-libinput insted of xf86-input-evdev 2021-01-27 19:37:38 no, input group is new, uhg 2021-01-27 19:37:53 and no i dont have xf86-input-libinput only xf86-input-evdev 2021-01-27 19:38:12 after adding input group, mouse works but not kb 2021-01-27 19:38:28 dalias: only in X? 2021-01-27 19:38:50 right 2021-01-27 19:38:53 on console keyboard works fine 2021-01-27 19:39:10 but X insists on using silly /dev/input stuff rather than putting fd 0 in raw mode... 2021-01-27 19:39:43 I even don't have udev running but all works 2021-01-27 19:39:50 will adding xf86-input-libinput maybe fix it? 2021-01-27 19:40:00 maybe -evdev is just broken/bitrotted? 2021-01-27 19:40:13 dalias: actually 2021-01-27 19:41:08 ? 2021-01-27 19:41:48 dalias: actually it is somewhat outdated, libinput is now official 2021-01-27 19:42:07 s/now/for some time/ 2021-01-27 19:42:07 mps meant to say: dalias: actually it is somewhat outdated, libinput is for some time official 2021-01-27 19:44:37 could this be something with rootless? 2021-01-27 19:44:49 dalias: i guess you don't use media keys, or caps lock, or prtsc, or want to differentiate alt and esc, etc 2021-01-27 19:45:05 if mouse work then I think no 2021-01-27 19:45:39 I use rootless X for long time and no problems 2021-01-27 19:46:05 if you have strange keyboard maybe udev rules doesn't match it? but i think that should be reasonably synchronized with libinput 2021-01-27 19:46:22 hello71, all of that works with raw kb mode 2021-01-27 19:46:24 it gets scan codes 2021-01-27 19:46:44 i think udev rules are broken and don't find it 2021-01-27 19:46:54 there are tons of nodes in /dev/input 2021-01-27 19:46:59 but x only scans a few of them 2021-01-27 19:47:09 so idiotic that it uses udev rather than inotify on /dev/input 2021-01-27 19:47:33 where are the relevant udev rules? 2021-01-27 19:48:50 you need elogind to use rootless X 2021-01-27 19:48:51 ah, yes, i think that's what xf86-input-keyboard does 2021-01-27 19:49:07 MY-R: not if you just add user to input/video 2021-01-27 19:49:15 MY-R: no, I use it with startx 2021-01-27 19:49:39 uhg wtf 2021-01-27 19:49:41 mps: startx is orthogonal to elogind 2021-01-27 19:49:50 so something changed probably, last time I was trying to do it in Alpine it didnt work 2021-01-27 19:49:50 no i am not going to use elogind whatever that it 2021-01-27 19:50:03 but anyway it's not working if i startx as root either 2021-01-27 19:51:16 I mostly use 'slim' as DM, and sometimes startx 2021-01-27 19:52:12 no e/logind, no polkit, no consolekit 2021-01-27 19:53:29 well consolekit is obsolete and unmaintained anyways 2021-01-27 19:53:42 other ideas? 2021-01-27 19:53:54 send Xorg.0.log? 2021-01-27 19:53:57 dbus? 2021-01-27 19:54:32 though don't know why would dbus help, sorry 2021-01-27 19:56:16 elogind? 2021-01-27 19:56:59 http://ix.io/2NuW 2021-01-27 19:58:23 you don't have the correct graphics modules loaded 2021-01-27 19:58:37 and or firmware 2021-01-27 19:58:39 hm... not sure what's wrong exactly, but i guess your keyboard is not detected by udev rules 2021-01-27 19:59:05 graytshirt: it looks fine to me 2021-01-27 19:59:25 modesetting is recommended over intel, but it should still work, and i doubt it's related to keyboard issues 2021-01-27 20:00:25 graytshirt, why? 2021-01-27 20:00:48 that's unrelated to keyboard and it works fine. i'd rather use proper dedicated 2d accel than build 2d on top of 3d 2021-01-27 20:01:52 as Hello71 says for some unknown reason keyboard is not detected 2021-01-27 20:02:34 yeah looks like eudev is broken... 2021-01-27 20:02:52 in direct response to your "where are the rules" question, seems like it should be /lib/udev/rules.d 2021-01-27 20:03:13 or /usr/lib/... 2021-01-27 20:03:25 it's essentially empty except some automount rules i wrote 2021-01-27 20:03:49 I don't have e/udev (just plain mdev) but all is detected 2021-01-27 20:03:50 huh? eudev should have lots of stuff 2021-01-27 20:04:20 mps: https://www.gentoo.org/support/news-items/2020-04-03-deprecation-of-legacy-x11-input-drivers.html says need udev 2021-01-27 20:04:24 ah they're in lib not etc 2021-01-27 20:04:27 i was looking in etc 2021-01-27 20:04:39 just looking at the fbdev and vesa errors 2021-01-27 20:04:55 but it doesn't specifically say mdev doesn't work 2021-01-27 20:05:15 graytshirt: totally unrelated. those are xorg modules, not kernel modules 2021-01-27 20:05:33 Hello71: udev is needed fot hot plug devices, but if they are plugged before boot they are detected by mdev 2021-01-27 20:06:12 how does it get the "event13 - BM30X mouse: is tagged by udev as: Mouse" then 2021-01-27 20:06:13 what udev rules file covers keyboard ? 2021-01-27 20:06:23 dalias: no idea! 2021-01-27 20:06:24 i have eudev and mice are fine 2021-01-27 20:06:30 it's keyboard that doesn't appear 2021-01-27 20:06:47 all the keyboards don't (also includes virtual ones like lid, power button, etc) 2021-01-27 20:07:02 it's like eudev is completely hiding keyboards 2021-01-27 20:07:02 maybe try evtest first? 2021-01-27 20:07:57 evtest works fine 2021-01-27 20:08:01 dalias: is your system fully upgraded? 2021-01-27 20:08:04 but it's not using udev 2021-01-27 20:08:18 my-r, not "fully" but all related packages seem to be 2021-01-27 20:08:24 oook 2021-01-27 20:08:25 (udev, libinput, all xorg stuff, etc) 2021-01-27 20:08:58 i really dont feel like upgrading GBs of random apps i haven't used in forever 2021-01-27 20:09:29 is there a way to get a report of packages that are behind latest? 2021-01-27 20:09:40 apk upgrade -s 2021-01-27 20:09:41 upgrade -as 2021-01-27 20:09:49 but maybe you want apk version -somethingorother 2021-01-27 20:10:05 or just "apk version" 2021-01-27 20:12:11 dont see anything relevant 2021-01-27 20:15:28 is there a way to look at what udev sees? 2021-01-27 20:15:42 udevadm 2021-01-27 20:17:47 what is usage? i'm trying to figure it out 2021-01-27 20:21:04 hmm with udevadm info 2021-01-27 20:21:16 mice have ID_INPUT_MOUSE=.. 2021-01-27 20:21:21 but keyboards have no ID_INPUT_* 2021-01-27 20:21:28 so something is wrong with udev.. 2021-01-27 20:23:51 should there be a /dev/input/by-id dir? 2021-01-27 20:29:02 ls -l /dev/input/ | tpaste => https://tpaste.us/jn8m 2021-01-27 20:29:41 that's all on my current box and everything works 2021-01-27 20:33:59 ok 2021-01-27 20:34:17 what does udevadm info /dev/input/event0 show ? 2021-01-27 20:34:36 dalias: you ask me? 2021-01-27 20:35:25 yeah 2021-01-27 20:35:56 I told I don't use udev, so don't have these tools 2021-01-27 20:36:35 ah ok 2021-01-27 20:36:49 but then you must have xorg configured in some udev-free way .. ? 2021-01-27 20:36:59 do you have an xorg.conf ? 2021-01-27 20:37:11 no, as it is shipped in alpine 2021-01-27 20:37:33 Seems like https://gitlab.alpinelinux.org/alpine/aports/-/commit/25c5e4f7d069fcc1f0cc8c2f4737ef261c7d2132 introduced a bug in rspamd, investigating right now 2021-01-27 20:37:34 only added tweaks to touchpad 2021-01-27 20:39:11 dalias: no, I don't have xorg.conf but have two files in /etc/X11/xorg.conf.d/ 2021-01-27 20:39:29 20-modules.conf and 30-lib-touchpad.conf 2021-01-27 20:40:57 i have no more 20-modules.conf 2021-01-27 20:41:00 it was removed by upgrade 2021-01-27 20:41:38 well, that is for loading modules, not should have any relation to your problem 2021-01-27 20:42:15 mps: are you using evdev or libinput? 2021-01-27 20:42:50 Hello71: no, libinput 2021-01-27 20:43:10 uh 2021-01-27 20:43:14 anyone with working udev setup able to show udevadm info for keyboard? 2021-01-27 20:44:25 let me look on old macbook, if it boots 2021-01-27 20:45:57 https://bpa.st/raw/YEREW but i am on gentoo, not alpine 2021-01-27 20:47:37 udevadm info /dev/input/event8 | tpaste => https://tpaste.us/DM9d 2021-01-27 20:49:11 yeah it has all the ID_* stuff telling it's a keyboard 2021-01-27 20:49:13 mine has none of that 2021-01-27 20:49:21 and X seems to therefore ignore it 2021-01-27 20:49:31 so something in the udev rules isn't matching 2021-01-27 20:52:22 dalias: those properties are set by https://github.com/gentoo/eudev/blob/master/src/udev/udev-builtin-input_id.c 2021-01-27 20:52:52 so what could cause them to be absent .. ?! 2021-01-27 20:53:03 according to the man page, you can try udevadm test-builtin 2021-01-27 20:53:56 what is the usage? 2021-01-27 20:56:45 dunno. maybe try udevadm test-builtin input_id /dev/input/... 2021-01-27 20:56:56 it prepends /sys for some reason... 2021-01-27 20:57:36 then i guess use the corresponding sysfs node 2021-01-27 20:57:48 from udevadm info 2021-01-27 20:59:28 yeah 2021-01-27 20:59:36 ok it works wtf 2021-01-27 20:59:43 ID_INPUT_KEYBOARD=1 2021-01-27 21:02:22 if i try test-builtin keyboard on it tho 2021-01-27 21:02:47 no db file to read /run/udev/data/c13:64: No such file or directory 2021-01-27 21:02:54 that sounds like it could be source of problem 2021-01-27 21:06:40 dunno then 2021-01-27 21:10:52 also I have no idea what is cause, for me on different machines, some old and some new keyboard never was problem 2021-01-27 21:16:37 nvm found the problem 2021-01-27 21:16:42 ah 2021-01-27 21:17:00 can i just make a static keyboard config for /dev/input/event0 somehow? 2021-01-27 21:17:07 separate from the auto udev shit? 2021-01-27 21:17:15 i'd actually LOVE for udev not to be able to add keyboards 2021-01-27 21:18:33 according to mps you can uninstall udev 2021-01-27 21:19:30 Hello71: yes, but have to install libudev-zero, some basic pkgs have deps on 'udev' 2021-01-27 21:20:13 is udev.conf perhaps supposed to contain something? 2021-01-27 21:23:07 https://k1ss.org/wiki/dev/replacing-udev 2021-01-27 21:27:26 also for libudev-zero https://github.com/illiliti/libudev-zero/ 2021-01-27 21:28:55 oh, good, just noticed that I have to upgrade it for alpine 2021-01-27 21:29:32 what does that do? 2021-01-27 21:29:50 a fake provider for udev 2021-01-27 21:29:54 uhg i cant find any info on how to make a static kb device entry 2021-01-27 21:32:45 something like ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="03f0", ATTR{idProduct}=="2f4a", ENV{ID_INPUT}="1" 2021-01-27 21:35:17 there is no usb here 2021-01-27 21:35:23 it's core platform device 2021-01-27 21:35:39 ps2 equivalent 2021-01-27 21:38:49 is there a way to turn on udev logging of some sort? 2021-01-27 21:45:30 does udev need some option to process stuff that was already present at boot rather than hot plugged? 2021-01-27 21:48:57 i'm not udev expert but it should settle devices detected on boot once and plugged/unplugged when they happens 2021-01-27 21:49:34 i'm manually startign udev and dont see it doing anything with existing devices 2021-01-27 21:50:59 well, when I change some rules for udev on devices where it is still used I simply restart it 2021-01-27 21:52:10 udevadm trigger made it all work (!!!!) 2021-01-27 21:52:21 ffs why is that not happening automatically? 2021-01-27 21:53:30 I always expected it should but never seen it to do that 2021-01-27 21:54:11 ok udev-trigger is not in rc-update config 2021-01-27 21:54:13 where should it be? 2021-01-27 21:54:53 also udev is not chgrp'ing /dev/input/* to group input so it's broken with suid... 2021-01-27 21:54:56 erm with nosuid 2021-01-27 21:55:14 is there a fix for that ? 2021-01-27 21:57:19 acpid is supposed to depend on it tho.. 2021-01-27 21:57:42 uhg fuck mdev has "provide dev" 2021-01-27 21:58:31 so is it preventing udev-trigger from getting pulled in ? 2021-01-27 22:00:33 yes that's what happened 2021-01-27 22:00:39 how do i prevent mdev from getting used ? 2021-01-27 22:01:55 dalias: iirc, when eudev installed it 'block' mdev from run 2021-01-27 22:02:20 how? 2021-01-27 22:02:23 ahm 2021-01-27 22:02:25 mdev was run here 2021-01-27 22:02:38 it's showing in Dynamic Runlevel: needed/wanted 2021-01-27 22:02:44 looks like it need to be set in kernel command line 2021-01-27 22:03:13 uhg lol wtf of course that's not there, why would this be oon kernel command line rather than /etc !? 2021-01-27 22:03:20 look 'etc/init.d/mdev start() function 2021-01-27 22:03:31 yeah i see 2021-01-27 22:03:56 rc-update del mdev could be enough, but I didn't tested 2021-01-27 22:04:00 is there any way with openrc to blacklist services? 2021-01-27 22:04:31 it's no there; it's implicitly pulled in because it "provides dev" 2021-01-27 22:06:19 remove 'provide dev' from init script 2021-01-27 22:06:37 maybe that will work 2021-01-27 22:09:56 i explicitly added udev-trigger in sysinit runlevel so it's already provided 2021-01-27 22:10:03 seems to have solved it 2021-01-27 22:10:33 nice to hear 2021-01-27 22:10:59 this might fix other random broken stuff too 2021-01-27 22:11:21 now I can ask you what to do with pkg which have on_exit function ;) 2021-01-27 22:11:45 lol wut 2021-01-27 22:11:55 give a minute 2021-01-27 22:12:26 is it that wacky thing that also gives the exit handlers the exit code? 2021-01-27 22:12:49 src/throttling.c:86:2: warning: implicit declaration of function 'on_exit'; did you mean '_exit'? [-Wimplicit-function-declaration] 2021-01-27 22:12:56 stalld pkg 2021-01-27 22:13:26 i would just patch it to use atexit 2021-01-27 22:13:47 thanks 2021-01-27 22:14:19 same for /home/mps/aports/testing/stalld/src/stalld-1.5/tests/test01.c:139: undefined reference to `pthread_attr_setaffinity_np' 2021-01-27 22:15:30 pthread_setaffinity_np 2021-01-27 22:15:42 aha 2021-01-27 22:16:12 thanks again 2021-01-27 22:25:17 how are you supposed to do rootless X with modesetting? 2021-01-27 22:25:24 i get a bunch of eaccess 2021-01-27 22:25:46 [ 938.715] (EE) modeset(0): drmSetMaster failed: Permission denied 2021-01-27 22:25:48 should be add user to video or use elogind, same as intel 2021-01-27 22:26:00 i'm in video 2021-01-27 22:26:11 hm... could be you need elogind actually... gotta go now but can check later 2021-01-27 22:26:13 it tries to open /dev/vga_arbiter too tho 2021-01-27 22:26:55 i want to try switching because after upgrade (w/intel) firefox is freezing for 5 seconds at a time 2021-01-27 22:27:05 and when i had this symptom before it was idiotic gpu stuff 2021-01-27 22:28:37 there's also DRM_IOCTL_SET_MASTER failure 2021-01-27 22:30:55 ah need to update kernel... 2021-01-27 22:32:17 dalias: by rootless X you mean without setuid? 2021-01-27 22:32:32 yes 2021-01-27 22:32:46 aha, it works fine for me 2021-01-27 22:32:54 with modesetting, I mean 2021-01-27 22:33:48 wow this is hideously slow 2021-01-27 22:33:56 as modesetting 2021-01-27 22:34:37 how can i tell if it's even using 3d accel right? 2021-01-27 22:35:09 ah lovely firefox is fast and it's just uuterm that's slow 2021-01-27 22:35:13 so there must be accel 2021-01-27 22:35:29 it's just that firefox is doing gpu compositing type shit 2021-01-27 22:35:33 which is accelerated 2021-01-27 22:35:42 but there's no acceleration for standard 2d raster ops 2021-01-27 22:35:44 grrr 2021-01-27 22:36:33 I play sometimes with these on arm64 but must say that it is 'black magic' for me 2021-01-27 22:37:09 if the firefox enough fast then the st term 'enough slow' 2021-01-27 22:37:32 but I don't waste much time on these things 2021-01-27 22:38:06 2d is quite fine for me 2021-01-27 22:38:35 right the problem is they made 2d slow and only 3d fast 2021-01-27 22:38:44 ah 2021-01-27 22:39:01 like 50x slower type slow 2021-01-27 22:40:09 hmm, something like this I have when using panfrost gpu driver 2021-01-27 22:40:38 mpv works nice, but editing source is slow 2021-01-27 22:40:53 "lol who would care if expansion of 1bpp data to screen is slow?" 2021-01-27 22:41:01 "umm, that's how you draw text" 2021-01-27 22:42:01 going to update kernel now too, see if getting drivers and kernel all latest just makes this decent again.. 2021-01-27 23:00:27 aports MR build log shows "ERROR: Uploading artifacts as "archive" to coordinator... too large archive", is it fixable? 2021-01-27 23:00:37 make it smaller 2021-01-27 23:00:46 Can't 2021-01-27 23:01:00 the app is large 2021-01-27 23:02:27 oh, pycharm... i don't think it makes sense to package that 2021-01-27 23:03:25 and of course you can. use system jvm for one 2021-01-27 23:08:31 It's part of a complete desktop environment 2021-01-27 23:09:10 if you use openjdk$ver the app nags you about it and recommend you to use the internal one. 2021-01-27 23:14:11 TBK[m]: would you backport libudev-zero to 3.13 2021-01-27 23:14:34 if not then here is one who will :) 2021-01-27 23:14:51 sure 2021-01-27 23:14:58 thanks 2021-01-27 23:18:58 what version of musl did alpine-3.12 use? 2021-01-27 23:19:51 skarnet: 1.1.24 2021-01-27 23:20:09 thanks 2021-01-27 23:20:24 with some patches 2021-01-27 23:20:52 dalias: what changed in time_t / timespec on armv7 (or generic 32-bit, maybe) between 1.1.24 and 1.2.2 ? 2021-01-27 23:21:03 it doubled in size? 2021-01-27 23:21:12 https://musl.libc.org/time64.html 2021-01-27 23:21:35 https://musl.libc.org/releases.html "This release moves all 32-bit archs to 64-bit time_t, enabling them to represent times beyond January of 2038.' 2021-01-27 23:21:57 yeah, but there's more to it 2021-01-27 23:22:35 context: I'm tracking #12346 and have the problem down to one line in skalibs 2021-01-27 23:23:18 did you read https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#time64_requirements 2021-01-27 23:25:00 I'll ask the reporter :) 2021-01-27 23:26:20 ... no, that's irrelevant, that's only libseccomp 2021-01-27 23:26:27 which is unrelated here 2021-01-27 23:50:04 skarnet, what is the problem? 2021-01-27 23:51:26 if the issue is under docker, i think it's broken docker seccomp 2021-01-27 23:51:37 no, seccomp is irrelevant here 2021-01-27 23:51:51 unless seccomp can corrupt timespecs :P 2021-01-27 23:52:53 the problem is that on armv7 and only with musl-1.2.2, I have a cast from uint64_t to time_t that seems to produce garbage 2021-01-27 23:53:09 not 100% yet, currently investigating 2021-01-27 23:54:02 well if you don't check the result of clock_gettime it'll give you garbage memory 2021-01-27 23:54:32 which is what happened to busybox date 2021-01-27 23:54:37 wait what? 2021-01-27 23:56:02 Hello71: can I have a link to the problem? and what am I supposed to be doing? 2021-01-27 23:57:14 clock_gettime sets errno = EPERM and does not initialize the output buffer when running in a 32-bit docker container if docker version is before 19.10.somesuch or if libseccomp version is before 2.4.someother 2021-01-27 23:57:33 case 1 doesn't usually apply but case 2 is disappointingly common across distros 2021-01-27 23:58:12 ah, so it can still be a seccomp problem even if don't use seccomp at all? because clock_gettime() gets blocked? 2021-01-28 00:12:01 docker uses seccomp. 2021-01-28 00:12:22 which I think I was sufficiently clear about in the release notes 2021-01-28 00:12:23 im not using docker 2021-01-28 00:12:42 Hello71 im running alpine armhf on a pi 2021-01-28 00:13:01 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12346 says docker several times 2021-01-28 00:13:09 am i missing something here 2021-01-28 00:13:13 the issue was related but not the same 2021-01-28 00:13:16 i didnt report that issue 2021-01-28 00:13:23 what issue are you talking about then 2021-01-28 00:13:27 i didnt file 2021-01-28 00:13:32 we've just been talking on irc so far 2021-01-28 00:14:22 issue is: s6 seems to be barfing on 32-bit because of musl's 64-bit time 2021-01-28 00:16:47 opal: don't mix issues please 2021-01-28 00:17:06 the issue I'm talking about here is the one that has been reported by mbentley, and it *may* be due to the seccomp thing 2021-01-28 00:17:11 ah ok 2021-01-28 00:17:15 I want to clear that up first 2021-01-28 00:17:20 my bad then 2021-01-28 00:17:58 im trying to make everything about me :p 2021-01-28 00:18:22 tbh I want both problems to be the same, it would be easier :P 2021-01-28 00:18:35 but it's not certain they are 2021-01-28 00:19:04 well i'll wait on that then before trying anything else on my end, i should probably be breaking other things tonight anyway 2021-01-28 00:19:24 i'll be around tomorrow to see what's up 2021-01-28 00:26:25 your clock_gettime() returns 0 so there's definitely something on rpi 2021-01-28 00:26:31 it's not docker-related 2021-01-28 00:26:35 but it's different 2021-01-28 00:27:00 joys of using old hardware 2021-01-28 00:27:09 friend gave me this thing since he wasnt using it lmao 2021-01-28 01:57:58 there was rpi kernel with broken vdso but we disabled vdso until that can be safely avoided 2021-01-28 01:58:59 opal, can you strace the failure? 2021-01-28 02:02:02 already have one handy, https://wowana.me/paste/fS6uSR.txt 2021-01-28 02:05:25 ok no sign of anything wrong there 2021-01-28 02:05:46 wdym, ppoll() returns einval 2021-01-28 02:06:13 oh ok looking 2021-01-28 02:06:32 ah because tv_sec = -1 2021-01-28 02:06:35 yeah 2021-01-28 02:08:09 where is that called from? 2021-01-28 02:08:39 skalibs somewhere 2021-01-28 02:08:43 dont have the code up right now 2021-01-28 02:11:05 here maybe? (sorry github link because it's easier to search) 2021-01-28 02:11:07 https://github.com/skarnet/skalibs/blob/f3d5157564992f1ef9f390b3ce0c7d3706ba0f19/src/libstddjb/iopause_ppoll.c 2021-01-28 02:11:19 uh yeah that'd be the file 2021-01-28 02:12:14 it looks like it can produce a negative timeout 2021-01-28 02:12:22 which is erroneous to pass to ppoll 2021-01-28 02:12:38 (sorry im focused on other broken crap rn so i cant be of much help) 2021-01-28 02:12:53 hmm no maybe the tain_less predicate avoids that 2021-01-28 02:12:53 gotta refactor someone else's code because their fucking docs dont line up with reality at all 2021-01-28 02:13:36 actually pissed at how bad this code is, so im gonna go ahead and take my anger out on it 2021-01-28 02:17:40 :/ 2021-01-28 02:18:12 "this code" definitely not meaning s6/skalibs 2021-01-28 02:18:18 just some other trash ive been trying to get running 2021-01-28 02:18:39 not pointing fingers but it's a popular piece of software, i'll leave it at that 2021-01-28 02:19:01 i know 2021-01-28 08:13:17 dalias: yeah tv_sec=-1 and the problem happens earlier, the previous ppoll() has tv_sec=0 and tv_nsec=something when it should have a very large tv_sec 2021-01-28 08:14:12 it works on 64-bit archs, it works on musl-1.1.24, so there's something with the time64 change that broke 2021-01-28 09:07:26 ikke: https://pkgs.alpinelinux.org/contents?file=&path=%2Fetc%2Fsudoers.d&name=&branch=edge&arch=x86_64 2021-01-28 09:08:08 Ah, indirect dependencies 2021-01-28 09:09:44 does doas handle includes? 2021-01-28 09:55:34 No mention of it, so I assume it does not 2021-01-28 11:28:56 Got a bit of an issue with a new version of one of my packages. For the tests to run, it needs a new package. However, this new package should go in 'testing' first. That'll mean the CI won't find this new package when it tries to build the update to the existing package. Any suggestions how to get around this? I guess I could initially upload the 2021-01-28 11:28:56 new package in testing, wait for it to be merged, then move to community and wait for that to be merged? 2021-01-28 11:42:25 That'd work, yes 2021-01-28 11:42:48 We usually allow introducing packages directly into community if they're a dependency of an existing package though 2021-01-28 11:44:04 Oh ok. That'd help. 2021-01-28 11:44:15 Now got to work out why it won't build in docker or CI, but does in alpine iwth abuild! 2021-01-28 11:51:05 ikke: guess we need something like "include" to replace the current use-cases of sudo 2021-01-28 11:51:50 just drop-in files are soft dependencies though 2021-01-28 11:52:02 so if people want to use it, they could install sudo from community 2021-01-28 11:52:55 x2goserver does not depend on sudo for example 2021-01-28 12:15:53 What's the versioning convention for git packages? 2021-01-28 12:16:37 0_git$dateOfCommit 2021-01-28 12:16:45 so e.g. 0_git20210128 2021-01-28 12:17:25 Thanks! 2021-01-28 12:18:36 https://github.com/tangwz/jsonlint/blob/master/LICENSE.txt 2021-01-28 12:18:45 this looks like 3-clause BSD, right? 2021-01-28 12:19:38 Yup 2021-01-28 12:27:32 timlegge: does perl-crypt-openssl-x509 depends on openssl-dev for some reason, or just overlooked 2021-01-28 12:30:01 ikke: sure but using /etc/sudoers.d is a common use case also in server management e.g. with ansible 2021-01-28 13:01:49 HRio: yupe, cloud-init creates files in /etc/sudoers.d/ 2021-01-28 13:07:50 let me look - I would guess that it should 2021-01-28 13:10:05 Anyone know why dabuild -vr resulted in "mkdir: can't create directory '/home/builder/aports/testing/xxxxxx/src': Permission denied"? 2021-01-28 13:11:04 Anyone able to checkout MR !17567 for me? 2021-01-28 13:11:40 It builds fine on an alpine box with abuild, but fails under dabuild and the CI container. 2021-01-28 13:11:41 sup adhawkins 2021-01-28 13:11:52 lets take a look 2021-01-28 13:11:57 https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/306913 2021-01-28 13:12:14 Thanks alex_y_. 2021-01-28 13:12:43 By the way, I'll fix up the commits before removing the WIP tag, just wanted to get it running on 'real' CI to double check the results were the same as I'm seeing locally. 2021-01-28 13:14:46 wow never seen that one before 2021-01-28 13:14:59 Are you seeing the same thing? You can build it locally? 2021-01-28 13:15:08 mps: yes perl-crypt-openssl-x509 is a XS based module whick links to the openssl libraries. However that should be a makedepends - I can sort it later today and test to ensure it is not needed for using the module 2021-01-28 13:15:14 I saw the MR build job log 2021-01-28 13:15:27 Ok. Any chance you could check out the branch and try to build it locally? 2021-01-28 13:15:31 yup 2021-01-28 13:15:46 py3-sly is a new package, and py3-quantiphy-eval is upgrading to v0.4 (sly is a new dependency) 2021-01-28 13:36:02 timlegge: thanks, I was not sure if you have some reasons for current deps 2021-01-28 13:37:35 adhawkins: it built fine on my end, all of it 2021-01-28 13:39:15 Yep, same behaviour as me then. I can build it natively, but if I build with dabuild or the CI docker container it fails (in the same way as the MR). 2021-01-28 13:39:19 Anyone got any ideas? 2021-01-28 13:43:15 As an aside, I've fixed up the commits now. 2021-01-28 13:43:25 Once it builds on CI I'll do some proper testing! :) 2021-01-28 13:44:05 Looks like sly is not passing NAME in lexer when it is imported 2021-01-28 13:45:15 But only when it's being done under Docker... 2021-01-28 13:45:32 Are you able to run dabuild locally alex_y_? Double check you see the same there? 2021-01-28 13:45:38 let's see 2021-01-28 13:47:57 ERROR: unable to select packages: py3-sly (no such package): 2021-01-28 13:48:06 adding it to depends 2021-01-28 13:48:33 hmm still wont find it 2021-01-28 13:48:35 wtf 2021-01-28 13:48:58 It should be in depends. 2021-01-28 13:49:14 Have you used dabuild to build it first? 2021-01-28 13:49:19 (py3-sly that is) 2021-01-28 13:49:55 how do you keep packages between dabuild runs? 2021-01-28 13:50:11 The container should handle that for you, it maps a local 'packages' directory into the container. 2021-01-28 13:50:48 docker run --tty --interactive -v /home/andy/alpine-packaging/aports:/home/builder/aports -v /home/andy/alpine-packaging/packages/edge:/home/builder/packages -v /home/andy/.gitconfig:/home/builder/.gitconfig -v dabuild-apkcache-edge-x86_64:/etc/apk/cache -v dabuild-config:/home/builder/.abuild --rm --workdir /home/builder/aports/community/py3-sly 2021-01-28 13:50:48 alpinelinux/docker-abuild:edge-x86_64 -rfK 2021-01-28 13:50:55 /home/builder? 2021-01-28 13:51:03 That's the docker command mine runs when I run dabuild 2021-01-28 13:51:04 ahhh 2021-01-28 13:51:12 try: 'bash -x dabuild -rfK' and see what you see. 2021-01-28 13:51:21 yeah it kept referring to /home/builder and I didn't provide a bind 2021-01-28 13:51:37 You shouldn't need to. dabuild should do all that or you. 2021-01-28 13:51:51 It creates a docker volume called (I think) dabuild-apkcache-edge-x86_64 2021-01-28 13:53:07 bash -x resulted in ' py3-sly (no such package): 2021-01-28 13:53:17 But what docker command did it run? 2021-01-28 13:53:32 i'll try find that -tty line 2021-01-28 13:53:37 bash -x dabuild -rfK 2021-01-28 13:53:48 oh u mean from the log 2021-01-28 13:53:49 You might need to quote the 'dabuild -rfK' bit. 2021-01-28 13:54:06 Actually, try 2021-01-28 13:54:11 bash -x 'dabuild checksum' 2021-01-28 13:54:19 That should produce less output so you can find it easier. 2021-01-28 13:55:59 ok 2021-01-28 13:56:49 sed: can't create temp file 'APKBUILDXXXXXX': Permission denied 2021-01-28 13:57:03 lol this is adding to the problem, i'll sort this out first 2021-01-28 14:01:03 Yeah, I thought it sorted all of this for me the first time I ran dabuild. It just creates a couple of docker volumes and uses them. 2021-01-28 14:02:06 i'll git clone a fresh path and try dabuild py3-sly etc 2021-01-28 14:10:48 E NameError: name 'NAME' is not defined 2021-01-28 14:10:59 skarnet, any idea where i should look? 2021-01-28 14:11:08 i dont see any obviously wrong code 2021-01-28 14:11:08 dabuild works now, got the exact same error for your mR 2021-01-28 14:11:49 dalias: I can't tell you yet, sorry, I'm shaving a medium size yak in order to be able to perform tests on an armv7 qemu 2021-01-28 14:11:59 skarnet, conversions from tai[n]_t to time[_t,spec] are just at the last moment right? 2021-01-28 14:12:04 yes 2021-01-28 14:12:15 so there's not much surface for a bug and i dont see one there 2021-01-28 14:12:19 I suspect it's more at the clock_gettime() level that something happens 2021-01-28 14:12:29 but I'm not sure yet, I have more work to do on my end 2021-01-28 14:12:45 I'll get back to you when I have more precise suspicions 2021-01-28 14:12:50 clock_gettime is returning the right thing, at least the syscall 2021-01-28 14:13:50 the tv_sec=-1 you saw in the failing ppoll() is not even the first problem 2021-01-28 14:14:09 the problem happens before the previous ppoll() where tv_sec=0 2021-01-28 14:14:13 it succeeds by accident 2021-01-28 14:14:28 tv_sec should not be 0 here, it should be 2^60 or something 2021-01-28 14:14:43 wtf 2021-01-28 14:14:46 why so huge? 2021-01-28 14:15:16 my model for infinity. (I also use NULL sometimes, but not when I have to do time arithmetic like looping on deadlines) 2021-01-28 14:16:04 That's something alex_y_. Now to work out why it's different under docker? 2021-01-28 14:16:15 having a huge value for infinity simplifies code because you don't have to specialcase your time arithmetic every time you may not have specified a timeout 2021-01-28 14:16:24 ok 2021-01-28 14:16:52 and ppoll is definitely called via iopause_ppoll right? 2021-01-28 14:16:56 yes 2021-01-28 14:17:07 again, I can't tell you where something goes wrong yet 2021-01-28 14:17:15 stamp is current time? 2021-01-28 14:17:18 yes 2021-01-28 14:17:29 ok. maybe something is wrong computing it from timespec. i'll loook 2021-01-28 14:18:54 again, it's not urgent, and I'll be able to get back to you in a day or two when I have pinpointed something 2021-01-28 14:19:22 ok 2021-01-28 14:19:32 the problem may still be in my code, it's just that it would be weird that everything worked with previous musl 2021-01-28 14:19:34 adhawkins: try this, on quantiphy_eval.py, line 44-53, what happens if you move that tokens = () to line 86, after NAME is defined at line 84? 2021-01-28 14:25:28 I did consider that alex_y_, but abuild will decompress the tarball each time. 2021-01-28 14:25:32 Let's see if there's a way to prevent that. 2021-01-28 14:27:18 'dabuild -f build' only runs the 'build' step, but that doesn't install all the dependencies. 2021-01-28 14:29:10 Huh... 2021-01-28 14:29:13 It's now working. 2021-01-28 14:29:51 patched and moved 44-53 to line 86, still NAME not defined 2021-01-28 14:30:00 Its's now working here... 2021-01-28 14:30:08 lol 2021-01-28 14:30:11 what did you do 2021-01-28 14:30:20 I even did 'rm -rf src' to force it to get the tarballs again! 2021-01-28 14:30:52 Trying to run again via the MR 2021-01-28 14:31:56 wonder if all the UTF-8 chars in quantiphy_eval.py caused a bug some where 2021-01-28 14:32:03 locale and all 2021-01-28 14:34:48 Hold on. I was building py3-sly :( 2021-01-28 14:35:30 skarnet, do you know the particular large value you'd be passing for "infinite" ? 2021-01-28 14:35:31 Yes. getting different errors now. 2021-01-28 14:35:44 Move those lines and run 'dabuild deps build check' 2021-01-28 14:35:46 yes, hold on 2021-01-28 14:36:21 It's now saying "Symbol 'NAME' used, but not defined as a token or a rule" 2021-01-28 14:37:14 hmm 2021-01-28 14:37:31 skarnet, ok. looking to see if it's potentially a bug in musl 2021-01-28 14:37:55 I think we might need someone who knows a bit more about how the CI / docker stuff is set up to comment. 2021-01-28 14:40:19 dalias: it's either 2^61, or 2^60 + the current time relative to epoch, depending if the infinity is absolute or relative (don't ask) 2021-01-28 14:40:43 I have a patch to make the relative offset also 2^61 because there's no reason for it to be different, but it's not integrated yet 2021-01-28 14:41:06 but if you see "something greater than 2^60" then that's it 2021-01-28 14:42:01 and if you see something greater than 2^62 then that's a bug I have (those are absolute times and should not be used in timespec_from_tain_relative) 2021-01-28 14:42:14 I think you're right alex_y_, it might be some sort of codepage issue with all those Unicode characters perhaps? 2021-01-28 14:42:41 openjdk 2021-01-28 14:42:51 wrong window, sorry ;) 2021-01-28 14:42:56 I'ma be afk for a couple hours though 2021-01-28 14:45:14 skarnet, ok it seems to give right results. 2021-01-28 14:45:39 what does? 2021-01-28 14:45:55 CLAMP() and IS32BIT() macros :) 2021-01-28 14:46:10 gesundheit 2021-01-28 14:46:22 that deal with a huge input and deciding which syscall to use, and how to adjust the value for fallback to old syscall 2021-01-28 14:49:18 ikke seems to be the CI / docker guru, wonder if they can help? 2021-01-28 14:49:37 In an hour 2021-01-28 14:49:55 adhawkins: back, was fixing my MR after Leo commented on it 2021-01-28 14:50:54 adhawkins: maybe the build evn isn't in UTF-8? 2021-01-28 14:51:17 atleast the test env 2021-01-28 14:52:41 I don't think we explicitly set that 2021-01-28 14:53:09 codepage is dos garbage carried over to windows garbage 2021-01-28 14:53:48 it's barely relevant on windows anymore since utf8 is now supported (ish...) 2021-01-28 14:55:25 adhawkins: probably you are using different package versions on host 2021-01-28 14:55:48 or you changed py3-sly locally and didn't reinstall 2021-01-28 15:24:43 adhawkins: this might be related, pytest unicode issue https://stackoverflow.com/questions/44903389/does-pytest-support-unicode-in-test-name 2021-01-28 15:28:09 Hello71: py3-sly is a new packaged added my this MR. 2021-01-28 15:28:14 yes. 2021-01-28 15:28:21 you say it works outside docker 2021-01-28 15:28:35 Correct. 2021-01-28 15:28:56 I'm pretty sure I was doing this on a clean VM. Let me revert and double checkl. 2021-01-28 15:34:41 Ok, so now local build is failing in the same way. I'm confused. 2021-01-28 15:36:43 This is the steps I carried out on a clean VM: https://paste.debian.net/1183103/ 2021-01-28 15:37:27 At least I'm getting consistent results now. Question is, why is it failing, and why did it work for both me and alex_y_? 2021-01-28 15:43:49 adhawkins: What happens if you modify /usr/bin/dabuild line 26 to [DABUILD_ENV=" -e LC_ALL=en_US.UTF-8 -e LANG=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 "]? 2021-01-28 15:44:10 adhawkins: I tried to test it but docker won't even run at this point, permission denied :/ 2021-01-28 15:53:35 I'm not sure it's a docker issue any more alex_y_. Had issues building it locally above. 2021-01-28 16:22:43 I just don't understand how we both got it to build locally alex_y_. 2021-01-28 16:25:43 mps: perl-crypt-openssl-x509 depends on libcrypto1.1 but that is not in the APKBUILD should it be? It seems to figure it out somehow on https://pkgs.alpinelinux.org/package/edge/community/x86_64/perl-crypt-openssl-x509 2021-01-28 16:27:31 timlegge: will look, but I think because use of openssl-dev in makedepends abuild will find that it needs libcrypto1 automatically 2021-01-28 16:27:55 I'm outside home right now 2021-01-28 16:28:17 or right term is 'out of home' 2021-01-28 16:32:37 homen't 2021-01-28 16:33:26 opal: :) 2021-01-28 16:42:13 outside, must be nice. Feels like I have not been out in weeks 2021-01-28 16:44:13 snowed here 2021-01-28 16:48:19 timlegge: I'm working on backport of perl-crypt-openssl-x509 to 3.12-stable, I need it there 2021-01-28 16:49:00 opal: snow here too -2C 2021-01-28 16:50:32 lucky you, I would like at least 50 cm of snow here 2021-01-28 16:51:04 mps: there is an outdated version there not a lot of changes 2021-01-28 16:51:59 we have 10-20 cm on the ground but its been that way for a few weeks. 2021-01-28 16:52:36 enough to make snowman 2021-01-28 16:55:29 We had a tiny bit of snow, but it was gone within a day 2021-01-28 16:55:55 nice temperature 2021-01-28 16:56:05 :D currently 29C here 2021-01-28 16:57:43 well, for you it's summer, right? 2021-01-28 17:07:18 timlegge: tested it, 'depends' is not needed at all 2021-01-28 17:07:41 only move openssl-dev to makedepends 2021-01-28 17:08:39 'apk info -R perl-crypt-openssl-x509' => so:libcrypto.so.1.1 2021-01-28 17:09:00 and musl, ofc 2021-01-28 17:09:47 but strange it didn't perl automatically 2021-01-28 17:10:11 huh 2021-01-28 17:12:04 hmhm 2021-01-28 17:17:35 huh, I used wrong lxc to build it :) 2021-01-28 17:18:58 what's the venue for discussing security fixes for packages in main? 2021-01-28 17:19:50 generally file an issue at aports. i don't think there's a place on irc 2021-01-28 17:20:06 THere is #alpine-security, but it's not really used atm 2021-01-28 17:21:05 You can create confidential issues on gitlab i 2021-01-28 17:27:23 adhawkins: it stops building local for me as well, maybe we both built py3-quantiphy instead of py3-quantiphy-eval? 2021-01-28 17:27:47 Anything's possible. I'm thoroughly confused now! 2021-01-28 17:30:29 adhawkins: heh when the test is coded worse than the code being tested, it's spaghetii 2021-01-28 17:30:44 heh 2021-01-28 17:31:08 Thing is, I think the code that's failing isn't the test code, it's the module itself. 2021-01-28 17:31:26 adhawkins: the codes are jumping all over the place, what the hell are {{1 {{2 in the comments? 2021-01-28 17:31:41 Sadly, I have no idea. 2021-01-28 17:37:39 # Remove commas {{{2 2021-01-28 17:37:45 # Main {{{1 2021-01-28 17:37:46 lol 2021-01-28 17:45:03 there are folding markers 2021-01-28 17:47:13 `zc` (close) to fold, `zo` (open) to unfold 2021-01-28 17:47:16 (that's assuming foldmethod=marker) 2021-01-28 17:47:26 also, vim 2021-01-28 17:49:04 ahh 2021-01-28 18:01:41 ddevault: typical :) 2021-01-28 18:02:55 hm? 2021-01-28 18:03:16 that issue you created 2021-01-28 18:03:19 ah 2021-01-28 18:03:20 and its timing 2021-01-28 18:03:22 aye 2021-01-28 18:03:40 and yet another matter that Rust would have done nothing to prevent 2021-01-28 18:03:47 heh 2021-01-28 18:04:37 and tbh this is encouraging 2021-01-28 18:04:53 is much more easily audited than 2021-01-28 18:05:14 which one? 2021-01-28 18:05:30 I decline to name it on the basis that the patch addressing the vulnerability has not shipped 2021-01-28 18:09:39 bleh 2021-01-28 18:09:42 oh ok 2021-01-28 18:09:48 ddevault: now email linux-distros :p 2021-01-28 18:10:07 I'm not responsible for the disclosure, I was disclosed to because it affects one of my packages 2021-01-28 18:10:10 my responsibility ends here 2021-01-28 18:10:11 ahh, okay 2021-01-28 19:08:53 HRio: I understand it's usefull to have a drop-in directory for config, but it's something upstream (or even upstream of upstream) would need to support 2021-01-28 19:11:06 i'm going through aports bugs, and it seems like we have several duplicates of "rpi does not boot, cannot find kernel.img, moving files out of boot fixes the issue". one user reports that reformatting the card fixed the issue for them 2021-01-28 19:11:34 my guess is that "raspberry pi imager" creates mbr or vfat with some issues? 2021-01-28 19:25:38 weren't we supposed to rebuild all packages for time64? how come time got skipped? https://pkgs.alpinelinux.org/packages?name=time&branch=edge https://gitlab.alpinelinux.org/alpine/aports/-/issues/11878 2021-01-28 19:27:10 only on 32-bits at least 2021-01-28 19:27:36 i dunno why but it shouldnt matter 2021-01-28 19:27:51 yeah but at least according to p.a.o it wasn't 2021-01-28 19:28:49 can we bump to 5.10.11 on linux-lts? thanks 2021-01-28 19:29:02 Hello71: on the x86 builder: 2021-01-28 19:29:10 -rw-r--r-- 1 buildoze buildoze 12629 Jul 16 2020 time-1.9-r0.apk 2021-01-28 19:30:40 But if I look in the package it says 2018 2021-01-28 19:31:02 c705: isn't it already 2021-01-28 19:31:19 yes 2021-01-28 19:31:20 is since day 2021-01-28 19:31:25 seems still building 2021-01-28 19:31:38 https://pkgs.alpinelinux.org/packages?name=linux-lts&branch=edge 2021-01-28 19:31:57 heh, there is linux-edge-5.10.11 2021-01-28 19:32:27 mps: np 2021-01-28 19:32:27 linux-lts-5.10.10-r0 2021-01-28 19:32:29 3.13 2021-01-28 19:32:33 no 2021-01-28 19:32:35 ah, that's different 2021-01-28 19:32:41 it's upgraded on edge 2021-01-28 19:32:43 no on 3.13 is too 2021-01-28 19:32:53 no it isn't 2021-01-28 19:32:56 https://pkgs.alpinelinux.org/packages?name=linux-lts&branch=v3.13 2021-01-28 19:32:56 for stables upgrades are at slower pace 2021-01-28 19:33:06 pkgs.a.o says it is 2021-01-28 19:33:12 c705: what mirror do you use? 2021-01-28 19:33:24 https://dl-cdn.alpinelinux.org/alpine/v3.13/main β”‚[ +0.000001] usb 5-3.4: Manufacturer: SAMSUNG 2021-01-28 19:34:14 if it's upstream, then i'll wait 2021-01-28 19:35:44 https://gitlab.alpinelinux.org/alpine/aports/-/commit/8744f6fe7507df0af6220e8e5b59aabf9a8f9bca 2021-01-28 19:35:55 Hmm: http://dl-master.alpinelinux.org/alpine/v3.13/main/x86_64/linux-lts-5.10.10-r0.apk 2021-01-28 19:36:15 builders stuck on something else? 2021-01-28 19:36:41 but how does pkgs.a.o get it then 2021-01-28 19:36:54 oh ye 2021-01-28 19:37:11 The x86_64 builder seems stuck 2021-01-28 19:37:13 so cdn didnt cache it yet? 2021-01-28 19:37:37 It doesnt cache the file index 2021-01-28 19:37:57 ye arch64 got 5.10.11 on cdn 2021-01-28 19:39:41 is great idea to update to 5.10.11, previous versions broke intel drm things 2021-01-28 19:40:14 uhg it did? 2021-01-28 19:40:37 intel seems to work here -- what breakage should i expect? 2021-01-28 19:41:40 hmm, I'm puzzled why pkgs.a.o already shows .11 for x86_64 2021-01-28 19:41:50 yeah, randomy missing letters/menus, screen flahes etc when used mpv 2021-01-28 19:45:33 https://gitlab.freedesktop.org/drm/intel/-/issues/2905 2021-01-28 20:06:13 actually there is quite a long history of such rpi bugs 2021-01-28 20:10:08 at least half a dozen going back a few years 2021-01-28 20:10:34 Hello71: the RPI issues generally appear to be a combination of out-of-date/incorrect guides on the Wiki, change in behaviour for RPI between 3.12 and 3.13, and "other" issues. I tried helping in one of those recent tickets but gave up when my attempt to help fell on deaf ears. 2021-01-28 20:11:10 i killed the telepathy-glib on build-3-13-x86_64. it seemd to be deadlocked 2021-01-28 20:11:10 which change? 2021-01-28 20:12:19 Hello71: ncopa changed one of the scripts to deal with the know issue of some of the RPI boot files being in the wrong place, let me find the related MR 2021-01-28 20:12:38 yes, the dtb files were moved 2021-01-28 20:12:47 but that's for upgrading. i'm talking about new installs 2021-01-28 20:12:57 Hello71: This is the issue where I recently tried to help someone: !12353 2021-01-28 20:13:05 seems like people format with god-knows-what, then copy rpi files on 2021-01-28 20:13:27 i guess you mean #12353 2021-01-28 20:13:43 yupe, my mistake :-) 2021-01-28 20:14:03 but as i was saying, then rpi bootloader fails to load kernel somehow 2021-01-28 20:14:03 yeah. original person is trying to install SYS mode specifying a mountpoint rather than a device name 2021-01-28 20:14:43 minimal: there is confusion all around there 2021-01-28 20:15:54 Hello71: I build my own SYS images for RPIs so I'm fairly familiar with how it should work. In this ticket someone else jumped on and talked about removing arbitary lines from the setup-disk script :-( 2021-01-28 20:18:21 Hello71: I'm happy to help people with RPI, I'm happy to be party of an Alpine RPI team to sort things out in general, I've had 2 RPI-related MRs gathering dust for 1 month (not specific to this issue but trying to improve RPI support in general) 2021-01-28 20:19:40 if you have some time (and i guess maybe a windows box), can you or someone else try using "raspberry pi imager" to make a raspbian sd card, then try to put alpine on it by just deleting the contents and replacing with alpine tar? 2021-01-28 20:19:50 i'm pretty sure that's what everybody is trying to do 2021-01-28 20:20:27 not sure if the Raspbian partitioning is similar to Alpine partitioning 2021-01-28 20:21:20 for the people running "disk-setup -m SYS /mnt" they need to *themselves* have already partitioned and created filesystem, and mounted the first partition onto /mnt/boot before running that command. 2021-01-28 20:22:01 whereas if they run "disk-setup -m SYS /dev/WHATEVER" the script is supposed to partition/createfs/mount correctly for them 2021-01-28 20:27:31 Hello71: If many of them are using NOOBS that might explain, at least in part, issues as the partitions layout is different: https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained 2021-01-28 20:28:46 however in the ticket I mentioned it appeared the original poster had booted Alpine on a RPI and was then attempting to do a SYS install - whether to the *same* SDcard they booted from or to a separate USB stick was not even mentioned or clear. 2021-01-28 20:30:27 Hello71: you might have noticed, I started adding a label to the rpi issues 2021-01-28 20:33:09 ikke: not sure what you mean 2021-01-28 20:34:36 aha, i have reproduced the issue. copy on raspios image, delete all files from partition 1 then copy on alpine. result: failure to boot, ACT flash 7 times 2021-01-28 20:34:41 ikke: noticed that. There's 4 RPI issues currently open and they're all differing situations 2021-01-28 20:36:35 Hello71: so that's a run-from-RAM Alpine so I guess everything can be in the same FAT partition and work. Sounds like an issue with the config.txt or usercfg.txt contents 2021-01-28 20:36:57 no, it is the same. there is some problem with partition table or filesystem or somesuch 2021-01-28 20:37:07 in the config.txt file what the path to the kernel and initramfs files? 2021-01-28 20:37:44 what's "fdisk -l" / "parted print" or equivalent output? 2021-01-28 20:48:46 Hello71: if somehow the config.txt from Raspian/Raspios is getting left behind that would be problem - Alpine names the kernel and initramfs files different than Raspbian 2021-01-28 20:58:45 how to 'flash' alpine tarball on mmc https://arvanta.net/alpine/flash-rpi-zero/ this is for rpi zero 2021-01-28 20:59:51 (a lot of people use somewhat strange argument, other distro) 2021-01-28 21:06:18 Hello71: you there? Think I see an issue 2021-01-28 21:09:23 so there definitely is something wrong with the raspios filesystem. reformatting it with a clean mkfs.fat fixes everything 2021-01-28 21:09:34 Hello71: I see an issue 2021-01-28 21:09:36 but fsck.fat doesn't detect anything wrong 2021-01-28 21:09:53 sure, go ahead. 2021-01-28 21:11:01 I downloaded the 3.13.0 armv7 tarfile to have a look - contents of cmdline.txt don't look right to me, it does have either "root=" or "rootfs=" specified. Not sure if both required but I'd expect to see "root=/dev/mmcblk0p1" for example 2021-01-28 21:11:05 i enabled BOOT_UART but it doesn't print anything i don't already know 2021-01-28 21:11:44 no, that's not right. first, initramfs auto-detects the modloop device. but even if it was related to that, it doesn't explain the seven blinks or why it works after reformatting 2021-01-28 21:12:13 yeah, am looking at my notes on the mkfs.fat to see if anything jumps out 2021-01-28 21:13:32 minimal: this tarballs are intended to run-from-ram, not 'disk' 2021-01-28 21:14:16 Hello71: for my own images I run "mkfs.fat -F32" but don't think that option is strictly necessary 2021-01-28 21:14:45 mps: yeah, I have to keep reminding myself that, I've been running SYS setups for so long lol 2021-01-28 21:16:06 something like this https://arvanta.net/alpine/armhf-setup/ 2021-01-28 21:19:00 similar, no need to set the boot flag for the FAT partition, the RPI's bootloader looks for the 1st suitable partition 2021-01-28 21:21:10 Hello71: what size is the FAT partition? is it FAT32? FAT16? 2021-01-28 21:23:16 true, not needed. this is artefact from another SBC 2021-01-28 21:50:46 im tagging 3.13.1 now 2021-01-28 21:53:30 Hello71: one other thing, I've never (personally) had the kernel and initramfs files in a boot subdirectory of the FAT partition. I've only ever had them in the top-level/root of that FS - the commented for #12361 seem to imply having them in a subdir is an issue. Maybe try moving them (and updating config.txt references accordingly) ? 2021-01-28 21:53:41 sigh 2021-01-28 21:54:59 looking at a Raspbian/Raspios image I have handy it has the kernel and initramfs at the top-level too 2021-01-28 21:55:05 yes. 2021-01-28 21:59:22 there was a bit of a disconnect pre-3.13 in terms of how the tarball creation script put some RPI files and where some APK packaged files were actually placed (such that updating the RPI kernel packages wouldn't update those files) 2021-01-28 22:01:57 that's why for my own stuff (SYS mode images) I resorted to mounting the boot partition as /boot and then also bind-mounting it as /boot/dtbs-rpi or dtbs-rpi2 or dtbs-rpi4 depending on the module I was using 2021-01-28 22:08:11 Hello71: The docs at https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md make no mention of the kernel & initramfs args supporting a path (on other hand they don't say they don't support a path...) 2021-01-28 22:38:16 so i finally found the repo for rpios image generation: https://github.com/RPi-Distro/pi-gen 2021-01-28 22:38:30 and it turns out the only difference is they specify -n boot 2021-01-28 22:38:49 and apparently it doesn't work if the volume label is equal to the directory name 2021-01-28 22:43:34 ncopa: if you're still around, see ^ 2021-01-28 22:44:29 i moved boot directory to aaaa, works fine if volume label is boot, stops working if set volume label to aaaa 2021-01-28 22:45:37 odd thing is it still doesn't work with volume label aaaa and moving files to root, and it also doesn't work to specify ./filename 2021-01-28 22:48:53 Hello71: doh! In my own setup I do pass "-n boot" to mkfs.fat but (like I said) I've never tried using a boot subdirectory. 2021-01-28 22:49:22 for when the filenames are in the top-level I use the following config.txt entry: 2021-01-28 22:49:23 [pi3] 2021-01-28 22:49:23 kernel=vmlinuz-rpi2 2021-01-28 22:49:23 initramfs initramfs-rpi2 2021-01-28 22:49:31 so no "./", just the filename 2021-01-28 22:50:43 yes 2021-01-28 22:50:57 i was wondering if could do ./boot/file 2021-01-28 22:51:01 but i guess not 2021-01-28 22:52:16 the bootloader for the RPI is no flashable on models before the RPI4 so no chance of getting it fixed (I was involved in the early netboot trails and when they hit some switch-specific issues they said it wouldn't get fixed for some time and at considerable cost to them) 2021-01-28 22:52:26 s/trails/trials/ 2021-01-28 22:52:26 minimal meant to say: the bootloader for the RPI is no flashable on models before the RPI4 so no chance of getting it fixed (I was involved in the early netboot trials and when they hit some switch-specific issues they said it wouldn't get fixed for some time and at considerable cost to them) 2021-01-28 22:52:43 well this isn't in preboot 2021-01-28 22:53:03 its in bootcode.bin I guess 2021-01-28 22:53:54 which then could be updated 2021-01-28 22:54:25 Hello71_: on alpine tarballs kernel and initramfs are in /boot 2021-01-28 22:54:55 ncopa: why don't we mount mmc to /boot anyways? why is it a subdirectory 2021-01-28 23:00:19 Hello71: its not just the kernels, package raspberrypi-bootloader (and subpackages) also puts files in /boot that should be in the top-level of the FAT partition. 2021-01-28 23:01:25 however things need to cater for both run-from-ram (where its only using a single FAT partition for everything) and SYS mode where there would be 2 partitions. FAT32 for boot files and kernel, and EXT4 for rootfs 2021-01-28 23:08:47 yes, but i don't see how that's relevant 2021-01-28 23:09:43 Well it was related to your question "why don't we mount mmc to /boot anyways?". I wasn't quite sure what you meant by that 2021-01-28 23:11:08 https://gitlab.alpinelinux.org/alpine/aports/-/issues/12368 2021-01-28 23:13:25 damn buggy closed source software... 2021-01-28 23:13:25 the point being on a SYS setup the 2nd partition with EXT4 would be mounted as "/" with the 1st FAT32 partition then mounted as /boot. In the case of the run-from-ram there's only 1 partition being used (FAT32) so where you suggesting mounting it at both "/" and "/boot"? 2021-01-28 23:23:58 what? 2021-01-28 23:25:09 why sys part should be only ext4 2021-01-28 23:26:08 full native filesystem for Linux which supports typical fs features unlike FAT 2021-01-28 23:26:29 doesn't have to be only ext4, basically anything but FAT 2021-01-28 23:27:16 to repeat Hello71_s words 'damn buggy closed source software...' :) 2021-01-28 23:27:52 I think we don't ship closed software? 2021-01-28 23:28:08 mps: firmware files? 2021-01-28 23:31:22 meh, I expected this :) 2021-01-28 23:31:22 and again, 'I think we don't ship closed software!' 2021-01-28 23:31:22 Hello81: at least that's potentially/eventually fixable if reported to Raspberry Pi Foundation 2021-01-28 23:31:22 but, yes I know arguments, so don't need to hear again 2021-01-28 23:31:22 specifically buggy software here is bootcode.bin/start.elf in rpi 2021-01-28 23:31:22 s/Hello81/Hello71/ 2021-01-28 23:31:22 minimal meant to say: Hello71: at least that's potentially/eventually fixable if reported to Raspberry Pi Foundation 2021-01-28 23:32:47 heh, Hello71_ you become somewhat older :) 2021-01-28 23:32:47 mps: I'm sure this issue has given him a few grey hairs :-) 2021-01-28 23:32:47 minimal: and you?? ;) 2021-01-28 23:33:52 anyway, old rpis can be booted by u-boot and newer ones with uefi and these should be 'paths' to fixing booting 2021-01-28 23:34:04 that's my opinion 2021-01-28 23:35:00 mps: I was grey long before this :-) 2021-01-28 23:35:49 ehm, I'm getting some 2021-01-28 23:35:59 i'm not going to report it, there are already some hundreds of unreplied issues on github 2021-01-28 23:41:08 they reply to most meaningful ones 2021-01-28 23:41:31 close alpine github 2021-01-28 23:44:02 meh, i'm already tired of this problem. someone else can report if they want 2021-01-29 00:53:42 lot of rpi shit lately eh 2021-01-29 01:46:11 something is broken since 3.13.1, haven't figured out what yet, but my DomUs are unable to boot 2021-01-29 02:03:33 think you're going to have to be more specific 2021-01-29 02:17:35 I will be 2021-01-29 02:39:53 downgrading dom0 linux to 5.10.10 helped 2021-01-29 03:16:59 5.10.11 lts and virt work fine for domUs 2021-01-29 03:17:53 peculiar that 'apk -U upgrade' didn't upgrade my downgraded packages (linux-lts & zfs-lts) 2021-01-29 03:32:29 here are the error messages from trying to start a domU with 'xl create' http://paste.debian.net/1183160/ 2021-01-29 03:32:52 in the above case there are two disks backed by a couple of zvols 2021-01-29 03:36:13 I skimmed https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.11 but it's pretty big 2021-01-29 07:22:38 morning 2021-01-29 07:22:44 so linux 5.10.11 is broken? 2021-01-29 08:01:52 Hello71_> i moved boot directory to aaaa, works fine if volume label is boot, stops working if set volume label to aaaa 2021-01-29 08:02:00 can you add that info to the isse? 2021-01-29 08:02:33 it sounds like a weird bug in raspberry pi bootloader. I could not find the sources for rpi boot loader 2021-01-29 09:08:27 Could someone who knows RPI stuff review !15863 ? 2021-01-29 09:11:19 this should be closed 2021-01-29 09:12:04 user should make change in currently available pkg and not create separate one 2021-01-29 09:12:34 (but gitlab openness will kill alpine, sooner or later) 2021-01-29 09:15:00 Not sure if that can be done with the RPI stuff, since that package is built against the RPI API 2021-01-29 09:57:01 if I wanted to package something but I realised I packaged the wrong thing and I now have no use for it, should I drop the package? 2021-01-29 09:57:21 I wouldn't personally mind keeping it in aports but I also don't have any reason to keep it there 2021-01-29 09:58:51 Newbyte: I have similar dilemma for some pkgs, I think moving them to unmaintained and remove maintainer field is most proper 2021-01-29 09:59:36 but also remove is quite ok if no one ask for keep it 2021-01-29 10:00:17 imo, we have a bunch of pkgs which should be removed/moved 2021-01-29 10:04:02 I'll move it to unmaintained then, thanks 2021-01-29 11:07:36 Any python experts around who can help me get the quantiphy_eval package updated to v0.4? 2021-01-29 11:08:07 This is what I get if I try to build the release tarball after installing appropriate dependencies on Alpine: 2021-01-29 11:08:19 https://paste.debian.net/1183196/ 2021-01-29 11:09:01 I've installed: python3 py3-quantiphy py3-inform py3-sly py3-setuptools py3-pytest. py3-sly is a new package I'm in the process of packaging while trying to update quantiphy_eval 2021-01-29 11:36:58 ncopa: https://lore.kernel.org/xen-devel/20210129005129.GA2452@mail-itl/T/#ma8f4a2e5cb092c92dd6496142bb1f5145bed59ad 2021-01-29 11:42:32 omni: do you think we should backport that patch or waith for 5.10.12? 2021-01-29 11:49:22 ncopa: I'd say backport, before more people upgrade their dom0 kernel to 5.10.11-r0 2021-01-29 11:50:54 Think I've got to the bottom of my issue. The 'sly' repo on github doesn't have labels for the latest release. The current version of 'master' does appear to be correct however. Is there an accepted way of downloading a specific git commit when building an Alpine package? 2021-01-29 11:50:57 I haven't set up an environment to buil packages myself yet, but if it lands in edge first I could install it from there 2021-01-29 11:54:43 ncopa: it is closed source, as I complained about earlier 2021-01-29 11:55:29 sam_ claims that they reply to filed issues though so maybe it's worth a shot 2021-01-29 11:58:03 Cogitri, mps: there are several such issues open about libcec 2021-01-29 12:01:41 for some reason dabuild is using user 1000 group 1000 by default, running into all sorts of permission issues 2021-01-29 12:03:50 Anyone care to comment on this approach to packaging a specific github commit? https://paste.debian.net/1183207/ 2021-01-29 12:04:02 In particular look at source and builddir lines, which aren't pretty. 2021-01-29 12:04:39 i would if i know where to begin, adhawkins :) 2021-01-29 12:05:31 Due to there being not 'release' tags on the upstream git repo, I'm having to specify a particular commit to get that release. Wondering if that's the 'done' thing, and whether this is the best way to do it. 2021-01-29 12:05:38 I've submitted an issue upstream asking for tags. 2021-01-29 12:07:27 adhawkins: It's prefered to have proper releases from upstream 2021-01-29 12:07:35 so if upstream is willing to create tags, that's good 2021-01-29 12:08:13 adhawkins: the community/mirage/APKBUILD has a bunch of commit hash, is that what you're looking for? 2021-01-29 12:09:44 adhawkins: also the community/docker one 2021-01-29 12:21:45 Hello71_: I will look over weekend and try to understand these, but no promise. as yo wrote last night also I'm becoming 'tired' on these cec/rpi 2021-01-29 12:24:34 Interesting, GKH says that 5.10 lts support duration relies on support from others (meaning usage and testing) 2021-01-29 12:41:50 https://dev.gnupg.org/T5259 exploitable heap overflow in libgcrypt 1.9, not packaged in alpine β™₯ 2021-01-29 12:43:13 ncopa: in the meantime I opened an issue for others to find 2021-01-29 12:44:36 adhawkins: regarding your first issue, probably ask upstream 2021-01-29 12:45:14 regarding your second issue, generally (alpine or otherwise) it's better to refactor such "magic constants" out into separate variables 2021-01-29 12:45:35 especially considering that in this case you probably want to change it when new version 2021-01-29 12:45:48 e.g. _commit=06b92e3e735db55b2d53db488785b2acc9d655ac; etc 2021-01-29 12:51:38 jvoisin: mind creating an issue for it on gitlab? 2021-01-29 12:53:45 I don't have access to my account atm :/ 2021-01-29 13:25:47 Cogitri: can you have arch-specific makedepends? If so then I'd agree with mps that the rpi-specific stuff should be subpackages of existing libcec 2021-01-29 13:27:42 minimal: case "$CARCH" in x86_64) makedepends="$makedepends ..." ;; esac 2021-01-29 13:29:30 maxice8: cool. I'll add a comment to that effect in the MR 2021-01-29 13:32:03 Hello71_: Thanks for the tip about using a constant, now done. 2021-01-29 13:32:16 I've create an issue upstream to ask them to create tags for the releases. 2021-01-29 13:32:56 And it now builds in CI :) 2021-01-29 13:57:10 Anyone care to look over !17567 for me? Particularly interested in the py3-sly package and its use of a specific GitHub commit for the release files (no tags in upstream) 2021-01-29 14:28:12 ikke: Can you point me to the container the CI stuff uses to lint a MR? Figured it'd be a good idea to have that available locally as well as the CI build one. 2021-01-29 14:29:50 https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools 2021-01-29 14:30:15 ncopa: added that information to issue and filed github bug upstream 2021-01-29 14:30:35 Perfect, thanks ikke. Will see if I can get that working locally. 2021-01-29 14:46:37 ikke: Does /usr/local/bin/lint expect a list of aports to be available as stdin? 2021-01-29 14:47:42 Ah, got it I think ikke. You don't need to specify a command for this container, it runs the 'changed' and 'lint' stuff itself. 2021-01-29 14:57:53 Hey guys, is there a 'nice' way to use different versions for subpackages? i have a (vendor supplied) library + application bundle; i want to create a subpkg for the library; however the library has a different version then the binary. Can i put this somewhere in the tuple or is it _split() {pkgver="abc" default_libs}? 2021-01-29 15:04:33 I don't think we have a nice way to do that and that sounds really hacky in general to be honest 2021-01-29 15:38:05 it is hacky; but one zip; binary + library deliverable; but hacking it via a custom lib_split (with default_libs) is the way to go i suppose 2021-01-29 15:39:09 I suppose so, yes 2021-01-29 15:55:46 If any developer with merge access is around please take a look at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/87 2021-01-29 15:56:45 Until that's merged I'll have to use a custom doc() for gtksourceviewmm which is strongly discouraged according to the guide 2021-01-29 15:58:05 spent hours to sort out the screw up between gtksourceviewmm 3.21.3 and 3.91.1 2021-01-29 15:58:31 3.91.1 is actually internally 4.0 and produces xxx-4.0.so 2021-01-29 15:59:23 broke multiple builds depending on 3.x 2021-01-29 16:12:17 It requires a new abuild release and updating it in aports as well 2021-01-29 16:13:10 isn't 3.91.1 a preview release anyways ? 2021-01-29 16:13:50 ncopa: could you take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14218? 2021-01-29 16:13:58 yes, and it has been the latest version since 2018 2021-01-29 16:14:46 doesn't look like they'll be releasing 4.0 anytime soon 2021-01-29 16:54:18 hmm, on a new MR, the pipeline passed for x86+x86_64 but failed on others because it's missing a new dep (mm-common) 2021-01-29 16:54:47 mm-common was merged yesterday, does it take awhile before it's available for aarch64 and others? 2021-01-29 16:55:08 alexy: if the builders are stuck on something, then yes 2021-01-29 16:55:19 mm-common is on "noarch" 2021-01-29 16:55:22 ahh 2021-01-29 16:55:47 it will still be built for each specific arch 2021-01-29 16:58:25 Can someone review this sudo MR (backport for CVE-2021-3156 for 3.11): https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17614 2021-01-29 17:08:02 I've 'mechanically' backported the changes 2021-01-29 17:42:02 speaking of sudo, i think we'll have another local priv esc bug that needs to be patched 2021-01-29 17:42:36 CVE-2021-3347 was assigned 20 or so minutes ago, affects <=5.10.11, no patch from kernel.org yet though 2021-01-29 17:46:18 oh, fun 2021-01-29 17:50:31 oh gosh 2021-01-29 17:53:59 i'm not sure where the "local priv esacalation" comes from, haven't seen any working exploits or anything 2021-01-29 17:55:02 I really need to drive the point home we are not Arch Linux 2021-01-29 17:55:30 what's the point? 2021-01-29 17:55:44 we have automatic soname dependencies 2021-01-29 17:55:50 one doesn't need to add every library to depends= 2021-01-29 17:57:56 ah so that's what "noarch" means 2021-01-29 17:58:01 "not like arch linux" 2021-01-29 17:58:12 ACTION is already out 2021-01-29 18:01:25 I chuckled a bit 2021-01-29 21:54:23 are licenses generally assumed to be "-or-later" unless the author have stated otherwise? 2021-01-29 21:54:38 it should be specified in the headers 2021-01-29 21:55:07 hmm 2021-01-29 21:55:27 alexy_: check the source files themselves 2021-01-29 21:55:39 ok 2021-01-29 23:54:58 hm... https://alpinelinux.org/releases/ doesn't have all the columns of https://wiki.alpinelinux.org/w/index.php?title=Alpine_Linux:Releases&oldid=18285 2021-01-29 23:56:08 specifically, is 3.9 still supported for security 2021-01-29 23:56:56 as a practical matter it seems like those remaining 3.9 issues are not going to be fixed after 1.5 years of sitting in gitlab 2021-01-30 07:19:41 We need to deprecate that page, the releases are listed on the main web page now 2021-01-30 12:23:36 is the information provided at the (somewhat outdated) wikipage available elsewhere? 2021-01-30 12:23:47 like EoL etc 2021-01-30 12:24:52 omni: https://alpinelinux.org/releases/ 2021-01-30 12:25:41 I think that page should mention that community only has 6 months of support though 2021-01-30 12:26:24 oh, ok =) 2021-01-30 12:28:28 It does 2021-01-30 12:28:31 at the top 2021-01-30 12:30:24 there we go 2021-01-30 12:30:50 ikke: https://wiki.alpinelinux.org/w/index.php?title=Alpine_Linux:Releases&diff=18572&oldid=18285 2021-01-30 12:31:01 but you didn't answer my question 2021-01-30 12:32:05 Hello71_: ah, didn't get it was a question 2021-01-30 12:32:42 v3.9 2019-01-29 3.9-stable | 3.9.6 | 3.9.5 | 3.9.4 | 3.9.3 | 3.9.2 | 3.9.1 | 3.9.0 2020-11-01 2021-01-30 12:32:48 so officially, not anymore 2021-01-30 12:37:27 Just out of interest (and by no means a complaint!) but does someone just walk over the open MRs and process them? I've tended to 'pester' about the previous ones, but just leaving this one to be processed naturally. 2021-01-30 12:41:10 adhawkins: yes 2021-01-30 12:41:34 Normally it's not necessary to notify someone for every MR 2021-01-30 12:47:34 Yep, I'm trying to avoid becoming that guy who pesters every time he submits an MR :) 2021-01-30 12:47:47 Just wanted to get a rough feel for when I should expect it to get processed 'naturally'. 2021-01-30 12:48:42 1 day to 1 week is normal 2021-01-30 12:48:57 Ok, I'll keep an eye on it. 2021-01-30 12:49:00 Thanks ikke. 2021-01-30 12:58:18 !17026 2021-01-30 13:06:30 dalias, sh4rm4^bnc: it occurred to me that i may have been too harsh on xf86-video-intel previously. if it works without bugs for you, it's probably fine to keep using it. but any bugs, including freezing and crashing, seem to not be fixed by upstream for quite a few years now, and bugs are likely to increase since i think neither windows nor major linux distros use the low-level 2d accel 2021-01-30 14:32:51 and all that thanks to not producing a release 2021-01-30 16:49:08 Anyone care to review this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17614 2021-01-30 16:50:47 Unfortunately I don't know C 2021-01-30 16:50:48 !17614 2021-01-30 16:50:51 algitbot: ? 2021-01-30 16:51:14 ikke: what are other distros doing? 2021-01-30 16:52:25 similar things 2021-01-30 16:55:24 https://git.launchpad.net/ubuntu/+source/sudo/tree/debian/patches/ 2021-01-30 16:57:16 i mean ubuntu isn't a great source -.- 2021-01-30 16:57:35 no, I nkow 2021-01-30 16:57:37 why ? 2021-01-30 16:57:56 I rebased the patches myself, and compared it at least with what ubuntu did 2021-01-30 16:58:04 (because it's the exact same version) 2021-01-30 16:58:36 superficially looking looks ok, but I don't have time for deep analysis 2021-01-30 16:59:14 maxice8: ubuntu has terrible security. particularly terrible when it comes to patching 2021-01-30 16:59:18 (correctly) 2021-01-30 16:59:28 https://securitylab.github.com/research/Ubuntu-gdm3-accountsservice-LPE 2021-01-30 17:01:18 I don't see where debian has patched sudo 2021-01-30 17:05:02 seems debian did same 2021-01-30 17:06:02 according to their patch comments, just context changes 2021-01-30 17:07:02 i wonder if default_prepare should set patch -F0. i don't think other distros do though 2021-01-30 17:08:58 yes, when I backported, there were only context changes 2021-01-30 18:23:40 hello71_, *nod* 2021-01-30 18:23:52 i wish they'd fix the dri/modesetting driver then tho 2021-01-30 18:24:02 it should be possible to implement fast 2d primitives using the gpu 2021-01-30 18:24:06 they just.... don't 2021-01-30 18:33:20 yay now that i solved my udev problem, purged libinput and switched back to evdev 2021-01-30 18:33:25 and my mouse sensitivity is back right 2021-01-30 18:33:39 for some idiotic reason xf86-input-libinput has different scaling 2021-01-30 18:34:00 why is everything in this domain so awful?? 2021-01-30 18:34:40 the answer starts with free and ends with desktop.org 2021-01-30 18:37:28 i mean why would you make B that's supposed to replace A, but that breaks the most critical personalized part of the ux ?! 2021-01-30 18:39:03 I already answered that 2021-01-30 18:39:33 :) 2021-01-30 18:39:44 skarnet, did you find anything more about the time64 breakage? 2021-01-30 18:40:55 no, I just shaved the yak to the point I'm now able to investigate it, and intended to do it today, but life got in the way. I'll do that tomorrow or Monday. 2021-01-30 18:41:01 ook 2021-01-30 19:30:11 as i recall, the problem with evdev/synaptics is too much fragmentation in workarounds for bad hardware 2021-01-30 19:30:50 so it works great on specifically those input devices that were tested, but works poorly on everything else 2021-01-30 19:31:05 and it's impossible to add new features without breaking the workarounds 2021-01-30 20:05:03 ? 2021-01-30 20:09:03 fuck, since upgrading alpine firefox closes every few hours from oom :( 2021-01-30 20:09:15 i need to make a bigger swap partition i guess :( 2021-01-30 20:38:42 use jemalloc, that'll help 2021-01-30 21:38:45 iiuc from #musl sudo vulnerabilty is related to linux-pam 2021-01-30 21:41:20 i'm not sure if it depends on pam 2021-01-30 21:41:52 i recall seeing one conversation about it where it appeared that pam's fooling around with malloc/free was necessary to get the heap into an exploitable state 2021-01-30 21:42:29 aha 2021-01-30 21:47:30 but i dont know if that's true 2021-01-30 21:47:51 i have not analyzed it in detail because i dont run any systems affected by it :-p 2021-01-30 21:48:35 https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit does not mention PAM 2021-01-30 21:48:38 I run doas for (hm) long time 2021-01-30 21:49:42 and I do 'su - root' often 2021-01-30 21:50:25 doas had it's own vulnerability :) (though way less severe as sudo) 2021-01-30 21:52:41 yes, but what doesn't have them (except maybe djbnds) 2021-01-30 21:54:49 ikke, it doesn't go into detail about how to exploit the heap overflow afaict 2021-01-30 21:55:15 in order for a heap overflow to be useful it has to (1) reach into the data you want to clobber, and (2) not be caught before the clobbered data gets used 2021-01-30 21:55:34 right 2021-01-30 21:55:46 i'm not sure if you can arrange that without pam 2021-01-30 21:56:12 it seems unlikely that there's significant use of malloc/free that would let you setup an exploitable arrangement without complex library code running 2021-01-30 21:56:23 but it may be possible 2021-01-30 21:56:53 So you say sudo without pam (like by default on alpine) would not be easily exploitable? 2021-01-30 21:57:29 https://www.kalmarunionen.dk/writeups/sudo/ here is a detailled writed 2021-01-30 21:57:31 *writeup 2021-01-30 21:57:48 ikke, i say i don't know, but it's plausible that that's the case 2021-01-30 21:58:00 by default assume it is exploitable :) 2021-01-30 21:58:05 but it's plausible that it's not 2021-01-30 21:58:12 yes, that's a fair assumption 2021-01-30 22:03:27 heres PoCs https://github.com/stong/CVE-2021-3156 https://github.com/lockedbyte/CVE-Exploits/tree/master/CVE-2021-3156 2021-01-30 22:05:33 jvoisin, the writeup there is glibc-specific 2021-01-30 22:05:56 i wonder if anyone has a plausible one for musl-based system 2021-01-30 22:08:23 based on it i think it's sounding more and more plausible that you can't exploit this on musl 2021-01-30 22:08:48 anyway `sudoedit -s '\' $(python3 -c 'print("A"*1000)')` doesn't give me a crash 2021-01-30 22:08:55 because musl is not going to do a bunch of malloc+free for you 2021-01-30 22:09:47 nah. sudoedit complains it doesn't know -s as a switch 2021-01-30 22:13:17 meh 2021-01-30 23:37:35 ah, it gets easier to exploit actually: https://seclists.org/oss-sec/2021/q1/88 2021-01-31 18:22:11 https://lists.debian.org/debian-kernel/2021/01/msg00369.html 2021-01-31 20:34:48 can someone please merge !15326 ? 2021-01-31 20:36:26 backports of openjdk7 (!15298 and !15297) are also waiting for some time now 2021-01-31 20:39:50 thanks ikke for taking care of these MR :) 2021-01-31 20:47:38 bratkartoffel: np 2021-01-31 23:52:32 jvoisin: !17678 we prefer size optimization 2021-01-31 23:57:32 why does monit particularly need speed optimizations? 2021-01-31 23:57:52 the python one kind of makes sense pragmatically despite being semantically wrong 2021-01-31 23:58:19 yes, right question