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?