2021-01-01 07:51:16 <ikke> morning
2021-01-01 07:59:55 <mps> good morning and happy new year
2021-01-01 08:10:03 <maxice8> morning
2021-01-01 08:10:20 <maxice8> Didn't sleep so functionally useless
2021-01-01 10:12:31 <fcolista> Looks that Siemens is using Alpine...
2021-01-01 10:12:32 <fcolista> https://download.industrysoftware.automation.siemens.com/open-source/alpine-docker-Build-3.10.3.html
2021-01-01 10:14:40 <ncopa> morning
2021-01-01 10:24:26 <artok> morninä
2021-01-01 10:24:56 <artok> already first thing I write this year has typo
2021-01-01 10:26:58 <ikke> fun, I think mallocng finds more bad behavior
2021-01-01 10:33:55 <ikke> hmm, not sure if it's the application
2021-01-01 11:49:22 <nmeum> fcolista: they should upgrade to 3.12 though :D
2021-01-01 12:46:06 <fcolista> nmeum, :D
2021-01-01 12:48:25 <nmeum> sed -i unit-tests/Makefile \
2021-01-01 12:48:25 <nmeum> AinNero-e "/deptgt-delete_on_error/d"
2021-01-01 12:48:27 <nmeum> oops
2021-01-01 12:54:17 <AinNero> heh
2021-01-01 12:55:10 <AinNero> still better than all the hilights i got from people talking about the monero currency
2021-01-01 12:57:39 <ikke> 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 <ikke> https://tpaste.us/K5no
2021-01-01 13:03:43 <Cogitri> That's valac complaining, not g-i I think
2021-01-01 13:03:57 <Cogitri> And that's definitely not caused by that patch
2021-01-01 13:04:18 <ikke> Cogitri: the only diffence between it building and not building is adding that patch
2021-01-01 13:05:25 <Cogitri> Huh
2021-01-01 13:05:50 <ikke> Cogitri: my thoughts exactly
2021-01-01 13:05:58 <Cogitri> I really don't see how that'd cause valac to fail to compile the project
2021-01-01 13:07:35 <ikke> me neither
2021-01-01 13:08:28 <afontain_> does just `touch`ing the files create an error?
2021-01-01 13:08:55 <afontain_> it might use some binary cache?
2021-01-01 13:09:55 <ikke> afontain_: which file?
2021-01-01 13:10:11 <ikke> I use abuild -r every time, so it builds from scratch
2021-01-01 13:10:12 <afontain_> the files changed by the patch
2021-01-01 13:10:21 <afontain_> (if you remove the patch, that is)
2021-01-01 13:19:13 <ikke> that seems to be it
2021-01-01 13:19:32 <ikke> strange
2021-01-01 13:31:48 <ikke> I think it generates .h when a stamp file does not match
2021-01-01 13:32:41 <ikke> so they ship pre-generated header files that get rebuild if you touch the source
2021-01-01 13:33:24 <ikke> if I touch the stamp and the source file at the same time, it continues
2021-01-01 13:33:49 <ikke> Cogitri: any idea how I could those vala errors?
2021-01-01 13:39:11 <Cogitri> Sorry? I think that sentence is missing a few words 😅
2021-01-01 13:41:29 <ikke> resolve
2021-01-01 13:42:30 <ikke> This is the command that fails https://tpaste.us/oPyk
2021-01-01 13:44:28 <ikke> so it's passing those packages as --pkg flags
2021-01-01 13:53:17 <ikke> Cogitri: do you know what it looks for when you specify --pkg foo?
2021-01-01 13:55:30 <ikke> a .pc file apparently
2021-01-01 13:58:06 <ikke> or .vapi
2021-01-01 14:01:48 <Cogitri> Yes. You can specify additional dirs it looks in with --vapidir
2021-01-01 14:02:14 <Cogitri> They probably forgot to add --vapidir $SRCFOLDER since that common and config vapi are probably vendored by them
2021-01-01 14:02:23 <ikke> I think it's becuase gobject-introspection is missing
2021-01-01 14:02:28 <ikke> there are no .vapi files
2021-01-01 14:02:30 <Cogitri> as for libmsi-1.0, no clue what provides that to be honest
2021-01-01 14:02:42 <Cogitri> Ah, config and common are probably handwritten files
2021-01-01 14:02:45 <ikke> libmsi1.0 is part of the project
2021-01-01 14:02:58 <Cogitri> The config.vapi is like a config.h for C projects
2021-01-01 14:03:09 <ikke> It's not generated
2021-01-01 14:04:27 <ikke> now there is libmsi-1.0.vapi file
2021-01-01 14:05:57 <ikke> but common / config.vapi are still missing
2021-01-01 14:07:21 <ikke> sigh
2021-01-01 14:07:30 <ikke> still complaining about symbol Libmsi missing :(
2021-01-01 14:08:34 <ikke> FUN
2021-01-01 14:18:13 <ikke> Ah
2021-01-01 14:18:17 <ikke> found a clue
2021-01-01 14:18:19 <ikke> if VAPI
2021-01-01 14:18:25 <ikke> in the makefile
2021-01-01 14:22:56 <ikke> finally
2021-01-01 14:23:21 <ikke> hmm, config remains :(
2021-01-01 14:37:37 <ikke> Cogitri: is there something that would normally generate a config.vapi file?
2021-01-01 14:37:46 <ikke> I cannot find any reference
2021-01-01 14:38:31 <Cogitri> Nop, normally that's handwritten
2021-01-01 14:39:12 <ikke> uf
2021-01-01 14:39:30 <Cogitri> The file would usually just be
2021-01-01 14:39:30 <Cogitri> namespace Config {
2021-01-01 14:39:30 <Cogitri> ```
2021-01-01 14:39:30 <Cogitri>     public static string VERSION;
2021-01-01 14:39:30 <Cogitri>     // Some more static strings here for other things
2021-01-01 14:39:30 <Cogitri> }
2021-01-01 14:39:30 <Cogitri> ```
2021-01-01 14:39:43 <ikke> Yes, I found example
2021-01-01 14:39:47 <ikke> examples*
2021-01-01 14:39:54 <ikke> just wonder how upstream does it if the file is not there
2021-01-01 14:40:08 <Cogitri> Yup, that's weird indeed
2021-01-01 14:40:45 <ikke> They switched to meson in master
2021-01-01 14:41:45 <Cogitri> Wise choice
2021-01-01 14:56:52 <ikke> https://gitlab.gnome.org/GNOME/msitools/-/blob/master/config.vapi
2021-01-01 14:57:04 <ikke> they added it when they switched to meson :/
2021-01-01 15:06:22 <ncopa> Cogitri: i think i know how to reproduce the gnome-software issue
2021-01-01 15:06:40 <ncopa> just bump pkgrel on gnome-software and rebuild
2021-01-01 15:11:32 <Cogitri> Yes, the new meson version probably changed how pkgconfig files are generated
2021-01-01 15:11:44 <Cogitri> Have you tried the suggestion I posted on the issue?
2021-01-01 15:12:07 <ncopa> static: true? yes
2021-01-01 15:12:11 <ncopa> it didnt work
2021-01-01 15:12:24 <ncopa> manually adding all the deps did work though
2021-01-01 15:15:55 <ikke> Cogitri: ok, managed to get it to work now
2021-01-01 15:15:57 <ikke> Cogitri: thanks
2021-01-01 15:16:08 <ikke> I copied the config.vapi from the master branch
2021-01-01 15:35:53 <Cogitri> Okie 👍
2021-01-01 15:36:40 <ikke> the other issues disappeared when I did the full ./autogen.sh
2021-01-01 16:22:27 <mps> ncopa: why kernels have installkernel in makedepends
2021-01-01 16:45:05 <Hello71> it copies from arch/x86/boot/bzImage to /boot/vmlinuz
2021-01-01 16:46:11 <mps> I don't see it in abuild
2021-01-01 16:51:55 <Hello71> https://github.com/torvalds/linux/blob/master/arch/x86/boot/install.sh
2021-01-01 16:55:40 <mps> if [ -x /sbin/lilo ]; then
2021-01-01 16:55:53 <mps> :)
2021-01-01 16:56:36 <mps> no, I'm talking about installkernel in APKBUILD makedepends for linux-*
2021-01-01 16:57:58 <MY-R> isnt installkernel script for making modloop etc thing with rpi stuff?
2021-01-01 16:58:44 <mps>  /sbin/installkernel is script and it quite short to read
2021-01-01 16:59:04 <mps> it just copies few files
2021-01-01 16:59:51 <mps> I don't see where it is used in building kernels
2021-01-01 17:05:03 <MY-R> ah ye, sorry, mixed it with "update-kernel" ... my bad!
2021-01-01 17:06:38 <mps> np
2021-01-01 17:11:44 <Hello71> https://github.com/torvalds/linux/blob/master/arch/x86/boot/install.sh#L37
2021-01-01 17:13:25 <mps> is it used in alpine
2021-01-01 17:14:05 <Hello71> huh?
2021-01-01 17:23:46 <mps> I can't find that /sbin/installkernel is used anywhere
2021-01-01 17:24:24 <Hello71> it is used in install.sh
2021-01-01 17:24:26 <Hello71> as i said
2021-01-01 17:26:01 <mps> where?
2021-01-01 17:29:54 <Hello71> https://github.com/torvalds/linux/blob/master/arch/x86/boot/install.sh#L37
2021-01-01 17:31:25 <mps> huh, I'm not talking about linux install.sh, but about installkernel alpine pkg
2021-01-01 17:33:34 <mps> I don't see in APKBUILD definition of INSTALLKERNEL variable
2021-01-01 17:33:58 <mps> nor in /usr/bin/abuild
2021-01-01 17:47:31 <fcolista> it's only me that lxc-create for alpine fails with mknod: dev/zero: File exists ?
2021-01-01 17:47:42 <fcolista> usgin alpine template
2021-01-01 17:48:06 <fcolista> lxc-create -n test -t alpine
2021-01-01 17:48:20 <fcolista> lxc-4.0.5-r0
2021-01-01 17:48:31 <fcolista> edge
2021-01-01 17:48:45 <fcolista> lxc-templates-legacy-alpine-3.0.3-r1
2021-01-01 17:50:19 <Hello71> 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 <Hello71> 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 <mps> Hello71: right, and this is why I'm not sure we need it installkernel in makedepends
2021-01-01 19:02:50 <mps> I'm testing linux-elm build without it, and it works fine
2021-01-01 19:05:48 <mps> fcolista: looks like bug somewhere
2021-01-01 19:18:50 <Ariadne> fcolista: i use lxc-download now
2021-01-01 19:19:03 <Ariadne> fcolista: lxc-create -t download -- -a amd64 -d alpine -v edge
2021-01-01 20:08:34 <Hello71> mps: no, it is required
2021-01-01 20:13:40 <mps> Hello71: it can work without it but decided to keep it to be 'in-line' with linux-lts
2021-01-01 20:14:29 <Hello71> well i think it will not install to syslinux expected location
2021-01-01 20:19:18 <mps> for linux-elm it is not needed, because kernel instalation is specific on these chromebooks
2021-01-01 20:44:22 <Hello71> could be
2021-01-01 20:44:59 <Hello71> I think "correct" solution would be to make installkernel-elm
2021-01-01 20:45:16 <Hello71> but probably too much work
2021-01-01 20:53:17 <mps> yes
2021-01-01 21:25:03 <mps> HRio: merged
2021-01-01 22:43:04 <HRio> mps: big thanks!
2021-01-01 23:38:29 <mps> HRio: np
2021-01-02 12:06:00 <PureTryOut[m]2> !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 <maxice8> done
2021-01-02 12:10:01 <PureTryOut[m]2> Oh awesome, thanks for the quick reply!
2021-01-02 12:10:05 <ikke> :)
2021-01-02 12:10:23 <maxice8> Ikke, you still using mkmr and mgmr ?
2021-01-02 12:10:29 <ikke> maxice8: once in a while
2021-01-02 12:11:05 <ikke> I saw your note
2021-01-02 12:25:42 <ikke> 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 <PureTryOut[m]2> Sounds like it, huh. If pkgname doesn't equal the directory name, then yes that's a mistake
2021-01-02 12:27:43 <ikke>  :)
2021-01-02 12:40:07 <ikke> PureTryOut[m]2: what should happen with it?
2021-01-02 12:41:25 <PureTryOut[m]2> I'll make a MR to fix it
2021-01-02 12:42:16 <ikke> ok
2021-01-02 13:04:39 <PureTryOut[m]2> ikke: !16355
2021-01-02 13:05:14 <ikke> so they have both kitinerary and itinerary?
2021-01-02 13:06:16 <ikke> PureTryOut[m]2: 'kpublictransport-dev (no such package):"
2021-01-02 13:08:27 <PureTryOut[m]2> Wait for the builders to catch up
2021-01-02 13:08:39 <PureTryOut[m]2> that package hasn't appeared in the repos yet but is in aports
2021-01-02 13:08:57 <PureTryOut[m]2> And yes, itinerary depends on kitinerary. The former is an end-user application, the latter a library
2021-01-02 13:09:06 <PureTryOut[m]2> I get the confusion 😉
2021-01-02 13:09:24 <ikke> :)
2021-01-02 13:29:25 <ikke> built locally
2021-01-02 13:34:06 <ikke> I'll disable it on s390x
2021-01-02 13:34:28 <PureTryOut[m]2> 👍️
2021-01-02 13:35:30 <ikke> and mips64
2021-01-02 16:33:56 <ikke> PureTryOut[m]2: kgpg is failing on aarch64 and ppc64le, kosmindoormap is faiiling on x66
2021-01-03 14:37:18 <PureTryOut[m]2> !16388
2021-01-04 07:31:04 <ncopa> morning
2021-01-04 07:34:24 <Cogitri> Morning
2021-01-04 07:40:21 <Ariadne> hi
2021-01-04 07:42:02 <ncopa> seems like crystal built? i wonder if it was related the musl update
2021-01-04 07:45:43 <mps> musl is updated? didn't noticed. nice if crystal is fixed
2021-01-04 07:51:38 <ncopa> only mips64 is left now
2021-01-04 07:52:03 <ncopa> seems like all other arches are idle for 3.13
2021-01-04 07:54:33 <Cogitri> Hooray
2021-01-04 07:55:55 <mps> is 'freeze' planed on some date?
2021-01-04 08:01:30 <ncopa> we have been in a "soft freeze" for some time already
2021-01-04 08:01:48 <ncopa> i think we'll do rc1 today
2021-01-04 08:02:59 <mps> is that (rc1) some kind of freeze
2021-01-04 08:04:07 <mps> 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 <ncopa> so, what we want avoid now is breakages that slows us down
2021-01-04 08:07:53 <ncopa> 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 <ncopa> within reasonable time (not weeks)
2021-01-04 08:08:22 <Ariadne> i'm just waiting on dalias to tag 1.2.2
2021-01-04 08:08:28 <Ariadne> thats all for 3.13 :)
2021-01-04 08:09:40 <ncopa> looks like `convert` cannot generate png files on mips64
2021-01-04 08:10:31 <Ariadne> likely endianness
2021-01-04 08:11:52 <mps> !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 <mps> 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 <mps> but yes, fixes and bugs will be always around
2021-01-04 08:22:35 <ikke> morning
2021-01-04 08:24:44 <mps> ikke: \o
2021-01-04 08:29:34 <ikke> ncopa: PureTryOut[m]2 had an MR for kosmindoormap
2021-01-04 08:30:09 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12254#note_133404
2021-01-04 08:30:27 <mps> 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 <mps> s/checj/check/
2021-01-04 08:30:40 <alpine-meetbot> 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 <Ariadne> junk
2021-01-04 08:32:34 <mps> now trying more conservative build
2021-01-04 08:55:20 <ncopa> oh, i forgot to check for MRs
2021-01-04 08:56:30 <ncopa> mps: libpcap/tcpdump can be merged
2021-01-04 08:56:42 <ncopa> just remove the "draft" in the MR
2021-01-04 09:10:31 <mps> hmm, no more WIP, now it Draft :)
2021-01-04 09:10:35 <mps> removed
2021-01-04 09:13:22 <mps> and merged
2021-01-04 09:14:42 <ncopa> thanks
2021-01-04 09:15:31 <mps> np
2021-01-04 09:16:15 <mps> thank you for encouragement :)
2021-01-04 09:16:37 <ikke> mps: yes, gitlab feels 'Draft' is more easily understood and does not indicate you are working on it
2021-01-04 09:18:55 <mps> hmm, when the people stop to change words especially established ones and well understood
2021-01-04 09:19:51 <mps> will stop*
2021-01-04 09:20:45 <mps> oh yes, they want/need more commits to be hired :)
2021-01-04 09:37:09 <mps> is the gitlab stuck on something? I pushed new MR but it doesn't appears in web ui
2021-01-04 09:38:17 <ikke> Does it appear now?
2021-01-04 09:39:11 <mps> not yet
2021-01-04 09:43:28 <mps> would be 'git push --force mps' of help
2021-01-04 09:44:14 <ikke> force only works if there is something to push
2021-01-04 09:44:25 <ikke> Can you check if the branch is visible in your fork
2021-01-04 09:44:30 <mps> aha
2021-01-04 09:44:53 <mps> will now
2021-01-04 09:45:31 <mps> yes, it is https://gitlab.alpinelinux.org/mps/aports/-/tree/svxlink-move2community
2021-01-04 09:46:03 <ikke> Then you should be able to create an MR from there
2021-01-04 09:47:52 <mps> aha, I see
2021-01-04 09:48:11 <mps> thanks
2021-01-04 10:03:46 <mps> would be bpfmon of use in community for 3.13 release?
2021-01-04 10:04:00 <Ariadne> would be nice to have
2021-01-04 10:04:52 <mps> ok, will move after breakfast
2021-01-04 10:14:53 <tpanmajia> I ran glxgears and the window content stood still
2021-01-04 10:15:09 <tpanmajia> only when I resized the window did the gears move
2021-01-04 10:15:20 <tpanmajia> could anyone help with this?
2021-01-04 10:15:32 <tpanmajia> GL_RENDERER   = Mesa Intel(R) UHD Graphics 620 (WHL GT2)
2021-01-04 10:15:33 <tpanmajia> GL_VERSION    = 4.6 (Compatibility Profile) Mesa 20.0.7 (git-53b2b224dc)
2021-01-04 10:15:33 <tpanmajia> GL_VENDOR     = Intel
2021-01-04 10:16:30 <Ariadne> under what desktop, etc
2021-01-04 10:16:34 <tpanmajia> ok
2021-01-04 10:16:46 <ikke> note that #alpine-linux is a better channel for these kinds of questions
2021-01-04 10:17:06 <tpanmajia> UHD620, X.Org X Server 1.20.10, MATE 1.24.0, everything vanilla
2021-01-04 10:17:12 <tpanmajia> and no relevant configs changed
2021-01-04 10:17:37 <tpanmajia> 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 <tpanmajia> 
ACTION thinks it would be an actual bug...

2021-01-04 10:23:26 <fcolista> what's the policy about backporting a package from edge/testing to a stable release like 3.12 ?
2021-01-04 10:26:58 <ikke> I don't think we commonly do those kinds of backports
2021-01-04 10:32:09 <fcolista> ok, that is what I suspected...thx
2021-01-04 10:34:49 <fcolista> ikke, moving a package from testing to package needs a bump of pkgver?
2021-01-04 10:34:53 <fcolista> I always forget this...
2021-01-04 10:35:04 <ikke> No, not required
2021-01-04 10:35:22 <fcolista> ok, thanks!
2021-01-04 10:35:45 <ikke> (the only reason to do this would be to force an upgrade for some reason)
2021-01-04 11:10:29 <ncopa> 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 <ncopa> its better to backport a package than mix v3.12 + edge repos
2021-01-04 11:11:08 <ikke> yes, the latter is error prone
2021-01-04 11:12:01 <mps> I agree
2021-01-04 11:12:33 <mps> but we should be careful when backporting
2021-01-04 11:13:35 <ikke> yes, but adding new packages should be relatively harmless
2021-01-04 11:15:29 <mps> it should be, but again carefully
2021-01-04 11:18:21 <ncopa> +1
2021-01-04 11:19:01 <ncopa> \o/ mips64 builder is uploading 3.13
2021-01-04 11:19:11 <ncopa> we shoudl be able to do rc1 today
2021-01-04 11:22:57 <ikke> nice
2021-01-04 11:23:32 <mps> I wonder how crystal pass in builders but not in my dev lxc /o\
2021-01-04 11:23:49 <ncopa> good question
2021-01-04 11:23:56 <ncopa> did you update musl version?
2021-01-04 11:24:01 <mps> yes
2021-01-04 11:24:14 <mps> updated everything
2021-01-04 11:24:49 <mps> but ok, we can disable compiler check if it fail at final release build, I think
2021-01-04 11:25:50 <mps> I didn't got any answer from boehm gc developers not from crystal
2021-01-04 11:26:17 <ncopa> i dont think problem is in boehm gc
2021-01-04 11:26:30 <mps> maybe it is not
2021-01-04 11:27:36 <mps> we have this for long time #10918
2021-01-04 12:15:05 <tdtrask> ncopa: thanks for the merge
2021-01-04 12:18:40 <mps> too late for busybox upgrade?
2021-01-04 12:38:49 <ncopa> busybox upgrade? sounds risky. they tend to break stuff
2021-01-04 12:39:46 <tpanmajia> last-minute busybox upgrade might not be a good idea...
2021-01-04 12:40:03 <tpanmajia> one minor inconsistency would ruin something
2021-01-04 12:42:44 <mps> ncopa: also to me, current patches in aports need review. yes, after release
2021-01-04 12:48:25 <Hello71> tpanmajia: did you remove nomodeset from kernel command line
2021-01-04 12:48:58 <tpanmajia> Hello71: wait I didn't
2021-01-04 12:49:23 <tpanmajia> Hello71: any method for permanently remove this kernel param
2021-01-04 12:52:20 <mps> tpanmajia: yes, edit /etc/update-extlinux.conf
2021-01-04 12:53:33 <tpanmajia> mps: got it
2021-01-04 12:53:45 <tpanmajia> Hello71, mps: actually is grub managed by this config?
2021-01-04 12:54:48 <mps> or for grub /etc/default/grub
2021-01-04 12:55:02 <mps> but these questions are for #alpine-linux
2021-01-04 12:55:18 <tpanmajia> bruh
2021-01-04 12:55:45 <tpanmajia> mps: I didn't find nomodeset in /etc/default/grub though
2021-01-04 12:56:19 <mps> what says 'cat /proc/cmdline'
2021-01-04 12:57:07 <tpanmajia> mps: it has nomodeset
2021-01-04 12:57:25 <Hello71> alpine 10-linux.sh reads /etc/update-extlinux.conf
2021-01-04 12:57:44 <tpanmajia> Hello71: oh thx
2021-01-04 12:57:51 <tpanmajia> Hello71: it's sourced as a shell script
2021-01-04 12:58:00 <tpanmajia> going to restart
2021-01-04 12:58:21 <mps> but this is for syslinux, not grub afaik
2021-01-04 14:17:51 <ncopa> im gonna tag 3.13.0_rc1 now
2021-01-04 14:18:15 <ikke> \o/
2021-01-04 14:27:38 <ncopa> hum... i think i messsed up
2021-01-04 14:45:39 <ncopa> looks like things are broken
2021-01-04 14:46:25 <ikke> what kinds of things?
2021-01-04 14:46:46 <ncopa> Signing: /tmp/update-kernel.jMiiHO/boot/modloop-lts
2021-01-04 14:46:46 <ncopa> gzip: invalid magic
2021-01-04 14:46:46 <ncopa> tar: Error is not recoverable: exiting now
2021-01-04 14:46:46 <ncopa> tar: Child returned status 1
2021-01-04 15:46:30 <Cogitri> ncopa: Should we wait with !16405 until post 3.13?
2021-01-04 15:46:46 <Cogitri> Technically we should, but that does fix a lot of stuff
2021-01-04 15:46:58 <Cogitri> We could wait and then backport it if it's fine in edge too
2021-01-04 15:47:51 <Cogitri> Also, I only know learned about https://pkgs.alpinelinux.org/flagged, that's pretty nifty :D
2021-01-04 16:05:21 <ncopa> i dont mind merging !16405 once the first release candidate is out - as long as nothign breaks
2021-01-04 16:05:49 <ncopa> oh... i thikn i know why the release fails
2021-01-04 16:10:26 <nmeum> 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 <ncopa> probably ok. it wil not break armv6?
2021-01-04 16:26:35 <Cogitri> ncopa: Okie, I'll wait until the RC is fixed then, thanks
2021-01-04 16:57:54 <nmeum> 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 <mps> looks like musl discovered bug in dovecot, 'Error: mmap_anon(.test_file_cache, 4096) failed: Out of memory'
2021-01-04 17:01:14 <mps> and 'Error: mremap_anon(.test_file_cache, 8192) failed: Out of memory'
2021-01-04 18:32:01 <ncopa> i pushed rc2
2021-01-04 18:37:08 <mps> I see. does it means that the commits to edge don't go to 3.13 now
2021-01-04 18:56:18 <Cogitri> mps: They still do, there's no 3.13-stable branch yet
2021-01-04 18:57:40 <mps> huh, just created !16429 not sure should I merge it
2021-01-04 18:58:02 <mps> ncopa: ^
2021-01-04 18:58:09 <ikke> 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 <Cogitri> And we would want a minor upgrade + cve fixes in 3.13 anyway
2021-01-04 18:58:34 <ikke> yes
2021-01-04 18:59:07 <ikke> Just avoid doing upgrades that would affect a lot of packages
2021-01-04 18:59:12 <mps> it pass on my dev lxc and on CIs
2021-01-04 18:59:32 <mps> dovecot shouldn't affect any
2021-01-04 18:59:40 <mps> except self :)
2021-01-04 19:00:13 <ikke> And you can always revert if it's broken
2021-01-04 19:00:34 <mps> and pleasure is work on fixing bugs with dovecot upstream author (cmouse on #dovecot)
2021-01-04 19:01:34 <mps> no, everything looks ok, but I think some configs are changed in this 'major' release, which is normal
2021-01-04 19:31:15 <nmeum> merged riscv abuild patches
2021-01-04 19:31:17 <nmeum> *the
2021-01-04 19:33:59 <MY-R> 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 <MY-R> looks like working fine on rpi4 :) no issues with upgrade
2021-01-04 19:34:25 <artok> whee
2021-01-04 20:13:29 <MY-R> is it normal that there are two different versions of same package like this?
2021-01-04 20:13:33 <MY-R> https://pkgs.alpinelinux.org/packages?name=cpupower*&branch=edge&arch=x86_64
2021-01-04 20:14:36 <ikke> no, that's not normal
2021-01-04 20:15:16 <ikke> seems that for some reason, the old package was never removed
2021-01-04 20:15:34 <MY-R> oh, thought I rly have to install -openrc package manualy
2021-01-04 20:16:42 <MY-R> but then new one doesnt provide any cpupower.initd or cpupower.confd
2021-01-04 20:16:50 <ikke> hmm, seems like that cpupower-5.10.1-r0.apk is out-of-place
2021-01-04 20:17:37 <MY-R> that was first issue with rpi4... is slow because cpu frequencies are all time low
2021-01-04 20:18:08 <MY-R> without cpupower-openrc package of course
2021-01-04 20:18:10 <ikke> aha
2021-01-04 20:18:13 <ikke> I see what happened
2021-01-04 20:18:28 <ikke> there is a cpupower package, but also a cpupower subpackage from linux-tools
2021-01-04 20:18:38 <ikke> which is quite confusing :)
2021-01-04 20:18:38 <artok> linux-too..
2021-01-04 20:19:41 <MY-R> yeah
2021-01-04 20:19:47 <MY-R> now I see that too
2021-01-04 21:32:35 <MY-R> just in case, created issue #12272
2021-01-04 21:36:25 <ikke> MY-R: thanks
2021-01-04 21:39:46 <MY-R> :)
2021-01-04 22:39:45 <mps> hmm, hmmmm, #12272
2021-01-04 22:40:24 <mps> old one should be remove
2021-01-04 22:40:29 <mps> ?
2021-01-04 22:42:33 <mps> but what to do with nls.patch
2021-01-04 22:49:26 <MY-R> both provide same things if not count extra -openrc files
2021-01-04 22:50:15 <MY-R> hmm, need check maybe patch is in newer version already
2021-01-04 22:50:52 <mps> no, it is old version
2021-01-04 22:51:55 <MY-R> I mean maybe newer version was already patched by upstream
2021-01-04 22:52:34 <mps> cpupower-libs.patch
2021-01-04 22:56:22 <MY-R> dunno, cpupower from linux-tools working for me just fine
2021-01-04 22:57:17 <mps> other one is outdatet, from 5.4.xx
2021-01-04 22:57:26 <MY-R> yeah
2021-01-04 22:57:29 <mps> outdated*
2021-01-04 22:58:44 <MY-R> 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 <mps> i'm working on it, have to conclude how to add -openrc to subpkg
2021-01-04 22:59:19 <MY-R> I dont really need that init.d script, just added cpupower to local.d
2021-01-04 22:59:46 <mps> though maybe it should be set by end users in /etc/local.d/
2021-01-04 23:00:10 <mps> eh, you read my mind or I yours :)
2021-01-04 23:00:29 <MY-R> is some old gentoo script but working fine too
2021-01-04 23:01:06 <MY-R> heh
2021-01-04 23:02:16 <MY-R> 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 <mps> I think I got it, i.e. build cpupower-openrc from linux-tools
2021-01-04 23:02:52 <MY-R> 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 <mps> yes, that is what I do in some cases where need more control
2021-01-04 23:03:48 <MY-R> ye another reason why I have to say sorry to "runit" init
2021-01-04 23:04:18 <MY-R> 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 <skarnet> a supervision suite is not a service manager
2021-01-04 23:04:50 <skarnet> those do very different things
2021-01-04 23:05:01 <mps> runit can have 'need' iirc
2021-01-04 23:05:09 <skarnet> runit is not a service manager, which is why it yolos everything at the same time
2021-01-04 23:05:14 <skarnet> no
2021-01-04 23:05:39 <skarnet> 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 <mps> long time ago read about it and never tested, so probably you are right
2021-01-04 23:07:28 <skarnet> I know... a thing or two about that space
2021-01-04 23:08:26 <mps> I think so :)
2021-01-04 23:08:51 <MY-R> 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 <skarnet> MY-R: yup, and I'm the s6 guy
2021-01-04 23:09:19 <MY-R> :)
2021-01-04 23:10:06 <mps> MY-R: :D
2021-01-04 23:10:37 <mps> MY-R: !16438
2021-01-04 23:10:53 <mps> there is cpupower-openrc
2021-01-04 23:12:01 <MY-R> mps: sweet, so now 3.13 can be released ;)
2021-01-04 23:12:18 <MY-R> mps: thanks btw
2021-01-04 23:12:45 <mps> today you are in good mood :)
2021-01-04 23:13:24 <MY-R> :P
2021-01-04 23:13:29 <mps> but I have to go to bed, too late is now, good night
2021-01-04 23:13:38 <MY-R> sleep well!
2021-01-04 23:13:50 <mps> thanks. will try
2021-01-05 08:01:42 <ikke> morning
2021-01-05 08:01:47 <ncopa> morning
2021-01-05 08:06:51 <Cogitri> 👋
2021-01-05 08:17:09 <mps> good morning
2021-01-05 08:17:45 <mps> ncopa: !16438 duplicate package in community fix (or try to fix)
2021-01-05 09:08:53 <mps> a lot of changes of just released ppp, not sure should we upgrade for 3.13
2021-01-05 09:11:51 <mps> here is MR for review !16441
2021-01-05 09:21:24 <Ariadne> mps: hold until post-3.13
2021-01-05 09:31:13 <mps> makes sense, we already have CVE-2020-8597 in current in aports
2021-01-05 09:31:33 <mps> I fixed this cve
2021-01-05 09:37:58 <MY-R> 'vlan' package shouldnt be removed from .iso/tar.gz images since ifupdown-ng provide that function?
2021-01-05 09:43:30 <MY-R> and 'bridge' package too
2021-01-05 09:53:26 <MY-R> aaaand 'bonding'
2021-01-05 09:56:12 <MY-R> hmm those are pulled by meta pkg 'network-extras'
2021-01-05 10:05:07 <Ariadne> bridge and bonding should stay, vlan not.
2021-01-05 10:05:23 <Ariadne> ifupdown-ng has vlan built in, but we haven't switched to ifupdown-ng bridge/bond yet
2021-01-05 10:08:35 <MY-R> oh ok :)
2021-01-05 10:10:24 <ikke> Ariadne: I guess we can mention that in the release notes?
2021-01-05 10:12:41 <ikke> 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 <MY-R> 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 <ikke> It's because someone created that subpackage manually
2021-01-05 10:49:28 <ikke> so it does not have the auto install logic
2021-01-05 10:49:36 <ncopa> ugh... backporting osinfo-db is messy. its not just to add patches
2021-01-05 10:49:51 <MY-R> ikke: ye in 3.12 there wasnt -openrc package
2021-01-05 10:50:00 <ikke> I'm looking at edge
2021-01-05 10:50:27 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/mumble/APKBUILD#L94
2021-01-05 10:50:47 <ikke> I think the contents can just be replaced with `default_openrc`
2021-01-05 10:51:03 <mps> I can't remember, last time I touched murmur is cd745397ee4b343e63305461c9187035f48a67ba
2021-01-05 10:51:47 <MY-R> ye, Im just testing 3.13rc2 and that is second service which didnt start because "missing" -openrc :)
2021-01-05 10:53:16 <ikke> MY-R: something like this should work: https://tpaste.us/maNL
2021-01-05 10:54:47 <ncopa> fcolista: i added an MR for alpine https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/264
2021-01-05 10:54:54 <ncopa> to osinfo-db
2021-01-05 10:55:16 <MY-R> ikke: yeah
2021-01-05 10:55:41 <fcolista> ncopa, cool.
2021-01-05 10:55:53 <fcolista> I can babysit it
2021-01-05 10:56:56 <fcolista> I don't see aarch64
2021-01-05 10:57:07 <ncopa> because we dont provide any .iso
2021-01-05 10:57:21 <fcolista> ah that is for ISO only?
2021-01-05 10:57:33 <ncopa> osinfo only detects iso and disk images
2021-01-05 10:57:37 <fcolista> ok, I missed it
2021-01-05 10:58:04 <ncopa> its really difficult to test the osinfo-db
2021-01-05 10:58:26 <ncopa> its not just to create patches to community/osinfo-db
2021-01-05 10:58:43 <fcolista> dockerize the apk and test against the new-iso?
2021-01-05 10:58:58 <ncopa> no
2021-01-05 10:59:07 <fcolista> apk containing the support of new alpine versions
2021-01-05 10:59:29 <ncopa> the genereated db does not include the makefile so the patched .xml.in is not included in .apk
2021-01-05 10:59:52 <ncopa> so im runnining make, and uploading the tarball to dev.a.o
2021-01-05 11:00:07 <ncopa> they dont do tags in their git repo either
2021-01-05 11:00:39 <ncopa> so basically, we need get things upstream to be able to get the data
2021-01-05 11:01:14 <fcolista> ok
2021-01-05 11:01:26 <ncopa> we should also add tests to upstream
2021-01-05 11:01:44 <ncopa> there is a script for that in scripts/
2021-01-05 11:02:14 <ncopa> https://gitlab.com/ncopa/osinfo-db/-/blob/master/scripts/osinfo-db-add-iso.py
2021-01-05 11:02:18 <fcolista> we can do something like this, for alpine:
2021-01-05 11:02:18 <fcolista> https://gitlab.com/libosinfo/osinfo-db/-/blob/master/scripts/updates/nixos.py
2021-01-05 11:02:23 <ncopa> yeah
2021-01-05 11:02:58 <ncopa> 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 <fcolista> btw, libvirtd for 3.13 is not fixed yet
2021-01-05 11:04:13 <fcolista> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12007#note_119129
2021-01-05 11:04:56 <ncopa> does it still happen with 3.13?
2021-01-05 11:05:25 <ncopa> its kind of expected with 3.12, which does not work with malloc after fork
2021-01-05 11:05:40 <ncopa> and qemu does alot of that
2021-01-05 11:06:05 <ncopa> 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 <fcolista> 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 <ncopa> finally..
2021-01-05 11:08:12 <ncopa> $ osinfo-detect ~/Downloads/alpine-virt-3.13.0_rc2-x86_64.iso
2021-01-05 11:08:12 <ncopa> Media is bootable.
2021-01-05 11:08:12 <ncopa> Media is an installer for OS 'Alpinelinux 3.13 Virtual (x86_64)'
2021-01-05 11:08:33 <fcolista> \0/
2021-01-05 11:08:40 <fcolista> <lunch>
2021-01-05 11:08:42 <ncopa> we need to get it upstreamed
2021-01-05 11:09:07 <fcolista> so we needto wait for them to merge your patches
2021-01-05 11:10:30 <ncopa> i think they will request more patches with tests
2021-01-05 11:10:34 <ncopa> before they merge
2021-01-05 11:10:52 <ncopa> but lets see
2021-01-05 11:11:23 <ncopa> i'm glad if you can try follow it up in the future
2021-01-05 11:11:38 <ncopa> make sure that osinfo-detect works on our images
2021-01-05 11:11:53 <ncopa> i think we may want add back the virtio devices for alpine too
2021-01-05 11:14:19 <ncopa> 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 <ncopa> actually, i should follow upt this time
2021-01-05 11:16:54 <Ariadne> 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 <Ariadne> oh virt
2021-01-05 11:20:57 <mps> 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 <ncopa> fcolista: maybe we should add aarch64 to there
2021-01-05 11:22:06 <clandmeter> ncopa: ping
2021-01-05 11:22:21 <clandmeter> ah he is here already :)
2021-01-05 11:22:32 <clandmeter> ncopa: did we set repos already to https?
2021-01-05 11:23:13 <clandmeter> by default i mean
2021-01-05 11:23:16 <ikke> clandmeter: doesn't that depend on what mirror is selected from mirrors.a.o?
2021-01-05 11:23:43 <ikke> for docker, we did
2021-01-05 11:23:47 <clandmeter> does it?
2021-01-05 11:23:56 <clandmeter> does it not auto select http?
2021-01-05 11:24:16 <ikke> maybe, I don't know how it behaves when there is both http and http(s)
2021-01-05 11:24:24 <ikke> s/(s)/s
2021-01-05 11:24:24 <alpine-meetbot> 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 <clandmeter> im asking because on for instance on linode it is still using http
2021-01-05 11:24:48 <clandmeter> 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 <clandmeter> so updating indexes is slow on http
2021-01-05 11:26:12 <clandmeter> and now that dl-cdn has https support, i think we could make it the default.
2021-01-05 11:27:10 <ikke> clandmeter: It uses this list: https://mirrors.alpinelinux.org/mirrors.txt
2021-01-05 11:27:45 <ikke> so we need to fix alpine-mirrors to return https when available
2021-01-05 11:28:42 <ikke> But I'm wondering what you mean with "updating indexes is slow on http"
2021-01-05 11:34:36 <clandmeter> apk update
2021-01-05 11:35:47 <ikke> is that a libfetch issue?
2021-01-05 11:35:53 <ikke> I wonder how https can be faster
2021-01-05 11:36:29 <ncopa> i think we use https by default for docker at least
2021-01-05 11:36:35 <ikke> yes, we do
2021-01-05 11:36:43 <ikke> on edge, not yet on 3.12
2021-01-05 11:37:05 <ncopa> i thiknw e shoudl use https by default everywhere
2021-01-05 11:37:28 <ncopa> i have a feeling that there are intecepting proxies that injects stuff when using http
2021-01-05 11:39:26 <dne> 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 <ikke> clandmeter: https://gitlab.alpinelinux.org/alpine/infra/mirror-status/-/merge_requests/4
2021-01-05 11:56:11 <ikke> (untested)
2021-01-05 12:08:57 <ncopa> 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 <ncopa> similar to this: https://github.com/alpinelinux/docker-alpine/blob/master/fetch-latest-releases.lua
2021-01-05 13:04:02 <fcolista> ncopa, I can do that
2021-01-05 13:04:08 <fcolista> (back now from lunch)
2021-01-05 13:35:04 <Hello71> 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 <minimal> 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 <ncopa> minimal: thanks for the review. will update
2021-01-05 18:17:25 <nmeum> PureTryOut[m]: kclock currently fails to build on the builders
2021-01-05 18:17:35 <nmeum> just FYI
2021-01-05 18:19:44 <PureTryOut[m]2> 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 <nmeum> > No rule to make target 'src/org.kde.kclockd.KClockSettings.xml', needed by 'src/kclock/kclocksettingsinterface.cpp'.
2021-01-05 18:20:28 <nmeum> could be a parallel build issue
2021-01-05 18:20:45 <nmeum> not urgent either way :D
2021-01-05 19:08:09 <ncopa> 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 <ncopa> make[3]: Leaving directory '/home/ncopa/aports/main/pcre/src/pcre-8.44'
2021-01-05 19:08:18 <ncopa>  /usr/lib/libgcc_s.so.1: file not recognized: file format not recognized
2021-01-05 19:08:18 <ncopa> make[2]: *** [Makefile:1538: install-libLTLIBRARIES] Error 1
2021-01-05 19:08:18 <ncopa> libtool:   error: error: relink 'libpcreposix.la' with the above command before installing it
2021-01-05 19:08:18 <ncopa> collect2: error: ld returned 1 exit status
2021-01-05 19:08:42 <ncopa> looks like  /usr/lib/libgcc_s.so.1 (not from sysroot) gets pulled in for some reason
2021-01-05 19:12:06 <Hello71> at a guess, it's "libtool sucks" :p
2021-01-05 19:15:42 <Cogitri> Probably :D
2021-01-05 19:16:46 <dalias> :/
2021-01-05 19:16:59 <dalias> the host environment is leaking into the build somehow
2021-01-05 19:19:30 <ncopa> yeah. i wonder how/why
2021-01-05 19:20:06 <ncopa> i "fixed" brotli package by changing to cmake
2021-01-05 19:22:02 <ncopa> i suppose i could use slibtool
2021-01-05 19:25:00 <dalias> does it not know you're cross compiling?
2021-01-05 19:30:21 <ncopa> it should yes
2021-01-05 19:31:42 <ncopa> 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 <ncopa> -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 <ncopa> it knows, the --sysroot is there
2021-01-05 19:32:10 <dalias> is the tuple the same as host tho?
2021-01-05 19:32:29 <dalias> 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 <ncopa> no, this is on an x86_64 machine
2021-01-05 19:32:45 <dalias> weird
2021-01-05 19:32:58 <dalias> how did -rpath /usr/lib get there?
2021-01-05 19:33:15 <ncopa> i think libtool adds it
2021-01-05 19:38:30 <ncopa> what is pulling li libgcc_s though?
2021-01-05 19:45:28 <ncopa> + eval 'cmd="$CC' -shared '$pic_flag' '$libobjs' '$deplibs' '$compiler_flags' '$wl-soname' '$wl$soname' -o '$lib"'
2021-01-05 19:45:28 <ncopa> + 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 <ncopa> + IFS='
2021-01-05 19:45:50 <ncopa> it adds -L/usr/lib
2021-01-05 19:46:00 <ncopa> i wonder what does that and how to prevent it to
2021-01-05 19:50:52 <iggy> 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 <ikke> It should be GPL
2021-01-05 20:01:58 <ncopa> ok, its the -rpath thingy that causes the problem
2021-01-05 20:02:05 <ncopa> now i wonder where the -rpath comes from
2021-01-05 20:04:47 <ncopa> 368:am_libpcreposix_la_rpath = -rpath $(libdir)
2021-01-05 20:06:32 <Hello71> 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 <iggy> Hello71: I think alpine generally uses -Os
2021-01-05 20:09:47 <Hello71> should be same
2021-01-05 20:34:39 <ikke> Hello71: Ok, I mostly just write the things I catch being mentioned here
2021-01-05 20:36:53 <ikke> Hello71: thanks for fixing up the release notes
2021-01-05 21:05:24 <ikke> fun, docker-compose on 3.12 is broken
2021-01-05 21:16:37 <Cogitri> Python stuff?
2021-01-05 21:19:35 <ikke> yeah, it uses platform.linux_distribution(), which has been removed
2021-01-05 21:19:46 <ikke> https://github.com/docker/compose/commit/a62a1e1d6273d1b2021b072603ee9ffc86afc5c5
2021-01-05 21:19:50 <ikke> backporting that
2021-01-05 21:21:52 <Cogitri> Yuck
2021-01-05 21:22:26 <ikke> It has been deprecated since python 3.6 already
2021-01-05 21:24:25 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16483
2021-01-05 21:28:17 <ikke> I'm yakshaving an adjustment to CI to skip uploading the artifacts when they are too large
2021-01-05 21:29:00 <ikke> 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 <Cogitri> That'd still be nice to have :)
2021-01-05 21:30:02 <ikke> ok
2021-01-05 21:30:21 <ikke> Trying to remember why I did not push that yet
2021-01-05 21:30:26 <Cogitri> Thanks for looking into it
2021-01-05 21:30:43 <Cogitri> Heh
2021-01-05 21:31:36 <Cogitri> 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 <Cogitri> Just that it's WIP
2021-01-05 21:32:14 <ikke> ok
2021-01-05 21:32:34 <ikke> Well, I'm working on CI for that part as well
2021-01-05 21:34:46 <Cogitri> CI for the CI?
2021-01-05 21:35:04 <ikke> For that docker image
2021-01-05 21:35:09 <ikke> testing the build.sh script
2021-01-05 21:35:42 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/jobs/286276
2021-01-05 21:36:19 <ikke> 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 <ikke> It's turtles, all the way down
2021-01-05 22:05:17 <ikke> Cogitri: it worked now :) https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/jobs/286416
2021-01-05 22:29:29 <Ariadne> Hello71: i'll merge it later today
2021-01-05 22:37:44 <Hello71> ok
2021-01-06 07:53:34 <ncopa> good morning!
2021-01-06 07:55:22 <Cogitri> Morning
2021-01-06 07:56:49 <ncopa> rust fails to build from scripts/bootstrap.sh
2021-01-06 07:57:11 <ncopa> Assembling stage1 compiler (aarch64-alpine-linux-musl)
2021-01-06 07:57:11 <ncopa> Building stage1 std artifacts (aarch64-alpine-linux-musl -> x86_64-alpine-linux-musl)
2021-01-06 07:57:11 <ncopa> 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 <Cogitri> Ah, did someone adjust the rust APKBUILD to actually be cross-compileable ?
2021-01-06 07:58:39 <Cogitri> I think Ariadne tried but gave up for the time being because of some linker errors
2021-01-06 08:02:02 <Cogitri> 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 <ikke> sorry, no
2021-01-06 08:02:51 <ikke> not yet
2021-01-06 08:03:04 <ikke> Will try to finish it tonight
2021-01-06 08:03:11 <ikke> that was just a CI job for a feature branch
2021-01-06 08:03:59 <Cogitri> Oh okay, no need to rush, thanks for working on it :)
2021-01-06 08:07:51 <ncopa> Ariadne: do you mind take maintainership of libtls-standalone again? #11695
2021-01-06 08:11:50 <Ariadne> ncopa: sure
2021-01-06 09:44:12 <ncopa> thanks!
2021-01-06 09:56:53 <ncopa> hum, xorg-server moved to community. setup-xorg-base no longer works
2021-01-06 09:57:07 <ncopa> setup-xorg-base needs to add community repo
2021-01-06 09:57:22 <ncopa> or should we add community repo by default?
2021-01-06 10:02:09 <Cogitri> Sounds good to me, most users will want it anyway
2021-01-06 10:03:14 <ncopa> I think it might be better to not enable community by default
2021-01-06 10:03:28 <ncopa> so that you by default, you have 2 years support
2021-01-06 10:03:43 <ncopa> if you manually modify it, you only get 6 months support
2021-01-06 10:04:15 <ikke> And setup-xorg-base could ask to add the community repo
2021-01-06 10:04:42 <ncopa> i think it shouldnt ask. i think it should just do it
2021-01-06 10:05:09 <ikke> Should it silently add the community repo with the privision that you just mentioned?
2021-01-06 10:05:13 <ikke> provision
2021-01-06 10:06:12 <ncopa> 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 <ikke> That assumes the person who runs it is aware of that fact
2021-01-06 10:06:57 <ikke> Good thing to mention in the release notes, that xorg has moved
2021-01-06 10:06:57 <ncopa> the user will see the apk update line
2021-01-06 10:07:04 <ncopa> but yeah. its a good point
2021-01-06 10:07:40 <ncopa> my thinking is, you get 2 year support by default, unless you install xorg
2021-01-06 10:10:41 <artok> telling that on setup-xorg-base startup wouldn't hurt "This will add community repo. See: <url> for details"
2021-01-06 10:11:29 <ncopa> yeah
2021-01-06 10:13:59 <ikke> 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 <ncopa> 👍
2021-01-06 10:36:05 <maxice8> db is still not removed, just deprecated
2021-01-06 10:36:52 <ikke> maxice8: feel free to adjust
2021-01-06 10:38:49 <ncopa> i think we also re-enabled busybox smtp
2021-01-06 10:39:11 <ncopa> im testing xfce install in a vm. seems to work pretty nice
2021-01-06 10:39:31 <ikke> ncopa: so sendmail?
2021-01-06 10:39:51 <ncopa> 3e2e759e8b3a6e05e81daabba4657d1f70813ff7
2021-01-06 10:39:58 <ikke> ok
2021-01-06 10:40:25 <ikke> updated
2021-01-06 10:40:28 <ncopa> i updated the wiki
2021-01-06 10:40:29 <ncopa> :)
2021-01-06 10:40:34 <maxice8> updated
2021-01-06 10:41:18 <ikke> 👍
2021-01-06 10:41:39 <ncopa> 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 <mps> ncopa: yesterday I upgraded xfce on my daughter x86_64, works ok except pool-tumblerd segfaults
2021-01-06 10:45:51 <ncopa> mps: file an issue for that
2021-01-06 10:46:32 <ncopa> 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 <mps> 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 <mps> I'm in mid of backporting some packages for my servers, so too busy
2021-01-06 10:49:08 <ncopa> idea with filing issue is to let someone else debug and fix
2021-01-06 10:50:10 <mps> you think I will not try to fix it if I make bug report :)
2021-01-06 10:52:31 <mps> 'abuild rootpkg' doesn't work if there are user and/or groups defined
2021-01-06 10:57:29 <ncopa> https://wiki.alpinelinux.org/wiki/Xfce_Setup#Allowing_shut_down_and_reboot recommends uninstall elogind?
2021-01-06 11:11:49 <Cogitri> Probably some user not knowing about polkit-elogind
2021-01-06 11:12:18 <Cogitri> 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 <Cogitri> Not sure if we can make apk install polkit-elogind when installing elogind and polkit is installed?
2021-01-06 11:13:07 <Cogitri> Maybe we should add a blocker on ck2 for elogind too
2021-01-06 11:14:42 <ncopa> i updated the wiki
2021-01-06 11:14:59 <ncopa> also with a new screenshot of xfce 4.16 :)
2021-01-06 11:16:25 <Cogitri> 👌
2021-01-06 11:17:19 <ncopa> im gonna test rpi now
2021-01-06 11:17:48 <ncopa> 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 <ncopa> i dont think it would be too difficult
2021-01-06 11:20:21 <mps> here is how I make mmc for it http://arvanta.net/alpine/flash-rpi-zero/
2021-01-06 11:22:48 <ncopa> idea is to create a alpine-rpi.*.img so you can simply use dd
2021-01-06 11:23:38 <ncopa> 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 <mps> yes, I understood you
2021-01-06 11:24:06 <mps> like Armbian
2021-01-06 11:24:36 <ncopa> i believe that is how most other distros out there does it
2021-01-06 11:25:18 <ikke> alarmpi used to do that, but they switched to tar files
2021-01-06 11:25:34 <ikke> https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-4
2021-01-06 11:25:59 <mps> alarm (Arch) use tarballs for all arms, iirc
2021-01-06 11:26:03 <ikke> yes
2021-01-06 11:26:11 <ikke> they used to have raw images
2021-01-06 11:26:23 <mps> to me this looks better than images
2021-01-06 11:28:44 <mps> user can choose FS type, size and other things when making/flashing mmc
2021-01-06 11:35:15 <ncopa> ok. I'm not gonna spend time on it then
2021-01-06 11:35:24 <ncopa> tarballs are convenient
2021-01-06 11:35:57 <skarnet> except when you don't have access to a full system to install it
2021-01-06 11:36:31 <skarnet> dd is easier than prepare + untar
2021-01-06 11:36:41 <mps> imo, tarballs are more flexible. only what we are missing is some guides
2021-01-06 11:37:06 <ncopa> skarnet: thats why i brought it up, dd is easier for user, tarballs are easier for us
2021-01-06 11:37:18 <mps> that is what I started to write on above link/s
2021-01-06 11:37:34 <skarnet> #whynotboth
2021-01-06 11:37:43 <ikke> skarnet: my thoughts
2021-01-06 11:37:53 <mps> human resources
2021-01-06 11:38:03 <ikke> I don't think these images are that big?
2021-01-06 11:38:34 <ncopa> 89MB
2021-01-06 11:38:44 <ncopa> i'd prefer not do both
2021-01-06 11:38:51 <ikke> ok
2021-01-06 11:38:54 <mps> images could be made small, and users will ask 'why you made so small FS'
2021-01-06 11:39:28 <ikke> mps: that only matters for a disk setup, right?
2021-01-06 11:40:10 <mps> not only this, you know that users want 'different' setups
2021-01-06 11:41:59 <ncopa> 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 <ncopa> and linux
2021-01-06 11:43:43 <mps> I think so
2021-01-06 11:44:17 <mps> do not have much experience with macos nor windows
2021-01-06 11:44:22 <ncopa> 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 <ncopa> so i'd prefer only do one
2021-01-06 11:45:24 <mps> also I
2021-01-06 11:46:19 <mps> 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 <Cogitri> ncopa: I think most distros use a img.xz
2021-01-06 11:49:59 <skarnet> 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 <skarnet> I had never installed a rpi before and Alpine gave exactly *zero* hint on how to do this
2021-01-06 11:50:37 <skarnet> and I didn't want to invest any time in this
2021-01-06 11:50:42 <skarnet> debian was the easy way
2021-01-06 11:51:11 <skarnet> 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 <HRio> lol for me its the inverse
2021-01-06 11:51:49 <HRio> really like the alpine way
2021-01-06 11:52:01 <skarnet> the lack of documentation incited you to install Alpine? now that's something else
2021-01-06 11:52:15 <HRio> no thats is not an image
2021-01-06 11:52:40 <HRio> just a tar.gz to unpack on the first partion of the microSD
2021-01-06 11:52:48 <HRio> I can partition how I like before
2021-01-06 11:52:58 <skarnet> yes
2021-01-06 11:53:13 <HRio> I the distro makes does not choose for me\
2021-01-06 11:53:22 <skarnet> 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 <HRio> s/makes/makers/
2021-01-06 11:53:23 <alpine-meetbot> HRio meant to say: I the distro makers does not choose for me\
2021-01-06 11:53:34 <skarnet> "unpack that .tar.gz on the first partition of the microSD"
2021-01-06 11:53:39 <skarnet> that would help
2021-01-06 11:54:00 <skarnet> this certainly seems obvious to you
2021-01-06 11:54:09 <skarnet> I can assure you that it is NOT obvious to a lot of people
2021-01-06 11:55:50 <HRio> 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 <skarnet> I probably wouldn't care
2021-01-06 11:56:09 <mps> skarnet: would something like this help you http://arvanta.net/alpine/flash-rpi-zero/
2021-01-06 11:56:39 <skarnet> mps: sorry, but no
2021-01-06 11:57:04 <skarnet> I don't trust scripts from the Internet that come with no context
2021-01-06 11:57:29 <mps> I didn't meant to run script blindly
2021-01-06 11:57:50 <mps> more as a hints
2021-01-06 11:58:08 <skarnet> 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 <skarnet> throwing scripts at them with "use the source Luke" is not it
2021-01-06 11:58:35 <skarnet> proper documentation and tutorials would be better
2021-01-06 11:59:01 <skarnet> yes, it's harder
2021-01-06 11:59:09 <skarnet> and I'm one to talk because I'm terrible at writing tutorials
2021-01-06 11:59:11 <mps> again, human resources
2021-01-06 11:59:31 <skarnet> you mean the human resources that we love to spend arguing on irc instead of doing productive things?
2021-01-06 11:59:36 <ikke> One of the hardest things about documentation is makin sure they are kept up-to-date
2021-01-06 12:00:10 <skarnet> true
2021-01-06 12:00:13 <mps> yes, we need some kind of relaxation, and irc is good one :)
2021-01-06 12:00:32 <ikke> I'm right now doing productive things, while on IRC :)
2021-01-06 12:02:30 <mps> IRC is productive and funny at same time, though depends on ones POV
2021-01-06 12:05:04 <afontain_> the arch linux arm install instructions may be a good inspiration https://archlinuxarm.org/platforms/armv7/ti/beagleboard
2021-01-06 12:05:37 <ikke> yes, already linked to the rpi4 one
2021-01-06 12:05:41 <mps> afontain_: they are for me already
2021-01-06 12:06:40 <mps> I'm preparing guide for chromebook and think I will take some 'things' from alarm
2021-01-06 12:07:29 <mps> btw, alarm guides helped me to install alpine on 3 chromebooks three years ago
2021-01-06 12:07:47 <mps> three different*
2021-01-06 12:08:05 <mps> hmm, 3 different*
2021-01-06 12:11:17 <afontain_> ikke: is your last message about arch arm?
2021-01-06 12:11:33 <afontain_> if then, sry, I must have missed it in the backlog
2021-01-06 12:11:33 <ikke> yes
2021-01-06 12:15:30 <artok> just wonder how long https://wiki.alpinelinux.org/wiki/Raspberry_Pi has been there...
2021-01-06 12:16:07 <ikke> " 20:13, 28 September 2015‎ Summer (talk | contribs | block)‎ . . (97 bytes) (+97)‎ . . (Created a tutorial for Raspberry Pi)"
2021-01-06 12:16:48 <artok> ah there was the page info
2021-01-06 12:28:38 <ikke> ugh
2021-01-06 12:29:16 <ikke> n/m
2021-01-06 12:30:41 <ikke> seems like qt5 5.15 will not receive new commits
2021-01-06 12:31:01 <ikke> only for paying customers
2021-01-06 12:32:09 <Cogitri> Yup, they did the last free commit yesterday
2021-01-06 12:32:41 <ikke> and that's the version that will be in alpine 3.13
2021-01-06 12:32:52 <Cogitri> https://lists.qt-project.org/pipermail/development/2021-January/040798.html
2021-01-06 12:33:39 <Cogitri> 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 <mps> ncopa: busybox 1.32.1 is released https://git.busybox.net/busybox/log/?h=1_32_stable
2021-01-06 12:35:54 <mps> some fixes
2021-01-06 12:36:38 <mps> 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 <mps> do you think we should have 1.32.1 in 3.13
2021-01-06 12:38:24 <ikke> It is a bugfix release, so it would make sense
2021-01-06 12:47:04 <fcolista> ncopa, re alpine-virt use virio by default. So far, according with your patch, everything is inherited by <resources arch="all">(.*)</resources>
2021-01-06 12:48:56 <fcolista> 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 <mps> fcolista: virtio-rng?
2021-01-06 12:55:18 <fcolista> is it needed by default?
2021-01-06 12:55:58 <fcolista> 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 <Hello71> 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 <fcolista> Hello71, yes I agree
2021-01-06 13:03:13 <HRio> does the kernel not consume virtio-rng on its own?
2021-01-06 13:06:19 <Hello71> it is same as other external hwrngs
2021-01-06 13:06:23 <Hello71> only rdrand is special
2021-01-06 13:08:20 <Hello71> 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 <HRio> 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 <HRio> (not sure as I am not using kvm)
2021-01-06 13:13:40 <Hello71> well it says "available" so right off the bat I would assume no
2021-01-06 13:14:26 <HRio> avail list all avail, /sys/devices/virtual/misc/hw_random/rng_current lists the selecte
2021-01-06 13:14:31 <HRio> selected
2021-01-06 13:15:42 <HRio> if rng_current shows virtio I think the kernel uses it
2021-01-06 13:15:56 <Hello71> it uses it... for /dev/hwrng
2021-01-06 13:16:34 <Hello71> which is not connected to anything in kernel
2021-01-06 13:17:11 <HRio> ah OK
2021-01-06 13:32:52 <PureTryOut[m]2> 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 <PureTryOut[m]2> 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 <mps> 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 <mps> dir is not writeable
2021-01-06 13:41:28 <Marian[m]1> PureTryOut: That is a good question. I sadly have no idea :-(
2021-01-06 13:42:42 <PureTryOut[m]2> 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 <Hello71> mps: seems fine here
2021-01-06 13:44:27 <PureTryOut[m]2> xdg-desktop-portal seems to be running however
2021-01-06 13:45:14 <Hello71> checked with busybox tar, gnu tar, bsdtar
2021-01-06 13:47:37 <mps> hmm, not in my lxc
2021-01-06 13:49:00 <mps> Hello71: hah, redownloaded it and it is ok.
2021-01-06 13:49:16 <mps> looks like they are fixed it in meantime
2021-01-06 13:49:39 <mps> thanks for idea to redownload
2021-01-06 13:55:32 <HRio> mps: seems there where some busybox devs here listening in :-)
2021-01-06 13:57:04 <Hello71> https://busybox.net/downloads/ [   ] busybox-1.33.0.tar.bz2  2021-01-01 10:27  2.3M
2021-01-06 13:57:28 <Hello71> seems unlikely unless they manually adjusted the mtime
2021-01-06 13:57:44 <HRio> yes
2021-01-06 13:58:02 <Hello71> seems more likely your ram is bad, since w is just one bit flip away
2021-01-06 14:06:18 <mps> Hello71: you are kidding, aren't you :)
2021-01-06 14:07:36 <mps> I did that on alpine developers box, and with APKBUILD, after redownload I see checksum is changed
2021-01-06 14:08:16 <mps> HRio: nick?
2021-01-06 14:23:26 <andypost[m]> Looks mips builders are hangs
2021-01-06 14:51:46 <ikke> build seems even awol
2021-01-06 14:51:52 <ikke> builder
2021-01-06 14:52:50 <ikke> Ariadne: ^
2021-01-06 15:19:27 <ikke> ncopa: nodejs currently has a checksum mismatch on both armv7 and armhf, that's suspicious
2021-01-06 15:20:01 <ikke> "Partial download found, trying to resume"
2021-01-06 15:20:11 <ikke> Looks like they are clobbering eachother
2021-01-06 15:20:58 <ikke> that's for armv7, armhf just shows a checksum mismatch
2021-01-06 15:21:25 <ikke> so looks like armhf started, and armv7 tried to write to the same file as armhf?
2021-01-06 15:35:03 <ncopa> 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 <ncopa> add those to our alpine-virt flavor
2021-01-06 15:35:29 <fcolista> ncopa, thats' a good suggestion. Thanks
2021-01-06 15:37:47 <jvoisin> 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 <ncopa> like build all the package with clang?
2021-01-06 15:53:35 <ncopa> 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 <ncopa> does it generate good code for all our architectures? including s390x, ppc64le and mips64?
2021-01-06 15:54:06 <ncopa> can we build the linux kernel with clang?
2021-01-06 15:54:12 <ikke> and future riscv
2021-01-06 15:54:24 <jvoisin> the linux kernel is almost buildable iirc
2021-01-06 15:54:40 <jvoisin> but yeah, it answers my question pretyt much, thanks :)
2021-01-06 15:55:05 <ncopa> 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 <ncopa> 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 <jvoisin> mh, apparently, gcc supports cfi as well
2021-01-06 15:59:43 <jvoisin> via `-fcf-protection`
2021-01-06 16:00:52 <artok> https://clangbuiltlinux.github.io/
2021-01-06 16:12:16 <mps> do we want stable or experimental?
2021-01-06 16:14:33 <artok> experiment for future is not bad thing, if someone has time for it =)
2021-01-06 16:38:31 <Hello71> jvoisin: well no clang sanitizers support musl now
2021-01-06 16:38:42 <Hello71> meowray is working on it, possibly for next llvm
2021-01-06 16:42:57 <Hello71> 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 <ncopa> iirc for clang -Os = -O2
2021-01-06 16:43:51 <ncopa> in either case, clang as system compiler will not happen for 3.13
2021-01-06 16:45:41 <Hello71> no, it was -O1 = -O2, but I think that is no longer the case
2021-01-06 17:24:37 <ncopa> ok
2021-01-06 17:25:29 <mps> I doubt that clang could be used even for 3.15
2021-01-06 17:27:22 <mps> 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 <insep_> 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 <ncopa> ok. it may need some attention then
2021-01-06 17:28:30 <insep_> freebsd i think builds all packages with clang though
2021-01-06 17:28:38 <insep_> so you know where to steal patches ;)
2021-01-06 17:29:52 <mps> ncopa: that is rejects https://tpaste.us/LwnK
2021-01-06 17:30:48 <mps> I looked at this but don't understand what and why you made this change
2021-01-06 17:31:20 <mps> ofc, I don't say that they are bad, just I don't understand them
2021-01-06 17:31:26 <Hello71> yes, basically take all of the dumb -fno-common and musl 1.2 bugs and add them together
2021-01-06 17:33:41 <ncopa> mps: 7e8d5484c6301602a2bdde9433b569d2bafa2226
2021-01-06 17:33:59 <ncopa> thats what git log told me about the patch. i dont remember a thing :)
2021-01-06 17:34:48 <mps> :)
2021-01-06 17:35:24 <ncopa> 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 <ncopa> https://bugs.busybox.net/show_bug.cgi?id=13116
2021-01-06 17:36:05 <ncopa> or look at the busybox log to find out what they changed
2021-01-06 17:36:15 <mps> I did already, but didn't know for stunnel bug
2021-01-06 17:37:00 <mps> they didn't changed much, some bugfixes only
2021-01-06 17:37:17 <mps> https://git.busybox.net/busybox/log/?h=1_32_stable
2021-01-06 17:37:21 <ncopa> i think they fixed the stunnel hang
2021-01-06 17:40:15 <mps> how to test? 'abuild -r' without without mentioned patch?
2021-01-06 17:40:31 <mps> maybe you remember
2021-01-06 17:40:35 <ncopa> abuild 1.32.1 without the patch
2021-01-06 17:40:47 <mps> it passed in lxc
2021-01-06 17:40:47 <ncopa> the update and build stunnel
2021-01-06 17:40:50 <ncopa> actually
2021-01-06 17:41:00 <mps> aha, ok
2021-01-06 17:41:17 <ncopa> should probably first remove the patch with 1.32.0 and update
2021-01-06 17:41:20 <ncopa> and test build tunnel
2021-01-06 17:41:24 <ncopa> stunnel
2021-01-06 17:41:30 <ncopa> to verify that it still happens
2021-01-06 17:41:35 <mps> lets try
2021-01-06 17:41:38 <ncopa> then update to 1.32.1 and verify that it fixes it
2021-01-06 17:43:30 <mps> already upgraded bb to 1.32.1 on my dev lxc
2021-01-06 17:43:42 <ncopa> without the patch?
2021-01-06 17:43:51 <ncopa> and stunnel builds?
2021-01-06 17:43:53 <mps> yes. without it
2021-01-06 17:44:03 <mps> yes stunnel passed abuild -r
2021-01-06 17:45:09 <mps> but before MR will do that once more
2021-01-06 17:45:28 <mps> or, you will?
2021-01-06 17:47:31 <ncopa> tested here. owrks
2021-01-06 17:47:33 <ncopa> works
2021-01-06 17:47:36 <ncopa> will you push it?
2021-01-06 17:48:36 <mps> let me finish linux-elm first
2021-01-06 17:48:48 <mps> I'm in mid of it
2021-01-06 17:49:12 <ncopa> ok. i have it ready to push here otherwise, in 5ish mins
2021-01-06 17:49:30 <mps> go ahead
2021-01-06 17:50:48 <mps> I'm not in race for commit numbers ;)
2021-01-06 17:54:55 <ncopa> pushed
2021-01-06 17:55:24 <mps> good, I see it
2021-01-06 17:56:03 <mps> so I can later work on 1.33.0
2021-01-06 17:57:15 <ncopa> 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 <artok> umm?
2021-01-06 17:57:49 <mps> afaik no
2021-01-06 17:58:06 <artok> I have upgraded latest kernels on traditional sys installation
2021-01-06 17:58:39 <mps> yes, on sys they work
2021-01-06 17:59:27 <mps> iirc problem is modloop
2021-01-06 17:59:40 <artok> 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 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11052
2021-01-06 18:00:33 <artok> https://termbin.com/i3cu
2021-01-06 18:00:47 <artok> aah that one too
2021-01-06 18:01:24 <artok> didn't rememeber that I've done that copying manually
2021-01-06 18:01:31 <mps> interesting, should find time to test
2021-01-06 18:03:10 <ncopa> was https://termbin.com/i3cu added to alpine-conf git repo?
2021-01-06 18:03:37 <ncopa> i just tagged alpine-conf-3.10.0 release with a bunch of MRs merged
2021-01-06 18:03:58 <artok> afaik no, I did that when upgraded my run-from-memory rpi3 some days ago
2021-01-06 18:04:34 <ncopa> i need to go out, but i think we should add that update-kernel fix
2021-01-06 18:04:52 <ncopa> i think i saw an issue with problem of /tmp running out of space
2021-01-06 18:05:12 <ncopa> artok: can you create an MR and I'll have a look at it tomorrow
2021-01-06 18:05:12 <artok> it's on gitlab.a.o on my fork, so MR is not far awa
2021-01-06 18:05:23 <artok> sur
2021-01-06 18:17:38 <ikke> ncopa: can there be some kind of race condition in abuild-fetch?
2021-01-06 18:31:16 <nmeum> 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 <nmeum> 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 <ikke> you mean from community to testing?
2021-01-06 18:32:22 <ikke> otherwise it would not make sense to me :P
2021-01-06 18:32:44 <nmeum> ooppps
2021-01-06 18:32:44 <nmeum> yes
2021-01-06 18:34:37 <ikke> Means people who use chromium / kodi on a stable release are out of luck
2021-01-06 18:37:14 <nmeum> 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 <nmeum> current version is 87.X we still package 86.X
2021-01-06 18:39:40 <Cogitri> Yup, the Chromium situation is suboptimal either way
2021-01-06 18:43:21 <mps> nmeum: +1
2021-01-06 18:44:25 <nmeum> I will just open an MR, let's see if someone complain about it :D
2021-01-06 18:58:35 <mps> 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 <ikke> hmm, someone reported regressions with zfs
2021-01-06 18:59:35 <mps> but I don't have experience with zfs, so someone else should look at it
2021-01-06 18:59:47 <ikke> 112278
2021-01-06 18:59:50 <ikke> !12278
2021-01-06 18:59:56 <ikke> ugh
2021-01-06 19:00:03 <ikke> #12278
2021-01-06 19:00:41 <nmeum> 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 <ikke> fun
2021-01-06 19:04:06 <mps> i wonder why I don't see much problems with one of most hated language called perl :)
2021-01-06 19:04:30 <HRio> I need python2 at least in community for 3.13
2021-01-06 19:04:41 <ikke> mps: nobody is using it :P
2021-01-06 19:05:03 <Lucas8037> mps: the meme outgrew the language, but it's quite fine, is quite stable and is installed everywhere
2021-01-06 19:05:16 <mps> ikke: why we have then so much pkgs in aports, I wonder :P
2021-01-06 19:05:32 <ikke> mps: because some people still believe ;-)
2021-01-06 19:07:09 <mps> aports/main > ap revdep perl | grep -v '^perl'
2021-01-06 19:07:30 <mps> 103
2021-01-06 19:07:39 <ikke> mps: you didn't even use perl for that? :P
2021-01-06 19:07:43 <ikke> sorry
2021-01-06 19:08:04 <mps> hehe
2021-01-06 19:08:32 <mps> community => 131
2021-01-06 19:09:07 <mps> hmm, testing is bad, just 61
2021-01-06 19:10:07 <ikke> 54, 157, 172 for python3 respectively
2021-01-06 19:10:07 <mps> but yes, perl uses braces and ';' which is hard to comprehend :)
2021-01-06 19:11:07 <mps> so perl is doubled py in main
2021-01-06 19:11:58 <nmeum> 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 <ikke> isn't that why they renamed perl6?
2021-01-06 19:12:32 <nmeum> yeah, i think they did
2021-01-06 19:12:38 <mps> perl5 and perl6 are different languages
2021-01-06 19:12:39 <ikke> rakudo
2021-01-06 19:12:40 <nmeum> wikipedia says it's called raku now
2021-01-06 19:14:28 <mps> and obligatory https://xkcd.com/224/ :)
2021-01-06 19:14:28 <alpine-meetbot> 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 <nmeum> )
2021-01-06 19:15:54 <insep_> nmeum: are you from russia?
2021-01-06 19:16:31 <nmeum> why?
2021-01-06 19:17:01 <insep_> we use ) instead of :)
2021-01-06 19:17:08 <ikke> https://xkcd.com/859/
2021-01-06 19:17:09 <alpine-meetbot> 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 <nmeum> insep_: no, i am not :p
2021-01-06 19:45:30 <ikke> Cogitri: firefox-esr fails
2021-01-06 20:06:03 <Cogitri> `g++: fatal error: Killed signal terminated program cc1plus`
2021-01-06 20:06:10 <Cogitri> I guess it even OOMs on the builders now? :D
2021-01-06 20:06:26 <Cogitri> 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 <Cogitri> algitbot: retry master
2021-01-06 20:06:52 <ikke> Probably because you pushed both master and 3.12
2021-01-06 20:06:55 <ikke> at the same time
2021-01-06 20:06:57 <Cogitri> Yup
2021-01-06 20:07:11 <Cogitri> Let's restart 3.12 once master went through
2021-01-06 20:07:48 <ikke> I saw some other messages as well, but that was probably noise
2021-01-06 20:08:27 <ikke> {standard input}:481586: Error: expected symbol name
2021-01-06 20:08:50 <ikke> {standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
2021-01-06 20:09:54 <ikke> build systems should be prohibited to output error unless something is an actual error 🤐
2021-01-06 20:10:46 <mps> I consider warning as error
2021-01-06 20:11:01 <ikke> then most programs are broken
2021-01-06 20:11:15 <mps> yes, they are
2021-01-06 20:11:46 <ikke> 
ACTION adds -Wpedantic -Werror to standard alpine flags

2021-01-06 20:12:17 <mps> without that there are so much of them
2021-01-06 20:15:52 <ikke> 
ACTION adds -Wall and -Wextra as well

2021-01-06 20:16:28 <ikke> Good luck, the next 10 years before we do another release :P
2021-01-06 20:17:37 <artok> good, we have time to make clang as system compiler!
2021-01-06 20:18:36 <mps> :)
2021-01-06 20:21:57 <ikke> 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 <artok> filesystem so that it won't allow creating folder named node_modules
2021-01-06 20:25:13 <ikke> ha!
2021-01-06 20:25:25 <ikke> Just map node_modules to /dev/null
2021-01-06 20:25:36 <ikke> Should be just about enough storage
2021-01-06 20:26:12 <Hello71> ikke: that one is probably also OOM
2021-01-06 20:59:05 <ikke> 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 <Cogitri> Yikes
2021-01-06 21:15:58 <Cogitri> Pushed fix, needed newer version of nss on 3.12
2021-01-06 21:20:40 <mps> 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 <ikke> not sure they are provided by a package
2021-01-06 21:22:25 <mps> so, how to set them with apk add --arch arch --root /mnt
2021-01-06 21:24:06 <ikke> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/blob/master/setup-alpine.in#L153
2021-01-06 21:25:00 <mps> nice, looked already earlier
2021-01-06 21:25:28 <mps> but have no idea how to do that with 'apk add --arch arch --root /mnt'
2021-01-06 21:28:25 <ikke> you need to add install openrc
2021-01-06 21:28:39 <ikke> and then add the desired services to the correct runlevels
2021-01-06 21:28:41 <mps> I did
2021-01-06 21:28:46 <ikke> (so basically chroot into it)
2021-01-06 21:29:16 <mps> 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 <ikke> You can just create the symlinks manually without a chroot
2021-01-06 21:29:52 <mps> maybe I will add to install symlinks to install script
2021-01-06 21:30:12 <mps> ikke: yes, understand that, (as a last resort though)
2021-01-06 21:30:17 <ikke> ls -s /etc/init.d/networking /mnt/etc/runlevels/boot/
2021-01-06 21:30:53 <ikke> ln -s*
2021-01-06 21:31:13 <mps> sure
2021-01-06 21:31:27 <ikke> oh, networking is in default, not boot
2021-01-06 21:33:09 <Hello71> this is not the main part though
2021-01-06 21:33:14 <Hello71> core services are enabled in mkinitfs
2021-01-06 21:33:50 <ikke> Hello71: right, suspected as much
2021-01-06 21:34:12 <Hello71> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L623
2021-01-06 21:34:21 <mps> hmm, mkinitfs run and created initramfs but not symlinks
2021-01-06 21:34:23 <ikke> heh
2021-01-06 21:34:36 <ikke> initramfs-init
2021-01-06 21:35:00 <ikke> but that's only relevant if you boot a kernel
2021-01-06 21:35:19 <ikke> not for lxc containers for example
2021-01-06 21:35:22 <mps> so, add initramfs-init?
2021-01-06 21:35:43 <ikke> mps: is this something you want to boot?
2021-01-06 21:35:52 <mps> yes
2021-01-06 21:36:15 <mps> working on script to install alpine for arm on mmc
2021-01-06 21:36:25 <ikke> You need to make sure /etc/.default_boot_services exists
2021-01-06 21:37:30 <ikke> then, at boot time, it will enable those services the first time, and then remove that file
2021-01-06 21:38:18 <ikke> 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 <mps> initramfs-init (no such package):
2021-01-06 21:40:57 <ikke> it's not a package you install
2021-01-06 21:41:01 <ikke> it's part of mkinitfs
2021-01-06 21:41:45 <mps> aha, touch /etc/.default_boot_services ?
2021-01-06 21:41:58 <ikke> yes
2021-01-06 21:42:10 <mps> thanks
2021-01-06 21:45:25 <mps> hmm, our /etc/securetty missing ttyS0
2021-01-06 21:47:13 <ikke> Hmm, but I've never had issues with logging in as root via serial
2021-01-06 21:48:02 <ikke> aha: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L122
2021-01-06 21:48:27 <ikke> initramfs-init automatically adds the blockdevice specifyed via console to /etc/securetty
2021-01-06 21:49:17 <mps> huh, have bad crc on gpt table, probably mmc card issue
2021-01-06 22:14:18 <mps> hmm, /etc/.default_boot_services doesn't work
2021-01-06 22:15:17 <mps> but it boots
2021-01-06 22:19:17 <ikke> I would expect it to work
2021-01-06 22:21:23 <mps> will left for some other day
2021-01-06 22:22:00 <ikke> heh, initramfs-init also just creates symlinks
2021-01-06 22:22:24 <mps> not armv7 3.12
2021-01-06 22:22:48 <ikke> I mean, the way it would add services
2021-01-06 22:22:56 <ikke> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L94
2021-01-06 22:23:31 <mps> that is last part what missing on my test
2021-01-06 22:23:43 <mps> but some other day
2021-01-06 22:26:05 <mps> but I nearly finished script to install armv7 on mmc in sys mode
2021-01-06 22:26:33 <mps> and script could be extended to some kind of guide for alpine users
2021-01-06 22:26:36 <ikke> What prevents alpine from providing a sys install by default?
2021-01-06 22:27:08 <mps> well, complicated for SBCs with usually just one mmc slot
2021-01-06 22:29:04 <ikke> right, you cannot really install it to some available persistent storage
2021-01-06 22:29:38 <ikke> most other distros you would just boot an already installed system
2021-01-06 22:30:04 <mps> 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 <mps> but a lot of work, especially for unexperienced
2021-01-06 22:31:05 <mps> here is my WIP shell script https://tpaste.us/ZEZl
2021-01-06 22:32:29 <ikke> 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 <mps> how to update kernel on SBC hundreds or thousands km away
2021-01-06 22:34:51 <ikke> with a sys install, it should be trivial
2021-01-06 22:34:59 <insep_> send satellite into space
2021-01-06 22:35:32 <mps> better NLO
2021-01-07 03:01:22 <TBK[m]> 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 <mps> TBK[m]: how to do that?
2021-01-07 03:08:07 <mps> 'git clone https://gn.googlesource.com/gn' and create tarball of dir?
2021-01-07 08:26:08 <ikke> morning
2021-01-07 08:27:18 <mps> good morning
2021-01-07 08:27:42 <Cogitri> Morning
2021-01-07 09:01:21 <craftyguy> howdy
2021-01-07 10:17:49 <TBK[m]> mps: yes, clone and tarball it all :)
2021-01-07 10:32:47 <mps> 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 <mps> gn-0_git20201222.tar.gz ?
2021-01-07 10:34:44 <TBK[m]> mps: gn-0_git20201222.tar.gz  would be perfect :)
2021-01-07 10:34:55 <mps> ok
2021-01-07 10:40:01 <mps> hmm, looks like I don't have rights to put files in /archive/gn/
2021-01-07 10:40:43 <mps> Cogitri: is owner
2021-01-07 10:41:58 <mps> gn dir needs group write flag
2021-01-07 10:52:41 <ikke> mps: will fix it
2021-01-07 10:52:59 <ikke> it should have a sticky bit set so that the group remains
2021-01-07 10:53:44 <mps> it have it
2021-01-07 10:55:59 <ikke> added write permissions to the group now
2021-01-07 11:02:45 <mps> ikke: thanks
2021-01-07 11:03:12 <mps> TBK[m]: there is it. if it is not ok tell us
2021-01-07 11:03:28 <TBK[m]> mps: thanks
2021-01-07 11:23:46 <mps> TBK[m]: np
2021-01-07 11:36:22 <ncopa> good day
2021-01-07 11:44:14 <TBK[m]> hi
2021-01-07 11:44:23 <ikke> o/
2021-01-07 11:45:09 <TBK[m]> ncopa: if you have some time could you take a look at !16536 ?
2021-01-07 11:46:58 <ncopa> um sure
2021-01-07 11:48:05 <ncopa> its just that I may want to update while update kernel
2021-01-07 11:48:33 <ncopa> 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 <ncopa> i'd like to push linux-lts separately and linux-rpi separately
2021-01-07 13:58:26 <Marian[m]1> 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 <ncopa> someone posted this to me yesterday i dont remember who... https://termbin.com/i3cu
2021-01-07 14:39:12 <minimal> ncopa: think that was either artok or mps
2021-01-07 14:39:33 <minimal> was part of the RPI discussion
2021-01-07 14:39:47 <ikke> artok
2021-01-07 14:42:45 <ncopa> sigh.. i think im losing it...
2021-01-07 14:42:56 <ikke> :(
2021-01-07 14:43:23 <minimal> 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 <ncopa> 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 <ncopa> i was about to push when i realized that i hadnt done what i was upposed to do
2021-01-07 14:45:22 <ikke> Well, it's hard to keep track of all details
2021-01-07 14:46:08 <ncopa> 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 <minimal> 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 <ncopa> 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 <ncopa> there is an MR for it
2021-01-07 14:50:11 <artok> hullo!
2021-01-07 14:50:38 <ncopa> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11052
2021-01-07 14:56:35 <minimal> 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 <artok> ncopa: !11 , was there some scripts calling update-kernel ? as Hello71 suggest that it would be mandantory setting
2021-01-07 15:32:59 <artok> duh.. not that aports 11, alpine-conf 11 =D
2021-01-07 15:33:09 <ikke> algitbot only supports aports
2021-01-07 15:33:36 <artok> narrow minded bot =)
2021-01-07 15:34:01 <ikke> patches welcome: https://gitlab.alpinelinux.org/alpine/infra/compose/algitbot/-/blob/master/sircbot/scripts/sircbot.lua :P
2021-01-07 15:38:00 <artok> oh.. lua
2021-01-07 15:58:02 <ncopa> 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 <artok> yeah, I did that purely so that without setting, it would act as before
2021-01-07 16:21:32 <Hello71> 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 <ikke> is the -t option deprecated, or the fallback to /tmp?
2021-01-07 16:36:16 <Hello71> 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 <Hello71> not sure that first part makes sense
2021-01-07 16:43:30 <ncopa> I dont have any tbh
2021-01-07 16:51:10 <ncopa> oh, now i see what you mean: mkdir -p "${TMPDIR:-/tmp}"  "$SCRIPT.XXXXXX"
2021-01-07 16:52:14 <ncopa> s/mkdir/mktemp/
2021-01-07 16:52:14 <alpine-meetbot> ncopa meant to say: oh, now i see what you mean: mktemp -p "${TMPDIR:-/tmp}"  "$SCRIPT.XXXXXX"
2021-01-07 18:05:04 <mps> 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 <wsinatra> mps: does it build up from a minirootfs?
2021-01-07 18:20:01 <mps> wsinatra: no, as wrote above 'apk add --root $dir --arch $arch ...'
2021-01-07 18:20:31 <mps> wsinatra: here it is https://tpaste.us/Yox4
2021-01-07 18:20:47 <mps> rough as you can see, but worked
2021-01-07 18:21:34 <wsinatra> 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 <wsinatra> I like the initial version :)
2021-01-07 18:22:35 <mps> I will try to 'polish' it somewhat and put somewhere on inet
2021-01-07 18:23:04 <mps> as usual, any comments and helps are welcome
2021-01-07 18:24:17 <mps> and this could be user as method for other arches, I plan to test it for arm64 chromebook
2021-01-07 18:31:29 <wsinatra> 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 <mps> yes, it is extensible to the need or use cases for end users
2021-01-07 18:33:32 <minimal> 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 <mps> meh, ansible ;)
2021-01-07 18:34:24 <mps> minimal: sorry, couldn't resist
2021-01-07 18:35:11 <minimal> mps: I know, my Ansible playbook ssh'ed in to you to trigger that reaction ;-)
2021-01-07 18:35:55 <mps> minimal: no, it is not, I did this long time ago
2021-01-07 18:36:22 <minimal> I meant your "meh, ansible" statement lol
2021-01-07 18:36:37 <mps> but found some time (insomnia) to make it as script
2021-01-07 18:37:00 <afontain_> I'm a bit surprised to see "Ansible" and "minimal" together
2021-01-07 18:37:12 <mps> :)
2021-01-07 18:37:58 <minimal> 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 <wsinatra> 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 <wsinatra> Ad hoc provisioning stuff is neat
2021-01-07 18:39:21 <minimal> and I'm also generating non-Linux/Unix configs with Ansible as well for things like switch config
2021-01-07 18:40:09 <minimal> 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 <wsinatra> oooh I DO like that idea
2021-01-07 18:41:26 <wsinatra> I might have to steal that ;)
2021-01-07 18:41:52 <wsinatra> 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 <minimal> "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 <minimal> 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 <wsinatra> 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 <minimal> 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 <minimal> 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 <minimal> 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 <wsinatra> 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 <minimal> wsinatra: won't touch a cloud-only-provisioned device with a bargepole
2021-01-07 18:51:31 <wsinatra> 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 <wsinatra> I feel that on SO many levels.
2021-01-07 18:52:17 <wsinatra> 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 <minimal> did a quick search on Mikrotiks and notice they talk about "binary" files written/read from TFTP
2021-01-07 18:53:29 <minimal> 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 <wsinatra> 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 <wsinatra> extra steps, and better than web interfaces
2021-01-07 18:55:27 <minimal> looks like I misread - there's a distinction between "backup" (binary file) and "export" (text)
2021-01-07 18:57:06 <minimal> 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 <minimal> 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 <wsinatra> 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 <wsinatra> 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 <minimal> 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 <nliadm> 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 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/secdb
2021-01-07 20:23:38 <ikke> Every APKBUILD has a section for secfixes
2021-01-07 20:23:45 <ikke> we have a set of scripts that extracts those
2021-01-07 20:30:28 <nliadm> 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 <omni> 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 <omni> https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/configure;h=8a708e9baa85a5ff8336a4dacb897453cb43c358;hb=HEAD#l1508
2021-01-07 20:36:06 <HRio> see here https://git.alpinelinux.org/aports/tree/main/xen/APKBUILD
2021-01-07 20:37:11 <omni> yeah, I did, just am not sure how qemu is "default" configured
2021-01-07 20:37:41 <HRio> ah OK, so qemu is needed for 9pfs ?
2021-01-07 20:37:52 <omni> I don't know
2021-01-07 20:37:56 <HRio> ( I am not using qemu with XEN myself )
2021-01-07 20:38:32 <omni> 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 <HRio> Alpine domUs works in pvh mode without qemu
2021-01-07 20:38:48 <HRio> I do not use hvm
2021-01-07 20:39:11 <omni> I do for pci passthrough, if I'm not mistaken and it is not needed there
2021-01-07 20:39:27 <HRio> not needed
2021-01-07 20:39:44 <HRio> pci passthrough works in pv mode as well
2021-01-07 20:40:14 <HRio> but qemu is needed if you are running an OS with a GUI
2021-01-07 20:41:17 <omni> hmm... ok... I'll need to investigate this
2021-01-07 20:41:27 <HRio> 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 <omni> either way, I'll open a ticket for --enable-9pfs
2021-01-07 20:43:20 <HRio> OK, can you try to investigate if that is something that requires qemu?
2021-01-07 20:45:45 <omni> perhaps I'm just failing...
2021-01-07 20:46:02 <omni> yeah, I'll hold off with the report a bit
2021-01-07 20:46:27 <omni> "Explicitly enable 9pfs support in QEMU build"
2021-01-07 20:46:59 <omni> it's just that I've tried and thought that, aha, this might be it
2021-01-07 20:50:44 <Hello71> alpine xen doesn't use system qemu
2021-01-07 20:57:48 <dne> but it probably should
2021-01-07 20:58:54 <ikke> nliadm: are these issues by chance already listed here? https://gitlab.alpinelinux.org/alpine/infra/docker/secdb/-/issues
2021-01-07 21:00:24 <nliadm> yeah, that empty values one, but also I've duplicate version entries before
2021-01-07 21:00:30 <HRio> seems there are 9pfs releated .c files in qemu-xen in edge
2021-01-07 21:00:56 <nliadm> specifically in the yaml output. maybe some yaml libraries are nice and merge them for you
2021-01-07 21:01:31 <HRio> e.g src/xen-4.14.1/tools/qemu-xen/hw/9pfs/xen-9p-backend.c
2021-01-08 08:10:18 <ncopa> morning
2021-01-08 08:11:27 <ikke> hey
2021-01-08 08:11:40 <mps> \o :)
2021-01-08 08:11:44 <HRio> morning
2021-01-08 08:12:36 <Cogitri> Morning
2021-01-08 08:13:19 <ncopa> i think i may have fixed rpi support for setup-disk
2021-01-08 08:13:55 <ikke> That would be nice
2021-01-08 08:13:59 <ncopa> on thing im considering is to unmount the boot media so you can do sys install on it
2021-01-08 08:14:10 <ncopa> currently setup-disk will not list mounted disks
2021-01-08 08:14:30 <ikke> right, so you first use the bootmedia for the setup, and then overwrite it with the actual installation
2021-01-08 08:14:38 <ncopa> yup
2021-01-08 08:15:27 <ncopa> 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 <ncopa> btw, i fixed the wifi configuration from setup-alpine earlier this week
2021-01-08 08:16:49 <ncopa> should be pretty ok now
2021-01-08 08:18:12 <mps> f2fs is better than ext4 for mmc, ime
2021-01-08 08:20:53 <ncopa> mps: why? do you have any references to article with numbers explaining why?
2021-01-08 08:21:47 <mps> I read dispersed article over inet but I don't have any 'under fingers'
2021-01-08 08:22:18 <mps> and f2fs is designed flash friendly FS
2021-01-08 08:22:54 <mps> and as I wrote above, 'IME'
2021-01-08 08:22:56 <Cogitri> f2fs has internal wear leveling which controller-less flash doesn't have
2021-01-08 08:23:59 <mps> I use it for long time on all mmc, usb flash disks and all ssd
2021-01-08 08:24:38 <insep_> Cogitri: that's ubifs
2021-01-08 08:24:56 <mps> though as everything, there is no perfect one
2021-01-08 08:25:13 <insep_> at least controller-less part
2021-01-08 08:26:20 <Cogitri> Oh, right
2021-01-08 08:26:35 <insep_> f2fs just tries to optimize write cycles and whatnot to save flash
2021-01-08 08:26:38 <mps> new kernels are now do some of these 'wear' tasks
2021-01-08 08:26:51 <insep_> comes with compression too
2021-01-08 08:32:16 <ncopa> f2fs seems to have good write performance as well
2021-01-08 08:32:53 <ncopa> 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 <mps> good, I don't propese change, just noted
2021-01-08 08:34:25 <mps> what kernel version is on CIs
2021-01-08 09:00:23 <HRio> 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 <mps> if someone want to merge !16592 then should look does bluez and ofono need to be rebuilt
2021-01-08 09:32:48 <HRio> 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 <ncopa> do we want swap enabled on rpi? I'd guess that we dont?
2021-01-08 09:52:46 <ikke> I don't think so either
2021-01-08 09:52:54 <ikke> swap on flash doesn't sound like a good idea
2021-01-08 10:08:52 <ncopa> 👍
2021-01-08 10:15:43 <ncopa> \o/ finally setup-disk worked!
2021-01-08 10:15:54 <ncopa> now i'll only test lvmsys install
2021-01-08 10:15:59 <ikke> \o/
2021-01-08 10:17:24 <ncopa> 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 <mps> I have this in script to flash rpi 'parted -s $device unit s -- mkpart primary fat32 2048 526335'
2021-01-08 11:29:58 <HRio> 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 <HRio> testing tool https://github.com/raspberrypi-ui/agnostics/blob/master/data/sdtest.sh
2021-01-08 11:34:50 <mps> 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 <ikke> 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 <mps> yes
2021-01-08 11:36:11 <HRio> sure but why not run from ramfs and commit with lbu then?
2021-01-08 11:36:21 <ikke> memory
2021-01-08 11:36:41 <ikke> Your storage is constrained by memory
2021-01-08 11:36:48 <mps> upgrade kernel on run-from-ram
2021-01-08 11:36:53 <HRio> sure but if you do not write...
2021-01-08 11:37:18 <mps> need persistent log
2021-01-08 11:38:01 <ikke> HRio: it's not about data, but about installed programs
2021-01-08 11:38:13 <ikke> someone on #alpine-linux could not install chromium by default due to this
2021-01-08 11:38:48 <HRio> the desktop use case is one of A1 or A2 speed class
2021-01-08 11:44:01 <HRio> 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 <HRio> (remote syslog)
2021-01-08 11:46:15 <mps> everything can be solved, except unsolvables
2021-01-08 11:47:36 <mps> running desktop on A1 is not 'pleasant' though it works, I have one
2021-01-08 11:48:25 <Ariadne> i'll stick to actual NVMe storage
2021-01-08 11:48:38 <Ariadne> raspi is not interesting to me except for small appliances
2021-01-08 11:49:00 <Ariadne> like i have a console server on rpi4
2021-01-08 11:49:01 <mps> if machine have one, then I would also
2021-01-08 11:49:03 <Ariadne> at my colo
2021-01-08 11:52:20 <HRio> yes for me rpi is for small jumphosts and ntp servers.
2021-01-08 11:56:30 <PureTryOut[m]2> 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 <ikke> should be easier now with the new changes
2021-01-08 11:57:12 <mps> PureTryOut[m]2: yesterday I posted script here for this
2021-01-08 13:32:39 <decke> the guide in the wiki also works for RPI with some side effects and small issues
2021-01-08 14:38:06 <omni> 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 <minimal> 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 <minimal> 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 <Hello71> 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 <Hello71> debian and rh already do this
2021-01-08 14:53:30 <ncopa> 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 <ncopa> one challenge is that we may not have frambuffer console at that time
2021-01-08 14:53:55 <ncopa> so its not possible to see the fsck progress
2021-01-08 14:54:42 <Hello71> 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 <HRio> 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 <minimal> 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 <minimal> s/not the fsck/the fsck/g
2021-01-08 15:14:19 <alpine-meetbot> 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 <Hello71> wait what
2021-01-08 15:46:19 <minimal> 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 <Hello71> you are supposed to *un*mount it, not mount it rw
2021-01-08 15:47:03 <minimal> this is before Alpine remounts it "rw", its "ro" during that stage of the boot
2021-01-08 15:48:00 <Hello71> 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 <minimal> 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 <minimal> remount F2FS in that case even if its potentially unclean.
2021-01-08 15:50:50 <Hello71> /etc/conf.d is totally unrelated to initramfs
2021-01-08 15:51:17 <minimal> Its why I switched back to EXT4 from F2FS for my RPIs
2021-01-08 15:53:26 <minimal> 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 <Hello71> 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 <ignapk> 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 <Hello71> ignapk: uh... why?
2021-01-08 15:56:51 <Hello71> s/said/previously said/
2021-01-08 15:56:52 <alpine-meetbot> 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 <minimal> 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 <ignapk> it's just a sanity check to detect infinite recursion so it shouln't hurt to increase it
2021-01-08 15:57:06 <Hello71> ignapk: right, but... why
2021-01-08 15:57:29 <Hello71> i agree that this is a low risk change but what kind of ridiculous tree do you have
2021-01-08 15:57:50 <ignapk> https://github.com/Dil3mm4/labyrinth_kernel_prague
2021-01-08 15:58:41 <Hello71> does that have 100 layers deep directories?
2021-01-08 15:58:47 <minimal> 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 <Hello71> that's not the kernel then
2021-01-08 15:59:46 <Hello71> you could implement such a policy but i doubt alpine/openrc does
2021-01-08 15:59:51 <minimal> 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 <Hello71> 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 <Hello71> the fsck.f2fs patches allow *checking* ro mounted filesystem
2021-01-08 16:02:03 <minimal> 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 <ignapk> Hello71: just checked and maximum directory depth is 12, that's weird
2021-01-08 16:03:41 <minimal> Hello71: which fsck.f2fs patches? The Alpine f2fs-tools package doesn't apply any patches to upstream code
2021-01-08 16:04:19 <ignapk> 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 <Hello71> meh, I already lost it
2021-01-08 16:09:05 <Hello71> 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 <mps> 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 <Hello71> 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 <Hello71> the best mode is always to run fsck with filesystem unmounted
2021-01-08 16:10:41 <minimal> 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 <mps> (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 <Hello71> or be designed to not require fsck (btrfs, xfs, zfs)
2021-01-08 16:12:51 <minimal> 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 <Hello71> 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 <Hello71> they thought that putting it under -f was sufficiently clear
2021-01-08 16:15:28 <Hello71> obviously it was not
2021-01-08 16:17:07 <minimal> 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 <Hello71> 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 <Hello71> fsck.xfs is also a no-op
2021-01-08 16:18:20 <Hello71> there is xfs_check but as the man page says it is not supposed to be run regularly
2021-01-08 16:18:32 <minimal> so we're coming full circle that the issue is only currently apparent with a F2FS rootfs
2021-01-08 16:19:08 <Hello71> yes, i said that 1.5 hours ago
2021-01-08 16:19:09 <minimal> which is why I'd chipped in after the earlier discussion about using a F2FS rootfs
2021-01-08 16:19:15 <ncopa> ok... i think im pretty happy with setup-disk + rpi. it will ask to unmount the /media/<wherever-modloop-is> and retry
2021-01-08 16:19:22 <Hello71> 14:54 <Hello71> 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 <ncopa> then it will copy the kernel modules to tmpfs
2021-01-08 16:19:55 <ncopa> 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 <Hello71> ncopa: cool
2021-01-08 16:20:17 <ncopa> sys install works and lvmsys also tested and works
2021-01-08 16:20:49 <mps> ncopa: this will be usable, really
2021-01-08 16:21:09 <Hello71> 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 <Hello71> if we consider this a minirootfs alternative
2021-01-08 16:21:52 <ncopa> the question will come up when there are no free disks found
2021-01-08 16:22:03 <ncopa> so not only for rpi
2021-01-08 16:22:22 <Hello71> 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 <ncopa> then user will have to manually unmount the disk before running setup-disk
2021-01-08 16:23:21 <ncopa> you can answer ! on any of the questions and you'll get a shell
2021-01-08 16:23:47 <Hello71> 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 <ncopa> i cleaned up the scripts a bit
2021-01-08 16:24:06 <ncopa> i have pushed the code
2021-01-08 16:24:23 <ncopa> and im pretty happy with the behavior
2021-01-08 16:24:48 <ncopa> its also "new" that you can answer ! on any question and get a shell
2021-01-08 16:25:07 <ncopa> and then come back to the setup script
2021-01-08 16:25:32 <ncopa> it was possible from some of the questions before, but now it should be possible from every
2021-01-08 16:36:46 <minimal> 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 <ncopa> 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 <ncopa> im gonna tag rc3 now
2021-01-08 16:38:32 <mps> every binary in can be used by 'one' pkg in main :)
2021-01-08 16:38:45 <mps> in testing*
2021-01-08 16:38:56 <mps> (I need coffee)
2021-01-08 16:40:08 <mps> 
ACTION wonders why alpine nowadays have separate subrepos

2021-01-08 16:40:34 <mps> rhetorical question, answer is not asked for
2021-01-08 16:42:52 <minimal> 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 <mps> and I'm thinking to remove librtlsdr from rng-tools
2021-01-08 16:46:02 <minimal> mps: too large for you?
2021-01-08 16:46:06 <mps> minimal: that is what actually happened to rng-tools when librtlsdr deps added (speaking guilty for that)
2021-01-08 16:46:46 <mps> minimal: I looked around and noticed that not much people use rtl sdr devices
2021-01-08 16:47:12 <ncopa> minimal: merged.
2021-01-08 16:47:45 <mps> jitterentropy could be more useful than librtlsdr
2021-01-08 16:48:01 <mps> this is my impression
2021-01-08 16:48:09 <ncopa> ugh.. i didnt pay attention to the "Apply 1 suggestion(s) to 1 file(s)"
2021-01-08 16:48:09 <mps> but time will show
2021-01-08 16:48:24 <minimal> 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 <yZ5vlALg86lP> 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 <ncopa> those messages are not useful at all. should have squashed them and rebased it
2021-01-08 16:49:04 <mps> yZ5vlALg86lP: thanks for notice, will look
2021-01-08 16:49:25 <mps> minimal: yes, that is what also think
2021-01-08 16:49:49 <ncopa> 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 <yZ5vlALg86lP> mps the main repo changed, and the old you're tracking is not being updated anymore...
2021-01-08 16:50:24 <mps> yZ5vlALg86lP: aha, that explains
2021-01-08 16:50:34 <ncopa> it was my fault. i shouldnt have merged :-/
2021-01-08 16:50:41 <minimal> 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 <ncopa> neither did I. it was my fault though.
2021-01-08 16:51:02 <minimal> normally I've have made changes locally and squashed them.
2021-01-08 16:51:21 <ncopa> i shouldnt look at tiwhile tagging release on a friday night when im tired...
2021-01-08 16:51:31 <ncopa> yeah, squshing them is the correct way
2021-01-08 16:51:40 <minimal> Is this a new Gitlab feature? Likely others will use it as well and cause the same messages
2021-01-08 16:52:08 <ncopa> gitlab is stupid
2021-01-08 16:52:20 <ncopa> github does probaly the same
2021-01-08 16:52:24 <mps> as every gui :)
2021-01-08 16:52:31 <minimal> perhaps you should disable that feature if possible
2021-01-08 16:52:39 <ncopa> might be a good idea
2021-01-08 16:54:39 <minimal> 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 <ncopa> 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 <ncopa> minimal: feel free to do so, but i'm not gonna deal with it today
2021-01-08 16:55:12 <ncopa> im tired. should have stopped long time ago
2021-01-08 16:56:03 <ncopa> _rc3 is out
2021-01-08 16:57:01 <minimal> 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 <Hello71> isn't jitterentropy upstream in 5.9 or something
2021-01-08 16:58:42 <Hello71> hopefully it should be better in kernel than in userspace
2021-01-08 16:59:15 <Hello71> even if the premise is questionable, surely kernel can measure more things
2021-01-08 17:00:25 <ncopa> ugh.. pipewire failed on mips64
2021-01-08 17:00:33 <ncopa> so rc3 is not on mips64
2021-01-08 17:02:30 <ncopa> 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 <ncopa> try help different disk installs (sys, lvm, raid, data etc)
2021-01-08 17:03:30 <minimal> 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 <Hello71> pretty sure updating entropy estimate was the only point of adding it
2021-01-08 17:04:07 <Hello71> over the objections of tytso etc
2021-01-08 17:04:34 <minimal> 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 <Hello71> as a reaction to widespread use of getrandom during boot
2021-01-08 17:06:10 <minimal> 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 <mps> Hello71: /crypto/Kconfig:config CRYPTO_JITTERENTROPY
2021-01-08 17:09:05 <Hello71> ah, my mistake. 5.4 added a separate jitterentropy
2021-01-08 17:09:17 <mps> iirc yes
2021-01-08 17:09:37 <Hello71> not sure why they didn't hook up crypto jitterentropy instead...
2021-01-08 17:10:40 <Hello71> 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 <mps> CRYPTO_JITTERENTROPY is selected by 'CRYPTO_DRBG [=y] && CRYPTO [=y] && CRYPTO_DRBG_MENU [=y]'
2021-01-08 17:12:35 <minimal> its an alternative to things like haveged
2021-01-08 17:16:10 <minimal> 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 <minimal> 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 <minimal> 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 <MY-R> 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 <minimal> MY-R: that would have been me :-)
2021-01-08 17:25:38 <MY-R> probably!
2021-01-08 17:25:50 <Hello71> 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 <Hello71> not sure it is a convincing argument though
2021-01-08 17:26:21 <minimal> 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 <Hello71> even though in his defense I think he made it before actually committing try_to_generate_entropy
2021-01-08 17:26:47 <MY-R> minimal: 3.13rc2 so ye rtc working now much earlier than before
2021-01-08 17:27:14 <Hello71> minimal: ugh, rpi nonsense
2021-01-08 17:28:16 <MY-R> minimal: in mine "/etc/init.d/osclock" is only provide clock
2021-01-08 17:28:46 <minimal> MY-R: so you've tried "rc-update add osclock boot" and "rc-update del hwclock boot"?
2021-01-08 17:29:09 <minimal> My-R: sorry I meant "clock", not "entropy".....to much entropy discussion going on currently :-)
2021-01-08 17:29:14 <MY-R> minimal: yes, and both starting
2021-01-08 17:29:38 <MY-R> is more like it adding automaticly by self because after reboot need del hwclock again
2021-01-08 17:29:55 <minimal> the "rc-update del hwclock boot" should mean it doesn't start anymore
2021-01-08 17:30:12 <minimal> is this a "sys" disk image or a run-from-memory?
2021-01-08 17:30:13 <MY-R> after reboot is again back in boot
2021-01-08 17:30:19 <MY-R> from memory
2021-01-08 17:30:31 <Hello71> well did you lbu commit
2021-01-08 17:30:33 <MY-R> so is some hardcoded dependency probably
2021-01-08 17:30:41 <MY-R> of course :)
2021-01-08 17:30:44 <HRio> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L728
2021-01-08 17:30:57 <minimal> 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 <Hello71> oh yeah
2021-01-08 17:31:12 <MY-R> ye
2021-01-08 17:32:08 <minimal> Hello71: rpi nonsense?
2021-01-08 17:32:26 <Hello71> well, rpi is main no-rtc platform
2021-01-08 17:32:53 <minimal> ask mps: there's plenty of non-rpi SBCs with no RTC
2021-01-08 17:33:03 <Hello71> sure
2021-01-08 17:33:27 <Hello71> but how many running alpine
2021-01-08 17:34:09 <MY-R> minimal: I wasnt sure if is correct behavior but all working fine so I dont care much :)
2021-01-08 17:35:06 <minimal> 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 <Hello71> ugh.
2021-01-08 17:35:34 <ikke> minimal: I don't think you can disable merge request suggestions
2021-01-08 17:35:47 <Hello71> does f2fs fsck actually check rtc
2021-01-08 17:35:53 <ikke> or applying them through the interface
2021-01-08 17:36:08 <minimal> ikke: Fun, expect various people to use that "useful" feature lol
2021-01-08 17:36:17 <ikke> Yes, I've already seen it
2021-01-08 17:36:35 <ikke> It's not new btw
2021-01-08 17:37:33 <Hello71> e2fsck specifically checks if clock is before year 2010
2021-01-08 17:38:00 <Hello71> 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 <Hello71> for f2fs it seems used for "quota grace time"
2021-01-08 17:39:08 <minimal> 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 <Hello71> i think this was true of old e2fsck
2021-01-08 17:42:11 <Hello71> https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?id=177839e24 very old e2fsck
2021-01-08 17:42:40 <minimal> without correct time then settings like the interval between checks will not work as expected
2021-01-08 17:43:26 <Hello71> that's set to 0 nowadays anyways
2021-01-08 17:44:41 <Hello71> and looking at pre-177839e24, it wasn't UNEXPECTED INCONSISTENCY, it was just running checks every boot
2021-01-08 17:45:48 <minimal> 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 <minimal> 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 <Hello71> yes, I mean by default
2021-01-08 17:46:28 <Hello71> idk, check what debian does
2021-01-08 17:47:13 <Hello71> 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 <minimal> 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 <Hello71> surely fsck relies more on the fs being unmounted than the system clock
2021-01-08 17:48:23 <Hello71> i'll concede that the system clock is sometimes used, but in that case swclock is useless
2021-01-08 17:48:28 <minimal> as you've said yourself earlier that depends on each of the various fsck tools
2021-01-08 17:50:55 <Hello71> there's no point to set the system clock to the shutdown time before running fsck
2021-01-08 17:51:01 <Hello71> it that was useful then the fsck could just do that itself
2021-01-08 17:51:10 <minimal> 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 <Hello71> if you want the clock to be accurate without rtc, then you need ntp (or similar)
2021-01-08 17:51:45 <Hello71> 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 <Hello71> /boot, which is presumably where you would need it to be for it to be ready before fsck
2021-01-08 17:53:24 <minimal> 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 <Hello71> so i'm not sure your concern is actually addressed by the current system either
2021-01-08 17:53:40 <Hello71> yes, but we're talking about fsck now
2021-01-08 17:54:32 <minimal> 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 <minimal> 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 <Hello71> right, but my point is that there's no point running swclock before fsck
2021-01-08 17:55:44 <Hello71> hwclock could be useful
2021-01-08 17:56:35 <minimal> 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 <Hello71> well i think the idea is to avoid time going backwards
2021-01-08 17:57:18 <Hello71> which is the main problem because it breaks make-style freshness check
2021-01-08 17:58:11 <minimal> 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 <minimal> 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 <Hello71> but that's not swclock or ntp, that's hwclock
2021-01-08 18:02:46 <minimal> 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 <minimal> 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 <Hello71> 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 <minimal> yupe and as I said already I agreed that non-RTC machines are generally problematic
2021-01-08 18:24:29 <Frassle> .
2021-01-08 18:24:43 <Frassle> 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 <Frassle> 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 <Frassle> The initial commit to add it was just picked up reviewed by someone, but this one hasn't.
2021-01-08 18:28:06 <Hello71> there is some busyness related to 3.13 release soon(tm)
2021-01-08 18:29:15 <Frassle> 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 <Frassle> 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 <Frassle> install/uninstall from that repo, or I could submit that APKBUILD to aports?
2021-01-08 18:32:35 <Frassle> 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 <Frassle> 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 <Cogitri> Well, I doubt anyone is interested in maintaining dotnet when no one introduced the APKBUILD for it yet
2021-01-08 19:36:44 <artok> Frassle: protoc ?
2021-01-08 19:38:36 <artok> protoc, protobuf stuff is neatly packaged on alpine
2021-01-08 20:28:14 <ignapk> 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 <ignapk> 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 <Hello71> 100 layers deep or 100 entries each
2021-01-08 21:02:09 <ikke> ignapk: An MR or issue will work
2021-01-08 21:02:40 <Frassle> 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 <Frassle> https://github.com/grpc/grpc/issues/18428
2021-01-08 21:05:12 <ignapk> 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 <ignapk> ikke: Ok
2021-01-08 21:06:13 <Hello71> ah, it is actually a bug
2021-01-08 21:07:12 <Hello71> MAX_SRCFILE_DEPTH is actually just the number of includes
2021-01-08 21:07:47 <ignapk> yes
2021-01-08 21:08:40 <Hello71> probably it would be better to fix that
2021-01-08 21:08:45 <Hello71> or at least rename it if there is no fix
2021-01-08 21:56:12 <MY-R> 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 <ikke> MY-R: you can add default_openrc in that function it will move it to the subpackage
2021-01-08 22:01:57 <MY-R> 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 <mps> 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 <ikke> you need ntp at that point, not?
2021-01-08 22:10:27 <mps> if net works yes
2021-01-08 22:11:03 <mps> (but these people like 'yak shaving')
2021-01-08 22:11:56 <MY-R> isnt like clock then is set up based on some files modification date/time?
2021-01-08 22:12:15 <MY-R> isnt accurate but at least not year 1970
2021-01-08 22:12:22 <mps> I wanted to say that there is no perfect solution to that problem
2021-01-08 22:12:30 <MY-R> ye that for sure
2021-01-08 22:13:05 <MY-R> that is why I cant understand why producing devices without rtc :\
2021-01-08 22:13:15 <mps> there is fakeclock somewhere, which remembers last time when machine saves datetime and read it on boot
2021-01-08 22:13:32 <ikke> yeah, that's the only option without network
2021-01-08 22:14:03 <mps> not perfect (or good well) but usable for fsck problem
2021-01-08 22:14:33 <ikke> because fsck is based on time?
2021-01-08 22:14:39 <ikke> fsck schedule
2021-01-08 22:14:56 <mps> for some old FS it was based on time
2021-01-08 22:15:15 <ikke> nowadays they use the amount of mounts, right?
2021-01-08 22:15:54 <mps> 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 <mps> 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 <mps> with journals this is not needed
2021-01-08 22:17:46 <ikke> nod
2021-01-08 22:18:06 <ikke> I read somewhere today that kernels can do journal replays
2021-01-08 22:18:13 <mps> in case of serious FS corruption user will be informed by 'harsh' message
2021-01-08 22:18:46 <mps> and then offline fsck could help, as it helped me few times
2021-01-08 22:19:48 <mps> yes, at least ext4 fs driver can 'replay' (and it does) uncommited  journals
2021-01-08 22:23:47 <minimal> @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 <mps> minimal: I don't think such change is needed for alpine, sorry if I look harsh
2021-01-08 22:25:57 <minimal> 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 <mps> yes, agree
2021-01-08 22:26:47 <mps> and we are not 'universal OS'
2021-01-08 22:27:31 <minimal> 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 <mps> 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 <minimal> which problem?
2021-01-08 22:28:21 <Hello71> 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 <mps> jitterentropy-rngd
2021-01-08 22:28:44 <ikke> Hello71: haa
2021-01-08 22:28:45 <minimal> mps: what's the problem? The updated version I submitted was merged.
2021-01-08 22:28:46 <ikke> aha*
2021-01-08 22:28:59 <Hello71> it works fine with alpine 3.12 and alpine edge docker
2021-01-08 22:29:02 <mps> minimal: merged, then ok
2021-01-08 22:29:13 <Hello71> unfortunately they don't have deb-src so idk how their package is different
2021-01-08 22:29:16 <ikke> Hello71: you mean as a host?
2021-01-08 22:29:20 <Hello71> yes
2021-01-08 22:29:23 <ikke> ok
2021-01-08 22:29:32 <ikke> Did you try overriding the seccom profile?
2021-01-08 22:29:58 <minimal> 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 <Hello71> not yet, it works with seccomp=unconfined
2021-01-08 22:32:07 <ikke> right, 2 others confirmed that as well
2021-01-08 22:32:08 <mps> minimal: I just created rng-tools upgrade MR
2021-01-08 22:32:21 <ikke> Hello71: did you override it on dockerd level, or just that specific container?
2021-01-08 22:32:31 <Hello71> --security-opt=seccomp=unconfined
2021-01-08 22:32:36 <mps> some CIs looks stuck
2021-01-08 22:32:42 <minimal> mps: I raised rng-tools upgrade MR 5+ hours ago
2021-01-08 22:32:47 <ikke> ok, can you try to start dockerd with --seccomp-profile
2021-01-08 22:33:01 <ikke> (passing it the latest profile)
2021-01-08 22:33:04 <mps> minimal: too late ;)
2021-01-08 22:33:11 <Hello71> also I was thinking maybe it is related to kernel config?
2021-01-08 22:33:23 <mps> minimal: number?
2021-01-08 22:33:24 <Hello71> yes, that was my next step, but need to head out atm
2021-01-08 22:33:30 <minimal> 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 <minimal> !16605
2021-01-08 22:33:51 <ikke> Hello71: lol, everyone seems to stall at that step :P
2021-01-08 22:33:58 <mps> heh, you should tell here
2021-01-08 22:34:16 <mps> !67348
2021-01-08 22:34:20 <ikke> mps: there are some long running jobs
2021-01-08 22:34:28 <ikke> but they seem to still continue
2021-01-08 22:34:50 <mps> !16620
2021-01-08 22:36:37 <minimal> 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 <minimal> so my MR is more comprehensive than yours
2021-01-08 22:38:10 <mps> minimal: yes. and your MR looks more complete, only -openrc part doesn't look good (too much imo)
2021-01-08 22:38:57 <ignapk> made the MR https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16621
2021-01-08 22:39:11 <minimal> 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 <ignapk> 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 <mps> minimal: small, simple ...
2021-01-08 22:40:06 <minimal> 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 <mps> minimal: no, I like to keep useless open MRs around :P
2021-01-08 22:40:53 <mps> where is jitterentropy-library
2021-01-08 22:41:22 <minimal> its a new aport - was merged earlier today into "testing"
2021-01-08 22:42:04 <mps> aha, iiuc you want it moved to main before rng-tools upgrade
2021-01-08 22:43:43 <minimal> 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 <mps> minimal: understand. for such changes I wouldn't mess before asking maintainer
2021-01-08 22:46:06 <MY-R> 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 <minimal> 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 <mps> minimal: such mails should be 'Cc'-ed to alpine-devel ML
2021-01-08 22:48:28 <minimal> 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 <MY-R> me either, east europe
2021-01-08 22:49:21 <minimal> 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 <mps> MY-R: you are in country of saunas, iirc
2021-01-08 22:50:44 <minimal> 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 <MY-R> more like country of alcoholics and thieves :D
2021-01-08 22:50:59 <minimal> MY-R: moi!
2021-01-08 22:51:08 <mps> :)
2021-01-08 22:51:35 <MY-R> .pl
2021-01-08 22:52:09 <mps> MY-R: I thought you are in finland
2021-01-08 22:52:24 <MY-R> nope
2021-01-08 22:52:45 <minimal> mps: maybe you misunderstood when he said he was finnished ;-)
2021-01-08 22:52:53 <MY-R> ps so how is with firefox currently? stable? crashing? :\
2021-01-08 22:52:57 <MY-R> hehe
2021-01-08 22:52:57 <mps> :D
2021-01-08 22:53:33 <mps> minimal: good joke, I have to keep stomach
2021-01-08 22:54:06 <mps> long time I didn't saw stable FF
2021-01-08 22:54:28 <mps> though it works most of time, on edge and 3.12
2021-01-08 22:54:28 <minimal> mps: so what happens if your rng-tool MR gets merged rather than mine?
2021-01-08 22:54:49 <mps> minimal: I will hold my for now
2021-01-08 22:55:02 <minimal> thanks
2021-01-08 22:56:04 <minimal> 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 <mps> but please, try to make -openrc changes smaller
2021-01-08 22:57:00 <mps> minimal: also I have some mails exchanged with rng-tools upstream
2021-01-08 22:57:27 <minimal> 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 <minimal> s/have/had/g
2021-01-08 22:58:11 <alpine-meetbot> 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 <mps> minimal: and look at my commit message
2021-01-08 22:59:01 <minimal> mps: saw it, was there something I'd missed?
2021-01-08 22:59:13 <mps> minimal: yes, these 'self explanatory' is what looks not nice to me
2021-01-08 22:59:52 <mps> minimal: no, everything is ok with your MR, except -openrc
2021-01-08 23:00:45 <mps> huh, midnight passed, time to stop babbling here
2021-01-08 23:01:15 <minimal> 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 <minimal> yupe, its late here too
2021-01-08 23:04:42 <mps> minimal: overall your changes are good, and I'm not against that you take maintainership
2021-01-08 23:06:25 <minimal> 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 <HRio> anybody tested the rc3 extended iso? does not work at all for me, seems the kernel package is not in place (no /lib/modules/<version> etc), and quite a lot of warnings during boot
2021-01-08 23:12:57 <HRio> 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 <HRio> but too late in the night for me now to continue
2021-01-08 23:14:02 <HRio> (with pass, I am refering to a virtual disk as I am testing in a VM)
2021-01-09 00:41:14 <Hello71> ikke, ncopa: finally figured this shit out. you need docker 19.03.9 *and* libseccomp 2.5.0
2021-01-09 00:47:26 <Hello71> 2.4.2 i mean
2021-01-09 00:48:14 <Hello71> and debian buster is stuck on 2.3.3
2021-01-09 01:19:18 <Hello71> grumble grumble grumble
2021-01-09 01:31:41 <Hello71> dammit and I already deleted my raspbian :/
2021-01-09 01:52:49 <TBK[m]> Just stumbled upon https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/587
2021-01-09 03:42:59 <Hello71> 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 <Hello71> unsurprisingly
2021-01-09 06:36:06 <craftyguy> are old alpine packages archived someplace?
2021-01-09 07:15:32 <craftyguy> ah I guess getting it from a stable release branch is good enough
2021-01-09 08:16:19 <ikke> Hello71: Nice find!
2021-01-09 08:41:36 <Ariadne> 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 <fcolista> 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 <fcolista> this affects also how py3-qt5 is built
2021-01-09 09:28:13 <Cogitri> I'm not sure if we even want to upgrade to 6.0.0?
2021-01-09 09:28:41 <Cogitri> 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 <Ariadne> most likely, we will ship qt5/qt6 simultaneously
2021-01-09 09:56:54 <Ariadne> but, qt really needs to be forked
2021-01-09 09:57:01 <Ariadne> the qt company is not a responsible steward
2021-01-09 09:57:24 <Ariadne> if a qt fork happens, i doubt many will care about qt6
2021-01-09 09:57:52 <Ariadne> 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 <Cogitri> 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 <Cogitri> Well, Qt5 OSS is basically unmaintained now AFAIU
2021-01-09 09:59:54 <Cogitri> Other than things like Qt5WebEngine
2021-01-09 10:04:49 <mps> qt should go to /dev/null long ago
2021-01-09 10:10:54 <ikke> lots of software depending on qt in some form
2021-01-09 10:14:09 <mps> yes, and that is also not good
2021-01-09 10:14:11 <Ariadne> mps: it is still better than gtk
2021-01-09 10:14:52 <mps> yes, and that is also not good
2021-01-09 10:14:55 <mps> :)
2021-01-09 10:15:24 <Ariadne> i think qt under real community governance would be fine
2021-01-09 10:15:37 <mps> I agree with this
2021-01-09 10:15:43 <Ariadne> the real problem is that the Qt company has fucked over the community hardcore
2021-01-09 10:15:50 <Ariadne> with qt6 and trying to 'monetize'
2021-01-09 10:16:11 <Ariadne> KDE folks want to fork Qt 5.15
2021-01-09 10:16:20 <Ariadne> and seem skittish on Qt 6
2021-01-09 10:16:38 <mps> actually I never tried to 'use' qt because of mentioned company
2021-01-09 10:37:16 <insep_> ikke: there's gtk->qt shim
2021-01-09 10:37:20 <insep_> if you want more
2021-01-09 10:37:46 <insep_> https://github.com/e8johan/gtk-made-qt
2021-01-09 10:55:05 <ikke> insep_: "This is very far from production ready. Feel free to improve!"
2021-01-09 10:55:27 <ikke> so, a nice poc, but still needs work
2021-01-09 10:58:47 <Cogitri> But GTK's nice :D
2021-01-09 11:03:30 <Ariadne> no it's not
2021-01-09 11:04:54 <ikke> I guess it would be best for KDE to fork Qt
2021-01-09 11:07:33 <Ariadne> GTK is great if you're a "GNOME app"
2021-01-09 11:07:43 <Ariadne> if you are not, it becomes not great very quickly
2021-01-09 11:07:59 <mps> gtk is great, though it is bad
2021-01-09 11:08:59 <ikke> "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 <ikke> Projects discoverying there _is_ merrit to dynamic linking
2021-01-09 11:09:25 <Ariadne> wow!  shocked!!
2021-01-09 11:19:54 <mps> jokes aside, but I think gtk is less bad of all gui toolkits we have
2021-01-09 11:20:07 <mps> least*
2021-01-09 11:20:36 <ikke> but we do not decide what toolkit projects use
2021-01-09 11:21:06 <mps> yes, but we can decide what to 'git rm'
2021-01-09 11:22:02 <ikke> We would drop gnome, kde, and with that, also what pmos does
2021-01-09 11:22:10 <Cogitri> I don't think deleting things which use Qt is an option
2021-01-09 11:22:46 <Cogitri> 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 <mps> unfortunately you are right
2021-01-09 11:24:54 <ikke> ~1200 packages have some dependency on qt5
2021-01-09 11:25:46 <ikke> in community
2021-01-09 11:33:38 <Cogitri> mps: Could you take a look at !16605
2021-01-09 11:41:26 <ikke> Hello71: do you happen to know what specific change in libseccomp fixes this issue?
2021-01-09 11:42:20 <Cogitri> 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 <Cogitri> 
ACTION has no clue about python

2021-01-09 11:43:27 <ikke> I think it can run tests on the system as well
2021-01-09 11:48:06 <artok> https://pypi.org/project/tox-current-env/ plugin is needed
2021-01-09 11:49:53 <ikke> "Well, it turns out that tox became too popular and gained another purpose."
2021-01-09 11:54:45 <artok> nicely put
2021-01-09 11:57:57 <Cogitri> heh
2021-01-09 11:58:05 <Cogitri> ikke: Could you test !16046 on armhf?
2021-01-09 12:03:26 <ikke> Cogitri: ok, let me try
2021-01-09 12:03:56 <PureTryOut[m]2> When projects use tox, you can most of the time still just run pytest
2021-01-09 12:06:46 <Cogitri> Okie, I guess would be best to just do that then
2021-01-09 12:07:33 <Cogitri> 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 <ikke> 3.9 officially is still supported until 3.13 is released :)
2021-01-09 12:15:05 <dne> bind release model update: https://www.isc.org/blogs/2021-bind-release-model/
2021-01-09 12:15:14 <Cogitri> ikke: We should update https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases then
2021-01-09 12:15:27 <ikke> The dates are generally guides
2021-01-09 12:20:53 <ikke> Cogitri: building zstd now on armhf
2021-01-09 12:21:06 <mps> 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 <Cogitri> I guess since 3.13rc3 is already out 3.9 will be EOL in a few days though
2021-01-09 12:37:11 <ikke> yeah, would not take long
2021-01-09 12:37:17 <Cogitri> mps: Ah okay, I was just confused since we have two MRs for the same thing
2021-01-09 12:45:04 <mps> 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 <mps> 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 <mps> so much new games in MRs, averts me from useful ones
2021-01-09 12:50:16 <mps> maybe is time to create 'useless' subdir in aports ;P
2021-01-09 12:50:48 <jvoisin> :D
2021-01-09 13:04:01 <ikke> Cogitri: Bus error (core dumped)
2021-01-09 13:06:19 <Cogitri> Ah, zstd on armhf?
2021-01-09 13:06:34 <ikke> yes
2021-01-09 13:06:43 <Cogitri> 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 <Cogitri> Is there a coredump somewhere?
2021-01-09 13:07:14 <ikke> I'd need to enable them, let me do that
2021-01-09 13:07:53 <ikke> oh, ulimit -c was already unlimited
2021-01-09 13:08:05 <ikke> ./src/zstd-1.4.8/tests/core
2021-01-09 13:08:13 <ikke> so yes, there is a coredump
2021-01-09 13:10:14 <Cogitri> Could you get  backtrace of that?
2021-01-09 13:10:26 <Cogitri> mps: !16162 how come you only approved it and didn't merge it?
2021-01-09 13:10:56 <ikke> Cogitri: need to figure out what executable produced that coredump
2021-01-09 13:12:07 <Cogitri> I think dmesg logs that
2021-01-09 13:12:49 <ikke> zstd -f tmp from the playtests.sh
2021-01-09 13:13:24 <ikke> ok, can repro it
2021-01-09 13:14:08 <ikke> https://tpaste.us/zxOa
2021-01-09 13:14:56 <Cogitri> OK, thanks, posted it on the MR
2021-01-09 13:15:38 <ikke> trying to build it with no optimizations
2021-01-09 13:16:39 <ikke> aaaand no more coredump
2021-01-09 13:18:21 <Cogitri> Huh
2021-01-09 13:18:26 <Cogitri> As in it works?
2021-01-09 13:18:53 <ikke> zstd -f tmp
2021-01-09 13:19:10 <ikke> that first gave a bus error, now no longer does, trying to increase optimization step by step
2021-01-09 13:19:14 <ikke> see if that makes a different
2021-01-09 13:19:23 <ikke> difference
2021-01-09 13:20:09 <Cogitri> 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 <PureTryOut[m]2> 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 <ikke> :/
2021-01-09 13:23:02 <ikke>  Merged by Rasmus Thomsen 1 hour ago
2021-01-09 13:23:52 <ikke> I guess revert it
2021-01-09 13:23:54 <maxice8> 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 <Cogitri> Yuck, somehow I thought I checked out CI and it only failed due to upload size
2021-01-09 13:24:28 <Cogitri> But I guess that was the other KDE MR
2021-01-09 13:24:39 <Cogitri> Maybe you could mark known broken MRs as WIP though
2021-01-09 13:28:27 <Cogitri> Want me to revert it?
2021-01-09 13:28:30 <PureTryOut[m]2> 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 <PureTryOut[m]2> Yes please, for now
2021-01-09 13:29:33 <ikke> 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 <ikke> Cogitri: interesting, it looks like make check builds everything again, and then it gives the error
2021-01-09 13:30:23 <Cogitri> Huh
2021-01-09 13:31:13 <ikke> if I run abuild build and then do ../zstd -f tmp, it goes through
2021-01-09 13:31:52 <ikke> testing now make check again
2021-01-09 13:32:51 <ikke> yes
2021-01-09 13:33:16 <ikke> so abuild -r -> coredump; followed by abuild build -> success; followed by make check -> coredump
2021-01-09 13:35:19 <ikke> Cogitri: might have to do with the flags being passed
2021-01-09 13:35:46 <ikke> make check needs the same flags as make
2021-01-09 13:37:23 <mps> Cogitri: re !16162 I wait for 3.13 builders to finish with crystal
2021-01-09 13:38:04 <mps> build fails in my dev lxc but ncopa told that it somehow passed builders
2021-01-09 13:38:32 <mps> in meantime I forgot this MR
2021-01-09 13:38:42 <ikke> Cogitri: updated MR
2021-01-09 13:38:45 <ikke> comment
2021-01-09 13:39:03 <ikke> always fun with make
2021-01-09 13:39:35 <mps> Cogitri: I will merge it and pray ;)
2021-01-09 13:41:05 <mps> huh, interesting commit msgs 'alpine/aports:master | Eric Tian | Apply 1 suggestion(s) to 1 file(s) |'
2021-01-09 13:42:38 <ikke> mps: that means someone pressed the 'apply suggestions' button after a reviewer added a suggested edit
2021-01-09 13:43:15 <mps> whatever, but msgs are bad
2021-01-09 13:43:23 <ikke> yes, blame gitlab
2021-01-09 13:43:44 <ikke> And there is no way that you can force someone to at least supply a sane commit message
2021-01-09 13:43:58 <ikke> So we need to be dilligent to review the commit messages as well
2021-01-09 13:44:36 <mps> hmm, that means 'burden on commiters back'
2021-01-09 13:45:07 <ikke> well, you need to verify the commit messages anyway
2021-01-09 13:45:46 <ikke> inbefore CI for commit messages
2021-01-09 13:46:06 <Cogitri> Yes, forgot to check the squash commits button, sorry
2021-01-09 13:46:30 <Cogitri> Thought Gitlab did that automatically when you apply suggestions
2021-01-09 13:46:34 <ikke> nope
2021-01-09 13:46:40 <ikke> it just appens useless commits
2021-01-09 13:46:42 <ikke> appends
2021-01-09 13:46:44 <Cogitri> :/
2021-01-09 13:47:50 <ikke> The only thing you can do is to override the commit message template
2021-01-09 13:49:05 <ikke> https://ibb.co/NTH9P26
2021-01-09 13:49:52 <Cogitri> Doesn't look too helpful either :/
2021-01-09 13:49:55 <ikke> nope
2021-01-09 13:51:57 <ikke> https://gitlab.com/gitlab-org/gitlab/-/issues/25381
2021-01-09 13:54:53 <ikke> I can modify our update hook to look for these kinds of messages
2021-01-09 14:07:13 <Hello71> 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 <Hello71> 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 <ikke> Hello71: thanks
2021-01-09 14:24:30 <Hello71> ubuntu backported libseccomp 2.4.3 in https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055
2021-01-09 14:37:33 <Hello71> 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 <Hello71> as pointed out in the ubuntu bug I didn't actually read
2021-01-09 14:38:09 <Hello71> which means that Arch doesn't work either despite having up-to-date libseccomp
2021-01-09 14:46:38 <Hello71> wait, no, I just didn't pass -t x86
2021-01-09 14:46:41 <Hello71> -a
2021-01-09 14:52:09 <minimal> 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 <minimal> 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 <minimal> s/has/saw/g
2021-01-09 14:53:38 <alpine-meetbot> 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 <minimal> s/saw/was/g
2021-01-09 14:53:46 <alpine-meetbot> 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 <Hello71> 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 <mps> minimal: still looks too big for me, both init and conf files
2021-01-09 15:14:47 <mps> our moto is: small, simple, secure^W
2021-01-09 15:15:27 <mps> in other word: minimal :)
2021-01-09 15:17:18 <minimal> 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 <mps> 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 <minimal> 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 <mps> then you can extend docs
2021-01-09 15:21:29 <mps> I'm really disappointed by postfix default files in /etc/postfix
2021-01-09 15:22:19 <mps> not to talk about vim default installed files
2021-01-09 15:23:08 <minimal> mps: so if I shrink conf.d more but leave init.d as is that make you happy?
2021-01-09 15:23:37 <mps> minimal: I'm already happy, no worries :)
2021-01-09 15:24:41 <mps> minimal: and I don't want to force you to do anything, just expressing my POV
2021-01-09 15:25:24 <mps> any other developer is free to merge MR, I will not object
2021-01-09 15:26:56 <mps> minimal: and I have tell again, your work on rng is really good imo
2021-01-09 15:27:05 <minimal> 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 <minimal> 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 <mps> noticed that
2021-01-09 16:07:51 <PureTryOut[m]2> 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 <ikke> 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 <PureTryOut[m]2> 👍️
2021-01-09 16:09:40 <ikke> Kind of defeating the purpose
2021-01-09 16:27:23 <HRio> anybody that have tested a rc3 x86_64 installer yet?
2021-01-09 16:28:09 <HRio> get no souch file or directory from modprobe during boot (/lib/modules is missing on the iso)
2021-01-09 16:28:32 <ikke> HRio: not yet, but let me try
2021-01-09 16:28:41 <HRio> s/souch/such/
2021-01-09 16:28:41 <alpine-meetbot> 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 <HRio> /etc/apk/world shows only alpine-base and openssl as installed
2021-01-09 16:31:01 <ikke> on the installed system?
2021-01-09 16:31:11 <HRio> directly after boot
2021-01-09 16:31:19 <HRio> before running setup-alpine
2021-01-09 16:31:50 <HRio> 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 <ikke> boot from iso?
2021-01-09 16:32:27 <HRio> ys
2021-01-09 16:32:29 <HRio> yes
2021-01-09 16:32:31 <ikke> ok
2021-01-09 16:32:37 <HRio> tried boot iso boot in xen and in kvm
2021-01-09 16:32:59 <ikke> trying it now in kvm
2021-01-09 16:33:48 <ikke> HRio: noticing the same
2021-01-09 16:34:17 <ikke> mount /dev/loop0 on /.modloop failed: invalid argument
2021-01-09 16:34:46 <HRio> yes see that as well
2021-01-09 16:40:37 <HRio> could it be something caused by this change perhaps? https://gitlab.alpinelinux.org/alpine/aports/-/commit/83f9f23d95c58c6c956d33b1141c971b4922a712
2021-01-09 16:41:11 <HRio> not sure if that is used when packing iso
2021-01-09 16:41:21 <ikke> no
2021-01-09 16:41:45 <ikke> bootstrap should not be used for that
2021-01-09 16:41:54 <HRio> k
2021-01-09 16:45:11 <ikke> the files on the iso are the same
2021-01-09 16:47:27 <HRio> seems same on the standard iso
2021-01-09 16:48:21 <ikke> yes, I'm using standard
2021-01-09 16:48:31 <ikke> The issue is that it cannot mount modloop for some reason
2021-01-09 16:54:19 <HRio> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/commit/30e6933e71fc18ff5bcb5a7d9dad105e464272bf seems to have been merged yesterday
2021-01-09 16:55:21 <ikke> ncopa did have some issues with the modloop
2021-01-09 16:55:24 <HRio> https://gitlab.alpinelinux.org/alpine/aports/-/commit/da0e91f15ec8b8babbd76ae3205bfdac9765a188
2021-01-09 17:05:38 <ikke> HRio: unsquashfs has no issues reading the modloop file
2021-01-09 17:06:01 <Hello71> check dmesg
2021-01-09 17:06:51 <ikke> yes, was thinking about that
2021-01-09 17:07:22 <ikke> no output
2021-01-09 17:07:39 <ikke> /proc/filesystems lists squashfs
2021-01-09 17:08:18 <Hello71> ah, ncopa merged the old version...
2021-01-09 17:08:29 <Hello71> or did I push the old version
2021-01-09 17:08:48 <Hello71> nah, I pushed the old version :(
2021-01-09 17:08:53 <ikke> oof
2021-01-09 17:09:02 <ikke> of alpine-conf?
2021-01-09 17:09:06 <Hello71> -nopad makes it impossible to mount
2021-01-09 17:09:12 <ikke> ouch
2021-01-09 17:10:48 <Hello71> I fixed it but then accidentally re-added it when fixing ncopa comments
2021-01-09 17:11:19 <ikke> HRio: would you mind opening an issue for this?
2021-01-09 17:13:39 <Hello71> https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/13
2021-01-09 17:13:53 <Hello71> big oof, sorry all
2021-01-09 17:14:07 <HRio> #12285
2021-01-09 17:14:15 <ikke> HRio: thanks
2021-01-09 17:16:29 <Hello71> it's not just standard and extended, it should be broken on all isos on all archs -.-
2021-01-09 17:17:19 <Hello71> real big oof
2021-01-09 17:19:39 <Hello71> 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 <Hello71> s=$(stat -c %s modloop); truncate -s $((s+4096-s%4096)) modloop
2021-01-09 20:29:19 <maxice8> What reason we have to keep security issues private ?
2021-01-09 20:30:27 <ikke> maxice8: heh, was wondering the same
2021-01-09 20:30:31 <ikke> Well, I know the reason
2021-01-09 20:30:44 <ikke> maxice8: this is regarding the dovecot issue, right?
2021-01-09 20:30:47 <maxice8> yes
2021-01-09 20:31:33 <ikke> The official reason is that it doens't become a repository of unpatched issues in Alpine
2021-01-09 20:31:33 <mps> to be members of 'security theater'
2021-01-09 20:32:15 <ikke> But I was wondering if we should reconsider this
2021-01-09 20:32:42 <mps> not if we get sec info in advance
2021-01-09 20:32:59 <ikke> sure, but that's not the case for most of the issues
2021-01-09 20:33:17 <mps> true
2021-01-09 20:33:32 <ikke> I don't remember us receiving any embargoed vulnerabilities in advance
2021-01-09 20:33:34 <mps> and dovecot is already known
2021-01-09 20:33:56 <ikke> We're not on the list, so to speak
2021-01-09 20:34:32 <mps> well, I don't have idea what is proper action for these things
2021-01-09 20:35:00 <ikke> Archlinux has public issues for public vulnerabilities
2021-01-09 20:35:52 <mps> personally I'm for 'openness', when we know something don't hide it
2021-01-09 20:37:36 <mps> but if open everything we know we could be 'attacked' in press/media as irresponsible 'team'
2021-01-09 20:37:40 <Cogitri> I think it's still a good idea to have it hidden
2021-01-09 20:38:16 <Cogitri> So users can't search for tag:security in issues and see every sec issue
2021-01-09 20:38:56 <mps> Cogitri: users are not problem, dark side/net usually knows these in advance
2021-01-09 20:39:04 <Hello71> can't they already search for cves
2021-01-09 20:39:08 <ikke> yes
2021-01-09 20:39:09 <Hello71> or other distros issues
2021-01-09 20:39:13 <ikke> there is software that does all that
2021-01-09 20:39:20 <Cogitri> Yes, but we don't have to make it easier than it has to be
2021-01-09 20:40:25 <ikke> If we do or job good, the list of unpatched vulns should be small
2021-01-09 20:42:01 <Cogitri> 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 <Cogitri> because it's so much effort to port things back
2021-01-09 20:42:25 <Cogitri> And testing stuff is annoying too when backporting isn't trivial :3
2021-01-09 21:57:39 <Hello71> 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 <dalias> not afaik
2021-01-09 22:26:16 <Hello71> uh, i mean default-pie and default -z now
2021-01-09 23:19:20 <Hello71> also, how is the decision made to put things in *FLAGS vs builtin specs
2021-01-10 04:32:17 <Ariadne> 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 <bratkartoffel> good morning and happy new year folks
2021-01-10 08:24:02 <bratkartoffel> someone got time to check !15294?
2021-01-10 08:25:03 <ikke> bratkartoffel: can that perhaps wait until after the 3.13 release?
2021-01-10 08:25:44 <bratkartoffel> ah yes, forgot about the announcement. sure
2021-01-10 08:25:50 <mps> bratkartoffel: happy new year
2021-01-10 11:12:55 <ikke> 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 <mps> rust is used as pretext for https://xkcd.com/303/
2021-01-10 12:46:11 <alpine-meetbot> 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 <ikke> :)
2021-01-10 12:49:15 <Cogitri> 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 <mps> this is understandable, rust is made to replace c++, compiling speed is achieved :)
2021-01-10 12:53:42 <exception> lol
2021-01-10 12:53:49 <Cogitri> Heh
2021-01-10 13:08:45 <Hello71> ikke: yes, I was thinking about it too
2021-01-10 13:09:00 <Hello71> but then I was thinking that wiki is not goos
2021-01-10 13:09:12 <Hello71> d
2021-01-10 13:14:32 <mps> anyone knows is lxcfs used for anything now
2021-01-10 13:35:26 <ikke> Hello71: We need to make it good :-)
2021-01-10 13:36:35 <ikke> Hello71: need to fight the broken window syndrome
2021-01-10 14:17:50 <exception> ikke: where to start with making it "good"
2021-01-10 14:18:21 <ikke> exception: somewhere, anywhere
2021-01-10 14:19:29 <exception> So there is a wiki and the (newer) handbook. Are they supposed to co-exist?
2021-01-10 14:19:37 <ikke> yes
2021-01-10 14:20:04 <exception> I see
2021-01-10 14:21:15 <mps> no! :)
2021-01-10 14:21:39 <mps> wiki should go to /dev/null or gitlab.a.o
2021-01-10 14:42:59 <ikke> mps: we have docs.a.o
2021-01-10 14:43:47 <mps> yes, we have it but I'm talking about wiki
2021-01-10 14:44:34 <exception> would be nice if u can just commit to the wiki with git
2021-01-10 14:45:09 <mps> exception: we have docs repo
2021-01-10 14:45:19 <exception> but what is supposed to go where
2021-01-10 14:45:24 <mps> and #alpine-docs channel
2021-01-10 14:45:37 <exception> I will just ask it there then, ty
2021-01-10 14:45:50 <mps> docs should be official documentation
2021-01-10 14:46:28 <mps> and wiki (ofc on gitlab.a.o) random wiki pages
2021-01-10 14:49:00 <ikke> problem with the wiki on gitlab is that you don't really have merge commits
2021-01-10 14:49:08 <ikke> merge requests*
2021-01-10 14:49:31 <ikke> So only members of the project can push to the wiki repo, and without any review
2021-01-10 16:27:22 <jammers> ncopa I noticed the Vbox kernel modules have been missing since 3.09. Is that intentional?
2021-01-10 16:27:23 <jammers> The userspace components are still acive in the current 3.13 repo.
2021-01-10 16:31:30 <PureTryOut[m]2> Got another case of CI only failing because of too big artifacts 😛 !16569 is ready for merging
2021-01-10 16:34:01 <Cogitri> 
ACTION carefully examines CI logs

2021-01-10 16:34:02 <Cogitri> :D
2021-01-10 16:34:36 <ikke> lol
2021-01-10 16:35:29 <Hello71> jammers: what modules? and what is 3.09
2021-01-10 16:36:31 <PureTryOut[m]2> Haha
2021-01-10 16:38:53 <jammers> 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 <Hello71> 3.12 still has virtualbox-guest-modules-* https://pkgs.alpinelinux.org/packages?name=virtualbox*&branch=v3.12
2021-01-10 16:40:25 <Hello71> 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 <ikke> The kernel now has guest-module built-in
2021-01-10 16:41:11 <Hello71> 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 <Hello71> and vboxguest
2021-01-10 17:02:50 <jammers> I'll update my  repo entries  and try again in 3.12, maybe something was wrong there.
2021-01-10 17:02:51 <jammers> 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 <jammers> 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 <jammers> 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 <skarnet> 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 <mps> I don't like idea to run random software from internet on my computers :)
2021-01-10 19:11:20 <ikke> ?
2021-01-10 19:11:36 <mps> jk with skarnet
2021-01-10 19:12:35 <skarnet> I hope you tell the same joke to every upstream you have
2021-01-10 19:13:25 <mps> 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 <skarnet> ah yes, the great petty saltiness
2021-01-10 19:14:14 <mps> np, as wrote just kidding. your software is ok
2021-01-10 19:23:34 <ikke> https://github.com/Rust-GCC/gccrs
2021-01-10 19:23:41 <ikke> gcc front-end for rust
2021-01-10 19:44:04 <Hello71> Ariadne: what do you reckon about the risks of -fno-plt then?
2021-01-10 20:19:08 <andypost[m]> Looks few builders stuck on building stunnel
2021-01-10 20:19:51 <ikke> :/
2021-01-10 20:24:45 <ikke> weird\
2021-01-10 20:25:05 <ikke> I straced an orphaned process which seems to have segfaulted, and afterwards everything seems to continue
2021-01-10 20:44:31 <andypost[m]> Now it passed, thanks! Please check ruby build on 3.12 if possible
2021-01-10 20:54:00 <ikke> seems to be deadlocked :-/
2021-01-10 20:54:15 <ikke> https://bugs.ruby-lang.org/issues/17189
2021-01-10 20:54:19 <ikke> I guess that
2021-01-10 20:54:54 <ikke> although, 3.12 is still musl 1.2
2021-01-10 20:54:59 <ikke> although, 3.12 is still musl 1.1.24
2021-01-10 21:29:51 <yZ5vlALg86lP> 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 <yZ5vlALg86lP> http pages work though.
2021-01-10 21:30:34 <ikke> yZ5vlALg86lP: haven't heard about this yet
2021-01-10 21:30:58 <yZ5vlALg86lP> 84.0.2-r0
2021-01-10 21:36:48 <TBK[m]> somebody with main write permissions please accept !16700
2021-01-10 21:36:58 <ikke> thanks
2021-01-10 21:53:44 <skarnet> don't merge it before !16685 though, else you'll have to rebuild it again
2021-01-10 21:59:54 <TBK[m]> skarnet: it was merged after ;)
2021-01-10 22:44:08 <maxice8> 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 <Ariadne> gcc-10.2.1_pre1-r2 depends on:
2021-01-11 02:58:14 <Ariadne> binutils
2021-01-11 02:58:14 <Ariadne> libgomp=10.2.1_pre1-r2
2021-01-11 02:58:14 <Ariadne> libatomic=10.2.1_pre1-r2
2021-01-11 02:58:16 <Ariadne> hmm
2021-01-11 02:58:26 <Ariadne> depends are being polluted from subpackages it seems
2021-01-11 03:10:02 <Ariadne> dunno, this is some ncopa-level shit
2021-01-11 03:32:14 <Hello71> looks right to me?
2021-01-11 03:32:30 <Hello71> notwithstanding the questionable nature of gcc depending on binutils to start with
2021-01-11 04:10:31 <Ariadne> the libgphobos is not right
2021-01-11 04:10:56 <Ariadne> only gdc should depend on that.
2021-01-11 06:17:30 <Thermi> 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 <Thermi> Seems like the test suite needs at least 253.6 MiB of space in /dev/shm
2021-01-11 06:18:27 <Thermi> The default is 64M
2021-01-11 06:18:55 <Thermi> My box has 32GiB of memory, so seems like it's fixed.
2021-01-11 07:54:23 <Thermi> ncopa: mps thoughts?
2021-01-11 08:08:25 <fcolista> ncopa, re osinfo-db: - the script should be integrated in docker-alpine?
2021-01-11 08:08:25 <fcolista> - the script should create a MR to libosinfo?
2021-01-11 08:11:12 <ncopa> morning
2021-01-11 08:11:26 <ikke> morning
2021-01-11 08:11:33 <fcolista> _0/
2021-01-11 08:11:48 <ikke> ncopa: rc3 is broken in case you missed it
2021-01-11 08:12:08 <ncopa> fcolista: no, we should not integrate osinfo-db in docker alpine
2021-01-11 08:12:12 <ncopa> ikke: oh how so?
2021-01-11 08:12:25 <fcolista> ok so is a standalone script
2021-01-11 08:12:28 <ikke> ncopa: Hello71 accidentally sent the wrong ersion of a patch
2021-01-11 08:12:38 <ikke> -nopad breaks the modloop (cannot be mounted)
2021-01-11 08:13:11 <ncopa> hum.. i thought i tested that
2021-01-11 08:13:20 <ncopa> lets revert it
2021-01-11 08:13:36 <ikke> ncopa: Hello71 sent an MR
2021-01-11 08:13:57 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/alpine-conf/-/merge_requests/13
2021-01-11 08:14:48 <ncopa> so we need an rc4...
2021-01-11 08:14:57 <ncopa> is rc3 completely broken on all arches?
2021-01-11 08:15:33 <ikke> I haven't tested other arches
2021-01-11 08:15:41 <ikke> but at least x86_64
2021-01-11 08:16:07 <ikke> you already see it when you want to boot from the iso
2021-01-11 08:16:58 <mps> known meme: don't make releases on friday :)
2021-01-11 08:17:57 <mps> Thermi: what about? my inet link is unstable in last days so I don't see context
2021-01-11 08:18:44 <mps> Thermi: about /dev/shm ?
2021-01-11 08:18:49 <Thermi> mps: yes
2021-01-11 08:19:49 <mps> what pkg use /dev/shm as storage? that package is 'bad', to not use more harsh words
2021-01-11 08:19:51 <ncopa> thats embarrasing
2021-01-11 08:20:28 <Thermi> mps: Well, I'm putting it together right now
2021-01-11 08:20:36 <Thermi> mps: it's the test suite of libmdbx that does that
2021-01-11 08:20:51 <Thermi> I could just sed all the paths, TBH. Is /tmp better?
2021-01-11 08:21:16 <mps> sure, /tmp is intended for such things
2021-01-11 08:21:30 <ikke> mps: what is /dev/shm intended for?
2021-01-11 08:22:03 <mps> ikke: mostly for IPC
2021-01-11 08:22:31 <ikke> aha
2021-01-11 08:23:19 <mps> unix from beginning have /tmp for files
2021-01-11 08:24:46 <mps> and idea with /dev/shm is/was for small files used for interproccess communication
2021-01-11 08:25:35 <ikke> 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 <mps> also, this is my 'impression'
2021-01-11 08:56:30 <Ariadne> 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 <Thermi> 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 <Thermi> The massive patch file adds the test suite for build time checking
2021-01-11 09:18:55 <Thermi> Immediately found an issue.
2021-01-11 09:18:56 <Thermi>  %)
2021-01-11 09:20:20 <Thermi> fiiiixxxxxeeeddd
2021-01-11 09:23:11 <Thermi> oh ffs
2021-01-11 09:29:21 <omni> would someone want to work with me on this? https://gitlab.alpinelinux.org/alpine/aports/-/issues/12176
2021-01-11 09:30:02 <omni> workarounds should be mentioned in 3.13 release notes unless there is a fix
2021-01-11 10:46:58 <ncopa> whats up with gcc?
2021-01-11 10:47:57 <ikke> ncopa: From what I read is that the dependency from gcc on libgphobos is unexpected
2021-01-11 10:49:22 <ikke> ncopa: https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/minicom/minicom-2.8-r0.log
2021-01-11 10:51:09 <ikke> seems like armhf and armv7 still clobber eachother
2021-01-11 10:51:32 <ncopa> looks like that yes
2021-01-11 10:51:37 <ncopa> i think i need to fix gcc first
2021-01-11 10:51:40 <ikke> sure
2021-01-11 10:51:47 <ikke> just wanted to point it out
2021-01-11 10:51:54 <ikke> armv7 says it found a partial download
2021-01-11 10:52:27 <ncopa> did libucontext ABI change?
2021-01-11 10:56:06 <ncopa> yes it did
2021-01-11 10:56:19 <ncopa> $ apk info --provides libucontext
2021-01-11 10:56:19 <ncopa> libucontext-0.13.1-r0 provides:
2021-01-11 10:56:19 <ncopa> libucontext-1.0-r0 provides:
2021-01-11 10:56:19 <ncopa> so:libucontext.so.1=1
2021-01-11 10:56:19 <ncopa> so:libucontext.so.0=0
2021-01-11 10:56:19 <ncopa> so:libucontext_posix.so.1=1
2021-01-11 10:57:11 <ncopa> if any of the gcc dependencies has a ABI breakage, special handling is needed
2021-01-11 10:59:32 <ncopa> its the same for isl d1f8d455bebf7d8b2f87f2bd75c53b9d0ff76a24 , gmp cb8fc691289c17163bef935c5bdef160c15f9423, mpfr 1a495321f9047492196280b09534c6d1478f2bcd
2021-01-11 11:00:36 <ncopa> so if gcc now also depends on libucontxt, then special care is needed when upgrading ABI breaking changes
2021-01-11 11:01:33 <ikke> So all gcc dependencies should be explicitly versioned?
2021-01-11 11:01:36 <ncopa> Ariadne: is 9486c3a6cfe02daf4237c42d63b20102ddc41a67 really necessary?
2021-01-11 11:01:38 <ncopa> yes
2021-01-11 11:02:37 <ncopa> 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 <ncopa> im sorry if im a bit grumpy today. my monday could have been better
2021-01-11 11:03:25 <ikke> Should it be reverted?
2021-01-11 11:04:00 <ncopa> (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 <ikke> oof
2021-01-11 11:04:54 <ncopa> 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 <ncopa> i suppose i need to spend time on reading the libuconxt gitlog to find out
2021-01-11 11:06:07 <ikke> :(
2021-01-11 11:10:13 <ncopa> https://github.com/kaniini/libucontext/blob/master/NEWS#L14
2021-01-11 11:10:43 <mps> is the libucontext needed for gcc
2021-01-11 11:10:54 <ncopa> its used by s390x and mips64
2021-01-11 11:11:09 <mps> better question will be 'why'
2021-01-11 11:11:22 <ncopa> no clue
2021-01-11 11:11:40 <ncopa> my guess is that  D needs it
2021-01-11 11:12:02 <mps> ahmm
2021-01-11 11:13:25 <mps> :D lang
2021-01-11 11:16:16 <ikke> ncopa: ariadne wondered why subpackage dependencies leaked to main gcc
2021-01-11 11:16:44 <ncopa> i think it is due to a bug in abuild
2021-01-11 11:17:28 <ncopa> the split function for gdc sets depends which is a global variable
2021-01-11 11:17:47 <ncopa> but hum.. does not really make sense
2021-01-11 11:20:19 <mps> ncopa: go to some martial art course where you can learn to fall safely (aikido, judo or similar)
2021-01-11 11:21:26 <ncopa> the abuild bug is bad news
2021-01-11 11:21:39 <ncopa> im pretty sure fixing it will break other stuff
2021-01-11 11:22:02 <ikke> ncopa: What is the bug?
2021-01-11 11:22:15 <ikke> It looks like subpackage function are run in a subshell
2021-01-11 11:22:26 <ncopa> setting depends in a split function should not set the global depends
2021-01-11 11:22:29 <ncopa> it looks like it does
2021-01-11 11:22:36 <ikke> https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L859
2021-01-11 11:23:02 <ikke> Sounds like something we could confirm in an abuild test
2021-01-11 11:23:22 <ikke> I think
2021-01-11 11:23:45 <ncopa> good idea. exactly what we should do
2021-01-11 11:52:22 <Ariadne> yeah the problem is with gcc dependencies being leaked
2021-01-11 11:52:36 <Ariadne> that needs fixed, then we just temporarily disable D on mips64/s390x
2021-01-11 11:53:42 <ncopa> i think i fixed the libucontext by adding libucontext0 with the .so.0 only
2021-01-11 11:54:01 <Ariadne> yeah that's fine for now
2021-01-11 11:54:09 <ncopa> im building gcc on x86_64 now to investigate how the depends leaks
2021-01-11 11:54:29 <Ariadne> yeah good plan, because ada stuff also leaks through
2021-01-11 11:56:13 <Ariadne> (and yes, D falls back to libucontext when there is no native implementation available)
2021-01-11 11:59:58 <ncopa> i am afraid we cannot fix the leaking
2021-01-11 12:00:08 <ncopa> im pretty sure it will break other stuff that depends on it
2021-01-11 12:00:41 <ikke> Should we fix it at some point?
2021-01-11 12:00:45 <ncopa> yes
2021-01-11 12:01:28 <ncopa> i think first step is to create a testcase in abuild.git/tests
2021-01-11 12:01:36 <ikke> nod
2021-01-11 12:01:44 <ncopa> with the behavior we want
2021-01-11 12:01:54 <ncopa> then we fix the packages that depends on broken behavior
2021-01-11 12:02:11 <Ariadne> i wonder if we should consider reworking APKBUILD format in general
2021-01-11 12:02:33 <Ariadne> but thats a longer term conversation for sure
2021-01-11 12:02:35 <ncopa> we shoudl have done that long time ago
2021-01-11 12:02:38 <ncopa> but yes
2021-01-11 12:02:52 <ikke> Ariadne: what do you have in mind?
2021-01-11 12:02:59 <Cogitri> What do you have in mind for a rework?
2021-01-11 12:03:02 <ikke> lol
2021-01-11 12:03:03 <Cogitri> Ah, ikke was faster :D
2021-01-11 12:03:14 <ncopa> 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 <ncopa> and we need to do the change incremental
2021-01-11 12:03:51 <ncopa> with backwards compatibility
2021-01-11 12:04:19 <Ariadne> the ability to have something more capable than posix shell scripting would be nice
2021-01-11 12:04:32 <ncopa> yup
2021-01-11 12:04:48 <ikke> Should be something fairly self-contained though
2021-01-11 12:04:55 <Cogitri> So something like flatpak yaml/json?
2021-01-11 12:05:03 <ikke> meh
2021-01-11 12:05:06 <caskd> 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 <Ariadne> i'm thinking "makefiles, but with YAML front matter"
2021-01-11 12:05:41 <Ariadne> if you have a common "runner" you can support the current format alongside the new one
2021-01-11 12:06:03 <ikke> yaml is nice for metadata, but not for build instructions
2021-01-11 12:06:04 <Cogitri> caskd: The latter should be the default in a new value
2021-01-11 12:06:25 <ncopa> anyway, i think we should prioritize fixing the builders and getting rc4 out
2021-01-11 12:06:31 <ncopa> and 3.13.0
2021-01-11 12:06:35 <ncopa> then we can discuss new format
2021-01-11 12:06:55 <Cogitri> YML is OK for building simple builds but it'd probably be hell for chromium :D
2021-01-11 12:07:08 <caskd> oh yeah
2021-01-11 12:07:26 <ncopa> 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 <Ariadne> Cogitri: hince yaml for data and makefile syntax for the actual steps
2021-01-11 12:07:43 <ncopa> maybe we should have some video call at some point for brainstorming
2021-01-11 12:07:51 <Ariadne> i can mock up an example of what i have in mind
2021-01-11 12:07:58 <Ariadne> inheritance would also be nice
2021-01-11 12:07:58 <ncopa> that would be perfect
2021-01-11 12:08:06 <ncopa> mockups are good
2021-01-11 12:08:09 <ikke> Is Makefile syntax an improvement on poxic sh?
2021-01-11 12:08:15 <ikke> posix*
2021-01-11 12:08:18 <Ariadne> ikke: yes, we can do inheritance with it
2021-01-11 12:08:36 <ncopa> alpine 1.8 had makefiles
2021-01-11 12:08:49 <skarnet> package manager syntax is... complicated
2021-01-11 12:09:04 <ncopa> the problem was (is) that its complicated and difficult for people to understand
2021-01-11 12:09:17 <ikke> difficult to debug
2021-01-11 12:09:34 <skarnet> also, my experience with yaml was netplan, and it was not a good experience
2021-01-11 12:09:47 <ncopa> the "posix" shell syntax is dead simple and transparent about what is happening
2021-01-11 12:09:52 <Ariadne> (well, what i really mean is shell fragments)
2021-01-11 12:10:10 <skarnet> shell fragments are good
2021-01-11 12:10:16 <mps> oh no, reinvent the world again
2021-01-11 12:10:19 <ncopa> i have been thinking in the direction rpm's .spec format or maybe even bash (ala void)
2021-01-11 12:10:35 <skarnet> 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 <Ariadne> rpm spec is probably the worst option
2021-01-11 12:11:04 <mps> to the pointed of squared wheel
2021-01-11 12:11:20 <mps> point*
2021-01-11 12:11:34 <Ariadne> rpmbuild is basically a glorified preprocessor that spits out a shell script and runs it
2021-01-11 12:11:45 <detha> 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 <Ariadne> if in doubt, do the opposite of whatever RPM does ^_^
2021-01-11 12:12:00 <ncopa> ha
2021-01-11 12:12:32 <skarnet> 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 <jvoisin> (having changelogs would be nice as well ♥ )
2021-01-11 12:13:06 <mps> for me APKBUILD is good
2021-01-11 12:13:08 <insep_> nix anyone?
2021-01-11 12:13:14 <Ariadne> 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 <ncopa> 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 <mps> insep_: you are kidding with us
2021-01-11 12:13:38 <skarnet> Ariadne: agreed, APKBUILD is good for building, but not for interacting with other tools that need package data
2021-01-11 12:13:49 <jvoisin> ncopa: same experience for me: packaging with APKBUILD has been a breeze compared to Debian.
2021-01-11 12:13:53 <insep_> yes
2021-01-11 12:13:55 <ncopa> detha: that was exactly the goal of the the APKBUILD format
2021-01-11 12:14:09 <Ariadne> jvoisin: ok, we can go back to alpine 1.8 :D
2021-01-11 12:14:24 <mps> detha: I had same experience from debian build system to apkbuild
2021-01-11 12:14:55 <mps> Ariadne: not bad idea :)
2021-01-11 12:15:06 <Ariadne> alpine 1.8 was makefiles
2021-01-11 12:15:06 <skarnet> 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 <Ariadne> like debian
2021-01-11 12:15:08 <Ariadne> :P
2021-01-11 12:15:19 <skarnet> that just need the var data*
2021-01-11 12:15:23 <detha> 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 <Ariadne> skarnet: my idea was to just have the shell fragments as metadata under `phases` or whatever
2021-01-11 12:15:44 <ncopa> 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 <ncopa> 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 <Ariadne> yep
2021-01-11 12:16:30 <skarnet> ncopa: you can do syntactic wonders with eval
2021-01-11 12:16:34 <ncopa> i know
2021-01-11 12:16:37 <skarnet> and by wonders, I mean marvels of ugliness
2021-01-11 12:16:46 <ncopa> but i dont really dont want go that route...
2021-01-11 12:16:50 <ncopa> eval is evil :)
2021-01-11 12:16:56 <Ariadne> skarnet: i think we should avoid lowering the bus factor of abuild to 1 person
2021-01-11 12:16:58 <Ariadne> :P
2021-01-11 12:17:08 <skarnet> you mean it's greater than 1 right now? :P
2021-01-11 12:17:13 <Ariadne> yes
2021-01-11 12:17:15 <Ariadne> mostly
2021-01-11 12:17:37 <Ariadne> 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 <skarnet> or - hear me out - the thing could, maybe, perhaps... be documented?
2021-01-11 12:18:22 <Ariadne> docuwhat
2021-01-11 12:18:26 <skarnet> *insert meme with skarnet being thrown out the window*
2021-01-11 12:18:34 <ncopa> :D
2021-01-11 12:18:36 <Ariadne> that sounds like fancy google shit
2021-01-11 12:18:58 <andypost[m]> any idea what's wrong with libucontext on s390x https://gitlab.alpinelinux.org/andypost/aports/-/jobs/290954
2021-01-11 12:19:25 <Ariadne> we fixed it already
2021-01-11 12:19:26 <ncopa> andypost[m]: yeah. fix is in the oven
2021-01-11 12:19:33 <Ariadne> well 'fixed'
2021-01-11 12:19:34 <ncopa> 07b24a1af666200053ac6be89579ce6a4e579350
2021-01-11 12:19:59 <Ariadne> the real problem is abuild dependency pollution
2021-01-11 12:20:09 <Ariadne> causing deps to trickle where they shouldn't be
2021-01-11 12:20:25 <skarnet> how does that happen?
2021-01-11 12:20:27 <ncopa> depending on how you see things, the fundamental underlying problem was the abi breakage in libucontext
2021-01-11 12:20:37 <ncopa> or in the dependency pollution
2021-01-11 12:21:01 <ncopa> i dunno how the depds polution happened. the abuild script run the split function in a subshell
2021-01-11 12:21:09 <Ariadne> well, the soname bump was unfortunate indeed
2021-01-11 12:21:10 <ncopa> so something does not works as expected
2021-01-11 12:21:24 <andypost[m]> thank you, threading is fragile everytime
2021-01-11 12:21:27 <Ariadne> yes, i expected it to not be needing special handling due to it only being gdc
2021-01-11 12:21:44 <Ariadne> and then i found out libgphobos is a dep on gcc itself
2021-01-11 12:21:50 <Ariadne> needless to say, that was surprising
2021-01-11 12:21:52 <ncopa> imho, the abi breakage was the problem, depends leak in gcc package separate issue
2021-01-11 12:22:27 <Ariadne> in fairness when libucontext was packaged, i was not expecting it to become a dependency of gcc :P
2021-01-11 12:22:41 <ncopa> understandable. i dont blame anyone
2021-01-11 12:22:42 <Ariadne> otherwise i would have packaged as libucontext0 to begin with
2021-01-11 12:23:07 <ncopa> this one of those things to keep in mind when messing with gcc
2021-01-11 12:23:13 <skarnet> ah yes, package managers that cannot handle several versions of the same package
2021-01-11 12:23:31 <ncopa> yup. its a design thing
2021-01-11 12:23:37 <skarnet> and that need naming shenanigans, thus delegating management to maintainers
2021-01-11 12:23:42 <ncopa> we intentionally imlemented it like that
2021-01-11 12:24:02 <skarnet> I honestly can't fathom why
2021-01-11 12:24:26 <Ariadne> mostly because that's the behavior of other managers (primarily apt) that we wanted to model
2021-01-11 12:24:32 <ncopa> more than a decade ago. when things were truly small and simple
2021-01-11 12:24:44 <skarnet> sigh
2021-01-11 12:24:59 <ncopa> we were ofc aware of the problem it caused, but had workarounds (rename package)
2021-01-11 12:25:18 <Ariadne> fwiw that might get revisited for apk3
2021-01-11 12:25:19 <ncopa> and believe me, the package manager is complicated enough as it is
2021-01-11 12:25:31 <ncopa> im not sure its worth it
2021-01-11 12:25:49 <ncopa> it creates a new set of problems
2021-01-11 12:25:55 <Ariadne> it is true that tracking multiple packages for a given apk_name is a problem
2021-01-11 12:26:02 <skarnet> 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 <skarnet> and you're not ready for that :P
2021-01-11 12:26:49 <Ariadne> 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 <Ariadne> apk (and other package managers like it) were built to maintain system images
2021-01-11 12:27:26 <ikke> people like apk because it's fast
2021-01-11 12:27:38 <Ariadne> end-user applications should be containerized imo
2021-01-11 12:29:57 <ikke> The problem is how to make sure dependencies are kept up-to-date
2021-01-11 12:31:07 <ikke> At least now, there is some pressure make sure things work together
2021-01-11 12:31:29 <ncopa> yeah
2021-01-11 12:32:41 <ncopa> anyone want to help make atest case for the leaking deps? abuild git repo abuild/tests
2021-01-11 12:33:49 <ikke> ncopa: I'm interested, but it would be tonight
2021-01-11 12:34:19 <ncopa> ok. thanks
2021-01-11 12:34:45 <ncopa> i think i'm gonna be busy with the modloop issue and kernel upgrade anyways
2021-01-11 12:34:48 <ncopa> will try get rc4 out today
2021-01-11 12:35:01 <ikke> Just wondering how we would verify this
2021-01-11 12:35:10 <ikke> Just build a package and verify dependencies?
2021-01-11 12:35:14 <ncopa> yeah
2021-01-11 12:35:16 <ikke> ok
2021-01-11 12:35:51 <ncopa> build package and verify that the dependencies are the way they should
2021-01-11 12:37:29 <ikke> oh, btw, another anoyance, ruby is hanging on 3.12
2021-01-11 12:38:17 <ikke> 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 <Thermi> all done peeps: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16709
2021-01-11 13:29:40 <Hello71> 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 <ncopa> 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 <Hello71> 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 <Hello71> 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 <ikke> Hello71: What is nightmarish about that?
2021-01-11 13:37:59 <Hello71> i mean if alpine packages were implemented in this language
2021-01-11 13:38:22 <ncopa> its a nightmare to try understand how it actually works, and debug things when they dont work
2021-01-11 13:38:36 <ikke> Hello71: Ah, missed your first message
2021-01-11 13:38:53 <ncopa> and its a nightmare to review patches from people not understaning how things works
2021-01-11 13:43:45 <Hello71> 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 <Hello71> if you wanted to go in the direction of make-style orchestration, a ninja generator might make sense
2021-01-11 13:44:49 <Hello71> Ariadne: what about nix?
2021-01-11 13:45:25 <ikke> ncopa: btw, I cleaned up the 3.13.0 milestone
2021-01-11 13:45:30 <Hello71> 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 <ncopa> awesome! thanks!
2021-01-11 13:45:35 <ikke> there are a few items left
2021-01-11 13:46:09 <ikke> We should keep the milestones clean to things we actually intend to fix in that milestone
2021-01-11 13:46:19 <ikke> There are lots of issues which just get bumped from milestone to milestone
2021-01-11 13:48:53 <Ariadne> imo if you want nix, you should go run nix
2021-01-11 13:50:12 <Hello71> well the problem as i said is that the current nix implementation is too heavy
2021-01-11 13:51:48 <Hello71> 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 <mps> software and philosophy :D
2021-01-11 13:56:06 <maxice8> foolosophy
2021-01-11 13:56:23 <mps> Hello71: I don't intend to insult you
2021-01-11 13:57:17 <mps> this was just 'shlagwort' for me
2021-01-11 13:57:27 <mps> schlagwort*
2021-01-11 13:57:51 <Ariadne> 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 <Hello71> mmhmm
2021-01-11 13:58:28 <Ariadne> if you're looking for alpine to become nix-like, i don't see it happening
2021-01-11 13:58:39 <Hello71> no
2021-01-11 13:58:43 <Ariadne> we seem to be solidly in the "debian, but not built on 1990s technology" lane
2021-01-11 13:59:27 <Hello71> yes, bourne shell is from 1970s :p
2021-01-11 14:00:13 <Ariadne> 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 <Ariadne> unfortunately, that comes at a high price
2021-01-11 14:01:02 <Ariadne> in nix, you don't just go and build stuff, you have to do it the nix way
2021-01-11 14:01:27 <Ariadne> which is cool
2021-01-11 14:03:16 <skarnet> 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 <skarnet> Apart from that, it's a good system.
2021-01-11 14:04:09 <gjabell> 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 <ikke> ncopa: I assume you killed ruby on 3.12-x86?
2021-01-11 14:35:51 <ncopa> ikke: i did
2021-01-11 14:35:54 <ncopa> and restarted it
2021-01-11 14:36:56 <ikke> ok
2021-01-11 15:13:48 <minimal> mps: existing rng-tools maintainer agreed for me to take over. Will now tweak !16605 to reflect this.
2021-01-11 15:22:45 <ncopa> 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 <mps> minimal: good news
2021-01-11 15:24:25 <mps> (except I broke important key on my workstation keyboard)
2021-01-11 15:26:51 <minimal> 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 <minimal> so rng-tools package would remain small and rng-tools-kitchensink would have everything in it ;-)
2021-01-11 15:28:12 <mps> minimal: I'm ok with this
2021-01-11 15:31:20 <minimal> mps: cool. suggestions for naming the kitchensink sub-package? rng-tools-complete? rng-tools-extra?
2021-01-11 15:31:40 <jvoisin> -extra
2021-01-11 15:34:08 <minimal> jvoisin: my thoughts as well, will go with that
2021-01-11 15:35:41 <jvoisin> or -bloat if you want to be passive-aggressive :P
2021-01-11 15:35:50 <maxice8> -huge
2021-01-11 15:37:39 <mps> kitchensink looks good
2021-01-11 15:39:35 <mps> 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 <mps> have to look at some other 'fine' pkgs :]
2021-01-11 15:41:52 <mps> ncopa: new seabios -128K is bigger that 128KB in new release
2021-01-11 15:42:14 <mps> about 135KB
2021-01-11 15:42:31 <minimal> 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 <mps> 'can be only one'
2021-01-11 15:54:19 <Ariadne> fwiw
2021-01-11 15:55:00 <Ariadne> 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 <Ariadne> if somebody agrees, it will be merged :P
2021-01-11 15:56:20 <minimal> 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 <maxice8> I have been thinking of dealing with maintainers
2021-01-11 16:01:19 <Ariadne> oh no
2021-01-11 16:01:44 <maxice8> I mean contacting ones that we have reason to believe are inactive
2021-01-11 16:01:54 <Ariadne> i'm going to wake up after 3.13 is released
2021-01-11 16:02:00 <Ariadne> and every APKBUILD i open
2021-01-11 16:02:02 <Ariadne> it's going to be
2021-01-11 16:02:06 <maxice8> and removing maintainership from the ones that do not get back in contact in $PERIOD_OF_TIME
2021-01-11 16:02:07 <Ariadne> # Maintainer: Leo <...>
2021-01-11 16:02:22 <maxice8> I don't even want to maintain my own packages
2021-01-11 16:02:53 <Ariadne> honestly mood
2021-01-11 16:03:31 <maxice8> 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 <ikke> 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 <ncopa> 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 <ncopa> 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 <ikke> ncopa: did the mt-fork patch fix the test suite in ruby for 1.2?
2021-01-11 16:13:18 <ncopa> i think it did
2021-01-11 16:13:33 <ncopa> oh
2021-01-11 16:13:42 <ncopa> i havent renabled the tests
2021-01-11 16:16:41 <ncopa> in any case, the test_thread.rb deadlocks with musl 1.1.24 (alpine 3.12-stable)
2021-01-11 16:17:51 <ikke> yeah, would be a good indicator whether the mt-fork patch fixes it
2021-01-11 16:17:59 <Hello71> 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 <Hello71> or maybe even higher risk
2021-01-11 16:19:19 <Hello71> 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 <maxice8> Rolling Release Alpine 😎
2021-01-11 16:20:26 <ncopa> edge is the rolling variant
2021-01-11 16:20:30 <maxice8> ^ emoji with sunglasses for the deficient of emojis
2021-01-11 16:20:52 <ncopa> :)
2021-01-11 16:21:07 <ikke> 👍
2021-01-11 16:21:09 <ncopa> the ruby tests passes on x86_64
2021-01-11 16:21:37 <Hello71> if patching ruby is a pain, what if we just don't update it in 3.12
2021-01-11 16:21:57 <Hello71> same with libvirt
2021-01-11 16:22:06 <ikke> it's not just about updating
2021-01-11 16:22:18 <ikke> I can imagine this leading to bugs / hangs for end-users too
2021-01-11 16:22:35 <ncopa> we have open bugs for libvirt already
2021-01-11 16:22:42 <ikke> We notice it with gitlab too
2021-01-11 16:22:49 <ikke> gitaly-ssh
2021-01-11 16:22:58 <ncopa> does gitaly-ssh work with current edge?
2021-01-11 16:23:04 <ikke> haven't tested it yet
2021-01-11 16:23:11 <ikke> hard to test
2021-01-11 16:23:22 <Hello71> tell them to use 3.13. prerequisite: get 3.13 out
2021-01-11 16:23:36 <ncopa> ikke: try install musl from edge
2021-01-11 16:24:06 <ncopa> Hello71: we still need to maintain 3.12, add security fixes there etc
2021-01-11 16:24:33 <Hello71> idk, is it more work to fix the malloc after fork or to pull a debian
2021-01-11 16:25:02 <ikke> currently 20 gitaly-ssh processes (hanging?)
2021-01-11 16:25:31 <ncopa> so, my thinking is that maybe we could backport the malloc stuff ffor maul 1.1.24
2021-01-11 16:25:46 <ncopa> s/maul/musl/
2021-01-11 16:25:47 <alpine-meetbot> 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 <ncopa> but i'd like to hear dalias opinion on what options we have
2021-01-11 16:27:59 <ikke> 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 <insep_> does anyone just happen to have pre-1.9 copy aports?
2021-01-11 16:28:46 <insep_> would like to see how those makefiles looked lik
2021-01-11 16:28:47 <insep_> e
2021-01-11 16:31:43 <ikke> I guess that was in svn?
2021-01-11 16:35:03 <ikke> cannot find anything
2021-01-11 16:40:20 <ncopa> it was in svn yes
2021-01-11 16:40:30 <clandmeter> We imported svn iirc
2021-01-11 16:40:31 <ncopa> i dont htink i have the svn history anywhere
2021-01-11 16:42:43 <ncopa> might be i have it on a cdrom somewhere
2021-01-11 16:43:25 <ncopa> insep_: also, back thn we built alpine packages using gentoo's ebuild
2021-01-11 18:05:09 <dalias> ncopa, hm?
2021-01-11 18:07:09 <ncopa> hi dalias! hope you are doing good :)
2021-01-11 18:07:23 <dalias> 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 <ncopa> ok. so there is no easy way to backport the fixes for malloc-after-fork?
2021-01-11 18:08:40 <ncopa> i suppose thats what i expected, but i just wanted to confirm
2021-01-11 18:14:28 <dalias> 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 <dalias> if i were trying to bring this into an old stable dist..
2021-01-11 18:14:56 <ikke> 3.12 is not old :P
2021-01-11 18:15:29 <dalias> 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 <dalias> :-P
2021-01-11 18:16:12 <dalias> 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 <dalias> 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 <dalias> 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 <ikke> I don't think we can
2021-01-11 18:17:20 <ikke> it would break all 32-bits arches
2021-01-11 18:18:24 <dalias> no, that's why i said shipping the 1.1.24 headers as dev package
2021-01-11 18:18:48 <dalias> there is no abi breakage in existing abi going from 1.1.x to 1.2.x
2021-01-11 18:19:01 <ikke> ah ok
2021-01-11 18:19:26 <dalias> but is this really getting hit in real world now?
2021-01-11 18:19:45 <ikke> libvirt, ruby
2021-01-11 18:19:47 <dalias> 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 <ikke> dalias: I'm not certain, but we seem to be hitting it in gitlab
2021-01-11 18:20:21 <ikke> gitaly-ssh processes getting stuck for FUTEX_WAIT
2021-01-11 18:20:40 <ikke> I've upgraded musl in the gitlab container to see if that solves it
2021-01-11 18:23:04 <ikke> I guess this is the libvirt issue: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12007
2021-01-11 19:08:18 <maxice8> 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 <maxice8> bound to have fun false positives like fcolista's gmail
2021-01-11 19:09:17 <ikke> yay, I'm in there
2021-01-11 19:09:40 <ikke> with 2 different e-mail addresses no less
2021-01-11 19:10:11 <maxice8> <ikke "yay, I'm in there"> Congrats
2021-01-11 19:19:18 <Hello71> 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 <Hello71> as a first pass
2021-01-11 19:29:20 <maxice8> Don't think it will change all that much
2021-01-11 19:29:36 <maxice8> 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 <mps> also i'm listed with one character in real name :)
2021-01-11 19:43:13 <mps> wrong character*
2021-01-11 19:43:42 <maxice8> Extracted from Maintainer: field of APKBUILDs
2021-01-11 19:43:58 <mps> huh, lets fix it
2021-01-11 20:28:32 <mps> does this looks ok for merge !16718
2021-01-11 20:28:44 <ikke> it was already merged
2021-01-11 20:28:58 <mps> ikke: this one is for 3.12
2021-01-11 20:29:01 <ikke> aha
2021-01-11 20:29:47 <mps> I still feel fear of merging on previous releases
2021-01-11 20:30:19 <ikke> looks ok
2021-01-11 20:30:23 <ikke> it's an upstream patch
2021-01-11 20:30:38 <mps> yes
2021-01-11 20:30:58 <mps> just talked with upstream on #irssi
2021-01-11 21:25:00 <afontain_> heh, I'm not in the list because I did a tiny change :P
2021-01-11 21:49:14 <maxice8> I need help writing nice emails
2021-01-11 22:04:39 <Hello71> "Dear sir/madam,"
2021-01-11 22:08:47 <ikke> I'd like to inform you of a fire
2021-01-11 22:16:52 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12293 :D
2021-01-11 22:21:29 <ikke> Quite a task
2021-01-11 22:21:40 <maxice8> yes
2021-01-11 22:23:03 <maxice8> My only fear is not replacing the $VARIABLES in the mail template
2021-01-11 22:23:20 <ikke> heh
2021-01-11 22:26:56 <ikke> What packages do you have for me btw?
2021-01-11 22:27:39 <maxice8> I was supposed to ?
2021-01-11 22:28:22 <ikke> no, sorry
2021-01-11 22:28:34 <ikke> I meant something different
2021-01-11 22:28:42 <ikke> but I can just check the e-mail addresses
2021-01-11 22:34:48 <maxice8> :D you going to help ?
2021-01-11 22:35:22 <ikke> It's too late for me, I'm not explaining myself well
2021-01-11 22:35:38 <maxice8> Around 22:35 ?
2021-01-11 22:35:48 <ikke> I was just cruous what packages I maintained that were flagged
2021-01-11 22:35:51 <ikke> yes
2021-01-11 22:35:58 <maxice8> no packages were flagged
2021-01-11 22:36:16 <ikke> mentioned in that list then :P
2021-01-11 22:37:14 <maxice8> 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 <ikke> 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 <ikke> by me
2021-01-11 22:38:10 <maxice8> not touched, likely one you have an old email
2021-01-11 22:38:38 <ikke> yes, updating them now
2021-01-11 22:38:42 <maxice8> community/markdown for me@ikke.info
2021-01-11 22:38:57 <ikke> right, but that package does not have any updates either
2021-01-11 22:39:16 <maxice8> piknik pugixml flickcurl colord-gtk for ops@ikke.info
2021-01-11 22:39:24 <ikke> right
2021-01-11 22:39:47 <ikke> last commits to markdown were all metadata fixes
2021-01-11 22:42:23 <maxice8> heh
2021-01-11 22:42:24 <maxice8> got my first reply
2021-01-11 22:42:32 <ikke> nice
2021-01-11 22:47:02 <maxice8> h1-cli lives!
2021-01-11 22:53:09 <maxice8> and another answered, didn't use for 2-3 years
2021-01-11 22:53:18 <maxice8> [Alpine Linux] being the thing used in this case
2021-01-11 22:55:43 <ikke> font-api source is awol
2021-01-11 22:55:47 <ikke> ipa
2021-01-11 22:55:55 <maxice8> heh
2021-01-11 22:56:36 <maxice8> disabled
2021-01-11 22:59:53 <ikke> I have an MR to update all my maintainer adresses
2021-01-11 23:01:41 <maxice8> ty
2021-01-11 23:01:43 <ikke> sigh
2021-01-11 23:01:52 <ikke> checking build system type... Invalid configuration `x86_64-pc-linux-musl': machine `x86_64-pc-linux' not recognized
2021-01-11 23:02:07 <ikke> and config.sub + config.guess are already being updated
2021-01-11 23:02:14 <ikke> oh, not sub
2021-01-12 00:17:06 <TBK[m]> ddevault: Was it a mistake in 6c6ed7f62bd62650c5196315d1c8a67d8a0b9991 to set Bartłomiej as the maintainer?
2021-01-12 00:17:31 <ddevault> how should I know
2021-01-12 00:17:36 <ddevault> that was more than 2 years ago
2021-01-12 00:17:40 <ddevault> presumably I asked first
2021-01-12 00:18:15 <ddevault> since that was the only change it probably would not have passed review otherwise
2021-01-12 03:07:33 <maxice8> the big As are done
2021-01-12 03:24:52 <maxice8> Left instructions on how to do it for https://gitlab.alpinelinux.org/alpine/aports/-/issues/12293
2021-01-12 07:03:12 <ncopa> morning
2021-01-12 07:03:22 <ncopa> 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 <ncopa> dn lookup failed for some reason
2021-01-12 07:07:58 <ncopa> i suspect the request timed out
2021-01-12 07:21:04 <ncopa> ikke: im killing ruby on the 3.12 builders
2021-01-12 07:21:21 <ncopa> looks like you are running a gdb there
2021-01-12 07:23:08 <ncopa> im disabling the ruby tests
2021-01-12 07:30:32 <ikke> ncopa: thanks, yes, was doing that in deed
2021-01-12 07:30:47 <ikke> feel free to kill it
2021-01-12 07:32:27 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/85
2021-01-12 08:17:37 <ncopa> nice! thanks
2021-01-12 08:27:21 <ncopa> i want to tag rc4 now
2021-01-12 08:30:02 <ikke> builders are churning on plasma atm
2021-01-12 08:33:00 <Cogitri> Should go through without problems though, was only URL fixes
2021-01-12 08:33:57 <ncopa> ok good
2021-01-12 08:34:00 <mps> on #musl dalias wrote that the 1.2.2 will be released soon
2021-01-12 08:34:19 <mps> yesterday
2021-01-12 08:34:23 <ikke> "today"
2021-01-12 08:34:45 <mps> announced yesterday, I mean
2021-01-12 08:35:01 <ikke> Soryr, yes, it was not a reaction to you
2021-01-12 08:35:16 <mps> last night actually
2021-01-12 08:35:30 <mps> ikke: ah, sorry then
2021-01-12 08:54:23 <ikke> 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 <ikke> I saw this on several builders
2021-01-12 08:54:34 <ikke> (just an fyi)
2021-01-12 09:07:37 <ikke> ncopa: except for edge/mips64, all builders seem idle now
2021-01-12 09:23:44 <ncopa> ok. lets tag rc4 then
2021-01-12 09:24:07 <ncopa> i suspect the stunnel problem is related busybox update
2021-01-12 09:24:27 <ikke> s390x is having network issues lately
2021-01-12 09:24:52 <mps> ncopa: do you remember why we have seabios in two sizes, 128k and 256k
2021-01-12 09:35:04 <ncopa> mps: i dont. wgat does git log say?
2021-01-12 09:35:30 <ncopa> i think there might been somethign that might have needed 128k at some point, but i dont remember
2021-01-12 09:43:21 <andypost[m]> ikke: I bet network issues could be solved with options="net" for golang pkgs
2021-01-12 09:44:02 <ikke> andypost[m]: why would that help?
2021-01-12 09:44:16 <ikke> The builders are not using rootbld
2021-01-12 09:44:23 <ikke> It's just random timeouts
2021-01-12 09:44:54 <andypost[m]> Got it, thanks for explanation
2021-01-12 09:45:19 <ikke> 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 <ikke> ncopa: would it help to install a caching dns forwarded on the s390x builder host?
2021-01-12 09:46:29 <ikke> We already have dnsmasq
2021-01-12 09:48:38 <ncopa> possibly
2021-01-12 09:48:53 <ncopa> we could use unbound or something
2021-01-12 09:49:23 <ikke> dnsmasq should do caching as well, right?
2021-01-12 09:49:37 <ikke> the edge builder is using the local dnsmasq as resolver
2021-01-12 09:49:56 <ikke> I did add extra nameservers to the host (it had only one)
2021-01-12 09:51:21 <ikke> "read udp 172.16.10.4:41454->172.16.10.1:53: i/o timeout"
2021-01-12 09:51:38 <ikke> 172.1.6.10.1:53 is dnsmasq on the host, strange
2021-01-12 09:58:20 <Ariadne> IP conflict ?
2021-01-12 10:01:08 <mps> ncopa: git log doesn't tell anything. maybe it is made small to fit in some flash devices
2021-01-12 10:01:48 <mps> whatever reason was new release doesn't fit to 128KB
2021-01-12 10:02:16 <mps> maybe could if some things 'trimmed out'
2021-01-12 10:04:46 <ikke> Ariadne: does not look like it
2021-01-12 10:18:55 <mps> 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 <mps> seabios 1.14.0
2021-01-12 10:51:52 <ncopa> 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 <ikke> ncopa: do we want to wait on the musl 1.2.2 official release?
2021-01-12 10:52:22 <ikke> or do we just upgrade it once released
2021-01-12 10:52:40 <ncopa> depends. if its released to day we include it
2021-01-12 10:52:53 <ncopa> i dont think we will wait another week for it
2021-01-12 10:53:22 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11695
2021-01-12 10:53:24 <ikke> ?
2021-01-12 10:53:47 <ncopa> it has not happened so i guess we post pone it
2021-01-12 10:53:58 <ikke> ok
2021-01-12 10:54:01 <mps> 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 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12176
2021-01-12 10:54:40 <ncopa> oh, we shoudl clean up the broken deps
2021-01-12 10:54:46 <mps> or make alpine rolling distro only :)
2021-01-12 10:55:13 <ikke> mps: just use edge :)
2021-01-12 10:55:50 <mps> I do, mostly, except on important servers
2021-01-12 10:56:12 <mps> even on servers I backport some pkgs
2021-01-12 10:56:51 <ncopa> hum #12176 might be tricky
2021-01-12 11:04:24 <ncopa> $ 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 <ncopa> https://tpaste.us/jn5l
2021-01-12 11:06:09 <ncopa> interesting that llvm10 depends on llvm10-dev
2021-01-12 11:06:33 <ncopa> perl-lwp-protocol-https should be moved to main, due to abuild depends on it
2021-01-12 11:10:44 <ncopa> we also need to move wireguard-tools
2021-01-12 11:10:56 <ncopa> which makes sense now that we have wireguard in mainline kernel
2021-01-12 11:18:08 <ncopa> 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 <Ariadne> ok that's fine
2021-01-12 11:18:52 <Ariadne> it does work fine
2021-01-12 11:19:00 <Ariadne> and kernels do support it
2021-01-12 11:37:26 <ikke> 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 <Ariadne> tcpdump from which side
2021-01-12 12:22:23 <ikke> from the host, but I just wrote it to a file and analized it with wireshark
2021-01-12 12:22:37 <Cogitri> 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 <mps> Cogitri: ah, I thought it is still in unmaintained
2021-01-12 12:23:30 <mps> why OP didn't told name of pkg
2021-01-12 12:24:26 <Cogitri> 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 <mps> yes, I see
2021-01-12 12:27:44 <mps> so Carl wants to move back all these pkgs removed with 3ce3c4fd596debefbad77328a9b62a39eccf753c :)
2021-01-12 12:29:06 <mps> I don't hate much things (if anything) but I really dislike alpine ML (please do not comment)
2021-01-12 12:30:27 <Cogitri> I've come to accept it for discussions, but +1 on that for patches on the ML
2021-01-12 12:31:26 <Cogitri> But fortunately we won't have to interact with it any more soon thanks to ddevault's work
2021-01-12 12:56:50 <mps> https://blog.gtk.org/2021/01/12/gtk-4-0-1/
2021-01-12 13:15:45 <mps> I'm thinking to add /etc/man.conf to mandoc. It is in mentioned FILES in man.1
2021-01-12 13:15:55 <mps> any objections
2021-01-12 13:23:24 <omni> ncopa: any suggestions on things to try or look at/into are welcome, wrt #12176
2021-01-12 13:23:53 <omni> I mentioned it in #openzfs yesterday but no response yet
2021-01-12 13:29:41 <ncopa> have you tried this? https://gitlab.alpinelinux.org/alpine/aports/-/issues/12176#note_134334
2021-01-12 13:31:11 <omni> gah! you can't search the zfs manpages any longer since they're split up!
2021-01-12 13:31:47 <omni> ncopa: no, I haven't
2021-01-12 13:34:58 <omni> 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 <omni> I'd like to know why it worked before and what's changed since
2021-01-12 13:37:09 <omni> ('zgrep legacy /usr/share/man/man*/z{fs,pool}*' is what you have to do now)
2021-01-12 14:18:54 <Hello71> ikke: you mean for the dns?
2021-01-12 14:20:08 <ikke> In wireshark I do see both request and response
2021-01-12 14:27:16 <HRio> any objections to merging !16738 ?
2021-01-12 14:33:26 <ikke> hmm, no, I still do not see the response from the external DNS server
2021-01-12 14:37:40 <Ariadne> what external DNS are you using
2021-01-12 14:37:48 <ikke> in this case 1.1.1.1
2021-01-12 14:37:50 <Ariadne> 9.9.9.9 is what i recommend
2021-01-12 14:37:53 <ikke> ok
2021-01-12 14:39:07 <Newbyte> has anyone seen stwa around recently?
2021-01-12 14:39:42 <ikke> not around here
2021-01-12 14:40:04 <ikke> nor gitlab
2021-01-12 14:40:37 <Hello71> i trust cloudflare more than quad9 for privacy and security
2021-01-12 14:40:37 <Newbyte> all right, thanks
2021-01-12 14:40:53 <Hello71> also for competent users at least use 9.9.9.10
2021-01-12 14:41:06 <ikke> what's the difference?
2021-01-12 14:41:16 <ikke> in any case, it does not make a lot of difference
2021-01-12 14:41:18 <Hello71> no filtering
2021-01-12 14:42:16 <Hello71> 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 <Hello71> s/confusing/ambiguous/
2021-01-12 14:42:22 <alpine-meetbot> 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 <ikke> dns query from a builder takes 5 seconds
2021-01-12 14:43:34 <ikke> fairly consistently (for uncached records)
2021-01-12 14:44:05 <ikke> let's move this to #alpine-infra
2021-01-12 14:46:17 <Cogitri> mps: already upgraded gtk4.0 :)
2021-01-12 15:13:44 <mps> Cogitri: to 4.0.1?
2021-01-12 15:16:05 <Cogitri> 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 <mps> aha, very well
2021-01-12 16:38:33 <maxice8> clandmeter: !16750
2021-01-12 19:30:32 <maxice8> clandmeter: ping
2021-01-12 20:00:52 <clandmeter> maxice8: pong
2021-01-12 20:01:30 <maxice8> Can you ok the move on !16750 ?
2021-01-12 20:02:48 <clandmeter> Yes looks good.
2021-01-12 20:03:02 <clandmeter> Although I'm on mobile
2021-01-12 20:03:20 <clandmeter> Thanks!
2021-01-12 20:03:22 <maxice8> The first comment is more than enough
2021-01-12 20:17:24 <Newbyte> 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 <ikke> ideally, CI would not even run after rebase (after it passed before)
2021-01-12 20:19:20 <ikke> depending on the kind of change
2021-01-12 20:19:52 <ikke> but that's technically more challenging
2021-01-12 20:23:02 <ikke> 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 <Cogitri> Even if CI failed, that wouldn't really help us, would it?
2021-01-12 20:24:05 <Cogitri> Since we'd notice the failure on the builders
2021-01-12 20:42:39 <maxice8> Ping Cogitri
2021-01-12 20:42:55 <maxice8> Newbyte: Gitlab has merge trains but only for EE
2021-01-12 20:43:08 <maxice8> And they don't have a rebase method merge like Github
2021-01-12 20:47:18 <Cogitri> Pong?
2021-01-12 20:48:37 <maxice8> Matrix mobile was being suboptimal
2021-01-12 20:48:39 <ikke> Not very self-confident
2021-01-12 20:50:58 <Cogitri> Yeah, it likes doing that
2021-01-12 20:51:06 <Cogitri> Fluffychat has been pretty nice recently though
2021-01-12 20:57:58 <insep_> neochat is definitely faster than element in sending messages, but also has its own weak points
2021-01-12 21:06:20 <ikke> with meson / abuild-meson, how do I disable optimisation?
2021-01-12 21:06:26 <ikke> just CFLAGS?
2021-01-12 21:07:06 <Cogitri> Yup, we do buildtype=plain so no additional flags should be set
2021-01-12 22:24:45 <TBK[m]> 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 <maxice8> delete the source file ?
2021-01-12 22:25:19 <maxice8> deleted* ?
2021-01-12 22:25:37 <TBK[m]> 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 <maxice8> nuke
2021-01-12 22:26:47 <TBK[m]> k, I will remove it.
2021-01-12 22:35:22 <maxice8> Thanks
2021-01-12 22:41:08 <Hello71> https://aur.archlinux.org/cgit/aur.git/log/?h=bieaz lol
2021-01-12 22:45:04 <maxice8> heh
2021-01-12 22:45:07 <maxice8> better commit messages than my dotfiles
2021-01-13 01:28:46 <andypost[m]> Last commits did break gettext
2021-01-13 02:17:53 <maxice8> break ? It shouldn't break as it only changed the Maintainer field
2021-01-13 02:29:15 <omni> ncopa: I think I found the culprit in nlplug-findfs #12176
2021-01-13 02:32:59 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12295 andypost
2021-01-13 03:14:45 <maxice8> algitbot: retry master
2021-01-13 07:08:25 <fcolista> maxice8, going to fix my maintainer's email
2021-01-13 07:31:57 <ncopa> morning
2021-01-13 07:36:22 <ncopa> cloud images on the downloads page: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/19
2021-01-13 07:36:41 <caskd> morning o/
2021-01-13 07:39:01 <ncopa> so we do 3.13.0 today?
2021-01-13 08:05:29 <ikke> after we fix gettext
2021-01-13 08:06:34 <ikke> A failure in the test suite
2021-01-13 08:17:40 <Newbyte> caskd: how is the Telegram stuff going?
2021-01-13 08:18:10 <caskd> haven't had time to take care of anything tg related
2021-01-13 08:18:22 <caskd> currently migrating my prodution servers to alpine
2021-01-13 08:18:48 <caskd> i'm planning to cleanup the code sometime to have everything external link against system libs
2021-01-13 08:19:42 <Newbyte> I wonder why it was giving you out of memory errors on x86_64 though?
2021-01-13 08:20:02 <caskd> on the pipeline?
2021-01-13 08:20:04 <Newbyte> yes
2021-01-13 08:20:10 <Newbyte> looks like it was doing fine apart from that
2021-01-13 08:20:26 <caskd> probably they changed something and now it builds even more stuff so it runs out of mem
2021-01-13 08:20:54 <Newbyte> it builds fine on armv7 which is 32-bit
2021-01-13 08:21:34 <caskd> yeah but the x86_64 has more cores afaik so it does more stuff in parallel
2021-01-13 08:21:50 <Newbyte> oh, that could be true
2021-01-13 08:23:14 <Newbyte> 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 <Newbyte> presumably that's why then
2021-01-13 08:23:33 <caskd> well that's odd
2021-01-13 08:24:01 <caskd> anyways, it's mostly OOM on builds due to parallelism or sometimes even just simple linking
2021-01-13 08:31:21 <ikke> our 86_64 CI host has 64G of ram
2021-01-13 08:31:32 <ikke> but, it has 128 cores
2021-01-13 08:31:46 <ikke> so about 512M per core :P
2021-01-13 08:31:52 <Newbyte> https://gitlab.alpinelinux.org/caskd/aports/-/jobs/283021#L1
2021-01-13 08:32:06 <Newbyte> > Memory: 1.95343 Gb
2021-01-13 08:32:20 <Newbyte> and 2 cores?
2021-01-13 08:33:09 <ikke> that runner should not have run CI builds (only things like linting)
2021-01-13 08:33:13 <ikke> fixed it
2021-01-13 08:35:10 <Newbyte> caskd: maybe just try giving the x86_64 CI another spin for !16345 then?
2021-01-13 08:35:19 <caskd> sure
2021-01-13 08:35:50 <ikke> I just restarted that job
2021-01-13 08:36:06 <caskd> ah, thanks
2021-01-13 08:36:17 <ikke> It does fail on s390x as well though
2021-01-13 08:36:58 <Newbyte> I think it's disabled for s390x
2021-01-13 08:37:00 <caskd> you mean ppc64le?
2021-01-13 08:37:08 <caskd> s390x is disabled
2021-01-13 08:37:08 <ikke> yes
2021-01-13 08:37:34 <caskd> yeah it's related to protobuf being downgraded sometime, should fix it
2021-01-13 08:37:57 <caskd> tg_owt should be rebuilt against .24 instead of .25
2021-01-13 08:38:49 <Newbyte> I wonder if we should just build Telegram against Google's WebRTC instead of tg_owt
2021-01-13 08:39:07 <Newbyte> tg_owt just seems to be a frozen fork of Google's WebRTC with CMake files added
2021-01-13 08:39:12 <caskd> we probably should considering that they consider tg_owt as a toy
2021-01-13 08:39:21 <caskd> but someone has to create a aport for that
2021-01-13 08:39:30 <Newbyte> toy?
2021-01-13 08:40:00 <caskd> well, https://github.com/desktop-app/tg_owt/issues/36#issuecomment-726718262
2021-01-13 08:40:20 <Newbyte> oh, that one. I expect it to stay open till the end of times
2021-01-13 08:40:52 <Newbyte> and yes, that comment wasn't very inspiring
2021-01-13 08:41:23 <caskd> 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 <Newbyte> Fedora does it as well
2021-01-13 08:41:51 <caskd> they already had libwebrtc originally so idk why they changed
2021-01-13 08:41:59 <ikke> x86_64 now passed
2021-01-13 08:42:23 <Newbyte> 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 <caskd> 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 <caskd> 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 <caskd> and then relink against everything upstream
2021-01-13 09:54:44 <ncopa> I wonder what broke  gnulib (gettext package)
2021-01-13 09:55:46 <ikke> ncopa: I've added some details to the ticket
2021-01-13 09:55:49 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12295
2021-01-13 09:56:24 <ncopa> i came to the same conclusion with pritf debugging :)
2021-01-13 09:56:43 <ncopa> s/pritf/printf/
2021-01-13 09:56:44 <alpine-meetbot> ncopa meant to say: i came to the same conclusion with printf debugging :)
2021-01-13 09:56:53 <ncopa> ikke: good job
2021-01-13 09:57:23 <ncopa> 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 <ikke> I have a simple c program that shows this as well
2021-01-13 10:01:41 <mps> isn't musl realpath changed in last week or two
2021-01-13 10:04:53 <ncopa> changed in nov
2021-01-13 10:05:32 <ikke> master has not been updated in 4 weeks
2021-01-13 10:06:05 <mps> huh, I don't paste link where dalias posted changes
2021-01-13 10:06:16 <mps> don't have*
2021-01-13 10:06:17 <ncopa> im looking at the canonicalize_file_name implementation in gnulib
2021-01-13 10:06:52 <ncopa> 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 <ncopa> so im currently rebuilding getttext with CFLAGS="$CFLAGS -D_GNU_SOURCE"
2021-01-13 10:07:48 <ncopa> should make it detect more stuff from libc rather than use gnulib
2021-01-13 10:09:34 <omni> 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 <mps> !78
2021-01-13 10:10:23 <omni> mps: isn't that just for alpine/aports?
2021-01-13 10:10:30 <mps> omni: yes
2021-01-13 10:10:57 <mps> algitbot should go in school
2021-01-13 10:11:21 <omni> it should now which project you thought of
2021-01-13 10:11:54 <mps> something like 'mkinitfs!78'
2021-01-13 10:12:41 <ikke> same syntax as gitlab uses
2021-01-13 10:13:25 <ncopa> omni: that makes sense to me
2021-01-13 10:18:34 <omni> 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 <omni> either way I think it's safe to keep mkinitfs-init as is and just patch nlplug-findfs
2021-01-13 10:20:18 <ncopa> yeah, that makes sense. thanks alot for your work on this
2021-01-13 10:20:30 <ncopa> i guess I need to use 3.12, set up a vm with zfs root
2021-01-13 10:20:32 <ncopa> and test upgrade?
2021-01-13 10:20:34 <omni> that something was introduced recently that made ro mount of zroot to /sysroot stop working
2021-01-13 10:20:48 <ncopa> my guess is that zfs 2.0.0 introduced it
2021-01-13 10:21:35 <omni> 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 <ncopa> -N	 Import	the pool without mounting any file systems.
2021-01-13 10:22:22 <omni> right, I copy-pasted that line in the commit & MR messages =)
2021-01-13 10:22:24 <ncopa> i think that makes sense anyway, since nlplug-findfs is not expected to mount the root, right?
2021-01-13 10:23:25 <ncopa> 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 <ncopa> 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 <ncopa> and then I'd like to verify the fix on my laptop
2021-01-13 10:24:06 <omni> ncopa: I built a separate initramfs and manually chose that to boot with
2021-01-13 10:25:53 <omni> 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 <omni> and then edited and replaced initramfs-lts with initramfs-zfs at boot
2021-01-13 10:28:45 <omni> (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 <omni> 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 <omni> do you use grub? not that I think that should change anything..?
2021-01-13 10:45:12 <Cogitri> I use zfs root too on my NAS
2021-01-13 10:45:16 <Cogitri> just works on edge
2021-01-13 10:45:27 <Cogitri> But I use rEFInd instead of syslinux
2021-01-13 10:46:36 <ncopa> omni: i havent updated my laptop in a while
2021-01-13 10:47:36 <omni> ah (=
2021-01-13 10:50:10 <omni> Cogitri: I haven't tried/used rEFInd, does it use initramfs-init?
2021-01-13 10:53:54 <omni> Cogitri: your zfs root doesn't happen to have mountpoint=legacy or none?
2021-01-13 10:59:54 <Cogitri> Ah, I think I have mointpoint=legacy
2021-01-13 11:36:32 <ikke> ncopa: any idea about realpath?
2021-01-13 11:37:00 <ikke> ah, just saw the messags in #musl
2021-01-13 11:57:39 <mps> I created !16771 but still wonder is the lxcfs needed anymore
2021-01-13 11:58:17 <omni> Cogitri: if so, then nlplug-findfs won't mount at import and you duck this
2021-01-13 12:31:43 <ncopa> ikke: let me test on *bsd and glibc
2021-01-13 12:36:27 <ncopa> ikke: technically the gnulib test suite is wrong, but I think the best solution is to fix musl
2021-01-13 12:37:00 <ikke> dejura standard versus defacto standard
2021-01-13 12:39:11 <mps> or, wrong implementation
2021-01-13 12:42:57 <ikke> 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 <ikke> "If a pathname begins with two successive <slash> characters, the first component following the leading <slash> characters may be interpreted in an implementation-defined manner, although more than two leading <slash> characters shall be treated as a single <slash> character."
2021-01-13 12:44:15 <mps> ikke: I'm on #musl, seen that
2021-01-13 12:44:32 <mps> saw?
2021-01-13 12:45:48 <ikke> "I have seen that", or "I saw that"
2021-01-13 12:46:20 <ikke> "i've seen that"
2021-01-13 12:46:54 <mps> heh, why 'I', I'm writing in my name not someone else :)
2021-01-13 12:47:31 <mps> 'seen' is a lot shorter, though 'sin' is more :)
2021-01-13 12:52:33 <mps> ikke: thanks for explanations :)
2021-01-13 12:53:25 <mps> huh, so 3.13 will be released without waiting for musl 1.2.2
2021-01-13 12:53:29 <ikke> mps: btw, why did you assign the lxc MR to me?
2021-01-13 12:53:49 <ikke> mps: depends on how quickly 1.2.2 is releaed
2021-01-13 12:53:52 <ikke> released*
2021-01-13 12:54:28 <mps> because you best know should it be merged before 3.13 release, you keep all builders
2021-01-13 12:54:56 <ikke> The builder hosts are not even on 3.12 yet :P
2021-01-13 12:55:20 <ikke> I want to upgrade them after 3.13 is released, though
2021-01-13 12:55:32 <mps> ah, that's why we have so much issues with them ;)
2021-01-13 12:55:37 <ikke> :D
2021-01-13 12:56:42 <mps> ok, I will remove assignment and merge
2021-01-13 14:01:01 <ikke> ncopa: will you apply that musl patch locally?
2021-01-13 14:02:16 <ikke> And do we know why this suddenly is an issue?
2021-01-13 14:06:20 <ncopa> 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 <ikke> Yes, read it
2021-01-13 14:06:46 <ncopa> it happened due to musl reimplemented realpath relatively recent
2021-01-13 14:06:58 <ncopa> the re-implementation is good as it does not depend on /proc being mounted
2021-01-13 14:07:00 <ikke> ah, ok, and I guess gettext was not rebuilt since then?
2021-01-13 14:07:10 <ncopa> yes, i think so
2021-01-13 14:07:39 <ncopa> and i think i used old musl when bootstrapping the builders
2021-01-13 14:07:55 <ncopa> and gettext was not rebuilt since then
2021-01-13 14:08:08 <ikke> Ah, fixing the gnulib test suite to allow for "//" as well
2021-01-13 14:08:28 <ncopa> yeah. according posix it depends on implementation
2021-01-13 14:08:48 <ncopa> so musl behavior it not wrong, technically
2021-01-13 14:08:53 <ncopa> its just inconvenient
2021-01-13 14:09:20 <ncopa> I tested it on a number of systems: https://www.openwall.com/lists/musl/2021/01/13/2
2021-01-13 14:12:09 <minimal> 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 <minimal> 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 <ikke> And it's even a special case in the code that adds this behavior
2021-01-13 14:13:36 <mps> I don't think we need rng-any
2021-01-13 14:14:37 <minimal> 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 <mps> rng-tools and rng-tools-(extra|all|full) is ok to me
2021-01-13 14:17:53 <minimal> rng-tools package contains rngtest binary, rngd & rngd-extras both contain rngd binary
2021-01-13 14:19:01 <mps> minimal: rng-tools contains rngd
2021-01-13 14:19:42 <minimal> 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 <mps> it should be as it is
2021-01-13 14:20:21 <mps> least surprise principle (for users)
2021-01-13 14:21:11 <minimal> 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 <minimal> I'm trying to maintain backwards compatibility
2021-01-13 14:22:17 <mps> that can be solved to having rng-tools-full which conflicts with rng-tools
2021-01-13 14:23:37 <minimal> 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 <mps> no, backward compatibility shouldn't be broken without good reason
2021-01-13 14:25:31 <minimal> 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 <minimal> 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 <mps> 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 <mps> you misunderstood me I think
2021-01-13 14:27:05 <minimal> mps: and how to solve rngtest issue in that scenario?
2021-01-13 14:27:27 <mps> rng-tools-full will replace rng-tools on install
2021-01-13 14:27:48 <minimal> are you suggesting I put rngtest binary in both packages?
2021-01-13 14:27:54 <mps> yes
2021-01-13 14:28:02 <mps> and rngd in booth
2021-01-13 14:28:38 <mps> they need to be linked with extra libs
2021-01-13 14:28:46 <minimal> 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 <mps> it will not work, I think. prove me wrong and I will amend your changes
2021-01-13 14:30:13 <mps> -rwxr-xr-x 1 root root 39320 Jun 19  2020 /usr/bin/rngtest
2021-01-13 14:30:22 <mps> 39KB
2021-01-13 14:30:57 <minimal> 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 <mps> sorry, have to go out, do whatever you want
2021-01-13 14:32:00 <minimal> 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 <ncopa> Cogitri: i think this is wrong: https://gitlab.alpinelinux.org/alpine/mkinitfs/-/commit/edad1469ace201e53f05ceeae2b779ac12c33990#1187d04399f559e39041f15bc35251c44c78daae_282_287
2021-01-13 15:35:27 <ncopa> because nlplug-findfs.c will run zpool import
2021-01-13 15:36:29 <ncopa> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/nlplug-findfs.c#L1016
2021-01-13 15:37:08 <Cogitri> 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 <Cogitri> I only ever use legacy mounting, that's probably why it worked for me
2021-01-13 15:38:16 <ncopa> 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 <ncopa> but i had other workaround for that
2021-01-13 15:38:52 <ncopa> why is -d /dev needed?
2021-01-13 15:39:37 <ncopa> btw, i think mountpoint=legacy is required for rootfs
2021-01-13 15:40:12 <ncopa> 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 <Cogitri> 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 <Cogitri> FreeBSD's virtualization thingie uses that
2021-01-13 15:40:40 <Cogitri> and without -d /dev it wouldn't find disks that have that setup for me
2021-01-13 15:40:40 <dalias> mount is "legacy" ?
2021-01-13 15:40:58 <ncopa> according zfs manpage it is :)
2021-01-13 15:40:58 <Cogitri> Yeah, zfs uses its own stuff for mounting apparently
2021-01-13 15:41:03 <dalias> who decided that? lennart?
2021-01-13 15:41:06 <dalias> oh
2021-01-13 15:41:09 <dalias> zfs..
2021-01-13 15:41:27 <ncopa> so i meant "legacy" tools
2021-01-13 15:41:56 <Cogitri> 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 <dalias> was thrre a realpath problem?
2021-01-13 15:44:12 <ikke> dalias: yes
2021-01-13 15:44:26 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12295
2021-01-13 15:44:57 <ikke> summary: musl realpath does not normalize "//" into "/", while other implementations do, and gnulib test suite verifies it does
2021-01-13 15:45:22 <dalias> eew
2021-01-13 15:45:29 <ikke> dalias: also: https://www.openwall.com/lists/musl/2021/01/13/1
2021-01-13 15:45:40 <dalias> what happens when gnulob test fsils?
2021-01-13 15:46:12 <ikke> It failed on our builders
2021-01-13 15:46:25 <ikke> But ncopa now patched it to accept both "//" and "/"
2021-01-13 15:47:22 <ikke> 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 <dalias> yes im aware but this is intentional
2021-01-13 15:51:45 <ncopa> 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 <ncopa> dalias: what is the rationale for that behavior?
2021-01-13 15:53:09 <dalias> to allow system to treat // specially
2021-01-13 15:53:24 <ncopa> what system needs that?
2021-01-13 15:53:31 <dalias> midipix was planning to do that but dropped it
2021-01-13 15:53:44 <ncopa> as I understand cygwin does and z/OS
2021-01-13 15:53:53 <dalias> 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 <dalias> so gnulib is just wrong here
2021-01-13 15:54:22 <ncopa> and i worked around it by patching gnulib
2021-01-13 15:54:36 <ncopa> i know gnulib is technically wrong
2021-01-13 15:54:56 <dalias> 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 <ncopa> but i find the musl behavior unexpected and slightly annoying
2021-01-13 15:55:53 <ncopa> because it triggers bugs in bad software, and people blame musl (or alpine) for it
2021-01-13 15:56:05 <ncopa> "too much hazzle. lets use gnu linux"
2021-01-13 15:56:43 <ncopa> "works on ubuntu, works on macos, works on openbsd, fails on alpine"
2021-01-13 15:58:01 <dalias> 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 <dalias> requires stat comparison and one nice thing about new realpath is no stat
2021-01-13 15:59:35 <ncopa> does it depend on kernel (eg linux) or on the filesystem (eg ext4/zfs/whatever)?
2021-01-13 15:59:58 <Hello71> isn't the only problem with stat that it's slow? considering that // -> / is "wrong" anyways
2021-01-13 16:00:07 <dalias> i dont think stock linux can distinguish them but im not sure
2021-01-13 16:00:24 <ncopa> its not "wrong". i think both are allowed
2021-01-13 16:00:25 <dalias> hello71, it doubles the size for static link
2021-01-13 16:00:42 <dalias> since stat is huge due to having to translate kernel crap
2021-01-13 16:00:43 <Hello71> also, fwiw, the man-pages realpath(3) says "resolves references to ... extra '/' characters"
2021-01-13 16:01:49 <Hello71> 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 <dalias> what happens when gnulib test fails? does it try to do a broken replacement?
2021-01-13 16:02:32 <ncopa> make check fails
2021-01-13 16:02:47 <ncopa> so build fails with error
2021-01-13 16:03:19 <dalias> ok so just error in tests?
2021-01-13 16:03:24 <ncopa> yup
2021-01-13 16:03:31 <ncopa> and the test is wrong, technically
2021-01-13 16:03:47 <dalias> i read test as configure-time test
2021-01-13 16:03:54 <dalias> and was confused
2021-01-13 16:04:05 <ncopa> its not configure test
2021-01-13 16:04:17 <dalias> yes its wrong and breaks on some real world systems, no?
2021-01-13 16:04:38 <Hello71> what breaks where?
2021-01-13 16:05:38 <ncopa> i dont think it breaks on any real world system
2021-01-13 16:05:44 <ncopa> there is an #ifdef
2021-01-13 16:06:04 <ncopa> for at least one known system where it differs
2021-01-13 16:06:21 <ncopa>  #ifndef __MVS__
2021-01-13 16:06:35 <ikke> But there might be more applications that assume this behaviour
2021-01-13 16:07:02 <ncopa> that was my concern too
2021-01-13 16:07:16 <ncopa> but i doubt there are many of them
2021-01-13 16:07:25 <ncopa> if any
2021-01-13 16:07:57 <ncopa> it shouldnt really matter
2021-01-13 16:08:14 <ncopa> im mostly annoyed that this pops up now, the day i was about to do 3.13 release
2021-01-13 16:08:28 <dalias> :p
2021-01-13 16:21:53 <ncopa> Cogitri: do you know if other distros has an zfs_force boot option?
2021-01-13 16:22:12 <Cogitri> Everything that uses dracut has that option
2021-01-13 16:22:25 <Cogitri> So e.g. Fedora has it
2021-01-13 16:24:34 <ncopa> looks like arch linux has it also
2021-01-13 16:26:23 <ncopa> looks like other option is to set hostid boot option spl.spl_hostid=0x0a0af0f8
2021-01-13 17:13:51 <ikke> fun, quickjs is failing now on x86_64
2021-01-13 17:27:25 <ikke> it says to build with -fPIC, but that does not seem to help (CLFAGS)
2021-01-13 17:29:17 <ikke> Does it make sense to build with both -static and -shared?
2021-01-13 17:30:35 <dalias> no
2021-01-13 17:31:02 <maxice8> tackling emby
2021-01-13 17:31:12 <maxice8> seems like it hardcodes a soname dependency,
2021-01-13 17:31:18 <dalias> ?
2021-01-13 17:32:22 <maxice8> !16778
2021-01-13 17:44:39 <TBK[m]> 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 <ikke> the quickjs issue is a bit over my head
2021-01-13 17:47:01 <TBK[m]> ikke: could you take a look at #12297 ?
2021-01-13 17:47:31 <ikke> TBK[m]: later tonight
2021-01-13 18:02:39 <PureTryOut[m]2> @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 <dalias> eggdrop failure looks bogus, not even related to the software but something in the alpine build system
2021-01-13 18:06:58 <dalias> (why would it decide bind-libs is a conflicting package??)
2021-01-13 18:14:36 <ikke> 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 <ikke> there*
2021-01-13 18:15:07 <Ariadne> :D
2021-01-13 18:15:17 <MY-R> :D
2021-01-13 18:15:55 <artok> so setup-disk has changed so setup-disk -m sys /mnt doesn't work anymore on rpi =/
2021-01-13 18:16:35 <dalias> ikke, :)
2021-01-13 18:23:45 <mps> MY-R: my syslinux on efi is over
2021-01-13 18:24:36 <mps> main mistake is testing on old macbook instead on 'normal' pc notebook
2021-01-13 18:25:28 <mps> finally found that ssd 3 is to fast for old macbook, had to force it to 3GB
2021-01-13 18:25:38 <mps> too*
2021-01-13 18:25:58 <mps> (never will learn these 'fine' points of english)
2021-01-13 18:26:43 <minimal> mps: native speakers are general the worst for using the correct form of a language
2021-01-13 18:27:00 <mps> so, yes, alpine can boot with syslinux in efi mode on old macbook, also on 'normal' PCs
2021-01-13 18:30:58 <artok> oh that script is more intelligent nowadays.. all good
2021-01-13 18:40:39 <MY-R> mps: so syslinux working fine with efi, I will keep that in mind, thanks!
2021-01-13 18:47:59 <mps> 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 <MY-R> mps: so soon wiki update? :)
2021-01-13 18:49:30 <mps> I think it will appear here http://arvanta.net/alpine/ :)
2021-01-13 18:49:55 <mps> I don't know to use wikis
2021-01-13 18:51:35 <MY-R> oh ok
2021-01-13 18:52:48 <Cogitri> 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 <Cogitri> So aports-qa-bot doesn't tell everyone to ping `@developers`
2021-01-13 18:54:38 <minimal> mps: finished work on !16605, would be great if you could have a look at it
2021-01-13 18:55:37 <mps> minimal: will try to find some time before bed this evening
2021-01-13 18:56:53 <mps> 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 <minimal> mps: no rush, still waiting for existing maintainer to publically agree to the change in maintainership
2021-01-13 19:12:06 <minimal> mps: upstream rng-tools author is *very* responsive, I'm getting responses and fixes/merges within minutes.
2021-01-13 19:13:27 <fcolista>  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 <Hello71> well you can't run ipxe scripts not in ipxe
2021-01-13 19:19:05 <fcolista> so I should ship a custom apkovl
2021-01-13 19:19:45 <fcolista> no way to instruct ipxe to wget/exec a binary file, for example
2021-01-13 19:23:04 <Hello71> a linux file?
2021-01-13 19:23:08 <fcolista> yes
2021-01-13 19:23:15 <fcolista> static binary
2021-01-13 19:24:51 <Hello71> how would it do it without linux
2021-01-13 19:25:45 <Hello71> static only allows you to run without libc, you still need a kernel
2021-01-13 19:27:18 <fcolista> no you're right...i was wondering some sort of injection during the boot process
2021-01-13 19:27:53 <fcolista> I should put it in the init or with a custom apkovl
2021-01-13 19:28:10 <fcolista> *initramfs
2021-01-13 19:31:57 <ncopa> hum, there are more tests that fails now. tinc-pre, nbd
2021-01-13 19:34:39 <ikke> 🤔
2021-01-13 19:36:20 <dalias> 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 <dalias> i can roll today if there's nothing blocking
2021-01-13 19:36:51 <skarnet> ouch. Hope you have shiny healthy teeth now. :D
2021-01-13 19:36:52 <ncopa> that would be nice
2021-01-13 19:37:19 <dalias> 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 <ncopa> yeah, i hope you feel better today
2021-01-13 19:38:01 <dalias> 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 <ncopa> 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 <clandmeter> Ok
2021-01-13 19:44:36 <ncopa> seems like there have been a few commits in 2020 though
2021-01-13 19:56:34 <ncopa> would be great if the builders were idle tomorrow morning so we could tag the release
2021-01-13 19:56:51 <ncopa> i think the nbd fail is due flaky test
2021-01-13 20:20:08 <ikke> Cogitri: How would we call this group?
2021-01-13 20:20:19 <ikke> Note that we have all our 'user' groups in teams/*
2021-01-13 20:20:29 <Ariadne> group for what
2021-01-13 20:21:03 <ikke> Who users can ping for help
2021-01-13 20:21:32 <jvoisin> helpers ?
2021-01-13 20:21:36 <Ariadne> i suggested mentors before
2021-01-13 20:21:51 <Ariadne> 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 <jvoisin> guides? since this is Alpine linux :D
2021-01-13 20:22:04 <Ariadne> that could work
2021-01-13 20:22:23 <ikke> guides sounds more like tutorials
2021-01-13 20:22:43 <ikke> gitlab-org has 'coaches'
2021-01-13 20:23:57 <ikke> I don't have a strong opinion, we just need to choose something
2021-01-13 20:25:25 <Ariadne> mentors
2021-01-13 20:26:11 <Cogitri> Naming things is always the hardest part :D
2021-01-13 20:26:30 <Cogitri> Mentors or Coachers sounds good
2021-01-13 20:27:27 <omni> charismatic leaders
2021-01-13 20:28:23 <PureTryOut[m]2> Lords, gods, saviours
2021-01-13 20:28:42 <ikke> https://gitlab.alpinelinux.org/groups/team/mentors
2021-01-13 20:29:05 <Cogitri> 👍
2021-01-13 20:29:07 <MY-R> team/apkbuild? :D
2021-01-13 20:29:26 <ikke> I've added you, Cogitri, and I'm by default part of it as well :P
2021-01-13 20:29:47 <insep_> how can one apply to this group? :D
2021-01-13 20:30:12 <ikke> Well, first you need to become a developer yourself before you can mentor others
2021-01-13 20:31:17 <ikke> And now, quickjs
2021-01-13 20:31:30 <insep_> 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 <ikke> insep_: it's a start :P
2021-01-13 20:32:04 <Cogitri> 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 <insep_> ikke: :D
2021-01-13 20:34:04 <ikke> Cogitri: that message only contains a placeholder
2021-01-13 20:35:45 <Cogitri> Oh
2021-01-13 20:35:47 <Cogitri> whoops :D
2021-01-13 20:36:14 <Cogitri> Sorry, a bit brain-drained today, did some 5K LOC changes at work today :D
2021-01-13 20:36:44 <ikke> I debugged some ruby code the entire day :P
2021-01-13 20:36:53 <ikke> (chef related)
2021-01-13 21:28:55 <mps> just upgraded one box to edge from 3.12 and noticed that perl-io-compress conflicts with perl
2021-01-13 21:29:48 <ikke> it's no longer in edge even
2021-01-13 21:30:15 <ikke> https://pkgs.alpinelinux.org/packages?name=perl-io-compress&branch=edge
2021-01-13 21:31:44 <ikke> https://pkgs.alpinelinux.org/packages?name=perl-io-compress&branch=edge
2021-01-13 21:31:48 <ikke> 2aa6d4ad481e1c4c405d8d8089ae6171d9d697ca
2021-01-13 21:31:56 <ikke> apparently it has been integrated into perl
2021-01-13 21:32:02 <mps> yes
2021-01-13 21:32:22 <mps> but apk upgrade -a don't know this
2021-01-13 21:32:34 <PureTryOut[m]2> Shouldn't perl have gotten a provides and replaces for it then?
2021-01-13 21:32:52 <ikke> that's not the issue
2021-01-13 21:33:00 <ikke> it's the fact that the package stil exists
2021-01-13 21:33:06 <ikke> on 3.12
2021-01-13 21:33:27 <ikke> although, a replaces might fix it
2021-01-13 21:34:02 <ikke> not sure how replaces interacts when the package still exists
2021-01-13 21:46:32 <ncopa> seems like 3.13 builders all passed
2021-01-13 21:46:38 <maxice8> nice
2021-01-13 21:46:57 <ncopa> 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 <maxice8> do rc5 :D
2021-01-13 21:54:08 <ncopa> ok, here comes rc5
2021-01-13 21:57:25 <ikke> everyone hold their horses :P
2021-01-14 00:58:29 <TBK[m]> !16793
2021-01-14 03:00:11 <omni> rc5 works for me
2021-01-14 06:42:58 <ncopa> good morning!
2021-01-14 06:43:03 <ikke> morning
2021-01-14 06:43:45 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/merge_requests/20
2021-01-14 06:43:49 <ncopa> i was about to say that builders are idle, but they arent
2021-01-14 06:44:13 <ikke> nope, just a stream of commits were pushed
2021-01-14 06:45:21 <ncopa> ikke: wonderful! thanks for preparing the release notes!
2021-01-14 06:45:32 <ncopa> i also see that 5.10.7 is out
2021-01-14 06:45:38 <ncopa> lets update that first
2021-01-14 06:46:03 <ikke> Not s
2021-01-14 06:46:09 <ikke> not all details are there yet
2021-01-14 06:46:17 <ikke> musl-1.2 upgrade notes
2021-01-14 06:47:11 <maxice8> In my defense it is still not morning here
2021-01-14 06:47:21 <ncopa> :D
2021-01-14 06:47:37 <maxice8> 03:47 AM
2021-01-14 06:48:12 <ncopa> thats morning. just very very early :)
2021-01-14 06:57:07 <maxice8> fair
2021-01-14 06:57:23 <maxice8> on the plus side I got a few upgrades that had CVE fixes
2021-01-14 06:57:34 <maxice8> which means we won't have to backport something to 3.13-stable 5 seconds after releasing it
2021-01-14 07:00:37 <mps> maxice8: you are optimist :)
2021-01-14 07:01:28 <maxice8> I'm just pretending
2021-01-14 07:01:42 <maxice8> If you knew how bad things really are
2021-01-14 07:02:19 <maxice8> 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 <ikke> ncopa: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12299
2021-01-14 07:32:45 <ncopa> ikke: i added a line and changed the title
2021-01-14 07:32:48 <ncopa> thanks!
2021-01-14 07:33:04 <mps> huh, openresolv site was awol few days, and now it is available. to late for upgrading openresol, ncopa ?
2021-01-14 07:33:31 <mps> and u-boot is just released, 2021.01
2021-01-14 07:33:36 <ncopa> its ok as long as it does not break anything or take alot of time to build
2021-01-14 07:34:23 <mps> and you want to break tradition, release on fridays :)
2021-01-14 07:47:49 <ikke> ncopa: nice
2021-01-14 08:00:55 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12293 if anyone wants to help contacting the maintainers
2021-01-14 08:16:30 <mps> andypost[m]: what is your 'note' for openresolv
2021-01-14 08:17:05 <mps> sorry, I notised it too late, just after merge
2021-01-14 08:18:55 <andypost[m]> I just rebased
2021-01-14 08:20:11 <mps> ah, ok
2021-01-14 08:41:29 <ncopa> im gonna move https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases to https://alpinelinux.org/releases
2021-01-14 08:41:37 <ncopa> and have the raw data in yaml
2021-01-14 08:42:08 <ikke> ncopa: ok
2021-01-14 08:42:29 <ikke> We can at some point render it into something nicer from the raw data
2021-01-14 08:42:39 <mps> what is python pkg_resources, https://gitlab.alpinelinux.org/mps/aports/-/jobs/292845#L1697
2021-01-14 08:42:44 <ncopa> ikke: thats what im working on right now
2021-01-14 08:42:48 <ikke> ncopa: ok, nice
2021-01-14 08:42:58 <mps> which module should be added to makedeps
2021-01-14 08:43:12 <ikke> py3-setuptools
2021-01-14 08:43:23 <mps> aha, lets try
2021-01-14 09:11:55 <HRio> 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 <HRio> s/som/some/
2021-01-14 09:12:08 <alpine-meetbot> 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 <ikke> aha ok, but you patched rdiff-backup there?
2021-01-14 09:14:41 <HRio> backport from rdiff-backup master
2021-01-14 09:15:27 <HRio> so I would not need py3-setuptools and all boxes running 3.11
2021-01-14 09:15:35 <HRio> s/and/on/
2021-01-14 09:15:35 <alpine-meetbot> HRio meant to say: so I would not need py3-setuptools on all boxes running 3.11
2021-01-14 09:16:52 <HRio> sorry forget det 3.11 part rememebered wrong about this specific commit
2021-01-14 10:11:54 <ncopa> ok, i have a generated releases page that im relatively happy with
2021-01-14 11:19:22 <ikke> ncopa: need any help with something?
2021-01-14 11:19:41 <ikke> I'll work on improving the release notes
2021-01-14 11:26:06 <ncopa> in a call. will tag in a sec
2021-01-14 11:36:39 <ikke> ncopa: What do we mention for musl
2021-01-14 11:36:49 <ikke> 1.2.2?
2021-01-14 11:40:45 <ncopa> i think we can say 1.2.x
2021-01-14 11:41:07 <ncopa> we should mention the time64 thingy
2021-01-14 11:41:12 <ikke> Yes, was just working on that
2021-01-14 11:41:37 <ikke> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0
2021-01-14 11:41:43 <ncopa> ok. let me tag the release now
2021-01-14 11:45:08 <ncopa> what we do with ipv6? https://gitlab.alpinelinux.org/alpine/aports/-/issues/10237
2021-01-14 11:45:14 <ncopa> move to 3.13.1 or 3.14?
2021-01-14 11:45:17 <ncopa> i guess 3.14
2021-01-14 11:45:47 <ikke> It's not really tied to an alpine release I guess, so it does not matter that much
2021-01-14 11:48:58 <ikke> ncopa: I've updated https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0
2021-01-14 11:49:01 <ikke> I have to go now
2021-01-14 13:40:30 <wener[m]> 👍
2021-01-14 13:40:52 <ncopa> ikke: are yo working on the release notes?
2021-01-14 13:41:03 <ikke> no, not at the moment
2021-01-14 13:41:12 <ikke> I see some suggestions were made
2021-01-14 13:41:15 <ncopa> ok let me push force a minor fix
2021-01-14 13:41:18 <ncopa> those suggestions
2021-01-14 13:43:41 <omni> zstd support in mkinitfs is pretty cool, could be worth a mention
2021-01-14 13:44:14 <wener[m]> 3.13 also contains k3s
2021-01-14 13:44:33 <wener[m]> really like this
2021-01-14 15:02:53 <ncopa> release notes is merged
2021-01-14 15:03:16 <ikke> nice
2021-01-14 15:03:24 <jvoisin> nice
2021-01-14 15:24:35 <ncopa> https://wwwtest.alpinelinux.org/
2021-01-14 15:25:09 <ncopa> 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 <ncopa> and the 3.13.0 release notes is there too
2021-01-14 15:25:42 <MY-R> 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 <ncopa> https://wwwtest.alpinelinux.org/releases/ is supposed to replace the wiki
2021-01-14 15:26:31 <ikke> And icons?
2021-01-14 15:26:34 <MY-R> I think dates with numbers only looks better
2021-01-14 15:26:41 <ikke> ohy no, they were already there
2021-01-14 15:26:47 <exception> There is a typo "for Alpine Linux abailable at the same time" (srry to be that guy)
2021-01-14 15:27:08 <ikke> exception: this is wwwtest, so good that you catch it there :)
2021-01-14 15:27:17 <MY-R> I mean End of support dates could looks same as Branch date
2021-01-14 15:27:21 <ncopa> exception: ah.. thanks!
2021-01-14 15:27:22 <MY-R> more readable
2021-01-14 15:28:32 <ncopa> i didnt take the time to make the dates green/yellow/red
2021-01-14 15:29:10 <ikke> ncopa: you were reading my mind :P
2021-01-14 15:29:14 <MY-R> aaand "repository is supported til next stable" should be "till" ?
2021-01-14 15:29:16 <minimal> 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 <ikke> but I was refraining myself
2021-01-14 15:29:56 <ncopa> minimal: * cloud-init support?
2021-01-14 15:29:57 <ncopa> or similar
2021-01-14 15:30:11 <ikke> isn't cloud-init a building block for cloud images?
2021-01-14 15:30:27 <ncopa> i havent tested it myself yet, unfortunately, so i don't know how well it works
2021-01-14 15:31:01 <ncopa> i think mcrute (who is maintaining cloud images) is going to take a look at cloud-init
2021-01-14 15:31:38 <minimal> 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 <ncopa> the nice thing with cloud-init is that most cloud provides have drivers for it
2021-01-14 15:32:29 <minimal> 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 <ncopa> he is in different timezone
2021-01-14 15:33:36 <minimal> 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 <ncopa> typos are fixed https://wwwtest.alpinelinux.org/
2021-01-14 15:35:23 <minimal> 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 <ncopa> do we have any documentation how to do that?
2021-01-14 15:36:20 <minimal> I can put some together
2021-01-14 15:36:59 <ncopa> ok if I point users who ask for cloud-init in your direction?
2021-01-14 15:37:03 <minimal> ncopa: I did sent you some notes on this a couple of months ago
2021-01-14 15:37:29 <minimal> ncopa: sure, I am the package maintainer after all :-)
2021-01-14 15:37:47 <ncopa> yeah, I never took the time to look closer at it. it got down-prioritized, sorry :-(
2021-01-14 15:38:43 <minimal> 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 <MY-R> ncopa: "til" -> "till" but imho "until" sounds better
2021-01-14 15:40:40 <ikke> MY-R: where?
2021-01-14 15:40:47 <ncopa> releases
2021-01-14 15:40:59 <ncopa> MY-R: i do think "till" is correct?
2021-01-14 15:41:07 <ncopa> but im not native english speaking
2021-01-14 15:41:11 <ikke> I agree until sounds better
2021-01-14 15:41:24 <ikke> in writing
2021-01-14 15:42:16 <ncopa> https://wwwtest.alpinelinux.org/releases/ updated
2021-01-14 15:42:46 <ncopa> 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 <ikke> until -> 'until the'?
2021-01-14 15:43:28 <exception> 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 <ncopa> oh, right
2021-01-14 15:44:02 <ncopa> we shoudl do that too
2021-01-14 15:44:12 <minimal> 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 <ncopa> what do you suggest?
2021-01-14 15:44:56 <minimal> 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 <ncopa> i mean that this (v3.13) is the first time we support cloud-init
2021-01-14 15:46:17 <minimal> ok, sorry, misunderstood the wording
2021-01-14 15:46:22 <mps> initially in alpine, I guess
2021-01-14 15:47:17 <ncopa> I'm open to better suggestions. if its not clear for you, then its not clear for others
2021-01-14 15:47:48 <ncopa> i added link to docs: https://wwwtest.alpinelinux.org/
2021-01-14 15:47:59 <ncopa> at the top right navbar
2021-01-14 15:48:09 <mps> perfect is enemy of good enough
2021-01-14 15:48:25 <ncopa> exactly :)
2021-01-14 15:48:27 <minimal> something like "cloud-init packages added to this release to enable building of custom Alpine cloud images"
2021-01-14 15:49:05 <mps> ncopa: nice, I wanted to mention docs.a.o earlier but forgot
2021-01-14 15:49:23 <ncopa> minimal: can it be shorter?
2021-01-14 15:49:26 <mps> minimal: too much words
2021-01-14 15:49:29 <mps> :)
2021-01-14 15:49:30 <ncopa> ha
2021-01-14 15:49:33 <MY-R> btw any reason why links point to git.a.o and not to gitlab.a.o?
2021-01-14 15:49:51 <ncopa> historical i guess
2021-01-14 15:50:02 <mps> MY-R: gitlab.a.o is crawling repo
2021-01-14 15:50:17 <mps> git.a.o is much faster
2021-01-14 15:50:38 <minimal> "cloud-init added for building custom cloud images"
2021-01-14 15:50:59 <ncopa> thats better :)
2021-01-14 15:51:27 <mps> minimal: with cloud-init you can build something else than cloud images? :P
2021-01-14 15:51:32 <minimal> word "custom" used to try and avoid confusion with the official cloud images
2021-01-14 15:51:57 <minimal> mps: yes
2021-01-14 15:52:30 <ncopa> 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 <ncopa> with "initial support ..." it indicates that this is the start, and that there is more to come
2021-01-14 15:53:23 <mps> it is ok as it is now, ime
2021-01-14 15:53:24 <dne> git.a.o link on 3.13 release page is http not https
2021-01-14 15:53:39 <ncopa> dne: thanks!
2021-01-14 15:53:51 <dne> (pet peeve)
2021-01-14 15:54:01 <mps> hmm, it is https
2021-01-14 15:54:20 <dne> not under CHANGES
2021-01-14 15:55:16 <ncopa> re git vs gitlab
2021-01-14 15:56:02 <ncopa> 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 <ncopa> but we have bugs  there
2021-01-14 15:56:15 <mps> hmm, click on it opens https
2021-01-14 15:56:30 <MY-R> mps is right, git. working faster but maybe just add (GitLab) links after .git
2021-01-14 15:56:46 <dne> mps: yeah it redirects
2021-01-14 15:57:24 <MY-R> v3.13 | 2021-01-14 | 3.13-stable (GL-link) | 3.13.0
2021-01-14 15:57:39 <insep_> not in creating logs for repo
2021-01-14 15:57:58 <ncopa> i'll change "bugs" -> "issues" which points to gitlab
2021-01-14 15:58:11 <ncopa> and keep "git" point to cgit
2021-01-14 15:59:16 <ncopa> please refresh https://wwwtest.alpinelinux.org/
2021-01-14 16:01:07 <ncopa> 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 <MY-R> 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 <ncopa> MY-R: can you create an issue for that in infra proj?
2021-01-14 16:05:30 <ncopa> is https://wwwtest.alpinelinux.org/posts/Alpine-3.13.0-released.html good enough now?
2021-01-14 16:06:18 <Hello71> i don't think it's possible (easy)
2021-01-14 16:07:11 <MY-R> ncopa: sure
2021-01-14 16:10:04 <ncopa> im pushing the site updates now to prod
2021-01-14 16:10:10 <ikke> succes :)
2021-01-14 16:12:41 <minimal> 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 <minimal> basically these packages should have been rebuilt when skalibs was updated.
2021-01-14 16:20:27 <dne> downloads page still points to 3.12
2021-01-14 16:21:53 <mps> waiting till people upgraade vim
2021-01-14 16:31:32 <ncopa> ikke: can you take care of the sync pkgs?
2021-01-14 16:31:41 <ikke> yes
2021-01-14 16:31:45 <ikke> working on it now
2021-01-14 16:32:17 <MY-R> ncopa: https://gitlab.alpinelinux.org/alpine/infra/alpine-mksite/-/issues/4 ok done, no problem!
2021-01-14 16:33:02 <minimal> 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 <minimal> s/build/Edge/g
2021-01-14 16:33:14 <alpine-meetbot> 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 <ikke> minimal: bumping it should be enough
2021-01-14 16:34:20 <MY-R> ah, why it posted in "alpine-mksite" and not directly in /infra/ issues, my bad :\
2021-01-14 16:34:27 <minimal> ikke: ok. Will do. Still confused why pkgs.alpinelinux.org doesn't show those deps
2021-01-14 16:35:28 <MY-R> ook, sorry and thank you whoever moved it!
2021-01-14 16:36:28 <ikke> MY-R: not sure if we can make it clickable
2021-01-14 16:37:40 <MY-R> damn, rly?
2021-01-14 16:37:59 <MY-R> limitations of cgit?
2021-01-14 16:39:46 <ikke> yup
2021-01-14 16:40:22 <MY-R> ikke: ah, so just close it, I thought it would be simple cosmetic change
2021-01-14 16:40:41 <ikke> I tried it with an <a> tag, but it's escaped
2021-01-14 16:40:49 <ikke> it's just a field in an ini file
2021-01-14 16:41:17 <ikke> ncopa: any proof of the last checklist item? :P
2021-01-14 16:51:26 <MY-R> another point to checklist? "Add new release to https://mirrors.alpinelinux.org/" ? :P
2021-01-14 16:52:10 <ikke> That should happen automatically
2021-01-14 16:52:25 <ikke> Let me check
2021-01-14 16:54:13 <skarnet> 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 <skarnet> what is the standard operating procedure when a library changes sonames?
2021-01-14 16:56:01 <MY-R> 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 <minimal> 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 <ikke> skarnet: use ap recursive-revdeps skalibs-dev
2021-01-14 16:56:51 <ikke> from lua-aprots
2021-01-14 16:56:56 <ikke> lua-aports
2021-01-14 16:57:31 <skarnet> I'm not keen on needing lua to handle my packages
2021-01-14 16:57:52 <skarnet> I'd rather recursively grep the aports source
2021-01-14 16:58:47 <skarnet> 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 <minimal> skarnet: Its visible here: https://gitlab.alpinelinux.org/dbradley/aports/-/jobs/293125
2021-01-14 16:59:18 <minimal> its in justc-envdir itself however
2021-01-14 16:59:34 <skarnet> right, it just hasn't been converted to skalibs-2.10 yet
2021-01-14 16:59:42 <minimal> converted?
2021-01-14 16:59:55 <skarnet> some APIs have changed (this is what a major bump means)
2021-01-14 17:00:15 <skarnet> it's still using the 2.9 API
2021-01-14 17:00:34 <minimal> doh!
2021-01-14 17:00:54 <skarnet> pin it to 2.9 until upstream fixes it
2021-01-14 17:00:56 <ikke> skarnet: this is using the_silver_searcher: ag -G APKBUILD 'makedepends=".*skalibs-dev'
2021-01-14 17:01:10 <ikke> I guess you can do something with find + grep as well
2021-01-14 17:01:10 <minimal> skarnet: seems someone flagged this about a month ago: https://github.com/just-containers/justc-envdir/pull/2
2021-01-14 17:01:53 <skarnet> minimal: ah, that's the one. I'll ping them to say the release has been done.
2021-01-14 17:02:16 <minimal> I'll have to check s6-overlay as well to see if it needs changes too
2021-01-14 17:03:08 <skarnet> 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 <skarnet> I'll ping jprjr as well
2021-01-14 17:04:19 <minimal> skarnet: yeah, I meant s6-overlay-preinit
2021-01-14 17:04:37 <skarnet> I... don't know what that is
2021-01-14 17:05:07 <sluggo> Hi, I'm wondering, is there any reason for the existence and adoption of ifupdown-ng?
2021-01-14 17:05:08 <minimal> simple priviliged binary for changing uid/gid
2021-01-14 17:05:41 <sluggo> What was the problem with busybox ifupdown or other existing ones?
2021-01-14 17:05:56 <ikke> sluggo: https://github.com/ifupdown-ng/ifupdown-ng/blob/master/doc/ADMIN-GUIDE.md
2021-01-14 17:06:03 <skarnet> minimal: ah, I see the GH issue on s6-overlay-preinit
2021-01-14 17:06:53 <mcrute> minimal: sorry, I must have somehow missed your messages did you per-chance email me? mike@crute.us
2021-01-14 17:07:05 <minimal> skarnet: you do? seeing no issues on s6-overlay-preinit
2021-01-14 17:07:29 <mcrute> 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 <sluggo> ikke I saw that page, but was interesting in some further reading. I'll check their IRC
2021-01-14 17:08:06 <minimal> 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 <skarnet> minimal: no, this is unrelated, it's an old issue that just got reopened
2021-01-14 17:08:14 <mcrute> 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 <minimal> mcrute: ok, I'll pop you an email
2021-01-14 17:10:26 <minimal> 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 <mcrute> 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 <skarnet> 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 <mcrute> 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 <mcrute> 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 <minimal> 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 <skarnet> looking atm
2021-01-14 17:12:39 <minimal> 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 <ikke> skarnet: Just to correct myself, you would want revdep for ap, not recursive-revdeps
2021-01-14 17:13:44 <mcrute> 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 <skarnet> minimal: for justc-envdir, xpathexec_r() -> xmexec_fm() and that should be it
2021-01-14 17:15:20 <skarnet> now looking at the scripts in s6-overlay
2021-01-14 17:17:07 <minimal> thanks
2021-01-14 17:19:47 <ikke> skarnet: atm, these are the revdeps for skalibs-dev: https://tpaste.us/6PLZ
2021-01-14 17:20:53 <skarnet> 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 <skarnet> 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 <skarnet> 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 <skarnet> but that shouldn't prevent you from bumping s6-overlay, if there are bugs we'll fix them
2021-01-14 17:28:19 <minimal> skarnet: thanks for your help
2021-01-14 17:28:45 <skarnet> np, I like to fix the stuff that breaks because of me >.>
2021-01-14 17:28:52 <minimal> seems from ikke's list that my packages are the only one's depending on your packages
2021-01-14 17:28:57 <skarnet> yes
2021-01-14 17:52:11 <skarnet> minimal: fyi, my message to jprjr: https://github.com/just-containers/s6-overlay/issues/317
2021-01-14 17:53:09 <minimal> thanks
2021-01-14 17:55:56 <maxice8> Oh nice 3.13.0 is released
2021-01-14 17:55:59 <maxice8> time to upgrade lua :D
2021-01-14 17:56:07 <maxice8> skarnet: re: soname rebuilds
2021-01-14 17:56:31 <maxice8> you can search for those that depend on the soname provided by the package.
2021-01-14 17:56:41 <maxice8> apk list --depends so:libfoo.so.1
2021-01-14 17:57:19 <skarnet> maxice8: thanks, it's exactly what I was looking for :)
2021-01-14 17:58:09 <skarnet> conclusion: please also rebuild libutempter
2021-01-14 17:58:13 <maxice8> I have a script
2021-01-14 17:58:40 <maxice8> http://ix.io/2M1C
2021-01-14 17:59:17 <skarnet> 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 <skarnet> (neither is sshd)
2021-01-14 18:06:19 <maxice8> ncopa: the lua5.4 MR is ready
2021-01-14 18:06:28 <minimal> 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 <skarnet> I can never remember if it's getty or login, but anyway it's busybox
2021-01-14 18:14:03 <ollieparanoid[m]> congratulations to the 3.13 release \o/
2021-01-14 18:14:30 <mps> login
2021-01-14 18:16:47 <mps> I don't think it is good idea to link anything with utmps lib by default
2021-01-14 18:16:47 <minimal> 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 <minimal> mps: by default no, but nothing to stop the adding of an extras subpackage with support
2021-01-14 18:17:31 <mps> minimal: that's ok
2021-01-14 18:22:01 <skarnet> well for login and sshd it's either you do or you don't
2021-01-14 18:22:08 <skarnet> and if you're going to support utmp then you need it everywhere
2021-01-14 18:22:20 <skarnet> 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 <skarnet> the plan is Ariadne's btw
2021-01-14 18:23:12 <mps> yes, I remember
2021-01-14 18:23:57 <mps> this was discussed many times here
2021-01-14 18:25:36 <mps> 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 <fcolista> clandmeter, you around?
2021-01-14 18:34:36 <minimal> 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 <fcolista> I've a question re: https://github.com/clandmeter/alpine-netboot/blob/master/boot.ipxe
2021-01-14 18:34:56 <fcolista> how is the item "latest-stable" automatically filled?
2021-01-14 18:34:57 <mps> minimal: yes :)
2021-01-14 18:35:48 <ikke> fcolista: latest-stable on the repos at least is a symlink
2021-01-14 18:36:29 <ikke> https://dl-cdn.alpinelinux.org/alpine/latest-stable/
2021-01-14 18:36:39 <fcolista> but how ipxe automatically "fills" that entry in the menu?
2021-01-14 18:37:09 <fcolista> I don't see any reference to latest-stable in the ipxe
2021-01-14 18:39:08 <ikke> What I read:
2021-01-14 18:39:14 <ikke> There is a menu with 2 items
2021-01-14 18:39:43 <ikke> the choose command returns the first element from the item you selected and assigns that to version
2021-01-14 18:40:21 <fcolista> ah ok.
2021-01-14 18:41:19 <fcolista> 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 <ikke> What do you mean, "filled in the menu"?
2021-01-14 18:42:32 <fcolista> when ipxe starts and shows the menu, is already written "3.12.3".
2021-01-14 18:42:40 <ikke> aha
2021-01-14 18:42:42 <fcolista> So the value of lastest-stabile is "filled" with the version
2021-01-14 18:42:49 <fcolista> but this happens *before* you choose.
2021-01-14 18:43:20 <ikke> Sounds like this ipxe does not provide that
2021-01-14 18:43:24 <ikke> ipxe script
2021-01-14 18:43:50 <Ariadne> phoronix wants to know what alpines revenue model is
2021-01-14 18:44:05 <ikke> Ariadne: yeah, was mentioned in #alpine-linux
2021-01-14 18:44:15 <ikke> "johncall"
2021-01-14 18:45:07 <ikke> fcolista: http://boot.alpinelinux.org/boot.ipxe
2021-01-14 18:48:20 <fcolista> 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 <mps> not phoronix but one commenter
2021-01-14 19:09:15 <Hello71> "Join Date: Mar 2020" "Posts: 1"
2021-01-14 19:09:16 <Hello71> uh
2021-01-14 19:11:12 <ikke> hackernews discussion: https://news.ycombinator.com/item?id=25778590
2021-01-14 19:11:12 <Hello71> fcolista: probably you should see https://gitlab.alpinelinux.org/alpine/infra/alpine-netboot instead
2021-01-14 19:11:56 <maxice8> !16545 anyone mind if I hog the edge builders with it ?
2021-01-14 19:12:04 <maxice8> !16546 err
2021-01-14 19:12:11 <maxice8> this one ^ includes libreoffice rebuild, very fun
2021-01-14 19:12:26 <ikke> yaay
2021-01-14 19:12:36 <ikke> I guess things are settled now
2021-01-14 19:13:45 <Hello71> is libreoffice working now? i thought it was still broken
2021-01-14 19:14:10 <ikke> no, it was fixed
2021-01-14 19:14:12 <maxice8> no clue, it builds apparently
2021-01-14 19:14:19 <ikke> 8fac12716006b0f8fdf1a01812f65310e33b7c6c
2021-01-14 19:14:41 <ikke> Timo Terras worked on that
2021-01-14 19:14:43 <Hello71> ah, ok :)
2021-01-14 19:15:16 <Hello71> i think it's still out of date but that's an improvement
2021-01-14 19:15:35 <ikke> Updating it is another can of worms
2021-01-14 19:16:19 <Hello71> 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 <Hello71> at least a week ago i had this issue
2021-01-14 19:16:37 <ikke> I've never had issues with it
2021-01-14 19:16:42 <ikke> I use alpine:edge a lot
2021-01-14 19:17:01 <Hello71> odd. maybe pebkac then
2021-01-14 19:17:20 <Hello71> is https repository supposed to work ootb?
2021-01-14 19:17:25 <ikke> yes
2021-01-14 19:17:35 <ikke> it's using letsencrypt certs
2021-01-14 19:18:35 <omni> release date is wrong on main web, 2021-10-14
2021-01-14 19:18:55 <Hello71> heh. we are bleeding edge distribution!
2021-01-14 19:19:08 <ikke> lol
2021-01-14 19:19:36 <maxice8> Alpine is ahead of the curve
2021-01-14 19:20:00 <mps> omni: it is not, all digits are there, though order is somewhat strange :)
2021-01-14 19:20:46 <maxice8> I think that is ISO 8601
2021-01-14 19:24:49 <mps> btw, today is first day of new year for julian calendar
2021-01-14 19:25:35 <mps> so, happy new year alpine release :)
2021-01-14 19:31:05 <maxice8> can we get the abuild stuff merged now that 3.13.0 is  gone ?
2021-01-14 19:48:34 <fcolista> Hello71 thanks for the suggestion
2021-01-14 19:49:05 <fcolista> 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 <fcolista> for netboot
2021-01-14 19:49:58 <fcolista> Or I should try http://$fqdn/.boot_repository
2021-01-14 19:50:46 <fcolista> no can't work
2021-01-14 19:50:46 <fcolista> find /media/* -name .boot_repository
2021-01-14 19:53:33 <mps> 'who' is this rapidswitch in list of our sponsors
2021-01-14 19:53:45 <ikke> They provide gbr1
2021-01-14 19:53:52 <mps> aha
2021-01-14 19:54:07 <mps> but I don't see packet.com there
2021-01-14 19:54:13 <mps> what's happened
2021-01-14 19:55:05 <ikke> Don't know, packet was still there in the 3.12 release notes
2021-01-14 19:55:16 <ikke> but they were bought by equinix
2021-01-14 19:55:26 <mps> ah, that explains
2021-01-14 19:55:36 <ikke> Oh, packet is still there
2021-01-14 19:55:46 <ikke> "Thanks to GIGABYTE, Linode, Fastly, IBM, Packet, vpsFree and RapidSwitch for providing us with hardware and hosting."
2021-01-14 19:56:19 <mps> https://alpinelinux.org/sponsors/
2021-01-14 19:56:35 <ikke> right, that's now equinix|metal
2021-01-14 19:57:10 <mps> ok, thanks
2021-01-14 20:17:09 <maxice8> lua5.4 is merged
2021-01-14 20:20:44 <Ariadne> wow !
2021-01-14 20:22:10 <maxice8> Next up is poppler (libreoffice rebuild), then boost (massive rebuilds)
2021-01-14 20:22:16 <maxice8> and finally python3 -> 3.9.1
2021-01-14 20:22:34 <maxice8> 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 <Ariadne> yes
2021-01-14 20:27:01 <omni> 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 <ikke> omni: all for
2021-01-14 20:28:15 <Terror> 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 <ikke> Terror: do you use latest-stable?
2021-01-14 20:28:38 <Terror> I do
2021-01-14 20:28:44 <ikke> right, that explains
2021-01-14 20:28:51 <ikke> so yes, we need to purge it still
2021-01-14 20:29:11 <ikke> I'll write something that purges everything
2021-01-14 20:29:16 <ikke> for latest-stable
2021-01-14 20:29:36 <Terror> Yup, that did it btw (thank goodness for fast internet)
2021-01-14 20:31:39 <Terror> Changing to v3.13 I mean.
2021-01-14 20:32:36 <maxice8> omni: isn't next alpine 4 ?
2021-01-14 20:42:27 <maxice8> ddevault is so quick
2021-01-14 20:43:03 <ddevault> it's my job
2021-01-14 20:43:34 <ikke> what did I miss?
2021-01-14 20:43:48 <maxice8> less than 1 minute to approve MR
2021-01-14 20:43:52 <ikke> aha
2021-01-14 20:43:59 <maxice8> approve-mr any%
2021-01-14 20:44:31 <ddevault> I can assure you that I'm even faster at reviewing emails ;)
2021-01-14 20:44:48 <insep_> is self-approving allowed?
2021-01-14 20:44:53 <maxice8> Yes
2021-01-14 20:45:04 <ikke> though, it inflicts a 7 day delay
2021-01-14 20:45:04 <maxice8> I do like to post the Obama giving Obama the medal image whenever someone does that though
2021-01-14 20:46:20 <insep_> 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 <ikke> 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 <insep_> But first, we need to learn how time is counted
2021-01-14 20:46:55 <timlegge> s390x is big endian correct?
2021-01-14 20:47:03 <ikke> yes
2021-01-14 20:47:30 <timlegge> thanks
2021-01-14 20:48:52 <insep_> 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 <insep_> i think that might have been too long of a message for irc
2021-01-14 20:52:17 <maxice8> any objections to !16546 ?
2021-01-14 20:52:25 <maxice8> It will block the builders for a bit with the huge libreoffice rebuild
2021-01-14 20:52:37 <Ariadne> go ahead
2021-01-14 20:53:27 <maxice8> done
2021-01-14 21:02:13 <omni> maxice8: I've just seen ppl talk about 3.14
2021-01-14 21:03:00 <omni> gitlab Dark Mode really is alpha, everything is fine except the header that is light on light background
2021-01-14 21:03:36 <maxice8> is it ? I see nothing wrong except they use blue instead of purple for merged MRs
2021-01-14 21:04:42 <MY-R> ye it is
2021-01-14 21:05:24 <omni> I logged out and in again and it's fine now
2021-01-14 21:08:24 <MY-R> ah so not that
2021-01-14 21:08:40 <MY-R> I have here after parent: some weird colors: https://i.imgur.com/VivECPN.png
2021-01-14 21:09:17 <maxice8> same here
2021-01-14 21:26:25 <maxice8> 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 <mps> is this useful
2021-01-14 21:30:02 <mps> to quote 'as other distros'. do we need to do things as other distros?
2021-01-14 21:30:26 <ikke> sometimes yes, sometimes no
2021-01-14 21:30:51 <mps> in exceptional cases, libusb0
2021-01-14 21:31:09 <mps> which doesn't work well, btw
2021-01-14 21:32:01 <ikke> 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 <ikke> they already have versioned names
2021-01-14 21:32:35 <mps> yes for most of them
2021-01-14 21:32:35 <ikke> the major drawback atm is that we need to duplicate APKBUILDs
2021-01-14 21:33:22 <maxice8> the benefits and drawbacks are mostly described in the original mail
2021-01-14 21:33:34 <ikke> skimming through it
2021-01-14 21:33:40 <yZ5vlALg86lP> 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 <maxice8> 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 <mps> everything have benefits and drawbacks. we should 'know' what we want: small, simple or something else
2021-01-14 21:34:51 <ikke> but what about having libfoo.so.1 and libfoo.so.2?
2021-01-14 21:34:55 <mps> I know for me
2021-01-14 21:35:56 <maxice8> Ikke: that will have problems if foo-1.0 suddenly has to upgrade their ABI
2021-01-14 21:36:45 <maxice8> yZ5vlALg86IP: depends, are the bindings official and upgraded in lockstep with the project ?
2021-01-14 21:36:51 <ikke> ok, so I see i'm conflating things
2021-01-14 21:37:48 <yZ5vlALg86lP> 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 <maxice8> 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 <ikke> what does the minor version in a soname signify?
2021-01-14 21:39:04 <ikke> libfoo.x.y
2021-01-14 21:39:33 <maxice8> I have no clue I guess ABI changes that do not break backwards compat (like adding new symbols)
2021-01-14 21:40:13 <mps> usually yes
2021-01-14 21:45:34 <Cogitri> Meson projects always increment the so version to mirror the project version
2021-01-14 21:45:39 <Cogitri> (by default at least)
2021-01-14 21:45:57 <Cogitri> So libfoo.so.2.4.1 was built by foo v2.4.1
2021-01-14 21:46:31 <ikke> right, but that implies the project is using semver
2021-01-14 21:46:39 <ikke> on an ABI level
2021-01-14 21:46:44 <Cogitri> Yup
2021-01-14 21:57:58 <maxice8> yes
2021-01-14 22:20:08 <omni> 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 <omni> is it mostly a placeholder for when $KOPT_rootflags isn't set or does it have another purpose?
2021-01-14 22:22:18 <omni> I'm looking at it to see if I should do something similar for overlaytmpfs
2021-01-14 22:24:39 <omni> hmm.. introduced here https://gitlab.alpinelinux.org/alpine/mkinitfs/-/commit/666c4d431cd585ce45df93bef58ada648bf88b55
2021-01-14 22:25:00 <omni> so I think I understand why and this should also be implemented for overlaytmpfs
2021-01-14 22:26:05 <omni> I think..?
2021-01-14 22:36:14 <maxice8> I want to merge !16850 in a few hours
2021-01-14 22:39:19 <mps> 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 <mps> so, do it
2021-01-15 00:48:50 <maxice8> boost rebuild in 12 minutes
2021-01-15 01:04:22 <maxice8> started with the right foot lol
2021-01-15 01:10:13 <Hello71> 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 <Hello71> 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 <maxice8> algitbot: retry master
2021-01-15 01:51:17 <maxice8> algitbot: retry master
2021-01-15 01:58:21 <TBK[m]> maxice8: lucene++'s src url has the version hardcoded
2021-01-15 01:58:51 <maxice8> noted
2021-01-15 02:14:46 <dalias> congrats on the release
2021-01-15 02:14:52 <maxice8> :D
2021-01-15 02:15:25 <dalias> 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 <dalias> which is a good thing :)
2021-01-15 02:16:22 <dalias> up to 19 who get credit in release announcements now
2021-01-15 02:19:10 <maxice8> grats on the new sponsors
2021-01-15 02:19:22 <maxice8> also poor builders, just finished libreoffice and now must rebuild all boost reverse dependencies
2021-01-15 02:19:58 <maxice8> 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 <tehcloud> boost your CPU usage
2021-01-15 02:20:43 <maxice8> I'm already playing a Paradox Interactive Grand Strategy in the background
2021-01-15 02:20:47 <maxice8> my CPU is abused enough
2021-01-15 04:00:55 <maxice8> algitbot: retry master
2021-01-15 04:11:46 <maxice8> algitbot: retry master
2021-01-15 04:39:27 <maxice8> huh
2021-01-15 04:39:32 <maxice8> /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 <maxice8> /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 <maxice8> Doesn't happen on x86_64
2021-01-15 04:45:14 <maxice8> algitbot: retry master
2021-01-15 04:54:44 <dalias> i really need to figure out how to get alpine to let me upgrade packages :/
2021-01-15 04:55:16 <dalias> afaict any -dev package permanently holds back the base package at the version of the -dev
2021-01-15 04:55:40 <dalias> until you find all the offending -dev packages and upgrade them in unison, or remove them
2021-01-15 05:01:15 <maxice8> algitbot: retry master
2021-01-15 05:01:29 <maxice8> CMake needs a Requires:
2021-01-15 05:05:46 <dalias> musl 1.2.2 release is now up :)
2021-01-15 05:06:04 <maxice8> Ariadne ^
2021-01-15 05:12:10 <maxice8> 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 <maxice8> algitbot: retry master
2021-01-15 05:14:34 <jackara> How do i change font size (increase)
2021-01-15 06:12:46 <jackara> I figured it out
2021-01-15 06:12:49 <jackara> I created a file called usercfg.txt and put in hdmi_group=2 (new line) hdmi_mode=3
2021-01-15 06:16:38 <maxice8> algitbot: retry master
2021-01-15 07:54:38 <mps> I forgot for yesterday notes about exfat drivers and tools change
2021-01-15 07:55:23 <mps> hope it will work 'out-of-the-box' on upgrades
2021-01-15 08:02:24 <ncopa> morning
2021-01-15 08:02:58 <ikke> 0o/
2021-01-15 08:23:14 <terror> Hi team, seems util-linux-2.36.1 have a bug that stop cifs mounts
2021-01-15 08:23:37 <terror> CIFS: Unknown mount option "symfollow"
2021-01-15 08:26:13 <terror> There's a patch: https://github.com/karelzak/util-linux/commit/76bb9b30cfcf54b59591a57a3d2a747e514469b2
2021-01-15 08:26:30 <ikke> aha, so an upstream issue
2021-01-15 08:26:47 <ikke> Can you make an issue on https://gitlab,alpinelinux.org/alpine/aports?
2021-01-15 08:26:58 <ikke> Or make a merge request
2021-01-15 08:27:01 <terror> I can try, of course
2021-01-15 08:30:19 <terror> Is there a simple way to sync my aports fork with upstream (sorry, not a git person :o)
2021-01-15 08:30:48 <Cogitri> git remote add upstream git@gitlab.alpinelinux.org:alpine/aports.git
2021-01-15 08:30:52 <ikke> So you have your own branch with custom changes?
2021-01-15 08:30:56 <Cogitri> git pull upstream master --rebase
2021-01-15 08:31:00 <ikke> Oh, you mean gitlab fork
2021-01-15 08:31:07 <terror> Yup, gitlab
2021-01-15 08:31:17 <terror> I contributed some aports in the past
2021-01-15 08:31:20 <ikke> (blame github for overloading the word fork)
2021-01-15 08:34:24 <terror> 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 <sosodank> 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 <sosodank> (community/doctest, community/notcurses, testing/growlight)
2021-01-15 08:48:55 <mps> sosodank: you are nick black?
2021-01-15 08:49:14 <sosodank> i am
2021-01-15 08:49:19 <mps> hi :)
2021-01-15 08:49:33 <sosodank> hello mps, thanks for all the merges :) hello also to Ariadne and a few others
2021-01-15 08:49:34 <ikke> sosodank: continue contributing, review other merge requests
2021-01-15 08:49:55 <mps> there is no 'process' to get commit rights
2021-01-15 08:49:57 <ikke> sosodank: we have a new (starting team) called team/mentors on gitlab
2021-01-15 08:49:57 <sosodank> cool, is it more of a nomination model ala arch/freebsd than a procedural model ala debian?
2021-01-15 08:49:59 <sosodank> ok got it
2021-01-15 08:50:06 <terror> 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 <ikke> sosodank: We are still figuring out how to do it in the future
2021-01-15 08:50:27 <sosodank> 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 <ikke> but right now it's indeed nominotional
2021-01-15 08:51:19 <mps> sosodank: fixing issue and helping on fixing bugs, improvement of pkgs and other helps are what counts
2021-01-15 08:51:20 <sosodank> 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 <sosodank> y'all have a good evening, hack on
2021-01-15 08:51:54 <Ariadne> [22:05] <e91e63dalias> musl 1.2.2 release is now up :)
2021-01-15 08:52:03 <Ariadne> I'll deal with it when I wake up
2021-01-15 08:52:04 <mps> Ariadne: yes
2021-01-15 08:52:11 <ikke> Ariadne: nice
2021-01-15 08:52:56 <mps> not sure could it be 'simply' backported to 3.13
2021-01-15 08:53:10 <ikke> mps: we are effectively already using 1.2.2
2021-01-15 08:53:16 <ikke> minus a few commits perhaps
2021-01-15 08:53:21 <mps> except _Fork
2021-01-15 08:53:44 <ikke> hmm?
2021-01-15 08:53:46 <mps> which is important change
2021-01-15 08:54:40 <mps> 'The release adds the _Fork function from the upcoming edition of POSIX'
2021-01-15 08:54:41 <ikke> You mean the mt-fork fix?
2021-01-15 08:54:47 <ikke> aha
2021-01-15 08:55:18 <mps> anyway, worth to try to backport it
2021-01-15 08:56:01 <mps> and I will try for sure, but not right now. have other things to do
2021-01-15 08:57:47 <mps> 'wcsnrtombs' is fix for CVE, have to look is it already in current musl in 3.13
2021-01-15 09:02:28 <terror> Issue created: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12306
2021-01-15 09:05:06 <DLange> 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 <Ariadne> it's AGPL now
2021-01-15 09:07:03 <Ariadne> we can't ship that as AGPL it would make everything that touches it also AGPL
2021-01-15 09:08:50 <maxice8> 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 <ncopa> morning
2021-01-15 09:09:03 <maxice8> morning ncopa
2021-01-15 09:09:19 <DLange> Ariadne: eh, no. If that was true no Linux distro could ship AGPL-3 code
2021-01-15 09:09:47 <DLange> but thanks for explaining the reasoning
2021-01-15 09:10:20 <Ariadne> we can ship AGPL-3 code that isn't a library
2021-01-15 09:10:23 <Ariadne> it's our policy
2021-01-15 09:10:46 <ncopa> too much for me to catch up in the channel :)
2021-01-15 09:11:12 <mps> don't sleep too much :)
2021-01-15 09:11:14 <maxice8> ncopa: TLDR I am doing the boost rebuild
2021-01-15 09:11:44 <ncopa> 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 <maxice8> the builders will keep trying master until build success rates improve
2021-01-15 09:12:15 <ncopa> maxice8: i saw the email about keep the major version number in libraries package names
2021-01-15 09:12:40 <ncopa> i will respond eventually, but in general, i don't want to do that always, for everything
2021-01-15 09:13:02 <ncopa> but it definitively makes sense for some packages
2021-01-15 09:13:12 <ncopa> and for gcc dependencies it is a requirement
2021-01-15 09:13:28 <maxice8> Like boost and packages that upstream supports it fully like GNOME libraries
2021-01-15 09:13:34 <ncopa> or anything in the build-base
2021-01-15 09:13:38 <terror> @ncopa enjoy the snow
2021-01-15 09:14:08 <ncopa> skarnet: apk list --depend is what I use for finding what needs to be rebuilt on ABI breakage
2021-01-15 09:14:12 <ncopa> terror: thanks
2021-01-15 09:14:26 <mps> uh, that reminds me that I didn't went to skiing in last four years
2021-01-15 09:14:32 <maxice8> http://ix.io/2M1C I have this scripts to print them neatly
2021-01-15 09:14:40 <maxice8> in a for-loopable way
2021-01-15 09:14:58 <terror> 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 <mps> and this season ski center are closed
2021-01-15 09:15:24 <maxice8> for pkg in $(depends so:libfoo.so.1); do apkgrel -a $(find_repo $pkg); done
2021-01-15 09:15:28 <ncopa> 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 <maxice8> http://ix.io/2M5h this is `find_repo`
2021-01-15 09:16:09 <ncopa> terror: can you post a link to where the patch is upstream? it saves time for us
2021-01-15 09:16:38 <terror> Done
2021-01-15 09:17:12 <mps> #12306
2021-01-15 09:17:13 <ncopa> 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 <ncopa> terror: i'll have a look at it now
2021-01-15 09:18:04 <ncopa> oh, one thing more...
2021-01-15 09:18:19 <ncopa> *thank you* to everyone helping getting 3.13 out
2021-01-15 09:18:58 <ncopa> 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 <mps> hmm, why? it is our pleasure
2021-01-15 09:19:09 <maxice8> ncopa: good to know about the go-tooling
2021-01-15 09:22:31 <ncopa> 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 <ncopa> whoops, i pushed the util-linux to 3.13-stable
2021-01-15 09:24:55 <mps> I understand your care for your 'baby'
2021-01-15 09:25:27 <ncopa> sometimes it feels like we are waling in mud, uphill
2021-01-15 09:25:38 <ncopa> things breaks faster than we manage to fix
2021-01-15 09:26:25 <terror> Thanks @ncopa!!
2021-01-15 09:26:34 <mps> 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 <ncopa> 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 <ncopa> yeah, exactly. the trick is to find where "good enough" is
2021-01-15 09:27:05 <terror> 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 <ncopa> terror: im glad you like it
2021-01-15 09:28:19 <mps> 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 <ikke> ncopa: not a bad plan :)
2021-01-15 09:33:59 <ikke> ncopa: for atools-go, I already have some code that statically parses sh files
2021-01-15 09:34:11 <ikke> including evaulation global variable values
2021-01-15 09:35:39 <terror> @ncopa, that fix worked fine. CIFS is back.
2021-01-15 09:35:44 <Ariadne>  delete mode 100644 main/boost/boost-fiber-mips64-ftbfs.patch
2021-01-15 09:35:45 <Ariadne> uhhh
2021-01-15 09:36:32 <ncopa> terror: awesome. i love trivial fixes :)
2021-01-15 09:37:01 <ikke> Ariadne: fun
2021-01-15 09:38:21 <Ariadne> well, hopefully that is all that is needed
2021-01-15 09:39:09 <maxice8> thanks
2021-01-15 09:41:52 <Ariadne> pushing musl 1.2.2 to edge, DO NOT backport this one because it enables faccessat2
2021-01-15 09:44:32 <Ariadne> doing a separate 1.2.2 backport to 3.13
2021-01-15 09:46:17 <ncopa> ok. Thank yo ufor taking care of it
2021-01-15 09:47:31 <maxice8> Is there a way to make build.alpinelinux.org stop moving the builder view up and down
2021-01-15 09:47:52 <maxice8> 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 <ncopa> its javascript
2021-01-15 09:50:28 <ncopa> pretty simple scripts
2021-01-15 09:50:34 <ncopa> they could need some love...
2021-01-15 09:51:10 <ncopa> i wonder what to do with dovecot security issues https://gitlab.alpinelinux.org/alpine/aports/-/issues/12274
2021-01-15 09:51:41 <ncopa> we could upgrade to 2.3.13 on 3.11-stable and 3.10-stable
2021-01-15 09:51:58 <ncopa> or we could find the patch for CVE-2020-24386
2021-01-15 09:52:04 <ncopa> finding the patch does not seem to be trivial
2021-01-15 09:53:31 <ikke> Some projects just don't want to be secure
2021-01-15 09:54:02 <Ariadne> unfortunately for us, dovecot is the only imap server worth a shit
2021-01-15 09:54:14 <mps> CVE-2020-24386 for dovecot is not serious, so we don't need to hurry
2021-01-15 09:54:15 <ncopa> i think upstream sometimes wants downstream to push new features
2021-01-15 09:54:42 <Ariadne> mps: ahh, but the FUD people will shame us
2021-01-15 09:54:42 <mps> I will ask upstream today later
2021-01-15 09:54:49 <ncopa> i want fix dovecot today
2021-01-15 09:54:55 <Ariadne> they will be like
2021-01-15 09:55:05 <Ariadne> ALPINE HAS OPEN CVEs USE UBUNTU INSTEAD
2021-01-15 09:55:07 <ikke> just update to latest unstable
2021-01-15 09:55:10 <ncopa> ha
2021-01-15 09:55:21 <mps> now I'm busy with some important job
2021-01-15 09:55:35 <Ariadne> (gee, no idea where those people come from)
2021-01-15 09:55:52 <Ariadne> (hint: the people paying for that astroturfing have a jet with a dragon mascot on it)
2021-01-15 09:56:12 <mps> who cares for them :P
2021-01-15 09:56:29 <Ariadne> sometimes people buy into the FUD
2021-01-15 09:56:37 <Ariadne> it is a concern
2021-01-15 09:57:10 <Ariadne> 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 <ncopa> maybe thats the problem. thy dont need to pay for it
2021-01-15 09:57:49 <Ariadne> ok we charge for it and become gartner magic quadrant leader
2021-01-15 09:57:56 <ncopa> :)
2021-01-15 09:57:57 <ikke> lol
2021-01-15 10:01:08 <ncopa> oh, there are more unresolved dovecot issues
2021-01-15 10:01:17 <ncopa> i think I'll just upgrade it
2021-01-15 10:02:06 <dne> 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 <dne> https://salsa.debian.org/debian/dovecot/-/commit/06dd33e4a2bc54bebe1db002ef8db84a3c5eff9d#ea8c8cccfa102e9509b18836683bce08bfaa68fd
2021-01-15 10:11:47 <Ariadne> now that's some magic quadrant leadership
2021-01-15 10:16:08 <hc-hmk> 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 <hc-hmk> My bad 3.13
2021-01-15 10:19:34 <ikke> hc-hmk: apparently still need to fix something for pkgs.a.o 3.13
2021-01-15 10:19:38 <ikke> https://pkgs.alpinelinux.org/packages?name=&branch=v3.13
2021-01-15 10:19:41 <ikke> it lists no packages at all
2021-01-15 10:19:49 <ikke> although syncing finished
2021-01-15 10:20:59 <hc-hmk> Okay, so docker *is* available, the online package viewer is just broken?
2021-01-15 10:25:41 <ikke> not up-to-date
2021-01-15 10:34:25 <maxice8> Gitlab user search or our instance's is so bad
2021-01-15 10:34:36 <maxice8> it is frustratingly terrible
2021-01-15 10:35:12 <ikke> The issue is that gitlab only autocompletes project members
2021-01-15 10:38:14 <maxice8> so unfortunate
2021-01-15 10:39:40 <ikke> You can mention everyone, but you have to explitily type out their username
2021-01-15 10:41:36 <maxice8> Yes which is unfortunate because some people commit under X and their username is completely unrelated
2021-01-15 11:00:38 <clandmeter> hc-hmk: can you check if its ok now?
2021-01-15 11:05:12 <hc-hmk> clandmeter: It works just fine now. Thanks!
2021-01-15 11:05:36 <hc-hmk> FYI the wiki hasn't been updated yet. https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2021-01-15 11:09:16 <clandmeter> should be part of the release process.
2021-01-15 11:09:32 <clandmeter> ncopa: ^
2021-01-15 11:09:40 <ikke> I've added it to the checklist
2021-01-15 11:10:01 <clandmeter> it was not on it yet?
2021-01-15 11:10:06 <clandmeter> i remember it was on the old wiki
2021-01-15 11:22:16 <hc-hmk> 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 <Cogitri> It's built w/o Ozone
2021-01-15 11:22:41 <Cogitri> Since Ozone still seems to be kind of crashy on X11
2021-01-15 11:24:12 <hc-hmk> Aw, that's unfortunate.
2021-01-15 11:26:04 <hc-hmk> 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 <Cogitri> To be honest, dunno, maybe you could look into that :)
2021-01-15 11:27:26 <ikke> 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 <ikke> it
2021-01-15 11:27:41 <hc-hmk> Or maybe a separate package, chromium-ozone? I remember seeing it on either redhat repos or aur
2021-01-15 11:28:17 <Cogitri> That won't fly, we already have trouble keeping chromium up-to-date
2021-01-15 11:28:29 <Cogitri> So unless someone steps up to maintaining both chromium and that new variant it wont happen
2021-01-15 11:30:29 <hc-hmk> Fair
2021-01-15 11:32:47 <hc-hmk> 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 <hc-hmk> 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 <travankor> hc-hmk: ozone is compiled by default in v87+
2021-01-15 11:36:49 <hc-hmk> Yep, I know. It can be explicitly enabled on 86 with a few flags. 3.13 uses 86.
2021-01-15 11:37:32 <travankor> i thought it's either ozone or x11 backend
2021-01-15 11:38:12 <travankor> so they're mutually exclusive
2021-01-15 11:40:11 <travankor> in other words, 87 is the version that supports building both the ozone and x11 backends
2021-01-15 11:40:12 <hc-hmk> That may very well be.
2021-01-15 11:41:34 <hc-hmk> Is there anything preventing us from updating chromium from 86 to 87, aside from putting in the work?
2021-01-15 11:41:42 <Cogitri> Nop
2021-01-15 11:42:00 <Cogitri> An active maintainer for Chromium would be pretty neat in general
2021-01-15 11:42:08 <hc-hmk> So if I get 87 running, based on the current patchset and APKBUILD script, that'd be good?
2021-01-15 11:42:48 <Cogitri> Sure
2021-01-15 11:43:16 <Cogitri> 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 <hc-hmk> I get that. Probably especially the musl stuff, since 3.13 ships with musl 1.2
2021-01-15 11:45:05 <Cogitri> I don't think musl 1.2 made that any harder than older musl versions
2021-01-15 11:45:43 <hc-hmk> 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 <ikke> abuild is the script you run, it uses the APKBUILD
2021-01-15 11:46:37 <hc-hmk> I dont see a file named abuild in the tree. Is it a separate program?
2021-01-15 11:46:40 <ikke> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package
2021-01-15 11:46:44 <ikke> hc-hmk: yes
2021-01-15 11:46:49 <hc-hmk> Alright
2021-01-15 12:02:50 <ncopa> I updated https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
2021-01-15 12:03:08 <ncopa> its now generated and moved to https://alpinelinux.org/releases
2021-01-15 12:05:01 <jvoisin> https://dl-cdn.alpinelinux.org/alpine/v2.1/
2021-01-15 12:05:08 <jvoisin> it seems that some old versions aren't on some mirrors
2021-01-15 12:08:30 <ikke> 2.x is only on ancient
2021-01-15 12:10:57 <ncopa> ikke: did you purge latest-stable on dl-cdn?
2021-01-15 12:11:03 <ikke> ncopa: not yet
2021-01-15 12:12:48 <MY-R> 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 <ncopa> ikke: i have this script: https://tpaste.us/Lwam
2021-01-15 12:13:47 <ncopa> and it looks like I have some work-in-progress for a go implementation
2021-01-15 12:16:12 <insep_> MY-R: oh god i've been looking for this
2021-01-15 12:16:19 <insep_> thanks!!!!!!!!!!!!!!!!!!
2021-01-15 12:16:43 <ncopa> i'd like to move it to a place with better bandwidth before we make it more visible
2021-01-15 12:18:03 <insep_> iso for alpine 1.1 is missing though :(
2021-01-15 12:20:38 <ncopa> ikke: im purging dl-cdn cache now
2021-01-15 12:20:52 <MY-R> insep_: any good reason to use the first release 1.1 ?
2021-01-15 12:21:36 <insep_> i'm just interested in such historic relic
2021-01-15 12:23:32 <ncopa> i think i have a cdrom somwhere around here with alpine 1.0
2021-01-15 12:23:34 <MY-R> so maybe not missing but wasnt even generated in that time
2021-01-15 12:23:54 <MY-R> damn...
2021-01-15 12:24:46 <ncopa> found this: old/backup/alpine-0.1.0-20050105.iso
2021-01-15 12:24:48 <ncopa> :)
2021-01-15 12:25:58 <afontain_> is there a tool to auto bump pkgrel?
2021-01-15 12:26:42 <MY-R> ncopa: museum.alpinelinux.org would be good link for that :D
2021-01-15 12:27:59 <Ariadne> afontain_: apkgrel -i
2021-01-15 12:28:22 <afontain_> basically, a lot of packages haven't been bumped since boost 1.75
2021-01-15 12:29:08 <afontain_> Ariadne: where can I find it?
2021-01-15 12:32:21 <afontain_> ah, abuild package
2021-01-15 12:37:49 <ncopa> https://dev.alpinelinux.org/~ncopa/alpine/alpine-0.1.0-20050105.iso
2021-01-15 12:38:52 <mps> afontain_: abump -h
2021-01-15 12:38:53 <hc-hmk> 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 <ncopa> hc-hmk: moved libmodbus
2021-01-15 12:54:45 <ncopa> to community
2021-01-15 12:55:11 <hc-hmk> Great :)
2021-01-15 12:55:38 <ncopa> will be avilable in alpine 3.14 unless i backport it to 3.13
2021-01-15 12:58:20 <afontain_> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16873
2021-01-15 13:09:52 <Hello71_> dalias: I think you can do this with apk upgrade -l
2021-01-15 13:19:22 <mps> just noticed, screen depends on utmps, not good change
2021-01-15 13:20:01 <mps> and coreutils, even worse
2021-01-15 13:23:51 <Hello71_> as I recall, you don't have to actually *use* utmps
2021-01-15 13:29:31 <skarnet> even if the clients are linked against utmps, if the daemons are not running, nothing will happen
2021-01-15 13:29:42 <skarnet> the function will just return nothing, just like the musl stubs
2021-01-15 13:29:57 <skarnet> so it's safe
2021-01-15 13:33:21 <mps> if I was satisfied with (unneeded) 'dependencies hell' on debian I wouldn't switch to alpine
2021-01-15 13:35:11 <mps> anyone against reverting these things
2021-01-15 13:47:01 <Ariadne> we can transition it to static linking
2021-01-15 13:49:58 <mps> I'm not in hurry, though maybe sounded that I'm angry. I'm not no worries
2021-01-15 13:50:55 <mps> we can look what option we have, to have utmps and to not install it 'by default'
2021-01-15 13:51:48 <Hello71_> wouldn't static linking increase the install size
2021-01-15 13:57:22 <minimal> can someone tag !16816 and !16857 so as to be included in 3.13.1?
2021-01-15 14:52:15 <Ariadne> [07:51] <Hello71_> wouldn't static linking increase the install size
2021-01-15 14:52:17 <Ariadne> minimally
2021-01-15 14:53:26 <Hello71_> well I'm saying if your concern with the deps is the increased size
2021-01-15 14:53:38 <Hello71_> then wouldn't static linking make it worse
2021-01-15 14:54:05 <Ariadne> i don’t think that’s the concern
2021-01-15 14:54:23 <Ariadne> i think it is “having to bump all these things due to utmps”
2021-01-15 14:55:32 <minimal> 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 <Hello71_> 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 <minimal> 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 <mps> 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 <detha> 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 <mps> detha: right option is to patch musl, but I doubt it will happen
2021-01-15 15:45:22 <mps> (and not complicate things too much)
2021-01-15 15:45:54 <mps> if we 'want' utmp support on alpine
2021-01-15 16:02:02 <detha> 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 <mps> 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 <minimal> 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 <skarnet> 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 <skarnet> tbh you could probably link against libutmps+libskarnet statically and it would be a *very* minimal size increase
2021-01-15 16:17:18 <skarnet> also I keep getting baffled by the wishy-washiness of this community
2021-01-15 16:17:56 <skarnet> are you as hesitant and unsure about all the other software you are integrating?
2021-01-15 16:18:21 <skarnet> do you keep saying yes, then backing up, then going forward again, but with a half-step?
2021-01-15 16:18:54 <minimal> 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 <minimal> 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 <skarnet> 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 <Ariadne> utmps is happening, but static linking is probably the best way
2021-01-15 16:21:46 <skarnet> people who don't want it just don't have to run the daemons
2021-01-15 16:22:02 <skarnet> and everything will 'work' like before, doing nothing
2021-01-15 16:22:03 <Ariadne> i wonder though if dalias would be open to integrating the client side into musl directly now
2021-01-15 16:22:06 <dne> at least it's not pam…
2021-01-15 16:22:51 <skarnet> 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 <Ariadne> anyway mps complaint is about depgraph size not disk size
2021-01-15 16:23:30 <skarnet> 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 <minimal> 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 <dne> right (anyway I don't have a problem with utmps)
2021-01-15 16:28:14 <dalias> ariadne, i haven't looked at the protocol enough to give an answer
2021-01-15 16:30:26 <skarnet> 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 <skarnet> Ariadne: it's precisely about depgraph size that I find mps (and maybe others) unjustifiably timid
2021-01-15 16:32:59 <skarnet> are they complaining that util-linux relies on, uh, libblkid, libfdisk, libmount, libsmartcols and libuuid?
2021-01-15 16:33:19 <skarnet> that coreutils depends on libacl and libattr?
2021-01-15 16:33:36 <dalias> 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 <skarnet> that the freaking *kernel* needs perl to build?
2021-01-15 16:34:56 <skarnet> 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 <mps> heh
2021-01-15 16:38:14 <mps> 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 <dalias> i really do hate dep creep and these uselessly general single-consumer libraries util-linux and such have
2021-01-15 16:38:41 <skarnet> dalias: exactly
2021-01-15 16:39:01 <skarnet> and the one dependency that utmps has is far from single-consumer
2021-01-15 16:39:03 <dalias> 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 <skarnet> thank you, someone understands
2021-01-15 16:40:12 <mps> dalias: you know, if you don't complain for small, complaining to big will be too late
2021-01-15 16:41:18 <dalias> it's already too late :-p
2021-01-15 16:42:01 <skarnet> 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 <mps> dalias: :)
2021-01-15 16:44:05 <mps> skarnet: Hope is the scariest of all daemons
2021-01-15 16:44:42 <Ariadne> heh
2021-01-15 16:45:10 <skarnet> 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 <mps> skarnet: it is not about your software at all
2021-01-15 16:46:20 <skarnet> is it really not? because it definitely feels like it
2021-01-15 16:46:23 <Ariadne> well anyway, utmps is something that most people want
2021-01-15 16:46:35 <mps> I'm talking about alpine 'process'
2021-01-15 16:46:45 <Ariadne> the process has been followed
2021-01-15 16:47:03 <mps> Ariadne: hmm
2021-01-15 16:47:44 <mps> skarnet: be assured that my complain is not about your software
2021-01-15 16:48:01 <Ariadne> your complaint is that alpine does not do what you want
2021-01-15 16:48:28 <mps> well, at least till the moto is: small, simple
2021-01-15 16:48:50 <mps> if we want to change that I'm ok
2021-01-15 16:48:55 <Ariadne> if you want absolutism on small, simple, there are better distributions
2021-01-15 16:49:04 <Ariadne> that has never been intended to be absolute
2021-01-15 16:49:36 <mps> Ariadne: I don't think that the 'there are better distributions' is good for discussion
2021-01-15 16:49:55 <Ariadne> i'm just telling it like it is
2021-01-15 16:50:58 <mps> 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 <Ariadne> my point is that alpine is pragmatic, not absolutist
2021-01-15 16:52:11 <mps> which POV of pragmatic
2021-01-15 16:52:26 <skarnet> 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 <mps> your or mine
2021-01-15 16:52:44 <Ariadne> your view is absolutist, not pragmatic
2021-01-15 16:52:53 <mps> heh
2021-01-15 16:53:01 <mps> I see it a pragmatic
2021-01-15 16:53:15 <Ariadne> 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 <mps> but we went out of the good talk, see you later
2021-01-15 16:53:52 <Ariadne> alpine is small and simple, but in the context of providing what people actually *want*
2021-01-15 16:53:58 <Ariadne> and that includes utmp
2021-01-15 18:12:32 <PureTryOut[m]2> Why do we still have https://git.alpinelinux.org/aports/tree/main/pth/APKBUILD#n6 in the repo?
2021-01-15 18:30:59 <maxice8> I refuse to belive x86 already finished the boost rebuild
2021-01-15 18:31:31 <maxice8> also armhf seems to be having distfile issues
2021-01-15 18:50:16 <Hello71_> fwiw libblkid and libuuid are actually somewhat useful
2021-01-15 18:50:56 <Hello71_> pretty sure udev uses libblkid
2021-01-15 18:52:34 <Hello71_> what's ridiculous is things like column being in util-linux and com_err being in e2fsprogs
2021-01-15 18:58:21 <ikke> PureTryOut[m]2: it was even recently added again: 56689d27fd383beba312b63d5439ea08b67d5a3f
2021-01-15 18:58:42 <PureTryOut[m]2> But uclibc is not used anymore
2021-01-15 19:02:16 <ikke> ¯\_(ツ)_/¯
2021-01-15 19:09:48 <PureTryOut[m]2> !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 <TBK[m]> maxice8: !16874
2021-01-15 19:39:35 <maxice8> The ones I have missed?
2021-01-15 19:40:22 <TBK[m]> yup
2021-01-15 19:46:36 <dalias> uhg how do i unbreak alpine's inability to upgrade anything??
2021-01-15 19:47:29 <mps> apk fix
2021-01-15 19:47:36 <dalias> ?
2021-01-15 19:47:43 <mps> run 'apk fix'
2021-01-15 19:47:43 <dalias> apk fix is a nop
2021-01-15 19:47:50 <dalias> the problem is not broken packages
2021-01-15 19:48:00 <dalias> it's some web of -dev package versions blocking upgrade of anything
2021-01-15 19:48:03 <mps> ah, what is problem?
2021-01-15 19:48:45 <mps> apk update ; apk upgrade -a (or apk upgrade -a -s) -s simulate
2021-01-15 19:49:05 <afontain_> the problem is forgotten pkgrel bump
2021-01-15 19:49:23 <dalias> http://ix.io/2M8w
2021-01-15 19:49:25 <mps> hm, how
2021-01-15 19:49:30 <dalias> first commadn it what i'm trying to install
2021-01-15 19:49:36 <dalias> it can't install because some boost lib is being held back
2021-01-15 19:49:48 <dalias> trying to force the boost package to update gives the huge error spam
2021-01-15 19:49:50 <ikke> boost is being ubilt
2021-01-15 19:49:54 <ikke> built*
2021-01-15 19:50:06 <dalias> this isn't related to current build
2021-01-15 19:50:34 <mps> dalias: one by one, 'apk add openvdb-dev@testing
2021-01-15 19:50:34 <mps> ERROR: unsatisfiable constraints:
2021-01-15 19:50:40 <mps> muh
2021-01-15 19:50:52 <mps> dalias: one by one, 'apk add -u openvdb-dev@testing'
2021-01-15 19:51:00 <dalias> 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 <afontain_> huh
2021-01-15 19:51:25 <afontain_> it's probably a bad idea
2021-01-15 19:51:32 <mps> usually in such cases I fix one by one
2021-01-15 19:51:42 <afontain_> at least now you have some dev packages
2021-01-15 19:51:48 <dalias> 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 <afontain_> well, nevermind, it wouldn't change anything
2021-01-15 19:52:01 <dalias> the =x.y.z dep in the -dev package keeps the main library package held back
2021-01-15 19:52:10 <dalias> rather than just forcing the -dev package to update too
2021-01-15 19:52:35 <mps> in -dev cases I simply upgrade -dev and rest is pulled automatically
2021-01-15 19:52:44 <dalias> basically automatic dep resolution for upgrades just doesn't work if you have any -dev packages
2021-01-15 19:52:50 <dalias> for a single -dev that works
2021-01-15 19:52:58 <dalias> but this is a huge web of 30+ -dev packages
2021-01-15 19:53:06 <dalias> i even tried upgrading them all:
2021-01-15 19:53:18 <dalias> apk add -ul $(grep -- '-dev' /etc/apk/world)
2021-01-15 19:53:26 <dalias> and it still fails
2021-01-15 19:53:59 <dalias> and boost and python3 are involved in the web making it a huge mess
2021-01-15 19:54:00 <afontain_> dalias: isn't that because some package hadn't been rebuilt against boost-1.75?
2021-01-15 19:54:13 <dalias> maybe
2021-01-15 19:54:25 <dalias> but the upgrade request should just upgrade anything else that needs to be upgraded at the same time
2021-01-15 19:54:36 <dalias> not hold the whole system back with unintelligible conflict errors
2021-01-15 19:55:20 <afontain_> well, it's not a bad idea to hold the system back here
2021-01-15 19:55:29 <mps> hmm, ime it ok, not to do what I don't ask
2021-01-15 19:55:42 <dalias> i asked it to upgrade package x
2021-01-15 19:55:58 <afontain_> yes, but it's not possible if the repos are inconsistent
2021-01-15 19:56:06 <dalias> it is possible
2021-01-15 19:56:16 <mps> but it detects some pkgs 'hold' it to do that
2021-01-15 19:56:18 <dalias> if i did apk upgrade it would almost surely work
2021-01-15 19:56:28 <afontain_> you can try
2021-01-15 19:56:36 <dalias> after waiting 24+ hours and running out of disk space upgrading unrelated stuff i dont care about
2021-01-15 19:56:53 <dalias> :-p
2021-01-15 19:57:02 <dalias> i'm going to just try purgine the -dev packages and re-adding them
2021-01-15 19:57:16 <dalias> removal of -dev packages should not break anything runtime
2021-01-15 19:57:58 <afontain_> 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 <maxice8> Could NOT find Lua (missing: LUA_LIBRARIES) (found suitable version "5.3.6", minimum required is "5.3")
2021-01-15 19:58:34 <maxice8> ¯\_(ツ)_/¯ why cmake
2021-01-15 19:58:59 <afontain_> 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 <afontain_> btw, there are like 3 packages that are not building against the new version of boost
2021-01-15 19:59:39 <afontain_> see #alpine-commits
2021-01-15 19:59:43 <maxice8> it is not only 3
2021-01-15 19:59:46 <maxice8> I am monitoring the situation
2021-01-15 19:59:52 <maxice8> and suffering because of CMake
2021-01-15 20:00:03 <afontain_> right, at least 3 :-/
2021-01-15 20:00:14 <afontain_> oof
2021-01-15 20:00:23 <maxice8> things will fail a lot more before they get better
2021-01-15 20:00:35 <afontain_> can I try to fix another package to help ya?
2021-01-15 20:00:35 <maxice8> it is the nature of big rebuilds, just you wait until python3 3.9 comes
2021-01-15 20:00:42 <mps> yes
2021-01-15 20:00:42 <mps> (I need hammers instead of fingers for this keyboard on old macbook :) )
2021-01-15 20:00:49 <maxice8> go wild, ping me on your MRs
2021-01-15 20:01:03 <TBK[m]> several of the aports that fail have upgrades available...
2021-01-15 20:01:19 <TBK[m]> I am working on domoticz atm
2021-01-15 20:02:46 <afontain_> having a look at horizon
2021-01-15 20:03:51 <maxice8> I have an MR for horizon
2021-01-15 20:03:56 <maxice8> just need Ariadne to give the ok
2021-01-15 20:04:06 <maxice8> and for it to actually build
2021-01-15 20:05:02 <maxice8> works fine locally on my x86_64 somehow it breaks the compiler in CI ??
2021-01-15 20:05:53 <maxice8> looking at icinga2
2021-01-15 20:08:52 <TBK[m]> 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 <maxice8> Yes
2021-01-15 20:09:46 <maxice8> my lookup table is Arch->Gentoo->Fedora->Debian
2021-01-15 20:10:47 <TBK[m]> I have the same list plus freebsd, openwrt and void
2021-01-15 20:17:56 <Ariadne> go ahead and push it
2021-01-15 20:17:59 <Ariadne> once it builds in CI :P
2021-01-15 20:19:06 <dalias> still working on this mess...
2021-01-15 20:19:34 <Ariadne> on what mess
2021-01-15 20:19:51 <dalias> unintelligible package conflicts
2021-01-15 20:20:09 <dalias> i removed a bunch of stuff i dont actually want/need and now i'm making some progress
2021-01-15 20:20:18 <dalias> libffi seems to be at the core of it
2021-01-15 20:20:34 <ikke> libffi is always the core of it
2021-01-15 20:20:41 <dalias> i sooooo wish alpine would just static link all libs without long term stable soname/abi
2021-01-15 20:20:51 <dalias> there's no reason at all to be using dynamic libffi
2021-01-15 20:21:12 <dalias> same for boost
2021-01-15 20:42:31 <PureTryOut[m]2> 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 <andypost[m]> Year ago PHP core started to require libffi otoh it could use bundled source
2021-01-15 20:46:40 <ikke> PureTryOut[m]2: https://distfiles.alpinelinux.org/distfiles/v3.13/lua-luaxml-130610.tar.gz
2021-01-15 20:48:32 <PureTryOut[m]2> Oh, why doesn't the APKBUILD have that as the source then?
2021-01-15 20:48:45 <ikke> PureTryOut[m]2: the builders are setup to first try distfiles
2021-01-15 20:49:38 <PureTryOut[m]2> 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 <ikke> I suppose not
2021-01-15 21:09:47 <dalias> still going
2021-01-15 21:10:05 <dalias> found a bunch of bogus py-* and python meta packages holding back ancient python2 package versions *sigh*
2021-01-15 21:10:18 <dalias> these were probably deleted ages ago but with no automated procedure for fixing the dep web
2021-01-15 21:10:36 <dalias> and now everything finally seems unblocked
2021-01-15 21:10:45 <ikke> yeah, I should have know
2021-01-15 21:11:36 <dalias> static boost and libffi in packages that depend on them would be a huge help for this tho
2021-01-15 21:11:45 <dalias> (avoiding forcing large unrelated upgrades in sync)
2021-01-15 21:13:32 <Hello71_> boost is pretty big though, and i'm skeptical that it has good static linking size properties
2021-01-15 21:14:09 <dalias> anything using boost is gigantic anyway, and likely doesn't use all of it, just parts
2021-01-15 21:23:19 <dalias> uhg now some of the boost libs are missing/unavailable
2021-01-15 21:23:22 <dalias> is that a builder problem?
2021-01-15 21:24:23 <maxice8> side-effect of Alpine not keeping old packages around
2021-01-15 21:24:57 <maxice8> I should have pushed boost1.75 harder
2021-01-15 21:25:03 <dalias> :(
2021-01-15 21:25:31 <dalias> so now i guess i just have a broken system til something happens..?
2021-01-15 21:25:37 <dalias> boost-date_time is missing
2021-01-15 21:25:45 <maxice8> it should have the new boost-libs
2021-01-15 21:25:47 <maxice8> but not the old ones
2021-01-15 21:26:28 <dalias> it doesnt have the new one
2021-01-15 21:27:27 <dalias> 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 <dalias> *sigh*
2021-01-15 21:27:35 <dalias> *please* make boost static linked everywhere
2021-01-15 21:27:51 <jvoisin> *please don't use boost
2021-01-15 21:28:12 <dalias> jvoisin, alpine is a distro not a rewriter of every junk c++ application out there so....
2021-01-15 21:28:55 <dalias> *sigh* like everything still depends on 1.72 but 1.75 is all that's there now
2021-01-15 21:29:19 <dalias> 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 <dalias> 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 <dalias> and i broke a bunch of self-compiled stuff because soname of libprotobuf changed
2021-01-15 21:34:14 <dalias> just hex editing the DT_NEEDED *sigh*
2021-01-15 21:44:38 <Cogitri> Having a versioned boost package seems better than static linking tbh
2021-01-15 21:44:51 <dalias> well yes that would be great too
2021-01-15 21:45:02 <dalias> but it would be a lot larger
2021-01-15 21:45:17 <dalias> because you'd have many full copies of boost on the system
2021-01-15 21:45:26 <dalias> rather than just one copy of the relevant parts per program using it
2021-01-15 21:46:05 <Hello71_> 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 <maxice8> looking at gnuradio
2021-01-15 21:47:10 <Cogitri> You'd only have a max of 2 boost copies on your system
2021-01-15 21:47:27 <Cogitri> and that only temporarily while stuff is still rebuilding
2021-01-15 21:51:27 <dalias> that's assuming you constantly upgrade everything
2021-01-15 21:51:50 <dalias> 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 <dalias> and add that other lib dir to ldso path
2021-01-15 21:52:06 <dalias> so nothing ever gets lost
2021-01-15 21:52:27 <dalias> yes this is a stupid solution but...
2021-01-15 21:53:05 <maxice8> But I wanna known if it works
2021-01-15 21:53:45 <dalias> for what use?
2021-01-15 21:54:08 <maxice8> morbid curiosity
2021-01-15 21:55:37 <dalias> oh i thought you were asking if gnuradio works
2021-01-15 21:55:43 <dalias> do you mean by hardlink hack? :-p
2021-01-15 21:56:06 <maxice8> yes
2021-01-15 21:59:20 <dalias> really stupid idea too...
2021-01-15 21:59:38 <dalias> 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 <dalias> and adding those dirs to ldso path
2021-01-15 22:00:29 <dalias> and using those paths for any self-compiled software
2021-01-15 22:01:12 <Hello71_> this sounds increasingly like nix
2021-01-15 22:01:20 <dalias> yes
2021-01-15 22:01:55 <dalias> is there musl-based nix repo?
2021-01-15 22:02:00 <dalias> maybe i should just use that..
2021-01-15 22:20:08 <afontain_> Well, in theory, things should go fine if we don't forget a third of boost-related rebuild
2021-01-15 22:21:34 <maxice8> 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 <maxice8> I don't know how far they got though
2021-01-15 22:23:13 <maxice8> some arches finished the boost rebuild
2021-01-15 22:23:26 <yZ5vlALg86lP> i heard that excising systemd from nix is quite painless
2021-01-15 22:23:50 <maxice8> I thought it was tied to it with lots of nix assuming it and making use of it
2021-01-15 22:23:56 <dalias> yeah i wouldn't care about anything systemd related from nix
2021-01-15 22:24:09 <dalias> basically there are two completely independent sets of packages i'm interested in
2021-01-15 22:24:23 <dalias> (1) system components / stuff i'd call part of "the OS"
2021-01-15 22:24:26 <dalias> (2) application programs
2021-01-15 22:24:46 <dalias> basically i'm very happy with (1) from alpine but (2) is a huge problem of constant breakage
2021-01-15 22:24:59 <maxice8> time to make Alpine Silverblue :D
2021-01-15 22:25:06 <dalias> and (2) should never be touching systemd
2021-01-15 22:39:16 <skarnet> (1) should never be touching systemd either. :P
2021-01-15 22:39:22 <dalias> skarnet, :)
2021-01-15 22:39:56 <dalias> i should have phrased it as "(2) should never be touching anything related to the init system"
2021-01-15 22:40:17 <skarnet> that's right
2021-01-15 22:45:12 <dalias> 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 <dalias> is it automated?
2021-01-15 22:45:48 <maxice8> depends on the package we bump the `pkgrel` and the builder rebuilds it
2021-01-15 22:45:58 <maxice8> we normally do it in one go
2021-01-15 22:46:09 <dalias> but it requires manual intervention?
2021-01-15 22:46:32 <dalias> 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 <maxice8> no it doesn't
2021-01-15 22:46:48 <dalias> :(
2021-01-15 22:46:50 <maxice8> it is on the maintainer to bump the pkgrel
2021-01-15 22:46:58 <dalias> so that leaves everything broken until maintainer notices? :(
2021-01-15 22:47:07 <maxice8> 0bf72f4ee7c03e74ba7b5260027fe67748037f81 f14316ecad37a49ccc81e95d12bb26e64ea3596e 9233749896bdaf3cedbca27e08018b96115ccf5c a63eefda9db2caba26cb68982ea3d7615c8160dc
2021-01-15 22:47:08 <maxice8> yes
2021-01-15 22:47:13 <PureTryOut[m]2> Yes, and that has happened before
2021-01-15 22:47:48 <maxice8> the rebuilding infra is suboptimal, Void Linux holds packages until it has been all rebuild
2021-01-15 22:48:16 <ikke> our builders only upload after things are finished as well
2021-01-15 22:48:27 <ikke> the whole "uploaded" message
2021-01-15 22:48:36 <ikke> from algitbot in #alpine-commits
2021-01-15 22:50:04 <ikke> but depending programs need to be explicitly bumped
2021-01-15 22:50:17 <ikke> otherwise, no one would ever get these upgraded packages
2021-01-15 22:50:20 <ikke> (rebuilt)
2021-01-15 22:50:43 <ikke> 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 <dalias> openvdb is one i need that looks like it's likely to be overlooked
2021-01-15 22:56:34 <maxice8> It was rebuilt in a later commit
2021-01-15 22:56:45 <dalias> oh it's done now? yay
2021-01-15 22:57:01 <dalias> i've got a big reinstall of all the -dev packages i purged going on now
2021-01-15 22:57:05 <maxice8> 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 <dalias> ah
2021-01-15 22:57:14 <dalias> ok
2021-01-15 22:57:22 <maxice8> algitbot: retry master
2021-01-15 22:57:30 <dalias> well maybe by the time this reinstall of *-dev finishes it'll be done :-p
2021-01-15 22:58:01 <dalias> i wonder if i should just do things the other way around...
2021-01-15 22:58:24 <dalias> use a long term stable as main dist, with edge in a chroot just for firefox, gcc, etc.
2021-01-15 22:58:40 <dalias> and add the latter to my path/ldsopath
2021-01-15 23:02:01 <dalias> hmm libtbb-dev package seems to lack a .a file :(
2021-01-15 23:02:41 <maxice8> Is it a matter of --enable-static ?
2021-01-15 23:02:53 <dalias> probably
2021-01-15 23:02:55 <ikke> or s/--disable-static//
2021-01-15 23:03:01 <maxice8> it is a makefile
2021-01-15 23:03:05 <dalias> i'm not sure
2021-01-15 23:03:26 <dalias> and the non-dev package has .so symlinks
2021-01-15 23:03:33 <dalias> contrary to policy aiui
2021-01-15 23:03:53 <dalias> (policy i disagreed with but .. :-p)
2021-01-15 23:04:50 <maxice8> Need better enforcement
2021-01-15 23:05:06 <maxice8> ¯\_(ツ)_/¯ I'll write an abuild rule for it lets hope it gets merged
2021-01-15 23:05:56 <maxice8> dalias: by tbb you mean threadingbuildingblocks ?
2021-01-15 23:06:30 <dalias> i guess, whatever libtbb is
2021-01-15 23:06:36 <dalias> i just added it as a dep
2021-01-15 23:06:52 <dalias> 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 <maxice8> I don't even see support for making it .a in its cluster of makefiles
2021-01-15 23:10:05 <maxice8> I really don't feel like messing with makefiles, hopefully they use meson in the future
2021-01-15 23:10:52 <maxice8> x86_64 is done
2021-01-15 23:14:05 <dalias> :/
2021-01-15 23:14:20 <dalias> c++ programmers use the worst junk libraries
2021-01-15 23:14:20 <maxice8> :\
2021-01-15 23:14:33 <dalias> it's as bad as node
2021-01-15 23:15:13 <dalias> 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 <Hello71_> at a guess, part of the reason is that msvc c sucks
2021-01-15 23:35:48 <dalias> cgal hasn't been updated for new boost either :(
2021-01-15 23:40:51 <mps> lost evening trying to use dendrite, at the end removed supervise option and it started to work
2021-01-15 23:41:56 <mps> now will set it to use runit run script
2021-01-15 23:43:03 <dalias> yay it's working after update
2021-01-16 01:54:53 <maxice8> huh
2021-01-16 01:55:05 <maxice8> make and /bin/sh are getting Operation not permitted errors
2021-01-16 02:03:16 <maxice8> yep, CI is broken
2021-01-16 02:14:07 <andypost[m]> looks gcc is broken not CI
2021-01-16 02:16:33 <maxice8> I don't know
2021-01-16 02:16:50 <maxice8> 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 <maxice8> In fact I'm almost done building CMake 3.19.3 locally :D
2021-01-16 03:36:08 <yZ5vlALg86lP> maxice8 dalias a nix variant that comes with runit instead of systemd: https://github.com/cleverca22/not-os
2021-01-16 03:37:22 <maxice8> fancy
2021-01-16 04:13:41 <dalias> i would just use nix for apps not system i think
2021-01-16 05:30:04 <maxice8> dalias: !16894
2021-01-16 05:44:52 <maxice8> !16892 will be fun to merge and manage
2021-01-16 06:38:25 <maxice8> https://lists.alpinelinux.org/~alpine/devel/%3Cd0c4cab578c513f312390679680eb1cf31690a05.camel%40gmail.com%3E
2021-01-16 07:23:42 <mps> 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 <Hello71_> maxice8: already discussed in #-linux, some kind of docker crap
2021-01-16 12:57:02 <ikke> docker+libseccomp
2021-01-16 12:57:11 <ikke> but I cannot reproduce it myself on the CI hosts
2021-01-16 12:59:38 <Hello71_> my guess would be different image version
2021-01-16 12:59:54 <Hello71_> or running apk upgrade first
2021-01-16 13:10:02 <ikke> Hello71_: thanks for getting me straight
2021-01-16 13:10:08 <ikke> I indeed forgot to upgrade musl
2021-01-16 13:10:14 <andypost[m]> looking at https://gitlab.alpinelinux.org/mpolanski/aports/-/pipelines/68152 only ppc64le CI runner works fine
2021-01-16 13:10:23 <ikke> Hello71_: faccessat2(AT_FDCWD, "/bin/sh", X_OK, AT_EACCESS) = -1 EPERM (Operation not permitted)
2021-01-16 13:10:29 <Hello71_> :)
2021-01-16 13:10:33 <ikke> Then the fix is trivial
2021-01-16 13:11:41 <ikke> Newer versions of runc are going to fix this
2021-01-16 13:12:00 <ikke> so that we don't have to update the secommp profile every time a new syscall is added
2021-01-16 13:12:12 <Hello71_> are they?
2021-01-16 13:12:58 <Hello71_> oh, I missed the last comment on the issue
2021-01-16 13:13:31 <ikke> Hello71_: link? Was trying to find it again
2021-01-16 13:14:01 <Hello71_> https://github.com/opencontainers/runc/issues/2151
2021-01-16 13:15:20 <ikke> https://github.com/opencontainers/runc/pull/2737
2021-01-16 13:18:02 <Ariadne> yes i held back faccessat2 until after 3.13
2021-01-16 13:18:34 <Ariadne> figured now was a better time to deal with it :P
2021-01-16 13:18:38 <ikke> right, but now I need to make sure container are allowed to call it
2021-01-16 13:18:43 <ikke> containers*
2021-01-16 13:18:54 <ikke> until runc is fixed
2021-01-16 13:23:15 <ikke> :(
2021-01-16 13:23:47 <ikke> sigh
2021-01-16 13:25:01 <ikke> dare I upgrade our x86_64 CI host to 3.13? :P
2021-01-16 13:28:35 <ikke> Ariadne: btw, did you see the ifupdown-ng issue regarding ifenslave?
2021-01-16 13:29:07 <Ariadne> no
2021-01-16 13:29:37 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12319
2021-01-16 13:31:03 <Ariadne> oh that's easy to fix
2021-01-16 13:31:10 <Ariadne> we just need to deprecate bonding
2021-01-16 13:31:20 <Ariadne> and use the ifupdown-ng version
2021-01-16 13:31:51 <Ariadne> it's because ifupdown-ng is rewriting the bond-slaves term internally to bond-members
2021-01-16 13:32:01 <Ariadne> and the old bonding script doesn't know bond-members
2021-01-16 13:32:08 <ikke> "The bridge and bond packages are still required."
2021-01-16 13:32:13 <ikke> from our release notes on the wiki
2021-01-16 13:32:16 <Ariadne> yeah
2021-01-16 13:32:22 <Ariadne> just fix bond for now
2021-01-16 13:32:31 <Ariadne> to look for bond-members
2021-01-16 13:32:34 <Ariadne> I'll fix it
2021-01-16 13:32:36 <ikke> ok
2021-01-16 13:33:50 <ikke> We use it on our packet/equinix hosts as well, so I guess we would be affected?
2021-01-16 13:34:38 <ikke> would it help to do s/bond-slaves/bond-members on /etc/networking/interfaces?
2021-01-16 13:37:54 <ikke> seems like bb ipcalc is broken
2021-01-16 13:37:58 <ikke> (in 3.11)
2021-01-16 13:38:49 <Ariadne> nah its 1 line fix
2021-01-16 13:39:12 <Ariadne> i just forgot to update the alpine script
2021-01-16 13:39:58 <ikke> ok, I'll wait for the package to be available
2021-01-16 13:40:05 <ikke> I wanted to upgrade the CI host to 3.13
2021-01-16 13:40:22 <ikke> which also has bond-slaves
2021-01-16 13:40:45 <ikke> But it should be bond-members, right?
2021-01-16 13:41:04 <Ariadne> it should be, but ifupdown-ng will just rewriite it internally
2021-01-16 13:41:19 <Ariadne> 0.11 will have iflint which will tell you about these things :)
2021-01-16 13:41:20 <ikke> nod, but then I will udpate it as it should be
2021-01-16 13:42:04 <Ariadne> you'll need the fixed bonding package for now
2021-01-16 13:42:22 <Ariadne> the ifupdown-ng one is better, but i wanted to be conservative for 3.13 :P
2021-01-16 13:42:49 <ikke> ok
2021-01-16 13:47:23 <ikke> ok, rebooting now 🤞
2021-01-16 13:52:26 <ikke> "Welcome to grub" -> nothing :-/
2021-01-16 13:55:15 <Hello71_> try rebooting again
2021-01-16 13:55:22 <ikke> yes
2021-01-16 13:55:33 <Hello71_> turn it off and on again
2021-01-16 13:56:43 <Hello71_> :p
2021-01-16 13:59:06 <ikke> "Enter User password" ....
2021-01-16 14:04:38 <Hello71_> heh
2021-01-16 14:05:27 <ikke> It did not do that the first reboot
2021-01-16 14:05:39 <ikke> "HDD is locked" :
2021-01-16 14:10:12 <Hello71_> ram issues?
2021-01-16 15:23:20 <Newbyte> If a package changes its name, should the paths the package installs files in correspond to this change?
2021-01-16 15:23:27 <Newbyte> And if so, how would this be handled?
2021-01-16 15:25:00 <ikke> Newbyte: depends
2021-01-16 15:25:06 <ikke> can you give a concrete example?
2021-01-16 15:25:28 <Newbyte> !16473
2021-01-16 15:28:00 <ikke> Newbyte: I guess upstream should already have renamed the package files, correct?
2021-01-16 15:29:15 <ikke> I see in the buildlog it's still called riot-web?
2021-01-16 15:30:14 <Newbyte> Upstream just provides a tarball with the web app. No particular directory structure.
2021-01-16 15:30:21 <Newbyte> And the installation is just done by copying files
2021-01-16 15:30:44 <Newbyte> So the riot-web path comes from the APKBUILD
2021-01-16 15:30:49 <ikke> aha ok
2021-01-16 15:31:17 <ikke> It would make sense to rename it
2021-01-16 15:31:33 <Newbyte> How should that be handled in the APKBUILD?
2021-01-16 15:31:38 <mps> for what dummy pkgs are built?
2021-01-16 15:31:44 <ikke> for non-config files, you don't need to do anything
2021-01-16 15:31:57 <ikke> config files (/etc/*) are more tricky
2021-01-16 15:32:07 <mps> i.e. is there a way to not make main pkg and just subpkgs
2021-01-16 15:32:13 <Newbyte> non-configuration files are removed automatically?
2021-01-16 15:32:18 <ikke> Newbyte: yes
2021-01-16 15:32:38 <ikke> otherwise packages could leave a lot of lingering files behind
2021-01-16 15:33:58 <ikke> replaces + provides like gjabel mentions helps with upgrading
2021-01-16 15:34:03 <Newbyte> Makes sense. I'll make it do that with the web content then
2021-01-16 15:35:09 <Newbyte> How would I go about doing it with the configuration file though?
2021-01-16 15:35:48 <Newbyte> 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 <Newbyte> Feels suboptimial though
2021-01-16 15:36:16 <Newbyte> And by move I mean put it in a different location
2021-01-16 15:37:16 <Newbyte> 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 <Newbyte> 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 <Newbyte> When people upgrade, that is. New installations should only have the new one
2021-01-16 16:23:39 <timlegge> any idea why make: /bin/sh: Operation not permitted on  !16898
2021-01-16 16:24:11 <ikke> timlegge: yes
2021-01-16 16:24:21 <ikke> Something I need to fix (and working on
2021-01-16 16:24:51 <ikke> basically docker/seccomp issue
2021-01-16 16:24:58 <ikke> docker/runc/seccomp
2021-01-16 17:08:11 <dalias> could alpine busybox package increase CONFIG_FEATURE_EDITING_MAX_LEN ?
2021-01-16 17:08:37 <dalias> 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 <dalias> i think it's 256 or something small
2021-01-16 17:20:55 <timlegge> ikke: thanks
2021-01-16 17:22:04 <Hello71_> why not apk add vim?
2021-01-16 17:22:41 <Hello71_> it's 18 MB but if you're already installing gcc anyways
2021-01-16 17:25:07 <dalias> vim??
2021-01-16 17:25:15 <dalias> this is for shell not editor
2021-01-16 17:25:28 <dalias> and "why not use bash?" is not an answer because bash sucks, ash is so much better
2021-01-16 17:25:54 <ikke> dalias: what is actually being limited?
2021-01-16 17:26:10 <dalias> ikke, line length
2021-01-16 17:26:11 <ikke> Never ran into this
2021-01-16 17:26:25 <dalias> it stops accepting characters after the limit (keypresses are ignored)
2021-01-16 17:26:33 <dalias> just hold down a and see where it stops
2021-01-16 17:26:56 <jvoisin> (if only ash had completion :<)
2021-01-16 17:27:04 <ikke> dalias: lol, I was just doing that :D
2021-01-16 17:44:31 <mps> jvoisin: ash have completion, not as 'big' ones though
2021-01-16 17:45:03 <mps> path and filename, enough
2021-01-16 17:47:57 <Hello71_> zsh
2021-01-16 17:48:16 <mps> hm, I think ash max line len is around 2000
2021-01-16 17:48:35 <mps> in alpine, I mean
2021-01-16 17:48:53 <mps> tcsh
2021-01-16 17:49:34 <mps> tcsh is small but have all 'bells and whistles' needed for normal interactive use
2021-01-16 17:51:59 <detha> if only ash had !pattern
2021-01-16 17:52:20 <detha> That alone is enough to not be usable for interactive work
2021-01-16 17:54:10 <ikke> and alt+.
2021-01-16 17:54:54 <mps> what is 'alt+'
2021-01-16 17:55:03 <mps> in which shell
2021-01-16 17:55:28 <ikke> alt + <dot>
2021-01-16 17:55:32 <ikke> bash, zsh
2021-01-16 17:55:42 <ikke> recall last argument
2021-01-16 17:56:20 <mps> ah, emacs mode
2021-01-16 18:26:06 <dalias> 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 <dalias> 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 <detha> dalias: it is a 'do what I say, not what I mean' feature.
2021-01-16 18:41:04 <detha> However, not having it means unlearning 20+ years of muscle memory. I'll take the risk.
2021-01-16 18:42:23 <detha> If I want belts and suspenders, I'll do the centos thing and alias rm='rm -i'
2021-01-16 18:42:39 <dalias> it's not about belts and suspenders but behaving contrary to spec and least-surprise
2021-01-16 18:43:09 <dalias> i pity folks who learned on that badness and rightly dont want to spend effort unlearning it :-p
2021-01-16 18:45:41 <detha> Matter of taste I guess, least surprise for me is ! just working like it should :p
2021-01-16 20:03:17 <Newbyte> How could ! turn into an accidental rm -rf /?
2021-01-16 20:12:18 <detha> if 'rm *' is the most recent thing starting with r, 'cd /; !r' would do that.
2021-01-16 20:12:29 <detha> Why someone would type that is another question
2021-01-16 20:18:27 <Ariadne> [10:26:52] <jvoisin> (if only ash had completion :<)
2021-01-16 20:18:42 <Ariadne> i have some patches halfway done for that
2021-01-16 21:38:04 <maxice8> !16894
2021-01-17 01:40:18 <maxice8> opinions on https://lists.alpinelinux.org/~alpine/devel/%3Cd0c4cab578c513f312390679680eb1cf31690a05.camel%40gmail.com%3E ?
2021-01-17 07:10:48 <maxice8> Ariadne: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12320 should we remove amavis ?
2021-01-17 07:18:16 <maxice8> 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 <ikke> maxice8: I tried that
2021-01-17 07:18:31 <maxice8> oh
2021-01-17 07:18:59 <ikke> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#time64_requirements has some more details
2021-01-17 07:23:06 <maxice8> huh, the ppc64le builder seems to be working
2021-01-17 07:23:10 <maxice8> :D python3 worked
2021-01-17 07:23:51 <maxice8> https://gitlab.alpinelinux.org/Leo/aports/-/jobs/295560 :D
2021-01-17 07:31:52 <ikke> maxice8: so that's why I decide to upgrade the x86_64 ci host
2021-01-17 07:31:55 <ikke> and the rest is history
2021-01-17 07:32:11 <maxice8> huh
2021-01-17 07:32:35 <ikke> https://ibb.co/KqPHHNZ
2021-01-17 08:05:58 <afontain_> maxice8: I'm in favor of removing -static for static libs and keeping it only for static binaries
2021-01-17 08:06:49 <maxice8> 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 <afontain_> I always had the impression those were pointless, and it create issues
2021-01-17 08:06:59 <afontain_> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11592
2021-01-17 08:07:02 <maxice8> It can possibly implicitly be infered from the fact I praised static linking on Alpine Linux
2021-01-17 08:36:27 <mps> also I 'advocating' this for about two years
2021-01-17 08:37:25 <mps> even 'vetoed' -static for libs I maintain
2021-01-17 10:50:11 <nmeum> hm, is the gitlab ci broken atm?
2021-01-17 10:50:27 <Cogitri> Yup
2021-01-17 10:50:30 <nmeum> > The C compiler "/usr/bin/gcc" is not able to compile a simple test program.
2021-01-17 10:50:31 <nmeum> ah
2021-01-17 10:50:38 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12321
2021-01-17 10:51:25 <ikke> something something faccessat2
2021-01-17 10:51:43 <ikke> (libseccomp actuall)
2021-01-17 10:53:27 <nmeum> I thought this wasn't an issue with recent containerd verison?
2021-01-17 10:53:28 <nmeum> https://github.com/containerd/containerd/commit/6a915a1453a5bfd859664679e1ac478a7022c7f6
2021-01-17 10:53:30 <nmeum> etc pp
2021-01-17 10:55:43 <ikke> most CI hosts are still Alpine 3.11
2021-01-17 12:37:31 <Ariadne> [01:37:21] <mps> even 'vetoed' -static for libs I maintain
2021-01-17 12:37:38 <Ariadne> agree.  -static is bad.  i have done the same
2021-01-17 13:11:49 <Hello71_> nmeum: also as I explained in 3.13 release notes (although according to aria
2021-01-17 13:12:15 <Hello71_> dne, this shouldn't affect 3.13), you need new libseccomp too
2021-01-17 13:15:46 <Newbyte> Are the x86_64 builders doing okay?
2021-01-17 13:16:32 <Newbyte> The x86_64 CI job for !16473 keeps failing due to the job timing out
2021-01-17 13:28:40 <ikke> Hello71_: this should be new enough, right? https://pkgs.alpinelinux.org/packages?name=libseccomp&branch=v3.11
2021-01-17 13:29:01 <ikke> Hello71_: somehow, even with the latest seccomp (passed as --seccomp-profile to dockerd), it was still blocked
2021-01-17 13:29:10 <ikke> but I did not do the other debugging command that you listed on the wiki yet
2021-01-17 13:29:19 <Hello71_> ikke: you can adapt the scmp_sys_resolver
2021-01-17 13:33:26 <Hello71_> ikke: libseccomp needs to be 2.4.4+
2021-01-17 13:33:29 <Hello71_> for faccessat2
2021-01-17 13:33:39 <Hello71_> "syscalls: update the syscall table for Linux v5.8.0-rc5"
2021-01-17 13:33:49 <ikke> Hello71_: aha
2021-01-17 13:33:58 <ikke> Hello71_: htanks
2021-01-17 13:34:01 <ikke> thanks*
2021-01-17 13:34:04 <Hello71_> we can probably safely backport that
2021-01-17 13:39:34 <ikke> Hello71_: I need an incentive to upgrade our hosts :P
2021-01-17 13:39:43 <Hello71_> mmhmm
2021-01-17 13:39:58 <ikke> (and break them in the mean time)
2021-01-17 15:32:58 <minimal> 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 <ikke> minimal: yes, indeed looks like it
2021-01-17 15:35:58 <minimal> other possibility is that its password protected/locked by BIOS rather than the drive itself
2021-01-17 15:36:45 <ikke> We provisioned a new server
2021-01-17 15:38:08 <Hello71_> well hdd password long predates hardware encryption
2021-01-17 15:41:24 <minimal> 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 <ikke> does not supprise me one bit
2021-01-17 15:43:18 <minimal> 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 <ikke> haha :D
2021-01-17 15:44:30 <Hello71_> 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 <Hello71_> it was later overloaded by decryption password entry
2021-01-17 15:47:10 <minimal> 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 <minimal> Question: what's the difference between 3.13 and 3.13-stable with regard to MRs?
2021-01-17 15:50:36 <ikke> minimal: euhm?
2021-01-17 15:50:42 <ikke> do you mean branch name?
2021-01-17 15:50:51 <ikke> there should only be 3.13-stable as a branch
2021-01-17 15:51:49 <minimal> 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 <ikke> 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 <Hello71_> sounds like typo
2021-01-17 15:53:24 <minimal> right but seems Leo has done that, so not sure what his comment then meant. !16816
2021-01-17 15:53:39 <ikke> yeah
2021-01-17 15:53:41 <ikke> perhaps 3.12?
2021-01-17 15:54:10 <ikke> although that does not make sense either
2021-01-17 15:54:15 <ikke> maxice8: what did you mean? ^
2021-01-17 15:54:40 <minimal> 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 <ikke> yeah
2021-01-17 15:56:21 <ikke> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) :(
2021-01-17 15:57:26 <Hello71_> missing initramfs
2021-01-17 15:57:29 <minimal> ikke: seems like you're having a run of bad luck
2021-01-17 15:59:04 <ikke> I did add lvm vgchange --sysinit --activate y to mkinitfs-init
2021-01-17 16:22:04 <opal> 
ACTION slaps minimal around a bit with a large trout.

2021-01-17 16:22:10 <opal> hard drives smh
2021-01-17 16:22:46 <opal> minimal nice reverse dns btw
2021-01-17 16:53:14 <maxice8> 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 <ikke> aha
2021-01-17 17:02:29 <minimal> maxice8: haven't done a backport before so wasn't clear on the procedure
2021-01-17 17:07:26 <minimal> so separate MRs for Edge/master and for 3.13-stable?
2021-01-17 17:07:40 <ikke> yes
2021-01-17 17:07:50 <ikke> the stable branches are separate branches based of master
2021-01-17 17:07:51 <maxice8> Impossible not to be
2021-01-17 17:08:12 <ikke> you basically need to cherry-pick in order to backport
2021-01-17 17:08:26 <maxice8> An MR needs a target branch
2021-01-17 17:12:13 <ikke> which defaults to master
2021-01-17 17:13:09 <maxice8> Which can't be more than 1 branch
2021-01-17 17:14:02 <minimal> yeah, just getting the steps clear in my head
2021-01-17 17:16:58 <minimal> BTW who looks after security issues?
2021-01-17 17:19:30 <Cogitri> The maintainer of the respective package does
2021-01-17 17:21:35 <minimal> Cogitri: I meant is there an Alpine security team
2021-01-17 17:21:57 <ikke> https://gitlab.alpinelinux.org/team
2021-01-17 17:24:09 <minimal> ikke: Thanks. No specific team for security there, guess I'll ping ncopa direct
2021-01-17 17:31:33 <minimal> 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 <ikke> No, gitlab itself distinguishes it
2021-01-17 17:32:16 <minimal> ok
2021-01-17 17:32:33 <ikke> check the open merge requests for openjdk
2021-01-17 17:32:47 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&search=openjdk7
2021-01-17 17:34:27 <minimal> got it. thanks
2021-01-17 17:34:54 <ikke> although, you see they did add a prefix to the MR title as well
2021-01-17 17:35:32 <maxice8> 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 <minimal> 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 <ikke> The commits at least should not have it
2021-01-17 17:36:34 <ikke> the MR title is optional
2021-01-17 17:43:10 <maxice8> never put the prefix in the commits
2021-01-17 17:48:26 <bratkartoffel> can someone please merge !15297 and !15298? edge is already updated, just the backports are missing
2021-01-17 17:49:11 <ikke> bratkartoffel: lol, I just linked to those
2021-01-17 17:49:18 <ikke> (unrelated, but still)
2021-01-17 17:50:28 <bratkartoffel> oh, haven't read the scrollback :)
2021-01-17 17:50:37 <ikke> np
2021-01-17 18:06:12 <ikke> Ok, we have an x86_64 runner again
2021-01-17 18:06:33 <Cogitri> Hurray
2021-01-17 18:08:10 <ikke> so, now, do I dare to do x86 as well? :P
2021-01-17 18:08:16 <ikke> I must be an expert at this point
2021-01-17 18:08:31 <ikke> to 3.12 for now
2021-01-17 19:08:17 <timlegge> 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 <ikke> timlegge: outdated docker / libseccomp
2021-01-17 19:09:14 <ikke> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#time64_requirements
2021-01-17 19:10:08 <ikke> for faccessat2 (the issue you are running into), you need at least 2.4.4
2021-01-17 19:10:13 <ikke> for libseccomp
2021-01-17 19:10:15 <timlegge> timlegge should really read Release Notes :-) - Thanks
2021-01-17 20:13:11 <Ariadne> that issue only effects edge anyway
2021-01-17 20:13:17 <Ariadne> i held back faccessat2 in 3.13
2021-01-17 20:13:30 <ikke> nod
2021-01-17 20:13:43 <ikke> but, it affects users who use alpine:edge
2021-01-17 20:20:48 <mps> what for is 'Lock merge request' in gitlab web ui
2021-01-17 20:21:58 <ikke> probably preventing non-contributors to comment
2021-01-17 20:22:16 <ikke> "Lock this merge request? Only project members will be able to comment."
2021-01-17 20:22:44 <ikke> In case you get a lot of off-topic / low value comments on a certain MR
2021-01-17 20:23:08 <mps> aha, good to know, thanks
2021-01-17 20:23:31 <mps> now I have tool to (over)use :)
2021-01-17 20:24:33 <mps> testing it here !16940
2021-01-17 20:25:10 <mps> huh, now see wrong commit msg, s/aports/aport/
2021-01-17 20:27:33 <mps> !16940
2021-01-17 20:27:46 <mps> meh
2021-01-17 20:43:55 <mps> https://gitlab.alpinelinux.org/mps/aports/-/jobs/295926#L134 'make: uname: Operation not permitted'
2021-01-17 20:44:03 <mps> uname also
2021-01-17 20:44:33 <ikke> yes
2021-01-17 20:44:37 <ikke> working on it
2021-01-17 20:44:47 <mps> no worries
2021-01-17 20:44:49 <ikke> x86 should be fixed soon as well
2021-01-17 20:44:59 <ikke> lots of issues related to this
2021-01-17 20:45:11 <mps> I follow your effort, sorry I can't help
2021-01-17 20:45:27 <ikke> no problem
2021-01-17 20:45:37 <ikke> x86 went noticibly faster than x86_64 :P
2021-01-17 20:45:44 <ikke> though, I still had to reinstall the host
2021-01-17 20:49:50 <ikke> ok, new x86 runner is online
2021-01-17 20:50:20 <mps> what is with x86_64
2021-01-17 20:50:32 <ikke> that it took longer?
2021-01-17 20:50:49 <mps> aha, ok, no hurries
2021-01-17 20:50:52 <ikke> no
2021-01-17 20:51:07 <ikke> first, the physical disks were locked
2021-01-17 20:51:12 <ikke> so we had to provision a complete new server
2021-01-17 20:51:35 <ikke> 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 <ikke> but apparently it does work on the x86 host (with efi)
2021-01-17 20:51:59 <mps> yes, I follow -infra
2021-01-17 20:52:09 <ikke> heh
2021-01-17 20:52:15 <ikke> so fun
2021-01-17 20:52:40 <mps> I don't have access to these consoles I think
2021-01-17 20:52:54 <ikke> no
2021-01-17 20:53:23 <mps> good
2021-01-17 21:55:44 <mps> 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 <Cogitri> -Wno-error :D
2021-01-17 21:59:27 <ikke> heh
2021-01-17 21:59:57 <mps> funny is comparison there :)
2021-01-17 22:00:49 <ikke> basically, is c between value a and b
2021-01-17 22:01:37 <ikke> I don't understand for what data type this would be always true
2021-01-17 22:02:15 <ikke> oh, it's complaining about '\x00' <= c
2021-01-17 22:02:42 <ikke> so that part could be easily patched out
2021-01-17 22:03:20 <maxice8> heh, signal is getting so popular, we got a patchset for signal-cli
2021-01-17 22:03:44 <ikke> heh
2021-01-17 22:04:09 <Cogitri> The compiler probably optimizes that comparison away anyway
2021-01-17 22:04:21 <Cogitri> (So it's warning because that comparison is useless and probably wrong)
2021-01-17 22:05:00 <ikke> yup
2021-01-17 22:05:15 <ikke> https://tpaste.us/oPdB
2021-01-17 22:06:25 <Cogitri> Huh, `and` instead of `&&` is a thing in C++
2021-01-17 22:06:35 <Cogitri> Learning some new oddness about C++ every day, I suppose :D
2021-01-17 22:06:40 <Ariadne> wtf
2021-01-17 22:06:41 <ikke> heh, didn't even occur to me
2021-01-17 22:06:44 <Ariadne> why
2021-01-17 22:06:46 <mps> :)
2021-01-17 22:06:53 <ikke> it looks to me the author is a python programmer
2021-01-17 22:06:56 <tehcloud> just wait until they get rid of the preprocessor in C++23
2021-01-17 22:07:22 <ikke> if a <= b <= c:
2021-01-17 22:08:43 <maxice8> Cogitri: what isn't a thing in C++ ?
2021-01-17 22:09:06 <ikke> the code uses 'and' instead of '&&'
2021-01-17 22:09:25 <ikke> why is this not failing in my container?
2021-01-17 22:11:00 <Cogitri> 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 <tehcloud> it's on the table
2021-01-17 22:11:28 <tehcloud> was having a little chat with someone who is on the committee last week
2021-01-17 22:11:35 <Cogitri> Yeah, but it'll take some time for everything to get to c++20
2021-01-17 22:13:48 <ikke> Ariadne: would that patch make sense?
2021-01-17 22:30:53 <Hello71_> 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 <Ariadne> ikke: would what patch
2021-01-17 23:26:58 <Ariadne> ikke: yes, seems reasonable
2021-01-17 23:43:26 <Hello71_> 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 <Ariadne> that's another reasonable patch
2021-01-17 23:45:33 <Hello71_> https://tpaste.us/oPdB has unintended logic on signed char platforms
2021-01-17 23:46:58 <Ariadne> yes, but none of our platforms are signed char ^_^
2021-01-17 23:48:21 <maxice8> Is there a programmatic way to get dependencies in CMake like with pkgconf --print-requires
2021-01-17 23:48:36 <maxice8> ?
2021-01-17 23:57:49 <Hello71_> Ariadne: uh
2021-01-18 00:03:36 <Hello71_> Ariadne: i wish
2021-01-18 01:54:16 <Ariadne> one can dream
2021-01-18 01:54:34 <Ariadne> it is true, s390x and powerpc are signed char
2021-01-18 01:54:42 <Ariadne> i think x86 is unsigned tho
2021-01-18 06:16:57 <afontain_> there's -f-signed-char, but I don't know if it's relevant
2021-01-18 06:17:23 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16965
2021-01-18 07:13:26 <ncopa> good morning
2021-01-18 07:13:53 <maxice8> morning
2021-01-18 07:39:20 <maxice8> !16894
2021-01-18 08:32:18 <clandmeter> morning
2021-01-18 08:34:23 <mps> clandmeter: goede morgen :)
2021-01-18 08:35:04 <clandmeter> was there a way to get the origin/subpkgs from apk?
2021-01-18 08:40:51 <clandmeter> maxice8: i think you didnt bump pkgrel for some lua pkgs
2021-01-18 08:40:58 <clandmeter> not sure there are more
2021-01-18 08:41:11 <maxice8> oof
2021-01-18 08:41:23 <maxice8> I'll check the lua commits, currently reviewing PureTryOut MR
2021-01-18 08:41:33 <clandmeter> i purged a few
2021-01-18 08:41:51 <clandmeter> ERROR: lua-socket-3.0_rc1_git20160306-r2: BAD signature
2021-01-18 08:41:51 <clandmeter> ERROR: lua5.2-socket-3.0_rc1_git20160306-r2: BAD signature
2021-01-18 08:41:51 <clandmeter> ERROR: lua5.2-sec-0.9-r0: BAD signature
2021-01-18 08:41:51 <clandmeter> ERROR: lua5.1-socket-3.0_rc1_git20160306-r2: BAD signature
2021-01-18 08:42:07 <maxice8> lua5.x is a subpkg of lua-X
2021-01-18 08:42:15 <maxice8> we have lua-X and create lua$LUAVER-X
2021-01-18 08:43:09 <clandmeter> yes, but sec is not a subpkg
2021-01-18 08:44:01 <clandmeter> i was wondering if i could get all subpkgs from any pkgname and let apk return it
2021-01-18 08:44:12 <clandmeter> so i could make a simple script to PURGE them.
2021-01-18 08:50:58 <maxice8> unfortunately I don't think so
2021-01-18 08:51:11 <maxice8> if you're making an script you can source the APKBUILD and echo $subpackages
2021-01-18 09:01:01 <clandmeter> maxice8: still a challenge if i only know subpkg name
2021-01-18 09:01:41 <maxice8> apk list -o ?
2021-01-18 09:02:42 <clandmeter> hmm
2021-01-18 09:02:53 <clandmeter> that does seem to list them all
2021-01-18 09:03:15 <clandmeter> i think ive used this before, but its not very obvious :)
2021-01-18 09:03:26 <clandmeter> i would expect apk info to help me.
2021-01-18 09:05:15 <clandmeter> uhm, it only works for the origin pkg.
2021-01-18 09:07:17 <mps> dalias: !16975 postfix upstream finally merged musl DANE fix patch :)
2021-01-18 09:30:45 <mps> 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 <rnalrd> mps, pls go ahead, thanks!
2021-01-18 09:33:45 <mps> rnalrd: thank you
2021-01-18 11:45:37 <ikke> mps: could you perhaps take a look at dovecot on 3.12?
2021-01-18 11:45:42 <ikke> it fails on 32-bits arches
2021-01-18 11:50:34 <mps> hmm, who merged it, it didn't worked on CI
2021-01-18 11:51:11 <mps> will look in a few hour, I'm now busy with $job
2021-01-18 11:51:25 <mps> hours*
2021-01-18 11:51:41 <ikke> 6bd01a05ab9aa278c9113f3f81f32f55cde5f990
2021-01-18 11:51:43 <ikke> sure
2021-01-18 11:52:05 <ikke> I just noticed that on build.a.o these were marked as failed
2021-01-18 11:52:10 <mps> although already looked at builder logs, and have idea what should be fixed
2021-01-18 11:52:30 <ikke> ncopa: did you already perge latest-stable on fastly?
2021-01-18 12:38:59 <maxice8> https://lists.alpinelinux.org/~alpine/devel/%3Cbf7ab4943efc85b6139bc34d038c15620bbac45b.camel%40gmail.com%3E
2021-01-18 12:42:23 <mps> maxice8: good, but we shouldn't change pkgs which have -tools like names upstream
2021-01-18 12:43:56 <maxice8> ?
2021-01-18 12:44:58 <mps> alsa-tools will not become alsa-utils
2021-01-18 12:46:11 <maxice8> never talked about -tools in the email
2021-01-18 12:46:28 <mps> then all is ok
2021-01-18 12:48:29 <mps> not sure what about util/s which contain just one util, singular or plural name
2021-01-18 12:48:51 <maxice8> plural
2021-01-18 12:52:34 <Hello71_> 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 <mps> hmm, I though that relates to alpine derived names only
2021-01-18 12:53:52 <mps> thought*
2021-01-18 12:54:24 <mps> first alpine rule in pkg names is 'follow upstream'
2021-01-18 12:57:55 <Cogitri> Yes, that's what is the plan in the RFC
2021-01-18 12:58:27 <Cogitri> To only rename subpackages Alpine created, so we have a consistent naming scheme for subpackages
2021-01-18 14:04:01 <ncopa> ikke: i did
2021-01-18 14:12:05 <mps> ncopa: would you mind to look at !16940
2021-01-18 14:14:56 <mps> maxice8: found gptfdisk cve reference, will add it after finishing with dovecot for 3.12-stable
2021-01-18 14:52:25 <ikke> ncopa: ok
2021-01-18 15:07:19 <minimal> mps: if you do take over u-boot then could you take a look at !15746 ?
2021-01-18 15:08:58 <PureTryOut[m]2> 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 <mps> minimal: will look for sure, but not now, I'm overloaded these days. sorry
2021-01-18 15:11:41 <minimal> no problem
2021-01-18 15:12:00 <mps> if I forgot please remind me
2021-01-18 15:24:06 <PureTryOut[m]2> 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 <bratkartoffel> 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 <bratkartoffel> We've got to be more careful about nextcloud updates in the future...
2021-01-18 16:07:10 <bratkartoffel> rnalrd: ping as you're the maintainer for nextcloud
2021-01-18 16:10:13 <bratkartoffel> maybe we should provide versioned packages?
2021-01-18 16:11:02 <rnalrd> bratkartoffel, that is what nextcloud19 package is for
2021-01-18 16:11:07 <rnalrd> transitional package
2021-01-18 16:13:07 <rnalrd> it's not an in-place upgrade, you have to remove all nextcloud packages and install nextcloud19
2021-01-18 16:14:22 <rnalrd> 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 <rnalrd> 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 <rnalrd> there should be*
2021-01-18 16:17:51 <ikke> 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 <ikke> 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 <rnalrd> yeah, setting provides for "nextcloud" would pull version 20 anyway, so it would not help
2021-01-18 16:20:03 <bratkartoffel> rnalrd: thanks for clarification. i'm using a docker container which installs nextcloud, so no message for me
2021-01-18 16:20:07 <ikke> rnalrd: and replaces?
2021-01-18 16:20:16 <bratkartoffel> i'll retry the upgrade this night and post any issues i encounter
2021-01-18 16:20:19 <rnalrd> 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 <rnalrd> hum, right I should try, replaces..
2021-01-18 16:21:23 <rnalrd> bratkartoffel, right, that another use case... hum
2021-01-18 16:21:30 <ikke> And I guess nextcloud-20 should then replace nextcloud19
2021-01-18 16:21:36 <rnalrd> yup
2021-01-18 16:27:01 <rnalrd> bratkartoffel, sound like your suggestion to use package versioning could be a good solution
2021-01-18 16:27:37 <rnalrd> we will face this problem every once in a while because NC is released more often than AL
2021-01-18 17:11:41 <mps> ikke: do I need bump pkgrel for dovecot fix to push
2021-01-18 17:12:12 <mps> I think yes, because it is already built on 64bit arches
2021-01-18 17:12:19 <ikke> 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 <ikke> but if you think it significantly changes what's built, then yes
2021-01-18 17:12:56 <ikke> if you are unsure this affects other arches, you could bump it, just to be sure
2021-01-18 17:13:03 <mps> but then versions will be different in archives
2021-01-18 17:13:21 <ikke> like I said, it depends on the kind of change
2021-01-18 17:13:53 <mps> hmm, when in doubth "BUMP" :)
2021-01-18 17:13:58 <ikke> ye
2021-01-18 18:52:43 <mps> ikke: looks like dovecot passed 3.12 builders
2021-01-18 18:52:53 <ikke> mps: yes, thanks for working on that
2021-01-18 18:53:07 <ikke> only ppc64le is still working
2021-01-18 18:53:10 <mps> np
2021-01-18 18:53:34 <mps> as it says: pleasure is mine :)
2021-01-18 18:54:05 <mps> but have to say thanks (I did ofc) to upstream for fast fix
2021-01-18 18:54:48 <ikke> Yes, that's always nice
2021-01-18 18:55:22 <mps> whoever says IRC is not good for development should be slapped daily by big trouts ;)
2021-01-18 18:56:00 <ikke> give me irc any day over other chat systems
2021-01-18 19:03:01 <Ariadne> 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 <PureTryOut[m]2> [[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 <ikke> PureTryOut[m]2: snapshots ('the snapshot function') does not scale
2021-01-18 19:34:25 <PureTryOut[m]2> Well I'm all ears for a different way to do it. This was just a PoC
2021-01-18 19:38:41 <ikke> Thinking a bit about it
2021-01-18 19:38:50 <ikke> normally the fetch function fetches the source
2021-01-18 19:39:02 <ikke> but to know what to fetch, you need to look inside the source
2021-01-18 19:44:21 <Ariadne> fwiw i think alpine should focus on dhcpcd moving forward
2021-01-18 19:45:41 <ikke> moving forward where?
2021-01-18 19:49:21 <PureTryOut[m]2> 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 <ikke> But that involves distributing these tarballs somewhere
2021-01-18 19:52:31 <Ariadne> ikke: 3.14 and later
2021-01-18 19:52:44 <Ariadne> we're starting to see network deployments that are IPv6-first
2021-01-18 19:52:56 <Ariadne> anyway i explained it on devel :)
2021-01-18 19:54:24 <Hello71_> what's wrong with udhcpc6 (that isn't also wrong with udhcpc)?
2021-01-18 19:56:17 <PureTryOut[m]2> 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 <ikke> yeah, we don't want binaries in our aports tree
2021-01-18 19:57:36 <ikke> this is not isolated to go btw
2021-01-18 19:57:47 <ikke> rust, haskell and maybe other languages as well
2021-01-18 19:59:05 <ikke> PureTryOut[m]2: having the go.mod / go.sum file in the tree would already be enough, though
2021-01-18 20:00:48 <PureTryOut[m]2> 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 <PureTryOut[m]2> 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 <ikke> well, you'd vendor the deps somewhere in the fetch phase already
2021-01-18 20:03:40 <Cogitri> 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 <Cogitri> 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 <Ariadne> [13:54] <Hello71_> what's wrong with udhcpc6 (that isn't also wrong with udhcpc)?
2021-01-18 20:05:02 <Ariadne> from ifupdown perspective it is preferable to have a single client which does both
2021-01-18 20:06:01 <Ariadne> that way we can treat it as a single operation
2021-01-18 20:06:28 <PureTryOut[m]2> 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 <ikke> Ariadne: how do you deal with android clients in a ipv6 dhcp world?
2021-01-18 20:06:50 <Ariadne> beyond that dhcpcd is better maintained
2021-01-18 20:06:59 <Ariadne> dunno, not my problem :p
2021-01-18 20:07:06 <Cogitri> PureTryOut[m]2: Go and Rust builds are reproducible even with net
2021-01-18 20:07:11 <ikke> PureTryOut[m]2: for go itself it would not matter a bit
2021-01-18 20:07:12 <Cogitri> As long as the deps are binned
2021-01-18 20:07:20 <Ariadne> probably 464xlat
2021-01-18 20:07:27 <Cogitri> which at least with Rust they're basically always are via Cargo.lock
2021-01-18 20:07:36 <Cogitri> versioned is pinned and everything is checksummed
2021-01-18 20:07:44 <ikke> with go modules as well
2021-01-18 20:07:58 <ikke> if you use go.mod, you automatically get a go.sum
2021-01-18 20:08:04 <PureTryOut[m]2> Then why are distros like Debian and openSUSE making such an issue out of it?
2021-01-18 20:08:11 <Ariadne> as i said on twitter i think ipv4 flag day is a pipe dream
2021-01-18 20:08:25 <Ariadne> but it makes sense to start taking an ipv6-first approach
2021-01-18 20:08:53 <ikke> 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 <ikke> which is also not like debian does it
2021-01-18 20:09:35 <ikke> as long as you trust the checksums, that part is reproducable
2021-01-18 20:10:12 <ikke> PureTryOut[m]2: what we are not protected against is sources going missing
2021-01-18 20:10:29 <ikke> maybe that's the reason other distros vendor everything
2021-01-18 20:10:56 <PureTryOut[m]2> Hmm
2021-01-18 20:11:14 <PureTryOut[m]2> At least it would be nice if we could enforce `options="net"` for Go, Rust and Haskell packages
2021-01-18 20:12:10 <ikke> you mean options="!net" :)
2021-01-18 20:14:04 <PureTryOut[m]2> Hmm? No to allow those to build with rootbld, they need net
2021-01-18 20:14:16 <PureTryOut[m]2> And that also marks them, makes it easier to find when needing to change it later
2021-01-18 20:14:34 <PureTryOut[m]2> (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 <ikke> doesn't 'net' mean they are allowed to download things from the net?
2021-01-18 20:15:04 <PureTryOut[m]2> Yes
2021-01-18 20:15:13 <PureTryOut[m]2> That means they can at least be build with rootbld
2021-01-18 20:15:29 <ikke> oh, now I understand what you mean
2021-01-18 20:15:49 <PureTryOut[m]2> Seems nobody except me uses rootbld 🤷‍♂️
2021-01-18 20:16:05 <ikke> It does not work in LXC without more permissions
2021-01-18 20:16:32 <ikke> and rootbld in docker does not make a lot of sense either
2021-01-18 20:17:01 <ikke> (apart from the disabling of the network during build)
2021-01-18 20:17:48 <PureTryOut[m]2> 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 <PureTryOut[m]2> And the net option is a thing, so please just use it lol
2021-01-18 20:20:17 <PureTryOut[m]2> 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 <ikke> maybe abuild should assume option="net" if go / rust / ghc is in makedepends
2021-01-18 20:20:33 <ikke> for the time being I mean
2021-01-18 20:22:06 <PureTryOut[m]2> That would work too I guess
2021-01-18 20:27:43 <Hello71_> as long as it could be overridden with options=!net
2021-01-18 20:28:00 <ikke> Hello71_: yeah, that was my idea in that case
2021-01-18 20:36:47 <Hello71_> Ariadne: of recent(-ish) archs, x86, mips, sh, sparc are all signed char
2021-01-18 20:37:31 <Hello71_> x86-32 and x86-64
2021-01-18 20:37:40 <Hello71_> according to gcc
2021-01-18 20:39:10 <ikke> Hello71_: so there are no recent arches that have unsigned char?
2021-01-18 20:39:57 <Hello71_> well as we found the other day, arm is unsigned char
2021-01-18 20:40:09 <ikke> ah ok
2021-01-18 20:40:24 <ikke> so the json patch makes sens then
2021-01-18 20:40:27 <Hello71_> 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 <Hello71_> but that last part is almost never relevant
2021-01-18 20:42:32 <Hello71_> arm(32/64), riscv, ppc, s390x all signed char by default
2021-01-18 20:42:54 <ikke> signed or unsigned?
2021-01-18 20:43:08 <ikke> ohg, signed, yes
2021-01-18 20:43:10 <Hello71_> so simply removing the c<0 will result in improper behavior
2021-01-18 20:43:15 <ikke> yes
2021-01-18 20:43:19 <Hello71_> uh, unsigned
2021-01-18 20:43:22 <Hello71_> for the last one
2021-01-18 20:43:42 <ikke> yes
2021-01-18 20:43:47 <ikke> so the upstream patch is better
2021-01-18 20:43:51 <Hello71_> 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 <ikke> aaaah
2021-01-18 20:44:25 <ikke> that explains why it worked in my container :P
2021-01-18 20:44:29 <ikke> I thought it failed on all arches
2021-01-18 20:46:16 <ikke> Hello71_: thanks for explaining
2021-01-18 20:46:48 <ozzz> guys, seems m4 is broken in armv7 repo
2021-01-18 20:46:59 <ikke> ozzz: docker?
2021-01-18 20:47:09 <ozzz> no, arm tablet
2021-01-18 20:47:17 <ikke> broken in what way?
2021-01-18 20:47:50 <Hello71_> well the right answer is probably not to use werror :/
2021-01-18 20:47:50 <ozzz> if I try to install it, it says - ERROR: m4-1.4.18-r1: BAD signature
2021-01-18 20:48:32 <ozzz> I tried to recompile it from source - FAIL: test-canonicalize-lgpl
2021-01-18 20:48:58 <ikke> hmm
2021-01-18 20:49:09 <ikke> gettext had the same failure
2021-01-18 20:49:19 <Hello71_> did you try rm /etc/apk/cache/*; apk update
2021-01-18 20:49:31 <Hello71_> ikke: i think this is that gnulib realpath("//") nonsense
2021-01-18 20:49:35 <ikke> yes
2021-01-18 20:49:41 <ozzz> I removed using apk, but I'll try now
2021-01-18 20:49:42 <PureTryOut[m]2> 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 <ikke> PureTryOut[m]2: heh
2021-01-18 20:49:56 <ikke> ozzz: check the gettext aport
2021-01-18 20:49:59 <ikke> it has a patch
2021-01-18 20:50:03 <ozzz> ok
2021-01-18 20:51:48 <ozzz>  rm /etc/apk/cache/*; apk update - that helped
2021-01-18 20:51:58 <ozzz> thanks a lot!
2021-01-18 20:55:42 <ikke> Hello71_: why does deleting the cache help?
2021-01-18 20:56:18 <Hello71_> corrupted cache? or whatever required purging latest-stable
2021-01-18 20:56:41 <ikke> oh, I missed the remark about bad signature
2021-01-18 20:59:26 <Hello71_> ok :)
2021-01-18 20:59:44 <ikke> I was thinking it somehow relating to the m4 issue
2021-01-18 21:03:22 <Hello71_> mmhmm
2021-01-19 06:11:14 <nmeum> is the webfrontend for lists.alpinelinux.org no longer available? 404's here
2021-01-19 06:11:44 <maxice8> Working here
2021-01-19 06:15:42 <nmeum> ah, now it works here too. maybe it was just briefly offline
2021-01-19 07:41:46 <mps> I had bad experience with dhcpcd, it likes to mess with manually configured things
2021-01-19 10:08:51 <ncopa> morning
2021-01-19 10:09:55 <ncopa> 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 <ncopa> ikke: do you have the tool in git somewhere?
2021-01-19 10:13:50 <ikke> ncopa: not yet, will finish it somewhere this week and will do that
2021-01-19 10:14:05 <ncopa> care to share what you have so far?
2021-01-19 10:14:14 <ncopa> $ tpaste < purge-dlcdn-cache.go
2021-01-19 10:14:14 <ncopa> https://tpaste.us/DMad
2021-01-19 10:16:06 <ikke> ncopa: https://tpaste.us/BEab
2021-01-19 10:29:05 <ikke> ncopa: I was thinking to create a namespace for go on gitlab
2021-01-19 10:29:16 <ikke> and then to create a redirect from alpinelinux.org/go to there
2021-01-19 10:29:57 <ikke> Then you can import alpinelinux.org/go/apk/<..> and it automatically owrks
2021-01-19 10:46:44 <bratkartoffel> 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 <ikke> bratkartoffel: Not aware of any
2021-01-19 10:53:46 <ikke> does nextcloud itself has documentation on this?
2021-01-19 10:56:25 <bratkartoffel> 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 <bratkartoffel> https://docs.nextcloud.com/server/latest/admin_manual/maintenance/upgrade.html
2021-01-19 10:58:35 <bratkartoffel> 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 <ikke> 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 <ikke> ncopa: this is the latest version: https://tpaste.us/byqW
2021-01-19 11:43:09 <bratkartoffel> i've added a section for nextcloud, thanks for the link ikke
2021-01-19 11:43:12 <ikke> the previous one was an older version
2021-01-19 11:46:24 <ikke> bratkartoffel: thanks
2021-01-19 12:15:22 <mps> 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 <mps> we don't need to backport it, noticed that after backported to 3.12 and 3.13
2021-01-19 13:03:03 <ncopa> ikke: i'd like the ParseIndex function take an io.Reader instead of an array of strings
2021-01-19 13:08:56 <ikke> Good idea, I did however wanted to decouple the downloading / extracting the archive from parsing the index
2021-01-19 13:10:39 <ikke> 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 <ncopa> 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 <ncopa> 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 <ikke> 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 <ncopa> exactly
2021-01-19 13:15:38 <ncopa> i'd want an api that does streams
2021-01-19 13:16:01 <ncopa> im not sure how we should output the Packages though
2021-01-19 13:18:30 <ncopa> in my implementation i sent them to a chan
2021-01-19 13:22:23 <ncopa> which means go routines are required
2021-01-19 13:27:29 <mps> go routines are more for parallel 'processes'
2021-01-19 13:30:01 <mps> 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 <mps> this models reminds me of wiring circuits
2021-01-19 14:06:07 <ddevault> https://alpinelinux.org/releases/
2021-01-19 14:06:13 <ddevault> it would be nice if this page linked to the release notes
2021-01-19 14:06:40 <ncopa> i think it does
2021-01-19 14:06:47 <ddevault> also, it seems that the nginx changes were not detailed in the release notes
2021-01-19 14:07:13 <ddevault> oh, the minor release links are links to the release notes
2021-01-19 14:07:16 <ddevault> that was not obvious, thanks
2021-01-19 14:08:07 <ncopa> looks like some links are missing for the minor releases notes
2021-01-19 14:23:37 <MY-R> damn, lot of CVEs in dnsmasq: https://www.thekelleys.org.uk/dnsmasq/CHANGELOG
2021-01-19 14:23:56 <mps> MY-R: yes
2021-01-19 14:24:01 <mps> noticed them
2021-01-19 14:26:19 <jvoisin> dnsmasq is a trashfire :/
2021-01-19 14:26:40 <jvoisin> 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 <Ariadne> nmeum: hopefully my reply explains my motivations :)
2021-01-19 14:28:19 <Ariadne> 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 <mps> do we have tool to automatically add CVEs to APKBUILD
2021-01-19 14:30:24 <nmeum> Ariadne: sure, will read it later. thanks for expanding on your inital mail
2021-01-19 14:33:21 <Ariadne> i wonder if a drop-in replacement for dnsmasq would be helpful
2021-01-19 14:33:43 <jvoisin> yes.
2021-01-19 14:57:02 <ikke> 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 <skarnet> dnsmasq does dns cache + dhcp client, right?
2021-01-19 15:07:11 <jvoisin> yes
2021-01-19 15:07:35 <mps> +tftp
2021-01-19 15:07:38 <MY-R> and that is why many people using it :P and probably all soho routers
2021-01-19 15:08:08 <skarnet> are you saying people *like* software that doesn't really know its purpose?
2021-01-19 15:09:29 <mps> there is #alpine-offtopic channel
2021-01-19 15:10:36 <skarnet> 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 <skarnet> 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 <MY-R> people like it because it automaticly setup up local domain names for clients using dhcp
2021-01-19 15:12:29 <mps> dnsmasq is long time in use and ofc far from perfect but people use it on different purposes
2021-01-19 15:15:35 <mps> 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 <skarnet> 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 <skarnet> 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 <skarnet> so if you want to put a cache on a v6 address, dnscache won't work
2021-01-19 15:21:15 <mps> 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 <Hello71_> dnsmasq doesn't have dhcp client?
2021-01-19 15:21:26 <Hello71_> or tftp client for that matter
2021-01-19 15:21:48 <mps> Hello71_: it have both
2021-01-19 15:21:52 <Hello71_> unless you count dhcp relay which is technically client but not in the conventional sense
2021-01-19 15:22:03 <skarnet> mps: dnscache and tinydns have never failed me in 20+ years of use ^^
2021-01-19 15:22:09 <Hello71_> dnsmasq has dhcp and tftp *server* but last i checked no client
2021-01-19 15:22:17 <mps> Hello71_: sorry, wrong
2021-01-19 15:22:37 <mps> yes, servers not client
2021-01-19 15:22:58 <skarnet> still a kitchen sink :P
2021-01-19 15:23:28 <Hello71_> 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 <mps> yes, right, I played a little with its RA but not much
2021-01-19 16:21:09 <Ariadne> 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 <mps> https://xkcd.com/2347/ :)
2021-01-19 16:22:13 <alpine-meetbot> 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 <Ariadne> imagemagick was solved by graphicsmagick but nobody seems to have noticed
2021-01-19 17:37:16 <minimal> 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 <ikke> minimal: We have confidential issues on gitlab
2021-01-19 17:39:44 <minimal> ikke: How do I create one?
2021-01-19 17:40:00 <ikke> It's an option when you create it
2021-01-19 17:40:24 <ikke> "This issue is confidential.."
2021-01-19 17:40:47 <minimal> doh! had missed that
2021-01-19 17:41:37 <minimal> ok. I'd assumed there would be security team to contact
2021-01-19 17:45:55 <ikke> PureTryOut[m]2 is now a developer, welcome!
2021-01-19 17:49:40 <PureTryOut[m]2> Thank you!
2021-01-19 17:50:36 <insep_> 🎉
2021-01-19 18:26:51 <afontain_> yay
2021-01-19 18:29:41 <mps> heh, now alpine and pmOS are merged :)
2021-01-19 18:30:44 <mps> jk, PureTryOut[m]2 is careful and works fine,
2021-01-19 18:31:46 <mps> PureTryOut[m]2: welcome
2021-01-19 18:33:19 <PureTryOut[m]2> 
ACTION merges the Windows 10 source code to Alpine

2021-01-19 18:33:48 <wsinatra> Microsoft
2021-01-19 18:33:52 <wsinatra> Alpine tm
2021-01-19 18:36:17 <afontain_> kdbus is now part of linux-lts
2021-01-19 18:36:31 <mps> :)
2021-01-19 18:51:25 <fabled> boost1.75-date_time-1.75.0-r3:
2021-01-19 18:51:25 <fabled>     conflicts: boost-date_time-1.72.0-r6[boost-date_time=1.75.0-r3]
2021-01-19 18:51:34 <fabled> i wonder if the provides was not done right
2021-01-19 19:30:42 <Ariadne> PureTryOut[m]2: congratulations on becoming an alpine developer :)
2021-01-19 19:50:44 <Cogitri> Yup, congrats and thanks for the work on KDE :)
2021-01-19 19:51:34 <exception> Congrats
2021-01-19 19:56:29 <jvoisin> congratz
2021-01-19 20:18:43 <PureTryOut[m]2> :D
2021-01-19 20:27:37 <mps> what to do for #12329
2021-01-19 20:28:52 <mps> 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 <mps> and 3.11-stable, ofc
2021-01-19 20:31:22 <ikke> so from 2.80 to 2.83
2021-01-19 20:33:09 <Cogitri> Just upgrade it imho
2021-01-19 20:33:47 <mps> ikke: right
2021-01-19 20:34:26 <mps> Cogitri: and that is what 'hold' me from 'Just upgrade'
2021-01-19 20:35:15 <mps> 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 <ikke> "Remove DSA signature verification from DNSSEC" in 2.81
2021-01-19 20:36:01 <ikke> That seems the only backwards incompattible change
2021-01-19 20:36:17 <mps> yes
2021-01-19 20:37:17 <mps> hmm, I will make MR for 3.11 and assign to maintainer, he should decide what to do
2021-01-19 20:50:20 <ncopa> 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 <ncopa> im searching in my inbox with 50k+ messages, and im not sure what i shoudl search for
2021-01-19 20:51:41 <ncopa> 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 <ikke> ncopa: this one? https://lists.alpinelinux.org/~alpine/devel/%3C86c7a81e-1640-7f82-9e13-dfdbe1aad07b%40gmail.com%3E
2021-01-19 20:58:20 <ncopa> thanks
2021-01-19 20:58:37 <ncopa> managed to set up a filter in claws-mail on list-id and found it
2021-01-19 20:58:38 <mps> ikke: I tested idea of crystal bootstrap from self, i.e. using provides
2021-01-19 20:58:52 <mps> use mutt Luke :)
2021-01-19 21:00:31 <mps> 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 <ikke> hehe :P
2021-01-19 21:15:17 <mps> ikke: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.9 and commit f1cd8c40936ff2b560e1f35159dd6a4602b558e5
2021-01-19 21:15:36 <ncopa> 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 <mps> maybe it is related to problem you had with upgrade
2021-01-19 21:17:09 <ncopa> ugh. my time is up. didnt even have time to read that versioned names proposal :-(
2021-01-19 21:18:37 <ncopa> 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 <maxice8> Then you should stop being afraid because I never even alluded to that in the proposal
2021-01-19 21:22:17 <ikke> mps: talks about discovery controllers
2021-01-19 21:22:26 <ikke> and smart, not sure if it's related
2021-01-19 21:23:16 <ikke> ncopa: I had issues booting alpine 3.13 on a server with lvm volumes
2021-01-19 21:23:42 <mps> nvme-fc: avoid calling _nvme_fc_abort_outstanding_ios from interrupt context
2021-01-19 21:24:08 <mps> not sure, though
2021-01-19 21:28:16 <ikke> too technical to know if it's linked
2021-01-19 21:28:32 <ikke> especially because I have no clue what is causing it in the first place
2021-01-19 21:28:44 <ikke> but switching kernels makes a difference
2021-01-19 21:30:20 <mps> nvm(e) :)
2021-01-19 21:31:08 <ikke> 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 <ollieparanoid[m]> "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 <maxice8> Making food
2021-01-19 22:58:23 <Hello71_> am looking at wiki now, thinking what to do about it
2021-01-19 22:59:55 <Hello71_> 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 <Hello71_> rfc: ^
2021-01-19 23:21:17 <skarnet> gitlab seems to have gone to lunch
2021-01-19 23:21:36 <skarnet> 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 <skarnet> hmmm, weird, looks like it only does it for my fork, not for alpine/aports
2021-01-19 23:27:33 <skarnet> anyway, dnsfunnel is ready for beta testing: !17040
2021-01-19 23:29:47 <mps> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17040/diffs?commit_id=da875e21d18105249c0062b00c393b196dccadec
2021-01-19 23:29:58 <mps> new aport
2021-01-19 23:30:48 <mps> COMMITSTYLE.md
2021-01-19 23:32:38 <mps> not sure about copyright for dnsfunnel.initd
2021-01-19 23:33:23 <skarnet> 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 <mps> other things looks good, except maybe add comment after 'options="!check"', why check is disabled
2021-01-19 23:34:47 <skarnet> ok, will edit
2021-01-19 23:34:47 <mps> as they say, ianal, so don't know really
2021-01-19 23:35:35 <mps> but I usually don't assing copyright to self in scripts
2021-01-19 23:35:46 <mps> or anything in alpine
2021-01-19 23:35:49 <skarnet> uuuuh, there *is* a copyright in dnsfuinnel.initd
2021-01-19 23:35:59 <skarnet> so I don't get your comment
2021-01-19 23:36:11 <skarnet> you mean I should remove it? I originally copied it from another package
2021-01-19 23:36:45 <skarnet> (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 <mps> 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 <skarnet> 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 <mps> :)
2021-01-19 23:41:42 <skarnet> added a comment after !check. It's enlightening.
2021-01-19 23:42:28 <mps> :)
2021-01-19 23:44:40 <mps> I didn't learned (and probably never will) to make comments directly in gitlab MRs
2021-01-19 23:46:00 <skarnet> I just made a new commit locally and pushed it
2021-01-19 23:46:07 <skarnet> okay, so gitlab *does* have a problem
2021-01-19 23:46:25 <skarnet> >>> dnsfunnel: Checking sha512sums...
2021-01-19 23:46:25 <skarnet> dnsfunnel-0.0.1.0.tar.gz: FAILED
2021-01-19 23:46:31 <skarnet> the tarball has not changed
2021-01-19 23:46:37 <skarnet> what is it smoking?
2021-01-19 23:47:14 <skarnet> 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 <skarnet> 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 <andypost> looks s390x builders hangs
2021-01-20 07:39:51 <maxice8> I like this changelog, very short.
2021-01-20 07:39:57 <maxice8> `Many fixes. Can't bother to list them. You can get the list of changes from git.`
2021-01-20 08:31:04 <ikke> More honest way of saying 'bug fixes and performance improvements"
2021-01-20 08:32:34 <maxice8> My favorite
2021-01-20 08:34:11 <mps> this one 'All users of the 5.10 kernel series must upgrade'
2021-01-20 09:52:33 <maxice8> ncopa: ping
2021-01-20 10:02:55 <ncopa> morning
2021-01-20 10:03:13 <ncopa> maxice8: pong
2021-01-20 10:07:02 <maxice8> 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 <ncopa> I think that should work
2021-01-20 10:17:42 <maxice8> Is there a way to test it
2021-01-20 10:17:52 <maxice8> !17094 ?
2021-01-20 11:13:40 <mps> hehe, https://lwn.net/Articles/843169/
2021-01-20 11:13:52 <mps> not totally OT
2021-01-20 11:15:05 <mps> I like this "Aaaaaah! The sky is falling, upgrade NOW!"
2021-01-20 11:22:14 <ikke> Some embargoed CVE?
2021-01-20 11:24:55 <maxice8> Seems like libgit2-static is just broken
2021-01-20 11:25:08 <maxice8> maybe -static is fine :D
2021-01-20 11:25:38 <maxice8> using -DUSE_HTTP_PARSER=system seems to prevent http_parser symbols from being included in the static archive
2021-01-20 11:47:51 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12335
2021-01-20 11:47:59 <maxice8> can someone decipher what is happening here ^
2021-01-20 11:52:04 <Cogitri> 🤔
2021-01-20 11:52:58 <ikke> We have p11-kit 0.33.22, and it needs to be upgraded to 0.33.22?
2021-01-20 11:53:38 <maxice8> 23.22 but yes
2021-01-20 11:53:54 <maxice8> 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 <maxice8> 0.23.22 is the latest upstream release
2021-01-20 12:30:38 <lmarz> 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 <lmarz> https://gitlab.alpinelinux.org/lmarz/aports/-/jobs/298457
2021-01-20 12:32:37 <ikke> Hello71_: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12311
2021-01-20 12:35:07 <Hello71_> ikke: I highly doubt this issue is seccomp related
2021-01-20 12:35:16 <ikke> Yes, me too
2021-01-20 12:36:06 <Hello71_> 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 <ikke> This error happens before user code is executed
2021-01-20 12:37:00 <Hello71_> also the error is invalid argument, not permission denied
2021-01-20 12:37:23 <ikke> Ie, gitlab runner is trying to invoke a shell I guess
2021-01-20 12:37:44 <ikke> Hello71_: I ran into this in november (and even before that)
2021-01-20 12:37:50 <ikke> with alpine:edge at that time
2021-01-20 12:38:09 <Hello71_> ikke: see lmarz, I thought you upgraded x86_64?
2021-01-20 12:38:10 <ikke> even 'echo hello world' would give the same error
2021-01-20 12:38:29 <ikke> Hello71_: to 3.12, so it does not have libseccomp 2.4.4 yet
2021-01-20 12:38:55 <Hello71_> wait then what were you upgrading it for
2021-01-20 12:39:13 <ikke> I wanted to upgrade it to 3.13
2021-01-20 12:39:29 <ikke> but ran into some issues related to the kernel
2021-01-20 12:39:39 <ikke> (which took all weekend to find out)
2021-01-20 12:39:51 <ikke> x86 is 3.13 already
2021-01-20 12:40:30 <Hello71_> ah
2021-01-20 15:25:07 <ikke> Hello71_: Note that we have the same issue at $work on specific runners
2021-01-20 15:25:22 <ikke> but on a runner I control with docker 19.03 and libseccomp 2.4.3, it works
2021-01-20 15:26:10 <Hello71_> 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 <ikke> I was trying to look in the gitlab-runner code
2021-01-20 15:27:10 <Hello71_> in particular it's interesting that the error is "Invalid argument". this excludes for example "Bad file descriptor"
2021-01-20 15:28:15 <Hello71_> ah, the github issue is more helpful
2021-01-20 15:32:53 <Hello71_> hm.... maybe TIOCGWINSZ is failing?
2021-01-20 15:35:32 <Hello71_> 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 <Hello71_> you can probably go from the end and see which one succeeds first
2021-01-20 15:37:01 <Hello71_> not sure why that would be different between 3.13 and edge though, hm
2021-01-20 15:37:23 <Hello71_> ah, they say it doesn't work on 3.13
2021-01-20 15:38:53 <ikke> I already had the same issue before 3.13 was released on edge
2021-01-20 15:39:04 <ikke> I don't think it executes anything you provide yet
2021-01-20 15:39:09 <ikke> It seems to fail before that
2021-01-20 15:39:35 <ikke> Hello71_: I have 'echo hello world' it failed before even executing that
2021-01-20 15:40:04 <Hello71_> aha, i think it is failing to write to /dev/tty
2021-01-20 15:40:18 <Hello71_> which unfortunately makes it a little hard to diagnose
2021-01-20 15:40:33 <Hello71_> what happens if you just put true
2021-01-20 15:40:51 <ikke> Hello71_: let me try
2021-01-20 15:41:25 <ikke> Hello71_: I can also try to provide an entry point text
2021-01-20 15:41:33 <ikke> instead of using script:
2021-01-20 15:42:39 <Hello71_> first check script: true. if that fails then it's almost certainly failing to write to /dev/tty
2021-01-20 15:43:29 <ikke> But why would the alpine version matter?
2021-01-20 15:43:36 <ikke> it works for 3.12
2021-01-20 15:43:56 <Hello71_> well that's the next question :)
2021-01-20 15:45:11 <ikke> Fails as well
2021-01-20 15:46:14 <Hello71_> try image:entrypoint: /bin/true then
2021-01-20 15:49:14 <Hello71_> also what arch and docker version are you using
2021-01-20 15:50:37 <ikke> x86_64
2021-01-20 15:51:22 <ikke> I don't know the docker version, have  to ask
2021-01-20 15:52:19 <ikke> That entrypoint works
2021-01-20 15:54:38 <ikke> Setting the entrypoint to /bin/sh -c fails with the same error
2021-01-20 15:57:45 <Hello71_> try /usr/bin/strace /bin/sh -c true
2021-01-20 15:58:17 <ikke> The image has no strace
2021-01-20 15:59:29 <ikke> I can do /bin/sh -c 'apk add strace', and even get output
2021-01-20 16:00:39 <Hello71_> what do you mean by
2021-01-20 16:00:41 <Hello71_> 15:54 <@ikke> Setting the entrypoint to /bin/sh -c fails with the same error
2021-01-20 16:03:25 <ikke> entrypoint: [/bin/sh, -c]
2021-01-20 16:04:15 <ikke> (I have to provide a script section as well, with an empty string as first element
2021-01-20 16:04:54 <Hello71_> hm... maybe docker is upset about {iov_base=NULL, iov_len=0}
2021-01-20 16:08:14 <Hello71_> but that didn't change in musl 1.2
2021-01-20 16:08:54 <Hello71_> dunno, i don't have enough information to diagnose the issue. it could be kernel version related too
2021-01-20 16:18:48 <ikke> I haven't seen it yet on any of the alpine systems
2021-01-20 16:18:53 <ikke> alpine CI
2021-01-20 16:19:23 <ikke> 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 <Hello71_> probably
2021-01-20 16:19:49 <Hello71_> if you can find out how to actually invoke it
2021-01-20 16:20:36 <ikke> yea
2021-01-20 16:20:49 <ikke> maybe an entrypoint
2021-01-20 16:22:57 <ikke> Hello71_: thanks for your helpt btw
2021-01-20 16:24:40 <Hello71_> 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 <maxice8> 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 <Ariadne> maxice8: now is a good time
2021-01-21 01:28:50 <maxice8> I'm not ready
2021-01-21 01:30:16 <Ariadne> lets aim for friday evening
2021-01-21 01:30:29 <Ariadne> or do you need more time/
2021-01-21 01:30:53 <maxice8> Can be
2021-01-21 04:33:34 <maxice8> Ariadne: can you ok !17127 ?
2021-01-21 04:41:26 <maxice8> ty
2021-01-21 04:41:52 <Ariadne> though we should move these tools out of aports
2021-01-21 04:41:53 <Ariadne> imo
2021-01-21 04:42:04 <maxice8> oh derp, we forgot the checksum
2021-01-21 04:42:21 <Ariadne> feel free to fix it
2021-01-21 04:42:35 <Ariadne> I'm not at my computer right now
2021-01-21 04:42:35 <maxice8> phew
2021-01-21 04:42:42 <maxice8> I was worried there was a sniper dot pointing at me
2021-01-21 04:43:43 <maxice8> fixed
2021-01-21 05:44:18 <maxice8> What is the version I put stuff we are not affected by
2021-01-21 05:44:56 <ikke> maxice8: ?
2021-01-21 05:45:08 <maxice8> 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 <maxice8> https://doc.powerdns.com/authoritative/security-advisories/powerdns-advisory-2020-06.html
2021-01-21 05:46:57 <ikke> version 0? :P
2021-01-21 05:47:12 <maxice8> ncopa recommended as far as I remember
2021-01-21 06:28:20 <ikke> maxice8: https://gitlab.alpinelinux.org/alpine/aports/-/pipelines/68810
2021-01-21 06:29:00 <maxice8> Yes?
2021-01-21 06:29:09 <ikke> notice something?
2021-01-21 06:30:50 <maxice8> It's all green which is suspect consdering how the CI currently is
2021-01-21 06:31:38 <ikke> maxice8: then inspect further
2021-01-21 06:34:01 <maxice8> ?
2021-01-21 06:39:55 <ikke> You said it was suspect
2021-01-21 06:40:19 <maxice8> yes
2021-01-21 06:40:27 <ikke> if you look at the jobs, does it look bogus?
2021-01-21 06:40:43 <maxice8> no
2021-01-21 06:40:47 <ikke> so..
2021-01-21 06:42:02 <maxice8> so nothing
2021-01-21 06:42:04 <maxice8> ¯\_(ツ)_/¯
2021-01-21 06:42:34 <ikke> sad trombone
2021-01-21 06:43:05 <ikke> I've changed the seccomp profile on the runners so they no longer block faccessat2
2021-01-21 06:43:28 <maxice8> oh
2021-01-21 06:43:42 <maxice8> that's good
2021-01-21 06:43:47 <ikke> yes :)
2021-01-21 06:56:33 <ikke> wondering whats up with dnsfunnel
2021-01-21 06:56:46 <ikke> I'll look at it later
2021-01-21 08:16:44 <ikke> Hello71: https://tpaste.us/OQOb strace output where the write error occurs
2021-01-21 09:57:34 <PureTryOut[m]2> fcolista: you upgraded re2 a few hours ago, but note that several packages need rebuilds because of that
2021-01-21 09:58:02 <PureTryOut[m]2> See https://git.alpinelinux.org/aports/commit?id=f444918c4e22dbe1224e0c3aa779f6093c2b717f
2021-01-21 11:12:45 <Hello71> ikke: yes, i replied in #musl
2021-01-21 11:12:47 <Hello71> thanks
2021-01-21 11:51:35 <PureTryOut[m]2> I just did my first merge! Not sure if I like the anxiousness that came from it lol
2021-01-21 11:51:58 <ikke> PureTryOut[m]2: heh :P
2021-01-21 11:52:16 <ikke> PureTryOut[m]2: congrats
2021-01-21 11:52:28 <PureTryOut[m]2> CI was green but still I'm thinking, "but what if it breaks on the builders?!"
2021-01-21 11:52:30 <mps> PureTryOut[m]2: after more than 2 years I still feel it :)
2021-01-21 11:52:37 <PureTryOut[m]2> Haha good to know
2021-01-21 11:53:02 <ikke> A health dose of cautiousness is never a bad thing
2021-01-21 11:54:25 <PureTryOut[m]2> Definitely
2021-01-21 11:55:16 <Cogitri> 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 <PureTryOut[m]2> 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 <ikke> I could just disable it :P
2021-01-21 11:57:03 <PureTryOut[m]2> 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 <ikke> https://ibb.co/BG7zGY5
2021-01-21 11:57:50 <PureTryOut[m]2> Personally I'd be in favor of disabling that option altogether yes
2021-01-21 11:57:55 <ikke> PureTryOut[m]2: maybe for piece of mind :)
2021-01-21 11:57:58 <PureTryOut[m]2> But others might disagree
2021-01-21 11:58:01 <Cogitri> 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 <PureTryOut[m]2> Cogitri: luckily we can squash locally
2021-01-21 11:58:27 <PureTryOut[m]2> 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 <Cogitri> Yeah, but that take more time
2021-01-21 11:58:42 <ikke> which apparently is not a bad thing :P
2021-01-21 11:58:48 <PureTryOut[m]2> Yeah
2021-01-21 11:59:05 <ikke> You can inspect the results before pushing it
2021-01-21 11:59:21 <PureTryOut[m]2> Exactly
2021-01-21 11:59:43 <maxice8> PureTryOut: builder-breaking worry never goes away
2021-01-21 12:04:05 <maxice8> it does transform though
2021-01-21 12:07:21 <mps> ikke: this is good idea, do it :) (please)
2021-01-21 12:07:55 <ikke> I'll do it with enough consensus
2021-01-21 12:08:14 <maxice8> do it
2021-01-21 12:08:44 <mps> what!? my vote is not enough to prevail all :D
2021-01-21 12:09:14 <maxice8> never was
2021-01-21 12:09:22 <PureTryOut[m]2> That's at least 3 votes in favor already
2021-01-21 12:10:51 <PureTryOut[m]2> 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 <ikke> We do not prohibit it
2021-01-21 12:12:01 <mps> (some people lost sense of humor)
2021-01-21 12:12:23 <maxice8> PureTryOut: no promises of support for that but feel free to fix it if you wish
2021-01-21 12:12:27 <ikke> PureTryOut[m]2: it's basically a best effort from that point
2021-01-21 12:13:42 <PureTryOut[m]2> Well I have no desire to fix it tbh. Only if we still actively support the branch
2021-01-21 12:13:57 <Cogitri> Can be closed then
2021-01-21 12:14:16 <PureTryOut[m]2> Good
2021-01-21 12:47:07 <TBK[m]> ikke: do you know the kernel version of the mips64 builder?
2021-01-21 12:47:50 <ikke> It's some bsp mernel
2021-01-21 12:47:54 <ikke> Kernel
2021-01-21 12:48:17 <ikke> I can verify later which
2021-01-21 12:49:22 <TBK[m]> I am asking because of -https://gitlab.alpinelinux.org/alpine/aports/-/issues/12327#note_137460
2021-01-21 12:54:48 <ikke> Not something trivially to change
2021-01-21 12:56:07 <TBK[m]> yeah...
2021-01-21 12:58:00 <TBK[m]> 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 <TBK[m]> *kernel patches
2021-01-21 13:10:02 <fcolista> @PureTryOut[m]2, I know and I've done a bump pkgrel for the related packages
2021-01-21 13:11:08 <fcolista> see commit: 165eace3025c63e9ca6e7469200fab119ed3aff1 and 3d22763916798cebc43eb84cc9bb2bdc9baa7b5c
2021-01-21 13:11:21 <PureTryOut[m]2> Oh huh, I missed those
2021-01-21 13:11:26 <PureTryOut[m]2> In that case, ignore me 😉
2021-01-21 13:11:31 <fcolista> the only one I couldn't bump the pkgre was for qt5-qtwebengine
2021-01-21 13:11:49 <fcolista> https://www.qt.io/blog/problem-with-open-source-downloads
2021-01-21 13:12:04 <fcolista> https://twitter.com/qtproject/status/1351838327520026625
2021-01-21 13:12:37 <fcolista> download.qt.io is down
2021-01-21 13:16:13 <PureTryOut[m]2> Oh ouch
2021-01-21 13:16:21 <PureTryOut[m]2> And exactly qt5-qtwebengine is the one of my MR's needs...
2021-01-21 13:19:13 <fcolista> yes...untli the download.qt.io is not up, we cannot bump the pkglre...
2021-01-21 13:19:20 <PureTryOut[m]2> Yeah
2021-01-21 13:19:21 <PureTryOut[m]2> Darn it
2021-01-21 13:19:49 <Hello71> if you still have copy then could put it on alpinelinux site
2021-01-21 13:20:27 <ikke> distfiles.a.o probably has it
2021-01-21 13:20:29 <fcolista> nope...I don't think is a good idea
2021-01-21 13:20:55 <ikke> So on the builders it would just work
2021-01-21 13:21:50 <fcolista> 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 <ikke> The builders transparently download it from distfiles
2021-01-21 13:25:03 <fcolista> done
2021-01-21 13:26:31 <PureTryOut[m]2> I was just about to ask why it got committed anyway haha. Good job
2021-01-21 13:27:57 <fcolista> vecause ikke's comment
2021-01-21 13:27:58 <fcolista> *because
2021-01-21 13:28:28 <PureTryOut[m]2> Yeah I know, I read the backlog before I was about to ask 😉
2021-01-21 13:28:40 <fcolista> that's a good habit ;-)
2021-01-21 13:51:46 <Hello71> ikke, ncopa: regarding busybox regression, should we backport busybox or musl patch, or both?
2021-01-21 13:52:33 <Hello71> 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 <ncopa> 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 <ncopa> i can do that, (once this meeting im in is over)
2021-01-21 14:03:47 <Hello71> 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 <ikke> I can test it on edge
2021-01-21 14:15:22 <mps> musl should be fixed, and bb fix probably will not hurt
2021-01-21 14:20:58 <Hello71> 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 <ncopa> i pushed it to alpine edge
2021-01-21 14:23:44 <Hello71> ok :)
2021-01-21 14:23:45 <Hello71> which one
2021-01-21 14:24:06 <Hello71> ah, only busybox patch
2021-01-21 14:24:30 <Hello71> 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 <Hello71> but that one can wait until dalias reviews
2021-01-21 14:37:17 <sh4rm4^bnc> 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 <mps> sh4rm4^bnc: some of specific gpu?
2021-01-21 14:40:32 <sh4rm4^bnc> it's an intel 965 iirc, but it dont see anything in dmesg that would confirm that
2021-01-21 14:40:49 <sh4rm4^bnc> ah, [    3.036420] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
2021-01-21 14:41:44 <sh4rm4^bnc> this also happened on my 10 year old laptop with another older intel chip, but much less frequently
2021-01-21 14:42:14 <mps>  3.181556] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
2021-01-21 14:42:45 <mps> old macbook pro, FF works without problem
2021-01-21 14:43:14 <sh4rm4^bnc> 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 <sh4rm4^bnc> mps: i suspect alpine had this fixed somehow years ago
2021-01-21 14:44:13 <mps> sh4rm4^bnc: ah, you are on something other than alpine?
2021-01-21 14:44:24 <sh4rm4^bnc> yeah, sabotage (my own distro)
2021-01-21 14:44:45 <mps> ah, yes I remember (you told me earlier)
2021-01-21 14:44:54 <sh4rm4^bnc> so it's one developer vs dozens behind alpine :)
2021-01-21 14:45:11 <mps> you are calling me to join :)
2021-01-21 14:45:17 <sh4rm4^bnc> :)))
2021-01-21 14:45:47 <mps> I looked at it to some degree but didn't tried to boot
2021-01-21 14:48:30 <mps> sh4rm4^bnc: btw, my wife also run alpine on one old intel notebook and it works fine
2021-01-21 14:48:49 <mps> s/run/use/
2021-01-21 14:48:49 <alpine-meetbot> 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 <sh4rm4^bnc> most people discard sabotage when they realize that some components aren't bleeding edge...
2021-01-21 14:49:21 <sh4rm4^bnc> i personally value stability way more
2021-01-21 14:49:44 <mps> I don't run bleeding edge on production systems
2021-01-21 14:49:56 <mps> also I
2021-01-21 14:50:36 <sh4rm4^bnc> 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 <mps> if I want 'featurist' OS I would use ubuntu or similar
2021-01-21 14:51:31 <mps> heh, because that we have stable releases
2021-01-21 14:53:20 <sh4rm4^bnc> 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 <mps> yes, NG people
2021-01-21 14:54:05 <mps> (Not Good, ofc :) )
2021-01-21 14:54:09 <sh4rm4^bnc> :)
2021-01-21 14:54:59 <mps> I use 'slim' DM which is also from 2012 or 2014
2021-01-21 14:56:01 <mps> removed udev and dbus, also
2021-01-21 14:56:06 <sh4rm4^bnc> after sabotage booted up and the default LXDE desktop is loaded, it uses a total 12MB of RAM
2021-01-21 14:56:41 <mps> till you run firefox :)
2021-01-21 14:56:49 <sh4rm4^bnc> i don't think you could get it much slimmer than that without heavily compromising user XP
2021-01-21 14:57:02 <sh4rm4^bnc> heh yeah
2021-01-21 14:57:43 <sh4rm4^bnc> 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 <mps> 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 <sh4rm4^bnc> maybe :>
2021-01-21 14:59:14 <mps> I thought to package palemon for alpine but license stopped me
2021-01-21 15:01:05 <maxice8> And palemoon last I checked wasn't interested in musl compat
2021-01-21 15:01:59 <sh4rm4^bnc> 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 <mps> maxice8: also this
2021-01-21 15:06:24 <sh4rm4^bnc> 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 <yZ5vlALg86lP> does palemoon backpoort security fixes from firefox?
2021-01-21 15:18:17 <Hello71> pretty sure it's diverged too much
2021-01-21 15:18:39 <Hello71> if it were easy then mozilla would do it themselves
2021-01-21 15:25:28 <yZ5vlALg86lP> > 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 <Hello71> are there firefox security fixes for 52.9-esr
2021-01-21 15:26:29 <ddevault> postfix appears to be newer in 3.12 than in 3.13, cc ncopa
2021-01-21 15:27:37 <sh4rm4^bnc> <yZ5vlALg86lP> does palemoon backpoort security fixes from firefox?
2021-01-21 15:27:56 <sh4rm4^bnc> yeah, those that apply to their codebase. they also have a "defense in depth" idiom
2021-01-21 15:29:22 <mps> hmm, didn't I backported postfix, lets see
2021-01-21 15:30:32 <mps> huh, I forgot
2021-01-21 15:33:34 <yZ5vlALg86lP> how does that > "defense in depth" idiom materialize?
2021-01-21 15:39:58 <adhawkins> 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 <maxice8> Installing packages from pypi on the package ?
2021-01-21 15:41:20 <adhawkins> 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 <adhawkins> emborg is already on PyPi, so I wondered if that might make building a package for alpine easier?
2021-01-21 15:42:12 <maxice8> 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 <maxice8> Ariadne: ping, tomorrow night is the py3.9 transition ?
2021-01-21 15:42:49 <adhawkins> Oh ok. I'll have a play then and see how far I get.
2021-01-21 15:44:40 <adhawkins> Is that the best document to work from, or is there a more comprehensive 'newbie' tutorial?