2020-09-01 10:03:28 <PureTryOut[m]> in pmOS we had a package mesa-git meant as a replacement for mesa. Nowadays there is no need for it anymore so we're trying to get installations to replace it for regular mesa again. I've added the `replaces="<stuff>"` in all it's subpackages but upgrading an installation causes issues
2020-09-01 10:03:56 <PureTryOut[m]> For some reason mesa-dri-gallium specifically complains while upgrading. For example `ERROR: mesa-dri-gallium-20.1.5-r1: usr/lib/xorg/modules/dri/etnaviv_dri.so: no hard link target (usr/lib/xorg/modules/dri/armada-drm_dri.so) in archive`
2020-09-01 10:04:20 <PureTryOut[m]> This causes the package (mesa-dri-gallium) to be installed but be completely empty. We need to run `apk fix mesa-dri-gallium` to fix it
2020-09-01 10:04:27 <PureTryOut[m]> How can we prevent this issue from occuring?
2020-09-01 10:25:24 <PureTryOut[m]> I can't really find anything on "no hard link target"...
2020-09-01 10:25:56 <ikke> Wonder where that hard link comes from
2020-09-01 10:26:40 <PureTryOut[m]> Not sure
2020-09-01 10:26:42 <ikke> Is that something that the project does that ends up in the archive?
2020-09-01 10:27:06 <Cogitri> I think mesa does hardlinks for the individual drivers
2020-09-01 10:27:14 <PureTryOut[m]> It does yes
2020-09-01 10:27:31 <PureTryOut[m]> Alpine's mesa package works the same way as our previous mesa-git did
2020-09-01 10:28:44 <ikke> https://git.sr.ht/~sircmpwn/apk-tools/commit/6484ed9849f03971eb48ee1fdc21a2f128247eb1
2020-09-01 10:28:53 <ikke> It contains the "no hard link target" message
2020-09-01 10:28:59 <PureTryOut[m]> Yeah I found that commit too
2020-09-01 10:30:14 <PureTryOut[m]> But the hard link target does exist... An apk fix fixes the issue which shows that the target does exist, otherwise that would just fail as well
2020-09-01 10:30:26 <ikke> right
2020-09-01 10:30:59 <ikke> Sounds like something to report to apk-tools
2020-09-01 10:31:44 <PureTryOut[m]> Ah ok will do
2020-09-01 10:40:51 <afontain_> ikke: I think the hard link is made at build time by the build system
2020-09-01 10:43:21 <PureTryOut[m]> I made https://gitlab.alpinelinux.org/alpine/apk-tools/-/issues/10709 for now
2020-09-01 11:33:09 <Hello71> PureTryOut[m]: what's the link to the apk?
2020-09-01 11:33:48 <PureTryOut[m]> None, building locally atm as it's a non-merged MR still
2020-09-01 11:33:53 <PureTryOut[m]> Although maybe I can link the CI artifact, hold on
2020-09-01 11:34:46 <mps> 'options="!check" # Need /dev/tty which we don't have on builders'
2020-09-01 11:35:03 <mps> in !11950
2020-09-01 11:35:22 <Hello71> uh... can't you run it in script?
2020-09-01 11:35:23 <mps> does that stand?
2020-09-01 11:35:52 <Hello71> also doesn't this PR *remove* that line?
2020-09-01 11:35:56 <Hello71> MR
2020-09-01 11:36:51 <mps> Hello71: you are asking me or?
2020-09-01 11:37:15 <Hello71> mps: what does "does that stand" mean
2020-09-01 11:37:20 <PureTryOut[m]> Hello71: CI pipeline is still running but you can see progress here and download artifacts from it as well once it's finished. https://gitlab.com/postmarketOS/pmaports/-/jobs/713444703
2020-09-01 11:37:35 <Hello71> PureTryOut[m]: ok, thanks
2020-09-01 11:37:41 <mps> Hello71: remove from APKBUILD
2020-09-01 11:38:10 <Hello71> mps: uh... I still don't understand
2020-09-01 11:38:18 <Hello71> who is the subject
2020-09-01 11:39:03 <mps> Hello71: !11950 have removal of options var
2020-09-01 11:39:41 <Hello71> yes, that sounds correct to me. and?
2020-09-01 11:39:48 <mps> but too late, merged
2020-09-01 11:41:40 <ikke> it fails on s390x
2020-09-01 11:44:03 <mps> I see, lets wait other and if fails again I will revert this option
2020-09-01 11:44:27 <ikke> most arches seems to succeed
2020-09-01 11:44:54 <ikke> ppc64le and mips64 are still missing
2020-09-01 11:45:40 <mps> I see, ppc64le finished, but mips64 is long behind I think
2020-09-01 11:46:15 <ikke> yes, it's blocked on gcc atm
2020-09-01 11:46:46 <mps> do we need to keep mips64 and s390x
2020-09-01 11:47:07 <ikke> if it looks broken on s390x, I would disable it there
2020-09-01 11:53:18 <mps> yes, working
2020-09-01 12:47:26 <PureTryOut[m]> Hello71: btw that CI pipeline is done and artifacts can be downloaded.
2020-09-01 12:47:29 <mps> hmm, we got pipewire again for firefox. is it tested to work?
2020-09-01 12:52:52 <Hello71> PureTryOut[m]: not sure what's wrong, but I need to go out now. probably be good to post a link to the apk on the issue too
2020-09-01 13:00:08 <Cogitri> mps: Yes, works on Wayland at least
2020-09-01 13:00:18 <Cogitri> Although we'll need DBus in FF again for proper Wayland support
2020-09-01 13:00:55 <mps> let me check on X again
2020-09-01 13:07:24 <mps> looks like it works, let see for few hours
2020-09-01 14:46:07 <sonder> Ariadne: Thanks, it turned out that the library I was using did a insane amount of de/allocations. It is annoyning that other allocators allow this and therefore people aren't careful with allocations.
2020-09-01 14:55:59 <mps> sonder: was interesting to follow on #musl ;)
2020-09-01 17:21:01 <crosbymichael> can 'nut' get out of testing and into community?
2020-09-01 17:27:09 <mps> probably yes, I'm using it on one server
2020-09-01 17:52:40 <crosbymichael> i'm using it as well
2020-09-01 19:47:02 <ikke> ocaml is failing due to -fno-common from gcc10 I believe
2020-09-01 19:51:26 <Cogitri> And it was orphaned a few hours ago
2020-09-01 19:51:41 <ikke> 50 minutes ago
2020-09-01 19:51:46 <ikke> that was what triggered the build error
2020-09-01 19:54:03 <ikke> Fixed one issue, but the next one is more tricky
2020-09-01 19:54:13 <ikke> startup_nat_npic.o:(.bss+0x120): multiple definition of `caml_atom_table'; startup_aux_npic.o:(.bss+0x20): first defined here
2020-09-01 20:03:38 <ikke> nice, fixed
2020-09-01 20:22:10 <ikke> ooh, htop got a update (by new maintainers)
2020-09-01 20:22:55 <ikke> oh, we already have it :D
2020-09-01 20:23:07 <ikke> mps: thanks :P
2020-09-01 20:23:39 <mps> ikke: np ;)
2020-09-01 20:25:32 <ikke> Interesting read from the original maintainer: https://github.com/hishamhm/htop/issues/992#issuecomment-683286672
2020-09-01 22:26:05 <maxice8> algitbot: retry master
2020-09-02 01:19:10 <maxice8> trying to push musl fixes upstream, most projects that need it use sourceforge unfortunately
2020-09-02 01:22:47 <maxice8> algitbot: retry master
2020-09-02 01:24:03 <dalias> heh sf
2020-09-02 01:28:32 <maxice8> so many #include <limits.h> missed
2020-09-02 07:14:47 <ikke> morning
2020-09-02 07:17:55 <mps> ikke: good morning
2020-09-02 07:18:36 <ikke> libhandy1 is failing to build
2020-09-02 07:26:18 <Cogitri> Yes, looking into it now
2020-09-02 07:26:29 <Cogitri> I'm wondering how it worked just fine on CI 🤔
2020-09-02 07:27:18 <ncopa> i saw someone reverted meson upgrade? maybe its related
2020-09-02 07:27:33 <Cogitri> Nop, we needed that for gis and libpeas
2020-09-02 07:27:36 <ncopa> 850a9b2dabafe24c5e91d3b43442aaf2085b6ec0
2020-09-02 07:27:51 <Cogitri> I reverted 0.55.0 to 0.54.3 due to that but it was upgraded to 0.55.1 again which was still broken
2020-09-02 07:27:58 <Cogitri> So it got downgraded again
2020-09-02 07:28:07 <Cogitri> I think for some reason the new glade wasn't pulled in on CI
2020-09-02 07:28:44 <ncopa> myabe builders didnt complete the previous buildjob
2020-09-02 07:32:08 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/197374
2020-09-02 07:32:14 <Cogitri> Oh, that's why CI was happy
2020-09-02 07:32:20 <Cogitri> ...why didn't it build anything? :D
2020-09-02 07:32:37 <ikke> hmff, it does the sometimes, I need to figure out why
2020-09-02 07:33:16 <ikke> But we only notice it after the fact, when the source branch has already been deleted, so no way for me to verify
2020-09-02 07:36:38 <Cogitri> Ah right, hard to check for it then :/
2020-09-02 07:39:30 <ncopa> the CI should exit with failure if git checkout fails?
2020-09-02 07:40:43 <ikke> "fatal: master...HEAD: no merge base"
2020-09-02 07:40:54 <ikke> so git merge-base fails
2020-09-02 09:07:20 <Cogitri> I think gjs on x86_64 is stuck, could someone kill it?
2020-09-02 09:35:43 <maxice8> algitbot: retry master
2020-09-02 09:36:29 <ikke> The last lines in the log is
2020-09-02 09:36:31 <ikke> [102/102] Generating GjsPrivate-1.0.typelib with a custom command
2020-09-02 09:36:33 <ikke> ninja: nothing to do
2020-09-02 09:44:31 <ikke> FUTEX_WAIT_PRIVATE
2020-09-02 09:44:39 <ikke> sounds like a maloc-after-fork deadlock again?
2020-09-02 10:02:22 <Cogitri> Ugh, so it's in gobject-introspection too
2020-09-02 10:03:00 <Cogitri> I think it worked on other arches tho, so maybe it'll just work on the next try
2020-09-02 10:09:24 <ikke> It's building webkit2gtk now
2020-09-02 10:27:43 <ikke> webkit2gtk fails on armv7
2020-09-02 10:28:07 <ikke> error: there are no arguments to 'dumpJITMemory' that depend on a template parameter, so a declaration of 'dumpJITMemory' must be available [-fpermissive]
2020-09-02 10:56:57 <Cogitri> Yeah, made a MR for it, let's see if CI likes it
2020-09-02 10:58:38 <Cogitri> Doesn't seem like it :/
2020-09-02 11:26:04 <maxice8> i think x86_64 is stuck again
2020-09-02 11:28:54 <ikke> 03:19:05      algitbot │ edge/community/x86_64: uploaded
2020-09-02 11:28:57 <ikke> 103:19:05      algitbot │ edge/community/x86_64: uploaded
2020-09-02 11:29:04 <ikke> lol
2020-09-02 11:29:06 <maxice8> Oh
2020-09-02 11:29:11 <maxice8> rakudo tests just took a bit
2020-09-02 13:23:28 <ollieparanoid[m]> hi all!
2020-09-02 13:23:42 <ikke> hey
2020-09-02 13:24:03 <ollieparanoid[m]> the 3.12 builders all display "failed" at https://build.alpinelinux.org/ and new packages are not being built
2020-09-02 13:24:35 <ollieparanoid[m]> can somebody look into it? let me know if I can help
2020-09-02 13:24:37 <Cogitri> algibot: retry master
2020-09-02 13:24:51 <Cogitri> algitbot: retry 3.12-stable
2020-09-02 13:25:02 <Cogitri> algitbot: retry master
2020-09-02 13:25:04 <Cogitri> :D
2020-09-02 13:26:05 <ollieparanoid[m]> now build-3-12-mips64 is trying to build main/vala, but the others still have "failed" without showing where they actually failed
2020-09-02 13:51:48 <PureTryOut[m]> algitbot: retry 3.12-stable
2020-09-02 13:52:19 <PureTryOut[m]> Yeah it's not actually retrying
2020-09-02 13:54:36 <ikke> hmm, trying to figure out what's going on
2020-09-02 13:56:56 <ollieparanoid[m]> thanks!
2020-09-02 14:26:09 <ikke> aha, there is an APKBUILD with a syntax error
2020-09-02 14:26:11 <ikke> great
2020-09-02 14:26:16 <ikke> in community
2020-09-02 14:27:29 <ikke> 87e30bb49d25155c5e2df96cb42411de249f6919
2020-09-02 14:27:56 <ikke> maxice8: committed a conflict
2020-09-02 14:30:41 <ikke> ollieparanoid[m]: 3.12 builds again
2020-09-02 14:31:05 <ollieparanoid[m]> ikke: \o/
2020-09-02 16:05:56 <maxice8> oops, sorry
2020-09-02 18:27:37 <mps> just to confirm, moving package from testing to community will trigger rebuild?
2020-09-02 18:27:47 <mps> no need to bump pkgrel?
2020-09-02 18:28:46 <Cogitri> Yes, but if additional changes have been done a pkgrel bump is a good idea
2020-09-02 18:28:51 <Cogitri> So users are upgraded
2020-09-02 18:30:01 <mps> no, zathura-pdf-mupdf need to be rebuilt with upgraded zathura-dev, and I wan't to move it community
2020-09-02 18:30:30 <mps> oh, yes, pkgrel bump is good idea
2020-09-02 18:30:37 <mps> Cogitri: thanks
2020-09-02 19:15:47 <maxice8> gitlab.alpinelinux.org is refusing my ssh key
2020-09-02 19:15:55 <ikke> hmm
2020-09-02 19:16:35 <maxice8> fixed :D
2020-09-02 19:16:48 <ikke> heh :P
2020-09-02 19:17:07 <ikke> pbkac?
2020-09-02 19:17:31 <maxice8> both, it refused at first so I just added another one and tried to remove the old (ended up removing the new)
2020-09-02 19:17:36 <maxice8> the new one works, idk why the old one was refused though
2020-09-02 20:00:15 <maxice8> @ncopa http://ix.io/2vZ3
2020-09-02 20:27:10 <maxice8> @ncopa http://ix.io/2vZg
2020-09-02 20:27:33 <maxice8> oh my, there are a lot of duplicates :c
2020-09-02 20:28:09 <ikke> What is the cause of that I wonder
2020-09-02 20:28:25 <maxice8> There is an issue that points to the commit
2020-09-02 20:28:39 <ikke> I saw the issue about it
2020-09-02 20:29:39 <ikke> ah, there is another one
2020-09-02 20:31:09 <maxice8> there are quite a few
2020-09-02 20:31:47 <ikke> Is that due to backporting?
2020-09-02 20:31:51 <maxice8> After i'm done writing tests for AL59 I'll go fix them
2020-09-02 20:31:54 <maxice8> no that is purely on edge
2020-09-02 20:31:57 <ikke> hmm
2020-09-02 20:31:58 <ikke> strange
2020-09-02 20:32:32 <maxice8> Don't worry, once I push the new atools version someone can go through versions and see everything wrong
2020-09-02 23:36:03 <maxice8> !12007
2020-09-03 07:55:39 <Cogitri> mps: Could you test build !11995 on armv7?
2020-09-03 07:57:50 <mps> Cogitri: sure, but in about half an hour, I'm outside right now
2020-09-03 07:59:48 <ikke> Cogitri: When I have time, I'll arange an armv7 container for you
2020-09-03 08:01:07 <mps> ikke: nice
2020-09-03 08:02:08 <mps> I read his request but didn't wanted to influence decision but I was for it
2020-09-03 08:02:43 <Cogitri> ikke: Thanks 👍
2020-09-03 08:04:51 <mps> in next weeks I'll have to devote more time to kernel because I think we will have new -lts
2020-09-03 08:05:33 <mps> and a lot new drivers and features which have to be tested
2020-09-03 08:05:46 <mps> and some new userspace tools
2020-09-03 08:35:31 <mps> why webkit build uses max cpu numbers?
2020-09-03 08:35:54 <mps> webkit2gtk
2020-09-03 08:36:07 <ikke> mps: abuild.conf on the builders defaults to $(nproc)
2020-09-03 08:36:11 <ikke> I mean JOBS
2020-09-03 08:36:26 <ikke> And same for CI
2020-09-03 08:36:56 <mps> my lxc have 8 but Cogitris MR run on 64
2020-09-03 08:37:22 <mps> maybe ninja default?
2020-09-03 08:38:25 <ikke> I can't imagine such a tool defaulting to running 64 concurrent jobs
2020-09-03 08:39:04 <mps> well, why then? I don't see overrides in APKBUILD
2020-09-03 08:43:12 <ikke> Well, it might default to nproc
2020-09-03 08:45:08 <mps> that will be bad, imo
2020-09-03 08:46:49 <ikke> samurai listens to SAMUFLAGS
2020-09-03 08:47:01 <ikke> so I think you need to add SAMUFLAGS to your abuild.conf
2020-09-03 08:47:40 <mps> heh
2020-09-03 08:48:08 <ikke> (that's the reason we switched to samurai iirc, because ninja does not support that)
2020-09-03 08:48:14 <ikke> or at least, one of the reasons
2020-09-03 08:48:19 <mps> it should be then 'SAMUFLAGS = $JOBS' or something similar
2020-09-03 08:48:32 <ikke> same as MAKEFLAGS
2020-09-03 08:48:44 <ikke> so copy the MAKEFLAGS line and replace MAKE with SAMU
2020-09-03 08:49:12 <mps> aha, good that I can guess without reading docs ;)
2020-09-03 08:49:17 <ikke> though, samu only supports -v and -j, so if you added additional optionso to Makeflags, you'd need to remove them
2020-09-03 08:49:39 <ikke> SAMUFLAGS="-j$JOBS
2020-09-03 08:49:42 <ikke> "
2020-09-03 08:50:35 <mps> anyway, it finished job successfully :)
2020-09-03 08:50:39 <mps> Cogitri: ^
2020-09-03 08:56:13 <Cogitri> Nice, thanks for testing
2020-09-03 09:53:58 <Cogitri> Yay, seems like webkit2gtk passed on armv7 now, thanks again for testing mps :)
2020-09-03 09:54:34 <ikke> nice
2020-09-03 09:59:14 <mps> Cogitri: np, pleased to help. and i adore your work and happy if I can help somewhat (though I disagree with some of your 'ideas')
2020-09-03 10:00:50 <mps> (if I agree with anyone)
2020-09-03 10:06:39 <ikke> There are lots of people here with different ideas, the trick is find an acceptable compromise somewhere
2020-09-03 10:10:34 <mps> or to destroy project (Alpine) ;P
2020-09-03 10:21:43 <ikke> openrct2 has bus errors during tests on armhf
2020-09-03 11:22:08 <mps> ncopa: you could upgrade linux-lts with changes you just pushed ;)
2020-09-03 11:22:23 <mps> 5.4.62 is just released
2020-09-03 11:24:57 <PureTryOut[m]> ikke: yeah same issue on armv7, just disable the tests like we did with armv7
2020-09-03 11:25:06 <PureTryOut[m]> I made an issue for it upstream already
2020-09-03 11:25:17 <ikke> ok
2020-09-03 12:44:59 <ncopa> mps: ugh... I checked latest kernel version before I started with it
2020-09-03 12:45:16 <ncopa> but i didnt re-check before push
2020-09-03 12:59:20 <mps> well, sometimes happens to me also
2020-09-03 14:39:20 <Ganwell> hmm, my system is more stable without dbus. I only need it because LibreOffice doesn't show menus without dbus. Are we trying to get dbus fixed?
2020-09-03 14:40:26 <ikke> Ganwell: Yes, the goal is to get dbus working again
2020-09-03 14:41:46 <Ganwell> ikke: great. is there an upstream issue, apart from the 3 year old issue from the chromium dev?
2020-09-03 14:42:19 <ikke> I don't think anyone created a collective issue for dbus yet
2020-09-03 15:02:04 <mps> Ganwell: right
2020-09-03 15:02:30 <mps> looks like upstream ignore bug
2020-09-03 15:04:09 <Ganwell> There problem is here: https://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c#n4745
2020-09-03 15:05:23 <Ganwell> I try to find out how this is usually done. I think dalias said it is an anti-pattern.
2020-09-03 15:09:58 <Ganwell> here is how python is doing it: https://github.com/python/cpython/blob/master/Modules/_posixsubprocess.c#L295
2020-09-03 15:11:30 <mps> linux 5.9 got close_range syscall iirc
2020-09-03 15:11:36 <ikke> I recall that ncopa has also written something I think of openjdk
2020-09-03 15:11:41 <ikke> s/of/for
2020-09-03 15:11:41 <alpine-meetbot> ikke meant to say: I recall that ncopa has also written something I think for openjdk
2020-09-03 15:12:28 <mps> or it is queued for 5.10, can't remember
2020-09-03 15:13:19 <Ganwell> I guess the python version could be ported. It is not nice, but they assured not do the mallocs etc.
2020-09-03 15:13:32 <ikke> f10a27abc4a038853c5b0f74655a1ca75356c93a
2020-09-03 15:13:55 <Ganwell> They call SYS_getdents64 directly
2020-09-03 15:28:03 <detha> mps: you sure xorg-server is fixed? 1.20.9-r1 on x86_64/nouveau segfaults here
2020-09-03 15:29:32 <mps> detha: it works fine on 3.12 x86_64
2020-09-03 15:29:56 <mps> not sure if it works on edge
2020-09-03 15:30:37 <mps> on edge it is tested on aarch64 and armv7
2020-09-03 15:31:55 <detha> hmm. I get 'segfault at address 0x0124', on 3.12. Going back to 1.20.8-r4 and it starts
2020-09-03 15:32:21 <mps> hmmm
2020-09-03 15:43:58 <detha> Just looked at what that last patch was, I see it has to do with pci bus scanning. Maybe noteworthy that this is a Frankenbox with built-in intel plus two nvidia 8400 cards
2020-09-03 15:48:20 <mps> aha, ok. will test on my daughter x86_64 (when she come) which have intel and nvidia cards
2020-09-03 15:48:24 <mps> notebook
2020-09-03 16:12:59 <ikke> Cogitri: ">>> ERROR: gobject-introspection: check failed"
2020-09-03 16:18:48 <Cogitri> mps,PureTryOut[m]: Can you test !12042? That might fix the FF freezes while keeping DBus enabled
2020-09-03 16:20:57 <Cogitri> `ImportError: attempted relative import with no known parent package` huh what, why is that popping up in gobject-introspection's check() now
2020-09-03 16:21:10 <ikke> yes, I saw those passing by
2020-09-03 17:09:58 <PureTryOut[m]> Cogitri: will do. Last time I compiled Firefox was when I still ran Gentoo 🤔
2020-09-03 17:12:28 <Cogitri> Thanks 👍
2020-09-03 17:12:49 <Cogitri> Heh, I compile it a bit more often than that :)
2020-09-03 18:18:24 <mps> Cogitri: I'm reading musl ML about that right now, dalias and Ariadne agree that this is not proper solution but just workaround, if I understand them correctly
2020-09-03 18:23:19 <PureTryOut[m]> Cogitri: btw libpulse will probably need the same thing
2020-09-03 18:24:36 <Cogitri> Well, if it makes Wayland not SEGFAULT and firefox not deadlock it seems ok to me to use it for now
2020-09-03 18:26:16 <Cogitri> And since the codepath is used on non-linux as well I don't think it's too bad to use it for now (it's just a bit slower AFAIU)
2020-09-03 18:26:32 <Cogitri> PureTryOut[m]: probably, but U didn't re-add that dep yet
2020-09-03 18:27:09 <mps> then I think it should be 'marked' as 'temporary workaround'
2020-09-03 18:29:25 <Cogitri> Let's see if it works first :)
2020-09-03 18:30:26 <PureTryOut[m]> U?
2020-09-03 18:31:27 <mps> sure ;)
2020-09-03 18:32:30 <mps> detha: tested xorg-server on machine with intel and nvidia, works fine but without trying to use nvidia card, if this is solution for you
2020-09-03 18:33:42 <detha> mps: thanks for testing, alas, at the moment I only have monitors on the nvidia cards, the intel not in use
2020-09-03 18:33:42 <Cogitri> PureTryOut[m]: Sorry, typo, meant I :)
2020-09-03 18:34:13 <mps> Cogitri: sorry, besides my day work I also trying to find why linux 5.8 don't work on any of my ARM32, so don't have time to test your MR. Hope PureTryOut[m] will and he use use wayland which will help more than my Xorg
2020-09-03 18:35:32 <detha> mps: anyway, pinning to 1.20.8-r4 helps for now, I'll get back to testing when things calm down a bit here
2020-09-03 18:36:20 <PureTryOut[m]> Ah
2020-09-03 18:37:15 <detha> (this being my main desktop, with 50-odd windows and ssh sessions to various things, doesn't get rebooted too often)
2020-09-03 18:38:19 <Cogitri> mps: Ah, no worries :)
2020-09-03 18:38:45 <PureTryOut[m]> mps: I don't use Wayland, never have
2020-09-03 18:39:03 <PureTryOut[m]> There is a major bug with KDE Plasma on Musl preventing me from using it sadly
2020-09-03 18:39:36 <nmeum> I also have this weird bug with xorg where it ocasionally becomes super unresponsive and I need to restart xorg manually to "fix it"
2020-09-03 18:42:32 <mps> PureTryOut[m]: ah, so I'm wrong, sorry
2020-09-03 18:43:32 <Cogitri> Well, if we enable DBus again FF Wayland should work too
2020-09-03 18:43:57 <Cogitri> So testing that it doesn't freeze would he sufficient
2020-09-03 18:44:03 <mps> Cogitri: yes if dbus is fixed
2020-09-03 19:07:05 <Cogitri> Yup
2020-09-03 19:16:19 <Cogitri> https://lwn.net/Articles/830538 oh my
2020-09-03 19:23:53 <mps> I read it two hours ago, but it doesn't look catastrophic
2020-09-03 19:24:35 <mps> 'Exploiting the bug aside from crashes is not trivial but likely possible for a dedicated attacker'
2020-09-03 19:25:08 <ikke> "The major hurdle for an attacker is that only every second byte is under their control with every first byte having a fixed value of 0x04."
2020-09-03 19:25:12 <mps> what is not possible with 'dedicated attacker'
2020-09-03 19:29:06 <ikke> not a lot
2020-09-03 20:40:40 <mps> I think I found reason why kernel 5.8.x don't boot on arm32. maybe binutils problem. continuing testing
2020-09-03 20:47:05 <mps> huh, looks solution for now is 'make mod2yesconfig'
2020-09-03 21:05:40 <dalias> mps, which thing is not a proper solution?
2020-09-03 21:07:19 <mps> kernel 5.8.x have bug which disallow modules load on arm32 and maybe some other arches
2020-09-03 21:07:24 <dalias> mps, if dbus, i think there're other mallocs beside the opendir, but getting rid of the opendir is correct
2020-09-03 21:07:43 <mps> ah, you talking about dbus
2020-09-03 21:09:32 <mps> dalias: after reading some bug reports and musl ML and some sites I come to conclusion that just fixing dbus is a workaround
2020-09-03 21:10:48 <mps> dalias: right?
2020-09-03 21:11:18 <dalias> ??
2020-09-03 21:11:29 <dalias> no, dbus is 100% wrong here
2020-09-03 21:11:33 <mps> my conclusion above
2020-09-03 21:11:50 <dalias> you cannot call non-AS-safe functions between fork and exec
2020-09-03 21:12:02 <dalias> (asuming you're library code that might be used in a MT application)
2020-09-03 21:12:08 <mps> yes, that is what I read on musl ML
2020-09-03 21:12:18 <dalias> and dbus is doing that, so dbus needs to be fixed
2020-09-03 21:13:09 <mps> and that 'need' is reported about 3 years ago, iiuc
2020-09-03 21:13:20 <dalias> yes
2020-09-03 21:14:15 <mps> but some people want dbus even with workaround
2020-09-03 21:14:29 <mps> however this is bad
2020-09-03 21:14:59 <Cogitri> ?
2020-09-03 21:15:25 <Cogitri> The patch removes the call to opendir(), so it seems muy bueno to me
2020-09-03 21:15:37 <mps> Cogitri: :)
2020-09-03 21:16:18 <mps> it will possibly work
2020-09-03 21:16:20 <Ariadne> the patch is wrong
2020-09-03 21:16:27 <Ariadne> it will leak FDs
2020-09-03 21:17:31 <Cogitri> Hm, but that code is called on non linux as well isn't it?
2020-09-03 21:17:35 <Ariadne> oh
2020-09-03 21:17:36 <Ariadne> i see
2020-09-03 21:17:39 <Ariadne> yeah, this is fine
2020-09-03 21:17:49 <Ariadne> please separate your firefox changes from the MR though
2020-09-03 21:18:01 <dalias> i suspect it just loops naively for non-linux?
2020-09-03 21:18:04 <Ariadne> yes
2020-09-03 21:18:08 <dalias> adding the poll variant would be an improvement
2020-09-03 21:18:12 <dalias> but noncritical
2020-09-03 21:18:27 <Ariadne> it will be interesting to see if this fixes kwayland
2020-09-03 21:18:33 <dalias> 1024 iterations of close takes ~5-10 ms at most
2020-09-03 21:18:47 <Cogitri> Yeah, let's just have this fixed for now, we can optimize later
2020-09-03 21:18:51 <dalias> which is bad but not very noticable
2020-09-03 21:18:51 <Cogitri> But I want working FF again :)
2020-09-03 21:19:20 <Ariadne> anyway, once you split out the dbus changes from the firefox changes, i will merge it
2020-09-03 21:19:34 <Ariadne> i don't want to merge firefox changes in a MR about dbus, even if they are related
2020-09-03 21:19:50 <Cogitri> Wanted someone to test the dbus thingie together with FF so we can make sure it actually works
2020-09-03 21:20:04 <Ariadne> well we need the dbus fix now
2020-09-03 21:20:07 <mps> 
ACTION have to build FF again for own usage

2020-09-03 21:20:29 <Ariadne> by the way, i figured out that chromium is stable when you disable seccomp
2020-09-03 21:20:55 <Ariadne> so i suspect we need to adjust some seccomp things
2020-09-03 21:25:17 <dalias> why is there no easy way to tell that crashes came from bogus seccomp filters?
2020-09-03 21:25:49 <Ariadne> seccomp is honestly pointless anyway
2020-09-03 21:25:56 <Cogitri> Dbus was broken for two weeks now, I don't think we need to rush deploying the test without testing now
2020-09-03 21:26:21 <dalias> ariadne, seccomp i pretty awesome. but i dont know if they're using it right or not
2020-09-03 21:26:55 <Ariadne> ok, let me rephrase
2020-09-03 21:27:03 <Ariadne> seccomp (as used by most projects) is honestly pointless anyway
2020-09-03 21:27:06 <dalias> with modern seccomp (SECCOMP_RET_USER_NOTIFY) you can implement UML entirely in userspace and run normal native binaries
2020-09-03 21:27:55 <Ariadne> because most seccomp bpf programs leave syscalls open that can be used to root the machine
2020-09-03 21:28:02 <dalias> if they have a static filter or a supervisor outside the supervised privilege domain, you can do really strong sandboxing with it
2020-09-03 21:28:07 <Ariadne> because the programs themselves need it
2020-09-03 21:28:27 <Ariadne> you have to actually architect your program correctly to leverage it, with a supervisor or similar :)
2020-09-03 21:28:44 <dalias> but yes if you leave escape vectors accessible or try to supervise from within the same priv domain it's useless
2020-09-03 21:29:02 <Ariadne> but 99% of seccomp use i have seen is just "lets bolt seccomp onto our program and block syscalls we don't use"
2020-09-03 21:29:17 <dalias> note that at least firefox is using it in one place to "supervise from within same priv domain" but it's not as a security boundary
2020-09-03 21:29:20 <Ariadne> and, well, that is honestly pointless
2020-09-03 21:29:28 <dalias> it's just as a way of suppressing unwanted behavior from shitty third-party libs :-P
2020-09-03 21:29:41 <Ariadne> ah yes, like widevinecdm :)
2020-09-03 21:29:50 <dalias> yes
2020-09-03 21:39:06 <Ariadne> i will just cherrypick the dbus fix
2020-09-03 21:39:29 <Ariadne> i am not in the mood to argue, but dbus is broken for more than just firefox
2020-09-03 21:46:42 <Cogitri> Sure, if you think the fix works that's fine by me
2020-09-03 21:47:12 <dalias> ariadne, is that the only malloc (and only AS-unsafe call) in the child?
2020-09-03 21:47:18 <dalias> or are there other things that could break too?
2020-09-03 21:51:26 <Ariadne> dalias: yes, it seems so.
2020-09-03 21:51:31 <Ariadne> dalias: i don't see anything else.
2020-09-03 21:52:16 <dalias> yay
2020-09-03 21:57:10 <Ariadne> i just hadn't gotten around to fixing dbus yet.  i am glad Cogitri dove into it.
2020-09-03 21:57:24 <Ariadne> past few weeks have been busy for me.
2020-09-04 00:34:37 <the6543> Hi
2020-09-04 00:34:57 <the6543> someone here who can give me a hint?
2020-09-04 00:58:25 <Ariadne> a hint regarding what
2020-09-04 01:03:14 <the6543> fixing the lint
2020-09-04 01:03:25 <the6543> but I just tryed things out - its working
2020-09-04 01:04:03 <the6543> @Ariadne but thanks for responding :)
2020-09-04 01:04:54 <the6543> do you like to se something funny (unrelated to my problem but has to do with lint)
2020-09-04 01:04:58 <the6543> <https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12060>
2020-09-04 01:05:04 <the6543> to confince lint
2020-09-04 01:05:20 <the6543> first unset LDFLAGS
2020-09-04 01:05:32 <the6543> and then LDFLAGS="$LDFLAGS ..."
2020-09-04 01:05:44 <the6543> just nonsence
2020-09-04 01:07:07 <craftyguy> is there a good example of an apkbuild for an app that includes its dependencies as git submodules?
2020-09-04 01:07:39 <craftyguy> (and how that should be handled, since I assume 'git submodule clone' or whatever in an apkbuild is a bad choice..?)
2020-09-04 01:08:21 <maxice8> See testing/pegasus-frontend
2020-09-04 01:08:32 <craftyguy> thanks!
2020-09-04 01:08:47 <maxice8> There is no way handling git submodule is good, telegram-desktop creates a -full.tar.xz that includes the proper checkouts of the git submodules they use
2020-09-04 01:09:06 <craftyguy> ah ok, that makes sense
2020-09-04 01:09:38 <craftyguy> but I like the pegasus example too
2020-09-04 01:28:28 <craftyguy> recursive submodules. fml
2020-09-04 01:50:33 <craftyguy> so I got everything in the right place. when I run 'make' from build() it fails to find some local headers. when I use abuild fetch/prepare, then manually cd into builddir and 'make', it works
2020-09-04 01:51:38 <maxice8> what are the errors ? (paste it on pastebin or another paste service)
2020-09-04 01:54:27 <craftyguy> oh, it actually fails later if I do it manually, but for the same reason
2020-09-04 01:54:31 <craftyguy> 
ACTION confused

2020-09-04 01:54:39 <craftyguy> one sec
2020-09-04 01:54:40 <maxice8> ?
2020-09-04 01:57:11 <craftyguy> (I have to move to a different system where I can copy the scroll buffer.. sigh)
2020-09-04 01:59:37 <craftyguy> alright. here's the apkbuild: https://bpa.st/5SHQ
2020-09-04 01:59:50 <craftyguy> output when just doing 'abuild' on that: https://bpa.st/CZ3Q
2020-09-04 02:01:09 <craftyguy> and here's doing abuild fetch/unpack/prepare and manually calling make from builddir: https://bpa.st/BGMA
2020-09-04 02:02:32 <craftyguy> I 'stubbed' package just to make sure it wasn't failing at that point (it isn't)
2020-09-04 02:02:52 <craftyguy> so that's obviously wrong, but I don't think it's the problem here
2020-09-04 02:14:23 <craftyguy> it builds fine if I do git submodule init --recursive, so I must be missing something
2020-09-04 02:14:47 <craftyguy> the different behavior between abuild and running 'make' manually seems weird to me though
2020-09-04 02:17:50 <craftyguy> I can't find any other dependencies that are submodules besides the 3 in that apkbuild
2020-09-04 02:24:37 <craftyguy> hmm, must be a problem with ccache or something, or ??
2020-09-04 02:24:56 <craftyguy> I can build the package successfully on a system without ccache, I don't know if it's related
2020-09-04 02:26:20 <craftyguy> nope, that's not it. wtf
2020-09-04 03:12:16 <Hello71> Cogitri: I don't understand https://lists.alpinelinux.org/~alpine/devel/%3C902cce83b8dd4155c8664cdf1ebf1ca6abd99c56.camel%40cogitri.dev%3E. it seems like less work (for everybody) and more reliable to go to https://pkgs.alpinelinux.org/contents?path=%2Fetc%2Fpam.d&branch=edge and download all the packages then extract them locally
2020-09-04 04:34:54 <Ariadne> hello71: agreed
2020-09-04 06:25:38 <ikke> morning
2020-09-04 06:29:15 <mps> ikke: good morning (goede morgen)
2020-09-04 07:00:58 <Cogitri> Hello71: That's what I ended up doing
2020-09-04 07:01:11 <Cogitri> But I still wanted to make sure I don't break people's login
2020-09-04 07:02:00 <Cogitri> And that way I can check if many people added those modules themselves
2020-09-04 08:25:48 <PureTryOut[m]> environment variables set in `/etc/conf.d/<service name>` will be used to run the program in `/etc/init.d/<service name>` right?
2020-09-04 08:29:06 <ikke> /etc/conf.d/<servicename> is sourced indeed
2020-09-04 08:31:31 <PureTryOut[m]> `/proc/<pid>/environ` doesn't seem to show the set variable though
2020-09-04 08:32:02 <PureTryOut[m]> Oh never mind I had to use the pid of supervisor-daemon
2020-09-04 08:44:12 <PureTryOut[m]> Hmm the environment variable is set on supervise-daemon, not the actual command it launches
2020-09-04 08:46:24 <ikke> Normaly they should inherrit, unless supervise-daemon is filtering them
2020-09-04 08:48:28 <PureTryOut[m]> Well, seems it's filtering then. `/proc/<pid of supervise-daemon running the process/environ` shows the variable, but `/proc/<the process>/environ` doesn't
2020-09-04 09:32:43 <Ganwell> Cogitri: do you know if the dbus patch work? I am trying to dbug the port of ncopas patch for openjdk8 and it it is difficult dbus forkes all over the place.
2020-09-04 09:33:37 <Cogitri> Well, it avoids the opendir() call so it should work
2020-09-04 09:34:47 <Cogitri> I can't reproduce the freezes on my machine (for some weird reason) so I can't really confirm it 100% tho
2020-09-04 09:36:14 <Ganwell> I can't reproduce systematically either
2020-09-04 09:37:58 <Ganwell> I want to run the function at least once
2020-09-04 09:46:45 <Ganwell> anybody know something that autolaunches dbus? firefox doesn't do it on my system
2020-09-04 09:48:21 <PureTryOut[m]> Cogitri: I can't reproduce the freezes anymore with the patch
2020-09-04 09:49:01 <Cogitri> Nice 👍
2020-09-04 10:42:12 <Ganwell> Cogitri: updated dbus patch: https://ad-sy.ch/cy
2020-09-04 10:48:56 <Cogitri> Ah, maybe dalias or Ariadne can take a look at that? I don't really do much C :)
2020-09-04 10:55:13 <Ganwell> Why did this issue disappear? https://gitlab.alpinelinux.org/alpine/aports/-/issues/11978
2020-09-04 10:56:19 <Ganwell> Sorry, never mind must be a typo by someone.
2020-09-04 10:56:38 <Cogitri> Yes, we're only at #11922
2020-09-04 11:59:39 <PureTryOut[m]> Cogitri: I see there is an abuild-meson, are we supposed to use that now rather than the usual regular meson command?
2020-09-04 12:00:28 <maxice8> yes
2020-09-04 12:01:03 <PureTryOut[m]> Interesting, ok
2020-09-04 12:01:11 <PureTryOut[m]> Guess we need the same for cmake, or is there already an abuild-cmake?
2020-09-04 12:01:31 <maxice8> it is a shellscript like in Arch Linux and sets all the --long-opts needed like --prefix --libdir --bindir --sbindir --buildtype and some internal meson opts like -Db_staticpic and -Db_pie
2020-09-04 12:02:08 <maxice8> Ideally everyone would get off CMake to meson but it would be nice, I'm not in a hurry to deal with CMake
2020-09-04 12:02:23 <maxice8> also CMake will produce lots of warnings of unused variables if we try to set stuff
2020-09-04 12:02:35 <PureTryOut[m]> That last one is true
2020-09-04 12:02:41 <PureTryOut[m]> Hmm
2020-09-04 12:18:51 <PureTryOut[m]> Cogitri: you might want !12083
2020-09-04 12:30:34 <PureTryOut[m]> Also if anybody wants too merge, !11955 is ready
2020-09-04 12:31:03 <PureTryOut[m]> So are !11953, !11952 and !11779
2020-09-04 12:51:09 <Ariadne> Ganwell: I would rather that patch go upstream.  the patch we have now is sufficiently performant
2020-09-04 12:59:19 <Hello71> 12:51 <Ariadne> Ganwell: I would rather that patch go upstream.  the patch we have now is sufficiently performant
2020-09-04 13:09:32 <Ganwell> Ariadne: Well, would it be good for the arguments that we probably get, if the patch is in use in alpine?
2020-09-04 13:11:08 <Ganwell> Ariadne: And the current patch does 1024+ sys-calls
2020-09-04 13:11:17 <Ariadne> ok?
2020-09-04 13:11:25 <Ariadne> it's still less than 10ms
2020-09-04 13:11:37 <Ariadne> like this doesn't really matter
2020-09-04 13:15:16 <Ganwell> Ariadne: My first argument is the important one, but it is 62ms if ulimit is set to 1024.
2020-09-04 13:16:25 <Ariadne> I think I'd rather implement this as closefrom(3) in musl instead of patch this in everywhere
2020-09-04 13:16:34 <Ariadne> if dalias doesn't object anyway
2020-09-04 13:18:22 <detha> Ideally, there would be a closefrom(2)
2020-09-04 13:18:43 <Ganwell> Ariadne: Ok, I am not going to upstream this, in that case. I don't have the nerve to argue this, without good evidence that it working.
2020-09-04 13:19:06 <Ganwell> Ariadne: I heard somewhere that a syscall like closefrom is coming soon.
2020-09-04 13:20:30 <Ganwell> Ariadne: http://lkml.iu.edu/hypermail/linux/kernel/2008.0/02649.html
2020-09-04 13:20:34 <Ariadne> first I've heard of it
2020-09-04 13:24:37 <Ariadne> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f30a60aa78410496e5ffe632a371c00f0d83a8d
2020-09-04 13:24:41 <Ariadne> nice
2020-09-04 13:37:51 <Ganwell> Ariadne: I started to collect core-dumps of chromium, although chromium 85 is much more stable.
2020-09-04 13:51:49 <mps> close_range is in 5.8 or 5.9 kernel
2020-09-04 13:52:53 <mps> aha, ' Merge tag 'close-range-v5.9' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux' kernel commit 4f30a60aa78410496e5ffe632a371c00f0d83a8d
2020-09-04 14:28:06 <dalias> ariadne, closefrom is objected-to because it's a fundamentally broken operation
2020-09-04 14:28:15 <dalias> you can't/shouldn't close fds that don't belong to you
2020-09-04 14:29:15 <dalias> in the case of dbus etc. they're doing it because they want to start a daemon behind the user's back (bad idea to begin with) without leaking fds (good idea) and don't want to have a contract that the calling application has to use O_CLOEXEC correctly (bad idea)
2020-09-04 14:30:03 <dalias> i'm not sure how we should proceed with linux offering a syscall for the fundamentally broken operation
2020-09-04 15:35:04 <Ganwell> dalias: at some level we must deal with it. there are a lot of bad designs out there that are not going away. If fds are created with O_CLOEXEC by default, I would say, lets just break bad applications that removed O_CLOEXEC. But it isn't default and every high-level user, who doesn't know about the whole fork/exec business is going to fall into that pitfall.
2020-09-04 15:36:23 <Ganwell> I'd say most standard-libraries of high-level languages have closefrom() in some form. (I checked 3).
2020-09-04 15:36:35 <dalias> there's a difference between dealing with it (accepting that some broken apps/libraries do it, and minimizing their brokenness when needed) and treating it as a supported API (which inherently stomps on portability)
2020-09-04 15:38:34 <dalias> programming with this model inherently breaks portability to any implementation that uses fds internally in ways that need to be preserved across child processes (e.g. using fds for binding to working directory, fs root, namespace-type stuff, etc.) which are explicitly valid implementation choices, and breaks ability to supervise process trees via intentionally letting them inherit fds
2020-09-04 15:38:57 <dalias> the latter is a really useful property that this junk breaks
2020-09-04 15:39:00 <Ganwell> dalias: people what to compose several libraries without having to know about the POSIX layer. and fork/exec pushes the need to know about POSIX up to user of high-level languages.
2020-09-04 15:39:29 <dalias> for higher-level languages they can just always use O_CLOEXEC
2020-09-04 15:39:56 <dalias> and explicitly un-mark it when setting up stdin/out/err for a child
2020-09-04 15:40:55 <dalias> but a big part of the problem too is folks wanting to treat posix as some sort of legacy they're just using rather than a core agreed-upon part of the abstraction
2020-09-04 15:41:17 <dalias> (analogous to the badness of how fdo treats x)
2020-09-04 15:49:25 <Ganwell> dalias: I checked python, they set O_CLOEXEC by default, so maybe most libraries and high-level languages already do the right thing. so what do we do about the closefrom()-paranoia? I guess we should remove any closefrom() from all alpine-linux packages and start reporting bugs?
2020-09-04 15:52:12 <dalias> for an individual package intending to use it, removing it is likely to make bugs. the problem with it is not that its use is a functional bug
2020-09-04 15:52:14 <Ganwell> we should make _dbus_close_all() a noop.
2020-09-04 15:52:33 <dalias> the problem is that it's nonportable and breaks useful usage idioms
2020-09-04 15:53:01 <dalias> these are problems that require systemic change in attitudes to fix
2020-09-04 15:54:43 <dalias> just changing it in alpine doesn't make upstreams portable, doesn't mitigate monoculture, doesn't make it so you can write supervision stuff assuming fds won't be closed behind your back and have it be portable
2020-09-04 15:55:16 <dalias> it's changing the upstream attitudes and culture around this that would be useful
2020-09-04 15:55:24 <Ganwell> so we should force the bugs and push fixes upstream, not? The musl/alpine-linux community is pushing a lot of POSIX/C problems upstream, already.
2020-09-04 15:56:03 <dalias> i don't think alpine has a lot of role in fixing this, because you can't say "this is a fix for a portability error that kept your software from running right on alpine"
2020-09-04 15:56:38 <dalias> it's a portability error that keeps your software from working on abstract/not-yet-written, future implementations
2020-09-04 15:57:23 <dalias> fds would be a great abstraction for how chroot works, namespaces/containers, etc. on a non-linux-based OS
2020-09-04 15:57:46 <dalias> and POSIX allows that, and has fought to continue to allow that when ppl requested closeall/closefrom
2020-09-04 15:58:00 <dalias> but applications de facto disallow it by rolling their own closefrom
2020-09-04 16:01:16 <Ganwell> most high-level languages have some form of "bool close_fds" in their signatures.
2020-09-04 16:01:16 <Ganwell> well, of course we don't have a lot weight, but you said we should not accept it and now you say we shouldn't try to fix it. so what should we do?
2020-09-04 16:21:24 <dalias> i'm not sure there is any action needed
2020-09-04 16:24:59 <sonder> dalias: so we leave the bad patch in dbus (causing a syscall per fd tried, ie 1024) and don't replace it with the "better" patch (causing a syscall per fd closed + plus one for poll)? And when close_range() comes we just ignore it?
2020-09-04 16:32:19 <dalias> sonder, no, i mean there's not any action needed for "getting rid of the closeall" because there's no benefit to patching it out locally when you're not the system affected by its wrongness
2020-09-04 16:33:23 <dalias> my leaning would be to just stick with the poll approach since it's plenty efficient for any real-world need and "portable" to the extent that the whole wrong closeall operation is (i.e. still not portable tot systems where closing a random fd can break things)
2020-09-04 16:34:21 <dalias> but upstream will probably adopt the close_range syscall anyway at some point, either via syscall() or conditional detection of a public function
2020-09-04 16:35:18 <dalias> i don't think there's any work alpine needs to do to change whatever upstream decises on unless upstream breaks AS-safety again
2020-09-04 16:36:00 <sonder> dalias: that seems good compromise.
2020-09-04 16:36:20 <dalias> imo the distro's role is just to fix bugs that prevent use of the software by the distro's users, not to worry about whether upstream is making good choices among choices that don't really affect it susers
2020-09-04 16:36:39 <dalias> the latter is a bottomless pit timesink
2020-09-04 16:45:41 <Ganwell> dalias: thanks for the explanations. these things are important to me, I want FOSS software be/become the best possible and I think you have a very good perspective. So I try to upstream the poll-patch [1] after all, right?
2020-09-04 16:45:41 <Ganwell> [1] https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12077
2020-09-04 16:47:12 <mps> Ganwell: +1
2020-09-04 16:49:03 <dalias> imo the poll patch makes a good pitch to upstream that "you can fix this completely, getting rid of the unsafe code rather than jut leaving it there conditional on __GLIBC__, with no appreciable performance regression"
2020-09-04 16:49:39 <dalias> otherwise you're asking them to accept eiher performance regression or more special-cases to maintain as a tradeoff for the fix
2020-09-04 16:50:13 <dalias> but if they'd already fixed it upstream, i wouldn''t consider pursuing the change to use poll as very important
2020-09-04 16:57:08 <Ganwell> thanks a lot. they haven't fixed it upstream, they have a  three-years old issue they marked as "very-difficult", I'll open a new one and propose the poll patch and won't argue much if they aren't interested.
2020-09-04 17:04:09 <dalias> :)
2020-09-04 17:04:25 <dalias> i wouldn't open a new issue, since one already exists
2020-09-04 17:04:33 <dalias> instead propose a patch/MR that solves the issue
2020-09-04 18:15:07 <nmeum> Ariadne: pushed gcc-go, thanks for taking a look
2020-09-04 18:27:04 <Ariadne> dalias: i agree that closefrom(3) is awful, but i don't think we are going to fix people doing stupid things, so at least we can hand them a high quality footgun
2020-09-04 18:27:19 <dalias> ariadne, yeah
2020-09-04 18:27:58 <Ariadne> what i want to avoid is tons of patches in alpine implementing closefrom(3) again and again
2020-09-04 18:28:14 <Ariadne> that is pretty ridiculous :)
2020-09-04 18:29:54 <nmeum> maybe add an implemenation to then bsd-compat-headers?
2020-09-04 18:30:36 <dalias> ariadne, i don't think alpine should be implementing it again and again
2020-09-04 18:30:51 <dalias> but there are going to be some number of packages that need their existing broken implementations fixed, anywya
2020-09-04 18:30:57 <Ariadne> well, i mean, we need to when we encounter broken softwares
2020-09-04 18:31:41 <Ariadne> replace opendir with closefrom(3) seems to be a pattern here :)
2020-09-04 18:31:42 <dalias> and sending instructions to upstream on how to fix it "portably" (under wrong assumption that closing unknown fds is safe) is very good
2020-09-04 18:32:06 <dalias> much better than sending a solution that depends on a particular new linux syscall
2020-09-04 18:33:38 <Ariadne> oh i meant adding a closefrom(3) that does the poll thing :)
2020-09-04 18:36:21 <clandmeter> https://youtu.be/W5n_5Idlxvo
2020-09-04 18:39:23 <nmeum> ahhhh a face to the name
2020-09-04 18:44:04 <maxice8> There is also the FOSSDEM 2017 talk
2020-09-04 18:55:27 <maxice8> How do we deal with telling users we are not affected by a CVE ?
2020-09-04 18:58:07 <maxice8> we expect them to distinguish if the CVE does not apply ?
2020-09-04 18:59:44 <nmeum> I think we need to enhance the secfixes yaml syntax for that
2020-09-04 19:00:17 <maxice8> Comments can be used but the problem is where we put it
2020-09-04 19:00:22 <nmeum> adding a secfixes entry for a cve which didn't apply to us in the first place might equally confuse users
2020-09-04 19:00:27 <maxice8> should we put it on the first version confirmed to have the CVE ?
2020-09-04 19:00:47 <nmeum> that's also confusing
2020-09-04 19:00:53 <maxice8> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12087
2020-09-04 19:01:29 <nmeum> what about something along these lines: https://tpaste.us/7KlO
2020-09-04 19:02:24 <maxice8> Can't it be on the same level as the versions ?
2020-09-04 19:04:16 <nmeum> well…the right yaml type for this would probably be a hash then e.g. { name: CVE-2020-2342, affected: False } but that would be a backwards incompatible change
2020-09-04 19:04:21 <nmeum> idk
2020-09-04 19:04:35 <maxice8> Just treat unaffected as a version
2020-09-04 19:05:09 <nmeum> hehe that would work too
2020-09-04 19:05:28 <maxice8> people looking in secdb would be able to filter
2020-09-04 19:09:15 <PureTryOut[m]> Cogitri: seems Gitlab fails to rebase, shall I do it locally so you can just merge it?
2020-09-04 19:11:56 <maxice8> https://gitlab.alpinelinux.org/alpine/infra/alpine-secdb/-/issues/2 @ncopa @nmeum
2020-09-04 19:15:24 <mps> iirc, we discussed idea of moving secfixes info from APKBUILD to some external 'store'
2020-09-04 19:15:44 <maxice8> iirc, ncopa vetoed that because they want APKBUILDs to be self-contained
2020-09-04 19:16:02 <maxice8> an understandable requirement
2020-09-04 19:16:44 <mps> all can be changed, so ncopa could change his mind one day :)
2020-09-04 19:19:00 <maxice8> @Ikke ping, about GitHub patches lint
2020-09-04 19:19:24 <maxice8> Is there an specific case you're thinking about ? I never had checksum mismatches
2020-09-04 19:22:41 <Ariadne> https://github.com/ifupdown-ng/ifupdown-ng/pull/60
2020-09-04 19:22:47 <Ariadne> can someone familiar with wireguard review this :)
2020-09-04 19:25:15 <mps> Ariadne: is it intended to be run by default
2020-09-04 19:25:28 <ikke> maxice8: I think that was about patch descriptions, ot?
2020-09-04 19:25:29 <ikke> not*
2020-09-04 19:25:53 <Ariadne> mps: no.  it is used for interfaces that request it.
2020-09-04 19:25:54 <maxice8> The issue said checksum mismatch
2020-09-04 19:25:59 <Ariadne> mps: `use wireguard` :)
2020-09-04 19:26:18 <maxice8> Maybe if one is using github.com/user/repo/pull-request/id.patch
2020-09-04 19:26:23 <ikke> maxice8: ah, that was about patches from github
2020-09-04 19:26:24 <maxice8> And the pull request is updated
2020-09-04 19:26:38 <mps> Ariadne: yes, I meant 'by default if we have wg interface'
2020-09-04 19:26:40 <ikke> We've had it several times that happened
2020-09-04 19:26:48 <maxice8> I can't test rn but it seems like a place where it would change
2020-09-04 19:27:10 <Ariadne> mps: yes, the idea is that you configure your wireguard interfaces in /e/n/i and ifupdown-ng manages them for you, like other interfaces.
2020-09-04 19:27:31 <Ariadne> so you just do `ifup wg0` if you want to bring up your vpn, and `ifdown wg0` to take it down.
2020-09-04 19:27:39 <maxice8> I guess we can warn against using patches from pull requests and merge requests, get commits instead (those can change if someone force pushes but rarely)
2020-09-04 19:27:41 <Ariadne> (and `auto` if you want it to just always be on)
2020-09-04 19:28:02 <mps> Ariadne: aha, but can it overriden with pre-up/down
2020-09-04 19:28:09 <Ariadne> yes
2020-09-04 19:28:23 <Ariadne> you also can just choose to not say `use wireguard` if you don't want it to run at all :)
2020-09-04 19:28:25 <mps> Ariadne: aha, then I think it is ok
2020-09-04 19:28:52 <mps> I don't have github account so can't comment there
2020-09-04 19:29:05 <Ariadne> as long as you don't set any wireguard-specific property, e.g. wireguard-config-path
2020-09-04 19:29:13 <Ariadne> it will not implicitly use the executor :)
2020-09-04 19:31:37 <mps> Ariadne: yes, looks fine to me. when I start using it I will know was I right ;)
2020-09-04 19:32:10 <Ariadne> i'm debating writing manpages for each included executor and its associated vocabulary
2020-09-04 19:33:49 <mps> I'm not against this idea for sure
2020-09-04 19:35:27 <mps> btw, anyone knows anything about brokenness of kernel 5.8.x with loading modules on arm32, regarding gcc and binutils
2020-09-04 19:36:19 <Hello71> I did hear something about long jumps and objtool and wireguard, but I don't think it's related
2020-09-04 19:37:07 <mps> Hello71: right, it is not related afaik
2020-09-04 19:37:56 <mps> there are some patches in linux-next but not sure is it worth to try waste time with them
2020-09-04 19:59:59 <Cogitri> PureTryOut[m]: Yeah, since the musl upgrade gitlab's rebase likes to get stuck at times :/
2020-09-04 20:00:18 <Cogitri> I cab rebase it once I get to merging it
2020-09-04 20:00:51 <PureTryOut[m]> Ok
2020-09-04 20:59:35 <PureTryOut[m]> Ok wtf is this linting https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/199914#L560
2020-09-04 21:09:55 <mps> new kid on the block https://github.com/bus1/dbus-broker
2020-09-04 21:10:49 <Cogitri> That's systemd specific iirc
2020-09-04 21:10:57 <mps> systemd will swallow dbus
2020-09-04 21:11:08 <mps> Cogitri: yes
2020-09-04 21:17:25 <Cogitri> It's just an alternative implementation
2020-09-04 21:26:35 <Cogitri> And dbus is rather integral to systemd so a tight integration makes sense
2020-09-04 21:27:09 <Cogitri> Although I'd of course wouldn't have a problem with also reaping the advantages dbus-broker has :)
2020-09-04 21:43:24 <mps> I switched to alpine because didn't want to use systemd
2020-09-04 21:44:08 <mps> not only because that but that was main reason to leave debian and search better distro
2020-09-04 21:44:13 <Cogitri> I didn't want to suggest to move to systemd, I mean it'd be nice if dbus-broker didn't need systemd (but I can understand why it does)
2020-09-04 21:44:31 <mps> I agree with this
2020-09-04 21:45:15 <mps> though I think dbus is not bright idea
2020-09-04 21:45:57 <Cogitri> We need IPC in some way at the end of the day and DBus is the standard way to do so, so it's fine in my books
2020-09-04 21:46:24 <Cogitri> It may be replaced with something else at some point but it'll probably do the same thing at the end of the day
2020-09-04 21:47:05 <mps> yes, but all processes to talk over same bus is not good idea imo
2020-09-04 21:47:28 <Cogitri> Way better than everything implementing its own custom thing
2020-09-04 21:47:59 <mps> well, kernel have netlink
2020-09-04 21:48:07 <Cogitri> And for things like signals you need a single bus
2020-09-04 21:48:21 <Cogitri> Netlink and dbus are very different things though
2020-09-04 21:48:49 <Cogitri> Since you can actually expose data structures, signals, properties and methods via DBus via a standard way
2020-09-04 21:49:26 <mps> I don't have solution and I didn't tried anything to make, so yes dbus is bearable also for me
2020-09-05 00:51:17 <Hello71> mps: first release more than 3 years ago, not really that new anymore
2020-09-05 01:38:08 <maxice8> https://pkgs.alpinelinux.org/contents?file=go&path=%2Fusr%2Fbin&name=&branch=edge&arch=x86_64
2020-09-05 01:38:12 <maxice8> gcc-go and go both own /go
2020-09-05 01:38:27 <maxice8> anyone using 'go' in makedepends will have the package fail due to file conflicts as gcc-go is already installed
2020-09-05 01:38:36 <maxice8> https://gitlab.alpinelinux.org/kaey/aports/-/jobs/200021
2020-09-05 05:49:27 <craftyguy> is there a way to limit apk update -a to only certain packages?
2020-09-05 05:50:57 <[[sroracle]]> the newer versions have an --ignore option or something
2020-09-05 05:51:09 <[[sroracle]]> you can also do "apk add -u" on individual packages i believe
2020-09-05 05:51:21 <[[sroracle]]> but that will add them to your world file of course
2020-09-05 05:54:20 <craftyguy> oh interesting, thanks. I'm running edge right now, I see --ignore there!
2020-09-05 05:57:16 <[[sroracle]]> note that you will probably cause breakage by doing partial upgrades and any breakage you cause will not be supported :)
2020-09-05 05:59:10 <craftyguy> of course
2020-09-05 06:19:11 <craftyguy> is gitlab down?
2020-09-05 06:19:26 <maxice8> seems to be up for me
2020-09-05 06:19:51 <craftyguy> ah there we go. not sure what that stutter was :/
2020-09-05 06:22:30 <craftyguy> Leo are you on IRC?
2020-09-05 06:22:35 <maxice8> Yes, I am
2020-09-05 06:22:41 <craftyguy> ah, hey :)
2020-09-05 06:23:14 <craftyguy> thanks for informing me about meson-abuild. I searched the wiki/apkbuild reference page for any meson helper things and found nothing :(
2020-09-05 06:23:44 <maxice8> It is kinda new, there isn't even a lint in apkbuild-lint for it
2020-09-05 06:23:46 <craftyguy> that's why I did what I did in that MR
2020-09-05 06:25:41 <craftyguy> hmm I'm still having trouble finding info on how to use it on the wiki. I'll grep around aports repo
2020-09-05 06:26:08 <craftyguy> ah lots of examples there
2020-09-05 06:59:11 <craftyguy> I guess I'll get the hang of this eventually
2020-09-05 09:27:28 <PureTryOut[m]> Cogitri: any chance you can re-enable PulseAudio on Firefox? It currently breaks video chats for me as I can not hear anyone and no output device is detected by the application 😢
2020-09-05 09:41:37 <nmeum> meh, slightly fucked up the gcc-go change yesterday. now gcc conflicts with go, working on a quick fix
2020-09-05 09:45:12 <Cogitri> PureTryOut[m]: I don't mind re-enabling it, but wasn't there one of those fork/malloc/exec thingies in libpulse too that caused freezes?
2020-09-05 09:45:26 <PureTryOut[m]> Yes, so it'll need that fix too
2020-09-05 09:58:53 <Cogitri> Not sure if libpulse does the same thing as dbus (use opendir() between fork() and exec())
2020-09-05 09:59:05 <Cogitri> Unfortunately we don't have gitlab issues or something for those
2020-09-05 09:59:28 <Cogitri> So I don't really know what's broken and I don't have time to dig into it right now unfortunately
2020-09-05 10:10:14 <andypost[m]> Looking for review !9848 - lower provider priority should not conflict with community?
2020-09-05 10:39:47 <nmeum> ok, gcc should no longer conflict with go
2020-09-05 10:39:50 <nmeum> hope I didn't fuckup this time ':)
2020-09-05 10:42:32 <ikke> nmeum: note that if you push more commits at the same time for the same package, you only need to bump once
2020-09-05 10:43:57 <nmeum> right
2020-09-05 10:45:00 <maxice8> Should be possible to build go packages on mips64 via gcc-go ?
2020-09-05 10:46:29 <nmeum> maybe
2020-09-05 10:46:39 <nmeum> I am primarly interested in gcc-go for bootstraping community/go
2020-09-05 11:12:30 <maxice8> I see
2020-09-05 13:18:19 <Hello71> PureTryOut[m]: strange, webrtc alsa works fine for me on many machines (glibc, but still)
2020-09-05 13:18:57 <PureTryOut[m]> Don't know what to tell you 🤷‍♂️
2020-09-05 13:56:06 <markand> wasn't there a policy regarding upgrades in releases?
2020-09-05 13:56:22 <markand> like, having only bugfixes or minor releases upgrades in packages
2020-09-05 13:57:13 <markand> I'm a bit surprised to see that an apk upgrade on my 3.11 did upgrade mercurial from 5.2.1 to 5.3.2
2020-09-05 14:07:50 <Cogitri> 5.2 to 5.3 is a minor upgrade thought
2020-09-05 14:08:03 <Cogitri> s/ht/h/
2020-09-05 14:08:03 <alpine-meetbot> Cogitri meant to say: 5.2 to 5.3 is a minor upgrade though
2020-09-05 14:08:30 <Cogitri> The version format is MAJOR.MINOR.PATCH
2020-09-05 14:13:45 <markand> Cogitri, it isn't
2020-09-05 14:13:54 <markand> every software have their own versioning
2020-09-05 14:14:07 <markand> SDL is even worse, they add more features in x.y.??? versions
2020-09-05 14:16:12 <Cogitri> You can add features in minor semver releases
2020-09-05 14:16:19 <markand> and in regards to Mercurial, we don't provide internal API compat between minor versions so it may cause problems with other software relying on it (redmine used to have that problems)
2020-09-05 14:16:25 <Cogitri> You just can't remove them or break API/behaviour
2020-09-05 14:16:31 <markand> not every software follow semantic versioning
2020-09-05 14:16:49 <markand> only in theoryland
2020-09-05 14:16:51 <Cogitri> I suppose Mercurial doesn't use semver then but the person upgrading it thought it did
2020-09-05 14:17:51 <Cogitri> Then that upgrade shouldn't have landed on stable then, I suppose
2020-09-05 14:25:57 <Cogitri> afontain_: Could you maybe look into GNOME Games 3.37.x? We need it for another bump (tracker 2.x -> 3.x), so it'd be nice if we could upgrade it soon
2020-09-05 15:48:02 <mps> hmm Wifi Display https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/ChangeLog
2020-09-05 15:48:29 <mps> do we need this feature?
2020-09-05 15:51:39 <PureTryOut[m]> Could anyone merge !11955 and !12096 and keep the builders busy for a while? 😛
2020-09-05 16:13:12 <mps> mhm, now we can send A/V to Wifi display with gstreamer iiuc this new iwd feature over wifi
2020-09-05 16:13:45 <mps> interesting, though I don't think I have such display
2020-09-05 17:56:07 <andypost> Filed #11925 looks glide affects xfce a lot
2020-09-05 18:02:41 <Cogitri> Ah, should be possible to build without libglade tho
2020-09-05 18:09:30 <craftyguy> for some reason I don't understand, I'm getting this when using xvfb-run to run tests for an app in an MR I submitted: Gtk-WARNING **: 11:08:03.950: cannot open display: :99
2020-09-05 18:09:44 <craftyguy> but I can do something like this just fine: xvfb-run xclock
2020-09-05 18:10:12 <craftyguy> are there some quirks with using xvfb-run in abuild that I should become familiar with?
2020-09-05 18:10:33 <Cogitri> Nop, that should just work
2020-09-05 18:10:49 <craftyguy> hmm, then I have no clue what's going on :/
2020-09-05 18:12:49 <mps> !12040 MR is to heave for my browser
2020-09-05 18:13:15 <PureTryOut[m]> 276 packages touched 😱
2020-09-05 18:14:39 <craftyguy> here's the output running meson test with xvfb-run. it's pretty light on details: https://bpa.st/RZXA
2020-09-05 18:15:14 <craftyguy> also tried starting xvfb manually and setting DISPLAY, still didn't work :/
2020-09-05 18:21:39 <craftyguy> ah, the problem was GDK_BACKEND was set in the environment to 'wayland'
2020-09-05 18:31:08 <andypost> Cogitri, it works in CI !12122
2020-09-05 18:32:51 <Cogitri> Maybe we want to try !12123 first
2020-09-05 18:36:59 <andypost> Cogitri, I think it needs pkgrel bump too
2020-09-05 18:40:02 <Cogitri> I don't think so, I enabled arches and glade will be built on those now
2020-09-05 18:40:59 <Cogitri> And nothing changed on other arches
2020-09-05 19:02:20 <craftyguy> is it ok to !check if the tests for an app seem to be broken in the same way on other distros? I don't know enough to be able to fix them, but I filed an upstream bug about it, and will reference the bug in a comment in the apkbuild..
2020-09-05 19:58:33 <PureTryOut[m]> What's everyones opinion on https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11779#note_110325?
2020-09-05 20:03:44 <ikke> What is there to have an opinion on?
2020-09-05 20:59:08 <PureTryOut[m]> Well, I guess I'm not sure if my comment/explanation is acceptable
2020-09-05 22:19:58 <Cogitri> clandmeter: Can you please take a look at !10653 ?
2020-09-06 04:44:14 <clandmeter> Cogitri: done thx.
2020-09-06 11:20:47 <PureTryOut[m]> Huh, does iwd segfault on boot for anyone else? I can restart the service and it'll work fine, but on first boot it always segfaults
2020-09-06 11:20:53 <PureTryOut[m]> (since today, on edge)
2020-09-06 11:21:16 <ikke> iwd was just upgraded I gather
2020-09-06 11:21:31 <PureTryOut[m]> Yes 19 hours ago by mps it seems
2020-09-06 11:21:35 <PureTryOut[m]> mps:  can you reproduce segfaults?
2020-09-06 11:22:27 <mps> ikke: works fine on my aarc64
2020-09-06 11:22:42 <mps> sorry, PureTryOut[m]
2020-09-06 11:22:58 <ikke> PureTryOut[m]: what arch do you use?
2020-09-06 11:23:03 <PureTryOut[m]> x86_64
2020-09-06 11:23:32 <mps> ok, I will try to build it on x86_64 and see
2020-09-06 11:42:20 <mps> PureTryOut[m]: just tested on x86_64 (3.12) and it works
2020-09-06 11:44:20 <PureTryOut[m]> On boot? I can start the process later fine, it only happens on boot
2020-09-06 11:44:48 <mps> aha, let me add it to default runlevel
2020-09-06 11:45:25 <mps> do you use alpine kernel or else?
2020-09-06 11:46:45 <mps> it works fine also on boot
2020-09-06 11:53:51 <PureTryOut[m]> Ok, wtf?
2020-09-06 11:54:17 <PureTryOut[m]> `[   18.501801] iwd[3107]: segfault at 0 ip 0000562f0982bd64 sp 00007ffcd33bde80 error 4 in iwd[562f09811000+7d000]`
2020-09-06 12:00:50 <mps> uname -a
2020-09-06 12:02:52 <mps> very strange it faults on boot but works later
2020-09-06 12:05:20 <ikke> maybe some implicit dependency that's not yet present?
2020-09-06 12:08:34 <ikke> Perhaps you can add rc_ulimit='-c unlimited' to iwd to make it dump a corefile?
2020-09-06 12:42:49 <PureTryOut[m]> ikke: to the init file?
2020-09-06 13:01:32 <ikke> to the confd file
2020-09-06 13:05:39 <PureTryOut[m]> mps: `Linux spaceblade 5.4.62-0-lts #1-Alpine SMP Thu, 03 Sep 2020 14:42:54 UTC x86_64 GNU/Linux`
2020-09-06 13:05:56 <PureTryOut[m]> Rebooting now with rc_ulimit set
2020-09-06 13:06:50 <PureTryOut[m]> And of course now it doesn't segfault on boot 😒
2020-09-06 13:07:05 <PureTryOut[m]> It happened the two times before this but not when I start debugging, damn it
2020-09-06 13:08:57 <mps> :)
2020-09-06 13:10:36 <mps> now we understand why RNG is important in computers :D
2020-09-06 13:12:08 <ikke> To create heisenbugs?
2020-09-06 13:12:23 <mps> yes
2020-09-06 13:14:24 <PureTryOut[m]> There we go, segfault again. Where would it have dumped a corefile?
2020-09-06 13:15:32 <ikke> in PWD :P
2020-09-06 13:16:10 <ikke> You should look for a file called core
2020-09-06 13:16:31 <PureTryOut[m]> $PWD? Where would that be for iwd lol
2020-09-06 13:17:00 <mps> hmm, /
2020-09-06 13:17:20 <mps> or /root
2020-09-06 13:17:41 <PureTryOut[m]> Ah, in `/` indeed
2020-09-06 13:17:47 <PureTryOut[m]> It's empty though 😕
2020-09-06 13:18:13 <PureTryOut[m]> Oh derp nvm, need root permissions ofc
2020-09-06 13:18:32 <PureTryOut[m]> Should I upload it here?
2020-09-06 13:20:27 <ikke> I guess so
2020-09-06 13:20:35 <ikke> We need a debug build for iwd
2020-09-06 13:22:51 <PureTryOut[m]> 
ACTION posted a file: core (576KiB) < https://matrix.org/_matrix/media/r0/download/fam-ribbers.com/NuXdKVLAfOrxZkethmLsHJJs >

2020-09-06 13:22:57 <PureTryOut[m]> The core file ☝️
2020-09-06 13:23:26 <Cogitri> I don't think that helps without a debug build
2020-09-06 13:23:41 <ikke> Building it now locally
2020-09-06 13:23:52 <Cogitri> Add a -dbg subpkg, rebuild and upgrade and then send the corefile to directly send the backtrace
2020-09-06 13:23:56 <mps> Cogitri: maybe could give a hint
2020-09-06 13:24:07 <Cogitri> I think building a -dbg package after the fact won't get a good backtrace
2020-09-06 13:24:47 <ikke> Why is that?
2020-09-06 13:25:06 <mps> iirc '--enable-debug' is also needed
2020-09-06 13:25:22 <ikke> Because of optimization?
2020-09-06 13:26:01 <Cogitri> I think because with -g the compiler can avoid some optimizations, yes
2020-09-06 13:26:29 <Cogitri> But not quite sure, I just noticed that I have to rebuild with -dbg upgrade and then get a new coredump because gdb only prints ??
2020-09-06 13:26:58 <Cogitri> mps: --enable-debug probably only adds -g to CFLAGS too (and maybe unsets D_NDEBUG
2020-09-06 13:27:04 <Hello71> -g doesn't affect the optimizations, that's -Og
2020-09-06 13:30:57 <ikke> I have the debug symbols installed, but gdb doesn't find them for some reason
2020-09-06 13:31:22 <ikke> (No debugging symbols found in /usr/libexec/iwd)
2020-09-06 13:32:26 <ikke> /usr/lib/debug/usr/libexec/iwd.debug exists
2020-09-06 13:33:38 <ikke> This is what I have so far: https://tpaste.us/PMkx
2020-09-06 13:33:43 <ikke> (i've manually set the symbol file
2020-09-06 13:33:46 <ikke> )
2020-09-06 13:42:39 <Hello71> that backtrace is not right, you can't call 0x0000000000000023
2020-09-06 13:47:29 <ikke> hmm
2020-09-06 13:49:23 <Hello71> pretty sure you can't compile debug symbols separately, the offsets will be all wrong
2020-09-06 13:49:33 <mps> with -dbg subpkg and '--enable-debug' works here
2020-09-06 13:50:22 <mps> Reading symbols from /usr/libexec/iwd...
2020-09-06 13:50:41 <mps> Reading symbols from /usr/lib/debug//usr/libexec/iwd.debug...
2020-09-06 13:51:19 <mps> but I can't get it segfaulting
2020-09-06 13:52:45 <Hello71> my guess is a race to set the device up, or rename the device
2020-09-06 13:54:34 <Hello71> PureTryOut[m]: probably work around with usedefaultdevice=true
2020-09-06 13:54:55 <Hello71> usedefaultinterface
2020-09-06 13:55:58 <PureTryOut[m]> In `/etc/iwd.conf`?
2020-09-06 13:56:11 <PureTryOut[m]> Sorry, `/etc/iwd/main.con`?
2020-09-06 13:56:14 <PureTryOut[m]> *conf
2020-09-06 14:14:13 <mps> it shouldn't crash even conf file doesn't exist
2020-09-06 17:35:05 <Ariadne> [05:54] <b30e0ePureTryOut[m]> `[   18.501801] iwd[3107]: segfault at 0 ip 0000562f0982bd64 sp 00007ffcd33bde80 error 4 in iwd[562f09811000+7d000]`
2020-09-06 17:35:10 <Ariadne> use addr2line
2020-09-06 17:40:58 <Hello71> don't you need symbols
2020-09-06 17:41:32 <dalias> ariadne, note that the addresses the kernel prints are bogus
2020-09-06 17:41:56 <dalias> i forget the details but they're such that you can't determine which load map they're in
2020-09-06 17:42:02 <Ariadne> hmm shit you're right
2020-09-06 17:42:08 <Hello71> doesn't it tell you 562f09811000+7d000
2020-09-06 17:42:20 <dalias> hello71, that's wrong tho :)
2020-09-06 17:42:26 <Ariadne> yes but it's wrong
2020-09-06 17:42:29 <dalias> you can often guess what it was supposed to be
2020-09-06 17:42:37 <Hello71> right
2020-09-06 17:42:51 <dalias> the problem is that they mixed up something about map addresses vs file offsets
2020-09-06 17:42:57 <dalias> in a way that's non-invertible
2020-09-06 17:44:04 <Hello71> but gdb can surely figure it out with a core dump. as long as you have symbols. which was the issue here
2020-09-06 17:44:16 <Hello71> and I don't see how addr2line can figure it out without symbols either
2020-09-06 17:44:25 <dalias> right
2020-09-06 17:44:35 <dalias> the problem is that it's supposed to help when you don't have core dumps
2020-09-06 17:44:39 <dalias> but it doesn't
2020-09-06 17:44:56 <dalias> at least not without a lot of extra work figuring out what the address was supposed to be
2020-09-06 17:45:33 <Hello71> probably, I never bothered using that info anyways (except the filename)
2020-09-06 18:37:38 <Cogitri> https://tpaste.us/6VZl  Hm, seems like Electron doesn't like our small stack-size :/
2020-09-06 18:43:43 <mps> ;p
2020-09-06 18:59:49 <andypost[m]> any idea why build-edge-ppc64le vala's log is missing?
2020-09-06 19:03:03 <Cogitri> Does ppc64le ever upload logs?
2020-09-06 19:03:17 <ikke> it does afaik
2020-09-06 19:03:22 <Cogitri> 
ACTION lost track which builders upload logs

2020-09-06 19:04:00 <ikke> all of them should
2020-09-06 19:04:45 <ikke> andypost[m]: https://tpaste.us/V4P1
2020-09-06 19:05:03 <Cogitri> Oh, do they? Somehow I think I often ran into 404's when trying to view logs but maybe that was in-progress builds and not failed ones
2020-09-06 19:05:27 <Cogitri> ikke: that's an old log I think
2020-09-06 19:05:36 <Cogitri> We have 0.48.10 in the repos now, not 0.48.9
2020-09-06 19:06:00 <ikke> https://tpaste.us/mEQJ
2020-09-06 19:07:02 <Cogitri> Thanks 👍
2020-09-06 19:07:39 <ikke> 
ACTION accuses lexicographical sorting

2020-09-06 19:10:17 <Cogitri> Heh, that gets me every time too, at $WORK the versions of our dependencies are sorted that way too  so I often think we missed some upgrade when we didn't :)
2020-09-06 20:53:46 <Ariadne> [12:37:38] <Cogitri> https://tpaste.us/6VZl  Hm, seems like Electron doesn't like our small stack-size :/
2020-09-06 20:53:48 <Ariadne> it's electron
2020-09-06 20:53:51 <Ariadne> does this really surprise you
2020-09-06 20:59:15 <Cogitri> Not really, but I was kind of hopeful that I could maybe run VSCode without flatpak when the build went through
2020-09-07 01:32:19 <sodface> Hello, what hardware does Alpine use for building armhf packages?
2020-09-07 02:55:32 <maxice8> unit/test-dhcp6 from ell fails on s390x
2020-09-07 05:05:45 <maxice8> algitbot: retry master
2020-09-07 05:08:51 <ikke> maxice8: mps is aware of it
2020-09-07 05:40:08 <maxice8> oh
2020-09-07 05:42:57 <mps> meh, I was aware yesterday but I forgot at the night
2020-09-07 05:43:06 <maxice8> I disabled on s390x for now
2020-09-07 05:43:38 <mps> not sure actually should I disable check on all arches or only on these two where it fails
2020-09-07 05:45:04 <mps> maxice8: ok. and I'm not sure is it needed on s390x ar all
2020-09-07 05:46:41 <craftyguy> what's the story behind s390x support in Alpine? are there folks that still have those big IBM systems running?
2020-09-07 08:26:56 <nmeum> is it just me or is mosh broken since the latest update?
2020-09-07 08:27:02 <nmeum> > TERM environment variable not set.
2020-09-07 08:27:19 <nmeum> > Died at /usr/bin/mosh line 311.
2020-09-07 08:29:09 <nmeum> (yes, I set TERM)
2020-09-07 08:31:40 <nmeum> seems to be a problem with the ncurses 6.2_p20200906 setupterm function
2020-09-07 09:15:07 <mps> nmeum: I canfirm
2020-09-07 09:15:17 <mps> confirm*
2020-09-07 09:17:14 <nmeum> here is the diff for the affected function https://tpaste.us/LYpp I think the problem is that it has to be if (CHECK_TERM_ENV(tname, NO_TERMINAL)) instead of if (!CHECK_TERM_ENV(tname, NO_TERMINAL))
2020-09-07 09:19:06 <ikke> seems like a fairly obvious mistake..
2020-09-07 09:19:45 <nmeum> currently at work and don't have the time to very this assumption atm
2020-09-07 09:19:59 <ikke> Same for me
2020-09-07 09:20:37 <nmeum> if someone has the time to build ncurses with debug-symbols: run `gdb --args mosh-client -c`, set a breakpoint in setupterm and check if that's the case otherwise I will do that later today ':)
2020-09-07 09:21:31 <mps> maybe I will find little time
2020-09-07 09:22:15 <mps> though I trying to fix armv7 linux-edge
2020-09-07 09:22:25 <nmeum> they should have just called the macro VALID_TERM_ENV or something to make the boolean return value of it more obvious
2020-09-07 09:23:16 <obarun> i think your newapkbuild.in program need a typo fix at usage() function:
2020-09-07 09:23:17 <obarun> -r  Crate rust package (Assume Cargo.toml is there)
2020-09-07 09:23:17 <obarun> -r  Create rust package (Assume Cargo.toml is there)
2020-09-07 09:23:17 <obarun> should be:
2020-09-07 09:23:51 <ikke> obarun: If you want, you could create a MR to fix it
2020-09-07 09:25:42 <mps> is anyone of you subscribed to ncurses ML? if not I can post bug report (I'm subscribed)
2020-09-07 09:26:51 <obarun> i let you make the fix :)
2020-09-07 09:27:20 <nmeum> took a quick work break https://tpaste.us/lYxa
2020-09-07 09:27:29 <nmeum> looks like i was right about this
2020-09-07 09:30:12 <mps> hmm, this could be mosh bug
2020-09-07 09:30:34 <nmeum> nope
2020-09-07 09:30:40 <nmeum> why should it be?
2020-09-07 09:30:52 <mps> ssh works fine
2020-09-07 09:31:27 <nmeum> ssh doesn't call setupterm i suppose
2020-09-07 09:31:37 <nmeum> or it calls it with different parameters
2020-09-07 09:31:44 <nmeum> e.g. with tname supplied so ncurses doesn't read the envirnoment variable
2020-09-07 09:34:37 <nmeum> !12169
2020-09-07 09:34:59 <mps> nmeum: yes, top also fails
2020-09-07 09:35:10 <nmeum> I will send my patch upstream
2020-09-07 09:35:39 <mps> why WIP in MR
2020-09-07 09:36:13 <nmeum> wanted to send it upstream first :p
2020-09-07 09:36:49 <mps> huh, and I have to build ncurses locally then
2020-09-07 09:36:57 <mps> from your MR
2020-09-07 09:37:18 <mps> and all users who upgraded it this morning
2020-09-07 09:37:29 <nmeum> if you are certain that the patch is correct just merge it :p
2020-09-07 09:37:43 <mps> ok, will test
2020-09-07 09:42:31 <nmeum> I just send the patch to Adranbug-ncurses@gnu.org let's see what they say
2020-09-07 09:42:39 <nmeum> *bug-ncurses@
2020-09-07 09:44:30 <mps> not yet arrived to my inbox
2020-09-07 09:55:24 <Cogitri> ```
2020-09-07 09:55:24 <Cogitri> <W> fish: Could not set up terminal.
2020-09-07 09:55:24 <Cogitri> <W> fish: TERM environment variable set to 'xterm-256color'.
2020-09-07 09:55:24 <Cogitri> <W> fish: Using fallback terminal type 'ansi'.
2020-09-07 09:55:24 <Cogitri> <W> fish: Check that this terminal type is supported on this system.
2020-09-07 09:55:25 <Cogitri> ```
2020-09-07 09:55:25 <Cogitri> Seems like fish is also bugged after the ncurses upgrade :)
2020-09-07 09:56:24 <ikke> Cogitri: well, if this is a bug in ncurses, everything that uses that function (without supplying tname) is affected
2020-09-07 09:58:36 <Cogitri> Yup, but then it's really not on moss
2020-09-07 10:00:04 <mps> Cogitri: no, some other programs also fail
2020-09-07 10:00:47 <mps> https://github.com/ThomasDickey/ncurses-snapshots/commit/96601e8bdc3b09fd5c8e87d5a1695cd9678fab44
2020-09-07 10:01:43 <mps> if you search for 'if (!CHECK_TERM_ENV(tname, NO_TERMINAL)) {'
2020-09-07 10:10:46 <PureTryOut[m]> Could anyone merge !12166 by any chance?
2020-09-07 10:13:09 <PureTryOut[m]> (I'm kinda waiting for it 😅)
2020-09-07 10:15:49 <ikke> in 5 mns
2020-09-07 10:22:08 <maxice8> mps re: s390x ell, it would be nice to have but not important
2020-09-07 10:26:16 <mps> maxice8: ok, will disable dhcp6 check
2020-09-07 10:26:40 <mps> what is kernel version on s390x builder?
2020-09-07 10:27:01 <ikke> mps: isn't that just hiding bugs?
2020-09-07 10:27:24 <ikke> unless you verified something in the test is broken
2020-09-07 10:28:45 <mps> ikke: I don't know anything about s390x working, i.e. what it can support in userspace
2020-09-07 10:29:39 <mps> and as I told you on infra I presume it is related to kernel version
2020-09-07 10:29:57 <nmeum> everything calling setupterm is bugged after the ncurses upgrade
2020-09-07 10:30:54 <nmeum> Cogitri: does fish crash afterwards? what if fish is the login shell?
2020-09-07 10:30:55 <mps> ikke: that could be because old kernel doesn't support pkcs8 (though strange it failed dhcp6 test)
2020-09-07 10:31:01 <PureTryOut[m]> Thanks ikke!
2020-09-07 10:31:08 <ikke> :)
2020-09-07 10:31:23 <PureTryOut[m]> Oh that explains why fish complains
2020-09-07 10:31:30 <PureTryOut[m]> It doesn't crash btw, just complains at startup
2020-09-07 10:31:45 <nmeum> https://lists.gnu.org/archive/html/bug-ncurses/2020-09/msg00007.html
2020-09-07 10:31:50 <PureTryOut[m]> And falls back to a different terminal type
2020-09-07 10:31:53 <nmeum> patch arrived upstream
2020-09-07 10:34:59 <nmeum> idk if we want to wait until upstream confirm this
2020-09-07 10:35:33 <ikke> depends on how fast upstream usually is
2020-09-07 10:36:46 <ikke> The bug seems rather obvious to me, and the fix trivial
2020-09-07 10:36:56 <mps> new releases are usually on sunday morning (CET)
2020-09-07 10:37:16 <mps> every sunday*
2020-09-07 10:38:21 <nmeum> the bug seems so obvious to me that I am suprised that they didn't notice it during testing
2020-09-07 10:40:36 <ikke> nmeum: nod
2020-09-07 10:53:50 <mps> ok, found why armv7 linux-edge 5.8.x don't boot. can't be compiled in thumb mode anymore because workaround for old and buggy binutils
2020-09-07 10:54:45 <mps> but to surprise it can't even work when built with binutils 2.35
2020-09-07 10:55:00 <mps> huh
2020-09-07 12:13:27 <PureTryOut[m]> Is there a way to tell a `setup.py` to install extras (what `pip install packagename[extraname]` does normally)? Or does it automatically go for extras?
2020-09-07 13:21:53 <nmeum> re ncurses: https://lists.gnu.org/archive/html/bug-ncurses/2020-09/msg00008.html
2020-09-07 13:22:17 <nmeum> can someone merge !12169 then? (:
2020-09-07 13:22:50 <mps> heh "I thought I'd repaired this..."
2020-09-07 13:24:45 <mps> nmeum: Fast-forward merge is not possible
2020-09-07 13:25:10 <mps> did you checked box to allow merging
2020-09-07 13:27:07 <nmeum> mps: try again
2020-09-07 13:28:36 <mps> merged ;)
2020-09-07 13:36:05 <Hello71> obarun: better to make MR, otherwise maintainers will forget. also then we can do proper attribution
2020-09-07 13:37:14 <nmeum> mps: ty
2020-09-07 13:39:14 <mps> nmeum: np
2020-09-07 14:02:27 <ikke> aha, so the ncurses bug was thought to be fixed, but did end up in a release
2020-09-07 14:02:30 <ikke> (https://lists.gnu.org/archive/html/bug-ncurses/2020-09/msg00008.html)
2020-09-07 14:02:35 <ikke> "I thought I repaired this"
2020-09-07 14:02:56 <PureTryOut[m]> Ariadne: a KDE dev found the dbus with kwin issue preventing hotkeys from working on Wayland sessions 🎉
2020-09-07 14:03:03 <PureTryOut[m]> !12176 is a temporary workaround
2020-09-07 14:41:13 <Cogitri> _afontain: !12181
2020-09-07 14:41:38 <Cogitri> Also bumps GNOME Games, maybe you want to take a look at that, I only tested it with Steam
2020-09-07 17:09:27 <mps> ncopa: ping
2020-09-07 17:11:32 <mps> hm, do we upgrade pkgs in stable main which have a 'solid' number of bug fixes? https://www.haproxy.org/download/2.1/src/CHANGELOG
2020-09-07 17:12:05 <mps> we have 2.1.4 in 3.12 and current upstream is 2.1.8
2020-09-07 17:12:26 <ikke> mps: I would say so, yes
2020-09-07 17:12:42 <ikke> the latest stable releases is explicitly marked as receiving bug fixes
2020-09-07 17:12:59 <ikke> I don't think it's required that someone reports a bug before we fix it
2020-09-07 17:14:00 <mps> there are some parameters change, not much though
2020-09-07 17:14:03 <Ariadne> PureTryOut[m]: ❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️
2020-09-07 17:14:33 <ikke> :)
2020-09-07 17:16:18 <Ariadne> PureTryOut[m]: what a weird bug
2020-09-07 17:17:01 <Hello71> wait, CAP_SYS_NICE?
2020-09-07 17:17:36 <PureTryOut[m]> Yup
2020-09-07 17:28:57 <Ariadne> thanks ikke for merging it btw
2020-09-07 17:29:15 <ikke> yw
2020-09-07 17:45:40 <PureTryOut[m]> Now other Wayland bugs come to light 🎉
2020-09-07 18:24:51 <Ariadne> looks like kmail is working happily again after the dbus fix too
2020-09-07 19:11:36 <Cogitri> BTW, I think there were some talks for having automated commits via gitlab CI for some DNS related package, did that go anywhere?
2020-09-07 19:11:50 <Cogitri> Would be nice if we had a CI pipeline to bump alpinelinux-appstream-data daily
2020-09-07 19:12:19 <Cogitri> Since users can only install newly introduced software via GNOME Software after that package got updated
2020-09-07 19:14:20 <mps> 
ACTION wonder why we make packages nowadays when we have things like appstream

2020-09-07 19:15:28 <Cogitri> I think you're mixing things up? AppStream is just app metadata so users can have icons, descriptions that are longer than 80 characters and screenshots etc. in software centres
2020-09-07 19:15:51 <Cogitri> If anything AppStream is good for us because that way GNOME Software doesn't integrate with only flatpak :)
2020-09-07 19:16:13 <mps> yes, you are right
2020-09-07 19:16:27 <mps> I mean to say flatpack
2020-09-07 19:17:25 <ikke> There was this discussion on HN about packaging, based on an articel about snap
2020-09-07 19:17:26 <mps> and no, I'm not against your work on these things. just wonders about them
2020-09-07 19:18:25 <mps> ikke: HN?
2020-09-07 19:18:30 <ikke> Hackernews
2020-09-07 19:18:38 <mps> ah, thanks
2020-09-07 19:19:01 <ikke> https://news.ycombinator.com/item?id=24383276
2020-09-07 19:19:33 <mps> I stopped to read similar 'things'
2020-09-07 19:30:06 <ikke> I do wonder how we can remain relevant as a distro
2020-09-07 19:31:02 <Cogitri> Same, more and more stuff will move to distro-independent package formats
2020-09-07 19:31:22 <mps> also I wonder
2020-09-07 19:31:40 <Cogitri> TBH, if I can understand that upstreams prefer that, no need to wrestle some weird bureaucratics distros empose
2020-09-07 19:31:49 <ikke> Ariadne: was that about the dns root hints?
2020-09-07 19:32:06 <Ariadne> huh ?
2020-09-07 19:32:13 <Ariadne> oh
2020-09-07 19:32:13 <Ariadne> no
2020-09-07 19:32:15 <Ariadne> kwin :)
2020-09-07 19:32:23 <ikke> oh, sorry
2020-09-07 19:32:31 <ikke> it was Cogitri that mentioned what I was referring to :P
2020-09-07 19:32:40 <ikke> Cogitri: was that about dns root hints?
2020-09-07 19:32:48 <Cogitri> Ah yes, I think that was it
2020-09-07 19:34:04 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11324
2020-09-07 19:34:07 <Cogitri> But not really invested in that, was mainly curious if I could utilize already done work in that area for alpinelinux-appstream-data :D
2020-09-07 19:34:08 <ikke> I guess this issue
2020-09-07 19:37:24 <ikke> Hmm, that does not mention anything about automatic comitting
2020-09-07 19:38:20 <Cogitri> Hm, I think I read something about plans to make a CI pipeline for it somewhere
2020-09-07 19:38:26 <Cogitri> But maybe that was just wishful thinking
2020-09-07 19:42:10 <mps> what that means? merge without review?
2020-09-07 19:46:17 <Cogitri> Yes, it'd mean that it'd bump the version without review (it'd effectively just change 20200906 to 20200907)
2020-09-07 19:46:23 <Cogitri> But I'd be fine with making a MR for it too
2020-09-07 19:46:51 <Cogitri> But it's a bit suboptimal when I only get around to bumping it every other week and users have to wait until then to install new software
2020-09-07 19:48:44 <ikke> There should be a better way then to push daily updates to a package to make sure users get the latest content..
2020-09-07 19:49:38 <Cogitri> Hm, fetching the appstream data on startup would probably be too slow
2020-09-07 19:49:55 <Cogitri> Since you need all appstream data available in order to make searches
2020-09-07 19:51:47 <ikke> It means users need to run apk ugprade before they get the latest data..
2020-09-07 19:52:31 <Cogitri> Yup (although GNOME Software can do auto-updates)
2020-09-07 19:52:45 <Cogitri> But I'm not sure if the alternatives are better
2020-09-07 19:52:50 <Cogitri> I think it's either
2020-09-07 19:52:57 <Cogitri> 1) Keep status quo
2020-09-07 19:53:27 <Cogitri> 2) Download the data from some server during startup -> probably slow
2020-09-07 19:53:57 <ikke> How do other distros do it?
2020-09-07 19:53:57 <Cogitri> 3) Query data on-demand from some upstream server -> would need a newly developed GNOME Software plugin and would probably not be adopted upstream
2020-09-07 19:54:03 <Cogitri> The same way as we do
2020-09-07 19:54:17 <Cogitri> https://www.archlinux.org/packages/extra/any/archlinux-appstream-data/
2020-09-07 19:54:47 <ikke> Seems to be updated once per month
2020-09-07 19:55:04 <ikke> not daily / weekly
2020-09-07 19:55:52 <Cogitri> Yup, so users can't install newly added software for that period of time (unless they have some fallback thingie in the pacman plugin for GNOME Software?)
2020-09-07 19:56:24 <ikke> seems to me like a cumbersom system..
2020-09-07 19:58:11 <Cogitri> Yup, but I guess it was designed in a way to not require an upstream server so the data needs to be locally stored somehow
2020-09-07 19:58:30 <Cogitri> I guess we could have a daemon which automatically downloads the latest appstream data and installs it
2020-09-07 20:00:34 <ikke> each appstream export is about 60MB
2020-09-07 20:02:09 <Cogitri> The appstream data takes up 15K + 2.7M + 320K for me 🤔
2020-09-07 20:03:37 <ikke> The report is 30M
2020-09-07 20:03:46 <ikke> and 20M in data
2020-09-07 20:04:48 <Cogitri> `alpinelinux-appstream-data-20200704-r0 installed size: 2984 KiB`
2020-09-07 20:59:55 <Hello71> check the original pr for dns-root-hints on gh
2020-09-07 21:03:20 <ikke> Which one/ https://github.com/alpinelinux/aports/pulls?q=is%3Apr+root+hints
2020-09-07 21:05:31 <Hello71> the ones with all the comments
2020-09-07 21:06:20 <ikke> PRs which involve tcely all have lots of comments..
2020-09-07 21:06:52 <ikke> I guess you mean this one? https://github.com/alpinelinux/aports/pull/5950
2020-09-07 21:24:26 <Hello71> mainly
2020-09-08 01:58:47 <bugwisser> Hey.. Are they any gottchas to building kernel modules on Alpine? I've been trying to build kenel modules with the `kernel-headers` package, but it won't create a symlink `\lib\modules\$(uname -r)\build` to a directory with `kbuild` and the kernel map Do I need to build a full kernel separately to generate the symbol map, or can I just get the
2020-09-08 01:58:47 <bugwisser> kernel source package from `aports` and customize the `EXTRAVERSION` in kbuild?
2020-09-08 02:06:45 <Hello71> ... \?
2020-09-08 05:18:40 <Ariadne> Hello71: yeah we changed it
2020-09-08 05:18:48 <Ariadne> Hello71: hope you don't mind
2020-09-08 05:19:00 <Ariadne> Hello71: next alpine version will add drive letters
2020-09-08 05:19:29 <ikke> :D
2020-09-08 05:19:54 <ikke> And apk upgrade reboots before it performs the actual upgrade which takes an hour
2020-09-08 05:20:11 <insep_> "Ariadne" (https://matrix.to/#/@freenode_Ariadne:matrix.org): i've been waiting for this feature since slackware, thank you!!!!!!!!!!!!!!!!!!!!
2020-09-08 05:20:12 <Ariadne> its ok, it will say things like "hi" and "we are getting your PC ready for use"
2020-09-08 05:20:32 <insep_> drive letters are do much more intuitive than unix filesystem
2020-09-08 05:20:45 <[[sroracle]]> "all of your files are where you left them" ;)
2020-09-08 05:20:59 <Ariadne> no we don't lie to users
2020-09-08 05:21:52 <insep_> can i leave a suggestion? alpine needs to switch to darwin or nt kernel
2020-09-08 05:21:54 <Ariadne> easier to say "all your data was deleted"
2020-09-08 05:22:03 <Ariadne> heck yeah lets switch to NT
2020-09-08 05:22:22 <Ariadne> actually
2020-09-08 05:22:28 <Ariadne> i got apk-tools mostly working on midipix
2020-09-08 06:05:46 <mps> ncurses 20200907 released with one msg: fix regression in setupterm validating non-empty $TERM (report by Soren Tempel).
2020-09-08 09:04:24 <mps> insep_: why not *bsd kernel
2020-09-08 09:05:03 <insep_> obviously nt is superior
2020-09-08 09:05:22 <mps> ah, yes ;p
2020-09-08 17:56:47 <minimal> Hi folks. What's the general consensus on packages not having openrc subpackages but rather having the init.d scripts in the main package?
2020-09-08 17:57:54 <ikke> The general consensus is that they should be added to subpackage
2020-09-08 17:58:29 <ikke> That was done as a general preparation to change init systems, if when we are ready to do so
2020-09-08 17:59:01 <ikke> The consensus is codified in abuild warning about those files not being in een *-openrc subpackage
2020-09-08 17:59:05 <minimal> ikke: I understand the seperation when, e.g., something like nginx could be used either without or without init.d scripts but it seems strange to have to create a openrc subpackage for something that only works via init.d
2020-09-08 17:59:23 <dalias> what "only works via init.d" ?
2020-09-08 17:59:42 <ikke> minimal: nginx in docker does not require openrc service files
2020-09-08 18:00:03 <minimal> dalias: in my case I maintain cloud-init and its only used during boot time via init.d
2020-09-08 18:00:04 <ikke> and the -openrc subpackage is automatically pulled in when openrc is installed
2020-09-08 18:00:22 <ikke> minimal: the only thing you need to do is to add $pkgname-openrc to subpackages
2020-09-08 18:00:34 <ikke> so the amount of work is 'minimal' :P
2020-09-08 18:00:49 <minimal> ikke: yes docker is exactly the point I was making of init.d script not being required in some cases and so making sense to seperate them
2020-09-08 18:01:37 <ikke> So not really sure what's against splitting it up then
2020-09-08 18:01:39 <minimal> ikke: I already have a openrc subpackage, I was considering removing it and noticed the abuild warning
2020-09-08 18:01:48 <dalias> minimal, what if a user wants to run instances of cloud-init themselves in some custom supervision not built on the distro's init system?
2020-09-08 18:02:16 <dalias> i'm not sure exactly what cloud-init is so i don't have a concrete example
2020-09-08 18:02:41 <dalias> but "we have our own supervision preference rather than using the distro's init system" is a fairly common position
2020-09-08 18:02:51 <ikke> minimal: keeping packages small and splitting things up in subpackages is common in alpinelinux
2020-09-08 18:02:52 <minimal> dalias: I can understand if Alpine in general was expecting multiple init packages to be provided
2020-09-08 18:03:05 <ikke> minimal: at some point, we may
2020-09-08 18:03:17 <ikke> so this is to be prepared for that
2020-09-08 18:04:01 <ikke> and because the only thing it requires is defining an -openrc subpackage, it cannot be considered burdensome
2020-09-08 18:04:27 <dalias> minimal, it doesn't depend on that though. "we want to supervise our stuff independently of the distro's init system, not change the distro's init system" is completely reasonable
2020-09-08 18:05:14 <ikke> dalias: if you have openrc installed, you will get all the subpackages anyway
2020-09-08 18:05:51 <dalias> alpine already has packages for s6 and runit, as well as busybox runit etc
2020-09-08 18:06:17 <dalias> ikke, ah i wasn't aware of that. but still you might not have openrc installed if your system is a container image
2020-09-08 18:06:32 <mps> dalias: busybox runit applets aren't built
2020-09-08 18:06:33 <ikke> yes, then you don't get them
2020-09-08 18:07:09 <dalias> then it's not so much "replacing the distro's init" (which would require redoing all the stuff to bring up a bare metal system) as "providing a supervisor to run as pid 1 in the container"
2020-09-08 18:07:09 <minimal> ikke: ok, fair enough I'll leave it be. Just wondered the reasoning. Also I've found some the interdependancy of packages sometimes unclear - doing an "apk info -a cloud-init"  doesn't show it depending on cloud-init-openrc, rather it "affect auto-installation of cloud-init-openrc"
2020-09-08 18:07:28 <dalias> mps, even in busybox-extras?
2020-09-08 18:07:52 <mps> no, even not there
2020-09-08 18:08:02 <ikke> minimal: the openrc subpackages have an 'install_if' set
2020-09-08 18:08:11 <mps> though I mumbled few times here to enable them
2020-09-08 18:08:20 <ikke> so they get pulled in when both the package and openrc is installed
2020-09-08 18:08:56 <minimal> dalias: for a container you don't normally run a typical init. However I maintain s6-overlay for Alpine which is designed specifically as a supervisor for containers
2020-09-08 18:09:23 <ikke> minimal: https://gitlab.alpinelinux.org/alpine/abuild/-/blob/master/abuild.in#L1946
2020-09-08 18:10:24 <minimal> ikke: yes, I realise that, just find it a little unclear
2020-09-08 18:10:35 <ikke> yes, but the mechanism is really nice
2020-09-08 18:10:44 <ikke> If you don't have openrc, you dont get the -openrc subpackages
2020-09-08 18:10:57 <ikke> the main package depending on the openrc subpackage would pull it in always
2020-09-08 18:11:39 <ikke> note that cloud-init itself does not really depend on the initd files
2020-09-08 18:11:53 <ikke> so marking it as a dependency would not really be correct
2020-09-08 18:12:34 <minimal> yeah. Make sense, especially for prepping for the day to officially support more than 1 init in general (Debian seemed to be heading in that direction with systemd and svsinit but then their policy stopped short of requiring all maintainers to provide more than just systemd support)
2020-09-08 18:13:15 <ikke> The same mechanism allows you to add `docs`, and you automatically get all -doc subpackages for installed packages
2020-09-08 18:14:55 <mps> I've got alpine desktop working without udev, using libudev-zero
2020-09-08 18:15:14 <mps> hotplug works fine
2020-09-08 18:18:19 <mps> need polishing and tweaks but first steps are good
2020-09-08 18:19:45 <mps> left is iwd without dbus, to have udev and dbus free alpine desktop
2020-09-08 18:26:54 <Cogitri> fcolista: About c695b12226e4606bca1034f48cbe6eee4fc85b98
2020-09-08 18:27:17 <Cogitri> The comment above the pkgver reads: ` # DONT bump this to 0.55.x! # This causes build failures in gjs and libpeas, see https://github.com/mesonbuild/meson/issues/7515.`
2020-09-08 18:27:47 <Cogitri> So could we stop reverting each others changes? :D
2020-09-08 18:28:37 <mps> you mean FF ;p
2020-09-08 18:28:49 <Cogitri> ?
2020-09-08 18:29:04 <mps> firefox
2020-09-08 18:29:26 <mps> just kidding with you, don't take it seriously
2020-09-08 18:29:36 <Cogitri> Ah okie, just wasn't sure what you were referring to ^^
2020-09-08 18:47:51 <ikke> Cogitri: maxice8 I haven't heard you about it, but apparent the container the made aports repos public crashed and didn't run for a while. Can it be that it's no longer required for projects to be public before you can rebase?
2020-09-08 18:48:40 <Cogitri> Ah, I had to manually rebase things locally and force push then
2020-09-08 18:49:10 <ikke> aha, ok
2020-09-08 18:49:35 <ikke> The script has run again, so now everything should be public again
2020-09-08 18:49:51 <Cogitri> I thought that's only on some weird merge conflict or something
2020-09-08 18:50:13 <Cogitri> Thanks for fixing it
2020-09-08 20:25:02 <Hello71> minimal: I think even if a package only contains openrc init.d, it should still use -openrc suffix. then, when more init systems are supported, you can see the base package as a "virtual" with multiple "providers"
2020-09-08 20:31:27 <Ariadne> [11:56:46] <minimal> Hi folks. What's the general consensus on packages not having openrc subpackages but rather having the init.d scripts in the main package?
2020-09-08 20:31:38 <Ariadne> literally, this is a policy violation and the linter should yell at you if it does not already
2020-09-08 20:32:05 <ikke> abuild complains about it
2020-09-08 20:32:23 <ikke> it's not something a static linter can detenct
2020-09-08 20:32:26 <ikke> detect
2020-09-08 21:48:51 <mps> https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00404.html
2020-09-08 21:49:21 <Hello71> haven't there been a bunch of these already
2020-09-08 21:49:28 <mps> Potential security vulnerability in Intel® Active Management Technology (AMT), and Intel® Standard Manageability (ISM) may allow escalation of privilege.
2020-09-08 21:49:36 <Hello71> I guess maybe the "Firmware versions of Intel® AMT 3.x thru 10.x are no longer supported, thus were not assessed for the vulnerabilities/CVEs listed in this Advisory. There is no new release planned for these versions." part is interesting
2020-09-08 21:49:59 <mps> heh, yes
2020-09-08 21:50:40 <mps> and we are mumbling on browsers insecurity :)
2020-09-08 22:31:51 <TBB> good good. I guess there is no new purchase planned for Intel products either, then.
2020-09-08 22:38:04 <mps> I stopped to by intel 5 years ago
2020-09-08 22:42:13 <mps> actually last intel bought by me was in 2012 or 2013, can't remember exactly
2020-09-08 22:48:22 <Ariadne> last intel purchase for me was skylake
2020-09-08 22:48:27 <Ariadne> skylake was disaster
2020-09-08 22:48:38 <Ariadne> replaced with ARM desktop (honeycomb) :)
2020-09-08 22:54:54 <minimal> anyone able to review/merge !12247? Not much to it so should be straightforward...
2020-09-08 23:07:54 <Ariadne> yes
2020-09-08 23:07:59 <Ariadne> let me get my otp token out
2020-09-08 23:10:11 <Ariadne> oof
2020-09-08 23:10:17 <Ariadne> your post-install changes system configuration
2020-09-08 23:10:31 <Ariadne> that's... not something we allow (unlike debian)
2020-09-08 23:13:14 <Ariadne> however, it is arguable that these changes are needed to make cloud-init work as expected
2020-09-08 23:13:18 <Ariadne> so i think it is fine
2020-09-08 23:13:57 <Ariadne> minimal: merged
2020-09-08 23:16:14 <minimal> Ariadne: thanks. Yeah, that was exactly my line of thought - cloud-init isn't used on a running system, rather its installed when building an OS image, so its kinda special
2020-09-08 23:16:53 <minimal> I didn't use rc-update as that won't work in a chroot environment
2020-09-09 06:00:17 <maxice8> Who wrote AL56 ?
2020-09-09 06:36:51 <ikke> missing-patch-description?
2020-09-09 06:37:07 <maxice8> yes
2020-09-09 06:37:50 <ikke> https://gitlab.alpinelinux.org/Leo/atools/-/commit/c0650e8cf35ba3bd891c53ae42d0bf2aa851d313
2020-09-09 06:52:09 <fcolista> Cogitri, sorry, didn't noticed that!
2020-09-09 06:59:01 <Cogitri> Alright, no worries
2020-09-09 08:12:50 <ikke> morning btw
2020-09-09 08:55:32 <oliv3r[m]> Hey all; what can I do to get !11068 to move further :) it feels like we are at a stalemate :)
2020-09-09 09:05:31 <ikke> oliv3r[m]: is the only outstanding issue the name of the resulting binary?
2020-09-09 09:34:46 <oliv3r[m]> ikke: I think it wasn't an issue :p so from my pov, there's nothing much left. Unless you have a suggestion/improvement there
2020-09-09 09:36:54 <ikke> I've added a comment, as a reaction to your comment about `--arch`
2020-09-09 09:37:31 <oliv3r[m]> ok, let me check :) thanks ikke
2020-09-09 09:38:39 <oliv3r[m]> but what if you do apk add --arch <foreign> --root /?
2020-09-09 09:39:24 <PureTryOut[m]> Ariadne: I can't reproduce Akonadi crashing anymore after installing qt5-qtbase-sqlite. Does !12274 help for you?
2020-09-09 09:40:02 <ikke> oliv3r[m]: no difference (just tried it)
2020-09-09 09:40:30 <oliv3r[m]> ikke: so 'no difference' means it doesn't work? you mean?
2020-09-09 09:40:33 <ikke> oliv3r[m]: I apk is hardcoded for a specific arch
2020-09-09 09:41:28 <ikke> oliv3r[m]: yes, it does not work
2020-09-09 09:42:23 <oliv3r[m]> that sounds likea  bug :p so --root /tmp works, but --root / doesn't :(
2020-09-09 09:43:31 <ikke> oliv3r[m]: I don't think --root /tmp works after apk has already been installed there
2020-09-09 09:43:47 <ikke> ie, it's basically used to determine what apk arch to install, from that point, the arch is fixed
2020-09-09 09:44:56 <ikke> so apk allows you to create a chroot for a different arch, but does not let you pick and choose arches within the same chroot
2020-09-09 09:47:56 <oliv3r[m]> ikke: i see; missing feature :p ok now that I understand the problem better; i'll fixt hat :) thanks for your input
2020-09-09 09:51:55 <oliv3r[m]> ikke: ok what I don't know how to solve yet, is that right now, we have 1 klibc package per arch, but as you said we can't use --arch, we have to have all arches on all arches. But that means cross-compilation then on each arch, right?
2020-09-09 10:10:13 <ikke> cross-compilation is not going to be trivial / straight-forward
2020-09-09 10:11:56 <oliv3r[m]> well for klibc its 'easy' as there's no dependencies; but i agree, it's not trivial nor-straight forward. But I don't see any other way :) But maybe I'll just refactor the MR for now to offer only a native version (so strip the multi-arch part) and see how far I can get with that for my needs first
2020-09-09 10:22:41 <oliv3r[m]> actually,no, there is no multi-arch release now, we just have the installation into an arch specific dir; which will be usefull when we do do the cross-compilation thing.
2020-09-09 10:23:44 <oliv3r[m]> ikke: so i guess i have to ask again: where can we install klibc, in an architecture specific way. right now, i was following how others are doing it too
2020-09-09 10:37:39 <ikke> oliv3r[m]: I'm not sure myself about that
2020-09-09 10:51:41 <oliv3r[m]> so it then ultimatly comes down to the comment 'don't put arch specific directories into /usr/lib' but I must question then 'where then' as we do want it to remain arch specific :)
2020-09-09 10:51:58 <oliv3r[m]> but cotigi never responded after that :D
2020-09-09 10:52:10 <oliv3r[m]> so we can just merge it then :p
2020-09-09 10:54:05 <mps> no
2020-09-09 10:54:18 <ikke> normally you have for instance /usr/lib and /usr/lib64 for 32/64bits multi-arch
2020-09-09 10:54:43 <mps> till it is fixed properly it shouldn't be merged
2020-09-09 10:59:40 <ikke> This is gcc-arm* https://pkgs.alpinelinux.org/contents?branch=edge&name=gcc-arm-none-eabi&arch=armhf&repo=testing
2020-09-09 10:59:58 <ikke> not sure if it's comparable
2020-09-09 11:01:56 <mps> I wonder why do we need klibc at all
2020-09-09 11:02:30 <mps> (to complicate distro)
2020-09-09 11:03:40 <mps> one day someone will add glibc
2020-09-09 11:03:56 <maxice8> There is already a glibc alpine
2020-09-09 11:04:22 <mps> yes, but it is unrelated to 'alpine proper'
2020-09-09 11:04:49 <mps> and afaik it also doesn't mix musl and glibc
2020-09-09 11:05:10 <insep_> maxice8: you mean glibc repo or entire alpine built with glibc?
2020-09-09 11:05:55 <mps> maxice8: and it called 'glibc alpine' we should as creator to change name
2020-09-09 11:06:09 <mps> if it is*
2020-09-09 11:06:23 <mps> huh, ask*
2020-09-09 11:06:46 <mps> too much sunlight is on my screen
2020-09-09 11:11:46 <Cogitri> mps: I think the proposed use for klibc was for initramfs images
2020-09-09 11:12:01 <oliv3r[m]> mps: are you suggesting we should 'ban' packages from the distro for reasons?
2020-09-09 11:12:27 <mps> oliv3r[m]: if it introduce mess in base then yes
2020-09-09 11:12:27 <Cogitri> It isn't supposed to be used in the distro itself (and can't be, AFAIU klibc is rather incomplete)
2020-09-09 11:12:36 <oliv3r[m]> klibc is a tiny libc, with a tiny user space (cp, switchroot etc) for indeed, initramfs or super embedded images; if a major package is linking against klibc or using klibc, then something is really off :)
2020-09-09 11:13:05 <oliv3r[m]> Cogitri: well the's always sadists :p
2020-09-09 11:13:09 <mps> yes, I know what is klibc for long time
2020-09-09 11:13:37 <oliv3r[m]> mps: so what is your worry on complicating things? its just adding a single independant package, without any dependancies or rdepencencies
2020-09-09 11:15:03 <mps> oliv3r[m]: I didn't tried your MR, but from discussion here I come to conclusion it will install some mess in /usr/lib
2020-09-09 11:15:16 <mps> sorry if I misunderstood that
2020-09-09 11:15:20 <oliv3r[m]> ikke: i'm not sure if gcc-arm-none-eabi is a fair comparission, but it is one that tackles with this issue, and it installs objects here: "/usr/lib/gcc/arm-none-eabi/10.2.0/arm/v5te/hard/libgcc.a" so using "/usr/lib/<arch>/klibc isn't so bad?
2020-09-09 11:15:45 <mps> if it made similar as it is in debian then I'm not against it
2020-09-09 11:16:05 <oliv3r[m]> mps: well we want to keep it arch specific (like gcc-arm-none-eabi) and so it would install in '/usr/lib/klibc/' or '/usr/lib/<arch>/klibc'
2020-09-09 11:16:16 <oliv3r[m]> mps: it is, but just need to find a decent name to fit it under :)
2020-09-09 11:16:26 <Cogitri> oliv3r: I'd say use /usr/lib/klibc/$arch
2020-09-09 11:16:30 <oliv3r[m]> mps: that's the only point of discussion that is 'left' I guess?
2020-09-09 11:16:38 <mps> ok
2020-09-09 11:16:44 <mps> sorry again
2020-09-09 11:16:54 <oliv3r[m]> Cogitri: if you could add it to the MR, that would be usefull for future reference, but I'll make that change, I do like that equally as well
2020-09-09 11:17:09 <mps> and /usr/lib/klibc/$arch sounds ok
2020-09-09 11:17:38 <oliv3r[m]> mps: actually, I suggested "/usr/lib/${CARCH}-alpine-linux-${pkgname}/"
2020-09-09 11:18:14 <obarun> just to say, you're work is awesome guys, very neat. i fired openrc and installed 66(build with musl) give me a really great system
2020-09-09 11:18:15 <oliv3r[m]> and the tupel does aline how cross-chains are installed normally; would we not prefer that? so '/usr/lib/armhf-alpine-linux-klibc'?
2020-09-09 11:18:19 <mps> oliv3r[m]: that could conflict for (future) cross compilers/tools
2020-09-09 11:18:41 <oliv3r[m]> mps: well the point is to turn it into a cross-lib in the future
2020-09-09 11:18:46 <mps> previous one
2020-09-09 11:19:14 <oliv3r[m]> mps: i don't follow
2020-09-09 11:19:26 <mps> you type too fast :)
2020-09-09 11:20:10 <mps> my message 'oliv3r[m]: that could conflict for (future) cross compilers/tools' was answer to 'mps: actually, I suggested "/usr/lib/${CARCH}-alpine-linux-${pkgname}/"'
2020-09-09 11:20:23 <Cogitri> I'd say just follow what our current packages do, maybe apk will add something to help crosscompilation in v3
2020-09-09 11:20:52 <Cogitri> So /usr/lib/klibc/$CARCH, anything custom here probably won't be useful
2020-09-09 11:21:01 <mps> Cogitri: I agree
2020-09-09 11:21:08 <oliv3r[m]> ok, we can also improve/fix this in the future
2020-09-09 11:21:22 <ikke> sounds like a plan
2020-09-09 11:21:32 <mps> if future ever come
2020-09-09 11:21:38 <Cogitri> Yup
2020-09-09 11:21:42 <oliv3r[m]> but 'tuple(s)' IS being used in alpine already :p
2020-09-09 11:21:47 <ikke> yes, but that lets the present continue :)
2020-09-09 11:22:03 <oliv3r[m]> well i'm using alpine for (embedded) (cross) development (via containers) so i have a need for thef uture :p
2020-09-09 11:23:11 <ikke> smokeping seems to be the only thing that uses a similar convention
2020-09-09 11:23:20 <ikke> /usr/lib/<arch>-<..>
2020-09-09 11:23:38 <mps> for long time I used debian for cross development and I have some experience about pitfails
2020-09-09 11:23:46 <ikke> there is nothing that uses /usr/lib/<arch>-alpine-linux-*/
2020-09-09 11:24:31 <mps> ikke: this should be reserved for future alpine cross dev toolchains
2020-09-09 11:24:48 <mps> imo, ofc
2020-09-09 11:26:08 <mps> tempting is to follow MCM tree naming
2020-09-09 11:28:00 <Cogitri> Hm, I'm not sure if we'll ever so crosscompilation tho, native compilation works for almost everything since we have native builders
2020-09-09 11:28:42 <Cogitri> And when aports doesn't support it there's little meaning behind getting crosscompilation working elsewhere
2020-09-09 11:30:09 <mps> cross dev tools would be useful for users, not for alpine builders
2020-09-09 11:30:39 <ikke> yes, but without alpine itself using it, there is little incentive for the project to maintain the toolchain
2020-09-09 11:31:12 <mps> or no one had time
2020-09-09 11:31:23 <TBB> or cross compiling used to suck
2020-09-09 11:31:31 <oliv3r[m]> well once alpine gets used more prominently in embedded development, the need will grow more I suppose
2020-09-09 11:31:33 <TBB> doesn't necessarily anymore
2020-09-09 11:32:04 <ikke> With enough incentive, a lot is possible. Without incintive, things are easily too difficult
2020-09-09 11:32:07 <oliv3r[m]> and with docker being used more and more in these scenario's, we should expect a slow uptick. I reccon most poeple 'fix' this themselves 'from alpine: run 'wget toolchain'
2020-09-09 11:32:43 <oliv3r[m]> though I'm a big supported of 'native' compiles, either with dedicated hardware or qemu; but which work really well with docker for example
2020-09-09 11:33:24 <oliv3r[m]> but I noticed, that for some things, cross-compilation tends to be much faster; e.g. compiling the linux kernel takes nativily 2 mins max; but 120 mins with qemu on the same machine :p
2020-09-09 11:33:34 <TBB> now that I've spent a year with buildroot, whatever little problems I had in the 4 years I actively used Alpine as a project base OS seem completely meaningless
2020-09-09 11:34:01 <mps> native build anything serious for armhf is hard
2020-09-09 11:35:10 <TBB> it's definitely different
2020-09-09 11:38:45 <oliv3r[m]> but would cross-compilation fix that?
2020-09-09 11:39:08 <oliv3r[m]> TBB: so you prefer buildroot or alpine then? why switch and would you switch back?
2020-09-09 11:39:56 <TBB> my work in the Alpine based project was finished
2020-09-09 11:41:50 <TBB> I went to buildroot because it seemed like a good idea at the time; it's got excellent support for a lot of platforms as it's wholly directed towards embedded development
2020-09-09 11:42:23 <TBB> especially in contrast to Yocto, which is like using a cannon to kill mosquitoes
2020-09-09 11:43:57 <TBB> now... I imagine at least that using Alpine on some of that embedded hardware would be a lot more convenient, especially now that the hardware isn't necessarily quite as restrictive anymore; but the area where I'd have to roll my own solution would be anything boot related
2020-09-09 11:44:15 <TBB> I'd probably still rather do that tho
2020-09-09 12:08:21 <oliv3r[m]> TBB: that are my thoughts too. buildroot/openwrt for super tiny systems; anything that has some storage; alpine :) but bootloader/kernel; custom build
2020-09-09 12:33:30 <mps> what about replace mdev init script with this one from https://github.com/slashbeast/mdev-like-a-boss
2020-09-09 12:33:57 <mps> it is more complete and works fine on my box
2020-09-09 12:36:33 <thibf[m]> Question: what triggers new docker image pushed  to hub.docker.com ? The current docker image for alpine edge was built before musl migration  and upgrade musl can reveal some problems (facing issues on RPi)
2020-09-09 12:36:57 <ikke> thibf[m]: ncopa doing a snapshot release on edge
2020-09-09 13:19:18 <thibf[m]> ikke: is there a regularity ? Or should I raise an issue ? Upgrading musl breaks busybox date and breaks busybox upgrade process on raspberry pi because https certificates date is not valid in 1970 (tried on multiple rpi and reproducable issue)
2020-09-09 13:20:29 <mps> thibf[m]: did you run ntp client on boot, chrony for example
2020-09-09 13:21:06 <mps> RPis don't have battery supported RTC afaik
2020-09-09 13:21:18 <ikke> they have no RTC at all
2020-09-09 13:21:26 <ikke> only as an addon module
2020-09-09 13:21:34 <thibf[m]> @mps i have date before running the upgrade , but as soon as musl is updated the date is broken
2020-09-09 13:21:45 <mps> ah, yet another nail in their .... :)
2020-09-09 13:22:26 <mps> thibf[m]: are you sure?
2020-09-09 13:22:58 <ikke> thibf[m]: I'm not sure what busybox date has to do with certificates (tls)
2020-09-09 13:23:12 <thibf[m]> mps : yes i will gather logs for you
2020-09-09 13:23:35 <mps> I have few arm32 SBCs around without battery on their RTCs and whenever I unplug power and later boot them date is always 1970 (which is normal)
2020-09-09 13:24:27 <mps> after restarting chrony server date is set to current
2020-09-09 13:26:19 <thibf[m]> pastebin.com/uh4FEw9D
2020-09-09 13:26:49 <ikke> thibf[m]: please post urls with http(s):// prefix as well
2020-09-09 13:27:10 <mps> and text version
2020-09-09 13:27:43 <ikke> thibf[m]: This is probably an issue with libseccomp that docker uses
2020-09-09 13:27:52 <ikke> We had that issue as well
2020-09-09 13:28:25 <mps> ah, this is not on bare metal problem. huh
2020-09-09 13:28:57 <ikke> the issue is that libseccomp returns -ENINVAL for non-existing syscalls, where musl expects -ENOSYS
2020-09-09 13:29:15 <ikke> so musl never falls back to the syscalls that do exist
2020-09-09 13:29:44 <ikke> up-to-date docker versions should have fixes this though
2020-09-09 13:30:22 <thibf[m]> This was a fresh pull, on docker hub its two months old
2020-09-09 13:30:39 <ikke> It's not about the docker image, it's about the docker version running on the host
2020-09-09 13:31:08 <thibf[m]> I didn't want to flood the chat with the logs
2020-09-09 13:32:03 <mps> `apk add tpaste ; tpaste < log` and post url only
2020-09-09 13:32:22 <ikke> thibf[m]: can you check what version of docker you are using?
2020-09-09 13:32:22 <thibf[m]> Okay ! Thanks for these informations,  i will dig deeper
2020-09-09 13:32:45 <thibf[m]> mps thanks, I will keep this
2020-09-09 13:33:53 <thibf[m]> ikke: the latest stable, 19.03.12
2020-09-09 13:37:16 <ikke> Hmm, that should include this then: https://github.com/moby/moby/commit/89fabf0f241292e929fbb2fbb794d58d8d697ab5
2020-09-09 13:46:09 <ikke> thibf[m]: Would help if you could run that with strace
2020-09-09 13:52:01 <Hello71> ncopa: why do you use scanelf instead of readelf in abuild? seems like binutils is already needed e.g. for strip
2020-09-09 14:01:05 <thibf[m]> ikke I think I understand the issue, it's not a docker issue, it's kernel a kernel issue. The latest raspberry pi os bundled is 4.19.
2020-09-09 14:01:05 <thibf[m]> Time changes to 64 bit in linux are in 5.1
2020-09-09 14:01:46 <mps> thibf[m]: upgrade kernel to linux-lts
2020-09-09 14:09:01 <ikke> The musl maintainer says it should still work in 4.19 (barring any regressions)
2020-09-09 14:09:11 <ikke> s/in/on/
2020-09-09 14:09:12 <alpine-meetbot> ikke meant to say: The musl maontainer says it should still work in 4.19 (barring any regressions)
2020-09-09 14:09:23 <ikke> -_-
2020-09-09 14:15:01 <insep_> does this bot use gnu sed? test test123
2020-09-09 14:15:03 <wsinatra> good bot, you tried
2020-09-09 14:15:34 <insep_> s/\btest/\btoast/g
2020-09-09 14:15:50 <ikke> nope :P
2020-09-09 14:15:56 <ikke> I think it's using python regexp
2020-09-09 14:16:05 <insep_> :(
2020-09-09 14:16:26 <Hello71> most implementations I've seen don't handle & or \refs either
2020-09-09 14:17:18 <insep_> test test123
2020-09-09 14:17:29 <insep_> s/\btest\b/toast/g
2020-09-09 14:17:46 <ikke> the bot is running on sopel
2020-09-09 14:18:05 <insep_> does it handle regex at all?
2020-09-09 14:18:15 <ikke> hmm
2020-09-09 14:18:30 <ikke> s/m+//
2020-09-09 14:18:37 <ikke> Seems like it doesn't
2020-09-09 14:22:08 <ikke> Hmm, it does use regular expressions..
2020-09-09 14:22:13 <ikke> https://github.com/sopel-irc/sopel/blob/master/sopel/modules/find.py#L131
2020-09-09 14:32:56 <ikke> test test123
2020-09-09 14:33:03 <ikke> s/\btest/\btoast/ig
2020-09-09 14:33:16 <ikke> Ok. I'll stop now
2020-09-09 15:45:09 <thibf[m]> ikke  it seems like docker respond EPERM when clock_gettime64 is called : https://tpaste.us/0PDE
2020-09-09 15:46:10 <thibf[m]> Maybe the patch that you linked wasn't included in the docker release, my daemon is also in this version
2020-09-09 15:47:18 <ikke> thibf[m]: You can test by putting that version of the profile in a folder and start the docker daemon with --seccomp-profile to that file
2020-09-09 15:47:36 <ikke> and eperm is indeed the wrong response
2020-09-09 16:32:21 <thibf[m]> ikke it seems like it's a bit deeper, i can modify correctly the seccomp parameter to unconfined and no problem, latest musl works and everything works fine, but forcing the profile to the latest one still produce EPERM. Still digging to see where this Eperm come from
2020-09-09 16:39:21 <thibf[m]> https://github.com/opencontainers/runc/issues/2151 EPERM is thrown when syscall is not implemented instead of ENOSYS, I think that's the answer to my problem
2020-09-09 17:59:40 <thibf[m]> ikke: thanks for your help and hints ! That was helpful
2020-09-09 18:06:26 <ikke> But when it's no longer confined, it should start returning ENOSYS
2020-09-09 18:06:49 <ikke> Otherwise I have no idea how it would fix things
2020-09-09 20:19:19 <thibf[m]> Unconfined disable entirely seccomp and don't filter/intercept syscalls, which enable musl to do his retrocompatibility logic
2020-09-09 20:21:25 <ikke> last time it was enough for me to use that seccomp profile to get the desired behavior
2020-09-09 21:34:17 <raijuuser> Is the wiki the main resource for how tos on building packages for alpine from source or is there a more extensive site?
2020-09-10 07:27:13 <ikke> morning
2020-09-10 07:29:38 <Cogitri> 👋
2020-09-10 07:29:58 <mps> \o
2020-09-10 08:22:49 <nmeum> can someone explain the weird build failure in !12079? Looks like it's also linking gnupg1 objfiles?
2020-09-10 08:23:07 <nmeum> can't reproduce this locally though but would really like to fix that CVE in gnupg
2020-09-10 08:25:38 <ikke> nmeum: can you try to run it in alpinelinux/build-base docker container? That should give you a nearly identical environment
2020-09-10 08:26:50 <ikke> nmeum: do you have gcc10 locally?
2020-09-10 08:26:56 <nmeum> yes
2020-09-10 08:27:08 <ikke> ok
2020-09-10 08:27:35 <nmeum> > multiple definition of `iobuf_debug_mode'; bftest.o:/builds/J0WI/aports/main/gnupg1/src/gnupg-1.4.23/tools/../include/iobuf.h:79: first defined here
2020-09-10 08:27:45 <nmeum> why is main/gnupg1 involved in a build for main/gnupg2? I just don't get it
2020-09-10 08:28:16 <ikke> >>> Changed aports:
2020-09-10 08:28:17 <nmeum> not sure if I get around to testing it in the docker container soonish, but thanks for pointing that out
2020-09-10 08:28:18 <ikke> gnupg gnupg1
2020-09-10 08:28:33 <ikke> It sees both gnupg as gnupg1 as changed
2020-09-10 08:29:22 <nmeum> why though? the diff only modifies main/gnupg/APKBUILD
2020-09-10 08:29:28 <ikke> Yes, I see it
2020-09-10 08:29:39 <maxice8> !12294
2020-09-10 08:30:19 <nmeum> ikke: how are changed aports determined? maybe is just a bug in the ci script?
2020-09-10 08:30:42 <ikke> roughly git diff --name-only  master...<branch>
2020-09-10 08:30:54 <nmeum> where can I find the source of that script?
2020-09-10 08:31:20 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/alpine-gitlab-ci/-/blob/master/overlay/usr/local/bin/build.sh
2020-09-10 08:31:26 <nmeum> thanks! :)
2020-09-10 08:32:10 <ikke> We ca define CI_DEBUG_BUILD for J0WI to get a bit more debug output
2020-09-10 08:35:45 <nmeum> > ap builddirs -d ~/src/aports/main/ gnupg
2020-09-10 08:35:46 <nmeum> > /home/soeren/src/aports/main//gnupg
2020-09-10 08:35:49 <nmeum> > /home/soeren/src/aports/main//gnupg1
2020-09-10 08:35:52 <nmeum> ap builddirs is wrong
2020-09-10 08:36:22 <ikke> ooh, good find
2020-09-10 08:37:36 <nmeum> https://gitlab.alpinelinux.org/alpine/lua-aports/-/blob/master/bin/ap.lua#L148
2020-09-10 08:37:42 <nmeum> that regex is missing an $ at the end, isn't it?
2020-09-10 08:38:36 <nmeum> hm, no
2020-09-10 08:39:08 <ikke> note that lua has no regex implementation by default, it has it's own custom more limited pattern language
2020-09-10 08:40:40 <nmeum> well, I don't really know lua but that ap builddirs thingy is definitly buggy and that's why the build is failing on the ci
2020-09-10 08:43:27 <ikke> https://www.lua.org/manual/5.3/manual.html#6.4.1
2020-09-10 08:43:43 <maxice8> i don't think the `-d` switch works
2020-09-10 08:46:45 <ikke> looks like it should work: https://gitlab.alpinelinux.org/alpine/lua-aports/-/blob/master/bin/ap.lua#L118
2020-09-10 08:48:52 <maxice8> shouldn't it pass all repodirs to require('aports.db'):new(dir:match(), repodirs)
2020-09-10 08:49:31 <maxice8> To perform actions on all repositories (assuming i'm in the aports i pass {"main", "community", "testing"}
2020-09-10 08:51:18 <ikke> It iterates over each provided dir, and runs the subcommand on each of the provided dirs
2020-09-10 08:53:32 <ikke> nmeum: I don't see any anchoring patterns in lua's pattern matching
2020-09-10 08:54:19 <nmeum> well, I don't know lua so not sure how to fix this really ':)
2020-09-10 08:54:29 <ikke> nmeum: hmm, strange
2020-09-10 08:54:40 <ikke> it only does it for gnupg(1)?
2020-09-10 08:54:46 <ikke> iperf does not return iperf3
2020-09-10 08:54:55 <nmeum> strange
2020-09-10 08:55:09 <nmeum> maybe create an issue in the lua-aports repo so we don't forget about this?
2020-09-10 08:55:21 <ikke> yes, certainly
2020-09-10 08:55:28 <nmeum> I think we could just merge the gnupg2 upgrade in the meantime to fix this CVE in gnupg2
2020-09-10 08:55:50 <ikke> yeah, if gnupg itself is succeeding, it should not be an issue
2020-09-10 09:10:07 <ikke> found another one: postgresql
2020-09-10 09:10:36 <ikke> iterating over all packages to see if they return more then 1 result
2020-09-10 09:11:34 <ikke> nmeum: is it because of the provides perhaps?
2020-09-10 09:12:44 <nmeum> hm, could be
2020-09-10 09:13:00 <nmeum> currently at work and didn't really have the time to look into the ap code in more detail
2020-09-10 09:13:32 <ikke> cpupower, go-bootstrap, network-manager
2020-09-10 13:29:06 <oliv3r[m]> ikke: is the runner for the CI using the 'alpine:edge' container, or something else? as I can't reproduce this compilation errors locally for !11068
2020-09-10 13:31:59 <Cogitri> It's using the build-base container
2020-09-10 13:32:20 <Cogitri> But I doubt that the container is causing that
2020-09-10 13:32:36 <Cogitri> Maybe the buildsystem doesn't like how many build jobs CI has
2020-09-10 13:41:56 <ikke> It's using alpinelinux/alpine-gitlab-ci, which uses alpinelinux/build-base, which uses alpine:edge
2020-09-10 14:07:34 <oliv3r[m]> I'm using alpine:edge (or alpine:latest) and in both systmes it works fine, compiling nativily for x86_64 and armv7 via qemu
2020-09-10 14:08:56 <ikke> oliv3r[m]: is it using gcc10?
2020-09-10 14:09:23 <ikke> gcc10 switched to -fno-common, which can result in this multiple definition errors
2020-09-10 15:05:05 <nmeum> ikke: did you investigate the ap issue further we discussed earlier today?
2020-09-10 15:05:21 <ikke> no
2020-09-10 15:06:07 <nmeum> ok, time to learn some lua then I guess
2020-09-10 15:06:30 <ikke> my strong suspicion is that it has to do with provides
2020-09-10 15:07:20 <nmeum> i will look into it
2020-09-10 15:07:30 <ikke> Yeah, almost certain that has to do with it
2020-09-10 15:07:45 <nmeum> main/gnupg has no provides though?
2020-09-10 15:07:59 <nmeum> ah gnupg1 has ok
2020-09-10 15:08:04 <ikke> yes
2020-09-10 15:08:08 <ikke> it provides gnupg
2020-09-10 15:08:15 <nmeum> yes, it has to do with provides if you remove that line from gnupg1 it works
2020-09-10 15:08:17 <ikke> so apk gnupg will list both
2020-09-10 15:08:26 <ikke> ap*
2020-09-10 15:08:47 <nmeum> yeah, probably intended behaviour then?
2020-09-10 15:09:19 <ikke> "Print the build dirs for given packages in build order""
2020-09-10 15:09:24 <ikke> I would say not for that command
2020-09-10 15:09:59 <nmeum> right
2020-09-10 15:10:04 <nmeum> I think I know how to fix this
2020-09-10 15:11:19 <oliv3r[m]> ikke: that sounds like the problem; (fno-common) but as I said, i'm using alpine:edge so the same container? but i'll check the gcc version inside the container :)
2020-09-10 15:11:39 <ikke> oliv3r[m]: did you do an apk upgrade in that container?
2020-09-10 15:11:46 <ikke> alpine:edge has not been updated yet
2020-09-10 15:11:49 <oliv3r[m]> gcc (Alpine 9.3.0) 9.3.0
2020-09-10 15:11:53 <ikke> bingo
2020-09-10 15:11:53 <oliv3r[m]> nope, I did not :)
2020-09-10 15:12:27 <ikke> so this is breaking due to gcc 10
2020-09-10 15:12:30 <oliv3r[m]> ok, i'll see if klibc did a new release to fix this issues (probably not) but at least i can reproduce and see if I can fix/patch it; alternativily, i'd disable the -fno-common flag in the APKBUILD if that is acceptable
2020-09-10 15:12:45 <ikke> oliv3r[m]: most of the time, the fix is relatively easy
2020-09-10 15:13:05 <oliv3r[m]> yeah, i just need 'time' :) that magical thing nobody has anymore :p
2020-09-10 15:13:21 <ikke> heh
2020-09-10 15:13:25 <oliv3r[m]> ikke: but with gcc10 it is breaking indeed :)
2020-09-10 15:14:02 <ikke> The duplicate definitions should be prefixed with extern
2020-09-10 15:16:48 <nmeum> ikke: https://tpaste.us/qlBa this fixes it
2020-09-10 15:17:49 <nmeum> the interesting question is: does it break any other script if we ignore provides in `ap builddirs`? :D
2020-09-10 15:19:40 <ikke> yeah, indeed
2020-09-10 15:20:01 <ikke> But given the nature of this command, I would not expect it
2020-09-10 15:23:10 <nmeum> the other commands will implicitly consider provides packages too though
2020-09-10 15:23:18 <nmeum> should we fix those too?
2020-09-10 15:23:34 <nmeum> e.g.
2020-09-10 15:23:38 <nmeum> > ./bin/ap.lua sources -d ~/src/aports/main/ gnupg
2020-09-10 15:23:42 <nmeum> > gnupg2.2.23https://gnupg.org/ftp/gcrypt/gnupg/gnupg-$VERSION.tar.bz2
2020-09-10 15:23:45 <nmeum> > gnupg11.4.23https://www.gnupg.org/ftp/gcrypt/gnupg/gnupg-$VERSION.tar.bz2
2020-09-10 15:24:41 <ikke> I would say so. If the command operates on supplied package names, it would be strange that it suddently returned provided packages
2020-09-10 15:25:06 <ikke> but, one thing I didn't think about, but not sure if it makes sense
2020-09-10 15:25:27 <ikke> what if your usecase is that you supply a pure virtual package, that only exists in provides?
2020-09-10 15:26:43 <nmeum> like ifupdown-any?
2020-09-10 15:27:26 <ikke> yeah, for instance
2020-09-10 15:27:34 <ikke> Not sure if it's a valid usecase
2020-09-10 15:30:35 <nmeum> hm
2020-09-10 15:31:40 <nmeum> i don't really get what the intended behaviour of this lua code is
2020-09-10 15:31:55 <nmeum> maybe just do a little write up as an issue / pr and we can discuss this further there?
2020-09-10 15:32:44 <ikke> sounds good
2020-09-10 15:32:51 <ikke> Then jirutka can chime in if he wants as well
2020-09-10 15:33:22 <ikke> We could even add a flag to only return real packages
2020-09-10 15:41:39 <nmeum> ok, I guess I will create an issue later today then
2020-09-10 15:42:03 <nmeum> command-line flag would be nice but lua doesn't seem to have any standard getopt-like parser
2020-09-10 15:42:18 <ikke> nope
2020-09-10 15:43:07 <ikke> And preferrably it should not require a flag
2020-09-10 16:16:22 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/aports/-/jobs/204086/raw: > thread 'dbus_server::test::test_delete_required_package' panicked at 'Failed to execute abuild!: Os { code: 2, kind: NotFound, message: "No such file or directory" }', apk-polkit-rs/src/dbus_server.rs:236:14
2020-09-10 16:16:46 <Cogitri> Huh, abuild should be available in the CI container, shouldn't it?
2020-09-10 16:32:35 <ikke> Is dbus executing abuild?
2020-09-10 16:34:07 <ikke> Cogitri: but yes, abuild is available
2020-09-10 16:35:25 <Cogitri> Weird that it fails on CI then 🤔
2020-09-10 16:35:52 <ikke> "No such file or directory". Is it trying it find it at a certain location?
2020-09-10 16:36:55 <Cogitri> It's not dbus itself, it's apk-polkit-rs (a dbus x polkit thingie to install packages via GNOME Software) executing abuild during tests to build some dummy packages
2020-09-10 16:37:29 <ikke> You can try it yourself in an alpinelinux/alpine-gitlab-ci container
2020-09-10 16:37:38 <Cogitri> Oh actually, seems like I have a bad error message :)
2020-09-10 16:37:43 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/apk-polkit-rs/-/blob/master/apk-polkit-rs/src/dbus_server.rs#L232
2020-09-10 16:38:13 <ikke> heh, I kind of suspected that
2020-09-10 16:40:07 <Cogitri> https://gitlab.alpinelinux.org/Cogitri/apk-polkit-rs/-/blob/master/tests/build_repo.sh#L1 Ah! Maybe it'd be best to actually install bash when the script that builds the repos uses bash :D
2020-09-10 16:40:33 <ikke> aha, makes sense in some way
2020-09-10 18:08:17 <ikke> Cogitri: grilo-plugins has test-failures (one test times out)
2020-09-10 18:08:53 <Cogitri> Hmm, after 300sec?
2020-09-10 18:09:19 <ikke> yes
2020-09-10 18:09:24 <ikke> 3000
2020-09-10 18:11:44 <Cogitri> Hmmm, the 2.99.4 -> 2.99.5 fixed that exact error on x86* 🤔
2020-09-10 18:11:59 <Cogitri> Thanks for the ping, gonna annoy tracker upstream with it :D
2020-09-10 18:19:42 <oliv3r[m]> ikke: sometimes, getting the new version works too :p It was fixed in master and a new release was spun already as well! Didn't think it would be that active (the project). !11068 compiled, some warnings remain, but upstream will probably address those in time I reccon
2020-09-10 18:20:13 <ikke> oliv3r[m]: yeah, that's even easier :P
2020-09-10 18:41:19 <oliv3r[m]> so unless you have other things that we want to change, i guess it's ready :)
2020-09-10 19:54:19 <nmeum> ikke: https://gitlab.alpinelinux.org/alpine/lua-aports/-/issues/1
2020-09-10 20:06:39 <nmeum> pushed the gnupg2 upgrade
2020-09-10 20:10:46 <Cogitri> 👍
2020-09-11 02:21:38 <unrznbl[m]> where in a package build would I create directories and chmod/chown them?
2020-09-11 02:22:06 <unrznbl[m]> post-install step?
2020-09-11 02:24:44 <maxice8> Opinions on: !12294, polkit needs rust now because of mozjs78
2020-09-11 04:42:44 <ikke> unrznbl[m]: In the package() function
2020-09-11 04:50:52 <ikke> maxice8: it seams polkit is only used by consolekit2, and it's not required by anything in main. Shouldn't it be possible to move it to community?
2020-09-11 04:51:20 <maxice8> It is used by libvirt too
2020-09-11 04:51:26 <maxice8> I moved both to comm
2020-09-11 04:51:54 <ikke> nod
2020-09-11 04:52:02 <ikke> I didn't check polkit-dev
2020-09-11 04:55:57 <ikke> hmm, if polkit is now suddently limited on arches by rust, doesn't that mean everything requiring polkit can no longer be bult on those arches either?
2020-09-11 04:56:31 <ikke> Everything in community depending on polkit-dev: https://tpaste.us/NmVB
2020-09-11 05:45:29 <maxice8> yeah
2020-09-11 05:45:37 <maxice8> big oof, lot of stuff will be shutted out of mips and s390x
2020-09-11 05:47:57 <ncopa> morning
2020-09-11 05:48:22 <Cogitri> Morning
2020-09-11 05:48:26 <ncopa> i killed elixir build on armv7
2020-09-11 05:48:29 <ikke> aha
2020-09-11 05:48:36 <ncopa> it appeared to be stuck for days
2020-09-11 05:49:24 <ncopa> whats the status of mips gcc?
2020-09-11 05:51:00 <maxice8> ncopa: can you take a look at https://gitlab.alpinelinux.org/alpine/infra/alpine-secdb/-/issues/2 ?
2020-09-11 05:52:20 <Cogitri> I think only Ariadne knows what's up with mips
2020-09-11 05:52:45 <Ariadne> the status is "the mips gcc maintainer hasn't been paid in 6 months by wave technology and doesn't care"
2020-09-11 05:53:01 <ncopa> should we drop mips?
2020-09-11 05:53:02 <Ariadne> wish i had better news
2020-09-11 05:53:13 <Ariadne> i am starting to think so
2020-09-11 05:53:26 <ncopa> i mean, we currently dont have resources to fix it
2020-09-11 05:53:33 <ncopa> and its holding us back
2020-09-11 05:53:58 <Ariadne> i can probably "fix" it again
2020-09-11 05:54:10 <Ariadne> and do an investigation myself
2020-09-11 05:54:30 <ncopa> i need to tag a new edge release, but i cannot do so if edge does nto even successfully build
2020-09-11 05:55:18 <ncopa> i think we need to set up builders for 3.13 in 2-3 weeks
2020-09-11 05:55:30 <Ariadne> i think we can drop mips for 3.13
2020-09-11 05:55:34 <Ariadne> and let it just track edge
2020-09-11 05:55:38 <Ariadne> that was my plan anyway
2020-09-11 05:55:54 <ncopa> ok
2020-09-11 05:56:24 <ncopa> sounds good to me
2020-09-11 05:56:39 <Ariadne> between marvell all but declaring octeon EOL, wave technology going out of business and our customers wanting us to focus on alpine x86 and aarch64, i don't see a path forward for mips being in a releasable state in alpine
2020-09-11 05:56:52 <Ariadne> the reality is i don't know how to even start to debug the gcc optimizer
2020-09-11 05:56:57 <Ariadne> and its crashing deep in that
2020-09-11 05:56:58 <Ariadne> soooo
2020-09-11 05:56:59 <Ariadne> :)
2020-09-11 05:57:48 <ncopa> i think it would be great if we could get rust working on s390x
2020-09-11 05:58:18 <Ariadne> that requires making the rust package bootstrappable and defining the ABI stuff for s390x
2020-09-11 05:58:21 <Ariadne> seems doable
2020-09-11 05:58:34 <Ariadne> i can work with Cogitri on that towards end of next week
2020-09-11 05:59:02 <ncopa> i suppose we only need to bootstrap it, right?
2020-09-11 05:59:06 <Ariadne> as far as mips goes -- we tried, but the ecosystem is bitrotting
2020-09-11 05:59:15 <Ariadne> i can't fix the entire ecosystem myself
2020-09-11 05:59:18 <Ariadne> :P
2020-09-11 05:59:27 <ncopa> nod
2020-09-11 05:59:41 <Ariadne> even with a team of developers, my team is working on doing more useful things
2020-09-11 06:00:05 <Ariadne> but if loongson is interested, then i am willing to work with them on mips in alpine
2020-09-11 06:00:13 <Ariadne> that's the only way i am afraid its going to work out
2020-09-11 06:00:14 <ncopa> there was a question of longsoon
2020-09-11 06:01:04 <ncopa> i think they may need to provide atleast one dev that can help us maintain it, so it does not end up bit rotting in our repos
2020-09-11 06:01:36 <ncopa> and set up and manage a compile server, and possibly a dev server for us
2020-09-11 06:05:05 <Ariadne> yes
2020-09-11 06:05:17 <Ariadne> well i think mips64el may be slightly easier to deal with
2020-09-11 08:24:07 <PureTryOut[m]> Huh I have a package compiling fine locally but on CI fails but I don't understand why... https://gitlab.alpinelinux.org/PureTryOut/aports/-/jobs/204757#L60
2020-09-11 08:25:32 <ncopa> PureTryOut[m]: possible that some other package is broken in global scope
2020-09-11 08:26:44 <ncopa> Ariadne: question re ifupdown-ng, It looks like it does not set/respect the `hostname $(hostname)` option for dhcp
2020-09-11 08:26:53 <PureTryOut[m]> How would I find out about that?
2020-09-11 08:26:55 <Ariadne> ncopa: 0.9
2020-09-11 08:27:32 <Ariadne> ncopa: actually
2020-09-11 08:27:37 <Ariadne> ncopa: it does support it, for dhcpcd
2020-09-11 08:27:45 <Ariadne> ncopa: not for udhcpc, that will be in 0.9 though
2020-09-11 08:28:46 <ncopa> 0.9 is not out yet, right?
2020-09-11 08:30:43 <ncopa> hum... does not seem to work with dhcpcd either
2020-09-11 08:30:55 <ncopa> oh..
2020-09-11 08:30:58 <ncopa>   531 root      0:00 /sbin/dhcpcd -h $(hostname) eth0
2020-09-11 08:31:27 <ncopa> compared to a working udhcpc:
2020-09-11 08:31:31 <ncopa>   236 root      0:00 udhcpc -b -R -p /var/run/udhcpc.eth0.pid -i eth0 -x hostname:ncopa-edge-x86
2020-09-11 08:32:02 <[[sroracle]]> it's escaping the $() ?
2020-09-11 08:32:31 <ncopa> i think ifupdown-ng is taking the hostname arg literally, while busybox parses it via shell
2020-09-11 08:32:42 <Ariadne> yes
2020-09-11 08:32:49 <Ariadne> i can fix that :)
2020-09-11 08:33:50 <ncopa> i think that parsing via shell is kinda stupid though. would be nice to get it from a syscall or similar
2020-09-11 08:34:49 <Ariadne> well, hostname $(hostname) is weird :)
2020-09-11 08:35:03 <ncopa> exactly
2020-09-11 08:35:24 <Ariadne> yeah we can add some sort of hostname learning thing
2020-09-11 08:35:30 <Ariadne> i want to get 0.9 out this weekend though
2020-09-11 08:35:41 <Ariadne> so i will fix the compatibility issue for now :)
2020-09-11 08:35:59 <Ariadne> but yeah regarding mips
2020-09-11 08:36:05 <Ariadne> we basically made a decision
2020-09-11 08:36:12 <Ariadne> that it makes more sense to focus on things like ifupdown-ng
2020-09-11 08:36:14 <ncopa> would be nice if it could get hostname from uname(2) nodename somehow
2020-09-11 08:36:18 <Ariadne> than it does on trying to keep mips on life support
2020-09-11 08:36:19 <Ariadne> :)
2020-09-11 08:36:22 <Ariadne> yeah
2020-09-11 08:36:38 <ncopa> either by using empty "hostname" or letting $(hostname) be a special keyword
2020-09-11 08:36:40 <Ariadne> sounds perfectly reasonable
2020-09-11 08:37:14 <Ariadne> but for now, IF_HOSTNAME=$(eval echo $IF_HOSTNAME) gets it done
2020-09-11 08:37:49 <Ariadne> while some parts will have native netlink clients provided down the road (i will be writing about this soon :D), i doubt dhcp will get that treatment :P
2020-09-11 08:38:17 <Ariadne> but it makes sense to put IF_HOSTNAME in environment always in some normalized way based on uname(2)
2020-09-11 08:42:26 <Ariadne> ncopa: https://github.com/ifupdown-ng/ifupdown-ng/issues/74
2020-09-11 08:42:34 <Ariadne> ncopa: feel free to drop your thoughts there :)
2020-09-11 08:58:29 <Ariadne> anyway, the future of ifupdown-ng is quite interesting.  we are working on something called libSAL
2020-09-11 08:59:02 <Ariadne> which will allow ifupdown-ng to drive the system with netlink, or drive merchant silicon using appropriate SDKs
2020-09-11 08:59:35 <ikke> to manage data layer for routers / switches?
2020-09-11 08:59:39 <ikke> data plane*
2020-09-11 09:00:16 <Ariadne> yup
2020-09-11 09:00:56 <ikke> nice
2020-09-11 09:04:10 <Ariadne> so eventually you will be able to download an alpine ISO and drive a switch with it
2020-09-11 09:04:16 <Ariadne> that's the end game anyway.
2020-09-11 09:06:44 <Ariadne> (actually the end game is to be able to do that *and* deploy a P4 model to define switch behavior, but... baby steps, right?)
2020-09-11 09:10:31 <Ariadne> anyway i just pushed ifupdown-ng 0.9 which amongst a lot of other things, works around hostname $(hostname) and supports that for udhcpc
2020-09-11 09:10:32 <Ariadne> :)
2020-09-11 09:15:07 <Ariadne> ncopa: anyway, busybox ifupdown runs udhcpc/dhcpcd directly.  we use a helper script for all system changes.  the C side simply determines what scripts to run and when, which is why hostname $(hostname) worked :)
2020-09-11 09:15:22 <Ariadne> or rather did not work :)
2020-09-11 09:21:29 <mps> if the ifupdown-ng will grow so much I hope busybox ifup/ifdown will stay
2020-09-11 09:22:55 <JD_the_fish> Im not quite sure if this is appropriate to ask here, but i couldnt solve this with the other channel. I've been having issues with drive names changing across reboots in diskless mode. fstab changes didnt help, because obviously it resides within the apkovl. Should i be changing the fstab file that resides within the initramfs? Or should i be
2020-09-11 09:22:55 <JD_the_fish> changing options of initramfs-init?
2020-09-11 09:23:17 <Ariadne> mps: the libSAL components will be in a separate package away from ifupdown-ng
2020-09-11 09:23:55 <mps> Ariadne: np, that work will be good, I think
2020-09-11 09:24:27 <Ariadne> mps: for one, libSAL is likely to be AGPL.  we don't want to infect ifupdown-ng with AGPL.
2020-09-11 09:24:32 <Ariadne> that would just be rude :)
2020-09-11 09:24:33 <mps> but I would like to have small utils which is good for simple things
2020-09-11 09:24:55 <Ariadne> ifupdown-ng is only 40KB.  that's small enough :)
2020-09-11 09:25:25 <mps> yes, but add busybox size ;)
2020-09-11 09:26:03 <mps> well, ok. for some simple setups bb ifupdown is quite enough
2020-09-11 09:26:30 <mps> and for more 'featured' ifupdown-ng is quite good
2020-09-11 09:26:45 <ikke> but the idea is to remove bb ifupdown iirc
2020-09-11 09:26:51 <mps> hope we will have choice
2020-09-11 09:27:11 <mps> ikke: iirc, remove of ifupdown pkg yes
2020-09-11 09:27:31 <mps> ifupdown which is ported from debian
2020-09-11 09:27:33 <Ariadne> i have nothing against people explicitly using busybox ifupdown
2020-09-11 09:27:43 <Ariadne> however, busybox ifupdown has a lot of limitations
2020-09-11 09:28:11 <Ariadne> basically as long as it does not become a headache, it can stay :)
2020-09-11 09:28:16 <mps> yes, right. also 'ash' is not featured as bash
2020-09-11 09:28:38 <Ariadne> yes, but a native ifupdown-ng config will not work with busybox ifupdown
2020-09-11 09:29:04 <mps> uh
2020-09-11 09:29:11 <Ariadne> and most of the point here is that the legacy ifupdown config file lacks flexibility, especially in dual-stack environment
2020-09-11 09:29:27 <mps> I thought we will have 'vertical' compatibilty
2020-09-11 09:30:00 <Ariadne> yes, ifupdown-ng will accept busybox config formats, but the native config format is quite simplified
2020-09-11 09:31:06 <mps> but would default config stay minimal
2020-09-11 09:31:18 <Ariadne> the default config is *more* minimal than busybox config
2020-09-11 09:31:20 <mps> wouldn't*
2020-09-11 09:31:22 <Ariadne> it is literally half the size
2020-09-11 09:31:38 <mps> yes, I remember
2020-09-11 09:31:47 <Ariadne> for example, busybox cannot configure multiple addresses on a NIC.  only one ipv4 and one ipv6.
2020-09-11 09:31:53 <mps> so, this will not work with bb ifupdown
2020-09-11 09:31:57 <Ariadne> ifupdown-ng allows you to configure as many addresses and gateways as you want
2020-09-11 09:32:29 <Ariadne> i mean, i'm sorry, but we cannot improve network management by just reimplementing busybox ifupdown and calling it a day
2020-09-11 09:32:38 <mps> but by default install we should not have such setups?
2020-09-11 09:33:09 <mps> i.e. multi net, gateways etc..
2020-09-11 09:33:24 <Ariadne> many people use alpine on their home router.  ifupdown-ng handles even that config simpler.
2020-09-11 09:34:02 <Ariadne> also, we plan to enhance the networking initscript to use ifquery
2020-09-11 09:34:06 <Ariadne> so, honestly
2020-09-11 09:34:06 <mps> heh, can it config my broadcom switch in arm SBC
2020-09-11 09:34:24 <Ariadne> mps: no, it can't.  not unless you install libSAL :)
2020-09-11 09:34:38 <mps> instead of script I made with a lot of 'ip link ...' lines
2020-09-11 09:34:45 <Ariadne> well
2020-09-11 09:34:49 <Ariadne> if iproute2 can configure it
2020-09-11 09:34:53 <Ariadne> then it can configure it
2020-09-11 09:35:12 <mps> sure, just kidding a little
2020-09-11 09:35:36 <Ariadne> but the point of libSAL is to provide ifupdown-ng helpers that can do exactly that
2020-09-11 09:35:38 <mps> your work on this is good, imo
2020-09-11 09:36:13 <mps> for small, simple system we can write guide with some examples
2020-09-11 09:36:22 <Ariadne> the other thing is, like i said, there is desire to use ifquery in the initscript.  it is possible to add an ifquery to busybox, but the ifupdown code in busybox is really a mess
2020-09-11 09:37:06 <Ariadne> i think busybox ifupdown is equally a deadend basically.  i would rather optimize ifupdown-ng core to be even smaller than it is now.  that's something that is quite doable.
2020-09-11 09:37:52 <Ariadne> but the super advanced stuff is going in libSAL
2020-09-11 09:37:58 <mps> good, but it is not big too much as it is now
2020-09-11 09:38:12 <Ariadne> which you wouldn't install typically
2020-09-11 09:38:28 <Ariadne> but using libSAL may be smaller in some cases too
2020-09-11 09:38:43 <Ariadne> since "advanced" features of ifupdown-ng require you to install iproute2
2020-09-11 09:39:15 <Ariadne> so libSAL with netlink backend is likely to be smaller than iproute2
2020-09-11 09:39:25 <mps> well, I always install iproute2
2020-09-11 09:39:29 <Ariadne> (and i did some work to slim iproute2 down by splitting out niche components)
2020-09-11 09:40:14 <Ariadne> i'm just saying if you want things like VRFs but you don't want to sacrifice 500kb of disk for iproute2, libSAL is likely to be a useful alternative
2020-09-11 09:40:58 <Ariadne> which is very relevant in some of the work i do.  if you are trying to fit alpine into 8MiB of flash, iproute2 is a huge ask :)
2020-09-11 09:41:20 <mps> yes, this is quite fine imo. if someone need features then installing extra pkgs is not problem
2020-09-11 09:41:34 <Ariadne> yeah, so that's how i am trying to architect this :)
2020-09-11 09:41:41 <Ariadne> you get small core by default
2020-09-11 09:41:48 <Ariadne> and you can add the things you need
2020-09-11 09:41:54 <Ariadne> for example if you add wireguard-tools
2020-09-11 09:41:59 <Ariadne> you will get ifupdown-ng-wireguard
2020-09-11 09:42:07 <Ariadne> which allows you to manage wireguard with ifupdown-ng
2020-09-11 09:42:12 <mps> that is good
2020-09-11 09:42:26 <mps> I mean, concept is good
2020-09-11 09:43:00 <Ariadne> and there's a clean separation of concerns between device manager and changing system state
2020-09-11 09:43:04 <Ariadne> something classic ifupdown doesn't have
2020-09-11 09:43:22 <Ariadne> one of my peeps is gonna give a talk about all of this at DENOG later this year
2020-09-11 09:43:27 <Ariadne> i'll link the video once its up
2020-09-11 09:43:28 <Ariadne> :)
2020-09-11 09:46:12 <mps> hah, I don't watch videos usually, but sure will watch your about that
2020-09-11 09:49:39 <Ariadne> anyway i think ifupdown-ng is very alpine way of doing things
2020-09-11 09:52:07 <Ariadne> (this is another thing i intend to do with libSAL: i want to write an ip(8) implementation using it -- i suspect iproute2 has a TON of code duplication bloating it up)
2020-09-11 09:54:55 <ncopa> im actually pretty excited about ifupdown-ng. busybox ifupdown has some limitations that has annoyed me for a decade or so
2020-09-11 09:55:21 <ncopa> and finally Ariadne takes the time to implement it properly
2020-09-11 09:56:51 <mps> yes, it is good, really. but I had a fear that it will grow to emacs :)
2020-09-11 09:57:26 <mps> now when he told that it will be even smaller I can only say: big thanks
2020-09-11 09:57:30 <Ariadne> no need.  we follow Unix philosophy strictly here and stay in our lane
2020-09-11 09:57:40 <Ariadne> she*
2020-09-11 09:57:59 <mps> oh, sorry (my mind is to old)
2020-09-11 09:58:09 <mps> too*
2020-09-11 09:58:49 <Ariadne> because of the way it's architected, we just make the libSAL executors replace the shell scripts using provides/replaces
2020-09-11 09:59:23 <Ariadne> so you get ifupdown-ng as it is, or if you want to drive a router with it, you apk add that feature (which is entirely separate package)
2020-09-11 09:59:45 <ncopa> i think it may grow a bit, but i dont expect it to grow to emacs. I also know Ariadne well enough that the big features/dependencies will be optional
2020-09-11 09:59:56 <ncopa> ha! :)
2020-09-11 10:01:26 <mps> ncopa: I put ':)' at the end
2020-09-11 10:02:15 <mps> btw, looked interview with linode, nice to hear you quoted me two times ;)
2020-09-11 10:02:47 <ncopa> i did? :)
2020-09-11 10:03:57 <Ariadne> ifupdown-ng itself is almost done anyway
2020-09-11 10:04:03 <mps> unconsciously probably :)
2020-09-11 10:04:06 <Ariadne> there's a few things left
2020-09-11 10:04:30 <Ariadne> hotplug (ifmond), ifreload and openrc hotplug integration
2020-09-11 10:04:42 <ncopa> wifi?
2020-09-11 10:04:49 <Ariadne> the idea on the latter is that you can start the network asynchronously
2020-09-11 10:04:53 <Ariadne> yes wifi too
2020-09-11 10:05:11 <ncopa> would be nice if alpine installer did not need to mess with wpa_supplicant
2020-09-11 10:05:16 <Ariadne> and services like chrony can start in background
2020-09-11 10:05:17 <Ariadne> yes
2020-09-11 10:05:25 <Ariadne> I think we can get that into 0.10
2020-09-11 10:05:34 <Ariadne> which is due out at end of month
2020-09-11 10:05:39 <mps> ncopa: write a script around iwd/iwctl
2020-09-11 10:05:49 <mps> iwctl is quite scriptable
2020-09-11 10:06:03 <Ariadne> I'm down to do that
2020-09-11 10:06:14 <Ariadne> I don't know what the latest and greatest wifi stuff is
2020-09-11 10:06:23 <Ariadne> that's why I haven't worked on that yet :)
2020-09-11 10:06:38 <Ariadne> but ifupdown-ng can configure your wireguard
2020-09-11 10:06:46 <Ariadne> I want to do the same for openvpn too
2020-09-11 10:07:01 <ncopa> that'd be great
2020-09-11 10:07:04 <Ariadne> but these days I just use wg
2020-09-11 10:07:05 <mps> I think I read some days ago that ubuntu switched to iwd as default
2020-09-11 10:07:13 <Ariadne> well
2020-09-11 10:07:19 <Ariadne> we can do that too
2020-09-11 10:07:25 <Ariadne> we still have time
2020-09-11 10:07:26 <ncopa> i wonder if it would make sense to support both iwd and wpa_supplicant
2020-09-11 10:07:33 <Ariadne> write to devel about it tho please
2020-09-11 10:07:47 <Ariadne> no objection to that either :)
2020-09-11 10:08:09 <mps> well, there is issues with some drivers firmware, but I think the same is with wpa_s
2020-09-11 10:08:14 <Ariadne> oh.  we need to support source-directory
2020-09-11 10:08:23 <Ariadne> 
ACTION opens a bug about that.

2020-09-11 10:08:58 <mps> bad thing about iwd is that it requires dbus
2020-09-11 10:09:24 <ncopa> i think wpa_supplicant may need it too
2020-09-11 10:09:31 <mps> I thought to port eiwd from kiss linux which don't need dbus
2020-09-11 10:10:20 <mps> but now I'm more concentrated to remove e/udev
2020-09-11 10:10:20 <ncopa> udhcpc: sending select for 172.16.7.6
2020-09-11 10:10:41 <ncopa> Ariadne: 0.9.0 works like a charm! thank you!
2020-09-11 10:10:51 <mps> and mainline kernel on RPi
2020-09-11 10:13:13 <Ariadne> as for driving the broadcom switch in your rpi
2020-09-11 10:13:22 <Ariadne> we do have broadcom sdk :)
2020-09-11 10:13:40 <Ariadne> that one is non-free license but :)
2020-09-11 10:14:18 <mps> hehe, I didn't expect otherwise from broadcom
2020-09-11 10:14:33 <Ariadne> well I should clarify
2020-09-11 10:15:05 <Ariadne> it's a combination of GPL, Apache-2 and "you can do whatever you want with this as long as it's running on bcm silicon" license
2020-09-11 10:15:34 <Ariadne> this is why libSAL is going to have a plug-in architecture
2020-09-11 10:15:47 <Ariadne> so we can ship the bcm crap only to bcm customers
2020-09-11 10:17:03 <mps> but mainline kernel now supports some of their switches
2020-09-11 10:17:46 <mps> and long time ago there was swconfig utility in openwrt
2020-09-11 10:18:21 <mps> I rebuilt it for alpine some time ago
2020-09-11 10:18:35 <Ariadne> yes, there is some kernel support for some switches.  but you still need sdk to do a lot.
2020-09-11 10:18:54 <Ariadne> anyway point of libSAL is to abstract that crazy shit away :)
2020-09-11 10:19:33 <Ariadne> idea is you say you want to config eth0 and it figures out how to do that
2020-09-11 10:19:47 <Ariadne> be it through netlink or sdk or whatever
2020-09-11 14:30:21 <indy> hi all, i finally convinced customer's jfrog admin to update to latest stable version which has support for alpine repositories, unfortunately as it requires http auth. userid and especially password/token is exposed in cd/ci log
2020-09-11 14:32:37 <indy> i started to poke at apk-tools, but not yet oriented in code of apk commands
2020-09-11 14:34:12 <indy> fetching part is in - https://github.com/alpinelinux/apk-tools/tree/master/libfetch ?
2020-09-11 14:41:51 <ikke> That's the library that interacts with http, yes
2020-09-11 14:42:04 <ikke> note that a bigger rewrite (apk-tools 3.0) is in the making
2020-09-11 14:42:22 <ikke> So it might be that libfetch is not even used anymore
2020-09-11 14:46:39 <z3ntu> ncopa: I think something's misconfigured in the mips64 linux-lts package: https://pkgs.alpinelinux.org/contents?file=vmlinuz-*&path=&name=linux-lts&branch=edge
2020-09-11 14:47:38 <indy> ikke, is apk-tools-3.0 in edge?
2020-09-11 14:48:00 <Cogitri> Nop, it's still being worked on
2020-09-11 14:48:21 <Cogitri> As in it'll probably take a few months or so until it's ready AFAIK
2020-09-11 14:48:43 <indy> Cogitri, ikke is that in apk-tools git repo?
2020-09-11 14:49:32 <ikke> https://gitlab.alpinelinux.org/alpine/apk-tools/-/tree/v3.0-wip
2020-09-11 14:50:17 <ikke> Only has one commit as of yet
2020-09-11 14:50:24 <alacerda> out of curiosity: what is the new features that is being implemented on this new version? is there any roadmap where I can read about/
2020-09-11 14:50:43 <ikke> alpine-devel and apk-tools mailing list
2020-09-11 14:50:48 <ikke> there are a few topics about it
2020-09-11 14:51:05 <alacerda> cool, thanks...
2020-09-11 14:51:16 <indy> Cogitri, ikke is there any improvement regarding security? (hiding password part of url) using netrc
2020-09-11 14:51:32 <ikke> I don't think libfetch supports netrc
2020-09-11 14:52:50 <ikke> alacerda: https://lists.alpinelinux.org/~alpine/devel/%3C20191203180717.0016af8a%40vostro%3E
2020-09-11 14:54:58 <dalias> lovely..
2020-09-11 14:57:03 <ikke> dalias: referring to "Unfortunately the above changes cannot be fixed easily without changing
2020-09-11 14:57:05 <ikke> to binary file formats.
2020-09-11 14:57:07 <ikke> "?
2020-09-11 15:02:51 <alacerda> thanks ikke
2020-09-11 17:20:08 <indy> are lists from lists.alpinelinux.org available via nntp?
2020-09-11 17:24:27 <dalias> ikke, just the http auth thing
2020-09-11 18:21:02 <mps> managed to boot mainline kernel 5.8.8 on RPi zero W with alpine, and logged in :]
2020-09-11 18:22:29 <mps> 'cat /proc/cpuinfo' => Hardware        : BCM2835
2020-09-11 18:22:50 <mps> Linux localhost 5.8.8-1-zero #1 Fri Sep 11 14:23:52 UTC 2020 armv6l Linux
2020-09-11 18:58:05 <ikke> dalias: ah
2020-09-11 19:04:25 <ikke> indy: I'm not aware of any nntp server
2020-09-11 19:05:18 <indy> ikke, on gmane is last message from 2019
2020-09-11 19:31:09 <dalias> mps, :)
2020-09-11 19:34:43 <mps> dalias: thanks. now have to install it in sys mode, and play with drivers
2020-09-11 19:36:18 <mps> actually it was not so hard, make bcm23(something)-defconfig and some small tweaks in kernel .config
2020-09-12 10:53:43 <Cogitri> Would a binary that's linked against glibc and uses gcompat on an Alpine system be able to call a binary that's linked against musl without blowing up?
2020-09-12 10:53:52 <Cogitri> Currently trying to bootstrap esy and it's not fun
2020-09-12 11:01:31 <mps> what you mean by 'call a binary'
2020-09-12 11:03:51 <Cogitri> Doing something like executing curl
2020-09-12 11:05:02 <mps> aha, not sure but I think it would work with system call
2020-09-12 12:29:19 <ikke> ocaml on armhf is still failing
2020-09-12 12:29:26 <ikke> (was just enabled again)
2020-09-12 13:21:55 <Cogitri> Ah, that's unfortunate
2020-09-12 13:22:06 <Cogitri> Couldn't test it on CI so I figured we could give it a go
2020-09-12 13:35:45 <dalias> cogitri, yes, gcompat is entirely local to the process, there's nothing from it inherited across exec
2020-09-12 13:48:21 <MY-R> aaaand already new kernel 5.4.65, maybe critical cus not many changes...
2020-09-12 13:49:20 <Cogitri> dalias: Okie, thanks for confirming
2020-09-12 13:49:46 <dalias> my-r, :/
2020-09-12 13:50:13 <MY-R> ye :\
2020-09-12 13:56:39 <dalias> i'll take a quick look at it
2020-09-12 14:03:32 <dalias> i don't see any that look like critical problems in non-niche functionality
2020-09-12 14:03:45 <dalias> the netpoll thing is some obscure feature for console-on-network i think
2020-09-12 14:04:01 <dalias> nbd is not user-facing
2020-09-12 14:04:56 <dalias> looks like pretty normal release interval for stable
2020-09-12 14:13:51 <MY-R> great!
2020-09-12 18:22:46 <craftyguy> I get a 502 error when trying to view this, does anyone else? https://git.alpinelinux.org/aports/log/main/vala
2020-09-12 18:23:33 <craftyguy> that link is from this page: https://git.alpinelinux.org/aports/tree/main/vala?h=master
2020-09-12 18:25:10 <insep_> same
2020-09-12 18:40:02 <MY-R> craftyguy, working fine for me, first link loaded fast and second link when clicked "log" was loading maybe 20 seconds
2020-09-12 18:40:50 <craftyguy> hmm, strange. still 502s for me
2020-09-12 18:40:51 <craftyguy> ¯\_(ツ)_/¯
2020-09-12 18:41:15 <[[sroracle]]> it was for me before but now it seems to work. maybe someone is poking at it
2020-09-12 18:42:11 <insep_> now it works for me too
2020-09-12 18:42:45 <craftyguy> yeah works now. guess I just got lucky :P
2020-09-12 18:53:49 <mps> where armhf is built? in armv7 or armhf lxc? and I think on some aarch64 host?
2020-09-12 18:54:40 <mps> tried to setup armhf lxc locally but I got 'Illegal instruction' for some commands (apk for example)
2020-09-12 18:54:51 <mps> most works fine though
2020-09-13 05:05:46 <craftyguy> it seems weird that 'abuild fetch' will only write to /var/cache/distfiles, which is +w for root only.. so fetch fails when run as a non-root user
2020-09-13 05:06:44 <craftyguy> and if you 'sudo abuild fetch', abuild doesn't want to run as root
2020-09-13 05:06:52 <craftyguy> am I going about this all wrong?
2020-09-13 05:08:53 <craftyguy> I guess abuild -s will let me throw it somewhere else
2020-09-13 06:20:19 <Ariadne> craftyguy: abuild-fetch is SUID and checks for abuild group membership
2020-09-13 06:20:29 <craftyguy> ah
2020-09-13 06:20:49 <craftyguy> I wasn't in the abuild group (yet)
2020-09-13 08:02:49 <maxice8> Ariadne: can you take a look at !12274 ?
2020-09-13 08:15:36 <maxice8> @PureTryOut, found out why you can't use all()
2020-09-13 08:15:38 <maxice8> on noto-emoji
2020-09-13 08:15:44 <maxice8> /usr/bin/abuild defines an all() function
2020-09-13 08:16:39 <maxice8> c646887fff6991c5776013899a75378207b530cb
2020-09-13 08:17:07 <Ariadne> maxice8: yes I will push when I get to computer.  or you can push now.
2020-09-13 08:17:28 <maxice8> done
2020-09-13 09:54:49 <mps> \o
2020-09-13 09:56:37 <mps> good news, RPi zero w run mainline kernel 5.8 and u-boot with menu select, wifi with iwd works, sound and video drivers loaded
2020-09-13 09:57:18 <mps> I'll cat it a day :)
2020-09-13 09:57:27 <mps> call*
2020-09-13 10:00:12 <mps> (huh, where are excitements? ;) )
2020-09-13 10:01:19 <insep_> cool
2020-09-13 10:01:45 <afontain_> Fancy!
2020-09-13 10:02:00 <mps> :)
2020-09-13 10:02:04 <mps> thanks
2020-09-13 20:15:35 <PureTryOut[m]> maxice8: oh interesting, good find. Thanks!
2020-09-14 06:29:32 <mps> why this happens https://gitlab.alpinelinux.org/mps/aports/-/jobs/206265
2020-09-14 06:43:39 <Cogitri> mps: I guess the x86_64 runner has some problems
2020-09-14 06:43:44 <Cogitri> ikke: ^
2020-09-14 06:48:52 <mps> aha, ok. thanks for info
2020-09-14 07:33:22 <ikke> hmm
2020-09-14 07:36:21 <ikke> docker seems to work just fine on that host
2020-09-14 07:36:48 <ikke> ah
2020-09-14 07:37:18 <ikke> hmm, no
2020-09-14 08:48:40 <kr0k0> I have problems with build, permission denied on cleanup: https://gitlab.alpinelinux.org/kr0k0/aports/-/jobs/206515
2020-09-14 08:49:05 <maxice8> add chmod-clean to options=
2020-09-14 08:54:16 <kr0k0> maxice8: Thanks!
2020-09-14 08:54:21 <maxice8> welcome
2020-09-14 09:25:09 <Thermi> craftyguy: you doing it wrong. /var/cache/Distfiles should have owner:group set to root:abuild and have acl 775
2020-09-14 09:25:31 <Thermi> If you want to run abuild, make sure you're a member of the abuild group
2020-09-14 09:25:37 <Thermi> Otherwise it won't work
2020-09-14 10:45:38 <maxice8> ping Ariadne
2020-09-14 10:46:05 <maxice8> you asked me to mark db as deprecated, what are the plans with that package ?
2020-09-14 10:46:06 <Ariadne> I'm not at my computer right now is it urgent
2020-09-14 10:47:41 <Ariadne> plan is to get reverse dependency count to 0 and then remove it
2020-09-14 10:47:59 <maxice8> ok, I'll see what I can replace with other dbs and what can be safely disabled
2020-09-14 12:59:33 <nangel> <rant> Doing my very first merge request... kamailio... 1605 packages in main repo, and kamailio is #3 in LOC, just behind samba and gcc
2020-09-14 12:59:52 <nangel> <rant> I'm screwing this up badly... :(
2020-09-14 12:59:55 <nangel> </rant>
2020-09-14 13:05:07 <mps> hmm, we don't have linux-lts for armhf. why?
2020-09-14 13:10:47 <Ariadne> maxice8: sounds good to me
2020-09-14 13:15:50 <Hello71> ncopa: why do you use scanelf instead of readelf in abuild? seems like binutils is already needed e.g. for strip
2020-09-14 13:52:23 <maxice8> <Ariadne "maxice8: sounds good to me"> I have made some MRs, can I tag you and you review them when possible?
2020-09-14 14:04:54 <ncopa> Hello71: i dont remember. i think scanelf was somewhat easier to use and could find elf binaries in a tree or something
2020-09-14 14:55:45 <mps> ncopa: did you read my yesterday msg about mainline kernel working on RPi?
2020-09-14 14:56:28 <mps> does it make sense to reintroduce armhf kernel with next -lts?
2020-09-14 15:21:20 <dalias> ariadne, db = legacy berkeley db? currently 'maintained' by oracle :-p
2020-09-14 15:22:43 <ikke> yes
2020-09-14 15:24:27 <ncopa> i saw that rpi work with lst kernel
2020-09-14 15:24:30 <ncopa> lts
2020-09-14 15:25:00 <ncopa> i think we can enable amrhf if we ever drop the linux-rpi
2020-09-14 15:25:59 <mps> ncopa: not lts, but current stable
2020-09-14 15:27:26 <mps> I'm asking before adding armhf to linux-edge. if you want to keep rpi kernels then I'm not sure should we have armhf in next -lts
2020-09-14 15:31:56 <mps> re db, what to do with postfix if db is removed
2020-09-14 15:40:13 <dalias> postfix can't work without it? :/
2020-09-14 15:40:37 <maxice8> use sqllite or another db like lmdb ?
2020-09-14 15:40:53 <ikke> Does postfix support that?
2020-09-14 15:41:24 <maxice8> there is postfix-sqlite, postfix-lmdb postfix-mysql and postfix-pgsq subpkgs
2020-09-14 15:41:39 <dalias> i dont understand why a MTA uses a db at all
2020-09-14 15:41:53 <dalias> it's such arbitrary awkward misengineering
2020-09-14 15:44:08 <mps> because of hash keys
2020-09-14 15:44:41 <mps> does lmdb support hash type
2020-09-14 15:46:33 <mps> dalias: yes, postfix can work without db, I've built it locally, but a lot of users use hash type in postfix
2020-09-14 15:48:21 <mps> hmm, http://www.postfix.org/lmdb_table.5.html
2020-09-14 15:50:17 <mps> http://www.postfix.org/DATABASE_README.html#types
2020-09-14 15:51:09 <mps> hash =>  This is available only on systems with support for Berkeley DB databases
2020-09-14 16:18:39 <dalias> so users may be depending on it :/
2020-09-14 16:19:33 <dalias> this whole functionality looks so pointless
2020-09-14 16:20:29 <dalias> environ looks especially awful
2020-09-14 16:21:26 <ikke> Every postfix guide encourages you to run postmap on the several mapping files
2020-09-14 16:23:22 <Bridouz> o/
2020-09-14 16:23:24 <detha> Hash/lmdb is only really an issue for 'large' installs
2020-09-14 16:24:08 <Bridouz> Cogitri Could you test if `lollypop` freezes on your computer when launching a song to play ?
2020-09-14 16:24:51 <dalias> ikke, despite it almost certainly making things slower until you reach thousands or tens of thousands of mappings...
2020-09-14 16:25:31 <mps> detha: yes, texthash is quite ok for simple setups, but most people follow giudes and most guides says 'hash'!
2020-09-14 16:25:57 <mps> and lmdb is quite fast
2020-09-14 16:26:43 <mps> but if we remove db on next release we will be flooded by bug reports, bad news and simiar
2020-09-14 16:26:58 <Cogitri> Bridouz: I'll check in a bit
2020-09-14 16:28:35 <mps> option is, write pre-upgrade script which rewrite users /etc/postfix conf files and change hash to lmdb (s/hash\:/lmdb\:/)
2020-09-14 16:29:23 <detha> mps: one of those: either provide a shim on top of something else that replaces db, or document it with large warnings
2020-09-14 16:29:45 <ikke> mps: I don't think that's a suitable option
2020-09-14 16:29:52 <detha> I wouldn't do auto-rewrites - I hate things that touch my configs
2020-09-14 16:30:31 <detha> (and what about those where the next ansible/salt/whatever run overwrites what the script did?)
2020-09-14 16:30:58 <mps> heh, yes
2020-09-14 16:31:20 <ikke> indeed, was thinking the same
2020-09-14 16:31:42 <mps> a lot of problems are on horizon for this, because that I told it will not be easy to remove db
2020-09-14 16:32:25 <detha> who does postfix upstream? Wietse still?
2020-09-14 16:32:32 <mps> but I think, we MUST
2020-09-14 16:32:57 <mps> db will not work correctly with next release
2020-09-14 16:33:05 <ikke> I think we should deprecate first before removing
2020-09-14 16:33:45 <mps> ikke: time64 is not fixed in db
2020-09-14 16:34:20 <ikke> hmm
2020-09-14 16:35:06 <mps> awilfox from adelie prepared web page with issues about this
2020-09-14 16:35:10 <ikke> Does that mean it's already broken on edge?
2020-09-14 16:35:53 <awilfox> https://wiki.adelielinux.org/wiki/Project:Time64
2020-09-14 16:36:08 <mps> awilfox: thanks :)
2020-09-14 16:36:09 <awilfox> if it hasn't been patched with something ala https://code.foxkit.us/adelie/packages/commit/0da94e6962c19e4f0835622bce5082ab4343711b yes, it is broken.
2020-09-14 16:39:11 <mps> I have to repeat: I vote for removal db in postfix
2020-09-14 17:23:34 <dalias> iirc the db fix was just removing some horrible ub
2020-09-14 17:24:19 <dalias> that patch isn't fundamentally right either; it just happens to work on the targets supported
2020-09-14 17:24:29 <dalias> the right fix is passing a real timespec not this broken thing
2020-09-14 17:31:07 <dalias> i think just #define db_timespec timespec (and removing this definition) would be the right thing
2020-09-14 17:31:32 <dalias> or otherwise fix the calls to any libc functions that take struct timespec * to convert back and forth between timespec and db_timespec
2020-09-14 17:31:49 <dalias> you can't just pass a pointer to the wrong type of object and expect it to work
2020-09-14 22:19:45 <Ariadne> [11:23:34] <dalias> iirc the db fix was just removing some horrible ub
2020-09-14 22:19:51 <Ariadne> actually, the db fix is to remove db
2020-09-14 22:20:04 <Ariadne> because new versions are AGPL
2020-09-14 22:20:08 <Ariadne> :D
2020-09-14 22:25:54 <Ariadne> but yes, it will take a long time to get there.
2020-09-14 22:26:15 <Ariadne> this is why i asked for maxice8 to add a warning to the linter -- so we don't dig ourselves any deeper of a hole
2020-09-14 22:26:51 <Hello71> I think dalias is confusing db and dbus
2020-09-14 22:27:13 <Hello71> oh, wait, I missed the lines after
2020-09-15 13:28:08 <nangel> is the ppc64le builder dead?
2020-09-15 13:29:31 <ikke> Might be stuck in emacs again
2020-09-15 13:30:22 <nangel> I restarted a job, and its "running", but not very fast.
2020-09-15 13:36:25 <ikke> temacs
2020-09-15 13:36:32 <ikke> it gets stuck everytime
2020-09-15 13:37:24 <ikke> '13:37:10.820727 futex(0x7ffff7ff2da4, FUTEX_WAIT_PRIVATE, 4294967295,'
2020-09-15 13:37:40 <ikke> I suspect the same issue we are having with other projects
2020-09-15 13:37:43 <ikke> maloc after fork
2020-09-15 13:37:58 <Cogitri> Probably, yes
2020-09-15 13:39:02 <ikke> But why only on ppc64le?
2020-09-15 13:57:25 <nangel> the kamailio build finishes, but hangs:
2020-09-15 13:57:31 <nangel> >>> main/kamailio: build succesfully
2020-09-15 13:57:31 <nangel> $ cp -ar ~/packages packages/
2020-09-15 13:57:32 <nangel> $ mkdir -p keys
2020-09-15 13:57:32 <nangel> $ cp ~/.abuild/*.rsa.pub keys/
2020-09-15 13:57:32 <nangel> Running after_script
2020-09-15 13:57:32 <nangel> 00:02
2020-09-15 13:57:34 <nangel> Saving cache
2020-09-15 13:57:36 <nangel> 00:02
2020-09-15 13:57:38 <nangel> Uploading artifacts for successful job
2020-09-15 13:57:40 <nangel> Uploading artifacts...
2020-09-15 13:57:42 <nangel> packages/: found 49 matching files and directories
2020-09-15 13:57:44 <nangel> keys/: found 2 matching files and directories
2020-09-15 13:57:46 <nangel> tching files and directories
2020-09-15 13:57:51 <nangel> --- 10 minutes and counting...
2020-09-15 14:01:40 <maxice8> please use a paste service when posting more than 2 lines
2020-09-15 14:14:14 <ikke> Should we disable emacs on ppc64le for now?
2020-09-15 14:14:19 <ikke> It keeps the builder stuck
2020-09-15 14:22:06 <Cogitri> Yup
2020-09-15 14:42:18 <dalias> :/
2020-09-15 14:42:22 <dalias> why is it breaking?
2020-09-15 14:42:26 <dalias> emacs should be portable now
2020-09-15 14:50:58 <ikke> somewhere in temacs
2020-09-15 14:51:14 <Cogitri> fwiw we had the same breakage on CI
2020-09-15 14:52:05 <Cogitri> But it worked locally so I figured we could give it a go (and it worked on other arches)
2020-09-15 14:59:09 <dalias> ikke, is this latest emacs with portable dumper?
2020-09-15 15:07:42 <nangel> maxice8: (and all) - sorry
2020-09-15 15:13:26 <ikke> 27.1, which is the latest
2020-09-15 15:13:51 <ikke> not sure what dumper is used
2020-09-15 15:20:41 <dalias> it might not be released yet
2020-09-15 15:22:37 <dne> from 27.1 NEWS file: Emacs now uses a "portable dumper" instead of unexec
2020-09-15 15:23:33 <dalias> ahh
2020-09-15 15:23:37 <dalias> so wonder how/why it breaks...
2020-09-15 15:25:49 <dne> also from NEWS: "Although the portable dumper has been tested, it may have a bug on unusual platforms" :-)
2020-09-15 15:28:05 <dalias> :-p
2020-09-15 15:28:48 <dne> but only one bug…
2020-09-15 18:19:52 <ikke> libdazzle has one testfailure (sigabrt) https://tpaste.us/7KrO
2020-09-15 18:24:36 <Cogitri> Huh, on all arches?
2020-09-15 18:24:45 <ikke> ppc64le
2020-09-15 18:25:48 <Cogitri> Ah, ppc64le was pretty far behind on building so I guess CI didn't run on it
2020-09-15 18:27:11 <ikke> Yeah, so would be good to get it up to speed again
2020-09-15 18:27:26 <ikke> sigabrt usually means memory alignment issues, right?
2020-09-15 18:27:34 <ikke> oh no, assertion failure
2020-09-15 18:29:13 <Cogitri> Yup
2020-09-15 20:12:55 <Hello71> ncopa: no problem using readelf or objdump in default_dbg then? I think I wanted it for some easier-to-parse output, but I can't remember what anymore
2020-09-15 20:14:41 <Hello71> for https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/54
2020-09-16 07:17:15 <ikke> morning
2020-09-16 07:17:46 <mps> ikke: \o
2020-09-16 07:28:54 <ncopa> morning
2020-09-16 07:29:14 <ncopa> so IIRC apk-tools no longer builds without lua support?
2020-09-16 07:29:36 <ncopa> which means we need to bootstrap lua and linenoise as well when bootstrapping new arch
2020-09-16 07:30:24 <mps> yes, lua everywhere
2020-09-16 07:30:50 <ncopa> what was the reasoning for htat?
2020-09-16 07:30:50 <mps> someone proposed and works on lua in linux kernel
2020-09-16 07:31:12 <ncopa> i think it kinda makes sense to build apk-tools without lua during bootstrap
2020-09-16 07:31:31 <mps> I agree
2020-09-16 07:31:58 <mps> I dislike mixing langs in base tools
2020-09-16 07:32:47 <mps> would be nice if base tools are only in plain C
2020-09-16 07:35:09 <ikke> abuild in c would be pretty complex I recon
2020-09-16 07:35:09 <mps> ncopa: when you are here, I would like to 'extend' (replace) mdev init script with one from 'mdev-like-a-boss'
2020-09-16 07:35:36 <ncopa> ok?
2020-09-16 07:35:49 <mps> ikke: sure, but ncopa talks about apk-tools
2020-09-16 07:35:50 <ncopa> which of the scripts?
2020-09-16 07:36:10 <mps> ncopa: init.d of mdev
2020-09-16 07:36:28 <mps> https://github.com/slashbeast/mdev-like-a-boss
2020-09-16 07:36:46 <mps> https://github.com/slashbeast/mdev-like-a-boss/blob/master/mdev.init
2020-09-16 07:37:48 <ikke> ncopa: you can build apk-tools with LUA=no
2020-09-16 07:38:04 <mps> with current init script mdev loading and setting modules works partially, with this from mdev-like-a-boss it does all needed things
2020-09-16 07:38:12 <ikke> https://gitlab.alpinelinux.org/alpine/apk-tools/-/blob/master/src/Makefile#L9
2020-09-16 07:39:25 <ncopa> mps: some of those things needs to be done with udev as well so it could be shared to avoid duplicate
2020-09-16 07:39:42 <ncopa> what is not working with current mdev init script?
2020-09-16 07:40:15 <mps> ncopa: I'm working on libudev-zero which 'replaces' udev
2020-09-16 07:40:54 <mps> already have it working fine on my two boxes
2020-09-16 07:41:27 <mps> https://github.com/illiliti/libudev-zero
2020-09-16 07:42:32 <ncopa> so what is the problem with current mdev script?
2020-09-16 07:42:53 <mps> it doesn't load and set all needed modules
2020-09-16 07:43:29 <ncopa> the mdev-like-a-boss init script duplicates the /etc/init.d/devfs which provides dev-mount
2020-09-16 07:43:37 <mps> and this from mdev-like-a-boss make system more 'clean'
2020-09-16 07:43:38 <ncopa> those bits needs to be removed
2020-09-16 07:43:53 <mps> yes, ofc
2020-09-16 07:44:33 <ncopa> so it is the https://github.com/slashbeast/mdev-like-a-boss/blob/master/mdev.init#L52 parts you need
2020-09-16 07:45:20 <mps> yes, something like that (which need more tests)
2020-09-16 07:45:45 <ncopa> the thing that plugs the loads modules for mdev is hwdrivers
2020-09-16 07:45:49 <mps> because that I wrote "'extend' (replace) mdev init script"
2020-09-16 07:46:50 <mps> uh, I overlooked hwdrivers, thanks for point
2020-09-16 07:47:03 <ncopa> i think the hwdrivers does it wrong though
2020-09-16 07:47:21 <ncopa> we may want replace hwdrivers with mdev-trigger
2020-09-16 07:49:36 <mps> mdev-trigger? something new to write/add?
2020-09-16 07:50:19 <ncopa> yes, replace/rename hwdrivers  with a mdev-trigger
2020-09-16 07:50:46 <ncopa> one of the things i wanted to solve with hwdrivers was some sort of reproducibility
2020-09-16 07:51:06 <ncopa> so eth0 and eth1 didnt randomly swap each reboot
2020-09-16 07:51:51 <mps> hm, I think this should be 'fixed' with /etc/mactab
2020-09-16 07:53:56 <mps> but also hwdriver/mdev-trigger should be make to do that
2020-09-16 07:54:13 <ncopa> ikke: i think LUA is for the lua version, and LUAAPK=yes/no
2020-09-16 07:55:07 <ikke> The comment on that line says to set LUA=no to build without help
2020-09-16 07:55:52 <ikke> if LUA=no, then it sets LUAAPK to no
2020-09-16 08:08:07 <ncopa> so how do you select lua version?
2020-09-16 08:09:42 <ncopa> right
2020-09-16 08:10:24 <ncopa> lua is needed by the build to generate the help text
2020-09-16 08:11:25 <ncopa> but to disable luaapk on the target host, but still use build lua to generate help text you can set LUAAPK
2020-09-16 08:22:21 <ncopa> humpf... explicitly set LUAAPK=yes does not seem to work when we are not crosscompiling
2020-09-16 08:26:44 <Ariadne> [01:29:14] <@ncopa> so IIRC apk-tools no longer builds without lua support?
2020-09-16 08:27:04 <Ariadne> help text.  what we can do is precompile the help text though.
2020-09-16 08:27:14 <ncopa> i figured that
2020-09-16 08:27:33 <ncopa> scripts/bootstrap.sh is broken, it tries to buidl luaapk
2020-09-16 08:27:34 <Ariadne> the generated header file is arch-independent
2020-09-16 08:27:37 <ncopa> which it does not need
2020-09-16 08:27:48 <Ariadne> want me to work on that?  i know how to detangle it
2020-09-16 08:28:06 <ncopa> the apk-tools makefile will autmoatically enable luaapk if any lua is set
2020-09-16 08:28:16 <Ariadne> yeah
2020-09-16 08:28:19 <Ariadne> so, what we do is
2020-09-16 08:28:37 <Ariadne> we precompile the help text and if [ $CBUILD != $CHOST ] don't set any lua
2020-09-16 08:28:38 <Ariadne> :)
2020-09-16 08:29:44 <ncopa> ugh... something is broken
2020-09-16 08:29:49 <Ariadne> mips builder will be back probably today.
2020-09-16 08:30:03 <Ariadne> i also have a solution for the gcc problem on mips
2020-09-16 08:30:09 <Ariadne> although, it is ugly.
2020-09-16 08:30:14 <ncopa> >>> lua5.3-apk*: Tracing dependencies...
2020-09-16 08:30:14 <ncopa> ERROR: /lib/libapk.so.2.10.4: Could not find owner package
2020-09-16 08:30:14 <ncopa> >>> ERROR: lua5.3-apk*: create_apks failed
2020-09-16 08:30:24 <ncopa> that happens with current git master
2020-09-16 08:30:36 <ncopa> either apk-tools is broken or abuild is
2020-09-16 08:30:37 <Ariadne> we disable main/gcc on mips, but create main/gcc9 for mips
2020-09-16 08:31:42 <ncopa> if [ "$CARCH" = mips64 ]; then pkgver=9.3.0; else pkgver=10...; fi
2020-09-16 08:31:43 <ncopa> ?
2020-09-16 08:31:50 <ncopa> hackish :)
2020-09-16 08:31:54 <Ariadne> yeah but with two APKBUILDs
2020-09-16 08:31:55 <Ariadne> :)
2020-09-16 08:32:14 <Ariadne> i mean, it's the only solution i see to "wave technology hasn't paid me in 6 months, so i'm not maintaining mips gcc anymore"
2020-09-16 08:32:22 <Ariadne> (well, that and switch to clang)
2020-09-16 08:32:48 <Ariadne> i don't know if kernels can yet be built with clang though, AFAIK that was the last major blocker
2020-09-16 08:32:53 <maxice8> Full switch to clang sounds nice
2020-09-16 08:33:01 <Ariadne> maybe mps knows :)
2020-09-16 08:34:37 <Ariadne> if switching to clang is viable, then i suggest main/gcc9 for now as mips fix, with mips switching to clang after 3.13.
2020-09-16 08:35:14 <ncopa> i dont know how well clang works with ppc64le and s390x
2020-09-16 08:35:32 <ncopa> i think that was another reason to why we may want stay on gcc
2020-09-16 08:36:05 <mps> Ariadne: this is still work-in-progress, though some people reported that they build it
2020-09-16 08:36:36 <Ariadne> clang works well on ppc64le
2020-09-16 08:36:41 <Ariadne> no idea on s390x :)
2020-09-16 08:36:55 <mps> I wouldn't rely on kernels built with clang for some time
2020-09-16 08:37:56 <mps> it is ok to play with it and test, but production system no
2020-09-16 08:38:01 <mps> systems*
2020-09-16 08:38:03 <Ariadne> Distributions such as Android, ChromeOS, and OpenMandriva use Clang built kernels.
2020-09-16 08:38:09 <Ariadne> interesting
2020-09-16 08:38:20 <mps> yes
2020-09-16 08:38:31 <Ariadne> maybe we should switch linux-edge to use clang and see how it goes?
2020-09-16 08:38:51 <mps> but they have a lot of money and 'work horses'
2020-09-16 08:39:23 <mps> yes, it is worth to try and test, ofc
2020-09-16 08:39:26 <Ariadne> OpenMandriva does? :P
2020-09-16 08:39:32 <mps> no :)
2020-09-16 08:39:41 <mps> I meant other two
2020-09-16 08:39:50 <Ariadne> i am pretty sure we are way bigger than OpenMandriva :P
2020-09-16 08:39:51 <ncopa> i think clang may work on ppc64le and s390x but iirc the problem was that it generated inferior code
2020-09-16 08:40:20 <Ariadne> ah, lower quality optimizer?
2020-09-16 08:40:22 <Ariadne> it is possible
2020-09-16 08:40:30 <Ariadne> but does it really matter in practice
2020-09-16 08:40:32 <mps> however you both want, I'm not against
2020-09-16 08:40:34 <ncopa> IIRC that was the issue a couple of years ago
2020-09-16 08:41:03 <mps> but, I wouldn't use clang built kernels for anything serious
2020-09-16 08:41:13 <Ariadne> that is why i propose linux-edge for now
2020-09-16 08:41:20 <Ariadne> so we can test and see what is up with them
2020-09-16 08:41:26 <ncopa> tmhoang: do you know if clang is usable with s390x nowdays?
2020-09-16 08:41:31 <mps> linux-edge is serious kernel!
2020-09-16 08:41:58 <Ariadne> ok, then we can make another package linux-clang-edge
2020-09-16 08:42:05 <mps> but ok, I'm not against testing it with clang
2020-09-16 08:42:06 <Ariadne> that tracks linux-edge, but with clang
2020-09-16 08:42:08 <Ariadne> :P
2020-09-16 08:42:46 <mps> maybe I will find time on weekend to try on x86_64 and aarch64
2020-09-16 08:43:25 <mps> I'm busy with some other tasks these days
2020-09-16 08:43:57 <mps> but you are free to try, we can always revert if it goes bad
2020-09-16 08:45:48 <Ariadne> i've queued up a linux-edge-5.8.9-r1 with clang locally
2020-09-16 08:45:54 <Ariadne> will see how it goes
2020-09-16 08:45:58 <Ariadne> if goes well for me, will push
2020-09-16 08:45:59 <Ariadne> :)
2020-09-16 08:47:43 <mps> ok, lets see
2020-09-16 08:49:11 <Ariadne> interesting: using clang as compiler adds additional kernel security feature options
2020-09-16 08:49:18 <mps> yes
2020-09-16 08:49:23 <Ariadne> i'll turn those on too
2020-09-16 08:50:13 <ncopa> how does meson work with crosscompile? libeconf does not crosscompile
2020-09-16 08:50:33 <Ariadne> you have to provide an answers file
2020-09-16 08:50:40 <maxice8> https://mesonbuild.com/Cross-compilation.html
2020-09-16 08:51:09 <maxice8> Void Linux automatically creates it on-demand with the build_style fancyness,  Exherbo ships the answers file for specific arches
2020-09-16 08:51:44 <ncopa> sigh...
2020-09-16 08:52:13 <ncopa> so we need fix our scripts/boostrap.sh to create an answers file?
2020-09-16 08:52:31 <Ariadne> we should do what exherbo does and ship a set of answer files for each arch
2020-09-16 08:52:37 <maxice8> or ship them in the meson package
2020-09-16 08:52:43 <Ariadne> then adjust APKBUILD to reference the answer file in a crosscompile scenario
2020-09-16 08:52:49 <ncopa> thats what i think bootstrap.sh should do
2020-09-16 08:53:00 <ncopa> create an ansers file for the arch
2020-09-16 08:53:25 <ncopa> can util-linux be built without libeconf for bootstrap?
2020-09-16 08:53:36 <maxice8> sure
2020-09-16 08:56:07 <ncopa> Ariadne: i think I have a new crosscompiled gcc for mips64
2020-09-16 08:56:29 <Ariadne> won't do any good -- that just kicks the ball down the road
2020-09-16 08:56:51 <Ariadne> but i guess it is "good enough" for the immediate moment
2020-09-16 09:00:02 <Ariadne> mps: any suggestions for loadtesting a kernel?
2020-09-16 09:01:51 <Ariadne> a substantial advantage for clang as system compiler is that it makes most of bootstrap.sh go away :)
2020-09-16 09:02:26 <ncopa> hum
2020-09-16 09:02:32 <ncopa> can gcc be built with clang?
2020-09-16 09:02:35 <Ariadne> yes
2020-09-16 09:03:24 <ncopa> seems like build-edge-mips64 is down
2020-09-16 09:03:53 <ncopa> at this point i wonder if we should just simply nuke mips64 from orbit
2020-09-16 09:05:26 <Ariadne> it will be returning later today
2020-09-16 09:05:30 <Ariadne> i just need to boot it back up
2020-09-16 09:05:38 <Ariadne> we relocated it into an actual cabinet
2020-09-16 09:06:20 <ncopa> ok
2020-09-16 09:06:40 <Ariadne> i also have a solution for the old BSP kernel
2020-09-16 09:06:51 <Ariadne> i'm going to move the builder itself into KVM
2020-09-16 09:07:08 <Ariadne> so we can just boot 5.4 kernel like any other machine :)
2020-09-16 09:09:36 <Ariadne> although that won't happen today.  i need to validate that my backporting of octeon3 kvm support into the vendor kernel sources actually works :)
2020-09-16 09:09:56 <Ariadne> and that linux-lts will actually boot under kvm
2020-09-16 09:15:58 <Ariadne> hmmph.  the openwrt box we are using as serial console server reset itself
2020-09-16 09:16:07 <Ariadne> very rude
2020-09-16 09:16:44 <Ariadne> time to go grep logs for whatever the default password was :)
2020-09-16 09:16:51 <Ariadne> once i do that i can bring it back up :)
2020-09-16 09:17:31 <artok> am I reading some gospel of clang ? =)
2020-09-16 09:20:30 <mps> Ariadne: sorry, was afk
2020-09-16 09:21:39 <mps> no, nothing special for testing but if you don't sniff smoke and cpu don't melting than it good first steps
2020-09-16 09:22:02 <mps> it is*
2020-09-16 09:23:10 <Ariadne> i think 5.9 will be next LTS
2020-09-16 09:23:19 <Ariadne> if 5.8 is good with clang, then 5.9 will be too
2020-09-16 09:23:21 <Ariadne> most likely.
2020-09-16 09:23:49 <mps> not sure, maybe 5.10
2020-09-16 09:24:07 <mps> 5.9 is too buggy
2020-09-16 09:25:24 <mps> 5.9 is unusable on mediatek arm64, had to go back to 5.8
2020-09-16 09:25:45 <mps> and a pile of new bugs on rk3399
2020-09-16 09:26:28 <Ariadne> afaik 5.4 does not have the support for clang yet
2020-09-16 09:27:46 <mps> i didn't hear/read that anyone use 5.4 built with clang, but I'm not informed well, at the end
2020-09-16 09:27:50 <insep_> google is fine with clang on 4.х /shrug
2020-09-16 09:28:38 <Ariadne> yes, but are the patches upstream
2020-09-16 09:28:40 <Ariadne> :P
2020-09-16 09:28:44 <mps> (could bear clang but now is rust on horizon in kernel)
2020-09-16 09:29:58 <Ariadne> clang analyzer may be interesting for kernel
2020-09-16 09:30:03 <Ariadne> find some 0day :)
2020-09-16 09:30:22 <Cogitri> clang generally has some really nice tooling
2020-09-16 09:30:47 <Ariadne> yeah that is why i would like to evaluate switching the default compiler over
2020-09-16 09:30:54 <Ariadne> i think gcc is not really in great shape
2020-09-16 09:32:12 <mps> I will try kernel with clang on armv7 this weekend (if something else doesn't take time)
2020-09-16 09:32:39 <Cogitri> It does seem like CLang is getting really good these days, I switched $WORK over to it a few months ago and it's pretty neat
2020-09-16 09:32:48 <Cogitri> Well, as neat as C++ can be :^)
2020-09-16 09:33:00 <artok> llvm with apple and google money...
2020-09-16 09:33:17 <Ariadne> gcc with codesourcery and IBM money
2020-09-16 09:33:19 <Ariadne> your point is what
2020-09-16 09:33:34 <mps> artok: that is reasons of my aversion to clang/llvm
2020-09-16 09:33:44 <Ariadne> gcc is corporate money too
2020-09-16 09:33:51 <Cogitri> It's still OSS software, so what gives
2020-09-16 09:33:56 <artok> yeah, but IBM is old style of house
2020-09-16 09:33:57 <Ariadne> if you want corporate-free toolchain, you'll need to write your own
2020-09-16 09:34:10 <Cogitri> Lots of stuff is corporate sponsored
2020-09-16 09:34:20 <mps> Ariadne: right
2020-09-16 09:34:23 <Ariadne> i just want to use the one that is being competently maintained
2020-09-16 09:34:28 <Ariadne> that is increasingly not gcc
2020-09-16 09:34:28 <insep_> how about tcc then? :^)
2020-09-16 09:34:33 <Ariadne> i said maintained
2020-09-16 09:34:55 <mps> sad world of free/open software
2020-09-16 09:35:37 <Ariadne> Cogitri: please do not ever refer to it as CLang again
2020-09-16 09:35:40 <Ariadne> :(
2020-09-16 09:35:49 <Ariadne> that is for some reason bothersome
2020-09-16 09:35:50 <Cogitri> Sorry, GLib tainted me :D
2020-09-16 09:35:51 <Ariadne> like X-Windows
2020-09-16 09:36:03 <Cogitri> And DBus ^^
2020-09-16 09:36:31 <Ariadne> i just refer to the latter as "malware"
2020-09-16 09:36:45 <mps> but if someone look at kernel git changelog, most are from people employed by big corporations
2020-09-16 09:36:48 <Ariadne> but not like i've written anything better
2020-09-16 09:36:56 <Ariadne> mps: Alpine/OpenBSD when
2020-09-16 09:37:31 <mps> will it run on our mediatek chromebooks :D
2020-09-16 09:37:50 <insep_> Ariadne: just run alpine in linuх emulation mode in freebsd :^)
2020-09-16 09:38:19 <Ariadne> insep_: at dayjob we are working on such an option, but using netbsd kernel instead
2020-09-16 09:39:35 <mps> 
ACTION have to stop mumbling and do what he can for better alpine

2020-09-16 09:43:46 <Ariadne> hmm that's weird
2020-09-16 09:43:51 <Ariadne> it is compiling the kernel twice?
2020-09-16 09:51:16 <Ariadne> CONFIG_TRIM_UNUSED_KSYMS=y
2020-09-16 09:51:17 <Ariadne> ah
2020-09-16 09:51:59 <ncopa> we cannot trim unused ksyms on lts kernel due to 3rd party mods
2020-09-16 09:52:30 <Ariadne> yeah
2020-09-16 09:52:37 <Ariadne> i was just wondering why it built the kernel twice
2020-09-16 09:52:39 <Ariadne> :)
2020-09-16 09:52:47 <Ariadne> first time it has to build to figure out what to trim
2020-09-16 09:52:52 <Ariadne> second time it builds and trims
2020-09-16 09:55:56 <mps> gcc does that in one pass
2020-09-16 09:57:31 <Ariadne> yeah
2020-09-16 09:57:37 <Ariadne> it does it in one pass here too, actually.
2020-09-16 09:57:42 <Ariadne> i was just confused :)
2020-09-16 09:59:30 <ncopa> ppc64le builder is far behind
2020-09-16 09:59:56 <mps> ncopa: are you sure about trim, I've built one third party module locally without problem
2020-09-16 10:00:36 <mps> but maybe some can't be built, idk
2020-09-16 10:00:50 <ncopa> depends on what symbols the thirdparty mods uses
2020-09-16 10:01:53 <mps> and with next -lts we will not need many third party modules, dahdi only, whatever it is
2020-09-16 10:03:19 <Ariadne> dahdi is used for asterisk
2020-09-16 10:03:31 <Ariadne> it provides timing and access to ISDN cards
2020-09-16 10:03:43 <PureTryOut[m]> maxice8: shit you were just too quick to merge
2020-09-16 10:03:54 <maxice8> Did I miss something ?
2020-09-16 10:03:55 <PureTryOut[m]> You now overwrote changes I made to modernize openhmd and enable it's tests
2020-09-16 10:03:59 <mps> Ariadne: thanks for info
2020-09-16 10:04:03 <maxice8> sorry
2020-09-16 10:04:23 <PureTryOut[m]> Oh wait nvm, my Gitlab page was outdated
2020-09-16 10:05:00 <maxice8> I doubt I can overwrite your stuff with mgmr
2020-09-16 10:05:07 <Ariadne> anyways
2020-09-16 10:05:14 <Ariadne> time to reboot in a minute i guess
2020-09-16 10:05:51 <maxice8> @PureTryOut: 8b7ecb6079b1f13660626dbbd893ec1fe9fb9ed1 seems like it made it through
2020-09-16 10:05:55 <maxice8> Just in Time
2020-09-16 10:06:30 <PureTryOut[m]> Yeah like I said, my Gitlab page was outdated
2020-09-16 10:08:47 <Ariadne> mozjs78 doesn't depend on rust does it
2020-09-16 10:09:23 <Cogitri> It does
2020-09-16 10:09:31 <Cogitri> Like ff78 does
2020-09-16 10:10:58 <ncopa> we need rust on s390x
2020-09-16 10:12:17 <Ariadne> welp
2020-09-16 10:12:55 <Ariadne> X causes a kpanic on this kernel.  going to downgrade and see if 5.8.9-r0 also kpanic
2020-09-16 10:13:55 <Ariadne> if it doesn't then going to disable the new security features
2020-09-16 10:14:37 <Ariadne> ok no kpanic on 5.8.9-r0
2020-09-16 10:20:07 <Ariadne> building new 5.8.9-r1
2020-09-16 10:21:09 <mps> uname -a => Linux zarya 5.9.0-rc5-1-gru #2 SMP PREEMPT Mon Sep 14 07:05:10 UTC 2020 aarch64 GNU/Linux
2020-09-16 10:21:12 <mps> :)
2020-09-16 10:26:38 <mps> ehm, can't resist to add: artok is right, all what comes from corporations smells to me
2020-09-16 10:27:26 <mps> s/smells/stinks/
2020-09-16 10:27:26 <alpine-meetbot> mps meant to say: ehm, can't resist to add: artok is right, all what comes from corporations stinks to me
2020-09-16 10:28:46 <artok> but my point was: apple and google are more forward thinking companies than others (for example IBM) so their money and work does more good
2020-09-16 10:29:58 <mps> whatever. if the beggining of free software didn't had RMS and ESR (and other) we all be windows users
2020-09-16 10:30:07 <artok> small things: going to meeting with IBM people. If you don't have suit on you when you're doing demo of the streaming system, you're not doing it correctly
2020-09-16 10:30:38 <mps> and shirt with blue stripes :)
2020-09-16 10:30:43 <Ariadne> RMS sure, ESR no.
2020-09-16 10:31:29 <mps> RMS is most important, I think. but a lot of other helped
2020-09-16 10:32:23 <Ariadne> ESR is someone who jumped on the bandwagon as a cheerleader in order to advance his own personal name recognition
2020-09-16 10:32:39 <mps> though I argued with RMS in person about some 'thing', even have video in my archive :)
2020-09-16 10:32:55 <Ariadne> it's ok
2020-09-16 10:33:22 <Ariadne> i've watched RMS scream at the top of his lungs at some intern because the green room at some conference was not arranged exactly to preference
2020-09-16 10:33:57 <mps> yes, strong people have 'strong opinions' ;)
2020-09-16 10:34:12 <Ariadne> i have strong opinions, but i've never yelled at anyone
2020-09-16 10:34:36 <Ariadne> at least -- not like that.
2020-09-16 10:35:33 <mps> hmmmm, I also don't yell, but sometimes that is only option
2020-09-16 10:36:58 <mps> and people who changes established things tends to be 'not CoC compliant'
2020-09-16 11:15:43 <mps> does mdev have include option to put in /etc/mdev.conf
2020-09-16 11:57:48 <Ariadne> time 2 reboot again
2020-09-16 12:00:41 <Ariadne> and that's a big nope
2020-09-16 12:00:59 <Ariadne> https://tpaste.us/pKjm
2020-09-16 12:06:08 <mps> hmm, my gut feeling was right, it is to early to use kernel built with clang/llvm
2020-09-16 15:23:30 <PureTryOut[m]> What is wrong with the pcc64le builder? According to https://build.alpinelinux.org it's been stuck for a while on emacs but it doesn't actually show the log for it
2020-09-16 15:27:36 <Cogitri> I think it only ever uploads them after success/fail
2020-09-16 15:27:39 <insep_> seems like emacs really hates powerpc and gets stuck there often, iirc there's been a discussion to disable emacs on that arch
2020-09-16 15:28:06 <dalias> *sigh* instead of how to fix it..
2020-09-16 15:31:42 <insep_> just use neovim /s
2020-09-16 15:33:09 <ikke> Yeah, lets disable it for now
2020-09-16 15:47:44 <ikke> ppc64le is now continuing
2020-09-16 15:50:05 <dne> is there a build log for the emacs issue somewhere?
2020-09-16 16:54:49 <ncopa> i suspect the emacs deadlock is due to something it does after fork
2020-09-16 16:55:02 <ncopa> i can reproduce in my build env
2020-09-16 16:55:23 <ncopa> 110638 ncopa     0:00 make -C src VCSWITNESS= all
2020-09-16 16:55:23 <ncopa> 111217 ncopa     0:03 ./temacs --__aslr-disabled -batch -l loadup --temacs=pdump
2020-09-16 16:55:23 <ncopa> 111221 ncopa     0:00 ./temacs --__aslr-disabled -batch -l loadup --temacs=pdump
2020-09-16 16:55:47 <ncopa> pid 111221 is a fork of 111217
2020-09-16 17:00:36 <ikke> ncopa: that was my suspicion as well
2020-09-16 17:01:00 <ikke> one process is waiting on read(), the other on futex()
2020-09-16 17:02:02 <ikke> dne: https://tpaste.us/WRyB
2020-09-16 17:02:40 <ikke> dne: also: 1ac2507e151c33a00570cba72c2112320f26b7e0
2020-09-16 19:10:36 <ikke> gcc-cross-embedded takes long :)
2020-09-16 20:57:28 <dne> ikke: thanks
2020-09-16 21:03:42 <dne> avoiding calling out to git in loadup.el seems to make the build succeed: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12558
2020-09-16 21:03:45 <ikke> build-edge-ppc64le is now idle
2020-09-16 21:05:52 <dne> but the issue is probably in https://git.savannah.gnu.org/cgit/emacs.git/tree/src/callproc.c?h=emacs-27.1#n280
2020-09-16 21:06:29 <dne> which definitely mallocs after (v)fork: https://git.savannah.gnu.org/cgit/emacs.git/tree/src/callproc.c?h=emacs-27.1#n1205
2020-09-16 21:06:48 <ikke> aha, nice find
2020-09-16 21:08:12 <dne> I wonder why it doesn't cause issues on other archs
2020-09-16 21:08:20 <ikke> yeah, me too
2020-09-16 21:09:31 <crosbymichael> is there a way in abuild to specify that a package conflicts with another?
2020-09-16 21:09:44 <maxice8> depends="!pkg"
2020-09-16 21:10:32 <crosbymichael> thanks, nice and clean
2020-09-16 21:16:49 <dne> so if someone could check if !12558 produces a working ppc emacs executable…?
2020-09-16 21:17:54 <ikke> I can check
2020-09-16 21:19:56 <dne> if you can try calling out to an external process too, e.g. M-! and enter shell command
2020-09-16 21:19:57 <ikke> I don't have a desktop environment where I can test it though
2020-09-16 21:20:05 <dne> works in terminal
2020-09-16 21:20:06 <ikke> only ssh access
2020-09-16 21:20:08 <ikke> ok
2020-09-16 21:24:51 <ikke> building it now
2020-09-16 21:52:52 <ikke> dne: seems to work
2020-09-16 22:05:26 <dne> ikke: cool, M-! too?
2020-09-16 22:06:32 <ikke> yes
2020-09-16 22:07:11 <ikke> emacs-27.1-r1
2020-09-16 22:10:34 <dne> nice
2020-09-16 22:12:21 <dne> I've un-WIP:ed the MR
2020-09-16 22:12:43 <ikke> thanks
2020-09-16 22:13:55 <ikke> will be merged after the pipeline goes green again
2020-09-16 22:42:16 <dalias> checking emacs MR, i wanna see what this was :)
2020-09-16 22:44:47 <dalias> wtf how does this fix it??
2020-09-16 22:45:17 <dalias> there has to be something awful behind this...
2020-09-17 04:33:13 <Ariadne> ncopa: mips64 builder is booted, but eth0 is plugged into the wrong thing.  should be available as soon as that is fixed.
2020-09-17 05:03:46 <yjftsjthsd> Sorry, I'm new: Do you have mips64 hardware that you're building on? If so, what hardware?
2020-09-17 05:28:16 <ncopa> morning!
2020-09-17 05:29:39 <ncopa> dalias: i have a backtrace. I suspect the emacs issue is that it is doing something illegal after fork https://tpaste.us/Jxk1
2020-09-17 05:31:20 <ncopa> setrlimit to be specific
2020-09-17 05:39:05 <ncopa> https://github.com/emacs-mirror/emacs/commit/b6d9613df83813609ef80da45975e70954d1fb6d
2020-09-17 05:39:36 <ncopa> due to this: https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-11/msg00212.html
2020-09-17 05:55:04 <dne> dalias: it's a work-around, not a fix :)
2020-09-17 05:56:54 <dne> ncopa: I believe it may also malloc here: https://git.savannah.gnu.org/cgit/emacs.git/tree/src/callproc.c?h=emacs-27.1#n1286
2020-09-17 05:57:19 <dne> but I guess that shouldn't happen during dumping
2020-09-17 06:00:37 <ncopa> i think another work around is to #undef HAVE_SETRLIMIT in src/process.c
2020-09-17 06:11:46 <wener[m]> @Leo please help review this mr https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12381
2020-09-17 06:15:22 <ncopa> I have pushed new edge tag
2020-09-17 06:18:26 <dne> ncopa: have you seen !11627 ?
2020-09-17 06:26:17 <ncopa> LGTM
2020-09-17 06:29:54 <dne> thanks!
2020-09-17 06:33:21 <dne> I'll amend the commit
2020-09-17 06:33:45 <ncopa> great!
2020-09-17 06:44:22 <dne> done
2020-09-17 07:15:35 <ncopa> tyvm!
2020-09-17 07:30:40 <ikke> it is failing
2020-09-17 07:30:57 <ikke> error: assignment of read-only variable '_cgo_r'
2020-09-17 07:31:03 <ikke> cgo-gcc-prolog:1160:12: error: assignment of read-only member 'r'
2020-09-17 07:31:08 <ikke> dne: ^
2020-09-17 07:32:05 <dne> hm, xen?
2020-09-17 07:32:34 <ikke> yes
2020-09-17 07:32:48 <dne> hmm, why did the MR jobs not fail?
2020-09-17 07:32:54 <ikke> beats me
2020-09-17 07:39:43 <ikke> testing it in my lxc container now
2020-09-17 07:43:35 <dne> hm, so it's the go stuff, I don't think that gets built by the MR job
2020-09-17 07:46:08 <dne> "checking for go... go" vs "checking for go... no"
2020-09-17 07:46:26 <ncopa> i think i may have a clue...
2020-09-17 07:46:44 <ikke> In my container it fails with a different error
2020-09-17 07:47:13 <ncopa> yup, i know what happens
2020-09-17 07:47:20 <ikke> ok, nice
2020-09-17 07:47:31 <ncopa> so, there have been a previous build failure
2020-09-17 07:47:46 <ncopa> or deadlock or something
2020-09-17 07:48:05 <ncopa> but the previous build did not clean up the makedepends
2020-09-17 07:48:19 <dne> ah
2020-09-17 07:48:22 <ikke> ah, so go is still installed?
2020-09-17 07:48:26 <ncopa> apk info shows that go is installed
2020-09-17 07:48:29 <ncopa> yup
2020-09-17 07:49:08 <ncopa> fix is to `apk del .make*` and reboot
2020-09-17 07:49:24 <dne> we could add --disable-golang for configure though
2020-09-17 07:49:36 <ncopa> i think that would be a general good idea yes
2020-09-17 07:49:57 <ncopa> but our build servers shouldnt have unexpected dependencies installed
2020-09-17 07:50:07 <dne> 
ACTION nods

2020-09-17 07:50:12 <ncopa> .makedepends-rest-server
2020-09-17 07:50:28 <ncopa> i suppose there was a problem with rest-server at some point
2020-09-17 07:50:53 <ncopa> but really, our building infra needs a refactoring
2020-09-17 07:51:12 <ncopa> we should spin up a clean container for each build, and destroy it after build is done
2020-09-17 07:51:42 <ncopa> we should probably use `abuild rootbld` for now
2020-09-17 07:54:08 <ikke> means the container would need CAP_SYS_ADMIN or something like that to get bubblewrap to work
2020-09-17 07:55:26 <ncopa> yeah... humm. not good
2020-09-17 08:02:01 <dne> no point in bumping pkgrel if I just add --disable-golang, right?
2020-09-17 08:03:49 <afontain_> I've not looked at this specific case, but usually you trigger a rebuild when you change the build flags
2020-09-17 08:06:35 <ikke> Yes, but the current package is already built without go
2020-09-17 08:06:42 <ikke> this is just for future builds
2020-09-17 08:06:46 <dne> right
2020-09-17 08:12:27 <dne> !12559
2020-09-17 08:25:47 <tmhoang> ncopa: regarding clang on s390x, I need to ask around for users
2020-09-17 08:26:24 <tmhoang> I don't hear any problems about that so far
2020-09-17 08:27:57 <ncopa> hi tmhoang! do you know if we could get some help with making rust work on s390x?
2020-09-17 08:30:15 <tmhoang> ncopa: I asked that libunwind supports s390x, but llvm-libunwind didn't back then - there were 2 teams could do it inside ibm but no one had time. llvm-libunwind is the only missing deps for rust on s390x IIRC.
2020-09-17 08:30:29 <tmhoang> I'll try to visit this again today and tmr
2020-09-17 08:31:16 <tmhoang> BUT, last time I was told by Cogitri that I could just bootstrap rust on s390x just fine - still didnt find time neither
2020-09-17 08:31:37 <tmhoang> that's something you want for 3.13  ?
2020-09-17 08:31:55 <ncopa> would be great if we could get it into 3.13
2020-09-17 08:32:00 <tmhoang> OK
2020-09-17 08:32:06 <ncopa> which means we have a couple of weeks
2020-09-17 08:32:21 <ncopa> i will try get the 3.13 builders up in the beginning of october
2020-09-17 08:32:40 <tmhoang> OK thanks for the heads up
2020-09-17 08:38:28 <artok> libunwind on LLVM 12 doesn't have any s390x code
2020-09-17 08:41:57 <Cogitri> I think we patch Rust to work with gcc_eh instead of libunwind
2020-09-17 08:56:16 <tmhoang> artok: that's correct, only libunwind, not llvm-libunwind
2020-09-17 09:02:42 <artok> ah yeah gnu had some IBM peeps working on
2020-09-17 11:14:11 <paper_> is there a way for me to add a label to my MR?
2020-09-17 11:14:42 <ikke> No, I don't think so
2020-09-17 11:16:00 <paper_> ok, nvm
2020-09-17 14:11:43 <PureTryOut[m]> !12319 is ready for merging
2020-09-17 16:22:15 <dalias> ncopa, why is the problem only happening on ppc?
2020-09-17 16:23:06 <dalias> does the ppc build box have the fd limit jacked up?
2020-09-17 16:23:30 <dalias> that's generally a bad idea without heavy audit just because of broken crap using select, which seems to be the underlying emacs issue here they're trying to work around
2020-09-17 16:23:41 <dalias> (i dont see why they don't just fix it to use poll)
2020-09-17 16:24:39 <dalias> it looks like the restore only happens if the initial rlimit exceeded FD_SETSIZE
2020-09-17 16:24:49 <dalias> maybe linux-ppc has some wacky default for it
2020-09-17 16:25:11 <ikke> How can you determine the FD limit?
2020-09-17 16:25:24 <dalias> ulimit -a
2020-09-17 16:25:44 <dalias> open files                      (-n) 1024
2020-09-17 16:26:00 <dalias> -n will just show file limit
2020-09-17 16:26:04 <ikke> open files                      (-n) 16384
2020-09-17 16:26:10 <ikke> so higher than normal
2020-09-17 16:26:13 <dalias> yeah that's the cause
2020-09-17 16:26:38 <dalias> it will make buffer overflow vulns in most programs that use select
2020-09-17 16:26:51 <dalias> (assuming attacker can control initial fd set they inherit, eg suid)
2020-09-17 16:28:18 <dalias> setrlimit should be fixed not to hang in child in musl tho -- it's a common operation ppl want to do between fork and exec and there's no fundamental reason it should break
2020-09-17 16:29:19 <dalias> so i'd like to find out why it's hanging
2020-09-17 16:30:45 <ikke> It's happening when it's trying to call out to git
2020-09-17 16:31:26 <ikke> dne pointed to a line of code he said that did malloc after fork
2020-09-17 16:32:02 <ikke>  dne │ which definitely mallocs after (v)fork: https://git.savannah.gnu.org/cgit/emacs.git/tree/src/callproc.c?h=emacs-27.1#n1205
2020-09-17 16:37:19 <c705> mps: 5.8.10 is out
2020-09-17 16:44:55 <dne> ikke: it's conditional though, and probably not what happened during the build
2020-09-17 16:52:57 <mps> c705: it is nearly ready, just testing build on aarch64
2020-09-17 16:54:15 <mps> (but liqueur preparation take time :) )
2020-09-17 17:07:01 <c705> thanks :)
2020-09-17 17:28:22 <mps> c705: pushed 5.8.10 to builders, will be ready for upgrade in about hour
2020-09-17 17:29:24 <mps> c705: new thing is 'vgacon: remove software scrollback support in 5.8.10'
2020-09-17 18:11:37 <c705> cheers
2020-09-17 18:24:37 <PureTryOut[m]> maxice8: any chance you can merge !12386 and !12229?
2020-09-17 18:44:53 <dalias> ikke, that function does not call malloc after vfork. it uses alloca. malloc is only on msdos.
2020-09-17 18:45:14 <dalias> i see what the problem is tho
2020-09-17 18:45:19 <dalias> it's calling setrlimit after vfork
2020-09-17 18:45:44 <dalias> which is unsafe (along with almost everything else they're doing after vfork)
2020-09-17 18:45:57 <dalias> the right fix is just undefining HAVE_VFORK or whatever so that they use fork
2020-09-17 18:46:26 <ikke> What's the difference?
2020-09-17 18:46:36 <dalias> because it's not 1990 anymore and "eight megabytes and constantly swapping" is no longer constantly swapping and nobody cares if 8MB is double-committed for a few microseconds
2020-09-17 18:47:09 <dalias> between fork and vfork?
2020-09-17 18:47:15 <ikke> yeah, reading about it now
2020-09-17 18:47:26 <ikke> vfork seems to suspend the parent until the child is done?
2020-09-17 18:47:28 <dalias> vfork runs in an extremely unsafe context that's sharing memory with the parent
2020-09-17 18:47:48 <dalias> the only way this works at all is by making the parent suspend until child does execve or _exit
2020-09-17 18:47:56 <ikke> ah, ok
2020-09-17 18:48:44 <dalias> i almost wonder if musl should implement vfork as "try fork, fallback to vfork if it fails with ENOSYS (nommu)"
2020-09-17 18:48:58 <dalias> because pretty much everything using vfork is using it wrong/unsafely
2020-09-17 18:49:06 <dalias> and the only real reason for vfork to exist is nommu
2020-09-17 18:49:23 <ikke> right, because you cannot create a separate address space then?
2020-09-17 18:49:29 <dalias> right
2020-09-17 18:49:54 <dalias> fork semantics are impossible to implement on nommu as long as pointers are actual machine pointers
2020-09-17 18:50:14 <dalias> fork can be done with a complex fat-pointer abi, but nobody does that
2020-09-17 18:50:32 <dalias> anyway here's the problem line: https://git.savannah.gnu.org/cgit/emacs.git/tree/src/callproc.c?h=emacs-27.1#n1352
2020-09-17 18:51:07 <ikke> restore_nofile_limit
2020-09-17 18:52:07 <dalias> *nod*
2020-09-17 18:52:12 <dalias> it happens in the vforked child there
2020-09-17 18:52:30 <dalias> not sure exactly what the mechanism of the hang is. do you know if the parent is multithreaded?
2020-09-17 18:52:54 <ikke> No, not really
2020-09-17 18:53:09 <ikke> I mean, I don't know
2020-09-17 18:54:26 <dalias> it looks like it should just work if it's not..
2020-09-17 18:55:25 <ikke> I can try to build it again without the work-around and see if there are multiple threads
2020-09-17 18:56:54 <dalias> the workaround of disabling HAVE_SETRLIMIT probably makes it so it can buffer overflow
2020-09-17 18:56:58 <dalias> so that should be fixed
2020-09-17 18:57:31 <ikke> No, the workaround was to disable the call to gi
2020-09-17 18:57:33 <ikke> git
2020-09-17 18:57:42 <ikke> on elisp level
2020-09-17 18:58:09 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/emacs/no-git-repo.patch
2020-09-17 18:58:37 <dalias> ahh
2020-09-17 18:58:55 <dalias> ok i can reproduce the hang with a multithreaded parent
2020-09-17 18:59:55 <dalias> changing to fork makes it work
2020-09-17 19:00:04 <dalias> so i think the right fix is getting rid of use of vfork
2020-09-17 19:00:32 <dalias> i could put a workaround for this in musl
2020-09-17 19:00:54 <dalias> actually this might be useful since it affects setuid (dropping elevated root privs, etc) in vfork child too
2020-09-17 19:02:48 <dalias> yep this works
2020-09-17 19:03:05 <dalias> http://ix.io/2xTG
2020-09-17 19:06:22 <dalias> concept here is simple: in vforked child (or child created by [mis]use of clone), self->tid won't be the actual tid of the caller, and best we can do is assume the caller is single-threaded vforked or vfork-like child (since making threads in such a context would be horrible horrible UB that can't be supported)
2020-09-17 19:20:20 <dalias> ikke, http://ix.io/2xTL
2020-09-17 19:21:59 <ikke> aha, so this would make it work with multi-threaded parents?
2020-09-17 19:22:59 <dalias> yes
2020-09-17 19:23:12 <dalias> the change is really simple
2020-09-17 19:23:58 <dalias> just "don't consider the process multithreaded if self->tid is wrong" (meaning that we got a new tid/pid via some mechanism outside libc control)
2020-09-17 19:24:49 <dalias> this makes vfork much safer to use
2020-09-17 19:26:08 <ikke> ok, nice
2020-09-17 19:30:26 <dne> dalias: AFAICT, it does (conditionally) malloc in child_setup, e.g. this may (indirectly) malloc: https://git.savannah.gnu.org/cgit/emacs.git/tree/src/callproc.c?h=emacs-27.1#n1292
2020-09-17 19:37:12 <dalias> dne, which function calls malloc there?
2020-09-17 19:37:35 <dalias> if it mallocs in a vforked child, even if that doesn't blow up, it leaks memory in the parent each time...
2020-09-17 19:37:45 <dalias> but i don't see a malloc
2020-09-17 19:38:04 <dalias> it looks like it just reads data and updates a count to pass to alloca
2020-09-17 19:41:51 <ikke> dalias: I can confirm the parent is multithreaded
2020-09-17 19:44:49 <ikke> https://tpaste.us/V4N1
2020-09-17 19:59:23 <PureTryOut[m]> Could anyone merge !12386? I'm kinda waiting on it for something else
2020-09-17 19:59:51 <maxice8> I'm in the process of merging it
2020-09-17 20:00:03 <maxice8> It is a massive MR
2020-09-17 20:05:03 <dalias> ikke, i think this'll fix it then
2020-09-17 20:05:04 <dne> dalias: e.g. build_string->make_string->make_{uni,multi}byte_string->make_uninit_multibyte_string->allocate_string->... etc.
2020-09-17 20:05:15 <dalias> ikke, nm mcf just confirmed it :)
2020-09-17 20:07:16 <mps> would someone look at !12466 and tell is the 'replaces' and 'provides' ok, please
2020-09-17 20:15:18 <PureTryOut[m]> maxice8: ah cool thanks!
2020-09-17 20:41:02 <arco_> Hi, I'm working on a package and I would like to NOT produce $pkgname.apk - the whole contents was splitted into subpackages. Is it possible?
2020-09-17 20:46:05 <maxice8> No, you can make an empty mainpkg though
2020-09-17 20:46:08 <maxice8> mkdir "$pkgdir"
2020-09-17 20:46:22 <arco_> Yes, it's empty after all the subpackages are built
2020-09-17 20:50:55 <maxice8> yes, unfortunately you can't get rid of it
2020-09-17 20:56:50 <maxice8> @PureTryOut kiconthemes is failing
2020-09-17 20:57:27 <PureTryOut[m]> Yeah I noticed, just disable the test for now. It failed once on CI as well but passed another time, it's too flaky
2020-09-17 20:57:39 <PureTryOut[m]> (just disable that specific test please)
2020-09-17 20:57:43 <maxice8> ok
2020-09-17 20:58:59 <maxice8> done
2020-09-18 05:36:43 <ncopa> morning!
2020-09-18 05:37:11 <ncopa> nice work on that emacs thing. yes. it seems like ppc64le has different default for nofiles
2020-09-18 05:56:20 <mps> morning!
2020-09-18 05:57:14 <mps> ncopa: you were right about mdev and hwdrivers init scripts, now all works fine with libudev-zero instead of eudev
2020-09-18 05:58:18 <mps> only left to test if enabling mdev -d option makes sense or not
2020-09-18 05:59:09 <mps> or use mdevd instead of mdev
2020-09-18 06:01:13 <mps> what keeps binutils at 2.24 version and not upgrading to 2.25
2020-09-18 06:43:26 <Cogitri> mps: That someone has to test the MR for it
2020-09-18 06:47:07 <mps> Cogitri: I did on armv7 about 10 days ago
2020-09-18 06:48:02 <Cogitri> Yes, but I think we need to test it on all arches
2020-09-18 06:48:43 <mps> test it is working or test it builds?
2020-09-18 07:00:15 <Cogitri> The former
2020-09-18 07:00:53 <Cogitri> CI can do the latter already, but I think some versions ago we had a binutils upgrade that broke linking with bfd on aarch64 or smth like that
2020-09-18 14:44:33 <jonjons> I noticed that /etc/profile looks for additional configs in profile.d ending with .sh yet the default files in profile.d do not have the .sh extension. should this be reported as a bug?
2020-09-18 14:51:23 <Hello71> they are off by default
2020-09-18 14:56:15 <jonjons> I was wondering if it was intentional
2020-09-18 14:56:19 <jonjons> thank you
2020-09-18 15:01:50 <dalias> uhg, i have some that are on by default (gawk.sh)
2020-09-18 15:01:56 <dalias> is that a bug in the package that dropped them in?
2020-09-18 15:02:21 <dalias> eew also vte.sh
2020-09-18 15:03:25 <dalias> eew eeew eew it sets a PROMPT_COMMAND
2020-09-18 15:05:39 <jonjons> the /etc/profile sets the PS1 var if that's what you mean, but be default the /etc/profile.d file does nothing. their a file that sets the PS1 differently in profile.d
2020-09-18 15:05:44 <mps> dalias: there is gawk.csh also
2020-09-18 15:06:22 <Hello71> well... I specifically meant *those* are off by default
2020-09-18 15:07:01 <dalias> PS1 is the right thing. PROMPT_COMMAND is evil that forks and execs crap every time you press enter and it's doing all sorts of unsafe variable handling
2020-09-18 15:07:13 <dalias> i wouldn't be surprised if you could make it blow up and do bad things by setting PWD or HOME bad
2020-09-18 15:07:17 <mps> well, /etc/profile.d.sh and /etc/profile.d.bash ....
2020-09-18 15:07:34 <dalias> i just killed the code in /etc/profile to run profile.d files
2020-09-18 15:07:41 <dalias> they're all unwanted crap
2020-09-18 15:08:03 <mps> good idea
2020-09-18 15:08:18 <dalias> but this should probably be fixed in the packages doing it
2020-09-18 15:08:24 <mps> users (even root) should have these things in HOME
2020-09-18 15:08:29 <dalias> there's no reason installing vte should change what your shell does at login
2020-09-18 15:09:52 <dalias> that violates the principle i thought alpine had right that packages are presence of software, not systemwide configuration changes
2020-09-18 15:10:19 <dalias> (and even if policy allows both, they should be fully factored so one doesn't imply the other)
2020-09-18 15:10:21 <Hello71> dalias: you can go complain about the cloud-init mr then
2020-09-18 15:10:32 <dalias> ?
2020-09-18 15:10:40 <Hello71> installing cloud-init automatically enables init scripts
2020-09-18 15:11:03 <dalias> can you go into more detail?
2020-09-18 15:11:09 <Hello71> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12247
2020-09-18 15:11:20 <dalias> it causes stuff to get run *without making a configuration change to use cloud-init* ?
2020-09-18 15:11:27 <Hello71> it was discussed here at the time
2020-09-18 15:11:38 <Hello71> not sure exactly how it works in practice
2020-09-18 15:11:58 <Hello71> but imo even if it does work that way I think it is a bad system
2020-09-18 15:12:25 <Hello71> similar to transitional debian system where some services were set by /etc/default, some by /etc/rc.d, some by systemctl
2020-09-18 15:13:12 <Hello71> so you check systemctl status and it says "enabled" but nothing is running because /etc/default/myservice has ENABLED=false or somesuch
2020-09-18 15:13:15 <dalias> hello71, done
2020-09-18 15:13:50 <Hello71> Ariadne: ^
2020-09-18 15:14:44 <Ariadne> cloud-init is a special case.  it is useless without the init scripts being enabled.
2020-09-18 15:15:06 <dalias> how so
2020-09-18 15:15:06 <Hello71> doesn't that apply to other packages too
2020-09-18 15:15:13 <dalias> someone could want to run it in a namespace
2020-09-18 15:15:23 <dalias> rather than changing their system config just because they installed a package
2020-09-18 15:15:30 <Hello71> "apache is useless without init scripts", "nginx is useless without init scripts", etc
2020-09-18 15:15:32 <Ariadne> the purpose of cloud-init is to run on the target
2020-09-18 15:15:42 <Ariadne> as a firstrun
2020-09-18 15:15:54 <Ariadne> it is not the same as apache or nginx
2020-09-18 15:16:04 <dalias> and you might install it specifically to run *as the first run in a user+pid namespace*
2020-09-18 15:16:08 <dalias> that you run with unshare(1)
2020-09-18 15:16:15 <skarnet> cloud-init is tricky because it has to run during the boot scripts at several times
2020-09-18 15:16:21 <dalias> and appropriate bind mounts etc
2020-09-18 15:16:22 <Ariadne> ^
2020-09-18 15:16:23 <skarnet> including one after everything else has run
2020-09-18 15:16:35 <skarnet> which is a pain to modelize in a service manager
2020-09-18 15:16:47 <Ariadne> like I said it's special
2020-09-18 15:16:55 <Ariadne> that's why we allowed it
2020-09-18 15:17:04 <Hello71> we?
2020-09-18 15:17:13 <dalias> then you just add one more thing: a script shipped with it that you run *if you want to*, *possibly in a namespace*, after installing the package
2020-09-18 15:17:23 <dalias> rather than violating the principle that packages don't fuck up your system config
2020-09-18 15:17:40 <dalias> this principle is seriously one of the main good things about alpine
2020-09-18 15:17:44 <Ariadne> open a bug and request the core team review it
2020-09-18 15:18:00 <Cogitri> dalias: those vte scripts are required so users of vte have functionality like new tabs being opened in $PWD
2020-09-18 15:18:13 <Ariadne> I'm not arguing over irc about this, I've spent the past 6 hours basically sitting on the toilet due to food poisoning
2020-09-18 15:18:30 <Ariadne> so I am not in any condition to debate it at the moment
2020-09-18 15:18:39 <Hello71> Cogitri: can't vte export an environment variable at least
2020-09-18 15:18:43 <Ariadne> but it is an atypical use case
2020-09-18 15:18:56 <Ariadne> I will just leave it at that
2020-09-18 15:19:04 <skarnet> +
2020-09-18 15:19:08 <skarnet> mt
2020-09-18 15:19:21 <Hello71> and why can't vte do it like tmux
2020-09-18 15:19:42 <dalias> cogitri, doesn't matter what the reason is. if users want it they can configure it
2020-09-18 15:19:56 <Ariadne> again open bugs about these things instead of aggressively questioning people on irc.  thanks
2020-09-18 15:19:59 <dalias> or there can be a vte-bash-profile package
2020-09-18 15:20:06 <Hello71> i'm not sure about cloud-init, but i'm with dalias on the vte
2020-09-18 15:20:08 <dalias> ariadne, i am
2020-09-18 15:20:24 <dalias> for example if some crap i install pulls in vte (which i never intend to use)
2020-09-18 15:20:33 <dalias> i don't want that changing my PROMPT_COMMAND for xterm (which i do use)
2020-09-18 15:20:40 <Hello71> or ssh
2020-09-18 15:20:45 <Ariadne> it is best to discuss on the tracker anyway so we have a permanent copy of the discussion
2020-09-18 15:20:48 <Cogitri> It's based functionality in VTE, so if you don't want it don't install VTE or delete it?
2020-09-18 15:20:48 <dalias> and i wouldn't want it changing my PROMPT_COMMAND when i was logged in from vte *on a remote system*
2020-09-18 15:20:53 <Ariadne> irc logs tend to not be reliable for that
2020-09-18 15:20:56 <Cogitri> s/based/base/
2020-09-18 15:20:57 <alpine-meetbot> Cogitri meant to say: It's base functionality in VTE, so if you don't want it don't install VTE or delete it?
2020-09-18 15:21:10 <Cogitri> (it being the profile file)
2020-09-18 15:21:19 <dalias> cogitri, it's not base functionality of vte. it's changing behavior of packages completely unrelated to vte
2020-09-18 15:21:39 <Ariadne> I'm confused about why vte requires anything in profile.d, I admit
2020-09-18 15:21:54 <dalias> with the goal of improving their interoperation with vte, but that's irrelevant because i may not even want to use vte
2020-09-18 15:22:01 <Ariadne> I thought it was just a terminal emulation package
2020-09-18 15:22:04 <dalias> (maybe it got pulled in as a dep for something, or maybe some other user on my box wants it)
2020-09-18 15:22:19 <Ariadne> we don't have a profile.d for konsole or xterm
2020-09-18 15:22:35 <dalias> the whole core point is that pulling in a package should not change the configuration for another package/part of the system
2020-09-18 15:23:10 <Hello71> (or tmux, which also has this feature of "new tabs being opened in $PWD")
2020-09-18 15:23:18 <Cogitri> Ariadne: copying an earlier msh of line: "those vte scripts are required so users of vte have functionality like new tabs being opened in $PWD"
2020-09-18 15:23:46 <Ariadne> i'm confused.  can't vte just call chdir(2) prior to execve the shell
2020-09-18 15:23:49 <dalias> also, why would i want new tabs being opened at PWD (pulling information out a shell running on the terminal)
2020-09-18 15:23:57 <Ariadne> that is what konsole does
2020-09-18 15:24:04 <Ariadne> if you enable that feature
2020-09-18 15:24:08 <Cogitri> I think then you should open an issue upstream that they should export an env variable or something so that we can have this profiled script only in Vte
2020-09-18 15:24:11 <dalias> ariadne, the idea is that the profile script programs the shell to export the PWD to the terminal via terminal escapes
2020-09-18 15:24:23 <dalias> so that the terminal knows what the shell's PWD is and can use tht information
2020-09-18 15:24:39 <dalias> otherwise the shell's PWD (and even the fact that there is a shell) is unknown to the terminal emulator
2020-09-18 15:25:00 <Ariadne> dalias: this sounds like atrociously bad design -- like i said, konsole is able to do this just by monitoring the child process
2020-09-18 15:25:02 <Cogitri> But let's not break the setup of users which expect this functionality to work because they didn't know about this some random subpackage
2020-09-18 15:25:16 <dalias> ariadne, "monitoring the child process" is atrociously bad design
2020-09-18 15:25:25 <Hello71> does this even work properly with ssh? does it automagically check SSH_CONNECTION or something?
2020-09-18 15:25:34 <dalias> and obviously would not work across su, ssh to localhost, etc.
2020-09-18 15:25:48 <Hello71> or does it open a new tab using the remote current directory
2020-09-18 15:25:57 <Ariadne> dalias: sure, i guess what i am saying is pick your poison regarding which design is more atrocious :)
2020-09-18 15:26:00 <dalias> it wouldn't even work with a shell that didn't actually change its PWD but instead just used a fd and at functions
2020-09-18 15:26:09 <dalias> ariadne, the one you proposed is far, far worse
2020-09-18 15:26:11 <Ariadne> Hello71: it knows when a tab is running ssh yes
2020-09-18 15:26:31 <dalias> it's poking at implementation internals of an unknown process rather than communicating with an agreed-upon protocol
2020-09-18 15:26:44 <Ariadne> it's not.  the process has its CWD in /proc filesystem
2020-09-18 15:26:53 <dalias> that doesn't tell you anything
2020-09-18 15:26:59 <dalias> it's an implementation internal
2020-09-18 15:27:05 <Ariadne> well, that is the one konsole uses :)
2020-09-18 15:27:23 <dalias> there's no reason a shell can't (and good reason it should) just chdir to / and use file descriptors and at functions for working directory
2020-09-18 15:27:36 <dalias> it lets you optimize out some subshells, etc.
2020-09-18 15:28:04 <Ariadne> sure
2020-09-18 15:28:10 <Hello71> except portability to older systems
2020-09-18 15:28:15 <dalias> external commands spawned from the shell need to see the "logical pwd" as their working dir when they start
2020-09-18 15:28:27 <Ariadne> apk does this for similar reasons (well, we do it using openat(2), but thats beside the point)
2020-09-18 15:28:31 <dalias> but the shell can implement the logical pwd within the shell any way it wants
2020-09-18 15:28:44 <dalias> poking at another process's /proc entry is horrible horrible behavior
2020-09-18 15:28:56 <Hello71> isn't that the point of /proc
2020-09-18 15:29:02 <Ariadne> it's kde.  most of the product is horrible behavior
2020-09-18 15:29:18 <dalias> the point of proc was historically implementing ps(1)
2020-09-18 15:29:19 <mps> :)
2020-09-18 15:29:25 <Hello71> or are you on the side of *bsd where /proc is basically useless
2020-09-18 15:29:26 <dalias> and similar tools like top
2020-09-18 15:29:37 <dalias> not programmatically poking at other processes
2020-09-18 15:29:53 <Ariadne> i only use kde because it manages to be the least annoying.
2020-09-18 15:30:12 <dalias> nowadays it's also accessing some of *your own* process state that should be exposed (because that's not poking at another unknown process) but that linux doesn't have any good interfaces to expose
2020-09-18 15:30:17 <Ariadne> do not consider my use an endorsement of how they make their sausage though
2020-09-18 15:30:20 <dalias> :)
2020-09-18 15:30:46 <Ariadne> on another topic, is it ethical to chargeback on grubhub for delivering tainted food?
2020-09-18 15:30:57 <Ariadne> because my morning has been highly unpleasant
2020-09-18 15:31:38 <Ariadne> (i'm not actually planning to do so.  but... i have to say, the idea is tempting.)
2020-09-18 15:32:11 <mps> alpine in last time tries to be 'user friendly' and to be similar with other big distros, which is not good path imo
2020-09-18 15:34:05 <Ariadne> i have no objection to user friendliness as long as execution is done competently.
2020-09-18 15:34:37 <Ariadne> cloud-init is certainly worth discussion, but the intention of the package is that you install it into the target image.  and in that scenario, it is completely useless if the init scripts are not configured.
2020-09-18 15:34:40 <mps> problem is to have common definition of 'user friendly'
2020-09-18 15:35:05 <mps> I'm user of alpine linux, also
2020-09-18 15:35:08 <Ariadne> you would not use cloud-init in a namespace.  that namespace would contain its own image.
2020-09-18 15:35:47 <Ariadne> if you're doing weird stuff like forking your rootfs into a new namespace, well, you would not use cloud-init anyway, because you know what you're doing already.
2020-09-18 15:35:56 <Ariadne> that's basically my opinion on cloud-init
2020-09-18 15:36:16 <Ariadne> and why i accepted that package.  but we can always ask core team to make a decision on whether or not its kosher.
2020-09-18 15:36:26 <mps> I remember discussion about cloud-init, but managed to resist not to be involved
2020-09-18 15:37:06 <mps> hmm, my bad english, managed to not involve self
2020-09-18 15:37:08 <Ariadne> i don't really have a dog in this fight -- i don't use cloud-init, but i did understand the maintainer's argument for why adding the init scripts by default made sense.  any image you build will have to have them added anyway for cloud-init to work at all.
2020-09-18 15:38:14 <Ariadne> i think skarnet mentioned that in other words, basically.  cloud-init cannot be used on its own, it works in concert with the service manager.
2020-09-18 15:38:26 <mps> and, tbh not sure is it good or bad, but it should be written somewhere if we can make exceptions in some special cases
2020-09-18 15:38:33 <Ariadne> (personally i find the whole concept of cloud-init flawed)
2020-09-18 15:40:27 <Ariadne> but just because i wouldn't solve that scenario in the way cloud-init does, doesn't mean we shouldn't package it and have the package work in line with expectations on other systems
2020-09-18 15:40:29 <Ariadne> :)
2020-09-18 15:42:13 <Ariadne> either way -- if you want core team to make a decision on it, it seems reasonable enough to me.  all somebody needs to do is open a bug requesting that decision be made.
2020-09-18 15:42:31 <Ariadne> i am sure that the maintainer will abide by that decision :)
2020-09-18 15:42:42 <mps> hmm, hmmm, looks like we reached to crossroad and have to consider do we want small, simple or something else
2020-09-18 15:43:21 <Ariadne> regarding cloud-init, whether or not the current situation is "simple" is subjective
2020-09-18 15:43:31 <mps> one (or few) particular packages are not problem imo
2020-09-18 15:43:37 <dalias> mps, i agree alpine has started copying bad idioms of other distros as a lazy path
2020-09-18 15:43:47 <dalias> which defeats a lot of the purpose of why i liked it to begin with
2020-09-18 15:43:54 <Ariadne> ifupdown-ng better not be one of those idioms :(
2020-09-18 15:44:02 <Ariadne> we even use posix_spawn()!
2020-09-18 15:44:21 <dalias> ariadne, i'm not thinking of it and haven't followed the discussion of it
2020-09-18 15:45:05 <dalias> i'm thinking more about things like the issue here (packages mixing software and policy), unwanted dependencies on stuff that should be optional, etc.
2020-09-18 15:45:19 <dalias> yay posix_spawn! :)
2020-09-18 15:45:22 <Ariadne> i agree that some packages are heavier than they need be
2020-09-18 15:45:49 <dalias> also some are lighter (like the cyrus sasl mess :-p)
2020-09-18 15:45:55 <Ariadne> i fixed that
2020-09-18 15:45:59 <dalias> yay!
2020-09-18 15:46:26 <Cogitri> The problem is that we don't have a good way to express optional deps right now
2020-09-18 15:46:36 <mps> dalias: yes, dependency hell and set everything for user/admin was which forced me to switch from debian after 18 years
2020-09-18 15:47:05 <Cogitri> It's either barebones and letting the user guess/hope they find some obscure wiki pages or have something that works by default but may pull in a package or two more than required for base functionality
2020-09-18 15:47:14 <Ariadne> although i think that was not meant to be harmful.  just somebody who was trying to lighten packages without knowing much about SASL or that SASL PLAIN is a required mechanism for any SASL implementation
2020-09-18 15:47:14 <mps> Cogitri: simple, minimum deps ;)
2020-09-18 15:47:46 <Ariadne> but needless to say, if you install something that pulls in cyrus-sasl, the SASL PLAIN plugin now comes with it
2020-09-18 15:47:53 <Ariadne> so you're not going to sit around going "wtf"
2020-09-18 15:49:00 <mps> Ariadne: that was my experience at begining :)
2020-09-18 15:51:43 <mps> and, btw, IRC is ok for discussion even serious things, not all read all issue/bug reports and MRs
2020-09-18 15:52:00 <dalias> ariadne, well what should have happened, the existing package should have been made into a virtual package for the cyrus-sasl base plus all the plugins that were previously included in the main package
2020-09-18 15:52:12 <Ariadne> dalias: yes, i agree
2020-09-18 15:52:15 <Cogitri> It is way easier to access after the fact tho
2020-09-18 15:52:19 <Ariadne> dalias: at least for SASL PLAIN :)
2020-09-18 15:52:21 <dalias> and then users who wanted to trim-down could remove the virtual package and just keep the base package and ones they wanted
2020-09-18 15:52:37 <dalias> but upgrading packages should not have broken anyone's mail
2020-09-18 15:52:39 <Cogitri> IMHO at least a summary of what is planned to be done should be mentioned in an issue before we work on it
2020-09-18 15:52:59 <Cogitri> So we know why things were done the way they were done later on
2020-09-18 15:53:06 <Ariadne> dalias: for me it was my connection to the XMPP server, but yes :)
2020-09-18 15:54:15 <Ariadne> 99% of SASL use is SASL PLAIN anyhow
2020-09-18 15:54:24 <Ariadne> i am not sure why SASL PLAIN is a plugin in cyrus-sasl
2020-09-18 15:54:36 <Ariadne> but i don't really think cyrus-sasl is a good library anyway
2020-09-18 15:55:40 <dalias> it's an awful library
2020-09-18 15:56:13 <Ariadne> at any rate the goal of myself (and others working with me) is to identify areas of alpine that are bad and come up with solutions
2020-09-18 15:56:41 <Ariadne> and when we get more revenue, hire additional contributors to work on solving those bad spots
2020-09-18 15:57:03 <Ariadne> alas sustainability and capitalism is a complicated dance
2020-09-18 15:57:47 <dalias> more companies using alpine should really be sponsoring it
2020-09-18 15:57:58 <dalias> there have got to be TONS who aren't
2020-09-18 15:58:15 <Ariadne> yes, it's basically just us and mirantis that seem to be trying to sponsor dev work
2020-09-18 15:58:21 <Ariadne> pretty sad, really
2020-09-18 16:00:40 <Ariadne> and, ensuring the underlying project powering huge parts of your ecosystem is just good business really
2020-09-18 16:00:53 <Ariadne> er, is healthy, is just good business really
2020-09-18 16:01:11 <Ariadne> oh well, must be why i'm not a billionaire
2020-09-18 16:02:11 <dalias> :-p
2020-09-18 16:03:22 <Ariadne> oh well, now that i don't have to jump up and run to the bathroom every 2 minutes, maybe i can start doing actual work today
2020-09-18 16:03:24 <mps> aren't we working for pleasure and not for money
2020-09-18 16:03:35 <Ariadne> mps: why not both?
2020-09-18 16:03:42 <Hello71> I wonder if we could add "do you want man pages" to setup-alpine
2020-09-18 16:03:59 <mps> usually they don't go well together
2020-09-18 16:04:08 <mps> that is my experience
2020-09-18 16:04:21 <Ariadne> depends on what you're mixing :)
2020-09-18 16:04:34 <Hello71> Ariadne: usually the cause of foodborne illness is not the last thing you ate
2020-09-18 16:04:42 <Ariadne> Hello71: yeah, i know :)
2020-09-18 16:04:43 <Hello71> incubation time is a thing
2020-09-18 16:05:50 <Ariadne> mps: from personal experience, i can say that what i am doing now is a lot less stressful and more enjoyable than previous endeavors
2020-09-18 16:07:38 <Ariadne> for one, i do not have to deal with transphobia on a daily basis :)
2020-09-18 16:08:20 <mps> understand, we all have some personal characters and that is normal
2020-09-18 16:08:20 <yjftsjthsd> Actually, is there a way to set apk to automatically install foo-doc when you install foo? I appreciate having the packages separate, but it's a bit of a pain to have to install both every time
2020-09-18 16:08:29 <maxice8> apk add docs
2020-09-18 16:09:34 <mps> (if the mind can be bought on the marked everyone will buy their own)
2020-09-18 16:09:42 <mps> market*
2020-09-18 16:10:43 <yjftsjthsd> maxice8 thank you, that's amazing
2020-09-18 16:10:55 <Ariadne> mps: well, at previous gig, the boss said that transphobia deserves an equal spot at the table.  sooooooo :)
2020-09-18 16:11:13 <Ariadne> sure love 2 work in free software for a living
2020-09-18 16:12:09 <yjftsjthsd> Wait how does that work? I expected some dependency magic but https://git.alpinelinux.org/aports/tree/main/docs/APKBUILD is all-but empty. Is there some magic hardcoded in apk itself based on the presence of that package?
2020-09-18 16:12:17 <Ariadne> install_if rules
2020-09-18 16:12:24 <Hello71> it goes backwards
2020-09-18 16:12:34 <maxice8> install_if="$pkgname=$pkgver-r$pkgrel docs"
2020-09-18 16:12:43 <Ariadne> install_if is basically recommends-done-right
2020-09-18 16:12:44 <Ariadne> imo
2020-09-18 16:12:45 <Ariadne> but
2020-09-18 16:12:51 <maxice8> if you install `docs` then you trigger that rule for every -docs package
2020-09-18 16:12:53 <Ariadne> now we will have recommends, too
2020-09-18 16:12:55 <Ariadne> :/
2020-09-18 16:15:31 <yjftsjthsd> Oh, I see. That's clever; very nice.
2020-09-18 16:18:51 <yjftsjthsd> Is that documented anywhere? Searching "docs" in the wiki doesn't show anything, and it's not something that a person would stumble over easily
2020-09-18 16:19:16 <Hello71> probably not
2020-09-18 16:19:34 <Hello71> it might be on docs.ao
2020-09-18 16:19:42 <mps> apk info docs
2020-09-18 16:20:01 <Hello71> I assumed yjftsjthsd meant "how to install man pages" broadly
2020-09-18 16:20:06 <mps> Meta package for pulling in all documentation
2020-09-18 16:21:11 <Hello71> it also doesn't say "man pages", but I think apk search can't search description anyways
2020-09-18 16:21:51 <yjftsjthsd> I guess what I mean to be asking is: If a new user starts using Alpine (say, downloads and installs on a laptop), how would that user find out that `apk add docs` automatically pulls all *-docs packages?
2020-09-18 16:22:03 <yjftsjthsd> Also, docs.alpinelinux.org is news to me; why is that not just a section in the wiki?
2020-09-18 16:22:16 <Hello71> well I proposed earlier that setup-alpine could suggest it
2020-09-18 16:22:28 <yjftsjthsd> That would be another solution, certainly
2020-09-18 16:24:44 <mps> 'docs' description should be changed to 'Meta package for pulling in documentation for installed packages'
2020-09-18 16:25:19 <mps> Hello71: that should be described on 'doc.a.o'
2020-09-18 16:25:23 <Hello71> unfortunately docs continues to be a weak point on alpine. docs.a.o was planned to be a more curated repository (small wiki tends to get filled with bad info) but I don't think anyone is working on it atm
2020-09-18 16:25:36 <mps> setup-alpine shouldn't be 'user guide'
2020-09-18 16:26:09 <Hello71> sure, but it asks things like sshd
2020-09-18 16:26:25 <mps> yes, alpine weak point is nearly no documentation
2020-09-18 16:27:09 <Hello71> I think it would be a little excessive if setup-alpine asked about e.g. gnome or kde or x11, but imo it would be reasonable to ask about man pages
2020-09-18 16:27:18 <Hello71> but I don't feel strongly about it
2020-09-18 16:33:36 <Ariadne> would be better to have something like debian tasksel for that
2020-09-18 16:33:44 <Ariadne> with setup-alpine asking if you want to run tasksel
2020-09-18 16:36:56 <yjftsjthsd> The wiki does have guides like https://wiki.alpinelinux.org/wiki/Xfce_Setup that loosely talk through "installed base alpine system" to "working usable workstation"; this feels like it would fit in there nicely but then it gets scattered (honestly, I feel like the whole thing should get refactored)
2020-09-18 16:37:36 <yjftsjthsd> I personally question the value of having another set of docs; if there aren't enough people to maintain the wiki, why would they be able to maintain a more curated selection?
2020-09-18 16:39:14 <Hello71> I think the theory is that it's hard to curate a continuous stream of contributions
2020-09-18 16:39:26 <mps> yes
2020-09-18 16:40:44 <mps> I have some half finished things but didn't put on wiki because wiki system is cumbersome to me
2020-09-18 16:43:12 <yjftsjthsd> That's fair. Are there other projects that are doing this better? Arch is famous for their wiki; is their tooling better, or do they just have more users pushing it forward? BSDs are famous for their manpages, but IDK if that's the same deal.
2020-09-18 16:43:51 <Hello71> mostly more users. BSD man pages aren't even that good, they're mostly just slightly better in some cases where Linux is terrible (e.g. basic networking setup)
2020-09-18 16:44:42 <yjftsjthsd> Heh. "We suck but everyone else sucks more" is a surprisingly effective approach.
2020-09-18 16:44:44 <Hello71> debian wiki has excellent pockets but is mostly horribly out of date
2020-09-18 16:44:56 <detha> imo openbsd man pages are an order of magnitude better, but they require actual reading, not skimming
2020-09-18 16:46:24 <yjftsjthsd> I had a notion once that docs should be done in jupyter notebooks or something, where commands in the docs would actually get run in a container. So when a new OS version changed things and the docs didn't work, it would flag as a failing test. Of course that still needs someone to fix things, but it at least would prevent silently non-working docs
2020-09-18 16:46:50 <yjftsjthsd> Of course, this was also a daydream and not something I implemented, so don't take me too seriously;)
2020-09-18 16:46:54 <Hello71> rust has "doctests" which are similar to this concept
2020-09-18 16:47:15 <Hello71> I don't think anybody has done this for a Linux distro
2020-09-18 16:47:43 <mps> MartijnBraam: what you think of this for linux-edge https://tpaste.us/mEYJ
2020-09-18 16:50:51 <MartijnBraam> On theory it's great, but I haven't managed to get display working yet with my own build of Linux edge with those changes
2020-09-18 16:53:40 <mps> hmm, ok. I will push it anyway, just tell me if your name properly written in commit msg
2020-09-18 16:54:14 <PureTryOut[m]> *Martijn Braam, double A
2020-09-18 16:54:23 <MartijnBraam> ^
2020-09-18 16:54:27 <mps> ah, I see, thanks
2020-09-18 16:59:45 <mps> it is on builders
2020-09-18 17:04:51 <mps> can someone look at prometeus fail on aarch64
2020-09-18 17:05:04 <mps> https://build.alpinelinux.org/buildlogs/build-edge-aarch64/community/prometheus/prometheus-2.21.0-r1.log
2020-09-18 17:05:45 <mps> it blocks builder
2020-09-18 18:36:58 <PureTryOut[m]> CI goes OOM constantly on !12581, but it compiles fine otherwise (x86 actually succeeded), can it be merged? The upgrade to 5.15.1 crippled it functionality and packages depending on it won't upgrade, and this restores it
2020-09-18 19:00:40 <PureTryOut[m]> Thanks!
2020-09-19 06:25:44 <insep_> anyone here with armv7 machine running alpine? i tried to run 'rc-status' without any args and for some reason it segfaulted on me right after outputing "Runlevel: default" :\
2020-09-19 06:31:58 <mps> insep_: which alpine release
2020-09-19 06:32:08 <insep_> edge
2020-09-19 06:34:56 <mps> I can tell only for lxc guest, it doesn't segfault
2020-09-19 06:35:28 <mps> right now I don't have any native armv7 edge installed
2020-09-19 07:11:39 <Cogitri> insep_: That's on a fully upgraded machine?
2020-09-19 07:12:58 <insep_> probably, i've generated that image like an hour ago
2020-09-19 12:24:57 <minimal> can anyone point me to a Alpine packaging policy document?
2020-09-19 12:25:31 <mps> minimal: CODINGSTYLE.md in aports
2020-09-19 12:25:45 <mps> that's all we have
2020-09-19 12:26:00 <mps> maybe man APKBUILD
2020-09-19 12:26:00 <maxice8> There are some separate articles in the wiki too
2020-09-19 12:26:28 <mps> maxice8: yes, but nothing is 'policy'
2020-09-19 12:27:50 <mps> actually we don't have official packaging policy document
2020-09-19 12:27:59 <minimal> mps: that's basically what I thought, however I've had a comment added to a MR (that was merged 1 week ago) by someone saying "This should be reverted. Packages are not supposed to change policy."
2020-09-19 12:28:23 <maxice8> Sounds like a different policy
2020-09-19 12:29:04 <mps> minimal: which one, MR number
2020-09-19 12:29:30 <minimal> @mps: !12247
2020-09-19 12:29:41 <mps> heh
2020-09-19 12:29:47 <maxice8> oh, cloud-init is the exception to the rule because of how it is meant to be used
2020-09-19 12:29:49 <maxice8> as far as I know
2020-09-19 12:29:54 <mps> we discussed this yesterday here
2020-09-19 12:29:55 <insep_> insep: so i had this issue in history, seems like it fails to read some script? https://github.com/OpenRC/openrc/issues/168
2020-09-19 12:30:55 <mps> minimal: please look at IRC log at irclogs.a.o of #alpine-devel, yesterday
2020-09-19 12:31:25 <insep_> rc-status command to show failed services shows only chronyd and this is the first in alphabetical order that i assume i have
2020-09-19 12:31:26 <minimal> @mps: I'll check the irc logs for yesyerday. Thing is regarding "exception to the rule" implies that there are rules, i.e. policy, hence my question about policy doc
2020-09-19 12:32:05 <minimal> mps: oops, meant that for maxice8
2020-09-19 12:32:57 <mps> minimal: yes and no, we don't have written policy but something as 'best practice' or accommodated practice
2020-09-19 12:36:19 <minimal> mps: right. I made that change knowing that it was going against typical practice as cloud-init is not a typical package
2020-09-19 12:36:46 <mps> minimal: yes, I remember
2020-09-19 12:37:12 <minimal> mps: so I've added a reply comment to the MR but really I don't know where this is going...
2020-09-19 12:37:21 <mps> I'm not sure for this case, maybe it should be exception
2020-09-19 12:37:44 <Ariadne> it should be exception, that's why i allowed it
2020-09-19 12:37:53 <minimal> mps: ok but when are exceptions defined so that I can point someone to the agreed exception then?
2020-09-19 12:37:59 <Ariadne> but again, we can ask core team to make a decision.  they will 99% most likely agree with my reasoning.
2020-09-19 12:38:10 <mps> imo, we shouldn't be rigid but also not 'soft'
2020-09-19 12:38:38 <minimal> basically will I have to potentiallu defend my change from now onwards with nothing to back it up?
2020-09-19 12:38:51 <Ariadne> if core team makes a decision you can point to that.
2020-09-19 12:39:16 <minimal> is there an agreed way to refer something to the core team for a decision?
2020-09-19 12:39:17 <Ariadne> as i said, i allowed it on the grounds that anyone installing the package would have to make those adjustments to their image anyway.
2020-09-19 12:39:40 <mps> minimal: I don't see this as war and that you have to defend it, explanation why it must be enabled is good
2020-09-19 12:40:13 <minimal> Ariadne: yes, thanks for that.
2020-09-19 12:40:41 <Ariadne> sec, i will do it.
2020-09-19 12:41:25 <minimal> mps: Unfortunately the comment in the MR comes across as rather negative. Maybe that's just my interpretation of it.
2020-09-19 12:41:39 <mps> have to add that I don't know much about this package
2020-09-19 12:42:42 <mps> minimal: keep in mind that most of developers are not native english speakers and from different cultures so don't take everything 'to heart'
2020-09-19 12:43:27 <minimal> mps: I understand and fully agree. That works both ways.
2020-09-19 12:43:45 <mps> sure :)
2020-09-19 12:46:25 <minimal> mps: cloud-init is a boot-time only package. There's no long-lived daemon for example. It design to run during both first-time boot and during subsequent boots to configure the OS for networking, storage, and various other things. If you for example create a Centos/Fedora/Debian/Ubuntu/Amazon Linux VM on AWS/Azure etc its there in the relevant OS "cloud image" to set up the OS based on user-data based to it
2020-09-19 12:47:39 <minimal> So the package is intended to be installed when you are building an OS image, its not intended to be installed on a normal running system
2020-09-19 12:47:46 <Ariadne> the summary i posted referring the issue to core explains it i think
2020-09-19 12:47:47 <Ariadne> :)
2020-09-19 12:47:55 <mps> minimal: thanks for explanation, but this is not were my works are
2020-09-19 12:48:56 <minimal> Ariadne: thanks for your help
2020-09-19 12:50:14 <minimal> mps: short version: cloud-init is not something that 99.9% of Alpine users will want to install. However its an important package to have in Alpine is someone (including the Alpine Project themselves) wants to build Alpine VM images for use with various cloud providers.
2020-09-19 12:50:53 <Ariadne> there are alternatives to cloud-init also in alpine with provide the same integration fwiw
2020-09-19 12:51:02 <Ariadne> s/with/which/
2020-09-19 12:51:03 <alpine-meetbot> Ariadne meant to say: there are alternatives to cloud-init also in alpine which provide the same integration fwiw
2020-09-19 12:51:23 <Ariadne> but i think they require custom initramfs or something.
2020-09-19 12:51:53 <minimal> yupe, I'm familiar with tiny-ec2-bootstrap, its AWS specific however. The advantage of cloud-init is the breadth of cloud providers it supports
2020-09-19 12:51:55 <Ariadne> a few months ago i saw some person give a talk about how they made ignition work with alpine (!)
2020-09-19 12:55:36 <minimal> yupe. There are multiple alternatives to cloud-init which are "lighter" in terms of dependencies. However cloud-init is effectively industry-standard. Any new cloud provider coming along will typical write a new C-I DataSource for their offering. FYI: https://cloudinit.readthedocs.io/en/latest/topics/datasources.html
2020-09-19 12:56:00 <Ariadne> idk i don't use cloud stuff
2020-09-19 12:56:01 <Ariadne> :)
2020-09-19 12:56:18 <minimal> Ariadne: I'll like to see an official Alpine cloud image available for download at some stage
2020-09-19 12:58:17 <minimal> Ariadne: FYI, cloud-init doesn't require a cloud to work, the NoCloud data source supports reading either an ISO image or a FAT partition containing its YAML files. For my RPI and some physical x86_86 machines I have disk images with a small cloud-init partition pre-created complete with YAML files to configure machine upon 1st boot
2020-09-19 12:59:01 <Ariadne> hmm, that could be interesting for ROMKit
2020-09-19 12:59:23 <Ariadne> (ROMKit is a very low priority project of mine to build firmware images based on Alpine)
2020-09-19 13:02:42 <minimal> Ariadne: Never heard of ROMkit. I have a homegrown Ansible playbook I use to create Alpine armv7, aarch64, and x86_64 images of v3.12 and Edge for physical and VM use. Then I either "dd" the resultant images to SD card (for RPI) or use a minimal Alpine image on a USB stick to "dd" to a machine's harddisk or use Qemu to run the image
2020-09-19 13:03:38 <Ariadne> ROMKit is for making images to flash into SPI NOR flash.
2020-09-19 13:03:52 <Ariadne> it generates a payload that is a kernel combined with a squashfs
2020-09-19 13:04:13 <Ariadne> you flash it into ROM
2020-09-19 13:04:15 <Ariadne> :)
2020-09-19 13:04:31 <minimal> what's your target hardware?
2020-09-19 13:04:32 <Ariadne> jffs2 is then overlaid on top
2020-09-19 13:04:56 <Ariadne> minimal: mostly 32-bit mips, armhf and armv7
2020-09-19 13:05:49 <Ariadne> many of the target devices i am using this with only have 8MiB of NOR flash
2020-09-19 13:05:55 <Ariadne> so i care about alpine-base being small :)
2020-09-19 13:06:05 <minimal> competing with OpenWRT?
2020-09-19 13:06:11 <Ariadne> yes
2020-09-19 13:06:23 <Ariadne> although OpenWRT are looking at using apk3
2020-09-19 13:06:38 <Ariadne> if they do, then maybe they will also adopt abuild
2020-09-19 13:06:39 <minimal> yeah? cool, hadn't heard that
2020-09-19 13:06:53 <Ariadne> and if they do, then romkit is obsolete :)
2020-09-19 13:08:38 <minimal> cloud-init might be a little big "large" for you then - being written in Python rather than a compiled language. I'd looked at multiple cloud-init alternatives but I still ended up back at cloud-init as nothing could compete on functionality with it.
2020-09-19 13:09:47 <Ariadne> maybe i look into it after ifupdown-ng is more complete.
2020-09-19 13:12:29 <minimal> Aridne: question about ifupdown-ng, does it support "ethernet-wol g" ?
2020-09-19 13:13:08 <minimal> that's for enabling wake-on-lan for an interface
2020-09-19 13:14:22 <Ariadne> is that a stanza in debian?
2020-09-19 13:14:27 <Ariadne> we've never supported that in alpine afaik
2020-09-19 13:15:00 <minimal> I've used it before on Debian. Just checked and the Debian manpage for interfaces doesn't mention it but I know I've justed it previously on Debian.
2020-09-19 13:15:18 <Ariadne> The script /etc/network/if-up.d/ethtool will then take care of calling ethtool on ifup. See /usr/share/doc/ethtool/README.Debian for more information.
2020-09-19 13:15:19 <Ariadne> ah
2020-09-19 13:15:37 <Ariadne> we don't yet have an ethtool integration
2020-09-19 13:15:56 <minimal> ah. so there's no way then currently to enable WoL
2020-09-19 13:16:58 <minimal> guess I could just kludge a boot-time script to run ethtool for now
2020-09-19 13:17:05 <Ariadne> 0.10 will have it
2020-09-19 13:17:59 <minimal> so with 0.10 what entry would need to be added to the interfaces file to trigger ethtool?
2020-09-19 13:21:07 <Hello71> can't you run post-up ethtool?
2020-09-19 13:21:38 <Ariadne> minimal: `ethernet-wol g`
2020-09-19 13:21:57 <Ariadne> and yes, as Hello71 says in the meantime you could just use a post-up statement
2020-09-19 13:23:56 <minimal> Hello71: trying to see what's required to have it work out-of-the-box with cloud-init which adds "ethernet-wol g" to the /net/network/interfaces file based on its network config YAML
2020-09-19 13:26:17 <Ariadne> (most likely it will actually be ethtool-wol g, but we can translate the property)
2020-09-19 13:28:54 <minimal> ok. Need to do some digging at my end as after adding the "wakeonlan: true" to the cloud-init YAML network-config didn't actually result it in adding it to the e/n/i file (despite what their docs say)...
2020-09-19 13:30:39 <andypost[m]> Talking about cloud images, I found it strange https://github.com/scaleway/image-alpine/blob/master/latest/overlay/etc/apk/repositories
2020-09-19 13:32:49 <minimal> andypost: what's strange about that?
2020-09-19 13:33:34 <andypost[m]> Stable mixed with edge
2020-09-19 13:34:56 <Cogitri> Many people aren't aware of how easy that breaks
2020-09-19 13:35:19 <minimal> ah right, yeah not a great idea. When I wrote the cloud-init module for configuring apk repositories file I made a point of adding a comment line into the file if testing repo was enabled on a non-Edge system to warn about that
2020-09-19 13:39:47 <minimal> andypost: from a quick look at that repo they're not using cloud-init, they seem to have their own scripts to do minimal config. However they do have 4 other cloud-init enabled Linux dists: https://www.scaleway.com/en/docs/how-to-use-cloud-init-to-configure-your-server-at-first-boot/
2020-09-19 13:40:48 <minimal> Which goes back to my point that it would be great for Alpine Linux to have official cloud-init enabled VM images produced that could then be used across multiple cloud providers rather than have some (or all) of the cloud providers develop their own images.
2020-09-19 13:42:45 <andypost[m]> That's great idea instead of scattered implementations
2020-09-19 13:43:33 <minimal> From memory both Debian and Ubuntu have official cloud images and I assume CentOS, Fedora, and SuSE do the same thing
2020-09-19 14:33:13 <Ariadne> is sqlite3 no longer packaged for python3?
2020-09-19 14:34:18 <Ariadne> oh
2020-09-19 14:34:23 <Ariadne> its part of python3 package itself.
2020-09-19 14:56:26 <minimal> Ariadne: re the WoL stuff, looks like upstream cloud-init dropped the ball, despite having a "wakeonlan: <true|false" specified in their network config YAML seems like the actual code to use this to actually put entries into /e/n/i or netplan is missing. I'll have to raise an issue/PR upstream to fix that.
2020-09-19 14:56:44 <Ariadne> well, ethernet-wol g will work
2020-09-19 14:57:27 <minimal> yeah, first I'll need to patch cloud-init itself to put "ethernet-wol g" into /e/n/i when it sees its YAML setting ;-)
2020-09-19 15:25:40 <maxice8> @Cogitri !12631 OOM'd on CI x86_64, can merge regardless ?
2020-09-19 16:46:44 <Cogitri> I think so, yes
2020-09-19 19:03:52 <mps> can someone look at prometeus (who know what is it) failure on aarch64 builder
2020-09-19 19:10:01 <ikke> I looked briefly at it
2020-09-19 19:10:19 <ikke> It's giving a usage for 'link'
2020-09-19 19:10:27 <mps> also I did but don't understand how build for it works
2020-09-19 19:24:59 <minimal> ikke: is this the build for !12381 ?
2020-09-19 19:25:56 <minimal> that MR added a LDFLAGS variable which is split across multiple lines.
2020-09-19 19:27:56 <ikke> yeah, most likely
2020-09-19 19:28:02 <ikke> But it fails only on a single arch
2020-09-19 19:28:33 <minimal> does it? I looked at the pipeline in !12381 and it shows failed for all archs
2020-09-19 19:29:40 <ikke> only the last pipeline
2020-09-19 19:29:50 <ikke> because it was merged (with source branch removed) immediately after rebase
2020-09-19 19:30:08 <ikke> On the builders, only aarch64 failed
2020-09-19 19:30:28 <ikke> https://pkgs.alpinelinux.org/packages?name=prometheus&branch=edge
2020-09-19 19:31:29 <minimal> definately strange then
2020-09-19 19:35:44 <ikke> checking it on the builder
2020-09-19 20:07:33 <ikke> aha, it's not /bin/link, but /usr/lib/go/pkg/tool/linux_arm64/link that's being called
2020-09-19 20:08:34 <ikke> the usage output would have been a clue :)
2020-09-19 20:19:09 <ikke> This is the link invokation
2020-09-19 20:19:11 <ikke> https://tpaste.us/9Nm6
2020-09-19 20:47:58 <court_jester> hey there... for the mini root filesystem download options in https://alpinelinux.org/downloads/? This is an automated build? There's any public pages for following the builds of these images? Or not?
2020-09-19 20:49:29 <ikke> minimal: minimal ok, asked in #go-nuts, and apparently it has to do with the -extldflags that are added
2020-09-19 20:49:32 <ikke> mps*
2020-09-19 20:50:25 <ikke> court_jester: they are generated when tags are pushed
2020-09-19 20:50:27 <ikke> to git
2020-09-19 20:50:46 <ikke> so it's periodically built
2020-09-19 20:51:01 <court_jester> @ikke Those deploy scripts are open sourced?
2020-09-19 20:52:25 <ikke> court_jester: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/scripts
2020-09-19 20:53:35 <court_jester> oh! Interesting. are you also using this gitlab as ci/cd for alpine?
2020-09-19 20:54:42 <mps> ikke: I'm mostly forgot about building go packages
2020-09-19 20:55:22 <ikke> court_jester: mostly CI
2020-09-19 20:55:36 <ikke> the actual building of packages is done on separate builders
2020-09-19 20:56:21 <court_jester> hmmm, interesting
2020-09-19 20:57:06 <mps> ikke: this extldflags are in prometheus from beginning
2020-09-19 20:57:41 <ikke> yes, I saw that too
2020-09-19 20:58:01 <ikke> court_jester: and images as well
2020-09-19 20:58:19 <court_jester> are these build systems public?
2020-09-19 20:58:46 <ikke> The scripts that run on those servers are
2020-09-19 20:59:08 <ikke> and https://build.alpinelinux.org shows what they are doing
2020-09-19 20:59:46 <mps> huh, go packages build becoming more and more cumbersome
2020-09-19 21:00:00 <ikke> mps: My experience is that it becomes easier, honestly
2020-09-19 21:01:23 <mps> heh, maybe my feel comes from faded memory about it
2020-09-19 21:01:53 <court_jester> Awesome, thanks @ikke <3
2020-09-19 21:02:06 <mps> but prometheus is some combo of go and node, iiuc
2020-09-19 21:02:29 <ikke> yes
2020-09-19 21:03:48 <mps> removing these two lines with -extldflags seems to solve build, at least in my lxc
2020-09-19 21:03:58 <ikke> yes
2020-09-19 21:04:01 <ikke> I tested it on the builder
2020-09-19 21:04:16 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12641
2020-09-19 21:04:28 <mps> ah, you could save me some seconds if you told that a minute ago :)
2020-09-19 21:04:43 <ikke> I wasn't aware you were trying it :P
2020-09-19 21:04:56 <mps> np, I'm joking a little
2020-09-19 21:05:22 <mps> it is good to see how my decision to throw go was good
2020-09-19 21:05:23 <court_jester> What is this build.alpine? DroneCI?
2020-09-19 21:05:35 <ikke> No, a custom tool
2020-09-19 21:05:41 <court_jester> hmmm, cool
2020-09-19 21:05:44 <ikke> It takes output from mqtt
2020-09-19 21:05:51 <ikke> which is central to our build infra
2020-09-19 21:08:24 <ikke> mps: hmm, it fails on other arches :-/
2020-09-19 21:08:50 <mps> oh
2020-09-19 21:09:13 <ikke> aha,
2020-09-19 21:09:20 <ikke> now I now why it only fails on aarch64
2020-09-19 21:10:22 <ikke> We set LDFLAGS to -Wl,--as-needed
2020-09-19 21:10:39 <mps> yes
2020-09-19 21:10:45 <ikke> but not on aarch64
2020-09-19 21:11:31 <mps> do we know why
2020-09-19 21:12:11 <ikke> Not me at least
2020-09-19 21:13:35 <ikke> ncopa: any idea why LFDLAGS is not set to -Wl,--as-needed on the aarch64 builder?
2020-09-19 21:14:55 <ikke> good that I tested it on CI first
2020-09-19 21:15:04 <ikke> I had some feeling that flag was set with a reason
2020-09-19 21:16:13 <mps> hm, looks like LDFLAGS are '-Wl,--as-needed' also on aarch64
2020-09-19 21:16:25 <ikke> You mean supported?
2020-09-19 21:16:33 <mps> yes
2020-09-19 21:16:56 <mps> echo $LDFLAGS in build() shows that
2020-09-19 21:17:23 <ikke> it depends on /etc/abuild.conf
2020-09-19 21:17:29 <ikke> on the builder, it's empty
2020-09-19 21:17:34 <ikke> the aarch64 builder
2020-09-19 21:18:07 <mps> ah, in my lxc it is `export LDFLAGS="-Wl,--as-needed"`
2020-09-19 21:18:11 <ikke> no
2020-09-19 21:18:13 <ikke> nod*
2020-09-19 21:18:42 <mps> let me try once more
2020-09-19 21:20:01 <mps> oh, I have time for glass of wine and cigarette ;P
2020-09-19 21:20:42 <mps> Browserslist: caniuse-lite is outdated. Please run the following command: `npx browserslist --update-db`
2020-09-19 21:22:46 <minimal> ikke: glad you figured out the issue, strange it didn't appear before in previous prometheus builds on aarch64
2020-09-19 21:23:26 <mps> uhm, something is wrong with my builder
2020-09-19 21:23:49 <ikke> minimal: it was due to the addition of the -X flas
2020-09-19 21:23:52 <ikke> flags
2020-09-19 21:24:17 <ikke> Before that, it would just pass "-extldflags" to link
2020-09-19 21:24:29 <ikke> but now, it passed -extldflags -X..."
2020-09-19 21:24:41 <ikke> because $LDFLAGS is empty on aarch64
2020-09-19 21:25:35 <mps> yes, last commit looks strange
2020-09-19 21:26:02 <minimal> ikke: wondering if this difference between aarch64 build env and other envs caused any other issues in packages in the past...
2020-09-19 21:26:32 <mps> add such things to LDFLAGS looks wrong to my uneducated eyes
2020-09-19 21:27:07 <ikke> mps: no idea
2020-09-19 21:27:18 <ikke> It seems to me that it can reduce the linked library list
2020-09-19 21:27:35 <ikke> if I read the documentation for --as-needed correctly
2020-09-19 21:28:46 <mps> really don't have any idea about this in prometheus
2020-09-19 21:29:18 <ikke> This is just general go / linking things
2020-09-19 21:30:12 <mps> uh, what a surprise, I'm this one who pushed it initially in aports
2020-09-19 21:30:19 <ikke> :D
2020-09-19 21:30:23 <mps> 
ACTION hides in deep cellar

2020-09-19 21:35:10 <ikke> I think this should fix it: https://tpaste.us/navg
2020-09-19 21:36:21 <mps> my hope is on you
2020-09-19 21:38:09 <ikke> hmm, I can simpllify it
2020-09-19 21:38:23 <ikke> ie, remove the if statement
2020-09-19 21:46:15 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12641
2020-09-19 22:01:43 <ikke> fixed
2020-09-19 22:01:51 <ikke> It now built on aarch64
2020-09-19 22:03:02 <mps> I see, well done meister :)
2020-09-19 22:08:24 <ikke> with the help of #golang-nuts :)
2020-09-20 08:56:02 <Ariadne> grr
2020-09-20 08:56:09 <Ariadne> i wish there was a way to disable verifying modloop
2020-09-20 08:56:22 <Ariadne> it really sucks when you are using ipmi over satellite connection
2020-09-20 11:06:07 <ikke> seems we still have race-condition issues when downloading sources on arm(hf|v7)
2020-09-20 11:06:15 <ikke> https://nos.nl/artikel/2349098-gronings-dorp-opgeschrikt-door-schietpartij-acht-arrestaties.html
2020-09-20 11:07:08 <clandmeter> ikke: ?
2020-09-20 11:07:23 <ikke> ups, wrong link
2020-09-20 11:07:28 <clandmeter> :D
2020-09-20 11:07:30 <Cogitri> Bad copy and paste? :D
2020-09-20 11:07:39 <ikke> Well, no copy happened when I expected it
2020-09-20 11:07:51 <ikke> https://build.alpinelinux.org/buildlogs/build-edge-armv7/main/nss/nss-3.57-r0.log
2020-09-20 11:07:57 <ikke>  https://build.alpinelinux.org/buildlogs/build-edge-armhf/main/nss/nss-3.57-r0.log
2020-09-20 11:15:04 <ikke> ncopa: armhf downloaded the source first, and armv7 started to overwriting it, causing checksum failures
2020-09-20 11:15:25 <ikke> So seems like locking is not working
2020-09-20 11:32:39 <PureTryOut[m]> Is it possible for a package to depend on a specific dbus service yet? Like `cmd:<whatever>` but for dbus?
2020-09-20 11:35:00 <ikke> no
2020-09-20 11:35:29 <ikke> maybe if you manually set provides / depends
2020-09-20 11:35:39 <ikke> provides dbus:<service>
2020-09-20 11:42:43 <Cogitri> Would be nice if abuild could do that automatically
2020-09-20 11:42:56 <maxice8> dbus-services-provider ?
2020-09-20 11:43:11 <maxice8> I'm willing to work on that
2020-09-20 11:43:16 <Cogitri> PureTryOut[m]: You can check gnome-keyring's APKBUILD for an example of how to do it manually
2020-09-20 11:46:00 <maxice8> @Cogitri they also ship a .impl. file with it, what do we do with those ?
2020-09-20 11:46:23 <Cogitri> Sorry?
2020-09-20 11:46:25 <maxice8> org.freedesktop.secrets.service and org.freedesktop.impl.portal.Secret.service
2020-09-20 11:46:57 <Cogitri> That's just the service name, I don't think .impl has some special meaning
2020-09-20 11:47:46 <PureTryOut[m]> Cogitri: ah cool thanks!
2020-09-20 11:47:57 <ikke> Any opinions about https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12614/diffs#f419afbf59e8e6772da1393e5bb318e95dc7b6f3_0_22?
2020-09-20 11:48:02 <ikke> I already commented on it earlier
2020-09-20 11:48:14 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12614/diffs#note_114810
2020-09-20 11:49:03 <mps> !12614
2020-09-20 11:49:32 <maxice8> commented
2020-09-20 12:12:05 <maxice8> @Cogitri http://ix.io/2ycy
2020-09-20 16:36:27 <Cogitri> maxice8: I think we might have to differentiate  between system and user dbus services
2020-09-20 16:51:52 <nmeum> ikke: i don't like it
2020-09-20 16:52:41 <ikke> nmeum: me neither
2020-09-20 16:53:07 <ikke> I've created a simple APKBUILD for mage
2020-09-20 17:28:44 <maxice8> @Cogitri how can we differentiate between the 2 ?
2020-09-20 17:40:28 <maxice8> @Cogitri like this ? https://gitlab.alpinelinux.org/alpine/abuild/-/merge_requests/67
2020-09-20 17:47:43 <Cogitri> Yup
2020-09-20 19:17:15 <maxice8> When can KODI get to python3 ?
2020-09-20 19:35:16 <PureTryOut[m]> 19.x release
2020-09-20 19:36:02 <maxice8> When is that ?
2020-09-20 19:59:43 <maxice8> seems like Neomutt tests hang all the builders
2020-09-20 20:02:25 <maxice8> Can someone kill all the EDGE builders ?
2020-09-20 20:03:04 <ikke> ANy idea why?
2020-09-20 20:04:09 <maxice8> no idea, I disabled them for now
2020-09-20 20:04:20 <maxice8> it hangs on Test test_mutt_file_read_line...
2020-09-20 20:05:39 <ikke> FUTEX_WAIT_PRIVATE
2020-09-20 20:06:15 <ikke> typical deadlock we've been seeing
2020-09-20 20:11:16 <ikke> Ok, killed all jobs
2020-09-20 20:15:24 <maxice8> ty
2020-09-20 21:46:33 <maxice8> asymptote causing FUTEX_WAIT_PRIVATE again apparently
2020-09-21 07:12:29 <ikke> Morning
2020-09-21 07:15:56 <mps> ikke: morning :)
2020-09-21 07:19:08 <Cogitri> Morning
2020-09-21 07:37:56 <clandmeter> good morning alpine lovers
2020-09-21 07:42:02 <mps> and haters :)
2020-09-21 07:44:08 <clandmeter> i hate haters, please go away!
2020-09-21 07:45:20 <mps> ok, see you in next life
2020-09-21 07:46:33 <clandmeter> this is my last one, take it or leave it.
2020-09-21 07:50:03 <mps> as a supreme deity (Brahma/Vishnu/Shiva) I'll give you another one for free even if you are sinner ;)
2020-09-21 08:33:04 <detha> clandmeter: I see you mentioned as maintainer for net-snmp, is there any chance of bringing it to 5.9 ?
2020-09-21 08:34:31 <detha> 5.8 has some issues with agentx plugins
2020-09-21 08:42:30 <clandmeter> detha: im currently not much active so maybe somebody here can help you upgrade it.
2020-09-21 08:43:18 <clandmeter> detha: or you could upgrade it yourself by sending an MR.
2020-09-21 08:44:07 <detha> clandmeter: ok, will do
2020-09-21 09:23:44 <mps> next linux-lts will have speakup moved from stating to 'main'. does it make sense to enable it on alpine kernels and work in idea to have speakup console on boot enabled as option
2020-09-21 09:32:51 <ncopa> morning
2020-09-21 09:34:28 <mps> \o
2020-09-21 09:35:08 <mps> nearly noon here
2020-09-21 11:23:46 <maxice8> @Ikke can you kill the builders again ? another deadlock
2020-09-21 11:24:03 <maxice8> except s390x, s390x is fine in this upside down world
2020-09-21 16:35:37 <maxice8> algitbot: retry master
2020-09-21 17:34:44 <ncopa> phew... i just rebased !10933 almost 800 commits. lots of conflicts. 6 packages moved so i had to update commit message `teseting/...:` to `community/...:`
2020-09-21 17:35:08 <ncopa> it passed the CI build a month ago. I wonder if I should just push it and see what happens
2020-09-21 17:36:50 <ikke> ouch
2020-09-21 17:37:11 <ncopa> is there some conveinent way to push force to j0wi's MR?
2020-09-21 17:37:29 <maxice8> There are instructions on GitLab on how to push but you need to set up stuff
2020-09-21 17:37:33 <ncopa> iirc i can do it but need to do it in like 5 steps
2020-09-21 17:37:36 <maxice8> I just make a new MR to make use of the CI
2020-09-21 17:37:51 <maxice8> then merge my own with all credit to him via the commits and close his with 'Merged manually with fixes'
2020-09-21 17:38:07 <Cogitri> You can do `git push git@gitlab.alpinelinux.org:J0WI/aports.git HEAD:actual_branch -f`
2020-09-21 17:38:20 <Cogitri> That will push your HEAD commit to the actual_branch in J0WI's fork
2020-09-21 17:39:29 <ncopa> ah, wonderful. that is what i was looking for
2020-09-21 17:40:53 <mps> 
ACTION would like to understand this

2020-09-21 17:41:46 <ikke> You just push the branch directly to J0WIs fork
2020-09-21 17:41:53 <ikke> The branch that is used for the merge request
2020-09-21 17:42:09 <ncopa> exactly, that is what i just did
2020-09-21 17:43:00 <ncopa> git push <repourl> <local>:<remote>
2020-09-21 17:43:18 <mps> what is 'HEAD:actual_branch'
2020-09-21 17:43:37 <ncopa> HEAD is the current local head
2020-09-21 17:43:56 <mps> in my git repo
2020-09-21 17:44:01 <mps> ?
2020-09-21 17:44:14 <ncopa> so whatever branch i have checked out. i could have used "master"
2020-09-21 17:44:25 <ncopa> because i merged in the commits to my local master barnch
2020-09-21 17:44:31 <mps> aha
2020-09-21 17:44:48 <mps> so I don't have to create local branch
2020-09-21 17:44:49 <ncopa> but HEAD means whatever I have currently checked out
2020-09-21 17:44:54 <ncopa> right
2020-09-21 17:45:06 <ncopa> i did rebase it against origin/master before pushing though
2020-09-21 17:45:09 <mps> in that case 'HEAD:master -f'
2020-09-21 17:45:11 <ncopa> so i got the latest commites
2020-09-21 17:45:12 <ncopa> no
2020-09-21 17:45:25 <ncopa> i dont want push to J0WI's master
2020-09-21 17:45:41 <ncopa> "Request to merge J0WI:perl-5.32.0 into master"
2020-09-21 17:46:00 <ncopa> J0WI has a branch called perl-5.32.0
2020-09-21 17:46:00 <mps> ah, actual_branch is branch where I push, i.e. MR branch
2020-09-21 17:46:02 <ikke> And you don't want to push something relevant
2020-09-21 17:46:23 <ncopa> so i did HEAD:perl-5.32.0
2020-09-21 17:46:25 <ncopa> with -f
2020-09-21 17:46:38 <mps> ah, now it is clearer to me
2020-09-21 17:47:09 <ncopa> so I force pushed my local master branch into his perl-5.32.0 branch
2020-09-21 17:47:20 <ncopa> my local master had all his commits rebased
2020-09-21 17:47:38 <mps> would you mind to write complete command you used to do that
2020-09-21 17:48:04 <ncopa>  git push git@gitlab.alpinelinux.org:J0WI/aports.git HEAD:perl-5.32.0 -f
2020-09-21 17:48:22 <mps> thanks :)
2020-09-21 17:48:39 <ncopa> please note that `git push -f` is dangerious
2020-09-21 17:48:52 <ncopa> so you need to be sure that you know exactly what you are doing
2020-09-21 17:49:19 <ncopa> and never push -f to aports master
2020-09-21 17:49:25 <ncopa> or any stable branches
2020-09-21 17:49:25 <mps> sure
2020-09-21 17:49:41 <mps> I'm talking about MRs
2020-09-21 17:50:34 <mps> had just once to use -f to master to fix mess
2020-09-21 17:51:29 <mps> and by luck there were no another other pushes on top
2020-09-21 17:51:44 <mps> s/another//
2020-09-21 17:51:44 <alpine-meetbot> mps meant to say: and by luck there were no  other pushes on top
2020-09-21 17:52:02 <ncopa> heh...
2020-09-21 17:52:08 <ncopa> :)
2020-09-21 17:52:15 <ncopa> i wish i didnt hear that :)
2020-09-21 17:52:25 <mps> :)
2020-09-21 17:52:55 <Cogitri> Hm, how come ocaml is still -r3 on x86_64
2020-09-21 17:52:55 <mps> things happens, even bad ones
2020-09-21 17:53:55 <ncopa> maybe build didnt complete? or failed to upload?
2020-09-21 17:54:18 <ncopa> im calling it a day. thanks!
2020-09-21 17:54:31 <ncopa> tomorro i'll hopefully push the perl MR
2020-09-21 17:55:05 <ncopa> we need to think about what to include before feature freeze for 3.13
2020-09-21 17:56:17 <mps> kernel? new one
2020-09-21 18:10:57 <mps> heh, Failed 1 test out of 2545, 99.96% okay
2020-09-21 18:11:06 <mps> perl on s390x
2020-09-21 18:12:00 <mps> 'FAILED--expected 1022 tests, saw 82'
2020-09-21 18:43:08 <craftyguy> if I understand the output here correctly, it looks like this CI job failed because it tried to build a package (chatty) before any of the new deps added in the MR were built? https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/211724
2020-09-21 18:43:37 <craftyguy> (specifically like 65 in the log)
2020-09-21 18:57:47 <craftyguy> If so, it seems like a bug in the CI test?
2020-09-21 19:47:53 <maxice8> Perl blew up, time to firefight
2020-09-21 19:48:24 <ikke> yup
2020-09-21 19:48:36 <ikke> per-pod-coverage has test failures
2020-09-21 19:48:44 <maxice8> it is missing perl-pod-parser
2020-09-21 19:49:02 <ikke> aha, I see you pushed that
2020-09-21 19:49:11 <maxice8> maybe perl 5.31.0 provided that because it never failed before
2020-09-21 19:49:23 <ikke> perl on s390x has test failures as well
2020-09-21 19:49:45 <mps> maxice8: perl odd versions are unstable/testing
2020-09-21 19:50:01 <mps> even versions are stable
2020-09-21 19:50:07 <ikke> Failed 1 test out of 2545, 99.96% okay.
2020-09-21 19:50:10 <ikke> re/pat_thr.t
2020-09-21 19:50:25 <mps> so, yes, maybe this is introduced in 5.31
2020-09-21 19:50:33 <ikke> t/re/pat_thr ................................................... FAILED--expected 1022 tests, saw 829
2020-09-21 19:50:54 <mps> ikke: yes, I wrote two hours ago about that fail
2020-09-21 19:51:02 <ikke> ah, I see
2020-09-21 19:51:15 <mps> I tested on x86_64 and it pass fine
2020-09-21 19:51:31 <ikke> yeah, it seems to only fail on s390x
2020-09-21 19:51:37 <mps> don't know why it fails on s390x
2020-09-21 19:52:01 <ikke> I could try to figure out, but I have no idea how to delve into this, I have very limited perl experience
2020-09-21 19:52:35 <mps> if have this line `require './thread_it.pl';`
2020-09-21 19:54:41 <ikke> testing it in a docker container on s390x now
2020-09-21 19:58:13 <mps> look at the end of log, about ./perl harness
2020-09-21 19:58:33 <mps> maybe this can spot reason for fail
2020-09-21 20:04:41 <ikke> still running
2020-09-21 20:15:47 <ikke> and of course the tests are passing now :-/
2020-09-21 22:01:15 <Ganwell> anyone using chromium on edge? Is it stable? No crashing taps with Aw, Snap!?
2020-09-21 22:02:56 <Cogitri> I think that still happens from time to time, something is wrong with seccomp apparently
2020-09-21 22:03:12 <Ganwell> I upstreamed the dbus malloc-after-fork to poll() patch https://gitlab.freedesktop.org/jeanlf/dbus/-/pipelines/204000
2020-09-21 22:04:24 <Cogitri> Nice 👍
2020-09-21 22:04:29 <Ariadne> Ganwell: i am, with --no-sandbox and it is fine.  seccomp seems to be the issue
2020-09-21 22:05:20 <Ganwell> Nice, so there is some hope.
2020-09-21 22:06:24 <c705> I had to do some stuff to my firejail profile to get Firefox to work (not sure if chromium or not)
2020-09-21 22:06:35 <c705> I can look it up if you'd like
2020-09-21 22:08:59 <Ganwell> Ariadne: Cogitri you were totally right about upstreaming first, the CI of dbus found a copy-paste error. openjdk needed to close stderr+ which is fd 2+ and dbus needed 3+.
2020-09-21 22:12:03 <Cogitri> Yup, upstreaming first is best since they have the proper CI and know the code best
2020-09-21 22:13:29 <Ganwell> I am running chromium --no-sandbox on my machines now.
2020-09-21 22:55:19 <maxice8> nginx is now failing due to multiple definitions
2020-09-21 23:53:29 <awilfox> Ganwell: left a review comment on that.  it looks generally ok though.
2020-09-22 00:25:07 <awilfox> I'm talking with a Mono committer that noticed they are using opendir for closeall too, so hopefully that will get fixed some time
2020-09-22 02:01:24 <craftyguy> does abuild normally include shared objects (.so) in -dev subpackages?
2020-09-22 02:04:20 <craftyguy> looking at some -dev packages in alpine, it seems that the answer is 'yes'
2020-09-22 02:04:40 <maxice8> yes, .solinks are always in -dev
2020-09-22 02:04:49 <maxice8> sonames are in the mainpkg or -libs or lib$pkgname
2020-09-22 02:05:20 <craftyguy> ah, so it seems my package is not creating solinks. sigh
2020-09-22 02:05:49 <craftyguy> since no .so end up in the -dev
2020-09-22 02:40:22 <maxice8> yes, it should create a library like libfoo.so.X.Y.Z, a soname libfoo.so.X and a solink libfoo.so
2020-09-22 02:40:30 <maxice8> first two go into the mainpkg, last one goes into -dev
2020-09-22 02:41:08 <craftyguy> but if the solink goes into -dev, wouldn't that just be a broken symlink if a package depends on the -dev?
2020-09-22 02:41:24 <maxice8> no, because the -dev depends on the package that provides the soname
2020-09-22 02:41:42 <craftyguy> hmm, that doesn't seem to be the case with my package (axc)
2020-09-22 02:41:57 <craftyguy> installing the -dev doesn't pull in the main package :/
2020-09-22 02:44:05 <maxice8> it only installs libaxc.so.0.3.2, it needs a symlink libaxc.so.0 -> libaxc.so.0.3.2 and another symlink libaxc.so -> libaxc.so.0.3.2
2020-09-22 02:45:36 <craftyguy> right, I added the symlinks in a local copy of the apkbuild
2020-09-22 02:45:50 <craftyguy> oh oops, not libaxc.so.0 though
2020-09-22 02:50:14 <craftyguy> hmm yeah even with that axc is not being pulled in by axc-dev
2020-09-22 02:56:27 <maxice8> you also need to pass some LDFLAGS
2020-09-22 03:30:35 <craftyguy> maxice8: when building axc or ?
2020-09-22 03:30:51 <maxice8> when linking libaxc
2020-09-22 03:32:59 <craftyguy> I'm not sure I follow. is there an example I can look at?
2020-09-22 03:33:43 <maxice8> See tinyxml, specifically the -Wl,-soname part
2020-09-22 03:34:05 <craftyguy> I'm already doing: -shared -Wl,-soname,libaxc.so.$(VER_MAJ)
2020-09-22 03:34:14 <craftyguy> ok, I'll check that out
2020-09-22 03:59:08 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/community/borgbackup/borgbackup-1.1.13-r1.log x86_64 is stuck
2020-09-22 04:17:24 <craftyguy> I still can't figure out the right combination of soname/solink, etc
2020-09-22 04:17:58 <craftyguy> libaxc.so.0.3.2 should be built with -soname,libaxc.so.0 ?
2020-09-22 04:18:12 <craftyguy> built/linked/whatever
2020-09-22 04:18:48 <craftyguy> -Wl,-soname,libaxc.so.0 -o libaxc.so.0.3.2
2020-09-22 04:19:36 <craftyguy> then ln -s libaxc.so.0.3.2 libaxc.so.0 && ln -s libaxc.so.0.3.2 libaxc.so
2020-09-22 04:19:42 <craftyguy> is that correct?
2020-09-22 04:27:39 <craftyguy> eh even with that abuild won't pull in axc when axc-dev is installed
2020-09-22 04:29:24 <craftyguy> same when linking with -soname,libaxc.so.0.3.2
2020-09-22 04:46:16 <craftyguy> ah, I see the problem
2020-09-22 04:47:53 <craftyguy> the version in the makefile was not updated, it should have been 0.3.3.. so the generated .so from make had a name different than what I was trying to symlink. oops
2020-09-22 04:49:56 <craftyguy> maxice8: thanks for the help, I appreciate it :)
2020-09-22 05:03:53 <craftyguy> these two MRs should fix the -dev packages for libomemo and axc: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12700 https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12699
2020-09-22 05:49:35 <maxice8> algitbot: retry
2020-09-22 05:52:17 <craftyguy> maxice8: the changes in my MR have already been submitted upstream, they haven't been accepted yet
2020-09-22 05:52:25 <maxice8> ok good
2020-09-22 05:52:28 <ncopa> morning
2020-09-22 05:52:33 <craftyguy> those patches are from the 'debian on mobile' effort, they beat me to making the changes :P
2020-09-22 05:52:36 <ncopa> looks like perl blew up
2020-09-22 05:52:37 <maxice8> Morning, perl rebuild is going good
2020-09-22 05:52:45 <craftyguy> and opened MRs for them
2020-09-22 05:52:50 <ncopa> fatal: master...HEAD: no merge base
2020-09-22 05:52:56 <ncopa> and CI gave green light
2020-09-22 05:53:58 <maxice8> @ncopa perl blew on s390x tests
2020-09-22 05:54:05 <ncopa> i saw
2020-09-22 05:54:20 <ncopa> what i wondered was why the CI gave green light
2020-09-22 05:54:22 <maxice8> also broke perl-pod-coverage which needed perl-pod-parser
2020-09-22 05:54:30 <ncopa> i think the CI never actually built anything
2020-09-22 05:54:41 <ncopa> and gave green light for all of it
2020-09-22 05:55:32 <ncopa> would have been better if I'd have built it locally as i traditionally do :-/
2020-09-22 06:14:54 <maxice8> I'm working on perl-snmp-info
2020-09-22 06:15:08 <ncopa> im building perl on s390x currently
2020-09-22 06:15:14 <maxice8> good luck
2020-09-22 06:15:21 <ncopa> and are trying to rebuild everything on my x86_64
2020-09-22 06:15:51 <ncopa> seems like s390x has deadlocked in test lib/locale_threads
2020-09-22 06:16:27 <mps> last night I rebuilt perl on x86_64, worked without problem
2020-09-22 06:17:20 <mps> and, yes on s390x problem is something with threads, it seems
2020-09-22 06:26:13 <ncopa> ok. i think we have a serious problem
2020-09-22 06:26:24 <ncopa> not only related perl
2020-09-22 06:26:48 <ncopa> the problem with the deadlocks
2020-09-22 06:49:00 <mps> Cogitri: sorry to annoy you in early morning, but do you think firefox should be upgraded in 3.12 also
2020-09-22 07:23:18 <Cogitri> mps: Yup, it probably fixed some CVEs (but the release notes aren't out yet so I don't know which ones)
2020-09-22 07:24:15 <Cogitri> ncopa: Yes, the fork()->malloc()->exec() thingie happens in loads of packages unfortunately and I doubt we'll be able to patch them all
2020-09-22 07:24:27 <mps> ok, thanks for caring about it
2020-09-22 07:25:31 <mps> yes, I doubt that we could fix all these with AS-unsafe
2020-09-22 07:26:08 <mps> probably we need workaround in musl, and keep buggy software for infinite time
2020-09-22 07:29:41 <Cogitri> Yup
2020-09-22 07:30:41 <mps> and, iirc dalias contemplated about this
2020-09-22 10:44:05 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11968 Is this a problem with fakeroot?
2020-09-22 10:56:16 <Ariadne> harrumph.  meson is now developing antifeatures
2020-09-22 10:56:43 <Ariadne> namely, they are writing their own pkg-config implementation
2020-09-22 10:56:55 <Ariadne> which will assuredly not be consistent with system pkg-config
2020-09-22 10:57:13 <Ariadne> that will be something we should probably defang somehow
2020-09-22 11:04:31 <Cogitri> Huh, do you have a link to that?
2020-09-22 11:10:55 <skarnet> you know Peter's law when promoting people?
2020-09-22 11:11:07 <skarnet> I believe the same is true with software and features
2020-09-22 11:11:28 <skarnet> every project grows until it collapses under its own weight
2020-09-22 11:11:43 <skarnet> the only way to avoid that is a tight vision
2020-09-22 11:11:53 <skarnet> and meson just proved it doesn't have that. :(
2020-09-22 11:38:33 <Ariadne> Cogitri: https://github.com/mesonbuild/meson/pull/7650
2020-09-22 11:39:00 <Eighth_Doctor> 🤦‍♂️
2020-09-22 11:39:50 <Ariadne> it makes sense for windows
2020-09-22 11:40:00 <Ariadne> but for distributions it is a nightmare
2020-09-22 11:40:20 <Ariadne> we obviously want all queries to pkg-config to be the same
2020-09-22 11:59:56 <Hello71> I think I considered this before, but don't remember what came of it: shouldn't it be possible to check if the program is doing something illegal after fork and abort instead of hanging? it would be useful to have a specific message instead of having to dive into the debugger
2020-09-22 12:00:37 <Hello71> if there is a significant performance penalty then it could be hidden behind a flag (compile or run time)
2020-09-22 12:07:18 <Cogitri> > This adds a python parser for pkg-config files and use it in PkgConfigDependency, unless a binary is set in PKG_CONFIG env or in machine files in which case we are forced to still use it because it would be a wrapper that sets some env.
2020-09-22 12:07:32 <Cogitri> So at least the meson pkg-config thingie will be easy to override
2020-09-22 12:13:07 <Ariadne> yeah
2020-09-22 12:13:22 <Ariadne> im just saying we will want to defang it :P
2020-09-22 12:28:23 <ncopa> i wonder if it would make sense with a libpkgconf and make python bindings to it
2020-09-22 12:29:34 <Hello71> Ariadne already asked that in the issue
2020-09-22 12:31:30 <ncopa> seems like they only want depend on python so it wont work
2020-09-22 12:31:32 <ncopa> oh well
2020-09-22 12:51:16 <Ariadne> Hello71: regarding SYSROOT, pkgconf is quite different than fd.o pkg-config.
2020-09-22 12:51:59 <Ariadne> (in fact, this difference is one of the big reasons why i made pkgconf to begin with.  bootstrapping alpine was much more complicated until i completely redesigned how SYSROOT works.)
2020-09-22 12:52:46 <Ariadne> in fd.o pkg-config, .pc files have to be specially written to support SYSROOT.  this requires patching the .pc files in many cases.  in pkgconf, *any* .pc file can be used with SYSROOT unmodified.
2020-09-22 12:53:07 <Ariadne> meaning, you just set SYSROOT and it "just works" assuming you actually have a cross-compiled library in your SYSROOT
2020-09-22 12:53:49 <Ariadne> the final straw of course was that stupid glib2 dependency loop where you needed pkg-config -> glib2 -> pkg-config
2020-09-22 12:54:05 <Ariadne> but before that happened we were already cooking up a wishlist for pkg-config
2020-09-22 12:54:16 <Ariadne> and so pkgconf was started based on those discussions :)
2020-09-22 12:56:04 <Ariadne> pkgconf also supports Provides, which fd.o pkg-config doesn't (even though they've had a patch for a long time in bugzilla)
2020-09-22 12:57:36 <Ariadne> SYSROOT is not a typical use of pkg-config though.  so i don't think it really matters much.  i think pkgconf's approach to SYSROOT is much better than pkg-config, though.  (and i think 0.29 and later use the same approach pkgconf uses anyway)
2020-09-22 12:58:36 <Ariadne> i should write a blog about that someday
2020-09-22 13:45:41 <Hello71> yes, I'm familiar with pkg-config glib from Gentoo: pkg-config is not in @system so you can easily end up with no glib or pkg-config. so there is USE=internal-glib but it's kind of a pain because portage isn't smart enough to set it temporarily
2020-09-22 13:53:34 <Ariadne> as far as i can tell gentoo prefers pkgconf-1.6.3 over the fd.o version
2020-09-22 13:53:46 <Ariadne> at least i have a lot of gentoo users hitting distfiles.dereferenced.org
2020-09-22 13:53:57 <Ariadne> several thousand downloads per day
2020-09-22 15:34:22 <cfengineuser> when i try to install pidgin i don't get the version in aports for 3.12
2020-09-22 15:35:03 <cfengineuser> i tried to build the version in aports but i am missing a dependency libgnt-dev
2020-09-22 15:35:13 <cfengineuser> not sure what to do
2020-09-22 15:35:23 <cfengineuser> any help would be appreciated
2020-09-22 15:35:50 <maxice8> algitbot: retry
2020-09-22 15:36:08 <mps> cfengineuser: I answered on #alpine-linux
2020-09-22 15:36:15 <cfengineuser> k
2020-09-22 15:36:49 <maxice8> Can someone take a look at x86_64 builder ?
2020-09-22 15:36:55 <maxice8> neomutt is failing to clean up
2020-09-22 15:48:54 <ikke> In a moment
2020-09-22 15:54:43 <maxice8> @Cogitri added secfixes for firefox=81.0-r0
2020-09-22 16:04:57 <Ariadne> ikke: these packages that get stuck in tests.  have you been tracking which ones they are?
2020-09-22 16:08:04 <ikke> Ariadne: each time different packages
2020-09-22 16:08:22 <ikke> well, neomutt is repeating now
2020-09-22 16:09:01 <maxice8> neomutt is failing to clean srcdir for some reason I asked someone to look into it
2020-09-22 16:09:04 <maxice8> asymptote is the one hanging
2020-09-22 16:11:15 <ikke> asymptote is hanging on generating man
2020-09-22 16:12:06 <ikke> ../asy -dir ../base -config  -render=0 -f pdf -noprc GaussianSurface.asy
2020-09-22 16:12:19 <ikke> That has 2 child processes, gs and latex
2020-09-22 16:12:33 <Ariadne> fork() with malloc probably
2020-09-22 16:13:07 <ikke> latex on read(0
2020-09-22 16:13:31 <ikke> strace doesn't show anything for asy
2020-09-22 16:14:30 <ikke> gs is a zombie process
2020-09-22 16:14:55 <ikke> asy is using 100% cpu
2020-09-22 16:15:29 <ikke> I have a backtrace for asy
2020-09-22 16:15:53 <ikke> https://tpaste.us/qgda
2020-09-22 16:21:42 <ikke> Anyone got an idea?
2020-09-22 16:26:29 <Ganwell> ikke: did you run strace -f on the root-process? (I assume latex is calling a lot of helpers, right?)
2020-09-22 16:26:44 <ikke> Ganwell: I don't see subprocesses
2020-09-22 16:27:16 <ikke> strace -f doesn't report anything more
2020-09-22 16:27:59 <Ganwell> how can it have to childs and strace can't follow them?
2020-09-22 16:28:10 <Ganwell> s/to/two/
2020-09-22 16:28:11 <alpine-meetbot> Ganwell meant to say: how can it have two childs and strace can't follow them?
2020-09-22 16:28:20 <ikke> asy has 2 childs
2020-09-22 16:28:25 <ikke> gs, which is a zombie
2020-09-22 16:28:29 <ikke> and latex
2020-09-22 16:29:40 <ikke> https://tpaste.us/N8vB
2020-09-22 16:29:59 <Ganwell> weill, my idea was to attach strace -f to the programm that orchestrates the processes, which would be asy, so you see "everything" in your strace.
2020-09-22 16:30:47 <ikke> The parent is make man
2020-09-22 16:31:04 <ikke> if I strace -f that, I still only see a single wait4(-1 line
2020-09-22 16:31:06 <Ganwell> I guess `strace -f ../asy -dir ../base -config  -render=0 -f pdf -noprc GaussianSurface.asy`
2020-09-22 16:31:26 <ikke> Right, now I'm attaching to running processes
2020-09-22 16:31:31 <Ariadne> I'll look into it in a moment
2020-09-22 16:31:58 <Ganwell> yes its better to have strace attached from the beginning. -f will tell it to follow forks.
2020-09-22 16:32:07 <ikke> nod
2020-09-22 16:32:20 <Ganwell> the downside is more logs to work through.
2020-09-22 16:32:25 <ikke> but that's not always easy with these build systems
2020-09-22 16:35:22 <ikke> ok, strace -f make man (while the other one was still running) does seem to get the same state
2020-09-22 16:37:59 <ikke> heh, while outputing the strace output to a file, I now see the gs output
2020-09-22 16:38:17 <ikke> https://tpaste.us/x1ZD
2020-09-22 16:44:49 <Ganwell> Does gs abort and some process still tries to read from it?
2020-09-22 16:45:19 <ikke> yes, looks like it
2020-09-22 17:34:16 <dalias> cogitri, is there any place you're documenting all the packages you hit this in?
2020-09-22 17:38:41 <Cogitri> I usually open gitlab issues for them, the packages I recall right now are: VTE (got a patch already but Tilix still likes to get stuck when clicking on links), pulseaudio, dbus
2020-09-22 17:47:59 <skarnet> the usual suspects
2020-09-22 18:00:11 <Cogitri> Well, it's rather easy to accidentally malloc () between fork () and exec () and since it works on glibc I suppose most devs just don't know that it's problematic
2020-09-22 18:05:07 <dalias> it doesn't work on glibc if the application (or user) has interposed its own malloc tho
2020-09-22 18:05:57 <dalias> also the ones i've seen breaking this mostly *know it's wrong* and willfully do it because glibc
2020-09-22 18:06:20 <dalias> (i don't think other non-linux systems consistently allow this either; it's even still *wrong* to allow it until next issue of posix is out)
2020-09-22 18:06:45 <dalias> (next issue will allow it but doesn't allow applications to assume it)
2020-09-22 18:06:57 <ikke> In practice, all what matters what glibc allows, sadly
2020-09-22 18:07:23 <Cogitri> Yup, at least most testing is done on that
2020-09-22 18:07:45 <dalias> ikke, that's really not the case at all unless the program is inherently linux-specific
2020-09-22 18:08:09 <Cogitri> Even so, most devs are on linux
2020-09-22 18:08:18 <dalias> if it breaks on all the bsds, solaris, hpux, whatever then the program is clearly broken and needs to be fixed
2020-09-22 18:08:38 <dalias> they don't have any legitimacy arguing "it works on glibc"
2020-09-22 18:09:02 <dalias> if it's inherently linux-only, then they have some defensible position of "glibc defined what the expectations on linux are"
2020-09-22 18:09:14 <Cogitri> Well, it works for them and 99% of their userbase
2020-09-22 18:09:40 <Cogitri> So I can understand where the dev is coming from not wanting to mess with that one weird linux distro
2020-09-22 18:10:14 <dalias> it's so unbelievable that, many years after musl having largely fixed the notion that that attitude is ok, it comes up again as soon as there's some "widespread" subtle bug from assuming glibc
2020-09-22 18:10:27 <ikke> It's an uphil battle
2020-09-22 18:10:34 <dalias> it was 5 or 6 years ago
2020-09-22 18:10:43 <dalias> now it's just a few shitty programs with hostile authors
2020-09-22 18:10:53 <dalias> and it's really not that hard to carry patches for them
2020-09-22 18:10:59 <ikke> Most projects accept fixes for these things
2020-09-22 18:11:04 <dalias> yes
2020-09-22 18:11:14 <ikke> but they do not test it on other systems, so only when they get reports, they realize things are wrong
2020-09-22 18:11:37 <dalias> most ppl are reasonable and happy to be informed that they were unknowingly doing something non-portable and that use on a musl-based linux dist caught a problem that was affecting users of other systems they weren't aware of too
2020-09-22 18:12:11 <dalias> they may not have the bandwidth to fix it themselves, but they're not hostile to getting it fixed
2020-09-22 18:12:27 <ikke> nod
2020-09-22 18:12:32 <mps> yes, most are ok
2020-09-22 18:13:01 <ikke> But that results in these things, where changes in musl suddenly show up in all kinds of bugs
2020-09-22 18:13:17 <mps> and some of them even ask do we have some kind of container where they can test when we fill bug report
2020-09-22 18:13:42 <mps> would be nice if we something (docker) handy for them
2020-09-22 18:13:50 <mps> we have*
2020-09-22 18:14:02 <dalias> ikke, i agree it's frustrating that a change makes the bug clear, but this is literally a situation where there were potentially-dangerous or at least crash-inducing bugs since forever, and now they're reliably caught
2020-09-22 18:14:06 <ikke> mps: we have
2020-09-22 18:14:22 <ikke> mps: alpinelinux/build-base should be a good starter
2020-09-22 18:15:08 <mps> ikke: is it documented for first time upstream developers
2020-09-22 18:15:42 <ikke> Not in particular for that usecase, no
2020-09-22 18:16:01 <mps> first time on alpine, I mean
2020-09-22 18:16:16 <ikke> 
ACTION is figuring out why abuild clean is erroring out on neomutt on x86_64

2020-09-22 18:16:17 <mps> some asked in mail or irc
2020-09-22 18:16:29 <Cogitri> Or just a simple Dockerfile that just does `FROM alpine:edge` and then installs the affected package
2020-09-22 18:16:55 <mps> Cogitri: something like that, but described a little
2020-09-22 18:17:11 <Cogitri> Hm, I guess someone could make a wiki article for it
2020-09-22 18:17:24 <ikke> build-base should be suitable for that
2020-09-22 18:17:27 <mps> would be nice
2020-09-22 18:17:43 <ikke> it already has alpine-sdk / build-base installed, which is needed in most cases anyway
2020-09-22 18:18:59 <ikke> https://gitlab.alpinelinux.org/alpine/infra/docker/build-base
2020-09-22 18:21:04 <mps> yes, but some guide for developers who do not any experience with alpine would be of help
2020-09-22 18:23:16 <ikke> strange
2020-09-22 18:23:29 <ikke> rm gets access denied (I see it in strace), but no message from rm
2020-09-22 18:24:21 <ikke> https://tpaste.us/yNWg
2020-09-22 18:25:22 <ikke> There is a directory that is chmod 000
2020-09-22 18:27:09 <mps> hmm, then I think that could be ok, 'undelete' flag ;)
2020-09-22 18:27:20 <ikke> ?
2020-09-22 18:27:57 <mps> chmod 000, and you create protected from delete file
2020-09-22 18:28:24 <ikke> You should still be able to unlink it if you have write permissions in the directory
2020-09-22 18:28:45 <mps> well, I'm just guessing
2020-09-22 18:30:37 <mps> touch x;  chmod 000 x; rm x => rm: remove write-protected regular empty file 'x'? y => removed 'x'
2020-09-22 18:32:28 <detha> not having x on the directory could be a problem
2020-09-22 18:32:47 <ikke> yeah, it's the open call on the dir that fails
2020-09-22 18:33:05 <ikke> which is probably because the lack of 'x'
2020-09-22 18:33:30 <ikke> but what I'm puzzled about is why rm doesn't report anything, except an error code
2020-09-22 18:36:09 <ikke> asymptote also hangs on aarch64
2020-09-22 18:43:38 <tehcloud> it is too busy approaching zero from the left hand side
2020-09-22 18:46:13 <ikke> lol
2020-09-22 18:50:41 <craftyguy> are packages not being built at the moment? or the system is backed up? (I'm not sure where to find this answer on my own other that searching pkgs.alpinelinux.org)
2020-09-22 18:52:27 <insep_> build.alpinelinux.org
2020-09-22 18:53:20 <ikke> craftyguy: most builders were stuck, but I just unstuck them
2020-09-22 18:54:39 <craftyguy> insep_: thanks
2020-09-22 18:54:46 <craftyguy> ikke: and, thanks :D
2020-09-22 19:34:25 <maxice8> cogitri: 3.12-firefox needs nss-3.56
2020-09-22 19:42:33 <ikke> regarding secfixes, do we mention the version that fixed it, or the version that we end up building (which might be a few versions ahead already)
2020-09-22 19:42:46 <maxice8> I was told it is version which is fixed
2020-09-22 19:43:00 <ikke> hmm, but the release then doesn't really make sense
2020-09-22 19:43:03 <ikke> -r0
2020-09-22 19:43:08 <ikke> because that never existed
2020-09-22 19:43:08 <maxice8> libfoo-0.5 is current version, we upgrade to 0.7 but it was fixed in 0.6 we mention 0.6
2020-09-22 19:43:24 <maxice8> it never existed but the value is less than the current value so the checkers don't trigger it
2020-09-22 19:43:30 <ikke> yea
2020-09-22 19:47:26 <maxice8> same reason ncopa recommened using 0: as unaffected version
2020-09-22 19:48:22 <ikke> Hmm, fun, bind 9.14.* did not receive sucurity fixes (which is present in 3.11
2020-09-22 19:48:26 <ikke> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11884
2020-09-22 19:50:36 <ikke> same for 3.9 and 3.10
2020-09-22 20:01:45 <ikke> Ugh, I have a hard time finding the commits that fixed those issues :-/
2020-09-22 20:02:23 <ikke> Ok, found one /o\
2020-09-23 01:10:57 <craftyguy> I'm confused why this build is failing, since the package it wants is in edge now.. is there a cache somewhere that hasn't been updated?
2020-09-23 01:11:00 <craftyguy> https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/212543#L569
2020-09-23 01:11:33 <craftyguy> (the package is axc-dev: https://pkgs.alpinelinux.org/package/edge/testing/x86_64/axc-dev
2020-09-23 01:12:37 <craftyguy> damn, only 1 arch is listed when I search for axc-dev. maybe the others haven't been built yet..
2020-09-23 01:12:47 <craftyguy> 
ACTION not confused anymore

2020-09-23 01:13:55 <craftyguy> I guess CI can't handle MRs that update an existing package with new deps that are also in the MR?
2020-09-23 01:13:58 <craftyguy> https://gitlab.alpinelinux.org/craftyguy/aports/-/jobs/212539#L76
2020-09-23 01:14:38 <craftyguy> should I separate those into different MRs?
2020-09-23 04:42:00 <ikke> craftyguy: if it's in the same MR, it should be able to handle it
2020-09-23 04:43:20 <ikke> craftyguy: the issue is that the dependencies are in testing, while chatty is in community
2020-09-23 04:43:33 <ikke> packages in community cannot depend on packages in testing
2020-09-23 04:43:43 <ikke> and packages in main cannot depend on packages in community or testing
2020-09-23 04:46:51 <craftyguy> oof
2020-09-23 07:18:53 <dne> ikke: can't see #11884 but bind 9.14 is EoL, so maybe best to backport 9.16 (which will get extended support)?
2020-09-23 07:41:52 <ikke> Will discuss it with ncopa, normally we only upgrade within minor releases for stable branches
2020-09-23 07:42:23 <ikke> If there are lts releases, we want to make sure to only use those
2020-09-23 07:43:09 <maxice8> Is it possible to get gdbm upgrade before 3.13 ? it seems to be all set
2020-09-23 07:44:01 <dne> ikke: ok, 9.11 is the current "extended support version" (supported until 2021-12), 9.16 will be the next one according to https://kb.isc.org/docs/aa-00896
2020-09-23 08:07:11 <ikke> dne: good to know
2020-09-23 08:07:41 <ikke> Thinking about taking maintainership for bind, there is no one right now
2020-09-23 08:25:22 <ncopa> morning
2020-09-23 08:25:30 <maxice8> morning
2020-09-23 08:25:36 <ncopa> maxice8: is gdbm upgrade ABI compat?
2020-09-23 08:25:43 <maxice8> no, requires rebuild
2020-09-23 08:25:53 <ncopa> ok. we should do that before 3.13 then
2020-09-23 08:26:05 <ncopa> i need to try clean up the perl disaster too :-/
2020-09-23 08:26:06 <maxice8> it is !9447 I think
2020-09-23 08:28:08 <ncopa> re updating bind in stable branches. what we want pevent is that things breaks for users when the upgrade. They should be able be confident that running `apk upgrade` never breaks anything
2020-09-23 08:28:26 <ncopa> so they should not need to change their config or anything
2020-09-23 08:29:06 <ncopa> so if you can update bind 9.14 -> 9.16, and things will "just work", and nobody will need to change their configs, then it may be acceptable solution
2020-09-23 08:29:18 <ncopa> if some users may need to change their configs, then its not acceptable
2020-09-23 08:35:54 <dne> https://downloads.isc.org/isc/bind9/9.16.7/doc/arm/html/notes.html#notes-for-bind-9-16-0
2020-09-23 10:18:33 <ikke> There are some config changes, so I don't think it's a good idea to upgrade to 9.16
2020-09-23 10:22:42 <ncopa> +1
2020-09-23 10:23:26 <ikke> So I'll see if I can backport these fixes
2020-09-23 10:35:51 <ncopa> i think i know why perl testsuite fails on s390x
2020-09-23 10:35:59 <ncopa> runs out of thread stack space
2020-09-23 11:11:35 <ncopa> looks like perl rebuilds actually passed on the other arches?
2020-09-23 17:20:10 <wsinatra> would anyone mind looking at !12763
2020-09-23 17:20:43 <wsinatra> I noticed an issues with libreswan's handling of ike algo and a lack of support for modp1024, so I swapped the ipsec dependency to strongswan
2020-09-23 17:21:08 <maxice8> valid->validate
2020-09-23 17:23:40 <wsinatra> nice catch, thanks leo
2020-09-23 19:11:36 <maxice8> ncopa: ok to push gdbm ? it will cause rebuilds of some important packages (python{2,3}, php*)
2020-09-23 19:16:44 <maxice8> wsinatra: made a force push to your !12763
2020-09-23 19:18:01 <wsinatra> thanks for the heads up!
2020-09-23 21:47:01 <craftyguy> Cogitri: I guess for this MR I should remove Chatty since it's in community and the plugins I've added there are in testing, right? https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12066
2020-09-23 21:47:32 <craftyguy> and make chatty not depend on those plugins (so users wanting omemo/more xmpp features will have to explicitly install them)
2020-09-23 21:48:07 <ikke> craftyguy: packages don't need to remain in testing for long
2020-09-23 21:48:30 <ikke> and potentially could even directly added to community if they are required as dependencies
2020-09-23 21:49:02 <craftyguy> I'm not sure if I should remove the changes to the community package that makes it depend on them, and merge the plugins to testing, or ?
2020-09-23 21:50:11 <craftyguy> Cogitri is listed as the maintainer for chatty, so I'd like his thoughts on how to proceed
2020-09-23 21:53:12 <Cogitri> I guess we could make chatty not depend on them for now since they can be a bit buggy apparently and move them to community later on
2020-09-23 21:53:52 <craftyguy> ok, sounds good. I'll fixup the MR
2020-09-24 03:38:04 <maxice8> The builders are peaceful (except s390x because perl)
2020-09-24 04:44:39 <ikke> maxice8: why did you mark all the tasks comlpeted for the xen CVE issue?
2020-09-24 04:45:10 <maxice8> I have good faith belief I merged the MRs that fix those issues
2020-09-24 04:45:17 <maxice8> I tagged the Author to confirm
2020-09-24 04:46:41 <ikke> Ah, I didn't see any back-reference to the ticket
2020-09-24 04:46:56 <maxice8> It was merged before that Issue was even made
2020-09-24 04:47:20 <ikke> oh, didn't see that
2020-09-24 04:47:33 <ikke> will add the commit hashes then
2020-09-24 04:54:38 <ikke> Hmm, there are a lot of closed security issues that are still marked confidential
2020-09-24 05:56:41 <ncopa> morning
2020-09-24 05:57:13 <maxice8> <ncopa "morning"> gdbm has been pushed
2020-09-24 05:57:19 <ncopa> maxice8: i think you can push gdbm now, if we have solved ...
2020-09-24 05:57:21 <ncopa> oh. ok :)
2020-09-24 05:57:24 <ncopa> very well
2020-09-24 05:57:30 <ncopa> thank you!
2020-09-24 05:57:38 <maxice8> No worries
2020-09-24 05:57:40 <Cogitri> Morning
2020-09-24 05:57:46 <maxice8> Cogitri is building the boost reverse deps
2020-09-24 05:58:02 <ncopa> aw... i forgot to push the perl fix yesterday. i thought i did
2020-09-24 05:59:06 <ncopa> pushed now. s390x will be busy today (hopefully)
2020-09-24 06:13:54 <ncopa> i think apkbuild-fixer is doing something nasty: https://tpaste.us/QWoz
2020-09-24 06:14:57 <ncopa> removed update_config_sub, ./configure and make install
2020-09-24 06:21:22 <maxice8> Seems like it is getting confused
2020-09-24 06:21:38 <maxice8> Can you open an issue on Leo/atools with an example APKBUILD?
2020-09-24 07:12:23 <ncopa> will do
2020-09-24 07:12:25 <ncopa> later...
2020-09-24 07:12:35 <maxice8> No worries I looked at vanessa_adt
2020-09-24 07:12:38 <maxice8> testing on it
2020-09-24 07:12:45 <maxice8> apkbuild-fixer is outdated
2020-09-24 07:13:07 <Cogitri> Is the version 0.48_git20200924 > 0.48 ?
2020-09-24 07:13:44 <ikke> apk version -t 0.48_git20200924 0.48                                                                                                                                                                               ~ 1 ↵
2020-09-24 07:13:46 <ikke> >
2020-09-24 07:14:00 <ikke> so yes
2020-09-24 07:14:06 <Cogitri> Alright, thanks :)
2020-09-24 07:19:02 <maxice8> @ncopa found out the problem
2020-09-24 07:19:14 <ncopa> that was fast :)
2020-09-24 07:19:36 <maxice8> 9 is bigger than 37 for sort
2020-09-24 07:19:45 <ncopa> ha!
2020-09-24 07:19:47 <maxice8> need sort -n
2020-09-24 07:19:47 <ncopa> sort -n
2020-09-24 07:20:17 <maxice8> I need to sort them in reverse order so I remove always the lines at the bottom so there is no chance the lines will screw up
2020-09-24 07:37:05 <ncopa> does anyone know the difference between gpl-3.0-only and the gpl-3.0-or-later?
2020-09-24 07:37:54 <maxice8> pratically none until GPL>3.0 is out
2020-09-24 07:37:57 <ncopa> im trying to compare  https://spdx.org/licenses/GPL-3.0-only.html#licenseText with https://spdx.org/licenses/GPL-3.0-or-later.html#licenseText
2020-09-24 07:38:30 <ncopa> this is the COPYING file: https://tpaste.us/K5On
2020-09-24 07:38:45 <ncopa> and i wonder if i should use GPL-3.0-only or GPL-3.0-or-later
2020-09-24 07:39:13 <maxice8> Should look at the disclaimers on the source files
2020-09-24 07:39:26 <ikke> yes, the source files itself should contain that qualifier
2020-09-24 07:39:37 <ikke> The license text is the same
2020-09-24 07:40:43 <ikke> See the Standard License Header at the bottom
2020-09-24 07:41:05 <maxice8> sed doesn't respect \t
2020-09-24 07:41:14 <ikke> "under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. "
2020-09-24 07:42:22 <ncopa> maxice8: maybe extended regexp supports \t?  sed -E
2020-09-24 07:42:46 <ncopa> sigh. grepping for GPL shows only one header
2020-09-24 07:42:54 <ncopa> which says gpl-2.0-or-later
2020-09-24 07:43:05 <Cogitri> I usually great for `or later` in the source files
2020-09-24 07:43:14 <Cogitri> s/great/grep/
2020-09-24 07:43:15 <alpine-meetbot> Cogitri meant to say: I usually grep for `or later` in the source files
2020-09-24 07:43:21 <ncopa> #define COPYRIGHT \
2020-09-24 07:43:21 <ncopa>   "(c) 1999 Horms <horms@verge.net.au>\nReleased under the GNU GPL\n"
2020-09-24 07:43:21 <ikke> If it doesn't mention, I would assume -only
2020-09-24 07:44:03 <maxice8> ncopa: no dice with sed -E
2020-09-24 07:45:01 <ncopa> https://unix.stackexchange.com/questions/145299/simple-sed-replacement-of-tabs-mysteriously-failing
2020-09-24 07:45:22 <ncopa> looks like there are only ugly workarounds :)
2020-09-24 07:46:02 <maxice8> nope
2020-09-24 07:46:17 <ncopa> re perdition license, i think what happened was, author intended to use gpl2-or-later, but automake/autoconf -i installed COPYING that was gpl 3
2020-09-24 07:46:32 <ncopa> the options.h header says gpl-2.0-or-later
2020-09-24 07:48:06 <maxice8> oh nice
2020-09-24 07:48:09 <maxice8> just needed to do
2020-09-24 07:48:23 <maxice8> sed -i '${linenum}i\\$statement" "$apkbuild"
2020-09-24 07:59:51 <dne> re: confidential issues, is there actually any point in that for public vulnerabilities in packaged software? (I don't see it at least)
2020-09-24 08:00:24 <dne> maxice8: e.g., I didn't see your mention until the ticket was closed
2020-09-24 08:00:44 <dne> (the xen issue)
2020-09-24 08:01:53 <ikke> dne: We do that for issues that haven't been addressed yet
2020-09-24 08:02:12 <ikke> so that the issue tracker does not become a repository of unpatched vulnerabilities in alpine
2020-09-24 08:02:21 <ikke> as soon as it's patched, we make the issue public
2020-09-24 08:02:34 <ikke> Or, that's what should happen anyway
2020-09-24 08:03:00 <dne> ok, yeah, but it doesn't take much to find out that something is unpatched anyway
2020-09-24 08:03:26 <ikke> sure, but you don't have to make it any easier as well
2020-09-24 08:03:37 <dne> ok fair enough
2020-09-24 08:45:52 <ncopa> yes. the reasoning is that we dont want an automated way to get all unfixed security issues
2020-09-24 08:51:15 <ikke> I think we should go over all closed confidatial issues with tag:security and make them public
2020-09-24 08:54:53 <Cogitri> What would be really nice would be if we had a way to unmask security issues after N days after it was fixed
2020-09-24 08:55:19 <Cogitri> Because unmaking immediately after the MR was merged is a bit suboptimal and I usually forget about it later on
2020-09-24 10:27:51 <PureTryOut[m]> maxice8: could you give a shot packaging the new Synapse deps for Redis usage? py3-hiredis needs a rebuild against newer redis (but causes segfaults for me while doing so) and there is an unpackaged dep `py3-txredisapi`
2020-09-24 12:34:09 <Ariadne> it would be nice if core team could formalize a decision on what minimal needs to do with cloud-init
2020-09-24 12:44:42 <minimal> Ariadne: Thanks for helping.
2020-09-24 12:46:10 <minimal> Unfortunately the issue is giving me 2nd thoughts about maintaining any Alpine packages going forward
2020-09-24 12:46:51 <ikke> minimal: Well, you have to take into account that this package is doing something unusual (from an alpine policy perspective).
2020-09-24 12:47:00 <ikke> So you can kind of expect at least some discussion
2020-09-24 12:47:45 <skarnet> cloud-init is really special in that it has to integrate with the service manager at several levels, so yes, it requires more coordination than your average package
2020-09-24 12:47:53 <minimal> ikke: I agree. I also have indicated that the package's use is also unusual. I have no problem with discussion, I'm actively seeking it
2020-09-24 12:48:04 <ikke> The only issue is that we don't have a good process to take quick decissions as a group in this regards
2020-09-24 12:49:06 <ikke> ncopa is even more busy than normal nowadays, but I suspect everyone is waiting for him to weigh in
2020-09-24 12:49:49 <minimal> ikke: I guess for me the issue is exposing the underlying concern I have regarding Alpine maintainership - to some extend maintainership is in name alone, anyone can submit a MR to change a package without consultation with the maintainer and there's a fair chance the MR will be merged.
2020-09-24 12:51:19 <ikke> Right, but it's not straight-forward
2020-09-24 12:53:10 <ikke> For example, trivial changes as patch updates should not have to wait for the maintainer to approve, that would cause a delay in being able to merge MRs
2020-09-24 12:53:25 <ikke> (some maintainers take a long time to respond, if they respond at all)
2020-09-24 12:53:37 <minimal> ikke: Agreed, and important security fixes so.
2020-09-24 12:55:31 <ikke> So there is at least some decission from the people who merge whether to wait for the maintainer to approve
2020-09-24 12:55:47 <ikke> I feel that if there are larger / more important changes, we tend to do ask the maintainer
2020-09-24 12:57:14 <minimal> There's a risk that someone unfamiliar with a particular package can have MRs merged that negatively impact on the package.
2020-09-24 12:59:52 <minimal> ikke: I realise we're all volunteers putting our personal time in and also that there are ongoing growing pains in Alpine (plus CI/CD issues related to musl changes) so I hope I don't come across as "demanding".
2020-09-24 13:00:27 <ikke> no, certainly not
2020-09-24 13:01:17 <ikke> We need to find a good trade-off between being able to move forward and making sure things keep working
2020-09-24 13:02:51 <minimal> ikke: On a more practical note regarding policy, where exactly is the relevant policy defined?
2020-09-24 13:03:20 <ikke> That's one of the issues we really need to solve, to start properly documenting
2020-09-24 13:04:29 <minimal> It's a bit hard to be told I'm breaking policy but no-ones pointed me to the policy so far...
2020-09-24 13:04:37 <insep_> maybe there's should be some script like setup-xorg-base but for cloud-init?
2020-09-24 13:04:39 <ikke> Yes, understood
2020-09-24 13:05:12 <ikke> RIght now it's transfered 'orally'
2020-09-24 13:05:21 <ikke> We need to put it down
2020-09-24 13:05:47 <ikke> https://docs.alpinelinux.org/developer-handbook/0.1a/index.html is kind if the place where we want to do that, but somebody needs to start working on it
2020-09-24 13:06:35 <minimal> insep_: yeah I could write a script and tell people to run that manually, and for a typical package that's what I'd do but as I've pointed out in the past, cloud-init is not a typical package, its not something you install on a machine and then use it. Its basically only installed when you are creating a OS image
2020-09-24 13:07:53 <minimal> ikke: Catch-22 I guess - the people who orally maintain the policy are far too busy to put the policy in writing and no-one else can volunteer to do it as they don't know the policy :-(
2020-09-24 14:19:55 <ncopa> hey minimal, sorry for not being around more :-/
2020-09-24 14:20:18 <minimal> No problem, understand you're very busy
2020-09-24 14:21:01 <ncopa> so, where can i read up on the details on this cloud-init?
2020-09-24 14:22:17 <minimal> !12247 is the MR that triggered the issue - it was merged and then @dalias raised a policy complaint in the MR
2020-09-24 14:23:31 <ncopa> oh, right, that one, thanks
2020-09-24 14:24:16 <minimal> ncopa: Yes my MR "broke" policy but I strongly believe its a valid exception
2020-09-24 14:27:11 <ncopa> :)
2020-09-24 14:27:18 <dalias> its *always* possible to want sw installed without a policy change. there is no exception
2020-09-24 14:27:43 <ikke> dalias: I don't follow that sentence..
2020-09-24 14:27:53 <ncopa> hang on a sec, i need to re-read all the comments
2020-09-24 14:28:11 <ncopa> i had a look at the post-install script itself
2020-09-24 14:28:51 <dalias> apk add x doesnt mean i want my system reconfigured to some purpose
2020-09-24 14:28:57 <dalias> assiciated with x
2020-09-24 14:29:09 <dalias> it means i want the software in pkg z
2020-09-24 14:29:10 <dalias> x
2020-09-24 14:29:15 <dalias> sorry android kb
2020-09-24 14:33:54 <ncopa> so, from first look at the script, my immediate reaction was similar to dalias. there is no way that this is acceptable. but after readin the comments, im not so sure. need to dig deeper into this
2020-09-24 14:34:49 <ncopa> i have also looked at cloud-init the other day, since i believe that if we got it working properly, it could help us get alpine in typical cloud environments if i understand things correctly
2020-09-24 14:35:38 <ncopa> minimal: is that correct? will cloud-init make it possible to deploy alpine in cloud environments? or is it for unattended installs in general?
2020-09-24 14:36:22 <minimal> ncopa: yes, I build VM images (not just cloud), and physical machine images using cloud-init for bootstrapping OS configuration
2020-09-24 14:37:01 <ncopa> i have been thinking about a solution for unattended installs for a decade but never taken the time to come to any conclusion. cloud-init seems to be a sstandard way to do it
2020-09-24 14:37:05 <ncopa> and i like standards :)
2020-09-24 14:37:12 <minimal> for physical machines for example I use the NoCloud cloud-init datasource where I have a FAT partition containing the YAML files specifying network config, users & groups, disk setup, etc
2020-09-24 14:38:08 <ncopa> my feeling is that cloud-init is big a clumsy and apparently it requires things like udev, but i think it may be worth make it work properly
2020-09-24 14:38:24 <minimal> So for my Raspberry PIs I "dd" the image to multiple SD cards, mount the partition of each SD card and configure unique machines' static IPs and names and then stick the SD cards into RPIs and bingo, functional servers
2020-09-24 14:38:42 <ncopa> thats awesome
2020-09-24 14:38:52 <ncopa> i have been looking for something like that
2020-09-24 14:40:15 <ncopa> that said, doing this from post-install script feels very wrong, so i wonder if there are any alternative ways to do it?
2020-09-24 14:40:17 <minimal> ncopa: Its the "industry standard" for bootstrapping Linux with cloud providers. I know you talked with the tiny-ec2-bootstrap author about creating Alpine AWS images. Cloud-init means the project could create images for AWS, Azure, GCE, and a whole host of other providers
2020-09-24 14:40:45 <ncopa> thats is what i assumed
2020-09-24 14:42:01 <minimal> ncopa: yes there's an alternative, leave it up to the package installer to do by hand. The change was intended to make it easier to use cloud-init and as the package is niche I felt it was acceptable to break policy then.
2020-09-24 14:43:02 <ncopa> we have traditionally never enabled services automagically. there have always been two steps: 1) install 2) enable to autostart
2020-09-24 14:43:20 <ncopa> not like apt-get install where it will start the service for you together with install
2020-09-24 14:43:36 <ncopa> so i understand that people react
2020-09-24 14:43:38 <minimal> Agreed, and for any other package I wouldn't have such a addition to post-install.
2020-09-24 14:44:53 <ncopa> so, the problem is: i have heard that cloud-init may solve my install to cloud problem, and want to check it out. i find a package for it and install it to see what it is/does.
2020-09-24 14:45:09 <minimal> However as I've tried to point out in the past, cloud-init is intended for 1st time boots so there's no reasonable reason for someone to install the package if not building an OS image. It doesn't work for Docker containers, doesn't work with namespaces in general, its designed to hook into OpenRC (or other init) and run during boot
2020-09-24 14:45:10 <ncopa> and boom. my system suddenly is reinstalled from scratch?
2020-09-24 14:46:24 <minimal> reinstalled? nope, the current post-install with setup 4 cloud-init init.d services plus disable mdev init.d and enable eudev init.d services
2020-09-24 14:46:49 <dalias> ncopa, indeed, thats highly unacceptable
2020-09-24 14:46:54 <ncopa> right. it will just reconfigure my system to use udev (potentially make it unbootable - even if thats unlikely)
2020-09-24 14:47:13 <dalias> i would be FUCKING PISSED if i apk added something and it trashed my system
2020-09-24 14:47:32 <dalias> this should never happen
2020-09-24 14:47:45 <ncopa> understandable. i want find a solution for this
2020-09-24 14:47:55 <dalias> it is no harder to have it just drop a script you *manually run* if you want it
2020-09-24 14:48:14 <dalias> setup-cloud-init.sh or something
2020-09-24 14:48:38 <ncopa> i guess that is one option
2020-09-24 14:48:51 <ncopa> i need to test how this works and how it is supposed to work
2020-09-24 14:49:02 <ncopa> i tried to read cloud-init docs the other week
2020-09-24 14:49:06 <minimal> With warning in the setup-cloud-init.sh script saying "Don't run this if you don't know what you're doing?"
2020-09-24 14:49:26 <dalias> (automated deploy tools can do that just fine)
2020-09-24 14:50:00 <dalias> make it need --yes or something to run without prompt
2020-09-24 14:50:22 <ncopa> setup-cloud-init.sh --dont-print-the-warning-i-know-exactly-what-im-doing-and-will-not-blame-the-alpine-devs-for-anything-:)
2020-09-24 14:50:57 <ncopa> the trailing ) makes sure that the arg is properly escaped :)
2020-09-24 14:51:21 <ncopa> other option may be to have a magic env var
2020-09-24 14:51:28 <minimal> dalias: cloud-init *IS* an autodeployment tool
2020-09-24 14:52:02 <ncopa> CLOUD_INIT_AUTO_SETUP="I know what I am doing" apk add cloud-init
2020-09-24 14:52:19 <ncopa> and if the env var is not set, the post-install will not do anything
2020-09-24 14:52:32 <dalias> no its not
2020-09-24 14:52:39 <minimal> ncopa: On a general point, am happy to help you out with figuring out cloud-init.
2020-09-24 14:52:55 <ncopa> minimal: thanks! i will need the help :)
2020-09-24 14:53:09 <dalias> the deployment tool runs on the deploying system not the deployed one
2020-09-24 14:53:23 <dalias> this is its helper in the deployed system
2020-09-24 14:53:41 <ncopa> dalias: do you ahve experience with cloud-init?
2020-09-24 14:53:42 <dalias> and should not do anything by virtue of being installed/present
2020-09-24 14:53:51 <dalias> only by virtue of being *run*
2020-09-24 14:54:58 <dalias> no, just conceptual model in which what theyre trying to do (abuse package manager as a way to run a helper in the deployed system) is badly wrong
2020-09-24 14:55:24 <dalias> and its easily fixed just by explicitly running the script
2020-09-24 14:56:11 <minimal> they?
2020-09-24 15:00:01 <ncopa> dalias: ok, i don't know how cloud-init is supposed to work
2020-09-24 15:00:43 <minimal> ncopa: I'll write a MR to remove the post-install changes and add a script for setup. I just wish this discussion had occurred before the merge rather than 2 weeks after it.
2020-09-24 15:01:35 <ncopa> minimal: the way I have always envisioned it was that you put a magic file (cloud-init config?) on the boot media (usb disk?) and when you boot first time, its found and picked up and will set up things for you
2020-09-24 15:02:23 <ncopa> possibly in combination with a boot option, so you dont accidentially reinstall your system by mistake due to having that config file on your usb
2020-09-24 15:02:47 <minimal> ncopa: cloud-init is simple, it has 4 init.d scripts run at different stages of boot to first setup network and then to use the relevant DataSource (i.e. AWS Metadata server, or NoCloud partition) to read the YAML file telling it what else to configure during boot
2020-09-24 15:03:06 <minimal> its a boottime-only application
2020-09-24 15:03:56 <ncopa> minimal: sorry for that. might be an idea to revert til we figured out how to do this properly - without surprises
2020-09-24 15:04:01 <ncopa> let me take care of that
2020-09-24 15:04:29 <ncopa> actually
2020-09-24 15:04:43 <ncopa> i would like to test it
2020-09-24 15:04:51 <minimal> ncopa: revert the existing MR? or let me submit a new MR without the post-install magic?
2020-09-24 15:05:19 <ncopa> i am thinking we could simply disable the package alltogheter. i guess it will not work anyway without the post-install?
2020-09-24 15:05:47 <minimal> ncopa: The alpine cloud-init functionality works in general (without or without the post-install stuff), I've been using it for about 1 year on Alpine.
2020-09-24 15:06:06 <minimal> ncopa: disable the package? what do you mean? remove it from Alpine?
2020-09-24 15:06:15 <ncopa> yes
2020-09-24 15:06:24 <minimal> ncopa: why?
2020-09-24 15:06:25 <ncopa> i guess we coudl simply remove the post-install script for now
2020-09-24 15:06:55 <ncopa> to prevent people from shooting themselves in the foot by installing it
2020-09-24 15:07:09 <minimal> ncopa: I've already indicated I can remote the post-install - that's a different matter from removing cloud-init completely from Alpine
2020-09-24 15:07:30 <ncopa> yeah, you are right.
2020-09-24 15:07:45 <ncopa> it was a stupid idea by me. sorry
2020-09-24 15:07:59 <minimal> I spent a lot of effort getting Alpine into upstream cloud-init
2020-09-24 15:08:49 <ncopa> thats awesome!
2020-09-24 15:09:10 <minimal> ncopa: with the init.d activation stuff removed from the post-install there's no danger
2020-09-24 15:09:23 <ncopa> is this ok? https://tpaste.us/N8vk
2020-09-24 15:09:42 <ncopa> it simply disables the post-install
2020-09-24 15:10:22 <minimal> right, but I'd also want to update the README then to mention those steps are manually necessary
2020-09-24 15:10:57 <ncopa> good point
2020-09-24 15:11:57 <minimal> FYI: https://github.com/canonical/cloud-init/pull/535
2020-09-24 15:12:20 <ncopa> so, how would I use cloud-init to set up a vm?
2020-09-24 15:14:14 <minimal> you're create an Alpine OS image including cloud-init, then load the image to the relevant cloud providers (i.e. in AWS create an AMI from the image), for KVM/QEMU just use the disk image directly, and then start the VM and specific relevant user-data as part of the VM creation
2020-09-24 15:15:59 <ncopa> in vkm/qemu, locally
2020-09-24 15:16:09 <ncopa> i will try set it up here locally
2020-09-24 15:16:28 <ncopa> either in libvirtd/virt-manager or via running qemu manually from command line
2020-09-24 15:16:57 <andypost[m]> Looks coreos ignition is only alternative to cloud-init
2020-09-24 15:17:27 <minimal> what I do here is use loop to mount a file that represents a disk, partition that loopback device, format partitions, etc, then use the static apk to create a base Alpine install inside the root partition I created and then chroot into and continue byuilding the OS image inside there
2020-09-24 15:18:00 <minimal> I've got an Ansible playbook I use here to drive it all, though the same stuff could be do in shell scripts for example
2020-09-24 15:18:13 <ncopa> ok, so its an alpine install basically
2020-09-24 15:18:40 <minimal> yes, that's why I mentioned you're installing cloud-init package when building an OS image
2020-09-24 15:18:42 <ncopa> ok let me create a disk image and do this manually
2020-09-24 15:18:50 <ncopa> thats what i though
2020-09-24 15:18:50 <minimal> There's no point installing on a normal machine
2020-09-24 15:19:10 <ncopa> good, then i think i understand things correctly
2020-09-24 15:19:42 <minimal> cloud-init itself doesn't actually run until you've actually booted the OS image you've created
2020-09-24 15:19:51 <ncopa> thats what i thought
2020-09-24 15:19:54 <dalias> minimal, sure there is. unshare(1), make some bind & overlay mounts, run the setup script inside
2020-09-24 15:20:35 <ncopa> minimal: do you have time to guide me through this now? (thank you for being patient!)
2020-09-24 15:21:07 <dalias> this kind of "sandbox thats mostly a clone of host" is becoming a standard idiom of mine for testing, debugging, etc
2020-09-24 15:21:29 <minimal> ncopa: Sure! I always intended to come talk to you about official Alpine cloud images once I'd got cloud-init into community (in time for 3.13 release)
2020-09-24 15:22:57 <minimal> ncopa: BTW as I actually do the chroot OS build with QEMU configured I build armv7, aarch64, and x86_64 using the same setup
2020-09-24 15:24:50 <ncopa> dalias: i suppose with unshare(1) i could create a disk image without being root?
2020-09-24 15:26:05 <ncopa> (which is something else I have been thinking of fora while, to build official disk images)
2020-09-24 15:27:11 <ncopa> btw.. i realized that virt-manager was not happy that i moved my vm image storage to zfs. it can apparently not create new disk images doe to fallocate not working on zfs or something
2020-09-24 15:27:25 <ncopa> but thats a problem for another rainy day
2020-09-24 15:28:36 <ncopa> minimal: do you recommend UEFI or bios boot?
2020-09-24 15:31:49 <ncopa> im thinking for official disk images we may want go for uefi, even if its slightly more complicated with a separate fat partition
2020-09-24 15:37:45 <ncopa> minimal: so when you use this disk image, will cloud-init modify the boot disk image, or does it depend on a separate empty vdisk?
2020-09-24 15:38:42 <minimal> ncopa: I'm using BIOS so far myself but have build UEFI images as well (fiddly to use with QEMU)
2020-09-24 15:39:01 <ncopa> ok. i'll stick to bios for now then
2020-09-24 15:41:54 <ncopa> hum.. why does not /dev/loop0p1 show up?
2020-09-24 15:42:48 <dalias> ncopa, not by mounting it. kernel attack surface is too big to let you mount actual disk-backed filesystems
2020-09-24 15:43:11 <dalias> if you had a fuse driver for it, or something that exposed it as a network share or similar, you could
2020-09-24 15:43:26 <dalias> that's assuming no root
2020-09-24 15:43:38 <dalias> if you have root then yes you can mount loop or real block devices in the mount namespace :)
2020-09-24 15:43:51 <ncopa> dalias: the challenge i have had has been to create a disk image without being root
2020-09-24 15:44:08 <Hello71> mtools does this but only for fat
2020-09-24 15:44:09 <minimal> ncopa: I'm work in hybrid BIOS/UEFI for a USB stick installer image, its fiddly too
2020-09-24 15:44:12 <ncopa> i suppose there are tricks for it,
2020-09-24 15:44:18 <dalias> imo there should be a tool like mkisofs but for ext4, etc.
2020-09-24 15:44:19 <ncopa> ueah mtools can do mcopy etc
2020-09-24 15:44:20 <Hello71> and the interface is... strange
2020-09-24 15:44:24 <dalias> rather than needing to mount
2020-09-24 15:44:30 <Hello71> dalias: mke2fs -d
2020-09-24 15:44:35 <dalias> hello71, oh?
2020-09-24 15:44:51 <ncopa> but how do i create that with paritions?
2020-09-24 15:44:59 <Hello71> although last I tried it was very slow for some reason
2020-09-24 15:45:10 <ncopa> or is it common with disk images without partitions
2020-09-24 15:45:23 <dalias> nice. yeah i think that'd work
2020-09-24 15:45:30 <Hello71> also ext* fuse was upstreamed to e2fsprogs
2020-09-24 15:45:33 <minimal> ncopa: regarding cloud-init modifying an image - its exactly the same as if you created a VM image manually - if you then boot the VM image it will be modified by the OS (including cloud-image), if however you duplicate the "gold image" and boot a VM using a copy then the original is unchanged
2020-09-24 15:45:54 <Hello71> before I think there were a few different implementations that didn't cover all of ext4
2020-09-24 15:47:29 <ncopa> minimal: understood. so cloud-init will change the partitions etc during first boot?
2020-09-24 15:49:56 <Hello71> ncopa: well you can use losetup -P, or losetup -o, or -i myimage@@offset
2020-09-24 15:50:33 <Hello71> e.g. mcopy -i image.img@@1M EFI ::EFI
2020-09-24 15:50:41 <Hello71> (maybe also need -r or somesuch)
2020-09-24 15:50:56 <minimal> looking at my Ansible playbook, basically I start by creating a directory to chroot use, create disk image: "truncate -s <size> <filename>", partition disk image file, using parted, run "losetup --partscan --show --find <disk image file>", format loopback partitions, mount partitions, use static apk to install base Alpine into chroot dir, etc
2020-09-24 15:51:53 <ncopa> ok. sounds like im on right track
2020-09-24 15:53:23 <minimal> minimal: well I've laid out the partitions when creating the disk image (i.e. swap part, root part, cloud-init partition if using it that way, etc). I shrink the disk image to be not much bigger than the OS. Cloud-init has modules for growpart and resizefs that can be configured (in your user-data) to grow things upon boot if wanted.
2020-09-24 15:54:16 <ncopa> what is cloud-init partition used for?
2020-09-24 15:54:23 <minimal> I could show you my Ansible playbooks or else show you the output of a Ansible run (which will log the resultant shell commands run by the playbook)
2020-09-24 15:54:46 <ncopa> oh... im running out of time. can we continue with this tomorrow?
2020-09-24 15:55:03 <ncopa> need to deal with something else now sorry
2020-09-24 15:56:23 <minimal> Originally cloud-init was designed to use a metadata service of a cloud provider, i.e. in AWS when a EC2 VM boots it can contact the Metadata server to retrieve YAML for both network and user-data settings. With NoCloud datasource instead config can be obtained from an ISO or FAT - I'm using a small FAT partition for my physical machine ready-to-boot images.
2020-09-24 15:57:34 <minimal> ncopa: No problem, happy to help. I can drop you an email perhaps rather than cluttering up IRC? I'm work on a MR today.
2020-09-24 15:58:22 <minimal> oops, I'll work on a MR today for the post-install and README changes.
2020-09-24 15:58:44 <artok> havin playbooks somewhere on public?
2020-09-24 15:59:50 <minimal> artok: not so far, though had thought about providing them in the future. Would need to tidy them up a bit first and document some stuff.
2020-09-24 16:03:56 <ncopa> minimal: sounds good. email sounds like a good idea too. thanks!
2020-09-24 16:04:18 <ncopa> minimal: and big thanks for helping out with this.
2020-09-24 16:05:03 <minimal> ncopa: just thinking I could give you a resultant minimal VM image to have a look at/test boot in QEMU, might make things clearer
2020-09-24 16:06:17 <ncopa> having a look at the ansible scripts might be good enough. im a bit curious how you create those things too
2020-09-24 16:06:31 <ncopa> there is a script somewhere to create bootable alpine images
2020-09-24 16:07:00 <ncopa> https://github.com/alpinelinux/alpine-make-vm-image
2020-09-24 16:07:05 <ncopa> i havent used it myself
2020-09-24 16:07:19 <minimal> yeah I'd looked at make-vm-image and make-chroot-image (filenames from memory) and decided a long time ago Ansible was better route for me
2020-09-24 16:07:49 <ncopa> need to run now. see you!
2020-09-24 16:07:50 <minimal> remember I'm building VMs and physical machine images for multi archs in the one playbook
2020-09-24 16:07:55 <minimal> ncopa: later
2020-09-24 17:11:09 <maxice8> ncopa: atools 19.5.5 is pushed, apkbuild-fixer is fixed and automatically sets -DCMAKE_BUILD_TYPE=None
2020-09-24 17:15:17 <maxice8> Seems like ruby is stuck on test_thread.rb
2020-09-24 17:17:24 <ikke> FUTEX_WAIT_PRIVATE..
2020-09-24 17:51:10 <maxice8> hello FUTEX_WAIT_PRIVATE my old friend...
2020-09-24 17:57:11 <insep_> i've stuck on you again...
2020-09-24 18:09:51 <dalias> what does None do?
2020-09-24 18:10:10 <dalias> ignore the project's debug/release bs and just use the CFLAGS you asked for? :)
2020-09-24 18:10:24 <maxice8> yes
2020-09-24 18:10:41 <maxice8> it is like --buildtype=plain from meson but less supported
2020-09-24 18:10:56 <maxice8> some projects will police what BUILD_TYPE you pass and will fail on None and default to Release
2020-09-24 18:11:17 <dalias> :/
2020-09-24 18:11:37 <maxice8> such is life
2020-09-24 18:12:36 <dalias> maxice8, can you tell what the stuck test is trying to assert?
2020-09-24 18:12:47 <maxice8> No clue
2020-09-24 18:12:59 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/ruby/ruby-2.7.1-r4.logv
2020-09-24 18:13:06 <maxice8> the line is just
2020-09-24 18:13:06 <maxice8> test_thread.rb           ......................
2020-09-24 18:13:14 <dalias> is this new?
2020-09-24 18:13:49 <maxice8> No clue
2020-09-24 18:14:14 <ikke> dalias: /home/buildozer/aports/main/ruby/src/ruby-2.7.1/ruby -I/home/buildozer/aports/main/ruby/src/ruby-2.7.1/lib --disable-gems -W0 bootstraptest.tmp.rb
2020-09-24 18:15:10 <dalias> does ruby implement its own mutex?
2020-09-24 18:15:23 <dalias> in the source i see a test_blocking_mutex_unlocked_on_fork
2020-09-24 18:15:42 <dalias> which, unless they do their own thing around fork and tracking mutexes, is a completely invalid expectation
2020-09-24 18:16:38 <dalias> looks like a lot of invalid stuff with fork in here
2020-09-24 18:16:51 <dalias> WHY do langs like ruby try to expose fork at all?
2020-09-24 18:17:01 <dalias> it's impossible to define a consistent meaning for fork in a HLL
2020-09-24 18:17:10 <ikke> dalias: partial backtrace: https://tpaste.us/x1ZJ
2020-09-24 18:18:27 <dalias> so it's almost surely just invalid stuff after MT fork...
2020-09-24 18:29:15 <dalias> why is the bt truncated?
2020-09-24 18:29:44 <ikke> truncated?
2020-09-24 18:29:51 <ikke> That's all there is
2020-09-24 18:36:50 <dalias> it should trace back to main or thread start
2020-09-24 18:49:18 <ikke> ah: "Backtrace stopped: frame did not save the PC"
2020-09-24 18:50:41 <ikke> dalias: this is from the parent process: https://tpaste.us/yNWl
2020-09-24 19:22:43 <dalias> maybe strace to see a better picture of what's going on?
2020-09-24 19:23:20 <dalias> i think we need to understand what the test is trying to assert, why it's failing, whether there's any chance of fixing it on their side, and if it matters whether there is
2020-09-24 19:33:44 <c705> mps: 5.8.11 is out
2020-09-24 20:26:01 <mps> c705: yes, I saw it yesterday, but don't have time now to upgrade. will do tomorrow or over weekend. sorry
2020-09-24 20:30:04 <c705> no worries, just fyi
2020-09-25 04:51:14 <maxice8> I'm thinking about a new lint for atools
2020-09-25 04:51:20 <maxice8> ALXX - version is unstable
2020-09-25 04:51:50 <maxice8> have a file that has regexes and packages and warn when people try to update to an unstable branch, like wireshark=3.3.x and anything uneven in GNOME
2020-09-25 05:40:16 <ncopa> morning
2020-09-25 05:40:22 <maxice8> morning
2020-09-25 05:40:23 <ncopa> so ruby build is deadlocking now
2020-09-25 05:40:36 <maxice8> Ikke and dalias discussed
2020-09-25 05:40:54 <ikke> conclusion was that we needed more info :P
2020-09-25 05:41:05 <ncopa> looks so yes :)
2020-09-25 05:41:32 <ncopa> so, i had a look at the ruby code when we talked about the gitlab issue the other day
2020-09-25 05:41:41 <ikke> right
2020-09-25 05:41:47 <ncopa> and i think there is a possible malloc after fork
2020-09-25 05:42:27 <ncopa> i will try reproduce this
2020-09-25 05:47:16 <Cogitri> Morning
2020-09-25 05:47:39 <Cogitri> maxice8: GNOME won't need that lint, it'll move to a new versioning scheme with the next version
2020-09-25 05:47:50 <Cogitri> So there will be no 3.39.x
2020-09-25 05:47:59 <maxice8> and adjacent gnome projects like flatpak ?
2020-09-25 05:48:12 <Cogitri> It'll be 40.alpha, 40.beta, 40.rc and 40
2020-09-25 05:48:59 <Cogitri> Not sure if other projects will follow suit, but we'd have to manually maintain a list of packages which follow the even==stable/uneven==development release version scheme
2020-09-25 05:50:06 <maxice8> no, we maintain a list of pkgname and a series of grep -E regexes that match unstable versions
2020-09-25 05:51:57 <maxice8> https://gitlab.alpinelinux.org/Leo/atools/-/commit/0d4faa388dd7ba3e284c38d52410d47aab01c93a
2020-09-25 05:55:38 <ncopa> i can reproduce ruby deadlock
2020-09-25 06:43:54 <clandmeter> ncopa: nice
2020-09-25 06:44:04 <clandmeter> and good morning
2020-09-25 06:56:45 <ikke> o/
2020-09-25 17:07:25 <ncopa> did anyone report the ruby deadlock upstream?
2020-09-25 17:14:06 <ikke> I haven't
2020-09-25 17:29:35 <ncopa> ok. i started to collect the backtraces of the processes, but i realized that there are not debugging symbols for gmp and zlib
2020-09-25 17:29:40 <ncopa> so im fixing that first
2020-09-25 17:36:15 <dalias> ncopa, what's the situation with libvirt?
2020-09-25 17:36:57 <dalias> are these new hangs stuff that was missed when toning-down the severity of my original patch, or are they somewhere else??
2020-09-25 17:43:56 <ncopa> dalias: i dont think i have covered all cases in the current patches
2020-09-25 17:44:15 <ncopa> i wish upstream could fix it :-/
2020-09-25 17:44:34 <ncopa> im trying to report ruby now
2020-09-25 17:44:42 <ncopa> collect the backtraces
2020-09-25 17:51:50 <mps> ikke: who merged ardour? https://distfiles.alpinelinux.org/distfiles/Ardour-6.3.0.tar.bz2 doesn't exist
2020-09-25 17:53:19 <Cogitri> https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12756 gitlab logs that
2020-09-25 17:53:26 <mps> correct location is https://community.ardour.org/srctar
2020-09-25 17:53:44 <mps> Cogitri: I'm not yet at my workstation
2020-09-25 17:56:40 <mps> https://github.com/Ardour/ardour/archive/6.3.tar.gz
2020-09-25 17:57:49 <ncopa> dalias: I reported ruby deadlock: https://bugs.ruby-lang.org/issues/17189 it is currently blocking our builders: https://build.alpinelinux.org/
2020-09-25 18:02:32 <mps> hm, didn't know that we have distfiles.a.o
2020-09-25 18:05:27 <mps> if it is planed to be used as source maybe it should be split by some hierarchy, by first character maybe?
2020-09-25 18:20:40 <Cogitri> We only really use it for software which don't have tarballs or whose tarballs are broken
2020-09-25 18:25:18 <mps> hmm, I'm looking at ardour source and it looks correct, "https://community.ardour.org/src/Ardour-$pkgver.tar.bz2
2020-09-25 18:28:39 <mps> aha, 'abuild -r' from my machine uploaded it on distfiles.a.o. so I think it is fixed now
2020-09-25 18:31:25 <mps> uhm, no. need to 'auild checksum' and push changes
2020-09-25 18:56:45 <mps> if someone know how this python 'waf' works would be nice to fix ardour build. It build on my local with error that it can't find libardour.so.{something}
2020-09-25 19:07:38 <ikke> All sources that are downloaded appear on distfiles
2020-09-25 19:08:11 <ikke> Abuild, if set up that way, will first check distfiles, and then the given source
2020-09-25 19:13:23 <dalias> ncopa, i posted on it
2020-09-25 19:14:37 <dalias> if ruby is actually trying to do this i suspect they have serious bugs on glibc too
2020-09-25 19:15:00 <dalias> since basically the whole std library except malloc (that they special case) is unsafe to use after fork in glibc too
2020-09-25 21:13:05 <maxice8> can x86 and x86_64 builders be reset ?
2020-09-25 21:26:02 <maxice8> they are stuck on ruby still
2020-09-25 21:28:28 <ikke> Problem is that they will be stuck right again
2020-09-25 21:28:37 <ikke> oh
2020-09-25 21:30:11 <ikke> done
2020-09-25 22:10:46 <timlegge> imagemagick-perlmagick needs to be rebuilt see issue #11977 there is a new version 7.0.10.30 so a MR for that would likely be best
2020-09-25 22:23:58 <maxice8> algitbot: retry master
2020-09-25 22:24:43 <timlegge> confirmed rebuilding imagemagick on edge fixes the issue #11977
2020-09-25 22:36:22 <maxice8> algitbot: retry master
2020-09-25 23:10:09 <maxice8> algitbot: retry master
2020-09-25 23:24:38 <maxice8> Seems like x86_64 is stuck
2020-09-25 23:24:56 <maxice8> something hard-depends on gdbm=1.14.0 while python3 is trying to install gdbm-dev=1.18.1
2020-09-25 23:52:44 <maxice8> yeah the x86_64 builder seems to be malformed
2020-09-26 01:05:36 <evilcat> yo. I'm using this script and am having some trouble getting networking working in qemu, would anyone be able to give me a hand setting up a tun/tap interface so I can use the arm version of alpine?https://gist.github.com/tuxmartin/f348d4247beda04e6029366da494f164at the moment I'm building a tun tap interface like this:sudo ip tuntap add dev tap3
2020-09-26 01:05:36 <evilcat> mode tapsudo ip link set up dev tap3sudo ip link set tap3 master br99sudo sysctl -w net.ipv4.ip_forward=1and have made a bridge in networkmanagerI'm using these args to start the 'qemu-system-arm' '-net nic,vlan=0 -net tap,vlan=0,ifname=tap3' I'm not 100% if I'm doing this correctly as when I do ifconfig, I don't see any interfaces and in
2020-09-26 01:05:37 <evilcat> /sys/devices/virtual/net besides lo
2020-09-26 03:13:42 <c705> qemu-system-x86_64 package seems broken, making a bug now
2020-09-26 03:22:50 <dalias> what goes wrong?
2020-09-26 03:28:23 <c705> dalias: https://termbin.com/7fe5
2020-09-26 03:28:34 <c705> missing so:libcdda_interface.so.0
2020-09-26 03:30:28 <maxice8> waiting for x86_64 to finish rebuilding stuff
2020-09-26 03:30:38 <c705> ah
2020-09-26 03:30:45 <maxice8> somehow the x86_64 is busted and it is not even possible to rebuild python3
2020-09-26 03:30:50 <c705> bad timing?
2020-09-26 03:38:42 <maxice8> yes
2020-09-26 05:30:04 <maxice8> x86_64 builder needs a look at, it can't install gdbm for rebuilds
2020-09-26 05:30:57 <maxice8> @Ikke
2020-09-26 05:47:49 <maxice8> Can someone look at the x86_64 builder ?
2020-09-26 06:35:34 <mps> looks like infra team (one man band, now) still sleeps
2020-09-26 06:36:00 <mps> or have private life
2020-09-26 06:48:46 <clandmeter> mps: I'm stil here!
2020-09-26 06:49:04 <clandmeter> But even then I can't access x86
2020-09-26 06:51:37 <mps> clandmeter: ah, nice to see you are active :)
2020-09-26 06:52:03 <mps> also I can't access it
2020-09-26 06:57:22 <ikke> I'm awake now :)
2020-09-26 06:57:28 <maxice8> :D
2020-09-26 06:57:43 <mps> ikke: \o/
2020-09-26 06:58:54 <maxice8> Can you look at x86_64 builder ? it can't install gdbm-dev to rebuild python3
2020-09-26 06:59:25 <ikke> yeah, was alreayd looking
2020-09-26 06:59:30 <maxice8> ty
2020-09-26 07:00:38 <ikke> It now continues
2020-09-26 07:01:25 <maxice8> build.a.o still shows it failing
2020-09-26 07:01:41 <ikke> I'm looking at the logs
2020-09-26 07:05:20 <maxice8> could it be a stray dependency from .ruby-makedepends ?
2020-09-26 07:05:48 <ikke> Yes and no
2020-09-26 07:05:59 <ikke> It was gdb, which was manually installed
2020-09-26 07:06:04 <maxice8> oh
2020-09-26 07:08:20 <ikke> I think gdb needs to be rebuilt as well (if it's not already happening)
2020-09-26 07:08:31 <ikke> Hmm, no
2020-09-26 07:08:33 <ikke> nm
2020-09-26 07:09:06 <maxice8> but it doesn't link against libgdbm.so.4
2020-09-26 07:09:15 <ikke> No
2020-09-26 07:10:09 <maxice8> yay
2020-09-26 07:10:12 <maxice8> thanks
2020-09-26 07:10:17 <maxice8> :D now x86_64 will be the backlogged one, not s390x
2020-09-26 07:10:22 <ikke> heh
2020-09-26 07:11:34 <c705> yay
2020-09-26 07:11:49 <ikke> mutt failed
2020-09-26 07:11:56 <ikke> hm
2020-09-26 07:12:56 <maxice8> pushed rebuild for cyrus-sasl
2020-09-26 07:13:52 <maxice8> somehow I'm missing packages with my usage of lua-aports
2020-09-26 07:24:22 <ikke> maxice8: ugh
2020-09-26 07:24:26 <ikke> you pushed a merge commit?
2020-09-26 07:24:36 <maxice8> apparently yes
2020-09-26 07:24:59 <ikke> 778c78b
2020-09-26 07:25:10 <ikke> 778c78b01cfeeee61adf4f19aa3f16e9080e1171
2020-09-26 07:39:25 <maxice8> algitbot: retry master
2020-09-26 07:40:14 <maxice8> algitbot: retry master
2020-09-26 07:40:50 <ikke> maxice8: is there a build dependency missing?
2020-09-26 07:41:00 <ikke> skopeo is now failing
2020-09-26 07:41:12 <maxice8> due to cyrus-sasl not being rebuilt even though I revbumped it
2020-09-26 07:41:14 <maxice8> indirect deps ?
2020-09-26 07:43:37 <ikke> hmm, cyrus-sasl is in main
2020-09-26 07:43:53 <ikke> and /home/buildozer/packages/main/x86_64/cyrus-sasl-2.1.27-r9.apk is present
2020-09-26 07:44:57 <maxice8> huh
2020-09-26 07:45:04 <maxice8> it built against libgdbm.so.4 ??
2020-09-26 07:45:36 <ikke> cyrus-sasl-2.1.27-r9 depends on:
2020-09-26 07:45:41 <ikke> so:libgdbm.so.4
2020-09-26 07:47:17 <maxice8> should have been built against libgdbm.so.6
2020-09-26 07:49:04 <maxice8> seems like avahi is the clue
2020-09-26 07:49:17 <maxice8> let me rebuild avahi and see if I can then rebuild mpd locally
2020-09-26 07:55:55 <maxice8> https://build.alpinelinux.org/buildlogs/build-edge-x86_64/main/cyrus-sasl/cyrus-sasl-2.1.27-r9.log
2020-09-26 07:55:59 <maxice8> it installed gdbm-1.13.0 huh
2020-09-26 07:57:50 <maxice8> apparently it was main/heimdal which had -r3 built against gdbm-1.13
2020-09-26 09:29:04 <ikke> x86_64 is green again
2020-09-26 09:29:15 <maxice8> Thanks for taking care of the builders
2020-09-26 09:29:35 <ikke> no problem
2020-09-26 12:29:20 <maxice8> c705: the qemu breakage is on me
2020-09-26 12:29:40 <maxice8> I moved cdparanoia to community by mistake
2020-09-26 12:30:29 <maxice8> Speaking of which lua-aports doesn't populate the db with providers from subpkgs
2020-09-26 12:30:57 <maxice8> llvm10-dev provides llvm-dev but because it is not top level it is ignored
2020-09-26 16:07:00 <maxice8> @Ikke: s390x is stuck on ruby, please reset it, I have added !check for it
2020-09-26 16:07:05 <ikke> k
2020-09-26 16:07:06 <maxice8> x86 is also stuck on py3
2020-09-26 16:07:31 <ikke> should we open up an issue for that btw?
2020-09-26 16:07:36 <ikke> with a link to the upstream ruby issue
2020-09-26 16:08:00 <maxice8> yes please
2020-09-26 16:08:11 <maxice8> I won't be able to help much since i have no clue about FUTEX_WAIT_PRIVATE or C in general
2020-09-26 16:08:30 <ikke> Me neither
2020-09-26 16:08:35 <ikke> But just to keep track of things
2020-09-26 16:08:50 <ikke> and a reminder to enable to test suite again once it's fixed
2020-09-26 17:11:20 <ikke> maxice8: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11979
2020-09-26 22:30:44 <maxice8> fpc is now in testing/ :D
2020-09-27 08:14:16 <ikke> maxice8: ruby also needs to be rebuild for gdbm
2020-09-27 08:14:25 <maxice8> again ?
2020-09-27 08:14:30 <ikke>  so:libgdbm.so.4 (missing):
2020-09-27 08:14:33 <ikke>     required by: ruby-libs-2.7.1-r4[so:libgdbm.so.4]
2020-09-27 08:16:26 <ikke> how do you determine what needs to be rebuilt?
2020-09-27 08:17:16 <maxice8> `adep list gdbm`
2020-09-27 08:17:33 <ikke> does that also take gdbm-dev into account?
2020-09-27 08:17:44 <maxice8> yes
2020-09-27 08:17:46 <ikke> ok
2020-09-27 08:17:56 <maxice8> it uses lua-aports and checks against the object in the database not names themselves
2020-09-27 08:18:09 <maxice8> It was bumped on 6c8f869da8f25b0eb482285f638a92dabb795edd
2020-09-27 08:18:20 <maxice8> it seems like a ordering error caused it to be build with the wrong gdbm
2020-09-27 08:18:54 <ikke> (5/25) Installing gdbm (1.18.1-r0)
2020-09-27 08:19:20 <ikke> seems the correct version?
2020-09-27 08:19:32 <maxice8> yes
2020-09-27 08:19:35 <maxice8> 1.13.0 is the old version
2020-09-27 08:19:59 <ikke> sorry, wrong arch
2020-09-27 08:20:07 <ikke> on x86_64: (5/20) Installing gdbm-dev (1.13-r1)
2020-09-27 08:23:35 <ikke> maxice8: `abuild builddirs ruby gdbm` does list them in the correct order
2020-09-27 08:23:41 <ikke> s/abuild/ap
2020-09-27 08:23:42 <alpine-meetbot> ikke meant to say: maxice8: `ap builddirs ruby gdbm` does list them in the correct order
2020-09-27 08:37:03 <ikke> maxice8: This MR was also open for alembic: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/11395
2020-09-27 08:37:32 <maxice8> I'll include it
2020-09-27 08:38:45 <maxice8> thanks for bringing it to notice
2020-09-27 09:40:31 <mps> heh, apk with examples  https://www.cyberciti.biz/faq/10-alpine-linux-apk-command-examples/
2020-09-27 09:42:28 <ikke> "t uses PaX and grsecurity for Linux kernel protection."
2020-09-27 09:48:41 <mps> ofc, but anyway nice that someone wrote that
2020-09-27 09:49:16 <afontain_> # echo "alias update='apk update && apk  upgrade'" >> /.bashrc
2020-09-27 09:49:20 <afontain_> best part
2020-09-27 09:50:00 <mps> hmm, :)
2020-09-27 09:50:59 <mps> and another one https://www.cyberciti.biz/faq/how-to-upgrade-alpine-linux-3-4-to-3-5-xx/ but the title is 'How to upgrade Alpine Linux 3.11 to 3.12'
2020-09-27 10:39:20 <mps> can anyone can look at for loop in !12910 is it ok or should be written in some better format
2020-09-27 10:43:08 <maxice8> commented
2020-09-27 10:44:53 <mps> maxice8: thanks
2020-09-27 10:49:15 <mps> hope it is better now
2020-09-28 12:28:11 <ncopa> is Jean-Luis Fuchs (https://gitlab.freedesktop.org/jeanlf) active on IRC? I just want say thanks for following up the dbus issue.
2020-09-28 12:28:59 <ncopa> yes, its Ganwell
2020-09-28 12:34:16 <ncopa> tbh, i have been slightly concerned recently, that the amount of upstream bugs is overwhelming, and we tend to only do temp fixes (like disabling test suite) to keep the thing moving. So seeing that things are followed up and getting fixed upstream is really really nice. Thank you Ganwell!
2020-09-28 12:38:35 <ikke> ncopa: created this btw: https://gitlab.alpinelinux.org/alpine/aports/-/issues/11979
2020-09-28 12:38:41 <ikke> to follow up on for ruby
2020-09-28 12:39:45 <ncopa> thanks!
2020-09-28 12:40:13 <ncopa> im thinking that we should probably only disable the broken test
2020-09-28 12:40:27 <ncopa> rather than disable all tests
2020-09-28 12:40:31 <ikke> yup
2020-09-28 13:21:08 <dalias> :)
2020-09-28 14:00:37 <ncopa> I'm seldomly excited about new programming languages, but i find zig pretty interesting https://ziglang.org/
2020-09-28 14:00:45 <ncopa> first time i heard about it was today
2020-09-28 14:02:19 <Cogitri> Yeah, zig does seem pretty nice, but no OOP hurts a bit
2020-09-28 14:02:37 <Cogitri> I mean there certainly is a place for OOPless languages, I'm just rather used to it
2020-09-28 15:00:27 <minecrell> nmeum: Is there any chance for moving android-tools to community? It would be useful to have adb/fastboot in stable and we kind of need it for the stable branch in pmOS since we have lots of Android devices.
2020-09-28 15:00:27 <minecrell> nmeum: It's kind of outdated at the moment, I tried to check how hard it would be to upgrade and it's a terrible mess, Google broke all the patches again, moved code to whatever repositories and who knows what else...
2020-09-28 15:00:27 <minecrell> nmeum: It might be easier to build android-tools with clang as at least some of the patches could be dropped then
2020-09-28 15:01:48 <nmeum> yeah, updating android-tools really is annoying. that's also the reason why I haven't moved it to community yet
2020-09-28 15:02:45 <nmeum> I kind of prefer building with gcc to profit from the hardening options we enable in gcc, e.g. fortify source by default
2020-09-28 15:03:51 <nmeum> the preferable solution regarding android tools would probably be finding a way to built the commandline utilitizes in a way that doesn't require any downstream effort
2020-09-28 15:04:41 <nmeum> also: last time I checked android-tools didn't built with clang because of https://gitlab.alpinelinux.org/alpine/aports/-/issues/11140#note_72286
2020-09-28 15:05:00 <minecrell> nmeum: Sadly that doesn't sound like a solution Google would make possible, they just keep maintaining their mess :\
2020-09-28 15:07:04 <nmeum> this entire android-tools thingy is also currently not on the top of my priority list, I only use adb and fastboot ocasionally
2020-09-28 15:07:24 <nmeum> due to job change and such I really haven't had the time to work on it lately
2020-09-28 15:08:22 <minecrell> nmeum: Well, FWIW I use it quite often but I don't really care that it is outdated, it works just fine. I kind of doubt newer versions make it any better :P
2020-09-28 15:11:32 <Hello71> ncopa: did you see https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
2020-09-28 15:20:13 <mps> ncopa: we have zig for about 6 months in testing :)
2020-09-28 15:21:03 <mps> I don't have time to make it also on armv7, hope will have some time in a month or two
2020-09-28 15:42:35 <mps> Cogitri: could be 'no OOP' is strength of zig ;)
2020-09-28 15:43:16 <Cogitri> Depends on your application I suppose, UI development without OOP isn't fun
2020-09-28 15:46:19 <mps> I see zig as system programming language, and only one sane in this camp in last decade
2020-09-28 15:46:57 <Hello71> imo anything shifting c/c++ hegemony is probably good
2020-09-28 15:47:29 <Hello71> nothing wrong with C interop but C++ popularity is depressing
2020-09-28 15:48:29 <mps> (is the c++ programming language, I wonder :) )
2020-09-28 15:53:23 <mps> Hello71: https://tpaste.us/byML
2020-09-28 15:56:05 <Hello71> nah, that's crap
2020-09-28 15:56:08 <Hello71> nobody understands C++
2020-09-28 15:57:46 <mps> :)
2020-09-28 16:00:44 <Ariadne> i understand C++
2020-09-28 16:04:23 <dalias> all of it? :)
2020-09-28 16:04:48 <Ariadne> considering templates have been proven to be turing complete, i guess i don't
2020-09-28 16:09:08 <dalias> :)
2020-09-28 16:10:01 <toogley> does https://git.alpinelinux.org/ serve a purpose, given alpine has a gitlab?
2020-09-28 16:10:30 <mps> as mirror, yes
2020-09-28 16:10:31 <Ariadne> yes, lots of people have workflow that depends on how things were prior to adopting a forge
2020-09-28 16:10:56 <ikke> and it's the only thing that lists the full aports tree
2020-09-28 16:12:32 <ikke> and git.alpinelinux.org is still a backup for gitlab as well
2020-09-28 16:13:08 <toogley> ah
2020-09-28 16:13:24 <toogley> so gitlab doesn't show the full aports tree, because its too big i guess?
2020-09-28 16:13:29 <ikke> yes
2020-09-28 16:13:35 <ikke> it limits directories to 1000 entries
2020-09-28 16:15:34 <dalias> lol
2020-09-28 16:15:38 <dalias> i hate gitlab so much
2020-09-28 16:16:07 <toogley> :D
2020-09-28 16:16:11 <dalias> (the whole React idiom)
2020-09-28 16:16:44 <toogley> i think that's the cost of the convenience
2020-09-28 16:16:56 <mps> also I'm not happy but we don't have anything better (at least now)
2020-09-28 16:18:18 <mps> toogley: I don't think is because of convenience but because make infrastructure for distro is not simple task
2020-09-28 16:25:49 <Ariadne> gitlab was determined to be the least bad option when we decided to adopt a forge
2020-09-28 16:25:57 <Ariadne> we looked at pagure as well
2020-09-28 16:26:12 <ikke> And gogs/gitea
2020-09-28 16:26:25 <Ariadne> gitlab if it blows up at least we can call someone
2020-09-28 16:27:11 <Ariadne> people complain that fedora sysadmins gave up on pagure in favor of gitlab
2020-09-28 16:27:22 <Ariadne> but reality is, there's a lot of value in being able to yell at gitlab
2020-09-28 16:27:26 <Ariadne> if it breaks
2020-09-28 16:27:40 <Ariadne> with these other forges if they break, you get to keep both pieces
2020-09-28 16:28:41 <Ariadne> for distro scale operations, that is not realistic
2020-09-28 16:28:53 <ikke> And to be honest, gitlab has been quite stable for us. Except from making sure it's up-to-date, it does not require a lot of maintenance
2020-09-28 16:29:58 <Ariadne> right, time to commit crimes
2020-09-28 16:30:08 <Ariadne> aka resurrect gcc 9 for mips64
2020-09-28 16:30:12 <ikke> 
ACTION looks the other way

2020-09-28 16:34:11 <Ariadne> now, time to go on the builder and bring gcc 9 back there
2020-09-28 16:41:32 <Ariadne> with some luck, buildrepo will be smart enough to figure out my crimes
2020-09-28 18:11:59 <Ariadne> the crimes worked as expected
2020-09-28 18:12:00 <Ariadne> wow
2020-09-28 18:12:48 <ikke> Ariadne: w00t
2020-09-28 18:13:27 <Ariadne> i wasn't sure if it was going to work or if i would have to spell it out more
2020-09-28 18:13:49 <ikke> So no more failed to build gcc messages for now? :)
2020-09-28 18:14:06 <Ariadne> yes
2020-09-28 18:14:20 <Ariadne> i mean, it's all i can do for now
2020-09-28 18:14:24 <ikke> yeah, understood
2020-09-28 18:14:34 <Ariadne> figuring out whatever is wrong with gcc 10 on mips is a rabbit hole i'm not qualified to go down
2020-09-28 18:14:35 <Ariadne> ;)
2020-09-28 18:14:37 <ikke> The platform is not really allive right now
2020-09-28 18:14:56 <Ariadne> maybe loongson will revitalize it, but doubtful
2020-09-28 18:15:14 <ikke> They offered to sponsor hardware, right?
2020-09-28 18:16:14 <ikke> We need somewhere to host it
2020-09-28 18:17:39 <Ariadne> well even so, if gcc 10 is broken on mips64, it will be broken on mips64el too
2020-09-28 18:17:44 <Ariadne> that isn't an endianness bug
2020-09-28 18:18:18 <ikke> yeah, so they would need to put in effor to fix those bugs
2020-09-28 18:23:57 <dalias> ariadne, aiui from midipix, pagure maintainer is very responsive to problems
2020-09-28 18:24:07 <dalias> and pagure is actually nice
2020-09-28 18:24:22 <dalias> it's like "imagine github or gitlab if they weren't written by react fans"
2020-09-28 18:24:30 <Ariadne> dalias: sure, but pagure was incomplete at the time we had to make a decision on what forge to use.
2020-09-28 18:24:59 <dalias> i don't actually want a "forge", i want a BT, so i don't think i'll use it
2020-09-28 18:25:03 <dalias> but i do like it fairly well
2020-09-28 18:26:19 <Ariadne> (and pagure is still incomplete, which is why red hat wants to give up)
2020-09-28 18:27:23 <dalias> :/
2020-09-28 18:34:33 <Ariadne> ikke: there is also the problem that loongson hardware is apparently really buggy
2020-09-28 18:34:41 <ikke> Ariadne: that does not help
2020-09-28 18:34:56 <Ariadne> https://virtuallyfun.com/wordpress/2020/09/24/a-modern-risc-workstation-for-a-modern-government-era/ is a good read about loongson
2020-09-28 18:37:20 <dalias> :/
2020-09-28 18:37:33 <Ariadne> ikke: i also find it unlikely that loongson would actually be able to send us hardware, my attempts to buy loongson boards in the past resulted in money being sent and then the government saying no
2020-09-28 18:38:56 <Ariadne> in the blog, they went through a broker to buy the boards (who presumably did not tell CCP that they were intended for export)
2020-09-28 18:39:46 <ikke> "Clearly the tape had been opened several times for various inspections as this shipment was destined to be exported."
2020-09-28 18:40:43 <dalias> why are they hard to export?
2020-09-28 18:41:27 <Ariadne> dalias: i don't know, honestly
2020-09-28 18:41:49 <Ariadne> i think they see it as restricted technology
2020-09-28 18:41:56 <Ariadne> even though it is just a mips64 core
2020-09-28 18:43:03 <ikke> "The first time I had both memory slots populated, and the board crashed at 5% of the install"
2020-09-28 18:44:24 <Ariadne> all i know is, 2010 i contacted info@lemote.com and got all the way as far as wiring them the money.  then they just refunded and said they couldn't send to USA.
2020-09-28 18:44:48 <Ariadne> then i tried a few times on aliexpress, seller wouldn't send to USA
2020-09-28 18:49:01 <Ariadne> i doubt they will ship hardware outside china except to countries that are loyal to china
2020-09-28 18:49:08 <Ariadne> that has been the vibe i've gotten
2020-09-28 18:52:01 <Ariadne> https://virtuallyfun.com/wordpress/2020/09/28/adding-a-radeon-rx-570/
2020-09-28 18:52:06 <Ariadne> he's going to be disappointed
2020-09-28 18:52:17 <Ariadne> amdgpu driver is really buggy outside of x86
2020-09-28 19:04:19 <Hello71> I think their standards for "it works" are really low
2020-09-28 19:14:20 <tomreid> Good evening folks, can I ask how the firmware bundles served at https://dev.alpinelinux.org/archive/linux-firmware/ get built?
2020-09-28 19:15:15 <tomreid> built is probably the wrong word... packaged? curated?
2020-09-28 19:15:55 <ikke> packaged, indeed
2020-09-28 19:16:04 <ikke> hmm
2020-09-28 19:16:39 <ikke> tomreid: https://git.alpinelinux.org/aports/tree/main/linux-firmware/APKBUILD#n49
2020-09-28 19:16:41 <ikke> there
2020-09-28 19:17:14 <ikke> So a git archive export of git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
2020-09-28 19:18:41 <tomreid> Cool, that makes perfect sense.
2020-09-28 19:19:58 <tomreid> I'd found the aports link, but don't understand where the kernal/linux-firmware.git gets built into the archive file on the dev.alpinelinux.org/archive...
2020-09-28 19:20:28 <ikke> Someone with access to dev.alpinelinux.org would run abuild snapshot
2020-09-28 19:21:00 <ikke> it creates the archive and scp's it to dev.a.o
2020-09-28 19:21:19 <ikke> That archive is then fetch on the builders when building the actual package
2020-09-28 19:22:12 <tomreid> perfect - another piece of the puzzle slots into place.
2020-09-28 19:50:45 <Ariadne> ikke: alpine main successfully composed
2020-09-28 19:51:08 <Ariadne> ikke: it is a christmas miracle
2020-09-28 19:51:09 <Ariadne> :D
2020-09-28 19:51:10 <ikke> heh
2020-09-28 19:52:35 <u0jQx9gPyrYg> Cogitri: dunno which part of OOP you're missing from zig, but it can do: > Structs can have methods: Struct methods are not special, they are only namespaced functions that you can call with dot syntax.
2020-09-28 19:54:58 <Ariadne> u0jQx9gPyrYg: at least in Qt, inheritance is useful
2020-09-28 19:55:18 <u0jQx9gPyrYg> yeah, inheritance i was also thinking might be something that is useful
2020-09-28 19:56:05 <andypost[m]> Looks armhf and s390x builders hangs
2020-09-28 19:56:27 <Ariadne> i'm considering pushing a musl 1.2.1 update that switches malloc back to the old one
2020-09-28 19:56:56 <Ariadne> the current situation is causing lots of problems
2020-09-28 19:57:11 <Ariadne> and yes, those problems should be fixed, but we need to ship too
2020-09-28 19:59:44 <Ariadne> [13:53:58] <algitbot> edge/main/mips64: uploaded
2020-09-28 19:59:45 <Ariadne> !!!!!
2020-09-28 20:00:08 <ikke> \o/
2020-09-28 20:00:29 <Ariadne> of course, the way this was achieved was absolutely horrible
2020-09-28 20:00:30 <Ariadne> but
2020-09-28 20:00:45 <Ariadne> at least keeps things going :)
2020-09-28 20:01:25 <ikke> Sometimes you need to take practical decissions
2020-09-28 20:04:08 <Cogitri> Ariadne: Apparently the things getting stuck on FUTEX_WAIT_PRIVATE isn't due to new malloc
2020-09-28 20:04:28 <Ariadne> Cogitri: according to who?
2020-09-28 20:04:55 <Ariadne> and yes, it is not due to new malloc, but new malloc makes it worse.
2020-09-28 20:05:29 <Ariadne> i know this because 1.2.0 did not have these issues
2020-09-28 20:05:39 <Ariadne> and the big difference for 1.2.1 was new malloc
2020-09-28 20:05:58 <Ariadne> so yes, it is still technically broken programs, but new malloc makes the failure rate many orders of magnitude higher
2020-09-28 20:06:32 <Ariadne> the futex is due to locking, new malloc has more granular locking (this means more locks)
2020-09-28 20:06:39 <Ariadne> more locks = more opportunity for deadlock
2020-09-28 20:06:57 <Ariadne> we can always switch back to new malloc after 3.13 and continue fighting the fire
2020-09-28 20:06:59 <Cogitri> According to dalias
2020-09-28 20:07:07 <Ariadne> yes, but he is being pedantic
2020-09-28 20:07:34 <dalias> ariadne, the breakage exposed has nothing to do with mallocng
2020-09-28 20:07:42 <dalias> you can bisect and see if you don't believe me
2020-09-28 20:08:02 <Ariadne> dalias: how come we get these deadlocks on 1.2.1 and only 1.2.1 then?
2020-09-28 20:08:12 <dalias> because another bug was fixed in that interval
2020-09-28 20:08:13 <Ariadne> the only major difference was mallocng
2020-09-28 20:08:16 <dalias> no it's not
2020-09-28 20:08:18 <Cogitri> See the thread in https://gitlab.alpinelinux.org/alpine/aports/-/issues/11602#note_115785
2020-09-28 20:08:32 <dalias> the change is commit e01b5939b38aea5ecbe41670643199825874b26c
2020-09-28 20:08:43 <Ariadne> ok, well i am not sure a bugfix which introduces deadlocks everywhere is a good bugfix
2020-09-28 20:09:31 <Ariadne> dalias: ok
2020-09-28 20:09:43 <Ariadne> dalias: how can we solve these deadlocks
2020-09-28 20:09:54 <dalias> it both fixed a bug in musl (affecting applications without any UB) and caused the UB you're dealing with to be a predictable hang rather than randomly hang, work, or corrupt-memory
2020-09-28 20:10:16 <dalias> which one are you looking at now?
2020-09-28 20:10:26 <Ariadne> i'm talking at large
2020-09-28 20:10:31 <Ariadne> this is not a fire we can fight right now
2020-09-28 20:10:43 <Ariadne> i need to put the fire out, even if it still burns down a few houses
2020-09-28 20:11:08 <Ariadne> because like
2020-09-28 20:11:12 <Ariadne> python is hanging
2020-09-28 20:11:14 <Ariadne> ruby is hanging
2020-09-28 20:11:24 <Ariadne> a ton of other packages are hanging
2020-09-28 20:11:31 <dalias> for ruby it's clear that the test that's hanging is completely invalid
2020-09-28 20:11:47 <Ariadne> but it doesn't hang on musl 1.1
2020-09-28 20:11:51 <dalias> it's not clear whether ruby (or ruby applications) actually depends on what it's attempting to assert
2020-09-28 20:11:52 <Ariadne> or 1.2.0
2020-09-28 20:11:57 <dalias> it does sometime
2020-09-28 20:12:04 <Ariadne> and it doesn't hang on glibc
2020-09-28 20:12:13 <dalias> it crashes sometime too
2020-09-28 20:12:42 <Ariadne> we agree that the test is broken, but the problem is that we have builders stalling out
2020-09-28 20:13:04 <Ariadne> your predictable hang is making it where we have to restart the build process frequently
2020-09-28 20:13:08 <dalias> then disable the broken test in the mean time
2020-09-28 20:13:18 <Ariadne> and then it stalls out at 3 AM
2020-09-28 20:13:22 <Ariadne> on some other broken package
2020-09-28 20:13:26 <Ariadne> that was previously building fine
2020-09-28 20:13:33 <dalias> also i've given you a patch you can try in musl that makes it a predictable crash
2020-09-28 20:13:43 <dalias> http://ix.io/2yyD
2020-09-28 20:13:43 <Ariadne> and hours of time where builders could be building
2020-09-28 20:13:50 <Ariadne> are instead not building
2020-09-28 20:14:10 <dalias> i'm pretty sure this is safe to upstream
2020-09-28 20:14:18 <Ariadne> i mean, i guess
2020-09-28 20:14:29 <Ariadne> but a package which crashes in test suite is only marginally better
2020-09-28 20:14:40 <Ariadne> however it does provide immediate feedback
2020-09-28 20:14:43 <Ariadne> which is preferable
2020-09-28 20:14:47 <Ariadne> i'll apply that :)
2020-09-28 20:15:21 <dalias> well right now i keep hearing that this is some huge widespread breakage but we can't actually determine the scope and there are incomplete/half fixes in aports
2020-09-28 20:15:52 <dalias> and to know how to proceed with this we really need to know the scope of how much broken stuff there is
2020-09-28 20:16:26 <dalias> if it's a couple pieces of fdo/poetteringware and a couple other packages that are fixable, then we fix them and it's done
2020-09-28 20:16:27 <Ariadne> thats fine
2020-09-28 20:16:36 <Ariadne> this will at least allow us to collect that data
2020-09-28 20:16:45 <Ariadne> the problem is right now, for those of us maintaining builders
2020-09-28 20:16:53 <Ariadne> we log into irc and builder we maintain is hung
2020-09-28 20:16:59 <Ariadne> this is getting old :)
2020-09-28 20:16:59 <dalias> if it's language interpreters and not just the language interpreter but applications *in the interpreted language* depending on being able to do broken stuff with fork
2020-09-28 20:17:06 <dalias> when we have a much bigger problem to deal with
2020-09-28 20:17:21 <dalias> yes understood
2020-09-28 20:17:26 <dalias> i think this patch will help with that :)
2020-09-28 20:17:46 <dalias> getting the builders un-stuck so we can figure out the scope of breakage and what action is needed
2020-09-28 20:18:44 <Ariadne> btw builders emit logs to #alpine-commits
2020-09-28 20:18:51 <Ariadne> you may want to keep an eye on that channel
2020-09-28 20:20:31 <mps> heh, if dalias like red colors in #alpine-commits, sure
2020-09-28 20:21:12 <Ariadne> the problem with irc color abuse is not color coding build failures
2020-09-28 20:21:18 <mps> I call it 'red hot chilly peppers' :)
2020-09-28 20:21:19 <Ariadne> the problem is idiots running mIRC with dumb scripts
2020-09-28 20:21:21 <Ariadne> :)
2020-09-28 20:24:24 <mps> but your discussion leads me to try rebuild some big pkgs with musl 1.2.1, to see if there more 'bad' ones
2020-09-28 20:30:01 <mps> (and these bugs/issues deserves headline on 'big tech' news sites)
2020-09-28 20:36:21 <mps> timlegge: what is your opinion on removing perl-data-dumper pkg? perl already contains it
2020-09-28 20:47:33 <Ariadne> some things may require newer data-dumper
2020-09-28 20:49:52 <awilfox> fwiw, we (Adélie) are still willing to rebuild our world with that musl patch after 1.0 is branched, to try and shake out just how bad the situation is.  same thing we did with time64.  but I do agree Alpine should probably revert until *someone* does that.  people are going to be quite upset when what they feel is basic stuff starts hanging everywhere
2020-09-28 20:50:22 <awilfox> ideal correctness cannot come at the cost of real-world breakage when you are shipping production software
2020-09-28 20:50:27 <mps> I doubt, latest release is from 2018
2020-09-28 20:51:14 <mps> ^ about perl-data-dumper, not musl
2020-09-28 21:08:09 <Ariadne> awilfox: i'm just saying that we are teetering close to freeze
2020-09-28 21:08:28 <Ariadne> awilfox: if it crashes reliably, i'm fine with that.  i'm not fine with hanging reliably.
2020-09-28 21:08:43 <awilfox> oh then yeah
2020-09-28 21:08:58 <awilfox> dalias' linked patch above (2yyD) will do that.
2020-09-28 21:09:08 <Ariadne> yes, i know.  i've already pushed an update with it.
2020-09-28 21:16:36 <dalias> i agree this is a messy situation but i'm not so convinced about the conclusion
2020-09-28 21:17:21 <dalias> "we're knowingly shipping a system with memory corruption because the only simple path forward makes it deadlock instead" isn't a good position to be in either :/
2020-09-28 21:19:04 <dalias> having arrived here was a consequence of not having seen (and still not having a grasp on) the scope of software being shipped that has UB that [mostly] works as the authors intended on glibc but not on musl (or various other systems))
2020-09-28 21:20:14 <mps> yes, something which is bad, to ship software which we know is buggy and call release 3.13-stable
2020-09-28 21:20:35 <dalias> :/
2020-09-28 21:20:46 <mps> hmm, it have '13', so maybe it is ok :)
2020-09-28 21:21:57 <Ariadne> dalias: crashing reliably is fine.  hanging reliably is not.
2020-09-28 21:24:14 <andypost[m]> Maybe it's reason why 2 builders hanging
2020-09-28 21:29:18 <dalias> ok well let's get this change done
2020-09-28 21:56:12 <timlegge> mps: basically its the same versionas that included in the main perl.  Removing it would be fine
2020-09-28 21:57:40 <timlegge> need to see what packages depend and change depends to perl
2020-09-28 22:08:09 <dalias> there are problems with this patch and aio but nobody uses aio so you won't care
2020-09-28 22:08:14 <dalias> if i upstream it i'll fix them
2020-09-28 22:55:46 <kaniini> algitbot: retry master
2020-09-29 01:24:01 <minimal> queue build-edge-s390x and build-edge-armv7 appear to have been stuck for some time on python
2020-09-29 06:07:15 <ncopa> morning
2020-09-29 06:08:00 <ncopa> looks like python2 on s390x hangs in testsuite. looks like its threading test
2020-09-29 06:08:33 <ncopa> 0:05:18 load avg: 0.60 [341/400] test_threading
2020-09-29 06:10:23 <ncopa> python3 on armv7 hags on: test_cancel_make_subprocess_transport_exec (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ...
2020-09-29 06:21:40 <ncopa> i killed python build on armv7 and s390x and reboot the builders
2020-09-29 06:30:05 <mps> (kill is not political correct word, update CoC :) )
2020-09-29 06:30:13 <mps> good morning
2020-09-29 06:32:10 <mps> timlegge: thanks for looking at perl-data-dumper. will you create MR or ...?
2020-09-29 08:03:49 <maxice8> How do we handle dependencies of unittests ?
2020-09-29 08:04:33 <Cogitri> checkdepends ?
2020-09-29 08:04:44 <maxice8> then it won't be present when !check is set
2020-09-29 08:05:11 <maxice8> if you are using a switch like -DENABLE_UNITTESTS=ON then compilation will fail
2020-09-29 08:17:44 <Cogitri> Ah, if it's required during compilation I put it in makedepends
2020-09-29 09:11:00 <ikke> maxice8: libgpod is failing with dependecy issues
2020-09-29 09:11:56 <maxice8> oh
2020-09-29 09:12:19 <maxice8> lets try again
2020-09-29 09:13:01 <maxice8> algitbot: retry master
2020-09-29 09:14:59 <maxice8> algitbot: retry master
2020-09-29 09:49:27 <timlegge> mps sure I can look tonight
2020-09-29 09:51:34 <dne> fwiw, the patch in musl-1.2.1-r2 doesn't seem to have "helped" for emacs, i.e it still hangs in setrlimit (when nofiles limit > FD_SETSIZE)
2020-09-29 09:57:34 <dne> hm, but there's https://git.musl-libc.org/cgit/musl/commit/?id=a5aff1972c9e3981566414b09a28e331ccd2be5d
2020-09-29 10:04:42 <mps> timlegge: thanks again. `ap revdep perl-data-dumper' in testing shows only hw-probe, and in community only imapsync and perl-radiusperl
2020-09-29 10:07:28 <mps> and ofc, we are not in hurry
2020-09-29 10:33:06 <mps> https://lists.freedesktop.org/archives/mesa-announce/2020-September/000600.html
2020-09-29 10:33:32 <mps> mesa 20.2.0
2020-09-29 10:33:53 <maxice8> Waiting for .1
2020-09-29 10:34:05 <mps> I hope that panfrost driver will be better now
2020-09-29 10:34:26 <mps> .1 will be probably in two weeks
2020-09-29 10:35:31 <ncopa> i have a dockerfile that will create a bootable alpine disk image when run
2020-09-29 10:35:57 <ncopa> it will copy id_*.pub to /root/.ssh/authorized_keys
2020-09-29 10:36:56 <ncopa> it currently requires docker --privileged so it can mount the image to run extlinux --install, which requires a mounted directory
2020-09-29 10:37:19 <ncopa> i dont know if it would be possible ti install extlinux without a mounted dir
2020-09-29 10:37:41 <ncopa> could maybe use grub also, but i'd prefer not
2020-09-29 10:38:34 <mps> hmmm, zig pass build with musl 1.2.1 but crystal didn't
2020-09-29 10:39:16 <mps> error msg: runs subcommand in preference to a filename Invalid memory access (signal 11) at address 0x7fa4f3c444f
2020-09-29 10:39:46 <mps> huh :(
2020-09-29 12:30:01 <minimal> From looking at the output of https://build.alpinelinux.org/ I'm seems that the builders work in a batches before pushing the created packages to storage. With the recent builder hang issues wouldn't it be better, even temporarily, to have the builders to store each individual package once its built to avoid having to rebuild some packages again and again because 1 of the packages in the batch is causing the builder to hang?
2020-09-29 12:33:33 <Hello71> if we're going full USE flags then shouldn't it be -DENABLE_UNITTESTS=$(options_has check && echo ON || echo OFF)?
2020-09-29 12:33:54 <maxice8> we are going full USE flags /
2020-09-29 12:33:55 <maxice8> ?
2020-09-29 12:42:37 <andypost[m]> build-edge-armhf hangs on k3s from yesterday
2020-09-29 12:44:17 <ikke> stopped it
2020-09-29 12:48:44 <mps> how we resolve same executable names in different pkgs?
2020-09-29 12:49:04 <maxice8> rename one of them
2020-09-29 12:49:24 <maxice8> by same name you mean same path or just the final name that appears in cmd:
2020-09-29 12:50:19 <mps> rancid have /usr/bin/par and I'm preparing par (paragraph format-er) with same executable name
2020-09-29 12:50:42 <mps> yes, same path and name, fullname
2020-09-29 12:51:56 <mps> !13082
2020-09-29 12:55:12 <maxice8> https://lists.llvm.org/pipermail/llvm-dev/2020-September/145320.html
2020-09-29 12:57:51 <mps> I thought I read it this morning but was for 6800 not 68000 :)
2020-09-29 13:18:13 <ikke> maxice8: Anything significant in that message?
2020-09-29 13:18:19 <maxice8> no, just sharing
2020-09-29 13:18:24 <ikke> k
2020-09-29 13:18:35 <maxice8> unless....
2020-09-29 13:18:38 <maxice8> m68k Alpine LInux  :^)
2020-09-29 13:18:42 <ikke> heh
2020-09-29 13:19:59 <mps> 6800{0} are better designed CPUs than intel
2020-09-29 13:20:13 <ikke> maxice8: py3-inquirer patch fails to apply
2020-09-29 13:20:51 <maxice8> looking into it
2020-09-29 13:31:37 <maxice8> how is that in when we don't even have py3-blessed ?
2020-09-29 13:50:45 <maxice8> algitbot: retry master
2020-09-29 13:51:05 <maxice8> algitbot: retry master
2020-09-29 13:51:12 <maxice8> algitbot: you'll keep going until you get py3-blessed before py3-inquirer
2020-09-29 13:51:27 <Hello71> isn't that what depends are for
2020-09-29 13:51:50 <ikke> Unless there is a dependency cycle somehow
2020-09-29 13:52:27 <maxice8> algitbot: retry master
2020-09-29 13:54:01 <maxice8> @PureTryOut could you check out !13070
2020-09-29 14:01:03 <Ariadne> I actually would like to get alpine going on my amiga
2020-09-29 14:03:22 <ikke> maxice8: conntract fails on the builders as I predicted: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/12614#note_114855
2020-09-29 14:03:41 <ikke> (as I experienced myself as well)
2020-09-29 14:04:00 <ikke> They did move the setcap to package but did not remove the sudo invokation from the build script
2020-09-29 14:04:24 <ikke> 
ACTION needs to remove sudo from the CI containers

2020-09-29 14:05:27 <ikke> 
ACTION is puzzled why it only fails on armv7, though

2020-09-29 14:14:34 <Ganwell> Cogitri: Our current dbus-fork-malloc fix is upstreamed: https://1042.ch/7, I am working on a better fix
2020-09-29 14:15:26 <Ariadne> great work
2020-09-29 14:17:15 <Cogitri> Nice :)
2020-09-29 14:28:18 <ikke> ncopa: algitbot still reports commit hashes that are too short to be unique
2020-09-29 16:01:42 <dsm42> Ariadne:  I used to run minix on my atari st  :-)   Full os build was  about 2.5 days :-)
2020-09-29 18:10:44 <Ariadne> dsm42: yeah for m68k port we would probably use qemu since it will assuredly be faster (although i have been considering picking up a Vampire upgrade board for my amiga, which would give it a ~500mhz m68k cpu)
2020-09-29 18:13:37 <Ariadne> http://wiki.apollo-accelerators.com/doku.php/vampire:vsa-v4:start
2020-09-29 18:13:47 <Ariadne> there is also the vampire4 board, which is 1ghz 68030
2020-09-29 18:20:32 <dalias> anyone wanna take a guess at what this might be? http://ix.io/2zbN
2020-09-29 18:22:33 <insep_> crash instead of hanging when doing unsafe stuff with fork?
2020-09-29 18:26:55 <dalias> no that's
2020-09-29 18:26:55 <dalias>  src/process/fork.c  | 2 +-
2020-09-29 18:26:56 <dalias>  src/thread/__lock.c | 1 +
2020-09-29 18:27:53 <mps> dalias: if I have (and I have) to report these fork bugs to upstream how I can explain to upstreams in few words/sentences?
2020-09-29 18:28:31 <mps> or, do we have url to post to upstream
2020-09-29 18:29:16 <mps> I think crystal lang also have this problem
2020-09-29 18:32:57 <dalias> when the parent is multithreaded, the forked child runs in a restricted context where it can only call AS-safe functions
2020-09-29 18:33:14 <dalias> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html
2020-09-29 18:33:21 <dalias> A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called.
2020-09-29 18:35:47 <mps> dalias: thank you :)
2020-09-29 19:27:43 <Hello71> Linux also specifies: *  After a fork() in a multithreaded program, the child can safely call only async-signal-safe functions (see signal-safety(7)) until such time as it calls execve(2). https://www.man7.org/linux/man-pages/man2/fork.2.html
2020-09-29 19:31:00 <dalias> hello71, yes. the problem is that glibc has a malloc-specific exception for this that mostly masks the problem, since malloc is the most common violation of the rule, and the others are all things that are called very rarely, so the chance of hitting the case where their lock is held is very low
2020-09-29 19:31:28 <dalias> in the case of ruby it looks like they expect a fully unrestricted child environment :(
2020-09-29 19:33:34 <Hello71> why is it still unsafe to call such functions after forking if you ensure that all threads are synchronized to be not calling libc functions?
2020-09-29 19:33:51 <Hello71> or is it practically safe but theoretically unspecified
2020-09-29 19:37:16 <dalias> pretty much that
2020-09-29 19:37:29 <dalias> but such synchronization is nontrivial
2020-09-29 19:37:38 <dalias> you'd have to construct a synchronization on AS-safe functions
2020-09-29 19:38:07 <Ariadne> why can't you just
2020-09-29 19:38:17 <Ariadne> have a mutex for every thread, with a condvar
2020-09-29 19:38:28 <Ariadne> that sleeps all threads except the one calling fork
2020-09-29 19:38:40 <Ariadne> post-fork in parent, signal using the condvar
2020-09-29 19:38:46 <Ariadne> post-fork in child, release all locks
2020-09-29 19:38:51 <Ariadne> should be synchronized i would think
2020-09-29 19:40:05 <Ariadne> i mean, i am pretty sure that is the whole point of pthread_atfork(2), to enable building such a synchronization mechanism
2020-09-29 19:40:14 <Ariadne> erf (3)
2020-09-29 19:42:01 <Ariadne> threads pretty much suck though
2020-09-29 19:42:14 <Ariadne> people knock multiprocess architecture but it is honestly better in many ways
2020-09-29 19:42:37 <Hello71> yes, non blocking event loop is the future. node.js is web scale
2020-09-29 19:43:08 <skarnet> galaxy brain comment right here
2020-09-29 20:10:15 <Ariadne> Hello71: multiprocess architecture has nothing to do with node.js
2020-09-29 20:10:39 <Hello71> I mean for thrads
2020-09-29 20:10:41 <Hello71> e
2020-09-29 20:10:49 <Ariadne> in multiprocess architecture, instead of having threads, you posix_spawn helper programs with socketpairs passed to them
2020-09-29 20:11:05 <Ariadne> this yields better security and resiliency
2020-09-29 20:11:09 <Hello71> or, historically, fork
2020-09-29 20:11:26 <Ariadne> yes -- historically.
2020-09-29 20:14:10 <dalias> ariadne, mutex and condvar aren't as-safe
2020-09-29 20:14:26 <Ariadne> ok
2020-09-29 20:14:35 <Ariadne> duplicate it yourself with futex syscall directly :)
2020-09-29 20:14:37 <Hello71> dalias: I still don't see why that's a problem
2020-09-29 20:14:37 <dalias> and you can't unlock the mutex in the child
2020-09-29 20:14:46 <dalias> that's UB because you're not the owner :)
2020-09-29 20:14:56 <Ariadne> you forked
2020-09-29 20:15:03 <Ariadne> that means you are the owner by default
2020-09-29 20:15:04 <dalias> right but fork doesn't make you the owner
2020-09-29 20:15:04 <Ariadne> :P
2020-09-29 20:15:26 <dalias> for mutex types that track the owner, *mechanically* this doesn't work
2020-09-29 20:15:45 <Ariadne> true
2020-09-29 20:15:45 <dalias> and for pshared mutexes in shared memory, *conceptually* it doesn't work
2020-09-29 20:16:01 <Ariadne> 
ACTION packages glibc ^_^

2020-09-29 20:16:02 <dalias> the core issue here is that the whole concept of fork is fundamentally wrong and broken
2020-09-29 20:16:10 <Ariadne> just kidding
2020-09-29 20:16:45 <dalias> a copy of the execution context of the parent just isn't an appropriate context for the child to execute in
2020-09-29 20:17:03 <dalias> and it happens even without threads, though patching it up is more managable
2020-09-29 20:17:11 <dalias> btw this go issue on the ml is weird
2020-09-29 20:17:25 <Ariadne> which go issue on which ml
2020-09-29 20:18:12 <Ariadne> oh i see
2020-09-29 20:18:26 <Ariadne> i noticed similar behavior with go 1.14 on mips
2020-09-29 20:18:37 <Ariadne> my conclusion is that the go event loop does weird shit
2020-09-29 20:20:13 <Ariadne> i wish there was posix_spawnattr_chroot()
2020-09-29 20:20:32 <Ariadne> that is the only thing blocking apk from using posix_spawn over fork+execve
2020-09-29 20:20:44 <Hello71> why does it fstat whoami anyways
2020-09-29 20:21:01 <Ariadne> why does what fstat whoami
2020-09-29 20:21:09 <Hello71> https://www.openwall.com/lists/musl/2020/09/29/6/2
2020-09-29 20:21:44 <Ariadne> oh, the go thing?
2020-09-29 20:21:47 <Ariadne> who fucking knows
2020-09-29 20:21:54 <Ariadne> i was going to say -- apk does not fstat whoami :P
2020-09-29 20:22:19 <Hello71> first I thought it was executing it, so I looked for a fork, but there isn't any
2020-09-29 20:22:33 <Ariadne> dalias: any thoughts on adding a posix_spawnattr_chroot_np() to musl?
2020-09-29 20:23:02 <dalias> ariadne, sounds like a good-ish idea
2020-09-29 20:23:03 <Ariadne> dalias: i will be happy to get that standardized with austin group btw
2020-09-29 20:23:49 <Ariadne> dalias: yeah, we need it for apk in order to move to posix spawn because we need to chroot when --root option is used
2020-09-29 20:24:03 <dalias> ariadne, that one you can't get standardized
2020-09-29 20:24:07 <dalias> chroot is outside the scope of the standard
2020-09-29 20:24:14 <Ariadne> damn
2020-09-29 20:24:25 <Ariadne> well, i will be happy to add it to glibc too
2020-09-29 20:24:25 <dalias> but can do on libc-coord
2020-09-29 20:24:31 <dalias> :)
2020-09-29 20:29:11 <Hello71> oh, it doesn't actually *run* it until CombinedOutput
2020-09-29 20:33:32 <dalias> ?
2020-09-29 20:33:55 <Hello71> whoami
2020-09-29 20:34:24 <dalias> solved the problem anyway
2020-09-29 20:34:33 <dalias> it was an invalid sigprocmask
2020-09-29 20:38:25 <dalias> so ariadne, mps, & friends..
2020-09-29 20:38:44 <Ariadne> that's interesting
2020-09-29 20:38:46 <dalias> <dalias> anyone wanna take a guess at what this might be? http://ix.io/2zbN
2020-09-29 20:38:59 <Ariadne> i wonder if sigprocmask is related to my mips64 issue on go
2020-09-29 20:41:32 <mps> dalias: guess without looking at git log?
2020-09-29 20:41:38 <Hello71> dalias: you missed a bunch of fork locks? seems maybe related to your grumbling about abort
2020-09-29 20:41:56 <dalias> no, its more exciting than that i think
2020-09-29 20:42:47 <dalias> mps, right :)
2020-09-29 20:42:56 <Hello71> musl always aborts on fork as-safe abuse?
2020-09-29 20:42:58 <mps> heh
2020-09-29 20:43:20 <dalias> there is no git log because this is just git diff of checkedout tree vs index :-p
2020-09-29 20:43:30 <dalias> hello71, no, that's the 2-line patch already published
2020-09-29 20:44:00 <Hello71> wasn't that "aborts instead of hanging"
2020-09-29 20:44:04 <mps> why syslog change, this is uncomprehensible to me
2020-09-29 20:44:27 <Ariadne> dalias: something that is going to annoy me? :)
2020-09-29 20:45:44 <dalias> quite the opposite i think
2020-09-29 20:46:16 <dalias> modulo possible mistakes, this is all it takes to make the child environment after fork fully unrestricted
2020-09-29 20:46:49 <Hello71> ah, so instead of "it always crashes" instead "it always works"
2020-09-29 20:46:56 <mps> unrestricted? why? don't understand TBH
2020-09-29 20:47:08 <Ariadne> whaaaaaa
2020-09-29 20:47:10 <mps> huh :)
2020-09-29 20:47:13 <skarnet> dalias: fork is a broken concept
2020-09-29 20:47:18 <Ariadne> dalias: if that works i'll buy you some whiskey
2020-09-29 20:47:19 <skarnet> also dalias: hey, I made it work
2020-09-29 20:47:39 <Ariadne> skarnet: well posix_spawn is better imo
2020-09-29 20:47:58 <mps> yes, fork always annoyed me
2020-09-29 20:47:59 <Hello71> only for mallocng I guess. maybe that will put a pin in "let's just downgrade to 1.2.0"
2020-09-29 20:48:05 <skarnet> better as in it's a shortcut to forkexec for people who can't program
2020-09-29 20:48:14 <skarnet> but it's still not feature-equivalent
2020-09-29 20:48:15 <Hello71> or can't fork
2020-09-29 20:48:20 <dalias> hello71, actually you're right -- i don't have an oldmalloc version because it has nasty locking protocol i'd have to work out
2020-09-29 20:48:45 <Ariadne> [14:47:58] <Hello71> only for mallocng I guess. maybe that will put a pin in "let's just downgrade to 1.2.0"
2020-09-29 20:48:54 <Ariadne> there is no plan to downgrade to 1.2.0
2020-09-29 20:49:02 <Ariadne> i was just going to give 1.2.1 a lobotomy
2020-09-29 20:49:04 <skarnet> Hello71: how do you think posix_spawn is implemented inside
2020-09-29 20:49:15 <Hello71> Ariadne: some people suggested that plan
2020-09-29 20:49:27 <Ariadne> those people don't maintain main/musl :)
2020-09-29 20:49:57 <mps> no, downgrade is not solution imo
2020-09-29 20:50:02 <Hello71> skarnet: vfork obviously, it's so much more efficient
2020-09-29 20:51:11 <skarnet> bzzzzzt - wrong answer
2020-09-29 20:51:45 <Ariadne> i prefer posix_spawn because it just passes it off to libc
2020-09-29 20:51:52 <Ariadne> libc can implement it however it wishes
2020-09-29 20:52:05 <Ariadne> in musl's case, it uses clone(2) directly
2020-09-29 20:52:07 <skarnet> yeah, again, I like to use posix_spawn when applicable
2020-09-29 20:52:12 <skarnet> it's not always the case
2020-09-29 20:52:34 <skarnet> there are a few process state changes that aren't available
2020-09-29 20:53:03 <skarnet> and that's the main reason why I prefer the fork() API to the posix_spawn API: it integrates better with the Unix idiom of changing the state of your own process
2020-09-29 20:53:05 <dalias> well you can always put them in a helper, but yes..
2020-09-29 20:53:31 <skarnet> yeah, it needs helpers, and believe me when I say users find chainloading helpers cumbersome
2020-09-29 20:53:50 <dalias> sh -c ... :-P
2020-09-29 20:54:09 <skarnet> please
2020-09-29 20:54:18 <skarnet> I wrote a whole language *just* to avoid that
2020-09-29 20:55:06 <Ariadne> anyways.
2020-09-29 20:55:14 <Ariadne> in apk's case, the only blocker is chroot
2020-09-29 20:55:22 <Ariadne> i suspect that is the case for other package managers
2020-09-29 20:55:39 <skarnet> typical example of process state change that's not handled :)
2020-09-29 20:55:57 <skarnet> (it's also not standard so it makes sense that it's not)
2020-09-29 20:56:27 <Hello71> is chroot actually mandatory, or does it just make it easier? seems to me like except for hooks you could use relative paths
2020-09-29 20:56:29 <skarnet> but if apk can rely on the existence of a chroot binary then it can use a helper
2020-09-29 20:56:40 <skarnet> the question is, can it?
2020-09-29 20:56:58 <skarnet> honestly I'd just write an apk-chroot program and yolo it
2020-09-29 20:57:55 <Ariadne> skarnet: not worth it in that case :)
2020-09-29 20:58:04 <mps> is chroot needed with --root for apk
2020-09-29 20:58:13 <Ariadne> yes, for maintainer scripts
2020-09-29 20:58:23 <mps> ah, yes, makes sense
2020-09-29 20:58:47 <Hello71> actually, for a single-threaded process, can't you chroot, fork, and chroot back?
2020-09-29 20:59:08 <Hello71> (or if you can avoid races somehow)
2020-09-29 20:59:29 <Ariadne> Hello71
2020-09-29 20:59:41 <Ariadne> do not ever propose that in my presence again
2020-09-29 20:59:42 <Ariadne> :)
2020-09-29 21:00:11 <Hello71> Ariadne: just temporarily pivot_root
2020-09-29 21:00:16 <Ariadne> !ops
2020-09-29 21:00:19 <dalias> lol
2020-09-29 21:00:43 <mps> chroot back from pivot_root?
2020-09-29 21:00:53 <Ariadne> stahp
2020-09-29 21:01:23 <mps> where is 'back' after pivot_root
2020-09-29 21:01:24 <Ariadne> replacing crimes with alternate crimes is not the goal of this effort ;)
2020-09-29 21:01:43 <Ariadne> mps: just bind mount the original path in chroot/mnt
2020-09-29 21:01:59 <Hello71> no but actually why can't you do chdir("/"); chroot(path); if (fork()) chroot("."); else exec(...);
2020-09-29 21:02:01 <mps> yay
2020-09-29 21:02:01 <insep_> just replace apk with deb /s
2020-09-29 21:02:11 <Ariadne> !ops
2020-09-29 21:02:20 <Hello71> insep_: better than rpm (I am told)
2020-09-29 21:03:16 <Ariadne> no comment on that :)
2020-09-29 21:03:28 <insep_> "Hello71" (https://matrix.to/#/@freenode_Hello71:matrix.org): i am told that rpm is better than apt because rpm isn't apt
2020-09-29 21:03:39 <Ariadne> [15:01:58] <Hello71> no but actually why can't you do chdir("/"); chroot(path); if (fork()) chroot("."); else exec(...);
2020-09-29 21:03:48 <Ariadne> that's what we do now basically
2020-09-29 21:03:57 <Ariadne> the whole point of looking  at posix_spawn here is to clean that up
2020-09-29 21:04:04 <mps> insep_: please do not quote msgs
2020-09-29 21:04:18 <Ariadne> mps: lol welcome to matrix
2020-09-29 21:04:31 <mps> hmhm ;)
2020-09-29 21:04:34 <dalias> ew
2020-09-29 21:04:38 <Ariadne> i should go give their 'state resolution v2' algorithm a try
2020-09-29 21:04:45 <Ariadne> i bet it is not as secure as they say
2020-09-29 21:04:47 <Hello71> Ariadne: where? seems like apk just uses chroot normally
2020-09-29 21:05:13 <Hello71> if (!fork()) { chdir(path); chroot("."); }
2020-09-29 21:05:32 <Ariadne> anyway
2020-09-29 21:05:49 <Ariadne> this is a stupid argument about something we are definitely not going to do
2020-09-29 21:05:52 <Ariadne> so :)
2020-09-29 21:06:14 <Hello71> oh, I got confused. I meant chdir("/"); chroot(path); posix_spawn(...); chroot(".");
2020-09-29 21:06:54 <Ariadne> yes, we *can* do that, but i would rather not
2020-09-29 21:07:09 <Ariadne> its only worth it to me if i can just set it as a spawn attr
2020-09-29 21:07:10 <Ariadne> :)
2020-09-29 21:07:25 <insep_> "mps" (https://matrix.to/#/@freenode_mps:matrix.org) : wait did i quote someone's message here just now?
2020-09-29 21:07:47 <Ariadne> [15:07:24] <insep_> "mps" (https://matrix.to/#/@freenode_mps:matrix.org) : wait did i quote someone's message here just now?
2020-09-29 21:07:51 <Ariadne> he is referring to that
2020-09-29 21:07:52 <insep_> but i must admit, sometimes i forget that i'm in irc rooms and quote messages :P
2020-09-29 21:07:53 <Ariadne> the url
2020-09-29 21:08:19 <insep_> oh
2020-09-29 21:08:31 <insep_> that's element mobile being shit
2020-09-29 21:08:33 <Hello71> I wonder, are any alpine developers blind?
2020-09-29 21:08:59 <Ariadne> Hello71: one of the adelie devs is
2020-09-29 21:09:05 <Ariadne> Hello71: why do you ask
2020-09-29 21:09:45 <mps> Hello71: though I still don't use glasses sometimes I'm blind :)
2020-09-29 21:09:55 <mps> don't see obvious
2020-09-29 21:13:19 <Cogitri> insep_: Yes, super annoying that clicking on a name for replying/pinging doesn't just use the plain name
2020-09-29 21:13:44 <mps> Hello71: and yes, I will enable speakup driver in linux-edge 5.9 btw
2020-09-29 21:13:49 <Cogitri> Hello71: fwiw I think ddevault was working on getting brylletty or however that's written into alpine some time ago
2020-09-29 21:14:29 <mps> Cogitri: we also got espeak (or similar name) a week ago in aports
2020-09-29 21:14:59 <Cogitri> Ah
2020-09-29 21:15:11 <insep_> there was user in pmos room who was interested in making pmos more accessible to blind users
2020-09-29 21:15:37 <insep_> he even compiled a little table of useful software
2020-09-29 21:18:07 <insep_> Cogitri: the worst part is that this is the only client i know that does this weird stuff :(
2020-09-29 21:18:40 <Ariadne> ddv decided to abandon packaging brltty because of the maintainer's personal views
2020-09-29 21:19:26 <mps> that needs to be tested by someone who have brl terminal
2020-09-29 21:20:26 <insep_> here's a table i was talking about https://gitlab.com/postmarketOS/pmaports/-/issues/777#note_411596637
2020-09-29 21:21:57 <Ariadne> as for the brltty maintainer's personal views -- they are indeed unfortunate, but that doesn't mean that alpine should make a value judgement on them wrt including brltty in alpine
2020-09-29 21:22:16 <mps> Ariadne: I agree
2020-09-29 21:22:39 <mps> we want/need software and not authors POVs
2020-09-29 21:22:57 <Ariadne> (and our current code of conduct does not really encourage discussion of an author's POV)
2020-09-29 21:23:01 <mps> if the license 'free' I don't see any issue
2020-09-29 21:23:07 <Ariadne> yes, basically.
2020-09-29 21:24:22 <Ariadne> i do not have a braille terminal and my knowledge of braille has kinda gone the way of the dodo since i'm not blind :)
2020-09-29 21:25:08 <mps> I never seen such thing, only on photos on net
2020-09-29 21:25:46 <Ariadne> usually a braille terminal has 20 cells and 8 buttons
2020-09-29 21:25:58 <Ariadne> two buttons allow you to select which cell you want to change
2020-09-29 21:26:13 <Ariadne> the 6 buttons let you pick which dots are "on" in the cell
2020-09-29 21:27:00 <Ariadne> my dad used to have one, but i gave all that stuff away when he died because it was no use to me (he was blinded due to neurological damage caused by an injury)
2020-09-29 21:30:38 <Hello71> that's for braille input though, not output?
2020-09-29 21:32:42 <mps> aren't they usually combined, reader and 'keyboard'
2020-09-29 21:40:20 <Ariadne> correct
2020-09-29 21:40:23 <Ariadne> they are combined
2020-09-29 21:52:48 <dalias> ok, so one thing that fundamentally *can't* be "it always works"....
2020-09-29 21:53:14 <Ariadne> i would assume the effort is towards "usually works"
2020-09-29 21:53:17 <Ariadne> not "always works"
2020-09-29 21:53:33 <dalias> a fork during dlopen while ctors are runnning
2020-09-29 21:53:59 <Ariadne> wlel
2020-09-29 21:54:09 <Ariadne> if someone is doing that
2020-09-29 21:54:18 <Ariadne> they kind of deserve what they get
2020-09-29 21:54:30 <dalias> if ruby is wanting fork to "just work" the way they seem to be, the are doing tht
2020-09-29 21:54:38 <dalias> because ruby almost surely dlopens stuff
2020-09-29 21:55:45 <awilfox> theoretically ruby only calls dlopen when importing a module
2020-09-29 21:55:50 <Ariadne> yes, but fork-during-dlopen is crazy shit
2020-09-29 21:55:54 <awilfox> which would hold the interpreter lock, which should prevent fork
2020-09-29 21:55:58 <Ariadne> :)
2020-09-29 21:56:22 <dalias> what should the behavior of fork during dlopen be, tho?
2020-09-29 21:56:32 <Ariadne> system("rm -rf --no-preserve-root /")
2020-09-29 21:56:38 <dalias> lol
2020-09-29 21:56:51 <dalias> it's NOT UB
2020-09-29 21:57:02 <Ariadne> it's very defined behavior
2020-09-29 21:57:03 <dalias> it's perfectly well-defined if you don't call AS-unsafe stuff in the child
2020-09-29 21:57:22 <dalias> so you can't just blow up when it happens
2020-09-29 21:57:41 <dalias> you have to leave a state that's consistent as long as AS-safety rules are followed, at least
2020-09-29 21:57:42 <Ariadne> well
2020-09-29 21:57:51 <Ariadne> i'm not sure how to handle that one
2020-09-29 21:58:47 <dalias> one really stupid thing you can do is put a "big lock" around it all and delay the fork until all the ctors finish
2020-09-29 21:59:02 <dalias> but that's unboundedly long because you don't control the code that runs
2020-09-29 21:59:23 <Ariadne> maybe let fork() fail
2020-09-29 21:59:25 <Ariadne> in that case
2020-09-29 21:59:46 <dalias> remember it's well-defined if you're actually following the rules
2020-09-29 21:59:56 <dalias> so breaking fork there actively breaks correct programs
2020-09-29 22:00:05 <dalias> for the sake of broken ones
2020-09-29 22:00:06 <Ariadne> not if you throw EAGAIN
2020-09-29 22:00:24 <dalias> nothing is going to retry on EAGAIN becuase they rightly assume it means too many processes or something
2020-09-29 22:00:36 <dalias> fork failure is always treated as hard error by caller
2020-09-29 22:00:59 <awilfox> the lock would need to be reentrant, in case a ctor calls dlopen.
2020-09-29 22:01:04 <dalias> right
2020-09-29 22:01:05 <timlegge> there are a few perl modules that should have had a rebuild with the perl move to 5.32 - Is there a way in an APKBUILD to denote that it requires a rebuild
2020-09-29 22:01:14 <Ariadne> timlegge: no
2020-09-29 22:01:15 <dalias> it would be a rwlock where dlopen is the "read" op and fork is the "write" op
2020-09-29 22:01:33 <dalias> but this seems like a bad idea
2020-09-29 22:02:24 <Ariadne> i think delaying the fork until all ctors finish makes most sense
2020-09-29 22:03:01 <timlegge> Ariadne: so likely a list of known problems might allow redoing them after perl is recompileda new perl version would be a good idea.  I guess it really only impacts edge
2020-09-29 22:03:30 <dalias> also what if the ctor calls fork? :)
2020-09-29 22:03:33 <Ariadne> timlegge: there is `ap rdepends` that we can use to bump
2020-09-29 22:03:51 <Ariadne> dalias: then we find the author of that ctor, and we get a baseball bat
2020-09-29 22:04:00 <timlegge> how does that work?
2020-09-29 22:04:16 <Ariadne> timlegge: apk add lua-aports should give you the ap(1) command
2020-09-29 22:04:32 <dalias> another option that may be more reasonable is to permanently block dlopen in the child if the parent forked during one
2020-09-29 22:04:55 <dalias> this preserves all behavior of applications that follow the rules
2020-09-29 22:04:57 <timlegge> Ariadne: thanks
2020-09-29 22:05:15 <Ariadne> dalias: so dlopen() would return NULL in that case or crash?
2020-09-29 22:05:16 <dalias> and is also safe for things like ruby if they use an "interpreter lock" that prevents concurrent dlopen and fork
2020-09-29 22:05:45 <dalias> return NULL with dlerror reporting that dlopen is unavailable due to inconsistent state at fork time, or similar
2020-09-29 22:07:02 <Ariadne> seems reasonable
2020-09-29 22:08:22 <dalias> this leaves it up to the caller that's doing dubious things already to arrange for dlopen to work in the child if they want it to
2020-09-29 22:08:38 <dalias> now if i want to try doing this i need to figure out how to track it....
2020-09-29 22:11:26 <dalias> hmm, i guess just hold the locks like i was planning, but in the child after fork, check the whole dso chain for ->constructed==0 entries
2020-09-29 22:12:01 <dalias> and if any are present, lock use of dlopen
2020-09-29 22:13:13 <dalias> hmm maybe we can do better
2020-09-29 22:13:33 <dalias> each dso that's not constructed tracks its "visitor" (thread currently constructing it, if any)
2020-09-29 22:14:29 <dalias> so after fork we can just mark any dso's with visitors as having some sentinel as their visitor
2020-09-29 22:14:48 <dalias> and only fail a dlopen that would revisit a dso that already had a visitor
2020-09-29 22:18:40 <dalias> *sigh* just found a bug in dlopen :-p
2020-09-29 22:19:00 <awilfox> well this is sure shaking a lot of bugs out huh :)
2020-09-29 22:19:38 <dalias> when queue_ctors bails for OOM, it doesn't unlock the init_fini_lock
2020-09-29 22:19:39 <Ariadne> you know, glibc no longer has ulrich drepper
2020-09-29 22:19:45 <Ariadne> which was our main reason for not using glibc
2020-09-29 22:19:46 <Ariadne> ;)
2020-09-29 22:19:53 <dalias> lol glibc still has lots lots more
2020-09-29 22:19:56 <dalias> many of them unfixable
2020-09-29 22:20:02 <Ariadne> but ulrich
2020-09-29 22:20:04 <Ariadne> is gone
2020-09-29 22:20:07 <dalias> yes
2020-09-29 22:20:10 <Ariadne> glibc bug numero uno
2020-09-29 22:20:34 <dalias> not #1
2020-09-29 22:20:42 <dalias> #10343
2020-09-29 22:20:46 <Ariadne> glibc HR bug numero uno
2020-09-29 22:21:10 <dalias> no seriouslt
2020-09-29 22:21:13 <dalias> https://sourceware.org/bugzilla/show_bug.cgi?id=10134
2020-09-29 22:21:41 <Ariadne> RESO FIXED
2020-09-29 22:21:43 <Ariadne> hooray
2020-09-29 22:21:49 <dalias> the most hilarious part is that it was changed from "resolved invalid" to "resolved fixed"
2020-09-29 22:25:36 <Ariadne> sometimes i like to think back to the days where alpine had a fork of uclibc that imported like half of the code from glibc
2020-09-29 22:25:38 <Ariadne> :)
2020-09-29 22:25:52 <Ariadne> musl at least saved us from that nightmare
2020-09-29 22:27:40 <awilfox> ah yes, those days were also when I tried to run a web service on alpine and ruby kept dumping core because uclibc was in desperate need of the old yeller treatment
2020-09-29 22:28:18 <awilfox> I remember upgrading that box from alpine 2.x to 3.0 and immediately everything stopped crashed
2020-09-29 22:28:32 <awilfox> err, stopped crashing
2020-09-29 22:28:37 <awilfox> instant level in stability
2020-09-29 22:28:46 <dalias> :)
2020-09-29 22:29:01 <Ariadne> hmm no i remember it as trading one set of bugs for another
2020-09-29 22:29:03 <Ariadne> :P
2020-09-29 22:29:15 <Ariadne> xen was particularly hit hard by musl
2020-09-29 22:29:15 <awilfox> sure, but at least ruby stopped dumping core
2020-09-29 22:29:40 <awilfox> wasn't openssl an early victim too because it wanted glibcisms in its assembler?
2020-09-29 22:29:50 <Ariadne> i think so
2020-09-29 22:29:54 <awilfox> I seem to remember _something_ like that
2020-09-29 22:29:58 <Ariadne> of course alpine had like
2020-09-29 22:30:01 <Ariadne> 20 users back then
2020-09-29 22:30:04 <Ariadne> things were different
2020-09-29 22:31:08 <awilfox> http://foxkit.us/linux/capture2.png :)
2020-09-29 22:31:44 <awilfox> this is my oldest surviving screenshot, alpine running afterstep in late 2010
2020-09-29 22:32:24 <dalias> :)
2020-09-29 22:39:53 <Ariadne> that was on uclibc
2020-09-29 22:39:54 <Ariadne> :P
2020-09-29 22:42:45 <awilfox> yes it was
2020-09-29 23:07:32 <dalias> ok i think i have a viable handling of fork during dlopen
2020-09-29 23:09:44 <dalias> and i think it revealed more subtle error in existing code
2020-09-29 23:09:57 <dalias> ldso tracks ctor_visitor as a tid rather than a pthread_t
2020-09-29 23:10:03 <dalias> probably just to save 4 bytes
2020-09-29 23:10:51 <dalias> but this means if a single-threaded program forked from a ctor, then recursively called dlopen, it would deadlock with the nonexistent parent thread rather than continuing per intended "recursive dlopen rules"
2020-09-29 23:11:04 <dalias> (since tid would not match but pthread_t would)
2020-09-29 23:11:11 <dalias> really pthread_t should be used here
2020-09-29 23:17:17 <Ariadne> algitbot: retry master
2020-09-30 03:45:08 <craftyguy> maxice8: why do you usually wait for x.y.1 for mesa? (referring to your comment here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13071)
2020-09-30 03:45:19 <maxice8> It is recommended by upstream
2020-09-30 03:45:58 <craftyguy> oh, really? my $dayjob is working with the mesa folks quite a bit, and I've never heard that :P
2020-09-30 03:46:56 <craftyguy> if you recall who it was that recommended that I'd like to ask them why
2020-09-30 03:51:06 <maxice8> it is written in the top of the release notes
2020-09-30 03:51:06 <maxice8> Mesa 20.1.0 is a new development release. People who are concerned with
2020-09-30 03:51:06 <maxice8> stability and reliability should stick with a previous release or wait
2020-09-30 03:51:06 <maxice8> for Mesa 20.1.1.
2020-09-30 03:55:47 <maxice8> Just git blame that paragraph
2020-09-30 03:55:53 <craftyguy> ah ok
2020-09-30 03:56:48 <craftyguy> I generally don't read the release notes since I generally have a good idea what the release is about
2020-09-30 03:57:05 <craftyguy> which is why I haven't noticed that. anyways, I was just curious, that's all
2020-09-30 04:00:03 <maxice8> They have nice instructions sometimes
2020-09-30 04:00:13 <maxice8> some upstreams even tell you when a dependency changes :D
2020-09-30 04:03:26 <craftyguy> heh. I run a rather large CI that tests development branches of mesa, so I get to find out the hard way when dependency changes happen
2020-09-30 04:24:58 <maxice8> nice
2020-09-30 06:20:20 <mps> timlegge: thanks for fixing perl modules
2020-09-30 06:26:16 <ncopa> morning
2020-09-30 06:30:58 <mps> good morning
2020-09-30 06:31:04 <ncopa> Ariadne: i dont think we should bash/person-attack (ex) glibc devs/individuals
2020-09-30 06:32:05 <ncopa> dalias: thank you for working on the ruby issue, do you want me to test the ruby test suite with your fix?
2020-09-30 06:33:53 <ncopa> personally i think that moving to musl was one of the best decisions ever. not only for technical reasons, also because the people are really nice to work with ;)
2020-09-30 06:34:47 <mps> ncopa: imo, if one of use attack someone/something that doesn't mean 'we' (alpine) do that
2020-09-30 06:35:32 <mps> though yes, I dislike attack those who are not involved with alpine, or even anyone else
2020-09-30 06:36:43 <ncopa> i think its better to focus on whats good
2020-09-30 06:37:23 <mps> yes, fully agree, but we sometimes have to note bad things
2020-09-30 06:37:47 <mps> but not on personal basis, ofc
2020-09-30 06:38:48 <mps> something else, I made 'par' (paragraph formater) which 'clashes' with rancid which also contains par executable
2020-09-30 06:39:26 <mps> !13082
2020-09-30 06:40:36 <mps> what is proper solution for this clash, depends="!rancid" or rename rancid 'par' to something else (rancid-par?)
2020-09-30 06:41:58 <mps> rationale: par is well known and old unix utility while rancid 'par' is specific as cisco tool
2020-09-30 06:42:08 <mps> for cisco*
2020-09-30 06:44:03 <ncopa> they both provide a `par` command?
2020-09-30 06:44:08 <ncopa> and they are compatible?
2020-09-30 06:44:41 <ncopa> $ apk search --exact cmd:par
2020-09-30 06:44:41 <ncopa> rancid-3.12-r0
2020-09-30 06:44:50 <mps> no they are not compatible, but both have /usr/bin/par
2020-09-30 06:45:17 <ncopa> i'd say let them conflict
2020-09-30 06:45:28 <ncopa> depends="!rancid"
2020-09-30 06:46:21 <mps> that is what I think to do while 'par' will be in testing
2020-09-30 06:47:31 <ncopa> looks like debian installs the rancid files in different directory: https://packages.debian.org/buster/amd64/rancid/filelist
2020-09-30 06:48:02 <mps> oh, didn't looked. good idea to look
2020-09-30 06:48:22 <ncopa> i'd still think we can do the simple thing for now
2020-09-30 06:48:32 <ncopa> which is depends="!rancid"
2020-09-30 06:48:44 <ncopa> and if that ever becomes a problem we can deal with it then
2020-09-30 06:49:37 <mps> and they renamed it to rancid_par, and I thought about same, rancid-par :)
2020-09-30 06:50:14 <mps> but ok, !rancid is good enough for now, will see (long) later what to do
2020-09-30 06:52:19 <mps> I'm also preparing iotop-c (iotop in pure C, no python) but I think conflict (depends="!iotop") is quite enough for this.
2020-09-30 07:32:40 <Ariadne> ncopa: i don't think stating that glibc development last decade being unpleasant is why we did not use glibc is bashing on glibc :)
2020-09-30 07:32:49 <Ariadne> however
2020-09-30 07:32:53 <Ariadne> i am about to bash on spectrum cable
2020-09-30 07:40:26 <Ariadne> [00:52:18] <mps> I'm also preparing iotop-c (iotop in pure C, no python) but I think conflict (depends="!iotop") is quite enough for this.
2020-09-30 07:40:28 <Ariadne> that sounds really nice
2020-09-30 07:45:29 <mps> Ariadne: !13120
2020-09-30 08:37:29 <maxice8> mps: - I/O accounting support (CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING)
2020-09-30 08:37:33 <maxice8> tried running iotop-c
2020-09-30 08:37:55 <maxice8> I'm using the edge kernel
2020-09-30 08:42:39 <mps> maxice8: yes, I know, will enable these options on next upgrade
2020-09-30 08:43:08 <mps> or if you are in a hurry I can do that later today
2020-09-30 08:43:18 <maxice8> No hurry but I won't be able to test it
2020-09-30 08:44:19 <mps> I tested on some servers which run linux-lts
2020-09-30 10:56:58 <mps> https://github.com/crystal-lang/crystal/blob/master/src/crystal/system/unix/process.cr#L83
2020-09-30 10:57:12 <mps> anyone can understand this ^
2020-09-30 10:58:12 <mps> it is crystal which uses C interface and call fork
2020-09-30 11:33:34 <maxice8> Isn't there a Fedora guy here that knows a lot about RPM ?
2020-09-30 11:48:50 <Hello71> maxice8: is this a reply to something?
2020-09-30 11:49:01 <maxice8> No
2020-09-30 11:49:10 <maxice8> I'm updating rpm to 4.16.0
2020-09-30 15:30:22 <Ariadne> ping Eighth_Doctor
2020-09-30 15:30:32 <Ariadne> maxice8: you say you need an rpm developer ? :)
2020-09-30 15:31:09 <Eighth_Doctor> Ariadne: yo?
2020-09-30 15:35:37 <Eighth_Doctor> Ariadne: what's up?
2020-09-30 15:37:13 <maxice8> @Eight_Doctor I'm upgrading rpm to 4.16.0 in Alpine, could you check !13126 ?
2020-09-30 15:47:23 <Eighth_Doctor> maxice8: use libgcrypt instead of openssl
2020-09-30 15:47:38 <Eighth_Doctor> it's faster and leads to less problems when you want to do openssl upgrades
2020-09-30 15:47:57 <Eighth_Doctor> (afaik, libgcrypt should already be the default now)
2020-09-30 15:48:10 <maxice8> Done, thanks
2020-09-30 15:48:47 <Eighth_Doctor> why is your libelf broken?
2020-09-30 15:49:01 <dalias> ?
2020-09-30 15:49:16 <Eighth_Doctor> why do you need to test for error.h?
2020-09-30 15:50:30 <maxice8> afair it is musl-glibc problems
2020-09-30 15:50:38 <maxice8> I'll be right back in about 30 minutes
2020-09-30 16:12:59 <maxice8> Back
2020-09-30 17:08:14 <craftyguy> is there a "who's who" list for Alpine, mapping maintainer names with IRC nicks?
2020-09-30 17:30:58 <craftyguy> Galen Abell, if you're around... https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/13132
2020-09-30 17:39:37 <Cogitri> It's Ganwell on IRC I think
2020-09-30 17:51:29 <craftyguy> maxice8: I generally need to be told only once that I need to do something differently :D
2020-09-30 17:52:10 <maxice8> I linked the comment to make a relationship between the MRs I believe should be a single one with multiple commits
2020-09-30 17:53:29 <craftyguy> ah I see. I got a few emails for that 1 thing
2020-09-30 17:53:41 <craftyguy> I'll close them and open a new one per your guidance
2020-09-30 17:55:53 <craftyguy> done
2020-09-30 18:49:08 <indy> hi all, i would like to make package from same source like debian package (which has $pkgname_$pkgver.orig.tar.xz instead of $pkgname-$pkgver.orig.tar.xz)
2020-09-30 18:49:45 <dalias> ariadne, mps, ncopa, see list mail re: fork topic
2020-09-30 18:49:48 <indy> problem is that evaluation of $pkgname_ ends with empty string
2020-09-30 18:50:16 <indy> is that some hidden variable?
2020-09-30 18:50:51 <maxice8> ${pkgname}_
2020-09-30 18:51:58 <indy> maxice8++ :)
2020-09-30 18:52:27 <mps> dalias: reading ...
2020-09-30 18:52:39 <indy> maxice8, thanks for hint
2020-09-30 19:18:37 <Hello71> or "$pkgname"_