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?
2021-01-21 16:05:52 <ikke> ncopa: bb started to give Stat usage output on upgrade btw
2021-01-21 16:08:22 <ikke> ncopa: seems it works
2021-01-21 16:08:41 <ikke> When I upgrade bb in the entrypoint, it goes through
2021-01-21 16:23:38 <ncopa> ddevault: looks like postfix-3.5.9 was pushed to 3.13-stable
2021-01-21 16:23:48 <ddevault> thanks
2021-01-21 16:28:26 <dalias> hello71, the musl patch introduces crash into valid programs on oom
2021-01-21 16:28:33 <dalias> so don't include it
2021-01-21 16:28:37 <Hello71> ugh
2021-01-21 16:28:47 <Hello71> what else do you do in that case
2021-01-21 16:28:55 <Hello71> free it later?
2021-01-21 16:29:18 <dalias> we could arrange to try freeing it later but that's nontrivial
2021-01-21 16:31:03 <dalias> we could re-queue it to a free group list to just keep using it (but it might not be suitably sized), or we could linear search all existant groups to see if it's immediately following one, and if so, increase that one's map length to encompass it so it gets freed when that one does
2021-01-21 16:31:33 <dalias> but a program in this state is likely on the verge of critical OOM'ing anyway and not going to make much forward progress
2021-01-21 16:32:12 <dalias> you just want to ensure it doesn't crash so it can handle that and exit safely without loss of data/unrestored state
2021-01-21 16:32:52 <dalias> i don't think it's worth putting a lot of effort, code size, and bug surface into accounting for and freeing the memory that failed to unmap
2021-01-21 16:34:14 <dalias> anyway i would do just the busybox patch for now
2021-01-21 16:34:43 <dalias> this is a busybox bug -- there is no current standard that requires free to preserve errno, and the "if (errno)" idiom is almost universally wrong anyway
2021-01-21 16:35:05 <dalias> this is classic busybox "let's save 10 bytes of .text by doing something wrong"
2021-01-21 16:35:43 <dalias> and the only possible motivation for "if (errno)" rather than "if (r<expected)" is saving bytes
2021-01-21 16:36:21 <ncopa> i already pushed a patch to alpine edge, sent a fix upstream (which also saves 8 bytes), and will back port it once its tested
2021-01-21 16:36:34 <ncopa> busybox patch http://lists.busybox.net/pipermail/busybox/2021-January/088491.html
2021-01-21 16:36:53 <dalias> :)
2021-01-21 16:36:55 <ikke> ncopa: I tested it
2021-01-21 16:36:58 <dalias> yay
2021-01-21 16:37:07 <dalias> saving 8 bytes will at least ensure they accept it :-P
2021-01-21 16:37:10 <ikke> :D
2021-01-21 16:37:31 <ncopa> that was the reason, to improve changes that they will accept it :)
2021-01-21 16:38:06 <dalias> chances*
2021-01-21 16:38:22 <ncopa> s/changes/chances/
2021-01-21 16:38:22 <alpine-meetbot> ncopa meant to say: that was the reason, to improve chances that they will accept it :)
2021-01-21 16:39:04 <dalias> heh i want a bot that understands the replacement* notation
2021-01-21 16:39:55 <ikke> The format is underspecced, though :P
2021-01-21 16:40:29 <dalias> (look for lowest-levenshtein-distance match, resolve ambiguities with some sort of markov chain model for which instance is likely wrong :)
2021-01-21 16:40:53 <dalias> partly because it would be hilarious when it makes the wrong replacement and we'd get to laugh at "lol look how idiotic ai is" :-p
2021-01-21 16:41:44 <ncopa> ai... lol
2021-01-21 16:42:05 <ikke> ncopa: docker run -it --rm alpine:edge apk add -u busybox
2021-01-21 16:43:07 <dalias> of course it's not really "ai", just an optimization problem with basic text algorithms and markov chains
2021-01-21 16:43:18 <ikke> What's the difference? :P
2021-01-21 16:43:23 <dalias> exactly :)
2021-01-21 16:44:15 <dalias> but i mean there's no tensorflow or GPUs or ... :-P :-P :-P
2021-01-21 16:47:04 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12311#note_137667
2021-01-21 16:47:17 <ikke> Is it correct what I've written there?
2021-01-21 16:48:52 <ncopa> looks correct, yes. thanks!
2021-01-21 16:49:29 <dalias> yes
2021-01-21 16:50:40 <ncopa> dalias can you please alos give a quick look at http://lists.busybox.net/pipermail/busybox/2021-January/088491.html i think its correct but...
2021-01-21 16:51:52 <dalias> LGTM
2021-01-21 16:52:00 <ncopa> 👍
2021-01-21 16:52:05 <ncopa> thanks
2021-01-21 16:52:13 <dalias> and yay i'm still subscribed to busybox list. hadn't opened the folder in a couple years i think :-p
2021-01-21 16:53:56 <ncopa> i think we should do 3.13.1 early next week
2021-01-21 16:54:30 <ncopa> the apk-tools fix, busybox fix and greg's "all users must upgrade"
2021-01-21 16:54:32 <ikke> I wonder what we should do with the docker faccessat2 issues
2021-01-21 16:54:49 <ikke> I have solved it now for our CI,but lots of users run into issues as well
2021-01-21 16:54:58 <ncopa> looks like glibc has same problem nowdays
2021-01-21 16:55:30 <ncopa> i havent digged into the dirty details yet, but from reading the comments, it looks complicated to solve it
2021-01-21 16:55:30 <ikke> runc is fixing it, but takes time before everyone has that version
2021-01-21 16:55:45 <ikke> https://github.com/opencontainers/runc/pull/2737
2021-01-21 16:56:34 <ikke> Hello71: Do you know what the consequences are from switch the default seccomp action from SCMP_ACCT_ERRNO to SCMP_ACCT_TRACE?
2021-01-21 16:57:32 <dalias> well it makes the seccomp not a security boundary
2021-01-21 16:57:45 <dalias> so if it's blocking things that would compromise the host, now they're no longer blocked
2021-01-21 16:57:48 <adhawkins> Hi. Getting this when trying to run apkbuild-pypi: https://termbin.com/wv9f
2021-01-21 16:57:59 <ikke> dalias: right, I figured as mutch
2021-01-21 16:58:08 <ikke> s/mutch/much/
2021-01-21 16:58:08 <alpine-meetbot> ikke meant to say: dalias: right, I figured as much
2021-01-21 16:58:55 <dalias> can you add a second seccomp filter inside the container to block new syscalls right?
2021-01-21 16:59:56 <adhawkins> Is this an appropriate place to ask newbie packaging questions by the way? Happy to be pointed to somewhere more appropriate.
2021-01-21 17:00:05 <ikke> adhawkins: yes, certainly
2021-01-21 17:00:18 <maxice8> Don't need to ask to ask if you ask in the wrong place we will just redirected to the correct place
2021-01-21 17:00:23 <ncopa> adhawkins: hi welcome!
2021-01-21 17:01:13 <ikke> dalias: I guess, no clue
2021-01-21 17:02:56 <dalias> i'm not sure how nesting seccomp works
2021-01-21 17:04:15 <ikke> The problem is that even though with an updated seccomp profile with faccessat2, it's still blocked due to an outdated libseccomp
2021-01-21 17:04:56 <ikke> It apparently needs to know about new syscalls as well
2021-01-21 17:07:45 <ikke> timlegge: do you know what that error means? ^^
2021-01-21 17:09:18 <Ariadne> maxice8: yes, lets do it tomorrow night
2021-01-21 17:09:55 <dalias> right, i'm wondering if there's something you can do inside the container since the container runtime is broken
2021-01-21 17:10:15 <Ariadne> anyway
2021-01-21 17:10:35 <Ariadne> i'm kind of surprised that the seccomp filters still haven't been updated
2021-01-21 17:10:43 <Ariadne> i held faccessat2 back 4 months ago
2021-01-21 17:10:43 <ikke> Ariadne: that's not the issue
2021-01-21 17:10:49 <ikke> they _have_ been updated
2021-01-21 17:10:52 <ikke> but it's not enough
2021-01-21 17:10:57 <adhawkins> In that case, can anyone help with why apkbuild-pypi is generating these errors? https://termbin.com/wv9f
2021-01-21 17:10:58 <Ariadne> hmmph
2021-01-21 17:11:20 <ikke> adhawkins: timlegge does a lot with perl, so maybe he can help
2021-01-21 17:11:32 <Ariadne> pypi is not cpan :P
2021-01-21 17:11:41 <ikke> Ariadne: no, but that script is written in perl
2021-01-21 17:11:58 <adhawkins> Ah, didn't realise that. Presumably some missing perl dependency then?
2021-01-21 17:12:13 <ikke> Ariadne: apparently you need at least libseccomp 2.4.4 for faccessat2
2021-01-21 17:12:18 <Ariadne> yes, missing IPC::System::Simple
2021-01-21 17:12:32 <maxice8> Unfortunately apkbuild-pypi is not maintained like apkbuild-cpan
2021-01-21 17:12:43 <Ariadne> ikke: i am really starting to become skeptical about seccomp ;/
2021-01-21 17:12:50 <adhawkins> Ah ok. Not sure it would actually give me very much anyway.
2021-01-21 17:12:53 <skarnet> only starting?
2021-01-21 17:12:58 <skarnet> what held you back?
2021-01-21 17:13:07 <Ariadne> ok, i've been skeptical all along :P
2021-01-21 17:13:12 <adhawkins> Is there an easy way to ensure that nobody has packaged up the following pypi modules? arrow inform quantiphy shlib
2021-01-21 17:13:12 <Ariadne> but now i'm really skeptical
2021-01-21 17:13:13 <mps> any opinion about this !17032 objections or ....?
2021-01-21 17:13:31 <adhawkins> apk show py3-$(module) doesn't show anything for them, but want to be sure the name hasn't been changed slightly.
2021-01-21 17:13:53 <Ariadne> in theory, seccomp sounds nice, but in practice, it seems very fragile
2021-01-21 17:13:54 <adhawkins> Sorry, that should have been apk info py3-$(module)
2021-01-21 17:14:09 <Ariadne> and, there is the possibility that you can defeat it by owning the BPF VM
2021-01-21 17:14:10 <mps> ikke: what is the question about this script
2021-01-21 17:14:23 <ikke> mps: adhawkins ran into an error
2021-01-21 17:14:30 <mps> ah
2021-01-21 17:14:34 <ikke> https://termbin.com/wv9f
2021-01-21 17:14:40 <skarnet> Ariadne: dnsfunnel has been merged (thanks Leo), in testing/ atm, for betatesting, if you know caches/servers with answers that need truncation or with wrong nxdomains
2021-01-21 17:14:48 <skarnet> I've tested the normal case reasonably well
2021-01-21 17:14:55 <ikke> Was the CI issue with dnsfunnel fixed?
2021-01-21 17:15:03 <skarnet> yes
2021-01-21 17:15:07 <ikke> ah, what was it?
2021-01-21 17:15:17 <mps> Ariadne: already answered :) I think
2021-01-21 17:15:25 <skarnet> ikke: which one? there were several XD
2021-01-21 17:15:41 <ikke> skarnet: I recall you mentioning 2 issues
2021-01-21 17:15:54 <ikke> checksum mismatch
2021-01-21 17:15:58 <ikke> and outdated dependencies
2021-01-21 17:16:00 <mps> adhawkins: how you invoke this command
2021-01-21 17:16:01 <skarnet> ikke: are you Leo?
2021-01-21 17:16:03 <ikke> skarnet: no
2021-01-21 17:16:09 <ikke> maxice8 here is Leo
2021-01-21 17:16:12 <skarnet> ooooh
2021-01-21 17:16:12 <maxice8> I am
2021-01-21 17:16:24 <adhawkins> mps: The command line is shown in the pastebin.
2021-01-21 17:16:31 <skarnet> maxice8: thanks for the push, you woke up earlier than me
2021-01-21 17:16:34 <adhawkins> Whoops, sorry, no it's not.
2021-01-21 17:16:41 <skarnet> well maxice8 fixed them, not sure how
2021-01-21 17:16:41 <mps> :)
2021-01-21 17:16:42 <Ariadne> i think for example, seccomp should allow syscalls by default
2021-01-21 17:16:48 <adhawkins> mps: apkbuild-pypi create emborg
2021-01-21 17:16:53 <Ariadne> and you just specify the ones that are evil
2021-01-21 17:16:58 <adhawkins> But if I just run 'apkbuild-pypi' I get the same error
2021-01-21 17:17:02 <Ariadne> but that's not how they do it
2021-01-21 17:17:04 <Ariadne> soooooo
2021-01-21 17:17:22 <ikke> general wisdom of allowing is better then denying
2021-01-21 17:17:28 <skarnet> I suppose the build issue was fixed by pushing the s6-dns upgrade first, updating the gitlab builder, and *then* pushing dnsfunnel
2021-01-21 17:17:49 <ikke> it should work in a single CI build
2021-01-21 17:17:57 <dalias> thanks for reminding me of need to update dnsmasq
2021-01-21 17:17:58 <dalias> :)
2021-01-21 17:18:04 <ikke> unless you try to depend on something in testing from community
2021-01-21 17:18:07 <Ariadne> update it to something thatis not dnsmasq
2021-01-21 17:18:20 <dalias> at least it runs in unprivileged sandbox but it's still a pretty bad issue
2021-01-21 17:18:21 <jvoisin> like systemd-resolvd
2021-01-21 17:18:23 <Ariadne> maybe i should write a shit simple dhcp server
2021-01-21 17:18:27 <skarnet> ikke: well it didn't work for me, not sure what happened, but my interactions with gitlab are never smooth
2021-01-21 17:18:32 <dalias> lol
2021-01-21 17:18:39 <dalias> who needs it for dhcp?? udhcpd does fine
2021-01-21 17:18:45 <dalias> it's dns it's needed for
2021-01-21 17:18:48 <skarnet> needs v6 I suppose
2021-01-21 17:18:51 <Ariadne> i assume that is what most people use dnsmasq for
2021-01-21 17:18:53 <dalias> and there are no non-awful alternatives
2021-01-21 17:18:54 <maxice8> skarnet: welcome
2021-01-21 17:18:58 <Ariadne> sure there is
2021-01-21 17:19:01 <Ariadne> there's unbound
2021-01-21 17:19:01 <dalias> skarnet, radvd is all you need for ipv6
2021-01-21 17:19:17 <Ariadne> unbound is a decent alternative
2021-01-21 17:19:17 <dalias> unbound is huge and has full recursive support
2021-01-21 17:19:18 <skarnet> unbound is not-awful but is also not-good
2021-01-21 17:19:28 <dalias> i just want a dnssec validating proxy
2021-01-21 17:19:28 <mps> adhawkins: for now 'sudo apk add perl-ipc-system-simple'
2021-01-21 17:19:29 <Ariadne> there's also skarnet's dnsfunnel
2021-01-21 17:19:41 <dalias> dnsfunnel is not validating afaik
2021-01-21 17:19:49 <skarnet> in beta, doesn't cache, doesn't validate, just forwards
2021-01-21 17:19:53 <dalias> (and not intended to be)
2021-01-21 17:19:57 <mps> adhawkins: and python3
2021-01-21 17:20:03 <Ariadne> ok
2021-01-21 17:20:06 <Ariadne> systemd-resolved it is
2021-01-21 17:20:10 <dalias> lol
2021-01-21 17:20:12 <Ariadne> 
ACTION switches alpine to systemd

2021-01-21 17:20:23 <Ariadne> don't worry i am just kidding
2021-01-21 17:20:25 <skarnet> I can write a dns cache, even a dnssec validating one
2021-01-21 17:20:32 <skarnet> but not for free, hint hint
2021-01-21 17:20:50 <skarnet> 
ACTION nudges nudges

2021-01-21 17:20:59 <dalias> dnsmasq is the only software whose intended usage model matches mine, without loads of YAGNI generality and bloat
2021-01-21 17:21:02 <dalias> skarnet, :)
2021-01-21 17:21:21 <ikke> inbefore dalias starts charging for musl :P
2021-01-21 17:21:34 <skarnet> dalias: but dnsmasq is already full of yagni generality
2021-01-21 17:21:50 <Ariadne> dnsmasq is full of security holes
2021-01-21 17:21:55 <skarnet> that too
2021-01-21 17:22:00 <dalias> we should really have a "musl community bounty board" or something
2021-01-21 17:22:26 <adhawkins> Thanks mps
2021-01-21 17:22:28 <skarnet> if the bounty board is aligned on those out there, no way it will be worth it
2021-01-21 17:22:32 <Ariadne> but seriously, dnsmasq needs to die
2021-01-21 17:22:55 <dalias> open to posting by ppl who have contributed to community in significant ways (bug reporting, patches, distro integration, ...) and subject to a CoC
2021-01-21 17:23:21 <dalias> "i want to make a [X] but this would be a significant amount of work. anyone want to fund it? this is minimum i'd need."
2021-01-21 17:23:23 <skarnet> ikke: he kinda is, that's what sponsors are for
2021-01-21 17:23:56 <timlegge> adhawkins: if that is a perl module its apkbuild-cpan you need
2021-01-21 17:24:31 <jvoisin> dalias: that would be really nice
2021-01-21 17:24:32 <skarnet> dalias: flat rates are dangerous unless you already know *exactly* where you're going
2021-01-21 17:26:47 <dalias> yeah. it requires good ability to estimate time and have a billable-hours rate in mind to figure from
2021-01-21 17:27:07 <dalias> i've gotten pretty good at it
2021-01-21 17:27:17 <dalias> maybe i should do a blog post or something on the topic
2021-01-21 17:28:04 <skarnet> please do, I'm always interested in peeks into the business side of things
2021-01-21 17:28:09 <ikke> Ariadne: just out of curiosity, is there anything happening with getting vanilla linux to work for the mips builders?
2021-01-21 17:28:16 <Ariadne> ikke: LOL
2021-01-21 17:28:29 <Hello71> Ariadne: libseccomp was updated ages ago. problem is that docker ppa doesn't have libseccomp
2021-01-21 17:28:30 <Ariadne> err, i mean
2021-01-21 17:28:33 <Ariadne> not yet :)))
2021-01-21 17:28:40 <ikke> Ariadne: :D
2021-01-21 17:28:41 <Ariadne> docker... ppa?
2021-01-21 17:28:50 <Ariadne> why would we be using a PPA?
2021-01-21 17:28:57 <ikke> Not us, other people
2021-01-21 17:29:05 <ikke> who use ubuntu as docker host
2021-01-21 17:29:06 <Ariadne> i was going to say
2021-01-21 17:29:09 <Ariadne> I DEMAND ANSWERS
2021-01-21 17:29:46 <Hello71> ubuntu has backported libseccomp... problem is they only backported like 2.4.2 or something and we need 2.4.4 or something
2021-01-21 17:30:04 <Ariadne> yes, but we wouldn't be using ubuntu in our infrastructure
2021-01-21 17:30:15 <ikke> Ariadne: and we only have libseccomp 2.4.4 in 3.13
2021-01-21 17:30:18 <Hello71> allegedly the libseccomp model does not easily allow negating filter
2021-01-21 17:30:29 <Hello71> right, almost nobody has backported 2.4.4
2021-01-21 17:30:33 <Ariadne> can we backport it to 3.12?
2021-01-21 17:30:37 <Ariadne> or does it involve ABI break
2021-01-21 17:30:46 <Hello71> plus those who do may not have compiled it against 5.10 headers
2021-01-21 17:31:03 <Ariadne> ah
2021-01-21 17:31:09 <Ariadne> so you have to backport linux-headers too
2021-01-21 17:31:11 <Hello71> i think libseccomp 2.5 does not require headers anymore
2021-01-21 17:31:16 <Ariadne> meh
2021-01-21 17:31:33 <timlegge> I ran into the issue with a Ubuntu hosts and managed to work around it with the details of from the release notes
2021-01-21 17:31:48 <ikke> timlegge: did you switch the default action?
2021-01-21 17:31:53 <Hello71> timlegge: yes, 3.13 release notes should be complete... for 3.13. this is for 3.14
2021-01-21 17:32:10 <Ariadne> yes
2021-01-21 17:32:14 <Ariadne> well
2021-01-21 17:32:22 <Ariadne> can't hold faccessat2 back forever
2021-01-21 17:32:27 <Hello71> dalias: afaik you can nest seccomp if the filter allows running seccomp, but cannot remove seccomp
2021-01-21 17:32:29 <timlegge> Yes for my purposes it worked fine
2021-01-21 17:32:39 <ikke> Hello71: Shouldn't we warn that changing the default seccomp action to SCMP_ACCT_TRACE effectively disables it?
2021-01-21 17:33:05 <timlegge> Could be a little delayed on replies my main laptop is having issues
2021-01-21 17:34:14 <Hello71> ikke: your message on #12311 is little confused, it says >4.4
2021-01-21 17:34:43 <ikke> Hello71: how so?
2021-01-21 17:34:51 <Hello71> also i'm confused why you would need to apk add -u busybox, shouldn't it be in the new alpine:edge
2021-01-21 17:35:03 <ikke> Hello71: not until ncopa makes a new snapshot
2021-01-21 17:35:04 <Hello71> ah, you mean >, not >=
2021-01-21 17:35:07 <ikke> yes
2021-01-21 17:35:15 <Hello71> i think other people will be confused about this too :p
2021-01-21 17:35:23 <Hello71> also technically it is not right, since e.g. 4.4.1 is not ok
2021-01-21 17:35:25 <ikke> I'll change it
2021-01-21 17:35:50 <Hello71> also your command i think has an error, you probably missed > before /dev/null?
2021-01-21 17:36:05 <ikke> Thanks, yes
2021-01-21 17:37:46 <ikke> Hello71: if you don't upgrade bb in the entrypoint, it already fails before you have the opportunity to update it
2021-01-21 17:37:52 <Hello71> yeah
2021-01-21 17:38:02 <ikke> the alpine:edge image still contains the unpatched version
2021-01-21 17:38:10 <Hello71> i was under the impression that ncopa updated alpine:edge, but if not then you are right
2021-01-21 17:38:21 <ikke> He pushed the patched version to edge
2021-01-21 17:38:41 <ikke> but once in a while he snapshots edge, and from that tag, new images are made
2021-01-21 17:39:08 <ikke> so alpine:edge is not automatically updated weekly or something like that
2021-01-21 17:39:20 <dalias> hello71, does docker's seccomp filter allow you to use seccomp inside?
2021-01-21 17:39:25 <Hello71> no idea
2021-01-21 17:40:44 <ikke> Hello71: if SCMP_ACCT_TRACE effectively disables seccomp, couldn't we as well just tell the to disable seccomp (which is more explicit in what's happening)
2021-01-21 17:40:52 <Hello71> uh
2021-01-21 17:40:56 <Hello71> well i didn't realize it would do that
2021-01-21 17:41:00 <Hello71> is the problem
2021-01-21 17:41:06 <ikke> according to dalias it does
2021-01-21 17:41:20 <Hello71> yes i think he's right. not 100% but seems right
2021-01-21 17:41:36 <ikke> So having that in our release notes without any warning does not seem right
2021-01-21 17:41:48 <Hello71> assuming so, then yes i agree
2021-01-21 17:42:31 <dalias> *nod*
2021-01-21 17:42:56 <dalias> trace is "disable seccomp, but log things that would have been violations" and users probably do not understand that, so "disable" is more honest
2021-01-21 17:43:06 <ikke> dalias: exactly
2021-01-21 17:43:39 <mps> now is more quiet here, so to repeat 'any opinion about this !17032 objections or ....?'
2021-01-21 17:43:45 <mps> ncopa: ^
2021-01-21 17:44:14 <mps> you are maintainer
2021-01-21 17:52:19 <Hello71> dalias: i don't think that's right. that's SCMP_ACT_LOG
2021-01-21 17:52:41 <ikke> https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#time64_requirements
2021-01-21 17:53:20 <Hello71> ah, yes. "If there is no tracer present, the system call is not executed and returns a failure status with errno set to ENOSYS."
2021-01-21 17:54:12 <Hello71> ikke: ^ also
2021-01-21 17:54:37 <ikke> hmm
2021-01-21 17:56:25 <ikke> Hello71: Where did you find that?
2021-01-21 17:56:32 <Hello71> man seccomp
2021-01-21 17:57:40 <ikke> ok, so that does work as expected that
2021-01-21 17:58:58 <dalias> ohh really?
2021-01-21 17:59:11 <dalias> if that's true then trace does fix it
2021-01-21 17:59:16 <dalias> does "tracer" mean ptrace?
2021-01-21 18:01:24 <ikke> "A tracer will be notified if it requests PTRACE_O_TRACESECCOMP using ptrace(PTRACE_SETOPTIONS)."
2021-01-21 18:02:28 <Hello71> i think i was previously confused about if it was possible to misbehave if dockerd was being debugged or something, but i don't think so
2021-01-21 18:03:22 <Hello71> i think it implies that if a tracer does not request PTRACE_O_TRACESECCOMP, then the system call is not executed and returns a failure status with errno set to ENOSYS.
2021-01-21 18:04:29 <dalias> sounds like a reliable fix
2021-01-21 18:04:50 <ikke> That's what I used for our CI hosts (that do not run alpine 3.13 yet)
2021-01-21 18:04:54 <dalias> effectively it's just "change EPERM to ENOSYS"
2021-01-21 18:07:21 <Hello71> yes. i think the only problem with this fix is that it changes some places that really should be EPERM to ENOSYS too
2021-01-21 18:07:48 <ikke> Hello71: right, was thinking about that
2021-01-21 18:07:51 <Hello71> which is part of the reason why i recommended updating libseccomp/docker first, and this as a workaround
2021-01-21 18:08:16 <dalias> hello71, i don't find any of the arguments that that's problematic compelling
2021-01-21 18:09:05 <dalias> replacing an error that indicates need for fallback with one that indicates a fatal problem (what runc is doing) is a breaking change
2021-01-21 18:09:30 <Hello71> well it's fine for syscalls that have a fallback
2021-01-21 18:09:46 <dalias> replacing an error that indicates a fatal problem with one that indicates a need for fallback at worst obscures the cause of breakage or causes spurious fallback sequence that also fails with errors
2021-01-21 18:10:04 <dalias> but it doesn't break anything
2021-01-21 18:10:26 <Hello71> i think someone said somewhere (yes, very specific i know) that there is actually some broken software
2021-01-21 18:10:38 <Hello71> if (errno == EPERM) etc
2021-01-21 18:10:51 <dalias> but what doess it do on the else condition?
2021-01-21 18:11:31 <Hello71> dunno
2021-01-21 18:11:57 <dalias> i can't imagine how "executing the else condition rather than the EPERM condition" is going to be catastrophic
2021-01-21 18:12:12 <dalias> it's an operation that's expected to fail just failing in a different way
2021-01-21 18:12:20 <dalias> rather than an operation that's expected to succeed failing
2021-01-21 18:13:58 <ikke> fail, succesfully
2021-01-21 18:16:56 <Hello71> idk, "else put file somewhere else instead"?
2021-01-21 18:17:39 <Hello71> i don't think that's correct, but assume that some other program may be broken in a way that happens to work here
2021-01-21 18:18:17 <Hello71> considering that most of the idea of docker is "put this crap in a box and make sure it doesn't get everywhere" that seems plausible
2021-01-21 19:51:15 <ddevault> unexpected/undocumented failure due to bdb deprecation: my cyrus-sasl database was just dropped on the floor and had to be remade from scratch
2021-01-21 19:51:31 <ddevault> and naturally the saslauthdb service starts up without complaints and doesn't fail until someone tries to send an email with it
2021-01-21 19:55:28 <Hello71> i'm inclined to say that it should be possible to convert it
2021-01-21 19:55:34 <Hello71> but i suspect cyrus doesn't support it
2021-01-21 19:56:00 <ddevault> I didn't have time to seek out an elegant situation, it caused an outage in a mission critical service
2021-01-21 19:56:07 <ddevault> perhaps if I had been forewarned by the release notes ;)
2021-01-21 19:56:42 <Hello71> i think this is maxice8's fault
2021-01-21 19:57:00 <ddevault> not pointing fingers, but the changelog should be updated and a lesson learned for next time
2021-01-21 19:57:13 <Hello71> except that when maxice8 made the commit the release notes didn't exist yet
2021-01-21 19:57:54 <Hello71> i think what maxice8 probably thought was "i should write this down. is there a place to write this down? not yet?" then forgot about it
2021-01-21 19:59:43 <Hello71> ddevault: added it now, thanks
2021-01-21 19:59:59 <ddevault> thanks Hello71
2021-01-21 20:00:38 <skarnet> ddevault: someone has to be that guy, so I will. Why do you have mission-critical services relying on bdb? :P
2021-01-21 20:01:01 <Hello71> my guess would be that ddevault didn't know that cyrus used bdb on alpine
2021-01-21 20:01:05 <ddevault> ^
2021-01-21 20:01:10 <skarnet> makes sense
2021-01-21 20:01:14 <ddevault> and for storing <20 username/password combos, who cares?
2021-01-21 20:01:31 <ddevault> I was able to deal with the migration for postfix without any issues because it was documented in the release notes
2021-01-21 20:01:43 <skarnet> <20 pairs? explicit text backend
2021-01-21 20:01:45 <Hello71> i think other distros switched to gdbm a while ago
2021-01-21 20:02:05 <Hello71> skarnet: does cyrus support that
2021-01-21 20:02:20 <ddevault> it really doesn't matter
2021-01-21 20:02:25 <ddevault> there was no need to exercise discretion here
2021-01-21 20:02:35 <ddevault> I had no way of predicting that the defaults would be a source of issues in the future
2021-01-21 20:02:42 <skarnet> Hello71: I don't know, but if it doesn't, it's trash. ;)
2021-01-21 20:03:14 <skarnet> ddevault: not paranoid enough yet
2021-01-21 20:03:21 <ddevault> welcome to mail software
2021-01-21 20:03:22 <ddevault> it sucks here
2021-01-21 20:03:32 <skarnet> yup
2021-01-21 20:03:45 <ddevault> if you want to avoid trash then you're going to spend the next 20 years rewriting the stack
2021-01-21 20:04:48 <skarnet> well *transport* is unavoidable trash, but *storage* is doable
2021-01-21 20:05:07 <skarnet> including credentials storage
2021-01-21 20:05:08 <ddevault> good luck
2021-01-21 20:05:11 <ddevault> give me a call when you're done
2021-01-21 20:05:21 <skarnet> I'm not saying I'm doing it
2021-01-21 20:05:30 <skarnet> I'm saying it's possible to do it without being trash
2021-01-21 20:05:39 <skarnet> dovecot has a passwdfile backend for instance
2021-01-21 20:08:08 <Hello71> yeah but is it really an improvement over cyrus
2021-01-21 20:08:37 <ddevault> skarnet supposes that if you stack shit high enough it'll solve any problem
2021-01-21 20:08:47 <skarnet> huh?
2021-01-21 20:08:54 <ddevault> dovecot is also a buggy pile of shit
2021-01-21 20:08:58 <ddevault> cyrus is a buggy pile of shit
2021-01-21 20:09:02 <ddevault> postfix is a buggy pile of shit
2021-01-21 20:09:10 <ddevault> under every overturned stone is more shit
2021-01-21 20:09:37 <skarnet> what part of "it's possible to do credentials storage without being shit" is unclear
2021-01-21 20:10:00 <ddevault> okay
2021-01-21 20:10:01 <ddevault> 
ACTION crosses one problem off the list

2021-01-21 20:10:06 <ddevault> the list is still very long
2021-01-21 20:10:11 <skarnet> oh definitely
2021-01-21 20:10:41 <skarnet> and transport being unavoidably shit is the reason why I'm never touching MTA stuff
2021-01-21 20:11:13 <Ariadne> deprecating and removing BDB was a good first step
2021-01-21 20:11:22 <Ariadne> sorry that it caused downtime though ddevault
2021-01-21 20:11:29 <ddevault> shit happens
2021-01-21 20:12:08 <Ariadne> we were in a shit situation though, our BDB was vulnerable and Oracle made it difficult to backport a secfix
2021-01-21 20:12:18 <Ariadne> and, well, we shouldn't negotiate with terrorists, right?
2021-01-21 20:13:03 <ddevault> I'm not miffed about the bdb deprecation, it was annoying but the right call
2021-01-21 20:13:16 <ddevault> the only issue is that the conseqeunces of it were not fully explored and documented
2021-01-21 20:13:31 <jvoisin> ddevault: what about the OpenBSD one? OpenSMTPD
2021-01-21 20:13:49 <Ariadne> we should do a sprint with 3.14 to fully flesh out the release notes i think
2021-01-21 20:13:50 <ddevault> OpenBSD is also an exercise in shit-stacking
2021-01-21 20:15:15 <nmeum> haha
2021-01-21 20:15:16 <nmeum> plan9 upas?
2021-01-21 20:15:21 <ddevault> please no
2021-01-21 20:15:43 <jvoisin> https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/ looks sane-ish
2021-01-21 20:15:49 <ddevault> upas may be the only thing in plan 9 which is rotten
2021-01-21 20:16:10 <nmeum> hehe
2021-01-21 20:16:33 <Ariadne> postfix is at least mostly reasonable to admin
2021-01-21 20:16:48 <ddevault> postfix just werks once you get it werking, and life is too short to configure two mail servers
2021-01-21 20:21:16 <Ariadne> i just use postgres with postfix and dovecot
2021-01-21 20:21:32 <Ariadne> even though it's just me, but that way if i want to add anyone else, it is just an sql query
2021-01-21 20:25:51 <skarnet> global warming thanks you :P
2021-01-21 20:32:56 <Hello71> i think for future releases we should have a place for draft notes up early so that people don't think "i should write this down... do we have a place? no? maybe later then" and then forget about it. it doesn't have to be good but the irc is not a reliable storage medium
2021-01-21 20:37:20 <Cogitri> We have that in the wiki
2021-01-21 20:39:58 <Hello71> hm... my mistake, it was created July 2020
2021-01-21 20:45:43 <mps> do we have tool in alpine which can remove PMBR (Protective MBR) on disks
2021-01-21 20:46:02 <mps> 'dd', fdisk doesn't work
2021-01-21 20:46:26 <mps> gptfdisk can but is cumbersome
2021-01-21 20:46:30 <ikke> Hello71: the deprection of bdb was the first thing I've added to that wiki page
2021-01-21 20:46:36 <Hello71> yes i saw that
2021-01-21 20:46:53 <Hello71> mps: wipefs (util-linux)
2021-01-21 20:47:18 <Hello71> if you need to do it frequently probably use dd
2021-01-21 20:48:13 <mps> Hello71: doubt that wipefs will work if dd doesn't but will try
2021-01-21 20:48:35 <Hello71> well i mean if dding the whole disk doesn't work then your problem isn't the mbr
2021-01-21 20:48:45 <Hello71> maybe you actually want partprobe
2021-01-21 20:49:10 <ikke> I did my best to start early with the release notes to capture as much as possible
2021-01-21 20:49:12 <ikke> for 3.13
2021-01-21 20:49:47 <Hello71> yes i do recall this
2021-01-21 20:49:54 <Hello71> so... we are back to blaming maxice8? :p
2021-01-21 20:50:27 <ikke> need to create a habbit of documenting these things
2021-01-21 20:50:52 <mps> Hello71: partprobe after changing or dd-ing also doesn't help
2021-01-21 20:51:39 <ikke> https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0 :)
2021-01-21 20:52:01 <ikke> Should be early enough now :P
2021-01-21 21:05:28 <Hello71> mps: what exactly is your problem
2021-01-21 21:05:55 <mps> trying to remove PMBR from disk, that is.
2021-01-21 21:07:43 <MY-R> if you remove first 460 bytes from disk then there is no mbr at all, am I missing something? :\
2021-01-21 21:08:13 <mps> I thought so but osX doesn't
2021-01-21 21:08:37 <mps> lets see what parted can do
2021-01-21 21:08:44 <MY-R> there is also mbr security in old bios'es maybe that is the problem
2021-01-21 21:11:47 <mps> MY-R: no in that case, macbook pro (old one)
2021-01-21 21:11:58 <mps> but parted solved problem :)
2021-01-21 21:12:13 <Hello71> MY-R: that's pretty ancient. not sure such machines can run unmodified syslinux though
2021-01-21 21:12:18 <MY-R> ahh no 460 but better just zero first 512
2021-01-21 21:14:03 <MY-R> Hello71: ye is very ancient :)
2021-01-21 21:20:27 <Hello71> i don't think i ever saw such machines, but heard of them
2021-01-21 21:24:40 <MY-R> really?
2021-01-21 21:25:38 <MY-R> I saw it many times but those were old machines in age of bios and also in old laptops
2021-01-21 21:34:51 <Hello71> yeah but problem is i'm only in early 20s years old. i think those machines with mbr lock were like mid 90s-early 2000s
2021-01-21 21:35:38 <MY-R> I think last one I saw was some Dell from 2002
2021-01-21 21:36:22 <Hello71> yeah, so pretty obsolete :p
2021-01-21 21:37:04 <Hello71> bios-only i'm quite familiar with, but those later machines didn't have "boot record security" anymore
2021-01-21 21:40:54 <MY-R> eh, Im just old :\ whatever, EOT :)
2021-01-21 23:08:41 <mps> maxice8: are you around?
2021-01-22 01:48:45 <maxice8> mps: pong
2021-01-22 07:24:09 <ncopa> morning
2021-01-22 07:24:56 <ncopa> ikke: good to start planning for the 3.14 release notes
2021-01-22 07:26:30 <ncopa> i was thinking that we could maybe have a form for MR where one of the entries is "Should this be mentioned in the release notes? [no]" and if its set, the title of the MR will be used for release notes.
2021-01-22 07:29:17 <Cogitri> A tag would probably be easier to search for
2021-01-22 07:43:05 <adhawkins> Morning all. I'm in the process of packaging emborg, a Python front end to borgbackup.
2021-01-22 07:43:45 <adhawkins> I've read that it's preferred that a PR is made.for each new package. However, emborg depends on some other Python packages that aren't in alpine yet.
2021-01-22 07:44:22 <adhawkins> Is it ok to make one PR for all of these new packages, as long as there's a separate commit for each package?
2021-01-22 07:46:13 <maxice8> Yes, that is the preferred method
2021-01-22 07:46:32 <maxice8> Packages added as a dependency of a desired package should be separate commits under the same Mr
2021-01-22 08:04:34 <adhawkins> That's great, thanks maxice8
2021-01-22 09:04:24 <mps> maxice8: sorry, I went to sleep
2021-01-22 09:06:06 <mps> wanted to ask you do we need to add CVE in secfixes again for !17252
2021-01-22 09:06:29 <maxice8> no
2021-01-22 09:06:51 <mps> I think no, because they already there, though on 'patch' version
2021-01-22 09:07:07 <maxice8> It was fixed in 2.0.4-r1 (or whatever release), changing the fix from a trivial backport from upstream to a new version released from upstream doesn't change the fact it was fixed in 2.0.4-r1
2021-01-22 09:07:50 <mps> yes
2021-01-22 09:08:39 <mps> another question, I see this in source 'CVE-2021-3181.patch::https://gitlab.com/muttmua/mutt/-/commit/c059e20ea4c7cb3ee9ffd3500ffe313ae84b2545.patch' for 2.0.4-r1
2021-01-22 09:09:41 <mps> do we have somewhere 'policy' that we can use this format for patches and maybe other things in source?
2021-01-22 09:10:08 <mps> if yes, would be nice if it is written somewhere
2021-01-22 09:10:08 <maxice8> No, we just warn against using pull request patches
2021-01-22 09:10:30 <maxice8> Because those can change as the contributor pushes changes, thus changing the checksum
2021-01-22 09:10:38 <mps> aha, ok
2021-01-22 09:10:47 <maxice8> AL60 something I think
2021-01-22 09:10:53 <maxice8> Around 55 to 60
2021-01-22 09:11:57 <adhawkins> Anyone here familiar with packaging python modules? The package I've created has both an 'inform' and 'inform-1.23.0-py3.8.egg-info' directory under site-packages. Should both of these be installed?
2021-01-22 09:12:29 <adhawkins> It looks like they are for other packages I already have installed.
2021-01-22 09:58:31 <maxice8> Yes, if you're packaging the inform module
2021-01-22 10:11:40 <adhawkins> I am maxice8, thanks.
2021-01-22 10:11:52 <adhawkins> Anyone prepared to 'review' some packages from a first-timer?
2021-01-22 10:20:41 <ikke> We have a @team/mentors group you can tag
2021-01-22 10:23:24 <adhawkins> Where do I do that ikke? Sorry, new to this.
2021-01-22 10:23:37 <ikke> In Gitlab
2021-01-22 10:23:48 <adhawkins> So this is when I submit the MR?
2021-01-22 10:23:52 <ikke> In the comments of your MR
2021-01-22 10:23:55 <ikke> Yes
2021-01-22 10:24:21 <adhawkins> Ok. Was hoping someone might be able to look at it before it got to that stage. Hate to waste people's time if I've made a rookie mistake.
2021-01-22 10:25:32 <ikke> Do not worry about that
2021-01-22 10:25:47 <ikke> You could mark the MR as draft
2021-01-22 10:26:59 <adhawkins> Ok. Will have a go. The document I've been using mentions making a PR in GitHub. Is that out of date?
2021-01-22 10:27:28 <adhawkins> https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package: "Because you do not have push rights to the Alpine aports repository you need to create a pull request to Alpine's mirror on GitHub (read instructions here)."
2021-01-22 10:27:46 <ikke> Ah, yes
2021-01-22 10:28:01 <adhawkins> Good. I've done all the work in GitLab :)
2021-01-22 10:28:09 <adhawkins> I'll create a merge request and see how I get on. Thanks ikke.
2021-01-22 10:29:16 <PureTryOut[m]2> adhawkins: yes both of those should be installed
2021-01-22 12:35:29 <PureTryOut[m]2> ncopa: you maintain libnl. I have a package depending on it and it fails to compile. It _seems_ because of libnl rather than the package itself, but I'm not sure what to do about it. Incoming error:
2021-01-22 12:35:32 <PureTryOut[m]2> 
ACTION sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/pgLdzTXILDWBpkGWdPhZiHnG/message.txt >

2021-01-22 12:39:28 <Hello71> seems suspiciously like problem with your linux headers
2021-01-22 12:39:49 <Hello71> which alpine release
2021-01-22 12:42:32 <Hello71> actually, hm....
2021-01-22 12:44:22 <PureTryOut[m]2> Edge
2021-01-22 12:44:33 <PureTryOut[m]2> `netlink-kernel.h` comes from libnl btw
2021-01-22 12:45:07 <Hello71> yeah i got that
2021-01-22 12:53:31 <Hello71> what i'm confused about is how this works at all on alpine
2021-01-22 12:54:48 <Hello71> it doesn't define __u32 or include <linux/types.h>
2021-01-22 12:58:05 <PureTryOut[m]2> Exactly. I couldn't find anything about it anywhere
2021-01-22 12:59:30 <adhawkins> Hi all. Trying to set my fork of aports so that it updates automatically. However, if I go into 'Mirroring repositories' and enter the URL of the 'real' aports (https://gitlab.alpinelinux.org/alpine/aports.git) it won't let me change the 'Mirror direction' to 'Pull'. Anyone assist with this?
2021-01-22 13:01:41 <PureTryOut[m]2> Oh seems our libnl is way outdated. Newest is 3.5.0
2021-01-22 13:01:55 <adhawkins> It appears it might be because of the GitLab plan alpine is on perhaps?
2021-01-22 13:01:58 <PureTryOut[m]2> Other distros seems to have the version we ship as libnl1 still for legacy compatibility
2021-01-22 13:02:06 <PureTryOut[m]2> So I might just rename our package to do the same
2021-01-22 13:02:20 <PureTryOut[m]2> Oh wait, we have libnl3 as well
2021-01-22 13:04:09 <PureTryOut[m]2> Yeah that's the one I need. Let's just ignore libnl, it's legacy anyway
2021-01-22 13:04:36 <mps> PureTryOut[m]2: libnl3
2021-01-22 13:05:37 <mps> that is, we have versioned libs already :)
2021-01-22 13:06:18 <PureTryOut[m]2> Yeah I just found that
2021-01-22 13:06:43 <PureTryOut[m]2> The non-fuzzy search on https://pkgs.alpinelinux.org messed me up lol
2021-01-22 13:07:07 <mps> I usually search aports repo
2021-01-22 13:07:22 <mps> lot more data for grep
2021-01-22 13:07:51 <adhawkins> ikke: Could you take a look over https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17298 and let me know if it looks like I've made any major screw ups?
2021-01-22 13:09:34 <PureTryOut[m]2> Don't be so afraid of making mistakes 😉
2021-01-22 13:09:45 <PureTryOut[m]2> You seem to have every commit in that MR twice?
2021-01-22 13:10:22 <adhawkins> They don't show in the original branch PureTryOut[m]2?
2021-01-22 13:10:26 <adhawkins> https://gitlab.alpinelinux.org/adhawkins/aports/-/commits/emborg
2021-01-22 13:10:28 <PureTryOut[m]2> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17298/diffs#cb8ed1578aed2eaf4449c7779748addac0f0728d
2021-01-22 13:10:45 <PureTryOut[m]2> Yeah they do
2021-01-22 13:10:51 <PureTryOut[m]2> There are just 3 unrelated commits inbetween
2021-01-22 13:10:55 <adhawkins> Oh wait, yes they do. I did a rebase, is that where I screwed up?
2021-01-22 13:11:00 <PureTryOut[m]2> Seems like it
2021-01-22 13:11:19 <maxice8> your master branch is not up-to-date
2021-01-22 13:11:22 <adhawkins> Damn. My git skills obviously failing me.
2021-01-22 13:11:23 <PureTryOut[m]2> I think you can just drop the old ones and it should be fine
2021-01-22 13:11:32 <adhawkins> maxice8: I did update the master and then rebase the branch against it.
2021-01-22 13:11:43 <PureTryOut[m]2> Use https://git-rebase.io/
2021-01-22 13:11:58 <maxice8> I'm currently reviewing it locally, a rebase against an up-to-date master is all that needed
2021-01-22 13:12:39 <PureTryOut[m]2> You don't have to rename the source packages btw, you can just download from https://github.com/<username>/<repo>/archive/<pkgver>/<pkgname>-<pkgver>.tar.gz
2021-01-22 13:14:06 <adhawkins> Does that look better PureTryOut[m]2 and maxice8?
2021-01-22 13:14:19 <PureTryOut[m]2> Yup!
2021-01-22 13:14:21 <adhawkins> (I think I've done the rebase)
2021-01-22 13:15:23 <adhawkins> Someone has commented that some of them aren't running tests. Can some assist with what I've done wrong?
2021-01-22 13:20:16 <PureTryOut[m]2> Not every package might have tests
2021-01-22 13:20:25 <PureTryOut[m]2> Also, I would recommend running Python tests with `pytest` rather than with setup.py
2021-01-22 13:20:57 <adhawkins> They have added some patches to get the tests running. Will give them a go.
2021-01-22 13:21:25 <PureTryOut[m]2> Add `py3-pytest` to checkdepends (create the variable if it does not exist yet) and run `pytest` in the check function
2021-01-22 13:22:41 <PureTryOut[m]2> Btw Leo on Gitlab is maxice8 here
2021-01-22 13:35:35 <adhawkins> Thanks. Added the patches to make it check. Getting a new failure in quantiphy. Beyond my python knowledge here sadly, so appreciate any suggestions.
2021-01-22 13:36:07 <adhawkins> https://termbin.com/wtsy
2021-01-22 13:37:53 <PureTryOut[m]2> Well for one, multiple missing modules
2021-01-22 13:39:11 <PureTryOut[m]2> `py.test-3` is such a weird binary name...
2021-01-22 13:39:13 <adhawkins> quantiphy_eval?
2021-01-22 13:39:17 <PureTryOut[m]2> Yeah
2021-01-22 13:39:23 <PureTryOut[m]2> Not sure where it should come from though
2021-01-22 13:39:55 <adhawkins> It seems to be a package in its own right: https://pypi.org/project/quantiphy-eval/
2021-01-22 13:40:07 <PureTryOut[m]2> Ah. Well easy solution then, package it 😃
2021-01-22 13:41:45 <maxice8> https://github.com/KenKundert/quantiphy/blob/master/tox.ini
2021-01-22 13:41:56 <maxice8> quantiphy_eval and rkm_codes
2021-01-22 13:48:36 <timlegge> adhawkins: is apkbuild-pypi working okay for you. I believe I made last changes to it over a year ago feel free to improve it
2021-01-22 13:49:42 <adhawkins> timlegge: I gave up on it in the end. Just starting from scratch
2021-01-22 13:50:57 <timlegge> That's too bad it makes it a lot easier once it works I don't create python packages but if I get sometime I will take a look
2021-01-22 13:52:12 <maxice8> timlegge: unfortunately it is lagging behind apkbuild-cpan in terms of features and policy compliance
2021-01-22 13:52:17 <timlegge> I use apkbuild-cpan for Perl modules and it really makes keeping them up-to-date a lot easier
2021-01-22 13:52:37 <maxice8> apkbuild-cpan is a godsent, don't even manually touch perl APKBUILDs
2021-01-22 13:53:44 <timlegge> maxice8: that is my goal with it I still have a couple of nagging things to look at but for the most part it works great
2021-01-22 13:54:16 <maxice8> yes, only problem I found is duplicate dependencies
2021-01-22 13:55:30 <PureTryOut[m]2> Wait, what does apkbuild-cpan do and what should apkbuild-pypi do?
2021-01-22 13:55:54 <maxice8> apkbuild-cpan queries metacpan and fills in license, dependencies and other stuff
2021-01-22 13:56:02 <maxice8> basically an automatic perl APKBUILD creator by interacting with metacpan API
2021-01-22 13:56:16 <maxice8> apkbuild-pypi is s/perl/python/ and s/metacpan/pypi/
2021-01-22 13:56:22 <PureTryOut[m]2> Oh interesting
2021-01-22 13:56:28 <maxice8> both are writte in Perl though and apkbuild-cpan has more work on it
2021-01-22 13:56:31 <PureTryOut[m]2> I just copy comparable APKBUILDs and modify what's needed 🤷‍♂️
2021-01-22 13:56:36 <PureTryOut[m]2> Ew Perl
2021-01-22 13:56:39 <PureTryOut[m]2> 😂
2021-01-22 13:57:00 <mps> timlegge: apkbuild-pypi need  perl-ipc-system-simple in deps
2021-01-22 13:57:14 <maxice8> mps: make an MR :D
2021-01-22 13:57:48 <mps> maxice8: I don't like to touch anything py related :)
2021-01-22 13:58:14 <maxice8> mps: it is the abuild APKBUILD, apkbuild-pypi is a subpkg
2021-01-22 13:58:26 <mps> ah
2021-01-22 13:58:39 <timlegge> LOL I will spend days working on a script to remove 2 minutes of work if I have to repeat that two minutes on a regular basis
2021-01-22 13:58:40 <mps> didn't know, I thought it is separate apk
2021-01-22 13:58:59 <timlegge> It's the application of Applied laziness
2021-01-22 13:59:39 <mps> yes, script are safer than manual work, less chances to make errors
2021-01-22 14:03:25 <timlegge> I forgot apkbuild-pypi was written in perl.  I will put it on my list to update
2021-01-22 14:05:51 <mps> maxice8: I updated !17255
2021-01-22 14:08:15 <adhawkins> maxice8: PureTryOut[m]2: I think I've addresssed all the comments regarding testing and licences now. Would appreciate confirmation if you get chance.
2021-01-22 14:33:31 <adhawkins> Think I've got those last couple of dependencies too. Lesson learned, check setup.py a bit more closely!
2021-01-22 14:38:33 <PureTryOut[m]2> Well mainly just run the build locally
2021-01-22 14:38:52 <PureTryOut[m]2> Also, use either `docker-abuild` or `abuild-rootbld` to make sure locally installed stuff on your machine isn't in the way
2021-01-22 14:42:43 <adhawkins> Ooh, docker-abuild sounds interesting. Not too concerned about locally installed stuff as it's a clean VM running alpine that I'm using.
2021-01-22 14:42:52 <adhawkins> Installed next to nothing other than the abuild stuff.
2021-01-22 14:56:35 <PureTryOut[m]2> In that case docker-abuild will help you not need a VM anymore
2021-01-22 15:18:26 <adhawkins> Well, all my network is VMs, so it's no big deal. Will have a look at docker-abuild though.
2021-01-22 15:18:38 <adhawkins> Getting pipeline build failures, could this be due to the ordering of my commits?
2021-01-22 15:18:44 <adhawkins> https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/301722
2021-01-22 15:22:17 <adhawkins> It seems to be failing to find quantiphy when building quantiphy-eval
2021-01-22 15:23:07 <maxice8> Check if there are no circular dependecies
2021-01-22 15:26:49 <maxice8> py3-quantiphy needs py3-quantiphy-eval and py3-quantiphy needs py3-quantiphy-eval
2021-01-22 15:27:21 <maxice8> disable tests on py3-quantiphy since it only needs py3-quantiphy eval for tests while py3-quantiphy-eval needs py3-quantiphy to actually run (according to setup.py)
2021-01-22 15:34:34 <adhawkins> Ok. I seem to recall seeing I need a specific comment to indicate why tests are being disabled.
2021-01-22 15:35:34 <Hello71> generally it is better to fix tests
2021-01-22 15:35:39 <Hello71> or exclude specific tests if possible
2021-01-22 15:40:37 <adhawkins> Hello71: I'm not familiar with Python testing frameworks. How would I exclude the tests?
2021-01-22 15:41:15 <Hello71> dunno
2021-01-22 15:41:27 <adhawkins> Ok, I'll do some research. Thanks.
2021-01-22 15:41:40 <Hello71> if it's a command as opposed to a make target then usually ./run_tests --help is useful
2021-01-22 15:44:14 <adhawkins> How does this look? https://paste.debian.net/1182254/
2021-01-22 15:44:32 <adhawkins> It excludes the test, just double checking that's an appropriate comment to indicate why it's being skipped?
2021-01-22 16:07:12 <PureTryOut[m]2> pytest can exclude tests
2021-01-22 16:07:21 <PureTryOut[m]2> And yes that looks fine
2021-01-22 16:09:10 <maxice8> --deselect <test>
2021-01-22 16:09:17 <maxice8> call --deselect how many times you need
2021-01-22 16:12:11 <adhawkins> The pipeline build is now passing. Is that paste Ok do you think maxice8, or should I be excluding specific tests?
2021-01-22 16:13:29 <PureTryOut[m]2> Specific tests would be nicer, but this is fine as well
2021-01-22 16:13:45 <PureTryOut[m]2> (at least, when those specific tests is not just the whole file)
2021-01-22 16:17:19 <adhawkins> This is the test file PureTryOut[m]2: https://termbin.com/lr5h
2021-01-22 16:17:47 <adhawkins> It's test_manual that isn't working. I've tried '--deselect test_manual' and '--deselect manual' but it still runs it.
2021-01-22 16:18:51 <PureTryOut[m]2> Use `-k 'not test_manual'` instead
2021-01-22 16:19:29 <PureTryOut[m]2> But that won't help in this case, as it'll break on the import on line 3 already
2021-01-22 16:19:35 <PureTryOut[m]2> So just exclude the whole file
2021-01-22 16:41:11 <adhawkins> Oh ok, thanks.
2021-01-22 16:41:36 <adhawkins> Actually, no. These tests are for the quantiphy package itself.
2021-01-22 16:42:56 <adhawkins> PureTryOut[m]2: ERROR: Wrong expression passed to '-k': not test manual: at column 10: expected end of input; got identifier
2021-01-22 16:43:01 <adhawkins> 	PYTHONPATH="$PWD/build/lib" py.test-3 -k 'not test manual' # --ignore=tests/test_doctests.py
2021-01-22 16:43:20 <PureTryOut[m]2> You forgot the underscore
2021-01-22 16:43:26 <PureTryOut[m]2> "not test_manual"
2021-01-22 16:43:43 <PureTryOut[m]2> Basically copy the function name that you want to skip
2021-01-22 16:44:43 <adhawkins> Doh, thanks. Tests now completing. Appreciate the help PureTryOut[m]2.
2021-01-22 16:46:25 <PureTryOut[m]2> No problem!
2021-01-22 17:00:13 <adhawkins> So, couple of questions about the merge request (feel free to point me to an FAQ or similar). 1. How long is it likely to be before this is merged? 2. How long is it likely to be before this becomes available in a 'release' of alpine? 3. What's the process for getting the packages moved out of 'testing'?
2021-01-22 17:01:45 <ikke> adhawkins: if packages are ok, they're usually merged withing 1 day - 1 week
2021-01-22 17:01:56 <ikke> packages in testing are not part of a release
2021-01-22 17:02:09 <ikke> so they need to moved to community (or main) first
2021-01-22 17:02:23 <ikke> An alpine release is created every half year
2021-01-22 17:02:52 <ikke> so packages in community and main now will be part of the next release
2021-01-22 17:03:01 <adhawkins> ikke: Ok. Is this move to community / main automatic? If not, what needs to be done to facilitate this?
2021-01-22 17:03:09 <ikke> No
2021-01-22 17:03:22 <ikke> After the package is built on the builders
2021-01-22 17:03:28 <ikke> you can verify it works properly
2021-01-22 17:03:38 <ikke> after that, you can create a merge request to move it
2021-01-22 17:04:05 <adhawkins> So this would just be moving all the directories I've created into community rather than testing?
2021-01-22 17:04:25 <ikke> yes
2021-01-22 17:04:39 <adhawkins> Ok great. Is there any sort of notification once this build process is complete?
2021-01-22 17:06:02 <ikke> You can watch https://build.alpinelinux.org
2021-01-22 17:06:09 <ikke> or watch #alpine-commits
2021-01-22 17:07:15 <adhawkins> Excellent, thanks for that info ikke.
2021-01-22 17:07:48 <ikke> You can also look at https://pkg.alpinelinux.org
2021-01-22 17:07:54 <ikke> if it appears there
2021-01-22 17:08:16 <adhawkins> I get an error from that link.
2021-01-22 17:09:31 <ikke> sorry, forgot an 's'
2021-01-22 17:09:33 <ikke> https://pkgs.alpinelinux.org/
2021-01-22 17:09:40 <adhawkins> That's better :)
2021-01-22 17:10:55 <adhawkins> Ok, final (possibly!) question for now. Is there any documentation on getting docker-abuild up and running? I've found the GIT repo but there isn't a whole lot of information about getting started with it.
2021-01-22 18:14:58 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16099#note_137898
2021-01-22 18:15:21 <Hello71> the wording of this comment is fairly aggravating if the submitter is not actually responsible for the delay
2021-01-22 18:16:33 <Hello71> i understand the intention of not wanting to have old mrs sitting around forever but this message seems to imply that it's my fault somehow
2021-01-22 18:17:40 <minimal> just noticed "env: can't execute 'bash': No such file or directory" in the build pipeline logs for multiple archs of a MR I submitted. It doesn't appear to be affecting the builds however
2021-01-22 18:20:44 <afontain_> probably should add bash to (make)?depends
2021-01-22 18:21:14 <ikke> The CI images do not have bash installed
2021-01-22 18:26:06 <minimal> afontain_: that's what I assumed, but then wouldn't expect it to build if bash was actually required. Plus I didn't see any (obvious) use of bash in the package's makefile
2021-01-22 18:26:57 <afontain_> `abuild rootbld` is a good way to catch those
2021-01-22 18:27:15 <afontain_> or in this specific case, grep '#!/usr/bin/env bash' :P
2021-01-22 18:28:22 <minimal> afountain_: had already searched package source for bash, only refs are in Markdown docs. So unless one of the pulled in (golang) files needs bash....
2021-01-22 18:31:02 <afontain_> weird
2021-01-22 18:31:18 <afontain_> you can still try to abuild rootbld
2021-01-22 18:32:31 <minimal> I'll have a look at that, locally I'm building inside my own Docker setup so will have to tweak that accordingly
2021-01-22 18:33:00 <minimal> for this package also had to disable armv7 and x86 archs - looks like there's code that's not 32bit clean :-(
2021-01-22 18:38:10 <ikke> you can also try to build it in the alpinelinux/alpine-gitlab-ci image
2021-01-22 18:41:23 <minimal> from Docker hub? Is there a source Dockerfile for that somewhere?
2021-01-22 18:42:42 <minimal> ideally I should finally get around to setting up cross-compile environment locally
2021-01-22 18:57:31 <adhawkins> Someone mentioned docker-abuild earlier. Sounds like a good approach to me, but can't find much information on how to set it up. Anyone point me to something useful?
2021-01-22 18:59:05 <minimal> adhawkins: https://gitlab.alpinelinux.org/alpine/docker-abuild
2021-01-22 18:59:50 <minimal> I haven't used it myself but I'm using something similar (using qemu-user inside docker so I can do multi-arch package builds)
2021-01-22 19:07:34 <adhawkins> Yeah, I found that minimal, but it doesn't give much information on how to get started with it.
2021-01-22 19:09:45 <minimal> adhawkins: think this is what my own setup was based on originally: https://github.com/andyshinn/docker-alpine-abuild
2021-01-22 19:10:14 <minimal> the docs there give an example
2021-01-22 19:12:34 <adhawkins> |Thanks minimal, will take a look.
2021-01-22 19:15:23 <adhawkins> maxice8: I'm not sure I fully understand your latest comment on my PR: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17298#note_137902
2021-01-22 19:15:23 <ikke> minimal: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci
2021-01-22 19:15:38 <maxice8> there is a line commented `# shlib`
2021-01-22 19:15:41 <maxice8> I don't think that is supposed to be there
2021-01-22 19:17:08 <adhawkins> Ah, good spot maxice8. That was my list of dependencies that I also needed to package. I obviously forgot to remove it!
2021-01-22 19:18:45 <minimal> ikke: thanks, will have a look. I spotted that my local docker abuild setup does have bash installed so that would (partly) explain why I don't see that warning locally. However I'm still confused as to what in the particular package I was building uses bash, but that's a different issue
2021-01-22 19:19:15 <adhawkins> Now fixed maxice8, thanks for that!
2021-01-22 19:19:39 <maxice8> welcome
2021-01-22 19:26:04 <mps> Marian[m]: ping
2021-01-22 19:26:59 <adhawkins> Well, I can install emborg from my packages directory with a combination of community and testing, so hopefully that means the MR is good to go!
2021-01-22 19:34:21 <adhawkins> Ooh, just seen a load of entries in alpine-commits with my name on. Does that mean it's merged?
2021-01-22 19:34:59 <mps> adhawkins: yes
2021-01-22 19:35:20 <adhawkins> So now I just need to wait for it to be built presumably?
2021-01-22 19:36:22 <ikke> fcolista: bareos is failing because chromium-chromedriver is missing
2021-01-22 19:36:55 <ikke> for most arches
2021-01-22 20:18:32 <adhawkins> Woot: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/emborg
2021-01-22 20:18:44 <ikke> adhawkins: nice
2021-01-22 20:18:48 <adhawkins> Thanks all for your assistance in getting these in. Will test and then look to have them move to community.
2021-01-22 20:18:49 <ikke> congrats with your first package!
2021-01-22 20:19:05 <maxice8> first packages
2021-01-22 20:19:12 <ikke> right
2021-01-22 20:19:14 <adhawkins> When I do that, do I need to bump up the pkgrel?
2021-01-22 20:19:24 <ikke> no
2021-01-22 20:19:48 <adhawkins> Can I do the same thing as before, a single MR with one commit for each package to move it?
2021-01-22 20:19:58 <ikke> yes
2021-01-22 20:20:03 <ikke> see an MR as a transaction
2021-01-22 20:20:13 <ikke> we want to move these things in a single transaction
2021-01-22 20:20:23 <adhawkins> Excellent. That's what I thought, it wouldn't make sense to move each package individually, as they depend on each other to a certain extent.
2021-01-22 21:16:34 <andypost[m]> It looks like edge-ppc64le builder hanging whole the week
2021-01-22 21:16:49 <ikke> let me take a look\
2021-01-22 21:16:55 <ikke> I've been a bit busy
2021-01-22 21:20:21 <ikke> andypost[m]: not sure what I did (well, I did strace the processes), but it seems to continue now
2021-01-22 21:20:36 <ikke> andypost[m]: was it stuck on botan all week?
2021-01-22 21:20:58 <andypost[m]> yep, botan and the same 45%
2021-01-22 21:21:37 <ikke> percantage does not change per package
2021-01-22 21:21:50 <ikke> it's jyst based on the amount of packages
2021-01-22 21:21:55 <ikke> but it seels to have finished now
2021-01-22 21:22:16 <ikke> now thing-provisioning-tools that does not know about ppc64le
2021-01-22 21:22:27 <ikke> "Invalid configuration `powerpc64le-unknown-linux-musl': machine `powerpc64le-unknown-linux' not recognized"
2021-01-22 21:22:49 <ikke> and update_config_{guess,sub} is already called
2021-01-22 21:23:21 <andypost[m]> asked bot to retry, and now it builds
2021-01-22 21:23:37 <andypost[m]> ikke: thank you
2021-01-22 21:24:49 <mps> Hello71: re !16099
2021-01-22 21:25:09 <mps> 
ACTION wonders why it is not merged for 3.13

2021-01-22 21:25:20 <mps> anyone know answer?
2021-01-22 21:25:30 <ikke> 
ACTION is puzzled how stracing processing unstucks them

2021-01-22 21:25:36 <ikke> I have seen that multiple times now
2021-01-22 21:26:27 <mps> yes, puzzles everywhere around us, God of AI shows to us but we are blind :)
2021-01-22 21:26:30 <ikke> observer effect
2021-01-22 21:26:40 <mps> also this
2021-01-22 21:27:07 <mps> famous cat
2021-01-22 21:28:21 <mps> 
ACTION changes nick to Schrödinger :)

2021-01-22 21:35:11 <Hello71> ikke: it sends a signal
2021-01-22 21:35:26 <Hello71> all system calls are terminated with EINTR
2021-01-22 21:35:58 <ikke> aha, ok
2021-01-22 21:36:06 <ikke> Was not aware
2021-01-22 21:36:42 <Hello71> well, all blocking system calls. most system calls are atomic and cannot be interrupted. like, you can't kill -9 a process waiting on hard nfs, you can't strace it either
2021-01-22 21:36:53 <Hello71> (i think...)
2021-01-22 21:37:11 <ikke> Right, uninteruptable sleep
2021-01-22 21:37:31 <Hello71> but if they're stuck in the kernel you can just ask the kernel where they are with cat /proc/x/{stack,wchan} or echo w > /proc/sysrq-trigger
2021-01-22 21:38:49 <Hello71> specifically i think strace needs to send SIGSTOP to all threads. so for poking a process kill -STOP; kill -CONT should be equivalent
2021-01-22 21:39:20 <Hello71> except i think it might have different effects on controlling terminal? not sure
2021-01-22 21:55:59 <maxice8> not ok 362 - udp_multicast_join6
2021-01-22 21:56:07 <maxice8> libuv fails on ppc64le
2021-01-22 23:56:03 <adhawkins> Whoops. Looks like when I changed the licence I didn't pick the correct wording. I've used 'GPL-3.0-or-newer' when it should in fact be 'GPL-3.0-or-later'. Should I do this as a separate change, or roll it into the rename from testing to community do you think?
2021-01-23 00:04:47 <Hello71> usually in git it's better to make change and move separate commits
2021-01-23 00:08:29 <adhawkins> Yeah, I was thinking the same. I'll do a correction to the licence issue. Is there any guidance as to what the commit message should look like for a package modification?
2021-01-23 00:09:12 <Hello71> git log
2021-01-23 00:09:19 <Hello71> i think is also in CODINGSTYLE.md or somesuch
2021-01-23 00:10:44 <mps> COMMITSTYLE.md iirc
2021-01-23 00:11:52 <mps> 'fix license to SPDX' is enough
2021-01-23 00:12:09 <mps> or something like this
2021-01-23 01:34:48 <timlegge> made some updates to apkbuild-pypi still need some work and not fully tested https://gitlab.alpinelinux.org/timlegge/abuild/-/blob/apkbuild-pypi/apkbuild-pypi.in
2021-01-23 01:53:51 <tbodt> what triggers an update of APKINDEX.tar.gz?
2021-01-23 01:53:57 <tbodt> trying to find the optimal time to update my mirror
2021-01-23 02:13:48 <timlegge> did someone mention that there is a docker image setup for abuild/aport dev instead of using a VM
2021-01-23 02:30:42 <TBK[m]> timlegge: https://gitlab.alpinelinux.org/alpine/docker-abuild
2021-01-23 02:31:48 <timlegge> thanks TBK[m]
2021-01-23 05:07:02 <maxice8> Aeiadne: can we postpone the python rebuild to end of Sunday m
2021-01-23 05:07:22 <maxice8> Bureocratic medical situation got me
2021-01-23 06:32:19 <Ariadne> works for me
2021-01-23 07:08:25 <maxice8> https://github.com/dense-analysis/ale/pull/3424#event-4241203185
2021-01-23 07:08:40 <maxice8> Yaaay
2021-01-23 07:15:41 <maxice8> ALE upstream now has APKBUILD support
2021-01-23 08:15:07 <mps> it is not that that the vim is good but alternatives are worse
2021-01-23 10:12:56 <fcolista> ikke, thanks for bareos, didn't notice that
2021-01-23 10:16:58 <ikke> fcolista: np
2021-01-23 11:27:31 <adhawkins> Need to make some changes to my new packages because I messed up the licence string. There were some other comments too that I might address. Is it ok to do more than one thing to the same package in an MR, or should they be separate?
2021-01-23 11:27:51 <adhawkins> If they can be in the same one, how should the commit message look?
2021-01-23 11:29:58 <mps> adhawkins: depends how changes are big, reviewers usually don't like big changes
2021-01-23 11:30:45 <mps> but that is left to 'common sense' of author of changes/MRs
2021-01-23 11:37:09 <adhawkins> They wouldn't be big. Little things like using pytest instead of py.3test (something like that!) and changing the source URL format.
2021-01-23 11:37:25 <adhawkins> So can I do multiple commits in the same MR?
2021-01-23 11:40:16 <maxice8> Yes
2021-01-23 11:42:14 <PureTryOut[m]2> Of course you can
2021-01-23 11:46:08 <adhawkins> Thanks. I realised it was technically possible, just wanted to make sure it was 'the done thing'
2021-01-23 12:59:18 <mps> Schroedingers cat again but I built apple M1 preloader on alpine using only alpine tools. have to check which tools are minimally needed
2021-01-23 13:59:04 <ikke> rebooting the x86_64 CI host
2021-01-23 13:59:12 <ikke> CI is quiet atm
2021-01-23 14:00:55 <mps> not for long, I'm preparing MR which will take a full day to finish :)
2021-01-23 14:01:13 <ikke> Too late :P
2021-01-23 14:01:23 <mps> not full but probably half of day
2021-01-23 14:01:38 <ikke> (or rather, I'm early enough)
2021-01-23 14:01:52 <mps> no, np, everything is ok
2021-01-23 14:02:51 <mps> I didn't finished yet, and intend to create late at this night
2021-01-23 14:03:06 <mps> to not block other works
2021-01-23 14:05:52 <ikke> Nice, x86_64 host is alpine 3.13 now, with the 3.12 kernel
2021-01-23 14:06:36 <mps> CI or builder
2021-01-23 14:06:41 <ikke> CI
2021-01-23 14:06:48 <ikke> the one I had issues with last week
2021-01-23 14:07:18 <mps> aha, kernel still make problem with lvm
2021-01-23 14:07:29 <ikke> I think so
2021-01-23 14:07:45 <ikke> This at least proves it's somehow related to the kernel
2021-01-23 14:07:54 <ikke> 3.12 with 3.13 kernel -> problem
2021-01-23 14:08:02 <ikke> 3.13 with 3.12 kernel -> no problem
2021-01-23 14:08:28 <ikke> I haven't tried 5.10.9 yet though
2021-01-23 14:09:21 <mps> I saw some fixes for nvme in 5.10.9, though not sure will it fix problem you encountered
2021-01-23 14:10:20 <ikke> I could try 5.10.9
2021-01-23 14:11:31 <mps> I missed to see, did ncopa upgraded -lts to 5.10.9
2021-01-23 14:11:45 <ikke> only on edge
2021-01-23 14:11:49 <ikke> but yes
2021-01-23 14:12:43 <mps> uhm, this reminds me that linux-tools 'must be upgraded' :) for 3.13
2021-01-23 14:12:44 <ikke> 3.13 is on 5.10.7
2021-01-23 14:13:18 <mps> hope will not forget tomorrow
2021-01-23 14:21:06 <ikke> 5.10.9 does not work either
2021-01-23 14:24:28 <mps> in about month we will have 5.11.x :)
2021-01-23 14:24:40 <adhawkins> Ok, I've made some changes on one of the packages. Appreciate it if someone can give it a quick look over? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17352
2021-01-23 14:25:03 <mps> !17352
2021-01-23 14:25:12 <adhawkins> Whoops, Forgot to update the package version.
2021-01-23 14:26:15 <adhawkins> Ok, all done hopefully.
2021-01-23 14:26:55 <mps> looking now, all this could be in one commit
2021-01-23 14:26:57 <ikke> adhawkins: our commit subjects (first line) are lower case
2021-01-23 14:27:38 <mps> and should be 'upgrade to $version'
2021-01-23 14:28:13 <mps> adhawkins: can I advice you to read COMMITSTYLE.ml
2021-01-23 14:28:23 <adhawkins> The source package version hasn't changed. This is just changes to the packaging.
2021-01-23 14:29:06 <mps> then it is pkgrel
2021-01-23 14:29:40 <mps> usually 'bump pkgrel to $reason'
2021-01-23 14:30:40 <mps> and as ikke say, lower cases
2021-01-23 14:30:44 <adhawkins> There are a number of small changes in that change set. I've changed all the commit messages.
2021-01-23 14:32:12 <mps> (huh, time to consider BSD, but I know conclusion already)
2021-01-23 14:32:42 <mps> alpine is not good but other alternatives are worse
2021-01-23 14:33:32 <mps> as everything in life, always choose less worse
2021-01-23 14:34:23 <ikke> mps: where is that a reaction to?
2021-01-23 14:34:54 <mps> ikke: to what? I don't follow
2021-01-23 14:35:25 <ikke> "(time to consider BSD .."
2021-01-23 14:35:45 <adhawkins> mps: The reason I split it across a number of commits was to avoid a commit message that said "Do this, and this, and this, and this"
2021-01-23 14:35:59 <ikke> that's good
2021-01-23 14:36:07 <adhawkins> If it's preferable as a single commit I can squash them? Discussion earlier suggested that individual commits were acceptable
2021-01-23 14:36:17 <ikke> But we do not require every change to be summarized in the commit message
2021-01-23 14:36:28 <ikke> Yeah, it's somewhat a trade-off
2021-01-23 14:36:45 <adhawkins> ikke: Oh, I thought that was the point of the commit message?
2021-01-23 14:37:03 <ikke> adhawkins: the commit message tells you mostly why a certain change is done
2021-01-23 14:37:10 <ikke> adhawkins: what is changed can be seen in the diff
2021-01-23 14:37:46 <adhawkins> So would something like "correct licence text and consolidate packaging changes" be the way to go?
2021-01-23 14:37:52 <adhawkins> Or just "correct licence text"?|
2021-01-23 14:38:18 <ikke> correct license field
2021-01-23 14:38:28 <adhawkins> And not mention the other changes?
2021-01-23 14:39:06 <mps> ikke: BSD is (nowadays called) meme when I'm irritated with linux distros
2021-01-23 14:39:36 <ikke> entioning incrementing pkgrel, unless there is an explicit reason (say, to make sure it's rebuilt against a new lib), is not necessary
2021-01-23 14:39:40 <ikke> mentioning
2021-01-23 14:39:53 <adhawkins> Ok. I'll squash them all up into a single commit then
2021-01-23 14:40:17 <ikke> I think this could be a separate commit still: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17352/diffs?commit_id=ba40b07aea827c9204841060b1472a8718179169
2021-01-23 14:41:06 <adhawkins> Why that one in particular ikke?
2021-01-23 14:41:44 <ikke> Because it might not be immediately obvious to others why it's done
2021-01-23 14:41:50 <adhawkins> Ok.
2021-01-23 14:42:39 <adhawkins> Ok, updated. How does that look?
2021-01-23 14:43:09 <ikke> fine for me
2021-01-23 14:43:23 <ikke> x86_64 CI host is back
2021-01-23 14:44:12 <adhawkins> That's great ikke. Will wait and see if it gets merged and then repeat the process with the other packages I created yesterday
2021-01-23 14:44:57 <ikke> it seems to fail on ppc64le / s390x
2021-01-23 14:45:15 <ikke> py3-inform being unavailable
2021-01-23 14:46:10 <adhawkins> Could that be because it hasn't been build from when I added it yesterday?
2021-01-23 14:46:50 <ikke> yes, those builders are stuck on other packages
2021-01-23 14:47:07 <adhawkins> Ah ok. So will it retry the build if I don't make any changes?
2021-01-23 14:47:25 <ikke> yes, it will be built eventually
2021-01-23 14:48:00 <adhawkins> Ok.
2021-01-23 14:48:54 <adhawkins> ppc64le is the same it would appear.
2021-01-23 14:49:15 <adhawkins> Is there any point me proceeding with similar changes to the other packages?
2021-01-23 14:49:30 <ikke> sure
2021-01-23 14:49:40 <adhawkins> Ok. I'll continue then. Thanks for the help.
2021-01-23 15:01:14 <adhawkins> Same thing for one of the other packages. If this one looks Ok I'll proceed with the others in the same way: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17353
2021-01-23 15:05:10 <mps> when I started to 'contribute' I read some different pkgs and read git log to get idea how should I work, I called that 'learning from masters'
2021-01-23 15:05:36 <adhawkins> That's a good idea mps. I'll have a dig around.
2021-01-23 15:05:55 <adhawkins> That latest one is failing the same two builds for a similar reason (one of the new packages I did yesterday not found)
2021-01-23 15:09:16 <mps> before pushing anything that is not simple upgrade to aports I usually build pkg on local builders (and different arches) even install and test locally
2021-01-23 15:10:00 <mps> call me 'too conservative' but I'm ok with this
2021-01-23 15:10:06 <adhawkins> These should be fairly simple. I am building locally on a single arch, I think the only reason for the issue is that I've done it before all the 'new' packages are fully built from yesterday.
2021-01-23 15:10:23 <adhawkins> How would I go about building on different arches out of interest?
2021-01-23 15:10:34 <mps> adhawkins: np, we all make mistakes
2021-01-23 15:10:39 <adhawkins> I did test locally before doing yesterday's merge request.
2021-01-23 15:12:30 <mps> believe or not, but I have pkgs in my local repo old more than 2 years and I use them daily but still didn't pushed
2021-01-23 15:13:13 <adhawkins> Yeah, I did consider that mps. But I figured if they were useful to me they were probably useful to others. The driving force was emborg, the other packages are its dependencies that weren't already packaged.
2021-01-23 15:13:50 <ikke> adhawkins: we have our CI to build it on multiple arches
2021-01-23 15:14:09 <mps> adhawkins: I didn't wanted to say anything against your effort and pkgs
2021-01-23 15:14:24 <adhawkins> Yeah, but that only comes in to place when I actually submit the MR. If I could short circuit that by testing myself I'd be happy to do that.
2021-01-23 15:14:55 <ikke> adhawkins: It's not wrong to do, but we do not expect everyone to test things on every arch (which would be unreasonable)
2021-01-23 15:14:57 <adhawkins> No offence taken mps. Appreciate I'm new at this (hadn't even considered making a new package until someone suggested it when I asked someone to package emborg!), so happy to elicit advice.
2021-01-23 15:15:15 <mps> just grumbling old Jon Postels robustness principle
2021-01-23 15:15:43 <ikke> adhawkins: And we're always happy to guide new users to do this
2021-01-23 15:15:53 <adhawkins> I've noticed :)
2021-01-23 15:16:50 <mps> some of expect that newcomers are willing to learn, but this is not addressed to adhawkins :)
2021-01-23 15:16:57 <mps> of us*
2021-01-23 15:17:33 <adhawkins> Thanks mps. WIll leave those two MRs for now. Might do the rest tomorrow. Thanks again both.
2021-01-23 15:18:26 <mps> adhawkins: all good and no worries, I see you as perspective contributor/developer
2021-01-23 15:19:12 <mps> you are not trying to impose your POVs
2021-01-23 15:26:09 <adhawkins> Far too new for that mps!
2021-01-23 15:28:11 <mps> adhawkins: when I started to use alpine and fix bugs, help other users, and even made some pkgs I never thought that I will be developer
2021-01-23 15:28:51 <mps> even didn't had any intention to become one, but life doesn't ask us what will happen :)
2021-01-23 15:29:29 <mps> and I still wonder why I'm developer
2021-01-23 15:31:30 <mps> (probably because I'm babbling much)
2021-01-23 15:43:16 <adhawkins> I don't know if I can commit that amount of time, and I'm not a serious enough alpine user to motivate me enough. I only use it as the basis of an emborg container I put together, so I thought I'd try to package emborg up to make the container a little more self-contained.
2021-01-23 15:50:05 <timlegge> if I was looking for a default python build check package template for an update apkbuild-pypi would one from one of the new py3 package be fine
2021-01-23 15:51:56 <mps> is it possible to cherry-pick pkg from edge to stable (3.13-stable for example)
2021-01-23 15:54:38 <timlegge> I've cherry picked from completely different repos before
2021-01-23 16:06:53 <ikke> mps: is that a question?
2021-01-23 16:08:52 <mps> ikke: nvm, I done it 'by hand' !17355
2021-01-23 16:09:18 <ikke> mps: ok, but it is possible to cherry-pick, given that there have not been too many changes
2021-01-23 16:10:22 <mps> yes, but looks like complicated and risky (for us not expert with git)
2021-01-23 16:11:10 <ikke> mps: you can try, if it runs into conflicts, just abort
2021-01-23 16:13:13 <mps> that is point after which I asked here :)
2021-01-23 16:14:21 <mps> now I need about 8 hours for MR, how to set it?
2021-01-23 16:15:05 <ikke> settings CI/CD on your fork
2021-01-23 16:15:24 <ikke> General Pipelines section
2021-01-23 16:17:22 <mps> ikke: thanks, found it, 10h is ok?
2021-01-23 16:17:41 <ikke> sure
2021-01-23 16:17:51 <mps> this is complete cross-embedded tools
2021-01-23 16:18:02 <mps> that needs time
2021-01-23 16:40:31 <mps> ikke: 5.10.10 kernel is released but no mentions of nvme
2021-01-23 16:41:50 <Hello71> there's that nvme power saving thing, but i don't think that's a new-kernel thing
2021-01-23 16:42:18 <Hello71> https://wiki.archlinux.org/index.php/Solid_state_drive/NVMe#Controller_failure_due_to_broken_APST_support
2021-01-23 16:42:36 <ikke> Hello71: mps is referring to the issue we have with 5.10 not finding our lvm volumes on boot
2021-01-23 16:42:39 <Hello71> yeah
2021-01-23 16:46:03 <mps> I can't tell, ikke knows does this is related to issue he had
2021-01-23 16:46:25 <ikke> I'm not sure it's even related to nvme
2021-01-23 19:17:28 <mps> #12329
2021-01-23 19:17:40 <mps> 3.11 is also fixed
2021-01-23 19:18:23 <ikke> updated
2021-01-23 19:18:29 <ikke> 3.10 not yet?
2021-01-23 19:18:40 <mps> and !17318 wait for 3.10
2021-01-23 19:19:06 <ikke> any reason not to merge?
2021-01-23 19:19:39 <mps> no, except I'm not behind machine with my keys from which I can merge
2021-01-23 19:20:00 <ikke> ok, I can merge it
2021-01-23 19:20:17 <mps> will be in a hour or two if someone doesn't merge in meantime :)
2021-01-23 19:21:15 <ikke> done
2021-01-23 19:21:50 <mps> checksum failed on armv7
2021-01-23 19:22:12 <mps> curl: (22) The requested URL returned error: 404
2021-01-23 19:27:27 <mps> ikke: also #12238 not that I ignore you but I don't know what I can tell about it
2021-01-23 19:27:54 <mps> reporter didn't persuaded me that this change is needed
2021-01-23 19:28:42 <mps> and I don't like to fall in trap 'whatever users ask we have to obey'
2021-01-23 19:29:48 <ikke> right, but it seems like they need it for their hardware to properly work?
2021-01-23 19:31:14 <mps> looks like it is true, but there is no 'strong or any' evidence that can't be done with initramfs
2021-01-23 19:31:31 <mps> or maybe modloop is problem, idk
2021-01-23 19:31:48 <ikke> ok, maybe suggest that in the issue?
2021-01-23 19:31:52 <mps> user didn't reported how it use machine with alpine
2021-01-23 19:32:25 <mps> 'it' is s/he
2021-01-23 19:33:10 <ikke> That's why I use they
2021-01-23 19:33:50 <mps> I use linux on few chromebook and never need such options 'in kernel', they works nice as modules
2021-01-23 19:35:10 <mps> well, 'they' to me sounds 'few of them' while 'it' is singular and better fit in my brain wiring
2021-01-23 19:35:37 <mps> but 's/he' is best
2021-01-23 19:35:41 <ikke> in english, it refers to things
2021-01-23 19:36:30 <mps> yes, but I don't think in english (and I can't), I always have to translate in head
2021-01-23 19:37:03 <ikke> using 'it' for people in english is considered quite rude
2021-01-23 19:37:11 <mps> huh
2021-01-23 19:37:38 <mps> english should be fixed then :P
2021-01-23 19:38:24 <ikke> 'a person or animal whose sex is unknown or disregarded', emphasis on the last word
2021-01-23 19:39:04 <mps> huh (again)
2021-01-23 19:39:15 <ikke> language is weird
2021-01-23 19:39:38 <mps> better to use '...' in such cases
2021-01-23 19:40:12 <mps> or simple '?', or $somevar
2021-01-23 19:40:38 <jvoisin> "they" is ok
2021-01-23 19:40:50 <mps> but I think I'm not right person to fix these problems, ignore me
2021-01-23 19:41:05 <ikke> yeah, 'they' has traction
2021-01-23 19:41:13 <ikke> but it's also ambiguous
2021-01-23 19:41:23 <mps> hah
2021-01-23 19:41:57 <ikke> lol that sentence was unintentionally ambiguous as well
2021-01-23 19:59:17 <maxice8> English is fun
2021-01-23 20:00:43 <ikke> It certainly is
2021-01-23 20:01:59 <maxice8> They certainly is
2021-01-23 20:02:11 <mps> :D
2021-01-23 20:04:23 <mps> I sorry we don't use some of old (not used as living lang) langs like latin or sanskrit for communications
2021-01-23 20:05:56 <maxice8> Binary esperanto for all AL documentation
2021-01-23 20:06:35 <mps> uh no, esperanto is 'constructed' and as such not good
2021-01-23 20:09:02 <mps> latin and sanskrit are rich in grammar and expressing thoughts, maybe old greek also but I don't know much about it/they :)
2021-01-23 20:09:04 <opal> rms suggests perse :^)
2021-01-23 20:09:16 <opal> nah i use they/them too
2021-01-23 20:09:39 <opal> most people understand, the people who think its awkward are just pedants ime
2021-01-23 20:10:18 <maxice8> Lisp so one can communicate with the machine spirit
2021-01-23 20:10:31 <mps> maxice8: :)
2021-01-23 20:10:36 <opal> gendered language sucks and it sucks we have to live with the assumptions it made in the modern information era, where we cant be sure of an object's gender as well as we may used to be
2021-01-23 20:11:01 <opal> i awkwardly worded that but you get the idea
2021-01-23 20:11:16 <mps> opal: yes, and bad one
2021-01-23 20:11:44 <ikke> myabe we should take this to #-offtopic
2021-01-23 20:11:51 <maxice8> Yes
2021-01-23 20:12:18 <opal> too many offtopic channels
2021-01-23 20:12:44 <ikke> heh
2021-01-23 20:32:40 <mps> https://gitlab.alpinelinux.org/mps/aports/-/jobs/302742#L384
2021-01-23 20:32:51 <mps> limit in bytes
2021-01-23 20:34:50 <ikke> hmm
2021-01-23 20:38:24 <ikke> it's a runner limit
2021-01-23 20:39:27 <mps> can it be increased?
2021-01-23 20:39:46 <mps> s/it/they/
2021-01-23 20:39:46 <alpine-meetbot> mps meant to say: can they be increased?
2021-01-23 20:39:52 <ikke> lol
2021-01-23 20:41:10 <ikke> mps: any idea how big the logs are? it's already 4M
2021-01-23 20:42:11 <mps> huh, no
2021-01-23 20:42:41 <mps> I only know that I built in all previous night in devs lxc
2021-01-23 20:43:12 <ikke> oh, we even have it set to 10M
2021-01-23 20:43:15 <mps> and log is 'big big big' I think
2021-01-23 20:43:48 <mps> maybe I should split MR to 5
2021-01-23 20:44:03 <mps> and do one by one
2021-01-23 20:44:14 <ikke> sorry, it's in kb, it's 100M
2021-01-23 20:44:44 <ikke> 104857659 this is the log size of that job
2021-01-23 20:44:55 <mps> yes
2021-01-23 20:45:09 <ikke> 100M of logs..
2021-01-23 20:45:21 <mps> but easy, this is not important much
2021-01-23 20:45:54 <mps> will consider to split it
2021-01-23 21:11:19 <yZ5vlALg86lP> wow. finally the "original" at&t ksh93 builds with musl! https://github.com/ksh93/ksh.git
2021-01-23 21:11:40 <yZ5vlALg86lP> i just managed to build it on alpine!
2021-01-23 21:11:50 <yZ5vlALg86lP> been dreaming about this for years
2021-01-23 21:21:43 <timlegge> adhawkins: if you are still adding python packagege you may want to try apkbuild-pypi again from https://gitlab.alpinelinux.org/timlegge/abuild/-/tree/apkbuild-pypi let me know if you need more changes
2021-01-23 21:41:11 <adhawkins> I might do that timlegge. Thanks
2021-01-23 21:55:21 <mps> just pushed new testing/linux-gru for all of you who have gru-kevin chromebook. enjoy and report bugs or fixes
2021-01-23 22:28:36 <adhawkins> Since I created my couple of MRs earlier, master has moved on, so it says they need rebasing on GitLab. Do I need to keep rebasing them as master changes, or isn't this necessary?
2021-01-23 22:32:20 <mps> adhawkins: it could be rebased before merge, not needed before that, usually
2021-01-23 23:03:45 <Hello71> algitbot needs to be fixed to not do https://gitlab.alpinelinux.org/users/root/activity. seems like out of top 20, more than half are waiting on maintainer
2021-01-23 23:03:51 <Hello71> not submitter
2021-01-23 23:14:59 <adhawkins> mps So I don't need to keep rebasing the MR branch until it's actually merged?
2021-01-23 23:15:08 <maxice8> no
2021-01-23 23:15:29 <maxice8> aports-qa-bot automatically enables collaboration on all MRs so developers can rebase and then merge
2021-01-23 23:15:34 <adhawkins> Ok. So whoever actually merges it will.do that at the point of merging?
2021-01-23 23:15:52 <maxice8> yes
2021-01-23 23:15:58 <adhawkins> Ok, understood
2021-01-23 23:16:06 <maxice8> rebasing is only necessary if there are conflicts that cannot be resolved automatically
2021-01-23 23:17:13 <adhawkins> One other thing, there's.been a comment on the rkm-code MR about the name of the downloaded file. Do these need to follow a particular convention? I've changed the URL so that GitHub provides what I think is an appropriately named file.
2021-01-23 23:18:48 <maxice8> if that is the case then feel free to ignore it
2021-01-23 23:19:12 <adhawkins> rkm_codes-v0.5.tar.gz in this instance
2021-01-23 23:20:12 <maxice8> yeah that is a good name, some GitHub urls return only v0.5.tar.gz
2021-01-23 23:20:17 <maxice8> which can conflict with other sources
2021-01-23 23:22:14 <adhawkins> source="https://github.com/KenKundert/rkm_codes/archive/v$pkgver/rkm_codes-v$pkgver.tar.gz"
2021-01-23 23:23:26 <adhawkins> Ok. How best.to 'ignore' that comment in the MR so it doesn't look like there's more work to do?
2021-01-23 23:24:24 <adhawkins> Should I just resolve that thread in the MR?
2021-01-24 00:33:06 <timlegge> adhawkins: I usually do 'git fetch upstream' and 'git rebase upstream/master' before I push to my origin and create a MR
2021-01-24 00:34:35 <timlegge> most of the time  I tend to create a branch just for the package I am working on that way any MRs are seperate (unless the packages are related)
2021-01-24 07:49:00 <ikke> https://pip.pypa.io/en/stable/news/#id1
2021-01-24 07:49:07 <ikke> pip dropped support for python2
2021-01-24 07:49:25 <maxice8> oh nice
2021-01-24 08:28:44 <mps> adhawkins: #12337 could be closed as 'fixed'?
2021-01-24 08:29:33 <mps> nice day will be when I see 'git rm py*' :)
2021-01-24 08:30:21 <ikke> at the same day we will do git rm perl* :P
2021-01-24 08:30:50 <mps> if we do this then we must do 'git rm *' ;P
2021-01-24 08:32:06 <mps> btw, I closed this big cross-embedded MR
2021-01-24 08:32:12 <ikke> ok
2021-01-24 08:33:11 <mps> do you delete artifact for such big and bad things by hand or wait till they expire
2021-01-24 08:33:50 <mps> if they take disk you can delete them manually right now, they are not needed
2021-01-24 08:34:36 <mps> (going to make big coffee, didn't slept well)
2021-01-24 08:37:20 <ikke> We just let it expire
2021-01-24 08:40:03 <mps> ok
2021-01-24 08:53:39 <mps> looking at dovecot for 3.11-stable, only sane option is to upgrade to latest stable release, i.e. 2.3.13
2021-01-24 08:54:28 <mps> and we should use stone and write on it that for 'important' pkgs we 'must' use only lts versions
2021-01-24 09:28:34 <ikke> Yes
2021-01-24 09:29:13 <ikke> There was some suggestion for per package version policies
2021-01-24 10:08:41 <adhawkins> mps Yes it could. I could probably have done that through the commit message?
2021-01-24 10:09:29 <adhawkins> Have another 4 or 5 packages to fix like the two I did yesterday. Can they be done in one MR, or do I need to keep them split?
2021-01-24 10:10:05 <mps> adhawkins: yes. with 'fixes: #12337' in one of lines in commit msg
2021-01-24 10:38:30 <adhawkins> Thanks mps. How about doing multiple changes like yesterday in a single MR? Is that the done thing, or should I split them?
2021-01-24 10:39:15 <ikke> If they are unrelated, separate MRs are better
2021-01-24 10:39:49 <ikke> Then one does not have to block the other
2021-01-24 10:54:01 <adhawkins> Understood ikke. I'll continue using that scheme then.
2021-01-24 10:59:35 <adhawkins> What's the difference between a package in 'community' and 'main'? The community repo doesn't get enabled by default during an install does it? What's the procedure for getting in to 'main'?
2021-01-24 11:00:02 <ikke> Difference is how long we support packages
2021-01-24 11:00:36 <ikke> Main receives support for 2 years, community only 6 months
2021-01-24 11:00:57 <nmeum> community is basically only supported for the latest -stable release
2021-01-24 11:01:20 <adhawkins> Ah ok. So what qualifies a package to move to 'main'?
2021-01-24 11:02:27 <nmeum> i think we don't have an "offical policy" on this but if we can't support it for two years it doesn't go into main think complex software like webbrowser et cetera
2021-01-24 11:03:36 <ikke> It also depends a bit on how implortant the package is for a base system
2021-01-24 11:03:51 <ikke> Important*
2021-01-24 11:04:22 <adhawkins> Ok, understood.
2021-01-24 11:04:49 <adhawkins> Is 'community' enabled by default? It is on my installation, but can't remember if I changed that.
2021-01-24 11:05:19 <ikke> Not by default on installations you install wit setup-alpine
2021-01-24 11:06:17 <nmeum> we should probably add a "do you want to enable the community repository? [y/n]" dialog to alpine-conf at some point
2021-01-24 11:06:58 <adhawkins> Yeah, that might be an idea. If there's a lot of 'useful' stuff in community it'd be nice if it were more discoverable.
2021-01-24 11:07:43 <nmeum> yep, every now and then people also open issues in the bug tracker because they are lacking a package which is actually available but only in community/
2021-01-24 11:11:10 <ikke> It should also make the differences between these repositories clear
2021-01-24 11:13:00 <adhawkins> It may well already be covered on the website somewhere, I have to admit I didn't look :)
2021-01-24 11:19:16 <adhawkins> I've just set my IRC client to highlight my nme in #alpine-commits. Is it Ok to post a quick 'test' message in there to see if it works?
2021-01-24 11:19:43 <Cogitri> Sure
2021-01-24 11:20:00 <adhawkins> Hmm, might not work if I make the post I guess...
2021-01-24 11:20:12 <adhawkins> Oh well, I'll just wait and see when my name next comes up :)
2021-01-24 11:20:36 <ikke> adhawkins: I just mentioned your name
2021-01-24 11:20:36 <adhawkins> Yep, worked. Thanks ikke :)
2021-01-24 11:21:05 <adhawkins> Yep, highlight worked. That'll help pick out when my changes are merged and built.
2021-01-24 11:42:36 <mps> enabling repos are described in installation wiki pages
2021-01-24 11:48:19 <mps> and move pkg to main should be done when it is *really* necessary
2021-01-24 11:49:12 <adhawkins> Ok, I understand. As nmeum said earlier, having a step in the installer asking whether they want to enable Community (and why it's probably a good idea) would be useful I think.
2021-01-24 11:49:51 <mps> yes, till someone ask why it is not enabled by default
2021-01-24 11:51:31 <adhawkins> Well, that's a different question I guess. But bringing it to people's attention at install time would be good, otherwise they may not even know it exists, and wonder why they can't get at a lot of packages.
2021-01-24 11:52:54 <mps> make splash screen with complete wiki and docs.a.o for setup-alpine :)
2021-01-24 11:56:14 <adhawkins> Think I need to look into some docker based build system moving forward. I'll add that to my todo list.
2021-01-24 12:01:56 <PureTryOut[m]2> About splash screens, has anyone ever gotten Plymouth to work on Alpine? There is a package for it, but no instructions on how to enable it at all anywhere
2021-01-24 12:02:01 <PureTryOut[m]2> I doubt mkinitfs has support for it?
2021-01-24 12:02:21 <nmeum> there is support for splashscreens in mkinitfs
2021-01-24 12:02:24 <nmeum> through busybox fbsplash
2021-01-24 12:03:05 <nmeum> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in#L646-662
2021-01-24 12:03:07 <PureTryOut[m]2> Not with Plymouth though?
2021-01-24 12:03:18 <PureTryOut[m]2> As I want Plymouth, not fbsplash
2021-01-24 12:03:27 <nmeum> I don't think so
2021-01-24 12:04:39 <mps> 'use win/macos Luke'
2021-01-24 12:07:03 <mps> never could understand why people wants (and pays for them) useless things
2021-01-24 12:10:04 <artok> some useless things are for mental health
2021-01-24 12:10:16 <mps> :D
2021-01-24 12:10:36 <artok> that is, rendering them useful =)
2021-01-24 12:11:38 <artok> totally useless to have dynamic motd that outputs ansi colorcoded ascii graphics, but still I've done it on each of my linux boxes =)
2021-01-24 12:12:23 <mps> for mental health a glass of red wine is better (a lot) ;)
2021-01-24 12:14:09 <artok> sure, but watching that ansi graphics while drinking red wine just makes nostalgic feeling, like being back in 90's BBS
2021-01-24 12:14:45 <artok> and without non-free brcm firmware, ssh into rpi4 feels like that 2400bps modem anyway =D
2021-01-24 12:15:32 <mps> artok: I fully understand you, even forgot that BBS existed. thanks for reminding me
2021-01-24 12:17:27 <mps> my first bought modem was 2400bps, before that I had two made myself, 300bps and 1200bps
2021-01-24 12:20:29 <adhawkins> Anyone here use dabuild? How to pass '-r' to the build in the container? It's failing saying the dependencies aren't available
2021-01-24 12:20:58 <adhawkins> https://termbin.com/cp6y
2021-01-24 12:22:23 <adhawkins> Ah, as simple as running 'dabuild -r' :)
2021-01-24 12:25:48 <Hello71> mps: bad for physical health though, increases cancer risk
2021-01-24 12:26:51 <mps> Hello71: what is bad?
2021-01-24 12:26:58 <mps> modems? ;P
2021-01-24 12:27:02 <Hello71> alcoholic begerages
2021-01-24 12:27:24 <Hello71> possibly modems are bad for mental health nowadays but depends on personality
2021-01-24 12:29:02 <mps> actually life is bad for health, increases cancer risk :)
2021-01-24 12:29:49 <mps> and no, wine is good for health, ime
2021-01-24 12:30:42 <mps> I use it as only medicine and didn't had to go to doctor/medic for more than 20 years
2021-01-24 12:31:30 <mps> but, everyone is free to have its religion
2021-01-24 12:34:52 <adhawkins> Well, getting dabuild running was easy enough!
2021-01-24 12:42:17 <jvoisin> → #-offtopic
2021-01-24 12:43:34 <mps> jvoisin: wine is never OT :)
2021-01-24 13:27:15 <ikke> oxygen also increases cancer risk :P
2021-01-24 13:28:43 <mps> huh, what is this!? https://gitlab.alpinelinux.org/mps/aports/-/jobs/303367#L21
2021-01-24 13:29:27 <ikke> shellcheck output?
2021-01-24 13:29:37 <mps> please remove this obscene wording
2021-01-24 13:30:03 <mps> 'Names commonly chosen instead of 'master' are 'main', 'trunk' and....'
2021-01-24 13:30:13 <ikke> aha,
2021-01-24 13:30:15 <ikke> that's git itself
2021-01-24 13:30:28 <ikke> latest version of git
2021-01-24 13:30:31 <mps> kill the git
2021-01-24 13:30:39 <mps> :)
2021-01-24 13:31:00 <ikke> we'll just add init.defaultBranchname=master to the global git config
2021-01-24 13:31:42 <mps> yes, I know and that is last corner of 'sane' world. Thanks ikke
2021-01-24 13:44:51 <ikke> TBK[m]: Could you try to refork apkbuild-lint-tools to see if you inherrit the image builders now?
2021-01-24 13:49:42 <TBK[m]> ikke: I deleted, reforked and manually ran a job - https://gitlab.alpinelinux.org/TBK/apkbuild-lint-tools/-/pipelines
2021-01-24 13:49:42 <TBK[m]> status: stuck
2021-01-24 13:50:17 <mps> ikke: pushed latest in list for #12274
2021-01-24 13:50:35 <ikke> TBK[m]: ok, anoying
2021-01-24 13:50:39 <mps> huh, merged :)
2021-01-24 13:50:56 <ikke> TBK[m]: the image builder runners are intentionally limited to the alpine/infra/docker group
2021-01-24 13:51:07 <ikke> But I read somewhere that forks should still inherrit them
2021-01-24 13:52:20 <TBK[m]> k, I will research it tonight when I got some time.
2021-01-24 13:54:13 <ikke> "Whenever a project is forked, it copies the settings of the jobs that relate to it. This means that if you have shared Runners set up for a project and someone forks that project, the shared Runners will also serve jobs of this project."
2021-01-24 13:54:24 <ikke> only talks about shared runners, but they should be available anyway
2021-01-24 13:56:36 <ikke> `https://gitlab.com/groups/gitlab-org/-/epics/3278
2021-01-24 14:34:41 <mps> timlegge: when you find some time please help me with !16549 it works in lxc but fails on CIs, probably tty related but I'm not sure
2021-01-24 14:39:11 <timlegge> mps just glanced on my phone.  can look closer later today or tonight AST
2021-01-24 14:41:32 <ikke> yeah, most likely the lack of tty
2021-01-24 14:43:53 <Hello71> try running in "script"?
2021-01-24 14:46:12 <mps> timlegge: np, when you find time, we are not in a hurry, so easy
2021-01-24 14:54:02 <adhawkins> Hi all. Working through updating my packages the same as the couple I did yesterday. First one is !17385
2021-01-24 15:01:08 <adhawkins> !17386
2021-01-24 15:05:25 <adhawkins> !17387
2021-01-24 15:08:22 <timlegge> mps: looks related to https://rt.cpan.org/Public/Bug/Display.html?id=128806#txn-1838418 can be reproduced locally with export set TERM=""
2021-01-24 15:08:47 <timlegge> looks like the builders might not have a TERM set properly in the ENV
2021-01-24 15:09:05 <ikke> There is no TERM
2021-01-24 15:09:10 <ikke> and no term either :)
2021-01-24 15:09:34 <ikke> On the builders, these builds are triggered by cron
2021-01-24 15:10:52 <ikke> on CI, they are run on docker containers, also without controlling TTY
2021-01-24 15:11:33 <adhawkins> !17388
2021-01-24 15:13:03 <mps> timlegge: interesting. it passed CIs in previous version without problem and now don't. that is what confuses me
2021-01-24 15:13:27 <ikke> maybe new tests were added?
2021-01-24 15:13:46 <mps> ikke: this is probable reason
2021-01-24 15:14:19 <mps> so solution is simple "!check" :)
2021-01-24 15:14:33 <ikke> so either disable these tests, or find a workaround (like Hello71 suggested with `script`)
2021-01-24 15:15:10 <mps> I didn't understood what Hello71 means by 'script'
2021-01-24 15:15:38 <ikke> script provides stdin/stdout for commands that run under it
2021-01-24 15:15:52 <ikke> https://stackoverflow.com/questions/32910661/pretend-to-be-a-tty-in-bash-for-any-command
2021-01-24 15:17:03 <mps> reading....
2021-01-24 15:17:12 <adhawkins> !17389
2021-01-24 15:20:35 <adhawkins> Once they're all merged I'll thoroughly test locally and then move to community.
2021-01-24 15:25:13 <adhawkins> When I move emborg and all its new dependencies from testing to community, this will be a single MR, but should it be a commit per package, or one commit for them all?
2021-01-24 16:16:43 <ikke> one commit per package
2021-01-24 16:17:56 <timlegge> mps ikke so 1.37 made a change to make it work better for automated testers like cpantesters seems to have failed for alpine builder.  I can look closer
2021-01-24 16:19:13 <mps> timlegge: thanks
2021-01-24 16:21:21 <adhawkins> Thanks ikke, will do. Just need to wait for those other MRs to complete then will get it done.
2021-01-24 16:56:45 <DylanVanAssche_> Is it possible to use the Alpine Linux builders or Gitlab CI to build a package?
2021-01-24 16:56:45 <DylanVanAssche_> I want to apply a patch to the `linux-rpi` package but building it locally on my hardware is a bit hard in terms of resources and arch ...
2021-01-24 16:57:17 <ikke> DylanVanAssche_: You can submit an (draft) MR to test the build
2021-01-24 16:57:41 <Hello71> but generally it is preferred to reserve builders for changes which you actually want to put in alpine
2021-01-24 16:57:52 <ikke> right
2021-01-24 16:57:58 <Hello71> if it is a personal patch you can set up cross compile
2021-01-24 16:58:34 <DylanVanAssche_> Yes, at some point I want to land them in Alpine, or even better: upstream the patch to the Linux kernel.
2021-01-24 16:58:34 <DylanVanAssche_> However, before I do, I need to be able to test the patch 🙂
2021-01-24 16:59:09 <DylanVanAssche_> With a MR, is there a way to extract the `.apk` file from the CI?
2021-01-24 16:59:20 <ikke> yes
2021-01-24 16:59:30 <ikke> it will be available as artifact
2021-01-24 16:59:59 <DylanVanAssche_> Ah okay, great! Thanks!
2021-01-24 17:04:56 <yZ5vlALg86lP> DylanVanAssche_: it is totally possible, on github you can do that. check out https://github.com/jirutka/user-aports jirutka uses ci for building his packages
2021-01-24 17:05:22 <yZ5vlALg86lP> only problem is that there is a timelimit for ci jobs, and if your build does not finish in time, it's lost entirely.
2021-01-24 17:05:49 <yZ5vlALg86lP> i do the same, but i actually ran into this time limit issue on my repo
2021-01-24 17:06:18 <DylanVanAssche_> It's a Linux kernel so I may hit the time limit as welll
2021-01-24 17:06:20 <ikke> apparently jirutka uses travis-ci, which is quite troublesome to use nowadays
2021-01-24 17:06:30 <jvoisin> this might sound petty, but what shall I do to get https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/16784 merged?
2021-01-24 17:06:53 <maxice8> Nothing really
2021-01-24 17:07:03 <maxice8> I don't get notifications when someone approves the merge request
2021-01-24 17:07:11 <maxice8> so it can be missed entirely
2021-01-24 17:07:50 <jvoisin> is coming on irc to ping op acceptable?
2021-01-24 17:07:58 <ikke> sure
2021-01-24 17:08:02 <maxice8> Yes
2021-01-24 17:08:10 <ikke> as long as it's reasonable
2021-01-24 17:08:29 <jvoisin> ok, thanks
2021-01-24 17:09:21 <mps> !16784
2021-01-24 17:09:56 <mps> this is good MR, remove deps is always good
2021-01-24 17:10:25 <ikke> unless we then get spammed by users about breaking their setup :)
2021-01-24 17:10:38 <ikke> but, alas
2021-01-24 17:10:45 <jvoisin> I'll be happy to handle the spam due to this MR
2021-01-24 17:11:17 <maxice8> jvoisin: one thing, you can use keywords `closes` or `fixes` following by #issuenum and GitLab will automatically close the issue when the commit is accepted
2021-01-24 17:11:38 <jvoisin> oh, right
2021-01-24 17:11:39 <mps> ikke: who cares if the patch is good
2021-01-24 17:11:41 <ikke> liborcus tests on mips64 fails due to this: "what():  boost::filesystem::status: Function not implemented: "../../test/css/invalids/1.css""
2021-01-24 17:12:15 <ikke> maxice8: aren't they present?
2021-01-24 17:13:28 <maxice8> ?
2021-01-24 17:14:17 <ikke> I see "
2021-01-24 17:14:20 <ikke> closes #12284
2021-01-24 17:14:25 <ikke> both in the commit message as in the description
2021-01-24 17:15:02 <maxice8> they are, but I pushed that sneakily
2021-01-24 17:16:02 <adhawkins> Wow, that was fast! All merged already bar !17388
2021-01-24 17:16:22 <jvoisin> also, it would be nice to have a "low hanging fruit"/"easy" label for issue: https://gitlab.alpinelinux.org/alpine/aports/-/labels
2021-01-24 17:16:34 <jvoisin> (since I have a bit of free time, and would like to give a hand to Alpine)
2021-01-24 17:17:21 <adhawkins> Once that last one is done I can test and make a start on the move to community.
2021-01-24 17:27:47 <mps> maybe there is 'trick' to make more branches from range of commits in one branch?
2021-01-24 17:32:45 <DylanVanAssche_> Is the `aarch64` CI runner out of service? The build seems to be waiting for such a runner
2021-01-24 17:32:45 <DylanVanAssche_> https://gitlab.alpinelinux.org/dylanvanassche/aports/-/jobs/303630
2021-01-24 17:33:19 <ikke> hmm, it should be running
2021-01-24 17:34:05 <DylanVanAssche_> According to Gitlab the runner was last seen 3 hours ago
2021-01-24 17:34:09 <ikke> yes
2021-01-24 17:34:16 <ikke> the runner is not able to connect back for some reason
2021-01-24 17:39:02 <ikke> DylanVanAssche_: restarting the runner fixed it. Somehow docker dns did not work
2021-01-24 17:41:03 <DylanVanAssche_> Ah okay, thanks!
2021-01-24 17:45:50 <ikke> Someone here experienced with boost?
2021-01-24 17:48:36 <Hello71> ikke: link?
2021-01-24 17:48:51 <ikke> Hello71: hold on, creating an issue for it with the details
2021-01-24 17:50:18 <ikke> Hello71: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12349
2021-01-24 17:54:58 <Hello71> well "Function not implemented" is ENOSYS
2021-01-24 17:55:07 <ikke> aha
2021-01-24 17:55:17 <Hello71> I think
2021-01-24 17:55:35 <Hello71> so I would recommend strace
2021-01-24 17:55:58 <ikke> statx(AT_FDCWD, "../../test/css/invalids/1.css", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_TYPE|STATX_MODE, 0xfffffd7d08) = -1 ENOSYS (Function not implemented)
2021-01-24 17:56:02 <ikke> Hello71: was alreayd on it :P
2021-01-24 17:56:12 <ikke> so statx
2021-01-24 17:57:19 <ikke> Hello71: I guess that's due to the kernel being too old
2021-01-24 17:57:37 <ikke> "Since linux 5.5"
2021-01-24 17:57:53 <Hello71> yes. but why doesn't it fall back?
2021-01-24 17:58:04 <Hello71> maybe same if (errno) issue...
2021-01-24 17:58:24 <ikke> madvise(0xffebd69000, 4096, MADV_FREE)  = 0
2021-01-24 17:58:26 <ikke> I bet
2021-01-24 17:58:33 <ikke> that is the next system call
2021-01-24 18:06:09 <dalias> what now? :-p
2021-01-24 18:06:19 <ikke> dalias: liborcus / boost
2021-01-24 18:06:32 <dalias> broken in what way?
2021-01-24 18:06:43 <ikke> it tries `statix`
2021-01-24 18:06:47 <ikke> `statx`
2021-01-24 18:06:55 <ikke> that returns ENOSYS
2021-01-24 18:07:29 <ikke> Next systemcall is madvise, with the MADV_FREE flag, same as happened with busybox echo
2021-01-24 18:08:16 <ikke> (kernel is 4.9)
2021-01-24 18:09:07 <ikke> It happens after `fs::is_regular_file`
2021-01-24 18:11:40 <dalias> ikke, where is statx being called from? if it's the libc stat function it should just use a different syscall after ENOSYS
2021-01-24 18:11:49 <dalias> are they doing their own call to it with no fallback ??
2021-01-24 18:12:07 <ikke> dalias: was trying to find the source
2021-01-24 18:16:34 <Hello71> dalias: https://github.com/boostorg/filesystem/blob/develop/src/operations.cpp#L2585 lol
2021-01-24 18:16:58 <Hello71> if (statx at compile time) then { statx at run time! }
2021-01-24 18:17:04 <dalias> lol wtf is this shit
2021-01-24 18:17:13 <dalias> we *dont* have statx
2021-01-24 18:17:27 <dalias> there's a pending patch to add it
2021-01-24 18:18:05 <dalias> and this bug does raise an important point: the patch as submitted is not ok
2021-01-24 18:18:20 <Hello71> https://github.com/boostorg/filesystem/blob/b4d606cdd08640c9bca68f7e97b52245aeef398d/src/operations.cpp#L365
2021-01-24 18:18:35 <Hello71> if (kinda have statx) then { make us have statx harder! }
2021-01-24 18:20:52 <dalias> it should call fstatat and convert results if requested info is baseline, or as fallback (reporting non-support for extended info) if SYS_statx fails
2021-01-24 18:27:24 <mps> any objections to merge !16022
2021-01-24 18:31:10 <caskd> mps: i gotta test if this breaks my setup, give me about 10 mins
2021-01-24 18:31:40 <mps> caskd: ok
2021-01-24 18:31:56 <ikke> if plain `startx` as normal user is still working (which you have tested), then fine with me
2021-01-24 18:32:46 <dalias> *nod*
2021-01-24 18:33:55 <dalias> someone should file a bug against boost
2021-01-24 18:34:01 <dalias> like 365 is horribly wrong
2021-01-24 18:34:04 <dalias> line*
2021-01-24 18:34:28 <dalias> you can't emulate the function with the syscall because the emulation doesn't have a fallback path
2021-01-24 18:35:19 <dalias> i would just patch that out for now
2021-01-24 18:35:58 <ikke> Make sure that code is not included?
2021-01-24 18:36:03 <ikke> #if 0
2021-01-24 18:36:09 <dalias> well rather
2021-01-24 18:36:14 <dalias> undefine BOOST_FILESYSTEM_HAS_STATX_SYSCALL
2021-01-24 18:36:21 <dalias> it's used elsewhere too
2021-01-24 18:36:27 <ikke> right
2021-01-24 18:36:51 <dalias> unfortunately this is kinda ABI breaking
2021-01-24 18:36:57 <ikke> sigh
2021-01-24 18:36:59 <dalias> i think
2021-01-24 18:37:04 <dalias> as an alternative you could fix their fallback
2021-01-24 18:37:09 <dalias> at line 369
2021-01-24 18:37:13 <dalias> check for errno==ENOSYS
2021-01-24 18:37:21 <dalias> and call fstatat instead, converting the struct
2021-01-24 18:37:54 <dalias> that would be non-ABI-breaking and acceptable for upstream i think
2021-01-24 18:38:20 <dalias> it's the inverse of the conversion in musl's src/stat/fstatat.c
2021-01-24 18:38:34 <ikke> dalias: from struct stat to struct statx?
2021-01-24 18:38:35 <dalias> and musl will need this inverse conversion too if we add statx() function
2021-01-24 18:38:37 <dalias> yes
2021-01-24 18:39:17 <dalias> converting the dev_t fields is the only nontrivial part
2021-01-24 18:39:25 <dalias> it needs makedev()/major()/minor()
2021-01-24 18:39:32 <Hello71> i think this statx code is internal to boost lib
2021-01-24 18:39:37 <dalias> because the kernel folks gratuitously split them out
2021-01-24 18:39:43 <dalias> oh ok
2021-01-24 18:39:48 <dalias> if it's internal then just disable it
2021-01-24 18:39:52 <dalias> because it's useless
2021-01-24 18:40:32 <Hello71> https://github.com/boostorg/filesystem/search?q=statx
2021-01-24 18:40:37 <Hello71> no results in .hpp
2021-01-24 18:41:15 <ikke> https://github.com/boostorg/filesystem/issues/173
2021-01-24 18:41:28 <Hello71> so just delete https://github.com/boostorg/filesystem/blob/6b5e38134a336b6ea777cd8a69b6ae929819db7e/build/Jamfile.v2#L57
2021-01-24 18:41:38 <ikke> https://github.com/boostorg/filesystem/issues/172
2021-01-24 18:42:07 <Hello71> boost people never heard of docker i guess
2021-01-24 18:42:49 <ikke> and this is no even docker
2021-01-24 18:42:56 <ikke> but linux-headers are way newer than the kernel
2021-01-24 18:43:43 <Hello71> funny thing is (until recently) libseccomp needs new uapi headers
2021-01-24 18:44:17 <Hello71> so really the answer is fuck boost
2021-01-24 18:45:08 <caskd> change looks fine, had to update my init script though as i call the server directly (i enjoy pain)
2021-01-24 18:47:27 <mps> caskd: yes, I run X for long time without suid set
2021-01-24 18:48:12 <caskd> mps: how do you give the user running it permission to take over the tty?
2021-01-24 18:48:31 <mps> but I don't know are there some corner cases where it need to stay
2021-01-24 18:48:43 <Hello71> caskd: modern way, elogind
2021-01-24 18:48:57 <Hello71> old way, udev + add user to video group
2021-01-24 18:49:02 <mps> no, I use startx or slim DM
2021-01-24 18:49:21 <Hello71> ah, yes, or dm
2021-01-24 18:49:29 <mps> Hello71: and to input group
2021-01-24 18:49:31 <caskd> Hello71: elogind can do that? could you give me a resource about that or tell me how?
2021-01-24 18:49:59 <Hello71> mps: i think technically that doesn't count but yes
2021-01-24 18:50:51 <caskd> i currently run elogind only for the power saving stuff, nothing more... would be cool if i could make it more useful
2021-01-24 18:51:56 <mps> (those who don't understand unix are doomed to invent it, poorly)
2021-01-24 18:59:17 <sh4rm4^bnc> mps, found the cause of my heisenbug Xorg crashes: https://github.com/sabotage-linux/sabotage/commit/2f4f4ebf149bca3cd1f6e80a8e7486f95edc5bd0
2021-01-24 18:59:38 <sh4rm4^bnc> basically xf86-video-intel's sna (sandybridge acceleration) is buggy
2021-01-24 19:00:13 <Hello71> shouldn't this be configured in xorg.conf?
2021-01-24 19:00:49 <sh4rm4^bnc> i dunno, do you ?
2021-01-24 19:01:11 <Hello71> or better, use modesetting. xf86-video-intel is basically abandonware
2021-01-24 19:01:38 <sh4rm4^bnc> modesetting has good hw accel ?
2021-01-24 19:01:53 <mps> sh4rm4^bnc: oh, I thought that only palemon crashes, not X
2021-01-24 19:01:59 <Hello71> anything that still uses xrender is fast enough on cpu
2021-01-24 19:02:27 <sh4rm4^bnc> mps: no, it tore down the whole desktop, having to reboot due to keyboard no longer responding
2021-01-24 19:02:44 <mps> uhh, not good
2021-01-24 19:03:13 <ikke> Hello71: building boost1.75 now on the mips builder with that line removed
2021-01-24 19:03:20 <mps> but as Hello71 says, modesetting is quite fine
2021-01-24 19:03:51 <Hello71> https://git.alpinelinux.org/alpine-conf/commit/?id=5847d54be1636f87d16e445e0a903d2e411f7c1c
2021-01-24 19:04:03 <Hello71> links are backwards but doesn't really matter
2021-01-24 19:06:15 <sh4rm4^bnc> ah so this is why i couldnt find any info on this bug. nobody is using xf86-video-intel anymore.
2021-01-24 19:06:44 <mps> let me see on old macbook
2021-01-24 19:12:38 <mps> hmm, it works with both, modesetting and intel
2021-01-24 19:13:10 <sh4rm4^bnc> the links in above commit point out that the driver is buggy for newer GPUs only
2021-01-24 19:14:23 <mps> could be, in last few kernel releases I see a lot of fixes for intel gpu
2021-01-24 19:14:51 <mps> kernels*
2021-01-24 19:15:43 <sh4rm4^bnc> i actually updated from 4.14 to 5.4 due to this issue, but didnt help
2021-01-24 19:16:49 <mps> iirc, 5.4 also had/have this problem
2021-01-24 19:17:39 <mps> I remember that with 5.4 I had some X crashes
2021-01-24 19:18:38 <sh4rm4^bnc> my debugging results were almost always crashes in pixman code called from sna_accel.c, and sometimes on free() in musl in a pixman_destroy codepath
2021-01-24 19:18:57 <sh4rm4^bnc> so i'd guess there's just some memory corruption in the userspace driver
2021-01-24 19:19:36 <mps> but for one year I use arm64 workstations
2021-01-24 19:19:50 <sh4rm4^bnc> one should probably compile this code with asan on glibc and check whether it points out some offending code
2021-01-24 19:20:35 <sh4rm4^bnc> how's arm64 perf compared to x86_64 ?
2021-01-24 19:20:56 <mps> actually retired last intel about year ago, I use arm workstations for about 5 years
2021-01-24 19:22:08 <dalias> sh4rm4^bnc, nobody is using xf86-video-intel anymore ??
2021-01-24 19:22:13 <mps> sh4rm4^bnc: I don't do any benchmarks (they are useless imo) but my experience is good
2021-01-24 19:22:14 <dalias> what does one use instead then?
2021-01-24 19:22:57 <sh4rm4^bnc> modesetting, apparently
2021-01-24 19:22:58 <mps> xf86-video-modesetting
2021-01-24 19:23:19 <dalias> hello71, i don't understand "modesetting". aiui all drivers use kernel mode setting nowadays but they still have all the userspace driver crap
2021-01-24 19:24:24 <mps> mesa-dri-intel also
2021-01-24 19:25:17 <mps> but I'm not 'graphic man' so don't know much about fine points
2021-01-24 19:25:46 <dalias> it looks like my xorg finds both intel and modesetting but uses intel
2021-01-24 19:25:49 <dalias> should i change that?
2021-01-24 19:26:24 <sh4rm4^bnc> if you don't have issues probably not
2021-01-24 19:26:25 <dalias> (is there any modern documentation on this stuff??)
2021-01-24 19:27:47 <dalias> well enabling glx makes the x server crash :/
2021-01-24 19:27:52 <dalias> i'd like to be able to enable it
2021-01-24 19:28:46 <dalias> and then disable clients' access to dri crap
2021-01-24 19:29:26 <sh4rm4^bnc> what's bad about dri ?
2021-01-24 19:29:43 <sh4rm4^bnc> i recall i had once to disable dri3 because i would get crashes otherwise
2021-01-24 19:29:43 <dalias> broken privilege model, requires dynamic linking
2021-01-24 19:30:09 <dalias> if you have working glx you could literally just static link mesa glx backend
2021-01-24 19:30:17 <sh4rm4^bnc> interesting
2021-01-24 19:31:56 <dalias> in theory
2021-01-24 19:32:13 <dalias> i actually have no idea if the protocol supports modern features or if it's bitrotted beyond usability or whatever
2021-01-24 19:32:20 <dalias> but i want to test it
2021-01-24 19:34:51 <mps> uhm, ppc64le CI https://gitlab.alpinelinux.org/mps/aports/-/jobs/303692#L264
2021-01-24 19:35:05 <mps> make: /bin/sh: Operation not permitted
2021-01-24 19:35:39 <ikke> ah, I don't think we ran into that before fore ppc64le
2021-01-24 19:36:03 <mps> first time see that on ppc
2021-01-24 19:38:14 <ikke> should be fixed now
2021-01-24 19:41:51 <mps> thanks, restarted job
2021-01-24 19:55:31 <ikke> Watching mips64 build is like watching paint dry
2021-01-24 20:03:15 <ikke> Hello71: dalias # PASS:  10  FAIL:  0
2021-01-24 20:06:51 <Hello71> dalias: in this context i mean xf86-video-modesetting, which i think uses glamor (opengl) as a backend for xrender
2021-01-24 20:07:37 <Hello71> the theory being that 3d accel is better maintained than 2d, so just use 2d commands in 3d mode
2021-01-24 20:08:45 <Hello71> also i think glx will also become poorly maintained as time goes on, since it is not compatible with wayland
2021-01-24 20:16:15 <ikke> Hello71: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17410
2021-01-24 20:18:33 <Hello71> ikke: commented
2021-01-24 20:18:58 <ikke> thanks
2021-01-24 20:19:28 <maxice8> python3.9.1 is coming later today
2021-01-24 20:20:09 <ikke> maxice8: I was trying to get the builders green again before that
2021-01-24 20:20:24 <maxice8> Makes sense
2021-01-24 20:20:24 <ikke> I have one fix for boost
2021-01-24 20:20:31 <ikke> that fixes mips64
2021-01-24 20:20:32 <maxice8> if the builder isn't green I can delay it
2021-01-24 20:20:46 <maxice8> or rather, should
2021-01-24 20:23:15 <ikke> vamp-sdk is holding up s390x
2021-01-24 20:23:17 <maxice8> Also this will help with the py3-setuptools 52 which removes easy_install
2021-01-24 20:23:22 <maxice8> vamp-sdk should be disabled
2021-01-24 20:23:26 <ikke> ok
2021-01-24 20:24:13 <maxice8> our certificates don't include the ones used by vamp-sdk
2021-01-24 20:24:21 <maxice8> works in the web browser with its own certificates
2021-01-24 20:24:21 <ikke> vamp-sdk is required by some pacakges
2021-01-24 20:24:24 <ikke> packages*
2021-01-24 20:24:35 <ikke> I guess it does not include the intermediate
2021-01-24 20:24:41 <maxice8> no it doesn't
2021-01-24 20:25:08 <ikke> shakes fist at MS
2021-01-24 20:26:23 <maxice8> also doesn't work on my Fedora Silverblue's curl
2021-01-24 20:26:27 <maxice8> so no clue what the deal is
2021-01-24 20:27:21 <ikke> certificates should include the entire chain, excluding the root cert
2021-01-24 20:28:22 <ikke> but it does seem to have build for other arches
2021-01-24 20:30:58 <adhawkins> Do I need to do anything to close a MR after it has been merged?
2021-01-24 20:31:08 <Cogitri> Nop
2021-01-24 20:31:32 <adhawkins> Ok, will leave well alone then. Thanks cogitri
2021-01-24 20:34:22 <ikke> maxice8: I think I just fixed vamp-sdk (by setting DISTFILES_MIRROR on s390x
2021-01-24 20:34:29 <ikke> but you disabled it already
2021-01-24 20:36:49 <maxice8> I did it sometime ago
2021-01-24 20:36:53 <ikke> ok
2021-01-24 20:37:13 <ikke> the reason it did not work on s390x is because it did not have that setting
2021-01-24 20:37:18 <ikke> while the others had
2021-01-24 20:37:30 <maxice8> so s390x was never fetching from distfiles ?
2021-01-24 20:37:45 <ikke> correct
2021-01-24 20:38:02 <ikke> it's not a durable solution, but for the time being, it works
2021-01-24 20:43:36 <ikke> maxice8: mips64 and ppc64le still have a bit to build
2021-01-24 20:44:20 <maxice8> I see
2021-01-24 20:44:29 <maxice8> 37% and 29%
2021-01-24 20:44:51 <ikke> and mips64 will be stuck on liborcut until boost is merged
2021-01-24 20:51:07 <ikke> boost is merged, so liborcut should not be a blocker anymore
2021-01-24 20:51:16 <dalias> it would probably help a lot if the builders always ran latest kernel and docker host
2021-01-24 20:51:30 <dalias> so as not to hit stupid syscall errors
2021-01-24 20:51:38 <ikke> dalias: we're kind of stuck with mips
2021-01-24 20:51:46 <dalias> :/
2021-01-24 20:51:47 <ikke> the builder is running a BSP kernel
2021-01-24 20:51:54 <dalias> eeeewww
2021-01-24 20:52:05 <ikke> They need to reverse engineer the network driver
2021-01-24 20:52:16 <ikke> I'm working on upgrading the rest
2021-01-24 20:52:31 <ikke> Most CI hosts run 3.13 already
2021-01-24 20:53:09 <dalias> lol is it gpl infringing??
2021-01-24 20:53:20 <ikke> dalias: I have no clue
2021-01-24 21:02:57 <Hello71> Ariadne has details, but afaik they have the source but it's terrible
2021-01-24 21:03:05 <Hello71> so they are rewriting it... slowly
2021-01-24 21:03:51 <dalias> its so awful of linux to have your API level tied to your hardware support layer
2021-01-24 21:04:23 <Hello71> i mean the question is who would maintain the old versions
2021-01-24 21:04:27 <dalias> like, what version of syscall api you have and what version of hardware drivers and architecture abstraction you have should be completely unrelated things
2021-01-24 21:04:58 <Hello71> the windows alternative is not much better, with microsoft releasing new apis every couple years because everybody is too scared to touch the old ones for fear of backward compat
2021-01-24 21:05:19 <dalias> indeed
2021-01-24 21:05:47 <Hello71> mac just says "fuck ur 'backwards compat'"
2021-01-24 21:06:18 <ikke> dalias: I guess that's the consequences of a monolithic repo
2021-01-24 21:06:24 <ikke> s/repo/kernel
2021-01-24 21:06:25 <alpine-meetbot> ikke meant to say: dalias: I guess that's the consequences of a monolithic kernel
2021-01-24 21:06:32 <Hello71> so yeah it kinda sucks but i don't see a better way, unless someone really wants to pour in what would probably be millions of dollars to maintain the old apis
2021-01-24 21:06:43 <Hello71> and right, at that rate you might as well finish hurd
2021-01-24 21:13:50 <TBK[m]> ikke: several of the Octeon III kernel patches stranded in review, I am guessing because Cavium got acquired by Marvell and Marvell is more interested in ARM...
2021-01-24 21:20:38 <dalias> "maintain the old apis" seems to be assuming some implementation strategy i'm not assuming
2021-01-24 21:23:00 <ikke> How would it work then?
2021-01-24 21:23:17 <ikke> You would need some stable API for drivers to work against
2021-01-24 21:23:43 <maxice8> py3-twisted failing on ppc64le
2021-01-24 21:23:45 <maxice8> twisted.internet.error.CannotListenError: Couldn't listen on fe80::fc8c:47ff:fe3a:fa24%eth0:0: [Errno 99] Address not available.
2021-01-24 21:24:29 <ikke> dadfailed
2021-01-24 21:26:26 <ikke> removed the address from the interface
2021-01-24 21:30:34 <dalias> ikke, the stupid monolithic-kernel-like way to do it is the other way around. HAL kernel lives *under* the kernel layer that hosts applications
2021-01-24 21:31:30 <dalias> so you just keep running the 3.x crap or whatever on the hardware, but applications are running on a 5.10 version of the process environment
2021-01-24 21:31:51 <dalias> think uml-like
2021-01-24 21:32:03 <dalias> this is not the good secure factorization where drivers are unprivileged
2021-01-24 21:32:34 <ikke> but this _does_ require some interface between the 2
2021-01-24 21:32:50 <dalias> yes
2021-01-24 21:33:10 <ikke> and you cannot change this interface
2021-01-24 21:34:14 <maxice8> !17288 !17287
2021-01-24 21:34:34 <mps> some discussions will never end ;)
2021-01-24 21:35:17 <ikke> maxice8: kunkku maintains both
2021-01-24 21:55:31 <ikke> maxice8: py3-usb fails on ppc64le
2021-01-24 21:56:07 <ikke> WARNING: The wheel package is not available.
2021-01-24 21:56:13 <ikke> /usr/bin/python3: No module named pip
2021-01-24 22:00:26 <maxice8> oh
2021-01-24 22:01:42 <maxice8> missing py3-setuptools_scm
2021-01-24 22:01:59 <maxice8> py3-setuptools 52 no longer provides easy_install and thus will fail whenever a dependency is missing
2021-01-24 22:02:22 <ikke> sounds like a good thing
2021-01-24 22:02:46 <maxice8> it basically broke loads of APKBUILDs that silently relied on easy_install
2021-01-24 22:02:55 <maxice8> I plan on fixing them as part of the python3.9 transition
2021-01-24 22:03:59 <ikke> at least dependencies are explicit
2021-01-24 22:04:04 <ikke> then
2021-01-24 22:04:12 <Hello71> dalias: firecracker?
2021-01-24 22:05:03 <maxice8> https://github.com/void-linux/void-packages/blob/master/common/build-style/python3-pep517.sh
2021-01-24 22:09:28 <dalias> ?
2021-01-24 22:11:45 <maxice8> python3 ecosystem is moving to those fancy pep517 and all the poetry/flint stuff
2021-01-24 22:11:53 <maxice8> one day Alpine Linux will have to start packaging it too
2021-01-24 22:16:51 <Hello71> if there's anything python ecosystem is known for, it's not quickly moving to new systems
2021-01-24 22:26:06 <maxice8> I wonder how setuptools_scm actually works for us I think it doesn't
2021-01-24 22:26:28 <Ariadne> actually my current plan is to backport mips64 kvm support to the bsp kernel
2021-01-24 22:27:45 <ikke> sl
2021-01-24 22:28:02 <ikke> So the builders will run in a VM?
2021-01-24 22:49:14 <Ariadne> yes
2021-01-24 22:51:25 <dalias> ooh nice
2021-01-24 22:51:45 <dalias> yeah that's roughly the factorization i had in mind
2021-01-24 22:51:48 <dalias> just stated better
2021-01-24 22:52:50 <ikke> ahd possible 'today'
2021-01-24 22:52:52 <ikke> :)
2021-01-24 22:53:50 <Hello71> Ariadne: does it not support xen?
2021-01-24 22:54:11 <Ariadne> xen is not ported to mips at all
2021-01-24 22:54:15 <Hello71> ah
2021-01-24 22:55:08 <Hello71> apparently there is actually a port. for one cpu. from 2014.
2021-01-24 22:57:05 <mps> hmm, qemu-system-mips64 is there so missing part is kvm part in kernel iiuc
2021-01-24 22:58:05 <mps> does it makes sense to run qemu-system-mips64 on some other arches with superfast host
2021-01-24 22:58:38 <ikke> depends on how good the emulation is
2021-01-24 22:59:39 <mps> last time I looked (about 5 years ago) mips ISA is not much too complicated
2021-01-24 23:00:35 <mps> though I never programmed anything in its assembler, just few simple exercises for my daughter faculty
2021-01-24 23:04:19 <Hello71> well the problem isn't implementing add or sub
2021-01-24 23:05:37 <Hello71> it's implementing floating point math, interrupts, hardware emulation, vector (and other) isa extensions...
2021-01-24 23:06:49 <mps> Hello71: no worries, I didn't raised my hand for this job ;)
2021-01-24 23:08:58 <Hello71> plus trying to do all of that *fast*
2021-01-24 23:36:42 <ikke> py3-inform missis pytest-runner
2021-01-24 23:37:54 <maxice8> fixed
2021-01-24 23:38:07 <maxice8> thanks Ikke and py3-setuptools=52.0.0-r0
2021-01-24 23:41:31 <dalias> yeah add and sub are only hard on cisc ;-)
2021-01-24 23:43:35 <Hello71> movfuscator etc :p
2021-01-25 00:18:18 <craftyguy> maxice8: bah, you beat my by a few seconds to that MR for porting those plugins to posix sh
2021-01-25 00:18:26 <craftyguy> :P
2021-01-25 00:18:42 <maxice8> :^)
2021-01-25 00:18:50 <timlegge> mps: ikke: not sure if it is acceptable but adding export TERM=xterm-256color to the check seems to work -> !17415
2021-01-25 01:18:19 <Ariadne> [15:55:05] <Hello71> apparently there is actually a port. for one cpu. from 2014.
2021-01-25 01:18:23 <Ariadne> probably not the cpu we have :)))
2021-01-25 04:35:40 <maxice8> oh we are missing py3-pytest-runner a lot
2021-01-25 04:36:54 <maxice8> I feel like the python3.9 rebuild is gonna be a lot of red fun :D
2021-01-25 06:15:41 <ikke> timlegge: Yeah, I don't see why that should be a problem
2021-01-25 06:56:17 <ncopa> morning
2021-01-25 06:57:29 <ncopa> maxice8: are you working on python 3.9? I wonder if we should update the triplet
2021-01-25 06:57:52 <maxice8> I have an MR for it
2021-01-25 06:58:07 <maxice8> Just not the massive rebuilds necessary
2021-01-25 06:59:57 <ncopa> "checking for the platform triplet based on compiler characteristics... x86_64-linux-gnu"
2021-01-25 07:00:10 <ncopa> i wonder if we may want to change that
2021-01-25 07:01:56 <ncopa> dalias: IIRC you once mentioned that it maybe was not a good idea to build python as x86_64-linux-gnu?
2021-01-25 07:02:59 <ncopa> i also wonder if we could make python wheels work properly, the precompiled modules
2021-01-25 07:04:40 <ncopa> basically, i'm interested in fixing this: https://lih-verma.medium.com/alpine-makes-python-docker-builds-way-too-50-slower-and-images-double-2-larger-61d1d43cbc79
2021-01-25 07:11:55 <maxice8> I had planned to do it yesterday near midnight but the builders aren't green yet
2021-01-25 07:14:15 <ncopa> i'd like to investigate if we need to build python differently to get musl wheels
2021-01-25 07:14:51 <maxice8> As far I understand (not a whole lot) we would need pypa or whatever authority manages pypi to host those like they host for manylinux
2021-01-25 07:15:40 <maxice8> Or host our own precompiled wheels and configure pip to look for them
2021-01-25 07:16:02 <ncopa> https://github.com/pypa/manylinux/issues/37
2021-01-25 07:18:30 <ncopa> there is a warning here about alpine linux https://realpython.com/python-wheels/#the-manylinux-wheel-tag
2021-01-25 07:19:07 <ncopa> but really, we don't want alpine to build those binary python wheels. we want upstream do it themselves, just like they build for manylinux
2021-01-25 07:19:26 <ncopa> we should find a solution for musllinux or similar
2021-01-25 07:20:02 <ncopa> and maybe provide docker images so its trivial for python devs to add alpine to their CI
2021-01-25 07:21:21 <ncopa> but i think first step is to investigate how pip can tell the difference if its gnu vs musl linux
2021-01-25 07:28:29 <ncopa> here is another discussion about the topic: https://mail.python.org/archives/list/distutils-sig@python.org/thread/H3323AXRRLJAYOY2XZKS74IOUQMJUOYD/
2021-01-25 07:29:33 <maxice8> mips64 and ppc64le are still rolling
2021-01-25 07:43:21 <ncopa> maxice8: I'd like to know if we should build python in different way to help https://mail.python.org/archives/list/distutils-sig@python.org/thread/H3323AXRRLJAYOY2XZKS74IOUQMJUOYD/ move forward
2021-01-25 07:43:45 <maxice8> I have no clue about all that
2021-01-25 07:46:52 <ncopa> maybe dalias knows?
2021-01-25 07:47:17 <ncopa> in either case, i'd like to make sure that we build python 3.9 properly
2021-01-25 07:47:39 <maxice8> sounds good, I'll delay the upgrade until this is sorted out
2021-01-25 07:48:13 <maxice8> ncopa: can you take a look at abuild MRs ?
2021-01-25 07:59:30 <maxice8> https://mm.icann.org/pipermail/tz-announce/2021-January/000065.html
2021-01-25 08:02:50 <mps> it's a pity earth is not flat and sun doesn't have light switch, all these TZ nonsense would disappear
2021-01-25 08:05:07 <maxice8> you just made the best pro-flatearth argument ever
2021-01-25 08:05:41 <mps> :)
2021-01-25 08:06:56 <mps> morning coffee is a strong inspiration for a lot of ideas
2021-01-25 08:07:58 <mps> and Brazilian ones, ofc ;)
2021-01-25 08:09:27 <mps> oh, not to forget Dutch tobacco
2021-01-25 08:30:58 <mps> timlegge: thanks. I wanted to merge your MR but it have WIP so I merged mine
2021-01-25 10:10:45 <adhawkins> !17437
2021-01-25 10:10:52 <adhawkins> The final step hopefully!
2021-01-25 10:17:49 <maxice8> adhwankins you need to move py3-arrow as well
2021-01-25 10:18:54 <adhawkins> That's not one of my packages maxice8. Good point though, let me check all the dependencies.
2021-01-25 10:19:14 <maxice8> It isn't but if you don't move it then your MR is moot and broken
2021-01-25 10:19:21 <adhawkins> Fair point. Thanks.
2021-01-25 10:19:22 <maxice8> put a commit to move it and tag the maintainer
2021-01-25 10:19:33 <adhawkins> How do I do that maxice8?
2021-01-25 10:19:56 <maxice8> the top of the APKBUILD has the maintainer name and email (hopefully in the future we will be able to quickly map that to gitlab username too)
2021-01-25 10:20:22 <adhawkins> And how do I 'tag' them?
2021-01-25 10:20:32 <maxice8> @username
2021-01-25 10:20:36 <maxice8> just did it
2021-01-25 10:21:31 <adhawkins> Ok, I've added the commit.
2021-01-25 10:22:05 <mps> #12274 should be closed, yesterday pushed fixes for last two releases
2021-01-25 10:22:16 <adhawkins> Will go round and double check there are no others.
2021-01-25 10:46:09 <adhawkins> Ok, been through all the packages checking their dependencies, and they're all available in either community or main. Thanks for spotting that maxice8, should be good to go now.
2021-01-25 10:54:11 <ikke> CI should catch that as well, btw
2021-01-25 10:54:25 <ikke> if you try to build something in community, the testing repo is not available
2021-01-25 10:54:31 <ikke> so the build should fail
2021-01-25 10:56:46 <adhawkins> Ah ok, that's good to know.
2021-01-25 10:58:44 <adhawkins> Any way I could catch that in a local build ikke?
2021-01-25 10:58:53 <adhawkins> I'm using dabuild at the moment.
2021-01-25 10:59:26 <ikke> adhawkins: I guess not easily. I assume all 3 repos are enabled in the dabuild image
2021-01-25 11:02:28 <adhawkins> ikke: Yes you're right, all three repos enabled.
2021-01-25 11:03:29 <ikke> The only easy way to catch this is to remove the not required repo
2021-01-25 11:03:45 <adhawkins> Yeah, that'd be easier to do if I weren't running in docker I suppose.
2021-01-25 11:04:07 <adhawkins> I might add it as a feature suggestion on dabuild, sounds like it could be useful?
2021-01-25 11:04:45 <ikke> adhawkins: It could probably use the same logic as we do in our CI
2021-01-25 11:06:45 <adhawkins> Yeah, that sounds like a good plan.
2021-01-25 11:06:57 <adhawkins> https://gitlab.alpinelinux.org/alpine/docker-abuild/-/issues/70
2021-01-25 11:31:09 <timlegge> mps no worries glad it worked
2021-01-25 11:32:16 <ikke> ncopa: I wonder how to debug an issue we have on one of the packet hosts we have. Details are here: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12325, but summary: on the latest kernels (5.10.x), during boot, it fails to activate the lvm volumes (nlplug-findfs). When I run the same command in the emergency shell, it works
2021-01-25 11:34:20 <Hello71> ikke: what was the result of adding sleep?
2021-01-25 11:34:48 <ikke> Hello71: Maybe I should have added more sleep, but 10/15 seconds didn't seem to help
2021-01-25 11:44:38 <Hello71> wondering if this is related to that linux uevent add/bind change...
2021-01-25 11:45:16 <Hello71> no, that was 4.12...
2021-01-25 11:52:39 <mps> I can only tell that 5.9.9-0-edge kernel works on one of the servers I maintain, with nvme
2021-01-25 11:52:57 <mps> though no lvm
2021-01-25 11:52:58 <Hello71> hm, does nlplug-findfs really use 100% cpu while polling?
2021-01-25 11:53:31 <ikke> mps: it works on another server we have, but it uses efi boot, not legacy boot
2021-01-25 11:53:50 <ikke> There might be other differences
2021-01-25 11:54:32 <mps> aha, yes also 'my' use uefi
2021-01-25 11:55:50 <Hello71> ikke: maybe you can try libahci.ignore_sss=1
2021-01-25 11:56:05 <ikke> as kernel parameter?
2021-01-25 11:57:30 <mps> this is kernel cli parameter
2021-01-25 11:58:00 <mps> hm, not strictly 'cli' but command line, so 'cl'
2021-01-25 11:58:19 <ikke> I'll try later
2021-01-25 11:58:35 <Hello71> how many disks does your server have?
2021-01-25 11:58:50 <Hello71> and are they real HDDs
2021-01-25 11:59:00 <ikke> 4, all either nvme or ssd
2021-01-25 11:59:07 <ikke> so nothing to spin up
2021-01-25 11:59:46 <ikke> and the boot output indicated the kernel at least detected the disks before nlplug-findfs was run
2021-01-25 12:01:18 <Hello71> hm... maybe try that, and also try sticking partprobe in somewhere
2021-01-25 12:01:37 <ikke> the ignore_sss?
2021-01-25 12:01:47 <Hello71> also try replacing nlplug-findfs call with sh, then running nlplug-findfs manually
2021-01-25 12:01:50 <Hello71> yeah
2021-01-25 12:01:54 <Hello71> or some combination of those
2021-01-25 12:19:45 <mps> if remove ifupdown-ng what is intended to start 'lo' interface
2021-01-25 12:20:54 <mps> write new 'networking' init script?
2021-01-25 12:22:34 <mps>  /etc/init.d/loopback
2021-01-25 12:46:14 <ncopa> ikke: we have a place where to reproduce and debug it in peace?
2021-01-25 12:46:54 <ikke> ncopa: usa7, which means, taking x86_64 ci down for a bit
2021-01-25 12:48:58 <ncopa> maybe we can have a look at it tomorrow?
2021-01-25 12:49:04 <ncopa> today is busy
2021-01-25 13:20:11 <Hello71> in the meantime, what's wrong with the builders?
2021-01-25 13:41:28 <adhawkins> Looks like py3-arrow has been in 'testing' for several months. How long would packages usually stay there before moving?
2021-01-25 13:42:44 <Hello71> no specific time
2021-01-25 13:43:54 <adhawkins> Ok. Just to migrate emborg py3-arrow also needs to migrate. Wondering how long it'll hold it up.
2021-01-25 14:28:01 <mps> depends on reasons and maintainer
2021-01-25 14:34:42 <minimal> could someone merge !17310?
2021-01-25 14:45:52 <mps> what is fine difference between words could and would?
2021-01-25 14:45:53 <adhawkins> mps Yes, understood. Hopefully the maintainer of py3-arrow will respond in a timely fashion.
2021-01-25 14:46:22 <adhawkins> Could means it's possible to do, would means you are going to do it if conditions allow.
2021-01-25 14:46:43 <adhawkins> So a 'would' is more of an intention to actually do it.
2021-01-25 14:46:49 <mps> :)
2021-01-25 14:47:01 <mps> that was ironical question
2021-01-25 14:47:08 <adhawkins> differehttps://www.learnersdictionary.com/qa/How-to-Use-Could-Would-and-Should#:~:text=Could%20is%20used%20to%20say,is%20not%20going%20to%20happen.
2021-01-25 14:47:24 <mps> adhawkins: sorry
2021-01-25 14:47:28 <adhawkins> mps: Apologies. Wasn't sure if you were a non-native English speaker asking for a clarification :D
2021-01-25 14:47:29 <minimal> mps: could/should/would - increasely degrees of likelyhood of something to happen :-)
2021-01-25 14:47:29 <adhawkins> My bad!
2021-01-25 14:48:12 <mps> I'm self taught in english, and obviously not good teacher :)
2021-01-25 14:48:48 <dalias> regression in firefox since upgrading to 84: getaddrinfo result order is not honored
2021-01-25 14:49:02 <dalias> thus firefox is making ipv6 connections over 6to4 rather than usign ipv4 results
2021-01-25 14:49:23 <dalias> because its own resolver is shit and doesn't follow rfc 3493
2021-01-25 14:49:37 <mps> looks like even 'ping' likes this
2021-01-25 14:51:00 <dalias> ?
2021-01-25 14:51:09 <dalias> how so?
2021-01-25 14:51:23 <mps> adhawkins: if there no blocker for moving pkg from testing to community you can create MR and assign it to maintainer
2021-01-25 14:51:54 <mps> dalias: ping prefer ipv6 over ipv4
2021-01-25 14:52:20 <mps> even if routing doesn't work
2021-01-25 14:52:51 <mps> it's enough for it to see ipv6 in dns response
2021-01-25 14:54:17 <mps> this ipv6 'switch' reminds of famous anecdote about british to switch to drive on the 'right' side
2021-01-25 14:54:32 <dalias> mps, doesn't seem to
2021-01-25 14:54:43 <dalias> $ ping google.com
2021-01-25 14:54:43 <dalias> PING google.com (172.217.164.142): 56 data bytes
2021-01-25 14:54:50 <MY-R> ye in many apps ip6 > ip4, first trying ip6 then fallback to ip4
2021-01-25 14:55:01 <mps> hmm, in my case it tries over ipv6
2021-01-25 14:55:05 <MY-R> ye because got ping6 for ip6
2021-01-25 14:55:16 <dalias> mps, presumably because you have a preferable route for v6
2021-01-25 14:55:21 <mps> no ping6, but ping
2021-01-25 14:56:19 <MY-R> ye ping by default trying ip6 first too
2021-01-25 14:56:37 <MY-R> need use ping -4 to force ip4
2021-01-25 14:57:36 <mps> hmm, yes ipv6 is 'preferred medium', didn't noticed
2021-01-25 14:58:10 <dalias> the problem is that firefox seems to be doing its own idiotic thing ignoring the results of getaddrinfo
2021-01-25 14:58:41 <MY-R> dalias: ye that is why I disable ipv6 in firefox :P when of course dont have ipv6 network
2021-01-25 14:59:20 <minimal> dalias: from this https://github.com/libuv/libuv/issues/2225 I'm guessing Firefox is assuming glibc behaviour: "That means musl by default returns addresses that may be unreachable from the current machine whereas glibc won't."
2021-01-25 14:59:50 <dalias> minimal, nope
2021-01-25 15:00:20 <dalias> there is no problem with unreachable addresses here
2021-01-25 15:00:25 <dalias> the problem is not honoring the preference order
2021-01-25 15:00:56 <MY-R> hmm, what order?
2021-01-25 15:00:59 <dalias> (which is the same as the nodejs bug, but i'm not sure if the mechanism is the same (wrongly resorting them itself) or different (e.g. bypassing getaddrinfo entirely)
2021-01-25 15:01:18 <dalias> getaddrinfo returns results sorted by routability preference
2021-01-25 15:01:42 <dalias> if one family is routable and the other isn't, the one that is will be first
2021-01-25 15:01:56 <dalias> but also if individual addresses are not routable they'll be last
2021-01-25 15:02:24 <dalias> and if individual addresses are tunnel (6to4) themselves or are routed out over an address that's a tunnel, they're de-preferred
2021-01-25 15:03:22 <dalias> something happpened in the rough range 69..84 to break this
2021-01-25 15:05:03 <dalias> and it's really annoying because, aside from impacting performance, google throws a captcha nag at you every time you make a search query over 6to4
2021-01-25 15:05:10 <dalias> lying that it's deprecated
2021-01-25 15:06:01 <dalias> network.dns.ipv4OnlyDomains = google.com should fix it for now..
2021-01-25 15:06:13 <MY-R> everytime like every single use or after when rerun firefox?
2021-01-25 15:06:19 <dalias> every single use
2021-01-25 15:06:42 <dalias> not 100% but not just once per restart
2021-01-25 15:06:56 <dalias> basically their abuse prediction AI just treats 6to4 as sus
2021-01-25 15:07:12 <Hello71> maybe just your range
2021-01-25 15:07:12 <MY-R> ye weird, normaly would use cookies to avoid that
2021-01-25 15:07:24 <minimal> I'm assuming musl doesn't support gai.conf
2021-01-25 15:07:25 <TBK[m]> With abfe51e79a7a833c2c0e4210e6ecddd42d7285ca pkgrel did not get reset (https://git.alpinelinux.org/aports/tree/main/linux-lts/APKBUILD?id=abfe51e79a7a833c2c0e4210e6ecddd42d7285ca#n10) and all the kernel packages are looking for 5.10.10-r0
2021-01-25 15:07:26 <dalias> they probably dont have cookies
2021-01-25 15:07:33 <Hello71> could be mtu but I don't think so
2021-01-25 15:07:57 <dalias> minimal, gai.conf is only needed to *change* this behavior not to get the right default we should be getting (and are getting when gai is called and results are used right)
2021-01-25 15:08:41 <minimal> dalias: yeah I know - I was bringing up a side issue
2021-01-25 15:09:11 <MY-R> I know that problem with huricane electric ipv6 tunnels but I had private mode enabled so my ipv6 address was different every reboot and then google was asking me to confirm that Im not a bot...
2021-01-25 15:11:37 <dalias> yeah it's really hostile
2021-01-25 15:12:20 <MY-R> and ye google reCaptcha using cookies
2021-01-25 15:17:21 <ikke> TBK[m]: so modules need to be fixed to use the correct rel
2021-01-25 15:19:17 <dalias> my-r, i'm not sure it even has access to cookies
2021-01-25 15:19:35 <maxice8> ncopa: ping
2021-01-25 15:19:48 <dalias> i use firstparty isolate, so i'm not sure if searches from url bar get the google.com cookies or an empty context
2021-01-25 15:19:58 <dalias> for the initial search query that is
2021-01-25 15:20:06 <dalias> once google.com is up in the tab it's the google.com isolate
2021-01-25 15:20:51 <dalias> hmm as an aside, i should use container tabs for google too
2021-01-25 15:21:19 <dalias> so just my gmail container tab is logged into google and default is not logged in or logged in as junk account
2021-01-25 15:21:35 <dalias> but i'm not sure if you can do stuff like turning off personalization and history if not logged in..
2021-01-25 15:23:25 <minimal> BTW Google's anonymising of IPv6 addresses is not correct anonymisation - they use a /48 mask whereas some ISPs handle out /48 blocks to end customers
2021-01-25 15:24:16 <dalias> yep
2021-01-25 15:24:57 <minimal> haven't seen anyone pull them on this yet (i.e. a EU Data Protection Authority re GDPR)
2021-01-25 15:32:19 <adhawkins> mps: Your English is a million times better than my (insert whatever your native language is)
2021-01-25 15:32:37 <adhawkins> And I've already created an MR moving this package over (along with all of mine) and the maintainer is mentioned in it.
2021-01-25 15:33:20 <adhawkins> Looks like Leo was the last person to touch it though, they did the last upgrade.
2021-01-25 15:44:02 <MY-R> dalias: that is why you have recaptcha so often, I have recaptcha too when remove cookies, and yes it is good idea to use extension like "Firefox Multi-Account Containers"
2021-01-25 15:46:52 <dalias> my-r, no, i don't get it when gai results are used correctly
2021-01-25 15:47:06 <dalias> only now that firefox is wrongly connecting over 6to4
2021-01-25 15:50:05 <MY-R> dalias: I wouldnt be suprised if firefox just started ignore what is in gai.conf :\
2021-01-25 15:53:57 <MY-R> ^ or maybe that: https://gist.github.com/e00E/70bcb5f7f0db216739029a7b7e342fdf
2021-01-25 15:57:49 <Hello71> actually i think firefox doesn't use gai
2021-01-25 15:58:06 <Hello71> something about dns ttl
2021-01-25 16:00:11 <detha> isn't there a knob in firefox to use the gai instead of its own cruft?
2021-01-25 16:01:13 <minimal> MY-R: that link does bring up the general question that if you have machines with only IPv6 ULA and you're using either IPv6-prefix-mapping (so NAT-ting between global and ULA prefixes) or general NAT6 whether this will work as expected in general
2021-01-25 16:02:16 <dalias> detha, that's what i'm looking for...
2021-01-25 16:02:54 <dalias> only ipv6 just isn't viable yet
2021-01-25 16:03:01 <dalias> you need some shitty ipv4 nat too
2021-01-25 16:03:05 <dalias> until all sites support v6
2021-01-25 16:03:22 <detha> 
ACTION wonders where network.dns.disabled does

2021-01-25 16:03:32 <detha> *what
2021-01-25 16:03:37 <dalias> detha, it's for use with tor when you want to be really sure you don't make dns queries
2021-01-25 16:03:47 <minimal> dalias: sorry I was unclear, I wasn't talking about IPv6-only but rather in a IPv6 context where the only IPv6 address machines have is a ULA, so no global address
2021-01-25 16:04:05 <dalias> minimal, that can just be normal NAT'd tho, no?
2021-01-25 16:04:44 <dalias> i.e. nat works without also requiring forgery of dns results
2021-01-25 16:05:34 <minimal> well that was my point - there's to ways to NAT - either map ULA prefix to global prefix (so rest of address is same) or do general NAT6. That like that MY-R posted seemed to imply that the RFC/GAI rules might cause issues with such NAT scenario
2021-01-25 16:05:45 <minimal> s/to ways/two ways/
2021-01-25 16:05:45 <alpine-meetbot> minimal meant to say: well that was my point - there's two ways to NAT - either map ULA prefix to global prefix (so rest of address is same) or do general NAT6. That like that MY-R posted seemed to imply that the RFC/GAI rules might cause issues with such NAT scenario
2021-01-25 16:09:20 <minimal> Where a destination host has both IPv4 & IPv6 and where my local machine has IPv4 & ULA IPv6 and I have some form of IPv6 NAT in place and my app looks up a DNS name that returns both A and AAAA records will I be able to make a IPv6 connection to the destination?
2021-01-25 16:13:58 <minimal> dalias: which goes back to my earlier "question", does musl support reading a gai.conf file? (which might be needed to fudge around such a NAT6 issue if it exists)
2021-01-25 16:16:05 <dalias> no, musl does not support gai.conf, but it's not needed for this
2021-01-25 16:16:14 <dalias> sorting by routability will automatically handle it
2021-01-25 16:17:33 <minimal> and the routability handles the "IPv6 ULA address but no IPv6 global address" situation with NAT6 ok?
2021-01-25 16:20:30 <dalias> yes. the nat6 isn't important, just that your host has a route to the ipv6 result
2021-01-25 16:20:54 <minimal> ok. thanks.
2021-01-25 16:21:06 <dalias> if your routing tables are misconfigured and claim there's a route to it, but the router won't in turn route them, then you'll have problems
2021-01-25 16:21:17 <dalias> but that should not happen under normal ipv6 autoconfig
2021-01-25 16:21:41 <dalias> (i.e. assuming routers are not advertising routes they don't actually intend to honor)
2021-01-25 16:37:51 <minimal> dalias: I'm using ULA internally mainly for servers to communicate between themselves so using static config (don't want internal-only traffic to fail due to a dynamic announcement (DHCP/RA/whatever) failing).
2021-01-25 16:41:15 <dalias> *nod*
2021-01-25 16:41:36 <dalias> heh our getaddrinfo tries to compute routability on :: and 0.0.0.0
2021-01-25 16:41:58 <dalias> this should probably be dropped
2021-01-25 16:45:58 <minimal> well default route should be taken in account as in the above scenario those machines with ULA-only IPv6 addresses have a IPv6 default route pointing to the boundary router/firewall which will be doing IPv6 NAT6 to global addresses
2021-01-25 16:47:45 <dalias> yes
2021-01-25 16:48:46 <minimal> need a coffee now - too much IPv6 discussion makes my head hurt lol
2021-01-25 16:48:52 <dalias> :)
2021-01-25 16:49:36 <MY-R> oh yes, for ipv6 need special mood :D
2021-01-25 16:51:46 <MY-R> dalias: so if it isnt about ula etc why you need gai.conf at all?
2021-01-25 16:53:48 <MY-R> ahh 4to6 ok ok nevermind :)
2021-01-25 16:53:52 <dalias> well i need the default sorting without gai.conf
2021-01-25 16:55:04 <ncopa> maxice8: pong
2021-01-25 16:55:43 <maxice8> Linux-lts pkgrel wasn't reset
2021-01-25 16:56:24 <ncopa> ugh. i messed up the rebase
2021-01-25 16:56:59 <ncopa> im fixing it
2021-01-25 17:26:03 <skarnet> someone please merge !17448 so I can pretend a few embarrassing bugs never happened :)
2021-01-25 17:27:05 <ikke> any ABI changes? :)
2021-01-25 17:27:46 <ikke> looks like it doesn't
2021-01-25 17:29:33 <ikke> merged
2021-01-25 17:30:54 <skarnet> no, it's a pure bugfix release, no api changes at all
2021-01-25 17:30:57 <skarnet> thanks
2021-01-25 17:32:53 <dalias> :)
2021-01-25 18:48:31 <ikke> oof, gitlab is down
2021-01-25 18:52:00 <adhawkins> I was just about to say the same thing :)
2021-01-25 18:52:26 <ikke> Our monitoring warned me :)
2021-01-25 18:53:24 <adhawkins> If only the monitoring could fix it too! ;)
2021-01-25 18:56:16 <ikke> seems like network issues
2021-01-25 18:58:41 <ikke> https://status.linode.com/incidents/dm9mc14kv2t4
2021-01-25 18:58:44 <ikke> yup
2021-01-25 19:01:06 <adhawkins> While we've all got nothing to do, is the CI / build stuff available for me to run locally?
2021-01-25 19:01:21 <adhawkins> Would be nice to know I've got dependency issues before submitting a MR and looking like a fool :)
2021-01-25 19:02:10 <adhawkins> Let me guess, I can find it on gitlab? :)
2021-01-25 19:05:23 <ikke> 😉
2021-01-25 19:07:01 <adhawkins> Is it the sort of thing I could run locally on a specific branch of my aports fork?
2021-01-25 19:07:50 <ikke> The docker image is available
2021-01-25 19:08:14 <ikke> but, it requires you to setup to run like it would locally
2021-01-25 19:08:18 <ikke> I mean, on CI
2021-01-25 19:08:26 <ikke> alpinelinux/alpine-gitlab-ci
2021-01-25 19:09:54 <adhawkins> Yeah, I've found that on Google but obviously can't see the details at the moment.
2021-01-25 19:10:09 <adhawkins> How much setup does it need?
2021-01-25 19:10:30 <ikke> It needs some environment variables set
2021-01-25 19:10:53 <adhawkins> Oh ok. That doesn't sound too onerous.
2021-01-25 19:11:14 <adhawkins> I might have a look once gitlab returns. Would be a nice tool to add to the arsenal before submitting a MR.
2021-01-25 19:11:38 <ikke> https://tpaste.us/E19R
2021-01-25 19:11:56 <ikke> Not sure if there is a lot of difference with dabuild
2021-01-25 19:14:06 <adhawkins> The main issue I head earlier was that dabuild has all the repositories listed, and I'd neglected to move a dependency from testing to community.
2021-01-25 19:14:25 <adhawkins> dabuild worked, because it found the dependency in testing when building my package in community.
2021-01-25 19:15:59 <adhawkins> Looks like 'set_repositories_for' will re-write /etc/apk/repositories appropriately.
2021-01-25 19:16:19 <ikke> yes
2021-01-25 19:16:29 <ikke> that's what I was talking about earlier
2021-01-25 19:17:01 <adhawkins> Cool. So as long as I can duplicate that behaviour it would do what I want hopefully.
2021-01-25 20:04:47 <ikke> gitlab is back (for now)
2021-01-25 20:44:24 <adhawkins> ikke: Where do I find 'setup.sh' in https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci ?
2021-01-25 20:47:00 <adhawkins> I guess I could just pull the container image from Docker hub.
2021-01-25 21:04:05 <adhawkins> Ok, making some progress. What should the variable 'CI_MERGE_REQUEST_PROJECT_URL' be ikke?
2021-01-25 21:14:39 <adhawkins> Doesn't look like my 'environment' is set up correctly. What should the filesystem look like when I run the docker image? Should I be in the directory that contains my changes?
2021-01-25 21:15:29 <adhawkins> Looks like I need to see the docker invocation to see what filesystems are passed through.
2021-01-25 22:28:13 <sh4rm4^bnc> Hello71, it seems the latest xf86-video-modesetting release is 6+ years old. am  i missing something, or how it could it properly support latest GPUs ?
2021-01-25 22:30:52 <sh4rm4^bnc> oh, tracing back all the git mirrors to gitlab.fdo.org i found this "modesetting driver development history; driver is now included with xorg/xserver"
2021-01-25 22:31:09 <MY-R> sh4rm4^bnc: it is dummy package
2021-01-25 22:33:04 <mps>  /usr/lib/xorg/modules/drivers/modesetting_drv.so is owned by xorg-server-1.20.10-r0
2021-01-25 22:33:41 <sh4rm4^bnc> sigh. i just updated to xorg-server 1.18.4 two days ago
2021-01-25 22:34:49 <sh4rm4^bnc> i really hate messing around with these components, but the performance of the intel driver with sna disabled is awkward
2021-01-25 22:35:42 <MY-R> for me best working is intel driver with accel 'uxa' and disabled dri3
2021-01-25 22:36:03 <MY-R> at least dont have any screen tearing in window mode and in full screen
2021-01-25 22:36:29 <sh4rm4^bnc> MY-R: do you need any special settings to use the exa mode ?
2021-01-25 22:36:53 <MY-R> sh4rm4^bnc: nothing special, just file in /etc/X11/xorg.conf.d/
2021-01-25 22:37:04 <sh4rm4^bnc> would you mind pasting that ?
2021-01-25 22:37:11 <MY-R> sure, one sec
2021-01-25 22:38:40 <MY-R> sh4rm4^bnc: https://tpaste.us/0Ea6
2021-01-25 22:39:17 <sh4rm4^bnc> thanks, gonna try that
2021-01-25 22:39:39 <MY-R> sh4rm4^bnc: but all depends from your igpu
2021-01-25 22:39:55 <sh4rm4^bnc> it's 915 from 2018 era
2021-01-25 22:40:26 <MY-R> so is basically very new :)
2021-01-25 22:40:35 <sh4rm4^bnc> and yours ?
2021-01-25 22:40:42 <MY-R> mine is from haswell hd 4600
2021-01-25 22:40:57 <sh4rm4^bnc> that's older than, i suppose ?
2021-01-25 22:41:01 <MY-R> ye
2021-01-25 22:42:16 <sh4rm4^bnc> rebooting X...
2021-01-25 22:42:18 <MY-R> but modesetting didnt work great, I had screen tearing in firefox videos then switched to intel and was something else, that is why changed to uxa and still wasnt perfect, some weird lags and then found that disabling dri3 can help aaaand helped... annoying
2021-01-25 22:42:45 <sh4rm4^bnc> does dri3 need to be disabled at build time or in that config ?
2021-01-25 22:43:04 <MY-R> dri "2" option disabling dri3, by default dri3 is turned on
2021-01-25 22:43:24 <sh4rm4^bnc> (another odd thing, since i updated xorg to 1.18.4 my mpv doesn't work anymore with -vo=xv)
2021-01-25 22:43:34 <MY-R> sh4rm4^bnc: and good
2021-01-25 22:43:43 <MY-R> you shouldnt use xv vo but "gpu"
2021-01-25 22:44:01 <sh4rm4^bnc> xv used to work super fast on my old laptop
2021-01-25 22:44:16 <sh4rm4^bnc> almost 0% cpu use, even with CPU at 800mhz
2021-01-25 22:44:39 <MY-R> gpu will use intel acceleration  but for that need use vaapi or newer if your cpu support it
2021-01-25 22:45:40 <sh4rm4^bnc> with -vo=gpu as soon as i move the mouse over mpv window, it starts lagging
2021-01-25 22:45:46 <MY-R> you can use "vaapi/media driver" only too then wont touch your cpu too but with vo=gpu it will use just little cpu
2021-01-25 22:46:01 <MY-R> sh4rm4^bnc: then you need install vaapi/media driver stuff to suport it
2021-01-25 22:46:18 <sh4rm4^bnc> is that some binary driver stuff?
2021-01-25 22:46:53 <MY-R> sh4rm4^bnc: https://wiki.archlinux.org/index.php/Hardware_video_acceleration#Intel
2021-01-25 22:47:20 <MY-R> sh4rm4^bnc: https://01.org/linuxmedia/vaapi
2021-01-25 22:48:27 <MY-R> sh4rm4^bnc: if it would be binary then wouldnt work in Alpine because of musl I guess :)
2021-01-25 22:49:08 <sh4rm4^bnc> hurr. this stuff needs to built into Xorg or ffmpeg or how does it kick in?
2021-01-25 22:50:51 <MY-R> it working in Alpine, just need install packages
2021-01-25 22:51:07 <MY-R> sh4rm4^bnc: go to #alpine-linux lets not spam dev channel
2021-01-25 22:51:20 <sh4rm4^bnc> i'm doing my own distro sabotage, so i need some bg info :)
2021-01-25 22:52:04 <sh4rm4^bnc> anyway i'm gonna restart X to try your uxa settings...
2021-01-25 22:52:41 <tehcloud> sabotage has that awesome theme song
2021-01-25 22:52:54 <tehcloud> I love an OS with a theme song
2021-01-25 22:55:37 <MY-R> sh4rm4^bnc: if you have broadwell cpu or newer then need "intel-media-driver"
2021-01-25 22:55:49 <MY-R> sh4rm4^bnc: with older is probably enough to install "mesa-dri-intel" and "libva-utils" and check with "vainfo" if working
2021-01-25 23:00:32 <sh4rm4^bnc> uxa settings seem to work, browser appears slightly more responsive
2021-01-25 23:01:28 <sh4rm4^bnc> for example on this page scrolling with the mouse is still very laggy https://gta.fandom.com/wiki/Civil_Asset_Forfeiture_Impound#Car_List_3
2021-01-25 23:02:09 <MY-R> sh4rm4^bnc: firefox?
2021-01-25 23:02:16 <sh4rm4^bnc> palemoon
2021-01-25 23:02:48 <sh4rm4^bnc> while using the sna driver (which crashed the whole sys every few minutes) scolling around was a lot quicker
2021-01-25 23:04:54 <MY-R> sh4rm4^bnc: did you try with "layers.acceleration.force-enabled = true" in "about:config" and restart browser
2021-01-25 23:06:50 <sh4rm4^bnc> hey wow, that makes a huge difference
2021-01-25 23:06:57 <MY-R> ofc
2021-01-25 23:07:07 <sh4rm4^bnc> do you have a solution for any problem ? :)
2021-01-25 23:07:18 <MY-R> but I think latest firefox got it already enabled by default
2021-01-25 23:07:54 <sh4rm4^bnc> the option is called slightly different in palemoon (just force) but it was disabled
2021-01-25 23:07:59 <MY-R> forcing layers working fine but if wanna fire up gpu/igpu then enabling webrender doing best job but accelerating layers only is fine enough
2021-01-25 23:09:38 <MY-R> and layers are safer, webrender was abble to crash from time to time but ye, acceleration stuff is from what I start when installing any distro and windows
2021-01-25 23:10:07 <sh4rm4^bnc> cool, this is really helpful. thanks!
2021-01-25 23:10:24 <sh4rm4^bnc> gonna try the intel vaapi stuff when mpv lag annoys me enough
2021-01-25 23:10:30 <MY-R> sh4rm4^bnc: on Arch wiki can find some stuff from what can start
2021-01-25 23:11:05 <sh4rm4^bnc> optimally i'd just find out why -vo=xv no longer works and get it re-enabled...
2021-01-25 23:11:42 <MY-R> mpv with "gpu" and working acceleration should working great especially on newer cpu's
2021-01-25 23:12:44 <sh4rm4^bnc> i see. kinda logical if they build mpeg accel stuff into the GPU.
2021-01-25 23:13:27 <MY-R> yep
2021-01-25 23:14:07 <MY-R> need try everything to find golden solution
2021-01-25 23:15:51 <sh4rm4^bnc> i was actually about to start debugging the SNA driver to find out where the memory corruption comes from, eventually spending days...
2021-01-25 23:16:02 <MY-R> sh4rm4^bnc: install "libva-utils" and use "vainfo" command to check if video decoding working
2021-01-25 23:16:25 <MY-R> I didnt have luck with sna too
2021-01-25 23:17:55 <sh4rm4^bnc> the firefox acceleration option fix is more than sufficient, so no need to dig into the messy driver anymore
2021-01-25 23:19:06 <MY-R> glad I could help you, I know how annoying it can be when things working like on 15 years old computer
2021-01-25 23:20:33 <sh4rm4^bnc> indeed, the performance of the browser was equivalent to my 10 year old PC which i shelved last week
2021-01-25 23:23:16 <MY-R> sh4rm4^bnc: oh that package is for older "libva-intel-driver" and that is for broadwell+ cpus "intel-media-driver"
2021-01-25 23:23:41 <MY-R> to have vaapi support in mpv/firefox etc
2021-01-25 23:25:00 <sh4rm4^bnc> my cpu seems to be name kaby lake
2021-01-25 23:27:42 <MY-R> sh4rm4^bnc: then install intel-media-driver
2021-01-25 23:28:27 <MY-R> restart xorg and check what got in "vainfo"
2021-01-25 23:28:55 <mps> hmm, looks like "layers.acceleration.force-enabled = true" also helps with panfrost driver
2021-01-25 23:37:49 <MY-R> :]
2021-01-25 23:39:58 <mps> so I can use panfrost by default now, except st is more lags, but will see
2021-01-25 23:40:06 <sh4rm4^bnc> hmm.. i'll leave that va stuff for another, there's a sufficient amount of dependencies that this will take a couple hour to steal and integrate the recipes into my distro
2021-01-25 23:40:12 <sh4rm4^bnc> *another day
2021-01-26 00:41:33 <Hello71> xv is very obsolete
2021-01-26 00:42:02 <Hello71> most likely why xv appears faster is because it's producing a vastly inferior result
2021-01-26 00:42:16 <Hello71> bilinear scaling etc
2021-01-26 00:44:39 <sh4rm4^bnc> i really don't mind that - i only watch documentaries and that in 640x400
2021-01-26 00:58:40 <dalias> what would you prefer over bilinear?
2021-01-26 01:05:53 <Hello71> hm... actually bilinear is still the default with gpu without other options. --profile=gpu-hq --sclae=ewa_lanczossharp is recommended by mpv
2021-01-26 01:06:15 <Hello71> gpu-hq sets --scale=spline36 which is rated as "Mid quality and speed" by the manual
2021-01-26 01:06:28 <Hello71> s/sclae/scale/
2021-01-26 01:06:29 <alpine-meetbot> Hello71 meant to say: hm... actually bilinear is still the default with gpu without other options. --profile=gpu-hq --scale=ewa_lanczossharp is recommended by mpv
2021-01-26 01:08:03 <Hello71> the mpv manual also says that "xv [...] is the most compatible VO on X, but may be low-quality, and has issues with OSD and subtitle display." and that "This driver is for compatibility with old systems."
2021-01-26 01:10:08 <Hello71> if your gpu is newer than 2010 then playing 640x480 video should be entirely fast enough with vo=gpu and no hwdec
2021-01-26 01:10:40 <MY-R> ewa_lanczossharp will kill that igpu
2021-01-26 01:10:58 <Hello71> ah, i wasn't clear. for that last part i meant "with the defaults"
2021-01-26 01:11:33 <MY-R> but if you watch low resolution stuff then can think about better downscaling setting
2021-01-26 01:11:46 <Hello71> downscaling?
2021-01-26 01:12:09 <MY-R> ye
2021-01-26 01:12:12 <Hello71> does anyone actually use mpv with monitors outputting less than 640x480?
2021-01-26 01:12:23 <Hello71> think you are confused about direction
2021-01-26 01:12:58 <MY-R> wait, ye
2021-01-26 01:13:43 <MY-R> upscaling is for low resolution videos on high resolution screen
2021-01-26 01:14:01 <MY-R> right? or I just drank too much coffee....
2021-01-26 01:18:22 <MY-R> yeah so scale=spline36 will make videos just a little sharper without loosing performance, just checked it in my mpv config
2021-01-26 01:43:40 <dalias> hello71, bilinear is default because it's the only reasonable one :)
2021-01-26 01:49:53 <sh4rm4^bnc> many gamers like those fancy hq2x etc scalers e.g. shipped in dosbox
2021-01-26 01:50:38 <dalias> yeah but they dont work on video
2021-01-26 01:50:44 <dalias> only on pixel art
2021-01-26 01:58:26 <Hello71> the manual says that bilinear is the default for backwards compatibility only
2021-01-26 01:59:16 <Hello71> i.e. some computers are too shit to do anything good
2021-01-26 01:59:42 <dalias> well that's wrong. the "good" ones are just shit :)
2021-01-26 02:00:56 <Hello71> also movies != videos etc
2021-01-26 02:02:54 <Hello71> no. the best scaler is the one that comes closest to the original signal, before sampling (nyquist etc). the definition of "closest" is somewhat subjective but it's not "whichever one is blurriest"
2021-01-26 02:04:32 <dalias> that's not really a well-defined metric
2021-01-26 02:05:59 <dalias> frequency-domain stuff on video isn't really sound to reason from because signals aren't band limited, at least not anywhere near the resolution you sample at
2021-01-26 02:06:14 <dalias> they have what are essentially sharp discontinuities
2021-01-26 02:26:16 <Hello71> right, but that only says that you can't perfectly reconstruct the original signal
2021-01-26 02:26:35 <Hello71> but there's still a right answer
2021-01-26 02:27:44 <Hello71> and image and video processing regularly works in the frequency domain
2021-01-26 02:28:08 <Hello71> as an old example, jpeg dct
2021-01-26 02:28:46 <dalias> it works decently as a form for efficient approximation, especially if you can represent the error well too
2021-01-26 02:38:44 <dalias> but re:scaling, it's trivial that any filter with negative taps will do wrong things
2021-01-26 07:22:42 <Guest69607> Hi there. I am trying to setup a Dell server here with Alpine Linux + fakeraid + LVM + LUKS2, with an encrypted /boot partition. From the install guide, there is this statement: "If using at least Alpine v3.11 and GRUB2 with encrypted /boot, the following should be used instead (because GRUB2 does not yet support LUKS2 containers):". So is GRUB2 officially supported now, for encrypted /boot?
2021-01-26 07:59:44 <maxice8> 50c2367aa4d added an options= overriding the previous options=
2021-01-26 08:00:13 <maxice8> 50c2367aa4df5edf1cc098bd1cccd58b16bb1af3
2021-01-26 08:19:52 <maxice8> ncopa: ping, I mentioned you in some abuild MRs that I think are ready for final-review and merge
2021-01-26 08:54:55 <ncopa> morning
2021-01-26 08:55:05 <ncopa> I'll have a look at it soon(ish)
2021-01-26 09:05:20 <maxice8> morning, thanks
2021-01-26 09:05:55 <maxice8> If we can get a new release would be great because apkbuild-pypi has been substantially improved
2021-01-26 09:09:31 <maxice8> about python3.9, any plans for fixing the triplet ?
2021-01-26 09:14:26 <ncopa> im working on alpine 3.13.1. i doubt i will have time for abuild release today. will try get it done later this week
2021-01-26 09:14:59 <ncopa> i'd like to discuss how to do the python 3.9 with dalias. didnt have time to follow that up yesterday sorry
2021-01-26 09:16:26 <ncopa> we should investigate if we need to make changes in our python build to be able to support precompiled python wheels with musl
2021-01-26 09:16:36 <mps> just made MR for dnsmasq upgrade 2.84, there are some bugfix, should that be backported to 3.13.1?
2021-01-26 09:16:43 <ncopa> sure
2021-01-26 09:16:47 <mps> ok
2021-01-26 09:18:50 <ncopa> i had a look at the python wheels yesterday but didnt come to any conclusion
2021-01-26 09:19:31 <ncopa> the whole thing seems a bit messy, and it seems like it is convenient for python community to simply ignore musl
2021-01-26 09:23:31 <mps> heh
2021-01-26 09:37:49 <ncopa> ikke: do you have tim to have a look at #12325 now?
2021-01-26 09:53:20 <ikke> ncopa: sadly no
2021-01-26 09:53:49 <ncopa> ok. im investigating myself then
2021-01-26 09:54:00 <ncopa> i'd like to reproduce the problem in a vm if possible
2021-01-26 09:54:21 <ncopa> looks like there are 4 disks in the vg0
2021-01-26 09:55:24 <ikke> It seems somewhat hardware related, though not sure
2021-01-26 09:55:59 <ncopa> i think what happens is that vgchange is called from nlplug-findfs before all disks are available
2021-01-26 09:56:18 <ncopa> that should be reproducible in a vm
2021-01-26 09:56:53 <ikke> I don't see vg_change called at all
2021-01-26 09:57:18 <ikke> I should've included a bit more logs
2021-01-26 10:26:33 <adhawkins> Looks like my latest MR has been merged. Didn't see any response from the maintainer of py3-arrow though.
2021-01-26 10:26:44 <adhawkins> !17437
2021-01-26 10:38:36 <adhawkins> Looks like the build has failed on all architectures though. Looks like the git checkout failed.
2021-01-26 10:40:47 <mps> adhawkins: don't see it failed, do you have log url
2021-01-26 10:41:21 <adhawkins> https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/305110
2021-01-26 10:41:42 <mps> hmm, ppc64le builder is stuck at testing/bpytop 1.0.60-r0
2021-01-26 10:41:47 <adhawkins> At the top of the merge request, it says the build and lint both failed. Build looks to have failed on all architectures.
2021-01-26 10:41:57 <maxice8> it was already merged
2021-01-26 10:42:10 <maxice8> don't worry about it
2021-01-26 10:42:10 <mps> adhawkins: this is not builders
2021-01-26 10:42:23 <maxice8> the builders are here: https://build.alpinelinux.org/
2021-01-26 10:42:27 <maxice8> and on #alpine-commits
2021-01-26 10:42:40 <mps> yes, #alpine-commits show these passed
2021-01-26 10:42:48 <adhawkins> Ah, apologies. Wrong terminology.
2021-01-26 10:43:03 <adhawkins> I saw the messages in alpine-commits, which was why I went back to look at the MR and found these failures.
2021-01-26 10:43:11 <mps> all looks good, no worries
2021-01-26 10:43:45 <adhawkins> Ok. This still shows it in testing. https://pkgs.alpinelinux.org/packages?name=&branch=edge&arch=x86_64&maintainer=Andy+Hawkins
2021-01-26 10:44:24 <mps> need some time to synchronize all things
2021-01-26 10:44:44 <adhawkins> Thought that would be the case. Thanks for my continued education maxice8 and mps :)
2021-01-26 10:48:10 <mps> ncopa: (yes, you are busy but who is not) I think to merge !16940 and add fixes later, to not wait too long for these changes
2021-01-26 10:50:02 <mps> I need to clean local branches to work further on cross-embedded tools, they are needed for building 'boot loader' for apple M1
2021-01-26 10:50:30 <mps> I would like to run alpine RSN on this machine
2021-01-26 10:50:55 <mps> (at least to try)
2021-01-26 11:26:10 <ikke> ncopa: I have some time now
2021-01-26 11:32:08 <ikke> rebooted usa7 with 5.10 kernel
2021-01-26 11:43:19 <ikke> ncopa: interestingly, now when I run nlplug-findfs manually, it no longer seems to discover the lvm volumes
2021-01-26 12:04:21 <Hello71> try running it again
2021-01-26 12:04:41 <Hello71> did you try the other things i suggested?
2021-01-26 12:07:27 <ikke> Hello71: not yet
2021-01-26 12:07:39 <ikke> But I forgot to provide the rootfs
2021-01-26 12:07:46 <ikke> Hello71: check https://gitlab.alpinelinux.org/alpine/aports/-/issues/12325#note_138465
2021-01-26 12:25:15 <ikke> Hello71: I did not have a lot of time so I could not try a lot of things, just wanted to get more logging first
2021-01-26 12:25:19 <ikke> -
2021-01-26 12:25:21 <Hello71> ok
2021-01-26 12:26:06 <ikke> The issue contains logging with quiet removed and debug_init=1
2021-01-26 12:26:14 <Hello71> I'm not sure what's going on here, but your ahci enumeration is quite slow. probably that is a factor
2021-01-26 12:30:35 <Hello71> maybe nlplug-findfs is losing events?
2021-01-26 12:32:41 <Hello71> https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/nlplug-findfs.c#L421
2021-01-26 12:32:58 <Hello71> 512/16=32
2021-01-26 12:34:00 <ikke> 32 events?
2021-01-26 12:35:26 <Hello71> apparently
2021-01-26 12:35:52 <Hello71> https://git.busybox.net/busybox/tree/util-linux/mdev.c#n1154 says that's way too small
2021-01-26 12:39:01 <Hello71> but it also says that kernel should set ENOBUFS in that case which we don't seem to get
2021-01-26 12:39:29 <Hello71> maybe because we are using recvmsg?
2021-01-26 12:39:40 <Hello71> doesn't add up
2021-01-26 12:42:11 <Hello71> could be worth increasing it
2021-01-26 12:52:02 <ikke> Yeah
2021-01-26 12:58:03 <adhawkins> Anyone familiar with how the CI stuff works help me running a similar build locally? I've got the Docker container but can't work out how to set it up to build against a local tree or specific branch.
2021-01-26 13:04:15 <ikke> I have time later today
2021-01-26 13:06:55 <adhawkins> That'd be great ikke, thanks.
2021-01-26 13:11:55 <adhawkins> Just thought I'd say I now have a Docker build based on Alpine that installs emborg from the 'community' tree. Thanks to everyone who helped me get this far. I'll do my best to keep on top of the packages and keep them updated.
2021-01-26 13:44:23 <timlegge> adhawkins: not sure if you are aware of https://repology.org/repository/alpine_edge you can search for packages you maintain by your email address and it makes it easier to know when to update them
2021-01-26 13:45:19 <adhawkins> Oooh, that's useful timlegge. I've just been subscribing to their github repos. Will take a look at that site.
2021-01-26 13:46:29 <ikke> That does rely on other projects updating it first
2021-01-26 13:48:29 <timlegge> hmm.  I guess in my case most of the packages are perl so they are updated on CPAN first - python would likely be similar if it is released on PYPI but I guess that is an issue I never thought of...
2021-01-26 13:51:23 <ikke> yeah, there are also some wiki like projects that are fairly quick for most projects
2021-01-26 13:52:41 <maxice8> They have per maintainer RSS feed
2021-01-26 13:55:29 <adhawkins> It looks like it might not have 'matched up' a couple of my packages, as it has no 'latest' version listed for them.
2021-01-26 13:55:37 <adhawkins> Pretty sure they're all on PyPi
2021-01-26 13:56:07 <adhawkins> Interestingly. they both have a '-' in their names. Think upstream uses an '_'. Should I have matched that?
2021-01-26 14:05:23 <adhawkins> The two packages are python.quantiphy-eval and python.rkm-codes
2021-01-26 14:05:59 <adhawkins> These are https://pypi.org/project/quantiphy-eval/ and https://pypi.org/project/rkm-codes/ respectively
2021-01-26 14:06:13 <adhawkins> Looking at them, they do use a '-' after all...
2021-01-26 14:08:18 <ikke> Repology has rules to match package names to upstream names
2021-01-26 14:08:37 <ikke> There is a repo on github that contains those rules
2021-01-26 14:10:49 <adhawkins> Ah ok. I'll take a look.
2021-01-26 14:12:11 <adhawkins> There doesn't appear to be any other mentions of 'quantiphy' on there to match up to (for the quantiphy-eval package)
2021-01-26 14:12:37 <adhawkins> Similarly the rkm codes one.
2021-01-26 14:14:53 <adhawkins> I've submitted an issue on there, will see what happens.
2021-01-26 14:17:18 <ikke> Note that there are also generic rules, so specific packages do not necessarily be mentioned
2021-01-26 14:18:42 <adhawkins> But if I search repology.org for 'quantiphy' or 'rkm' it doesn't bring up any other versions of the package as far as I can see.
2021-01-26 14:18:50 <adhawkins> So it's as if it hasn't even found them on PyPi.
2021-01-26 14:19:39 <ikke> Or you are the first one to package it
2021-01-26 14:19:45 <adhawkins> They're on PyPi
2021-01-26 14:19:54 <adhawkins> Repology says it indexes PyPi too.
2021-01-26 14:19:59 <ikke> Hmm
2021-01-26 14:21:18 <ikke> python:quantiphy
2021-01-26 14:22:51 <adhawkins> Yes, but there's also python:quantiphy-eval (they're different packages)
2021-01-26 14:22:57 <adhawkins> It's matched up the first one, but not the second.
2021-01-26 14:23:22 <adhawkins> https://pypi.org/project/quantiphy/
2021-01-26 14:23:31 <adhawkins> https://pypi.org/project/quantiphy-eval/0.1.0/
2021-01-26 14:32:00 <minimal> Guest69607: version of GRUB2 in Alpine is 2.04 (from July 2019). There has been no upstream release of GRUB2 since then and so unfortunately there is currently no support for LUKS2 in Alpine's GRUB2. As upstream only appear to do even-numbered releases (e.g. there was no GRUB 2.01 release) then it will appear in GRUB 2.06 (likely April/May 2021). Current GRUB2 in Alpine does have encrypted boot support so you can use that with LUKS1
2021-01-26 15:24:38 <ozzz> Hello all! I solved battery discharging value by setting max CPU freq limit.
2021-01-26 15:25:30 <ozzz> maybe it helps somebody: sudo echo 700000 > /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq
2021-01-26 15:25:47 <ozzz> It must be done for all cores
2021-01-26 15:25:55 <mps> ozzz: are you on intended channel
2021-01-26 15:26:04 <ozzz> sorry....
2021-01-26 15:30:52 <ikke> ozzz: ofcourse, thottling your CPU will reduce battery usage :)
2021-01-26 15:31:14 <ikke> You might also set a specific govenor to achieve the same
2021-01-26 15:32:47 <mps> especially 'printf 0 > /sys/devices/system/cpu/cpu3/cpufreq/scaling_max_freq' :)
2021-01-26 15:33:09 <ikke> mps: what that actually do something?
2021-01-26 15:33:11 <ozzz> zero ) Is it possible anyway?
2021-01-26 15:33:53 <mps> you people lost sense of humor ;)
2021-01-26 15:34:21 <ikke> mps: No, I found it funny, just wondering what it would even do
2021-01-26 15:34:26 <ozzz> ikke: I just left it working, until whole alpine repo won't be recompiled
2021-01-26 15:34:37 <ozzz> sorry guys, I turned it into gentoo :)
2021-01-26 15:34:38 <mps> ikke: no '0' is possible
2021-01-26 15:36:16 <mps> cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_available_frequencies, will tell possible ones
2021-01-26 15:36:32 <mps> cpu3 is cpuX
2021-01-26 15:37:50 <ozzz> with 1300mgz it sucks out a life from battery
2021-01-26 15:38:55 <mps> cat /sys/devices/system/cpu/cpu3/cpufreq/scaling_available_governors, and select one which will be good for use case
2021-01-26 15:39:30 <mps> printf it to /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
2021-01-26 15:40:05 <mps> ondemand is what most 'people on battery' likes
2021-01-26 15:41:00 <ozzz> mps: great! Thanks!
2021-01-26 15:41:51 <mps> ozzz: np
2021-01-26 15:43:59 <mps> also, on different kernel builds not all governors enabled by default, usually they are in modules which needs to be explicitly loaded (modprobe)
2021-01-26 15:52:42 <ozzz> mps: sure. I enabled it. It was fun to setup/compile. Frontswap helped a lot, tablet has only 1gb of ram.
2021-01-26 15:53:42 <mps> ozzz: build on tablet, you are brave
2021-01-26 15:54:46 <ozzz> :) seems yes. /var/cache /var/tmp on NBD, tmpfs for /tmp, swap over nbd
2021-01-26 15:55:25 <ozzz> I hope compilation wont kill ecc flash
2021-01-26 15:57:03 <mps> but sometimes I build some things on arm SBCs with FS on mmc and 1GB RAM
2021-01-26 15:58:52 <mps> uh, 'Job's log exceeded limit of 104857600 bytes.' on CI. will it pass on builders?
2021-01-26 16:52:35 <ikke> adhawkins: ping
2021-01-26 16:53:31 <adhawkins> Here ikke.
2021-01-26 16:54:22 <ikke> ok, so the main idea behind how that image works is that it detects what it needs to build by comparing the current branch against a target branch
2021-01-26 16:54:42 <adhawkins> I get that. What I couldn't work out was what I needed to pass into the container to get it to run.
2021-01-26 16:54:52 <adhawkins> I assume I need to mount a git checkout, and then run the command.
2021-01-26 16:54:57 <ikke> you run the build.sh script
2021-01-26 16:55:35 <adhawkins> Yes, but presumably I need to have mounted the git repo somewhere for it to find it?
2021-01-26 16:55:44 <adhawkins> This is as far as I got: docker run -e CI_DEBUG_BUILD=1 -e CI_PROJECT_DIR=/home/andy/alpine-packaging/aports/emborg/ -e CI_MERGE_REQUEST_TARGET_BRANCH_NAME=master -e CI_MERGE_REQUEST_PROJECT_URL=origin  -v /home/andy:/home/andy alpinelinux/alpine-gitlab-ci:latest-x86_64 /usr/local/bin/build.sh
2021-01-26 16:56:04 <ikke> adhawkins: it expects the repo to be PWD
2021-01-26 16:56:17 <ikke> so add -w /home/andy
2021-01-26 16:56:29 <adhawkins> What does -w do?
2021-01-26 16:56:41 <ikke> set the working dir
2021-01-26 16:56:48 <ikke> the CI_PROJECT_DIR needs to be the root of the repo
2021-01-26 16:56:59 <ikke> you cannot specify just a single package to build
2021-01-26 16:57:18 <adhawkins> That dir is the root of the repo I called the local dir 'emborg' as that's what I was working on.
2021-01-26 16:57:29 <adhawkins> So -w should point to the top of the repo?
2021-01-26 16:57:37 <ikke> yes
2021-01-26 16:58:23 <adhawkins> Ok, it's doing something now. Looks like it's building perl?
2021-01-26 16:58:48 <adhawkins> Do I need to make sure my repo's master matches edge/master?
2021-01-26 16:59:24 <adhawkins> Should the -w include the 'community' part? Or should it point to the directory above?
2021-01-26 16:59:30 <ikke> the directory above
2021-01-26 16:59:47 <ikke> It expects the repository to be checked out at the branch with commits you want to build
2021-01-26 16:59:51 <adhawkins> Ok, that's what I've done. It's building lots of stuff...
2021-01-26 17:00:06 <ikke> it looks at git diff --name-only master...HEAD
2021-01-26 17:00:24 <adhawkins> Let me make sure I've updated master to upstream.
2021-01-26 17:01:19 <ikke> the build.sh script should make sure the target branch is up-to-date: https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh#L141
2021-01-26 17:03:14 <adhawkins> Where should CI_PROJECT_DIR point to?
2021-01-26 17:03:30 <ikke> the same as you pass to -w
2021-01-26 17:03:46 <ikke> (these variables normally come from gitlab)
2021-01-26 17:04:03 <adhawkins> What about CI_MERGE_REQUEST_TARGET_BRANCH_NAME and CI_MERGE_REQUEST_PROJECT_URL
2021-01-26 17:04:09 <adhawkins> I have them set to 'master' and 'origin'.
2021-01-26 17:04:15 <ikke> Should work
2021-01-26 17:04:22 <adhawkins> Should origin actually be upstream (the main alpine aports repo)
2021-01-26 17:04:27 <adhawkins> origin is my fork of that.
2021-01-26 17:05:05 <ikke> should be the main aports repo, otherwise, if your forks master is behind, it will build too much :)
2021-01-26 17:05:13 <adhawkins> That could be why.
2021-01-26 17:05:31 <ikke> so https://gitlab.alpinelinux.org/alpine/aports.git
2021-01-26 17:05:48 <adhawkins> That's the 'upstream' remote in my local repo
2021-01-26 17:06:04 <adhawkins> 'origin' is 'https://gitlab.alpinelinux.org/adhawkins/aports.git'
2021-01-26 17:06:16 <adhawkins> Ok, that looks to have worked!
2021-01-26 17:06:25 <adhawkins> docker run -e CI_DEBUG_BUILD=1 -e CI_PROJECT_DIR=/home/andy/alpine-packaging/aports/emborg/ -e CI_MERGE_REQUEST_TARGET_BRANCH_NAME=master -e CI_MERGE_REQUEST_PROJECT_URL=upstream  -v /home/andy:/home/andy -w /home/andy/alpine-packaging/aports/emborg/ alpinelinux/alpine-gitlab-ci:latest-x86_64 /usr/local/bin/build.sh
2021-01-26 17:08:20 <adhawkins> Only errors I'm seeing are 'build package already in repo' which I guess is Ok.
2021-01-26 17:08:30 <adhawkins> Let me move one of the dependencies back to testing and see if it picks that up.
2021-01-26 17:09:53 <adhawkins> Ah, but that won't work because that dependency is actually available in community now...
2021-01-26 17:10:18 <adhawkins> Oh well, looks like it's doing the 'correct' thing. Will give it a try if I need to make any changes.
2021-01-26 17:10:32 <adhawkins> I was nearly there, just missing a couple of key pieces of information. Thanks again ikke.
2021-01-26 17:10:39 <ikke> no problem
2021-01-26 17:22:10 <adhawkins> Regarding repology.org, it seems the process that looks for 'interesting' modules on PyPy is run manually. The admin of repology has kicked that process off, and it's now picked up one of the two packages it knew nothing about. I assume the other will follow as the process continues.
2021-01-26 17:22:36 <ikke> aha
2021-01-26 17:23:29 <ikke> probably means you will not get usefull version update information for those packages
2021-01-26 17:27:47 <adhawkins> No, I think it's just the first time it realises that package is of interest. I guess it doesn't monitor *every* package on PyPi, only those that are also packages elsewhere.
2021-01-26 17:28:00 <adhawkins> The process that realises it's packaged elsewhere too is the one that had to be run manually I think.
2021-01-26 17:28:12 <adhawkins> https://repology.org/projects/?maintainer=andy%40gently.org.uk&inrepo=alpine_edge&newest=1
2021-01-26 17:28:42 <adhawkins> You can see it now knows that quantiphy-eval is used in 2 places (alpine and PyPi) but rkm-codes only 1 (currently alpine, but I assume as it indexes PyPi it will spot it there too)
2021-01-26 17:29:05 <ikke> maybe it will start look for version bumps for those packages now
2021-01-26 17:29:52 <adhawkins> That's what I'm hoping, yes.
2021-01-26 17:29:57 <dalias> ncopa, what is the python issue?
2021-01-26 17:30:31 <mps> heh
2021-01-26 17:30:31 <adhawkins> Right, time to prepare food. Thanks again for the assistance ikke. I'll probably disappear for a while now until I start getting notifications that there are new upstream versions of those packages.
2021-01-26 17:30:50 <adhawkins> I at least have a docker container running emborg that just installs it from 'community' now.
2021-01-26 17:30:51 <ikke> I don't know all the details, but it's about what triplet we should use for python, something to do with python wheel supporting musl
2021-01-26 17:31:10 <ikke> python wheels*
2021-01-26 17:32:15 <artok> gcc -dumpmachine ?
2021-01-26 17:32:33 <ikke> https://tpaste.us/QWal
2021-01-26 17:32:47 <ikke> part of relevant chat log
2021-01-26 17:33:13 <artok> oh gosh it has also that old .guess
2021-01-26 17:33:30 <ikke> "@ncopa │ dalias: IIRC you once mentioned that it maybe was not a good idea to build python as x86_64-linux-gnu?"
2021-01-26 17:34:01 <dalias> ah yes
2021-01-26 17:34:15 <dalias> indeed that's going to make it pull glibc binaries
2021-01-26 17:34:27 <dalias> from pip's binary repos
2021-01-26 17:36:21 <ikke> right, but we'd still have to convince those projects to build for musl as well
2021-01-26 17:36:41 <dalias> well, if they don't it should grab source and build from source
2021-01-26 17:36:53 <dalias> which is much better than trying to pull glibc binaries
2021-01-26 17:36:55 <ikke> I think that's part of the issue
2021-01-26 17:37:03 <dalias> ?
2021-01-26 17:37:20 <ikke> @ncopa │ basically, i'm interested in fixing this: https://lih-verma.medium.com/alpine-makes-python-docker-builds-way-too-50-slower-and-images-double-2-larger-61d1d43cbc79
2021-01-26 17:40:22 <artok> sure, slower build time, but that "big image" is just because there is no proper purge
2021-01-26 17:41:36 <ikke> yes, that's clear
2021-01-26 17:41:43 <ikke> nowadays you'd even use build stages
2021-01-26 17:41:51 <ikke> so that you can leave the mess behind in the build container
2021-01-26 17:41:57 <dalias> *nod*
2021-01-26 17:42:53 <ikke> https://github.com/pypa/manylinux/issues/37
2021-01-26 17:42:55 <Hello71> did docker not have build stages in Feb 5, 2020?
2021-01-26 17:43:18 <artok> Hello71: many python people don't know how to use 'em
2021-01-26 17:43:30 <Hello71> 17:41 <@ikke> nowadays you'd even use build stages
2021-01-26 17:43:59 <ikke> well, before you had to clean it up manually
2021-01-26 17:44:18 <artok> build wheels on first stage, install 'em on virtual env, start new stage, install python, copy the virtual env.
2021-01-26 17:44:33 <ikke> artok: why not copy the wheels over?
2021-01-26 17:44:34 <artok> and cleaning was needed on same run command
2021-01-26 17:44:47 <artok> ikke: because that copy layer is saved on image
2021-01-26 17:44:54 <maxice8> Also didn't remove the build dependencies
2021-01-26 17:45:26 <ikke> RUN apk add -t build-depends foo bar && ... && apk del build-depends
2021-01-26 17:45:29 <ikke> hehe
2021-01-26 17:45:30 <artok> if you copy wheels, one layer has whl files that are then installed, even they're not needed after that
2021-01-26 17:45:48 <ikke> right
2021-01-26 17:46:08 <Hello71> what is the way now?
2021-01-26 17:46:11 <maxice8> ¯\_(ツ)_/¯
2021-01-26 17:47:43 <artok> that's why I tend to install thingies into /opt/service, then copy that over to last stage, do readelf recursively to check what libraries are needed, and install, and also purge any unneeded data (in single run command)
2021-01-26 17:49:10 <artok> last stage is then: FROM, COPY, RUN, ENTRYPOINT, CMD
2021-01-26 17:49:12 <artok> one of each
2021-01-26 17:52:02 <Hello71> sounds suspiciously like nix
2021-01-26 17:52:23 <Hello71> except nix is crazy enough to just grep for dependencies
2021-01-26 18:04:07 <artok> I'll run test for that same package
2021-01-26 18:18:29 <skarnet> it's just that /opt and nix share the common concept of using filesystem structure as a way to store metadata, and only FHS is small-brain enough as to... not do that
2021-01-26 18:22:15 <DylanVanAssche_> I want to upstream `feedbackd-device-themes` to Alpine, normally new packages should go to `testing`, but `feedbackd` (in `community`) depends on it. Should I put it directly in `community` then?
2021-01-26 18:22:44 <ikke> DylanVanAssche_: yes
2021-01-26 18:23:02 <DylanVanAssche_> ikke: Ok, thanks!
2021-01-26 18:23:03 <ikke> Please add that to the commit message
2021-01-26 18:23:40 <c705> can we grab sudo 1.9.5p2 for 3.13? Real nasty bug just got published as CVE-2021-3156
2021-01-26 18:24:03 <ikke> c705: details?
2021-01-26 18:24:09 <c705> CVE-2021-3156
2021-01-26 18:24:58 <jvoisin> https://www.sudo.ws/alerts/unescape_overflow.html
2021-01-26 18:25:01 <jvoisin> https://www.openwall.com/lists/oss-security/2021/01/26/3
2021-01-26 18:26:16 <ikke> ouch
2021-01-26 18:27:02 <jvoisin> don't use sudo :/
2021-01-26 18:27:21 <ikke> I'm switching to doas
2021-01-26 18:27:37 <Hello71> why is it & in one place and ISSET in another anyways
2021-01-26 18:28:07 <c705> bugs happen. let's just patch it up and move on
2021-01-26 18:30:41 <Hello71> "Unfortunately, this initial technique failed [...] Fortunately, however, our brute-forcer produced dozens of unique Sudo crashes and gdb backtraces" -.-
2021-01-26 18:31:11 <c705> "...among these, three caught our attention, and"
2021-01-26 18:31:11 <c705> we eventually exploited all three.
2021-01-26 18:31:40 <ikke> No backports either
2021-01-26 18:48:00 <maxice8> kdaudt are sudo 'p' safe to upgrade ?
2021-01-26 18:48:04 <maxice8> on backports
2021-01-26 18:48:22 <ikke> I have no idea
2021-01-26 18:48:30 <ikke> I would assume so
2021-01-26 18:48:32 <ikke> patch releases
2021-01-26 18:49:22 <ikke> It's listed under stable releases: https://www.sudo.ws/stable.html
2021-01-26 18:49:36 <maxice8> would be much more convenient if I could update 3.12 which is on 1.9.0 to 1.9.5p2
2021-01-26 18:50:10 <c705> yeah, I think it's stable
2021-01-26 18:50:26 <c705> don't see why that would be an issue. thought 3.12 was EOL anyways
2021-01-26 18:50:49 <ikke> no
2021-01-26 18:50:54 <maxice8> not for secfixes
2021-01-26 18:51:00 <c705> when does it EOL?
2021-01-26 18:51:01 <ikke> packages in main down to 3.10 are stil supported
2021-01-26 18:51:12 <ikke> https://alpinelinux.org/releases/
2021-01-26 18:51:17 <c705> i did not know that. good to know
2021-01-26 18:51:35 <c705> thanks
2021-01-26 18:53:01 <maxice8> is adding #12294 really necessary on the 1.9.5p1->1.9.5p2 transition ?
2021-01-26 18:53:10 <ikke> I mean, secfixes
2021-01-26 18:53:23 <ikke> It's not necessary
2021-01-26 18:53:33 <ikke> but it would need to be added eventually
2021-01-26 18:53:49 <maxice8> it is already present in the secfixes of edge
2021-01-26 18:54:22 <ikke> oh, I'm blind
2021-01-26 18:56:39 <maxice8> armv7 has a chronic problem with invalid distfiles
2021-01-26 18:56:52 <ikke> maxice8: yes, it's a race condition between armv7 and armhf
2021-01-26 18:57:12 <ikke> abuild-fetch should account for that, but there seems to be a bug
2021-01-26 18:57:23 <ikke> (those 2 arches share the same distfiles mount)
2021-01-26 18:58:01 <ikke> maxice8: oh, you're already backporting it
2021-01-26 18:58:17 <maxice8> feel free to do 3.11 and 3.10 :D
2021-01-26 18:59:10 <c705> thanks folks
2021-01-26 18:59:32 <maxice8> 1.8.x is the -legacy- branch which means they don't get the secfixes
2021-01-26 19:04:20 <ikke> fun times
2021-01-26 19:05:55 <ikke> maybe it's time to demote sudo to community :-)
2021-01-26 19:06:06 <maxice8> DDEVAULT
2021-01-26 19:06:09 <maxice8> DOAS TIME TO STRIKE
2021-01-26 19:06:39 <ddevault> yes?
2021-01-26 19:06:39 <ikke> nagios-plugins in main depends on it
2021-01-26 19:06:44 <ddevault> oh, yes
2021-01-26 19:06:47 <ddevault> doas good, sudo bad
2021-01-26 19:07:03 <maxice8> 😎👍️
2021-01-26 19:07:06 <skarnet> getting rid of suid better
2021-01-26 19:07:11 <skarnet> service!
2021-01-26 19:07:57 <ikke> just run everything as root, no privilege escalation possible
2021-01-26 19:08:15 <skarnet> that's galaxy brain level right there
2021-01-26 19:09:39 <Hello71> polkit is now mandatory
2021-01-26 19:12:00 <dalias> uhg wtf
2021-01-26 19:12:10 <dalias> on alpine??
2021-01-26 19:12:17 <dalias> i went to so much trouble to purge that shit last time
2021-01-26 19:12:21 <skarnet> mandatory for what? where? how?
2021-01-26 19:13:21 <ikke> I guess that was a reaction to our sudo remarks?
2021-01-26 19:13:47 <dalias> ah maybe
2021-01-26 19:14:01 <skarnet> don't do that to our fragile hearts, please
2021-01-26 19:14:07 <ikke> :D
2021-01-26 19:14:25 <maxice8> Wait until April 1st
2021-01-26 19:14:30 <ikke> maxice8: :)
2021-01-26 19:15:01 <mps> or use 'faketime' utility
2021-01-26 19:15:02 <dalias> >_<
2021-01-26 19:15:25 <dalias> i cant believe linux added time namespaces without actually enabling them to fake the time *sigh*
2021-01-26 19:15:41 <dalias> (they can fake boot/monotonic time only, not real... *facepalm*)
2021-01-26 19:15:59 <skarnet> time namespaces... without the ability to fake time?
2021-01-26 19:16:37 <dalias> apparently they only cared about using it for checkpoint/resume where monotonic absolutely must not go backwards
2021-01-26 19:17:01 <skarnet> ohey guize I'ma host a masquerade ball, but for security reasons everyone will have to wear a badge with their ID
2021-01-26 19:17:34 <Hello71> i think the problem is trying to support changing real time from inside
2021-01-26 19:17:36 <Hello71> or somesuch
2021-01-26 19:18:07 <dalias> either it just should fail from inside, or it should adjust an offset from monotonic within its namespace
2021-01-26 19:18:15 <skarnet> ^
2021-01-26 19:21:12 <mps> ikke: so no option to increase size of build log on CI?
2021-01-26 19:21:29 <ikke> I have to adjust it on each runner
2021-01-26 19:21:37 <mps> uh
2021-01-26 19:22:09 <mps> I'll just merge and risk
2021-01-26 20:15:02 <ikke> ddevault: https://gitlab.alpinelinux.org/alpine/aports/-/issues/12357
2021-01-26 20:16:25 <ikke> Oh, tbk already pinged you in the issue
2021-01-26 21:48:56 <mps> anyone know what is with ppc64le builder? it show building bpytop for more than a day
2021-01-26 21:50:17 <ikke> hanging on a test apparently
2021-01-26 21:53:21 <mps> aha
2021-01-26 21:53:40 <ikke> hmm, uninterruptable sleep
2021-01-26 21:54:21 <ikke> strace keeps hanging as well
2021-01-26 21:55:59 <ddevault> I wrote this on the subject of doas vs sudo: https://paste.sr.ht/~sircmpwn/c6478737cfb459f84e22737f45cd0b6912e52055
2021-01-26 21:56:16 <ddevault> 
ACTION uninstalls sudo-doc again

2021-01-26 21:57:31 <ikke> heh, despair
2021-01-26 22:01:09 <ikke> mps: lxc is acting up
2021-01-26 22:01:27 <mps> kill switch :)
2021-01-26 22:03:35 <mps> just read on #asahi channel that the apple will release soon 11.2 of macos for M1, so would be nice to boot alpine on it soon, and cross-embedded needs to be finished for this
2021-01-26 22:07:35 <ikke> "Stopping LXC containers ..."
2021-01-26 22:11:06 <ikke> ok, had to force stop all containers
2021-01-26 22:11:13 <mps> hope it will stop in next morning at coffee time
2021-01-26 22:11:34 <ikke> My patience ran out
2021-01-26 22:11:42 <mps> :)
2021-01-26 22:11:43 <ikke> seems to be working again
2021-01-26 23:24:13 <Ariadne> ddevault: i think it would be good to deprecate sudo in alpine
2021-01-26 23:32:00 <maxice8> move it to community and have doas as the one used where required by AL ?
2021-01-26 23:42:08 <Ariadne> yes, i think so.  but that should be discussed on list first.
2021-01-26 23:48:53 <sam_> is there a "more official" doas port to linux?
2021-01-26 23:49:37 <ddevault> not so far as I'm aware, no
2021-01-26 23:52:05 <Hello71> does anything actually call sudo?
2021-01-26 23:52:32 <ddevault> abuild
2021-01-26 23:53:07 <ddevault> oh, not anymore
2021-01-27 00:30:59 <[[sroracle]]> only abuild-keygen -i calls sudo anymore and that is trivially replaceable
2021-01-27 06:50:26 <ikke> it already has an environment variable that you can set to switch it
2021-01-27 06:51:13 <ikke> nagios-plugins-openrc depends on sudo atm
2021-01-27 06:51:16 <ikke> in main
2021-01-27 06:52:19 <ikke> ncopa: apparently the ppc64le 3.7 builder was stuck for quite some time. Due to an lxc issue, I restarted all containers, and now it's building quite a lot
2021-01-27 07:51:56 <ncopa> whoops :)
2021-01-27 07:52:01 <ncopa> good morning
2021-01-27 07:53:50 <Cogitri> 👋
2021-01-27 07:58:40 <ikke> Morning
2021-01-27 08:08:21 <adhawkins> Just had a thought. When one of my packages receives an upstream upgrade, should I do it straight in community, or should I first create a package in testing to prove it, before then moving that to community?
2021-01-27 08:10:07 <ikke> You just update the existing package
2021-01-27 08:10:35 <ikke> In community in this case
2021-01-27 08:44:14 <adhawkins> Ok, understood. Was just worried that might potentially break it temporarily if someone updates.
2021-01-27 08:47:48 <Cogitri> Updates should be tested locally and edge is all about testing updates
2021-01-27 09:10:17 <c0dex> Hello
2021-01-27 09:25:23 <alex_y> Hello, I just spent 6 months building a desktop env on alpine, I have some APKBUILD I'd like to contribute to the community, how would one get access to the staging repo?
2021-01-27 09:26:17 <PureTryOut[m]2> What is "the staging repo"?
2021-01-27 09:26:33 <PureTryOut[m]2> Normally you just submit the APKBUILD to the testing folder in the aports repo, master branch
2021-01-27 09:26:54 <alex_y> Ahh
2021-01-27 09:27:09 <mps> alex_y: 6 months and didn't read how alpine development work?
2021-01-27 09:28:14 <maxice8> alex_y: to contribute one makes merge requests against https://gitlab.alpinelinux.org/alpine/aports/
2021-01-27 09:28:20 <alex_y> mps: sorry no, I just started today
2021-01-27 09:29:00 <mps> alex_y: ah, that is something else then
2021-01-27 09:29:58 <mps> alex_y: I would start from https://wiki.alpinelinux.org/wiki/Category_talk:Developer_Documentation
2021-01-27 09:34:04 <alex_y> mps: it's been a long deep dive into the desktop env, building and fine tuning the auto install script for ZFS root booting from a thin mbr/grubx64.efi into a luks lvmcrypt/cryptsetup, that alone took 2 months to fine tune
2021-01-27 09:35:53 <alex_y> kept waiting for true luks2 support from grub2 (current luks2 support is struct only, doesn't actually support the new encryptions), would have used something else but grub2 has the best zfs support
2021-01-27 09:36:02 <mps> alex_y: okay okay, I misunderstood you
2021-01-27 09:36:37 <alex_y> I have gone through hours and hours of pain to get a desktop installation installed and running smoothly, I'd like to save other people some time ;)
2021-01-27 09:36:44 <alex_y> mps: thank you sir
2021-01-27 09:37:03 <mps> :)
2021-01-27 09:39:00 <mps> alex_y: looks like your endeavor with settings all this will be good for any exhaustive article
2021-01-27 09:39:10 <alex_y> Some desktop apps stubbornly requires glibc and can only be launched from a docker container with another x11 wm inside, don't think those can make it into the repo anytime soon
2021-01-27 09:39:17 <mps> s/any/an/
2021-01-27 09:39:18 <alpine-meetbot> mps meant to say: alex_y: looks like your endeavor with settings all this will be good for an exhaustive article
2021-01-27 09:39:56 <alex_y> mps: hmmm.. now that you've mentioned it
2021-01-27 09:43:21 <alex_y> On https://wiki.alpinelinux.org/wiki/Development_using_git:Developer_repositories
2021-01-27 09:43:36 <alex_y> It reads " Some git repositories of Alpine developer are hosted at git.alpinelinux.org. Developers who has no push access to the offical aports repo can has a developer aports repo that can be used as a staging area. Developers with push access, integration managers, can review and pull from this or can choose to reject if the changes needs more fixing."
2021-01-27 09:44:22 <alex_y> I was wondering what it means by a "developer aports repo" as a "staging area"
2021-01-27 09:44:24 <mps> alex_y: this docs are outdated, but some basic things there are still useful
2021-01-27 09:44:42 <mps> alpine moved development to gitlab
2021-01-27 09:44:56 <mps> i.e. gitlab.alpinelinux.org
2021-01-27 09:45:03 <alex_y> I was thinking along the lines of maybe I have to register an account somewhere and push the commit somewhere
2021-01-27 09:45:06 <alex_y> ahhhh
2021-01-27 09:45:22 <alex_y> btw the ZFS installation wiki needs massive update ;)
2021-01-27 09:45:51 <mps> wiki needs to be removed, imnsho
2021-01-27 09:46:00 <alex_y> ohh
2021-01-27 09:46:33 <mps> alpine needs better official docs, starting point is docs.alpinelinux.org
2021-01-27 09:47:04 <mps> but we are too small and not have much 'man power' to work on this
2021-01-27 09:48:16 <mps> (except we have a man power for useless babbles ;) )
2021-01-27 09:48:40 <alex_y> I am interested to contribute towards the desktop area in a foreseable future, if the community accepts it :)
2021-01-27 09:48:58 <alex_y> been exciting to see a security focused linux WITHOUT systemd
2021-01-27 09:49:08 <mps> but ok, we are not commercially related to anything so we have freedom for this ;)
2021-01-27 09:49:09 <alex_y> that actually gained real traction (due to docker)
2021-01-27 09:49:54 <alex_y> ahh
2021-01-27 09:51:01 <alex_y> That 5mb alpine docker image is just beautiful ;)
2021-01-27 09:53:43 <mps> any(n)one knows why build.a.o is so heavy for browsers, my FF often segfaults when opening it
2021-01-27 09:55:07 <adhawkins> Cogitri: Absolutely, would be testing locally. Mistakes do happen though sadly.
2021-01-27 09:57:12 <PureTryOut[m]2> mps: can not reproduce, build.a.o seems quite light even
2021-01-27 10:08:05 <mps> PureTryOut[m]2: yes, interesting that this happens for me only on one machine, two other works fine
2021-01-27 10:08:24 <PureTryOut[m]2> Maybe something wrong with that machine?
2021-01-27 10:09:20 <mps> strange is it doesn't crash on heavy pages like gitlab.a.o
2021-01-27 10:41:16 <ncopa> dalias> indeed that's going to make it pull glibc binaries
2021-01-27 10:41:16 <ncopa> dalias> from pip's binary repos
2021-01-27 10:41:39 <ncopa> dalias: do you have any suggestions or ideas how we prevent our python build to pull in glibc binaries?
2021-01-27 10:42:20 <ncopa> also, do you remember if there are any issue reported somewhere, with the details or how to reproduce?
2021-01-27 10:42:51 <ricardo10> Hélio folks
2021-01-27 10:44:09 <ricardo10> My friends, I am New working Wittel Alpine and. Dockers
2021-01-27 10:44:36 <ricardo10> But I am Senior Engineer in Network
2021-01-27 10:44:54 <ricardo10> I have studied about Decker networks
2021-01-27 10:44:56 <adhawkins> What's the procedure for packaging something where the upstream seems to have disappeared? The package is available in Debian. Is it Ok to use the debian 'orig' tarball as the source?
2021-01-27 10:45:28 <mps> adhawkins: yes, I use it for weex
2021-01-27 10:45:46 <ricardo10> But I am Worth dificult in a single step
2021-01-27 10:45:58 <adhawkins> Ok, I'll do that then, thanks mps
2021-01-27 10:48:26 <ricardo10> I am creating a new network in Docker. When I create and attach a container The port exposed Not works properly. When I restart the Alpine all start works well
2021-01-27 10:49:15 <ricardo10> I believe that is Not a correct behavior
2021-01-27 10:49:46 <ricardo10> Someone could help me?
2021-01-27 10:50:49 <Thermi> Hi, I need to get a specific file from a gitlab pipeline. I can move the file to any destination I want. Is it possible to get the file then somehow? The runner fails and the log contains debug information.
2021-01-27 10:51:05 <Thermi> It's that pipeline: https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/305866
2021-01-27 10:56:46 <ikke> Thermi: in one of these paths: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/.gitlab-ci.yml#L37 (relative to the root of the repo)
2021-01-27 10:57:45 <aparcar[m]> Hi, what is the structure of apk public keys again? It's <username>-<some hash>.rsa.pub?
2021-01-27 10:57:55 <adhawkins> Is the 'build' function inside the APKBUILD file executed from within $builddir? It doesn't seem to be for me. If I do a 'pwd' inside it, I'm in src/ not the directory below where the tarball is extracted.
2021-01-27 10:58:15 <ikke> aparcar[m]: it doesn't matter that much, what matters is that the name is the same as the key you built it with
2021-01-27 10:58:23 <adhawkins> https://paste.debian.net/1182916/
2021-01-27 10:58:33 <ikke> adhawkins: it is, but only when $builddir exists
2021-01-27 10:58:34 <maxice8> prepare|build|check|package 'cd' to $builddir before running themselves
2021-01-27 10:58:56 <ikke> adhawkins: $builddir defaults to $srcdir/$pkgname-$pkgver
2021-01-27 10:59:02 <adhawkins> https://termbin.com/a63g
2021-01-27 10:59:10 <aparcar[m]> ikke: thank you
2021-01-27 10:59:27 <adhawkins> Aha. _ and not '-'.
2021-01-27 10:59:28 <adhawkins> Thanks ikke
2021-01-27 10:59:53 <ikke> adhawkins: so set builddir as a global variable to the correct name
2021-01-27 11:00:32 <ikke> builddir="$srcdir/$pkgname_$pkgver"
2021-01-27 11:00:44 <adhawkins> Yep, just done that ikke. I thought I had, but I'd used an '_' instead of a '-' (the filename contains '_', but the tarball itself contains '-')
2021-01-27 11:01:01 <ikke> oh, if it's the default, then you should leave it out even :)
2021-01-27 11:01:07 <ikke> (our linting warns about that)
2021-01-27 11:01:20 <adhawkins> Theres an 'orig' in there though too, so not quite default.
2021-01-27 11:01:28 <ikke> ah, ok
2021-01-27 11:02:17 <alex_y> Hello, I am attempting to push an APKBUILD to the testing repo, I've added my ssh key to gitlab.alpinelinux.org
2021-01-27 11:02:49 <ikke> alex_y: did you fork the aports project?
2021-01-27 11:02:52 <alex_y> I am unsure as to what to do next, I've tried ssh into git@git.alpinelinux.org, but resulted in "No more authentication methods to try" after trying the pub key
2021-01-27 11:03:07 <alex_y> ikke: no
2021-01-27 11:03:07 <mps> alex_y: you cannot push to repo, you have to create merge request in your forked repo
2021-01-27 11:03:14 <alex_y> ahhh
2021-01-27 11:03:17 <ikke> but authentication should work first
2021-01-27 11:05:22 <alex_y> let me try again
2021-01-27 11:15:09 <adhawkins> Anyone familiar with autoconf and the like help with these errors? https://termbin.com/gjna
2021-01-27 11:15:18 <adhawkins> It's a very old package so it's possible that's why it doesn't build.
2021-01-27 11:16:42 <alex_y> adhawkins: it looks like a log of a successful apk add?
2021-01-27 11:17:21 <adhawkins> Ah, I guess the control characters have truncated it somehow.
2021-01-27 11:17:30 <adhawkins> Can abuild provide 'clean' output?
2021-01-27 11:17:39 <Thermi> ikke: what variable hols the path of the repo? Or is it just ~=
2021-01-27 11:17:42 <Thermi> *?
2021-01-27 11:17:49 <adhawkins> -m by the look of it, let's try.
2021-01-27 11:18:44 <ikke> Thermi: $CI_PROJECT_DIR
2021-01-27 11:18:50 <Thermi> Ty, need to export it?
2021-01-27 11:18:58 <Thermi> ikke: ^
2021-01-27 11:19:02 <ikke> No, it's provided by gitlab
2021-01-27 11:19:58 <adhawkins> Ok, this one looks better: https://paste.debian.net/1182919/
2021-01-27 11:22:34 <mps> adhawkins: no it doesn't :)
2021-01-27 11:22:41 <mps> it is html
2021-01-27 11:22:53 <mps> adhawkins: apk add tpaste
2021-01-27 11:22:59 <adhawkins> Not here it's not mps
2021-01-27 11:23:17 <mps> and, echo 'hello' | tpaste
2021-01-27 11:23:28 <ikke> https://paste.debian.net/plain/1182919
2021-01-27 11:23:38 <mps> huh
2021-01-27 11:23:43 <adhawkins> I'm not building on an alpine box, I'm using a docker container.
2021-01-27 11:23:53 <mps> https://paste.debian.net/1182919/ is html
2021-01-27 11:23:58 <alex_y> adhawkins: I've had many battles with autoconf, one of them was solved by putting the autoconf version outside of a () :/
2021-01-27 11:24:11 <adhawkins> alex_y: I'm not sure what you mean?
2021-01-27 11:24:20 <alex_y> adhawkins: if you paste the APKBUILD I can have a go at it :)
2021-01-27 11:24:39 <adhawkins> https://paste.debian.net/1182921/
2021-01-27 11:24:46 <alex_y> ok
2021-01-27 11:26:43 <adhawkins> It's a package that hasn't been touched since 2004, be warned!
2021-01-27 11:28:00 <mps> 'cat something | curl tpaste.us -F tpaste=\<-'
2021-01-27 11:28:22 <alex_y> adhawkins: have you tried replacing:
2021-01-27 11:28:26 <alex_y> "autoreconf && ./configure --prefix=/usr && make"
2021-01-27 11:28:28 <alex_y> with:
2021-01-27 11:28:36 <alex_y> "./autogen.sh && ...." ?
2021-01-27 11:28:47 <adhawkins> Tried that, similar errors.
2021-01-27 11:29:12 <alex_y> ok digging...
2021-01-27 11:30:23 <alex_y> adhawkins: when I tried that it worked, then it stopped on:
2021-01-27 11:30:27 <alex_y> /usr/bin/abuild: cd: line 2374: can't cd to /alpine/update/repo/custom/build/test/pkg/libunac-dev: No such file or directory
2021-01-27 11:31:09 <alex_y> maybe it doesn't have .h etc?
2021-01-27 11:31:43 <ikke> yes, you can remove $pkgname-dev from subpackages in that case
2021-01-27 11:32:32 <alex_y> if i remove -dev and -doc from subpackages, then it stops at :
2021-01-27 11:32:35 <alex_y> /usr/bin/abuild: cd: line 2374: can't cd to /alpine/update/repo/custom/build/test/pkg/libunac: No such file or directory
2021-01-27 11:32:54 <ikke> that means nothing is installed at all
2021-01-27 11:33:15 <alex_y> because package() is empty
2021-01-27 11:37:26 <Thermi> ikke: Seems like copying worked, but the artifacts section is empty. Does the file need to end with .apk or something?
2021-01-27 11:37:26 <alex_y> give this one a try
2021-01-27 11:37:31 <alex_y> https://paste.debian.net/1182923/
2021-01-27 11:37:59 <ikke> Thermi: no, it should upload everything in that directory
2021-01-27 11:38:11 <Thermi> ikke: Well, it doesn't. :|
2021-01-27 11:38:23 <adhawkins> Oooh, thanks. Will have another try alex_y.
2021-01-27 11:38:31 <alex_y> no probs :)
2021-01-27 11:38:32 <adhawkins> There will be .h, need to sort that
2021-01-27 11:38:34 <Thermi> There should be the file here: https://gitlab.alpinelinux.org/Thermi/aports/-/jobs/305936
2021-01-27 11:38:48 <alex_y> adhawkins: With that it reaches >>> libunac: Signing the index...
2021-01-27 11:38:52 <Thermi> > 		cp /tmp/mdbx-test.db /tmp/mdbx-test.log.gz $CI_PROJECT_DIR/packages/
2021-01-27 11:38:53 <alex_y> adhawkins: on my end
2021-01-27 11:39:02 <adhawkins> I'm sure I tried that. Will rty again
2021-01-27 11:39:49 <alex_y> adhawkins: yeah the -doc and -dev requirement came back after the earlier issue was bypassed
2021-01-27 11:40:12 <ikke> Thermi: https://docs.gitlab.com/ee/ci/yaml/#artifactswhen
2021-01-27 11:40:27 <adhawkins> Let me try again alex_y. I'm sure I tried autogen.sh
2021-01-27 11:40:41 <aparcar[m]> is BKPepe sometimes here?
2021-01-27 11:40:43 <Thermi> ikke: Yeah well, I need it when the check fails
2021-01-27 11:40:49 <aparcar[m]> wrong channel sorry
2021-01-27 11:40:53 <Thermi> Otherwise this is an exercise in futility
2021-01-27 11:40:58 <ikke> Thermi: understood, but that's the reason it does not work now
2021-01-27 11:41:08 <Thermi> ikke: Okay, ty, can you change it?
2021-01-27 11:41:13 <alex_y> adhawkins: after that it needs "make DESTDIR="$pkgdir" PREFIX=/usr install" in the package(){}
2021-01-27 11:42:34 <ikke> Thermi: We've something planned that we could use for this
2021-01-27 11:47:07 <ikke> Thermi: If you rebase your branch on the latest master, you can put your files in a logs/ dir
2021-01-27 11:47:23 <Thermi> ikke: Relative to $CI_...?
2021-01-27 11:47:29 <ikke> yes
2021-01-27 11:47:47 <Thermi> And I then get the file when the pipeline fails?=
2021-01-27 11:47:50 <Thermi> *-=
2021-01-27 11:48:01 <ikke> https://git.alpinelinux.org/aports/commit/?id=57a7f1223f71
2021-01-27 11:48:20 <Thermi> Ah, ty, will rebase
2021-01-27 11:49:07 <adhawkins> I don't get it build with autogen.sh alex
2021-01-27 11:49:16 <adhawkins> config.status: error: Something went wrong bootstrapping makefile fragments
2021-01-27 11:49:35 <alex_y> adhawkins: what happens when you try [ https://paste.debian.net/1182923/
2021-01-27 11:49:54 <alex_y> adhawkins: it built the package on my end
2021-01-27 11:51:38 <alex_y> adhawkins: with a package containing the following: https://paste.debian.net/1182924/
2021-01-27 11:54:46 <adhawkins> alex_y: https://paste.debian.net/1182925/
2021-01-27 11:56:34 <adhawkins> Wonder if it's because I'm using dabuild?
2021-01-27 11:56:42 <adhawkins> Trying on an actual alpine box
2021-01-27 11:58:50 <adhawkins> Odd, that works. Ok, so what's going wrong with dabuild?
2021-01-27 11:59:42 <alex_y> hmm, not sure, autogen.sh looks vanilla also
2021-01-27 12:00:09 <alex_y> I've had build failed because it was in a different shell
2021-01-27 12:00:35 <alex_y> not sure if it applies here
2021-01-27 12:01:38 <alex_y> adhawkins: wonder what happens if you remove --gnu from automake inside autogen.sh
2021-01-27 12:02:14 <adhawkins> Must be a missing build dependency I'm guessing.
2021-01-27 12:03:25 <alex_y> ls
2021-01-27 12:03:39 <alex_y> adhawkins: does it do anything if you add this line:
2021-01-27 12:03:42 <alex_y> sed -i 's/--gnu / /' $builddir/autogen.sh
2021-01-27 12:03:52 <alex_y> above the ./autogen.sh && line?
2021-01-27 12:04:24 <adhawkins> Same error.
2021-01-27 12:04:33 <alex_y> damn
2021-01-27 12:04:45 <adhawkins> Let me see what packages are installed on the alpine box. Must be one of those making it work I guess.
2021-01-27 12:04:51 <adhawkins> Lunch time here.
2021-01-27 12:04:55 <adhawkins> Back later :)
2021-01-27 12:05:06 <alex_y> enjoy :)
2021-01-27 12:48:18 <adhawkins> Is there a command that will list all installed packages?
2021-01-27 12:48:44 <PureTryOut[m]2> `apk list -I`
2021-01-27 12:52:21 <adhawkins> Thanks, will give that a go.
2021-01-27 13:04:27 <adhawkins> Hmmm, nothing obvious. Any thoughts for candidates alex_y?
2021-01-27 13:05:12 <adhawkins> This is the packages in the docker container build: https://termbin.com/7q0a
2021-01-27 13:05:22 <adhawkins> And this on the 'real' machine: https://termbin.com/s0fp
2021-01-27 13:15:08 <alex_y> let's take a look
2021-01-27 13:16:51 <adhawkins> Pasing '--disable-dependency-tracking' to configure gets past this error, but now I've getting:
2021-01-27 13:16:55 <adhawkins> config.status: executing libtool commands
2021-01-27 13:16:55 <adhawkins> make: /bin/sh: Operation not permitted
2021-01-27 13:16:55 <adhawkins> make: *** [Makefile:688: config.h] Error 127
2021-01-27 13:17:33 <adhawkins> That bit of the Makefile is:
2021-01-27 13:17:34 <adhawkins> config.h: stamp-h1
2021-01-27 13:17:34 <adhawkins>         @test -f $@ || rm -f stamp-h1
2021-01-27 13:17:34 <adhawkins>         @test -f $@ || $(MAKE) $(AM_MAKEFLAGS) stamp-h1
2021-01-27 13:17:41 <adhawkins> The first 'test' command is the referenced line number.
2021-01-27 13:17:59 <adhawkins> ash / bash?
2021-01-27 13:18:07 <Hello71> upgrade libseccomp
2021-01-27 13:18:09 <Hello71> and docker
2021-01-27 13:19:04 <alex_y> adhawkins: the only interesting diff appear to be : atools-19.8.6-r0 x86_64 {atools} (MIT) [installed]
2021-01-27 13:19:55 <adhawkins> Was that for me Hello71? The box I'm running this on is a Debian box.
2021-01-27 13:20:22 <adhawkins> alex_y: That same package is installed on both I think?
2021-01-27 13:20:41 <alex_y> adhawkins: it's not on your docker list
2021-01-27 13:21:07 <adhawkins> Let me try.
2021-01-27 13:21:15 <alex_y> yup
2021-01-27 13:23:40 <adhawkins> Same error alex_y :(
2021-01-27 13:23:45 <alex_y> damn
2021-01-27 13:23:58 <alex_y> can you paste your docker file?
2021-01-27 13:24:03 <alex_y> I'll try it in docker as well
2021-01-27 13:24:09 <adhawkins> I'm using dabuild.
2021-01-27 13:24:16 <adhawkins> cd
2021-01-27 13:24:19 <adhawkins> Whoops.
2021-01-27 13:25:23 <adhawkins> alex_y: https://gitlab.alpinelinux.org/alpine/docker-abuild.git
2021-01-27 13:26:20 <alex_y> what happens if you also add this to the docker side? ->
2021-01-27 13:26:38 <alex_y> alpine-base-3.13.0-r0 x86_64 {alpine-base} (MIT) [installed]
2021-01-27 13:28:04 <adhawkins> Same error with dependencies.
2021-01-27 13:28:07 <Hello71> ncopa: why does alpine 3.8/3.9 have libseccomp 2.4.2 but alpine 3.10 has 2.4.1? https://repology.org/project/libseccomp/versions
2021-01-27 13:28:42 <adhawkins> If I add --disable-dependency-tracking to configure it gets past that but then fails at the 'executing libtool commands' phase.
2021-01-27 13:28:54 <adhawkins> Can I force the build system to use bash instead of ash?
2021-01-27 13:29:06 <adhawkins> Is that likely to be an issue?
2021-01-27 13:29:28 <alex_y> i had problem building outside ash in earlier days
2021-01-27 13:31:02 <alex_y> no longer had issues after the os was installed from scratch and doesn't have ash
2021-01-27 13:31:14 <alex_y> everything under bash
2021-01-27 13:31:29 <Hello71> adhawkins: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0#faccessat2
2021-01-27 13:31:51 <alex_y> adhawkins: I am not familiar with docker-abuild, how do I get to where you are at?
2021-01-27 13:32:09 <adhawkins> alex_y: I just cloned the repo, ran 'make' and then put dabuild in my path.
2021-01-27 13:32:19 <alex_y> ahh
2021-01-27 13:32:24 <adhawkins> Then to run it, you just run 'dabuild' instead of 'abuild' (using the same arguments)
2021-01-27 13:32:31 <alex_y> ok let me try
2021-01-27 13:33:35 <adhawkins> Hello71: Ok. Is that likely to affect this particular case do you think?
2021-01-27 13:33:42 <Hello71> sigh
2021-01-27 13:34:09 <Hello71> what part of "requires" is not clear
2021-01-27 13:34:23 <adhawkins> Ok, understood Hello71.
2021-01-27 13:35:02 <adhawkins> I'll try running docker on my alpine host.
2021-01-27 13:36:00 <Hello71> note that 3.12 doesn't work
2021-01-27 13:36:11 <Hello71> gonna open an issue to backport 2.4.4
2021-01-27 13:37:52 <Hello71> actually wait it doesn't have the needed docker either
2021-01-27 13:37:59 <adhawkins> I'm on 3.13
2021-01-27 13:38:50 <adhawkins> Ok. That builds, thanks *so* much Hello71.
2021-01-27 13:39:08 <adhawkins> Fails at the 'dev' part, but that's another issue.
2021-01-27 13:40:26 <alex_y> adhawkins: what params did you run dabuild with? -vxxxx?
2021-01-27 13:41:10 <adhawkins> -rfKm
2021-01-27 13:41:21 <adhawkins> But see above, it seems it's an issue with me using an older Docker.
2021-01-27 13:41:27 <alex_y> ahh
2021-01-27 13:41:30 <adhawkins> If I run it in docker on Alpine it builds Ok.
2021-01-27 13:44:19 <alex_y> yup it built
2021-01-27 14:03:00 <ncopa> Hello71: looks like it is due to CVE-2019-9893
2021-01-27 14:03:05 <ncopa> 9092d9ca814a141dbcee7a97070ff4bd93f78e10
2021-01-27 14:03:31 <Hello71> i realized that those old versions don't have new docker anyways
2021-01-27 14:03:57 <ncopa> upgrade from libseccomp 2.3 -> 2.4
2021-01-27 14:04:09 <ncopa> i'm not sure that was a good idea
2021-01-27 14:04:21 <ncopa> iirc it breaks ABI
2021-01-27 14:04:35 <ncopa> or introduces a performance regression
2021-01-27 14:05:29 <ncopa> the 3.10-stable probably already had libseccom 2.4 and was not upgraded
2021-01-27 14:07:07 <Hello71> meh
2021-01-27 14:14:18 <adhawkins> Hello71: Just updated my Debian to docker 20.10.2 and getting the same issue.
2021-01-27 14:16:03 <adhawkins> Looks like it doesn't have the appropriate seccomp support.
2021-01-27 14:20:46 <Thermi> Regarding the "arch" field in an APKBUILD; the wiki says that:
2021-01-27 14:20:46 <Thermi> arch
2021-01-27 14:20:46 <Thermi> Package architecture(s) to build for. Can be one of: x86, x86_64, arm7, armhf, aarch64, ppc64le, s390x, mips64, all, or noarch, where all means all architectures, and noarch means it's architecture-independent (e.g., a pure-python package).
2021-01-27 14:21:06 <Thermi> I assume it is actually wrong, it can be a combination of at least one of: [...]
2021-01-27 14:21:24 <Thermi> Question is if it's space seperated or any other character?
2021-01-27 14:21:31 <PureTryOut[m]2> Space separated
2021-01-27 14:21:32 <Hello71> isn't it an array
2021-01-27 14:21:39 <Hello71> wait
2021-01-27 14:21:46 <Hello71> too much arch :/
2021-01-27 14:22:02 <ncopa> are you talking about this libseccomp issue? https://github.com/moby/buildkit/issues/1946
2021-01-27 14:22:54 <Thermi> Okay, ty. Can I use ! for negation? E.g. arch="all !ppc64le"?
2021-01-27 14:23:00 <PureTryOut[m]2> Yup that works
2021-01-27 14:23:11 <Thermi> Ty. Who wants to fix that part of the wiki for me? :P
2021-01-27 14:23:18 <PureTryOut[m]2> "Build for all arches except ppc64le"
2021-01-27 14:23:20 <ncopa> its a wiki ;)
2021-01-27 14:23:24 <PureTryOut[m]2> You can do it yourself?
2021-01-27 14:23:40 <adhawkins> ncopa: No. I'm running dabuild on a debian host. At the 'executing libtool commands' of a configure, I get: 'make: /bin/sh: Operation not permitted make: *** [Makefile:688: config.h] Error 127'
2021-01-27 14:23:47 <adhawkins> If I do the same using dabuild under alpine, it works fine.
2021-01-27 14:24:07 <adhawkins> Hello71 says it's due to this: https://wiki.alpinelinux.org/wiki/Draft_Release_Notes_for_Alpine_3.14.0#faccessat2
2021-01-27 14:24:25 <adhawkins> Which requires either an up-to-date libseccomp2 (which Debian doesn't have) or some modifications (which I'm not sure I know how to do!)
2021-01-27 14:25:04 <Thermi> PureTryOut[m]2: Ah, I assumed it was restricted to registered accounts of developers or something
2021-01-27 14:25:24 <PureTryOut[m]2> It wouldn't really be a proper wiki if that were the case 😉
2021-01-27 14:33:07 <adhawkins> Hello71: Where do I put the 'default.json' file that I need to download? Or do I just provide a full path to it on the dockerd command line?
2021-01-27 14:33:24 <Hello71> anywhere
2021-01-27 14:35:13 <Thermi> " A brief description of the abuse rule which your action matched is: New users are not allowed to add ip addresses and phone numbers within 5 hrs of account creation"
2021-01-27 14:35:19 <Thermi> -.-
2021-01-27 14:35:39 <Thermi> The edit contains none of these
2021-01-27 14:37:45 <ikke> It does not look at the edit text
2021-01-27 14:38:54 <adhawkins> Ok, thanks Hello71. Now to work out how to do that with Debian's systemd :)
2021-01-27 14:39:37 <Thermi> ikke: Why does it then report that
2021-01-27 14:39:52 <ikke> It looks at the entire page
2021-01-27 14:40:00 <ikke> So if anything already exists, it would block it
2021-01-27 14:41:07 <ikke> Thermi: you should be able to edit it now
2021-01-27 14:41:11 <ikke> 'should'
2021-01-27 14:49:11 <adhawkins> Ok, think I've got it sorted now Hello71, thanks again for the assistance.
2021-01-27 14:51:19 <ikke> Cogitri: gnome-podcasts has test failures
2021-01-27 14:54:25 <Cogitri> Yikes, worked locally
2021-01-27 14:55:31 <Cogitri> At work right now, could you disable the tests for the time being so I can take a look at it later?
2021-01-27 15:35:57 <sam_> ddevault: what slightly depresses me is https://twitter.com/canadianbryan/status/1354256433798377475
2021-01-27 15:36:49 <ddevault> I don't use PAM, either, thank god
2021-01-27 15:37:11 <dalias> <@ncopa> dalias: do you have any suggestions or ideas how we prevent our python build to pull in glibc binaries?
2021-01-27 15:37:21 <dalias> by not calling it x86_64-linux-gnu (gnu means glibc)
2021-01-27 15:37:37 <dalias> instead call it x86_64-linux-musl
2021-01-27 16:30:35 <minimal> anyone good with POSIX shell? Trying to figure out the equivalent of this Bash logic:  if [ ! "$NFS_VERSIONS" =~ [234]+ ]; then
2021-01-27 16:30:48 <ikke> minimal: use case
2021-01-27 16:31:20 <ikke> though, not sure if you can match only numbers
2021-01-27 16:31:26 <minimal> shellcheck tells me its not valid POSIX - which is good, but its Wiki page on its error code doesn't give any pointers to a POSIX-compliant alternative
2021-01-27 16:32:00 <ikke> posix sh only has wildcard matching
2021-01-27 16:32:05 <minimal> ikke: have a variable might should contain only the numbers 2, 3, or 4, or combinations of those
2021-01-27 16:32:15 <ikke> yes, I figured
2021-01-27 16:32:40 <maxice8> use case
2021-01-27 16:33:06 <ikke> I don't think you can match on 1 ore more numbers with case
2021-01-27 16:33:17 <ikke> s/ore/or/
2021-01-27 16:33:17 <alpine-meetbot> ikke meant to say: I don't think you can match on 1 or more numbers with case
2021-01-27 16:34:04 <minimal> I'm sure I could come up with a messy way to do it, from a quick online search couldn't see any "elegant" way to do it
2021-01-27 16:34:55 <ikke> I can only think of grep -qx
2021-01-27 16:35:09 <ikke> (or sed or awk)
2021-01-27 16:37:12 <minimal> will play around with sed. Usually the shellcheck docs are good at pointing to drop-in Posix alternatives
2021-01-27 16:37:37 <ikke> the fact that non are listed is already an indication that there is not a straight-forward alternative
2021-01-27 16:38:46 <maxice8> done in case
2021-01-27 16:38:54 <minimal> ikke: that particular error code covers various Posix issues but that webpage doesn't mention the regex scenario at all, let alone give alternative
2021-01-27 16:39:14 <maxice8> http://ix.io/2Nu4
2021-01-27 16:40:16 <minimal> maxice8: thanks.
2021-01-27 16:44:14 <maxice8> welcome
2021-01-27 16:57:01 <Hello71> i don't think that's even valid bash
2021-01-27 16:57:12 <Hello71> it needs to be [[
2021-01-27 16:57:53 <ikke> indeed
2021-01-27 17:00:02 <minimal> Hello71: True, I have a bad habit of using "[" instead of "[[" for Bash (shellcheck usually keeps me right). In this case however I was writing something intended for sh/ash...
2021-01-27 17:01:36 <mps> abuild should be rewritten in perl
2021-01-27 17:02:20 <ikke> no pls :P
2021-01-27 17:02:50 <mps> miniperl actually
2021-01-27 17:53:32 <DylanVanAssche_> Who do I need to contact to get this MR going?
2021-01-27 17:53:32 <DylanVanAssche_> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/15863
2021-01-27 17:58:17 <mps> !15863
2021-01-27 17:59:28 <minimal> various people raising issues with installing on RPIs...
2021-01-27 18:03:12 <DylanVanAssche_> minimal: with libcec? The normal package doesn't work as RPis need some special API against which libcec needs to be compiled.
2021-01-27 18:03:33 <minimal> minimal: nope, just installing on RPI in general
2021-01-27 18:04:34 <DylanVanAssche_> minimal: Ah, well I use postmarketOS with Kodi on the RPi but I try to upstream my changes where possible.
2021-01-27 18:04:35 <mps> yes, people bought this bad SBCs
2021-01-27 18:05:40 <DylanVanAssche_> I got it for free back in the day without knowing how much trouble there's with it ☹️
2021-01-27 18:06:41 <minimal> its partly a Alpine wiki/documentation issue
2021-01-27 18:06:41 <mps> fix for pmOS doesn't necessary needs to be in alpine
2021-01-27 18:07:34 <DylanVanAssche_> Well, it's not a pmOS specific thing as it's for Kodi in Alpine actually.
2021-01-27 18:07:34 <DylanVanAssche_> I just use the pmOS tools to install it on the RPi
2021-01-27 18:08:05 <mps> I don't have to say anything bad for pmOS, but pmOS is not alpine and alpine is not pmOS
2021-01-27 18:09:20 <DylanVanAssche_> That's true 🙂 I can keep it on pmOS only as well if that's preferred
2021-01-27 18:10:07 <mps> and please don't use these emojis, this is IRC
2021-01-27 18:10:33 <DylanVanAssche_> mps: will keep it in mind
2021-01-27 18:10:48 <mps> DylanVanAssche_: thanks :)
2021-01-27 18:12:32 <mps> DylanVanAssche_: so, if the problem/bug related to alpine than it appreciate if you report it, and even better if you made MR (as you did)
2021-01-27 18:12:48 <mps> s/than/then/
2021-01-27 18:12:48 <alpine-meetbot> mps meant to say: DylanVanAssche_: so, if the problem/bug related to alpine then it appreciate if you report it, and even better if you made MR (as you did)
2021-01-27 18:13:45 <mps> but keep in mind that alpine devs are usually busy and can't respond quickly
2021-01-27 18:14:43 <mps> about half of listed alpine devs are actually inactive
2021-01-27 18:32:30 <DylanVanAssche_> mps: Alright. I didn't know that, I started with Alpine a couple of months ago. In general, I really like Alpine so I try to contribute where I can
2021-01-27 18:38:07 <mps> DylanVanAssche_: thanks for understanding 'state' of alpine project (huh, what a word)
2021-01-27 18:47:42 <alex_y_> Hello, I am having problem with one of the steps on: https://wiki.alpinelinux.org/wiki/Creating_patches
2021-01-27 18:48:00 <alex_y_> git clone git@gitlab.alpinelinux.org:$USER/$REPO.git results in "Permission denied"
2021-01-27 18:48:23 <maxice8> what is the full error and the invocation ?
2021-01-27 18:48:24 <alex_y_> where $USER and $REPO is my nick and "aports" on gitlab
2021-01-27 18:49:00 <alex_y_> I seem to have entered the wrong password, am I supposed to enter the same password as the one on gitlab?
2021-01-27 18:49:33 <alex_y_> maxice8: Permission denied, please try again.
2021-01-27 18:49:34 <alex_y_> git@gitlab.alpinelinux.org's password:
2021-01-27 18:50:32 <alex_y_> ssh -Tvvvv git@gitlab.alpinelinux.org also failed
2021-01-27 18:50:48 <alex_y_> I have added a SSH key
2021-01-27 18:51:02 <alex_y_> i tried both the SSH key's password and gitlab's password, still couldn't login
2021-01-27 18:59:14 <Hello71> all works fine here. probably you put wrong username or uploaded wrong key
2021-01-27 18:59:27 <Hello71> or your key is world-readable or somesuch
2021-01-27 19:00:06 <adhawkins> alex_y_If it's asking for the password for git@gitlab, sounds like it's not trying to use a key, or that key is being rejected.
2021-01-27 19:00:40 <adhawkins> Perhaps try 'ssh -v git@gitlab.alpinelinux.org' and see if that gives any more info?
2021-01-27 19:00:51 <adhawkins> I wouldn't expect you to get a shell, but it'll at least tell you if it authenticates
2021-01-27 19:02:10 <alex_y_> in ~/.ssh/config I added "Host git.alpinelinux.org\n Preferredauthentications publickey \n IdentityFile ~/.ssh/pub_key"
2021-01-27 19:02:28 <alex_y_> to force ssh to use the pub_key for all git.alpinelinux.org connections
2021-01-27 19:02:57 <adhawkins> I don't think that's how it works. The 'host' bit is an alias, then there should be a line that gives the actual host name isn't there?
2021-01-27 19:03:17 <alex_y_> Doesn't seem to be working, ssh -v shows logs like "id_rsa: No such file or directory"
2021-01-27 19:03:25 <alex_y_> it's looking for the wrong keys
2021-01-27 19:03:58 <adhawkins> See above regarding entries in config
2021-01-27 19:04:12 <alex_y_> adhawkins: thanks, I'll try
2021-01-27 19:07:50 <alex_y_> Ahh, "Host git.alpinelinux.org" should be "gitlab.alpinelinux.org"
2021-01-27 19:08:05 <alex_y_> now getting other errors, working through
2021-01-27 19:09:24 <mps> pub in pub_key?
2021-01-27 19:09:58 <mps> priv_key?
2021-01-27 19:10:38 <alex_y_> debug1: Server accepts key: /home/x/.ssh/test.pub ED25519 SHA256:QEi9S8bC+/Z5oydBgnXk53dRjIoTSB1Tpj52Y06xgu8 explicit
2021-01-27 19:10:41 <alex_y_> debug3: sign_and_send_pubkey: ED25519 SHA256:QEi9S8bC+/Z5oydBgnXk53dRjIoTSB1Tpj52Y06xgu8
2021-01-27 19:10:44 <alex_y_> debug3: sign_and_send_pubkey: signing using ssh-ed25519 SHA256:QEi9S8bC+/Z5oydBgnXk53dRjIoTSB1Tpj52Y06xgu8
2021-01-27 19:10:47 <alex_y_> Load key "/home/x/.ssh/test.pub": invalid format
2021-01-27 19:10:52 <alex_y_> mps: test.pub is the pubkey
2021-01-27 19:11:35 <mps> public key is what you put on remote, and use private key on your side to connect
2021-01-27 19:12:17 <alex_y_> doh
2021-01-27 19:12:21 <adhawkins> Ah yes. IdentityFile should point to the private key.
2021-01-27 19:12:38 <alex_y_> "Welcome to GitLab"
2021-01-27 19:12:45 <alex_y_> thank you all :)
2021-01-27 19:13:18 <alex_y_> adhawkins: how did your dabuild go?:)
2021-01-27 19:13:24 <alex_y_> mps: thank you
2021-01-27 19:13:49 <alex_y_> Hello71: thank you :)
2021-01-27 19:16:03 <mps> heh, you give me idea to reverse keys ;)
2021-01-27 19:16:11 <alex_y_> lol
2021-01-27 19:16:22 <adhawkins> alex_y: All sorted now I think. Thanks a lot for your help.
2021-01-27 19:16:23 <mps> would be funny it works
2021-01-27 19:16:33 <mps> s/it/if/
2021-01-27 19:16:34 <alpine-meetbot> mps meant to say: would be funny if works
2021-01-27 19:16:38 <alex_y_> adhawkins: nice
2021-01-27 19:16:46 <adhawkins> Reconfigured my docker as per the instructions pointed to by Hello71.
2021-01-27 19:17:21 <ncopa> dalias: looks like its not possible to set the triplet. Its detected from compiler defines https://github.com/python/cpython/blob/master/configure.ac#L714
2021-01-27 19:18:00 <ncopa> i suppose we should file a bug upstream, but I don't know the details or how to reproduce it
2021-01-27 19:21:57 <dalias> uhg wtf
2021-01-27 19:22:03 <dalias> after rebooting X doesn't support keyboard
2021-01-27 19:22:14 <ncopa> do you have udev running?
2021-01-27 19:22:15 <dalias> did anything change in this area recently?
2021-01-27 19:22:59 <ncopa> i know udev is needed for input device hotplugging in xorg
2021-01-27 19:23:48 <dalias> yes seems to be running
2021-01-27 19:24:01 <Hello71> xf86-input-keyboard was removed upstream at some point
2021-01-27 19:24:03 <dalias> mice work
2021-01-27 19:24:36 <dalias> is there a way to check which event device it is?
2021-01-27 19:24:46 <ncopa> do you have xf86-input-evdev installed?
2021-01-27 19:25:06 <dalias> yes
2021-01-27 19:25:09 <Hello71> i wonder why we still have xf86-input-keyboard. isn't it broken?
2021-01-27 19:30:22 <dalias> any other ideas to check?
2021-01-27 19:30:52 <dalias> guess i'll upgrade xorg server to latest
2021-01-27 19:32:50 <dalias> lovely now mouse doesnt work eithe
2021-01-27 19:34:57 <mps> dalias: are you in input group
2021-01-27 19:35:52 <mps> and xf86-input-libinput insted of xf86-input-evdev
2021-01-27 19:37:38 <dalias> no, input group is new, uhg
2021-01-27 19:37:53 <dalias> and no i dont have xf86-input-libinput only xf86-input-evdev
2021-01-27 19:38:12 <dalias> after adding input group, mouse works but not kb
2021-01-27 19:38:28 <MY-R> dalias: only in X?
2021-01-27 19:38:50 <dalias> right
2021-01-27 19:38:53 <dalias> on console keyboard works fine
2021-01-27 19:39:10 <dalias> but X insists on using silly /dev/input stuff rather than putting fd 0 in raw mode...
2021-01-27 19:39:43 <mps> I even don't have udev running but all works
2021-01-27 19:39:50 <dalias> will adding xf86-input-libinput maybe fix it?
2021-01-27 19:40:00 <dalias> maybe -evdev is just broken/bitrotted?
2021-01-27 19:40:13 <mps> dalias: actually
2021-01-27 19:41:08 <dalias> ?
2021-01-27 19:41:48 <mps> dalias: actually it is somewhat outdated, libinput is now official
2021-01-27 19:42:07 <mps> s/now/for some time/
2021-01-27 19:42:07 <alpine-meetbot> mps meant to say: dalias: actually it is somewhat outdated, libinput is for some time official
2021-01-27 19:44:37 <dalias> could this be something with rootless?
2021-01-27 19:44:49 <Hello71> dalias: i guess you don't use media keys, or caps lock, or prtsc, or want to differentiate alt and esc, etc
2021-01-27 19:45:05 <mps> if mouse work then I think no
2021-01-27 19:45:39 <mps> I use rootless X for long time and no problems
2021-01-27 19:46:05 <Hello71> if you have strange keyboard maybe udev rules doesn't match it? but i think that should be reasonably synchronized with libinput
2021-01-27 19:46:22 <dalias> hello71, all of that works with raw kb mode
2021-01-27 19:46:24 <dalias> it gets scan codes
2021-01-27 19:46:44 <dalias> i think udev rules are broken and don't find it
2021-01-27 19:46:54 <dalias> there are tons of nodes in /dev/input
2021-01-27 19:46:59 <dalias> but x only scans a few of them
2021-01-27 19:47:09 <dalias> so idiotic that it uses udev rather than inotify on /dev/input
2021-01-27 19:47:33 <dalias> where are the relevant udev rules?
2021-01-27 19:48:50 <MY-R> you need elogind to use rootless X
2021-01-27 19:48:51 <Hello71> ah, yes, i think that's what xf86-input-keyboard does
2021-01-27 19:49:07 <Hello71> MY-R: not if you just add user to input/video
2021-01-27 19:49:15 <mps> MY-R: no, I use it with startx
2021-01-27 19:49:39 <dalias> uhg wtf
2021-01-27 19:49:41 <Hello71> mps: startx is orthogonal to elogind
2021-01-27 19:49:50 <MY-R> so something changed probably, last time I was trying to do it in Alpine it didnt work
2021-01-27 19:49:50 <dalias> no i am not going to use elogind whatever that it
2021-01-27 19:50:03 <dalias> but anyway it's not working if i startx as root either
2021-01-27 19:51:16 <mps> I mostly use 'slim' as DM, and sometimes startx
2021-01-27 19:52:12 <mps> no e/logind, no polkit, no consolekit
2021-01-27 19:53:29 <Hello71> well consolekit is obsolete and unmaintained anyways
2021-01-27 19:53:42 <dalias> other ideas?
2021-01-27 19:53:54 <Hello71> send Xorg.0.log?
2021-01-27 19:53:57 <mps> dbus?
2021-01-27 19:54:32 <mps> though don't know why would dbus help, sorry
2021-01-27 19:56:16 <graytshirt> elogind?
2021-01-27 19:56:59 <dalias> http://ix.io/2NuW
2021-01-27 19:58:23 <graytshirt> you don't have the correct graphics modules loaded
2021-01-27 19:58:37 <graytshirt> and or firmware
2021-01-27 19:58:39 <Hello71> hm... not sure what's wrong exactly, but i guess your keyboard is not detected by udev rules
2021-01-27 19:59:05 <Hello71> graytshirt: it looks fine to me
2021-01-27 19:59:25 <Hello71> modesetting is recommended over intel, but it should still work, and i doubt it's related to keyboard issues
2021-01-27 20:00:25 <dalias> graytshirt, why?
2021-01-27 20:00:48 <dalias> that's unrelated to keyboard and it works fine. i'd rather use proper dedicated 2d accel than build 2d on top of 3d
2021-01-27 20:01:52 <mps> as Hello71 says for some unknown reason keyboard is not detected
2021-01-27 20:02:34 <dalias> yeah looks like eudev is broken...
2021-01-27 20:02:52 <Hello71> in direct response to your "where are the rules" question, seems like it should be /lib/udev/rules.d
2021-01-27 20:03:13 <Hello71> or /usr/lib/...
2021-01-27 20:03:25 <dalias> it's essentially empty except some automount rules i wrote
2021-01-27 20:03:49 <mps> I don't have e/udev (just plain mdev) but all is detected
2021-01-27 20:03:50 <Hello71> huh? eudev should have lots of stuff
2021-01-27 20:04:20 <Hello71> mps: https://www.gentoo.org/support/news-items/2020-04-03-deprecation-of-legacy-x11-input-drivers.html says need udev
2021-01-27 20:04:24 <dalias> ah they're in lib not etc
2021-01-27 20:04:27 <dalias> i was looking in etc
2021-01-27 20:04:39 <graytshirt> just looking at the fbdev and vesa errors
2021-01-27 20:04:55 <Hello71> but it doesn't specifically say mdev doesn't work
2021-01-27 20:05:15 <Hello71> graytshirt: totally unrelated. those are xorg modules, not kernel modules
2021-01-27 20:05:33 <mps> Hello71: udev is needed fot hot plug devices, but if they are plugged before boot they are detected by mdev
2021-01-27 20:06:12 <Hello71> how does it get the "event13 - BM30X mouse: is tagged by udev as: Mouse" then
2021-01-27 20:06:13 <dalias> what udev rules file covers keyboard ?
2021-01-27 20:06:23 <Hello71> dalias: no idea!
2021-01-27 20:06:24 <dalias> i have eudev and mice are fine
2021-01-27 20:06:30 <dalias> it's keyboard that doesn't appear
2021-01-27 20:06:47 <dalias> all the keyboards don't (also includes virtual ones like lid, power button, etc)
2021-01-27 20:07:02 <dalias> it's like eudev is completely hiding keyboards
2021-01-27 20:07:02 <Hello71> maybe try evtest first?
2021-01-27 20:07:57 <dalias> evtest works fine
2021-01-27 20:08:01 <MY-R> dalias: is your system fully upgraded?
2021-01-27 20:08:04 <dalias> but it's not using udev
2021-01-27 20:08:18 <dalias> my-r, not "fully" but all related packages seem to be
2021-01-27 20:08:24 <MY-R> oook
2021-01-27 20:08:25 <dalias> (udev, libinput, all xorg stuff, etc)
2021-01-27 20:08:58 <dalias> i really dont feel like upgrading GBs of random apps i haven't used in forever
2021-01-27 20:09:29 <dalias> is there a way to get a report of packages that are behind latest?
2021-01-27 20:09:40 <Hello71> apk upgrade -s
2021-01-27 20:09:41 <afontain_> upgrade -as
2021-01-27 20:09:49 <Hello71> but maybe you want apk version -somethingorother
2021-01-27 20:10:05 <MY-R> or just "apk version"
2021-01-27 20:12:11 <dalias> dont see anything relevant
2021-01-27 20:15:28 <dalias> is there a way to look at what udev sees?
2021-01-27 20:15:42 <Hello71> udevadm
2021-01-27 20:17:47 <dalias> what is usage? i'm trying to figure it out
2021-01-27 20:21:04 <dalias> hmm with udevadm info
2021-01-27 20:21:16 <dalias> mice have ID_INPUT_MOUSE=..
2021-01-27 20:21:21 <dalias> but keyboards have no ID_INPUT_*
2021-01-27 20:21:28 <dalias> so something is wrong with udev..
2021-01-27 20:23:51 <dalias> should there be a /dev/input/by-id dir?
2021-01-27 20:29:02 <mps> ls -l /dev/input/ | tpaste  => https://tpaste.us/jn8m
2021-01-27 20:29:41 <mps> that's all on my current box and everything works
2021-01-27 20:33:59 <dalias> ok
2021-01-27 20:34:17 <dalias> what does udevadm info /dev/input/event0 show ?
2021-01-27 20:34:36 <mps> dalias: you ask me?
2021-01-27 20:35:25 <dalias> yeah
2021-01-27 20:35:56 <mps> I told I don't use udev, so don't have these tools
2021-01-27 20:36:35 <dalias> ah ok
2021-01-27 20:36:49 <dalias> but then you must have xorg configured in some udev-free way .. ?
2021-01-27 20:36:59 <dalias> do you have an xorg.conf ?
2021-01-27 20:37:11 <mps> no, as it is shipped in alpine
2021-01-27 20:37:33 <caskd> Seems like https://gitlab.alpinelinux.org/alpine/aports/-/commit/25c5e4f7d069fcc1f0cc8c2f4737ef261c7d2132 introduced a bug in rspamd, investigating right now
2021-01-27 20:37:34 <mps> only added tweaks to touchpad
2021-01-27 20:39:11 <mps> dalias: no, I don't have xorg.conf but have two files in /etc/X11/xorg.conf.d/
2021-01-27 20:39:29 <mps>  20-modules.conf and  30-lib-touchpad.conf
2021-01-27 20:40:57 <dalias> i have no more 20-modules.conf
2021-01-27 20:41:00 <dalias> it was removed by upgrade
2021-01-27 20:41:38 <mps> well, that is for loading modules, not should have any relation to your problem
2021-01-27 20:42:15 <Hello71> mps: are you using evdev or libinput?
2021-01-27 20:42:50 <mps> Hello71: no, libinput
2021-01-27 20:43:10 <Hello71> uh
2021-01-27 20:43:14 <dalias> anyone with working udev setup able to show udevadm info for keyboard?
2021-01-27 20:44:25 <mps> let me look on old macbook, if it boots
2021-01-27 20:45:57 <Hello71> https://bpa.st/raw/YEREW but i am on gentoo, not alpine
2021-01-27 20:47:37 <mps> udevadm info /dev/input/event8 | tpaste => https://tpaste.us/DM9d
2021-01-27 20:49:11 <dalias> yeah it has all the ID_* stuff telling it's a keyboard
2021-01-27 20:49:13 <dalias> mine has none of that
2021-01-27 20:49:21 <dalias> and X seems to therefore ignore it
2021-01-27 20:49:31 <dalias> so something in the udev rules isn't matching
2021-01-27 20:52:22 <Hello71> dalias: those properties are set by https://github.com/gentoo/eudev/blob/master/src/udev/udev-builtin-input_id.c
2021-01-27 20:52:52 <dalias> so what could cause them to be absent .. ?!
2021-01-27 20:53:03 <Hello71> according to the man page, you can try udevadm test-builtin
2021-01-27 20:53:56 <dalias> what is the usage?
2021-01-27 20:56:45 <Hello71> dunno. maybe try udevadm test-builtin input_id /dev/input/...
2021-01-27 20:56:56 <dalias> it prepends /sys for some reason...
2021-01-27 20:57:36 <Hello71> then i guess use the corresponding sysfs node
2021-01-27 20:57:48 <Hello71> from udevadm info
2021-01-27 20:59:28 <dalias> yeah
2021-01-27 20:59:36 <dalias> ok it works wtf
2021-01-27 20:59:43 <dalias> ID_INPUT_KEYBOARD=1
2021-01-27 21:02:22 <dalias> if i try test-builtin keyboard on it tho
2021-01-27 21:02:47 <dalias> no db file to read /run/udev/data/c13:64: No such file or directory
2021-01-27 21:02:54 <dalias> that sounds like it could be source of problem
2021-01-27 21:06:40 <Hello71> dunno then
2021-01-27 21:10:52 <mps> also I have no idea what is cause, for me on different machines, some old and some new keyboard never was problem
2021-01-27 21:16:37 <caskd> nvm found the problem
2021-01-27 21:16:42 <ikke> ah
2021-01-27 21:17:00 <dalias> can i just make a static keyboard config for /dev/input/event0 somehow?
2021-01-27 21:17:07 <dalias> separate from the auto udev shit?
2021-01-27 21:17:15 <dalias> i'd actually LOVE for udev not to be able to add keyboards
2021-01-27 21:18:33 <Hello71> according to mps you can uninstall udev
2021-01-27 21:19:30 <mps> Hello71: yes, but have to install libudev-zero, some basic pkgs have deps on 'udev'
2021-01-27 21:20:13 <dalias> is udev.conf perhaps supposed to contain something?
2021-01-27 21:23:07 <mps> https://k1ss.org/wiki/dev/replacing-udev
2021-01-27 21:27:26 <mps> also for libudev-zero https://github.com/illiliti/libudev-zero/
2021-01-27 21:28:55 <mps> oh, good, just noticed that I have to upgrade it for alpine
2021-01-27 21:29:32 <dalias> what does that do?
2021-01-27 21:29:50 <ikke> a fake provider for udev
2021-01-27 21:29:54 <dalias> uhg i cant find any info on how to make a static kb device entry
2021-01-27 21:32:45 <Hello71> something like ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="03f0", ATTR{idProduct}=="2f4a", ENV{ID_INPUT}="1"
2021-01-27 21:35:17 <dalias> there is no usb here
2021-01-27 21:35:23 <dalias> it's core platform device
2021-01-27 21:35:39 <dalias> ps2 equivalent
2021-01-27 21:38:49 <dalias> is there a way to turn on udev logging of some sort?
2021-01-27 21:45:30 <dalias> does udev need some option to process stuff that was already present at boot rather than hot plugged?
2021-01-27 21:48:57 <mps> i'm not udev expert but it should settle devices detected on boot once and plugged/unplugged when they happens
2021-01-27 21:49:34 <dalias> i'm manually startign udev and dont see it doing anything with existing devices
2021-01-27 21:50:59 <mps> well, when I change some rules for udev on devices where it is still used I simply restart it
2021-01-27 21:52:10 <dalias> udevadm trigger made it all work (!!!!)
2021-01-27 21:52:21 <dalias> ffs why is that not happening automatically?
2021-01-27 21:53:30 <mps> I always expected it should but never seen it to do that
2021-01-27 21:54:11 <dalias> ok udev-trigger is not in rc-update config
2021-01-27 21:54:13 <dalias> where should it be?
2021-01-27 21:54:53 <dalias> also udev is not chgrp'ing /dev/input/* to group input so it's broken with suid...
2021-01-27 21:54:56 <dalias> erm with nosuid
2021-01-27 21:55:14 <dalias> is there a fix for that ?
2021-01-27 21:57:19 <dalias> acpid is supposed to depend on it tho..
2021-01-27 21:57:42 <dalias> uhg fuck mdev has "provide dev"
2021-01-27 21:58:31 <dalias> so is it preventing udev-trigger from getting pulled in ?
2021-01-27 22:00:33 <dalias> yes that's what happened
2021-01-27 22:00:39 <dalias> how do i prevent mdev from getting used ?
2021-01-27 22:01:55 <mps> dalias: iirc, when eudev installed it 'block' mdev from run
2021-01-27 22:02:20 <dalias> how?
2021-01-27 22:02:23 <mps> ahm
2021-01-27 22:02:25 <dalias> mdev was run here
2021-01-27 22:02:38 <dalias> it's showing in Dynamic Runlevel: needed/wanted
2021-01-27 22:02:44 <mps> looks like it need to be set in kernel command line
2021-01-27 22:03:13 <dalias> uhg lol wtf of course that's not there, why would this be oon kernel command line rather than /etc !?
2021-01-27 22:03:20 <mps> look 'etc/init.d/mdev start() function
2021-01-27 22:03:31 <dalias> yeah i see
2021-01-27 22:03:56 <mps> rc-update del mdev could be enough, but I didn't tested
2021-01-27 22:04:00 <dalias> is there any way with openrc to blacklist services?
2021-01-27 22:04:31 <dalias> it's no there; it's implicitly pulled in because it "provides dev"
2021-01-27 22:06:19 <mps> remove 'provide dev' from init script
2021-01-27 22:06:37 <mps> maybe that will work
2021-01-27 22:09:56 <dalias> i explicitly added udev-trigger in sysinit runlevel so it's already provided
2021-01-27 22:10:03 <dalias> seems to have solved it
2021-01-27 22:10:33 <mps> nice to hear
2021-01-27 22:10:59 <dalias> this might fix other random broken stuff too
2021-01-27 22:11:21 <mps> now I can ask you what to do with pkg which have on_exit function ;)
2021-01-27 22:11:45 <dalias> lol wut
2021-01-27 22:11:55 <mps> give a minute
2021-01-27 22:12:26 <dalias> is it that wacky thing that also gives the exit handlers the exit code?
2021-01-27 22:12:49 <mps> src/throttling.c:86:2: warning: implicit declaration of function 'on_exit'; did you mean '_exit'? [-Wimplicit-function-declaration]
2021-01-27 22:12:56 <mps> stalld pkg
2021-01-27 22:13:26 <dalias> i would just patch it to use atexit
2021-01-27 22:13:47 <mps> thanks
2021-01-27 22:14:19 <mps> same for /home/mps/aports/testing/stalld/src/stalld-1.5/tests/test01.c:139: undefined reference to `pthread_attr_setaffinity_np'
2021-01-27 22:15:30 <dalias> pthread_setaffinity_np
2021-01-27 22:15:42 <mps> aha
2021-01-27 22:16:12 <mps> thanks again
2021-01-27 22:25:17 <dalias> how are you supposed to do rootless X with modesetting?
2021-01-27 22:25:24 <dalias> i get a bunch of eaccess
2021-01-27 22:25:46 <dalias> [   938.715] (EE) modeset(0): drmSetMaster failed: Permission denied
2021-01-27 22:25:48 <Hello71> should be add user to video or use elogind, same as intel
2021-01-27 22:26:00 <dalias> i'm in video
2021-01-27 22:26:11 <Hello71> hm... could be you need elogind actually... gotta go now but can check later
2021-01-27 22:26:13 <dalias> it tries to open /dev/vga_arbiter too tho
2021-01-27 22:26:55 <dalias> i want to try switching because after upgrade (w/intel) firefox is freezing for 5 seconds at a time
2021-01-27 22:27:05 <dalias> and when i had this symptom before it was idiotic gpu stuff
2021-01-27 22:28:37 <dalias> there's also DRM_IOCTL_SET_MASTER failure
2021-01-27 22:30:55 <dalias> ah need to update kernel...
2021-01-27 22:32:17 <mps> dalias: by rootless X you mean without setuid?
2021-01-27 22:32:32 <dalias> yes
2021-01-27 22:32:46 <mps> aha, it works fine for me
2021-01-27 22:32:54 <mps> with modesetting, I mean
2021-01-27 22:33:48 <dalias> wow this is hideously slow
2021-01-27 22:33:56 <dalias> as modesetting
2021-01-27 22:34:37 <dalias> how can i tell if it's even using 3d accel right?
2021-01-27 22:35:09 <dalias> ah lovely firefox is fast and it's just uuterm that's slow
2021-01-27 22:35:13 <dalias> so there must be accel
2021-01-27 22:35:29 <dalias> it's just that firefox is doing gpu compositing type shit
2021-01-27 22:35:33 <dalias> which is accelerated
2021-01-27 22:35:42 <dalias> but there's no acceleration for standard 2d raster ops
2021-01-27 22:35:44 <dalias> grrr
2021-01-27 22:36:33 <mps> I play sometimes with these on arm64 but must say that it is 'black magic' for me
2021-01-27 22:37:09 <mps> if the firefox enough fast then the st term 'enough slow'
2021-01-27 22:37:32 <mps> but I don't waste much time on these things
2021-01-27 22:38:06 <mps> 2d is quite fine for me
2021-01-27 22:38:35 <dalias> right the problem is they made 2d slow and only 3d fast
2021-01-27 22:38:44 <mps> ah
2021-01-27 22:39:01 <dalias> like 50x slower type slow
2021-01-27 22:40:09 <mps> hmm, something like this I have when using panfrost gpu driver
2021-01-27 22:40:38 <mps> mpv works nice, but editing source is slow
2021-01-27 22:40:53 <dalias> "lol who would care if expansion of 1bpp data to screen is slow?"
2021-01-27 22:41:01 <dalias> "umm, that's how you draw text"
2021-01-27 22:42:01 <dalias> going to update kernel now too, see if getting drivers and kernel all latest just makes this decent again..
2021-01-27 23:00:27 <alex_y_> aports MR build log shows "ERROR: Uploading artifacts as "archive" to coordinator... too large archive", is it fixable?
2021-01-27 23:00:37 <Hello71> make it smaller
2021-01-27 23:00:46 <alex_y_> Can't
2021-01-27 23:01:00 <alex_y_> the app is large
2021-01-27 23:02:27 <Hello71> oh, pycharm... i don't think it makes sense to package that
2021-01-27 23:03:25 <Hello71> and of course you can. use system jvm for one
2021-01-27 23:08:31 <alex_y_> It's part of a complete desktop environment
2021-01-27 23:09:10 <alex_y_> if you use openjdk$ver the app nags you about it and recommend you to use the internal one.
2021-01-27 23:14:11 <mps> TBK[m]: would you backport libudev-zero to 3.13
2021-01-27 23:14:34 <mps> if not then here is one who will :)
2021-01-27 23:14:51 <TBK[m]> sure
2021-01-27 23:14:58 <mps> thanks
2021-01-27 23:18:58 <skarnet> what version of musl did alpine-3.12 use?
2021-01-27 23:19:51 <mps> skarnet: 1.1.24
2021-01-27 23:20:09 <skarnet> thanks
2021-01-27 23:20:24 <mps> with some patches
2021-01-27 23:20:52 <skarnet> dalias: what changed in time_t / timespec on armv7 (or generic 32-bit, maybe) between 1.1.24 and 1.2.2 ?
2021-01-27 23:21:03 <Hello71> it doubled in size?
2021-01-27 23:21:12 <Hello71> https://musl.libc.org/time64.html
2021-01-27 23:21:35 <Hello71> https://musl.libc.org/releases.html "This release moves all 32-bit archs to 64-bit time_t, enabling them to represent times beyond January of 2038.'
2021-01-27 23:21:57 <skarnet> yeah, but there's more to it
2021-01-27 23:22:35 <skarnet> context: I'm tracking #12346 and have the problem down to one line in skalibs
2021-01-27 23:23:18 <Hello71> did you read https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#time64_requirements
2021-01-27 23:25:00 <skarnet> I'll ask the reporter :)
2021-01-27 23:26:20 <skarnet> ... no, that's irrelevant, that's only libseccomp
2021-01-27 23:26:27 <skarnet> which is unrelated here
2021-01-27 23:50:04 <dalias> skarnet, what is the problem?
2021-01-27 23:51:26 <dalias> if the issue is under docker, i think it's broken docker seccomp
2021-01-27 23:51:37 <skarnet> no, seccomp is irrelevant here
2021-01-27 23:51:51 <skarnet> unless seccomp can corrupt timespecs :P
2021-01-27 23:52:53 <skarnet> the problem is that on armv7 and only with musl-1.2.2, I have a cast from uint64_t to time_t that seems to produce garbage
2021-01-27 23:53:09 <skarnet> not 100% yet, currently investigating
2021-01-27 23:54:02 <Hello71> well if you don't check the result of clock_gettime it'll give you garbage memory
2021-01-27 23:54:32 <Hello71> which is what happened to busybox date
2021-01-27 23:54:37 <skarnet> wait what?
2021-01-27 23:56:02 <skarnet> Hello71: can I have a link to the problem? and what am I supposed to be doing?
2021-01-27 23:57:14 <Hello71> clock_gettime sets errno = EPERM and does not initialize the output buffer when running in a 32-bit docker container if docker version is before 19.10.somesuch or if libseccomp version is before 2.4.someother
2021-01-27 23:57:33 <Hello71> case 1 doesn't usually apply but case 2 is disappointingly common across distros
2021-01-27 23:58:12 <skarnet> ah, so it can still be a seccomp problem even if don't use seccomp at all? because clock_gettime() gets blocked?
2021-01-28 00:12:01 <Hello71> docker uses seccomp.
2021-01-28 00:12:22 <Hello71> which I think I was sufficiently clear about in the release notes
2021-01-28 00:12:23 <opal> im not using docker
2021-01-28 00:12:42 <opal> Hello71 im running alpine armhf on a pi
2021-01-28 00:13:01 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12346 says docker several times
2021-01-28 00:13:09 <Hello71> am i missing something here
2021-01-28 00:13:13 <opal> the issue was related but not the same
2021-01-28 00:13:16 <opal> i didnt report that issue
2021-01-28 00:13:23 <Hello71> what issue are you talking about then
2021-01-28 00:13:27 <opal> i didnt file
2021-01-28 00:13:32 <opal> we've just been talking on irc so far
2021-01-28 00:14:22 <opal> issue is: s6 seems to be barfing on 32-bit because of musl's 64-bit time
2021-01-28 00:16:47 <skarnet> opal: don't mix issues please
2021-01-28 00:17:06 <skarnet> the issue I'm talking about here is the one that has been reported by mbentley, and it *may* be due to the seccomp thing
2021-01-28 00:17:11 <opal> ah ok
2021-01-28 00:17:15 <skarnet> I want to clear that up first
2021-01-28 00:17:20 <opal> my bad then
2021-01-28 00:17:58 <opal> im trying to make everything about me :p
2021-01-28 00:18:22 <skarnet> tbh I want both problems to be the same, it would be easier :P
2021-01-28 00:18:35 <skarnet> but it's not certain they are
2021-01-28 00:19:04 <opal> well i'll wait on that then before trying anything else on my end, i should probably be breaking other things tonight anyway
2021-01-28 00:19:24 <opal> i'll be around tomorrow to see what's up
2021-01-28 00:26:25 <skarnet> your clock_gettime() returns 0 so there's definitely something on rpi
2021-01-28 00:26:31 <skarnet> it's not docker-related
2021-01-28 00:26:35 <skarnet> but it's different
2021-01-28 00:27:00 <opal> joys of using old hardware
2021-01-28 00:27:09 <opal> friend gave me this thing since he wasnt using it lmao
2021-01-28 01:57:58 <dalias> there was rpi kernel with broken vdso but we disabled vdso until that can be safely avoided
2021-01-28 01:58:59 <dalias> opal, can you strace the failure?
2021-01-28 02:02:02 <opal> already have one handy, https://wowana.me/paste/fS6uSR.txt
2021-01-28 02:05:25 <dalias> ok no sign of anything wrong there
2021-01-28 02:05:46 <opal> wdym, ppoll() returns einval
2021-01-28 02:06:13 <dalias> oh ok looking
2021-01-28 02:06:32 <dalias> ah because tv_sec = -1
2021-01-28 02:06:35 <opal> yeah
2021-01-28 02:08:09 <dalias> where is that called from?
2021-01-28 02:08:39 <opal> skalibs somewhere
2021-01-28 02:08:43 <opal> dont have the code up right now
2021-01-28 02:11:05 <dalias> here maybe? (sorry github link because it's easier to search)
2021-01-28 02:11:07 <dalias> https://github.com/skarnet/skalibs/blob/f3d5157564992f1ef9f390b3ce0c7d3706ba0f19/src/libstddjb/iopause_ppoll.c
2021-01-28 02:11:19 <opal> uh yeah that'd be the file
2021-01-28 02:12:14 <dalias> it looks like it can produce a negative timeout
2021-01-28 02:12:22 <dalias> which is erroneous to pass to ppoll
2021-01-28 02:12:38 <opal> (sorry im focused on other broken crap rn so i cant be of much help)
2021-01-28 02:12:53 <dalias> hmm no maybe the tain_less predicate avoids that
2021-01-28 02:12:53 <opal> gotta refactor someone else's code because their fucking docs dont line up with reality at all
2021-01-28 02:13:36 <opal> actually pissed at how bad this code is, so im gonna go ahead and take my anger out on it
2021-01-28 02:17:40 <dalias> :/
2021-01-28 02:18:12 <opal> "this code" definitely not meaning s6/skalibs
2021-01-28 02:18:18 <opal> just some other trash ive been trying to get running
2021-01-28 02:18:39 <opal> not pointing fingers but it's a popular piece of software, i'll leave it at that
2021-01-28 02:19:01 <dalias> i know
2021-01-28 08:13:17 <skarnet> dalias: yeah tv_sec=-1 and the problem happens earlier, the previous ppoll() has tv_sec=0 and tv_nsec=something when it should have a very large tv_sec
2021-01-28 08:14:12 <skarnet> it works on 64-bit archs, it works on musl-1.1.24, so there's something with the time64 change that broke
2021-01-28 09:07:26 <HRio> ikke: https://pkgs.alpinelinux.org/contents?file=&path=%2Fetc%2Fsudoers.d&name=&branch=edge&arch=x86_64
2021-01-28 09:08:08 <ikke> Ah, indirect dependencies
2021-01-28 09:09:44 <HRio> does doas handle includes?
2021-01-28 09:55:34 <ikke> No mention of it, so I assume it does not
2021-01-28 11:28:56 <adhawkins> Got a bit of an issue with a new version of one of my packages. For the tests to run, it needs a new package. However, this new package should go in 'testing' first. That'll mean the CI won't find this new package when it tries to build the update to the existing package. Any suggestions how to get around this? I guess I could initially upload the
2021-01-28 11:28:56 <adhawkins> new package in testing, wait for it to be merged, then move to community and wait for that to be merged?
2021-01-28 11:42:25 <Cogitri> That'd work, yes
2021-01-28 11:42:48 <Cogitri> We usually allow introducing packages directly into community if they're a dependency of an existing package though
2021-01-28 11:44:04 <adhawkins> Oh ok. That'd help.
2021-01-28 11:44:15 <adhawkins> Now got to work out why it won't build in docker or CI, but does in alpine iwth abuild!
2021-01-28 11:51:05 <HRio> ikke: guess we need something like "include" to replace the current use-cases of sudo
2021-01-28 11:51:50 <ikke> just drop-in files are soft dependencies though
2021-01-28 11:52:02 <ikke> so if people want to use it, they could install sudo from community
2021-01-28 11:52:55 <ikke> x2goserver does not depend on sudo for example
2021-01-28 12:15:53 <Newbyte> What's the versioning convention for git packages?
2021-01-28 12:16:37 <Cogitri> 0_git$dateOfCommit
2021-01-28 12:16:45 <Cogitri> so e.g. 0_git20210128
2021-01-28 12:17:25 <Newbyte> Thanks!
2021-01-28 12:18:36 <Newbyte> https://github.com/tangwz/jsonlint/blob/master/LICENSE.txt
2021-01-28 12:18:45 <Newbyte> this looks like 3-clause BSD, right?
2021-01-28 12:19:38 <Cogitri> Yup
2021-01-28 12:27:32 <mps> timlegge: does perl-crypt-openssl-x509 depends on openssl-dev for some reason, or just overlooked
2021-01-28 12:30:01 <HRio> ikke: sure but using /etc/sudoers.d is a common use case also in server management e.g. with ansible
2021-01-28 13:01:49 <minimal> HRio: yupe, cloud-init creates files in /etc/sudoers.d/
2021-01-28 13:07:50 <timlegge> let me look - I would guess that it should
2021-01-28 13:10:05 <alex_y_> Anyone know why dabuild -vr resulted in "mkdir: can't create directory '/home/builder/aports/testing/xxxxxx/src': Permission denied"?
2021-01-28 13:11:04 <adhawkins> Anyone able to checkout MR !17567 for me?
2021-01-28 13:11:40 <adhawkins> It builds fine on an alpine box with abuild, but fails under dabuild and the CI container.
2021-01-28 13:11:41 <alex_y_> sup adhawkins
2021-01-28 13:11:52 <alex_y_> lets take a look
2021-01-28 13:11:57 <adhawkins> https://gitlab.alpinelinux.org/adhawkins/aports/-/jobs/306913
2021-01-28 13:12:14 <adhawkins> Thanks alex_y_.
2021-01-28 13:12:43 <adhawkins> By the way, I'll fix up the commits before removing the WIP tag, just wanted to get it running on 'real' CI to double check the results were the same as I'm seeing locally.
2021-01-28 13:14:46 <alex_y_> wow never seen that one before
2021-01-28 13:14:59 <adhawkins> Are you seeing the same thing? You can build it locally?
2021-01-28 13:15:08 <timlegge> mps: yes perl-crypt-openssl-x509 is a XS based module whick links to the openssl libraries.  However that should be a makedepends - I can sort it later today and test to ensure it is not needed for using the module
2021-01-28 13:15:14 <alex_y_> I saw the MR build job log
2021-01-28 13:15:27 <adhawkins> Ok. Any chance you could check out the branch and try to build it locally?
2021-01-28 13:15:31 <alex_y_> yup
2021-01-28 13:15:46 <adhawkins> py3-sly is a new package, and py3-quantiphy-eval is upgrading to v0.4 (sly is a new dependency)
2021-01-28 13:36:02 <mps> timlegge: thanks, I was not sure if you have some reasons for current deps
2021-01-28 13:37:35 <alex_y_> adhawkins: it built fine on my end, all of it
2021-01-28 13:39:15 <adhawkins> Yep, same behaviour as me then. I can build it natively, but if I build with dabuild or the CI docker container it fails (in the same way as the MR).
2021-01-28 13:39:19 <adhawkins> Anyone got any ideas?
2021-01-28 13:43:15 <adhawkins> As an aside, I've fixed up the commits now.
2021-01-28 13:43:25 <adhawkins> Once it builds on CI I'll do some proper testing! :)
2021-01-28 13:44:05 <alex_y_> Looks like sly is not passing NAME in lexer when it is imported
2021-01-28 13:45:15 <adhawkins> But only when it's being done under Docker...
2021-01-28 13:45:32 <adhawkins> Are you able to run dabuild locally alex_y_? Double check you see the same there?
2021-01-28 13:45:38 <alex_y_> let's see
2021-01-28 13:47:57 <alex_y_> ERROR: unable to select packages: py3-sly (no such package):
2021-01-28 13:48:06 <alex_y_> adding it to depends
2021-01-28 13:48:33 <alex_y_> hmm still wont find it
2021-01-28 13:48:35 <alex_y_> wtf
2021-01-28 13:48:58 <adhawkins> It should be in depends.
2021-01-28 13:49:14 <adhawkins> Have you used dabuild to build it first?
2021-01-28 13:49:19 <adhawkins> (py3-sly that is)
2021-01-28 13:49:55 <alex_y_> how do you keep packages between dabuild runs?
2021-01-28 13:50:11 <adhawkins> The container should handle that for you, it maps a local 'packages' directory into the container.
2021-01-28 13:50:48 <adhawkins> docker run --tty --interactive -v /home/andy/alpine-packaging/aports:/home/builder/aports -v /home/andy/alpine-packaging/packages/edge:/home/builder/packages -v /home/andy/.gitconfig:/home/builder/.gitconfig -v dabuild-apkcache-edge-x86_64:/etc/apk/cache -v dabuild-config:/home/builder/.abuild --rm --workdir /home/builder/aports/community/py3-sly
2021-01-28 13:50:48 <adhawkins> alpinelinux/docker-abuild:edge-x86_64 -rfK
2021-01-28 13:50:55 <alex_y_> /home/builder?
2021-01-28 13:51:03 <adhawkins> That's the docker command mine runs when I run dabuild
2021-01-28 13:51:04 <alex_y_> ahhh
2021-01-28 13:51:12 <adhawkins> try: 'bash -x dabuild -rfK' and see what you see.
2021-01-28 13:51:21 <alex_y_> yeah it kept referring to /home/builder and I didn't provide a bind
2021-01-28 13:51:37 <adhawkins> You shouldn't need to. dabuild should do all that or you.
2021-01-28 13:51:51 <adhawkins> It creates a docker volume called (I think) dabuild-apkcache-edge-x86_64
2021-01-28 13:53:07 <alex_y_> bash -x resulted in '  py3-sly (no such package):
2021-01-28 13:53:17 <adhawkins> But what docker command did it run?
2021-01-28 13:53:32 <alex_y_> i'll try find that -tty line
2021-01-28 13:53:37 <alex_y_> bash -x dabuild -rfK
2021-01-28 13:53:48 <alex_y_> oh u mean from the log
2021-01-28 13:53:49 <adhawkins> You might need to quote the 'dabuild -rfK' bit.
2021-01-28 13:54:06 <adhawkins> Actually, try
2021-01-28 13:54:11 <adhawkins> bash -x 'dabuild checksum'
2021-01-28 13:54:19 <adhawkins> That should produce less output so you can find it easier.
2021-01-28 13:55:59 <alex_y_> ok
2021-01-28 13:56:49 <alex_y_> sed: can't create temp file 'APKBUILDXXXXXX': Permission denied
2021-01-28 13:57:03 <alex_y_> lol this is adding to the problem, i'll sort this out first
2021-01-28 14:01:03 <adhawkins> Yeah, I thought it sorted all of this for me the first time I ran dabuild. It just creates a couple of docker volumes and uses them.
2021-01-28 14:02:06 <alex_y_> i'll git clone a fresh path and try dabuild py3-sly etc
2021-01-28 14:10:48 <alex_y_> E   NameError: name 'NAME' is not defined
2021-01-28 14:10:59 <dalias> skarnet, any idea where i should look?
2021-01-28 14:11:08 <dalias> i dont see any obviously wrong code
2021-01-28 14:11:08 <alex_y_> dabuild works now, got the exact same error for your mR
2021-01-28 14:11:49 <skarnet> dalias: I can't tell you yet, sorry, I'm shaving a medium size yak in order to be able to perform tests on an armv7 qemu
2021-01-28 14:11:59 <dalias> skarnet, conversions from tai[n]_t to time[_t,spec] are just at the last moment right?
2021-01-28 14:12:04 <skarnet> yes
2021-01-28 14:12:15 <dalias> so there's not much surface for a bug and i dont see one there
2021-01-28 14:12:19 <skarnet> I suspect it's more at the clock_gettime() level that something happens
2021-01-28 14:12:29 <skarnet> but I'm not sure yet, I have more work to do on my end
2021-01-28 14:12:45 <skarnet> I'll get back to you when I have more precise suspicions
2021-01-28 14:12:50 <dalias> clock_gettime is returning the right thing, at least the syscall
2021-01-28 14:13:50 <skarnet> the tv_sec=-1 you saw in the failing ppoll() is not even the first problem
2021-01-28 14:14:09 <skarnet> the problem happens before the previous ppoll() where tv_sec=0
2021-01-28 14:14:13 <skarnet> it succeeds by accident
2021-01-28 14:14:28 <skarnet> tv_sec should not be 0 here, it should be 2^60 or something
2021-01-28 14:14:43 <dalias> wtf
2021-01-28 14:14:46 <dalias> why so huge?
2021-01-28 14:15:16 <skarnet> my model for infinity. (I also use NULL sometimes, but not when I have to do time arithmetic like looping on deadlines)
2021-01-28 14:16:04 <adhawkins> That's something alex_y_. Now to work out why it's different under docker?
2021-01-28 14:16:15 <skarnet> having a huge value for infinity simplifies code because you don't have to specialcase your time arithmetic every time you may not have specified a timeout
2021-01-28 14:16:24 <dalias> ok
2021-01-28 14:16:52 <dalias> and ppoll is definitely called via iopause_ppoll right?
2021-01-28 14:16:56 <skarnet> yes
2021-01-28 14:17:07 <skarnet> again, I can't tell you where something goes wrong yet
2021-01-28 14:17:15 <dalias> stamp is current time?
2021-01-28 14:17:18 <skarnet> yes
2021-01-28 14:17:29 <dalias> ok. maybe something is wrong computing it from timespec. i'll loook
2021-01-28 14:18:54 <skarnet> again, it's not urgent, and I'll be able to get back to you in a day or two when I have pinpointed something
2021-01-28 14:19:22 <dalias> ok
2021-01-28 14:19:32 <skarnet> the problem may still be in my code, it's just that it would be weird that everything worked with previous musl
2021-01-28 14:19:34 <alex_y_> adhawkins: try this, on quantiphy_eval.py, line 44-53, what happens if you move that tokens = () to line 86, after NAME is defined at line 84?
2021-01-28 14:25:28 <adhawkins> I did consider that alex_y_, but abuild will decompress the tarball each time.
2021-01-28 14:25:32 <adhawkins> Let's see if there's a way to prevent that.
2021-01-28 14:27:18 <adhawkins> 'dabuild -f build' only runs the 'build' step, but that doesn't install all the dependencies.
2021-01-28 14:29:10 <adhawkins> Huh...
2021-01-28 14:29:13 <adhawkins> It's now working.
2021-01-28 14:29:51 <alex_y_> patched and moved 44-53 to line 86, still NAME not defined
2021-01-28 14:30:00 <adhawkins> Its's now working here...
2021-01-28 14:30:08 <alex_y_> lol
2021-01-28 14:30:11 <alex_y_> what did you do
2021-01-28 14:30:20 <adhawkins> I even did 'rm -rf src' to force it to get the tarballs again!
2021-01-28 14:30:52 <adhawkins> Trying to run again via the MR
2021-01-28 14:31:56 <alex_y_> wonder if all the UTF-8 chars in quantiphy_eval.py caused a bug some where
2021-01-28 14:32:03 <alex_y_> locale and all
2021-01-28 14:34:48 <adhawkins> Hold on. I was building py3-sly :(
2021-01-28 14:35:30 <dalias> skarnet, do you know the particular large value you'd be passing for "infinite" ?
2021-01-28 14:35:31 <adhawkins> Yes. getting different errors now.
2021-01-28 14:35:44 <adhawkins> Move those lines and run 'dabuild deps build check'
2021-01-28 14:35:46 <skarnet> yes, hold on
2021-01-28 14:36:21 <adhawkins> It's now saying "Symbol 'NAME' used, but not defined as a token or a rule"
2021-01-28 14:37:14 <alex_y_> hmm
2021-01-28 14:37:31 <dalias> skarnet, ok. looking to see if it's potentially a bug in musl
2021-01-28 14:37:55 <adhawkins> I think we might need someone who knows a bit more about how the CI / docker stuff is set up to comment.
2021-01-28 14:40:19 <skarnet> dalias: it's either 2^61, or 2^60 + the current time relative to epoch, depending if the infinity is absolute or relative (don't ask)
2021-01-28 14:40:43 <skarnet> I have a patch to make the relative offset also 2^61 because there's no reason for it to be different, but it's not integrated yet
2021-01-28 14:41:06 <skarnet> but if you see "something greater than 2^60" then that's it
2021-01-28 14:42:01 <skarnet> and if you see something greater than 2^62 then that's a bug I have (those are absolute times and should not be used in timespec_from_tain_relative)
2021-01-28 14:42:14 <adhawkins> I think you're right alex_y_, it might be some sort of codepage issue with all those Unicode characters perhaps?
2021-01-28 14:42:41 <bratkartoffel> openjdk
2021-01-28 14:42:51 <bratkartoffel> wrong window, sorry ;)
2021-01-28 14:42:56 <skarnet> I'ma be afk for a couple hours though
2021-01-28 14:45:14 <dalias> skarnet, ok it seems to give right results.
2021-01-28 14:45:39 <skarnet> what does?
2021-01-28 14:45:55 <dalias> CLAMP() and IS32BIT() macros :)
2021-01-28 14:46:10 <skarnet> gesundheit
2021-01-28 14:46:22 <dalias> that deal with a huge input and deciding which syscall to use, and how to adjust the value for fallback to old syscall
2021-01-28 14:49:18 <adhawkins> ikke seems to be the CI / docker guru, wonder if they can help?
2021-01-28 14:49:37 <ikke> In an hour
2021-01-28 14:49:55 <alex_y_> adhawkins: back, was fixing my MR after Leo commented on it
2021-01-28 14:50:54 <alex_y_> adhawkins: maybe the build evn isn't in UTF-8?
2021-01-28 14:51:17 <alex_y_> atleast the test env
2021-01-28 14:52:41 <ikke> I don't think we explicitly set that
2021-01-28 14:53:09 <Hello71> codepage is dos garbage carried over to windows garbage
2021-01-28 14:53:48 <Hello71> it's barely relevant on windows anymore since utf8 is now supported (ish...)
2021-01-28 14:55:25 <Hello71> adhawkins: probably you are using different package versions on host
2021-01-28 14:55:48 <Hello71> or you changed py3-sly locally and didn't reinstall
2021-01-28 15:24:43 <alex_y_> adhawkins: this might be related, pytest unicode issue https://stackoverflow.com/questions/44903389/does-pytest-support-unicode-in-test-name
2021-01-28 15:28:09 <adhawkins> Hello71: py3-sly is a new packaged added my this MR.
2021-01-28 15:28:14 <Hello71> yes.
2021-01-28 15:28:21 <Hello71> you say it works outside docker
2021-01-28 15:28:35 <adhawkins> Correct.
2021-01-28 15:28:56 <adhawkins> I'm pretty sure I was doing this on a clean VM. Let me revert and double checkl.
2021-01-28 15:34:41 <adhawkins> Ok, so now local build is failing in the same way. I'm confused.
2021-01-28 15:36:43 <adhawkins> This is the steps I carried out on a clean VM: https://paste.debian.net/1183103/
2021-01-28 15:37:27 <adhawkins> At least I'm getting consistent results now. Question is, why is it failing, and why did it work for both me and alex_y_?
2021-01-28 15:43:49 <alex_y_> adhawkins: What happens if you modify /usr/bin/dabuild line 26 to [DABUILD_ENV=" -e LC_ALL=en_US.UTF-8 -e LANG=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 "]?
2021-01-28 15:44:10 <alex_y_> adhawkins: I tried to test it but docker won't even run at this point, permission denied :/
2021-01-28 15:53:35 <adhawkins> I'm not sure it's a docker issue any more alex_y_. Had issues building it locally above.
2021-01-28 16:22:43 <adhawkins> I just don't understand how we both got it to build locally alex_y_.
2021-01-28 16:25:43 <timlegge> mps:  perl-crypt-openssl-x509 depends on libcrypto1.1 but that is not in the APKBUILD should it be?  It seems to figure it out somehow on https://pkgs.alpinelinux.org/package/edge/community/x86_64/perl-crypt-openssl-x509
2021-01-28 16:27:31 <mps> timlegge: will look, but I think because use of openssl-dev in makedepends abuild will find that it needs libcrypto1 automatically
2021-01-28 16:27:55 <mps> I'm outside home right now
2021-01-28 16:28:17 <mps> or right term is 'out of home'
2021-01-28 16:32:37 <opal> homen't
2021-01-28 16:33:26 <mps> opal: :)
2021-01-28 16:42:13 <timlegge> outside, must be nice.  Feels like I have not been out in weeks
2021-01-28 16:44:13 <opal> snowed here
2021-01-28 16:48:19 <mps> timlegge: I'm working on backport of perl-crypt-openssl-x509 to 3.12-stable, I need it there
2021-01-28 16:49:00 <timlegge> opal: snow here too -2C
2021-01-28 16:50:32 <mps> lucky you, I would like at least 50 cm of snow here
2021-01-28 16:51:04 <timlegge> mps: there is an outdated version there not a lot of changes
2021-01-28 16:51:59 <timlegge> we have 10-20 cm on the ground but its been that way for a few weeks.
2021-01-28 16:52:36 <mps> enough to make snowman
2021-01-28 16:55:29 <ikke> We had a tiny bit of snow, but it was gone within a day
2021-01-28 16:55:55 <maxice8> nice temperature
2021-01-28 16:56:05 <maxice8> :D currently 29C here
2021-01-28 16:57:43 <ikke> well, for you it's summer, right?
2021-01-28 17:07:18 <mps> timlegge: tested it, 'depends' is not needed at all
2021-01-28 17:07:41 <mps> only move openssl-dev to makedepends
2021-01-28 17:08:39 <mps> 'apk info -R perl-crypt-openssl-x509' => so:libcrypto.so.1.1
2021-01-28 17:09:00 <mps> and musl, ofc
2021-01-28 17:09:47 <mps> but strange it didn't perl automatically
2021-01-28 17:10:11 <mps> huh
2021-01-28 17:12:04 <mps> hmhm
2021-01-28 17:17:35 <mps> huh, I used wrong lxc to build it :)
2021-01-28 17:18:58 <ddevault> what's the venue for discussing security fixes for packages in main?
2021-01-28 17:19:50 <Hello71> generally file an issue at aports. i don't think there's a place on irc
2021-01-28 17:20:06 <ikke> THere is #alpine-security, but it's not really used atm
2021-01-28 17:21:05 <ikke> You can create confidential issues on gitlab i
2021-01-28 17:27:23 <alex_y__> adhawkins: it stops building local for me as well, maybe we both built py3-quantiphy instead of py3-quantiphy-eval?
2021-01-28 17:27:47 <adhawkins> Anything's possible. I'm thoroughly confused now!
2021-01-28 17:30:29 <alex_y__> adhawkins: heh when the test is coded worse than the code being tested, it's spaghetii
2021-01-28 17:30:44 <ikke> heh
2021-01-28 17:31:08 <adhawkins> Thing is, I think the code that's failing isn't the test code, it's the module itself.
2021-01-28 17:31:26 <alex_y__> adhawkins: the codes are jumping all over the place, what the hell are {{1 {{2 in the comments?
2021-01-28 17:31:41 <adhawkins> Sadly, I have no idea.
2021-01-28 17:37:39 <alex_y__> # Remove commas {{{2
2021-01-28 17:37:45 <alex_y__> # Main {{{1
2021-01-28 17:37:46 <alex_y__> lol
2021-01-28 17:45:03 <afontain_> there are folding markers
2021-01-28 17:47:13 <afontain_> `zc` (close) to fold, `zo` (open) to unfold
2021-01-28 17:47:16 <afontain_> (that's assuming foldmethod=marker)
2021-01-28 17:47:26 <afontain_> also, vim
2021-01-28 17:49:04 <alex_y__> ahh
2021-01-28 18:01:41 <ikke> ddevault: typical :)
2021-01-28 18:02:55 <ddevault> hm?
2021-01-28 18:03:16 <ikke> that issue you created
2021-01-28 18:03:19 <ddevault> ah
2021-01-28 18:03:20 <ikke> and its timing
2021-01-28 18:03:22 <ddevault> aye
2021-01-28 18:03:40 <ddevault> and yet another matter that Rust would have done nothing to prevent
2021-01-28 18:03:47 <ikke> heh
2021-01-28 18:04:37 <ddevault> and tbh this is encouraging
2021-01-28 18:04:53 <ddevault> <simple software which shall not be named> is much more easily audited than <complex software which shall not be named>
2021-01-28 18:05:14 <dalias> which one?
2021-01-28 18:05:30 <ddevault> I decline to name it on the basis that the patch addressing the vulnerability has not shipped
2021-01-28 18:09:39 <sam_> bleh
2021-01-28 18:09:42 <dalias> oh ok
2021-01-28 18:09:48 <sam_> ddevault: now email linux-distros :p
2021-01-28 18:10:07 <ddevault> I'm not responsible for the disclosure, I was disclosed to because it affects one of my packages
2021-01-28 18:10:10 <ddevault> my responsibility ends here
2021-01-28 18:10:11 <sam_> ahh, okay
2021-01-28 19:08:53 <ikke> HRio: I understand it's usefull to have a drop-in directory for config, but it's something upstream (or even upstream of upstream) would need to support
2021-01-28 19:11:06 <Hello71> i'm going through aports bugs, and it seems like we have several duplicates of "rpi does not boot, cannot find kernel.img, moving files out of boot fixes the issue". one user reports that reformatting the card fixed the issue for them
2021-01-28 19:11:34 <Hello71> my guess is that "raspberry pi imager" creates mbr or vfat with some issues?
2021-01-28 19:25:38 <Hello71> weren't we supposed to rebuild all packages for time64? how come time got skipped? https://pkgs.alpinelinux.org/packages?name=time&branch=edge https://gitlab.alpinelinux.org/alpine/aports/-/issues/11878
2021-01-28 19:27:10 <ikke> only on 32-bits at least
2021-01-28 19:27:36 <dalias> i dunno why but it shouldnt matter
2021-01-28 19:27:51 <Hello71> yeah but at least according to p.a.o it wasn't
2021-01-28 19:28:49 <c705> can we bump to 5.10.11 on linux-lts? thanks
2021-01-28 19:29:02 <ikke> Hello71: on the x86 builder:
2021-01-28 19:29:10 <ikke> -rw-r--r--    1 buildoze buildoze     12629 Jul 16  2020 time-1.9-r0.apk
2021-01-28 19:30:40 <ikke> But if I look in the package it says 2018
2021-01-28 19:31:02 <mps> c705: isn't it already
2021-01-28 19:31:19 <ikke> yes
2021-01-28 19:31:20 <MY-R> is since day
2021-01-28 19:31:25 <Hello71> seems still building
2021-01-28 19:31:38 <ikke> https://pkgs.alpinelinux.org/packages?name=linux-lts&branch=edge
2021-01-28 19:31:57 <mps> heh, there is linux-edge-5.10.11
2021-01-28 19:32:27 <c705> mps: np
2021-01-28 19:32:27 <c705> linux-lts-5.10.10-r0
2021-01-28 19:32:29 <c705> 3.13
2021-01-28 19:32:33 <c705> no
2021-01-28 19:32:35 <ikke> ah, that's different
2021-01-28 19:32:41 <ikke> it's upgraded on edge
2021-01-28 19:32:43 <MY-R> no on 3.13 is too
2021-01-28 19:32:53 <c705> no it isn't
2021-01-28 19:32:56 <ikke> https://pkgs.alpinelinux.org/packages?name=linux-lts&branch=v3.13
2021-01-28 19:32:56 <mps> for stables upgrades are at slower pace
2021-01-28 19:33:06 <ikke> pkgs.a.o says it is
2021-01-28 19:33:12 <ikke> c705: what mirror do you use?
2021-01-28 19:33:24 <c705> https://dl-cdn.alpinelinux.org/alpine/v3.13/main                                                          │[  +0.000001] usb 5-3.4: Manufacturer: SAMSUNG
2021-01-28 19:34:14 <c705> if it's upstream, then i'll wait
2021-01-28 19:35:44 <MY-R> https://gitlab.alpinelinux.org/alpine/aports/-/commit/8744f6fe7507df0af6220e8e5b59aabf9a8f9bca
2021-01-28 19:35:55 <ikke> Hmm: http://dl-master.alpinelinux.org/alpine/v3.13/main/x86_64/linux-lts-5.10.10-r0.apk
2021-01-28 19:36:15 <MY-R> builders stuck on something else?
2021-01-28 19:36:41 <ikke> but how does pkgs.a.o get it then
2021-01-28 19:36:54 <MY-R> oh ye
2021-01-28 19:37:11 <ikke> The x86_64 builder seems stuck
2021-01-28 19:37:13 <MY-R> so cdn didnt cache it yet?
2021-01-28 19:37:37 <ikke> It doesnt cache the file index
2021-01-28 19:37:57 <MY-R> ye arch64 got 5.10.11 on cdn
2021-01-28 19:39:41 <MY-R> is great idea to update to 5.10.11, previous versions broke intel drm things
2021-01-28 19:40:14 <dalias> uhg it did?
2021-01-28 19:40:37 <dalias> intel seems to work here -- what breakage should i expect?
2021-01-28 19:41:40 <ikke> hmm, I'm puzzled why pkgs.a.o already shows .11 for x86_64
2021-01-28 19:41:50 <MY-R> yeah, randomy missing letters/menus, screen flahes etc when used mpv
2021-01-28 19:45:33 <MY-R> https://gitlab.freedesktop.org/drm/intel/-/issues/2905
2021-01-28 20:06:13 <Hello71> actually there is quite a long history of such rpi bugs
2021-01-28 20:10:08 <Hello71> at least half a dozen going back a few years
2021-01-28 20:10:34 <minimal> Hello71: the RPI issues generally appear to be a combination of out-of-date/incorrect guides on the Wiki, change in behaviour for RPI between 3.12 and 3.13, and "other" issues. I tried helping in one of those recent tickets but gave up when my attempt to help fell on deaf ears.
2021-01-28 20:11:10 <ncopa> i killed the telepathy-glib on build-3-13-x86_64. it seemd to be deadlocked
2021-01-28 20:11:10 <Hello71> which change?
2021-01-28 20:12:19 <minimal> Hello71: ncopa changed one of the scripts to deal with the know issue of some of the RPI boot files being in the wrong place, let me find the related MR
2021-01-28 20:12:38 <Hello71> yes, the dtb files were moved
2021-01-28 20:12:47 <Hello71> but that's for upgrading. i'm talking about new installs
2021-01-28 20:12:57 <minimal> Hello71: This is the issue where I recently tried to help someone: !12353
2021-01-28 20:13:05 <Hello71> seems like people format with god-knows-what, then copy rpi files on
2021-01-28 20:13:27 <Hello71> i guess you mean #12353
2021-01-28 20:13:43 <minimal> yupe, my mistake :-)
2021-01-28 20:14:03 <Hello71> but as i was saying, then rpi bootloader fails to load kernel somehow
2021-01-28 20:14:03 <minimal> yeah. original person is trying to install SYS mode specifying a mountpoint rather than a device name
2021-01-28 20:14:43 <Hello71> minimal: there is confusion all around there
2021-01-28 20:15:54 <minimal> Hello71: I build my own SYS images for RPIs so I'm fairly familiar with how it should work. In this ticket someone else jumped on and talked about removing arbitary lines from the setup-disk script :-(
2021-01-28 20:18:21 <minimal> Hello71: I'm happy to help people with RPI, I'm happy to be party of an Alpine RPI team to sort things out in general, I've had 2 RPI-related MRs gathering dust for 1 month (not specific to this issue but trying to improve RPI support in general)
2021-01-28 20:19:40 <Hello71> if you have some time (and i guess maybe a windows box), can you or someone else try using "raspberry pi imager" to make a raspbian sd card, then try to put alpine on it by just deleting the contents and replacing with alpine tar?
2021-01-28 20:19:50 <Hello71> i'm pretty sure that's what everybody is trying to do
2021-01-28 20:20:27 <minimal> not sure if the Raspbian partitioning is similar to Alpine partitioning
2021-01-28 20:21:20 <minimal> for the people running "disk-setup -m SYS /mnt" they need to *themselves* have already partitioned and created filesystem, and mounted the first partition onto /mnt/boot before running that command.
2021-01-28 20:22:01 <minimal> whereas if they run "disk-setup -m SYS /dev/WHATEVER" the script is supposed to partition/createfs/mount correctly for them
2021-01-28 20:27:31 <minimal> Hello71: If many of them are using NOOBS that might explain, at least in part, issues as the partitions layout is different: https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained
2021-01-28 20:28:46 <minimal> however in the ticket I mentioned it appeared the original poster had booted Alpine on a RPI and was then attempting to do a SYS install - whether to the *same* SDcard they booted from or to a separate USB stick was not even mentioned or clear.
2021-01-28 20:30:27 <ikke> Hello71: you might have noticed, I started adding a label to the rpi issues
2021-01-28 20:33:09 <Hello71> ikke: not sure what you mean
2021-01-28 20:34:36 <Hello71> aha, i have reproduced the issue. copy on raspios image, delete all files from partition 1 then copy on alpine. result: failure to boot, ACT flash 7 times
2021-01-28 20:34:41 <minimal> ikke: noticed that. There's 4 RPI issues currently open and they're all differing situations
2021-01-28 20:36:35 <minimal> Hello71: so that's a run-from-RAM Alpine so I guess everything can be in the same FAT partition and work. Sounds like an issue with the config.txt or usercfg.txt contents
2021-01-28 20:36:57 <Hello71> no, it is the same. there is some problem with partition table or filesystem or somesuch
2021-01-28 20:37:07 <minimal> in the config.txt file what the path to the kernel and initramfs files?
2021-01-28 20:37:44 <minimal> what's "fdisk -l" / "parted print" or equivalent output?
2021-01-28 20:48:46 <minimal> Hello71: if somehow the config.txt from Raspian/Raspios is getting left behind that would be problem - Alpine names the kernel and initramfs files different than Raspbian
2021-01-28 20:58:45 <mps> how to 'flash' alpine tarball on mmc https://arvanta.net/alpine/flash-rpi-zero/ this is for rpi zero
2021-01-28 20:59:51 <mps> (a lot of people use somewhat strange argument, other distro)
2021-01-28 21:06:18 <minimal> Hello71: you there? Think I see an issue
2021-01-28 21:09:23 <Hello71_> so there definitely is something wrong with the raspios filesystem. reformatting it with a clean mkfs.fat fixes everything
2021-01-28 21:09:34 <minimal> Hello71: I see an issue
2021-01-28 21:09:36 <Hello71_> but fsck.fat doesn't detect anything wrong
2021-01-28 21:09:53 <Hello71_> sure, go ahead.
2021-01-28 21:11:01 <minimal> I downloaded the 3.13.0 armv7 tarfile to have a look - contents of cmdline.txt don't look right to me, it does have either "root=" or "rootfs=" specified. Not sure if both required but I'd expect to see "root=/dev/mmcblk0p1" for example
2021-01-28 21:11:05 <Hello71_> i enabled BOOT_UART but it doesn't print anything i don't already know
2021-01-28 21:11:44 <Hello71_> no, that's not right. first, initramfs auto-detects the modloop device. but even if it was related to that, it doesn't explain the seven blinks or why it works after reformatting
2021-01-28 21:12:13 <minimal> yeah, am looking at my notes on the mkfs.fat to see if anything jumps out
2021-01-28 21:13:32 <mps> minimal: this tarballs are intended to run-from-ram, not 'disk'
2021-01-28 21:14:16 <minimal> Hello71: for my own images I run "mkfs.fat -F32" but don't think that option is strictly necessary
2021-01-28 21:14:45 <minimal> mps: yeah, I have to keep reminding myself that, I've been running SYS setups for so long lol
2021-01-28 21:16:06 <mps> something like this https://arvanta.net/alpine/armhf-setup/
2021-01-28 21:19:00 <minimal> similar, no need to set the boot flag for the FAT partition, the RPI's bootloader looks for the 1st suitable partition
2021-01-28 21:21:10 <minimal> Hello71: what size is the FAT partition? is it FAT32? FAT16?
2021-01-28 21:23:16 <mps> true, not needed. this is artefact from another SBC
2021-01-28 21:50:46 <ncopa> im tagging 3.13.1 now
2021-01-28 21:53:30 <minimal> Hello71: one other thing, I've never (personally) had the kernel and initramfs files in a boot subdirectory of the FAT partition. I've only ever had them in the top-level/root of that FS - the commented for #12361 seem to imply having them in a subdir is an issue. Maybe try moving them (and updating config.txt references accordingly) ?
2021-01-28 21:53:41 <Hello71_> sigh
2021-01-28 21:54:59 <minimal> looking at a Raspbian/Raspios image I have handy it has the kernel and initramfs at the top-level too
2021-01-28 21:55:05 <Hello71_> yes.
2021-01-28 21:59:22 <minimal> there was a bit of a disconnect pre-3.13 in terms of how the tarball creation script put some RPI files and where some APK packaged files were actually placed (such that updating the RPI kernel packages wouldn't update those files)
2021-01-28 22:01:57 <minimal> that's why for my own stuff (SYS mode images) I resorted to mounting the boot partition as /boot and then also bind-mounting it as /boot/dtbs-rpi or dtbs-rpi2 or dtbs-rpi4 depending on the module I was using
2021-01-28 22:08:11 <minimal> Hello71: The docs at https://www.raspberrypi.org/documentation/configuration/config-txt/boot.md make no mention of the kernel & initramfs args supporting a path (on other hand they don't say they don't support a path...)
2021-01-28 22:38:16 <Hello71_> so i finally found the repo for rpios image generation: https://github.com/RPi-Distro/pi-gen
2021-01-28 22:38:30 <Hello71_> and it turns out the only difference is they specify -n boot
2021-01-28 22:38:49 <Hello71_> and apparently it doesn't work if the volume label is equal to the directory name
2021-01-28 22:43:34 <Hello71_> ncopa: if you're still around, see ^
2021-01-28 22:44:29 <Hello71_> i moved boot directory to aaaa, works fine if volume label is boot, stops working if set volume label to aaaa
2021-01-28 22:45:37 <Hello71_> odd thing is it still doesn't work with volume label aaaa and moving files to root, and it also doesn't work to specify ./filename
2021-01-28 22:48:53 <minimal> Hello71: doh! In my own setup I do pass "-n boot" to mkfs.fat but (like I said) I've never tried using a boot subdirectory.
2021-01-28 22:49:22 <minimal> for when the filenames are in the top-level I use the following config.txt entry:
2021-01-28 22:49:23 <minimal> [pi3]
2021-01-28 22:49:23 <minimal> kernel=vmlinuz-rpi2
2021-01-28 22:49:23 <minimal> initramfs initramfs-rpi2
2021-01-28 22:49:31 <minimal> so no "./", just the filename
2021-01-28 22:50:43 <Hello71_> yes
2021-01-28 22:50:57 <Hello71_> i was wondering if could do ./boot/file
2021-01-28 22:51:01 <Hello71_> but i guess not
2021-01-28 22:52:16 <minimal> the bootloader for the RPI is no flashable on models before the RPI4 so no chance of getting it fixed (I was involved in the early netboot trails and when they hit some switch-specific issues they said it wouldn't get fixed for some time and at considerable cost to them)
2021-01-28 22:52:26 <minimal> s/trails/trials/
2021-01-28 22:52:26 <alpine-meetbot> minimal meant to say: the bootloader for the RPI is no flashable on models before the RPI4 so no chance of getting it fixed (I was involved in the early netboot trials and when they hit some switch-specific issues they said it wouldn't get fixed for some time and at considerable cost to them)
2021-01-28 22:52:43 <Hello71_> well this isn't in preboot
2021-01-28 22:53:03 <minimal> its in bootcode.bin I guess
2021-01-28 22:53:54 <minimal> which then could be updated
2021-01-28 22:54:25 <mps> Hello71_: on alpine tarballs kernel and initramfs are in /boot
2021-01-28 22:54:55 <Hello71_> ncopa: why don't we mount mmc to /boot anyways? why is it a subdirectory
2021-01-28 23:00:19 <minimal> Hello71: its not just the kernels, package raspberrypi-bootloader (and subpackages) also puts files in /boot that should be in the top-level of the FAT partition.
2021-01-28 23:01:25 <minimal> however things need to cater for both run-from-ram (where its only using a single FAT partition for everything) and SYS mode where there would be 2 partitions. FAT32 for boot files and kernel, and EXT4 for rootfs
2021-01-28 23:08:47 <Hello71_> yes, but i don't see how that's relevant
2021-01-28 23:09:43 <minimal> Well it was related to your question "why don't we mount mmc to /boot anyways?". I wasn't quite sure what you meant by that
2021-01-28 23:11:08 <Hello71_> https://gitlab.alpinelinux.org/alpine/aports/-/issues/12368
2021-01-28 23:13:25 <Hello71_> damn buggy closed source software...
2021-01-28 23:13:25 <minimal> the point being on a SYS setup the 2nd partition with EXT4 would be mounted as "/" with the 1st FAT32 partition then mounted as /boot. In the case of the run-from-ram there's only 1 partition being used (FAT32) so where you suggesting mounting it at both "/" and "/boot"?
2021-01-28 23:23:58 <Hello71_> what?
2021-01-28 23:25:09 <mps> why sys part should be only ext4
2021-01-28 23:26:08 <minimal> full native filesystem for Linux which supports typical fs features unlike FAT
2021-01-28 23:26:29 <minimal> doesn't have to be only ext4, basically anything but FAT
2021-01-28 23:27:16 <mps> to repeat Hello71_s words 'damn buggy closed source software...' :)
2021-01-28 23:27:52 <mps> I think we don't ship closed software?
2021-01-28 23:28:08 <minimal> mps: firmware files?
2021-01-28 23:31:22 <mps> meh, I expected this :)
2021-01-28 23:31:22 <mps> and again, 'I think we don't ship closed software!'
2021-01-28 23:31:22 <minimal> Hello81: at least that's potentially/eventually fixable if reported to Raspberry Pi Foundation
2021-01-28 23:31:22 <mps> but, yes I know arguments, so don't need to hear again
2021-01-28 23:31:22 <Hello71_> specifically buggy software here is bootcode.bin/start.elf in rpi
2021-01-28 23:31:22 <minimal> s/Hello81/Hello71/
2021-01-28 23:31:22 <alpine-meetbot> minimal meant to say: Hello71: at least that's potentially/eventually fixable if reported to Raspberry Pi Foundation
2021-01-28 23:32:47 <mps> heh, Hello71_ you become somewhat older :)
2021-01-28 23:32:47 <minimal> mps: I'm sure this issue has given him a few grey hairs :-)
2021-01-28 23:32:47 <mps> minimal: and you?? ;)
2021-01-28 23:33:52 <mps> anyway, old rpis can be booted by u-boot and newer ones with uefi and these should be 'paths' to fixing booting
2021-01-28 23:34:04 <mps> that's my opinion
2021-01-28 23:35:00 <minimal> mps: I was grey long before this :-)
2021-01-28 23:35:49 <mps> ehm, I'm getting some
2021-01-28 23:35:59 <Hello71_> i'm not going to report it, there are already some hundreds of unreplied issues on github
2021-01-28 23:41:08 <sam_> they reply to most meaningful ones
2021-01-28 23:41:31 <mps> close alpine github
2021-01-28 23:44:02 <Hello71_> meh, i'm already tired of this problem. someone else can report if they want
2021-01-29 00:53:42 <opal> lot of rpi shit lately eh
2021-01-29 01:46:11 <omni> something is broken since 3.13.1, haven't figured out what yet, but my DomUs are unable to boot
2021-01-29 02:03:33 <Hello71_> think you're going to have to be more specific
2021-01-29 02:17:35 <omni> I will be
2021-01-29 02:39:53 <omni> downgrading dom0 linux to 5.10.10 helped
2021-01-29 03:16:59 <omni> 5.10.11 lts and virt work fine for domUs
2021-01-29 03:17:53 <omni> peculiar that 'apk -U upgrade' didn't upgrade my downgraded packages (linux-lts & zfs-lts)
2021-01-29 03:32:29 <omni> here are the error messages from trying to start a domU with 'xl create' http://paste.debian.net/1183160/
2021-01-29 03:32:52 <omni> in the above case there are two disks backed by a couple of zvols
2021-01-29 03:36:13 <omni> I skimmed https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.11 but it's pretty big
2021-01-29 07:22:38 <ncopa> morning
2021-01-29 07:22:44 <ncopa> so linux 5.10.11 is broken?
2021-01-29 08:01:52 <ncopa> Hello71_> i moved boot directory to aaaa, works fine if volume label is boot, stops working if set volume label to aaaa
2021-01-29 08:02:00 <ncopa> can you add that info to the isse?
2021-01-29 08:02:33 <ncopa> it sounds like a weird bug in raspberry pi bootloader. I could not find the sources for rpi boot loader
2021-01-29 09:08:27 <Cogitri> Could someone who knows RPI stuff review !15863 ?
2021-01-29 09:11:19 <mps> this should be closed
2021-01-29 09:12:04 <mps> user should make change in currently available pkg and not create separate one
2021-01-29 09:12:34 <mps> (but gitlab openness will kill alpine, sooner or later)
2021-01-29 09:15:00 <Cogitri> Not sure if that can be done with the RPI stuff, since that package is built against the RPI API
2021-01-29 09:57:01 <Newbyte> if I wanted to package something but I realised I packaged the wrong thing and I now have no use for it, should I drop the package?
2021-01-29 09:57:21 <Newbyte> I wouldn't personally mind keeping it in aports but I also don't have any reason to keep it there
2021-01-29 09:58:51 <mps> Newbyte: I have similar dilemma for some pkgs, I think moving them to unmaintained and remove maintainer field is most proper
2021-01-29 09:59:36 <mps> but also remove is quite ok if no one ask for keep it
2021-01-29 10:00:17 <mps> imo, we have a bunch of pkgs which should be removed/moved
2021-01-29 10:04:02 <Newbyte> I'll move it to unmaintained then, thanks
2021-01-29 11:07:36 <adhawkins> Any python experts around who can help me get the quantiphy_eval package updated to v0.4?
2021-01-29 11:08:07 <adhawkins> This is what I get if I try to build the release tarball after installing appropriate dependencies on Alpine:
2021-01-29 11:08:19 <adhawkins> https://paste.debian.net/1183196/
2021-01-29 11:09:01 <adhawkins> I've installed: python3 py3-quantiphy py3-inform py3-sly py3-setuptools py3-pytest. py3-sly is a new package I'm in the process of packaging while trying to update quantiphy_eval
2021-01-29 11:36:58 <omni> ncopa: https://lore.kernel.org/xen-devel/20210129005129.GA2452@mail-itl/T/#ma8f4a2e5cb092c92dd6496142bb1f5145bed59ad
2021-01-29 11:42:32 <ncopa> omni: do you think we should backport that patch or waith for 5.10.12?
2021-01-29 11:49:22 <omni> ncopa: I'd say backport, before more people upgrade their dom0 kernel to 5.10.11-r0
2021-01-29 11:50:54 <adhawkins> Think I've got to the bottom of my issue. The 'sly' repo on github doesn't have labels for the latest release. The current version of 'master' does appear to be correct however. Is there an accepted way of downloading a specific git commit when building an Alpine package?
2021-01-29 11:50:57 <omni> I haven't set up an environment to buil packages myself yet, but if it lands in edge first I could install it from there
2021-01-29 11:54:43 <Hello71_> ncopa: it is closed source, as I complained about earlier
2021-01-29 11:55:29 <Hello71_> sam_ claims that they reply to filed issues though so maybe it's worth a shot
2021-01-29 11:58:03 <Hello71_> Cogitri, mps: there are several such issues open about libcec
2021-01-29 12:01:41 <alexy> for some reason dabuild is using user 1000 group 1000 by default, running into all sorts of permission issues
2021-01-29 12:03:50 <adhawkins> Anyone care to comment on this approach to packaging a specific github commit? https://paste.debian.net/1183207/
2021-01-29 12:04:02 <adhawkins> In particular look at source and builddir lines, which aren't pretty.
2021-01-29 12:04:39 <alexy> i would if i know where to begin, adhawkins :)
2021-01-29 12:05:31 <adhawkins> Due to there being not 'release' tags on the upstream git repo, I'm having to specify a particular commit to get that release. Wondering if that's the 'done' thing, and whether this is the best way to do it.
2021-01-29 12:05:38 <adhawkins> I've submitted an issue upstream asking for tags.
2021-01-29 12:07:27 <ikke> adhawkins: It's prefered to have proper releases from upstream
2021-01-29 12:07:35 <ikke> so if upstream is willing to create tags, that's good
2021-01-29 12:08:13 <alexy> adhawkins:  the community/mirage/APKBUILD has a bunch of commit hash, is that what you're looking for?
2021-01-29 12:09:44 <alexy> adhawkins: also the community/docker one
2021-01-29 12:21:45 <mps> Hello71_: I will look over weekend and try to understand these, but no promise. as yo wrote last night also I'm becoming 'tired' on these cec/rpi
2021-01-29 12:24:34 <ikke> Interesting, GKH says that 5.10 lts support duration relies on support from others (meaning usage and testing)
2021-01-29 12:41:50 <jvoisin> https://dev.gnupg.org/T5259 exploitable heap overflow in libgcrypt 1.9, not packaged in alpine ♥
2021-01-29 12:43:13 <omni> ncopa: in the meantime I opened an issue for others to find
2021-01-29 12:44:36 <Hello71_> adhawkins: regarding your first issue, probably ask upstream
2021-01-29 12:45:14 <Hello71_> regarding your second issue, generally (alpine or otherwise) it's better to refactor such "magic constants" out into separate variables
2021-01-29 12:45:35 <Hello71_> especially considering that in this case you probably want to change it when new version
2021-01-29 12:45:48 <Hello71_> e.g. _commit=06b92e3e735db55b2d53db488785b2acc9d655ac; etc
2021-01-29 12:51:38 <ikke> jvoisin: mind creating an issue for it on gitlab?
2021-01-29 12:53:45 <jvoisin> I don't have access to my account atm :/
2021-01-29 13:25:47 <minimal> Cogitri: can you have arch-specific makedepends? If so then I'd agree with mps that the rpi-specific stuff should be subpackages of existing libcec
2021-01-29 13:27:42 <maxice8> minimal: case "$CARCH" in x86_64) makedepends="$makedepends ..." ;; esac
2021-01-29 13:29:30 <minimal> maxice8: cool. I'll add a comment to that effect in the MR
2021-01-29 13:32:03 <adhawkins> Hello71_: Thanks for the tip about using a constant, now done.
2021-01-29 13:32:16 <adhawkins> I've create an issue upstream to ask them to create tags for the releases.
2021-01-29 13:32:56 <adhawkins> And it now builds in CI :)
2021-01-29 13:57:10 <adhawkins> Anyone care to look over !17567 for me? Particularly interested in the py3-sly package and its use of a specific GitHub commit for the release files (no tags in upstream)
2021-01-29 14:28:12 <adhawkins> ikke: Can you point me to the container the CI stuff uses to lint a MR? Figured it'd be a good idea to have that available locally as well as the CI build one.
2021-01-29 14:29:50 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/apkbuild-lint-tools
2021-01-29 14:30:15 <Hello71_> ncopa: added that information to issue and filed github bug upstream
2021-01-29 14:30:35 <adhawkins> Perfect, thanks ikke. Will see if I can get that working locally.
2021-01-29 14:46:37 <adhawkins> ikke: Does /usr/local/bin/lint expect a list of aports to be available as stdin?
2021-01-29 14:47:42 <adhawkins> Ah, got it I think ikke. You don't need to specify a command for this container, it runs the 'changed' and 'lint' stuff itself.
2021-01-29 14:57:53 <oliv3r[m]> Hey guys, is there a 'nice' way to use different versions for subpackages? i have a (vendor supplied) library + application bundle; i want to create a subpkg for the library; however the library has  a different version then the binary. Can i put this somewhere in the tuple or is it _split() {pkgver="abc" default_libs}?
2021-01-29 15:04:33 <Cogitri> I don't think we have a nice way to do that and that sounds really hacky in general to be honest
2021-01-29 15:38:05 <oliv3r[m]> it is hacky; but one zip; binary + library deliverable; but hacking it via a custom lib_split (with default_libs) is the way to go i suppose
2021-01-29 15:39:09 <Cogitri> I suppose so, yes
2021-01-29 15:55:46 <alexy> If any developer with merge access is around please take a look at https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/87
2021-01-29 15:56:45 <alexy> Until that's merged I'll have to use a custom doc() for gtksourceviewmm which is strongly discouraged according to the guide
2021-01-29 15:58:05 <alexy> spent hours to sort out the screw up between gtksourceviewmm 3.21.3 and 3.91.1
2021-01-29 15:58:31 <alexy> 3.91.1 is actually internally 4.0 and produces xxx-4.0.so
2021-01-29 15:59:23 <alexy> broke multiple builds depending on 3.x
2021-01-29 16:12:17 <ikke> It requires a new abuild release and updating it in aports as well
2021-01-29 16:13:10 <maxice8> isn't 3.91.1 a preview release anyways ?
2021-01-29 16:13:50 <PureTryOut[m]2> ncopa: could you take a look at https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/14218?
2021-01-29 16:13:58 <alexy> yes, and it has been the latest version since 2018
2021-01-29 16:14:46 <alexy> doesn't look like they'll be releasing 4.0 anytime soon
2021-01-29 16:54:18 <alexy> hmm, on a new MR, the pipeline passed for x86+x86_64 but failed on others because it's missing a new dep (mm-common)
2021-01-29 16:54:47 <alexy> mm-common was merged yesterday, does it take awhile before it's available for aarch64 and others?
2021-01-29 16:55:08 <ikke> alexy: if the builders are stuck on something, then yes
2021-01-29 16:55:19 <alexy> mm-common is on "noarch"
2021-01-29 16:55:22 <alexy> ahh
2021-01-29 16:55:47 <ikke> it will still be built for each specific arch
2021-01-29 16:58:25 <ikke> Can someone review this sudo MR (backport for CVE-2021-3156 for 3.11): https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17614
2021-01-29 17:08:02 <ikke> I've 'mechanically' backported the changes
2021-01-29 17:42:02 <c705> speaking of sudo, i think we'll have another local priv esc bug that needs to be patched
2021-01-29 17:42:36 <c705> CVE-2021-3347 was assigned 20 or so minutes ago, affects <=5.10.11, no patch from kernel.org yet though
2021-01-29 17:46:18 <ikke> oh, fun
2021-01-29 17:50:31 <artok> oh gosh
2021-01-29 17:53:59 <c705> i'm not sure where the "local priv esacalation" comes from, haven't seen any working exploits or anything
2021-01-29 17:55:02 <maxice8> I really need to drive the point home we are not Arch Linux
2021-01-29 17:55:30 <c705> what's the point?
2021-01-29 17:55:44 <maxice8> we have automatic soname dependencies
2021-01-29 17:55:50 <maxice8> one doesn't need to add every library to depends=
2021-01-29 17:57:56 <skarnet> ah so that's what "noarch" means
2021-01-29 17:58:01 <skarnet> "not like arch linux"
2021-01-29 17:58:12 <skarnet> 
ACTION is already out

2021-01-29 18:01:25 <maxice8> I chuckled a bit
2021-01-29 21:54:23 <alexy_> are licenses generally assumed to be "-or-later" unless the author have stated otherwise?
2021-01-29 21:54:38 <maxice8> it should be specified in the headers
2021-01-29 21:55:07 <alexy_> hmm
2021-01-29 21:55:27 <ikke> alexy_: check the source files themselves
2021-01-29 21:55:39 <alexy_> ok
2021-01-29 23:54:58 <Hello71_> hm... https://alpinelinux.org/releases/ doesn't have all the columns of https://wiki.alpinelinux.org/w/index.php?title=Alpine_Linux:Releases&oldid=18285
2021-01-29 23:56:08 <Hello71_> specifically, is 3.9 still supported for security
2021-01-29 23:56:56 <Hello71_> as a practical matter it seems like those remaining 3.9 issues are not going to be fixed after 1.5 years of sitting in gitlab
2021-01-30 07:19:41 <ikke> We need to deprecate that page, the releases are listed on the main web page now
2021-01-30 12:23:36 <omni> is the information provided at the (somewhat outdated) wikipage available elsewhere?
2021-01-30 12:23:47 <omni> like EoL etc
2021-01-30 12:24:52 <Cogitri> omni: https://alpinelinux.org/releases/
2021-01-30 12:25:41 <Cogitri> I think that page should mention that community only has 6 months of support though
2021-01-30 12:26:24 <omni> oh, ok =)
2021-01-30 12:28:28 <ikke> It does
2021-01-30 12:28:31 <ikke> at the top
2021-01-30 12:30:24 <omni> there we go
2021-01-30 12:30:50 <Hello71_> ikke: https://wiki.alpinelinux.org/w/index.php?title=Alpine_Linux:Releases&diff=18572&oldid=18285
2021-01-30 12:31:01 <Hello71_> but you didn't answer my question
2021-01-30 12:32:05 <ikke> Hello71_: ah, didn't get it was a question
2021-01-30 12:32:42 <ikke> v3.9 2019-01-29 3.9-stable | 3.9.6 | 3.9.5 | 3.9.4 | 3.9.3 | 3.9.2 | 3.9.1 | 3.9.0 2020-11-01
2021-01-30 12:32:48 <ikke> so officially, not anymore
2021-01-30 12:37:27 <adhawkins> Just out of interest (and by no means a complaint!) but does someone just walk over the open MRs and process them? I've tended to 'pester' about the previous ones, but just leaving this one to be processed naturally.
2021-01-30 12:41:10 <ikke> adhawkins: yes
2021-01-30 12:41:34 <ikke> Normally it's not necessary to notify someone for every MR
2021-01-30 12:47:34 <adhawkins> Yep, I'm trying to avoid becoming that guy who pesters every time he submits an MR :)
2021-01-30 12:47:47 <adhawkins> Just wanted to get a rough feel for when I should expect it to get processed 'naturally'.
2021-01-30 12:48:42 <ikke> 1 day to 1 week is normal
2021-01-30 12:48:57 <adhawkins> Ok, I'll keep an eye on it.
2021-01-30 12:49:00 <adhawkins> Thanks ikke.
2021-01-30 12:58:18 <TBK[m]> !17026
2021-01-30 13:06:30 <Hello71_> dalias, sh4rm4^bnc: it occurred to me that i may have been too harsh on xf86-video-intel previously. if it works without bugs for you, it's probably fine to keep using it. but any bugs, including freezing and crashing, seem to not be fixed by upstream for quite a few years now, and bugs are likely to increase since i think neither windows nor major linux distros use the low-level 2d accel
2021-01-30 14:32:51 <sh4rm4^bnc> and all that thanks to not producing a release
2021-01-30 16:49:08 <ikke> Anyone care to review this? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/17614
2021-01-30 16:50:47 <maxice8> Unfortunately I don't know C
2021-01-30 16:50:48 <mps> !17614
2021-01-30 16:50:51 <mps> algitbot: ?
2021-01-30 16:51:14 <Hello71_> ikke: what are other distros doing?
2021-01-30 16:52:25 <ikke> similar things
2021-01-30 16:55:24 <ikke> https://git.launchpad.net/ubuntu/+source/sudo/tree/debian/patches/
2021-01-30 16:57:16 <Hello71_> i mean ubuntu isn't a great source -.-
2021-01-30 16:57:35 <ikke> no, I nkow
2021-01-30 16:57:37 <maxice8> why ?
2021-01-30 16:57:56 <ikke> I rebased the patches myself, and compared it at least with what ubuntu did
2021-01-30 16:58:04 <ikke> (because it's the exact same version)
2021-01-30 16:58:36 <mps> superficially looking looks ok, but I don't have time for deep analysis
2021-01-30 16:59:14 <Hello71_> maxice8: ubuntu has terrible security. particularly terrible when it comes to patching
2021-01-30 16:59:18 <Hello71_> (correctly)
2021-01-30 16:59:28 <Hello71_> https://securitylab.github.com/research/Ubuntu-gdm3-accountsservice-LPE
2021-01-30 17:01:18 <ikke> I don't see where debian has patched sudo
2021-01-30 17:05:02 <Hello71_> seems debian did same
2021-01-30 17:06:02 <Hello71_> according to their patch comments, just context changes
2021-01-30 17:07:02 <Hello71_> i wonder if default_prepare should set patch -F0. i don't think other distros do though
2021-01-30 17:08:58 <ikke> yes, when I backported, there were only context changes
2021-01-30 18:23:40 <dalias> hello71_, *nod*
2021-01-30 18:23:52 <dalias> i wish they'd fix the dri/modesetting driver then tho
2021-01-30 18:24:02 <dalias> it should be possible to implement fast 2d primitives using the gpu
2021-01-30 18:24:06 <dalias> they just.... don't
2021-01-30 18:33:20 <dalias> yay now that i solved my udev problem, purged libinput and switched back to evdev
2021-01-30 18:33:25 <dalias> and my mouse sensitivity is back right
2021-01-30 18:33:39 <dalias> for some idiotic reason xf86-input-libinput has different scaling
2021-01-30 18:34:00 <dalias> why is everything in this domain so awful??
2021-01-30 18:34:40 <skarnet> the answer starts with free and ends with desktop.org
2021-01-30 18:37:28 <dalias> i mean why would you make B that's supposed to replace A, but that breaks the most critical personalized part of the ux ?!
2021-01-30 18:39:03 <skarnet> I already answered that
2021-01-30 18:39:33 <dalias> :)
2021-01-30 18:39:44 <dalias> skarnet, did you find anything more about the time64 breakage?
2021-01-30 18:40:55 <skarnet> no, I just shaved the yak to the point I'm now able to investigate it, and intended to do it today, but life got in the way. I'll do that tomorrow or Monday.
2021-01-30 18:41:01 <dalias> ook
2021-01-30 19:30:11 <Hello71_> as i recall, the problem with evdev/synaptics is too much fragmentation in workarounds for bad hardware
2021-01-30 19:30:50 <Hello71_> so it works great on specifically those input devices that were tested, but works poorly on everything else
2021-01-30 19:31:05 <Hello71_> and it's impossible to add new features without breaking the workarounds
2021-01-30 20:05:03 <dalias> ?
2021-01-30 20:09:03 <dalias> fuck, since upgrading alpine firefox closes every few hours from oom :(
2021-01-30 20:09:15 <dalias> i need to make a bigger swap partition i guess :(
2021-01-30 20:38:42 <Hello71_> use jemalloc, that'll help
2021-01-30 21:38:45 <mps> iiuc from #musl sudo vulnerabilty is related to linux-pam
2021-01-30 21:41:20 <dalias> i'm not sure if it depends on pam
2021-01-30 21:41:52 <dalias> i recall seeing one conversation about it where it appeared that pam's fooling around with malloc/free was necessary to get the heap into an exploitable state
2021-01-30 21:42:29 <mps> aha
2021-01-30 21:47:30 <dalias> but i dont know if that's true
2021-01-30 21:47:51 <dalias> i have not analyzed it in detail because i dont run any systems affected by it :-p
2021-01-30 21:48:35 <ikke> https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit does not mention PAM
2021-01-30 21:48:38 <mps> I run doas for (hm) long time
2021-01-30 21:49:42 <mps> and I do 'su - root' often
2021-01-30 21:50:25 <ikke> doas had it's own vulnerability :) (though way less severe as sudo)
2021-01-30 21:52:41 <mps> yes, but what doesn't have them (except maybe djbnds)
2021-01-30 21:54:49 <dalias> ikke, it doesn't go into detail about how to exploit the heap overflow afaict
2021-01-30 21:55:15 <dalias> in order for a heap overflow to be useful it has to (1) reach into the data you want to clobber, and (2) not be caught before the clobbered data gets used
2021-01-30 21:55:34 <ikke> right
2021-01-30 21:55:46 <dalias> i'm not sure if you can arrange that without pam
2021-01-30 21:56:12 <dalias> it seems unlikely that there's significant use of malloc/free that would let you setup an exploitable arrangement without complex library code running
2021-01-30 21:56:23 <dalias> but it may be possible
2021-01-30 21:56:53 <ikke> So you say sudo without pam (like by default on alpine) would not be easily exploitable?
2021-01-30 21:57:29 <jvoisin> https://www.kalmarunionen.dk/writeups/sudo/ here is a detailled writed
2021-01-30 21:57:31 <jvoisin> *writeup
2021-01-30 21:57:48 <dalias> ikke, i say i don't know, but it's plausible that that's the case
2021-01-30 21:58:00 <dalias> by default assume it is exploitable :)
2021-01-30 21:58:05 <dalias> but it's plausible that it's not
2021-01-30 21:58:12 <ikke> yes, that's a fair assumption
2021-01-30 22:03:27 <yZ5vlALg86lP> heres PoCs https://github.com/stong/CVE-2021-3156 https://github.com/lockedbyte/CVE-Exploits/tree/master/CVE-2021-3156
2021-01-30 22:05:33 <dalias> jvoisin, the writeup there is glibc-specific
2021-01-30 22:05:56 <dalias> i wonder if anyone has a plausible one for musl-based system
2021-01-30 22:08:23 <dalias> based on it i think it's sounding more and more plausible that you can't exploit this on musl
2021-01-30 22:08:48 <yZ5vlALg86lP> anyway `sudoedit -s '\' $(python3 -c 'print("A"*1000)')` doesn't give me a crash
2021-01-30 22:08:55 <dalias> because musl is not going to do a bunch of malloc+free for you
2021-01-30 22:09:47 <yZ5vlALg86lP> nah. sudoedit complains it doesn't know -s as a switch
2021-01-30 22:13:17 <dalias> meh
2021-01-30 23:37:35 <yZ5vlALg86lP> ah, it gets easier to exploit actually: https://seclists.org/oss-sec/2021/q1/88
2021-01-31 18:22:11 <omni> https://lists.debian.org/debian-kernel/2021/01/msg00369.html
2021-01-31 20:34:48 <bratkartoffel> can someone please merge !15326 ?
2021-01-31 20:36:26 <bratkartoffel> backports of openjdk7 (!15298 and !15297) are also waiting for some time now
2021-01-31 20:39:50 <bratkartoffel> thanks ikke for taking care of these MR :)
2021-01-31 20:47:38 <ikke> bratkartoffel: np
2021-01-31 23:52:32 <mps> jvoisin: !17678 we prefer size optimization
2021-01-31 23:57:32 <Hello71> why does monit particularly need speed optimizations?
2021-01-31 23:57:52 <Hello71> the python one kind of makes sense pragmatically despite being semantically wrong
2021-01-31 23:58:19 <mps> yes, right question